Bug#918375: Info received (dockerd segfaults can be repeated)

[El boulangero]

Thanks for the details.

So I just uploaded a new version in experimental, it is
20.10.0~rc1+dfsg3-1. In this version docker.io vendors the old go-radix, as
suggested.

If someone can give it a try and confirm that indeed the bug is fixed, that
would be great. Thanks again.

  Arnaud

On Wed, Dec 2, 2020 at 12:48 AM Shengjing Zhu  wrote:

> Sadly I see it in my log too. So after searching a bit, I find this
>
> https://github.com/moby/libnetwork/pull/2581
>
> So it's indeed caused by golang-github-armon-go-radix-dev 1.0.0
>
> And docker maintainer has proposed a patch to go-radix,
> https://github.com/armon/go-radix/pull/14
> But reading from the issue, it seems docker just implemented in the wrong
> way.
>
> So I suggest vendoring the old go-radix...
>
> On Mon, Sep 16, 2019 at 1:53 PM Arnaud Rebillout
>  wrote:
> >
> >
> > From: Vincent Smeets 
> >
> > Using journalctl, I see the following error:
> >
> > panic: runtime error: invalid memory address or nil pointer dereference
> > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0
> pc=0x564a9d3a2158]
> > goroutine 439 [running]:
> > github.com/armon/go-radix.recursiveWalk(0x0, 0xc4212bddb8, 0xc4212bdc00)
> > /build/docker.io-18.06.1+dfsg1/.gopath/src/
> github.com/armon/go-radix/radix.go:477 +0x28
> >
> >
> > Hans, do you also see the same logs in the journal? (trying to be sure
> it's the same issue)
> >
> > docker-ce builds against armon/go-radix
> e39d623f12e8e41c7b5529e9a9dd67a1e2261f80, Jan 2015 [1]
> >
> > docker.io builds against armon/go-radix v1.0, Aug 2018 [2], as you can
> see with:
> >
> >   $ rmadison golang-github-armon-go-radix-dev
> >   golang-github-armon-go-radix-dev | 1.0.0-1 |
> stable | all
> >   golang-github-armon-go-radix-dev | 1.0.0-1 |
> unstable   | all
> >
> > That could be the issue. Now, I don't know if you hit a bug in go-radix
> v1.0, or if you hit an incompatibility between docker and the version v1.0
> of go-radix.
>
>
> --
> Shengjing Zhu
>

Bug#976253: nfdump: Please try to get new upstream release 1.6.22 into Bullseye

[Axel Beckert]

Package: nfdump
Severity: normal
Version: 1.6.20-1

Dear nfdump Maintainers,

please upload the latest upstream release 1.6.22 to Debian Unstable so
that we can have it in Bullseye.

Upstream changelog since 1.6.20, currently in Debian Unstable:

2020-11-21
- Release 1.6.22

2020-10-18
- Fix nfreplay v5 time shift bug

2020-10-17
- add support for >=, <= comparators. #256. Thanks to piorek94
- Fix yacc/bison warnings. Cleanup unused tokens
- Fix syntax error 'flags AS' as AS is a reserved word. #255
- Add element 139 for ICMP type/code in IPv6. #250
- Fix IPv4/IPv6 statistics representation #252

2020-09-12
- Cleanup nip/xip filter syntax. Add filter syntax 'nip in [ ]'. 
Request #246

2020-09-03
- Add nfversion to nfpcapd

2020-08-31
- Add collected netflow/sflow version in nfdump record. Request #242
- Fix GuessDir bug - issue #215

2020-08-02
- Re-address issue #231 - remove strict rule rfc 7011

2020-08-02
- Release 1.6.21
- Address issue #159. Implement rfc 7011 and include sender UDP port into 
unique template identification
- Address issue #236 Add token 'dir' equivalent to 'flowdir' in filter syntax

2020-07-25
- Add optional print direction ascending or descending to output of statistics 
-s and oredered printing -O. Request #235
- Fix issue #234 
- Fix #230 - Avoid use_syslog name clash on certain OS

2020-06-20
- Honor -n flag when printing sorted flow cache
- Fix uninitialized variable printPlain
- Fix bug #223 limit matchig flows -c
- Restore old behaviour unlimiting output flows unless in -s stat
- Fix ft2nfdump nexthop fields
- Fix ft2nfdump extension map size
- internal: put output parameters in a single struct
- Fix GuessDir bug - issue #215
- Compact Changelog
- Fix GuessDir bug - issue #215 in flow exporter

Thanks in advance!

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Bug#976252: RFS: pynpoint/0.8.3-2 -- Pipeline for processing and analysis of high-contrast imaging data

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "pynpoint":

 * Package name: pynpoint
   Version : 0.8.3-2
   Upstream Author : [fill in name and email of upstream]
 * URL : https://github.com/PynPoint/PynPoint
 * License : GPL-3-only, GPL-3+
 * Vcs : https://salsa.debian.org/debian-astro-team/pynpoint
   Section : science

It builds those binary packages:

  python3-pynpoint - Pipeline for processing and analysis of
high-contrast imaging data

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/pynpoint/

Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/p/pynpoint/pynpoint_0.8.3-2.dsc

Changes since the last upload:

 pynpoint (0.8.3-2) unstable; urgency=medium
 .
   * Source only upload.

Regards,
--
  Gürkan Myczko

Bug#976251: RFS: libansilove/1.2.8-1 -- Library for converting ANSI, ASCII, and other formats to PNG

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libansilove":

 * Package name: libansilove
   Version : 1.2.8-1
   Upstream Author : Frederic Cambus 
 * URL : https://github.com/ansilove/libansilove
 * License : BSD-2-clause, ISC
 * Vcs : [fill in URL of packaging vcs]
   Section : libs

It builds those binary packages:

  libansilove1 - Library for converting ANSI, ASCII, and other formats
to PNG
  libansilove-dev - Convert ANSI, ASCII, and other formats to PNG -
development files

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/libansilove/

Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/liba/libansilove/libansilove_1.2.8-1.dsc

Changes since the last upload:

 libansilove (1.2.8-1) unstable; urgency=medium
 .
   * New upstream version.
   * Bump debhelper version to 13, drop d/compat.
   * d/upstream/metadata: added.
   * d/control: added Rules-Requires-Root.
   * d/copyright: added Upstream-Contact.
   * d/shlibs.local: bump versions.
   * d/libansilove-dev.manpages: added.

Regards,
--
  Gürkan Myczko

Bug#976250: xtables-addons-dkms: fail to build with 4.19.0-13

[di dit]

Package: xtables-addons-dkms
Version: 3.2-1
Severity: important

Dear Maintainer,

After updating to linux 4.19.0-13, dkms failed with the following message:

/etc/kernel/postinst.d/dkms:
Error!  Build of xt_ACCOUNT.ko failed for: 4.19.0-13-amd64 (x86_64)
Consult the make.log in the build directory

The make.log file is attached.

Thanks for your help and your work on  this package.

-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-12-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xtables-addons-dkms depends on:
ii  dkms   2.6.1-4
ii  make   4.2.1-1.2
ii  xtables-addons-common  3.2-1

Versions of packages xtables-addons-dkms recommends:
pn  linux-headers  

xtables-addons-dkms suggests no packages.

-- no debconf information
DKMS make.log for xtables-addons-3.2 for kernel 4.19.0-13-amd64 (x86_64)
mercredi 2 décembre 2020, 07:36:46 (UTC+0100)
make : on entre dans le répertoire « /usr/src/linux-headers-4.19.0-13-amd64 »
make -C /usr/src/linux-headers-4.19.0-13-amd64 KBUILD_SRC=/usr/src/linux-headers-4.19.0-13-common \
-f /usr/src/linux-headers-4.19.0-13-common/Makefile modules
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (		\
echo >&2;			\
echo >&2 "  ERROR: Kernel configuration is invalid.";		\
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it.";	\
echo >&2 ;			\
/bin/false)
mkdir -p /var/lib/dkms/xtables-addons/3.2/build/extensions/.tmp_versions ; rm -f /var/lib/dkms/xtables-addons/3.2/build/extensions/.tmp_versions/*
make -f /usr/src/linux-headers-4.19.0-13-common/scripts/Makefile.build obj=/var/lib/dkms/xtables-addons/3.2/build/extensions
make -f /usr/src/linux-headers-4.19.0-13-common/scripts/Makefile.build obj=/var/lib/dkms/xtables-addons/3.2/build/extensions/ACCOUNT need-builtin=
make -f /usr/src/linux-headers-4.19.0-13-common/scripts/Makefile.build obj=/var/lib/dkms/xtables-addons/3.2/build/extensions/pknock need-builtin=
(cat /dev/null;   echo kernel//var/lib/dkms/xtables-addons/3.2/build/extensions/ACCOUNT/xt_ACCOUNT.ko;) > /var/lib/dkms/xtables-addons/3.2/build/extensions/ACCOUNT/modules.order
(cat /dev/null;   echo kernel//var/lib/dkms/xtables-addons/3.2/build/extensions/pknock/xt_pknock.ko;) > /var/lib/dkms/xtables-addons/3.2/build/extensions/pknock/modules.order
   gcc-8 -Wp,-MD,/var/lib/dkms/xtables-addons/3.2/build/extensions/ACCOUNT/.xt_ACCOUNT.o.d  -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/8/include -I/usr/src/linux-headers-4.19.0-13-common/arch/x86/include -I./arch/x86/include/generated  -I/usr/src/linux-headers-4.19.0-13-common/include -I./include -I/usr/src/linux-headers-4.19.0-13-common/arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I/usr/src/linux-headers-4.19.0-13-common/include/uapi -I./include/generated/uapi -include /usr/src/linux-headers-4.19.0-13-common/include/linux/kconfig.h -include /usr/src/linux-headers-4.19.0-13-common/include/linux/compiler_types.h  -I/var/lib/dkms/xtables-addons/3.2/build/extensions/ACCOUNT -I/var/lib/dkms/xtables-addons/3.2/build/extensions/ACCOUNT -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -funit-at-a-time -DCONFIG_X86_X32_ABI -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-int-in-bool-context -O2 --param=allow-store-data-races=0 -Wframe-larger-than=2048 -fstack-protector-strong -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-var-tracking-assignments -g -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -Wdeclaration-after-statement -Wno-pointer-sign -Wno-stringop-truncation -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=implicit-int 

Bug#971564: python-pygit2: libgit2 1.0 transition

[Ondrej Novy]

Hi,

if you want to proceed with the transition, maybe it's a good idea to
upload libgit2 to unstable first :)

python-pygit2 is ready for transition since 12 Jun 2020 (in experimental).

-- 
Best regards
Ondřej Nový

Bug#941986: [debian-mysql] Bug#941986: Bug#941986: Bug#941986: mariadb-client-10.3: InnoTop crashes during use

[Otto Kekäläinen]

Thanks Michael for PR at https://github.com/innotop/innotop/pull/176

Since upstream Innotop did now accepted your PR, do you want to submit
latest Innotop it at github.com/mariadb/server on branch 10.5 or at
https://salsa.debian.org/mariadb-team/mariadb-10.5 so that you can
later on enjoy the best Innotop experience in Debian?


--
- Otto

Bug#976249: dpkg: /usr/share/perl5/Dpkg/Source/Package.pm call syserror() instead of syserr()

[Uwe Steinmann]

Package: dpkg
Version: 1.20.5
Severity: normal

Dear Maintainer,

In line 547 of /usr/share/perl5/Dpkg/Source/Package.pm syserror()
instead of syserr() is called.

cp($src, $dst)
or syserr(g_('cannot copy %s to %s'), $src, 
$dst);

-- Package-specific info:

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-5
ii  liblzma5 5.2.4-1+b1
ii  libselinux1  3.1-2+b1
ii  tar  1.32+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.1.12
pn  debsig-verify  

-- no debconf information

Bug#975707: adb devices fails with munmap_chunk() invalid pointer

[Markus]

Pinning the needed packages

Package: adb*
Pin: version 1:8.1*
Pin-Priority: 1001

Package: android*
Pin: version 1:8.1*
Pin-Priority: 1001

Package: android*
Pin: version 8.1*
Pin-Priority: 1001

Package: android-sdk-platform*
Pin: version 27*
Pin-Priority: 1001

within /etc/apt/preferences does do the trick for me until the updates 
are merged into unstable.



Cheers,

Bug#976248: bluefish: Right-click on the little bookmark square crashes Bluefish (segment violation)

[rv]

Package: bluefish
Version: 2.2.12-1+b1
Severity: normal
X-Debbugs-Cc: riveravaldezm...@gmail.com

Dear Maintainer,

when you open Bluefish, write some characters, and press Ctrl+K (generating a 
bookmark, which is visible as a little black square at the beginning of the 
line), if you right-click over that little black square then Bluefish crashes 
and get closed, with a 'segment violation' message.

Let me know if you need any info.

Best regards!

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bluefish depends on:
ii  bluefish-data2.2.12-1
ii  bluefish-plugins 2.2.12-1+b1
ii  gvfs-backends1.46.1-1
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libenchant-2-2   2.2.12-1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-7
ii  libglib2.0-0 2.66.3-1
ii  libgtk-3-0   3.24.23-3
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libxml2  2.9.10+dfsg-6.2
ii  python3  3.8.6-1

bluefish recommends no packages.

Versions of packages bluefish suggests:
ii  chromium [www-browser]  83.0.4103.116-3.1
pn  csstidy 
pn  dos2unix
ii  epiphany-browser [www-browser]  3.38.1-1
ii  firefox-esr [www-browser]   78.5.0esr-1
pn  libxml2-utils   
pn  php-codesniffer 
pn  pylint  
pn  tidy
pn  weblint-perl | weblint  

-- no debconf information

Bug#974705: [PATCH] jobs: Only block in waitcmd on first run

[Herbert Xu]

This patch ensures that waitcmd never blocks unless there are
outstanding jobs.  This could otherwise trigger a hang if children
were created prior to the shell coming into existence, or if
there are backgrounded children of other kinds (e.g., a here-
document).

Fixes: 6c691b3e5099 ("jobs: Only clear gotsigchld when waiting...")
Reported-by: Michael Biebl 
Signed-off-by: Herbert Xu 

diff --git a/src/jobs.c b/src/jobs.c
index 3417633..516786f 100644
--- a/src/jobs.c
+++ b/src/jobs.c
@@ -81,6 +81,7 @@
 #define DOWAIT_NONBLOCK 0
 #define DOWAIT_BLOCK 1
 #define DOWAIT_WAITCMD 2
+#define DOWAIT_WAITCMD_ALL 4
 
 /* array of jobs */
 static struct job *jobtab;
@@ -615,7 +616,7 @@ waitcmd(int argc, char **argv)
jp->waited = 1;
jp = jp->prev_job;
}
-   if (!dowait(DOWAIT_WAITCMD, 0))
+   if (!dowait(DOWAIT_WAITCMD_ALL, 0))
goto sigout;
}
}
@@ -1138,6 +1139,7 @@ static int dowait(int block, struct job *jp)
pid = waitone(block, jp);
rpid &= !!pid;
 
+   block &= ~DOWAIT_WAITCMD_ALL;
if (!pid || (jp && jp->state != JOBRUNNING))
block = DOWAIT_NONBLOCK;
} while (pid >= 0);
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#976247: speech-dispatcher: conffiles not removed: /etc/speech-dispatcher/modules/ kali.conf ibmtts.conf baratinoo.conf

[Paul Wise]

Package: speech-dispatcher
Version: 0.10.2-1
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade,
or to move them to speech-dispatcher-{kali,ibmtts,baratinoo}.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ p=speech-dispatcher ; adequate $p ; dpkg-query -W -f='${Conffiles}\n' $p | 
grep obsolete
speech-dispatcher: obsolete-conffile /etc/speech-dispatcher/modules/kali.conf
speech-dispatcher: obsolete-conffile /etc/speech-dispatcher/modules/ibmtts.conf
speech-dispatcher: obsolete-conffile 
/etc/speech-dispatcher/modules/baratinoo.conf
 /etc/speech-dispatcher/modules/kali.conf f2bb689fe05aa29ec830c65ad30189e4 
obsolete
 /etc/speech-dispatcher/modules/ibmtts.conf 4d7812b0b95020ffa19be4ea7e53c06a 
obsolete
 /etc/speech-dispatcher/modules/baratinoo.conf 7595456c249126d7f5cc31f9628b32aa 
obsolete

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages speech-dispatcher depends on:
ii  adduser  3.118
ii  init-system-helpers  1.59
ii  libc6    2.31-5
ii  libdotconf0  1.3-0.3
ii  libglib2.0-0 2.66.3-1
ii  libltdl7 2.4.6-14
ii  libsndfile1  1.0.28-8
ii  libspeechd2  0.10.2-1
ii  lsb-base 11.1.0
ii  speech-dispatcher-audio-plugins  0.10.2-1

Versions of packages speech-dispatcher recommends:
ii  pulseaudio   13.0-5
pn  sound-icons  
pn  speech-dispatcher-espeak-ng  

Versions of packages speech-dispatcher suggests:
ii  espeak  1.48.04+dfsg-9
pn  libttspico-utils    
pn  mbrola  
pn  speech-dispatcher-cicero    
pn  speech-dispatcher-doc-cs    
pn  speech-dispatcher-espeak    
pn  speech-dispatcher-festival  
pn  speech-dispatcher-flite 

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#971570: [Pkg-julia-devel] Bug#971570: julia: libgit2 1.0 transition

[Norbert Preining]

Hi Ximin,

On Tue, 01 Dec 2020, Ximin Luo wrote:
> Control: severity -1 serious

I am very doubtful what you are doing here.

Have you tested julia with libgit2 1.0? Are there build errors?

I don't see any, the package builds fine with libgit2-dev 1.0.1+dfsg.1-1
from experimental, I just did a test build.

That means, the transition would require a simple binary rebuild,
without any action on our side.

I tend to close this bug as incorrect.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#976187: runit-systemd => runit-run transition fails to enable unit

[Lorenzo]

Control: tag -1 moreinfo


Hi,

On 12/1/20 8:26 AM, Jamie Heilman wrote:
> Package: runit
> Version: 2.1.2-38
>
> The runit-run package fails to enable the runit.service unit during
> installation on systems that use systemd.  This is surprising behavior
> that isn't documented in the NEWS file (if it was even intentional)
> and leaves folks with a previously working setup w/runit-systemd a
> system that won't start runit on next reboot.
It is not intentional and it comes to me as a surprise: I'm relying on
dh_installsystemd to manage the systemd service, and the default
is to enable the unit on install..
anyway I've just done another round of test in a Vbox machine with systemd
and i cannot reproduce the issue.
i've done the following

1. downgrade runit-run --> runit-systemd

    download in /some/dir/ runit-systemd from
https://packages.debian.org/sid/all/runit-systemd/download

    apt install /some/dir/runit-systemd_2.1.2-36_all.deb

2. upgrade again to runit-run

    apt-get install runit-run

3. reboot the system

at this point 'systemctl status runit.service' shows the service as
active and enabled,
and i can also see the runsvdir process with pstree.

A few wild guess on why the service is not enabled for you:

* Maybe you disabled the service at some point before the upgrade?
  Note that with systemd 'enabled' and 'started' are decoupled, so if
you disable the service
  it will continue to run until the next reboot.

* You are upgrading from an old version of runit (<2.1.2-31)?

  there's been a change in the directory that is watched by runsvdir
when runit
  is not init: it was /etc/runit/runsvdir/default, now it's
/etc/runit/runsvdir/svmanaged;
  again you will notice this only on after a reboot: the runit.service
is enabled and running
  but there will be no services supervised

With "fails to enable the runit.service" you mean that an error happened
during the upgrade,
or that the upgrade is successfull but at the end the service is disabled?
What does 'systemctl status runit.service' say? (note the second line
'vendor preset: enabled')

Regards,
Lorenzo

Bug#976187: runit-systemd => runit-run transition fails to enable unit

[Jamie Heilman]

Lorenzo wrote:
> at this point 'systemctl status runit.service' shows the service as
> active and enabled, and i can also see the runsvdir process with
> pstree.
> 
> A few wild guess on why the service is not enabled for you:
> 
> * Maybe you disabled the service at some point before the upgrade?
>
>   Note that with systemd 'enabled' and 'started' are decoupled, so
>   if you disable the service it will continue to run until the next
>   reboot.

No, I've never disabled runit.

> * You are upgrading from an old version of runit (<2.1.2-31)?
> 
>   there's been a change in the directory that is watched by runsvdir
>   when runit is not init: it was /etc/runit/runsvdir/default, now
>   it's /etc/runit/runsvdir/svmanaged; again you will notice this
>   only on after a reboot: the runit.service is enabled and running  
>   but there will be no services supervised

Actually my /etc/service is a directory not a symlink at all, always
has been.  Here's every upgrade of the package going back 6 years:

root@ruth:~# grep 'upgrade runit' /var/log/dpkg.log 
2014-07-30 23:12:17 upgrade runit:amd64 2.1.1-6.2 2.1.1-7
2014-08-02 11:33:30 upgrade runit:amd64 2.1.1-7 2.1.1-8
2014-08-15 20:45:37 upgrade runit:amd64 2.1.1-8 2.1.2-1
2014-10-27 20:53:26 upgrade runit:amd64 2.1.2-1 2.1.2-2
2014-12-31 18:38:32 upgrade runit:amd64 2.1.2-2 2.1.2-3
2016-08-02 00:54:53 upgrade runit:amd64 2.1.2-3 2.1.2-5
2016-08-24 00:13:26 upgrade runit:amd64 2.1.2-5 2.1.2-6
2016-09-13 22:16:06 upgrade runit:amd64 2.1.2-5 2.1.2-8
2016-10-15 14:45:55 upgrade runit:amd64 2.1.2-8 2.1.2-9
2017-06-04 18:55:24 upgrade runit:amd64 2.1.2-9 2.1.2-9.2
2018-04-12 20:43:05 upgrade runit-systemd:all 2.1.2-9.2 2.1.2-10
2018-04-12 20:43:07 upgrade runit:amd64 2.1.2-9.2 2.1.2-10
2018-04-15 20:05:02 upgrade runit-helper:all 2.7.1 2.7.2
2018-04-15 20:05:03 upgrade runit-systemd:all 2.1.2-10 2.1.2-11
2018-04-15 20:05:05 upgrade runit:amd64 2.1.2-10 2.1.2-11
2018-04-23 00:03:50 upgrade runit-systemd:all 2.1.2-11 2.1.2-12
2018-04-23 00:03:51 upgrade runit:amd64 2.1.2-11 2.1.2-12
2018-05-14 21:53:35 upgrade runit-systemd:all 2.1.2-12 2.1.2-13
2018-05-14 21:53:36 upgrade runit:amd64 2.1.2-12 2.1.2-13
2018-05-27 14:25:26 upgrade runit-helper:all 2.7.2 2.7.3
2018-05-27 14:25:27 upgrade runit-systemd:all 2.1.2-13 2.1.2-14
2018-05-27 14:25:29 upgrade runit:amd64 2.1.2-13 2.1.2-14
2018-06-02 20:07:39 upgrade runit-systemd:all 2.1.2-14 2.1.2-15
2018-06-02 20:07:45 upgrade runit:amd64 2.1.2-14 2.1.2-15
2018-10-09 22:09:24 upgrade runit-systemd:all 2.1.2-15 2.1.2-16
2018-10-09 22:09:26 upgrade runit:amd64 2.1.2-15 2.1.2-16
2018-10-28 11:58:15 upgrade runit-systemd:all 2.1.2-16 2.1.2-17
2018-10-28 11:58:19 upgrade runit:amd64 2.1.2-16 2.1.2-17
2018-11-08 01:13:27 upgrade runit-systemd:all 2.1.2-17 2.1.2-18
2018-11-08 01:13:29 upgrade runit:amd64 2.1.2-17 2.1.2-18
2018-11-25 00:56:45 upgrade runit-systemd:all 2.1.2-18 2.1.2-19
2018-11-25 00:56:48 upgrade runit:amd64 2.1.2-18 2.1.2-19
2019-01-05 20:50:34 upgrade runit:amd64 2.1.2-19 2.1.2-21
2019-01-07 19:06:11 upgrade runit-systemd:all 2.1.2-19 2.1.2-22
2019-01-07 19:06:12 upgrade runit:amd64 2.1.2-21 2.1.2-22
2019-01-20 22:55:40 upgrade runit-helper:all 2.7.3 2.8.2
2019-01-23 20:58:40 upgrade runit-helper:all 2.8.2 2.8.3
2019-02-06 22:50:02 upgrade runit-helper:all 2.8.3 2.8.4
2019-02-10 21:49:13 upgrade runit-helper:all 2.8.4 2.8.5
2019-02-17 22:03:52 upgrade runit-helper:all 2.8.5 2.8.6
2019-03-08 19:45:02 upgrade runit-systemd:all 2.1.2-22 2.1.2-24
2019-03-08 19:45:04 upgrade runit:amd64 2.1.2-22 2.1.2-24
2019-03-11 22:05:05 upgrade runit-systemd:all 2.1.2-24 2.1.2-25
2019-03-11 22:05:07 upgrade runit:amd64 2.1.2-24 2.1.2-25
2019-07-12 22:17:30 upgrade runit-helper:all 2.8.6 2.8.13.1
2019-07-13 11:25:35 upgrade runit-helper:all 2.8.13.1 2.8.13.2
2019-07-17 10:00:04 upgrade runit-systemd:all 2.1.2-25 2.1.2-32
2019-07-17 10:00:06 upgrade runit:amd64 2.1.2-25 2.1.2-32
2019-08-16 20:56:34 upgrade runit-systemd:all 2.1.2-32 2.1.2-33
2019-08-16 20:56:36 upgrade runit:amd64 2.1.2-32 2.1.2-33
2019-09-02 13:44:41 upgrade runit-helper:all 2.8.13.2 2.8.14
2019-09-28 21:19:22 upgrade runit-systemd:all 2.1.2-33 2.1.2-35
2019-09-28 21:19:24 upgrade runit:amd64 2.1.2-33 2.1.2-35
2020-03-15 22:49:23 upgrade runit-systemd:all 2.1.2-35 2.1.2-36
2020-03-15 22:49:26 upgrade runit:amd64 2.1.2-35 2.1.2-36
2020-03-15 22:49:26 upgrade runit-helper:all 2.8.14 2.8.15
2020-07-26 14:51:57 upgrade runit-helper:all 2.8.15 2.9.0
2020-11-14 07:47:35 upgrade runit-helper:all 2.9.0 2.10.1
2020-11-22 20:43:00 upgrade runit-helper:all 2.10.1 2.10.2
2020-11-25 18:25:00 upgrade runit:amd64 2.1.2-36 2.1.2-38

It's not the critical difference, though of the 3 systems running
unstable that I've seen this failure on, all 3 were converted to
systemd from sysvinit and have been in existance for a long enough
time that /etc/service is not a symlink.  Ultimately it makes no
real difference to /etc/runit/2, and it's not going to be a
particularly uncommon scenario for 

Bug#976246: dpkg-source: Reference detection of native vs non-native source package type

[Anatoli Babenia]

Package: dpkg-dev
Version: 1.19.7
Severity: normal
File: /usr/bin/dpkg-source

Dear Maintainer,

It would help greatly if `dpkg-source` reported native or non-native
package type.

-dpkg-source: info: using source format '1.0'
+dpkg-source: info: using non-native source format '1.0'

There is no information about native vs non-native format in this wiki page
https://wiki.debian.org/Packaging/SourcePackage

Mentors FAQ explains it in a lot of detail, but still hard to understand.
https://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a_native_Debian_
package_and_a_non-native_package.3F

`dpkg-source` code does explain the logic either. Detection of source format
relies on checking command line flags, and it does not make sense to me.

my $v = Dpkg::Version->new($self->{fields}->{'Version'});
if ($sourcestyle =~ m/[kpursKPUR]/) {
error(g_('non-native package version does not contain a revision'))
if $v->is_native();
} else {
# FIXME: This will become fatal in the near future.
warning(g_('native package version may not have a revision'))
unless $v->is_native();
}

https://salsa.debian.org/dpkg-team/dpkg/-/blob/09c9e02046f18f02bf3c3c2533bc557abfdc828c/scripts/Dpkg/Source/Package/V1.pm#L355

It would be nice to see a reference algorithm that detects different package
types. It would help people like me to troubleshoot issues with Debian
packaging faster.

https://github.com/openSUSE/obs-build/issues/633

I was not aware of the differences between native and non-native
packages before. Wish I could spend less time discovering this.

Bug#976245: mugshot: Muhshot fails with AttributeError: 'ElementTree' object has no attribute 'getiterator' in console

[Juozas Pocius]

Package: mugshot
Version: 0.4.2-1
Severity: important
X-Debbugs-Cc: juoza...@gmail.com

Dear Maintainer,

I'm unable to run mugshot, as it fails with error in console as shown below
It triggers a python3 error when trying to run it, with python 3.9 as default,
window does not open, so I'm unable to edit user information.

Terminal output:
$ mugshot
Traceback (most recent call last):
  File "/usr/bin/mugshot", line 36, in 
mugshot.main()
  File "/usr/lib/python3/dist-packages/mugshot/__init__.py", line 47, in main
window = MugshotWindow.MugshotWindow()
  File "/usr/lib/python3/dist-packages/mugshot_lib/Window.py", line 51, in
__new__
builder = get_builder('MugshotWindow')
  File "/usr/lib/python3/dist-packages/mugshot_lib/helpers.py", line 43, in
get_builder
builder.add_from_file(ui_filename)
  File "/usr/lib/python3/dist-packages/mugshot_lib/Builder.py", line 92, in
add_from_file
ele_widgets = tree.getiterator("object")
AttributeError: 'ElementTree' object has no attribute 'getiterator'



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mugshot depends on:
ii  accountsservice  0.6.55-3
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-1
ii  gir1.2-gdkpixbuf-2.0 2.40.0+dfsg-8
ii  gir1.2-glib-2.0  1.66.1-1+b1
ii  gir1.2-gst-plugins-base-1.0  1.18.1-1
ii  gir1.2-gstreamer-1.0 1.18.1-1
ii  gir1.2-gtk-3.0   3.24.23-3
ii  python3  3.9.0-3
ii  python3-cairo1.16.2-4+b1
ii  python3-dbus 1.2.16-4
ii  python3-gi   3.38.0-1+b1
ii  python3-pexpect  4.6.0-4

Versions of packages mugshot recommends:
pn  gir1.2-cheese-3.0  
pn  gir1.2-gtkclutter-1.0  
pn  gstreamer1.0-tools 

Versions of packages mugshot suggests:
pn  gstreamer1.0-plugins-good  

-- no debconf information

Bug#932870: marked as pending in lintian

[Paul Wise]

On Tue, 2020-12-01 at 17:55 -0800, Felix Lechner wrote:

> Which part, please? For the level, 'warning' is too high for a
> peripheral matter like tests, which are optional.

From my previous mail:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932870#17

   In addition I think this superficial-only-tests tag should be of a
   different severity to testsuite-autopkgtest-missing, perhaps raised to
   info or warning level instead of pedantic.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#976244: RFA: sudo -- Provide limited super user privileges to specific users

[Bdale Garbee]

Package: wnpp
Severity: normal

I took over the sudo package in August of 1996, and have maintained it since
then.  The package is in pretty good condition, with very reliable core 
functionality.  Upstream is active and responds promptly to concerns.  Despite
this, there are a significant number of bugs open against the package, a fair
number of which are related to the LDAP interface or other features I don't
use, and just don't have the time, facilities, and/or motivation to work on.  

So, I think that after nearly a quarter century taking care of sudo in
Debian, it's time someone else took over the package.

Because this package is more or less "essential" to many users despite 
being marked as 'optional' in our packaging system, I'd like to suggest 
anyone considering taking it on look over the package, review the open 
bug list, and then reach out to me for some conversation before making a
committment to take it over.

Bdale

Bug#976243: ITP: deepin-log-viewer -- System log viewer of Deepin Desktop Environment

[Tu Qinggang]

Package:wnpp
Severity: wishlist
Owner: Tu Qinggang 
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name    : deepin-album
  Version : 5.8.0.13.1
  Upstream Author : Deepin Technology Co, Ltd.
* URL : https://github.com/linuxdeepin/deepin-log-viewer
  License : GPL-3.0
  Programming Lang: C++
  Description : System log viewer of Deepin Desktop Environment

deepin-log-viewer is a fast and lightweight application for viewing 
system log

Log viewer provides a graphical interface for viewing system logs


It is part of Deepin software and DDE (Deepin Desktop Environment)

I intend to co-maintain this package inside the pkg-deepin group.

Bug#975191: rust-js-sys: FTBFS: dh_auto_test: error: /usr/share/cargo/bin/cargo build returned exit code 101

[peter green]

> This will impact quite some other modules.

I agree that the current autoremoval list looks pretty scary, so I decided to 
do some
dependency analysis. It seems there are 5 source packages with direct or 
indirect hard
dependencies on rust-js-sys.

rust-www-sys
rust-ring
rust-rustls
rust-sct
rust-webpki

There are also some feature packages which directly or indirectly depend on 
rust-js-sys.

librust-chrono+js-sys-dev (already dropped by the version of rust-chrono in 
unstable)
librust-chrono+wasmbind-dev (already dropped by the version of rust-chrono in 
unstable)
librust-cookie+ring-dev (not in testing)
librust-cookie+secure-dev (not in testing)
librust-trust-dns-proto+dnssec-ring-dev
librust-trust-dns-proto+ring-dev
librust-reqwest+rustls-dev
librust-reqwest+rustls-tls-dev
librust-reqwest+webpki-roots-dev


None of these feature packages seem to have any reverse dependencies. 
Furthermore None of the other
binaries built from rust-trust-dns-proto seem to have any reverse dependenices 
in unstable.
For rust-reqwest there seems to be one reverse dependency in unstable, but it 
is not
currently in testing for other reasons.

In summary once kpcyrd's upload of rust-chrono migrates to testing, the list of 
packages
to be autoremoved because of rust-js-sys should get a lot shorter.

Bug#976231: [socklog] Please split socklog binaries package from system configuration

[Mathieu Mirmont]

On Tue, Dec 01, 2020 at 10:48:26PM +0100, Michał Mirosław wrote:
> Current unstable package introduces a lot of unneeded dependencies
> making it hard to use socklog outside of system-wide use-case (eg. in
> trimmed-down chroot). Please split the system configuration part to
> separate package, as the program itself doesn't hard-depend on more
> than the libc.
>
> This is a regression compared to the 2.1.0-8 version carried over from
> ancient times.

Hi Michał,

It is true that the socklog package is indeed intended to be deployed
as a replacement for system log daemons such as rsyslogd. This was a
deliberate choice. I am interested in your use-case though, do you use
svlogd/runit at all with socklog?

The current dependencies are quite few really:
Depends: runit, runit-helper (>= 2.10.0~),
 sysuser-helper (<< 1.4), libc6 (>= 2.4)

Together these weight about 530K (excluding libc6). A rather large
part of this is in fact man pages and stuff under /usr/share/doc,
which are both often removed from trimmed-down chroots.

Which of these dependencies is bothering you?

Cheers,

-- 
Mathieu Mirmont 


signature.asc
Description: PGP signature

Bug#976241: ITP: pyannotate -- PyAnnotate: Auto-generate PEP-484 annotations

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi 

* Package name: pyannotate
  Version : 1.2.0
  Upstream Author : Dropbox 
* URL : https://github.com/dropbox/pyannotate
* License : Apache 2.0
  Programming Lang: Python
  Description : PyAnnotate: Auto-generate PEP-484 annotations

Binary package names: python3-pyannotate

 PyAnnotate: Auto-generate PEP-484 annotations
 =
 .
 Insert annotations into your source code based on call arguments and
 return types observed at runtime.
 .
 For license and copyright see the end of this file.
 .
 Blog post: 
http://mypy-lang.blogspot.com/2017/11/dropbox-releases-pyannotate-auto.html
 .
 How to use
 ==
 .
 See also the example directory.
 .
 Phase 1: Collecting types at runtime
 
 .
 - Install the usual way (see "red tape" section below)
 - Add `from pyannotate_runtime import collect_types` to your test
 - Early in your test setup, call `collect_types.init_types_collection()`
 - Bracket your test execution between calls to `collect_types.start()` and
   `collect_types.stop()` (or use the context manager below)
 - When done, call `collect_types.dump_stats(filename)`
 .
 All calls between the `start()` and `stop()` calls will be analyzed
 and the observed types will be written (in JSON form) to the filename
 you pass to `dump_stats()`.  You can have multiple start/stop pairs
 per dump call.
 .
 If you'd like to automatically collect types when you run `pytest`,
 see `example/example_conftest.py` and `example/README.md`.
 .
 Instead of using `start()` and `stop()` you can also use a context
 manager:
 ```
 collect_types.init_types_collection()
 with collect_types.collect():
 
 collect_types.dump_stats()
 ```
 .
 Phase 2: Inserting types into your source code
 --
 .
 The command-line tool `pyannotate` can add annotations into your
 source code based on the annotations collected in phase 1.  The key
 arguments are:
 .
 - Use `--type-info FILE` to tell it the file you passed to `dump_stats()`
 - Positional arguments are source files you want to annotate
 - With no other flags the tool will print a diff indicating what it
   proposes to do but won't do anything.  Review the output.
 - Add `-w` to make the tool actually update your files.
   (Use git or some other way to keep a backup.)
 .
 At this point you should probably run mypy and iterate.  You probably
 will have to tweak the changes to make mypy completely happy.
 .
 Notes and tips
 --
 .
 - It's best to do one file at a time, at least until you're
   comfortable with the tool.
 - The tool doesn't touch functions that already have an annotation.
 - The tool can generate either of:
   - type comments, i.e. Python 2 style annotations
   - inline type annotations, i.e. Python 3 style annotations, using `--py3` in 
v1.0.7+
 .
 Red tape
 
 .

Bug#976242: ssh-copy-id: fails to copy key

[Lisandro Damián Nicanor Pérez Meyer]

Package: openssh-client
Version: 1:8.4p1-2
Severity: normal
Tags: patch
X-Debbugs-Cc: lisan...@debian.org

Hi! I have been experiencing issues copying a key with ssh-copy-id which are 
solved by
upstream in https://github.com/openssh/openssh-portable/pull/206/files

Tested the patch myself.

Thanks!


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:es
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openssh-client depends on:
ii  adduser   3.118
ii  dpkg  1.20.5
ii  libc6 2.31-4
ii  libedit2  3.1-20191231-1
ii  libfido2-11.5.0-2
ii  libgssapi-krb5-2  1.18.3-4
ii  libselinux1   3.1-2+b1
ii  libssl1.1 1.1.1h-1
ii  passwd1:4.8.1-1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.10-1

Versions of packages openssh-client suggests:
pn  keychain   
ii  ksshaskpass [ssh-askpass]  4:5.19.5-3
pn  libpam-ssh 
pn  monkeysphere   

-- no debconf information

Bug#976180: RFS: libzc/0.4.3-1 -- Command line tool for the libzc library

[Marc Ferland]

On Tue, Dec 1, 2020 at 3:07 PM Niels Thykier  wrote:
>
> Niels Thykier:
> > Control: tags -1 moreinfo
> >
> > Marc Ferland:
> >> Package: sponsorship-requests
> >> Severity: normal
> >>
> >> Dear mentors,
> >>
> >> [...]
> >>
> >> Changes since the last upload:
> >>
> >>  libzc (0.4.3-1) unstable; urgency=low
> >>  .
> >>* New upstream release.
> >>* New Dockerfile to simplify debian releases.
> >>* Removed zc_file_info_offset() function from API.
> >>* Added two new functions to the API: zc_file_info_offset_begin() and
> >>  zc_file_info_offset_end().
> >>* ABI change libzc4 -> libzc6
> >>* Added the possibility to specify the filenames instead of the
> >>  offsets in the plaintext cracker in yazc tool.
> >>* Added the -S option to the plaintext cracker to print time stats.
> >>
> >> Regards,
> >> --
> >>   Marc Ferland
> >>
> >
> > Hi Marc,
> >
> >
> > I found a few issues I would like to see resolved before I will sponsor
> > the upload.
> >
> >
> > [...]
> >
> > SONAME bump
> > ===
> >
> > The library changes SONAME and there is no mention of it.
>
> I take that back, there is a mention in the changelog.  However, the
> following part:
>
> > This requires
> > a transition if the package has reverse dependencies, but there is no
> > comment from you on whether you have started the relevant transition
> > procedures or that they are irrelevant because your package has no
> > reverse dependencies in unstable and testing.
> >
>
> still stands and still needs an answer.
>
>
> Apologies for the oversight on my part in my first answer.

Thanks for your comments. I get the message! :-)

No transition is required since the libzc4 library does not have any reverse
dependencies either in unstable or testing.

Output from 'apt-cache rdepends libzc4' in unstable and testing:
libzc4
Reverse Depends:
  libzc-dev
  yazc

Updated the changelog following your comments and uploaded a new version
to debian mentors here:

https://mentors.debian.net/package/libzc/

Regards,

Marc

Bug#932870: marked as pending in lintian

[Felix Lechner]

Hi Paul,

On Tue, Dec 1, 2020 at 4:39 PM Paul Wise  wrote:
>
> This seems to miss part of my request:

Which part, please? For the level, 'warning' is too high for a
peripheral matter like tests, which are optional.

Kind regards,
Felix Lechner

Bug#976240: hplip: Upgrede to 3.20.9+dfsg0-4 broke laserjet mfp network printing/scanning

[andrew]

Package: hplip
Version: 3.20.9+dfsg0-4
Severity: important

Dear Maintainer,

The hplip package was update in testing from 3.20.5+dfsg0-3+b1 to 3.20.9+dfsg0-4
After which I'm no longer able to install my network HP LaserJet MFP
M148 printer.
Installing the printer using hp-setup -i fails with the following:

hp-setup -i -a -x 192.168.89.196

HP Linux Imaging and Printing System (ver. 3.20.9)
Printer/Fax Setup Utility ver. 9.0

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.



| SELECT CONNECTION (I/O) TYPE |


  Num   Connection  Description
Type
    --  
--
  0*usb Universal Serial Bus (USB)
  1 net Network/Ethernet/Wireless (direct connection or 
JetDirect)

Enter number 0...1 for connection type (q=quit, enter=usb*) ? 1

Using connection type: net

error: No device selected/specified or that supports this functionality.

I can print to the printer using the KDE cups connection:
implicitclass://HP_LaserJet_Pro_M148fdw_E27AD3_/

Thank you,
Andrew

-- Package-specific info:
Saving output in log file: /home/andrew/Downloads/hp-check.log

HP Linux Imaging and Printing System (ver. 3.20.9)
Dependency/Version Check Utility ver. 15.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Note: hp-check can be run in three modes:
1. Compile-time check mode (-c or --compile): Use this mode before compiling 
the HPLIP supplied tarball (.tar.gz or .run) to determine if the proper 
dependencies are installed to successfully compile HPLIP.   

   
2. Run-time check mode (-r or --run): Use this mode to determine if a distro 
supplied package (.deb, .rpm, etc) or an already built HPLIP supplied tarball 
has the proper dependencies installed to successfully run.  

 
3. Both compile- and run-time check mode (-b or --both) (Default): This mode 
will check both of the above cases (both compile- and run-time dependencies).   

   

Check types:



a. EXTERNALDEP - External Dependencies  



b. GENERALDEP - General Dependencies (required both at compile and run time)



c. COMPILEDEP - Compile time Dependencies   



d. [All are run-time checks]



PYEXT SCANCONF QUEUES PERMISSION




Status Types:
OK
MISSING   - Missing Dependency or Permission or Plug-in
INCOMPAT  - Incompatible dependency-version or Plugin-version

warning: debian-testing version is not supported. Using debian-10.4 versions 
dependencies to verify and install...

---
| SYSTEM INFO |
---

 Kernel: 5.9.0-3-amd64 #1 

Bug#974058: Help with an arm64 specific gcc internal error with polymake

[Wookey]

On 2020-11-28 07:32 -0400, David Bremner wrote:
> Wookey  writes:
> 
> > On 2020-11-27 10:28 -0400, David Bremner wrote:
> >
> >> I'm talking about remove polymake/arm64, not perl.
> >
> > Right, but perl build-depends on polymake, so with no polymake we
> > can't update perl (e.g. for security reasons)
> >
> 
> That doesn't make sense to me. Polymake is software for mathematical
> research, which happens to be a perl extension.

OK. I think I had the wrong end of the stick. I assumed it was a
build-dep because Dominic said somewhere in this thread/bugrep that it
being broken was blocking the perl transition, so I assumed that it
was needed to build perl, but I guess he just meant that everything
which is a perl module has to be rebuilt against the current perl
before it can migrate?

In which case you are quite right, removing polymake does not affect
perl updates. Adrian's latest message suggests that the issue is gone
in the latest gcc-10 upload so hopefully polymake can stay for now.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#974797: pocl: Please upgrade to llvm-toolchain-11

[Andreas Beckmann]

On 11/19/20 3:39 PM, Andreas Beckmann wrote:
> POCL built against LLVM 10 (sid) or LLVM 11 (experimental) causes a 
> autopkgtest regression on armhf in libgpuarray while it succeeded with 
> LLVM 9.

I finally managed to create a plain c reproducer (based on some pocl
test) which dies with this backtrace on abel.d.o:

#0  getEmissionKind () at 
/build/llvm-toolchain-10-hVI0Qp/llvm-toolchain-10-10.0.1/llvm/include/llvm/IR/DebugInfoMetadata.h:1244
#1  initialize () at 
/build/llvm-toolchain-10-hVI0Qp/llvm-toolchain-10-10.0.1/llvm/lib/CodeGen/LexicalScopes.cpp:53
#2  0xb13a82f0 in computeIntervals () at 
/build/llvm-toolchain-10-hVI0Qp/llvm-toolchain-10-10.0.1/llvm/lib/CodeGen/LiveDebugVariables.cpp:979
#3  runOnMachineFunction () at 
/build/llvm-toolchain-10-hVI0Qp/llvm-toolchain-10-10.0.1/llvm/lib/CodeGen/LiveDebugVariables.cpp:996
#4  runOnMachineFunction () at 
/build/llvm-toolchain-10-hVI0Qp/llvm-toolchain-10-10.0.1/llvm/lib/CodeGen/LiveDebugVariables.cpp:1023
#5  0xb141d6c8 in runOnFunction () at 
/build/llvm-toolchain-10-hVI0Qp/llvm-toolchain-10-10.0.1/llvm/lib/CodeGen/MachineFunctionPass.cpp:73
#6  0xb1297494 in runOnFunction () at 
/build/llvm-toolchain-10-hVI0Qp/llvm-toolchain-10-10.0.1/llvm/lib/IR/LegacyPassManager.cpp:1481
#7  0xb1297750 in runOnModule () at 
/build/llvm-toolchain-10-hVI0Qp/llvm-toolchain-10-10.0.1/llvm/lib/IR/LegacyPassManager.cpp:1517
#8  0xb1297ba8 in runOnModule () at 
/build/llvm-toolchain-10-hVI0Qp/llvm-toolchain-10-10.0.1/llvm/lib/IR/LegacyPassManager.cpp:1582
#9  run () at 
/build/llvm-toolchain-10-hVI0Qp/llvm-toolchain-10-10.0.1/llvm/lib/IR/LegacyPassManager.cpp:1694
#10 0xb6dfac82 in pocl_llvm_codegen (Device=Device@entry=0x1a3dfc8, 
Modp=0x20102d8, Output=Output@entry=0xbe9be8bc, 
OutputSize=OutputSize@entry=0xbe9be8d0) at ./lib/CL/pocl_llvm_wg.cc:624
#11 0xb6dbf1de in llvm_codegen (output=output@entry=0x1be75e0 
"/home/anbe/.cache/pocl/kcache/AP/PNFEAPBKBFEAKGGNMALGHGJEEKGMJFBFBMDHA/Sdot_kernel/0-0-0/Sdot_kernel.so",
 device_i=device_i@entry=0, kernel=kernel@entry=0xbe9c0290, device=0x1a3dfc8, 
command=command@entry=0xbe9c02c8, specialize=specialize@entry=0) at 
./lib/CL/devices/common.c:158
#12 0xb6dc0e44 in pocl_check_kernel_disk_cache 
(command=command@entry=0xbe9c02c8, specialized=specialized@entry=0) at 
./lib/CL/devices/common.c:958
#13 0xb6dc1262 in pocl_check_kernel_dlhandle_cache (command=0xbe9c02c8, 
initial_refcount=0, specialize=0) at ./lib/CL/devices/common.c:1081
#14 0xb6d993d4 in program_compile_dynamic_wg_binaries 
(program=program@entry=0x1a18350) at ./lib/CL/pocl_build.c:179
#15 0xb6da9f20 in get_binary_sizes (sizes=0xbe9c03d4, program=0x1a18350) at 
./lib/CL/clGetProgramInfo.c:36
#16 POclGetProgramInfo (program=0x1a18350, param_name=4453, 
param_value_size=128, param_value=0xbe9c03d4, param_value_size_ret=0xbe9c03d0) 
at ./lib/CL/clGetProgramInfo.c:115
#17 0x0045a070 in main () at 975931.c:238

I expect pocl built against llvm 11 (experimental) to fail similarily.
pocl built against llvm 9 (testing) passes.

Sylvestre, could you check whether this is an error on the LLVM side
or is POCL using LLVM incorrectly?


Andreas
#define CL_TARGET_OPENCL_VERSION 220

#include 
#include 
#include 
#include 

const char source[] =
"#ifdef DOUBLE_PRECISION\n"
"#ifdef cl_khr_fp64\n"
"#pragma OPENCL EXTENSION cl_khr_fp64 : enable\n"
"#else\n"
"#pragma OPENCL EXTENSION cl_amd_fp64 : enable\n"
"#endif\n"
"#endif\n"
"\n"
"__kernel void Sdot_kernel( __global float *_X, __global float *_Y, __global float *scratchBuff,\n"
"uint N, uint offx, int incx, uint offy, int incy, int doConj )\n"
"{\n"
"__global float *X = _X + offx;\n"
"__global float *Y = _Y + offy;\n"
"float dotP = (float) 0.0;\n"
"\n"
"if ( incx < 0 ) {\n"
"X = X + (N - 1) * abs(incx);\n"
"}\n"
"if ( incy < 0 ) {\n"
"Y = Y + (N - 1) * abs(incy);\n"
"}\n"
"\n"
"int gOffset;\n"
"for( gOffset=(get_global_id(0) * 4); (gOffset + 4 - 1) 0);

  CHECK_CL_ERROR(clGetDeviceIDs(platforms[0], CL_DEVICE_TYPE_ALL, MAX_DEVICES, devices, ));
  TEST_ASSERT(ndevices > 0);

  cl_context context = clCreateContext(NULL, 1, devices, NULL, NULL, );
  CHECK_OPENCL_ERROR_IN("clCreateContext");

  const char * src[] = {source};
  program = clCreateProgramWithSource(context, 1, src, NULL, );
  CHECK_OPENCL_ERROR_IN("clCreateProgramWithSource");

  CHECK_CL_ERROR(clBuildProgram(program, 1, devices, "-g -DINCX_NONUNITY -DINCY_NONUNITY", NULL, NULL));

  CHECK_CL_ERROR(clGetProgramInfo(program, CL_PROGRAM_BINARY_SIZES, sizeof(binsizes), binsizes, ));
  printf("binary size: %zd\n", binsizes[0]);

  CHECK_CL_ERROR(clReleaseProgram(program));

  CHECK_CL_ERROR (clReleaseContext (context));

  printf ("OK\n");

  return EXIT_SUCCESS;
}

Bug#975250: clarify gathering together of copyright information

[Holger Levsen]

On Tue, Dec 01, 2020 at 02:03:59PM -0500, Sam Hartman wrote:
> My rationale is that debian/copyright is a summary, it's not the license
> text in the files.
> I absolutely agree we shouldn't go change people's actual copyright
> notices in the files.

that. and what Bill said.

> As a copyright holder I'd probably be more annoyed at the hyphen instead
> of the n-dash rather than the notice.  But that's  just me.
 
oh dear, you've send me into a small rabbit hole researching the distinctions
between hyphen, dash, hyphen-minus and the minus sign... :) thanks! :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

If secure encryption is outlawed, only criminals will have it.


signature.asc
Description: PGP signature

Bug#932870: marked as pending in lintian

[Paul Wise]

On Tue, 2020-12-01 at 22:15 +, Felix Lechner wrote:

> The new tag resembles, pursuant to the filers request, the existing
> tag testsuite-autopkgtest-missing (which has since been renamed) to
> the extent that it is likewise issued with an 'info' visibility.

This seems to miss part of my request:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932870#17

   In addition I think this superficial-only-tests tag should be of a
   different severity to testsuite-autopkgtest-missing, perhaps raised to
   info or warning level instead of pedantic.

The missing testsuite tag is now at info level, so the superficial
tests tag should be raised to warning level. I'll commit a fix.

   $ grep -hrC20 testsuite-autopkgtest-missing /usr/share/lintian
   Tag: missing-tests-control
   Severity: info
   Check: testsuite
   Renamed-From:
testsuite-autopkgtest-missing
   Explanation: The source package declares the generic Testsuite: 
autopkgtest
field but provides no debian/tests/control file.
.
The control file is not needed when a specialized test suite such as
autopkgtest-pkg-perl is being used.
   See-Also: 
https://salsa.debian.org/ci-team/autopkgtest/tree/master/doc/README.package-tests.rst

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#975373: Upstream patch proposed

[James Cameron]

Upstream has a patch and would like reviewers.

https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/454

-- 
James Cameron
http://quozl.netrek.org/

Bug#976239: qemu-user: emulator crash with minimal test program

[David Given]

Package: qemu-user
Version: 1:5.1+dfsg-4+b2
Severity: normal
Tags: upstream
X-Debbugs-Cc: d...@cowlark.com

I have a test program for the PowerPC which reliably causes qemu-ppc to crash,
apparently on startup. I haven't been able to get it to tell me what it's doing
during the crash. The minimal program is:

---snip---
.text
.global _start
_start:
li 3,0
li 0,1
sc # call _exit()

.section .bss
.byte 0
---snip---

To reproduce, do:

$ powerpc-linux-gnu-as -o test.o test.s
$ powerpc-linux-gnu-ld -o test test.o
$ qemu-ppc ./test
Segmentation fault

I believe this is a bug in qemu as the same binary works absolutely fine on
real hardware. Removing the `.byte 0` line causes the crash to go away.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages qemu-user depends on:
ii  libc6 2.31-4
ii  libcapstone3  4.0.1+really+3.0.5-2+b1
ii  libgcc-s1 10.2.0-16
ii  libglib2.0-0  2.66.2-1
ii  libgnutls30   3.6.15-4
ii  libstdc++610.2.0-16
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages qemu-user recommends:
ii  qemu-user-static [qemu-user-binfmt]  1:5.1+dfsg-4+b2

Versions of packages qemu-user suggests:
ii  sudo  1.9.3p1-1

-- debconf-show failed

Bug#976235: enlightenment: e switches off screen|monitor

[Ross Vandegrift]

On Tue, Dec 01, 2020 at 11:49:54PM +0100, enno wrote:
> Upgraded e, after that e on start complained in a window that I had no screen
> configured to display on--but my 4 screens from prior .e were present.  But
> the complaint persisted, so finally I tried the suggested Settings->Screens--
> but that doesn't exist.  However I remembered there was some Screen config
> somewhere, found that, didn't find anything to configure.  Complaint about
> unconfigured persisted.  So again into the configure-dialog, there is a lot of
> options without explanation or tooltip, f.i. one checkbox choice with
> 0 90 180 270 as choices.  Checked 90 and haven't seen e again since that.

Sounds like you found the right dialog - it is terse.  The options
correspond to xrandr config for your displays.  Quick explanation:

- The drop down in the upper left selects which output to configure.
- The middle pane lists supported modes.
- The upper right (0,90,180,270) sets screen rotation.
- Below that, the On checkbox enables/disables the screen.
- Below that are priority and layout controls.

> Calling enlightenment_start since then just switches off the monitor (on a
> laptop) and .xsession-errors contains some lines that google doesn't come up
> with any solution:

When you checked 90, you enabled 90 degree rotation for one screen.
>From the error, it looks like X or your video driver doesn't like that:

This should clear out all of your screen config, hopefully allowing you
to start E again:
 rm ~/.e/e/config/standard/e_randr*.cfg

Ross

Bug#976225: RFS: reuse/0.11.1-1 [ITP] -- tool for REUSE copyright and license recommendations

[Stephan Lachnit]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "reuse":

 * Package name: reuse
   Version : 0.11.1-1
   Upstream Author : Carmen Bianca Bakker <
carmenbia...@fsfe.org
>
 * URL :
https://reuse.software/
* License : CC-BY-SA-4.0, CC0-1.0, GPL-3.0-or-later
 * Vcs :
https://salsa.debian.org/python-team/packages/reuse
Section : devel

It builds those binary packages:

  reuse - tool for REUSE copyright and license recommendations

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/reuse/
Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/r/reuse/reuse_0.11.1-1.dsc
Changes for the initial release:

 reuse (0.11.1-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #974696)

This package requires python3-boolean (source: boolean.py) and 
python3-license-expression (source: license-expression), which both need a 
sponsor.

Regards,
--
  Stephan Lachnit

Bug#976223: RFS: boolean.py/3.8-1 [ITP] -- small library implementing a boolean algebra

[Stephan Lachnit]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "boolean.py":

 * Package name: boolean.py
   Version : 3.8-1
   Upstream Author : Sebastian Kraemer 
 * URL : https://github.com/bastikr/boolean.py
 * License : BSD-2-Clause
 * Vcs : https://salsa.debian.org/python-team/packages/boolean.py
   Section : python

It builds those binary packages:

  python3-boolean - small library implementing a boolean algebra

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/boolean.py/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/b/boolean.py/boolean.py_3.8-1.dsc

Changes for the initial release:

 boolean.py (3.8-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #976117)

Regards,
--
  Stephan Lachnit

Bug#976224: RFS: license-expression/1.2+ds1-1 [ITP] -- small library to handle license expressions

[Stephan Lachnit]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "license-expression":

 * Package name: license-expression
   Version : 1.2+ds1-1
   Upstream Author : nexB Inc. 
 * URL : https://github.com/nexB/license-expression
 * License : GPL-2.0-or-later, Apache-2.0, public-domain
 * Vcs : 
https://salsa.debian.org/python-team/packages/license-expression
   Section : python

It builds those binary packages:

  python3-license-expression - small library to handle license expressions

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/license-expression/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/l/license-expression/license-expression_1.2+ds1-1.dsc

Changes for the initial release:

 license-expression (1.2+ds1-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #976143)

This package requires python3-boolean (source: boolean.py), which needs a 
sponsor as well.

Regards,
--
  Stephan Lachnit


Sent with ProtonMail Secure Email.

Bug#976227: O: breathe -- Sphinx autodox support for languages with doxygen support

[Melvin Vermeeren]

Hi,

I am the current maintainer of Breathe upstream[1] and also a Debian user 
since a few years after having switched distribution. If I possible I would 
like to also (help?) maintain Breathe in Debian in some way.

Currently I'm not an official Debian maintainer, though I do have a around a 
year experience by now in maintaining an unofficial Debian repository[2], 
mainly for additional backports. Said repo is currently undergoing some rework 
to improve correctness and automation. On Salsa[3] I open up MRs for buster 
bugfixes if I find anything cumbersome as I'm used to the GitLab workflow.

[1] https://github.com/michaeljones/breathe
[2] https://mel.vin/debian/
[3] https://salsa.debian.org/vermeeren

In some form of sponsorship or helping out possible? I could for example do 
some maintaining in a fork on Salsa and submit MRs to the real Salsa repo for 
a final check by someone with proper maintainer permissions. It has been a 
while since I read the specifics of sponsorship etc so I am not entirely sure 
what the options are.

Had a very nice exchange of emails with Chris Knadle, the maintainer of 
Mumble, quite a while ago. Adding in the CC both for general interest and 
perhaps for some ideas. Looking forward to hearing what can be done!

Thanks,

-- 
Melvin Vermeeren
Systems engineer

signature.asc
Description: This is a digitally signed message part.

Bug#976191: texlive-latex-base: Fails to build formats for LaTeX

[Hilmar Preuße]

Am 01.12.2020 um 10:46 teilte Hilmar Preusse mit:

Hi,


we uploaded latest CTAN snapshot to Debian. Now the format for LaTeX fail to 
build:

fmtutil [ERROR]: running `pdftex -ini   -jobname=pdflatex -progname=pdflatex 
-translate-file=cp227.tcx *pdflatex.ini I could solve the issue by installing texlive-latex-recommended, which 
introduces


(/usr/share/texlive/texmf-dist/tex/latex/l3packages/xparse/xparse.ltx
(/usr/share/texlive/texmf-dist/tex/latex/l3packages/xparse/xparse-generic.tex

hille@sid:~ $ sudo apt install texlive-latex-recommended
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  texlive-latex-recommended-doc texlive-luatex texlive-pstricks
The following NEW packages will be installed:
  texlive-latex-recommended
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 14.5 MB of archives.
After this operation, 31.4 MB of additional disk space will be used.
Get:1 http://ftp.de.debian.org/debian unstable/main i386 
texlive-latex-recommended all 2020.20201129-2 [14.5 MB]

Fetched 14.5 MB in 2s (6,379 kB/s)
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Selecting previously unselected package texlive-latex-recommended.
(Reading database ... 147880 files and directories currently installed.)
Preparing to unpack 
.../texlive-latex-recommended_2020.20201129-2_all.deb ...

Unpacking texlive-latex-recommended (2020.20201129-2) ...
Setting up tex-common (6.15) ...
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time... done.
Setting up texlive-latex-recommended (2020.20201129-2) ...
Processing triggers for man-db (2.9.3-2) ...

H.
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#974705: Changes to job handling cause hangs in wait

[Herbert Xu]

On Wed, Dec 02, 2020 at 12:21:52AM +0100, Michael Biebl wrote:
>
> I'll update the timedated test accordingly.
> Incidentally we already have
> https://salsa.debian.org/systemd-team/systemd/-/merge_requests/110

Thanks.

I will make dash not wait for existing children as this is indeed
a change in behaviour which is undesirable.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#974705: Changes to job handling cause hangs in wait

[Michael Biebl]

Am 01.12.20 um 07:56 schrieb Herbert Xu:

On Tue, Dec 01, 2020 at 05:06:18PM +1100, Herbert Xu wrote:


For some reason this is causing the final two tee's to be created
as children of debian/tests/timedated rather than the bash shell.


An alternative to changing the parent is of course to do

wait $MONPID

instead of

wait

I think this makes more sense anyway as otherwise someone could
easily introduce a hang if they unwittingly add a backgrounded
job to this script.


I'll update the timedated test accordingly.
Incidentally we already have
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/110

Bug#976238: release-notes: Please mention that NSS NIS/NIS+ support has been moved to separate packages

[Aurelien Jarno]

Package: release-notes
Severity: normal

Starting with glibc 2.31-4, NSS NIS and NIS+ support has been moved to separate
packages called libnss-nis and libnss-nisplus. glibc initially depended
on those packages, but apt is unable to handle the upgrade, so they are
now only recommended.

On systems using NIS or NIS+, it is therefore recommended to check that
those packages are correctly installed after the upgrade.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#976063: apt-listbugs: [INTL:de] Updated German translation

[Francesco Poli]

On Sun, 29 Nov 2020 09:29:23 +0100 Chris Leick wrote:

[...]
> Hi,
> 
> please find attached the newest German translation.

Hello Chris,
thanks a lot for your contribution!

I have a few questions.
Please take into account that, although I am learning German, my
knowledge is still somewhat basic, so bear with me!


First question
==

#: ../lib/aptlistbugs/logic.rb:66
msgid ""
" -F   : Automatically pin all buggy packages.\n"
msgstr ""
" -F: hängt automatisch alle fehlerhaften Pakete an.\n"


The verb "to pin" is translated as "pinnen" elsewhere.
In order to improve consistency, I changed this into:

msgstr ""
" -F: pinnt automatisch alle fehlerhaften Pakete.\n"

Please speak up, in case I have to revert this change!


Second question
===

#: ../lib/aptlistbugs/logic.rb:699
msgid ""
" r - redisplay bug lists.\n"
msgstr ""
" r- zeigt die Fehlerlisten erneut an.\n"

#: ../lib/aptlistbugs/logic.rb:700
msgid ""
" c - compose bug lists in HTML.\n"
msgstr ""
" c- stellt eine Fehlerliste in HTML zusammen.\n"

#: ../lib/aptlistbugs/logic.rb:702
msgid ""
" w - display bug lists in HTML\n"
" (uses %{prog} as user %{user}).\n"
msgstr ""
" w- zeigt Fehlerlisten in HTML\n"
"(verwendet %{prog} als Anwender %{user}).\n"


Why is "bug lists" translated as "eine Fehlerliste" (singular) in the
second case?
I changed it into the corresponding plural:

msgstr ""
" c- stellt Fehlerlisten in HTML zusammen.\n"

Please speak up, in case I have to revert this change!

Same doubt for:

#: ../lib/aptlistbugs/logic.rb:920
msgid ""
"You can view the bug lists in HTML at the following URI:\n"
msgstr ""
"Sie können die Fehlerliste in HTML unter dem folgenden URI anschauen:\n"


I changed it into:

msgstr ""
"Sie können die Fehlerlisten in HTML unter dem folgenden URI anschauen:\n"

Please speak up, in case I have to revert this change!


Thanks for your time and patience...

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpOG6sooeOAT.pgp
Description: PGP signature

Bug#974065: [DRE-maint] Bug#974065: rails: nocheck builds should not depend on qunit-selenium

[Antonio Terceiro]

On Mon, Nov 09, 2020 at 03:40:15PM +0100, Sven Mueller wrote:
> Package: rails
> Version: 2:6.0.3.4+dfsg-1
> Tags: patch
> 
> Turns out that this isn't needed and pulls in a lot of dependencies if the
> build is done without tests.
> 
> The attached patch moves the start of the redis server (only needed for
> tests) inside the override_dh_auto_test section in debian/rules (I suspect
> that the redis server was also only pulled in via the qunit-selenium
> dependency? - without this move, the resulting build failed). The
> dependency on qunit-selenium is marked as  so it is now only
> pulled in if tests are enabled.
> 
> Please consider merging this. The change is trivial and I don't believe it
> would create any copyright concerns, but just in case a license would
> actually be required, I license this under the Expat license or CC-BY 3.0
> or CC-BY-SA-4.0, the choice of license is left to the receiver of the
> license and should  be fully compatible with the Debian packaging as well
> as upstream (though this only affects the packaging, so I doubt they care).

> diff --git a/debian/control b/debian/control
> index 59d14bfe..3d067e13 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -18,7 +18,7 @@ Build-Depends: debhelper-compat (= 12),
> ruby-byebug,
>  # Ruby packages - from Gemfile
> puma (>= 4.1~),
> -   qunit-selenium,
> +   qunit-selenium ,
> racc (>= 1.4.6),
> rake (>= 11.1),
> ruby-bcrypt (<< 3.2),
> diff --git a/debian/rules b/debian/rules
> index d3747fee..41bfe45a 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -20,17 +20,17 @@ override_dh_clean:
>   debian/stop-redis-server.sh || true
>   
>  override_dh_auto_install:
> - # start redis server for tests
> - debian/start-redis-server.sh
>   # auto install
>   dh_auto_install -O--buildsystem=ruby
> - # kill redis server used for tests
> - debian/stop-redis-server.sh 
>   $(RM) debian/ruby-activesupport/usr/bin/generate_tables
>   $(RM) debian/*/usr/bin/test
>   rmdir debian/*/usr/bin || true
>  
>  override_dh_auto_test:
>  ifeq ($(filter nocheck,$(DEB_BUILD_PROFILES)),)
> + # start redis server for tests
> + debian/start-redis-server.sh
>   dh_auto_test
> + # kill redis server used for tests
> + debian/stop-redis-server.sh 
>  endif

Did you test this on a full build? gem2deb has a limitation/bug that
causes the tests to be executed during the install target, and not the
test one.


signature.asc
Description: PGP signature

Bug#976237: ITP: golang-github-containers-dnsname -- name resolution for containers

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: dnsname
  Version : 1.1.1-1
  Upstream Author : Containers
* URL : https://github.com/containers/dnsname
* License : Apache-2.0
  Programming Lang: Go
  Description : name resolution for containers

 dnsname pluginOverview This plugin sets up the use of dnsmasq on a given
 CNI network so that Pods can resolve each other by name.  When configured,
 the pod and its IP address are added to a network specific hosts file that
 dnsmasq reads in.  Similarly, when a pod is removed from the network,
 it will remove the entry from the hosts file.  Each CNI network will
 have its own dnsmasq instance.
 .
 The dnsname plugin was specifically designed for the Podman
 (https://github.com/containers/podman) container engine.

Podman 2.2 uses this for resolving names to containers in other networks

Bug#976101: systemd: Offline update installation in systemd (via gnome-update) doesn't cleanly unmount filesystem

[Josh Jones]

No worries - I will send you the debug journal at the next package update - or 
if I have time tomorrow I will try to install outdated versions of the packages 
last updated to force it to happen. Whatever is happening is pretty consistent 
for me by the looks of it.

I have just enabled persistent logging.

Josh

On 1 December 2020 22:46:47 GMT+00:00, Michael Biebl  wrote:
>Control: tags -1 unreproducible
>
>Am 01.12.20 um 18:02 schrieb Josh Jones:
>> Sorry which log do you mean by debug journal log? Apologies for my
>> ignorance.
>> 
>> (Incidentally this problem has occured on two out of three offline
>> updates in recent days)
>
>So, I tried this in a test VM.
>The offline update went just fine (see attached journal.txt), so I
>can't 
>reproduce the issue locally and we will need at the very least at 
>journal log.
>
>Michael

Bug#975191: rust-js-sys: FTBFS: dh_auto_test: error: /usr/share/cargo/bin/cargo build returned exit code 101

[Bastian Germann]

Does someone care about this issue? This will impact quite some other 
modules.

Bug#976235: enlightenment: e switches off screen|monitor

[enno]

Package: enlightenment
Version: 0.24.2-5
Severity: important

Dear Maintainer,

Upgraded e, after that e on start complained in a window that I had no screen
configured to display on--but my 4 screens from prior .e were present.  But
the complaint persisted, so finally I tried the suggested Settings->Screens--
but that doesn't exist.  However I remembered there was some Screen config
somewhere, found that, didn't find anything to configure.  Complaint about
unconfigured persisted.  So again into the configure-dialog, there is a lot of
options without explanation or tooltip, f.i. one checkbox choice with
0 90 180 270 as choices.  Checked 90 and haven't seen e again since that.

Calling enlightenment_start since then just switches off the monitor (on a
laptop) and .xsession-errors contains some lines that google doesn't come up
with any solution:

look at 0x1f5e360 
LVDS/000030e4060300140104901f11780243459759578e282150540001010101010101010101010101010101a82f404062842430a060350036ae1019c51f404062842430a060350036ae10190002000a3aff0a3c7d191b337d9d
cmp2 
[LVDS/000030e4060300140104901f11780243459759578e282150540001010101010101010101010101010101a82f404062842430a060350036ae1019c51f404062842430a060350036ae10190002000a3aff0a3c7d191b337d9d]
 == 
[LVDS/000030e4060300140104901f11780243459759578e282150540001010101010101010101010101010101a82f404062842430a060350036ae1019c51f404062842430a060350036ae10190002000a3aff0a3c7d191b337d9d]
BL: set 
[/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-LVDS-1/radeon_bl0]
 -> 1000
WIZARD PAGE: page_010.so
X I/O Error - fatal. Exiting

flwm works--enlightenment is dead.  I suppose there is some unrecognized
dependency problem.

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 5.3.0-3-686-pae (SMP w/4 CPU cores)
Locale: LANG=de_AT@euro, LC_CTYPE=de_AT@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages enlightenment depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-1
ii  dbus-x11 [dbus-session-bus]   1.12.20-1
ii  enlightenment-data0.24.2-5
ii  libasound21.1.8-1
ii  libbluetooth3 5.43-2
ii  libc6 2.30-2
ii  libecore-con1 1.25.1-1
ii  libecore-drm2-1   1.25.1-1
ii  libecore-evas11.25.1-1
ii  libecore-file11.25.1-1
ii  libecore-input1   1.25.1-1
ii  libecore-ipc1 1.25.1-1
ii  libecore-wl2-11.25.1-1
ii  libecore-x1   1.25.1-1
ii  libecore1 1.25.1-1
ii  libedje-bin   1.25.1-1
ii  libedje1  1.25.1-1
ii  libeet1   1.25.1-1
ii  libeeze1  1.25.1-1
ii  libefreet-bin 1.25.1-1
ii  libefreet1a   1.25.1-1
ii  libeina1a 1.25.1-1
ii  libeio1   1.25.1-1
ii  libelementary11.25.1-1
ii  libelput1 1.25.1-1
ii  libemile1 1.25.1-1
ii  libemotion1   1.25.1-1
ii  libevas1  1.25.1-1
ii  libevas1-engines-drm  1.25.1-1
ii  libevas1-engines-wayland  1.25.1-1
ii  libevas1-engines-x1.25.1-1
ii  libpam0g  1.3.1-5
ii  libpulse0 13.0-5
ii  libuuid1  2.36-3+b2
ii  libwayland-client01.18.0-2~exp1.1
ii  libwayland-server01.18.0-2~exp1.1
ii  libxkbcommon0 0.10.0-1

Versions of packages enlightenment recommends:
ii  acpid1:2.0.31-1
ii  bc   1.07.1-2+b1
pn  bluez
ii  eterm [x-terminal-emulator]  0.9.6-6
ii  libevas-loaders  1.25.1-1
pn  packagekit   
ii  udisks2  2.8.1-4
ii  xterm [x-terminal-emulator]  361-1

Versions of packages enlightenment suggests:
ii  gdb  9.1-3
ii  lightdm [x-display-manager]  1.26.0-7

Bug#587553: Any updates on BlueJ packaging?

[Tassia Camoes Araujo]

Hi Ryan,

On 2020-12-01 15:25, Ryan Kavanagh wrote:
> 
> Your email arrived a decade (to the day) after the last time I touched
> this bug report

What a lovely coincidence! I hadn't notice ;-)

> and I haven't touched or thought of BlueJ in nearly as
> long :-) You should definitely feel free to package BlueJ if you are
> interested.
>

Hehe, that was not my original intention, it's been a while that I don't
do any packaging work. Though I could take the task as a challenge,
since
I'd really like to have it in Debian.

I'll take a look at the package provided by upstream. In the meantime,
if anyone else is interested in giving a hand, please jump in!

Cheers,

Tassia.

Bug#976101: systemd: Offline update installation in systemd (via gnome-update) doesn't cleanly unmount filesystem

[Michael Biebl]

Control: tags -1 unreproducible

Am 01.12.20 um 18:02 schrieb Josh Jones:

Sorry which log do you mean by debug journal log? Apologies for my
ignorance.

(Incidentally this problem has occured on two out of three offline
updates in recent days)


So, I tried this in a test VM.
The offline update went just fine (see attached journal.txt), so I can't 
reproduce the issue locally and we will need at the very least at 
journal log.


Michael
-- Logs begin at Tue 2020-12-01 23:38:01 CET, end at Tue 2020-12-01 23:44:25 
CET. --
Dec 01 23:43:38 debian kernel: Linux version 4.19.0-12-amd64 
(debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP 
Debian 4.19.152-1 (2020-10-18)
Dec 01 23:43:38 debian kernel: Command line: 
BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-amd64 
root=UUID=2d376769-5673-4402-bb23-0ca440730377 ro quiet
Dec 01 23:43:38 debian kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 
floating point registers'
Dec 01 23:43:38 debian kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE 
registers'
Dec 01 23:43:38 debian kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX 
registers'
Dec 01 23:43:38 debian kernel: x86/fpu: xstate_offset[2]:  576, 
xstate_sizes[2]:  256
Dec 01 23:43:38 debian kernel: x86/fpu: Enabled xstate features 0x7, context 
size is 832 bytes, using 'standard' format.
Dec 01 23:43:38 debian kernel: BIOS-provided physical RAM map:
Dec 01 23:43:38 debian kernel: BIOS-e820: [mem 
0x-0x0009fbff] usable
Dec 01 23:43:38 debian kernel: BIOS-e820: [mem 
0x0009fc00-0x0009] reserved
Dec 01 23:43:38 debian kernel: BIOS-e820: [mem 
0x000f-0x000f] reserved
Dec 01 23:43:38 debian kernel: BIOS-e820: [mem 
0x0010-0x7ffdbfff] usable
Dec 01 23:43:38 debian kernel: BIOS-e820: [mem 
0x7ffdc000-0x7fff] reserved
Dec 01 23:43:38 debian kernel: BIOS-e820: [mem 
0xb000-0xbfff] reserved
Dec 01 23:43:38 debian kernel: BIOS-e820: [mem 
0xfed1c000-0xfed1] reserved
Dec 01 23:43:38 debian kernel: BIOS-e820: [mem 
0xfeffc000-0xfeff] reserved
Dec 01 23:43:38 debian kernel: BIOS-e820: [mem 
0xfffc-0x] reserved
Dec 01 23:43:38 debian kernel: NX (Execute Disable) protection: active
Dec 01 23:43:38 debian kernel: SMBIOS 2.8 present.
Dec 01 23:43:38 debian kernel: DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
1.14.0-1 04/01/2014
Dec 01 23:43:38 debian kernel: Hypervisor detected: KVM
Dec 01 23:43:38 debian kernel: kvm-clock: Using msrs 4b564d01 and 4b564d00
Dec 01 23:43:38 debian kernel: kvm-clock: cpu 0, msr 16deb001, primary cpu clock
Dec 01 23:43:38 debian kernel: kvm-clock: using sched offset of 349372252767 
cycles
Dec 01 23:43:38 debian kernel: clocksource: kvm-clock: mask: 0x 
max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
Dec 01 23:43:38 debian kernel: tsc: Detected 2790.936 MHz processor
Dec 01 23:43:38 debian kernel: e820: update [mem 0x-0x0fff] usable 
==> reserved
Dec 01 23:43:38 debian kernel: e820: remove [mem 0x000a-0x000f] usable
Dec 01 23:43:38 debian kernel: last_pfn = 0x7ffdc max_arch_pfn = 0x4
Dec 01 23:43:38 debian kernel: MTRR default type: write-back
Dec 01 23:43:38 debian kernel: MTRR fixed ranges enabled:
Dec 01 23:43:38 debian kernel:   0-9 write-back
Dec 01 23:43:38 debian kernel:   A-B uncachable
Dec 01 23:43:38 debian kernel:   C-F write-protect
Dec 01 23:43:38 debian kernel: MTRR variable ranges enabled:
Dec 01 23:43:38 debian kernel:   0 base 00C000 mask FFC000 uncachable
Dec 01 23:43:38 debian kernel:   1 disabled
Dec 01 23:43:38 debian kernel:   2 disabled
Dec 01 23:43:38 debian kernel:   3 disabled
Dec 01 23:43:38 debian kernel:   4 disabled
Dec 01 23:43:38 debian kernel:   5 disabled
Dec 01 23:43:38 debian kernel:   6 disabled
Dec 01 23:43:38 debian kernel:   7 disabled
Dec 01 23:43:38 debian kernel: x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB 
 WP  UC- WT  
Dec 01 23:43:38 debian kernel: found SMP MP-table at [mem 0x000f5cb0-0x000f5cbf]
Dec 01 23:43:38 debian kernel: RAMDISK: [mem 0x33b07000-0x35d7afff]
Dec 01 23:43:38 debian kernel: ACPI: Early table checksum verification disabled
Dec 01 23:43:38 debian kernel: ACPI: RSDP 0x000F5AC0 14 (v00 BOCHS )
Dec 01 23:43:38 debian kernel: ACPI: RSDT 0x7FFE203D 34 (v01 BOCHS  
BXPCRSDT 0001 BXPC 0001)
Dec 01 23:43:38 debian kernel: ACPI: FACP 0x7FFE1E65 F4 (v03 BOCHS  
BXPCFACP 0001 BXPC 0001)
Dec 01 23:43:38 debian kernel: ACPI: DSDT 0x7FFE0040 001E25 (v01 BOCHS  
BXPCDSDT 0001 BXPC 0001)
Dec 01 23:43:38 debian kernel: ACPI: FACS 0x7FFE 40
Dec 01 23:43:38 debian kernel: ACPI: APIC 0x7FFE1F59 80 (v01 BOCHS  
BXPCAPIC 0001 BXPC 0001)
Dec 01 23:43:38 debian kernel: ACPI: MCFG 0x7FFE1FD9 3C (v01 BOCHS  
BXPCMCFG 0001 

Bug#976234: RM: jerry -- ROM; outdated and not maintained

[Dominik Klein]

Package: ftp.debian.org
Severity: normal

Source: jerry
Version: 3.1.0-1
Outdated (version 3.1.0) and no longer maintained. Has build errors (cf. bug
#974583). Latest version 4.0 uses Java and several maven-dependencies, for
which no debian packages exist. For me as the maintainer, this is a too complex
task.

thanks

- Dominik

Bug#973480: transition: llvm-defaults

[Adrian Bunk]

On Wed, Nov 11, 2020 at 04:36:06PM +0200, Adrian Bunk wrote:
> On Sat, Oct 31, 2020 at 03:18:52PM +0100, Sebastian Ramacher wrote:
> >...
> > I'm not sure what .depends ~ "~" is supposed to catch here and it causes
> > a parser failure. So I've merged this ben file with the one from the
> > llvm-defaults 9 transition. Once the tracker is available, please check
> > if that looks sane.
> 
> Please remove the second part from the Affected, these packages are not 
> part of the llvm-defaults transition.

I've rebuilt the 13 bad packages from the ben file below:
ccls OK
clazy OK
codelite OK
faust OK
ghdl FTBFS #976233
ldc OK
libclang-perl OK
qttools-opensource-src OK
sparse OK
ycmd OK
kdevelop OK
qtcreator OK
gnome-builder OK

This is not a normal transition where old package(s) disappear from 
testing since both LLVM 9 and LLVM 11 are already in testing and will 
stay in testing after this transition.

This means rebuilds could be scheduled at any time after an 
llvm-defaults upload without actual conflict with other transitions.

Removal of LLVM 9 and/or LLVM 10 from bullseye are topics unrelated
to this llvm-defaults transition.

cu
Adrian


title = "llvm-defaults 11";
is_affected = .build-depends ~ /\b(libclang|liblldb|llvm)-dev\b/;
is_good = .depends ~ /\b(lib|)(clang|lldb|llvm)1?-?11\b/;
is_bad = .depends ~ /\b(lib|)(clang|lldb|llvm)1?-?9\b/;

Bug#976233: ghdl FTBFS with LLVM 11 as default

[Adrian Bunk]

Source: ghdl
Version: 0.37+dfsg-2
Severity: important
Tags: ftbfs patch
Forwarded: https://github.com/ghdl/ghdl/pull/1451
Control: block 973480 by -1

LLVM 11 will soon be default, and this causes a FTBFS in ghdl.

Manually applying the one-line upstream change linked above
fixes the build.

Bug#976232: ITP: ustreamer -- Lightweight and fast MJPG-HTTP streamer

[Sam Reed]

Package: wnpp
Severity: wishlist
Owner: Sam Reed 

* Package name: ustreamer
  Version : 2.2
  Upstream Author : Maxim Devaev 
* URL : https://pikvm.org/
* License : GPL-3
  Programming Lang: C
  Description : Lightweight and fast MJPG-HTTP streamer

µStreamer is a lightweight and very quick server to stream MJPG
videofrom any V4L2 device to the network. All new browsers have
native support of this video format, as well as most video
players such as mplayer, VLC etc. µStreamer is a part of the
Pi-KVM project designed to stream VGA and HDMI screencast
hardware data with the highest resolution and FPS possible.

ustreamer is used as part of Pi-KVM (a Raspberry Pi based IP
KVM), to stream video to a web browser.

It is intended to get this packaged so it will eventually be
available in Raspberry Pi OS (and other Debian derivatives),
allowing Pi-KVM to be used on those OS rather than using Arch.

I currently use it as part of the Pi-KVM project, and
hopefully when it is packaged, also use it as part of
OctoPrint and the OctoPi OS (version of Raspberry Pi OS).

MJPG-Streamer is alternative software providing the same
function, however it is currently not packaged for Debian
either, though it is available in a snap.

I'm happy to work on packaging/maintaining it in future,
and I believe the upstream Author (Maxim) may be interested
too, but is currently busy with other work, hence me packaging
it.

Bug#540782: Recent switch to Dwarf2 exception handling breaks compatibility with upstream Mingw-64

[Stefan Weil]

Am 01.12.20 um 21:00 schrieb Stephen Kitt:


Hi Stefan,

Thanks for the feedback, one of the reasons I made the change was to see if
it would cause problems for anyone, before the Debian 11 freeze...

The dilemma I’m faced with now is that MSYS2 and Fedora and others have
switched to Dwarf2 for 32-bit Windows targets, and the Rust ecosystem only
supports that. I toyed with the idea of providing both Dwarf2 and SJLJ
toolchains, but the problem there is that I’d really need to use two
different triplets to avoid mix-ups!

Which packages do you use exactly, and where do you get them from?



Hi Stephen,

for the QEMU build I installed these packages:

mingw64-i686-adwaita-icon-theme mingw64-i686-atk1.0 mingw64-i686-bzip2 
mingw64-i686-cairo mingw64-i686-cogl mingw64-i686-curl 
mingw64-i686-expat mingw64-i686-fontconfig mingw64-i686-freetype2 
mingw64-i686-gdk-pixbuf2.0 mingw64-i686-gettext mingw64-i686-glib2.0 
mingw64-i686-gmp mingw64-i686-gnutls mingw64-i686-gtk3 
mingw64-i686-harfbuzz mingw64-i686-hicolor-icon-theme mingw64-i686-icu 
mingw64-i686-jasper mingw64-i686-jbigkit mingw64-i686-libepoxy 
mingw64-i686-libffi mingw64-i686-libgcrypt mingw64-i686-libgnurx 
mingw64-i686-libgpg-error mingw64-i686-libidn2 
mingw64-i686-libjpeg-turbo mingw64-i686-libpng mingw64-i686-libssh2 
mingw64-i686-libtasn1 mingw64-i686-libunistring mingw64-i686-libusb1.0 
mingw64-i686-libxml2 mingw64-i686-lzo2 mingw64-i686-ncurses 
mingw64-i686-nettle mingw64-i686-nghttp2 mingw64-i686-openssl 
mingw64-i686-p11-kit mingw64-i686-pango1.0 mingw64-i686-pcre 
mingw64-i686-pixman mingw64-i686-sdl2 mingw64-i686-tiff 
mingw64-i686-usbredir mingw64-i686-win-iconv mingw64-i686-xz 
mingw64-i686-zlib


Tesseract builds have a slightly different list of packages:

mingw64-i686-atk1.0 mingw64-i686-bzip2 mingw64-i686-cairo 
mingw64-i686-curl mingw64-i686-expat mingw64-i686-fontconfig 
mingw64-i686-freetype2 mingw64-i686-gdk-pixbuf2.0 mingw64-i686-gettext 
mingw64-i686-giflib mingw64-i686-glib2.0 mingw64-i686-gmp 
mingw64-i686-gtk3 mingw64-i686-harfbuzz mingw64-i686-icu 
mingw64-i686-jasper mingw64-i686-jbigkit mingw64-i686-libarchive 
mingw64-i686-libepoxy mingw64-i686-libffi mingw64-i686-libjpeg-turbo 
mingw64-i686-liblept5 mingw64-i686-libpng mingw64-i686-libssh2 
mingw64-i686-libwebp mingw64-i686-libxml2 mingw64-i686-lz4 
mingw64-i686-lzo2 mingw64-i686-nettle mingw64-i686-nghttp2 
mingw64-i686-openjpeg2 mingw64-i686-openssl mingw64-i686-pango1.0 
mingw64-i686-pcre mingw64-i686-pixman mingw64-i686-tiff 
mingw64-i686-win-iconv mingw64-i686-xz mingw64-i686-zlib


All those packages are available from https://qemu.weilnetz.de/debian/ 
(which also describes how those packages were converted from Cygwin to 
Debian packages).


I see the dilemma, but don't have a good solution up to now.

QEMU mainly uses C code without exceptions, so it might be possible to 
build it with all exceptions disabled which could avoid the dilemma 
unless one of the libraries uses exception handling (I am afraid some do).


Would it be possible to build the toolchain with support for two 
different exception handlers with Dwarf2 by default, but SJLJ as a 
compiler and linker option?


Kind regards,

Stefan

Bug#976231: [socklog] Please split socklog binaries package from system configuration

[Michał Mirosław]

Package: socklog
Version: 2.1.0+repack-3
Severity: important

--- Please enter the report below this line. ---

Current unstable package introduces a lot of unneeded dependencies
making it hard to use socklog outside of system-wide use-case (eg. in
trimmed-down chroot). Please split the system configuration part to
separate package, as the program itself doesn't hard-depend on more
than the libc.

This is a regression compared to the 2.1.0-8 version carried over from
ancient times.

--- System information. ---
Architecture: 
Kernel:   Linux 5.9.8+

Debian Release: 10.7
  900 stable-debugdebug.mirrors.debian.org 
  900 stable  security.debian.org 
  900 stable  ftp.pl.debian.org 
  900 stable  dl.winehq.org 
  900 proposed-updates ftp.pl.debian.org 
  850 buster-backports ftp.pl.debian.org 
  800 testing ftp.pl.debian.org 
  700 unstableftp.pl.debian.org 
  600 experimentalftp.pl.debian.org 
  540 oldstable   security.debian.org 
  540 oldstable   ftp.pl.debian.org 
  530 jessie  packagecloud.io 
  500 unstable-debug  debug.mirrors.debian.org 
  500 testing-debug   debug.mirrors.debian.org 
  500 stable  repository.spotify.com 
  500 stable  repo.skype.com 
  500 stable  packages.microsoft.com 
  500 stable  dl.google.com 
  500 proposed-updates-debug debug.mirrors.debian.org 
  100 buster-backports-debug debug.mirrors.debian.org 
1 experimental-debug debug.mirrors.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#973148: [help] Error in hdmf possibly caused by hdf5 issue?

[Andreas Tille]

Control: tags -1 help

Hi,

the build log says:

...
> ==
> FAIL: test_link_h5py_dataset_h5dataio_input 
> (tests.unit.test_io_hdf5_h5tools.H5IOTest)
> --
> Traceback (most recent call last):
>   File 
> "/<>/.pybuild/cpython3_3.9_hdmf/build/tests/unit/test_io_hdf5_h5tools.py",
>  line 688, in test_link_h5py_dataset_h5dataio_input
> self.assertTrue(isinstance(self.f.get('test_softlink', getlink=True), 
> SoftLink))
> AssertionError: False is not true
> 
> ==
> FAIL: test_link_h5py_dataset_input (tests.unit.test_io_hdf5_h5tools.H5IOTest)
> --
> Traceback (most recent call last):
>   File 
> "/<>/.pybuild/cpython3_3.9_hdmf/build/tests/unit/test_io_hdf5_h5tools.py",
>  line 671, in test_link_h5py_dataset_input
> self.assertTrue(isinstance(self.f.get('test_softlink', getlink=True), 
> SoftLink))
> AssertionError: False is not true
> 
> --
> Ran 748 tests in 3.146s
> 
> FAILED (failures=2, skipped=3, expected failures=1)
> E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: cd 
> /<>/.pybuild/cpython3_3.9_hdmf/build; python3.9 -m unittest 
> discover -v 
> dh_auto_test: error: pybuild --test -i python{version} -p "3.9 3.8" returned 
> exit code 13
...

I wonder whether there is a known issue with hdf5 which might cause this
test suite error which otherwise looks pretty clean (also in other hdf5
tests).

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#976230: at command does not start job, if I remove directory, it was launched from

[tyghr]

Package: at
Version: 3.1.23-1

if I launch at job with commands like this, nothing will happen.

#!/bin/bash
mkdir /tmp/123
cd /tmp/123
echo "some_command" | at now + 1 min
cd /tmp
rmdir /tmp/123
exit 0

if I change that script by commenting 6th line. It will work.

#!/bin/bash
mkdir /tmp/123
cd /tmp/123
echo "some_command" | at now + 1 min
cd /tmp
#rmdir /tmp/123
exit 0

It is not obvious, that at uses current working directory. I think it is a
bug.

Tested on last available versions on Buster(at 3.1.23-1), Stretch(at
3.1.20-3), Jessie(at 3.1.16-3)

Bug#963927: [ROM] Please remove predictprotein

[Andreas Tille]

Control: retitle -1 [ROM] Please remove predictprotein
Control: reassign -1 ftp.debian.org

Hi ftpmaster,

the code is not maintained upstream any more and relies on a feature of
Perl that was deprecated several versions ago.  The Debian Med team
consulted Debian Perl team for help but it has turned out that this code
is not maintainable any more.  So please remove this package from Debian.

Kind regards

  Andreas.

PS: @Thorsten: Please mark this bug for the Advent calendar. ;-)

-- 
http://fam-tille.de

Bug#972134: chromium: please, consider moving the package to team-maintainance to properly maintain it

[Moritz Mühlenhoff]

On Tue, Oct 13, 2020 at 12:32:28AM -0300, Rogério Brito wrote:
> Currently, the way that chromium is being maintained is far from the
> standards that we expect in Debian.
> 
> A considerable number of reasonable bug reports (like, for instance the one
> for enabling sharing one's desktop in this age of pandemic and many people
> having to work from home) are not answered or ignored.
> 
> Besides that, there is a skeleton of a version 84 in the repo, but the
> package manager (and https://packages.debian.org/search?keywords=chromium)
> doesn't know about it.
> 
> Going even further, Google Chrome (which I really, really don't want to
> install on my systems) is already at version 86 according to both
> https://en.wikipedia.org/wiki/Google_Chrome_version_history and
> https://chromereleases.googleblog.com/2020/10/stable-channel-update-for-desktop_12.html
> 
> Furthermore, https://tracker.debian.org/pkg/chromium lists, at this moment,
> 100 security issues in sid, buster and bullseye.
> 
> Honestly, if one can't keep up with updates to their packages, at least make
> a call for a group of buddy developers to help (the package tracker doesn't
> show any kind of RFH bug open) or find someone else that is willing to
> maintain the package.

I'm raising this bug to RC severity, we should only include Chromium in Bullseye
if we have more maintainence person power available to make sure it gets updated
in unstable and stable in a timely manner

Michael has been heroically keeping up with this beast of a codebase for years,
but we clearly need a broader base to sustain it going forward.

Cheers,
Moritz

Bug#976183: ITP: golang-github-godbus-dbus -- Native Go bindings for D-Bus

[Sascha Steinbiss]

Hi,

> * Package name : golang-github-godbus-dbus
> Version : 5.0.3-1

I believe this is already in Debian, via golang-dbus [1]

Cheers
Sascha

[1] https://packages.debian.org/source/sid/golang-dbus

Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles

[Clint Adams]

On Mon, Nov 30, 2020 at 10:09:56PM +0100, Antoine Le Gonidec wrote:
> My add-ons installed from Debian repositories are still silently disabled on 
> launch, I have to switch them off then on again to get them working for the 
> current session. And of course start again when I restart Firefox.
> 
> It does not seem the disabling of webrender changed anything for me. Actually 
> I did not check if it was in use before I force-disabled it.

For me it is not enabled by default, and as one would assume,
force-disabling does not help with FF83.

Bug#957206: dh_testroot: error: Package needs targeted root but builder has not provided a gain-root command via ${DEB_GAIN_ROOT_CMD}

[Andrey Rahmatullin]

On Tue, Dec 01, 2020 at 09:08:23PM +0100, Andreas Tille wrote:
> Control: tags -1 pending
> 
> Hi,
> 
> upstream of fis-gtm package[1] confirmed that the build needs some root
> permissions.  Thus I've set
> 
>Rules-Requires-Root: yes
There is no "Rules-Requires-Root: yes", see the Policy.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#975712: Processed: Re: Unifont should be installed by default on Bullseye

[Fabian Greffrath]

control: reassign -1 task-desktop

Am Montag, den 30.11.2020, 13:51 + schrieb Debian Bug Tracking
System:
> Bug #975712 [unifont] Unifont should be installed by default on
> Bullseye

That would be the task-desktop package, I guess.


signature.asc
Description: This is a digitally signed message part

Bug#975250: clarify gathering together of copyright information

[Sam Hartman]

> "Bill" == Bill Allombert  writes:

Bill> Let us be honest with ourselves: what matter for most purpose
Bill> is the position of the ftp-master team that processes the NEW
Bill> queue.  What policy says is secondary.

I absolutely agree we should coordinate appropriately with the ftp team.

Bug#975205: rmlint: diff for NMU version 2.9.0-2.2

[Sudip Mukherjee]

Control: tags 975205 + patch
Control: tags 975205 + pending
--

Dear maintainer,

I've prepared an NMU for rmlint (versioned as 2.9.0-2.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru rmlint-2.9.0/debian/changelog rmlint-2.9.0/debian/changelog
--- rmlint-2.9.0/debian/changelog   2020-08-20 20:43:54.0 +0100
+++ rmlint-2.9.0/debian/changelog   2020-12-01 20:37:43.0 +
@@ -1,3 +1,11 @@
+rmlint (2.9.0-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS for cannot remove directory. (Closes: #975205)
+- Mention explicitly the file and directory to be cleaned.
+
+ -- Sudip Mukherjee   Tue, 01 Dec 2020 20:37:43 
+
+
 rmlint (2.9.0-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru rmlint-2.9.0/debian/clean rmlint-2.9.0/debian/clean
--- rmlint-2.9.0/debian/clean   2020-08-20 19:48:06.0 +0100
+++ rmlint-2.9.0/debian/clean   2020-12-01 20:07:13.0 +
@@ -8,7 +8,8 @@
 rmlint*.json
 rmlint*.sh
 rmlint*.stamp
-.scon*
+.sconsign.dblite
 tests/*.pyc
 tests/*/__pycache__/
 tests/__pycache__/
+.sconf_temp/

Bug#976229: autopkgtest causes stack overflow when lxc fails to start (on s390x)

[Paul Gevers]

Package: autopkgtest
Version: 5.15

Hi,

I started to deploy our s390x host. I had a mistake first in the lxc
configuration, so I had a container that fails to start. When using such
bad container I get this:

root@ci-worker-s390x-01:~# autopkgtest --user debci cacti -- lxc --sudo
autopkgtest-unstable-s390x
autopkgtest [15:26:41]: starting date: 2020-12-01
autopkgtest [15:26:41]: version 5.15

autopkgtest [15:26:41]: host ci-worker-s390x-01; command line:
/usr/bin/autopkgtest --user debci cacti -- lxc --sudo
autopkgtest-unstable-s390x

lxc-start: autopkgtest-lxc-lhrroq: lxccontainer.c:
wait_on_daemonized_start: 849 Received container state "ABORTING"
instead of "RUNNING"
lxc-start: autopkgtest-lxc-lhrroq: tools/lxc_start.c: main: 308 The
container failed to start
lxc-start: autopkgtest-lxc-lhrroq: tools/lxc_start.c: main: 311 To get
more details, run the container in foreground mode
lxc-start: autopkgtest-lxc-lhrroq: tools/lxc_start.c: main: 313
Additional information can be obtained by setting the --logfile and
--logpriority options
: failure: lxc-start failed with exit status 1
Fatal Python error: Cannot recover from stack overflow.
Python runtime state: initialized

Current thread 0x03ffb2ef2710 (most recent call first):
  File "/usr/share/autopkgtest/lib/adtlog.py", line 86 in debug
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 437 in send
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 486 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 452 in expect
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 487 in command
  File "/usr/share/autopkgtest/lib/adt_testbed.py", line 446 in send
  File 

Bug#957206: dh_testroot: error: Package needs targeted root but builder has not provided a gain-root command via ${DEB_GAIN_ROOT_CMD}

[Niels Thykier]

Andreas Tille:
> Control: tags -1 pending
> 
> Hi,
> 
> upstream of fis-gtm package[1] confirmed that the build needs some root
> permissions.  Thus I've set
> 
>Rules-Requires-Root: yes
> 
> When trying to build with pbuilder I get:
> 
>dh_testroot
> dh_testroot: error: Package needs targeted root but builder has not provided 
> a gain-root command via ${DEB_GAIN_ROOT_CMD}
> make: *** [debian/rules:21: binary] Error 25
> 
> 
> How can this be fixed?
> 
> Kind regards
> 
>   Andreas.
> 
> 
> [1] https://salsa.debian.org/med-team/fis-gtm
> 


You want "Rules-Requires-Root: binary-targets".

~Niels

Bug#976228: dlt-daemon: CVE-2020-29394

[Salvatore Bonaccorso]

Source: dlt-daemon
Version: 2.18.5-0.2
Severity: grave
Tags: security upstream
Forwarded: https://github.com/GENIVI/dlt-daemon/issues/274
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2.18.0-1

Hi,

The following vulnerability was published for dlt-daemon.

CVE-2020-29394[0]:
| A buffer overflow in the dlt_filter_load function in dlt_common.c in
| dlt-daemon 2.8.5 (GENIVI Diagnostic Log and Trace) allows arbitrary
| code execution because fscanf is misused (no limit on the number of
| characters to be read in a format argument).


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-29394
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-29394
[1] https://github.com/GENIVI/dlt-daemon/issues/274
[2] https://github.com/GENIVI/dlt-daemon/pull/275

Regards,
Salvatore

Bug#587553: Any updates on BlueJ packaging?

[Ryan Kavanagh]

Hi Tassia,

On Tue, Dec 01, 2020 at 12:14:16PM -0800, Tassia Camoes Araujo wrote:
> Are there any updates on BlueJ packaging?
> Thanks for your work on that!

Your email arrived a decade (to the day) after the last time I touched
this bug report and I haven't touched or thought of BlueJ in nearly as
long :-) You should definitely feel free to package BlueJ if you are
interested.

Best wishes,
Ryan

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#976218: file breaks nagios-plugins-contrib autopkgtest: SSL_CERT UNKNOWN www.debian.org: Unable to fetch a valid certificate issuer certificate.

[Paul Gevers]

reassign 976218 src:nagios-plugins-contrib 27.20200511+1
affects 976218 src:file
retitle 976218 nagios-plugins-contrib needs update of check_ssl_cert
user debian...@lists.debian.org
usertags 976218 - breaks
thanks

Hi Christoph,

Thanks for the analysis.

On 01-12-2020 20:44, Christoph Biedl wrote:
> The file(1) program however now¹ outputs "Certificate, Version=3", and
> the check cannot handle that.

That's more or less what I feared.

> While I could revert that change in file(1) I guess it's way better to
> adjust nagios-plugins-contrib instead.

So, let's reassign appropriately.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#587553: Any updates on BlueJ packaging?

[Tassia Camoes Araujo]

Hi Ryan and Mònica,

I hope this message finds you well ;-)

Are there any updates on BlueJ packaging?
Thanks for your work on that!

Cheers,

Tassia.

Bug#976227: O: breathe -- Sphinx autodox support for languages with doxygen support

[Sebastian Ramacher]

Package: wnpp
Severity: normal
X-Debbugs-Cc: sramac...@debian.org

I no longer use breathe, hence I am orphaning it.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#973672: transition: re2

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 https://release.debian.org/transitions/html/auto-re2.html

On 2020-11-02 18:42:03 -0800, Stefano Rivera wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Public ABI Breakage:
> 
> The implementation of RE2::Arg was changed from preprocessor macros to
> C++ templates. It remains API-compatible, though.
> 
> Reverse Dependencies:
> 
> $ grep ^Status: *.build
> chromium_amd64.build:Status: successful
> clickhouse_amd64.build:Status: attempted
> dnsdist_amd64.build:Status: successful
> effcee_amd64.build:Status: successful
> libphonenumber_amd64.build:Status: successful
> libpog_amd64.build:Status: successful
> libre-engine-re2-perl_amd64.build:Status: successful
> node-re2_amd64.build:Status: successful
> qtwebengine-opensource-src_amd64.build:Status: successful
> re2_20201101+dfsg-1_amd64.build:Status: successful
> re2_20201101+dfsg-1_i386.build:Status: successful
> ruby-re2_amd64.build:Status: successful
> 
> clickhouse FTBFS (#966439) is caused by GCC 10 and unrelated.

Please go ahead with the upload to unstable. I'll wait with the binNMU
of yaramod until python3-defaults migrated.

Cheers

> 
> Ben file:
> 
> title = "re2";
> is_affected = .depends ~ "libre2-8" | .depends ~ "libre2-9";
> is_good = .depends ~ "libre2-9";
> is_bad = .depends ~ "libre2-8";
> 
> The automatically generated ben files are usually correct.
> 
> SR
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#976180: RFS: libzc/0.4.3-1 -- Command line tool for the libzc library

[Niels Thykier]

Niels Thykier:
> Control: tags -1 moreinfo
> 
> Marc Ferland:
>> Package: sponsorship-requests
>> Severity: normal
>>
>> Dear mentors,
>>
>> [...]
>>
>> Changes since the last upload:
>>
>>  libzc (0.4.3-1) unstable; urgency=low
>>  .
>>* New upstream release.
>>* New Dockerfile to simplify debian releases.
>>* Removed zc_file_info_offset() function from API.
>>* Added two new functions to the API: zc_file_info_offset_begin() and
>>  zc_file_info_offset_end().
>>* ABI change libzc4 -> libzc6
>>* Added the possibility to specify the filenames instead of the
>>  offsets in the plaintext cracker in yazc tool.
>>* Added the -S option to the plaintext cracker to print time stats.
>>
>> Regards,
>> --
>>   Marc Ferland
>>
> 
> Hi Marc,
> 
> 
> I found a few issues I would like to see resolved before I will sponsor
> the upload.
> 
> 
> [...]
>
> SONAME bump
> ===
> 
> The library changes SONAME and there is no mention of it.

I take that back, there is a mention in the changelog.  However, the
following part:

> This requires
> a transition if the package has reverse dependencies, but there is no
> comment from you on whether you have started the relevant transition
> procedures or that they are irrelevant because your package has no
> reverse dependencies in unstable and testing.
> 

still stands and still needs an answer.


Apologies for the oversight on my part in my first answer.

~Niels

Bug#957206: dh_testroot: error: Package needs targeted root but builder has not provided a gain-root command via ${DEB_GAIN_ROOT_CMD}

[Andreas Tille]

Control: tags -1 pending

Hi,

upstream of fis-gtm package[1] confirmed that the build needs some root
permissions.  Thus I've set

   Rules-Requires-Root: yes

When trying to build with pbuilder I get:

   dh_testroot
dh_testroot: error: Package needs targeted root but builder has not provided a 
gain-root command via ${DEB_GAIN_ROOT_CMD}
make: *** [debian/rules:21: binary] Error 25


How can this be fixed?

Kind regards

  Andreas.


[1] https://salsa.debian.org/med-team/fis-gtm

-- 
http://fam-tille.de

Bug#540782: Recent switch to Dwarf2 exception handling breaks compatibility with upstream Mingw-64

[Stephen Kitt]

Hi Stefan,

On Tue, 1 Dec 2020 20:24:07 +0100, Stefan Weil  wrote:
> The recent switch from SJLJ exception handling to Dwarf2 breaks the
> compatibility with upstream Mingw-w64 which still sticks to SJLJ:
> https://sourceforge.net/p/mingw-w64/wiki2/Exception%20Handling/.
> 
> It is now no longer possible to use for example the Mingw-w64 cross packages
> from Cygwin for cross builds targeting 32 bit Windows on latest Debian.
> That's how I generated the Windows binaries for QEMU and Tesseract during
> the last years.

Thanks for the feedback, one of the reasons I made the change was to see if
it would cause problems for anyone, before the Debian 11 freeze...

The dilemma I’m faced with now is that MSYS2 and Fedora and others have
switched to Dwarf2 for 32-bit Windows targets, and the Rust ecosystem only
supports that. I toyed with the idea of providing both Dwarf2 and SJLJ
toolchains, but the problem there is that I’d really need to use two
different triplets to avoid mix-ups!

Which packages do you use exactly, and where do you get them from?

Regards,

Stephen


pgp_oWxQLX7X7.pgp
Description: OpenPGP digital signature

Bug#972085: gtkam: Build-Depends on libexif-gtk, which is moving to GTK3

[Adrian Bunk]

Control: forcemerge 967485 -1

On Wed, Nov 18, 2020 at 12:09:30AM +1100, Hugh McMaster wrote:
> Hi Adrian,

Hi Hugh,

> On Tue, 17 Nov 2020 at 03:53, Adrian Bunk wrote:
> 
> > What is the point of moving libexif-gtk to GTK3 when the only package
> > using it does not support it?
> >
> > This sounds like a mistake that should be reverted.
> 
> 
> I already have. When I realised gtkam was an issue, I updated libexif-gtk
> to build both GTK 2 and 3.

thanks, and sorry that I missed that.

> Unfortunately, gtkam is dead upstream, so nothing will change there.
> However, several good alternatives exist.
> 
> The Debian QA team is also reluctant to remove gtkam due to its popcon
> installation numbers.
> 
> That said, as libexif-gtk will have GTK 2 support for some time, this bug
> severity can probably be downgraded.

I am merging this with the "depends on deprecated GTK 2" bug for gtkam.

> If smcv does manage to remove GTK 2 during the next development cycle,
> however, we will need to revisit this bug.

>From his "depends on deprecated GTK 2" bugs:

  GTK 2 is used by some important productivity applications like GIMP, 
  and has also historically been a popular UI toolkit for proprietary 
  software that we can't change, so perhaps removing GTK 2 from Debian 
  will never be feasible.


cu
Adrian

Bug#976218: file breaks nagios-plugins-contrib autopkgtest: SSL_CERT UNKNOWN www.debian.org: Unable to fetch a valid certificate issuer certificate.

[Christoph Biedl]

Paul Gevers wrote...

> With a recent upload of file the autopkgtest of nagios-plugins-contrib
> fails in testing when that autopkgtest is run with the binary packages
> of file from unstable. It passes when run with only packages from
> testing. In tabular form:

> autopkgtest [14:13:17]: test command7:
> /usr/lib/nagios/plugins/check_ssl_cert -H www.debian.org
> autopkgtest [14:13:17]: test command7: [---
> SSL_CERT UNKNOWN www.debian.org: Unable to fetch a valid certificate
> issuer certificate.
> autopkgtest [14:13:18]: test command7: ---]

Okay, that error message was a bit misleading.

Full story: The test downloads the certificate from

http://cert.int-x3.letsencrypt.org/

and runs file(1) on the result. And either something of "ASCII",
"PEM", or plain "data".

The file(1) program however now¹ outputs "Certificate, Version=3", and
the check cannot handle that.

While I could revert that change in file(1) I guess it's way better to
adjust nagios-plugins-contrib instead.

Christoph

¹ https://github.com/file/file/commit/FILE5_38-41-g1956e3ad


signature.asc
Description: PGP signature

Bug#976226: RFP: arqiver - a simple Qt5 archive manager

[программист некто]

Package: wnpp
Severity: wishlist

Package name : arqiver
Version :  0.6.1
URL :  https://github.com/tsujan/Arqiver
License : GPL-3.0

Arqiver (by Pedram Pourang, a.k.a. Tsu Jan tsujan2...@gmail.com) is a simple 
Qt5 archive manager as a front-end for libarchive (bsdtar), gzip and 7z.
Arqiver can extract, create and edit archives that are supported by its 
back-ends. It can open archives by drag-and-drop. Its listed items can be 
viewed separately or dragged and dropped into appropriate applications. With 
7z, it also supports password protection.

Bug#975250: clarify gathering together of copyright information

[Bill Allombert]

On Tue, Dec 01, 2020 at 02:03:59PM -0500, Sam Hartman wrote: > > "Russ" == 
Russ Allbery  writes:
> 
> Russ> That said, I tend to be hyper-conservative and nit-picky about
> Russ> things like this, accurately representing copyright years
> Russ> isn't in my top thousand things I want people to work on in
> Russ> Debian, and I'm highly dubious that it will ever matter or
> Russ> anyone will ever care.  So I'm very open to being told I'm
> Russ> being much too cautious.
> 
> On the compromise front, how would people feel about leaving the gap
> years question ambiguous in policy?

Let us be honest with ourselves: what matter for most purpose
is the position of the ftp-master team that processes the NEW queue.
What policy says is secondary.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#976157: thunderbird: Thunderbird refuses to decrypt inline PGP message

[Carsten Schoenert]

Hello Jeff,

Am 01.12.20 um 20:09 schrieb Jeff:
...
>> You are aware that inline PGP is incompatible while using with HTML emails?
> 
> Other people send me inline PGP. I would like to be able to read what 
> they have written.

yes, of course. But remember my sentence above your answer. If the
sender is using inline PGP with an HTML message the behavior is
undefined, in the end Thunderbird can't decrypt the message and there is
nothing we can do about this.

You need to have a look at the source of the email, Ctrl + U will show
you the message at source level.

Look for 'Content-Type', if you find a line

  Content-Type: text/plain; charset=..

than the message is text only. If you see

  Content-Type: multipart/mixed; (or similar)

than you look at a HTML message.

In my eyes best is to convince the sender to not use inline PGP in the
long run.

If the sender is using MS Exchange you have likely no chance to get a
RFC correct message here.

The following bug from Bugzilla is marked as fixed in 78.5.0, but I
still can't open the attached encrypted example messages.

https://bugzilla.mozilla.org/show_bug.cgi?id=1672851

Without further information what the message is build of you have
problems with we can't do any useful error detection.
I expect you will have the same problems if you use an upstream version
of Thunderbird from Mozilla. If yes your bug report should go into
Bugzilla so MZLNA have a chance to fix the underlying issue (if possible).


> I am happy sending with PGP/MIME.
Fine, then your setup is correct and futurproof.

-- 
Regards
Carsten

Bug#540782: Recent switch to Dwarf2 exception handling breaks compatibility with upstream Mingw-64

[Stefan Weil]

The recent switch from SJLJ exception handling to Dwarf2 breaks the 
compatibility
with upstream Mingw-w64 which still sticks to SJLJ:
https://sourceforge.net/p/mingw-w64/wiki2/Exception%20Handling/.

It is now no longer possible to use for example the Mingw-w64 cross packages
from Cygwin for cross builds targeting 32 bit Windows on latest Debian.
That's how I generated the Windows binaries for QEMU and Tesseract during
the last years.

Regards,
Stefan W.

Bug#971570: julia: libgit2 1.0 transition

[Ximin Luo]

Package: julia
Version: 1.5.3+dfsg-2
Followup-For: Bug #971570
Control: severity -1 serious

Dear Maintainer,

It has been several weeks since filing this and we want to proceed with the
transition. Therefore I am bumping this bug to RC severity. If no action is
taken it will be removed from Debian Testing within several weeks, allowing
us to proceed with the transition.

Best, 
Ximin

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable'), (300, 'unstable'), (100, 'experimental'), 
(1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages julia depends on:
pn  julia-common  
ii  libc6 2.31-4
ii  libcurl3-gnutls   7.72.0-1
pn  libdsfmt-19937-1  
ii  libgcc-s1 10.2.0-19
ii  libgfortran5  10.2.0-19
ii  libgit2-280.28.5+dfsg.1-1
ii  libgmp10  2:6.2.1+dfsg-1
pn  libjulia1 
pn  libllvm10 
ii  libmbedcrypto32.16.5-1
ii  libmbedtls12  2.16.5-1
ii  libmbedx509-0 2.16.5-1
ii  libmpfr6  4.1.0-3
pn  libopenlibm3  
ii  libpcre2-8-0  10.34-7
ii  libquadmath0  10.2.0-19
ii  libssh2-1 1.8.0-2.1
ii  libunwind81.3.2-2
ii  libutf8proc2  2.5.0-1

Versions of packages julia recommends:
ii  git  1:2.29.2-1
ii  openssl  1.1.1h-1

Versions of packages julia suggests:
pn  ess
pn  julia-doc  
pn  vim-julia  

Bug#971568: geany-plugins: libgit2 1.0 transition

[Ximin Luo]

Package: geany-plugins
Version: 1.37+dfsg-3
Followup-For: Bug #971568
Control: severity -1 serious

Dear Maintainer,

It has been several weeks since filing this and we want to proceed with the
transition. Therefore I am bumping this bug to RC severity. If no action is
taken it will be removed from Debian Testing within several weeks, allowing
us to proceed with the transition.

Best, 
Ximin

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable'), (300, 'unstable'), (100, 'experimental'), 
(1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages geany-plugins depends on:
pn  geany-plugin-addons  
pn  geany-plugin-autoclose   
pn  geany-plugin-automark
pn  geany-plugin-codenav 
pn  geany-plugin-commander   
pn  geany-plugin-ctags   
pn  geany-plugin-debugger
pn  geany-plugin-defineformat
pn  geany-plugin-doc 
pn  geany-plugin-extrasel
pn  geany-plugin-gendoc  
pn  geany-plugin-geniuspaste 
pn  geany-plugin-git-changebar   
pn  geany-plugin-insertnum   
pn  geany-plugin-keyrecord   
pn  geany-plugin-latex   
pn  geany-plugin-lineoperations  
pn  geany-plugin-lipsum  
pn  geany-plugin-lua 
pn  geany-plugin-macro   
pn  geany-plugin-miniscript  
pn  geany-plugin-numberedbookmarks   
pn  geany-plugin-overview
pn  geany-plugin-pairtaghighlighter  
pn  geany-plugin-pg  
pn  geany-plugin-pohelper
pn  geany-plugin-prettyprinter   
pn  geany-plugin-prj 
pn  geany-plugin-projectorganizer
pn  geany-plugin-sendmail
pn  geany-plugin-shiftcolumn 
pn  geany-plugin-spellcheck  
pn  geany-plugin-tableconvert
pn  geany-plugin-treebrowser 
pn  geany-plugin-updatechecker   
pn  geany-plugin-vc  
pn  geany-plugin-vimode  
pn  geany-plugin-workbench   
pn  geany-plugin-xmlsnippets 

geany-plugins recommends no packages.

geany-plugins suggests no packages.

Bug#971563: libgit2-glib: libgit2 1.0 transition

[Ximin Luo]

Source: libgit2-glib
Followup-For: Bug #971563
Control: severity -1 serious

Dear Maintainer,

It has been several weeks since filing this and we want to proceed with the
transition. Therefore I am bumping this bug to RC severity. If no action is
taken it will be removed from Debian Testing within several weeks, allowing
us to proceed with the transition.

Best, 
Ximin

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable'), (300, 'unstable'), (100, 'experimental'), 
(1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#971565: ruby-rugged: libgit2 1.0 transition

[Ximin Luo]

Package: ruby-rugged
Followup-For: Bug #971565
Control: severity -1 serious

Dear Maintainer,

It has been several weeks since filing this and we want to proceed with the
transition. Therefore I am bumping this bug to RC severity. If no action is
taken it will be removed from Debian Testing within several weeks, allowing
us to proceed with the transition.

Best, 
Ximin

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable'), (300, 'unstable'), (100, 'experimental'), 
(1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#971564: python-pygit2: libgit2 1.0 transition

[Ximin Luo]

Source: python-pygit2
Followup-For: Bug #971564
Control: severity -1 serious

Dear Maintainer,

It has been several weeks since filing this and we want to proceed with the
transition. Therefore I am bumping this bug to RC severity. If no action is
taken it will be removed from Debian Testing within several weeks, allowing
us to proceed with the transition.

Best,
Ximin

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable'), (300, 'unstable'), (100, 'experimental'), 
(1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#971562: gall: libgit2 1.0 transition

[Ximin Luo]

Source: gall
Followup-For: Bug #971562
Control: severity -1 serious

Dear Maintainer,

It has been several weeks since filing this and we want to proceed with the
transition. Therefore I am bumping this bug to RC severity. If no action is
taken it will be removed from Debian Testing within several weeks, allowing
us to proceed with the transition.

Best, 
Ximin

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable'), (300, 'unstable'), (100, 'experimental'), 
(1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#976157: thunderbird: Thunderbird refuses to decrypt inline PGP message

[Jeff]

Hi Carsten,

On 30/11/2020 19:42, Carsten Schoenert wrote:

is there a particular reason why you want to use inline PGP? This is an
old technique that shouldn't get used any longer, it's a dead horse.
PGP/MIME is the thing users should use instead. Thunderbird uses
PGP/MIME by default and I currently see no way to enforce inline PGP for
sending encrypted emails with Thunderbird?

You are aware that inline PGP is incompatible while using with HTML emails?


Other people send me inline PGP. I would like to be able to read what 
they have written.


I am happy sending with PGP/MIME.

Regards

Jeff



OpenPGP_signature
Description: OpenPGP digital signature

Bug#975250: clarify gathering together of copyright information

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> That said, I tend to be hyper-conservative and nit-picky about
Russ> things like this, accurately representing copyright years
Russ> isn't in my top thousand things I want people to work on in
Russ> Debian, and I'm highly dubious that it will ever matter or
Russ> anyone will ever care.  So I'm very open to being told I'm
Russ> being much too cautious.

My rationale is that debian/copyright is a summary, it's not the license
text in the files.
I absolutely agree we shouldn't go change people's actual copyright
notices in the files.

And, I'm fairly convinced that it can never hurt us.  I mean if someone
came along and actually bothered to send us a legal letter, or even a
strongly worded bug report as a copyright holder, we'd go  use their
preferred notice.
What sort of damage are they going to be able to show because we listed
2009-2020 instead of 2009, 2012, 2019-2020.

As a copyright holder I'd probably be more annoyed at the hyphen instead
of the n-dash rather than the notice.  But that's  just me.

But I totally understand we're well into bikeshedding here.

On the compromise front, how would people feel about leaving the gap
years question ambiguous in policy?
That is, we clearly agree you can combine years across files, our
question is whether you can insert years that appear in no file.
Could we just sidestep the issue and leave that ambiguous?

Bug#976222: RFS: fasttracker2/1.41+ds-1 -- Fasttracker II clone

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "fasttracker2":

 * Package name: fasttracker2
   Version : 1.41+ds-1
   Upstream Author : Olav "8bitbubsy" Sørensen 
 * URL : https://16-bits.org/ft2.php
 * License : BSD-3-clause, CC-BY-NC-SA-4.0, MIT
 * Vcs : 
https://salsa.debian.org/multimedia-team/fasttracker2

   Section : non-free/sound

It builds those binary packages:

  fasttracker2 - Fasttracker II clone

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/fasttracker2/

Alternatively, one can download the package with dget using this 
command:


  dget -x 
https://mentors.debian.net/debian/pool/non-free/f/fasttracker2/fasttracker2_1.41+ds-1.dsc


Changes since the last upload:

 fasttracker2 (1.41+ds-1) unstable; urgency=medium
 .
   * New upstream version.
   * d/copyright:
 - set Upstream-Contact, fix Upstream-Name.
 - update years.
   * Bump debhelper version to 13, drop d/compat.
   * d/upstream/metadata: added.
   * d/control: added Rules-Requires-Root.

Regards,
--
  Gürkan Myczko

Bug#976221: blender: gpu hang when working

[Anton]

Package: blender
Version: 2.83.5+dfsg-4+b1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: toha...@gmail.com

Dear Maintainer,

When I use this program, after a while the computer completely freezes, but the 
mouse works

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages blender depends on:
ii  blender-data  2.83.5+dfsg-4
ii  fonts-dejavu  2.37-2
ii  libavcodec58  7:4.3.1-5
ii  libavdevice58 7:4.3.1-5
ii  libavformat58 7:4.3.1-5
ii  libavutil56   7:4.3.1-5
ii  libboost-locale1.71.0 1.71.0-7+b1
ii  libc6 2.31-4
ii  libfftw3-double3  3.3.8-2
ii  libfreetype6  2.10.2+dfsg-4
ii  libgcc-s1 10.2.0-19
ii  libgl11.3.2-1
ii  libglew2.12.1.0-4+b1
ii  libgomp1  10.2.0-19
ii  libilmbase25  2.5.3-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.16~dfsg-1
ii  libjemalloc2  5.2.1-1
ii  libjpeg62-turbo   1:2.0.5-1.1
ii  libopenal11:1.19.1-2
ii  libopencolorio1v5 1.1.1~dfsg0-6+b2
ii  libopenexr25  2.5.3-2
ii  libopenimageio2.2 2.2.7.0+dfsg-2+b1
ii  libopenjp2-7  2.3.1-1
ii  libopenvdb7.1 7.1.0-2+b1
ii  libosdcpu3.4.33.4.3-3
ii  libosdgpu3.4.33.4.3-3
ii  libpcre3  2:8.39-13
ii  libpng16-16   1.6.37-3
ii  libpython3.9  3.9.1~rc1-2
ii  libsdl2-2.0-0 2.0.12+dfsg1-4
ii  libsndfile1   1.0.28-8
ii  libspnav0 0.2.3-1+b2
ii  libstdc++610.2.0-19
ii  libswscale5   7:4.3.1-5
ii  libtbb2   2020.3-1
ii  libtiff5  4.1.0+git191117-2
ii  libx11-6  2:1.6.12-1
ii  libxfixes31:5.0.3-2
ii  libxi62:1.7.10-1
ii  libxml2   2.9.10+dfsg-6.2
ii  libxrender1   1:0.9.10-1
ii  libxxf86vm1   1:1.1.4-1+b2
ii  zlib1g1:1.2.11.dfsg-2

blender recommends no packages.

blender suggests no packages.

-- no debconf information

Bug#976220: RM: todo.txt-cli -- ROM; Duplicate package

[David Steele]

Package: ftp.debian.org
Severity: normal
Control: affects -1 todo.txt-cli
thanks

Please remove the package "todo.txt-cli" from "unstable". I am the
maintainer.

It turns out that the package is a duplicate of the existing "todotxt-cli".

I will work with the other maintainer to have todotxt-cli provide the
virtual todo.txt.



signature.asc
Description: OpenPGP digital signature

Bug#975250: clarify gathering together of copyright information

[Russ Allbery]

Guillem Jover  writes:

> Personally I see a big distinction between someone doing it for their
> own copyright claims, and doing that for someone else's.

Yeah, this is where I'm at too.  It feels weird, and I'm not sure it's
technically compliant with the license requirement to preserve the
copyright notice for those licenses that have it.

That said, I tend to be hyper-conservative and nit-picky about things like
this, accurately representing copyright years isn't in my top thousand
things I want people to work on in Debian, and I'm highly dubious that it
will ever matter or anyone will ever care.  So I'm very open to being told
I'm being much too cautious.

> AFAIUI when and what you have done before publication does not count
> when it comes to copyright, only the publication date does.

Yes, this is also my understanding, with the caveat that I only have read
the US law in any detail and I don't know to what extent it varies.  (I
know Berne mostly standardizes copyright, but mostly isn't entirely and
there are countries with fairly significant differences, such as moral
rights.  I have no idea how universal the exact semantics of copyright
notices are under Berne.)

Here's the circular from the US Copyright Office on notices, for whatever
it's worth:

https://www.copyright.gov/circs/circ03.pdf

-- 
Russ Allbery (r...@debian.org)  

Bug#935081: No Intel sound

[Elimar Riesebieter]

* Karsten  [2020-12-01 18:03 +0100]:

> Sorry for the really late answer, but there was no email notification for the 
> answer on this bug.
> 
> > What tells 'dpkg -l | grep timidity' ?
> 
> ii  timidity  2.14.0-8
>  amd64Software sound renderer (MIDI sequencer, MOD player)
> ii  timidity-daemon   2.14.0-8
>  all  runs TiMidity++ as a system-wide MIDI sequencer
> 

What happens if you stop timidity daemon:

# systemctl stop timidity

?

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901148

Elimar
-- 
  The path to source is always uphill!
-unknown-

Bug#976219: zsh uninstallable due to partial oldstable security update

[Markus Koschany]

Hello,

zsh 5.3.1-4+deb9u4 was sucessfully uploaded to stretch-security thirteen hours
ago but it still remains in status "uploaded" for all supported architectures
except arch all. Who can "install" the packages into the archive or is another
upload necessary?

Regards,

Markus





signature.asc
Description: This is a digitally signed message part

Bug#939548: dsdp: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> [..]

Friendly ping on this?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#898912: telepathy-gabble: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> [..]

Friendly ping on this?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#918375: Info received (dockerd segfaults can be repeated)

[Shengjing Zhu]

Sadly I see it in my log too. So after searching a bit, I find this

https://github.com/moby/libnetwork/pull/2581

So it's indeed caused by golang-github-armon-go-radix-dev 1.0.0

And docker maintainer has proposed a patch to go-radix,
https://github.com/armon/go-radix/pull/14
But reading from the issue, it seems docker just implemented in the wrong way.

So I suggest vendoring the old go-radix...

On Mon, Sep 16, 2019 at 1:53 PM Arnaud Rebillout
 wrote:
>
>
> From: Vincent Smeets 
>
> Using journalctl, I see the following error:
>
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x564a9d3a2158]
> goroutine 439 [running]:
> github.com/armon/go-radix.recursiveWalk(0x0, 0xc4212bddb8, 0xc4212bdc00)
> /build/docker.io-18.06.1+dfsg1/.gopath/src/github.com/armon/go-radix/radix.go:477
>  +0x28
>
>
> Hans, do you also see the same logs in the journal? (trying to be sure it's 
> the same issue)
>
> docker-ce builds against armon/go-radix 
> e39d623f12e8e41c7b5529e9a9dd67a1e2261f80, Jan 2015 [1]
>
> docker.io builds against armon/go-radix v1.0, Aug 2018 [2], as you can see 
> with:
>
>   $ rmadison golang-github-armon-go-radix-dev
>   golang-github-armon-go-radix-dev | 1.0.0-1 | stable 
> | all
>   golang-github-armon-go-radix-dev | 1.0.0-1 | unstable   
> | all
>
> That could be the issue. Now, I don't know if you hit a bug in go-radix v1.0, 
> or if you hit an incompatibility between docker and the version v1.0 of 
> go-radix.


-- 
Shengjing Zhu