Bug#968360: RFP: gfeeds — RSS/Atom feed reader for GNOME

[Andrei POPESCU]

Control: reassign -1 wnpp
Control: severity -1 wishlist

On Jo, 13 aug 20, 16:16:20, Marek Ľach wrote:
> Package: gfeeds
> 
> RFP
> Severity: wnpp
> 
> A GNOME RSS/Atom feed  reader.
> 
> License: GPL
> 
> Source: https://gitlab.gnome.org/World/gfeeds
> 
> Package works much faster when native, as opposed to Flathub!
> 
> It'd be much appreciated, if also packaged for aarch64. Sincere thanks.

-- 
Looking after bugs filled against unknown packages


signature.asc
Description: PGP signature

Bug#968295: additional content - what may of caused the issue

[Andrei POPESCU]

Control: reassign -1 cryptsetup-bin

Hello,

As there is no such package as 'lvm' your report is currently not 
assigned to any package.

Without being familiar with LVM and cyrptsetup, based on below I'm 
guessing your problem is related to encryption rather than lvm, so I'm 
tentatively reassigning this to cryptsetup-bin. If my guess was wrong 
the maintainer will reassign as needed.

Kind regards,
Andrei

On Mi, 12 aug 20, 21:24:10, Andrew P wrote:
> I found the following notes which may explain what caused this:
> 
> I installed pdftk per below (included the messages which were received and
> my response, left out some usual context as im typing this on mobile)
> 
> sudo apt-get install pdftk
> 
> You might want to run 'apt--fix-broken install' to correct these. The
> following packages have
> unmet dependencies:
> cryptsetup-run : depends: cryptsetup-bin (>=2:1.6.0) but it is not going to
> be installed
> pdftk: depends: pdftk-java but it is not going to be installed
> 
> 
> 
> E: unmet dependencies. Try 'apt --fix-broken install' with no packages (or
> specify a solution).
> 
> so i ran
> 
> sudo apt --fix-broken install
> 
> returned:
> 
> The following additional pakcages will be installed:
> cryptsetup-bin
> The following NEW packages will be installed cryptsetup-bin
> 0 upgraded, 1 newly installed, 0 to remove and 46 not upgraded.
> 
> Need to get 303Kb of archives.
> After this operation 1,514kB of additional disk space will be used.  do you
> want to continue? Y
> 
> Get:1
> 
> downloaded  /debian buster/main amd64/cryptsetup-bin
> (cryptsetup-bin_2%3a2.1.0-5+deb10u2_amd64.deb ...
> 
> unpacked...
> 
> set up
> 
> processing triggers for libc-bin (2.28-10)...
> Processing triggers for man-db (2.8.5-2)...
> processing triggers for initramfs-tools (0.133+deb10u1)...
> 
> Update-initramfs: Generating /boot/initrd.img-4.19.0-9-amd64
> 
> Then my notes took me into installing pdftk, which included installing and
> configuring pdftk-java and pdftk_2.02-5_amd64.deb and process triggers for
> man-db.
> 
> 
> still given the above im rather novice and unsure what needs to be done to
> fix it...

-- 
Looking after bugs filled against unknown packages


signature.asc
Description: PGP signature

Bug#963659: pybind11: FTBFS with Sphinx 3.1: File "/usr/lib/python3/dist-packages/sphinx/domains/c.py", line 3093, in object_type / raise NotImplementedError()

[Drew Parsons]

Source: pybind11
Followup-For: Bug #963659

The new sphinx has various problems.  Let's wait for pybind11 3.2.1
and see if that fixes things.

Bug#951748: dh-python: subst emission results in dpkg-gencontrol warning in absence of deprecated field

[Nick Black]

Do you see a problem with the provided patch? Have I
misunderstood the problem?

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.

Bug#318884: xfig: Xfig draws a figure 5 times on start-up

[G Kochanski]

The files that give the gray zone problem are pretty similar to the one I
sent you.   Portrait files, with a lot of polygons.
I looked at dmesg, syslog, and Xorg logs,and I didn't see any suspicious
log lines.
Nor did Xfig dump anything particularly suspicious on the stderr:

xfig cb_it2.fig
no non-UTF-8 locale found, try setting XFIG_LC_CTYPE, if you have trouble
with your charset

So, I'm not sure what else to say.

On Thu, Aug 13, 2020 at 4:16 AM Roland Rosenfeld  wrote:

> Hi Greg!
>
> On Mi, 12 Aug 2020, G Kochanski wrote:
>
> > Sure, here's a video. You can see some behaviors more easily that
> way.
> > https://photos.app.goo.gl/AboMENDfpf8aNGsE9
>
> Okay, seems you are using a much smaller screen than mine, which
> changes behavior a little.
> The problem with the figure shown below the bottom window border is
> that your FIG file seems to portrait mode where the figure is placed
> at the bottom of the sheet.  With the example cb_it3.fig I can work
> around this issue here by calling xfig with the -geometry option to
> extend the window size (or by manually resizing the window).
> Except this Ctrl-Z is a great option to zoom into the figure and fit
> the image to the window size.
>
> About the gray zone: I can hardly reproduce this here.  It may be
> depending on your screen size, maybe in combination with the window
> manager.
> I only saw this when I try to set the window size via xrdb in
> Xresources like this:
> Fig.geometry:   1300x1300+0+0
> Then I see a grey area on the right of the layers and below the bottom
> menu, but when calling xfig on command line, it warns me that this is
> a bad idea:
> "Don't specify Fig.geometry in the resources.  The xfig window may not
> appear
> correctly if this resource is specified."
>
> But I think, that this isn't exactly the behavior you observe.
> As far as I can see in the video, this doesn't happen on all FIG
> files, but only on some of them.  Do the problematic files have some
> commonality?
>
> Greetings
> Roland
>

Bug#968380: O: apt-dpkg-ref -- APT, Dpkg Quick Reference sheet

[Boyuan Yang]

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

I intend to orphan the apt-dpkg-ref package.

As indicated in https://bugs.debian.org/964020 , this package needs some
refreshing both on the content side and on the packaging side.

The package description is:
 A quick lookup chart with various APT and dpkg options for handy reference,
 for those who haven't quite memorized the most commonly used commands.
 .
 This package will generate the documentation in different formats, such as
 HTML and PDF.

Bug#968371: Acknowledgement (mailman3: NNTP Gateway'ing fails and causes message to not go out via email either)

[Athanasius]

  Having figured out how to get a test mailman3 instance up using latest
git master I can confirm the gating of mailinglist emails to NNTP is
working there.

  I guess I'll see if I can sanely git bisect to when they fixed this.

-- 
- Athanasius = Athanasius(at)miggy.org / https://miggy.org/
  GPG/PGP Key: https://miggy.org/gpg-key
   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME

Bug#746966: HiDPI support

[Ben Hutchings]

On Tue, 2020-08-04 at 17:39 -0500, Diego Escalante Urrelo wrote:
[...]
> MIN_WIDTH_HIDPI=1600
> virtual_size=/sys/class/graphics/fb0/virtual_size
> 
> if [ "$kernel" = linux -a -e "$virtual_size" ]; then
> width=`cut -d',' -f2 < "$virtual_size"`
> 
> if [ "$width" -ge "$MIN_WIDTH_HIDPI" ]; then
> FONTSIZE="16x32"
> fi
[...]

You have consistently written "width" here where you mean "height".

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.




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

Bug#968379: wireshark-common: versioned dependency on libsystemd0 breaks installability with elogind

[Thorsten Glaser]

Package: wireshark-common
Version: 3.2.6-1
Severity: important
X-Debbugs-Cc: t...@mirbsd.de

I cannot upgrade wireshark-common (and thus wireshark-qt) from 3.2.5-1
to 3.2.6-1 because the latter introduced a version into the libsystemd0
dependency. This seems to have been done with no reason, considering it
is not documented in the Debian changelog.

Please revert this, because otherwise, wireshark-qt is not installable
on systemd-less systems.

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages wireshark-common depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libc6  2.31-3
ii  libcap21:2.42-2
ii  libcap2-bin1:2.42-2
ii  libelogind0 [libsystemd0]  243.7-1+debian1
ii  libgcrypt201.8.6-2
ii  libglib2.0-0   2.64.4-1
ii  libmaxminddb0  1.3.2-1
ii  libnl-3-2003.4.0-1+b1
ii  libnl-genl-3-200   3.4.0-1+b1
ii  libpcap0.8 1.9.1-4
ii  libspeexdsp1   1.2~rc1.2-1.1
ii  libssh-gcrypt-40.9.4-1
ii  libwireshark13 3.2.6-1
ii  libwiretap10   3.2.6-1
ii  libwsutil113.2.6-1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages wireshark-common recommends:
pn  wireshark | tshark  

wireshark-common suggests no packages.

-- debconf information:
  wireshark-common/setcap-failed:
* wireshark-common/install-setuid: true
  wireshark-common/group-is-user-group:
  wireshark-common/addgroup-failed:
  wireshark-common/group-removal-failed:

Bug#968199: Set up /dev/stdin and others

[Thorsten Glaser]

severity 968199 important
tags 968199 + pending
thanks

On Fri, 14 Aug 2020, gregor herrmann wrote:

> > I’ll have a look at it. If nobody complains quickly enough,
> > I will team-upload a fix tonight.
> 
> Thanks alot!

Testing a fix already…

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!

Bug#968199: Set up /dev/stdin and others

[gregor herrmann]

On Fri, 14 Aug 2020 01:39:27 +0200, Thorsten Glaser wrote:

> > Thanks for filing this bug; I was also bitten by #967546 after a
> > reboot and by all kind of fun with a missing /dev/fd.
> … heh, /dev/std* and /dev/fd are indeed missing. Fuck.
> This is going to break all kinds of things.

Indeed.
 
> > And I guess this should technically go into the initscripts package
> > and not sysvinit-core. - /etc/init.d/mountkernfs.sh and
> > /etc/init.d/mountdevsubfs.sh do similar things currently …
> I’ll have a look at it. If nobody complains quickly enough,
> I will team-upload a fix tonight.

Thanks alot!


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#907576: . ITP: dream --A Software Digital Radio Mondiale

[GMiller]

TNX Christoph

OK I have just established an account on Salsa. The particulars are:

Full Name
Garie Miller

Username
GMiller

Email
gmill...@protonmail.com

I don't think I registered before unless it was in connection with the 
Multimedia Team.

Let me read up on the procedure then I will push my Dream stuff up. It may take 
me a few days. I suppose someone will then need to merge. Then later a sponsor.

Here is a summary on Dream as best I know. I worked it locally mostly following 
the Debmake/Debuild procedure 'Guide for Debian Maintainers' M262019. The 
Debian and Docs directories are complete (with lintian) barring last minute 
tweaking. I believe src includes commits thru 1339, which best I can tell is 
vital to support the the new codec and maybe other problems. Last I checked 
SourceForge there has been no activity since 1339 and February.

Anyway, during 'Debuild' object files are generated but compilation fatally 
stops with file GUI-QT/EvaluationDlg.cpp (I will include some screenshots). The 
compiler declares this an illegal cast (this in old code dating to 2000. Maybe 
the compiler is getting stricter?) I would guess this issue is something like 
trying to make a positive real into an integer. But trying to debug and patch 
C+ code like this is getting over my head and I would like to solicit input 
from someone who KNOWS what they are doing. And there are likely to be more of 
these before it links.

The new codec 'libfdk-aac-dev 2.0.1' is currently in Sid. I have an RTL dongle 
here that I will use for on air testing if we succeed in producing a binary. If 
we get that far we can then decide if Dream is stable enough for Debian. I 
invite others to test and give their results too.

73

Garie Miller WB9AWA

Sent with [ProtonMail](https://protonmail.com) Secure Email.

Bug#968199: Set up /dev/stdin and others

[Thorsten Glaser]

On Fri, 14 Aug 2020, gregor herrmann wrote:

> On Mon, 10 Aug 2020 15:51:05 +0200, Matti Palmström wrote:
>
> > Since udev don't set up /dev/stdin and others any longer

I first read this as “doesn’t set up stdin any longer” and
thought it of low importance, but…

> > https://github.com/systemd/systemd/commit/6b2229c6c60d0486 could this be
> > moved to sysvinit-core (or similar package widely used) for those of us who
> > don't use systemd?
>
> Thanks for filing this bug; I was also bitten by #967546 after a
> reboot and by all kind of fun with a missing /dev/fd.

… heh, /dev/std* and /dev/fd are indeed missing. Fuck.
This is going to break all kinds of things.

> And I guess this should technically go into the initscripts package
> and not sysvinit-core. - /etc/init.d/mountkernfs.sh and
> /etc/init.d/mountdevsubfs.sh do similar things currently …

I’ll have a look at it. If nobody complains quickly enough,
I will team-upload a fix tonight.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general

Bug#968199: Set up /dev/stdin and others

[gregor herrmann]

On Mon, 10 Aug 2020 15:51:05 +0200, Matti Palmström wrote:

> Since udev don't set up /dev/stdin and others any longer
> https://github.com/systemd/systemd/commit/6b2229c6c60d0486 could this be
> moved to sysvinit-core (or similar package widely used) for those of us who
> don't use systemd?

Thanks for filing this bug; I was also bitten by #967546 after a
reboot and by all kind of fun with a missing /dev/fd.

FWIW, a temporary workaround seems to be something like

ln -sf /proc/self/fd /dev/fd
ln -sf fd/0 /dev/stdin
ln -sf fd/1 /dev/stdout
ln -sf fd/2 /dev/stderr

And I guess this should technically go into the initscripts package
and not sysvinit-core. - /etc/init.d/mountkernfs.sh and
/etc/init.d/mountdevsubfs.sh do similar things currently …

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#968378: transition: libraw

[Matteo F. Vescovi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

I'm filing this bug for a new transition of libraw package.

On July 23, 2020 the 0.20.0 stable version has been released by
upstream.

On August 04, 2020, after initial upload to experimental accepted by FTP
Masters, a couple of testing-purpose packages has been uploaded to
experimental, the first as first-hand attempt to check the packaging on
all architectures, the latter to fix a bunch of FTBFS due to C++
symbols.

So, following the auto-libraw checklist[1], here is the list of source
packages reverse-depending on libraw and the results of the builds:

 * deepin-image-viewer_5.0.0-1 => OK
 * efl_1.24.3-5 => OK
 * entangle_3.0-1 => OK
 * fotoxx_20.08-1 => OK
 * freeimage_3.18.0+ds2-5 => FTBFS (possibly LibRaw-related)
 * gegl_0.4.24-1 => OK
 * gthumb_3:3.8.0-2.1 => OK
 * hdrmerge_0.5+git20200117-2 => OK
 * krita_1:4.3.0+dfsg-1 => OK
 * kstars_5:3.4.3-1 => OK
 * libkf5kdcraw_20.04.3-1 => OK
 * luminance-hdr_2.6.0+dfsg-2 => OK
 * nomacs_3.12.0+dfsg-3 => OK
 * openimageio_2.1.18.1~dfsg0-1 => OK
 * shotwell_0.30.10-1 => OK
 * siril_0.9.12-3 => OK
 * theli_3.0.2-1.1 => FTBFS (possibly LibRaw-related)

Both FTBFS seem to be caused by some changes in libraw 0.20.0 compared
to older 0.19.x version.

Thanks for your time and patience.

mfv


[1] https://release.debian.org/transitions/html/auto-libraw.html


Ben file:

title = "libraw";
is_affected = .depends ~ "libraw19" | .depends ~ "libraw20";
is_good = .depends ~ "libraw20";
is_bad = .depends ~ "libraw19";


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

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

-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#968080: xfburn: Bug in the "A full, but erasable disc is in the drive" dialog

[René Kjellerup]

Thank you, for verifying.
a new update is present upstream, would you be able to retest?

On Wed, Aug 12, 2020 at 3:55 AM Job Bautista
 wrote:
>
> The bug is still in upstream's master branch.
>
> I attached a PNG screenshot in this email.
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, August 12, 2020 2:31 PM, René Kjellerup 
>  wrote:
>
> > if you have the option, and or the inclination could you clone master
> > from https://gitlab.xfce.org/apps/xfburn.git
> > and test if this is still an issue. As mentioned before I don't really
> > have any way of verifying the Blank Dialog yet
> >
> > I hope to get support in CDEmu for RW media that I could emulate
> > blanking consistently.
> >
> > On Sat, Aug 8, 2020 at 3:29 PM René Kjellerup rk.katana.st...@gmail.com 
> > wrote:
> >
> > > Thank you for the report,
> > > Unfortunately I have no RW media to verify the issue.
> > > It does sound like incorrect behavior and I will see if we can solve
> > > this with the next release,
> > > or at the very least suppress the ask for blanking when opening the
> > > blank disc dialog.
> > > On Sat, Aug 8, 2020 at 12:30 AM Job Bautista
> > > jobbautis...@protonmail.com wrote:
> > >
> > > > Package: xfburn
> > > > Version: 0.6.2-1
> > > > Severity: normal
> > > > Dear Maintainer,
> > > > When I try to blank my CD-RW disc, a pop-up dialog saying "A full but
> > > > erasable disc in the drive" appears. When I press yes, it will open 
> > > > another
> > > > Blank Disc window and the same dialog shows up again. It seems like I am
> > > > unable to blank the disc, but if I press no, the dialog disappears and 
> > > > I was
> > > > able to blank. So the blanking works, it's just annoying having to 
> > > > click no
> > > > to a dialog that wasn't supposed to appear.
> > > > Attached in this report is a PNG screenshot showing the bug.
> > > > -- System Information:
> > > > Distributor ID: Devuan
> > > > Description: Devuan GNU/Linux 4 (chimaera/ceres)
> > > > Release: testing/unstable
> > > > Codename: n/a
> > > > Architecture: x86_64
> > > > Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
> > > > Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> > > > Locale: LANG=en_PH.UTF-8, LC_CTYPE=en_PH.UTF-8 (charmap=UTF-8), 
> > > > LANGUAGE=en_PH:en
> > > > Shell: /bin/sh linked to /bin/dash
> > > > Init: sysvinit (via /sbin/init)
> > > > LSM: AppArmor: enabled
> > > > Versions of packages xfburn depends on:
> > > > ii libburn4 1.5.2-1
> > > > ii libc6 2.31-2
> > > > ii libexo-2-0 0.12.11-1
> > > > ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5
> > > > ii libglib2.0-0 2.64.4-1
> > > > ii libgstreamer-plugins-base1.0-0 1.16.2-4
> > > > ii libgstreamer1.0-0 1.16.2-2
> > > > ii libgtk-3-0 3.24.20-1
> > > > ii libgudev-1.0-0 233-1
> > > > ii libisofs6 1.5.2-1
> > > > ii libxfce4ui-2-0 4.14.1-1+b1
> > > > ii libxfce4util7 4.14.0-1
> > > > xfburn recommends no packages.
> > > > xfburn suggests no packages.
> > > > -- no debconf information
> > >
> > > --
> > > -- as life grows older, I gain experience.
> > > -- http://www.alchemiestick.net/
> >
> > --
> >
> > -- as life grows older, I gain experience.
> > -- http://www.alchemiestick.net/
>


-- 
-- as life grows older, I gain experience.
-- http://www.alchemiestick.net/

Bug#968377: libplacebo FTBFS: error: ‘VK_PHYSICAL_DEVICE_TYPE_END_RANGE’ undeclared

[Helmut Grohne]

Source: libplacebo
Version: 1.29.1+dfsg1-2
Severity: serious
Tags: ftbfs

libplacebo fails to build from source in unstable. A build log ends
with:

| /usr/bin/mips64el-linux-gnuabi64-gcc -Isrc/libplacebo.so.29.p -Isrc -I../src 
-I../src/include -I../subprojects/xtalloc/include -I../subprojects/bstr/include 
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wall -Wundef 
-Wshadow -Wparentheses -Wpointer-arith -D_ISOC99_SOURCE -D_GNU_SOURCE 
-D_XOPEN_SOURCE=700 -U__STRICT_ANSI__ -fvisibility=hidden -Wmissing-prototypes 
-Wno-pointer-sign -Werror=implicit-function-declaration 
-Werror=incompatible-pointer-types -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -fPIC -pthread -MD -MQ 
src/libplacebo.so.29.p/vulkan_context.c.o -MF 
src/libplacebo.so.29.p/vulkan_context.c.o.d -o 
src/libplacebo.so.29.p/vulkan_context.c.o -c ../src/vulkan/context.c
| ../src/vulkan/context.c: In function ‘pl_vulkan_choose_device’:
| ../src/vulkan/context.c:391:10: error: ‘VK_PHYSICAL_DEVICE_TYPE_END_RANGE’ 
undeclared (first use in this function); did you mean 
‘VK_PHYSICAL_DEVICE_TYPE_MAX_ENUM’?
|   391 | [VK_PHYSICAL_DEVICE_TYPE_END_RANGE+1]= {0},
|   |  ^
|   |  VK_PHYSICAL_DEVICE_TYPE_MAX_ENUM
| ../src/vulkan/context.c:391:10: note: each undeclared identifier is reported 
only once for each function it appears in
| ../src/vulkan/context.c:391:10: error: array index in initializer not of 
integer type
| ../src/vulkan/context.c:391:10: note: (near initialization for ‘types’)
| ninja: build stopped: subcommand failed.
| dh_auto_build: error: cd obj-mips64el-linux-gnuabi64 && LC_ALL=C.UTF-8 ninja 
-j1 -v returned exit code 1
| make: *** [debian/rules:7: binary-arch] Error 25
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

Reproducible by reproducible builds:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/libplacebo_1.29.1+dfsg1-2.rbuild.log.gz

Also seen by crossqa:
http://crossqa.debian.net/build/libplacebo_1.29.1+dfsg1-2_mipsel_20200710170355.log

Helmut

Bug#967118: 0ad: Unversioned Python removal in sid/bullseye

[Itms]

Hello,

I am a developer of 0ad and I am in charge of upgrading the SpiderMonkey 
library that we embed, which still depends on Python 2.


I confirm what smcv said: the presence of a working `python2.7` 
executable should be enough to build spidermonkey, and I do not think 
that third-party modules are necessary.


We are determined to remove our python2 dependency in our upcoming 
stable release, which is under active development. However, we will 
definitely not be able to get it out in time for the release of Debian 
bullseye. We hope that our latest stable version can be kept in 
bullseye, with our future release ready for bookworm.


Please let me know if I should post additional information to bug #936101.

Best regards,
Nicolas

Bug#968371: mailman3: NNTP Gateway'ing fails and causes message to not go out via email either

[Athanasius]

Package: mailman3
Version: 3.2.1-1
Severity: important

Dear Maintainer,

After importing lists from Mailman2.1 using the 'import21' module I
automatically had one list with settings to gateway to NNTP as expected.

Any email to that list with that configuration fails:

---
Aug 12 17:00:38 2020 (5717) ACCEPT: 
Aug 12 17:06:17 2020 (5717) ACCEPT: <20200812160616.e3aaorp5zhtjb...@fysh.org>
Aug 12 17:06:18 2020 (5721) fysh-annou...@fysh.org invalid FilterAction: discard
.  Treating as discard
Aug 12 17:06:18 2020 (5721) <20200812160616.e3aaorp5zhtjb...@fysh.org> discarded
 by "default-posting-pipeline" pipeline handler "mime-delete": The message's con
tent type was not explicitly allowed
Aug 12 17:06:18 2020 (5721) Uncaught runner exception: 'MailingList' object has 
no attribute 'nntp_host'
Aug 12 17:06:18 2020 (5721) Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 173, in 
_one_iteration
self._process_one_file(msg, msgdata)
  File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 266, in 
_process_one_file
keepqueued = self._dispose(mlist, msg, msgdata)
  File "/usr/lib/python3/dist-packages/mailman/runners/pipeline.py", line 37, 
in _dispose
process(mlist, msg, msgdata, pipeline)
  File "/usr/lib/python3/dist-packages/mailman/core/pipelines.py", line 50, in 
process
handler.process(mlist, msg, msgdata)
  File "/usr/lib/python3/dist-packages/mailman/handlers/to_usenet.py", line 53, 
in process
if not mlist.nntp_host:
AttributeError: 'MailingList' object has no attribute 'nntp_host'
---

This immediate problem is addressed upstream by:

59d8b47c432e43ce463cbb4a7aec649415d08702

Applying just the change to remove that conditional in to_usenet.py gets
past that point (and messages now make it out in email), but then the
code runs into another problem:

---
Aug 13 17:44:26 2020 (15817) ACCEPT: <20200813164426.ga15...@fysh.org>
Aug 13 17:44:27 2020 (15814) HyperKitty archived message <20200813164426.GA15940
@fysh.org> to https://www.fysh.org/mailman3/hyperkitty/list/testl...@fysh.org/me
ssage/OMXF2QRUZLZPO3WFZMXDBSW4QZTWO5HJ/
Aug 13 17:44:28 2020 (15819) <159733706828.15819.11534859148741658...@river.fysh
.org> NNTP unexpected exception for testl...@fysh.org
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/mailman/runners/nntp.py", line 77, in _di
spose
conn.post(fp)
  File "/usr/lib/python3.7/nntplib.py", line 916, in post
return self._post('POST', data)
  File "/usr/lib/python3.7/nntplib.py", line 902, in _post
if not line.endswith(_CRLF):
TypeError: endswith first arg must be str or a tuple of str, not bytes
---

Which appears to either be an error in nntplib, or a mis-use of it.

I'm running this on a production machine so can't easily play with
running mailman3 from source to see if they've fixed this upstream.  I
might find time to try it out on another machine.

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

Kernel: Linux 4.19.138-fysh-kvmguest (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mailman3 depends on:
ii  dbconfig-sqlite32.0.11+deb10u1
ii  debconf [debconf-2.0]   1.5.71
ii  logrotate   3.14.0-4
ii  lsb-base10.2019051400
ii  python3 3.7.3-1
ii  python3-aiosmtpd1.2-3
ii  python3-alembic 1.0.0-3
ii  python3-click   7.0-1
ii  python3-dnspython   1.16.0-1
ii  python3-falcon  1.0.0-2+b3
ii  python3-flufl.bounce3.0-1
ii  python3-flufl.i18n  2.0.1-1
ii  python3-flufl.lock  3.2-1
ii  python3-lazr.config 2.2-1
ii  python3-passlib 1.7.1-1
ii  python3-psycopg22.7.7-1
ii  python3-public  0.5-1
ii  python3-requests2.21.0-1
ii  python3-sqlalchemy  1.2.18+ds1-2
ii  python3-zope.component  4.3.0-1
ii  python3-zope.configuration  4.0.3-3
ii  python3-zope.event  4.2.0-1
ii  python3-zope.interface  4.3.2-1+b2
ii  ucf 3.0038+nmu1

Versions of packages mailman3 recommends:
ii  exim4-daemon-heavy [mail-transport-agent]  4.92-8+deb10u4

Versions of packages mailman3 suggests:
ii  chromium [www-browser]  83.0.4103.116-1~deb10u3
ii  elinks [www-browser]0.13~20190125-3
ii  links [www-browser] 2.18-2
ii  links2 [www-browser]   

Bug#949699: Patch from upstream for Ryzen 3000 CPUs

[Itms]

Hello,

If needed, here is the patch from upstream which cleanly applies to the 
latest stable release of 0ad.


Best regards,
Nicolas

From: Nicolas Auvray 
Date: Thu, 13 Aug 2020 18:27:44 +0200
Subject: Fix #949699 on 0.0.23b

---
 source/lib/sysdep/arch/x86_x64/cache.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/source/lib/sysdep/arch/x86_x64/cache.cpp 
b/source/lib/sysdep/arch/x86_x64/cache.cpp
index 1be905a..761254c 100644
--- a/source/lib/sysdep/arch/x86_x64/cache.cpp
+++ b/source/lib/sysdep/arch/x86_x64/cache.cpp
@@ -89,7 +89,8 @@ static x86_x64::Cache L1Cache(u32 reg, x86_x64::Cache::Type 
type)
 static const size_t associativityTable[16] =
 {
0, 1, 2, 0, 4, 0, 8, 0,
-   16, 0, 32, 48, 64, 96, 128, x86_x64::Cache::fullyAssociative
+   // TODO: The second '16' does not obey to the specifications and is 
only a workaround. For a correct implementation please look here: 
https://community.amd.com/thread/244207
+   16, 16, 32, 48, 64, 96, 128, x86_x64::Cache::fullyAssociative
 };
 
 static x86_x64::Cache L2Cache(u32 reg, x86_x64::Cache::Type type)
-- 

Bug#966649: [UDD] Upload_history table is currently empty

[Lucas Nussbaum]

On 12/08/20 at 14:59 +0200, Andreas Tille wrote:
> Hi again,
> 
> On Mon, Aug 03, 2020 at 11:20:21AM +0200, Andreas Tille wrote:
> > > > 'munge_ddc.py' has the following issues:
> > > > [...]
> > > > - it doesn't support xz email archives, so it's broken for recent
> > > >   archives
> > > 
> > > It used to work some months ago because it was relying on a huge
> > > debian-devel-changes.current. But ullmann ran out of disk space due to
> > > this.
> > 
> > Argh, to bad that disk space is an issue these days.
> >  
> > > > Do we have a plan to fix this?  I really need those Uploaders data to 
> > > > prepare
> > > > my DebConf20 talk.
> > > 
> > > Given your ongoing effort to port UDD to Python3, I think that the best
> > > plan is to do that, and port munge_dcc.py to Python3.
> > 
> > I'd do some 2to3 and simply start it - but its hard to do this on a
> > local box here since it seems to rely on data that are stored on
> > ullmann.  I also need to admit that I'm currently not able to spent lots
> > of time into it. 
> 
> Do you see any way I can help speeding up solving this issue?
> I have no idea about the actual code (not even who wrote it since
> its not in Git (couldn't we at least move a copy to UDD git and
> possibly symlink to it on ullmann to have some version control)
> and how to test it locally without breaking anything on ullmann?

Hi,

Well, why don't you look at the code? I think I provided the needed
details in the initial report? And you have access to the VM since you
are in the 'uddadm' group?

Lucas

Bug#968376: chroot postinst failure modes

[Ryan Finnie]

Package: raspi-firmware
Version: 1.20200601-2
Severity: important

/etc/kernel/postinst.d/z50-raspi-firmware will fail in the following
situations:

1) findmnt fails.  It attempts to mitigate this:

ROOTPART=`findmnt -n --output=source /`
if [ -z "$ROOTPART" ]; then ROOTPART=/dev/mmcblk0p2;fi

But findmnt will exit 1 and fail -e, so this is needed:

ROOTPART=`findmnt -n --output=source / || true`
if [ -z "$ROOTPART" ]; then ROOTPART=/dev/mmcblk0p2;fi

2) dtbs don't exist for kernel being considered:

  for dtb in ${dtb_path}/bcm*.dtb; do
[ -e "${dtb}" ] && cp "${dtb}" /boot/firmware/

[ will exit 1 in that case and fail -e, so we need to flip the test:

  for dtb in ${dtb_path}/bcm*.dtb; do
[ -e "${dtb}" ] || continue
cp "${dtb}" /boot/firmware/

Context: live-build pulls in all packages which have files in
/lib/firmware, so raspi-firmware is installed in the arm64/armel chroot
it's building, even though it's not necessarily targeting raspi hardware
or kernel.

Thank you!



signature.asc
Description: OpenPGP digital signature

Bug#956967: Patch from upstream for FTBFS with gcc-10

[Itms]

Hello,

I am a developer of 0ad. As noticed by Reiner, this is fixed upstream. 
As far as I can see, only a part of the upstream fix is necessary for 
patching the latest 0ad release. I am attaching a patch which should fix 
the issue for the Debian package.


We would like to offer any help we can in preventing the removal of 0ad 
from the repository. The latest release is a bit old and unfortunately 
our upcoming release will not be ready in time for the stabilization of 
Debian bullseye. However, the project is still very active and we would 
like to prevent a break in the availability of 0ad in your repos.


Thanks a lot for the maintaining work, do not hesitate to contact me if 
needed.


Best regards,
Nicolas


From: Nicolas Auvray 
Date: Thu, 13 Aug 2020 18:28:12 +0200
Subject: Fix #956967 on 0.0.23b

---
 .../FColladaPlugins/FArchiveXML/FAXPhysicsExport.cpp | 12 
 .../src/FColladaPlugins/FArchiveXML/FArchiveXML.h| 11 ++-
 2 files changed, 10 insertions(+), 13 deletions(-)

diff --git 
a/libraries/source/fcollada/src/FColladaPlugins/FArchiveXML/FAXPhysicsExport.cpp
 
b/libraries/source/fcollada/src/FColladaPlugins/FArchiveXML/FAXPhysicsExport.cpp
index e999c4e..4272a16 100644
--- 
a/libraries/source/fcollada/src/FColladaPlugins/FArchiveXML/FAXPhysicsExport.cpp
+++ 
b/libraries/source/fcollada/src/FColladaPlugins/FArchiveXML/FAXPhysicsExport.cpp
@@ -330,15 +330,3 @@ void 
FArchiveXML::WritePhysicsRigidBodyParameters(FCDPhysicsRigidBodyParameters*
}
 }
 
-template 
-xmlNode* FArchiveXML::AddPhysicsParameter(xmlNode* parentNode, const char* 
name, FCDParameterAnimatableT& value)
-{
-   xmlNode* paramNode = AddChild(parentNode, name);
-   AddContent(paramNode, FUStringConversion::ToString((TYPE&) value));
-   if (value.IsAnimated())
-   {
-   const FCDAnimated* animated = value.GetAnimated();
-   FArchiveXML::WriteAnimatedValue(animated, paramNode, name);
-   }
-   return paramNode;
-}
diff --git 
a/libraries/source/fcollada/src/FColladaPlugins/FArchiveXML/FArchiveXML.h 
b/libraries/source/fcollada/src/FColladaPlugins/FArchiveXML/FArchiveXML.h
index a20abcb..4f18cc0 100644
--- a/libraries/source/fcollada/src/FColladaPlugins/FArchiveXML/FArchiveXML.h
+++ b/libraries/source/fcollada/src/FColladaPlugins/FArchiveXML/FArchiveXML.h
@@ -553,7 +553,16 @@ public:
 
static void 
WritePhysicsRigidBodyParameters(FCDPhysicsRigidBodyParameters* 
physicsRigidBodyParameters, xmlNode* techniqueNode);
template 
-   static xmlNode* AddPhysicsParameter(xmlNode* parentNode, const char* 
name, FCDParameterAnimatableT& value);
+   static xmlNode* AddPhysicsParameter(xmlNode* parentNode, const char* 
name, FCDParameterAnimatableT& value) {
+   xmlNode* paramNode = AddChild(parentNode, name);
+   AddContent(paramNode, FUStringConversion::ToString((TYPE&) 
value));
+   if (value.IsAnimated())
+   {
+   const FCDAnimated* animated = value.GetAnimated();
+   FArchiveXML::WriteAnimatedValue(animated, paramNode, 
name);
+   }
+   return paramNode;
+   }
 
 
//
-- 

Bug#926331: warning: symlink leaves directory: /etc/postfix/./makedefs.out

[Christian Kujau]

The commit log of 36f00335 states:

 > Make makedefs.out no more be a conffile but still keep it
 > reachable at the old location via a symlink

Why do we need that symlink in /etc/postfix/ at all? Nothing in /usr/ 
seems to reference "makedefs.out", so can't we remove that symlink and the 
warning should go away?

FWIW, its only use seems so be to find out how Postfix was built, and to 
then reproduce the build:

 > Re: makedefs.out
 > https://marc.info/?l=postfix-users=143747602027291=2

Thanks,
Christian.

Bug#968375: scottfree: Crashes when restoring save file

[Colin Williams]

Package: scottfree
Version: 1.14-10+b1
Severity: important
Tags: newcomer

Dear Maintainer,


   * What led up to the situation? Attempting to restore any save file with the
command:  scottfree  

   * What exactly did you do (or not do) that was effective (or
 ineffective)? N/A

   * What was the outcome of this action? Program crashed with the message:
*** stack smashing detected ***:  terminated

   * What outcome did you expect instead? To resume a saved adventure.

Fix:  Rebuild the package with DEB_BUILD_OPTIONS="noopt", the program no longer
crashes and works as expected.



-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages scottfree depends on:
ii  libc62.28-10
ii  libncurses6  6.1+20181013-2+deb10u2
ii  libtinfo66.1+20181013-2+deb10u2

scottfree recommends no packages.

scottfree suggests no packages.

-- no debconf information

Bug#968368: ifenslave: Option bond-master fails to add interface to bond

[Sami Haahtinen]

Package: ifenslave
Version: 2.11
Severity: important
Tags: patch

The option bond-master doesn't add the defined interface to the bond due to
an incorrect variable in the if-up script and due to an incorrect ifquery
invocation.

The former issue is caused by code copied from the bond-slaves option,
which uses $slave variable to refer to the interface being added, while the
$1 argument should be used instead.

Latter issue is caused by incorrectly calling ifstate instead of ifquery
when verifying iface stanza for the master interface. Attached patch will
fix the issue.


ifenslave-args.diff
Description: Binary data

Bug#968260: libc6: breaks translations when changing the charset to ...//TRANSLIT

[Vincent Lefevre]

On 2020-08-13 15:13:18 +0200, Aurelien Jarno wrote:
> On 2020-08-12 05:13, Vincent Lefevre wrote:
> > Since the upgrade to 2.31-3, the translations are no longer working
> > in Mutt.
> > 
> > In my config, the charset gets automatically set to UTF-8//TRANSLIT
> > (possibly with something else instead of UTF-8). There is the same
> > issue with ISO-8859-1//TRANSLIT, but not with UTF-8 or ISO-8859-1.
[...]
> Thanks for the reproducer, I have been able to identify the broken
> function, I have reported the bug upstream as BZ#26383. While it is
> clearly a regression, please note that adding //TRANSLIT to the charset
> doesn't bring anything, as transliteration is always enabled for gettext
> messages.

Thanks. In case, this was not clear, I hadn't added //TRANSLIT for
gettext messages, but for general output of mail messages in the
terminal (as transliteration is not enabled by default for such
output). But it appears that the "charset" variable is used for
anything related to the terminal (which makes sense for users who
set this variable to correct the charset obtained by default from
the environment).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#966114: src:cyrus-imapd: Mail::JMAPTalk version 0.15 required--this is only version 0.13 at ./Cassandane/Cyrus/JMAPCore.pm

[Xavier]

Control: severity -1 important

Hi,

bug is now fixed in upstream test libraries.

> I must say I find it unacceptable that autopkgtests which are being
> used to test migration from Debian unstable to Debian testing to rely
> on code from random places on the Internet, which Debian Developers
> have no control over.

I understand your point of view. We found this way to reproduce upstream
test in this package that had no test before. What would be the best:
 * embed test libraries in source package (like apache2) ?
   + embed copies of dovecot and some other package that exists in
 Debian but with a different version ?
 -- or --
   + try to patch upstream test to use Debian packages in test ? (I
 tried without success)
 * remove autopkgtest files ?
 * render autopkgtest success "skippable" ?

Cheers,
Xavier

Bug#968265: g++: asymptote fails to compile on m68k

[Hilmar Preusse]

Control: forwarded -1 https://github.com/vectorgraphics/asymptote/issues/172

On 12.08.20 Hilmar Preusse (hill...@web.de) wrote:

> the package fails to build on m68k inside a qemu vm.  I'm able to
> reproduce the issue localle, a core dump was generated, here is the
> back trace.  The issue was first visible w/ 2.66-1.
> 
Forwarded to upstream for now.

H.
-- 
sigmentation fault


signature.asc
Description: PGP signature

Bug#968374: transition: proftpd-dfsg

[Hilmar Preusse]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

This transition was already started by the recent proftpd upload, but is
not caught caught automatically since it is a virtual package name that
has changed.

Ben file:

title = "proftpd-dfsg";
is_affected = .depends ~ /proftpd-abi-/;
is_good = .depends ~ /proftpd-abi-1.3.7a/;
is_bad = .depends ~ /proftpd-abi-1.3.6c/;

Thanks!

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 5.7.0-1-686-pae (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


signature.asc
Description: PGP signature

Bug#966433: [Help] Re: seqan autopkg test failures triggered by gcc-defaults

[Andreas Tille]

Hi folks,

I tried to reproduce the issue.  When I try to run the test in a chroot I get:

...
   Required dependency:Range-V3 found.
--   Required dependency:SDSL found.
--   Optional dependency:Cereal found.
--   Optional dependency:Lemon not found.
--   Optional dependency:ZLIB-1.2.11 found.
--   Optional dependency:BZip2-1.0.8 found.
--   Optional dependency:libexecinfo found.
--   SeqAn3 platform.hpp build:  passed.
-- Found SeqAn3: /usr/include..
CMake Error at /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:104 
(include):
  include could not find load file:

seqan3_test_component
Call Stack (most recent call first):
  CMakeLists.txt:11 (include)


CMake Error at /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:105 
(include):
  include could not find load file:

seqan3_test_files
Call Stack (most recent call first):
  CMakeLists.txt:11 (include)


CMake Error at /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:106 
(include):
  include could not find load file:

seqan3_require_ccache
Call Stack (most recent call first):
  CMakeLists.txt:11 (include)


CMake Error at /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:107 
(include):
  include could not find load file:

seqan3_require_benchmark
Call Stack (most recent call first):
  CMakeLists.txt:11 (include)


CMake Error at /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:108 
(include):
  include could not find load file:

seqan3_require_test
Call Stack (most recent call first):
  CMakeLists.txt:11 (include)


CMake Error at /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:109 
(include):
  include could not find load file:

add_subdirectories
Call Stack (most recent call first):
  CMakeLists.txt:11 (include)


CMake Error at CMakeLists.txt:32 (seqan3_require_ccache):
  Unknown CMake command "seqan3_require_ccache".


-- Configuring incomplete, errors occurred!
See also 
"/tmp/autopkgtest.olJ5KS/autopkgtest_tmp/build_unit/CMakeFiles/CMakeOutput.log".
See also 
"/tmp/autopkgtest.olJ5KS/autopkgtest_tmp/build_unit/CMakeFiles/CMakeError.log".


For me this looks as if test/seqan3-test.cmake needs some patches.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#968361: game-data-packer: missing quake2 match1.tar.gz, q2ctf4a.tar.gz

[axet]

Package: quake2
Version: 63
Severity: normal

Dear Maintainer,

Packing quake2 directory causing following errors:

WARNING:game_data_packager.download:Failed to download 
"ftp://ftp.debian.nl/pub/idsoftware/idstuff/quake2/maps/match1.tar.gz": 


I guess, 'ftp' no longer popular, and we need to use 'http' instead.

-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages quake2 depends on:
ii  game-data-packager 63
ii  game-data-packager-runtime 63
ii  yamagi-quake2 [quake2-engine]  7.40+ctf1.06~dfsg-1

Versions of packages quake2 recommends:
ii  game-data-packager  63

Versions of packages quake2 suggests:
pn  quake2-groundzero  
pn  quake2-music   
pn  quake2-reckoning   

-- no debconf information

Bug#966894: faucc: FTBFS: parse.tab.c:108:10: fatal error: parse.tab.h: No such file or directory

[Stefan Potyra]

Hi,

turns out that my patch was not yet working, attached is an even simpler fix.

Cheers,
  Stefan.
diff --git a/parse.y b/parse.y
index 3e108e3..57df757 100644
--- a/parse.y
+++ b/parse.y
@@ -21,6 +21,8 @@
 #include "expr.h"
 %}
 
+%define api.header.include {"parse.h"}
+
 %union {
 	int nil;
 	unsigned long long integer;


signature.asc
Description: PGP signature

Bug#965960: chromium: Received signal 11 SEGV_ACCERR 000004c03193. can't load pages and extensions

[peter green]

thank you for packaging chromium.
after upgrading libc to 2.31, all available chromium: 80 and 83 are cashing.
the bug has been treated at redhat: 
https://bugzilla.redhat.com/show_bug.cgi?id=1773289
and has been confirmed by upstream: 
https://bugs.chromium.org/p/chromium/issues/detail?id=1025739


hope my report will help,
alex


I can confirm that chromium is crashing in Sid on i386 (and also raspbian 
bullseye)
, but the bugs you link to have already been fixed.

I think the current crash is a similar issue but with a different syscall, 
namely
clock_gettime64. I will try to whip up a patch.

In the meantime the issue can be worked around with --no-sandbox

Bug#961813: the missing firmware

[permondes - sagen]

Am Dienstag, den 02.06.2020, 20:00 +0100 schrieb Ben Hutchings:
> On Tue, 2020-06-02 at 14:40 +0200, permondes - sagen wrote:
> > installed are:- firmware-linux-free 3.4 (there is a newer version
> > in testing:20200122-1)- firmware-linux 20190717-2~bpo10+1-
> > firmware-linux-nonfree 20190717-2~bpo10+1
> > I realized the missing firmware is available at git.kernel.org.
> > Arethese included already in the free package in testing? If so,
> > are thereany plans to backport them (I am running on stable and
> > would ratherwait for that)? Would it harm to fetch just this
> > package from testing(I presume no)?
> 
> The i915 firmware is non-free.
> I've done some work toward a new version of firmware-nonfree, but
> it'snot quite ready yet.
> Ben.

Please backport firmware-misc-nonfree (20200619-1) to buster-backports
ThanksDietmar

Bug#968337: sylpheed: crash on startup

[Simon McVittie]

Control: tags -1 + moreinfo

On Thu, 13 Aug 2020 at 19:17:08 +0100, Simon McVittie wrote:
> If this isn't immediately reproducible in an unconfigured copy of sylpheed
> (I haven't tried yet, I don't use it myself), then we'll need more
> information than this to be able to diagnose what's happening.

I couldn't reproduce this crash myself, so I'll need a backtrace from
someone who can.

smcv

Bug#968373: RFP: hls+ghcide -- Haskell Development Environment and Language Server

[hyiltiz]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: hyil...@gmail.com

* Package name: hls (or ghcide)
  Version : 0.3.0
  Upstream Author : https://github.com/haskell/haskell-language-server
* URL : https://github.com/haskell/haskell-language-server
* License : BSD
  Programming Lang: Haskell
  Description : Haskell Development Environment and Language Server

 GHCIDE is the recommended [1] tool supporting a wide range of editors (Vim,
 Emacs, VSCode etc. [2]), crucial for Haskell development. Recently, there
 are many interest in its development, and has joined forces [3] with others
 to build haskell-language server (hls) [4], so Debian could provide a single
 package hls (hls contains ghcide internally). Hls provides officially built
 binaries in their Github Release page.

It has more functionality and better support than older haskell development
packages such as happy, hlint, ghc-mod etc.

[1] https://gitlab.haskell.org/ghc/ghc/-/wikis/spacemacs#historical
[2] https://github.com/digital-asset/ghcide
[3] 
https://neilmitchell.blogspot.com/2020/01/one-haskell-ide-to-rule-them-all.html
[4] https://github.com/haskell/haskell-ide-engine/issues/1416

Bug#968360: RFP: gfeeds — RSS/Atom feed reader for GNOME

[Marek Ľach]

Package: gfeeds

RFP
Severity: wnpp

A GNOME RSS/Atom feed  reader.

License: GPL

Source: https://gitlab.gnome.org/World/gfeeds

Package works much faster when native, as opposed to Flathub!

It'd be much appreciated, if also packaged for aarch64. Sincere thanks.

Bug#968372: sylpheed: crash on startup

[Simon McVittie]

On Thu, 13 Aug 2020 at 19:31:38 +0200, Francesco Poli wrote:
> On Thu, 13 Aug 2020 09:20:30 +0100 Matthew Munro  
> wrote:
> > Following libpango-1.0-0 (and others) upgrade this morning, gdb reports:
> > 
> > Thread 1 "sylpheed" received signal SIGSEGV, Segmentation fault.
> > 0xb73cfebf in pango_renderer_part_changed ()
> >from /usr/lib/i386-linux-gnu/libpango-1.0.so.0

If this isn't immediately reproducible in an unconfigured copy of sylpheed
(I haven't tried yet, I don't use it myself), then we'll need more
information than this to be able to diagnose what's happening. Please
quote the whole backtrace, preferably after installing debugging
symbols for pango, sylpheed and any other libraries that show up in the
backtrace.

More information on detached debug symbols and getting a backtrace:
https://wiki.debian.org/HowToGetABacktrace

> I do not know whether a fix is needed in sylpheed or in libpango-1.0-0,
> but a RC bug report against libpango-1.0-0 is necessary in order to
> prevent its migration to testing.

My understanding had been that the preferred representation for that is to
reassign the bug to *both* packages ("reassign -1 libpango-1.0-0,sylpheed",
"found -1 pango1.0/x.y.z", "found -1 sylpheed/u.v.w"), which avoids having
to either duplicate relevant information between the two bugs, or have
the information only show up in one of the two places.

Thanks,
smcv

Bug#968359: linux-image-5.7.0-2-amd64: '/dev/fd' is not created automatically

[Boris Jakubith]

Package: src:linux
Version: 5.7.10-1
Severity: important

The symbolic link '/dev/fd' (which is essential for packages like 'dkms') is
no longer created at system startup. I'm currently using a small workaround
for this problem by manually creating this symbolic link with

ln -s /proc/self/fd /dev/fd

in an init script (i'm using the sysv init, not systemd).

But this should not be the intended solution, as '/dev/fd' should be created
during the kernel startup, together with (most of) the other devices.

I marked this bug as 'important', because it cost me half a day to find it,
after an upgrade of 'virtualbox-dkms' failed. Normal people propbaly may not
have been able to identify it.

-- Package-specific info:
** Version:
Linux version 5.7.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 
(Debian 9.3.0-16), GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 
5.7.10-1 (2020-07-26)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.7.0-2-amd64 
root=UUID=aee09a8d-1e43-4fb1-828f-796b3a69769d ro iomem=relaxed 
vsyscall=emulate quiet showopts elevator=deadline

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[8.545857] Installing knfsd (copyright (C) 1996 o...@monad.swb.de).
[9.148470] usb 3-6.1: reset high-speed USB device number 5 using xhci_hcd
[   10.928978] vboxdrv: loading out-of-tree module taints kernel.
[   10.929274] vboxdrv: module verification failed: signature and/or required 
key missing - tainting kernel
[   10.941989] vboxdrv: Found 8 processor cores
[   10.960236] vboxdrv: TSC mode is Invariant, tentative frequency 3703122198 Hz
[   10.960237] vboxdrv: Successfully loaded version 6.1.12_Debian (interface 
0x002d0001)
[   10.973269] VBoxNetFlt: Successfully started.
[   10.983080] VBoxNetAdp: Successfully started.
[   11.070031] tun: Universal TUN/TAP device driver, 1.6
[   11.196608] igb :06:00.0 enp6s0: igb: enp6s0 NIC Link is Up 1000 Mbps 
Full Duplex, Flow Control: RX/TX
[   11.196955] br0: port 1(enp6s0) entered blocking state
[   11.196956] br0: port 1(enp6s0) entered forwarding state
[   11.197162] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready
[   11.404025] fuse: init (API version 7.31)
[   11.414800] elogind-daemon[3248]: New seat seat0.
[   11.417083] elogind-daemon[3248]: Watching system buttons on 
/dev/input/event14 (Power Button)
[   11.461344] cgroup: cgroup: disabling cgroup2 socket matching due to 
net_prio or net_cls activation
[   11.468303] elogind-daemon[3248]: Watching system buttons on 
/dev/input/event13 (Power Button)
[   11.472407] br0: port 2(vethPTZBWO) entered blocking state
[   11.472409] br0: port 2(vethPTZBWO) entered disabled state
[   11.472456] device vethPTZBWO entered promiscuous mode
[   11.472528] br0: port 2(vethPTZBWO) entered blocking state
[   11.472530] br0: port 2(vethPTZBWO) entered forwarding state
[   11.499142] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   11.499144] Bluetooth: BNEP filters: protocol multicast
[   11.499150] Bluetooth: BNEP socket layer initialized
[   11.616415] elogind-daemon[3248]: Watching system buttons on 
/dev/input/event8 (Chicony Wireless Device)
[   11.616671] elogind-daemon[3248]: Watching system buttons on 
/dev/input/event10 (Chicony Wireless Device System Control)
[   11.636395] elogind-daemon[3248]: Watching system buttons on 
/dev/input/event9 (Chicony Wireless Device Consumer Control)
[   11.692274] elogind-daemon[3248]: Watching system buttons on 
/dev/input/event2 (SONiX USB DEVICE)
[   11.692389] elogind-daemon[3248]: Watching system buttons on 
/dev/input/event3 (SONiX USB DEVICE Keyboard)
[   11.756521] loop: module loaded
[   11.760267] elogind-daemon[3248]: Watching system buttons on 
/dev/input/event5 (SONiX USB DEVICE Consumer Control)
[   11.865388] EXT4-fs (loop0): mounting ext3 file system using the ext4 
subsystem
[   12.121441] hdaps: supported laptop not found!
[   12.121443] hdaps: driver init failed (ret=-19)!
[   12.164068] br0: port 2(vethPTZBWO) entered disabled state
[   12.198218] applesmc: supported laptop not found!
[   12.198220] applesmc: driver init failed (ret=-19)!
[   12.293620] acer_wmi: Acer Laptop ACPI-WMI Extras
[   12.293633] acer_wmi: No or unsupported WMI interface, unable to load
[   12.503323] EXT4-fs (loop0): mounted filesystem with ordered data mode. 
Opts: (null)
[   12.503529] eth0: renamed from vethHOPIKO
[   12.584772] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   12.584803] IPv6: ADDRCONF(NETDEV_CHANGE): vethPTZBWO: link becomes ready
[   12.584831] br0: port 2(vethPTZBWO) entered blocking state
[   12.584833] br0: port 2(vethPTZBWO) entered forwarding state
[   13.070766] kauditd_printk_skb: 29 callbacks suppressed
[   13.070769] audit: type=1400 audit(1597325940.453:40): apparmor="DENIED" 
operation="mount" info="failed flags match" error=-13 
profile="/usr/bin/lxc-start" name="/proc/sys/kernel/random/boot_id" pid=3352 
comm="lxc-start" 

Bug#744401: snowdrop: diff for NMU 0.02b-12.1

[David da Silva Polverari]

On Thu, Aug 13, 2020 at 06:29:34PM +0200, Andreas Metzler wrote:

Hi Andreas,

> Reopening seems to be make-work if you are in the process of adopting
> anyway. ;-)

Ok! :)

> cu Andreas
> 
> 
> [1] Worried is too strong. But the rationale for closing made no sense. I
> submitted a bugreport with a diff for the NMU to make it available to
> the maintainer and track its integration. Closing it with "a package
> that contains the diff already entered the Debian archive" did not make
> sense, since the only package in the archive with the diff is still the
> NMU, so the status of the package had not changed at all since I had
> submitted the tracking bug report.

Sorry for "worried" lol. As English is not my first language, sometimes
I make a poor choice of words.

As for the rationale for closing, maybe I misinterpreted what was stated
on the Debian wiki about BTS usage [1] in this case, but I see your
point now. I should have deferred closing the bug after the new revision
I am working on was accepted on unstable. All those processes are still
new to me, so I'm unfortunately still making some mistakes along the
way. Sorry for the inconvenience and thanks for the explanation!

[1] https://www.debian.org/Bugs/Developer#closing

Regards,

David Polverari.

Bug#968337: sylpheed: crash on startup

[Francesco Poli]

Control: clone -1 -2
Control: reassign -2 libpango-1.0-0 1.46.0-1
Control: affects -2 + sylpheed
Control: retitle -2 libpango-1.0-0: causes sylpheed to crash on startup


On Thu, 13 Aug 2020 09:20:30 +0100 Matthew Munro  wrote:

> Package: sylpheed
> Version: 3.7.0-8
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: bugzilla...@gmail.com
> 
> Dear Maintainer,
> 
> Following libpango-1.0-0 (and others) upgrade this morning, gdb reports:
> 
> 
> Thread 1 "sylpheed" received signal SIGSEGV, Segmentation fault.
> 0xb73cfebf in pango_renderer_part_changed ()
>from /usr/lib/i386-linux-gnu/libpango-1.0.so.0
[...]
> ii  libpango-1.0-0   1.46.0-1
[...]

Hello,
I am a user of Sylpheed who has just noticed your bug report.

Since (on Debian testing) sylpheed/3.7.0-8 works correctly with
libpango-1.0-0/1.44.7-4 , I would say that it is important to prevent
the migration of libpango-1.0-0/1.46.0-1 from unstable to testing,
until this issue is fixed.

I do not know whether a fix is needed in sylpheed or in libpango-1.0-0,
but a RC bug report against libpango-1.0-0 is necessary in order to
prevent its migration to testing.

I am consequently cloning this bug report and reassigning the clone to
package libpango-1.0-0.
Dear pango1.0 maintainers, please do not reassign back or downgrade
this bug report, until the issue is solved for the best. 
Thanks.


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


pgpieXisUKzMu.pgp
Description: PGP signature

Bug#968370: ITP: ruby-aws-sdk-cloudformation -- AWS SDK for Ruby - AWS CloudFormation

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

* Package name : ruby-aws-sdk-cloudformation
Version : 1.41.0
Upstream Author : Amazon Web Services
* URL : https://github.com/aws/aws-sdk-ruby
* License : Apache-2.0
Programming Lang: Ruby
Description : AWS SDK for Ruby - AWS CloudFormation
Official AWS Ruby library for AWS CloudFormation.
.
AWS CloudFormation provides a common language to model and provision 
AWS and
third party application resources in a cloud environment. AWS 
CloudFormation

allows using programming languages or a simple text file to model and
provision, in an automated and secure manner, all the resources needed 
for an
application across all regions and accounts. This gives a single 
source of

truth for AWS and third party resources.
.
This library is part of the AWS SDK for Ruby.

This is a dependency of gitlab 13.3

Bug#968369: sane-backends: broken dep-8 test?

[Sylvain Beucler]

Source: sane-backends

Hi,

I'm preparing a stretch LTS update for sane-backends and it seems 
debian/tests/start-net does not work as intended.

I think the expected output is like:
+ scanimage -d net -L
device `pnm:0' is a Noname PNM file reader virtual device
device `pnm:1' is a Noname PNM file reader virtual device

but due to grepping ':net' those line are not counted, and the test fails.
CNT=`scanimage -d net -L | grep net: | wc -l`

Grepping ':pnm' fixes the test:
CNT=`scanimage -d net -L | grep pnm: | wc -l`

Was that the intended use?

Cheers!
Sylvain Beucler
Debian LTS Team

Bug#968367: sogo: please include active sync support

[Raoul Gunnar Borenius]

Package: sogo
Version: 4.3.2-1
Severity: wishlist

Dear Maintainer,

currently the active sync support ist not included in the Debian
version of sogo.

Unfortunately there are a still a lot of clients preferring
active sync over carddav/caldav.

Would it be possible to include active sync support in future
Debian packages?

Thank you for considering!

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

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

Versions of packages sogo depends on:
ii  adduser   3.118
ii  gnustep-base-runtime  1.27.0-3
ii  init-system-helpers   1.58
ii  libc6 2.31-3
ii  libcrypt1 1:4.4.16-1
ii  libcurl3-gnutls   7.68.0-1+b1
ii  libgcc-s1 10.2.0-5
ii  libglib2.0-0  2.64.4-1
ii  libgnustep-base1.27   1.27.0-3
ii  libgnutls30   3.6.14-2+b1
ii  liblasso3 2.6.1-1
ii  libmemcached111.0.18-4.2
ii  libobjc4  10.2.0-5
ii  libsbjson2.3  2.3.2-4+b2
ii  libsope1  4.3.2-2
ii  lsb-base  11.1.0
ii  memcached 1.6.6-1
ii  sogo-common   4.3.2-1
ii  systemd   246-2
ii  zip   3.0-11+b1

sogo recommends no packages.

Versions of packages sogo suggests:
pn  postgresql | default-mysql-server | virtual-mysql-server  

-- Configuration Files:
/etc/sogo/sogo.conf [Errno 13] Permission denied: '/etc/sogo/sogo.conf'

-- no debconf information

Bug#744401: snowdrop: diff for NMU 0.02b-12.1

[Andreas Metzler]

On 2020-08-13 David da Silva Polverari  wrote:
> On Wed, Aug 12, 2020 at 07:11:35PM +0200, Andreas Metzler wrote:
>> this bug tracks the fact that the changes in the NMU have NOT been
>> integrated into a maintainer upload. So it should stay open until that
>> has happened, afaik.

> Hi Andreas,

> I'm not sure if I follow, but from what I see, you are worried that new
> maintainers will not take these NMU changes into account on the next
> revisions, right?

Hello David,

Yes, indeed.[1]

> I have an ITA opened and I'm working on a Debian revision of the package
> atm, and I have created a git repository (using gbp import-dscs
> --debsnap), which contains your NMU.

> Even if I weren't doing this revision, I think any other potential
> Debian contributor would be basing their work on the latest Debian
> revision found on the archives, which happen to be your NMU at this
> point, as can be seen by fetching the package sources on sid with apt
> source.

> Thus I'm not sure what the benefits are of keeping this bug open. Of
> course, I may be completely wrong :). So, do you think I should reopen
> it until I (or anyone else, for that matter) release a new Debian
> revision?

Reopening seems to be make-work if you are in the process of adopting
anyway. ;-)

cu Andreas


[1] Worried is too strong. But the rationale for closing made no sense. I
submitted a bugreport with a diff for the NMU to make it available to
the maintainer and track its integration. Closing it with "a package
that contains the diff already entered the Debian archive" did not make
sense, since the only package in the archive with the diff is still the
NMU, so the status of the package had not changed at all since I had
submitted the tracking bug report.

Bug#968156: Also in Java packages (lintian repeated-path-segment false positive)

[Olek Wojnar]

I'd like to add that this issue often comes up in Java packages as well,
for similar directory structure reasons. For example,

O: libgoogle-flogger-java: [90mrepeated-path-segment [0m flogger
usr/share/maven-repo/com/google/flogger/flogger/0.5.1/
O: libgoogle-flogger-java: [90mrepeated-path-segment [0m flogger
usr/share/maven-repo/com/google/flogger/flogger/debian/flogger-debian.jar
O: libgoogle-flogger-java: [90mrepeated-path-segment [0m flogger
usr/share/maven-repo/com/google/flogger/flogger/debian/flogger-debian.pom
O: libopencensus-java: [90mrepeated-path-segment [0m examples
usr/share/doc/libopencensus-java/examples/src/main/java/io/opencensus/examples/gauges/DerivedDoubleGaugeQuickstart.java
O: libopencensus-java: [90mrepeated-path-segment [0m examples
usr/share/doc/libopencensus-java/examples/src/main/java/io/opencensus/examples/grpc/helloworld/
O: libopencensus-java: [90mrepeated-path-segment [0m examples
usr/share/doc/libopencensus-java/examples/src/main/java/io/opencensus/examples/grpc/helloworld/HelloWorldClient.java
O: bazel-bootstrap-data: [90mrepeated-path-segment [0m android
usr/share/bazel/embedded_tools/src/tools/android/java/com/google/devtools/build/android/ziputils/BUILD
O: bazel-bootstrap-data: [90mrepeated-path-segment [0m buildjar
usr/share/bazel/embedded_tools/src/java_tools/buildjar/java/com/google/devtools/build/buildjar/jarhelper/

-Olek

Bug#965012: new test with debug_options ALL,9

[Markus Koschany]

Hello Andreas,

Am 07.08.20 um 10:40 schrieb Andreas Schulz:
[...]
> now everything compiles but I still have ICAP-errors. Just to be sure
> that I did everything correctly:
> 
> - apt source squid3
> - quilt pop -a
> - replaced the package patch with yours
> - quilt push -a
> - built packages and installed them


You did nothing wrong but you could add a new changelog entry with a new
version number and then run dpkg-source -b to create a new source
package. After that you can easily compare the old source package with
the new one by running

debdiff old.dsc new.dsc > my.debdiff

which highlights all the changes and also ensures the patch got applied
correctly.

In short, I have corrected the remaining error and I will upload a new
version today. The new package should be available on all mirrors within
24 hours.

For future reference:

The icap exception is triggered by two asserts (Must macros in squid
terminology) the one in src/adaptation/icap/OptXact.cc line 70 and
src/adaptation/icap/ModXact.cc line 1473. In order to fix CVE-2019-12523
the idea also was to better check for supported protocols. However the
urlParse function in 3.x and the corresponding AnyP::Uri::parse function
in 4.x are declared differently. While urlParse is of type HttpRequest,
AnyP::Uri::parse is of type boolean. The latter function simply returns
false if an invalid scheme is found but for the older urlParse function
NULL has to be returned. Since icap is not listed in urlParseProtocol
PROTO_NONE is returned which in turn triggers NULL. The corresponding
FindProtocolType function in 4.x would return PROTO_UNKNOWN instead and
only PROTO_NONE when the scheme is empty. I don't know why icap and ecap
are not explicitly defined as known protocols in 3.x and 4.x. In order
to keep the changes minimal I have simply added icap, icaps, ecap and
ecaps as known protocols now. Thanks to Nico Rogowski for pointing me in
the right direction.

The new update will also include an improved patch for CVE-2019-12529.


Regards,

Markus






signature.asc
Description: OpenPGP digital signature

Bug#968344: pencil2d: please make the build reproducible

[Chris Lamb]

Hi Vagrant,

> I think that should be:
> 
> +timestamp=$(shell date +%Y-%m-%d -u -d "@$(SOURCE_DATE_EPOCH)")
> 
> Since @SOURCE_DATE_EPOCH is be passed to the "-d" argument.

ACK - thank you for the correction.


Regards,

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

Bug#968003: lintian: bad name for duplicate-globbing-patterns and redundant-globbing-patterns

[Otto Kekäläinen]

Hello!

I agree with Raphaël's comments. The wording of this error could be
improved a bit.

In 
https://mariadb-team.pages.debian.net/-/mariadb-10.3/-/jobs/929803/artifacts/debian/output/lintian.html
I got

E duplicate-globbing-patterns mysql-test/mysql-stress-test.pl in lines
213 467 467
E duplicate-globbing-patterns storage/innobase/fts/fts0pars.cc in lines 590 590
E duplicate-globbing-patterns
storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/lib/getopt_int.h
in lines 769 800
E duplicate-globbing-patterns strings/strxmov.c in lines 355 355
E duplicate-globbing-patterns strings/strxnmov.c in lines 355 355
E redundant-globbing-patterns [client/* client/echo.c] for client/echo.c
E redundant-globbing-patterns [mysql-test/mysql-stress-test.pl
mysql-test/mysql-stress-test.pl] for mysql-test/mysql-stress-test.pl
E redundant-globbing-patterns [storage/innobase/fts/fts0pars.cc
storage/innobase/fts/fts0pars.cc] for storage/innobase/fts/fts0pars.cc
E redundant-globbing-patterns [strings/strxmov.c strings/strxmov.c]
for strings/strxmov.c
E redundant-globbing-patterns [strings/strxnmov.c strings/strxnmov.c]
for strings/strxnmov.c

-> 6 errors would have been enough, now there are 10
-> some have identical line numbers twice

Also, I was unable to find it's documentation at the usual location at
https://lintian.debian.org/tags/duplicate-globbing-patterns.html


Never the less, the usability was good enough that I was able to fix
the issues and now Lintian passes for this package. This is just a
minor improvement suggestion.

Bug#914702: ghci: The 'impossible' happens when running ":print length"

[Ilias Tsitsimpis]

Dear Asher,

On Tue, Dec 03, 2019 at 03:43PM, Asher Gordon wrote:
> Should I create a new report now or just leave it as is?

This is indeed a different issue. I think you should report this
upstream (https://gitlab.haskell.org/ghc/ghc/-/issues).

Best,

-- 
Ilias

Bug#968366: libproxy#126: buffer overflow when PAC is enabled

[Simon McVittie]

Source: libproxy
Version: 0.4.14-2
Severity: grave
Justification: user security hole
Tags: security upstream
Forwarded: https://github.com/libproxy/libproxy/pull/126
X-Debbugs-Cc: Debian Security Team 

Li Fei (@lifeibiren on Github) reported that if the server serving a PAC
file sends more than 102400 bytes without a Content-Length present,
libproxy can overflow its buffer by PAC_HTTP_BLOCK_SIZE (512) bytes.

This PR is said to fix it, although I have not reviewed it in detail, and
it would be better if someone who knows C++ better than me did the review:

https://github.com/libproxy/libproxy/pull/126

Thanks to Michael Catanzaro for highlighting this as likely to be a
security vulnerability during a more general conversation about libproxy.

(Please reduce severity as desired if this is succesfully mitigated by
some security measure - I'm assuming stack smashing is arbitrary code
execution, but maybe it's just DoS.)

>From source code inspection, versions >= 0.4.14-2 in stretch appear
to be vulnerable. 0.4.11-4 in jessie does not appear to be vulnerable,
because it assumes absence of Content-Length means a length of 0 (which
is a bug, but not a security bug). Intermediate versions between jessie
and stretch not checked.

smcv

Bug#968364: pkg-perl-tools: mojibake in dpt-forward (forwarding Debian bugs as GitHub issues)

[gregor herrmann]

Package: pkg-perl-tools
Version: 0.62
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

In #968362 I've used the ellipsis UTF-8 character to denote an elison
like: '[…]'.

After running `dpt forward 968362' the nice 3 dots end up in the GitHub
issue at https://github.com/maxmind/MaxMind-DB-Writer-perl/issues/112
as: '[�]'

Looks like there's some (UTF-8 or other) encoding directive missing
somewhere …


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl81WkBfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZnKg//TZ4fZ+LaoNEl1tKtCKyGnKedsBCFS68adEZzdgHd73QXal87Yf4yHZxo
6NAago77qSEcsdfCv/+fLl2RyOQdlOdAaar9cwgWogdGk8Y37QvdYkrkg7Vt0J8K
CXC4BPOhRUkfe0rYv0BTZv/dYC7zGpzjDZAxQHRLs+d4mPb7wtmaXnTBvnjqrGqD
HhpaY0JmvFxG7EXyAQYGtVjrlwswrMALrCf31FJNb4FFLAEDjQDS5dlAaQ1yLimu
8Ejhuh58pZaQ6gKeqfCLc78R0WzaiYKzTgIhjdGSnDOLs6G4QfKLsbozE/DAqc2e
SZrB6bEGyJiB9bHa4S8MP+bl7+qLhzJXl9b4kf0q/cljzQHmUWS6XKcSmsAFoZ/Q
JzP7JkY+ng24Tb7RXgq81s7a/joo2K5qxelPr5xwvCj1Keuy5ANe8D0gD9jD5whf
2RX+dBGhgAOx7exzA/GXVfvXqnX2+5VSb/hHNPhAO8suhZJHgRcwG7+3aABIbVni
VHV02ZxC7BWFGvW+hf6atOPl8pPM9ra49TFRDgrUl0EBg+WijQEACejFH3j/jVPq
sYqEtRmAn5ErT3Qgpyg2kcCL0yBZBqauCR8/iT/RJjYpb3h7bM2wClGUVKuVnrAt
klnKOsoGXmzHR2S45z+Qa3qwr3B8NrH1bSuWK1Ig7HFS23mygJM=
=VhRx
-END PGP SIGNATURE-

Bug#968365: /usr/bin/freshclam: Ignores DatabaseCustomURL unless --update-db=custom is specified

[Stephan Jänecke]

Package: clamav-freshclam
Version: 0.102.3+dfsg-0~deb9u1
Severity: normal
File: /usr/bin/freshclam

Dear Maintainer,

starting with version 0.102.3 freshclam ignores DatebaseCustomURL
options.

As this option is used to specify custom paths to update databases on
our local mirror, updates fail after upgrading from version 0.101.4.

Let me give you an example. Instead of downloading the database from
`http://update.dfn-cert.de/av-sigs/clamav/db/main.cvd` freshclam will
try `https://update.dfn-cert.de/main.cvd` and fail.

Looking at the code I figured out that freshclam can be motivated to honour
the values in DatabaseCustomURL options. Once I specified the executable
parameter `--update-db=custom` freshclam happily updated the databases
from the custom paths.

Now I'm wondering: is my site incorrectly specifying custom database
paths using `DatabaseCustomURL` and the breakage on update has been
intentionally introduced by upstream? If so, what would be the correct
way to introduce custom paths?

Or did I indeed find a bug?

Best regards,

Stephan Jänecke


-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
AlertExceedsMax disabled
PreludeEnable disabled
PreludeAnalyzerName disabled
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog = "yes"
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile = "/var/run/clamav/clamd.pid"
TemporaryDirectory = "/var/tmp"
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode disabled
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "200"
StreamMaxLength = "1073741824"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "100"
ReadTimeout = "120"
CommandReadTimeout = "30"
SendBufTimeout = "500"
MaxQueue = "200"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "5000"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
ScanPE = "yes"
ScanELF = "yes"
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
HeuristicAlerts = "yes"
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
AlertBrokenExecutables disabled
AlertEncrypted disabled
AlertEncryptedArchive disabled
AlertEncryptedDoc disabled
AlertOLE2Macros disabled
AlertPhishingSSLMismatch disabled
AlertPhishingCloak disabled
AlertPartitionIntersection disabled
ScanPDF = "yes"
ScanSWF = "yes"
ScanXMLDOCS = "yes"
ScanHWP3 = "yes"
ScanArchive = "yes"
ForceToDisk disabled
MaxScanTime disabled
MaxScanSize = "10737418240"
MaxFileSize = "10737418240"
MaxRecursion = "16"
MaxFiles disabled
MaxEmbeddedPE = "10485760"
MaxHTMLNormalize = "10485760"
MaxHTMLNoTags = "2097152"
MaxScriptNormalize = "5242880"
MaxZipTypeRcg = "1048576"
MaxPartitions = "50"
MaxIconsPE = "100"
MaxRecHWP3 = "16"
PCREMatchLimit = "10"
PCRERecMatchLimit = "2000"
PCREMaxFileSize = "26214400"
OnAccessMountPath disabled
OnAccessIncludePath disabled
OnAccessExcludePath disabled
OnAccessExcludeRootUID disabled
OnAccessExcludeUID disabled
OnAccessExcludeUname disabled
OnAccessMaxFileSize = "5242880"
OnAccessDisableDDD disabled
OnAccessPrevention disabled
OnAccessExtraScanning disabled
OnAccessCurlTimeout = "5000"
OnAccessMaxThreads = "5"
OnAccessRetryAttempts disabled
OnAccessDenyOnError disabled
DevACOnly disabled
DevACDepth disabled
DevPerformance disabled
DevLiblog disabled
DisableCertCheck disabled
AlgorithmicDetection = "yes"
BlockMax disabled
PhishingAlwaysBlockSSLMismatch disabled
PhishingAlwaysBlockCloak disabled
PartitionIntersection disabled
OLE2BlockMacros disabled
ArchiveBlockEncrypted disabled

Config file: freshclam.conf
---
LogFileMaxSize = "10485760"
LogTime = "yes"
LogSyslog = "yes"
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
PidFile = "/var/run/clamav/freshclam.pid"
DatabaseDirectory = "/var/lib/clamav"
Foreground disabled
Debug disabled
UpdateLogFile = "/var/log/clamav/freshclam.log"
DatabaseOwner = "clamav"
Checks = "24"
DNSDatabaseInfo = "current.cvd.clamav.net"
DatabaseMirror = "update.dfn-cert.de"
PrivateMirror disabled
MaxAttempts = "3"
ScriptedUpdates disabled
TestDatabases = "yes"
CompressLocalDatabase disabled

Bug#963714: on Debian kernel as well

[Christian Ehrhardt]

I wanted to check if this could be an Ubuntu kernel bug, so I checked
Debian on:

 Linux debian 5.7.0-2-amd64 #1 SMP Debian 5.7.10-1 (2020-07-26) x86_64
GNU/Linux

It is slightly faster there, but the results look just as bad:
 fatrace.log.0oLjK : .F - 9 matches missing
 fatrace.log.0qKTf : F..FFF - 4 matches missing
 fatrace.log.18xyI : ...F.. - 1 matches missing
 fatrace.log.2Jk3p : ..F.FF - 3 matches missing
 fatrace.log.38fQg : .. - 0 matches missing
 fatrace.log.3k2ln : .FFF.F - 8 matches missing

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#968363: libproxy: px_proxy_factory_get_proxies not thread-safe

[Simon McVittie]

Source: libproxy
Version: 0.4.15-13
Severity: important
Forwarded: https://github.com/libproxy/libproxy/pull/128
Tags: upstream

Upstream bug https://github.com/libproxy/libproxy/issues/68 says
libproxy is not currently thread-safe. Fedora uses, or has used,
https://github.com/libproxy/libproxy/pull/128 to avoid numerous
thread-related crashes; the author of the latest version sent upstream
recommended that we consider it for Debian too.

smcv

Bug#968344: pencil2d: please make the build reproducible

[Vagrant Cascadian]

On 2020-08-13, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0] we noticed that
> pencil2d could not be built reproducibly.
>
> While you do use SOURCE_DATE_EPOCH to populate GIT_TIMESTAMP, you omit
> the --utc flag to date(1) so the generated date will depend on the
> build system's current timezone.
...
> --- a/debian/rules2020-08-13 11:34:56.164335215 +0100
> --- b/debian/rules2020-08-13 11:59:46.372680920 +0100
> @@ -6,7 +6,7 @@
>  
>  # export information for the "About" screen
>  include /usr/share/dpkg/pkg-info.mk
> -timestamp=$(shell date +%Y-%m-%d -d "@$(SOURCE_DATE_EPOCH)")
> +timestamp=$(shell date +%Y-%m-%d -d -u "@$(SOURCE_DATE_EPOCH)")

I think that should be:

+timestamp=$(shell date +%Y-%m-%d -u -d "@$(SOURCE_DATE_EPOCH)")

Since @SOURCE_DATE_EPOCH is be passed to the "-d" argument.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#968345: RM: golang-github-mendersoftware-scopestack-dev -- ROM; deprecated and unused

[lluis . campos]

Package: ftp.debian.org
Severity: normal

Hello ftp team,

This dependency is also deprecated after removing
golang-github-mendersoftware-log (see #960398)

Unused both in testing and unstable, so please remove:

golang-github-mendersoftware-scopestack-dev


Regards,

Lluís M. Campos Martínez
Northern.tech ++ Mender.io

Bug#968335: kernel crash: WARNING: CPU: 0 PID: 0 at lib/percpu-refcount.c:155 percpu_ref_switch_to_atomic_rcu+0xf8/0x120

[tobias]

Hello,

wanted to add that the issue gets triggered when running the following
script:

#!/bin/sh
if [ -x /usr/bin/certbot ]; then
  certbot -q--authenticator standalone \
--installer none renew  \
--pre-hook "service apache2 stop" \
--post-hook "service apache2 start"
  sleep 60
  /bin/systemctl restart apache2
fi

if i run this script using previous kernel ( linux-image-4.19.0-9-amd64
) no kernel crash is happening.

tobias.

Bug#968362: FTBFS: test failures on some architectures

[gregor herrmann]

Source: libmaxmind-db-writer-perl
Version: 0.33-1
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source (but built successfully in the past)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

libmaxmind-db-writer-perl never built on all architectures:

https://buildd.debian.org/status/logs.php?pkg=libmaxmind-db-writer-perl

The history of the uploads goes like this:

0.33-1: testsuite disabled
Result: successful build on all architectures where all build dependencies
are available (esp. libmath-int128-perl is missing on quite a few).

0.33-2: testsuite enabled but tests needing Test::HexDifferences
skipped (as it was not yet packaged)
Result: additional failures in the tests on ppc64, s390x, sparc64
As (only) s390x is a release architecture, the package never migrated
to testing.

0.33-3: all tests are run after libtest-hexdifferences entered
the archive.
Result: same as for 0.33-2


Logs of the failures (for 0.33-3):

ppc64:
https://buildd.debian.org/status/fetch.php?pkg=libmaxmind-db-writer-perl=ppc64=0.33-3=1596597051=0

sparc64:
https://buildd.debian.org/status/fetch.php?pkg=libmaxmind-db-writer-perl=sparc64=0.33-3=1596597463=0

s390x:
https://buildd.debian.org/status/fetch.php?pkg=libmaxmind-db-writer-perl=s390x=0.33-3=1596578449=0


The failing tests are always the same, quoting from the s390x log:

#   Failed test 'No tests run for subtest "Tree with 256 networks - IPv4 only - 
24-bit records"'
#   at t/MaxMind/DB/Writer/Tree-freeze-thaw.t line 62.
Sereal: Error: Bad Sereal header: Not a valid Sereal document. at offset 1 of 
input at srl_decoder.c line 600 at 
/<>/blib/lib/MaxMind/DB/Writer/Tree.pm line 403.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 1.
t/MaxMind/DB/Writer/Tree-freeze-thaw.t . 
# Subtest: Tree with 256 networks - IPv4 only - 24-bit records
1..0
not ok 1 - No tests run for subtest "Tree with 256 networks - IPv4 only - 
24-bit records"
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 1/1 subtests 
[…]
Sereal: Error: Bad Sereal header: Not a valid Sereal document. at offset 1 of 
input at srl_decoder.c line 600 at 
/<>/blib/lib/MaxMind/DB/Writer/Tree.pm line 403.
t/MaxMind/DB/Writer/Tree-output/freeze-thaw-record-size.t .. 
Dubious, test returned 255 (wstat 65280, 0xff00)
No subtests run 
[…]
Sereal: Error: Bad Sereal header: Not a valid Sereal document. at offset 1 of 
input at srl_decoder.c line 600 at 
/<>/blib/lib/MaxMind/DB/Writer/Tree.pm line 403.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 21.
t/MaxMind/DB/Writer/Tree-record-collisions.t ... 
[…]
Dubious, test returned 255 (wstat 65280, 0xff00)
All 21 subtests passed 
[…]
#   Failed test 'Run without exceptions'
#   at t/MaxMind/DB/Writer/Tree-thaw-merge.t line 86.
# Sereal: Error: Bad Sereal header: Not a valid Sereal document. at offset 
1 of input at srl_decoder.c line 600 at 
/<>/blib/lib/MaxMind/DB/Writer/Tree.pm line 403.
# Looks like you failed 1 test of 1.

#   Failed test 'check defaults work'
#   at t/MaxMind/DB/Writer/Tree-thaw-merge.t line 89.

#   Failed test 'Run without exceptions'
#   at t/MaxMind/DB/Writer/Tree-thaw-merge.t line 86.
# Sereal: Error: Bad Sereal header: Not a valid Sereal document. at offset 
1 of input at srl_decoder.c line 600 at 
/<>/blib/lib/MaxMind/DB/Writer/Tree.pm line 403.
# Looks like you failed 1 test of 1.

#   Failed test 'check no merging explictly'
#   at t/MaxMind/DB/Writer/Tree-thaw-merge.t line 89.

#   Failed test 'Run without exceptions'
#   at t/MaxMind/DB/Writer/Tree-thaw-merge.t line 86.
# Sereal: Error: Bad Sereal header: Not a valid Sereal document. at offset 
1 of input at srl_decoder.c line 600 at 
/<>/blib/lib/MaxMind/DB/Writer/Tree.pm line 403.
# Looks like you failed 1 test of 1.

#   Failed test 'check no merging and none explictly'
#   at t/MaxMind/DB/Writer/Tree-thaw-merge.t line 89.

#   Failed test 'Run without exceptions'
#   at t/MaxMind/DB/Writer/Tree-thaw-merge.t line 86.
# Sereal: Error: Bad Sereal header: Not a valid Sereal document. at offset 
1 of input at srl_decoder.c line 600 at 
/<>/blib/lib/MaxMind/DB/Writer/Tree.pm line 403.
# Looks like you failed 1 test of 1.

#   Failed test 'set mrc in constructor, toplevel in thaw'
#   at t/MaxMind/DB/Writer/Tree-thaw-merge.t line 89.

#   Failed test 'Run without exceptions'
#   at t/MaxMind/DB/Writer/Tree-thaw-merge.t line 86.
# Sereal: Error: Bad Sereal header: Not a valid Sereal document. at offset 
1 of input at srl_decoder.c line 600 at 
/<>/blib/lib/MaxMind/DB/Writer/Tree.pm line 403.
# Looks like you failed 1 test of 1.

#   Failed test 'set toplevel in constructor'
#   at t/MaxMind/DB/Writer/Tree-thaw-merge.t line 89.

#   Failed test 'Run without 

Bug#968071: lintian: Differentiate between "ar" static libraries and "ar" archives

[Olek Wojnar]

Hi Felix,

First of all, apologies for accidentally replying to the wrong email
before. Sending to the bug email now.

On Wed, Aug 12, 2020 at 2:26 AM Olek Wojnar  wrote:

> Hi Felix,
>
> On Tue, Aug 11, 2020 at 7:35 AM Felix Lechner 
> wrote:
>
>> Hi Olek,
>>
>> On Fri, Aug 7, 2020 at 6:03 PM Olek Wojnar  wrote:
>> >
>> > Lintian currently emits an arch-dependent-file-in-usr-share
>>
>> I cannot find bazel in the archive. How can I trigger the tag, please?
>>
>
> I'm getting ready to submit the bootstrap variant to NEW. The latest
> in-work branch is on Salsa [1] and I have a binary (with a dependency
> that's still stuck in NEW) on my p.d.o page. [2] Both binary packages have
> a signed .changes with them. Please let me know if there's anything else
> you need!
>
>
>> > lintian assumes that this is a static library.
>>
>> That is probably right. The relevant line is:
>>
>>
>> https://salsa.debian.org/lintian/lintian/-/blob/master/checks/binaries.pm#L345
>
>
> Strange, that line seems like it should identify it correctly. But I can
> open the files in question using emgrampa so they are clearly archives and
> I get this when I run file:
> $ file a.ar
> a.ar: current ar archive
>
>
>> >
>> https://salsa.debian.org/bazel-team/bazel-bootstrap/-/tree/olek-temp4/tools/build_defs/pkg/testdata
>>
>> The link shows source files but the tag is about installed files.
>> Which *.deb are you using, please?
>>
>
> Please use the one on p.d.o [2] for now.
>
>
>> > Please consider using the `file` command or something similar to
>> distinguish
>> > between the two types of "ar" files.
>>
>> I am not sure it is possible to distinguish them that way, but am
>> happy to look at it once I can reproduce. The ar files in your source
>> tree also come up as 'current ar archive'.
>>
>
> Thanks for taking a look at this! Again, please let me know if there's
> anything else that I can send you to make the troubleshooting easier!
>

Note that this issue also comes up for the
"arch-independent-package-contains-binary-or-object" tag. I ended up
splitting my packaging since the overwhelming majority of the size was
arch-independent and this tag came up for the same files.

-Olek
>
> [1] https://salsa.debian.org/bazel-team/bazel-bootstrap
> [2] https://people.debian.org/~olek/packages/
>

Bug#968343: RM: golang-github-mendersoftware-mendertesting-dev -- ROM; deprecated and unused

[lluis . campos]

Package: ftp.debian.org
Severity: normal

Hello ftp team,

This dependency is now deprecated after latest update of packages
mender-cli and golang-github-mendersoftware-mender-artifact following
upstream Mender project release.

Unused both in testing and unstable, so please remove:

golang-github-mendersoftware-mendertesting-dev

See also #960398 for related previously RM bug report.

Regards,

Lluís M. Campos Martínez
Northern.tech ++ Mender.io

Bug#964908:

[Thomas Kotzian]

Success report.
tomcat 9.0.37-3 works fine now.
Thank you!

Bug#964670: gsettings-qt: FTBFS: QQmlComponent: Component is not ready

[Mike Gabriel]

Hi,

On  Do 01 Jan 1970 01:00:00 CET, handsome_feng wrote:


Hi,
Is there any progress on this? I found that it failed when running  
`$$[QT_INSTALL_BINS]/qmlplugindump -notrelocatable GSettings 1.0 ..`  
, but I can only reproduce it when pdebuild. And with the same  
generated file, If I chroot the pbuilder environment and mount the  
build dir, cd the GSettings dir and run `qmlplugindump  
-notrelocatable GSettings 1.0 ..`, it will failed with  
"QQmlComponent: Component is not ready", but if I run the same  
command in the same build dir in my local environment, everything is  
fine. Could it be a lack of dependency?



regards,
handsome_feng


I have indeed made the same observation: local sid chroot with many  
packages installed (B-Ds of other packages mainly) -> the build works.


Build in a clean chroot (via sbuild) -> build fails.

I already started looking into this, but had to reprioritize. I will  
give more time to this (hopefully) the coming week.


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpItsw4l0Ih7.pgp
Description: Digitale PGP-Signatur

Bug#968338: WARNING: CPU: 0 PID: 0 at lib/percpu-refcount.c:155 percpu_ref_switch_to_atomic_rcu+0xf8/0x120

[tobias]

Hello,

please close this bug. bug 968335 is about the same issue and does 
contain the relevant kernel log.


tobias.

Bug#966816: /lib/systemd/system/blk-availability.service:10: Neither a valid executable name nor an absolute path: ${exec_prefix}/bin/true

[Tom Overlund]

I know Debian is a volunteer project, but it seems like bad form when a 
package-breaking bug is reported on the 
same day it is introduced, a trivial fix is availble, and 11 days later the 
package is still broken. One 
maintainer can trivially fix this, but in the meantime an untold number of 
people run across this error and have 
to spend time tracking it down.

Bug#968331: ITP: systemd-genie -- quick way into a systemd "bottle" under Windows Subsystem for Linux

[Alistair J R Young]

> If I understand correctly, this is a problem with WSL 1 that will go away with
> WSL 2, because WSL 1 is a compatibility layer in which the Windows kernel
> pretends to be Linux (like Wine in reverse), but WSL 2 is a virtual machine
> running a real Linux kernel (suitable for e.g. systemd)?

No, it's a current WSL 2 problem, I'm afraid.

You can't run systemd under WSL 1 at all, even with this tool or other hacks, 
because the compatibility layer doesn't implement some of the required system 
calls.

Under WSL 2, though, while the kernel has the necessary to support it, it's not 
used by default, as WSL injects its own init which handles the various issues 
surrounding interoperability, running multiple distributions off the same 
kernel, and so forth. If you want a real (pid 1) systemd, the only way to do it 
is to set up a pid namespace and run it within that, the assorted wrinkles 
around doing which are what genie exists to simplify/automate.

> If that's the case, then the useful lifetime of this package might be limited.
> (That doesn't *necessarily* mean it shouldn't be in Debian, depending on
> availability and adoption of WSL 2.)

I suspect - and hope! - its eventual lifespan may be limited, as there's 
clearly a lot of demand for system services under WSL (as per the ongoing 
discussion at https://github.com/microsoft/WSL/issues/994 etal.), but as of 
right now, there are no signs that it's anywhere close to the top of 
Microsoft's plans at this point.

Bug#968358: lsusb: claims keyboard with empty idProduct is a Yubikey

[Ansgar]

Package: usbutils
Version: 1:012-2
Severity: minor
File: /usr/bin/lsusb
Tags: upstream

`lsusb -v` reports:

+---
| Bus 002 Device 029: ID 0bf8:101e Fujitsu Siemens Computers Yubikey 4 
OTP+U2F+CCID
| [...]
|   idVendor   0x0bf8 Fujitsu Siemens Computers
|   idProduct  0x101e 
|   bcdDevice1.09
|   iManufacturer   1 Fujitsu
|   iProduct2 Fujitsu Keyboard
+---

There is also a Yubikey connected (listed later in the output) which I
guess the string comes from:

+---
| Bus 002 Device 020: ID 1050:0407 Yubico.com Yubikey 4/5 OTP+U2F+CCID
| [...]
|   idVendor   0x1050 Yubico.com
|   idProduct  0x0407 Yubikey 4/5 OTP+U2F+CCID
+---

Maybe `lsusb` reuses a previous device's product name if none is available?

Ansgar

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

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

Versions of packages usbutils depends on:
ii  libc6 2.31-3
ii  libudev1  246-2
ii  libusb-1.0-0  2:1.0.23-2
ii  usb.ids   2020.06.22-1

usbutils recommends no packages.

usbutils suggests no packages.

-- no debconf information

Bug#968357: rasdaemon: mountdebugfs no longer available

[Cristian Ionescu-Idbohrn]

Package: rasdaemon
Version: 0.6.6-1
Severity: normal

The mountdebugfs script is no longer provided by the blktrace package,
since a while back:

blktrace (1.2.0-1) unstable; urgency=medium
...
  * Remove debugfs mounting init script, as systemd is moutning debugfs
by default nowadays (Closes: #873470, #705269)
...
 -- Bas Zoetekouw   Sat, 19 May 2018 21:49:22 +0200

Bug #705269 provides some detail:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705269#10

An error:

insserv: FATAL: service mountdebugfs has to be enabled to use service 
rasdaemon

is produced when the package is upgraded.

Therefore, another method to detect if debugfs is mounted is needed.
I came out with the initscript hack bellow, that informs the user and
also extends the script actions.  Is this an acceptable workaround?

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages rasdaemon depends on:
ii  init-system-helpers  1.58
ii  libc62.31-3
ii  libdbd-sqlite3-perl  1.64-1+b1
ii  libsqlite3-0 3.32.3-1
ii  perl 5.30.3-4
ii  sqlite3  3.32.3-1

rasdaemon recommends no packages.

rasdaemon suggests no packages.

-- Configuration Files:
/etc/init.d/rasdaemon changed:
command -v rasdaemon >/dev/null 2>&1 || exit 0
. /lib/lsb/init-functions
pm=/proc/mounts
[ -r $pm ] || {
log_failure_msg "Can't read $pm"
exit 1
}
d=/sys/kernel/debug
t=debugfs
grep -qE "^[^[:blank:]]+[[:blank:]]+$d[[:blank:]]+$t[[:blank:]]" $pm || {
log_failure_msg "$t not mounted on $d"
exit 2
}
case $1 in
start)
log_action_begin_msg "Starting rasdaemon"
rasdaemon --record
log_action_end_msg "$?"
rasdaemon --enable
log_action_end_msg "$?"
ras-mc-ctl --register-labels
log_action_end_msg "$?"
;;
stop)
log_action_begin_msg "Stopping rasdaemon"
rasdaemon --disable
log_action_end_msg "$?"
;;
restart)
$0 stop
$0 start
;;
force-reload|status)
;;
*)
log_failure_msg "Usage: $0 start|stop|restart"
exit 3
;;
esac


-- no debconf information


Cheers,

-- 
Cristian

Bug#966289: Reassign

[Scott Talbert]

Control: reassign -1 ftp.debian.org

Bug#596193: A possible solution (and a workaround for anyone else finding this bug)

[Matthew Vernon]

Hi,

We encountered this issue, too - many of our systems are setup in the 
smarthost config, with /etc/mailname set to sanger.ac.uk. This mostly 
works - central LDAP means that user fred will reliably by fred at 
sanger.ac.uk, and so on.


The downside is that we can't then e.g. alias 'root' so that cron-mail 
goes to the person/team best placed to deal with it, and root at 
sanger.ac.uk gets too much automated email.


This is because:
i) qualify_domain is not a member of local_domains; so the qualified 
address root@qualify_domain is not considered by the system_aliases router
ii) in any case the smarthost router occurs before the system_aliases 
router, so even if you fix the above, it doesn't help


What we did was to change

domains = +local_domains

in the system_aliases router to

domains = +local_domains : $qualify_domain

To address point i) and then move the 
router/400_exim4-config_system_aliases block earlier in the config file 
(between router/150_exim4-config_hubbed_hosts and 
router/200_exim4-config_primary) - a similar effect can be achieved 
using the split files, obviously


I think this is a common enough configuration that providing better 
support for it in Debian would be useful - you could have a conditional 
block do the aliasing router earlier for smarthosts, or a separate 
alias-style router that just did qualify_domain, according to maintainer 
taste. But I think it's something that Debian could support more 
straightforwardly for users without much extra maintenance effort, so 
maybe Debian should do so?


Regards,

Matthew


--
The Wellcome Sanger Institute is operated by Genome Research 
Limited, a charity registered in England with number 1021457 and a 
company registered in England with number 2742969, whose registered 
office is 215 Euston Road, London, NW1 2BE. 

Bug#966289: (no subject)

[Scott Talbert]

Control: reassign -1 ftp.debian.org

Bug#966289: (no subject)

[Scott Talbert]

reassign -1 ftp.debian.org

Bug#927768: bash: 'read -e -u FD' reads from stdin if FD is a terminal

[Marriott NZ]

This bug is no longer reproducible on bash 5.1-alpha compiled from source (but 
it is reproducible on bash 5.0).

The changelog says:
g. `read -e' may now be used with arbitrary file descriptors (`read -u N').

That's probably it.

Bug#968356: transition: mysql-8.0

[Robie Basak]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Though this is a transition, I don't think it requires the usual
coordination with the release team because it won't entangle with
anything.

src:mysql-5.7 generates binary package libmysqlclient20 and is currently
in unstable. However, it is blocked from testing in favour of MariaDB by
order of the release team. Therefore libmysqlclient20 does not exist in
testing.

src:mysql-8.0 is ready in experimental and moves to libmysqlclient21.
I'd like to upload this to unstable.

Packages in unstable that need a MySQL client library build depend on
default-libmysqlclient-dev which sends them in MariaDB's direction. So
while this might be technically considered an unstable-only transition,
it should not affect testing.

The release team will presumably want to move the migration block on
src:mysql-5.7 to also include src:mysql-8.0.

Thanks,

Robie

Ben file:

title = "mysql-8.0";
is_affected = .depends ~ "libmysqlclient20" | .depends ~ "libmysqlclient21";
is_good = .depends ~ "libmysqlclient21";
is_bad = .depends ~ "libmysqlclient20";


signature.asc
Description: PGP signature

Bug#964558: Please change the ibus Recommends in ibus-data to a Suggests

[Rik Mills]

Could someone please make an upload to unstable with this change?
Kubuntu would like to see this change. Thanks.

Bug#963714: fatrace test issue still present - missing random events

[Christian Ehrhardt]

Hi,
I revisited this today and it still is present.

I tried 0.15 (groovy-proposed) and 0.13 (groovy-release) against the
current test of 0.15 and they both failed the same way. So it really is the
new test that seemed broken.

But then I looked deeper and it seems worse than I thought. [1] has
detailed steps on how I got there, but the TL;DR is that it misses random
events in a non reliable way.

I've had the test (already extended -s parameter and the following sleep to
ensure it is no late start or early exit) running in a loop a few times and
modified the log checking to report which matches are found and which are
missing.

   fatrace.log.7XZ3Ief : ...F...F.F - 3 matches missing
   fatrace.log.DHuzcGX : F. - 1 matches missing
   fatrace.log.DtQWtxF : ..FF.. - 2 matches missing
   fatrace.log.IPN1ZZX : ...F...F.F - 3 matches missing
   fatrace.log.JmcGCpx : .. - 0 matches missing
   fatrace.log.K06ToCE : .. - 0 matches missing
   fatrace.log.KSdRSG8 : ...F.. - 1 matches missing
   fatrace.log.NepBJN8 : ...F.. - 1 matches missing
   fatrace.log.OiECdoh : ..FF.F - 3 matches missing
   fatrace.log.TydkhKd : .. - 0 matches missing
   fatrace.log.UV22acQ : ...F.. - 1 matches missing
   fatrace.log.UxzxTRb : F. - 1 matches missing
   fatrace.log.VApdiDa : ..FF.F - 3 matches missing
   fatrace.log.Y8rSY2G : .. - 0 matches missing
   fatrace.log.ehxRpk7 : ...F.. - 1 matches missing
   fatrace.log.k8NBKKk : F..F.. - 2 matches missing
   fatrace.log.kLmSHVi : ...FF.F.FF - 5 matches missing
   fatrace.log.kb4wV7v : ...FF. - 2 matches missing
   fatrace.log.nsbCDTm : ..FF.. - 2 matches missing
   fatrace.log.oR5UZ58 : ..FF.. - 2 matches missing
   fatrace.log.qACUHvY : F.FF.. - 3 matches missing
   fatrace.log.rxWTYs5 : F...FF - 3 matches missing
   fatrace.log.rxrJBZl : .. - 0 matches missing
   fatrace.log.uCDFrK1 : ...F.. - 1 matches missing
   fatrace.log.uTSKJQF : ...F.. - 1 matches missing
   fatrace.log.wNQsl8z : .FF..FFF.. - 5 matches missing
   fatrace.log.zT5gLQF : ...F.. - 1 matches missing

This indicates that we miss a random set of events, sometimes none
sometimes half of them.

I know that events might be lost if the event queue is full, but on this
system not a lot is going on. I'm puzzled, does that make any sense to you?

[1]: https://bugs.launchpad.net/ubuntu/+source/fatrace/+bug/1885188
-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#539617: dpkg: Add option to suppress progress display while reading database

[Yuri Kanivetsky]

Hi,

stdout is not tty, but dpkg still produces a lot of output:


$ docker stop apt-quiet \
; docker run --rm --name apt-quiet -d cypress/base:12 sleep infinity \
&& docker exec apt-quiet sh -euxc '
[ -t 1 ] && echo tty || echo non-tty
&& ps -efH
&& export DEBIAN_FRONTEND=noninteractive
&& apt-get -qq update
&& apt-get -qq install less
'

apt-quiet
10ff09dfe813df80917d6a4b180f616c54ecd78267739eb5e0c79927410e55a4
non-tty
+ [ -t 1 ]
+ echo non-tty
+ ps -efH
UID  PIDPPID  C STIME TTY  TIME CMD
root   7   0  0 13:08 ?00:00:00 sh -euxc [ -t 1 ]
&& echo tty || echo non-tty && ps -efH && export
DEBIAN_FRONTEND=noninteractive && apt-get -qq update && apt-get -qq
install less
root  12   7  0 13:08 ?00:00:00   ps -efH
root   1   0 28 13:08 ?00:00:00 sleep infinity
+ export DEBIAN_FRONTEND=noninteractive
+ apt-get -qq update
+ apt-get -qq install less
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package less.
(Reading database ...  (Reading database ... 5% (Reading database ...
10% (Reading database ... 15% (Reading database ... 20% (Reading
database ... 25% (Reading database ... 30% (Reading database ... 35%
(Reading database ... 40% (Reading database ... 45% (Reading database
... 50% (Reading database ... 55% (Reading database ... 60% (Reading
database ... 65% (Reading database ... 70% (Reading database ... 75%
(Reading database ... 80% (Reading database ... 85% (Reading database
... 90% (Reading database ... 95% (Reading database ... 100% (Reading
database ... 33231 files and directories currently installed.)
Preparing to unpack .../less_487-0.1+b1_amd64.deb ...
Unpacking less (487-0.1+b1) ...
Setting up less (487-0.1+b1) ...
Processing triggers for mime-support (3.62) ...


Regards,
Yuri

Bug#968299: Desktot Xfcee in English and locales in Portuguese

[Aurelien Jarno]

control: reassign -1 xfce4

On 2020-08-12 18:12, Luis Duarte wrote:
> Package: locales
> Version: 2.24-11+deb9u4
> Severity: normal
> Tags: l10n
> 
> I would like to have Xfce in English and locales in Portuguese, automatically
> based on installation of Xfce. It is possible in Gnome to have this kind of
> configuration.

I am reassigning the bug to the xfce4 package as Xfce maintainers
probably have a better idea how to configure Xfce than the glibc
maintainers.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#968328: transition: gloox

[Graham Inggs]

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

Hi Vincent

On Thu, 13 Aug 2020 at 04:54, Vincent Cheng  wrote:
> I'd like to request a transition slot for src:gloox. This is a
> relatively small transition, with only 2 source packages affected
> (tested builds against newer gloox, currently in experimental, results
> are as follows):

Please go ahead with the upload to unstable.

Regards
Graham

Bug#968260: libc6: breaks translations when changing the charset to ...//TRANSLIT

[Aurelien Jarno]

control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=26383
control: tag -1 + upstream

On 2020-08-12 05:13, Vincent Lefevre wrote:
> Package: libc6
> Version: 2.31-3
> Severity: important
> 
> Since the upgrade to 2.31-3, the translations are no longer working
> in Mutt.
> 
> In my config, the charset gets automatically set to UTF-8//TRANSLIT
> (possibly with something else instead of UTF-8). There is the same
> issue with ISO-8859-1//TRANSLIT, but not with UTF-8 or ISO-8859-1.
> 
> Reverting to 2.31-2 solves the issue (at least with UTF-8//TRANSLIT).
> 
> I can reproduce the issue with:
> 
>   LC_MESSAGES=fr_FR /usr/bin/mutt -F muttrc foo
> 
> where the muttrc file contains:
> 
> set charset=UTF-8//TRANSLIT
> 
> or
> 
> set charset=ISO-8859-1//TRANSLIT
> 
> I get "To: foo@..." instead of "À : foo@...".

Thanks for the reproducer, I have been able to identify the broken
function, I have reported the bug upstream as BZ#26383. While it is
clearly a regression, please note that adding //TRANSLIT to the charset
doesn't bring anything, as transliteration is always enabled for gettext
messages.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#968355: O: dav-text -- minimalist ncurses-based text editor

[Adam Bilbrough]

Package: wnpp
Severity: normal

I intend to orphan the dav-text package.

I no longer believe that the effort to maintain it is worthwhile,
based on it's low usage.
.
I adopted it because I do use it for small scripts (and will continue
to do so), however the maintenance of the debian package no longer
makes sense.

Bug#968354: xpdf crash with empty document

[halfdog]

Package: xpdf
Version: 3.04-13
Severity: normal
Tag: security

On Debian Bullseye this crashes xpdf with coredump:

touch x.pdf; xpdf x.pdf

Funny, after a 2-byte Virtualbox (and now qemu) crash, this is 
the shortest input for a DoS-bug I have seen so far :-)

For xpdf this bug itself is not really a security risk: an attacker
could also send a white page document or no document at all if
he wants the victim not to see a document. Still someone familiar
with the code should look at it, maybe some half-broken document
could turn the NULL-dereference into something more useful.

rax0x0 0

   0x5556e6d0 <+16>:je 0x5556e6e0 

   0x5556e6d2 <+18>:mov%ebp,%eax
   0x5556e6d4 <+20>:pop%rbx
   0x5556e6d5 <+21>:pop%rbp
   0x5556e6d6 <+22>:pop%r12
   0x5556e6d8 <+24>:retq   
   0x5556e6d9 <+25>:nopl   0x0(%rax)
   0x5556e6e0 <+32>:mov0x8(%rbx),%rax
=> 0x5556e6e4 <+36>:mov(%rax),%rax   (doc is null)
   0x5556e6e7 <+39>:mov(%rax),%rdi 
   0x5556e6ea <+42>:callq  0x5557d730 


Relevant source:

int XPDFCore::loadFile(const GString *fileName, GString *ownerPassword,
   GString *userPassword) {
  int err;

  err = PDFCore::loadFile(fileName, ownerPassword, userPassword);
  if (err == errNone) {
// save the modification time
modTime = getModTime(doc->getFileName()->getCString());

// update the parent window
if (updateCbk) {
  (*updateCbk)(updateCbkData, doc->getFileName(), -1,
   doc->getNumPages(), NULL);
}
  }
  return err;
}

(gdb) print doc
$1 = (PDFDoc *) 0x0

If understand correctly, "PDFCore::loadFile" does not return
an error when processing an empty file, but also does not set
static variable "doc". This seems to be due to "xpdf/PDFCore.cc":

int PDFCore::loadFile2(PDFDoc *newDoc) {
  int err;
  double w, h, t;
  int i;

  // open the PDF file
  if (!newDoc->isOk()) {
err = newDoc->getErrorCode();
delete newDoc;
return err;
  }

...

The PDFDoc seems to come from "libpoppler.so.82" already and
detects the problem:

Syntax Error: Document stream is empty

On a quick glance I could not see this may result in !isOk()
but also "err" not set correctly. If error should be in libpoppler,
then this is the relevant version:

ii  libpoppler82:amd64   0.71.0-6
amd64PDF rendering library

Bug#949549: Not fixed

[Thomas Braun]

In [1] I still have

I: tango-accesscontrol: hardening-no-fortify-functions
usr/lib/tango/TangoAccessControl.

and checking with hardening-check gives the same output as before.

[1]: https://salsa.debian.org/science-team/tango/-/jobs/808832

Bug#968353: RFS: gxkb/0.8.2-1 [RC] -- X11 keyboard indicator and switcher

[Mateusz Łukasik]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: gxkb
   Version : 0.8.2-1
   Upstream Author : [fill in name and email of upstream]
 * URL : https://zen-tools.github.io/gxkb
 * License : PERMISSIVE, BSD-3-clause, GPL-2+, GAP
 * Vcs : https://github.com/mati75/gxkb.git
   Section : x11

It builds those binary packages:

  gxkb - X11 keyboard indicator and switcher

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/g/gxkb/gxkb_0.8.2-1.dsc

Changes since the last upload:

 gxkb (0.8.2-1) unstable; urgency=medium
 .
   [ Mateusz Łukasik ]
   * New upstream release. (Closes: #956771, #957325)
   * Bump Standards-Version to 4.5.0 (no changes needed)
   * Bump minimal dh version to 13.
   * d/patches:
 + Add fix-cross-build.patch for fix FTCBFS: hard codes the build
   architecture pkg-config (Closes: #958484)
   * d/control: Switch B-D from libappindicator-dev to
 libayatana-appindicator-dev.
 .
   [ Debian Janitor ]
   * Use secure copyright file specification URI.
   * debian/copyright: use spaces rather than tabs to start continuation
 lines.
   * Use secure URI in debian/watch.
   * Bump debhelper from old 10 to 12.
   * Set debhelper-compat version in Build-Depends.
   * Set upstream metadata fields: Archive, Bug-Database, Bug-Submit,
 Repository, Repository-Browse.

Regards,
--
  Mateusz Łukasik

Bug#968352: RFS: spacefm/1.0.6-5 [RC] -- Multi-panel tabbed file manager - GTK2 version

[Mateusz Łukasik]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: spacefm
   Version : 1.0.6-5
   Upstream Author : [fill in name and email of upstream]
 * URL : https://ignorantguru.github.io/spacefm/
 * License : GPL-2+, permissive, GAP~Makefile.in, GPL-3+, Zlib, LGPL-3+
 * Vcs : https://github.com/mati75/spacefm.git
   Section : utils

It builds those binary packages:

  spacefm-gtk3 - Multi-panel tabbed file manager - GTK3 version
  spacefm-common - Multi-panel tabbed file manager - common files
  spacefm - Multi-panel tabbed file manager - GTK2 version

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/spacefm/spacefm_1.0.6-5.dsc

Changes since the last upload:

 spacefm (1.0.6-5) unstable; urgency=medium
 .
   [ Debian Janitor ]
   * debian/copyright: use spaces rather than tabs to start continuation
 lines.
   * Wrap long lines in changelog entries: 1.0.6-1.
   * Use secure URI in Homepage field.
   * Set debhelper-compat version in Build-Depends.
   * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
 Repository-Browse.
   * Drop unnecessary dependency on dh-autoreconf.
 .
   [ Mateusz Łukasik ]
   * Fix FTBFS with gcc-10. (Closes: #957829)
 * debian/control:
 + Bump to Standards-Version to 4.5.0.

Regards,
--
  Mateusz Łukasik

Bug#968350: RFS: smplayer/20.6.0~ds0-1 -- Complete front-end for MPlayer and mpv

[Mateusz Łukasik]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: smplayer
   Version : 20.6.0~ds0-1
   Upstream Author : Ricardo Villalba 
 * URL : http://smplayer.sourceforge.net/
 * License : BSD-2-clause, GPL-2+, Expat, BSD-3-clause, LGPL-2+, 
LGPL-2.1+
 * Vcs : https://salsa.debian.org/multimedia-team/smplayer
   Section : video

It builds those binary packages:

  smplayer-l10n - Complete front-end for MPlayer and mpv - translation files
  smplayer - Complete front-end for MPlayer and mpv

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/smplayer/smplayer_20.6.0~ds0-1.dsc

Changes since the last upload:

 smplayer (20.6.0~ds0-1) unstable; urgency=medium
 .
   * New upstream release.
 + Update and refresh patches.
   * Bumped Standards-Version to 4.5.1, no changes needed
   * Add debian/patches/10_drop_DONATE_REMINDER.patch:
 - drop donate reminder. (Closes: #964359)

Regards,
--
  Mateusz Łukasik

Bug#968351: RM: ocaml-deriving-ocsigen -- ROM; obsolete

[Stéphane Glondu]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org

Dear FTP team,

Please remove ocaml-deriving-ocsigen from unstable. Its only
reverse-dependency was eliom which has just been updated to a version
that does not use it.


Cheers,

-- 
Stéphane

Bug#968348: NTP - Built without leap smear support.

[Maurizio Cimaschi]

Package: ntp
Version: 1:4.2.8p12+dfsg-4

Dear Maintainer,
trying to enable the "leap smearing" function, NTP complained in
the log file that it has been "built without LEAM_SMEAR support".
Please, could the package be rebuild with support for leap smearing ?

Thank you for your interest in the subject.

Kind regards.

Bug#968342: libgegl-sc-0.4.so: undefined symbol: __exp_finite

[Simon McVittie]

Control: retitle -1 libgegl-sc-0.4.so: undefined symbol: __exp_finite
Control: reassign -1 libgegl-0.4-0 0.4.12-2
Control: affects -1 + gimp
Control: tags -1 + bullseye sid
Control: clone -1 -2
Control: severity -2 minor
Control: retitle -2 libc6: please consider adding Breaks on libgegl-0.4-0 (<< 
0.4.18)
Control: reassign -2 libc6 2.31.2

On Thu, 13 Aug 2020 at 12:38:00 +0200, W Forum W wrote:
> Gimp does not start anymore (even after new install)
> 
> $ gimp
> GEGL-Message: Module '/usr/lib/x86_64-linux-gnu/gegl-0.4/seamless-clone.so'
> load error: /lib/x86_64-linux-gnu/libgegl-sc-0.4.so: undefined symbol:
> __exp_finite

This is fallout from upgrading glibc to 2.31. It appears to have
been fixed as a side-effect of build system changes in gegl 0.4.18, so
upgrading to the version of gegl from testing/unstable should fix this.

This can only affect partial upgrades from Debian 10 'buster' to
testing/unstable or the future Debian 11 'bullseye'. Pure Debian 10 systems
are unaffected, and so are pure testing/unstable systems.

> -- System Information:
> Debian Release: 10.5
> ii  libc62.31-2
> ii  libgegl-0.4-00.4.12-2

You appear to have a mixture of packages from the Debian 10 stable release,
and the Debian testing/unstable rolling release that will eventually get
released as Debian 11.

This is referred to as a "Frankendebian" system, and is not something that
can really be fully supported - we try to make it work, but realistically
the bugs that can happen during a partial upgrade will never all be found
or fixed. To make it work, you will have to upgrade some other packages
(in this case gegl, but probably a lot more) to their testing/unstable
versions.

smcv

Bug#968347: ITP: node-basic-auth-parser -- Parse Basic Auth Authorization HTTP headers

[merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: node-basic-auth-parser
  Version : 0.0.2
  Upstream Author : Maciej Małecki 
* URL : https://npmjs.com/package/basic-auth-parser
* License : Expat
  Programming Lang: JavaScript
  Description : Parse Basic Auth Authorization HTTP headers
 NodeJS package to parse Basic Auth Authorization HTTP headers.

This package is a dependency of node-proxy, which is required by
node-proxy-from-env, which is required by node-puppeteer.

Remark: This package is to be maintained with Debian Javascript
Maintainers at
   https://salsa.debian.org/js-team/node-basic-auth-parser

Bug#957837: sprng: ftbfs with GCC-10

[Dirk Eddelbuettel]

Nilesh,

On 12 August 2020 at 21:17, Nilesh wrote:
| Hi,
| 
| This patch fixes the build. Let me know if something else is needed:
| 
| --- a/SRC/primes_32.c
| +++ b/SRC/primes_32.c
| @@ -7,7 +7,7 @@
|  #define NO  0
|  #define NPRIMES 1000
|  
| -int primes[NPRIMES];
| +extern int primes[NPRIMES];
|  
|  #ifdef __STDC__
|  int init_prime_32(void)

Thanks!  That was easy enough -- my other gcc-10 "victim" (dieharder)
required much more extensive changes (but then CRAN already made me make the
same change last December (!!) when it was their turn to ask for gcc-10 fixes
in my R package RDieHarder using the same code).

I was about to let sprng die its natural cause as I had assumed that
r-cran-rsprng was its only reverse dependency (and that package was removed
from CRAN years ago).

As I now see that another package depends on sprng I will maintain sprng for
a while longer---but it too is outdated. Its build system was a mess, they
rewrote for sprng4 and sprng5 but I guess there is no real demand for that in
Debian.

I find it a little rude and inconstructive that this was NMUed without even
emailing me first, but that's just how it is with some people.

Cheers, Dirk

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

Bug#968231: global: does not index definitions with pygments anymore

[Gregory Heytings]

Hi Punit,



* When used, pygments only provide reference tags (GRTAGS) not 
definition tags




That's correct AFAIK.



* The definitions were provided by /usr/bin/ctags (in 6.4.4-3). "ctags" 
is usually a symlink pointing to one of few possible ctags 
implementations - ctags.emacs, exuberant-ctags, universal-ctags the ones 
I've come across.




Correct again.



* The pygments plugin script (/usr/share/global/gtags/script) has a 
dependency on exuberant ctags but may also be able compatible with other 
ctags implementations. It is possible to override this by using 
"ctagscom=" in the config file.




That's correct, except that there is no need to make this dependency too 
strict.  Universal Ctags is a fork of Exuberant Ctags, whose development 
has stopped some ten years ago.  Which means that Pygments works with 
Universal Ctags, and that the dependency is in fact "exuberant-ctags | 
universal-ctags".  With only Emacs ctags is installed, gtags with pygments 
displays:


/usr/bin/ctags: unrecognized option '--filter'
Try '/usr/bin/ctags --help' for a complete list of options.



Looking at these, the changes introduced in 6.4.4-4 seem to be headed in 
the right direction.




I do not fully agree with this statement.  I believe that Global should 
honor the choice of the user, who selected an implementation of ctags with 
Debian's "alternatives".  Perhaps there should be a better warning than 
the "unrecognized option '--filter'" when neither exuberant-ctags nor 
universal-ctags is installed.


Gregory

Bug#968346: maybe linked to libdrm-nouveau2

[Luc Maisonobe]

Looking more precisely at the backtrace in the core file,
the culprit seems to be here:

  #10 0x7f1c4420b5b2 in __assert_fail () from
/lib/x86_64-linux-gnu/libc.so.6
  #11 0x7f1c3d68143f in nouveau_pushbuf_data () from
/usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2

which appears in a different form in the journalctl output:

 août 13 11:31:51 lehrin gnome-shell[14075]: Xwayland:
../nouveau/pushbuf.c:723: nouveau_pushbuf_data: Assertion `kref' failed.


This looks a lot like bug #929130, registered more than one year
ago for libdrm-nouveau2 package.

Luc

Bug#968303: fish-common: pkgconfig lists /usr/local

[Norbert Preining]

Hi

> This is fixed upstream in 
> https://github.com/fish-shell/fish-shell/pull/6778 which is not in a 
> released version yet.

Good to hear!

> flatpak adds itself to XDG_DATA_DIRS via Xsession.d; I think that may
> be where these paths come from.

Indeed indeed - I didn't know I have that monster on my computer, sorry
for bothering about that. After purging the directories are gone.

Thanks

Norbert

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

Bug#968346: xwayland crashes randomly (core dumped) with nouveau driver

[Luc Maisonobe]

Package: xwayland
Version: 2:1.20.8-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I upgraded my hardware and installed a new motherboard/CPU/memory and basic
graphic card.
The new graphic card is a very basic MSI GeForce GT 710 2GD3H LP.

Now xwayland crashed randomly, causing gnome-shell to end. I get a black screen
first,
and then a gnome shell log screen. I can log again in a new gnome shell
session, but
all graphic applications have been killed at crash time.

The last crash happened while I had thunderbird and firefox opened but
otherwise
idle, and I was working on freecad. There was not special load on the machine.

After I logged in again, I found a core file in my home directory. The core
was created by xwayland. Opening the core file with gdb and printing the
backtrace,
I got this:

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/Xwayland :0 -rootless -noreset -accessx -core
-auth /run/user/1000/.mu'.
Program terminated with signal SIGABRT, Aborted.
[Current thread is 1 (Thread 0x7f1c439d9a40 (LWP 14075))]
(gdb) bt
#0  0x7f1c44212db1 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f1c441fc537 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x55adc1a612da in OsAbort ()
#3  0x55adc1a66643 in ?? ()
#4  0x55adc1a67496 in FatalError ()
#5  0x55adc1a5e745 in ?? ()
#6  
#7  0x7f1c44212db1 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x7f1c441fc537 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#9  0x7f1c441fc40f in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#10 0x7f1c4420b5b2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#11 0x7f1c3d68143f in nouveau_pushbuf_data () from /usr/lib/x86_64-linux-
gnu/libdrm_nouveau.so.2
#12 0x7f1c3d6813a3 in nouveau_pushbuf_data () from /usr/lib/x86_64-linux-
gnu/libdrm_nouveau.so.2
#13 0x7f1c3d6814bc in ?? () from /usr/lib/x86_64-linux-
gnu/libdrm_nouveau.so.2
#14 0x7f1c3d6818df in ?? () from /usr/lib/x86_64-linux-
gnu/libdrm_nouveau.so.2
#15 0x7f1c3d682399 in ?? () from /usr/lib/x86_64-linux-
gnu/libdrm_nouveau.so.2
#16 0x7f1c42b12acf in ?? () from /usr/lib/x86_64-linux-
gnu/dri/nouveau_dri.so
#17 0x7f1c42bbc2a3 in ?? () from /usr/lib/x86_64-linux-
gnu/dri/nouveau_dri.so
#18 0x7f1c42bbee3e in ?? () from /usr/lib/x86_64-linux-
gnu/dri/nouveau_dri.so
#19 0x7f1c42bbef77 in ?? () from /usr/lib/x86_64-linux-
gnu/dri/nouveau_dri.so
#20 0x7f1c42bc05fe in ?? () from /usr/lib/x86_64-linux-
gnu/dri/nouveau_dri.so
#21 0x7f1c423685a8 in ?? () from /usr/lib/x86_64-linux-
gnu/dri/nouveau_dri.so
#22 0x7f1c425bc9c4 in ?? () from /usr/lib/x86_64-linux-
gnu/dri/nouveau_dri.so
#23 0x55adc190d798 in ?? ()
#24 0x55adc190dc56 in ?? ()
#25 0x55adc1947647 in miCopyRegion ()
#26 0x55adc1947d86 in miDoCopy ()
#27 0x55adc190e6a4 in ?? ()
#28 0x55adc19d0076 in ?? ()
#29 0x55adc19c7742 in ?? ()
#30 0x55adc19c7c1e in ?? ()
#31 0x55adc19c67cc in ?? ()
#32 0x55adc1909c73 in ?? ()
#33 0x55adc1909ec7 in ?? ()
#34 0x55adc1a57ec0 in ?? ()
#35 0x55adc1a57f28 in ?? ()
#36 0x55adc1a58165 in WaitForSomething ()
#37 0x55adc1a283d3 in ?? ()
#38 0x55adc1a2c5e4 in ?? ()
#39 0x7f1c441fdcca in __libc_start_main () from /lib/x86_64-linux-
gnu/libc.so.6
#40 0x55adc18fe28a in _start ()


I also looked at journalctl and found the following lines that seem relevant to
the problem:

août 13 11:31:51 lehrin kernel: nouveau :2d:00.0: gr: TRAP ch 6 [007f97a000
Xwayland[14075]]
août 13 11:31:51 lehrin kernel: nouveau :2d:00.0: gr: GPC0/TPC0/TEX:
8049
août 13 11:31:51 lehrin kernel: nouveau :2d:00.0: fifo: fault 00 [READ] at
00257000 engine 00 [GR] client 01 [GPC0/T1_0] reason 02 [PTE] on
channel 6 [007f97a000 Xwayland[14075]]
août 13 11:31:51 lehrin kernel: nouveau :2d:00.0: fifo: channel 6: killed
août 13 11:31:51 lehrin kernel: nouveau :2d:00.0: fifo: runlist 0:
scheduled for recovery
août 13 11:31:51 lehrin kernel: nouveau :2d:00.0: fifo: engine 0: scheduled
for recovery
août 13 11:31:51 lehrin kernel: nouveau :2d:00.0: Xwayland[14075]: channel
6 killed!
août 13 11:31:51 lehrin gnome-shell[14075]: nouveau: kernel rejected pushbuf:
No such device
août 13 11:31:51 lehrin gnome-shell[14075]: nouveau: ch6: krec 0 pushes 1 bufs
9 relocs 0
août 13 11:31:51 lehrin gnome-shell[14075]: nouveau: ch6: buf  0003
0004 0004 
août 13 11:31:51 lehrin gnome-shell[14075]: nouveau: ch6: buf 0001 0008
0002 0002 0002
août 13 11:31:51 lehrin gnome-shell[14075]: nouveau: ch6: buf 0002 000b
0002 0002 
août 13 11:31:51 lehrin gnome-shell[14075]: nouveau: ch6: buf 0003 000a
0002 0002 0002
août 13 11:31:51 lehrin gnome-shell[14075]: nouveau: ch6: buf 0004 0006
0004  0004
août 13 11:31:51 lehrin gnome-shell[14075]: 

Bug#968344: pencil2d: please make the build reproducible

[Chris Lamb]

Source: pencil2d
Version: 0.6.4-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
pencil2d could not be built reproducibly.

While you do use SOURCE_DATE_EPOCH to populate GIT_TIMESTAMP, you omit
the --utc flag to date(1) so the generated date will depend on the
build system's current timezone.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   ` a/debian/rules  2020-08-13 11:34:56.164335215 +0100
--- b/debian/rules  2020-08-13 11:59:46.372680920 +0100
@@ -6,7 +6,7 @@
 
 # export information for the "About" screen
 include /usr/share/dpkg/pkg-info.mk
-timestamp=$(shell date +%Y-%m-%d -d "@$(SOURCE_DATE_EPOCH)")
+timestamp=$(shell date +%Y-%m-%d -d -u "@$(SOURCE_DATE_EPOCH)")
 export DEB_CXXFLAGS_MAINT_APPEND += -DGIT_TIMESTAMP=\\\"$(timestamp)\\\"
 
 %:

Bug#628571: Fix pending

[Johnny Willemsen]

Hi,

I have made a change for this issue, see
https://github.com/DOCGroup/ACE_TAO/pull/1184. Should be in the upcoming
ACE 6.5.11.

Best regards,

Johnny Willemsen
Remedy IT
http://www.remedy.nl

Bug#949035: blender: crashes when opening certain files

[Guillaume Clercin]

Dear Maintainer,

Works fine with version 2.83.4+dfsg-1 of blender.
I thinks this bug can be closed.

Cheers,
-- 
Guillaume Clercin

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

Bug#968322: tinyproxy exits 2 on standard systemd stop signal SIGTERM

[Mike Gabriel]

Control: severity -1 important

On  Do 13 Aug 2020 01:02:26 CEST, RDS wrote:


Package: tinyproxy
Version: 1.10.0-2+deb10u1

The default systemd stop signal (SIGTERM) on Buster machines cause  
tinyproxy to exit 2, which systemd then logs and reports as a  
tinyproxy failure. This is happening consistently on both a 32-bit  
and two 64-bit machines, at least after a first systemd stop of  
tinyproxy, which often (?never?) reports an exit failure, but does  
after each subsequent start-stop cycle.


Not sure where the root cause might be. Thought it best to let  
packaging (systemd) people consider it first.


Don't know if this is appropriate, but here's a solution that does  
not require any tinyproxy code changes. I've not examined its code  
to confirm this change is safe, but I've been using it without issue.



[...]



$ sudoedit /usr/lib/systemd/system/tinyproxy.service

# Add line 'KillSignal=SIGINT' to [Service] section.


This should rather be fixed in the tinyproxy code. I also sense this  
is an important bug, so raising severity. Will look into it (but  
patches welcome).


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp1Q24y3uvLN.pgp
Description: Digitale PGP-Signatur