On Saturday, June 16 2018, Fabian Wolff wrote:

> On Sat, Jun 16, 2018 at 02:53:54PM -0400, Sergio Durigan Junior wrote:
>> On Saturday, June 16 2018, Fabian Wolff wrote:
>> > Could someone please create a 'libantlr3c' repository in the Debian
>> > group on Salsa and give me (wolff-guest) write access to it? An empty
>> > repository will suffice, I will populate the repository with the
>> > history from snapshot.debian.org as well as my own changes.
>> 
>> Done:
>> 
>>   https://salsa.debian.org/debian/libantlr3c
>
> Great, thank you.

No problem.

> You see, I am the maintainer of a reverse dependency of libantlr3c
> (cvc4). libantlr3c is scheduled for autoremoval on 15 July due to
> #900601, and since libantlr3c is currently orphaned, I took it upon
> myself to investigate the issue.

That's a great initiative, thanks a lot for doing it.

> I have attempted to fix the issue by removing the non-DFSG-compliant
> files.

OK.

> One of the functions that was defined there is needed by other
> parts of the code, however, which is why I have provided an
> alternative implementation. I know rather little about proper Unicode
> string handling, and I have never worked with libicu, which is why
> I've attempted a solution in C++. Better solutions are welcome, of
> course.

OK.  That's kind of a bold move, but I can see your rationale.  I myself
have never worked with Unicode as well, so it's hard to say if your code
will really work.  It does look OK, but without proper testing it's a
shot in the dark.

I see a few problems here; some I need you to address before moving
forward, and others can be tackled later.  Let me make a list:

1) You're basically removing functionalities from the upstream project,
so I think you should detail what's being removed (and why) on
d/README.Debian.

2) I also think it's a good idea to proper license your code, because it
will be redistributed along with the project.  I'd suggest choosing the
same license as the project.

These two problems are easy enough to fix, and I think that uploading a
package without having them addressed first is not going to work.

Other things worth doing:

3) IANAL, but this issue seems serious enough to justify contacting
upstream and reporting the problem to them.

4) I see that src/antlr3string.c is the only user of the
ConvertUTF16toUTF8 function.  What do you think of declaring the
function inside the file?  This way we'd get rid of the problematic
files, which is a good thing, since we'll not export their API anymore.

> Removing the non-DFSG files changes the public API, so a transition is
> necessary. There has also been a new upstream release that changes the
> SONAME, so I figured it would be best to combine both of those into a
> single transition, which is why I've included the new upstream release
> into this QA upload.
>
> I have uploaded the package to Mentors:
>
>   https://mentors.debian.net/package/libantlr3c
>
> I have set the distribution to "experimental", as described in [0].

Great.  I see you did the experimental work on the master branch.  I
personally don't think it's a good idea, because eventually you'll have
to release the package on stable, and d/changelog doesn't need to have
entries reflecting experimental releases.  What I usually do is create a
separate branch ("debian-experimental" or some such) and do the
experimental work there.  This way, when it's time to merge, it's
easier.

There's a nice write-up of this workflow here:

  
https://wiki.debian.org/PackagingWithGit#Merging_a_debian-experimental_branch_into_master_for_sid

But bear in mind, you don't need to fix this before I upload.  Actually,
if you prefer you can keep your experimental work on the master branch,
no problem at all.

> Sergio, would you be willing to sponsor this upload? I would also be
> glad if you could assist me with the rest of the transition process.

Yeah, I'd be happy too.  It will be my first time monitoring a
transition :-).  Just let me know when you have addressed the two issues
I mentioned above, and I'll upload the package right away.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Attachment: signature.asc
Description: PGP signature

Reply via email to