Bug#933100: hg-git: autopkgtest needs update for new version of git

[Greg Price]

Control: affects -1 - src:git

On Fri, 26 Jul 2019 20:07:31 +0200 Paul Gevers  wrote:
> With a recent upload of git the autopkgtest of hg-git fails in testing
> when that autopkgtest is run with the binary packages of git from
> unstable. It passes when run with only packages from testing. In tabular
> form:
>passfail
> gitfrom testing1:2.22.0-1
> hg-git from testing0.8.12-1.1
> all others from testingfrom testing
>
> I copied some of the output at the bottom of this report. It seems your
> test is picky about capitalization of output generated by a binary (git)
> provided by the git package. Please fix your test.

I'm not quite sure whether this test in hg-git was ever fixed, but in
any case I believe it no longer affects git: the delay eventually
expired and a new git version migrated. (As have several more new
versions since then.)

Cheers,
Greg

Bug#959999: xz-utils FTBFS for musl: misdetects presence of gettex, locales go missing

[Helmut Grohne]

Source: xz-utils
Version: 5.2.4-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

xz-utils fails to build from source for musl-linux-any, because it uses
an old version of the gettext check that is not yet aware of C libraries
other than glibc and therefore thinks that musl didn't have a gettext.
Consequently, it opts out of using gettext and skips locale generation,
which ultimately makes the build fail.

Fortunately, the gettext macros have been fixed now and all we need to
do here is bump up the macro version being used. Note that there are
still symbol issues for xz-utils, which are not part of this bug. Please
consider applying the attached patch and close this bug when doing so.

Helmut
--- a/configure.ac
+++ b/configure.ac
@@ -609,7 +609,8 @@

 echo
 echo "Initializing gettext:"
-AM_GNU_GETTEXT_VERSION([0.19])
+AM_GNU_GETTEXT_REQUIRE_VERSION([0.19.8])
+AM_GNU_GETTEXT_VERSION([0.19.6])
 AM_GNU_GETTEXT([external])

Bug#956868: Use Realtek's r8101 driver

[Heiner Kallweit]

On 07.05.2020 16:14, Camaleón wrote:
> On Thu, 7 May 2020 12:20:54 +0200, Heiner Kallweit wrote:
> 
> Hello,
> 
>> RTL8401 (XID 240) was never supported by r8169.
>> Having said that nothing was dropped from the driver.
>> And most likely you don't have to compile r8101 yourself,
>> most distro's have a pre-compiled package.
> 
> How that can be? This computer perfectly detected the ethernet card 
> years ago (2013), using kernel 3.9.0-rc2 (Debian nomenclature) and r8169
> driver:
> 
> (dmesg excerpt)
> 
> [0.00] Linux version 3.9.0-rc2 (root@stt300) (gcc version 4.7.2 
> (Debian 4.7.2-5) ) #1 SMP Sun Mar 17 22:49:53 CET 2013
> 
> [0.00] DMI: Hewlett-Packard Compaq Mini CQ10-500 /148A, BIOS F.15 
> 01/14/2011
> 
> [6.558651] [drm] Initialized drm 1.1.0 20060810
> [6.573693] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> [6.574014] r8169 :01:00.0 (unregistered net_device): unknown MAC, 
> using family default

This is the key. There has never been native support for the RTL8401. In 
earlier times (until
end of 2018) we had a fallback to a default chip version for unknown chip 
versions.
This was removed because each chip version requires it's own specific 
initialization and quirks.
It's quite fortunate that your RTL8401 works properly if treated as RTL8101e.
What we can do is adding this as explicit assignment.

> [6.574358] r8169 :01:00.0: irq 43 for MSI/MSI-X
> [6.575005] r8169 :01:00.0 eth0: RTL8101e at 0xf8268000, 
> 68:b5:99:d3:c1:d8, XID 0400 IRQ 43:
> 
> (pci devices excerpt)
> 
> 01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
> RTL8101E/RTL8102E PCI Express Fast Ethernet controller [10ec:8136] (rev 04)
> Subsystem: Hewlett-Packard Company Device [103c:148a]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-  SERR-  Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 43
> Region 0: I/O ports at 2000 [size=256]
> Region 2: Memory at 90004000 (64-bit, prefetchable) [size=4K]
> Region 4: Memory at 9000 (64-bit, prefetchable) [size=16K]
> Capabilities: 
> Kernel driver in use: r8169
> 
> Greetings,
> 

Bug#959998: wmcore FTCBFS: hard codes the build architecture compiler

[Helmut Grohne]

Source: wmcore
Version: 0.0.2+ds-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

wmcore fails to cross build from source, because the upstream Makefile
hard codes the build architecture compilier. Please consider applying
the attached patch to make it substitutable.

Helmut
--- wmcore-0.0.2+ds.orig/Makefile
+++ wmcore-0.0.2+ds/Makefile
@@ -7,10 +7,10 @@
 
 
 .c.o:
-	cc $(CPPFLAGS) $(CFLAGS) -Wall -c -O3 $< -o $*.o
+	$(CC) $(CPPFLAGS) $(CFLAGS) -Wall -c -O3 $< -o $*.o
 
 wmlmon: $(OBJS)
-	cc $(LDFLAGS) -Wall -o wmcore $^ $(LIBDIR) $(LIBS)
+	$(CC) $(LDFLAGS) -Wall -o wmcore $^ $(LIBDIR) $(LIBS)
 
 clean::
 	for i in $(OBJS) ; do \

Bug#908712: Still present in stable

[Salvatore Bonaccorso]

Hi Martin, Arnaud,

On Mon, May 04, 2020 at 04:49:36PM +0800, Martin Michlmayr wrote:
> The fix got accepted upstream a long time ago and made it into
> unstable.
> 
> Unfortunately, even though Arnaud submitted it to the -stable tree and
> even though maintainer Andrew Lunn acked it, it never made it into
> the 4.19 stable series (despite several pings from Arnaud).

I see it was acked here
https://lore.kernel.org/netdev/2019080353.ga29...@lunn.ch/ and
applied to stable due to
https://lore.kernel.org/netdev/20190805.133134.1233042381014184856.da...@davemloft.net/
but usually Dave does only take backports for the last two stable
releases.

I have looked up the stable list but did not found any followup
specific with the 4.19 backport.

Might it be worth doing one last timme a request explicitly for a
backport to 4.19 including your patch, sending it to stable list, and
as required Cc'ed again to Andrew Lunn, Dave and the netdev list and
other required people?

The upstream commit d934423ac26e
("drivers/net/ethernet/marvell/mvmdio.c: Fix non OF case") does not
seem to apply cleanly to linux-4.19.y so the request should include
explicitly as well the backported version.

Does this helps?

Regards,
Salvatore

Bug#959997: Acknowledgement (python-pip-whl: pip incorrectly tries to build wheels in virtualenvs without wheel package)

[Nikhil Benesch]

I noticed a possible validation of the proposed solution. Upstream does
not include "wheel" in the list of packages that need to be vendored [0].
(But there is an over-selective glob that implicitly and inadvertently adds
wheel.whl to the path [1]).

[0]: 
https://github.com/pypa/pip/blob/5cac4dc6bd4c2150380d5368f2541357364b5d4b/src/pip/_vendor/__init__.py#L61-L114
[1]: 
https://github.com/pypa/pip/blob/5cac4dc6bd4c2150380d5368f2541357364b5d4b/src/pip/_vendor/__init__.py#L56-L58


On Fri, May 8, 2020 at 12:45 AM Debian Bug Tracking System
 wrote:
>
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 959997: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959997.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   nikhil.bene...@gmail.com
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  Debian Python Modules Team 
>
> If you wish to submit further information on this problem, please
> send it to 959...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 959997: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959997
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#959997: python-pip-whl: pip incorrectly tries to build wheels in virtualenvs without wheel package

[Nikhil Benesch]

Package: python-pip-whl
Version: 20.1-1
Severity: normal

This is a resubmission of #917006 and #884353 with more color. I believe
this is a Debian-specific problem, despite what the resolution of
#884353 claims.

Steps to reproduce:

$ python3 -m venv venv
$ venv/bin/pip install future
...
  Building wheel for future (setup.py) ... error
  ERROR: Command errored out with exit status 1:
   command: /venv/bin/python3 -u -c 'import sys, setuptools, tokenize; 
sys.argv[0] = '"'"'/tmp/pip-install-dosvesc9/future/setup.py'"'"'; 
__file__='"'"'/tmp/pip-install-dosvesc9/future/setup.py'"'"';f=getattr(tokenize,
 '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', 
'"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' 
bdist_wheel -d /tmp/pip-wheel-tkrzl6ct
   cwd: /tmp/pip-install-dosvesc9/future/
  Complete output (6 lines):
  usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
 or: setup.py --help [cmd1 cmd2 ...]
 or: setup.py --help-commands
 or: setup.py cmd --help

  error: invalid command 'bdist_wheel'
  
  ERROR: Failed building wheel for future
  Running setup.py clean for future
Failed to build future
Installing collected packages: future
Running setup.py install for future ... done
Successfully installed future-0.18.2

The though the package is still installed, the bdist_wheel failure is
loud and rendered in red, and makes it look as though the operation has
failed.

The problem, as described in #884353, is that `import wheel` works in
pip's context (from /share/python-wheels), but the wheel module is
not on sys.path when pip invokes `venv/bin/python setup.py bdist_wheel`.

Note that upstream pip handles the situation correctly by only trying to
invoke `bdist_wheel` if `import wheel` succeeds


https://github.com/pypa/pip/blob/ea9cb06c49c0f5dddf5c00e6770ebd5228e851e1/src/pip/_internal/utils/misc.py#L892-L901

but Debian patches make this check invalid.

This also reproduces with the example from #884353, which uses
`virtualenv --no-wheel` instead of `python -m venv`:

$ virtualenv --no-wheel venv
$ venv/bin/pip install future
...

The outcome and root cause are the same.

The fix is likely to stop packaging wheel.whl with python-pip-whl. As
far as I can tell, its only effect is to make this test wrong. The wheel
module seems never to be used by pip outside of the test. Users who want
to build wheels with pip will need to install the python3-wheel package
anyway (or `pip install wheel` inside of a venv.)

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

Kernel: Linux 5.4.0-28-generic (SMP w/64 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages python-pip-whl depends on:
ii  ca-certificates  20190110

python-pip-whl recommends no packages.

python-pip-whl suggests no packages.

-- no debconf information

Bug#959996: src:systemd: d/rules disables resolved DNSSEC on "stable Debian", but checks for stretch

[наб]

Package: src:systemd
Version: 245.5-2
Severity: normal

Dear Maintainer,

Around line 88, d/rules says this (also present on Salsa @ b9498a5):

-- >8 --
# resolved's DNSSEC support is still not mature enough, don't enable it by
# default on stable Debian or any Ubuntu releases
CONFFLAGS += $(shell grep -qE 'stretch|ubuntu' /etc/os-release && echo 
-Ddefault-dnssec=no)
-- >8 --

I don't know if DNSSEC support matured and this isn't needed anymore
anyway, but going by the comment this was probably overlooked
at some point; but now I looked at it, and here we are.

Best,
наб


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/24 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 
TAINT_FIRMWARE_WORKAROUND, 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


signature.asc
Description: PGP signature

Bug#959953: RFS: urlwatch/2.18-1 -- monitors webpages for you

[Adam Borowski]

On Thu, May 07, 2020 at 02:05:54PM +0200, Maxime Werlen wrote:
>  * Package name: urlwatch
>Version : 2.18-1

> Changes since the last upload:
> 
>* New upstream release
>* Updated Standards-Version to 4.5.0
>* Update Python minimum version to 3.5
>* Adjust patches to changed files
>* Removing Dockerfile from package
>* Add optional dependency on jsbeautifier

I'm afraid that it fails to repack the source:

 fakeroot debian/rules clean
dh clean --with python3 --buildsystem=pybuild
dh: error: unable to load addon python3: Can't locate 
Debian/Debhelper/Sequence/python3.pm in @INC (you may need to install the 
Debian::Debhelper::Sequence::python3 module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 
/usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at (eval 12) line 
1.
BEGIN failed--compilation aborted at (eval 12) line 1.

Looking at B-Deps, I see:
Build-Depends: debhelper (>= 12)
Build-Depends-Indep: dh-python, python3 (>= 3.5), python3-appdirs, 
python3-minidb, python3-nose, python3-pycodestyle, python3-requests,
 python3-setuptools, python3-yaml, python3-lxml, python3-cssselect

so stuff required to pack the source would need to be moved into regular
B-Deps.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#959944: ITP: xdg-desktop-portal-wlr -- xdg-desktop-portal backend for wlroots

[Mike Gabriel]

On  Do 07 Mai 2020 10:09:14 UTC, Birger Schacht wrote:


Package: wnpp
Severity: wishlist
Owner: Birger Schacht 

* Package name: xdg-desktop-portal-wlr
  Version : 0.1.0
  Upstream Author : Simon Ser
* URL : https://github.com/emersion/xdg-desktop-portal-wlr
* License : MIT
  Programming Lang: C
  Description : xdg-desktop-portal backend for wlroots

This package will provide support for the screenshot, screencast, and
possibly remote-desktop xdg-desktop-portal interfaces for wlroots based
compositors.
I plan to maintain it in the swaywm-team.


ping me if uou need a sponsor for this...

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

Bug#959423: [pkg-cryptsetup-devel] Bug#959423: cryptsetup-initramfs: MODULES=dep missed "ecb" since linux-5.6.0

[Adrien CLERC]

I saw the upload of 2:2.3.2-1, thanks for that!

I think the description should say Closes: #959423 but it says instead
that it's closing (my old) #901884.

Is it on purpose?

Bug#959995: coreutils: Please package new upstream release (8.32)

[Boyuan Yang]

Source: coreutils
Version: 8.30-3
Severity: important
Tags: sid  bullseye
X-Debbugs-CC: mst...@debian.org

Dear Debian coreutils maintainer,

The new version of coreutils has been available for quite some time. Please
consider packging it in Debian. Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#959994: codeville: Consider removing this package

[Boyuan Yang]

Source: codeville
Severity: serious
Version: 0.8.0-2.1
Tags: sid  bullseye
X-Debbugs-CC: jamu...@debian.org

Dear Debian codeville maintainer,

It seems that package codevilla has a dead upstream since at least 2014. It is
a discontinued VCS thus it doesn't make any sense to keep it in Debian
archive. Besides, this software is now affected by python2 removal.

As a result, I am proposing to have this package removed from Debian. I will
submit a removal request to FTP Masters 7 days later (after May 14, 2020). If
you have any thoughts, please let me know *immediately*.

-- 
Best Regards,
Boyuan Yang


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

Bug#959993: RM: syslog-summary -- RoQA: unmaintained Python2 package

[Jeremy Bicha]

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

Please remove syslog-summary from Debian unstable as part of the
Pyhon2 removal effort.

Its last maintainer upload was a decade ago and its last NMU was in
2015. There has been no response on the Python2 removal bug.

syslog-summary was recently removed from Testing and it depends on
python-magic which is no longer built in Debian.

References
---
https://bugs.debian.org/943282

Thank you,
Jeremy Bicha

Bug#959992: ITP: gitid -- A simple, minimal git identity management tool

[Luiserebii]

Package: wnpp
Severity: wishlist
Owner: Luiserebii 

* Package name: gitid
  Version : 0.3.1
  Upstream Author : Luiserebii 
* URL : https://github.com/Luiserebii/gitid
* License : GPL
  Programming Lang: C
  Description : A simple, minimal git identity management tool

gitid is a command line tool allowing for easy shifting between git identities 
(username, email, and signing key (e.g GPG)). It aims to make working with 
different git configurations easy and shifting between identities painless. 
Above all, the tool aims to reduce any possibility for user error. It is 
intended for people who need to manage multiple username/email/signing key 
configurations, and want to minimize the difficulties and risk of managing 
multiple repositories with multiple configurations. A short, readable guide may 
be found here: https://luiserebii.io/2020/05/introduction-to-gitid/

The alternative, to maintain a list of identities somewhere and to manually 
paste them into a new repo's .gitconfig allows for too much error, and it is 
not simple to manage.

This package intends to make this program useful for those who encounter this 
issue, and provide a unified interface to handle this. I personally use this 
package daily, and am therefore invested in maintaining it and making it useful 
for others.

I plan to maintain this package by following the typical Debian maintainment 
procedures, fixing bugs as reported. I also intend to be active in responding 
to new issues raised on the project's GitHub repository.

I do need a sponsor for this package, and would be grateful to receive any 
assistance. I plan to spend time making the package, before making a 
request-for-sponsorship.

Thank you!

Bug#959991: joblib: build and install documentation

[Sandro Tosi]

Source: joblib
Severity: normal

Hello,
the upstream tarball contains the doc dir, so please build it and ship it in a
-doc package.  sphinx-gallery will benefit from it since it uses joblib
intersphinx data for its tests.

Thanks!

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

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

Bug#959990: joblib: update Homepage field

[Sandro Tosi]

Source: joblib
Severity: normal

Hello,
Homepage points to http://packages.python.org/joblib/ but that's 404ing right
now. debian/copyright already points to https://github.com/joblib/joblib so
maybe update Homepage to the gh project?

thanks

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

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

Bug#938756: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).

[peter green]

On 07/05/2020 19:00, peter green wrote:

On 21/04/2020 22:20, Thomas Goirand wrote:

So, if I'm following correctly, what you seem to propose, is to remove
Python 2 from unittest2. If that's the case, then I agree with such a
plan. I just didn't dare to do it yet.

Though in fact, I already worked on that, but stopped, also because
unittest2 FTBFS when I try building it on my laptop. So I've pushed it
in its normal Git repo [1] under a py2-removal branch. If anyone has
some time available to look at it, that'd be nice (I currently don't...).
I got a failure too when I cloned that branch and tried to build it, but once I added in the changes from the previous NMU it built fine. I would push that addition back to the branch but i'm not currently a member of the python modules team, I requested to join but no response yet. 

I have now been added to the Debian python modules team and have pushed the 
commit importing the NMU changes.

Bug#959989: nftables: nft does not recognize imap service

[Artur Pydo]

Package: nftables
Version: 0.9.0-2
Severity: normal

Dear Maintainer,

While setting fail2ban with nftables (with default /etc/nftables.conf) the 
firewall initialization command failed on fail2ban start :

nft insert rule inet filter input tcp dport \{ 
smtp,465,submission,imap,imaps,pop3,pop3s \} ip saddr @f2b-postfix-sasl reject

failed with the following error : Error: Could not resolve service: Servname 
not found in nft services list
The error was related to 'imap' service.

However, in /etc/services imap service is defined as follows :
imap2   143/tcp imap# Interim Mail Access P 2 and 4

This service main name is 'imap2' and there is also an alias set to 'imap'.
It seems that nft does not take into account this service alias.

Replacing 'imap' with 'imap2' solved the nft problem :
nft insert rule inet filter input tcp dport \{ 
smtp,465,submission,imap2,imaps,pop3,pop3s \} ip saddr @f2b-postfix-sasl reject

Please note that to solve this problem in fail2ban, one have to change the 
default ports list in jail.local.
Example of working /etc/fail2ban/jail.local :
[DEFAULT]
banaction = nftables-multiport
banaction_allports = nftables-allports

[postfix-sasl]
enabled  = true
port = smtp,465,submission,imap2,imaps,pop3,pop3s

[dovecot]
enabled  = true
port= pop3,pop3s,imap2,imaps,submission,465,sieve

One may expect to have imap service resolved in nft and to have a default 
working configuration in fail2ban

Thanks for your attention.

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

Kernel: Linux 5.5.0-0.bpo.2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nftables depends on:
ii  dpkg  1.19.7
ii  libc6 2.28-10
ii  libgmp10  2:6.1.2+dfsg-4
ii  libjansson4   2.12-1
ii  libnftables0  0.9.0-2
ii  libreadline7  7.0-5

nftables recommends no packages.

nftables suggests no packages.

-- Configuration Files:
/etc/nftables.conf changed [not included]

-- no debconf information

Bug#933439: amule: Please rebuild against wxWidgets GTK 3 package

[Sandro Tosi]

> Does the crash you referenced here require connecting to file sharing
> networks to reproduce?

hard to say, as it crashed early on in the start up process (and also
because i dont really remember because several months have passed).

Clearly there's always a "risk" when using a file sharing software
that it connects to the network. that being said, there's no _legal_
issue is you dont have anything in download/upload: even if amule
connects to the enkey/kademlia networks it has nothing so share or
download, so that's just an empty client with no implications for the
IP address it connected to.

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

Bug#947720: sollya ftbfs with libfplll6

[Sudip Mukherjee]

Hi,

I tried to build this and did not get any failure.

+--+
| Summary  |
+--+

Build Architecture: amd64
Build Type: full
Build-Space: 163104
Build-Time: 388
Distribution: unstable
Host Architecture: amd64
Install-Time: 244
Job: sollya
Machine Architecture: amd64
Package: sollya
Package-Time: 636
Source-Version: 7.0+ds-3
Space: 163104
Status: successful
Version: 7.0+ds-3


The test has also passed:

Building check029.sh
PASS: check029.sh
Building check030.sh
PASS: check030.sh
Building check031.sh
PASS: check031.sh
Building timecheck.sh
PASS: timecheck.sh

Testsuite summary for sollya 7.0

# TOTAL: 32
# PASS:  32
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


Can you please retest and confirm.

--
Regards
Sudip

Bug#959971: jitsi: unable to hear or see other users in a room

[Florence Birée]

Same problem here. The binary from the firefox website works well…

-- 
Florence Birée


pgp8yr6ZRE1Fc.pgp
Description: Signature digitale OpenPGP

Bug#959981: Trademark concerns with Chef/Cinc package included in Debian and Ubuntu

[Lance Albertson]

I think removing it from Debian is the safe way to go currently. If you
want assistance with how we build Cinc and how it could be adapted for
Debian let me know. Also if there are any changes we can make on our end to
make it easier.

Thanks-

On Thu, May 7, 2020 at 2:14 PM Antonio Terceiro  wrote:

> On Thu, May 07, 2020 at 03:32:10PM -0400, benny Vasquez wrote:
> > Thanks, Lance!
> >
> > As he laid out, this packaged shipped as-is is a pretty serious violation
> > of our trademarks, and we'd like to see it addressed as soon as humanly
> > possible.
> >
> > On Thu, May 7, 2020 at 2:40 PM Lance Albertson  wrote:
> >
> > > All,
> > >
> > > I'm a member of the Cinc Project [1] which rebuilds and rebrands
> various
> > > Chef projects to comply with Chef Trademark Policy [2]. We have worked
> > > closely with Chef to ensure Cinc Client complies with this policy.
> > >
> > > A member of our community notified us today that it appears that Ubuntu
> > > [3] and Debian [4] are both including a package called "chef" which
> seems
> > > to pull in the Cinc source code but doesn't fully comply with the Chef
> > > Trademark Policy. We are concerned that this use of the Cinc Client in
> the
> > > manner it's currently presented will create an issue for us and you in
> the
> > > future unless this gets resolved quickly.
> > >
> > > Specifically, we are concerned with the following:
> > >
> > > 1. The package name should be cinc and not chef as Chef is trademarked
> and
> > > also causes users to think they are installing Chef when they are
> > > installing Cinc
> > > 2. The package should have proper attributions to include the Cinc
> Project
> > > including pointing any issues related to the package to our issue
> page, and
> > > not Chef
> > > 2. Running "chef-client" (or other similar commands) does not tell the
> > > user that it's actually using Cinc Client as our package does properly
> > > 3. All of the trademark renaming we did in our Cinc Client distribution
> > > seems to have been removed and retains all of the Chef related paths
> (i.e.
> > > /etc/chef when it should be /etc/cinc). This will cause confusion for
> users
> > > who are expecting Cinc.
> > >
> > > We would like to work with the Debian/Ubuntu maintainers to ensure
> you're
> > > following compliance and also ensuring our distribution works well on
> > > Debian/Ubuntu. However we also want to ensure you don't get into any
> legal
> > > trouble with Chef. I am sure most of these changes weren't done
> > > intentionally and was a mistake.
> > >
> > > Feel free to reach out to us via the #community-distros channel on the
> > > Chef Community Slack, or you can reach me directly via IRC on Freenode
> as
> > > "Ramereth".  I've also cc'd Benny Vasquez who is a community manager at
> > > Chef who can answer any questions relating to this and provide any
> > > additional feedback.
> > >
> > > Thanks!
> > >
> > > [1] https://cinc.sh/
> > > [2] https://www.chef.io/trademark-policy/
> > > [3] https://packages.ubuntu.com/focal/chef
> > > [4] https://packages.debian.org/sid/chef
>
> I am inclined to just remove chef from Debian as a way of fixing this.
>
> Maybe I will package cinc from scratch. That would be easier if there
> were proper source releases.
>


-- 
Lance Albertson
Director
Oregon State University | Open Source Lab

Bug#959943: FTBFS on ppc64el

[Frédéric Bonnard]

> > Here is a merge request for review :
> > https://salsa.debian.org/xorg-team/lib/mesa/-/merge_requests/13
> 
> this is merged now, and I commented that I hope you could send it upstream..

Thanks Timo!
I sent a merge request to mesa a few hours ago. But one of the file I
patched is actually copied by mesa from another project, so my merge
request needs to be split :
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4948

I'll follow up on that monday and will keep you updated.

Regards,

F.


pgp2xRJWm1gCx.pgp
Description: PGP signature

Bug#959424: [Pkg-clamav-devel] Bug#959424: Error: VirusEvent: fork failed

[Sebastian Andrzej Siewior]

control: tags -1 -a11y

On 2020-05-03 15:47:03 [+0200], Bernd Scheinbeth wrote:
> Hallo Sebastian,
Hi,

> sorry it's my first reportbug.

So there is a reply-all button in your email client. Please use so the
bug number remains in CC. 
You added a11y but based on what you just wrote I assume that this was
not on purporse (a11y is accessibility).

> When clamonacc or because clamav-daemon find a virus, they put it in the
> /root/quarantine folder The VirusEvent option should send a Email to me. But
> there is nothing. Even if I insert VirusEvent /usr/bin/mail -s "A Virus was
> Found %v" < /var/log/clamav.log or /bin/run-parts --lsbsysinit --
> /etc/clamav/virusevent.d/ or /root/detect there is no function. All this
> options are working for itself, but not with VirusEvent. In
> /var/clamav/clamav.log comes the error message Error: VirusEvent: fork
> failed.

Not really a clue but could you try again with apparmor disabled? Maybe
this one is disabling the fork function. If this is not it, then I would
have to dig deeper.

> I send you the clamonacc.service from systemd as an appendix
> 
> Bernd

Sebastian

Bug#959971: jitsi: unable to hear or see other users in a room

[Johan Fleury]

Package: firefox
Version: 76.0-2
Severity: important

Hi.

Since I upgraded to Firefox 76.0 on Debian Sid, I’m unable to hear or see other 
participants in a Jitsi Room (and they are unable to hear or see me). Other 
participants can hear each other perfectly fine.

I’ve reproduced this behaviour on three different installation of Debian Sid 
and multiple Jitsi servers. I’ve also reproduced with my main Firefox profile 
as well as with a new, empty profile.

I tested with some friends using Firefox 76.0 on Archlinux and they have no 
issue (apart that we can’t communicate together). I also tested with Jitsi on 
Android and with Chromium on Debian. None of these have issues.

Regards.

-- Package-specific info:

-- Addons package information

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox depends on:
ii  debianutils 4.9.1
ii  fontconfig  2.13.1-4
ii  libatk1.0-0 2.36.0-2
ii  libc6   2.30-7
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libdbus-1-3 1.12.16-2
ii  libdbus-glib-1-20.110-5
ii  libevent-2.1-7  2.1.11-stable-1
ii  libffi7 3.3-4
ii  libfontconfig1  2.13.1-4
ii  libfreetype62.10.1-2
ii  libgcc-s1   10-20200502-1
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-4
ii  libglib2.0-02.64.2-1
ii  libgtk-3-0  3.24.18-1
ii  libnspr42:4.25-1
ii  libnss3 2:3.52-1
ii  libpango-1.0-0  1.44.7-4
ii  libstdc++6  10-20200502-1
ii  libvpx6 1.8.2-1
ii  libx11-62:1.6.9-2+b1
ii  libx11-xcb1 2:1.6.9-2+b1
ii  libxcb-shm0 1.14-2
ii  libxcb1 1.14-2
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.5-2
ii  libxext62:1.3.3-1+b2
ii  libxfixes3  1:5.0.3-2
ii  libxrender1 1:0.9.10-1
ii  libxt6  1:1.1.5-1+b3
ii  procps  2:3.3.16-4
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages firefox recommends:
ii  libavcodec58  7:4.2.2-1+b1

Versions of packages firefox suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-7
ii  libgtk2.0-02.24.32-4
ii  pulseaudio 13.0-5

-- no debconf information

--
Johan Fleury
PGP Key ID : 0x5D404386805E56E6

signature.asc
Description: OpenPGP digital signature

Bug#959988: elixir : Depends: erlang-pcre-8.43 but it is not installable

[Rowan Cannaday]

Package: elixir
Severity: important

Dear Maintainer,

`apt-get install elixir` fails with the following error message:

The following packages have unmet dependencies:

 elixir : Depends: erlang-pcre-8.43 but it is not installable

E: Unable to correct problems, you have held broken packages.



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

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

Versions of packages elixir depends on:
ii  erlang-base1:22.3.3+dfsg-1
ii  erlang-crypto  1:22.3.3+dfsg-1
ii  erlang-inets   1:22.3.3+dfsg-1
ii  erlang-parsetools  1:22.3.3+dfsg-1
pn  erlang-pcre-8.43   
ii  erlang-public-key  1:22.3.3+dfsg-1
ii  erlang-tools   1:22.3.3+dfsg-1

elixir recommends no packages.

elixir suggests no packages.

Bug#959987: libsdl-sge: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: libsdl-sge
Version: 030809dfsg-9
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Hi Manuel,

In Ubuntu, we have moved the i386 architecture to a compatibility-only layer
on amd64, and therefore we are also moving our autopkgtest infrastructure to
test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The libsdl-sge tests currently fail in this environment, because they
include build tests that do not invoke the toolchain in a cross-aware
manner.  I've verified that the attached patch lets the tests successfully
build i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libsdl-sge-030809dfsg/debian/tests/compile-libsdl-sge-test0 
libsdl-sge-030809dfsg/debian/tests/compile-libsdl-sge-test0
--- libsdl-sge-030809dfsg/debian/tests/compile-libsdl-sge-test0 2015-08-24 
08:27:23.0 -0700
+++ libsdl-sge-030809dfsg/debian/tests/compile-libsdl-sge-test0 2020-05-07 
13:59:46.0 -0700
@@ -8,6 +8,12 @@
 
 set -e
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+  CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+  CROSS_COMPILE=
+fi
+
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
@@ -17,7 +23,7 @@
 # compile
 cp -v $EXAMPLESDIR/* .
 make clean
-make
+make CC=${CROSS_COMPILE}gcc CXX=${CROSS_COMPILE}g++
 echo "build: OK"
 
 # check/execute

Bug#959946: grace: fails to start: failed request: 12 (X_ConfigureWindow)

[Nicholas Breen]

On Thu, May 07, 2020 at 06:52:58PM +0800, Drew Parsons wrote:
> On a clean installation, grace fails to launch:
> 
> $ xmgrace
> X Error of failed request:  BadValue (integer parameter out of range for 
> operation)
>   Major opcode of failed request:  12 (X_ConfigureWindow)
>   Value in failed request:  0x0
>   Serial number of failed request:  2821
>   Current serial number in output stream:  2822

Hello Drew,

I cannot reproduce this on any of three systems.  If you have a residual
/etc/X11/app-defaults/XMgrace, can you try removing it?  Can you
generate a log with xtrace?



--
Nicholas Breen
nbr...@debian.org

Bug#889748: diagnostics FTBFS: FAIL: stacktrace

[Sudip Mukherjee]

Hi,

I tried to build it and did not get any failure.

Build Architecture: amd64
Build Type: full
Build-Space: 352384
Build-Time: 172
Distribution: unstable
Host Architecture: amd64
Install-Time: 37
Job: diagnostics
Machine Architecture: amd64
Package: diagnostics
Package-Time: 213
Source-Version: 0.3.3-12
Space: 352384
Status: successful
Version: 0.3.3-12

And this is the stacktrace test that failed before:

/usr/bin/make  check-TESTS
make[11]: Entering directory 
'/<>/diagnostics/extensions/stacktrace'
make[12]: Entering directory 
'/<>/diagnostics/extensions/stacktrace'
PASS: stacktrace

Testsuite summary for diagnostics 0.3.3

# TOTAL: 1
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


Can you please retest this and confirm..

--
Regards
Sudip

Bug#959986: freeglut: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: freeglut
Version: 2.8.1-5
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Hi Anton,

In Ubuntu, we have moved the i386 architecture to a compatibility-only layer
on amd64, and therefore we are also moving our autopkgtest infrastructure to
test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The freeglut tests currently fail in this environment, because they include
build tests that do not invoke the toolchain in a cross-aware manner, and do
not declare their test dependencies in a cross-friendly matter.  I've
verified that the attached patch lets the tests successfully build i386
tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru freeglut-2.8.1/debian/tests/build1 freeglut-2.8.1/debian/tests/build1
--- freeglut-2.8.1/debian/tests/build1  2014-05-23 14:30:30.0 -0700
+++ freeglut-2.8.1/debian/tests/build1  2020-05-07 13:19:37.0 -0700
@@ -4,6 +4,12 @@
 
 set -e
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+  CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+  CROSS_COMPILE=
+fi
+
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
@@ -389,7 +395,7 @@
 
 EOF
 
-gcc -o demo demo.c -lglut -lGL -lm
+${CROSS_COMPILE}gcc -o demo demo.c -lglut -lGL -lm
 echo "build: OK"
 [ -x demo ]
 #./demo
diff -Nru freeglut-2.8.1/debian/tests/build2 freeglut-2.8.1/debian/tests/build2
--- freeglut-2.8.1/debian/tests/build2  2014-05-24 00:15:59.0 -0700
+++ freeglut-2.8.1/debian/tests/build2  2020-05-07 13:19:52.0 -0700
@@ -4,6 +4,12 @@
 
 set -e
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+  CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+  CROSS_COMPILE=
+fi
+
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
@@ -264,7 +270,7 @@
 }
 EOF
 
-g++ -o demo demo.cpp -lglut -lGL -lGLU
+${CROSS_COMPILE}g++ -o demo demo.cpp -lglut -lGL -lGLU
 echo "build: OK"
 [ -x demo ]
 #./demo
diff -Nru freeglut-2.8.1/debian/tests/build3 freeglut-2.8.1/debian/tests/build3
--- freeglut-2.8.1/debian/tests/build3  2014-05-23 14:29:49.0 -0700
+++ freeglut-2.8.1/debian/tests/build3  2020-05-07 13:20:01.0 -0700
@@ -4,6 +4,12 @@
 
 set -e
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+  CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+  CROSS_COMPILE=
+fi
+
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
@@ -416,7 +422,7 @@
 
 EOF
 
-gcc -o demo demo.c -lglut -lGL
+${CROSS_COMPILE}gcc -o demo demo.c -lglut -lGL
 echo "build: OK"
 [ -x demo ]
 #./demo
diff -Nru freeglut-2.8.1/debian/tests/build4 freeglut-2.8.1/debian/tests/build4
--- freeglut-2.8.1/debian/tests/build4  2014-05-23 23:46:28.0 -0700
+++ freeglut-2.8.1/debian/tests/build4  2020-05-07 13:20:09.0 -0700
@@ -4,6 +4,12 @@
 
 set -e
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+  CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+  CROSS_COMPILE=
+fi
+
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
@@ -515,7 +521,7 @@
 
 EOF
 
-gcc -o demo demo.c -lglut -lGL
+${CROSS_COMPILE}gcc -o demo demo.c -lglut -lGL
 echo "build: OK"
 [ -x demo ]
 #./demo
diff -Nru freeglut-2.8.1/debian/tests/build5 freeglut-2.8.1/debian/tests/build5
--- freeglut-2.8.1/debian/tests/build5  2014-05-23 23:50:02.0 -0700
+++ freeglut-2.8.1/debian/tests/build5  2020-05-07 13:19:05.0 -0700
@@ -4,6 +4,12 @@
 
 set -e
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+  CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+  CROSS_COMPILE=
+fi
+
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
@@ -389,7 +395,7 @@
 
 EOF
 
-gcc -o demo demo.c -lglut -lGL -lm
+${CROSS_COMPILE}gcc -o demo demo.c -lglut -lGL -lm
 echo "build: OK"
 [ -x demo ]
 #./demo

Bug#959985: ifupdown-pre.service: Failed to start Helper to synchronize boot up for ifupdown

[Heinrich Schuchardt]

Package: ifupdown
Version: 0.8.35
Severity: normal

Dear Maintainer,

booting is slowed down by failing ifupdown_pre.service. The problem is
around since a few days only.

[FAILED] Failed to start Helper to …chronize boot up for ifupdown.
See 'systemctl status ifupdown-pre.service' for details.
[DEPEND] Dependency failed for Raise network interfaces.

● ifupdown-pre.service - Helper to synchronize boot up for ifupdown
   Loaded: loaded (/lib/systemd/system/ifupdown-pre.service; static;
vendor pres
   Active: failed (Result: exit-code) since Thu 2020-05-07 22:01:37
CEST; 3min 1
  Process: 269 ExecStart=/bin/sh -c if [ "$CONFIGURE_INTERFACES" != "no"
] && [
 Main PID: 269 (code=exited, status=1/FAILURE)

Feb 14 11:12:00 server systemd[1]: Starting Helper to synchronize boot up fo
May 07 22:01:37 server systemd[1]: ifupdown-pre.service: Main process exited
May 07 22:01:37 server systemd[1]: ifupdown-pre.service: Failed with result
May 07 22:01:37 server systemd[1]: Failed to start Helper to synchronize boo

My system is booted via iSCSI. So the only available network interface
is needed before the init process starts.

/etc/network/interfaces.d/eth0:
»»»
auto eth0
iface eth0 inet static
address 192.168.0.8
netmask 255.255.255.0
gateway 192.168.0.1

auto eth0:1
iface eth0:1 inet dhcp
«««

Best regards

Heinrich Schuchardt

-- Package-specific info:
--- /etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet manual
# This is an autoconfigured IPv6 interface
iface eth0 inet6 auto

--- /etc/network/interfaces.d/*:
auto eth0
iface eth0 inet static
address 192.168.123.28
netmask 255.255.255.0
gateway 192.168.123.254

auto eth0:1
iface eth0:1 inet dhcp

--- up and down scripts installed:
/etc/network/if-down.d:
total 4
-rwxr-xr-x 1 root root 919 Sep 16  2018 sendmail

/etc/network/if-post-down.d:
total 4
-rwxr-xr-x 1 root root 919 Sep 16  2018 sendmail

/etc/network/if-pre-up.d:
total 0

/etc/network/if-up.d:
total 4
-rwxr-xr-x 1 root root 1714 Sep 16  2018 sendmail


-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: arm64 (aarch64)

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

Versions of packages ifupdown depends on:
ii  adduser   3.118
ii  iproute2  4.20.0-2
ii  libc6 2.28-10
ii  lsb-base  10.2019051400

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.1-2

Versions of packages ifupdown suggests:
pn  ppp 
pn  rdnssd  

-- no debconf information

Bug#959981: Trademark concerns with Chef/Cinc package included in Debian and Ubuntu

[Antonio Terceiro]

On Thu, May 07, 2020 at 03:32:10PM -0400, benny Vasquez wrote:
> Thanks, Lance!
> 
> As he laid out, this packaged shipped as-is is a pretty serious violation
> of our trademarks, and we'd like to see it addressed as soon as humanly
> possible.
> 
> On Thu, May 7, 2020 at 2:40 PM Lance Albertson  wrote:
> 
> > All,
> >
> > I'm a member of the Cinc Project [1] which rebuilds and rebrands various
> > Chef projects to comply with Chef Trademark Policy [2]. We have worked
> > closely with Chef to ensure Cinc Client complies with this policy.
> >
> > A member of our community notified us today that it appears that Ubuntu
> > [3] and Debian [4] are both including a package called "chef" which seems
> > to pull in the Cinc source code but doesn't fully comply with the Chef
> > Trademark Policy. We are concerned that this use of the Cinc Client in the
> > manner it's currently presented will create an issue for us and you in the
> > future unless this gets resolved quickly.
> >
> > Specifically, we are concerned with the following:
> >
> > 1. The package name should be cinc and not chef as Chef is trademarked and
> > also causes users to think they are installing Chef when they are
> > installing Cinc
> > 2. The package should have proper attributions to include the Cinc Project
> > including pointing any issues related to the package to our issue page, and
> > not Chef
> > 2. Running "chef-client" (or other similar commands) does not tell the
> > user that it's actually using Cinc Client as our package does properly
> > 3. All of the trademark renaming we did in our Cinc Client distribution
> > seems to have been removed and retains all of the Chef related paths (i.e.
> > /etc/chef when it should be /etc/cinc). This will cause confusion for users
> > who are expecting Cinc.
> >
> > We would like to work with the Debian/Ubuntu maintainers to ensure you're
> > following compliance and also ensuring our distribution works well on
> > Debian/Ubuntu. However we also want to ensure you don't get into any legal
> > trouble with Chef. I am sure most of these changes weren't done
> > intentionally and was a mistake.
> >
> > Feel free to reach out to us via the #community-distros channel on the
> > Chef Community Slack, or you can reach me directly via IRC on Freenode as
> > "Ramereth".  I've also cc'd Benny Vasquez who is a community manager at
> > Chef who can answer any questions relating to this and provide any
> > additional feedback.
> >
> > Thanks!
> >
> > [1] https://cinc.sh/
> > [2] https://www.chef.io/trademark-policy/
> > [3] https://packages.ubuntu.com/focal/chef
> > [4] https://packages.debian.org/sid/chef

I am inclined to just remove chef from Debian as a way of fixing this.

Maybe I will package cinc from scratch. That would be easier if there
were proper source releases.


signature.asc
Description: PGP signature

Bug#959984: krb5: Add "Multi-Arch: foreign" to krb5-doc

[Andreas Hasenack]

Package: krb5
Version: 1.17-7
Severity: normal

Dear Maintainer,

Adding multi-arch foreign to krb5-doc allows it to be used as a
dependency of architecture-dependent packages.

For example, this will then work on an amd64 host:

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install krb5-doc:i386

Instead of:

Package krb5-doc:i386 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

This error was triggered in Ubuntu i386 builds due to our slow
deprecation of the i386 architecture. See
https://lists.ubuntu.com/archives/ubuntu-devel/2019-December/040859.html
and similar threads for details.

I understand this is not an issue Debian needs to fix on their side,
but I'm submitting it here with the goal of keeping our delta (which
is nonexistent at the moment) small.

I filed a salsa MR about this at
https://salsa.debian.org/debian/krb5/-/merge_requests/4

Thanks!

Bug#959983: sqlite3: Upstream changelog not in easily viewable format

[Ben Hutchings]

Package: sqlite3
Version: 3.27.2-3
Severity: minor

Dear Maintainer,

The upstream changelog is provided in HTML format, compressed with
gzip.  Neither Chromium nor Firefox can display this, unless it is
first uncompressed to another file.

While Debian policy does say you should use changelog.html.gz (and that
seems like a bug in policy), it also says that changelog.gz "should be
generated" from it.  In sqlite3 it just refers back to the HTML
version.

Ben.

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/2 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)
LSM: AppArmor: enabled

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom

Bug#959388: [Pkg-privacy-maintainers] Bug#959388: torbrowser fails to start due to lacking fonts/* entry in apparmor

[Santiago R.R.]

El 07/05/20 a las 22:30, Roger Shimizu escribió:
> On Thu, May 7, 2020 at 9:41 PM Santiago R.R.  wrote:
> >
> > I have unsuccessfully tried to reproduce the bug in the same machine,
> > even removing my .local/share/torbrowser/ directory. I still see the
> > apparmor DENIED message in the logs, but torbrowser starts without
> > issues.
> 
> If you see the DENIED log in dmesg, the problem still exists.
> And if after the apparmor patch, the DENIED log gets gone, that tells
> us the patch is valid.
> 
> > So sorry if this bug is just noise.
> 
> Just double confirm my question above. and we'll decide whether to
> move forward to the pull-request.
> Thank you!

I can confirm I see the DENIED without the patch, if
.local/share/torbrowser/ is clean. No messages with the patch.

Cheers!

 -- S


signature.asc
Description: PGP signature

Bug#959982: kerberos-configs: Set Multi-Arch to foreign

[Andreas Hasenack]

Package: kerberos-configs
Version: 2.6
Severity: normal

Dear Maintainer,

Setting multi-arch to foreign allows the krb5-config package to be
used as a dependency of architecture-dependent packages, like
krb5-user. I filed a salsa MR for this at
https://salsa.debian.org/debian/kerberos-configs/-/merge_requests/1

For example, with this fix the following will work on an amd64 host:

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install krb5-user:i386

This is similar to
https://salsa.debian.org/debian/krb5/-/merge_requests/4, and Ubuntu
needs that change due to its phasing out of the i386 architecture. See
https://lists.ubuntu.com/archives/ubuntu-devel/2019-December/040859.html
and similar threads for details.

I realize this is not an immediate problem for Debian, but we would
like to keep the delta between these packages in Ubuntu and Debian to
a minimum.

Thanks!

Bug#959981: Trademark issues with Chef/Cinc package included in Debian

[Antonio Terceiro]

Package: chef
Version: 15.8.25.3.gcf41df6a2-6
Severity: serious
X-Debbugs-CC: la...@osuosl.org, maintain...@cinc.sh, be...@chef.io

- Forwarded message from Lance Albertson  -

Date: Thu, 7 May 2020 11:40:38 -0700
From: Lance Albertson 
To: pkg-ruby-extras-maintain...@lists.alioth.debian.org, terce...@debian.org, 
ubuntu-m...@lists.ubuntu.com
Cc: maintain...@cinc.sh, be...@chef.io
Subject: Trademark concerns with Chef/Cinc package included in Debian and Ubuntu
X-Spam-Level: 
X-Spam-Status: No, score=0.5 required=3.0 tests=BAYES_00,DKIM_SIGNED, 
DKIM_VALID,HTML_MESSAGE,SPF_SOFTFAIL,URIBL_BLOCKED,URIBL_SBL, URIBL_SBL_A 
autolearn=no autolearn_force=no
version=3.4.2
Message-ID: 

All,

I'm a member of the Cinc Project [1] which rebuilds and rebrands various
Chef projects to comply with Chef Trademark Policy [2]. We have worked
closely with Chef to ensure Cinc Client complies with this policy.

A member of our community notified us today that it appears that Ubuntu [3]
and Debian [4] are both including a package called "chef" which seems to
pull in the Cinc source code but doesn't fully comply with the Chef
Trademark Policy. We are concerned that this use of the Cinc Client in the
manner it's currently presented will create an issue for us and you in the
future unless this gets resolved quickly.

Specifically, we are concerned with the following:

1. The package name should be cinc and not chef as Chef is trademarked and
also causes users to think they are installing Chef when they are
installing Cinc
2. The package should have proper attributions to include the Cinc Project
including pointing any issues related to the package to our issue page, and
not Chef
2. Running "chef-client" (or other similar commands) does not tell the user
that it's actually using Cinc Client as our package does properly
3. All of the trademark renaming we did in our Cinc Client distribution
seems to have been removed and retains all of the Chef related paths (i.e.
/etc/chef when it should be /etc/cinc). This will cause confusion for users
who are expecting Cinc.

We would like to work with the Debian/Ubuntu maintainers to ensure you're
following compliance and also ensuring our distribution works well on
Debian/Ubuntu. However we also want to ensure you don't get into any legal
trouble with Chef. I am sure most of these changes weren't done
intentionally and was a mistake.

Feel free to reach out to us via the #community-distros channel on the Chef
Community Slack, or you can reach me directly via IRC on Freenode as
"Ramereth".  I've also cc'd Benny Vasquez who is a community manager at
Chef who can answer any questions relating to this and provide any
additional feedback.

Thanks!

[1] https://cinc.sh/
[2] https://www.chef.io/trademark-policy/
[3] https://packages.ubuntu.com/focal/chef
[4] https://packages.debian.org/sid/chef

-- 
Lance Albertson
Director
Oregon State University | Open Source Lab

- End forwarded message -


signature.asc
Description: PGP signature

Bug#959980: TAG: libgwavi -- c library for generating avi files

[folkert]

Package: WNPP
Severity: ITP

Bug#959979: TAG: constatus -- video monitoring system

[folkert]

Package: WNPP
Severity: ITP

Bug#959975: mesa: FTBFS on hurd-i386

[Timo Aaltonen]

On 7.5.2020 21.02, Svante Signell wrote:
> Source: mesa
> Version: 20.0.6-1
> Severity: important
> Tags: ftbfs, patch
> User: debian-h...@lists.debian.org
> Usertags: hurd
> 
> Hello,
> 
> Currently mesa FTBFS on GNU/Hurd due to a missing struct definition. Version 
> 20-0.4-2 built successfully earlier. The attached patch
> src_glx_dri_common.h.diff fixes that problem. Strangely this problem does not
> occur for other builds. Probably this is due to that all other architectures 
> use
> llvm for the build while the build for Hurd is with gcc.
> 
> This patch is also needed to build 20.1.0~rc1-1 from experimental together 
> with
> a new PATH_MAX patch. That patch will be submitted in a separate bug report.
> 
> Thanks!
> 

Ok, thanks.. and please send these upstream too.


-- 
t

Bug#959943: FTBFS on ppc64el

[Timo Aaltonen]

On 7.5.2020 13.34, Frédéric Bonnard wrote:
> Control: tags -1 patch
> 
> --
> 
> Here is a merge request for review :
> https://salsa.debian.org/xorg-team/lib/mesa/-/merge_requests/13

this is merged now, and I commented that I hope you could send it upstream..


-- 
t

Bug#959500: misleading 'You need to be root' when Linux is in Lockdown mode

[John Scott]

Control: tags -1 + upstream

On Tuesday, May 5, 2020 7:07:39 AM EDT Gürkan Myczko wrote:
> The error message:
> ERROR: Could not get I/O privileges (Operation not permitted).
> to me and #flashrom is not misleading at all.

I had overlooked that part and fixated on the last line about root.
However 'You need to be root' sounds too strong IMHO especially since
that's not what's really necesarry. Maybe a message more like
  E: Unable to acquire the dpkg frontend lock, are you root?
would be fitting.

Thanks for giving me the gumption to try strace. With it I got the attached
output showing iopl() is throwing the error. Its man page says
ERRORS
  EPERM  The calling process has insufficient privilege to call iopl();
the CAP_SYS_RAWIO capability is required to raise the I/O privilege level
above its current value.
So maybe root isn't necessary in general.

With gdb the problem seems to be at
#0  rget_io_perms () at ../hwaccess.c:119
#1  0x5559fbab in internal_init () at ../internal.c:213
#2  0x555b706a in programmer_init (prog=PROGRAMMER_INTERNAL, param=0x0) 
at ../flashrom.c:555
#3  0x555ccffe in main (argc=5, argv=0x7fffe608) at 
../cli_classic.c:459

int rget_io_perms(void)
{
#if IS_X86 && !(defined(__DJGPP__) || defined(__LIBPAYLOAD__))
#if defined (__sun)
if (sysi86(SI86V86, V86SC_IOPL, PS_IOPL) != 0) {
#elif USE_DEV_IO
if ((io_fd = open("/dev/io", O_RDWR)) < 0) {
#elif USE_IOPERM
if (ioperm(0, 65536, 1) != 0) {
#elif USE_IOPL
if (iopl(3) != 0) {
#endif
msg_perr("ERROR: Could not get I/O privileges (%s).\n", 
strerror(errno));
msg_perr("You need to be root.\n");


I was pointed to it by the Linux commit [1], that on my system I can read
/sys/kernel/security/lockdown as root which says
none [integrity] confidentiality

I hope this can provide a check comparable to the OpenBSD and NetBSD ones
there.

If you have Linux 5.4+ you might be able to boot with lockdown=integrity
(EFI/Secure Boot not necessary) and reproduce this way.

Please let me know if you'd be helped by any more details. I hope this can be
solved cleanly.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4execve("/usr/sbin/flashrom", ["flashrom", "--programmer", "internal", "-r", 
"woo"], 0x7ffebadd4dc0 /* 20 vars */) = 0
brk(NULL)   = 0x564f5f7a9000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=197499, ...}) = 0
mmap(NULL, 197499, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc50c0ba000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libusb-1.0.so.0", O_RDONLY|O_CLOEXEC) = 
3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260G\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=109552, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fc50c0b8000
mmap(NULL, 112016, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc50c09c000
mmap(0x7fc50c0a, 57344, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x7fc50c0a
mmap(0x7fc50c0ae000, 32768, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x12000) = 0x7fc50c0ae000
mmap(0x7fc50c0b6000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19000) = 0x7fc50c0b6000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpci.so.3", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P5\0\0\0\0\0\0"..., 832) 
= 832
fstat(3, {st_mode=S_IFREG|0644, st_size=60024, ...}) = 0
mmap(NULL, 62096, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc50c08c000
mprotect(0x7fc50c08f000, 45056, PROT_NONE) = 0
mmap(0x7fc50c08f000, 28672, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fc50c08f000
mmap(0x7fc50c096000, 12288, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0xa000) = 0x7fc50c096000
mmap(0x7fc50c09a000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd000) = 0x7fc50c09a000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libftdi1.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2004\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=59872, ...}) = 0
mmap(NULL, 62024, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc50c07c000
mmap(0x7fc50c07f000, 32768, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fc50c07f000
mmap(0x7fc50c087000, 12288, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0xb000) = 0x7fc50c087000
mmap(0x7fc50c08a000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd000) = 0x7fc50c08a000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) 

Bug#959977: obs-api: does not include application.css

[folkert]

> I installed obs-api.
> It works mostly only the web-interface is broken: this is due to
> /stylesheets/webui/application.css and other web-files missing.

I removed obs-api and did a new install.
Then when I ran /usr/share/obs/api/script/rake-tasks.sh setup I got a
few errors. Stylesheets etc are still missing.

/usr/lib/ruby/vendor_ruby/mysql2/error.rb:55: warning: Using the last argument 
as keyword parameters is deprecated
/usr/lib/ruby/vendor_ruby/mysql2/error.rb:94: warning: Using the last argument 
as keyword parameters is deprecated
Database 'obsapi' already exists
/usr/share/rubygems-integration/all/gems/activerecord-5.2.4.1/lib/active_record/connection_adapters/mysql/database_statements.rb:12:
 warning: Using the last argument as keyword parameters is deprecated; maybe ** 
should be added to the call
/usr/share/rubygems-integration/all/gems/activerecord-5.2.4.1/lib/active_record/connection_adapters/abstract/query_cache.rb:95:
 warning: The called method `select_all' is defined here
/usr/share/rubygems-integration/all/gems/activerecord-5.2.4.1/lib/active_record/transactions.rb:212:
 warning: Using the last argument as keyword parameters is deprecated; maybe ** 
should be added to the call
/usr/share/rubygems-integration/all/gems/activerecord-5.2.4.1/lib/active_record/connection_adapters/abstract/database_statements.rb:260:
 warning: The called method `transaction' is defined here
/usr/share/rubygems-integration/all/gems/activerecord-5.2.4.1/lib/active_record/connection_adapters/abstract/transaction.rb:171:
 warning: Using the last argument as keyword parameters is deprecated; maybe ** 
should be added to the call
/usr/share/rubygems-integration/all/gems/activerecord-5.2.4.1/lib/active_record/connection_adapters/abstract/transaction.rb:97:
 warning: The called method `initialize' is defined here
/usr/share/rubygems-integration/all/gems/activemodel-5.2.4.1/lib/active_model/type/integer.rb:13:
 warning: Using the last argument as keyword parameters is deprecated; maybe ** 
should be added to the call
/usr/share/rubygems-integration/all/gems/activemodel-5.2.4.1/lib/active_model/type/value.rb:8:
 warning: The called method `initialize' is defined here
/usr/share/rubygems-integration/all/gems/activerecord-5.2.4.1/lib/active_record/relation/delegation.rb:132:
 warning: Using the last argument as keyword parameters is deprecated; maybe ** 
should be added to the call
/usr/share/rubygems-integration/all/gems/activerecord-5.2.4.1/lib/active_record/relation.rb:25:
 warning: The called method `initialize' is defined here
/usr/share/rubygems-integration/all/gems/activerecord-5.2.4.1/lib/active_record/persistence.rb:705:
 warning: Using the last argument as keyword parameters is deprecated; maybe ** 
should be added to the call
/usr/share/rubygems-integration/all/gems/activerecord-5.2.4.1/lib/active_record/timestamp.rb:105:
 warning: The called method `_update_record' is defined here
/usr/share/rubygems-integration/all/gems/activerecord-5.2.4.1/lib/active_record/associations.rb:1855:
 warning: Using the last argument as keyword parameters is deprecated; maybe ** 
should be added to the call
/usr/share/rubygems-integration/all/gems/activerecord-5.2.4.1/lib/active_record/associations.rb:1368:
 warning: The called method `has_many' is defined here
bundler: command not found: writeconfiguration
Install missing gem executables with `bundle install`
Run in api.
`/root` is not writable.
Bundler will use `/tmp/bundler20200507-24301-qzlloj24301' as your home 
directory temporarily.
Rails Error: Unable to access log file. Please ensure that 
/usr/share/obs/api/log/production.log exists and is writable (ie, make it 
writable for user and group: chmod 0664 /usr/share/obs/api/log/production.log). 
The log level has been raised to WARN and the output directed to STDERR until 
the problem is fixed.
I, [2020-05-07T20:38:57.829887 #24301]  INFO -- : Writing 
/usr/share/obs/api/public/assets/webui/application/cm2/index-e27139c45f6ef69ad021ee93390421d2e5678b1f7720aeaf4ddbc2c7f91ac50a.js
I, [2020-05-07T20:38:57.830339 #24301]  INFO -- : Writing 
/usr/share/obs/api/public/assets/webui/application/cm2/index-e27139c45f6ef69ad021ee93390421d2e5678b1f7720aeaf4ddbc2c7f91ac50a.js.gz
I, [2020-05-07T20:39:01.550639 #24301]  INFO -- : Writing 
/usr/share/obs/api/public/assets/webui/application/cm2/index-diff-0ebb8c72c0a49c913e2c74acd75ba836dad39195e266c1f99863eb86e99ce381.js
I, [2020-05-07T20:39:01.550839 #24301]  INFO -- : Writing 
/usr/share/obs/api/public/assets/webui/application/cm2/index-diff-0ebb8c72c0a49c913e2c74acd75ba836dad39195e266c1f99863eb86e99ce381.js.gz
I, [2020-05-07T20:39:05.253283 #24301]  INFO -- : Writing 
/usr/share/obs/api/public/assets/webui/application/cm2/index-xml-7194be093c9b9ff3deb4050e0263de35429b0ed04019ddaca1d5b24d015da34e.js
I, [2020-05-07T20:39:05.253518 #24301]  INFO -- : Writing 

Bug#959978: libpango1.0-0: Newer version needed (depending on newest libpango-1.0-0, etc.)

[Alexandre Lymberopoulos]

Package: libpango1.0-0
Version: 1.42.4-8
Severity: normal

Dear Maintainer,

In my system, I must hold the dependencies below, since libpango1.0-0
depends on those exact versions. They can be updated do 1.44.7-4, so
should be libpango1.0-0, right?

Thanks in advance,
Alexandre

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libpango1.0-0 depends on:
hi  libpango-1.0-0   1.42.4-8
hi  libpangocairo-1.0-0  1.42.4-8
hi  libpangoft2-1.0-01.42.4-8
ii  libpangox-1.0-0  0.0.2-5+b2
hi  libpangoxft-1.0-01.42.4-8

libpango1.0-0 recommends no packages.

libpango1.0-0 suggests no packages.

-- no debconf information

Bug#937769: [Python-modules-team] Bug#938756: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).

[Scott Kitterman]

On Thursday, May 7, 2020 2:00:58 PM EDT peter green wrote:
> I got a failure too when I cloned that branch and tried to build it, but
> once I added in the changes from the previous NMU it built fine. I would
> push that addition back to the branch but i'm not currently a member of the
> python modules team, I requested to join but no response yet.

That part is fixed (waiting to  join the team).

Scott K

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

Bug#959977: obs-api: does not include application.css

[folkert]

Package: obs-api
Version: 2.9.4-3
Severity: important

Dear Maintainer,

I installed obs-api.
It works mostly only the web-interface is broken: this is due to
/stylesheets/webui/application.css and other web-files missing.


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages obs-api depends on:
ii  adduser 3.116
ii  apache2 2.4.38-3
ii  dbconfig-common 2.0.8
ii  debconf 1.5.63
ii  gsfonts 1:8.11+urwcyr1.0.7~pre44-4.3
ii  libapache2-mod-passenger5.0.30-1.1+b2
ii  libapache2-mod-xforward 0.6-1+b2
ii  libgd-perl [libgd-gd2-perl] 2.71-2+b1
ii  libjs-bootstrap 3.3.7+dfsg-2
pn  libjs-html5shiv 
ii  lsb-base9.20170808
ii  mariadb-client-10.3 [virtual-mysql-client]  1:10.3.17-1
ii  memcached   1.6.5-2
ii  ruby1:2.7+1
ii  ruby-activemodel-serializers-xml1.0.2-2
ii  ruby-acts-as-list   0.9.15-1
ii  ruby-acts-as-tree   2.8.0-1
ii  ruby-addressable2.7.0-1
ii  ruby-bcrypt 3.1.13-2+b1
ii  ruby-bunny  2.14.4-3
ii  ruby-capybara   3.12.0-1
ii  ruby-chunky-png 1.3.8-1
ii  ruby-cliver 0.3.2-3
ii  ruby-clockwork  2.0.4-1
ii  ruby-cocoon 1.2.6-2
ii  ruby-codemirror-rails   5.16.0-1
ii  ruby-coderay1.1.2-3
ii  ruby-coffee-rails   4.2.2-1
ii  ruby-colorize   0.8.1-1
ii  ruby-crack  0.4.3-4
ii  ruby-crass  1.0.2-2
ii  ruby-cssmin 1.0.3-5
ii  ruby-daemons1.1.9-2
ii  ruby-dalli  2.7.9-2
ii  ruby-data-migrate   5.3.1-1
ii  ruby-delayed-job4.1.5-1
ii  ruby-delayed-job-active-record  4.1.3-1
ii  ruby-docile 1.1.5-2
ii  ruby-erubis 2.7.0-3
ii  ruby-escape-utils   1.2.1-1+b3
ii  ruby-execjs 2.6.0-1
ii  ruby-feature1.4.0-2
ii  ruby-flot-rails 0.0.7-1
ii  ruby-font-awesome-rails 4.7.0.5-1
ii  ruby-gssapi 1.2.0-1
ii  ruby-haml   5.1.2-1
ii  ruby-hike   1.2.1-3
ii  ruby-i18n   1.8.2-2
ii  ruby-innertube  1.1.0-5
ii  ruby-joiner 0.4.2-2
ii  ruby-jquery-datatables-rails3.4.0+dfsg-1
ii  ruby-jquery-rails   4.3.3-1
ii  ruby-jquery-ui-rails6.0.1+dfsg-3
pn  ruby-json   
ii  ruby-kaminari   1.0.1-5
ii  ruby-kgio   2.11.2-1+b3
ii  ruby-ldap   0.9.20-1+b3
ii  ruby-metaclass  0.0.4-1
ii  ruby-method-source  1.0.0-2
ii  ruby-middleware 0.1.0-1
ii  ruby-mime-types 3.3.1-1
ii  ruby-momentjs-rails 2.20.1-2
ii  ruby-mousetrap-rails1.4.6-6
ii  ruby-mysql2 0.5.2-1+b3
ii  ruby-nokogiri   1.10.9+dfsg-1
ii  ruby-nokogumbo  1.4.2+ds-1+b7
ii  ruby-peek   1.1.0-1
ii  ruby-pkg-config 1.4.1-1
ii  ruby-pundit 2.0.0-1
ii  ruby-rails  2:5.2.4.1+dfsg-2
ii  ruby-rails-tokeninput   1.7.0-1
ii  ruby-raindrops  0.19.0-1+b4
ii  ruby-redcarpet  3.5.0-1+b2
ii  ruby-responders 3.0.0-3
ii  ruby-riddle

Bug#959976: autodep8: install linux-headers-* for dkms-autopkgtest

[Paul Gevers]

Hi Andreas,

On 07-05-2020 20:07, Andreas Beckmann wrote:
> *-dkms autopkgtests are currently quite useless without some linux-headers-*
> installed to build against (#945594). I think this is solved best in
> autodep8 which "defines" the environment for the test.
> Even with kernel headers installed, the test may fail early (while
> installing test dependencies) if dkms autoinstall fails and not give a
> helpful failure log. I therefore sent two patches for dkms (#959910) that
> allow disabling autoinstall mode by creating a flag file and then do the
> autoinstall step-by-step with verbose error reporting on failure. This
> will be done for all installed kernel headers, independent of the
> running kernel, s.t. this should work even in a plain chroot.
> 
> This will only work if autoinstall is disabled early enough, therefore
> my patch drops the "Depends: @" from the generated test, the
> dkms-autopkgtest script will install the *-dkms packages anyway.

We have merge requests pending that also do that:
https://salsa.debian.org/ci-team/autodep8/-/merge_requests/21
and some of the discussion in this bug also happened there.

> I'm a but unsure about the restrictions of the test:
> * isolation-machine should not be needed any more, since the test script
>   is now independent of the running kernel

That's https://salsa.debian.org/ci-team/autodep8/-/merge_requests/20

> * breaks-testbed could be needed, since the test script (which
>   needs-root) installs/removes packages and 'changes configuration
>   files'

Yes, please.

> * skippable is currently not used, but something using it could be
>   implemented in dkms's dkms-autopkgtest script at some point
> * superficial because this only tests whether the module can be built

> I tested these changes in dkms and autodep8 on bbswitch-dkms in Debian,
> but I have no idea which impact they might have on Ubuntu.

So, it's best to have them join in.

> At least the list of kernel header packages would need to be different.
> Ideally the list of kernel header packages should not be hardcoded but
> generated at runtime, but that would have to happen for the correct
> release, ...

I don't get your last remark. Please also note that the current version
of autodep8 is used to cover all suites, so it indeed needs to be generic.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#959884: hardening-runtime: max_user_namespaces breaks uuid-runtime

[Aaron M. Ucko]

Yves-Alexis Perez  writes:

> I think one of us missed something. I'm unsure what you mean about “non-round
> machine-dependent number”.

Looking at a handful of hosts that TTBOMK leave this setting as is, I
see values of 30732, 31730, 31796, and in one case 96081.  I haven't
traced how the kernel arrives at them, and concede that the exact values
probably don't matter much and that it may be just as well if they're
not so convenient to keep.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#959976: autodep8: install linux-headers-* for dkms-autopkgtest

[Andreas Beckmann]

Package: autodep8
Version: 0.22
Severity: normal
Tags: patch
Control: block -1 with 959910
Control: tag 959910 patch

Hi,

*-dkms autopkgtests are currently quite useless without some linux-headers-*
installed to build against (#945594). I think this is solved best in
autodep8 which "defines" the environment for the test.
Even with kernel headers installed, the test may fail early (while
installing test dependencies) if dkms autoinstall fails and not give a
helpful failure log. I therefore sent two patches for dkms (#959910) that
allow disabling autoinstall mode by creating a flag file and then do the
autoinstall step-by-step with verbose error reporting on failure. This
will be done for all installed kernel headers, independent of the
running kernel, s.t. this should work even in a plain chroot.

This will only work if autoinstall is disabled early enough, therefore
my patch drops the "Depends: @" from the generated test, the
dkms-autopkgtest script will install the *-dkms packages anyway.

I'm a but unsure about the restrictions of the test:
* isolation-machine should not be needed any more, since the test script
  is now independent of the running kernel
* breaks-testbed could be needed, since the test script (which
  needs-root) installs/removes packages and 'changes configuration
  files'
* skippable is currently not used, but something using it could be
  implemented in dkms's dkms-autopkgtest script at some point
* superficial because this only tests whether the module can be built

I tested these changes in dkms and autodep8 on bbswitch-dkms in Debian,
but I have no idea which impact they might have on Ubuntu.
At least the list of kernel header packages would need to be different.
Ideally the list of kernel header packages should not be hardcoded but
generated at runtime, but that would have to happen for the correct
release, ...

Andreas
>From e3489a39da32b60479b43440f672c87740112f50 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Thu, 7 May 2020 20:03:20 +0200
Subject: [PATCH] install linux-headers-* for dkms tests

---
 support/dkms/generate | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/support/dkms/generate b/support/dkms/generate
index 0883cd8..0fbd440 100755
--- a/support/dkms/generate
+++ b/support/dkms/generate
@@ -2,7 +2,29 @@
 
 cat <

Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).

[peter green]

On 21/04/2020 22:20, Thomas Goirand wrote:

Python 2 has never been removed from this
package. Though instead, we shall remove this source package entirely
from Debian.

# Broken Depends:
nipype: python-nipype
pytest: pypy-pytest
python-logfury: python3-logfury
python-oslo.utils: python3-oslo.utils

# Broken Build-Depends:
beaker: python3-funcsigs
kombu: python3-funcsigs
nipype: python-funcsigs
pagure: python3-funcsigs
pytest: pypy-funcsigs
python-oslo.log: python3-funcsigs
python-oslo.utils: python3-funcsigs (>= 0.4)
ripe-atlas-cousteau: python3-funcsigs

You can remove all of the python-oslo* from the list. The versions in
Experimental, which are the next version of OpenStack, are fixed. In 2
weeks of time, I'll upload all what I staged in Experimental to Sid
(maybe 150 packages?) and that's going to fix it all.

For the others, probably I should start filling bugs...

While I understand you would like to get rid of the python-funcsigs source 
package completely, would you be ok with a NMU (debdiff attached) so we can get 
the packages in testing back into a consistent state without waiting for all 
the rdeps of funcsigs?

So, if I'm following correctly, what you seem to propose, is to remove
Python 2 from unittest2. If that's the case, then I agree with such a
plan. I just didn't dare to do it yet.

Though in fact, I already worked on that, but stopped, also because
unittest2 FTBFS when I try building it on my laptop. So I've pushed it
in its normal Git repo [1] under a py2-removal branch. If anyone has
some time available to look at it, that'd be nice (I currently don't...).

I got a failure too when I cloned that branch and tried to build it, but once I 
added in the changes from the previous NMU it built fine. I would push that 
addition back to the branch but i'm not currently a member of the python 
modules team, I requested to join but no response yet.

I also prepped a NMU for numba and posted a debdiff to the bug report
diff -Nru python-funcsigs-1.0.2/debian/changelog 
python-funcsigs-1.0.2/debian/changelog
--- python-funcsigs-1.0.2/debian/changelog  2018-02-27 12:49:28.0 
+
+++ python-funcsigs-1.0.2/debian/changelog  2020-04-30 21:43:30.0 
+
@@ -1,3 +1,12 @@
+python-funcsigs (1.0.2-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python 2 support.
+  * Switch to pybuild, the old build system doesn't like building python3
+only packages.
+
+ -- Peter Michael Green   Thu, 30 Apr 2020 21:43:30 +
+
 python-funcsigs (1.0.2-4) unstable; urgency=medium
 
   * Team upload.
diff -Nru python-funcsigs-1.0.2/debian/control 
python-funcsigs-1.0.2/debian/control
--- python-funcsigs-1.0.2/debian/control2018-02-27 12:49:28.0 
+
+++ python-funcsigs-1.0.2/debian/control2020-04-30 21:43:20.0 
+
@@ -9,13 +9,10 @@
  dh-python,
  pypy,
  pypy-setuptools (>= 17.1),
- python-all,
- python-setuptools (>= 17.1),
  python3-all,
  python3-setuptools (>= 17.1),
  python3-sphinx,
 Build-Depends-Indep:
- python-unittest2 (>= 1.1.0),
  python3-unittest2 (>= 1.1.0),
 Standards-Version: 4.1.3
 Vcs-Browser: https://salsa.debian.org/openstack-team/python/python-funcsigs
@@ -37,20 +34,6 @@
  .
  This package contains the PyPy module.
 
-Package: python-funcsigs
-Architecture: all
-Depends:
- ${misc:Depends},
- ${python:Depends},
-Suggests:
- python-funcsigs-doc,
-Description: function signatures from PEP362 - Python 2.7
- funcsigs is a backport of the PEP 362 function signature features from Python
- 3.3's inspect module. The backport is compatible with Python 2.6, 2.7 as well
- as 3.2 and up.
- .
- This package contains the Python 2.7 module.
-
 Package: python-funcsigs-doc
 Section: doc
 Architecture: all
diff -Nru python-funcsigs-1.0.2/debian/rules python-funcsigs-1.0.2/debian/rules
--- python-funcsigs-1.0.2/debian/rules  2018-02-27 12:43:35.0 +
+++ python-funcsigs-1.0.2/debian/rules  2020-04-30 21:43:30.0 +
@@ -1,19 +1,14 @@
 #!/usr/bin/make -f
 
-PYTHONS:=$(shell pyversions -vr)
 PYTHON3S:=$(shell py3versions -vr)
 
 UPSTREAM_GIT := https://github.com/testing-cabal/funcsigs.git
 -include /usr/share/openstack-pkg-tools/pkgos.make
 
 %:
-   dh $@ --buildsystem=python_distutils --with 
python2,python3,pypy,sphinxdoc
+   dh $@ --buildsystem=pybuild --with python3,pypy,sphinxdoc
 
 override_dh_auto_install:
-   set -e ; for pyvers in $(PYTHONS); do \
-   python$$pyvers setup.py install --install-layout=deb \
-   --root $(CURDIR)/debian/python-funcsigs; \
-   done
set -e ; for pyvers in $(PYTHON3S); do \
python$$pyvers setup.py install --install-layout=deb \
--root $(CURDIR)/debian/python3-funcsigs; \
@@ -24,7 +19,7 @@
 
 override_dh_auto_test:
 ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
-   set -e ; for pyvers in $(PYTHONS) $(PYTHON3S); do \
+   set -e ; for pyvers in $(PYTHON3S); do \

Bug#959975: mesa: FTBFS on hurd-i386

[Svante Signell]

Source: mesa
Version: 20.0.6-1
Severity: important
Tags: ftbfs, patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

Currently mesa FTBFS on GNU/Hurd due to a missing struct definition. Version 
20-0.4-2 built successfully earlier. The attached patch
src_glx_dri_common.h.diff fixes that problem. Strangely this problem does not
occur for other builds. Probably this is due to that all other architectures use
llvm for the build while the build for Hurd is with gcc.

This patch is also needed to build 20.1.0~rc1-1 from experimental together with
a new PATH_MAX patch. That patch will be submitted in a separate bug report.

Thanks!
--- a/src/glx/dri_common.h	2020-04-30 00:48:24.0 +0200
+++ b/src/glx/dri_common.h	2020-05-07 17:15:37.0 +0200
@@ -55,7 +55,7 @@
 
 extern void driDestroyConfigs(const __DRIconfig **configs);
 
-extern __GLXDRIdrawable *
+extern struct __GLXDRIdrawable *
 driFetchDrawable(struct glx_context *gc, GLXDrawable glxDrawable);
 
 extern void

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

[Aurelien Jarno]

On 2020-05-07 13:04, Noah Meyerhans wrote:
> On Wed, May 06, 2020 at 04:15:09PM +0200, Aurelien Jarno wrote:
> > > >One solution for this would be to ship the optimized library in the same
> > > >package as the default library. Now this is not acceptable for embedded
> > > >systems as they might not need that library and can't remove it. This is
> > > >even more problematic if we need to add more optimized libraries. I guess
> > > >this might be the case for arm64 as there are many new extensions in the
> > > >pipe.
> > > 
> > > ACK. It's a problem to ship the different things in separate
> > > packages. If it's really a problem for smaller systems to have all the
> > > variants because of size, is there maybe another way to do things? How
> > > about keeping the existing libc and have an extra package
> > > ("libc-optimised") with all the optimised versions *and* the basic
> > > version, and have it provide/replace/conflict libc6?
> > > 
> > > (/me prepares to be ambarrassed as you point out the obvious flaw I'm
> > > missing...)
> > 
> > I guess that the provide/replace/conflict libc6 will just prevent
> > installation of foreign libc6 packages, basically making this optimized
> > package useless in the multiarch context.
> > 
> > OTOH, what is the drawback of having GCC defaulting to -moutline-atomics?
> > It will improve performance on many more packages than only glibc, and
> > is way easier to implement overall. It also means users has nothing to
> > do to get additional performances.
> 
> For the current issue, defaulting to -moutline-atomics might be a sane
> approach.  As you said earlier, though, it seems that there are many new
> extensions in the pipe for ARM.  There may not be an equivalent solution
> for all of them, and even if there is, at some point the runtime
> overhead of all this conditional code is going to add up to something
> meaningful.

If we are talking about future extensions, another option for some of
them is to use ifunc. It's how the various SSE and AVX extensions are
supported on x86, and neon is supported on armv7.

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

Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does

[Julien Cristau]

On Thu, May 07, 2020 at 09:48:34PM +1000, Dmitry Smirnov wrote:
> On Thursday, 7 May 2020 7:04:17 PM AEST Julien Cristau wrote:
> > This use of Provides is not acceptable.  The systemctl package does not
> > in any way provide the same functionality / interfaces as the systemd
> > package, and as such it does not get to pretend that it does and cause
> > problems to other packages.
> 
> I have to challenge that. "systemctl" provides enough functionality to 
> replace "systemd" inside application containers. Therefore there are 
> situations where "Provides: systemd" is justified.
> 
That's not what "Provides" means though.  What you're saying is
"systemctl provides a subset of the systemd package's functionality".
That's not good enough.  Provides is much stronger than "there are cases
where this might be enough", and there's more to systemd than systemctl.

Also, per policy §3.6, virtual packages outside the defined agreed-upon
names should only be used "amongst a cooperating group of packages".  It
seems clear to me this is neither of those cases.

You're welcome to try and convince either the systemd maintainers to
split some of the functionality to separate binary packages, or the
php-fpm maintainer to forgo using functionality that is only available
in systemd, but abusing package relationships the way you're doing now
is just not on.

Cheers,
Julien

Bug#805833: listpw

[Todd C. Miller]

This was fixed in sudo 1.8.20.

 - todd

Bug#959973: pgcli: does not work due to prompt_toolkit incompatibility

[George B.]

Package: pgcli
Version: 2.2.0-4
Severity: grave
Justification: renders package unusable

```
borisov@glossy:~ $ pgcli 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 584, in 
_build_master
ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 901, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 792, in 
resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (prompt-toolkit 3.0.5 
(/usr/lib/python3/dist-packages), 
Requirement.parse('prompt_toolkit<3.0.0,>=2.0.6'), {'pgcli'})

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/pgcli", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3259, 
in 
def _initialize_master_working_set():
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3242, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3271, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 586, in 
_build_master
return cls._build_from_requirements(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 599, in 
_build_from_requirements
dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 787, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'prompt_toolkit<3.0.0,>=2.0.6' 
distribution was not found and is required by pgcli
```

```
borisov@glossy:~ $ sudo aptitude install python3-prompt-toolkit
[sudo] password for borisov:
python3-prompt-toolkit is already installed at the requested version (3.0.5-2)
python3-prompt-toolkit is already installed at the requested version (3.0.5-2)
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
```

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 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 pgcli depends on:
ii  python3 3.8.2-3
ii  python3-click   7.0-3
ii  python3-configobj   5.0.6-4
ii  python3-humanize2.3.0-1
ii  python3-pgspecial   1.9.0-2
ii  python3-pkg-resources   46.1.3-1
ii  python3-prompt-toolkit  3.0.5-2
ii  python3-psycopg22.8.5-1
ii  python3-pygments2.3.1+dfsg-3
ii  python3-setproctitle1.1.10-1+b4
ii  python3-sqlparse0.3.1-1
ii  python3-tabulate0.8.2-1.1
ii  python3-terminaltables  3.1.0-3

pgcli recommends no packages.

pgcli suggests no packages.

-- no debconf information

Bug#935081: alsa-utils: Intel sound not working in Debian 10

[Elimar Riesebieter]

* justjohndoe  [2020-05-07 19:31 +0300]:

> Package: alsa-utils
> Version: 1.2.2-1
> Followup-For: Bug #935081
> 

What tells 'dpkg -l | grep timidity' ?

Elimar
-- 
  We all know Linux is great... it does infinite loops in 5 seconds.
-Linus Torvalds

Bug#783582: sudo german translation typo

[Todd C. Miller]

This was fixed in the following commit on 2014-09-17:
https://www.sudo.ws/repos/sudo/rev/588c41d2eab5

Bug#959972: nextcloud-desktop: Please provide a backport for buster

[Daniel Scharon]

Package: nextcloud-desktop
Version: 2.5.1-3+deb10u1
Severity: wishlist

It would be nice to let users of buster enjoy the improvements since 2.6

Thank you and kind regards,
Dan



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

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

Versions of packages nextcloud-desktop depends on:
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libnextcloudsync0 2.5.1-3+deb10u1
ii  libqt5concurrent5 5.11.3+dfsg1-1+deb10u3
ii  libqt5core5a  5.11.3+dfsg1-1+deb10u3
ii  libqt5dbus5   5.11.3+dfsg1-1+deb10u3
ii  libqt5gui55.11.3+dfsg1-1+deb10u3
ii  libqt5keychain1   0.9.1-2
ii  libqt5network55.11.3+dfsg1-1+deb10u3
ii  libqt5positioning55.11.3+dfsg-2
ii  libqt5printsupport5   5.11.3+dfsg1-1+deb10u3
ii  libqt5qml55.11.3-4
ii  libqt5quick5  5.11.3-4
ii  libqt5sql5-sqlite 5.11.3+dfsg1-1+deb10u3
ii  libqt5webchannel5 5.11.3-2
ii  libqt5webenginecore5  5.11.3+dfsg-2+deb10u1
ii  libqt5webenginewidgets5   5.11.3+dfsg-2+deb10u1
ii  libqt5webkit5 5.212.0~alpha2-21
ii  libqt5widgets55.11.3+dfsg1-1+deb10u3
ii  libqt5xml55.11.3+dfsg1-1+deb10u3
ii  libsqlite3-0  3.27.2-3
ii  libssl1.1 1.1.1d-0+deb10u3
ii  libstdc++68.3.0-6
ii  nextcloud-desktop-common  2.5.1-3+deb10u1
ii  nextcloud-desktop-l10n2.5.1-3+deb10u1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages nextcloud-desktop recommends:
ii  nextcloud-desktop-doc  2.5.1-3+deb10u1

nextcloud-desktop suggests no packages.

-- no debconf information

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

[Noah Meyerhans]

On Wed, May 06, 2020 at 04:15:09PM +0200, Aurelien Jarno wrote:
> > >One solution for this would be to ship the optimized library in the same
> > >package as the default library. Now this is not acceptable for embedded
> > >systems as they might not need that library and can't remove it. This is
> > >even more problematic if we need to add more optimized libraries. I guess
> > >this might be the case for arm64 as there are many new extensions in the
> > >pipe.
> > 
> > ACK. It's a problem to ship the different things in separate
> > packages. If it's really a problem for smaller systems to have all the
> > variants because of size, is there maybe another way to do things? How
> > about keeping the existing libc and have an extra package
> > ("libc-optimised") with all the optimised versions *and* the basic
> > version, and have it provide/replace/conflict libc6?
> > 
> > (/me prepares to be ambarrassed as you point out the obvious flaw I'm
> > missing...)
> 
> I guess that the provide/replace/conflict libc6 will just prevent
> installation of foreign libc6 packages, basically making this optimized
> package useless in the multiarch context.
> 
> OTOH, what is the drawback of having GCC defaulting to -moutline-atomics?
> It will improve performance on many more packages than only glibc, and
> is way easier to implement overall. It also means users has nothing to
> do to get additional performances.

For the current issue, defaulting to -moutline-atomics might be a sane
approach.  As you said earlier, though, it seems that there are many new
extensions in the pipe for ARM.  There may not be an equivalent solution
for all of them, and even if there is, at some point the runtime
overhead of all this conditional code is going to add up to something
meaningful.

noah

Bug#959057: RFS: dh-cmake/0.4 [ITP] -- Debhelper programs for CMake projects

[Kyle Edwards]

On Thu, 2020-05-07 at 20:47 +0800, Paul Wise wrote:
> On Thu, 2020-05-07 at 08:44 -0400, Kyle Edwards wrote:
> 
> > 
> > * Putting different CMake install components into different binary
> > packages (for example, putting the "Libraries" component into
> > libexample and the "Development" component into libexample-dev),
> > which
> > is easier than listing individual files
> Seems like this would be useful in debhelper itself.
> 
> > 
> > * Running the CMake project's test suite inside the build process
> > and
> > submitting the results to CDash (this is more useful for continuous
> > integration than production builds)
> Possibly this too.
> 
> > 
> > * Extracting CPack component metadata from the project and
> > incorporating that into the binary packages (for example, knowing
> > that
> > the "Development" component depends on the "Libraries" component
> > allows
> > libexample-dev to automatically depend on libexample)
> This too.

Arguably, yes. However, there is precedent for splitting off highly-
specialized Debhelper functionality into separate packages - see dh-
python and javahelper for example.

On top of that, since I am one of the upstream CMake developers, and
have put lots of CMake expertise into this project (we even made
changes to CMake itself to accommodate the CPack functionality), I
would prefer to maintain it myself rather than integrate it directly
into Debhelper.

Just my $.02 :)

Kyle

Bug#959937: tomcat9: update to tomcat9:amd64 9.0.31-1~deb10u1 breaks application

[Markus Koschany]

Control: severity -1 normal

Am 07.05.20 um 17:58 schrieb Michael Meier:
[...]
> The application doesn't use ajp.
> 
> The sense of using unattended-upgrades and debian stable (no breaking
> changes on updates) is not to read each security announcement in before.
> 
> I'm not working in an area, where anybody would (be able to) pay for that.

It is not feasible to detect any possible incompatibility beforehand
because it heavily depends on the apps in use. Debian stable updates
work 99% of the time without major issues but there will never be a 100%
success rate because some problems are unrelated or simply not under
Debian control. Setting up a test server before deploying updates to a
production environment is the way to go here.

>> If that does not solve your problem, then we need more information about
>> your setup and configuration to debug the problem but note that we ship
>> the latest upstream version basically unmodified, so this would be most
>> likely an upstream bug.
> 
> I could trace it back to the zk library used:
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=64097
> 
> https://tracker.zkoss.org/browse/ZK-4510
> 
> That seems to be a really really weird bug. If I understand it
> correctly, it's the fault of zk, but I'm not 100% sure.
> 
> Anyway, as it seems if I manage to update the project to the new zk
> major version, it's supposed to work again.

Ok, as I previously thought, it is an upstream bug but not in Tomcat
itself but in el-api. Updating the zk library for your app might resolve
the issue. I wonder if we need to upgrade src:el-api in Debian too. I
think it is best when Emmanuel Bourg chimes in here.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#959970: game-data-packager: ScummVM game myst-win does not exist

[Frodo Looijaard]

Package: game-data-packager
Version: 63
Severity: normal

Dear Maintainer,

when packaging Myst with game-data-packager, the desktop menu calls ScummVM
as follows:

  Exec=scummvm -p /usr/share/games/myst-masterpiece myst-win

But this does not work with scummvm: the myst-win engine does not exist.

It seems that myst must be called with the mohawk engine:

  Exec=scummvm -p /usr/share/games/myst-masterpiece mohawk

Kind regards,
  Frodo Looijaard 

-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (700, 'stable'), (500, 'stable-updates'), (400, 'testing'), (350, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages game-data-packager depends on:
ii  dpkg1.19.7
ii  fakeroot1.23-1
ii  python3 3.7.3-1
ii  python3-debian  0.1.35
ii  python3-yaml3.13-2

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

Versions of packages game-data-packager suggests:
pn  arj   
ii  binutils  2.31.1-16
ii  cabextract1.9-1
ii  cdparanoia3.10.2+debian-13
pn  dynamite  
ii  gcc   4:8.3.0-1
pn  gdebi | gdebi-kde 
ii  gir1.2-gdkpixbuf-2.0  2.38.1+dfsg-1
ii  innoextract   1.7-2+b1
pn  lgc-pg
pn  lgogdownloader
ii  lhasa [lzh-archiver]  0.3.1-3
ii  make  4.2.1-1.2
ii  p7zip-full16.02+dfsg-6
ii  python3-gi3.30.4-1
pn  steam 
pn  steamcmd  
pn  unace-nonfree 
ii  unar  1.10.1-2+b4
ii  unrar 1:5.6.6-1
pn  unshield  
ii  unzip 6.0-23+deb10u1
ii  vorbis-tools  1.4.0-11
pn  xdelta
pn  xdelta3   

-- no debconf information

Bug#959957: kate: Kate ctags addon does not start ctag process to update database

[Dmitry Ivanov]

Package: kate
Version: 4:20.04.0-1
Severity: normal
Tags: upstream

Dear Maintainer,

After updating to the latest Kate, I have noticed that cgit no longer
updates its tag database when I press "Update Index" button. Instead, it
produces a message box:

  Failed to run "ctags -R  -f /home/di/ 
/home/di/ ". exitStatus = 0

After Kate source code examination I have found this upstream commit:

https://github.com/KDE/kate/commit/30bde6d47a8727347f6deaa4b318669d078f85d2

"Port some deprecated method in qt5.15"

Among other things, it has changed the way Kate is starting cgit process:

 QString command = QStringLiteral("%1 -f %2 
%3").arg(m_ctagsUi.cmdEdit->text(), m_ctagsUi.tagsFile->text(), targets);

-m_proc.start(command);
+m_proc.start(command, QStringList());

According to Qt documentation, in this version of QProcess::start(...),
"No further splitting of the arguments is performed".

https://doc.qt.io/qt-5.12/qprocess.html#start

At the same time, ctags command is still prepared together with its
arguments as one string! So ctags addon is essentially broken by this
commit, and it's not fixed yet in upstream.

My proposal is to create a patch for debian which will restore an old
method call - it should work fine as long as Debian is using Qt 5.12/5.14
and upstream Kate is not fixed.


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

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

Versions of packages kate depends on:
ii  kate5-data   4:20.04.0-1
ii  kio  5.62.1-2+b1
ii  ktexteditor-katepart 5.62.0-1+b1
ii  libc62.30-4
ii  libkf5bookmarks5 5.62.0-1+b1
ii  libkf5completion55.62.0-1+b1
ii  libkf5configcore55.62.0-1+b1
ii  libkf5configgui5 5.62.0-1+b1
ii  libkf5configwidgets5 5.62.0-1+b1
ii  libkf5coreaddons55.62.0-1
ii  libkf5crash5 5.62.0-1+b1
ii  libkf5dbusaddons55.62.0-1
ii  libkf5guiaddons5 5.62.0-2
ii  libkf5i18n5  5.62.0-1
ii  libkf5jobwidgets55.62.0-1+b1
ii  libkf5kiocore5   5.62.1-2+b1
ii  libkf5kiofilewidgets55.62.1-2+b1
ii  libkf5kiowidgets55.62.1-2+b1
ii  libkf5newstuff5  5.62.0-1+b1
ii  libkf5parts5 5.62.0-1+b1
ii  libkf5plasma55.62.0-2
ii  libkf5service-bin5.62.0-1
ii  libkf5service5   5.62.0-1
ii  libkf5syntaxhighlighting55.62.0-3
ii  libkf5texteditor55.62.0-1+b1
ii  libkf5textwidgets5   5.62.0-1+b1
ii  libkf5threadweaver5  5.62.0-1
ii  libkf5wallet-bin 5.62.0-1+b1
ii  libkf5wallet55.62.0-1+b1
ii  libkf5widgetsaddons5 5.62.0-1+b1
ii  libkf5windowsystem5  5.62.0-3
ii  libkf5xmlgui55.62.0-1+b1
ii  libqt5core5a 5.12.5+dfsg-10
ii  libqt5dbus5  5.12.5+dfsg-10
ii  libqt5gui5   5.12.5+dfsg-10
ii  libqt5sql5   5.12.5+dfsg-10
ii  libqt5widgets5   5.12.5+dfsg-10
ii  libqt5xml5   5.12.5+dfsg-10
ii  libstdc++6   10-20200418-1
ii  plasma-framework 5.62.0-2
ii  qml-module-org-kde-kquickcontrolsaddons  5.62.0-1+b2
ii  qml-module-qtquick-layouts   5.12.5-5
ii  qml-module-qtquick2  5.12.5-5

Versions of packages kate recommends:
ii  sonnet-plugins  5.62.0-1+b1

Versions of packages kate suggests:
pn  darcs
ii  exuberant-ctags  1:5.9~svn20110310-13
ii  git  1:2.26.2-1
ii  khelpcenter  4:18.04.0-1+b1
ii  konsole-kpart4:19.08.1-2+b1
pn  mercurial
ii  subversion   1.13.0-4

-- no debconf information

Bug#959969: firefox: crashes frequently on sites like reuters.com w/o pulseaudio

[Jiri Palecek]

Package: firefox
Version: 76.0-2
Severity: normal
Tags: patch

Dear Maintainer,

as the title says, firefox 76 (and 75) crashes frequently when pages are
about to play audio, when pulseaudio is not installed. The exact cause
is not really known to me (it's not the actual audio, but dbus
connection to rtkit probably, but installing rtkit doesn't fix
it...). Anyway, I have reported this upstream and there is a fix
available, which is included in firefox 77:
https://bugzilla.mozilla.org/show_bug.cgi?id=1633266

Please consider including that fix for firefox 76 too, there was a
workaround for 75 which sadly doesn't work for 76.

Regards
Jiri Palecek

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

Kernel: Linux 5.5.0-rc5-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE= 
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firefox depends on:
ii  debianutils 4.9.1
ii  fontconfig  2.13.1-4
ii  libatk1.0-0 2.36.0-2
ii  libc6   2.30-4
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libdbus-1-3 1.12.16-2
ii  libdbus-glib-1-20.110-4
ii  libevent-2.1-7  2.1.11-stable-1
ii  libffi7 3.3-3
ii  libfontconfig1  2.13.1-4
ii  libfreetype62.10.1-2
ii  libgcc-s1   10-20200418-1
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-1
ii  libglib2.0-02.64.2-1
ii  libgtk-3-0  3.24.18-1
ii  libnspr42:4.25-1
ii  libnss3 2:3.52-1
ii  libpango-1.0-0  1.44.7-4
ii  libstdc++6  10-20200418-1
ii  libvpx6 1.8.2-dmo1
ii  libx11-62:1.6.9-2+b1
ii  libx11-xcb1 2:1.6.9-2+b1
ii  libxcb-shm0 1.14-2
ii  libxcb1 1.14-2
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.5-1
ii  libxext62:1.3.3-1+b2
ii  libxfixes3  1:5.0.3-1
ii  libxrender1 1:0.9.10-1
ii  libxt6  1:1.1.5-1+b3
ii  procps  2:3.3.16-4
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages firefox recommends:
ii  libavcodec58  10:4.2.2-dmo8

Versions of packages firefox suggests:
ii  fonts-lmodern  2.004.5-5
ii  fonts-stix [otf-stix]  1.1.1-3
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-5
ii  libgtk2.0-02.24.32-4
pn  pulseaudio 

-- no debconf information

Bug#959057: RFS: dh-cmake/0.4 [ITP] -- Debhelper programs for CMake projects

[Kyle Edwards]

On Wed, 2020-05-06 at 23:49 +, Paul Wise wrote:
> How is this different to the existing cmake support in debhelper?
> 
> $ dpkg -L debhelper libdebhelper-perl  | grep -i cmake
> /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm

The CMake buildsystem support in Debhelper is merely for *building* a
CMake project. This project augments that with additional
functionality, such as:

* Putting different CMake install components into different binary
packages (for example, putting the "Libraries" component into
libexample and the "Development" component into libexample-dev), which
is easier than listing individual files
* Running the CMake project's test suite inside the build process and
submitting the results to CDash (this is more useful for continuous
integration than production builds)
* Extracting CPack component metadata from the project and
incorporating that into the binary packages (for example, knowing that
the "Development" component depends on the "Libraries" component allows
libexample-dev to automatically depend on libexample)

See the project's readme for more details.

Bug#926154: Falkon's version 3.1.0 seems to be the last on, isn't it?

[Georges Khaznadar]

The website https://www.falkon.org/ features version 3.1.0 (released
19 March 2019) .

The version in Debian is now 3.1.0+dfsg1-6, so I close this bug report.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#903785: fixed in version 3.1.0

[Georges Khaznadar]

So I close the bug report.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#906241: Bug fixed with falkon 3.1.0, Qt 5.12

[Georges Khaznadar]

I can no longer reproduce this bug, so I close the report.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#935081: alsa-utils: Intel sound not working in Debian 10

[justjohndoe]

Package: alsa-utils
Version: 1.2.2-1
Followup-For: Bug #935081

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

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

Versions of packages alsa-utils depends on:
ii  kmod  27+20200310-2
ii  libasound21.2.2-2.1
ii  libatopology2 1.2.2-2.1
ii  libc6 2.30-4
ii  libfftw3-single3  3.3.8-2
ii  libncursesw6  6.2-1
ii  libsamplerate00.1.9-2
ii  libtinfo6 6.2-1
ii  lsb-base  11.1.0

alsa-utils recommends no packages.

Versions of packages alsa-utils suggests:
pn  dialog  

-- no debconf information

Bug#905711: No longer found with version 3.1.0

[Georges Khaznadar]

Hello, I cannot reproduce this bug with the last package version.

Please feel free to repopen the bug if you can trigger it on your
machine.

Closing th bug report now.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#888705: abseil-cpp packaging

[GCS]

On Thu, May 7, 2020 at 5:57 PM Benjamin Barenblat  wrote:
> I’m getting very close to an Abseil upload. The CMake integration
> doesn’t work yet, but I can install the binary packages and build
> software that links Abseil.
 Good news.

> I’m going to keep working on CMake support, but I’d love to upload what
> I have to Salsa. Would somebody be willing to reset the
> https://salsa.debian.org/debian/abseil repository to a pristine state so
> I can push to it without any of the old history in that repo? I’d do it
> myself, but Google has some weird rules about creating new repositories;
> it would be much easier for me if someone else could create the repo and
> give me push access.
 All Debian Developers have push access under /debian but only admins
can delete / create repositories there. If I understand correctly, you
retained src:abseil. If not and using src:abseil-cpp then you need a
new repository named after that. Which way should I go?

Cheers,
Laszlo/GCS

Bug#959884: hardening-runtime: max_user_namespaces breaks uuid-runtime

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2020-05-07 at 12:13 -0400, Aaron M. Ucko wrote:
> Yves-Alexis Perez  writes:
> 
> > Yes but once a user namespace has been created (by root or a simple user),
> > anyone on that namespace can in turn create new users namespace.
> 
> Ah, I'd missed that. :-/
> 
> > I'm unsure what you mean here. Overriding it is a simple as adding a
> > /etc/sysctl.d/10-hardening-override.conf with user.max_user_namespace=1
> > (or 2,
> > 3 etc.). You don't have to provide anything else or copy any other setting
> > from /usr/lib/sysctl.d/10-hardening.conf
> 
> This point is, as noted, just a minor technicality.  To clarify, though,
> the original default appears to be a non-round machine-dependent number
> that might plausibly vary across reboots, and 10-hardening.conf is under
> /usr and therefore inappropriate to edit.  As such, combining the two
> would require either copying 10-hardening.conf to /etc/sysctl.d/ under
> its original name, editing the copy, and keeping it in sync with
> (historically infrequent) changes to the original, or else propagating
> the original default to /etc/sysctl.conf or some non-shadowing file
> under /etc/sysctl.d and somehow keeping that file up to date.
> 
I think one of us missed something. I'm unsure what you mean about “non-round
machine-dependent number”. You're free to use whatever version works for you,
and for that you only need to put it in a sysctl file in /etc/sysctl.d like
any other sysctl configuration. /etc overrides /usr so the local administrator
can do whatever she wants. No need to keep anything up to date or in sync.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl60NnIACgkQ3rYcyPpX
RFtDXAgAs6DlPEANe3vKoaJld1IWJqj9Ieq/Q1PG6SjEvRJg+9q8JHfmsC/NNP8r
Auz2qGQcnm2oTxj5fydv9HtBobqKJhTglYhdh2wwZ4kmZf7eqeiMd151pfZcaKZr
Ca1DY4Z/5LFe+S6mclzVnqLL/F5Di+JzUCNDcNNEr290D+8pB+7Oy6ZHlNCjtc9H
AyXnAM7qH/iHnz4ipp+ETPEDqMt108o8urK6fiDm4TOL5HYtUGvzy10YGX0CEx3g
lb8KKSJH8oC6tO+xG/xGJukdDKPXSACnfJw2byDSmLjcPq43237HmUor8YDtSXvp
/oelbMWlQX9+lMZ5+3QZxoEIrIhXfw==
=4yF+
-END PGP SIGNATURE-

Bug#959909: debian-policy: complete implementation of ctte decision to forbid vendor-specific series files

[Graham Inggs]

On Wed, 06 May 2020 13:28:53 -0700, Sean Whitton wrote:
> Quoting from #904302:
>
> > The Committee therefore resolves that:
> >
> > 1. Any use of dpkg's vendor-specific patch series feature is a bug for
> >packages in the Debian archive (including contrib and non-free).
> >
> >This should be implemented in Debian Policy by declaring that a
> >package SHOULD NOT contain a non-default series file.
> >
> > 2. After Buster is released, use of the vendor-specific patch series
> >feature is forbidden in the Debian archive.
> >
> >This should be implemented in Debian Policy by declaring that a
> >package MUST NOT contain a non-default series file.
>
> Here is a patch to finish implementing this; I am seeking seconds:

Seconded.

Bug#958414: Latest equivs version 2.3.0 breaks mk-build-deps

[Johannes Schauer]

Hi Axel,

Quoting Axel Beckert (2020-05-07 15:45:12)
> > bisection finished successfully
> >   last good timestamp: 2020-04-19 06:52:31.476563+02:00
> >   first bad timestamp: 2020-04-19 10:35:09.156250+02:00
> > only one package differs: equivs is the culprit
> Yeah, but we know that already. I still haven't understood what exactly
> causes this issue.

sorry, me writing this was not supposed to come across as "I think that you are
wrong, so here is further evidence that I'm right". Instead, all I knew was
what was written by Otto and (same as myself) Otto wasn't sure whether this was
a bug in equivs or something else. So what I wanted to say was "this problem
indeed only started happening once the new equivs version got uploaded".

> If it's similar as with mk-ci-build-deps above, this is likely a bug in
> mk-build-deps then, just triggered by equivs.

Again, I don't want to be confrontational here. I don't understand as much
about equivs as you do. But what I tested is completely independent from
mk-build-deps. What I tried was running:

equivs-build /usr/share/doc/equivs/examples/webserver.ctl

And I got the same error as Otto ("Unmet build dependencies:
build-essential:native") -- even when I tried with all the other control files
in the examples directory. So if the bug is indeed not in equivs, then there
must be a bug in the control files?

Sorry if I came across as confrontational -- that was not my intention. Please
ignore this mail in case I still didn't manage to make sense.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#959884: hardening-runtime: max_user_namespaces breaks uuid-runtime

[Aaron M. Ucko]

Yves-Alexis Perez  writes:

> Yes but once a user namespace has been created (by root or a simple user),
> anyone on that namespace can in turn create new users namespace.

Ah, I'd missed that. :-/

> I'm unsure what you mean here. Overriding it is a simple as adding a
> /etc/sysctl.d/10-hardening-override.conf with user.max_user_namespace=1 (or 2,
> 3 etc.). You don't have to provide anything else or copy any other setting
> from /usr/lib/sysctl.d/10-hardening.conf

This point is, as noted, just a minor technicality.  To clarify, though,
the original default appears to be a non-round machine-dependent number
that might plausibly vary across reboots, and 10-hardening.conf is under
/usr and therefore inappropriate to edit.  As such, combining the two
would require either copying 10-hardening.conf to /etc/sysctl.d/ under
its original name, editing the copy, and keeping it in sync with
(historically infrequent) changes to the original, or else propagating
the original default to /etc/sysctl.conf or some non-shadowing file
under /etc/sysctl.d and somehow keeping that file up to date.

That said, I appreciate the merits of keeping 10-hardening.conf under
/usr, and agree that there's no need for the limit to be so high anyway,
so it may be just as well that it's not so easy to reinstate fully.

> Actually no, it's not. kernel.unprivileged_userns_clone comes from a Debian
> specific patch which is not mainline:

Never mind, then.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#959937: tomcat9: update to tomcat9:amd64 9.0.31-1~deb10u1 breaks application

[Michael Meier]

On 07.05.20 06:31, Markus Koschany wrote:


Am 07.05.20 um 10:04 schrieb Michael Meier:

Package: tomcat9
Version: 9.0.16-4
Severity: grave
Justification: renders package unusable

I've just been called out of bed.
As it seems unattended-upgrades upgraded on a debian buster server
from:9.0.16-4 to 9.0.31-1~deb10u1
One of the installed webapps throws following error when trying to use it:

[https-openssl-nio-8443-exec-13] ERROR org.zkoss.zk.ui.metainfo.Property -
Failed to assign [value=${i18n:rt('Benutzername')}] to 
Unable to find ExpressionFactory of type: # Licensed to the Apache Software
Foundation (ASF) under one or more

Downgrading to 9.0.16-4 solves the issue.

Have you read the changelog or the Debian security announcement before
upgrading Tomcat 9 ? Does your application require the AJP protocol to
work? Then you probably need to slightly change your Tomcat
configuration. For more information please also refer to the official
documentation at

   https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html


The application doesn't use ajp.

The sense of using unattended-upgrades and debian stable (no breaking 
changes on updates) is not to read each security announcement in before.


I'm not working in an area, where anybody would (be able to) pay for that.



If that does not solve your problem, then we need more information about
your setup and configuration to debug the problem but note that we ship
the latest upstream version basically unmodified, so this would be most
likely an upstream bug.


I could trace it back to the zk library used:

https://bz.apache.org/bugzilla/show_bug.cgi?id=64097

https://tracker.zkoss.org/browse/ZK-4510

That seems to be a really really weird bug. If I understand it 
correctly, it's the fault of zk, but I'm not 100% sure.


Anyway, as it seems if I manage to update the project to the new zk 
major version, it's supposed to work again.

Bug#920555: xmobar: compile flag with_alsa to support Volume command

[Benjamin Barenblat]

Control: tag 920555 + patch

It looks like `with_alsa` was turned off due to missing dependencies,
but the dependencies are all packaged in bullseye. I’ve attached a patch
to update the package with the new dependencies and enable the flag.
diff -Naur a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,8 @@ Source: xmobar
 Standards-Version: 4.5.0
 Build-Depends: debhelper-compat (=12),
ghc,
+   libghc-alsa-core-dev [linux-any],
+   libghc-alsa-mixer-dev (>= 0.3) [linux-any],
libghc-dbus-dev [linux-any],
libghc-extensible-exceptions-dev,
libghc-hinotify-dev [linux-any],
diff -Naur a/debian/copyright b/debian/copyright
--- a/debian/copyright	2019-01-14 15:02:30.0 -0500
+++ b/debian/copyright	2020-05-03 19:57:33.954104115 -0400
@@ -11,6 +11,7 @@
 Files: debian/*
 Copyright: Copyright 2008-2019 Apollon Oikonomopoulos 
Copyright 2018 Aggelos Avgerinos 
+   Copyright 2020 Google LLC
 License: BSD-3-Clause
 
 Files: examples/xmonadpropwrite.hs
diff -Naur a/debian/README.Debian b/debian/README.Debian
--- a/debian/README.Debian	2018-11-14 02:55:08.0 -0500
+++ b/debian/README.Debian	2020-05-03 19:57:33.954104115 -0400
@@ -7,10 +7,10 @@
 
 Plugin notes
 
-- The Mail, MBox and Wireless plugins are Linux-specific and have been
+- The Alsa, Mail, MBox and Wireless plugins are Linux-specific and have been
   disabled in non-Linux architectures (kFreeBSD, Hurd).
 
 - The MPRIS and DBus plugins require haskell-dbus, which is currently broken
   for non-linux platforms and so they are enabled only for Linux.
 
-- The mpd, alsa and datezone plugins are disabled to missing dependencies.
+- The mpd and datezone plugins are disabled to missing dependencies.
diff -Naur a/debian/rules b/debian/rules
--- a/debian/rules	2019-01-14 18:39:34.0 -0500
+++ b/debian/rules	2020-05-03 19:57:33.954104115 -0400
@@ -15,7 +15,7 @@
 CONFIGURE_OPTS = --ghc-options="$(GHC_OPTIONS)"
 
 ifeq ($(DEB_HOST_ARCH_OS),linux)
-CONFIGURE_OPTS += --flags="with_xft with_inotify with_iwlib with_mpris with_dbus with_xpm with_uvmeter with_conduit"
+CONFIGURE_OPTS += --flags="with_xft with_inotify with_iwlib with_alsa with_mpris with_dbus with_xpm with_uvmeter with_conduit"
 else
 CONFIGURE_OPTS += --flags="with_xft with_xpm"
 endif

Bug#888705: abseil-cpp packaging

[Benjamin Barenblat]

I’m getting very close to an Abseil upload. The CMake integration
doesn’t work yet, but I can install the binary packages and build
software that links Abseil.

I’m going to keep working on CMake support, but I’d love to upload what
I have to Salsa. Would somebody be willing to reset the
https://salsa.debian.org/debian/abseil repository to a pristine state so
I can push to it without any of the old history in that repo? I’d do it
myself, but Google has some weird rules about creating new repositories;
it would be much easier for me if someone else could create the repo and
give me push access.

Bug#959668: os-prober: translated auto-added items in other installs are not recognized as such

[Colin Watson]

On Thu, May 07, 2020 at 04:41:30PM +0200, Cyril Brulebois wrote:
> Benno Schulenberg  (2020-05-07):
> > Right.  However... looking at the latest grub POT file
> > (https://translationproject.org/POT-files/grub-2.04-pre1.pot),
> > it no longer contains the "(on %s)" msgid.  In fact, it does
> > not contain anything from '30_os-prober.in' at all any more.  :|
> > 
> > Did something go wrong in the packaging of grub?  Or did they
> > eliminate the script?  Or were the scripts moved to a separate
> > package?
> 
> Let's ask grub2 maintainers (cc'd). :)

I think that's the thing I fixed upstream here:

  
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=ac116bd659b295d3b9e116808d3e1d940dc0fd67

-- 
Colin Watson   [cjwat...@debian.org]

Bug#959968: RFS: mplcursors/0.3-1 [ITP] -- Interactive data selection cursors for Matplotlib

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-pyt...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "mplcursors"

 * Package name: mplcursors
   Version : 0.3-1
   Upstream Author : Antony Lee 
 * URL : https://github.com/anntzer/mplcursors
 * License : MIT
 * Vcs : https://salsa.debian.org/sudip/mplcursors
   Section : python

It builds those binary packages:

  python3-mplcursors - Interactive data selection cursors for Matplotlib

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/mplcursors/mplcursors_0.3-1.dsc

Changes since the last upload:

   * Initial release (Closes: #959870)

Note: This is my first attempt at python package and so I have added
debian-python@l.d.o in X-Debbugs-CC with the hope that someone from the
python team will check this and point out my mistakes (if any).


-- 
Regards
Sudip

Bug#959967: RM: bbswitch [arm64 armel mips64el mipsel s390x] -- RoM; ANAIS; restricted to architectures with nvidia binary driver

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

since stretch bbswitch is only useful on architectures that
have the proprietary nvidia driver: amd64, armhf, i386, ppc64el


Andreas

Bug#949133: z3: request for backport to buster

[Alex ARNAUD]

Le 07/05/2020 à 15:50, Fabian Wolff a écrit :

So in principle, I could upload it now, but I'm kind of hesitant with regards to
how this would make me responsible for the package until buster's EOL [1]. Do
you have any experience with backports, is it really such a big commitment as
they make it sound in [1]? Because my personal focus is definitely on testing.
If you upload a package to buster-backports, you'll have to maintain it 
until the release of Bullseye "only", not the Debian 10 EOL.


Best regards.

Bug#937302: playonlinux: Python2 removal in sid/bullseye

[Scott Talbert]

On Thu, 23 Apr 2020, Markus Koschany wrote:


OK, so it turns out the port to Python 3 was a bit harder than
expected, but I think I've got something ready for further review /
testing.  I have done some initial testing, but I'm not that familiar
with playonlinux so I would appreciate some additional testing.  I
submitted my patch as a merge request here:

https://salsa.debian.org/games-team/playonlinux/-/merge_requests/1

Please do let me know if you encounter any bugs.  I will fix them.


Hello Markus and Bertrand,

Did you have any chance to review my patch or test it yet?

Thanks,
Scott


I haven't had the time to really review and test your patch but I will
do so eventually.


Thanks.  Let me know if you would like me to just NMU it as well.

Regards,
Scott

Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does

[Shengjing Zhu]

I can see both php-fpm and systemctl maintainers have good reasons to
do what they did.

So taking one step back, does it make sense to dpkg-divert /usr/bin/systemctl?

Bug#959966: gdc -flto doesn't accept void main() signature.

[Witold Baryluk]

Package: gdc
Version: 4:9.2.1-3.1
Severity: normal

Dear Maintainer,

According to language spec:

https://dlang.org/spec/function.html#main

"""
19.20 main() Function

For console programs, main() serves as the entry point. It gets called
after all the module initializers are run, and after any unittests are
run. After it returns, all the module destructors are run. main() must be
declared using one of the following forms:

void main() { ... }
void main(string[] args) { ... }
int main() { ... }
int main(string[] args) { ... }
"""


However:
$ cat dlang.d
void main() {
}
$ gdc -flto dlang.d
/usr/lib/gcc/x86_64-linux-gnu/9/include/d/__entrypoint.di:33:5: warning: type 
of ‘_Dmain’ does not match original declaration [-Wlto-type-mismatch]
   33 | int _Dmain(char[][] args);
  | ^
dlang.d:2:6: note: type mismatch in parameter 1
2 | void main() {
  |  ^
dlang.d:2:6: note: type ‘void’ should match type ‘struct char[][]’
dlang.d:2:6: note: ‘D main’ was previously declared here
$

It does compile fine using `int mine(string[] args)` (and returning 0
from it) and run correctly.

Also the message 'void' should match type 'struct char[][]' is confusing.
'struct'? void (return type?) should match it. Weird wording. I guess,
maybe it is parameter 1, which is not in my definition, but should be
string[]. But I am guessing here. Wording is weird and unclear what is
what.

Minor issue, but still a bit annoying and a violatation of the D language
spec.


Regards,
Witold




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

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

Versions of packages gdc depends on:
ii  gdc-9   9.3.0-11
ii  libgphobos-dev  9.2.1-3.1

gdc recommends no packages.

gdc suggests no packages.

-- no debconf information

Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions

[Marc Lehmann]

On Mon, May 04, 2020 at 12:19:43PM +0200, Chris Hofstaedtler  
wrote:
> > partitions on the same disk it is unlikely to be caused by something weird
> > in the partition tables. That, or the algorithm is completely hosed, as it
> > shouldn't depend on the partition at all, only on the disk.
> 
> Well, I tried recreating your setup on a loop blockdev, and it works
> for me:

Studying the manpage, I tried LSBLK_DEBUG, and I think it gives a good hint:

http://data.plan9.de/lsblkbug.txt

   539: lsblk:  DEV: [0x55596de0]: add 'sda3' to scols
   539: lsblk:  DEV: [0x55596de0]:  refer data[0]="/dev/sda3"
   539: lsblk:  DEV: [0x55596de0]:  refer data[1]="sda3"
   539: lsblk:  DEV: [0x55596de0]:  refer data[2]="  8:3  "
   539: lsblk:  DEV: [0x55596de0]:  refer data[3]="part"
   539: lsblk:  DEV: [0x55596de0]: /dev/sda3: properties requested
   539: lsblk:  DEV: [0x55596de0]: sda3: found udev properties
   539: lsblk:  DEV: [0x55596de0]:  from udev
   539: lsblk:  DEV: [0x55596de0]:  refer data[4]="dos"

I don't know how to exactly interpret this, but it seems this info comes from
udev. And indeed:

   udevadm info /dev/sda3
   [...]
   E: ID_PART_TABLE_UUID=81be6e1d-066c-45eb-a13d-53fc8e4730bd
   E: ID_PART_TABLE_TYPE=dos

So maybe this is a bug in udev (otoh, udev might use blkid, I have no clue
:).

[... later ...]

poking around in systemd sources, it does use blkid, although it is not clear
to me whether it uses libblkid or rolls it's own, but util-linux's blkid also
says PTTYPE="dos".

Deleting /run/blkid/blkid.tab and running blkid with doesn't show anything
obvious to me (http://data.plan9.de/blkidbug.txt), except that it wrongly
detetcs pttype as dos:

3900: libblkid: LOWPROBE: Resetting partitions values
3900: libblkid: LOWPROBE: --> starting probing loop [PARTS idx=-1]
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=1024)
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=1024)
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=1024)
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=1024)
3900: libblkid: LOWPROBE:   magic sboff=510, kboff=0
3900: libblkid: LOWPROBE: dos: ---> call probefunc()
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=512)
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=1024)
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=1024)
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=1024)
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=1024)
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=1024)
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=1024)
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=1024)
3900: libblkid: LOWPROBE:   magic sboff=0, kboff=0
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=512)
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=512)
3900: libblkid: LOWPROBE: returning TYPE value
3900: libblkid: LOWPROBE: dos: <--- (rc = 0)
3900: libblkid: LOWPROBE: assigning PTTYPE [partitions]
3900: libblkid: LOWPROBE: <-- leaving probing loop (type=dos) [PARTS idx=3]
3900: libblkid: LOWPROBE: parts: start probing for partition entry
3900: libblkid:DEVNO: found devno 0x0800 as /dev/sda
3900: libblkid: LOWPROBE: allocate a wholedisk probe
3900: libblkid: LOWPROBE: allocate a new probe
3900: libblkid: LOWPROBE: zeroize wiper
3900: libblkid: LOWPROBE: ready for low-probing, offset=0, size=2000398934016
3900: libblkid: LOWPROBE: whole-disk: YES, regfile: NO
3900: libblkid: LOWPROBE: partlist reset
3900: libblkid: LOWPROBE: parts: initialized partitions list (size=0)
3900: libblkid: LOWPROBE: --> starting probing loop [PARTS idx=-1]
3900: libblkid: LOWPROBE:   read: off=0 len=1024
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=1024)
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=1024)
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=1024)
3900: libblkid: LOWPROBE:   magic sboff=510, kboff=0
3900: libblkid: LOWPROBE: dos: ---> call probefunc()
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=512)
3900: libblkid: LOWPROBE: probably GPT -- ignore
3900: libblkid: LOWPROBE: dos: <--- (rc = 1)
3900: libblkid: LOWPROBE: gpt: ---> call probefunc()
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=0 len=512)
3900: libblkid: LOWPROBE:  #1 valid PMBR partition
3900: libblkid: LOWPROBE:  checking for GPT header at 1
3900: libblkid:   BUFFER:   reuse: off=0 len=1024 (for off=512 len=512)
3900: libblkid: LOWPROBE:   read: off=1024 len=16384
3900: libblkid: LOWPROBE: parts: create a new partition table (type=gpt, 
offset=512)
3900: libblkid: LOWPROBE: parts: add partition (start=2048, size=524288)
3900: libblkid: LOWPROBE: 

Bug#953109: Recommend [check-valid-until=no] by default

[Chris Lamb]

Hi,

> Recommend [check-valid-until=no] by default

Just an FYI that this is not (yet) supported in debian-installer:

  https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/13


Regards,

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

Bug#808724: gdc: "switch" requires a "default" case

[Witold Baryluk]

Package: gdc
Version: 4:9.2.1-3.1
Followup-For: Bug #808724

This bug seems to be fixed long time ago:

$ gdc example.d
dlang.d:10:9: error: switch statement without a default; use 'final switch' or 
add 'default: assert(0);' or add 'default: break;'
   10 | switch (1) {
$


So, bug can be closed.

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

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

Versions of packages gdc depends on:
ii  gdc-9   9.3.0-11
ii  libgphobos-dev  9.2.1-3.1

gdc recommends no packages.

gdc suggests no packages.

-- no debconf information

Bug#959684: [cveh...@saltstack.com] Action Required: SaltStack CVE Follow-Up Patch

[Elimar Riesebieter]

Hi Salvatore and others,

* Salvatore Bonaccorso  [2020-05-06 13:09 +0200]:

> Hi Elimar,
> 
> On Wed, May 06, 2020 at 10:36:42AM +0200, Elimar Riesebieter wrote:
> > Hi all,
> > 
> > please notice the attached note from saltstack! I assume this is not
> > integrated into DSA 4676-1, isn't it?
> 
> Yes this is right, those parts were missing. 
> 
> Do you have possibility to test updated salt packages for stretch?

we fired up your kindly provided deb9u4 packages and run the
verification script http://em.saltstack.com/F1sH900oN0P0M17U000Qhf7
with the following result:

CVE-2020-11651 - OK
CVE-2020-11652 - OK

Thanks for cooperation
Elimar
-- 
  Never make anything simple and efficient when a way
  can be found to make it complex and wonderful ;-)

Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions

[Marc Lehmann]

On Mon, May 04, 2020 at 12:19:43PM +0200, Chris Hofstaedtler  
wrote:
> > partitions on the same disk it is unlikely to be caused by something weird
> > in the partition tables. That, or the algorithm is completely hosed, as it
> > shouldn't depend on the partition at all, only on the disk.
> 
> Well, I tried recreating your setup on a loop blockdev, and it works
> for me:

As an intermediate result, I did sgdisk -R /dev/sde /dev/sda, and the
problem does not travel:

   # lsblk -o PATH,KNAME,MAJ:MIN,TYPE,PTTYPE,PTUUID,PARTUUID,LABEL,FSTYPE 
/dev/sda /dev/sde
   PATH  KNAME MAJ:MIN TYPE  PTTYPE PTUUID  
 PARTUUID LABEL FSTYPE
   /dev/sda  sda 8:0   disk  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd

   /dev/sda1 sda18:1   part  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d EFI   
vfat
   /dev/sda2 sda28:2   part  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119   
LVM2_member
   /dev/sda3 sda38:3   part  dos
81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d 
SSDCERntfs
   /dev/sde  sde 8:64  disk  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd

   /dev/sde1 sde18:65  part  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d   

   /dev/sde2 sde28:66  part  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119   

   /dev/sde3 sde38:67  part  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d   


So I guess replicating this is not trivial.

I think it would be more fruitful for somebody who knows the code to look
at this, as obviously lsblk takes information from some place that is not
the disk partition info, which should be more obvious (i.e. PTTYPE should
simply not differ between partitions on the same disk).

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions

[Marc Lehmann]

On Mon, May 04, 2020 at 12:19:43PM +0200, Chris Hofstaedtler  
wrote:
> > On Sun, May 03, 2020 at 09:01:49PM +0200, Chris Hofstaedtler 
> >  wrote:
> 
> > I wouldn't assume this is necessary, though, as this is almost certainly
> > a relatively simple bug to fix - since the partition type differs for
> > partitions on the same disk it is unlikely to be caused by something weird
> > in the partition tables. That, or the algorithm is completely hosed, as it
> > shouldn't depend on the partition at all, only on the disk.
> 
> Well, I tried recreating your setup on a loop blockdev, and it works
> for me:

Hi, and thanks for your efforts. I jumped the gun and upgraded to testing,
and the bug still exists - at this point, I assume lsblk somehow looks at
the partition data to detect PTTYPE (which makes no sense to me), or maybe
it looks at some gpt data not visible in gdisk output:

   # lsblk --version
   lsblk from util-linux 2.35.1
   #  lsblk -o PATH,KNAME,MAJ:MIN,TYPE,PTTYPE,PTUUID,PARTUUID,LABEL,FSTYPE
   PATH  KNAME MAJ:MIN TYPE  PTTYPE PTUUID  
 PARTUUID LABEL  FSTYPE
   /dev/sda  sda 8:0   disk  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd
   /dev/sda1 sda18:1   part  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d EFI   
 vfat
   /dev/sda2 sda28:2   part  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119   
 LVM2_member
   /dev/sda3 sda38:3   part  dos
81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d 
SSDCER ntfs

I might be able to creat some test image, or maybe I'll look at the
util-linux sources to see what issue is going on here, but either will
take some time for me.

> Which fdisk is this, because it omits important info (partition
> table type) and also doesn't show the GPT partitions?

Oh right, sorry - that is actually fdisk v1.17.3, which I use because it
doesn't support gpt and also lacks many of tghe safeguards of newer versions
that kept getting into my way. I use it for so long I forgot it's not the
debian one :().

OTOH, the current fdisk version doesn't show the mbr data on -l, so maybe
that was a good thing after all.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#959965: reprepro: Using $fullfilename with --list-format uses basedir even if a different outdir is configured

[Silas McCroskey]

Package: reprepro
Version: 5.3.0-1.1
Severity: normal

The reprepro manual states the following about $fullfilename:

The special field names $basename, $filekey and $fullfilename
denote the first package file part of this entry (i.e.  usually
the .deb, .udeb or .dsc file) as basename, as filekey (filename
relative to the outdir) and the full filename with outdir
prepended (i.e.  as relative or absolute as your outdir (or
basedir if you did not set outdir) is).

But reprepro unconditionally uses the basedir to populate
$fullfilename, regardless of whether or not an outdir was set:

} else { /* fullfilename */
value = calc_dirconcat(global.basedir,
filekeys.values[0]);
if (FAILEDTOALLOC(value))
return RET_ERROR_OOM;
v = value;
}

(source is from a fresh clone from git, using the debian branch).

$fullfilename should use outdir as described.


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

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

Versions of packages reprepro depends on:
ii  libarchive13   3.4.0-1+b1
ii  libbz2-1.0 1.0.8-2
ii  libc6  2.29-10
ii  libdb5.3   5.3.28+dfsg1-0.6
ii  libgpg-error0  1.37-1
ii  libgpgme11 1.13.1-6
ii  liblzma5   5.2.4-1+b1
ii  zlib1g 1:1.2.11.dfsg-1.2

Versions of packages reprepro recommends:
ii  apt  1.8.4

Versions of packages reprepro suggests:
ii  gpg-agent [gnupg-agent]  2.2.19-1
ii  inoticoming  0.2.3-2+b1
pn  lzip 
ii  pinentry-curses  1.1.0-3+b1

-- no debconf information

Bug#959668: os-prober: translated auto-added items in other installs are not recognized as such

[Cyril Brulebois]

Hi,

Benno Schulenberg  (2020-05-07):
> 
> Op 07-05-2020 om 08:19 schreef Cyril Brulebois:
> > My first hunch would be, given languages are tricky: “Don't assume
> > anything! Can it be that depending on the language, the device might
> > get mentioned first, and other words get postfixed instead?”
> 
> Good catch.
> 
> > In which case maybe matching '(.*/dev/[^)]\+.*)' would make the fix a
> > little more general? (Don't trust that pattern too much, -ENOCOFFEE…)
> 
> True.  The final ".*" is superfluous, though.

Right, I thoughtlessly “unanchored” the existing pattern (that I treated
as a constant) by padding it with .* on each side. :)
> 
> > po/pa.po-msgstr "(%s ਉੱਤੇ)"
> > po/tr.po-msgstr "(%s üzerinde)"
> 
> Right.  However... looking at the latest grub POT file
> (https://translationproject.org/POT-files/grub-2.04-pre1.pot),
> it no longer contains the "(on %s)" msgid.  In fact, it does
> not contain anything from '30_os-prober.in' at all any more.  :|
> 
> Did something go wrong in the packaging of grub?  Or did they
> eliminate the script?  Or were the scripts moved to a separate
> package?

Let's ask grub2 maintainers (cc'd). :)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#959964: What about moving bitshuffle into debian-science

[Picca Frédéric-Emmanuel]

Package: bitshuffle
Version: 0.3.5-3.1
Severity: wishlist

Dear Maintainer,

I would like to help improving bitshuffle by

1) unbranding lzf and lz4
2) providing hdf( plugins at the system level for hdf5-serial and hdf5-mpi

So would you considere moving bitshuffle under the debian-science team umbrella.

thanks

Frederic


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bitshuffle depends on:
ii  cython30.29.14-1
ii  libc6  2.30-7
ii  libgomp1   10-20200502-1
ii  libhdf5-openmpi-103-1  1.10.6+repack-2
ii  python33.8.2-3
ii  python3-h5py   2.10.0-7
ii  python3-numpy  1:1.18.4-1
ii  python3-pkg-resources  46.1.3-1

bitshuffle recommends no packages.

bitshuffle suggests no packages.

-- no debconf information

Bug#959963: qterminal: Bump request to 0.15.0

[Jeff Lang]

Package: qterminal
Version: 0.14.1-1+b1
Severity: wishlist

I would like to request a package for qterminal 0.15.0 as it includes several 
bug fixes and a feature to disable menu bar accelerators, which can be highly 
annoying in the current version. 

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

Kernel: Linux 5.4.0-kali4-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages qterminal depends on:
ii  libc6  2.30-2
ii  libqt5core5a   5.12.5+dfsg-10
ii  libqt5dbus55.12.5+dfsg-10
ii  libqt5gui5 5.12.5+dfsg-10
ii  libqt5widgets5 5.12.5+dfsg-10
ii  libqt5x11extras5   5.12.5-1
ii  libqtermwidget5-0  0.14.1-3
ii  libstdc++6 10-20200324-1
ii  libx11-6   2:1.6.9-2+b1

Versions of packages qterminal recommends:
ii  qterminal-l10n  0.14.1-1

qterminal suggests no packages.

-- no debconf information

Bug#959962: Missing dependencies?

[Laurent Bigonville]

Package: virt-p2v
Version: 1.42.0-1
Severity: serious

Hello,

virt-p2v has no dependencies defined, but quickly looking which external
tools it's using it should IMVHO at least requires the following
dependencies:

xz-utils for xzcat
binutils for strip
libguestfs-tools for virt-builder

It's also using bash and gzip but these are essentials and should
probably not be added to the dependencies.

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#759230: shell: Always use explicit large file API

[Herbert Xu]

There are some remaining stat/readdir calls in dash that may lead
to spurious EOVERFLOW errors on 32-bit platforms.  This patch changes
them (as well as open(2)) to use the explicit large file API.

Reported-by: Tatsuki Sugiura 
Signed-off-by: Herbert Xu 

diff --git a/configure.ac b/configure.ac
index 5dab5aa..dbd97d8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -144,8 +144,13 @@ AC_CHECK_FUNC(stat64,, [
AC_DEFINE(fstat64, fstat, [64-bit operations are the same as 32-bit])
AC_DEFINE(lstat64, lstat, [64-bit operations are the same as 32-bit])
AC_DEFINE(stat64, stat, [64-bit operations are the same as 32-bit])
+   AC_DEFINE(readdir64, readdir,
+ [64-bit operations are the same as 32-bit])
+   AC_DEFINE(dirent64, dirent,
+ [64-bit operations are the same as 32-bit])
 ])
 
+dnl OS X apparently has stat64 but not open64.
 AC_CHECK_FUNC(open64,, [
AC_DEFINE(open64, open, [64-bit operations are the same as 32-bit])
 ])
diff --git a/src/bltin/test.c b/src/bltin/test.c
index b7188df..c7fc479 100644
--- a/src/bltin/test.c
+++ b/src/bltin/test.c
@@ -473,17 +473,17 @@ static int isoperand(char **tp)
 static int
 newerf (const char *f1, const char *f2)
 {
-   struct stat b1, b2;
+   struct stat64 b1, b2;
 
 #ifdef HAVE_ST_MTIM
-   return (stat (f1, ) == 0 &&
-   stat (f2, ) == 0 &&
+   return (stat64(f1, ) == 0 &&
+   stat64(f2, ) == 0 &&
( b1.st_mtim.tv_sec > b2.st_mtim.tv_sec ||
 (b1.st_mtim.tv_sec == b2.st_mtim.tv_sec && (b1.st_mtim.tv_nsec 
> b2.st_mtim.tv_nsec )))
);
 #else
-   return (stat (f1, ) == 0 &&
-   stat (f2, ) == 0 &&
+   return (stat64(f1, ) == 0 &&
+   stat64(f2, ) == 0 &&
b1.st_mtime > b2.st_mtime);
 #endif
 }
@@ -491,17 +491,17 @@ newerf (const char *f1, const char *f2)
 static int
 olderf (const char *f1, const char *f2)
 {
-   struct stat b1, b2;
+   struct stat64 b1, b2;
 
 #ifdef HAVE_ST_MTIM
-   return (stat (f1, ) == 0 &&
-   stat (f2, ) == 0 &&
+   return (stat64(f1, ) == 0 &&
+   stat64(f2, ) == 0 &&
(b1.st_mtim.tv_sec < b2.st_mtim.tv_sec ||
 (b1.st_mtim.tv_sec == b2.st_mtim.tv_sec && (b1.st_mtim.tv_nsec 
< b2.st_mtim.tv_nsec )))
);
 #else
-   return (stat (f1, ) == 0 &&
-   stat (f2, ) == 0 &&
+   return (stat64(f1, ) == 0 &&
+   stat64(f2, ) == 0 &&
b1.st_mtime < b2.st_mtime);
 #endif
 }
@@ -509,10 +509,10 @@ olderf (const char *f1, const char *f2)
 static int
 equalf (const char *f1, const char *f2)
 {
-   struct stat b1, b2;
+   struct stat64 b1, b2;
 
-   return (stat (f1, ) == 0 &&
-   stat (f2, ) == 0 &&
+   return (stat64(f1, ) == 0 &&
+   stat64(f2, ) == 0 &&
b1.st_dev == b2.st_dev &&
b1.st_ino == b2.st_ino);
 }
diff --git a/src/cd.c b/src/cd.c
index b6742af..1ef1dc5 100644
--- a/src/cd.c
+++ b/src/cd.c
@@ -96,7 +96,7 @@ cdcmd(int argc, char **argv)
const char *path;
const char *p;
char c;
-   struct stat statb;
+   struct stat64 statb;
int flags;
int len;
 
@@ -132,7 +132,7 @@ dotdot:
c = *p;
p = stalloc(len);
 
-   if (stat(p, ) >= 0 && S_ISDIR(statb.st_mode)) {
+   if (stat64(p, ) >= 0 && S_ISDIR(statb.st_mode)) {
if (c && c != ':')
flags |= CD_PRINT;
 docd:
diff --git a/src/expand.c b/src/expand.c
index 4a5d75a..ecd7ee5 100644
--- a/src/expand.c
+++ b/src/expand.c
@@ -1286,7 +1286,7 @@ expmeta(char *name, unsigned name_len, unsigned 
expdir_len)
int metaflag;
struct stat64 statb;
DIR *dirp;
-   struct dirent *dp;
+   struct dirent64 *dp;
int atend;
int matchdot;
int esc;
@@ -1363,7 +1363,7 @@ expmeta(char *name, unsigned name_len, unsigned 
expdir_len)
p++;
if (*p == '.')
matchdot++;
-   while (! int_pending() && (dp = readdir(dirp)) != NULL) {
+   while (! int_pending() && (dp = readdir64(dirp)) != NULL) {
if (dp->d_name[0] == '.' && ! matchdot)
continue;
if (pmatch(start, dp->d_name)) {
diff --git a/src/input.c b/src/input.c
index 177fd0a..7d6be63 100644
--- a/src/input.c
+++ b/src/input.c
@@ -397,7 +397,7 @@ setinputfile(const char *fname, int flags)
int fd;
 
INTOFF;
-   if ((fd = open(fname, O_RDONLY)) < 0) {
+   if ((fd = open64(fname, O_RDONLY)) < 0) {
if (flags & INPUT_NOFILE_OK)
goto out;
exitstatus = 127;
diff --git a/src/jobs.c b/src/jobs.c
index a9e6524..f65435d 100644
--- a/src/jobs.c
+++ b/src/jobs.c
@@ -196,7 +196,7 @@ setjobctl(int on)
return;
if 

Bug#959961: Prefix not properly set?

[Laurent Bigonville]

Package: virt-p2v
Version: 1.42.0-1
Severity: grave

Hi,

When running virt-p2v-make-disk or virt-p2v-make-kiwi, I get the
folowing errors:

# virt-p2v-make-disk -o plop
virt-p2v-make-disk: cannot find /lib/x86_64-linux-gnu/virt-p2v/virt-p2v.xz

# virt-p2v-make-kiwi
/usr/bin/virt-p2v-make-kiwi: cannot find dependencies file 
(/share/virt-p2v/dependencies.suse)

The files are installed under
/usr/lib/x86_64-linux-gnu/virt-p2v/virt-p2v.xz and
/usr/share/virt-p2v/dependencies.suse.

Looks like the prefix is not properly set

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#733622: bogofilter: Crash on several emails with realloc(): invalid next size

[Matthias Andree]

https://sourceforge.net/p/bogofilter/bugs/116/#52a0

i. e. this was fixed 91 commits before bogofilter-1.2.5.rc1. I don't
know if the commit (Git cd33fc00802a75fe7b3b8a967bf879f7bc33c320) works
standalone or only in context, and I'm not researching this because for
me as upstream maintainer, this is done with the 1.2.5 release.

=> I think someone should package 1.2.5 for sid/unstable... more than
half a year after its release.