Bug#913997: Bug#977709: Bug#913997: what is the current maintainer view on this ?

2021-01-19 Thread Gunnar Wolf
Christian Kastner dijo [Tue, Jan 19, 2021 at 09:55:19AM +0100]:
> > We are considering NMU of vmdb 0.22. The Salsa repo. is at
> > https://salsa.debian.org/ckk/vmdb2
> 
> Given that a new upstream version usually does not fit the profile of an
> NMU: just to be clear, the vmdb2 Maintainer indicated that because of
> limited availability in Dec/Jan, he'd be OK with an NMU if need be.

Or even better, if need be -- If you can update the Git repo with the
changes and notify me, I can promise to look and the changes and
perform an upload within 24hr



Bug#913997: what is the current maintainer view on this ?

2021-01-19 Thread Christian Kastner
Hi all,

On 19.01.21 07:55, Pirate Praveen wrote:
> Antonio, can we go ahead with the renaming now?

Just to be clear, personally, I agree with the both original and the
current cmdtest maintainers that this issue has been caused by the other
upstream, and the other upstream's collaboration on a resolution has
been poor.

I really only wanted to comment on the situation with regards to reverse
dependencies, as I had new objective data on that one issue being
discussed, which would probably lead to another outcome with regards to
that issue.

In particular, another issue I did not want to comment on is that popcon
indicates that cmdtest does have some regular users, and I believe that
this must be weighed as well. A NEWS entry for a rename might resolve
this, but that's not for me to decide.

Best,
Christian



Bug#913997: what is the current maintainer view on this ?

2021-01-19 Thread Christian Kastner
Hi all,

On 19.01.21 01:51, Ryutaroh Matsumoto wrote:
>> Ryutaroh and I have been working with vmdb2 upstream on a new release
>> with support for more architectures.
> 
> We are considering NMU of vmdb 0.22. The Salsa repo. is at
> https://salsa.debian.org/ckk/vmdb2

Given that a new upstream version usually does not fit the profile of an
NMU: just to be clear, the vmdb2 Maintainer indicated that because of
limited availability in Dec/Jan, he'd be OK with an NMU if need be.

Best,
Christian



Bug#913997: what is the current maintainer view on this ?

2021-01-18 Thread Pirate Praveen
On Tue, 19 Jan 2021 00:29:18 +0100 Christian Kastner  wrote:
> Hi all,
> 
> On Sat, 19 Dec 2020 Pirate Praveen wrote:>> Renaming the binary is
> harder, because there are at least two
> >> packages that use yarn from cmdtest during the build: gitano and
> >> vmdb2. they would need to be ported, and that's up to their
> >> maintainers and upstreams, who I assume won't be happy about it.
> > 
> > Now only xauth and vmdb2 shows up as reverse build dependencies. I 
> > have asked their maintainers if they are open to the name change in 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977709
> Ryutaroh and I have been working with vmdb2 upstream on a new release
> with support for more architectures.
> 
> During this process, upstream indicated that vmdb2 will move away from
> yarn (cmdtest) to Subplot (not yet packaged).
> 
> A quick grep of the sources of xauth, the other reverse dependency of
> cmdtest, gets no results for the string 'yarn'. So the conflicting
> binary does not seem to be used there.
> 
> So, strictly from the point of view of its reverse dependencies, holding
> off on renaming the 'yarn' binary would probably not make much sense.
> 
> Best,
> Christian

Thanks Christian for your comment.

Antonio, can we go ahead with the renaming now?

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#913997: what is the current maintainer view on this ?

2021-01-18 Thread Ryutaroh Matsumoto
Hi all,

> Ryutaroh and I have been working with vmdb2 upstream on a new release
> with support for more architectures.

We are considering NMU of vmdb 0.22. The Salsa repo. is at
https://salsa.debian.org/ckk/vmdb2
Please also have a look at
https://salsa.debian.org/ckk/vmdb2/-/merge_requests/4

Best regards, Ryutaroh Matsumoto



Bug#913997: what is the current maintainer view on this ?

2021-01-18 Thread Christian Kastner
Hi all,

On Sat, 19 Dec 2020 Pirate Praveen wrote:>> Renaming the binary is
harder, because there are at least two
>> packages that use yarn from cmdtest during the build: gitano and
>> vmdb2. they would need to be ported, and that's up to their
>> maintainers and upstreams, who I assume won't be happy about it.
> 
> Now only xauth and vmdb2 shows up as reverse build dependencies. I 
> have asked their maintainers if they are open to the name change in 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977709
Ryutaroh and I have been working with vmdb2 upstream on a new release
with support for more architectures.

During this process, upstream indicated that vmdb2 will move away from
yarn (cmdtest) to Subplot (not yet packaged).

A quick grep of the sources of xauth, the other reverse dependency of
cmdtest, gets no results for the string 'yarn'. So the conflicting
binary does not seem to be used there.

So, strictly from the point of view of its reverse dependencies, holding
off on renaming the 'yarn' binary would probably not make much sense.

Best,
Christian



Bug#913997: what is the current maintainer view on this ?

2020-12-19 Thread Pirate Praveen
On Wed, 3 Jun 2020 12:08:29 -0300 Antonio Terceiro 
 wrote:
> Now, with that said, I understand that the current situation creates 
a

> technical problem for a growing ecosystem in Debian. Unfortunately I
> don't have any easy solution to propose.
>
> I will not block technical work to solve this in the correct way, 
and as
> gatekeeper that will need to be involved in a solution I will review 
and

> apply patches that make sense.
>
> Dropping the Provides: would be relatively easy.

Would you take a merge request for this?

> Renaming the binary is harder, because there are at least two 
packages

> that use yarn from cmdtest during the build: gitano and vmdb2. they
> would need to be ported, and that's up to their maintainers and
> upstreams, who I assume won't be happy about it.

Now only xauth and vmdb2 shows up as reverse build dependencies. I have 
asked their maintainers if they are open to the name change in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977709




Bug#913997: what is the current maintainer view on this ?

2020-06-03 Thread Antonio Terceiro
On Tue, May 26, 2020 at 08:05:31PM +0200, Paolo Greppi wrote:
> The issue has been raised again on the yarnpkg side:
> https://bugs.debian.org/940511
> 
> Antonio, what is your point of view ?
> Do you think we can fix this for the Bookworm release ?

I think that the people who created this problem in the first place
showed no empathy and were not flexible at all even after presented with
evidence that there were existing projects from before theirs that were
already using the yarn name.

I agree with the original maintainer that this namespace takeover
attempt feels like bullying. "Mine is bigger than yours" is not a good
argument for anything in Debian.

I have a lot of other priorities, and I only adopted cmdtest to keep
vmdb2 in testing since autopkgtest uses it for building vm images.  I
don't plan to spend a single minute of my time working towards changing
the status quo (with a caveat, see below).

Now, with that said, I understand that the current situation creates a
technical problem for a growing ecosystem in Debian. Unfortunately I
don't have any easy solution to propose.

I will not block technical work to solve this in the correct way, and as
gatekeeper that will need to be involved in a solution I will review and
apply patches that make sense.

Dropping the Provides: would be relatively easy.

Renaming the binary is harder, because there are at least two packages
that use yarn from cmdtest during the build: gitano and vmdb2. they
would need to be ported, and that's up to their maintainers and
upstreams, who I assume won't be happy about it.


signature.asc
Description: PGP signature


Bug#913997: what is the current maintainer view on this ?

2020-05-26 Thread Paolo Greppi
The issue has been raised again on the yarnpkg side:
https://bugs.debian.org/940511

Antonio, what is your point of view ?
Do you think we can fix this for the Bookworm release ?

Thanks,

Paolo