date:20200408

Hello Julien,

On Tue, Feb 18, 2020 at 12:33 PM Julien Cristau  wrote:
> Before switching in sid I'd want to:
> - be able to use the python3 version myself
> - give extensions some time to figure out their own switch
> - ideally not regress significant functionality; e.g. python-subversion
>   is still not available for python3
>
> I don't know what that means in terms of timeframe, it may or may not
> happen in time for bullseye, but I'm also not in a rush and I'd rather
> not break stuff by switching too early.

I see that python3-enabled mercurial has been in experimental for a 3
weeks now, how's it going? it would greatly help progress with the
overall py2removal effort if we could start planning to upload that
mercurial release to sid.

Can you share with us your plans here?

I understand and agree (in general) with your desire to now break
anything, but we're also at the tail end of the py2removal process, so
we are at a point where something may be broken, for some period of
time.

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

Bug#954294: __X32_SYSCALL_BIT being defined as UL constant breaks userspace

2020-04-08 Thread Andy Lutomirski

On Wed, Apr 8, 2020 at 7:34 AM Thorsten Glaser  wrote:
>
> Hello,
>
> I’m writing to you because your name shows up on this:
>
> commit 45e29d119e9923ff14dfb840e3482bef1667bbfb
> Author: Andy Lutomirski 
> Date:   Wed Jul 3 13:34:05 2019 -0700
>
> x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long
>
> Currently, it's an int.  This is bizarre.  Fortunately, the code using it
> still works: ~__X32_SYSCALL_BIT is also int, so, if nr is unsigned long,
> then C kindly sign-extends the ~__X32_SYSCALL_BIT part, and it actually
> results in the desired value.
>
> This is far more subtle than it deserves to be.  Syscall numbers are, for
> all practical purposes, unsigned long, so make __X32_SYSCALL_BIT be
> unsigned long.
>
> Signed-off-by: Andy Lutomirski 
> Signed-off-by: Thomas Gleixner 
> Link: 
> https://lkml.kernel.org/r/99b0d83ad891c67105470a1a6b63243fd63a5061.1562185330.git.l...@kernel.org
>
> This commit changed an uapi header, breaking userspace. Long debugging
> story (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954294 if you
> are interested) short, it goes like this:
>
> libseccomp exposes an interface SCMP_SYS() which is designed to expand
> to an int and be usable in cpp context. It redirects to the __NR_*
> constants from .
>
> Example: SCMP_SYS(mmap) becomes __NR_mmap or __NR_mmap2 (depending on
> the architecture).
>
> Now, most architectures define __NR_mmap as a mere integer number:
>
> asm/unistd_32.h:#define __NR_mmap 90
> asm/unistd_64.h:#define __NR_mmap 9
>
> x32 differs:
>
> asm/unistd_x32.h:#define __NR_mmap (__X32_SYSCALL_BIT + 9)
>
> This construct is, thankfully, still usable in something like
> #if (__NR_mmap > __NR_somethingelse)
> but as __X32_SYSCALL_BIT is no longer int its type also isn’t.
>
> Therefore I ask you to revert this change, bringing x32 closer
> to all other architectures.
>

One might reasonably ask whether it makes sense for syscall nrs to be
signed at all.

But regardless, this breaks userspace and we should fix it.  I can
whip up a patch to split it into X32_SYSCALL_BIT (unsigned long) and
__X32_SYSCALL_BIT (uapi, int).  Thomas, etc, does this seem
reasonable?  (For those not following all the machinations, this
change caused some userspace build failures in libseccomp and/or
systemd for reasons that are vaguely silly.)

> > Syscall numbers are, for
> > all practical purposes, unsigned long
>
> Yes, except for the one purpose of the C data type of the
> syscall constants exposed to userspace, they are.
>
> Feel free to handle __X32_SYSCALL_BIT differently in the
> kernel (although even there it *will* introduce subtle
> differences from other architectures), but please keep it
> as int as visible from userspace.
>
> Thanks in advance,
> //mirabilos
>
> PS: Please keep both me *and* the Debian bug in Cc, but
> feel free to forward to relevant lists and persons;
> I’m unsure where exactly to write to about this.
>
> @bwh: commit 45e29d119e9923ff14dfb840e3482bef1667bbfb is
> literally just this…
> -#define __X32_SYSCALL_BIT  0x4000
> +#define __X32_SYSCALL_BIT  0x4000UL
> … so can you please revert it in Debian in the meantime,
> even if you said you won’t spend time on this?
> --
> tarent solutions GmbH
> Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
> Tel: +49 228 54881-393 • Fax: +49 228 54881-235
> HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
> Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
>
> **
>
> Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
> Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.
>
> Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.
>
> **

Bug#936857: libfreenect: diff for version 1:0.5.3-2

Control: tags 936857 + patch


Dear maintainer,

I've prepared an upload for libfreenect (versioned as 1:0.5.3-2). The diff
is attached to this message.

Regards.

diff -Nru libfreenect-0.5.3/debian/changelog libfreenect-0.5.3/debian/changelog
--- libfreenect-0.5.3/debian/changelog	2016-01-01 22:37:38.0 -0500
+++ libfreenect-0.5.3/debian/changelog	2020-04-09 00:50:52.0 -0400
@@ -1,3 +1,11 @@
+libfreenect (1:0.5.3-2) unstable; urgency=medium
+
+  * Team upload.
+  * Drop python2 support; python bindings can be added again when packaging an
+upstream release supporting python3; Closes: #936857
+
+ -- Sandro Tosi   Thu, 09 Apr 2020 00:50:52 -0400
+
 libfreenect (1:0.5.3-1) unstable; urgency=medium
 
   * Recent upstream bugfix release
diff -Nru libfreenect-0.5.3/debian/control libfreenect-0.5.3/debian/control
--- libfreenect-0.5.3/debian/control	2016-01-01 22:37:38.0 -0500
+++ libfreenect-0.5.3/debian/control	2020-04-09 00:49:34.0 -0400
@@ -5,7 +5,7 @@
 Uploaders: Arne Bernin , Yaroslav Halchenko , Mark Renouf 
 Build-Depends: debhelper (>= 9), cmake,  pkg-config,
  libusb-1.0-0-dev(>= 1.0.18~), freeglut3-dev, libxmu-dev, libxi-dev,
- python-all-dev (>= 2.6.6-3~), cython, python-numpy, doxygen
+ doxygen
 X-Python-Version: 2.7
 Standards-Version: 3.9.6
 Homepage: http://openkinect.org/
@@ -104,27 +104,6 @@
  .
  This package contains the documentation of the API of libfreenect.
 
-Package: python-freenect
-Section: python
-Architecture: any
-Provides: ${python:Provides}
-Depends: ${python:Depends}, ${misc:Depends}, ${shlibs:Depends},
- libfreenect0.5 (= ${binary:Version}), python-numpy
-Suggests: python-matplotlib, python-opencv
-Description: library for accessing Kinect device -- Python bindings
- libfreenect is a cross-platform library that provides the necessary interfaces
- to activate, initialize, and communicate data with the Kinect hardware.
- Currently, the library supports access to RGB and depth video streams, motors,
- accelerometer and LED and provide binding in different languages (C++,
- Python...)
- .
- This library is the low level component of the OpenKinect project which is an
- open community of people interested in making use of the Xbox Kinect hardware
- with PCs and other devices.
- .
- This package provides freenect extension to use libfreenect functionality
- from Python and includes some demo scripts.
-
 Package: freenect
 Section: libs
 Architecture: any
diff -Nru libfreenect-0.5.3/debian/python-freenect.docs libfreenect-0.5.3/debian/python-freenect.docs
--- libfreenect-0.5.3/debian/python-freenect.docs	2016-01-01 22:37:38.0 -0500
+++ libfreenect-0.5.3/debian/python-freenect.docs	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-wrappers/python/README
diff -Nru libfreenect-0.5.3/debian/python-freenect.examples libfreenect-0.5.3/debian/python-freenect.examples
--- libfreenect-0.5.3/debian/python-freenect.examples	2016-01-01 22:37:38.0 -0500
+++ libfreenect-0.5.3/debian/python-freenect.examples	1969-12-31 19:00:00.0 -0500
@@ -1,2 +0,0 @@
-wrappers/python/demo_*
-wrappers/python/frame_convert.py
diff -Nru libfreenect-0.5.3/debian/python-freenect.install libfreenect-0.5.3/debian/python-freenect.install
--- libfreenect-0.5.3/debian/python-freenect.install	2016-01-01 22:37:38.0 -0500
+++ libfreenect-0.5.3/debian/python-freenect.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python*/*packages/freenect.so
diff -Nru libfreenect-0.5.3/debian/rules libfreenect-0.5.3/debian/rules
--- libfreenect-0.5.3/debian/rules	2016-01-01 22:37:38.0 -0500
+++ libfreenect-0.5.3/debian/rules	2020-04-09 00:49:51.0 -0400
@@ -5,12 +5,10 @@
 export MA_TRIPLET=`dpkg-architecture -qDEB_HOST_MULTIARCH`
 
 %:
-	dh $@ --with python2
+	dh $@
 
 override_dh_auto_configure:
 	dh_auto_configure -- \
-  -DBUILD_PYTHON:Bool=True \
-  -DPYTHON_EXECUTABLE:Path=/usr/bin/python \
   -DPROJECT_LIBRARY_INSTALL_DIR:Path="lib/$(MA_TRIPLET)"
 
 override_dh_auto_build-indep:
@@ -22,10 +20,6 @@
 	mkdir -p debian/html
 endif
 
-override_dh_python2:
-	dh_python2 -p python-freenect
-	if [ -x /usr/bin/dh_numpy ]; then dh_numpy -ppython-freenect; fi
-
 override_dh_installdocs:
 	dh_installdocs --all CONTRIB

Bug#954654: transition: hdf5

2020-04-08 Thread Sebastiaan Couwenberg

On 4/6/20 12:54 PM, Emilio Pozuelo Monfort wrote:
> hdf5 is currently blocked from migrating to testing on mpich due to #954244.

mpich migrated to testing. hdf5 will need some help to migrate, not all
bad rdeps will be autoremoved eventually.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#956260: bkchem: should this package be removed?

Package: bkchem
Severity: serious
Tags: bullseye, sid

Hello,
i think this pacakge should be removed from debian:


* python2-only
* dead upstream (last release in 2010)
* relatively low pop-con
* keeps in the archive at least 1 package that could be removed if we remove
  bkchem

if I dont receive within week a good reason to keep this pacakge in the archive,
i'll file for its removal.

Regards,
Sandro

-- 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

Versions of packages bkchem depends on:
ii  python  2.7.16-1
ii  python-pil  6.1.0-1
pn  python-pmw  

bkchem recommends no packages.

Versions of packages bkchem suggests:
ii  python-cairo  1.16.2-1+b1

Bug#956016: Add Flight Levels

2020-04-08 Thread Adrian Mariano

On Mon, Apr 06, 2020 at 04:00:15PM +0800, 積丹尼 Dan Jacobson wrote:
> X-debbugs-Cc: adri...@gnu.org
> Package: units
> Version: 2.19-1
> Severity: wishlist
> File: /usr/share/units/definitions.units
> 
> Add https://en.wikipedia.org/wiki/Flight_level
> 1 FL = 1 hectoft = 1e2 ft
> 
> By the way one wants to write e.g., FL310, not 310FL, but nevermind.

You can, of course, write "FL 310" if you like.  I thought about
allowing prefix units like this, most common for currency, but decided
against it.  

I've added the following:

flightlevel100 ft# Flight levels are used to ensure safe
FL flightlevel   #   vertical separation between aircraft
 #   despite variations in local air
 #   pressure.  Flight levels define
 #   altitudes based on a standard air
 #   pressure so that altimeter calibration
 #   is not needed.  This means that
 #   aircraft at separated flight levels
 #   are guaranteed to be separated.
 #   Hence the definition of 100 feet is
 #   a nominal, not true, measure.

Bug#956259: ezgo: update section to `metapackages`

Source: ezgo
Severity: important

Hello,
all of the packages generated by this source are metapackages, please update
the packages section to `metapackages`

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#956258: override: debian-science

Package: ftp.debian.org
Severity: normal

Hello,
is there a way for me to check all the override disparities regarding the
section? the ones i find at https://ftp-master.debian.org/#override are only for
the package priority.

Anyhow, some more overrides to update:

science-robotics: Override says science - optional, .deb says metapackages - 
optional
science-engineering-dev: Override says science - optional, .deb says 
metapackages - optional
science-chemistry: Override says science - optional, .deb says metapackages - 
optional
science-presentation: Override says science - optional, .deb says metapackages 
- optional
science-neuroscience-modeling: Override says science - optional, .deb says 
metapackages - optional
science-astronomy: Override says science - optional, .deb says oldlibs - 
optional
science-dataacquisition: Override says science - optional, .deb says 
metapackages - optional
science-nanoscale-physics: Override says science - optional, .deb says 
metapackages - optional
science-typesetting: Override says science - optional, .deb says metapackages - 
optional
science-psychophysics: Override says science - optional, .deb says metapackages 
- optional
science-engineering: Override says science - optional, .deb says metapackages - 
optional
science-machine-learning: Override says science - optional, .deb says 
metapackages - optional
science-viewing: Override says science - optional, .deb says metapackages - 
optional
science-astronomy-dev: Override says science - optional, .deb says oldlibs - 
optional
science-electrophysiology: Override says science - optional, .deb says 
metapackages - optional
science-simulations: Override says science - optional, .deb says metapackages - 
optional
science-highenergy-physics-dev: Override says science - optional, .deb says 
metapackages - optional
science-geometry: Override says science - optional, .deb says metapackages - 
optional
science-highenergy-physics: Override says science - optional, .deb says 
metapackages - optional
science-linguistics: Override says science - optional, .deb says metapackages - 
optional
science-dataacquisition-dev: Override says science - optional, .deb says 
metapackages - optional
science-logic: Override says science - optional, .deb says metapackages - 
optional
science-social: Override says science - optional, .deb says metapackages - 
optional
science-mathematics: Override says science - optional, .deb says metapackages - 
optional
science-distributedcomputing: Override says science - optional, .deb says 
metapackages - optional
science-electronics: Override says science - optional, .deb says oldlibs - 
optional
science-physics: Override says science - optional, .deb says metapackages - 
optional
science-numericalcomputation: Override says science - optional, .deb says 
metapackages - optional
science-economics: Override says science - optional, .deb says metapackages - 
optional
science-nanoscale-physics-dev: Override says science - optional, .deb says 
metapackages - optional
science-robotics-dev: Override says science - optional, .deb says metapackages 
- optional
science-mathematics-dev: Override says science - optional, .deb says 
metapackages - optional
science-meteorology-dev: Override says science - optional, .deb says 
metapackages - optional
science-viewing-dev: Override says science - optional, .deb says metapackages - 
optional
science-meteorology: Override says science - optional, .deb says metapackages - 
optional
science-biology: Override says science - optional, .deb says metapackages - 
optional
science-imageanalysis: Override says science - optional, .deb says metapackages 
- optional
science-physics-dev: Override says science - optional, .deb says metapackages - 
optional
science-geography: Override says science - optional, .deb says metapackages - 
optional
science-neuroscience-cognitive: Override says science - optional, .deb says 
metapackages - optional
science-financial: Override says science - optional, .deb says metapackages - 
optional
science-statistics: Override says science - optional, .deb says metapackages - 
optional

Thanks!

Bug#953052: [Help] Re: Bug#953052: psychopy: python2 dependencies

On Wed, Apr 8, 2020 at 12:09 PM Andreas Tille  wrote:
>
> Control: tags -1 help
>
> Hi DPMT,
>
> I need to admit I'm currentl overwhelmed with COVID-19 hackathon.
> A quick view does not really show any suspicious things to me.
> Any help (including team upload / NMU) would be appreciated.

didnt take much to figure it out..

$ aptitude why psychopy python2.7
p   psychopyRecommends python3-pyo
p   python3-pyo Recommends jackd2
p   jackd2  Dependspython-dbus
p   python-dbus Dependspython2 (>= 2.7~)
p   python2 Dependspython2.7 (>= 2.7.17~rc1-1~)


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

Bug#953722: ITP: josm-installer -- Editor for OpenStreetMap (installer)

2020-04-08 Thread Sebastiaan Couwenberg

On 4/9/20 4:37 AM, Christoph Anton Mitterer wrote:
>> The package will be maintained with in the Debian GIS team where
>> it will eventually replace the josm package.
> 
> I'm afraid but this is a really unfortunate idea.

Don't be:

 https://lists.debian.org/debian-gis/2020/04/msg0.html

> Downloader packages - and that's what this is - are generally a bad
> idea.

You don't have to use it.

It's no different from users downloading the JAR themselves, the package
just integrates it in the desktop environment and schedules periodic
downloads.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#950578: Linux 5.5.0-1-arm64: kernel panic after module bcmgenet was loaded

2020-04-08 Thread Steven Shiau


Package: src:linux
Version: 5.5.13-2
Severity: normal

Dear Maintainer,

I created an arm64 live system for Raspberry Pi 4 using Debian 
live-build, and it successfully booted into the initramfs.
However, after the network module bcmgenet was loaded, I got the kernel 
panic.

Attached please find the output messages on the serial console.
If you need more info or tests, please let me know.

Thank you very much.

Steven

--
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

[0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
[0.00] Linux version 5.5.0-1-arm64 (debian-ker...@lists.debian.org) 
(gcc version 9.3.0 (Debian 9.3.0-8)) #1 SMP Debian 5.5.13-2 (2020-03-30)
[0.00] Machine model: Raspberry Pi 4 Model B Rev 1.1
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 256 MiB at 0xec00
[0.00] NUMA: No NUMA configuration found
[0.00] NUMA: Faking a node at [mem 
0x-0xfbff]
[0.00] NUMA: NODE_DATA [mem 0xeb9a9100-0xeb9aafff]
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x-0x3fff]
[0.00]   DMA32[mem 0x4000-0xfbff]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x07ff]
[0.00]   node   0: [mem 0x4000-0xfbff]
[0.00] Initmem setup node 0 [mem 0x-0xfbff]
[0.00] percpu: Embedded 32 pages/cpu s93656 r8192 d29224 u131072
[0.00] Detected PIPT I-cache on CPU0
[0.00] CPU features: detected: EL2 vector hardening
[0.00] CPU features: kernel page table isolation forced ON by KASLR
[0.00] CPU features: detected: Kernel page table isolation (KPTI)
[0.00] ARM_SMCCC_ARCH_WORKAROUND_1 missing from firmware
[0.00] CPU features: detected: ARM erratum 1319367
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 790272
[0.00] Policy zone: DMA32
[0.00] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 cma=64M 
cma=256M cma=256M 
video=HDMI-A-1:1920x1080M@60,margin_left=48,margin_right=48,margin_top=48,margin_bottom=48
 smsc95xx.macaddr=DC:A6:32:55:44:A4 vc_mem.mem_base=0xec0 
vc_mem.mem_size=0x1000  boot=live union=overlay config components noswap 
edd=on nomodeset enforcing=0 locales=en_US keyboard-layouts=en 
ocs_live_run="ocs-live-general" ocs_live_extra_param="" ocs_live_batch="no" 
net.ifnames=0 noeject fetch=http://192.168.76.254/filesystem-czarm64.squashfs 
ocs_daemonon="ssh" console=ttyAMA0,115200n81
[0.00] Dentry cache hash table entries: 524288 (order: 10, 4194304 
bytes, linear)
[0.00] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, 
linear)
[0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
[0.00] software IO TLB: mapped [mem 0x02684000-0x06684000] (64MB)
[0.00] Memory: 2757316K/3211264K available (9980K kernel code, 1758K 
rwdata, 3684K rodata, 5120K init, 552K bss, 191804K reserved, 262144K 
cma-reserved)
[0.00] random: get_random_u64 called from 
__kmem_cache_create+0x44/0x5c0 with crng_init=0
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] ftrace: allocating 35767 entries in 140 pages
[0.00] ftrace: allocated 140 pages with 3 groups
[0.00] rcu: Hierarchical RCU implementation.
[0.00] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4.
[0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 
jiffies.
[0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[0.00] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[0.00] GIC: Using split EOI/Deactivate mode
[0.00] arch_timer: cp15 timer(s) running at 54.00MHz (phys).
[0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
[0.06] sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 
4398046511102ns
[0.000318] Console: colour dummy device 80x25
[0.000446] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 108.00 BogoMIPS (lpj=216000)
[0.000460] pid_max: default: 32768 minimum: 301
[0.000628] LSM: Security Framework initializing
[0.000660] Yama: disabled by default; enable with sysctl kernel.yama.*
[0.000756] AppArmor: AppArmor initialized
[0.000769] TOMOYO Linux initialized
[0.000905] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes, 
linear)
[0.000966] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 
bytes, linear)
[0.003000] ASID allocator initialised with 32768 entries
[0.003135]

Bug#956257: RFS: e2tools/0.0.16-6.2 [NMU] -- utilities for manipulating files in an ext2/ext3 filesystem

2020-04-08 Thread atzlinux



Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : e2tools
Version : 0.0.16-6.2
Upstream Author : Keith Sheffield 
* URL : http://home.earthlink.net/~k_sheff/sw/e2tools/index.html
* License : GPL-2+
* Vcs : None
Section : misc

It builds those binary packages:

e2tools - utilities for manipulating files in an ext2/ext3 filesystem

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

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

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

dget -x
https://mentors.debian.net/debian/pool/main/e/e2tools/e2tools_0.0.16-6.2.dsc

Changes since the last upload:

* Non-maintainer upload.
.
[ Helmut Grohne ]
* Fix FTCBFS: Export CC supplied by buildtools.mk for configure.
(Closes: #-1)
.
[ faris xiao ]
* Changed source format to 3.0 (quilt)
* Bumped debhelper-compat-version to 12
* Bumped Standards-Version to 4.5.0
* Fix lintian check: priority-extra-is-replaced-by-priority-optional
* Fix FTCBFS. (Closes: #916417)
* delete changelog trailing-whitespace
* control:+Rules-Requires-Root: no
* replaced debian/compat with the debhelper-compat virtual package
* fix lintian: wiki-copyright-format-uri
* fix lintian: obsolete-field-in-dep5-copyright upstream-maintainer
dep5-copyright-license-name-not-unique gpl-2+
* +DEB_BUILD_MAINT_OPTIONS=hardening=+all
* add fix-spelling-error-in-binary.patch: fileystem -> filesystem
* fix lintian:copyright-refers-to-symlink-license

Regards,

-- 
肖盛文 Faris Xiao
邮箱：atzli...@yeah.net
微信：atzlinux
ＱＱ：909868357
铜豌豆 Linux 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com

Bug#956256: boinc-manager: the -g/--gui_rpc_port option doesn't work now

2020-04-08 Thread Russell Coker

Package: boinc-manager
Version: 7.16.5+dfsg-1exp1
Severity: normal

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953613

Previously I used the -g option to connect to a different port on localhost
for each boinc server (redirected via a ssh tunnel to the real server).  I
filed the above bug report about boincmgr not connecting on startup.  Since
then it has stopped accepting the -g option so I can't connect to other
systems in this way.  It connects to port 31416 regardless of the -g option.

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages boinc-manager depends on:
ii  boinc-client  7.16.5+dfsg-1
ii  libboinc7 7.16.5+dfsg-1
ii  libc6 2.30-4
ii  libgcc-s1 [libgcc-s1] 10-20200402-1
ii  libglib2.0-0  2.64.1-1
ii  libgtk-3-03.24.17-1
ii  libnotify40.7.9-1
ii  libsqlite3-0  3.31.1-4
ii  libstdc++610-20200402-1
ii  libwxbase3.0-0v5  3.0.4+dfsg-15
ii  libwxgtk-webview3.0-gtk3-0v5  3.0.4+dfsg-15
ii  libwxgtk3.0-gtk3-0v5  3.0.4+dfsg-15

boinc-manager recommends no packages.

Versions of packages boinc-manager suggests:
ii  libgl1-mesa-glx  20.0.2-1
ii  libxt6   1:1.1.5-1+b3

-- no debconf information

Bug#953722: ITP: josm-installer -- Editor for OpenStreetMap (installer)

2020-04-08 Thread Christoph Anton Mitterer

Hey.

> The package will be maintained with in the Debian GIS team where
> it will eventually replace the josm package.

I'm afraid but this is a really unfortunate idea.


Downloader packages - and that's what this is - are generally a bad
idea.

They circumvent package management, any tools building upon package
management (from simply things like apt-listchanges to advanced things
like Icinga/Nagios checks for package upgrades) and any reasonable
security support.

I know only few such downloader tools which do it really right, i.e. in
a secure way.
Just checking for some signatures isn't typically enough, as it allows
for things like downgrade attacks.

Some downloader tools even use the upstream keys for verification,
which may sound good at a first glance, but would effectively allow an
hostile (or hacked) upstream to selectively send hacked versions of the
code/binaries to selected users only (thereby making it even much
harder to ever detect, as when *all* users would have to bee


Security wise (and generally), it's probably safest to hardcode the
valid hashsums for the downloaded files within the downloader package
and really upgrade the package everytime a new version of code/binaries
comes out.
This would not mean a general circumvention of the distributions
package management tool.


I personally can only think of very few cases, where a downloader
package is justified (like when legal reasons prevent shipping
something, e.g. as with ttf-mscorefonts-installer).
For most other things one should wonder whether its not better to
simply drop a package from the distro if it cannot be actually
maintained within that distro.

After all, Linux isn't the Windows world, where each and every software
brings it's own (often crappy) installers, and where this causes
gazillions of problems and security issues.


Cheers,
Chris.

Bug#956255: pulseeffects: Version 4.7.2+ needs libboost 1.72+

2020-04-08 Thread Boyuan Yang

Source: pulseeffects
Version: 4.7.1-1
Severity: important
Tags: help

According to https://github.com/wwmm/pulseeffects/issues/645 ,
pulseeffects with version 4.7.2+
needs new features provided by libboost 1.72 or higher. Since Debian
has just started the
preparation of transition onto boost 1.71, it could take a long time
before boost 1.72 is available
on Debian and pulseeffects version in Debian could be stuck here. If
you have any good
solution, please let me know.

-- 
Best,
Boyuan Yang

Bug#956082: Salsa Repository

2020-04-08 Thread fancycade

I have built the package and created a repo on salsa: 
https://salsa.debian.org/fancycade-guest/validators

Bug#954311: Not just rendering issues...

2020-04-08 Thread Pascal Giard

Thanks for the information, I appreciate it.

Apparently I missed the transition from intel_drv to modesetting_drv.

After switching to modesetting (instead of intel) and purging
xserver-xorg-video-intel, the workaround in /etc/drirc is no longer needed.

Best regards,

-Pascal
--
Homepage (http://pascal.giard.info)
École de technologie supérieure (http://etsmtl.ca)




On Wed, Apr 8, 2020 at 10:52 AM Timo Aaltonen  wrote:

> On 8.4.2020 17.15, Pascal Giard wrote:
> > On Mon, Apr 6, 2020 at 12:05 PM Timo Aaltonen  > > wrote:
> >
> > On 6.4.2020 1.55, Pascal Giard wrote:
> > > Thanks A LOT for the /etc/drirc trick, it fixed the problem
> > > detailed below for me.
> > > Took me over an hour to figure out what was wrong and to end up on
> > this
> > > bug report.
> > >
> > > I have a Thinkpad T480 (Intel UHD 620).
> > >
> > > The new iris driver causes all my video players to crash (e.g.,
> VLC or
> > > mpv) and prevents Zoom from converting my recorded sessions.
> > Do you use xserver-xorg-video-intel? If yes, get rid of it.
> >
> >
> > I do use it, yes. Which driver am I suppose to use instead?
>
> The default, which is modesetting_drv.so from the xserver.
>
>
> --
> t
>

Bug#956045: gnome-keyring: several cryptographic vulnerabilities

2020-04-08 Thread brian m. carlson

On 2020-04-08 at 12:15:22, Daiki Ueno wrote:
> "brian m. carlson"  writes:
> > [2] is an example of a cross-VM cryptographic timing attack, which can
> > also be applied across processes.  Other timing attacks are known even
> > across networks.
> 
> I am not sure why you suddenly mention cross-VM attacks while VMs are a
> different beast from containers.

The attack I mentioned states that it is possible to simply run on the
same processor as the affected process to conduct a side-channel attack.
That applies to containers as well as other processes, in addition to
VMs.

> > It is, in general, not safe to assume that any timing attack is
> > unexploitable.
> 
> I would also be concerned with that, if this was reported against crypto
> components.  However, this was reported against desktop, where
> protecting active attacks is not a goal for various reasons:
> https://wiki.gnome.org/Projects/GnomeKeyring/SecurityPhilosophy#Active_Attacks

gnome-keyring stores data in a cryptographic format and is therefore a
cryptographic tool.  The standard cryptographic model assumes an active
attacker, Mallory, who tampers with the data and monitors the actors.
Even if you do not wish to protect against active attacks where an
attacker tampers with the data, reasonable users will expect
cryptographic tools to do so.  Moreover, it is in fact part of the
threat model of other password managers, such as 1Password.

Moreover, protecting against timing attacks like this is extremely
simple.  It can be done with three lines of portable C:

  int x = 0;
  for (size_t i = 0; i < n; i++)
  x |= a[i] ^ b[i];

Now x is zero if the values matched, and nonzero if they didn't, and the
operation is constant time.  There's no reason not to fix this, even if
you don't consider it a vulnerability.

You have also not mentioned the other attack which I mentioned in which
there is information disclosure of metadata.  This is in fact trivial to
reproduce and is in my opinion the most damning of the vulnerabilities
because it is entirely passive and can be done completely offline.

An attacker should not be able to determine from my keyring how many
GnuPG keys I have stored passphrases for, which wireless network
passwords I've saved, or if I have a password for a given username on a
given Git hosting site.  Right now, all of those are trivial from my
login keyring.

The fix to issue 1 is a simple, well-known technique which is standard
practice among cryptographic tools.  The fix to the other issues is to
encrypt all the data using a secure AEAD or EtM construction.  Since the
former is easy to do and the latter is required to fix the most severe
of the issues, I'm not sure why we're arguing about the particulars.

I should also point our that when someone reports a security issue to
you with a disclosure deadline, the right time to discuss the matter or
dispute the findings is during the coordination period.  If you don't
bother to respond then, then the reporter can only assume that you don't
care at all.  I received no such discussion or feedback about the
reports during the 45 day disclosure window, only notification that some
bug reports were filed.

I would not perform coordinated disclosure with the GNOME Project again.

I stand by my bug report that these issues represent security-related
defects in the gnome-keyring package and that they need to be fixed.
Unless you are specifically disputing that they constitute defects
needing fixing, or are reporting on your intention to productively fix
them, I ask you not to further respond to this report.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

signature.asc
Description: PGP signature

Bug#953198: ronn 0.9.0 uploaded to experimental

2020-04-08 Thread Cédric Boutillier

Hi!

Thank you for your work. I am uploading right now your version with some
additional commits to experimental, as some reverse build-dependencies
(in particular shapelib) are failing to build with this new version.

Looking forward to your next contribution to the Ruby team

Best wishes,

Cédric



signature.asc
Description: PGP signature

Bug#956146: lintian: check for rules enabling --as-needed

2020-04-08 Thread Chris Lamb

tags 956146 + moreinfo
thanks

Andreas,

> if I understood correctly, the bullseye toolchain defaults to linking
> with --as-needed. Therefore it should no longer be neccessary to inject
> -Wl,--as-needed into the build process, allowing d/rules to be further
> minimized.
> 
> Some common ways of adding --as-needed that I found in the (possibly
> ancient) rules files on my local hard disk:

Thanks for this example. We can actually use codesearch to get a crude
idea of the prevalence of this:

  
https://codesearch.debian.net/search?q=path%3Adebian%2Frules+%5C-Wl%2C%5C-%5C-as-needed=0

Any input on whether a brute grep for "-Wl,--as-needed" in debian/
rules would be sufficient to catch most instances of these? (Feel free
to drop moreinfo tag upon replying.)


Regards,

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

Bug#956254: python3-pykdl: PyKDL crashes Python 3 interpretter (SIGABRT) if any API accepting a str is used

2020-04-08 Thread Shane Loretz

Package: python3-pykdl
Version: 1.4.0-7
Severity: important
Tags: patch

Dear Maintainer,


The package python3-pykdl crashes the Python 3 interpretter if any API
accepting a str is used. I've tested this in both Debian Buster and Sid.

$ python3 -c "import PyKDL; PyKDL.Tree('foobar')"
python3: 
/build/orocos-kdl-oHbJfL/orocos-kdl-1.4.0/python_orocos_kdl/PyKDL/std_string.sip:52:
 int convertTo_std_string(PyObject*, void**, int*, PyObject*): Assertion 
`PyUnicode_Check(s)' failed.
Aborted (core dumped)
$ echo $?
134

The following patch resolves the issue on both Buster (1.4.0-7) and Sid
(1.4.0-8)


Index: orocos-kdl-1.4.0/python_orocos_kdl/PyKDL/std_string.sip
===
--- orocos-kdl-1.4.0.orig/python_orocos_kdl/PyKDL/std_string.sip
+++ orocos-kdl-1.4.0/python_orocos_kdl/PyKDL/std_string.sip
@@ -48,9 +48,7 @@
  return 1;
  }
  if (PyUnicode_Check(sipPy)) {
-PyObject* s = PyUnicode_AsEncodedString(sipPy, "UTF-8", "");
-*sipCppPtr = new std::string(PyUnicode_AS_DATA(s));
-Py_DECREF(s);
+*sipCppPtr = new std::string(PyUnicode_AsUTF8(sipPy));
 return 1;
  }
 #if PY_MAJOR_VERSION < 3


Would you be willing to apply that patch and release a new version to
Buster and Sid?


Cheers,
Shane


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

Kernel: Linux 5.3.0-45-generic (SMP w/8 CPU cores)
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 python3-pykdl depends on:
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  liborocos-kdl1.4  1.4.0-7+b1
ii  libpython3.7  3.7.3-2+deb10u1
ii  libstdc++68.3.0-6
ii  python3   3.7.3-1
ii  python3-sip   4.19.14+dfsg-2

python3-pykdl recommends no packages.

python3-pykdl suggests no packages.

-- no debconf information
Index: orocos-kdl-1.4.0/python_orocos_kdl/PyKDL/std_string.sip
===
--- orocos-kdl-1.4.0.orig/python_orocos_kdl/PyKDL/std_string.sip
+++ orocos-kdl-1.4.0/python_orocos_kdl/PyKDL/std_string.sip
@@ -48,9 +48,7 @@
  return 1;
  }
  if (PyUnicode_Check(sipPy)) {
-PyObject* s = PyUnicode_AsEncodedString(sipPy, "UTF-8", "");
-*sipCppPtr = new std::string(PyUnicode_AS_DATA(s));
-Py_DECREF(s);
+*sipCppPtr = new std::string(PyUnicode_AsUTF8(sipPy));
 return 1;
  }
 #if PY_MAJOR_VERSION < 3

Bug#782654: Bug#838416: Bug#782654: Bug#838416: ITP: bazel -- Fast and correct automated build system by Google

2020-04-08 Thread Philipp Kern

On 2020-04-08 19:43, Olek Wojnar wrote:
Bazel has suddenly become more important because it is preventing us
from getting packages working that would help with the COVID-19
pandemic. Due to the significance, I am copying the Debian Med team as
well as key people from this bug's history in the hopes of getting
something moving quickly.

On Tue, 22 May 2018 14:55:19 -0600 Kyle Moffett
wrote:

I spent a while working on it off and on, but there is a decent amount
of tweaking and other packaging work needed to get policy-compliant
bazel packages. (E.G: There are quite a few binary JAR files shipped
in the upstream tarball that don't necessarily match the versions in
Debian).

I just didn't have the spare time, especially now that I have a kid,
to sink into one package.

I can relate to the kid/time issues! ;) Have you had any time to work
on it recently? Did you ever upload any of your work?

In the meantime, I see that Bazel has an unofficial Ubuntu build [1].
Do you know anything about that? It seems like a good place for us to
start if you aren't close to a product yourself.

That's the build Google provides that is built with Bazel itself, using
a ton of vendored libraries. (Because that's how Google operates
internally.)

Generally the pkg_deb output[1] is not really policy-compliant and more
built from the ground up without any Debian tooling. So the /mere
existence/ of that package (which was there from the beginning) does not
help the quest of getting Bazel packaged for Debian, unfortunately.

Kind regards
Philipp Kern, obviously not speaking for Google

[1]
https://github.com/bazelbuild/bazel/blob/f828b4c77805ad0ea6afecef798aa69d68bec8d4/scripts/packages/debian/BUILD#L69

Bug#955056: workaround Re: snakemake: FTBFS with Sphinx 2.4: AttributeError: 'member_descriptor' object has no attribute 'expandtabs'

2020-04-08 Thread Rebecca N. Palmer

An upstream comment says common.py:lazy_property is the problem item, 
and excluding that from the documentation does make Sphinx succeed (I 
haven't tested a whole build):


--- snakemake-5.10.0.orig/docs/conf.py
+++ snakemake-5.10.0/docs/conf.py
@@ -107,6 +107,8 @@ pygments_style = 'sphinx'
 # If true, keep warnings as "system message" paragraphs in the built 
documents.

 #keep_warnings = False

+# skip internal class that Sphinx 2 can't process (#296)
+autodoc_default_options = {'exclude-members': 'lazy_property'}

 # -- Options for HTML output 
--



This is obviously not an ideal fix, but it's an internal class with 
little documentation to begin with: 
https://snakemake.readthedocs.io/en/stable/api_reference/internal/snakemake.html#snakemake.common.lazy_property

Bug#956253: mu-editor: Update to 1.1.0 alpha 2 or newer

2020-04-08 Thread Ryan Pavlik

Package: mu-editor
Version: 1.1.0~alpha2+dfsg-0.1
Severity: wishlist
Tags: patch

Dear Maintainer,

It would be good to get the alpha version of mu-editor in Debian, since the 
existing version
has some issues in my experience accessing (at least newer) Adafruit devices 
with
CircuitPython (blank REPL, etc).

I've forked the repo on Salsa and tried my hand at updating the package:

https://salsa.debian.org/rpavlik-guest/mu-editor

(just to the alpha2 level that uscan found)

I can build it locally (on Buster) and on salsa-ci (on unstable?) but when 
building in a buster cowbuilder,
I'm getting a strange error (see log below).
Not sure if this is a blocking issue, but this is the first package I've had 
this problem with.
Once this issue gets resolved I think the package on my fork would be ready to 
upload.
(You may take it and modify it, or alternately sponsor it, as I do not have 
upload capability)

Thanks,
Ryan

Log:


   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/mu-editor-1.1.0~alpha2+dfsg'
xvfb-run -a dh_auto_test
pybuild --test -i python{version} -p 3.7
D: pybuild pybuild:545: version: 3.20190308
D: pybuild pybuild:546: ['/usr/bin/pybuild', '--test', '-i', 'python{version}', 
'-p', '3.7']
D: pybuild pybuild:36: cfg: Namespace(after_build=None, after_clean=None, 
after_configure=None, after_install=None, after_test=None, before_build=None, 
before_clean=None, before_configure=None, before_install=None, 
before_test=None, build_args=None, build_only=False, clean_args=None, 
clean_only=False, configure_args=None, configure_only=False, custom_tests=True, 
destdir='debian/tmp', detect_only=False, 
dir='/build/mu-editor-1.1.0~alpha2+dfsg', disable=None, ext_destdir=None, 
ext_pattern='\\.so(\\.[^/]*)?$', ext_sub_pattern=None, ext_sub_repl=None, 
install_args=None, install_dir=None, install_only=False, 
interpreter=['python{version}'], list_systems=False, name='mu-editor', 
print_args=None, quiet=False, really_quiet=False, system=None, test_args=None, 
test_nose=False, test_only=True, test_pytest=True, test_tox=False, 
verbose=True, versions=['3.7'])
D: pybuild __init__:36: cannot initialize 'cmake' plugin
Traceback (most recent call last):
  File "/usr/share/dh-python/dhpython/build/__init__.py", line 32, in 
module.BuildSystem.is_usable()
  File "/usr/share/dh-python/dhpython/build/base.py", line 120, in is_usable
raise Exception("missing command: %s" % command)
Exception: missing command: cmake
D: pybuild tools:232: invoking: /usr/bin/dpkg-architecture
D: pybuild pybuild:129: detected build system: distutils (certainty: 60%)
I: pybuild pybuild:272: mkdir -p 
/build/mu-editor-1.1.0~alpha2+dfsg/.pybuild/cpython3_3.7_mu-editor/build/mu/resources/fonts;
 cp /usr/share/fonts/truetype/inconsolata/Inconsolata.otf 
/build/mu-editor-1.1.0~alpha2+dfsg/.pybuild/cpython3_3.7_mu-editor/build/mu/resources/fonts/Inconsolata.otf
D: pybuild tools:232: invoking: mkdir -p 
/build/mu-editor-1.1.0~alpha2+dfsg/.pybuild/cpython3_3.7_mu-editor/build/mu/resources/fonts;
 cp /usr/share/fonts/truetype/inconsolata/Inconsolata.otf 
/build/mu-editor-1.1.0~alpha2+dfsg/.pybuild/cpython3_3.7_mu-editor/build/mu/resources/fonts/Inconsolata.otf
I: pybuild base:217: cd 
'/build/mu-editor-1.1.0~alpha2+dfsg/.pybuild/cpython3_3.7_mu-editor/build'; 
python3.7 -m pytest --random-order
D: pybuild tools:232: invoking: cd 
'/build/mu-editor-1.1.0~alpha2+dfsg/.pybuild/cpython3_3.7_mu-editor/build'; 
python3.7 -m pytest --random-order
= test session starts ==
platform linux -- Python 3.7.3, pytest-3.10.1, py-1.7.0, pluggy-0.8.0
Using --random-order-bucket=module
Using --random-order-seed=926224

rootdir: /build/mu-editor-1.1.0~alpha2+dfsg, inifile:
plugins: xvfb-1.0.0, random-order-1.0.4
Aborted
E: pybuild pybuild:341: test: plugin distutils failed with: exit code=134: cd 
'/build/mu-editor-1.1.0~alpha2+dfsg/.pybuild/cpython3_3.7_mu-editor/build'; 
python3.7 -m pytest --random-order
Traceback (most recent call last):
  File "/usr/bin/pybuild", line 338, in main
run(func, i, version, c)
  File "/usr/bin/pybuild", line 289, in run
result = func(context, args)
  File "/usr/share/dh-python/dhpython/build/base.py", line 267, in wrapped_func
raise Exception(msg)
Exception: exit code=134: cd 
'/build/mu-editor-1.1.0~alpha2+dfsg/.pybuild/cpython3_3.7_mu-editor/build'; 
python3.7 -m pytest --random-order
dh_auto_test: pybuild --test -i python{version} -p 3.7 returned exit code 13
make[1]: *** [debian/rules:42: override_dh_auto_test] Error 25
make[1]: Leaving directory '/build/mu-editor-1.1.0~alpha2+dfsg'
make: *** [debian/rules:25: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2





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

Bug#956252: RFP: largelavenderlink -- A web conferencing system designed for online learning

2020-04-08 Thread Olek Wojnar

Package: wnpp
Severity: wishlist

* Package name: largelavenderlink
  Version : 2.2.3
  Upstream Author : BigBlueButton Inc. 
* URL : https://bigbluebutton.org/open-source-license/
* License : (GPL, LGPL v3)
  Programming Lang: (ActionScript, Java, Grails, Scala)
  Description : A web conferencing system designed for online learning

This program provides real-time sharing of audio, video, slides, chat, and
screen. Students are engaged through sharing of emoji icons, polling, and
breakout rooms.


Relevant packaging information:
Source code is hosted on GitHub:
https://github.com/bigbluebutton/bigbluebutton

Given the increased social distancing and closed schools during the COVID-19
pandemic, increased remote learning and collaboration is incredibly
important. This package will help to make such tools available in Debian.

Note that the developer has a trademark on the name "BigBlueButton" and the
logo. The reason for the alliterative name change is to respect the
trademark of the author while using the software package that they developed
in accordance with the license under which it was released.

Bug#712451: [pkg-apparmor] Bug#712451: Please support AppArmor network rules

2020-04-08 Thread Heenec

intrigeri:
> FWIW, this is now mentioned in the manpage that documents the policy
> language: apparmor.d(5)

Maybe I have not read the manual thoroughly enough, but I have not found
mentions of features that does not work in Debian yet. Maybe such notice
should be placed in "Network Rules" section of the manual? Or in
"KNOWN BUGS"? So that newcomers will not be misguided (like me).

Okay, it's my bad that I have not checked explicitly if it works. But
IMO there is an issue with documentation if you can't understand from it
what is supposed to be working and what is not.

By the way, ping under apparmor fails with "ping: socket: Operation not
permitted", while wget or curl works pretty well under the same profile.
Don't know if it is supposed to be like it.

Heenec


0x4B12C0FAA12F367B.asc
Description: application/pgp-keys

Bug#956250: RFS: python-jsbeautifier/1.11.0-1 -- JavaScript unobfuscator and beautifier (python3)

2020-04-08 Thread Håvard Flaget Aasen

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-jsbeautifier"

 * Package name: python-jsbeautifier
   Version : 1.11.0-1
   Upstream Author : Liam Newman, Einar Lielmanis, et al.

 * URL : https://github.com/beautify-web/js-beautify
 * License : MIT
 * Vcs : https://salsa.debian.org/debian/python-jsbeautifier
   Section : python

It builds those binary packages:

  python3-jsbeautifier - JavaScript unobfuscator and beautifier (python3)
  jsbeautifier - JavaScript unobfuscator and beautifier

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-jsbeautifier/python-jsbeautifier_1.11.0-1.dsc

Changes since the last upload:

   * New upstream version 1.11.0
   * Add minimum version for python3-six in d/control
   * Add Upstream-Contact in d/copyright

This might have lintian warnings which is related to this bug #956151

Regards,
Håvard

Bug#956251: xscreensaver-demo do not handle correctly domain part of usernames

2020-04-08 Thread Vincent Danjean

Package: xscreensaver
Version: 5.42+dfsg1-1
Severity: normal

  Hi,

  I run xscreensaver (with xfce4) on machines that use SSSD
to managed its users. There are several source of authentification
(as allowed by SSSD) but the main one (and default one) is to
authenticate against an AD (windows kind of ldap/kerberos).
  The important thing is that user names (ie logins) are of the
form name@domain

  When launching xscreensaver-demo, I always got the following
message (sorry, its in French):
===
xscreensaver-demo est lancé par l'utilisateur «name@domain» sur la machine 
«myhostname».
Cependant le xscreensaver gérant l'écran «:0.0»
est lancé par l'utilisateur «name»  sur la machine «domain@myhostname».

Comme ce sont des utilisateurs différents, ils ne vont pas lire/écrire
le même fichier «~/.xscreensaver», donc xscreensaver-demo ne fonctionnera
pas correctement.

Vous devez soit relancer xscreensaver-demo en tant que «name», soit relancer
xscreensaver en tant que «name@domain».

Relancer le démon xscreensaver maintenant ?

Annuler / Valider
==
[approximate translation:]
xscreensaver-demo is launched by the «name@domain» user on the «myhostname» 
machine.
However, the xscreensaver managing the screen «:0.0»
is launched by the «name» user on the «domain@myhostname» machine.

As these are two different users, they won't read/write
the same «~/.xscreensaver» file, so xscreensaver-demo won't work
correctly.

You must either restart xscreensaver-demo as «name», or restart
xscreensaver as «name@domain».

Restart xscreensaver daemon now?

Cancel / Validate
==

Using "Annuler" (ie cancel) or "Valider" (validate) leads to the
same effect: I can manipulate the demo options through xscreensaver-demo
in any cases.

  I suspect the message is due to the fact that xscreensaver(-demo?)
stores the login and the machine name under the form login@machine
but fails to correctly parse such string when login contains a '@'
character, as this is the case here.

  Regards,
Vincent

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

Kernel: Linux 5.4.0-0.bpo.2-amd64 (SMP w/8 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)

Versions of packages xscreensaver depends on:
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglade2-0  1:2.6.4-2+b1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk2.0-0  2.24.32-3
ii  libice6  2:1.0.9-2
ii  libpam0g 1.3.1-5
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpangoft2-1.0-01.42.4-7~deb10u1
ii  libsm6   2:1.2.3-1
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  libxi6   2:1.7.9-1
ii  libxinerama1 2:1.1.4-2
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxmu6  2:1.1.2-2+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxt6   1:1.1.5-1+b3
ii  libxxf86vm1  1:1.1.4-1+b2
ii  xscreensaver-data5.42+dfsg1-1

Versions of packages xscreensaver recommends:
ii  libjpeg-turbo-progs   1:1.5.2-2+b1
ii  perl  5.28.1-6
ii  wamerican [wordlist]  2018.04.16-1
ii  wfrench [wordlist]1.2.4-1

Versions of packages xscreensaver suggests:
ii  firefox-esr [www-browser]  68.4.1esr-1~deb10u1
pn  fortune
ii  gdm3   3.30.2-3
ii  konqueror [www-browser]4:18.12.0-1
ii  lynx [www-browser] 2.8.9rel.1-3
pn  qcam | streamer
ii  w3m [www-browser]  0.5.3-37
pn  xdaliclock 
pn  xfishtank  
pn  xscreensaver-data-extra
pn  xscreensaver-gl
pn  xscreensaver-gl-extra  

-- no debconf information

Bug#956041: libmaxminddb: FTBFS (BD-Uninstallable): Build-Depends-Arch on pandoc

2020-04-08 Thread Faidon Liambotis

severity 956041 wishlist
thanks

On Tue, Apr 07, 2020 at 05:06:02PM +0200, Thorsten Glaser wrote:
> On Mon, 6 Apr 2020, Thorsten Glaser wrote:
> 
> > Please do ensure to only ever Build-Depends-Indep on pandoc
> > and that the build really only needs it for the arch:all build.
> 
> Erk. The manpages are built like that upstream, so splitting
> them into a separate package is required, which… is irksome.

Indeed, creating a separate package for two manpages is indeed a not a
great investment of time and resources -- not to mention a policy
violation¹ :)

> However:
> 
> > This is now very critical, because bind9 recently gained a B-D
> > on libmaxminddb ☹
> 
> I’ve got another idea. Would you be willing to accept a
> Debian-specific (but upstreamable) patch to generate the
> manpages with a shell script I’d write? This looks to be
> doable easy enough, given it’s just the two files in doc/
> and that the -mdoc macropackage supports the semantic
> markup used already.

I'd prefer to not have to carry a Debian-specific patch that changes the
build system for upstream's documentation. Implementing a simple
Markdown parser for the few elements the docs have right now (sections
and URLs mostly) in shell seems within reach, but it would be
error-prone with regards to any future modifications of those documents.
Breakages would likely slip through and I wouldn't even notice until a
bug report came in.

That said, if the patch is upstreamable, I'd encourage you to submit it
directly to upstream². Assuming it gets merged in some way or form, I
wouldn't mind backporting it before upstream tagged a release.

Thanks,
Faidon

1: §12.1 "Each program, utility, and function should have an associated
manual page included in the **same** package" (emphasis mine)
2: https://github.com/maxmind/libmaxminddb

Bug#956249: No command to show all the aliases of a unit

2020-04-08 Thread 積丹尼 Dan Jacobson

X-Debbugs-Cc: adri...@gnu.org
Package: units
Version: 2.19-1
Severity: wishlist

$ units --verbose are
Definition: 100 m^2 = 100 m^2
should mention all the aliases of it, too, e.g., "a".

$ units --verbose foot
Definition: 12 inch = 0.3048 m
$ units --verbose ft
Definition: foot = 12 inch = 0.3048 m

So we see there is no command to show all the aliases.
We can see ft is short for foot,
but we cannot see what, if any, foot is "long" for.

P.S., so --verbose (which currently does nothing above of course) should
be given this new power, (and mention it on the man page.)

P.S.S.,

$ HOME=/ units --version
GNU Units version 2.19
with readline, with utf8, locale zh_TW
Units data file is '/usr/share/units/definitions.units'
Personal units data file is '//.units'
  (file does not exist)  ^^
 ^^
One slash is enough! ^^

Bug#956248: libzt FTCBFS: uses the build architecture compiler

2020-04-08 Thread Helmut Grohne

Source: libzt
Version: 0.2-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libzt fails to cross build from source, because it uses the build
architecture compiler. dh_auto_configure calls configure with the usual
--host flag, but the configure script ignores that flag. Consequently,
dh_auto_build does not pass cross tools to make (as it assumes that
configure will have set up the correct compiler). By forcing the
makefile buildsystem for dh_auto_build, we can make it pass cross tools
anyway. Please consider applying the attached patch.

Helmut
diff --minimal -Nru libzt-0.2/debian/changelog libzt-0.2/debian/changelog
--- libzt-0.2/debian/changelog  2020-04-01 11:08:17.0 +0200
+++ libzt-0.2/debian/changelog  2020-04-08 16:14:23.0 +0200
@@ -1,3 +1,10 @@
+libzt (0.2-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use the makefile buildsystem to pass cross tools. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 08 Apr 2020 16:14:23 +0200
+
 libzt (0.2-3) unstable; urgency=medium
 
   * Cherry pick build system from master to unblock Hurd and kFreeBSD builds.
diff --minimal -Nru libzt-0.2/debian/rules libzt-0.2/debian/rules
--- libzt-0.2/debian/rules  2020-03-28 22:26:16.0 +0100
+++ libzt-0.2/debian/rules  2020-04-08 16:14:22.0 +0200
@@ -2,3 +2,6 @@
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 %:
dh $@
+
+override_dh_auto_build:
+   dh_auto_build --buildsystem=makefile

Bug#956247: RFS: traceshark/0.9.9~beta-1 [ITP] -- Graphical viewer for the Ftrace and Perf events

2020-04-08 Thread Sudip Mukherjee

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: kilob...@angband.pl

Dear mentors,

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

 * Package name: traceshark
   Version : 0.9.9~beta-1
   Upstream Author : Viktor Rosendahl 
 * URL : https://awesomeopensource.com/project/cunctator/traceshark
 * License : GPL-2+ or BSD-2-clause
 * Vcs : https://github.com/sudipm-mukherjee/traceshark.git
   Section : devel

It builds those binary packages:

  traceshark - Graphical viewer for the Ftrace and Perf events

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/traceshark/traceshark_0.9.9~beta-1.dsc

Changes since the last upload:

   * Initial release (Closes: #949827)

This is a re-upload to NEW. Last upload was done via #952405, but
ftp-masters pointed out about the missing BSD license which has been
added now.

-- 
Regards
Sudip

Bug#956246: ITP: r-bioc-tcgabiolinks -- GNU R/Bioconductor package for integrative analysis with GDC data

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-tcgabiolinks -- GNU R/Bioconductor package for integrative 
analysis with GDC data
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-tcgabiolinks
  Version : 2.14.1
  Upstream Author : Antonio Colaprico,
* URL : https://bioconductor.org/packages/TCGAbiolinks/
* License : GPL-3+
  Programming Lang: GNU R
  Description : GNU R/Bioconductor package for integrative analysis with 
GDC data
 The aim of TCGAbiolinks is:
  1) facilitate the GDC open-access data retrieval,
  2) prepare the data using the appropriate pre-processing strategies,
  3) provide the means to carry out different standard analyses and
  4) to easily reproduce earlier research results.
 In more detail, the package provides multiple methods for analysis (e.g.,
 differential expression analysis, identifying differentially methylated
 regions) and methods for visualization (e.g., survival plots, volcano plots,
 starburst plots) in order to easily develop complete analysis pipelines.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-tcgabiolinks

Bug#956232: sumaclust: Last sequence of input is skipped on arm64

2020-04-08 Thread Pierre Gruet

Hi Andreas,

Le 08/04/2020 à 21:35, Andreas Tille a écrit :
> 
> Thanks again for your contribution.  Would you mind commiting your patch
> right to salsa to enable me sponsoring your second package version?
> 

Done, I have committed version 1.0.35-3. Now autopkgtests pass on amd64 and
arm64!

> Kind regards
> 
>  Andreas.
> 

Thanks again for your help,
Pierre

Bug#956238: [Pkg-javascript-devel] Bug#956238: npm: autopkgtest failures in arm64 and ppc64el

2020-04-08 Thread Xavier

Control: severity -1 important

Le 08/04/2020 à 20:18, Gianfranco Costamagna a écrit :
> Source: npm
> Version: 6.13.4+ds-2
> Severity: serious
> 
> Hello, looks like probably since version 6.x, a new autopkgtest introduced 
> has been failing on arm64, ppc64el and s390x (this one happens in Ubuntu, but 
> should be reproducible in Debian too).
> 
> https://ci.debian.net/packages/n/npm/unstable/arm64/
> https://ci.debian.net/packages/n/npm/unstable/ppc64el/
> 
> Can you please have a look?
> 
> thanks
> 
> Gianfranco

Hi,

the problem is "address already in use :::56443". It's difficult to
enable network tests without reserved port on debci machines.

So it's not a really a bug

Bug#956160: strip-nondeterminism: Support zip-based OpenJDK symbol file (ct.sym)

2020-04-08 Thread Chris Lamb

forwarded 956160 
https://salsa.debian.org/reproducible-builds/strip-nondeterminism/-/issues/15
thanks

I've forwarded this upstream here:

  https://salsa.debian.org/reproducible-builds/strip-nondeterminism/-/issues/15


Regards,

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

Bug#956245: /etc/kernel/header_postinst.d/dkms: Error! You must be root to use this command.

2020-04-08 Thread Thorsten Glaser

tags 956245 + patch
thanks

On Wed, 8 Apr 2020, Thorsten Glaser wrote:

> /etc/kernel/header_postinst.d/dkms:
> Error! You must be root to use this command.

This is caused by line 3178 of /usr/sbin/dkms:
((UID == 0)) && return

I am root, but $UID is 1000. Changing the line to…
[[ $(id -u) = 0 ]] && return
… makes it succeed.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#956245: /etc/kernel/header_postinst.d/dkms: Error! You must be root to use this command.

2020-04-08 Thread Thorsten Glaser

Package: dkms
Version: 2.6.1-4
Severity: grave
Justification: renders package unusable

After installing a package that needs DKMS, I also wanted to install
the kernel headers, to make it usable. I get:

[…]

Unpacking linux-headers-4.19.0-8-amd64 (4.19.98-1) ...
Selecting previously unselected package linux-headers-amd64.
Preparing to unpack .../linux-headers-amd64_4.19+105+deb10u3_amd64.deb ...
Unpacking linux-headers-amd64 (4.19+105+deb10u3) ...
Setting up linux-compiler-gcc-8-x86 (4.19.98-1) ...
Setting up linux-kbuild-4.19 (4.19.98-1) ...
Setting up linux-headers-4.19.0-8-common (4.19.98-1) ...
Setting up linux-headers-4.19.0-8-amd64 (4.19.98-1) ...
/etc/kernel/header_postinst.d/dkms:
Error! You must be root to use this command.
run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 1
Failed to process /etc/kernel/header_postinst.d at 
/var/lib/dpkg/info/linux-headers-4.19.0-8-amd64.postinst line 11.
dpkg: error processing package linux-headers-4.19.0-8-amd64 (--configure):
 installed linux-headers-4.19.0-8-amd64 package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-headers-amd64:
 linux-headers-amd64 depends on linux-headers-4.19.0-8-amd64; however:
  Package linux-headers-4.19.0-8-amd64 is not configured yet.

dpkg: error processing package linux-headers-amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-headers-4.19.0-8-amd64
 linux-headers-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages dkms depends on:
ii  build-essential  12.6
ii  coreutils8.30-3
ii  dpkg-dev 1.19.7
ii  gcc  4:8.3.0-1
ii  kmod 26-1
ii  make 4.2.1-1.2
ii  patch2.7.6-3+deb10u1

Versions of packages dkms recommends:
ii  fakeroot 1.23-1
iu  linux-headers-amd64  4.19+105+deb10u3
ii  lsb-release  10.2019051400
ii  sudo 1.8.27-1+deb10u2

Versions of packages dkms suggests:
ii  menu2.1.47+b1
pn  python3-apport  

-- no debconf information

Bug#956216: buster-pu: package systemd/241-7~deb10u3

2020-04-08 Thread Salvatore Bonaccorso

Hi Michael,

[Giving my opinion only, final word is obviously to the release team]

On Wed, Apr 08, 2020 at 04:11:31PM +0200, Michael Biebl wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Hi,
> 
> I'd like to make a stable/buster upload for systemd fixing CVE-2020-1712
> https://security-tracker.debian.org/tracker/CVE-2020-1712
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950732
> 
> After talking to the security team (namely Salvatore), we decided to fix
> this issue via a stable upload.
> 
> The debdiff is a bit on the larger side, unfortunately.
> Salvatore made a smaller backport avoiding some of the refactorings
> that were done upstream
> https://salsa.debian.org/systemd-team/systemd/-/merge_requests/69
> 
> I decided to go with the backport provided by upstream that was done for
> the v241-stable branch mainly for two reasons:
> - It makes potential future cherry-picks easier
> - Doing our own backport has the potential to introduce Debian specific
>   bugs
> 
> That said, if you prefer the more minimal backport from Salvatore,
> please let me know and I'll redo the upload accordingly.

While I did the work, I would as well strongly prefer to go rather the
upstream route and be on safe side. I tried to diligently backport it
but as upstream did provide their own approach to v241 branch I think
this would be better by means of the two raised reasons from Michael
above.

Thank you Michael for working towards a fix for the issue for buster.

Regards,
Salvatore

Bug#956232: sumaclust: Last sequence of input is skipped on arm64

Hi Pierre,

On Wed, Apr 08, 2020 at 07:21:54PM +0200, Pierre Gruet wrote:
> Package: sumaclust
> Version: 1.0.35-2
> Severity: normal
> Tags: patch upstream

Thanks again for your contribution.  Would you mind commiting your patch
right to salsa to enable me sponsoring your second package version?

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#956244: RFS: nis/3.17.1-4 [QA][RC] -- clients and daemons for the Network Information Service (NIS)

2020-04-08 Thread Sudip Mukherjee

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: nis
   Version : 3.17.1-4
   Upstream Author : 
 * URL : http://www.linux-nis.org/
 * License : GPL-2
 * Vcs : None
   Section : net

It builds those binary packages:

  nis - clients and daemons for the Network Information Service (NIS)

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/n/nis/nis_3.17.1-4.dsc

Changes since the last upload:

   * QA upload.
   * Mark source format as quilt.
   * Import diff in quilt format.
   * Fix FTBFS. (Closes: #954525)
   * Update Standards-Version to 4.5.0
   * Add dependency on debhelper-compat.
 - Update compat level to 12.

Note: There are few lintian warnings which I guess can be fixed after
the RC bug is fixed.

-- 
Regards
Sudip

Bug#956205: gitlab: Problem installing 12.8.8-6

2020-04-08 Thread Pirate Praveen

Control: forwarded -1 
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/29187

On 2020, ഏപ്രിൽ 8 8:08:34 PM IST, Pirate Praveen  
wrote:
>Control: merge 953415 -1
>
>On 2020, ഏപ്രിൽ 8 3:59:36 PM IST, David L 
>wrote:
>>rake aborted!
>>SassC::SyntaxError: Error: Top-level selectors may not contain the
>>parent selector "&".
>>on line 6:9 of
>node_modules/@gitlab/ui/src/scss/components.scss
>
>It is already known and work around documented in
>https://wiki.debian.org/gitlab (it is a good idea to check that page
>for known issues). Upstream sassc gem is still using an older version
>of libsass and sassc is failing to build on CentOS 6, so it is
>currently not easy to reproduce for gitlab upstream.

I have opened MR upstream to reproduce the issue 
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/29187 if they provide a 
patch, we can include it. For now, downgrade libsass.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#956207: opendmarc remain in foreground, ie fails to daemonize

2020-04-08 Thread David Bürgin

Daemonization is controlled with the ‘-f’ command-line option or the
‘Background’ parameter in the configuration file. Nothing has changed in
this area since the last version, so not sure what the problem is.

Bug#956242: RFS: kdocker/5.3-1 -- lets you dock any application into the system tray

2020-04-08 Thread Håvard Flaget Aasen

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: kdocker
   Version : 5.3-1
   Upstream Author : Girish Ramakrishnan 
 * URL : https://github.com/user-none/KDocker
 * License : GPL-2
 * Vcs : None
   Section : x11

It builds those binary packages:

  kdocker - lets you dock any application into the system tray

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/k/kdocker/kdocker_5.3-1.dsc

Changes since the last upload:

   * QA upload.
   * New upstream release closes: #934846, lp: #1797829
 - Upstream also changed AppStream icon lp: #1558713
   * d/control
 - Change to debhelper-compat
 - Bump debhelper to 12
 - Update Standards-Version to 4.5.0
 - Set maintainer to Debian QA Group
 - Add Rules-Requires-Root: no
   * d/copyright
 - Use secure URI
 - Change source to GitHub
 - Add CC0-1.0 for AppStream-metadata-license
   * Update manpage lp: #590577
   * d/rules add hardening flags

Regards,
Håvard

Bug#956243: ITP: r-cran-survminer -- GNU R drawing survival curves using 'ggplot2'

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-survminer -- GNU R drawing survival curves using 'ggplot2'
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-survminer
  Version : 0.4.6
  Upstream Author : Alboukadel Kassambara,
* URL : https://cran.r-project.org/package=survminer
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R drawing survival curves using 'ggplot2'
 Contains the function 'ggsurvplot()' for drawing easily beautiful and
 'ready-to-publish' survival curves with the 'number at risk' table and
 'censoring count plot'. Other functions are also available to plot
 adjusted curves for `Cox` model and to visually examine 'Cox' model
 assumptions.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-survminer

Bug#956241: wireguard-dkms: dkms should not attempt to build wireguard-dkms for (Debian) Linux >= 5.5.0-1

2020-04-08 Thread Nicolas Schier

Package: wireguard-dkms
Version: 1.0.20200330-1
Severity: normal

Dear Maintainer,

after installing the current Debian Linux 5.5.0-1 package,
wireguard-dkms fails to build.  Further, the Linux package has wireguard
already included as a module.

For me it helped to update the 'BUILD_EXCLUSIVE_KERNEL' dkms directive
to no more include version 5.5 (thus, only 3.10 up to 5.4).

Kind regards,
Nicolas


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

Kernel: Linux 5.5.0-1-arm64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to nb_NO.UTF-8), LANGUAGE=nb:nn:se:dk:de:C (charmap=UTF-8) (ignored: LC_ALL 
set to nb_NO.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wireguard-dkms depends on:
ii  dkms  2.8.1-5
ii  perl  5.30.0-9

Versions of packages wireguard-dkms recommends:
ii  wireguard1.0.20200319-1
ii  wireguard-tools  1.0.20200319-1

wireguard-dkms suggests no packages.

-- no debconf information

-- 
epost: nico...@fjasle.eu   irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb  c82b 7d97 0932 55a0 ce7f
 -- frykten for herren er opphav til kunnskap --
DKMS make.log for wireguard-1.0.20200330 for kernel 5.5.0-1-arm64 (aarch64)
on. 08. april 20:41:15 +0200 2020
make: Verzeichnis „/usr/src/linux-headers-5.5.0-1-arm64“ wird betreten
  AR  /var/lib/dkms/wireguard/1.0.20200330/build/built-in.a
  CC [M]  /var/lib/dkms/wireguard/1.0.20200330/build/main.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200330/build/noise.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200330/build/device.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200330/build/peer.o
In file included from :
/var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:959:20: error: 
static declaration of ‘icmp_ndo_send’ follows non-static declaration
  959 | static inline void icmp_ndo_send(struct sk_buff *skb_in, int type, int 
code, __be32 info)
  |^
In file included from :
/var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:959:20: error: 
static declaration of ‘icmp_ndo_send’ follows non-static declaration
  959 | static inline void icmp_ndo_send(struct sk_buff *skb_in, int type, int 
code, __be32 info)
  |^
In file included from :
/var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:959:20: error: 
static declaration of ‘icmp_ndo_send’ follows non-static declaration
  959 | static inline void icmp_ndo_send(struct sk_buff *skb_in, int type, int 
code, __be32 info)
  |^
In file included from 
/var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:954,
 from :
/usr/src/linux-headers-5.5.0-1-common/include/net/icmp.h:47:6: note: previous 
declaration of ‘icmp_ndo_send’ was here
   47 | void icmp_ndo_send(struct sk_buff *skb_in, int type, int code, __be32 
info);
  |  ^
In file included from 
/var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:954,
 from :
/usr/src/linux-headers-5.5.0-1-common/include/net/icmp.h:47:6: note: previous 
declaration of ‘icmp_ndo_send’ was here
   47 | void icmp_ndo_send(struct sk_buff *skb_in, int type, int code, __be32 
info);
  |  ^
In file included from 
/var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:954,
 from :
/usr/src/linux-headers-5.5.0-1-common/include/net/icmp.h:47:6: note: previous 
declaration of ‘icmp_ndo_send’ was here
   47 | void icmp_ndo_send(struct sk_buff *skb_in, int type, int code, __be32 
info);
  |  ^
In file included from :
/var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:988:20: error: 
static declaration of ‘icmpv6_ndo_send’ follows non-static declaration
  988 | static inline void icmpv6_ndo_send(struct sk_buff *skb_in, u8 type, u8 
code, __u32 info)
  |^~~
In file included from :
/var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:988:20: error: 
static declaration of ‘icmpv6_ndo_send’ follows non-static declaration
  988 | static inline void icmpv6_ndo_send(struct sk_buff *skb_in, u8 type, u8 
code, __u32 info)
  |^~~
In file included from :
/var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:988:20: error: 
static declaration of ‘icmpv6_ndo_send’ follows non-static declaration
  988 | static inline void icmpv6_ndo_send(struct sk_buff *skb_in, u8 type, u8 
code, __u32 info)
  |^~~
In file included from 
/var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:952,
 from :
/usr/src/linux-headers-5.5.0-1-common/include/linux/icmpv6.h:26:6: note:

Bug#956240: [kgpg] Does not run on wayland

2020-04-08 Thread erentar2002

Subject: Does not run on wayland
Package: kgpg
Version: 4:19.08.3-1
Severity: important



get the following:

   Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use 
QT_QPA_PLATFORM=wayland to run on Wayland anyway.
   QSocketNotifier: Can only be used with threads started with QThread

while other QT apps are fine.

Problem appeared after:
* installing app
* rebooting to Gnome X
* rebooting to Gnome Wayland
and it does not work at all, even when the suggested variables are set.



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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Init: systemd (via /run/systemd/system)

Versions of packages kgpg depends on:
ii  gnupg2.2.20-1
ii  kio  5.62.1-2+b1
ii  libc62.30-4
ii  libgcc-s1 [libgcc1]  10-20200402-1
ii  libgcc1  1:10-20200402-
1
ii  libkf5akonadicontact5 [libkf5akonadicontact5-19.08]  4:19.08.3-1
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-19.08]4:19.08.3-1
ii  libkf5archive5   5.62.0-1
ii  libkf5codecs55.62.0-1
ii  libkf5configcore55.62.0-1+b1
ii  libkf5configgui5 5.62.0-1+b1
ii  libkf5configwidgets5 5.62.0-1+b1
ii  libkf5contacts5 [libkf5contacts5-19.08]  4:19.08.3-1
ii  libkf5coreaddons55.62.0-1
ii  libkf5crash5 5.62.0-1+b1
ii  libkf5dbusaddons55.62.0-1
ii  libkf5i18n5  5.62.0-1
ii  libkf5iconthemes55.62.0-1+b1
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  libkf5notifications5 5.62.0-1+b1
ii  libkf5service-bin5.62.0-1
ii  libkf5service5   5.62.0-1
ii  libkf5textwidgets5   5.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-9
ii  libqt5dbus5  5.12.5+dfsg-9
ii  libqt5gui5   5.12.5+dfsg-9
ii  libqt5network5   5.12.5+dfsg-9
ii  libqt5printsupport5  5.12.5+dfsg-9
ii  libqt5widgets5   5.12.5+dfsg-9
ii  libstdc++6   10-20200402-1

kgpg recommends no packages.

kgpg suggests no packages.


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

Bug#956239: libwxgtk3.0-dev: Package is not installable due to dependency problems

2020-04-08 Thread Huub Reuver

Package: libwxgtk3.0-dev
Version: 3.0.4+dfsg-14
Severity: important


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

Kernel: Linux 5.4.24 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_RANDSTRUCT
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: sysvinit (via /sbin/init)

Versions of packages libwxgtk3.0-dev depends on:
pn  libgl1-mesa-dev | libgl-dev
pn  libwxbase3.0-dev   
pn  libwxgtk3.0-0v5
pn  wx-common  
pn  wx3.0-headers  
pn  xlibmesa-glu-dev | libglu-dev  

libwxgtk3.0-dev recommends no packages.

Versions of packages libwxgtk3.0-dev suggests:
pn  gettext
pn  wx3.0-doc  

# apt-get install libwxgtk3.0-dev
Reading package lists... Done
Building dependency tree   
Reading state information... Done
libwxgtk3.0-dev is already the newest version (3.0.4+dfsg-14).
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 libwxgtk3.0-dev : Depends: wx3.0-headers (= 3.0.4+dfsg-14) but 3.0.4+dfsg-15 
is to be installed
   Depends: libwxbase3.0-dev (= 3.0.4+dfsg-14) but 
3.0.4+dfsg-15 is to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or 
specify a solution).

Bug#956112: RFS: eggdrop/1.8.4-3 -- Advanced IRC Robot

2020-04-08 Thread Adam Borowski

On Tue, Apr 07, 2020 at 01:08:58PM +, Cédric Barboiron wrote:
> * Package name : eggdrop
> Version : 1.8.4-3
> Changes since the last upload:
> 
> * New upstream version 1.8.4
> * patches
> - remove 03openssl_checks (fixed upstream)
> - refresh patches
> * fix some lintian warnings
> - use debhelper 12
> - enable hardening flags (+all)
> - remove autotools-dev and dh-autoreconf dependencies
> - update to standards version 4.3.0
> - add override for compress.so hardening
> * debian/watch
> - use https
> - ignore rc releases in debian/watch
> * rename NEWS and UPGRADING files
> * add Vcs-Git and Vcs-Browser to control
> * use dh_autoreconf

Hi!
The package is marked as UNRELEASED, and uploading that would cause an
autoreject.

The changelog entry from 11 Aug 2014 is overwritten with a bunch of
UNRELEASED entries.  This shows some confusion.  Past changelog entries are
supposed to be immutable other than for corrections.

dh-missing complains about a lot of files installed into staging dirs but
not put anywhere into actual packages.

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

Bug#956237: RFS: logrotate/3.16.0-3 -- Log rotation utility

2020-04-08 Thread Christian Göttsche

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: logrotate
   Version : 3.16.0-3
   Upstream Author : https://github.com/logrotate/logrotate/issues
 * URL : https://github.com/logrotate/logrotate
 * License : GPL-2
 * Vcs : https://salsa.debian.org/debian/logrotate
   Section : admin

It builds those binary packages:

  logrotate - Log rotation utility

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/l/logrotate/logrotate_3.16.0-3.dsc

Changes since the last upload:

   * d/patches: cherry-pick upstream switch-user fixes
 - When using configuration directive su, accept staying as user root.
   In particular restore mailman's usage of 'su root list'.
 - Reset user/group when error returning early in rotateLogSet().

Best regards,
Christian Göttsche

p.s.:
the Lintian tag package-does-not-install-examples examples/ is a fp, see #954141
Lintian might not recognize my name from the Changelog to be the
Maintainer, see #956151

Bug#955858: gparted: does not start, 'unable to init server', tmp.mount does not exist

2020-04-08 Thread Phillip Susi



Kyle B writes:

> (gpartedbin:11049): Gtk-WARNING **: 09:04:39.901: cannot open display:

What display server / desktop environment are you using?

Bug#956216: buster-pu: package systemd/241-7~deb10u4

2020-04-08 Thread Michael Biebl

Control: retitle -1  buster-pu: package systemd/241-7~deb10u4

Sorry, messed up the version in the Subject

Bug#956238: npm: autopkgtest failures in arm64 and ppc64el

2020-04-08 Thread Gianfranco Costamagna

Source: npm
Version: 6.13.4+ds-2
Severity: serious

Hello, looks like probably since version 6.x, a new autopkgtest introduced has 
been failing on arm64, ppc64el and s390x (this one happens in Ubuntu, but 
should be reproducible in Debian too).

https://ci.debian.net/packages/n/npm/unstable/arm64/
https://ci.debian.net/packages/n/npm/unstable/ppc64el/

Can you please have a look?

thanks

Gianfranco

Bug#956233: lintian: Internal error opening files since 2.63.0

2020-04-08 Thread Felix Lechner

Control: retitle -1 lintian: UTF-8 filenames cause internal errors

Hi Dmitry,

On Wed, Apr 8, 2020 at 10:30 AM Dmitry Shachnev  wrote:
>
>   Can't open 
> '/tmp/lintian-pool-z2LddsoVG9/pool/s/sphinx/sphinx_2.4.3-2+salsaci_source/unpacked/tests/roots/test-images/testimÃ¤ge.png'
>  with mode '<:raw': 'No such file or directory' at 
> /usr/share/lintian/checks/cruft.pm line 992

This error is about UTF-8 filenames. We have a solution in Lintian,
but it does not work reliably due to a Perl bug.

In my opinion, the bug is serious enough to patch all versions of Perl
shipped in Debian, as explained below. In lieu of what would have been
an upcoming email to debian-perl, they are hereby copied.

In a nutshell, file tests such as '-f' do not work reliably with
strings that were internally "upgraded" by Perl (i.e. utf8::upgrade).
More details about this dangerous bug are available here [1] and [2].
Other system calls such as 'stat' and 'open' are likewise affected.
This bug shows the problem with 'open'.

It is amazing that the bug has been open for so long. It is literally
the well-known "Unicode bug", but for file names. Apparently there is
no common solution for all Perl platforms. (The use of UTF-8 filenames
also appears to be uncommon outside Linux, or is implemented
differently, i.e. MacOS.)

In my view, many Perl scripts in Debian, including those for
installation and security purposes, depend on file tests working
reliably. Perhaps our Perl interpreters should be patched with a
Debian-specific fix.

Related questions about file name mangling or matching in modules,
such as Path::Tiny and File::Find::Rule, may have to be explored or
mitigated before this bug can be considered completely closed.

The credit for identifying the bug in Lintian (and saving my sanity)
goes to Grinnz on #debian-perl.

Kind regards,
Felix Lechner

[1] https://github.com/Perl/perl5/issues/10550
[2] https://github.com/Perl/perl5/issues/9674

Bug#956236: SyntaxWarnings with updated python3-imexam

2020-04-08 Thread shirish शिरीष

Package: python3-imexam
Version: 0.8.1-2+b1
Severity: normal


Dear Maintainer,
Got a few SyntaxWarnings while updating python3-imexam. Please fix
them whenever possible -

Setting up python3-gammapy (0.16-1+b1) ...
/usr/lib/python3/dist-packages/gammapy/cube/fov.py:52: SyntaxWarning:
"is" with a literal. Did you mean "=="?
  if self.method is "fit":
Setting up python3-imexam (0.8.1-2+b1) ...
/usr/lib/python3/dist-packages/imexam/imexamine.py:715: SyntaxWarning:
"is not" with a literal. Did you mean "!="?
  if fitform.name is not "Polynomial1D":
/usr/lib/python3/dist-packages/imexam/imexamine.py:743: SyntaxWarning:
"is" with a literal. Did you mean "=="?
  if fitform.name is "Gaussian1D":
/usr/lib/python3/dist-packages/imexam/imexamine.py:747: SyntaxWarning:
"is" with a literal. Did you mean "=="?
  elif fitform.name is "Moffat1D":
/usr/lib/python3/dist-packages/imexam/imexamine.py:750: SyntaxWarning:
"is" with a literal. Did you mean "=="?
  elif fitform.name is "MexicanHat1D":
/usr/lib/python3/dist-packages/imexam/imexamine.py:753: SyntaxWarning:
"is" with a literal. Did you mean "=="?
  elif fitform.name is "Polynomial1D":
/usr/lib/python3/dist-packages/imexam/imexamine.py:757: SyntaxWarning:
"is" with a literal. Did you mean "=="?
  elif fitform.name is "AiryDisk2D":
/usr/lib/python3/dist-packages/imexam/imexamine.py:767: SyntaxWarning:
"is" with a literal. Did you mean "=="?
  if fitform.name is "AiryDisk2D":
/usr/lib/python3/dist-packages/imexam/imexamine.py:798: SyntaxWarning:
"is" with a literal. Did you mean "=="?
  if fitform.name is "Gaussian1D":
/usr/lib/python3/dist-packages/imexam/imexamine.py:808: SyntaxWarning:
"is" with a literal. Did you mean "=="?
  elif fitform.name is "Moffat1D":
/usr/lib/python3/dist-packages/imexam/imexamine.py:816: SyntaxWarning:
"is" with a literal. Did you mean "=="?
  elif fitform.name is "MexicanHat1D":
/usr/lib/python3/dist-packages/imexam/imexamine.py:822: SyntaxWarning:
"is" with a literal. Did you mean "=="?
  elif fitform.name is "Polynomial1D":
/usr/lib/python3/dist-packages/imexam/imexamine.py:827: SyntaxWarning:
"is" with a literal. Did you mean "=="?
  elif fitform.name is "AiryDisk2D":
/usr/lib/python3/dist-packages/imexam/imexamine.py:1087:
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if fitform.name is "Gaussian1D":
/usr/lib/python3/dist-packages/imexam/imexamine.py:1103:
SyntaxWarning: "is" with a literal. Did you mean "=="?
  elif fitform.name is "Moffat1D":
/usr/lib/python3/dist-packages/imexam/imexamine.py:1118:
SyntaxWarning: "is" with a literal. Did you mean "=="?
  elif fitform.name is "MexicanHat1D":

  Please fix the above if possible.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-debug'), (100,
'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50,
'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages python3-imexam depends on:
ii  libc6   2.30-4
ii  libxpa1 2.1.19-1
ii  python3 3.8.2-2
ii  python3-astropy 4.0-4
ii  python3-matplotlib  3.1.2-2

Versions of packages python3-imexam recommends:
ii  ipython3   7.13.0-1
ii  python3-ginga  3.0.0-1
ii  python3-scipy  1.3.3-3
ii  saods9 8.1+repack-1
ii  xpa-tools  2.1.19-1

Versions of packages python3-imexam suggests:
pn  python-imexam-doc  

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

partially answering my own question here, the binary_grub-efi script
rejects use for netboot images (as well as hdd coincidentally), so no
need to be concerned with compatibility there.

On Wed, 2020-04-08 at 16:05 +0100, jnq...@gmail.com wrote:
> Oh, quick addition of something I forgot to put in the below message:
> 
> So in the discussion of #924053 it was suggested that the /.disc/info
> based solution would only work for ISO/ISO-hybrid images because this
> file was created by xorriso. I added a comment just now pointing out
> that in fact this file is created by the binary_disc script, which
> generates it for iso, iso-hybrid and hdd image types.
> 
> It does not create any such info for netboot and tar images types,
> though. I do not expect the tar image will be booted will it? and
> thus
> there's no concern there? I really do not know all that much about
> netboot, so I do not know whether or not there is a problem there.

Bug#956120: rspamd: please make paths.lua reproducible

2020-04-08 Thread Christian Göttsche

Hi,

Many thanks for the efforts of making Debian reproducible and also
many thanks for looking into rspamd.

This bug report and the attached patch are targeting the version
1.9.4-2, while as of recently there is a new version available: 2.5-1
.

Unfortunately this version does also not build reproducibly; could you
please take a look at it? (addresses are off by few bytes; adding
-frandom-seed=0 or -frandom-seed=1 does not resolve it)

Best regards,
  Christian Göttsche

Bug#956235: TypeError: can't multiply sequence by non-int of type 'float'

2020-04-08 Thread Richard Kettlewell


Package: graphite-api
Version: 1.1.3-2+deb9u1

With a target of:

movingAverage(alias(snmp.escalabra.snmp.if_octets-Slot__0_Port__2_Gigabit_-_Level.rx, 
'g2 rx'), '5min')


...I get an exception from graphite. It's the same one shown here: 
https://github.com/brutasse/graphite-api/issues/201


The cause seems to be that graphite-api has not been completely ported 
to Python 3.


A patch that fixes this particular issue is attached. I don't know if 
there are other lurking dependencies on Python 2.


ttfn/rjk
--- /usr/lib/python3/dist-packages/graphite_api/functions.py.orig	2020-04-08 18:38:00.827220689 +0100
+++ /usr/lib/python3/dist-packages/graphite_api/functions.py	2020-04-08 18:38:04.915021572 +0100
@@ -2106,7 +2106,7 @@
 for bootstrap, original in zip_longest(bootstrapList, seriesList):
 newValues = []
 if bootstrap.step != original.step:
-ratio = bootstrap.step / original.step
+ratio = bootstrap.step // original.step
 for value in bootstrap:
 # XXX For series with aggregationMethod = sum this should also
 # divide by the ratio to bring counts to the same time unit

Bug#956234: xserver-xorg-input-libinput - Touchpad unstable

2020-04-08 Thread limassalin191

Package: xserver-xorg-input-libinput
Version: 0.29.0-1
Touchpad type: ETPS/2 Elantech Touchpad
Device: Acer Aspire E1-572G (Aspire E1-572G_0776_V2.14)

I have this problem with Debian Bullseye, Ubuntu 19.10, Tails and many distro 
based on Debian.

When I use two finger scrolling it is causing a central click, this is very 
frustrating when you browse a web page because this defect causes other web 
pages to accidentally open when you encounter links.

Only with Debian Buster Stable can i use the touchpad correctly.

Updated versions of this driver seem to have problems.

Is there any way to fix this?.

Thanks in advance.

Bug#782654: Bug#838416: Bug#782654: Bug#838416: ITP: bazel -- Fast and correct automated build system by Google

2020-04-08 Thread Olek Wojnar

Hi Kyle, (or other interested/involved parties)

Bazel has suddenly become more important because it is preventing us from
getting packages working that would help with the COVID-19 pandemic. Due to
the significance, I am copying the Debian Med team as well as key people
from this bug's history in the hopes of getting something moving quickly.

On Tue, 22 May 2018 14:55:19 -0600 Kyle Moffett 
wrote:
> I spent a while working on it off and on, but there is a decent amount
> of tweaking and other packaging work needed to get policy-compliant
> bazel packages.  (E.G: There are quite a few binary JAR files shipped
> in the upstream tarball that don't necessarily match the versions in
> Debian).
>
> I just didn't have the spare time, especially now that I have a kid,
> to sink into one package.

I can relate to the kid/time issues! ;) Have you had any time to work on it
recently? Did you ever upload any of your work?

In the meantime, I see that Bazel has an unofficial Ubuntu build [1]. Do
you know anything about that? It seems like a good place for us to start if
you aren't close to a product yourself.

Oh, and to state this explicitly: I'm happy to work on this if it'll help
it get into Debian faster! I just don't want to step on anyone's toes if
someone has already made significant progress on this ITP.

-Olek

[1]
https://docs.bazel.build/versions/master/install-ubuntu.html#install-on-ubuntu

Bug#952055: paulstretch: FTBFS: XMLwrapper.cpp:32:26: error: invalid use of incomplete type ‘mxml_node_t’ {aka ‘struct _mxml_node_s’}

2020-04-08 Thread Sudip Mukherjee

Hi,

I have raised a merge request to fix this issue. This is an issue due to
change in mxml.

https://salsa.debian.org/multimedia-team/paulstretch/-/merge_requests/1

Note: I could not test it, I am getting segfaults even with 2.2-2-4.


--
Regards
Sudip

Bug#953952: kmod: libkmod2-udeb contains binary instead of libraries

2020-04-08 Thread Aurelien Jarno

On 2020-04-05 02:21, Marco d'Itri wrote:
> On Mar 15, Aurelien Jarno  wrote:
> 
> > The kmod binaries are actually the one being used, so yes please add a
> > kmod-udeb.
> Does it look good to you?
> 
> https://salsa.debian.org/md/kmod/-/commit/801ce705d39efdae9411192b1c33aee8ad522cc7
> 
> drwxr-xr-x root/root 0 2020-04-05 02:14 ./
> drwxr-xr-x root/root 0 2020-04-05 02:14 ./bin/
> -rwxr-xr-x root/root121656 2020-04-05 02:14 ./bin/kmod
> drwxr-xr-x root/root 0 2020-04-05 02:14 ./etc/
> drwxr-xr-x root/root 0 2020-04-05 02:14 ./etc/modprobe.d/
> -rw-r--r-- root/root   246 2020-04-05 02:14 ./etc/modprobe.d/aliases.conf
> drwxr-xr-x root/root 0 2020-04-05 02:14 ./sbin/
> lrwxrwxrwx root/root 0 2020-04-05 02:14 ./bin/lsmod -> kmod
> lrwxrwxrwx root/root 0 2020-04-05 02:14 ./sbin/depmod -> /bin/kmod
> lrwxrwxrwx root/root 0 2020-04-05 02:14 ./sbin/insmod -> /bin/kmod
> lrwxrwxrwx root/root 0 2020-04-05 02:14 ./sbin/lsmod -> /bin/kmod
> lrwxrwxrwx root/root 0 2020-04-05 02:14 ./sbin/modinfo -> /bin/kmod
> lrwxrwxrwx root/root 0 2020-04-05 02:14 ./sbin/modprobe -> /bin/kmod
> lrwxrwxrwx root/root 0 2020-04-05 02:14 ./sbin/rmmod -> /bin/kmod
> 
> drwxr-xr-x root/root 0 2020-04-05 02:14 ./
> drwxr-xr-x root/root 0 2020-04-05 02:14 ./usr/
> drwxr-xr-x root/root 0 2020-04-05 02:14 ./usr/lib/
> -rw-r--r-- root/root 76504 2020-04-05 02:14 ./usr/lib/libkmod.so.2.3.5
> lrwxrwxrwx root/root 0 2020-04-05 02:14 ./usr/lib/libkmod.so.2 -> 
> libkmod.so.2.3.5
> 
>  Package: kmod-udeb
>  Source: kmod
>  Version: 27-3
>  Architecture: amd64
>  Maintainer: Marco d'Itri 
>  Installed-Size: 133
>  Depends: libc6-udeb (>= 2.30)
>  Section: debian-installer
>  Priority: important
>  Description: libkmod shared library
>   This is a minimal version of kmod, only for use in the installation system.
> 
>  Package: libkmod2-udeb
>  Source: kmod
>  Version: 27-3
>  Architecture: amd64
>  Maintainer: Marco d'Itri 
>  Installed-Size: 80
>  Depends: libc6-udeb (>= 2.30)
>  Section: debian-installer
>  Priority: important
>  Description: libkmod shared library
>   This is a minimal version of libkmod2, only for use in the installation 
> system.
> 

Yep, that looks all good, thanks a lot.

Regards,
Aurelien

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


signature.asc
Description: PGP signature

Bug#956233: lintian: Internal error opening files since 2.63.0

2020-04-08 Thread Dmitry Shachnev

Package: lintian
Version: 2.64.0
Severity: important

Dear Maintainer,

Lintian recently started getting internal error when checking sphinx package:

The error is:

  Can't open 
'/tmp/lintian-pool-z2LddsoVG9/pool/s/sphinx/sphinx_2.4.3-2+salsaci_source/unpacked/tests/roots/test-images/testimÃ¤ge.png'
 with mode '<:raw': 'No such file or directory' at 
/usr/share/lintian/checks/cruft.pm line 992
  Lintian::cruft::open(GLOB(0x5563649da270), "<:raw", 
"/tmp/lintian-pool-z2LddsoVG9/pool/s/sphinx/sphinx_2.4.3-2+sal"...) called at 
/usr/share/lintian/checks/cruft.pm line 992
  Lintian::cruft::full_text_check(Lintian::cruft=HASH(0x556364a09fa0), 
Lintian::File::Path=HASH(0x5563605a7948), 
"tests/roots/test-images/testim\x{c3}\x{a4}ge.png", "testim\x{c3}\x{a4}ge.png", 
"tests/roots/test-images/") called at /usr/share/lintian/checks/cruft.pm line 
710
  ...
  internal error: cannot run cruft check on package 
source:sphinx/2.4.3-2+salsaci

Visible here:
https://salsa.debian.org/python-team/modules/sphinx/-/jobs/654529

Note that the file is named testimäge.png.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#956232: sumaclust: Last sequence of input is skipped on arm64

2020-04-08 Thread Pierre Gruet

Package: sumaclust
Version: 1.0.35-2
Severity: normal
Tags: patch upstream

Version 1.0.35-2 of sumaclust runs on arm64 but the last sequence of input 
files is always skipped.
This appears to be linked to the way sequences are read in libfasta/sequence.c. 
I have proposed a patch to upstream, which seems to solve the problem. I am 
waiting for its opinion on it.

Best,
Pierre
From: Pierre Gruet 
Date: Wed, 8 Apr 2020 11:18:01 +0200
Subject: Reading only-ACGT sequences safely

---
 sumalibs/libfasta/sequence.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/sumalibs/libfasta/sequence.c b/sumalibs/libfasta/sequence.c
index 2cf3d10..db999f8 100755
--- a/sumalibs/libfasta/sequence.c
+++ b/sumalibs/libfasta/sequence.c
@@ -162,19 +162,25 @@ void seq_fillSeqOnlyATGC(char *seq, fastaSeqPtr seqElem, 
int seqLen)
 {
char* seqTemp;
char c;
-   int32_t index = 0, seqIndex = 0, len = strlen(seq);
+   int32_t index = 1, seqIndex = 0, len = strlen(seq);
char* seqAlphabets = "acgtACGT";
int notAllATGC = 0;
+int goOnParsing = 1;
 
seqTemp = (char*) util_malloc(seqLen*sizeof(char), __FILE__, __LINE__);
 
-   while (index < len)
+   while (goOnParsing)
{
c = seq[index++];
if (strchr(seqAlphabets, c) != NULL)
seqTemp[seqIndex++] = tolower(c);
+else if (c == '\n')
+goOnParsing = 0; //End of line character terminating 
the sequence has been reached.
else if (c != '\n')
notAllATGC = 1;
+
+if (index == len)
+goOnParsing = 0;
}
 
if (notAllATGC)

Bug#956178: libjna-jni libjnidispatch.system.so has build directory in soname

2020-04-08 Thread tony mancill

On Tue, Apr 07, 2020 at 08:02:24PM -0700, Bart Massey wrote:
> Package: libjna-jni
> Version: 4.5.2-1+b1
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> Placed the following in /etc/ld.so.conf.d/java-jni.conf
> 
> /usr/lib/x86_64-linux-gnu/jni
> /usr/lib/jni
> 
> and ran ldconfig, which reported
> 
> ldconfig: Can't link 
> /usr/lib/x86_64-linux-gnu/jni//build/libjna-java-ayrlgf/libjna-java-4.5.2/build/native-linux-x86-64/libjnidispatch.system.so
>  to libjnidispatch.system.so
> 
> This didn't seem right, so after some tracking down
> discovered that the Makefile was borked.
> 
> Attached is a tested patch that resolves the problem by
> removing the build path from the library soname.

Hi Bart,

Thanks for the analysis and the patch!  I will apply the patch and get
this uploaded.

Cheers,
tony

Bug#956229: FTBFS: test failures

2020-04-08 Thread gregor herrmann

Source: libtickit-widget-floatbox-perl
Version: 0.05-1
Severity: serious
Tags: upstream ftbfs sid bullseye
Justification: fails to build from source

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The package started to fail its test after uploading one of the other
Tickit::* packages:

perl Build test --verbose 1
t/00use.t . 
ok 1 - use Tickit::Widget::FloatBox;
1..1
ok
Argument "Tickit::Rect[(0,0)..(80,25)]" isn't numeric in subroutine entry at 
/usr/lib/x86_64-linux-gnu/perl5/5.30/Tickit/Test.pm line 253.
Argument "Tickit::Rect[(0,0)..(100,30)]" isn't numeric in subroutine entry at 
/usr/lib/x86_64-linux-gnu/perl5/5.30/Tickit/Test.pm line 253.
t/01base-child.t .. 
ok 1 - defined $widget
ok 2 - scalar $widget->children
ok 3 - $widget->children[0]
ok 4 - $widget->children[0]->parent
ok 5 - $widget->lines with no bounds
ok 6 - $widget->cols with no bounds
ok 7 - child render rect
ok 8 - child render rect after term resize
1..8
ok
Too many arguments for subroutine 'Tickit::Widget::FloatBox::Float::BUILD' at 
/usr/lib/x86_64-linux-gnu/perl5/5.30/Object/Pad.pm line 378.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 1.
t/02float.t ... 
ok 1 - Display initially
Dubious, test returned 255 (wstat 65280, 0xff00)
All 1 subtests passed 
Too many arguments for subroutine 'Tickit::Widget::FloatBox::Float::BUILD' at 
/usr/lib/x86_64-linux-gnu/perl5/5.30/Object/Pad.pm line 378.
t/03hide-show.t ... 
Dubious, test returned 255 (wstat 65280, 0xff00)
No subtests run 
t/99pod.t . skipped: Test::Pod 1.00 required for testing POD

Test Summary Report
- ---
t/02float.t (Wstat: 65280 Tests: 1 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/03hide-show.t (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
Files=5, Tests=10,  1 wallclock secs ( 0.02 usr  0.02 sys +  0.49 cusr  0.04 
csys =  0.57 CPU)
Result: FAIL
Failed 2/5 test programs. 0/10 subtests failed.



Cf. also 
https://ci.debian.net/data/autopkgtest/unstable/amd64/libt/libtickit-widget-floatbox-perl/4827036/log.gz
or http://www.cpantesters.org/cpan/report/c560fee6-75c9-11ea-9a78-d3801f24ea8f


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl6OB1ZfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbLmg//VNUTviCtjmL7KoHLxkoCiOPCtdMFB2m8uwvSLwGCM4JFxtFej1BteesG
btzZnnF720TF6lgHxdG9MY86e8sf0Kf7azZibtRWcnLkeDkA4rRHpFrOuPuG6Pxj
nB+LVtZYjZoiOhkw4CgKW/9ltfMz/LdmVtQcFRwl3k892lpVj84Yp/TmqL8h5lY+
iZWsYLMZMUyLxel6noMwHDLfbe+lEUGs0xjkxE3zGKXy7Ux+iESPGRChwRYYdDgr
AbMQhyoxrk1iY+T6pnEtE+t+y49EC/pxPDgFwZLsVEU6XpgPUmtinib+ZEUjI6Z5
yIEDrG8SnFNqwhiulvsc17EASycdOwM5zVIPrLfXDp/k/TaLNjDzJsqU0WJfoTDP
hJjAQOfqwM8nLEpe/21L63kYBqaPTIXZjwU1Lk3WNPVOOrMY0pAstaPH195Aai6K
YtAvJ3dkxnC4zWK4MNyfzVtC2BjKdnsbuzbd0ONhKzQrgcibgIvxYldQY06AFuO2
qFol7wBgyK2i5unw2J/jO1FqpuvwssTnEw8lqvEXn5s1DnVxrRnhPAUT7F7Qva3l
1vmpZuCdJHCSYcOmn1dIEa1PhisTpOC1ColmFIAp5reYBPkR3RseJ9/5OwEtif9d
5bhmNkBmREYn4Nj/WrpxnFnJ28vPgUlvFaZvkX9jMfanUq6xhTM=
=Z6i2
-END PGP SIGNATURE-

Bug#956231: ITP: r-bioc-rots -- GNU R Teproducibility-Optimized Test Statistic

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-rots -- GNU R Teproducibility-Optimized Test Statistic
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-rots
  Version : 1.14.0
  Upstream Author : Fatemeh Seyednasrollah, Tomi Suomi, Laura L. Elo
* URL : https://bioconductor.org/packages/ROTS/
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R Teproducibility-Optimized Test Statistic
 This BioConductor package calculates the Reproducibility-Optimized
 Test Statistic (ROTS) for differential testing in omics
 data.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-rots

Bug#955267: gnome-calendar: Also appears on month view

2020-04-08 Thread Calum McConnell

Package: gnome-calendar
Version: 3.36.0-1
Followup-For: Bug #955267

I am experiancing the exact same issue on month view, with this calendar
imported:
http://calendar.google.com/calendar/ical/cheshire.k12.ct.us_5dpc4689dsv5p21e2ie9nvqknc%40group.calendar.google.com/public/basic.ics
In this calendar, every weekday has a day name: 'a' 'b' 'c' 'd', which is
represented by an all-day event.  The 'd' day events ONLY appear as a single
continuous all-day event accross the entire month, in addition to the normal
event.  Intrestingly, the date given for the continuous event in april is the
1st of may, which is a D day but is not displayed on the april month view.

Investigation of other calenders led me to the conclusion that all-day events
that occur on the first of the following month (eg, Feb. 1: First day of
Black History Month) are displayed throughout the previous month (Jan) as
all-day, every-day events. 

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

Kernel: Linux 5.4.0-4-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.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 gnome-calendar depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  gsettings-desktop-schemas3.36.0-1
ii  libc62.30-4
ii  libcairo21.16.0-4
ii  libdazzle-1.0-0  3.36.0-1
ii  libecal-2.0-13.36.1-1
ii  libedataserver-1.2-243.36.1-1
ii  libedataserverui-1.2-2   3.36.1-1
ii  libgeoclue-2-0   2.5.6-1
ii  libglib2.0-0 2.64.1-1
ii  libgoa-1.0-0b3.36.0-1
ii  libgtk-3-0   3.24.17-2
ii  libgweather-3-16 3.36.0-1
ii  libhandy-0.0-0   0.0.13-2
ii  libical3 3.0.8-1
ii  libpango-1.0-0   1.44.7-3
ii  libpangocairo-1.0-0  1.44.7-3
ii  libsoup2.4-1 2.70.0-1

Versions of packages gnome-calendar recommends:
ii  evolution-data-server  3.36.1-1

gnome-calendar suggests no packages.

-- no debconf information

Bug#956230: ITP: r-cran-survmisc -- GNU R miscellaneous functions for survival data

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-survmisc -- GNU R miscellaneous functions for survival data
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-survmisc
  Version : 0.5.5
  Upstream Author : Chris Dardis
* URL : https://cran.r-project.org/package=survMisc
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R miscellaneous functions for survival data
 A collection of functions to help in the analysis of
 right-censored survival data. These extend the methods available in
 package:survival.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-survmisc

Bug#956228: ITP: libbio-tradis-perl -- set of tools to analyse the output from TraDIS analyses.

2020-04-08 Thread Michael R. Crusoe

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-tradis-perl -- set of tools to analyse the output from 
TraDIS analyses.
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libbio-tradis-perl
  Version : 1.4.5
  Upstream Author : , Carla Cummins 
* URL : https://metacpan.org/release/Bio-Tradis
* License : GPL-3
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : set of tools to analyse the output from TraDIS analyses.
 For more information on the TraDIS method,
 see http://genome.cshlp.org/content/19/12/2308

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/libbio-tradis-perl

Bug#940656: [Pkg-privacy-maintainers] Bug#940656: black screen after upgrade

2020-04-08 Thread Roger Shimizu

control: forcemerge -1 942901

On Wed, Oct 23, 2019 at 9:18 PM Jean-Michel Vourgère  wrote:
>
> Control: notforwarded -1
>
> On Wednesday, 23 October 2019 13:01:53 CEST intrigeri wrote:
> > To me, it looks like you're affected by #942901 rather than #940656.
>
> You are right, sorry for the noise.

Thanks for the confirmation!
So closing this ticket.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#956227: lintian: false positive package-relation-with-self with foreign arch qualification

2020-04-08 Thread Andreas Beckmann

Package: lintian
Version: 2.64.0
Severity: normal

Hi,

I just tried to get rid of primus-libs-ia32 by changing the Recommends
in primus-libs from
  primus-libs-ia32 (= ${binary:Version}) [amd64],
to
  primus-libs:i386 (= ${binary:Version}) [amd64],
This nowadays works fine and I couldn't find any documentation saying
that arch-qualified Depends/Recommends/... are (still) forbidden. IIRC
they were not allowed(/working) at the introduction of multi-arch ...

The package looks like this:

 Package: primus-libs
 Source: primus
 Version: 0~20150328-11
 Architecture: amd64
 Maintainer: Debian NVIDIA Maintainers 

 Installed-Size: 273
 Depends: libc6 (>= 2.17), libgcc-s1 (>= 3.0), libglapi-mesa (>= 20.0.4), 
libstdc++6 (>= 5.2), libx11-6, libgl1, libglx-mesa0
 Recommends: primus-libs:i386 (= 0~20150328-11), libprimus-vk1
 Section: utils
 Priority: optional
 Multi-Arch: same
 Homepage: https://github.com/amonakov/primus
 Description: shared libraries for primus

and Lintian emits

W: primus-libs: package-relation-with-self recommends: primus-libs:i386 (= 
0~20150328-11)

which is not really a self-relation.

(Foreign-arch qualified Depends are probably not that useful, because
installation would require the foreign architecture to be enabled.
But Recommends do work fine if the foreign architecture is enabled and
do nothing otherwise.)


Andreas

Bug#955821: [Pkg-privacy-maintainers] Bug#955821: torbrowser-launcher: include upstream patch to allow access to u2f tokens

2020-04-08 Thread Roger Shimizu

control: tags -1 +pending

On Mon, Apr 6, 2020 at 7:33 PM Birger Schacht  wrote:
>
> Hi!
>
> On 4/6/20 10:57 AM, Ulrike Uhlig wrote:
> > Hi Birger!
> >
> >> it would be great if U2F devices (like a yubikey) would be usable by
> >> default with torbrowser. I created an upstream merge request to allow
> >> these devices in the apparmor profile a couple of months ago and it was
> >> was merged [0] (thanks to intrigeri!), but there was no new torbrowser
> >> release since then.
> >> Would it be possible to include the patch in the debian package? That
> >> would allow using salsa with U2F tokens (and any other Gitlab instance
> >> that might come up ;))
> >
> >> [0] https://github.com/micahflee/torbrowser-launcher/pull/434
> >
> > Great!
> >
> > How do you feel about creating a pull request on
> > https://salsa.debian.org/pkg-privacy-team/torbrowser-launcher ?
>
> Done ;)
> https://salsa.debian.org/pkg-privacy-team/torbrowser-launcher/-/merge_requests/1

Merged.
Thanks for your contribution to Debian!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#956226: linux: dh-thin-pool module missing in md-modules udeb, d-i unable to remove thinly provisioned logical volume

2020-04-08 Thread Raphael Hertzog

Source: linux
Version: 4.19.67-2+deb10u2
Severity: normal
Tags: d-i patch

The dm-thin-pool module is required when you want to run d-i on a machine
which contains thinly provisioned logical volumes. Otherwise d-i is unable
to remove them and you see messages like this from partman-lvm:

> modprobe: FATAL: Module dm-thin-pool not found in directory 
> /lib/modules/4.9.0-9-amd64
[...]
> Can't process LV vg_system/lv_system: thin-pool target support missing from 
> kernel?

Thus I attach a patch to add the missing module in md-modules. I have also
included the dependencies (dm-persistent-data and dm-bio-prison), I'm not
sure if it's required...

Cheers,
 Raphaël.

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS
>From 3b91afe0e9bc9626d81ae6695a7072e4bd792ef3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Wed, 8 Apr 2020 17:51:54 +0200
Subject: [PATCH] udeb: add dm-thin-pool in md-modules udeb

That module is required when you want to run d-i on a machine which
contains thinly provisioned logical volumes. Otherwise d-i is unable
to remove them and you see messages like this from partman-lvm:

modprobe: FATAL: Module dm-thin-pool not found in directory /lib/modules/4.9.0-9-amd64
Can't process LV vg_system/lv_system: thin-pool target support missing from kernel?
---
 debian/installer/modules/md-modules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/installer/modules/md-modules b/debian/installer/modules/md-modules
index d4f710406d46..d2da3b835d4f 100644
--- a/debian/installer/modules/md-modules
+++ b/debian/installer/modules/md-modules
@@ -6,9 +6,12 @@ raid0
 raid1
 raid456
 raid10
+dm-bio-prison
 dm-mirror
+dm-persistent-data
 dm-raid
 dm-snapshot
+dm-thin-pool
 bcache
 
 # RAID-related libraries, also used by btrfs
-- 
2.26.0

Bug#953052: [Help] Re: Bug#953052: psychopy: python2 dependencies

Control: tags -1 help

Hi DPMT,

I need to admit I'm currentl overwhelmed with COVID-19 hackathon.
A quick view does not really show any suspicious things to me.
Any help (including team upload / NMU) would be appreciated.

Kind regards

  Andreas.

On Tue, Mar 03, 2020 at 09:34:24PM +0100, Bob wrote:
> Package: psychopy
> Version: 2020.1.1+dfsg-1
> Severity: important
> 
> Dear Maintainer,
> 
> Psychopy seems to have python2 dependencies.
> 
> I do not have any python2 packages installed anymore.
> When installing psychopy 2020.1.1 with apt-get from the official debian repo,
> it pulls in a selection of python2 packages:
> 
> ipython libpython-stdlib libpython2-stdlib libpython2.7-minimal
> libpython2.7-stdlib python
>   python-backports-shutil-get-terminal-size python-chardet python-decorator
> python-enum34 python-ipython
>   python-ipython-genutils python-minimal python-pathlib2 python-pexpect 
> python-
> pickleshare python-pkg-resources
>   python-prompt-toolkit python-ptyprocess python-pygments python-scandir
> python-simplegeneric python-six python-traitlets
>   python-wcwidth python2 python2-minimal python2.7 python2.7-minimal
> 
> When manually installing the deb with gdebi it does not install these python2
> packages.
> 
> Seems to be some kind of packaging error.
> 
> Best,
> Bob
> 
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.5.0-7.1-liquorix-amd64 (SMP w/8 CPU cores; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
> TAINT_OOT_MODULE
> Locale: LANG=en_NL.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages psychopy depends on:
> ii  python33.7.5-3
> ii  python3-configobj  5.0.6-3
> ii  python3-freetype   2.1.0.post1-2
> ii  python3-future 0.18.2-1
> ii  python3-gevent 1.4.0-1+b1
> ii  python3-git3.0.7-1
> ii  python3-gitlab 1:2.0.1-1
> ii  python3-json-tricks3.11.0-2
> ii  python3-lxml   4.5.0-1
> ii  python3-matplotlib 3.1.2-2
> ii  python3-msgpack0.5.6-3
> ii  python3-msgpack-numpy  0.4.4-1
> ii  python3-numpy  1:1.17.4-5
> ii  python3-opengl 3.1.0+dfsg-2
> ii  python3-openpyxl   3.0.3-1
> ii  python3-pandas 0.25.3+dfsg-7
> ii  python3-pil6.2.1-2+b1
> ii  python3-psutil 5.6.7-1
> ii  python3-pygame 1.9.6+dfsg-2
> ii  python3-pyglet 1.4.10-1
> ii  python3-requests   2.22.0-2
> ii  python3-scipy  1.3.3-3
> ii  python3-serial 3.4-5.1
> ii  python3-soundfile  0.10.3+post1-1
> ii  python3-tables 3.6.1-2
> ii  python3-xlrd   1.1.0-5
> ii  python3-yaml   5.3-1
> ii  python3-zmq17.1.2-4
> 
> Versions of packages psychopy recommends:
> pn  ipython   
> ii  libxxf86vm1   1:1.1.4-1+b2
> ii  python3-cryptography  2.8-3
> ii  python3-distro1.4.0-1
> ii  python3-opencv4.2.0+dfsg-5
> ii  python3-pygame1.9.6+dfsg-2
> ii  python3-pyglet1.4.10-1
> ii  python3-pyo   1.0.0-2.1
> ii  python3-questplus 2019.4-2
> ii  python3-wxgtk4.0  4.0.7+dfsg-2
> ii  python3-xlib  0.23-2
> 
> Versions of packages psychopy suggests:
> pn  libavbin0   
> pn  python3-iolabs  
> pn  python3-pyxid   
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#956225: ITP: r-cran-purrrogress -- GNU R progress bars to mapping functions

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-purrrogress -- GNU R progress bars to mapping functions
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-purrrogress
  Version : 0.1.1
  Upstream Author : Andrew Redd
* URL : https://cran.r-project.org/package=purrrogress
* License : MIT
  Programming Lang: GNU R
  Description : GNU R progress bars to mapping functions
 This GNU R package provides functions to easily add progress bars
 to apply calls.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-purrrogress

Bug#956152: rabbitmq-server: fails to install reliably on arm64

2020-04-08 Thread Thomas Goirand

On 4/7/20 10:35 PM, Paul Gevers wrote:
> Package: rabbitmq-server
> Version: 3.7.18-1
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: flaky breaks
> Control: affects -1 mcollective
> 
> Dear maintainer(s),
> 
> As can be seen in the autopkgtests of mcollective [1], rabbitmq-server
> fails to reliably install on arm64 as it often fails to start.
> 
> Paul
> 
> [1] https://ci.debian.net/packages/m/mcollective/testing/arm64/
> 
> https://ci.debian.net/data/autopkgtest/testing/arm64/m/mcollective/4853115/log.gz
> 
> Setting up rabbitmq-server (3.7.18-1) ...
> Adding group `rabbitmq' (GID 109) ...
> Done.
> Adding system user `rabbitmq' (UID 107) ...
> Adding new user `rabbitmq' (UID 107) with group `rabbitmq' ...
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be
> preloaded (cannot open shared object file): ignored.
> Not creating home directory `/var/lib/rabbitmq'.
> Created symlink
> /etc/systemd/system/multi-user.target.wants/rabbitmq-server.service →
> /lib/systemd/system/rabbitmq-server.service.
> Job for rabbitmq-server.service failed because the control process
> exited with error code.
> See "systemctl status rabbitmq-server.service" and "journalctl -xe" for
> details.
> invoke-rc.d: initscript rabbitmq-server, action "start" failed.
> ● rabbitmq-server.service - RabbitMQ Messaging Server
>  Loaded: loaded (/lib/systemd/system/rabbitmq-server.service;
> enabled; vendor preset: enabled)
>  Active: activating (auto-restart) (Result: exit-code) since Mon
> 2020-04-06 20:55:24 UTC; 7ms ago
> Process: 2726 ExecStart=/usr/sbin/rabbitmq-server (code=exited,
> status=1/FAILURE)
>Main PID: 2726 (code=exited, status=1/FAILURE)
> dpkg: error processing package rabbitmq-server (--configure):
>  installed rabbitmq-server package post-installation script subprocess
> returned error exit status 1
> dpkg: dependency problems prevent configuration of autopkgtest-satdep:
>  autopkgtest-satdep depends on rabbitmq-server; however:
>   Package rabbitmq-server is not configured yet.
> 
> dpkg: error processing package autopkgtest-satdep (--configure):
>  dependency problems - leaving unconfigured
> 

Hi Paul,

How may I test installing rabbitmq-server on ARM64 ? I don't have such a
hardware...

Cheers,

Thomas Goirand (zigo)

Bug#956211: [Pkg-javascript-devel] Bug#956211: nodejs 10 segfaults when running webpack on gitlab 12.9.2 - FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap ou

2020-04-08 Thread Jérémy Lal

Tags: wontfix

Le mer. 8 avr. 2020 à 15:48, Pirate Praveen  a
écrit :

> Package: nodejs
> Version: 10.19.0~dfsg-3
> Severity: grave
> Control: notfound -1 12.13.1~dfsg-1
>
>
> nodejs 10 crashed (retried again) and on the same machine nodejs 12
> worked.
> This has been working upto gitlab 12.8.8 and the failure appeared when
> trying to update to 12.9.2 (just installing gitlab from experimental in
> an lxc container).
>

This is a known issue with nodejs and high memory usage, which happen
to be better with nodejs 12 (but only because gitlab assets compilation does
not go way above 2GB usage).

There is no way to fix it in general: you will always find use cases that
make
nodejs crash as soon as it is using GB of heap memory space.

Any nodejs < 14 version is affected (because who knows, v8 might make it
possible for node to fix it in nodejs 14) but not in the same way (some
fail at 1.4GB,
others at 2GB of heap space usage).

You can try running it with this flag:
webpack --max-old-space-size=4096

Note also that using a high value by default is not a good solution either.

Jérémy

Bug#939951: Link upstream bug

2020-04-08 Thread Ross Gammon

forwarded 939951 https://github.com/kupferlauncher/keybinder/issues/16
thanks

Looks like upstream have committed a fix, but have not confirmed it by
closing the issue.

Ross

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

Oh, one more thing I mean to say, @adrian, can you please confirm that
this installation of a live-build (?) image in this HP system does not
in fact include the /.disk/ files. Moving to a /.disk/info/ based
detection is of course not going to improve things in that situation if
the file exists in it anyway. I'm sure you probably thought of this,
but I did not notice any explicit mention in your discussion in
#924053...

On Wed, 2020-04-08 at 16:05 +0100, jnq...@gmail.com wrote:
> Oh, quick addition of something I forgot to put in the below message:
> 
> So in the discussion of #924053 it was suggested that the /.disc/info
> based solution would only work for ISO/ISO-hybrid images because this
> file was created by xorriso. I added a comment just now pointing out
> that in fact this file is created by the binary_disc script, which
> generates it for iso, iso-hybrid and hdd image types.
> 
> It does not create any such info for netboot and tar images types,
> though. I do not expect the tar image will be booted will it? and
> thus
> there's no concern there? I really do not know all that much about
> netboot, so I do not know whether or not there is a problem there.
> 
> On Wed, 2020-04-08 at 15:56 +0100, jnq...@gmail.com wrote:
> > Hi,
> > 
> > Okay, so I've just take a cursory look at your liveid stuff which
> > also
> > led me to #924053 where you've already brought up the EFI failure
> > side
> > of things.
> > 
> > I'll limit my response here (this bug report discussion) to matters
> > relating to simply fixing the broken ability to get bootable
> > images;
> > discussion of a unique-disc identification solution can take place
> > separately.
> > 
> > To fix the issue of broken EFI booting when syslinux is not used
> > (and
> > thus binary_syslinux was not put in place /live/vmlinuz), I was
> > intending to solve by moving creation of short filename kernel
> > files
> > out of binary_syslinux into somewhere common.
> > 
> > The first problem with this though is that alone of course it is
> > not
> > enough because it does not cover the `/live/vmlinuz1` multi-flavour
> > case, so a change to binaru_grub-efi would also be needed in order
> > to
> > dynamically change the searched for file to /live/vmlinuz1 where
> > appropriate.
> > 
> > However, I now understand from reading #924053 that although this
> > would
> > fix things in all/most cases, it's at risk of breaking for odd
> > situations like your HP laptop case. Using /.disc/info as the
> > searched
> > for file as proposed in #924053 is much a better solution.
> > 
> > My current intention is to take the patch of yours provided in
> > #924053
> > that makes this change, though with a tweaked commit message (I
> > think
> > the problem is EFI specific not Secure Boot specific), and submit
> > it
> > in
> > an MR, along with the fix for grub-pc, and some additional loosely
> > related work, in one or more MRs.
> > 
> > While the concept of correctly identifying discs (aka liveid type
> > stuff) is interesting and of some potential value, priority should
> > be
> > given to simply fixing the ability to create working images first
> > and
> > foremost.
> > 
> > I will have the patches mark this bug and #924053 as closed, and
> > leave
> > you to create a new wishlist bug to propose or re-start discussion
> > of
> > the unique-disc identification stuff as you wish.
> > 
> > Regards,
> > Lyndon
> > 
> > On Wed, 2020-04-08 at 09:40 +0200, adrian15sgd wrote:
> > > I think what you need is liveid.
> > > 
> > > https://github.com/rescatux/liveid
> > > 
> > > Here you can find the technical details and commits:
> > > 
> > > https://github.com/rescatux/liveid/blob/master/LIVEID_LIVE_BUILD_IMPLEMENTATION_1.md
> > > 
> > > That way you won't longer depend on arbitrary files such as
> > > vmlinuz.
> > > 
> > > 
> > > Feedback is welcome.
> > > 
> > > 
> > > P.S.: I was going to do proper merge requests in about 5 or 6
> > > months 
> > > later but here you are.
> > > 
> > > adrian15
> > > 
> > > 
> > > El 8/4/20 a las 1:02, jnq...@gmail.com escribió:
> > > > update:
> > > > 
> > > > 1) from my notes, in fact I'd gone back as far as v5.0
> > > > confirming
> > > > the
> > > > presence of the grub-pc failure.
> > > > 
> > > > 2) I've noticed the presence of the fixed path '/live/vmlinuz'
> > > > in
> > > > binary_grub-efi, and with a hack to have this replaced with the
> > > > long
> > > > name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI
> > > > side
> > > > of
> > > > the
> > > > problem, so that explains how the EFI stuff ends up checking
> > > > that
> > > > fixed
> > > > /live/vmlinuz' path and presents an alternate opportunity for a
> > > > fix. It
> > > > seems the author of the EFI live-build functionality only
> > > > tested
> > > > it
> > > > with syslinux.
> > > >

Bug#956224: firmware-realtek: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for module r8169

2020-04-08 Thread Nelson A. de Oliveira

Package: firmware-realtek
Version: 20190717-2
Severity: normal

Hi!

It seems that we are also missing /lib/firmware/rtl_nic/rtl8168fp-3.fw now:

=
update-initramfs: Generating /boot/initrd.img-5.5.0-1-amd64
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module 
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for module 
r8169
=

Thank you!

Best regards,
Nelson

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.136

-- no debconf information

Bug#956223: policykit-1: out-of-bounds reads in _localize (sub...@bugs.debian.org, line 1127)

2020-04-08 Thread Kevin Backhouse

Package: policykit-1
Version: 0.105-26

Dear Maintainer,

I noticed that there is an out-of-bounds read at the following source
location:

https://salsa.debian.org/utopia-team/polkit/-/blob/debian/0.105-26/src/polkitbackend/polkitbackendactionpool.c#L1127

There is also a potential out-of-bounds write a few lines below in the same
file (line 1131).

The bug happens when the locale string is longer than 256 characters. It
happens because strncpy does not insert a terminating null byte ('\0') when
the source string is too long. This means that the loop can read off the
end of the string, and potentially write out-of-bounds on line 1131.

The bug can be triggered by an unprivileged user sending an
EnumerateActions D-Bus message to polkitd. (I have attached a PoC.)

Although an out-of-bounds read/write is a potential security issue, in
practice my PoC does not cause polkitd to crash. That's because there are
usually some zero bytes on the stack (in the memory above lang2) which
prevent it from hitting anything important. In other words, this bug is
technically a security issue, but it is very low severity.

Weirdly, this bug only exists on the version of polkit used by Debian. It
was fixed 7 years ago in the main polkit repo:

https://gitlab.freedesktop.org/polkit/polkit/-/commit/facadfb5c8c52ba45fd20ffe3b6d3ddd4208a427

The bug is also fixed in policykit-1 version 0.116-2, which is the version
used by Debian experimental. But versions 0.105-15~deb8u4 to 0.105-26,
which are the versions used by the other Debian releases, contain the bug.

Despite the low severity of the bug, I would recommend cherry-picking
commit facadfb5c8c52ba45fd20ffe3b6d3ddd4208a427 onto all of your releases
to fix it.

Thank you,

Kevin Backhouse
GitHub Security Lab

Polkit_EnumerateActions_PoC.tar.bz2
Description: application/bzip

Bug#948206: mitmproxy incompatible with python3-wsproto=0.15.0-2

2020-04-08 Thread Andrej Shadura


On 08/04/2020 16:58, Andrej Shadura wrote:
Uploading an NMU to DELAYED/0, including the upstream fix and two 
clean-up commits from the Janitor.


Sorry, I intended to upload it to DELAYED/1 but was hit by an off-by-one 
error.


--
Cheers,
  Andrej

Bug#952603: python-tinyalign: license of buildwheels.sh is CC0

2020-04-08 Thread Sean Whitton

Hello,

On Mon 06 Apr 2020 at 08:34AM -07, tony mancill wrote:

> The buildwheels.sh in tinyalign is a derived work (there are multiple
> non-trivial modifications) from the upstream build-wheels.sh in
> pypa/python-manylinux-demo project, so I'm not sure that it's correct to
> say that it is necessarily licensed under the CC0.  That is, since
> CC0 is a "no rights reserved" license, what is prevent the author of the
> derived work from releasing under MIT without attribution?
>
> I am basing that on my reading of the CC0 [1] and its FAQ [2],
> specifically the statement:
>
>CC0 is a useful tool for clarifying that you do not claim
>copyright in a work anywhere in the world.
>
> IANAL and I'm not trying to bikeshed the license question, but it seems
> to me that works derived from CC0-licensed works might be different in
> this regard.  I patched the debian/copyright in [3] to refer to the
> original work and its CC0 license, but stopped short of indicating that
> the file in tinyalign is licensed under the CC0 because that seems to
> impinge upon the rights of author of the derived work.
>
> Does that address your concerns with the copyright for this file?

Makes sense to me.  Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#956222: thunderbird: Display glitch in folder pane's "Unread" column

2020-04-08 Thread Kris Deugau

Package: thunderbird
Version: 1:68.6.0-1~deb10u1
Severity: minor

Dear Maintainer,

After finally updating from 60.9 to 68.6, I found that the "Unread" column
in the folder pane was not consistently displaying the count of unread
messages.

This is enabled from "View -> Layout -> Folder Pane Columns", then clicking
the dropdown at the left of the resulting folder pane header, and checking
"Unread".

After toggling this option back and forth, and toggling messages as
read/unread, I found that if up to 9 messages in a folder were unread, the
correct number showed in this column.  If 10 or more messages were unread,
the number wasn't shown.  This was not affected by the column width, nor
the width of the folder pane.

The counts are displayed correctly in the default display mode (in brackets
just after the folder name).


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

Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6.1
ii  fontconfig2.13.1-2
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3+deb10u1
ii  libgcc1   1:8.3.0-6
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgtk-3-03.24.5-1
ii  libgtk2.0-0   2.24.32-3
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.42.4-7~deb10u1
ii  libstartup-notification0  0.12-6
ii  libstdc++68.3.0-6
ii  libvpx5   1.7.0-3+deb10u1
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  psmisc23.2-1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1
pn  lightning 

Versions of packages thunderbird suggests:
pn  apparmor  
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.17-3

-- no debconf information

Bug#952060: libsignon-glib: diff for NMU version 1.12-2.1

2020-04-08 Thread Aurélien COUDERC

Le 07/04/2020 à 09:52, Adrian Bunk a écrit :
> Control: tags 952060 + patch
> Control: tags 952060 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for libsignon-glib (versioned as 1.12-2.1) and 
> uploaded it to DELAYED/15. Please feel free to tell me if I should 
> cancel it.

Applied in git [1], thanks !

[1] https://salsa.debian.org/qt-kde-team/3rdparty/libsignon-glib


Happy hacking,
--
Aurélien

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

Oh, quick addition of something I forgot to put in the below message:

So in the discussion of #924053 it was suggested that the /.disc/info
based solution would only work for ISO/ISO-hybrid images because this
file was created by xorriso. I added a comment just now pointing out
that in fact this file is created by the binary_disc script, which
generates it for iso, iso-hybrid and hdd image types.

It does not create any such info for netboot and tar images types,
though. I do not expect the tar image will be booted will it? and thus
there's no concern there? I really do not know all that much about
netboot, so I do not know whether or not there is a problem there.

On Wed, 2020-04-08 at 15:56 +0100, jnq...@gmail.com wrote:
> Hi,
> 
> Okay, so I've just take a cursory look at your liveid stuff which
> also
> led me to #924053 where you've already brought up the EFI failure
> side
> of things.
> 
> I'll limit my response here (this bug report discussion) to matters
> relating to simply fixing the broken ability to get bootable images;
> discussion of a unique-disc identification solution can take place
> separately.
> 
> To fix the issue of broken EFI booting when syslinux is not used (and
> thus binary_syslinux was not put in place /live/vmlinuz), I was
> intending to solve by moving creation of short filename kernel files
> out of binary_syslinux into somewhere common.
> 
> The first problem with this though is that alone of course it is not
> enough because it does not cover the `/live/vmlinuz1` multi-flavour
> case, so a change to binaru_grub-efi would also be needed in order to
> dynamically change the searched for file to /live/vmlinuz1 where
> appropriate.
> 
> However, I now understand from reading #924053 that although this
> would
> fix things in all/most cases, it's at risk of breaking for odd
> situations like your HP laptop case. Using /.disc/info as the
> searched
> for file as proposed in #924053 is much a better solution.
> 
> My current intention is to take the patch of yours provided in
> #924053
> that makes this change, though with a tweaked commit message (I think
> the problem is EFI specific not Secure Boot specific), and submit it
> in
> an MR, along with the fix for grub-pc, and some additional loosely
> related work, in one or more MRs.
> 
> While the concept of correctly identifying discs (aka liveid type
> stuff) is interesting and of some potential value, priority should be
> given to simply fixing the ability to create working images first and
> foremost.
> 
> I will have the patches mark this bug and #924053 as closed, and
> leave
> you to create a new wishlist bug to propose or re-start discussion of
> the unique-disc identification stuff as you wish.
> 
> Regards,
> Lyndon
> 
> On Wed, 2020-04-08 at 09:40 +0200, adrian15sgd wrote:
> > I think what you need is liveid.
> > 
> > https://github.com/rescatux/liveid
> > 
> > Here you can find the technical details and commits:
> > 
> > https://github.com/rescatux/liveid/blob/master/LIVEID_LIVE_BUILD_IMPLEMENTATION_1.md
> > 
> > That way you won't longer depend on arbitrary files such as
> > vmlinuz.
> > 
> > 
> > Feedback is welcome.
> > 
> > 
> > P.S.: I was going to do proper merge requests in about 5 or 6
> > months 
> > later but here you are.
> > 
> > adrian15
> > 
> > 
> > El 8/4/20 a las 1:02, jnq...@gmail.com escribió:
> > > update:
> > > 
> > > 1) from my notes, in fact I'd gone back as far as v5.0 confirming
> > > the
> > > presence of the grub-pc failure.
> > > 
> > > 2) I've noticed the presence of the fixed path '/live/vmlinuz' in
> > > binary_grub-efi, and with a hack to have this replaced with the
> > > long
> > > name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI side
> > > of
> > > the
> > > problem, so that explains how the EFI stuff ends up checking that
> > > fixed
> > > /live/vmlinuz' path and presents an alternate opportunity for a
> > > fix. It
> > > seems the author of the EFI live-build functionality only tested
> > > it
> > > with syslinux.
> > >

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

2020-04-08 Thread Markus Koschany



Am 08.04.20 um 16:20 schrieb Scott Talbert:
[...]
> So, I took an initial look at trying to package Phoenicis, but it looks
> like a rather large task (ie, lots of missing dependencies).
> 
> On the other hand, I looked at the Python code, and at first glance, it
> doesn't look like it would be *that* difficult to port to Python 3. 
> Would you be amenable to me developing a patch to port to Python 3, at
> least as an interim solution?
> 
> Thanks,
> Scott

Hello Scott,

sure feel free to work on a patch to fix #937302, no need to ask for my
approval.

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux