Bug#943683: RM: hgsvn/0.1.8-1.1

[Adam D. Barratt]

Control: reassign -1 ftp.debian.org

On Mon, 2019-10-28 at 00:22 +0100, Vincent Danjean wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: rm
> 
>   Hi,
> 
>   Can you remove this package from unstable ?

No, that's FTP Team territory. Re-assigning.

> It is
> completly buggy in oldstable (see #907494), not
> present in stable and testing, not maintained
> upstream anymore and not usable with current
> versions of mercurial and subversion (see last
> message in #907494).
> 
>   Regards,
> Vincent
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'),
> (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500,
> 'oldstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, armel, mipsel
> 
> Kernel: Linux 5.3.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8),
> LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> 

Bug#943691: lifeograph FTCBFS: does not pass a crossfile to meson

[Helmut Grohne]

Source: lifeograph
Version: 1.5.1.1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

lifeograph fails to cross build from source, because it does not pass a
crossfile to meson. The easiest way of fixing that - using
dh_auto_configure - makes lifeograph cross buildable. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru lifeograph-1.5.1.1/debian/changelog 
lifeograph-1.5.1.1/debian/changelog
--- lifeograph-1.5.1.1/debian/changelog 2019-01-24 21:48:58.0 +0100
+++ lifeograph-1.5.1.1/debian/changelog 2019-10-28 05:41:18.0 +0100
@@ -1,3 +1,10 @@
+lifeograph (1.5.1.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass a crossfile to meson. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 28 Oct 2019 05:41:18 +0100
+
 lifeograph (1.5.1.1-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru lifeograph-1.5.1.1/debian/rules 
lifeograph-1.5.1.1/debian/rules
--- lifeograph-1.5.1.1/debian/rules 2019-01-24 21:48:58.0 +0100
+++ lifeograph-1.5.1.1/debian/rules 2019-10-28 05:41:18.0 +0100
@@ -7,24 +7,16 @@
 BUILDDIR=$(CURDIR)/builddir/
 DESTDIR=$(CURDIR)/debian/lifeograph/
 
-override_dh_clean:
-   dh_clean
-   rm -rf $(BUILDDIR)
-
 override_dh_auto_configure:
-   meson --buildtype=release --prefix=/usr/ $(BUILDDIR)
-
-override_dh_auto_build:
-   cd $(BUILDDIR) && ninja
+   dh_auto_configure -- --buildtype=release
 
 override_dh_auto_install:
-   cd $(BUILDDIR) && DESTDIR=$(DESTDIR) ninja install
+   dh_auto_install
install -m0755 -d $(DESTDIR)/usr/share/metainfo/
mv $(DESTDIR)/usr/share/appdata/net.sourceforge.lifeograph.appdata.xml \
   $(DESTDIR)/usr/share/metainfo/
 
 %:
-   dh $@
+   dh $@ --buildsystem=meson --builddirectory=$(BUILDDIR)
 
-.PHONY: override_dh_clean override_dh_auto_configure override_dh_auto_build \
-   override_dh_auto_install
+.PHONY: override_dh_auto_configure override_dh_auto_install

Bug#938757: unrardll: diff for NMU version 0.1.3-3.1

[Norbert Preining]

Hi Sandro,

> calibre only declares a Suggests on unrardll; as per policy

Because it is in contrib, and not main ... 

> that means calibre should work perfectly fine even without unrardll.

It does, but a considerable part of the functionality is missing.

> should consider bump it to at least Recommends.

Which is not possible due to policy.

> > https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu
> 
> anything in particular you want to highlight in regards to a package

Please reread the points stated there. 
Have you clearly expressed your intention to NMU, at least in the BTS? 
If that didn't generate any feedback, it might also be a good idea to try to 
contact the maintainer by other means (email to the maintainer addresses or 
private email, IRC).

and
When doing an NMU, you must first make sure that your intention to NMU 
is clear. Then, you must send a patch with the differences between the current 
package and your proposed NMU to the BTS. The nmudiff script in the devscripts 
package might be helpful.

Anyway.

> in contrib, with practically no reverse depends, part of a 3300+
> packages "transition"?

So what need is there to hurry then if there are no rdepends besides
calibre, which is py2 and thus needs the py2 version of it.

> anyhow, i cancel this NMU..

Thanks

Norbert

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

Bug#941060: chromium: When will the upgrade to v77 reach debian?

[Shengjing Zhu]

Dear maintainer,

The current version of Chromium is seriously out of date. And even
chromium itself is telling you that

Please see the attached screenshot.
https://img.vim-cn.com/2f/303f0cbf9a492a55d40004937ea97f08174aa2.png

-- 
Shengjing Zhu

Bug#938757: unrardll: diff for NMU version 0.1.3-3.1

[Sandro Tosi]

> You might not have seen my blog posts about the state of calibre in Debian, 
> they have been aggregated on planet.

i read it, and i considered when preparing this NMU.

> Anyway, as long as I keep a Py2 version of Calibre in sid/testing, **do not** 
> remove Py2 support from unrardll.

calibre only declares a Suggests on unrardll; as per policy
https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends

Suggests
This is used to declare that one package may be more useful with one
or more others. Using this field tells the packaging system and the
user that the listed packages are related to this one and can perhaps
enhance its usefulness, but that installing this one without them is
perfectly reasonable.

that means calibre should work perfectly fine even without unrardll.
if it is more important than what Suggests means, then i guess you
should consider bump it to at least Recommends.

even dak, the archive toolkit, ignores Suggests when checking what
would break when removing a binary package:

```
$ dak rm -Rn -b python-unrardll
Will remove the following packages from unstable:

python-unrardll |0.1.3-3 | amd64

Maintainer: Norbert Preining 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.
```


> And in addition, you might want to read up on
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu

anything in particular you want to highlight in regards to a package
in contrib, with practically no reverse depends, part of a 3300+
packages "transition"?

anyhow, i cancel this NMU..

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

Bug#740369: libapache2-mod-python: needs python3 support

[Peter Chubb]

Package: libapache2-mod-python
Version: 3.3.1-11
Followup-For: Bug #740369

Dear Maintainer,

Given that python2 is nearing end-of-life, it's becoming urgent to package a
a version of libapache2-mod-python that supports python3.

Please package up version 3.5 for Debian.

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/28 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libapache2-mod-python depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.41-1
ii  libc6   2.29-2
ii  libpython2.72.7.17-1
ii  python  2.7.17-1

libapache2-mod-python recommends no packages.

Versions of packages libapache2-mod-python suggests:
pn  libapache2-mod-python-doc  

-- no debconf information

Bug#943690: src:sphinxcontrib-youtube: Maintainer email address not working

[Scott Kitterman]

Package: src:sphinxcontrib-youtube
Version: 1.0-1
Severity: serious
Justification: Policy 3.3

Policy requires a maintainer email address that accepts mail.  Mail for
this maintainer has been failing:

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  thomi.richa...@canonical.com
host mx.canonical.com [91.189.95.10]
SMTP error from remote mail server after RCPT 
TO::
550 5.1.1 : Recipient address rejected:
User unknown in virtual alias table

 Given the error, it seems unlikely to be temporary.

 Scott K

Bug#943689: python-hamcrest: Long description incomplete

[Scott Kitterman]

Package: python-hamcrest
Version: 1.8.0-3
Severity: minor

Dear Maintainer,

If you compare the long description of the python-hamcrest package (just
re-introduced) to that of the python3-hamcrest package, you'll find
three lines missing.  It looks like a copy/paste error.

While not critical, it ought to be easy enough to fix in the next
upload.

Scott K

Bug#943688: src:pyhamcrest: debian/copyright out of date

[Scott Kitterman]

Package: src:pyhamcrest
Version: 1.8.0-1
Severity: inportant

Dear Maintainer,

The copyright statements in debian/copyright are out of date/incomplete.
There is no longer any copyright claim by Joe Walnes and the
hamcrest.org copyright statements are incomplete (which is a license
violation in this case):

src/hamcrest/core/core/raises.py:__copyright__ = "Copyright 2013 hamcrest.org"
src/hamcrest/core/compat.py:__copyright__ = "Copyright 2013 hamcrest.org"
src/hamcrest/__init__.py:__copyright__ = "Copyright 2013 hamcrest.org"
src/hamcrest/library/collection/__init__.py:__copyright__ = "Copyright 2013 
hamcrest.org"
src/hamcrest/library/collection/is_empty.py:__copyright__ = "Copyright 2012 
hamcrest.org"

Scott K

Bug#943687: linux-image-4.19.0-5-amd64: kernel forgets usb mice device connected through a usb version 3 monitor hub

[Adrian Immanuel Kiess]

Package: src:linux
Version: 4.19.37-6
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 Bought a new monitor, a HP Z24i G2
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Plugged monitor in, connected two usb devices onto the monitor hub; namely
a HP CCID keyboard and a standard HP laser mouse
   * What was the outcome of this action?
 The linux kernel seems to forget the USB HP laser mouse, after monitor
went into suspend state and wakes up again
   * What outcome did you expect instead?
 Working USB mouse after suspend state of monitor

I've connected a new HP Z24i G2 monitor to my Debian/testing system running
recent Xorg plus  Enlightenment DR17 and encounter the following problem:

I've connected two USB devices at the USB version 3 hub of the monitor which
works quite fine, a USB CCID keyboard and a standard HP USB laser mouse. But
when the HP Z24i G2 monitor wents into suspend state or is turned manually off,
the connected USB laser mouse won't work any longer after the monitor has
turned to ready state any longer.

Try this two or three times and let an hour pass while the monitor is turned
off. It is not happening all the time.

Workaround: Plug out and plug in again the HP USB laser mouse at the USB 3 hub
of the monitor.

I assume this is a linux kernel issue and has to do with the kernel
implementation of USB hubs.

I hope you can find a solution for this behaviour of the linux kernel.

Thank you very much for reading this.

Yours sincerely,

Adrian Kiess



-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-19)) #1 SMP Debian 4.19.37-6 (2019-07-18)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 
root=UUID=96d5fdb9-5d4e-46f2-89e3-34fcfc7bfe14 ro 
resume=UUID=3d740914-57bc-440c-843f-d15812ee3903 splash splash vga=775

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: HP
product_name: ProLiant ML110 G6
product_version: 
chassis_vendor: HP
chassis_version: N/A
bios_vendor: HP
bios_version: O27   
board_vendor: Wistron Corporation
board_name: ProLiant ML110 G6
board_version: 

** Loaded modules:
nft_chain_route_ipv6
nft_chain_nat_ipv6
nf_nat_ipv6
rfcomm
cmac
bnep
btusb
btrtl
btbcm
btintel
bluetooth
drbg
ansi_cprng
ecdh_generic
rfkill
fuse
nf_conntrack_netlink
nft_chain_route_ipv4
xt_CHECKSUM
nft_chain_nat_ipv4
ipt_MASQUERADE
nf_nat_ipv4
nf_nat
xt_conntrack
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
ipt_REJECT
nf_reject_ipv4
nft_counter
xt_tcpudp
nft_compat
tun
bridge
stp
llc
devlink
nf_tables
nfnetlink
cpufreq_conservative
cpufreq_userspace
cpufreq_powersave
uinput
binfmt_misc
quota_v2
quota_tree
joydev
snd_usb_audio
snd_usbmidi_lib
snd_rawmidi
snd_seq_device
evdev
loop
intel_powerclamp
coretemp
ipmi_watchdog
ipmi_ssif
kvm_intel
kvm
snd_hda_codec_hdmi
irqbypass
amdgpu
snd_hda_intel
intel_cstate
sg
snd_hda_codec
snd_hda_core
intel_uncore
snd_hwdep
snd_pcm
pcspkr
snd_timer
iTCO_wdt
snd
chash
gpu_sched
iTCO_vendor_support
soundcore
pcc_cpufreq
button
acpi_cpufreq
dm_mod
nfsd
nfs_acl
lockd
auth_rpcgss
grace
sunrpc
ipmi_si
ipmi_poweroff
ipmi_devintf
ipmi_msghandler
i2c_dev
parport_pc
ppdev
lp
parport
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
fscrypto
ecb
crypto_simd
cryptd
glue_helper
aes_x86_64
btrfs
xor
zstd_decompress
zstd_compress
xxhash
raid6_pq
libcrc32c
crc32c_generic
uhci_hcd
uas
usb_storage
hid_generic
usbhid
hid
sr_mod
cdrom
sd_mod
radeon
ahci
libahci
xhci_pci
i2c_algo_bit
ehci_pci
libata
drm_kms_helper
xhci_hcd
ttm
ehci_hcd
scsi_mod
i2c_i801
drm
tg3
crc32c_intel
lpc_ich
usbcore
libphy
usb_common

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Core Processor DMI [8086:d130] 
(rev 11)
Subsystem: Hewlett-Packard Company Core Processor DMI [103c:3318]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:03.0 PCI bridge [0604]: Intel Corporation Core Processor PCI Express Root 
Port 1 [8086:d138] (rev 11) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:08.0 System peripheral [0880]: Intel Corporation Core Processor System 
Management Registers [8086:d155] (rev 11)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:08.1 System peripheral [0880]: Intel Corporation Core Processor Semaphore 
and Scratchpad Registers [8086:d156] (rev

Bug#936865: libgda5 python porting forwarded upstream

[Andreas Henriksson]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/libgda/issues/202

Hello,

I've opened an upstream bug report about porting python2->python3.

Regards,
Andreas Henriksson

Bug#942235: dask: autopkgtest needs update for new version of pytest

[Drew Parsons]

Source: dask
Followup-For: Bug #942235
Control: tags -1 + help

On 2019-10-27 10:03, Drew Parsons wrote:

Fixed upstream, latest version is pushed to the experimental branch.

Needs sphinx-click, which is in the NEW queue.



sphinx-click is now available.

The dask 2.6.0 build from experimental proceeds, but runs into an error 
when buildings docs with sphinx:


  PYTHONPATH=/home/projects/python/build/dask /usr/bin/make -C docs html
  make[2]: Entering directory '/home/projects/python/build/dask/docs'
  sphinx-build -b html -d build/doctrees   source build/html
  Running Sphinx v1.8.5
  making output directory...
  loading intersphinx inventory from 
/usr/share/doc/python-pandas-doc/html/objects.inv...


  Exception occurred:
File "/usr/lib/python3/dist-packages/sphinx/ext/intersphinx.py", 
line 224, in load_mappings

  name, (uri, inv) = key, value
  ValueError: too many values to unpack (expected 2)


The accompanying error log does not give me more illumination:

# Sphinx version: 1.8.5
# Python version: 3.7.5 (CPython)
# Docutils version: 0.15.2 release
# Jinja2 version: 2.10.1
# Last messages:

# Loaded extensions:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 303, 
in build_main

args.tags, args.verbosity, args.jobs, args.keep_going)
  File "/usr/lib/python3/dist-packages/sphinx/application.py", line 263, 
in __init__

self._init_builder()
  File "/usr/lib/python3/dist-packages/sphinx/application.py", line 325, 
in _init_builder

self.emit('builder-inited')
  File "/usr/lib/python3/dist-packages/sphinx/application.py", line 510, 
in emit

return self.events.emit(event, self, *args)
  File "/usr/lib/python3/dist-packages/sphinx/events.py", line 80, in 
emit

results.append(callback(*args))
  File "/usr/lib/python3/dist-packages/sphinx/ext/intersphinx.py", line 
224, in load_mappings

name, (uri, inv) = key, value
ValueError: too many values to unpack (expected 2)


I can't tell if it's an internal error in sphinx, or triggered by dask, 
so need help with the bug (cc:ing Diane, the dask uploader).


The last output in the build log refers to 
python-pandas-doc/html/objects.inv. I'm not sure if it means pandas-doc 
passed successfully, or if it indicates pandas is triggering the 
ValueError.  cc:ing Rebecca (pandas uploader) to ask if she's seen this 
problem with pandas elsewhere.


Drew

Bug#939713: ifupdown: brctl dependency

[Andreas Henriksson]

Control: reassign -1 ifupdown 0.8.35

Hello,

On Fri, Sep 27, 2019 at 11:21:51AM +0300, sergio wrote:
> On 27/09/2019 11:15, Luca Boccassi wrote:
> 
> > why the reassignment from bridge-utils to iproute2
> 
> bridge-utils already provides if-{pre|post}-up.d/bridge and iproute2
> does not.

I'm going to reassign this back to where it originally came from,
ifupdown.

My opinions is that bridge-utils is deprecated and should eventually
get removed. (The sooner the better.)

As previously suggested bridge-utils /could/ ports its ifupdown hooks
over to use iproute2, but as I'm personally not a fan of micro-packaging
keeping the bridge-utils package around simply for the ifupdown hooks
does not sound like a good plan to me. (The current hooks
implementations also seems to have limitations that one might want to
adress in a newly designed solution.)

The iproute2 package also can't ship the same ifupdown hook files as
bridge-utils does as that would be a conflict. And even if the conflict
was specified via the Conflicts: control keyword that still wouldn't
work as files under /etc are dpkg conffiles. The files could ofcourse
have a different name under iproute2 but then you would also need to
handle the case when both iproute2 and bridge-utils provides the same
hooks (with different names) and avoid both of their functionality
colliding mid-air. I simply don't find this compelling to pursue.

I'm also going to state that iproute2 is a package with (only) low level
networking utilities. It is not the right place to implement higher
level (ifupdown) functionality. The iproute2 package does not ship any
kind of policy on how the tools should be used (eg. init scripts, etc.),
it simply provides a mechanism which other higher level packages can
use to implement their policy.

The ifupdown implementation already heavily relies on iproute2 and
changing that would be a big undertaking and isn't going to change any
time soon as far as I can predict. If someone wants bridge support in
ifupdown, then I'd suggest the correct place to implement that would be
in the ifupdown package itself. The functionality is already at
ifupdowns fingertips as the already existing dependency on iproute2
also gives the bridge command. Spreading ifupdown implementation over a
wide range of packages is in my opinion a mistake. I also think the
hooks are an often overused way of working around missing functionality
in ifupdown that is better adressed by implementing it properly in
ifupdown if so desired.

I personally think that networking tools that wants to be something to
count with needs to be able to speak netlink (and listen to events). I
don't see ifupdown as part of a future vision. It's mainly filling the
need of being a widly documented way of setting up basic networking. As
time passes I hope documentation for more modern solutions will be more
pervasive and the need for keeping compatibility with
/etc/network/interfaces hopefully diminish. The iproute2 suite can be
used for simpler "one off" tasks (which higher level networking policy
tools should see via netlink events). With all this in mind, I think
this is yet another reason why iproute2 should not get involved in
ifupdown business (or in any other way widen its scope). Specially since
getting people interested in helping out with iproute2 package
maintenance has unfortunately proven harder than desired despite its
very wide usage. In my opinion someone who wants to rely on advanced
functionility like bridging should probably be looking for an
alternative to ifupdown. I personally wouldn't mind this bug report
simply being tagged wontfix (and closed) in a self-deprecating kind of
way if ifupdown maintainers thinks bridging is not something they
want to support.

Apart from the reasons already stated above, I think the original
description fits well with this being an ifupdown feature request
(rather than any other alternative view of how to interpret this as has
been done during the following reassignings).

Regards,
Andreas Henriksson

Bug#932416: debian-installer: running d-i in parallel on multiple consoles may lead to race conditions

[Wookey]

Apologies for the delay in getting to look at this properly. After
quite a lot of faffage, I have now reproduced this issue in a
convenient (KVM) setup so will be working on fixing it forthwith.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#924673: libopencsd0:amd64: New flag needed to compile CoreSight support in the perf tools

[Wookey]

On 2019-03-15 11:09 -0600, Mathieu Poirier wrote:
> Package: libopencsd0
> Severity: normal
> 
> Dear Maintainer,
> 
> Starting with the 5.1 Linux kernel cycle it is mandatory to add the command 
> line
> option "CORESIGHT=1" to enable CoreSight support when compiling the perf 
> tools.
> 
> Before kernel 5.1:
> 
>   $ make -C tools/perf 
> 
> For kernel 5.1 and after:
> 
>   $ make -C tools/perf CORESIGHT=1

OK. It took a while to get kernel 5.3.7 building aginst
libopencsd0.12, but it is now, so I could test this.

The debian kernel package does indeed now need a small patch to enable
coresight in perf. Attached. (and this bug re-assigned to the kernel).


Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
--- debian/rules.d/tools/perf/Makefile~	2019-09-10 11:36:37.0 +
+++ debian/rules.d/tools/perf/Makefile	2019-10-24 15:54:13.659470790 +
@@ -22,6 +22,9 @@
 # an explicit exception.  Override detection of libcrypto.
 MAKE_PERF += NO_LIBCRYPTO=1
 
+# perf only links against libopencsd (coresight) if specifically enabled
+MAKE_PERF += CORESIGHT=1
+
 # Currently babeltrace support for `perf data' is not automatically detected.
 MAKE_PERF += LIBBABELTRACE=1
 


signature.asc
Description: PGP signature

Bug#943685: installation-reports: Missing modules for all ethernet NICs

[Witold Baryluk]

Package: installation-reports
Severity: important

I have never seen this problem before with debian testing installer, but here 
it is


3d1f1fbae2fa937f6af9a71e96dbad10f9ce8ce1f0210deb1ac069b57f074948  
debian-testing-amd64-netinst.iso

https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso

2019-10-27 22:45338M


I tried Expert install in virt-manager with qemu, both with rtl8139
emulated device, and with e1000e to no success. lspci does show them.

/lib/modules/5.2.0-3-amd64/kernel/drivers/net/ethernet/ has only one file: 
broadcom/cnci.ko

The debian installer says:


"No kernel modules were found. This is probably due to a missmatch
between kernel used by this version of the installer and the kernel
version available in the archive."


Ugh? I don't have access to any network yet, so I am not sure what
archive debian installer is talking about.


If it included different kernel to boot and different modules on the
medium that is definitively a bug in the debian installer build process
or in live wrapper or something.

In debug console it shows:

cdrom-retriever: warning: File 
/cdrom/dists/bullseye/main/debian-installer/binary-amd64/Packages does not 
exist.
(PS. Packages.gz does exists there tho).
cdrom-retriever: warning: Unable to find 
contrib/debian-installer/binary-amd64/Packages in /cdrom/dists/bullseye/Release.
cdrom-retriever: warning: Unable to find 
contrib/debian-installer/binary-amd64/Package.gz in 
/cdrom/dists/bullseye/Release.
anna[2050]: WARNING **: no packages matching running kernel 5.2.0-3-amd64 in 
archive




I did check manually zcat
/cdrom/dists/bullseye/main/debian-installer/binary-amd64/Packages.gz and
it does list multiple udeb packages for kernel 5.3.0-1-amd64-di. For
example nic-modules-5.3.0-1-amd64-di_5.3.7-1_amd64.udeb

The file does exist on the medium, and is 4.0MB.

The running kernel is 5.2.0-3-amd64

So maybe the issue is with the "-di" suffix?


Regards,
Witold



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

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

Bug#749991: debian-installer: Wrong kernel in debian-installer package

[Witold Baryluk]

Package: debian-installer
Followup-For: Bug #749991

I think I did hit the same issue with todays daily netinst CD images.

See https://bugs.debian.org/943685

Cheers,
Witold

Bug#914573: ITP: mongo-cxx-driver -- MongoDB C++ client library

[Roberto C . Sánchez]

I am still waiting.  However, there are many packages still waiting in
NEW, some for nearly one year, so I am not sure when mongo-cxx-driver
might be approved.

Regards,

-Roberto

On Sun, Oct 27, 2019 at 08:04:26PM +0100, Christophe CT. TROPHIME wrote:
> Any news for this package?
> 
> It seems to be in NEW but cannot find it elsewhere
> 
> https://ftp-master.debian.org/new/mongo-cxx-driver_3.4.0-1.html
> 
> Best.
> C

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

Bug#865372: firefox-esr: 45.9.0esr-1~deb8u1 to 52.2.0esr-1~deb8u1 breaks profiles

[karlnorma]

Confirmed - forcing people to create a mozilla account to migrate to a new version is not the Debian 
way.


This is actually a serious bug.



Karl Schmidt  EMail k...@lrak.net
3209 West 9th Street Ph (785) 979-8397
Lawrence, KS 66049

Bug#943684: lintian: Refine ‘override_dh_auto_test’ check to trigger only when different command

[Ben Finney]

Package: lintian
Version: 2.15.0
Severity: normal

The check ‘override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS’
triggers incorrectly when the ‘override_dh_auto_test’ target merely
invokes ‘dh_auto_test’ with different options.

=
$ grep '^override_dh_auto_test:' --after-context 3 debian/rules
override_dh_auto_test:
dh_auto_test --buildsystem=makefile

$ lintian
[…]
I: python-daemon source: override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS 
(line 25)
[…]
=

The manual page ‘dh(1)’ explains of “override targets” that:

The override target can then run the command with additional
options, or run entirely different commands instead.

The above usage is a normal use of override target to change the
command-line option with which ‘dh_auto_test’ is invoked. This does
not need to be further wrapped with a ‘DEB_BUILD_OPTIONS’ test,
because that is done when ‘dh_auto_test’ runs.

Please change Lintian so that this check is done only when the
‘override_dh_auto_test’ target contains commands *other than* a
‘dh_auto_test’ command. The logic could be:

* If this is an ‘override_dh_auto_test’ target:
  * If there is exactly one command in the rule:
* If the command name is ‘dh_auto_test’:
  * Do not inspect whether ‘DEB_BUILD_OPTIONS’ is tested.

  * Otherwise (different command; or multiple commands):
* Inspect whether ‘DEB_BUILD_OPTIONS’ is tested. If not:
  * Emit ‘override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS’.


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

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-16
ii  bzip2  1.0.6-9.2~deb10u1
ii  diffstat   1.62-1
ii  dpkg   1.19.7
ii  dpkg-dev   1.19.7
ii  file   1:5.35-4+deb10u1
ii  gettext0.19.8.1-9
ii  gpg2.2.12-1+deb10u1
ii  intltool-debian0.35.0+20060710.5
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcapture-tiny-perl   0.48-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
ii  libdpkg-perl   1.19.7
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libio-async-perl   0.72-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libpath-tiny-perl  0.108-1
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  libtry-tiny-perl   0.30-1
ii  liburi-perl1.76-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.76+repack-1
ii  man-db 2.8.5-2
ii  patchutils 0.3.4-2
ii  perl [libdigest-sha-perl]  5.28.1-6
ii  t1utils1.41-3
ii  xz-utils   5.2.4-1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

Versions of packages lintian suggests:
ii  binutils-multiarch 2.31.1-16
ii  libhtml-parser-perl3.72-3+b3
pn  libtext-template-perl  

-- no debconf information

-- 
 \ “If history and science have taught us anything, it is that |
  `\ passion and desire are not the same as truth.” —E. O. Wilson, |
_o__)  _Consilience_, 1998 |
Ben Finney 

signature.asc
Description: PGP signature

Bug#925591: grub-install fails on raid1+efi setup

[Jakub Filo]

Hello,

I would like to ask, what firmware is this happening on? Any chance it's
OVMF?


Best Regards,
Jakub Filo

Bug#919533: python3-oauthlib: New version available

[Daniele Tricoli]

On Thu, 17 Jan 2019 02:22:07 +0300 Gennady Kovalev  wrote:
> Package: python3-oauthlib
> Version: 2.1.0-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> oauthlib has new version released, that supports openid connect. Please update
> if it possible.
> 
> Thanks!
> 
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
> LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages python3-oauthlib depends on:
> ii  python3   3.7.1-3
> ii  python3-blinker   1.4+dfsg1-0.2
> ii  python3-cryptography  2.3-1
> ii  python3-jwt   1.7.0-2
> 
> python3-oauthlib recommends no packages.
> 
> python3-oauthlib suggests no packages.
> 
> -- no debconf information
> 
> 

Bug#938757: unrardll: diff for NMU version 0.1.3-3.1

[Norbert Preining]

And in addition, you might want to read up on 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu

Thanks

Norbert

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

Bug#943683: RM: hgsvn/0.1.8-1.1

[Vincent Danjean]

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

  Hi,

  Can you remove this package from unstable ? It is
completly buggy in oldstable (see #907494), not
present in stable and testing, not maintained
upstream anymore and not usable with current
versions of mercurial and subversion (see last
message in #907494).

  Regards,
Vincent

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

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

Bug#938757: unrardll: diff for NMU version 0.1.3-3.1

[Norbert Preining]

Control: tags 938757 - pending

Dear Sandro,

Thanks for your interest, but please stop this, please, immediately.

You might not have seen my blog posts about the state of calibre in Debian, 
they have been aggregated on planet.

Anyway, as long as I keep a Py2 version of Calibre in sid/testing, **do not** 
remove Py2 support from unrardll.

Thanks

Norbert



On October 28, 2019 7:46:44 AM GMT+09:00, Sandro Tosi  wrote:
>Control: tags 938757 + patch
>Control: tags 938757 + pending
>
>
>Dear maintainer,
>
>I've prepared an NMU for unrardll (versioned as 0.1.3-3.1) and
>uploaded it to DELAYED/7. Please feel free to tell me if I
>should delay it longer.
>
>Regards.


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

Bug#926997: Fixed

[Thomas Goirand]

I believe this bug is not relevant anymore to the version in Sid (though
I'm not sure when this FTBFS issue was fixed).

Thomas

Bug#746415: The problem is in bashrc.

[Stephen Samuel]

I've just had this problem -- updated to Mint 19.2 and found Gnome-terminal
not starting.  I tracked that to gnome-terminal-server refusing to start
because of a non-UTF locale.

I ended up commenting out these two lines in
samuel@hpre:~$ egrep 'LANG|LC[_=]' .??* 2> /dev/null
 . . . .
.profile:# export LANG=C
.profile:# export LC_ALL=C
. . . .
.bashrc:# export LANG=en
.bashrc:# export LC_ALL=en

Problem solved.
-- 
Stephen Samuel http://www.bcgreen.com  Software, like love,
778-861-7641  grows when you give it away

Bug#943681: keepassxc: Resizing KeepassXC on KDE on intel video driver crashes Plasma

[Ivan]

Package: keepassxc
Version: 2.3.4+dfsg.1-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 Executing KeepassXC, opening the database.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Open database and try to resize the window on KDE.
   * What was the outcome of this action?
 KDE Plasma completely frozen, only mouse moving. Need to restart SDDM to 
get it back.
   * What outcome did you expect instead?
 Resize window.

[27436.083291] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure 
on pipe B (start=51173 end=51174) time 175 us, min 1431, max 1439, scanline 
start 1430, end 1446
[28814.602509] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure 
on pipe B (start=133816 end=133817) time 148 us, min 1431, max 1439, scanline 
start 1428, end 1441
   8.188923] DMAR: DRHD: handling fault status reg 2
[8.188932] DMAR: [DMA Write] Request device [02:00.0] fault addr 0 [fault 
reason 05] PTE Write access is not set




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

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

Versions of packages keepassxc depends on:
ii  libargon2-1   0~20171227-0.2
ii  libc6 2.28-10
ii  libgcrypt20   1.8.4-5
ii  libqt5core5a  5.11.3+dfsg1-1
ii  libqt5dbus5   5.11.3+dfsg1-1
ii  libqt5gui55.11.3+dfsg1-1
ii  libqt5network55.11.3+dfsg1-1
ii  libqt5widgets55.11.3+dfsg1-1
ii  libqt5x11extras5  5.11.3-2
ii  libsodium23   1.0.17-1
ii  libstdc++68.3.0-6
ii  libx11-6  2:1.6.7-1
ii  libxi62:1.7.9-1
ii  libxtst6  2:1.2.3-1
ii  libykpers-1-1 1.19.3-3+deb10u1
ii  libzxcvbn02.4+dfsg-2
ii  zlib1g1:1.2.11.dfsg-1

keepassxc recommends no packages.

keepassxc suggests no packages.

-- no debconf information

Bug#943682: Resizing KeepassXC crashes KDE Plasma

[M.]

Package: keepassxc
Version: 2.3.4+dfsg.1-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 Executing KeepassXC, opening the database.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Open database and try to resize the window on KDE.
   * What was the outcome of this action?
 KDE Plasma completely frozen, only mouse moving. Need to restart SDDM
to get it back.
   * What outcome did you expect instead?
 Resize window.

[27436.083291] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update
failure on pipe B (start=51173 end=51174) time 175 us, min 1431, max 1439,
scanline start 1430, end 1446
[28814.602509] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update
failure on pipe B (start=133816 end=133817) time 148 us, min 1431, max
1439, scanline start 1428, end 1441
   8.188923] DMAR: DRHD: handling fault status reg 2
[8.188932] DMAR: [DMA Write] Request device [02:00.0] fault addr 0
[fault reason 05] PTE Write access is not set




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

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

Versions of packages keepassxc depends on:
ii  libargon2-1   0~20171227-0.2
ii  libc6 2.28-10
ii  libgcrypt20   1.8.4-5
ii  libqt5core5a  5.11.3+dfsg1-1
ii  libqt5dbus5   5.11.3+dfsg1-1
ii  libqt5gui55.11.3+dfsg1-1
ii  libqt5network55.11.3+dfsg1-1
ii  libqt5widgets55.11.3+dfsg1-1
ii  libqt5x11extras5  5.11.3-2
ii  libsodium23   1.0.17-1
ii  libstdc++68.3.0-6
ii  libx11-6  2:1.6.7-1
ii  libxi62:1.7.9-1
ii  libxtst6  2:1.2.3-1
ii  libykpers-1-1 1.19.3-3+deb10u1
ii  libzxcvbn02.4+dfsg-2
ii  zlib1g1:1.2.11.dfsg-1

keepassxc recommends no packages.

keepassxc suggests no packages.

-- no debconf information

Bug#925833: Fixed upstream

[Aleksey Kravchenko]

Hello!

This bug duplicates upstream issue #142:
https://github.com/a2o/snoopy/issues/142

It is fixed by PR https://github.com/a2o/snoopy/pull/143

The fix commit (PR merge) is
https://github.com/a2o/snoopy/commit/360bb18e16ceaca16a22b94be9e17fd5f2184c01

I've tried to extract the patch from commit (patch attached), but
compilation started to fail with another warning:

cmdline.c: In function ‘snoopy_datasource_cmdline’:
cmdline.c:71:79: error: comparison between pointer and zero character
constant [-Werror=pointer-compare]
   71 | for (cmdLineArgCount=0 ;
*(snoopy_inputdatastorage->argv+cmdLineArgCount) != '\0' ;
cmdLineArgCount++);
 
|  
^~
cmdline.c:71:30: note: did you mean to dereference the pointer?
   71 | for (cmdLineArgCount=0 ;
*(snoopy_inputdatastorage->argv+cmdLineArgCount) != '\0' ;
cmdLineArgCount++);
  |  ^
cc1: all warnings being treated as errors

diff -Nur a/lib/inih/dev-update.sh b/lib/inih/dev-update.sh
--- a/lib/inih/dev-update.sh
+++ b/lib/inih/dev-update.sh
@@ -7,17 +7,27 @@
 set -e
 set -u
 GITORIGINURL="https://github.com/benhoyt/inih.git";
-GITORIGINREF="master"
+GITREF="master"
 TMPGITDIR="./_tmp-inih-git"
 DESTDIR="."
 DESTDIRSRC="./src"
 
 
 
+### Parse arguments
+#
+if [ "${1:-}" != "" ]; then
+GITREF="$1"
+fi
+echo "Using gitref: $GITREF"
+
+
+
 ### Clone the repo
 #
 rm -rf $TMPGITDIR
 git clone   $GITORIGINURL   $TMPGITDIR
+(cd $TMPGITDIR && git checkout $GITREF)
 
 
 
@@ -30,7 +40,7 @@
 
 ### Apply patches
 #
-patch -p3 < ./patches/0001-strip-value-quotes.diff
+patch -p0 < ./patches/0001-strip-value-quotes.diff
 
 
 
diff -Nur a/lib/inih/patches/0001-strip-value-quotes.diff 
b/lib/inih/patches/0001-strip-value-quotes.diff
--- a/lib/inih/patches/0001-strip-value-quotes.diff
+++ b/lib/inih/patches/0001-strip-value-quotes.diff
@@ -1,9 +1,7 @@
-diff --git a/lib/inih/src/ini.c b/lib/inih/src/ini.c
-index 27ca85b..2c015c8 100644
 a/lib/inih/src/ini.c
-+++ b/lib/inih/src/ini.c
-@@ -149,6 +149,17 @@ int ini_parse_stream(ini_reader reader, void* stream, 
ini_handler handler,
- #endif
+--- src/ini.c.orig 2018-12-26 21:08:15.289767000 +
 src/ini.c  2018-12-26 21:07:25.707778000 +
+@@ -187,6 +187,17 @@
+ value = lskip(value);
  rstrip(value);
  
 +/* Strip surrounding double and single quotes */
@@ -19,4 +17,4 @@
 +
  /* Valid name[=:]value pair found, call handler */
  strncpy0(prev_name, name, sizeof(prev_name));
- if (!handler(user, section, name, value) && !error)
+ if (!HANDLER(user, section, name, value) && !error)
diff -Nur a/lib/inih/SOURCE.txt b/lib/inih/SOURCE.txt
--- a/lib/inih/SOURCE.txt
+++ b/lib/inih/SOURCE.txt
@@ -1,3 +1,3 @@
 git-origin-url = 'https://github.com/benhoyt/inih.git'
-git-origin-ref = 'tags/r36-0-g5dbf5cb'
+git-origin-ref = 'tags/r42-0-g9d1af9d'
 patches-dir = 'patches/'
diff -Nur a/lib/inih/src/ini.c b/lib/inih/src/ini.c
--- a/lib/inih/src/ini.c
+++ b/lib/inih/src/ini.c
@@ -24,6 +24,12 @@
 #define MAX_SECTION 50
 #define MAX_NAME 50
 
+/* Used by ini_parse_string() to keep track of string parsing state. */
+typedef struct {
+const char* ptr;
+size_t num_left;
+} ini_parse_string_ctx;
+
 /* Strip whitespace chars off end of given string, in place. Return s. */
 static char* rstrip(char* s)
 {
@@ -64,7 +70,7 @@
 /* Version of strncpy that ensures dest (size bytes) is null-terminated. */
 static char* strncpy0(char* dest, const char* src, size_t size)
 {
-strncpy(dest, src, size);
+strncpy(dest, src, size - 1);
 dest[size - 1] = '\0';
 return dest;
 }
@@ -76,8 +82,14 @@
 /* Uses a fair bit of stack (use heap instead if you need to) */
 #if INI_USE_STACK
 char line[INI_MAX_LINE];
+int max_line = INI_MAX_LINE;
 #else
 char* line;
+int max_line = INI_INITIAL_ALLOC;
+#endif
+#if INI_ALLOW_REALLOC
+char* new_line;
+int offset;
 #endif
 char section[MAX_SECTION] = "";
 char prev_name[MAX_NAME] = "";
@@ -90,14 +102,40 @@
 int error = 0;
 
 #if !INI_USE_STACK
-line = (char*)malloc(INI_MAX_LINE);
+line = (char*)malloc(INI_INITIAL_ALLOC);
 if (!line) {
 return -2;
 }
 #endif
 
+#if INI_HANDLER_LINENO
+#define HANDLER(u, s, n, v) handler(u, s, n, v, lineno)
+#else
+#define HANDLER(u, s, n, v) handler(u, s, n, v)
+#endif
+
 /* Scan through stream line by line */
-while (reader(line, INI_MAX_LINE, stream) != NULL) {
+while (reader(line, max_line, stream) != NULL) {
+#if INI_ALLOW_REALLOC
+offset = strlen(line);
+while (offset == max_line - 1 && line[offset - 1] != '\n') {
+max_line *= 2;
+if (max_line > INI_MAX_LINE)
+max_line = INI_MAX_LINE;
+new_line = realloc(line, max_line);
+if (!new_line) {
+free(line);
+

Bug#938757: unrardll: diff for NMU version 0.1.3-3.1

[Sandro Tosi]

Control: tags 938757 + patch
Control: tags 938757 + pending


Dear maintainer,

I've prepared an NMU for unrardll (versioned as 0.1.3-3.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru unrardll-0.1.3/debian/changelog unrardll-0.1.3/debian/changelog
--- unrardll-0.1.3/debian/changelog	2019-03-02 18:36:50.0 -0500
+++ unrardll-0.1.3/debian/changelog	2019-10-27 18:44:32.0 -0400
@@ -1,3 +1,10 @@
+unrardll (0.1.3-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938757
+
+ -- Sandro Tosi   Sun, 27 Oct 2019 18:44:32 -0400
+
 unrardll (0.1.3-3) unstable; urgency=medium
 
   * update VCS and email fields
diff -Nru unrardll-0.1.3/debian/control unrardll-0.1.3/debian/control
--- unrardll-0.1.3/debian/control	2019-03-02 18:36:50.0 -0500
+++ unrardll-0.1.3/debian/control	2019-10-27 18:44:29.0 -0400
@@ -4,11 +4,8 @@
 Maintainer: Norbert Preining 
 Build-Depends: debhelper (>= 10),
dh-python,
-   python-all-dev,
python3-all-dev,
-   python-setuptools,
python3-setuptools,
-   python-pkgconfig,
python3-pkgconfig,
libunrar-dev
 Standards-Version: 4.2.1
@@ -17,12 +14,6 @@
 Vcs-Browser: https://github.com/norbusan/unrardll-debian
 Vcs-Git: https://github.com/norbusan/unrardll-debian.git
 
-Package: python-unrardll
-Architecture: any
-Depends: ${python:Depends}, ${misc:Depends}, ${shlibs:Depends}, libunrar5
-Description: Python wrapper for the unrar shared library
- Python library that provides access to libunrar
-
 Package: python3-unrardll
 Architecture: any
 Depends: ${python3:Depends}, ${misc:Depends}, ${shlibs:Depends}
diff -Nru unrardll-0.1.3/debian/rules unrardll-0.1.3/debian/rules
--- unrardll-0.1.3/debian/rules	2019-03-02 18:36:50.0 -0500
+++ unrardll-0.1.3/debian/rules	2019-10-27 18:44:12.0 -0400
@@ -3,5 +3,5 @@
 export PYBUILD_NAME = unrardll
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 

Bug#936321: comedilib: diff for NMU version 0.11.0-1.1

[Sandro Tosi]

Control: tags 936321 + patch
Control: tags 936321 + pending


Dear maintainer,

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

Regards.

diff -Nru comedilib-0.11.0/debian/changelog comedilib-0.11.0/debian/changelog
--- comedilib-0.11.0/debian/changelog	2018-12-30 18:32:36.0 -0500
+++ comedilib-0.11.0/debian/changelog	2019-10-27 17:56:26.0 -0400
@@ -1,3 +1,10 @@
+comedilib (0.11.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #936321
+
+ -- Sandro Tosi   Sun, 27 Oct 2019 17:56:26 -0400
+
 comedilib (0.11.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru comedilib-0.11.0/debian/control comedilib-0.11.0/debian/control
--- comedilib-0.11.0/debian/control	2018-12-30 17:57:06.0 -0500
+++ comedilib-0.11.0/debian/control	2019-10-27 17:54:48.0 -0400
@@ -17,7 +17,6 @@
fop,
libboost-program-options-dev,
libgsl-dev,
-   python-all-dev, 
python3-all-dev, 
libboost-dev, 
dh-autoreconf
@@ -61,19 +60,6 @@
  available in the comedi-source package, which also contains
  instructions on how to compile and install the modules.
 
-Package: python-comedilib
-Section: python
-Architecture: any
-Depends: ${misc:Depends},
- ${shlibs:Depends},
- ${python:Depends}
-Provides: ${python:Provides}
-Description: Python wrapper for Comedilib
- Comedilib is a library for using Comedi, a driver interface for data
- acquisition hardware.  See the libcomedi0 package for more information.
- .
- This package provides Python bindings to the comedi library.
-
 Package: python3-comedilib
 Section: python
 Architecture: any
diff -Nru comedilib-0.11.0/debian/python-comedilib.install comedilib-0.11.0/debian/python-comedilib.install
--- comedilib-0.11.0/debian/python-comedilib.install	2014-05-11 04:14:53.0 -0400
+++ comedilib-0.11.0/debian/python-comedilib.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python2*/dist-packages/*
diff -Nru comedilib-0.11.0/debian/rules comedilib-0.11.0/debian/rules
--- comedilib-0.11.0/debian/rules	2018-12-30 18:32:12.0 -0500
+++ comedilib-0.11.0/debian/rules	2019-10-27 17:56:26.0 -0400
@@ -4,7 +4,6 @@
 #export DH_VERBOSE=1
 include /usr/share/dpkg/pkg-info.mk
 
-PYTHONS  := $(shell pyversions -vr)
 PYTHONS3 := $(shell py3versions -vr)
 #ruby_ver = 1.8
 arch_name = $(subst linux-gnu,linux-,$(patsubst %linux-gnu,%linux,$(HOST)))
@@ -30,19 +29,6 @@
 configure-stamp:
 	dh_testdir
 	dh_autoreconf
-	for pyvers in ${PYTHONS}; \
-	do\
-		mkdir -p pybuild/$$pyvers; \
-		cp -Rl `ls . |grep -v pybuild|grep -v debian` pybuild/$$pyvers; \
-		(cd pybuild/$$pyvers; \
-		PYTHON="/usr/bin/python$$pyvers" ./configure \
-			--host=$(DEB_HOST_GNU_TYPE) \
-			--build=$(DEB_BUILD_GNU_TYPE) \
-			--prefix=/usr \
-			CFLAGS="$(CFLAGS)" \
-			CPPFLAGS="$(CPPFLAGS)" \
-			LDFLAGS="$(LDFLAGS)");\
-	done
 	for pyvers in ${PYTHONS3}; \
 	do\
 		mkdir -p pybuild/$$pyvers; \
@@ -84,15 +70,6 @@
 	dh_testdir
 	$(MAKE)
 	cd comedi-calibrate && $(MAKE)
-	for pyvers in ${PYTHONS};\
-	do\
-		rm -rf pybuild/$$pyvers/lib;\
-		(cd pybuild/$$pyvers;\
-		ln -s ../../lib .);\
-		(cd pybuild/$$pyvers/swig/python;\
-		$(MAKE);\
-		sed -i '1s/^/#!\/usr\/bin\/python\n/' comedi.py);\
-	done
 	for pyvers in ${PYTHONS3};\
 	do\
 		rm -rf pybuild/$$pyvers/lib;\
@@ -149,11 +126,6 @@
 		localstatedir=$(CURDIR)/debian/tmp/var
 	cd comedi-calibrate && $(MAKE) install prefix=$(CURDIR)/debian/tmp/usr
 
-	for pyvers in ${PYTHONS};\
-	do\
-		(cd pybuild/$$pyvers/swig/python;\
-		$(MAKE) DESTDIR=$(CURDIR)/debian/tmp install);\
-	done
 	mkdir -p $(CURDIR)/debian/tmp/usr/lib/python3/dist-packages/comedi
 	for pyvers in ${PYTHONS3};\
 	do\
@@ -181,7 +153,7 @@
 #	   do mv $$f $${f%.so}.$$ABITAG.so; done;)
 	mkdir -p debian/tmp/lib/udev/rules.d
 	cp debian/90-comedi.rules debian/tmp/lib/udev/rules.d/
-	chmod 644 debian/tmp/usr/lib/python*/dist-packages/comedi.py
+	chmod 644 debian/tmp/usr/lib/python*/dist-packages/comedi/comedi.py
 	mkdir -p debian/tmp/usr/share/doc/libcomedi-dev/demo
 	cp -a demo debian/libcomedi-dev/usr/share/doc/libcomedi-dev
 	rm -f debian/libcomedi-dev/usr/share/doc/libcomedi-dev/demo/Makefile*
@@ -209,7 +181,6 @@
 	dh_link
 	dh_strip --no-automatic-dbgsym
 	dh_compress --exclude=.c
-	dh_python2 -X python3
 	dh_python3
 	for pyvers in ${PYTHONS3};\
 	do\

Bug#943216: simple-scan: Python2 removal in sid/bullseye

[Jeremy Bicha]

I fixed this issue weeks ago in my branch

https://salsa.debian.org/jbicha/simple-scan/commits/minor-cleanup

It's frustrating that there has been no response to
https://bugs.debian.org/904168

Thanks,
Jeremy Bicha

Bug#943603:

[Cyril Richard]

I don't understand why this bug has come back.

The error is here:

checking how to run the C++ preprocessor... g++ -E
checking whether g++ supports C++11 features by default... yes
checking for OPENCV... no
checking for OPENCV... no
checking for OPENCV... no
configure: error: opencv not found. Not using some image processing.
tail -v -n \+0 config.log
==> config.log <==


because opencv 4.1.2 dropped the pkg-config file.
But opencv 4.1.2+dfsg-4 reintroduced the file (#942562) and now I can
compile with pbuilder and opencv 4.1.2 without any issue.

checking dependency style of g++... (cached) none
checking how to run the C++ preprocessor... g++ -E
checking whether g++ supports C++11 features by default... yes
checking for OPENCV... no
checking for OPENCV... no
checking for OPENCV... yes
checking for LIBRAW... yes
checking for LIBTIFF... yes
checking for jpeg_mem_src in -ljpeg... yes
checking for LIBPNG... yes

Bug#937456: Reopen

[Ondrej Novy]

Hi,

twisted needs Python 2 version (see #943582), reuploading and reopening bug.

-- 
Best regards
 Ondřej Nový

Bug#943680: lz4: CVE-2019-17543

[Salvatore Bonaccorso]

Source: lz4
Version: 1.9.1-2
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for lz4.

CVE-2019-17543[0]:
| LZ4 before 1.9.2 has a heap-based buffer overflow in LZ4_write32
| (related to LZ4_compress_destSize), affecting applications that call
| LZ4_compress_fast with a large input. (This issue can also lead to
| data corruption.) NOTE: the vendor states "only a few specific /
| uncommon usages of the API are at risk."


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-17543
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17543

I think for unstable moving to 1.9.2 is the best option. For buster
and stretch the issue is not worth a DSA, given this only affect very
specific and uncommon usages of the API.

Regards,
Salvatore

Bug#938347: reglookup: diff for NMU version 1.0.1+svn287-7.1

[Giovani Ferreira]

Hi Sandro,

Em 27/10/2019 15:04, Sandro Tosi escreveu:

> 
> I've prepared an NMU for reglookup (versioned as 1.0.1+svn287-7.1) and
> uploaded it to DELAYED/7. Please feel free to tell me if I
> should delay it longer.

Thanks for pointing this fix. I'm canceling upload because I will now 
update the packaging reglookup and will include your patch.

Regards,

-- 
Giovani Ferreira
0x78494EF72375A66C



signature.asc
Description: OpenPGP digital signature

Bug#943679: Apt fails to update ANY package if ONE source gives a malformed package list

[Chris]

Package: apt

Version: 1.8.3

Severity: serious

I have the following entries in my /etc/apt/sources.list:

deb https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/ disco main
deb-src https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/ disco main

Currently, apt-get update gives errors about these sources:

E: Encountered a section with no Package: header
E: Problem with MergeList
/var/lib/apt/lists/adoptopenjdk.jfrog.io_adoptopenjdk_deb_dists_disco_main_binary-amd64_Packages
E: The package lists or status file could not be parsed or opened.

However, I also get the same errors when I use apt-get install, apt-get
upgrade or apt-cache policy, even when the package I'm trying to install,
update or check the version of doesn't depend on adoptopenjdk. Shouldn't
apt still be able to process the package lists from unaffected sources, and
install and upgrade packages that don't come from or depend on the affected
sources?

Bug#943678: RM: rust-euclid-macros -- ROM; deprecated upstream, no reverse dependencies

[Andrej Shadura]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

euclid_macros has been deprecated and removed upstream, and as euclid
moves beyond 0.19, and 0.19 is patched with the upstream commit removing
euclid_macros dependency, it is no longer needed in Debian. Please
remove the package.

Thanks.

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl22CSkUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdLNdAf9ESy9uFuKN86Q/BMi8K0NGAt9nBsb
AUs/Ge0ziStO4bbywbkX5PtbtCmZR9oxAHTCR9WnkPdTJeHJKMkpGltTfmCUesgm
kxJ9eVHA1FNVr1vixA904EsVO+VzWz/nmjr1xoaWbXE/QloTQBaJHVLoV1vbajH0
JERYC+YqXgGgNvvUmGmCpaeuE2iYMBgII0cZTmuiMY6BsUFsGVyXV1YBh46pSfMz
XYJZLrt9icUuvhkUEBi+2f67Sj54b4kDFUM9m/T8gc1MgAbTnIArmdwwgXlwFGJE
RwhnpY9sXk4lTXm57T0YpQKFG7qFFqcCdD/KY4yHX2Y0gcPlPjRPYmkeng==
=oH5l
-END PGP SIGNATURE-

Bug#943677: please package insighttoolkit5 (5.0 and 5.1 beta 1 are out)

[Yaroslav Halchenko]

Source: insighttoolkit4
Version: 4.xxx
Severity: normal

According to https://github.com/InsightSoftwareConsortium/ITK/releases
5.1 beta 1 is out.

I am filing as "normal" and not "wishlist" since I am afraid I would need ITK5
to provide an updated package of ANTS package in Debian.

While preparing a new package,
https://github.com/InsightSoftwareConsortium/ITK/issues/1200#issuecomment-524836729
might be of relevance -- please build/ship with  Module_ITKReview On, or would
it be too much?


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

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

Bug#930526: incron creates zombie processes

[Alexander Brüning]

This is still an issue on 0.5.12-1

These commits apparently fix it

https://github.com/ar-/incron/commit/f45c2f5ac4baea99b48e99a713d1f4ec1854aa76

A thread on Stackoverflow suggests exiting with a non-zero exit code from
your shell scripts.

https://stackoverflow.com/questions/53722957/incrond-processes-with-shell-script-only-exit-if-script-exit-code-is-1

Bug#943676: ITP: opensurge -- Fun 2d retro platformer

[Andreas Ronnquist]

Package: wnpp
Severity: wishlist

* Package name: opensurge
  Version : 0.5.0-1
  Upstream Author : Alexandre Martins
* URL : https://opensurge2d.org/
* License : GPL3+
  Programming Lang: C
  Description : Fun 2d retro platformer

Open Surge is a fun 2D retro platformer inspired by old-school Sonic
games. It is also a game creation system that lets you unleash your
creativity! Play, create games & share!

I intend to maintain Open Surge in the Debian games team.

-- Andreas Rönnquist
gus...@debian.org

Bug#932408: linux-image-4.19.0-5-amd64: kernel panic not syncing

[Vcs Ccs]

On Tue, 23 Jul 2019 21:55:16 +0100 Terry Glanfield wrote:
> Thank you for the suggestion.
>
> I've installed 4.19.60 but that gives the same kernel panic.
>
> Where do I start in getting some more information to track what's causing
this?
>
> On Tue, 23 Jul 2019 14:40:59 +0200 Kinky Nekoboi
> wrote:
> > i had and have several problems with 4.19.37-5 ... an selfbuild vanila
> > kernel 4.19.60 with default options fixed most of them for me ...
> >
> > Debian should really push a newer 4.19.y kernel for buster
> >
> > Am 23.07.19 um 14:01 schrieb Terry Glanfield:
> > > This is still failing after an update to 4.19.37-5+deb10u1
> > >
> > > Any clues on where to start tracking this down?
> > >
> >
>
>

Hi Terry!

I had exactly the same problem.

A BIOS upgrade have solved it.

You can download new bios from here:
https://driverscollection.com/_447618233044da0d30a495b6285/Download-HP-Compaq-dc5800-Microtower-BIOS-v.4.02-Re.-A-free

Best regards:

vcs

Bug#936528: flask-principal: diff for NMU version 0.4.0-1.1

[Ondřej Nový]

Control: tags 936528 + patch
Control: tags 936528 + pending


Dear maintainer,

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

Regards.

diff -Nru flask-principal-0.4.0/debian/control 
flask-principal-0.4.0/debian/control
--- flask-principal-0.4.0/debian/control2013-08-22 02:46:55.0 
+0200
+++ flask-principal-0.4.0/debian/control2019-10-27 21:10:30.0 
+0100
@@ -3,28 +3,11 @@
 Homepage: https://flask-principal.readthedocs.org/
 Section: python
 Priority: optional
-Build-Depends: debhelper (>= 9), dh-python, python-all (>= 2.6.6-3),
- python-blinker, python-flask, python-nose,
- python-setuptools (>= 0.6b3), python3-all (>= 3.2), python3-flask,
+Build-Depends: debhelper (>= 9), dh-python,
+ python3-all (>= 3.2), python3-flask,
  python3-setuptools (>= 0.6b3)
 Standards-Version: 3.9.4
 
-Package: python-flask-principal
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Description: identity management for Flask
- Flask-Principal provides a very loose framework to tie in providers of two
- types of service, often located in different parts of a web application:
- .
-  - Authentication providers
-  - User information providers
- .
- For example, an authentication provider may be oauth, using Flask-OAuth and
- the user information may be stored in a relational database. Looseness of
- the framework is provided by using signals as the interface.
- .
- This is the Python 2 version of the package.
-
 Package: python3-flask-principal
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Nru flask-principal-0.4.0/debian/changelog 
flask-principal-0.4.0/debian/changelog
--- flask-principal-0.4.0/debian/changelog  2013-08-02 23:55:18.0 
+0200
+++ flask-principal-0.4.0/debian/changelog  2019-10-27 21:12:31.0 
+0100
@@ -1,3 +1,10 @@
+flask-principal (0.4.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Python 2 support (Closes: #936528).
+
+ -- Ondřej Nový   Sun, 27 Oct 2019 21:12:31 +0100
+
 flask-principal (0.4.0-1) unstable; urgency=low
 
   * Initial release. Closes: 718555
diff -Nru flask-principal-0.4.0/debian/rules flask-principal-0.4.0/debian/rules
--- flask-principal-0.4.0/debian/rules  2013-08-21 00:08:53.0 +0200
+++ flask-principal-0.4.0/debian/rules  2019-10-27 21:09:56.0 +0100
@@ -1,10 +1,8 @@
 #!/usr/bin/make -f
 
-export PYBUILD_DESTDIR_python2=debian/python-flask-principal/
-export PYBUILD_DESTDIR_python2-dbg=debian/python-flask-principal-dbg/
 export PYBUILD_DESTDIR_python3=debian/python3-flask-principal/
 export PYBUILD_DESTDIR_python3-dbg=debian/python3-flask-principal-dbg/
 export PYBUILD_DISABLE_python3=test
 
 %:
-   dh $@ --with python2,python3 --buildsystem=pybuild
+   dh $@ --with python3 --buildsystem=pybuild

Bug#937759: python-flask-httpauth: diff for NMU version 3.2.4-3.1

[Ondřej Nový]

Control: tags 937759 + pending


Dear maintainer,

I've prepared an NMU for python-flask-httpauth (versioned as 3.2.4-3.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-flask-httpauth-3.2.4/debian/control 
python-flask-httpauth-3.2.4/debian/control
--- python-flask-httpauth-3.2.4/debian/control  2018-10-24 15:27:30.0 
+0200
+++ python-flask-httpauth-3.2.4/debian/control  2019-10-27 20:37:21.0 
+0100
@@ -4,11 +4,8 @@
 Priority: optional
 Build-Depends: debhelper (>= 11),
dh-python,
-   python-all,
-   python-docutils,
-   python-flask,
-   python-setuptools,
python3-all,
+   python3-docutils,
python3-flask,
python3-setuptools,
python3-sphinx,
@@ -18,18 +15,6 @@
 Homepage: https://github.com/miguelgrinberg/flask-httpauth/
 Testsuite: autopkgtest-pkg-python
 
-Package: python-flask-httpauth
-Architecture: all
-Depends: ${misc:Depends},
- ${python:Depends},
-Provides: ${python:Provides},
-Suggests: python-flask-httpauth-doc,
-Description: Basic and Digest HTTP authentication for Flask (Python 2)
- Flask-HTTPAuth is a simple extension that provides Basic and Digest HTTP
- authentication for Flask routes.
- .
- This package installs the library for Python 2.
-
 Package: python3-flask-httpauth
 Architecture: all
 Depends: ${misc:Depends},
diff -Nru python-flask-httpauth-3.2.4/debian/changelog 
python-flask-httpauth-3.2.4/debian/changelog
--- python-flask-httpauth-3.2.4/debian/changelog2018-10-24 
15:27:30.0 +0200
+++ python-flask-httpauth-3.2.4/debian/changelog2019-10-27 
20:37:51.0 +0100
@@ -1,3 +1,10 @@
+python-flask-httpauth (3.2.4-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Python 2 support (Closes: #937759).
+
+ -- Ondřej Nový   Sun, 27 Oct 2019 20:37:51 +0100
+
 python-flask-httpauth (3.2.4-3) unstable; urgency=medium
 
   * debian/control: Put the Breaks/Replaces in the proper place; previous
diff -Nru python-flask-httpauth-3.2.4/debian/rules 
python-flask-httpauth-3.2.4/debian/rules
--- python-flask-httpauth-3.2.4/debian/rules2018-10-24 15:27:30.0 
+0200
+++ python-flask-httpauth-3.2.4/debian/rules2019-10-27 20:36:44.0 
+0100
@@ -3,7 +3,7 @@
 export PYBUILD_NAME = flask-httpauth
 
 %:
-   dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild
+   dh $@ --with python3,sphinxdoc --buildsystem=pybuild
 
 override_dh_auto_build: export http_proxy=127.0.0.1:9
 override_dh_auto_build: export https_proxy=127.0.0.1:9

Bug#922573: FTBFS against opencv 4.0.1 (exp)

[Ying-Chun Liu (PaulLiu)]

Hi all,


This pull request fixes this bug.

https://github.com/pjreddie/darknet/pull/1348


It is not yet merged to the upstream but I'll cherry-pick these patches
from this PR.

And will upload the new package soon.


Yours,
Paul




signature.asc
Description: OpenPGP digital signature

Bug#903090: Want to spot source-only binaries-NEW upload to Debian

[Russ Allbery]

Sean Whitton  writes:
> On Sat 26 Oct 2019 at 03:54PM -07, Russ Allbery wrote:

>> For what it's worth, I also always follow a practice of running dgit
>> sbuild before dgit push-source, so dgit could have detected the binary
>> packages that way in theory, but I'm not sure if that's common.

> Wouldn't dgit have to connect to the Internet in order to perform the
> detection?

> I'm not sure we want a build command performing any connections.

My thought process was more that since I've run dgit sbuild, there's a
*.changes file that lists all the binary packages that the source builds.
But there probably isn't any reasonable way for push-source to be able to
use that *.changes file to know the binary package list, since it doesn't
know that any *.changes file is from the same package that one is calling
push-source on.

-- 
Russ Allbery (r...@debian.org)  

Bug#943675: RFS: ogre-1.12/1.12.2+dfsg0-1 -- 3D Object-Oriented Graphics Rendering Engine (development files)

[Simon Schmeisser]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

I am looking for a sponsor for my package "ogre-1.12"

* Package name : ogre-1.12
Version : 1.12.2+dfsg0-1
Upstream Author : [fill in name and email of upstream]
* URL : https://ogre3d.org/
* License : MIT
* Vcs : https://salsa.debian.org/games-team/ogre-1.12
Section : libs

It builds those binary packages:

libogre-1.12-dev - 3D Object-Oriented Graphics Rendering Engine
(development files)
libogre-1.12 - 3D Object-Oriented Graphics Rendering Engine (libraries)
ogre-1.12-doc - 3D Object-Oriented Graphics Rendering Engine (documentation)
ogre-1.12-tools - 3D Object-Oriented Graphics Rendering Engine (tools)

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

https://mentors.debian.net/package/ogre-1.12

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

dget -x
https://mentors.debian.net/debian/pool/main/o/ogre-1.12/ogre-1.12_1.12.2+dfsg0-1.dsc

Changes since the last upload:

* New upstream version
* removed patches included upstream
* Bump Standards-Version to 4.4.1 (no changes needed)
* blender2ogre is now a separate script, removed it from here

Regards,

Simon Schmeißer

Bug#367515: Bug#749991: debian-installer: Wrong kernel in debian-installer package

[Holger Wansing]

Bugreport against kernel version mismatch, when using outdated or broken 
netboot images:


Since it's unlikely that we completely prevent this issue to happen, maybe we 
could at least change the error message, saying that the user should try 
another / a newer installation image?
(as already suggested in bug#367515)

It would be a good time for such template changing now...
Patch attached.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/debian/anna.templates b/debian/anna.templates
index 66677ee..dd9e49f 100644
--- a/debian/anna.templates
+++ b/debian/anna.templates
@@ -72,8 +72,12 @@ _Description: Continue the install without loading kernel modules?
  available in the archive.
  .
  If you're installing from a mirror, you can work around this problem by
- choosing to install a different version of Debian. The install will probably
- fail to work if you continue without kernel modules.
+ choosing to install a different version of Debian.
+ .
+ You can also try to use another/a newer installation image.
+ .
+ The install will probably fail to work if you continue without kernel
+ modules.
 
 Template: anna/retriever
 Type: string

Bug#794836: sphinxcontrib-youtube: diff for NMU version 1.0-1.1

[Ondřej Nový]

Control: tags 938541 + patch


Dear maintainer,

I've prepared an NMU for sphinxcontrib-youtube (versioned as 1.0-1.1). The diff
is attached to this message.

Regards.

diff -Nru sphinxcontrib-youtube-1.0/debian/control 
sphinxcontrib-youtube-1.0/debian/control
--- sphinxcontrib-youtube-1.0/debian/control2014-05-22 16:21:38.0 
+0200
+++ sphinxcontrib-youtube-1.0/debian/control2019-10-27 20:14:58.0 
+0100
@@ -4,9 +4,6 @@
 Maintainer: Thomi Richards 
 Build-Depends: debhelper (>= 9.0.0),
dh-python,
-   python-all (>= 2.6.6-3~),
-   python-setuptools,
-   python-setuptools,
python3-all,
python3-setuptools
 Standards-Version: 3.9.5
@@ -14,16 +11,6 @@
 X-Python3-Version: >= 3.2
 Homepage: http://bitbucket.org/birkenfeld/sphinx-contrib
 
-Package: python-sphinxcontrib.youtube
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Provides: ${python:Provides}
-Description: Sphinx "YouTube" extension
- This package contains the YouTube Sphinx extension. This extension enables
- you to insert YouTube videos in your Sphinx documents.
- .
- This is the Python 2 package.
-
 Package: python3-sphinxcontrib.youtube
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}
diff -Nru sphinxcontrib-youtube-1.0/debian/changelog 
sphinxcontrib-youtube-1.0/debian/changelog
--- sphinxcontrib-youtube-1.0/debian/changelog  2014-05-22 16:21:38.0 
+0200
+++ sphinxcontrib-youtube-1.0/debian/changelog  2019-10-27 20:16:04.0 
+0100
@@ -1,3 +1,11 @@
+sphinxcontrib-youtube (1.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Python 2 support (Closes: #938541).
+  * Fix compatibility with Python 3 (Closes: #794836).
+
+ -- Ondřej Nový   Sun, 27 Oct 2019 20:16:04 +0100
+
 sphinxcontrib-youtube (1.0-1) unstable; urgency=low
 
   * Initial release. Closes: #748912
diff -Nru sphinxcontrib-youtube-1.0/debian/patches/python3-fix.patch 
sphinxcontrib-youtube-1.0/debian/patches/python3-fix.patch
--- sphinxcontrib-youtube-1.0/debian/patches/python3-fix.patch  1970-01-01 
01:00:00.0 +0100
+++ sphinxcontrib-youtube-1.0/debian/patches/python3-fix.patch  2019-10-27 
20:16:04.0 +0100
@@ -0,0 +1,11 @@
+--- a/sphinxcontrib/youtube.py
 b/sphinxcontrib/youtube.py
+@@ -19,7 +19,7 @@
+ return int(m.group(1)), m.group(2) or "px"
+ 
+ def css(d):
+-return "; ".join(sorted("%s: %s" % kv for kv in d.iteritems()))
++return "; ".join(sorted("%s: %s" % kv for kv in d.items()))
+ 
+ class youtube(nodes.General, nodes.Element): pass
+ 
diff -Nru sphinxcontrib-youtube-1.0/debian/patches/series 
sphinxcontrib-youtube-1.0/debian/patches/series
--- sphinxcontrib-youtube-1.0/debian/patches/series 1970-01-01 
01:00:00.0 +0100
+++ sphinxcontrib-youtube-1.0/debian/patches/series 2019-10-27 
20:16:04.0 +0100
@@ -0,0 +1 @@
+python3-fix.patch
diff -Nru sphinxcontrib-youtube-1.0/debian/python-sphinxcontrib.youtube.docs 
sphinxcontrib-youtube-1.0/debian/python-sphinxcontrib.youtube.docs
--- sphinxcontrib-youtube-1.0/debian/python-sphinxcontrib.youtube.docs  
2014-05-22 16:21:38.0 +0200
+++ sphinxcontrib-youtube-1.0/debian/python-sphinxcontrib.youtube.docs  
1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-README.rst
\ Chybí znak konce řádku na konci souboru
diff -Nru sphinxcontrib-youtube-1.0/debian/rules 
sphinxcontrib-youtube-1.0/debian/rules
--- sphinxcontrib-youtube-1.0/debian/rules  2014-05-22 16:21:38.0 
+0200
+++ sphinxcontrib-youtube-1.0/debian/rules  2019-10-27 20:14:57.0 
+0100
@@ -7,7 +7,7 @@
 export PYBUILD_NAME=sphinxcontrib.youtube
 
 %:
-   dh $@ --with python2,python3 --buildsystem=pybuild
+   dh $@ --with python3 --buildsystem=pybuild
 
 get-orig-source:
hg clone https://bitbucket.org/birkenfeld/sphinx-contrib

Bug#943674: flask: please make the build reproducible

[Chris Lamb]

Source: flask
Version: 1.1.1-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

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

This is because it includes an absolute build directory in the
documentation as the "json_module" attribute points to a Python class/
module (which has a string representation including its path).

Patch attached that skips this (inherited) member from the
documentation.


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


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/0002-Reproducible-build.patch  1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/0002-Reproducible-build.patch  2019-10-27 
19:13:50.584954938 +
@@ -0,0 +1,14 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2019-10-27
+
+--- flask-1.1.1.orig/docs/api.rst
 flask-1.1.1/docs/api.rst
+@@ -31,6 +31,7 @@ Incoming Request Data
+ .. autoclass:: Request
+:members:
+:inherited-members:
++   :exclude-members: json_module
+ 
+.. attribute:: environ
+ 
--- a/debian/patches/series 2019-10-27 18:58:45.336245250 +
--- b/debian/patches/series 2019-10-27 19:13:49.740978529 +
@@ -1,2 +1,3 @@
 0001-Don-t-require-sphinxcontrib.log_cabinet-extension.patch
 disable_sphinx_issues.patch
+0002-Reproducible-build.patch

Bug#937740: python-evtx: diff for NMU version 0.6.1-1.1

[Ondřej Nový]

Control: tags 937740 + patch
Control: tags 937740 + pending


Dear maintainer,

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

Regards.

diff -Nru python-evtx-0.6.1/debian/control python-evtx-0.6.1/debian/control
--- python-evtx-0.6.1/debian/control2017-07-17 10:04:40.0 +0200
+++ python-evtx-0.6.1/debian/control2019-10-27 20:04:13.0 +0100
@@ -3,27 +3,19 @@
 Priority: optional
 Maintainer: Hilko Bengen 
 Build-Depends: debhelper (>= 10), dh-python,
- python, python3,
- python-setuptools, python3-setuptools,
- python-six, python3-six,
+ python3,
+ python3-setuptools,
+ python3-six,
 Standards-Version: 4.0.0
 Homepage: http://www.williballenthin.com/evtx/index.html
 Vcs-Git: git://anonscm.debian.org/collab-maint/python-evtx.git
 Vcs-Browser: 
http://anonscm.debian.org/?p=collab-maint/python-evtx.git;a=summary
 
-Package: python-evtx
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Description: parser for recent Windows Event Log files -- Python 2 version
- This module provides programmatic access to the File and Chunk
- headers, record templates, and event entries from Microsoft Windows
- Vista and later.
- .
- This package contains modules for Python 2.
-
 Package: python3-evtx
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
+Replaces: python-evtx (<< 0.6.1-1.1)
+Breaks: python-evtx (<< 0.6.1-1.1)
 Description: parser for recent Windows Event Log files -- Python 3 version
  This module provides programmatic access to the File and Chunk
  headers, record templates, and event entries from Microsoft Windows
diff -Nru python-evtx-0.6.1/debian/changelog python-evtx-0.6.1/debian/changelog
--- python-evtx-0.6.1/debian/changelog  2017-07-17 10:09:27.0 +0200
+++ python-evtx-0.6.1/debian/changelog  2019-10-27 20:04:13.0 +0100
@@ -1,3 +1,11 @@
+python-evtx (0.6.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Python 2 support (Closes: #937740).
+  * Move cli tools from python-evtx to python3-evtx binary package.
+
+ -- Ondřej Nový   Sun, 27 Oct 2019 20:04:13 +0100
+
 python-evtx (0.6.1-1) unstable; urgency=medium
 
   * New upstream version 0.6.1
diff -Nru python-evtx-0.6.1/debian/python-evtx.docs 
python-evtx-0.6.1/debian/python-evtx.docs
--- python-evtx-0.6.1/debian/python-evtx.docs   2016-12-19 10:03:21.0 
+0100
+++ python-evtx-0.6.1/debian/python-evtx.docs   1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-README.md
diff -Nru python-evtx-0.6.1/debian/rules python-evtx-0.6.1/debian/rules
--- python-evtx-0.6.1/debian/rules  2017-07-17 10:02:46.0 +0200
+++ python-evtx-0.6.1/debian/rules  2019-10-27 20:03:31.0 +0100
@@ -3,8 +3,4 @@
 export PYBUILD_NAME := evtx
 
 %:
-   dh $@ --with=python2,python3 --buildsystem=pybuild
-
-override_dh_auto_install:
-   dh_auto_install
-   rm -rf debian/python3-evtx/usr/bin
+   dh $@ --with=python3 --buildsystem=pybuild

Bug#914573: ITP: mongo-cxx-driver -- MongoDB C++ client library

[Christophe CT. TROPHIME]

Any news for this package?

It seems to be in NEW but cannot find it elsewhere

https://ftp-master.debian.org/new/mongo-cxx-driver_3.4.0-1.html

Best.
C

Bug#937161: notmuch: Python2 removal in sid/bullseye

[David Bremner]

Matthias Klose  writes:

> Package: src:notmuch
> Version: 0.29.1-2
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
>
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
>
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.
>
> - Convert your Package to Python3. This is the preferred option.  In
>   case you are providing a Python module foo, please consider dropping
>   the python-foo package, and only build a python3-foo package.  Please
>   don't drop Python2 modules, which still have reverse dependencies,
>   just document them.

Since the known rdeps have switched to the python3-notmuch binary
package, this should be doable. Please yell soon if you are depending on
python2-notmuch.

Bug#853750: hdfview: HDF5 files appear empty

[Chris Billington]

A further update, the Arch Linux AUR package is now building HDFView 3.1
successfully. I'm using it on Arch and it works. If Debian wants to
replicate this for their package, see the build script here:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=hdfview

The AUR package patches HDFview's build.xml file to unbundle java from the
resulting package and to remove what looks like a workaround for incorrect
library filenames that is not relevant on Arch. This may or may not be
identical on Debian, but may be a useful starting point for anyone wanting
to solve this bug.

Bug#938129: python-rencode: diff for NMU version 1.0.5-1.1

[Ondřej Nový]

Control: tags 938129 + patch
Control: tags 938129 + pending


Dear maintainer,

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

Regards.

diff -Nru python-rencode-1.0.5/debian/control 
python-rencode-1.0.5/debian/control
--- python-rencode-1.0.5/debian/control 2016-08-06 08:00:17.0 +0200
+++ python-rencode-1.0.5/debian/control 2019-10-27 19:56:19.0 +0100
@@ -2,8 +2,7 @@
 Section: python
 Priority: optional
 Maintainer: Dmitry Smirnov 
-Build-Depends: debhelper (>= 9), dh-python, python-all-dev, python3-all-dev
-  ,cython (>= 0.19)
+Build-Depends: debhelper (>= 9), dh-python, python3-all-dev
   ,cython3 (>= 0.19)
 X-Python-Version: >= 2.7
 Standards-Version: 3.9.8
@@ -11,16 +10,6 @@
 Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/python-rencode.git
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/python-rencode.git
 
-Package: python-rencode
-Architecture: any
-Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}
-Description: Python encoding library similar to bittorrent's bencode
- For complex, heterogeneous data structures with many small elements,
- r-encodings take significantly less space than b-encodings.
- This version of rencode is a complete rewrite in Cython in order to
- increase performance over the pure Python module written by Petru Paler,
- Connelly Barnes et al.
-
 Package: python3-rencode
 Architecture: any
 Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
diff -Nru python-rencode-1.0.5/debian/changelog 
python-rencode-1.0.5/debian/changelog
--- python-rencode-1.0.5/debian/changelog   2016-08-06 08:01:16.0 
+0200
+++ python-rencode-1.0.5/debian/changelog   2019-10-27 19:56:53.0 
+0100
@@ -1,3 +1,10 @@
+python-rencode (1.0.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Python 2 support (Closes: #938129).
+
+ -- Ondřej Nový   Sun, 27 Oct 2019 19:56:53 +0100
+
 python-rencode (1.0.5-1) unstable; urgency=medium
 
   * New upstream release [June 2016].
diff -Nru python-rencode-1.0.5/debian/rules python-rencode-1.0.5/debian/rules
--- python-rencode-1.0.5/debian/rules   2015-06-16 10:06:12.0 +0200
+++ python-rencode-1.0.5/debian/rules   2019-10-27 19:56:07.0 +0100
@@ -6,4 +6,4 @@
 export PYBUILD_NAME=rencode
 
 %:
-   dh $@ --parallel --with python2,python3 --buildsystem=pybuild
+   dh $@ --parallel --with python3 --buildsystem=pybuild

Bug#938181: python-socketio-client: diff for NMU version 0.6.5-0.2

[Ondřej Nový]

Control: tags 938181 + patch
Control: tags 938181 + pending


Dear maintainer,

I've prepared an NMU for python-socketio-client (versioned as 0.6.5-0.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-socketio-client-0.6.5/debian/control 
python-socketio-client-0.6.5/debian/control
--- python-socketio-client-0.6.5/debian/control 2016-01-12 13:13:24.0 
+0100
+++ python-socketio-client-0.6.5/debian/control 2019-10-27 19:51:02.0 
+0100
@@ -3,32 +3,17 @@
 Priority: optional
 Maintainer: Leo Iannacone 
 Build-Depends: debhelper (>= 9)
- , python-all (>= 2.6.6-3~)
+ , dh-python
  , python3-all
- , python-setuptools
  , python3-setuptools
 Standards-Version: 3.9.6
 Homepage: https://github.com/invisibleroads/socketIO-client
 Vcs-Git: git://anonscm.debian.org/collab-maint/python-socketio-client.git
 Vcs-Browser: 
http://anonscm.debian.org/gitweb/?p=collab-maint/python-socketio-client.git
 
-Package: python-socketio-client
-Architecture: all
-Depends: ${python:Depends}
- , ${misc:Depends}
- , python-requests
- , python-six
- , python-websocket
-Description: socket.io-client library for Python
- This package contains a socket.io client library
- for Python.
- .
- You can use it to write test code against your
- socket.io server.
-
 Package: python3-socketio-client
 Architecture: all
-Depends: ${python:Depends}
+Depends: ${python3:Depends}
  , ${misc:Depends}
  , python3-requests
  , python3-six
diff -Nru python-socketio-client-0.6.5/debian/changelog 
python-socketio-client-0.6.5/debian/changelog
--- python-socketio-client-0.6.5/debian/changelog   2016-01-12 
13:17:23.0 +0100
+++ python-socketio-client-0.6.5/debian/changelog   2019-10-27 
19:51:46.0 +0100
@@ -1,3 +1,12 @@
+python-socketio-client (0.6.5-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Python 2 support (Closes: #938181).
+  * Add dh-python to B-D.
+  * Change ${python:Depends} to ${python3:Depends} for Py3 binary.
+
+ -- Ondřej Nový   Sun, 27 Oct 2019 19:51:46 +0100
+
 python-socketio-client (0.6.5-0.1) unstable; urgency=medium
 
   * Non-maintainer Upload.
diff -Nru python-socketio-client-0.6.5/debian/python-socketio-client.docs 
python-socketio-client-0.6.5/debian/python-socketio-client.docs
--- python-socketio-client-0.6.5/debian/python-socketio-client.docs 
2016-01-12 13:17:22.0 +0100
+++ python-socketio-client-0.6.5/debian/python-socketio-client.docs 
1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-README.rst
-TODO.goals
diff -Nru python-socketio-client-0.6.5/debian/rules 
python-socketio-client-0.6.5/debian/rules
--- python-socketio-client-0.6.5/debian/rules   2016-01-12 13:13:24.0 
+0100
+++ python-socketio-client-0.6.5/debian/rules   2019-10-27 19:47:31.0 
+0100
@@ -8,18 +8,11 @@
 export PYBUILD_DISABLE=test
 
 %:
-   dh $@ --with python2,python3 --buildsystem=pybuild
+   dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_clean:
dh_auto_clean
rm -fr socketIO_client.egg-info
 
-override_dh_auto_install:
-   dh_auto_install
-   find debian/python-socketio-client -name "*SOURCES.txt" -delete
-
 override_dh_installchangelogs:
dh_installchangelogs -k CHANGES.rst
-
-override_dh_python2:
-   dh_python2 --no-guessing-deps

Bug#943673: RM: yubikey-piv-manager -- RoQA; Not in testing, not installable since 2019-09-11, Python 2 only

[Dmitry Shachnev]

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Dear FTP masters,

pyside was removed from unstable on 2019-09-11 and from testing later in
September.

yubikey-piv-manager depends on python-pyside so it is not installable since
then.

Also this package is Python 2 only.

Reverse dependencies checked with dak rm -Rn yubikey-piv-manager.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#943672: RM: python-ghost -- ROM; not in testing, not installable since 2019-09-11

[Dmitry Shachnev]

Package: ftp.debian.org
Severity: normal

Dear FTP masters,

pyside was removed from unstable on 2019-09-11 and from testing later in
September.

python3-ghost depends on python3-pyside so it is not installable since then.

The upstream source code also supports PyQt4 as alternative, however it is
also going to be removed soon.

I am filing this as ROM because the package is maintained by the Python
modules team which I am part of.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#727005: switch python bindings to python3

[Torsten Landschoff]

On 10/27/19 7:03 PM, Boruch Baum wrote:
> Hi Andreas,
>
> I don't foresee this working, because the package depends on swig to
> perform the heavy lifting for the python bindings, and debian currently
> packages only version 3 of swig, which as far as I can tell, does not
> support python3...

Actually, SWIG supports Python 3 for quite some time: Support was
introduced in SWIG 1.3.37

Source: https://github.com/swig/swig/blob/master/RELEASENOTES#L260

AFAICT, only some Python 3.8 specific changes are missing in SWIG 3.

> Version 4 of swig does seem to support python3, using a new command-line
> option `-py3`.

This option is only for type annocation support.

See http://swig.org/Doc3.0/SWIGDocumentation.html#Python_nn74

> @Torsten - Am I correct about python3 support in swig3? Is debian
> planning on soon updating the package to version 4 (ie. before debian
> drops support for python2)? Do you have any suggestions or pointers for
> us?

See above for Pointers wrt. Python 3 support. Matthias Klose uploaded an
NMU to add even Python 3.8 support to swig3.

I intend to upload swig4 soonish.

Greetings, Torsten

Bug#936873: Bug#727005: switch python bindings to python3

[Boruch Baum]

- Forwarded message from Boruch Baum  -

Date: Sun, 27 Oct 2019 14:03:58 -0400
From: Boruch Baum 
To: Andreas Henriksson , 727...@bugs.debian.org
Cc: Torsten Landschoff 
Subject: Bug#727005: switch python bindings to python3
User-Agent: NeoMutt/20180716

Hi Andreas,

I don't foresee this working, because the package depends on swig to
perform the heavy lifting for the python bindings, and debian currently
packages only version 3 of swig, which as far as I can tell, does not
support python3...

Version 4 of swig does seem to support python3, using a new command-line
option `-py3`.

I'm cc'ing  Torsten Landschoff  on this bug, as he
is llisted as the debian maintainer for the swig package.

@Torsten - Am I correct about python3 support in swig3? Is debian
planning on soon updating the package to version 4 (ie. before debian
drops support for python2)? Do you have any suggestions or pointers for
us?

On 2019-10-24 22:27, Andreas Henriksson wrote:
> Control: tags -1 + patch
>
> Hello,
>
> Please see attached patch with my naive attempt at porting libhdate
> to build python3 bindings instead of python2.
>
> This seems to work with the patch I'm about to post to the only
> reverse build-dependency bsdmainutils in #936244 but you should
> probably review it carefully anyway since I'm not really sure
> what I'm doing here.
>
> Regards,
> Andreas Henriksson


- End forwarded message -

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Bug#943671: claws-mail: GTK3 build

[sergio]

Source: claws-mail
Version: GTK3
Severity: normal

Dear Maintainer,

please make a gtk3 flavor build.

Bug#942232: maitreya: Should maitreya be removed from Debian?

[Olly Betts]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: maitreya -- RoQA; outdated; unmaintained; low popcon; 
RC-buggy

On Sun, Oct 13, 2019 at 08:46:29AM +1300, Olly Betts wrote:
> I wonder if it's time to remove the maitreya package:
> 
> * Last uploaded 2014-08-16 - over 5 years ago
> * Out of date compared to upstream (latest upstream is 8.0.1 released
>   2017-10-03)
> * Low popcon - maitreya inst:57 vote:11, fonts-maitreya inst:176 vote:0
> * RC buggy:
>   + Uninstallable in unstable (#940541)
>   + Blocker for the current wxwidgets3.0-gtk3 transition (#934097)
> * No reverse dependencies according to: dak rm -Rn maitreya
> * Maintainer seems unresponsive - only one of the 6 open bugs has a
>   maintainer response, and that was back in 2015.
> 
> If there are no objections within two weeks, I'll turn this into an RM
> bug. 

I've had no response, so doing so now.

Cheers,
Olly

Bug#943670: ITP: node-eslint-plugin-requirejs -- enforce code conventions for RequireJS modules with ESLint

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : node-eslint-plugin-requirejs
  Version  : 4.0.0
  Upstream Author  : Casey Visco 
* Url  : https://github.com/cvisco/eslint-plugin-requirejs
* Licenses : Expat
  Programming Lang : JavaScript

 eslint-plugin-requirejs provides a plugin for ESLint
 covering JavaScript code targeted RequireJS.
 .
 ESLint is a tool for identifying and reporting on patterns
 found in ECMAScript/JavaScript code.
 .
 RequireJS is a JavaScript file and module loader.

I plan to maintain this package in the JavaScript team, keeping 
debianization in following Git repository:

 https://salsa.debian.org/js-team/node-eslint-plugin-requirejs.git

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#938347: reglookup: diff for NMU version 1.0.1+svn287-7.1

[Sandro Tosi]

Control: tags 938347 + patch
Control: tags 938347 + pending


Dear maintainer,

I've prepared an NMU for reglookup (versioned as 1.0.1+svn287-7.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru reglookup-1.0.1+svn287/debian/changelog reglookup-1.0.1+svn287/debian/changelog
--- reglookup-1.0.1+svn287/debian/changelog	2018-09-06 14:50:58.0 -0400
+++ reglookup-1.0.1+svn287/debian/changelog	2019-10-27 14:00:40.0 -0400
@@ -1,3 +1,10 @@
+reglookup (1.0.1+svn287-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938347
+
+ -- Sandro Tosi   Sun, 27 Oct 2019 14:00:40 -0400
+
 reglookup (1.0.1+svn287-7) unstable; urgency=medium
 
   [ Raphaël Hertzog ]
diff -Nru reglookup-1.0.1+svn287/debian/control reglookup-1.0.1+svn287/debian/control
--- reglookup-1.0.1+svn287/debian/control	2018-09-06 14:45:37.0 -0400
+++ reglookup-1.0.1+svn287/debian/control	2019-10-27 13:59:37.0 -0400
@@ -11,7 +11,6 @@
jdupes,
libtalloc-dev,
libtalloc2,
-   python-all,
python3-all,
scons (>= 2.3),
 Standards-Version: 4.2.1
@@ -72,16 +71,6 @@
  provides the following commands: reglookup, reglookup-recover and
  reglookup-timeline.
 
-Package: python-pyregfi
-Architecture: all
-Section: python
-Depends: libregfi1 (>= ${binary:Version}), ${misc:Depends}, ${python:Depends}
-Recommends: reglookup-doc
-Description: Python Bindings for reglookup
- This package contains Python bindings to libregfi. There are the low-level
- data structures for winsec library and C API mappings for  accessing
- registry data structures.
-
 Package: python3-pyregfi
 Architecture: all
 Section: python
diff -Nru reglookup-1.0.1+svn287/debian/rules reglookup-1.0.1+svn287/debian/rules
--- reglookup-1.0.1+svn287/debian/rules	2018-08-29 14:18:38.0 -0400
+++ reglookup-1.0.1+svn287/debian/rules	2019-10-27 14:00:31.0 -0400
@@ -10,7 +10,7 @@
 export DEB_BUILD_HARDENING=1
 
 %:
-	dh $@ --buildsystem=pybuild --with python2,python3
+	dh $@ --buildsystem=pybuild --with python3
 
 override_dh_auto_build:
 	scons bin doc doc-devel

Bug#727005: switch python bindings to python3

[Boruch Baum]

Hi Andreas,

I don't foresee this working, because the package depends on swig to
perform the heavy lifting for the python bindings, and debian currently
packages only version 3 of swig, which as far as I can tell, does not
support python3...

Version 4 of swig does seem to support python3, using a new command-line
option `-py3`.

I'm cc'ing  Torsten Landschoff  on this bug, as he
is llisted as the debian maintainer for the swig package.

@Torsten - Am I correct about python3 support in swig3? Is debian
planning on soon updating the package to version 4 (ie. before debian
drops support for python2)? Do you have any suggestions or pointers for
us?

On 2019-10-24 22:27, Andreas Henriksson wrote:
> Control: tags -1 + patch
>
> Hello,
>
> Please see attached patch with my naive attempt at porting libhdate
> to build python3 bindings instead of python2.
>
> This seems to work with the patch I'm about to post to the only
> reverse build-dependency bsdmainutils in #936244 but you should
> probably review it carefully anyway since I'm not really sure
> what I'm doing here.
>
> Regards,
> Andreas Henriksson

Bug#938672: tmuxp: diff for NMU version 1.5.0a-1.1

[Ondřej Nový]

Control: tags 938672 + patch
Control: tags 938672 + pending


Dear maintainer,

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

Regards.

diff -Nru tmuxp-1.5.0a/debian/control tmuxp-1.5.0a/debian/control
--- tmuxp-1.5.0a/debian/control 2019-01-16 18:00:23.0 +0100
+++ tmuxp-1.5.0a/debian/control 2019-10-27 18:53:20.0 +0100
@@ -2,14 +2,14 @@
 Maintainer: Sebastien Delafond 
 Section: utils
 Priority: optional
-Build-Depends: dh-python, python-setuptools (>= 0.6b3), python3-setuptools, 
python-all (>= 2.6.6-3), python3-all, debhelper (>= 9),
-python-kaptan, python3-kaptan,
-python-libtmux (>= 0.8.0), python3-libtmux (>= 0.8.0),
-python-click, python3-click,
-python-flake8, python3-flake8,
-python-hypothesis, python3-hypothesis,
-python-isort, python3-isort,
-python-pytest, python3-pytest,
+Build-Depends: dh-python, python3-setuptools, python3-all, debhelper (>= 9),
+python3-kaptan,
+python3-libtmux (>= 0.8.0),
+python3-click,
+python3-flake8,
+python3-hypothesis,
+python3-isort,
+python3-pytest,
 tmux,
 vulture
 Standards-Version: 4.1.3
@@ -33,20 +33,6 @@
  .
  This is a dependency package
 
-Package: python-tmuxp
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Description: tmux session manager (Python 2)
- tmux session manager allowing both JSON and YAML configuration
- formats. Available features:
-  - allows both simple and very elaborate configs
-  - can store and load multiple sessions
-  - can custom startup scripts (such as installing project dependencies
-before loading tmux)
-  - session freezing: snapshot your current tmux layout, pane paths,
-and window/session names, and dump the result as a tmuxp
-configuration
-
 Package: python3-tmuxp
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends},
diff -Nru tmuxp-1.5.0a/debian/changelog tmuxp-1.5.0a/debian/changelog
--- tmuxp-1.5.0a/debian/changelog   2019-01-16 18:00:23.0 +0100
+++ tmuxp-1.5.0a/debian/changelog   2019-10-27 18:55:15.0 +0100
@@ -1,3 +1,10 @@
+tmuxp (1.5.0a-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Python 2 support (Closes: #938672).
+
+ -- Ondřej Nový   Sun, 27 Oct 2019 18:55:15 +0100
+
 tmuxp (1.5.0a-1) unstable; urgency=medium
 
   * New upstream release (Closes: #919167)
diff -Nru tmuxp-1.5.0a/debian/python-tmuxp.lintian-overrides 
tmuxp-1.5.0a/debian/python-tmuxp.lintian-overrides
--- tmuxp-1.5.0a/debian/python-tmuxp.lintian-overrides  2019-01-16 
18:00:23.0 +0100
+++ tmuxp-1.5.0a/debian/python-tmuxp.lintian-overrides  1970-01-01 
01:00:00.0 +0100
@@ -1 +0,0 @@
-python-tmuxp: wrong-section-according-to-package-name python-tmuxp => python
diff -Nru tmuxp-1.5.0a/debian/rules tmuxp-1.5.0a/debian/rules
--- tmuxp-1.5.0a/debian/rules   2019-01-16 18:00:23.0 +0100
+++ tmuxp-1.5.0a/debian/rules   2019-10-27 18:53:19.0 +0100
@@ -2,12 +2,11 @@
 
 d = $(CURDIR)/debian/tmuxp/usr/bin
 export PYBUILD_NAME=tmuxp
-export PYBUILD_AFTER_INSTALL_python2 = rm -rv {destdir}/usr/bin
 export PYBUILD_AFTER_INSTALL_python3 = mkdir -pv $d && mv -v 
{destdir}/usr/bin/tmuxp $d
 export HYPOTHESIS_DATABASE_FILE=$(CURDIR)/debian/hypothesis
 export PYBUILD_AFTER_TEST=rm -r {build_dir}/.hypothesis
 export PYBUILD_DISABLE=test
 
 %:
-   dh $@ --with python2,python3 --buildsystem=pybuild
+   dh $@ --with python3 --buildsystem=pybuild
 

Bug#938084: python-pyperclip: diff for NMU version 1.6.4-1.1

[Sandro Tosi]

Control: tags 938084 + patch
Control: tags 938084 + pending


Dear maintainer,

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

Regards.

diff -Nru python-pyperclip-1.6.4/debian/changelog python-pyperclip-1.6.4/debian/changelog
--- python-pyperclip-1.6.4/debian/changelog	2018-08-04 02:36:06.0 -0400
+++ python-pyperclip-1.6.4/debian/changelog	2019-10-27 13:51:48.0 -0400
@@ -1,3 +1,10 @@
+python-pyperclip (1.6.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938084
+
+ -- Sandro Tosi   Sun, 27 Oct 2019 13:51:48 -0400
+
 python-pyperclip (1.6.4-1) unstable; urgency=medium
 
   * New upstream version 1.6.4
diff -Nru python-pyperclip-1.6.4/debian/control python-pyperclip-1.6.4/debian/control
--- python-pyperclip-1.6.4/debian/control	2018-08-04 02:36:06.0 -0400
+++ python-pyperclip-1.6.4/debian/control	2019-10-27 13:51:13.0 -0400
@@ -2,23 +2,12 @@
 Section: python
 Priority: optional
 Maintainer: Sebastien Delafond 
-Build-Depends: debhelper (>= 9), python-setuptools, python-all, python3-all,
- python3-setuptools, python-pytest, xclip, xvfb, xauth
+Build-Depends: debhelper (>= 9), python3-all,
+ python3-setuptools, python3-pytest, xclip, xvfb, xauth
 Standards-Version: 4.1.3
 Homepage: https://github.com/asweigart/pyperclip
 Vcs-Git: https://salsa.debian.org/debian/python-pyperclip.git
 Vcs-Browser: https://salsa.debian.org/debian/python-pyperclip
-X-Python-Version: >= 2.7
-X-Python3-Version: >= 3.4
-
-Package: python-pyperclip
-Architecture: all
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}, xclip | xsel | python-gi | python-qt4
-Description: Cross-platform clipboard module for Python
- This module is a cross-platform Python module for copy and paste clipboard
- functions.
- .
- It currently only handles plaintext.
 
 Package: python3-pyperclip
 Architecture: all
diff -Nru python-pyperclip-1.6.4/debian/rules python-pyperclip-1.6.4/debian/rules
--- python-pyperclip-1.6.4/debian/rules	2018-08-04 02:36:06.0 -0400
+++ python-pyperclip-1.6.4/debian/rules	2019-10-27 13:51:41.0 -0400
@@ -3,13 +3,10 @@
 export PYBUILD_NAME=pyperclip
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_test:
-	# manually run tests for python2
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-	# xvfb-run python tests/test_pyperclip.py
-	# xvfb-run python tests/test_single.py
-	# # run manually tests for python3
-#	xvfb-run python3 tests/test_pyperclip.py
+	# run manually tests for python3
+	xvfb-run python3 tests/test_pyperclip.py
 endif

Bug#940985: dnsmasq WFTBFS: Accesses ECC curves directly

[Andreas Metzler]

Control: tags -1 + patch fixed-upstream

On 2019-09-23 Magnus Holmgren  wrote:
> Package: dnsmasq
> Version: 2.80-1
> Tags: upstream
> Severity: serious

> dnsmasq_ecdsa_verify() (in crypto.c) uses the addresses of nettle_secp_256r1 
> and nettle_secp_384r1 directly. As the comment in ecc-curve.h explains, "Due 
> to ABI subtleties, applications should not refer to these directly, but use 
> the below accessor functions." (nettle_get_secp_256r1() and 
> nettle_get_secp_384r1().) Indeed, dnsmasq will fail to build with nettle 
> 3.5.1.

This should be fixed in upstream GIT by commit
ab73a746a0d6fcac2e682c5548eeb87fb9c9c82e.

cu Andreas
diff -u dnsmasq-2.80/debian/changelog dnsmasq-2.80/debian/changelog
--- dnsmasq-2.80/debian/changelog
+++ dnsmasq-2.80/debian/changelog
@@ -1,3 +1,11 @@
+dnsmasq (2.80-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply ab73a746a0d6fcac2e682c5548eeb87fb9c9c82e from upstream GIT to fix
+build error against nettle 3.5. Closes: #940985
+
+ -- Andreas Metzler   Sun, 27 Oct 2019 18:40:21 +0100
+
 dnsmasq (2.80-1) unstable; urgency=low
 
* New upstream. (closes: #837602) (closes: #794640) (closes: #794636)
only in patch2:
unchanged:
--- dnsmasq-2.80.orig/src/crypto.c
+++ dnsmasq-2.80/src/crypto.c
@@ -275,6 +275,10 @@
   static struct ecc_point *key_256 = NULL, *key_384 = NULL;
   static mpz_t x, y;
   static struct dsa_signature *sig_struct;
+#if NETTLE_VERSION_MAJOR == 3 && NETTLE_VERSION_MINOR < 4
+#define nettle_get_secp_256r1() (&nettle_secp_256r1)
+#define nettle_get_secp_384r1() (&nettle_secp_384r1)
+#endif
   
   if (!sig_struct)
 {
@@ -294,7 +298,7 @@
 	  if (!(key_256 = whine_malloc(sizeof(struct ecc_point
 	return 0;
 	  
-	  nettle_ecc_point_init(key_256, &nettle_secp_256r1);
+	  nettle_ecc_point_init(key_256, nettle_get_secp_256r1());
 	}
   
   key = key_256;
@@ -307,7 +311,7 @@
 	  if (!(key_384 = whine_malloc(sizeof(struct ecc_point
 	return 0;
 	  
-	  nettle_ecc_point_init(key_384, &nettle_secp_384r1);
+	  nettle_ecc_point_init(key_384, nettle_get_secp_384r1());
 	}
   
   key = key_384;

Bug#936430: docker-pycreds: diff for NMU version 0.3.0-1.1

[Sandro Tosi]

Control: tags 936430 + patch
Control: tags 936430 + pending


Dear maintainer,

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

Regards.

diff -Nru docker-pycreds-0.3.0/debian/changelog docker-pycreds-0.3.0/debian/changelog
--- docker-pycreds-0.3.0/debian/changelog	2018-10-20 11:44:57.0 -0400
+++ docker-pycreds-0.3.0/debian/changelog	2019-10-27 13:45:51.0 -0400
@@ -1,3 +1,10 @@
+docker-pycreds (0.3.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #936430
+
+ -- Sandro Tosi   Sun, 27 Oct 2019 13:45:51 -0400
+
 docker-pycreds (0.3.0-1) unstable; urgency=medium
 
   * Set team address as Maintainer
diff -Nru docker-pycreds-0.3.0/debian/control docker-pycreds-0.3.0/debian/control
--- docker-pycreds-0.3.0/debian/control	2018-10-20 11:44:57.0 -0400
+++ docker-pycreds-0.3.0/debian/control	2019-10-27 13:45:24.0 -0400
@@ -7,30 +7,14 @@
 Build-Depends: debhelper (>= 9~),
dh-python,
golang-docker-credential-helpers,
-   python-all (>= 2.7),
python3-all (>= 3.3),
-# python-pytest,
 # python3-pytest,
python3-setuptools,
-   python-setuptools,
-   python-six,
python3-six
 Standards-Version: 4.1.3
 Homepage: https://github.com/shin-/dockerpy-creds
 Vcs-Git: https://salsa.debian.org/docker-compose-team/docker-pycreds.git
 Vcs-Browser: https://salsa.debian.org/docker-compose-team/docker-pycreds
-X-Python-Version: >= 2.7
-X-Python3-Version: >= 3.3
-
-Package: python-dockerpycreds
-Architecture: all
-Depends: ${misc:Depends},
- ${python:Depends},
- golang-docker-credential-helpers,
- python-six
-Description: Python bindings for the docker credentials store API
- This module provides bindings to use the native OS credential storage
- provided by the golang-docker-credential-helpers package.
 
 Package: python3-dockerpycreds
 Architecture: all
diff -Nru docker-pycreds-0.3.0/debian/rules docker-pycreds-0.3.0/debian/rules
--- docker-pycreds-0.3.0/debian/rules	2018-10-20 11:44:57.0 -0400
+++ docker-pycreds-0.3.0/debian/rules	2019-10-27 13:45:46.0 -0400
@@ -3,15 +3,12 @@
 export PYBUILD_NAME=dockerpycreds
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_test:
 
 # Tests are potentially interactive as they attempt to connect to the user keyring
 # therefore only run manually. Necessary dependencies:
-# python-pytest,
-# python-pytest-cov,
-# python-flake8,
 # python3-pytest,
 # python3-pytest-cov,
 # python3-flake8,

Bug#934844: python-trezor: diff for NMU version 0.9.0-1.1

[Ondřej Nový]

Control: tags 934844 + patch
Control: tags 938227 + patch


Dear maintainer,

I've prepared an NMU for python-trezor (versioned as 0.9.0-1.1). The diff
is attached to this message.

Regards.

diff -Nru python-trezor-0.9.0/debian/control python-trezor-0.9.0/debian/control
--- python-trezor-0.9.0/debian/control  2018-03-10 18:16:36.0 +0100
+++ python-trezor-0.9.0/debian/control  2019-10-27 18:41:20.0 +0100
@@ -8,13 +8,6 @@
  bash-completion,
  debhelper (>= 11),
  dh-python,
- python-all,
- python-ecdsa,
- python-hid,
- python-mnemonic,
- python-protobuf,
- python-requests,
- python-setuptools,
  python3-all,
  python3-ecdsa,
  python3-hid,
@@ -28,7 +21,7 @@
 
 Package: trezor
 Architecture: all
-Depends: python3-trezor, ${misc:Depends}, ${python:Depends}
+Depends: python3-trezor, ${misc:Depends}, ${python3:Depends}
 Section: utils
 Breaks: python-trezor (<< 0.7.16-1)
 Replaces: python-trezor (<< 0.7.16-1)
@@ -42,19 +35,6 @@
  This package contains the trezorctl binary for interacting with a TREZOR
  wallet, and the udev rules needed to make the device accessible.
 
-Package: python-trezor
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Breaks: electrum (<< 3.1.0)
-Description: library for communicating with TREZOR Bitcoin HW wallet (Python 2)
- No matter how unprotected your computer or internet connection might be,
- your coins always stay safe with TREZOR as it never exposes your private keys.
- TREZOR is an isolated environment for offline transaction signing and using
- a small display you can visually verify the transaction contents. That's why
- all operations using TREZOR are entirely safe.
- .
- This package contains the Python 2 version of python-trezor.
-
 Package: python3-trezor
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Nru python-trezor-0.9.0/debian/changelog 
python-trezor-0.9.0/debian/changelog
--- python-trezor-0.9.0/debian/changelog2018-03-10 18:16:36.0 
+0100
+++ python-trezor-0.9.0/debian/changelog2019-10-27 18:41:20.0 
+0100
@@ -1,3 +1,10 @@
+python-trezor (0.9.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Python 2 support (Closes: #938227, #934844).
+
+ -- Ondřej Nový   Sun, 27 Oct 2019 18:41:20 +0100
+
 python-trezor (0.9.0-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru python-trezor-0.9.0/debian/pydist-overrides 
python-trezor-0.9.0/debian/pydist-overrides
--- python-trezor-0.9.0/debian/pydist-overrides 2018-03-10 18:16:36.0 
+0100
+++ python-trezor-0.9.0/debian/pydist-overrides 1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-hidapi python-hid; PEP386
diff -Nru python-trezor-0.9.0/debian/python-trezor.pyremove 
python-trezor-0.9.0/debian/python-trezor.pyremove
--- python-trezor-0.9.0/debian/python-trezor.pyremove   2018-03-10 
18:16:36.0 +0100
+++ python-trezor-0.9.0/debian/python-trezor.pyremove   1970-01-01 
01:00:00.0 +0100
@@ -1 +0,0 @@
-bin/trezorctl
diff -Nru python-trezor-0.9.0/debian/rules python-trezor-0.9.0/debian/rules
--- python-trezor-0.9.0/debian/rules2018-03-10 18:16:36.0 +0100
+++ python-trezor-0.9.0/debian/rules2019-10-27 18:38:47.0 +0100
@@ -1,8 +1,7 @@
 #!/usr/bin/make -f
 
 export PYBUILD_NAME=trezor
-export PYBUILD_AFTER_INSTALL_python2=rm -r {destdir}/usr/bin
 export PYBUILD_AFTER_INSTALL_python3=mkdir -p debian/trezor/usr/bin && mv 
{destdir}/usr/bin/trezorctl debian/trezor/usr/bin
 
 %:
-   dh $@ --with python2,python3 --buildsystem=pybuild
+   dh $@ --with python3 --buildsystem=pybuild

Bug#942558: hurd: should return ENXIO instead of EIEIO in open()

[Samuel Thibault]

Control: tags -1 + pending

Hello,

Svante Signell, le ven. 18 oct. 2019 19:16:01 +0200, a ecrit:
> >  open(s, O_WRONLY | O_NONBLOCK);
> > 
> > On linux, it prints "No such device or address";
> > On the hurd vm, it prints "Computer bought the farm".
> > 
> Confirmed:
> ./test_fifo
> Computer bought the farm
> 
> And it does not seem to kill the translator:
> ps -feM|grep fifo
>  srs 11016   411  0:00.00 /hurd/fifo

Ok, I digged further, the problem was in ext2fs' diskfs_S_dir_lookup
when starting the fifo, it does get the ENXIO error, but along
development to implement the list of active translators, it got lost. I
have pushed a fix to upstream and the debian repo.

Thanks for the precise report!
Samuel

Bug#919533: python3-oauthlib: New version available

[Daniele Tricoli]

Hello Gennady,
sorry for this late reply, I was sure to have replied within few days.

On Thu, Jan 17, 2019 at 02:22:07AM +0300, Gennady Kovalev wrote:
> Package: python3-oauthlib
> Version: 2.1.0-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> oauthlib has new version released, that supports openid connect. Please update
> if it possible.

Upstream switched to pytest 4 before the freeze of Buster[¹] and I had
to disable tests at build time to have it in Buster.

Currently pytest 4 is still only in unstable so, although I'm going to
update oauthlib, I would not be able to backport it.

Kind regards,

[¹] 
https://github.com/oauthlib/oauthlib/commit/4bd39a770ce48d94ab8914463e20e9002e0b4869

-- 
  Daniele Tricoli 'eriol'
  https://mornie.org


signature.asc
Description: PGP signature

Bug#943669: RFS: backintime 1.2.1-2 -- simple backup/snapshot system [closes RC bugs]

[Fabian Wolff]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: j...@debian.org

Dear mentors,

I am looking for a sponsor for an upload of the 'backintime' package.

My changes are summarized in the latest changelog entry:

  backintime (1.2.1-2) unstable; urgency=medium

* Source-only reupload after the package has been in the NEW queue
  (due to backintime-qt).
* Change incorrect dependency on python3-dbus.mainloop.qt to the Qt 5
  python3-dbus.mainloop.pyqt5 (thanks to Michael Weghorn for pointing
  this out to me!) (Closes: #941686).
* Audit and update debian/copyright (Closes: #941984, #942155).
* Upgrade to Standards-Version 4.4.1 (no changes).
* Add additional backintime-qt_polkit.1.gz symlink to backintime.1.gz
  to silence the binary-without-manpage Lintian warning.

   -- Fabian Wolff   Sat, 19 Oct 2019 23:21:22 +0200

The package is available on Mentors and on Salsa:

  https://salsa.debian.org/jmw/pkg-backintime
  https://mentors.debian.net/package/backintime

Thank you very much for your help!

Best regards,
Fabian

Bug#942158: rdate: packaging needs a new licensing

[Eriberto]

Hi Thiago,

I think you can already relicense rdate.

Cheers,

Eriberto

Bug#943639: grisbi: text unreadable when GTK theme is Adwaita-Dark

[Ludovic Rousseau]

Le 27/10/2019 à 14:07, Roberto C. Sanchez a écrit :

Package: grisbi
Version: 1.2.2-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

When I changed my GTK theme to Adwaita-Dark much of the UI text became
unreadable.  It appears that some UI elements are specified for
particular colors while others are left with default values.  This
resulted in things like white text on white background, which was
impossible to read.

I may try to fix this myself, but I am not sure when I may find time.


I can reproduce the problem.
Screen copy attached.

I have no idea how to fix it. I reported the issue upstream in 
https://www.grisbi.org/bugsreports/view.php?id=1980

If you know how to fix it please share your knowledge. I may try to fix it 
myself.

Thanks

--
 Dr. Ludovic Rousseau

Bug#943668: Getting "Can't update Chromium" notifications

[積丹尼 Dan Jacobson]

Package: chromium
Version: 76.0.3809.100-1

I am seeing
https://bugs.chromium.org/p/chromium/issues/attachment?aid=418143&signed_aid=9UPqmf4gwZqsGKKmHEFHZw==
(I couldn't copy it,
https://bugs.chromium.org/p/chromium/issues/detail?id=1018582 )
I didn't try pushing its button.

Bug#943658: wmbattery FTCBFS: fails ./configure during clean

[Jeremy Sowden]

On 2019-10-27, at 16:38:50 +0100, Helmut Grohne wrote:
> Source: wmbattery
> Version: 2.51-2
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
>
> wmbattery fails to cross build from source, because the upstream
> Makefile configures for the build architecture when running make clean
> and this is what dh_auto_clean does ahead of a build. We can prevent
> that behaviour by carefully touching a few files that are to be removed
> anyway.
>
> Then it fails, because the Makefile runs the build architecture
> pkg-config. In theory, make has no business in running pkg-config in an
> autotools project. It should be using PKG_CHECK_MODULES instead.
>
> Please consider applying the attached patch.

I'll fix this upstream.

J.


signature.asc
Description: PGP signature

Bug#903090: Want to spot source-only binaries-NEW upload to Debian

[Sean Whitton]

Hello Russ,

On Sat 26 Oct 2019 at 03:54PM -07, Russ Allbery wrote:

> For what it's worth, I also always follow a practice of running dgit
> sbuild before dgit push-source, so dgit could have detected the binary
> packages that way in theory, but I'm not sure if that's common.

Wouldn't dgit have to connect to the Internet in order to perform the
detection?

I'm not sure we want a build command performing any connections.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#943667: buster-pu: package python-oslo.messaging/8.1.3-1 -> 8.1.4-1+deb10u1

[Thomas Goirand]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Dear Stable Release team,

I'd like to upgrade oslo.messaging to version 8.1.4-1+deb10u1. Indeed,
in versin 8.1.3, when a Rabbitmq server configured through transport_url
dies (or is turned off because of maintenance), the OpenStack clients,
which means, all services running on compute hosts, would attempt to
reconnect to the same RabbitMQ host. As a consequence, upgrading would
be *very* problematic, as the node wouldn't reconnect to another node
when we're upgrading one rabbit node (and as a consequence, turning off
the service there).

Attached is the debdiff for this change,
Please allow me to upgrade oslo.messaging in Buster,
Cheers,

Thomas Goirand (zigo)
diff -Nru python-oslo.messaging-8.1.3/debian/changelog 
python-oslo.messaging-8.1.4/debian/changelog
--- python-oslo.messaging-8.1.3/debian/changelog2019-05-17 
14:33:29.0 +0200
+++ python-oslo.messaging-8.1.4/debian/changelog2019-10-27 
18:01:18.0 +0100
@@ -1,3 +1,10 @@
+python-oslo.messaging (8.1.4-1+deb10u1) buster; urgency=medium
+
+  * New upstream point release, with an important fix:
+- Fix switch connection destination when a rabbitmq cluster node disappear.
+
+ -- Thomas Goirand   Sun, 27 Oct 2019 18:01:18 +0100
+
 python-oslo.messaging (8.1.3-1) unstable; urgency=medium
 
   * New upstream point release, which includes this fix:
diff -Nru python-oslo.messaging-8.1.3/doc/requirements.txt 
python-oslo.messaging-8.1.4/doc/requirements.txt
--- python-oslo.messaging-8.1.3/doc/requirements.txt2019-04-23 
09:50:41.0 +0200
+++ python-oslo.messaging-8.1.4/doc/requirements.txt2019-08-09 
21:54:57.0 +0200
@@ -3,7 +3,8 @@
 # process, which may cause wedges in the gate later.
 
 openstackdocstheme>=1.18.1 # Apache-2.0
-sphinx!=1.6.6,!=1.6.7,>=1.6.2 # BSD
+sphinx!=1.6.6,!=1.6.7,>=1.6.2,<2.0.0;python_version=='2.7' # BSD
+sphinx!=1.6.6,!=1.6.7,>=1.6.2;python_version>='3.4' # BSD
 reno>=2.5.0 # Apache-2.0
 
 # imported when the source code is parsed for generating documentation:
diff -Nru python-oslo.messaging-8.1.3/oslo_messaging/_drivers/amqpdriver.py 
python-oslo.messaging-8.1.4/oslo_messaging/_drivers/amqpdriver.py
--- python-oslo.messaging-8.1.3/oslo_messaging/_drivers/amqpdriver.py   
2019-04-23 09:50:41.0 +0200
+++ python-oslo.messaging-8.1.4/oslo_messaging/_drivers/amqpdriver.py   
2019-08-09 21:54:57.0 +0200
@@ -167,8 +167,34 @@
  'duration': duration})
 return
 
+def heartbeat(self):
+with self.listener.driver._get_connection(
+rpc_common.PURPOSE_SEND) as conn:
+self._send_reply(conn, None, None, ending=False)
+
+# NOTE(sileht): Those have already be ack in RpcListener IO thread
+# We keep them as noop until all drivers do the same
 def acknowledge(self):
-self._message_operations_handler.do(self.message.acknowledge)
+pass
+
+def requeue(self):
+pass
+
+
+class NotificationAMQPIncomingMessage(AMQPIncomingMessage):
+def acknowledge(self):
+def _do_ack():
+try:
+self.message.acknowledge()
+except Exception as exc:
+# NOTE(kgiusti): this failure is likely due to a loss of the
+# connection to the broker.  Not much we can do in this case,
+# especially considering the Notification has already been
+# dispatched. This *could* result in message duplication
+# (unacked msg is returned to the queue by the broker), but the
+# driver tries to catch that using the msg_id_cache.
+LOG.warning("Failed to acknowledge received message: %s", exc)
+self._message_operations_handler.do(_do_ack)
 self.listener.msg_id_cache.add(self.unique_id)
 
 def requeue(self):
@@ -178,12 +204,12 @@
 # msg_id_cache, the message will be reconsumed, the only difference is
 # the message stay at the beginning of the queue instead of moving to
 # the end.
-self._message_operations_handler.do(self.message.requeue)
-
-def heartbeat(self):
-with self.listener.driver._get_connection(
-rpc_common.PURPOSE_SEND) as conn:
-self._send_reply(conn, None, None, ending=False)
+def _do_requeue():
+try:
+self.message.requeue()
+except Exception as exc:
+LOG.warning("Failed to requeue received message: %s", exc)
+self._message_operations_handler.do(_do_requeue)
 
 
 class ObsoleteReplyQueuesCache(object):
@@ -256,7 +282,7 @@
 else:
 LOG.debug("received message with unique_id: %s", unique_id)
 
-self.incoming.append(AMQPIncomingMessage(
+self.incoming.append(self.message_cls(
 self,
 ctxt.to_dict(

Bug#943666: python3: Update Python Policy for removal of the Python 2 stack

[Neil Williams]

Package: python3
Version: 3.7.5-1
Severity: normal

As discussed on IRC and alongside the post to debian-devel-announce, please
review and include this amendment to the Debian Python Policy to cover
the removal of the Python 2 stack as outlined at 
https://wiki.debian.org/Python/2Removal

https://salsa.debian.org/codehelp/python3-defaults/commit/9b1dabbdc7105486e8a2132a100066e4c225a874

Thanks.

Bug#797077: didjvu: FTBFS: XMP tests fail

[Santiago Vila]

Hello Jakub and Daniel.

A problem very similar to the one reported here is happening right now
in buster (which I am still tracking for QA purposes). I've put a
bunch of build failures here from my own autobuilders:

https://people.debian.org/~sanvila/build-logs/didjvu/

The problem seems timezone-related and it's happening at least since
2019-10-09. I believe that the recent switch from summer time to
winter time (which happened today in Europe) may have something to do.

Please advise if it's ok to repoen this bug or a new one should be
filed instead.

Thanks.

Bug#942105: Can not active fcitx after Debian testing upgraded

[Gunnar Hjalmarsson]

For me the latest version of Fcitx works fine. I tested on Ubuntu, but 
AFAIK it should work the same way as on Debian. So it's possible that 
nobody who saw your bug report can reproduce the problem, and given that 
you provided very little information about the circumstances, it's hard 
to proceed.


So I think you need to provide some details. To start with, do you know 
that Fcitx is running?


ps aux | grep fcitx

If it is, and even if the shortcut doesn't work, can you switch to an 
Fcitx input method by clicking the Fcitx icon?


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#943545: Similar behaviour for me

[Paul Bryan]

Indeed, good catch, thanks. This is an issue with kernel/module, not
pulseaudio. From dmesg, in 5.3.0-1-amd64:
[4.892963] snd_hda_intel :00:1f.3: bound :00:02.0 (ops
i915_audio_component_bind_ops [i915])...[4.946159]
snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC257: line_outs=1
(0x14/0x0/0x0/0x0/0x0) type:speaker[4.946161] snd_hda_codec_realtek
hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)[4.946163]
snd_hda_codec_realtek hdaudioC0D0:hp_outs=1
(0x21/0x0/0x0/0x0/0x0)[4.946164] snd_hda_codec_realtek
hdaudioC0D0:mono: mono_out=0x0[4.946165] snd_hda_codec_realtek
hdaudioC0D0:inputs:[4.946166] snd_hda_codec_realtek
hdaudioC0D0:  Mic=0x19[4.946168] snd_hda_codec_realtek
hdaudioC0D0:  Internal Mic=0x12...[5.004050]
snd_hda_codec_generic hdaudioC0D2: autoconfig for Generic: line_outs=0
(0x0/0x0/0x0/0x0/0x0) type:line[5.004052] snd_hda_codec_generic
hdaudioC0D2:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)[5.004053]
snd_hda_codec_generic hdaudioC0D2:hp_outs=0
(0x0/0x0/0x0/0x0/0x0)[5.004054] snd_hda_codec_generic
hdaudioC0D2:mono: mono_out=0x0[5.004055] snd_hda_codec_generic
hdaudioC0D2:dig-out=0x3/0x0[5.004056] snd_hda_codec_generic
hdaudioC0D2:inputs:[5.005678] input: HDA Intel PCH Mic as
/devices/pci:00/:00:1f.3/sound/card0/input13[5.005721]
input: HDA Intel PCH Headphone as
/devices/pci:00/:00:1f.3/sound/card0/input14[5.005761]
input: HDA Intel PCH HDMI as
/devices/pci:00/:00:1f.3/sound/card0/input15...[9.053869]
snd_hda_intel :00:1f.3: azx_get_response timeout, switching to
polling mode: last cmd=0x20270503[   10.062212] snd_hda_intel
:00:1f.3: No response from codec, disabling MSI: last
cmd=0x20270503...[   11.065881] snd_hda_intel :00:1f.3: No response
from codec, resetting bus: last cmd=0x20270503...[   12.069891]
snd_hda_intel :00:1f.3: No response from codec, resetting bus: last
cmd=0x20370503[   13.077848] snd_hda_intel :00:1f.3: No response
from codec, resetting bus: last cmd=0x201f0500...[   15.129827]
snd_hda_intel :00:1f.3: No response from codec, resetting bus: last
cmd=0x20270503[   16.137898] snd_hda_intel :00:1f.3: No response
from codec, resetting bus: last cmd=0x20370503[   17.146104]
snd_hda_intel :00:1f.3: No response from codec, resetting bus: last
cmd=0x201f0500[   19.198203] snd_hda_intel :00:1f.3: No response
from codec, resetting bus: last cmd=0x20270503[   20.201883]
snd_hda_intel :00:1f.3: No response from codec, resetting bus: last
cmd=0x20370503[   21.213817] snd_hda_intel :00:1f.3: No response
from codec, resetting bus: last cmd=0x201f0500[   23.253873]
snd_hda_intel :00:1f.3: No response from codec, resetting bus: last
cmd=0x20270503[   24.265820] snd_hda_intel :00:1f.3: No response
from codec, resetting bus: last cmd=0x20370503[   25.273832]
snd_hda_intel :00:1f.3: No response from codec, resetting bus: last
cmd=0x201f0500[   27.321858] snd_hda_intel :00:1f.3: No response
from codec, resetting bus: last cmd=0x20270503[   28.329841]
snd_hda_intel :00:1f.3: No response from codec, resetting bus: last
cmd=0x20370503[   29.337825] snd_hda_intel :00:1f.3: No response
from codec, resetting bus: last cmd=0x201f0500[   31.389818]
snd_hda_intel :00:1f.3: No response from codec, resetting bus: last
cmd=0x20270503[   32.398045] snd_hda_intel :00:1f.3: No response
from codec, resetting bus: last cmd=0x20370503[   33.401863]
snd_hda_intel :00:1f.3: No response from codec, resetting bus: last
cmd=0x201f0500[   35.441874] snd_hda_intel :00:1f.3: No response
from codec, resetting bus: last cmd=0x20270503[   36.445960]
snd_hda_intel :00:1f.3: No response from codec, resetting bus: last
cmd=0x20370503[   37.465594] snd_hda_intel :00:1f.3: No response
from codec, resetting bus: last cmd=0x201f0500[   39.536476]
snd_hda_intel :00:1f.3: No response from codec, resetting bus: last
cmd=0x20270503[   40.556048] snd_hda_intel :00:1f.3: No response
from codec, resetting bus: last cmd=0x20370503[   41.574378]
snd_hda_intel :00:1f.3: No response from codec, resetting bus: last
cmd=0x201f0500[   43.621504] snd_hda_intel :00:1f.3: No response
from codec, resetting bus: last cmd=0x20270503[   44.637599]
snd_hda_intel :00:1f.3: No response from codec, resetting bus: last
cmd=0x20370503[   45.649795] snd_hda_intel :00:1f.3: No response
from codec, resetting bus: last cmd=0x201f0500[   47.700057]
snd_hda_intel :00:1f.3: No response from codec, resetting bus: last
cmd=0x20270503[   48.714610] snd_hda_intel :00:1f.3: No response
from codec, resetting bus: last cmd=0x20370503[   49.728817]
snd_hda_intel :00:1f.3: No response from codec, resetting bus: last
cmd=0x201f0500[   50.762801] snd_hda_intel :00:1f.3: No response
from codec, resetting bus: last cmd=0x20170500[   51.776502]
snd_hda_intel :00:1f.3: No response from codec, resetting b

Bug#943545: Similar behaviour for me

[Paul Bryan]

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942803 for kernel
bug.

Bug#943665: RM: haskell-cabal-file-th -- ROM; unused Haskell library

[Ilias Tsitsimpis]

Package: ftp.debian.org
Severity: normal

This Haskell library is unused, so please remove it.
See also #911570 for more information.

Thanks,

-- 
Ilias

Bug#943664: xserver-xorg-video-radeon 19.1 (ppc64) crash at startup: undefined symbol: exaGetPixmapDriverPrivate

[Ralf P.]

Package: xserver-xorg-video-radeon
Version: 1:19.0.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   on the ppc64 architecture the package 
   
  xserver-xorg-video-radeon_1%3a19.1.0-1_ppc64.deb

   crashes the xserver at startup.
   Xorg complains about an undefined symbol: exaGetPixmapDriverPrivate
   
   The bug occured after an update
   from:  xserver-xorg-video-radeon_1%3a19.0.1-1_ppc64.deb
   to:xserver-xorg-video-radeon_1%3a19.1.0-1_ppc64.deb

   To make sure the bug is in xserver-xorg-video-radeon 19.1.0-1
   I switched several times between these two versions of the package.
   As soon as version 19.0.1-1 is installed, Xorg runs well.


   Log from Xorg (in console):

  X.Org X Server 1.20.4
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.19.0-2-powerpc64 ppc64 Debian
  Current Operating System: Linux g5-1 4.19.28-rt16rp1 #1 SMP Tue Apr 30 
21:12:53 CEST 2019 ppc64
  Kernel command line: BOOT_IMAGE=/boot/vmlinux-4.19.28-rt16rp1 
root=UUID=0b889fec-98b2-4e34-ade1-1a43105f8417 ro
  Build Date: 05 March 2019  08:11:12PM
  xorg-server 2:1.20.4-1 (https://www.debian.org/support) 
  Current version of pixman: 0.36.0
  Before reporting problems, check http://wiki.x.org
  to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
  (++) from command line, (!!) notice, (II) informational,
  (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/home/ralf/.local/share/xorg/Xorg.1.log", Time: Sun Oct 
27 15:29:03 2019
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  (II) [KMS] Kernel modesetting enabled.
  /usr/lib/xorg/Xorg: symbol lookup error: 
/usr/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: 
exaGetPixmapDriverPrivate
  xinit: giving up
  xinit: unable to connect to X server: Connection refused
  xinit: server error
  

-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
:0a:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Cedar [Radeon HD 7350/8350 / R5 220] [1002:68fa]


DRM Information from dmesg:
--

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

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

Versions of packages xserver-xorg-video-radeon depends on:
ii  libc6  2.29-2
ii  libdrm-radeon1 2.4.99-1
ii  libgbm119.2.1-1
ii  libudev1   242-7
ii  xserver-xorg-core [xorg-video-abi-24]  2:1.20.4-1

xserver-xorg-video-radeon recommends no packages.

Versions of packages xserver-xorg-video-radeon suggests:
ii  firmware-amd-graphics  20180825+dfsg-1

-- no debconf information

Bug#943585: kwin-x11: kwin (?) causes extreme flickering and tear on login

[Brendon Higgins]

Hi,

I've encountered similar behaviour: black/residual/flickering windows 
making the desktop unusable after login. I also noticed some minor (white) 
flickering in SDDM prior to login, although it was still quite usable at that 
point. I'm running a mixed testing/unstable system, and am also using an 
Intel display chip (Dell Latitude; only on-board, no discrete graphics chip).

I found disabling OpenGL compositing with ALT+SHIFT+F12 worked around 
it at first, as did downgrading KDE+QT packages back to testing. I'm just 
trying this now with unstable packages again, and running the suggestsed 
'DRI_PRIME=1 kwin_x11 --replace'also seems to work - even as the new 
kwin_x11 instance brings OpenGL compositing back with it.

Peace,
Brendon

On Sun, 27 Oct 2019 01:15:10 +0200 Stefan Schwarzer 
 wrote:
> Package: kwin-x11
> Version: 4:5.14.5-1+b1
> Severity: important
> 
> Dear Maintainer,
> 
> I am following debian unstable, desktop X11/sddm/kde on a Lenovo laptop 
T460p.
> The nvidia graphics on the laptop is disabled in favor of the chipset 
graphics
> (Intel).
> 
> After the last upgrade (which was from testing to stable on the 25th 
October),
> I am experiencing a mostly unusable desktop. The login screen (sddm) 
comes up
> as expected,
> but right after login I get flickering black rectangles on the screen, which
> may
> cover up to 90% of its area. Windows mostly remain black or their content
> suddenly
> becomes visible he task bar remains black and I see other residuals of the 
kde
> splash
> screen where windows should be drawn or the background wallpaper be
> restored. Swithing to a VT; all seems ok, kwin, the desktop and applications
> are
> running.
> 
> So far, my only clue as to what may be going on is a workaroud: if I start a
> terminal
> via keyboard shortcut and issue blindly
> DRI_PRIME=1 kwin_x11 --replace
> then afterwards things behave mostly normally (Sometimes window 
contaent is
> still
> not correctly updated). I just picked this line up from older bug reports
> against kwin on the net without understanding what it does.
> 
> This is the output of kwin following this command in the hope that it helps
> 
> OpenGL vendor string:   Intel Open Source Technology Center
> OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530
> (Skylake GT2)
> OpenGL version string:  4.5 (Core Profile) Mesa 19.2.1
> OpenGL shading language version string: 4.50
> Driver: Intel
> GPU class:  Unknown
> OpenGL version: 4.5
> GLSL version:   4.50
> Mesa version:   19.2.1
> X server version:   1.20.4
> Linux kernel version:   5.3
> Requires strict binding:yes
> GLSL shaders:   yes
> Texture NPOT support:   yes
> Virtual Machine:no
> 
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386

Bug#939364: stretch-pu: package python-acme/0.28.0-1~deb9u2

[Harlan Lieberman-Berg]

On Sat, Oct 26, 2019 at 10:44 AM Adam D. Barratt
 wrote:
> I've included a draft for an SUA below; comments welcome.

The draft looks good.  I've included a couple of minor tweaks, just to
help indicate to users that there may be an operational impact, not
just broken tests in a CI system somewhere.

Other than that, +1, it's ready to ship!


-- 
Harlan Lieberman-Berg
~hlieberman
--- old.txt	2019-10-27 11:50:56.226063124 -0400
+++ new.txt	2019-10-27 11:53:02.668777460 -0400
@@ -11,12 +11,12 @@
 python-acme is part of an implementation of the ACME protocol, as used
 by the Let's Encrypt certification authority to issue TLS certificates.
 
-The ACME protocol has deprecated support for the use of unauthenicated
+The ACME protocol has deprecated support for the use of unauthenticated
 GET requests in favour of authenticated POST requests. On November 1st,
 Let's Encrypt's staging ACME v2 endpoint will stop supporting the older
 protocol, with the production endpoint following at a later point. The
 staging endpoint is used by applications such as certbot in order to
-perform tests before issuing a certificate.
+perform tests, including when testing renewals with `--dry-run`.
 
 This update moves python-acme to use the newer protocol.
 

Bug#943661: RM: ghc-testsuite -- ROM; not useful

[Ilias Tsitsimpis]

Package: ftp.debian.org
Severity: normal

This package is not useful as its sole purpose is to run GHC's testsuite
during build. Please remove it from the archive.

Thanks,

-- 
Ilias

Bug#943663: pyviennacl: should this package be removed?

[Sandro Tosi]

Source: pyviennacl
Severity: serious

Hello,
this package has 2 RC bugs un-addressed since more 3 and 4 years respectively!
Due to this, it is not in stable. There were only ever been 2 uploads of this
package, 5 years ago.  should we just remove it from debian?

if i dont hear back within a week with a good reason to keep this package, i'll
file for it's removal (it also has no rdeps)


-- 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#943662: libproguard-java: Does not support Java 11, the current default jdk

[Timo Kalliomäki]

Package: libproguard-java
Version: 6.0.3-1
Severity: important

Dear Maintainer,

the currently packaged version of proguard (6.0) is incompatible with the
currently packaged version of Java (11). Trying to run proguard with he 
option


  -libraryjars 
/usr/lib/jvm/java-11-openjdk-amd64/jmods/java.base.jmod(!**.jar;!module-info.class)


will output the following error:
  Reading library jmod 
[/usr/lib/jvm/java-11-openjdk-amd64/jmods/java.base.jmod] (filtered)
  Error: Can't read 
[/usr/lib/jvm/java-11-openjdk-amd64/jmods/java.base.jmod(;;!**.jar;!module-info.class)] 
(Can't process class 
[com/sun/security/cert/internal/x509/X509V1CertImpl.class] (Unsupported 
version number [55.0] (maximum 54.0, Java 10)))


Due to this version incompatibility, most usage of proguard is not possible.

Upstream has fixed the issue in version 6.1.

Br,
Timo

Bug#932812: crashes with java.lang.ClassCastException when opening PDFs

[Alowishus Devadander Abercrombie]

Confirming that pdftk-java version 3.0.6 from Sid fixes the bug.

On Tue, 3 Sep 2019 21:25:56 +0200 Johann Felix Soden  wrote:
> Hi Ryan, hi Jean-Baka,
>
> thanks for your bug report about the crash in pdftk-java. Would it be
> possible that you send me or upstream [1] a PDF document that produces
> this crash?
>
> It would also help if you could try the latest version 3.0.6 from Sid
> which has some bug fixes for similar errors.
>
> Best wishes,
>  Johann Felix
>
>
> [1] https://gitlab.com/pdftk-java/pdftk/issues
>
>
> --
> Johann Felix Soden, joh...@debian.org, DD
>
>
Sent from Mail for Windows 10

Bug#943217: pplpy: diff for NMU version 0.8.4-3

[Sandro Tosi]

Control: tags 943217 + patch


Dear maintainer,

I've prepared an NMU for pplpy (versioned as 0.8.4-3). The diff
is attached to this message.

apparently master is protected on git and i cant push to it..

Regards.

diff -Nru pplpy-0.8.4/debian/changelog pplpy-0.8.4/debian/changelog
--- pplpy-0.8.4/debian/changelog	2019-09-03 07:54:50.0 -0400
+++ pplpy-0.8.4/debian/changelog	2019-10-26 16:39:43.0 -0400
@@ -1,3 +1,10 @@
+pplpy (0.8.4-3) unstable; urgency=medium
+
+  * Team upload.
+  * Drop python2 support; Closes: #943217
+
+ -- Sandro Tosi   Sat, 26 Oct 2019 16:39:43 -0400
+
 pplpy (0.8.4-2) unstable; urgency=medium
 
   * Add upstream patch to fix doctests on 32 bit architectures.
diff -Nru pplpy-0.8.4/debian/control pplpy-0.8.4/debian/control
--- pplpy-0.8.4/debian/control	2019-09-03 07:54:24.0 -0400
+++ pplpy-0.8.4/debian/control	2019-10-26 16:23:58.0 -0400
@@ -6,7 +6,6 @@
 Build-Depends:
  debhelper (>= 11),
  dh-python (>= 3.20180313),
- cython (>= 0.26),
  cython3 (>= 0.26),
  libgmp-dev,
  libmpfr-dev,
@@ -14,15 +13,10 @@
  libppl-dev,
  libpari-dev,
  libjs-mathjax,
- python-all-dev,
  python3-all-dev,
- python-cysignals-pari (>= 1.8.1),
  python3-cysignals-pari (>= 1.8.1),
- python-gmpy2,
  python3-gmpy2,
- python-setuptools,
  python3-setuptools,
- python-sphinx,
  python3-sphinx,
 Standards-Version: 4.4.0
 X-Python3-Version: >= 3.7
@@ -30,16 +24,6 @@
 Vcs-Git: https://salsa.debian.org/science-team/pplpy.git
 Vcs-Browser: https://salsa.debian.org/science-team/pplpy
 
-Package: python-ppl
-Architecture: any
-Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}, python-cysignals-pari
-Description: Python interface to PPL -- Python 2
- A Python interface to the C++ Parma Polyhedra Library (PPL),
- which allows computations with polyhedra and grids, like mixed
- integer linear programming.
- .
- This package installs the library for Python 2.
-
 Package: python3-ppl
 Architecture: any
 Depends: ${python3:Depends}, ${shlibs:Depends}, ${misc:Depends}, python3-cysignals-pari
diff -Nru pplpy-0.8.4/debian/rules pplpy-0.8.4/debian/rules
--- pplpy-0.8.4/debian/rules	2019-09-03 07:54:24.0 -0400
+++ pplpy-0.8.4/debian/rules	2019-10-26 16:24:28.0 -0400
@@ -4,7 +4,7 @@
 export PYBUILD_NAME = ppl
 
 %:
-	dh $@ --with autoreconf --with python2,python3,sphinxdoc  --buildsystem=pybuild
+	dh $@ --with autoreconf --with python3,sphinxdoc  --buildsystem=pybuild
 
 override_dh_auto_build: export http_proxy=127.0.0.1:9
 override_dh_auto_build: export https_proxy=127.0.0.1:9
@@ -14,10 +14,6 @@
 
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS) $(DEB_BUILD_PROFILES)))
 override_dh_auto_test:
-	export PYTHONPATH=$(CURDIR)/.pybuild/cpython2_2.7_ppl/build && python2 tests/runtests.py
-	export PYTHONPATH=$(CURDIR)/.pybuild/cpython2_2.7_ppl/build && cd tests && python2 setup.py build_ext --inplace
-	export PYTHONPATH=$(CURDIR)/.pybuild/cpython2_2.7_ppl/build && cd tests && python2 setup2.py build_ext --inplace
-	export PYTHONPATH=$(CURDIR)/.pybuild/cpython2_2.7_ppl/build && cd tests && python2 -c "import testpplpy; testpplpy.test(); testpplpy.example(); import testpplpy2; testpplpy2.test(); testpplpy2.example()"
 	export PYTHONPATH=$(CURDIR)/.pybuild/cpython3_3.7_ppl/build && python3 tests/runtests.py
 	export PYTHONPATH=$(CURDIR)/.pybuild/cpython3_3.7_ppl/build && cd tests && python3 setup.py build_ext --inplace
 	export PYTHONPATH=$(CURDIR)/.pybuild/cpython3_3.7_ppl/build && cd tests && python3 setup2.py build_ext --inplace
diff -Nru pplpy-0.8.4/debian/tests/control pplpy-0.8.4/debian/tests/control
--- pplpy-0.8.4/debian/tests/control	2019-07-19 09:34:24.0 -0400
+++ pplpy-0.8.4/debian/tests/control	2019-10-26 16:24:40.0 -0400
@@ -1,7 +1,3 @@
-Tests: upstreamtestsuite2
-Depends: python-ppl
-Restrictions: allow-stderr
-
 Tests: upstreamtestsuite3
 Depends: python3-ppl
 Restrictions: allow-stderr
diff -Nru pplpy-0.8.4/debian/tests/upstreamtestsuite2 pplpy-0.8.4/debian/tests/upstreamtestsuite2
--- pplpy-0.8.4/debian/tests/upstreamtestsuite2	2019-07-19 09:34:24.0 -0400
+++ pplpy-0.8.4/debian/tests/upstreamtestsuite2	1969-12-31 19:00:00.0 -0500
@@ -1,3 +0,0 @@
-#!/bin/sh
-set -e
-python2 tests/runtests.py

Bug#942349: buster-pu: package ublock-origin/1.18.4+dfsg-2

[Michael Meskes]

> > {+  if dpkg --compare-versions "$2" lt 3.0-1; then+}
> > 
> > Why is the compared version there 3.0-1 when the extension is only
> > at
> > 1.22.2?
> 
> I don't know. I presume Michael wanted the preinst script to execute
> in
> any circumstances?

To me it looks like a copy&paste error that has gone unnoticed till
now. Sorry, this seems to be my bad, but I do not recall putting that
version number in. It certainly was not done on purpose.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL


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

Bug#943623: objects in libclangIndex.a are llvm ir bitcode

[Sylvestre Ledru]

Hello,

Le 27/10/2019 à 13:08, Shengjing Zhu a écrit :

Package: libclang-9-dev
Version: 1:9.0.0-1
Severity: serious
Control: affects -1 ccls

As for 1:9.0.0-1

ar x /usr/lib/llvm-9/lib/libclangIndex.a
file *.o

CodegenNameGenerator.cpp.o: LLVM IR bitcode
CommentToXML.cpp.o: LLVM IR bitcode
FileIndexRecord.cpp.o:  LLVM IR bitcode
IndexBody.cpp.o:LLVM IR bitcode
IndexDecl.cpp.o:LLVM IR bitcode
IndexingAction.cpp.o:   LLVM IR bitcode
IndexingContext.cpp.o:  LLVM IR bitcode
IndexSymbol.cpp.o:  LLVM IR bitcode
IndexTypeSourceInfo.cpp.o:  LLVM IR bitcode
USRGeneration.cpp.o:LLVM IR bitcode

While version 1:9-1 shows

CodegenNameGenerator.cpp.o: ELF 64-bit LSB relocatable, x86-64, version 1 
(SYSV), not stripped
CommentToXML.cpp.o: ELF 64-bit LSB relocatable, x86-64, version 1 
(SYSV), not stripped
FileIndexRecord.cpp.o:  ELF 64-bit LSB relocatable, x86-64, version 1 
(SYSV), not stripped
IndexBody.cpp.o:ELF 64-bit LSB relocatable, x86-64, version 1 
(SYSV), not stripped
IndexDecl.cpp.o:ELF 64-bit LSB relocatable, x86-64, version 1 
(SYSV), not stripped
IndexingAction.cpp.o:   ELF 64-bit LSB relocatable, x86-64, version 1 
(SYSV), not stripped
IndexingContext.cpp.o:  ELF 64-bit LSB relocatable, x86-64, version 1 
(SYSV), not stripped
IndexSymbol.cpp.o:  ELF 64-bit LSB relocatable, x86-64, version 1 
(SYSV), not stripped
IndexTypeSourceInfo.cpp.o:  ELF 64-bit LSB relocatable, x86-64, version 1 
(SYSV), not stripped
USRGeneration.cpp.o:ELF 64-bit LSB relocatable, x86-64, version 1 
(SYSV), not stripped

This causes GNU ld fails to link, errors are:

   /usr/lib/llvm-9/lib/libclangIndex.a error adding symbols: archive has no 
index; run ranlib to add one

I checked the upstream prebuild tarball, the objects in libclangIndex.a are ELF.

So I think this is bug in the Debian package, and is a regression from the 
version in testing.


Interesting!
A patch would be appreciated.

FYI, the change between 9-1 and 9.0.0-1 is that I am using the github project
and the new method to enable/disable projects

S

Bug#943660: groundhog: broken, outdated, embedded copy of AM_PATH_GLIB_2_0

[Helmut Grohne]

Source: groundhog
Version: 1.4-10
Severity: important
Tags: upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

groundhog fails to cross build from source, because it ships a broken,
oudated, embedded copy of AM_PATH_GLIB_2_0. Please remove this copy or
update and register it with the security tracker. Since the wrong
behaviour is fixed already, this bug comes without a patch. groundhog
just happens to ship a copy of the bug. The debian policy recommends not
using embedded copies if possible.

Helmut

Bug#166028: Gardens Court Musashikosugi for sale | Properties for Sale - Ken Corporation Ltd.

[web-request]

Property of Tokyo real estate from Ken Corporation Ltd.

Comment of This Property

茫茫人海相遇即是缘分，我也不知道我这封邮件发出去谁会收到，总之收到的就是缘分，那就加我QQ吧1298844073
最近刚分手，一个人不知道该怎么办，好难受啊，想找个人倾诉一下，加我QQ聊聊吧：1298844073 



Gardens Court Musashikosugi for sale | Properties for Sale - Ken Corporation 
Ltd.
https://www.kencorp.com/buy/forsale/search/results/188658.html




Note: This e-mail is an automatically generated message. Please do not use the 
auto reply function. To contact us again, please use this e-mail address: 
r-le...@kencorp.co.jp



Ken Corporation Ltd.

Tokyo
Tel: 81-(0)3-5413-5666
Email: r-le...@kencorp.co.jp

Yokohama
Tel: 81-(0)45-650-7895
Email: yoko...@kencorp.co.jp

URL: http://www.kencorp.com/
Facebook: http://www.facebook.com/kencorporation

Bug#943659: RM: haskell-attoparsec-enumerator -- ROM; unused Haskell library

[Ilias Tsitsimpis]

Package: ftp.debian.org
Severity: normal

This Haskell library is unmaintained and unused, so please remove it.
See also #939502 for more information.

Thanks,

-- 
Ilias

Bug#943648: tmux: FTBFS twice in a row: deletes cmd-parse.c which cannot be regenerated due to lack of yacc

[Romain Francoise]

Hi,

On Sun, Oct 27, 2019 at 3:21 PM Andreas Beckmann  wrote:
> The first build succeeds, but the subsequent distclean removes
> cmd-parse.c which cannot be regenerated due to yacc (bison) not being
> available.

Thanks for the report. Indeed this file is now generated and shipped
in the upstream tarball. I will add a build-depends on bison.