1 IRC_meeting_2021 11 09

John Johansen edited this page 2021-11-09 18:53:24 +00:00

(10:00:59 AM) jjohansen1: cboltz, sbeattie, seth, jontourville, georgiag: meeting time
(10:01:11 AM) cboltz: this time I'm here ;-)
(10:02:15 AM) jjohansen1: hey cboltz
(10:02:42 AM) bitblit [~bitblit@0BGAAFQP6.tor-irc.dnsbl.oftc.net] entered the room.
(10:07:08 AM) das_j: You probably meant to ping sarnold and not seth?
(10:07:08 AM) ***cboltz wonders where the others hide
(10:07:53 AM) ***georgiag is here
(10:10:48 AM) jontourville: also here
(10:13:11 AM) jjohansen1: Alright lets get started
(10:14:08 AM) jjohansen1: The first question is whether we want to roll a point release soon
(10:15:01 AM) jjohansen1: if we are releasing soon, the only issue that I have as needing to be revised is https://gitlab.com/apparmor/apparmor/-/issues/202
(10:16:11 AM) jjohansen1: if not then we have several things I would like to land, before rolling the next release
(10:16:21 AM) cboltz: ah, python 3.10 - and switching from distutils from setuptools
(10:16:29 AM) sbeattie: yeah, we need to resolve that.
(10:16:39 AM) jjohansen1: yep
(10:16:50 AM) jjohansen1: that is a blocker for any release
(10:16:52 AM) cboltz: I'm afraid I'm not familiar with this area of python - at least I never touched a setup.py
(10:17:38 AM) cboltz: we could work around the problem by changing our test code, but we'll only survive until python 3.12 with that
(10:18:40 AM) georgiag: I'll take a look and try to fix it 
(10:18:58 AM) cboltz: thanks!
(10:19:54 AM) cboltz: FYI: the issue is about the libapparmor python part, but utils/ also uses distutils
(10:21:31 AM) jjohansen1: oh fun
(10:24:37 AM) georgiag: thanks for letting me know!
(10:24:52 AM) jjohansen1: cboltz: are you going to look at the utils/ part or do you want georgiag to take a look at that as well while she is working on the lib
(10:25:34 AM) cboltz: I won't object if georgiag does it ;-)  (and I promise to review the MR)
(10:27:02 AM) jjohansen1: georgiag: can you look into the utils/ use of distutils as well?
(10:27:06 AM) jjohansen1: please
(10:27:10 AM) georgiag: will do
(10:28:01 AM) jjohansen1: thanks
(10:28:40 AM) jjohansen1: cboltz: how close are the utils to supporting variables?
(10:28:50 AM) jjohansen1: err well conditionals
(10:29:47 AM) cboltz: I'm making slow progress, but it will still take some time until conditional support can be added in a sane way
(10:29:58 AM) jjohansen1: okay
(10:30:03 AM) cboltz: currently using conditionals will result in a profile parse error
(10:30:30 AM) cboltz: (the conditional itsself gets ignored, but the   }   "explodes")
(10:30:44 AM) jjohansen1: got it
(10:31:14 AM) jjohansen1: don't worry, I am going to introduce some more new syntax to explode as well :)
(10:31:55 AM) cboltz: well, depending on what you introduce it might be less explosive
(10:32:13 AM) jjohansen1: well you know set operations on policy
(10:32:45 AM) jjohansen1: { /foo/** rw, } except { /foo/bar w, }
(10:32:51 AM) jjohansen1: and that kind of fun
(10:33:21 AM) cboltz: oh, that indeed looks funny[tm]
(10:33:28 AM) jjohansen1: syntax of course is still being haggled over
(10:34:04 AM) jjohansen1: once the MR hits I expect the discussion to get more lively, its still at least a couple weeks away
(10:34:16 AM) cboltz: just wondering - could we simplify that to   /foo/** rw except ...
(10:34:35 AM) cboltz: I understand why you want   { ... }   for the exceptions, but it shouldn't be needed for the main rule
(10:34:48 AM) jjohansen1: well, the plan is to offer something at the rule level too, eventually
(10:34:53 AM) jjohansen1: but the block level is needed
(10:35:28 AM) jjohansen1: actually very needed, for dealing with includes and some other stuff coming
(10:35:53 AM) jjohansen1: for one it is going to allow removing denies from includes
(10:36:25 AM) jjohansen1: {
(10:36:25 AM) jjohansen1:    include <foo>
(10:36:25 AM) jjohansen1: } except {
(10:36:25 AM) jjohansen1:    deny network,
(10:36:25 AM) jjohansen1: }
(10:37:17 AM) cboltz: well,   include <foo> except { ... }   would be not-too-hard to handle, but I still wonder why you think we need   { include <foo> } ...
(10:37:25 AM) jjohansen1: anyways lets save debate about that feature until their is an MR
(10:37:38 AM) cboltz: (the parser might need it, and could automatically wrap includes in {...} )
(10:37:59 AM) jjohansen1: because there are cases where we need to edit stuff out of includes, we have hit is several times already
(10:38:36 AM) jjohansen1: anyways, I need to keep the meeting moving, or I am going to run out of time
(10:39:17 AM) cboltz: could it be that you think too much like the parser? ;-)   (as in "include means inlining")?
(10:39:21 AM) cboltz: but yeah, we can discuss this at another time
(10:40:22 AM) jjohansen1: So current planning for the next release, is december before christmas
(10:40:50 AM) jjohansen1: I think we can roll a bug fix release for issue 202 sooner, if needed
(10:41:11 AM) jjohansen1: it is definitely an issue for debian so I expect we will
(10:41:28 AM) jjohansen1: is there anything else to discuss?
(10:42:40 AM) cboltz: do you have a rough timeline for a 3.1 release?
(10:44:40 AM) jjohansen1: cboltz: mid-late december, pre-christmas is the current goal
(10:44:55 AM) jjohansen1: is there something specific you want to get in?
(10:45:24 AM) cboltz: only the things that are already in master ;-)
(10:46:01 AM) jjohansen1: well then I guess we can't blame you for slowing/blocking the release :)
(10:47:58 AM) jjohansen1: alright with nothing else, I will note that for the time being
(10:48:23 AM) jjohansen1: wiki.apparmor.net now points to the web page, do to cert issues
(10:48:48 AM) jjohansen1: once we can get those resolved it will redirect to the actual wiki again
(10:49:01 AM) sbeattie: oh, thanks for the time spent on that.
(10:49:45 AM) jjohansen1: next meeting is scheduled for Tuesday Decemeber 14, @18:00 if this is an issue let us know, so it can be rescheduled
(10:49:52 AM) jjohansen1: meeting adjourned