Bug#898543: [Pkg-freeipa-devel] Bug#898543: Bug#898543: nss-pem available
I should have written I built in on groovy dpkg-buildpackage -b -uc and the error was the one on the bug you wrote was related to this one. On October 7, 2020 4:09:22 PM CDT, Timo Aaltonen wrote: >On 7.10.2020 22.59, Harry Coin wrote: >> This was from a build on ubuntu-groovy. I suspected the cause was >a >> race condition since the immediate prior step lauches over a dozen >> dogtag processes that eventually all end but not before the failing >step >> begins and then times out. > >There is no freeipa-server on groovy, and there won't be. And the error > >is different on Debian. > > > >-- >t -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#971386: RFS: golang-github-kelvins-sunrisesunset/1.0-1 [ITP] -- Go package that provides the sunrise and sunset equation.
On Tue, Sep 29, 2020 at 22:35, Arun Kumar Pariyar wrote: Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-github-kelvins-sunrisesunset": Uploaded, thanks for your work.
Bug#971281: RFS: golang-github-axgle-mahonia/0.0~git20180208.3358181-1 [ITP] -- Character-set conversion library implemented in Go.
On Tue, Sep 29, 2020 at 00:44, Arun Kumar Pariyar wrote: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "golang-github-axgle-mahonia": Uploaded, thanks for your work.
Bug#933151: mariadb-10.3: FTBFS on riscv64
Hello! > Can we use the patch I proposed earlier in this bug report? I have > tested it on riscv64 and it builds. I can do another try with the > changes from the latest upload and propose a MR on salsa. Sorry, I somehow missed this. Also other "subscribers" of this bug missed it since the Debian bug system does not automatically include everybody as the recipient of new messages in a bug. Tested your patch in an upload to experimental and it worked! See https://buildd.debian.org/status/package.php?p=mariadb-10.5=experimental https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commits/master Could you Aurelien please submit your patch upstream for permanent inclusion? Thanks!
Bug#971669: libopenmpi3: armel mipsel: mca_pmix_pmix3x.so: undefined symbol: OPAL_MCA_PMIX3X_PMIx_Get_version
Source: openmpi Followup-For: Bug #971669 Control: affects -1 src:dolfinx Control: severity -1 serious This bug seems to be make making dolfinx FTBFS (via the impact on scotch), so bumping severity up to serious.
Bug#971786: [Pkg-javascript-devel] Bug#971786: Bug#971786: src:pdf.js: please package new upstream version
Le 07/10/2020 à 17:13, Xavier a écrit : > Le 07/10/2020 à 17:03, Carsten Schoenert a écrit : >> Hello Xavier, >> >> Am 07.10.20 um 16:29 schrieb Xavier: >>> Le 07/10/2020 à 10:29, Carsten Schoenert a écrit : >>> this modules looks useless in Debian: >>> * no reverse-dependencies >> >> well, might simply because the version in Debian is far to old for all >> possibly other packages. ;) >> I haven't looked at packages that using now preshipped pdf.js. >> >>> * one binary mas to be removed (xul component, #906835) >> >> Yes, obviously. >> >>> * you're the first person who looks to it for a while ;-) >>> >>> Then do you need its update ? I can do it but it requires some work >>> (zelenka.debian.org is working on it :-D). >> >> No hurry, I was today looking into upgrading kopano-webapp to 4.3 and >> the Kopano is using pdf.js since version 4.0 here. >> >> There are other issues to solve, but using pdf.js from Debian would >> prevent the requirement to use the embedded version. > > OK, I'll update it Sadly updating pdf.js requires to update acorn to acorn 7.4. This will take time...
Bug#971823: ITP: simrisc -- simulation model for risk associated with breast cancer
Package: wnpp Severity: wishlist Owner: tony mancill X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: simrisc Version : 13.02.00 Upstream Author : Frank B. Brokken * URL : https://fbb-git.gitlab.io/simrisc/ * License : GPL-3+ Programming Lang: C++ Description : simulation model for breast cancer risk https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3668482/ I intend to maintain this package as part of the Debian-Med team. Regards, tony signature.asc Description: PGP signature
Bug#914230: ITP: git-imerge -- incremental merge and rebase for git
Control: owner ! On Tue, 20 Nov 2018 19:37:49 + Jessica Clarke wrote: > * Package name: git-imerge ... > Description : incremental merge and rebase for git ... > I recently discovered this useful tool and now use it for my day-to-day > work dealing with forks of large upstream projects. It was mentioned on IRC that this is no longer true and mergify was adopted as a replacement, but I am still using git-imerge so I will take over the package. Hopefully Jessica will package mergify too :) https://github.com/brooksdavis/mergify -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#971786: [Pkg-javascript-devel] Bug#971786: Bug#971786: Bug#971786: src:pdf.js: please package new upstream version
On 2020, ഒക്ടോബർ 7 11:27:21 PM IST, Jonas Smedegaard wrote: >Quoting Pirate Praveen (2020-10-07 19:19:53) >> On 2020, ഒക്ടോബർ 7 8:43:14 PM IST, Xavier wrote: >> >Le 07/10/2020 à 17:03, Carsten Schoenert a écrit : >> >> well, might simply because the version in Debian is far to old for all >> >> possibly other packages. ;) >> >> I haven't looked at packages that using now preshipped pdf.js. > >[...] > >> >> No hurry, I was today looking into upgrading kopano-webapp to 4.3 >> >> and the Kopano is using pdf.js since version 4.0 here. >> >> >> >> There are other issues to solve, but using pdf.js from Debian would >> >> prevent the requirement to use the embedded version. >> > >> >OK, I'll update it >> >> Thanks. >> >> Need it for gitlab too, but since debian version was old, I was using >> it from npmjs.com > >When embedding code copies, please document it here: >https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/embedded-code-copies > >...as documented here: https://wiki.debian.org/EmbeddedCopies It is not embedded. It is installed via postinst and gitlab is in contrib (till all those are packaged - 400+ out of 1600+ still to package). > - Jonas > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#971822: ogongify.1: fix some formatting in the manual
Package: a2ps Version: 1:4.14-5 Severity: minor Tags: patch Dear Maintainer, the only change in the output is 1) \- (minus) replaces - for options (only visible in "troff" output) 2) Two spaces (if groff request ".ss .. 0" is not used) after an end of a sentence instead of a single space. Patch: --- ogonkify.1 2020-10-08 02:05:19.0 + +++ ogonkify.1.new 2020-10-08 02:09:27.0 + @@ -79,9 +79,9 @@ Includes the specified procset in the ou .TP .B \-e -Set the encoding of the output. Defaults to +Set the encoding of the output. Defaults to .B L2 -(ISO 8859\-2, a.k.a. ISO Latin\-2). Other possible values are +(ISO 8859\-2, a.k.a. ISO Latin\-2). Other possible values are .B L1 (ISO 8859\-1, a.k.a. ISO Latin\-1), .B L3 @@ -198,9 +198,9 @@ processing. Do .B mp processing. Will not work with the -.B -A +.B \-A option (use -.B -C +.B \-C instead). .TP @@ -236,15 +236,15 @@ End options. .SH USAGE Let us assume that you want to print a WWW page encoded in -ISO Latin\-2. Netscape stubbornly insists on printing it as -ISO Latin\-1. By using the File->Print command, have Netscape send the +ISO Latin\-2. Netscape stubbornly insists on printing it as +ISO Latin\-1. By using the File->Print command, have Netscape send the output to a file, say alamakota.ps. As .B ogonkify is configured for ISO Latin\-2 by default, passing it the PostScript -generated by Netscape will correct the encoding of the fonts. It is -enough to do: +generated by Netscape will correct the encoding of the fonts. +It is enough to do: .IP % ogonkify \-N ii wdiff 1.2.2-2+b1 Versions of packages a2ps suggests: ii emacsen-common 3.0.4 ii ghostscript 9.52.1~dfsg-1 pn graphicsmagick-imagemagick-compat | imagemagick ii groff1.22.4-5 ii gv 1:3.7.4-2+b1 pn html2ps pn t1-cyrillic ii texlive-binaries [texlive-base-bin] 2020.20200327.54578-5 -- no debconf information -- Bjarni I. Gislason
Bug#971821: fixnt.1: fix formatting of references to manuals
Package: a2ps Version: 1:4.14-5 Severity: minor Tags: patch Dear Maintainer, see man-pages(7), about formatting of references to man pages (bold typeface). Patch: --- fixnt.1 2020-10-08 01:50:28.0 + +++ fixnt.1.new 2020-10-08 01:51:55.0 + @@ -11,7 +11,8 @@ fixnt \- Filter for the Windows NT posts The Windows NT postscript driver has a tendency to make broken postscript files, that are incompatible with psutils. .B fixnt -is a filter that fixes these problems, allowing the use of psnup(1). +is a filter that fixes these problems, allowing the use of +.BR psnup (1). .PP The filter takes the broken postscript file on .BR stdin , @@ -24,7 +25,9 @@ It has no other form for invocation and takes no options. .SH BUGS .B fixnt -does not check for NTPSOct94. For a workaround, use a sed(1) command +does not check for NTPSOct94. For a workaround, use a +.BR sed (1) +command to replace 'NTPSOct94' with 'NTPSOct95', like so: .RS sed 's/NTPSOct94/NTPSOct95/g' @@ -40,4 +43,5 @@ Report bugs to the Authors, but avoid se .P Patches are always welcome; send to . .SH "SEE ALSO" -psnup(1), sed(1) +.BR psnup (1), +.BR sed (1) -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.10-1 (SMP w/2 CPU threads) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages a2ps depends on: ii file 1:5.38-5 ii libc6 2.31-3 ii libpaper1 1.1.28+b1 ii psutils1.17.dfsg-4 Versions of packages a2ps recommends: ii bzip2 1.0.8-4 pn lpr | rlpr | cups-client ii wdiff 1.2.2-2+b1 Versions of packages a2ps suggests: ii emacsen-common 3.0.4 ii ghostscript 9.52.1~dfsg-1 pn graphicsmagick-imagemagick-compat | imagemagick ii groff1.22.4-5 ii gv 1:3.7.4-2+b1 pn html2ps pn t1-cyrillic ii texlive-binaries [texlive-base-bin] 2020.20200327.54578-5 -- no debconf information -- Bjarni I. Gislason
Bug#971819: manuals created with a "help2man" version that is far too old
Package: a2ps Version: 1:4.14-5 Severity: normal Dear Maintainer, the used version of "help2man" is from the year 1999 (version 1.019). It should not be local in the package. The current version is from the year 2020 (version 1.47.16). -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.10-1 (SMP w/2 CPU threads) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages a2ps depends on: ii file 1:5.38-5 ii libc6 2.31-3 ii libpaper1 1.1.28+b1 ii psutils1.17.dfsg-4 Versions of packages a2ps recommends: ii bzip2 1.0.8-4 pn lpr | rlpr | cups-client ii wdiff 1.2.2-2+b1 Versions of packages a2ps suggests: ii emacsen-common 3.0.4 ii ghostscript 9.52.1~dfsg-1 pn graphicsmagick-imagemagick-compat | imagemagick ii groff1.22.4-5 ii gv 1:3.7.4-2+b1 pn html2ps pn t1-cyrillic ii texlive-binaries [texlive-base-bin] 2020.20200327.54578-5 -- no debconf information -- Bjarni I. Gislason
Bug#971820: composeglyphs.1: Remove a repeated word
Package: a2ps Version: 1:4.14-5 Severity: minor Tags: patch Dear Maintainer, remove a repeated word "that". Patch: --- composeglyphs.1 2020-10-08 01:39:14.0 + +++ composeglyphs.1.new 2020-10-08 01:42:57.0 + @@ -18,7 +18,7 @@ composeglyphs \- generate an encoding ve .B composeglyphs is a script to generate either an encoding vector or a new font for postscript. It requires a pre-existing AFM and allows -for the use of composite characters that that AFM does not already +for the use of composite characters that AFM does not already provide. .SH OPTIONS .TP -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.10-1 (SMP w/2 CPU threads) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages a2ps depends on: ii file 1:5.38-5 ii libc6 2.31-3 ii libpaper1 1.1.28+b1 ii psutils1.17.dfsg-4 Versions of packages a2ps recommends: ii bzip2 1.0.8-4 pn lpr | rlpr | cups-client ii wdiff 1.2.2-2+b1 Versions of packages a2ps suggests: ii emacsen-common 3.0.4 ii ghostscript 9.52.1~dfsg-1 pn graphicsmagick-imagemagick-compat | imagemagick ii groff1.22.4-5 ii gv 1:3.7.4-2+b1 pn html2ps pn t1-cyrillic ii texlive-binaries [texlive-base-bin] 2020.20200327.54578-5 -- no debconf information -- Bjarni I. Gislason
Bug#971818: ogonkify.1: fix a misuse of a two-font macro
Package: a2ps Version: 1:4.14-5 Severity: minor Tags: patch Dear Maintainer, correct the misuse of a two-fonts macro, which function is to 1) use the first font for each odd numbered argument and the second font for all others. 2) join the arguments without an intervening space. ### Patch: --- ogonkify.1 2020-10-08 00:04:50.0 + +++ ogonkify.1.new 2020-10-08 00:07:48.0 + @@ -139,7 +139,7 @@ Helvetica. .TP .B \-A Like -.BR \-a +.B \-a but also downloads the Courier\-Ogonki fonts. .TP -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.10-1 (SMP w/2 CPU threads) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages a2ps depends on: ii file 1:5.38-5 ii libc6 2.31-3 ii libpaper1 1.1.28+b1 ii psutils1.17.dfsg-4 Versions of packages a2ps recommends: ii bzip2 1.0.8-4 pn lpr | rlpr | cups-client ii wdiff 1.2.2-2+b1 Versions of packages a2ps suggests: ii emacsen-common 3.0.4 ii ghostscript 9.52.1~dfsg-1 pn graphicsmagick-imagemagick-compat | imagemagick ii groff1.22.4-5 ii gv 1:3.7.4-2+b1 pn html2ps pn t1-cyrillic ii texlive-binaries [texlive-base-bin] 2020.20200327.54578-5 -- no debconf information -- Bjarni I. Gislason
Bug#971817: Some manuals have trailing spaces
Package: a2ps Version: 1:4.14-5 Severity: minor Dear Maintainer, some manuals in this package contain trailing spaces. These should be removed before the files are compressed. a2ps-lpr-wrapper.1.gz composeglyphs.1.gz fixnt.1.gz ogonkify.1.gz -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.10-1 (SMP w/2 CPU threads) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages a2ps depends on: ii file 1:5.38-5 ii libc6 2.31-3 ii libpaper1 1.1.28+b1 ii psutils1.17.dfsg-4 Versions of packages a2ps recommends: ii bzip2 1.0.8-4 pn lpr | rlpr | cups-client ii wdiff 1.2.2-2+b1 Versions of packages a2ps suggests: ii emacsen-common 3.0.4 ii ghostscript 9.52.1~dfsg-1 pn graphicsmagick-imagemagick-compat | imagemagick ii groff1.22.4-5 ii gv 1:3.7.4-2+b1 pn html2ps pn t1-cyrillic ii texlive-binaries [texlive-base-bin] 2020.20200327.54578-5 -- no debconf information -- Bjarni I. Gislason
Bug#971816: gnome-shell-timer: fails to load with GNOME shell 3.38: TypeError: meta is null
Package: gnome-shell-timer Version: 0.3.20+20171025-4 Severity: serious Usertags: crash The GNOME shell timer extension fails to load with GNOME shell 3.38 and I see the following message in the systemd journal: Oct 03 12:18:06 gnome-shell[2523]: JS ERROR: Extension ti...@olebowle.gmx.com: TypeError: meta is null _patchContainerClass/containerClass.prototype.child_set@resource:///org/gnome/shell/ui/environment.js:43:13 _patchContainerClass/containerClass.prototype.add@resource:///org/gnome/shell/ui/environment.js:52:18 _init@/usr/share/gnome-shell/extensions/ti...@olebowle.gmx.com/extension.js:103:19 wrapper@resource:///org/gnome/gjs/modules/script/_legacy.js:82:27 enable@/usr/share/gnome-shell/extensions/ti...@olebowle.gmx.com/extension.js:418:17 _callExtensionEnable@resource:///org/gnome/shell/ui/extensionSystem.js:167:32 loadExtension@resource:///org/gnome/shell/ui/extensionSystem.js:348:26 _loadExtensions/<@resource:///org/gnome/shell/ui/extensionSystem.js:586:18 collectFromDatadirs@resource:///org/gnome/shell/misc/fileUtils.js:27:28 _loadExtensions@resource:///org/gnome/shell/ui/extensionSystem.js:565:19 _enableAllExtensions@resource:///org/gnome/shell/ui/extensionSystem.js:595:18 _sessionUpdated@resource:///org/gnome/shell/ui/extensionSystem.js:626:18 init@resource:///org/gnome/shell/ui/extensionSystem.js:56:14 _initializeUI@resource:///org/gnome/shell/ui/main.js:269:22 start@resource:///org/gnome/shell/ui/main.js:159:5 @:1:47 -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell-timer depends on: ii dconf-gsettings-backend [gsettings-backend] 0.38.0-1 ii gnome-shell 3.38.0-2 ii python3 3.8.2-3 gnome-shell-timer recommends no packages. gnome-shell-timer suggests no packages. -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#971748: raspi-firmware: architecture misunderstood by /etc/kernel/postinst.d/z50-raspi-firmware
Control: retitle -1 DPKG_MAINTSCRIPT_ARCH should be used in
/etc/kernel/postinst.d/z50-raspi-firmware instead of dpkg --print-architecture
Control: tags -1 patch
The following patch should fix this bug:
--- var/tmp/z50-raspi-firmware 2020-10-08 10:01:37.576672275 +0900
+++ etc/kernel/postinst.d/z50-raspi-firmware2020-10-08 10:09:47.032477030
+0900
@@ -61,7 +61,7 @@
# copy and rename the available device tree binaries
# the bootloader will pick the right device tree binary
# if it is named according to the system on chip family name
-arch=$(dpkg --print-architecture)
+arch=$DPKG_MAINTSCRIPT_ARCH
if [ "arm64" = "$arch" ]; then
dtb_path="/usr/lib/linux-image-${latest_kernel#/boot/vmlinuz-}/broadcom"
else
Best regards, Ryutaroh
Bug#954794: New packages must not declare themselves Essential
Hello, On Wed 07 Oct 2020 at 06:43pm -04, Sam Hartman wrote: > Josh, my current reading is that there is not support for even the > first step. I believe Guillem and I have disagreed, and I haven't > noticed support from anyone other than you. Speaking as Policy Editor, I agree. I don't see any sort of consensus that we should deprive ourselves of the ability to declare packages Essential. > C) I'd support non-normative documentation that we don't expect to > approve new essential packages in the future in policy. This sounds like a good idea to me too. -- Sean Whitton
Bug#898543: [Pkg-freeipa-devel] Bug#898543: nss-pem available
On 10/7/20 2:31 PM, Timo Aaltonen wrote: > On 7.10.2020 19.11, Harry Coin wrote: >> On Fri, 25 Sep 2020 11:46:16 +0300 Timo Aaltonen >> wrote: >>> >>> Hi, >>> >>> This bug shouldn't happen anymore, as nss-pem is used. There's another >>> bug (970880) preventing server install right now though. >>> >>> -- >>> t >>> >>> >> File >> "/usr/lib/python3/dist-packages/ipaserver/install/cainstance.py", >> line 484, in configure_instance >> self.start_creation(runtime=runtime) >> File "/usr/lib/python3/dist-packages/ipaserver/install/service.py", >> line 606, in start_creation >> run_step(full_msg, method) >> File "/usr/lib/python3/dist-packages/ipaserver/install/service.py", >> line 592, in run_step >> method() >> File >> "/usr/lib/python3/dist-packages/ipaserver/install/cainstance.py", >> line 880, in __request_ra_certificate >> reqId = certmonger.request_and_wait_for_cert( >> File "/usr/lib/python3/dist-packages/ipalib/install/certmonger.py", >> line 409, in request_and_wait_for_cert >> raise RuntimeError( >> >> 2020-10-07T14:45:28Z DEBUG The ipa-server-install command failed, >> exception: RuntimeError: Certificate issuance failed (CA_UNREACHABLE: >> Error 35 connecting to >> https://registry1.1.quietfountain.com:8443/ca/agent/ca//profileReview: >> SSL connect error.) >> 2020-10-07T14:45:28Z ERROR Certificate issuance failed (CA_UNREACHABLE: >> Error 35 connecting to >> https://registry1.1.quietfountain.com:8443/ca/agent/ca//profileReview: >> SSL connect error.) >> 2020-10-07T14:45:28Z ERROR The ipa-server-install command failed. See >> /var/log/ipaserver-install.log for more information >> >> ... >> >> [11/30]: starting certificate server instance >> [12/30]: configure certmonger for renewals >> [13/30]: requesting RA certificate from CA >> [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE: >> Error 35 connecting to >> https://registry1.1.quietfountain.com:8443/ca/agent/ca//profileReview: >> SSL connect error.) >> >> ___ >> Pkg-freeipa-devel mailing list >> pkg-freeipa-de...@alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeipa-devel >> >> > > No need to post it here, as I said 970880 is the other bug. Upstream > is looking at it. > This was from a build on ubuntu-groovy. I suspected the cause was a race condition since the immediate prior step lauches over a dozen dogtag processes that eventually all end but not before the failing step begins and then times out. -HC
Bug#946456: systemd: Provide systemd-sysusers as an independent package
On Wed, 7 Oct 2020 18:21:39 +0200 Michael Biebl wrote: > I like this approach and think we should do the same in Debian. > Users, which have the full systemd package installed don't have any > negative side effects, which could result from splitting out > systemd-tmpfiles/systemd-sysusers and libsystemd-shared. > > Restricted/non-systemd environments, like containers, can use > systemd-standalone-sysusers and systemd-standalone-tmpfiles with minimal > dependencies. > > We could debate whether systemd-standalone-tmpfiles and > systemd-standalone-sysusers should be provided by a single binary > package, but since Fedora has already done this split this way, I would > simply follow here and use the same binary package names. > The relevant Fedora PR is > https://src.fedoraproject.org/rpms/systemd/pull-request/27 fwiw. > > Thankfully, -Dstandalone-binaries=true doesn't require a separate, third > build variant (as with the udeb flavour), so build times shouldn't go up. > > If there are no objections to this approach I would proceed and > implement it like this: > - Build systemd with -Dstandalone-binaries=true > - Install the standalone binaries in binary packages named > systemd-standalone-sysusers and systemd-standalone-tmpfiles > - Those binaries packages would only ship /bin/systemd-sysusers resp. > /bin/systemd-tmpfiles and have a Conflicts/Replaces: systemd > > > In case there are no objections to this plan, I would create a MR on salsa. > > Thoughts? This seems like a great plan. I look forward to seeing it. I'm hopeful that this will make it easier for packages to start relying on systemd-tmpfiles and systemd-sysusers.
Bug#971802: elpa-debian-el: Documentation link in apt-utils.el refers to alioth.
On Wed, 2020-10-07 at 15:55 -0300, David Bremner wrote: > > The last release was in 2010, I think the url should probably just be > deleted. That sounds like it'd work too. Diane
Bug#954794: New packages must not declare themselves Essential
> "Josh" == Josh Triplett writes: Josh> Long-term, I'd like to see that happen. But I'm a huge fan of Josh> incremental steps; defining the problem as "eliminate Josh> Essential" makes it both difficult enough and controversial Josh> enough to make it unlikely to happen at all. Right now, the Josh> first step is "let's not let the problem get any worse, and Josh> let's ensure that any new package that might have otherwise Josh> used Essential must instead get packages to add a dependency". Josh, my current reading is that there is not support for even the first step. I believe Guillem and I have disagreed, and I haven't noticed support from anyone other than you. Is there support I'm failing to remember? I would not attempt to summarize Guillem's concerns. My concerns are roughly that I think 1) debian-devel consensus is an adequate block for things getting worse unless there is a good reason 2) I am not convinced that we would (or should) decline to use this particular hammer if it really is the best tool we have available for a bind we find ourselves in; nor do I think policy would actually bar us if we had necessity 3) The benefit I perceive in spending more time trying to figure out whether I could be convinced that there are no circumstances under which I'd support a new essential package is less than what I think we'd get out of it , so I'd rather not spend the time. In the interest of being constructive: A) I do support reducing the essential set over time B) I would support better education of the community about why we should be hesitant to support essential: yes on debian-devel C) I'd support non-normative documentation that we don't expect to approve new essential packages in the future in policy. --Sam
Bug#947847: Fwd: Bug#946456: systemd: Provide systemd-sysusers as an independent package
Michael Biebl writes: > > If there are no objections to this approach I would proceed and > implement it like this: > - Build systemd with -Dstandalone-binaries=true > - Install the standalone binaries in binary packages named > systemd-standalone-sysusers and systemd-standalone-tmpfiles > - Those binaries packages would only ship /bin/systemd-sysusers resp. > /bin/systemd-tmpfiles and have a Conflicts/Replaces: systemd Speaking for myself, it sounds reasonable. signature.asc Description: PGP signature
Bug#971815: podman: --init is broken: /usr/libexec/podman/catatonit not found
Package: podman
Version: 2.0.6+dfsg1-1
Severity: normal
Tags: patch
I was testing some things that I usually run against docker with podman,
and discovered that --init does not work:
$ docker run --init debian echo Hello world
Hello world
$ podman run --init debian echo Hello world
Error: container-init binary not found on the host: stat
/usr/libexec/podman/catatonit: no such file or directory
I found https://github.com/containers/podman/issues/4159 upstream
I did a quick packaging of catatonit, installed it, and with the
attached patch, I can make it work. I have just submitted an ITP for
catatonit.
$ podman run --init debian echo Hello world
Hello world
Should I go ahead and upload catatonit? Or would you rather point to a
different init by default? It seems we have quite some of them in the
archive already (tini, dumb-init, ...)?
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, i386
Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages podman depends on:
ii conmon 2.0.20-1
ii containernetworking-plugins 0.8.6-2
ii golang-github-containers-common 0.14.10+ds1-1
ii init-system-helpers 1.58
ii libc62.31-3
ii libdevmapper1.02.1 2:1.02.171-3
ii libgpgme11 1.14.0-1
ii libseccomp2 2.4.4-1
ii runc 1.0.0~rc92+dfsg1-5
Versions of packages podman recommends:
ii buildah 1.15.2-1
ii catatonit 0.1.5-2.ge27d77f
ii fuse-overlayfs 1.1.2-1
ii slirp4netns 1.0.1-1
ii tini0.19.0-1
ii uidmap 1:4.8.1-1
Versions of packages podman suggests:
pn containers-storage
-- no debconf information
From cc06f4d235ec8c45e56304b8fd5e8e08981bb6b1 Mon Sep 17 00:00:00 2001
From: Antonio Terceiro
Date: Wed, 7 Oct 2020 18:20:05 -0300
Subject: [PATCH] Use catatonit with --init by default
---
debian/control | 2 +-
debian/podman.links | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
create mode 100644 debian/podman.links
diff --git a/debian/control b/debian/control
index c2c758ef2..1a1a4bb2b 100644
--- a/debian/control
+++ b/debian/control
@@ -114,7 +114,7 @@ Recommends: ${misc:Recommends}
,buildah (>= 1.10.1-6~)
,fuse-overlayfs (>= 1.0.0~)
,slirp4netns (>= 0.4.1~)
-,tini | dumb-init
+,catatonit | tini | dumb-init
,uidmap
Suggests: ${misc:Suggests}
,containers-storage
diff --git a/debian/podman.links b/debian/podman.links
new file mode 100644
index 0..b8d6e9761
--- /dev/null
+++ b/debian/podman.links
@@ -0,0 +1 @@
+/usr/bin/catatonit/usr/libexec/podman/catatonit
--
2.28.0
signature.asc
Description: PGP signature
Bug#971814: ITP: catatonit -- init process for containers
Package: wnpp Severity: wishlist Owner: Antonio Terceiro X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: catatonit Version : 0.1.5 Upstream Author : Aleksa Sarai * URL : https://github.com/openSUSE/catatonit * License : GPL-3+ Programming Lang: C Description : init process for containers catatonic is a very simple init process for application containers. Its purpose is to support only the usage by container managers such as docker and podman, which is /dev/init -- . No other use cases will be supported. It is used by podman as container init when given the --init flag. signature.asc Description: PGP signature
Bug#971780: debian-edu-config: adapt fetch-ldap-cert and fetch-rootca-cert
Hi Wolfgang, thanks for your feedback. Am Mittwoch, 7. Oktober 2020 schrieb Wolfgang Schweer: > Hi Mike, > > [ Mike Gabriel, 2020-10-07 ] > > IMHO, fetch-ldap-cert should not try to download the Debian-Edu_rootCA.crt > > anymore as that's handled by fetch-rootca-cert. The fetch-ldap-cert script > > should only handle situations where a Debian Edu clients runs against a > > TJENER from stretch (or earlier) or buster 10.0. > > > > Comments on that? > > Yes, it has only been kept for the purpose of older main servers, please > fix the script. > > Wolfgang Ok, I'll take a look... Mike -- Sent from my Fairphone powered by SailfishOS
Bug#898543: [Pkg-freeipa-devel] Bug#898543: Bug#898543: nss-pem available
On 7.10.2020 22.59, Harry Coin wrote: This was from a build on ubuntu-groovy. I suspected the cause was a race condition since the immediate prior step lauches over a dozen dogtag processes that eventually all end but not before the failing step begins and then times out. There is no freeipa-server on groovy, and there won't be. And the error is different on Debian. -- t
Bug#970606: [Openjdk] Bug#970606: src:openjdk-*: autopkgtest times out on Debian/Ubuntu infrastructure
Hi Matthias, On 21-09-2020 17:52, Paul Gevers wrote: >> Apparently >> the very same tests don't time out on the buildds. > > I don't know what timeouts apply to buildds, but indeed I think they are > much higher to cope with *building* some extremely big packages. Do you know how much time these tests would take? If so, I wonder if we should make it possible for individual packages to have a longer timeout. It would be work on the debci/ci.d.n side of things, but not impossible of course. Paul signature.asc Description: OpenPGP digital signature
Bug#971768: abseil: FTBFS on hppa - needs porting
On Tuesday, October 6, 2020, at 8:59 PM +, John David Anglin wrote: > The attached change enables abseil to build successfully on hppa. This is fantastic – thanks. I’ve got a few pending changes of this sort for other architectures; I’ll plan to include yours in the next upload. May I assume that you wish to contribute this patch under the Apache License, version 2.0, as is used throughout the rest of Abseil? Best, Benjamin signature.asc Description: PGP signature
Bug#964090: Please upload backport
Control: tags -1 + patch Hi, > Is this because of a ghostscript vulnerability? The PDF policy restriction is also in effect on Debian stable even though that release ships with Ghostscript 9.27, which online sources suggest is safe. [1] Converting images to PDF is a very common functionality. Please provide a backport with the attached patch, or similar. Thanks! Kind regards Felix Lechner [1] https://stackoverflow.com/questions/52998331/imagemagick-security-policy-pdf-blocking-conversion --- /etc/ImageMagick-6/policy.xml 2020-10-07 13:05:46.246938227 -0700 +++ /etc/ImageMagick-6/policy.xml~ 2020-06-25 11:00:40.0 -0700 @@ -91,6 +91,6 @@ - +
Bug#898543: nss-pem available
On Fri, 25 Sep 2020 11:46:16 +0300 Timo Aaltonen wrote: > > Hi, > > This bug shouldn't happen anymore, as nss-pem is used. There's another > bug (970880) preventing server install right now though. > > -- > t > > File "/usr/lib/python3/dist-packages/ipaserver/install/cainstance.py", line 484, in configure_instance self.start_creation(runtime=runtime) File "/usr/lib/python3/dist-packages/ipaserver/install/service.py", line 606, in start_creation run_step(full_msg, method) File "/usr/lib/python3/dist-packages/ipaserver/install/service.py", line 592, in run_step method() File "/usr/lib/python3/dist-packages/ipaserver/install/cainstance.py", line 880, in __request_ra_certificate reqId = certmonger.request_and_wait_for_cert( File "/usr/lib/python3/dist-packages/ipalib/install/certmonger.py", line 409, in request_and_wait_for_cert raise RuntimeError( 2020-10-07T14:45:28Z DEBUG The ipa-server-install command failed, exception: RuntimeError: Certificate issuance failed (CA_UNREACHABLE: Error 35 connecting to https://registry1.1.quietfountain.com:8443/ca/agent/ca//profileReview: SSL connect error.) 2020-10-07T14:45:28Z ERROR Certificate issuance failed (CA_UNREACHABLE: Error 35 connecting to https://registry1.1.quietfountain.com:8443/ca/agent/ca//profileReview: SSL connect error.) 2020-10-07T14:45:28Z ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information ... [11/30]: starting certificate server instance [12/30]: configure certmonger for renewals [13/30]: requesting RA certificate from CA [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE: Error 35 connecting to https://registry1.1.quietfountain.com:8443/ca/agent/ca//profileReview: SSL connect error.)
Bug#971720: tumbler FTCBFS: gtk-doc runs host code
On Wed, Oct 07, 2020 at 09:37:17PM +0200, Yves-Alexis Perez wrote: > On Mon, 2020-10-05 at 20:25 +0200, Helmut Grohne wrote: > > + dh_auto_configure -- --$(if $(filter tumbler-common,$(shell > > dh_listpackages)),en,dis)able-gtk-doc > > Hi Helmut, thanks for the report. Is there not a nicer way to detect from > debian/rules that we're running a cross build or something? It might just be > aesthetics, but I'm not sure I really like the above line =/ There are ways to check whether we're running a cross build. The code snippet above does not do that however. It checks whether the tumbler-common package is part of the build, which really is the thing we care about here. It does fix cross builds, but really what it says is: Enable gtk-doc iff tumbler-common is being built. The method used here is a quite common pattern. You can easily find lots of users: https://codesearch.debian.net/search?q=filter.*dh_listpackages=0 You do have a point in that it is a little difficult to understand. Would it help to write it more verbosely? DO_PACKAGES:=$(shell dh_listpackages) ifeq (,$(filter tumbler-common,$(DO_PACKAGES))) CONFIGURE_ARGS += --disable-gtk-doc else CONFIGURE_ARGS += --enable-gtk-doc endif override_dh_auto_configure: dh_auto_configure -- $(CONFIGURE_ARGS) Helmut
Bug#947847: Fwd: Bug#946456: systemd: Provide systemd-sysusers as an independent package
Forwarding this to the CTTE, just in case they have some input on this
proposed plan.
Weitergeleitete Nachricht
Betreff: Re: Bug#946456: systemd: Provide systemd-sysusers as an
independent package
Datum: Wed, 7 Oct 2020 18:21:39 +0200
Von: Michael Biebl
An: 946...@bugs.debian.org, Felipe Sateler , Ansgar
, Niels Thykier
A small update here:
v246 provides a build switch -Dstandalone-binaries=true:
`
option('standalone-binaries', type : 'boolean', value : 'false',
description : 'also build standalone versions of supported binaries')
`
Atm, those supported binaries are systemd-tmpfiles and systemd-sysusers.
Those binaries do not link against libsystemd-shared and have minimal
dependencies.
Fedora decided to ship those binaries in separate binary packages named
systemd-standalone-sysusers and systemd-standalone-tmpfiles, which
conflict with the main systemd package, i.e. the main systemd package
will continue to ship systemd-tmpfiles and systemd-sysusers linking
against libsystemd-shared.
I like this approach and think we should do the same in Debian.
Users, which have the full systemd package installed don't have any
negative side effects, which could result from splitting out
systemd-tmpfiles/systemd-sysusers and libsystemd-shared.
Restricted/non-systemd environments, like containers, can use
systemd-standalone-sysusers and systemd-standalone-tmpfiles with minimal
dependencies.
We could debate whether systemd-standalone-tmpfiles and
systemd-standalone-sysusers should be provided by a single binary
package, but since Fedora has already done this split this way, I would
simply follow here and use the same binary package names.
The relevant Fedora PR is
https://src.fedoraproject.org/rpms/systemd/pull-request/27 fwiw.
Thankfully, -Dstandalone-binaries=true doesn't require a separate, third
build variant (as with the udeb flavour), so build times shouldn't go up.
If there are no objections to this approach I would proceed and
implement it like this:
- Build systemd with -Dstandalone-binaries=true
- Install the standalone binaries in binary packages named
systemd-standalone-sysusers and systemd-standalone-tmpfiles
- Those binaries packages would only ship /bin/systemd-sysusers resp.
/bin/systemd-tmpfiles and have a Conflicts/Replaces: systemd
In case there are no objections to this plan, I would create a MR on salsa.
Thoughts?
Michael
signature.asc
Description: OpenPGP digital signature
Bug#971813: Broken invocation through mailcap
Package: icedtea-netx Version: 1.7.2-2 This is actually a follow-up to #924706. The symlinks have been fixed since, however the mailcap entries are still wrong. $ ls /usr/share/icedtea-web/bin/ gives itweb-settings.sh itw-modularjdk.args javaws.sh policyeditor.sh The alternatives' links seem to be fine... /etc/alternatives/javaws -> /usr/share/icedtea-web/bin/javaws.sh /usr/bin/javaws -> /etc/alternatives/javaws ... but /usr/lib/mime/packages/icedtea-netx still contains application/x-java-jnlp-file; /usr/share/icedtea-web/bin/javaws %s As a result, all programs using the mailcap system to run javaws fail to do so. Depending on what location is preferred(?), I suggest that /usr/lib/mime/packages/icedtea-netx should contain application/x-java-jnlp-file; /usr/share/icedtea-web/bin/javaws.sh %s or application/x-java-jnlp-file; /usr/bin/javaws %s Best regards, Phil
Bug#971812: gegl: version in buster not compatible with libc6 from bullseye
Control: reassign -1 libgegl-0.4-0 0.4.12-2 Control: retitle -1 gegl: version in buster not compatible with libc6 from bullseye Control: severity -1 normal Control: affects -1 + gimp On Wed, 07 Oct 2020 at 20:47:59 +0200, Artur Linhart wrote: > In the curent state of available packages from stable (buster) the program > GIMP > cannot be used. *On a purely stable system*, it works fine. However, like the reporter of #968342, you are using a system that mixes packages from stable and testing: > ii libc62.31-3 The error message seen in the GUI is misleading, because it's guessing that the reason the seamless-clone.so module didn't load successfully is because gegl is too old (which it is not). The warning shown when you run it from a terminal is more accurate: > "$ gimp > GEGL-Message: 20:38:16.980: Fehler beim Laden von Modul > »/usr/lib/x86_64-linux- > gnu/gegl-0.4/seamless-clone.so«: /usr/lib/x86_64-linux-gnu/libgegl-sc-0.4.so: > undefined symbol: __exp_finite This is because you are using the version of libc6 from testing (bullseye) on a mostly-buster system, and the version of libgegl in buster has assumptions that mean it works fine in buster, but breaks when libc6 is upgraded. Mixing packages from stable and testing is not something that anyone can guarantee will work flawlessly. This is not going to be something that can change in buster, unless the release team would accept a stable-update that changes how libgegl is linked in order to future-proof it against people upgrading core system libraries to versions 18 months newer. I'm not sure they're going to go for that, but I'll ask... > This bug has been already reported as a bug https://bugs.debian.org/cgi- > bin/bugreport.cgi?bug=968342 and was closed with the statement the dependency > has to be used on libgegl-0.4-0 where the problem has been fixed, but the > problem is, such version is not available on stable - buster, or even buster- > backports. Neither are libc6 version 2.31-3 and libgcc-s1 version 10.2.0-9, but you seem to have installed those somehow. smcv
Bug#971807: buster-pu: package webext-tbsync
On Wed, 2020-10-07 at 21:24 +0200, Mechtilde Stehmann wrote: > Hello Adam, > > On Wed, 07 Oct 2020 19:54:41 +0100 "Adam D. Barratt" > wrote:> severity 971807 normal > > retitle 971807 buster-pu: package webext-tbsync > > user release.debian@packages.debian.org > > usertags 971807 + pu > > thanks > > > > On Wed, 2020-10-07 at 20:39 +0200, Mechtilde Stehmann wrote: > > > Package: release.debian.org > > > Version: > > > Severity: grave > > > > Absolutely not. A stable update is generally - and at most - normal > > severity. > > I choose 'grave' because the bugs about the incompatibility are set > to grave like #968102. The package might well have an RC bug. The release process does not. :- ) [...] > > You want 2.16.1-0+deb10u1 or 2.16.1-1~deb10u1, with an appropriate > > changelog stanza on top of either the current stable package or the > > unstable upload, depending on which way you go. > > yes I will take the right versioning 2.16.1~deb10u1-1. You have the components out of order - it's 2.16.1-1~deb10u1, not 2.16.1~deb10u1-1. It's effectively a backport of 2.16.1-1. > It is needed to be uploaded to stable-update because of the > > > update > > > thunderbird 68 to 78. > > > > Is the new package compatible with Thunderbird 68 as well? > > The new package isn't compatible with Thunderbird 68 but only with 78 > as described in d/control. That's why it is useful to update to > stable-update and not to proposed-update. One *can't* "update [in] stable-updates and not proposed-updates". An update to stable is *always* made via proposed-updates. The Release Team may then choose to copy the package to stable-updates as well, but the upload is no different from any other. > Since RT updated Thunderbird in buster from version 68.x to 78.x this > causes the incompatibility from webext-tbsync with the recent > Thunderbird version in Buster. For the record, the Release Team have done no such thing. The Security Team have released 78.x, which is not yet even in stable-new, yet alone buster (although it likely will be in buster after the next point release). I realise this might seem picky, but if you're going to say we caused it... :-) Regards, Adam
Bug#971720: tumbler FTCBFS: gtk-doc runs host code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2020-10-05 at 20:25 +0200, Helmut Grohne wrote: > + dh_auto_configure -- --$(if $(filter tumbler-common,$(shell > dh_listpackages)),en,dis)able-gtk-doc Hi Helmut, thanks for the report. Is there not a nicer way to detect from debian/rules that we're running a cross build or something? It might just be aesthetics, but I'm not sure I really like the above line =/ Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl9+GO0ACgkQ3rYcyPpX RFsMigf9HUTUo0Eyg90qERt8qhw6hnFbWlHQEiUjim3B3X7n8TD3k13JUEyAk2cD KfhEBBHP0RH2pInnhqqcyrAoFBED09SN9/8yDnduc3iy+g3H8k7TQoiuMaaK9oTQ qT9L5pzoZYy/J4cTV8WtYPIa2yiz1VYHSLxp9QaEIh++euBvyLMfaQN5oGgqW7hC F7JQrZv4FW9vrXfeuNF/IQMo5REvPEzwqlwlPhdSkN94OYiWYxrI/87lDv+9zMja OueCPqcr7QbXuHTXTvkDCAOQGF7I34Oue42wnHH5xMszUtUql30Vy93lu8rek0Uj Au8qPhxul6NnB68XM8HPdRFby71Sxw== =MV/d -END PGP SIGNATURE-
Bug#898543: [Pkg-freeipa-devel] Bug#898543: nss-pem available
On 7.10.2020 19.11, Harry Coin wrote: On Fri, 25 Sep 2020 11:46:16 +0300 Timo Aaltonen wrote: Hi, This bug shouldn't happen anymore, as nss-pem is used. There's another bug (970880) preventing server install right now though. -- t File "/usr/lib/python3/dist-packages/ipaserver/install/cainstance.py", line 484, in configure_instance self.start_creation(runtime=runtime) File "/usr/lib/python3/dist-packages/ipaserver/install/service.py", line 606, in start_creation run_step(full_msg, method) File "/usr/lib/python3/dist-packages/ipaserver/install/service.py", line 592, in run_step method() File "/usr/lib/python3/dist-packages/ipaserver/install/cainstance.py", line 880, in __request_ra_certificate reqId = certmonger.request_and_wait_for_cert( File "/usr/lib/python3/dist-packages/ipalib/install/certmonger.py", line 409, in request_and_wait_for_cert raise RuntimeError( 2020-10-07T14:45:28Z DEBUG The ipa-server-install command failed, exception: RuntimeError: Certificate issuance failed (CA_UNREACHABLE: Error 35 connecting to https://registry1.1.quietfountain.com:8443/ca/agent/ca//profileReview: SSL connect error.) 2020-10-07T14:45:28Z ERROR Certificate issuance failed (CA_UNREACHABLE: Error 35 connecting to https://registry1.1.quietfountain.com:8443/ca/agent/ca//profileReview: SSL connect error.) 2020-10-07T14:45:28Z ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information ... [11/30]: starting certificate server instance [12/30]: configure certmonger for renewals [13/30]: requesting RA certificate from CA [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE: Error 35 connecting to https://registry1.1.quietfountain.com:8443/ca/agent/ca//profileReview: SSL connect error.) ___ Pkg-freeipa-devel mailing list pkg-freeipa-de...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeipa-devel No need to post it here, as I said 970880 is the other bug. Upstream is looking at it. -- t
Bug#971796: hexedit: regression: crash (SIGFPE) with empty files
Thanks Paul. Already fixed in upstream[1]. I think we will have a new upstream release soon. [1] https://github.com/pixel/hexedit/commit/41981645134d201151f1cea9fd964d892166e866 Cheers, Eriberto
Bug#971807: buster-pu: package webext-tbsync
Hello Adam, On Wed, 07 Oct 2020 19:54:41 +0100 "Adam D. Barratt" wrote:> severity 971807 normal > retitle 971807 buster-pu: package webext-tbsync > user release.debian@packages.debian.org > usertags 971807 + pu > thanks > > On Wed, 2020-10-07 at 20:39 +0200, Mechtilde Stehmann wrote: > > Package: release.debian.org > > Version: > > Severity: grave > > Absolutely not. A stable update is generally - and at most - normal > severity. I choose 'grave' because the bugs about the incompatibility are set to grave like #968102. > > Please use standard metadata for p-u bugs, and at the very least > mention the package in the subject if not... > > > Hello, > > > > I prepare an update of webext-tbsync for buster with version > > 2.16.1+deb10u1. > > That would be higher than the version in unstable, so would be > inappropriate. (and appears to be missing a Debian package revision, > but I assume that's simply a typo and you meant 2.16.1-1+deb10u1.) > > You want 2.16.1-0+deb10u1 or 2.16.1-1~deb10u1, with an appropriate > changelog stanza on top of either the current stable package or the > unstable upload, depending on which way you go. yes I will take the right versioning 2.16.1~deb10u1-1. I was irritated with the description in th the developer reference. But now I hope I understand the difference which isn't described there. > > > It is needed to be uploaded to stable-update because of the update > > thunderbird 68 to 78. > > Is the new package compatible with Thunderbird 68 as well? The new package isn't compatible with Thunderbird 68 but only with 78 as described in d/control. That's why it is useful to update to stable-update and not to proposed-update. Since RT updated Thunderbird in buster from version 68.x to 78.x this causes the incompatibility from webext-tbsync with the recent Thunderbird version in Buster. The previous version doesn't work anymore > > > This fixed the incompatibility (#968102). It is now uploaded to > > unstable after being two months in experimental. > > > > I will also fill two further bug reports for DAV-4-TbSync and > > EAS-4-Tbsync which are dependencies of TbSyc > > Please bear the above in mind before doing so. yes I will change the versioning for all three packages. Sorry for the missinterpreting the developer-reference about this. I hope now it is cleare why I prefer an upload to stable > > Regards, > > Adam -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F signature.asc Description: OpenPGP digital signature
Bug#970520: confirm workaround
On Tue, 29 Sep 2020 14:58:36 +0200 Benedikt Hallinger wrote: > Confirming $ wesnoth --nocache works here too. > > But what is causing this? Is this an upstream bug? Or one debian > introduces? Nobody directly answered your question, so... It was introduced by the Debian builder, using libwolfssl, instead of openssl, due to licensing issues.
Bug#958598: triggerhappy: diff for NMU version 0.5.0-1.1
Control: tags 958598 + patch
Control: tags 958598 + pending
Dear maintainer,
I'm sponsoring an NMU by Baptiste Beauplat for triggerhappy (versioned
as 0.5.0-1.1) and uploaded it to DELAYED/2. Please feel free to tell me
if I should delay it longer.
Regards.
--
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 `-
diffstat for triggerhappy-0.5.0 triggerhappy-0.5.0
changelog | 13 +
compat|1 -
control |3 ++-
rules |2 +-
4 files changed, 16 insertions(+), 3 deletions(-)
diff -Nru triggerhappy-0.5.0/debian/changelog triggerhappy-0.5.0/debian/changelog
--- triggerhappy-0.5.0/debian/changelog 2016-08-30 09:26:25.0 +0200
+++ triggerhappy-0.5.0/debian/changelog 2020-10-07 12:03:39.0 +0200
@@ -1,3 +1,16 @@
+triggerhappy (0.5.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix Build-Depends on deprecated dh-systemd (Closes: #958598)
+- Replace debhelper by debhelper-compat
+- Bump debhelper-compat to 13
+- Remove debian/compat file
+- Remove dh-systemd dependency
+- Remove systemd dh addon
+- Add missing ${misc:Pre-Depends}
+
+ -- Baptiste Beauplat Wed, 07 Oct 2020 12:03:39 +0200
+
triggerhappy (0.5.0-1) unstable; urgency=medium
* add new upstream release 0.5.0 (Closes: #834637, #835980)
diff -Nru triggerhappy-0.5.0/debian/compat triggerhappy-0.5.0/debian/compat
--- triggerhappy-0.5.0/debian/compat 2016-08-30 09:26:25.0 +0200
+++ triggerhappy-0.5.0/debian/compat 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-9
diff -Nru triggerhappy-0.5.0/debian/control triggerhappy-0.5.0/debian/control
--- triggerhappy-0.5.0/debian/control 2016-08-30 09:26:25.0 +0200
+++ triggerhappy-0.5.0/debian/control 2020-10-07 12:03:39.0 +0200
@@ -2,7 +2,7 @@
Section: utils
Priority: extra
Maintainer: Stefan Tomanek
-Build-Depends: debhelper (>= 9), linux-libc-dev, pkg-config, libsystemd-dev, dh-systemd (>= 1.5)
+Build-Depends: debhelper-compat (= 13), linux-libc-dev, pkg-config, libsystemd-dev
Standards-Version: 3.9.8
Homepage: https://github.com/wertarbyte/triggerhappy
Vcs-Git: https://github.com/wertarbyte/triggerhappy.git
@@ -10,6 +10,7 @@
Package: triggerhappy
Architecture: linux-any
+Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}, libsystemd0
Description: global hotkey daemon for Linux
Triggerhappy watches connected input devices for certain key presses
diff -Nru triggerhappy-0.5.0/debian/rules triggerhappy-0.5.0/debian/rules
--- triggerhappy-0.5.0/debian/rules 2016-08-30 09:26:25.0 +0200
+++ triggerhappy-0.5.0/debian/rules 2020-10-07 12:03:39.0 +0200
@@ -4,4 +4,4 @@
export DEB_BUILD_MAINT_OPTIONS=hardening=+all
%:
- dh $@ --with=systemd
+ dh $@
signature.asc
Description: PGP signature
Bug#968102: [Pkg-mozext-maintainers] Bug#968102: Bug#968102: new upstream release (2.16)
On Wed, 2020-10-07 at 11:11 +0200, Carsten Schoenert wrote: > Hello Mechtilde, > > Am 07.10.20 um 10:34 schrieb Mechtilde: > > Hello, > > > > I will do a update-proposal for buster ASAP. > > > > Do I still have to consider something to get it drectly into buster > > and > > not just with the next point release. > > that's a decision finally made by the RT. > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#upload-stable > > I'm sure if you kindly ask and can describe why an upload to > stable-update instead of proposed-updates is useful for Debian As a point of clarity here - there's no such thing as "an upload to stable-updates", and it's certainly not "instead of proposed-updates". The update *always* goes to proposed-updates, and may then be copied to stable-updates from there. Regards, Adam
Bug#971812: gimp cannot be started because of dependency on wrong version of libgegl-0.4-0 package
Package: gimp Version: 2.10.8-2 Severity: grave Justification: renders package unusable In the curent state of available packages from stable (buster) the program GIMP cannot be used. After start it shows following message: "GEGL operation missing! GIMP requires the GEGL operation "gegl:seamless-clone". This operation cannot be found. Check your GEGL install and ensure it has been compiled with any dependencies required for GIMP." and ends. If started from command line, then following additional error message is produced to the console: "$ gimp GEGL-Message: 20:38:16.980: Fehler beim Laden von Modul »/usr/lib/x86_64-linux- gnu/gegl-0.4/seamless-clone.so«: /usr/lib/x86_64-linux-gnu/libgegl-sc-0.4.so: undefined symbol: __exp_finite " This bug has been already reported as a bug https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=968342 and was closed with the statement the dependency has to be used on libgegl-0.4-0 where the problem has been fixed, but the problem is, such version is not available on stable - buster, or even buster- backports. It breaks the basic rule, the stable packages have to depend only on stable packages. The todays stable (buster) version of libgegl-0.4-0 which is 0.4.12-2, does not contain the functionality, needed by the current stable version of gimp (2.10.8-2), what means the dependency in this gimp package version is defined ina wrong way, it should be defined like (>= 0.4.18-1) and not, like defined (>= 0.4.12). neither gimp, not libgegl-0.4-0 cannot be in the current stable version downgraded, which seems to be the reason, why the software after update of the stable system renders to be unbusable for everybody who keeps strictly on stable releases. Proposed solution: move the library libgegl-0.4-0 of version >= 0.4.18-1 from testing to stable or buster-backports... I cannot imagine, we cannot use GIMP software for the next 2 years until bullseye becomes stable. -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-0.bpo.2-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE, TAINT_AUX Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=cs:en_US:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gimp depends on: ii gimp-data2.10.8-2 ii libaa1 1.4p5-46 ii libbabl-0.1-00.1.62-1 ii libbz2-1.0 1.0.6-9.2~deb10u1 ii libc62.31-3 ii libcairo21.16.0-4 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3+deb10u1 ii libgcc-s1 [libgcc1] 10.2.0-9 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgegl-0.4-00.4.12-2 ii libgexiv2-2 0.10.9-1 ii libgimp2.0 2.10.8-2 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgs9 9.27~dfsg-2+deb10u4 ii libgtk2.0-0 2.24.32-3 ii libgudev-1.0-0 232-2 ii libharfbuzz0b2.3.1-1 ii libheif1 1.3.2-2~deb10u1 ii libilmbase23 2.2.1-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-3 ii liblzma5 5.2.4-1 ii libmng1 1.0.10+dfsg-3.1+b5 ii libmypaint-1.3-0 1.3.0-2.1 ii libopenexr23 2.2.1-4.1+deb10u1 ii libopenjp2-7 2.3.0-2+deb10u1 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libpangoft2-1.0-01.42.4-8~deb10u1 ii libpng16-16 1.6.36-6 ii libpoppler-glib8 0.71.0-5 ii librsvg2-2 2.44.10-2.1 ii libstdc++6 10.2.0-9 ii libtiff5 4.1.0+git191117-2~deb10u1 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2+b1 ii libwmf0.2-7 0.2.8.4-14 ii libx11-6 2:1.6.7-1+deb10u1 ii libxcursor1 1:1.1.15-2 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2+b3 ii libxpm4 1:3.5.12-1 ii xdg-utils1.1.3-1+deb10u1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages gimp recommends: ii ghostscript 9.27~dfsg-2+deb10u4 Versions of packages gimp suggests: pn gimp-data-extras pn gimp-help-en | gimp-help pn gimp-python ii gvfs-backends 1.38.1-5 ii libasound21.1.8-1 -- no debconf information
Bug#971810: engrampa FTCBFS: AC_RUN_IFELSE
Source: engrampa Version: 1.24.1-1 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs engrampa fails to cross build from source, because it uses a run check to discover the behaviour of file wrt zstd. This has two problems: A) It uses AC_RUN_IFELSE, which breaks cross compilation. B) It checks the version of file used during build. Not the one it is working with. I'm attaching a patch that makes it simply assume a recent file during cross compilation and we can be done with that. My solution leaves aspect B) unaddressed. Please close this bug even if not solving B). For solving B), there are a number of options. A simple one is issuing a runtime dependency on libmagic1 (>= 1:5.38). Then you always have the fixed libmagic and nothing to worry about. This doesn't work upstream however. For upstream there also is a better solution. Instead of checking the behaviour of file at build time, you can check the version of file at runtime. You can simply call magic_version() in the application. Just some thoughts. The bug is really about A). Helmut --- engrampa-1.24.1.orig/configure.ac +++ engrampa-1.24.1/configure.ac @@ -190,9 +190,15 @@ } return status;]])], [zstd_mime_type="application/x-zstd"], - [zstd_mime_type="application/zstd"] + [zstd_mime_type="application/zstd"], + [zstd_mime_type="cross"] ) - AC_MSG_RESULT($zstd_mime_type) + AS_IF([test "$zstd_mime_type" = "cross"],[ + zstd_mime_type="application/x-zstd" + AC_MSG_RESULT(cross, guessing $zstd_mime_type) + ],[ + AC_MSG_RESULT($zstd_mime_type) + ]) dnl *** LIBS="$save_LIBS"
Bug#971811: srt FTCBFS: does not pass cross flags to cmake
Source: srt Version: 1.4.2-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs srt fails to cross build from source, because it does not pass cross flags to cmake. The easiest way of doing so - using dh_auto_configure - makes srt cross buildable. Please consider applying the attached patch. Helmut diff --minimal -Nru srt-1.4.2/debian/changelog srt-1.4.2/debian/changelog --- srt-1.4.2/debian/changelog 2020-10-03 12:40:07.0 +0200 +++ srt-1.4.2/debian/changelog 2020-10-07 20:53:40.0 +0200 @@ -1,3 +1,10 @@ +srt (1.4.2-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_configure pass cross flags to cmake. (Closes: #-1) + + -- Helmut Grohne Wed, 07 Oct 2020 20:53:40 +0200 + srt (1.4.2-1) unstable; urgency=medium * New upstream release (Closes: #963798) diff --minimal -Nru srt-1.4.2/debian/rules srt-1.4.2/debian/rules --- srt-1.4.2/debian/rules 2020-10-03 12:40:07.0 +0200 +++ srt-1.4.2/debian/rules 2020-10-07 20:53:39.0 +0200 @@ -18,7 +18,7 @@ export USE_ENCLIB=gnutls %: - dh $@ + dh $@ --buildsystem=cmake+makefile override_dh_auto_clean: dh_clean @@ -30,9 +30,8 @@ # -- --use-enclib=openssl #dh_auto_configure --builddirectory=debian/build/gnutls \ # -- --use-enclib=gnutls - mkdir -p build-openssl build-gnutls - cd build-openssl && cmake .. $(CMAKE_OPTS) -DUSE_ENCLIB=openssl - cd build-gnutls && cmake .. $(CMAKE_OPTS) -DUSE_ENCLIB=gnutls -DTARGET_srt=srt-gnutls + dh_auto_configure --builddirectory=build-openssl -- $(CMAKE_OPTS) -DUSE_ENCLIB=openssl + dh_auto_configure --builddirectory=build-gnutls -- $(CMAKE_OPTS) -DUSE_ENCLIB=gnutls -DTARGET_srt=srt-gnutls override_dh_auto_build-arch: #dh_auto_build --builddirectory=debian/build/openssl
Bug#954794: New packages must not declare themselves Essential
On Wed, 30 Sep 2020 18:34:06 -0700 Jonathan Nieder wrote: > Even so, some *rough* consensus on the plan is very useful for > helping people evaluate that first step. Here is a rough plan: 1. Policy: Packages should declare all their dependencies, even essential ones. 2. Make easier this task: document dependencies, add Lintian checks, etc. 3. Policy: Packages must declare all their dependencies. 4. Wait until previous Debian releases become unsupported. 5. Drop support for Essential. smime.p7s Description: S/MIME cryptographic signature
Bug#971807: release.debian.org - fixed incompatibility to thunderbird 78
severity 971807 normal retitle 971807 buster-pu: package webext-tbsync user release.debian@packages.debian.org usertags 971807 + pu thanks On Wed, 2020-10-07 at 20:39 +0200, Mechtilde Stehmann wrote: > Package: release.debian.org > Version: > Severity: grave Absolutely not. A stable update is generally - and at most - normal severity. Please use standard metadata for p-u bugs, and at the very least mention the package in the subject if not... > Hello, > > I prepare an update of webext-tbsync for buster with version > 2.16.1+deb10u1. That would be higher than the version in unstable, so would be inappropriate. (and appears to be missing a Debian package revision, but I assume that's simply a typo and you meant 2.16.1-1+deb10u1.) You want 2.16.1-0+deb10u1 or 2.16.1-1~deb10u1, with an appropriate changelog stanza on top of either the current stable package or the unstable upload, depending on which way you go. > It is needed tobe uploaded to sstable-update because of the Update of > thunderbird 68 to 78. Is the new package compatible with Thunderbird 68 as well? > This fixed the incompatibility (#968102). It is now uploaded to > unstable after being two months in experimental. > > I will also fill two further bug reports for DAV-4-TbSync and > EAS-4-Tbsync which are dependencies aof TbSyc Please bear the above in mind before doing so. Regards, Adam
Bug#971802: elpa-debian-el: Documentation link in apt-utils.el refers to alioth.
Diane Trout writes: > Package: elpa-debian-el > Version: 37.9 > Severity: normal > X-Debbugs-Cc: none, Diane Trout > > Dear Maintainer, > > I was looking through apt-utils.el and for interesting functions and I > found this. > > (defgroup apt-utils nil > "Emacs interface to APT (Debian package management)." > :group 'tools > :link '(url-link "http://mph-emacs-pkgs.alioth.debian.org/AptUtilsEl.html;)) > > I'm pretty sure alioth.debian.org is gone, so perhaps that link should > be updated to something on salsa? The last release was in 2010, I think the url should probably just be deleted. d
Bug#971809: release.debian.org - fixed incompatibility to thunderbird 78
Package: release.debian.org Version: Severity: grave Hello, I prepare an update of webext-eas4tbsync for buster with version 1.16+deb10u1. This is a dependency for TbSync 2.16.1 It is needed to be uploaded to stable-update because of the update of thunderbird 68 to 78. This fixed the incompatibility (#971771). It is now uploaded to unstable after being two months in experimental. There are two further bug reports for TbSync and DAV-4-Tbsync which is dependency of TbSync -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (400, 'testing'), (300, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: 5.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F signature.asc Description: OpenPGP digital signature
Bug#971808: release.debian.org - fixed incompatibility to thunderbird 78
Package: release.debian.org Version: Severity: grave Hello, I prepare an update of webext-dav4tbsync for buster with version 1.16+deb10u1. This is a dependency for TbSync 2.16.1 It is needed tobe uploaded to stable-update because of the update of thunderbird 68 to 78. This fixed the incompatibility (#971770). It is now uploaded to unstable after being two months in experimental. There are two further bug reports for TbSync and EAS-4-Tbsync which is dependencies of TbSync -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (400, 'testing'), (300, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: 5.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F signature.asc Description: OpenPGP digital signature
Bug#971807: release.debian.org - fixed incompatibility to thunderbird 78
Package: release.debian.org Version: Severity: grave Hello, I prepare an update of webext-tbsync for buster with version 2.16.1+deb10u1. It is needed tobe uploaded to sstable-update because of the Update of thunderbird 68 to 78. This fixed the incompatibility (#968102). It is now uploaded to unstable after being two months in experimental. I will also fill two further bug reports for DAV-4-TbSync and EAS-4-Tbsync which are dependencies aof TbSyc -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (400, 'testing'), (300, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: 5.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F signature.asc Description: OpenPGP digital signature
Bug#966373: general: Higher version for uploads to stable and oldstable distributions
El dl 21 de 09 de 2020 a les 16:50 +0200, Javier Serrano Polo va escriure: > I will elaborate on the problem with 1-1+b1foo1 and 1-1+b1foo1+b1 if > you are willing to help. First, a binNMU in Debian may be unnecessary in the derivative. Following Debian binNMUs means unnecessary builds in architectures supported by the derivative and a burden for users in unsupported architectures. Moreover, the derivative would need to track all binary changes instead of source changes only. smime.p7s Description: S/MIME cryptographic signature
Bug#971786: [Pkg-javascript-devel] Bug#971786: Bug#971786: Bug#971786: src:pdf.js: please package new upstream version
Quoting Pirate Praveen (2020-10-07 19:19:53) > On 2020, ഒക്ടോബർ 7 8:43:14 PM IST, Xavier wrote: > >Le 07/10/2020 à 17:03, Carsten Schoenert a écrit : > >> well, might simply because the version in Debian is far to old for all > >> possibly other packages. ;) > >> I haven't looked at packages that using now preshipped pdf.js. [...] > >> No hurry, I was today looking into upgrading kopano-webapp to 4.3 > >> and the Kopano is using pdf.js since version 4.0 here. > >> > >> There are other issues to solve, but using pdf.js from Debian would > >> prevent the requirement to use the embedded version. > > > >OK, I'll update it > > Thanks. > > Need it for gitlab too, but since debian version was old, I was using > it from npmjs.com When embedding code copies, please document it here: https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/embedded-code-copies ...as documented here: https://wiki.debian.org/EmbeddedCopies - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#968556: torbrowser-launcher: Will not update with french locale
On Mon, Aug 17, 2020 at 7:21 PM Olivier Berger wrote: > > $ locale > LANG=fr_FR.UTF-8 > LANGUAGE= > LC_CTYPE="fr_FR.UTF-8" > LC_NUMERIC="fr_FR.UTF-8" > LC_TIME="fr_FR.UTF-8" > LC_COLLATE="fr_FR.UTF-8" > LC_MONETARY="fr_FR.UTF-8" > LC_MESSAGES="fr_FR.UTF-8" > LC_PAPER="fr_FR.UTF-8" > LC_NAME="fr_FR.UTF-8" > LC_ADDRESS="fr_FR.UTF-8" > LC_TELEPHONE="fr_FR.UTF-8" > LC_MEASUREMENT="fr_FR.UTF-8" > LC_IDENTIFICATION="fr_FR.UTF-8" > LC_ALL= > $ torbrowser-launcher > Tor Browser Launcher > Par Micah Lee, sous licence MIT > version 0.3.2 > https://github.com/micahflee/torbrowser-launcher > Votre version du Navigateur Tor est obsolète. Téléchargement de la nouvelle > version. > Télécharger à travers Tor > Téléchargement > https://aus1.torproject.org/torbrowser/update_3/release/Linux_x86_64-gcc3/x/en-US > > Which terminates immediately without doing anything else... not starting > torbrowser :-/ I think it's related to #753173 [1], if not a duplicated one. [1] https://bugs.debian.org/753173 I tested in my side, and it worked well. $ LC_MESSAGES=fr_FR.UTF-8 torbrowser-launcher --settings Above command can download FR version of TBB without problem. So if you meet problems, I guess it's because of the locale settings. Please confirm you already installed fr_FR.UTF-8 locale correctly: $ sudo dpkg-reconfigure locales Then confirm you have checked fr_FR.UTF-8 item, and then the locales are correctly generated. After that you can try to launch TBB again. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#971806: python-hdf5storage's autopkg tests fail in unstable
Package: src:python-hdf5storage Version: 0.1.15+git20200608.09dfc5f-1 Severity: serious Tags: sid bullseye seen, when triggered by the setuptools upload, only used as a build time tool by python-hdf5storage. blocking the setuptools migration to testing. https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-hdf5storage/7325816/log.gz https://ci.debian.net/data/autopkgtest/testing/arm64/p/python-hdf5storage/7326442/log.gz == ERROR: test_write_readback.TestMatlabFormat.test_dtype_structured_with_offsets_titles -- Traceback (most recent call last): File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/tmp/autopkgtest-lxc.bkohktuu/downtmp/autopkgtest_tmp/tests/test_write_readback.py", line 862, in test_dtype_structured_with_offsets_titles np.dtype(desc).itemsize + random.randint(1, 100) ValueError: name already used as a name or title -- Ran 1513 tests in 28.846s FAILED (SKIP=4, errors=1)
Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org
Control: tags -1 wontfix El dt 29 de 09 de 2020 a les 17:10 +0200, Javier Serrano Polo va escriure: > Thus, I will tag this report as wontfix. Tagging. smime.p7s Description: S/MIME cryptographic signature
Bug#971786: [Pkg-javascript-devel] Bug#971786: Bug#971786: src:pdf.js: please package new upstream version
On 2020, ഒക്ടോബർ 7 8:43:14 PM IST, Xavier wrote: >Le 07/10/2020 à 17:03, Carsten Schoenert a écrit : >> Hello Xavier, >> >> Am 07.10.20 um 16:29 schrieb Xavier: >>> Le 07/10/2020 à 10:29, Carsten Schoenert a écrit : >>> this modules looks useless in Debian: >>> * no reverse-dependencies >> >> well, might simply because the version in Debian is far to old for all >> possibly other packages. ;) >> I haven't looked at packages that using now preshipped pdf.js. >> >>> * one binary mas to be removed (xul component, #906835) >> >> Yes, obviously. >> >>> * you're the first person who looks to it for a while ;-) >>> >>> Then do you need its update ? I can do it but it requires some work >>> (zelenka.debian.org is working on it :-D). >> >> No hurry, I was today looking into upgrading kopano-webapp to 4.3 and >> the Kopano is using pdf.js since version 4.0 here. >> >> There are other issues to solve, but using pdf.js from Debian would >> prevent the requirement to use the embedded version. > >OK, I'll update it Thanks. Need it for gitlab too, but since debian version was old, I was using it from npmjs.com There is a lot of dependencies to package, so no urgency. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#971805: Configuration file keyword 'textEncoding' not recognised
Package: xpdf Version: 3.04-13 Like described in #863382 for a different config file command, xpdf reports Config Error: Unknown config file command 'textEncoding' (/etc/xpdf/xpdfrc:) when the config file contains it. However, xpdfrc(5) lists this option as valid. I assume this needs to be fixed upstream - either in the code, or in the manpage.
Bug#847984:
Hi, Was this eventually included in rxvt-unicode? Thanks, -- Radu
Bug#971804: libzstd: embedded libxxhash implementation
Source: libzstd Version: 1.4.5+dfsg-4 Severity: important Hello, I see you build an embedded xxhash.c/xxhash.h version of the xxhash library already in Debian. I tried to use the system version, but some pre-processor directives such as XXH_NAMESPACE=ZSTD_ are tricking my efforts in crafting a patch, resulting into some undefined libraries when linking. Please consider asking upstream to detect and support (if possible) a system library, or add it to the list of embedded libraries in Debian G.
Bug#971803: RM: gnome-shell-extension-workspaces-to-dock -- ROM; RC buggy, no longer maintained upstream
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: j...@debian.org Please remove gnome-shell-extension-workspaces-to-dock. It no longer works on GNOME 3.38 (now in unstable) and the maintainer has announced that no further maintenance will take place for this extension.
Bug#971802: elpa-debian-el: Documentation link in apt-utils.el refers to alioth.
Package: elpa-debian-el Version: 37.9 Severity: normal X-Debbugs-Cc: none, Diane Trout Dear Maintainer, I was looking through apt-utils.el and for interesting functions and I found this. (defgroup apt-utils nil "Emacs interface to APT (Debian package management)." :group 'tools :link '(url-link "http://mph-emacs-pkgs.alioth.debian.org/AptUtilsEl.html;)) I'm pretty sure alioth.debian.org is gone, so perhaps that link should be updated to something on salsa? Diane -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable'), (110, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-debian-el depends on: ii bzip2 1.0.8-4 ii dpkg1.20.5 ii emacsen-common 3.0.4 ii reportbug 7.7.0 ii xz-utils5.2.4-1+b1 Versions of packages elpa-debian-el recommends: ii emacs 1:26.3+1-2 ii emacs-gtk [emacs] 1:26.3+1-2 ii wget 1.20.3-1+b3 elpa-debian-el suggests no packages. -- no debconf information
Bug#946456: systemd: Provide systemd-sysusers as an independent package
A small update here:
v246 provides a build switch -Dstandalone-binaries=true:
`
option('standalone-binaries', type : 'boolean', value : 'false',
description : 'also build standalone versions of supported binaries')
`
Atm, those supported binaries are systemd-tmpfiles and systemd-sysusers.
Those binaries do not link against libsystemd-shared and have minimal
dependencies.
Fedora decided to ship those binaries in separate binary packages named
systemd-standalone-sysusers and systemd-standalone-tmpfiles, which
conflict with the main systemd package, i.e. the main systemd package
will continue to ship systemd-tmpfiles and systemd-sysusers linking
against libsystemd-shared.
I like this approach and think we should do the same in Debian.
Users, which have the full systemd package installed don't have any
negative side effects, which could result from splitting out
systemd-tmpfiles/systemd-sysusers and libsystemd-shared.
Restricted/non-systemd environments, like containers, can use
systemd-standalone-sysusers and systemd-standalone-tmpfiles with minimal
dependencies.
We could debate whether systemd-standalone-tmpfiles and
systemd-standalone-sysusers should be provided by a single binary
package, but since Fedora has already done this split this way, I would
simply follow here and use the same binary package names.
The relevant Fedora PR is
https://src.fedoraproject.org/rpms/systemd/pull-request/27 fwiw.
Thankfully, -Dstandalone-binaries=true doesn't require a separate, third
build variant (as with the udeb flavour), so build times shouldn't go up.
If there are no objections to this approach I would proceed and
implement it like this:
- Build systemd with -Dstandalone-binaries=true
- Install the standalone binaries in binary packages named
systemd-standalone-sysusers and systemd-standalone-tmpfiles
- Those binaries packages would only ship /bin/systemd-sysusers resp.
/bin/systemd-tmpfiles and have a Conflicts/Replaces: systemd
In case there are no objections to this plan, I would create a MR on salsa.
Thoughts?
Michael
signature.asc
Description: OpenPGP digital signature
Bug#666926: (no subject)
Enviado do meu smartphone Samsung Galaxy.
Bug#971798: Regression: lockPref no longer recognised in .js files
Am 07.10.20 um 14:43 schrieb Sergio Gelato: > Sorry, wrong commit. It was actually e7a23ec5 two months earlier. > Anyway, this is a change to > debian/patches/fixes/Allow-.js-preference-files-to-set-locked-prefs-with-lockP.patch > which looks at least superficially as a Debian-specific change (I > couldn't find the patch queue branch and dig into the history any > further). Please have a look at the date this patch was introduced! This patch is since 2008 applied to every version of Icedove and Thunderbird and did only a fine tuning since then. This was and is mostly done by Mike how is maintaining the Firefox package. At the time this patch was originally created I haven't contributed anything to Debian. I've to admit I even don't know exactly what this patch was and is about or why this patch was introduced. But as this patch is still used no change on the user side did happen. -- Regrads Carsten Schoenert
Bug#971786: [Pkg-javascript-devel] Bug#971786: src:pdf.js: please package new upstream version
Le 07/10/2020 à 17:03, Carsten Schoenert a écrit : > Hello Xavier, > > Am 07.10.20 um 16:29 schrieb Xavier: >> Le 07/10/2020 à 10:29, Carsten Schoenert a écrit : >> this modules looks useless in Debian: >> * no reverse-dependencies > > well, might simply because the version in Debian is far to old for all > possibly other packages. ;) > I haven't looked at packages that using now preshipped pdf.js. > >> * one binary mas to be removed (xul component, #906835) > > Yes, obviously. > >> * you're the first person who looks to it for a while ;-) >> >> Then do you need its update ? I can do it but it requires some work >> (zelenka.debian.org is working on it :-D). > > No hurry, I was today looking into upgrading kopano-webapp to 4.3 and > the Kopano is using pdf.js since version 4.0 here. > > There are other issues to solve, but using pdf.js from Debian would > prevent the requirement to use the embedded version. OK, I'll update it
Bug#971786: [Pkg-javascript-devel] Bug#971786: src:pdf.js: please package new upstream version
Hello Xavier, Am 07.10.20 um 16:29 schrieb Xavier: > Le 07/10/2020 à 10:29, Carsten Schoenert a écrit : > this modules looks useless in Debian: > * no reverse-dependencies well, might simply because the version in Debian is far to old for all possibly other packages. ;) I haven't looked at packages that using now preshipped pdf.js. > * one binary mas to be removed (xul component, #906835) Yes, obviously. > * you're the first person who looks to it for a while ;-) > > Then do you need its update ? I can do it but it requires some work > (zelenka.debian.org is working on it :-D). No hurry, I was today looking into upgrading kopano-webapp to 4.3 and the Kopano is using pdf.js since version 4.0 here. There are other issues to solve, but using pdf.js from Debian would prevent the requirement to use the embedded version. -- Regards Carsten
Bug#971784: libconfig-model-dpkg-perl: cme should not warn on "unknown dh-sequence-nodejs package"
Le 07/10/2020 à 16:53, Xavier a écrit :
> Le 07/10/2020 à 16:49, gregor herrmann a écrit :
>> On Wed, 07 Oct 2020 10:32:42 +0200, Xavier Guimard wrote:
>>
>>> Since all dh-sequence-* build dependencies are virtual packages, cme
>>> should ignore related warnings.
>>
>> Right, the handling of dh-sequence-* could be improved.
>>
>> Currently it's an array of static entries in
>> lib/Config/Model/Dpkg/Dependency.pm
>> (@virtual_list) which is then converted into a hash which is then
>> checked to exclude warnings. Maybe adding a regexp to
>>
>> if ( @res == 0 and not $virtual_hash{$pkg}) {
>>
>> would be enough? Like (untested pseudo-code)
>>
>> … and $pkg =! /^dh-sequence-.+/
>
> Yes, sounds enough
>
>> (and removing the list of dh-sequence-* packages from @virtual_list)
>
> easy: no dh-sequence-* for now in this file ;-)
oups, I was not looking at the good branch...
Bug#971784: libconfig-model-dpkg-perl: cme should not warn on "unknown dh-sequence-nodejs package"
Le 07/10/2020 à 16:49, gregor herrmann a écrit :
> On Wed, 07 Oct 2020 10:32:42 +0200, Xavier Guimard wrote:
>
>> Since all dh-sequence-* build dependencies are virtual packages, cme
>> should ignore related warnings.
>
> Right, the handling of dh-sequence-* could be improved.
>
> Currently it's an array of static entries in
> lib/Config/Model/Dpkg/Dependency.pm
> (@virtual_list) which is then converted into a hash which is then
> checked to exclude warnings. Maybe adding a regexp to
>
> if ( @res == 0 and not $virtual_hash{$pkg}) {
>
> would be enough? Like (untested pseudo-code)
>
> … and $pkg =! /^dh-sequence-.+/
Yes, sounds enough
> (and removing the list of dh-sequence-* packages from @virtual_list)
easy: no dh-sequence-* for now in this file ;-)
Bug#971784: libconfig-model-dpkg-perl: cme should not warn on "unknown dh-sequence-nodejs package"
On Wed, 07 Oct 2020 10:32:42 +0200, Xavier Guimard wrote:
> Since all dh-sequence-* build dependencies are virtual packages, cme
> should ignore related warnings.
Right, the handling of dh-sequence-* could be improved.
Currently it's an array of static entries in lib/Config/Model/Dpkg/Dependency.pm
(@virtual_list) which is then converted into a hash which is then
checked to exclude warnings. Maybe adding a regexp to
if ( @res == 0 and not $virtual_hash{$pkg}) {
would be enough? Like (untested pseudo-code)
… and $pkg =! /^dh-sequence-.+/
(and removing the list of dh-sequence-* packages from @virtual_list)
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Bettina Wegner: die rose
signature.asc
Description: Digital Signature
Bug#971800: ITP: erfs -- A free and encrypted cloud based network file system
Package: wnpp Severity: wishlist Owner: sky...@thc.org * Package name: erfs Version : 1.3 Upstream Author : skyper * URL : https://github.com/hackerschoice/erfs * License : GPL Programming Lang: bash Description : A free and encrypted cloud based network file system An easy-to-use, easy-to-setup, hassle-free secure file system with the encrypted data being stored on a remote cloud server without having to trust the server. All key material is created on the user's computer and never stored or transferred to the server. All data is locally encrypted (including the file name). The encrypted data (and only that!) is stored in the cloud. The data remains secure even if the cloud server is compromised. It does not need root or superuser privileges. No need to run your own server. All you need is the bash script (literally). It is one single command to add and use a file system: $ erfs mount aDe5F2ik3x35x7pfAEAWdC5Y ~/secure Why is it useful: It enables two users (behind NAT) to share data securely without the hassle of setting up a server or revealing their identity. Maintain: I plan to maintain it with good faith and to the best of my ability. I already have a sponsor (I hope).
Bug#971786: [Pkg-javascript-devel] Bug#971786: src:pdf.js: please package new upstream version
Le 07/10/2020 à 10:29, Carsten Schoenert a écrit : > Package: src:pdf.js > Severity: wishlist > > Dear Maintainer, > > the current version of pdf.js in Debian is heavily outdated. > Please consider to package a recent version. > > While writing this whishlist bug report version 2.6.347 is avaialable, > the most recent version in Debian is 1.5.188. > > Thanks > Carsten Hi, this modules looks useless in Debian: * no reverse-dependencies * one binary mas to be removed (xul component, #906835) * you're the first person who looks to it for a while ;-) Then do you need its update ? I can do it but it requires some work (zelenka.debian.org is working on it :-D). Cheers, Xavier
Bug#971542: Please enable HTSlib plugins
On 7 Oct 2020, at 14:16, Andreas Tille wrote: > > On Wed, Oct 07, 2020 at 09:36:06AM +, John Marshall wrote: >> --enable-plugins --with-plugin-dir='$(libdir)/htslib' >> --with-plugin-path='/usr/local/lib/htslib:/usr/local/libexec/htslib:$(plugindir)' > > OK, that's in Git now Great, thanks. >> BTW it looks like htslib-s3-plugin.7.gz has ben placed in libhts3 basically >> by default, although that is the right package for it. > > Sorry, I do not understand this sentence. There are lines in libhts-dev.install (now libhts3.install -- thanks) for man5, so I expected to see a line for man7 in some *.install file. But now I see there are also *.manpages files which take care of this file. So never mind then, my mistake. >> How can I verify / test the correct setting? > > What exactly do you mean? Test my lastest changes I mentioned above or > rather testing the package that is in unstable currently? Sorry, this was a reply to your previous question but my mail client garbled the exchange with its unintended rich text. You previously asked Andreas> How can I verify / test the correct setting? which I took to mean how do you verify that your plugin-dir and plugin-path configure settings are effective, i.e., how does one verify what plugin directories HTSlib is actually searching. And the answer is By observing the -DPLUGINPATH=… setting that goes past in the log when plugin.c is compiled; by running `strings` on libhts.so; or by seeing what directories are scanned via e.g. `strace htsfile foo:bar 2>&1|grep O_DIRECTORY`. (So no changes are needed. This is how you could check what plugin path settings are burnt into the library if you wanted to.) John
Bug#962421: closed by Xavier (pdf.js exists in sid)
Hi, Message https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962421#10 doesn't list any explanation for closing the issue. Has there been work on resolving it? Debian Bug Tracking System: > This is an automatic notification regarding your Bug report > which was filed against the libjs-pdf package: > > #962421: libjs-pdf for PDF.js was packaged for Debian Jessie but is missing > from Sid > > It has been closed by Xavier . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Xavier > by > replying to this email. > >
Bug#971742: proftpd-basic: Symlink navigation broken
Control: tags -1 + patch,pending Am 07.10.2020 um 12:17 teilte Andrea Capriotti mit: Hi, yes, it works: Tag patch + pending. H. -- #206401 http://counter.li.org OpenPGP_signature Description: OpenPGP digital signature
Bug#971790: Acknowledgement (thunderbird: Autocrypt is broken)
I realized there is already a bugreport upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1663116 signature.asc Description: PGP signature
Bug#905564: /etc/default/su
There is no /etc/default/su file by default, but if you create one and put ALWAYS_SET_PATH yes in it, then su *does* change the PATH variable, and this avoids the warning message from login. ii util-linux 2.33.1-0.1 amd64miscellaneous system utilities unicorn:~$ cat /etc/default/su ALWAYS_SET_PATH yes unicorn:~$ echo "$PATH" /home/greg/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin unicorn:~$ su Password: root@unicorn:/home/greg# echo "$PATH" /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin root@unicorn:/home/greg#
Bug#962194: lintian-brush: autopkgtest failure on s390x
control: forwarded -1 https://sourceforge.net/p/ruamel-yaml/tickets/360/ G.
Bug#969538: vips/ruby-vips: autopkgtest regression on arm64 and ppc64el
On Wed, Oct 7, 2020 at 3:39 PM Gianfranco Costamagna wrote: > According to upstream, this might fix the issue I'm not sure if Kleis Auke is part of upstream. But testing his fix on ARM64 - please give me some time as it's just an emulation for me and not very fast. Going to upload the fixed package if that works. Regards, Laszlo/GCS
Bug#971778: [debian-mysql] Bug#971778: mariadb-client-core-10.5: mariadb-embedded is missing
We removed it due to low or no use. It will s unclear what the use case even is. In an embedded scenario you most likely are better off compiling yourself a version that only has the parts your embedded system actually needs? Let's see if anybody else chips in here and if there was other consumers of this.
Bug#969538: vips/ruby-vips: autopkgtest regression on arm64 and ppc64el
According to upstream, this might fix the issue
diff -Nru vips-8.10.1/debian/changelog vips-8.10.1/debian/changelog
--- vips-8.10.1/debian/changelog2020-10-03 18:41:08.0 +0200
+++ vips-8.10.1/debian/changelog2020-10-07 13:20:49.0 +0200
@@ -1,3 +1,12 @@
+vips (8.10.1-2ubuntu1) groovy; urgency=medium
+
+ * debian/patches/143c815a0a85cb187bc6f690dab0555fd617063e.patch:
+- cherry-pick an upstream fix for autopkgtests on arm64 and ppc64el
+ ( See Debian bug: #969538 and
+https://github.com/libvips/libvips/issues/1846 )
+
+ -- Gianfranco Costamagna Wed, 07 Oct 2020
13:20:49 +0200
+
vips (8.10.1-2) unstable; urgency=medium
* Backport upstream fix for docs building with gobject-introspection 1.66+
diff -Nru
vips-8.10.1/debian/patches/143c815a0a85cb187bc6f690dab0555fd617063e.patch
vips-8.10.1/debian/patches/143c815a0a85cb187bc6f690dab0555fd617063e.patch
--- vips-8.10.1/debian/patches/143c815a0a85cb187bc6f690dab0555fd617063e.patch
1970-01-01 01:00:00.0 +0100
+++ vips-8.10.1/debian/patches/143c815a0a85cb187bc6f690dab0555fd617063e.patch
2020-10-07 13:20:49.0 +0200
@@ -0,0 +1,37 @@
+Origin:
https://github.com/kleisauke/libvips/commit/143c815a0a85cb187bc6f690dab0555fd617063e
+Bug: https://github.com/libvips/libvips/issues/1846
+From 143c815a0a85cb187bc6f690dab0555fd617063e Mon Sep 17 00:00:00 2001
+From: kleisauke
+Date: Wed, 7 Oct 2020 15:20:18 +0200
+Subject: [PATCH] Try a patch for libvips/libvips#1846
+
+---
+ libvips/morphology/morph.c | 8
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/libvips/morphology/morph.c b/libvips/morphology/morph.c
+index 7f7ffc485..07a6fc517 100644
+--- a/libvips/morphology/morph.c
b/libvips/morphology/morph.c
+@@ -449,8 +449,8 @@ vips_dilate_gen( VipsRegion *or,
+ seq->ss = 0;
+ seq->cs = 0;
+ for( y = 0; y < M->Ysize; y++ )
+- for( x = 0; x < M->Xsize; x++ )
+- switch( t[x] ) {
++ for( x = 0; x < M->Xsize; x++, t++ )
++ switch( *t ) {
+ case 255:
+ soff[seq->ss++] =
+ VIPS_REGION_ADDR( ir,
+@@ -560,8 +560,8 @@ vips_erode_gen( VipsRegion *or,
+ seq->ss = 0;
+ seq->cs = 0;
+ for( y = 0; y < M->Ysize; y++ )
+- for( x = 0; x < M->Xsize; x++ )
+- switch( t[x] ) {
++ for( x = 0; x < M->Xsize; x++, t++ )
++ switch( *t ) {
+ case 255:
+ soff[seq->ss++] =
+ VIPS_REGION_ADDR( ir,
diff -Nru vips-8.10.1/debian/patches/series vips-8.10.1/debian/patches/series
--- vips-8.10.1/debian/patches/series 2020-10-03 18:41:08.0 +0200
+++ vips-8.10.1/debian/patches/series 2020-10-07 13:20:49.0 +0200
@@ -1,2 +1,3 @@
reproducible-build.patch
fix_build_with_goi_1.66+.patch
+143c815a0a85cb187bc6f690dab0555fd617063e.patch
G.
Bug#971790: thunderbird: Autocrypt is broken
Package: thunderbird Version: 1:78.3.1-2~deb10u2 Severity: normal Dear Maintainer, I updated thunderbird and migrated PGP settings via enigmail 2.2.x as suggested, but autocrypt is no longer working. I wrote an email to a contact where autocrypt worked before but the email was sent unencrypted although I expected it to be encrypted. I am not sure if this issue should even get a higher severity than normal as sending sensitive information unencrypted while expected it being encrypted might be dangerous. Best regards, Martin -- System Information: Debian Release: 10.6 APT prefers stable APT policy: (900, 'stable'), (500, 'stable-updates'), (500, 'stable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-11-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages thunderbird depends on: ii debianutils 4.8.6.1 ii fontconfig 2.13.1-2 ii libatk1.0-0 2.30.0-2 ii libbotan-2-92.9.0-2 ii libbz2-1.0 1.0.6-9.2~deb10u1 ii libc6 2.28-10 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libdbus-1-3 1.12.20-0+deb10u1 ii libdbus-glib-1-20.110-4 ii libevent-2.1-6 2.1.8-stable-4 ii libffi6 3.2.1-9 ii libfontconfig1 2.13.1-2 ii libfreetype62.9.1-3+deb10u1 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-02.58.3-2+deb10u2 ii libgtk-3-0 3.24.5-1 ii libjson-c3 0.12.1+ds-2+deb10u1 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libstdc++6 8.3.0-6 ii libx11-62:1.6.7-1+deb10u1 ii libx11-xcb1 2:1.6.7-1+deb10u1 ii libxcb-shm0 1.13.1-2 ii libxcb1 1.13.1-2 ii libxext62:1.3.3-1+b2 ii libxrender1 1:0.9.10-1 ii psmisc 23.2-1 ii x11-utils 7.7+4 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages thunderbird recommends: ii hunspell-ar [hunspell-dictionary]3.2-1.1 ii hunspell-be [hunspell-dictionary]0.53-3 ii hunspell-bg [hunspell-dictionary]1:6.2.0-1 ii hunspell-ca [hunspell-dictionary]3.0.3+repack1-1 ii hunspell-de-at [hunspell-dictionary] 20161207-7 ii hunspell-de-ch [hunspell-dictionary] 20161207-7 ii hunspell-de-de [hunspell-dictionary] 20161207-7 ii hunspell-en-gb [hunspell-dictionary] 1:6.2.0-1 ii hunspell-en-us [hunspell-dictionary] 1:2018.04.16-1 ii hunspell-eu [hunspell-dictionary]0.5.20151110-4 ii hunspell-fr-classical [hunspell-dictionary] 1:6.3-2 ii hunspell-gl [hunspell-dictionary]1:6.2.0-1 ii hunspell-hr [hunspell-dictionary]1:6.2.0-1 ii hunspell-hu [hunspell-dictionary]1:6.2.0-1 ii hunspell-it [hunspell-dictionary]1:6.2.0-1 ii hunspell-kk [myspell-dictionary] 1.1-2 ii hunspell-kmr [hunspell-dictionary] 1:6.2.0-1 ii hunspell-ko [hunspell-dictionary]0.7.1-1 ii hunspell-lt [hunspell-dictionary]1:6.2.0-1 ii hunspell-lv [hunspell-dictionary]1.3.0-5 ii hunspell-ne [hunspell-dictionary]1:6.2.0-1 ii hunspell-pl [hunspell-dictionary]1:6.2.0-1 ii hunspell-pt-br [hunspell-dictionary] 1:6.2.0-1 ii hunspell-pt-pt [hunspell-dictionary] 1:6.2.0-1 ii hunspell-ro [hunspell-dictionary]1:6.2.0-1 ii hunspell-ru [hunspell-dictionary]1:6.2.0-1 ii hunspell-se [hunspell-dictionary]1.0~beta6.20081222-1.2 ii hunspell-sl [hunspell-dictionary]1:6.2.0-1 ii hunspell-sr [hunspell-dictionary]1:6.2.0-1 ii hunspell-sv [hunspell-dictionary]1:6.2.0-1 ii hunspell-th [hunspell-dictionary]1:6.2.0-1 ii hunspell-vi [hunspell-dictionary]1:6.2.0-1 ii myspell-cs [myspell-dictionary] 20040229-5.2 ii myspell-da [myspell-dictionary] 1.6.36-11 ii myspell-eo [myspell-dictionary] 2.1.2000.02.25-57 ii myspell-es [myspell-dictionary] 1.11-15 ii myspell-et [myspell-dictionary] 1:20030606-30 ii myspell-ga [myspell-dictionary] 2.0-27 ii myspell-he [myspell-dictionary] 1.4-3 ii myspell-nb [myspell-dictionary] 2.2-4 ii myspell-nl [myspell-dictionary] 1:2.10-5 ii myspell-nn [myspell-dictionary] 2.2-4 ii myspell-sk [myspell-dictionary] 0.5.5a-2.3 ii myspell-sq [myspell-dictionary] 1.6.4-1 ii myspell-uk [myspell-dictionary] 1.7.1-2 Versions of packages thunderbird suggests: ii apparmor 2.13.2-10 pn fonts-lyx ii libgssapi-krb5-2 1.17-3 ii libgtk2.0-0 2.24.32-3 -- no debconf
Bug#971542: Please enable HTSlib plugins
On Wed, Oct 07, 2020 at 09:36:06AM +, John Marshall wrote: > > There is no need to patch configure.ac to alter this. Just add > --with-plugin-dir='$(libdir)/htslib' as another configure option. > > I see Debian policy at last now blesses FHS 3.0, which includes libexec. > However you may not wish to be in the vanguard of this, so that > /usr/lib/ARCH/htslib would indeed appear to be the existing-Debian-style > appropriate place under /usr. For /usr/local, any third-party instructions > are likely to recommend installing their plugin into > /usr/local/libexec/htslib, so I would recommend configuring with > > --enable-plugins --with-plugin-dir='$(libdir)/htslib' > --with-plugin-path='/usr/local/lib/htslib:/usr/local/libexec/htslib:$(plugindir)' OK, that's in Git now > as being the most flexible for your users. (These directories are just > scanned for files matching hfile_*.so; it is not an error if any of them does > not exist.) > > BTW it looks like htslib-s3-plugin.7.gz has ben placed in libhts3 basically > by default, although that is the right package for it. Sorry, I do not understand this sentence. > IMHO that would also be the right package for man5/*.5.gz as these are man > pages aimed at users (not just developers) but YMMV. Done in Git. > How can I verify / test the correct setting? What exactly do you mean? Test my lastest changes I mentioned above or rather testing the package that is in unstable currently? > By observing the -DPLUGINPATH=… setting that goes past in the log when > plugin.c is compiled; by running `strings` on libhts.so; or by seeing what > directories are scanned via e.g. `strace htsfile foo:bar 2>&1|grep > O_DIRECTORY`. Sorry, I do not understand what you want to express / want me to change. Thanks a lot for your helpful hints Andreas. -- http://fam-tille.de
Bug#961491: fixed in sympa 6.2.40~dfsg-5
Hi, I noticed this local root escalation yesterday and I'm working on a Stretch LTS update. See also https://salsa.debian.org/sympa-team/sympa/-/merge_requests/1 Are there plans to update buster? Cheers! Sylvain
Bug#971798: Regression: lockPref no longer recognised in .js files
* Carsten Schoenert [2020-10-07 14:29:31 +0200]: > Am 07.10.20 um 13:47 schrieb Sergio Gelato: > > Commit a21b649 (first included in 1:77.0~b1-1) silently changed the > > spelling of lockPref to lock_pref . > > Are you sure? Sorry, wrong commit. It was actually e7a23ec5 two months earlier. Anyway, this is a change to debian/patches/fixes/Allow-.js-preference-files-to-set-locked-prefs-with-lockP.patch which looks at least superficially as a Debian-specific change (I couldn't find the patch queue branch and dig into the history any further).
Bug#971798: Regression: lockPref no longer recognised in .js files
Am 07.10.20 um 13:47 schrieb Sergio Gelato:
> Commit a21b649 (first included in 1:77.0~b1-1) silently changed the
> spelling of lockPref to lock_pref .
Are you sure?
This commit is about modifying the patch queue. I don't see any changes
here regarding a switch of using lockPref over lock_pref.
> $ git show a21b649 --summary
> commit a21b6495154e02f772c44c95ce237c6e47e116f8
> Author: Carsten Schoenert
> Date: Thu May 7 18:28:34 2020 +0200
>
> rebuild patch queue from patch-queue branch
>
> removed patch:
> lower-down-required-version-on-NSS3.patch
>
> added patches:
> fixes/Bug-1634994-fix-disable-av1-r-tnikkel.patch
> fixes/Bug-1635671-Upgrade-typename-to-1.12.0.-r-emilio.patch
>
> create mode 100644
> debian/patches/fixes/Bug-1634994-fix-disable-av1-r-tnikkel.patch
> create mode 100644
> debian/patches/fixes/Bug-1635671-Upgrade-typename-to-1.12.0.-r-emilio.patch
> delete mode 100644 debian/patches/lower-down-required-version-on-NSS3.patch
...
> This breaking change doesn't seem to have been documented anywhere:
> not in debian/changelog, not in debian/thunderbird.NEWS.
If there was a change than this change was introduced by upstream not by
me or Debian. So how would we need to document such things that we even
don't know, if I'd be aware of such changes I for sure would have
documented it somehow.
> Moreover, it looks like parts of the test suite (e.g.,
> extensions/pref/autoconfig/test/unit/autoconfig-all.cfg) are still
> referencing the old spelling. Are these files being used?
I don't know, we don't do any usage of the upstream test suites. I guess
you'd need to ask these MZLNA.
The only change about handling of preferences I know of did happen
before 1:60.0-1.
> $ git show 90a1d9e
> commit 90a1d9eb61f1cf502ef55a7df38030e66c86cb4e
> Author: Carsten Schoenert
> Date: Wed Jul 11 22:00:36 2018 +0200
>
> sticky prefs: use the new syntax in vendor.js
>
> The syntax for locked preferences has been changed a while ago, it's
> time to adjust the entry within vendor.js to disable automatic updates
> for AddOns.
>
> diff --git a/debian/vendor.js b/debian/vendor.js
> index 15bcb62bfc8..1a5daea0a2b 100644
> --- a/debian/vendor.js
> +++ b/debian/vendor.js
> @@ -1,2 +1,2 @@
> // Forbid application updates
> -lockPref("app.update.enabled", false);
> +pref("app.update.enabled", false, locked);
...
> The most annoying implication of this change is that custom .js files
> must be updated at the same time as Thunderbird itself. It would have
> been more convenient if both spellings had been allowed during a
> transition period.
I've no real idea what your problem is about.
The syntax of /e/t/pref/thunderbird.js hasn't changed since it got
introduced, at this time it was called icedove.js of course.
So any other user specific file within that folder doesn't need adjustments.
The same is true for the other shipped files in
/usr/lib/thunderbird/defaults/pref/.
Sorry, as much I'd like to help, but some information is missing to give
some more useful feedback.
--
Regards
Carsten Schoenert
Bug#971584: libsane1: Scanner no more identified after upgrade to 1.0.31 version
Package: libsane1 Version: 1.0.31-2 Followup-For: Bug #971584 Same here with an Epson Perfection 1260 (plustek backend). -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libsane1 depends on: ii acl2.2.53-8 ii adduser3.118 ii libavahi-client3 0.8-3 ii libavahi-common3 0.8-3 ii libc6 2.31-3 ii libcairo2 1.16.0-4 ii libcurl3-gnutls7.72.0-1 ii libgcc-s1 10.2.0-13 ii libglib2.0-0 2.66.0-2 ii libgphoto2-6 2.5.25-3 ii libgphoto2-port12 2.5.25-3 ii libieee1284-3 0.2.11-14 ii libjpeg62-turbo1:2.0.5-1.1 ii libpng16-161.6.37-3 ii libpoppler-glib8 20.09.0-2 ii libsane-common 1.0.31-2 ii libsnmp40 5.9+dfsg-3 ii libstdc++6 10.2.0-13 ii libtiff5 4.1.0+git191117-2 ii libusb-1.0-0 2:1.0.23-2 ii libxml22.9.10+dfsg-6 ii udev 246.6-1 Versions of packages libsane1 recommends: ii ipp-usb 0.9.13-1 ii sane-utils 1.0.31-2 Versions of packages libsane1 suggests: ii avahi-daemon 0.8-3 pn hplip -- no debconf information
Bug#971799: mz: Immediate crash when starting interactive mode
This also affects the "mausezahn" command from the netsniff-ng package. When I build myself from Git, it does not crash. This (closed) upstream issue might be related: https://github.com/netsniff-ng/netsniff-ng/issues/195 The Debian packages have not been updated since. Regards Stephan
Bug#970479: RM: syncthing [armel armhf i386 mipsel] -- ANAIS; package is not built on these architectures
Badger for Syncthing is just an experiment (need to set an env var to use it), and it's more or less a failed one at this point. I opened an MR with a patch to remove it. It's large, but given it just removes code shouldn't be that much of a burden to carry: https://salsa.debian.org/go-team/packages/syncthing/-/merge_requests/2
Bug#971799: mz: Immediate crash when starting interactive mode
Package: mz Version: 0.40-1.1+b1 Severity: important Tags: a11y ipv6 Dear Maintainer, mz (mausezahn) is crashing immediately when launched with interactive mode. As a result, interactive mode cannot be used. How to reproduce? # mz -x The problem exists in Buster and Sid (and also Ubuntu 20.04). Note that according to the manpage, the interactive mode uses a more efficient implementation and is therefore crucial for effective testing networks with the tool. -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-11-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mz depends on: ii libc6 2.28-10 ii libcli1.9 1.9.7-2+b11 ii libnet1 1.1.6+dfsg-3.1 ii libpcap0.8 1.8.1-6 mz recommends no packages. Versions of packages mz suggests: pn python-matplotlib -- no debconf information
Bug#971696: linux-image-4.19.0-11-armmp: network hangs, oops in ath9k_htc after upgrade
Sascha Silbe writes: > since the last kernel update (from linux-image-armmp:armhf > 4.19+105+deb10u5 / linux-image-4.19.0-10-armmp 4.19.132-1 to > linux-image-armmp 4.19+105+deb10u6 / linux-image-4.19.0-11-armmp > 4.19.146-1) our BeagleBone Black systems with AR9271 based WLAN adapter > (ath9k_htc driver) print a kernel warning or oops during boot and all > network related system calls hang, breaking not just WLAN but also > ethernet: [...] > If there's a git repository I can *cross*-build from with reasonable > effort I can try git bisect. I was unable to reproduce this bug using a kernel cross-built from tag debian/4.19.146-1 in the repository https://salsa.debian.org/kernel-team/linux.git on a Buster amd64 host or a Stretch amd64 host. I used the config from the official kernel with only CONFIG_LOCALVERSION and CONFIG_SYSTEM_TRUSTED_KEYS changed. Is debian/4.19.146-1 the right tag for the kernel sources used by linux-image-4.19.0-11-armmp 4.19.146-1? If so, why does this bug only happen with the official package but not with one I built locally? One thing that seems odd is that the package built from tag debian/4.19.146-1 identifies itself as 4.19.87, not 4.19.146. Sascha signature.asc Description: PGP signature
Bug#971798: Regression: lockPref no longer recognised in .js files
Package: thunderbird Version: 1:78.3.1-2~deb10u2 Commit a21b649 (first included in 1:77.0~b1-1) silently changed the spelling of lockPref to lock_pref . This breaking change doesn't seem to have been documented anywhere: not in debian/changelog, not in debian/thunderbird.NEWS. Moreover, it looks like parts of the test suite (e.g., extensions/pref/autoconfig/test/unit/autoconfig-all.cfg) are still referencing the old spelling. Are these files being used? The most annoying implication of this change is that custom .js files must be updated at the same time as Thunderbird itself. It would have been more convenient if both spellings had been allowed during a transition period.
Bug#971782: Place files not symlinks in /u/s/fonts
Package: fonts-font-awesome Version: 5.0.10+really4.7.0~dfsg-2 Severity: normal Hi, I would like to ask if it's possible to move the files from /usr/share/fonts-font-awesome/fonts to /usr/share/fonts. I'm using AppArmor and this allows access to files underneath /usr/share/fonts. But if there are symlinks to files in other directories, the access gets prohibited. Regards Jörg -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information signature.asc Description: PGP signature
Bug#971797: RFP: xlivebg -- Live wallpapers for the X window system
Package: wnpp Severity: wishlist * Package name: xlivebg Version : 1.0 Upstream Author : John Tsiombikas * URL : http://nuclear.mutantstargoat.com/sw/xlivebg * License : GPL Programming Lang: C Description : Live wallpapers for the X window system xlivebg is a live wallpaper framework, and collection of live wallpapers, for the X window system. xlivebg is independent of window managers and desktop environments, and should work with any of them, or even with no window manager at all. Live wallpapers are a way to have an animated desktop background, instead of a simple static image. They are essentially programs which use OpenGL to display an animated moving image in place of the traditional wallpaper. Live wallpapers are written as plugins for xlivebg. All X11-specific initialization, OpenGL context creation, and root window management are performend by xlivebg; the live wallpaper plugins need only provide a draw function, which is called by xlivebg at (approximately) fixed intervals. An effort has been made to keep the number of dependencies as low as possible. The main xlivebg program needs Xlib (with libXrandr), OpenGL, libpng, zlib, and libjpeg. The GUI configuration tool depends on motif, and the bundled video playback wallpaper adds the ffmpeg libraries to the list of dependencies.
Bug#971778: [debian-mysql] Bug#971778: mariadb-client-core-10.5: mariadb-embedded is missing
Hi! Indeed https://github.com/MariaDB/server/blob/10.4/debian/not-installed#L4 It seems that the move was done in 10.4 to not deploy it anymore due to it's huge size. Otto, do you know if this binary is provided by another deb or if there is any way to get it through Debian repositories. Faustin signature.asc Description: PGP signature
Bug#971796: hexedit: regression: crash (SIGFPE) with empty files
Package: hexedit Version: 1.5-1 Severity: important Usertags: crash hexedit crashes (SIGFPE) with empty files. This did not happen in past versions, so this is a regression. I'm not sure when it occurred. I am assuming that the SIGFPE is caused by a division by zero since it doesn't occur when the file isn't empty. $ > foo $ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex 'thread apply all bt full' -tty=/dev/null --args hexedit foo [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGFPE, Arithmetic exception. 0x7738 in display () at display.c:208 208 display.c: No such file or directory. #0 0x7738 in display () at display.c:208 #1 0x6515 in main (argc=, argv=) at hexedit.c:104 #0 0x7738 in display () at display.c:208 i = #1 0x6515 in main (argc=, argv=) at hexedit.c:104 No locals. Thread 1 (Thread 0x77d43740 (LWP 486589)): #0 0x7738 in display () at display.c:208 i = #1 0x6515 in main (argc=, argv=) at hexedit.c:104 No locals. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages hexedit depends on: ii libc62.31-3 ii libncurses6 6.2+20200918-1 ii libtinfo66.2+20200918-1 hexedit recommends no packages. hexedit suggests no packages. -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#969538: vips/ruby-vips: autopkgtest regression on arm64 and ppc64el
control: forwarded -1 https://github.com/libvips/libvips/issues/1846 thanks G.
Bug#971795: ITP: git-pw -- tool for integrating Git with Patchwork
Package: wnpp Severity: wishlist Owner: Dimitri John Ledkov X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: git-pw Version : 2.0.0 Upstream Author : Stephen Finucane https://github.com/stephenfin * URL : https://github.com/getpatchwork/git-pw * License : Expat Programming Lang: Python Description : tool for integrating Git with Patchwork Patchwork is the web-based patch tracking system, this tool helps to integrate with it. It was requested at Plumbers to have this in distro's to aid development & code review work.
Bug#971794: fakeroot: testsuite fails on mipsel
Source: fakeroot Version: 1.25.2-1 Severity: serious Tags: patch ftbfs Justification: fails to build from source (but built successfully in the past) Hi, The latest upload of fakeroot got support for statx added, thanks for that. Unfortunately it doesn't work on mipsel, as spotted by the testsuite: | make[5]: Entering directory '/<>/obj-sysv/test' | FAIL: t.chmod_dev | PASS: t.cp-a | PASS: t.echoarg | PASS: t.falsereturn | FAIL: t.mknod | PASS: t.no_ld_preload | PASS: t.no_ld_preload_link | PASS: t.option | PASS: t.tar | PASS: t.touchinstall | PASS: t.truereturn | PASS: t.xattr | | Testsuite summary for fakeroot 1.25.2 | | # TOTAL: 12 | # PASS: 10 | # SKIP: 0 | # XFAIL: 0 | # FAIL: 2 | # XPASS: 0 | # ERROR: 0 | | See test/test-suite.log | Please report to cl...@debian.org | The full build log is available there: https://buildd.debian.org/status/fetch.php?pkg=fakeroot=mipsel=1.25.2-1=1601883875=0 The issue is due to mixes between struct stat and INT_STRUCT_STAT as spotted by this warning: | ../libfakeroot.c: In function ‘statx’: | ../libfakeroot.c:2466:17: warning: passing argument 1 of ‘send_get_stat’ from incompatible pointer type [-Wincompatible-pointer-types] | 2466 | SEND_GET_STAT(,ver); | | ^~~ | | | | | struct stat64 * | ../libfakeroot.c:88:42: note: in definition of macro ‘SEND_GET_STAT’ |88 | #define SEND_GET_STAT(a,b) send_get_stat(a) | | ^ | In file included from ../libfakeroot.c:60: | ../communicate.h:174:40: note: expected ‘struct stat *’ but argument is of type ‘struct stat64 *’ | 174 | extern void send_get_stat(struct stat *buf); | | ~^~~ The attached patch fixes the issue. With it the warning is gone, the testsuite passes and the package builds successfully on mipsel. Regards, Aurelien --- fakeroot-1.25.2.orig/libfakeroot.c +++ fakeroot-1.25.2/libfakeroot.c @@ -102,6 +102,7 @@ #define INT_NEXT_FSTATAT(a,b,c,d) NEXT_FSTATAT64(_STAT_VER,a,b,c,d) #define INT_SEND_STAT(a,b) SEND_STAT64(a,b,_STAT_VER) #define INT_SEND_GET_XATTR(a,b) SEND_GET_XATTR64(a,b,_STAT_VER) +#define INT_SEND_GET_STAT(a,b) SEND_GET_STAT64(a,b) #else #define INT_STRUCT_STAT struct stat #define INT_NEXT_STAT(a,b) NEXT_STAT(_STAT_VER,a,b) @@ -110,6 +111,7 @@ #define INT_NEXT_FSTATAT(a,b,c,d) NEXT_FSTATAT(_STAT_VER,a,b,c,d) #define INT_SEND_STAT(a,b) SEND_STAT(a,b,_STAT_VER) #define INT_SEND_GET_XATTR(a,b) SEND_GET_XATTR(a,b,_STAT_VER) +#define INT_SEND_GET_STAT(a,b) SEND_GET_STAT(a,b) #endif #include @@ -2463,7 +2465,7 @@ int statx (int dirfd, const char *path, r=INT_NEXT_FSTATAT(dirfd, path, , flags); if(r) return -1; - SEND_GET_STAT(,ver); + INT_SEND_GET_STAT(,ver); r=next_statx(dirfd, path, flags, mask, buf); if(r)
