tifications.
I did some research on that a while back and ended up not filing a bug
about it because it looked relatively pointless. It appeared to be a deep
design choice on both sides, and not something anyone was likely to solve,
so I just switched to a desktop-aware locker.
--
Russ Allbery (
esn't appear to be a Debian bug for this; it
might be a good idea to open one against light-locker (or, if you confirm
switching to slick-greeter per that bug, lightdm-gtk-greeter).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
things easy while getting
out of your way if you need to do something uncommon and complicated.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
y maintained and integrated; it's
more that they don't see any value in doing that work for the incremental
thing that they're adding. They cobble together some combination of local
config management and a deployment method until it works and then move on
to some (from their perspective) more inter
Ansgar writes:
> On Thu, 2019-05-02 at 09:15 -0700, Russ Allbery wrote:
>> I'm confused. I'm a happy user of dgit and don't have to think about
>> any of those things as part of using dgit. I choose to use branches,
>> but I certainly wouldn't have to, and merging, mul
user of dgit and don't have to think about any
of those things as part of using dgit. I choose to use branches, but I
certainly wouldn't have to, and merging, multiple remotes, and so forth
don't seem related to using dgit at all.
Maybe you're using dgit in a way that's suboptimal for your workflow?
--
roaches, and this one seemed to cause
the least amount of pain. It means I'm not renaming the upstream branches
when I pull them into my repository (which is possible to do in Git but
tedious and irritating if you get the .git/config runes incorrect or some
tool doesn't pay attention and merges the wro
file is absurd. This bit
is a shell script! This bit is a configuration file! This bit is
human-readable text! This bit is a patch list! This bit is a file
manifest! This bit is a structured changelog! This bit is a bunch of
preprocessor definitions! Aie.
One syntax per file, please.
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sat, 09 Mar 2019 14:36:00 -0800
Source: libnet-duo-perl
Binary: libnet-duo-perl
Architecture: source all
Version: 1.02-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Perl Group
Changed-By: Russ Allbery
Description
n
more than twenty years. This seems like a reasonable feature to add.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
the same.
You can use the same approach recursively and symlink every file. This is
an old package manager trick that I think Nix is still using to this day,
and which was used to some success by such things as GNU stow (albeit for
different reasons).
--
Russ Allbery (r...@debian.org)
ontest gathered. I
definitely do not want that dumped into my syslog.
Maybe you could start with Xorg.0.log. :)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
more concrete and specific proposal
with worked examples of how to deal with cases like this. As is, I think
this proposal is much too vague to really discuss, let alone implement.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Mon, 18 Feb 2019 18:58:27 -0800
Source: rssh
Architecture: source
Version: 2.3.4-12
Distribution: unstable
Urgency: high
Maintainer: Russ Allbery
Changed-By: Russ Allbery
Changes:
rssh (2.3.4-12) unstable; urgency=high
ture whether the build was done via sbuild, pbuilder, or cowbuilder,
none of which would arguably qualify as "tainted" but which may have
different behavior and may therefore be useful in tracking down a bug.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
e feels like a more productive investment and would
benefit every package.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sun, 10 Feb 2019 11:17:28 -0800
Source: rssh
Architecture: source
Version: 2.3.4-11
Distribution: unstable
Urgency: high
Maintainer: Russ Allbery
Changed-By: Russ Allbery
Closes: 921655
Changes:
rssh (2.3.4-11) unstable; urgency
(Changing the existing ones is sadly a much more complicated problem.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sat, 02 Feb 2019 10:59:47 -0800
Source: rssh
Architecture: source
Version: 2.3.4-10
Distribution: unstable
Urgency: high
Maintainer: Russ Allbery
Changed-By: Russ Allbery
Changes:
rssh (2.3.4-10) unstable; urgency=high
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Mon, 28 Jan 2019 21:03:59 -0800
Source: rssh
Architecture: source
Version: 2.3.4-9
Distribution: unstable
Urgency: high
Maintainer: Russ Allbery
Changed-By: Russ Allbery
Closes: 919623
Changes:
rssh (2.3.4-9) unstable; urgency
ne can tell, that viewpoint did not prevail.
Maybe it's used less now and it might be easier to get rid of it?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
pfile in this case), the f2 file, the cmd2 command,
>and finally the f3 file. Pretty nifty, eh?
Note also that you can modify @ARGV in the program and then use <>, and I
know of Perl programs (I have even written Perl programs, back in the day)
that do this to introduce pipes and other constr
e discussions of this on perl5-porters, and
there's some general consensus that it was a bad idea originally, but
changing this destroys backwards compatibility. You just can't; it's like
removing strcpy from libc. The best you could do would be to add a
pragmata to turn it off, and *maybe*, *someday*, enable that pragmata by
default with a sufficiently new version in "use".
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
k it's worth writing an explicit Policy exception for this,
since it's a single edge case. Instead, I think it's a good use of a
Lintian override documenting what's going on. Obviously, if Nix becomes
really popular in the long run, we can then go back and write this into
Policy.
--
Russ Allbery (r..
ck to having Policy say one thing but having the standards for
the archive be something else entirely, something that we all have been
collectively unhappy about for probably at least a decade. I think
there's a pretty strong consensus for keeping the wording of Policy in
tighter alignment with what ftp-ma
ntation, and client configuration to send
all mail from debian.org addresses through project infrastructure would be
a lot of work, particularly since I'm sure that, in the grand Debian
tradition, there are at least as many ways we all send mail as there are
Debian developers.
--
Russ Allbery (r..
, it's still the wrong way to go
> around this.
Does this imply that you're considering adding support for merging /usr
*properly* directly inside dpkg, with all the correct updates to dpkg's
metadata?
Because that would be an awesome way to fully support this.
--
Russ Allbery (r...@debian.org)
using
problems.
But perhaps the reproducible build testing infrastructure is the better
solution to this problem.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
need
to be in place.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ckages, or ship something that just notes that the unit file can be
autoconverted. This would cut down on the maintenance burden of the
primary package maintainer a lot.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
That will give us something concrete to
debate and to test against the risks that people perceive, and hopefully
will reduce the hardening of positions on all sides.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
n using the env trick.
This therefore makes your point even stronger.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ive years from now has to do a bunch of
work to finally finish, assuming that happens at all. But it would be
backward-compatible the entire way.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
sion *now*, when the problems are
fresh in our mind, and then defer *action* to early in the bullseye
release cycle (which I suspect is likely to happen anyway given how long
it usually takes us to sort through questions of large migrations like
this).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
at we can lean on a single, well-tested, robust
implementation.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
e disagree.
To support my side of that, I promise to not mischaracterize consensus on
*what we're debating* as consensus on *what the outcome should be*, and
keep those two things entirely separate.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Michael Stone writes:
> On Wed, Nov 21, 2018 at 02:19:56PM -0800, Russ Allbery wrote:
>> Doing this check in reproducible-builds definitely helps allievate my
>> concerns as a backstop, but this is still fragile and we don't have a
>> tight test/fix cycle. And, in general,
d then
allow running it on both merged and unmerged systems. There are so many
places that binary paths creep into software build processes, and so many
different upstream software build processes to analyze.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Holger Levsen writes:
> On Wed, Nov 21, 2018 at 12:38:53PM -0800, Russ Allbery wrote:
>> But it's not just my opinion that matters. I think we need to decide
>> this somehow as a project, whether via the TC or via GR or something,
>> because there's a real disagreement her
s definitely a valid point.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Jeremy Bicha writes:
> On Wed, Nov 21, 2018 at 3:39 PM Russ Allbery wrote:
>> But it's not just my opinion that matters. I think we need to decide
>> this somehow as a project, whether via the TC or via GR or something,
>> because there's a real disagreement here over whe
Michael Stone writes:
> On Wed, Nov 21, 2018 at 09:59:24AM -0800, Russ Allbery wrote:
>> If we just force-merge every system on upgrade, none of those
>> inconsistencies matter, and I do believe we could successfully complete
>> that process (with some bumps, of course).
&g
Marco d'Itri writes:
> On Nov 21, Russ Allbery wrote:
>> I think there are some arguments to be made for just force-merging and
>> moving on, but they're mostly "tidiness" arguments (letting everyone
> No, they are not that at all. I have never argued about "
erge and be done with it,
or whether we're going to do a much slower migration by some more robust
strategy of (for example) moving each binary out of /bin manually, but
either way, the current strategy does not seem viable to me.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Ian Jackson writes:
> Russ Allbery writes ("Re: Our build system may be broken: /bin vs /usr/bin"):
>> Marco d'Itri writes:
>>> Actually this is the root problem: policy says that packages should
>>> use the $PATH to search for commands, but your pac
d use
> the $PATH to search for commands, but your package (like many others)
> hardcodes their full path.
Policy only says that for maintainer scripts. I agree that it's not a
good idea in any location, but I don't believe we've explicitly forbidden
it anywhere.
--
Russ
Carsten Leonhardt writes:
> Russ Allbery writes:
>> The general principle that I would advocate for here, though, is that
>> if someone says clearly and explicitly "never contact me again," we
>> should do what we can to never contact them again.
> If the
never been able to contact them again.
To be clear, I think his reply was unnecessarily nasty, and I greatly
appreciate the work that you're doing. This is not intended as any sort
of dissatisfaction with your work, just a suggestion for if this comes up
again.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
o run Debian on non-free hardware and leave that choice up to the
user. (I also don't think this would be useful from a tactical
standpoint; vendors making such locked-down hardware don't care whether
Debian runs on it.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
a PAM module that determines which logind is running and then dispatches
the PAM calls to the appropriate module for the running logind.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
The Wanderer writes:
> On 2018-10-25 at 20:00, Russ Allbery wrote:
>> The Depends field should be used if the depended-on package is
>> required for the depending package to provide a significant amount of
>> functionality.
> This does not actually seem to
is in any way
doing something wrong given what Policy says right now. This *clearly*
meets the definition of Depends as currently stated in Policy.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Ian Jackson writes:
> Russ Allbery writes ("Re: no{thing} build profiles"):
>> Minimal installation size is *not* the only goal here. Ease of use and
>> lack of surprise is important to. Personally, I'd much rather have
>> numerous unused packages install
in this thread are too worried about trying to
remove as many packages from their system as possible and not worried
enough about a straightforward user experience.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Paul Wise writes:
> On Thu, Oct 18, 2018 at 5:24 AM Russ Allbery wrote:
>> Timer units are also a more complicated problem since they're not a
>> superset of cron behavior. They do some things better than cron jobs;
>> they do other things much *worse* than cron jo
Philipp Kern writes:
> On 17.10.2018 06:52, Russ Allbery wrote:
>> I think a package of a daemon that does not inherently require any
>> systemd-specific features and would work straightforwardly with
>> sysvinit, but has only a systemd unit file and no init script, is not
should solve the problem of timer/cron de-duplication before
opening the door to timer units. I agree that timer units would be a very
valuable addition to a lot of packages, but timer/cron de-duplication
feels like an entirely tractable problem that's useful to resolve in its
own right. Maybe
bian user that they use apt instead
of apt-get as their normal interaction mechanism with the package system.
Sometimes the other tools are useful for getting more specific behavior,
but the defaults of apt seem well-tuned for the typical user and typical
use cases.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
strongly against epochs. When I first got involved in Debian, it
was common to use epochs whenever we had to package an older version of
upstream for some reason, but my impression is that this has fallen out of
favor. That reduces the use of epochs considerably.
--
Russ Allbery (r...@debian.org)
t would
give me pause is going from a 0.x to a 1.x version number, since that
carries some more semantic weight.) But I could see some people being
irritated by the request.
I think there's no substitute for knowing upstream and having a feel for
how they'd react.
--
Russ Allbery (
Andrey Rahmatullin writes:
> On Mon, Sep 24, 2018 at 09:21:14AM -0700, Russ Allbery wrote:
>> apt is going to have no idea what to do for a system that already has
>> the previous package installed.
> This is not a problem as upgrading to an unrelated software is not
> som
of software. Version
numbers should be monotonically increasing, and I think it's reasonable
for a lot of software to bake in the assumption that's the case.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
that address CVEs or Debian
> bug reports?
For the record, I've found these curated summaries of the upstream changes
*incredibly* helpful more times than I can count. So I'd love to see
these continue to be available somewhere.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
oth your original phrasing and "this is a lie" (unintentionally, I
assume) implied.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ontinues to expand,
and not all of the problems have relatively easy solutions.
(Node, which came up elsewhere in this thread, was a particularly
challenging problem because it was an interpreter and had to be referenced
in #! lines. Hopefully we won't have that specific problem frequently.)
--
l use the other
program.
It's not totally unheard of to have to modify PATH to use a package,
particularly one that wants to use a bunch of very generic command names.
That was always the official way to use MH, for example.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Fri, 31 Aug 2018 17:07:43 -0700
Source: krb5-strength
Binary: krb5-strength
Architecture: source
Version: 3.1-2
Distribution: unstable
Urgency: medium
Maintainer: Russ Allbery
Changed-By: Russ Allbery
Description:
krb5-strength
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Fri, 31 Aug 2018 15:52:25 -0700
Source: xfonts-jmk
Binary: xfonts-jmk
Architecture: source
Version: 3.0-22
Distribution: unstable
Urgency: medium
Maintainer: Russ Allbery
Changed-By: Russ Allbery
Description:
xfonts-jmk - Jim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Fri, 31 Aug 2018 10:57:00 -0700
Source: libpam-krb5
Binary: libpam-krb5 libpam-heimdal
Architecture: source
Version: 4.8-2
Distribution: unstable
Urgency: medium
Maintainer: Russ Allbery
Changed-By: Russ Allbery
Description
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sun, 26 Aug 2018 18:17:15 -0700
Source: krb5-sync
Binary: krb5-sync-plugin krb5-sync-tools
Architecture: source
Version: 3.1-2
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group
Changed-By: Russ Allbery
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sun, 26 Aug 2018 16:11:10 -0700
Source: libpam-afs-session
Binary: libpam-afs-session
Architecture: source
Version: 2.6-2
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group
Changed-By: Russ Allbery
Description
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sun, 26 Aug 2018 15:02:10 -0700
Source: gnubg
Binary: gnubg gnubg-data
Architecture: source
Version: 1.06.002-1
Distribution: unstable
Urgency: medium
Maintainer: Russ Allbery
Changed-By: Russ Allbery
Description:
gnubg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sun, 26 Aug 2018 13:34:55 -0700
Source: kstart
Binary: kstart
Architecture: source
Version: 4.2-2
Distribution: unstable
Urgency: medium
Maintainer: Russ Allbery
Changed-By: Russ Allbery
Description:
kstart - Kerberos kinit
ere may already be one).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
he package. It's completely obvious
that the word "boob" is referring to female anatomy, and the rest of the
package is an extended riff on that joke.
You can certainly disagree about how important that is or what impact it
might have, but let's at least be honest about the obvious i
beros ticket cache implementation (still a non-standard one,
though) that uses this mechanism since it even works across processes if
one is careful. It's a really interesting trick, although it has a few
drawbacks.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
the same way any user of the
package would: instantiating the net and further training it, or starting
over and training a new network.
That may have been a better example to ask about than my scientific data
example.
(For those who are curious, this is the file gnubg.weights in the gnubg
source packa
is rendered helpless.
This is a great argument. I'm convinced.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ientific data, reproducing a result data set is not trivial and
the concept of "source" is pretty murky.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ration and build on
the tool that's already solving 95% of this problem. (Or, alternatively,
a lower-level tool that uscan itself, as well as other tools like dgit,
can use, and that borrows from the work uscan has already done.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
n the get-orig-source target, specifically Files-Excluded in
debian/copyright. See the documentation of Files-Excluded in uscan(1).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
is more
dubious and often doesn't add much value for them.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
like you now want https://dep-team.pages.debian.net/ (probably
because the repository migrated to Salsa).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sat, 26 May 2018 19:03:58 -0700
Source: tf5
Binary: tf5
Architecture: source
Version: 5.0beta8-7
Distribution: unstable
Urgency: medium
Maintainer: Russ Allbery <r...@debian.org>
Changed-By: Russ Allbery <r...@d
eral.
But things like this may be a nice solution for the 80% case.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ain...@lists.alioth.debian.org>
Changed-By: Russ Allbery <r...@debian.org>
Description:
libnet-duo-perl - Perl API for Duo multifactor authentication service
Changes:
libnet-duo-perl (1.01-2) unstable; urgency=medium
.
[ Russ Allbery ]
* Contribute the package to the Debian Perl Group.
- Chang
Urgency: medium
Maintainer: Russ Allbery <r...@debian.org>
Changed-By: Russ Allbery <r...@debian.org>
Description:
libnet-remctl-perl - Perl client for Kerberos-authenticated command execution
libremctl-dev - Development files for Kerberos-authenticated command execution
libremct
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sun, 22 Apr 2018 10:58:03 -0700
Source: rssh
Binary: rssh
Architecture: source
Version: 2.3.4-8
Distribution: unstable
Urgency: medium
Maintainer: Russ Allbery <r...@debian.org>
Changed-By: Russ Allbery <r...@d
ere there be dragons, you may not want to go down this path."
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Russ Allbery <r...@debian.org> writes:
> Adam Borowski <kilob...@angband.pl> writes:
>> Thus, there are locales where a purely ASCII word sorts differently
>> when capitalized and when not.
> Yes, including en_US.
Just to head off the noise of the corrections fo
Andreas Tille <andr...@an3as.eu> writes:
> From my understanding the names in quotes should be parsed correctly,
> right?
Definitely not. They will absolutely break with some tools.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
e Maintainer field for various
purposes (tracker.debian.org, dd-list, etc.).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Adam Borowski <kilob...@angband.pl> writes:
> On Wed, Apr 18, 2018 at 10:19:46AM -0700, Russ Allbery wrote:
>> That said, nearly all US English writers will just omit the accents
>> anyway. At least US English (I can't speak for UK) really aggressively
>> drops acce
t easier to just leave them
off.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
as just a miscommunication, but the NMU process is spelled
out to try to avoid exactly this miscommunication, and also because it
provides a lot of signal for figuring out what packages do need a change
of maintainers.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
and I also
don't think this fairly unusual edge case requires standardization.
That said, I think guidance for good practices for edge cases is always
useful if someone wants to write it up, and the Developer's Reference
seems like a good place to accumulate such things.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Paul Wise <p...@debian.org> writes:
> On Thu, Apr 12, 2018 at 5:02 AM, Russ Allbery wrote:
>> Rather than documenting this fallback in Policy, why not add that
>> fallback directly to uscan?
> uscan is used in situations where one does not want arbitrary code from
> so
osed of integers. Getting another integer is
free, and there is not a limited supply. We won't run out, and missing
sequence numbers cause no problems in the world.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
if there is really no chance to use uscan) seems
> important to me,
Rather than documenting this fallback in Policy, why not add that fallback
directly to uscan?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
moving it outside
the scope of Policy, such as how to document dependencies required for
running the get-orig-source target.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
401 - 500 of 4303 matches
Mail list logo
