Bug#896464: Passing -V as default

[Niels Thykier]

Scott Kitterman:
> 
> 
> On April 23, 2018 10:03:45 PM UTC, "Lisandro Damián Nicanor Pérez Meyer" 
>  wrote:
>> If I understand correctly and, let's suppose, libQtFoo 5.10.2 is built
>> with a patched compat 12, then all applications rebuilt against 5.10.2
>> would require at very least 5.10.2 even if symbols files allowed it to
>> depend on a minor version.
>>

As far as I understand it, symbols files overrule shlibs.  I.e. if your
symbols files covers all the symbols required by the application, the
version will be derived from the symbols file.

dpkg-shlibdeps(1) seems to agree with this:

> DESCRIPTION
>dpkg-shlibdeps  calculates  shared  library  dependencies for 
> executables named in its arguments. The dependencies are added to the 
> substitution variables
>file debian/substvars as variable names shlibs:dependency-field where 
> dependency-field is a dependency field  name.  Any  other  variables  
> starting  with
>shlibs: are removed from the file.
> 
>dpkg-shlibdeps  has  two  possible  sources  of information to 
> generate dependency information. Either symbols files or shlibs files. For 
> each binary that
>dpkg-shlibdeps analyzes, it finds out the list of libraries that it's 
> linked with.  Then, for each library, it looks up either the symbols  file,  
> or  the
>shlibs  file  (if  the  former  doesn't  exist  or if 
> debian/shlibs.local contains the relevant dependency). Both files are 
> supposed to be provided by the
>library package and should thus be available as 
> /var/lib/dpkg/info/package.symbols or /var/lib/dpkg/info/package.shlibs. The 
> package name is identified in
>two steps: find the library file on the system (looking in the same 
> directories that ld.so would use), then use dpkg -S library-file to lookup 
> the package
>providing the library.

Note the "Then, for each library, it looks up either the symbols file,
or the shlibs file (if the former doesn't exist or if
debian/shlibs.local contains the relevant dependency)."  To me that
implies that the symbols file is preferred over the shlibs file when
both are present.


Further, in the concrete case, dh_makeshlibs will still allow you to
override the default when you happen to know that upstream has a sane
versioning scheme.

>> [...]
>>
>> The only thing I don't know from this is iif symbols files dependency
>> info is totally discarded or the dependency on qtbase-abi-x-y-z would
>> still be get trough them for packages using private API.
>>
>> Niels: like in [1] we use dpkg-symbols'
>> "alternative-dependency.template" to track packages using private API.
>> As long as this is kept then the change, I think, should be ok.
>>
>> [1]
>> 
> 
> If that's true, I doubt C++ symbols files  are worth the trouble.  
> 
> Scott K
> 

I think this case would still work as it used too (e.g. ok for .debs and
ignored for .udebs - but as I recall, qtbase-abi does not have any udebs
and should not be concerned by that)


Thanks,
~Niels

Bug#896115: RFS: python-cerberus/1.2-1 [ITP]

[Sergio Durigan Junior]

Control: tags -1 + moreinfo

On Friday, April 20 2018, I wrote:

> On Thursday, April 19 2018, Joel Cross wrote:
>
>>   Dear mentors,
>>
>>   I am looking for a sponsor for my package "python-cerberus"
>>
>>  * Package name: python-cerberus
>>Version : 1.2-1
>>Upstream Author : Nicola Iarocci 
>>  * URL : http://github.com/pyeve/cerberus
>>  * License : ISC
>>Section : python
>>
>>   It builds those binary packages:
>>
>> python-cerberus-doc - Documentation for python3-cerberus
>>  python3-cerberus - Lightweight, extensible data validation library for 
>> Python
>
> Thanks for the package, Joel.  A few nits, mostly small:
[...]

Hi there,

I saw you were accepted by the DPMT.  Great!  Now you can create a
repository under the python-team/modules namespace and just move your
stuff there.

I'm just marking this bug with the moreinfo tag so that it doesn't fall
into the cracks.  Let me know when you've addressed the comments, and we
can go from there.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#880494: D-I fails on odroid-hc1 devices: kernel doesn't find usb connected SATA and network card

[Jochen Sprickerhof]

Hi Andreas,

I had a similar problem with the Odroid XU4 which was fixed 
https://bugs.debian.org/895976. Given that both devices are really 
similar, I suspect that it probably fixes your device as well. Can you 
test it using the latest daily snapshot of the installer?


Cheers Jochen

* Andreas Jellinghaus  [2017-11-01 10:06]:

Package: debian-installer
Version: 20171008

To install Debian on Odroid-hc1 single board computer I managed to combine
firmware.none and the armhf images and modify the result with the latest
u-boot and network-console kernels and inject the vendor firmware blobs.
But the network card is not found, it seems an issue with the kernel.

Bypassing D-I with gparted/mkfs/multistrap/... the result is a fine booting
debian system, the only extra binaries are the firmware blobs around
u-boot, i.e. no modified debian packages were required.

How can I analyze the system and provide the necessary info to get all
required modules into the typical D-I powered install images?

I'm told the list of modules in D-I might be manually configured, thus here
is lsmod as a start:

What other information would be useful?

root@debian-odroid-h1:~# dpkg -l |grep linux-image
ii  linux-image-4.13.0-1-armmp-lpae 4.13.4-2   armhf
Linux 4.13 for ARMv7 multiplatform compatible SoCs supporting LPAE
ii  linux-image-armmp-lpae  4.13+86armhf
Linux for ARMv7 multiplatform compatible SoCs supporting LPAE (meta-package)
root@debian-odroid-h1:~# lsmod
Module  Size  Used by
cdc_ether  16384  0
usbnet 32768  1 cdc_ether
r8152  57344  0
mii16384  2 usbnet,r8152
exynosdrm  86016  0
analogix_dp36864  1 exynosdrm
drm_kms_helper139264  2 exynosdrm,analogix_dp
drm   299008  4 exynosdrm,analogix_dp,drm_kms_helper
exynos_adc 24576  0
pwm_samsung16384  2
industrialio   57344  1 exynos_adc
s3c2410_wdt16384  0
leds_pwm   16384  0
cpufreq_dt 16384  0
pwm_fan16384  0
ip_tables  24576  0
x_tables   24576  1 ip_tables
autofs440960  2
ext4  589824  2
crc16  16384  1 ext4
mbcache16384  1 ext4
jbd2  102400  1 ext4
crc32c_generic 16384  4
fscrypto   24576  1 ext4
ecb16384  0
xhci_plat_hcd  16384  0
xhci_hcd  176128  1 xhci_plat_hcd
dwc3  102400  0
udc_core   36864  1 dwc3
phy_generic16384  0
s2mps1157344  19
clk_s2mps1116384  0
dwc3_exynos16384  0
phy_exynos_mipi_video16384  0
phy_exynos_dp_video16384  0
i2c_exynos516384  0
ohci_exynos16384  0
ohci_hcd   45056  1 ohci_exynos
ehci_exynos16384  0
ehci_hcd   77824  1 ehci_exynos
usbcore   204800  9
ehci_exynos,usbnet,ehci_hcd,cdc_ether,xhci_plat_hcd,ohci_hcd,ohci_exynos,r8152,xhci_hcd
dw_mmc_exynos  16384  0
dw_mmc_pltfm   16384  1 dw_mmc_exynos
dw_mmc 36864  2 dw_mmc_pltfm,dw_mmc_exynos
usb_common 16384  3 udc_core,usbcore,dwc3
phy_exynos_usb220480  2
phy_exynos5_usbdrd 16384  4


Some details frm the boot log:
root@debian-odroid-h1:~# dmesg |grep -i -E "usb|hci|exynos|815|hub"
[0.010515] Exynos MCPM support installed
[0.109738] EXYNOS5420 PMU initialized
[5.478185] exynos5_usb3drd_phy 1210.phy: 1210.phy supply vbus
not found, using dummy regulator
[5.492258] exynos5_usb3drd_phy 1210.phy: 1210.phy supply
vbus-boost not found, using dummy regulator
[5.492315] usbcore: registered new interface driver usbfs
[5.492459] usbcore: registered new interface driver hub
[5.492769] usbcore: registered new device driver usb
[5.496834] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[5.498256] ehci-exynos: EHCI EXYNOS driver
[5.499238] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[5.500351] ohci-exynos: OHCI EXYNOS driver
[5.540049] dwmmc_exynos 1220.mmc: IDMAC supports 32-bit address
mode.
[5.546324] dwmmc_exynos 1220.mmc: Using internal DMA controller.
[5.552121] dwmmc_exynos 1220.mmc: Version ID is 250a
[5.557500] dwmmc_exynos 1220.mmc: DW MMC controller at irq 73,64
bit host data width,64 deep fifo
[5.567483] dwmmc_exynos 1222.mmc: IDMAC supports 32-bit address
mode.
[5.573999] dwmmc_exynos 1222.mmc: Using internal DMA controller.
[5.579904] dwmmc_exynos 1222.mmc: Version ID is 250a
[5.585305] dwmmc_exynos 1222.mmc: DW MMC controller at irq 74,64
bit host data width,64 deep fifo
[5.594932] samsung-usb2-phy 1213.phy: 1213.phy supply vbus not
found, using dummy regulator
[5.604806] exynos-ehci 

Bug#896716: libnetfilter-conntrack3: Event filtering does not take effect on MIPS.

[Phil]

Package: libnetfilter-conntrack3
Version: 1.0.6-2
Severity: normal
Tags: upstream

Dear Maintainer,

Attaching a filter to a conntrack handle has no effect when compiled/run on a
MIPS machine.

I have included the source of a test case demonstrating the issue which prints a
summary when the state of an applicable connection changes. The filter applied
should ensure the callback is only called for TCP connections.

This works as expected on an x64 machine, but on a MIPS machine the filter has
no effect, the callback is triggered for all connections.

I have tried different filter types other than NFCT_FILTER_L4PROTO with the same
outcome.

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: mips

Kernel: Linux 4.9.0-6-4kc-malta
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libnetfilter-conntrack3 depends on:
ii  libc6  2.24-11+deb9u3
ii  libmnl01.0.4-2
ii  libnfnetlink0  1.0.1-3

libnetfilter-conntrack3 recommends no packages.

libnetfilter-conntrack3 suggests no packages.

-- no debconf information
#include 
#include 
#include 

static int cb(enum nf_conntrack_msg_type type, struct nf_conntrack *ct, void 
*data) {
char buf[1024];

nfct_snprintf(buf, sizeof(buf), ct, type, NFCT_O_PLAIN, NFCT_OF_TIME);
printf("%s\n", buf);

return NFCT_CB_CONTINUE;
}

int main() {
struct nfct_handle *h = nfct_open(CONNTRACK, NFCT_ALL_CT_GROUPS);
if (!h) {
perror("nfct_open");
return 1;
}

struct nfct_filter *filter = nfct_filter_create();
if (!filter) {
perror("nfct_create_filter");
return 1;
}

nfct_filter_add_attr_u32(filter, NFCT_FILTER_L4PROTO, IPPROTO_TCP);

if (nfct_filter_attach(nfct_fd(h), filter) == -1) {
perror("nfct_filter_attach");
return 1;
}

nfct_callback_register(h, NFCT_T_ALL, cb, NULL);
nfct_catch(h);
nfct_filter_destroy(filter);
nfct_close(h);
}

Bug#896715: Modern initial negotiation failed

[Stéphane Glondu]

Package: nbd-client
Version: 1:3.16.2-1
Severity: important

Dear Maintainer,

On the client (Debian testing):

steph@korell:~$ nbd-client -l 192.168.42.1
Negotiation: ..
export

In the server's logs (Debian stretch):

Apr 24 06:22:44 sark nbd_server[17422]: Spawned a child process
Apr 24 06:22:44 sark nbd_server[19435]: Session terminated by client
Apr 24 06:22:44 sark nbd_server[19435]: Exiting.
Apr 24 06:22:44 sark nbd_server[19435]: Modern initial negotiation failed
Apr 24 06:22:44 sark nbd_server[17422]: Child exited with 1

Cheers,

-- 
Stéphane


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

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

Versions of packages nbd-client depends on:
ii  debconf [debconf-2.0]  1.5.66
ii  libc6  2.27-3
ii  libgnutls303.5.18-1

nbd-client recommends no packages.

nbd-client suggests no packages.

-- Configuration Files:
/etc/nbdtab changed [not included]

-- debconf information:
  nbd-client/no-auto-config:
  nbd-client/killall_set:

Bug#896714: RFS: cavestory-nx/1.0.0-1 [ITP] -- NXEngine is a Cave Story game engine clone

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "cavestory-nx"

 * Package name: cavestory-nx
   Version : 1.0.0-1
   Upstream Author : Carlos Donizete Froes 
 * URL : https://github.com/coringao/cavestory-nx
 * License : GPL-3+
   Section : contrib/games

  It builds those binary packages:

  cavestory-nx - NXEngine is a Cave Story game engine clone
  cavestory-nx-data - NXEngine is a Cave Story game engine clone (data files)

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

  https://mentors.debian.net/package/cavestory-nx

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

  dget -x 
https://mentors.debian.net/debian/pool/contrib/c/cavestory-nx/cavestory-nx_1.0.0-1.dsc

  More information about Cave Story NX can be obtained from 
https://github.com/coringao/cavestory-nx.

  Regards,
   Carlos Donizete Froes [a.k.a coringao]

Bug#896713: gamine FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: gamine
Version: 1.5-2
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

gamine fails to cross build from source, because it uses the build
architecture pkg-config and thus fails finding gtk, which is only
requested for the host architecture by Build-Depends. Making pkg-config
substitutable is all that is necessary here as dh_auto_build
automatically supplies the host pkg-config. After doing so, gamine cross
builds successfully. Please consider applying the attached patch.

Helmut
Index: gamine-1.5/Makefile
===
--- gamine-1.5.orig/Makefile
+++ gamine-1.5/Makefile
@@ -10,10 +10,11 @@
 LOCALEDIR = $(DATADIR)/locale
 MANDIR = $(DATADIR)/man/man6
 
+PKG_CONFIG ?= pkg-config
 CFLAGS = -Wall -g `dpkg-buildflags --get CFLAGS`
-CPPFLAGS = $(shell pkg-config --cflags gtk+-3.0 cairo glib-2.0 gstreamer-1.0)  -DDATADIR=\""$(PKGDATADIR)"\"  -DLOCALDIR=\""$(LOCALEDIR)"\" -DSYSCONFDIR=\""$(SYSCONFDIR)"\"
+CPPFLAGS = $(shell $(PKG_CONFIG) --cflags gtk+-3.0 cairo glib-2.0 gstreamer-1.0)  -DDATADIR=\""$(PKGDATADIR)"\"  -DLOCALDIR=\""$(LOCALEDIR)"\" -DSYSCONFDIR=\""$(SYSCONFDIR)"\"
 CPPFLAGS += `dpkg-buildflags --get CPPFLAGS`
-LDLIBS = $(shell pkg-config --libs gtk+-3.0 cairo glib-2.0 gstreamer-1.0)  -DDATADIR=\""$(PKGDATADIR)"\"  -DLOCALDIR=\""$(LOCALEDIR)"\" -DSYSCONFDIR=\""$(SYSCONFDIR)"\" -lm
+LDLIBS = $(shell $(PKG_CONFIG) --libs gtk+-3.0 cairo glib-2.0 gstreamer-1.0)  -DDATADIR=\""$(PKGDATADIR)"\"  -DLOCALDIR=\""$(LOCALEDIR)"\" -DSYSCONFDIR=\""$(SYSCONFDIR)"\" -lm
 LDFLAGS = `dpkg-buildflags --get LDFLAGS`
 CC = gcc
 target = gamine

Bug#896712: ITP: golang-github-dataence-porter2 -- Native Go English Porter2 stemmer

[jrmarsha]

Good night time Aaron,

Reviewing the performance claims, I don't see data validating the 660% 
speed up.  Also, having looked at libdivsufsort and SACA-K, I think the 
code could use some more comparisons.  It does look neat though.  Also, 
why is this going through the bug list?


I am not a mod, so don't worry all too much about me.


Package: wnpp
Severity: wishlist
Owner: "Aaron M. Ucko" 

* Package name: golang-github-dataence-porter2(-dev)
   Version : 0.0~git20150829.0.56e4718
   Upstream Author : Jian Zhen / Dataence, LLC
* URL : https://github.com/dataence/porter2
* License : Apache 2.0
   Programming Lang: Go
   Description : Native Go English Porter2 stemmer

Porter2 implements the english Porter2 stemmer.  It is written
completely using finite state machines to do suffix comparison, rather
than the string-based or tree-based approaches.  As a result, it is
660% faster compared to string comparison-based approach.

I intend to package this library under the auspices of debian-med for
the sake of recent ncbi-entrez-direct releases.  However, if somebody
from the Go team wants to take this package over, they're certainly
welcome to it. ;-)

Bug#896712: ITP: golang-github-dataence-porter2 -- Native Go English Porter2 stemmer

[Aaron M. Ucko]

Package: wnpp
Severity: wishlist
Owner: "Aaron M. Ucko" 

* Package name: golang-github-dataence-porter2(-dev)
  Version : 0.0~git20150829.0.56e4718
  Upstream Author : Jian Zhen / Dataence, LLC
* URL : https://github.com/dataence/porter2
* License : Apache 2.0
  Programming Lang: Go
  Description : Native Go English Porter2 stemmer

Porter2 implements the english Porter2 stemmer.  It is written
completely using finite state machines to do suffix comparison, rather
than the string-based or tree-based approaches.  As a result, it is
660% faster compared to string comparison-based approach.

I intend to package this library under the auspices of debian-med for
the sake of recent ncbi-entrez-direct releases.  However, if somebody
from the Go team wants to take this package over, they're certainly
welcome to it. ;-)

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

Bug#896704: RFS: python-picklable-itertools/0.1.1-2 [RC]

[Sergio Durigan Junior]

Control: tags -1 + moreinfo
Control: owner -1 !

On Monday, April 23 2018, Fabian Wolff wrote:

> Package: sponsorship-requests
> Severity: important
>
> Dear mentors,
>
> I am looking for a sponsor for my package "python-picklable-itertools".
>
> The current version of this package is missing a dependency, which is
> why it fails to import on systems where that dependency is not
> installed (see #896213, #896214). dh-python did not find this
> dependency, and I apparently only tested the package on systems that
> happened to have the missing dependency installed, which is why
> importing worked fine for me.
>
> I have now manually added the missing dependency in debian/control.
> In order to (hopefully) avoid this problem in the future, I have also
> added a Testsuite field in debian/control.
>
> My changes are summarized in the latest changelog entry:
>
>   python-picklable-itertools (0.1.1-2) unstable; urgency=medium
>
> * Depend on python[3]-pkg-resources (Closes: #896213, #896214).
> * Add Testsuite field to debian/control.
> * Upgrade to Standards-Version 4.1.4 (no changes).
> * Upgrade to debhelper compat level 11 (no changes).
>
>-- Fabian Wolff   Mon, 23 Apr 2018 18:30:09 +0200

Hi Fabian,

I can help with it, but there are two things I'd like to see first.

1) There are no Vcs-* fields, and it's unclear to me where the git
repository for the package is located (I couldn't find it on
salsa.d.o).

2) If having the Python 2 version of this package is important for some
reason, could you please override the lintian warning
("new-package-should-not-package-python2-module")?

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#894785: apache2: File conflict with libapache2-mod-proxy-uwsgi

[Andreas Beckmann]

Followup-For: Bug #894785
Control: found -1 2.4.33-2

Hi,

the recently added
  Replaces: libapache2-mod-md (<< 2.4.33), libapache2-mod-proxy-uwsgi (<< 
2.4.33)
on apache2-bin misses a corresponding
  Breaks: libapache2-mod-md (<< 2.4.33), libapache2-mod-proxy-uwsgi (<< 2.4.33)
otherwise partial upgrades crippling the old packages without installing
the new transitional packages are possible.

For Replaces added on other packages the same holds.


Andreas

Bug#896559: googletest: please separate source and "prebuilt library" packages

[Steve Robbins]

On Sunday, April 22, 2018 5:27:07 AM CDT you wrote:
> Package: googletest
> Version: 1.8.0-8
> Severity: important
> 
> Dear maintainer. Now that #868234 has been resolved,
> the package installs sources into /usr/src,
> and the prebuild library, + headers into /usr/include.
> 
> This is somewhat problematic.
> Now if one does not want to use the prebuilt library,
> but build it in tree (anyone who cares will do that),
> the headers from the prebuild library will still be in
> the search path.

I agree it is not optimal.  I have prepared a new revision that implements 
your suggestion #4.  In the upcoming revision:

Package googletest installs sources only
Package libgtest-dev installs headers + lib for gtest
New package libgmock-dev installs headers + lib for gmock

Let me know if this works for you.  I've just pushed it to Salsa:
https://salsa.debian.org/debian/googletest 


> There are several solutions:
> 1. Don't provide prebuild library.
> 2. Don't install sources in googletest package,
>tell people to use $ apt-get source.  BAD.
> 3. Install headers into some prefix, so they won't be automatically used.
> 4. Keep googletest with only the sources, and package
>built library + headers as a separate package, googletest-prebuilt.
> 5. 3+4 Probably the best one.

I don't believe #3 is worth the trouble because (a) it breaks the automatic 
detection I've seen in some packages; and (b) the headers in /usr/src/googlest 
and in /usr/include are identical, so there's no real issue if the latter is 
used for a source build.

Best,
-Steve


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

Bug#868234:

[Steve Robbins]

On Sunday, April 22, 2018 5:15:03 AM CDT you wrote:
> Why does the subject of this issue contains "(now enabled by upstream)"
> even though the content explicitly talks that upstream does *NOT*
> recommend doing that?

I believe the answer lies in the first paragraph:

googletest recommended against a system-wide installation of gtest and
disabled the install target on their build system.  While it seems
they maintain this odd recommendation, they have backtracked on
disabling the installation and since version 1.8 have added install
rules for cmake.

I read "now enabled by upstream" as referring to the  "added install rules".

-Steve


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

Bug#895946: rake: LoadError from Get::Ext::RakeBuilder trying to find rake

[Martin Dorey]

Looking into this further, I see that it's just a particular case of a more 
general problem:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710814
rubygems-integration: fails to override bin_path

The raiser, nearly five years ago, appeared more confident than I am about 
where the solution should be.

Bug#859213: x11vnc: stack smashing detected: x11vnc terminated

[Guillermo Reisch]

This problem is still present in version: x11vnc 0.9.13-5 (sid)

Note: Lots of errors in debian are already fixed in patch in a lots 
of bugs! But, lots of package are "orphan"... and you can't upload 
a simple patch without going through a traumatizing "adoption".

PS: Sory my bad ingles. :-P

Guillermo Reisch
UInf - FENF - UdelaR

Bug#896711: zeromq3: please package curve_keygen utility

[Scott Talbert]

Source: zeromq3
Severity: wishlist

Dear Maintainer,

zeromq builds a utility binary curve_keygen which generates keys.  It 
would be useful to have this utility available.  Please consider 
packaging it.

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

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

Bug#896710: harfbuzz: autopkgtest to detect freetype regressions

[Steve Langasek]

Package: harfbuzz
Version: 1.7.2-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear maintainers,

In Ubuntu we found a regression in freetype 2.8.1 due to unaligned memory
access on armhf (when running on certain chips in certain kernel
configurations) that was only discovered because it caused harfbuzz to fail
to build on this architecture.

It would have been useful to catch this regression much earlier, if the
harfbuzz build-time test suite were run at the time the new version of
freetype was introduced, instead of later as part of an archive rebuild test.

So I've added a simple build-only autopkgtest to harfbuzz in Ubuntu; please
see the attached patch, and please consider whether you think this would
also be useful to have in Debian.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru harfbuzz-1.7.2/debian/tests/control 
harfbuzz-1.7.2/debian/tests/control
--- harfbuzz-1.7.2/debian/tests/control 1969-12-31 16:00:00.0 -0800
+++ harfbuzz-1.7.2/debian/tests/control 2018-04-12 20:36:14.0 -0700
@@ -0,0 +1,3 @@
+Test-Command: true
+Depends: @, @builddeps@
+Restrictions: build-needed

Bug#895761: jhove: FTBFS with java 9

[Jeff Breidenbach]

I think the right thing is to update to the latest jhove release (1.20) but
looks like the build system has changed dramatically. Would love to get a
little help from someone who works with Java packages on a more regular
basis.

Bug#895864: leptonlib: needs config.guess/sub update for riscv64

[Jeff Breidenbach]

Okay, uploading now. Thanks for all the help!

On Mon, Apr 23, 2018 at 4:06 PM, Manuel A. Fernandez Montecelo <
manuel.montez...@gmail.com> wrote:

> 2018-04-23 23:22 GMT+02:00 Manuel A. Fernandez Montecelo
> :
> >
> > This additionally runs the tests,
> > can be disabled with another override_dh_auto_test and leaving it
> > empty, but I recommend to enable them.
>
> The tests built in riscv64 successfully:
>
> 
> 
> Testsuite summary for leptonica 1.75.3
> 
> 
> # TOTAL: 111
> # PASS:  96
> # SKIP:  15
> # XFAIL: 0
> # FAIL:  0
> # XPASS: 0
> # ERROR: 0
> 
> 
>
> And:
> Build needed 00:24:24, 341376k disk space
>
> So IMO it's worth enabling them.
>
>
> Cheers.
> --
> Manuel A. Fernandez Montecelo 
>

Bug#896709: [debian-mysql] Bug#896709: innobackupex: Error: Unsupported server version: '5.7.21-1-log'

[Robie Basak]

tags 896709 + moreinfo
thanks

This doesn't appear to be a bug report. Please see
https://www.debian.org/Bugs/Reporting (in particular the section
entitled "The body of the report") and
https://www.chiark.greenend.org.uk/~sgtatham/bugs.html and provide a
full explanation.


signature.asc
Description: PGP signature

Bug#896709: innobackupex: Error: Unsupported server version: '5.7.21-1-log'

[Nye Liu]

Package: percona-xtrabackup
Version: 2.2.3-2.1
Severity: grave
Justification: renders package unusable

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona LLC and/or its affiliates 2009-2013.  All Rights Reserved.

This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

180423 16:13:11  innobackupex: Connecting to MySQL server with DSN 
'dbi:mysql:;mysql_read_default_group=xtrabackup' (using password: NO).
180423 16:13:11  innobackupex: Connected to MySQL server
innobackupex: Error: Unsupported server version: '5.7.21-1-log' Please report a 
bug at https://bugs.launchpad.net/percona-xtrabackup

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

Kernel: Linux 4.15.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages percona-xtrabackup depends on:
ii  libaio10.3.111-1
ii  libc6  2.27-3
ii  libdbd-mysql-perl  4.046-1
ii  libgcc11:8-20180414-1
ii  libgcrypt201.8.2-2
ii  libgpg-error0  1.29-4
ii  libstdc++6 8-20180414-1

percona-xtrabackup recommends no packages.

percona-xtrabackup suggests no packages.

-- no debconf information

Bug#885264: childsplay: Depends on unmaintained pygtk

[Markus Koschany]

Control: forwarded -1 https://savannah.nongnu.org/bugs/index.php?53734



signature.asc
Description: OpenPGP digital signature

Bug#895864: leptonlib: needs config.guess/sub update for riscv64

[Manuel A. Fernandez Montecelo]

2018-04-23 23:22 GMT+02:00 Manuel A. Fernandez Montecelo
:
>
> This additionally runs the tests,
> can be disabled with another override_dh_auto_test and leaving it
> empty, but I recommend to enable them.

The tests built in riscv64 successfully:


Testsuite summary for leptonica 1.75.3

# TOTAL: 111
# PASS:  96
# SKIP:  15
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


And:
Build needed 00:24:24, 341376k disk space

So IMO it's worth enabling them.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#895718: python-pyqt5: import PyQt5.QtCore fails

[Jürgen E . Fischer]

Hi,

On Sun, 15. Apr 2018 at 13:26:50 +0300, Dmitry Shachnev wrote:
> Control: tags -1 unreproducible
> 
> On Sun, Apr 15, 2018 at 12:59:12AM -0400, Scott Kitterman wrote:
> > Tried this on sid with both pyqt5 5.9.2 and 5.10.1:
> >
> > Unpacking python-pyqt5 (5.10.1+dfsg-1) over (5.9.2+dfsg-1+b1) ...
> > Setting up python-pyqt5 (5.10.1+dfsg-1) ...
> > # python
> > Python 2.7.14+ (default, Apr  2 2018, 04:16:25)
> > [GCC 7.3.0] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import PyQt5.QtCore
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > ImportError: libQt5Core.so.5: cannot open shared object file: No such file 
> > or directory
> 
> Works for me in a clean sid chroot.
> 
> Can it be that you had a PyQt5 installation from PyPI which would conflict
> with the distro package?
> 
> If not, please check strace output and look which libQt5Core.so.5 it tries
> to load.

I'm hitting this too - in a cowbuilder running in docker.

jef@qgis:~$ docker exec -it 2fcadc4ab376 bash

root@qgis:/# cowbuilder --login --basepath /var/cache/pbuilder/buster-i386.cow
[...]
root@qgis:/# apt-get update && apt-get -y install python3-pyqt5 strace && 
strace -o /tmp/log python3
[...]
Python 3.6.5rc1 (default, Mar 14 2018, 06:54:23) 
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import PyQt5.QtCore
Traceback (most recent call last):
  File "", line 1, in 
ImportError: libQt5Core.so.5: cannot open shared object file: No such file or 
directory
>>> quit()

root@qgis:/# grep libQt5Core.so /tmp/log | grep -v ENOENT

openat(AT_FDCWD, "/usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5", 
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/i386-linux-gnu/libQt5Core.so.5", O_RDONLY|O_CLOEXEC) 
= 3
write(2, "ImportError: libQt5Core.so.5: ca"..., 88) = 88

root@qgis:/# cat /tmp/log

execve("/usr/bin/python3", ["python3"], 0xffe31a08 /* 25 vars */) = 0
brk(NULL)   = 0x8cc2000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf771d000
openat(AT_FDCWD, "/usr/lib/cowdancer/libcowdancer.so", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \23\0\0004\0\0\0"..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=21764, ...}) = 0
mmap2(NULL, 24664, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xf7716000
mmap2(0xf771b000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0xf771b000
close(3)= 0
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=21538, ...}) = 0
mmap2(NULL, 21538, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf771
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/i386-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300P\0\0004\0\0\0"..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=140408, ...}) = 0
mmap2(NULL, 123544, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xf76f1000
mmap2(0xf770c000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a000) = 0xf770c000
mmap2(0xf770e000, 4760, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf770e000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/i386-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\n\0\0004\0\0\0"..., 512) = 
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=13828, ...}) = 0
mmap2(NULL, 16500, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xf76ec000
mmap2(0xf76ef000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0xf76ef000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/i386-linux-gnu/libutil.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\n\0\0004\0\0\0"..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=9796, ...}) = 0
mmap2(NULL, 12424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xf76e8000
mmap2(0xf76ea000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0xf76ea000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/i386-linux-gnu/libexpat.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\ \0\0004\0\0\0"..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, 

Bug#896708: ITP: maven-cache-cleanup -- Utility to purge timestamped snapshots from Maven repositories

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: maven-cache-cleanup
  Version : 1.0.4
  Upstream Author : Yuri Nadestin
* URL : https://github.com/nadestin/tools
* License : Apache-2.0
  Programming Lang: Java
  Description : Utility to purge timestamped snapshots from Maven 
repositories

Maven 3 dropped support for non-unique snapshot versions, which had the
side effect of filling up Maven caches on developer machines and on CI
build hosts. The Maven Cache Cleanup utility scans a specified Maven cache
directory for snapshot versions and deletes all but the latest version of
the timestamped artifacts.

This package will be maintained by the Java Team.

Bug#896464: Passing -V as default

[Scott Kitterman]

On April 23, 2018 10:03:45 PM UTC, "Lisandro Damián Nicanor Pérez Meyer" 
 wrote:
>If I understand correctly and, let's suppose, libQtFoo 5.10.2 is built
>with a patched compat 12, then all applications rebuilt against 5.10.2
>would require at very least 5.10.2 even if symbols files allowed it to
>depend on a minor version.
>
>If this is true is more or less what we are currently forcing with any
>package that B-Ds on qtbase5-dev, although this would also mean that
>packages that just B-D on qtbase5-private-dev will get the same
>behavior (even if they do not list qtbase5-dev as a B-D and not taking
>into account the qtbase-abi-x-y-z dependency).
>
>The only thing I don't know from this is iif symbols files dependency
>info is totally discarded or the dependency on qtbase-abi-x-y-z would
>still be get trough them for packages using private API.
>
>Niels: like in [1] we use dpkg-symbols'
>"alternative-dependency.template" to track packages using private API.
>As long as this is kept then the change, I think, should be ok.
>
>[1]
>

If that's true, I doubt C++ symbols files  are worth the trouble.  

Scott K

Bug#896464: Passing -V as default

[Lisandro Damián Nicanor Pérez Meyer]

If I understand correctly and, let's suppose, libQtFoo 5.10.2 is built
with a patched compat 12, then all applications rebuilt against 5.10.2
would require at very least 5.10.2 even if symbols files allowed it to
depend on a minor version.

If this is true is more or less what we are currently forcing with any
package that B-Ds on qtbase5-dev, although this would also mean that
packages that just B-D on qtbase5-private-dev will get the same
behavior (even if they do not list qtbase5-dev as a B-D and not taking
into account the qtbase-abi-x-y-z dependency).

The only thing I don't know from this is iif symbols files dependency
info is totally discarded or the dependency on qtbase-abi-x-y-z would
still be get trough them for packages using private API.

Niels: like in [1] we use dpkg-symbols'
"alternative-dependency.template" to track packages using private API.
As long as this is kept then the change, I think, should be ok.

[1] 


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#896676: pristine-tar: more convenient automatic mode please

[Sean Whitton]

Hello,

On Mon, Apr 23 2018, Sean Whitton wrote:

> So long as I am its (de facto) maintainer, I do not want git-deborig
> to have that functionality, for two reasons.

For some reason I wrote my e-mail very defensively.

Please imagine I had instead written "IMO git-deborig should not have
that functionality for the following two reasons:"

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#896707: libopensrs-perl: perl warns of Unescaped left brace in regex

[root]

Package: libopensrs-perl
Version: 3.0.0-1
Severity: normal

Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/{{ <-- HERE (.*?)}}/ at /usr/share/perl5/OpenSRS/Util/Common.pm 
line 201,  line 244.
Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/{{ <-- HERE (.*?)}}/ at /usr/share/perl5/OpenSRS/Util/Common.pm 
line 573,  line 244.


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

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

Versions of packages libopensrs-perl depends on:
ii  libcrypt-blowfish-perl2.14-1+b4
ii  libcrypt-cbc-perl 2.33-1
ii  libdata-structure-util-perl   0.16-1+b2
ii  libdate-calc-perl 6.4-1
ii  libdate-manip-perl6.57-1
ii  libdate-pcalc-perl6.1-4+b2
ii  libhtml-template-perl 2.95-2
ii  libnet-libidn-perl0.12.ds-2+b3
ii  libunicode-map-perl   0.112-11+b3
ii  libunicode-string-perl2.10-1+b1
ii  libxml-parser-perl2.44-2+b1
ii  perl  5.24.1-3+deb9u3
ii  perl-modules-5.24 [liblocale-codes-perl]  5.24.1-3+deb9u3

libopensrs-perl recommends no packages.

libopensrs-perl suggests no packages.

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

-- no debconf information

Bug#896676: pristine-tar: more convenient automatic mode please

[Sean Whitton]

control: tag -1 -moreinfo

Hello,

On Mon, Apr 23 2018, Ian Jackson wrote:

>> origtargz is "a tarball has been settled on for this upload, get it
>> for me please."
>
> I have just read the manpage for origtargz.
>
> I don't think origtargz is good for my usecase because it's too
> automatic.  In particular, if I know I want to use a local
> pristine-tar branch I don't want a command which might download
> something from the network.

That is reasonable.  Untagging this bug 'moreinfo'.

You may wish to know that gbp can also extract pristine-tar tarballs:

% gbp buildpackage --pristine-tar

but of course that involves more than what this wishlist bug is
requesting.

>> pristine-tar is one way of settling on that tarball.
>>
>> git-deborig is "my git tree is right, please give me a tarball
>> because the Debian archive works that way."
>
> git-deborig was more what I wanted.

I don't follow.  What you wanted was exactly your sponsee's tarball, I
thought.  In that case, git tags are not authoritative in the sense that
git-deborig takes to them to be authoritative, so git-deborig is not
appropriate.

> I wouldn't have minded having to ask `git-deborig --pristine-tar'.

So long as I am its (de facto) maintainer, I do not want git-deborig to
have that functionality, for two reasons.

Firstly, it strikes me as a layering violation.  git-deborig is in the
git-* namespace because it is a wrapper for an existing git command,
namely, git-archive.  Just as git-debrebase wraps git-rebase, plus a few
other git commands.  And the nine ~/bin/git-* scripts I have ..

Secondly, tarballs generated/outputted by git-deborig should always be
ephemeral, not needing to be stored anywhere and regenerated when
needed, which is the opposite of pristine-tar.  ISTM that git-deborig
would be harder to understand if that particular assumption was
violated.

So it seems that as you originally suggested, the functionality you are
requesting should be in pristine-tar.

Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#892293: paraview: errors when saving animations as AVI files [regression]

[Francesco Poli]

On Sat, 31 Mar 2018 13:10:28 +0200 Francesco Poli wrote:

[...] 
> On Wed, 07 Mar 2018 22:43:06 +0100 Francesco Poli (wintermute) wrote:
> 
[...]
> > In a nutshell, version 5.4.1 fails to save animations as AVI files
> > (while version 5.1.2 was perfectly capable of doing so).
[...]
> I've just re-checked with paraview/5.4.1+dfsg4-2 and I am still unable
> to save animations as AVI files

To work around this regression, one can save the animation as PNG
images and then use ffmpeg to create the AVI video:

  $ ffmpeg -f image2 -framerate 5 -i wave_anim_test.%04d.png \
   -vcodec mjpeg -pix_fmt yuvj422p -qscale 3 wave_anim_test.avi


I am adding this hint to the bug log, so that other users may benefit
from the workaround, while waiting for a proper fix in paraview...



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


pgpxPn13NTwvR.pgp
Description: PGP signature

Bug#896706: pcbnew: crashes with a failed assertion on i386, starts fine on amd64

[Mirko Parthey]

Package: kicad
Version: 5.0.0~rc1+dfsg1+20180318-3
Severity: normal

On the i386 architecture, I get this error when starting pcbnew:

pcbnew: 
/build/kicad-9PGPiJ/kicad-5.0.0~rc1+dfsg1+20180318/include/geometry/rtree.h:1642:
 void RTree::Classify(int, int, RTree::PartitionVars*) [with DATATYPE = KIGFX::VIEW_ITEM*; 
ELEMTYPE = int; int NUMDIMS = 2; ELEMTYPEREAL = float; int TMAXNODES = 8; int 
TMINNODES = 4]: Assertion `!a_parVars->m_taken[a_index]' failed.

Conversely, on an amd64 system, pcbnew starts fine.

Both systems are up-to-date installations of Debian buster,
with kicad pulled from Debian experimental.

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

Kernel: Linux 4.15.0-2-686-pae (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 kicad depends on:
ii  libc6   2.27-3
ii  libcairo2   1.15.10-1
ii  libcurl37.58.0-2
ii  libgcc1 1:8-20180414-1
ii  libgl1  1.0.0-2
ii  libglew2.0  2.0.0-5
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libgomp18-20180414-1
ii  libpixman-1-0   0.34.0-2
ii  libpython2.72.7.15~rc1-1
ii  libssl1.1   1.1.0h-2
ii  libstdc++6  8-20180414-1
ii  libwxbase3.0-0v53.0.4+dfsg-3
ii  libwxgtk3.0-gtk3-0v53.0.4+dfsg-3
ii  python  2.7.15~rc1-1
ii  python-wxgtk3.0 3.0.2.0+dfsg-7

Versions of packages kicad recommends:
ii  kicad-demos  5.0.0~rc1+dfsg1+20180318-3
ii  kicad-libraries  5.0.0~rc1+dfsg1+20180318-3
ii  xsltproc 1.1.29-5

Versions of packages kicad suggests:
pn  extra-xdg-menus   
ii  kicad-doc-en  5.0.0~rc1+dfsg1+20180318-3
pn  kicad-packages3d  

-- no debconf information

Bug#893919: RFS: yasnippet-snippets/0.2-1

[Nicholas D Steeves]

Hi Chris,

To further your request to comment on upstream changes in progress
I've added README.source to Elpy and am cross-referencing the issue
here.

Yasnippet-snippets' upstream tells me he expects to merge my PR in the
next week, so its next upstream version (0.3) should have Elpy's
yasnippets installed to the cannonical system location for snippets.
Then I can do the work to unbundle them (upstream) from Elpy, and by
then I expect it will be either the 1.20 or 1.21 release (currently
waiting for sponsorship for 1.19).

When the snippets are unbundled, Elpy will require an elpafied
yasnippet-snippets.  I have DM on yasnippet-snippets, but this RFS
needs to be sponsored, because it will prevent updating to Elpy >= 1.20.

If you have time to sponsor it I'd very much appreciate it :-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#894159: transition: icu

[Emilio Pozuelo Monfort]

On 23/04/18 21:40, László Böszörményi (GCS) wrote:
> On Mon, Apr 23, 2018 at 9:27 PM, Emilio Pozuelo Monfort
>  wrote:
>> On 23/04/18 21:19, László Böszörményi (GCS) wrote:
>>>  As I remember, 99% of the FTBFS reasons were the icu-config removal,
>>> others are the dependent package bugs I've already mentioned. I do not
>>> recall any API change. In short, there are fifteen packages FTBFS and
>>> all is due to the icu-config removal. This is true for the date of my
>>> previous mail. There were several dependent packages upload since
>>> then, but I think the situation remained the same.
>>
>> In that case I'm ok with removing icu-config, but please don't entangle that
>> with the SONAME bump. That is, reintroduce icu-config so we can have an easy
>> transition, and once the transition is finished, then you are free to drop
>> icu-config. Sounds good?
>  I do agree and open to do an other compilation test of the dependent
> packages with icu-config being available.

Thanks. Let me know how that goes, and I'll ack this transition as soon as 
possible.

Cheers,
Emilio

Bug#895864: leptonlib: needs config.guess/sub update for riscv64

[Manuel A. Fernandez Montecelo]

Hi,

2018-04-23 21:12 GMT+02:00 Jeff Breidenbach :
> Is it sufficient to put Build-Depends: debhelper (>= 11.0.0) in
> debian/control and 11 in debian/compat ?

Thanks for taking care of this.

You have to un-comment the "dh_autoreconf*" lines in debian/rules too,
not sure why they are disabled, but possibly because they don't work
(there's an error from libtoolize/autoconf).  It seems to need
additionally "pkg-config" in the build-depends, when reconfguring.

To the best of my knowledge, if you were using a rule like the
following one and without the handcrafted rules, I think that it would
be part of the commands invoked by default, but with the handcrafted
rules they take precedence, so the defaults are not invoked.

=
%:
dh $@
=

The rule above covers the defaults of leptonlib quite well, since it's
not using anything contrived, only needs a minor modification for the
manpage.  Things like noopt and nostrip are supposed to be handled
automatically.

I attach 3 files:

1) the minimal conversion so dh-autoreconf works (leptonlib_1.75.3-3.1.debdiff)

2) and 3) the full conversion to simple rules, with
leptonlib_1.75.3-3.2.debdiff and debian/rules attached separate, to
see clearly the benefits.  (Obviously, by the way, the message in
d/changelog should be squashed).  This additionally runs the tests,
can be disabled with another override_dh_auto_test and leaving it
empty, but I recommend to enable them.


I tested 1 and 2/3 and it works fine, both produce binaries in amd64
that don't differ from the previous version (debdiff).


Hope that helps.  If in any doubt, please ask.


Cheers.
-- 
Manuel A. Fernandez Montecelo 


leptonlib_1.75.3-3.1.debdiff
Description: Binary data


leptonlib_1.75.3-3.2.debdiff
Description: Binary data


rules
Description: Binary data

Bug#896433: ifupdown: ifquery can't be called recursively from ifup/ifdown, but if-pre/up.d scripts call it

[Dan Streetman]

On Sun, Apr 22, 2018 at 3:24 PM, Guus Sliepen  wrote:
> On Fri, Apr 20, 2018 at 04:52:24PM -0400, Dan Streetman wrote:
>
>> Scripts in the if-pre-up.d and if-up.d dirs call ifquery directly, or call 
>> it indirectly
>> through other scripts.  However ifquery tries to lock each interface and 
>> exits with
>> error if it's called from ifup or ifdown.  Since ifquery doesn't change 
>> anything,
>> there is no reason interface locks need to be taken; ifquery can be safely 
>> run
>> recurseively from ifup/ifdown.
>
> You're right, it should be possible to run ifquery recursively. But it
> should still ensure the interface is locked before querying it, to
> ensure consistency.
>
>> In Ubuntu, the attached patch was applied to achieve the following:
>
> The patch avoids locking at all when no_act == true. Consider this:
>
> iface foo inet ...
> pre-up ifquery --state bar
>
> iface bar inet ...
>
> Now if I call ifup foo and ifup bar at the same time, then the ifquery
> might theoretically read a half-written /run/network/ifstate.bar.

Eh?

ifquery --state doesn't use the ifstate.* files.  It reads state from
the global ifstate file.

main() checks (state_query) and then calls do_state(argc, argv) to
actually print out the current state of any/all specified interfaces
(all if none specified).

The do_state() function calls read_all_state() to actually get the
state info of all interfaces.

The read_all_state() function first locks the global .ifstate.lock
file, then opens and reads the global /run/network/ifstate file (then
closes both).  It does not open or read any of the ifstate.* files.

In fact ifquery --state returns do_state(), so it will never even
reach the call to do_interface() that my patch adjusts.

Am I misunderstanding your assertion?

> Granted, the change of this is extremely small, and one could also
> question whether it makes sense to run ifquery in this way at all, since
> even if it did read a consistent /run/network/ifstate.bar, it could
> either read the state as being up or down depending on whether ifup bar
> finished before or after ifquery. But it's not hard to do it correctly,
> so I'll make it so it only avoids locking if it detects recursion.
>
>> Thanks for considering the patch.
>
> Thanks for sending the patch :)
>
> --
> Met vriendelijke groet / with kind regards,
>   Guus Sliepen 

Bug#893302: lwjgl FTBFS with openjdk-9

[Markus Koschany]

I had a go at this today. This package has multiple issues. I tried to
work around the RuntimeExceptions by returning true instead of throwing
an exception. Very bad I know.

It turned out that not only one but four classes are not properly
generated at build time. Those will cause missing symbol errors later.
Then there are several removed or deprecated sun.* classes that either
cause a build failure or warnings.

I'm attaching a simple patch that makes more of those errors visible.

lwjgl 2.9.3 is a legacy release from 2015. It is the last version of the
2.x series and no longer supported. Upstream moved to lwjgl 3. If nobody
can fix this we should consider to remove lwjgl because the new version
3 would require new Kotlin build dependencies and more.

Markus
From: Markus Koschany 
Date: Mon, 23 Apr 2018 22:30:13 +0200
Subject: java9

---
 src/java/org/lwjgl/util/generator/GeneratorProcessor.java | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/src/java/org/lwjgl/util/generator/GeneratorProcessor.java b/src/java/org/lwjgl/util/generator/GeneratorProcessor.java
index dc03404..754b262 100644
--- a/src/java/org/lwjgl/util/generator/GeneratorProcessor.java
+++ b/src/java/org/lwjgl/util/generator/GeneratorProcessor.java
@@ -87,11 +87,8 @@ public class GeneratorProcessor extends AbstractProcessor {
 			first_round = false;
 			return true;
 		} catch (Exception e) {
-			if ( lastFile == null ) {
-throw new RuntimeException(e);
-			} else {
-throw new RuntimeException("\n-- Failed to process template: " + lastFile.asType().toString() + " --", e);
-			}
+			System.out.println("\n-- Failed to process template: " + lastFile.asType().toString() + " --");
+			return true;
 		}
 	}
 


signature.asc
Description: OpenPGP digital signature

Bug#829092: i18n.debian.org: use https for links in l10n-pkg-status/pkglist file

[Laura Arjona Reina]

Hello Paul
Thanks for reporting this issue.
I have committed changes to the scripts so they now use https for the
links; I will look (at the next generation of the file
https://i18n.debian.org/l10n-pkg-status/pkglist (tomorrow) to see if the
change is effective, and if yes, will close this bug.

Thanks!

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#896705: [uscan] problem with creating orig.tar from git tag

[Thorsten Alteholz]

Package: devscripts
Version: 2.18.1
Severity: normal

Hi,

uscan in version 2.18.1 is no longer able to create a new orig.tar from a 
tag in a git repository.


At the end are the results from version 2.17.12, which is doing fine.

  Thorsten


debian@devel:~/devscript-bug$ LANG=C dpkg -l devscripts
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version   Architecture  Description
+++--=-=-==
ii  devscripts   2.18.1amd64 scripts to 
make the life of a Debian Package maintaine


debian@devel:~/devscript-bug$ LANG=C apt-get source osmo-trx=0.2.0-2
Reading package lists... Done
NOTICE: 'osmo-trx' packaging is maintained in the 'Git' version control system 
at:
https://salsa.debian.org/debian-mobcom-team/osmo-trx.git
Please use:
git clone https://salsa.debian.org/debian-mobcom-team/osmo-trx.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 140 kB of source archives.
Get:1 http://ftp2.de.debian.org/debian unstable/main osmo-trx 0.2.0-2 (dsc) 
[2275 B]
Get:2 http://ftp2.de.debian.org/debian unstable/main osmo-trx 0.2.0-2 (tar) 
[132 kB]
Get:3 http://ftp2.de.debian.org/debian unstable/main osmo-trx 0.2.0-2 (diff) 
[5660 B]
Fetched 140 kB in 1s (94.3 kB/s)
dpkg-source: info: extracting osmo-trx in osmo-trx-0.2.0
dpkg-source: info: unpacking osmo-trx_0.2.0.orig.tar.xz
dpkg-source: info: unpacking osmo-trx_0.2.0-2.debian.tar.xz
dpkg-source: info: applying 02_no_march_native.patch

debian@devel:~/devscript-bug$ cd osmo-trx-0.2.0/

debian@devel:~/devscript-bug/osmo-trx-0.2.0$ LANG=C uscan --verbose --download

uscan info: uscan (version 2.18.1) See uscan(1) for help
uscan info: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="osmo-trx" version="0.2.0-2" (as seen in debian/changelog)
uscan info: package="osmo-trx" version="0.2.0" (no epoch/revision)
uscan info: ./debian/changelog sets package="osmo-trx" version="0.2.0"
uscan info: Process watch file at: debian/watch
package = osmo-trx
version = 0.2.0
pkg_dir = .
uscan info: opts: mode=git, dversionmangle=s/\+ds//
uscan info: line: https://git.osmocom.org/osmo-trx refs/tags/([\d\.]+) debian 
uupdate
uscan info: Parsing mode=git
uscan info: Parsing  dversionmangle=s/\+ds//
uscan info: line: https://git.osmocom.org/osmo-trx refs/tags/([\d\.]+) debian 
uupdate
uscan info: Last orig.tar.* tarball version (from debian/changelog): 0.2.0
uscan info: Last orig.tar.* tarball version (dversionmangled): 0.2.0
uscan info: Execute: git ls-remote https://git.osmocom.org/osmo-trx
uscan info: Found the following matching refs:
 refs/tags/0.3.0 (0.3.0)
 refs/tags/0.2.0 (0.2.0)
 HEAD ()
 refs/heads/achemeris/2sector ()
 refs/heads/achemeris/diversity ()
 refs/heads/achemeris/empty-bursts ()
 refs/heads/achemeris/load_testing ()
 refs/heads/achemeris/phase_err_meas ()
 refs/heads/achemeris/poweroff_hack ()
 refs/heads/achemeris/ramp-mask ()
 refs/heads/achemeris/rtmd ()
 refs/heads/achemeris/stable_threads ()
 refs/heads/coverity ()
 refs/heads/fairwaves/625 ()
 refs/heads/fairwaves/WIP-decoder ()
 refs/heads/fairwaves/master ()
 refs/heads/fairwaves/master-old ()
 refs/heads/fairwaves/no-demod ()
 refs/heads/fairwaves/old-master ()
 refs/heads/fix-osmogsmtester ()
 refs/heads/kluchnikov/recv-timeout-fix ()
 refs/heads/laforge/lime ()
 refs/heads/master ()
 refs/heads/max/fix ()
 refs/heads/ms ()
 refs/heads/pmaier/cpudetect ()
 refs/heads/ramp-mask ()
 refs/heads/rel-0.3.0 ()
 refs/heads/ttsou/master-compat ()
 refs/heads/ttsou/siggen ()
 refs/tags/fairwaves/0.1.10-1 ()
 refs/tags/fairwaves/0.1.10-2 ()
 refs/tags/fairwaves/0.1.10-3 ()
 refs/tags/fairwaves/0.1.11 ()
 refs/tags/fairwaves/0.1.9 ()
 refs/tags/fairwaves/0.1.9-1 ()
uscan info: Looking at $base = https://git.osmocom.org/osmo-trx with
$filepattern = refs/tags/([\d\.]+) found
$newfile = refs/tags/0.3.0
$newversion  = 0.3.0 which is newer than
$lastversion = 0.2.0
uscan info: Upstream URL(+tag) to download is identified as
https://git.osmocom.org/osmo-trx refs/tags/0.3.0
uscan info: Filename (filenamemangled) for downloaded file: 
osmo-trx-0.3.0.tar.xz
uscan: Newest version of osmo-trx on remote site is 0.3.0, local version is 
0.2.0
uscan:=> Newer package available from
  https://git.osmocom.org/osmo-trx refs/tags/0.3.0
uscan info: Downloading upstream package: osmo-trx-0.3.0.tar.xz
uscan info: Execute: git clone --bare --depth=1 
https://git.osmocom.org/osmo-trx ../osmo-trx-temporary.2327.git
Cloning into bare repository 

Bug#896704: RFS: python-picklable-itertools/0.1.1-2 [RC]

[Fabian Wolff]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "python-picklable-itertools".

The current version of this package is missing a dependency, which is
why it fails to import on systems where that dependency is not
installed (see #896213, #896214). dh-python did not find this
dependency, and I apparently only tested the package on systems that
happened to have the missing dependency installed, which is why
importing worked fine for me.

I have now manually added the missing dependency in debian/control.
In order to (hopefully) avoid this problem in the future, I have also
added a Testsuite field in debian/control.

My changes are summarized in the latest changelog entry:

  python-picklable-itertools (0.1.1-2) unstable; urgency=medium

* Depend on python[3]-pkg-resources (Closes: #896213, #896214).
* Add Testsuite field to debian/control.
* Upgrade to Standards-Version 4.1.4 (no changes).
* Upgrade to debhelper compat level 11 (no changes).

   -- Fabian Wolff   Mon, 23 Apr 2018 18:30:09 +0200


The package is available on Mentors:

  https://mentors.debian.net/package/python-picklable-itertools
  
https://mentors.debian.net/debian/pool/main/p/python-picklable-itertools/python-picklable-itertools_0.1.1-2.dsc

Thank you!

Best regards,
Fabian

Bug#881725: apache2: reload fails inside (libvirt) lxc container

[Stefan Fritsch]

On Monday, 16 April 2018 21:51:36 CEST Stefan Fritsch wrote:
> So tmpreaper should exclude systemd-private-* files by default. Moritz, do
> you also have some cron job cleaning up stale files in /tmp ?

tmpreaper needs to exclude dirs inside the  systemd-private-* dir, too (there 
is a tmp dir inside). There does not seem to be a recursive mode and

TMPREAPER_PROTECT_EXTRA='/tmp/systemd-private*'

did not help. Probably something like

TMPREAPER_PROTECT_EXTRA='/tmp/systemd-private*/*'

should work better.

Bug#894159: transition: icu

[GCS]

On Mon, Apr 23, 2018 at 9:27 PM, Emilio Pozuelo Monfort
 wrote:
> On 23/04/18 21:19, László Böszörményi (GCS) wrote:
>>  As I remember, 99% of the FTBFS reasons were the icu-config removal,
>> others are the dependent package bugs I've already mentioned. I do not
>> recall any API change. In short, there are fifteen packages FTBFS and
>> all is due to the icu-config removal. This is true for the date of my
>> previous mail. There were several dependent packages upload since
>> then, but I think the situation remained the same.
>
> In that case I'm ok with removing icu-config, but please don't entangle that
> with the SONAME bump. That is, reintroduce icu-config so we can have an easy
> transition, and once the transition is finished, then you are free to drop
> icu-config. Sounds good?
 I do agree and open to do an other compilation test of the dependent
packages with icu-config being available.

Cheers,
Laszlo/GCS

Bug#896683: dl10n manpages-rrd.pl script fails trying to download nonexistent arch in testing

[Laura Arjona Reina]

Hello
I have committed an update of the lists of architectures:

https://salsa.debian.org/l10n-team/dl10n/commit/d29d906d9f14a612b5fa223ce3e92049b27396fb

I will look at the logs for tomorrow and if the problem is fixed I will
close the bug.

Cheers
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#895237: apache2: apachectl does not use systemd for restarts

[Stefan Fritsch]

On Sunday, 15 April 2018 21:50:57 CEST Jan Heitkötter wrote:
> The hooks in Let’s Encrypt’s conffile say “apachectl -k”; the manpage
> does not explain this option. Omitting -k makes things work:

options unknown to apachectl are passed to apache2 and apache2 -k start tells 
apache2 to do a normal start and go into the background. But this means that 
the systemd magic that apachectl does for "apachectl start" is not done for 
"apachectl -k start".

Not sure how to fix this. In general, it is not possible to map all options to 
systemd actions. For example, one could do

apachectl -DSOME_CONFIG_DEFINE -k start

to start apache with some special config options. Even worse, "-k start" is 
the default if no other action option (like -k, -t, -l, -L, ...) is given.

Bug#896408: python3-spyder-memory-profiler: spyder_memory_profiler fails to import

[Adrian Bunk]

Control: severity -1 important

On Fri, Apr 20, 2018 at 10:01:37PM +0200, Helmut Grohne wrote:
> Package: python3-spyder-memory-profiler
> Version: 0.1.2-1
> Severity: serious
> User: helm...@debian.org
> Usertags: python-import
> 
> After installing python3-spyder-memory-profiler importing the module 
> spyder_memory_profiler
> into a python interpreter fails with the following error:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3/dist-packages/spyder_memory_profiler/__init__.py", 
> line 12, in 
> from .memoryprofiler import MemoryProfiler
>   File 
> "/usr/lib/python3/dist-packages/spyder_memory_profiler/memoryprofiler.py", 
> line 14, in 
> from spyder.utils.qthelpers import qapplication
>   File "/usr/lib/python3/dist-packages/spyder/utils/qthelpers.py", line 25, 
> in 
> from spyder.config.base import get_image_path, running_in_mac_app
>   File "/usr/lib/python3/dist-packages/spyder/config/base.py", line 221, in 
> 
> LANG_FILE = get_conf_path('langconfig')
>   File "/usr/lib/python3/dist-packages/spyder/config/base.py", line 126, in 
> get_conf_path
> xdg_config_home = osp.join(get_home_dir(), '.config')
>   File "/usr/lib/python3/dist-packages/spyder/config/base.py", line 116, in 
> get_home_dir
> raise RuntimeError('Please define environment variable $HOME')
> RuntimeError: Please define environment variable $HOME
>...

This a problem specific to HOME not pointing to a valid home directory.

And depending on the circumstances (I cannot judge it here) it might not 
even be a bug that this module expect a $HOME that points to a real location.

> Helmut

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#896703: packagekit: CVE-2018-1106: Installation of Signed Packages without Administrator Authentication

[Salvatore Bonaccorso]

Source: packagekit
Version: 1.1.5-2
Severity: grave
Tags: patch security upstream
Justification: user security hole

Hi,

The following vulnerability was published for packagekit. Filling it
for now with RC severity.

CVE-2018-1106[0]:
Installation of Signed Packages without Administrator Authentication

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-2018-1106
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1106
[1] 
https://github.com/hughsie/PackageKit/commit/7e8a7905ea9abbd1f384f05f36a4458682cd4697

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#894159: transition: icu

[Emilio Pozuelo Monfort]

On 23/04/18 21:19, László Böszörményi (GCS) wrote:
> On Mon, Apr 23, 2018 at 7:57 PM, Emilio Pozuelo Monfort
>  wrote:
>> First of all, sorry for the delay. I saw there were several issues here and
>> decided to postpone this a bit.
>  Emilio! I already owe you a couple of beers. Hope we can meet again
> in Hsinchu and have a chat about this.
> 
>> On 26/03/18 22:29, László Böszörményi (GCS) wrote:
>>> It will need a quick bootstrap. It needs to build without the Layout
>>> Engine API, then the support library (icu-le-hb). Only then ICU can be
>>> built with the Layout Engine API as the two libraries tied together.
>>
>> Can you explain that? Why can't you enable Layout Engine from the start?
>  The Layout Engine was always buggy and was abandoned for a while. It
> was removed in ICU 58.1 [1]. Actually it was deprecated with ICU 54.1,
> released in October, 2014 (three and a half years ago).
> Someone started to re-implement the API using an external library,
> HarfBuzz[2]. But it is also stalled, the last real code commit is from
> 6th of May, 2016 [3]. Only one project still using it via the
> Paragraph Layout and it's the OpenTTD game[4].
> To answer your question, as you see Layout Engine is an external
> project by now. It needs to build with the actual ICU ABI, which
> changes with major releases (hence the need of a transition). When the
> Layout Engine is available for the current ICU ABI, then the
> additional Paragraph Layout API / libraries of ICU can be built. This
> is the cause of the ICU build -> icu-le-hb -> ICU build again steps.
> I might bundle the two sources together into one source package, but
> then every ICU build would do this three step compilation instead of
> one. It's enough to do once IMHO for every ICU major releases.
> In short, I should speak with the OpenTTD folks how / why they use
> Paragraph Layout API and if they can migrate to an other solution.

Ok, I didn't realise that icu-le-hb was a separate source package.

>>> Some patches are simply adding '--with-icu=/usr' to the configure
>>> invocation in debian/rules. Others are for ICU detection in the
>>> configuration phase. No code change is needed in the packages.
>>> If it matters, Ubuntu already transitioned with a bit different method.
>>
>> Are those changes and the large number of FTBFS because of the removal of
>> icu-config? Can we keep it for now and file bugs at severity:important for 
>> the
>> rdeps asking to fix the build when icu-config is removed? That should ease 
>> this
>> transition.
>  Agree, keeping icu-config would help a lot with the transition.
> Ubuntu did the transition this way. On the other hand, icu-config is a
> simple script and don't know much about MultiArch and/or
> cross-compilation. Upstream has pkg-config files for a while, but not
> all dependent packages migrated to it yet. :-/
> OK, riscv64 already over the initial bootstrap and rebuild steps.
> 
>> I would appreciate a number of failing rdeps and how many are due to ICU API
>> changes and how many are due to icu-config removal.
>  As I remember, 99% of the FTBFS reasons were the icu-config removal,
> others are the dependent package bugs I've already mentioned. I do not
> recall any API change. In short, there are fifteen packages FTBFS and
> all is due to the icu-config removal. This is true for the date of my
> previous mail. There were several dependent packages upload since
> then, but I think the situation remained the same.

In that case I'm ok with removing icu-config, but please don't entangle that
with the SONAME bump. That is, reintroduce icu-config so we can have an easy
transition, and once the transition is finished, then you are free to drop
icu-config. Sounds good?

Cheers,
Emilio

Bug#896230: python-gpod: gpod fails to import

[Mark Williams]

Installing python-gobject seems to work around this. Suggest this is added
to dependencies.

Bug#895960: 100 -> 10

[dann frazier]

Sorry for the typo - that should be DELAYED/*10*.

Bug#896322: python3-subliminal: subliminal fails to import

[Adrian Bunk]

Control: reassign -1 python3-guessit
Control: forcemerge 896282 -1
Control: affects 896282 python3-subliminal

On Fri, Apr 20, 2018 at 10:01:37PM +0200, Helmut Grohne wrote:
> Package: python3-subliminal
> Version: 1.1.1-2
> Severity: serious
> User: helm...@debian.org
> Usertags: python-import
> 
> After installing python3-subliminal importing the module subliminal
> into a python interpreter fails with the following error:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3/dist-packages/subliminal/__init__.py", line 10, in 
> 
> from .api import (ProviderPool, check_video, provider_manager, 
> download_best_subtitles, download_subtitles,
>   File "/usr/lib/python3/dist-packages/subliminal/api.py", line 13, in 
> 
> from .subtitle import compute_score, get_subtitle_path
>   File "/usr/lib/python3/dist-packages/subliminal/subtitle.py", line 7, in 
> 
> from guessit.matchtree import MatchTree
>   File "/usr/lib/python3/dist-packages/guessit/__init__.py", line 99, in 
> 
> from guessit.plugins import transformers
>   File "/usr/lib/python3/dist-packages/guessit/plugins/transformers.py", line 
> 222, in 
> reload()
>   File "/usr/lib/python3/dist-packages/guessit/plugins/transformers.py", line 
> 220, in reload
> reload_options(all_transformers())
>   File "/usr/lib/python3/dist-packages/guessit/plugins/transformers.py", line 
> 179, in all_transformers
> return _extensions.objects()
>   File "/usr/lib/python3/dist-packages/guessit/plugins/transformers.py", line 
> 111, in objects
> return self.map(self._get_obj)
>   File "/usr/lib/python3/dist-packages/stevedore/extension.py", line 261, in 
> map
> raise NoMatches('No %s extensions found' % self.namespace)
> stevedore.exception.NoMatches: No guessit.transformer extensions found
>...

This is a duplicate of #896282 in python3-guessit.

> Helmut

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#896701: drupal7: CVE-2018-7602: SA-CORE-2018-004

[Salvatore Bonaccorso]

Hi,

On Mon, Apr 23, 2018 at 02:04:33PM -0500, Gunnar Wolf wrote:
> Salvatore Bonaccorso dijo [Mon, Apr 23, 2018 at 08:53:38PM +0200]:
> > The following vulnerability was published for drupal7.
> > 
> > CVE-2018-7602[0]:
> > SA-CORE-2018-004
> > 
> > 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-2018-7602
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7602
> > [1] https://www.drupal.org/psa-2018-003
> 
> Rather than published, they were forewarned. They will be published
> two days from now (when I expect to patch right away!)

Yes that was just a poorly worded bugreport of mine. Its just a
prenotification yet, and the known CVE id for it.

Regards,
Salvatore

Bug#894159: transition: icu

[GCS]

On Mon, Apr 23, 2018 at 7:57 PM, Emilio Pozuelo Monfort
 wrote:
> First of all, sorry for the delay. I saw there were several issues here and
> decided to postpone this a bit.
 Emilio! I already owe you a couple of beers. Hope we can meet again
in Hsinchu and have a chat about this.

> On 26/03/18 22:29, László Böszörményi (GCS) wrote:
>> It will need a quick bootstrap. It needs to build without the Layout
>> Engine API, then the support library (icu-le-hb). Only then ICU can be
>> built with the Layout Engine API as the two libraries tied together.
>
> Can you explain that? Why can't you enable Layout Engine from the start?
 The Layout Engine was always buggy and was abandoned for a while. It
was removed in ICU 58.1 [1]. Actually it was deprecated with ICU 54.1,
released in October, 2014 (three and a half years ago).
Someone started to re-implement the API using an external library,
HarfBuzz[2]. But it is also stalled, the last real code commit is from
6th of May, 2016 [3]. Only one project still using it via the
Paragraph Layout and it's the OpenTTD game[4].
To answer your question, as you see Layout Engine is an external
project by now. It needs to build with the actual ICU ABI, which
changes with major releases (hence the need of a transition). When the
Layout Engine is available for the current ICU ABI, then the
additional Paragraph Layout API / libraries of ICU can be built. This
is the cause of the ICU build -> icu-le-hb -> ICU build again steps.
I might bundle the two sources together into one source package, but
then every ICU build would do this three step compilation instead of
one. It's enough to do once IMHO for every ICU major releases.
In short, I should speak with the OpenTTD folks how / why they use
Paragraph Layout API and if they can migrate to an other solution.

>> Some patches are simply adding '--with-icu=/usr' to the configure
>> invocation in debian/rules. Others are for ICU detection in the
>> configuration phase. No code change is needed in the packages.
>> If it matters, Ubuntu already transitioned with a bit different method.
>
> Are those changes and the large number of FTBFS because of the removal of
> icu-config? Can we keep it for now and file bugs at severity:important for the
> rdeps asking to fix the build when icu-config is removed? That should ease 
> this
> transition.
 Agree, keeping icu-config would help a lot with the transition.
Ubuntu did the transition this way. On the other hand, icu-config is a
simple script and don't know much about MultiArch and/or
cross-compilation. Upstream has pkg-config files for a while, but not
all dependent packages migrated to it yet. :-/
OK, riscv64 already over the initial bootstrap and rebuild steps.

> I would appreciate a number of failing rdeps and how many are due to ICU API
> changes and how many are due to icu-config removal.
 As I remember, 99% of the FTBFS reasons were the icu-config removal,
others are the dependent package bugs I've already mentioned. I do not
recall any API change. In short, there are fifteen packages FTBFS and
all is due to the icu-config removal. This is true for the date of my
previous mail. There were several dependent packages upload since
then, but I think the situation remained the same.

Cheers,
Laszlo/GCS

Bug#895864: leptonlib: needs config.guess/sub update for riscv64

[Jeff Breidenbach]

Is it sufficient to put Build-Depends: debhelper (>= 11.0.0) in
debian/control and 11 in debian/compat ?

Bug#896702: lazarus-ide-1.8: Cannot install packages and rebuild the IDE

[Alexander Kernozhitsky]

Package: lazarus-ide-1.8
Version: 1.8.2+dfsg-3~bpo9+1
Severity: important

Dear Maintainer,

I clicked on

Tools > Build Lazarus with Profile: Normal IDE

The expected result was the IDE will rebuild itself. But the build finished
with the error:

lazarus.pp(1,1) Fatal: Cannot find lazcontroldsgn used by Lazarus. Check if
package LazControlDsgn creates lazcontroldsgn.ppu, check nothing deletes this
file and check that no two packages have access to the unit source..

Did it with clean Lazarus installation.

The bug doesn't affect upstream Lazarus packages available to download on the
official website.



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

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

Versions of packages lazarus-ide-1.8 depends on:
ii  fp-compiler-3.0.4 [fp-compiler]  3.0.4+dfsg-15~bpo9+1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u3
ii  libcairo21.14.8-1
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgtk2.0-0  2.24.31-2
ii  libpango-1.0-0   1.40.5-1
ii  libx11-6 2:1.6.4-3

Versions of packages lazarus-ide-1.8 recommends:
ii  fpc  3.0.4+dfsg-15~bpo9+1
ii  fpc-3.0.4 [fpc]  3.0.4+dfsg-15~bpo9+1
ii  gdb  7.12-6

Versions of packages lazarus-ide-1.8 suggests:
ii  fp-utils-3.0.4 [fp-utils]  3.0.4+dfsg-15~bpo9+1

-- no debconf information

Bug#896671: lintian: false positive description-synopsis-might-not-be-phrased-properly on 'e.g.'

[Chris Lamb]

tags 896671 + pending
thanks

Nice report, thanks... I liked the "stretc." corner case! Fixed
in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/2c6fcf72575342bb874a4f983db825f4abd1e03d

  checks/description.pm  |   7 +-
  debian/changelog   |   6 ++
  .../description-general/debian/debian/control.in   |  23 +---
  t/tests/description-general/desc   |   3 +-
  t/tests/description-general/tags   |   2 -
  .../debian/debian/control.in   | 117 +
  .../desc   |   5 +
  .../tags   |   5 +
  8 files changed, 141 insertions(+), 27 deletions(-)


Regards,

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

Bug#896701: drupal7: CVE-2018-7602: SA-CORE-2018-004

[Gunnar Wolf]

Salvatore Bonaccorso dijo [Mon, Apr 23, 2018 at 08:53:38PM +0200]:
> The following vulnerability was published for drupal7.
> 
> CVE-2018-7602[0]:
> SA-CORE-2018-004
> 
> 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-2018-7602
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7602
> [1] https://www.drupal.org/psa-2018-003

Rather than published, they were forewarned. They will be published
two days from now (when I expect to patch right away!)

Thanks,

Bug#895761: jhove: FTBFS with java 9

[Jeff Breidenbach]

Taking a look

Bug#896216: python3-pytest-cookies: pytest_cookies fails to import

[Adrian Bunk]

Control: reassign -1 python3-future
Control: reassign 896389 python3-future
Control: forcemerge 896597 -1 896389
Control: retitle -1 python3-future: depend on python3-lib2to3
Control: affects -1 python3-pytest-cookies python3-flask-autoindex

On Fri, Apr 20, 2018 at 10:01:33PM +0200, Helmut Grohne wrote:
> Package: python3-pytest-cookies
> Version: 0.3.0-1
> Severity: serious
> User: helm...@debian.org
> Usertags: python-import
> 
> After installing python3-pytest-cookies importing the module pytest_cookies
> into a python interpreter fails with the following error:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3/dist-packages/pytest_cookies.py", line 6, in 
> from cookiecutter.main import cookiecutter
>   File "/usr/lib/python3/dist-packages/cookiecutter/main.py", line 15, in 
> 
> from .generate import generate_context, generate_files
>   File "/usr/lib/python3/dist-packages/cookiecutter/generate.py", line 27, in 
> 
> from .hooks import run_hook
>   File "/usr/lib/python3/dist-packages/cookiecutter/hooks.py", line 13, in 
> 
> from cookiecutter import utils
>   File "/usr/lib/python3/dist-packages/cookiecutter/utils.py", line 19, in 
> 
> from .prompt import read_user_yes_no
>   File "/usr/lib/python3/dist-packages/cookiecutter/prompt.py", line 14, in 
> 
> from past.builtins import basestring
>   File "/usr/lib/python3/dist-packages/past/__init__.py", line 88, in 
> from past.translation import install_hooks as autotranslate
>   File "/usr/lib/python3/dist-packages/past/translation/__init__.py", line 
> 41, in 
> from lib2to3.pgen2.parse import ParseError
> ModuleNotFoundError: No module named 'lib2to3'
>...

These are duplicates of #896597 in python3-future:

>>> import past
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/past/__init__.py", line 88, in 
from past.translation import install_hooks as autotranslate
  File "/usr/lib/python3/dist-packages/past/translation/__init__.py", line 41, 
in 
from lib2to3.pgen2.parse import ParseError
ModuleNotFoundError: No module named 'lib2to3'
>>> 


> Helmut

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#681326: pristine-tar: Directly accessing .git directory

[Antonio Terceiro]

On Mon, Apr 23, 2018 at 01:49:29PM +0100, Ian Jackson wrote:
> FYI, working trees generated by `git worktree' also have a file rather
> than a directory as .git.  So this bug in pristine-tar will stop it
> working properly in those, too.
> 
> Ie the problem is not limited to submodules.  I mention this because
> no-one in their right mind would use submodules :-) whereas
> `git worktree' is a very nice feature.

just tried private-tar with a worktree and AFAICT it just works. do you
have a specific test case that fails?


signature.asc
Description: PGP signature

Bug#896644: (no subject)

[Kyle Edwards]

This is happening to me too.

Bug#896597: python3-future: depend on python3-lib2to3

[Adrian Bunk]

Control: tags -1 - moreinfo

On Sun, Apr 22, 2018 at 09:10:22PM +0300, Adrian Bunk wrote:
> Control: tags -1 moreinfo
> 
> On Sun, Apr 22, 2018 at 07:46:48PM +0200, Matthias Klose wrote:
> > Package: src:python-future
> > Version: 0.15.2-4
> > Severity: serious
> > Tags: sid buster patch
> > 
> > lib2to3 now lives in it's own package. python3-future needs a dependency pn
> > python3-lib2to3.
> >...
> 
> Please provide the actual error message,
> I cannot see why this would be required.

Found it after more searching:

>>> import past
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/past/__init__.py", line 88, in 
from past.translation import install_hooks as autotranslate
  File "/usr/lib/python3/dist-packages/past/translation/__init__.py", line 41, 
in 
from lib2to3.pgen2.parse import ParseError
ModuleNotFoundError: No module named 'lib2to3'
>>> 

It would avoid wasting time if such information is in the bug report.


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#896701: drupal7: CVE-2018-7602: SA-CORE-2018-004

[Salvatore Bonaccorso]

Source: drupal7
Version: 7.32-1
Severity: grave
Tags: security upstream

Hi,

The following vulnerability was published for drupal7.

CVE-2018-7602[0]:
SA-CORE-2018-004

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-2018-7602
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7602
[1] https://www.drupal.org/psa-2018-003

Regards,
Salvatore

Bug#895769: Forwarded upstream

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/scikit-image/scikit-image/issues/3025

Bug#896699: transmission FTCBFS: missing Build-Depends: qt5-qmake:native for lrelease

[Helmut Grohne]

Source: transmission
Version: 2.93-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

transmission fails to cross build from source, because it fails running
lrelease. For using lrelease you must Build-Depends: qt5-qmake:native.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru transmission-2.93/debian/changelog 
transmission-2.93/debian/changelog
--- transmission-2.93/debian/changelog  2018-04-22 01:19:08.0 +0200
+++ transmission-2.93/debian/changelog  2018-04-22 14:18:29.0 +0200
@@ -1,3 +1,10 @@
+transmission (2.93-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix missing qt5-qmake:native in Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 22 Apr 2018 14:18:29 +0200
+
 transmission (2.93-1) unstable; urgency=medium
 
   * New upstream release; Closes: #890325, #857511, #895869
diff --minimal -Nru transmission-2.93/debian/control 
transmission-2.93/debian/control
--- transmission-2.93/debian/control2018-04-22 01:19:08.0 +0200
+++ transmission-2.93/debian/control2018-04-22 14:18:26.0 +0200
@@ -18,6 +18,7 @@
libssl-dev,
libsystemd-dev [linux-any],
qt5-qmake,
+   qt5-qmake:native,
qtbase5-dev,
qttools5-dev-tools,
zlib1g-dev

Bug#896700: gnome-session: after gnome startup process CLUTTER_BACKEND says x11, breaking clutter based applications

[Johannes Rohr]

Package: gnome-session
Version: 3.28.1-1
Severity: critical
Justification: breaks unrelated software

Please feel free to reassign as appropriate. Something during the gnome-session
startup process sets CLUTTER_BACKEND=x11

This breaks gnome-control-center:

(gnome-control-center:4903): Clutter-Gtk-ERROR **: 20:48:43.776: *** 
Unsupported backend.
Trace/Breakpoint ausgelöst

Probably breaks also other packages which use clutter.



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

Kernel: Linux 4.15.0-3-amd64 (SMP w/4 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 gnome-session depends on:
ii  gnome-session-bin  3.28.1-1
ii  gnome-session-common   3.28.1-1
ii  gnome-settings-daemon  3.28.1-1
ii  gnome-shell3.28.0-1+b1

gnome-session recommends no packages.

Versions of packages gnome-session suggests:
ii  desktop-base   9.0.5
ii  gnome-keyring  3.28.0.2-1

-- no debconf information

Bug#896698: autopkgtest: silently fails when 'needs-recommends' can't be installed

[Paul Gevers]

Package: autopkgtest
Version: 5.2
User: debian...@lists.debian.org
Usertags: issue

autopkgtest doesn't fail when apt can't install recommended packages.
This is caused by APT::Install-Recommends=true, which is what
autopkgtest uses to achieve this) not forcing apt to fail. apt can't be
forced to fail with that setting on missing recommends. Also that option
is transitive. Is that really wanted?

For a more detailed example, see the e-mail below.

 Forwarded Message 
Subject: Re: autopkgtest 'needs-recommends' with testing + unstable
Date: Sun, 22 Apr 2018 17:16:12 +0300
From: Niko Tyni 
To: debian...@lists.debian.org

On Sun, Apr 22, 2018 at 03:46:50PM +0200, Paul Gevers wrote:
> On 22-04-18 14:53, Niko Tyni wrote:
>> So afaics part of the issue is that when the 'needs-recommends'
>> test restriction cannot be fulfilled, autopkgtest doesn't notice
>> and report an error, but rather carries on and runs the test
>> regardless.
> 
> This (not bailing out) sounds like a bug in autopkgtest to me. I'll
> file one soon, based on your message. Although, if you want to file
> it yourself, please do so.

Some details: in


https://ci.debian.net/data/autopkgtest/testing/amd64/libs/libsearch-elasticsearch-perl/189195/log.gz

starting at 'test command3: preparing testbed' we see

  Investigating (0) libjson-xs-perl:amd64 < none -> 3.040-1 @un uN Ib >
  Broken libjson-xs-perl:amd64 Depends on libcommon-sense-perl:amd64 <
none | 3.74-2+b4 @un uH >
Considering libcommon-sense-perl:amd64 2 as a solution to
libjson-xs-perl:amd64 1
Holding Back libjson-xs-perl:amd64 rather than change
libcommon-sense-perl:amd64
  Investigating (0) libtypes-serialiser-perl:amd64 < none -> 1.0-1 @un
uN Ib >
  Broken libtypes-serialiser-perl:amd64 Depends on
libcommon-sense-perl:amd64 < none | 3.74-2+b4 @un uH >
Considering libcommon-sense-perl:amd64 2 as a solution to
libtypes-serialiser-perl:amd64 1
Holding Back libtypes-serialiser-perl:amd64 rather than change
libcommon-sense-perl:amd64
  Done
   Done

The test dependencies are just '@, pkg-perl-autopkgtest' with
'Restrictions: needs-recommends', so it's supposed to install
libsearch-elasticsearch-perl and its dependencies and recommendations.
The package Recommends libjson-xs-perl, which is uninstallable without
pulling libcommon-sense-perl:amd64 3.74-2+b5 from unstable. This doesn't
happen, so we get a failure:

#   Failed test '/usr/bin/perl -wc
/usr/share/perl5/Search/Elasticsearch/Serializer/JSON/XS.pm exited
successfully'
#   at
/usr/share/pkg-perl-autopkgtest/runtime-deps-and-recommends.d/syntax.t
line 121.

[...]

# Can't locate JSON/XS.pm in @INC (you may need to install the
JSON::XS module) (@INC contains: /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2
/usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at
/usr/share/perl5/Search/Elasticsearch/Serializer/JSON/XS.pm line 4.
# BEGIN failed--compilation aborted at
/usr/share/perl5/Search/Elasticsearch/Serializer/JSON/XS.pm line 4.

Similarly in
https://ci.debian.net/data/autopkgtest/testing/amd64/libp/libppi-perl/184151/log.gz
libppi-perl Recommends: libclass-xsaccessor-perl which is only
installable from unstable but doesn't get pulled in, which leads to a
failure. In this case apt is totally silent about the uninstallability
afaics.




signature.asc
Description: OpenPGP digital signature

Bug#891872: transition: curl

[Emilio Pozuelo Monfort]

On 01/03/18 22:31, Alessandro Ghedini wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> I'd like to request a transition for curl in order to unblock the migration
> to OpenSSL 1.1 (#871056). This is necessary due to the fact that the curl ABI
> exposes a structure inherited from libssl itself, which was changed in the 1.1
> update (see #844018 for more information).

I was looking at this in order to ack it. However I've noticed that libcurl4
conflicts against libcurl3. Why is that? That's going to make the transition
hard, can it be removed?

Hmm, I just realised libcurl3 ships libcurl.so.4, so that explains the conflict.
I just found the rationale for this in
https://salsa.debian.org/debian/curl/merge_requests/2. That means this will have
to wait until there are no conflicting ongoing transitions. I will ack this when
that time comes.

Cheers,
Emilio

Bug#893189: transition: llvm-defaults to llvm 6.0

[Sylvestre Ledru]

Le 23/04/2018 à 19:58, Emilio Pozuelo Monfort a écrit :
> Hi Sylvestre,
>
> On 28/03/18 00:10, Emilio Pozuelo Monfort wrote:
>> On 17/03/18 09:43, Sylvestre Ledru wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
>>>
>>> Hello,
>>>
>>> This is again the time to transition to a more recent version of LLVM.
>>> This time to 6.0. Just like in bug 832098 & 869752, I propose that we skip 
>>> one version (5.0 here)
>>>
>>> All supported archs are green:
>>> https://buildd.debian.org/status/package.php?p=llvm-toolchain-6.0=sid 
>>> 
>>> I am rebuilding the packages with v6.0.
>> How did the rebuild go?
> Any news here?

Not yet, sorry. been busy with other things!

S

Bug#896695: ITP: Qt5 port kbackup

[Scott Kitterman]

On Monday, April 23, 2018 05:34:33 PM you wrote:
> Package: kbackup
> Severity: normal
> 
>  I intend on packaging this.

I was the previous maintainer of the KDE4 version of kbackup and I support 
this (for avoidance of doubt).

Scott K

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

Bug#896312: closed by Thomas Goirand <z...@debian.org> (Bug#896312: fixed in python-sphinxcontrib.plantuml 0.5-4)

[Adrian Bunk]

Control: reopen -1

On Sat, Apr 21, 2018 at 03:24:03PM +, Debian Bug Tracking System wrote:
>...
>  python-sphinxcontrib.plantuml (0.5-4) unstable; urgency=medium
>  .
>* Add runtime sphinx depends (Closes: #896372, #896312).
>...
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3/dist-packages/sphinxcontrib/plantuml.py", line 19, 
> in 
> from sphinx.util.compat import Directive
> ImportError: cannot import name 'Directive'
>...

A missing dependency is actually not the only problem here, see
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896485#12
for background why this module is broken with sphinx 1.7.2.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#896343: Bug#896281: python-networkmanager: NetworkManager fails to import

[Simon McVittie]

On Mon, 23 Apr 2018 at 20:36:43 +0300, Adrian Bunk wrote:
> On Fri, Apr 20, 2018 at 10:01:05PM +0200, Helmut Grohne wrote:
> > After installing python-networkmanager importing the module NetworkManager
> > into a python interpreter fails with the following error:
...
> > dbus.exceptions.DBusException: org.freedesktop.DBus.Error.FileNotFound: 
> > Failed to connect to socket /var/run/dbus/system_bus_socket: No such file 
> > or directory
> >...
> 
> dbus is not running in a chroot (which is correct).

Ideally these modules would connect to the system bus on first use
(for instance when an interesting object is instantiated) instead of
connecting as a side-effect of being imported. That would allow the
contents of the module to be listed (for instance for sphinx autodoc)
without needing a system bus.

smcv

Bug#894770: java.lang.NullPointerException thrown while loading gnu.io.RXTXCommDriver

[Ying-Chun Liu (PaulLiu)]

Hi,

I got the same error messages.

I tried some minimal code using librxtx-java got the same messages.
Please check if I'm correct.


import java.util.*;
import gnu.io.*;

public class Test1 {
public Test1() {
Enumeration ports = CommPortIdentifier.getPortIdentifiers();
}
public static void main (String args[]) {
Test1 myTest1 = new Test1();
}
}



And save it as Test1.java
$ CLASSPATH=/usr/share/java/RXTXcomm.jar javac Test1.java
$ CLASSPATH=/usr/share/java/RXTXcomm.jar:. java Test1
java.lang.NullPointerException thrown while loading gnu.io.RXTXCommDriver
java.lang.NullPointerException thrown while loading gnu.io.RXTXCommDriver


So it seems to me that there are some problems in librxtx-java ?


Yours,
Paul
-- 
PaulLiu (劉穎駿)
E-mail: Ying-Chun Liu (PaulLiu) 



signature.asc
Description: OpenPGP digital signature

Bug#896677: RM: falkon/oldstable -- ROM; qupzilla is definetely replaced by falkon

[Adam D. Barratt]

Control: retitle -1 RM: qupzilla -- RoM; replaced by falkon

On Mon, 2018-04-23 at 15:03 +0200, Georges Khaznadar wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> The package falkon replaces now the package qupzilla. So it is no
> longer
> necessary to keep qupzilla's last built packages in debian/sid.

Yet you've requested the removal of *falkon*, not qupzilla. And sid is
*not* oldstable.

Regards,

Adam

Bug#896202: python-subliminal: subliminal fails to import

[Adrian Bunk]

Control: reassign -1 python-guessit
Control: forcemerge 896346 -1
Control: retitle -1 python-guessit: guessit fails to import
Control: affects -1 python-subliminal

On Fri, Apr 20, 2018 at 10:01:14PM +0200, Helmut Grohne wrote:
> Package: python-subliminal
> Version: 1.1.1-2
> Severity: serious
> User: helm...@debian.org
> Usertags: python-import
> 
> After installing python-subliminal importing the module subliminal
> into a python interpreter fails with the following error:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.7/dist-packages/subliminal/__init__.py", line 10, in 
> 
> from .api import (ProviderPool, check_video, provider_manager, 
> download_best_subtitles, download_subtitles,
>   File "/usr/lib/python2.7/dist-packages/subliminal/api.py", line 13, in 
> 
> from .subtitle import compute_score, get_subtitle_path
>   File "/usr/lib/python2.7/dist-packages/subliminal/subtitle.py", line 7, in 
> 
> from guessit.matchtree import MatchTree
>   File "/usr/lib/python2.7/dist-packages/guessit/__init__.py", line 99, in 
> 
> from guessit.plugins import transformers
>   File "/usr/lib/python2.7/dist-packages/guessit/plugins/transformers.py", 
> line 222, in 
> reload()
>   File "/usr/lib/python2.7/dist-packages/guessit/plugins/transformers.py", 
> line 220, in reload
> reload_options(all_transformers())
>   File "/usr/lib/python2.7/dist-packages/guessit/plugins/transformers.py", 
> line 179, in all_transformers
> return _extensions.objects()
>   File "/usr/lib/python2.7/dist-packages/guessit/plugins/transformers.py", 
> line 111, in objects
> return self.map(self._get_obj)
>   File "/usr/lib/python2.7/dist-packages/stevedore/extension.py", line 261, 
> in map
> raise NoMatches('No %s extensions found' % self.namespace)
> stevedore.exception.NoMatches: No guessit.transformer extensions found
>...

This is a duplicate of #896346 in python-guessit.

> Helmut

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#896696: lintian: please improve tag description to explain that python 2 modules are only questioned on 1st upload

[Chris Lamb]

Hi Holger,

> > For example, I think Holger is interpreting this particular tag as
> > "this source package is shipping a Python 2.x" module. This is not
> > the case. 
>
> Then the lintian message should be appended to say this only happens on
> the first upload.

It does, no? The current text is:

  Info: This package appears to be the initial packaging of a new upstream
   software package (ie. it contains a single changelog entry).

:)


Best wishes,

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

Bug#896697: dehydrated: Certificate file also contains chain for ACME v2

[Aurelien Jarno]

Source: dehydrated
Version: 0.6.1-1
Severity: important
Tags: upstream
Forwarded: https://github.com/lukas2511/dehydrated/issues/501

Since dehydrated switch to ACME V2 by default, the returned
fullchain.pem file contains the intermediate certificate twice.

The gnutls version on wheezy systems is not able to cope with that,
causing the certificate to be rejected. As a side effect build daemons
are not able to build wheezy-lts anymore:

https://buildd.debian.org/status/fetch.php?pkg=ruby1.8=armhf=1.8.7.358-7.1%2Bdeb7u6=1524480374=0

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

Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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#896354: python-neo: neo fails to import

[Adrian Bunk]

Control: reassign 896361 python-quantities
Control: forcemerge 896361 896354
Control: retitle 896354 python-quantities: quantities fails to import
Control: affects 896354 python-neo

On Fri, Apr 20, 2018 at 10:01:05PM +0200, Helmut Grohne wrote:
> Package: python-neo
> Version: 0.3.3-2
> Severity: serious
> User: helm...@debian.org
> Usertags: python-import
> 
> After installing python-neo importing the module neo
> into a python interpreter fails with the following error:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.7/dist-packages/neo/__init__.py", line 7, in 
> from neo.core import *
>   File "/usr/lib/python2.7/dist-packages/neo/core/__init__.py", line 42, in 
> 
> from neo.core.analogsignal import AnalogSignal
>   File "/usr/lib/python2.7/dist-packages/neo/core/analogsignal.py", line 30, 
> in 
> import quantities as pq
>   File "/usr/lib/python2.7/dist-packages/quantities/__init__.py", line 283, 
> in 
> from .units import *
>   File "/usr/lib/python2.7/dist-packages/quantities/units/__init__.py", line 
> 9, in 
> from . import acceleration
>   File "/usr/lib/python2.7/dist-packages/quantities/units/acceleration.py", 
> line 7, in 
> from .time import s
>   File "/usr/lib/python2.7/dist-packages/quantities/units/time.py", line 18, 
> in 
> aliases=['milliseconds']
>   File "/usr/lib/python2.7/dist-packages/quantities/unitquantity.py", line 
> 62, in __new__
> ret._conv_ref = definition._reference
>   File "/usr/lib/python2.7/dist-packages/quantities/quantity.py", line 139, 
> in _reference
> rq = rq * u._reference**d
>   File "/usr/lib/python2.7/dist-packages/quantities/unitquantity.py", line 
> 230, in __pow__
> return self.view(Quantity).__pow__(other)
>   File "/usr/lib/python2.7/dist-packages/quantities/quantity.py", line 88, in 
> g
> return f(self, other, *args)
>   File "/usr/lib/python2.7/dist-packages/quantities/quantity.py", line 321, 
> in __pow__
> return super(Quantity, self).__pow__(other)
>   File "/usr/lib/python2.7/dist-packages/quantities/quantity.py", line 236, 
> in __array_prepare__
> """
> ValueError: ufunc %r not supported by quantities
> please file a bug report at 
> https://github.com/python-quantities
>...

This is a duplicate of #896361 in python-quantities.

> Helmut

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#894159: transition: icu

[Emilio Pozuelo Monfort]

Hi László,

First of all, sorry for the delay. I saw there were several issues here and
decided to postpone this a bit. Please see some questions below.

On 26/03/18 22:29, László Böszörményi (GCS) wrote:
> It will need a quick bootstrap. It needs to build without the Layout
> Engine API, then the support library (icu-le-hb). Only then ICU can be
> built with the Layout Engine API as the two libraries tied together.

Can you explain that? Why can't you enable Layout Engine from the start?

> Some patches are simply adding '--with-icu=/usr' to the configure
> invocation in debian/rules. Others are for ICU detection in the
> configuration phase. No code change is needed in the packages.
> If it matters, Ubuntu already transitioned with a bit different method.

Are those changes and the large number of FTBFS because of the removal of
icu-config? Can we keep it for now and file bugs at severity:important for the
rdeps asking to fix the build when icu-config is removed? That should ease this
transition.

I would appreciate a number of failing rdeps and how many are due to ICU API
changes and how many are due to icu-config removal.

Cheers,
Emilio

Bug#893189: transition: llvm-defaults to llvm 6.0

[Emilio Pozuelo Monfort]

Hi Sylvestre,

On 28/03/18 00:10, Emilio Pozuelo Monfort wrote:
> On 17/03/18 09:43, Sylvestre Ledru wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>> Hello,
>>
>> This is again the time to transition to a more recent version of LLVM.
>> This time to 6.0. Just like in bug 832098 & 869752, I propose that we skip 
>> one version (5.0 here)
>>
>> All supported archs are green:
>> https://buildd.debian.org/status/package.php?p=llvm-toolchain-6.0=sid 
>> 
> 
>> I am rebuilding the packages with v6.0.
> 
> How did the rebuild go?

Any news here?

Thanks,
Emilio

Bug#896576: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#896576: Reading from /proc/[pid]/environ returns garbage)

[Guillaume]

Le 23/04/2018 à 02:27, Debian Bug Tracking System a écrit :
> The kernel only knows where it stored the environment for a process
> when it started.  If the process manipulates its environment after
> that, the kernel doesn't know about it.  This means that the "environ"
> file is not reliable, and this can't be fixed.  Sorry.

Thanks for the clarification, I now understand this isn't a kernel bug.

-- 
Jabber : guilla...@atto.be
PGP : 2054C46F0019B937

Bug#896696: lintian: please improve tag description to explain that python 2 modules are only questioned on 1st upload

[Holger Levsen]

package: lintian
severity: wishlist
x-debbugs-cc: debian-de...@lists.debian.org

On Mon, Apr 23, 2018 at 06:33:20PM +0100, Chris Lamb wrote:
> For example, I think Holger is interpreting this particular tag as
> "this source package is shipping a Python 2.x" module. This is not
> the case. 
> 
> Rather, Lintian detects that this is the *initial* upload of the
> source package and, if so, asks the maintainer just to double-check
> that there is any requirement for it.
> 
> If there is such a need, the maintainer just needs to add a short,
> quick justification in the initial changelog entry and Lintian will
> then be silent on the matter.
> 
> It is thus not asking maintainers to drop Python 2 support…

Then the lintian message should be appended to say this only happens on
the first upload.

Thanks.

> As there can only be one initial upload by definition, adding an
> override here is not only a little silly given that it will trigger
> an "unused override" warning on the next upload, it can simply be
> avoided in the changelog entry as previously discussed, which 
> implicitly serves as some documentation too.

Maybe it's also worth pointing this out.

> (This talk of overrides was why I believe Holger is accidentally
> confusing the tag.)
 
Yes. And because the tag description needs improving. ;)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#896220: python-lasagne: lasagne fails to import

[Adrian Bunk]

Control: reassign -1 python-theano 0.9.0+dfsg-2
Control: retitle -1 python-theano fails to load without nonexisting HOME
Control: affects -1 python-lasagne
Control: severity -1 important
Control: reassign 896421 python3-theano 0.9.0+dfsg-2
Control: retitle 896421 python3-theano fails to load with nonexisting HOME
Control: affects 896421 python3-lasagne
Control: severity 896421 important

On Fri, Apr 20, 2018 at 10:00:53PM +0200, Helmut Grohne wrote:
> Package: python-lasagne
> Version: 0.1+git20180322.37ca134-1
> Severity: serious
> User: helm...@debian.org
> Usertags: python-import
> 
> After installing python-lasagne importing the module lasagne
> into a python interpreter fails with the following error:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.7/dist-packages/lasagne/__init__.py", line 12, in 
> 
> import theano
>   File "/usr/lib/python2.7/dist-packages/theano/__init__.py", line 66, in 
> 
> from theano.compile import (
>   File "/usr/lib/python2.7/dist-packages/theano/compile/__init__.py", line 
> 10, in 
> from theano.compile.function_module import *
>   File "/usr/lib/python2.7/dist-packages/theano/compile/function_module.py", 
> line 21, in 
> import theano.compile.mode
>   File "/usr/lib/python2.7/dist-packages/theano/compile/mode.py", line 10, in 
> 
> import theano.gof.vm
>   File "/usr/lib/python2.7/dist-packages/theano/gof/vm.py", line 662, in 
> 
> from . import lazylinker_c
>   File "/usr/lib/python2.7/dist-packages/theano/gof/lazylinker_c.py", line 
> 42, in 
> location = os.path.join(config.compiledir, 'lazylinker_ext')
>   File "/usr/lib/python2.7/dist-packages/theano/configparser.py", line 333, 
> in __get__
> self.__set__(cls, val_str)
>   File "/usr/lib/python2.7/dist-packages/theano/configparser.py", line 344, 
> in __set__
> self.val = self.filter(val)
>   File "/usr/lib/python2.7/dist-packages/theano/configdefaults.py", line 
> 1745, in filter_compiledir
> " '%s'. Check the permissions." % path)
> ValueError: Unable to create the compiledir directory 
> '/nonexistent/.theano/compiledir_Linux-4.14--amd64-x86_64-with-debian-buster-sid--2.7.15rc1-64'.
>  Check the permissions.
>...

The problem is in theano.

And depending on the circumstances (I cannot judge it here) it might not 
even be a bug that this module expect a $HOME that points to a real location.

> Helmut

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#896412: python-napalm-eos: napalm_eos fails to import

[Adrian Bunk]

Control: reassign -1 python-napalm-base
Control: forcemerge 896250 -1
Control: affects 896250 python-napalm-eos

On Fri, Apr 20, 2018 at 10:01:04PM +0200, Helmut Grohne wrote:
> Package: python-napalm-eos
> Version: 0.6.1-1
> Severity: serious
> User: helm...@debian.org
> Usertags: python-import
> 
> After installing python-napalm-eos importing the module napalm_eos
> into a python interpreter fails with the following error:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.7/dist-packages/napalm_eos/__init__.py", line 16, in 
> 
> from napalm_eos.eos import EOSDriver
>   File "/usr/lib/python2.7/dist-packages/napalm_eos/eos.py", line 39, in 
> 
> import napalm_base.helpers
>   File "/usr/lib/python2.7/dist-packages/napalm_base/__init__.py", line 25, 
> in 
> import pkg_resources
> ImportError: No module named pkg_resources
>...

This is a duplicate of #896250 in python-napalm-base.

> Helmut

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#896695: ITP: Qt5 port kbackup

[Scarlett Clark]

Package: kbackup
Severity: normal

 I intend on packaging this.

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

Kernel: Linux 4.13.0-38-generic (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#896343: Bug#896281: python-networkmanager: NetworkManager fails to import

[Adrian Bunk]

Control: severity -1 normal

On Fri, Apr 20, 2018 at 10:01:05PM +0200, Helmut Grohne wrote:
> Package: python-networkmanager
> Version: 2.0.1-4
> Severity: serious
> User: helm...@debian.org
> Usertags: python-import
> 
> After installing python-networkmanager importing the module NetworkManager
> into a python interpreter fails with the following error:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.7/dist-packages/NetworkManager.py", line 99, in 
> 
> init_bus = dbus.SystemBus(private=True)
>   File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 194, in __new__
> private=private)
>   File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 100, in __new__
> bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
>   File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 122, in __new__
> bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.FileNotFound: 
> Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or 
> directory
>...

dbus is not running in a chroot (which is correct).

> Helmut

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#896275: python-nipy: nipy fails to import

[Adrian Bunk]

Control: reassign -1 python-nibabel 2.2.1-1
Control: reassign 896301 python-nibabel 2.2.1-1
Control: forcemerge -1 896301
Control: retitle -1 python-nibabel: missing dependency on python-six
Control: affects -1 python-nipy python-dcmstack

On Fri, Apr 20, 2018 at 10:01:05PM +0200, Helmut Grohne wrote:
> Package: python-nipy
> Version: 0.4.2-1
> Severity: serious
> User: helm...@debian.org
> Usertags: python-import
> 
> After installing python-nipy importing the module nipy
> into a python interpreter fails with the following error:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.7/dist-packages/nipy/__init__.py", line 32, in 
> 
> from nipy.io.api import load_image, save_image, as_image
>   File "/usr/lib/python2.7/dist-packages/nipy/io/api.py", line 3, in 
> from .files import load as load_image, save as save_image, as_image
>   File "/usr/lib/python2.7/dist-packages/nipy/io/files.py", line 19, in 
> 
> import nibabel as nib
>   File "/usr/lib/python2.7/dist-packages/nibabel/__init__.py", line 38, in 
> 
> from . import analyze as ana
>   File "/usr/lib/python2.7/dist-packages/nibabel/analyze.py", line 87, in 
> 
> from .volumeutils import (native_code, swapped_code, make_dt_codes,
>   File "/usr/lib/python2.7/dist-packages/nibabel/volumeutils.py", line 22, in 
> 
> from .casting import (shared_range, type_info, OK_FLOATS)
>   File "/usr/lib/python2.7/dist-packages/nibabel/casting.py", line 11, in 
> 
> from .testing import setup_test  # flake8: noqa F401
>   File "/usr/lib/python2.7/dist-packages/nibabel/testing/__init__.py", line 
> 29, in 
> from six.moves import zip_longest
> ImportError: No module named six.moves
>...

The missing dependency is in python-nibabel:

>>> import nibabel
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/nibabel/__init__.py", line 38, in 

from . import analyze as ana
  File "/usr/lib/python2.7/dist-packages/nibabel/analyze.py", line 87, in 

from .volumeutils import (native_code, swapped_code, make_dt_codes,
  File "/usr/lib/python2.7/dist-packages/nibabel/volumeutils.py", line 22, in 

from .casting import (shared_range, type_info, OK_FLOATS)
  File "/usr/lib/python2.7/dist-packages/nibabel/casting.py", line 11, in 

from .testing import setup_test  # flake8: noqa F401
  File "/usr/lib/python2.7/dist-packages/nibabel/testing/__init__.py", line 29, 
in 
from six.moves import zip_longest
ImportError: No module named six.moves
>>> 

> Helmut

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#893913:

[Scarlett Clark]

Control: retitle -1 ITP: qtspell -- spell-checking functionality to
Qt's text widgets

Bug#896341: python-strongwind: strongwind fails to import

[Adrian Bunk]

On Fri, Apr 20, 2018 at 10:01:13PM +0200, Helmut Grohne wrote:
> Package: python-strongwind
> Version: 0.9-2
> Severity: serious
> User: helm...@debian.org
> Usertags: python-import
> 
> After installing python-strongwind importing the module strongwind
> into a python interpreter fails with the following error:
> 
> 
> (process:19624): dbind-ERROR **: 19:20:12.267: AT-SPI: Couldn't connect to 
> accessibility bus. Is at-spi-bus-launcher running?
> Trace/breakpoint trap
>...

This is likely related to dbus not running in a chroot (which is correct).

But outside a chroot there is

>>> import strongwind
Error importing yaml module; tags will not be parsed
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/strongwind/__init__.py", line 33, in 

import procedurelogger
  File "/usr/lib/python2.7/dist-packages/strongwind/procedurelogger.py", line 
65, in 
import pyatspi
  File "/usr/lib/python2.7/dist-packages/pyatspi/__init__.py", line 21, in 

from pyatspi.Accessibility import *
  File "/usr/lib/python2.7/dist-packages/pyatspi/Accessibility.py", line 214, 
in 
RELATION_DETAILS = Atspi.RelationType.DETAILS
AttributeError: type object 'RelationType' has no attribute 'DETAILS'
>>> 

> Helmut

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#896675: lintian: false positive non-consecutive-debian-revision on source package rename

[Chris Lamb]

tags 896675 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/ffbf44fcadc5d6e2160425d5cba446c80f2e80cf

  checks/changelog-file.pm |  3 ++-
  debian/changelog |  4 
  .../debian/debian/changelog.in   | 12 
  .../changelog-file-consecutive-debian-revision-unrel/desc| 10 ++
  .../changelog-file-consecutive-debian-revision-unrel/tags|  1 +
  5 files changed, 29 insertions(+), 1 deletion(-)


Regards,

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

Bug#895570: devscripts: wrap-and-sort should default to -ast (--wrap-always, --short-indent, --trailing-comma)

[Daniel Kahn Gillmor]

On Mon 2018-04-23 14:10:02 +0200, Dominique Dumont wrote:
> I do believe that we should have one so tool writers can have a reference to 
> implement and people would not see changes when using different formatting or 
> generation tools (e.g dh-make-perl, cme, wrap-and-sort). 

makes sense to me.

> That said, I think that having formatting options (like --wrap-always --short-
> indent) kind of defeat that purpose because people have different ideas on 
> what looks best.

sure, but they're all wrong except for me, right? :P

> Back to cme and wrap-and-sort, I'd really like to converge on formatting so 
> that both tools provide the same output (I've already changed the way 
> dependencies are sorted to match wrap-and-sort algorithm).
>  
> If we allow formatting options, these options should be saved in a file 
> (should that be a local or global conf file ? or both ?) so that cme and wrap-
> and-sort can produce the same result with a simple command.

perhaps the options could go someplace like debian/source/canonicalize ?

--dkg

Bug#889027: quodlibet: New upstream version (4.0.2) available (Python 3 support)

[W. Martin Borgert]

Quoting Christoph Reiter :

In case of raven we use private API and senf never found any external
users so there is not much value I think.


In case of raven, we should use the official Debian package.
The two bugs in the package don't look difficult. (Famous last words!)

In case of senf, we can live with an embedded copy, I guess.

Bug#896676: pristine-tar: more convenient automatic mode please

[Ian Jackson]

Sean Whitton writes ("Re: Bug#896676: pristine-tar: more convenient automatic 
mode please"):
> On Mon, Apr 23 2018, Ian Jackson wrote:
> > I tried `git-deborig' (which Sean had mentioned to me before) and it
> > didn't invoke pristine-tar at all.
> 
> Yes.  I think that git-deborig and pristine-tar are orthogonal --
> pristine-tar is when you care about having the tarball with precisely
> the same checksum, whereas git-deborig is for when it's git tags that
> are authoritative.
> 
> origtargz is "a tarball has been settled on for this upload, get it for
> me please."

I have just read the manpage for origtargz.

I don't think origtargz is good for my usecase because it's too
automatic.  In particular, if I know I want to use a local
pristine-tar branch I don't want a command which might download
something from the network.

> pristine-tar is one way of settling on that tarball.
> 
> git-deborig is "my git tree is right, please give me a tarball because
> the Debian archive works that way."

git-deborig was more what I wanted.  I wouldn't have minded
having to ask `git-deborig --pristine-tar'.

> I think you probably want to file a bug against devscripts, too, in that
> case.

Let's finish the conversation and then I'll do some bug gardening.

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#896659: please build boot rom for QEMU

[Vagrant Cascadian]

On 2018-04-23, Michael Tokarev wrote:
> Please enable building of a boot rom suitable to boot a QEMU virtual machine,
> maybe u-boot-qemu-ppce500:
>
> $(MAKE) -C u-boot O=build.e500 qemu-ppce500_config
> $(MAKE) -C u-boot CROSS_COMPILE=$(powerpc_cross_prefix) O=build.e500
> $(powerpc_cross_prefix)strip u-boot/build.e500/u-boot -o \
> /usr/share/qemu/u-boot.e500
>
> (it should contain /usr/share/qemu/u-boot.e500 built the above way).

Any particular reason why that one specifically and/or that one only?

There are numerous other qemu related configurations available:

qemu-ppce500 qemu-x86_efi_payload64 qemu_mips64el qemu-x86_64 qemu_arm64
qemu_mips qemu-x86 qemu_arm qemu_mipsel qemu-x86_efi_payload32
qemu_mips64

There appears to be doc/README.qemu-arm doc/README.qemu-mips documenting
how to use those. Not sure how to make use of the other targets.

I'm wondering if it would make sense to make a u-boot-qemu package,
possibly one for each relevent architecture, or to build an arch:all
package with cross-compilers containing all of them. Building an
arch:all package would probably require more packaging changes, though
if it's really "the right thing" it would of course be worth
considering.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#896694: RM: jana -- ROM; dead upstream

[Ying-Chun Liu (PaulLiu)]

Package: ftp.debian.org
Severity: normal

Dear ftp-master,

Please remove "jana" from Debian archive. This package is a part of the
ancient Moblin project. It provides an interface for reading
time-related personal data, like personal calendars. But no one is
currently using this interface for consuming data. No one provides data
source for this interface neither.

I've been maintaining this library for 8 years already and doesn't think
that we need this library anymore.

Yours,
Paul

-- 
PaulLiu (劉穎駿)
E-mail: Ying-Chun Liu (PaulLiu) 



signature.asc
Description: OpenPGP digital signature

Bug#896676: pristine-tar: more convenient automatic mode please

[Sean Whitton]

Hello Ian,

On Mon, Apr 23 2018, Ian Jackson wrote:

> I tried `git-deborig' (which Sean had mentioned to me before) and it
> didn't invoke pristine-tar at all.

Yes.  I think that git-deborig and pristine-tar are orthogonal --
pristine-tar is when you care about having the tarball with precisely
the same checksum, whereas git-deborig is for when it's git tags that
are authoritative.

origtargz is "a tarball has been settled on for this upload, get it for
me please."

pristine-tar is one way of settling on that tarball.

git-deborig is "my git tree is right, please give me a tarball because
the Debian archive works that way."

> Now I know that it is, apparently, the Debian way to have
> difficult-to-use primary functionality with a plethora of competing
> wrapper scripts, sometimes even competing wrapper scripts within the
> same package (devscripts, in this case).
>
> But could we at least have a few cross references in the manpages ?

I think you probably want to file a bug against devscripts, too, in that
case.

> I notice that there is also a program `mk-origtargz'.  Is that
> different from `origtargz' ?

Yes.

devscripts has good manpages.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#889027: quodlibet: New upstream version (4.0.2) available (Python 3 support)

[W. Martin Borgert]

Quoting Ondřej Kuzník :

Would you be able to get the salsa repository created?


Yes, will do. Hopefully today or tomorrow.
I will send the link here.


If you want to do any of the above, let me know, but I'm happy to do the
work and would then ask if you'd be OK sponsoring the upload for me.


I'm always happy about other people doing the work :~)
Will sponsor gladly, of course!

Bug#896579: RFS: goodvibes/0.3.6-1 [ITP]

[Elías Alejandro]

Thanks! :D

Best regards,
Elías Alejandro

On Mon, Apr 23, 2018 at 12:21 PM, Sergio Durigan Junior
 wrote:
> On Monday, April 23 2018, Elías Alejandro wrote:
>
>> On Sun, Apr 22, 2018 at 11:37 PM, Sergio Durigan Junior
>>  wrote:
>>> Something else worth mentioning is the possibility to move the package
>>> repository from your personal namespace to the Debian namespace.  Please
>>> let me know if you have interest and I can set a repository there for
>>> you.
>> That could be great! Please let me know when you set a new repository.
>> Thanks Sergio!
>
> Done:
>
>   https://salsa.debian.org/debian/goodvibes
>
> I've added you as a Master, so you can set the repository up as you
> wish.
>
> Cheers,
>
> --
> Sergio
> GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
> Please send encrypted e-mail if possible
> http://sergiodj.net/

Bug#896019: libglib2.0-0: undefined symbol g_date_copy breaking many programs

[Simon McVittie]

On Mon, 23 Apr 2018 at 17:11:11 +0200, Michael Biebl wrote:
> @smcv: Do you think this is a failure of dpkg/apt cleaning up old
> versions? My suspicion is rather, that there is some old copy of libglib
> lying around in /lib/x86_64-linux which was copied there by some 3rd
> party installer, possibly lying around for years there.

That's entirely possible.

> @rektide: the time stamp of
> /lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0 would be interesting.

I already asked for "ls -il" output which would tell us the timestamp
(as well as whether various files are hard-links to each other).

> Does that coincide wit the installation of a proprietary/non-Debian
> package or the use of "make install"?

Whether there's a correlation with some other event is also interesting
information, though.

smcv

Bug#670798: Please, confirm this error

[Innocent De Marchi]

Hi jasen,

The connectagram package has been updated in Debian to the latest
version of the author. 

Please confirm if you can reproduce this error with the latest version
of the program. If it is not possible to reproduce the error, please
close this error report.

The author of the program remembers solving this problem a long time
ago.

Thank you!

I. De Marchi

Bug#883840: RFS: spglib/1.10.3-1 [ITP]

[Andrius Merkys]

On 04/23/2018 06:43 PM, Lumin wrote:
> Oh, I forgot to tell you that the failure is due to output to stderr.
> By redirecting
> the stderr to e.g. stdout, this failure can be fixed.

Thanks for pointing this out :) I had similar idea, but it would have taken me 
much longer to solve it.

> Please let me know if you think the package is ready. Then I'll check
> it again :-)

I suppose it's ready now. By the way, the package is already in NEW queue -- 
should I close this bug? Or is it possible to update a package already in the 
NEW?

Many thanks for help!
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania