Bug#982520: RM: r-bioc-destiny [armel] -- ROM; The dependency r-cran-vim is not available on arm any more

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi,

I've read on r-cran-vim excuses[1]:

  removing r-cran-vim/6.0.0+dfsg-2/armel from testing makes 
r-bioc-destiny/3.4.0-1/armel uninstallable

Since it is important that r-cran-vim migrates to testing and its
sensible to assume that there are no practical use cases for this
software on armel anyway please remove r-bioc-destiny for armel
(on unstable and testing).

Kind regards and thanks for your work as ftpmaster

 Andreas.


[1] https://qa.debian.org/excuses.php?package=r-cran-vim

Bug#982483: Bug in r-base and r-cran-rcppparallel

[Andreas Tille]

Hi Kevin,

On Wed, Feb 10, 2021 at 11:20:38AM -0800, Kevin Ushey wrote:
> Perhaps I'm misunderstanding, but there is a Debian patch for RcppParallel 
> here:
> 
> https://sources.debian.org/patches/r-cran-rcppparallel/5.0.2+dfsg-3/use_debian_packaged_libtbb.patch/
> 
> and all that does is force RcppParallel to use the Debian-provided
> copy of TBB as opposed to the version normally bundled and installed
> by RcppParallel itself.
> 
> Is the implied bug in the RcppParallel patch, or in RcppParallel itself?

The bug is inside the patch you linked to.  However, the fix Bastian
suggested requires a fix in R itself.  Dirk kept you in the row whether
you might imagine some other solution that does not require a change in
R.

(I personally need to admit I need to trust you here since despite I'm
packaging lots of R packages for Debian my R knowledge is extremely
limited.)

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#982519: zstd: Race condition allows attacker to access world-readable destination file

[Sebastien Delafond]

Package: zstd
Version: 1.4.8+dfsg-1
Severity: grave
Tags: security
X-Debbugs-Cc: t...@security.debian.org

The recently applied patch still creates the file with the default
umask[0], before chmod'ing down to 0600, so an attacker could still open
it in the meantime.

Cheers,

-- 
Seb

[0] https://github.com/facebook/zstd/blob/dev/programs/fileio.c#L682

Bug#982518: sbuild: fails to build amp or spherepack: /dev/shm is unwriteable

[Johannes Schauer Marin Rodrigues]

Hi Julian,

Quoting Julian Gilbey (2021-02-11 08:20:45)
> When trying to build amp and spherepack on my Debian testing machine, I get a
> build failure, but I don't if I use pbuilder.  Johannes Schauer Marin
> Rodrigues has kindly identified the source of the problem, in
> https://lists.debian.org/debian-devel/2021/02/msg00167.html (my question) and
> https://lists.debian.org/debian-devel/2021/02/msg00168.html (Josch's
> analysis).

yes, that's me, the sbuild maintainer. :)

> It turns out that pbuilder sets up /dev/shm in the chroot environment
> to be a tmpfs but sbuild does not (or at least gets the permissions
> wrong): here's what I get when I test this:
> 
> On a regular build (using >> to indicate commands in debian/rules):
> >> mount | grep shm
> tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
> >> ls -ld /dev/shm
> drwxrwxrwt 2 root root 80 Feb 11 07:06 /dev/shm
> 
> On an sbuild though:
> >> mount | grep shm
> make: [debian/rules:7: clean] Error 1 (ignored)
> >> ls -ld /dev/shm
> drwxr-xr-x 2 root root 40 Feb 10 10:06 /dev/shm
> 
> So /dev/shm is a real directory rather than a tmpfs, and is only
> writable by root.
> 
> This can be fixed using Josch's workaround
> (--chroot-setup-commands="chmod 777 /dev/shm") but it would be better
> to have a more general solution.  There are two obvious fixes for
> this:
> 
> (1) Running "mount -t tmpfs tmpfs /dev/shm" or
> (2) Running "chmod 1777 /dev/shm"
> 
> at some point during the chroot setup.
> 
> The first is clearly more efficient.  However, the second is somewhat
> more sophisticated because of the different operating systems; see
> /usr/lib/pbuilder/pbuilder-modules for how they deal with it.

which chroot mode are you using? Are you using schroot? In that case, how does
this file look like on your system:

/etc/schroot/sbuild/fstab

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#982518: sbuild: fails to build amp or spherepack: /dev/shm is unwriteable

[Julian Gilbey]

Package: sbuild
Version: 0.81.2
Severity: normal

When trying to build amp and spherepack on my Debian testing machine,
I get a build failure, but I don't if I use pbuilder.  Johannes
Schauer Marin Rodrigues has kindly identified the source of the
problem, in
https://lists.debian.org/debian-devel/2021/02/msg00167.html (my
question) and
https://lists.debian.org/debian-devel/2021/02/msg00168.html
(Josch's analysis).

It turns out that pbuilder sets up /dev/shm in the chroot environment
to be a tmpfs but sbuild does not (or at least gets the permissions
wrong): here's what I get when I test this:

On a regular build (using >> to indicate commands in debian/rules):
>> mount | grep shm
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
>> ls -ld /dev/shm
drwxrwxrwt 2 root root 80 Feb 11 07:06 /dev/shm

On an sbuild though:
>> mount | grep shm
make: [debian/rules:7: clean] Error 1 (ignored)
>> ls -ld /dev/shm
drwxr-xr-x 2 root root 40 Feb 10 10:06 /dev/shm

So /dev/shm is a real directory rather than a tmpfs, and is only
writable by root.

This can be fixed using Josch's workaround
(--chroot-setup-commands="chmod 777 /dev/shm") but it would be better
to have a more general solution.  There are two obvious fixes for
this:

(1) Running "mount -t tmpfs tmpfs /dev/shm" or
(2) Running "chmod 1777 /dev/shm"

at some point during the chroot setup.

The first is clearly more efficient.  However, the second is somewhat
more sophisticated because of the different operating systems; see
/usr/lib/pbuilder/pbuilder-modules for how they deal with it.

Best wishes,

   Julian

Bug#982517: RM: mricron [mipsel] -- RoQA; new build-dep lcl-qt5 is not available for mipsel

[Juhani Numminen]

Package: ftp.debian.org
X-Debbugs-Cc: mric...@packages.debian.org

Dear FTP Masters,

Please remove existing mipsel binaries for mricron. The new version
can't be built on mipsel as src:lazarus does not make lcl-qt5 available
on that architecture.

Thanks!

--
Juhani

Bug#982516: mricron: FTBFS [arm64, mips64el]

[Juhani Numminen]

Source: mricron
Version: 1.0.20190902+dfsg-1
Tags: ftbfs
Severity: serious

Hello,

mricron FTBFS on arm64 and mips64el. The error messages look like this:

(9009) Assembling cutout
/<>/RenderThds.pas(79,44) Error: (3069) Call by var for arg no. 1 
has to match exactly: Got "LongWord" expected "TRTLCriticalSection"
/usr/lib/aarch64-linux-gnu/fpc/3.2.0/units/aarch64-linux/rtl/system.ppu:thread.inc(220,11)
 Hint: (5039) Found declaration: EnterCriticalSection(var TRTLCriticalSection);
/usr/lib/lazarus/2.0.10/lcl/units/aarch64-linux/lclintf.ppu:winapi.inc(243,11) 
Hint: (5039) Found declaration: EnterCriticalSection(var QWord);
/<>/RenderThds.pas(81,44) Error: (3069) Call by var for arg no. 1 
has to match exactly: Got "LongWord" expected "TRTLCriticalSection"
/usr/lib/aarch64-linux-gnu/fpc/3.2.0/units/aarch64-linux/rtl/system.ppu:thread.inc(232,11)
 Hint: (5039) Found declaration: LeaveCriticalSection(var TRTLCriticalSection);
/usr/lib/lazarus/2.0.10/lcl/units/aarch64-linux/lclintf.ppu:winapi.inc(664,11) 
Hint: (5039) Found declaration: LeaveCriticalSection(var QWord);
/<>/RenderThds.pas(545,37) Error: (3069) Call by var for arg no. 1 
has to match exactly: Got "LongWord" expected "QWord"
/usr/lib/lazarus/2.0.10/lcl/units/aarch64-linux/lclintf.ppu:winapi.inc(659,11) 
Hint: (5039) Found declaration: InitializeCriticalSection(var QWord);
/<>/RenderThds.pas(549,33) Error: (3069) Call by var for arg no. 1 
has to match exactly: Got "LongWord" expected "QWord"
/usr/lib/lazarus/2.0.10/lcl/units/aarch64-linux/lclintf.ppu:winapi.inc(168,11) 
Hint: (5039) Found declaration: DeleteCriticalSection(var QWord);
RenderThds.pas(551) Fatal: (10026) There were 4 errors compiling module, 
stopping
Fatal: (1018) Compilation aborted
Error: /usr/bin/ppca64 returned an error exitcode
Error: (lazarus) Compile Project, Mode: Default, Target: MRIcron: stopped with 
exit code 1
Error: (lazbuild) failed compiling of project /<>/mricron.lpi


I am wondering if the related ifdef should be some sort of generic 64-bitness
check instead of x86_64 specifically.
https://sources.debian.org/src/mricron/1.0.20190902+dfsg-1/RenderThds.pas/#L68

Regards,
Juhani

Bug#962485: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel

[Bastian Blank]

Moin

On Thu, Feb 11, 2021 at 10:15:02AM +0800, YunQiang Su wrote:
> > Could the mips porters comment on this? Given that we're close to the 
> > release
> > of bullseye, I'm not convinced it's a good idea to change this now.

This option is also a dependency of several types of CPU support.  So it
might not be feasable to disable.

> Yes. It will be a problem to run with buster's golang program on
> bullseys's kernel.
> Let's have another way to get this problem sloved without revert this changes.

Sure, by discontinuing support for go on mips for example.

> Maybe detect the golang applications and run them in FP32 mode?

The kernel already does.  But it seems go decided to set the FPXX marker
on it's objects.  See https://github.com/golang/go/issues/39435

Bastian

-- 
Captain's Log, star date 21:34.5...

Bug#982515: RM: apertium-swe -- ROM; Obsolete by new apertium language pairs

[Kartik Mistry]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: kar...@debian.org

Dear FTP Team,

Please remove apertium-swe from Unstable. It is no longer needed by
new apertium language pairs.

Thanks,
Kartik

Bug#982514: RM: apertium-srd -- ROM; Obsolete by new apertium language pairs

[Kartik Mistry]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: kar...@debian.org

Dear FTP Team,

Please remove apertium-srd from Unstable. It is no longer needed by
new apertium language pairs.

Thanks,
Kartik

Bug#982513: RM: apertium-rus -- ROM; Obsolete by new apertium language pairs

[Kartik Mistry]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: kar...@debian.org

Dear FTP Team,

Please remove apertium-rus from Unstable. It is no longer needed by
new apertium language pairs.

Thanks,
Kartik

Bug#982512: RM: apertium-pol -- ROM; Obsolete by new apertium language pairs

[Kartik Mistry]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: kar...@debian.org

Dear FTP Team,

Please remove apertium-pol from Unstable. It is no longer needed by
new apertium language pairs.

Thanks,
Kartik

Bug#982511: RM: apertium-oci -- ROM; Obsolete by new apertium language pairs

[Kartik Mistry]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: kar...@debian.org

Dear FTP Team,

Please remove apertium-oci from Unstable. It is no longer needed by
new apertium language pairs.

Thanks,
Kartik

Bug#982510: libfilezilla11: libgnutls30 v3.7.0-5 breaks libfilezilla11 but downgrade to v3.6.15-4 still works

[Etilem]

Package: libfilezilla11
Version: 0.26.0-1+b1
Severity: important
Tags: patch

Hello,

While using

  filezilla v3.52.2-3

and

  libgnutls30 v3.7.0-5

I was unable to make a PASV connection to a PureFTP server, but after
downgrading to

  libgnutls30 v3.6.15-4

everything worked.



-- System Information:
Distributor ID: Kali
Description:Kali GNU/Linux Rolling
Release:2020.4
Codename:   kali-rolling
Architecture: x86_64

Kernel: Linux 5.10.0-kali3-amd64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libfilezilla11 depends on:
ii  libc62.31-9
ii  libgcc-s110.2.1-6
ii  libgnutls30  3.7.0-5
ii  libhogweed6  3.6-2
ii  libnettle8   3.6-2
ii  libstdc++6   10.2.1-6

libfilezilla11 recommends no packages.

libfilezilla11 suggests no packages.

-- no debconf information

Bug#980642: [PATCH] diagnostics: FTBFS: configure: error: invalid ltdl library directory: '/usr/lib/x86_64-linux-gnu'

[Dennis Filder]

The first patch appears to have been mangled in transit (whitespace),
so disregard that.  The attached compressed patch should be integrous.


diagnostics_0.3.3-12-no-ltdl-convenience.patch.gz
Description: application/gzip

Bug#980607: [PATCH] netcfg: FTBFS: test/test_inet_mton.c:12:15: error: too many arguments for format [-Werror=format-extra-args]

[Dennis Filder]

On Wed, Feb 10, 2021 at 05:41:29PM +0100, Cyril Brulebois wrote:

> Patches fail to apply locally, and I'd rather avoid having to fix
> them up (possibly breaking things in the process).

Strange: When I download the patches from BTS somehow they have
mangled whitespace whereas my local patches don't.  No idea what
happened here.  Is that a known issue?  Regardless I attached the
patches anew compressed plus an md5sums file and verified that they
apply fine against current master HEAD
b897697d6f1d816b3420dac277bcd58da336da7e and preserve the whitespace
style of each changed line.

Regards,
Dennis.


netcfg_1.169-fix-CheckAPI.patch.gz
Description: application/gzip


netcfg_1.169-fix-strncpy.patch.gz
Description: application/gzip
5143239a2f25142ee06b02d4c70db735  netcfg_1.169-fix-CheckAPI.patch.gz
092ebedd836b8640f05d04ca9638e911  netcfg_1.169-fix-strncpy.patch.gz

Bug#982439: xterm: crash when selecting specially crafted UTF-8 character sequence

[Salvatore Bonaccorso]

Control: tags -1 + fixed-upstream

Hi,

On Wed, Feb 10, 2021 at 11:28:43AM +0100, Salvatore Bonaccorso wrote:
> Source: xterm
> Version: 365-1
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi
> 
> See https://www.openwall.com/lists/oss-security/2021/02/09/7 which was
> a followup to the screen issue.
> 
> Upstream said that there will be shortly a patch released (#366), cf.
> https://www.openwall.com/lists/oss-security/2021/02/09/9

This is now adressed:
https://invisible-island.net/xterm/xterm.log.html#xterm_366

Regards,
Salvatore

Bug#945317: xcftools NMU for CVE-2019-5086 and CVE-2019-5087

[Salvatore Bonaccorso]

Hi Markus,

On Thu, Feb 11, 2021 at 03:03:19AM +0100, Markus Koschany wrote:
> Hi Salvatore,
> 
> Am Mittwoch, den 10.02.2021, 22:03 +0100 schrieb Salvatore Bonaccorso:
> [...]
> > 
> > I'm not fully in favor to have all the (build-)rdeps forced out of
> > Debian, that would likely not be a benefit as seems unfair to the
> > castle-game-engine, game-data-packager and neurodebian packages, but
> > still think having out xcftools out of bullseye would be the right
> > thing.
> > 
> 
> I believe it makes sense to remove xcftools from Debian because there is a 
> lack
> of upstream support and development but I wouldn't be too aggressive about the
> removal at the moment. My intention is to send a patch to fix the open CVE in
> stable to you when we have addressed the remaining 32 bit issues.

Yes that sounds fine. Admittely it was for us in dsa-needed only
because Hugo initially aimed to adress it across all suites top-down.
It might just be an option to include a fix once it is stable enough
via a point release. But we can look at it once you have a fix as well
for the 32bit issues.

So thanks for working on it!

> I believe it
> would be possible to substitute xcftools with imagemagick but as Simon 
> McVittie
> for game-data-packager already pointed out, the result wouldn't always be the
> same. So a bug report like "Should this package be removed from Debian" with
> severity important should be sufficient for now and bug reports for reverse-
> decencies that highlight the current problems are a good start.

Yes so we have done this, but in double-checking with the release team
the severities are RC (with the clear indication that if it turns not
to be possible, that it can be revisited).

I have seen Simon's reply, so the imagemagick convert variant does not
look the same in in the game-data-packager case actually worse.

It is late in the preparation for bullseye and we should have done
this actually much earlier. So we will see if it is feasible or not
and then have a desirable state or "bite the bullet".

Regards,
Salvatore

Bug#982502: game-data-packager: Build-Depends on xcftools wich should not be released with bullseye

[Salvatore Bonaccorso]

Hi Simon

You are fast! :)

On Thu, Feb 11, 2021 at 12:38:22AM +, Simon McVittie wrote:
> On Wed, 10 Feb 2021 at 22:47:35 +0100, Salvatore Bonaccorso wrote:
> > game-data-packager uild-Depends on xcftools which ideally should not
> > be released with bullseye. As it looks xcftools is used for calling
> > xcf2png. In the makefile there is already even the casing to fall back
> > to convert from imagemagick if xcf2png is not present. So could you
> > please investigate if it is possible to switch away from xcftools for
> > this conversions.
> 
> The version converted with imagemagick looks pretty horrible, particularly
> for Team Arena (I suspect it's getting layer modes wrong), so I'd really
> prefer not to rely on that. I think we have to either continue to use
> xcftools, or include pregenerated PNG versions in the source package
> and re-export them with gimp if they ever get modified.

Although we are late in the release process admitelly, from our
persective it would be desirabel to get xcftools removed with
bullseye. So if you think your later option might be okay enough then
I would have suggested to go this way instead. Is this okayish to just
include the pregenerated PNG versions then?

As I want to mention explcitly: if it turns out to be infeasible at
this point we simply will be biting the bullet, but this was the
reason the severity is initially RC and acked by release team twith
the clear indication that we can revisit it it turns out to not be
possible.

Thank you Simon for all your involvement!

Salvatore

Bug#982464: subversion: CVE-2020-17525: Remote unauthenticated denial-of-service in Subversion mod_authz_svn

[Salvatore Bonaccorso]

Hi James,

On Wed, Feb 10, 2021 at 08:49:39PM -0500, James McCoy wrote:
> On Wed, Feb 10, 2021 at 09:21:54PM +0100, Salvatore Bonaccorso wrote:
> > Hi James,
> > 
> > On Wed, Feb 10, 2021 at 03:20:22PM -0500, James McCoy wrote:
> > > On Wed, Feb 10, 2021 at 03:36:11PM +0100, Salvatore Bonaccorso wrote:
> > > > The following vulnerability was published for subversion.
> > > > 
> > > > CVE-2020-17525[0]:
> > > > | Remote unauthenticated denial-of-service in Subversion mod_authz_svn
> > > 
> > > I'll have uploads ready for this tonight to both sid and buster.  I'll
> > > send the debdiff for review before uploading to buster-security.
> > 
> > Ack, thank you!
> 
> Buster debdiff attached.

Looks good to me. Did you got an explicit chance to test the issue
triggering setup? In any case please feel free to upload to
security-master.

Regards,
Salvatore

Bug#982509: ITP: flask-basicauth -- HTTP basic access authentication for Flask

[Sandro Tosi]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org
X-Debbugs-Cc: debian-pyt...@lists.debian.org
Owner: Sandro Tosi 

* Package name: flask-basicauth
  Version : 0.2.0
  Upstream Author : Janne Vanhala 
* URL : https://github.com/jpvanhal/flask-basicauth
* License : BSD
  Programming Lang: Python
  Description : HTTP basic access authentication for Flask

Binary package names: python3-flask-basicauth

 Flask-BasicAuth is a Flask extension that provides an easy way to protect
 certain views or your whole application with HTTP `basic access
 authentication`_.


this is a dependency of locust

Bug#981804: [Pkg-auth-maintainers] Bug#981804: yubioath-desktop: fails to read yubikey

[Jason Hernandez]

Hi Taowa,

Thank you! I tested using the last six digits in the UI and that was
accepted by a login provider (Github). Hopefully upstream fixes this issue
quickly.
Let me know if you want me to file a separate bug. I think the severity is
reduced with this workaround.

Best regards,
Jason Hernandez (he/him)


On Wed, Feb 10, 2021 at 10:37 AM Taowa  wrote:

> Hello,
>
> Jason Hernandez, 2021-02-10 10:03 -0500:
> > I believe the fix for this bug may be incomplete.
> > This version is generating 9-10 digit codes instead of the standard 6
> digit
> > codes on my machine when using the CCID interface with a Yubikey NEO.
> These
> > 9-10 digit codes fail verification and make the package unusable.
>
> See the upstream bug at [1]. They're aware of the issue and working on a
> fix for it :).
>
> In the meantime, the report seems to suggest that the last six digits of
> the TOTP code generated are valid. If you have a moment, please try it
> and get back to me as to whether that's true.
>
> Thanks,
> Taowa
>
>
> [1] https://github.com/Yubico/yubioath-desktop/issues/693
>
> --
> Taowa (they)
> LOC FN35EM
>

Bug#982508: ITP: locust -- Developer friendly load testing framework

[Sandro Tosi]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org
X-Debbugs-Cc: debian-pyt...@lists.debian.org
Owner: Sandro Tosi 

* Package name: locust
  Version : 1.4.3
  Upstream Author : Carl Byström, Jonatan Heyman
* URL : https://locust.io/
* License : MIT
  Programming Lang: Python
  Description : Developer friendly load testing framework

Binary package names: python3-locust

 Locust is an easy to use, scriptable and scalable performance testing tool. You
 define the behaviour of your users in regular Python code, instead of using a
 clunky UI or domain specific language. This makes Locust infinitely expandable
 and very developer friendly.
 .
 Features:
 .
  * Write user test scenarios in plain-old Python -- If you want your users to
loop, perform some conditional behaviour or do some calculations, you just
use the regular programming constructs provided by Python. Locust runs every
user inside its own greenlet (a lightweight process/coroutine). This enables
you to write your tests like normal (blocking) Python code instead of having
to use callbacks or some other mechanism. Because your scenarios are “just
python” you can use your regular IDE, and version control your tests as
regular code (as opposed to some other tools that use XML or binary
formats).
  * Distributed & Scalable - supports hundreds of thousands of users -- Locust
makes it easy to run load tests distributed over multiple machines. It is
event-based (using gevent), which makes it possible for a single process to
handle many thousands concurrent users. While there may be other tools that
are capable of doing more requests per second on a given hardware, the low
overhead of each Locust user makes it very suitable for testing highly
concurrent workloads.
  * Web-based UI -- Locust has a user friendly web interface that shows the
progress of your test in real-time. You can even change the load while the
test is running. It can also be run without the UI, making it easy to use
for CI/CD testing.
  * Can test any system -- Even though Locust primarily works with web
sites/services, it can be used to test almost any system or protocol. Just
write a client for what you want to test, or explore some created by the
community.

Bug#981070: e2fsprogs: (Possibly) e2fsck sometimes enables ext4 features on ext2 filesystems?

[Christoph Biedl]

[ Sorry for not getting back to your earlier ]

Theodore Ts'o wrote...

> What could have happened on your file system?  Well, there are two
> scenarios that could explain what had happened:

After some more desastrous experiences (kernel stack traces and
segfaults) I assume serious hardware issues. All this happened only if
there was either a PCI card plugged in (ethernet, USB controller, SATA
controller) or a external drive via firewire. Either is mainboard has a
flaw, or the PCI/DMA(?) support in the kernel went out of shape without
people noticing. That machine is from 2003-ish and that type isn't much
in use any longer. For example, networking in newer kernels has issues
under a specific load, which is why I'm still stuck on 4.19. Should
bisect that some day.

Anyway, it's easy to assume the data in a write request to the block
device was garbled, and things went downhill from there.

> 1) Somehow the inode was corrupted to (a) both set the inline data
> flag, and (b) a valid extended attribute that had "system.data" (which
> can't be set via the userspace API; it would have had to been
> magically, random set).   Highly unlikely.
> 
> 2) There was a random bit flip that enabled the inline_data feature
> flag in the superblock.  The other fscrypt kernel message would
> be explained another random bit flip and/or random garbage written
> into an inode table block.

Makes a lot of sense, then.

> 3) An admin accidentally ran "tune2fs -O inline_data /dev/sdXX" to
> enable the inline_data feature.  The fscrypt message could be
> explained as above.

Not in this case, I'm the only person who has access.

> In any case, e2fsck is doing the right thing.  It *is* possible for
> e2fsck to set the inline_data feature flag, yes. but it's under
> very tightly constrained circumstances, and the alternative would be
> to have e2fsck to delete user data that could potentially be quite
> valuable.  (For example, a cryptographic key which protects a bitcoin
> wallet with $220 million dollars worth of bitcoin in it.  :-P )

In theory, e2fsck could emit a warning "That filesystem is ext2, the
change I'd like to perform next would require ext4 support". But that
would possibly get lost among all the other warnings or/or the bugged
admin already hit "Yes to all questions" (I did) and it goes unnoticed
as well. It might be possible to handle such a situation but honestly
it's not happening often enough that it's worth you spend a lot of time
on it. Old lesson learned again: If a fsck reports more than just a few
glitches, it might be wiser to clean the filesystem entirely and restore
the data from the backup.

> Could this happen when it shouldn't?  Well, it would highly unlikely
> --- as in one in bazillions odds unlucky.  It's actually much more
> likely that a random bitflip in the in-memory superblock toggled the
> inline_data feature bit set.

Yeah, I guess we can as well close this bug. thanks a lot for your time
and the explanations given.

Christoph


signature.asc
Description: PGP signature

Bug#982505: zfsutils-linux: trim cronjob triggers "cannot trim" e-mails on spinning rust

[Christoph Biedl]

Package: zfsutils-linux
Version: 2.0.1-3
Severity: normal

Dear Maintainer,

on a host where the ZFS installation is based on harddisks, the
/usr/lib/zfs-linux/trim cronjob triggers e-mails with the body

| cannot trim: no devices in pool support trim operations

The reason for this is fairly obvious. Still these messages create
nothing but noise.

Please find a solution for this - preferably by checking beforehand
whether trimming is possible. Or if all else fails, by muting stderr
from the "zpool trim" command. Although that might hide serious errors
as well.

Regards,

Christoph

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

Kernel: Linux 5.10.14 (SMP w/4 CPU threads)
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)

Versions of packages zfsutils-linux depends on:
ii  init-system-helpers  1.60
ii  libblkid12.36.1-6
ii  libc62.31-9
pn  libnvpair3linux  
ii  libuuid1 2.36.1-6
pn  libuutil3linux   
pn  libzfs4linux 
pn  libzpool4linux   
ii  python3  3.9.1-1

Versions of packages zfsutils-linux recommends:
ii  lsb-base11.1.0
pn  zfs-modules | zfs-dkms  
pn  zfs-zed 

Versions of packages zfsutils-linux suggests:
pn  nfs-kernel-server   
pn  samba-common-bin
pn  zfs-initramfs | zfs-dracut  



signature.asc
Description: PGP signature

Bug#982507: lxc-net/dnsmasq-base shouldn't be required

[Matt Corallo]

Package: lxc
Version: 1:4.0.6-1

I've been happily using lxc on debian for some time, without dnsmasq-base or lxc-net. The recent addition of 
dnsmasq-base and lxc-net as a required dependency is somewhat surprising, given lxc-net edits IP address information for 
lxc-attched bridges which were created outside of lxc-net, and dnsmasq doubly so given DSA 4844-1 was only a few days 
ago. Several commentors on IRC seemed equally surprised by this change.


Is there more information available for why lxc-net is now an explicit dependency and not optional or can this change be 
reverted?


Thanks for all the work keeping lxc working!
Matt

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

[Antoine Le Gonidec]

After a couple days of regular Web browsing on two different computers running 
Debian Sid, the silent add-on disabling did not happen again.
I marked this bug as fixed in version 85.0.1-1 since no one reported otherwise, 
but feel free to chime in if you actually still get this issue with 85.0.1-1 
(or newer).



OpenPGP_signature
Description: OpenPGP digital signature

Bug#962485: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel

[YunQiang Su]

Ivo De Decker  于2021年2月9日周二 下午9:45写道：
>
> Hi,
>
> On Mon, Jun 08, 2020 at 08:15:38PM +0300, Adrian Bunk wrote:
> > On Fri, May 29, 2020 at 11:03:14PM +0200, Aurelien Jarno wrote:
> > > On 2020-05-28 09:04, YunQiang Su wrote:
> > > > Adrian Bunk  于2020年5月21日周四 下午3:40写道：
> > > > > On Thu, May 21, 2020 at 06:41:34AM +0800, YunQiang Su wrote:
> > > > > > Adrian Bunk  于2020年5月21日周四 上午4:44写道：
> > > > > > > On Tue, May 19, 2020 at 11:43:30AM +0800, Shengjing Zhu wrote:
> > > > > > > >
> > > > > > > > FTR, after giving back golang-1.14 mipsel several times, it's 
> > > > > > > > finally
> > > > > > > > built, by a longson builder.
> > > > > > > > So I guess it only occurs on octeon. Since the porterbox eller 
> > > > > > > > is also
> > > > > > > > octeon, it also can't build any go program.
> > > > > > >
> > > > > > > On eller golang-1.14 fails to build both in sid and buster 
> > > > > > > chroots.
> > > > > > >
> > > > > > > golang-1.11 also fails to build in a buster chroot with floating 
> > > > > > > point
> > > > > > > test errors.
> > > > > > >
> > > > > > > golang-1.14 gets unbroken by GOMIPS=softfloat.
> > > > > > >
> > > > > > > The only kernel configuration change on eller in the buster point
> > > > > > > release is CONFIG_MIPS_O32_FP64_SUPPORT=y, everything observed 
> > > > > > > would
> > > > > > > make sense if the problem is that golang-1.11 and golang-1.14 are
> > > > > > > not compatible with CONFIG_MIPS_O32_FP64_SUPPORT.
> > > > > >
> > > > > > It is just support O32_FP64. I don't expect it will have any effect.
> > > > > > Since currently, the toolchain/libraries are all FPXX.
> > > > >
> > > > > Only the gcc/binutils toolchain/libraries or also the Go toolchain?
> > > >
> > > > you are right. the current golang still output FP32 object...
> > > > So, we think that it is buggy.
> > > >
> > > > Since Loongson CPU has some strange behaviour, it even can work...
> > > > Let's try to patch golang to support FPXX or FP64.
> > > >
> > > > https://github.com/golang/go/issues/39289
> > >
> > > That's probably a solution for bullseye/sid, however we can't backport
> > > such changes and rebuild the go world in buster. I therefore think that
> > > for buster the kernel change has to be reverted.
> >
> > What is clear at this point is that the kernel change should be reverted
> > in buster since it causes a regression (including build failures on
> > buildds). I am cloning this bug for a revert in the kernel of
> > https://salsa.debian.org/kernel-team/linux/-/commit/947fbc66183d022fe3de7871dfb262d2b87af826
> >
> > I am marking the version in bullseye as found since we might run into
> > the same problem again when buster DSAs will be built on machines
> > running the bullseye kernel after the release of bullseye. It might be
> > possible to mitigate this problem (e.g. in the kernel or by keeping some
> > buildd running with the buster kernel), but without an open bug this
> > issue might get forgotten and then resurface after the bullseye release.
>
> Could the mips porters comment on this? Given that we're close to the release
> of bullseye, I'm not convinced it's a good idea to change this now.

Yes. It will be a problem to run with buster's golang program on
bullseys's kernel.
Let's have another way to get this problem sloved without revert this changes.

Maybe detect the golang applications and run them in FP32 mode?

>
> Cheers,
>
> Ivo
>
>

Bug#982506: RM: chaksem -- ROM; Source unavailable upstream, function obsoleted by alternatives

[Jamie Wilkinson]

Package: ftp.debian.org
Severity: normal

Dear colleagues,

`chaksem' is no longer available from the location mentioned in it's copyright 
file.  The source only exists now in Debian (archives, salsa) AFAIK.

I personally have no use for a LaTeX slide deck class, and there are many like 
it in the wild, presumably at least with source code available.

With a popcon rating of 42, I don't think anyone will miss it.

Thanks in advance.

Bug#945317: xcftools NMU for CVE-2019-5086 and CVE-2019-5087

[Markus Koschany]

Hi Salvatore,

Am Mittwoch, den 10.02.2021, 22:03 +0100 schrieb Salvatore Bonaccorso:
[...]
> 
> I'm not fully in favor to have all the (build-)rdeps forced out of
> Debian, that would likely not be a benefit as seems unfair to the
> castle-game-engine, game-data-packager and neurodebian packages, but
> still think having out xcftools out of bullseye would be the right
> thing.
> 

I believe it makes sense to remove xcftools from Debian because there is a lack
of upstream support and development but I wouldn't be too aggressive about the
removal at the moment. My intention is to send a patch to fix the open CVE in
stable to you when we have addressed the remaining 32 bit issues. I believe it
would be possible to substitute xcftools with imagemagick but as Simon McVittie
for game-data-packager already pointed out, the result wouldn't always be the
same. So a bug report like "Should this package be removed from Debian" with
severity important should be sufficient for now and bug reports for reverse-
decencies that highlight the current problems are a good start.

Cheers,

Markus


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

Bug#982464: subversion: CVE-2020-17525: Remote unauthenticated denial-of-service in Subversion mod_authz_svn

[James McCoy]

On Wed, Feb 10, 2021 at 09:21:54PM +0100, Salvatore Bonaccorso wrote:
> Hi James,
> 
> On Wed, Feb 10, 2021 at 03:20:22PM -0500, James McCoy wrote:
> > On Wed, Feb 10, 2021 at 03:36:11PM +0100, Salvatore Bonaccorso wrote:
> > > The following vulnerability was published for subversion.
> > > 
> > > CVE-2020-17525[0]:
> > > | Remote unauthenticated denial-of-service in Subversion mod_authz_svn
> > 
> > I'll have uploads ready for this tonight to both sid and buster.  I'll
> > send the debdiff for review before uploading to buster-security.
> 
> Ack, thank you!

Buster debdiff attached.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB
diffstat for subversion-1.10.4 subversion-1.10.4

 changelog   |8 
+++
 gbp.conf|2 
 patches/0017-Fix-a-potential-NULL-dereference-in-the-config-file-.patch |   26 
++
 patches/series  |1 
 4 files changed, 36 insertions(+), 1 deletion(-)

diff -Nru subversion-1.10.4/debian/changelog subversion-1.10.4/debian/changelog
--- subversion-1.10.4/debian/changelog  2019-07-27 22:44:06.0 -0400
+++ subversion-1.10.4/debian/changelog  2021-02-10 15:15:45.0 -0500
@@ -1,3 +1,11 @@
+subversion (1.10.4-1+deb10u2) buster-security; urgency=high
+
+  * Backport security fixes from upstream:
++ CVE-2020-17525: Remote unauthenticated denial-of-service in Subversion
+  mod_authz_svn  (Closes: #982464)
+
+ -- James McCoy   Wed, 10 Feb 2021 15:15:45 -0500
+
 subversion (1.10.4-1+deb10u1) buster-security; urgency=high
 
   * Backport security fixes from upstream:
diff -Nru subversion-1.10.4/debian/gbp.conf subversion-1.10.4/debian/gbp.conf
--- subversion-1.10.4/debian/gbp.conf   2019-07-27 22:44:06.0 -0400
+++ subversion-1.10.4/debian/gbp.conf   2021-02-10 15:15:45.0 -0500
@@ -1,6 +1,6 @@
 [DEFAULT]
 upstream-branch = upstream/1.10.x
-debian-branch = debian/sid
+debian-branch = debian/buster
 upstream-tag = upstream/%(version)s
 
 sign-tags = True
diff -Nru 
subversion-1.10.4/debian/patches/0017-Fix-a-potential-NULL-dereference-in-the-config-file-.patch
 
subversion-1.10.4/debian/patches/0017-Fix-a-potential-NULL-dereference-in-the-config-file-.patch
--- 
subversion-1.10.4/debian/patches/0017-Fix-a-potential-NULL-dereference-in-the-config-file-.patch
1969-12-31 19:00:00.0 -0500
+++ 
subversion-1.10.4/debian/patches/0017-Fix-a-potential-NULL-dereference-in-the-config-file-.patch
2021-02-10 15:15:45.0 -0500
@@ -0,0 +1,26 @@
+From: Stefan Sperling 
+Date: Fri, 29 Jan 2021 13:17:15 +
+Subject: Fix a potential NULL dereference in the config file parser.
+
+* subversion/libsvn_repos/config_file.c
+  (get_repos_config): svn_repos_find_root_path() may return NULL.
+   Check the return value accordingly.
+---
+ subversion/libsvn_repos/config_file.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/subversion/libsvn_repos/config_file.c 
b/subversion/libsvn_repos/config_file.c
+index 9187277..2414db9 100644
+--- a/subversion/libsvn_repos/config_file.c
 b/subversion/libsvn_repos/config_file.c
+@@ -237,6 +237,10 @@ get_repos_config(svn_stream_t **stream,
+ {
+   /* Search for a repository in the full path. */
+   repos_root_dirent = svn_repos_find_root_path(dirent, scratch_pool);
++  if (repos_root_dirent == NULL)
++return svn_error_trace(handle_missing_file(stream, checksum, access,
++   url, must_exist,
++   svn_node_none));
+ 
+   /* Attempt to open a repository at repos_root_dirent. */
+   SVN_ERR(svn_repos_open3(>repos, repos_root_dirent, NULL,
diff -Nru subversion-1.10.4/debian/patches/series 
subversion-1.10.4/debian/patches/series
--- subversion-1.10.4/debian/patches/series 2019-07-27 22:44:06.0 
-0400
+++ subversion-1.10.4/debian/patches/series 2021-02-10 15:15:45.0 
-0500
@@ -14,3 +14,4 @@
 0014-Provide-a-way-for-svnserve-s-get-deleted-rev-API-to-.patch
 0015-Adjust-expectations-of-a-new-test-to-account-for-dif.patch
 0016-In-svnserve-consistently-handle-errors-in-opening-a-.patch
+0017-Fix-a-potential-NULL-dereference-in-the-config-file-.patch

Bug#982435: [screen-devel] [bug #60030] Screen segfaults by displaying some UTF-8 character combination

[Axel Beckert]

Hi Tavis,

thanks for having a look into this!

Tavis Ormandy wrote:
> On 2021-02-10, Axel Beckert wrote:
> > +  else if (i < sizeof combchars / sizeof *combchars) {
> 
> This doesn't seem right, I think it should be compared against the
> calloc param at the top of utf8_handle_comb(),

Good point, thanks!

Your patch works fine on a first glance. No side effects like these
"ÿ " I saw with Michael's proposed patch. (But Michael's patch also
seems to care more about these 0x800 ff. values, so his and your patch
probably go into the right direction while my fix was rather generic
and perhaps too local.)

> but I don't really understand enough about unicode to know where
> that 0x802 comes from!

Will have a closer look into that direction tomorrow. But it indeed
sounds saner than my patch. And it is also much shorter and less
intrusive as it doesn't need to indent a whole block.

> I think for sure this code doesn't handle c > 0x801,

Which would mean it just can handle Unicode characters which are
represented by two bytes in UTF-8 representation. Because
that's what's special about characters around that value:

U+07FF NKO TAMAN SIGNis 0xDF 0xBF  in UTF-8.
U+0800 SAMARITAN LETTER ALAF is 0xE0 0xA0 0x80 in UTF-8.

(according to gucharmap)

This also explains why we see c1 and c2 in the code (and what they
mean) but e.g. no c3. It suddenly all starts to make more sense, yes.

BTW, credit for the right hint goes to
https://stackoverflow.com/questions/47783583/generating-3-byte-0x800-to-0x-utf-8-encodings-in-java

> so maybe that's an acceptable fix?

I probably haven't looked around far enough for my patch, yes. Just
looked at where the backtrace of the crash pointed me (same if-clause
as you pointed out on oss-sec) and tried to guard that one very
generically.

P.S.: A disclaimer for those who aren't aware of it: I'm not a GNU
Screen developer. I'm just Debian's screen package maintainer trying
fix that package in time for Debian's next stable release. So I can't
break GNU Screen, just Debian's package of it. ;-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Bug#982498: RM: geant321 -- development stopped, package abandoned

[Stephan Lachnit]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: stephanlach...@protonmail.com

Last upload was in 2013. Upstream is dead (website doesn't even exit anymore).

This applies to the entire old cernlib stack:
geant321, cernlib, paw

Regards,
Stephan

Bug#982417: Python louvain packages naming confusion.

[Diane Trout]

On Wed, 2021-02-10 at 18:35 -0500, Sandro Tosi wrote:
> +Steffen explicitly, given the team is not in Maintainer nor
> Uploaders
> 
> > How about renaming the current python3-louvain package to
> > python3-community-louvain using a normal transition package.
> 
> that's incorrect: src:python-louvain builds a module called
> `community` (that includes also a cli tool), so the resulting binary
> package should either be `python3-community` or `community` where the
> cli is the main product and the module is installed in /usr/share/ to
> support it.
> 

It is bending policy, but I liked python3-community-louvain because the
package name "python3-community" is just an exceptionally vague name. I
think it's clearer if the name of the algorithm is in the package name.

Also while looking through scanpy's louvain function I learned of yet
more implementations of louvain. (Look through this function for
different "flavors")
https://github.com/theislab/scanpy/blob/550b82fdb53f35890e60343b826dd19454600bdb/scanpy/tools/_louvain.py#L23

Apparently what I'd previously called "igraph", scanpy calls "vtraag"
because the vtraag version builds on the louvain implementation
in python-igraph.

There's also yet another version in nvidia's rapids library.

> > Then I can submit the other louvain package using a binary package
> > name
> > of python3-louvain-igraph.
> 
> this is incorrect too: (perspective) src:louvain (or
> src:louvain-igraph, as the upstream called their repo) builds a
> module
> called `louvain` so the resulting binary package should be
> `python3-louvain` eventually conflicting with the existing package
> (<<
> current-version-in-sid)
> 
> src:python-louvain is in a pretty bad shape: it received a single
> upload in late 2018, it has an RC bug since a *day* after that
> upload,
> and it has never been in testing: tbh i dont consider this package to
> be maintained/targeting any stable release, so i believe you can
> "take
> over" the namespace given you seem to show interest in maintaining
> https://github.com/vtraag/louvain-igraph

I wasn't sure how much effort to put into saving the previous Debian
louvain package since it didn't look like it was really usable by
anyone.

Libraries.io makes it look like the python-louvain "import community"
version is a bit more popular and more actively developed. The "vtraag"
version has a comment in it's REAME saying the developer deprecated it
in favor of leidenalg (an improved method).

On the other hand scanpy thinks the vtraag version is the most feature
full implementation of louvain and uses it as their default.

Diane

Bug#982502: game-data-packager: Build-Depends on xcftools wich should not be released with bullseye

[Simon McVittie]

On Wed, 10 Feb 2021 at 22:47:35 +0100, Salvatore Bonaccorso wrote:
> game-data-packager uild-Depends on xcftools which ideally should not
> be released with bullseye. As it looks xcftools is used for calling
> xcf2png. In the makefile there is already even the casing to fall back
> to convert from imagemagick if xcf2png is not present. So could you
> please investigate if it is possible to switch away from xcftools for
> this conversions.

The version converted with imagemagick looks pretty horrible, particularly
for Team Arena (I suspect it's getting layer modes wrong), so I'd really
prefer not to rely on that. I think we have to either continue to use
xcftools, or include pregenerated PNG versions in the source package
and re-export them with gimp if they ever get modified.

smcv

Bug#937102: mysql-workbench: Python2 removal in sid/bullseye

[Dmitry Smirnov]

On Wednesday, 10 February 2021 6:47:24 PM AEDT Adrian Bunk wrote:
> Yes, I think this is just a bug in libantlr4-runtime-dev with a simple
> fix to its headers.

Perhaps it is simple for you but I don't understand how to address the
problem...


> Errors regarding MYSQL_TYPE_INVALID being undefined were the next ones I
> got, I assume you know these kind of issues better.

I wish I knew better but I don't... Upstream builds against MySQL and
MariaDB is not supported. We always have to improvise to build M-W
against MariaDB...

-- 
All the best,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

The end cannot justify the means for the simple and obvious reason that the
means employed determine the nature of the ends produced.
-- Aldous Huxley

---

Masks are neither effective nor safe: A summary of the science.
-- https://www.primarydoctor.org/masks-not-effect


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

Bug#982283: override: bsdmainutils:oldlibs/optional

[Samuel Thibault]

Sean Whitton, le mer. 10 févr. 2021 16:44:30 -0700, a ecrit:
> On Thu 11 Feb 2021 at 12:21AM +01, Samuel Thibault wrote:
> > Sean Whitton, le lun. 08 févr. 2021 11:10:43 -0700, a ecrit:
> >> On Mon 08 Feb 2021 at 10:19AM +01, Chris Hofstaedtler wrote:
> >> >
> >> > bsdmainutils has become a transitional package in bullseye. It would be
> >> > great if we don't install it by default - right now its Priority:
> >> > important.
> >>
> >> I'm happy to go right ahead and lower the priority of the package that's
> >> only transitional, as it having a higher priority is not achieving
> >> anything at all.
> >
> > Yes, please.
> 
> Done.

Thanks!

> >> It seems appropriate to start a discussion on -devel about not
> >> installing those various utils by default by not raising the priority of
> >> the package they're not in, however?
> >
> > With the three "not" I didn't understand which way you wanted to mean
> > something.
> 
> Heh, sorry.  It seems appropriate to start a discussion on -devel to see
> if anyone thinks it's a problem for us to stop shipping those various
> utils in the base install, which would be achieved by raising the
> priority of the package which now contains them, in addition to lowering
> the priority of this one.

Ok now I understand, thanks :)

As I mentioned previously in the bug, bsdutils (required) recommends
bsdextrautils, so for that part things don't change.

For calendar and cal/ncal, the question indeed holds. For bsdmainutils
maintainers: I guess the goal of splitting them out of bsdmainutils was
precisely to not install them by default?

Samuel

Bug#982348: Bug#981804: yubioath-desktop: fails to read yubikey

[Norbert Preining]

Hi Nicoo,

> Being an alpha version is not a bug.  This was coordinated with upstream,
> who is working to ensure there's a final 4.0 release soon.

You might want to talk with release managers about this, not upstream.

> Yes, there is a UI bug in yubioath-desktop now (extraneous data getting
> displayed), which is getting fixed as we speak.

Git commit released

I tried to use your git repo, it is a mess, complete mess:
- the orig tar ball has no top level directory if you unpack it manually
- you cannot do apt-get source  followed by dpkg-buildpackage -us -uc
  -rfakeroot, since source building fails
  You override the auto_clean target and link setup.py from debian/ to .
  That works only once, and the change cannot be represented in the
  source building
  The only way to build such a package is using dpkg-source -b .

You might look into proper packaging practices ...

> Exactly as is currently going on: fixing the one remaining bug.
> Throwing tantrums and opening spurious Severity: serious bugs is only making a
> larger mess.

Again, I don't play ping-pong with severities, but this change has
broken other software in a serious way. You interpretation may vary,
anyway.

> Moving to fido2 0.9 and ykman 4.0a1 was a deliberate move: I discussed with
> upstream and they moved up their release schedule in order to accomodate the
> Debian bullseye release.

Again, you should talk to release managers about this, not upstream.

I could have packaged Plasma 5.20.90 for bullseye ... that is beta and
not alpha ... and still I not even upload it to experimental.

> I'm aware the timing isn't ideal, but it's the best that could be done.

For what? What is the gain?

Anyway, I have fixed it in my personal repo and uploaded fixed ykman
packages to my personal repo.

For me personally I don't care, I can fix these things myself. But I
just hope that bullseye users won't be left out.

Enjoy

Norbert

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

Bug#976462: Bug#631985: Compress debug

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

Sean> Hello,
Sean> So, just to confirm, you're saying that you think that you or
Sean> people you know would end up doing the latter pretty regularly
Sean> if we were to decide to turn off compression?

I know for larger packages I'd be likely to do that.

Bug#982417: Python louvain packages naming confusion.

[Sandro Tosi]

+Steffen explicitly, given the team is not in Maintainer nor Uploaders

> How about renaming the current python3-louvain package to
> python3-community-louvain using a normal transition package.

that's incorrect: src:python-louvain builds a module called
`community` (that includes also a cli tool), so the resulting binary
package should either be `python3-community` or `community` where the
cli is the main product and the module is installed in /usr/share/ to
support it.

> Then I can submit the other louvain package using a binary package name
> of python3-louvain-igraph.

this is incorrect too: (perspective) src:louvain (or
src:louvain-igraph, as the upstream called their repo) builds a module
called `louvain` so the resulting binary package should be
`python3-louvain` eventually conflicting with the existing package (<<
current-version-in-sid)

src:python-louvain is in a pretty bad shape: it received a single
upload in late 2018, it has an RC bug since a *day* after that upload,
and it has never been in testing: tbh i dont consider this package to
be maintained/targeting any stable release, so i believe you can "take
over" the namespace given you seem to show interest in maintaining
https://github.com/vtraag/louvain-igraph

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#982059: Bug#982372: Bug#982059: manpages-de: procps: File sconflict between procps and manpages-de

[Sedat Dilek]

With attached debdiff I was able to build and install:

manpages-de (4.9.2-1.1~dileks)

- Sedat -


manpages-l10n-4_9_2-1_dileks-v2.debdiff
Description: Binary data

Bug#469263: devscripts: new script to access ldap/machines.cgi and login to machines

[Paul Wise]

On Thu, 2021-02-11 at 00:23 +0100, Guillem Jover wrote:
On Tue, 2008-03-04 at 18:28:45 +0900, Paul Wise wrote:
> > I'd like a script to transfer data to and login to the Debian
> > porting machines that are up and available to me.
> 
> This seems quite some requirements, when I think most people tend to
> want mostly to know where to connect to.

I believe Jakub Wilk has another script for this, CCed for his opinion.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#469263: devscripts: new script to access ldap/machines.cgi and login to machines

[Faidon Liambotis]

On Thu, Feb 11, 2021 at 12:23:34AM +0100, Guillem Jover wrote:
> I'm also not sure what license Faidon would like to add to this.
> Personally I'd be fine with permissive or copyleft, or whatever other
> default license is used in devscripts.

I don't think I ever considered my one-liner copyrightable :) but for
the avoidance of any doubt, consider this licensed under the Zero-Clause
BSD license, as found e.g. on the OSI website:
https://opensource.org/licenses/0BSD

Best,
Faidon

Bug#981647: libgnupg-interface-perl 1.01 breaks ssh-agent msva-perl ...

[Andrew Ruthven]

On Wed, 2021-02-10 at 22:01 +, Dominic Hargreaves wrote:
> On Sun, Feb 07, 2021 at 11:42:43PM +, Dominic Hargreaves wrote:
> > Andrew, was this intentional? Maybe we should just restore that
> > part
> > of the patch?
> 
> Ah, I expect the change to /usr/bin/gpg was lost when applying an
> altered upstream version of the patch. So my tentative fix
> was correct and just the previous behaviour, with the upstream
> changes and the Debian-specific changes now in separate files.
> Uploaded.

You are correct, that was accidental while I was updating the patches.
You fix looks correct to me. Thank you!

Cheers,
Andrew
-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud:   | This space intentionally left blank
 https://catalystcloud.nz |

Bug#469263: devscripts: new script to access ldap/machines.cgi and login to machines

[Guillem Jover]

Control: tag -1 patch

Hi!

On Tue, 2008-03-04 at 18:28:45 +0900, Paul Wise wrote:
> Package: devscripts
> Version: 2.10.18.1
> Severity: wishlist

> I'd like a script to transfer data to and login to the Debian porting
> machines that are up and available to me. The script could: 
> 
>   * connect to ldap or parse machines.cgi 
>   * choose machines to login to based on all/DD/restricted,
> architecture, status, have chroots, distribution
> (etch/sarge/etc) 
>   * transfer a tarball and a script to run on the machines 
>   * chmod and run the script in the dchroot (or outside it) 
>   * detect if dchroot is available, run the script normally if not 
>   * log script output to a file and transfer the result back after
> logging out 
>   * have an option to leave an interactive session after running the
> script on each host 
>   * have an option to have each machine in a separate xterm for
> parallel execution
> 
> I don't need such a script very often but it would be nice to have.

This seems quite some requirements, when I think most people tend to
want mostly to know where to connect to.

This was discussed on debian-devel some years ago [P], and several
scripts were posted. I've been using Faidon Liambotis' one locally for a
while, and today while this came up again on #debian-apt, improved it to
cover the foreign chroot cases. I'm attaching the script, which I think
could go as is, and can always be improved/extended later on.

  [P] 

I've included the host and arch in the output, so that for the foreign
cases, people can choose the beefier arches if available. But I guess
this could then be modified with a command-line option or similar if
desired.

I'm pondering though that deb-porterbox might be abusing the «deb-»
namespace and it might be better to call this «debian-porterbox»?

I'm also not sure what license Faidon would like to add to this.
Personally I'd be fine with permissive or copyleft, or whatever other
default license is used in devscripts.

Thanks,
Guillem
#!/bin/sh

set -e

arch="$1"
if [ -z "$arch" ]; then
  echo "error: missing architecture argument" 2>&1
  exit 1
fi

case "$arch" in
i386)
  sarch=amd64
  ;;
armel|armhf)
  sarch=arm64
  ;;
mips)
  sarch=mips64
  ;;
mips64el)
  # The host is mipsel, but the kernel is 64-bit MIPS.
  sarch=mipsel
  ;;
mipsel)
  sarch=mips64el
  ;;
powerpc)
  sarch=ppc64
  ;;
esac

archfilter="(architecture=$arch)"
if [ -n "$sarch" ]; then
  archfilter="(|$archfilter(architecture=$sarch))"
fi

exec ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org \
  "(&(purpose=porterbox)$archfilter)" hostname architecture | \
  sed -e '/^dn:/d;s/^hostname:/host:/;s/^architecture:/arch:/'

Bug#982283: override: bsdmainutils:oldlibs/optional

[Samuel Thibault]

Sean Whitton, le lun. 08 févr. 2021 11:10:43 -0700, a ecrit:
> On Mon 08 Feb 2021 at 10:19AM +01, Chris Hofstaedtler wrote:
> > Package: ftp.debian.org
> > Severity: normal
> >
> > Hi,
> >
> > bsdmainutils has become a transitional package in bullseye. It would be
> > great if we don't install it by default - right now its Priority:
> > important.
> 
> I'm happy to go right ahead and lower the priority of the package that's
> only transitional, as it having a higher priority is not achieving
> anything at all.

Yes, please.

> It seems appropriate to start a discussion on -devel about not
> installing those various utils by default by not raising the priority of
> the package they're not in, however?

With the three "not" I didn't understand which way you wanted to mean
something.

Samuel

Bug#982435: screen: CVE-2021-26937

[Tavis Ormandy]

On Wed, Feb 10, 2021 at 05:51:50PM +0100, Axel Beckert wrote:
> 
> It though doesn't crash an unpatched screen.
> 

Hey Axel, I tried to reply to your screen-devel post, but it's taking a
while to subscribe!

Here is the message I sent:

On 2021-02-10, Axel Beckert wrote:
> +  else if (i < sizeof combchars / sizeof *combchars) {

This doesn't seem right, I think it should be compared against the
calloc param at the top of utf8_handle_comb(), but I don't really
understand enough about unicode to know where that 0x802 comes from!

I think for sure this code doesn't handle c > 0x801, so maybe that's an
acceptable fix?

i.e.

--- encoding.c>-2020-02-05 12:09:38.0 -0800
+++ encoding.c>-2021-02-10 15:00:05.0 -0800
@@ -1357,6 +1357,9 @@
   int root, i, c1;
   int isdouble;

+  if (c > 0x801)
+return;
+
   c1 = mc->image | (mc->font << 8) | mc->fontx << 16;
   isdouble = c1 >= 0x1100 && utf8_isdouble(c1);
   if (!combchars)


Tavis.


-- 
 _o)$ lynx lock.cmpxchg8b.com
 /\\  _o)  _o)  $ finger tav...@sdf.org
_\_V _( ) _( )  @taviso

Bug#982504: redis-server: Redis crashes with SIGBUS on armhf (with 64bit kernel) when enabling clustering

[Stefano Rivera]

Package: redis-server
Version: 5:6.0.9-4
Severity: severe
Tags: upstream patch
Forwarded: https://github.com/redis/redis/pull/7958
Control: block 982209 with -1

Discoved due to autopkgtest timeouts on the python-limits package
(#982209).

redis-server crashes with a SIGBUS when you start clustering, due to an
alignment error. armhf on arm64 kernels has hard alignment requirements.

=== REDIS BUG REPORT START: Cut & paste starting from here ===
16647:M 10 Feb 2021 21:34:54.656 # Redis 6.0.9 crashed by signal: 7, si_code: 1
16647:M 10 Feb 2021 21:34:54.656 # Crashed running the instruction at: 0xbc9446
16647:M 10 Feb 2021 21:34:54.656 # Accessing address: 0x1b133c5
16647:M 10 Feb 2021 21:34:54.656 # Killed by PID: 28390341, UID: 0
16647:M 10 Feb 2021 21:34:54.657 # Failed assertion:  (:0)

-- STACK TRACE --
EIP:
redis-server *:7001 [cluster](clusterProcessPacket+0x491)[0xbc9446]

Backtrace:
redis-server *:7001 [cluster](logStackTrace+0x39)[0xbc263a]
redis-server *:7001 [cluster](sigsegvHandler+0x93)[0xbc2ca4]
/lib/arm-linux-gnueabihf/libc.so.6(+0x2acc0)[0xf7986cc0]
redis-server *:7001 [cluster](clusterProcessPacket+0x491)[0xbc9446]
redis-server *:7001 [cluster](clusterReadHandler+0x9b)[0xbc9b88]
redis-server *:7001 [cluster](+0x9fb64)[0xbfeb64]
redis-server *:7001 [cluster](aeProcessEvents+0x1ef)[0xb85b88]
redis-server *:7001 [cluster](aeMain+0xf)[0xb85e44]
redis-server *:7001 [cluster](main+0x35d)[0xb819e6]
/lib/arm-linux-gnueabihf/libc.so.6(__libc_start_main+0x97)[0xf7976a20]

Full log attached.

Looks like this has been addressed upstream, and that patch resolves the
issue for me.

SR
16647:C 10 Feb 2021 21:19:56.163 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
16647:C 10 Feb 2021 21:19:56.163 # Redis version=6.0.9, bits=32, 
commit=, modified=0, pid=16647, just started
16647:C 10 Feb 2021 21:19:56.163 # Configuration loaded
16647:M 10 Feb 2021 21:19:56.165 * Increased maximum number of open files to 
10032 (it was originally set to 1024).
16647:M 10 Feb 2021 21:19:56.165 # Warning: 32 bit instance detected but no 
memory limit set. Setting 3 GB maxmemory limit with 'noeviction' policy now.
16647:M 10 Feb 2021 21:19:56.165 * No cluster configuration found, I'm 
ee0dfd182ce28b79f27190c079dbae115bb9d31a
16647:M 10 Feb 2021 21:19:56.211 * Running mode=cluster, port=7001.
16647:M 10 Feb 2021 21:19:56.211 # WARNING: The TCP backlog setting of 511 
cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower 
value of 128.
16647:M 10 Feb 2021 21:19:56.211 # Server initialized
16647:M 10 Feb 2021 21:19:56.211 # WARNING overcommit_memory is set to 0! 
Background save may fail under low memory condition. To fix this issue add 
'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the 
command 'sysctl vm.overcommit_memory=1' for this to take effect.
16647:M 10 Feb 2021 21:19:56.211 # WARNING you have Transparent Huge Pages 
(THP) support enabled in your kernel. This will create latency and memory usage 
issues with Redis. To fix this issue run the command 'echo madvise > 
/sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your 
/etc/rc.local in order to retain the setting after a reboot. Redis must be 
restarted after THP is disabled (set to 'madvise' or 'never').
16647:M 10 Feb 2021 21:19:56.212 * Ready to accept connections
16647:M 10 Feb 2021 21:20:27.306 # configEpoch set to 2 via CLUSTER 
SET-CONFIG-EPOCH


=== REDIS BUG REPORT START: Cut & paste starting from here ===
16647:M 10 Feb 2021 21:34:54.656 # Redis 6.0.9 crashed by signal: 7, si_code: 1
16647:M 10 Feb 2021 21:34:54.656 # Crashed running the instruction at: 0xbc9446
16647:M 10 Feb 2021 21:34:54.656 # Accessing address: 0x1b133c5
16647:M 10 Feb 2021 21:34:54.656 # Killed by PID: 28390341, UID: 0
16647:M 10 Feb 2021 21:34:54.657 # Failed assertion:  (:0)

-- STACK TRACE --
EIP:
redis-server *:7001 [cluster](clusterProcessPacket+0x491)[0xbc9446]

Backtrace:
redis-server *:7001 [cluster](logStackTrace+0x39)[0xbc263a]
redis-server *:7001 [cluster](sigsegvHandler+0x93)[0xbc2ca4]
/lib/arm-linux-gnueabihf/libc.so.6(+0x2acc0)[0xf7986cc0]
redis-server *:7001 [cluster](clusterProcessPacket+0x491)[0xbc9446]
redis-server *:7001 [cluster](clusterReadHandler+0x9b)[0xbc9b88]
redis-server *:7001 [cluster](+0x9fb64)[0xbfeb64]
redis-server *:7001 [cluster](aeProcessEvents+0x1ef)[0xb85b88]
redis-server *:7001 [cluster](aeMain+0xf)[0xb85e44]
redis-server *:7001 [cluster](main+0x35d)[0xb819e6]
/lib/arm-linux-gnueabihf/libc.so.6(__libc_start_main+0x97)[0xf7976a20]

-- INFO OUTPUT --
# Server
redis_version:6.0.9
redis_git_sha1:
redis_git_dirty:0
redis_build_id:74d695619ee2c9cb
redis_mode:cluster
os:Linux 4.19.0-14-arm64 armv8l
arch_bits:32
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:10.2.1
process_id:16647
run_id:46f70fb862cefd4e2c1f068385d388a6258005ff
tcp_port:7001
uptime_in_seconds:31
uptime_in_days:0
hz:10
configured_hz:10
lru_clock:2379291

Bug#982485: libdist-zilla-plugin-requiresexternal-perl: FTBFS: t/externaldeps.t failure

[gregor herrmann]

On Wed, 10 Feb 2021 20:46:30 +0200, Niko Tyni wrote:

> From what I can see the libdist-zilla-plugin-requiresexternal-perl
> autopkgtest checks didn't get triggered for libtest-output-perl testing
> migration at all. I don't understand why.

Maybe because libtest-output-perl is "only" a build dependency?

Cheers,
gregor 

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#982501: texlive-full: Not possible to compile a document using the Copernicus Publications LaTeX Template

[Hilmar Preuße]

Am 10.02.2021 um 22:36 teilte Ramiro Checa-Garcia mit:

Hi,


Here I am reporting an issue I found to compile a LaTeX document with
pdflatex or latexmk when I use the Copernicus Publications Template.
Here I describe the issue (this is my first bug-report, please don't
hesitate to ask further information!)

(1) I have installed Texlive-full and download the Copernicus
Publications LaTeX Template.

Please consider to contact the author of that document class if you have 
issues using it. We do package TL for Debian, but we do not support 
every kind of package combinations in your documents. You may post the 
document + document class here but I can't promise that I can help you.


Hilmar


(2) I have compiled successfully the same document with NixOS and
Manjaro. Therefore th the latex document is ok and it seems a problem
of the package of Texlive

(3) With Debian-Testing (Bullseye) it is not possible to compile. At
the beginning it reports some warnings and then is the compilation is
frozen (with 100% CPU use) for hours without ending.

Here is the output I got:

===


pdflatex blabla.tex



This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian)
(preloaded format=pdflatex)
  restricted \write18 enabled.
entering extended mode
(./crescendo_DUST_stage2_3.tex
LaTeX2e <2020-10-01> patch level 4
L3 programming layer <2021-01-09> xparse <2020-03-03> (./copernicus.cls
Document Class: copernicus 2018/10/08 8.82 Copernicus papers
(/usr/share/texlive/texmf-dist/tex/latex/base/fixltx2e.sty

Package fixltx2e Warning: fixltx2e is not required with releases after
2015
(fixltx2e)    All fixes are now in the LaTeX kernel.
(fixltx2e)    See the latexrelease package for details.

)
Additional configuration file copernicus.cfg used
(./copernicus.cfg) (/usr/share/texlive/texmf-
dist/tex/latex/base/article.cls
Document Class: article 2020/04/10 v1.4m Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/fleqn.clo)
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty)
(/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty)
(/usr/share/texlive/texmf-dist/tex/latex/base/textcomp.sty)
(/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty)
(/usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
(/usr/share/texlive/texmf-dist/tex/generic/babel/babel.def
(/usr/share/texlive/texmf-dist/tex/generic/babel/txtbabel.def))
(/usr/share/texlive/texmf-dist/tex/generic/babel-english/english.ldf))
(/usr/share/texlive/texmf-dist/tex/latex/tools/array.sty)
(/usr/share/texlive/texmf-dist/tex/latex/tools/tabularx.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg)
(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def)))
(/usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg))
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amssymb.sty
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amsfonts.sty))
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty
For additional information on amsmath, use the `?' option.
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amstext.sty
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsgen.sty))
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty)
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty))
(/usr/share/texlive/texmf-dist/tex/latex/amscls/amsthm.sty)
(/usr/share/texlive/texmf-dist/tex/latex/url/url.sty)
(/usr/share/texlive/texmf-dist/tex/latex/accents/accents.sty)
(/usr/share/texlive/texmf-dist/tex/latex/cancel/cancel.sty)
(/usr/share/texlive/texmf-dist/tex/latex/multirow/multirow.sty)
(/usr/share/texlive/texmf-dist/tex/latex/supertabular/supertabular.sty)
(/usr/share/texlive/texmf-dist/tex/latex/algorithms/algorithmic.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/ifthen.sty))
(/usr/share/texlive/texmf-dist/tex/latex/algorithms/algorithm.sty
(/usr/share/texlive/texmf-dist/tex/latex/float/float.sty))
(/usr/share/texlive/texmf-dist/tex/latex/caption/caption.sty
(/usr/share/texlive/texmf-dist/tex/latex/caption/caption3.sty)

Package caption Warning: Unknown document class (or package),
(caption)    standard defaults will be used.
See the caption package documentation for explanation.

) (/usr/share/texlive/texmf-dist/tex/latex/subfloat/subfloat.sty
Package `subfloat', Version 2.14 of 2003/08/21.

Package subfloat Warning: Numbers of floats not counted:
(subfloat)    If you use one of the counters
subfloatfiguremax or
(subfloat)    subfloattablemax you will get strange error
messages
(subfloat)    

Bug#982468: [Pkg-fonts-devel] Bug#982468: fonts-noto-color-emoji: U+1F52B PISTOL shows a water-spraying toy instead

[James Godfrey-Kittle]

For a little more context, see discussion at
https://github.com/googlefonts/noto-emoji/pull/213. In particular note
that this design upstream (i.e. in Noto) is actually motivated by a
need to be consistent with Apple, which made the change from pistol to
water gun about two years earlier. In this case Apple has effectively
dictated their own standard that contradicts Unicode, and forced other
platforms to follow. Practically all actively-maintained emoji fonts
are using a water gun glyph for U+1F52B at this point:
https://emojipedia.org/pistol/.

Anyways, what did you hope to accomplish by filing this bug against a
Debian package? Is Debian going to start designing its own hotfix
glyphs? If not, you should try to get this fixed in Noto (unlikely,
admittedly) or use a different font.

Bug#981647: libgnupg-interface-perl 1.01 breaks ssh-agent msva-perl ...

[Dominic Hargreaves]

On Sun, Feb 07, 2021 at 11:42:43PM +, Dominic Hargreaves wrote:
> [Adding Andrew as the person who has recently worked on the package]
> 
> On Sun, Feb 07, 2021 at 03:28:48PM -0500, Aaron M. Ucko wrote:
> > Dominic Hargreaves  writes:
> > 
> > > As a hunch, I changed the default from 'gpg' to '/usr/bin/gpg'.
> > > Could you install this on your system and confirm whether it fixes
> > > the problem?
> 
> (the tentative fix was at
> )
> 
> > I must confess that I haven't actually fully deployed MonkeySphere, so I
> > can't test the change quite as thoroughly as it perhaps deserves, but
> > AFAICT this tweak is sufficient: I can log in without incident, and both
> > dh_auto_test calls to succeed (albeit noisily) with
> > 
> >   -- FULLPERL='/usr/bin/perl -t'
> > 
> > appended.  (Full -T appears to break the test harness, but -t suffices
> > to trigger the PATH-clearing logic.)
> 
> In fact, I've just realised that this regression comes from reverting
> a functionality equivalent (part of a) patch in the latest upload.
> This looks like it might have been unintentional?
> 
> https://salsa.debian.org/perl-team/modules/packages/libgnupg-interface-perl/-/commit/a96ae3047570483e96da309008d4110f16824ed5#f37d120361709f5984c8a7d93302241dc341b4b3_1_1
> 
> Andrew, was this intentional? Maybe we should just restore that part
> of the patch?

Ah, I expect the change to /usr/bin/gpg was lost when applying an
altered upstream version of the patch. So my tentative fix
was correct and just the previous behaviour, with the upstream
changes and the Debian-specific changes now in separate files.
Uploaded.

Bug#982503: neurodebian: Build-Depends on xcftools wich should not be released with bullseye

[Salvatore Bonaccorso]

Source: neurodebian
Version: 0.40.1
Severity: serious
Justification: Depends on xcftools unfit for bullseye release
X-Debbugs-Cc: car...@debian.org,t...@security.debian.org
Control: block 982499 by -1

neurodebian Build-Depends on xcftools which ideally should not be
released with bullseye. As it looks xcftools is used for calling
xcf2png. This can be equivalently be done with convert from
imagemagick, can you please check to switch away from xcftools for
this conversions?

game-data-packager for instance has already the casing to use convert
if xcf2png is not available. So you could do similarly.

Ivo De Decker confirmed to fill those bugs with serious severity to
make it possible to release bullseye without xcftools:

< ivodd> carnil: I suggest you file serious bugs against the 3 rdeps asking 
them to switch
< ivodd> if it's as easy as it looks from the bug report, it shouldn't be a big 
issue
< ivodd> if it turn out it's more complicated, we can still revisit the issue

if it turns out to not be feasible we later on can revisit the severity and
postpone it for bookworm.

Regards,
Salvatore

Bug#982502: game-data-packager: Build-Depends on xcftools wich should not be released with bullseye

[Salvatore Bonaccorso]

Source: game-data-packager
Version: 66
Severity: serious
Justification: Depends on xcftools unfit for bullseye release
X-Debbugs-Cc: car...@debian.org,t...@security.debian.org
Control: block 982499 by -1

Hi

game-data-packager uild-Depends on xcftools which ideally should not
be released with bullseye. As it looks xcftools is used for calling
xcf2png. In the makefile there is already even the casing to fall back
to convert from imagemagick if xcf2png is not present. So could you
please investigate if it is possible to switch away from xcftools for
this conversions.

Ivo De Decker confirmed to fill those bugs with serious severity to
make it possible to release bullseye without xcftools:

< ivodd> carnil: I suggest you file serious bugs against the 3 rdeps asking 
them to switch
< ivodd> if it's as easy as it looks from the bug report, it shouldn't be a big 
issue
< ivodd> if it turn out it's more complicated, we can still revisit the issue

if it turns out to not be feasible we later on can revisit the severity and
postpone it for bookworm.

Regards,
Salvatore

Bug#982501: texlive-full: Not possible to compile a document using the Copernicus Publications LaTeX Template

[Ramiro Checa-Garcia]

Package: texlive-full
Version: 2020.20210202-2
Severity: normal
Tags: upstream

Dear Maintainer,

Here I am reporting an issue I found to compile a LaTeX document with
pdflatex or latexmk when I use the Copernicus Publications Template.
Here I describe the issue (this is my first bug-report, please don't
hesitate to ask further information!)

(1) I have installed Texlive-full and download the Copernicus
Publications LaTeX Template.

(2) I have compiled successfully the same document with NixOS and
Manjaro. Therefore th the latex document is ok and it seems a problem
of the package of Texlive

(3) With Debian-Testing (Bullseye) it is not possible to compile. At
the beginning it reports some warnings and then is the compilation is
frozen (with 100% CPU use) for hours without ending.

Here is the output I got:

===

> pdflatex blabla.tex


This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian)
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./crescendo_DUST_stage2_3.tex
LaTeX2e <2020-10-01> patch level 4
L3 programming layer <2021-01-09> xparse <2020-03-03> (./copernicus.cls
Document Class: copernicus 2018/10/08 8.82 Copernicus papers
(/usr/share/texlive/texmf-dist/tex/latex/base/fixltx2e.sty

Package fixltx2e Warning: fixltx2e is not required with releases after
2015
(fixltx2e)    All fixes are now in the LaTeX kernel.
(fixltx2e)    See the latexrelease package for details.

)
Additional configuration file copernicus.cfg used
(./copernicus.cfg) (/usr/share/texlive/texmf-
dist/tex/latex/base/article.cls
Document Class: article 2020/04/10 v1.4m Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/fleqn.clo)
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty)
(/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty)
(/usr/share/texlive/texmf-dist/tex/latex/base/textcomp.sty)
(/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty)
(/usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
(/usr/share/texlive/texmf-dist/tex/generic/babel/babel.def
(/usr/share/texlive/texmf-dist/tex/generic/babel/txtbabel.def))
(/usr/share/texlive/texmf-dist/tex/generic/babel-english/english.ldf))
(/usr/share/texlive/texmf-dist/tex/latex/tools/array.sty)
(/usr/share/texlive/texmf-dist/tex/latex/tools/tabularx.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg)
(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def)))
(/usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg))
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amssymb.sty
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amsfonts.sty))
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty
For additional information on amsmath, use the `?' option.
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amstext.sty
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsgen.sty))
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty)
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty))
(/usr/share/texlive/texmf-dist/tex/latex/amscls/amsthm.sty)
(/usr/share/texlive/texmf-dist/tex/latex/url/url.sty)
(/usr/share/texlive/texmf-dist/tex/latex/accents/accents.sty)
(/usr/share/texlive/texmf-dist/tex/latex/cancel/cancel.sty)
(/usr/share/texlive/texmf-dist/tex/latex/multirow/multirow.sty)
(/usr/share/texlive/texmf-dist/tex/latex/supertabular/supertabular.sty)
(/usr/share/texlive/texmf-dist/tex/latex/algorithms/algorithmic.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/ifthen.sty))
(/usr/share/texlive/texmf-dist/tex/latex/algorithms/algorithm.sty
(/usr/share/texlive/texmf-dist/tex/latex/float/float.sty))
(/usr/share/texlive/texmf-dist/tex/latex/caption/caption.sty
(/usr/share/texlive/texmf-dist/tex/latex/caption/caption3.sty)

Package caption Warning: Unknown document class (or package),
(caption)    standard defaults will be used.
See the caption package documentation for explanation.

) (/usr/share/texlive/texmf-dist/tex/latex/subfloat/subfloat.sty
Package `subfloat', Version 2.14 of 2003/08/21.

Package subfloat Warning: Numbers of floats not counted:
(subfloat)    If you use one of the counters
subfloatfiguremax or
(subfloat)    subfloattablemax you will get strange error
messages
(subfloat)    containing \c@subfloatfiguremax or
(subfloat)    \c@subfloattablemax:
(subfloat)    Please switch on countmax or remove the code
using
(subfloat)    the counter then..

) (./natbib.sty) (/usr/share/texlive/texmf-

Bug#982164: RFS: geda-gaf/1.10.2-2 [ITA] -- GPL EDA -- Electronics design software

[Roland Lutz]

On Wed, 10 Feb 2021, Juhani Numminen wrote:

The xorn executable is not too well suited to be in libgeda47 because
its name does not change with SONAME which would make library
transitions difficult.[2] So perhaps put xorn live in geda-utils then?


The xorn executable is called internally, so packaging it in geda-utils 
would mean the other packages would have to depend on this package. 
Since geda-utils contains rarely-used programs that usually aren't 
installed at all, I'd like to avoid this.  The xorn binary itself is a 
script, so it could be packaged in libgeda-common, though.


Another option would be to package the xorn binary separately; but 
gEDA/gaf is already fragmented into many packages, and I'd like to avoid 
introducing yet another one.


Leaving things as-is shouldn't be a problem, either, since libgeda is an 
internal library used by gEDA/gaf, and when it's replaced by a new 
version, all binary packages are replaced at the same time.


Roland

Bug#982500: castle-game-engine: Build-Depends on xcftools wich should not be released with bullseye

[Salvatore Bonaccorso]

Source: castle-game-engine
Version: 6.4+dfsg1-5
Severity: serious
Justification: Depends on xcftools unfit for bullseye release
X-Debbugs-Cc: car...@debian.org,t...@security.debian.org
Control: block 982499 by -1

Hi

castle-game-engine Build-Depends on xcftools which ideally should not
be released with bullseye. As it looks xcftools is used for calling
xcf2png. Could you please investigate if it is possible to switch away
from xcftools for this conversions.

Ivo De Decker confirmed to fill those bugs with serious severity to
make it possible to release bullseye without xcftools:

< ivodd> carnil: I suggest you file serious bugs against the 3 rdeps asking 
them to switch
< ivodd> if it's as easy as it looks from the bug report, it shouldn't be a big 
issue
< ivodd> if it turn out it's more complicated, we can still revisit the issue

if it turns out to not be feasible we later on can revisit the severity and
postpone it for bookworm.

Regards,
Salvatore

Bug#982499: xcftools: not fit for stable release, dead upstream, unmaintained

[Salvatore Bonaccorso]

Source: xcftools
Version: 1.0.7-6
Severity: serious
Justification: dead upstream, not fit for stable release
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi

xcftools is at it looks dead upstream and on the last security issues
reported (CVE-2019-5086 CVE-2019-5087, #945317) there never was an
upstream reaction.

Ideally in this form xcftools is not to be shipped in bullseye and
later, but there are some issues to be resolved:

castle-game-engine: xcftools
game-data-packager/contrib: xcftools
neurodebian: xcftools

build-depend on it and it seems mostly for xcf2png calling, which can
probably be replaced with an imagemagick convert call.

I will fill bugs (with RC severity) after checking with the release
team (Ivo De Decker), for the three reverse build dependencies
initially with RC severity to investigate the switch from xcftools:

[22:21] < ivodd> carnil: I suggest you file serious bugs against the 3 rdeps 
asking them to switch
[22:21] < ivodd> if it's as easy as it looks from the bug report, it shouldn't 
be a big issue
[22:21] < ivodd> if it turn out it's more complicated, we can still revisit the 
issue

if it turns out to not be feasible we later on can revisit the severity and
postpone it for bookworm.

Regards,
Salvatore

Bug#970689: live-build: fails when lilo can't be installed, even if unused

[Roland Clobus]

On 09/02/2021 06:38, Borden wrote:
> On Sat, 6 Feb 2021 10:34:19 +0100 Roland Clobus  wrote:
>> I have a patch in preparation. I'm reviewing it and will send a merge
>> request soon.
> 
> That's great. Is it in a repo where I can test it? I'm a bit impatient to get 
> my custom live-boot working so I can upgrade hard drives / have a disaster 
> recovery plan.

I've finished it. I needed some more time to confirm that the amd64 live
images for Buster did not need lilo (otherwise it would have needed a
backwards compatibility mode).

The merge request is at:
https://salsa.debian.org/live-team/live-build/-/merge_requests/241

The merge request adds Bullseye and removes the need for lilo.
Using upstream/master with the MR applied, will result in images of
Buster that will allow the installer to run. If you want to use
Bullseye, you'll need the daily installer
(--parent-debian-installer-distribution daily), otherwise you'll get a
warning that no kernel modules are found (because the installer is based
on the current Debian Stable).

With kind regards,
Roland Clobus

Bug#955540: chromium: Using ozone

[Bastian Germann]

Control: tags - help

On Thu, 21 Jan 2021 16:31:29 +0100 Michel Le Bihan  
wrote:

Hello,

I built Chromium with ozone, but I'm not sure if it's ready for Debian
yet. It will need testing. You can test it, if you want:
https://lebihan.pl/chromium/chromium_88.0.4324.96-ozone.tar
Currently, I only built for amd64.

Michel Le Bihan


Thanks for providing the build. It works great for me. I tested it over 
one week. Would you please upload this to experimental? I will then try 
building for armhf with the hardware decoding enabled.

Bug#981969: ddd: diff for NMU version 1:3.3.12-5.3

[Sebastian Ramacher]

Control: tags 981969 + patch

Dear maintainer,

I've prepared an NMU for ddd (versioned as 1:3.3.12-5.3). The diff
is attached to this message.

Cheers
-- 
Sebastian Ramacher
diff -Nru ddd-3.3.12/debian/changelog ddd-3.3.12/debian/changelog
--- ddd-3.3.12/debian/changelog	2019-10-03 14:13:39.0 +0200
+++ ddd-3.3.12/debian/changelog	2021-02-10 22:05:37.0 +0100
@@ -1,3 +1,10 @@
+ddd (1:3.3.12-5.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Only modify manpage in arch builds (Closes: #981969)
+
+ -- Sebastian Ramacher   Wed, 10 Feb 2021 22:05:37 +0100
+
 ddd (1:3.3.12-5.2) unstable; urgency=medium
 
   [ Sophie Brun ]
diff -Nru ddd-3.3.12/debian/rules ddd-3.3.12/debian/rules
--- ddd-3.3.12/debian/rules	2019-10-03 14:13:39.0 +0200
+++ ddd-3.3.12/debian/rules	2021-02-10 22:00:42.0 +0100
@@ -27,8 +27,7 @@
 	rm -f ddd/ddd.info.txt ddd/ddd.info.txt.gz
 	rm -f ddd/ddd.info.txt.gz.C
 
-override_dh_install:
-	dh_install
+execute_after_dh_install-arch:
 	# The manpage installed contains a reference to a logo .eps file in the
 	# build directory which isn't even created; remove this reference to
 	# eliminate man warnings.


signature.asc
Description: PGP signature

Bug#945317: xcftools NMU for CVE-2019-5086 and CVE-2019-5087

[Salvatore Bonaccorso]

Hi Markus,

On Wed, Feb 10, 2021 at 03:17:57PM +0100, Markus Koschany wrote:
> Hello Salvatore,
> 
> Am Mittwoch, den 10.02.2021, 06:30 +0100 schrieb Salvatore Bonaccorso:
> [...]
> > Question back on this.
> > 
> > Is it confirmed that it fixes both CVE-2019-5086 (TALOS-2019-0878,
> > https://github.com/j-jorge/xcftools/issues/12) and CVE-2019-5087
> > (TALOS-2019-0879, https://github.com/j-jorge/xcftools/issues/13) which
> > were slight different issues?
> > 
> > Unfortunately upstream itself is at best dormant.
> > 
> > There was lot of discussion back then basically just around
> > CVE-2019-5086 but not covering CVE-2019-5087 involving Brian May and a
> > patch from Anton.
> > 
> > Hugo, Brian, Anton does the final patch you were aiming and posted
> > address both issues, did any of you got some feedback from Talos
> > because of TALOS-2019-0878 and TALOS-2019-0879?
> 
> I was in contact with Anton Gladky and this was basically his patch. The patch
> is unfortunately incomplete for 32 bit architectures which I saw too late. I
> believe I know how to fix it and I intend to discuss the new patch with Anton.
> In my opinion upstream is dead and our Debian maintainer is unresponsive 
> and/or
> MIA too, so we have to take the initiative. I haven't contacted TALOS and we
> haven't received any feedback from them. The idea behind the patch was to
> prevent the overflow with a check for a upper limit for INT. Now, because of
> the 32 bit problem, I think we should double-check this with a guard to 
> protect
> against negative values for height and width because negative values are
> illogical for these dimensions. Currently I believe this fixes both CVE and
> Anton had created a test case for it but I check with him again.

Thanks for the status-Update. In short, I cannot claim to judge if the
patch is covering fully both vulnerabilities, but if you are confident
it does then this good. Thing which was unclear is the item Brian
looked at if there are issues with XCF specs.

In a short offlist discussion we (as in security team) discussed in
general about the state of xcftools and we think it might be worth
trying to get it removed from unstable (and so bullseye) in time
because of as said at least dormant, but probably likely dead
upstream.

So checked what would cause problems to have it removed and it looks
not overall too bad. There seem to be only broken build-depends:

castle-game-engine: xcftools
game-data-packager/contrib: xcftools
neurodebian: xcftools

and hopefully all of those can do without it.

castle-game-engine calls in debian/rules xcf2png and maybe this can be
equivalently covered with a imagemagick convert.

For game-data-packager I'm already talking to the right person I guess
:). The Makefile uses here as well xcf2png to convert files.

neurodebian: Again very similar to the others, they use apparently
xcf2png to convert some xcf to png.

But this is something to be detached from the #945317 bugreport, but
it is probably doable and so we can get actually rid of xcftools for
the bullseye release cycle.

I'm not fully in favor to have all the (build-)rdeps forced out of
Debian, that would likely not be a benefit as seems unfair to the
castle-game-engine, game-data-packager and neurodebian packages, but
still think having out xcftools out of bullseye would be the right
thing.

Regards,
Salvatore

Bug#982497: RFP: sequeler -- Sequeler is a SQL client built in Vala and Gtk

[Leandro Ramos]

Package: wnpp
Severity: wishlist

* Package name: sequeler
  Version : 0.8.0
  Upstream Author : Alessandro Castellani 
* URL : https://github.com/Alecaddd/sequeler
* License : GPL-3.0
  Programming Lang: Vala
  Description : Sequeler is a SQL client built in Vala and Gtk

Sequeler is a native Linux SQL client built in Vala and Gtk. It allows you to
connect to your local and remote databases, write SQL in a handy text editor
with language recognition, and visualize SELECT results in a Gtk.Grid Widget.

Supported databases:
- PostgreSQL
- MariaDB/MySQL
- SQLite

I consider this package very useful to connect and perform simple queries in
database servers.

Bug#982483: Bug in r-base and r-cran-rcppparallel

[Andreas Tille]

Hi Bastian,

On Wed, Feb 10, 2021 at 06:55:57PM +0100, Bastian Blank wrote:
> Control: retitle -2 r-cran-rcppparallel: generates broken load path for 
> libtbb and fails on several architectures

Thanks a lot for the bug report including explanation and patch.

> - r-cran-rcppparallel trying to workaround the bug in dyn.load by
>   deducting the full path of libtbb from the architecture instead of the
>   correct multiarch setting and failing.

I admit I was not really happy about my patch and I see now the
issue more clearly.
 
> This has nothing to do with r-cran-rstan or r-cran-rstanarm, but it
> seems to be the first one to find out.  I've attached patches to fix
> both problems, properly re-assigned and adjusted the bugs.
> 
> This behaviour of R dyn.load might even be considered a security
> vulnerability, because loading libraries from the working directory is a
> problem.


> diff -Nru r-cran-rcppparallel-5.0.2+dfsg/debian/control 
> r-cran-rcppparallel-5.0.2+dfsg/debian/control
> --- r-cran-rcppparallel-5.0.2+dfsg/debian/control 2020-09-30 
> 13:39:50.0 +
> +++ r-cran-rcppparallel-5.0.2+dfsg/debian/control 2021-02-10 
> 17:43:22.0 +
> @@ -7,7 +7,7 @@
>  Priority: optional
>  Build-Depends: debhelper-compat (= 13),
> dh-r,
> -   r-base-dev,
> +   r-base-dev (>= 4.0.3-1.1~),

Seems I should set a
block -1 by 982465
since your patch works only with a fixed r-base-dev and the r-base-dev
maintainer seems to be not happy about your solution.

Kind regards and thanks again

 Andreas.

-- 
http://fam-tille.de

Bug#982059: Bug#982372: Bug#982059: manpages-de: procps: File sconflict between procps and manpages-de

[Sedat Dilek]

On Wed, Feb 10, 2021 at 9:50 PM Craig Small  wrote:
>
>
>
> On Thu, 11 Feb 2021 at 07:39, Sedat Dilek  wrote:
>>
>> Small nit:
>> On a quick view on latest manpages-l10n I still see the duplicates in
>> debian/rules e.g. kill.1 (manpages-de).
>
> The criteria for removing a page out of manpages-* is actually more 
> complicated than that. It's not just "does the procps package have this 
> manpage" but "does the procps package have this translated manpage in *this 
> language*".
>
> And for each manpage the languages that are available are different, both in 
> the procps and manpages-l10n packages. It's also not good enough to see the 
> relevant .po file because po4a will only translate a file if it is at least 
> 80% translated.
>
> In short, its a massive pain, but I think its ok now; or at least its no 
> longer conflicting.
>
> I'm not sure what you mean by duplicates here.
>

In [1] I saw:

# Remove manpages from procps
rm -f debian/manpages-de/usr/share/man/de/man1/kill.1
rm -f debian/manpages-de/usr/share/man/de/man1/free.1
rm -f debian/manpages-de/usr/share/man/de/man1/kill.1

kill.1 double.

This is now history with manpages version 4.9.2 see [2].

[2] says:

  * New upstream version 4.9.2
  * This version no longer contains the procps manpages

No more need of above hacksz in d/r.

- Sedat -

[1] 
https://salsa.debian.org/debian/manpages-l10n/-/commit/d54f4eb1227af99607feab876fdd8927d5a16dc1
[2] 
https://salsa.debian.org/debian/manpages-l10n/-/commit/81eebd8536abfbb598cb0855a5f613b7204bb1c8

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2021-02-01 23:50:03 [+0100], To Kurt Roeckx wrote:
> in case someone wants to test.
> I think the ship for this pu is sailing without me but I'm ready for the
> next cruise :)

OpenSSL upstream announced [0] 1.1.1j for next Tuesday with a security
fix classified as MODERATE [1].

[0] https://mta.openssl.org/pipermail/openssl-announce/2021-February/000191.html
[1] https://www.openssl.org/policies/secpolicy.html#moderate

Sebastian

Bug#982465: Bug in r-base and r-cran-rcppparallel

[Dirk Eddelbuettel]

On 10 February 2021 at 20:35, Bastian Blank wrote:
| On Wed, Feb 10, 2021 at 01:30:10PM -0600, Dirk Eddelbuettel wrote:
| > Thanks for the CVE. I am happy to discuss this with R Core and one fellow in
| > particular.
| > Before I do so can you clarify what you think the issue is?  Loading from
| > user directories as eg ~/R/lib/mypackage/libs/mypack.so ?
| 
| No, the problem is loading from ".", not a specific directory.

Ok, sorry, then maybe I am out of the loop ... but who/where does that?

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#982059: Bug#982372: Bug#982059: manpages-de: procps: File sconflict between procps and manpages-de

[Craig Small]

On Thu, 11 Feb 2021 at 07:39, Sedat Dilek  wrote:

> Small nit:
> On a quick view on latest manpages-l10n I still see the duplicates in
> debian/rules e.g. kill.1 (manpages-de).
>
The criteria for removing a page out of manpages-* is actually more
complicated than that. It's not just "does the procps package have this
manpage" but "does the procps package have this translated manpage in *this
language*".

And for each manpage the languages that are available are different, both
in the procps and manpages-l10n packages. It's also not good enough to see
the relevant .po file because po4a will only translate a file if it is at
least 80% translated.

In short, its a massive pain, but I think its ok now; or at least its no
longer conflicting.

I'm not sure what you mean by duplicates here.

 - Craig

Bug#982496: debian-cd: Support grub theme on arm64

[Raphaël Hertzog]

Package: debian-cd
Version: 3.1.33
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: raph...@offensive-security.com

We're working on getting Kali to work as a VM on the Apple M1 and so we
are trying to build arm64 installer images with simple-cdd (and thus
debina-cd). In this process, Steev Klimaszewski 
discovered that the grub configuration used for the EFI boot on arm64 does
not take advantage of any theming, contrary to amd64/i386.

It would be nice if we could fix this by enabling the grub theme
everywhere. However this doesn't look entirely trivial as the theming
is handled through a mixture of code in tools/boot/bullseye/boot-x86
and tools/boot/bullseye/parse_isolinux, and arm64 is not relying on
isolinux at all.

Steve, your input is thus most welcome.

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN
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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debian-cd depends on:
ii  apt2.1.18
ii  bc 1.07.1-2+b2
ii  bzip2  1.0.8-4
ii  cpp4:10.2.1-1
ii  curl   7.74.0-1
ii  dctrl-tools [grep-dctrl]   2.24-3+b1
ii  dpkg-dev   1.20.7.1
ii  genisoimage9:1.1.11-3.2
pn  libcompress-zlib-perl  
pn  libdigest-md5-perl 
ii  libdpkg-perl   1.20.7.1
ii  lynx   2.9.0dev.6-1
ii  make   4.3-4
ii  perl [libdigest-sha-perl]  5.32.1-2
ii  tofrodos   1.7.13+ds-5
ii  wget   1.21-1+b1
ii  xorriso1.5.2-1

Versions of packages debian-cd recommends:
ii  dosfstools   4.1-2
ii  hfsutils 3.2.6-15
ii  isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  mtools   4.0.26-1
ii  netpbm   2:10.0-15.3+b2
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  syslinux-utils   3:6.04~git20190206.bf6db5b4+dfsg1-3

debian-cd suggests no packages.

-- no debconf information

Bug#982059: manpages-de: procps: File sconflict between procps and manpages-de

[Sedat Dilek]

On Wed, Feb 10, 2021 at 9:38 PM Sedat Dilek  wrote:
>
> On Wed, Feb 10, 2021 at 8:59 PM Craig Small  wrote:
> >
> > For testing this I installed Procps and *all*of the generated man pages and 
> > that seemed to be fine.
> >
> > That's slightly different to the patch I put in the bug report but I 
> > emailed Helge the difference.
> >
>
> Thanks Craig.
>
> Small nit:
> On a quick view on latest manpages-l10n I still see the duplicates in
> debian/rules e.g. kill.1 (manpages-de).
>

Cool, you fixed that *.install files.

Checked the latest version d/r which is fine to me.

- Sedat -

[1] https://salsa.debian.org/debian/manpages-l10n/-/blob/master/debian/rules

Bug#981846: python-argcomplete: diff for NMU version 1.8.1-1.4

[Sebastian Ramacher]

Control: tags 981846 + patch
Control: tags 981846 + pending

Dear maintainer,

I've prepared an NMU for python-argcomplete (versioned as 1.8.1-1.4) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru python-argcomplete-1.8.1/debian/changelog python-argcomplete-1.8.1/debian/changelog
--- python-argcomplete-1.8.1/debian/changelog	2020-01-16 23:49:36.0 +0100
+++ python-argcomplete-1.8.1/debian/changelog	2021-02-10 21:41:38.0 +0100
@@ -1,3 +1,11 @@
+python-argcomplete (1.8.1-1.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Set LC_ALL to C.UTF-8 instead of unsetting it (Closes:
+#981846)
+
+ -- Sebastian Ramacher   Wed, 10 Feb 2021 21:41:38 +0100
+
 python-argcomplete (1.8.1-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-argcomplete-1.8.1/debian/rules python-argcomplete-1.8.1/debian/rules
--- python-argcomplete-1.8.1/debian/rules	2020-01-14 22:48:08.0 +0100
+++ python-argcomplete-1.8.1/debian/rules	2021-02-10 21:41:38.0 +0100
@@ -7,7 +7,7 @@
 
 # Avoid failures in unit tests
 # See https://github.com/kislyuk/argcomplete/issues/199
-unexport LC_ALL
+export LC_ALL=C.UTF-8
 
 %:
 	dh $@ --with python3 --buildsystem=pybuild


signature.asc
Description: PGP signature

Bug#982355: Bug#982059: manpages-de: procps: File sconflict between procps and manpages-de

[Sedat Dilek]

On Wed, Feb 10, 2021 at 8:59 PM Craig Small  wrote:
>
> For testing this I installed Procps and *all*of the generated man pages and 
> that seemed to be fine.
>
> That's slightly different to the patch I put in the bug report but I emailed 
> Helge the difference.
>

Thanks Craig.

Small nit:
On a quick view on latest manpages-l10n I still see the duplicates in
debian/rules e.g. kill.1 (manpages-de).

- Sedat -

Bug#884101: cuetools: fails to convert .toc file generated by cdrdao (syntax error around # character)

[Jonathan Rubenstein]

I just tried using cuetag, and got a rapid slew of

> 10: syntax error

We find this on line 10

  08 | TITLE "Matka"
  09 | PERFORMER "A-Men"
>>10 | SIZE_INFO { 0,  1, 15,  0, 46,  8,  0,  0,  0,  0,  0,  0,
  11 | 0,  0,  0,  0,  0,  0,  0,  3, 56,  0,  0,  0,
  12 | 0,  0,  0,  0,  9,  0,  0,  0,  0,  0,  0,  0}

Removing this field and the following lines 11 and 12 allowed cuetag to 
work.

Bug#979819: Raise severity, cannot create venv for any older python versions!

[Kostis Anagnostopoulos]

On Wed, 10 Feb 2021 at 21:33, Stefano Rivera  wrote:
>
> Hi Kostis (2021.01.21_05:52:57_-0800)
>
> I think there are two issues to solve here:
>
> 1: Tighten the dependency on python3-distutils, to avoid this happening.
>
> 2: The thing that prints out the instructions to install python3-venv
>could be more to write errorintelligent about when it prints the message. 
> We could
>probe for the installation of the package, e.g. probe for the
>existence of /usr/lib/python3.X/ensurepip/__main__.py or try to
>import it.

I identify (2) as a root cause of confusion - given the shear number
of questions in StackOverflow sites
about venv-creation failures,
it's important that at least the message suggests to the user to try the command
(if not modifying the `subprocess` code to dump STDERR to console).

> Otherwise we print a message that is more confusing than helpful:
>
> > For instance in "sid":
> >
> > $  python3.8 -m venv .venv
> > The virtual environment was not created successfully because
> > ensurepip is not
> > available.  On Debian/Ubuntu systems, you need to install the 
> > python3-venv
> > package using the following command.
> >
> > apt-get install python3-venv
> >
> > You may need to use sudo with that command.  After installing the
> > python3-venv
> > package, recreate your virtual environment.
> >
> > Failing command: ['/home/user/.venv/bin/python3.8', '-Im',
> > 'ensurepip', '--upgrade', '--default-pip']
>
> >
> > It's only when you try the failing command that you get the root cause:
> >
> > $ /home/user/.venv/bin/python3.8 -Im ensurepip --upgrade --default-pip
> > Traceback (most recent call last):
> >   File "", line 6, in 
> >   File "/usr/lib/python3.8/runpy.py", line 207, in run_module
> > return _run_module_code(code, init_globals, run_name, mod_spec)
> >   File "/usr/lib/python3.8/runpy.py", line 97, in _run_module_code
> > _run_code(code, mod_globals, init_globals,
> >   File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
> > exec(code, run_globals)
> >   File 
> > "/tmp/tmpybc1t180/pip-20.1.1-py2.py3-none-any.whl/pip/__main__.py",
> > line 23, in 
> >   File "", line 259, in load_module
> >   File 
> > "/tmp/tmpybc1t180/pip-20.1.1-py2.py3-none-any.whl/pip/_internal/cli/main.py",
> > line 10, in 
> >   File "", line 259, in load_module
> >   File 
> > "/tmp/tmpybc1t180/pip-20.1.1-py2.py3-none-any.whl/pip/_internal/cli/autocompletion.py",
> > line 9, in 
> >   File "", line 259, in load_module
> >   File 
> > "/tmp/tmpybc1t180/pip-20.1.1-py2.py3-none-any.whl/pip/_internal/cli/main_parser.py",
> > line 7, in 
> >   File "", line 259, in load_module
> >   File 
> > "/tmp/tmpybc1t180/pip-20.1.1-py2.py3-none-any.whl/pip/_internal/cli/cmdoptions.py",
> > line 19, in 
> > ModuleNotFoundError: No module named 'distutils.util'
> > Traceback (most recent call last):
> >   File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
> > return _run_code(code, main_globals, None,
> >   File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
> > exec(code, run_globals)
> >   File "/usr/lib/python3.8/ensurepip/__main__.py", line 5, in 
> > sys.exit(ensurepip._main())
> >   File "/usr/lib/python3.8/ensurepip/__init__.py", line 265, in _main
> > return _bootstrap(
> >   File "/usr/lib/python3.8/ensurepip/__init__.py", line 183, in 
> > _bootstrap
> > return _run_pip(args + _PROJECTS, additional_paths)
> >   File "/usr/lib/python3.8/ensurepip/__init__.py", line 61, in _run_pip
> > return subprocess.run([sys.executable, "-c", code],
> > check=True).returncode
> >   File "/usr/lib/python3.8/when trying the", in run
> > raise the real cause CalledProcessError(retcode, process.args,
> > subprocess.CalledProcessError: Command
> > '['/home/user/.venv/bin/python3.8', '-c', '\nimport runpy\nimport
> > sys\nsys.path =
> > [\'/tmp/tmpybc1t180/setuptools-44.0.0-py2.py3-none-any.whl\',
> > \'/tmp/tmpybc1t180/pip-20.1.1-py2.py3-none-any.whl\',
> > \'/tmp/tmpybc1t180/pkg_resources-0.0.0-py2.py3-none-any.whl\'] +
> > sys.path\nsys.argv[1:] = [\'install\', \'--no-cache-dir\',
> > \'--no-index\', \'--find-links\', \'/tmp/tmpybc1t180\', \'--upgrade\',
> > \'setuptools\', \'pip\', \'pkg_resources\']\nrunpy.run_module("pip",
> > run_name="__main__", alter_sys=True)\n']' returned non-zero exit
> > status 1.
>
> SR
>
> --
> Stefano Rivera
>   http://tumbleweed.org.za/
>   +1 415 683 3272
>
> --
> To unsubscribe, send mail to 979819-unsubscr...@bugs.debian.org.

Bug#982494: acpica-unix: FTBFS on armhf

[Sebastian Ramacher]

Source: acpica-unix
Version: 20200925-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

| ++ dpkg-architecture -qDEB_HOST_ARCH_BITS
| + BITS=32
| ++ stat --format=%Y /<>/generate/unix/bin/iasl
| ++ cut '-d ' -f1
| + FDATE=1612117256
| ++ date --date=@1612117256 '+%b %_d %Y'
| + WHEN='Jan 31 2021'
| + sed -e s//20200925/ /<>/debian/badcode.asl.result
| + sed -e s//20200925/ /<>/debian/grammar.asl.result
| + sed -e s//20200925/ 
/<>/debian/converterSample.asl.result
| + /<>/generate/unix/bin/iasl -f badcode.asl
| + tee badcode.asl.actual
| + diff badcode.asl.actual badcode.asl.expected
| + '[' 1 -eq 0 ']'
| + exit 1
| make[2]: *** [Makefile:28: check] Error 1
| make[2]: Leaving directory '/<>'
| make[1]: *** [debian/rules:72: override_dh_auto_test] Error 2
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:31: build-arch] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

See
https://buildd.debian.org/status/fetch.php?pkg=acpica-unix=armhf=20200925-1=1612117350=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#982495: acpica-unix: FTBFS on mips64el

[Sebastian Ramacher]

Source: acpica-unix
Version: 20200925-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

| obj/acpiexamples ../../../source/components/namespace/nswalk.c
| /<>/generate/unix/iasl/obj/aslcompiler.y: In function 
‘AslCompilerparse’:
| /<>/generate/unix/iasl/obj/aslcompiler.y:1094:92: error: cast 
from pointer to integer of different size [-Werror=pointer-to-int-cast]
|  1094 | | PARSEOP_NAMESTRING{$$ = TrCreateValuedLeafOp 
(PARSEOP_NAMESTRING, (ACPI_NATIVE_INT) $1);}
|   |   
 ^
| /<>/generate/unix/iasl/obj/aslcompiler.y:1095:92: error: cast 
from pointer to integer of different size [-Werror=pointer-to-int-cast]
|  1095 | | PARSEOP_IO{$$ = TrCreateValuedLeafOp 
(PARSEOP_NAMESTRING, (ACPI_NATIVE_INT) "IO");}
|   |   
 ^
| /<>/generate/unix/iasl/obj/aslcompiler.y:1096:92: error: cast 
from pointer to integer of different size [-Werror=pointer-to-int-cast]
|  1096 | | PARSEOP_DMA   {$$ = TrCreateValuedLeafOp 
(PARSEOP_NAMESTRING, (ACPI_NATIVE_INT) "DMA");}
|   |   
 ^
| /<>/generate/unix/iasl/obj/aslcompiler.y:1097:92: error: cast 
from pointer to integer of different size [-Werror=pointer-to-int-cast]
|  1097 | | PARSEOP_IRQ   {$$ = TrCreateValuedLeafOp 
(PARSEOP_NAMESTRING, (ACPI_NATIVE_INT) "IRQ");}
|   |   
 ^
| /<>/generate/unix/iasl/obj/aslcompiler.y:1098:92: error: cast 
from pointer to integer of different size [-Werror=pointer-to-int-cast]
|  1098 | | PARSEOP_FOR   {$$ = TrCreateValuedLeafOp 
(PARSEOP_NAMESTRING, (ACPI_NATIVE_INT) "FOR");}
|   |   
 ^
| /<>/generate/unix/iasl/obj/aslcompiler.y:1109:41: error: cast 
from pointer to integer of different size [-Werror=pointer-to-int-cast]
|  1109 | (ACPI_NATIVE_INT) 
AslCompilerlval.s);}
|   | ^
| /<>/generate/unix/iasl/obj/aslcompiler.y:1482:41: error: cast 
from pointer to integer of different size [-Werror=pointer-to-int-cast]
|  1482 | (ACPI_NATIVE_INT) 
AslCompilerlval.s);}
|   | ^
| obj/acpiexec ../../../source/components/dispatcher/dswload.c

https://buildd.debian.org/status/fetch.php?pkg=acpica-unix=mips64el=20200925-1=1612716867=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#982417: Python louvain packages naming confusion.

[Diane Trout]

> 
> In the short term I recommend fixing this by adding a file to the
> Debian python-louvain package named "debian/tests/autopkgtest-pkg-
> python.conf" with the contents "import_name = community"
> 

How about renaming the current python3-louvain package to 
python3-community-louvain using a normal transition package.

(I got the new name from wRAR pointing out that upstream even suggests
"import community as community_louvain")

Then I can submit the other louvain package using a binary package name
of python3-louvain-igraph.

Eventually we can just drop the python3-louvain package in favor of the
more specific names.

Diane

Bug#982464: subversion: CVE-2020-17525: Remote unauthenticated denial-of-service in Subversion mod_authz_svn

[Salvatore Bonaccorso]

Hi James,

On Wed, Feb 10, 2021 at 03:20:22PM -0500, James McCoy wrote:
> On Wed, Feb 10, 2021 at 03:36:11PM +0100, Salvatore Bonaccorso wrote:
> > The following vulnerability was published for subversion.
> > 
> > CVE-2020-17525[0]:
> > | Remote unauthenticated denial-of-service in Subversion mod_authz_svn
> 
> I'll have uploads ready for this tonight to both sid and buster.  I'll
> send the debdiff for review before uploading to buster-security.

Ack, thank you!

Regards,
Salvatore

Bug#982464: subversion: CVE-2020-17525: Remote unauthenticated denial-of-service in Subversion mod_authz_svn

[James McCoy]

On Wed, Feb 10, 2021 at 03:36:11PM +0100, Salvatore Bonaccorso wrote:
> The following vulnerability was published for subversion.
> 
> CVE-2020-17525[0]:
> | Remote unauthenticated denial-of-service in Subversion mod_authz_svn

I'll have uploads ready for this tonight to both sid and buster.  I'll
send the debdiff for review before uploading to buster-security.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#979841: rdflib: diff for NMU version 5.0.0-1.1

[Sebastian Ramacher]

Control: tags 979841 + patch
Control: tags 979841 + pending

Dear maintainer,

I've prepared an NMU for rdflib (versioned as 5.0.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru rdflib-5.0.0/debian/changelog rdflib-5.0.0/debian/changelog
--- rdflib-5.0.0/debian/changelog	2020-12-11 23:51:02.0 +0100
+++ rdflib-5.0.0/debian/changelog	2021-02-10 21:06:36.0 +0100
@@ -1,3 +1,11 @@
+rdflib (5.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/tests: Update path for test runner, disable tests that require
+network access, and fix test dependencies (Closes: #979841)
+
+ -- Sebastian Ramacher   Wed, 10 Feb 2021 21:06:36 +0100
+
 rdflib (5.0.0-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru rdflib-5.0.0/debian/tests/control rdflib-5.0.0/debian/tests/control
--- rdflib-5.0.0/debian/tests/control	2020-12-11 23:51:02.0 +0100
+++ rdflib-5.0.0/debian/tests/control	2021-02-10 20:54:11.0 +0100
@@ -1,3 +1,3 @@
 Tests: python3
-Depends: @, python3-sparqlwrapper, python3-nose
+Depends: @, python3-setuptools, python3-sparqlwrapper, python3-nose, python3-requests
 Restrictions: allow-stderr
diff -Nru rdflib-5.0.0/debian/tests/python3 rdflib-5.0.0/debian/tests/python3
--- rdflib-5.0.0/debian/tests/python3	2020-12-11 23:51:02.0 +0100
+++ rdflib-5.0.0/debian/tests/python3	2021-02-10 21:04:00.0 +0100
@@ -5,4 +5,4 @@
 # verbosity set to 0 so that there's nothing on stderr and sadt is happy
 #TESTS_VERBOSITY=--verbosity=0
 #python2 ./run_tests.py $TESTS_VERBOSITY --with-doctest
-./run_tests_py3.sh
+python3 ./run_tests.py --exclude=test_sparql_service --exclude=test_conneg --exclude=test_xmlliterals


signature.asc
Description: PGP signature

Bug#980211: libextractor: FTBFS (flaky tests)

[Bertrand Marc]

Le 10/02/2021 à 15:29, John Scott a écrit :

According to upstream, the fix for this should've been included in the 1.11-1
upload. Can this issue be closed?

Indeed, the original issue reported in this bug was fixed in 1.11-1. However, the general issue of flaky tests is still there: 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libextractor.html


Would you consider this bug as fixed?

Cheers,
Bertrand

Bug#982059: manpages-de: procps: File sconflict between procps and manpages-de

[Craig Small]

For testing this I installed Procps and *all*of the generated man pages and
that seemed to be fine.

That's slightly different to the patch I put in the bug report but I
emailed Helge the difference.

- Craig

Bug#982493: openvswitch: CVE-2020-35498

[Salvatore Bonaccorso]

Source: openvswitch
Version: 2.15.0~git20210104.def6eb1ea+dfsg1-4
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2.10.6+ds1-0+deb10u1
Control: found -1 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12+deb10u2
Control: found -1 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12

Hi,

The following vulnerability was published for openvswitch.

CVE-2020-35498[0]:
| Packet parsing vulnerability

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-35498
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35498
[1] https://www.openwall.com/lists/oss-security/2021/02/10/4

Regards,
Salvatore

Bug#944386: autopkgtest: can autopkgtest-build-qemu create a QEMU/KVM image without requiring superuser privileges?

[Simon McVittie]

On Fri, 08 Nov 2019 at 23:59:48 +0100, Francesco Poli (wintermute) wrote:
> Its man page states:
> |  Note that you need to call this as root.
> 
> I guess this is because of vmdb2, which requires superuser privileges.

As a stopgap solution for this, the latest version in git will try to use
fakemachine(1) if you are not uid 0. fakemachine is currently only available
on amd64 (it has to make non-portable assumptions while building the
initramfs that it will use for the VM).

I think the long-term solution is to bootstrap from an official cloud
image or by running -build-qemu as root, then build any subsequent,
more minimal images by booting a pre-existing VM image and running
vmdb2 inside it (or by running whatever tool we use instead of vmdb2,
if the implementation of -build-qemu changes). This is how I do it in
.

smcv

Bug#982492: haskell-jwt: Wrong homepage

[Davide Prina]

Source: haskell-jwt
Version: 0.10.0-1
Severity: normal

I have see that the project homepage do not respond anymore:
https://bitbucket.org/ssaasen/haskell-jwt

I think that the homepage is now:
https://hackage.haskell.org/package/jwt

Ciao
Davide

Note: this is a simplified bug report that I use to report homepage 
problems found at https://repology.org/repository/debian_testing/problems

Bug#982465: Bug in r-base and r-cran-rcppparallel

[Bastian Blank]

On Wed, Feb 10, 2021 at 01:30:10PM -0600, Dirk Eddelbuettel wrote:
> Thanks for the CVE. I am happy to discuss this with R Core and one fellow in
> particular.
> Before I do so can you clarify what you think the issue is?  Loading from
> user directories as eg ~/R/lib/mypackage/libs/mypack.so ?

No, the problem is loading from ".", not a specific directory.

Bastian

-- 
Violence in reality is quite different from theory.
-- Spock, "The Cloud Minders", stardate 5818.4

Bug#982491: haskell-incremental-parser: Wrong homepage + new version

[Davide Prina]

Source: haskell-incremental-parser
Version: 0.4.0.2-1
Severity: normal

I have see that the project homepage do not respond anymore:
https://patch-tag.com/r/blamario/incremental-parser/wiki/

I think that the homepage is now:
https://github.com/blamario/incremental-parser
https://hackage.haskell.org/package/incremental-parser

I think here there is a new versione: 0.5.0.1

Ciao
Davide

Note: this is a simplified bug report that I use to report homepage 
problems found at https://repology.org/repository/debian_testing/problems

Bug#982490: haskell-hsh: Wrong homepage

[Davide Prina]

Source: haskell-hsh
Version: 2.1.3-4
Severity: normal

I have see that the project homepage do not respond anymore:
https://wiki.github.com/jgoerzen/hsh

I think that the homepage is now:
https://github.com/jgoerzen/hsh
https://hackage.haskell.org/package/HSH

Ciao
Davide

Note: this is a simplified bug report that I use to report homepage 
problems found at https://repology.org/repository/debian_testing/problems

Bug#982465: Bug in r-base and r-cran-rcppparallel

[Dirk Eddelbuettel]

Hi Bastian,

On 10 February 2021 at 20:03, Bastian Blank wrote:
| Hi Dirk
| 
| On Wed, Feb 10, 2021 at 12:18:04PM -0600, Dirk Eddelbuettel wrote:
| > As for your suggested patch to R's own dynload.c:  that is very well tested
| > and robust system code I do not have any real intention of changing because
| > one package out of 17k at CRAN is having hickups under one (maybe 
suboptimal)
| > Debian config.
| 
| I really doubt that.  Because the code as it is right now can't be used
| in any sensible way without an absolute path.  To load anything from
| /usr/lib*, which is the primary use of dlopen, you need to hardcode the
| path.
| 
| The documentation does not even mention any such specific differences to
| how the system loader works on non-Windows.[1]  So I doubt this us used
| often or at all.
| 
| Also this is the same problem as CVE-2016-1238, see DSA-3628[2].  I
| can provide a CVE id for R.

Thanks for the CVE. I am happy to discuss this with R Core and one fellow in
particular.

Before I do so can you clarify what you think the issue is?  Loading from
user directories as eg ~/R/lib/mypackage/libs/mypack.so ?

That is _bread and butter_ for R.  Also the `.libPaths()` (for where packages
are looked for, leading then for those with native code to loading of their
shared libs) never has "." on.

Dirk
 
| Regards,
| Bastian
| 
| [1]: 
https://www.rdocumentation.org/packages/base/versions/3.6.2/topics/dyn.load
| [2]: https://www.debian.org/security/2016/dsa-3628
| -- 
| There is a multi-legged creature crawling on your shoulder.
|   -- Spock, "A Taste of Armageddon", stardate 3193.9

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#979819: Raise severity, cannot create venv for any older python versions!

[Stefano Rivera]

Hi Kostis (2021.01.21_05:52:57_-0800)

I think there are two issues to solve here:

1: Tighten the dependency on python3-distutils, to avoid this happening.

2: The thing that prints out the instructions to install python3-venv
   could be more intelligent about when it prints the message. We could
   probe for the installation of the package, e.g. probe for the
   existence of /usr/lib/python3.X/ensurepip/__main__.py or try to
   import it.

Otherwise we print a message that is more confusing than helpful:

> For instance in "sid":
> 
> $  python3.8 -m venv .venv
> The virtual environment was not created successfully because
> ensurepip is not
> available.  On Debian/Ubuntu systems, you need to install the python3-venv
> package using the following command.
> 
> apt-get install python3-venv
> 
> You may need to use sudo with that command.  After installing the
> python3-venv
> package, recreate your virtual environment.
> 
> Failing command: ['/home/user/.venv/bin/python3.8', '-Im',
> 'ensurepip', '--upgrade', '--default-pip']

> 
> It's only when you try the failing command that you get the root cause:
> 
> $ /home/user/.venv/bin/python3.8 -Im ensurepip --upgrade --default-pip
> Traceback (most recent call last):
>   File "", line 6, in 
>   File "/usr/lib/python3.8/runpy.py", line 207, in run_module
> return _run_module_code(code, init_globals, run_name, mod_spec)
>   File "/usr/lib/python3.8/runpy.py", line 97, in _run_module_code
> _run_code(code, mod_globals, init_globals,
>   File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
> exec(code, run_globals)
>   File "/tmp/tmpybc1t180/pip-20.1.1-py2.py3-none-any.whl/pip/__main__.py",
> line 23, in 
>   File "", line 259, in load_module
>   File 
> "/tmp/tmpybc1t180/pip-20.1.1-py2.py3-none-any.whl/pip/_internal/cli/main.py",
> line 10, in 
>   File "", line 259, in load_module
>   File 
> "/tmp/tmpybc1t180/pip-20.1.1-py2.py3-none-any.whl/pip/_internal/cli/autocompletion.py",
> line 9, in 
>   File "", line 259, in load_module
>   File 
> "/tmp/tmpybc1t180/pip-20.1.1-py2.py3-none-any.whl/pip/_internal/cli/main_parser.py",
> line 7, in 
>   File "", line 259, in load_module
>   File 
> "/tmp/tmpybc1t180/pip-20.1.1-py2.py3-none-any.whl/pip/_internal/cli/cmdoptions.py",
> line 19, in 
> ModuleNotFoundError: No module named 'distutils.util'
> Traceback (most recent call last):
>   File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
> return _run_code(code, main_globals, None,
>   File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
> exec(code, run_globals)
>   File "/usr/lib/python3.8/ensurepip/__main__.py", line 5, in 
> sys.exit(ensurepip._main())
>   File "/usr/lib/python3.8/ensurepip/__init__.py", line 265, in _main
> return _bootstrap(
>   File "/usr/lib/python3.8/ensurepip/__init__.py", line 183, in _bootstrap
> return _run_pip(args + _PROJECTS, additional_paths)
>   File "/usr/lib/python3.8/ensurepip/__init__.py", line 61, in _run_pip
> return subprocess.run([sys.executable, "-c", code],
> check=True).returncode
>   File "/usr/lib/python3.8/when trying the", in run
> raise the real cause CalledProcessError(retcode, process.args,
> subprocess.CalledProcessError: Command
> '['/home/user/.venv/bin/python3.8', '-c', '\nimport runpy\nimport
> sys\nsys.path =
> [\'/tmp/tmpybc1t180/setuptools-44.0.0-py2.py3-none-any.whl\',
> \'/tmp/tmpybc1t180/pip-20.1.1-py2.py3-none-any.whl\',
> \'/tmp/tmpybc1t180/pkg_resources-0.0.0-py2.py3-none-any.whl\'] +
> sys.path\nsys.argv[1:] = [\'install\', \'--no-cache-dir\',
> \'--no-index\', \'--find-links\', \'/tmp/tmpybc1t180\', \'--upgrade\',
> \'setuptools\', \'pip\', \'pkg_resources\']\nrunpy.run_module("pip",
> run_name="__main__", alter_sys=True)\n']' returned non-zero exit
> status 1.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#982489: haskell-hashmap: Wrong homepage

[Davide Prina]

Source: haskell-hashmap
Version: 1.3.3-3
Severity: normal

I have see that the project homepage do not respond anymore:
http://git.auryn.cz/haskell/hashmap/

I think that the homepage is now:
https://hackage.haskell.org/package/hashmap
https://github.com/foxik/hashmap

note that on github it say: "Deprecated in favor of unordered-containers"

Ciao
Davide

Note: this is a simplified bug report that I use to report homepage 
problems found at https://repology.org/repository/debian_testing/problems

Bug#982488: RFS: python-imgviz/1.2.5+ds-1 -- Image Visualization Tools (Python 3)

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-imgviz":

 * Package name: python-imgviz
   Version : 1.2.5+ds-1
   Upstream Author : Kentaro Wada
 * URL : https://github.com/wkentaro/imgviz
 * License : BSD-3-clause, MIT
 * Vcs : https://salsa.debian.org/myczko-guest/imgviz
   Section : python

It builds those binary packages:

  python3-imgviz - Image Visualization Tools (Python 3)

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


  https://mentors.debian.net/package/python-imgviz/

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


  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-imgviz/python-imgviz_1.2.5+ds-1.dsc


Changes since the last upload:

 python-imgviz (1.2.5+ds-1) experimental; urgency=medium
 .
   * New upstream version.
   * Bump standards version to 4.5.1.

Regards,
--
  Gürkan Myczko

Bug#982487: RFS: sasm/3.12.0-1 -- simple IDE for NASM, GAS and FASM assembly languages

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: sasm
   Version : 3.12.0-1
   Upstream Author : Dmitriy Manushin 
 * URL : https://github.com/Dman95/SASM
 * License : GPL-3+, BSD-3-clause
 * Vcs : https://salsa.debian.org/myczko-guest/sasm
   Section : devel

It builds those binary packages:

  sasm - simple IDE for NASM, GAS and FASM assembly languages

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/s/sasm/sasm_3.12.0-1.dsc


Changes since the last upload:

 sasm (3.12.0-1) experimental; urgency=medium
 .
   * New upstream version.
   * d/upstream/metadata: added.
   * d/control: added Rules-Requires-Root.
   * Bump debhelper version to 13, drop d/compat.
   * Bump standards version to 4.5.1.
   * d/watch: drop template.
   * d/copyright: update year and set Upstream-Contact.

Regards,
--
  Gürkan Myczko

Bug#982486: haskell-fdo-notify: Wrong homepage

[Davide Prina]

Source: haskell-fdo-notify
Version: 0.3.1-11
Severity: normal

I have see that the project homepage do not respond anymore:
https://bitbucket.org/taejo/fdo-notify/

I think that the homepage is now:
https://hackage.haskell.org/package/fdo-notify

Ciao
Davide

Note: this is a simplified bug report that I use to report homepage 
problems found at https://repology.org/repository/debian_testing/problems

Bug#982321: libcdparanoia-dev: overly generic header name: /usr/include/utils.h

[Sebastian Ramacher]

Control: tags -1 + patch

On 2021-02-08 20:46:54 +0100, Andreas Beckmann wrote:
> Package: libcdparanoia-dev
> Version: 3.10.2+debian-13
> Severity: serious
> Tags: sid bullseye
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package uses a very generic
> header file name that now clashes with other packages:
> 
> /usr/include/utils.h

The file is not used by any of the reverse dependencies, so the attached
patch is enough.

Cheers
-- 
Sebastian Ramacher
diff -Nru cdparanoia-3.10.2+debian/debian/libcdparanoia-dev.install 
cdparanoia-3.10.2+debian/debian/libcdparanoia-dev.install
--- cdparanoia-3.10.2+debian/debian/libcdparanoia-dev.install   2018-01-30 
06:28:04.0 +0100
+++ cdparanoia-3.10.2+debian/debian/libcdparanoia-dev.install   2021-02-09 
21:10:51.0 +0100
@@ -1,3 +1,3 @@
-/usr/include
+/usr/include/cdda_*
 /usr/lib/*/*.a
 /usr/lib/*/*.so

Bug#982465: Bug in r-base and r-cran-rcppparallel

[Kevin Ushey]

Perhaps I'm misunderstanding, but there is a Debian patch for RcppParallel here:

https://sources.debian.org/patches/r-cran-rcppparallel/5.0.2+dfsg-3/use_debian_packaged_libtbb.patch/

and all that does is force RcppParallel to use the Debian-provided
copy of TBB as opposed to the version normally bundled and installed
by RcppParallel itself.

Is the implied bug in the RcppParallel patch, or in RcppParallel itself?

Best,
Kevin

On Wed, Feb 10, 2021 at 10:18 AM Dirk Eddelbuettel  wrote:
>
>
> Hi Bastian,
>
> Thanks for taking the time to propose a bug report.
>
> However (and please see below) I don't think this is the way forward. There
> have been a lot of recent changed in RcppParallel upstream (as I lurk on the
> GH repo which is part of our Rcpp org), and maybe some of these things will
> be different under the as-of-right-now-still-unreleased version 5.1.0 of
> RcppParallel. I am CCing its (upstream) maintainer / core developer who is
> also a friend and Rcpp collaborator. In the meantime please see
> https://github.com/RcppCore/RcppParallel/blob/master/inst/NEWS
>
> As for your suggested patch to R's own dynload.c:  that is very well tested
> and robust system code I do not have any real intention of changing because
> one package out of 17k at CRAN is having hickups under one (maybe suboptimal)
> Debian config.
>
> Maybe Andreas (for r-cran-rcppparallel) should talk to Kevin here to see what
> if anything could or should be changed.
>
> As for ~ expansion, we usually do that _before_ calling dyn.load() and
> passing paths on to other C level functions:
>
>> Sys.glob("~/.Rprofile")
>[1] "/home/edd/.Rprofile"
>>
>
> I would be happy to take a patch forward to R Core and fend for it, as we
> have in fact done in the past, but I think I would need to see a stronger
> case of why we would all of a sudden inject a getcwd() here.  Happy to chat
> more and hear real arguments if there are any.
>
> Cheers,  Dirk
>
> On 10 February 2021 at 18:55, Bastian Blank wrote:
> | Control: clone -1 -2
> | Control: reassign -1 r-base 4.0.3-1
> | Control: retitle -1 r-base: dyn.load not useful for system libraries
> | Control: affects -1 r-cran-rcppparallel 5.0.2+dfsg-3
> | Control: severity -1 important
> | Control: reassign -2 r-cran-rcppparallel 5.0.2+dfsg-3
> | Control: retitle -2 r-cran-rcppparallel: generates broken load path for 
> libtbb and fails on several architectures
> | Control: severity -2 serious
> |
> | Hi Andreas
> |
> | This are actually two bugs:
> | - r-base dyn.load not accepting relative library names on Linux systems
> |   and
> | - r-cran-rcppparallel trying to workaround the bug in dyn.load by
> |   deducting the full path of libtbb from the architecture instead of the
> |   correct multiarch setting and failing.
> |
> | This has nothing to do with r-cran-rstan or r-cran-rstanarm, but it
> | seems to be the first one to find out.  I've attached patches to fix
> | both problems, properly re-assigned and adjusted the bugs.
> |
> | This behaviour of R dyn.load might even be considered a security
> | vulnerability, because loading libraries from the working directory is a
> | problem.
> |
> | Bastian
> |
> | --
> | Kirk to Enterprise -- beam down yeoman Rand and a six-pack.
> | x[DELETED ATTACHMENT r-base_4.0.3-1.1.debdiff, plain text]
> | x[DELETED ATTACHMENT r-cran-rcppparallel_5.0.2+dfsg-3.1.debdiff, plain text]
>
> --
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#958597: Build-Depends on dh-systemd is back

[Daniel Schepler]

found 958597 1.7.6-1
thanks

It looks like the 1.7.6-1 upload of src:pmacct unintentionally added
the Build-Depends on dh-systemd back in.
-- 
Daniel Schepler

Bug#982465: Bug in r-base and r-cran-rcppparallel

[Bastian Blank]

Hi Dirk

On Wed, Feb 10, 2021 at 12:18:04PM -0600, Dirk Eddelbuettel wrote:
> As for your suggested patch to R's own dynload.c:  that is very well tested
> and robust system code I do not have any real intention of changing because
> one package out of 17k at CRAN is having hickups under one (maybe suboptimal)
> Debian config.

I really doubt that.  Because the code as it is right now can't be used
in any sensible way without an absolute path.  To load anything from
/usr/lib*, which is the primary use of dlopen, you need to hardcode the
path.

The documentation does not even mention any such specific differences to
how the system loader works on non-Windows.[1]  So I doubt this us used
often or at all.

Also this is the same problem as CVE-2016-1238, see DSA-3628[2].  I
can provide a CVE id for R.

Regards,
Bastian

[1]: https://www.rdocumentation.org/packages/base/versions/3.6.2/topics/dyn.load
[2]: https://www.debian.org/security/2016/dsa-3628
-- 
There is a multi-legged creature crawling on your shoulder.
-- Spock, "A Taste of Armageddon", stardate 3193.9

Bug#982059: manpages-de: procps: File sconflict between procps and manpages-de

[Sedat Dilek]

user$ sudo LC_ALL=C dpkg -i manpages-de_4.9.1-2.1~dileks_all.deb
(Reading database ... 341292 files and directories currently installed.)
Preparing to unpack manpages-de_4.9.1-2.1~dileks_all.deb ...
Unpacking manpages-de (4.9.1-2.1~dileks) ...
Setting up manpages-de (4.9.1-2.1~dileks) ...
Processing triggers for man-db (2.9.4-1) ...

root# dpkg -l | egrep 'manpages-de|procps|psmisc' | awk '/^ii/ {print
$1 " " $2 " " $3}' | column -t
ii  libprocps8:amd64  2:3.3.17-2
ii  manpages-de   4.9.1-2.1~dileks
ii  manpages-dev  5.10-1
ii  procps2:3.3.17-2
ii  psmisc23.4-2

- Sedat -

Bug#963025: (no subject)

[Jean Baptiste Favre]

Got the same issue with latest kernel and iwlwifi firmware from sid

>  cat /proc/version
Linux version 5.10.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-10
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian)
2.35.1) #1 SMP Debian 5.10.12-1 (2021-01-30)

> dpkg -l firmware-iwlwifi
ii  firmware-iwlwifi 20201218-3   all  Binary firmware for Intel
Wireless cards

As far as I can tell, it only happens when trying to connect to a 5GHz
wifi network using 80mhz wide channel.
I updated my AP configuration to use only 20 or 40mhz channels and
everything works fine now.

I also found an old bug [1] describing the same issue, but it's stated
to be solved and has been closed.

Hope this can help,
Cheers,
Jean Baptiste

[1]: https://bugzilla.kernel.org/show_bug.cgi?id=205055



OpenPGP_signature
Description: OpenPGP digital signature