[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language



Hi Bastian,

* Bastian Germann <bage@debian.org> [221215 08:57]:
>
> Thanks for draft package.

No problem, thanks for looking at it.

> Let's go for 0.9 and when that is in we'll see what version can be
> packaged next.

Great.

I've filed an issue about the problems I have building 0.10.0 on the Zig
github but no response yet. I've also tried raising it twice in Zig IRC
but no luck there either.

> I have reopened Thr RFS bug. Please have that in copy during the discussion
> so other sponsors can pick up if I am not repsonsive.

Ok.

> In general it is a good idea to put your package in a repo on Debian's salsa
> git service because that has a CI system with a working setup to build
> Debian packages. You would then have to put the files that are in your
> repository's root into a debian directory. With the CI in place you will get
> an idea of the quality of your package before posting it for review.

I'd be more than happy to move it to salsa, but thought it was only
available for DDs/DMs. I see now that that is incorrect. I registered an
account and it seems to be pending approval.

In the mean time I've made a debian directory in the repo and moved
everything into it.

> d/rules
> =======
> You should leave the CMAKE_BUILD_TYPE default because this will build the
> debug info that will then be extracted and stripped by default.

Ok done.

> Your package fails to build from scratch on amd64 with a test fail (maybecaused by wrong pwd?):
>
> [100%] Built target zig
> make[2]: Leaving directory '/home/bage/zig-0.9.1/obj-x86_64-linux-gnu'
> /usr/bin/cmake -E cmake_progress_start /home/bage/zig-0.9.1/obj-x86_64-linux-gnu/CMakeFiles 0
> make[1]: Leaving directory '/home/bage/zig-0.9.1/obj-x86_64-linux-gnu'
>    debian/rules override_dh_auto_test
> make[1]: Entering directory '/home/bage/zig-0.9.1'
> ./debian/zig/usr/bin/zig build test-fmt || exit 1; ./debian/zig/usr/bin/zig
> build test-behavior || exit 1; ./debian/zig/usr/bin/zig build
> test-compiler-rt || exit 1; ./debian/zig/usr/bin/zig build test-minilibc ||
> exit 1; ./debian/zig/usr/bin/zig build test-compare-output || exit 1;
> ./debian/zig/usr/bin/zig build test-standalone || exit 1;
> ./debian/zig/usr/bin/zig build test-stack-traces || exit 1;
> ./debian/zig/usr/bin/zig build test-cli || exit 1; ./debian/zig/usr/bin/zig
> build test-asm-link || exit 1; ./debian/zig/usr/bin/zig build
> test-runtime-safety || exit 1; ./debian/zig/usr/bin/zig build
> test-translate-c || exit 1; ./debian/zig/usr/bin/zig build
> test-run-translated-c || exit 1; ./debian/zig/usr/bin/zig build test-std ||
> exit 1;
> /bin/sh: 1: ./debian/zig/usr/bin/zig: not found
> make[1]: *** [debian/rules:16: override_dh_auto_test] Error 1
> make[1]: Leaving directory '/home/bage/zig-0.9.1'
> make: *** [debian/rules:8: binary] Error 2

I don't know why that is. It works for me on amd64 on unstable
(bullseye with backports). I do recall that someone on #mentors had
issues building it using sbuild at some point. But at least 3 or 4
others did not: success was reported with both pbuilder and sbuild.

> d/watch
> =======
> The watch file in your upload differs from the one in git. Please keep
> them in sync.

Hmm, at least in the main branch I think it is the same. Anyway I will
be more careful to try to keep them in sync. Unfortunately I've not yet
found a workflow for easily doing so, although I'm sure one (probably
many) exists.

> d/changelog
> ===========
> As long as the package is not sponsored, please only keep one version
> (0.9.1-1) with the ITP closing entry. Your latest upload has 3
> versions.

Ok.

> d/copyright
> ===========
> Please use more wildcards so you do not have to list so many files.

This is where it gets tricky for me. As I understand it the last match
in d/copyright file is the one that applies. So for example, the block
starting at line 253 specifies a LGPL-2.1+ license for a bunch of files
under lib/libc/include/. Lines 253-270 explicitly list header files
under lib/libc/include/aarch64-linux-gnu/bits/. So first thought is to
just list them all as a glob lib/libc/include/aarch64-linux-gnu/bits/*
However on closer inspection I see that there is a file in that
directory that is not listed. Specifically
lib/libc/include/aarch64-linux-gnu/bits/fcntl/endianness.h
Inspecting this file and the others in the directory I see that
explicitly listed files contain the LGPL-2.1+ text, but that
endianness.h contains no license text. Thus endianness.h is actually
Expat license and is covered in the block starting on line 10 "Files:
lib/*".

So if I change the explicit list of files under
lib/libc/include/aarch64-linux-gnu/bits/ to a glob, I'll need to and
anther block later to explicitly list endianness.h as Expat.
Or is possible to not use a glob but instead use a regex that includes
everything other than endianness.h?

This is the sort of thing that I've been battling with the whole time
with that d/copyright.

> Your comment:
> "COPYRIGHT file has a lont list of "Authors/contributors include". Should these be added here in some way?"
> You should first think if the whole musl dir can be replaced with the
> musl-dev package. If so, you can repack the tarball,

I comment on this further down.

> else you stick to the Copyright line, as required by the Expat license.
> The long list of authors does not claim they are copyright holders but
> "Authors/contributors".

Ok thanks, that clarifies that for me. I removed that comment.

> The repackaging comment does not only go for musl but also the other
> 3rd party components.

Striping out the bundled source would change Zig drastically and would
make both producing and maintaining this package much harder. I think
that the bundled source is part of what makes Zig Zig.

If you have not seen it already (and for the sake of others) please see
what Andrew Kelly of wrote in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995670

> BSD-4-clause is not correctly represented. You replaced the 3rd clause's
> acknowlegement with "This product includes software developed by this
> project." However, this mentions the University of California in the
> referencing files.
> For BSD-4-clause by UC California specifically you can just remove the whole
> 3rd clause because the Regents allowed to do so once upon a time. If there
> is a file with different acknowlegement please keep it as-is.

Checking my copyright file it seems that all files that are licensed
BSD-4-clause have "The Regents of the University of California" as one
of the copyright holders. Checking the files themselves I see that for
most files third clause does indeed specify University of California,
Berkeley and its contributors. However there are a handful of others
that specify different people in the clause 3 and have correspondingly
modified clause 4. So I guess I need to grind through and separate them
all?

> CC0 is in Debian's common-licenses. Please replace the whole text with
> a reference like in the GPL variants.

Ok. I haven't been able find a definitive short version of the CC0
license. There seem to be some variations checking
/usr/share/doc/*/copyright on my system. Can you suggest what I should
use for this?

> BSD-2-clause-NetBSD is not the right license. You copied the ISC from
> lib/libc/mingw/misc/getopt.c, not the BSD-2-clause-NetBSD.

Thanks. Fixed.

> There is more to come; I have only reviewed the overall appearance of
> the file.

Understood.

> What is the debian.decopy file about?

That is the output produced by decopy. It should not have been included
in the package.

> d/patches
> ==============
> Please do not include if you do not have at least one patch.

Think that's an artefact of earlier iterations when the package did have
patches. Removed.

I committed and pushed the updates to
https://github.com/NickHastings/zig-debian
Will move it to salsa when/if my account application is approved.

Should I also reupload to mentors?

Thanks for your time and efforts reviewing this package. You've found
problems that I had overlooked and explained things that I didn't
previously understand.

Cheers,

Nick.


Reply to: