Timo Röhling writes:
> I think these are questions we need answered, because it would be
> advisable to have someone with clearly defined responsibilities at
> the wheel for the transition. Otherwise, we risk stale-mating
> ourselves with endless debates on how to finish the transition
> "properl
:
>On 15/05/2023 16:54, Bdale Garbee wrote:
>> I could.
>>
>> Can you provide an example of actual value delivered to Debian from
>> merged-/usr?
>
>With respect, I don't think this line of argument is going to get us very far
>- this bug isn't abou
I could.
Can you provide an example of actual value delivered to Debian from merged-/usr?
Bdale
On May 15, 2023 7:15:53 AM MDT, Luca Boccassi wrote:
>On Mon, 15 May 2023 at 13:51, Bdale Garbee wrote:
>>
>> Merged-/usr seems to me to have brought great pain with no discerna
Merged-/usr seems to me to have brought great pain with no discernable benefit
to Debian so far, and I at least have completely lost the thread on what the
point of doing it was supposed to be. So, using it as a justification for
further harm to user and system expectations isn't compelling.
B
Russ Allbery writes:
> I assumed that if option B won, some
> maintainers would drop init scripts, and therefore if folks wanted to
> maintain a set of working init scripts, they'd need to look at different
> options than ensuring they were incorporated into each package.
I agree, this was my se
Santiago Vila writes:
> Even if we ever wanted to allow packages to "need" more than one CPU
> for building, I'd like to believe that we would do so by introducing a
> new control field for that, say, Build-CPU, instead of making
> multi-core mandatory for all packages.
I agree.
Bdale
signatu
Sean Whitton writes:
> The concrete question that I am asking the committee to decide, in my
> capacity as a Policy delegate, is whether or not vendor-specific patch
> series should be permitted in the Debian archive.
While I am no longer a member of the TC, and my analysis of the
situation cons
Aleksander Morgado writes:
I'm no longer a TC member, but have been bitten by this problem, so will
chime in.
> Would the new approach satisfy Debian's needs?
It seems so to me. The key thing I care about is that we *not* assume
any arbitrary cdc-acm device is a modem. I can't say for sure, b
Philip Hands writes:
> So, I'd say that the whole thing was a car-crash anyway, and this just
> dropped a cigarette in the spilling petrol.
Yeah. I'm not immediately sure to suggest as a way to do things
differently, and this may not seem immediately helpful... but about the
first piece of advi
Adrian Bunk writes:
> Only DFSG-free packages that depend on non-free software are allowed
> in contrib.
At Debconf in Heidelberg, this definition was tweaked somewhat by
inspiration of the sitting DPL in light of the ZFS discussion to include
software which itself is free, but the use of which
Sam Hartman writes:
> It was asked who plans to go to debconf in the meeting today.
Assuming someone proposes one, I'm very much looking forward to sitting
in the audience at a TC BOF this year... ;-)
Bdale
signature.asc
Description: PGP signature
Kurt Roeckx writes:
> The alternative is that I go and cherry pick the important bug
> fixes. By this time there are really a lot that I would like to
> have in the stable releases and I think going that way actually
> has a higher chance of breaking things.
We've run into this before a number
Sam Hartman writes:
> I'd like to call for votes on the following resolution:
I vote D > A=B > Z > C.
Bdale
signature.asc
Description: PGP signature
Don Armstrong writes:
> I personally cannot reasonably dedicate more than an hour or two a week
> to the CTTE, and I suspect that few people serving can either.
2 hours a week seems pretty consistent with what I think I've spent over
the years. The initsystem debate was a complete anomaly, I do
Sam Hartman writes:
> I'm just sying having seen it used once I'd rather decide never to go
> there again.
For what it's worth, I agree.
Even in the worst of times, I'm personally just fine with extreme
boundary conditions being left to human sensibility. We have a pretty
effective set of ch
The suggestion someone made somewhere during this discussion that I
liked the best was quite simple. Every time there is a change in the
membership of the TC, we should have a vote on who should serve as
chair. Given the term limits now in place, that would guarantee a
fairly regular need to vote
Didier 'OdyX' Raboud writes:
> What about meeting in the foyer at 11h30 [0]?
I can do that.
Bdale
signature.asc
Description: PGP signature
Sam Hartman writes:
> I can be available via IRC, webrtc, SIP, phone or any other streaming
> media in Debian to participate in any TC-related activities.
No worries, Sam! Glad to hear $dayjob is keeping you technically
engaged!
Bdale
signature.asc
Description: PGP signature
Sam Hartman writes:
> I would like to be heard and understood ...
> I hear Bdale's frustration when he talks about how long this has been
> going on, and the concerns he raised about having to dig through the
> entire history.
>
> For me, honoring the work of the debian-policy team is important
Sam Hartman writes:
> Unless we get significantly more feedback very soon, let's stick both on
> the ballot.
Works for me.
Bdale
signature.asc
Description: PGP signature
Mehdi DOGGUY writes:
> Le 31 mars 2015 02:49, bjf...@gmail.com a écrit :
>>
>> After explaining we have an impressive ratio of female to male
>> participants in the Debian project as a whole (not just technical),
>> your suggestion is to get more women involved generally with Debian
>> (still not
Sam Hartman writes:
>> "Andreas" == Andreas Barth writes:
>
> Andreas> * Sam Hartman (hartm...@debian.org) [150311 13:18]:
> >> So, I don't feel that I have the information I need to make an
> >> informed decision on this issue, so I won't be able to cast a
> >> ballot.
>
Don Armstrong writes:
> The outcome is no longer in doubt:
While this is true, I note that the constitution says we either need all
current members to vote or a week to pass for the vote to officially
conclude.
Regardless of how much longer it takes to be "official", congratulations
Don!
Bdale
Bdale Garbee writes:
> === BEGIN
>
> The Technical Committee Chairman should be:
>
> A: Don Armstrong
> B: Andreas Barth
> C: Steve Langasek
> D: Keith Packard
> E: Didier Raboud
> F: Tollef Fog Heen
> G: Sam Hartman
>
> == END
In light of Lucas' appointment of our recommended candidates to the
Debian Technical Committee, I would like to start by congratulating and
welcoming Sam Hartman, Tollef Fog Heen, and Didier Raboud .. as you will
soon see, I intend to put you immediately to work in your new roles!
I would also lik
Sam Hartman writes:
> I regret bringing this up at such a late point, although I couldn't come
> up with any better options. I didn't want to just have a discussion
> with Bdale and the DPL.
By this time next year, more than half the sitting TC will be "new", so
there's every reason to want to
Don Armstrong writes:
> ===BEGIN
>
> The Technical Committee recommends that Sam Hartman (hartmans) be
> appointed by the Debian Project Leader to the Technical Committee.
>
> A: Recommend to Appoint Sam Hartman (hartmans)
> B: Further Discussion
>
> ===END
A > B
> ===BEGIN
>
> The Technical Co
Anthony Towns writes:
> The way it was done last time was:
That was to decide between two "final candidates" for one open
position. We now have 2 present and one pending (Colin's) open
positions, and have discussed the nominated list of candidates privately
as has been our custom.
I'd be happ
Don Armstrong writes:
> Please vote [A] for Decline to override, and [FD] for Further
> Discussion.
I vote A, FD.
Bdale
signature.asc
Description: PGP signature
Svante Signell writes:
> Do people use the usb stick/cd/dvd etc for upgrades to jessie, i.e. the
> debian installer. Or do they only use apt/aptitude/etc?
I don't know that we can speak in absolutes, but I've never personally
seen or heard of anyone using debian-installer to do an upgrade.
Bdal
Don Armstrong writes:
> I think we should give people a bit more time to come up with options,
> but if no one is even moving by our IRC meeting on December 4th, then
> something along these lines seems reasonable to me.
I agree.
Bdale
signature.asc
Description: PGP signature
Don Armstrong writes:
> Package: tech-ctte
> Severity: minor
> User: tech-c...@packages.debian.org
> Usertag: consensus-seeking
>
> On Mon, 17 Nov 2014, Bdale Garbee wrote:
>> I see that Don has added an agenda item about this to our next IRC
>> meeting schedul
With the resignation of Russ and notice of impending resignation from
Colin, I believe we should begin the process of finding new members for
the committee.
I see that Don has added an agenda item about this to our next IRC
meeting scheduled for 4 December, but I don't really want to wait until
th
Bdale Garbee writes:
> I'm intentionally not making this a public message ...
I clearly failed to adequately edit the message headers before sending.
Oh well.
Bdale
signature.asc
Description: PGP signature
Colin Watson writes:
> I hereby declare my intent to resign from the Debian Technical
> Committee. The Constitution doesn't really have a clear procedure for
> handling resignations here; I expect the TC will want to appoint a new
> member, which I appreciate might take a while. Subject to advi
Ian Jackson writes:
> I am calling for votes on the text below:
> Y (override, swap dependencies, requires >>3:1)
> FD
I vote Y > FD.
Bdale
signature.asc
Description: PGP signature
Ian Jackson writes:
> 2. Normally when Debian changes the default provider of some service,
> this means that new installs get the new provider. We do not
> transition existing installs to the new provider during upgrades,
> unless the old provider is being removed.
That's not stri
Russ Allbery writes:
> I think "default" is about what we install with fresh installs.
> That's consistent with the other examples you list, where we've picked
> a default.
I agree.
Bdale
pgpbspOmI0C3L.pgp
Description: PGP signature
Steve Langasek writes:
> As previously agreed in the IRC meeting, I call for votes on this question
> with the following ballot options:
>
> A non-free packages as non-default alternatives should not be prohibited in
> main
> B non-free packages should always be prohibited in package depende
Ian Jackson writes:
> I would accept increasing the required number of stoppers to two
> (which is also the quorum for passing a resolution).
That's certainly preferable to one.
> And, secondly, that the ultimate outcome of separate votes on
> semantically related resolutions might be incoheren
Ian Jackson writes:
> I would like to present an improved proposal for a minimum TC
> discussionn period, which will allow the committee to move quickly
> when there is consensus (at least, procedural consensus) within the
> committee:
In the general case, a discussion period is clearly desired.
Ian Jackson writes:
> Ian Jackson writes ("Re: Bug#717076: libjpeg draft resolution"):
>> I hereby propose the resolution below. I intend to call for a vote no
>> earlier than after the conclusion of the relevant agenda item in
>> tomorrow's IRC meeting.
>
> As agreed on IRC, I hereby call for v
Ian Jackson writes:
> As discussed at the meeting, I hereby call for votes on this
> resolution (text below).
>
> There are two options
>Y Issue statement about (multiple) init system support
>FD
>
> Thanks,
> Ian.
>
> -- resolution text begins
>
> The issue of init system support re
Ian Jackson writes:
> Here is the resolution text that I think we agreed at the last
> meeting. I formally propose this text:
>
> The issue of init system support recently came to the Technical
> Committee's attention again.[1]
>
> For the record, the TC expects maintainers to contin
Cameron Norman writes:
> From your other message I was under the impression that you thought it
> was ok to remove Upstart support, but now you agree that if there was
> interest, then it should be kept (as long as it does not cause
> issues).
Under the circumstances, I don't think we should
Russ Allbery writes:
> I can see your point that the future of upstart is possibly unclear, but
> my feeling is that if anyone filed a bug against a package requesting
> upstart support, that's sufficient indication of interest to merge upstart
> support patches, including this sort of minor modi
Ian Jackson writes:
> Russ Allbery writes ("Bug#746715: the foreseeable outcome of the TC vote on
> init systems"):
>> On what grounds do you think it was a mistake? As soon as someone talked
>> to the maintainer in question and asked them to re-add support, support
>> was almost immediately re
Steve Langasek writes:
> Package: tech-ctte
>
> An Ubuntu developer just brought the following Debian changelog entry to my
> attention:
>
> tftp-hpa (5.2-17) experimental; urgency=low
>
>* Removing upstart hacks, they are ugly and upstart is dead now.
>
> Since various members of the Tech
Don Armstrong writes:
> I don't have a problem with this myself; does anyone have a problem with
> date -d'Thu May 22 17:00:00 UTC 2014'?
Works for me.
Bdale
pgpe66xHGeKAu.pgp
Description: PGP signature
Don Armstrong writes:
> date -d'Thu May 29 17:00:00 UTC 2014'
Looks ok on my calendar.
Bdale
pgpplSRK5UVcU.pgp
Description: PGP signature
Ian Jackson writes:
> I did find three which are arguably recalcitrant maintainers:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407750
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609807
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738027
> But this is a gratifyingly l
Russ Allbery writes:
> This issue is, in part, an internal team conflict between Bill and
> myself, so I don't think it's appropriate for me to vote.
Thanks for being up-front about this, Russ.
Please do contribute to the discussion.
Bdale
pgpAq05j9I2AQ.pgp
Description: PGP signature
Colin Watson writes:
> I ran across this interesting post from an upstream GNOME developer
> which I think deserves some signal-boosting ...
Indeed. Thanks for the pointer.
Bdale
pgprLKfQDUuJW.pgp
Description: PGP signature
Ian Jackson writes:
> I hereby call for votes on my coupling proposal and the amendments
> that have been put.
With all 8 votes cast, this CFV on the init system coupling issue has
ended in a tie between options "L" and "N". Given my vote on this
issue, it should be no surprise that I use my ca
Ian Jackson writes:
> * 2:1 supermajority for TC overrides should be abolished (seems
>we are probably agreed on this - speak now if not)
I'm fine with this.
> * FD threshold needs to be >= always, not >. Requirement to get
>>> 4/8 voting X > FD was exploitable and bad news.
There h
Ian Jackson writes:
> I hereby call for votes on my coupling proposal and the amendments
> that have been put.
>
> L Software may not depend on a specific init system
> N No TC resolution on this question at this time
> A Advice: sysvinit compatibility in jessie and multiple init supp
Ian Jackson writes:
> I'm going to try to go through this thread and produce a draft Call
> for Votes based on the proposals, amendments etc. which have been
> emailed so far.
That would be good, since I at least have sort of lost track of what you
think the ballot options will be at this point.
James Hogarth writes:
> So in light of the new announcement[1] how much of L vs T is still
> relevant?
Mark's announcement may mean that upstart is less likely to be a viable
alternative over time, but it says nothing at all about the other init
systems and their users in Debian.
Bdale
pgpw
Ian Jackson writes:
> I hereby propose the L versions from git:
>
> == dependencies rider version L (Loose coupling) ==
>
> Software outside of an init system's implementation may not require
> a specific init system to be pid 1, although degraded operation is
> tolerable.
>
>
Steve Langasek writes:
> FWIW I have always assumed that the casting vote is implicit in the chair's
> ballot. To require the chair to explicitly exercise their casting vote, as
> opposed to the chair's preferences as expressed on the ballot being applied
> automatically, opens up another set of
Ian Jackson writes:
> I hereby call for votes on the following resolution
>
>If the project passes (before the release of jessie) by a General
>Resolution, a "position statement about issues of the day", on the
>subject of init systems, the views expressed in that position
>statem
Ian Jackson writes:
> I hereby call for votes on the following resolution:
>
>The init system decision is limited to selecting a default
>initsystem for jessie. We expect that Debian will continue to
>support multiple init systems for the foreseeable future; we
>continue to welco
Sam Hartman writes:
> 2) Russ and Steve were discussing text for a coupling option. That's
> still a live discussion, right? The fact that there haven't been any
> messages there is more about spending your time on other things and not
> a sign you've given up?
I suspect they were waiting for
Anthony Towns writes:
> A.6.6: Schwartz set is {D,U}
> A.6.8: There are no defeats in the Schwartz set, so the elector with
>the casting vote chooses which of these options wins.
>
> Per 6.3.2, the casting vote is held by the Chairman, who is currently
> Bdale.
Thank you, Anthony, for yo
Ian Jackson writes:
> I hereby call for votes on the following resolution
Equivalent language reviewed by our project secretary was included in my
resolution. Is there some particular value you see in running this as a
separate resolution?
Bdale
pgp0Lg4UR_bki.pgp
Description: PGP signature
Steve Langasek writes:
> I will note for the record here that a number of DDs have at this point
> given the TC an ultimatum in private, stating that they will start a GR if
> the TC does not call for votes within a specified time limit. I suspect
> that this ultimatum didn't have much effect on
Bdale Garbee writes:
> - - - start ballot - - -
>
> We exercise our power to decide in cases of overlapping jurisdiction
> (6.1.2) by asserting that the default init system for Linux
> architectures in jessie should be
>
> Dsystemd
>
> Uupstart
>
>
I have carefully considered Ian's current proposal for a process and
schedule to reach a next ballot on the init system issue, and do not
believe it is the best way for us to proceed.
The fundamental problem is that I remain as convinced now as I was when
I posted my last CFV that conflating multi
Ian Jackson writes:
> If so I think it would be useful, although I guess Bdale as chair of
> the ctte ought to decide.
I think it's far too late for it to be useful on our current issue. The
bug thread is already too large to manage in any useful way.
Bdale
pgpByuzPqnFQt.pgp
Description: PGP
Ian Jackson writes:
> Yes. I would still prefer to see something like that. I don't
> remember exactly what the objections were and I'm very very tired now
> but perhaps something like
>
> We expect that Debian will continue to support mkultiple init
> systems for the foreseeable future.
>
Russ Allbery writes:
> I *like* systemd, and I would still be very unhappy
> if a routine aptitude upgrade (or even a dist-upgrade) of a system
> currently running sysvinit suddenly resulted in running systemd without
> some sort of critical debconf question or the like.
Indeed.
Bdale
pgpFNkB
Josselin Mouette writes:
>> == optional rider M (Multiple init systems) ==
>>
>>Debian intends to support multiple init systems, for the
>>foreseeable future, and so long as their respective communities
>>and code remain healthy.
>>
>>Where feasible, software should interoperate
Petr Baudis writes:
> Would such a particular example of (greatly, but not fatally) degraded
> operation fall within the intent of this proposal?
I think so, yes.
I do think forcing users who've made a conscious decision to live this
way to click through a warning pop-up on each login is rath
Sergey B Kirpichev writes:
> I just wonder why nobody from tect-ctte take care about the exact
> specification of that "bare minimum" (or, in other words, what exactly
> is wrong with sysvinit).
In a sense, we all have done this, even if you don't see it explicitly
written in just this way.
T
Kurt Roeckx writes:
> So even if Colin would vote you couldn't beat the default option
> (FD), and all the other options would be dropped. As such I think
> the result is no longer in doubt and FD wins.
Thank you Kurt, this matches my understanding.
I therefore assert the ballot I called for
Ian Jackson writes:
> I think it doesn't make sense to allow people to require a non-default
> init. If you think it does then there are three possible answers to
> Q2: "requiring a specific init is permitted even if it is not the
> default one", "requiring the default init is OK but requiring a
Kurt Roeckx writes:
> I would like to point out that there is a quorum of 2, which has
> been reached, and that you have 1 week to vote.
Kurt,
It has been suggested to me that now that we have 4 votes for FD, that
this vote is effectively terminated regardless of whether I take action.
In your
Ian Jackson writes:
> I think there are the following three reasonable answers to Q1/Q2
> taken together.
>
> i. Q1: Multiple in >jessie
> Q2: Requiring specific init is forbidden
>
> ii. Q1: Multiple in >jessie
> Q2: Requiring default init is permitted
>
> iii. Q1: Single in jessie+
Ian Jackson writes:
> If we are I to vote now, I would like to see on the ballot at least:
If we choose to proceed with this kind of a vote, the combinations I
care about are adequately captured by this list.
I remain uncomfortable, however, about trying to be prescriptive about
what happens p
Ian Jackson writes:
> I hereby propose the following resolution:
>
>1. Support for sysvinit is mandatory in jessie.
>
>2. Debian intends to support multiple init systems, for the
> foreseeable future, and so long as their respective communities
> and code remain healthy. Noth
Ian Jackson writes:
> I hereby propose the following resolution:
>
> 1. The Technical Committee does not wish any resolutions it passes
> about the init system question(s) to stand in the face of any
> contrary view expressed by a majority of the Developers in a
> General Resolut
Don Armstrong writes:
> I think we should break the bigger question into this question plus
> additional advice for transition after we resolve this issue, but for me
> to vote things above FD, we should allow for a simple majority GR to
> vacate this decision.
Ok, you and Ian clearly both feel
Ian Jackson writes:
> Bdale Garbee writes ("call for votes on default Linux init system for
> jessie"):
>> I've spent much of the last few days pondering the current state
>> of the TC's init system debate, and what our next step(s) should be.
>
>
Ian Jackson writes:
> I thought we had agreed that the TC resolution would explicitly state
> that it would be overrideable by a simple majority.
>
> None of Bdale's options do that. Doing this with a later resolution
> which might or might not pass the TC is IMO unacceptable.
>
> I hope this om
I've spent much of the last few days pondering the current state
of the TC's init system debate, and what our next step(s) should be.
The original question posed to us in bug #727708 was to "vote on and
decide the default init system for Debian". Two things have become
clear to me in the ensuing
Bdale Garbee writes:
> Ballot:
>
> The default init system for Linux architectures in jessie should be
>
> 1. systemd
>
> 2. upstart
>
> 3. openrc
>
> 4. sysvinit (no change)
>
> 5. requires further discussion.
I vote 12345.
Bdale
pgplNPSOfvAd8.pgp
Description: PGP signature
Ian Jackson writes:
> I think this is a good idea. I have written a draft paragraph about
> the Canonical upstart CLA, in my most recent message to Keith.
>
> At the risk of feeding the horrible energy beast I think I need to try
> to propose some wording about these troublesome aspects of syste
Ian Jackson writes:
> Don Armstrong writes ("Bug#727708: Thoughts on Init System Debate"):
>> However, moving to a single supported init system with a defined
>interface is something that I would like to see.
>
> If you want that, and you want to keep the non-Linux ports, then I
> think you have
Andrew Shadura writes:
> It is actually fairly easy to write an initscript which uses native
> OpenRC facilities if they're available. While this serves little
> practical use, I tried to play with this, and this is the result:
Thanks for sharing that.
Bdale
pgpRO75eKg_7I.pgp
Description: PGP
Martin Pitt writes:
> But having more than $DEFAULT and
> sysv just boils down to "we can't make a decision".
I understand your point, but the more I learn about OpenRC the more
likely it seems to me that supporting it as an enhancement of sysvinit
makes sense as the "other" init system than jus
Adrian Bunk writes:
> There are at least three tricky areas:
>
> 1. init systems will have to cope with packages supplying init scripts
> in several formats they support.
This doesn't seem that tricky to me. If a package provides init
functionality in the preferred native format for a given in
Ian Jackson writes:
> I'm coming round to the view that we should be planning to support
> multiple systems indefinitely.
This has been my opinion all along. Various assertions that it's
somehow just too hard really haven't swayed me. The tricky bit, I
think, is to define just what "support" m
Russ Allbery writes:
> My inclination would be to give maintainers technical advice to accept
> integrations with either existing synchronization protocols, but leave it
> as technical advice rather than the binding part of the decision.
I strongly agree.
Bdale
pgpOJBZR_5XNx.pgp
Description:
Ian Jackson writes:
> Andreas, Bdale, Don, Keith: please let us know what you're thinking,
> and what more information/discussion would be useful.
Right. I've meant to post something before now, but after returning
home from a family road trip over the holidays, I was hit by a nasty
cold. Feel
Josselin Mouette writes:
> It shouldn’t come as a surprise that it is hard for developers to
> respect the TC’s decisions when we see disrespectful sentences like the
> one above from some of its members.
I agree.
We are of course each entitled to hold opinions about such things, but I
would st
Sjoerd Simons writes:
> While i don't have a good answer for your question, i did trigger me to
> have a look at popcon to see what that told me in terms of popularity of
> systemd vs. upstart.
Thank you!
Bdale
pgpPoSk59R79j.pgp
Description: PGP signature
Ian Jackson writes:
> Based on the responses to the recurring flamewars on debian-devel, I
> think the majority of contributors are happy not to have to wrestle
> with this decision and would prefer to leave it to us.
Agreed.
> Perhaps we
> should put (b) on the TC ballot for form's sake; I gue
Josselin Mouette writes:
> a friend of mine mentioned (not in a pub, but in a serious discussion
> about systemd & upstart) that he looked into upstart bugs more closely
Thanks to Jef for this work, the results and his comparison of some bugs
to systemd CVEs is quite interesting.
> However, I f
Josselin Mouette writes:
> There are two implied assumptions here:
> * that the same people are developing all components;
> * that develolpers have the same attention to code quality and
> security in all components they work on.
>
> I don’t think either of them applies to
Ian Jackson writes:
> There are three options: Packard, Kern and FD.
I vote:
1. Packard
2. Kern
3. FD
Bdale
pgpRPeugE5JDv.pgp
Description: PGP signature
1 - 100 of 236 matches
Mail list logo
