Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Thanks for checking. The arch i386 is going away, so it can be ignored/disabled. Issues with BLHC and reprotest should be fixed if they are easy. Having them both pass is not a hard requirement. Most important here is that you checked all failures and there was nothing else. I don't have any suggestions how to get around the wasm binary issue right now. Let me think about it for a couple of days.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Hi, * Nick Hastings [240716 10:08]: > > I just merged the zig-0.11.0 branch into main. Note however that as far as I > understand it, the wasm blob introduced in 0.11.0 now makes this dsfg > non-free. > > The build for this version worked for me locally, but seems to have failed on > salsa. Will look into it. To clarify: - i386 package build failed but the default one succeeded - Obviously wasm binary means that the lintian check failed - blhc failed: complaining about missing -fstack-protector-strong - reprotest failed: exceeded maximum number of open file descriptors? https://salsa.debian.org/zig-team/zig/-/pipelines/702071 Cheers, Nick.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Hi, * Otto Kekäläinen [240715 12:07]: > > The CI at > https://salsa.debian.org/zig-team/zig/-/jobs/5643130 fails on: > > /bin/sh: 1: ./obj-x86_64-linux-gnu/zig: not found Checking the log, it seems that the build worked but it failed to run the tests since it seems that the path to the final zig binary changed. > Do you need help getting past this? No, I know how to fix it. I just merged the zig-0.11.0 branch into main. Note however that as far as I understand it, the wasm blob introduced in 0.11.0 now makes this dsfg non-free. The build for this version worked for me locally, but seems to have failed on salsa. Will look into it. Cheers, Nick.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Cool, latest version indeed is on Salsa https://salsa.debian.org/zig-team/zig/-/blob/main/debian/control Vcs-Browser: https://salsa.debian.org/zig-team/zig Vcs-Git: https://salsa.debian.org/zig-team/zig.git Homepage: https://github.com/ziglang/zig The CI at https://salsa.debian.org/zig-team/zig/-/jobs/5643130 fails on: /bin/sh: 1: ./obj-x86_64-linux-gnu/zig: not found Do you need help getting past this?
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
On Sun, 2024-07-14 at 15:06 -0700, Otto Kekäläinen wrote: > Hi! > > > * Vcs : https://github.com/NickHastings/zig-debian > > Any particular reason this is not hosted on Salsa and using Salsa-CI > to validate that all easily testable things are correct? > > - Otto > Hi Otto, While using salsa and extended tools like salsa CI is an ideal, as far as I am aware (others correct me), Debian does not mandate workflow. Contributors may be hosted anywhere and use whatever tools they wish. Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg -- signature.asc Description: This is a digitally signed message part
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
* Otto Kekäläinen [240715 07:07]: > > Any particular reason this is not hosted on Salsa and using Salsa-CI > to validate that all easily testable things are correct? https://salsa.debian.org/zig-team/zig-team
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Hi! > * Vcs : https://github.com/NickHastings/zig-debian Any particular reason this is not hosted on Salsa and using Salsa-CI to validate that all easily testable things are correct? - Otto
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Hi Submitter and all, It has been almost a year since the last activity on this Request For Sponsorship (RFS). Is there still interest in the packaging of zig by the submitter or others, or can this RFS be closed and the Intent To Package (ITP) be returned (retitled) to Request For Package (RFP) status? Regards Phil -- Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg signature.asc Description: This is a digitally signed message part
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
* Bastian Germann [230113 18:05]: > Am 13.01.23 um 03:40 schrieb Nick Hastings: > > This debian/copyright file was originally produced by decopy and I > > adjusted it wherever I found problems. I hesitate to change things that > > I do not know to be wrong, at the risk of introducing errors simply to > > reduce the number of lines in the file. > > If you want this to be sponsored by me, please do so. I spent a couple of hours grinding through the LGPL-2.1 section of lib/libc/include and was able reduce the copyright file by about 760 lines. I was also able to save a few lines from the APSL-2 an GPL-2 sections. > I will not review a non-reviewable copyright file. I'm not clear on what constitutes a reviewable vs non-reviewable copyright file. If there are other specific parts of the copyright file that you think need more work please let me know.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
I would recommend you install the debian-policy package and review the documentation on the format of the copyright file at /usr/share/doc/debian- policy/copyright-format-1.0.html. With that as a reference, I do not find it difficult to manually edit copyright files. On Thursday, January 12, 2023 7:40:02 PM MST Nick Hastings wrote: > * Bastian Germann [230104 02:20]: > > Control: tags -1 moreinfo > > > > Am 15.12.22 um 06:40 schrieb Nick Hastings: > > > > 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. > > > > Yes, you would use a glob for the LGPL files and add another block > > specifically for the Expat-licensed file after the LGPL block. > > Understood. However I do not feel confident that I can correctly make > these changes by hand. The above is just one example where I found that > using a glob would require an additional section/exception. There are > likely many more. > > This debian/copyright file was originally produced by decopy and I > adjusted it wherever I found problems. I hesitate to change things that > I do not know to be wrong, at the risk of introducing errors simply to > reduce the number of lines in the file. -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Am 13.01.23 um 03:40 schrieb Nick Hastings: This debian/copyright file was originally produced by decopy and I adjusted it wherever I found problems. I hesitate to change things that I do not know to be wrong, at the risk of introducing errors simply to reduce the number of lines in the file. If you want this to be sponsored by me, please do so. I will not review a non-reviewable copyright file.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
* Bastian Germann [230104 02:20]: > Control: tags -1 moreinfo > > Am 15.12.22 um 06:40 schrieb Nick Hastings: > > > 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. > > Yes, you would use a glob for the LGPL files and add another block > specifically > for the Expat-licensed file after the LGPL block. Understood. However I do not feel confident that I can correctly make these changes by hand. The above is just one example where I found that using a glob would require an additional section/exception. There are likely many more. This debian/copyright file was originally produced by decopy and I adjusted it wherever I found problems. I hesitate to change things that I do not know to be wrong, at the risk of introducing errors simply to reduce the number of lines in the file.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Control: tags -1 moreinfo Am 15.12.22 um 06:40 schrieb Nick Hastings: 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. Yes, you would use a glob for the LGPL files and add another block specifically for the Expat-licensed file after the LGPL block. Or is possible to not use a glob but instead use a regex that includes everything other than endianness.h? The only other wildcard is ? for a single char. So non-trivial patterns are not really supported. Yes, this is a shortcoming but it also makes the patterns easier to review. I am expecting another review to be triggered by you. Please untag moreinfo from this bug for this.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Am 15.12.22 um 06:40 schrieb Nick Hastings: 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. Okay. Just keep them for now. But when the package is in the archive please register the package with the Security Team to have those embedded copies.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Am 15.12.22 um 06:40 schrieb Nick Hastings: Should I also reupload to mentors? You can skip that. Just notify me and the RFS bug when you want to trigger another review.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Am 15.12.22 um 06:40 schrieb Nick Hastings: 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? License: CC0 On Debian systems, the full text of the Creative Commons Zero 1.0 Universal can be found in the file `/usr/share/common-licenses/CC0-1.0'.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Am 15.12.22 um 06:40 schrieb Nick Hastings: 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? Yes. The NetBSD Foundation allows to relicense their files under BSD-4-clause to BSD-2-clause, see http://www.netbsd.org/about/redistribution.html For the rest of the files you would have to make separate BSD-4-clause variants, e.g. BSD-4-clause-Utah or BSD-4-clause-Adam-Glass.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Am 15.12.22 um 06:40 schrieb Nick Hastings: 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. You would enable the CI at https://salsa.debian.org/nickh/zig/-/settings/ci_cd by setting the CI/CD configuration file to recipes/debian.yml@salsa-ci-team/pipeline
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Hi Bastian,
* Bastian Germann [221219 06:22]:
> A quick note before I forget it: llvm-toolchain-13 is on its way out of
> Debian.
> Can we make this package use the unversioned (default, currently v14)
> llvm packages or v15?
The cmake setup is quite specific about needing v13 so changing it to
greater than v13 would be significant work. Instead I changed it from
v13 to v14. I was able to get it to configure, but the build failed.
make[3]: Leaving directory '/build/zig-0.9.1/obj-x86_64-linux-gnu'
[ 82%] Built target embedded_softfloat
/build/zig-0.9.1/src/zig_llvm-ar.cpp:139:1: error: 'LLVM_ATTRIBUTE_NORETURN'
does not name a type; did you mean 'LLVM_ATTRIBUTE_NODEBUG'?
139 | LLVM_ATTRIBUTE_NORETURN static void badUsage(Twine Error) {
| ^~~
| LLVM_ATTRIBUTE_NODEBUG
/build/zig-0.9.1/src/zig_llvm-ar.cpp:146:1: error: 'LLVM_ATTRIBUTE_NORETURN'
does not name a type; did you mean 'LLVM_ATTRIBUTE_NODEBUG'?
146 | LLVM_ATTRIBUTE_NORETURN static void fail(Twine Error) {
| ^~~
| LLVM_ATTRIBUTE_NODEBUG
I changed these LLVM_ATTRIBUTE_NORETURN to "[[ noreturn ]]" and then the
build failed soon after at:
make[3]: Leaving directory '/build/zig-0.9.1/obj-x86_64-linux-gnu'
[ 82%] Built target embedded_softfloat
/build/zig-0.9.1/src/zig_clang.cpp: In function 'void
ZigClang_detect_enum_TypeClass(clang::Type::TypeClass)':
/build/zig-0.9.1/src/zig_clang.cpp:297:27: error: 'DependentExtInt' is not a
member of 'clang::Type'
297 | case clang::Type::DependentExtInt:
| ^~~
/build/zig-0.9.1/src/zig_clang.cpp:318:27: error: 'ExtInt' is not a member of
'clang::Type'
318 | case clang::Type::ExtInt:
| ^~
So I think the short answer is: no, we can't use LLVM 14 or 15. I guess
it may be possible by patching the source but if that level of effort is
to be spent I think would be better spending it on getting Zig 0.10.0
(which depends on LLVM 15) to build. See
https://github.com/ziglang/zig/issues/13915
Cheers,
Nick.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
A quick note before I forget it: llvm-toolchain-13 is on its way out of Debian. Can we make this package use the unversioned (default, currently v14) llvm packages or v15?
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Hi, thought it may be a little while until I could dig into this but actually found the time today. So here's another quick update. * Nick Hastings [221216 13:15]: > Hi, > > quick update. > > * Nick Hastings [221215 14:40]: > > > * Bastian Germann [221215 08:57]: > > > > > Your package fails to build from scratch on amd64 with a test fail > > > (maybecaused by wrong pwd?): Yes, turns out to be wrong pwd. > > 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. > > I updated my unstable chroot and now build the fails in this way for me > too. I will investigate. I don't actually understand why this ever worked. As I now understand it dh_auto_test is run before dh_auto_install so I had no reason to expect that the binary would already be in debian/zig/usr/bin/zig. Updating this to the build time path fixed this (thanks to pabs and mjt in #debian-mentors). Now all but one of the test suites completes without error. An updated d/rules skips that test suite for now. I was able to build the package on x86_64 unstable with pbuilder. New package uploaded to both mentors and salsa. Cheers, Nick.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Hi, quick update. * Nick Hastings [221215 14:40]: > * Bastian Germann [221215 08:57]: > > > 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. I updated my unstable chroot and now build the fails in this way for me too. I will investigate. Cheers, Nick.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Hi Bastian, * Bastian Germann [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
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Hi Nick, Thanks for draft package. Let's go for 0.9 and when that is in we'll see what version can be packaged next. 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. 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. 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. 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 d/watch === The watch file in your upload differs from the one in git. Please keep them in sync. 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. d/copyright === Please use more wildcards so you do not have to list so many files. 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, 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". The repackaging comment does not only go for musl but also the other 3rd party components. 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. CC0 is in Debian's common-licenses. Please replace the whole text with a reference like in the GPL variants. 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. There is more to come; I have only reviewed the overall appearance of the file. What is the debian.decopy file about? d/patches == Please do not include if you do not have at least one patch.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Hi,
quick progress report.
* Nick Hastings [220615 14:20]:
>
> * Adam Borowski [220603 23:34]:
> > On Fri, Jun 03, 2022 at 09:38:37AM +0900, Nick Hastings wrote:
> >
> > Worst news first: the copyright file requires a lot more work. I see for
> > example unlisted Khronos stuff (lib/libc/include/any-windows-any/{GL,KHR}/),
> > NTP (lib/libc/include/any-linux-any/linux/timex.h), Zope (mingw), ISC,
> > Apache, APSL, ... And the list of copyright holders is even more
> > incomplete. This is a big honking waste of time but it's
> > required... :(
>
> I actually already put quite a bit of effort into the copyright file,
> but it has been a very long time since I last worked on it.
>
> Taking a quick look now I wonder if maybe I have overlooked include
> directories, perhaps assuming that anything in there would be covered by
> src directories. Or maybe I'd just become burned out with it and wanted
> to move on!
>
> Anyway I think I'm ready to dive back in.
The initial copyright file was generated by debmake, have since used
decopy which seems to have found a lot of things that were previously
missed. I'm slowly grinding though it, adding and fixing things. It's
very time consuming, but I'm making progress.
https://github.com/NickHastings/zig-debian/blob/decopy/copyright
> > The package includes a bunch of tests, and with the likelihood of code not
> > handling a particular arch, glibc, etc, I'd say it's a must to run
> > them.
>
> Ok, I'll investigate running the tests.
I've added the tests to debian/rules. However two of them fail. See
https://github.com/NickHastings/zig-debian/blob/tests/rules
It's unclear to me if they are important. Have asked on zig irc, but so
far, no response. Will try to chase it up soon.
> > Not a strict requirement, but a man page would be greatly appreciated.
>
> Will put it on the todo list, but hopefully I can get upstream to do
> something on that front.
This is still sitting untouched at the bottom of the todo list.
Cheers,
Nick.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Hi Adam,
wow, this is unfortunate - gmail flagged this as spam and I only just saw
it now. So please don't interpret my late reply as being from a lack of
motivation.
* Adam Borowski [220603 23:34]:
> On Fri, Jun 03, 2022 at 09:38:37AM +0900, Nick Hastings wrote:
> > * Package name: zig
> > * URL : https://github.com/ziglang/zig
> > * License : Expat, Apache-2, Apache-2 with LLVM exception,
> > CC0, BSD-2-Clause, and LGPL-2+
> > * Vcs : https://github.com/NickHastings/zig-debian
>
> > zig - Imperative, general-purpose, statically typed, system programming
> > language
>
> Hi!
> Worst news first: the copyright file requires a lot more work. I see for
> example unlisted Khronos stuff (lib/libc/include/any-windows-any/{GL,KHR}/),
> NTP (lib/libc/include/any-linux-any/linux/timex.h), Zope (mingw), ISC,
> Apache, APSL, ... And the list of copyright holders is even more
> incomplete. This is a big honking waste of time but it's
> required... :(
I actually already put quite a bit of effort into the copyright file,
but it has been a very long time since I last worked on it.
Taking a quick look now I wonder if maybe I have overlooked include
directories, perhaps assuming that anything in there would be covered by
src directories. Or maybe I'd just become burned out with it and wanted
to move on!
Anyway I think I'm ready to dive back in.
> The package includes a bunch of tests, and with the likelihood of code not
> handling a particular arch, glibc, etc, I'd say it's a must to run
> them.
Ok, I'll investigate running the tests.
> Not a strict requirement, but a man page would be greatly appreciated.
Will put it on the todo list, but hopefully I can get upstream to do
something on that front.
Thanks for taking interest in this package.
Cheers,
Nick.
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
On Fri, Jun 03, 2022 at 09:38:37AM +0900, Nick Hastings wrote:
> * Package name: zig
> * URL : https://github.com/ziglang/zig
> * License : Expat, Apache-2, Apache-2 with LLVM exception,
> CC0, BSD-2-Clause, and LGPL-2+
> * Vcs : https://github.com/NickHastings/zig-debian
> zig - Imperative, general-purpose, statically typed, system programming
> language
Hi!
Worst news first: the copyright file requires a lot more work. I see for
example unlisted Khronos stuff (lib/libc/include/any-windows-any/{GL,KHR}/),
NTP (lib/libc/include/any-linux-any/linux/timex.h), Zope (mingw), ISC,
Apache, APSL, ... And the list of copyright holders is even more
incomplete. This is a big honking waste of time but it's required... :(
The package includes a bunch of tests, and with the likelihood of code not
handling a particular arch, glibc, etc, I'd say it's a must to run them.
Not a strict requirement, but a man page would be greatly appreciated.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi
⠈⠳⣄
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "zig": * Package name: zig Version : 0.9.1-1 Upstream Author : Andrew Kelley * URL : https://github.com/ziglang/zig * License : Expat, Apache-2, Apache-2 with LLVM exception, CC0, BSD-2-Clause, and LGPL-2+ * Vcs : https://github.com/NickHastings/zig-debian Section : devel The source builds a single binary package: zig - Imperative, general-purpose, statically typed, system programming language To access further information about this package, please visit the following URL: https://mentors.debian.net/package/zig/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/z/zig/zig_0.9.1-1.dsc An ITP bug, #995670, has been filed. It can be seen at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995670 Regards, Nick Hastings.
