[06:46] <mborzecki> morning
[06:55] <zyga> good morning
[06:55] <zyga> mborzecki: how was your weekend?
[06:55] <mborzecki> zyga: indoors mostly ;)
[06:56] <mborzecki> zyga: is it equally cold in waw?
[06:56] <zyga> me too, what a coincidence :)
[06:57] <zyga> I see we had a 2.44.1
[06:58] <zyga> anything special on Friday?
[07:00] <mborzecki> zyga: idk, spent almost whole friday fighting console conf
[07:51] <zyga> re
[08:03] <pstolowski> mornings
[08:04] <mvo> good morning zyga and pstolowski
[08:06] <zyga> hey pawel, hey mvo
[08:06] <zyga> I'm not sure how it's around where you live
[08:07] <mborzecki> pstolowski: mvo: morning guys
[08:07] <zyga> but when I walked outside earlier today
[08:07] <zyga> it was so so incredibly quiet
[08:07] <zyga> I heard birds chirping and not much else
[08:08] <zyga> I saw maybe four cars on a wide artery that is normally stuck in traffic at this time
[08:08] <zyga> it's so surreal
[08:16] <zyga> travis very non responsive today
[08:16] <zyga> at least for me
[08:17] <mvo> zyga: yeah, travis had half-a-day of database upgrade at saturday
[08:17] <zyga> uh
[08:17] <mvo> zyga: and I no longer have the "rebuild" button
[08:17] <zyga> what could possibly go wrong now
[08:18] <zyga> I'm trying to open or restart runs
[08:18] <mvo> zyga: can you still restart runs?
[08:20] <zyga> no, I cannot get the pages to load
[08:20] <zyga> travis times out, gh is responding fast
[08:30] <mup> PR snapd#8315 opened: tests: ensure session agent service is ready in prepare <Created by mvo5> <https://github.com/snapcore/snapd/pull/8315>
[08:34] <mup> PR snapd#8316 opened: github: add prototype workflow running unit tests <Created by zyga> <https://github.com/snapcore/snapd/pull/8316>
[08:42] <pedronis> jamesh: hi, we sometimes see failures of snap-session-agent-service-control , https://api.travis-ci.org/v3/job/665599033/log.txt
[08:43] <jamesh> looking
[08:46] <pedronis> jamesh: seems mvo was also looking in that: https://github.com/snapcore/snapd/pull/8315
[08:46] <mup> PR #8315: tests: ensure session agent service is ready in prepare <Created by mvo5> <https://github.com/snapcore/snapd/pull/8315>
[08:48] <mvo> jamesh: yeah, if you could review that PR 8315 that would be great
[08:48] <mup> PR #8315: tests: ensure session agent service is ready in prepare <Created by mvo5> <https://github.com/snapcore/snapd/pull/8315>
[08:49] <mvo> jamesh: it might be too simplistic
[08:50] <jamesh> mvo: is there a systemctl invocation to wait for a unit to be started?
[08:51] <jamesh> e.g. I wonder if we could do "systemctl --user start sockets.target"?
[08:51] <mvo> jamesh: maybe, this is also about socket activation so start might test less than what we tested before?
[08:53] <jamesh> mvo: the tests expect that sockets.target has completed: i.e. systemd has created the unix domain socket and is prepared to start the session agent when someone connects to it
[08:53] <zyga> hey pedronis, good morning
[08:53] <zyga> pedronis: do you remember that A=$B; B=$C; C=foo; problem my earlier implementation of environment untangled?
[08:53] <jamesh> I don't think this would meaningfully change what is being tested, and might get rid of the race
[08:54] <pedronis> zyga: yes
[08:54] <pedronis> is somebody trying to do that?
[08:54] <zyga> pedronis: it seems snapcraft has a bug where it would be useful, it reorders environment entires, it sorts them :|
[08:54] <zyga> pedronis: I filed a bug for snapcraft
[08:54] <pedronis> it's definityl a snapcraft bug
[08:54] <zyga> yeah
[08:55] <zyga> just found this ironic
[08:55] <mvo> jamesh: ok, feel free to push something else to the PR or a new one, happy with a better fix :)
[09:05] <jamesh> mvo: I don't think I can edit other peoples' PRs, so I'll create a new one
[09:06] <mvo> jamesh: thank you
[09:19] <mup> PR core20#28 opened: Add iptables package <Created by alfonsosanchezbeato> <https://github.com/snapcore/core20/pull/28>
[09:26] <mup> PR snapd#8317 opened: many: make sure ephemeral failover snapd does not open sockets <Created by pedronis> <https://github.com/snapcore/snapd/pull/8317>
[09:37] <zyga> please review https://github.com/snapcore/snapd/pull/8316
[09:37] <mup> PR #8316: github: add prototype workflow running unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8316>
[09:39] <zyga> last run was one minute and 55 seconds
[09:39] <zyga> for "go test" results
[09:45] <mup> PR snapd#8298 closed: many: enumerate system seeds, return them on the /v2/systems API endpoint <UC20> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8298>
[09:46] <zyga> brb
[09:47] <mup> PR snapd#8318 opened: tests: ensure sockets target is ready in session agent spread tests <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8318>
[09:51] <mup> PR snapd#8318 closed: tests: ensure sockets target is ready in session agent spread tests <Created by jhenstridge> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8318>
[10:12] <pedronis> mvo: I think you closed the wrong PR ^  8318 sees it was closed in favor of 8318
[10:12] <pedronis> s/sees/says/
[10:14] <mvo> pedronis: oh, sorry, /me is a muppet
[10:15] <mup> PR snapd#8318 opened: tests: ensure sockets target is ready in session agent spread tests <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8318>
[10:16] <mup> PR snapd#8315 closed: tests: ensure session agent service is ready in prepare <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8315>
[10:18] <pstolowski> pedronis: hi, i pushed some changes to search v2 wrt error-list. it turned out to be slightly annoying and the change may look a bit confusing, happy to discuss
[10:18] <pedronis> pstolowski: thx, in a meeting atm
[10:27] <mup> PR snapd#8319 opened: github: run unit tests and spread via github actions <Created by zyga> <https://github.com/snapcore/snapd/pull/8319>
[10:28] <zyga> wow, github actions runner is FOSS
[10:28] <zyga> https://github.com/actions/runner
[10:28] <zyga> and can run on hosted machines
[10:30] <zyga> this is neat https://github.com/actions/labeler
[10:30] <zyga> action to put labels based on what's changed in the tree
[10:39] <ackk> zyga, hi, any chance https://github.com/snapcore/snapd/pull/8265 can be merged? I'd be happy to test a snapd snap with that fix
[10:39] <mup> PR #8265: tests: add regression test for MAAS refresh bug <Created by zyga> <https://github.com/snapcore/snapd/pull/8265>
[10:39] <zyga> ackk: this is just a regression test, there's no fix there
[10:39] <zyga> the fix has been merged and is behind a feature flag, long ago
[10:39] <ackk> zyga, the https://trello.com/c/QjX63wGx/201-4-document-snap-downgrade ?
[10:40] <ackk> zyga, I'm still seeing that issue with it enabled
[10:40] <ackk> zyga, it happens all the time for me
[10:40] <ackk> install/refresh/remove
[10:40] <zyga> I cannot see that
[10:40] <ackk> actually,even when I connect interfaces
[10:40] <zyga> let me log in
[10:40] <ackk> zyga, sorry, wrong link
[10:41] <alvesadrian> good morning
[10:41] <alvesadrian> zyga
[10:41] <ackk> zyga,  I meant if it's robust-mount-namespace-updates
[10:41] <alvesadrian> there is way to sort this with jetty
[10:41] <ackk> copy/paste is a  bit messed up in focal
[10:41] <zyga> ackk: I'm sorry, is this different from any of the earlier fixes we did recently?
[10:41] <alvesadrian> zyga https://pastebin.com/W9iT0sF3
[10:42] <ackk> zyga, wdym?
[10:42] <zyga> ackk: I'm confused
[10:42] <zyga> ackk: can you tell me if the thing that is failing is one of the things we inspected last week
[10:42] <alvesadrian> Starting Jetty: chown: changing ownership of '/tmp/oxauth.pid': Operation not permitted
[10:42] <alvesadrian> su: must be run from a terminal
[10:42] <zyga> alvesadrian: I'm sorry, I cannot debug things for you
[10:42] <ackk> zyga, https://paste.ubuntu.com/p/mjV2zR4Pcn/ is an example of failure
[10:43] <alvesadrian> zyga is not a debug
[10:43] <alvesadrian> am not asking for that
[10:43] <zyga> ackk: does this represent one of the failures we've inspected before or is a new failure?
[10:43] <alvesadrian> is how or why snap is failing to run a jetty app using jetty and the app in the same yaml
[10:44] <ackk> zyga, I'm not sure. one question I have is, does snap-discard-ns clean up everything? I wonder if running that might cause issues with later operations
[10:44] <alvesadrian> zyga where i can find snapcraft.yaml
[10:44] <zyga> ackk: yes it does
[10:44] <alvesadrian> zyga for java server apps
[10:44] <zyga> ackk: it should be invoked when there are no processes around, otherwise you fracture the view, some inhabit old world, some new
[10:44] <zyga> alvesadrian: I don't know, did you try checking on the forum?
[10:44] <alvesadrian> yes
[10:44] <zyga> alvesadrian: since you mentioned chown, snaps should not change ownership of files
[10:44] <alvesadrian> if course i already open a ticket
[10:45] <zyga> ticket?
[10:45] <alvesadrian> sorry a post
[10:46] <ackk> zyga, so, just rebooted the container, I get this: https://paste.ubuntu.com/p/NVQ34Jvwxw/
[10:46] <zyga> ackk: I'm not entirely sure what rebooting a container does
[10:47] <zyga> does it really discard mount namespaces?
[10:47] <alvesadrian> zyga https://forum.snapcraft.io/t/issues-with-different-users-chown-and-su/16129
[10:47] <ackk> zyga, well, it should? I mean it's like a a machine reboot
[10:47] <zyga> I don't know
[10:47] <zyga> that's a lxd question
[10:47] <zyga> alvesadrian: please familiarize yourself with https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461
[10:47] <alvesadrian> i already read that
[10:48] <ackk> zyga, what should I check to see if the correct namespaces are set up?
[10:48] <alvesadrian> i cannot find a snapcraft.yaml file as example of people bullding a java app with the tocamcat or jetty on it
[10:48] <zyga> great, then you should understand that you cannot chown anything to 1000 or most other values
[10:48] <zyga> I cannot help you beyond that, I don't even know what jetty is
[10:48] <alvesadrian> that will be great for me but i cannot find it like nobody did an snap of hat
[10:49] <alvesadrian> jetty==tomcat
[10:49] <zyga> ackk: it's hard because of startup services,
[10:49] <zyga> ackk: can we spin it another way? can you report a bug with reproducer?
[10:49] <zyga> ackk: I cannot promise I will look instantly
[10:49] <zyga> as we have some other fires
[10:49] <zyga> but I will do my best
[10:49] <ackk> zyga, sure I'll try
[10:50] <alvesadrian> couldnt find any example of snaocraft.yal for a java app containing a tomcat on it
[10:50] <alvesadrian> or a java server app to serve the app
[10:50] <zyga> I don't know anything about tomcat but I googled some results
[10:51] <zyga> did you go over the first few hits?
[10:51] <alvesadrian> nothing man
[10:51] <alvesadrian> being the whole weekend digging
[10:51] <alvesadrian> its like nobody build it a snappy for tomcat app or java server app
[10:52] <alvesadrian> forget about tomcat, just mean a java server app
[10:52] <alvesadrian> nobody builds java server apps on snaps
[10:53] <zyga> alvesadrian: did you check out https://snapcraft.io/docs/java-applications ?
[10:53] <alvesadrian> course
[10:53] <zyga> can you post some feedback about that to the forum
[10:53] <zyga> I'm sorry, I"m not the spokesperson for snapd :)
[10:53] <zyga> I cannot help everyone
[10:53] <alvesadrian> didnt mention anything about using an external java serer as source
[10:53] <alvesadrian> i know
[10:54] <alvesadrian> just wondering if u know something about it
[10:54] <zyga> I don't know what an external java server is (is that tomcat?)
[10:54] <alvesadrian> thans
[10:54] <alvesadrian> external means dont using the plug of jdk
[10:54] <alvesadrian> thata what i mean getting from source
[10:54] <alvesadrian> download it and running
[10:54] <alvesadrian> thats what i mean
[10:55] <zyga> what does "the plug of jdk" mean?
[10:55] <alvesadrian> like a snap that fetch tomcat(java server) and run the app inside
[10:55] <zyga> why fetcH?
[10:55] <zyga> why not bundle tomcat at build time?
[10:55] <alvesadrian> the pluging for the jdk framework
[10:56] <alvesadrian> what u mean?
[10:56] <alvesadrian> an example?
[10:56] <zyga> maybe I misunderstand but from what you are saying the snap package would, after being installed, download tomcat and do something with it
[10:56] <alvesadrian> nope
[10:57] <alvesadrian> snap has a part tomcat and anotehr part for the java app
[10:57] <zyga> I see
[10:57] <zyga> and what is the problem there?
[10:57] <zyga> downloading tomcat?
[10:57] <ackk> zyga, fwiw https://paste.ubuntu.com/p/wQpmk2mkcS/ reproduces it for me. I'm not sure whether to file a new bug or it's just a manifestation of the previous one?
[10:57] <alvesadrian> i cant find an example about how to
[10:57] <zyga> alvesadrian: is tomcat special? is downloading it different from downloading other files?
[10:57] <alvesadrian> place it and run it with the java app
[10:57] <alvesadrian> nope
[10:58] <alvesadrian> just a source zip file
[10:58] <alvesadrian> static
[10:58] <zyga> alvesadrian: did you check the snapcraft documentation for parts?
[10:58] <alvesadrian> it will run a daemon
[10:58] <zyga> there's a way to download things there
[10:58] <zyga> source: URL
[10:58] <alvesadrian> yes
[10:58] <zyga> it can fetch tomcat, or whatever
[10:58] <zyga> so?
[10:58] <zyga> ackk: at this rate, I'd say please file one
[10:58] <zyga> even if it's a dupe
[10:58] <ackk> zyga, ok
[10:58] <zyga> it's easier for me to keep a TODO list this way
[10:59] <zyga> ackk: I'm sorry for the issues, it's likely that maas has found more bugs than an average snap by now :)
[10:59] <ackk> zyga, we like to live on the bleeding edge :)
[10:59] <zyga> alvesadrian: so can you download tomcat using snapcraft part or not?
[10:59] <alvesadrian> yes
[10:59] <alvesadrian> as a part
[10:59] <zyga> ok, so what's the problem again?
[11:00] <alvesadrian> not tomcat specially jetty but they are similar
[11:00] <alvesadrian> after download
[11:00] <alvesadrian> move the java app into the webapp folder
[11:00] <alvesadrian> but not cluu how to run it
[11:00] <zyga> with a service declaration
[11:01] <ackk> alvesadrian, add an app: with daemon:simple and command pointing to a script which runs tomcat?
[11:01] <zyga> (remember to exec in the last line of the script)
[11:01] <alvesadrian> where i can get a snapcraft.yaml with an example
[11:01] <alvesadrian> about how to do it?
[11:02] <zyga> I really think you should slow down and look at snapcraft docs
[11:02] <ackk> zyga, oh, so maybe I'm still hitting https://bugs.launchpad.net/snapd/+bug/1867752 actually
[11:02] <mup> Bug #1867752: Unable to remove snap with content interface (with robust namespace update) <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1867752>
[11:02] <zyga> https://snapcraft.io/docs/services-and-daemons
[11:02] <ackk> zyga, is this available in a snapd snap?
[11:02] <alvesadrian> so i need to create a service declaration to run the script that start tomcat?
[11:02] <ackk> alvesadrian, yes
[11:02] <zyga> alvesadrian: ^ please check that page
[11:03] <alvesadrian> zyga thanks thats enough
[11:03] <zyga> ackk: this should be in edge
[11:03] <ackk> zyga, ok, I'll test with that, see if it solves the issue. thanks
[11:03] <alvesadrian> ackk also thanks
[11:03] <zyga> thanks!
[11:06] <ackk> zyga, that seems to work, thanks!
[11:10] <alvesadrian> zyga final question
[11:11] <alvesadrian> SNAP_DATA SNAP_USER_DATA SNAP_COMMON
[11:11] <alvesadrian> those contaiing dirs writeables
[11:11] <alvesadrian> can be chown?
[11:11] <alvesadrian> teh files inside fo those?
[11:12] <alvesadrian> ackk also if you know this ^^^
[11:12] <ackk> alvesadrian, yes those are writable. why do you need chown?
[11:14] <alvesadrian> java developers are asking me
[11:14] <alvesadrian> why we cannot chown to jetty or tomcat user
[11:14] <alvesadrian> why it needs to run as root
[11:14] <ogra> where would that user live
[11:14] <ackk> alvesadrian, services run as "root" in the container
[11:14] <ackk> alvesadrian, that's a confined root user though, so it's safe
[11:14] <alvesadrian> no clue why they complaing about that
[11:15] <ogra> iirc fchown and chown syscalls are blocked by seccomp by default
[11:15] <ogra> you can make them a no-op by using snapcraft-preload if you can not change the code
[11:17] <ogra> if your developers heavily insist to drop to a user (which is pretty much nonsense inside confinement, but some apps can not be changed) you can use https://forum.snapcraft.io/t/system-usernames/13386
[11:17] <ogra> ... but need to change your app to use this username ...
[11:18] <alvesadrian> ogra the problem is they want to run jetty services
[11:18] <alvesadrian> with user jetty
[11:18] <ogra> well, and they can not run it as root ?
[11:19] <ogra> it is inside confinement ... switching to that user brings no benefit
[11:19] <alvesadrian> ogra here is teh case
[11:19] <alvesadrian> https://pastebin.com/Uwe6vF8r
[11:19] <alvesadrian> ogra https://pastebin.com/Uwe6vF8r
[11:19] <ogra> but they *can* switch to an unprivileged user if needed ... as described in the doc i just gave you above
[11:20] <ogra> so make them use that and configure it in the snapcraft.yaml
[11:20] <ogra> or convince them to run it as root
[11:21] <ackk> it should be possible to run jetty as root
[11:21] <ackk> there are few apps that really can't be convinced to run as root (postgres being one of them)
[11:21] <ogra> right
[11:21] <alvesadrian> ackk https://pastebin.com/Uwe6vF8r
[11:22] <alvesadrian> thats an exxample of whats going on
[11:22] <ackk> that's a flask app though? I don't see how is it relevant
[11:24] <alvesadrian> su - jetty
[11:24] <alvesadrian> I also set JETTY_USER=jetty for command
[11:24] <ogra> well, su or sudo inside snaps dont work anyway
[11:24] <alvesadrian> Jython 2.7.2rc1 (v2.7.2rc1:1fcef1abf1d6, Mar 1 2020, 16:27:06)
[11:24] <alvesadrian> [OpenJDK 64-Bit Server VM (Amazon.com Inc.)] on java1.8.0_222
[11:24] <alvesadrian> Type "help", "copyright", "credits" or "license" for more information.
[11:24] <alvesadrian> >>>
[11:24] <alvesadrian> >>> f=open("/tmp/text.txt",'w')
[11:24] <alvesadrian> >>> f.write("test")
[11:24] <alvesadrian> >>> f.close()
[11:24] <alvesadrian> >>> import os
[11:24] <alvesadrian> >>> os.getuid()
[11:24] <alvesadrian> 1000
[11:24] <alvesadrian> >>> os.system('chown 1000 /tmp/text.txt')
[11:24] <alvesadrian> chown: changing ownership of '/tmp/text.txt': Operation not permitted
[11:24] <alvesadrian> 1
[11:24] <alvesadrian> Even see this:
[11:24] <alvesadrian> >>> os.stat("/tmp/text.txt").st_uid
[11:24] <ogra> and chown is blocked by seccomp
[11:24] <alvesadrian> 1000
[11:25] <alvesadrian> so we need to fix rthat app code?
[11:25] <ogra> run jetty as root, run the commands as root ...
[11:25] <pedronis> or use snap_daemon if possible
[11:25] <ogra> the snap confinement is designed to be root safe
[11:26] <ackk> alvesadrian, is that chown a test or actual code you have ?
[11:26] <ogra> right, if you really cant use root, use snap_daemon ...
[11:27] <alvesadrian> code
[11:27] <ogra> the point is, there is no jetty user on systems you install your snap on ... and nothing in snaps that allows to create such a user
[11:27] <alvesadrian> thats real code
[11:28] <ackk> alvesadrian, maybe unrelated but, you shouldn't really need to chown the file to the same user that created it?
[11:28] <alvesadrian> am not the developer
[11:28] <alvesadrian> just packaging
[11:28] <ogra> use snapcraft-preload to make chown a no-op then
[11:29] <ogra> https://github.com/sergiusens/snapcraft-preload
[11:31] <ackk> alvesadrian, fwiw if the service is running as root in the snap, that chown will succeed (assuming you replace 1000 with os.getuid()): https://paste.ubuntu.com/p/v88DXT45bh/
[11:32] <ackk> 1000 won't as you can only chown to the same user
[11:32] <ackk> (and root doesn't have CAP_DAC_OVERRIDE in the snap)
[12:12] <mup> PR snapd#8320 opened: Updates to login-session-observe and network-manager interfaces <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/8320>
[12:37] <pedronis> pstolowski: commented, let me know
[12:38] <mup> PR snapd#8312 closed: many: fix packages having mistakenly their copyright as doc <Simple 😃> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8312>
[12:38] <pedronis> pstolowski: also ping me when is ready for re-review, I saw there bits still not addressed. thanks
[12:56] <pedronis> pstolowski: I did a pass on #8309
[12:56] <pedronis> thanks for it
[12:56] <mup> PR #8309: o/configcore: implement Apply method for early configuration of core <Created by stolowski> <https://github.com/snapcore/snapd/pull/8309>
[12:59] <pstolowski> pedronis: thanks! i just replied to one of your search v2 comments
[13:02] <pedronis> pstolowski: answered
[13:03] <pedronis> pstolowski: I'm sure we can do something but yes touching the global helper is delicate so we can postone
[13:04] <pstolowski> pedronis: thanks. yes it's all messy and super confusing already. nb, error-list vs error_list in struct storeErrors, but that's probably historical?
[13:05] <pedronis> pstolowski: yes, that's used in the bit that we should drop when we can
[13:09] <mborzecki> pedronis: do you think we could stay after the standup and discuss integration of snap-recovery-chooser with console-conf?
[13:09] <pedronis> mborzecki: yes, if the standup doesn't take too long
[13:10] <mborzecki> ack
[13:18] <ijohnson> morning folks
[13:19] <cmatsuoka> hey ijohnson
[13:20] <ijohnson> hey cmatsuoka how was your weekend ?
[13:20] <cmatsuoka> confined, and yours?
[13:21] <ijohnson> haha yep same, but we did a lot of cleaning so that's nice
[13:33] <cwayne> cmatsuoka: thats a whole new level of eating your own dogfood man
[13:34] <cmatsuoka> cwayne: haha indeed
[13:55] <pedronis> ijohnson: I answerd to you comments in 8314, we cannot write a snap-failure that assumes only new snapds
[15:10] <ogra> jdstrand, if i added "/dev/usb/lp[0-9]* rwk," to the raw-usb interface to allow a customer to use a receipt printer (writing  to the device directly, no cups or so) ... would you object that ? (raw-usb seems like the correct place, if thats wrong we'll likely need a "raw-usbprinter" interface or so)
[15:12] <jdstrand> ogra: sure, for the same reason as we allow "# Allow access to all ttyUSB devices too"
[15:12] <ogra> yeahm that was my rationale to pick that place :) create
[15:12] <ogra> s/create/great/
[15:13]  * ogra glares at his fingers
[15:34] <ijohnson> mvo: #8287 is the PR for 2.44 of my initial snap-failure changes that pedronis's changes are based on top of FYI
[15:34] <mup> PR #8287: tests, many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests (2.44) <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8287>
[15:41] <mvo> ijohnson: thanks, checking it now
[15:43] <cachio> mvo, hey
[15:43] <cachio> I am creating the cloud config in this place currently system-data/var/lib/cloud/seed/nocloud-net/
[15:43] <cachio> for uc20
[15:44] <cachio> mvo, this right? ubuntu-seed/data/etc/cloud/cloud.cfg.
[15:44] <cachio> d
[15:44] <pedronis> cachio: it depends what kind of data are you creating
[15:45] <pedronis> is it user-data?
[15:45] <cachio> user-data and meta-data
[15:45] <pedronis> yea, your place is correct
[15:45] <pedronis> and we need more code
[15:45] <pedronis> (I mean correct about to /data)
[15:45] <pedronis> mvo: ^
[15:46] <pedronis> what we discussed last week actually
[15:47] <cachio> pedronis, i tried to merge #8299 but still out of sync
[15:47] <mup> PR #8299: devicestate,sysconfig: support "cloud.cfg.d" in uc20 for grade: dangerous <Squash-merge> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8299>
[15:47] <cachio> I did re-login
[15:47] <cachio> but didnt work
[15:47] <cachio> on github and travis as well
[15:47] <cachio> pedronis, any other idea?
[15:48] <mvo> pedronis, cachio indeed, the current PR only supports cloud.cfg.d - I can extend the code for user-data and meta-dat
[15:49]  * mvo added a todo for himsef
[15:49] <pedronis> mvo: we need to extend for seed/* at least for dangerous, for non-dangerous we need to be a bit more careful
[15:49] <cachio> mvo, if it is in a following pr should be nice
[15:52] <ngaio> Hello everyone, where do the MOTU team chat? IRC? The MOTU information on the Ubuntu wiki is many years out of date (seriously!)
[15:52] <mvo> pedronis: yeah
[15:52] <mvo> cachio: yeah, put on my todo
[15:52] <cachio> thanks
[15:53] <ngaio> I'm asking because I have a request about a specific package in Universe that is packaged in Debian
[15:53] <ngaio> (not because I'm looking to update the Ubuntu Wiki ;-) )
[15:54] <mup> PR snapd#8314 closed: cmd/snap-failure,tests: try to make snap-failure more robust <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8314>
[15:56] <mup> PR snapd#8287 closed: tests, many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests (2.44) <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8287>
[15:57] <zyga> hmm
[15:57] <zyga> test failure in 2.44.1+ git build
[15:57] <zyga> ... error string = "Get http://42/v1/session-info: context deadline exceeded"
[15:57] <zyga> ... regex string = "Get \\\"?http://1000/v1/session-info\\\"?: context deadline exceeded"
[15:57] <zyga> mvo: ^ perhaps this is what was blocking edge builds?
[15:57] <zyga> FAIL: client_test.go:101: clientSuite.TestAgentTimeout
[15:58] <zyga> there's also a c.Check(err, IsNil) that should be c.Assert
[15:58] <zyga> and a panic after that
[15:58] <zyga> PANIC: client_test.go:287: clientSuite.TestSnapdClientIntegration
[15:58] <zyga> I can send a patch that quickly
[15:59] <mup> PR snapd#8321 opened:  cmd/snap-failure,tests: try to make snap-failure more robust (2.44) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8321>
[16:01] <mup> PR snapd#8322 opened: client: use Assert when checking for error <Simple 😃> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8322>
[16:01] <zyga> https://github.com/snapcore/snapd/pull/8322
[16:01] <mup> PR #8322: client: use Assert when checking for error <Simple 😃> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8322>
[16:11] <ackk> zyga, is it possible to make "snap run --strace" work in a container?
[16:11] <ackk> it doesn't seem it is by default
[16:11] <zyga> ackk: IIRC no without lxd changes
[16:12] <ackk> zyga, ok, thanks
[16:19] <mup> PR snapd#8299 closed: devicestate,sysconfig: support "cloud.cfg.d" in uc20 for grade: dangerous <Squash-merge> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8299>
[16:40] <mup> PR snapd#8323 opened: many: improve comments, naming, a possible TODO <Created by pedronis> <https://github.com/snapcore/snapd/pull/8323>
[16:41] <pedronis> ijohnson: ^ tries to apply your feedback and turns a point of it into a TODO
[16:42] <ijohnson> thanks pedronis just approved it
[16:47] <ijohnson> hmm pedronis (hopefully quick) question about refactoring the logic from snap-bootstrap to boot pkg, should snap-bootstrap/cmd_initramfs_mounts.go pass in the bootloader and modeenv to a function in boot, or should the function in boot get that stuff itself ?
[16:50] <pedronis> ijohnson: this is for run mode right?
[16:52] <ijohnson> pedronis: yes
[16:52] <ijohnson> the logic to pick the base snap and kernel snap to mount and also for the base to update the modeenv
[16:53] <pstolowski> pedronis: can you clarify on #8309 (just replied)?
[16:53] <mup> PR #8309: o/configcore: implement Apply method for early configuration of core <Created by stolowski> <https://github.com/snapcore/snapd/pull/8309>
[16:53] <ijohnson> I'll save the bikeshedding about function names for the PR itself, but while coding it just occurred to me  maybe it would be easier/make more sense if the book package picked that stuff up itself instead of getting that state passed to it from snap-boostap's code
[16:54] <pedronis> ijohnson: yes, I don't think that passing in the bootloader is useful,  it's more like MakeBootable really
[16:54] <pedronis> ijohnson: but what's the input and the output?
[16:55] <pedronis> ijohnson: if we look at how install works,  the input would be []snap.Type and the output paths?
[16:55] <ijohnson> well the input for now was just which snap (base or kernel) and the bootloader and the modeenv, the output is what snap to mount as a string and an error
[16:56] <ijohnson> oh hmm
[16:56] <pedronis> I mean, there's more to the input than []snap.Type,  definitely the bootloader is not needed
[16:56] <ijohnson> right sure ignore that
[16:56] <ijohnson> then I have this (ignore the name)
[16:57] <ijohnson> `func InitramfsSnapToMount(snapT snap.Type) (snapFilename string, err error) {`
[16:58] <pedronis> that seems ok fine, it might or might not need to take the model? maybe not? there' the wrinkle that we need to mutate modeenv
[16:58] <pedronis> sometimes
[16:59] <ijohnson> right so the other thing I was doing here just for simplicity is that this function would mutate the modeenv and write that out, so in generateMountsModeRun, we wouldn't have that step "4.1 Write the modeenv out again"
[16:59] <ijohnson> but I suppose I could return the modeenv and keep that step 4.1
[16:59] <ijohnson> also where would we get the model from during snap-bootstrap ?
[17:00]  * ijohnson looks
[17:02] <pedronis> pstolowski: answered
[17:02] <pstolowski> ty
[17:03] <pedronis> ijohnson: do we need the model?
[17:03] <ijohnson> pedronis: not right now AFAICT ?
[17:03] <pedronis> ok, so ignore me
[17:03] <pedronis> pstolowski: let me know if my comment is still confusing
[17:03] <ijohnson> okay, but do you have thoughts on step 4.1 in snap-bootstrap ?
[17:04] <ijohnson> pedronis: i.e. should we still write the modeenv at the very end, or could we write it sooner?
[17:04] <pedronis> ijohnson: I think we could write it sooner afaiu,  the issue then is more that function name doesn't scream I'm mutating stuff
[17:05] <ijohnson> yeah let's figure out a good name in the PR review :-)
[17:05] <ijohnson> I should have it open this afternoon, need to break now for lunch though
[17:05] <pedronis> ijohnson: I might not get to look at it today though, trying to have a short day for a change :)
[17:05] <ijohnson> pedronis: that's perfectly fine I understand :-)
[17:10] <pstolowski> pedronis: looks good,ty
[17:12] <mup> PR snapd#8324 opened: github: cache go build cache and pkg dirs <Created by zyga> <https://github.com/snapcore/snapd/pull/8324>
[17:20] <pedronis> pstolowski: I made a list of the follow ups if I see things correctly
[17:23] <pstolowski> pedronis: great, thanks. none of that is sophisticated, mostly a matter of diff size for the review / avoiding loosely related changes in this PR
[17:24] <pedronis> pstolowski: yea, no proble, small PRs that can go in quickly are good
[17:27] <pstolowski> eod, o/
[17:33]  * zyga eds
[17:41] <pedronis> mvo: this didn't even trigger travis in any way: https://github.com/snapcore/snapd/pull/8321 seems something really confused there
[17:41] <mup> PR #8321:  cmd/snap-failure,tests: try to make snap-failure more robust (2.44) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8321>
[18:18] <mvo> if someone could eyeball/approve 8321 that would be nice, maybe the approval is what's missing from triggering a travis run?
[18:29] <ijohnson|lunch> mvo I approved it
[18:29] <ijohnson|lunch> still no travis though :-/
[18:33] <mvo> ijohnson|lunch: meh, silly travis
[18:33] <ijohnson|lunch> mvo: what I've done before is to close and re-open the PR
[18:34] <mvo> ijohnson|lunch: thanks, let me try this
[18:34] <mvo> that helped
[18:34] <mvo> thanks pedronis
[18:34] <pedronis> I tried it, but didn't help
[18:34] <pedronis> afaict
[18:34] <pedronis> actually it did
[18:35] <pedronis> it took a little bit
[18:35] <ijohnson|lunch> I reapproved anyways just to make sure it didn't be weird
[18:41] <pedronis> so travis and github got desynced again
[18:42] <pedronis> for me
[18:43] <pedronis> :/
[18:54] <cachio> mvo, I am creating cloug condiguration like this https://paste.ubuntu.com/p/Mz3PHrtZJ6/
[18:54] <cachio> is it ok?
[18:55] <zyga> Travis has a very bad day
[18:55] <cachio> mvo, then I copy that file to /ubuntu-seed/data/etc/cloud/cloud.cfg.d/
[18:55] <cachio> on the image
[19:07] <sergiusens> zyga: Travis had a very bad weekend!
[19:11] <mvo> cachio: yeah, that should work
[19:11] <mvo> cachio: good luck, keep me updated
[19:12] <cachio> mvo, and which is hte path in uc18 and uc16?
[19:12] <cachio> the same should work as well?
[19:12] <mup> PR snapd#8316 closed: github: add prototype workflow running unit tests <Skip spread> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8316>
[19:13] <mup> PR snapd#8316 opened: github: add prototype workflow running unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8316>
[19:17] <pedronis> cachio: mvo: in the image you don't want the ubuntu-seed bit (that's the partition mount point)
[19:18] <cachio> pedronis, currently I mount the partition and then copy to /ubuntu-seed/data/etc/cloud/cloud.cfg.d/
[19:18] <cachio> in uc20
[19:19] <cachio> there are 2 partitions and the second one contains /ubuntu-seed
[19:20] <cachio> pedronis, is that ok?
[19:26] <ijohnson|lunch> cachio: yes the put the data/etc/... files in the ubuntu-seed partition
[19:27] <cachio> ijohnson, thanks
[19:27] <ijohnson> cachio: if you are mounting ubuntu-seed at /ubuntu-seed then that directoriy you have is correct
[19:28] <cachio> ijohnson, ye
[19:28] <cachio> s
[19:28] <cachio> I am running now, reults will be ready in few minutes
[19:47] <ijohnson> great cachio
[20:24] <mup> PR snapd#8325 opened: snap-bootstrap: copy auth data from real ubuntu-data in recovery mode <Created by mvo5> <https://github.com/snapcore/snapd/pull/8325>
[20:38] <mup> Bug #1868620 opened: Snaps based on Wine fail with nvidia driver 440  <Snappy:New> <https://launchpad.net/bugs/1868620>
[20:41] <cmatsuoka> zyga: do you have plans to work on LP:1868450? should I assign it back to you?
[20:57] <cmatsuoka> ijohnson: do you know who worked with timers more recently?
[21:20] <ijohnson> cmatsuoka: I think mborzecki or pstolowski
[21:21] <cmatsuoka> ijohnson: thanks, I'll check with them
[21:40] <pedronis> cachio: hi, the issues here seems real, one missing/changed package?, issue with the urls we get from the store, the store is changing how they handle downloads so something might have changed there, please talk to them: https://api.travis-ci.org/v3/job/665954535/log.txt