Bug#886012: ITP: ptpython -- Alternative Python Prompt
Package is tested and ready for upload to NEW, waiting on prompt-toolkit 3.0.16 update (see #983556). Regards, Daniel
Bug#983557: Allow to build packages without udebs
Package: src:util-linux Version: 2.36.1-7 Tags: patch Allow to build packages without udebs, adding a profile. patch at http://launchpadlibrarian.net/525153751/util-linux_2.36.1-7ubuntu1_2.36.1-7ubuntu2.diff.gz
Bug#983523: general: some WWW sites no longer work neither in Firefox nor in Chrome
On Fri, Feb 26 2021 at 3:26 +00, Paul Wise wrote: > On Thu, Feb 25, 2021 at 6:45 PM Janusz S. Bień wrote: > >> Anyway a clue should be provided by the fact the both (perhaps all?) >> browsers are affected. The things broke several weeks ago, perhaps after >> the upgrade to 10.8. > > Please try some of the following things to narrow down where the problem is: Thank you very much for a constructive answer. [...] > Use the Debian wayback archive to switch back to an older version of > the browsers to test if this is caused by the Debian upgrade or not. I have some earlier version of Debian on virtual machines and I see that my hypothesis that the culprit is the recent upgrade was wrong. The problem occurs already in a December version. I will investigate first the console output for the chat site, there are some messages which can give a hint. When I click to select an item on the other site there is no console output at all. Best regards Janusz -- , Janusz S. Bien emeryt (emeritus) https://sites.google.com/view/jsbien
Bug#983424: plocate-updatedb.service: PrivateTmp=true blocks indexing /tmp when removed from PRUNEPATHS
On Fri, Feb 26, 2021 at 09:59:00AM +0800, Paul Wise wrote: > Well, you change the config, and it is still broken even though you > changed the config, but you don't notice that, later on you do notice > that, but you don't understand systemd so you don't know that it could > have broken that and cannot figure out how to fix it so you contact the > developers of plocate to find out, and they say to fix PrivateTmp too > and then you wonder why you need to make essentially the same change to > the settings of another program rather than just the plocate settings. > > I think this is a fairly poor user experience for this situation. Well, what do you think is the right fix? Setting PrivateTmp=false, reducing security for everyone except the tiny minority who wants /tmp indexed? Having something parse PRUNEPATHS and synthesize a systemd unit from that? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#983556: new upstream (3.0.16; needed for ptpython)
Package: prompt-toolkit Hi, I'd like to upload ptpython to debian which requires prompt-toolkit 3.0.16. Can you please upload it to experimental? I've verified and tested that the current debian packaging from 3.0.14 does not any changes for 3.0.16, as well as tested it with ptpython. In case you'll need a sponsor, I'm happy to do so. Regards, Daniel
Bug#981846: python-argcomplete: multiple tests failure
Package: python-argcomplete Version: 1.8.1-1 Followup-For: Bug #981846 Control: reopen -1 The issue is not fixed in the latest NMU, i.e. 1.8.1-1.4 Attached is full build log -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads) Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python-argcomplete depends on: pn python python-argcomplete recommends no packages. python-argcomplete suggests no packages. $ debspawn build bullseye debspawn 0.4.1 on priyasi at 2021-02-26 12:42:30 UTC+0530 ╔╗ ║ Package build (from directory)║ ╚╝ ┌─┐ │ Creating source package│ └─┘ dpkg-buildpackage: info: source package python-argcomplete dpkg-buildpackage: info: source version 1.8.1-1.4 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Sebastian Ramacher dpkg-source --before-build . dpkg-buildpackage: warning: building a source package without cleaning up as you asked; it might contain undesired files dpkg-source -b . dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building python-argcomplete using existing ./python-argcomplete_1.8.1.orig.tar.gz dpkg-source: warning: upstream signing key but no upstream tarball signature dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: building python-argcomplete in python-argcomplete_1.8.1-1.4.debian.tar.xz dpkg-source: info: building python-argcomplete in python-argcomplete_1.8.1-1.4.dsc dpkg-genbuildinfo --build=source dpkg-genchanges --build=source >../python-argcomplete_1.8.1-1.4_source.changes dpkg-genchanges: info: not including original source code in upload dpkg-source --after-build . dpkg-buildpackage: info: binary and diff upload (original source NOT included) ╔═══╗ ║ Package build║ ╚═══╝ Package: python-argcomplete Version: 1.8.1-1.4 Distribution: bullseye Architecture: amd64 dpkg-source: warning: extracting unsigned source package (/var/tmp/Debian-Build/temp/python-argcomplete-1.8.1/../python-argcomplete_1.8.1-1.4.dsc) dpkg-source: info: extracting python-argcomplete in python-argcomplete-1.8.1 dpkg-source: info: unpacking python-argcomplete_1.8.1.orig.tar.gz dpkg-source: info: unpacking python-argcomplete_1.8.1-1.4.debian.tar.xz dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: applying py3k-scripts.patch dpkg-source: info: applying py3k-tests.patch Free space in workspace: 45.1GiB ┌───┐ │ Preparing container for build│ └───┘ Get:1 http://deb.debian.org/debian bullseye InRelease [142 kB] Get:2 http://deb.debian.org/debian bullseye/main amd64 Packages.diff/Index [63.6 kB] Ign:2 http://deb.debian.org/debian bullseye/main amd64 Packages.diff/Index Get:3 http://deb.debian.org/debian bullseye/main Translation-en.diff/Index [63.6 kB] Get:4 http://deb.debian.org/debian bullseye/main amd64 Packages [8210 kB] Get:5 http://deb.debian.org/debian bullseye/main Translation-en T-2021-02-26-0200.39-F-2021-02-02-1403.30.pdiff [112 kB] Get:5 http://deb.debian.org/debian bullseye/main Translation-en T-2021-02-26-0200.39-F-2021-02-02-1403.30.pdiff [112 kB] Fetched 8591 kB in 8s (1110 kB/s) Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... The following NEW packages will be installed: libmd0 The following packages will be upgraded: apt apt-utils base-passwd bash bsdextrautils bsdutils e2fsprogs fdisk gcc-9-base gpgv iproute2 iputils-ping libacl1 libapparmor1 libapt-pkg6.0 libblkid1 libbsd0 libcom-err2 libdb5.3 libelf1 libext2fs2 libfdisk1 libgcrypt20 libjansson4 libjson-c5 libmount1 libnftables1 libpam-modules libpam-modules-bin libpam-runtime libpam0g libperl5.32 libpython3.9-minimal libselinux1 libsmartcols1 libss2 libssl1.1 libsystemd0 libudev1 libuuid1 libzstd1 linux-libc-dev logsave mount nano nftables perl perl-base perl-modules-5.32 python3.9-minimal systemd systemd-sysv systemd-timesyncd tasksel tasksel-data udev util-linux 57 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 8200 kB/35.3 MB of archives. After this operation, 266 kB of additional disk space will be used. Get:1 http://deb.debian.org/debian bullseye/main amd64 bash amd64 5.1-2+b1 [1417 kB] Get:2 http://deb.debian.org/debian bullseye/main amd64 bsdutils amd64 1:2.36.1-7
Bug#983100: libboost-python1.74-dev: multiarchify python dependency
Hi Giovanni, On Thu, Feb 25, 2021 at 08:52:07PM +0100, Giovanni Mascellani wrote: > I'd say that's ok for me. Could you please NMU? I don't think this would be appropriate given the freeze policy. While this fixes an issue, I think it would be better to defer this for bullseye. Helmut
Bug#982892: ITP: binutils-or1k-elf -- GNU binary utilities for the Open RISC 1000 processors
Control: tags -1 + moreinfo On Thu, Feb 25, 2021 at 10:54:39AM +0100, Nicolas Boulenguez wrote: > The maintainers of the 'binutils' .dsc package deliberately support a > limited set of targets. Outside this set, separate .dsc packages are > recommended (even without patches) so that an issue affecting an > architecture does not block all other ones. That limited set even includes alpha, m68k riscv64 and sh4. I'd say that or1k is not a stranger among these. If that really is an issue, I strongly recommend not adding one binutils package per architecture, but instead adding a binutils-ports (or similar) package that collects the more exotic architectures. This would nicely resemble the split already done for gcc (gcc-10-cross, gcc-10-cross-ports). But really, sticking them in the main binutils package makes things a lot easier for bootstrapping. The major downside of having many of these binutils-* packages is that they lag behind the main binutils. You keep running into bugs already fixed in src:binutils, because those other packages are not reuploaded as frequently. Not a hypothetical issue. I'm pained by it regularly on the gcc side. The fewer source packages we have here, the better the chances are of keeping them up to date. I'm tagging the itp moreinfo for this reason. Helmut
Bug#975390: RFS: dragonfly-reverb/3.2.1-1 [ITP] -- Reverb effect plugins (metapackage)
tag 975390 - moreinfo thanks Hi Dennis, I will take another look over the weekend. Hopefully my gpg key issue is sorted out now. I am on a different machine, so I can't check the exact lintian warning. I think it was the "manpage missing" warnings, which have changed name and lintian does the divert automatically. I run lintian as a pbuilder hook (with all the pedantic options etc.), so it would have been the latest lintian in sid at that time. No matter. It is something that can be sorted out at the next upload anyway (if required). Cheers, Ross On 25.02.2021 23.57, Dennis Braun wrote: Hi Ross, thank you for the review! I think ive fixed everything. I also added 2 patches to fix cross building and fix building without sse. about 5., i dont know which new tag you mean. my build on sid didnt had a different tag. and about 12., yeah all plugins should be installed. Best, Dennis
Bug#983314: linux-base: perf fails to report that linux-perf-5.10 is not installed
On Fri, 2021-02-26 at 06:47 +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 + confirmed
>
> Hi Bart,
>
> On Mon, Feb 22, 2021 at 11:57:56AM +0100, Bart Martens wrote:
> > Package: linux-base
> > Version: 4.6
> > Severity: minor
> > File: /usr/bin/perf
> >
> > Observed behavior:
> >
> > $ perf
> > /usr/bin/perf: line 13: exec: perf_5.10: not found
> >
> > Expected behavior:
> >
> > $ perf
> > /usr/bin/perf: line 14: exec: perf_5.10: not found
> > E: linux-perf-5.10 is not installed.
FYI Debian Buster backports AMD64 provides 'Expected behavor' in a debian
packaging for 5.10.15-2 reiser4 build hack running in an AMD Epyc/Ryzen cloud
instance:
https://metztli.it/buster/perf.png
>
> That's intersting, confirmed. The script is the same since the buster
> release without changes, but it looks it behaves differently in a buster
> vs. unstable/bullseye environment when the replacement ${version%%-*}
> is involved after the version setting:
>
> , [ perf-minimal ]
> > #!/bin/bash
> >
> > version="$(uname -r)"
> > version="${version%%-*}"
> > shopt -s execfail
> > exec "perf_$version" "$@"
> > echo >&2 "E: not installed."
> > exit 1
> `
>
> In an buster environment:
>
> ++ uname -r
> + version=4.19.0-14-amd64
> + version=4.19.0
> + shopt -s execfail
> + exec perf_4.19.0
> ./perf-minimal: line 6: exec: perf_4.19.0: not found
> + echo 'E: not installed.'
> E: not installed.
> + exit 1
>
> In an unstable environment:
>
> bash -x ./perf-minimal
> ++ uname -r
> + version=4.19.0-14-amd64
> + version=4.19.0
> + shopt -s execfail
> + exec perf_4.19.0
> ./perf-minimal: line 6: exec: perf_4.19.0: not found
>
> Regards,
> Salvatore
>
Best Professional Regards.
--
--
Jose R R
http://metztli.it
---
Download Metztli Reiser4: Debian Buster w/ Linux 5.9.16 AMD64
---
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
---
or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/
---
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
Bug#706676: bug 706676 remains in the newest sysvinit-core sid
> Sorry I meant > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695568#15 Sorry again, the above is obsolete for the newest sysvinit-core. A correct patch is as follows: --- usr/share/sysvinit/inittab 2021-02-21 22:53:09.0 +0900 +++ /tmp/inittab.lxc2021-02-26 15:47:39.711010978 +0900 @@ -36,9 +36,9 @@ #kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work." # What to do when the power fails/returns. -pf::powerwait:/etc/init.d/powerfail start -pn::powerfailnow:/etc/init.d/powerfail now -po::powerokwait:/etc/init.d/powerfail stop +pf::powerwait:/sbin/shutdown -P +1 +pn::powerfailnow:/sbin/shutdown -P now +po::powerokwait:/sbin/shutdown -c "Power supply recovered." # /sbin/getty invocations for the runlevels. # Best regards, Ryutaroh
Bug#983555: ITP: python-sinfo -- Print version information for loaded modules in the current session, Python, and the OS
Package: wnpp Severity: wishlist Subject: ITP: python-sinfo -- Print version information for loaded modules in the current session, Python, and the OS Package: wnpp Owner: Robbi Nespu Severity: wishlist * Package name: python-sinfo Version : 0.3.1 Upstream Author : Joel Ostblom * URL : https://gitlab.com/joelostblom/sinfo * License : BSD Programming Lang: Python Description : Print version information for loaded modules in the current session, Python, and the OS sinfo outputs version information for modules loaded in the current session, Python, the OS, and the CPU. It is designed as a minimum measure to increase reproducibility and provides similar information as sessionInfo in R. The name is shortened to encourage regular usage through reduced typing Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/python-sinfo
Bug#983554: inkscape: Measurement path effect scale inaccurate after changing display units in document properties
Package: inkscape Version: 1.0.2-3 Severity: normal X-Debbugs-Cc: wiiliamchung...@gmail.com Dear Maintainer, Changing the Display Units to anything other than the default mm throws off the measurement path effect. Attached documents includes a box scaled to 5 x 10 inch with measurement path applied. With the default display unit (mm), the measurements are displayed correctly. The file with display unit changed to inches shows an incorrect measurement. Other units are also affected, for example: cm is off by a factor of x10. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (100, 'experimental'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/24 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages inkscape depends on: ii libatkmm-1.6-1v5 2.28.0-3 ii libc6 2.31-9 ii libcairo2 1.16.0-5 ii libcairomm-1.0-1v5 1.12.2-4 ii libcdr-0.1-1 0.1.6-2 ii libdbus-glib-1-2 0.110-6 ii libdouble-conversion3 3.1.5-6.1 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 ii libgc1 1:8.0.4-3 ii libgcc-s1 10.2.1-6 ii libgdk-pixbuf-2.0-02.42.2+dfsg-1 ii libgdl-3-5 3.34.0-1 ii libglib2.0-0 2.66.7-1 ii libglibmm-2.4-1v5 2.64.2-2 ii libgomp1 10.2.1-6 ii libgsl25 2.6+dfsg-2 ii libgtk-3-0 3.24.24-1 ii libgtkmm-3.0-1v5 3.24.2-2 ii libgtkspell3-3-0 3.0.10-1 ii libharfbuzz0b 2.7.4-1 ii libjpeg62-turbo1:2.0.5-2 ii liblcms2-2 2.12~rc1-2 ii libmagick++-6.q16-88:6.9.11.60+dfsg-1 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-01.46.2-3 ii libpangoft2-1.0-0 1.46.2-3 ii libpangomm-1.4-1v5 2.42.1-1 ii libpng16-161.6.37-3 ii libpoppler-glib8 20.09.0-3.1 ii libpoppler102 20.09.0-3.1 ii libpotrace01.16-2 ii librevenge-0.0-0 0.0.4-6+b1 ii librsvg2-common2.50.3+dfsg-1 ii libsigc++-2.0-0v5 2.10.4-2 ii libsoup2.4-1 2.72.0-2 ii libstdc++6 10.2.1-6 ii libvisio-0.1-1 0.1.7-1+b1 ii libwpg-0.3-3 0.3.3-1 ii libx11-6 2:1.7.0-2 ii libxml22.9.10+dfsg-6.3+b1 ii libxslt1.1 1.1.34-4 ii python33.9.1-1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages inkscape recommends: ii aspell 0.60.8-2 ii fig2dev 1:3.2.8-2 ii imagemagick 8:6.9.11.60+dfsg-1 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1 ii libimage-magick-perl 8:6.9.11.60+dfsg-1 ii libwmf-bin 0.2.8.4-17 ii python3-lxml 4.6.2-1 ii python3-numpy1:1.19.5-1 ii python3-scour0.38.2-1 Versions of packages inkscape suggests: pn dia pn inkscape-tutorials pn libsvg-perl pn libxml-xql-perl pn pstoedit pn python3-uniconvertor ii ruby 1:2.7+2
Bug#983553: ITP: python-sinfo -- Print version information for loaded modules in the current session, Python, and the OS
Package: wnpp Severity: wishlist Subject: ITP: python-sinfo -- Print version information for loaded modules in the current session, Python, and the OS Package: wnpp Owner: Robbi Nespu Severity: wishlist * Package name: python-sinfo Version : 0.3.1 Upstream Author : Joel Ostblom * URL : https://gitlab.com/joelostblom/sinfo * License : BSD Programming Lang: Python Description : Print version information for loaded modules in the current session, Python, and the OS sinfo outputs version information for modules loaded in the current session, Python, the OS, and the CPU. It is designed as a minimum measure to increase reproducibility and provides similar information as sessionInfo in R. The name is shortened to encourage regular usage through reduced typing Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/python-sinfo
Bug#983531: buster-pu: package python2.7/2.7.16-2+deb10u2
On 2/25/21 7:41 PM, Moritz Muehlenhoff wrote: > + * CVE-2021-3177 are all the ctypes tests passing with this patch? See #983516. Matthias
Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
On 2/25/21 10:16 PM, Paul Gevers wrote: > Control: tags -1 confirmed > > Hi Stefano, > > On 25-02-2021 07:17, Stefano Rivera wrote: >> Please unblock package python3-defaults and python3.9 >> >> Adding a new binary package, -full, to both source packages. Both are >> currently in binNEW. > > We'll unblock with the understanding that the only difference is these > new meta packages. I'm planning to upload the upload as done to experimental, plus the final (no changes) 3.9.2 release. Granted, refreshing the patches is not not necessary, but that's what is now tested in experimental. Matthias python3.9 (3.9.2-1) unstable; urgency=medium * Python 3.9.2 release. No changes since 3.9.2~rc1-1. * Build idlelib/help.html from source, don't ship the pre-generated file. -- Matthias Klose Sat, 20 Feb 2021 12:05:08 +0100 python3.9 (3.9.2~rc1-1) experimental; urgency=medium * Python 3.9.2 release candidate 1. Changes since 3.9.1-4: - Fix issue #42967, web cache poisoning vulnerability. - Fix issue #42938, explicitly disable bracketed paste in the interactive interpreter. Closes: #979154. * Fix permissions and group for local directories. Closes: #962422. * Build a python3.9-full package. * idle-python3.9: Drop dependency on libjs-mathjax, Unused in 3.8 and 3.9. * python3.9-doc: Fix links to the documentation in /usr/share/doc/python3.9. * Refresh patches. -- Matthias Klose Wed, 17 Feb 2021 19:32:50 +0100
Bug#706676: bug 706676 remains in the newest sysvinit-core sid
> Could you consider to apply the known patch at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706676 Sorry I meant http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695568#15 Best regards, Ryutaroh Matsumoto
Bug#983314: linux-base: perf fails to report that linux-perf-5.10 is not installed
Control: tags -1 + confirmed
Hi Bart,
On Mon, Feb 22, 2021 at 11:57:56AM +0100, Bart Martens wrote:
> Package: linux-base
> Version: 4.6
> Severity: minor
> File: /usr/bin/perf
>
> Observed behavior:
>
> $ perf
> /usr/bin/perf: line 13: exec: perf_5.10: not found
>
> Expected behavior:
>
> $ perf
> /usr/bin/perf: line 14: exec: perf_5.10: not found
> E: linux-perf-5.10 is not installed.
That's intersting, confirmed. The script is the same since the buster
release without changes, but it looks it behaves differently in a buster
vs. unstable/bullseye environment when the replacement ${version%%-*}
is involved after the version setting:
, [ perf-minimal ]
| #!/bin/bash
|
| version="$(uname -r)"
| version="${version%%-*}"
| shopt -s execfail
| exec "perf_$version" "$@"
| echo >&2 "E: not installed."
| exit 1
`
In an buster environment:
++ uname -r
+ version=4.19.0-14-amd64
+ version=4.19.0
+ shopt -s execfail
+ exec perf_4.19.0
./perf-minimal: line 6: exec: perf_4.19.0: not found
+ echo 'E: not installed.'
E: not installed.
+ exit 1
In an unstable environment:
bash -x ./perf-minimal
++ uname -r
+ version=4.19.0-14-amd64
+ version=4.19.0
+ shopt -s execfail
+ exec perf_4.19.0
./perf-minimal: line 6: exec: perf_4.19.0: not found
Regards,
Salvatore
Bug#982993: python-aiohttp breaks python-molotov autopkgtest: result changed
It appears a simple git commit upstream corrects this bug. https://github.com/loads/molotov/commit/5e8854d95a74fb8820020335a8368c19f9f658b4?branch=5e8854d95a74fb8820020335a8368c19f9f658b4=unified Thanks to tianon on #debian-mentors for sharing this solution and link. Control: tag -1 patch 2 molotov/tests/test_run.py @@ -356,7 +356,7 @@ async def here_three(session): ) wanted = "SUCCESSES: 2" self.assertTrue(wanted in stdout, stdout) -self.assertEqual(delay, [1, 0.1, 1, 0.6, 1, 0.1, 1, 0.6, 1]) +self.assertEqual(delay[:9], [1, 0.1, 1, 0.6, 1, 0.1, 1, 0.6, 1]) @dedicatedloop def test_rampup(self): signature.asc Description: PGP signature
Bug#706676: bug 706676 remains in the newest sysvinit-core sid
Control: reassign -1 sysvinit-core 2.96-6 Control: tags -1 + patch bullseye sid The bug 706676 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706676 still remains in the newest sysvinit-core in Sid. Could you consider to apply the known patch at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706676 Best regards, Ryutaroh Matsumoto
Bug#983523: general: some WWW sites no longer work neither in Firefox nor in Chrome
On Thu, Feb 25, 2021 at 6:45 PM Janusz S. Bień wrote: > Anyway a clue should be provided by the fact the both (perhaps all?) > browsers are affected. The things broke several weeks ago, perhaps after > the upgrade to 10.8. Please try some of the following things to narrow down where the problem is: Create a new user account on your computer and check if the problem occurs there. Create a new Firefox browser profile and check if the problem occurs there. Open up the Firefox/Chrome developer tools (F12 in Firefox) and check for any errors or warnings in the Console and Network tabs after reloading the page. Use the Debian wayback archive to switch back to an older version of the browsers to test if this is caused by the Debian upgrade or not. Please note that the older Firefox will not be able to open your current profile created by the newer Firefox, so create a new profile for the older version, you will be able to access the current profile after upgrading again. https://snapshot.debian.org/ -- bye, pabs https://wiki.debian.org/PaulWise
Bug#983552: python-virtualenv: 20.4.0+ds-1
Source: python-virtualenv Version: 20.4.0+ds-1 Severity: normal Python 2 virtualenvs have incorrect sysconfig configuration: $ virtualenv -p python2 /tmp/py2ve $ /tmp/py2ve/bin/python -m sysconfig ... Paths: data = "/tmp/py2ve/local" include = "/tmp/py2ve/local/include/python2.7" platinclude = "/tmp/py2ve/local/include/python2.7" platlib = "/tmp/py2ve/local/lib/python2.7/dist-packages" platstdlib = "/tmp/py2ve/lib/python2.7" purelib = "/tmp/py2ve/local/lib/python2.7/dist-packages" scripts = "/tmp/py2ve/local/bin" stdlib = "/tmp/py2ve/lib/python2.7" ... $ ls -l /tmp/py2ve/local ls: cannot access '/tmp/py2ve/local': No such file or directory Pre-virtualenv 20, $ve/local/bin and $ve/local/lib were symlinks to the non /local/ versions. For Python 3 virtualenvs, this isn't an issue.
Bug#982740: pulseaudio: FTBFS on ppc64el
On Fri, 26 Feb 2021 03:21:36 +0200
Faidon Liambotis wrote:
[...]
>
> pa_cpu_init_orc() returns true only if cpu_info.cpu_type ==
> PA_CPU_X86. This should not be the case here, but cpu_info is being
> passed to the function uninitialized, and... as luck would have it,
> cpu_info.cpu_type's "random" contents are set to PA_CPU_X86.
>
> So at minimum, the test is broken; initializing cpu_info as is done on
> other tests is enough to fix this:
>
> --- pulseaudio-14.2.orig/src/tests/cpu-volume-test.c
> +++ pulseaudio-14.2/src/tests/cpu-volume-test.c
> @@ -187,7 +187,7 @@ END_TEST
>
> START_TEST (svolume_orc_test) {
> pa_do_volume_func_t orig_func, orc_func;
> -pa_cpu_info cpu_info;
> +pa_cpu_info cpu_info = { PA_CPU_UNDEFINED, {}, false };
> int i, j;
>
> #if defined (__i386__) || defined (__amd64__)
>
> I've tested this fix on plummer, and it seems to work as expected.
Thank you! Your explanation and patch looks correct, this is most
certainly the correct fix.
Bug#854327: pulseaudio: default configuration depends on consolekit
On Sat, Jul 08, 2017 at 02:35:05PM +0200, bert schulze wrote: > 1. ConsoleKit is not maintained and recommends systemd-logind [1] In the 3½ years since this bug was reported, ConsoleKit was removed from Debian as "dead upstream", cf. #911416. It was not even part of buster. I think the proper fix here would be... for Debian to not ship the module at all :) Faidon
Bug#983551: cloud.debian.org: Vagrant/Virtualbox image testing64 ownership of synced_folders is always root
Package: cloud.debian.org Severity: normal X-Debbugs-Cc: henning.spr...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I am setting up a system with the debian/testing64 Box provided in the Vagrant Cloud Box Repository, using virtualbox. The same configuration has been used until yesterday with the debian/buster64 box, and worked as expected. The Vagrantfile is set up to sync the directory 2 levels above the directory from which vagrant is run and where the Vagrantfile resides on the host to /work in the guest. With the buster64 box this works fine. * What exactly did you do (or not do) that was effective (or ineffective)? In my working Vagrantfile with buster I changed the value config.vm.box = "debian/buster64" to config.vm.box = "debian/testing64" And did a vagrant destroy / vagrant up, a "vagrant ssh" to log into the machine, and then an "ls -l /work". The Vagrantfile has a synced_folder configuration that reads like this: config.vm.synced_folder "../..", "/work" * What was the outcome of this action? All files and directories in /work on the guest system are the files from the host system, and are owned by root. * What outcome did you expect instead? The expectation is that the synced folder is provided to the guest via nfs and the ownership is mapped to the vagrant user in the guest, the default for synced folders as described in the Vagrant documentation. https://www.vagrantup.com/docs/synced-folders/basic_usage So that the files in /work are owned by user "vagrant" as they were before when the debian/buster64 box was used. Additional debugging: In order to try fixing it, I addionally tried to explicitly set the ownership of the directory changing the line to config.vm.synced_folder "../..", "/work", owner: "vagrant", mount_options: ["uid=1000"] and rebootet / ran "vagrant halt / vagrant up" and also destroyed and rebuilt the machine. But the result is always the same - those files and directories previously when using the buster64 box being owned by "vagrant" keep being owned by "root" now with the testing64 box. This is making it impossible to do the intened work inside the system as user vagrant. I did some research trying to see if anyone else has been experiencing this issue, but did not find any clues so far. So for now I cannot tell if the problem is that the Virtualbox Guest additions are not prepared for bullseye or if something in bullseye prevents them from working correctly. Writing that I remember one more possibly releveant thing: I am using the vbguest vagrant plugin version 0.29.0. It takes care of the installation of the guest additions, and this also works well with buster64. I also tried installing the Guest additions provided by the package virtualbox-guest-additions-iso burt this results in the system not even starting up proplery with "vagrant up", hanging on ==> test: Waiting for machine to boot. This may take a few minutes... test: SSH address: 127.0.0.1:2200 test: SSH username: vagrant test: SSH auth method: private key forever, and after canceling the comand with ctrl-c, trying to "vagrant ssh" into it hangs forever, too. Going to debug further... if you need me to provide any further logs etc, please let me know. Thank you.
Bug#983424: plocate-updatedb.service: PrivateTmp=true blocks indexing /tmp when removed from PRUNEPATHS
On Wed, 2021-02-24 at 11:34 +0100, Steinar H. Gunderson wrote: > I don't count this as a bug, really. If you change config, you change > config -- and then you can also change the config of the systemd > service by adding an override in /etc. Well, you change the config, and it is still broken even though you changed the config, but you don't notice that, later on you do notice that, but you don't understand systemd so you don't know that it could have broken that and cannot figure out how to fix it so you contact the developers of plocate to find out, and they say to fix PrivateTmp too and then you wonder why you need to make essentially the same change to the settings of another program rather than just the plocate settings. I think this is a fairly poor user experience for this situation. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#983146: RFP: bung -- backup next generation
The original build system built a .deb which installs in FHS appropriate directories for a non-Debian package I created a new build system which builds a .deb which installs in Debian FHS directories. It is attached as a tarball The new build system precisely defines the steps required to produce a Debian compliant binary .deb from the source tarball (https://redmine.auroville.org.in/attachments/download/9186/bung-2.1.0.tgz) As noted above "I tried hard to make a source .deb but did not manage to do so". If somebody is willing to guide me, I am willing to try again. Charles Atkinson 983146.tar Description: Unix tar archive
Bug#983550: articles.c: remove a stray "*/"
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch
Dear Maintainer,
>From ad7c80cf5a8d02682096e9c334d5981f56dbfc85 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason
>Date: Fri, 26 Feb 2021 01:42:39 +
>Subject: [PATCH] articles.c: remove a stray "*/"
articles.c: remove a stray "*/".
Signed-off-by: Bjarni Ingi Gislason
---
articles.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/articles.c b/articles.c
index 6364979..8e36e15 100644
--- a/articles.c
+++ b/articles.c
@@ -590,7 +590,7 @@ attr_again:
data_error:
log_entry('E', "%s: article data inconsistency; number=%li, first=%li,
last=%li", gh->group_name,
- db_hdr.dh_number, gh->first_db_article, gh->last_db_article); */
+ db_hdr.dh_number, gh->first_db_article, gh->last_db_article);
#ifndef NOV
fclose(data);
--
2.30.0
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.9-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)
-- debconf information excluded
--
Bjarni I. Gislason
Bug#983549: article.c: Add information to the output of "log_entry()" in the label "data_error:"
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch
Dear Maintainer,
>From 659beebb427e3163f3600d18b15ef5fe5977d26b Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason
>Date: Fri, 26 Feb 2021 01:26:08 +
>Subject: [PATCH] articles.c: Add information to the output of "log_entry()" in
> the label "data_error:"
articles.c: Add information to the output of "log_entry()" in the
label "data_error:"
Signed-off-by: Bjarni Ingi Gislason
---
articles.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/articles.c b/articles.c
index 02be346..6364979 100644
--- a/articles.c
+++ b/articles.c
@@ -39,7 +39,7 @@ article_header **articles;
extern int ignore_fancy_select;
extern int killed_articles;
-extern attr_type test_article();
+extern attr_type test_article(article_header *); /* defined in "newsrc.h" */
/*
* memory management
@@ -589,7 +589,8 @@ attr_again:
return n_articles > 0 ? 1 : 0;
data_error:
-log_entry('E', "%s: data inconsistency", gh->group_name);
+log_entry('E', "%s: article data inconsistency; number=%li, first=%li,
last=%li", gh->group_name,
+ db_hdr.dh_number, gh->first_db_article, gh->last_db_article); */
#ifndef NOV
fclose(data);
--
2.30.0
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.9-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)
-- debconf information excluded
--
Bjarni I. Gislason
Bug#983435: Regarding the backup/restore function
Regarding the backup/restore function in the commit bb3205709aa9f83e1c8cb91e7f6f9f110d41b34e, for me it seems bringing in more critical dangers than the safety it provides. The logic is too error prone, it relies on on_exit() absolutely never duped by any fork()'s, meaning it's requiring absolutely every fork() in the entire code to be patched. And there is no safeguard against misfiring of restore_backup_on_exit(). It itself is "just irrevocably removing them as the first action," even if there is nothing to be restored. Oh well. I bet it's better to set onhold on grub for now...
Bug#982740: pulseaudio: FTBFS on ppc64el
Control: tags -1 patch
On Sat, Feb 13, 2021 at 02:53:58PM -0500, Andres Salomon wrote:
> Pulseaudio is failing to build on ppc64el. The version of pulseaudio in
> bullseye suffers from a pretty serious usability bug (see #980836)
> which should arguably be a higher severity, but let's focus on getting
> 14.2-1 built properly.
>
> https://buildd.debian.org/status/logs.php?pkg=pulseaudio=ppc64el
>
> Here's where the ppc64el build fails:
>
>
> FAIL: cpu-volume-test
> =
>
> Running suite(s): CPU
> 0%: Checks: 1, Failures: 1, Errors: 0
> tests/cpu-volume-test.c:81:F:svolume:svolume_orc_test:0: Failed
> FAIL cpu-volume-test (exit status: 1)
The output of the check (src/cpu-volume-test) is:
Running suite(s): CPU
Initialising ORC optimized volume functions.
Checking Orc svolume
Correctness test failed: align=1, channels=2
1: 3303 != d317 (a1ed * 7a36)
0%: Checks: 1, Failures: 1, Errors: 0
tests/cpu-volume-test.c:81:F:svolume:svolume_orc_test:0: Failed
Looking at the code of the test, that seems... not the intention:
pa_cpu_info cpu_info;
[...]
#if defined (__i386__) || defined (__amd64__)
pa_zero(cpu_info);
cpu_info.cpu_type = PA_CPU_X86;
pa_cpu_get_x86_flags(_info.flags.x86);
#endif
[...]
if (!pa_cpu_init_orc(cpu_info)) {
pa_log_info("Orc not supported. Skipping");
return;
}
[...]
pa_log_debug("Checking Orc svolume");
pa_cpu_init_orc() returns true only if cpu_info.cpu_type == PA_CPU_X86.
This should not be the case here, but cpu_info is being passed to the
function uninitialized, and... as luck would have it,
cpu_info.cpu_type's "random" contents are set to PA_CPU_X86.
So at minimum, the test is broken; initializing cpu_info as is done on
other tests is enough to fix this:
--- pulseaudio-14.2.orig/src/tests/cpu-volume-test.c
+++ pulseaudio-14.2/src/tests/cpu-volume-test.c
@@ -187,7 +187,7 @@ END_TEST
START_TEST (svolume_orc_test) {
pa_do_volume_func_t orig_func, orc_func;
-pa_cpu_info cpu_info;
+pa_cpu_info cpu_info = { PA_CPU_UNDEFINED, {}, false };
int i, j;
#if defined (__i386__) || defined (__amd64__)
I've tested this fix on plummer, and it seems to work as expected.
src/pulsecore/cpu.c has the only other invocation of pa_cpu_init_orc(),
and this seems to be initializing cpu_info properly, so this failure is
limited to the test suite and does not affect any runtime operation.
(This of course does not explain why the Orc code is broken on ppc64el.
It does not look to have been written with anything but i386/amd64 in
mind and the codepath is not meant to be running anywhere else, so
that's probably more in the "feature request" category.)
HTH!
Faidon
Bug#983535: sbuild: source-only-changes only includes most recent changelog entry despite -v arg
> > it seems you are running sbuild 0.79.1 which explains that you see this issue. > This is the same as has already been reported in #884428, #891247, #917849, > #947755 and fixed in 0.80.0. I looked through the changelog for the version in unstable, but I guess I completely missed the entry where it was fixed. Of course, now that you pointed it out, I see it. The next stable release is fine. Sorry for the noise! Best regards, Bill
Bug#983548: answer.c: add MIME header if charset is not us-ascii
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch
Dear Maintainer,
>From e05d9f839fafa7bc9ba5308d8be7456604626823 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason
>Date: Fri, 26 Feb 2021 00:46:52 +
>Subject: [PATCH] answer.c: add MIME header if charset is not us-ascii
answer.c: add MIME header if charset is not us-ascii
Signed-off-by: Bjarni Ingi Gislason
---
answer.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/answer.c b/answer.c
index 69330ce..d602c80 100644
--- a/answer.c
+++ b/answer.c
@@ -13,6 +13,7 @@
#include "global.h"
#include "answer.h"
#include "aux.h"
+#include "chset.h"
#include "db.h"
#include "fullname.h"
#include "group.h"
@@ -99,8 +100,10 @@ static int ed_line;
#include
#include
-extern struct tm *gmtime();
-extern char*asctime();
+/* defined in
+ extern struct tm *gmtime();
+ extern char*asctime();
+*/
#endif
static int
@@ -866,6 +869,9 @@ post_menu(void)
group_headergh;
chargroup_name[FILENAME], subject[FILENAME],
distribution[FILENAME],
keywords[FILENAME], summary[FILENAME];
+const char *cp;
+const char mime_header_format[]="MIME-Version: 1.0\nContent-Type:
text/plain; charset=%s\nContent-Transfer-Encoding: 8bit\n";
+
if (checkhold(NULL, K_POST))
return 1;
@@ -992,6 +998,14 @@ again_group:
fprintf(t, "Keywords: %s\n", keywords);
ed_line++;
}
+
+/* Add MIME header if charset is not us-ascii */
+if (strcmp(curchset->cs_name, "us-ascii") != 0) {
+ fprintf(t, mime_header_format, curchset->cs_name);
+ for (cp = mime_header_format; *cp != NUL; cp++)
+ if (*cp == '\n') ed_line++;
+}
+
end_header(t, extra_news_headers);
if (post_source_file) {
--
2.30.0
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.9-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)
-- debconf information excluded
--
Bjarni I. Gislason
Bug#983547: julia-common: julia-config.jl does not find libjulia.so
Package: julia-common Version: 1.5.3+dfsg-3 Severity: normal X-Debbugs-Cc: greg.van2...@gmail.com Dear Maintainer, To embed Julia in a C program it's possible to use the script: /usr/share/julia/julia-config.jl But in Debian it is not usable with the following args: --ldflags or --ldlibs This script is a simple tool to know automatically which parameter to give to gcc when embeding Julia in a C program. It's usable in Julia from julialang.org. This is in fact an old "bug" in the Debian package. Try for example: $/usr/share/julia/julia-config.jl --allflags It will return (among other things): libjulia.so: cannot open shared object file: no such file or directory Adding a symlink libjulia.so that points to libjulia.so.1.5 (package libjulia1) is a workaround of course. -- System Information: Distributor ID: Debian Description:Debian Release: Codename: sid Architecture: x86_64 Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/4 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect julia-common depends on no packages. Versions of packages julia-common recommends: ii julia 1.5.3+dfsg-3 julia-common suggests no packages. -- no debconf information
Bug#932403: Bug932403
I can't reproduce this. I'd guess it is a font-related crash like https://debbugs.gnu.org/30045 If it still happens to you with Emacs 27.1, I suggest you report it upstream with M-x report-emacs-bug.
Bug#981685: request to test the upstream release
On Thu, Feb 25, 2021 at 3:01 PM Noah Meyerhans wrote: > > On Thu, Feb 25, 2021 at 11:50:01AM +, Sudip Mukherjee wrote: > > There is a change merged in upstream which should fix this issue. > > Details at: https://github.com/OfflineIMAP/offlineimap3/pull/56 > > > > It will be great if you can test the latest HEAD from github and > > confirm if it fixes the issue. > > I can give you a deb package if that is easier. > > I have tested this change and it appears to resolve the issue. Attached > is the patch that I applied to the current debian/master salsa branch, > which should be suitable for incorporating directly into the package as > is. I can send it in a salsa MR if you'd like. Thanks for testing Noah. I have also tested now on gmail and found a minor problem which I mentioned on the upstream issue. But it has definitely fixed the regression from old offlineimap. > > > But in any case, I think the change is too big to be included in > > Debian during this time of the Bullseye freeze. I can add it to > > bullseye-backports after the change has been properly tested. > > Respectfully, this is absolutely not the right response. > stable-backports is intended for providing feature updates, and is not > the appropriate place to publish fixes for Severity: important bugs. > This bug has a significant impact on the ability of this package to > fulfill its intended purpose, and further is a regression from buster. > Even if bullseye was already released as stable, this bug would warrant > a fix in a stable point release. This issue should most definitely be > fixed during the bullseye freeze. Sorry, I meant to say 'point release'. But as discussed on #debian-release today I have now uploaded the package to experimental. Lets discuss in #debian-release in few days about it going to Bullseye. -- Regards Sudip
Bug#983544: debdiff
And tge debdiff that is rejected by Gmail.diff -Nru kodi-19.0~rc1+git20210119.8c761c4+dfsg1/debian/changelog
kodi-19.0+dfsg1/debian/changelog
--- kodi-19.0~rc1+git20210119.8c761c4+dfsg1/debian/changelog2021-01-19
20:02:25.0 +
+++ kodi-19.0+dfsg1/debian/changelog2021-02-19 00:02:45.0 +
@@ -1,3 +1,19 @@
+kodi (2:19.0+dfsg1-1) unstable; urgency=medium
+
+ * New upstream version 19.0+dfsg1
+ * Declare proper Debian release splitting kodi-addons-dev (Closes: #980846)
+ * Detect and honor big-endian architectures
+ * Refresh cdatetime-std-chrono patch
+
+ -- Vasyl Gello Fri, 19 Feb 2021 00:02:45 +
+
+kodi (2:19.0~rc1+git20210119.8c761c4+dfsg1-2) experimental; urgency=medium
+
+ * Team upload.
+ * Re-instate the kodi-addons-dev-common package split.
+
+ -- Mattia Rizzolo Wed, 20 Jan 2021 01:56:06 +0100
+
kodi (2:19.0~rc1+git20210119.8c761c4+dfsg1-1) unstable; urgency=medium
[ Vasyl Gello ]
diff -Nru kodi-19.0~rc1+git20210119.8c761c4+dfsg1/debian/control
kodi-19.0+dfsg1/debian/control
--- kodi-19.0~rc1+git20210119.8c761c4+dfsg1/debian/control 2021-01-19
20:02:25.0 +
+++ kodi-19.0+dfsg1/debian/control 2021-02-19 00:02:45.0 +
@@ -373,12 +373,14 @@
.
This package is the ZeroConf script for Kodi Event Client.
-Package: kodi-addons-dev
-Architecture: any
+Package: kodi-addons-dev-common
+Architecture: all
+Multi-Arch: foreign
Section: libdevel
Depends: ${misc:Depends}
-Provides: dh-sequence-kodiaddon (= ${binary:Version})
-Description: Open Source Home Theatre (Addons Dev package)
+Breaks: kodi-addons-dev (<< 2:19.0~rc1+git20210119.8c761c4+dfsg1-2~),
+Replaces: kodi-addons-dev (<< 2:19.0~rc1+git20210119.8c761c4+dfsg1-2~),
+Description: Open Source Home Theatre (architecture-independent addon
development package)
Kodi, formerly known as XBMC is an award winning free and
open source software media-player and entertainment hub for all your digital
media. Kodi is available for Linux, Mac OS X (Leopard, Tiger and Apple TV)
@@ -398,8 +400,25 @@
.
This is the development package for Kodi Addons.
.
- This package contains independent headers for building Addons
- without the whole Kodi source tree.
+ This package contains independent headers for building addons without the need
+ to keep a whole Kodi source tree.
+
+Package: kodi-addons-dev
+Section: libdevel
+Architecture: any
+Multi-Arch: same
+Provides: dh-sequence-kodiaddon (= ${binary:Version})
+Depends: kodi-addons-dev-common (= ${source:Version}),
+ ${misc:Depends}
+Description: Open Source Home Theatre (addon development package)
+ This package is a dummy package used in conjunction with kodi-addons-dev
+ to detect if a binary addon should be built for given Debian architecture.
+ .
+ The alternative to introducing this package is marking kodi-addons-dev back
+ as arch:any, but this makes Lintian and multi-arch hinter noisy.
+ .
+ If Kodi upstream starts shipping architecture-specific development libraries
+ again, they will land in this package.
Package: kodi-repository-kodi
Architecture: all
diff -Nru
kodi-19.0~rc1+git20210119.8c761c4+dfsg1/debian/dh-addon/dh_kodiaddon_depends
kodi-19.0+dfsg1/debian/dh-addon/dh_kodiaddon_depends
---
kodi-19.0~rc1+git20210119.8c761c4+dfsg1/debian/dh-addon/dh_kodiaddon_depends
2021-01-19 20:02:25.0 +
+++ kodi-19.0+dfsg1/debian/dh-addon/dh_kodiaddon_depends2021-02-19
00:02:45.0 +
@@ -96,7 +96,7 @@
}
}
-my $baseDir = "debian/kodi-addons-dev";
+my $baseDir = "debian/kodi-addons-dev-common";
if (! -d "$baseDir/usr/include/kodi") {
$baseDir = "debian/tmp";
if (! -d "$baseDir/usr/include/kodi") {
diff -Nru
kodi-19.0~rc1+git20210119.8c761c4+dfsg1/debian/kodi-addons-dev-common.install
kodi-19.0+dfsg1/debian/kodi-addons-dev-common.install
---
kodi-19.0~rc1+git20210119.8c761c4+dfsg1/debian/kodi-addons-dev-common.install
1970-01-01 00:00:00.0 +
+++ kodi-19.0+dfsg1/debian/kodi-addons-dev-common.install 2021-02-19
00:02:45.0 +
@@ -0,0 +1,4 @@
+usr/include/kodi
+usr/share/kodi/cmake/*.cmake
+debian/dh-addon/kodiaddon.pm usr/share/perl5/Debian/Debhelper/Sequence/
+debian/dh-addon/dh_kodiaddon_depends usr/bin/
diff -Nru
kodi-19.0~rc1+git20210119.8c761c4+dfsg1/debian/kodi-addons-dev-common.manpages
kodi-19.0+dfsg1/debian/kodi-addons-dev-common.manpages
---
kodi-19.0~rc1+git20210119.8c761c4+dfsg1/debian/kodi-addons-dev-common.manpages
1970-01-01 00:00:00.0 +
+++ kodi-19.0+dfsg1/debian/kodi-addons-dev-common.manpages 2021-02-19
00:02:45.0 +
@@ -0,0 +1 @@
+debian/dh-addon/*.1
diff -Nru
kodi-19.0~rc1+git20210119.8c761c4+dfsg1/debian/kodi-addons-dev-common.README.Debian
kodi-19.0+dfsg1/debian/kodi-addons-dev-common.README.Debian
---
kodi-19.0~rc1+git20210119.8c761c4+dfsg1/debian/kodi-addons-dev-common.README.Debian
1970-01-01 00:00:00.0 +
+++
Bug#192522: sudo: should validate sudoers on upgrade and abort if incompatible
Marc Haber writes: > I am therefore reluctant to implement this at the moment. FYI, I never found an acceptable solution to this problem, and chose to leave the bug open to remind myself and anyone searching for help that this *could* happen. It might be better to move this into a README.Debian clause or something and close the bug with no further action taken? Bdale signature.asc Description: PGP signature
Bug#983534: fail2ban: set syslog_local0 to /var/log/syslog (not /var/log/messages) for Debian
Package: fail2ban
Severity: important
Some days ago, I discovered, that the internal path variable
%{syslog_local} in fail2ban's config is set to /var/log/messages by
default. For the Debian package of fail2ban, shouldn't this be changed
to /var/log/syslog? This would be a Debian-specific change.
If you, as the maintainers, agree, I can file a PR upstream for this, too.
Feedback? Comments?
Mike
--
DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
pgprmZukEIZz0.pgp
Description: Digitale PGP-Signatur
Bug#983399: filter for portscans detected by scanlogd
Control: forwarded -1 https://github.com/fail2ban/fail2ban/pull/2950 On Do 25 Feb 2021 18:57:15 CET, Sylvestre Ledru wrote: Hello Could you please try to have it merged upstream ? thanks Cheers, S Done: https://github.com/fail2ban/fail2ban/pull/2950 Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpRzIUISrDIk.pgp Description: Digitale PGP-Signatur
Bug#983546: geeqie --remote File:IMAGE fails
Package: geeqie Version: 1:1.6-6 Severity: important X-Debbugs-Cc: fizb...@gmx.de Dear Maintainer, After a recent update of debian testing I found that geeqie option --remote does not work anymore. 'geeqie --remote File:IMAGE' should show image IMAGE in an already running geeqie instance and return to cli. Instead, new instances of geeqie are started and a random wrong image is shown. The command does not return to cli. Older versions work as expected; currently I use geeqie 1.4 from buster to temporary address this issue. I've set severity to 'important' instead of 'normal' because geeqie seems to be the one and only image viewer in debian with the ability to be remotely controlled. In my case I use geeqie to show intermediate results of scripted image processing without a flickering window. Only pqiv provides a (complicated) alternative, but has its own remote bugs. Other than pqiv geeqie is actively maintained. The developer is already working on a fix. Bug report: https://github.com/BestImageViewer/geeqie/issues/871 Once the bug is fixed, likely soon, I hope (and beg) that the fix will get into debian testing. Cheers, Martin -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-rt-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 geeqie depends on: ii geeqie-common1:1.4+git20190121-2 ii libatk1.0-0 2.36.0-2 ii libc62.31-9 ii libcairo21.16.0-5 ii libexiv2-14 0.25-4 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 ii libgcc-s1 [libgcc1] 10.2.1-6 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libglib2.0-0 2.66.6-1 ii libgtk2.0-0 2.24.33-1 ii libjpeg62-turbo 1:2.0.5-2 ii liblcms2-2 2.12~rc1-2 ii liblirc-client0 0.10.1-6.2+b1 ii liblua5.1-0 5.1.5-8.1+b3 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libpangoft2-1.0-01.46.2-3 ii libstdc++6 10.2.1-6 ii libtiff5 4.2.0-1 ii sensible-utils 0.0.14 Versions of packages geeqie recommends: ii cups-bsd [lpr] 2.3.3op2-2 ii exiftran 2.10-4 ii exiv20.27.3-3 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1 ii librsvg2-common 2.50.3+dfsg-1 ii ufraw-batch 0.22-4 ii zenity 3.32.0-6 Versions of packages geeqie suggests: pn geeqie-dbg ii gimp 2.10.22-2 ii libjpeg-turbo-progs [libjpeg-progs] 1:2.0.5-2 ii ufraw0.22-4 pn xpaint -- no debconf information
Bug#983533: [vinagre] black screen when launching RDP session
Package: src:vinagre
Severity: grave
Version: 3.22.0-8
For a while now, vinagre when running against FreeRDP >= 2.0.0 has
been broken in Debian. When launching an RDP session, the user sees a
GTK window with a black rectangle in the middle.
A fix proposed by FreeRDP upstream is
https://gitlab.gnome.org/GNOME/vinagre/-/commit/404a56a11469ef24a1df632847465030d81db091.patch
See:
https://gitlab.gnome.org/GNOME/vinagre/-/merge_requests/12
However, the vinagre version in Debian will not be fixed after the
referenced patch (an adapted version of it for vinagre 3.22.0) has
been applied (I just tested that).
Let me know, if I can give any more input on this. I saw from other
open bugs that vinagre upstream is scarcely maintained. Does it make
sense to ship vinagre in Debian 11? If yes, let me know how I can help
fixing this issue.
Greets,
Mike
--
DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
>From 404a56a11469ef24a1df632847465030d81db091 Mon Sep 17 00:00:00 2001
From: Ondrej Holy
Date: Fri, 15 May 2020 15:43:37 +0200
Subject: [PATCH] plugins/rdp: Fix hangs with recent FreeRDP versions
Connection to all my testing servers fails with "SERVER BUG: The support
for this feature was not announced! Use /relax-order-checks to ignore"
currently. This happens always with current FreeRDP versions after
https://github.com/FreeRDP/FreeRDP/pull/4926 has been merged. This can be
fixed by the usage of /relax-order-checks option, however, this option
should be used only if necessary needed and it should not be needed in
most of the cases. This currenlty happens always as it interfere with our
custom OrderSupports settings. Let's use the default OrderSupports
settings to fix this issue, which is possible thanks to
https://github.com/FreeRDP/FreeRDP/pull/5057.
See: https://gitlab.gnome.org/GNOME/gtk-frdp/-/issues/27
---
configure.ac | 2 +-
plugins/rdp/vinagre-rdp-tab.c | 27 ---
2 files changed, 1 insertion(+), 28 deletions(-)
--- a/configure.ac
+++ b/configure.ac
@@ -58,7 +58,7 @@
AM_CONDITIONAL([VINAGRE_ENABLE_SSH], [test "x$have_ssh" = "xyes"])
# Whether to enable support for RDP.
-RDP_DEPS="freerdp2 x11"
+RDP_DEPS="freerdp2 >= 2.0.0 x11"
AC_ARG_ENABLE([rdp],
[AS_HELP_STRING([--disable-rdp],
[Disable Remote Desktop Protocol (RDP) support])])
--- a/plugins/rdp/vinagre-rdp-tab.c
+++ b/plugins/rdp/vinagre-rdp-tab.c
@@ -522,9 +522,9 @@
static BOOL
frdp_pre_connect (freerdp *instance)
{
+#if HAVE_FREERDP_1_1
rdpSettings *settings = instance->settings;
-#if HAVE_FREERDP_1_1
settings->OrderSupport[NEG_DSTBLT_INDEX] = TRUE;
settings->OrderSupport[NEG_PATBLT_INDEX] = TRUE;
settings->OrderSupport[NEG_SCRBLT_INDEX] = TRUE;
@@ -549,31 +549,6 @@
settings->OrderSupport[NEG_POLYGON_CB_INDEX] = FALSE;
settings->OrderSupport[NEG_ELLIPSE_SC_INDEX] = FALSE;
settings->OrderSupport[NEG_ELLIPSE_CB_INDEX] = FALSE;
-#else
- settings->order_support[NEG_DSTBLT_INDEX] = true;
- settings->order_support[NEG_PATBLT_INDEX] = true;
- settings->order_support[NEG_SCRBLT_INDEX] = true;
- settings->order_support[NEG_OPAQUE_RECT_INDEX] = true;
- settings->order_support[NEG_DRAWNINEGRID_INDEX] = false;
- settings->order_support[NEG_MULTIDSTBLT_INDEX] = false;
- settings->order_support[NEG_MULTIPATBLT_INDEX] = false;
- settings->order_support[NEG_MULTISCRBLT_INDEX] = false;
- settings->order_support[NEG_MULTIOPAQUERECT_INDEX] = true;
- settings->order_support[NEG_MULTI_DRAWNINEGRID_INDEX] = false;
- settings->order_support[NEG_LINETO_INDEX] = true;
- settings->order_support[NEG_POLYLINE_INDEX] = true;
- settings->order_support[NEG_MEMBLT_INDEX] = true;
- settings->order_support[NEG_MEM3BLT_INDEX] = false;
- settings->order_support[NEG_MEMBLT_V2_INDEX] = true;
- settings->order_support[NEG_MEM3BLT_V2_INDEX] = false;
- settings->order_support[NEG_SAVEBITMAP_INDEX] = false;
- settings->order_support[NEG_GLYPH_INDEX_INDEX] = true;
- settings->order_support[NEG_FAST_INDEX_INDEX] = true;
- settings->order_support[NEG_FAST_GLYPH_INDEX] = false;
- settings->order_support[NEG_POLYGON_SC_INDEX] = false;
- settings->order_support[NEG_POLYGON_CB_INDEX] = false;
- settings->order_support[NEG_ELLIPSE_SC_INDEX] = false;
- settings->order_support[NEG_ELLIPSE_CB_INDEX] = false;
#endif
return TRUE;
pgpsbnc6UgEV3.pgp
Description: Digitale PGP-Signatur
Bug#983545: active.c: add "__FILE__" to the ouput of "log_entry()"
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch
Dear Maintainer,
>From b7568dd0e37bdcb87eac01b2b017622d54f6140f Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason
>Date: Thu, 25 Feb 2021 23:02:33 +
>Subject: [PATCH] active.c: add "__FILE__" to the ouput of "log_entry"
active.c: add "__FILE__" to the ouput of "log_entry"
Signed-off-by: Bjarni Ingi Gislason
---
active.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/active.c b/active.c
index 9513e20..86f28a7 100644
--- a/active.c
+++ b/active.c
@@ -132,8 +132,8 @@ read_active_file(FILE * act, FILE * copy)
if (gh1 == NULL) {
/* '=unknown.group' is treated just like 'x' */
if ((old_flag & M_IGNORE_A) == 0)
- log_entry('R', "Group %s aliased to unknown group (%s)",
- gh->group_name, name);
+ log_entry('R', "%s: Group %s aliased to unknown group
(%s)",
+ __FILE__, gh->group_name, name);
gh->master_flag |= M_IGNORE_A;
if ((old_flag & (M_IGNORE_A | M_ALIASED)) == M_IGNORE_A)
continue;
--
2.30.0
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.9-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)
-- debconf information excluded
--
Bjarni I. Gislason
Bug#983544: unblock: kodi/19.0+dfsg1-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: mat...@debian.org, bal...@balintreczey.hu
Dear colleagues,
Please unblock package kodi within bullseye.
[ Reason ]
The block reason is the delayed upload of Kodi package having 'kodi-addons-dev'
(the development headers package used to build Kodi addons but not targeting
end-users)
split to arch-independent part ('kodi-addons-dev-common') and the
architecture-dependent
part ('kodi-addons-dev').
This change was prepared on Salsa on January 8th 2021
(see
https://salsa.debian.org/multimedia-team/kodi-media-center/kodi/-/commit/d1dc691507e7c28a3818fa338d68646cd0a5ae83)
to keep files from '/usr/share' in arch:all package (making multi-arch hinter
happy),
but also to prevent buildds from building Kodi addons on architectures there is
no Kodi for (like mipsel).
Overall, the change in question:
* Restored the proper way for buildds to know if it is feasible to build Kodi
addons
for a given architecture, reducing build resource waste,
* Made the package multi-arch compliant.
[ Impact ]
If the unblock is not granted, end users will receive release candidate 1 of
Kodi 19.0
instead of final release. The difference between the build in bullseye and
final release
is 65 bug fixes, including several PVR and JSON-RPC API corrections that have
great usability
impact.
The risks of reverting the commit in question are discussed under "Risks"
paragraph.
[ Tests ]
The following tests were performed on the Debian uploads:
* Autotest suite (590 tests) passes during package build,
* Autopkgtest passes as well,
* All the kodi addons build fine with this package split (it needs to
be noted that the questioned change is relevant only to this one use
case),
* Manual daily-driver testing by ~25 users who I invited to test
Kodi from Debian in various channels (my unofficial Github
nightly repo, Kodi forums, Kodinupstream bugtracker, Discord
groups etc)
The 19.0 final upload is tested in its current shape and builds fine on
all release architectures, except of mipsel / mips64el (due to #969946)
[ Risks ]
Reverting previous iteration of multiarch fix in hope to get Kodi 19.0 in
unstable faster
has already led to an FTBFS requiring two more uploads.
See the following git commits for more background on the history of the
change:
https://salsa.debian.org/multimedia-team/kodi-media-center/kodi/-/commit/0f31a067216559064cf885ba389c18b87e50085b
https://salsa.debian.org/multimedia-team/kodi-media-center/kodi/-/commit/d1dc691507e7c28a3818fa338d68646cd0a5ae83
https://salsa.debian.org/multimedia-team/kodi-media-center/kodi/-/commit/1fc69926ae708e5a426bee9be85aaacb3a141407
https://salsa.debian.org/multimedia-team/kodi-media-center/kodi/-/commit/621b27d14fbd971eca88861a4bb2393eff90d3f6
https://salsa.debian.org/multimedia-team/kodi-media-center/kodi/-/commit/2ffa9c994e4c939ce2ece997aea0c4ac4015e4e6
https://salsa.debian.org/multimedia-team/kodi-media-center/kodi/-/commit/80d363c229b0361e5778894ecbe88904818f1c34
Keeping in mind that any regression during the freeze can end dropping Kodi
irrevocably
off bullseye, I would prefer not to break the tested package layout.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing (including one with
only the debian/ part, for easier reviewing)
[ Other info ]
Please don't let the results of 8mo+ work on Kodi packaging for Debian to get
dropped
off Debian :)
Also note that this change was really read in time by the proper
deadline (i.e. 12th February), but wasn't uploaded to unstable just
because we missed the extra bit of the freeze policy that also changes
to the set of binary packages wasn't allowed, plus my sponsor wanted to
save an extra upload of kodi just to have this small change migrate when
it could have easily do it together with the expected 19.0 upload (which
was entirely planned to be within the scope of the soft freeze, and
still is).
unblock kodi/19.0+dfsg1-1
Bug#975390: RFS: dragonfly-reverb/3.2.1-1 [ITP] -- Reverb effect plugins (metapackage)
Hi Ross, thank you for the review! I think ive fixed everything. I also added 2 patches to fix cross building and fix building without sse. about 5., i dont know which new tag you mean. my build on sid didnt had a different tag. and about 12., yeah all plugins should be installed. Best, Dennis OpenPGP_signature Description: OpenPGP digital signature
Bug#983543: account.c: use "snprintf()" instead of "sprintf()"
Source: nn Version: 6.7.3-14 Severity: normal Tags: patch Dear Maintainer, >From cb0cb7b01ae8049b40d2f2a26ab54ec8ec58665a Mon Sep 17 00:00:00 2001 >From: Bjarni Ingi Gislason >Date: Thu, 25 Feb 2021 22:43:26 + >Subject: [PATCH] account.c: use "snprintf()" instead of "sprintf()" account.c: use "snprintf()" instead of "sprintf()" Signed-off-by: Bjarni Ingi Gislason --- account.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/account.c b/account.c index 257ccdd..5bd0b98 100644 --- a/account.c +++ b/account.c @@ -310,7 +310,7 @@ do_zero(void) if (old == NULL) goto err; -sprintf(bak, "%s.old", acct); +snprintf(bak, FILENAME, "%s.old", acct); if (unlink(bak) < 0 && errno != ENOENT) goto err; if (link(acct, bak) < 0) -- 2.30.0 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.9-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) -- debconf information excluded -- Bjarni I. Gislason
Bug#484468:
13 years on, if you are still interested in this feature, I suggest you ask for it on the cc-mode mailing list: https://sourceforge.net/p/cc-mode/mailman/cc-mode-help/ where the cc-mode maintainer can hopefully give a definitive answer. No development of cc-mode happens on Debian.
Bug#983528: reports false positives for missing -fPIE
Em qui., 25 de fev. de 2021 às 14:57, Marc Haber escreveu: > Hi, > > for the aide package, blhc complains about missing CFLAGS (-fPIE), see > https://buildd.debian.org/status/fetch.php?pkg=aide=amd64=0.17.3-1=1613025725=0 > > However, aide uses dpkg-buildflags correctly, it is just the case that > dpkg-buildflags doesn't emit fPIE (any more?) since gcc (nowadays, to my > knowlegde) defaults to -fPIE. > > Please let me know if I'm wrong with this diagnosis. Should > dpkg-buildflags not emit -fPIE automatically? Hi Marc, Thanks for your message. Yes, since 2016 dpkg enables PIE by default. The right way is always to use --debian option to check your .build files. See below: # blhc --all --debian aide_0.17.3-1_amd64.build Can I close this bug? Cheers, Eriberto
Bug#983505: doas: persist option does not work
On Thu, Feb 25, 2021 at 09:56:58AM +0100, Andrea Pappacoda wrote: > Package: doas > Version: 6.8.1-2 > Severity: important > > The manpage of doas.conf(5) says that the persist option can be user to make > doas not ask for the user's password every time the command is ran. > Unfortunately, this option seems to be broken, as it doesn't do anything. > > Thanks for packaging this openbsd port! Oh, right, almost forgot about that. That feature has to be enabled using the --with-timestamp configue flag. I'll add that flag in -3. Thank you for reminding me! -- Scupake :D 4737A2C0A769B53AE82F77922BD8BE5CDD5ADA16 signature.asc Description: PGP signature
Bug#877740: gedit-latex-plugin: diff for NMU version 3.20.0-1.2
On Sat, Feb 13, 2021 at 11:23:58AM +0100, Pietro Battiston wrote: > Thank you again! > > Meanwhile, I merged your changes back in salsa, where there is a new > version in principle ready to be uploaded: > https://salsa.debian.org/debian/gedit-latex-plugin > It fixes a number of small other issues which are not urgent, but > neither invasive. > > I'll let you judge if you want to proceed with this NMU or rather > upload the new version (notice I'm not a DD, so I need a sponsor > anyway). If you choose the second option, let me know beforehand and I > will quickly squeeze 3.20.0-1.2 out of debian/changelog. >... Sorry for the late reply (and I had my second NMU already uploaded). I've now uplaoded 3.20.0-2 after changing the distribution to unstable. > Pietro cu Adrian
Bug#983542: gnome-session-flashback: Wastebaske/t icon - label is linewrapped
Package: gnome-session-flashback Severity: minor Dear Maintainer, [This may well be reported against the wrong package, because it's not immediately clear to me what would cause this, so please reasign this bug as as you see fit.] As you can see here: https://openqa.debian.net/tests/11042#step/_graphical_wait_login/9 the Wastebasket's icon has it's label line-wrapped, such that it looks something like this: | | | | +--+ Wastebaske t This is immediately after install of one of today's daily images, from here: https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd//debian-testing-amd64-netinst.iso but this is not a recent development AFAIK. The versions of packages that produced this result should be visible in this file: https://openqa.debian.net/tests/11042/file/_collect_data-debs.log other detauls of the system are in the other "Logs & Assets": https://openqa.debian.net/tests/11042#downloads It seems to me that either a font that causes the word to fit on one line should be selected, or the word should be changed for a shorter one. If rewording is deemed the right way to fix this, I would suggest "Recycling" as a reasonable alternative: It's shorter, so ought to fit; also it matches the icon, which includes the circular-arrow recycling symbol. Cheers, Phil.
Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
Control: tags -1 confirmed Hi Stefano, On 25-02-2021 07:17, Stefano Rivera wrote: > Please unblock package python3-defaults and python3.9 > > Adding a new binary package, -full, to both source packages. Both are > currently in binNEW. We'll unblock with the understanding that the only difference is these new meta packages. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#983541: RFE: Please support pointopoint in the INET6 address family
Package: ifupdown Version: 0.8.36 Severity: wishlist Tags: ipv6 Hello currently the manual method for ipv6 does not support pointopoint configurations config ``` iface wg3 inet static pre-up ip link add $IFACE type wireguard pre-up wg setconf $IFACE /etc/wireguard/$IFACE.conf post-down ip link del $IFACE post-up wg set $IFACE fwmark 51097 address 172.21.68.1 netmask 255.255.255.255 pointopoint 172.21.68.9 iface wg3 inet6 static address fe80::1:100/128 pointopoint fdc5:30f7:af0a:1000::1 ``` resulting config ``` # ip -6 a s dev wg3 69: wg3: mtu 1420 state UNKNOWN qlen 1000 inet6 fe80::1:100/128 scope link valid_lft forever preferred_lft forever ``` while this configuration is supported by ip without problems (removing ipv6 config for wg3 in /etc/network/interfaces) ``` ip -6 addr add fe80::1:100 peer fdc5:30f7:af0a:1000::1 dev wg3 # ip -6 a s dev wg3 68: wg3: mtu 1420 state UNKNOWN qlen 1000 inet6 fe80::1:100 peer fdc5:30f7:af0a:1000::1/128 scope link valid_lft forever preferred_lft forever ``` thanks!
Bug#983540: binutils-dev: please make foreign binutils-dev installable
Package: binutils-dev
Version: 2.35.2-2
Severity: normal
Tags: patch
Dear Maintainer,
I'm trying to cross build some code that uses libbfd (not for Debian).
However, I can't install binutils-dev:${foreign-arch} because is depends
on binutils.
In #842439, all libraries previously provided by binutils have been
moved to the (then new) libbinutils binary package. At that time,
binutils-dev was changed to depend on both binutils and libbinutils.
However, that dependency on binutils is no longer needed since nothing
in binutils-dev really uses what's left in binutils itself (basically
just the programs).
Beyond dropping that dependency, adding `Multi-Arch: same` makes a
foreign binutils-dev co-installable with a native one.
The attached patch does both things.
-- 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
Kernel: Linux 5.10.0-3-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 binutils-dev depends on:
ii binutils 2.35.2-2
ii libbinutils2.35.2-2
ii libctf-nobfd0 2.35.2-2
ii libctf02.35.2-2
binutils-dev recommends no packages.
binutils-dev suggests no packages.
-- no debconf information
--- debian/control.orig 2021-02-25 16:27:19.056189876 -0300
+++ debian/control 2021-02-25 16:27:34.484574772 -0300
@@ -122,8 +122,9 @@
Package: binutils-dev
Architecture: any
+Multi-Arch: same
Priority: optional
-Depends: binutils (= ${binary:Version}), libbinutils (= ${binary:Version}),
+Depends: libbinutils (= ${binary:Version}),
libctf0 (= ${binary:Version}), libctf-nobfd0 (= ${binary:Version})
Conflicts: libbfd-dev
Provides: libbfd-dev
signature.asc
Description: PGP signature
Bug#983535: sbuild: source-only-changes only includes most recent changelog entry despite -v arg
Hi, Quoting William Blough (2021-02-25 20:34:42) > When passing -v via debbuildopt in conjunction with > --source-only-changes, the source-only changes file only includes the most > recent changelog entry as if the -v option was not present. The arch-specific > changes file does include the expected changelog entries. > > This can be worked around by copying/pasting the changelog entries from > the arch-specific changes file to the source-only changes file, but it > would be nice if doing so wasn't necessary. it seems you are running sbuild 0.79.1 which explains that you see this issue. This is the same as has already been reported in #884428, #891247, #917849, #947755 and fixed in 0.80.0. Would you like to do a backport of sbuild or rather wait until the next stable release? Thanks! cheers, josch signature.asc Description: signature
Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
On Thu, 25 Feb 2021 09:58:36 +0100 Paul Gevers wrote: > > On 25-02-2021 07:17, Stefano Rivera wrote: > > TL;DR: Debian heard of some upstream Python grumpyness about our > > standard library splits, recently. > > We have more upstreams being grumpy how we handle things in Debian. > > > This is all very badly timed for the > > freeze. > > Exactly. To be clear, we acted as soon as upstream attempted to engage Debian. This was not raised directly to Debian until early January, when the freeze had already begun. Hence, our attempts to determine what would be feasible and not overly disruptive before and after freeze. We have been moving as quickly as possible. > > Including a python3-full and python3.x-full packages, that Depends on > > the entire stdlib, is a compromise position to help them to support > > Python users on Debian (and derivative) platforms. > > This is the piece we're missing. What is it in Debian that makes this > support difficult? Why do we need to rush this into bullseye now? Stefano has written more at length about this in the previous reply, but tl;dr: when developers `apt install python`, they tend to expect the full Python standard library to be present as following the upstream documentation, and not a split. Right now, we are failing those users by asking them to figure out which packages to install on their own. By adding a metapackage "python3-full" which installs everything automatically to match the upstream expectations, we will provide a much smoother and improved user experience. Since this is merely a metapackage and no packages are permitted to depend on it directly, it should be a minimally invasive/disruptive change, even during freeze. We are basically adding a user-friendly alias. > Also, that message 00035 mentions two items that were considered as too > disruptive. Does fixing only the third item really warrant the upload > now, considering it seems to hint that you'll want to rename things > again after the release: > """ > - It was requested that we differentiate between "system" Python and > what upstream considers core Python. A package rename (e.g. python3 -> > python3-system) will confuse everyone and take multiple releases to > implement, and cannot be targeted until bookworm at the earliest. > """ Yes, because there is no guarantee that we will actually make these changes as requested. I mentioned them for completeness (to document all the discussions we had), not necessarily because there's been any concrete decision to act on them. I think python3-full is an obvious improvement over the status quo, and a minimally invasive change to introduce in freeze. Any other Python packaging changes are is up for debate. - e signature.asc Description: PGP signature
Bug#983539: false positive (.DEFAULT?) E: debian-rules-missing-required-target
Package: lintian Version: 2.104.0 Severity: normal I'm working on a yet-to-be-released package, binutils-sh-elf, which is a native package. I've attached the source for your examination. This package uses Debhelper. What I think causes the false positive is that, instead of using a pattern rule like %: dh $@ I use the .DEFAULT special target and also call mkdir prior, like: .DEFAULT: mkdir -p $(unpacked_dir) dh $@ -D$(unpacked_dir) -Bbuild The .DEFAULT special target, unlike pattern rules, is specified by POSIX, and as Lintian indicates this is an error, I'd very much appreciate if this could be fixed. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (2, 'unstable'), (1, 'testing-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.35.1-7 ii bzip2 1.0.8-4 ii diffstat 1.64-1 ii dpkg 1.20.7.1 ii dpkg-dev 1.20.7.1 ii file 1:5.39-3 ii gettext 0.21-4 ii gpg 2.2.27-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.39 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl 0.48-1 ii libclass-xsaccessor-perl 1.19-3+b7 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.24-1 ii libcpanel-json-xs-perl 4.25-1+b1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl 0.10-1.1 ii libdevel-size-perl 0.83-1+b2 ii libdpkg-perl 1.20.7.1 ii libemail-address-xs-perl 1.04-1+b3 ii libfile-basedir-perl 0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl 1.06-1.1 ii libhtml-html5-entities-perl 0.004-1.1 ii libipc-run3-perl 0.048-2 ii libjson-maybexs-perl 1.004003-1 ii liblist-compare-perl 0.55-1 ii liblist-moreutils-perl 0.430-2 ii liblist-utilsby-perl 0.11-1 ii libmoo-perl 2.004004-1 ii libmoox-aliases-perl 0.001006-1.1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.118-1 ii libperlio-gzip-perl 0.19-1+b7 ii libproc-processtable-perl 0.59-2+b1 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libtext-glob-perl 0.11-1 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.12-1+b1 ii libtext-xslate-perl 3.5.8-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl 2.3300-1 ii libtry-tiny-perl 0.30-1 ii libtype-tiny-perl 1.012001-1 ii libunicode-utf8-perl 0.62-1+b2 ii liburi-perl 5.07-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii libyaml-libyaml-perl 0.82+repack-1+b1 ii lzip 1.22-3 ii lzop 1.04-2 ii man-db 2.9.4-1 ii patchutils 0.4.2-1 ii perl [libdigest-sha-perl] 5.32.1-2 ii t1utils 1.41-4 ii unzip 6.0-26 ii xz-utils 5.2.5-1.0 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.35.1-7 ii libtext-template-perl 1.59-1 -- no debconf information binutils-sh-elf_1.tar.xz Description: application/xz-compressed-tar signature.asc Description: This is a digitally signed message part
Bug#983512: Bug#983513: debuerreotype: autopkgtest seems to hard-code amd64 signature
On Thu, 25 Feb 2021 at 12:09, Paul Gevers wrote: > On 25-02-2021 20:40, Tianon Gravi wrote: > > Hi Paul! Thanks for filing these -- I've pushed two commits to the > > Git repo which fix both 983512 and 983513 (and made it more forgiving > > of other architectures for the future). > > Can't you skip the hash test (but still run all the rest) on other > archs? If yes, then your d/t/control is OK, but if you only intend this > to be run on amd64 and arm64, there's a # in d/t/control that shouldn't > be there. Indeed! That's the approach I've taken in https://github.com/debuerreotype/debian-debuerreotype/commit/eec4eabf97a53642292e637da8a1932e1782400d#diff-408e3c392fd7a35b7ef0a5e5cfae15a6326c1a19af82263a0487d62ca2b35b81R44-R52 :) (So future unsupported architectures won't fail, but will instead encourage bug reporting which will give us a hash and a request for a new architecture to be fully supported. :D) I'm testing on buster with unstable schroots, so my autopkgtests doesn't support "Architecture:" and I decided to leave it as a comment since those are the ones we can run the full test on but others should still succeed. O:) > We're in soft freeze [1], no paperwork is needed except if your package > is in the (build-)essential set: > https://release.debian.org/bullseye/essential-and-build-essential.txt. Ah, easy! I'll "do the thing" then! ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
Bug#983271: devscripts: [INTL:pt] Portuguese translation of MANPAGE
A quinta-feira, 25 de fevereiro de 2021 20:10:56 WET Mattia Rizzolo escreveu: > Hi! Hi > > On Sun, Feb 21, 2021 at 08:43:49PM +, Américo Monteiro wrote: > > Updated Portuguese translation for devscripts's manpage > > Translator: Américo Monteiro > > Feel free to use it. > > Thank you! > This is not just an update, but a whole new transation, so I'll have to > go read that makefile concerning l10n that I never touched. oh well. I supose you just have to rename my file to pt.po and put it in some "po4a" directory in the source tree it should allready be there at least an de.po (german translation) and a fr.po (french) > > > There is also an addendum to add, hope it's allright. > > It's my first time seeing this. I see the ohter transations also have > some addendum, but none is in latex. Can you give me a pointer to what > is that thing and how it's supposed to work? > FWIW, devscripts doesn't build any latext documents. I'm not sure how it works... it's suppose to be a extra message that appear when someone read the manpage in Portuguese... I've copied the format from other manpages please ask the maintainers of debhelper or debconf packages, they got to know how to make that file work, in both manpages it's working (appears at the bottom of the manpage) Best regards Américo Monteiro
Bug#983538: debomatic: trivial suggestions for the packaging
Package: debomatic Severity: wishlist Tags: patch Hello. Please consider the attached cosmetic suggestions. 0005 is related to https://github.com/debomatic/debomatic/issues/52 0009 is deliberately missing (for now). 0010 affects upstream (but you are the upstream maintainer too) I may submit separate bugs or merge requests for changes that are not accepted or refused after a quick review. Thanks. debomatic-commits.tar.gz Description: application/gzip
Bug#983537: golang-github-pointlander-compress-dev should not depend on golang-go
Package: golang-github-pointlander-compress-dev
Version: 1.1.0-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:golang-github-pointlander-peg
The affected packages cannot satisfy their cross Build-Depends, because
their transitive dependency on golang-github-pointlander-compress-dev is
not satisfiable. In general, Architecture: all packages can never
satisfy cross Build-Depends unless marked Multi-Arch: foreign or
annotated :native. In this case, the foreign marking would be wrong due
to the runtime dependency on golang-any. This dependency seems wrong
however. golang-github-pointlander-compress can be built with gccgo and
go libraries should not depend on a go compiler without reason. I
therefore ask to drop this dependency. Please consider applying the
attached patch.
Helmut
diff --minimal -Nru golang-github-pointlander-compress-1.1.0/debian/changelog
golang-github-pointlander-compress-1.1.0/debian/changelog
--- golang-github-pointlander-compress-1.1.0/debian/changelog 2018-02-06
05:21:53.0 +0100
+++ golang-github-pointlander-compress-1.1.0/debian/changelog 2021-02-23
20:23:16.0 +0100
@@ -1,3 +1,10 @@
+golang-github-pointlander-compress (1.1.0-5.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop unnecessary golang-go runtime dependency. (Closes: #-1)
+
+ -- Helmut Grohne Tue, 23 Feb 2021 20:23:16 +0100
+
golang-github-pointlander-compress (1.1.0-5) unstable; urgency=medium
* Team upload.
diff --minimal -Nru golang-github-pointlander-compress-1.1.0/debian/control
golang-github-pointlander-compress-1.1.0/debian/control
--- golang-github-pointlander-compress-1.1.0/debian/control 2018-02-06
05:21:53.0 +0100
+++ golang-github-pointlander-compress-1.1.0/debian/control 2021-02-23
20:23:16.0 +0100
@@ -19,7 +19,6 @@
Architecture: all
Depends: ${shlibs:Depends},
${misc:Depends},
- golang-go,
golang-github-kjk-lzma-dev,
golang-github-nfnt-resize-dev
Description: parallelized modular compression library
Bug#983271: devscripts: [INTL:pt] Portuguese translation of MANPAGE
Hi! On Sun, Feb 21, 2021 at 08:43:49PM +, Américo Monteiro wrote: > Updated Portuguese translation for devscripts's manpage > Translator: Américo Monteiro > Feel free to use it. Thank you! This is not just an update, but a whole new transation, so I'll have to go read that makefile concerning l10n that I never touched. oh well. > There is also an addendum to add, hope it's allright. It's my first time seeing this. I see the ohter transations also have some addendum, but none is in latex. Can you give me a pointer to what is that thing and how it's supposed to work? FWIW, devscripts doesn't build any latext documents. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#983512: Bug#983513: debuerreotype: autopkgtest seems to hard-code amd64 signature
Hi Tianon, On 25-02-2021 20:40, Tianon Gravi wrote: > Hi Paul! Thanks for filing these -- I've pushed two commits to the > Git repo which fix both 983512 and 983513 (and made it more forgiving > of other architectures for the future). Can't you skip the hash test (but still run all the rest) on other archs? If yes, then your d/t/control is OK, but if you only intend this to be run on amd64 and arm64, there's a # in d/t/control that shouldn't be there. > I haven't uploaded yet because I'm concerned about / very unfamiliar > with the appropriate paperwork while we're in freeze, and don't want > to do anything wrong. :) We're in soft freeze [1], no paperwork is needed except if your package is in the (build-)essential set: https://release.debian.org/bullseye/essential-and-build-essential.txt. > If I do the upload, is there someone who can help me with the > necessary paperwork to make sure this isn't blocking / breaking anyone > else? O:) Minus my remark above, you changes look OK from a quick glance. Paul [1] https://release.debian.org/bullseye/freeze_policy.html#soft OpenPGP_signature Description: OpenPGP digital signature
Bug#974828: Fwd: Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup
Sorry missed your email. Weitergeleitete Nachricht Betreff: Re: Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup Datum: Thu, 25 Feb 2021 17:03:02 +0100 Von: Bernhard Übelacker An: 974...@bugs.debian.org Hello Ian, I tried to collect some informations for the maintainer in the other report #972339. Therefore I tried to reproduce this issue now too, because my amd64 hardware is much faster as my armhf systems... But I failed to reproduce maybe because I use the wrong ppd file, or something else might be different here. Do you still see this issue? Maybe you could make your /etc/cups/ppd/HP_Officejet_Pro_8610.ppd public? Or maybe this issue might be reproducible just with one of your print_step_2.raster file, if size permits and its possible to make it public? Kind regards, Bernhard
Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup
Hello Ian, I tried to collect some informations for the maintainer in the other report #972339. Therefore I tried to reproduce this issue now too, because my amd64 hardware is much faster as my armhf systems... But I failed to reproduce maybe because I use the wrong ppd file, or something else might be different here. Do you still see this issue? Maybe you could make your /etc/cups/ppd/HP_Officejet_Pro_8610.ppd public? Or maybe this issue might be reproducible just with one of your print_step_2.raster file, if size permits and its possible to make it public? Kind regards, Bernhard
Bug#983507: mame FTBFS on armel and mipsel: Cannot allocate memory (armel) / ar failure (mipsel)
I already looked at this, and in the mipsel build gcc runs out of address space even with "OPTIMIZE = 0". My suggestion would be to file architecture-specific RM bugs, MAME is anyway unlikely to have users there. cu Adrian
Bug#983536: nm-tray: no icon shown in tray
Package: nm-tray Version: 0.4.3-2+b1 Severity: normal X-Debbugs-Cc: matl...@gmail.com Dear Maintainer, * What led up to the situation? Running nm-tray * What exactly did you do that was ineffective? I started nm-tray from a terminal under i3 * What was the outcome of this action? The application started but, on the tray, a blank space appeared * What outcome did you expect instead? I expected to see an icon in the tray instead of the blank space on the tray -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nm-tray depends on: ii konsole [x-terminal-emulator] 4:20.12.2-1 ii libc6 2.31-9 ii libgcc-s1 [libgcc1]10.2.1-6 ii libkf5networkmanagerqt65.79.0-1~np1 ii libqt5core5a 5.15.2+dfsg-4 ii libqt5dbus55.15.2+dfsg-4 ii libqt5gui5 5.15.2+dfsg-4 ii libqt5network5 5.15.2+dfsg-4 ii libqt5widgets5 5.15.2+dfsg-4 ii libstdc++6 10.2.1-6 ii network-manager1.28.0-2+b1 ii xterm [x-terminal-emulator]366-1 Versions of packages nm-tray recommends: ii nm-tray-l10n 0.4.3-2 nm-tray suggests no packages. -- no debconf information
Bug#983100: libboost-python1.74-dev: multiarchify python dependency
Hi, Il 18/02/21 20:46, Helmut Grohne ha scritto: The affected packages cannot satisfy their cross Build-Depends, because their transitive dependency on the host architecture Python interpreter is not installable. The host architecture Python interpreter is required from libboost-python1.74-dev -> python3-dev -> python3. For building python extensions, one usually wants a build architecture python and the host architecture python development files. This is expressed as "python3-dev:any, libpython3-dev". For single-architecture installations, nothing changes. Please consider applying the attached patch. I'd say that's ok for me. Could you please NMU? Sorry for the delay, Giovanni. -- Giovanni Mascellani
Bug#983365: linphone-desktop: chat messages
The file rules.patch got mangled in transit. Attached is the integrous version. rules.patch.gz Description: application/gzip
Bug#983512: Bug#983513: debuerreotype: autopkgtest seems to hard-code amd64 signature
On Thu, 25 Feb 2021 at 04:18, Paul Gevers wrote: > Your package has an autopkgtest, great. However, it always fails on > non-amd64 architectures. Looking at the error message, it seems to > compare the build tar ball with a pre-computed hash that's only valid on > amd64. (And then the log becomes insanely long.) Hi Paul! Thanks for filing these -- I've pushed two commits to the Git repo which fix both 983512 and 983513 (and made it more forgiving of other architectures for the future). I haven't uploaded yet because I'm concerned about / very unfamiliar with the appropriate paperwork while we're in freeze, and don't want to do anything wrong. :) If I do the upload, is there someone who can help me with the necessary paperwork to make sure this isn't blocking / breaking anyone else? O:) At https://github.com/debuerreotype/debian-debuerreotype/compare/debian/0.10-1...master you can see the full diff from what's in unstable currently to what I'm proposing to upload (which I don't think contains anything terribly alarming beyond the two fixes for these bugs -- mostly just Janitor changes). ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
Bug#881671: sudo: please ship Apport hook
On Tue, Nov 14, 2017 at 12:24:58AM +0100, Balint Reczey wrote: > Please consider shipping an Apport hook like many other packages in Debian. > I attached the patch carried in Ubuntu for adding the hook, please > consider merging it. Your python script has a shebang line /usr/bin/python, which many Debian unstable systems don't have any more. Also, it imports from the apport module, which doesn't seem to be in Debian. Are you sure that your patch makes sense for the Debian package? Does it just need updating or has it bitrotted away in the three years since it was filed? Greetings Marc
Bug#983526: buster-pu: package python-django/1:1.11.29-1+deb10u1
Hi Chris, On Thu, Feb 25, 2021 at 04:42:55PM +, Chris Lamb wrote: > Package: release.debian.org > Severity: normal > Tags: buster > User: release.debian@packages.debian.org > Usertags: pu > > Dear stable release managers, > > Please consider python-django (1:1.11.29-1+deb10u1) for buster: > > python-django (1:1.11.29-1+deb10u1) buster; urgency=high > . > * CVE-2021-23336: Prevent a web cache poisoning attack via "parameter > cloaking". Django contains a copy of urllib.parse.parse_qsl() which was > added to backport some security fixes. A further security fix has been > issued recently such that parse_qsl() no longer allows using ";" as a > query parameter separator by default. (Closes: #983090) > . > For more information, please see: > . > https://www.djangoproject.com/weblog/2021/feb/19/security-releases/ There are as well yet open other issues (which similarly do not warrant a DSA), CVE-2021-3281, CVE-2020-24583 and CVE-2020-24584. Can you add fixes for those as well? > The full diff is attached. The security team believe this should go > via s-p-u rather than via a DLA (if at all): > >https://bugs.debian.org/983090#27 > > Please double-check the version number for me. The current version in > buster-security is 1:1.11.29-1~deb10u1 (with a tilde). The version should IMHO be still smaller as 1:1.11.29-1 but incremented, so I would use 1:1.11.29-1~deb10u2, as it is patched with respect to 1:1.11.29-1~deb10u1. Regards, Salvatore
Bug#983090: python-django: CVE-2021-23336
Hi Chris, On Thu, Feb 25, 2021 at 04:47:34PM +, Chris Lamb wrote: > Sébastien Delafond wrote: > > > > > Django is vulnerable because it embeds parse_qsl: > > > > > > > > https://www.djangoproject.com/weblog/2021/feb/19/security-releases/ > > > > > > Security team, let me know if you would like an update for stable. > […] > > we think this should rather go via s-p-u. > > ACK. Have filed #983526 for this purpose. Can you please add as well the fixes for the other open issues? Will reply there with the same message. Regards, Salvatore
Bug#983535: sbuild: source-only-changes only includes most recent changelog entry despite -v arg
Package: sbuild Version: 0.79.1-1~bpo10+1 Severity: normal Hi, When passing -v via debbuildopt in conjunction with --source-only-changes, the source-only changes file only includes the most recent changelog entry as if the -v option was not present. The arch-specific changes file does include the expected changelog entries. This can be worked around by copying/pasting the changelog entries from the arch-specific changes file to the source-only changes file, but it would be nice if doing so wasn't necessary. -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 sbuild depends on: ii adduser 3.118 ii libsbuild-perl 0.79.1-1~bpo10+1 ii perl5.28.1-6+deb10u1 Versions of packages sbuild recommends: ii autopkgtest 5.10 ii debootstrap 1.0.114 ii schroot 1.6.10-6+b1 Versions of packages sbuild suggests: pn deborphan ii e2fsprogs 1.44.5-1+deb10u3 ii kmod 26-1 ii wget 1.20.1-1.1 -- Configuration Files: /etc/sbuild/sbuild.conf changed [not included] -- no debconf information
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
Found this in the junk e-mails today... Am 23.02.21 um 19:20 schrieb Sebastiaan Couwenberg: There is still a test failure, though. Refer to the attached buildlog for details. This seems unrelated to PROJ 8.0.0. The failing test creates a QTemporaryFile, removes all permissions from the file via QFile::setPermissions(), and expects QFileInfo::readable() to return false for the path of the temporary file. This expectation seems to be not met. The test may be volatile, but worked so far, and I didn't have a better idea how to solve this in a portable way. If there is another change in the environment, hints are welcome. Best regards, Kai
Bug#192522: sudo: should validate sudoers on upgrade and abort if incompatible
notforwarded #192522 thanks # this is not an upstream issue On Thu, May 08, 2003 at 10:11:03PM +0100, James Troup wrote: > [? maybe not but it left me with one dead box, so I'm inclined to > inflate right now, downgrade if you want...] > > I just upgraded a hideous potato/sid hybrid box to woody; it use to > have sudo 1.6.3p7-2 on it and when I installed 1.6.6-1.1 sudo broke > complaining about a syntax error in /etc/sudoers. This screwed me > quite nicely since I had neither an open root shell nor the root > password. I think it'd be really nice if sudo would validate > /etc/sudoers on upgrade and if it finds syntax errors abort the > upgrade (or at least offer to). This is indeed a completly ugly situation, potentially leaving a user without working root access if the root account doesn't have a password assigned. > [Doing this would be interesting, you'd probably have to save a copy > of the old sudo binary in the preinst, check with the new binary in > the postinst and then restore it, if the new sudo can't validate > sudoers, in the postinst - but given the alternative, I think it's > worth it.] I am not sure where in poliy it is written, but I pretty well believe that a package is not supposed to meddle around with files in /usr, this being dpkg's domain. dpkg -D12 has still been a great help in finding the following things that I am recording here so that they are not forgotten. When dpkg unpacks a package during upgrade, there is a moment when the new binary is already there (as filename.dpkg-something) at the side of the untouched old binary. In this phase, the prerm script of the OLD package is run, so we could theoretically call the new binary and find out whether it is ready to eat the new configuration file. I expect that a non-zero exit code might probably cause dpkg to abort and roll back the package installation. I haven't actually tried this. The disadvantage of this approach is that an adapted prerm script would be useless in the first update round of the package since dpkg calls the OLD package's prerm during upgrade which doesn't have the new code yet. The protection of this code would not be useful until the SECOND round of upgrades. In addition, this "extra round" of package updates would also be needed for bug fixes in the code and such an round cannot even be forced here. Also, this feels like wading knee deep inside dpkg internals. I am therefore reluctant to implement this at the moment. Maybe this text can motivate somebody else to take a look at this after the bullseye release. I might do that myself because it's an interesting topic, but I wouldn't suggest that anybody hold their breath waiting for me. Maybe it would also be a valid approach to check whether sudo will accept the current configuration and if not, display a big fat warning and replace the configuration with the package's default. This might grant people from the sudo group more privileges as intended, but that might be better to do it this way than having the user end up with an inaccessible root account. A new sudo choking on an old, custom-made configuration is an unfortunate situation, but since this bug report is almost 20 years old and still hasn't accumulated any horror stories of people locking theirselves out, it's seldom enough to let this issue rest another bit. Not being able to properly roll back after a failed upgrade is a dpkg/Debian shortcoming in the first place. Greetings Marc
Bug#974828: Fwd: Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup
Control: found -1 3.20.11+dfsg0-2 Control: found -1 3.21.2+dfsg1-1 On Thu, 2021-02-25 at 18:32 +, Ian Campbell wrote: > I'll see if I can upgrade and repeat. Confirmed I see this with both the current bullseye and sid versions of printer-driver-hpcups. Ian.
Bug#982530: libpam-modules: unable to login when using pam_tally2 after upgrade to libpam-modules >1.4.0
In adapting your first patch, I narrowed things down a bit. I search /etc/pam.d files containing only a-z0-9A-Z, which I believe should catch all the active pam.d files but not editor backups, .pam-new files and the like. I also specifically recommend looking at pam_faillock. --Sam
Bug#983429: mosquitto: /run/mosquitto is on a tmpfs and should be created dynamically
The systemd unit file should recreate the folder each time the service is started. It uses /var/run/mosquitto instead of /run/mosquitto, but that should work through the /var/run symlink. Does this definitely not work for you? On Wed, 24 Feb 2021 at 01:15, Alexandre Detiste wrote: > > Package: mosquitto > Version: 2.0.7-3 > Severity: minor > > /run/mosquitto shows up in cruft-ng report as existing in dpkg database > but missing from the filesystem, if service has been disabled before boot. > > please create /run/mosquitto dynamically on boot > > fix_permissions() in postinst seams not enough. > > Greetings, > > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (501, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads) > Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), > LANGUAGE=fr_BE:fr > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages mosquitto depends on: > ii adduser 3.118 > ii libc62.31-9 > ii libcjson11.7.14-1 > ii libdlt2 2.18.6-1 > ii libmosquitto12.0.7-3 > ii libssl1.11.1.1j-1 > ii libsystemd0 247.3-1 > ii libwebsockets16 4.0.20-2 > ii libwrap0 7.6.q-31 > ii lsb-base 11.1.0 > > mosquitto recommends no packages. > > Versions of packages mosquitto suggests: > pn apparmor > > -- no debconf information
Bug#983532: freecad: Version number not shown correctly in Help -> About FreeCAD
Package: freecad Version: 0.19~pre1+git20210207.a3fb41502b+dfsg-1 Severity: normal X-Debbugs-Cc: a...@wotcc.org.uk Dear Maintainer, When following Help -> About FreeCAD The version number is blank Using the copy to clipboard button it shows the version but not the build number. Shown is Version: 0.19. On the Appimage you get Version: 0.19.24212 (Git) AppImage And on a local buidl from git Version: 0.19.24226 (Git) Sorry if you get this twice I tried a few hours ago and no email has been recieved, nor has it appeared on the bugs page, I have reconfigured my Reportbug -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages freecad depends on: ii freecad-python3 0.19~pre1+git20210207.a3fb41502b+dfsg-1 Versions of packages freecad recommends: ii calculix-ccx 2.17-3 ii graphviz 2.42.2-4+b2 Versions of packages freecad suggests: pn povray
Bug#655211: sudo: add non EBNF'ed manpages
Version: 1.9.5-1 On Mon, Jan 09, 2012 at 11:35:35AM +0100, Michael Schmitt wrote: > please consider adding a more descriptive manpage avoiding EBNF syntax. The sudoers man page still has EBNF, but has become a lot more descriptive. I am therefore closing this bug for version 1.9.5, because I cannot easily find out when the man page improvement actually took place. If it's still not descriptive enough, please re-open this issue. Greetings Marc
Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
Hi Paul (2021.02.25_08:58:36_+) > > Including a python3-full and python3.x-full packages, that Depends on > > the entire stdlib, is a compromise position to help them to support > > Python users on Debian (and derivative) platforms. > > This is the piece we're missing. What is it in Debian that makes this > support difficult? Beginner Python developers install "python" on their machine, and then get surprised when some standard library modules fail to import. The examples we've seen are most commonly distutils, venv, and lib2to3 (used by tools like black, apparently). The existence of "python3-full" doesn't immediately change this situation. But it does give people providing support a simple instruction to give the users. What they really would have liked is a "python" package that installs the full python developer environment, not the more minimal python that Debian packages need. But that's a *huge* change that would take multiple releases to achieve. I don't think the Debian Python community has the will to do that. This as an entirely political change. It's a peace offering, to try to improve communication with the grumpier parts of the upstream community. If we respond to their concerns, we can hope that they will bring them to us sooner, in the future. > Why do we need to rush this into bullseye now? Because this blew in up late Jan, and bullseye is the next release after that. We didn't rush to get it in before the freeze, to be sure that the Debian Python community was on board, and the upstream community agreed with the details. We have explained that bullseye was going into freeze, and making this change now may be difficult. So not forcing your hand, here. Feel free to reject it. It will come back to the Stable Release Team for .1, though. > Also, that message 00035 mentions two items that were considered as too > disruptive. Does fixing only the third item really warrant the upload > now, considering it seems to hint that you'll want to rename things > again after the release: > """ > - It was requested that we differentiate between "system" Python and > what upstream considers core Python. A package rename (e.g. python3 -> > python3-system) will confuse everyone and take multiple releases to > implement, and cannot be targeted until bookworm at the earliest. > """ As above, I think that change is a *huge* transition, that I don't think we have the will to push for in Debian. So, I wouldn't count on it happening. We're hoping to have a cross-distro Python packaging discussion at the next PyCon. That may push us towards wanting to take changes like that. But it'll still need people within Debian to drive it. Small steps. Hopefully they make things better. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#983530: fastboot: please update fastboot. Current version hangs with my smartphone
Package: fastboot Version: 1:10.0.0+r36-7 Followup-For: Bug #983530 X-Debbugs-Cc: schissdra...@rmm.li I've just realized. It doesn't have anything to do with the fastboot version. It only accidentally worked with the new one. As it seems the only way to make it work is (independently the version): - Disconnect the device - execute the fastboot command, so it says: "< waiting for any device >" - connection the device - now the fastboot command will be executed correctly. so I guess that's just a normal bug report then, now idea how to change the subject though
Bug#983210: atlas-ecmwf: FTBFS with PROJ 8.0.0
Control: tags -1 patch
On 2/21/21 7:23 AM, Bas Couwenberg wrote:
> Your package FTBFS with PROJ 8.0.0:
>
> /usr/include/proj.h:345:23: error: type alias redefinition with different
> types ('struct pj_ctx' vs 'struct projCtx_t') [clang-diagnostic-error]
> typedef struct pj_ctx PJ_CONTEXT;
>^
>
> /home/bas/tmp/debian/atlas-ecmwf-0.23.0/src/atlas/projection/detail/ProjProjection.h:23:7:
> note: previous definition is here
> using PJ_CONTEXT = struct projCtx_t;
>^
> 2156 warnings and 1 error generated.
> Error while processing
> /home/bas/tmp/debian/atlas-ecmwf-0.23.0/src/atlas/projection/detail/ProjProjection.cc.
The attached patch fixes the issue.
It's pretty much the same as the one for magics++ (#983236)
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
--- a/src/atlas/projection/detail/ProjProjection.cc
+++ b/src/atlas/projection/detail/ProjProjection.cc
@@ -9,10 +9,10 @@
*/
-#include "ProjProjection.h"
-
#include
+#include "ProjProjection.h"
+
#include "eckit/types/FloatCompare.h"
#include "eckit/utils/Hash.h"
--- a/src/atlas/projection/detail/ProjProjection.h
+++ b/src/atlas/projection/detail/ProjProjection.h
@@ -17,12 +17,14 @@
#include "atlas/util/Config.h"
+#if PROJ_VERSION_MAJOR < 8
extern "C" {
using PJ = struct PJconsts;
PJ* proj_destroy( PJ* );
using PJ_CONTEXT = struct projCtx_t;
PJ_CONTEXT* proj_context_destroy( PJ_CONTEXT* );
}
+#endif
namespace atlas {
Bug#983531: buster-pu: package python2.7/2.7.16-2+deb10u2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@debian.org
debdiff below fixes three security issues, which don't warrant a DSA by itself.
Update has been tested on a Buster few systems (and verified with the PoCs).
Cheers,
Moritz
diff -u python2.7-2.7.16/debian/changelog python2.7-2.7.16/debian/changelog
--- python2.7-2.7.16/debian/changelog
+++ python2.7-2.7.16/debian/changelog
@@ -1,3 +1,11 @@
+python2.7 (2.7.16-2+deb10u2) buster; urgency=medium
+
+ * CVE-2020-8492 (Closes: #970099)
+ * CVE-2019-20907 (Closes: #970099)
+ * CVE-2021-3177
+
+ -- Moritz Mühlenhoff Wed, 24 Feb 2021 20:33:20 +0200
+
python2.7 (2.7.16-2+deb10u1) buster; urgency=medium
* CVE-2018-20852
diff -u python2.7-2.7.16/debian/patches/series.in
python2.7-2.7.16/debian/patches/series.in
--- python2.7-2.7.16/debian/patches/series.in
+++ python2.7-2.7.16/debian/patches/series.in
@@ -80,0 +81,3 @@
+CVE-2019-20907.diff
+CVE-2020-8492.diff
+CVE-2021-3177.diff
only in patch2:
unchanged:
--- python2.7-2.7.16.orig/debian/patches/CVE-2019-20907.diff
+++ python2.7-2.7.16/debian/patches/CVE-2019-20907.diff
@@ -0,0 +1,26 @@
+From 47a2955589bdb1a114d271496ff803ad73f954b8 Mon Sep 17 00:00:00 2001
+From: "Miss Islington (bot)"
+ <31488909+miss-isling...@users.noreply.github.com>
+Date: Wed, 15 Jul 2020 05:36:36 -0700
+Subject: [PATCH] bpo-39017: Avoid infinite loop in the tarfile module
+ (GH-21454) (#21485)
+
+Avoid infinite loop when reading specially crafted TAR files using the tarfile
module
+(CVE-2019-20907).
+(cherry picked from commit 5a8d121a1f3ef5ad7c105ee378cc79a3eac0c7d4)
+
+Co-authored-by: Rishi
+
+diff --git a/Lib/tarfile.py b/Lib/tarfile.py
+index adf91d5..574a6bb 100644
+--- a/Lib/tarfile.py
b/Lib/tarfile.py
+@@ -1400,6 +1400,8 @@ class TarInfo(object):
+
+ length, keyword = match.groups()
+ length = int(length)
++if length == 0:
++raise InvalidHeaderError("invalid header")
+ value = buf[match.end(2) + 1:match.start(1) + length - 1]
+
+ keyword = keyword.decode("utf8")
only in patch2:
unchanged:
--- python2.7-2.7.16.orig/debian/patches/CVE-2020-8492.diff
+++ python2.7-2.7.16/debian/patches/CVE-2020-8492.diff
@@ -0,0 +1,26 @@
+Backport of 0b297d4ff1c0e4480ad33acae793fbaf4bf015b4, trimmed down to the
+fix for CVE-2020-8492
+
+Co-Authored-By: Serhiy Storchaka
+diff --git a/Lib/urllib2.py b/Lib/urllib2.py
+index 8b634ad..11a62a4 100644
+--- a/Lib/urllib2.py
b/Lib/urllib2.py
+@@ -856,8 +856,15 @@ class AbstractBasicAuthHandler:
+
+ # allow for double- and single-quoted realm values
+ # (single quotes are a violation of the RFC, but appear in the wild)
+-rx = re.compile('(?:.*,)*[ \t]*([^ \t]+)[ \t]+'
+-'realm=(["\']?)([^"\']*)\\2', re.I)
++rx = re.compile('(?:^|,)' # start of the string or ','
++'[ \t]*'# optional whitespaces
++'([^ \t]+)' # scheme like "Basic"
++'[ \t]+'# mandatory whitespaces
++# realm=xxx
++# realm='xxx'
++# realm="xxx"
++'realm=(["\']?)([^"\']*)\\2',
++re.I)
+
+ # XXX could pre-emptively send auth info already accepted (RFC 2617,
+ # end of section 2, and section 1.2 immediately after "credentials"
only in patch2:
unchanged:
--- python2.7-2.7.16.orig/debian/patches/CVE-2021-3177.diff
+++ python2.7-2.7.16/debian/patches/CVE-2021-3177.diff
@@ -0,0 +1,149 @@
+bpo-42938: Replace snprintf with Python unicode formatting in ctypes param
reprs.
+--- a/Lib/ctypes/test/test_parameters.py
b/Lib/ctypes/test/test_parameters.py
+@@ -206,6 +206,49 @@
+ with self.assertRaises(ZeroDivisionError):
+ WorseStruct().__setstate__({}, b'foo')
+
++def test_parameter_repr(self):
++from ctypes import (
++c_bool,
++c_char,
++c_wchar,
++c_byte,
++c_ubyte,
++c_short,
++c_ushort,
++c_int,
++c_uint,
++c_long,
++c_ulong,
++c_longlong,
++c_ulonglong,
++c_float,
++c_double,
++c_longdouble,
++c_char_p,
++c_wchar_p,
++c_void_p,
++)
++self.assertRegexpMatches(repr(c_bool.from_param(True)), r"^$")
++self.assertEqual(repr(c_char.from_param('a')), "")
++self.assertRegexpMatches(repr(c_wchar.from_param('a')), r"^$")
++self.assertEqual(repr(c_byte.from_param(98)), "")
++self.assertEqual(repr(c_ubyte.from_param(98)), "")
++self.assertEqual(repr(c_short.from_param(511)), "")
++self.assertEqual(repr(c_ushort.from_param(511)), "")
++self.assertRegexpMatches(repr(c_int.from_param(2)), r"^$")
++
Bug#983523: general: some WWW sites no longer work neither in Firefox nor in Chrome
On Thu, Feb 25 2021 at 10:27 -08, William Unruh wrote: > This really is a useless bug report. How can anyone try to duplicate it? > You do not tell anyone who your internet provider is, How you try to get > the "chat", what internet site you go to, and what kind of goods you > select. The chat is available only for the logged customer of the Internet provider. FYI, it is Multimedia - does it really help? On the other hand you can pretend to be a potential customer of https://kucharekszesc.pl/pl/ (I'm afraid the site is available only in Polish). Anyway a clue should be provided by the fact the both (perhaps all?) browsers are affected. The things broke several weeks ago, perhaps after the upgrade to 10.8. Best regards janusz -- , Janusz S. Bien emeryt (emeritus) https://sites.google.com/view/jsbien
Bug#983523: general: some WWW sites no longer work neither in Firefox nor in Chrome
This really is a useless bug report. How can anyone try to duplicate it? You do not tell anyone who your internet provider is, How you try to get the "chat", what internet site you go to, and what kind of goods you select. In linux.debian.devel, you wrote: > Package: general > Severity: normal > > I was angry with my Internet provider because on their site since > several weeks the chat was reported as not available. It appeared the > chat works all the time in any Windows browser. > > Today I tried to order some goods by Internet, by I was unable to select > the interesting items with a click neither in Firefox nor in > Chrome. Again it appeared that it works in any Windows browser. >
Bug#983530: fastboot: please update fastboot. Current version hangs with my smartphone
Package: fastboot Version: 1:10.0.0+r36-7 Severity: normal X-Debbugs-Cc: schissdra...@rmm.li When trying to flash a recovery to my smartphone (poco x3). It hangs forever at Sending 'recovery' (131072 KB) After a while an error appears in dmesg: [227526.825738] INFO: task fastboot:960640 blocked for more than 120 seconds. [227526.825742] Tainted: G OE 5.10.0-3-amd64 #1 Debian 5.10.13-1 [227526.825743] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [227526.825745] task:fastbootstate:D stack:0 pid:960640 ppid:959360 flags:0x [227526.825747] Call Trace: [227526.825753] __schedule+0x282/0x870 [227526.825755] ? usleep_range+0x80/0x80 [227526.825757] schedule+0x46/0xb0 [227526.825758] schedule_timeout+0xff/0x140 [227526.825761] ? __prepare_to_swait+0x4b/0x70 [227526.825762] __wait_for_common+0xae/0x160 [227526.825774] usb_start_wait_urb+0x83/0x160 [usbcore] [227526.825783] do_proc_bulk+0x12e/0x2c0 [usbcore] [227526.825792] usbdev_ioctl+0x299/0x1060 [usbcore] [227526.825796] __x64_sys_ioctl+0x83/0xb0 [227526.825797] do_syscall_64+0x33/0x80 [227526.825799] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [227526.825801] RIP: 0033:0x7f1e24e8acc7 [227526.825803] RSP: 002b:7ffd36ed8fa8 EFLAGS: 0246 ORIG_RAX: 0010 [227526.825804] RAX: ffda RBX: RCX: 7f1e24e8acc7 [227526.825805] RDX: 7ffd36ed8fb8 RSI: c0185502 RDI: 0004 [227526.825806] RBP: 7ffd36ed8fd0 R08: 021d42a0 R09: [227526.825807] R10: 7ffd36f0d080 R11: 0246 R12: 0040 [227526.825807] R13: 021d30d0 R14: 0040 R15: 7ffd36ed9140 With the newest fastboot version from following url: https://dl.google.com/android/repository/platform-tools_r31.0.0-linux.zip it works. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (600, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fastboot depends on: ii android-libadb 1:10.0.0+r36-7 ii android-libbase1:10.0.0+r36-7 ii android-libboringssl 10.0.0+r36-1 ii android-libcutils 1:10.0.0+r36-7 ii android-libext4-utils 10.0.0+r36+ds-2 ii android-libsparse 1:10.0.0+r36-7 ii android-libunwind 10.0.0+r36-4 ii android-libziparchive 1:10.0.0+r36-7 ii android-sdk-platform-tools-common 28.0.2+3 ii libc6 2.31-9 ii libgcc-s1 10.2.1-6 ii libstdc++6 10.2.1-6 fastboot recommends no packages. Versions of packages fastboot suggests: pn android-sdk-platform-tools
Bug#982060: run-mailcap: special characters in file names break "open"
Le Sat, Feb 06, 2021 at 07:35:16AM +0100, Marriott NZ a écrit : > > run-mailcap fails if run as "open" on file names containing special > characters. > It also allows shell command injection from file names (again: > https://www.debian.org/security/2014/dsa-3114). Thanks Mariott for the head-up. I totally forgot about this. > The problem originates from this commit: > https://salsa.debian.org/debian/mailcap/-/commit/66f82f13d86d565ebe249a8b56da8dd0cb63e2ef > > Prevent run-mailcap from creating a temporary copy when run as "open". I will revert it. > The man page is giving false information, please fix this too: Thanks for spotting this as well. > An alternative to making a temporary symlink would be to properly > quote special characters in the file name (as described here: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980345). I will have a lood at this but first will upload the fix for /usr/bin/open. Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Bug#983236: magics++: FTBFS with PROJ 8.0.0
Control: tags -1 patch
On 2/21/21 1:21 PM, Bas Couwenberg wrote:
> Your package FTBFS with PROJ 8.0.0:
>
> /usr/include/proj.h:123:4: error: #error "The proj_api.h header has been
> removed from PROJ with version 8.0.0"
>123 | #error "The proj_api.h header has been removed from PROJ with
> version 8.0.0"
>|^
> /usr/include/proj.h:345:23: error: conflicting declaration 'typedef struct
> pj_ctx PJ_CONTEXT'
>345 | typedef struct pj_ctx PJ_CONTEXT;
>| ^~
> In file included from /build/magics++-4.5.3/src/common/ProjP.cc:19:
> /build/magics++-4.5.3/src/common/ProjP.h:18:26: note: previous declaration
> as 'typedef struct projCtx_t PJ_CONTEXT'
> 18 | typedef struct projCtx_t PJ_CONTEXT;
>| ^~
> make[3]: *** [src/CMakeFiles/MagPlus.dir/build.make:4418:
> src/CMakeFiles/MagPlus.dir/common/ProjP.cc.o] Error 1
The problem is twofold.
ACCEPT_USE_OF_DEPRECATED_PROJ_API_H is still defined in d/rules, which
triggers the first error. Since upstream uses proj.h, there is no need
for this any more. Apply the changes in magics++_4.5.3-1.1.debdiff to
fix this.
The second error is fixed by disabling the typedefs for the conflicting
declarations when PROJ_VERSION_MAJOR is >= 8. This is done by proj8.patch.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
--- magics++-4.5.3/debian/rules 2021-01-21 13:39:40.0 +0100
+++ magics++-4.5.3/debian/rules 2021-02-21 13:05:37.0 +0100
@@ -7,8 +7,8 @@
# To enable all, uncomment following line
# DEB_BUILD_MAINT_OPTIONS:= hardening=+all,-pie
-CXXFLAGS:= -fPIC $(shell dpkg-buildflags --get CXXFLAGS)
-DACCEPT_USE_OF_DEPRECATED_PROJ_API_H # -std=c++14
-CFLAGS:= -fPIC $(shell dpkg-buildflags --get CFLAGS)
-DACCEPT_USE_OF_DEPRECATED_PROJ_API_H=1
+CXXFLAGS:= -fPIC $(shell dpkg-buildflags --get CXXFLAGS) # -std=c++14
+CFLAGS:= -fPIC $(shell dpkg-buildflags --get CFLAGS)
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
# Set for build reproducibility
--- a/src/common/ProjP.h
+++ b/src/common/ProjP.h
@@ -14,8 +14,10 @@
#include "magics.h"
+#if PROJ_VERSION_MAJOR < 8
typedef struct PJconsts PJ;
typedef struct projCtx_t PJ_CONTEXT;
+#endif
namespace magics {
--- a/src/common/ProjP.cc
+++ b/src/common/ProjP.cc
@@ -16,8 +16,8 @@
Apr 06: update for GCC 4.0 (Stephan)
*/
-#include
#include
+#include
using namespace magics;
Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2
On Thu, Feb 25, 2021 at 12:05:39PM +0100, Jerome BENOIT wrote: > I was rather wondering if setting Rules-Requires-Root to yes in d/rules > will ask to bbuild to act as "needs-root" for autopkgtest. No. Rules-Requires-Root is only to tell the build scripts that some parts of the build requires real or fake root. autopkgtests are not primarily intended for running builds. Their actual purpose is to test packages as-installed. Building packages in an autopkgtest is only suitable if some extraordinary circumstance necessitates that (which is the case here as it is necessary for setting /proc/sys/kernel/unprivileged_userns_clone to 1). So it wouldn't make sense for it to reuse settings intended for build scripts. I don't know if you have seen the autopkgtest FAQ for maintainers: https://ci.debian.net/doc/file.MAINTAINERS.html And maybe take some notes on which steps you needed to take to set up your LXC autopkgtest environment. Maybe that can be fleshed out into a short tutorial for other maintainers facing similar situations. Regards, Dennis.
Bug#982356: (no subject)
I think this bug is due to the switch to fai for testing/bullseye. IIRC with fai, we run a dhcp client for each interface, which would cause the double IP adresses you see (one set up by DHCP, one set up by Vagrant directly over ssh when booting the VM)
Bug#983365: linphone-desktop: chat messages
Control: tag -1 + confirmed sid bullseye
I looked into this the past days, and I think this is actually a bug
in d/rules in src:linphone. I'm beginning to suspect that this is due
to this line:
-DENABLE_DB_STORAGE=NO \
Apparently the code for the once separate chat history and call
history DBs has been merged into a single DB with special logic to
handle the migration -- since I have no files from a previous version
linphone-desktop 4.2.5 here does not even create anymore the sqlite3
database linphone.db in ~/.local/share/linphone/ that David mentions,
only call-history.db and friends.db are created (which matches the
source code). However, if the database storage isn't configured and
compiled in then that new database is not going to work of course.
Was there a specific reason for disabling this? I could get
linphone-4.4.21 to build with -DENABLE_DB_STORAGE=YES, but I had to
first build+install a version of libsoci-dev that was compiled with
-DSOCI_CXX11=YES. I'll contact the soci maintainer to see if he can
change that in time.
linphone-4.4.21/cmake/FindSoci.cmake calls the soci support
experimental, but the official appimage ships with both libsoci_core.0
and libsoci_sqlite3.0, so it should be stable enough for us, too.
That warning is probably outdated. I attached a diff of the linked-in
shared libraries in Debian's and the AppImage's /usr/bin/linphone
(4.2.5) to illustrate where else we deviate.
Another issue I ran into: during dh_auto_configure a CMake macro tries
to invoke "git describe" to look up the tag for the build's branch.
Setting GIT_EXECUTABLE to a shell script that emits the expected tag
worked around that. I used $(shell pwd) there to point to the script,
but I don't know if this is the right way to do it. Fix it if it's
wrong.
I'll keep digging into this and let you know if I learn something new.
Regards,
Dennis
diff --git a/linphone-4.4.21/debian/git.sh b/linphone-4.4.21/debian/git.sh
new file mode 100755
index 000..2d1c3ec
--- /dev/null
+++ b/linphone-4.4.21/debian/git.sh
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+#echo 4.4.12
+#f=$PWD/debian/git.sh
+f=$0
+g=${f%/debian/git.sh}
+h=${g##*/}
+i=${h##*-}
+#echo "$f $g $h"
+echo "$i"
diff --git a/linphone-4.4.21/debian/rules b/linphone-4.4.21/debian/rules
index 74476b0..9fa407f 100755
--- a/linphone-4.4.21/debian/rules
+++ b/linphone-4.4.21/debian/rules
@@ -2,6 +2,17 @@
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+# The macro bc_compute_lib_version (among others) from
+# /usr/share/bctoolbox/cmake/bctoolboxCMakeUtils.cmake expects the
+# .git directory to be available. We fool it with a shellscript
+# debian/git.sh that emits the version number hard-coded.
+CONFIGURE_ARGS += -DGIT_EXECUTABLE=$(shell pwd)/debian/git.sh
+
+# this enables the unified call+chat database; it requires sqlite3 and
+# a version of libsoci-dev built with C++11 support (libsoci-dev 4.0.1-3
+# doesn't have it yet).
+CONFIGURE_ARGS += -DENABLE_DB_STORAGE=YES
+
%:
dh $@ --buildsystem=cmake
@@ -14,7 +25,6 @@ override_dh_auto_configure:
-DENABLE_ADVANCED_IM=NO \
-DENABLE_LIME=NO \
-DENABLE_LIME_X3DH=NO \
- -DENABLE_DB_STORAGE=NO \
-DENABLE_UNIT_TESTS=NO \
-DENABLE_STATIC=NO \
$(CONFIGURE_ARGS)
--- ldd-bullseye-4.2.5.txt 2021-02-25 18:06:16.143870152 +0100
+++ ldd-appimage-4.2.5.txt 2021-02-25 18:06:16.139870152 +0100
@@ -1,158 +1,99 @@
/lib64/ld-linux-x86-64 (ADDR)
-libantlr3c-3.4
-libaom
libasound
libasyncns
libavcodec
libavutil
+libbcg729
libbctoolbox
libbelcard
libbellesip
libbelr
-libblkid
-libbrotlicommon
-libbrotlidec
libbsd
+libbv16
libbzrtp
libc
-libcairo
-libcairo-gobject
-libcodec2.9
-libcom_err
-libdatrie
-libdav1d
+libcap
libdbus-1
+libdecaf
libdl
-libdouble-conversion
-libdrm
-libexpat
-libffi
libFLAC
-libfontconfig
-libfreetype
-libfribidi
libgcc_s
libgcrypt
-libgdk_pixbuf-2.0
-libgio-2.0
libGL
libGLdispatch
-libGLEW.1
+libGLEW.0
libglib-2.0
libGLX
-libgmodule-2.0
-libgobject-2.0
-libgomp
libgpg-error
-libgraphite2
libgsm
-libgssapi_krb5
-libharfbuzz
+libgthread-2.0
+libICE
libicudata
libicui18n
libicuuc
-libk5crypto
-libkeyutils
-libkrb5
-libkrb5support
+libjpeg
+liblime
liblinphone
liblinphone++
liblz4
liblzma
libm
libmbedcrypto
libmbedtls
libmbedx509
-libmd
-libmd4c
libmediastreamer
-libmfx
-libmount
-libmp3lame
libnsl
-libnspr4
-libnss3
-libnssutil3
-libnuma
libogg
-libOpenCL
-libopenjp2
libopus
libortp
-libpango-1.0
-libpangocairo-1.0
-libpangoft2-1.0
libpcre
-libpcre2-16
-libpcre2-8
-libpixman-1
-libplc4
-libplds4
-libpng16
libpthread
libpulse
-libpulsecommon-14.1
+libpulsecommon-10.0
+libQt5Concurrent
libQt5Core
libQt5DBus
libQt5Gui
libQt5Network
libQt5Qml
-libQt5QmlModels
libQt5Quick
libQt5QuickControls2
libQt5QuickTemplates2
libQt5Svg
+libQt5TextToSpeech
libQt5Widgets
libresolv
-librsvg-2
librt
libselinux
-libshine
-libsnappy
+libSM
libsndfile
-libsoxr
+libsoci_core.0
+libsoci_sqlite3.0
libspeex
libspeexdsp
libsqlite3
libsrtp2
Bug#983446: redis: CVE-2021-21309
Hi Moritz, > given that this only affects 32 bit archs and only with an inherently insecure > setup (opening up the default bulk size to such high values might impact all > kinds of stability / availability I guess) I don't think this needs a DSA. > So s-p-u or piggybacking with the next DSA seems fine to me. Sure thing. I've filed this as #983527. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#983399: filter for portscans detected by scanlogd
Hello Could you please try to have it merged upstream ? thanks Cheers, S Le 23/02/2021 à 16:15, Mike Gabriel a écrit : Package: fail2ban Severity: whislist Tags: patch Hi, today I worked on a fail2ban filter rule that is able to filter out log lines from scanlogd. The scanlogd daemon is a port scan detector. This is my /etc/fail2ban/filter.d/scanlogd.conf file: ``` # Fail2Ban filter for port scans detected by scanlogd [Definition] failregex = scanlogd:\ \ to\ .*\ ports\ .* ignoreregex = # Author: Mike Gabriel ``` Hope, this is helpful. Mike
Bug#983529: Backport mailman3 for buster
Package: mailman3 Version: 3.2.1-1 What do you think about providing a backport of mailman3 3.3.3-1 for Buster? I'm about to setup mailman for a German organization that would like to have localized messages. But those are only available in 3.3.3. This would of course only make sense together with backports for hyperkitty and posterious. Python-Django does have backports for buster. Would you be OK if I'd upload backports? Do you think it is feasible? Thank you! Thomas
Bug#983528: reports false positives for missing -fPIE
Package: blhc Version: 0.12-2 Severity: normal Hi, for the aide package, blhc complains about missing CFLAGS (-fPIE), see https://buildd.debian.org/status/fetch.php?pkg=aide=amd64=0.17.3-1=1613025725=0 However, aide uses dpkg-buildflags correctly, it is just the case that dpkg-buildflags doesn't emit fPIE (any more?) since gcc (nowadays, to my knowlegde) defaults to -fPIE. Please let me know if I'm wrong with this diagnosis. Should dpkg-buildflags not emit -fPIE automatically? Greetings Marc -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.11.1-zgsrv20080 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages blhc depends on: ii libdpkg-perl 1.20.7.1 blhc recommends no packages. blhc suggests no packages. -- no debconf information
Bug#983527: buster-pu: package redis/5:5.0.3-4+deb10u3
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Dear stable release managers,
Please consider redis (5:5.0.3-4+deb10u3) for buster:
redis (5:5.0.3-4+deb10u3) buster; urgency=medium
.
* CVE-2021-21309: Fix a series of integer overflow issues on 32-bit systems.
(Closes: #983446)
The full diff is attached. I am submitting this as a potential s-p-u
due to a request from the Security Team:
https://bugs.debian.org/983446#27
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
diff --git a/debian/changelog b/debian/changelog
index eae2bf71..c184fefb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+redis (5:5.0.3-4+deb10u3) buster; urgency=medium
+
+ * CVE-2021-21309: Fix a series of integer overflow issues on 32-bit systems.
+(Closes: #983446)
+
+ -- Chris Lamb Thu, 25 Feb 2021 17:46:45 +
+
redis (5:5.0.3-4+deb10u2) buster-security; urgency=high
* Non-maintainer upload by the Security Team.
diff --git a/debian/patches/0015-CVE-2021-21309.patch
b/debian/patches/0015-CVE-2021-21309.patch
new file mode 100644
index ..14cb441c
--- /dev/null
+++ b/debian/patches/0015-CVE-2021-21309.patch
@@ -0,0 +1,139 @@
+From: Chris Lamb
+Date: Thu, 25 Feb 2021 17:44:59 +
+Subject: CVE-2021-21309
+
+---
+ src/config.c | 16
+ src/sds.c | 3 +++
+ src/zmalloc.c | 10 ++
+ 3 files changed, 21 insertions(+), 8 deletions(-)
+
+diff --git a/src/config.c b/src/config.c
+index 9f51bba..cb13818 100644
+--- a/src/config.c
b/src/config.c
+@@ -878,10 +878,10 @@ void loadServerConfig(char *filename, char *options) {
+ if (max != LLONG_MAX && ll > max) goto badfmt; \
+ _var = ll;
+
+-#define config_set_memory_field(_name,_var) \
++#define config_set_memory_field(_name,_var,min,max) \
+ } else if (!strcasecmp(c->argv[2]->ptr,_name)) { \
+ ll = memtoll(o->ptr,); \
+-if (err || ll < 0) goto badfmt; \
++if (err || ll < (long long) (min) || ll > (long long) (max)) goto
badfmt; \
+ _var = ll;
+
+ #define config_set_enum_field(_name,_var,_enumvar) \
+@@ -1147,7 +1147,7 @@ void configSetCommand(client *c) {
+ } config_set_numerical_field(
+
"active-defrag-threshold-upper",server.active_defrag_threshold_upper,0,1000) {
+ } config_set_memory_field(
+- "active-defrag-ignore-bytes",server.active_defrag_ignore_bytes) {
++
"active-defrag-ignore-bytes",server.active_defrag_ignore_bytes,0,LONG_MAX) {
+ } config_set_numerical_field(
+ "active-defrag-cycle-min",server.active_defrag_cycle_min,1,99) {
+ } config_set_numerical_field(
+@@ -1243,7 +1243,7 @@ void configSetCommand(client *c) {
+
+ /* Memory fields.
+ * config_set_memory_field(name,var) */
+-} config_set_memory_field("maxmemory",server.maxmemory) {
++} config_set_memory_field("maxmemory",server.maxmemory,0,LONG_MAX) {
+ if (server.maxmemory) {
+ if (server.maxmemory < zmalloc_used_memory()) {
+ serverLog(LL_WARNING,"WARNING: the new maxmemory value set
via CONFIG SET is smaller than the current memory usage. This will result in
key eviction and/or the inability to accept new write commands depending on the
maxmemory-policy.");
+@@ -1251,12 +1251,12 @@ void configSetCommand(client *c) {
+ freeMemoryIfNeededAndSafe();
+ }
+ } config_set_memory_field(
+- "proto-max-bulk-len",server.proto_max_bulk_len) {
++ "proto-max-bulk-len",server.proto_max_bulk_len,1024*1024,LONG_MAX/2) {
+ } config_set_memory_field(
+- "client-query-buffer-limit",server.client_max_querybuf_len) {
+-} config_set_memory_field("repl-backlog-size",ll) {
++ "client-query-buffer-limit",server.client_max_querybuf_len,0,LONG_MAX) {
++} config_set_memory_field("repl-backlog-size",ll,0,LONG_MAX) {
+ resizeReplicationBacklog(ll);
+-} config_set_memory_field("auto-aof-rewrite-min-size",ll) {
++} config_set_memory_field("auto-aof-rewrite-min-size",ll,0,LONG_MAX) {
+ server.aof_rewrite_min_size = ll;
+
+ /* Enumeration fields.
+diff --git a/src/sds.c b/src/sds.c
+index 330c955..25da92f 100644
+--- a/src/sds.c
b/src/sds.c
+@@ -96,6 +96,7 @@ sds sdsnewlen(const void *init, size_t initlen) {
+ int hdrlen = sdsHdrSize(type);
+ unsigned char *fp; /* flags pointer. */
+
++assert(hdrlen+initlen+1 > initlen); /* Catch size_t overflow */
+ sh = s_malloc(hdrlen+initlen+1);
+ if (init==SDS_NOINIT)
+ init = NULL;
+@@ -214,6 +215,7 @@ sds sdsMakeRoomFor(sds s, size_t addlen) {
+ len = sdslen(s);
+ sh = (char*)s-sdsHdrSize(oldtype);
+ newlen = (len+addlen);
++assert(newlen > len); /* Catch size_t overflow */
+ if (newlen < SDS_MAX_PREALLOC)
+ newlen *= 2;
+ else
+@@ -227,6 +229,7 @@ sds sdsMakeRoomFor(sds s, size_t addlen) {
Bug#982035: Please consider reverting (i.e. re-adding dependency)
Hello Paul, hello Holger, manpages-it comes back, just from a new source package (manpages-l10n). The reason this was delayed is that I cannot get this through NEW myself, as I'm only a Debian Maintainer, so I needed a sponsor (Toddy is currently unavailable). This has been resolved, so now manpages-it is on it's way through Testing. I received positive signals from the release team that it will be accepted. Currently manpages-l10n (and with it manpages-it) still hast to wait 5 more days, before it can enter testing. (So it is already in unstable) Please note, that manpages-l10n ships the following languages currently, so you might check tasksel if it follows suit: manpages-de manpages-es manpages-fr manpages-it manpages-mk manpages-nl manpages-pl manpages-bt-BR manpages-ro If you have any questions regaring the manpage translations, do not hesitate to ask (there are more langauges in the pipeline, but not for Bullseye) Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#893022: adequate doesn't find missing pkg-config dependencies
Control: reassign -1 piuparts-slave-from-git-deps On Mon, 14 May 2018 11:34:37 +0200 Jakub Wilk wrote: * Adrian Bunk , 2018-03-15, 21:22: >adequate already seems to try to check this, but for some reason it >doesn't find the libinput-dev problem. adequate checks these dependencies only if the pkg-config package is installed. libinput-dev currently depends on it transitively, but I think it didn't back when this bug was filed, and AFAICS piuparts doesn't install it on its own either. piuparts-slave-from-git-deps needs Depends: adequate pkg-config Andreas
