[04:10] <arraybolt3> LocutusOfBorg: Focal verification done on VBox, should be ready to push to production February 2.
[06:22] <adrien> sergiodj: perfect, thanks a lot! :)
[07:06] <LocutusOfBorg> thanks!
[10:04] <slyon> @pilot in
[15:58] <slyon> @pilot out
[16:00] <lvoytek> @pilot in
[17:30] <tsimonq2> jjohansen: So, I've just spent the last two hours writing AppArmor profiles for various elements of my system. That's what I get for running Noble, but what could have possibly changed to cause this?
[17:30] <tsimonq2> jjohansen: Will happily file a bug and follow up there too, just wondering if you had an idea of what I'm talking about.
[17:33] <jjohansen> tsimonq2: I would assume user namespace mediation, and unconfined no longer allowing certain operations if the user is unprivileged
[17:33] <jjohansen> again mostly around user namespace mediation
[17:40] <tsimonq2> jjohansen: Got it. Do you happen to have documentation handy on how this is best handled from a user perspective?
[17:40] <tsimonq2> (Update a profile?)
[17:40] <jjohansen> tsimonq2: there are some changes coming that might be worth testing, https://launchpad.net/~apparmor-dev/+archive/ubuntu/unprivileged-userns
[17:41] <tsimonq2> oooh this seems promising
[17:42] <jjohansen> tsimonq2: we have some documentation around what is currently in noble, we need to update for what is in the ppa
[17:42] <jjohansen> tsimonq2: https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction
[17:43] <jjohansen> we are trying to get it updated this week
[17:43] <jjohansen> the ppa makes some significant changes
[17:44] <jjohansen> instead of unconfined denying unprivileged user namespace creation, it allows it and transitions the task to the unprivileged_userns profile
[17:44] <jjohansen> which have no capabilities within the user namespace
[17:45] <jjohansen> even if this causes failures, we have found most applications handle denials of capabilities better than denial of userns creation
[17:48] <jjohansen> tsimonq2: please do file a bug with what you have hit/done. The more feedback, bugs, etc we get back means we can get fixes in place
[18:09] <tsimonq2> jjohansen: Sorry, got pulled into a meeting. I'll be happy to, I really appreciate all the information here. :)
[20:53] <doko> how do I report a bug against a snap package, in Launchpad?
[20:59] <rbasak> Bugs in snaps aren't necessarily tracked in Launchpad
[20:59] <rbasak> snap info $package
[21:00] <rbasak> And then what it says under "contact" is the closest thing we have to being connected to the correct bug tracker AIUI
[21:15] <cpete> tsimonq2: I have a pending mp in lp:ubuntu-dev-tools, are you interested in taking a look? https://code.launchpad.net/~cpete/ubuntu-dev-tools/+git/ubuntu-dev-tools/+merge/459002
[22:01] <LocutusOfBorg> cpete, is the test a timing bomb?
[22:02] <LocutusOfBorg> like something that will fail once 20.04 is EOL?
[22:04] <cpete> LocutusOfBorg: I don't understand what you mean
[22:04] <LocutusOfBorg> ubuntutools/running_autopkgtests.py
[22:04] <LocutusOfBorg> what is it supposed to test?
[22:04] <LocutusOfBorg> I mean <rbasak> Bugs in snaps aren't necessarily tracked in Launchpad
 snap info $package
 And then what it says under "contact" is the closest thing we have to being connected to the correct bug tracker AIUI
[22:04] <LocutusOfBorg> * sil2100 has quit (Ping timeout: 268 seconds)
[22:04] <LocutusOfBorg> sorry
[22:07] <LocutusOfBorg> we can continue here
[22:08] <LocutusOfBorg> sorry rbasak for the ping, I copy-pasted wrongly
[22:08] <cpete> The tests are in ubuntutools/test/test_running_autokgtests.py. ubuntutools/running_autopkgtests is the module with the meat of the functionality
[22:12] <LocutusOfBorg> ok but what about not hardcoding a specific ubuntu version there?
[22:12] <LocutusOfBorg> are the tests using internet in some ways? or are they just using stub answers?
[22:13] <LocutusOfBorg> (sorry it's EOD here, I won't look deeply until tomorrow)
[22:13] <LocutusOfBorg> but maybe some test description won't hurt
[22:14] <vorlon> if the tests are hitting the production server: they shouldn't
[22:14] <vorlon> that's a recipe for flakiness
[22:14] <vorlon> autopkgtests should not depend on mutable resources on the Internet
[22:15] <cpete> The tests are using dummy data I hard coded into the tests for sure
[22:15] <cpete> I didn't see where there's a hard coded ubuntu version but I'll double check
[22:15] <cpete> thanks for looking LocutusOfBorg
[22:16] <LocutusOfBorg> cpete, +QUEUED_DATA = b'{"ubuntu": {"noble": {"arm64": ["libobject-accessor-perl {\\"requester\\": \\"someone\\", \\"submit-time\\": \\"2024-01-18 01:08:55\\", \\"triggers\\": [\\"perl/5.38.2-3\\", \\"liblocale-gettext-perl/1.07-6build1\\"]}"]}}}'
[22:16] <LocutusOfBorg> I'm seeing this
[22:17] <LocutusOfBorg> that said, if this is about providing fake data, and checking if we can parse it, fine for me
[22:17] <LocutusOfBorg> but if the infrastructure changes, we won't detect anything.
[22:17] <LocutusOfBorg> sadly, as vorlon said, autopkgtests should not depend on mutable resources on the internet
[22:18] <LocutusOfBorg> but if autopkgtest is meant to check a functionality of downloading stuff from internet, not testing it is meh
[22:18] <cpete> Oh yeah, thanks. I'll add some comments to clarify but yes this is about testing behavior on a dummy response from the autopkgtest server
[22:19] <LocutusOfBorg> but cpete please tell me if I'm wrong: if somebody changes totally the output json formatting of autopkgtests, will the test detect it? will the running-autopkgtests fail?
[22:19] <LocutusOfBorg> My answers are no, yes
[22:19] <LocutusOfBorg> :D
[22:21] <cpete> Right,  tests won't detect it and the script will fail
[22:24] <cpete> Would a test validating the json format from the autopkgtest server be reasonable test to run in autopkgtest?
[22:25] <LocutusOfBorg> vorlon, ^^
[22:25] <LocutusOfBorg> not sure sorry