On Tue, 25 Jan 2022 21:38:01 +0100, Vincent Bernat wrote:
>
> I think we should forego the NEW queue. If people want to check
> packages, they can do it once they are in unstable with regular bugs.
> Current checks are partly done by Lintian and I suppose people could
> watch new Lintian warnings
On Wed, 26 Jan 2022 07:38:10 +0100 Andreas Tille wrote:
> Am Tue, Jan 25, 2022 at 01:45:11PM -0800 schrieb Russ Allbery:
[...]
> > The question, which keeps being raised in part
> > because I don't think it's gotten a good answer, is what the basis is for
> > treating copyright and licensing bugs
Hi,
Not a DD, still raising my voice. I'm *not* advocating that Fedora's
processes are "better", just trying to add ideas.
On 26/01/2022 11:43, Adam Borowski wrote:
On Tue, Jan 25, 2022 at 09:38:01PM +0100, Vincent Bernat wrote:
I think we should forego the NEW queue. If people want to che
Adam Borowski writes:
> On Tue, Jan 25, 2022 at 09:38:01PM +0100, Vincent Bernat wrote:
>> For me, the copyright check is just a bad excuse. People upload
>> non-distributable stuff everywhere and it seems the world continue to go
>> round. What amount of non-distributable packages is stopped by
On Wed, Jan 26, 2022 at 11:43 AM Adam Borowski wrote:
>
> On Tue, Jan 25, 2022 at 09:38:01PM +0100, Vincent Bernat wrote:
> >
> > I think we should forego the NEW queue. If people want to check
> > packages, they can do it once they are in unstable with regular bugs.
>
> Without the NEW queue, the
On Tue, Jan 25, 2022 at 09:38:01PM +0100, Vincent Bernat wrote:
> For me, the copyright check is just a bad excuse. People upload
> non-distributable stuff everywhere and it seems the world continue to go
> round. What amount of non-distributable packages is stopped by the NEW
> queue?
>
> I think
On Wed, Jan 26, 2022 at 10:44:37AM +0100, Gard Spreemann wrote:
> Jonas Smedegaard writes:
> > Quoting Vincent Bernat (2022-01-25 21:38:01)
> >> I didn't comment at first because I thought someone else would raise
> >> the idea. But it seems people still like the idea of a NEW queue. Not
> >> me
Jonas Smedegaard writes:
> Quoting Vincent Bernat (2022-01-25 21:38:01)
>> I didn't comment at first because I thought someone else would raise
>> the idea. But it seems people still like the idea of a NEW queue. Not
>> me. The NEW queue is a hindrance.
>
> For the record, I don't "like" the N
Andreas Tille writes:
...
> May be some intermediate step would be to not hide packages in NEW queue
> but exposing them as an apt source. If I'm correct this is not the case
> since it had certain legal consequences for the project if code with
> certain non-free licenses would be downloadable
Am Tue, Jan 25, 2022 at 01:45:11PM -0800 schrieb Russ Allbery:
> Jonas Smedegaard writes:
>
> > I just don't think the solution is to ignore copyright or licensing
> > statements.
>
> That's not the goal. The question, which keeps being raised in part
> because I don't think it's gotten a good
Hi Russ,
> > I just don't think the solution is to ignore copyright or licensing
> > statements.
>
> That's not the goal. The question, which keeps being raised in part
> because I don't think it's gotten a good answer, is what the basis is for
> treating copyright and licensing bugs differently
Jonas Smedegaard writes:
> I just don't think the solution is to ignore copyright or licensing
> statements.
That's not the goal. The question, which keeps being raised in part
because I don't think it's gotten a good answer, is what the basis is for
treating copyright and licensing bugs differ
❦ 25 January 2022 21:51 +01, Jonas Smedegaard:
>> I didn't comment at first because I thought someone else would raise
>> the idea. But it seems people still like the idea of a NEW queue. Not
>> me. The NEW queue is a hindrance.
>
> For the record, I don't "like" the NEW queue.
>
> I don't like
Quoting Vincent Bernat (2022-01-25 21:38:01)
> I didn't comment at first because I thought someone else would raise
> the idea. But it seems people still like the idea of a NEW queue. Not
> me. The NEW queue is a hindrance.
For the record, I don't "like" the NEW queue.
I don't like current copy
❦ 21 January 2022 09:51 -05, M. Zhou:
> I'd rather propose choice C. Because I to some extent understand
> both sides who support either A or B. I maintain bulky C++ packages,
> and I also had a little experience reviewing packages on behalf of
> ftp-team.
I didn't comment at first because I tho
Am Mon, Jan 24, 2022 at 06:50:17PM -0500 schrieb Theodore Y. Ts'o:
>
> So could the Release Team figure out a way to automatically rebuild
> packages that have source dependencies on static libraries?
>
> This would solve the problem of new binary packages causing a full
> ftpmasters policy revie
On Mon, Jan 24, 2022 at 8:15 AM Andreas Tille wrote:
>
> However, my point was that I want to know what policy ftpmaster applies
> to new binary names and to focus on this topic. I really want to know
> that policy of ftpmaster and I really would like to see that documented
> and I'm afraid that
On Mon, Jan 24, 2022 at 08:48:28PM +0100, Paul Gevers wrote:
> Hi Ted,
>
> I think this is the second time you write something like this, but for
> dynamically linked libraries, the rebuild happens (by the Release Team,
> (please use transition trackers for that) because we automatically track
> t
Hi Ted,
On 24-01-2022 19:44, Theodore Y. Ts'o wrote:
No, dpkg-shlibsdeps doesn't save you. Again, consider the
hypothetical package libshaky, which over the period of 9 months, has
soname changes which generate (over time) packages libshaky3,
libshaky4, libshaky6, libshaky7, and libshaky8.
The
On Mon, Jan 24, 2022 at 08:15:30AM +0100, Andreas Tille wrote:
> Hi Paul and others,
>
> its surely an interesting topic how to avoid binary name changes and its
> also interesting to discuss ABI changes and workarounds.
>
> However, my point was that I want to know what policy ftpmaster applies
On Mon, Jan 24, 2022 at 10:20:48AM +0800, Paul Wise wrote:
> On Sun, 2022-01-23 at 17:43 -0500, Theodore Y. Ts'o wrote:
>
> > That only works if there are no other packages depending on those
> > shared libraries which are coming from other source packages.
>
> I don't think that is true, I belie
Hi Paul and others,
its surely an interesting topic how to avoid binary name changes and its
also interesting to discuss ABI changes and workarounds.
However, my point was that I want to know what policy ftpmaster applies
to new binary names and to focus on this topic. I really want to know
that
On Sun, 2022-01-23 at 17:43 -0500, Theodore Y. Ts'o wrote:
> That only works if there are no other packages depending on those
> shared libraries which are coming from other source packages.
I don't think that is true, I believe you can put multiple things in
the depends section of an shlibs file
On Sat, Jan 22, 2022 at 08:58:37AM +0800, Paul Wise wrote:
> > The other thing that's perhaps considering here is that unfortunately,
> > there are some upstreams that are extremely irresponsible with library
> > ABI backwards compatibility, where they bump the SONAME essentially at
> > every relea
On Fri, Jan 21, 2022 at 7:04 PM Paul Gevers wrote:
>
> It's not only the copyright that the ftp-master are responsible for. New
> binaries fill a place in the Debian namespace and they *are* the keepers
> of that.
One could say that for new binaries packages whose src is already in
Debian, the ft
Hi,
Am Fri, Jan 21, 2022 at 07:04:33PM +0100 schrieb Paul Gevers:
> > I have heard this argument and my mail was simply to find out what
> > fellow developers think about this. IMHO the issue is sufficiently
> > important to have some kind of documented consensus about this.
>
> It's not only th
On Sat, 22 Jan 2022 at 08:58:37 +0800, Paul Wise wrote:
> On Fri, 2022-01-21 at 13:55 -0500, Theodore Ts'o wrote:
> > The other thing that's perhaps considering here is that unfortunately,
> > there are some upstreams that are extremely irresponsible with library
> > ABI backwards compatibility, wh
On Fri, 2022-01-21 at 13:55 -0500, Theodore Ts'o wrote:
> Can we have better automated tooling, either in Lintian, or in when
> source packages are rebuilt, that can take care of this?
>
> The other thing that's perhaps considering here is that unfortunately,
> there are some upstreams that are e
On Fri, 21 Jan 2022 13:41:05 -0500, Scott Kitterman wrote:
> On Friday, January 21, 2022 1:33:07 PM EST Adam Borowski wrote:
> > Stealing a binary does not go through NEW.
> It does. Binary is new to that source so there is no existing override.
If this is correct, dak / the override system must
On Fri, Jan 21, 2022 at 01:28:54PM -0500, Scott Kitterman wrote:
>
> 1. When the SO name changes and the binary package name is adjusted
> accordingly, it is not super rare for the maintainer to mess something up in
> the renaming and end up with an empty binary package, which does no one any
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 also be malicious (I
> > don't remember
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 also be malicious (I don't remember
> if I've every actually seen this done for an intentional "steal" o
On Friday, January 21, 2022 12:19:12 PM EST Andreas Tille wrote:
> Hi Mo,
>
> Am Fri, Jan 21, 2022 at 09:51:12AM -0500 schrieb M. Zhou:
> > I'd rather propose choice C. Because I to some extent understand
> > both sides who support either A or B. I maintain bulky C++ packages,
> > and I also had a
Hi,
I'm not involved in ftp-master, but...
On 21-01-2022 18:19, Andreas Tille wrote:
Am Fri, Jan 21, 2022 at 09:51:12AM -0500 schrieb M. Zhou:
I'd rather propose choice C. Because I to some extent understand
both sides who support either A or B. I maintain bulky C++ packages,
and I also had a
e I would seek for
opinions since this argument is in conflict with my interpretation
of the said mail I was refering to[1].
> Given the understanding of both options, I propose choice C:
>
> C. Lottery NEW queue:
>
> if (src is new):
> # completely new package
>
ially bulky (C++) packages, this is
painful for both uploaders and ftp checkers.
Given the understanding of both options, I propose choice C:
C. Lottery NEW queue:
if (src is new):
# completely new package
require manual-review
elif (src is old) but (bin is new):
if not-check
36 matches
Mail list logo
