Bug#1055448: RFS: libsilkit/4.0.37-1 [ITP] -- Simulation in the loop kit by Vector
Hi Tobi, sorry for the long wait. It took some time to fix all problems and synchronize efforts within Vector. Unfortunately, we do not have a plan for community contributions in the short/midterm. This might change in the future, we (the SIL Kit team) just cannot say when it will be happening. For now, we have made the decision to post pone our efforts to package SIL Kit within the Debian archive. Instead, we will shift development completely to the public Github repo and try to grow the community with the goal to accept patches in the future. Thanks again for the feedback and help. Let's hope we can revisit a SIL Kit request in the future. Cheers, Jan On Sun, 12 Nov 2023 11:17:36 +0100 Tobias Frost wrote: > Control: tags -1 moreinfo > > Hi Jan, > > Thanks for your RFS! > as you are listed as upstream contact, let me, as I always do, point you to > https://wiki.debian.org/UpstreamGuide > > As this is your first package your are maintaining, please also read > https://mentors.debian.net/intro-maintainers/ > > This part of the CONTRIBUTING.md concerns me: > We are sorry, but at the moment, we do not accept external contributions > until > wehave established a contribution process. We're working behind the scenes > to > get this ready in the future. Until then, we would kindly ask you to not > open pull > requests. > > This stanca is older than a year (Aug 2022), so when will this happen? > > Sorry to be blunt, but putting a DFSG license on a piece of software and > then saying we do not accept contributions, is (IMHO) not within the > spirit of the Open Source Community, even if it might on paper fullfil > the DFSG. > > This is also problematic for maintaining the package, as how should we, > as Debian, upstream patches, for example if you are go missing for > whatever reasons? Effectively, we would need to maintain a fork, and > that is certainly nothing Vector could want. > > I'd say this brings the RFS very close to the "wontfix" territory, > certainly I will not sponsor this upload, but other sponsors might. > (The review below is partial, done until I saw the README.) > > In Debian we do not package every software. So maybe I'll need a salse > pitch here: > - Why does Vector want it in the Debian archives? > - Why would Debian want it to be in the Debian archives? > - Are there other projects using the library that you intend to package > for Debian? > > On Mon, Nov 06, 2023 at 12:57:23PM +, > =?UTF-8?Q?Kr=C3=a4...@buxtehude.debian.org wrote: > > > * Package name : libsilkit > > Version: 4.0.37-1 > > Upstream contact : jan.krae...@vector.com > > * URL : https://github.com/vectorgrp/sil-kit > > * License : MIT > > * Vcs : https://github.com/vectorgrp/sil-kit > >Section: libs > > > > The source builds the following binary packages: > > > > libsilkit-dev - Development packages for libsilkit > > libsilkit4 - Simulation in the loop kit by Vector > > > > To access further information about this package, please visit the > > following URL: > > > > https://mentors.debian.net/package/libsilkit/ > > > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > > https://mentors.debian.net/debian/pool/main/libs/libsilkit/libsilkit_4.0.37-1.dsc > > > > > > Changes for the initial release: > > libsilkit (4.0.37-1) unstable; urgency=medium > > . > >* Reworked the documentation on Virtual Time Synchronization > >* The documentation of the demo section now refers to the pre built > > Vector > > SIL Kit packages and not to a source build. > > > > An ITP bug for the wnpp package can be found here: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055064 > > Here's a short review on your package: As the build fails, it is likely > to be incomplete. > > - d/changelog: An initial upload has no changes, so it would just say > "Initial upload. Closes: #your-itp-bug." > > (As there is a lots of history in d/changelog: This file is not the > upstream changelog, is about recording changes to the packaging.) > > However, as said, your only entry for the initial upload is as I > described above, delete the rest. > - d/control: > - cmake >= 3.20 is aready fulfiled in stable, you can drop the > versioned part. > - you have a -dev package and a library package - good! > However, I see that you are installing a systemd service file, that > means you also need a non-library binary package so that multi-arch > will work. (something like a -tools package > - manpage: It says it is autogenerated, so you need to generate it > during build. As you are upstream, include the manpages upstream, so > other distributions will benefit too. > > - src/ThirdPArty (most of the directories are empty, possibly
Bug#1055448: RFS: libsilkit/4.0.37-1 [ITP] -- Simulation in the loop kit by Vector
Hi Tobias, Thank you for the quick review. I will try to provide some quick feedback/acknowledgement as well below. On Sun, 12 Nov 2023 11:17:36 +0100 Tobias Frost wrote: > Control: tags -1 moreinfo > > Hi Jan, > > Thanks for your RFS! > as you are listed as upstream contact, let me, as I always do, point you to > https://wiki.debian.org/UpstreamGuide > > As this is your first package your are maintaining, please also read > https://mentors.debian.net/intro-maintainers/ > > This part of the CONTRIBUTING.md concerns me: > We are sorry, but at the moment, we do not accept external contributions >until > wehave established a contribution process. We're working behind the scenes >to > get this ready in the future. Until then, we would kindly ask you to not >open pull > requests. > > This stanca is older than a year (Aug 2022), so when will this happen? > > Sorry to be blunt, but putting a DFSG license on a piece of software and > then saying we do not accept contributions, is (IMHO) not within the > spirit of the Open Source Community, even if it might on paper fullfil > the DFSG. > > This is also problematic for maintaining the package, as how should we, > as Debian, upstream patches, for example if you are go missing for > whatever reasons? Effectively, we would need to maintain a fork, and > that is certainly nothing Vector could want. > > I'd say this brings the RFS very close to the "wontfix" territory, > certainly I will not sponsor this upload, but other sponsors might. > (The review below is partial, done until I saw the README.) > Our team knows that this is not ideal from a community perspective and we are working towards a solution. I will try to get back to you ASAP on these points. > In Debian we do not package every software. So maybe I'll need a salse > pitch here: > - Why does Vector want it in the Debian archives? > - Why would Debian want it to be in the Debian archives? > - Are there other projects using the library that you intend to package > for Debian? > I will probably bundle this with the answer above since both deal with Vectors overall FOSS strategy. > On Mon, Nov 06, 2023 at 12:57:23PM +, > =?UTF-8?Q?Kr=C3=a4...@buxtehude.debian.org wrote: > > > * Package name : libsilkit > > Version : 4.0.37-1 > > Upstream contact : jan.krae...@vector.com > > * URL : https://github.com/vectorgrp/sil-kit > > * License : MIT > > * Vcs : https://github.com/vectorgrp/sil-kit > > Section : libs > > > > The source builds the following binary packages: > > > > libsilkit-dev - Development packages for libsilkit > > libsilkit4 - Simulation in the loop kit by Vector > > > > To access further information about this package, please visit the > > following URL: > > > > https://mentors.debian.net/package/libsilkit/ > > > > Alternatively, you can download the package with 'dget' using this command: For some reason the last part of your email is omitted from the quote, but it seems I missed quite some stuff. Thanks though for the feedback. I will work on a revised version now and update the bug report once it is uploaded. I still have some questions: - Is it permitted to update the libsilkit version (to 4.0.39) within the review process? - The only remaining vendoring is GoogleTest, which is only used for the unit/integration tests which are not shipped by the package. Is this allowed or should we use the systems libraries here as well? - Related, if this is allowed, do we need to include the License information, since we do not ship source files nor object files compiled with these source files in the binary package? Cheers and thanks again for the review, Jan
Bug#1055448: RFS: libsilkit/4.0.37-1 [ITP] -- Simulation in the loop kit by Vector
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libsilkit": * Package name : libsilkit Version : 4.0.37-1 Upstream contact : jan.krae...@vector.com * URL : https://github.com/vectorgrp/sil-kit * License : MIT * Vcs : https://github.com/vectorgrp/sil-kit Section : libs The source builds the following binary packages: libsilkit-dev - Development packages for libsilkit libsilkit4 - Simulation in the loop kit by Vector To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libsilkit/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libs/libsilkit/libsilkit_4.0.37-1.dsc Changes for the initial release: libsilkit (4.0.37-1) unstable; urgency=medium . * Reworked the documentation on Virtual Time Synchronization * The documentation of the demo section now refers to the pre built Vector SIL Kit packages and not to a source build. An ITP bug for the wnpp package can be found here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055064 Regards, Jan Kraemer
Bug#1055064: ITP: libsilkit4 -- library for connecting software-in-the-loop environments
Package: wnpp Severity: wishlist * Package name: libsilkit4 Version : 4.0.37 Upstream Author : Vector Informatik GmbH * URL : https://github.com/vectorgrp/sil-kit * License : MIT Programming Lang: C++ Description : library for connecting software-in-the-loop environments The Vector SIL Kit is an open-source library for connecting Software-in-the-Loop Environments. One of the design goals of SIL Kit is to easily connect different third-party tools, such as emulators (such as QEMU), virtual machines and simulation tools. The goal of having this package within the Debian Package ecosystem is to provide users of SIL Kit an easy and unified way of installing and updating their installation of SIL Kit. We (Vector Informatik GmbH) would offer to package and maintain SIL Kit (libsilkit4). I (Jan Kraemer, jan.krae...@vector.com) would be the primary contact/proposed maintainer. But since we are new to the Debian community we are looking for a sponsor.
Bug#963496: parallel: Input is not forwarded "as it is" anymore
Package: parallel Version: 20161222-1.1 Severity: normal Tags: upstream Dear Maintainer, i got a simple backup solution that relies on parallel and rsync, which was running fine in jessie but is not working in buster anymore. The setup looks like this: xinetd will start "parallel --semaphore -j 10 --fg --id rsyncd rsync --daemon /dev/null" on incomming connections on port 873. What it did in jessie: On an incoming connection xinetd will exec parallel with the socket as input and parallel itself will exec rsync and forward the input to rsync. rsync will notice that the input is a socket and will start working in xinetd-mode. Parallels starts up to 10 concurrent rsync-daemon processes. Every further connection is blocked but not rejected. What it does in buster: On an incomming connection xinetd will exec parallels, which itself executes rsync but rsync crashes because it can't bind port 873. I'm very sure this is a regression and it's resulting from patch a36729cdf39f06d0aa1464bf0c1cd3be8fddba27 in upstream. http://git.savannah.gnu.org/cgit/parallel.git/patch/?id=a36729cdf39f06d0aa1464bf0c1cd3be8fddba27 So i already reverted the patch myself and voilà it works again. I'm quite unsure if this report belongs here or upstream but i then i read: "If necessary, the maintainer of the package will forward the bug upstream." So here you go. Have a nice day. -- System Information: Debian Release: 10.4 APT prefers debian APT policy: (500, 'debian') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages parallel depends on: ii perl 5.28.1-6 ii procps 2:3.3.15-2 ii sysstat 12.0.3-2 parallel recommends no packages. parallel suggests no packages. -- no debconf information
Bug#895204: Acknowledgement (fai-make-nfsroot not using qemu-user-static on "--arch ")
Please forget about the second part of the bug where initrd.img-* & vmlinu?-* are not copied. The correct fai way of resolving this is adding the following lines to NFSROOT within FAI_ETC_DIR: PACKAGES install-norec ARMHF grub-efi-arm #grub-uboot linux-image-armmp
Bug#895204: fai-make-nfsroot not using qemu-user-static on "--arch "
Package: fai-server
Version: 5.6
When running fai-make-nfsroot on amd64 or i386 architecture using e.g.
FAI_DEBOOTSTRAP_OPTS="--exclude=wget --arch armhf"
it does not use qemu-user-static option.
When running fai-make-nfsroot on amd64 or i386 architecture using e.g.
FAI_DEBOOTSTRAP_OPTS="--exclude=wget --arch=armhf"
it does use qemu-user-static option.
While both of above syntax are correct the following line within
fai-make-nfsroot only applies to "--arch=armhf":
263:targetarch=$(expr "$FAI_DEBOOTSTRAP_OPTS" :
'.*--arch=\([^[:space:]]*\)' || true)
My suggestion is to replace this line with the following which handles
both types of given --arch parameter:
targetarch=$(echo "$(expr "$FAI_DEBOOTSTRAP_OPTS" :
'.*--arch=\([^[:space:]]*\)' || expr "$FAI_DEBOOTSTRAP_OPTS" :
'.*--arch\s\([^[:space:]]*\)' || echo true)" | tail -n 1)
If "$targetarch" was set correctly fai-make-nfsroot fails with
following error if executed using e.g.
FAI_DEBOOTSTRAP_OPTS="--exclude=wget --arch=armhf":
Running hooks in /etc/ca-certificates/update.d...
done.
install_packages: executing chroot /srv/fai/nfsroot-armhf1 apt-get clean
install_packages: executing chroot /srv/fai/nfsroot-armhf1 dpkg
--configure --pending
install_packages: executing chroot /srv/fai/nfsroot-armhf1 dpkg -C
install_packages: executing chroot /srv/fai/nfsroot-armhf1 apt-get clean
chmod: missing operand after ‘a+r’
Try 'chmod --help' for more information.
ERROR: No initrd was created. Check the package name of the
linux-image package in /etc/fai/NFSROOT.
Log file written to /var/log/fai/fai-make-nfsroot.log
This is because armhf may be using vlinu?-* & initrd.img-* files for
booting, but not mandatory.
I have worked around this by not copy vlinu?-* & initrd.img-* if
FAI_DEBOOTSTRAP_OPTS is defined for armhf.
(Maybe there is a more general solution for this)
Below is the patch file content which applies the described changes:
--- fai-make-nfsroot2018-04-08 12:00:46.608172000 +0200
+++ fai-make-nfsroot2 2018-04-08 12:22:15.749502200 +0200
@@ -260,7 +260,7 @@
echo "Creating base system using debootstrap version $dversion"
# Check if we need cross architecture debootstrap
-targetarch=$(expr "$FAI_DEBOOTSTRAP_OPTS" :
'.*--arch=\([^[:space:]]*\)' || true)
+targetarch=$(echo "$(expr "$FAI_DEBOOTSTRAP_OPTS" :
'.*--arch=\([^[:space:]]*\)' || expr "$FAI_DEBOOTSTRAP_OPTS" :
'.*--arch\s\([^[:space:]]*\)' || echo true)" | tail -n 1)
hostarch1=$(dpkg --print-architecture)
hostarch2=$(dpkg --print-foreign-architectures)
@@ -543,8 +543,10 @@
# tftp environment
rm -f $NFSROOT/boot/*.bak
mkdir -p $TFTPROOT/pxelinux.cfg
+if [[ ! "${FAI_DEBOOTSTRAP_OPTS}" =~ '--arch'.'armhf' ]];then
chmod a+r $NFSROOT/boot/initrd.img-* || die 9 "No initrd was
created. Check the package name of the linux-image package in
/etc/fai/NFSROOT."
cp -p $v $NFSROOT/boot/vmlinu?-* $NFSROOT/boot/initrd.img-* $TFTPROOT
+fi
cp -u $v $NFSROOT/usr/lib/PXELINUX/pxelinux.0 $TFTPROOT
if [ -f $NFSROOT/usr/lib/syslinux/modules/bios/ldlinux.c32 ]; then
cp -u $NFSROOT/usr/lib/syslinux/modules/bios/ldlinux.c32 $TFTPROOT
Thank you for your support
Bug#742029: tesseract-ocr: Trainingtools missing in SID version (3.03.02-3)
Package: tesseract-ocr Version: 3.03.02-3 Severity: important Dear Maintainer, dear all, I wanted to train some language for use in tesseract and had to realize that the reqired trainingtools are not in the package. i.e. /usr/bin/ambiguous_words /usr/bin/classifier_tester /usr/bin/cntraining /usr/bin/combine_tessdata /usr/bin/dawg2wordlist /usr/bin/mftraining /usr/bin/shapeclustering /usr/bin/unicharset_extractor /usr/bin/wordlist2dawg I downgraded to the debian version 3.02.01-6 which does containt them. Sincerely - Jan Krämer -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-2-amd64 (SMP w/6 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tesseract-ocr depends on: ii libc6 2.18-4 ii libgcc11:4.8.2-16 ii liblept3 1.69-3.1 ii libstdc++6 4.8.2-16 ii libtesseract3 3.02.01-6 ii tesseract-ocr-eng 3.02-2 ii tesseract-ocr-equ 3.02-2 ii tesseract-ocr-osd 3.02-2 tesseract-ocr recommends no packages. tesseract-ocr suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
