Hi, Thanks for bringing this problem to my attention.
On 2017-09-03 03:01 AM, [email protected] wrote: > Hi! > > (Context: tackling my AppArmor-in-Debian backlog in order to move the > "let's enable AppArmor by default" topic forward.) > > Today I had a look at https://bugs.debian.org/855346 and thought > "well, I'll simply fix myself the issue I've raised when reviewing > https://code.launchpad.net/%7Eu-d/apparmor-profiles/+git/apparmor-profiles/+merge/320276/ > and then will submit for merging upstream + to Debian". And then > I realized that the profile shipped in Debian has diverged from the > upstream / shared / cross-distro one: quite a few changes have been > cherry-picked from Simon's repo > (https://github.com/simondeziel/aa-profiles/) and didn't make their > way to the apparmor-profiles repository. And actually, currently the > profile in the packaging Vcs-Git is exactly Simon's one, modulo > a 1-newline difference. > > I see two problems with this situation: > > * It's not clear to contributors where they should submit > improvements: e.g. if Ulrike's merge request was accepted > upstream, someone would still have to merge it with Simon's > profile (via another PR on GitHub?). > > * It's not clear to the Thunderbird maintainers where they should > pick new versions from. This situation is probably my fault, I apologize. I think we ended up with the current situation because merge proposals in apparmor-profiles are not reviewed quickly enough (and/or I'm not patient enough). > I see two options to fix this confusing situation. > > A. Use lp:apparmor-profiles as the upstream > > This implies that Simon's improvements are submitted to > lp:apparmor-profiles. I guess it would be much easier to do so if > Simon's repo was a fork of lp:apparmor-profiles (that's in Git > now! :) Who would handle that on a regular basis? > > B. Use Simon's repository as the upstream > > To reduce confusion, then I think we should: > > 1. Document *inside* the profile where it comes from / where > improvements shall be submitted. > 2. Empty the usr.bin.thunderbird profile in lp:apparmor-profiles, > pointing to the de facto new upstream repository. > > Personally I would prefer (A), that would avoid having to > learn/document yet another workflow. But I suspect it's not realistic, > and I prefer us doing (B) correctly that (A) poorly. I'm OK with A and wouldn't mind sending any new rules to the official repo. My only concern is what to do when those new rules are stalled waiting on review? Could they be integrated to the Debian version while waiting for the official merge? If yes, I think that's the best of both worlds. No matter A or B, I want and will maintain a working AA profile to support my own usage of Thunderbird and Enigmail on Ubuntu 16.04. If that can be useful to Debian users, I'd be happy to try and make it easier to reuse. In general, I remain committed to have a working TB AA profile working for the current version of TB (+Enigmail) in Ubuntu 16.04 as I depend on that for work/personal stuff. I think 16.04 Regards, Simon P.S.: As soon as I have more time, I'll catch-up on the other TB/AA bugs like https://bugs.debian.org/855346.
signature.asc
Description: OpenPGP digital signature
