[08:18] <adrien> \o
[08:32] <adrien> is there a way to get a serialized output from apparmor profiles? I'd like to see which paths are covered (I don't need exact data, only approximate)
[08:33] <adrien> I've see -p to only preprocess profiles which might be enough to grep with the paths that I am interested in but I'm wondering if there's a cleaner way
[11:41] <adrien> I finally had another look at erlang/rabbitmq-server and the TLS configuration appears to be simply forwarded to erlang/tls without going through code which means that any code change would have to be done in erlang instead and I'm not proficient in erlang
[18:32] <tsimonq2> adrien: jjohansen or sarnold may know the answer to your AppArmor question. That's a good one, let me know what you find.
[18:35] <jjohansen> adrien: so currently apparmor_parser -p is probably your best bet, there is wip to be able to expose more controls around the profile dump (different levels of processing) but nothing that is available atm
[18:36] <jjohansen> at least not cleanly, there are the -D flags, but their dumps can change (its not a fixed format) and they are fairly messy
[18:37] <jjohansen> apparmor_parser --help=D
[18:37] <jjohansen> will give the full list supported by a give parser
[18:41] <jjohansen> apparmor_parser -D rule-exprs would be the next closest thing to -p, it late stage dumping what the rules get converted to before the statemachine build
[18:41] <jjohansen> it comes after includes, variable expansion, rule dedup, etc. It has a certain order to it, but exactly what depends on the dedup phase and that has changed over time, and not all rule types have always supported dedup, etc.
[18:41] <jjohansen> and a single rule might expand into multiple rule-exprs
[18:41] <jjohansen> so it probably not what you are looking for
[18:45] <georgiag> --debug might be helpful as well
[18:46] <jjohansen> but as with dump, its messy and not a fixed format
[18:47] <jjohansen> debug also can vary based on how the parser is compiled, as some of the output will only happen when DEBUG is set at build time
[18:47] <jjohansen> but most it doesn't
[19:02] <adrien> thanks, these all look interesting; I'm not sure which one I'd settle on right now and I guess I'll know when I start using that at scale
[19:03] <adrien> for context, I am interested in finding out which packages ship server programs which communicated over TCP and do TLS, and maybe other protocols
[19:03] <adrien> I have some heuristics but more heuristics is better (and I'll also expand the scope but as you can imagine, there are already quite a few package that match this)
[20:15] <plugwash> hi, the autopkgtest documentation mentions a file called big_packages, but it doesn't say anything about how to view said file or request changes. Can anyone elaborate?
[20:18] <plugwash> ok, I just reread the page and saw the git repo, still leaves the question of how to request changes.
[20:21] <vorlon> plugwash: MP
[20:23] <plugwash> do you mean MR? if so where? (the repo i've found doesn't appear to be on a gitlab instance)
[20:23] <vorlon> merge proposal; the repository is in launchpad, are you familiar with launchpad code hosting?
[20:26] <vorlon> plugwash https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud has some info at the top about how this works
[20:38] <plugwash> hmm, I've cloned the repo, but I can't find big_packages, looking at the cgit url it looks like it's on it's own branch, but I don't seem to have that branch in my clone
[20:38] <vorlon> oh sorry one sec
[20:39] <vorlon> that's simply the wrong repo I mangled urls when trying to translate
[20:39] <vorlon> https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-package-configs
[20:55] <plugwash> ok I've made and pushed a commit, how do I turn that into a merge proposal?
[20:57] <bdmurray> when you did the push you should have seen a url for creating an MP
[20:58] <bdmurray> https://code.launchpad.net/~plugwash/autopkgtest-cloud/+git/autopkgtest-cloud/+ref/main or there is a propose for merge link there
[20:58] <bdmurray> In the MP it would be helpful to point a failure log
[21:47] <bdmurray> plugwash: Do you suspect that there are more packages that might need moving to big_packages?
[21:51] <plugwash> I would not be at all surprised but i'm not going to read every log to find out.
[21:52] <bdmurray> plugwash: there is a tool called retry-autopkgtest-regressions that aids in searching log files but I'll do that
[22:17] <rbasak> plugwash: hello! Long time! Thank you for your help!
[22:57] <bdmurray> liushuyu: what did you do to test the regression potential of gdb e.g. "may break ARM64 execution"?