Bug#950319: libreoffice: filename replacements in mime entries for mailcap must not be quoted within the given command
Hi, Am 17.12.20 um 00:48 schrieb Marriott NZ: > Unfortunately no progress yet on #928037, but I wanted to add here some info > from related bug reports. > > 1) There is a Lintian test for this specific problem: > https://lintian.debian.org/tags/quoted-placeholder-in-mailcap-entry.html > Package libreoffice and 40 more, currently trigger the warning. > The test was introduced in Lintian 2.42.0, 19 Dec 2019. > The bug report requesting the test dates back to 17 Feb 1999: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=33486 I know and saw that one, and as long as there isn't a *definitive* answer am continuing what I am doing already: ignoring it. Or is lintians tag is a distro-wide decision? I don't take that for a given since they introduce bogus tags all the time .oO ( "breakout-link" ) > 2) The problem has already been discussed in old bugs, usually reaching the > conclusion that %-escapes should *not* be quoted in the rules: *usually*? > Unfortunately they decided not to document anything because "I would like to > avoid divergence with other platforms": > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=90483#30 Fair point, IMHO. > As a result, many years later, every piece of Debian concerning mailcap is > still a vector for arbitrary command execution, while package maintainers > have no way of knowing what to do, and bug reports keep resurrecting like > zombies (my #928037 is a duplicate of 10yo #90483). As we see here, too. > 3) Thunderbird doesn't use the %-expansion in the rules at all. > The parsing function extracts what it thinks is the "executable name" and > returns just that. > > https://hg.mozilla.org/mozilla-central/file/661f0d8ae4c44db58e668c831b555dbc038b77d0/uriloader/exthandler/unix/nsOSHelperAppService.cpp > > From function UnescapeCommand: > "UnescapeCommand really needs some work -- it should actually do some > unescaping" > From function GetHandlerAndDescriptionFromMailcapFile: > // XXX ugly hack. Just grab the executable name > ... > // XXX End ugly hack > > I don't know about Evolution. > That would be important info - and please don't forget mutt et al. Regards, Rene
Bug#968181: v3d.ko for RPi4
Hi Lucas, This is in response to your message https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968181#14 >B/ RPI4 support in the kernel v3d driver >(B) requires less work, so should come next quite quickly. I tried loading v3d.ko to the vanilla 5.10.1 kernel, but doing so did not bring /dev/dri/render*, which appears and enables GPU acceleration on Ubuntu kernel for RPi4. I reported it to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977441#27 Bringing GPU acceleration to Debian kernel seems to need some work. On the other hand, I also have the garbled screen on my 4K HDMI display as you wrote at http://lists.infradead.org/pipermail/linux-rpi-kernel/2020-November/007894.html Best regards, Ryutaroh Matsumoto
Bug#977582: ITP:deepin-compressor -- lightweight archive manager of DDE
Package:wnpp Severity: wishlist Owner: Tu Qinggang X-Debbugs-Cc: debian-de...@lists.debian.org * Package name : deepin-compressor Version : 5.8.0.14 Upstream Author : Deepin Technology Co, Ltd. * URL : https://github.com/linuxdeepin/deepin-compressor License : GPL-3.0 Programming Lang: C++ Description : lightweight archive manager of DDE deepin-compressor is a fast and lightweight application. this package is designed for creating and extracting archives. This package is a part of DDE (deepin desktop environment). I intend to maintaining this.
Bug#977578: python3-opencv: Incomplete dependency on libcharls2
Control: tags -1 +moreinfo Hi, I'm confused. On Wed, 2020-12-16 at 19:42 -0800, Dima Kogan wrote: > Hi. I just upgraded my python opencv bindings on Debian/sid: > apt install python3-opencv [...] > I had libcharls2=2.0.0+dfsg-1 (the current stable release). It called [...] > libcharls2 to the current Debian/sid version fixed the problem. A package in sid is built against sid, why is it expected to work with a package in stable? And as described, this problem does not exist when libcharls2/sid is correctly installed. What should I fix?
Bug#977581: ITP: deepin-wallpapers -- DDE wallpapers
Package: wnpp Severity: wishlist Owner: Hu Feng X-Debbugs-Cc: debian-de...@lists.debian.org * Package name : deepin-wallpapers Version : 1.6.14 Upstream Author : amazingfate * URL : https://github.com/linuxdeepin/deepin-wallpapers License : GPL-3+, CC-BY-NC 3.0, CC-BY-SA 3.0 Programming Lang: Makefile Description : DDE wallpapers When users are ready to set their own desktop background, Deepin Wallpaper provides many beautiful background pictures for users to choose. . It is part of Deepin software and DDE (Deepin Desktop Environment). I intend to co-maintain this package inside pkg-deepin group.
Bug#976102: a2ps 32-bit segfaults on startup
On 12/16/20 6:24 AM, Bernhard Übelacker wrote: Am 15.12.20 um 23:00 schrieb Mack Stanley: Dear Bernhard, Thanks so much for your interest and your message. I very recently realized that my bug report is in error and hoped that I would be able to correct or withdraw it before troubling anyone. Here is how to reproduce the segfault I observed (in wither 32 or 64 bit debian a2ps): Near the top of /etc/a2ps-site.cfg comment out one or both of the lines _ Options: --encoding=latin1 Options: --medium=libpaper _ Then just execute a2ps The result will be a crash with simply Segmentation Fault --- I am very sorry to have filed a false bug report. I had tried two 32 bit installations and one 64 bit. Evidently I made the same mistake in both 32 bit installations: I must have installed with an old Fedora a2ps-site.cfg already in /etc/ , which the Debian installation politely refused to overwrite. The default Fedora a2ps-site.cfg has those two lines as #Options: --encoding=latin1 Options: --medium=_glibc After removing "#" from the first line, the debian build a2ps complains helpfully about the second line. But with the "#" it just segfaults. I am sorry it took me so long to find this mistake. It wasn't till I built 32 bit a2ps from the GNU source that I saw the problem (http://ftp.gnu.org/gnu/a2ps/a2ps-4.14.tar.gz./configure --prefix=/usr --with-gnu-gettext --with-medium=letter ). It would be nice if a2ps itself had been more forthcoming about my mistake rather than segfaulting. But it was just that---my mistake. Again, my apologies for wasting your time and my thanks for your interest. Best regards, Mack Hello Mack, no problem, with these great details I could collect these backtraces: # With: #Options: --encoding=latin1 (gdb) bt #0 __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:50 #1 0x0050bfcc in strlower (string=0x0) at routines.c:95 #2 0x005096cd in get_encoding_by_alias (job=0x57bc50, alias=0x0) at encoding.c:1207 #3 0x0050aa50 in a2ps_job_finalize (job=0x57bc50) at jobs.c:305 #4 0x004ef980 in main (argc=, argv=out>) at main.c:1025 (gdb) # With: #Options: --medium=libpaper (gdb) bt #0 __strcasecmp_l_sse4_2 () at ../sysdeps/i386/i686/multiarch/strcmp-sse4.S:229 #1 0x0050e22a in a2ps_get_medium (job=0xb1ec50, name=0x0) at media.c:164 #2 0x0050ea6c in a2ps_job_finalize (job=0xb1ec50) at jobs.c:312 #3 0x004f3980 in main (argc=, argv=out>) at main.c:1025 (gdb) As you mentioned some relation to fedora I made a short search and it looks like there are some patches used, which are not yet upstreamed. https://src.fedoraproject.org/rpms/a2ps/tree/ https://git.savannah.gnu.org/cgit/a2ps.git/log/ Especially the a2ps-4.13b-encoding.patch and a2ps-4.13-glibcpaper.patch seem related. Kind regards, Bernhard apt install systemd-coredump gdb a2ps a2ps-dbgsym zcat /usr/share/doc/a2ps/README.gz | a2ps coredumpctl list coredumpctl gdb 2478 https://sources.debian.org/src/a2ps/1:4.14-5/lib/jobs.c/#L305 Dear Bernhard, That's great news! I do know that the build from the GNU a2ps tarball behaves like the Debian builds. (I tried the Debian testing build too.) That's not surprising since it was the GNU stable source that I used. The only other thing I know is that Fedora 33's current build doesn't care whether "Options: --encoding=latin1" is commented out or not, but it does segfault if "Options: --medium=_glibc" is commented out in a2ps-site.cfg. It doesn't segfault as long as it is passed "Options: --medium=..." where ... can be anything. It will object that it doesn't know what "..". is, that is, if it is not "_glibc" or "letter" or "A4" or whatever, but it won't segfault. Incidentally, it doesn't know what "libpaper" is. And I don't know what "_glibc" is! Thanks again for the positive news. Best wishes, Mack
Bug#977580: phamm: Fix Apache configuration to use mod_php7.c, not mod_php5.c
Package: phamm Version: 0.6.8-1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu hirsute ubuntu-patch Dear Maintainer, In Ubuntu, the attached patch was applied to achieve the following: * Fix Apache configuration file to use mod_php7.c, not mod_php5.c. Thanks for considering the patch. Logan -- System Information: Debian Release: bullseye/sid APT prefers groovy-updates APT policy: (500, 'groovy-updates'), (500, 'groovy-security'), (500, 'groovy'), (100, 'groovy-backports') Architecture: amd64 (x86_64) Kernel: Linux 4.19.128-microsoft-standard (SMP w/8 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect diff -Nru phamm-0.6.8/debian/conf/phamm.conf phamm-0.6.8/debian/conf/phamm.conf --- phamm-0.6.8/debian/conf/phamm.conf 2014-07-15 01:38:41.0 -0400 +++ phamm-0.6.8/debian/conf/phamm.conf 2019-03-28 12:19:26.0 -0400 @@ -23,7 +23,7 @@ - + AddType application/x-httpd-php .php php_flag magic_quotes_gpc Off @@ -32,12 +32,12 @@ php_value include_path . - + AddType application/x-httpd-php .php -Action application/x-httpd-php /cgi-bin/php5 +Action application/x-httpd-php /cgi-bin/php
Bug#977579: gnumeric: Please ask upstream to increase the precision of "=now()" to at least milliseconds.
Package: gnumeric Version: 1.12.47-1 Severity: wishlist Dear Dmitry, Thank you very much for maintaining gnumeric! I like it very much and have used it many times. The main reason I'm writing is to politely ask you to please forward something like an enhancement request or bug report to gnumeric's fine upstream maintainers. I'd like gnumeric's "=now()" time function to be more precise. My testing and reading suggest the most precise time gnumeric's =now() currently supports is 1 second intervals. This is done with time formats like "[mm]:ss". However localc (Libre Office Calc), and evidently also Excel, can format times with much greater precision. Like in milliseconds. localc supports it with the "MM:SS.000" format. I tried to report this directly to the gnumeric guys at https://gitlab.gnome.org/GNOME/gnumeric/-/issues but it says "new user registrations are disabled". Thanks again for sharing your skill so generously! Happy holidays, Kingsley *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages gnumeric depends on: ii cdebconf [debconf-2.0] 0.253 ii debconf [debconf-2.0] 1.5.74 ii gnumeric-common 1.12.47-1 ii gsfonts 1:8.11+urwcyr1.0.7~pre44-4.4 ii libatk1.0-0 2.36.0-2 ii libc6 2.31-5 ii libcairo2 1.16.0-4 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-8 ii libglib2.0-02.64.4-1 ii libgoffice-0.10-10 0.10.46-1 ii libgsf-1-1141.14.46-1 ii libgtk-3-0 3.24.20-1 ii libpango-1.0-0 1.46.1-1 ii libpangocairo-1.0-0 1.46.1-1 ii libxml2 2.9.10+dfsg-6.2 ii procps 2:3.3.15-2+b1 ii pxlib1 0.6.7-1+b1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages gnumeric recommends: ii evince3.32.0-3 ii gnumeric-doc 1.12.47-1 ii lp-solve 5.5.0.15-4+b1 Versions of packages gnumeric suggests: ii fonts-liberation1:1.07.4-11 ii gnumeric-plugins-extra 1.12.47-1 pn libgsf-1-dev -- debconf information: gnumeric/existing-process-title: * gnumeric/existing-process: true
Bug#977441: linux: Pls. consider CONFIG_DRM_V3D
Control: retitle 968181 GPU/DRM acceleration unavailable on Raspberry Pi I modprobe'ed v3d.ko on vanilla Linux kernel 5.10.1, but /dev/dri/render* does not appear like https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1880125/comments/14 https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1850876/comments/33 Simply compiling and loading v3d do not seem to enable DRM/GPU acceleration on RPi4... We may need some work for enabling GPU acceleration on Raspberry Pi series... Ryutaroh
Bug#973905: block 973905 by 972803
block 973905 by 972803 fixed 973905 0.6.0-2 thanks This bug has been fixed in git [1], but can't be uploaded since the package doesn't build with python 3.9 (#972803). [1]: https://salsa.debian.org/python-team/packages/python-typing-inspect/-/commit/7d1368bad8b2a76c83018195bb35fe85ebc480d2 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#977578: python3-opencv: Incomplete dependency on libcharls2
Package: python3-opencv Version: 4.2.0+dfsg-6+b6 Severity: normal X-Debbugs-Cc: none, Dima Kogan Hi. I just upgraded my python opencv bindings on Debian/sid: apt install python3-opencv This worked. But then this happened: dima@fatty:~$ python3 Python 3.9.1 (default, Dec 8 2020, 07:51:42) [GCC 10.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import cv2 Traceback (most recent call last): File "", line 1, in ImportError: libcharls.so.2: cannot open shared object file: No such file or directory I had libcharls2=2.0.0+dfsg-1 (the current stable release). It called that library libCharLS.so.2 instead of libcharls.so.2. Upgrading libcharls2 to the current Debian/sid version fixed the problem. Opencv should update its dependency.
Bug#977577: libowfat: Disable dietlibc build on riscv64
Package: libowfat
Version: 0.30-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
Dear Maintainer,
libowfat currently doesn't build on riscv64 because dietlibc is not
available for that architecture.
In Ubuntu, the attached patch was applied to achieve the following:
* Adapt xnox's patch from 0.30-2ubuntu1, this time to only disable the
dietlibc build on riscv64.
You'll probably need to adapt the patch to reflect all of the
architectures supported in Debian.
Thanks for considering the patch.
Logan
-- System Information:
Debian Release: bullseye/sid
APT prefers groovy-updates
APT policy: (500, 'groovy-updates'), (500, 'groovy-security'), (500,
'groovy'), (100, 'groovy-backports')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.128-microsoft-standard (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru libowfat-0.30/debian/control libowfat-0.30/debian/control
--- libowfat-0.30/debian/control2020-04-30 16:42:48.0 -0400
+++ libowfat-0.30/debian/control2020-12-16 00:01:12.0 -0500
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Debian QA Group
Standards-Version: 4.5.0
-Build-Depends: dietlibc-dev, dietlibc-dev (>= 0.32-5) [sparc],
debhelper-compat (= 13)
+Build-Depends: dietlibc-dev [amd64 arm64 armhf ppc64el s390x],
debhelper-compat (= 13)
Homepage: http://www.fefe.de/libowfat/
Vcs-Git: https://salsa.debian.org/debian/libowfat.git
Vcs-Browser: https://salsa.debian.org/debian/libowfat
@@ -43,7 +43,7 @@
Package: libowfat-dietlibc-dev
Section: libdevel
-Architecture: any
+Architecture: amd64 arm64 armhf ppc64el s390x
Depends: dietlibc-dev, ${misc:Depends}
Conflicts: libdjbdns1-dev
Breaks: libowfat-dev (<< 0.28-3)
diff -Nru libowfat-0.30/debian/rules libowfat-0.30/debian/rules
--- libowfat-0.30/debian/rules 2020-04-30 14:41:56.0 -0400
+++ libowfat-0.30/debian/rules 2020-12-16 00:01:12.0 -0500
@@ -1,5 +1,7 @@
#!/usr/bin/make -f
+include /usr/share/dpkg/architecture.mk
+
CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS)
CFLAGS:=$(shell dpkg-buildflags --get CFLAGS) $(CPPFLAGS)
CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS) $(CPPFLAGS)
@@ -15,11 +17,14 @@
$(MAKE) -f $(CURDIR)/GNUmakefile -C build-glibc SRC=$(CURDIR)/ DIET=''
rm build-glibc/entities.h
+# dietlibc is unavailable on riscv64
+ifneq (,$(filter $(DEB_HOST_ARCH), amd64 arm64 armhf ppc64el s390x))
mkdir build-diet
$(MAKE) -f $(CURDIR)/GNUmakefile -C build-diet SRC=$(CURDIR)/
DIET='diet -v -Os'
rm build-diet/entities.h
touch build-stamp
+endif
override_dh_clean:
dh_clean # doesn't remove directories
Bug#977576: bandwidthd: Update bandwidthd-pgsql Recommends to PHP 7
Package: bandwidthd
Version: 2.0.1+cvs20090917-12
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
Dear Maintainer,
bandwidthd-pgsql currently recommends PHP 5 packages that are no longer
published.
In Ubuntu, the attached patch was applied to achieve the following:
* Update bandwidthd-pgsql Recommends to PHP 7.
Thanks for considering the patch.
Logan
-- System Information:
Debian Release: bullseye/sid
APT prefers groovy-updates
APT policy: (500, 'groovy-updates'), (500, 'groovy-security'), (500,
'groovy'), (100, 'groovy-backports')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.128-microsoft-standard (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru bandwidthd-2.0.1+cvs20090917/debian/control
bandwidthd-2.0.1+cvs20090917/debian/control
--- bandwidthd-2.0.1+cvs20090917/debian/control 2020-08-06 16:42:53.0
-0400
+++ bandwidthd-2.0.1+cvs20090917/debian/control 2020-12-16 22:27:00.0
-0500
@@ -35,7 +35,7 @@
${misc:Depends},
${shlibs:Depends},
lsb-base
-Recommends: php5, php5-gd, php5-pgsql
+Recommends: php, php-gd, php-pgsql
Suggests: apache2, postgresql
Conflicts: apache2 (<< 2.4), bandwidthd
Description: Tracks usage of TCP/IP and builds html files with graphs
Bug#816861: fuser does not show the PID that keeps busy a schroot mount-point
On Fri, 29 Apr 2016 at 06:31, Franco Martelli wrote:
> $ fuser -M
> /var/lib/schroot/mount/kubuntu-e1c05063-2aca-491c-b5e4-4a4e1c41c65c
> Specified filename
> /var/lib/schroot/mount/kubuntu-e1c05063-2aca-491c-b5e4-4a4e1c41c65c is
> not a mountpoint.
>
> fuser now tell me that it wasn't a mount point but it was indeed,
> although actually not mounted anymore:
> $ mount | grep
> /var/lib/schroot/mount/kubuntu-e1c05063-2aca-491c-b5e4-4a4e1c41c65c
> $
>
Then fuser is doing the correct thing. If you specify that it should be
looking for a mount, and the mount is no longer there, then it will
correctly say it doesn't exist.
Most chroots are just directories, so they don't have their own mount point.
Also processes inside the chroot and outside the choot have a different
view of the world.
asking fuser which processes keeps busy the mount-point:
> # fuser
> /var/lib/schroot/mount/kubuntu-76da7862-ef1b-4b04-920b-459be3350e85/
> /var/lib/schroot/mount/kubuntu-76da7862-ef1b-4b04-920b-459be3350e85: 5681r
> # fuser -m
> /var/lib/schroot/mount/kubuntu-76da7862-ef1b-4b04-920b-459be3350e85/
> /var/lib/schroot/mount/kubuntu-76da7862-ef1b-4b04-920b-459be3350e85:
> 5681rce
> # fuser -M
> /var/lib/schroot/mount/kubuntu-76da7862-ef1b-4b04-920b-459be3350e85/
> /var/lib/schroot/mount/kubuntu-76da7862-ef1b-4b04-920b-459be3350e85: 5681r
>
So its doing the right thing here? It looks correct.
fuser never report cupsd's PID(5723) the 5681 PID number reported refers
> to bash:
> # pstree -cpan | grep -B2 -A1 5681
> | |-bash,1148 --rcfile ~/.bashrc_develop -i
> | | `-schroot,5608 -c kubuntu --
> | | `-bash,5681
> | `-bash,1152 --rcfile ~/.bashrc_develop -i
>
Can you provide:
* what fuser command you are running
* are you running this as root or not
* Run sudo ls -l /proc//{root,exe,cwd} where is the cups process
or whatever the one you think it is
e.g.
$ sudo fuser /srv/chroot/bullseye/
/srv/chroot/bullseye: 99201rc
$ sudo ls -l /proc/99201/{root,exe,cwd}
lrwxrwxrwx 1 root root 0 Dec 17 13:41 /proc/99201/cwd ->
/srv/chroot/bullseye
lrwxrwxrwx 1 root root 0 Dec 17 13:41 /proc/99201/exe ->
/srv/chroot/bullseye/usr/bin/bash
lrwxrwxrwx 1 root root 0 Dec 17 13:41 /proc/99201/root ->
/srv/chroot/bullseye
>
> HTH best regards
>
> On 25/04/2016 at 04:26, Craig Small wrote:
> > The problem is that fuser works off device numbers (it has to otherwise
> > symlinks would confuse it) and there is nothing much that makes the
> > chroots unique. A chroot is basically saying "start your tree here". My
> > chroots for example sit under /var/chroot
> >
> > Now, outside the chroot I can work out what process has that open with
> > fuser /var/chroot/wheezy (note the lack of -m because these are not
> > mount points).
> >
> > Remember when you use the -m command you are saying the device ID where
> > that file sits. It might be the actual mount point, or just a file (and
> > fuser works out where that file sits).
> >
> > If you really mean a mount point, then -M is a better idea.
> > I don't really understand your setup because you have other mounts
> > coming into your chroot. I think your tests are doing simple text
> > matching which causes a bunch of failed misses but need to be sure.
> >
> > /proc//mountinfo isn't the fix, because just like /proc//fd it
> > can be fooled by symlinks.
> >
> > - Craig
> > --
> > Craig Small (@smallsees) http://enc.com.au/ csmall at :
> > enc.com.au
> > Debian GNU/Linux http://www.debian.org/ csmall at :
> > debian.org
> > GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50
> FEA5
>
> --
> Franco Martelli
>
--
Craig Small https://dropbear.xyz/ csmall at : dropbear.xyz
Debian GNU/Linuxhttps://www.debian.org/
Bug#959905: Any update?
Hi Alexandre, Any update on this bug? It's stopping the migration to testing and it would be nice to have this tool in the next stable release of Debian. Thanks! -- Martin Michlmayr https://www.cyrius.com/
Bug#977516: osmo-bsc: build-depends on obsolete package.
On 16/12/2020 21:48, Thorsten Alteholz wrote: Hi Peter, are you sure about your bug report? The control file of osmo-bsc/1.6.1+dfsg1-3 contains: Build-Depends: debhelper-compat (= 12), pkg-config, libosmocore-dev (>= 1.4.0), libosmo-sccp-dev (>= 1.3.0), libosmo-mgcp-client-dev (>= 1.7.0), libosmo-legacy-mgcp-dev, libosmo-abis-dev (>= 1.0.1), libosmo-netif-dev (>= 1.0.0), libosmo-sigtran-dev (>= 1.3.0), libsqlite3-dev, libpcap-dev, libcdk5-dev, txt2man # libosmo-legacy-mgcp-dev (>= 1.7.0), The dependency libosmo-legacy-mgcp-dev is commented out I see libosmo-legacy-mgcp-dev in the build-dependency list twice, the second one is commented out, but the first one is still active. and instead libosmo-mgcp-client-dev (>= 1.7.0) is used, which is provided by osmo-mgw/1.7.0+dfsg1-2 Thorsten
Bug#977514: Problem persists after nVidia driver update to 455 branch
I updated nVidia drivers to .run archive from nVidia's site, version 455.45.01 (support for 5.9 kernel). Unfortunately the problem persists.
Bug#977575: raspberry pi touch screen support
Source: linux Version: 5.10.1-1~exp1 Severity: wishlist Dear Debian kernel maintainers, debian/config/arm64/config on salsa.debian.org has CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN=m suggesting intention of supporting the official raspi touch screen... But the following config items are disabled now, which seems contradicting... CONFIG_TOUCHSCREEN_RASPBERRYPI_FW=m CONFIG_REGULATOR_RASPBERRYPI_TOUCHSCREEN_ATTINY=m may provide better support of raspi touch screnn. Best regards, Ryutaroh Matsumoto
Bug#977574: lintian: issues about quoted-placeholder-in-mailcap-entry
Package: lintian
Version: 2.42.0
X-Debbugs-CC: felix.lech...@lease-up.com, atom...@gmail.com
Hello,
thanks for your work on #33486 (check for unsafe mailcap entries).
I want to report a couple of issues:
1) only %s is checked
The top message in #33486 refers to "%-expansions", but the test only addresses
"%s".
I don't see a reason not to check for every possible %-expansion (%s, %t,
%{name}, %n, %F).
Mailcap rules are not required to have a "%s" because they can use
stdin/stdout, but they may still contain other %-expansions, which are also
unsafe if quoted.
For example the replacement for %t or %{charset} may come directly from
untrusted email headers.
2) false positives / false negatives
The current algorithm to determine whether a %-expansion is inside quotes may
work in the majority of cases, but it's easy to produce false positives and
false negatives:
False negatives:
text/plain; foo --opt=\\' '%s'
text/plain; foo --opt="\\"it's cool\\"" '%s'
False positives:
text/plain; foo --opt=\\' %s; print=bar --opt=\\' %s
text/plain; foo "$(readlink %s)"
Making a 100% correct check is a hairy business: it would require to take into
account the entire shell grammar.
I don't have a concrete proposal at the moment, I just wanted to make sure you
are aware of the problem. I'm not suggesting to complicate the current check by
adding special cases because it would just make it harder to reason about.
Before I knew about the Lintian test I used to look for bad rules with these
simple patterns:
'.*%(s|t|{[^}]*}|n|F)'
".*%(s|t|{[^}]*}|n|F)"
This also has both false positives and false negatives, but they should be
unlikely to occur because %-expansions are usually intended to be placed at the
end of a shell word.
The current check also doesn't address %-expansions inside `back quotes` which,
albeit improbable, are also affected by the same problem.
I don't know what to do about point #2, but at least #1 should be easy to fix.
Now that we have this Lintian test, is it still appropriate to file bugs for
packages with bad quotation in mailcap rules, or should I assume that every
maintainer runs Lintian and is already aware of the problem?
For example we have libreoffice bug #950319 (bad mailcap rule), which is
blocked by mailcap bug #928037 (document policy about quoting). The latter was
reported by me (and not making any progress).
Thanks,
MNZ
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=33486
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950319
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928037
Bug#977438: Pls. consider raspi-related configs for kernel 5.10
Control: retitle -1 Pls. consider raspi-related configs for 5.10 Control: tags -1 + patch Control: block 968181 by 977441 Dear Debian kernel maintainers, CC: the Debian ARM list, Could you consider enabling the following kernel compilation options for Raspberry Pi 3&4 series for kernel 5.10? The patch is against latest package source at salsa.debian.org. --- debian/config/arm64/config-orig 2020-12-16 09:46:18.645380333 +0900 +++ debian/config/arm64/config 2020-12-16 10:22:17.998897582 +0900 @@ -424,6 +424,11 @@ ## file: drivers/gpu/drm/vc4/Kconfig ## CONFIG_DRM_VC4=m +CONFIG_DRM_VC4_HDMI_CEC=y +CONFIG_DRM_V3D=m +CONFIG_BCM_VIDEOCORE=m +CONFIG_BCM2835_VCHIQ=m +CONFIG_BCM2835_VCHIQ_MMAL=m ## ## file: drivers/gpu/host1x/Kconfig @@ -443,6 +448,7 @@ CONFIG_SENSORS_PWM_FAN=m CONFIG_SENSORS_SL28CPLD=m CONFIG_SENSORS_XGENE=m +CONFIG_SENSORS_RASPBERRYPI_HWMON=m ## ## file: drivers/hwspinlock/Kconfig @@ -1006,6 +1012,7 @@ CONFIG_PINCTRL_AMD=y CONFIG_PINCTRL_SINGLE=y CONFIG_PINCTRL_MAX77620=y +CONFIG_PINCTRL_BCM2835=y ## ## file: drivers/pinctrl/qcom/Kconfig @@ -1093,6 +1100,7 @@ ## file: drivers/reset/Kconfig ## CONFIG_RESET_CONTROLLER=y +CONFIG_RESET_RASPBERRYPI=m ## ## file: drivers/rpmsg/Kconfig @@ -1136,6 +1144,7 @@ ## file: drivers/soc/bcm/Kconfig ## CONFIG_RASPBERRYPI_POWER=y +CONFIG_BCM2835_POWER=y ## ## file: drivers/soc/fsl/Kconfig I have already built a Debian package with the above options from the latest master branch source on salsa.debian.org, and observed the following on RPi4: (1) CONFIG_DRM_V3D has no effect, as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977441#18 (2) HDMI display resolution can become 4K and fixing an important bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968188 (3) /dev/dri/render* does not appear unlike https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1880125/comments/14 https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1850876/comments/33 GPU/DRM acceleration remains unusable on RPi4, and bug 968181 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968181 remains open. 968181 seems blocked by 977441. (4) My built Debian kernel 5.10.1 can boot from my usb mass storage device ID 04bb:0168 I-O Data Device, Inc. I-O DATA HDPH-UT but cannot access the root filesystem... My USB MSD mergenally worked with Debian kernel 5.9.* and can compile the Debian kernel package. My USB MSD requires periodical reset by the Debian kernel 5.9.*, which suggests this MSD is buggy... I ordered a faster SSD-based USB MSD. (5) Raspberry Pi Wireless cannot be used by my built Debian kernel 5.10.1. The wirelss has worked perfectly with Debian kernel 5.7--5.9. I will see what will happen with a Debian kernel package 5.10* both with and without proposed patch, and report it back, when it arrives in experimental or unstable. Bes regards, Ryutaroh Matsumoto
Bug#950319: libreoffice: filename replacements in mime entries for mailcap must not be quoted within the given command
Hello, Unfortunately no progress yet on #928037, but I wanted to add here some info from related bug reports. 1) There is a Lintian test for this specific problem: https://lintian.debian.org/tags/quoted-placeholder-in-mailcap-entry.html Package libreoffice and 40 more, currently trigger the warning. The test was introduced in Lintian 2.42.0, 19 Dec 2019. The bug report requesting the test dates back to 17 Feb 1999: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=33486 2) The problem has already been discussed in old bugs, usually reaching the conclusion that %-escapes should *not* be quoted in the rules: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=33486#42 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747050 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745141 https://lists.debian.org/debian-user/2005/04/msg01185.html Unfortunately they decided not to document anything because "I would like to avoid divergence with other platforms": https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=90483#30 As a result, many years later, every piece of Debian concerning mailcap is still a vector for arbitrary command execution, while package maintainers have no way of knowing what to do, and bug reports keep resurrecting like zombies (my #928037 is a duplicate of 10yo #90483). 3) Thunderbird doesn't use the %-expansion in the rules at all. The parsing function extracts what it thinks is the "executable name" and returns just that. https://hg.mozilla.org/mozilla-central/file/661f0d8ae4c44db58e668c831b555dbc038b77d0/uriloader/exthandler/unix/nsOSHelperAppService.cpp >From function UnescapeCommand: "UnescapeCommand really needs some work -- it should actually do some unescaping" >From function GetHandlerAndDescriptionFromMailcapFile: // XXX ugly hack. Just grab the executable name ... // XXX End ugly hack I don't know about Evolution.
Bug#977441: linux: Pls. consider CONFIG_DRM_V3D
Control: tags -1 + patch Just adding CONFIG_DRM_V3D=m is not enough, as reported at https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1876862/comments/5 The following patch seems necessary, which has been introduced in the Ubuntu kernel. change linux/drivers/gpu/drm/v3d/kconfig - depends on ARCH_BCM || ARCH_BCMSTB || COMPILE_TEST + depends on ARCH_BCM || ARCH_BCMSTB || ARCH_BCM2835 || COMPILE_TEST Best regards, Ryutaroh Matsumoto
Bug#977516: osmo-bsc: build-depends on obsolete package.
Hi Peter, are you sure about your bug report? The control file of osmo-bsc/1.6.1+dfsg1-3 contains: Build-Depends: debhelper-compat (= 12), pkg-config, libosmocore-dev (>= 1.4.0), libosmo-sccp-dev (>= 1.3.0), libosmo-mgcp-client-dev (>= 1.7.0), libosmo-legacy-mgcp-dev, libosmo-abis-dev (>= 1.0.1), libosmo-netif-dev (>= 1.0.0), libosmo-sigtran-dev (>= 1.3.0), libsqlite3-dev, libpcap-dev, libcdk5-dev, txt2man # libosmo-legacy-mgcp-dev (>= 1.7.0), The dependency libosmo-legacy-mgcp-dev is commented out and instead libosmo-mgcp-client-dev (>= 1.7.0) is used, which is provided by osmo-mgw/1.7.0+dfsg1-2 Thorsten
Bug#977226: diff NMU for 0.46.0-1.1
tags 977226 +pending +patch user team+bo...@tracker.debian.org usertag 977226 +boost174 thanks Dear maintainer, I have prepared an NMU (versioned as 0.46.0-1.1) and uploaded to DELAYED/5. Please feel free to tell me if I should delay it longer, cancel or reschedule. Diff is attached. MR is here [1]. [1] https://salsa.debian.org/games-team/openmw/-/merge_requests/1 Best regards Anton nmu.debdiff Description: Binary data
Bug#977562: systemd: Incorrect order of agetty arguments in serial-getty@ttyS0.service definition file
Am 16.12.20 um 20:49 schrieb MK: Package: systemd Version: 241-7~deb10u5 Severity: normal Goal: enabling serial communication over null modem cable between two Debian 10 hosts. Steps to reproduce: 1. Connect null-modem cable to both machines. 2. Edit /etc/default/grub: GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200n8" GRUB_TERMINAL=console (update-initramfs -u of course) 3. Enable serial systemd service: # systemctl enable serial-getty@ttyS0.service 4. Reboot. Expected result: Serial comm works, command used: tio -f soft /dev/ttyS0 Actual results: tio or minicom spit out garbage characters. Cause: Incorrect order of arguments to agetty in the serial-getty@ttyS0.service unit file. It is: ExecStart=/sbin/agetty --autologin root -8 --keep-baud 115200,38400,9600 ttyS0 xterm-256color While it should be like: ExecStart=/sbin/agetty --autologin root -8 --keep-baud ttyS0 115200 xterm-256color Note: order of port and baud rate is reversed. man agetty says it should be: agetty [options] port [baud_rate...] [term] In the default service definition baud rate PRECEDES port. After using my config line above serial commuication works fine. agetty [options] port [baud_rate...] [term] In the default service definition baud rate PRECEDES port. After using my config line above serial commuication works fine. According to the examples in man agetty, both should work. Andreas, can you comment here? If what MK is saying, should the "EXAMPLE" section in man agetty be updated? OpenPGP_signature Description: OpenPGP digital signature
Bug#977573: net-snmp: Make the perl agent code more tolerant of perl types
Source: net-snmp
Source-Version: 5.9+dfsg-3
Severity: wishlist
Tags: patch
Hi!
The code is currently very strict, and does not accept several internal
perl representations for integer scalars. This is a problem when writing
SNMP agents in perl as the values might come from external sources and
might be represented internally in multiple ways, which might change
over the course of the execution.
In addition, improve the logging output to make it easier to diagnose why
a scalar variable could not be set.
These two patches were merged upstream:
https://github.com/net-snmp/net-snmp/pull/153
but I don't expect a new release soon. And it would be nice to merge
these in Debian before the bullseye release. This would be helpful as
these are the only two patches we need a fork for at $work. :)
I'm attaching a patch adding these two patches.
Thanks,
Guillem
diff --git c/debian/patches/0001-Perl-agent-Print-the-perl-scalar-flags-on-type-misma.patch i/debian/patches/0001-Perl-agent-Print-the-perl-scalar-flags-on-type-misma.patch
new file mode 100644
index 000..c4b4a33
--- /dev/null
+++ i/debian/patches/0001-Perl-agent-Print-the-perl-scalar-flags-on-type-misma.patch
@@ -0,0 +1,85 @@
+From d59ae433af8b6d9051d149ca2a745fc845e7c82d Mon Sep 17 00:00:00 2001
+From: Guillem Jover
+Date: Fri, 22 Apr 2016 15:45:07 +0200
+Subject: [PATCH 1/2] Perl, agent: Print the perl scalar flags on type mismatch
+ in setValue
+
+This makes it easier to debug why a type mismatch happened, as we can
+see how the type is represented internally by perl.
+---
+ perl/agent/agent.xs | 24
+ 1 file changed, 12 insertions(+), 12 deletions(-)
+
+diff --git a/perl/agent/agent.xs b/perl/agent/agent.xs
+index 163a3ba81a..ed8a56c9fb 100644
+--- a/perl/agent/agent.xs
b/perl/agent/agent.xs
+@@ -646,8 +646,8 @@ nari_setValue(me, type, value)
+ break;
+ }
+ else {
+- snmp_log(LOG_ERR, "Non-integer value passed to setValue with ASN_INTEGER: type was %lu\n",
+- (unsigned long)SvTYPE(value));
++ snmp_log(LOG_ERR, "Non-integer value passed to setValue with ASN_INTEGER: type was %lu flags %#lx\n",
++ (unsigned long)SvTYPE(value), (unsigned long)SvFLAGS(value));
+ RETVAL = 0;
+ break;
+ }
+@@ -682,8 +682,8 @@ nari_setValue(me, type, value)
+ break;
+ }
+ else {
+- snmp_log(LOG_ERR, "Non-unsigned-integer value passed to setValue with ASN_UNSIGNED/ASN_COUNTER/ASN_TIMETICKS: type was %lu\n",
+- (unsigned long)SvTYPE(value));
++ snmp_log(LOG_ERR, "Non-unsigned-integer value passed to setValue with ASN_UNSIGNED/ASN_COUNTER/ASN_TIMETICKS: type was %lu flags %#lx\n",
++ (unsigned long)SvTYPE(value), (unsigned long)SvFLAGS(value));
+ RETVAL = 0;
+ break;
+ }
+@@ -708,8 +708,8 @@ nari_setValue(me, type, value)
+ RETVAL = 1;
+ }
+ else {
+- snmp_log(LOG_ERR, "Non-unsigned-integer value passed to setValue with ASN_COUNTER64: type was %lu\n",
+- (unsigned long)SvTYPE(value));
++ snmp_log(LOG_ERR, "Non-unsigned-integer value passed to setValue with ASN_COUNTER64: type was %lu flags %#lx\n",
++ (unsigned long)SvTYPE(value), (unsigned long)SvFLAGS(value));
+ RETVAL = 0;
+ }
+ if (RETVAL) {
+@@ -725,8 +725,8 @@ nari_setValue(me, type, value)
+ case ASN_OPAQUE:
+ /* Check that we have been passed something with a string value (or a blessed scalar) */
+ if (!SvPOKp(value) && (SvTYPE(value) != SVt_PVMG)) {
+- snmp_log(LOG_ERR, "Non-string value passed to setValue with ASN_OCTET_STR/ASN_BIT_STR: type was %lu\n",
+- (unsigned long)SvTYPE(value));
++ snmp_log(LOG_ERR, "Non-string value passed to setValue with ASN_OCTET_STR/ASN_BIT_STR: type was %lu flags %#lx\n",
++ (unsigned long)SvTYPE(value), (unsigned long)SvFLAGS(value));
+ RETVAL = 0;
+ break;
+ }
+@@ -752,8 +752,8 @@ nari_setValue(me, type, value)
+
+ /* Check that we have been passed something with a string value (or a blessed scalar) */
+ if (!SvPOKp(value) && (SvTYPE(value) != SVt_PVMG)) {
+- snmp_log(LOG_ERR, "Non-string value passed to setValue with ASN_IPADDRESS: type was %lu\n",
+- (unsigned long)SvTYPE(value));
++ snmp_log(LOG_ERR, "Non-string value passed to setValue with ASN_IPADDRESS: type was %lu flags %#lx\n",
++ (unsigned long)SvTYPE(value), (unsigned long)SvFLAGS(value));
+ RETVAL = 0;
+ break;
+ }
+@@ -779,8 +779,8 @@ nari_setValue(me, type, value)
+ case ASN_OBJECT_ID:
+ /* Check that we have been passed something with a string value (or a blessed scalar) */
+ if (!SvPOKp(value) && (SvTYPE(value) != SVt_PVMG)) {
+- snmp_log(LOG_ERR, "Non-string value passed to setValue with ASN_OBJECT_ID: type was %lu\n",
+- (unsigned long)SvTYPE(value));
++ snmp_log(LOG_ERR, "Non-string value passed to setValue with ASN_OBJECT_ID: type was %lu flags %#lx\n",
++ (unsigned long)SvTYPE(value), (unsigned long)SvFLAGS(value));
+ RETVAL = 0;
+ break;
+ }
+--
Bug#977572: libssl-utils-clojure: jars are not installed in maven-repo
Package: src:ssl-utils-clojure Version: 0.8.3-2 Severity: important Owner: po...@debian.org It seems only pom files are installed in maven-repo, and not jar files. This means we can't currently use this package as a dependency when building with leiningen. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#977571: libring-core-clojure: jars are not installed in maven-repo
Package: src:ring-core-clojure Version: 1.6.2-2 Severity: important Owner: po...@debian.org It seems only pom files are installed in maven-repo, and not jar files. This means we can't currently use this package as a dependency when building with leiningen. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#844078: Updating upstream debian packages
Hello, AGS has an experimental branch to switch from Allegro4 backend to SDL2 backend. It's in the process of updating the AGS Debian packaging scripts of this branch. If someone is interested in helping out, please give a hi here : https://github.com/adventuregamestudio/ags/issues/1148 Is it alright to statically link SDL_Sound since the version in the Debian repository targets SDL 1.2 instead of 2? And should SDL2 be dynamically or statically linked, since depending on the Debian version, SDL 2 will be pre SDL 2.0.9, which breaks SDL_Sound and thus breaks ags.
Bug#977185: Can be switched to default
I have checked and your package can easily be switched to the unversioned dev-package. Regards Anton
Bug#974095: telegram-desktop: Segmentation fault in LottieShapeData::lerp
reassign 974095 librlottie0-1 0.1+dfsg-1 affects 974095 telegram-desktop stop Hello! I reassign your bug to the rlottie package since the given stack-trace distinctly reveals that the crash happens inside rlottie source code. I daresay the crash occurs due to different sizes of mInPoint, mOutPoint, or mVertices vectors that is filled from "o", "v", or "c" arrays in input JSON with animated sticker. I managed to reproduce the bug after I corrupted in such a way an animated sticker. Here the bug appears, because of empty mPoints vector. https://sources.debian.org/src/rlottie/0.1+dfsg-1/src/lottie/lottieparser.cpp/#L1913 signature.asc Description: This is a digitally signed message part
Bug#976909: h2o: FTBFS on ppc64el: ld: /usr/lib/gcc/powerpc64le-linux-gnu/10/../../../powerpc64le-linux-gnu/Scrt1.o:(.data.rel.ro.local+0x8): undefined reference to `main'
severity 976909 normal tags 976909 +moreinfo thanks Hi Lucas, thanks for filing the bug. But I cannot reproduce this failure and it looks like the last upload of the package h2o into the archive was successfully built of ppc64el [1]. Could you please check your setup and provide more information? [1] https://buildd.debian.org/status/fetch.php?pkg=h2o=ppc64el=2.2.5%2Bdfsg2-6=1608152493=0 Regards Anton Am Mi., 9. Dez. 2020 um 10:09 Uhr schrieb Lucas Nussbaum : > > Source: h2o > Version: 2.2.5+dfsg2-5 > Severity: serious > Justification: FTBFS on ppc64el > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el
Bug#977536: tang: provide the nagios plugin as Debian Package
Control: retitle 977536 ITP: nagios-tang -- A Nagios plugin to check the health of the Tang server Control: package 977536 wnpp Reiner Schulz wrote... > please provide the tang nagios plugin as Debian Package Oh well, this took a moment to figure out. That check existed in the past but is no longer part of tang. So a request for packaging (RFP) is right way to deal with such a situation, let me take care of that. Christoph signature.asc Description: PGP signature
Bug#977536: tang: provide the nagios plugin as Debian Package
X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: nagios-tang Version : 7 Upstream Author : Nathaniel McCallum * URL : https://github.com/latchset/nagios-tang/ * License : GPL-3+ Programming Lang: C Description : A Nagios plugin to check the health of the Tang server -Description: monitoring plugin to check the tang server - This package provides a plugin to monitor a tang server, a service for - binding cryptographic keys to network presence. The nagios check for a tang service was part of the tang package in ealier times¹, but later upstream moved it into a separate package. By request of a user I wish to bring it back to Debian. Cheers, Christoph ¹ http://snapshot.debian.org/binary/tang-nagios/ signature.asc Description: PGP signature
Bug#977459: tang: describe what 'tangd-update.service' does
Reiner Schulz wrote... > After install the package there ist a systemd unit 'tangd-update.service' > please describe what this service does tangd-update.service was used by upstream in earlier versions of tang to create some additional files needed for operation. That was removed there recently, and therefore it will vanish from Debian as well soon. Christoph signature.asc Description: PGP signature
Bug#977570: netatalk FTCBFS: uses the build architecture compiler via dtrace
Source: netatalk Version: 3.1.12~ds-7 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs netatalk fails to cross build from source, because it runs the build architecture compiler via dtrace. Everything else works now. dtrace is a strange thing and part of systemtap. In order to use it during cross compilation, one must export the compiler as CC environment variable. The attached patch implements that. Please consider applying it. Once doing so, netatalk finally becomes cross buildable. Helmut --- netatalk-3.1.12~ds.orig/etc/afpd/Makefile.am +++ netatalk-3.1.12~ds/etc/afpd/Makefile.am @@ -90,7 +90,7 @@ DTRACE_OBJ = afpd-afp_dsi.o afpd-fork.o afpd-appl.o afpd-catsearch.o afpd-directory.o afpd-enumerate.o afpd-file.o afpd-filedir.o afp_dtrace.o: $(top_srcdir)/include/atalk/afp_dtrace.d $(DTRACE_OBJ) if test -f afp_dtrace.o ; then rm -f afp_dtrace.o ; fi - $(LIBTOOL) --mode=execute dtrace -G -s $(top_srcdir)/include/atalk/afp_dtrace.d -o afp_dtrace.o $(DTRACE_OBJ) + CC=$(CC) $(LIBTOOL) --mode=execute dtrace -G -s $(top_srcdir)/include/atalk/afp_dtrace.d -o afp_dtrace.o $(DTRACE_OBJ) afpd_LDADD += afp_dtrace.o @DTRACE_LIBS@ CLEANFILES += afp_dtrace.o endif
Bug#977569: l2tpns FTCBFS: uses the build architecture compiler
Source: l2tpns Version: 2.3.1-2 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs l2tpns fails to cross build from source, because it uses the build architecture compiler in a few remaining spots. It hard codes plain gcc in two occasions. Using $(CC) there fixes that. It also uses the build architecture compiler via the LD variable. This variable is not susbtituted by dh_auto_build, because its usage is not consistent. Sometimes people store ld there. In this case, defaulting it to $(CC) does what one usually wants. Please consider applying the attached patch as it makes l2tpns cross buildable. Helmut --- l2tpns-2.3.1.orig/Makefile +++ l2tpns-2.3.1/Makefile @@ -13,7 +13,7 @@ DEB_CFLAGS_MAINT_APPEND=-Wall -O3 -Wno-format-zero-length CC = gcc -LD = gcc +LD = $(CC) INCLUDES = -I. CPPFLAGS = `dpkg-buildflags --get CPPFLAGS` $(INCLUDES) $(DEFINES) CFLAGS = `dpkg-buildflags --get CFLAGS` @@ -50,8 +50,8 @@ depend: (sed -n 'p; /^## Dependencies: (autogenerated) ##/q' Makefile && \ - gcc -MM $(CPPFLAGS) $(OBJS:.o=.c) && \ - gcc -MM $(CPPFLAGS) $(PLUGINS:.so=.c) | sed 's/\.o/.so/') >Makefile.tmp + $(CC) -MM $(CPPFLAGS) $(OBJS:.o=.c) && \ + $(CC) -MM $(CPPFLAGS) $(PLUGINS:.so=.c) | sed 's/\.o/.so/') >Makefile.tmp mv Makefile Makefile.bak mv Makefile.tmp Makefile
Bug#976368: override: python2.7 and python-defaults binaries should be optional, not standard
On 12/16/20 9:41 PM, Sean Whitton wrote: > control: tag -1 + moreinfo > > Hello, > > On Fri 04 Dec 2020 at 08:35AM +01, Matthias Klose wrote: > >> Package: ftp.debian.org >> >> python2.7 and python-defaults binaries should be optional, not standard. > > Just to be sure, do you mean all the binaries produced by these two > source packages? yes please!
Bug#977568: xml-security-c: FTBFS with Xalan 1.12
Source: xml-security-c
Severity: serious
Tags: patch upstream
Hi,
xalan-c 1.12 is currently in experimental and contains some changes that
cause xml-security-c to FTBFS.
The attached quilt patch contains the necessary updates and allows for
compilation with either 1.11 and 1.12.
Best regards,
Bill
Description: Update for Xalan 1.12
Author: Bill Blough
Forwarded: no
Last-Update: 2020-12-16
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/xsec/dsig/DSIGXPathHere.cpp
+++ b/xsec/dsig/DSIGXPathHere.cpp
@@ -30,7 +30,7 @@
#ifdef XSEC_HAVE_XPATH
-XALAN_USING_XALAN(XalanCopyConstruct);
+using xalanc::XalanCopyConstruct;
DSIGXPathHere::DSIGXPathHere() {
--- a/xsec/dsig/DSIGXPathHere.hpp
+++ b/xsec/dsig/DSIGXPathHere.hpp
@@ -56,12 +56,12 @@
// Namespace usage
-XALAN_USING_XALAN(Function);
-XALAN_USING_XALAN(XalanNode);
-XALAN_USING_XALAN(XPathExecutionContext);
-XALAN_USING_XALAN(XalanDOMString);
-XALAN_USING_XALAN(XObjectPtr);
-XALAN_USING_XALAN(MemoryManagerType);
+using xalanc::Function;
+using xalanc::XalanNode;
+using xalanc::XPathExecutionContext;
+using xalanc::XalanDOMString;
+using xalanc::XObjectPtr;
+using xalanc::MemoryManagerType;
XSEC_USING_XERCES(Locator);
--- a/xsec/samples/simpleDecrypt.cpp
+++ b/xsec/samples/simpleDecrypt.cpp
@@ -54,7 +54,7 @@
#ifdef XSEC_HAVE_XALAN
#include
-XALAN_USING_XALAN(XalanTransformer)
+using xalanc::XalanTransformer;
#endif
// OpenSSL
--- a/xsec/samples/simpleEncrypt.cpp
+++ b/xsec/samples/simpleEncrypt.cpp
@@ -48,7 +48,7 @@
#ifdef XSEC_HAVE_XALAN
#include
-XALAN_USING_XALAN(XalanTransformer)
+using xalanc::XalanTransformer;
#endif
XERCES_CPP_NAMESPACE_USE
--- a/xsec/samples/simpleHMAC.cpp
+++ b/xsec/samples/simpleHMAC.cpp
@@ -49,7 +49,7 @@
#ifdef XSEC_HAVE_XALAN
#include
-XALAN_USING_XALAN(XalanTransformer)
+using xalanc::XalanTransformer;
#endif
XERCES_CPP_NAMESPACE_USE
--- a/xsec/samples/simpleValidate.cpp
+++ b/xsec/samples/simpleValidate.cpp
@@ -52,7 +52,7 @@ XERCES_CPP_NAMESPACE_USE
#ifdef XSEC_HAVE_XALAN
#include
-XALAN_USING_XALAN(XalanTransformer)
+using xalanc::XalanTransformer;
#endif
char docToValidate [4096] = "\
--- a/xsec/tools/checksig/checksig.cpp
+++ b/xsec/tools/checksig/checksig.cpp
@@ -83,8 +83,8 @@ using std::endl;
#include
#include
-XALAN_USING_XALAN(XPathEvaluator)
-XALAN_USING_XALAN(XalanTransformer)
+using xalanc::XPathEvaluator;
+using xalanc::XalanTransformer;
#endif
--- a/xsec/tools/cipher/cipher.cpp
+++ b/xsec/tools/cipher/cipher.cpp
@@ -93,8 +93,8 @@ using std::ostream;
#include
#include
-XALAN_USING_XALAN(XPathEvaluator)
-XALAN_USING_XALAN(XalanTransformer)
+using xalanc::XPathEvaluator;
+using xalanc::XalanTransformer;
#endif
--- a/xsec/tools/siginf/siginf.cpp
+++ b/xsec/tools/siginf/siginf.cpp
@@ -86,8 +86,8 @@ using std::ostream;
#include
#include
-XALAN_USING_XALAN(XPathEvaluator)
-XALAN_USING_XALAN(XalanTransformer)
+using xalanc::XPathEvaluator;
+using xalanc::XalanTransformer;
#else
--- a/xsec/tools/templatesign/templatesign.cpp
+++ b/xsec/tools/templatesign/templatesign.cpp
@@ -95,8 +95,8 @@
#include
#include
-XALAN_USING_XALAN(XPathEvaluator)
-XALAN_USING_XALAN(XalanTransformer)
+using xalanc::XPathEvaluator;
+using xalanc::XalanTransformer;
#endif
--- a/xsec/tools/txfmout/txfmout.cpp
+++ b/xsec/tools/txfmout/txfmout.cpp
@@ -84,8 +84,8 @@ using std::ofstream;
#include
#include
-XALAN_USING_XALAN(XPathEvaluator)
-XALAN_USING_XALAN(XalanTransformer)
+using xalanc::XPathEvaluator;
+using xalanc::XalanTransformer;
#else
--- a/xsec/tools/xklient/xklient.cpp
+++ b/xsec/tools/xklient/xklient.cpp
@@ -122,8 +122,8 @@ using std::ostream;
#include
#include
-XALAN_USING_XALAN(XPathEvaluator)
-XALAN_USING_XALAN(XalanTransformer)
+using xalanc::XPathEvaluator;
+using xalanc::XalanTransformer;
#endif
--- a/xsec/tools/xtest/xtest.cpp
+++ b/xsec/tools/xtest/xtest.cpp
@@ -63,8 +63,8 @@
#include
#include
-XALAN_USING_XALAN(XPathEvaluator)
-XALAN_USING_XALAN(XalanTransformer)
+using xalanc::XPathEvaluator;
+using xalanc::XalanTransformer;
#endif
--- a/xsec/transformers/TXFMXPath.cpp
+++ b/xsec/transformers/TXFMXPath.cpp
@@ -48,25 +48,25 @@
#endif
// Xalan namespace usage
-XALAN_USING_XALAN(XPathProcessorImpl)
-XALAN_USING_XALAN(XercesDOMSupport)
-XALAN_USING_XALAN(XercesParserLiaison)
-XALAN_USING_XALAN(XercesDocumentWrapper)
-XALAN_USING_XALAN(XercesWrapperNavigator)
-XALAN_USING_XALAN(XPathEvaluator)
-XALAN_USING_XALAN(XPathFactoryDefault)
-XALAN_USING_XALAN(XPathConstructionContextDefault)
-XALAN_USING_XALAN(XalanDocument)
-XALAN_USING_XALAN(XalanNode)
-XALAN_USING_XALAN(XalanDOMChar)
-XALAN_USING_XALAN(XPathEnvSupportDefault)
-XALAN_USING_XALAN(XObjectFactoryDefault)
-XALAN_USING_XALAN(XPathExecutionContextDefault)
-XALAN_USING_XALAN(ElementPrefixResolverProxy)
-XALAN_USING_XALAN(XPath)
-XALAN_USING_XALAN(NodeRefListBase)
-XALAN_USING_XALAN(XSLTResultTarget)
Bug#957758: restbed: ftbfs with GCC-10
[Matthias Klose] > /<>/source/corvusoft/restbed/response.cpp: In member function > ‘void restbed::Response::get_header(const string&, long long int&, long long > int) const’: > /<>/source/corvusoft/restbed/response.cpp:146:23: error: ISO C++ > forbids declaration of ‘invalid_argument’ with no type [-fpermissive] > 146 | catch ( const invalid_argument& ) > | ^~~~ Could it be that the code need to use std::invalid_argument? -- Happy hacking Petter Reinholdtsen
Bug#977462: Debian Edu sssd.conf conflicts with sssd service sockets
Hi Wolfgang, On Mi 16 Dez 2020 01:26:05 CET, Wolfgang Schweer wrote: [ Wolfgang Schweer, 2020-12-16 ] I'm just wondering if this is a Debian Edu specific bug at all. If /usr/share/sssd/generate-config is used to generate sssd.conf, the same messages are showing up upon reboot. Maybe the shipped script is outdated. After reading the logs twice, I noticed that maybe the only change needed is to comment the services line in /etc/sssd/sssd.conf. It seems that sssd switched to socket activation as default to reduce the amount of running services. (And services = x, y, z means that these services are running permanently, see the 'systemctl status sssd' output before and after commenting the services line. Also, see the information below /var/lib/sss/, e.g. pipes. Please test Wolfgang It seems the simplest fix for d-e-c would be to adapt sssd-generate-config in /usr/share/d-e-c/tools/. It is sufficient to omit the "services = pam, nss, autofs line from /etc/sssd/sssd.conf. Greets, Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgp0_cvVTYqGe.pgp Description: Digitale PGP-Signatur
Bug#976368: override: python2.7 and python-defaults binaries should be optional, not standard
control: tag -1 + moreinfo Hello, On Fri 04 Dec 2020 at 08:35AM +01, Matthias Klose wrote: > Package: ftp.debian.org > > python2.7 and python-defaults binaries should be optional, not standard. Just to be sure, do you mean all the binaries produced by these two source packages? -- Sean Whitton signature.asc Description: PGP signature
Bug#957499: logtools: diff for NMU version 0.13e+nmu1
Control: tags 957499 + patch Control: tags 957499 + pending -- Dear maintainer, I've prepared an NMU for logtools (versioned as 0.13e+nmu1) and uploaded it to DELAYED/2. Please feel free to tell me if I should cancel it. -- Regards Sudip diff -Nru logtools-0.13e/changes.txt logtools-0.13e+nmu1/changes.txt --- logtools-0.13e/changes.txt 2016-12-25 15:11:11.0 + +++ logtools-0.13e+nmu1/changes.txt 2020-12-16 20:22:13.0 + @@ -1,3 +1,11 @@ +logtools (0.13e+nmu1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix ftbfs with GCC-10. (Closes: #957499) +- Add the missing header files. + + -- Sudip Mukherjee Wed, 16 Dec 2020 20:22:13 + + logtools (0.13e) unstable; urgency=medium * Fixes build problems with latest STL. Closes: #849126 diff -Nru logtools-0.13e/clfdomainsplit.cpp logtools-0.13e+nmu1/clfdomainsplit.cpp --- logtools-0.13e/clfdomainsplit.cpp 2016-12-25 15:08:38.0 + +++ logtools-0.13e+nmu1/clfdomainsplit.cpp 2020-12-16 20:13:55.0 + @@ -6,6 +6,7 @@ #include #include #include +#include #include "logtools.h" using namespace std; diff -Nru logtools-0.13e/clfmerge.cpp logtools-0.13e+nmu1/clfmerge.cpp --- logtools-0.13e/clfmerge.cpp 2016-12-25 14:50:06.0 + +++ logtools-0.13e+nmu1/clfmerge.cpp2020-12-16 20:12:02.0 + @@ -5,6 +5,7 @@ #include #include #include +#include #include "logtools.h" diff -Nru logtools-0.13e/debian/changelog logtools-0.13e+nmu1/debian/changelog --- logtools-0.13e/debian/changelog 2016-12-25 15:11:11.0 + +++ logtools-0.13e+nmu1/debian/changelog2020-12-16 20:22:13.0 + @@ -1,3 +1,11 @@ +logtools (0.13e+nmu1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix ftbfs with GCC-10. (Closes: #957499) +- Add the missing header files. + + -- Sudip Mukherjee Wed, 16 Dec 2020 20:22:13 + + logtools (0.13e) unstable; urgency=medium * Fixes build problems with latest STL. Closes: #849126
Bug#865881: Adding ET to debian
Hi folks, It seems that the v6 branch has been completed and merged so the blocker of shell support has been resolved. Can we move forward with this package landing in debian? I would love to not have to use a 3rd party repo Thanks Dean
Bug#977567: ITP: jruby-utils-clojure -- A library for creating and interacting with a pool of JRuby instances in Clojure
Package: wnpp Severity: wishlist Owner: po...@debian.org * Package name : jruby-utils-clojure Version : 3.2.1 Upstream Author : Puppet Labs Inc * URL : https://github.com/puppetlabs/jruby-utils * License : Apache-2.0 Programming Lang: Clojure Description : A library for creating and interacting with a pool of JRuby instances in Clojure This package is a first-level dependency for puppetserver. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#977566: lollypop: Missing dependency on python3-cairo
Package: lollypop Version: 1.4.5-1 Severity: important Dear Maintainer, While installing lollypop on a system where python3-cairo is not installed, it fails to start with the following error message: Traceback (most recent call last): File "/usr/bin/lollypop", line 45, in from lollypop.application import Application File "/usr/lib/python3/dist-packages/lollypop/application.py", line 28, in from lollypop.utils import init_proxy_from_gnome File "/usr/lib/python3/dist-packages/lollypop/utils.py", line 19, in import cairo ModuleNotFoundError: No module named 'cairo' Suggestion is to add python3-cairo as dependency to fix this. Thanks for your work! Henry-Nicolas Tourneur -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-13-amd64 (SMP w/16 CPU threads) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages lollypop depends on: pn dconf-gsettings-backend | gsettings-backend pn gir1.2-gst-plugins-base-1.0 pn gir1.2-gstreamer-1.0 pn gir1.2-handy-1 pn gir1.2-secret-1 pn gir1.2-soup-2.4 pn gir1.2-totemplparser-1.0 pn libhandy-1-0 ii python3 3.9.0-4 pn python3-bs4 pn python3-gi pn python3-gst-1.0 pn python3-pil Versions of packages lollypop recommends: pn youtube-dl Versions of packages lollypop suggests: pn gstreamer1.0-libav
Bug#976402: Proposed official virtual packages - todo and todo.txt
On Wed, Dec 16, 2020 at 2:34 PM David Steele wrote: > > > On Wed, Dec 16, 2020 at 2:14 PM Sean Whitton > wrote: > >> >> Okay, and you expect every implementation of todo.txt to have >> tdtcleanup? I think we probably want to specify that as one of the (or >> the only?) requirements of the virtual package. >> > > No, no. > > The gtd stuff is an optional add-on to todo.txt. The requirements on > todo.txt to support these types of add-ons I listed earlier in the thread. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976402#98
Bug#977565: RFP: node-castv2 -- Chromecast CASTV2 protocol implementation
Package: wnpp Severity: wishlist * Package name: node-castv2 Version : 0.1.10 Upstream Author : Thibaut Séguy, James Sigurðarson * URL : https://github.com/thibauts/node-castv2 * License : Expat Programming Lang: JavaScript Description : Chromecast CASTV2 protocol implementation An implementation of the Chromecast CASTV2 protocol This module is an implementation of the Chromecast CASTV2 protocol over TLS. The module provides both a Client and a Server implementation of the low-level protocol. The server is (sadly) pretty useless because device authentication gets in the way for now (and maybe for good). The client still allows you to connect and exchange messages with a Chromecast dongle without any restriction. This module is a dependency of a Chromecast protocol bridge for fx_cast, an experimental Firefox casting extension.
Bug#977564: RFP: node-protobufjs -- pure JavaScript Protocol Buffers implementation
Package: wnpp Severity: wishlist * Package name: node-protobufjs Version : 6.10.2 Upstream Author : Daniel Wirtz * URL : https://github.com/dcodeio/protobuf.js * License : BSD 3-Clause Programming Lang: JavaScript Description : pure JavaScript Protocol Buffers implementation protobuf.js is a pure JavaScript Protocol Buffers implementation with TypeScript support for node.js and the browser. It is a dependency of node-castv2, an implementation of the Chromecast CASTV2 protocol.
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Matthew Vernon writes: > On 14/12/2020 21:56, Philip Hands wrote: > >> Could I just check if there's a point of common acceptability which both >> sides of this discussion could live with? > > [...] > >> My suggestion for a mutually bearable solution would be that the >> network-manager package could have its dependency on libpam-systemd >> changed to instead be something like: >> >>libpam-systemd | network-manager-nonsystemd > > Is this instead of the logind virtual package? I'm not quite sure what > problem you're trying to solve here, but I'm don't think it generalises > well (you'd end up with potentially lots of package that just Depend on > logind and maybe contain an init script); and without any input from the > network-manager maintainer about why they were unwilling to take the > patch to use the existing virtual package, I'm not sure why this should > be more acceptable. If that were the way things were going, then I'd expect one to end up with a package that bundled all the init scripts, and provided whatever virtual packages etc. required to glue all the bits together somehow. The details of how to do that seemed like things that should be between the people maintaining the two sets of packages, and I wasn't worrying about the details too much, because I was rather hoping that it wouldn't actually be needed. >> If you think this approach is impractical for some reason, please say >> so, because what I have in mind as a better option does rather rely on >> this being available as a plausible fall-back position. > > I'm confused as to why you don't just tell us what your better option is. My better option was that having defined the areas of responsibility by thinking about who'd do what in a split package setup, we might manage to agree that the same people could take the same responsibility for maintaining those bits in the places where they would need to be in the packages as they stand. For that to work, I think the maintainer would have to have the right to declare that they didn't think the experiment was working out (presumably because of drowning in bugs that were not being handled in a sensible time, say) at which point the already agreed split package setup would provide an acceptable plan B. That would hopefully allow the maintainer to relax enough about having some new people co-maintaining some fragments of the package to give space for everyone to demonstrate that it was possible for them to work together. There's nothing specific to NM in any of that BTW, so if other packages are in this position where constructive cooperation really ought to work, but there's just a little too much distrust at present, then maybe you can give this a try there. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#977563: please package 0.30.0
Package: yapf Version: 0.29.0-1 Severity: important Control: block 975535 by -1 Hi, Please package 0.30.0. This missing dependency blocks updating Elpy to the latest upstream version which is necessary to solve the Python 3.9 ftbfs. I've taken the liberty to update the package in git, because it is under Debian Python Team namespace, and the only outstanding issues I'm aware of are resolving #944241 and ensuring compliance with Policy 4.5.1. Thank you, Nicholas
Bug#977469: matplotlib: Please make package bootstrappable
Hello! On 12/15/20 1:44 PM, John Paul Adrian Glaubitz wrote: > Could you make matplotlib bootstrappable so that porters can bootstrap the > package when it's necessary? It seems that most of the Python dependencies in Build-Depends in debian/control are optional when comparing those with the build dependencies in openSUSE [1]. I used the brute-force approach now and it built for me on powerpc with those packages set to : python3-all-dbg, python3-all-dev, python3-cairocffi [!ia64] , python3-certifi (>= 2020.6.20-1) , python3-colorspacious , python3-cxx-dev , python3-cycler (>= 0.10.0) , python3-dateutil , python3-gi , python3-ipython , python3-ipywidgets , python3-kiwisolver , python3-kiwisolver-dbg , python3-mock , python3-nose , python3-numpy , python3-numpy-dbg , python3-numpydoc , python3-pandas , python3-pil , python3-pkg-resources , python3-pyparsing (>= 1.5.6) , python3-pyqt5 [!hurd-i386] , python3-pytest , python3-scipy , python3-setuptools, python3-six (>= 1.4) , python3-sphinx , python3-sphinx-copybutton , python3-sphinxcontrib.svg2pdfconverter , python3-tk , python3-tk-dbg , python3-tornado , Adrian > [1] > https://build.opensuse.org/package/view_file/devel:languages:python:numeric/python-matplotlib/python-matplotlib.spec?expand=1 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#976402: Proposed official virtual packages - todo and todo.txt
On Wed, Dec 16, 2020 at 2:14 PM Sean Whitton wrote: > > Okay, and you expect every implementation of todo.txt to have > tdtcleanup? I think we probably want to specify that as one of the (or > the only?) requirements of the virtual package. > No, no. The gtd stuff is an optional add-on to todo.txt. The requirements on todo.txt to support these types of add-ons I listed earlier in the thread.
Bug#975943: Patch
Control: tag -1 patch Just submitted a MR which fixes this issue: https://salsa.debian.org/debian/raspi-firmware/-/merge_requests/18 signature.asc Description: This is a digitally signed message part.
Bug#687179: dak: Please ignore packages with empty arch keys from Package-List
Control: tag -1 + moreinfo On Sat, 2 Mar 2019 13:15:12 +0100 Guillem Jover wrote: > On Mon, 2012-09-10 at 17:46:26 +0200, Andreas Beckmann wrote: > > the changes file generated by dpkg-genchanges includes in its Binary > > field packages that have been intentionally disabled by setting an empty > > Architecture field. Using an empty "Architecture" field for this purpose feels like a hack. Wouldn't specify a "Build-Profiles: " be a better solution? dak didn't handle positive lists well, but that should be fixed ([1] is pending). So shouldn't one use this and possible make an empty "Architecture" field a bug instead? (I notice the original bug is from 2012 where Build-Profiles might not have existed and the missing support in dak also made it not very nice to use.) Ansgar [1]: https://bugs.debian.org/913965
Bug#977561: osmo-hlr: reproducible builds: Example Makefile contains variable build paths and binary paths
Source: osmo-hlr
Version: 1.7.0+dfsg1-2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath usrmerge shell
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
The included file /usr/share/doc/osmo-hlr/examples/Makefile contains
various paths dependent on the build environment:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/osmo-hlr.html
154 ACLOCAL·=·${SHELL}·'/build/1st/osmo-hlr-1.2.0+dfsg1/missing'·aclocal-1.16
154
ACLOCAL·=·${SHELL}·'/build/2/osmo-hlr-1.2.0+dfsg1/2nd/missing'·aclocal-1.16
176 EGREP·=·/bin/grep·-E
176 EGREP·=·/usr/bin/grep·-E
The attached patch fixes this by removing the Makefile from the package,
while preserving the Makefile.in and Makefile.am files needed to
regenerate the Makefile should the user wish to use it.
Thanks for maintaining osmo-hlr!
live well,
vagrant
From 5c565cc9d173b988f3f0e47591c3e3251454da31 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Wed, 16 Dec 2020 19:07:33 +
Subject: [PATCH] debian/rules: Remove example Makefile.
The Makefile contains information specific to the build environment
such as build paths and paths to specific binaries. Remove it as it
would need to be regenerated on the end user system in order to be
used.
---
debian/rules | 4
1 file changed, 4 insertions(+)
diff --git a/debian/rules b/debian/rules
index 6a206cc..cf98b80 100755
--- a/debian/rules
+++ b/debian/rules
@@ -24,3 +24,7 @@ override_dh_clean:
override_dh_installsystemd:
dh_installsystemd --no-enable --no-start
+
+override_dh_installexamples:
+ dh_installexamples
+ rm -f debian/osmo-hlr/usr/share/doc/osmo-hlr/examples/Makefile
--
2.29.2
signature.asc
Description: PGP signature
Bug#976402: Proposed official virtual packages - todo and todo.txt
Hello, On Wed 16 Dec 2020 at 10:02AM -05, David Steele wrote: > Imagine that tdtcleanup is a pre/post hook in todo.txt-base. An > implementation of todo.txt is needed > to make use of it. Okay, and you expect every implementation of todo.txt to have tdtcleanup? I think we probably want to specify that as one of the (or the only?) requirements of the virtual package. -- Sean Whitton signature.asc Description: PGP signature
Bug#977560: dwz fails with .debug_line reference above end of section
Package: gcc-10 Version: 10.2.1-1 Severity: normal Affects: src:globus-rsl I recently updates some packages I maintain to compat level 13. Since they previously were on compat level 10, this meant that the dh_dwz that was added to the default sequence is now run for these packages. For most packages this did not create a problem. But for one of the packages the dh_dwz failed miserably. In the update for this package I added an empty override_dh_dwz rule to work around the problem. I don't know it the problem is with gcc producing broken debug information that is correctly rejected by dwz, or if it is dwz that fails to parse valid debug information generated by gcc. Please reassign the bug if appropriate. Steps to reproduce: Download affected package: $ dget https://deb.debian.org/debian/pool/main/g/globus-rsl/globus-rsl_11.2-1.dsc Enter the directory: $ cd globus-rsl-11.2 Edit the debian/rules file. Comment out the empty override_dh_dwz rule. $ emacs debian/rules Then build the package: $ dpkg-buildpackage The build ends in a failure: dh_dwz -a dwz: debian/libglobus-rsl2/usr/lib/debug/.dwz/x86_64-linux- gnu/libglobus-rsl2.debug: .debug_line reference above end of section dh_dwz: error: dwz -mdebian/libglobus-rsl2/usr/lib/debug/.dwz/x86_64- linux-gnu/libglobus-rsl2.debug -M/usr/lib/debug/.dwz/x86_64-linux- gnu/libglobus-rsl2.debug -- debian/libglobus-rsl2/usr/lib/x86_64-linux- gnu/libglobus_rsl.so.2.9.2 debian/libglobus-rsl2/usr/lib/x86_64-linux- gnu/libglobus_rsl_assist.so.2.9.2 returned exit code 1 make: *** [debian/rules:13: binary] Fel 1 dpkg-buildpackage: fel: fakeroot debian/rules binary subprocess returned exit status 2 $ dpkg-query -W gcc gcc-10 dwz binutils binutils2.35.1-4 dwz 0.13+20201015-2 gcc 4:10.2.0-1 gcc-10 10.2.1-1 signature.asc Description: This is a digitally signed message part
Bug#977559: Munipack fails unit test on arm 64 bit on Debian
Package: munipack Version: 0.5.12-1 Dear Filip, I just discovered that munipack is blocked from entering Debian testing because the unit tests fail on the arm 64 bit platform. The relevant log lines are: autopkgtest [05:10:58]: test check.sh: [--- FITSIO status = 307: bad first row number Attempted to read from group 4294967296 of the HDU, however the HDU only contains 1 group(s). STOP Some error(s) occurred during this star FIND. Error: Execution failed (consider re-run with --verbose). barnard-calibrated.fits: Failed to read data. FITSIO status = 307: bad first row number Attempted to read from group 4294967296 of the HDU, however the HDU only contains 1 group(s). STOP Some error(s) occurred during this APHOT run. Error: Execution failed (consider re-run with --verbose). FITSIO status = 307: bad first row number Attempt to read past end of table: Table has 31 rows with 1 elements per row; Tried to read 21474836511 elements starting at row 1, element 1. STOP Failed to open the catalogue file. Error: Execution failed (consider re-run with --verbose). FITSIO status = 308: bad first element number First element to write is too large: 4294967297; max allowed value is 1 STOP Failed to read a catalogue. Error: Execution failed (consider re-run with --verbose). autopkgtest [05:10:59]: test check.sh: ---] autopkgtest [05:10:59]: test check.sh: - - - - - - - - - - results - - - - - - - - - - check.sh FAIL non-zero exit status 9 Full log is here: https://ci.debian.net/data/autopkgtest/testing/arm64/m/munipack/8535450/log.gz Do you have an idea what happens there? Best regards Ole
Bug#892058: Your Debian key is expiring
Hi, On Sat, Dec 12, 2020 at 09:23:11PM -0800, Felix Lechner wrote: > Dear Antonio, > > This is a courtesy reminder that your Debian key is expiring on 2021-02-01. > > Debian does not synchronize its keyring with other public key servers. > You have to upload your key manually after extending the expiration > date. For more information, please check out the instructions. [1] > > This is your GPG key ID: > > FC0DB1BBCD460BDE > > Please keep in mind that the Debian folks in charge of the keyring > update it only once a month. That usually happens on the 24th of each > month. It it just a few days away. Yes, this service is very useful. I always set my key to expire on Feb 1st, and renew it on December of the previous year. I usually set a reminder in my calendar, but this year I failed to do that. :) Even when I don't fail to set a reminder, this is important enough that some reduncancy is useful. OTOH it would be nice for people to be able to opt out, though. signature.asc Description: PGP signature
Bug#977558: python-jedi: please package 0.17.2
Package: python-jedi Version: 0.17.0-1 Severity: important Control: block 975535 by -1 Hi, Please package 0.17.2. This missing dependency blocks updating Elpy to the latest upstream version which is necessary to solve the Python 3.9 ftbfs. Thank you, Nicholas
Bug#977557: ITP: pathetic-clojure -- Simple unix-style path manipulation
Package: wnpp Severity: wishlist Owner: po...@debian.org * Package name : pathetic-clojure Version : 0.5.1 Upstream Author : David Santiago * URL : https://github.com/davidsantiago/pathetic * License : EPL-1.0 Programming Lang: Clojure Description : Simple unix-style path manipulation pathetic provides a small number of functions meant to ease the manipulation of file paths. For example, it provides functions to normalize (remove superfluous or roundabout path components, like . and ..), relativize (transform one path to be relative to another), and resolve (add path components to an existing path) paths. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
Hi Emmanuel, On 16-12-2020 16:47, Emmanuel Bourg wrote: > Hi Paul > > Le 15/12/2020 à 20:49, Paul Gevers a écrit : > >> Unfortunately, there hasn't been any activity on this bug accept for bug >> manipulation. rhino is a key package, so is not going to be autoremoved. >> Let's fix this before the first freeze hits. > > Do you know what version of Rhino does dojo use upstream? I have no clue what dojo is or does. Let alone I know it's upstream. Sorry I can't help there. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#976102: a2ps 32-bit segfaults on startup
Am 15.12.20 um 23:00 schrieb Mack Stanley: Dear Bernhard, Thanks so much for your interest and your message. I very recently realized that my bug report is in error and hoped that I would be able to correct or withdraw it before troubling anyone. Here is how to reproduce the segfault I observed (in wither 32 or 64 bit debian a2ps): Near the top of /etc/a2ps-site.cfg comment out one or both of the lines _ Options: --encoding=latin1 Options: --medium=libpaper _ Then just execute a2ps The result will be a crash with simply Segmentation Fault --- I am very sorry to have filed a false bug report. I had tried two 32 bit installations and one 64 bit. Evidently I made the same mistake in both 32 bit installations: I must have installed with an old Fedora a2ps-site.cfg already in /etc/ , which the Debian installation politely refused to overwrite. The default Fedora a2ps-site.cfg has those two lines as #Options: --encoding=latin1 Options: --medium=_glibc After removing "#" from the first line, the debian build a2ps complains helpfully about the second line. But with the "#" it just segfaults. I am sorry it took me so long to find this mistake. It wasn't till I built 32 bit a2ps from the GNU source that I saw the problem (http://ftp.gnu.org/gnu/a2ps/a2ps-4.14.tar.gz./configure --prefix=/usr --with-gnu-gettext --with-medium=letter ). It would be nice if a2ps itself had been more forthcoming about my mistake rather than segfaulting. But it was just that---my mistake. Again, my apologies for wasting your time and my thanks for your interest. Best regards, Mack Hello Mack, no problem, with these great details I could collect these backtraces: # With: #Options: --encoding=latin1 (gdb) bt #0 __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:50 #1 0x0050bfcc in strlower (string=0x0) at routines.c:95 #2 0x005096cd in get_encoding_by_alias (job=0x57bc50, alias=0x0) at encoding.c:1207 #3 0x0050aa50 in a2ps_job_finalize (job=0x57bc50) at jobs.c:305 #4 0x004ef980 in main (argc=, argv=) at main.c:1025 (gdb) # With: #Options: --medium=libpaper (gdb) bt #0 __strcasecmp_l_sse4_2 () at ../sysdeps/i386/i686/multiarch/strcmp-sse4.S:229 #1 0x0050e22a in a2ps_get_medium (job=0xb1ec50, name=0x0) at media.c:164 #2 0x0050ea6c in a2ps_job_finalize (job=0xb1ec50) at jobs.c:312 #3 0x004f3980 in main (argc=, argv=) at main.c:1025 (gdb) As you mentioned some relation to fedora I made a short search and it looks like there are some patches used, which are not yet upstreamed. https://src.fedoraproject.org/rpms/a2ps/tree/ https://git.savannah.gnu.org/cgit/a2ps.git/log/ Especially the a2ps-4.13b-encoding.patch and a2ps-4.13-glibcpaper.patch seem related. Kind regards, Bernhard apt install systemd-coredump gdb a2ps a2ps-dbgsym zcat /usr/share/doc/a2ps/README.gz | a2ps coredumpctl list coredumpctl gdb 2478 https://sources.debian.org/src/a2ps/1:4.14-5/lib/jobs.c/#L305
Bug#724931: ISO images need loop.ko and iso-scan
Hi! It's the end of 2020 and we still need initrd from hd-media if we wont to loopback-mount ISO file during install. Why not to include iso-scan into netinst and other cd images? Best regards, Aleksei Shargalin
Bug#977555: RM: mariadb-10.3 -- RoM; obsoleted by mariadb-10.5
Control: retitle -1 RM: mariadb-10.3/experimental -- RoM; obsoleted by mariadb-10.5 On Wed, Dec 16, 2020 at 07:57:52PM +0200, Otto Kekäläinen wrote: > Please remove src:mariadb-10.3 from experimental. Please consider using reportbug so that you get the right text in the subject… -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#957996: xppaut: diff for NMU version 6.11b+1.dfsg-1.1
Control: tags 957996 + patch Control: tags 957996 + pending -- Dear maintainer, I've prepared an NMU for xppaut (versioned as 6.11b+1.dfsg-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should cancel it. -- Regards Sudip diff -Nru xppaut-6.11b+1.dfsg/debian/changelog xppaut-6.11b+1.dfsg/debian/changelog --- xppaut-6.11b+1.dfsg/debian/changelog2012-02-13 03:23:30.0 + +++ xppaut-6.11b+1.dfsg/debian/changelog2020-12-16 18:12:16.0 + @@ -1,3 +1,10 @@ +xppaut (6.11b+1.dfsg-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix ftbfs with GCC-10. (Closes: #957996) + + -- Sudip Mukherjee Wed, 16 Dec 2020 18:12:16 + + xppaut (6.11b+1.dfsg-1) unstable; urgency=low [ Jakub Nowacki ] diff -Nru xppaut-6.11b+1.dfsg/debian/patches/fix_gcc-10.patch xppaut-6.11b+1.dfsg/debian/patches/fix_gcc-10.patch --- xppaut-6.11b+1.dfsg/debian/patches/fix_gcc-10.patch 1970-01-01 01:00:00.0 +0100 +++ xppaut-6.11b+1.dfsg/debian/patches/fix_gcc-10.patch 2020-12-16 18:11:49.0 + @@ -0,0 +1,21 @@ +Description: Fix ftbfs with GCC-10 + + Use -fcommon with CFLAGS + +Author: Sudip Mukherjee +Bug-Debian: https://bugs.debian.org/957996 +Forwarded: no + +--- + +--- xppaut-6.11b+1.dfsg.orig/Makefile xppaut-6.11b+1.dfsg/Makefile +@@ -36,7 +36,7 @@ AUTLIBS= -lm + #CFLAGS= -g -O -m32 -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=$(MAJORVER) -DMYSTR2=$(MINORVER) -I/usr/X11R6/include + #CFLAGS= -g -O -m64 -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=$(MAJORVER) -DMYSTR2=$(MINORVER) -I/usr/include/X11 + +-CFLAGS = -g -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=$(MAJORVER) -DMYSTR2=$(MINORVER) -I/usr/include/X11 ++CFLAGS = -g -pedantic -fcommon -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=$(MAJORVER) -DMYSTR2=$(MINORVER) -I/usr/include/X11 + #LDFLAGS= -m64 -L/usr/lib -L/usr/lib64 + LDFLAGS= -L/usr/lib + LIBS= -lX11 -lm -ldl diff -Nru xppaut-6.11b+1.dfsg/debian/patches/series xppaut-6.11b+1.dfsg/debian/patches/series --- xppaut-6.11b+1.dfsg/debian/patches/series 2012-02-13 03:23:30.0 + +++ xppaut-6.11b+1.dfsg/debian/patches/series 2020-12-16 18:10:37.0 + @@ -1,2 +1,3 @@ 010_makefile.diff 040_menudrive_c.diff +fix_gcc-10.patch
Bug#977555: RM: mariadb-10.3 -- RoM; obsoleted by mariadb-10.5
Package: ftp.debian.org Severity: normal Hi, Please remove src:mariadb-10.3 from experimental. MariaDB 10.3 has been replaced by MariaDB 10.5 and 10.3 was already removed from unstable and testing. The version in experimental will never be used and is obsolete. Related: Bug#977254
Bug#977462: Debian Edu sssd.conf conflicts with sssd service sockets
[ Wolfgang Schweer, 2020-12-16 ] > After reading man 5 sssd.conf, some other cleanup should be done: > - remove obsolete / wrong settings > - drop default settings > > About to test the changes... Revised sssd-generate-config script tested both inside Debian Edu network and outside. Works like it should. This is the diff: diff --git a/share/debian-edu-config/tools/sssd-generate-config b/share/debian-edu-config/tools/sssd-generate-config index 031c77a1..1af98791 100755 --- a/share/debian-edu-config/tools/sssd-generate-config +++ b/share/debian-edu-config/tools/sssd-generate-config @@ -109,20 +109,11 @@ cat < signature.asc Description: PGP signature
Bug#977556: libbellesip-dev: Missing dependency on libbctoolbox-dev
Package: libbellesip-dev Version: 1.6.3-5 Severity: important Hi! This package contains header files that further include header files from libbctoolbox-dev, but that's an implementation detail, so users of this package should not need to know that they need to depend on that other package. Please add libbctoolbox-dev into libbellesip-dev Depends, for both the versions in sid and experimental. :) Thanks, Guillem
Bug#975169: litecoin: FTBFS: qt/trafficgraphwidget.cpp:55:9: error: invalid use of incomplete type ‘class QPainterPath’
Dear Maintainer, after adding #include in qt/trafficgraphwidget.cpp, litecoin builds fine in a pbuilder sid chroot. Kind Regards
Bug#977554: lintian: fpos alternates-not-allowed
Package: lintian Version: 2.104.0 Severity: important against dehydrated 0.7.0-1 (which is about to be uploaded): + su -c lintian -EIi --pedantic --color always --no-tag-display-limit --suppress-tags upstream-metadata-file-is-missing /build/*.changes; : - pbuilder su: warning: cannot change directory to /nonexistent: No such file or directory Warning in group dehydrated/0.7.0-1: Use of uninitialized value in string eq at /usr/share/lintian/checks/fields/package-relations.pm line 129. [... many lines like that ...] E: dehydrated-apache2: alternates-not-allowed Recommends N: E: alternates-not-allowed N: N: Only the "Depends", "Recommends", "Suggests" and "Pre-Depends" fields N: may specify alternate dependencies using the "|" symbol. N: N: Refer to Debian Policy Manual section 7.1 (Syntax of relationship N: fields) for details. N: N: Severity: error N: N: Check: fields/package-relations N: N: 1 hint overridden (1 warning) The binary has this: dehydrated-apache2_0.7.0-1_all.deb -- Package: dehydrated-apache2 Source: dehydrated Version: 0.7.0-1 Architecture: all Maintainer: Debian Let's Encrypt Team Installed-Size: 25 Recommends: dehydrated, apache2 (>= 2.4.6-4~) | httpd Section: misc Priority: optional It's my understanding that "apache2 (>= 2.4.6-4~) | httpd" is legal in Recommends, and the extended tag description also seems to say so. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#977553: embree: reproducible builds: Embedded timestamps in PDF files
Source: embree Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org The build timestamp is embedded in /usr/share/doc/embree3/readme.pdf.gz: https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/embree.html 4 December·4,·2020 4 January·8,·2022 The attached patch fixes this by setting FORCE_SOURCE_DATE=1 in debian/rules, which texlive needs in order to respect SOURCE_DATE_EPOCH, which is set during debian package builds to the timestamp in the latest debian/changelog entry. https://reproducible-builds.org/docs/source-date-epoch/ While this doesn't fix all reproducibility issues in embree (e.g. build paths), it should be reproducible once it lands in bullseye, which does not vary build paths in the reproducible builds test infrastructure. Thanks for maintaining embree! live well, vagrant From 8ca18e76ec83a4c79dfba4263f1dd1f06ab90da9 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Wed, 16 Dec 2020 17:32:25 + Subject: [PATCH] debian/rules: Set FORCE_SOURCE_DATE=1 in order for texlive to respect SOURCE_DATE_EPOCH for reproducible timestamps. https://reproducible-builds.org/docs/source-date-epoch/ --- debian/rules | 3 +++ 1 file changed, 3 insertions(+) diff --git a/debian/rules b/debian/rules index 7a3959f..bd88c72 100755 --- a/debian/rules +++ b/debian/rules @@ -2,6 +2,9 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all +# Needed for texlive to respect SOURCE_DATE_EPOCH when setting date +export FORCE_SOURCE_DATE=1 + INSTDIR=debian/tmp %: -- 2.20.1 signature.asc Description: PGP signature
Bug#977552: gnutls28: Time bomb in testpkcs11.sh triggered
Source: gnutls28 Version: 3.6.15-1 Severity: serious Tags: upstream ftbfs Justification: fails to build from source Forwarded: https://gitlab.com/gnutls/gnutls/-/issues/1135 autopkgtests and build fail now due to an expired certificate Not After : Dec 13 08:24:54 2020 GMT cu Andreas
Bug#977462: Debian Edu sssd.conf conflicts with sssd service sockets
Moin Mike, [ Mike Gabriel, 2020-12-16 ] > It seems the simplest fix for d-e-c would be to adapt sssd-generate-config > in /usr/share/d-e-c/tools/. yes. > It is sufficient to omit the "services = pam, nss, autofs line from > /etc/sssd/sssd.conf. yes. After reading man 5 sssd.conf, some other cleanup should be done: - remove obsolete / wrong settings - drop default settings About to test the changes... Wolfgang signature.asc Description: PGP signature
Bug#976915: service-wrapper-java: FTBFS on ppc64el: [exec] wrapper.c:(.text+0x3598): undefined reference to `pow'
On Wed, Dec 16, 2020 at 04:43:55PM +0100, Emmanuel Bourg wrote: > Le 13/12/2020 à 00:38, Markus Koschany a écrit : > > > In this case I believe the RC severity is correct because the arch:any or > > jni > > version of the package FTBFS on ppc64el. We should try to fix the problem on > > ppc64el or, if upstream doesn't support ppc64el, remove the architecture > > from > > the list of supported architectures in debian/control. > > As a side note, if we keep getting issues with service-wrapper-java I > wonder if we could scrap it, systemd is now able to provide similar > auto-restart features for services. Good idea. The only r-dep I see is i2p, and the popcon graphs [2,3] appear to match pretty closely. I am adding mha...@debian.org to the thread. Perhaps we can update i2p and and drop service-wrapper from bullseye. Cheers, tony [1] https://tracker.debian.org/pkg/i2p [2] https://qa.debian.org/popcon.php?package=service-wrapper-java [3] https://qa.debian.org/popcon.php?package=i2p signature.asc Description: PGP signature
Bug#892001: ITP: dbus-broker -- Linux D-Bus Message Broker
On Wed, 2020-12-16 at 14:48 +0100, Daniele Nicolodi wrote: > Hi Luca, > > On 13/12/2020 23:33, Luca Boccassi wrote: > > Hi, > > > > I have updated the package and done several changes, and unless there > > are objections I intend to upload to experimental/NEW in a couple of > > days. I'll start by grabbing the ITP. Repository: > > > > https://salsa.debian.org/bluca/dbus-broker > > > > I've also done some work on src:dbus to split out config and tools, > > like it's done in Fedora/RHEL and Yocto. MR on Salsa: > > > > https://salsa.debian.org/utopia-team/dbus/-/merge_requests/8 > > > > Thanks for starting the work on this! I'm of course very happy to work > > together and be both uploaders if you'd like to work on this as well > > going forward. Just let me know and I'll list you and add you to the > > shared repository once it's created. > > Thank you for picking this up. I don't think I'll have much to > contribute to the package in the future. Feel free to take full > ownership of it. > > Just a note: the Vcs- fields in debian/control point to a repository in > the debian team that not yet exist and the discussion on the dbus MR > seems to suggest that the repository for the dbus-broker package should > live in the utopia-team group anyway. > > Cheers, > Dan Yeah was waiting for a conclusion before changing and uploading. Simon, would you like this in utopia-team then? If so, could you please create a dbus-broker repo and give me push access? I'd like to upload to experimental before the end of the week, so that it can go through NEW. Will not upload to unstable until we are all happy, and possibly the dbus package split is agreed if not uploaded. But the current status should be good enough for experimental. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#973537: ausweisapp2: Backporting 1.20.2-1 to buster requires small patch
Hi Frank! On 12/16/20 11:10 AM, John Paul Adrian Glaubitz wrote: > Sorry for the delays. I haven't had the time to work on that yet. I am > planning > to do this over Christmas, my vacation begins on Monday. Currently I'm still > busy with regular work. > > If it hasn't happened in two weeks, please ping me again. Here's a preliminary package for testing [1]. Let me know if that works for you. I tested it myself in a Debian Buster virtual machine and it ran fine, but I couldn't test the card reader as the VM was running on a remote server. Adrian > [1] https://people.debian.org/~glaubitz/ausweisapp2-bpo/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#862887: 14 tests fail gulp
Control: fixed -1 4.0.2-1 On Fri, 31 May 2019 17:14:12 +0530 Pirate Praveen wrote: > I'm updating gulp to 4.x and planning to upload it to experimental soon. > > I have updated node-vinyl-fs in experimental and glob-watcher is > embedded. The tests are still failing. Fixed in an earlier upload.
Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures
Hello Peter,
Am 16.12.20 um 11:08 schrieb Peter Palfrader:
Hi Bernhard!
Can you try to rebuild tor with __attribute__((aligned(8))) for the
keccak_state as suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977#44
and then let us know if the issue is still there?
I rebuilt the tor package with this change [1] below (I hope I
placed it correctly).
With this I found "disassemble /r keccak_finalize" produces the
exact same instructions, but now the pointer given to keccak_finalize
seems to be aligned at a 8 byte boundary.
Now the strd placed at armv5tel the same sequence as
on armv7 to the "a" member [3].
And I guess hostname contains now the expected value:
$ cat hs/hostname
upxkcswnvepfls7vcy5vuixy54hlugfjnzhvl5ygfbjtm7znkyahcvad.onion
Kind regards,
Bernhard
[1]
diff --git a/src/ext/keccak-tiny/keccak-tiny.h
b/src/ext/keccak-tiny/keccak-tiny.h
index a9c8ed6..dd26386 100644
--- a/src/ext/keccak-tiny/keccak-tiny.h
+++ b/src/ext/keccak-tiny/keccak-tiny.h
@@ -21,7 +21,7 @@ typedef struct keccak_state {
size_t offset;
uint8_t finalized : 1;
-} keccak_state;
+} __attribute__((aligned(8))) keccak_state;
/* Initialize a Keccak instance suitable for SHA-3 hash functions. */
int keccak_digest_init(keccak_state *s, size_t bits);
[2]
(gdb) bt
#0 0x005c4ac4 in xorin8 (len=136, src=, dst=) at
../src/ext/keccak-tiny/keccak-tiny-unrolled.c:21
#1 keccak_finalize (s=s@entry=0xbeffef98) at
../src/ext/keccak-tiny/keccak-tiny-unrolled.c:189
[3]
(gdb) stepi
0x005c4ac0 21return _le64toh(r);
1: x/i $pc
=> 0x5c4ac0 : strdr2, [r4]
(gdb) x/8xb &((keccak_state *) 0xbeffef98)->a
0xbeffef98: 0x000x000x000x000x000x000x000x00
(gdb) stepi
0x005c4ac4 21return _le64toh(r);
1: x/i $pc
=> 0x5c4ac4 : bhi 0x5c4a90
(gdb) x/8xb &((keccak_state *) 0xbeffef98)->a
0xbeffef98: 0x2e0x6f0x6e0x690x6f0x6e0x200x63
(gdb) display/x $r2
2: /x $r2 = 0x696e6f2e
(gdb) display/x $r4
3: /x $r4 = 0xbeffef98
Bug#966184: xfractint: diff for NMU version 20.4.10-2.1
Control: tags 966184 + patch Control: tags 966184 + pending -- Dear maintainer, I've prepared an NMU for xfractint (versioned as 20.4.10-2.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should cancel it. -- Regards Sudip diff -u xfractint-20.4.10/debian/changelog xfractint-20.4.10/debian/changelog --- xfractint-20.4.10/debian/changelog +++ xfractint-20.4.10/debian/changelog @@ -1,3 +1,11 @@ +xfractint (20.4.10-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with GCC 10. (Closes: #966184) +- Use -fcommon with CFLAGS. + + -- Sudip Mukherjee Wed, 16 Dec 2020 17:16:36 + + xfractint (20.4.10-2) unstable; urgency=low * replace/conflict with fractxtra. Closes: #604975 only in patch2: unchanged: --- xfractint-20.4.10.orig/Makefile +++ xfractint-20.4.10/Makefile @@ -118,7 +118,7 @@ ifeq ($(AS),/usr/bin/nasm) -CFLAGS = -I$(HFD) $(DEFINES) -g -DBIG_ANSI_C -DLINUX -DNASM -fno-builtin +CFLAGS = -I$(HFD) $(DEFINES) -g -DBIG_ANSI_C -DLINUX -DNASM -fno-builtin -fcommon #CFLAGS = -I. -D_CONST $(DEFINES) #CFLAGS = -I$(HFD) $(DEFINES) -g -DBIG_ANSI_C -DLINUX \ # -march=$(ARCH) -DNASM -fno-builtin @@ -126,7 +126,7 @@ else -CFLAGS = -I$(HFD) $(DEFINES) -g -DBIG_ANSI_C -DLINUX -fno-builtin +CFLAGS = -I$(HFD) $(DEFINES) -g -DBIG_ANSI_C -DLINUX -fno-builtin -fcommon #CFLAGS = -I$(HFD) $(DEFINES) -g -DBIG_ANSI_C -DLINUX \ # -march=$(ARCH) -fno-builtin #CFLAGS = -I. $(DEFINES) -g -DBIG_ANSI_C -DLINUX -Os -fno-builtin
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On Wed, 2020-12-16 at 14:46 +, Matthew Vernon wrote: Not is it straightforwardly clear that "alternative init systems" should in fact be interpreted to mean "alternative init systems (but not sysvinit)". The GR text mostly seems to talk about *exploring* alternatives; continuing to maintain a 30 year old system doesn't really seem explorative work to me? Even retiring sysvinit support completely seems fine with the GR's text. Besides preserving sysvinit in its current state (arguably not exploration), not much else seems to happen with regard to alternatives to systemd as far as I am aware? For exploration, much less support is needed: to install systemd-sysv you had to fight with dpkg to uninstall / keep away an essential package (sysvinit) for several years or choose alternative routes (e.g. specify init= on the kernel command-line); you might have needed to write .service units yourself to start services using systemd's native facilities instead of a (limited, but well-working) compatibility layer. I still have some custom .service units for packages that don't ship one themselves. Arguably having to create "fake" packages using `equivs` or similar tools to satisfy dependencies one would like to force to be avoided would be comparable to having to remove essential packages? Not having all packages ship a sysvinit script must also be more or less expected: we have 250+ packages shipping .service files, but no sysvinit scripts in current testing. I already filtered out any packages shipping DBus .service files and some packages part of the systemd/sysvinit implementation itself for this, but there are some other false postives like .timer units with their associated .service unit that have equivalent cronjobs (though some might miss a cronjob as well). For comparison: 980 packages in total have any .service system units and 1057 have a sysvinit script (excluding the packages part of systemd/sysvinit itself.) In addition some package use other systemd-provided facilities that elogind conflicts with, e.g., systemd-tmpfiles; or systemd-hostnamed here for NM (AFAIU). As you already said you would like the technical committee to rule that similar changes should not be blocked by maintainer of other packages and already said you have some packages in mind, I think it would be interesting to know which ones you are talking about. Would maintainers have to accept patches stopping use of systemd-tmpfiles, systemd-hostnamed, ...? Ansgar
Bug#977535: [Pkg-javascript-devel] Bug#977535: Bug#977535: Bug#977535: Bug#977535: pkg-js-tools should create node_modules symlink in autopkgtest
On 2020, ഡിസംബർ 16 8:28:01 PM IST, Xavier wrote: > >autopkgtest will be fixed with node-tape migration > Thanks for the fix. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#976638: Fixed in 108-9
Hi! Just upgraded with the new testing package, and it builds OK. Thanks.
Bug#977551: gprbuild's autopkg tests fail
Package: src:gprbuild Version: 2021.0.0.0778b109-3 Severity: serious Tags: sid bullseye two tests fail: autopkgtest [18:06:29]: test gpr-wrapper: [--- ==Messages for file: /tmp/autopkgtest-lxc.a8l7fm0h/downtmp/autopkgtest_tmp/p.gpr 1. with "gpr.gpr"; | >>> imported project file "gpr.gpr" not found gprbuild: "p.gpr" processing failed autopkgtest [18:06:30]: test gpr-wrapper: ---] autopkgtest [18:06:30]: test gpr-wrapper: - - - - - - - - - - results - - - - - - - - - - gpr-wrapper FAIL non-zero exit status 4 autopkgtest [18:06:30]: test gpr-wrapper: - - - - - - - - - - stderr - - - - - - - - - - gprbuild: "p.gpr" processing failed autopkgtest [18:07:44]: test examples: [--- cp: cannot stat '/usr/share/doc/gprbuild/examples': No such file or directory autopkgtest [18:07:46]: test examples: ---] autopkgtest [18:07:46]: test examples: - - - - - - - - - - results - - - - - - - - - - examples FAIL non-zero exit status 1 autopkgtest [18:07:46]: test examples: - - - - - - - - - - stderr - - - - - - - - - - cp: cannot stat '/usr/share/doc/gprbuild/examples': No such file or directory
Bug#977550: libxmlada's autopkg tests fail
Package: src:libxmlada Version: 21.0.0-2 Severity: serious Tags: sid bullseye see at https://ci.debian.net/data/autopkgtest/testing/amd64/libx/libxmlada/8859011/log.gz autopkgtest [19:16:13]: test link-with-shared: [--- gprbuild: raised CONSTRAINT_ERROR : gpr-proc.adb:696 discriminant check failed autopkgtest [19:16:14]: test link-with-shared: ---] autopkgtest [19:16:14]: test link-with-shared: - - - - - - - - - - results - - - - - - - - - - link-with-shared FAIL non-zero exit status 4 autopkgtest [19:16:15]: test link-with-shared: - - - - - - - - - - stderr - - - - - - - - - - gprbuild: raised CONSTRAINT_ERROR : gpr-proc.adb:696 discriminant check failed
Bug#976638: Severity: grave
Hi! Could someone turn the severity of this bug to grave, as it renders the 3D acceleration unavailable with 5.9.0-4 kernel. Thanks.
Bug#976915: service-wrapper-java: FTBFS on ppc64el: [exec] wrapper.c:(.text+0x3598): undefined reference to `pow'
Le 13/12/2020 à 00:38, Markus Koschany a écrit : > In this case I believe the RC severity is correct because the arch:any or jni > version of the package FTBFS on ppc64el. We should try to fix the problem on > ppc64el or, if upstream doesn't support ppc64el, remove the architecture from > the list of supported architectures in debian/control. As a side note, if we keep getting issues with service-wrapper-java I wonder if we could scrap it, systemd is now able to provide similar auto-restart features for services. Emmanuel Bourg
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
Hi Paul Le 15/12/2020 à 20:49, Paul Gevers a écrit : > Unfortunately, there hasn't been any activity on this bug accept for bug > manipulation. rhino is a key package, so is not going to be autoremoved. > Let's fix this before the first freeze hits. Do you know what version of Rhino does dojo use upstream? Emmanuel Bourg
Bug#977549: bpftrace: all programs fail with Segmentation fault
Package: bpftrace
Version: 0.11.3-3
Severity: grave
Justification: renders package unusable
Any attempt of running bpftrace programs fails on my sid workstation:
$ sudo bpftrace -e 'kprobe:do_nanosleep { printf("PID %d sleeping\n", pid); }'
Two passes with the same argument (-tti) attempted to be registered!
Segmentation fault
The issue isn't limited to kprobes, uprobes fail too:
$ sudo bpftrace -e 'uprobe:/bin/bash:readline { printf("Hello\n") }'
Two passes with the same argument (-tti) attempted to be registered!
Segmentation fault
Even bpftrace -V fails, though with a different error:
$ sudo bpftrace -V
bpftrace v0.11.3
free(): double free detected in tcache 2
Aborted
I'm running linux-image-5.9.0-4-amd64 5.9.11-1 and libllvm11
1:11.0.0-5+b1.
Bug#977545: libnetcdf-mpi-dev: The provided CMake config file (netCDFConfig.cmake) refers to non-existing directories
Please also note that trying to work-around the issue by specifying
`-DCMAKE_PREFIX_PATH=/usr/lib/x86_64-linux-gnu/netcdf/mpi/lib/` to cmake
instead to leverage the recursive symlink
`/usr/lib/x86_64-linux-gnu/netcdf/mpi/lib/` -> `./`
and add an extra element to the path leads to another similar error:
```
CMake Error at /usr/lib/x86_64-linux-gnu/netcdf/mpi/lib/lib/cmake/netCDF/
netCDFConfig.cmake:25 (message):
File or directory /usr/lib/x86_64-linux-gnu/netcdf/mpi/lib/x86_64-linux-gnu
referenced by variable netCDF_LIB_DIR does not exist !
Call Stack (most recent call first):
/usr/lib/x86_64-linux-gnu/netcdf/mpi/lib/lib/cmake/netCDF/netCDFConfig.cmake:
34 (set_and_check)
CMakeLists.txt:43 (find_package)
```
I believe both issues could be solved by creating the symlink
`/usr/lib/x86_64-linux-gnu/netcdf/mpi/lib/${DEB_HOST_MULTIARCH}` -> `../`
instead.
Best regards,
Julien Bigot
--
Dr. Julien Bigot -- http://work.julien-bigot.fr
CEA Researcher @ Maison de la Simulation
USR 3441 - bât. 565 - CEA Saclay
91191 Gif-sur-Yvette CEDEX - FRANCE
phone: +33 (0)1 69 08 01 75
signature.asc
Description: This is a digitally signed message part.
Bug#977548: bash-completion: sqlite3 filename completion does not include .sqlar (SQLite Archive) files
Package: bash-completion Version: 1:2.11-2 Severity: normal Dear Maintainer, SQLite defines an archive file format, which is an SQLite datbase with a single table containing each contained file as a row. The sqlite CLI tool can maniuplate these with the -A option, and the customary file extension for these are .sqlar, so it would be useful if bash would include them when completing file names. See https://sqlite.org/sqlar.html for more info. - ilmari -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information -- - Twitter seems more influential [than blogs] in the 'gets reported in the mainstream press' sense at least. - Matt McLeod - That'd be because the content of a tweet is easier to condense down to a mainstream media article. - Calle Dybedahl
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
> "Matthew" == Matthew Vernon writes: Matthew> On 15/12/2020 22:07, Sam Hartman wrote: >>> However, Debian remains an environment where developers and >>> users can explore and develop alternate init systems and >>> alternatives to systemd features. Those interested in exploring >>> such alternatives need to provide the necessary development and >>> packaging resources to do that work. Technologies such as >>> elogind that facilitate exploring alternatives while running >>> software that depends on some systemd interfaces remain >>> important to Debian. It is important that the project support >>> the efforts of developers working on such technologies where >>> there is overlap between these technologies and the rest of the >>> project, for example by reviewing patches and participating in >>> discussions in a timely manner. >> >> We did not say in that GR that we were interested in supporting >> ongoing development of sysvinit. Matthew> I find it surprising that, in a TC bug about (inter alia) Matthew> whether a dependency on libpam-systemd should be changed to Matthew> default-logind | logind i.e. to facilitate use of elogind Matthew> you appear to be saying that a GR text that talks about the Matthew> importance of "technologies such as elogind" should be Matthew> interpreted as meaning in effect that actually it isn't all Matthew> that important and network-manager should continue to have Matthew> effectively a systemd-only dependency. I'd like to be heard differently. I think that we should either decide that 1) NetworkManager should support elogind or 2) That we haven't seen enough development of alternatives to systemd and the project consensus on the GR has changed. Matthew> Not is it straightforwardly clear that "alternative init Matthew> systems" should in fact be interpreted to mean "alternative Matthew> init systems (but not sysvinit)". I'd like to be heard differently on this point too. I think that to the extent that people are doing things like adding support for service units, looking at ways of solving problems that motivated systemd in non systemd ways in the sysvinit ecosystem, that clearly counts as development of alternative init systems in the scope of the GR. I think that maintaining sysvinit for stable releases so that users can use it does not count as development of alternate init systems. I understand that several people in the project want to do that work. I'm not speaking against that work here, but I don't think you can use the GR as support for that work. Matthew> Nor is this a case of someone demanding that the Matthew> network-manager maintainer provide a sysvinit script nor Matthew> fix the bugs in an existing-but-broken one. Understood. I did suggest to Mark that he use that argument in arguing for maintaining the init script. As I mentioned policy process was not able to come to consensus on when to remove existing init scripts. --Sam
Bug#927971: tomcat9: split policy files and libexec scripts so that pki-server can use them
Le 16/12/2020 à 15:26, Timo Aaltonen a écrit : > Ping, any objection to moving policy files and the update script to > -common? I can do that either directly or via a merge request. I wonder if this is really necessary. The policy files are used to limit the privileges of the web applications hosted by Tomcat when the security manager is enabled. This is convenient when the applications aren't fully trusted. But in the pki-server case there is no trust issue and the security manager could be disabled. The sandboxing could be implemented at the systemd level if necessary. Emmanuel Bourg
Bug#976402: Proposed official virtual packages - todo and todo.txt
On Mon, Dec 14, 2020 at 5:29 PM David Steele wrote: > > On Mon, Dec 14, 2020 at 3:48 PM Sean Whitton > wrote: > >> >> >> Putting aside the use of the alternatives system, why is a virtual >> package wanted? When would it be useful to be able to declare a >> dependency and have it satisfied by one of these implementations? >> >> > As an example, a future rev of an integrated todo.txt-gtd[1] would depend > on that virtual package. > > [1]: https://github.com/davesteele/todo.txt-gtd > > Somehow I don't have a copy or your reply. Imagine that tdtcleanup is a pre/post hook in todo.txt-base. An implementation of todo.txt is needed to make use of it.
Bug#977547: nmu: migrate-parsetree reverse dependencies
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hello, The following Ocaml packages need rebuilding due to the new version of migrate-parsetree uploaded to unstable. List generated from https://people.debian.org/~nomeata/binNMUs-ocaml.txt nmu eliom_6.12.4-1 . armhf . sid . -m 'migrate-parsetree changed from 4csu3 to 1abp1, ppx-tools-versioned changed from r6hc4 to d07i9' nmu eliom_6.12.4-1 . mips64el mipsel armel . sid . -m 'migrate-parsetree changed from 4oqg7 to y9ik5, ppx-tools-versioned changed from j28d9 to a8sg6' nmu eliom_6.12.4-1 . arm64 . sid . -m 'migrate-parsetree changed from 4te49 to vtsf2, ppx-tools-versioned changed from 1wex2 to l05p7' nmu eliom_6.12.4-1 . i386 . sid . -m 'migrate-parsetree changed from hu422 to rl9d2, ppx-tools-versioned changed from 9yhu1 to 1qvw3' nmu eliom_6.12.4-1 . ppc64el . sid . -m 'migrate-parsetree changed from id828 to btpv9, ppx-tools-versioned changed from nu7y1 to z1h94' nmu eliom_6.12.4-1 . amd64 . sid . -m 'migrate-parsetree changed from nuom0 to n2039, ppx-tools-versioned changed from pn5t7 to brxi3' nmu eliom_6.12.4-1 . s390x . sid . -m 'migrate-parsetree changed from yvb04 to 9pt34, ppx-tools-versioned changed from wq601 to hrxm5' nmu js-of-ocaml_3.8.0-1 . armhf . sid . -m 'migrate-parsetree changed from 4csu3 to 1abp1' nmu js-of-ocaml_3.8.0-1 . armhf . sid . -m 'migrate-parsetree changed from 4csu3 to 1abp1, ppxlib changed from 8feq3 to ne9p3' nmu js-of-ocaml_3.8.0-1 . mips64el mipsel armel . sid . -m 'migrate-parsetree changed from 4oqg7 to y9ik5' nmu js-of-ocaml_3.8.0-1 . mips64el mipsel armel . sid . -m 'migrate-parsetree changed from 4oqg7 to y9ik5, ppxlib changed from ab5j9 to 9a9z1' nmu js-of-ocaml_3.8.0-1 . arm64 . sid . -m 'migrate-parsetree changed from 4te49 to vtsf2' nmu js-of-ocaml_3.8.0-1 . arm64 . sid . -m 'migrate-parsetree changed from 4te49 to vtsf2, ppxlib changed from sshr3 to mdnj0' nmu js-of-ocaml_3.8.0-1 . i386 . sid . -m 'migrate-parsetree changed from hu422 to rl9d2' nmu js-of-ocaml_3.8.0-1 . i386 . sid . -m 'migrate-parsetree changed from hu422 to rl9d2, ppxlib changed from yw937 to wjeo5' nmu js-of-ocaml_3.8.0-1 . ppc64el . sid . -m 'migrate-parsetree changed from id828 to btpv9' nmu js-of-ocaml_3.8.0-1 . ppc64el . sid . -m 'migrate-parsetree changed from id828 to btpv9, ppxlib changed from gyp44 to ypxs5' nmu js-of-ocaml_3.8.0-1 . amd64 . sid . -m 'migrate-parsetree changed from nuom0 to n2039' nmu js-of-ocaml_3.8.0-1 . amd64 . sid . -m 'migrate-parsetree changed from nuom0 to n2039, ppxlib changed from jf0b6 to age97' nmu js-of-ocaml_3.8.0-1 . s390x . sid . -m 'migrate-parsetree changed from yvb04 to 9pt34' nmu js-of-ocaml_3.8.0-1 . s390x . sid . -m 'migrate-parsetree changed from yvb04 to 9pt34, ppxlib changed from 3v3b9 to 2rql7' nmu lwt_5.3.0-1 . armhf . sid . -m 'migrate-parsetree changed from 4csu3 to 1abp1, ppx-tools-versioned changed from r6hc4 to d07i9' nmu lwt_5.3.0-1 . mips64el mipsel armel . sid . -m 'migrate-parsetree changed from 4oqg7 to y9ik5, ppx-tools-versioned changed from j28d9 to a8sg6' nmu lwt_5.3.0-1 . arm64 . sid . -m 'migrate-parsetree changed from 4te49 to vtsf2, ppx-tools-versioned changed from 1wex2 to l05p7' nmu lwt_5.3.0-1 . i386 . sid . -m 'migrate-parsetree changed from hu422 to rl9d2, ppx-tools-versioned changed from 9yhu1 to 1qvw3' nmu lwt_5.3.0-1 . ppc64el . sid . -m 'migrate-parsetree changed from id828 to btpv9, ppx-tools-versioned changed from nu7y1 to z1h94' nmu lwt_5.3.0-1 . amd64 . sid . -m 'migrate-parsetree changed from nuom0 to n2039, ppx-tools-versioned changed from pn5t7 to brxi3' nmu lwt_5.3.0-1 . s390x . sid . -m 'migrate-parsetree changed from yvb04 to 9pt34, ppx-tools-versioned changed from wq601 to hrxm5' nmu obus_1.2.3-1. armhf . sid . -m 'migrate-parsetree changed from 4csu3 to 1abp1' nmu obus_1.2.3-1. armhf . sid . -m 'migrate-parsetree changed from 4csu3 to 1abp1, ppxlib changed from 8feq3 to ne9p3' nmu obus_1.2.3-1. mips64el mipsel armel . sid . -m 'migrate-parsetree changed from 4oqg7 to y9ik5' nmu obus_1.2.3-1. mips64el mipsel armel . sid . -m 'migrate-parsetree changed from
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On 14/12/2020 21:56, Philip Hands wrote: Could I just check if there's a point of common acceptability which both sides of this discussion could live with? [...] My suggestion for a mutually bearable solution would be that the network-manager package could have its dependency on libpam-systemd changed to instead be something like: libpam-systemd | network-manager-nonsystemd Is this instead of the logind virtual package? I'm not quite sure what problem you're trying to solve here, but I'm don't think it generalises well (you'd end up with potentially lots of package that just Depend on logind and maybe contain an init script); and without any input from the network-manager maintainer about why they were unwilling to take the patch to use the existing virtual package, I'm not sure why this should be more acceptable. If you think this approach is impractical for some reason, please say so, because what I have in mind as a better option does rather rely on this being available as a plausible fall-back position. I'm confused as to why you don't just tell us what your better option is. Regards, Matthew
Bug#977535: [Pkg-javascript-devel] Bug#977535: Bug#977535: Bug#977535: Bug#977535: pkg-js-tools should create node_modules symlink in autopkgtest
Le 16/12/2020 à 14:59, Xavier a écrit : > Le 16/12/2020 à 14:39, Pirate Praveen a écrit : >> >> >> On 2020, ഡിസംബർ 16 6:45:06 PM IST, Xavier wrote: >>> import tape from "tape"; >>> ^^ >>> >>> SyntaxError: Cannot use import statement outside a module >> >> We need .babelrc too. >> >> https://salsa.debian.org/js-team/node-d3-geo/-/blob/master/debian/patches/use-babel-register-for-esm.patch > > Ok, works with pkg-js-tools 0.9.56 + this patch: > > https://salsa.debian.org/js-team/node-tape/-/blob/master/debian/patches/fix-register-paths.patch autopkgtest will be fixed with node-tape migration
Bug#977546: duplicity: remove-all-but-n-full includes failed backups
Package: duplicity
Version: 0.8.17-1+b1
Severity: normal
X-Debbugs-Cc: none, Barak A. Pearlmutter
I ran out of storage on my remote, so I tried to reclaim some with
$ duplicity remove-all-but-n-full 1 --force "${transport}/${target}"
But afterwards there are just a few meg used in the target directory
instead of many hundreds of gig. It would appear that a full backup
failed due to space exhaustion on the remote, but that the failed full
backup is (inappropriately) included in remove-all-but-n-full's count.
This is just my best guess as to what's going on. But I am 100% sure
that "duplicity remove-all-but-n-full 1" sometimes does not leave an
intact full backup, instead it deletes nearly everything.
This has happened to me repeatedly, so I'm sure there's an actual
problem.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (490, 'testing'), (450, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages duplicity depends on:
ii gnupg 2.2.20-1
ii libc6 2.31-5
ii librsync2 2.3.1-1
ii python33.9.0-4
ii python3-fasteners 0.14.1-2
ii python3-future 0.18.2-4
ii python3-lockfile 1:0.12.2-2.2
Versions of packages duplicity recommends:
pn python3-oauthlib
ii python3-paramiko 2.7.2-1
ii python3-pexpect 4.6.0-4
ii python3-urllib3 1.25.11-1
ii rsync 3.2.3-2
Versions of packages duplicity suggests:
pn lftp
pn ncftp
pn par2
pn python3-boto
ii python3-pip 20.1.1-2
pn python3-swiftclient
pn tahoe-lafs
-- no debconf information
Bug#977545: libnetcdf-mpi-dev: The provided CMake config file (netCDFConfig.cmake) refers to non-existing directories
Package: libnetcdf-mpi-dev
Version: 1:4.7.4-1+b1
Severity: important
X-Debbugs-Cc: jul...@julien-bigot.fr
Dear Maintainer,
Using the parallel version of NetCDF from CMake leads to invalid path found.
The provided CMake config file is installed to the canonical path
/usr/lib/x86_64-linux-gnu/cmake/netCDF_mpi/netCDFConfig.cmake but in order
to be found by CMake, it must be used from the actual path
/usr/lib/x86_64-linux-gnu/netcdf/mpi/lib/cmake/netCDF/netCDFConfig.cmake
( Cf.
https://cmake.org/cmake/help/latest/command/find_package.html#search-procedure
on unix-like systems, the path has to contain either lib/ or share/ just
before the package name.) Hence I used the following command to build my
library depending on NetCDF:
```
cmake -DCMAKE_PREFIX_PATH=/usr/lib/x86_64-linux-gnu/netcdf/mpi/
```
This resulted in the following output:
```
CMake Error at
/usr/lib/x86_64-linux-gnu/netcdf/mpi/lib/cmake/netCDF/netCDFConfig.cmake:25
(message):
File or directory /usr/lib/x86_64-linux-gnu/netcdf/include referenced by
variable netCDF_INCLUDE_DIR does not exist !
Call Stack (most recent call first):
/usr/lib/x86_64-linux-gnu/netcdf/mpi/lib/cmake/netCDF/netCDFConfig.cmake:33
(set_and_check)
CMakeLists.txt:43 (find_package)
```
Indeed, netCDFConfig.cmake sets the variable netCDF_INCLUDE_DIR to
"${PACKAGE_PREFIX_DIR}/include" where PACKAGE_PREFIX_DIR is set to
"${CMAKE_CURRENT_LIST_DIR}/../../../../" (relative to netCDFConfig.cmake
actual path, i.e. /usr/lib/x86_64-linux-gnu/netcdf/mpi/lib/cmake/netCDF/)
This resolves to PACKAGE_PREFIX_DIR=/usr/lib/x86_64-linux-gnu/netcdf and
then netCDF_INCLUDE_DIR=/usr/lib/x86_64-linux-gnu/netcdf/include that does
not exist (missing the mpi/ bit). The package libnetcdf-mpi-dev installs its
include files in /usr/lib/x86_64-linux-gnu/netcdf/mpi/include/
I tried to have a look at the source package on salsa to provide a patch,
however the link provided at
https://packages.debian.org/source/sid/netcdf-parallel regarding the Debian
Source Repository is inaccessible to me
( https://salsa.debian.org/mckinstry/netcdf-parallel ) is the
dev-coinstallable branch of https://salsa.debian.org/mckinstry/netcdf the new
canonical source for these packages?
Best regards,
Julien Bigot
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'stable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libnetcdf-mpi-dev depends on:
ii libnetcdf-mpi-18 1:4.7.4-1+b1
ii pkg-config0.29.2-1
libnetcdf-mpi-dev recommends no packages.
Versions of packages libnetcdf-mpi-dev suggests:
pn netcdf-bin
pn netcdf-doc
-- no debconf information
