mupPR snapd#8903 opened: tests: new core config helper <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8903>03:25
=== JanC_ is now known as JanC
mborzeckimvo: hey05:51
mborzeckiquick errand, brb05:53
mvomborzecki: good morning05:54
zygaGood morning06:32
zygaI will start at 906:32
zygaGood to see you mvo!06:32
mvozyga: good morning. even better to see you :)06:33
mvozyga: hope you are well (enough)!06:33
mborzeckizyga: hey06:39
zygaI’m going to be soon. Just had my morning painkillers06:40
zygaBut even without them I think there is an improvement06:40
mborzeckizyga: something is off in centos 8 with the change from #890106:40
mupPR #8901:  tests/lib/tools: apply linger workaround when needed  <Precious Logs> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8901>06:40
mvozyga: nice!06:40
zygamborzecki: I’ll look in 20 minutes06:41
mborzeckizyga: thanks06:45
mupPR snapd#8904 opened: snapstate: use testutil.HostScaledTimeout() in snapstate tests <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8904>06:56
zygain makeshift floor office07:02
zygaI'm on bug shift today07:02
mborzeckipstolowski: heya07:07
* zyga looks at the PRs 07:11
mborzeckifunny 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 tests07:12
zygamborzecki: can you push the syntax fixes to https://github.com/snapcore/snapd/pull/8901/files please07:12
mupPR #8901:  tests/lib/tools: apply linger workaround when needed  <Precious Logs> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8901>07:12
zygacommented in the RP07:13
mborzeckizyga: ah, w8, the code that retries linger is further down07:14
zygaI don't see any07:15
mborzeckizyga: line 161/16907:15
mborzeckizyga: w8, 143/15107:15
zygaah I understand now07:16
mborzeckizyga: enabling twice should be harmless, right? it jus drops a file under /var/lib/ssytemd/linger07:17
zygaIIRC it does more than that07:17
zygabut it enabling twice should be harmless if it works right07:17
zygaI wonder what happens if we try and fail07:17
zygafix the system07:17
zygaand try again07:17
zygaenabling linger does start all the user services07:18
mborzeckizyga: maybe we should disable/stop user@<uid>.service?07:18
mborzeckizyga: in the branch when enable fails07:18
zyganot sure, we'd have to look at logind to see what it does and where the current failure is placed in the sequence of calls07:18
mupPR 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
mupPR 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
zygaok, my plan for today is to work some more on the udev mystery07:39
zygaand then do bug triage07:39
zygaand some iteration on branches07:39
* mborzecki wonders how to split a 2k 'WIP' commit nicely into smaller patches07:47
CruftWhy is there an autostart service running without snaps that require auto starting applications?08:01
zygaCruft: the auto-start service runs once on session startup, in case there are things to do IIRC08:04
Cruftbut 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
zygacan you be more specific please, I'm not sure I understand what you meant08:07
Cruftits to help snapd make sure the snap program(s) that have autostart functionality are run on startup correct?08:08
CruftWouldn't you already know upon installation and or boot that that was the case?08:08
zygaas those programs cannot use the normal method for starting08:08
zygaI'm sorry, know what?08:08
zygathat some programs auto-start?08:09
CruftThat they would otherwise autostart08:09
CruftThey are mounted on install right?08:09
zygaare 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
zygayes, they are mounted08:09
CruftNo. I'm saying that the auto start service should not be run unless an auto start application exists08:09
zygaI see what you mean now08:10
zygait's much easier this way08:10
CruftAlso that in the event that auto start applications exist, that it can be explicitly turned off if not already possible, therefor not running after08:10
zygawe'd have to enable or disable this08:10
zygaare you saying that you'd like to control this per app?08:10
Cruftbut A makes B easier08:11
zygaI think they are unrelated, A is a service that you can disable per user or globally08:11
CruftI can control microphone permissions but not autostart? Eh.08:11
zygaB is new (per user) state that needs UI and APIs to drive08:11
zygaautostart is not an interface08:12
zygaI see what you mean but it's not done this way technically08:12
CruftIs it just using freedesktop conventions to determine this?08:12
CruftWithin the snap(s)08:13
zygasomewhat, but it's more complex to prevent confinement escape08:13
mborzeckiCruft: kind of, the app cannot drop a random file under $HOME/.config/autostart, iirc the service looks inside ~/snap/<name>/ instead08:13
Cruftright so its using the same xdg / .config i guess per user autostart as a determination within the snap tree?08:15
zygathere's also some extra layer08:15
zygathat matches the desktop file08:15
zygaagain, to prevent confinement esape08:15
zygawe cannot just use the desktop file that was created by the app08:15
CruftI'm more thinking in terms of deciding to run at all08:15
zygaeventually there will be a portal08:16
zygaand the UI will be nice08:16
zygathis makes it work with existing programs08:16
zygawithout new APIs08:16
mborzeckiCruft: maybe it's somthing to consider, but the whole selecting which app runs by tweaking gnome session is a pita since the old days08:17
CruftYou must understand though that people who have no autostart snaps are now having their boot further slowed by a service to autostart snaps08:17
zygais it this slow?08:18
CruftIts not fast, it was slower than alot when I measured. That is how I found the service.08:18
CruftI have many snaps but none autostart08:19
mborzeckiCruft: hmm the sevice actually globs inside ~/snap/*/current/.config/autostart08:19
zygaCruft: unfortunately there's no easy way to make it conditional08:19
Cruftright so you would know at install time08:19
zygaCruft: as snapd does not mediate the act of opting into or out of autostart08:20
Cruftto run the service in userspace08:20
zygano, we don't know at install time08:20
zygawe only look in that auto-start service08:21
zygaand if the file is there and matches something in the snap definition08:21
zygawe start the snap app08:21
zygawe don't have an event when a running app enables auto-start08:21
CruftSo you have no first mount etc hook08:23
Cruftfor current or whatever08:23
zygathis is not related to mounting08:23
zygaI don't think you understand how this works08:23
zygawhen a running app decides to enable auto-start08:23
zygait drops a file into an xdg location08:23
zygawe only re-map $HOME so it's not the real location08:23
zygathat's all08:24
zygawhen a session starts, the auto-start service scans the per-snap $HOME of each snap08:24
zygaand looks for the xdg auto-start information08:24
zygaand then acts on it08:24
zygathat's it08:24
zygathere's no more logic08:24
CruftSo rather than scanning post mount it scans every time you boot08:24
zygait's not post mount because this is dynamic08:25
zygaand it's not every time you boot08:25
zygait's in the user session08:25
zygathere's no way to statically say you want to auto start an app via xdg08:25
CruftSo then why isn't the service disabled if no new snaps have been installed08:25
zygayou must create a desktop file in a specific location in the home directory08:25
zygabecause it's not something we considered important, when there's nothing to do it's doing nothing pretty quickly08:26
zygaand making it better is really hard08:26
zygaand again08:26
zygayou misunderstand how it works when you talk about installed snaps, you can have one snap and it can opt in and out of autostart08:26
zygaso it's not about that08:27
mborzeckiCruft: w8, maybe i'm confused, which service are we discussing here? /etc/xdg/autostart/snap-userd-autostart.desktop ?08:27
CruftI believe that was the one08:27
CruftLet me check08:27
mborzeckiCruft: 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 exits08:30
ograCruft, 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 start08:30
ograsnaps are mouned by systemd during boot ... way before you reach any session you could access08:31
CruftOh believe me, I saw.08:31
mborzeckiCruft: 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
Cruftand that it shouldn't be in either case.08:33
ograsounds like these are simply bugs ...08:33
mborzeckiCruft: can you do `ps -ef |grep userd` ?08:34
CruftIt could literally check during updates at the same time08:34
* zyga is confused about updates08:34
Cruftyes, there is a line with the pid, time, etc08:35
mborzeckiCruft: can you paste it?08:35
Cruftno, i'm not on that computer on this machine08:35
Crufti can retype it i guess08:35
mborzeckiCruft: 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 standards08:38
Cruftyou could shard them out in sqlite if you use that08:39
Cruftas they currently stand08:39
zyganone of that matters if apps don't use that08:40
zygaso we support what apps do08:40
CruftI'm not sure what you're asking me to type mborzecki08:40
mborzeckiCruft: `ps -ef|grep userd`, there should be a command in the last column that starts with `snap userd..`, please paste/type that in the channel08:40
ograhe wants the most right entry of the ps output 🙂08:40
Cruftsnap userd08:41
zygathat's the other userd08:41
zyganot the auto-start thing08:41
mborzeckiCruft: 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 sanitized08:45
ogra... and that specific one is rather unlikely to have any impact on session startup time ...08:46
mborzeckiCruft: so you're saying that one starts slow?08:46
ogra(as it starts async and nothing but snaps depend on it)08:46
CruftI can see that. I didn't realize this was go08:47
Cruftwelp, looks like i need to Delve into it08:49
mborzeckiCruft: `snap userd` is actually started via dbus activation08:50
mborzeckiCruft: i don't think it shows up as a systemd --user service08:51
Cruftok yeh I see the two dbus unconfined services for snapd userd08:55
mborzeckiCruft: yes, io.snapcraft.Settings and Launcher08:59
=== ricab__ is now known as ricab
zygamvo: o/10:32
zygamvo: 2.45 is not released, right?10:32
zygaI mean, I see it in groovy10:33
zygabut focal has 2.4410:33
mvozyga: I asked sil2100 to look at the 2.45.1 SRU, he said he will get to it today :)10:33
mvozyga: but yeah, it's waiting in the unapproved queue10:33
zygasure I just wanted to know10:34
zygamvo: one more thing10:34
zygamvo: the core snap is at 2.45 while snapd is at 2.45.110:34
zygais that expected?10:35
mvozyga: maybe because of phasing, let me double check10:35
mvozyga: hm, that sounds like we need to ask cachio what is going on there10:35
zygathanks, I just wanted to understand where we are to update bugs that are fix commited10:36
mupBug #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
zygamvo: do you expect 2.45.1? I would like to update the launchpad milestones10:38
zygaoh. we have one :D10:39
mupBug #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
mupBug #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
zygaI updated all the milestones that were open10:45
zygamvo: is the next release going to be 2.45.2 or 2.46?10:46
mvozyga: there will be a 2.45.2 most likely we have some requests for this10:50
zygaI see10:50
=== pedronis_ is now known as pedronis
mupPR snapd#8905 opened: bootloader: introduce managed bootloader, implement for grub <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8905>10:52
mborzeckipedronis: trivial piece ^^10:52
pedronismborzecki: thanks, will try to look at it soon10:53
mvodegville: 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
degvillemvo: html comments work11:01
degvilleie. <!-- comment -->11:01
mvodegville: is that what is what we use elsewhere too? if so, I will use it11:02
mvodegville: is the preview confused? in the preview the comment is displayed as is11:03
degvillemvo: 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
degvillemvo: it shouldn't be visible in the preview?11:04
mvodegville: hm, maybe I do something wrong, let me try again11:05
degvillemvo: At least, I've just tried it and it's hidden for me.11:05
mvodegville: yeah, silly me, works11:06
mvodegville: thank you11:06
degvilleit's not very pretty.11:06
mupPR 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
mupPR snapd#8907 opened: asserts: implement Database.FindSequence <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8907>11:07
mupPR snapcraft#3184 closed: build providers: check revision before switching <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3184>11:33
zygamvo: is https://github.com/snapcore/snapd/pull/8436 something you wanted to cherry pick into 2.45.2?11:38
mupPR #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
zygaI'm asking if I should target the bug report accordingly11:39
zygaI set the bug to target 2.46, if you want it in 2.45.2 just ping me and I'll adjust things11:41
mvozyga: iirc it was not super urgent but I can double check11:41
zyga2.46 is fine11:41
zygaI'm only asking because it was squash merged11:41
=== alan_g_ is now known as alan_g
zygasil2100: are we using classic eth0 or the new "stable" names on core images?11:50
zygasil2100: the context is a bug where pi4 has different behavior than prior images11:50
pedronisijohnson: I re-reviewed #868312:16
mupPR #8683: osutil/disks: support IsDecryptedDevice for mountpoints which are dm devices <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8683>12:16
mupPR snapd#8908 opened: overlord/snapstate: graceful handling of denied "managed" refresh schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8908>12:17
mborzeckipedronis: ^^12:17
pedronismborzecki: reviewed12:36
mborzeckipedronis: thanks12:37
zygapedronis: 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 wrappers12:40
zygapedronis: currently the allowed app expression is:12:41
zygavar appContentWhitelist = regexp.MustCompile(`^[A-Za-z0-9/. _#:$-]*$`)12:41
pedroniszyga: it's related to snapcraft dropping wrappers support for core2012:41
zygalooking at this I think that adding = is probably okay12:41
zygabut I wanted to ask you for advice12:41
zygaindeed, it's mentioned in the bug report12:41
pedroniswell, we need to think this through12:41
zygasure, I've left it as whishlist12:42
pedroniszyga: feel free to assign to it to me12:42
pedronisdoesn't mean we'll get to it quickly, but it's blocked on me either way12:42
zygasil2100: do you know where to track bugs about raspberry pi kernel?12:44
zyga(on core)12:44
ijohnsonThanks pedronis12:49
sil2100zyga: hm, I guess I'd have to check with the ethernet device names, can't say from the top of my head12:56
zygasil2100: the bug claims that pi4 uses eth012:56
zygasil2100: but earlier devices us en!@!#@!@#!12:56
sil2100zyga: 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
mupPR 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
zygathanks, that's what I needed12:57
zygasil2100: hmm, no such project12:58
zygaoh well12:58
zygastandup time12:58
sil2100zyga: hah, it's not a project, it's a package: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/13:09
ograzyga, 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
mupBug #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
zygaogra: ah, a source package13:15
zygaogra: got that, thanks!13:15
* zyga breaks for lunch13:38
mupPR 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
mupPR 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
pstolowskii 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 ops14:48
mupBug #1882957: Snapd `internal error: connection "[slot] [plug]" not found in state` <snapd:Confirmed for stolowski> <https://launchpad.net/bugs/1882957>14:48
cachiomvo, hey14:58
cachiomvo, the snap ubuntu-clock-app isnot in the repo anymore, so the test for unity fails14:58
cachiodo you know any other snap that could be used instead14:59
mupPR snapd#8910 opened: usersession: support additional zoom URL schemes <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8910>15:03
mborzeckihm gadget Update/Backup/Rollback could use a little refactor15:08
mborzeckianyways, errands, bbl15:10
mvocachio: uh, a good question15:14
* cachio lunch15:29
abeatozyga, 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
abeatohi :)15:35
zygaah , //deleted15:35
zygaI'm doing bug triage now, can you please show me some more context15:35
abeatoI am installing on qemu, while running spread tests15:36
abeatoI have a snap version with core18, and I install on top a core20 version of the snap15:36
abeatothe first does not use layouts, the second does15:36
abeatoif I reinstall the snap, things look good and there is no //deleted string15:37
zygawhat are the layout definitions15:39
zygaactually, I think it's best if you report a bug15:39
zygawith all the details15:39
zygaI'll try to look at it in the evening15:39
zygaI have a few more bugs to go through today15:39
abeatozyga, sure will do - I wanted to double check if this was a known issue before15:40
zygait may be known behavior15:40
zygadepending on the paths used15:41
zygathe //deleted thing is really interesting part of linux15:41
zygaI didn't know about it before I started working on snapd15:41
abeatoseems like some timing problem, some times happens, some times it does not15:41
zygaabeato: I think it's not timing as snapd is freezing the world for mount changes15:43
zygaprobably sequence15:43
zygaI'll gladly analyze it in detail and explain what's going on15:43
ijohnsoncachio: for https://github.com/snapcore/snapd/pull/8902#issuecomment-648236050 how did you reproduce this ?15:49
mupPR #8902: tests: fix assertion disk handling for nested UC systems <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8902>15:49
abeatozyga, https://bugs.launchpad.net/snapd/+bug/188480615:52
mupBug #1884806: layouts are not honored some times <snapd:New> <https://launchpad.net/bugs/1884806>15:52
zygaabeato: thank you!15:57
=== grumble is now known as rawr
zygaabeato: btw, what is /usr/var?15:59
abeatozyga, a folder with some config files for NM16:00
zygaI mean, I don't have /usr/var on my classic system16:00
zygait's a weird location16:00
zygais that hardcoded in n-m?16:00
abeatozyga, it is the default in nm, unless you change it with config options - which we do in the deb16:01
abeatofor the snap anyway we override it16:01
zygaI see16:01
zygaI'll look more closely16:02
zygacan you do one quick test perhaps16:02
zygarefresh the exact same revision twice16:02
zygajust install --local perhaps16:02
zygaand see if that has the same effect16:02
abeatohm I did not know that one16:02
abeatozyga, not sure what is that? 'snap install --local' does not exist16:03
abeatozyga, refreshing the same revision actually works16:03
abeatozyga, also disabling then enabling the snap16:04
zygaah, sorry16:04
zyganot local16:04
zygaI meant --dangerous :)16:04
zygaand just install the .snap file16:04
zygainstaling the same snap file twice tests if layout system can re-construct a no-update update16:05
abeatozyga, yeah, that works16:07
zygaabeato: thanks for checking, that's useful to know16:07
zygaabeato: perhaps there's an issue with core18 -> core20 transition16:08
zygaI'll debug this16:08
mupPR 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
pedronisijohnson: this ^ tries to address some of your concerns about the seed code16:13
ijohnsonthanks I will take a look16:14
mvopedronis: I updated 8889 a bit16:31
pedronismvo: thx, adding it back to my queue16:33
mupPR snapcraft#3185 opened: cli: allow promoting from edge without --yes <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3185>16:44
zygamvo: I'll take a break now, see you tomorrow16:59
zygaafter Thursday typing won't be such a chore16:59
cachioijohnson, sorry17:20
cachiospread -debug google-nested:ubuntu-16.04-64:/tests/nested/core/image-build17:20
ijohnsoncachio: I am running `spread --debug -v google-nested:...:tests/nested/` now, and have not seen any failures yet17:20
cachiospread -debug google-nested:ubuntu-16.04-64:tests/nested/core/image-build17:20
ijohnsonhaha literally as I just sent that it failed on a tet17:21
ijohnsonlet me look17:21
cachiocore-18 workerd perfect here17:21
cachioijohnson, also failed with timeout uc2017:22
ijohnsoncachio: yes I just saw the uc20 failure here, I will investigate17:22
ijohnsonactually I need to break for lunch, but will investigate more afterwards17:22
cachioijohnson, something that I forgot SPREAD_USE_CLOUD_INIT=false17:22
cachioyou need to use that to force the use of the assertion disk17:23
cachiootherwise by default it will use cloud_init17:23
ijohnsoncachio: let's chat a bit later after I'm back from lunch17:23
=== ijohnson is now known as ijohnson|lunch
cachioijohnson|lunch, sure17:24
cachiomvo, should we run the unity test in nightly in case there is not any unity snap available?17:46
ijohnson|lunchcachio: I didn't reproduce that error with my current patchset, let me push it up before my next meeting17:52
ijohnson|lunchcachio: I will attach the log from my run in the PR17:52
=== ijohnson|lunch is now known as ijohnson
cachioI'll make another tun17:53
ijohnsoncachio: please pull from the branch, but here's the output from my most recent run https://github.com/snapcore/snapd/pull/8902#issuecomment-64832173717:55
mupPR #8902: tests: fix assertion disk handling for nested UC systems <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8902>17:55
mvocachio: I think we can stop testing unity if we don't have any snaps. let's remove it17:55
cachiomvo, sure, thanks17:56
ijohnsoncachio: 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 disk17:56
ijohnsoncachio: in other words the spread run I linked to in the PR comment doesn't have SPREAD_USE_CLOUD_INIT=false defined17:57
ijohnsoncachio: so if you could test just normally that would be great to see17:57
cachioijohnson, ok17:57
cachiolet me try17:57
ijohnsonI will look more after my meeting now17:57
cachioijohnson, in core16 workerd with SPREAD_USE_CLOUD_INIT=false and without18:19
cachioso the fix works18:19
cachiolet me check uc2018:19
ijohnsoncachio: yes let me look at why the uc20 ones failed18:34
mupPR snapcraft#3186 opened: Riscv64 support <Created by xnox> <https://github.com/snapcore/snapcraft/pull/3186>18:34
ijohnsoncachio: for me, only tests/nested/core20/basic and 64:tests/nested/manual/core20-early-config failed18:34
cachioijohnson, yes, this is something different18:36
cachioI need to take a look tomorrow to that one18:36
cachioijohnson, so, on uc20 the user assertion creates the user but then I see https://paste.ubuntu.com/p/zgDk4hWFqb/18:57
cachioerror: too early for operation, device not yet seeded or device model not acknowledged18:57
cachioijohnson, I am running again18:57
ijohnsoncachio: ah interesting18:57
ijohnsoncachio: 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 up18:58
roadmrjdstrand: heads up, xnox is about to send your way a bug about making review-tools happy with a new architecture18:58
cachioperhaps we'll need to wait until seeding is copmleted, right?18:58
ijohnsoncachio: perhaps18:59
ijohnsoncachio: for uc20 probably yes, but the /dev/mapper issue is not related to seeding18:59
ijohnson(but I know how to fix it18:59
jdstrandroadmr: that will be interesting to fix, as I likely will need core20 but focal has bugs in various places19:00
roadmrthe fun19:00
ijohnsoncachio: did you ever figure out the deal with uc20 nested VMs rebooting constantly ?19:14
cachioijohnson, well, it used to reboot 1 once by using -smp 119:14
ijohnsoncachio: 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 rebooted19:15
cachioijohnson, I saw different bug reports similar19:15
cachiobut not sure the reason19:15
cachioijohnson, reboots in install mode?19:16
cachiorun mode?19:16
ijohnsoncachio: in run mode19:16
ijohnsoncachio: although actually maybe install mode too, don't remember19:16
ijohnsonlet me show you the log19:16
cachioit is the same I see19:16
cachiohere in the last log19:16
ijohnsoncachio: this is the serial boot log from the nested VM: https://pastebin.ubuntu.com/p/b9PHpFkFKm/19:19
ijohnsonyeah it was rebooted 6 times I guess, all the unintended reboots were in run mode19:20
cachioijohnson, well this is not normal19:20
cachioat least should reboot 1 extra time19:20
cachiobut not more19:20
ijohnsonhaha yeah I would agree it is not normal for a VM to get randomly rebooted 6 times at random points in the boot sequence19:21
cachioperhaps it is related to the usr assertion19:21
ijohnsoncachio: could be, this run was with SPREAD_USE_CLOUD_INIT=false just to see what happens with the assertions on all the systems19:22
cachioI triggered new executions with and without user assertion to see if that could be the reason19:22
ijohnsonit eventually made it to a successful boot and is running normally now, but it did not import the assertion on uc2019:22
cachiolast run I did worked, it took 15 minutes to prepare the nested vm and connecto shrough ssh19:23
ijohnsoncachio: it is very slow19:24
cachioijohnson, yes19:24
mupPR 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
cachioperhaps there were some reboots19:24
cachioijohnson, this is the last run https://paste.ubuntu.com/p/83MKxjngDv/19:25
ijohnsoncachio: 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 assertions19:25
cachioijohnson, sure19:25
ijohnsoncachio: so it seems it is randomly failing with uc20 then19:25
cachioijohnson, yes19:26
cachiothis is related to some errors we have seen with kvm and gce19:26
ijohnsoncachio: 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 PR19:26
cachioif you run without kvm then never reboots19:26
ijohnsoncachio: what do you think ?19:26
cachioijohnson, it is ok19:27
cachioit is working pretty well now19:27
cachiojust that problem but shouldn't affect the current nightly executions19:27
ijohnsoncachio: what do you mean about not rebooting without kvm ?19:27
ijohnsoncachio: you only see these random reboots with kvm enabled ?19:27
cachiowe use qemu with kvm aceleration19:28
ijohnsoni.e. -machine ubuntu-q35,accel=kvm ?19:28
cachioif I run without kvm acceleration those random reboots never happen19:28
cachioijohnson, right19:28
ijohnsonah very interesting19:28
cachiothe problem is that if we don't use kvm then the execution is very slow19:28
cachioand something interesting is that if we dont use ovmf the reboots don't happen19:29
ijohnsoncachio: where did you report this bug again? I remember reading through your LP bug you filed but I don't remember where now19:30
cachioso it is a combination between could + ovmf + kvm19:30
cachioijohnson, a time agou I created the bug in launchpad19:30
cachioin kvm project19:30
ijohnsondo you have the link ?19:30
cachioijohnson, let me check19:30
cachioijohnson, https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/187280319:33
mupBug #1872803: VM reboots using qemu and kvm with ovmf <qemu (Ubuntu):Expired> <https://launchpad.net/bugs/1872803>19:33
cachioijohnson, this issue should address that https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/188277419:34
mupBug #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
ijohnsonthanks cachio, very interesting19:36
mupBug #1874156 changed: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:Fix Released by morrisong> <https://launchpad.net/bugs/1874156>19:56
mupBug #1874156 opened: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:Fix Released by morrisong> <https://launchpad.net/bugs/1874156>20:05
mupBug #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
mupBug #1874156 changed: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:Fix Released by morrisong> <https://launchpad.net/bugs/1874156>20:08
ijohnsoncachio: 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
cachioijohnson, let me try with the qemu from proposed20:14
cachiothat could contains a fix20:15
mupPR 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
ddstreethi all, anyone know if snaps are building and/or providing dbgsyms yet? or is that still a future item?20:38
ijohnsonhi 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 snap20:46
ijohnsonddstreet: that will allow you to have dbgsysm exist on the host outside of the snap and debug the snap20:46
ijohnsonthere's a forum post about this here: https://forum.snapcraft.io/t/new-experimental-snap-run-experimental-gdbserver-option/1822720:47
ddstreetijohnson thanks! and are snaps now built with dbgsyms included?20:48
ijohnsonddstreet: that is up to each snap, most are not built with dbgsyms afaik20:48
ddstreethmm ok, so do you know if at least canonical-provided snaps include dbgsyms?  e.g. chromium?20:49
ddstreetor any documented way to tell if a snap includes dbgsym?20:49
mupPR snapd#8912 opened: tests: update unity app on nightly test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8912>20:49
ijohnsonddstreet: there is no documented way to tell if a snap includes dbgsym outside of just looking at it20:49
ijohnsonddstreet: why do you ask ?20:49
ddstreetmore 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 snaps20:51
ddstreetbut 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 future20:51
ijohnsonddstreet: 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 those20:52
ijohnsonddstreet: 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 snap20:53
ijohnsonddstreet: 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 time20:53
jdstrandroadmr: hey, in case you didn't see in the bug comment from 30 seconds ago, 20200623-2050UTC has the riscv64 update20:54
roadmrjdstrand: oh I didn't :)20:54
jdstrandroadmr: if you can pull whenever it makes sense for you, that would be great20:54
roadmrI'll queue it up!20:54
jdstrandthanks :)20:54
* roadmr checks time20:55
jdstrandxnox: fyi (and thanks again)20:55
roadmrjust enough time to land/QA today so maybe it can be deployed tomorrow20:55
jdstrandxnox: ^20:55
roadmrI'm off tomorrow but the awesome team might deploy20:55
mupPR 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!