Processing of python-ofxparse_0.21-2_source.changes

python-ofxparse_0.21-2_source.changes uploaded successfully to localhost along with the files: python-ofxparse_0.21-2.dsc python-ofxparse_0.21-2.debian.tar.xz python-ofxparse_0.21-2_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)

Question Hercules

Question Hercules Hi Hercules, I came across your page at https://packages.debian.org/unstable/main/siril and I had a quick question about this. Being a night photographer, we really need to stack our images to pull as much detail from them as possible, so I put together a guide on how to stack

easyh10_1.5-5_source.changes ACCEPTED into unstable

Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 18 Aug 2021 18:02:33 -0400 Source: easyh10 Architecture: source Version: 1.5-5 Distribution: unstable Urgency: medium Maintainer: Debian QA Group Changed-By: Boyuan Yang Changes: easyh10 (1.5-5) unstable; urgen

Processing of easyh10_1.5-5_source.changes

easyh10_1.5-5_source.changes uploaded successfully to localhost along with the files: easyh10_1.5-5.dsc easyh10_1.5.orig.tar.gz easyh10_1.5-5.debian.tar.xz easyh10_1.5-5_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)

Bug#992455: canna: use mktemp instead of tempfile in postinst

Package: canna Version: 3.7p3-16 tempfile was deprecated and mktemp is better anyway

Bug#992372: kst: Dirfile data sources (via libgetdata) are no longer recognized

Update: this is a dependency-related bug in libgetdata, and a separate bug report has been filed here:     https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992437 Depending on convention, please feel free to close this bug (it's not a KST bug) or leave it open until the dependency bug in libg

libpcre++_0.9.5-7_source.changes ACCEPTED into unstable

Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 18 Aug 2021 11:02:21 -0400 Source: libpcre++ Architecture: source Version: 0.9.5-7 Distribution: unstable Urgency: medium Maintainer: Debian QA Group Changed-By: Boyuan Yang Changes: libpcre++ (0.9.5-7) unstabl

grun_0.9.3+git20200303-1_source.changes ACCEPTED into unstable

Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 18 Aug 2021 11:09:37 -0400 Source: grun Architecture: source Version: 0.9.3+git20200303-1 Distribution: unstable Urgency: medium Maintainer: Debian QA Group Changed-By: Boyuan Yang Changes: grun (0.9.3+git20200

Processing of grun_0.9.3+git20200303-1_source.changes

grun_0.9.3+git20200303-1_source.changes uploaded successfully to localhost along with the files: grun_0.9.3+git20200303-1.dsc grun_0.9.3+git20200303.orig.tar.gz grun_0.9.3+git20200303-1.debian.tar.xz grun_0.9.3+git20200303-1_amd64.buildinfo Greetings, Your Debian queue daemon (run

Processing of libpcre++_0.9.5-7_source.changes

libpcre++_0.9.5-7_source.changes uploaded successfully to localhost along with the files: libpcre++_0.9.5-7.dsc libpcre++_0.9.5.orig.tar.gz libpcre++_0.9.5-7.debian.tar.xz libpcre++_0.9.5-7_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)

Bug#992430: schroot: user password does not match

Hi Roger, I compared `/etc/shadow` and `/etc/passwd` across my host and from inside the testable chroot environments, no difference, I also checked `/etc/pam.d/common-password` and it looks that bullseye uses `yescrypt` for hashing while buster uses `sha512`. It also says in `/etc/pam.d/common-pa

Bug#992430: schroot: user password does not match

Hi, I'm not personally familiar with the changes in the latest Debian release, but please check that all the password, shadow password files etc. are all copied into the chroot and are self-consistent with one another. Are the host files using a hash type not supported by the chroot environmen

Bug#992430: schroot: user password does not match

Package: schroot Version: 1.6.10-12 Severity: important X-Debbugs-Cc: ser...@vlasov.me Dear Maintainer, When doing schroot into a buster chroot environment, sudo commands fail due to password not matching the current user password. There is no such problem for bullseye chroot environment. To rep