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
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
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
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,
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
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
> >>
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
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
❦ 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
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
❦ 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
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
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
>
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.
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
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
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
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
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
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,
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
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
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"
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
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
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 little experience reviewing packages on behalf of
> ftp-team.
>
> A --
28 matches
Mail list logo
