Your message dated Sun, 18 Mar 2018 15:05:20 +0000
with message-id <[email protected]>
and subject line Bug#888244: fixed in apparmor 2.12-4
has caused the Debian Bug report #888244,
regarding apparmor: Convert quilt patch series to per-topic subdirectories
managed by gbp-pq
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
888244: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888244
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: apparmor
Version: 2.12-1
Severity: minor
X-Debbugs-Cc: Simon McVittie <[email protected]>
As mentioned when we discussed moving the packaging to Git, I want to
use gbp-pq. This is not feasible yet because lots of metadata about
our patch series is encoded with comments in d/p/series and gbp-pq
drops all this info.
Thankfully there's a way to store this metadata in a more structured
way: we can store patches in sub-directories of d/patches/ and use
gbp-pq's "topic" concept. For example, see how it's done for
src:systemd:
https://anonscm.debian.org/git/pkg-systemd/systemd.git/tree/debian/README.source?h=debian/236-3#n28
So I propose we reorganize the patch series this way:
- Upstream cherry-picks and patches already submitted upstream go
into the "empty" topic (i.e. directly into debian/patches/)
Currently we have two different sections for those in d/p/series:
"Patches backported from upstream commits" and "Patches backported
from upstream fix submissions", presumably to encode the "has the
patch been applied upstream yet?" information. But very often this
info is outdated so I propose to stop pretending we can maintain
it consistently.
- Patches applied on Debian and presumably all derivatives, that are
not applicable upstream, go into "Gbp-Pq: Topic debian" (i.e.
debian/patches/debian/)
These are those corresponding to lines that are currently not
commented out on the debian/master branch in the "Ubuntu-specific
patches" section of d/p/series. So far our patch series has been
organized under the assumption that the Debian packaging is
a derivative of the Ubuntu one; I don't think this reflects reality
anymore so let's instead organize it under the assumption that the
Ubuntu packaging is a derivative of the Debian one.
For example, we would have
debian/patches/debian/libapparmor-layout-deb.patch
- Patches applied on $derivative go into "Gbp-Pq: Topic $derivative"
(i.e. debian/patches/$derivative/).
For example, we would have
debian/patches/Ubuntu/profiles-grant-access-to-systemd-resolved.patch
(it requires fine-grained AppArmor mediation of D-Bus traffic,
which one cannot expect to have outside of Ubuntu).
We could have a sanity check in debian/rules that ensures no such
patch is enabled when `dpkg-vendor --derives-from Ubuntu' returns
non-zero.
- I'm not sure what to do about patches that Debian wants but Ubuntu
doesn't. Thankfully this is a very rare case, of which we currently
have only one instance (pin-feature-set.patch). I propose we put
them into a "debian-only" topic; and we could have a check in
debian/rules that ensures no such patch is enabled whenever
`dpkg-vendor --is Debian' returns non-zero.
- The only patch we have that's not covered explicitly by the above
proposal is non-linux.patch: if we don't drop it (yet?) it would
logically fit in "Gbp-Pq: Topic debian" (there's a good reason not
to apply it upstream but Debian currently wants it and it's
harmless on derivatives that have no non-Linux port).
Then gbp-pq will construct a d/p/series file that's basically the same
as we have currently, slightly reordered, and without comments; any
information stored there in comments currently would be encoded either
by the topic the patch is stored in, and when that's not enough by
DEP-3 headers (e.g. the explanation of why a given patch is applicable
on Ubuntu but not on Debian, or of why another patch is applicable on
Debian but not upstream).
I'll prepare a PoC branch but you folks don't have to wait for it
before you comment. I'll include documentation about patch handling
based on src:systemd's d/README.source.
Thoughts?
In particular I'd welcome input from Simon who, I believe, has built
extensive experience with using gbp-pq's "topic" concept in
similar situation.
Cheers,
--
intrigeri
--- End Message ---
--- Begin Message ---
Source: apparmor
Source-Version: 2.12-4
We believe that the bug you reported is fixed in the latest version of
apparmor, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
intrigeri <[email protected]> (supplier of updated apparmor package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Sun, 18 Mar 2018 13:47:35 +0000
Source: apparmor
Binary: apparmor apparmor-utils apparmor-profiles libapparmor-dev libapparmor1
libapparmor-perl libapache2-mod-apparmor libpam-apparmor apparmor-notify
python-libapparmor python3-libapparmor python-apparmor python3-apparmor
dh-apparmor apparmor-easyprof
Architecture: source
Version: 2.12-4
Distribution: unstable
Urgency: medium
Maintainer: Debian AppArmor Team <[email protected]>
Changed-By: intrigeri <[email protected]>
Closes: 888244
Description:
apparmor-easyprof - AppArmor easyprof profiling tool
apparmor-notify - AppArmor notification system
apparmor-profiles - experimental profiles for AppArmor security policies
apparmor - user-space parser utility for AppArmor
apparmor-utils - utilities for controlling AppArmor
dh-apparmor - AppArmor debhelper routines
libapache2-mod-apparmor - changehat AppArmor library as an Apache module
libapparmor1 - changehat AppArmor library
libapparmor-dev - AppArmor development libraries and header files
libapparmor-perl - AppArmor library Perl bindings
libpam-apparmor - changehat AppArmor library as a PAM module
python3-apparmor - AppArmor Python3 utility library
python3-libapparmor - AppArmor library Python3 bindings
python-apparmor - AppArmor Python utility library
python-libapparmor - AppArmor library Python bindings
Changes:
apparmor (2.12-4) unstable; urgency=medium
.
* Migrate patch handling to gbp-pq (Closes: #888244).
* Merge 2.12-3ubuntu1 (dropping the Ubuntu delta):
- upstream-commit-46f88f5-properly-identify-empty-ouid-fsuid-fields.patch:
new patch, properly identify empty ouid/fsuid fields in logs.
- upstream-commit-130958a-allow-shell-helper-read-locale.patch:
new patch, allow the shell helper regression test program read
the locale.
Checksums-Sha1:
ddc352350850d56011044d991c163f34431826ac 3274 apparmor_2.12-4.dsc
381004b6c661f71016feadd8817eb69f5e13fa22 85176 apparmor_2.12-4.debian.tar.xz
Checksums-Sha256:
e764a2385aeff03e72eac266f93d9d5c9edd675efed19ad742246e4168f1b862 3274
apparmor_2.12-4.dsc
9c12219142515ec8b314962e54498c9a4347a800a5015e4d251d18866840d905 85176
apparmor_2.12-4.debian.tar.xz
Files:
1bdf0908a547009151494922da50d8f8 3274 admin optional apparmor_2.12-4.dsc
0af8dd059e8c2c6fc13dd19bc6fb1d3c 85176 admin optional
apparmor_2.12-4.debian.tar.xz
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEcMAxqZeuB0p8dimNy2kI2AAOzf4FAlqucpUACgkQy2kI2AAO
zf5XxhAAsEy/b7sW3JGGGfxhL5/PVrSs7GVDO1cn8Wg5vg5CQ525++UXBueu3dwO
jIFDRh1N1j1v0P2t9AiNAECkoQKEVqmv1e0qI4D11eoVcm4crqZSOu7C4nbnRzDk
nYy8+/Kxc80HfYYaupvTikiSj8iY1yPX9Vy5rioRg/n6LQeZYE/E7WqJxZBcgfED
lPkRO6l60KLv+JEzqBSMGRv6bypFHqGIchxYL134/4BdKzUte1Md0mJ0WDw9Zneh
8ooEYIoroCRkhDuXuxx2K30gwkTPrLV4iinqz7oIFUaSfKMw1TNO31zFhtn0zkOC
VAEFlEe/qCh3sCQEz5GDUFZcSIOH3q3etN6y1RhN6ynwbCwy0dXzVR4T399FSqUT
FFdyxlwNSD0Sk7MW6yrIhUdKyrZUHb7CiXEoFEMQmaAbdiACoCN7WNF2by52mzMk
G3vPqBB4Kv5reZJsj6IVvb8fkp8OUa2VegVZXSv27GOpxaIZsqVa6AMZmtG6Sazw
Dqt4MGIZMhxx7OmS7D+0uxdBFLhCldUeTZeGWfUzysA8BazVhksHT53YyYUx8o/8
xiyMqdwsUKKm9BWPWwq3q0IlQWOSHCr/JFaDFCwci7fyvmcaVt8VQ3SriIB8Hwbs
u0IGogHvliQBkOhV3iEDIonjkvyurDsYYWfqC0V5cqLwNpIVISY=
=bYho
-----END PGP SIGNATURE-----
--- End Message ---
