Alban Browaeys (2024-03-21):
> On Thu, 14 Mar 2024 22:04:33 +0100 intrigeri
> wrote:
> https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/516/diffs
>> … which I understand will be included in 3.7 stable.
>
>
> Should be fixed by 3.7.0-1 which is available
going.
Yes, thanks a lot Simon!
Cheers,
--
intrigeri
://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/516/diffs
… which I understand will be included in 3.7 stable.
Cheers,
--
intrigeri
Hi,
Debian (2023-11-08):
> Am 08.11.23 um 18:14 schrieb Thorsten Alteholz:
>>
>> But this looks rather like a local problem. If your /var/*/cups is not
>> at the default location, you should adapt your apparmor files on your
>> own, shouldn't you?
> Oh yes - that's true. Embarrassing ...
I'm
dditional context, all this stuff has never been really
maintained in Debian proper; it was once used by Ubuntu, together with
their own AppArmor profile for Chromium, but since they moved to
shipping Chromium as a Snap and don't use this AppArmor
policy anymore.
Cheers,
--
intrigeri
eports to track workarounds on top of #1050256 that's
tracking the root cause, or something.
Cheers,
--
intrigeri
workarounds such as disabling
PrivateNetwork=yes for autopkgtests
Cheers,
--
intrigeri
eport and fixing the metadata to make it
clearer what it is about.
Cheers,
--
intrigeri
ase.
If I misunderstood something important, please let me know.
Cheers,
--
intrigeri
ect the
right people.
Cheers,
--
intrigeri
m to the authors of
said profile.
If my assumptions are incorrect, please help me understand :)
Cheers,
--
intrigeri
east track) any remaining problem
Cheers,
--
intrigeri
Hi,
The corresponding SVG icon is missing as well.
Cheers!
id/desktop/org.onionshare.OnionShare.desktop
Cheers,
--
intrigeri
a bug still in the Debian BTS for it.
> intrigeri has already explained the siutation in the upstream bug.
>
> CVE-2016-1585[0]:
> | In all versions of AppArmor mount rules are accidentally widened when
> | compiled.
Upstream has fixed this:
- 2.13.x (Bullseye):
https://gitlab.co
making them use Desktop Portals
(e.g. via GTK_USE_PORTAL=1). This would allow us to make the AppArmor
policy much stricter, and would solve the whole class of UX problems
that this bug is part of.
Cheers,
--
intrigeri
s problem could have been directly caused by
a Debian package or upgrade.
Cheers,
--
intrigeri
.[eE][pP][sS][fFiI23] r,
/**.[tT][iI][fF] r,
/**.[tT][iI][fF][fF] r,
/**.[xX][pP][mM] r,
/**.[gG][zZ] r,
/**.[bB][zZ]2r,
/**.[cC][bB][rRtTzZ7] r,
/**.[xX][zZ] r,
Could you please share a bit more about the value of "name" in the
error message, possibly privately?
Does it end with ".pdf", like name="/run//pdf", or does it
look different?
Cheers,
--
intrigeri
-cli 2.4.0-1 installed,
which includes
/usr/share/rubygems-integration/all/specifications/puppetserver-ca-2.4.0.gemspec.
This satisfies the current dependency that puppetserver has:
ruby-puppetserver-ca-cli (>= 2.3.6)
Cheers,
--
intrigeri
e of
more data): I'm not convinced that installing auditd by default on
Debian would solve more AppArmor usability problems than it would
create. But a "Suggests" seems well deserved: at least for some use
cases, auditd *is* the best solution.
Cheers,
--
intrigeri
Control: forwarded -1 https://gitlab.com/apparmor/apparmor/-/issues/291
Hi,
Damien Pous (2022-12-02):
> On Sun, 22 May 2022 07:53:43 +0200 intrigeri wrote:
>> This suggests it's a bug in the exo-open abstraction.
>> Is this problem fixed by adding the following line to
>
20 magit-toplevel:tramp (1.286620 sec)
passed 20/20 magit-utils:add-face-text-property (0.000050 sec)
Ran 20 tests, 18 results as expected, 2 unexpected (2022-11-22 08:13:31+,
6.072702 sec)
2 unexpected results:
FAILED magit-get
FAILED magit-toplevel:submodule
I feel I'm out o
Package: pdf-redact-tools
Version: 0.1.2-4
Severity: serious
Hi,
At least on Bullseye and sid, any pdf-redact-tools operation fails
with an error like:
convert-im6.q16: attempt to perform an operation not allowed by the security
policy `PDF' @ error/constitute.c/IsCoderAuthorized/421.
Feel free to downgrade severity if this does not affect all systems :)
Thanks for maintaining Dino in Debian!
--
intrigeri
Hi,
Guillem Jover (2022-09-23):
> On Mon, 2022-09-19 at 10:06:11 +0200, intrigeri wrote:
>> According to
>> https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level,
>> _FORTIFY_SOURCE=3 improves memory management protections. It requires
>> glib
Package: dpkg-dev
Version: 1.21.9
Severity: wishlist
Hi,
According to
https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level,
_FORTIFY_SOURCE=3 improves memory management protections. It requires
glibc 2.34. It's been supported in Clang "for some time" and support
was
Control: tag -1 + moreinfo
Hi,
Harald Dunkel (2022-08-18):
> apparmor writes a bazillion of log entries to dmesg and /var/log/\
> kern.log
I don't see this here so I'd like to understand where this comes from.
Could you please share the output of "sudo aa-status" or of "ls
/etc/apparmor.d/"
Package: elpa-ledger
Version: 3.1.2~pre3+g5067e408-2
Severity: serious
Hi,
When upgrading my sid system today, which included the upgrade to
Emacs 28.1, byte-compilation of the ledger .el files failed,
which broke the upgrade. See log below.
I understand that's because
Package: elpa-dimmer
Version: 0.4.2+repack-2
Severity: serious
Forwarded: https://github.com/gonewest818/dimmer.el/issues/50
Hi,
When upgrading my sid system today, which included the upgrade to
Emacs 28.1, this broke:
Install emacsen-common for emacs
emacsen-common: Handling install of
Package: python3-bandit
Version: 1.6.2-1
Severity: wishlist
Hi!
In 1.7.1, upstream added support for configuring bandit via
pyproject.toml, which is nice: it allows configuring various static
analysis tools, linters, etc. in 1 single place.
It would be sweet if the package was updated in time
Hi,
anonym (2022-07-25):
> The attached patch fixes this, and is in fact already merged
> upstream, but not released yet.
Update: the fix was released in 0.10.0 upstream (and 0.10.1 was
released since).
Cheers!
/hypermail/linux/kernel/2104.3/01302.html
Ubuntu 22.04 LTS has this setting enabled by default.
KSPP recommends enabling it:
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
Thanks for your attention,
cheers!
--
intrigeri
Hi,
NIIBE Yutaka (2017-09-27):
> intrigeri wrote:
>> Can you please take a look, and maybe attach an updated patch?
>
> OK.
>
> Attached is updated patch for gcr to fix this issue, by simply supplying
> parent's environ untouched, intended to be put under debian/patc
Julian Andres Klode (2022-07-07):
> My plan is to assume that Installed-Size is close enough to "size in
> /usr", and just compare that with free space in /usr with like a 100MB
> padding.
>
> This does not work for kernels which install in /boot, and if anything
> were to install stuff to /opt or
Package: apt
Version: 2.5.1
Severity: wishlist
Hi,
On a system with a very simple partition layout (/boot and /),
with 2GB available on the root filesystem, APT lets me try to
install packages that will fill the filesystem:
0 upgraded, 355 newly installed, 0 to remove and 0 not upgraded.
Hi,
intrigeri (2022-02-13):
> Alistair J R Young (2022-02-12):
>>> So yeah, Alistair, please submit your last patch a merge request upstream,
>>> as
>>> Christian suggested :)
>>
>> I've done this now and it has been merged:
>>
>> htt
Hi,
This bug report seems to be about 2 distinct problems:
1. Evince cannot start external applications on XFCE because the
exo-open abstraction lacks permission to execute
/usr/bin/xfce4-mime-helper.
A cursory look at the sources suggests that recent exo-open
needs to execute
Hi,
Tobias Mueller (2021-08-13):
> This has been reported as
> https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/582.
>
> And it has already been fixed, but not yet released.
> The patch reverts a workaround for a bug in usbguard<0.7.7.
I understand the fix was released in 41.rc.
Hi Andrej,
Andrej Shadura (2022-03-07):
> This reminded me I promised to work on dh-apparmor. I should find
> time for that,
Great!
> maybe also for apparmor itself.
Sounds good. Please keep me updated as you think about it :)
Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-de...@lists.debian.org,
pkg-apparmor-t...@alioth-lists.debian.net
Control: affects -1 src:apparmor
Hi,
I request assistance with maintaining the apparmor package.
AppArmor has been enabled by default on the Linux ports of Debian
since Buster.
Control: forwarded -1 https://gitlab.com/apparmor/apparmor/-/merge_requests/852
Craig Small (2022-02-17):
> Not sure if Debian BTS handles forwards to MR, I've only ever done it for
> issues.
I don't know if the code that will automatically sync the upstream
state here works, but apart of that
Hi,
Craig Small (2022-02-17):
> On Sat, 12 Feb 2022 at 20:35, intrigeri wrote:
>
>> So it seems to me a good solution may be to allow being ptraced
>> in the "apache2-common" abstraction.
>>
> That makes sense.
:)
>> Would one of you be inter
Package: hiera-eyaml
Version: 3.2.2-2
Severity: serious
Hi,
I usually use "eyaml edit FILE.eyaml" to edit files.
It's currently broken for me on sid.
Even this simpler command fails:
$ eyaml version
Traceback (most recent call last):
7: from /bin/eyaml:25:in `'
6: from
Control: tag -1 + moreinfo
Hi,
Trent W. Buck (2021-09-30):
> The original bug report complained about LibreOffice and Evince.
> I tested those specifically.
>
> LibreOffice is in "complain" mode.
> It's rules fail, but there is no user-visible impact.
>
> Evince is in "enforce" mode.
> I
Alistair J R Young (2022-02-12):
>> So yeah, Alistair, please submit your last patch a merge request upstream, as
>> Christian suggested :)
>
> I've done this now and it has been merged:
>
> https://gitlab.com/apparmor/apparmor/-/merge_requests/812
Awesome, thanks!
Control: tag -1 - moreinfo
Control: tag -1 + upstream
Control: found -1 3.0.3-6
Hi,
Sorry for the noise, I missed some context and got stuff wrong
in my previous message.
intrigeri (2022-02-12):
> Christian Boltz (2021-11-08):
>> Your patch looks like something that should (also?)
Hi Christian,
Christian Boltz (2021-11-08):
> Your patch looks like something that should (also?) be fixed upstream.
My understanding is that the problem here is caused by a Debian patch:
Control: tag -1 + upstream
Hi,
Craig Small (2022-01-05):
> On 2022-01-05 at 12:24, debian-b...@cboltz.de wrote:
>> (Nevertheless, the apache hats should allow to be ptraced.
OK!
>> I'll leave that to the maintainer of the Apache profile in Debian -
>> and would love to see the fix upstreamed.)
Package: onionshare
Version: 2.2-3
Severity: wishlist
Hi,
onionshare currently Depends: obfs4proxy.
But at least recent versions of OnionShare (I did not check which ones
exactly) have code to cope just fine when obfs4proxy is not available,
so "Depends" seems a bit too strong here and it
Package: obfs4proxy
Version: 0.0.8-1+b6
Severity: important
Tags: security
Hi,
Please see
https://lists.torproject.org/pipermail/anti-censorship-team/2022-January/000213.html
tl;dr:
> All existing versions prior to the migration to the new code […] are
> fatally broken, and trivial to
rom e5711ee98c5115cc24fe61b7346de92473b65199 Mon Sep 17 00:00:00 2001
From: intrigeri
Date: Wed, 19 Jan 2022 10:28:03 +
Subject: [PATCH] AppArmor: allow access to
/sys/kernel/mm/transparent_hugepage/hpage_pmd_size
obfs4proxy 0.0.11 needs this.
---
debian/tor.apparmor-profile.abstraction | 1 +
1 file changed
Hi,
Since then, a duplicate bug report was filed (#1000908) and promptly
fixed in 2:3.3.17-6 ⇒ this bug report can now be closed :)
Cheers!
Hi,
Dr. Tobias Quathamer (2021-12-13):
> thanks a lot for your work! I've added some more tweaks and uploaded the
> new version to unstable.
Thanks!
> As a side note: in your local repository, there's probably a tag for
> upstream/1.20.1, which is missing on salsa. Could you please push that
Hi,
Graham Knop (2021-12-05):
> I'm the maintainer of Moo.
I'm seizing this opportunity to thank you for your work. Moo is one of
the few reasons why I still enjoy writing Perl code when possible :)
> The reason Class::XSAccessor isn't listed as a hard prerequisite is
> that Moo is intended to
Hi,
Felix Lechner (2021-12-05):
> Moo performs faster when Class::XSAccessor is available [1] but
> libmoo-perl only Recommends it. More important, Moo's behavior changes
> when Class::XSAccessor is installed. [1] For consistency as well as
> performance, Moo should probably Depend on
Hi,
intrigeri (2021-12-05):
>> I understand this is upstream bug
>> https://github.com/beancount/fava/issues/1266,
>> that's been fixed in the 1.19 release.
>
> Upgrading fava requires python3-flask-babel (>= 1).
>
> I'll try to update it.
I've uploaded p
Hi,
> I understand this is upstream bug
> https://github.com/beancount/fava/issues/1266,
> that's been fixed in the 1.19 release.
Upgrading fava requires python3-flask-babel (>= 1).
I'll try to update it.
Control: tag 995909 + ftbfs
Control: tag 995909 + bookworm
Control: tag 995909 + sid
Control: severity 995909 serious
Control: reassign 995909 src:fava
Control: merge -1 995909
Hi,
Lucas Nussbaum (2021-10-24):
>> help2man: can't get `--help' info from PYTHONPATH="/<>/src"
>> python3 -m fava.cli
Hi,
Sylvestre Ledru (2021-12-01):
> As part of the effort to limit the number of llvm packages in the
> archive, it would be great if you could upgrade to -13 (or -12).
>
> Bookworm won't ship with llvm-toolchain-11
>
> llvm-defaults is now pointing to -13.
I understand a binNMU would be
Control: clone -1 -2
Control: retitle -1 Python bindings fail to build with Python 3.10
Control: tag -1 + upstream
Control: forwarded -1 https://gitlab.com/apparmor/apparmor/-/issues/202
Control: retitle -2 Failure to build for 1 of the supported Python 3 versions
does not trigger FTBFS, while it
eye and sid.)
Cheers,
--
intrigeri
Hi,
Graham Inggs (2021-11-06):
> This package build-depends on python3-all-dev, but does not build
> extensions/libraries for all supported python3 versions.
Thanks for this report :)
debian/rules tries to build for every Python 3 version
output by "py3versions -s".
On my sid system, this
Control: tag -1 + upstream
Control: forwarded -1 https://github.com/Perl-Critic/Perl-Critic/issues/925
Hi,
I can reproduce this even if I delete all lines from
lib/Lintian/Index/Item.pm (current master branch) except the first
5 ones:
# -*- perl -*-
# Lintian::Index::Item -- Representation of
gt;> > a triplet whereas the -config tool is. Thus we get the build
>> > architecture python-config here, but we should use the host one.
>> > AC_PATH_TOOL is required here.
>
> https://gitlab.com/apparmor/apparmor/-/merge_requests/729 is just
> reported.
It's also
Package: python3-discogs-client
Version: 2.3.5-2
Severity: normal
Hi,
Using beets' discogs plugin from sid, OAuth fails:
To authenticate with Discogs, visit:
https://www.discogs.com/oauth/authorize?oauth_token=REDACTED
Enter the code: REDACTED
discogs: connection error: Only unicode
Hi,
intrig...@debian.org (2020-10-25):
> Any objection to removing the package from testing & sid?
I've requested the removal of this package from sid: #996441.
Cheers!
Package: ftp.debian.org
Severity: normal
Hi,
The Perl bindings for Clutter have been deprecated upstream in December 2020.
For this reason, this package has not been in testing since November 2020,
and was not included in Bullseye.
Nobody objected, since I proposed it on 2020-10-25, to removing
Package: wnpp
Severity: normal
Control: affects -1 src:metche
I intend to orphan the metche package.
The package description is:
metche monitors changes made to a "system state" composed of:
- a "watched" directory (typically: /etc)
- one or more user maintained changelog files
Hi,
intrig...@debian.org (2018-11-14):
> Unless upstream and package maintenance are taken over by July 2019,
> I'll orphan the package or request it to be removed from sid (I'm
> undecided yet, opinions welcome).
I'm going to orphan this package.
Cheers!
Hi,
Frank (2021-09-03):
> https://gitlab.com/apparmor/apparmor/-/merge_requests/796
Great!
> It might be as well better to add a patch to current Debian oldstable /
> stable?
I don't think this change qualifies for a stable update: it's more of
an improvement than a bug fix, and local
Thanks!
Package: python3-fava
Version: 1.18-1
Severity: important
Hi!
On current sid, starting fava fails here:
$ fava accounting.beancount
Traceback (most recent call last):
File "/bin/fava", line 33, in
sys.exit(load_entry_point('fava==1.18', 'console_scripts', 'fava')())
File "/bin/fava",
Control: tag -1 + upstream
Control: severity -1 wishlist
Hi,
Frank (2021-06-30):
> The current setup for the profile sanitized_helper does not include a local
> profile for adjustments. I would like to propose
>
> #include
>
> in /etc/apparmor.d/abstraction/ubuntu-helpers
This makes sense to
Hi,
Romain Francoise (2021-07-03):
> On Fri, Jul 2, 2021 at 1:57 AM Christoph Anton Mitterer
> wrote:
>> So is it tcpdump's responsibility to clean this up (manually) or should
>> debhelper
>> do it (somehow ^^) automatically, i.e. also migrate the existing file
>> automatically, because people
Hi,
Ďoďo (2021-09-03):
> Yesterday I noticed that some autoupgrade fully updated my TP. So I removed
> testing, run dist-upgrade to current stable. (TP completely freeze
> during the systemd upgrade) Then I rebooted and exactly the same problem. I
> finished the upgrade (due to previous crash)
Package: dh-apparmor
Version: 3.0.3-1
Severity: normal
"include if exists" is well supported in AppArmor 3.x,
so we could stop creating /etc/apparmor.d/local/$profile
local include files.
I don't think we can do that by default though: if we did, it would
break loading newly installed profiles
Hi,
Роман Ращинский (2021-05-30):
> Thank you!
It seems there's been a misunderstanding.
So again, please answer these questions:
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
*
Package: libapparmor-perl
Version: 3.0.3-1
Severity: normal
I'm considering dropping the Perl extension in the 3.x packaging: it's
not used by anything in Debian anymore and I seriously doubt there's
any relevant, non-obsolete, 3rd-party code that uses it.
Additionally, removing this package
Hi,
Ďoďo (2021-04-11):
> Hi, yes, I do agree the problem is in libc dependencies.
I'm glad we're on the same page here.
> Yes, I am using testing and I just did allow the apt to upgrade all
> the recommended packages.
> […]
> Otherwise I do not understand your comment about "running testing on
Hi,
I faced the same Lintian warning when preparing the apparmor 3.0.3-1
upload: debhelper moves the systemd unit to
/usr/lib/systemd/system/apparmor.service
I was wondering whether Lintian was correct and whether this would
actually cause trouble, especially on non-merged-/usr systems, so
I
Package: ftp.debian.org
Severity: normal
Hi,
I'm splitting #986109, as Sean kindly requested.
The bug report about this package's dependency on libgtk2-perl is #912889.
I'll share some extra information here on top of what's already on #986109,
because among the reverse dependencies of
Package: ftp.debian.org
Severity: normal
Hi,
I'm splitting #986109, as Sean kindly requested.
The bug report about this package's dependency on libgtk2-perl is #932220
(compared to the other libgtk2-perl reverse dependencies that have 33 months old
bug reports about it, this one was filed only
Package: ftp.debian.org
Severity: normal
Hi,
I'm splitting #986109, as Sean kindly requested.
The bug report about this package's dependency on libgtk2-perl is #912874.
The only reverse-dependency is asciio, whose removal I just requested.
Thanks!
Package: ftp.debian.org
Severity: normal
Hi,
I'm splitting #986109, as Sean kindly requested.
The bug report about this package's dependency on libgtk2-perl is #912870.
Unfortunately, the RFH I filed a year ago (#968843) was not sufficient.
Thanks!
Package: ftp.debian.org
Severity: normal
Hi,
I'm splitting #986107 as requested by Sean.
Thanks!
Package: ftp.debian.org
Severity: normal
Hi,
I'm splitting #986107 as requested by Sean.
Thanks!
Package: ftp.debian.org
Severity: normal
Hi,
I'm splitting #986107 as requested by Sean.
Thanks!
Package: ftp.debian.org
Severity: normal
Hi,
I'm splitting #986107 as Sean kindly requested.
On top of the reasons mentioned there, this package has been completely unusable
since 3 years: #983473.
Thanks!
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-emac...@lists.debian.org
* Package name: elpa-persistent-scratch
Version : 0.3.5
Upstream Author : Fanael Linithien
* URL or Web page : https://github.com/Fanael/persistent-scratch
* License : BSD 2-clause "Simplified"
Hi,
I see that power-profiles-daemon has been in experimental for a while?
Is there any particular reason why we should not close this ITP?
Thanks a lot for packaging this piece of software, can't wait to try
it once GNOME 41 lands in sid with the corresponding GNOME Shell UI
bits :)
Hi,
Eduard Bloch (2021-05-24):
> In case you have instructions on the proper process to get this fixed,
> please let me know.
Sure.
The operations involved don't meet the freeze policy, so we'll have to
wait until Bullseye is released.
tl;dr:
- Import and install an AppArmor profile.
I
Control: severity -1 serious
Hi,
Eduard Bloch (2021-06-08):
> I set it RC because it deliberately breaks other package's (legal)
> operations,
The whole purpose of AppArmor policy is to restrict operations to
a pre-defined set. This package does nothing else than shipping opt-in
extra AppArmor
Hi Simon,
Simon McVittie (2021-04-30):
> Sorry, I can't work out how to get a system where the bug you reported
> would even be relevant. At this stage in the release process I am reluctant
> to apply changes that I can't test - please could you describe how I can?
Thanks for having considered
Control: severity -1 important
intrigeri (2021-06-02):
> I see you've made this bug RC. I'd like to better understand the
> severity, so I can figure out what I should do for Bullseye.
> I'm wondering because I'm using this AppArmor policy on sid with
> apt-cacher-ng myself, and
and I can't find traces of such denials in
my logs.
Could you please help me understand what kind of apt-cacher-ng
operations (or configuration) trigger these denials and are broken by
the current AppArmor policy?
Thanks in advance,
cheers!
--
intrigeri
Control: tag -1 + moreinfo
Hi,
Please answer these questions:
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
… so we can understand what's
Control: tag -1 + moreinfo
Hi,
Alistair Young (2021-05-07):
> Specifically, systemd-detect-virt detects WSL as a container,
> technically accurately, but this then causes the apparmor.systemd
> script to decline to start apparmor.
I'm trying to understand what's, at the end of the day, the
Package: gdm3
Version: 3.38.2.1-1
Severity: important
Hi,
On LUKS-encrypted systems, by default the GNOME keyring is encrypted
using the LUKS passphrase typed on boot. pam_gdm unlocks the keyring
using that passphrase. So far, so good.
On current sid, pam_gdm uses the _first_ passphrase that
the copied abstraction with
a dependency on apparmor-profiles-extra at some point, let me know if
there's anything you need from me.)
Cheers,
--
intrigeri
Paul Gevers (2021-04-02):
> On 02-04-2021 14:00, intrigeri wrote:
>> I would like to see the same 1-line change in Bullseye, in the hope
>> that it's enough to allow you folks to remove src:apparmor from
>> the blocklist.
>
> Shall we test first if it helps?
Sure
1 - 100 of 3752 matches
Mail list logo
