in advance
bill
you*, as your reply fails entirely to even address the work that
> has been done and put right there in front of you.
Language please! Steve is right that you did not forward this to the
BTS. The email title says 'Bug#835520' but actually it was not
forwarded to bug #835520.
Cool down.
--
Bill.
Imagine a large red swirl here.
ies.
>
> > I'd personally probably not ship them,
> > and would instead provide non-PIC ones there. Or at most ship them in
> > addition as _pic.a libraries, to require explicit invocation.
>
> I'd rather not built everything twice, so I think I'll just drop the
> static libraries in the next upload and only worry about this again,
> when/if someone files a bug about missing the static libraries.
It is customary to build everything twice, one with -fPIC, one without.
Waiting for a bug report to do something is unfriendly to people using
the stable release.
Cheers,
--
Bill.
Imagine a large red swirl here.
s measurably slower than normal code.
The fact that the Debian default compiler generate slow code is quite annoying
for HPC and anything where performance comparaison are important.
At the very least this break the principle of leat surprise. -fPIE
should only be activated by default when building Debian package, not
for users compiling their own code.
Cheers,
--
Bill.
Imagine a large red swirl here.
help with delayed
> NMUs where we can), we'll upload the changed emacs-defaults package to
> sid and then try to help with any further issues.
Hello Rob,
Do you realize the freeze is in one week, and that lot of people are
in holiday during this week ?
Cheers,
--
Bill.
Imagine a large red swirl here.
On Wed, Dec 28, 2016 at 02:19:26PM -0600, Rob Browning wrote:
> Bill Allombert writes:
>
> > Do you realize the freeze is in one week, and that lot of people are
> > in holiday during this week ?
>
> My understanding is that the upcoming freeze is for the addition of new
On Sun, Jan 01, 2017 at 12:09:14AM -0800, Russ Allbery wrote:
> * Policy: [4.3] update autotools during build time
> Wording: Bill Allombert
> Seconded: Niels Thykier
> Seconded: Andreas Barth
> Closes: #746514
The title does not reflect what my wording is a
d become two in the future once
> DebianDoc-SGML is converted to Docbook.
Thanks Guillem, I would very happy to get rid of the emacs dependency.
Cheers,
--
Bill.
Imagine a large red swirl here.
orry about the main Policy
> document, which presumably would be harder, in a later release.
I am concerned that DocBook is much too complex to be used for Debian policy.
We need to people to write patches without trouble and we do not have
many editors available for fixing the XML. Debiandoc-SGML virtue is that
it is simple.
Cheers,
--
Bill.
Imagine a large red swirl here.
others.
This is rather opposite goals.
Cheers,
--
Bill.
Imagine a large red swirl here.
DPL".
>
> How many of the current policy editors expect to be present at DebCamp
> this year? How about organising a sprint to handle the current backlog?
> This would raise everyone's spirits about making progress with Policy.
> I would love to be involved.
Alas
build packages
reproducibly with an interface like cowbuilder.
Currently, there are too much uncertainty about the process for bug
reports to be of severity normal.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Sun, May 14, 2017 at 02:36:46PM +, Holger Levsen wrote:
> On Thu, May 11, 2017 at 02:42:43PM +0200, Bill Allombert wrote:
> > I really think there should be an official tool to do build packages
> > reproducibly with an interface like cowbuilder.
>
> the official t
On Sun, May 14, 2017 at 02:58:27PM +, Holger Levsen wrote:
> On Sun, May 14, 2017 at 04:51:47PM +0200, Bill Allombert wrote:
> > > the official tool to build packages reproducible in sid is called
> > > "dpkg-buildpackage" (since dpkg 1.18.16 in sid since 2016
On Sun, May 14, 2017 at 03:20:54PM +, Holger Levsen wrote:
> On Sun, May 14, 2017 at 05:05:36PM +0200, Bill Allombert wrote:
> a.) go to http://reproducible.debian.net/$srcpkg and see if its reproducible
> today.
As I said, I would like to check that my package build is reproducible
On Sun, May 14, 2017 at 11:15:26PM +, Holger Levsen wrote:
> On Mon, May 15, 2017 at 12:05:17AM +0200, Bill Allombert wrote:
> > On Sun, May 14, 2017 at 03:20:54PM +, Holger Levsen wrote:
> > > On Sun, May 14, 2017 at 05:05:36PM +0200, Bill Allombert wrote:
&g
a minimal debian/rules file.
> - Move the doc-base registration files into debian with *.doc-base names.
>
> My guess is that nearly no one will care, but if I'm missing some reason
> not to do this, please let me know.
What we should really do is to remove the build-dependency on emacs which
cause trouble.
Cheers,
--
Bill.
Imagine a large red swirl here.
sal.
Cheers,
--
Bill.
Imagine a large red swirl here.
all supported /bin/sh are actually
compliant with v4.2.
Cheers,
--
Bill.
Imagine a large red swirl here.
eed to be listed to check
whether this can affect any shell script that rely on SUSv3
Cheers,
--
Bill.
Imagine a large red swirl here.
symbols).
> + This priority is deprecated, but may be used to denote packages
> + that are unlikely to be useful even for most users interested
> + in their general field.
Before anything, we should ask the ftp masyer whether they consider the
policy group or themselves responsible for setting the priority.
Cheers,
--
Bill.
Imagine a large red swirl here.
by packages.
So we shoud first ask the FTP master whether they consider that the
priorities are defined by them or by the policy, and if they are willing
to change the override file to adjust.
Cheers,
--
Bill.
Imagine a large red swirl here.
t of the box (build-depends on xmlto
> > and
> > fop). Perhaps it would deserve its own package ?
>
> I would like to see FHS 3.0 adopted as well. Or an 2.3 exception to
> allow the use of /usr/libexec.
I assume if we allow /usr/libexec, we also need to support
/usr/libexec/x86_64-linux-gnu/ etc. ?
Cheers,
--
Bill.
Imagine a large red swirl here.
this is consistent with the devref, since
it covers the same ground.
Cheers,
--
Bill.
Imagine a large red swirl here.
lid information about the effective maintainers.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Sat, Jul 15, 2017 at 07:18:41AM -0700, Sean Whitton wrote:
> Hello Bill,
>
> On Sat, Jul 15, 2017 at 02:48:36PM +0200, Bill Allombert wrote:
> > The problem is that the majority of such documentation is outdated and
> > obsolete to the point of being useless.
> > M
seconds. This assuming the writer endorce the
proposal, but this is always the case in practice.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Tue, Aug 01, 2017 at 04:23:05PM -0400, Sean Whitton wrote:
> Hello,
>
> I second Charles' patch.
Please always quote what you are seconding. This avoid confusion.
Cheers,
--
Bill.
Imagine a large red swirl here.
", which is not true of a lot of teams.
You are omitting the case of a team which get reduced to a single
member, in which case the package need not be orphaned. Yet it is
important the fact is mentionned in the package.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Wed, Aug 02, 2017 at 04:22:41PM -0700, Russ Allbery wrote:
> Bill Allombert writes:
> > On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
>
> >> I've also included a purely informative change which emphasises that
> >> packages that are tea
So I'm seeking seconds for the following replacement for
> Andreas' 5th and 8th patches:
In general, policy paragraph mentioning debhelper features are moved to
footnotes.
Cheers,
--
Bill.
Imagine a large red swirl here.
> the bug against the package, and not against wnpp.]
>
> In N days, the bug can be filed against
Nowadays orphaning is done by reuploading the package with the
maintainer set to the QA group rather than using a O: wnpp bug.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Sat, Aug 05, 2017 at 01:55:01AM +0500, Andrey Rahmatullin wrote:
> On Fri, Aug 04, 2017 at 10:46:19PM +0200, Bill Allombert wrote:
> > On Fri, Aug 04, 2017 at 11:59:40AM -0700, Don Armstrong wrote:
> > > > An O: bug means that it is confirmed that the package is orphan
get that it would work 90% of package ?
Using [] for non-team members is very common.
Cheers,
--
Bill.
Imagine a large red swirl here.
the Maintainer field, even in the cases where
> they are actively and regularly monitored, appears to violate the
> spirit of Section 3.3 which stipulates a "working email address".
How do you define "moderated" ?
Cheers,
--
Bill.
Imagine a large red swirl here.
On Fri, Aug 11, 2017 at 07:53:51AM -0700, Sean Whitton wrote:
> Version: 3.9.4.0
>
> We believe this was fixed in a recent release.
What make you believe that ?
Cheers,
--
Bill.
Imagine a large red swirl here.
is require policy to define the build environment and build
instruction much more precisely than it does now, which does not
seems to be practical. Unless maybe if a reference implementation
is provided.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Tue, Aug 08, 2017 at 08:06:46PM -0400, Chris Lamb wrote:
> Hi Bill,
>
> > How do you define "moderated" ?
>
> I can't really, sorry. I guess getting a "Your message awaits moderator
> approval" quasi-bounce… but that's not exactly right.
I
fferent concept that deserve a different name.
Cheers,
--
Bill.
Imagine a large red swirl here.
able way for maintainers
to check whether a package is reproducible according to policy before
uploading it to the archive.
Cheers,
--
Bill.
Imagine a large red swirl here.
r report you
cannot reproduce, do some change following the help provided and
hope for the best. Then some day later you get the same error
report.
Cheers,
--
Bill.
Imagine a large red swirl here.
m concerned we are putting the cart before the horse.
Cheers,
Another Policy Editor (a delegated position).
--
Bill.
Imagine a large red swirl here.
timestamps honour
SOURCE_DATE_EPOCH.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Wed, Aug 16, 2017 at 12:19:47PM -0700, Don Armstrong wrote:
> On Wed, 16 Aug 2017, Bill Allombert wrote:
> > But as a technical document, it is lacking practical recommendation
> > for maintainers how to make sure their package build reproducibly
>
> The practica
On Wed, Aug 16, 2017 at 05:40:23PM -0700, Chris Lamb wrote:
> Hi Bill,
>
> > Now compare with reproducible build. You get some error report you
> > cannot reproduce, do some change following the help provided and
> > hope for the best. Then some day later you get t
workflow to try to
> standardize.)
How do you plan to instruct uscan how repacking should be done ?
To me, having a debian/rules target seems the correct think to do.
(That is what I do with my packages with comple repacking.)
That said, maybe the shell magic that could be moved inside uscan.
Cheers,
--
Bill.
Imagine a large red swirl here.
upported in source control files but not in the binary
> > ones?
Maybe a better way to say that is that it is only supported in
debian/control, and not in files generated from it, including .dsc.
We already had this discussion in another bug report.
Cheers,
--
Bill.
Imagine a large red swirl here.
o not need that. Watch files could not do
that until recently.
So the comparaison is unfair.
What need to be checked is how many get-orig-source rules has been
reimplemented in term of watch files.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Mon, Sep 18, 2017 at 12:38:49PM +0200, Helmut Grohne wrote:
> On Mon, Sep 18, 2017 at 11:28:42AM +0200, Bill Allombert wrote:
> > get-orig-source and watch files serve a different purpose.
> >
> > get-orig-source is used to build the .orig. tarball from the true
> >
want policy
to read like legalese, we need to accept minor ambiguities in wording
that can be resolved from the rationale.
Cheers,
--
Bill.
Imagine a large red swirl here.
ith you, what are the practical negative effect of
putting the 4th digit in the Standards-Version field ?
Lintian could easily be made to flag it, but is it worth the trouble ?
Cheers,
--
Bill.
Imagine a large red swirl here.
four?"
Doing that would be lead to the removal of four digits by maintainers
for all practical prupose. Nobody is going to add a lintian exception
for this. If four digits are fine, then lintian whould not warn against
them.
Cheers,
--
Bill.
Imagine a large red swirl here.
ce package, but documentation-only binary packages may be
> nearly empty when built with this option." [2]
>
> I don't think there is any benefit to anyone from empty -doc packages.
What about packages that depend on -doc packages ?
They might become uninstallable.
Cheers,
--
Bill.
Imagine a large red swirl here.
nclude the relevant
extract from the changelog and do not miss packaging change because
they where listed in unreleased versions and dpkg-genchanges -v
was not used properly.
Cheers,
--
Bill.
Imagine a large red swirl here.
duced
and see whether the package is actively maintained upstream and in
Debian. Also I read it to my children before putting them to bed.
Cheers,
--
Bill.
Imagine a large red swirl here.
ather than putting things called 'editor'
> > and 'pager' into PATH.
>
> I understand and agree, but that doesn't mean that packages should
> invoke editor using an absolute path.
>
> Policy describes package behavior, not user behavior.
>
> Further, a sysadmin on a shared machine doesn't have a way to set
> EDITOR for all users,
Why not ? PAM can do it, see /etc/environment?
Cheers,
--
Bill.
Imagine a large red swirl here.
gt; Seconded.
Before we make it a must, is there a lintian test for it ?
How may packages need to be fixed ?
Cheers,
--
Bill.
Imagine a large red swirl here.
On Mon, Nov 27, 2017 at 02:08:37PM -0700, Sean Whitton wrote:
> Hello Bill,
>
> On Mon, Nov 27 2017, Bill Allombert wrote:
>
> > Before we make it a must, is there a lintian test for it ?
>
> I am not sure.
>
> > How may packages need to be fixed ?
>
&g
On Mon, Nov 27, 2017 at 09:10:12PM +0100, Bill Allombert wrote:
> On Mon, Nov 27, 2017 at 11:34:15AM -0600, Gunnar Wolf wrote:
> > Sean Whitton dijo [Sat, Oct 14, 2017 at 11:49:59AM -0700]:
> > > I am seeking seconds for the following patch to close this bug, which I
> > &g
hat all changelog are useless, and by removing them we
discourage upstream of producing useful changelog.
git log might be more useful in some situation and extremly inconvenient
in some others (to start with it require network access and cloning
the full project history).
The ability to extract upstream changelog from .deb is useful.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Thu, Nov 30, 2017 at 08:45:51PM -0800, Russ Allbery wrote:
> Bill Allombert writes:
>
> > git log might be more useful in some situation and extremly inconvenient
> > in some others (to start with it require network access and cloning the
> > full project history).
&
h_installchangelogs can do is to install
everything that looks like a changelog or a NEWS file.
However, I am concerned that having dh_installchangelogs removing files will
lead to less predictability.
Cheers,
--
Bill.
Imagine a large red swirl here.
GPL-2``,
> > ``/usr/share/common-licenses/GPL-3``,
>
> Seconded.
So, what is the percentage of packages under this license ?
This has always been the criterium used to put it in common-licenses.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Sat, Dec 09, 2017 at 10:26:26AM -0700, Sean Whitton wrote:
> Hello Bill,
>
> On Sat, Dec 09 2017, Bill Allombert wrote:
>
> > So, what is the percentage of packages under this license ? This has
> > always been the criterium used to put it in common-licenses.
>
&
On Sat, Dec 09, 2017 at 11:53:51AM -0700, Sean Whitton wrote:
> Hello,
>
> On Sat, Dec 09 2017, Bill Allombert wrote:
>
> > See the file tools/license-count in the policy git repo and look up
> > the debian-policy list archive for previous statistics.
>
> Thank
ng distribution but it always offer both source
and binary.
The client is performing downloading and copying. It is its choice to
download binaries only.
However: this covers the GPL clause about source distribution, but it
might not satisfy the MIT "include in all copy" clause beca
ld write a script to generate the copyright file.
In any case, before going farther with this we need a run of
tools/license-count.
Cheers,
--
Bill.
Imagine a large red swirl here.
ieve the proposal in this bug report can be
> implemented quite easily without conflating the automated tools idea.
Plese remember that there is no requirement to use copyright-format-1.0.
If you feel that copyright-format-1.0. is a burden rather than a help,
do not use it.
Cheers,
--
Bill.
Imagine a large red swirl here.
have been included in the first place
(it was expected that more packages would migrate from 1.2 to 1.3).
So it makes better sense to count GFDL 1.2+1.3 as a single number.
The usual threshold for inclusion was much higher than 138.
Cheers,
--
Bill.
Imagine a large red swirl here.
ig-source target from policy is that it will appear in some
debian/rules but not be documented anymore. I do not see how this can
be helpful to newcomers. They will still be exposed to it without having
the documentation in policy.
It would be more useful to kept it but to add a note toward migrating to
uscan if possible.
Cheers,
--
Bill.
Imagine a large red swirl here.
n the other hand it should not be done in NMU, because some
maintainers use this field to track of far they checked the
upgrading-checklist file for this package.
So I agree that updating S-V should never block uploading other
improvements.
Cheers,
--
Bill.
Imagine a large red swirl here.
deb files
that did not include the copyright file.
However your proposal has the benefit of avoiding spurious circular
dependencies caused by the symlink option.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Wed, Feb 07, 2018 at 02:32:55PM +0100, Bill Allombert wrote:
> On Wed, Feb 07, 2018 at 01:43:08PM +0100, Javier Serrano Polo wrote:
> > Package: debian-policy
> > Version: 4.1.3.0
> > Severity: wishlist
> > X-Debbugs-CC: a...@debian.org, ballo...@debian.org,
>
On Wed, Feb 07, 2018 at 06:56:59PM +0100, Javier Serrano Polo wrote:
> X-Debbugs-CC: a...@debian.org, ballo...@debian.org, spwhit...@spwhitton.name,
> r...@debian.org
>
> El dc 07 de 02 de 2018 a les 17:31 +0100, Bill Allombert va escriure:
> > ... However will have to have a
gt; but…)
You can also download policy from
https://www.debian.org/doc/debian-policy/policy.txt
(there seems to be missing a link to policy-1.html)
Cheers,
--
Bill.
Imagine a large red swirl here.
On Fri, Mar 02, 2018 at 07:56:40PM +0530, Pirate Praveen wrote:
> Node.js expects pure js modules to be installed at /usr/lib/nodejs but
> javascript libraries are installed at /usr/share/javascript
Why should pure js module be in /usr/lib instead of /usr/share ?
Cheers,
--
Bill.
Ima
s?
You should not embed them. Instead you can merge several tiny
modules together and ship them as a single .deb, which eventually
Provides: node-mod1, node-mod2 etc. So package can still Depends on the
individual names.
Cheers,
--
Bill.
Imagine a large red swirl here.
re policy allows for both
behaviour. This way, debhelper can be updated without breaking policy
and developers would have a reference for the new behaviour.
Then the old behaviour is deprecated.
Cheers,
--
Bill.
Imagine a large red swirl here.
d to provide a script debian/get-orig-source .
I wonder, maybe uscan could support debian/get-orig-source as a last
resort ?
Cheers,
--
Bill.
Imagine a large red swirl here.
On Wed, Apr 11, 2018 at 03:49:17PM +0100, Ian Jackson wrote:
> Bill Allombert writes ("Re: Bug#515856: Debian Policy 4.1.4.0 released"):
> > I wonder, maybe uscan could support debian/get-orig-source as a last
> > resort ?
>
> Only if you pass --trust-source o
agged by lintian, but does not need to appear in policy.
Most of the time it will be an oversight or caused by a change in
external dependencies, so it is worthwhile to notify the maintainer,
but does not need to be in policy.
Cheers,
--
Bill.
Imagine a large red swirl here.
I violate any
> laws?" What am I to answer? "I don't know"?
Lintian is not a policeman, more like the helpful person that knock to
your window to tell you your left-rear tyre is flat.
> Can I answer "No you are not. I am just telling you anyway."
Yes, you can.
Cheers,
--
Bill.
Imagine a large red swirl here.
ependencies) and there should be an option for non
transitive Recommends (install Recommends but not Recommends of
Recommends).
Cheers
--
Bill.
Imagine a large red swirl here.
as the Debian Policy group.
Cheers,
--
Bill.
Imagine a large red swirl here.
ive to require them to be implemented at the same time.
Also probably not all package are relevant for the new requirement
anyway.
I rather read it as a basic QA check: if a package carries a 5-year old
std-ver, probably it is not maintained anymore.
Cheers,
--
Bill.
Imagine a large red swirl here.
> Any objections to dropping singlepage html output completely, until a
> future date at which Sphinx upstream has improved it?
If you do that, then do not close the bugs related to policy-1.html
because they will still be valid, and report a bug 'policy-1.html is
missing'.
The policy-1.html has the nice property that it is easy to search the
whole document.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Sun, Jun 10, 2018 at 03:01:51PM +0200, Bill Allombert wrote:
> On Sun, Jun 10, 2018 at 01:37:11PM +0100, Sean Whitton wrote:
> > Hello all,
> >
> > On Mon, Dec 25 2017, Russ Allbery wrote:
> >
> > > I'm not sure where we landed with this, but it fee
On Sun, Jun 25, 2017 at 11:28:11PM +0100, Simon McVittie wrote:
> On Sun, 25 Jun 2017 at 22:37:04 +0200, Bill Allombert wrote:
> > I assume if we allow /usr/libexec, we also need to support
> > /usr/libexec/x86_64-linux-gnu/ etc. ?
>
> I'm not sure I see why we would? Pl
(my emphasis), which is a fairly common bit of en_DE. I assume it's
> a literal translation of something that's correct in German?
This is also common in en_FR, so it is probably valid in en_EU.
The English passive forms rules are awkward for latin speakers.
It is common to use the latin passive forms rules in en_EU.
Cheers,
--
Bill.
Imagine a large red swirl here.
are dropped in filenames. I'm
> afraid I stand by that decision.
While I agree with the consultation requirement, the epoch in filename
is a different issue. The only reason I saw mentinned was that using
':' was problematic. However why not use another separator then ?
Cheers,
--
Bill.
Imagine a large red swirl here.
; section for that matter).
As a rule, sections are decided by the FTP masters and not by Debian
policy.
Cheers,
--
Bill.
Imagine a large red swirl here.
ME.source can
be useful.
Cheers,
--
Bill.
Imagine a large red swirl here.
Could you switch the web mirrors to use the multipage version, please?
> Then I can drop the file from our releases.
>
> If Sphinx upstream improves the singlehtml output sufficiently that we
> decide to include it in our package again, I don't think we'd want to
> change the web mirrors again.
Why we would not want that ?
Cheers,
--
Bill.
Imagine a large red swirl here.
controlsyntax`.
> > >
> > > - :ref:`Dgit `
> > >
> > > -- :ref:`Standards-Version ` (recommended)
> > > +- :ref:`Standards-Version ` (mandatory)
> > >
> > > - :ref:`Build-Depends et al `
>
> seconded.
Seconded.
Cheers,
--
Bill.
Imagine a large red swirl here.
signature.asc
Description: Digital signature
For example pari-gp include both changelog.gz and NEW.gz and both are
potentially useful to users without a copy of the source.
Cheers,
--
Bill.
Imagine a large red swirl here.
signature.asc
Description: Digital signature
On Mon, Jul 23, 2018 at 07:50:59AM +0800, Sean Whitton wrote:
> Hello Bill,
>
> On Sun 22 Jul 2018 at 07:45PM +0200, Bill Allombert wrote:
>
> > I have to disagree with that recommendation. It all depends on how the
> > changelog is worded. Since we do not include a
vel changelog).
In that sense, the latest draft of Sean is a step in the right direction.
I might be wrong, but I do not think the majority of upstream changelog
are source-level changelog, except for GNU software. Changing debhelper
not to install upstream changelog by default will likely create more
bugs than it will fix.
Cheers,
--
Bill.
Imagine a large red swirl here.
hat statement, only to find packages being rejected from NEW because
> their copyright files did not include license grants. We need to be
> sure.
I completely agree with Sean. This is a matter where policy must defer
to the ftp-master team.
Cheers,
--
Bill.
Imagine a large red swirl here.
dency is needed.)
> >
> FWIW I disagree, I expect this is rather nice usage and so requiring a
I assume you mean niche usage.
> build-dep on netbase for the few packages that need this isn't a
> problem. Plus, these files being conffiles means you can't actually
> rely on finding anything specific in there anyway.
Yes this is something I am concerned too.
Cheers,
--
Bill.
Imagine a large red swirl here.
t that sad truth is that the real issue is not that users do not use
doc-base, but rather that they do not use the documentation provided in
Debian in the first place, and instead reach to Google to locate some
documentation online (which might not be for the same version,
leading to conflict with upstream) ]]
Cheers,
--
Bill.
Imagine a large red swirl here.
1 - 100 of 1106 matches
Mail list logo
