better
for portability in the long run anyway.
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
tell, the legal system does not operate that
way, and actual lawyers make distinctions based on harm/damages or lack
thereof.
I think Debian should take the position that Apache-2.0 and GPL-2.0-only
are compatible in practice.
[1] https://www.apache.org/licenses/GPL-compatibility.html
--
implementation details would almost certainly
vary) to what pytz upstream is doing in gen_tzinfo.py.
Michael Stone proposed:
C) Make python-tz depend on tzdata-legacy.
On 2025-04-08 12:37, Michael Stone wrote:
On Tue, Apr 08, 2025 at 12:08:05PM -0500, Richard Laager wrote:
I got bit (not in pytz
data..
Any opinions or recommendations?
I'd just depend on tzdata-legacy. I don't really understand why it was
decided to put some names in a separate package, but it's a small one
and if you need compatibility, that's what you need to do.
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
Holger Levsen writes:
> package: releasenotes
> x-debbugs-cc: debian-devel@lists.debian.org
>
> On Tue, Apr 01, 2025 at 03:27:05PM -0400, Michael Stone wrote
> Message-ID: <70ba7152-0f2e-11f0-9b6a-00163eeb5...@msgid.mathom.us>
> to debian-devel@l.d.o stating:
>
>> /run/utmp is no longer provided
Lee Garrett writes:
>> On Tue, 4 Mar 2025 20:39:43 -0500, "Helmut K. C. Tessarek"
>> wrote:
>>>Network interface name changed: please update config files before reboot.
> P.S.: This failure mode isn't even documented in the release notes.
This does seem to be correct given that the OP was upg
Guillem Jover writes:
> Hi!
>
> On Sat, 2025-02-01 at 22:33:16 +0100, Abou Al Montacir wrote:
>> On Sat, 2025-02-01 at 17:35 +0100, Abou Al Montacir wrote:
>> > But also, in this particular case, it's not the issue of the spec but of a
>> > particular tool trying to enforce the rule.
>> >
>> > I
Julien Plissonneau Duquène writes:
> Le 2025-01-24 13:00, Andrea Pappacoda a écrit :
>> Same for me. In addition, on the topic of making things easier for
>> new
>> contributors, when I first started using Salsa I felt lost in the
>> myriad
>> of features and options enabled by default. Not only
Crypticverse writes:
> Package: wnpp
> Severity: wishlist
> Owner: Crypticverse
> X-Debbugs-Cc: debian-devel@lists.debian.org, crypticvers...@gmail.com
>
> * Package name: linux-os-updater
> Version : 1.0.0
> Upstream Contact: Crypticverse
> * URL : https://github.co
Enrico Zini writes:
> [5] Do we have a thing that clones the running system into a throwaway
> VM?
systemd-nspawn claims to support this --
https://0pointer.net/blog/running-an-container-off-the-host-usr.html
Enrico Zini writes:
> today I decided to upgrade from bookworm to trixie/testing[1][2]. I ran
> the upgrade in a gnome-terminal, and of course all gnome terminals in
> the system crashed halfway through the upgrade[1][3].
not much consolation, but: i supose this is why the release-notes
recommen
Otto Kekäläinen writes:
>> >> i think the barrier is likely to be "i didnt know you could do that?"
>> >> rather than "how do i use that?"
>> >
>> > Salsa CI is and has always been opt-in.
>>
>> oops - i meant the oppposite, ie make people have to opt out of having
>> it run, rather than have to
Otto Kekäläinen writes:
> Hi!
>
>> > Salsa CI is a great system for all aspiring Debian packagers to test
>> > their packages before requesting review from mentors
>>
>> > However, as there are still packages not using Salsa CI, I wonder is
>> > it straightforward enough for everyone?
>> >
>>
>>
Otto Kekäläinen writes:
> Salsa CI is a great system for all aspiring Debian packagers to test
> their packages before requesting review from mentors
> However, as there are still packages not using Salsa CI, I wonder is
> it straightforward enough for everyone?
>
I think the best solution woul
Josh Triplett writes:
> Suppose that packages ship sample configuration files *that exactly
> match their defaults* (which should in general mean that everything is
> commented out) in some standardized path under /usr/share/doc/$package/
> (e.g. examples/etc), that makes it easy to see what pat
"Jonathan Dowland" writes:
> On Wed Dec 18, 2024 at 10:58 AM GMT, Henrik Ahlgren wrote:
>> Adding a couple of lines to the systemd unit should not add any new
>> dependincies to the package, or affect users of other init systems in
>> any way.
>
> That's a very good point. In which case that's li
Michael Tokarev writes:
> BTW, is there a way for a systemd unit to take/inherit (security) settings
> from
> another unit?
You might want to look at the examples here
https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/tree/main/systemd/system/postfix%40.service.d
(from Trent W. Buck
Bill Allombert writes:
> Le Thu, Dec 12, 2024 at 02:36:51PM +, Jonathan Dowland a écrit :
>> The "Perl Problem" is a wider issue we should explore in much more depth.
>> I'm personally a little surprised if it's true that younger people are
>> unprepared to take a stab at hacking Perl. But si
Tiago Bortoletto Vaz writes:
> Btw, for triage I used to suggest https://fabre.debian.net to
> newcomers. I had some hope that it could be a start for something
> bigger, so I tried to have access to the code to improve a few things
> but never had an answer from the maintainer :\
This looks lik
Gard Spreemann writes:
> While I personally think e-mail-based workflows can be quite nice, the
> BTS' asynchronous nature did cause me a lot of extra pointless work
> when I was an outsider attempting to learn the ropes. Being not 100%
> confident with the system, I way too often found myself wa
Andreas Tille writes:
> I wonder if we should reconsider the default assumption of package
> ownership.
(This is a reas objective, but) i wasnt sure how the following text would
achieve the above)
> Instead, we could introduce a file, such as
> debian/dont_touch_my_package (or a similarly named
Soren Stoutner writes:
> On Monday, December 2, 2024 9:32:27 AM MST Andreas Tille wrote:
>> Attracting newcomers
>>
>>
>> In my own talk[mt3], I regret not leaving enough time for questions--my
>> apologies for this. However, I want to revisit the sole question raised,
>> wh
duplicate checking, sorting, comparing.
That approach has an advantage for backwards compatibility: it works
with any existing usernames in the password file, regardless of how they
were encoded.
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
Otto Kekäläinen writes:
> Basically you can start by forking
> https://salsa.debian.org/agx/git-buildpackage on Salsa and then start
> hacking away on the things you want to improve.
>
> If you want to do Python coding, fixing this issue could be an easy
> one to start with:
> https://bugs.debian
Otto Kekäläinen writes:
> Please also help Guido iterate on git-buildpackage so that it works
> well, is easy to debug, has good docs etc. Based on discussions in
> this thread there are a lot of people with misconceptions and
> polishing the docs would be the best action item right now.
Happy
Niels Thykier writes:
> # The bug template used
>
> Severity: important
> User: ni...@thykier.net
> Usertags: rrr-no-as-default-issue
>
> Dear maintainer,
>
> During a test rebuild for building packages "Rules-Requires-Root: no" as
^
minor point, but a
"Philipp Kern" writes:
> On Sun Nov 24, 2024 at 4:45 AM CET, Otto Kekäläinen wrote:
>> To me the whole free and open source movement is about collaboration,
>> transparency and the ethos of "given enough eyeballs, all bugs are
>> shallow".
> The "given enough eyeballs" always happened after the
phil995511 - writes:
you say using backports is for advanced users yet you want users to be
able to choose their init systems? that's backwards. most users do not
care about the init system they use. adding backports and installing a
new kernel is not actually that difficult to do, and is easier
Marc Haber writes:
> For adduser's next release, I would like to discuss the following
> things:
>
> (1)
> Should Debian allow UTF-8 user names in the first place or should we
> restrict names for regular users to some us-ascii near set as well? (I
> think yes, we should)
would allowing utf-8 e
Jonathan carter writes:
>> https://surveys.debian.net/
I found the wording a bit confusing -- i expect you will get a lot of
votes in the reverse order to what is extended.
I suggest "ranking" and "choices" are a too similar: and the text seems
to use them backwards to normal usage in one place
Otto Kekäläinen writes:
> Hi all,
>
> I published a complete rewrite of the earlier draft as:
>
> https://salsa.debian.org/dep-team/deps/-/merge_requests/12
> DEP-18: Encourage Continuous Integration and Merge Request
> based Collaboration for Debian packages
>
> If you are in favor o
Mo Zhou writes:
> The tone can change: http://paste.debian.net/1335055/
> LLMs are being improved rapidly over time.
>
> I guess it's due to some potential safety issues so that LLM uses a dull
> corporate tone by default.
I think it's slightly misdiagnosed here. to me, it comes accross as
"tedi
Fay Stegerman writes:
> [Added diffosc...@lists.reproducible-builds.org to Cc]
>
> * Fay Stegerman [2024-11-06 17:43]:
>> * Johannes Schauer Marin Rodrigues [2024-11-06 02:28]:
>> [...]
>> > Have one package diffoscope and one package diffoscope-full and you could
>> > even
>> > have a package
I couldnt work out where to ask this: Are emails about packages being
removed from testing generated using stale data on what bugs are open?
(are im not complaining about the process just trying to understand it)
According to https://udd.debian.org/udd-status.cgi data on bugs is
updated a lot les
Marco d'Itri writes:
> On Oct 05, Simon Josefsson wrote:
>
>> I would like that 'apt install signify' install OpenBSD's signify (from
>> the Debian 'signify-openbsd' package) and not the 2003 mail-related
>> signify perl script from the Debian 'signify' source package.
> Agreed: the current sign
Lukas Märdian writes:
> On 23.09.24 12:27, Ansgar 🙀 wrote:
>> On Mon, 2024-09-23 at 12:22 +0200, Lukas Märdian wrote:
>>> On 22.09.24 15:58, Ansgar 🙀 wrote:
On Fri, 2024-09-20 at 13:12 +0200, Lukas Märdian wrote:
>>> The benefit that Netplan would provide in such cases is that
>>> debian-in
Lukas Märdian writes:
> On 04.09.24 17:26, Marco d'Itri wrote:
>> Do we even have general documentation about configuring networking?
>
> Yes, there is a "NetworkConfiguration" page on the wiki and the Debian ref:
>
> * https://wiki.debian.org/NetworkConfiguration
I dont thinj this page is usefu
PICCA Frederic-Emmanuel writes:
> What about dog fooding ?
>
> for now we can setup a schroot and sbuild very easily and start to build a
> local repository in minutes.
>
> But when it comes to install gitlab and the CI system it is another story. So
> we rely on the central salsa instance.
f
> My overall impression is that this is a bold attempt, but the document could
> do
> with some copy-editing to whittle it down, make it more focussed, and possibly
> narrow the scope. E.g. perhaps Gitlab CI is too much in one go? Could that be
> done further down the line in a follow-up DEP?
I
Bastien Roucariès writes:
>> b) but if im in a terminal (even if running in gnome) then i want a
>> terminal-based editor (based on what i installed)
>
> depends for me I prefer to run under emacsclient so you could do
> something like
> SENSIBLE_EDITOR='if [ -t 0 ]; then sensible-editor-GNOME ;
Bastien Roucariès writes:
> Sensible-editor could now use EDITOR="emacsclient -n -c" and accept
> that sh -c accept
>
> My goal is to create a sensible-editor.desktop that will lauch by
> default the sensible-editor of choice
>
> For this I plan:
> - to allow by alternative mechanism to have an s
Otto Kekäläinen writes:
> Could you point me to some Debian Bug # or otherwise share examples of
> cases when a build succeeded locally but failed on official Debian
> builders due to something that is specific for sbuild/schroot?
I believe both these uploads
https://tracker.debian.org/news/128
Russ Allbery writes:
> Simon McVittie writes:
>
>> I know fail2ban and logcheck do read plain-text logs (although as
>> mentioned, fail2ban already has native Journal-reading support too), and
>> I would guess that fwlogwatch, snort and xwatch probably also read the
>> logs.
>
> logcheck also ha
Simon McVittie writes:
> On Mon, 27 May 2024 at 03:29:53 +0100, Luca Boccassi wrote:
>> The list of affected packages according to apt-cache showpkg is not
>> that long either:
>>
>> logcheck
> However, for packages that want to read a traditional /var/log/syslog
> or similar, notably logch
Holger Levsen writes:
> I'm a bit surprised how many people seem to really rely on data in /tmp
> to survive for weeks or even months. I wonder if they backup /tmp?
I use /tmp for things that fall somewhere between "needs a backup" and
"unimportant, can be deleted whenever". I think all of the i
Luca Boccassi writes:
> qwhat would
> break where, and how to fix it?
Another one for you to investigate: I believe apt source and 'apt-get
source' download and extract things into /tmp, as in the mmdebootstap
example mentioned by someone else, this will create "old" files that
could immediately
Luca Boccassi writes:
> Hence, I am not really looking for philosophical discussions or lists
> of personal preferences or hypotheticals, but for facts: what would
> break where, and how to fix it?
- tmux stores sockets in /tmp/tmux-$UID
- I think screen might use /tmp/screens
I suppose if you
Luca Boccassi writes:
> On Mon, 6 May 2024 at 15:42, Richard Lewis
> wrote:
>>
>> Luca Boccassi writes:
>>
>> > Hence, I am not really looking for philosophical discussions or lists
>> > of personal preferences or hypotheticals, but for facts: what
Luca Boccassi writes:
> Hence, I am not really looking for philosophical discussions or lists
> of personal preferences or hypotheticals, but for facts: what would
> break where, and how to fix it?
cleaning /tmp or /var/tmp: users may lose files if they dont realise a
directory tmp can be clea
ispensable-geospatial-tool-you-didnt-know-you-were-missing/
Regards,
Richard Duivenvoorde
, but I also get why they may want
to restrict it.)
If Python is what you want, you could use waf, but there is one big
downside... You have to repack the upstream tarball:
https://wiki.debian.org/UnpackWaf
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
. It seems potentially confusing if some of the
relationships fields are included and some are not.
This proposal sounds generally good. I'll have to defer to others who
know more about potential corner cases.
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
Package: wnpp
Severity: wishlist
Owner: Richard Hansen
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: keyd
Version : 2.4.3
Upstream Contact: Raheman Vaiya
* URL : https://github.com/rvaiya/keyd
* License : Expat
Programming Lang: C
Helmut Grohne writes:
> I incline to agreeing with the scenario you depict. This can reasonably
> happen. I also think that David made a good case for it being unlikely
> to manage oneself into the buggy situation that way. And then the
> consequence is that you lost some possibly important files
Package: wnpp
Severity: wishlist
Owner: Richard Duivenvoorde
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: laz-perf
Version : 3.4.0
Upstream Contact: Howard Butler
* URL : https://github.com/hobuinc/laz-perf
* License : APLv2
Programming Lang
such a lintian check.
This repos from Trent Buck has a lot of research -
https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/tree/main/systemd/system/0-EXAMPLES
Indeed.
--
Richard
(strcmp(pathname, special) == 0) {
return;
}
}
unlink(pathname);
}
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
latively fixed (e.g. /bin, /usr/bin,
/lib), that might be workable.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
g that
should block the transition. By all means, transition and we will sort
things out.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
[ -e /etc/packagename ]
then
mv /var/lib/packagename /etc/packagename
fi
fi
fi
That said, I'm not sure what Policy has to say about this. It seems to
me that you want the package to do things right moving forward, and you
want to support clean upgrades, so this seems like the approach that
gets both of those.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
public
domain (at least not while it is still of useful/non-historical value).
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
ities Debian has for that. Would it be a
binNMU of everything?
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
o existing packages.
--
Richard
'ed in to ntpc.py
by the build process).
I hope that helps.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
frequently. Would they likely exceed 22 in the near
future? If so, you might just do 22.3+really10.0.0+dfsg+~cs16.6.17-1 and
when they get to 23, it goes back to normal, without the epoch.
--
Richard
On 4/27/22 12:57, Nilesh Patra wrote:
I am looking for more opinions.
Patch every instance of /srv/shiny-server to /var/lib/shiny-server. The
admin can customize from there.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
ftpmaster removal of src:ntp?
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
values the idea of using the pristine
upstream tarball. Granted, sometimes that goal has to yield to higher
priority things, like DFSG compliance.
How do you feel about the pristine tarball concept?
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
On 3/9/22 23:47, Marc Haber wrote:
On Wed, 9 Mar 2022 14:35:52 -0600, Richard Laager
wrote:
If the admin can change the default DIR_MODE that applies to system user
home directories, then any postinst script doing `adduser --system`
needs to also explicitly chmod its home directory if it
On 3/9/22 14:00, Marc Haber wrote:
On Tue, 8 Mar 2022 17:02:06 -0600, Richard Laager
wrote:
On 3/8/22 10:49, Marc Haber wrote:
(1a) would it be necessary to handle --system accounts differently? I
think yes. > (1b) should we stay with 0755 for --system accounts?
I don't
g with native format packages with Debian
revisions. They work just fine. For a small paockage, this is often
a good choice, because it avoids dealing with patches at all.
I don't follow the "avoid dealing with patches at all" piece here.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
(6)
#849265,
https://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/2017-January/032300.html
Should we really empty out the extra_groups list default?
With the exception of users, I wouldn't expect adduser to put people in
special groups by default. If those groups do nothing, I guess it's
moot. But in principle (and in the past), those groups give special
permissions and I would NOT expect that, nor want that.
--
Richard
On 1/19/22 15:04, Bernhard Schmidt wrote:
On 19.01.22 20:34, Richard Laager wrote:
2. I create transitional binary packages in src:ntpsec:
I got to thinking about this more. This won't work, because src:ntp is
1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch
ftp-master tool is relevant)
hard fail if going from non-date-based to date-based at the front of the
version string.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
On 1/20/22 8:04 AM, Thomas Goirand wrote:
On 1/19/22 20:34, Richard Laager wrote:
For people that want something more than systemd-timesyncd, e.g. to
get NTS, I think either are acceptable choices. It seems that the
consensus for new installs is towards chrony over ntpsec. But I don't
ide of the certificate validity period?
This is a concern too. I did some brainstorming about this on the NTPsec
list a couple years ago, but neither I nor anybody else has implemented
this (nor do I have plans to do so myself):
https://lists.ntpsec.org/pipermail/devel/2019-February/007576
;re going to promote chrony instead, then I think we need some
more discussion and there would be more work, as it seems we should
then replace systemd-timesyncd with chrony in default installs too.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
I decided it was better to use a different namespace. This
does mean that Debian ntpsec is patched and diverges a bit from upstream
NTPsec.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
obably a lot)
longer, until it's no longer reasonable to install a .deb containing
non-usrmerged paths (which might be old or from a third party).
Am I missing something here?
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
cmd to set CipherString, Ciphersuites, and MinProtocol per
$DAYJOB's general TLS policy. It may also be because of issues with
GnuTLS, I can't remember (and my comments/config messages don't indicate
that).
--
Richard
se. But
that's not the case right now and at this point, it's been ELEVEN YEARS.
It's time to move forward.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
On 10/7/21 11:35 AM, Russ Allbery wrote:
Richard Laager writes:
I haven't looked into the specifics of this situation, but in general,
tests should be run against the same versions of dependencies that the
actual code will use, for what should be obvious reasons. If Debian ha
ing time is low.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
On 9/28/21 11:49 AM, Vincent Bernat wrote:
❦ 28 September 2021 11:16 -05, Richard Laager:
As to what should be the distro default, I'm not sure I am convinced
either way, but to argue the other side... There is some value in
using netplan by default. Some random thoughts:
[...]
On 9/28/21 8:44 AM, Vincent Bernat wrote:
❦ 28 September 2021 01:29 -05, Richard Laager:
As to what should be the distro default, I'm not sure I am convinced
either way, but to argue the other side... There is some value in
using netplan by default. Some random thoughts:
[...]
ding this file from an Ansible template and
most of it (by volume) is built by loops.
In the trivial case, it's 19 lines of netplan (16 if you exclude the
stock comment) vs 25 lines of systemd-networkd, both in single files.
That's not a huge difference.
--
Richard
shes to
override the TC, they need to propose a GR.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
way. That
said, Debian Policy is not binding on them anyway.
If it _is_ harmful for /etc/shells to reference shells that do no exist,
then maintaining the list automatically (by whatever mechanism,
including the current approach but fixing the bugs) makes sense.
--
Richard
How close is upstream to 3.0? If not close, are they willing to bump to
3.0 anyway to avoid this versioning issue?
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
first discussed. Back then and today, agreed, it does not make sense
there.
IMO, it makes sense on both servers and desktops, so rather than
through tasksel, I would think it's a useful default to have on all
non-virtual installations.
Richard
I for now do not deny or admit officially. Marc, are you someone with
authority? I will clarify myself later, pretty lease
On wo, 2020-12-23 at 20:08 +0100, Marc Haber wrote:
> On Wed, 23 Dec 2020 19:43:18 +0100, Richard
> wrote:
> >I want to clarify I feel not up to seriously
I want to clarify I feel not up to seriously reading and thinking about
a response after a day of work, groceries and soms fastfood. But then I
saw master Geert responding in my topic. This I am glad to. I also want
to clarify, I amaware of both Humour and high level of intelect. I want
to learn fr
I have mailed a few official e-mails and some persons (surname@debian) i
have a request
On di, 2020-12-22 at 23:28 -0500, Calum McConnell wrote:
> On Tue, 2020-12-22 at 21:34 +0100, Richard wrote:
> > why no respond >:
>
> Sir,
> This is a volunteer organization. Any
why no respond >:
Package: wnpp
Severity: wishlist
Owner: Richard Lough
* Package name: golang-github-kubuxu-go-os-helper
Version : 0.0.1-1
Upstream Author : Jakub Sztandera
* URL : https://github.com/Kubuxu/go-os-helper
* License : Expat
Programming Lang: Go
Description
Package: wnpp
Severity: wishlist
Owner: Richard Lough
* Package name: golang-github-texttheater-golang-levenshtein
Version : 1.0.1-1
Upstream Author : Kilian Evang
* URL : https://github.com/texttheater/golang-levenshtein
* License : Expat
Programming Lang
;m not sure if additional text is
necessary to clarify this, especially since this isn't actually binding
on Kali anyway. But at the same time, I have no objection to that
additional text either.
--
Richard
signature.asc
Description: OpenPGP digital signature
ng term for that distinction in various places, including
dpkg-vendor.
--
Richard
signature.asc
Description: OpenPGP digital signature
Haloo Debian,
Ik heb wat e-mails verstuur den wil nu eindelijjk meedoen maar dan moet
iemand wel reageren op mijn e-mails?
Groeten,
Richard Waterbeek
Nederland
ersion of '1.1.0'
> So, I will need to add an epoch to the version to package it directly
> from its upstream repo.
Have you asked upstream if they would be willing to bump the version to
6.0 or something?
--
Richard
signature.asc
Description: OpenPGP digital signature
1 - 100 of 638 matches
Mail list logo
