clean-source?
Thanks,
Scott
Hello everyone,
(TL;DR at the end)
I've mostly been lurking on Debian mailing lists for a long time, so if you
don't know me, I'm John, a Debian Maintainer working on a couple cross
toolchains for building the device firmware that *is* free from source, but I
pitch in on many packages here and
AIR and if things have not changed?) source
>package renames do not go through NEW. That you can take over (also
>AFAIR if things have not changed) a binary package from another source
>package. And that binaries no longer produced by any source get
>automatically garbage collected (https://wiki.debian.org/Glossary#nbs).
>
>So depending on the timelines, the process could be reduced by staging
>the binary package moves/take-overs and source package renames in
>different ordered uploads.
They do go through New.
Scott K
On September 5, 2024 3:39:35 PM UTC, Andreas Tille wrote:
>Hi,
>
>Am Wed, Sep 04, 2024 at 11:29:39PM -0400 schrieb Scott Kitterman:
>> On Wednesday, September 4, 2024 6:22:14 PM EDT Pierre-Elliott Bécue wrote:
>> >
>> > OoC, what is your point, especially
On Wednesday, September 4, 2024 6:22:14 PM EDT Pierre-Elliott Bécue wrote:
> Scott Kitterman wrote on 04/09/2024 at 06:23:50+0200:
> > On Monday, September 2, 2024 11:23:30 AM EDT Andreas Tille wrote:
> > ...
> >
> >> While I’ve read several emails in agreement, Sco
On Monday, September 2, 2024 11:23:30 AM EDT Andreas Tille wrote:
...
> While I’ve read several emails in agreement, Scott Kitterman made a
> valid point[ru4]: "I don't think we need more process. We just need
> someone to do the work of finding the packages and filing the bu
On August 20, 2024 12:16:47 PM UTC, Andrey Rakhmatullin wrote:
>On Tue, Aug 20, 2024 at 12:12:33PM +0000, Scott Kitterman wrote:
>> >Removing packages that aren't formally orphaned always sounds too bold to
>> >me, though it should be fine if we formalize a process
uite reasonable in that regard).
There are people doing this, we could use more, but it does happen. I've
processed lots of these and it's virtually always fine. In the rare case of a
mistake, the cost to rectify the mistake is a trip through New.
I don't think we need more process. We just need someone to do the work of
finding the packages and filing the bugs.
Scott K
P.S. FTP Team member, but not speaking for the team.
A
>version numbers in such a way that packages from those repositories can be
>used interchangeably.
>
I would suggest that you work with upstream on how they will version things in
the future, so you aren't bumping the epoch every year.
Scott K
ppropriate?
Yes. I don't think this is it.
A sane version is one that's higher than the last one. If upstream wants the
last one to include their versioning from non-Debian packages, they can do
that. If they don't want to, that's fine, but I don't think we should either
then.
Scott K
On Monday, July 1, 2024 7:07:16 PM EDT Alec Leamas wrote:
> On 02/07/2024 00:54, Scott Kitterman wrote:
> > On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:
> >> If you switch hats for a moment: have you any advice for upstream in
> >> this situation?
> >
On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:
> On 02/07/2024 00:31, Scott Kitterman wrote:
>
> HI again
>
> > On July 1, 2024 10:18:07 PM UTC, Alec Leamas
wrote:
> >> But here the situation is that upstream do care and wants to fix it. But
> >&
On July 1, 2024 10:18:07 PM UTC, Alec Leamas wrote:
>On 02/07/2024 00:10, Scott Kitterman wrote:
>
>Hi Scott,
>
>> Upstream can change the versioning however they want. They are upstream. If
>> they don't care to fix it, then I think we assume they are fine
favor of something sane. But the legacy is
> there, and we need to handle it.
>
> Have considered tricks like adding a 1. prefix to the debian/ubuntu
> versions. But to me, this looks even worse.
>
> Thoughts?
Upstream can change the versioning however they want. They are upstream. If
they don't care to fix it, then I think we assume they are fine with it and
leave it as is.
Scott K
signature.asc
Description: This is a digitally signed message part.
On May 26, 2024 6:14:40 PM UTC, Bastian Blank wrote:
>On Sun, May 26, 2024 at 05:43:54PM +0000, Scott Kitterman wrote:
>> On May 26, 2024 5:35:27 PM UTC, Santiago Vila wrote:
>> >https://people.debian.org/~sanvila/build-logs/trixie-time-bomb/
>> The clamav issue loo
ck at 2028-06-10 and built trixie/sid on such date,
>and found around 50 packages with time bomb issues of all kinds. A preliminary
>list of build logs is available here:
>
>https://people.debian.org/~sanvila/build-logs/trixie-time-bomb/
The clamav issue looks like a false positive. The distro-info data will get
updated between now and then.
Scott K
from Debian which don't conform
to a specific layout (in my mind, that's the implication of mandating it)?
Scott K
;t know if that is * official* enough for
you or not.
No, I don't know when DSA will upgrade it. It's a matter of coordination
between DSA and the FTP Team that I haven't personally been involved in.
Scott K
Package: wnpp
Severity: wishlist
Owner: Scott Kitterman
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-gfloat
Version : 0.1
Upstream Contact: Andrew Fitzgibbon
* URL : https://github.com/graphcore-research/gfloat
* License : Expat
Package: wnpp
Severity: wishlist
Owner: Cody Scott
X-Debbugs-Cc: debian-devel@lists.debian.org, cody.sc...@giatec.ca
* Package name: python3-pyzmq
Version : 25.1.2
Upstream Contact: ZeroMQ
* URL : https://pyzmq.readthedocs.io/en/latest/
* License : BSD
Package: wnpp
Severity: wishlist
Owner: Cody Scott
X-Debbugs-Cc: debian-devel@lists.debian.org, cody.sc...@giatec.ca
* Package name: python3-atcom
Version : 0.4.3
Upstream Contact: Sixfab
* URL : https://pypi.org/project/atcom/
* License : Apache Version 2.0
le.
I have all my packages in git on salsa. Mostly I find it not that helpful to
me, but I know others value it, so I do it (and for the occasional benefits it
provides me). I think I would feel pretty strongly about not continuing to do
so if someone told me I had to.
Scott K
ve to deal with that.
If something's broken (in a violates policy, breaks things for the user kind
of way), I don't mind NMUs if I'm not paying attention (that does happen
sometimes), but the original maintainer of postfix (lamont) made some
opinionated choices about the package
to be removed?
>
>[1] https://tracker.debian.org/pkg/nifticlib
Because the bug still exists in Testing. Once the package in Unstable
migrates, all is well.
Scott K
SN
lookups, so not very accurate either. I would definitely encourage you to work
with upstream to find a more unique and less inaccurate name before packaging
this.
Scott K
here there's already a version of the package in
experimental (this applies to clamav where we are tracking the latest, non-LTS
version in experimental)?
Scott K
On Wed, 31 Jan 2024, Jonas Smedegaard wrote:
Quoting Scott Talbert (2024-01-31 16:49:59)
On Wed, 31 Jan 2024, Jonas Smedegaard wrote:
Unfortunately it is not likely that the package will be catch up soon,
because the Haskell team upgrade most Haskell libraries only as a whole.
That issue is
use of debbugs:
https://lists.debian.org/debian-haskell/2024/01/msg00012.html
Note: I don't discourage usage of debbugs. It's just that I'm unlikely to
notice bugs immediately due to the way debbugs notifications work.
Scott
tions on services (DBus services, DBus
>itself, daemons, ...).
>
>A quick poll on IRC in #-devel seemed to show a majority of people who
>responded agreeing with this.
>
>(This does not have to apply to libnss-* or libpam-* which are not
>actually libraries, but plugins.)
>
>Ansgar
I think this is correct. I believe the appropriate relationship is Suggests.
Scott K
On September 29, 2023 10:01:45 AM UTC, Adam Borowski
wrote:
>On Thu, Sep 28, 2023 at 03:45:14PM +0000, Scott Kitterman wrote:
>> On September 28, 2023 3:22:20 PM UTC, Bastian Germann
>> wrote:
>> >Okay. What do you suggest for "team maintained" packages
cannot even NMU them based on the MIA bug.
>
>I think, just letting such packages rot for one or two decades does not help
>anybody, certainly not our users.
>
Any team member can orphan the package.
Scott K
We
recently had #1050053 [1] filed suggesting we change the Recommends on fonts-
noto-unhinted to "the appropriate package" since it's now empty. No idea what
that would be though. Suggestions welcome.
Scott K
{1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050053
signat
n plakativ, I
>wanted to ask here what the canonical way is to fix this issue?
Generally something like this (although depending on the Python build tool, it
may need some adjustment):
https://salsa.debian.org/python-team/packages/dkimpy/-/commit/bf39be7563b680bdc73a67a4db7dc1af05af
Scott K
d with rebuilding the upstream package metadata. You get the same
binary regardless, so as long as you can build the source package by ignoring
that diff, it's good to go.
Scott K
hat this issue is important enough that people should
>care and mass bugs be filed, sbuild will need a more concise way to
>test this; something like pbuilder's --twice option.
For the affected packages I looked at, this was enough to reproduce:
dpkg-buildpackage -b
dpkg-buildpackage -S
Or debuild if you prefer.
Scott K
gt; preferred form of modification of a Debian package has to be in salsa
>> and not in our archive when the changes cannot be represented as quilt
>> patches against tarballs.
>Is the gbp-pq workflow improper?
>
Git-dpm too. Apparently everything I do in git is improper. Maybe I should
give up on it then?
Scott K
ks. I think this is useful and we should fix issues like these. For the
packages I maintain/co-maintain on the list, I'd pushed fixes to the packaging
git, so they should all be fixed after the next upload.
In my case, I've gotten in the habit of using -nc when building source
packages, but that's a crutch and it's better to fix the issues. Thanks for
the prompt.
Scott K
signature.asc
Description: This is a digitally signed message part.
Package: wnpp
Severity: wishlist
Owner: Scott Kitterman
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org
* Package name: aioquic
Version : 0.9.21
Upstream Author : Jeremy Lainé
* URL : https://github.com/aiortc/aioquic
* License
Package: wnpp
Severity: wishlist
Owner: Scott Kitterman
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org
* Package name: pylsqpack
Version : 0.3.17
Upstream Author : Jeremy Lainé
* URL : https://github.com/aiortc/pylsqpack
* License
erge_requests/2529
Here's the postfix change, for another example:
https://github.com/vdukhovni/postfix/commit/
3b0ac407f313135ffd74e248ad88abd2ad6dfe09
Scott K
signature.asc
Description: This is a digitally signed message part.
On Monday, June 26, 2023 2:02:24 PM EDT Bastian Blank wrote:
> On Mon, Jun 26, 2023 at 01:22:38PM -0400, Scott Kitterman wrote:
> > > Less prone to errors than a manual process might be to watch
> > > automatically where legacy startup scripts disappear anyway; it's not
atches exactly the old
> > > init script name, in which case it's fine to add an override and close
> > > the bug.
> >
> > It would probably make things easier if I typed the destination
> > address correctly.
>
> It's generally expected that yo
r the policy discussion to
say
that maintainers who drop sysv init scripts should file a bug against orphan-
sysvinit-scripts with the final version of the provided init attached and which
lists the lowest version that won't include it (so that orphan-sysvinit-
scripts can Replaces << that version).
Scott K
signature.asc
Description: This is a digitally signed message part.
On Wed, 14 Jun 2023, Félix Sipma wrote:
* Package name: fuse
There's already a package named fuse in Debian:
https://tracker.debian.org/pkg/fuse
Regards,
Scott
angfrisch is still a useful thing to have in Debian.
Scott K
signature.asc
Description: This is a digitally signed message part.
eam:
https://salsa.debian.org/clamav-team
Fangfrisch has been on my TODO list for some time and I'm glad someone has
taken it up. It'd be nice to see it maintained in the same team with clamav.
Scott K
signature.asc
Description: This is a digitally signed message part.
Package: wnpp
Severity: wishlist
Owner: John Scott
X-Debbugs-Cc: debian-devel@lists.debian.org
Control: block 1025210 by -1
* Package name: golang-github-bemasher-rtltcp
* URL : https://github.com/bemasher/rtltcp
* License : AGPLv3
Programming Lang: Go
Description
Package: wnpp
Severity: wishlist
Owner: John Scott
Tags: newcomer
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name : usbscale
Upstream Contact: Eric Jiang
* URL : https://github.com/erjiang/usbscale
* License : GPL 3.0 or any later version
Programming Lang: C
ll be another option, where a generated tarball is
>uploaded as upstream source (as is already required by the ftp team for
>repacks) plus one debian/patches/debian.patch containing all changes to
>the upstream sources.
>
>Generating one quilt patch per commit that changes the upstream sources
>would not always be technically possible due to limitations of quilt.
Putting something in a git repository doesn't make a particular file more or
less the preferred form of modification. It's the same form. IMO you are
conflating two separate concepts here. I don't find Sean's perspective at all
surprising.
Scott K
e only
>difference is one notice included years and one did not.
>
I would add, that it's absolutely a requirement for license compliance in some
cases. For those cases, please continue to include it. I don't think Debian
should have a view that failing to comply with a license is okay if we think we
can get away with it.
Scott K
red to state copyright at all).
>
> - Jonas
>
>¹ Unless some licensing requires listing copyright *years* which from
>the top of my head I do not recall having seen, but am too lazy to check
>- also because my interest is not to cut corners most possible but to be
>as helpful to our users as possible, and copyright years serve a real
>(albeit cornercase) purpose.
You won't encounter it in license texts this way. Many licenses require
complete/verbatim inclusion of the copyright claims. If you remove the years,
you aren't doing that.
Scott K
anged - yes, this
happens). I don't think you should assume acceptance of a package without
years implies any particular judgement about if the practice is good or bad.
Scott K
P.S. Please don't turn this into yet another thread about how annoying having
to spend time on debian/copyright is. We know.
On Wed, 18 Jan 2023, Peter Pentchev wrote:
On Tue, Jan 17, 2023 at 08:03:18PM -0800, Russ Allbery wrote:
Scott Talbert writes:
In one of the library packages I maintain (hidapi), upstream removed a
couple of global variables (my .symbols file noticed this). See
abipkgdiff below.
Does
, so I
can't see how external user code would have referenced them.
Thanks,
Scott
changes of 'libhidapi-hidraw.so.0.0.0'===
Functions changes summary: 0 Removed, 0 Changed, 0 Added function
Variables changes summary: 0 Removed, 0 Changed, 0
27;s guaranteed to
be installed.
The new borg2 package has a borg-is-borg2 binary which provides usr/bin/borg
pointing to borg2. These two packages conflict, so that only one usr/bin/borg
provider can be installed.
After Bookworm is released, borg1/borg2 can recommend their usr/bin/borg
provider and the user can pick.
Once borg1 is removed, the extra packages can be dropped too.
This might be a little more work and needs a trip through new, but I think it's
policy compliant and a little lower risk.
Scott K
Package: wnpp
Severity: wishlist
Owner: John Scott
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-h...@lists.debian.org,
debian...@lists.debian.org
* Package name : rtlamr
Version : 0.9.1
Upstream Author : Douglas Hall
* URL : https://github.com/bemasher/rtlamr
ild a deb package and check it with lintian, so I'm
> not unprepared :)
The package name is very generic. I would pick something more specific. Also,
I suspect the speed advantage would be less significant if you used SubnetTree
(python3-subnettree), which does all the hard work in C. Is this really
needed?
Scott K
signature.asc
Description: This is a digitally signed message part.
e you trying to avoid that extra effort?
Regards,
Scott
ome transient failures due to the perl
rebuild that's ongoing. Specifically wxwidgets3.0 and wxpython4.0 are
affected by that.
Scott
Package: wnpp
Severity: wishlist
Owner: Scott Kitterman
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org
* Package name: python-noseofyeti
Version : 2.3.1
Upstream Author : Stephen Moore
* URL : https://github.com/delfick/nose-of-yeti
On Thu, 15 Sep 2022, Andreas Metzler wrote:
On 2022-09-13 Scott Talbert wrote:
Hi,
wxWidgets 3.2 (a new API/ABI stable release) has been released a few months
ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped
supporting wxWidgets 3.0, so the Debian wx team would
On Wed, 14 Sep 2022, gregor herrmann wrote:
On Mon, 12 Sep 2022 22:32:23 -0400, Scott Talbert wrote:
wxWidgets 3.2 (a new API/ABI stable release) has been released a few months
ago and is now packaged in unstable as wxwidgets3.2. …
For most packages, the transition should be as simple as
sion,
by using the version-specific wx-config (e.g., wx-config-3.0 or
wx-config-3.2), or using the generic wx-config with
wx-config --version=x.y.
In any event, I don't plan to change the packaging design at this point
(it's been this way forever, AFAIK). Maybe when wx 3.4 comes out in ~10
years we can reconsider. :)
Scott
On Tue, 13 Sep 2022, Mattia Rizzolo wrote:
On Mon, Sep 12, 2022 at 10:32:23PM -0400, Scott Talbert wrote:
wxWidgets 3.2 (a new API/ABI stable release) has been released a few months
ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped
supporting wxWidgets 3.0, so the
on in Fedora already).
The Release Team has set up a transition tracker for us to track
progress [1].
I'm planning to file bugs for all packages that haven't yet migrated.
dd-list is attached.
Please let me know if you have any questions or comments.
Thanks,
Scott
[1] https://rel
On Sunday, August 28, 2022 11:53:50 PM EDT Russ Allbery wrote:
> Scott Kitterman writes:
> > Sean Whitton wrote:
> >> I think we still want the binary package namespace checking?
> >>
> >> I.e., a GR just saying "ftpteam should not do a full
> >>
namespace checking?
>
>I.e., a GR just saying "ftpteam should not do a full licensing/copyright
>check for packages in binNEW".
>
>Then no software changes are required.
>
I think that a GR to prohibit developers from looking for bugs is at least in
principle inconsistent with not hiding problems.
Scott K
ebhelper 11 or 12 or 13. I'm having
>to patch debian/control every time I do a build, and this isn't a useful
>use of my time. Can we please loosen this in some way?
Is your package compatible with debhelper 14? If so, how do you know?
Scott K
at a couple of them and they were (source all) so that does
appear to be the problem. All uploads need to be source-only (since
bullseye?).
Scott
t's possible that my information
>is dated, though
That's correct.
Scott K
repository would be via backports. It looks
as if someone has already requested a backport of php8.1, so perhaps you
want to follow this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012615
Scott
Hi,
Is it possible to instruct the buildds to use a build profile when
performing an official build (e.g., using nocheck to break a dependency
loop)? If so, how?
Thanks,
Scott
On May 1, 2022 4:44:21 PM UTC, "Timo Röhling" wrote:
>* Scott Kitterman [2022-04-29 23:32]:
>> I don't understand why this is any better than just rejecting the
>> package? Once it's been determined that the upload won't be
>> accepted, I don&
On April 29, 2022 11:44:54 PM UTC, Paul Wise wrote:
>On Fri, 2022-04-29 at 23:32 +0000, Scott Kitterman wrote:
>
>> I don't understand why this is any better than just rejecting the
>> package? Once it's been determined that the upload won't be
>> accep
PT
>action by the ftpmasters, although of course a final review is needed.
I don't understand why this is any better than just rejecting the package?
Once it's been determined that the upload won't be accepted, I don't see a
benefit to having it remain in New.
Scott K
On Friday, April 29, 2022 12:08:21 PM EDT Andreas Tille wrote:
> Hi Scott,
>
> thanks a lot for becoming involved into this discussion.
>
> Am Fri, Apr 29, 2022 at 11:26:33AM -0400 schrieb Scott Kitterman:
> > 2. Not rejecting packages with serious defects:
> >
&g
aren't fixed. If that's what is
proposed, my thought is absolutely not.
If a package is not suitable for the archive then it should be rejected with
appropriate feedback and re-uploaded.
Note: Although I am a member of the FTP Team, I am only speaking for myself
here, not the team as a whole.
Scott K
signature.asc
Description: This is a digitally signed message part.
ider this mail a team-orphane of the package.
>
> I'm sorry; I do indeed intend to bring it into pkg-rpm, and I will try
> to do that in the next couple of days. Apologies for the months of
> delay, and thanks a lot for all of your team's work!
>
> G'lu
On Thursday, February 10, 2022 9:13:29 AM EST The Wanderer wrote:
> On 2022-02-10 at 09:06, Scott Kitterman wrote:
> > On Thursday, February 10, 2022 8:26:23 AM EST Simon McVittie wrote:
> >> I think the copyright file is doing several things which are perhaps in
> >> co
On Thursday, February 10, 2022 8:26:23 AM EST Simon McVittie wrote:
> On Tue, 08 Feb 2022 at 08:59:23 -0500, Scott Kitterman wrote:
> > From my point of view, treating something like other common classes of RC
> > bugs means that the project is producing tools and processes to mak
On Tuesday, February 8, 2022 2:45:18 PM EST Paul Gevers wrote:
> Hi,
>
> Release Team member hat on, but not speaking on behalf of the team. I
> haven't consulted anybody on the idea I mention below.
>
> On 08-02-2022 14:59, Scott Kitterman wrote:
>
> > If peo
On Tuesday, February 8, 2022 2:38:29 PM EST Russ Allbery wrote:
> Scott Kitterman writes:
> > Technically it would be the simplest, but there's a process for policy
> > changes that's more involved than writing emails to d-devel. I'm
> > suggesting you enga
Technically it would be the simplest, but there's a process for policy changes
that's more involved than writing emails to d-devel. I'm suggesting you
engage with it on this topic if you want the results of your work to be usable
in Debian.
Scott K
On Tuesday, February 8, 2022
On Tuesday, February 8, 2022 12:53:22 PM EST Stephan Lachnit wrote:
> On Tue, Feb 8, 2022 at 5:00 PM Scott Kitterman wrote:
> > Since Debian policy requires verbatim copies of licenses (or links to
> > /usr/
> > share/common-licenses), I think any policy compliant debian/co
y policy compliant debian/copyright will
have to be human readable, but I'm not that familiar with SPDX, so maybe it
will surprise me.
I would be good to understand how this proposal supports Debian Policy.
Scott K
signature.asc
Description: This is a digitally signed message part.
The
> > justification has always been dire consequences if we don't stamp out all
> > of these bugs, but to be honest I think this is wildly unlikely.
>
> I fully subscribe to this.
>
> I'd also like to thank Scott for
> a) His speedy processing of onetbb (w
ase), but with the current state of our
tooling that's not a policy that could be implemented (even if there was a
consensus among the FTP Masters to do so).
Scott K
ncy, suddenly I can't upload new releases to unstable properly
>until all the deps have made it through NEW.
Backports is an entirely different team. Let's not mix it in with this
discussion. It should be it's own thread.
Scott K
On Friday, February 4, 2022 6:24:56 PM EST Philip Hands wrote:
> Scott Kitterman writes:
>
> ...
>
> > Currently the only answer is join the FTP Team as a trainee when there
> > is a call for volunteers. I totally get the frustration.
>
> People could always just
On Friday, February 4, 2022 2:48:50 PM EST Russ Allbery wrote:
> Scott Kitterman writes:
> > Since we're doing strawman arguments in this thread: I disagree with the
> > notion that it's not a problem to put crap packages in the archive and
> > fix them later if an
On Friday, February 4, 2022 12:39:09 PM EST Russ Allbery wrote:
> The Wanderer writes:
> > What I read Scott as having been suggesting, by contrast, is that people
> > instead do copyright review for packages already in Debian, which may
> > well have had changes that did not
On Friday, February 4, 2022 4:00:44 AM EST Philip Hands wrote:
> Scott Kitterman writes:
>
> ...
>
> > My impression is that people are tired of waiting on New, but no one
> > really seems to be interested in doing any work on any alternative
> > other than more
On Thursday, February 3, 2022 2:40:08 PM EST Phil Morrell wrote:
> On Thu, Feb 03, 2022 at 09:43:16AM -0500, Scott Kitterman wrote:
> > I am a member of the FTP Team and have been participating, at least a bit,
> > in this thread. I am not, however, speaking for the team.
>
&g
m. If people think reviews by
the broader community can replace New, I would invite you to get started on
the work and demonstrate that there is sufficient interest in doing the work.
There are plenty of in-archive issues to be found and fixed.
I would certainly not support the notion that we have too few licensing
documentation bugs in the archive and we can afford to dismantle the one
process we have in place that actually makes a difference in this area.
Scott K
signature.asc
Description: This is a digitally signed message part.
d to be established
and demonstrated to be effective. No reason this can't be done with existing
packages to establish the concept.
Scott K
signature.asc
Description: This is a digitally signed message part.
s case a lawyer) can give us information on trade offs related to legal
risk (both to potentially losing in a legal action and to having to spend
significant project resources even if we win), but the project has to make the
decision about what level of risk it is willing to accept.
Scott K
signat
Package: wnpp
Severity: wishlist
Owner: Scott Kitterman
* Package name: python-rangehttpserver
Version : 1.2.0
Upstream Author : Dan Vanderkam
* URL : https://github.com/danvk/RangeHTTPServer
* License : Apache 2.0
Programming Lang: Python
Description
Package: wnpp
Severity: wishlist
Owner: Scott Kitterman
* Package name: clamav-cvdupdate
Version : 1.0.2
Upstream Author : The Clamav Team
* URL : https://github.com/Cisco-Talos/cvdupdate
* License : Apache 2.0
Programming Lang: Python
Description
On Friday, January 21, 2022 1:33:07 PM EST Adam Borowski wrote:
> On Fri, Jan 21, 2022 at 01:28:54PM -0500, Scott Kitterman wrote:
> > 2. New binary package "steals" binary from another source. This is
> > sometimes OK. Sometimes it's accidental. It could
aintainer, but not
for the archive as a whole. I've seen this come up multiple times, usually in
the context of the binary being too trivial (which is a judgment call).
It's not just let's do extra copyright/license checks.
Scott K
signature.asc
Description: This is a digitally signed message part.
1 - 100 of 963 matches
Mail list logo
