Bug#1059711: over here also
Hi, After upgrade to Bookworm upon `systemctl restart slurmd` I got slurmd[41362]: slurmd-hostname: error: mpi/pmix_v4: init: (null) [0]:\mpi_pmix.c:195: pmi/pmix: can not load PMIx library (in 1 physical line) That error was gone after installing package libpmix-dev. sudo apt install libpmix-dev So I think this email confirms the bug and the workaround. Regards Geert Stappers -- Silence is hard to parse
Bug#1066224: radvd_2.19-2_amd64.changes REJECTED
tags 1066224 pending stop On Sun, Apr 21, 2024 at 10:19:31AM +, Debian FTP Masters wrote: > radvd_2.19-2_amd64.deb: trying to install to unstable, but could not find > source (radvd 1:2.19-2) Oops. On the upside: an opportunity to add an tag Groeten Geert Stappers -- Silence is hard to parse
Bug#1066224:
Tags: +acknowledge On Fri, Apr 19, 2024 at 12:02:13PM +0200, Miriam Espana Acebal wrote: > Hi, > > In ubuntu we applied the upstream's fix at > https://github.com/radvd-project/radvd/pull/196. I adapted it to a pair of > patches that I attach here for fixing this FTBFS. > > I am sending this for your consideration, and I hope it helps. We will find out this weekend:-) > --- a/gram.y > +++ b/gram.y > @@ -20,6 +20,10 @@ > > #define YYERROR_VERBOSE 1 > > +int yylex (void); > +void yyset_in (FILE * _in_str); > +int yylex_destroy (void); > + > #if 0 /* no longer necessary? */ > #ifndef HAVE_IN6_ADDR_S6_ADDR > # ifdef __FreeBSD__ > --- a/Makefile.am > +++ b/Makefile.am > @@ -66,9 +66,6 @@ > scanner.c: gram.h > gram.h: gram.c > > -libradvd_parser_a_CFLAGS = \ > - -Wno-implicit-function-declaration > - > libradvd_parser_a_SOURCES = \ > gram.h \ > gram.y \ Groeten Geert Stappers -- Silence is hard to parse
Bug#1064605: [Pkg-rust-maintainers] rustup_1.26.0-5_source.changes ACCEPTED into unstable
On Sun, Mar 17, 2024 at 02:11:37PM +0100, Tobias Frost wrote: > Debian FTP Masters > > > > rustup_1.26.0-5.dsc: Refers to non-existing file 'rustup_1.26.0.orig.tar.xz' > > Perhaps you need to include the file in your upload? > > > > If the orig tarball is missing, the -sa flag for dpkg-buildpackage will be > > your friend. > > The problem was the the sponsoree's dsc included a different orig.tar, > (identical in content, but compressed with xz; If I'd had to guess maybe > gbp created that one.) > > I've reuploaded alrady with the one using the one in the archives, so > this should(tm) appear soon. > Yes, it did. - Forwarded message from Debian FTP Masters - Date: Sun, 17 Mar 2024 13:22:35 + From: Debian FTP Masters To: t...@debian.org, Zixing Liu , Debian Rust Maintainers Subject: [Pkg-rust-maintainers] rustup_1.26.0-5_source.changes ACCEPTED into unstable Thank you for your contribution to Debian. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 24 Feb 2024 14:34:36 -0700 Source: rustup Architecture: source Version: 1.26.0-5 Distribution: unstable Urgency: medium Maintainer: Debian Rust Maintainers Changed-By: Zixing Liu Closes: 1064564 Changes: rustup (1.26.0-5) unstable; urgency=medium . * Team upload. * d/debcargo.toml: declare additional conflict packages for: - rust-web-clippy - rustfmt-web - rust-mozilla-gdb - rust-mozilla-lldb - rust-web-gdb - rust-web-lldb ... so that users can correctly install rustup when those packages are present (by replacing them with rustup). (Closes: #1064564) * d/copyright: update copyright years. * d/control: update Conflicts using debcargo. Checksums-Sha1: e45316006bb96cac88f9df90024b9cf364ef2651 4019 rustup_1.26.0-5.dsc 68b311c6b0f2eae7fdaf1e9eed88ca86d2a92ba8 16984 rustup_1.26.0-5.debian.tar.xz 3533c0a2edbc169d33fc21c26c51b0c01018d94c 24868 rustup_1.26.0-5_amd64.buildinfo Checksums-Sha256: d65d71a09983e527a230711cf806cc3b5bce107c7bc34ec374070a2079155520 4019 rustup_1.26.0-5.dsc 799739439acccd871a2bf87a6f0ffb8bd6abd8514aa11d5c2a33ce14e50f9b66 16984 rustup_1.26.0-5.debian.tar.xz 18e8e8cfc5a92d468d4b8845c863e7a92583b9c84036fc69e317841dfb6dd969 24868 rustup_1.26.0-5_amd64.buildinfo Files: 3fa90be920ca43511b0ec6911456924b 4019 rust optional rustup_1.26.0-5.dsc 5077ba37f31ce8f96a41be7aa1e6a5db 16984 rust optional rustup_1.26.0-5.debian.tar.xz 5d61d24cbeb4c2da8cc77d4c3faba955 24868 rust optional rustup_1.26.0-5_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE/d0M/zhkJ3YwohhskWT6HRe9XTYFAmX26Y8ACgkQkWT6HRe9 XTa1eBAAyU6GRradzzHpQMFSaJvxdAVX7Doxy3LGLrb8JD4pZPsgOZnjLw99tXMX hX8h1Q8/psSWci7ZC7uUf1pI3D7DNgMoOWDe5jcghqmc8m/CnKvq6DsGakKG/6Zb s+0A67Ah2ML6hmVnQ60LiRlsxADnw2b4YBqyX1+Y9Ifa4ubnHwBxGczwgKw9eFF2 3N12QkZUZKRi9A+CMgckvz8F8gkptLQQDkULDarNXg8PjZ3/qVu4MbGTzh7WjWn5 B9ws0cCd6b4NiKlhI/yq5DrcJx62ar9fJKQwZa9w+4lchqdAkkHn7CcZ9cElOyYJ ntGL+RFQCGP1+NE+jWEU5OIqBWBzxmv6g1xUl8ioDGf3dvvWyV/zCsiJItn81KNI +237ttrrzhHgUc63zHtxBqeffDj8J8uAD5NQFxXcDExlA6NDjOnmY/uq0Pea24dY IwEomAcYcbs/qvTEY0QukkaggwDwAuy5OslxupXJ/yJrDy9TF6NrgGLoTzMnWFJL j0tEApieKOPQxjoDU1xCqDrbDzkL09otJ0RC+Da117GUwacG6+86qyoNKshmjfYI 6awgteCl9LlTv/jXraTP6S8b3Z9M1NZZFQtBnapV5N5cNiZI+b8iJ0/2al3afIqL J4GTuj4S4g8Qlc+tMaiUxvQujV9agVLdzl1YE+sb7mE33Gxz1BI= =HpE8 -END PGP SIGNATURE- ___ Pkg-rust-maintainers mailing list pkg-rust-maintain...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers - End forwarded message - Thanks! Groeten Geert Stappers -- Silence is hard to parse
Bug#1064605: [ftpmas...@ftp-master.debian.org: [Pkg-rust-maintainers] rustup_1.26.0-5_source.changes REJECTED]
Hi, In an attempt to express my appreciation for working rustup in Debian, this forwarded message. - Forwarded message from Debian FTP Masters - Date: Sun, 17 Mar 2024 11:32:47 + From: Debian FTP Masters To: Debian Rust Maintainers , t...@debian.org, Zixing Liu Subject: [Pkg-rust-maintainers] rustup_1.26.0-5_source.changes REJECTED rustup_1.26.0-5.dsc: Refers to non-existing file 'rustup_1.26.0.orig.tar.xz' Perhaps you need to include the file in your upload? If the orig tarball is missing, the -sa flag for dpkg-buildpackage will be your friend. === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. ___ Pkg-rust-maintainers mailing list pkg-rust-maintain...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers - End forwarded message - Regards Geert Stappers Should be working on making it possible to be ready for the next RFS for rustup -- Silence is hard to parse
Bug#1061820: Patch looks good
On Mon, Jan 29, 2024 at 08:26:14PM +, Ken Sharp wrote: > > - Turns out I've attached the patch four times. And the patch looks good. Groeten Geert Stappers -- Silence is hard to parse signature.asc Description: PGP signature
Bug#1055167: Network interface lost IP when lease expired after switching from isc-dhcp-client
On Wed, Nov 01, 2023 at 02:44:13PM +0100, Larsen wrote: > ... but instead the package should take care of such a situation. Please add logging of the install ( "apt" ) stop of isc-dhcp-client ( either journalctl or /var/log/ ) and start of udhcpc ( journalctl or log ) Groeten Geert Stappers -- Silence is hard to parse
Bug#1053504: build target not in manual page
Package: caspar Version: 20200611-2 Dear maintainer(s) The manual page of caspar is unaware of the build target. $ grep --context 4 build /usr/include/caspar/mk/caspar.mk | head -n 9 _csp_DIRS := $(shell for d in *; do test -d "$$d" && echo "$$d"; done) _csp_DIRS := $(filter-out $(csp_TABOODIRS),$(_csp_DIRS)) all: $(MAKE) build $(MAKE) install $(MAKE) load define _csp_filetargets $ I noticed the build target in $ make make build make[1]: Entering directory 'path/redacted' make[1]: Nothing to be done for 'build'. make[1]: Leaving directory 'path/redacted' make install make[1]: Entering directory 'path/redacted' redacted command redacted parameters ... more "make output" ... and would like to use it. ( I have an use case for "build", but don't know how to use it.) Please document how to use the build target. Groeten Geert Stappers -- RTFM: read the fine manual
Bug#994081: Patch
Control: tags 994081 +patch
The patch is in Message #47
( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994081#47 )
And attached to this email.
Groeten
Geert Stappers
DD
--
Silence is hard to parse
>From 09bbe34369307aaf25c2139fa62f79742d2e3622 Mon Sep 17 00:00:00 2001
From: Geert Stappers
Date: Sun, 3 Sep 2023 19:34:45 +0200
Subject: [PATCH] Dry run apt check, no abort on fail.
Fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994081
"Upgrade Results in 'apt-get check' Failure"
It is fairly nasty bug. Nasty because it hides well.
Thing is that the `apt check` is during development never called
as a child proces of `apt`. It reveals it self only during
an upgrade by `apt` or `apt-get`, not during a `dpkg --install`.
Adding '--dry-run' is to prevent bail out on
E: Could not get lock /var/lib/dpkg/lock-frontend.
It is held by process PID (apt)
E: Unable to acquire the dpkg frontend lock
Manual page of `apt-get` says about `--dry-run`
Locking will be disabled (Debug::NoLocking) so the system
state could change while apt-get is running.
The removal of 'exit 0' makes it possible that the (build) script
continues. Frankly, I think the whole `apt check` part should
be removed. It is not up to /usr/lib/libdvd-pkg/b-i_libdvdcss.sh
to judge the sanity of the build system.
--dry-run suggested by Alban Browaeys in Message #37
'What does the apt check?' by The Wanderer in Message #10
---
debian/b-i_libdvdcss.sh | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/debian/b-i_libdvdcss.sh b/debian/b-i_libdvdcss.sh
index 536614c..6d77a50 100755
--- a/debian/b-i_libdvdcss.sh
+++ b/debian/b-i_libdvdcss.sh
@@ -43,10 +43,9 @@ if [ $? -ne 0 ]; then
exit 1
fi
-apt-get check >/dev/null 2>&1
+apt-get --dry-run check >/dev/null 2>&1
if [ "$?" -ne 0 ]; then
-echo "${PKGI}: \`apt-get check\` failed, you may have broken packages. Aborting..."
-exit 0
+echo "${PKGI}: \`apt-get --dry-run check\` failed, you may have broken packages."
fi
set -e
--
2.40.1
Bug#994081: [PATCH] Dry run apt check, no abort on fail.
From: Geert Stappers
Fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994081
"Upgrade Results in 'apt-get check' Failure"
It is fairly nasty bug. Nasty because it hides well.
Thing is that the `apt check` is during development never called
as a child proces of `apt`. It reveals it self only during
an upgrade by `apt` or `apt-get`, not during a `dpkg --install`.
Adding '--dry-run' is to prevent bail out on
E: Could not get lock /var/lib/dpkg/lock-frontend.
It is held by process PID (apt)
E: Unable to acquire the dpkg frontend lock
Manual page of `apt-get` says about `--dry-run`
Locking will be disabled (Debug::NoLocking) so the system
state could change while apt-get is running.
The removal of 'exit 0' makes it possible that the (build) script
continues. Frankly, I think the whole `apt check` part should
be removed. It is not up to /usr/lib/libdvd-pkg/b-i_libdvdcss.sh
to judge the sanity of the build system.
--dry-run suggested by Alban Browaeys in Message #37
'What does the apt check?' by The Wanderer in Message #10
---
debian/b-i_libdvdcss.sh | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/debian/b-i_libdvdcss.sh b/debian/b-i_libdvdcss.sh
index 536614c..6d77a50 100755
--- a/debian/b-i_libdvdcss.sh
+++ b/debian/b-i_libdvdcss.sh
@@ -43,10 +43,9 @@ if [ $? -ne 0 ]; then
exit 1
fi
-apt-get check >/dev/null 2>&1
+apt-get --dry-run check >/dev/null 2>&1
if [ "$?" -ne 0 ]; then
-echo "${PKGI}: \`apt-get check\` failed, you may have broken packages.
Aborting..."
-exit 0
+echo "${PKGI}: \`apt-get --dry-run check\` failed, you may have broken
packages."
fi
set -e
--
2.40.1
Bug#1040047: ITP: discord -- All-in-one voice and text chat for gamers
On Sat, Jul 01, 2023 at 05:47:07PM +, matt wrote: > Package: wnpp > Severity: wishlist > Owner: matt > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: discord Discord server? Discord client?Both? > Version : 0.0.27 > Upstream Author : https://discord.com Author is usual a person > * URL : https://discord.com/ Should be location of source code I was at https://discord.com/download but failed to find source. > * License : (custom) License will effect if it goes into 'main', 'contrib' or 'nonfree'. > Programming Lang: (electron) AFAIK is electron a runtime. > Description : All-in-one voice and text chat for gamers > > Discord is a VoIP and instant messaging social platform. > > most foss servers have one example mint it is useful to ask for help there > no there is nothing depending on this package it's standalone > yes I do use it if there are other packages > I don't believe that there are other packages that have similar functions > .sh file that if there is a update download the update inside a packaging team > the package team is discord it's self > I am not looking for co maintainers > yes because this is my first package > I see a mismatch, could be due the age of my eyes. Groeten Geert Stappers -- Silence is hard to parse
Bug#1022061: at Salsa
Hi, > Where is develop happening? } Where is development happening? Seems to be at "salsa". stappers@juli:~/src $ debcheckout debian-kernel-handbook declared git repository at https://salsa.debian.org/kernel-team/kernel-handbook.git git clone https://salsa.debian.org/kernel-team/kernel-handbook.git debian-kernel-handbook ... Cloning into 'debian-kernel-handbook'... remote: Enumerating objects: 1283, done. remote: Counting objects: 100% (228/228), done. remote: Compressing objects: 100% (88/88), done. remote: Total 1283 (delta 169), reused 181 (delta 134), pack-reused 1055 Receiving objects: 100% (1283/1283), 412.97 KiB | 1.10 MiB/s, done. Resolving deltas: 100% (836/836), done. stappers@juli:~/src $ cd debian-kernel-handbook/ stappers@juli:~/src/debian-kernel-handbook $ ls chapter-bugs.dbk chapter-scope.dbk kernel-handbook.dbk chapter-common-tasks.dbk chapter-source.dbkMakefile chapter-initramfs.dbk chapter-update-hooks.dbk po4a chapter-modules.dbk chapter-versions.dbk stylesheet.xsl chapter-packaging.dbk debian stappers@juli:~/src/debian-kernel-handbook $ The silence in this bug report might be transmitting Yes, your contribution is welcome. Regards Geert Stappers -- What is the last time you did something for the first time?
Bug#1033488: Idea: use CROSS_GRADE_TO_ARCH, if set.
> cross-grading an ARM system from armhf to arm64 Idea for supporting such corner cases if environmentvariable CROSS_GRADE_TO_ARCH is set use it else dpkg --print-architecture Groeten Geert Stappers -- Silence is hard to parse
Bug#1031555: new upstream version
Package: salt-master Version: 3004.1+dfsg-2.2 Severity: wishlist Hello, At https://repo.saltproject.io/#about is said there is a 3005.1 version of Salt. I hope that that release fixes the problems that prevent having salt in the next Debian release. Groeten Geert Stappers -- Silence is hard to parse
Bug#1022061: Where is development happening?
Hi Debian Kernel Team, Where is develop happening? Groeten Geert Stappers P.S. At https://salsa.debian.org/kernel-team/kernel-handbook/-/tags is tag 1.20 missing. -- Silence is hard to parse
Bug#1026333: [Pkg-rust-maintainers] rustup in Debian
On Wed, Dec 28, 2022 at 10:44:59PM +, Samuel Henrique wrote: >... bugs are related ... so I'm sending this to at least link > them together for the readers. Thanks for doing that cross linking. > https://bugs.debian.org/955208 The "would be great to have rustup packaged for Debian". > https://bugs.debian.org/1026333 Made it possible that the good idea is visible / findable at https://bugs.debian.org/wnpp > I don't know if the owners want them merged $ pwd /usr/src/debian/rust/debcargo-conf/src/rustup/debian $ head changelog rust-rustup (1.21.1-1) UNRELEASED-FIXME-AUTOGENERATED-DEBCARGO; urgency=medium * Package rustup 1.21.1 from local source using debcargo 2.4.3 -- Ximin Luo Mon, 04 May 2020 18:00:06 +0100 $ So no "Closes: ." yet in the debian/changelog I suggest: --- a/src/rustup/debian/changelog +++ b/src/rustup/debian/changelog @@ -1,5 +1,6 @@ rust-rustup (1.21.1-1) UNRELEASED-FIXME-AUTOGENERATED-DEBCARGO; urgency=medium + * Initial release. Closes: #1026333, #955208 * Package rustup 1.21.1 from local source using debcargo 2.4.3 -- Ximin Luo Mon, 04 May 2020 18:00:06 +0100 Groeten Geert Stappers -- Silence is hard to parse
Bug#1004832: Fwd: hyx_2021.06.09-1_amd64.changes is NEW
- Forwarded message from Debian FTP Masters - Date: Fri, 23 Dec 2022 12:06:09 + From: Debian FTP Masters To: Geert Stappers Subject: hyx_2021.06.09-1_amd64.changes is NEW binary:hyx is NEW. binary:hyx is NEW. source:hyx is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will receive an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html or https://ftp-master.debian.org/backports-new.html for *-backports - End forwarded message - Groeten Geert Stappers -- Silence is hard to parse
Bug#1010082: Heart beat request
Hello Alex, What are you plans with the reasonable request that this[1] bugreport is about? Groeten Geert Stappers [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010082 -- Silence is hard to parse
Bug#1026792: How libre is the license
> * Package name: firebuild > * URL : https://firebuild.com > * License : Firebuild-license Qouting website: License Free for personal use or commercial trial. Non-trial commercial use requires per-computer license available below: Buy license(s) or manage license(s) I do like the 'Buy license', it states "it has value". When sending money are the 100 freedoms still there? 001 Use every where, even for crypto mining 010 Share with others 011 Study the source 100 Modify when deemed Groeten Geert Stappers -- Silence is hard to parse
Bug#1025959: Feedback regarding RFS: davmail/6.0.1.3390-2
On Wed, Dec 14, 2022 at 10:14:09AM +0100, Alexandre Rossi wrote: > Hi, > > > * Add the release "davmail (6.0.1.3390-1.1)" to packaging git repo > > Pushed. Ack > Further changes are awaiting upload to unstable before being pushed. See below > > * Review / improve the `prepare-service` > > This history behind this script is detailed in: > > startup script that copies keystoreFile to StateDirectory (Closes: #968236) > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968236 Seen the "adduser _davmail" advice. And seeing that "adduser _davmail" in debian/davmail-server.postinst (I didn't see that post install script yesterday) > The point is to make available private keys to the daemon. Do you think I need > to add comments to the script to explain the purpose? Yes please, elaborate purpose AND elaborate the if keystore is a file then create keystore file > > * Make that `davmail-service` makes it into `davmail-server` package > > Fixed, thanks and sorry for that. Thanks for fixing and thanks for confirming the "good catch". > > * Ping me > > New source package is on mentors. What about doing this development in a git branch? Your benefit: No need for a `dput` to mentors, just `git push` the branch. My benefit: No need to visit mentors for URL that I can `dget`, just `git pull`. Another benefit for you: No duplicates in reporting progress. Report to "git" by commit message. Tell me the branch name to use. Telling me there won't be such development branch is fine, we use mentors. > Alexandre Groeten Geert Stappers Fully aware that the freeze before the Bookworm release is nearby -- Silence is hard to parse
Bug#1025959: Feedback regarding RFS: davmail/6.0.1.3390-2
On Mon, Dec 12, 2022 at 05:14:23PM +0100, Alexandre Rossi wrote: > Hi, > > > > The source builds the following binary packages: > > > > > > davmail - POP/IMAP/SMTP/CalDav/LDAP to Microsoft Exchange gateway - GUI > > > davmail-server - POP/IMAP/SMTP/CalDav/LDAP to Microsoft Exchange > > > gateway - headless > > > > The -server package is probably new. > > That's why I need a sponsor. Working on it :-) > > What about D.M. upload privileges? > > I have those, but because the -server package goes through NEW, it does not > apply. > > Cheers and thanks, Feedback: * The packaging git repo is not up to date * Systemd unit file `debian/davmail.service` is not installed in davmail-server (Neither in davmail) * Script `debian/prepare-service` feels wrong if keystore is a file then copy+chown keystore else remove keystore That doesn't make sense Request: * Add the release "davmail (6.0.1.3390-1.1)" to packaging git repo * Review / improve the `prepare-service` * Make that `davmail-service` makes it into `davmail-server` package * Ping me > Alexandre Groeten Geert Stappers -- Silence is hard to parse
Bug#1025959: RFS: davmail/6.0.1.3390-2 -- POP/IMAP/SMTP/CalDav/LDAP to Microsoft Exchange gateway
On Mon, Dec 12, 2022 at 03:29:08PM +0100, Alexandre Rossi wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "davmail": :-) > * Package name : davmail >Version : 6.0.1.3390-2 >Upstream contact : Mickaël Guessant > * URL : http://davmail.sourceforge.net/ > * License : GPL-2+-CE, CC0-1.0, GPL-2+, MIT > * Vcs : https://salsa.debian.org/debian/davmail >Section : net > > The source builds the following binary packages: > > davmail - POP/IMAP/SMTP/CalDav/LDAP to Microsoft Exchange gateway - GUI > davmail-server - POP/IMAP/SMTP/CalDav/LDAP to Microsoft Exchange gateway - > headless The -server package is probably new. > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/davmail/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/d/davmail/davmail_6.0.1.3390-2.dsc I will check it tuesday 2022-12-13 CET. > Changes since the last upload: > > davmail (6.0.1.3390-2) unstable; urgency=medium > . >[ Gioele Barabucci ] >* d/postinst: Check systemd via /sbin/init > . >[ Alexandre Rossi ] >* Acknowledge 6.0.1.3390-1.1 NMU >* add sd-notify.patch >* update to policy 4.6.1.0 (no change) >* fix depends-on-essential-package-without-using-version >* update d/copyright year >* clarify depends: split davmail (GUI) and davmail-server (Closes: > #1018809) > > Regards, > Alexandre Rossi Groeten Geert Stappers P.S. What about D.M. upload privileges? -- Silence is hard to parse
Bug#893083: more as just VCS fields
On Sun, Dec 11, 2022 at 05:41:21PM +0100, Santiago Vila wrote: > El 11/12/22 a las 16:25, Geert Stappers escribió: > > I'm fine with deleting the current repo at Salsa > > to make room for a repository that has more history. > > Please do so. https://salsa.debian.org/debian/hello/edit has no "Delete project" button for me. (privileges issue) https://salsa.debian.org/stappers/hello/edit does have that button (for reference purposes) > It's not only about the history but about the conventions, > there is a DEP document which recommends a layout for branches and so on, > and the repo you created (I'm afraid) does not follow it at all. > > This is really not a matter of adding fields to a control file, if that was > all, it would be already done. This really involves a change in the way I'm > maintaining the package, which at this point I'm still not comfortable. > > My plan for this would be to create it under my "sanvila" namespace. > But there are a lot of other work to do which is more important than this. > This is still wishlist. The wish is: Make `debcheckout hello` possible. Thanks for expressing "to create it in sanvila namespace". I confirm that https://salsa.debian.org/debian/hello has only 1 branch. And that one branch makes it possible what this bugreport is about. Groeten Geert Stappers -- Silence is hard to parse
Bug#893083: with more history would be nice
Hi, Three weeks ago it didn't came to my mind that there could be more Debian history found. In my defense, I had only the information of a wishlist bug report open for as four years and version 2.10-2 in unstable and 2.10-1 in old-old-stable. I'm fine with deleting the current repo at Salsa to make room for a repository that has more history. And I'm fine with continueing with the current content in the git repository at Salsa. Thing I'm concerned about is having bookworm released with a hello package without VCS fields. Groeten Geert Stappers DD -- Silence is hard to parse
Bug#893083: Reverted the d/changelog change
Hi, Subject says all. And below the long version: $ vi debian/changelog $ git commit -a [debian/main f50b783] Revert the d/changelog change 1 file changed, 7 deletions(-) $ git commit --amend --author 'Geert Stappers ' [debian/main 85cdb0f] Revert the d/changelog change Author: Geert Stappers Date: Sun Nov 20 22:28:50 2022 +0100 1 file changed, 7 deletions(-) $ git show commit 85cdb0f6e38eaea4cbe72f6ba8d46787de5f602a (HEAD -> debian/main) Author: Geert Stappers Date: Sun Nov 20 22:28:50 2022 +0100 Revert the d/changelog change Makes room for other paths as a path via a NMU. diff --git a/debian/changelog b/debian/changelog index fc1ca45..df4a850 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,10 +1,3 @@ -hello (2.10-2.1) UNRELEASED; urgency=medium - - * Non-maintainer upload. - * Added Vcs-fields to d/control Closes: #893083. - - -- Geert Stappers Sun, 20 Nov 2022 17:47:38 +0100 - hello (2.10-2) unstable; urgency=medium * Fix version skew. Closes: #928887. $ git push Enumerating objects: 7, done. Counting objects: 100% (7/7), done. Delta compression using up to 12 threads Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 419 bytes | 419.00 KiB/s, done. Total 4 (delta 3), reused 0 (delta 0), pack-reused 0 To salsa.debian.org:debian/hello.git f55bbe9..85cdb0f debian/main -> debian/main $ Groeten Geert Stappers -- Silence is hard to parse
Bug#893083: Hello Vcs fields
On Sun, Nov 20, 2022 at 07:48:04PM +0100, Santiago Vila wrote: > El 20/11/22 a las 18:27, Geert Stappers escribió: > > tag 893083 + pending > > Please don't. > While I agree that it would be better to use git, > forcing it via NMUs is unwelcome. Which way will it be? Groeten Geert Stappers -- Silence is hard to parse signature.asc Description: PGP signature
Bug#893083: git pushed
user debian-rele...@lists.debian.org usertag 893083 + bsp-2022-11-nl-tilburg tag 893083 + pending thank you |$ git push --set-upstream origin debian/main |Enumerating objects: 332, done. |Counting objects: 100% (332/332), done. |Delta compression using up to 12 threads |Compressing objects: 100% (327/327), done. |Writing objects: 100% (332/332), 813.38 KiB | 9.68 MiB/s, done. |Total 332 (delta 95), reused 0 (delta 0), pack-reused 0 |remote: Resolving deltas: 100% (95/95), done. |To salsa.debian.org:debian/hello.git | * [new branch] debian/main -> debian/main |branch 'debian/main' set up to track 'origin/debian/main'. |$ git remote -v |origin g...@salsa.debian.org:debian/hello.git (fetch) |origin g...@salsa.debian.org:debian/hello.git (push) |$ git show |commit f55bbe9bcd1f3aa4632ded1f53eaff6ddd0dc52d (HEAD -> debian/main, origin/debian/main) |Author: Geert Stappers |Date: Sun Nov 20 17:50:33 2022 +0100 | |Added Vcs URL to d/control | |diff --git a/debian/changelog b/debian/changelog |index df4a850..fc1ca45 100644 |--- a/debian/changelog |+++ b/debian/changelog |@@ -1,3 +1,10 @@ |+hello (2.10-2.1) UNRELEASED; urgency=medium |+ |+ * Non-maintainer upload. |+ * Added Vcs-fields to d/control Closes: #893083. |+ |+ -- Geert Stappers Sun, 20 Nov 2022 17:47:38 +0100 |+ | hello (2.10-2) unstable; urgency=medium | | * Fix version skew. Closes: #928887. |diff --git a/debian/control b/debian/control |index fd41939..672a489 100644 |--- a/debian/control |+++ b/debian/control |@@ -5,6 +5,8 @@ Maintainer: Santiago Vila | Standards-Version: 4.3.0 | Build-Depends: debhelper-compat (= 9) | Homepage: http://www.gnu.org/software/hello/ |+Vcs-Browser: https://salsa.debian.org/debian/hello |+Vcs-Git: https://salsa.debian.org/debian/hello.git | Rules-Requires-Root: no | | Package: hello |$ The 'tag 893083 + pending'-upload will to delay queue twenty days. Groeten Geert Stappers -- Silence is hard to parse
Bug#940511: Our mutual interest in /usr/bin/yarn
On Wed, Nov 09, 2022 at 09:21:15PM +0100, Geert Stappers wrote: > Hello JavasScript people, > Hello Python people, > :-) > > We both want to use /usr/bin/yarn for a program, > unfortunately different programs. > > What about agreeing on a disagreement? > > So binary packages cmdtest and yarnpkg conflict each other? > After rethinking that: It might work for a large part, but it realy blocks the people who want to install both packages. The plan is now to patch the debian yarnpkg package so it has clearly visible that it provides `yarn`. Groeten Geert Stappers -- Silence is hard to parse
Bug#973922: Claimed time for working on it
user debian-rele...@lists.debian.org usertag 973922 + bsp-2022-11-nl-tilburg thank you Subject says all Groeten Geert Stappers P.S. Different to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973922#47 - bugnumber ( not "-1" ) Groeten Geert Stappers -- Silence is hard to parse
Bug#973922: Claimed time for working on it
user debian-rele...@lists.debian.org usertag -1 + bsp-2022-11-nl-tilburg thank you Subject says all Groeten Geert Stappers P.S. Different to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973922#42 - Cc: cont...@bugs.debian.org - usertag( not usertags ( singular versus plural ) -- Silence is hard to parse
Bug#973922: Claimed time for working on it
user debian-rele...@lists.debian.org usertags -1 + bsp-2022-11-nl-tilburg thank you Subject says all Groeten Geert Stappers -- Silence is hard to parse
Bug#940511: Our mutual interest in /usr/bin/yarn
Hello JavasScript people, Hello Python people, We both want to use /usr/bin/yarn for a program, unfortunately different programs. What about agreeing on a disagreement? So binary packages cmdtest and yarnpkg conflict each other? Regards Geert Stappers DD -- Silence is hard to parse signature.asc Description: PGP signature
Bug#859130: s/git/diff/
Oops. In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859130#83 should command 'git' be replaced with 'diff'. Correct text is Wanted: Upon having a directory with a subdirectory containing the git repo and another subdir containing the orig tarball should diff -ur --exclude=.git git_repo_dir/ orig_tarball_dir/ report _no differences_ Groeten Geert Stappers -- Silence is hard to parse
Bug#808940: Getting an executable
Hi, Here my summary and notes on https://github.com/hashicorp/terraform/blob/main/.github/CONTRIBUTING.md#terraform-clicore-development-environment Having `git` and `golang-go` installed. Have "hello world" for go compiled and run, so you know that it works. Copy and paste this in your command line terminal: git clone https://github.com/hashicorp/terraform.git cd terraform/ go install . ls -lh $(go env GOPATH)/bin/terraform $(go env GOPATH)/bin/terraform version This what you can expect as output stappers@myhost:/usr/src/github $ git clone https://github.com/hashicorp/terraform.git Cloning into 'terraform'... remote: Enumerating objects: 264828, done. remote: Counting objects: 100% (244/244), done. remote: Compressing objects: 100% (146/146), done. remote: Total 264828 (delta 139), reused 174 (delta 94), pack-reused 264584 Receiving objects: 100% (264828/264828), 231.55 MiB | 1.74 MiB/s, done. Resolving deltas: 100% (164863/164863), done. stappers@myhost:/usr/src/github $ cd terraform/ stappers@myhost:/usr/src/github/terraform $ go install . most likely several lines of "downloading something" and no additional output stappers@myhost:/usr/src/github/terraform $ ls -lh $(go env GOPATH)/bin/terraform -rwxr-xr-x 1 gs0604 gs0604 82M 19 sep 20:49 /home/stappers/go/bin/terraform stappers@myhost:/usr/src/github/terraform $ $(go env GOPATH)/bin/terraform version Terraform v1.3.0-dev on linux_amd64 stappers@myhost:/usr/src/github/terraform $ What me did surprise, was how quick / fast the compile is after the download. I was wondering "Already now a succesfull build?" In doubt I did another `go install .` which was immediatly finished. Yes, that build went again fast. To get the executable "installed" I did: sudo ln -s /home/stappers/go/bin/terraform /usr/bin/ That symlink will help to be up to date with what is build. Groeten Geert Stappers -- Silence is hard to parse
Bug#808940: https://github.com/hashicorp/terraform/issues/27378#issuecomment-1251244275
Hello, Core of this Debian bug tracking system update is https://github.com/hashicorp/terraform/issues/27378#issuecomment-1251244275 - Forwarded message from Martin Atkins - Date: Mon, 19 Sep 2022 09:20:23 -0700 From: Martin Atkins To: hashicorp/terraform Cc: Geert Stappers , Comment Subject: Re: [hashicorp/terraform] Publish arm64 Terraform packages in the HashiCorp "apt" repository (Debian/Ubuntu packages) (#27378) It seems that this Debian RFP originally started in 2015 while Terraform v0.6 was the current version, and consequently it got bogged down in the fact that Terraform v0.6 still had all of the HashiCorp-distributed providers directly in the main distribution and therefore the package would need to depend on the union of all dependencies of all of the providers. Thankfully that hasn't been true since Terraform v0.10, and also with Terraform v1.0 establishing [the v1.x compatibility promises](https://www.terraform.io/language/v1-compatibility-promises) the rate of change to Terraform is slower now and so probably a more appropriate speed for Debian's process such that the version available in Debian Stable is likely to remain useful for longer than Terraform v0.6 would've. With all of that said: we unfortunately don't have the resources to participate directly in the packaging processes for Debian and other distributions. While we certainly would not object to Terraform being packaged in Debian (nor should we!), I think it would be necessary for someone in the Debian developer community to manage that particular packaging. In particular, I don't think our methodology for building APT packages would be acceptable for the main Debian repository: we take literally the `terraform` executable from the official `.zip` packages and copy it into a Debian binary package, whereas the main Debian repository must always be buildable from source code. That is technically possible to do but not how our own in-house packaging processes are built. -- Reply to this email directly or view it on GitHub: https://github.com/hashicorp/terraform/issues/27378#issuecomment-1251244275 You are receiving this because you commented. Message ID: - End forwarded message - I triggered that response with https://github.com/hashicorp/terraform/issues/27378#issuecomment-1251224003 which boils down to "cross reference link to Debian BTS issue, have Terraform in Debian means have it available for release architectures" -- Silence is hard to parse
Bug#1004832: ping qrpnxz, revival \o/
On Thu, Sep 08, 2022 at 09:26:40AM +0200, Geert Stappers wrote: > On Wed, Sep 07, 2022 at 04:54:26PM -0500, Russell Hernandez Ruiz wrote: > > I've got Salsa access now. I will push what I have in the next few > > days. > > OK > A few minutes ago I granted account 'qrpnxz' developer access to https://salsa.debian.org/debian/hyx
Bug#1004832: ping qrpnxz, revival \o/
On Wed, Sep 07, 2022 at 04:54:26PM -0500, Russell Hernandez Ruiz wrote: > I've got Salsa access now. I will push what I have in the next few > days. OK > I'll check for newer versions, and add the bits necessary to > allow the automatic checking of updates. Also good. Do known: * That perfect is the enemy good. * I'm fine with uploading the "what I have" version, letting that migrate to testing. And then uploading a newer version. So we can verify checking of updates. * Not every message on this ITP needs to go to the BTS Groeten Geert Stappers BTS Bug Tracking System (for us 1004...@bugs.debian.org) -- Silence is hard to parse
Bug#1004832: ping qrpnxz
Is it Salsa account qrpnxz for Russell Hernandez Ruiz that is missing for continueing this ITP? Groeten Geert Stappers -- Silence is hard to parse
Bug#1012999: Avoiding removal from testing (attempt)
Control: notfound -1 8.1-2 Hi, This e-mail is (an attempt) to prevent that msc-generator gets removed from testing. Originally was the bugreport serverity normal and had the request "leave it to us". Later became the serverity "serious" The "leave it us" is still a good thing. Yes, I appriciate the work that "archive rebuild people" do. But the unpredicable next rebuild run. http://qa-logs.debian.net/2022/04/ Index of /2022/04 [ICO] NameLast modified SizeDescription [PARENTDIR] Parent Directory- [DIR] 12/ 2022-04-12 18:36- Apache/2.4.54 (Debian) Server at qa-logs.debian.net Port 80 http://qa-logs.debian.net/2022/05/ Index of /2022/05 [ICO] NameLast modified SizeDescription [PARENTDIR] Parent Directory- [DIR] 25/ 2022-05-26 05:47- Apache/2.4.54 (Debian) Server at qa-logs.debian.net Port 80 http://qa-logs.debian.net/2022/06/ Index of /2022/06 [ICO] NameLast modified SizeDescription [PARENTDIR] Parent Directory- [DIR] 09/ 2022-06-10 18:50- [DIR] 10/ 2022-06-11 20:24- [DIR] 23/ 2022-06-23 06:25- [DIR] 24/ 2022-06-24 06:40- Apache/2.4.54 (Debian) Server at qa-logs.debian.net Port 80 http://qa-logs.debian.net/2022/07/ Index of /2022/07 [ICO] NameLast modified SizeDescription [PARENTDIR] Parent Directory- [DIR] 16/ 2022-07-16 12:45- [DIR] 28/ 2022-07-29 13:20- Apache/2.4.54 (Debian) Server at qa-logs.debian.net Port 80 http://qa-logs.debian.net/2022/08/ Not Found The requested URL was not found on this server. Apache/2.4.54 (Debian) Server at qa-logs.debian.net Port 80 At https://buildd.debian.org/status/logs.php?pkg=msc-generator could I not find a full log. But I have seen that msc-generator builds with GCC 12.1, so now this close message. That is what the 'Control: notfound -1 8.1-2' should do. Regards Geert Stappers DD P.S. The https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012999#29 question: 'Where to find information about the rebuild schedule?' is still valid -- Silence is hard to parse
Bug#1016546: rust-vergen inserts build timestamps
Date: Tue, 2 Aug 2022 19:18:46 +0200, From: Maxime Devos > > In Guix, I've noticed that rust-vergen embeds build timestamps. There is also > a work-around available: <https://issues.guix.gnu.org/56893#1>. Thanks for reporting the FTBR. Please update the workaround, so it looks more like https://en.wikipedia.org/wiki/Diff#Unified_format and can be absured by https://en.wikipedia.org/wiki/Patch_(Unix) Just telling the filename that needs modification would be a great help. Groeten Geert Stappers Has set Reply-To to wanted destination (the BTS). -- Silence is hard to parse
Bug#1016546: rust-vergen inserts build timestamps
Package: rust-vergen Version: 3.0.4-2 Severity: serious Justify: fails to build reproducible Tags: +patch - Forwarded message from Maxime Devos - Date: Tue, 2 Aug 2022 19:18:46 +0200 From: Maxime Devos To: debian-r...@lists.debian.org Subject: rust-vergen is irreproducible and causes irreproducibility User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Hi, In Guix, I've noticed that rust-vergen embeds build timestamps. There is also a work-around available: <https://issues.guix.gnu.org/56893#1>. Greetings, Maxime. pub EdDSA 256/191725EE 2020-10-14 Maxime Devos sub ECDH 256/52A5D546 2020-10-14 - End forwarded message - Groeten Geert Stappers -- Silence is hard to parse
Bug#1012999: keep the issue open until the package can be built in a follow-up test rebuild.
Hello, Where to find information about the rebuild schedule? The some what template text |[This bug is targeted to the upcoming bookworm release] | |Please keep this issue open in the bug tracker for the package it |was filed for. If a fix in another package is required, please |file a bug for the other package (or clone), and add a block in this |package. Please keep the issue open until the package can be built in |a follow-up test rebuild. | |The package fails to build in a test rebuild on at least amd64 with |gcc-12/g++-12, but succeeds to build with gcc-11/g++-11. The |severity of this report will be raised before the bookworm release. does not provide any information about it. Groeten Geert Stappers P.S. Please keep 1012...@bugs.debian.org in the loop. -- Silence is hard to parse
Bug#1012999: Uploaded
FWIW Uploads did happen ( https://tracker.debian.org/news/1349600/accepted-msc-generator-81-1-source-into-unstable/ and https://tracker.debian.org/news/1349742/accepted-msc-generator-81-2-source-into-unstable/ ). At https://buildd.debian.org/status/package.php?p=msc-generator is currently: | Buildd exposure stats all 8.1-2 Installed 1h 5m x86-grnet-02 miscold | all (1) giveback | Buildd exposure stats amd64 8.1-2 Installed 1h 6m x86-ubc-01 miscold | all (1) giveback | Buildd exposure stats arm64 8.1-2 Installed 51m arm-arm-03 miscold | all (1) giveback | Buildd exposure stats armel 8.1-2 Installed 51m arm-ubc-06 miscold | all (1) giveback | Buildd exposure stats armhf 8.1-2 Installed 8m arm-arm-04 miscold | all (2) giveback | Buildd exposure stats i3868.1-2 Installed 1h 6m x86-grnet-01 miscold | all (1) giveback | Buildd exposure stats mips64el8.1-2 Installed 51m mipsel-osuosl-03miscold | all (1) giveback | Buildd exposure stats mipsel 8.1-2 Installed 28m mipsel-manda-04 miscold | all (1) giveback | Buildd exposure stats ppc64el 8.1-2 Installed 1h 6m ppc64el-osuosl-01 miscold | all (1) giveback | Buildd exposure stats s390x 8.1-2 Installed 1h 5m zani misc old | all (1) giveback In other words: Succesfull builds on all release architectures. Groeten Geert Stappers -- Silence is hard to parse
Bug#1015730: move more
Control: tag -1 patch stop The "fix me"s needs more TLC On Tue, Jul 26, 2022 at 10:08:22AM +0200, Zozó Teki wrote: > Now it says; > "NOTE! We have moved to https://gitlab.com/msc-generator/msc-generator >All development happens there. >Also, download new releases & submit issues there." > > --- a/debian/control +++ b/debian/control @@ -9,9 +9,9 @@ Build-Depends: debhelper-compat (=13), g++ (>=10), automake, bison, flex, fonts-droid-fallback, fonts-urw-base35, fonts-dejavu-core Standards-Version: 4.6.1 -Homepage: https://sourceforge.net/projects/msc-generator -Vcs-Browser: https://sourceforge.net/p/msc-generator/gcode/ci/debian/unstable/~/tree/ -Vcs-Git: git://git.code.sf.net/p/msc-generator/gcode -b debian/unstable +Homepage: https://moved.to.gitlab/fix/me +Vcs-Browser: https://moved.to.gitlab/fix/me +Vcs-Git: git://git.code.moved.to.gitlab/fix/me Rules-Requires-Root: no Package: msc-generator
Bug#1015730: Please elaborate the move
On Tue, Jul 26, 2022 at 10:08:22AM +0200, Zozó Teki wrote: > Now it says; > "NOTE! We have moved to https://gitlab.com/msc-generator/msc-generator >All development happens there. >Also, download new releases & submit issues there." > > Is this better? Yes, much better. Thanks Regards Geert Stappes Live from https://mch2022.org
Bug#1015887: debian-installer: Adding https repo doesn't work without manually installing ca-certificates
On Sun, Jul 24, 2022 at 12:15:24AM +1200, Richard Hector wrote: > On 23/07/22 23:01, Cyril Brulebois wrote: > > > As mentioned by Julien, getting the installer's syslog (compressed, to > > make sure it reaches the mailing list) would help understand what's > > going on. > > Oh - uncompressed, it made it into the BTS, https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1015887;filename=syslog;msg=27 Jul 23 01:08:13 in-target: Err:1 https://deb.debian.org/debian bullseye InRelease Jul 23 01:08:13 in-target: Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 2a04:4e42:27::644 443] Jul 23 01:08:13 in-target: Reading package lists... Jul 23 01:08:13 in-target: Jul 23 01:08:13 in-target: W: https://deb.debian.org/debian/dists/bullseye/InRelease: No system certificates available. Try installing ca-certificates. Jul 23 01:08:13 in-target: W: Failed to fetch https://deb.debian.org/debian/dists/bullseye/InRelease Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 2a04:4e42:27::644 443] Jul 23 01:08:13 in-target: W: Some index files failed to download. They have been ignored, or old ones used instead. Jul 23 01:08:13 apt-setup: dpkg-divert: warning: diverting file '/sbin/start-stop-daemon' from an Essential package with rename is dangerous, use --no-rename Jul 23 01:08:14 in-target: Err:1 https://deb.debian.org/debian bullseye InRelease Jul 23 01:08:14 in-target: Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 2a04:4e42:27::644 443] Jul 23 01:08:14 in-target: Reading package lists... Jul 23 01:08:14 in-target: Jul 23 01:08:14 in-target: W: https://deb.debian.org/debian/dists/bullseye/InRelease: No system certificates available. Try installing ca-certificates. Jul 23 01:08:14 in-target: W: Failed to fetch https://deb.debian.org/debian/dists/bullseye/InRelease Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 2a04:4e42:27::644 443] Jul 23 01:08:14 in-target: W: Some index files failed to download. They have been ignored, or old ones used instead. no traces of manual install of ca-certificates found by me. Regards Geert Stappers Failed to explain that httpS is NOT needed for apt. Agrees that it is nice to have ca-certificates installed. -- Silence is hard to parse
Bug#1015887: debian-installer: Adding https repo doesn't work without manually installing ca-certificates
Control: severity -1 wishlist On Sat, Jul 23, 2022 at 03:49:55PM +1200, Richard Hector wrote: > Dear Maintainer, > > Using netinst bullseye 11.4 installer: > > https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.4.0-amd64-netinst.iso > > I chose to add a network mirror, using https, and the default > 'deb.debian.org'. > > I used (non-graphical) Expert Mode. > > The problem first showed up when tasksel only displayed 'standard system > utilities'. When I went ahead with that, the next screen was a red > 'Installation step failed' screen. > > The log on tty4 showed various dependency problems. > > I tried to 'chroot /target' and 'apt update', which showed certificate > problems. I then ran 'apt install ca-certificates', which worked > (installing from the cd image?), after which 'apt update' worked, and I > was also able to continue successfully with the installer. > > I was able to reproduce this in a (kvm/qemu) VM (which is where I > confirmed my steps); the original problem was on an HP Thin Client > (t520). In both cases only 8G of storage was available. > > It all works fine using http for the mirror. And the archive mirror content is secured by checksums and signatures. > I'm happy to do further testing with the VM; the thin client is less > convenient as it has a job to do. Another job that will help: Find other bug reports that ask for installing ca-certificates. Yeah, I recall have I seen such requests before. Groeten Geert Stappers -- Silence is hard to parse
Bug#1015730: Please elaborate the move
Hi msc-generator people, At https://sourceforge.net/projects/msc-generator/ is NOTE! We have moved to https://gitlab.com/msc-generator/msc-generator Download releases, submit issues there. and the text that is there since a long time. I don't understand the strange relocation. I can understand "We are tiring to find an alternative for Source Force". It is the choice for SCM, Source Code Management, site gitlab.com for file distribution and issue tracker that makes it a strange move. I could have understand NOTE! We have moved to https://gitlab.com/msc-generator/msc-generator also NOTE! We have moved to https://gitlab.com/msc-generator/msc-generator as new home or NOTE! We have moved to https://gitlab.com/msc-generator/msc-generator Git clone & git pull, Download releases and submit issues there. My misunderstanding might be that I can't see what is the leading git repository. Both, SF & GL, repos have recent changes in git. It is "Where does the development happen" that I would like to have clarified. And I think other msc-generator users ought to know that. Regards Geert Stappers Debian Developer, did upload msc-generator into Debian
Bug#1015730: Upstream is on the move
Package: msc-generator Version: 7.2.1-1 Severity: normal Hi, Upstream is on the move, maybe upstream was on the move. Thing is that they stopped publishing releases at the place we have defined in debian/watch, so `uscan` is blind for new releases. Groeten Geert Stappers -- Silence is hard to parse
Bug#1012999: tagging and additional text
control: tags -1 confirmed Hi, Here a potential uploading sponsor. Thing I want to tell^W^W^Wtelling is that I have seen the Please keep the issue open until the package can be built in a follow-up test rebuild. Groeten Geert Stappers -- Silence is hard to parse
Bug#1014694: a possible solution
Hi, With 'User=www-data' and 'Group=www-data' in `/lib/systemd/system/caddy.service` does `caddy` start. But that local modification will be overwritten upon upgrades (and re-installs). Having a group 'caddy' and a user 'caddy' is a better solution. What I did: |stappers@hop:~ |$ sudo addgroup --system caddy |Adding group `caddy' (GID 119) ... |Done. |stappers@hop:~ |$ |stappers@hop:~ |$ sudo adduser --system --home /var/www --shell /usr/sbin/nologin --no-create-home --ingroup caddy caddy |Warning: The home dir /var/www you specified can't be accessed: No such file or directory |Adding system user `caddy' (UID 109) ... |Adding new user `caddy' (UID 109) with group `caddy' ... |Not creating home directory `/var/www'. |stappers@hop:~ |$ Comparing the result with 'www-data' |stappers@hop:~ |$ grep -e www-data -e caddy /etc/passwd |www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin |caddy:x:109:119::/var/www:/usr/sbin/nologin |stappers@hop:~ |$ Please consider to add addgroup --system caddy adduser --system --home /var/www --shell /usr/sbin/nologin --no-create-home --ingroup caddy caddy to the maintainer scripts. Groeten Geert Stappers -- Silence is hard to parse
Bug#1014694: caddy.service: Failed to determine user credentials: No such process
Package: caddy Version: 2.4.6-2 Severity: serious Justification: package usable Hello, For me, on Debian Testing, doesn't Caddy start. How I installed: |stappers@hop:~ |$ wget http://ftp.nl.debian.org/debian/pool/main/c/caddy/caddy_2.4.6-2_amd64.deb |--2022-07-10 11:15:44-- http://ftp.nl.debian.org/debian/pool/main/c/caddy/caddy_2.4.6-2_amd64.deb |Resolving ftp.nl.debian.org (ftp.nl.debian.org)... 2001:67c:2564:a120::21, 130.89.149.21 |Connecting to ftp.nl.debian.org (ftp.nl.debian.org)|2001:67c:2564:a120::21|:80... connected. |HTTP request sent, awaiting response... 200 OK |Length: 8073508 (7.7M) [application/x-debian-package] |Saving to: ‘caddy_2.4.6-2_amd64.deb’ | |caddy_2.4.6-2_amd64.deb 100%[==>] 7.70M --.-KB/sin 0.05s | |2022-07-10 11:15:44 (141 MB/s) - ‘caddy_2.4.6-2_amd64.deb’ saved [8073508/8073508] | |stappers@hop:~ |$ sudo dpkg -i caddy_2.4.6-2_amd64.deb |Selecting previously unselected package caddy. |(Reading database ... 26988 files and directories currently installed.) |Preparing to unpack caddy_2.4.6-2_amd64.deb ... |Unpacking caddy (2.4.6-2) ... |Setting up caddy (2.4.6-2) ... |Processing triggers for man-db (2.10.2-1) ... |stappers@hop:~ |$ systemctl status caddy |○ caddy.service - Caddy | Loaded: loaded (/lib/systemd/system/caddy.service; disabled; vendor preset: enabled) | Active: inactive (dead) | Docs: https://caddyserver.com/docs/ |stappers@hop:~ |$ What I have, including error message "Failed to determine user credentials": |stappers@hop:~ |$ dpkg -l caddy |Desired=Unknown/Install/Remove/Purge/Hold || Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend ||/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) |||/ Name Version Architecture Description |+++-==---= |ii caddy 2.4.6-2 amd64Fast, lightweight web server with automatic HTTPS |stappers@hop:~ |$ systemctl --failed | UNIT LOAD ACTIVE SUBDESCRIPTION |● caddy.service loaded failed failed Caddy | |LOAD = Reflects whether the unit definition was properly loaded. |ACTIVE = The high-level unit activation state, i.e. generalization of SUB. |SUB= The low-level unit activation state, values depend on unit type. |1 loaded units listed. |stappers@hop:~ |$ systemctl status caddy |× caddy.service - Caddy | Loaded: loaded (/lib/systemd/system/caddy.service; disabled; vendor preset: enabled) | Active: failed (Result: exit-code) since Sun 2022-07-10 11:16:23 UTC; 42min ago | Docs: https://caddyserver.com/docs/ |Process: 189961 ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile (code=exited, status=217/USER) | Main PID: 189961 (code=exited, status=217/USER) |CPU: 2ms | |Jul 10 11:16:23 hop systemd[1]: Starting Caddy... |Jul 10 11:16:23 hop systemd[189961]: caddy.service: Failed to determine user credentials: No such process |Jul 10 11:16:23 hop systemd[189961]: caddy.service: Failed at step USER spawning /usr/bin/caddy: No such process |Jul 10 11:16:23 hop systemd[1]: caddy.service: Main process exited, code=exited, status=217/USER |Jul 10 11:16:23 hop systemd[1]: caddy.service: Failed with result 'exit-code'. |Jul 10 11:16:23 hop systemd[1]: Failed to start Caddy. |stappers@hop:~ |$ The unit file, without comment line, note the 'User=caddy' being present |stappers@hop:~ |$ systemctl cat caddy | grep -v ^\# | |[Unit] |Description=Caddy |Documentation=https://caddyserver.com/docs/ |After=network.target network-online.target |Requires=network-online.target | |[Service] |Type=notify |User=caddy |Group=caddy |ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile |ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile |TimeoutStopSec=5s |LimitNOFILE=1048576 |LimitNPROC=512 |PrivateTmp=true |ProtectSystem=full |AmbientCapabilities=CAP_NET_BIND_SERVICE | |[Install] |WantedBy=multi-user.target |stappers@hop:~ |$ But user 'caddy' is not present. |stappers@hop:~ |$ id caddy |id: ‘caddy’: no such user |stappers@hop:~ |$ I think that is the reason for caddy.service: Failed to determine user credentials: No such process Regards Geert Stappers Will reply to this bugreport with possible solution -- Silence is hard to parse
Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel")
On Mon, Jun 27, 2022 at 03:00:22PM +0100, lkcl wrote: > hi Geert, ;-) > sorry i have an odd mailer which can only toppost. Acknowledge on "odd mailer" and thanks for NOT poluting the Bug Tracking System with topposts (thanks for preventing needless scrolling) > as in the initial post, i found a link that indicates that such explicit > requests are in direct violation of DFSG Section 8, namely that others > (including Derivatives) may take the source that goes through Debian > and continue to use and distribute it without limit or restriction. Ah, I missed that. > the message to the Mozilla Foundation needs to be more along the lines, > "please remove the restriction from the Trademark License so that we > may comply with DFSG Section 8, otherwise we have to do an iceweasel". Yeah, avoiding another iceweasel is a good thing. Groeten Geert Stappers -- Silence is hard to parse
Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel")
On Mon, Jun 27, 2022 at 01:58:41PM +0100, lkcl wrote: > everything is "fine" as long as: > > 1) the Mozilla Foundation acts reasonably and non-discriminatorily > (FRAND applies to Trademarks just as it applies to patent Licensing) > 2) the Mozilla Foundation does not appreciate quite how much power it > actually has under Trademark Law. > > given that this is between Free Software Groups i would expect the > discussion to remain civil and reasonable, and for them to drop or > modify the unachievable nonfree constraint, but please for goodness > sake do not let the civility of the interaction lull you into a sense > of false safety. > > under the Trademark as they have defined it, the Mozilla Foundation > is perfectly permitted to issue Debian a Legal Notice to Cease and > Desist distribution of the Unlawfully patched rustc binaries. > > l. Hi Luke, Hi all others, Let's continue thinking several steps ahead. * Allow all room to move forward * Accept there is NO "request pending" documentation, trust https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920#10 that it is "work in progress" * Ask over six weeks how much you should worry about this * Meanwhile team-up with other Linux distributions * Meanwhile create a concept letter you want to have, like We, Mozilla Foundation grant these Linux distributions * foo * bar * debian * baz to distribute our Rust and our Cargo that we still can recognice as our Rust and as our Cargo. * Continue enjoying Rust and Cargo Regards Geert Stappers P.S. a Trade Mark is a request for respect, not a demand for respect. And yes, respect is something like trust, it has to be earnt. -- Silence is hard to parse
Bug#974944: "documented"
Hi, I think this bugreport is documenting don't use ' in password. Groeten Geert Stappers https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003157#15 -- a dog's life
Bug#1002830: How to reproduce
control: tag -1 moreinfo > Could somebody fix the misleading message? I think that is waiting on how to reproduce the message. What were the wrong permissions and what are the correct permission on /var/lib/mailman3/templates/lists/test-l.example.org/en/list:member:regular:footer.txt ? Please provide the output of `ls -l` on the file for the "good" and "bad" situations. Telling what might have caused the wrong permissions is also a good thing. Groeten Geert Stappers -- Silence is hard to parse
Bug#1012604: RFS: libcap-ng/0.7.9-3 [ITS] -- alternate POSIX capabilities library
On Sat, Jun 11, 2022 at 05:57:26AM +, Håvard F. Aasen wrote: > On 2022-06-10 15:52, Bastian Germann wrote: > > Am 10.06.22 um 17:35 schrieb Håvard F. Aasen: > > > > I have forked the salsa repo to debian namespace and invited you. > > > I know the package is already uploaded, but is this a hard > > > requirement for you? I would prefer to have it under my own > > > namespace. > > > > Kind of. If (when) you become unresponsive and someone else is taking > > over the package, we can keep that. > Not sure if I agree with you on this one, you proved yourself how easy > it is to move the repository, this will be just as easy if I become > unresponsive at a later time. > Most of my worries is because of [1]. By placing it in the Debian > namespace it is now in the "Debian Team" where every DD can do > whatever they want. That "whatever" indeed include smart, good, needed, desired and even stupid things. > > I would really like to keep it that way. Please tag the uploaded > > version when it has arrived in the archive. > Will do. > > I will keep the repo in the Debian namespace for now and not push > this further, but personally I feel that demanding packages to be > part of a team isn't the best approach. Aiming for perfect is good, reaching good is much better. Groeten Geert Stappers DD P.S. In an ideal world will happen a stupid thing only once. [1] https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group -- Silence is hard to parse signature.asc Description: PGP signature
Bug#1011753: git branch recovery
What I earlier wrote: > Things I noticed: > * git looses information about in which branch I am > ... > $ git branch > * ignoretarget > master > $ debianize --verbose > ... > $ git branch > ignoretarget > master > $ It said "in the begin was I in branch 'ignoretarget'" and "in the end was unknown in which I was" ( no * shown) After `git checkout ignoretarget` do I get | $ git branch | * ignoretarget | master | $ So git has again information in which branch I am. I hope that the workaround helps some one. And it says "no unrecoverable harm to the git repository done by debianize" Groeten Geert Stappers -- Silence is hard to parse
Bug#1011753: debianize first encounter report
Package: lintian-brush Version: 0.124 Severity: minor Hello Jelmer, Hello Lintian-Brush co-maintainers, This is a report about to debianize hurl ( Hurl is written in Rust Hurl, run and test HTTP requests with plain text. https://github.com/Orange-OpenSource/hurl ) In the upstream git tree I triggered debianize --verbose Things I noticed: * git looses information about in which branch I am * duplicate reports * a Python backtrace stappers@trancilo:~/src/rust/hurl $ git branch * ignoretarget master stappers@trancilo:~/src/rust/hurl $ debianize --verbose Switching to packaging branch debian/main. Unnhandled field 'deploy status' in README Unnhandled field 'CircleCI' in README Unnhandled field 'Crates.io' in README Unnhandled field 'documentation' in README Found Cargo.toml, assuming rust cargo package. Creating core packaging using process_cargo Text conflict in packages/hurl_core/tests/json Text conflict in packages/hurl_core/tests/json Text conflict in contrib/windows/windows_package_managers/chocolatey/hurl Text conflict in contrib/windows/windows_package_managers/chocolatey/hurl Text conflict in integration/tests_failed Text conflict in integration/tests_failed Text conflict in packages/hurl/src/cli Text conflict in packages/hurl/src/cli Text conflict in integration/tests_error_lint Text conflict in integration/tests_error_lint Text conflict in packages/hurl_core/tests Text conflict in packages/hurl_core/tests Text conflict in packages/hurl/src/json Text conflict in packages/hurl/src/json Text conflict in packages/hurlfmt/src/cli Text conflict in packages/hurlfmt/src/cli Text conflict in contrib/npm/docs Text conflict in contrib/npm/docs Text conflict in packages/hurlfmt/tests/json Text conflict in packages/hurlfmt/tests/json Text conflict in integration/report Text conflict in integration/report Text conflict in packages/hurl/src/jsonpath/parser Text conflict in packages/hurl/src/jsonpath/parser Text conflict in packages/hurlfmt Text conflict in packages/hurlfmt Text conflict in contrib/windows Text conflict in contrib/windows Text conflict in packages/hurl_core/src/parser Text conflict in packages/hurl_core/src/parser Text conflict in packages/hurl/src/http Text conflict in packages/hurl/src/http Text conflict in integration/tests_error_parser Text conflict in integration/tests_error_parser Text conflict in packages Text conflict in packages Text conflict in ci/windows Text conflict in ci/windows Text conflict in contrib/windows/windows_package_managers Text conflict in contrib/windows/windows_package_managers Text conflict in packages/hurl/src/report/html Text conflict in packages/hurl/src/report/html Text conflict in integration/tests_ok Text conflict in integration/tests_ok Text conflict in bench/tests Text conflict in bench/tests Text conflict in packages/hurl/tests Text conflict in packages/hurl/tests Text conflict in packages/hurl/src/report Text conflict in packages/hurl/src/report Text conflict in packages/hurlfmt/src/linter Text conflict in packages/hurlfmt/src/linter Text conflict in integration Text conflict in integration Text conflict in bench Text conflict in bench Text conflict in docs/man Text conflict in docs/man Text conflict in packages/hurl_core/src/ast Text conflict in packages/hurl_core/src/ast Text conflict in packages/hurl/src/runner Text conflict in packages/hurl/src/runner Text conflict in packages/hurl/src/jsonpath Text conflict in packages/hurl/src/jsonpath Text conflict in docs Text conflict in docs Text conflict in .circleci Text conflict in .circleci Text conflict in packages/hurl_core/src/error Text conflict in packages/hurl_core/src/error Text conflict in contrib/npm Text conflict in contrib/npm Text conflict in contrib/windows/windows_package_managers/scoop Text conflict in contrib/windows/windows_package_managers/scoop Text conflict in contrib/windows/windows_package_managers/chocolatey Text conflict in contrib/windows/windows_package_managers/chocolatey Text conflict in art Text conflict in art Text conflict in integration/report/html/tests Text conflict in integration/report/html/tests Text conflict in packages/hurl_core/src/format Text conflict in packages/hurl_core/src/format Text conflict in .github/workflows Text conflict in .github/workflows Text conflict in packages/hurlfmt/tests Text conflict in packages/hurlfmt/tests Text conflict in integration/ssl Text conflict in integration/ssl Text conflict in integration/report/html Text conflict in integration/report/html Text conflict in contrib/windows/windows_package_managers/winget Text conflict in contrib/windows/windows_package_managers/winget Text conflict in packages/hurl/src/report/junit Text conflict in packages/hurl/src/report/junit Text conflict in packages/hurl_core Text conflict in packages/hurl_core Text conflict in packages/hurlfmt/src Text conflict
Bug#1010256: Let go
Summary: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010256#41 On Sun, May 01, 2022 at 09:09:12PM -0400, James McCoy wrote: > On Wed, Apr 27, 2022 at 04:07:43PM +0200, Jonas Smedegaard wrote: > > > > Please in future consider filing ITPs to avoid such situations. > > The Rust team files ITPs for binary crates, not the library crates, as > the binary crates are generally more relevant to the broader Debian > audience. > > In terms of avoiding duplicate effort, the debcargo-conf repo _is_ that > mechansim for the Rust team. You're choosing to ignore that and package > things outside of the team's infrastructure. > > The Rust team isn't unique in using a single repo for all their > packages. > > It would be appreciated if you worked within the team, so the packages > can benefit from the same infrastructure, rather than going off in a > different direction and stepping on existing work. In addition to "my way is better, no my way is the better one" here a link to a blog of Ian Jackson https://diziet.dreamwidth.org/10559.html That text, that I still don't completely comprehend, is saying something like "the pieces do not fit". Thing I'm trying to say: Let go, we known that the current tooling isn't perfect. What I like to see is that several workflows are being explored. And with the information it brings improve the comfort of the journey we are making. Groeten Geert Stappers DD P.S. Note to myself: Consider there is no fight, so no need to stop a fight. -- Silence is hard to parse signature.asc Description: PGP signature
Bug#1010256: Package
This ITP is severing it's purpose: Telling that is there an intent to package. The packaging and upload can be done. Yes, that is our common goal. Future will tell which conflicts we have to resolve. But we gonna cross that bridge when we are at the brigde. Groeten Geert Stappers -- Silence is hard to parse
Bug#1009658: RFS: ncdu/1.16-0.1 [NMU] -- ncurses disk usage viewer
On Wed, Apr 27, 2022 at 04:40:19PM +0200, Santiago Ruano Rincón wrote: > Control: tags 1009658 + pending Good > El 27/04/22 a las 14:47, Christian Göttsche escribió: > > > I'd prefer to have a more verbose description about what that update on > > > Build-Deps means. This is just a personal preference. > > > Would you like to give a little more detail please? > > > > Uploaded a new version with a more detailed changelog: > > > > ncdu (1.16-0.1) unstable; urgency=medium > > . > >* Non-maintainer upload. > >* New upstream version 1.16 (Closes: #996240) > >* d/control: > > - update build dependencies > >+ replace transitional libncurses5-dev and libncursesw5-dev by > > libncurses-dev > >+ add pkg-config for successful autoreconf > >+ drop autotools-dev, default since debhelper compat 10 > > - bump to debhelper compat 13 > > - bump to std-ver 4.6.0 (no further changes) > > - set Rules-Requires-Root no > > - use https homepage address > >* d/patches: cherry-pick upstream commits > > - Add dark-bg color scheme + enable colors by default if !NO_COLOR > >(Closes: #894380) > > - Make options, keys and file flags bold in man page > > - dir_scan: fix wrong assumption that errno can only be changed by > >readdir() > > - dir_scan: call strlen only once > >* d/rules: enable hardening and LTO > >* d/u/metadata: add basic metadata > > > > Uploaded to DELAYED/10. > > Thanks for your work! > > -- Santiago Thank you for the upload. Groeten Geert Stappers Did not understand > >* New upstream version 1.16 versus > >* d/patches: cherry-pick upstream commits -- Silence is hard to parse
Bug#1006287: Version older than that in the archive.
On Tue, Apr 26, 2022 at 07:21:10PM -0400, rapier wrote: > On 4/26/22 3:17 PM, Bastian Germann wrote: > > Am 26.04.22 um 21:04 schrieb rapier: > > > On 4/26/22 2:17 PM, Bastian Germann wrote: > > > > On Tue, 22 Feb 2022 15:24:48 -0500 rapier wrote: > > > > > hpnssh (1:8.8p1-hpn16v1-9) sid; urgency=medium > > > > The Debian revision has to be -1 and the epoch (1:) has to be removed. > > > When you say the Debian revision needs to be -1 do you > > > mean making the 1:8.8p1-hpn16v1-9 into 8.8p1-hpn16v1-1 or something > > > else? Would that take care of the epoch as well? > > That version number is fine if the upstream version 8.8p1-hpn16v1 exists > > Epoch and revision are okay with 8.8p1-hpn16v1-1. > > > Bastian, Hello debian-ment...@lists.debian.org mailinglist, > I'm sorry to bother you. I've tried to upload a new version with the changes > you suggested but it was rejected. The error is > > Rejected: > hpnssh_8.8p1hpn16v1-1.dsc: Version older than that in the archive. > 8.8p1hpn16v1-1 <= 1:8.8p1-hpn16v1-8 } 0:8.8p1hpn16v1-1 <= 1:8.8p1-hpn16v1-8 > > hpnssh (8.8p1hpn16v1-1) impish; urgency=medium > > * Submission to Debian for impish. > * Refactor binary names to have hpn prefix > > Which is why my revision number hit 9 the first time. I'm not sure how to > resolve this aside from either deleting the existing PPA and starting over > or creating a new PPA. The "repository gate keeper software" rules "epoch+1" newer as "epoch". In this case 1:placeholder being newer as 0:placeholder. I miss, this email misses, where the repository is. PPA hits it is Ubuntu. I don't known if PPA allows removal what has been uploaded. So yes, deleting and starting over or a new PPA are a path to beyond the 'Version older than that in the archive'. > Do I have any other options? No, and no need for. You are learning that "epoch" is something to rarely use. "epoch" is an escape hatch to be used in Debian packaging when Upstream publishes a new release with an older version number. $ dpkg --compare-versions 3.3 ge 3.2 && echo no need for epoch || echo Chips no need for epoch $ dpkg --compare-versions 3.3 ge 3.4 && echo no need for epoch || echo Chips Chips $ > I really appreciate the time you are spending on this. Yes, b...@debian.org is doing good work. Do known that you are also doing good by all the stuff that you are learning. > Thanks again, Thank you for being curious AND persistent. > Chris Groeten Geert Stappers DD -- Silence is hard to parse signature.asc Description: PGP signature
Bug#1006287: RFS: hpnssh/1:8.8p1-hpn16v1-9 [ITP] -- high performance secure shell client and server (metapackage)
On Tue, Apr 26, 2022 at 09:17:21PM +0200, Bastian Germann wrote: > Am 26.04.22 um 21:04 schrieb rapier: > > Bastian, > > > > On 4/26/22 2:17 PM, Bastian Germann wrote: > > > Control: tags -1 moreinfo > > > > > > On Tue, 22 Feb 2022 15:24:48 -0500 rapier wrote: > > > > Changes for the initial release: > > > > > > > > hpnssh (1:8.8p1-hpn16v1-9) sid; urgency=medium > > > > . > > > > * Updated copyright. > > > > > > Please replace your massive changelog just with one entry that closes > > > your ITP. > > > The Debian revision has to be -1 and the epoch (1:) has to be removed. > > > Please target "unstable". When you have provided a new revision, please > > > untag moreinfo. > > > > > > This is my first submission to Debian so I apologize for the stupid > > questions. When you say the Debian revision needs to be -1 do you mean > > making the 1:8.8p1-hpn16v1-9 into 8.8p1-hpn16v1-1 or something else? > > Would that take care of the epoch as well? > > That version number is fine if the upstream version 8.8p1-hpn16v1 exists (I > did not check for it). > Epoch and revision are okay with 8.8p1-hpn16v1-1. What I understand from https://www.psc.edu/hpn-ssh-home is 8.8p1 version of OpenSSH and hpn16v1 the hpn-ssh part. However two - in the version feels odd. Gut feeling says "drop one -" > > Also, what should be in the changelog? Just an update that says closing the > > ITP? Yes. Because there are no other Debian changes to logged. (debian/changelog is for reporting/documenting Debian changes) > > I apologize if this is documented somewhere. I've spent time looking for > > a submission guide but I couldn't find one that seemed up to date. > > https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#changelog > > The New Maintainer's Guide is generally a good read. Probably advices also version number convention. Groeten Geert Stappers -- Silence is hard to parse
Bug#996240: Bug#1009658: RFS: ncdu/1.16-0.1 [NMU] -- ncurses disk usage viewer
Now it is here (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996240) also. - Forwarded message from Geert Stappers - Date: Mon, 25 Apr 2022 15:59:30 +0200 From: Geert Stappers To: Santiago Ruano Rincón , 1009...@bugs.debian.org, 894...@bugs.debian.org Cc: Christian Göttsche , n...@packages.debian.org Subject: Bug#1009658: RFS: ncdu/1.16-0.1 [NMU] -- ncurses disk usage viewer User-Agent: NeoMutt/20170113 (1.7.2) Full quote On Mon, Apr 25, 2022 at 03:25:02PM +0200, Santiago Ruano Rincón wrote: > El 22/04/22 a las 11:09, Christian Göttsche escribió: > > > Is it really urgency=medium? low wouldn't fit? > > > > I never used anything else than the default medium; happy to reduce to > > low if wished. > > I don't think reducing is really needed. I'd upload to a DELAYED queue > though, which is a different thing, to give Eugene some time to react. > > > > Eugene tagged #894380 as wontfix: > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894380#10 > > > Why do you have another opinion? Is there anything different on > > > upstream's side that has changed since Eugene's comment? > > > > His reasoning from my understanding was to not divert from upstream > > and set experimental features as default. > > Now with the cherry-picked commit "Add dark-bg color scheme + enable > > colors by default if !NO_COLOR"[1] upstream enabled colors by default. > > Quote from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894380#10: > > > If you persuade upstream to change the defaults earlier before the next > > > release, I'm open to cherry-picking that. > > OK. I'd suggest you to comment this on #894380, to make it easier to > find your reasoning. > > > > > > Have you had any feedback/input from Eugene? > > > > Unfortunately no. > > ACK. > > > Sorry for not commenting this before. From d/changelogs: > > +ncdu (1.16-0.1) unstable; urgency=medium > + > + * Non-maintainer upload. > + * New upstream version 1.16 (Closes: #996240) > + * d/control: > +- update build dependencies > > I'd prefer to have a more verbose description about what that update on > Build-Deps means. This is just a personal preference. > Would you like to give a little more detail please? > > Thanks for your work, > > -- Santiago Reason for the full quote is to add #894380 and #996240 with this discussion about the RFS URLs for "jumping" to them (and back) * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894380 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996240 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009658 Groeten Geert Stappers -- Silence is hard to parse - End forwarded message - -- Groeten Geert Stappers -- Silence is hard to parse
Bug#1009658: RFS: ncdu/1.16-0.1 [NMU] -- ncurses disk usage viewer
Full quote On Mon, Apr 25, 2022 at 03:25:02PM +0200, Santiago Ruano Rincón wrote: > El 22/04/22 a las 11:09, Christian Göttsche escribió: > > > Is it really urgency=medium? low wouldn't fit? > > > > I never used anything else than the default medium; happy to reduce to > > low if wished. > > I don't think reducing is really needed. I'd upload to a DELAYED queue > though, which is a different thing, to give Eugene some time to react. > > > > Eugene tagged #894380 as wontfix: > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894380#10 > > > Why do you have another opinion? Is there anything different on > > > upstream's side that has changed since Eugene's comment? > > > > His reasoning from my understanding was to not divert from upstream > > and set experimental features as default. > > Now with the cherry-picked commit "Add dark-bg color scheme + enable > > colors by default if !NO_COLOR"[1] upstream enabled colors by default. > > Quote from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894380#10: > > > If you persuade upstream to change the defaults earlier before the next > > > release, I'm open to cherry-picking that. > > OK. I'd suggest you to comment this on #894380, to make it easier to > find your reasoning. > > > > > > Have you had any feedback/input from Eugene? > > > > Unfortunately no. > > ACK. > > > Sorry for not commenting this before. From d/changelogs: > > +ncdu (1.16-0.1) unstable; urgency=medium > + > + * Non-maintainer upload. > + * New upstream version 1.16 (Closes: #996240) > + * d/control: > +- update build dependencies > > I'd prefer to have a more verbose description about what that update on > Build-Deps means. This is just a personal preference. > Would you like to give a little more detail please? > > Thanks for your work, > > -- Santiago Reason for the full quote is to add #894380 and #996240 with this discussion about the RFS URLs for "jumping" to them (and back) * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894380 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996240 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009658 Groeten Geert Stappers -- Silence is hard to parse
Bug#988716: After the release is before the release
} > Upstream changed paths for the framework manifest files in recent } > releases and did not maintain backward compatibility links resulting } > in 4.3.4 no longer being able to install the frameworks. } } Had a quick look, and it's worse than that. Not just a change in paths, } but an entire new package manager, with a new API (/v2/ in the URLs). } > ... package is basically unusable for new installations } > Since it did not exist in buster, it is always a new installation } > in bullseye. Considering we are in late freeze phase I suggest to } > drop the package from Debian testing (and upload a new upstream } > release to sid). } } Sounds like the right call. } This bugreport has now a link to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976665 New upstream version 5.0.x available
Bug#976665: solves 988716
Hi, I think the 5.x version of plafform.io would fix #988716 ( platformio 4.3.4 cannot download required frameworks ) This bugreport has now a link to that BR https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988716 Groeten Geert Stappers -- Silence is hard to parse
Bug#1009389: confirming and repair attempt
Hi,
The FTBFS is reproducable `debuild -uc -us`.
Below is a screenshot of my repair attempt.
8<--8<--8<--8<--
stappers@myhost:~/src/lirc
$ cd python-pkg/tests/
stappers@myhost:~/src/lirc/python-pkg/tests
$ python3 -m unittest discover && rm backend.log
E
==
ERROR: test_client (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_client
Traceback (most recent call last):
File "/usr/lib/python3.10/unittest/loader.py", line 436, in _find_test_path
module = self._get_module_from_name(name)
File "/usr/lib/python3.10/unittest/loader.py", line 377, in
_get_module_from_name
__import__(name)
File "/home/stappers/src/lirc/python-pkg/tests/test_client.py", line 116
self.assertEqual(len(lines), 1000)
IndentationError: expected an indented block after 'with' statement on line 110
--
Ran 1 test in 0.000s
FAILED (errors=1)
stappers@myhost:~/src/lirc/python-pkg/tests
$ vi +110 test_client.py
stappers@myhost:~/src/lirc/python-pkg/tests
$ python3 -m unittest discover && rm backend.log
...E...
==
ERROR: testReceive1AsyncLines (test_client.ReceiveTests)
Receive 1000 lines using the async interface.
--
Traceback (most recent call last):
File "/home/stappers/src/lirc/python-pkg/tests/test_client.py", line 113, in
testReceive1AsyncLines
run_until_complete(get_lines(conn, 1000))
NameError: name 'run_until_complete' is not defined
--
Ran 7 tests in 0.748s
FAILED (errors=1)
stappers@myhost:~/src/lirc/python-pkg/tests
$ git diff test_client.py
diff --git a/python-pkg/tests/test_client.py b/python-pkg/tests/test_client.py
index d9af254..9428485 100644
--- a/python-pkg/tests/test_client.py
+++ b/python-pkg/tests/test_client.py
@@ -106,12 +106,12 @@ class ReceiveTests(unittest.TestCase):
stdout = subprocess.PIPE,
stderr = subprocess.STDOUT) as child:
_wait_for_socket()
-loop = asyncio.get_event_loop()
+#loop = asyncio.get_event_loop()
with LircdConnection('foo',
socket_path=_SOCKET,
lircrc_path='lircrc.conf') as conn:
-loop.run_until_complete(get_lines(conn, 1000))
-loop.close()
+run_until_complete(get_lines(conn, 1000))
+#loop.close()
self.assertEqual(len(lines), 1000)
self.assertEqual(lines[0], 'foo-cmd')
stappers@myhost:~/src/lirc/python-pkg/tests
$
8<--8<--8<--8<--
I hope this helps to fix the fails to build from source.
Groeten
Geert Stappers
--
Silence is hard to parse
Bug#988945: Another workflow for Rust Was: Rust libraries left broken
Hello Jonas, Hello people in the CC, On Mon, Apr 11, 2022 at 12:34:47PM +0200, Jonas Smedegaard wrote: > Quoting Sylvestre Ledru (2022-04-11 09:34:48) > > Le 11/04/2022 à 01:14, Jonas Smedegaard a écrit : > > > Quoting Sylvestre Ledru (2022-04-10 22:15:47) > > >> Maybe you should join the team, commit there and follow the process > > >> for our packages? :) > > > > > > Thanks for the suggestion, but I decline the offer: > > > > > > I am not interested in joining a team where packages should be > > > tracked in one giant git repo. > > > > > > If I am mistaken and that's not a policy in the Rust team - or if > > > the team might consider changing that policy, then I would gladly > > > join. > > It is and it probably won't change (too hard)) > > > > I will then have to ask you to stop doing NMU without delays as it > > will make our life harder. :( > > Thanks, your kind request is duly noted. > > Rust team [discouraging nmudiff] and [not using our BTS], and leaving > packages [very broken], makes our lives harder as well. :-( > > > - Jonas > > [discourage nmudiff]: See https://bugs.debian.org/998347#28 > > [not using our BTS]: See https://bugs.debian.org/969609#10 > > [very broken]: Totally broken for months despite fix being simple > (and notably *not* needing to involve NEW queue): > * rust-rustls: 6 months FTBFS, https://bugs.debian.org/1007749 > * rust-sha-1: 16 months FTBFS, https://bugs.debian.org/1009123 > * rust-http: 4 months FTBFS, https://bugs.debian.org/988945 > Duly noted and in my very own works: Acknowledge Now that is expressed that things are NOT going smoothly, we should be alert that we NOT gonna fight with each other. Jonas, you have my permission to let it go. Jonas, you have my permission to let it go for now. Jonas, my actual request is that you notice that your report "Debian Rust packaging currently sub-optimal" has been seen. Then interpret it as "no need to add more fuel to the flame war". It is up to us for how long we let cool this down. The cooling down is important for getting a constructive mindset. As in "frustration will block finding a solution". I will leave this "as is" for the next few days. And after that continue with an old idea how to improve Debian Rust packaging. That will be at debian-r...@lists.debian.org I have set Reply-To for it. Groeten Geert Stappers DD -- Silence is hard to parse
Bug#999837: my two cents
Merecat footprint is ~ 140 KiB. Having CGI support and Let's encrypt support is also a plus. The swap of publicfile-installer for merecat is a improvement for Debian. FWIW, this email adds deep link https://salsa.debian.org/debian/merecat to this ITP BR. I can confirm that debcheckout https://salsa.debian.org/debian/merecat works. Once merecat is in debian you can do just debcheckout merecat (Install debcheckout by `sudo apt install -y devscripts`.) Groeten Geert Stappers -- Silence is hard to parse
Bug#1009034: no disk space probably not an issue
On Wed, Apr 06, 2022 at 02:00:24PM +0200, Geert Stappers wrote: > > > > Finished at 2022-04-06T09:14:38Z > > Build needed 00:00:00, no disk space > > > That "no disk space" should be solved first. > I might be wrong about that. While researching it, I encountered | $ debcheckout rust-libgit2-sys | declared git repository at https://salsa.debian.org/rust-team/debcargo-conf.git [src/libgit2-sys] | git clone https://salsa.debian.org/rust-team/debcargo-conf.git [src/libgit2-sys] rust-libgit2-sys ... | Cloning into 'rust-libgit2-sys'... | fatal: unable to access 'https://salsa.debian.org/rust-team/debcargo-conf.git [src/libgit2-sys]/': URL using bad/illegal format or missing URL | checkout failed (the command above returned a non-zero exit code) | $ And in /usr/src/debian/rust/debcargo-conf/src/libgit2-sys | $ sbuild | dpkg-source: error: cannot read libgit2-sys/debian/control: No such file or directory | E: Failed to run dpkg-source --before-build /usr/src/debian/rust/debcargo-conf/src/libgit2-sys | $ ls debian/ | changelog copyright copyright.debcargo.hint debcargo.toml patches | $ I have to let this go. Sorry for the noise. Groeten Geert Stappers -- Silence is hard to parse
Bug#1009015: [Pkg-rust-maintainers] Bug#1009034: rust-libgit2-sys: FTBFS with libgit2 1.3.0
On Wed, Apr 06, 2022 at 04:02:25PM +0530, Mohammed Bilal wrote: > > rust-libgit2-sys was found to fail to build > during a test rebuild with libgit2 1.3.0 in unstable. > Attaching the buildlogs as well. > sbuild (Debian sbuild) 0.83.0 (05 February 2022) on debian ... > +--+ > | Summary > | > +--+ > > Build Architecture: amd64 > Build Type: full > Build-Space: n/a > Build-Time: 0 > Distribution: unstable > Fail-Stage: install-deps > Host Architecture: amd64 > Install-Time: 0 > Job: /tmp/tmp.IWMPTclA8J/rust-libgit2-sys_0.12.24-3.dsc > Machine Architecture: amd64 > Package: rust-libgit2-sys > Package-Time: 0 > Source-Version: 0.12.24-3 > Space: n/a > Status: given-back > Version: 0.12.24-3 > > Finished at 2022-04-06T09:14:38Z > Build needed 00:00:00, no disk space That "no disk space" should be solved first. And this email makes cross references to related bugs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009015 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009034 Groeten Geert Stappers Might be wrong about the relation of #1009015 and #1009034 -- Silence is hard to parse
Bug#992692: link
iHTH https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008652
Bug#1008652: mirrors must support also HTTPS in order to be considered official
Control: retitle -1 mirrors must support also HTTPS in order to be considered official > This is related to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992692 Quoting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992692#37 This change is more about recognizing HTTPS as the primary transport protocol for the modern Web, not sending mixed signals regarding the general security risks posed by plain HTTP when used for unrelated purposes, and no longer needing to repeatedly explain to users that Debian has gone to great lengths to implement package distribution security which doesn't really depend at all on transport layer encryption. Original Subject: mirrors must support HTTPS in order to be considered official should have been: mirrors must support also HTTPS in order to be considered official I have retitled this wishlist bugreport accordingly to make more clear that the wish is about **adding** another transport protocol, not about **switching** transport protocol. Groeten Geert Stappers -- Debian has gone to great lengths to implement package distribution security which doesn't really depend at all on transport layer encryption.
Bug#1001779: It is a request
On Thu, Mar 24, 2022 at 12:23:16AM -0700, lepapareil wrote: > ... our bug seems to be on hold for almost 3 months ? No, nothing is on hold. An request for packaging is a request for packaging. > Thks for your help :) Expressing expectations is fine, insisting on ones own expectation doesn't help. FWIW, I only partly argee with "somebody else should do it", thing I will do is sponsoring uploads to Debian. On expressing expectations: I love to see messages like At $URL is hurl dependency foo packaged. What is, beside review time, needed to get it uploaded to Debian? Groeten Geert Stappers -- Silence is hard to parse
Bug#1007982: ITP: popsicle -- A Linux utility for flashing multiple USB devices in parallel
On Sat, Mar 19, 2022 at 09:42:53PM +, Matthias Geiger wrote: > * Package name : popsicle > * URL : https://github.com/pop-os/popsicle > Programming Lang: Rust > Description : Popsicle is a Linux utility for flashing multiple USB > devices in parallel > > A small program for creating bootable USB drives. I believe this would be a > nice addition, especially for newcomers to linux. I believe it will be also a nice addition for those who have to deal with writing many USB devices. Part of the Cargo.toml: | [dependencies] | anyhow = "1.0" | as-result = "0.2" | async-std = "1" | derive-new = "0.5" | futures = "0.3" | futures_codec = "0.4" | libc = "0.2" | memchr = "2.2" | mnt = "0.3" | ron = "0.6" | serde = "1.0" | srmw = "0.1" | thiserror = "1" | usb-disk-probe = "0.1" > I'd package it but I'd need a sponsor. Work together with Debian Rust people. Groeten Geert Stappers DD, subscribed to debian-r...@lists.debian.org -- Silence is hard to parse
Bug#1006940: Why still Alioth at main page
Package: sso.debian.org Hello SSO maintainers, Currently, 2022-03-08, has https://sso.debian.org/ two large icons. One is for Alioth, Alioth account certificates, and links to https://sso.debian.org/alioth/certs/ For which reason is there such large icon for Alioth? Or: Why not remove it? After all is Alioth been shutdown. Groeten Geert Stappers -- Silence is hard to parse
Bug#1006823: patch to prevent debos example adduser waits for password
Control: tag -1 patch The hang is caused by `adduser` waiting for password (and password confirmation) Providing two password strings can be done with a bash subshell. Creating the subshell is done by wrapping in parentheses. So the adduser --gecos User user should be (echo user ; echo user ) | adduser --gecos User user The complete patch: --- a/doc/examples/setup-user.sh +++ b/doc/examples/setup-user.sh @@ -1,10 +1,8 @@ -#!/bin/sh +#!/bin/bash set -e echo "I: create user" -adduser --gecos User user +(echo user ; echo user ) | adduser --gecos User user -echo "I: set user password" -echo "user:user" | chpasswd adduser user sudo Groeten Geert Stappers -- Silence is hard to parse
Bug#1006823: debos example has adduser waiting for password
Package: debos Version: 1.0.0+git20210707.c66a48d-2 Severity: minor Hello debos maintainers, Doing debos /usr/share/doc/debos/examples/example.yaml got me a waiting / hanging debos. But the provide example should just work ... (a patch is work in progress) Groeten Geert Stappers -- Silence is hard to parse
Bug#983146: 983146 RFS: bung/3.2.1-1 [ITP] -- backup next generation
On Wed, Mar 02, 2022 at 12:39:38PM +0530, Charles wrote: > > When that doubt is resolved I will create 3.2.1-2 including a watch file do
Bug#1006618: lcd4linux new homepage
Package: lcd4linux Hi, Currently is lcd4linux homepage https://ssl.bulix.org/projects/lcd4linux/ unvailable. What would / should be the new homepage for debian/control/Homepage: ? Groeten Geert Stappers -- Silence is hard to parse
Bug#1006288: prebuild and/or cache pages of some packages
Package: bugs.debian.org Severity: wishlist Hello Debian BTS People, https://bugs.debian.org/foo gets redirected to https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=foo;dist=unstable and then gets https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=foo;dist=unstable build. In case package "foo" has many bugs is the response time very long. The idea c.q. wish is to prebuild and/or cache pages for packages like "linux" and "wnpp". Not hindered by implementation knowledge, I would make cronjob that captures the output of https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wnpp;dist=unstable and store it at https://bugs.debian.org/wnpp and tell the webserver to NOT redirect to the cgi-bin/pkgreport.cgi for package wnpp Groeten Geert Stappers -- Silence is hard to parse
Bug#1006284: the idea
Something like https://bugs.debian.org/debbugs-source/mainline/README.md but with a recent file date. ( I fear that content from 2015-02-10 is outdated.)
Bug#1006284: a README at debbugs-source
Package: bugs.debian.org Severity: normal Hello Debian BTS people, The webpage of this issue links to https://bugs.debian.org/debbugs-source/ Over there is currently: Index of /debbugs-source [ICO] Name Last modified Size [PARENTDIR] Parent Directory- [DIR] bugscan.git/ 2019-08-24 00:08- [DIR] bugscan.old/ 2011-06-16 17:06- [DIR] bugscan/ 2019-08-24 00:08- [DIR] debbugs-database/ 2018-03-28 23:11- [DIR] debbugs-package-update.git/ 2018-11-02 05:56- [DIR] debbugs.git/ 2022-01-12 05:26- [DIR] debian-pregit/2012-03-23 02:37- [DIR] debian.old/ 2010-05-04 21:03- [DIR] debian/ 2018-03-29 21:49- [DIR] mainline-pregit/ 2012-03-23 02:37- [DIR] mainline/ 2019-11-24 04:37- [TXT] update_branch.sh 2012-03-23 15:291.6K [ ] update_branch.sh_bak2007-03-08 02:25540 Apache Server at bugs.debian.org Port 443 It would be an improvement if there is a "README" file that describes what the visitor is looking at and tells what the visitor might be looking for. Groeten Geert Stappers -- Silence is hard to parse
Bug#898089: reproducable
FYI Triggering the 500 Internal Server Error was today possible. In other words: I should not close this old bug report.
Bug#1000766: Processed (with 1 error): Package is linux
Control: reassign -1 linux On Tue, Feb 22, 2022 at 05:39:05PM +, Debian Bug Tracking System wrote: > Processing control commands: > > > assign -1 linux > Unknown command or malformed arguments to command. >
Bug#1000766: Package is linux
Control: assign -1 linux Hello Kirill, BlueTooth controller stuff is NOT package bugs.debian.org See also https://wiki.debian.org/DebianKernelReportingBugs Groeten Geert Stappers DD -- Silence is hard to parse
Bug#983146: RFS: bung/3.2.1-1 [ITP] -- backup next generation
On Fri, Feb 18, 2022 at 12:40:51PM +0530, Charles wrote: > > The tarball and .deb are available from > https://redmine.auroville.org.in/projects/bung/files. Which has a .debian.tar.xz ( https://redmine.auroville.org.in/attachments/download/13572/bung_3.2.1-1.debian.tar.xz ) > *Changes since 3.1.1* > > The most important changes are rsync_bu now supports non-root user for > remote rsync and Debian 8 Jessie is no longer supported. The User Guide now > includes an Android backup example > > Bugfixes and new features > > . And what about responding to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983146#127 ? That question in other words: Proof that feedback gets follow-up. Groeten Geert Stappers -- Silence is hard to parse
Bug#996973: [mailer-dae...@stappers.nl: Undelivered Mail Returned to Sender]
OOPS - Forwarded message from Mail Delivery System - Date: Tue, 15 Feb 2022 19:54:35 +0100 (CET) From: Mail Delivery System To: stapp...@stappers.nl Subject: Undelivered Mail Returned to Sender This is the mail system at host gpm.stappers.nl. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system <996...@debian.org>: host mailly.debian.org[2001:41b8:202:deb:6564:a62:52c3:4b72] said: 550 Unrouteable address (in reply to RCPT TO command) Reporting-MTA: dns; gpm.stappers.nl X-Postfix-Queue-ID: D727B30412F X-Postfix-Sender: rfc822; stapp...@stappers.nl Arrival-Date: Tue, 15 Feb 2022 19:54:31 +0100 (CET) Final-Recipient: rfc822; 996...@debian.org Original-Recipient: rfc822;996...@debian.org Action: failed Status: 5.0.0 Remote-MTA: dns; mailly.debian.org Diagnostic-Code: smtp; 550 Unrouteable address Date: Tue, 15 Feb 2022 19:54:31 +0100 From: Geert Stappers To: NG Cc: stapp...@debian.org, 996...@debian.org Subject: Re: msc-generator_7.1-1_amd64.changes REJECTED User-Agent: NeoMutt/20170113 (1.7.2) On Tue, Feb 15, 2022 at 08:52:35AM -0800, NG wrote: > On 2022-02-15 17:49, Debian FTP Masters wrote: > > There was an uncaught exception when processing your upload: > > Traceback (most recent call last): > > File "/srv/ftp-master.debian.org/dak/dak/process_upload.py", line > > 213, in wrapper > > return function(directory, upload, *args, **kwargs) > > File "/srv/ftp-master.debian.org/dak/dak/process_upload.py", line > > 311, in accept_to_new > > upload.install_to_new() > > File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 1428, > > in install_to_new > > self._do_bts_versiontracking() > > File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 1290, > > in _do_bts_versiontracking > > for line in fh.readlines(): > > File "/usr/lib/python3.7/codecs.py", line 322, in decode > > (result, consumed) = self._buffer_decode(data, self.errors, final) > > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe1 in position > > 97: invalid continuation byte > > This is my fault, I ruined the encoding of d/chglog and had to change it > back. It is already pushed as 1117dc9. Sorry for this. Ah, :-) This is what I learnt in the last twentyfour hours: stappers@trancilo:/usr/src/debian/msc-generator-7.1 $ dput ../msc-generator_7.1-1_amd64.changes Trying to upload package to ftp-master (ftp.upload.debian.org) Package has already been uploaded to ftp-master on ftp.upload.debian.org Nothing more to do for ../msc-generator_7.1-1_amd64.changes stappers@trancilo:/usr/src/debian/msc-generator-7.1 $ rm ../msc-generator_7.1-1_amd64.ftp-master.upload stappers@trancilo:/usr/src/debian/msc-generator-7.1 $ dput ../msc-generator_7.1-1_amd64.changes Trying to upload package to ftp-master (ftp.upload.debian.org) Uploading to ftp-master (via ftp to ftp.upload.debian.org): Uploading msc-generator_7.1-1.dsc: done. Uploading msc-generator_7.1.orig.tar.xz: done. Uploading msc-generator_7.1-1.debian.tar.xz: done. Uploading msc-generator-dbgsym_7.1-1_amd64.deb: done. Uploading msc-generator-doc_7.1-1_all.deb: done. Uploading msc-generator_7.1-1_amd64.buildinfo: done. Uploading msc-generator_7.1-1_amd64.deb: done. Uploading msc-generator_7.1-1_amd64.changes: done. Successfully uploaded packages. stappers@trancilo:/usr/src/debian/msc-generator-7.1 $ The screenshot says that `dput` checks for a `.upload` file. So the `debian/changelog` changes concerning '-2' where NOT needed. And they need be reverted or other clean up is needed. If you want a Sorry for it, say so. Groeten Geert Stappers -- Silence is hard to parse - End forwarded message - -- Groeten Geert Stappers -- Silence is hard to parse
Bug#996973: Second upload Was: msc-generator_7.1-1_amd64.changes REJECTED
On Tue, Feb 15, 2022 at 02:08:35AM -0800, NG wrote: > On 2022-02-14 23:37, Geert Stappers wrote: > > On Mon, Feb 14, 2022 at 10:22:42PM +, Debian FTP Masters wrote: > >> > >> msc-generator_7.1-1_amd64.deb: trying to install to new, but could not > >> find source (msc-generator 7.1-1) > >> > > > > $ dput ../msc-generator_7.1-1_amd64.changes > > Trying to upload package to ftp-master (ftp.upload.debian.org) > > Package has already been uploaded to ftp-master on ftp.upload.debian.org > > Nothing more to do for ../msc-generator_7.1-1_amd64.changes > > $ > > > > Tomorrow an new `dput` Got the same result. > Wow. I understand there are some subtleties with dput and the NEW queue > that I don't understand, but a single thought came to me: Can it be > a/the problem that I did *not* change the version number for this new > upload to NEW? I.e., it was 7.1-1 on the first upload in January, and it > is still the same now. (I was thinking as this is not an accepted > package, the version should/can stay the same but maybe that causes > hickups in the processing.) Yes, I was also surprised. Find attached a patch. Review it, process it further and report back. Groeten Geert Stappers -- Silence is hard to parse >From cd0de6d971fcaa7246cbeb7d1e4b9e122896c855 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?G=C3=A1bor=20N=C3=A9meth?= Date: Tue, 15 Feb 2022 13:55:51 +0100 Subject: [PATCH] Next upload to Debian The previous upload was rejected due incomplete debian/copyright. After updating it, said `dput`: Package has already been uploaded to ftp-master on ftp.upload.debian.org So now incremented the debian version. --- debian/changelog | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index acbb2e38..fab2e807 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,5 +1,11 @@ -msc-generator (7.1-1) unstable; urgency=medium +msc-generator (7.1-2) unstable; urgency=medium * First Debian release (Closes: #996973) + -- Gábor Németh Tue, 15 Feb 2022 13:49:54 +0100 + +msc-generator (7.1-1) unstable; urgency=medium + + * Rejected by FTP-masters due incomplete copyright notes + -- Gábor Németh Mon, 14 Feb 2022 12:31:54 +0100 -- 2.34.1
Bug#996973: msc-generator_7.1-1_amd64.changes REJECTED, feedback
On Mon, Feb 14, 2022 at 02:10:07AM -0800, NG wrote: > On 2022-02-13 12:00, Thorsten Alteholz wrote: > > please also mention at least > > The Khronos Group Inc. > > Sean Barrett > > Tristan Grimmer > > Stephane Cuillerdier (aka aiekick) > > in your debian/copyright. > > Done, I have included these and created a new upload at mentors. @Geert > can you please check and forward it in Thorsten's way? Done. In case that upload also needs additional care, please tell how we, Maintainer & Uploader, could/should check. Groeten Geert Stappers -- Silence is hard to parse
Bug#1004832: hyx, vim-like hex editor, at Salsa
On Mon, Feb 07, 2022 at 09:26:41AM -0600, Russell Hernandez Ruiz wrote: > On Mon, 2022-02-07 at 15:35 +0100, Geert Stappers wrote: > > On Sun, Feb 06, 2022 Russell Hernandez Ruiz wrote: > > > I've just signed-up there with username `qrpnxz`. > > > > Somehow is that account not found / not visible. > > > > It's pending approval from an admin. That matches https://wiki.debian.org/Salsa/Doc#Users | Your account will be locked until a gitlab administrator enables | it. As of July 2021 you will now receive an email confirming your | account validation, please be patient. > I don't know if you can do that, No, I don't have that privilegde. > or know who I should contact about that. Allow the Sala admins to do a next batch run. I have no idea how often the queue is checked. I do have an idea whom to contact, but I go for being patient (a.k.a. work on other things). Groeten Geert Stappers -- Silence is hard to parse
Bug#1004832: hyx, vim-like hex editor, at Salsa
On Sun, Feb 06, 2022 at 02:16:06PM -0600, Russell Hernandez Ruiz wrote: > On Sun, 2022-02-06 at 16:43 +0100, Geert Stappers wrote: > > ... Russell provides VCS repo or git at Salsa ... > > Both paths are fine with me. > > @Russell I make it your call. > > Stappers: git repo at Salsa sounds good. > > I'd like to create it/set it up myself if that's okay/possible. > Plan would be to have a tagged upstream branch, with packaging > living in master. > > If you have to do it, then go ahead. Thing I as Debian Developer are allow to do, is creating a "project" in "salsa debian organisation". So now there is https://salsa.debian.org/debian/hyx It is empty as requested "I'd like to create it/set it up myself" > I've just signed-up there with username `qrpnxz`. Somehow is that account not found / not visible. Please provide some proof that the sign-up was succesfull. E.g. by creating a dummy git reposity like https://salsa.debian/qrpnxz/hello When Salsa account can be found / be seen, I'll grant it full privilege to https://salsa.debian.org/debian/hyx Groeten Geert Stappers -- Silence is hard to parse signature.asc Description: PGP signature
Bug#1004832: ITP: hyx -- minimalistic but powerful vim-like hex editor
On Wed, Feb 02, 2022 at 07:09:56AM -0600, Russell Hernandez Ruiz wrote:
> On Wed, 2022-02-02 at 14:02 +0100, Geert Stappers wrote:
> > Is there a VCS, Version Control System, that has hyx debian
> > packaging? (Please recieve that yes-no-question as a conversation starter)
>
> No.
OK
> Should I upload this as a git somewhere?
Yes, and I could create a git repository at Salsa.
( https://salsa.debian.org )
So, that means there are (at least) two paths to a git repository
where the debian tarball for hyx can live.
Both paths are fine with me.
@Russell I make it your call.
Please respond with an option from something along:
* Stappers: Yes, a git repo at Salsa is fine. Create one
* There is now ${GIT_REPO_URL}
* I prefer the old days approach when the debian directory
was "maintainer pet thing". (AFAIK this is still valid)
* I choose ..
> The original project has no version control.
That is fine. Upstream provides tarballs.
Thing that could be improved is that https://yx7.cc/code/hyx/
would has an index. Something that allows to see that a new
upstream version is available. (It is what debian utility `uscan`
does.)
Regards
Geert Stappers
* Tried (the packaged) `hyx`
* Willing to upload it into Debian
* Discussing if and where a hyx debian directory VCS repository
* Added upstream author, Lorenz Panny, to 'To: '
* Referenced https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004832 for
Lorenz
--
Silence is hard to parse
Bug#1004832: ITP: hyx -- minimalistic but powerful vim-like hex editor
On Wed, Feb 02, 2022 at 06:23:30AM -0600, Russell Hernandez Ruiz wrote: > On Wed, 2022-02-02 at 08:12 +0100, Geert Stappers wrote: > > Show the (libre software) world what is already done to get there. > > > > In other words: > > Make it possible that reviewing of the packaging came be started. > > I've attached everything. ... many lines ... > Package: hyx > Version: 2021.06.09-1 > Architecture: amd64 > Maintainer: Russell Hernandez Ruiz > Installed-Size: 61 > Depends: libc6 (>= 2.33) > Section: editors > Priority: optional > Multi-Arch: foreign > Homepage: https://yx7.cc/code/ > Description: minimalistic but powerful vim-like hex editor > A minimalistic (< 2300 lines of C) vim-like hex editor. > It can display ASCII with colors, insert/replace/delete, > copy/paste, undo/redo, and search. ... many lines ... Is there a VCS, Version Control System, that has hyx debian packaging? (Please recieve that yes-no-question as a conversation starter) Groeten Geert Stappers -- Silence is hard to parse
Bug#1004832: builds fine on unstable Was: Bug#1004832: ITP: hyx
On Wed, Feb 02, 2022 at 06:23:30AM -0600, Russell Hernandez Ruiz wrote: > > I was able to build on bullseye, OK > but not on stretch due to debhelper-compat. also OK (as in: no need the worry about) Groeten Geert Stappers -- Silence is hard to parse
Bug#1004832: improbable-bug-number-in-closes Was: Bug#1004832: ITP: hyx
On Wed, Feb 02, 2022 at 06:23:30AM -0600, Russell Hernandez Ruiz wrote: > On Wed, 2022-02-02 at 08:12 +0100, Geert Stappers wrote: > > Show the (libre software) world what is already done to get there. > > > > Lintian outputs: > > $ lintian hyx_2021.06.09-1_amd64.deb > W: hyx: improbable-bug-number-in-closes 1004832 > $ lintian hyx-dbgsym_2021.06.09-1_amd64.deb > $ > > We just got to 1,000,000 bugs; that perhaps seem unlikely to lintian? Indeed. > Not sure if an override is necessary here. No, not necessary. Groeten Geert Stappers DD -- Silence is hard to parse
Bug#1004832: ITP: hyx -- minimalistic but powerful vim-like hex editor
On Tue, Feb 01, 2022 at 04:25:01PM -0600, Russell Hernandez Ruiz wrote: > * Package name: hyx > > A minimalistic (< 2300 lines of C) vim-like hex editor. > It can display ASCII with colors, insert/replace/delete, > copy/paste, undo/redo, and search. > > The package is already made. I'm new to packaging so I'll need a sponsor. I'd > like for it to be included in bullseye. It only depends on libc (according to > dpkg, >= 2.17). It could even go into buster and stretch I think, but I don't > know if that's possible/desirable. > Show the (libre software) world what is already done to get there. In other words: Make it possible that reviewing of the packaging came be started. Groeten Geert Stappers -- Silence is hard to parse
Bug#1004658: Help to compile a wasm package
control: tag -1 -pending I might be wrong about the removal of that tag, do feel free to re-add it. On Mon, Jan 31, 2022 at 03:11:00PM +0100, Yadd wrote: (fully quoted because I'm adding 1004...@bugs.debian.org to the loop) > On 31/01/2022 15:00, Geert Stappers wrote: > > On Mon, Jan 31, 2022 at 01:09:43PM +0100, Yadd wrote: > > > Hi all, > > > > > > to update a nodejs package, > > > > Which package is that? Please provide an URL. > > Hi > > thanks for your answer. Here is the working package: > https://salsa.debian.org/js-team/node-source-map > > (embedded component source-map-mappings) At https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004658#35 is adviced: source-map-mappings should be packaged separately, and then build-depended on from package node-source-map. > > > I need to build a wasm file using cargo. I succeed to do it > > > > OKay, nice. > > > > > > > but it downloads some package during build process: > > > * libc-0.2.116 > > > * rand-0.4.6 > > > * vlq-0.5.1 > > > > > > Which package do I have to install as dependency to avoid this ? > > > > Some how I do read "How to avoid dependency?" > > > > Please elaborate your question. Because I don't understand it, > > but want to understand it. > > With network enabled, "cargo build" downloads these 3 packages and stores > them in ~/.cargo > > > > PS: sorry, I don't know anything about rust packaging, > > > neither rust/cargo themselves... > > > > > > > Some how I do read "I fear the yet unknown rust and unknown cargo world" > > > > Just tell more about "starting point" > > > to update a nodejs package, > > https://salsa.debian.org/js-team/node-source-map > > Cheers, > Yadd > Now I understand the } } } it builds } } } there are dependencies (they are fetched by Cargo) the problem^Wchallenge in my words } } } It builds when Internet access is allowed. } } } During "debian build" is Internet access not allowed } } } (to prevent unreproduceable builds). } } } How to get the missing build dependencies? Rust packages / crates needs to packaged for Debian. > > > * libc-0.2.116 With https://packages.debian.org/search?suite=stable=all=any=all=libc+rust did I found `librust-libc-dev`. > > > * rand-0.4.6 There is Debian package `librust-rand+libc-dev`. > > > * vlq-0.5.1 That one seems to be missing. Groeten Geert Stappers DD -- Silence is hard to parse
