Bug#831406: yorick FTBFS - linked to mpich

[Nicholas Breen]

block 831406 by 831442
thanks


The same bug is hitting one of my packages, seems to be an issue with mpich.
Filed as https://bugs.debian.org/831442 .



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

Bug#831443: dh-strip-nondeterminism: "Out of memory" (on 4G RAM) while while processing a png in glib2.0

[Helmut Grohne]

Package: dh-strip-nondeterminism
Version: 0.019-1
Severity: important
User: helm...@debian.org
Usertags: rebootstrap

I noticed that building glib2.0 (native or cross) started to fail for me
on some systems. The relevant part of the build log always is:

| dh_strip_nondeterminism -plibglib2.0-tests 
| Out of memory!
| /usr/share/cdbs/1/rules/debhelper.mk:302: recipe for target 
'binary-strip-IMPL/libglib2.0-tests' failed
| make: *** [binary-strip-IMPL/libglib2.0-tests] Error 1
| dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit 
status 2

So I reran dh_strip_nondeterminism under strace and saw

mmap(NULL, 4294971392, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = -1 ENOMEM (Cannot allocate memory)

as the last action before printing the "Out of memory" message. The last
file opened was


debian/libglib2.0-tests/usr/lib/glib2.0/installed-tests/glib/thumbnails/huge-chunk-size.png

which has a size of 512 bytes.

If you try reproducing the issue, "ulimit -v $((1024*1024*4))" can be
useful.

I'll be using

ln -sf /bin/true /usr/bin/dh_strip_nondeterminism

for now unless you can propose something better.

I was also thinking that since these files are deliberately broken,
maybe glib2.0 should explicitly --exclude them from
dh_strip_nondeterminism?

Helmut

Bug#831442: mpich: Broken /usr/lib/libmpich.so.12 symlink, depending on installation order

[Nicholas Breen]

Source: mpich
Version: 3.2-6
Severity: important

A symlink /usr/lib/libmpich.so.12 is created only depending on what order the
packages libmpich12 and libmpich-dev are installed in, apparently requiring
libmpich-dev to be unpacked before libmpich12 is configured.  In a clean
chroot:

  # dpkg --purge libmpich12 libmpich-dev
  # apt-get install libmpich12
  # apt-get install libmpich-dev
  # ls -l /usr/lib/libmpich.so.12
  ls: cannot access '/usr/lib/libmpich.so.12': No such file or directory

  # dpkg --purge libmpich12 libmpich-dev
  # apt-get install libmpich12 libmpich-dev
  # ls -l /usr/lib/libmpich.so.12
  lrwxrwxrwx 1 root root 9 Jul 16 05:12 /usr/lib/libmpich.so.12 -> libmpi.so

Because libmpi.so is part of the update-alternatives group with OpenMPI,
problems can result when they're both installed:

  # readlink -f /usr/lib/libmpich.so.12
  /usr/lib/x86_64-linux-gnu/libmpich.so.12.1.0
  # apt-get install libopenmpi-dev
  # readlink -f /usr/lib/libmpich.so.12
  /usr/lib/openmpi/lib/libmpi.so.12.0.3

This hits any package that builds against both MPI variants, causing failures
in dpkg-shlibdeps when it can't find MPICH symbols in /usr/lib/libmpich.so.12:
it's responsible for a FTBFS bug on yorick [1] and a whole bunch of build
failures on gromacs in experimental [2].  I don't know why it's suddenly a
problem now, but the buildds now seem to be installing the packages in the
order that triggers this problem more often than not.


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


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831406
[2] 
https://buildd.debian.org/status/fetch.php?pkg=gromacs=amd64=2016%7Erc1-2=1468635513
(also on eight other architectures and counting)

Bug#831441: RFP: pology -- in-depth processing of PO files

[Petter Reinholdtsen]

Package: wnpp
Severity: wishlist

* Package name: pology
  Version : 0.12
  Upstream Author : Chusslove Illich 
* URL : http://pology.nedohodnik.net/
* License : GPLv3
  Programming Lang: Python
  Description : in-depth processing of PO files

Pology is a Python library and collection of command-line tools for
in-depth processing of PO files, the translation file format of the GNU
Gettext software translation system. Pology functionality ranges from
precision operations on individual PO messages, to cross-file operations
on large collections of PO files.

A distinguishing aspect of Pology is that no attempt is made to handle
arbitrary translation file formats, as is typical of many translation
tools. Pology can thus take advantage not only of all technical aspects
of the PO format, but also of the established conventions and workflows
revolving around it and Gettext in general. This focus is present on all
levels, from the end-user commands to the library file format
abstractions.

The code is available from 
svn://anonsvn.kde.org/home/kde/trunk/l10n-support/pology

A document describing how to use pology to automatically translate po
files based on another language using apertium is available from
http://wiki.apertium.org/wiki/Translating_gettext >.  For example
this command can be used to create Norwegian Bokmål translations from
Swedish:

  pomtrans  -s sv -t nb -p _nb.:_sv. -M swe-nob apertium client_nb.po 

More information about Pology can be found from
https://techbase.kde.org/Localization/Tools/Pology#About >.

-- 
Happy hacking
Petter Reinholdtsen

Bug#817038: transifex-client: Use python-six instead of the embedded version of python-urllib3

[Petter Reinholdtsen]

[Christos Trochalakis 2016-03-07]
> Transifex imports six from urlilib3 embedded version.
> Since python-urllib3 (1.13.1-1) debian dropped the
> embedded six module which, although it makes sense, broke
> transifex-client.
> 
> Please consider applying the attached patch that switches
> imports to python-six.

[Sebastian Ramacher 2016-04-18]
> Raising the severity as this makes transifex-client unusable:

Thank you.  I was bit by the same issue just now when I needed to use the
tx client in unsable.

Is there something wrong with the proposed patch, or is there some other
reason the RC issue have not been adressed since March?

-- 
Happy hacking
Petter Reinholdtsen

Bug#830459: log4cpp: FTBFS: configure.in:44: error: required file 'config/compile' not found

[A . Maitland Bottoms]

It seemed to me that a bit of modernization in log4cpp packaging would
help fix this. I noticed upstream states that the 1.1.1 is the newest
stable release, and refactored the packaging around dh and
dh-autoreconf.

(I have not had time yet to build and test my packages with this
newer log4cpp, and I do hope that I can run abi-compliance-checker
soon and not be too surprised.)

Hope this helps,
-Maitland


log4cpp_1.1.1-1.debian.tar.xz
Description: log4cpp_1.1.1-1.debian.tar.xz

Bug#831396: procps: [ps] fails on kfreebsd

[Craig Small]

On Sat, Jul 16, 2016 at 1:21 AM Carsten Leonhardt  wrote:

> # ps
> Error: /proc must be mounted
>
/proc must be mounted basically means "I tried opening a file under /proc
and failed".

I just compiled procps 3.3.12 on the Debian kfreebsd machine asdfasdf and
worked fine.
Unfortunately I am unable to test it locally because the installer is
broken horribly; everything crashes, but I digress.

Kernel: kFreeBSD 10.3-0-amd64
asdfasdf has the following:
uname -a
GNU/kFreeBSD asdfasdf 9.0-2-amd64 #0 Sun May 17 20:12:58 UTC 2015 x86_64
amd64 AMD Sempron(tm) Processor 3000+ GNU/kFreeBSD

Could it be they have "improved" the procfs in some way from 9.x to 10.x?
Can you strace the ps command? I'm looking for opens under /proc that fail.

 - Craig

Bug#823014: [pkg-golang-devel] Bug#823014: Bug#823014: golang: Package compiled stdlib for PIE build mode

[Peter Colberg]

On Fri, Jul 15, 2016 at 04:04:26PM -0700, Tianon Gravi wrote:
> - the "Build-Profiles" bits -- I know we should be using
> build-profiles more intelligently throughout src:golang-X.Y, but is
> there something specific to PIE itself that makes it more
> necessary/appropriate than in the normal case?

It is not specific to PIE. When cross-compiling golang, the generated
compiler cannot be executed on the host, so the stdlib with PIE mode
cannot be built using that compiler.

I have to admit that I did not look at the golang build process in
detail yet. When finished, does it leave a stage1 compiler for the
host that could be reused to cross-compile PIE stdlib?

> - "golang-X.Y-go.install" currently has "pkg/*_*
> /usr/lib/go-X.Y/pkg/", which will still match
> "pkg/linux_amd64_shared", and thus include these files _both_ in
> "golang-1.6-std-pie" and "golang-1.6-go" -- I guess we need to fix
> that by using "dh_exec" and passing through our GOOS and GOARCH values
> instead of using globs?

That was my first and preferred solution, but I could not make dh_exec
pass GOARCH to the .install scripts, while DEB_HOST_MULTIARCH is passed
just fine. So now override_dh_install-arch moves the PIE stdlib to the
correct package after dh_install.

Peter

Bug#831440: icingaweb2: recommend/suggest php-json, php-intl and php-imagick

[Christoph Anton Mitterer]

Source: icingaweb2
Severity: normal


Hi.

When doing the websetup of Icinga Web2 it shows me which PHP modules
I have and which it would use.

May I suggest that you recommend/suggest:
php-json, php-intl and php-imagick
which are according to that web site used for:
PHP Module: JSONThe JSON module for PHP is required for various export 
functionalities as well as APIs
PHP Module: INTLIf you want your users to benefit from language, 
timezone and date/time format negotiation, the INTL module for PHP is required.
PHP Module: Imagick In case you want graphs being exported to PDF as well, 
you'll need the ImageMagick extension for PHP.

Yes I know, php7.0-json (but not php-json) is already depended upon indirectly
via the PHP SAPIs and via php-dompdf, but I think that would make it clear
that it's actually used by Icinga Web2 and should be enabled for it.

This:
PHP Module: GD  In case you want views being exported to PDF, you'll 
need the GD extension for PHP.
is already pulled in via the dependency on php-dompdf, but it seems
Icinga Web2 can use it independently of that as well (not sure about that)?
If that would be the case (some expert would need to check), than one could
make php-dompdf also just recommended.

Cheers,
Chris.

Bug#831439: vmdebootstrap: stretch image has no DNS setup

[Antonio Terceiro]

Package: vmdebootstrap
Version: 1.5-1+terceiro
Severity: important
Tags: patch

Hi, building a stretch image results in systemd-networkd enabled for
interfaces matching en*, and DHCP works, but DNS is not configured. You
end up with /etc/resolv.conf copied from the host machine when the image
was built.

To have resolv.conf properly setup when using systemd-networkd, you need
to also use systemd-resolved.

The attached patch does just that. I have tested locally, and the image
built gets proper a proper DNS setup, and everything works.



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

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

Versions of packages vmdebootstrap depends on:
ii  debootstrap 1.0.81
ii  extlinux3:6.03+dfsg-14
ii  kpartx  0.6.1-3
ii  libjs-sphinxdoc 1.4.5-1
ii  mbr 1.1.11-5+b1
ii  parted  3.2-15
ii  python-cliapp   1.20160316-1
ii  python-distro-info  0.14
ii  python2.7   2.7.12-1
pn  python:any  
ii  qemu-utils  1:2.6+dfsg-3

Versions of packages vmdebootstrap recommends:
ii  grub2-common  2.02~beta2-36
ii  python-guestfs1:1.32.6-1
ii  qemu-system   1:2.6+dfsg-3
ii  qemu-user-static  1:2.6+dfsg-3
ii  squashfs-tools1:4.3-3

Versions of packages vmdebootstrap suggests:
pn  cmdtest   
ii  pandoc1.17.0.3~dfsg-2+b1
pn  u-boot:armhf  

-- no debconf information

-- 
Antonio Terceiro 
Description: Enable systemd-resolved together with systemd-networkd
 Without systemctl-resolved, DNS servers informed by DHCP and received by
 systemd-networkd will not be used to update /etc/resolv.conf
Author: Antonio Terceiro 

--- vmdebootstrap-1.5.orig/vmdebootstrap/network.py
+++ vmdebootstrap-1.5/vmdebootstrap/network.py
@@ -101,3 +101,8 @@ class Networking(Base):
 eth.write('\n[Network]\n')
 eth.write('DHCP=yes\n')
 runcmd(['chroot', rootdir, 'systemctl', 'enable', 'systemd-networkd'])
+
+self.message('Enabling systemctl-resolved for DNS')
+runcmd(['chroot', rootdir, 'systemctl', 'enable', 'systemd-resolved'])
+runcmd(['chroot', rootdir, 'ln', '-sfT',
+'/run/systemd/resolve/resolv.conf', '/etc/resolv.conf'])


signature.asc
Description: PGP signature

Bug#831240: google-perftools: FTBFS: Running death test 0 hangs

[Aliaksey Kandratsenka]

Thanks for reporting the issue. I just tried to reproduce the problem
on my sid laptop in cleanly deboostrap-ed sid chroot and was unable to
hit this issue. This maybe indicates that kernel matters or maybe
there is something else in the host that is relevant. Can you please
share more details on how I can reproduce this? Also let me note once
again that 2.2.1 is much outdated and latest upstream is 2.4, although
I don't think we fixed anything related to death tests recently.


On Thu, Jul 14, 2016 at 3:06 AM, Lucas Nussbaum  wrote:
> Source: google-perftools
> Version: 2.2.1-0.3
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20160714 qa-ftbfs
> Justification: FTBFS on amd64
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part (hopefully):
>> PASS: malloc_extension_debug_test
>> PASS
>> PASS: memalign_debug_unittest
>> PASS
>> PASS: realloc_debug_unittest
>> make[2]: *** wait: No child processes.  Stop.
>> make[2]: *** Waiting for unfinished jobs
>> make[2]: *** wait: No child processes.  Stop.
>> make[1]: *** wait: No child processes.  Stop.
>> make[1]: *** Waiting for unfinished jobs
>> make[1]: *** wait: No child processes.  Stop.
>> make: *** wait: No child processes.  Stop.
>> make: *** Waiting for unfinished jobs
>> make: *** wait: No child processes.  Stop.
>> E: Caught signal ‘Terminated’: terminating immediately
>> Running death test 0Build killed with signal TERM after 150 minutes of 
>> inactivity
>
> The full build log is available from:
>
> http://people.debian.org/~lucas/logs/2016/07/14/google-perftools_2.2.1-0.3_unstable_gcc5.log
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
>

Bug#724461: (no subject)

[Mike]

This is still an issue in 4.3-11+b1.

Bug#827557: Acknowledgement (linux-image-4.6.0-1-armmp-lpae: 4.6 armmp kernel fails to boot on nvidia jetson (4.5 works))

[Wookey]

On 2016-06-17 18:27 +, Debian Bug Tracking System wrote:

Using the latest 4.6.3-1 version of this package does not change the issue.

Here is the output from the failed boot:

--
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0...
Found U-Boot script /boot.scr
2440 bytes read in 27 ms (87.9 KiB/s)
## Executing script at 9000
3637048 bytes read in 169 ms (20.5 MiB/s)
64138 bytes read in 86 ms (727.5 KiB/s)
16334316 bytes read in 480 ms (32.5 MiB/s)
Booting Debian 4.6.0-1-armmp from mmc 0:1...
Kernel image @ 0x8100 [ 0x00 - 0x377f38 ]
## Flattened Device Tree blob at 8200
   Booting using the fdt blob at 0x8200
   Using Device Tree in place at 8200, end 82012a89
Starting kernel ...

[0.00] Tegra clk 127: register failed with -17
[0.068144] /cpus/cpu@0 missing clock-frequency property
[0.068194] /cpus/cpu@1 missing clock-frequency property
[0.068239] /cpus/cpu@2 missing clock-frequency property
[0.068286] /cpus/cpu@3 missing clock-frequency property
[0.158867] +USB0_VBUS_SW: Failed to request enable GPIO108: -517
[0.158885] reg-fixed-voltage regulators:regulator@7: Failed to register 
regulator: -517
[0.159005] +5V_USB_HS: Failed to request enable GPIO109: -517
[0.159021] reg-fixed-voltage regulators:regulator@8: Failed to register 
regulator: -517
[0.159243] +1.05V_RUN_AVDD_HDMI_PLL: Failed to request enable GPIO63: -517
[0.159258] reg-fixed-voltage regulators:regulator@11: Failed to register 
regulator: -517
[0.159375] +5V_HDMI_CON: Failed to request enable GPIO86: -517
[0.159391] reg-fixed-voltage regulators:regulator@12: Failed to register 
regulator: -517
[0.159508] +5V_SATA: Failed to request enable GPIO242: -517
[0.159523] reg-fixed-voltage regulators:regulator@13: Failed to register 
regulator: -517
[0.159638] +12V_SATA: Failed to request enable GPIO242: -517
[0.159654] reg-fixed-voltage regulators:regulator@14: Failed to register 
regulator: -517
[1.720038] tegra-pcie 1003000.pcie-controller: Failed to get supply 
'avddio-pex': -517
[1.918190] tegra-pcie 1003000.pcie-controller: Slot present pin change, 
signature: 0008
[2.330537] tegra-pcie 1003000.pcie-controller: link 0 down, retrying
[2.743653] tegra-pcie 1003000.pcie-controller: link 0 down, retrying
[3.156872] tegra-pcie 1003000.pcie-controller: link 0 down, retrying
[3.167450] tegra-pcie 1003000.pcie-controller: Slot present pin change, 
signature: 
[3.589677] mmc0: Unknown controller version (3). You may experience 
problems.
[3.650454] mmc1: Unknown controller version (3). You may experience 
problems.
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
  /dev/mmcblk1rpmb: read failed after 0 of 4096 at 0: Input/output error
  /dev/mmcblk1rpmb: read failed after 0 of 4096 at 4128768: Input/output error
  /dev/mmcblk1rpmb: read failed after 0 of 4096 at 4186112: Input/output error
  /dev/mmcblk1rpmb: read failed after 0 of 4096 at 4096: Input/output error
  /dev/mapper/tegra-debian--root: recovering journal
  /dev/mapper/tegra-debian--root: clean, 39411/1831424 files, 434011/7323648 
blocks
[   13.311582] tegra-snd-rt5640 sound: ASoC: CPU DAI (null) not registered
[   13.318332] tegra-snd-rt5640 sound: snd_soc_register_card failed (-517)
[   13.328334] tegra-snd-rt5640 sound: ASoC: CPU DAI (null) not registered
[   13.335000] tegra-snd-rt5640 sound: snd_soc_register_card failed (-517)
[   13.625987] tegra-snd-rt5640 sound: ASoC: CPU DAI (null) not registered
[   13.632660] tegra-snd-rt5640 sound: snd_soc_register_card failed (-517)
---

At which point it seems to have hung.


A successful boot with 4.5.0 looks like this:

---
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0...
Found U-Boot script /boot.scr
2445 bytes read in 27 ms (87.9 KiB/s)
## Executing script at 9000
** File not found /vmlinuz-4.6.0-1-armmp-lpae **
3655488 bytes read in 217 ms (16.1 MiB/s)
64138 bytes read in 112 ms (558.6 KiB/s)
16263429 bytes read in 472 ms (32.9 MiB/s)
Booting Debian from mmc 0:1...
Kernel image @ 0x8100 [ 0x00 - 0x37c740 ]
## Flattened Device Tree blob at 8200
   Booting using the fdt blob at 0x8200

EHCI failed to shut down host controller.
   Using Device Tree in place at 8200, end 82012a89

Starting kernel ...

[0.00] L2C: failed to init: -19
[0.00] Tegra clk 127: register failed with -17
[0.055528] /cpus/cpu@0 missing clock-frequency property
[0.055576] /cpus/cpu@1 missing clock-frequency property
[0.055621] /cpus/cpu@2 missing clock-frequency property
[0.055666] /cpus/cpu@3 missing clock-frequency property
[0.141445] +USB0_VBUS_SW: Failed to request enable GPIO108: -517
[0.141599] reg-fixed-voltage regulators:regulator@7: Failed to register 
regulator: -517
[

Bug#830329: qwt: FTBFS: dh_makeshlibs: failing due to earlier errors

[Lisandro Damián Nicanor Pérez Meyer]

On viernes, 15 de julio de 2016 10:36:27 P. M. ART Lisandro Damián Nicanor 
Pérez Meyer wrote:
[snip] 
> I really *love* them (I haven't used cme before, someday I'll need to
> investigate that one). Sadly I think applying them without the maintainer's
> approval it's a bad idea.

It is worth to note here that the last upload was marked as "Team upload" 
because it was prepared by Gudjon and I while we where working towards pushin 
qwt with qt5 support to unstable and I just coordinated with Gudjon to do the 
upload.

I'm really not too interested in maintaining qwt myself, I just happen to have 
another package that requires it too.


-- 
$ make war
make: *** No rule to make target `war'.  Stop.  Try `love' instead
  David Gravereaux

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


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

Bug#830329: qwt: FTBFS: dh_makeshlibs: failing due to earlier errors

[Lisandro Damián Nicanor Pérez Meyer]

Hi Bas!


On sábado, 16 de julio de 2016 2:57:42 A. M. ART Sebastiaan Couwenberg wrote:
> Hi Lisandro,
[snip]
> On 07/16/2016 02:50 AM, Sebastiaan Couwenberg wrote:
> > As the uploader of the last couple qwt revisions, can you upload a new
> > revision to fix this issue?

I was planning to do so in case Gudjon didn't reply, so I guess yes :)
 
> > I'd like to prevent the removal of the qwt reverse dependencies, so I've
> > updated the package to resolve this RC bug and fix a bunch of unrelated
> > issues along the way.
>
> > From the attached patches only the first three are needed to fix this RC
> > bug, specifically the third.

Actually the third patch is really not desired when maintaining a lib that 
tends to break api/abi like qwt did in the last version, so I won't apply it.

I've looked at the symbols changes and I'll apply the first two patches and 
add some optional tags to prevent further FTBFSs. The ones you marked in amd64 
will surely happen on other archs. But they are destructors added by the 
compiler, so they are safe to be marked as optional.

> > The other patches are general improvements
> > to the packaging, please consider applying them as well.

I really *love* them (I haven't used cme before, someday I'll need to 
investigate that one). Sadly I think applying them without the maintainer's 
approval it's a bad idea.

Gudjon: please consider patches starting from 0004-...

Kinds regards, Lisandro.

-- 
Passwords are like underwear. You shouldn’t leave them out where people can
see them. You should change them regularly. And you shouldn’t loan them out
to strangers.
  Anonymous

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


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

Bug#831124: guitarix: FTBFS with GCC 6: ../libgxwmm/gxwmm/gainline.h:25:110: error: call of overloaded 'abs(double)' is ambiguous

[Hermann Meyer]

Hi

This is already fixed in upstream on 2016-05-16
here is the fix commit:
https://sourceforge.net/p/guitarix/git/ci/975b3b5cbd6b7b8a74f4da9eb687c9af8538178c/

regards
hermann

Bug#823600: libfcgi: please make libfcgi-dev Multi-Arch: same

[Christian Hofstaedtler]

* Helmut Grohne  [160716 01:22]:
> On Fri, May 06, 2016 at 01:56:16PM +0200, Helmut Grohne wrote:
> >  * It bumps the debhelper compatibility level from 7 to 9, because
> >debhelper 9 makes supporting multiarch much easier.
> >  * It adds a new binary package libfcgi-bin and thus goes through NEW.
> >  * It doesn't pass simple piuparts, because piuparts does not handle
> >complex upgrades that involve multiple packages by default (see
> >#766543).

I had a quick look at the diff and also did a build-test of
ruby-fcgi with the new libfcgi-dev; LGTM.

> I am uploading the slightly updated (only d/changelog) patch attached as
> a NMU to delayed/15.

DELAYED/0 would also have worked I think :-)

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#830329: qwt: FTBFS: dh_makeshlibs: failing due to earlier errors

[Sebastiaan Couwenberg]

Hi Lisandro,

The patches now actually attached.

On 07/16/2016 02:50 AM, Sebastiaan Couwenberg wrote:
> As the uploader of the last couple qwt revisions, can you upload a new
> revision to fix this issue?
> 
> I'd like to prevent the removal of the qwt reverse dependencies, so I've
> updated the package to resolve this RC bug and fix a bunch of unrelated
> issues along the way.
> 
> From the attached patches only the first three are needed to fix this RC
> bug, specifically the third. The other patches are general improvements
> to the packaging, please consider applying them as well.

Kind Regards,

Bas

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


0001-Update-symbols-for-sparc64-x32.patch
Description: inode/symlink


0002-Update-symbols-for-amd64.patch
Description: inode/symlink


0003-Override-dh_makeshlibs-to-not-fail-on-symbols-change.patch
Description: inode/symlink


0004-Enable-bindnow-hardening-buildflags.patch
Description: inode/symlink


0005-Update-Vcs-Browser-URL-to-use-HTTPS.patch
Description: inode/symlink


0006-Update-copyright-file-using-copyright-format-1.0.patch
Description: inode/symlink


0007-Bump-debhelper-compatibility-to-9.patch
Description: inode/symlink


0008-Override-dh_install-to-use-list-missing-instead-of-a.patch
Description: inode/symlink


0009-Override-dh_installman-to-remove-_tmp_-files.patch
Description: inode/symlink


0010-Discard-manpages-installed-by-buildsystem-use-dh_ins.patch
Description: inode/symlink


0011-Install-pkg-config-files-in-their-respective-dev-pac.patch
Description: inode/symlink


0012-Restructure-control-file-with-cme.patch
Description: inode/symlink


0013-Drop-unused-substitution-variables.patch
Description: inode/symlink


0014-Update-03_fix_spelling.patch-to-fix-additional-spell.patch
Description: inode/symlink


0015-Bump-Standards-Version-to-3.9.8-changes-copyright-fo.patch
Description: inode/symlink

Bug#831438: Completion should not emit errors for symbolic refs with no target

[Josh Triplett]

Package: git
Version: 1:2.8.1-1
Severity: normal

If a repository contains a symbolic ref whose target does not exist yet
(similar to how HEAD looks when pointing to an unborn branch that
doesn't have any commits yet), tab completion for many commands, such as
git branch or git checkout, will emit errors like "warning: ignoring
broken ref refs/SYMREF" repeatedly during completion.  I don't think it
makes sense to emit such errors during completion.

- Josh Triplett

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

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

Versions of packages git depends on:
ii  git-man   1:2.8.1-1
ii  libc6 2.23-1
ii  libcurl3-gnutls   7.47.0-1
ii  liberror-perl 0.17-1.3
ii  libexpat1 2.2.0-1
ii  libpcre3  2:8.38-3.1
ii  perl-modules-5.22 [perl-modules]  5.22.2-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages git recommends:
ii  less 481-2.1
ii  openssh-client [ssh-client]  1:7.2p2-5
ii  patch2.7.5-1
ii  rsync3.1.1-3

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-1
pn  git-arch  
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
ii  git-svn   1:2.8.1-1
ii  gitk  1:2.8.1-1
pn  gitweb

-- no debconf information

Bug#830329: qwt: FTBFS: dh_makeshlibs: failing due to earlier errors

[Sebastiaan Couwenberg]

Control: tags -1 patch

Hi Lisandro,

As the uploader of the last couple qwt revisions, can you upload a new
revision to fix this issue?

I'd like to prevent the removal of the qwt reverse dependencies, so I've
updated the package to resolve this RC bug and fix a bunch of unrelated
issues along the way.

>From the attached patches only the first three are needed to fix this RC
bug, specifically the third. The other patches are general improvements
to the packaging, please consider applying them as well.

Kind Regards,

Bas

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

Bug#819856: dnsmasq: diff for NMU version 2.76-1.2

[zeha]

Control: tags 819856 + patch
Control: tags 819856 + pending

Dear maintainer,

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

Best,
Chris


diff -u dnsmasq-2.76/debian/changelog dnsmasq-2.76/debian/changelog
--- dnsmasq-2.76/debian/changelog
+++ dnsmasq-2.76/debian/changelog
@@ -1,3 +1,11 @@
+dnsmasq (2.76-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * dnsmasq: Install marker file to determine package installed state,
+for the benefit of the init script. (Closes: #819856)
+
+ -- Christian Hofstaedtler   Sat, 16 Jul 2016 00:17:57 +
+
 dnsmasq (2.76-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u dnsmasq-2.76/debian/init dnsmasq-2.76/debian/init
--- dnsmasq-2.76/debian/init
+++ dnsmasq-2.76/debian/init
@@ -33,7 +33,7 @@
 # The following test ensures the dnsmasq service is not started, when the
 # package 'dnsmasq' is removed but not purged, even if the dnsmasq-base 
 # package is still in place.
-test -d /usr/share/doc/dnsmasq || exit 0
+test -e /usr/share/dnsmasq/installed-marker || exit 0
  
 test -x $DAEMON || exit 0
 
diff -u dnsmasq-2.76/debian/rules dnsmasq-2.76/debian/rules
--- dnsmasq-2.76/debian/rules
+++ dnsmasq-2.76/debian/rules
@@ -105,6 +105,7 @@
-d debian/daemon/etc/dnsmasq.d \
-d debian/daemon/etc/resolvconf/update.d \
-d debian/daemon/usr/lib/resolvconf/dpkg-event.d \
+   -d debian/daemon/usr/share/dnsmasq \
-d debian/daemon/etc/default \
-d debian/daemon/lib/systemd/system \
 -d debian/daemon/etc/insserv.conf.d
@@ -113,6 +114,7 @@
install -m 755 debian/init debian/daemon/etc/init.d/dnsmasq
install -m 755 debian/resolvconf 
debian/daemon/etc/resolvconf/update.d/dnsmasq
install -m 755 debian/resolvconf-package 
debian/daemon/usr/lib/resolvconf/dpkg-event.d/dnsmasq
+   install -m 644 debian/installed-marker debian/daemon/usr/share/dnsmasq
install -m 644 debian/default debian/daemon/etc/default/dnsmasq
install -m 644 dnsmasq.conf.example debian/daemon/etc/dnsmasq.conf
install -m 644 debian/readme.dnsmasq.d 
debian/daemon/etc/dnsmasq.d/README
only in patch2:
unchanged:
--- dnsmasq-2.76.orig/debian/installed-marker
+++ dnsmasq-2.76/debian/installed-marker
@@ -0,0 +1,2 @@
+# This file indicates dnsmasq (and not just dnsmasq-base) is installed.
+# It is an implementation detail of the dnsmasq init script.

Bug#831437: RFP -> ITP.

[Ben Albrecht]

Package: wnpp
Followup-For: Bug #831437
Owner: Ben Albrecht 

 I have built this package and am submitting for review by a sponsor.

Bug#830729: [pkg-go] Bug#830729: golang-github-mitchellh-go-homedir: FTBFS: homedir_test.go:44: "/home/lamby" != "~"

[Tianon Gravi]

On 10 July 2016 at 13:30, Chris Lamb  wrote:
> go install -v github.com/mitchellh/go-homedir
>   github.com/mitchellh/go-homedir
>  debian/rules override_dh_auto_test
>   make[1]: Entering directory 
> '/home/lamby/temp/cdt.20160710222637.V3OyQr9oAG.golang-github-mitchellh-go-homedir/golang-github-mitchellh-go-homedir-0.0~git20150831.0.df55a15'
>   # explicitly unset HOME to force tests to shell out
>   HOME= dh_auto_test
> go test -v github.com/mitchellh/go-homedir
>   === RUN   TestDir
>   --- FAIL: TestDir (0.00s)
> homedir_test.go:44: "/home/lamby" != "~"
>   === RUN   TestExpand
>   --- FAIL: TestExpand (0.00s)
> homedir_test.go:97: Input: "~/foo"
>
> Output: "~/foo"
>   FAIL
>   exit status 1
>   FAIL  github.com/mitchellh/go-homedir 0.005s
>   dh_auto_test: go test -v github.com/mitchellh/go-homedir returned exit code 
> 1
>   debian/rules:4: recipe for target 'override_dh_auto_test' failed
>   make[1]: *** [override_dh_auto_test] Error 1
>   make[1]: Leaving directory 
> '/home/lamby/temp/cdt.20160710222637.V3OyQr9oAG.golang-github-mitchellh-go-homedir/golang-github-mitchellh-go-homedir-0.0~git20150831.0.df55a15'

I can't seem to reproduce this failure. :(


   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
# explicitly unset HOME to force tests to shell out
HOME= dh_auto_test
go test -v -p 1 github.com/mitchellh/go-homedir
=== RUN   TestDir
--- PASS: TestDir (0.00s)
=== RUN   TestExpand
--- PASS: TestExpand (0.00s)
PASS
ok   github.com/mitchellh/go-homedir 0.010s
make[1]: Leaving directory '/<>'
 fakeroot debian/rules binary
dh binary --buildsystem=golang --with=golang
   dh_testroot -O--buildsystem=golang
   dh_prep -O--buildsystem=golang
   dh_auto_install -O--buildsystem=golang


♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#811670: FTBFS with GCC 6: cannot convert x to y

[Andreas Steigmiller]

Hi Jonas,

Many thanks for maintaining the packaging of Konclude for Debian and for 
reporting this problem. I fixed the compilation errors and zipped a new source 
code package of version 0.6.2 that can be downloaded with the following link 
(it is also available on Konclude's webpage):

http://www.derivo.de/fileadmin/externe_websites/ext.derivo/KoncludeReleases/v0.6.2-544/Konclude-v0.6.2-544-SourceCode-GCC6Fixes.zip

Of course, we will also include the fixes in the next release.

Best,

Andreas

Am 15.07.2016 um 12:43 schrieb Jonas Smedegaard:
> Hi Konclude Developer Team,
>
> I maintail the packaging of Konclude for Debian.
>
> My fellow developer, Martin, have discovered that Konclude fails to 
> compile succesfully with the most recent GNU compiler, GCC 6.
>
> Any help resolving this is quite appreciated.
>
> Quoting Martin Michlmayr (2016-01-20 01:48:28)
>> This package fails to build with GCC 6.  GCC 6 has not been released 
>> yet, but it's expected that GCC 6 will become the default compiler for 
>> stretch.
>>
>> Note that only the first error is reported; there might be more.  You
>> can find a snapshot of GCC 6 in experimental.  To build with GCC 6,
>> you can set CC=gcc-6 CXX=g++-6 explicitly.
>>
>>> sbuild (Debian sbuild) 0.67.0 (26 Dec 2015) on dl580gen9-02.hlinux
>> ...
>>> g++ -c -m64 -pipe -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
>>> -fstack-protector-strong -Wformat -Werror=format-security -Wall -w 
>>> -D_REENTRANT -DQT_XML_LIB -DQT_NETWORK_LIB 
>>> -DKONCLUDE_FORCE_ALL_DEBUG_DEACTIVATED -DQT_NO_DEBUG -DQT_GUI_LIB 
>>> -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++-64 -I. 
>>> -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork 
>>> -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtXml -I/usr/include/qt4 
>>> -I./generatedfiles -I./GeneratedFiles/Release -ISource -I. 
>>> -IGeneratedFiles/release -o release/CQueryError.o 
>>> Source/Reasoner/Query/CQueryError.cpp
>>> g++ -c -m64 -pipe -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
>>> -fstack-protector-strong -Wformat -Werror=format-security -Wall -w 
>>> -D_REENTRANT -DQT_XML_LIB -DQT_NETWORK_LIB 
>>> -DKONCLUDE_FORCE_ALL_DEBUG_DEACTIVATED -DQT_NO_DEBUG -DQT_GUI_LIB 
>>> -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++-64 -I. 
>>> -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork 
>>> -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtXml -I/usr/include/qt4 
>>> -I./generatedfiles -I./GeneratedFiles/Release -ISource -I. 
>>> -IGeneratedFiles/release -o release/CQueryInconsitentOntologyError.o 
>>> Source/Reasoner/Query/CQueryInconsitentOntologyError.cpp
>>> Source/Reasoner/Query/CQueryInconsitentOntologyError.cpp: In static member 
>>> function 'static Konclude::Reasoner::Query::CQueryInconsitentOntologyError* 
>>> Konclude::Reasoner::Query::CQueryInconsitentOntologyError::getInconsistentOntologyError(Konclude::Reasoner::Query::CQueryError*)':
>>> Source/Reasoner/Query/CQueryInconsitentOntologyError.cpp:57:12: error: 
>>> cannot convert 'bool' to 
>>> 'Konclude::Reasoner::Query::CQueryInconsitentOntologyError*' in return
>>>  return false;
>>> ^
>>>
>>> Makefile:10326: recipe for target 
>>> 'release/CQueryInconsitentOntologyError.o' failed
>
> Kind regards,
>
>  - Jonas
>

Bug#732069: mgltools-vision and cadd should appear in tasks page

[Steffen Möller]

Hello,

I propose to have mgltools-pmv, mgltools-vision on the tasks page and
also mgltools-cadd. The other parts of the mgltools are more of a
collection of helping libraries that the non-developing user seems
unlikely to be aware of.

Cheers,

Steffen

Bug#831437: RFP: chapel-minimal -- Minimal compiler for Chapel, a productive parallel programming language

[Ben Albrecht]

Package: wnpp
Severity: wishlist

* Package name: chapel-minimal
  Version : 1.13.1
  Upstream Author : Ben Albrecht 
* URL : chapel.cray.com
* License : Apache
  Programming Lang: Chapel
  Description : Minimal compiler for Chapel, a productive parallel 
programming language

Minimal compiler without third-party dependencies for Chapel, an emerging
programming language designed for productive parallel computing at scale.
Chapel's design and implementation have been undertaken with portability in
mind, permitting Chapel to run on multicore desktops and laptops, commodity
clusters, and the cloud, in addition to the high-end supercomputers for which
it was designed. Chapel's design and development are being led by Cray Inc. in
collaboration with academia, computing centers, and industry.

I am a developer on the Chapel team and we would like to make a minimal version
of our compiler available for Debian users.

Bug#831436: liquidwar: Please update build-depends on liballegro4-dev

[Jeremy Bicha]

Source: liquidwar
Version: 5.6.4-4

Please build-depend on liballegro4-dev instead of the virtual package
liballegro4.2-dev.

allegro4.2 was replaced a while ago by allegro4.4.

This change was made in Ubuntu:
https://launchpadlibrarian.net/144272350/liquidwar_5.6.4-3build1_5.6.4-3ubuntu1.diff.gz

Thanks,
Jeremy Bicha

Bug#822670: [debhelper-devel] Bug#822670: Bug#822670: dh-systemd should be merged into debhelper

[Tianon Gravi]

On 11 July 2016 at 17:31, Michael Biebl  wrote:
> What is the exact lintian warning you are talking about here,
> https://lintian.debian.org/tags/maintainer-script-calls-systemctl.html ?
>
> I think we just need to fix the output and also the wiki page along with
> it to recommend a versioned b-dep on debhelper instead of dh-systemd.

If I just remove "dh-systemd" from build-depends, I get
https://lintian.debian.org/tags/missing-build-dependency-for-dh-addon.html

E: my-pkg source: missing-build-dependency-for-dh-addon systemd => dh-systemd

So I suppose that particular check just needs to check for a
reasonable version of debhelper to satisfy "systemd" in particular? :)

> As for backports to jessie: If that is of concern to you, just keep
> using dh-systemd for now. It's not like we are dropping the dh-systemd
> package anytime soon. I wouldn't use alternative b-deps fwiw.
>
> Backporting this version of debhelper to jessie won't be trivial as this
> also means a backport of init-system-helpers. The latter is not easily done.

Yeah, that's totally fair, thanks. :)


♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#823014: [pkg-golang-devel] Bug#823014: Bug#823014: golang: Package compiled stdlib for PIE build mode

[Tianon Gravi]

On 14 July 2016 at 10:12, Peter Colberg  wrote:
> Tianon, can this be merged into golang-1.6 and golang-1.7?

Yeah, overall I'm +1 on the idea! (especially since Michael thinks it's sane)

I have a few questions about the patch:

- the "Build-Profiles" bits -- I know we should be using
build-profiles more intelligently throughout src:golang-X.Y, but is
there something specific to PIE itself that makes it more
necessary/appropriate than in the normal case?

- "golang-X.Y-go.install" currently has "pkg/*_*
/usr/lib/go-X.Y/pkg/", which will still match
"pkg/linux_amd64_shared", and thus include these files _both_ in
"golang-1.6-std-pie" and "golang-1.6-go" -- I guess we need to fix
that by using "dh_exec" and passing through our GOOS and GOARCH values
instead of using globs?



♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#830978: Browserified javascript and DFSG 2

[Neil Williams]

On Fri, 15 Jul 2016 23:45:01 +0530
Pirate Praveen  wrote:

> On 2016, ജൂലൈ 15 10:46:51 PM IST, Ian Jackson
>  wrote:
> >Sam Hartman writes ("Bug#830978: Browserified javascript and DFSG
> >2"):  
> >> Speaking as an individual TC member, here's my personal reading
> >> of  
> >the  
> >> TC discussion.
> >> 
> >> It's not clear that the TC is the right body for this discussion.
> >> We certainly could offer advice, but it's not clear that the
> >> ftpmasters  
> >or  
> >> release team--the parties most likely to need such advice-- would
> >> benefit from our advice.  
> >
> >I would like to comment briefly on the general idea about the TC
> >offering advice and making statements of opinion.
> >
> >
> >If someone in authority in the project, such as a maintainer of the
> >ftpmasters or the release team, is doing something which the TC
> >thinks is wrong, then (if the question is important) I think it
> >would be entirely appropriate for the TC to issue a statement of
> >opinion, disagreeing with the other authority.
> >
> >Conversely, if a contributor has been criticised, they may welcome a
> >message of support from the TC.  That may help lay to rest an
> >unfounded criticism and save the contributor the energy required to
> >wonder whether they're really right, rebut any public criticisms, and
> >so on.  
> 
> I agree.
> 
> >And finally if a question needs authoritative input but the relevant
> >authority in Debian has not made a clear decision, TC involvement
> >might help get the matter properly resolved.
> >
> >
> >In this case I think that it would be worth TC members considering,
> >for themselves, briefly, and without too much back-and-forth enquiry,
> >what their initial assessments of the merits of the situation are.
> >
> >If TC members feel that the submitter of #817092 (Luke, who is
> >complaining that the aggregated file is not source, along with Ben,
> >Jonas etc.) are right, they could ask the release team and the
> >ftpmasters (informally, perhaps) whether the release team would
> >welcome a supportive TC intervention.
> >
> >That would allow the TC to help settle this long-running question
> >(which keeps coming up on -devel and is frankly quite annoying).
> >
> >This is true even though it seems the specific case of
> >libjs-handlebars has a more clear-cut problem, as found by Ansgar and
> >described in #830986.
> >
> >
> >Concretely, as one of the people who agree with the submitter of
> >#817092, I would like to see the TC pass a resolution along these
> >lines:
> >
> > The TC gives a non-binding statement of opinion:
> >
> > * The point of having the source code (with an appropriate licence
> >   etc.) is so that all our contributors, downstreams, and users are
> >   able to modify the code and to share their modifications with each
> >   other, with Debian, and with upstream.  
> 
> I agree this is an important consideration, but not serious enough to
> reject a package.

So you consider that upstream are not fully-qualified users somehow and
therefore do not get the benefits of the DFSG? If the freedoms of users
who choose to interact with upstream are reduced by choices made within
the package then the package is breaking the DFSG by penalising a
field of endeavour.

> If this argument is accepted, we will not be able to package a fork
> because the original upstream won't accept a patch against the fork.
> Similarly we'd be able to package only HEAD of the vcs as they
> usually accept patched only against HEAD. Porting patches is an
> essential part of packaging. By choosing to maintain this source, I
> accept this challenge. If I cannot keep the package rc bug free
> otherwise, it will be removed any way.
> 
> > * In particular, Debian will often want to share modifications with
> >   upstream, which means that we need to be working with the software
> >   in a form which lets us do so.  
> 
> This is ideal thing, but should not be a requirement to qualify as
> dfsg-free.
> 
> > * For Debian, therefore, the source code for a file or program is
> > the form which can be conveniently modified and shared;
> > specifically, the form in which upstream will accept patches.  
> 
> This was never the intention of dfsg, it was always about freedoms of
> the user receiving the source code.
>
> Our only consideration for dfsg qualification would be to see if a
> user can exercise freedoms in a generally accepted way. In this case,
> would some comfortable with javascript modify the code? If they are
> able to modify the split files, they will be able to modify the
> browserified files as well without any extra complexity.
> 
> As for patches from upstream, the effort is similar to backporting.
> Same for sending patches upstream, effort is similar to rebasing.

Where do you get this crazy and fanciful notion that upstream are
somehow second-class community members? Upstream are users of the
software and all users must be free to 

Bug#831435: www.debian.org: Link to the patch tracker broken

[Orestis Ioannou]

Package: www.debian.org
Severity: normal
User: www.debian@packages.debian.org
Usertag: packages

Heya

The URL for the patch tracker changed slightly hence the links towards
sources.debian.net/patches are broken.
I.e when you are at https://packages.debian.org/stretch/python-pip
the link to the Debian Patch Tracker is
http://sources.debian.net/patches/summary/python-pip/8.1.2-2/
but the correct one is http://sources.debian.net/patches/python-pip/8.1.2-2/

I should probably be able to propose a patch for that but i ve been
thinking to
do this for a week so somebody might beat me at it :)

Cheers,

Orestis



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

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

Bug#831225: Errata

[Alberto Gallardo]

My apollogies: I have just realized that I have copy-pasted the wrong log
for the start daemon. Unfortunately, I don't have access to the environment
from where I have reported the bug, neither have the time now to replicate
it in my laptop. The

root@3186238ed456:/# /etc/init.d/tomcat8 start

obviously didn't reported an error stopping Tomcat, but a failure starting
it.



Alberto

Bug#827835: What's the status of this RC bug?

[Francesco Poli]

Hello,
I must confess that I am beginning to be mildly worried about
bug #827835: this serious bug report was filed back on June,
the 21st and appears to be still unaddressed without any
visible activity.

Package ruby-xmlparser risks to be autoremoved (along with its
reverse dependencies, among which apt-listbugs, which I maintain),
because of this bug.

Could you please clarify what is the status of this RC bug?
Is it going to be fixed soon?

Please let me know.
Thanks for your time and dedication!


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


pgp0Q_hm7nURj.pgp
Description: PGP signature

Bug#831106: build with other mpich lib

[Thorsten Alteholz]

Hi Lucas,

according to the logfile the problem is:
 configure:4194: checking for mpi.h
 configure:4207: mpic++ -c -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/hdf5/mpich 
conftest.cpp >&5
 In file included from /usr/include/mpich/mpi.h:2231:0,
  from conftest.cpp:11:
 /usr/include/mpich/mpicxx.h:21:4: error: #error 'Please use the same version 
of GCC and g++ for compiling MPICH and user MPI programs'

So can you please redo the test with the version of mpich that is compiled 
with gcc6?


  Thorsten

Bug#831434: bzip2 not working with symbolic links: bzip2: Input file b.bz2 is not a normal file.

[drcnjio908]

Package: bzip2
Version: 1.0.6-8
Severity: normal

Dear Maintainer,

Steps to reproduce:
  echo test > a
  bzip2 --compress --keep a
  ln -s a.bz2 b.bz2
  bzip2 -d b.bz2
bzip2: Input file b.bz2 is not a normal file.

What I think it should do:
  Extract the file the symbolic link points to.

Related Bug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=41217

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

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

Versions of packages bzip2 depends on:
ii  libbz2-1.0  1.0.6-8
ii  libc6   2.22-10

bzip2 recommends no packages.

Versions of packages bzip2 suggests:
pn  bzip2-doc  

-- debconf-show failed

Bug#830978: Browserified javascript and DFSG 2

[Philip Hands]

Pirate Praveen  writes:

...
>> * For Debian, therefore, the source code for a file or program is the
>>   form which can be conveniently modified and shared; specifically,
>>   the form in which upstream will accept patches.
>
> This was never the intention of dfsg, it was always about freedoms of the 
> user receiving the source code.
>
> Our only consideration for dfsg qualification would be to see if a
> user can exercise freedoms in a generally accepted way. In this case,
> would some comfortable with javascript modify the code? If they are
> able to modify the split files, they will be able to modify the
> browserified files as well without any extra complexity.

Am I right in thinking that this change in the upstream source:

  
https://github.com/wycats/handlebars.js/commit/08781798f564a68abee11c74e2b98272657b2a56#diff-a13581e6dfc1c61c90703da188230cbcR123

becomes this change in the ruby gem that subsequently goes into the package:

  
https://github.com/leshill/handlebars_assets/commit/53443fa7f92c011714bd6aa5831be6074131cfca#diff-49dc26dc0a147a52074ac39c72bd99b1R2119

and if so, are you really trying to claim that these are
indistinguishable as far as anyone working on the code
might be concerned?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#825833: libkms

[ydirson]

Well, the fact that it's enabled by default upstream, and that at least
one very recent piece of software requires it could weight a bit :)

- Mail original -
> De: "Julien Cristau" 
> À: ydir...@free.fr, 825...@bugs.debian.org
> Cc: 825833-submit...@bugs.debian.org
> Envoyé: Vendredi 15 Juillet 2016 22:33:41
> Objet: Re: Bug#825833: libkms
> 
> On Wed, Jul  6, 2016 at 18:46:32 +0200, ydir...@free.fr wrote:
> 
> > In fact, it looks like libkms was built in the past, but is
> > explicitely
> > disabled now.  There is probably a reason for this, but there is no
> > more
> > information than that in the changelog, and no README.Debian.
> > 
> > Could we please have more insight about why this decision was made
> > ?
> > 
> libkms wasn't used/useful then, I'd need some convincing to re-enable
> it.
> 
> Cheers,
> Julien
> 

Bug#539788: isutf8: return TRUE for ISO-2022-JP (7bit escaped JIS code)

[Julien Palard]

Hi,

Every 7 bits encodings will always be valid UTF8 as the range U+..U+007F is 
explicitly (documented as) valid in UTF8.


So, there will always be the possibility to find legitimate UTF-8 encoded 
documents matching sequences found in ISO-2022-JP, like:
'\x1B\x28\x42' which is "control, left parenthesis, LATIN CAPITAL LETTER B".

If you want to start speaking about probabilities that a given document is UTF8 
or ISO-2022-JP according to a frequency analysis of common patterns, you're not 
talking about `isutf8` but `chardet`.

The role of isutf8 is *only* to tell if a given bit sequence is valid in utf8,
it means that false positives are acceptable (ASCII is UTF-8 compatible, so if 
a document is encoded in ASCII, isutf8 will falsely tell it's valid, which is 
acceptable) but
false negatives are not acceptable: every encoding error have to be reported.

Bests,
--
Julien Palard
https://mdk.fr

Bug#831433: gnome-shell: Week start day miscalucated

[Neil McGovern]

Package: gnome-shell
Version: 3.20.3-1
Severity: normal

Hi,

It seems that there's an error in the mini calendar when the day starts
on a Monday, rather than a Sunday - there's an offset with the day of
the week.

See attached.

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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  evolution-data-server3.20.3-1
ii  gir1.2-accountsservice-1.0   0.6.40-3
ii  gir1.2-atspi-2.0 2.20.2-1
ii  gir1.2-caribou-1.0   0.4.20-2
ii  gir1.2-clutter-1.0   1.26.0-2
ii  gir1.2-freedesktop   1.48.0-2
ii  gir1.2-gcr-3 3.20.0-2
ii  gir1.2-gdesktopenums-3.0 3.20.0-3
ii  gir1.2-gdm-1.0   3.20.1-1
ii  gir1.2-glib-2.0  1.48.0-2
ii  gir1.2-gnomebluetooth-1.03.20.0-1
ii  gir1.2-gnomedesktop-3.0  3.20.2-1
ii  gir1.2-gtk-3.0   3.20.6-2
ii  gir1.2-gweather-3.0  3.20.1-1
ii  gir1.2-ibus-1.0  1.5.11-1
ii  gir1.2-mutter-3.03.20.3-2
ii  gir1.2-networkmanager-1.01.2.2-2
ii  gir1.2-nmgtk-1.0 1.2.2-2
ii  gir1.2-pango-1.0 1.40.1-1
ii  gir1.2-polkit-1.00.105-15
ii  gir1.2-soup-2.4  2.54.1-1
ii  gir1.2-telepathyglib-0.120.24.1-1.1
ii  gir1.2-telepathylogger-0.2   0.8.2-1
ii  gir1.2-upowerglib-1.00.99.4-3
ii  gjs  1.45.3-2
ii  gnome-backgrounds3.20-1
ii  gnome-settings-daemon3.20.1-2
ii  gnome-shell-common   3.20.3-1
ii  gsettings-desktop-schemas3.20.0-3
ii  libatk-bridge2.0-0   2.20.1-2
ii  libatk1.0-0  2.20.0-1
ii  libc62.23-1
ii  libcairo21.14.6-1+b1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libclutter-1.0-0 1.26.0-2
ii  libcogl-pango20  1.22.0-2
ii  libcogl201.22.0-2
ii  libcroco30.6.11-1
ii  libdbus-glib-1-2 0.106-1
ii  libecal-1.2-19   3.20.3-1
ii  libedataserver-1.2-213.20.3-1
ii  libgcr-base-3-1  3.20.0-2
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libgirepository-1.0-11.48.0-2
ii  libgjs0e [libgjs0-libmozjs-24-0] 1.45.3-2
ii  libglib2.0-0 2.48.1-1
ii  libgstreamer1.0-01.8.2-1
ii  libgtk-3-0   3.20.6-2
ii  libical2 2.0.0-0.4
ii  libicu55 55.1-7
ii  libjson-glib-1.0-0   1.2.0-1
ii  libmozjs-24-024.2.0-3.1
ii  libmutter0h  3.20.3-2
ii  libnm-glib4  1.2.2-2
ii  libnm-util2  1.2.2-2
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libpolkit-agent-1-0  0.105-15
ii  libpolkit-gobject-1-00.105-15
ii  libpulse-mainloop-glib0  9.0-1.1
ii  libpulse09.0-1.1
ii  libsecret-1-00.18.3-1
ii  libstartup-notification0 0.12-4
ii  libsystemd0  230-7
ii  libtelepathy-glib0   0.24.1-1.1
ii  libx11-6 2:1.6.3-1
ii  libxfixes3   1:5.0.2-1
ii  mutter   3.20.3-2
ii  python3  3.5.1-4
ii  telepathy-mission-control-5  1:5.16.3-2

Versions of packages gnome-shell recommends:
ii  gdm33.20.1-1
ii  gkbd-capplet3.6.0-1
ii  gnome-contacts  3.20.0-1
ii  gnome-control-center1:3.20.1-2
ii  

Bug#831432: mknbi: please make the build reproducible

[Chris Lamb]

Source: mknbi
Version: 1.4.4-11
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed
that mknbi could not be built reproducibly.

Patch attached.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/06-reproducible-builds.patch   1970-01-01 
02:00:00.0 +0200
--- b/debian/patches/06-reproducible-builds.patch   2016-07-15 
23:06:54.580070469 +0200
@@ -0,0 +1,30 @@
+Author: Chris Lamb 
+Last-Update: 2016-07-15
+
+--- mknbi-1.4.4.orig/Makefile
 mknbi-1.4.4/Makefile
+@@ -61,6 +61,11 @@ MANS=   mknbi.1 disnbi.1 menuc.1
+ HTMLS=mknbi.html disnbi.html menuc.html
+ DOCS= $(MANS) $(HTMLS)
+ 
++ifdef SOURCE_DATE_EPOCH
++BUILD_DATE=   $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "+%Y-%m-%d" 
2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "+%Y-%m-%d" 2>/dev/null || 
date -u "+%Y-%m-%d")
++else
++BUILD_DATE=   $(shell date "+%Y-%m-%d")
++endif
+ 
+ all:  $(PROG) $(FIRSTS) $(RMRD) $(DOCS)
+ 
+@@ -210,9 +215,9 @@ $(ALTBOOT):altboot.S
+   $(RM) altboot.s
+ 
+ $(MANS):  mknbi.pl disnbi.pl Makefile
+-  pod2man --date=`date +%Y-%m-%d` --release="Mknbi 
$(VERSION)$(EXTRAVERSION)" --center="Etherboot tools" mknbi.pl > mknbi.1
+-  pod2man --date=`date +%Y-%m-%d` --release="Mknbi 
$(VERSION)$(EXTRAVERSION)" --center="Etherboot tools" disnbi.pl > disnbi.1
+-  pod2man --date=`date +%Y-%m-%d` --release="Mknbi 
$(VERSION)$(EXTRAVERSION)" --center="Etherboot tools" menuc.pl > menuc.1
++  pod2man --date=$(BUILD_DATE) --release="Mknbi 
$(VERSION)$(EXTRAVERSION)" --center="Etherboot tools" mknbi.pl > mknbi.1
++  pod2man --date=$(BUILD_DATE) --release="Mknbi 
$(VERSION)$(EXTRAVERSION)" --center="Etherboot tools" disnbi.pl > disnbi.1
++  pod2man --date=$(BUILD_DATE) --release="Mknbi 
$(VERSION)$(EXTRAVERSION)" --center="Etherboot tools" menuc.pl > menuc.1
+ 
+ $(HTMLS): mknbi.pl disnbi.pl
+   pod2html mknbi.pl > mknbi.html
--- a/debian/patches/series 2016-07-15 23:00:52.105074043 +0200
--- b/debian/patches/series 2016-07-15 23:06:45.327993142 +0200
@@ -3,3 +3,4 @@
 03-gcc-multilib-harder.patch
 04-no-stack-protector.patch
 05-gcc-5,patch
+06-reproducible-builds.patch

Bug#776171: same problem

[Thomas Vaughan]

On Sun, 10 Jul 2016 15:36:57 +0200 Michael Biebl  wrote:
> Control: tags -1 + moreinfo
>
> Hi
>
> Am 25.02.2016 um 10:26 schrieb Vincent Bernat:
> >
> > Same problem here. Any poweroff, reboot, suspend targets answer with the
> > same message. Absolutely no clue how to debug this...
>
> Which systemd version do you use? Is this problem reproducible (on a
> current sid system)?

​I am seeing this "transaction is destructive" message still whenever,
after starting up my laptop docked, I try to do a shutdown.

When docked with lid closed, the machine is incapable of shutting down
normally.  If I log in as root and type 'poweroff', that's when I see
"transaction is destructive".

I run Debian sid, updated daily.

I think that this problem has existed for me ever since the forced
transition to systemd months and months ago.

This problem has tempted me to look at Devuan, but I have so far been too
lazy.

My work-around is to leave my laptop lid open when it is docked. However, I
don't like this because
(a) my keyboard grows needlessly ever dirtier with dust over the months, and
(b) the backlight is on and generates extra heat that I'd rather not inject
into my already-too-hot office.​

​Please help.​

​(I am using the stock '/etc/systemd/logind.conf'.​ I have tried mucking
with the various lid-switch settings, but nothing seems to work.)

​My machine is a Latitude E6530 with both Nvidia and Intel via Optimus.
When docked, I am using the proprietary Nvidia drivers via dkms.

Both Intel and Nvidia drivers are installed, and I manually switch between
them via the update-glx command when I transition between docked and
undocked configuration.

--
​Thomas E. Vaughan
tevaug...@gmail.com​

Bug#831430: nmh: please make the build reproducible

[Chris Lamb]

Source: nmh
Version: 1.6-11
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed
that nmh could not be built reproducibly.

Patch attached.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/11-repro   2016-07-15 22:35:09.137520083 +0200
--- b/debian/patches/11-repro   2016-07-15 22:40:32.859756578 +0200
@@ -7,3 +7,14 @@
 -echo "char *version_str = \"nmh-$VERSION [compiled on $HOSTNAME at `date`]\";"
 +echo "char *version_str = \"nmh-$VERSION\";"
  echo "char *version_num = \"nmh-$VERSION\";"
+--- nmh-1.6.orig/man/mh-chart-gen.sh
 nmh-1.6/man/mh-chart-gen.sh
+@@ -9,7 +9,7 @@ nmhmandir=`dirname $0`
+ # from the local build environment when building distribution packages.
+ LC_TIME=C; export LC_TIME
+ unset LANG
+-datestamp=`date '+%B %d, %Y'`
++datestamp="$(date --utc --date="@${SOURCE_DATE_EPOCH:-$(date +%s)}" '+%B %d, 
%Y')"
+ 
+ cat <<__HOOPY_FROOD
+ .TH MH-CHART %manext7% "${datestamp}" "%nmhversion%"

Bug#798476: debian-policy: don't require Uploaders

[Christian Hofstaedtler]

* Tobias Frost  [160715 21:03]:
> > These packages are clearly not not-maintained (teams care about
> > them), so orphaning or assinging to Debian QA Group would make no
> > sense whatsoever.
[..]

> From my short time as MIA member I can tell it is already hard enough
> to find persons being MIA; to track complete teams will be lot harder.
> (e.g the question who is actually a team member is sometimes hard to
> answer from outside)

I can't disagree; however as said before, the info in Uploaders: is
- for the larger teams - meaningless.

> IMHO if the team commits to maintain that package it shouldn't be too much 
> strain to add an explict carer too, is it? 

But who would that be?

> For that people need to know that that particular package is up for
> adoption. That information would be harder to retrieve.

I do not think "adoption" is the right word here; in Debian context
it somehow implies that the package is orphaned and sees no
maintenance.

> However wnpp could be used as a tool here: Why not advertise 
> using a RFA and telling there that the team has open positions?

*shrug*. In pkg-ruby-extras, that wnpp bug would be very generic:
"please join and work on all packages that you can find" ...

Best,
-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#824693: ocaml: Enable native compilers in ppc64el starting at version 4.03

[Ralf Treinen]

On Wed, May 18, 2016 at 03:00:53PM -0400, Breno Leitao wrote:

> Currently, the package ocaml-native-compilers is not being built for ppc64el
> because the patch to enable it still not available in version 4.02.3.
> 
> Starting at version 4.03, the patch to enable native compiler on ppc64el is
> integrated into the source code (SVN revision 16374) and [1], thus, I would
> like to have package omcal-native-compilers targeting ppc64el.
> 
> OcamL native compiler is required to be enable in order to enable hhvm 
> package,
> which build-depends on ocaml-native-compilers.

why does hhvm build-depend on ocaml-native-compiler? Packages should 
(build-)depend on ocaml-best-compilers, which is provided by -native-compilers
on architectures where it exists, and by -nox on others.

-Ralf.

Bug#830151: xorgs: Do not have a human maintainer/uploader listed

[Julien Cristau]

Control: severity -1 normal

On Wed, Jul  6, 2016 at 19:02:53 +0200, Tobias Frost wrote:

> Package: xorg
> Version: 1:7.7+15
> Severity: serious
> Justification: Policy 3.3 / 5.6.3
> 
https://release.debian.org/stretch/rc_policy.txt doesn't list this as
release critical.  If you want to be listed in xorg's Uploaders, feel
free.

Cheers,
Julien

Bug#831429: xorp: please make the build reproducible

[Chris Lamb]

Source: xorp
Version: 1.8.5-4.1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed
that xorp could not be built reproducibly.

Patch attached.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/libxorp/create_buildinfo.sh   2016-07-15 17:56:24.575091115 +0200
--- b/libxorp/create_buildinfo.sh   2016-07-15 21:57:56.723874929 +0200
@@ -45,7 +45,10 @@
 fi
 
 cat build_info.prefix > $BINFO
-if uname -mrspn > /dev/null 2>&1
+if [ -n "$SOURCE_DATE_EPOCH" ]
+then
+echo "const char* BuildInfo::getBuildMachine() { return \"Reproducible 
build @ $SOURCE_DATE_EPOCH\"; }" >> $BINFO
+elif uname -mrspn > /dev/null 2>&1
 then
 echo "const char* BuildInfo::getBuildMachine() { return \"`uname 
-mrspn`\"; }" >> $BINFO
 else
@@ -59,7 +62,7 @@
 
 if date > /dev/null 2>&1
 then
-echo "const char* BuildInfo::getBuildDate() { return \"`date`\"; }" >> 
$BINFO
+echo "const char* BuildInfo::getBuildDate() { return \"$(date --utc 
--date=@${SOURCE_DATE_EPOCH:-$(date +%s)})\"; }" >> $BINFO
 else
 echo "Warning:  'date' does not function on this system."
 echo "const char* BuildInfo::getBuildDate() { return \"Unknown\"; }" >> 
$BINFO
@@ -68,7 +71,7 @@
 
 if date '+%F %H:%M' > /dev/null 2>&1
 then
-echo "const char* BuildInfo::getShortBuildDate() { return \"`date '+%F 
%H:%M'`\"; }" >> $BINFO
+echo "const char* BuildInfo::getShortBuildDate() { return \"$(date --utc 
--date=@${SOURCE_DATE_EPOCH:-$(date +%s)}) '+%F %H:%M'\"; }" >> $BINFO
 else
 echo "Warning:  date +%F %H:%M does not function on this system."
 echo "const char* BuildInfo::getShortBuildDate() { return \"Unknown\"; }" 
>> $BINFO

Bug#825833: libkms

[Julien Cristau]

On Wed, Jul  6, 2016 at 18:46:32 +0200, ydir...@free.fr wrote:

> In fact, it looks like libkms was built in the past, but is explicitely
> disabled now.  There is probably a reason for this, but there is no more
> information than that in the changelog, and no README.Debian.
> 
> Could we please have more insight about why this decision was made ?
> 
libkms wasn't used/useful then, I'd need some convincing to re-enable
it.

Cheers,
Julien

Bug#831428: ITP: python-tackerclient -- CLI and Client Library for OpenStack Tacker

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-tackerclient
  Version : 0.4.0
  Upstream Author : OpenStack Foundation 
* URL : https://github.com/openstack/python-tackerclient
* License : Apache-2.0
  Programming Lang: Python
  Description : CLI and Client Library for OpenStack Tacker

 Tacker is an official OpenStack project building a Generic VNF Manager (VNFM)
 and a NFV Orchestrator (NFVO) to deploy and operate Network Services and
 Virtual Network Functions (VNFs) on an NFV infrastructure platform like
 OpenStack. It is based on ETSI MANO Architectural Framework and provides a
 functional stack to Orchestrate Network Services end-to-end using VNFs.
 .
 This is the client API library for Tacker.

Bug#831427: ITP: ipv6pref -- preloadable library and wrapper script to influence address selection for IPv6 programs

[Stefan Tomanek]

Package: wnpp
Severity: wishlist
Owner: Stefan Tomanek 

* Package name: ipv6pref
  Version : 1.0.0
  Upstream Author : Stefan Tomanek 
* URL : https://github.com/wertarbyte/ipv6pref
* License : GPLv3
  Programming Lang: C
  Description : preloadable library and wrapper script to influence address 
selection for IPv6 programs

Many systems that support IPv6 connectivity employ Privacy Extensions during
address configuration. This loads to periodic reconfiguration of the IPv6
address used for establishing connections. In some cases it is desirable to use
the permanent address instead, e.g. for long-running connections (SSH sessions
come to mind). 'ipv6pref.so' is a small library that wraps around the socket()
function and - once hooked into the program via LD_PRELOAD - takes the value of
an environment variable (IPV6PREF_ADDR) into account: if set to 'pub', it
advices the kernel to use the permanent, non-random address for the newly
created socket, if set to 'tmp', it defaults to the privacy-enhanced addresses.
A small wrapper script 'ipv6pref' (symlinked to 'v6pub' and 'v6tmp') is
supplied to simplify the address selection for single commands.

Bug#831426: jessie-pu: package ccache/3.1.12-1

[Joel Rosdahl]

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

As suggested by Stefan Fritsch in #829088 ("ccache may silently
miscompile symlinked source files"), I propose to upgrade ccache from
3.1.10 to 3.1.12 in jessie. I'm the upstream maintainer of ccache as
well and I made the 3.1.12 release specifically for Debian stable to fix
#829088. Upgrading from 3.1.10 to 3.1.12 would also include three other
bug fixes that I think would be good to have in jessie.

Here's a summary of the bug fixes:

>From 3.1.12:

- Fixes a bug where (due to ccache rewriting paths) the compiler could
  choose incorrect include files if CCACHE_BASEDIR is used and the
  source file path is absolute and is a symlink. (Closes: #829088.)

>From 3.1.11:

- Fixes a bug which could result in false cache hits when source code
  contains '"' followed by " /*" or " //" (with variations).
- Makes hash of cached result created with and without CCACHE_CPP2
  different. This makes it possible to rebuild with CCACHE_CPP2 set
  without having to clear the cache to get new results.
- Fixes a bug which could result in "No such file or directory" messages
  in the ccache log when the cache directory doesn't exist.

See attachment for the proposed update diff.

-- Joel
diff -Nru ccache-3.1.10/AUTHORS.html ccache-3.1.12/AUTHORS.html
--- ccache-3.1.10/AUTHORS.html  2014-10-19 19:12:05.0 +0200
+++ ccache-3.1.12/AUTHORS.html  2016-07-12 21:34:50.0 +0200
@@ -734,7 +734,7 @@
 
 
 ccache authors
-version 3.1.10
+version 3.1.12
 
   Table of Contents
   JavaScript must be enabled in your browser to display the 
table of contents.
@@ -915,8 +915,9 @@
 
 
 
-Version 3.1.10
-Last updated 2014-10-19 19:05:10 CEST
+Version 3.1.12
+Last updated
+ 2016-07-12 21:34:27 CEST
 
 
 
diff -Nru ccache-3.1.10/INSTALL.html ccache-3.1.12/INSTALL.html
--- ccache-3.1.10/INSTALL.html  2014-10-19 19:12:05.0 +0200
+++ ccache-3.1.12/INSTALL.html  2016-07-12 21:34:50.0 +0200
@@ -734,7 +734,7 @@
 
 
 ccache installation
-version 3.1.10
+version 3.1.12
 
   Table of Contents
   JavaScript must be enabled in your browser to display the 
table of contents.
@@ -843,8 +843,9 @@
 
 
 
-Version 3.1.10
-Last updated 2014-10-19 19:02:09 CEST
+Version 3.1.12
+Last updated
+ 2016-07-12 21:34:27 CEST
 
 
 
diff -Nru ccache-3.1.10/LICENSE.html ccache-3.1.12/LICENSE.html
--- ccache-3.1.10/LICENSE.html  2014-10-19 19:12:05.0 +0200
+++ ccache-3.1.12/LICENSE.html  2016-07-12 21:34:50.0 +0200
@@ -734,7 +734,7 @@
 
 
 ccache copyright and license
-version 3.1.10
+version 3.1.12
 
   Table of Contents
   JavaScript must be enabled in your browser to display the 
table of contents.
@@ -776,7 +776,7 @@
 
 
   Copyright (C) 2002-2007 Andrew Tridgell
-  Copyright (C) 2009-2011 Joel Rosdahl
+  Copyright (C) 2009-2016 Joel Rosdahl
 
 
 
@@ -1210,8 +1210,9 @@
 
 
 
-Version 3.1.10
-Last updated 2014-10-19 19:02:09 CEST
+Version 3.1.12
+Last updated
+ 2016-07-12 21:34:27 CEST
 
 
 
diff -Nru ccache-3.1.10/LICENSE.txt ccache-3.1.12/LICENSE.txt
--- ccache-3.1.10/LICENSE.txt   2014-10-19 19:12:05.0 +0200
+++ ccache-3.1.12/LICENSE.txt   2016-07-12 21:34:50.0 +0200
@@ -38,7 +38,7 @@
 
 ---
   Copyright (C) 2002-2007 Andrew Tridgell
-  Copyright (C) 2009-2011 Joel Rosdahl
+  Copyright (C) 2009-2016 Joel Rosdahl
 ---
 
 
diff -Nru ccache-3.1.10/MANUAL.html ccache-3.1.12/MANUAL.html
--- ccache-3.1.10/MANUAL.html   2014-10-19 19:12:05.0 +0200
+++ ccache-3.1.12/MANUAL.html   2016-07-12 21:34:50.0 +0200
@@ -734,7 +734,7 @@
 
 
 CCACHE(1)
-version 3.1.10
+version 3.1.12
 
   Table of Contents
   JavaScript must be enabled in your browser to display the 
table of contents.
@@ -2014,8 +2014,9 @@
 
 
 
-Version 3.1.10
-Last updated 2014-10-19 19:02:09 CEST
+Version 3.1.12
+Last updated
+ 2016-07-12 21:34:27 CEST
 
 
 
diff -Nru ccache-3.1.10/NEWS.html ccache-3.1.12/NEWS.html
--- ccache-3.1.10/NEWS.html 2014-10-19 19:12:05.0 +0200
+++ ccache-3.1.12/NEWS.html 2016-07-12 21:34:50.0 +0200
@@ -734,7 +734,7 @@
 
 
 ccache news
-version 3.1.10
+version 3.1.12
 
   Table of Contents
   JavaScript must be enabled in your browser to display the 
table of contents.
@@ -742,6 +742,55 @@
 
 
 
+ccache 3.1.12
+
+Release date: 2016-07-12
+
+Bug fixes
+
+
+
+Fixed a bug where (due to ccache rewriting paths) the compiler could choose
+  incorrect include files if CCACHE_BASEDIR is used and the 
source file path
+  is absolute and is a symlink.
+
+
+
+
+
+
+
+ccache 3.1.11
+
+Release date: 2015-03-07
+
+Bug fixes
+
+
+
+Fixed bug which could result in false cache hits when source code contains
+  '"' followed by " /*" or " //" (with 
variations).
+
+
+
+
+Made hash of cached result created with and without CCACHE_CPP2 
different.
+ 

Bug#831425: fontforge-nox: Creates invalid .otf on i386 and hppa, causing FTBFS 3270font

[Christoph Biedl]

Package: fontforge-nox
Version: 20120731.b-7.2
Severity: important

Dear Maintainer,

some research why the 3270font (arch: all) package fails to (re-)build
here led to a surprising result: On some architectures, fontforge
creates invalid font files at least for .otf, breaking the build.

Details: The build process calls fontforge to create the font in
several file formats, then fontlint to check for errors. This works
flawless on amd64, armel, armhf, powerpc but fails when checking the
on ...

* i386:

| Copyright (c) 2000-2012 by George Williams.
|  Executable based on sources from 14:57 GMT 31-Jul-2012-ML.
|  Library based on sources from 14:57 GMT 31-Jul-2012.
| A point in NameMe.955 is outside the font bounding box data.
| Validation 3270Medium ...Failed
|   Bad 'CFF ' table
| make[1]: *** [test] Error 1

* hppa:

| Copyright (c) 2000-2012 by George Williams.
|  Executable based on sources from 14:57 GMT 31-Jul-2012-ML.
|  Library based on sources from 14:57 GMT 31-Jul-2012.
| Validation 3270Medium ...Failed
|   Bad BlueScale entry in PostScript Private dictionary

Comparison shows the created font is identical for all succeeding
architectures (faketime is needed when creating the fonts) but are
different to the ones created in the failing archs. A diff of the
dumps created by otfdump is attached.

How to repeat: Download src:3270font, run "make all test".

Wild guess: The failing archs are 32bit *and* have signed characters.

Christoph

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

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

Versions of packages fontforge-nox depends on:
ii  fontforge-common 20120731.b-7.2
ii  libc62.22-13
ii  libcairo21.14.6-1+b1
ii  libfontconfig1   2.11.0-6.4
ii  libfontforge120120731.b-7.2
ii  libfreetype6 2.6.3-3+b1
ii  libgif7  5.1.4-0.3
ii  libglib2.0-0 2.48.1-1
ii  libjpeg62-turbo  1:1.5.0-1
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libpangoft2-1.0-01.40.1-1
ii  libpangoxft-1.0-01.40.1-1
ii  libpng16-16  1.6.23-1
ii  libpython2.7 2.7.12-1
ii  libspiro01:0.5.20150702-4
ii  libtiff5 4.0.6-1
ii  libuninameslist0 0.5.20150701-1
ii  libxft2  2.3.2-1
ii  libxml2  2.9.3+dfsg1-1.2
ii  zlib1g   1:1.2.8.dfsg-2+b1

fontforge-nox recommends no packages.

fontforge-nox suggests no packages.

-- no debconf information

--- 3270Medium.otf.dump.amd64
+++ 3270Medium.otf.dump.i386
@@ -6,13 +6,13 @@
 (enterSelector 3)
 (rangeShift 48))
   (Table 0 (tag "CFF " #x43464620)
-(checkSum 4214D902) (offset #x22D0) (length: #xE0A9))
+(checkSum 17BDA930) (offset #x22D0) (length: #xE0C2))
   (Table 1 (tag "FFTM" #x4646544D)
-(checkSum 69D7A25C) (offset #x0001039C) (length: #x001C))
+(checkSum 69D7A25C) (offset #x000103B4) (length: #x001C))
   (Table 2 (tag "GDEF" #x47444546)
-(checkSum 000F001E) (offset #x0001037C) (length: #x001E))
+(checkSum 000F001E) (offset #x00010394) (length: #x001E))
   (Table 3 (tag "OS/2" #x4F532F32)
-(checkSum 55DD15A8) (offset #x0120) (length: #x0060))
+(checkSum 55DA15A8) (offset #x0120) (length: #x0060))
   (Table 4 (tag "cmap" #x636D6170)
 (checkSum 71A79D15) (offset #x1864) (length: #x0A4A))
   (Table 5 (tag "head" #x68656164)
@@ -20,7 +20,7 @@
   (Table 6 (tag "hhea" #x68686561)
 (checkSum 06D70010) (offset #x00F4) (length: #x0024))
   (Table 7 (tag "hmtx" #x686D7478)
-(checkSum 7302689A) (offset #x000103B8) (length: #x07C2))
+(checkSum 7302689A) (offset #x000103D0) (length: #x07C2))
   (Table 8 (tag "maxp" #x6D617870)
 (checkSum 03DF5000) (offset #x0118) (length: #x0006))
   (Table 9 (tag "name" #x6E616D65)
@@ -30,7 +30,7 @@
   (head
 (TableVersionNumber 1.0)
 (fontRevision 1.0)
-(checkSumAdjustment #x5300EEBA)
+(checkSumAdjustment #xA7B54DFD)
 (magicNumber #x5F0F3CF5)
 (flags #x000B)
 (unitsPerEm 1000))


signature.asc
Description: Digital signature

Bug#831423: e2fsprogs: tune2fs -l modifies file system

[Bob Proulx]

Package: e2fsprogs
Version: 1.43.1-1
Severity: normal

The 'tune2fs -l' command modifies the file system.  The man page says:

 -l  List the contents of the filesystem superblock, including the
 current values of the parameters that can be set via this program.

To recreate the problem:

  # stat --format=%y /
  2016-07-15 07:23:18.767919229 -0600

  # tune2fs -l /dev/mapper/v1-root > /dev/null

  # stat --format=%y /
  2016-07-15 13:56:20.703068156 -0600

Interestingly:

  # chattr +i /

  # lsattr -d /
  i-- /

  # stat --format=%y /
  2016-07-15 13:56:20.703068156 -0600

  # tune2fs -l /dev/mapper/v1-root > /dev/null

  # stat --format=%y /
  2016-07-15 13:56:20.703068156 -0600

But no errors were produced.  So even though it is modifying the file
system it isn't checking error codes.

Thank you for maintaining these utilities in Debian.

Bob

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages e2fsprogs depends on:
ii  e2fslibs1.43.1-1
ii  libblkid1   2.28-5
ii  libc6   2.23-1
ii  libcomerr2  1.43.1-1
ii  libss2  1.43.1-1
ii  libuuid12.28-5
ii  util-linux  2.28-5

e2fsprogs recommends no packages.

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
ii  gpart  1:0.3-3
ii  parted 3.2-15

-- no debconf information

Bug#831424: RFP: parsoid -- Web service converting HTML+RDFa to MediaWiki wikitext and back

[Pierre Rudloff]

Package: wnpp
Severity: wishlist

* Package name: parsoid
  Version : 0.5.1
  Upstream Author : Gabriel Wicke 
* URL : https://www.mediawiki.org/wiki/Parsoid
* License : GPL
  Programming Lang: JavaScript
  Description : Web service converting HTML+RDFa to MediaWiki wikitext and
back

Bidirectional conversion between HTML+RDFa and the MediaWiki flavor of wikitext
in a node.js web service.

Bug#831422: RFP: fluxgui -- f.lux indicator applet is an indicator applet to control xflux

[Pierre Rudloff]

Package: wnpp
Severity: wishlist

* Package name: fluxgui
  Version : 1.1.8
  Upstream Author : Kilian Valkhof 
* URL : https://justgetflux.com/
* License : MIT
  Programming Lang: Python
  Description : f.lux indicator applet

f.lux indicator applet is an indicator applet to control xflux, an application
that makes the color of your computer's display adapt to the time of day, warm
at nights and like sunlight during the day

Bug#830906: freepascal textmode IDE crashes on startup on arm64

[Paul Gevers]

Hi,

On 15-07-16 10:49, Paul Gevers wrote:
> If you can wait, I will push my changes to git when I fixed the
> autopkgtest fully (there is still one thing going wrong), so that you
> can upload a new package once Adam has the fix for powerpc or when
> patience is running out.

The git repro of the Debian packaging now has the fix of the armhf issue
and the fixed autopkgtest in. (I didn't include this bugs fix yet).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#830814: Now backlight is turned of when resuming

[Joonas Kylmälä]

So now the keyboard's backlight is always turned off when I resume
from sleep. It was like this once earlier and after that it changed to
the brightness = 1 mode, and so now it is again in brightness = 0
mode. I didn't do any changes specificly for the keyboard – it just
did that by itself.

Bug#831363: jquery-goodies: Update to PHP7.0 dependencies

[Jeremy Bicha]

Control: severity -1 serious

I'm bumping the priority because php5 was removed from Debian testing.
php5 will not be supported in Debian Stretch so it should not be
recommended any more.

Thanks,
Jeremy Bicha

Bug#830230: systemd disable wake-on-lan

[Christian Hofstaedtler]

* Norbert Schulz  [160714 15:12]:
> output of ethtool eth0 with systemd
> Settings for eth0:
[..]
>   MDI-X: on (auto)
>   Wake-on: g
> 
> output of ethtool eth0 with sysvinit
> Settings for eth0:
[..]
>   MDI-X: off (auto)
>   Wake-on: g 

> The difference between them is the MDI-X: value, with systemd it is 'on' and
> with sysvinit it is 'off'.

Which network card and which driver is this?
Are you sure both boot options boot the same Linux kernel version?
(Which ones?)

Please check dmesg if the driver in use prints helpful messages
about the link negotiation (some do, some don't), and if you see
them please report back what they say (for both systemd/sysvinit).

Thanks,
-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#831421: RFP: xubuntu-artwork -- Xubuntu themes and artwork

[Pierre Rudloff]

Package: wnpp
Severity: wishlist

* Package name: xubuntu-artwork
  Version : 16.04.2
  Upstream Author : Xubuntu Team
* URL : https://launchpad.net/xubuntu-artwork
* License : GPL
  Description : Xubuntu themes and artwork

Xubuntu desktop themes and artwork for lightdm and plymouth

This package provides some nice artworks, especially the xubuntu-icon-theme.

Bug#819416: shibboleth-sp2: FTBFS when built with dpkg-buildpackage -A (dh_install: missing files, aborting)

[Ferenc Wágner]

Santiago Vila  writes:

> I have the ok from the Release Managers to consider this issue as RC
> for stretch. I'm going to wait at least one week before raising
> this to "serious".
>
> If you need help to fix this bug, please tag it as "help".

I'm planning to handle this in the next upload, so it's almost
"pending", just haven't quite got there yet.  Got entangled with two
transitions in the stack and some GCC-6 errors.  Next week, hopefully.
-- 
Feri

Bug#753410: ITP: node-chalk -- Terminal string styling

[Mathias Behrle]

Control: owner !

* Ross Gammon: " Re: Bug#753410: ITP: node-chalk -- Terminal string
  styling" (Fri, 15 Jul 2016 18:08:45 +0200):

Hi Ross,

> Hi Mathias,
> 
> On 15/07/16 16:44, Mathias Behrle wrote:
> > Hi Ross,
> >
> > I just took over the RFPs for node-nomnom and node-supports-color,
> > node-nomnom being a dependency for node-po2json/tryton-sao.
> >
> > As you stated on [1] you are currently busy. So may I ask if you already
> > made some progress on the packaging of node-chalk?
> >
> > Regards,
> >
> > Mathias
> >
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774567
> >
> >  
> Excellent news! It is always good when a node package ends up being 
> needed by something else and the workload gets shared ;.)
> 
> I can't remember exactly why I was stalled on node-chalk. It may have 
> been that it turned out to have a lot more dependencies than expected. 
> Even if that was the case, the packaging was probably left in the 
> Javacript Team git repo by Bas for easy resurrection.
> 
> Feel free to take ownership of this ITP, and push it forward. There is 
> no shortage of other node packages that I can start on when I next get a 
> free slot.
> 
> Regards,
> 
> Ross

Indeed there will always be enough work left...;)

So I take this ITP.

Regards,

Mathias


-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6

Bug#831420: RM: xserver-xorg-input-vmmouse -- RoQA; obsolete and conflicts with kernel

[Ben Hutchings]

Package: ftp.debian.org
Severity: normal

This is a driver for the VMware virtual mouse device.  We now enable
the Linux kernel driver for this device, so Xorg will support it
through its generic libinput or evdev driver.  Further, the kernel and
Xorg vmmouse drivers cannot be used at the same time so the current
linux-image packages break this package.

Although this package might conceivably be useful on non-Linux kernels,
it is currently only built for Linux so I don't think that's a reason
to keep it.

Bug#830715: musescore: just rebuilding from source package fixes this

[Giacomo Mulas]

Package: musescore
Version: 2.0.2+dfsg-2
Followup-For: Bug #830715

Dear Maintainer,

musescore became uninstallable when qtquick1 was removed. 
However, it builds flawlessly from the source package: I just did it 
locally and obtained an installable and perfectly working musescore
package. Please just rebuild it ignoring (or removing) the 
build-depends: qtquick1-5-dev and you will get a working package.

Thanks, bye
Giacomo

Bug#831419: ITP: wfuzz -- Web application bruteforcer

[Hugo Lefeuvre]

Package: wnpp
Severity: wishlist
Owner: Hugo Lefeuvre 

* Package name: wfuzz
  Version : 2.1.3
  Upstream Author : Xavier Mendez aka Javi 
Carlos del ojo 
Christian Martorella 
* URL or Web page : https://github.com/xmendez/wfuzz
* License : GPL2+
  Description : a web application bruteforcer

This has already been packaged on Kali[0].

[0] http://pkg.kali.org/pkg/wfuzz

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E


signature.asc
Description: PGP signature

Bug#831418: EOL: not to be released with Stretch

[David Prévot]

Source: zendframework
Severity: serious
Tags: security sid stretch

Hi,

Upstream recently stated [0] that “Zend Framework 1 reaches its End of
Life (EOL) […] on 28 September 2016.”

0: https://framework.zend.com/blog/2016-06-28-zf1-eol.html

Therefore, we should not release it with Stretch (and we’ll do our best
to support it during Jessie lifetime). Reverse dependencies already had
an important bug report about zendframework removal for Stretch a while
ago.

Regards

David


signature.asc
Description: PGP signature

Bug#831416: linux-image-4.6.0-1-amd64: No link on USB3-hub-ethernet adapter Realtek 8153, using r8152

[Marius Mikucionis]

Package: src:linux
Version: 4.6.3-1
Severity: normal

Dear Maintainer,

I'll start with a solution as it is simple to explain:

there is new upstream r8152 driver (v2.06 2016/2/23) which fixes the issue:
http://www.realtek.com.tw/Downloads/downloadsView.aspx?Langid=1=13=56=5=4=3=false

Now the issue:
I have USB3.0 hub with built-in Realtek 8153 ethernet adapter (served by r8152 
driver).
When I plug it into USB2.0 socket it works out-of-the-box automatically: 
ethtool reports "Link detected: yes" and network-manager acquires IP etc..
When I plug it into USB3.0 socket, the device is correctly detected and 
configured (r8152 is loaded and the adapter appears in usbview etc),
but the adapter refuses to sense any network cable, i.e. ethtool reports "Link 
detected: no", consequently the network does not work
(dhclient sends requests but does not get any response).
I cannot use the noted USB2.0 socket for long because this socket is primarily 
used by the charger (it's a laptop without ethernet),
so I need it to work with remaining USB3.0 sockets.

The solution was to download the new driver (linked above), compile, install 
and copy 50-usb-realtek-net.rules into /lib/udev/rules.d -- then it works 
automatically.
So it would be nice if this driver version was included into distribution.

I also found a related problem: 
https://bugzilla.redhat.com/show_bug.cgi?id=1236679
but their workaround did not help me (I tried without tlp and with their fix -- 
the symptoms were the same).

Marius

-- Package-specific info:
** Version:
Linux version 4.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.0 
20160609 (Debian 5.4.0-6) ) #1 SMP Debian 4.6.3-1 (2016-07-04)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.6.0-1-amd64 
root=UUID=b6485691-c9ee-4aad-85ba-4d9a8032e2c7 ro quiet

** Tainted: POE (12289)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded (currently expected).

** Kernel log:
[ 3641.426334] usb 1-5.1: Manufacturer: Realtek
[ 3641.426336] usb 1-5.1: SerialNumber: 0100
[ 3641.497319] usb 1-5.1: reset high-speed USB device number 22 using xhci_hcd
[ 3641.615887] r8152 1-5.1:1.0 eth0: v1.08.3
[ 3641.658110] r8152 1-5.1:1.0 enx00e04c680005: renamed from eth0
[ 3641.691076] IPv6: ADDRCONF(NETDEV_UP): enx00e04c680005: link is not ready
[ 3641.737063] IPv6: ADDRCONF(NETDEV_UP): enx00e04c680005: link is not ready
[ 3644.326690] IPv6: ADDRCONF(NETDEV_CHANGE): enx00e04c680005: link becomes 
ready
[ 3712.823926] [drm:intel_pipe_update_start [i915]] *ERROR* Potential atomic 
update failure on pipe A
[ 4009.221118] usbcore: deregistering interface driver r8152
[ 4091.423337] usb 1-5.1: reset high-speed USB device number 22 using xhci_hcd
[ 4091.598695] r8152 1-5.1:1.0 eth0: v2.06.0 (2016/01/14)
[ 4091.598699] r8152 1-5.1:1.0 eth0: This product is covered by one or more of 
the following patents:
US6,570,884, US6,115,776, and US6,327,625.
   
[ 4091.598750] usbcore: registered new interface driver r8152
[ 4091.599333] r8152 1-5.1:1.0 enx00e04c680005: renamed from eth0
[ 4091.623307] IPv6: ADDRCONF(NETDEV_UP): enx00e04c680005: link is not ready
[ 4091.649105] IPv6: ADDRCONF(NETDEV_UP): enx00e04c680005: link is not ready
[ 4094.461390] IPv6: ADDRCONF(NETDEV_CHANGE): enx00e04c680005: link becomes 
ready
[ 4159.601904] r8152 1-5.1:1.0 enx00e04c680005: Rx status -71
[ 4159.601941] r8152 1-5.1:1.0 enx00e04c680005: Rx status -71
[ 4159.601986] r8152 1-5.1:1.0 enx00e04c680005: Rx status -71
[ 4159.602025] r8152 1-5.1:1.0 enx00e04c680005: Rx status -71
[ 4159.602068] r8152 1-5.1:1.0 enx00e04c680005: Rx status -71
[ 4159.602115] r8152 1-5.1:1.0 enx00e04c680005: Rx status -71
[ 4159.602161] r8152 1-5.1:1.0 enx00e04c680005: Rx status -71
[ 4159.602200] r8152 1-5.1:1.0 enx00e04c680005: Rx status -71
[ 4159.602251] r8152 1-5.1:1.0 enx00e04c680005: Rx status -71
[ 4159.602290] r8152 1-5.1:1.0 enx00e04c680005: Rx status -71
[ 4159.603215] usb 1-5: USB disconnect, device number 21
[ 4159.603220] usb 1-5.1: USB disconnect, device number 22
[ 4163.514874] usb 1-5: new high-speed USB device number 34 using xhci_hcd
[ 4163.646658] usb 1-5: New USB device found, idVendor=05e3, idProduct=0610
[ 4163.646663] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 4163.64] usb 1-5: Product: USB2.0 Hub
[ 4163.646668] usb 1-5: Manufacturer: GenesysLogic
[ 4163.647414] hub 1-5:1.0: USB hub found
[ 4163.647686] hub 1-5:1.0: 4 ports detected
[ 4163.918884] usb 1-5.1: new high-speed USB device number 35 using xhci_hcd
[ 4164.008236] usb 1-5.1: New USB device found, idVendor=0bda, idProduct=8153
[ 4164.008243] usb 1-5.1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=6
[ 4164.008248] usb 1-5.1: Product: USB 10/100/1000 LAN
[ 4164.008251] usb 1-5.1: Manufacturer: Realtek
[ 4164.008254] usb 1-5.1: SerialNumber: 0100
[ 4164.095157] usb 1-5.1: reset high-speed USB device number 35 using xhci_hcd
[ 4164.243840] 

Bug#798476: debian-policy: don't require Uploaders

[Tobias Frost]

Am Freitag, den 08.07.2016, 17:36 +0200 schrieb Christian Hofstaedtler:
> * Julien Cristau  [160708 15:31]:
> > for some time I've been uploading packages with Maintainer set to a
> > mailing list and no Uploaders field.  In cases where some package
> > kind
> > of fit within a team, but noone cares specifically about that
> > individual
> > package, I feel it's better than setting Maintainer to the Debian
> > QA
> > Group, which policy currently says is required, since the team will
> > get
> > bug mail, and any updates to the package will probably come from
> > the
> > team anyway.  So I'd like to see this requirement relaxed.
> 
> I also want to see this. It makes lots of sense, especially for
> teams maintaining very large numbers of packages. Honestly, the
> individual package does not carry heavy weight in some of those
> teams. 

Mmm, In theory you're right. However in practice see also some
downsides. For at least some teams it is not very clear who is member
of it and on especially smaller teams it is sometimes quite unclear if
the team exists at all. 
Especially in such it will then be lots harder to actually detect an
orphaned package and this might even deter some person taking over the
package. 

> At the same time, many packages carry old Uploaders,
> including names of people that have long been known to be MIA, and
> are kept there only to avoid setting an empty Uploaders field.

Which makes this information invisible to people outside of the team. 

> These packages are clearly not not-maintained (teams care about
> them), so orphaning or assinging to Debian QA Group would make no
> sense whatsoever.

YMMV. That requires a hell of discipline in the team. 
There are many teams that take quite great care about the packages, but
others do not so well (or even existing only on paper anymore). 

>From my short time as MIA member I can tell it is already hard enough
to find persons being MIA; to track complete teams will be lot harder.
(
e.g the question who is actually a team member is sometimes hard to
answer from outside)

IMHO if the team commits to maintain that package it shouldn't be too much 
strain to add an explict carer too, is it? 

> (Also, as far as I'm aware, the large teams are
> all very open for anybody to join.)

For that people need to know that that particular package is up for
adoption. That information would be harder to retrieve. 
However wnpp could be used as a tool here: Why not advertise 
using a RFA and telling there that the team has open positions?

Maybe we should dicsuss this on -devel to get more other views and
arguments too?

-- 
tobi

Bug#831417: xmlcopyeditor: please make the build reproducible

[Chris Lamb]

Source: xmlcopyeditor
Version: 1.2.1.3-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed
that xmlcopyeditor could not be built reproducibly.

Patch attached.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2016-07-15 17:57:28.461699383 +0200
--- b/debian/rules  2016-07-15 20:49:06.614047198 +0200
@@ -81,6 +81,7 @@
chmod 664 $(CURDIR)/debian/xmlcopyeditor/usr/share/xmlcopyeditor/*/*/*.*
chmod 755 `find 
$(CURDIR)/debian/xmlcopyeditor/usr/share/xmlcopyeditor/dtd/docbook/ -type d`
rm -rf $(CURDIR)/debian/xmlcopyeditor/usr/share/xmlcopyeditor/copying
+   rm -rf 
$(CURDIR)/debian/xmlcopyeditor/usr/share/xmlcopyeditor/po/.intltool-merge-cache
sed -i 's/\r//g' 
$(CURDIR)/debian/xmlcopyeditor/usr/share/applications/xmlcopyeditor.desktop
dh_installmenu
dh_installman debian/xmlcopyeditor.1

Bug#815793: IPv6 code ignores unsolicited router advertisements

[Marc Haber]

Hi Martin,

On Wed, Jul 06, 2016 at 08:57:43AM +0200, Martin Pitt wrote:
> while we reverted the change in 229, we don't want to carry the
> reversion forever. Also, some problems were fixed already in 230, like
> [1]. I forwarded this upstream to
> https://github.com/systemd/systemd/issues/3663, and will now play
> relay :-)
> 
> If this is hardware specific, can you please try this with 230 with
> the patch reverted? I build packages for amd64 here:
> https://people.debian.org/~mpitt/tmp/systemd-userspace-ndisc/
> (there's also a Packages.gz so this can be used as an apt deb line)
> There were a lot of changes to the RA handling in 230.

Unfortunately the system I have been seeing this on is a Banana Pi,
thus armhf, and I cannot run your test packages on this system. This
bug does not, however, show itself on a reference system running amd64
with 230-5pitti1.

I have found another showstopper IPv6 bug in 230-5pitti1 and have duly
reported it.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#831415: xsel: cannot run in xfce4-genmon-plugin

[Nathaniel Morck Beaver]

Package: xsel
Version: 1.2.0-2
Severity: wishlist

Dear Maintainer,

When 'xsel' is run in the XFCE panel from the "Generic Monitor" plugin, 
it fails with this error:



xsel: fstat error on stdin: Bad file descriptor


This appears to be because 'xsel' runs fstat (0, _statbuf) even if 
the --output flag is enabled.


One workaround is to write a wrapper script that calls xsel like this:

xsel < /dev/null

This is also reproducible on Debian sid.

Sincerely,

Nathaniel Beaver

P.S. See the sister bug for xfce4-genmon-plugin here:

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

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

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xsel depends on:
ii  libc6 2.19-18+deb8u4
ii  libx11-6  2:1.6.2-3

xsel recommends no packages.

xsel suggests no packages.

-- no debconf information

Bug#830356: Pending fixes for bugs in the libhttp-oai-perl package

[pkg-perl-maintainers]

tag 830356 + pending
thanks

Some bugs in the libhttp-oai-perl package are closed in revision
f2a70ebff0f524a0a5bea71f551a44f98df6f27d in branch 'master' by gregor
herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libhttp-oai-perl.git/commit/?id=f2a70eb

Commit message:

Add patch to skip tests which do a DNS query.

Thanks: Chris Lamb for the bug report.
Closes: #830356

Bug#827883: tellico: diff for NMU version 2.3.9+dfsg.1-1.1

[zeha]

Control: tags 827883 + pending

Dear maintainer,

I've prepared an NMU for tellico (versioned as 2.3.9+dfsg.1-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Cheers,
Chris

diff -Nru tellico-2.3.9+dfsg.1/debian/changelog 
tellico-2.3.9+dfsg.1/debian/changelog
--- tellico-2.3.9+dfsg.1/debian/changelog   2014-10-18 10:42:24.0 
+
+++ tellico-2.3.9+dfsg.1/debian/changelog   2016-07-15 13:42:28.0 
+
@@ -1,3 +1,11 @@
+tellico (2.3.9+dfsg.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop build dependency on obsolete nepomuk-core-dev. (Closes: #827883)
+Patch from Pino Toscano .
+
+ -- Christian Hofstaedtler   Fri, 15 Jul 2016 13:42:26 +
+
 tellico (2.3.9+dfsg.1-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru tellico-2.3.9+dfsg.1/debian/control 
tellico-2.3.9+dfsg.1/debian/control
--- tellico-2.3.9+dfsg.1/debian/control 2014-10-18 10:43:48.0 +
+++ tellico-2.3.9+dfsg.1/debian/control 2016-07-15 13:39:57.0 +
@@ -2,7 +2,7 @@
 Section: kde
 Priority: optional
 Maintainer: Regis Boudin 
-Build-Depends: debhelper (>= 9), cmake, pkg-config, pkg-kde-tools (>= 0.9), 
kdelibs5-dev (>=4:4.7), libxml2-dev, libxslt1-dev, libtag1-dev, libyaz4-dev, 
libkcddb-dev, kdepimlibs5-dev (>=4:4.7), libpoppler-qt4-dev, libexempi-dev, 
libqimageblitz-dev, nepomuk-core-dev, libksane-dev, shared-desktop-ontologies, 
libqjson-dev
+Build-Depends: debhelper (>= 9), cmake, pkg-config, pkg-kde-tools (>= 0.9), 
kdelibs5-dev (>=4:4.7), libxml2-dev, libxslt1-dev, libtag1-dev, libyaz4-dev, 
libkcddb-dev, kdepimlibs5-dev (>=4:4.7), libpoppler-qt4-dev, libexempi-dev, 
libqimageblitz-dev, libksane-dev, shared-desktop-ontologies, libqjson-dev
 Standards-Version: 3.9.6
 Homepage: http://tellico-project.org/
 Vcs-Git: git://anongit.kde.org/tellico.git

Bug#831414: systemd: learns IPv6 prefix from its own RAs and configures IP address on wrong interface

[Marc Haber]

Package: systemd
Version: 230-5pitti1
Severity: minor
Tags: ipv6

Hi,

I am filing this as severity minor because this bug is in a version
that is not officially in Debian. I am filing it nevertheless because
systemd with this IPv6 user space code active should not be in Debian.
If this were an official version, this would be an important bug, with
the potential for "serious" at maintainer discretion.

While following up Martin's requests for #815793 and #815884, I have
found new misbehsvior regarding IPv6.

Given a host that also acts as a router, with the following network
setup:

2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
link/ether 54:04:a6:82:21:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.182.250/32 brd 192.168.182.250 scope global eth0
   valid_lft forever preferred_lft forever
inet 192.168.182.29/24 brd 192.168.182.255 scope global dynamic eth0
   valid_lft 12650sec preferred_lft 12650sec
inet6 2001:db8:0:3282:5604:a6ff:fe82:2100/64 scope global mngtmpaddr 
noprefixroute dynamic
   valid_lft 86309sec preferred_lft 14309sec
inet6 2001:db8:0:3282::1d:250/128 scope global
   valid_lft forever preferred_lft forever
inet6 2001:db8:0:3282::1d:100/64 scope global
   valid_lft forever preferred_lft forever
inet6 fe80::5604:a6ff:fe82:2100/64 scope link
   valid_lft forever preferred_lft forever
3: br0:  mtu 1500 qdisc noqueue state UP group 
default qlen 1000
link/ether c6:f4:98:dc:5e:21 brd ff:ff:ff:ff:ff:ff
inet 192.168.29.254/24 brd 192.168.29.255 scope global br0
   valid_lft forever preferred_lft forever
inet6 2001:db8:0:328d::1d:153/64 scope global
   valid_lft forever preferred_lft forever
inet6 2001:db8:0:328d::1d:100/64 scope global
   valid_lft forever preferred_lft forever
inet6 fec0:0:0:::3/128 scope site
   valid_lft forever preferred_lft forever
inet6 fec0:0:0:::2/128 scope site
   valid_lft forever preferred_lft forever
inet6 fec0:0:0:::1/128 scope site
   valid_lft forever preferred_lft forever
inet6 fe80::c4f4:98ff:fedc:5e21/64 scope link
   valid_lft forever preferred_lft forever

On br0, there is a radvd, advertising a prefix on br0:
interface br0 {
AdvSendAdvert on;
MinRtrAdvInterval 600;
MaxRtrAdvInterval 1200;
prefix 2001:db8:0:328d::/64 {
DeprecatePrefix on;
};
RDNSS 2001:db8:0:328d::1d:153 {
AdvRDNSSLifetime 1200;
};
};

When the radvd is started, the local host seems to learn the prefix
from the locally running radvd and _configures_ _it_ _on_ _eth0_,
which is plain wrong:

2: eth0:  mtu 1500 qdisc pfifo_fast state UP gr
oup default qlen 1000
link/ether 54:04:a6:82:21:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.182.250/32 brd 192.168.182.250 scope global eth0
   valid_lft forever preferred_lft forever
inet 192.168.182.29/24 brd 192.168.182.255 scope global dynamic eth0
   valid_lft 12530sec preferred_lft 12530sec
inet6 2001:db8:0:328d:5604:a6ff:fe82:2100/64 scope global mngtmpaddr 
noprefixroute dynamic
   valid_lft 86390sec preferred_lft 14390sec
inet6 2001:db8:0:3282:5604:a6ff:fe82:2100/64 scope global mngtmpaddr 
noprefixroute dynamic
   valid_lft 86189sec preferred_lft 14189sec
inet6 2001:db8:0:3282::1d:250/128 scope global
   valid_lft forever preferred_lft forever
inet6 2001:db8:0:3282::1d:100/64 scope global
   valid_lft forever preferred_lft forever
inet6 fe80::5604:a6ff:fe82:2100/64 scope link
   valid_lft forever preferred_lft forever

It also learns a default route pointing to its own link local IP
address on br0:

[2/502]mh@fan:~$ ip -6 r
2001:db8:0:3282::1d:250 dev eth0  proto kernel  metric 256  pref medium
2001:db8:0:3282::/64 dev eth0  proto kernel  metric 256  pref medium
2001:db8:0:3282::/64 dev eth0  proto ra  metric 1024  pref medium
2001:db8:0:328d::/64 dev br0  proto kernel  metric 256  pref medium
2001:db8:0:328d::/64 dev eth0  proto ra  metric 1024  pref medium
fe80::/64 dev eth0  proto kernel  metric 256  pref medium
fe80::/64 dev dummy0  proto kernel  metric 256  pref medium
fe80::/64 dev br0  proto kernel  metric 256  pref medium
fe80::/64 dev vnet0  proto kernel  metric 256  pref medium
fec0:0:0:::1 dev br0  proto kernel  metric 256  pref medium
fec0:0:0:::2 dev br0  proto kernel  metric 256  pref medium
fec0:0:0:::3 dev br0  proto kernel  metric 256  pref medium
default via fe80::1 dev eth0  proto ra  metric 1024  hoplimit 64 pref high
default via fe80::c4f4:98ff:fedc:5e21 dev eth0  proto ra  metric 1024  pref 
medium
[3/503]mh@fan:~$

which is also plain wrong.

While it is proably debateable whether a host is supposed to learn an
IPv6 prefix from a locally running radvd (I can't quote the relevant
parts of the standard right now), it is plain wrong to configure the
newly learned IP address on a totally different interface and to

Bug#828854: [codeh...@debian.org: Bug#828854: RM: debian-installer [kfreebsd-amd64 kfreebsd-i386] -- RoQA; Fails to build on kfreebsd]

[Steven Chamberlain]

Hello,

Steve McIntyre wrote:
> [...] we're proposing to remove
> them. We're *fairly* sure this shouldn't cause problems for you as
> these binaries are ancient - please confirm!

I'm quite sure this is okay.  The binaries we care most about are in the
separate jessie-kfreebsd-proposed-updates suite.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#831413: xfce4-genmon-plugin: missing /dev/stdin when spawned command is xsel

[Nathaniel Morck Beaver]

Package: xfce4-genmon-plugin
Version: 3.4.0-2
Severity: normal

Dear Maintainer,

When the spawned command is set to 'xsel' to show the text currently in 
the primary clipboard, 'xsel' fails because there is no /dev/stdin, 
presumably since genmon_Spawn() closes stdin.


This is also reproducible on 3.4.0-2+b1 on Debian unstable.

One workaround is to write a wrapper script like this:

xsel < /dev/stdin

However, it would be better if this were not necessary.

I will also file a feature request for 'xsel' in case that would be better.

Sincerely,

Nathaniel Beaver

P.S. Another workaround is to use 'xclip -o', since 'xclip' does not 
require stdin.


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

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xfce4-genmon-plugin depends on:
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u4
ii  libcairo21.14.0-2.1+deb8u1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-3+deb8u1
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
ii  libglib2.0-0 2.42.1-1+b1
ii  libgtk2.0-0  2.24.25-3+deb8u1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libxfce4ui-1-0   4.10.0-6
ii  libxfce4util64.10.1-2
ii  xfce4-panel  4.10.1-1

xfce4-genmon-plugin recommends no packages.

xfce4-genmon-plugin suggests no packages.

-- no debconf information

Bug#831404: yersinia: please make the build reproducible

[Chris Lamb]

Hi,

> Patch attached. Please send it upstream if possible.

Corrected patch attached. Apologies for the noise!


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/configure.in b/configure.in
index 5e45e68..98f895d 100644
--- a/configure.in
+++ b/configure.in
@@ -839,6 +839,13 @@ info_kern="`uname -s`"
 info_kern_ver="`uname -r`"
 info_platform="`uname -m`"
 
+if test -n "$SOURCE_DATE_EPOCH"; then
+   info_date="`LC_ALL=C date --utc --date=@$SOURCE_DATE_EPOCH '+%a 
%d-%b-%Y %H:%M'`"
+   info_kern="`lsb_release --short --id`"
+   info_kern_ver="`lsb_release --short --id`"
+   info_platform="`lsb_release --short --id`"
+fi
+
 AC_DEFINE_UNQUOTED(INFO_KERN, "$info_kern")
 AC_DEFINE_UNQUOTED(INFO_KERN_VER, "$info_kern_ver")
 AC_DEFINE_UNQUOTED(INFO_PLATFORM, "$info_platform")
diff --git a/debian/control b/debian/control
index f5379be..33e1a7b 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: yersinia
 Section: admin
 Priority: optional
 Maintainer: Noël Köthe 
-Build-Depends: debhelper (>= 9.0.0), autotools-dev, libncurses5-dev (>=5.4), 
libnet1-dev (>=1.1.2), libpcap0.8-dev, libgtk2.0-dev
+Build-Depends: debhelper (>= 9.0.0), autotools-dev, libncurses5-dev (>=5.4), 
libnet1-dev (>=1.1.2), libpcap0.8-dev, libgtk2.0-dev, lsb-release
 Standards-Version: 3.9.8
 Homepage: http://www.yersinia.net/
 

Bug#831356: Option "non-unix" is broken and leads to segmentation fault

[Solar Designer]

Hi Jim,

On Thu, Jul 14, 2016 at 04:02:18PM -0400, Jim Paris wrote:
> With a pam configuration like:
> 
>   password required pam_passwdqc.so min=disabled,8,8,7,7 retry=1 non-unix 
> random=32 enforce=users
> 
> The passwdqc module fails with a segmentation fault.  This is because,
> in non-unix mode, pam_sm_chauthtok builds up a fake "struct passwd" on
> the stack:

Thank you for reporting this bug.  I can confirm it from looking at the
source code, although the segfault does not happen for me - I guess a
valid pointer just happens to be in that stack location on my system.

I intend to fix it shortly and put out a new upstream passwdqc release,
which Debian would then need to update to.

Alexander

Bug#831412: FTBFS: missing build dependency on uglifyjs

[Hans Joachim Desserud]

Source: underscore.string
Version: 3.3.4+dfsg-1
Severity: important

Dear Maintainer,

When attempting to build underscore.string from source, it fails with
the following error message:
dh build
   dh_testdir
   dh_update_autotools_config
   dh_auto_configure
   debian/rules override_dh_auto_build
make[1]: Entering directory 
'/home/debian/dev/underscore.string-3.3.4+dfsg'

uglifyjs -o dist/underscore.string.min.js dist/underscore.string.js
make[1]: uglifyjs: Command not found
debian/rules:6: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 127
make[1]: Leaving directory 
'/home/debian/dev/underscore.string-3.3.4+dfsg'

debian/rules:3: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2



Adding a build dependency on uglifyjs resolves the issue.

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

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


--
mvh / best regards
Hans Joachim Desserud
http://desserud.org

Bug#830978: Browserified javascript and DFSG 2

[Pirate Praveen]

On 2016, ജൂലൈ 15 10:46:51 PM IST, Ian Jackson  
wrote:
>Sam Hartman writes ("Bug#830978: Browserified javascript and DFSG 2"):
>> Speaking as an individual TC member, here's my personal reading of
>the
>> TC discussion.
>> 
>> It's not clear that the TC is the right body for this discussion.  We
>> certainly could offer advice, but it's not clear that the ftpmasters
>or
>> release team--the parties most likely to need such advice-- would
>> benefit from our advice.
>
>I would like to comment briefly on the general idea about the TC
>offering advice and making statements of opinion.
>
>
>If someone in authority in the project, such as a maintainer of the
>ftpmasters or the release team, is doing something which the TC thinks
>is wrong, then (if the question is important) I think it would be
>entirely appropriate for the TC to issue a statement of opinion,
>disagreeing with the other authority.
>
>Conversely, if a contributor has been criticised, they may welcome a
>message of support from the TC.  That may help lay to rest an
>unfounded criticism and save the contributor the energy required to
>wonder whether they're really right, rebut any public criticisms, and
>so on.

I agree.

>And finally if a question needs authoritative input but the relevant
>authority in Debian has not made a clear decision, TC involvement
>might help get the matter properly resolved.
>
>
>In this case I think that it would be worth TC members considering,
>for themselves, briefly, and without too much back-and-forth enquiry,
>what their initial assessments of the merits of the situation are.
>
>If TC members feel that the submitter of #817092 (Luke, who is
>complaining that the aggregated file is not source, along with Ben,
>Jonas etc.) are right, they could ask the release team and the
>ftpmasters (informally, perhaps) whether the release team would
>welcome a supportive TC intervention.
>
>That would allow the TC to help settle this long-running question
>(which keeps coming up on -devel and is frankly quite annoying).
>
>This is true even though it seems the specific case of
>libjs-handlebars has a more clear-cut problem, as found by Ansgar and
>described in #830986.
>
>
>Concretely, as one of the people who agree with the submitter of
>#817092, I would like to see the TC pass a resolution along these
>lines:
>
> The TC gives a non-binding statement of opinion:
>
> * The point of having the source code (with an appropriate licence
>   etc.) is so that all our contributors, downstreams, and users are
>   able to modify the code and to share their modifications with each
>   other, with Debian, and with upstream.

I agree this is an important consideration, but not serious enough to reject a 
package.

If this argument is accepted, we will not be able to package a fork because the 
original upstream won't accept a patch against the fork. Similarly we'd be able 
to package only HEAD of the vcs as they usually accept patched only against 
HEAD. Porting patches is an essential part of packaging. By choosing to 
maintain this source, I accept this challenge. If I cannot keep the package rc 
bug free otherwise, it will be removed any way.

> * In particular, Debian will often want to share modifications with
>   upstream, which means that we need to be working with the software
>   in a form which lets us do so.

This is ideal thing, but should not be a requirement to qualify as dfsg-free.

> * For Debian, therefore, the source code for a file or program is the
>   form which can be conveniently modified and shared; specifically,
>   the form in which upstream will accept patches.

This was never the intention of dfsg, it was always about freedoms of the user 
receiving the source code.

Our only consideration for dfsg qualification would be to see if a user can 
exercise freedoms in a generally accepted way. In this case, would some 
comfortable with javascript modify the code? If they are able to modify the 
split files, they will be able to modify the browserified files as well without 
any extra complexity.

As for patches from upstream, the effort is similar to backporting. Same for 
sending patches upstream, effort is similar to rebasing.

> * There may be exceptions to this principle but none of them apply in
>   the case of libjs-handlebars.  We do not expect that any such
>   exception would be applicable to other concatenated or
>   `browserified' JavaScript files generated with tools like Grunt,
>   even if the JavaScript output is not minified or obfuscated.

Any JavaScript source that is not obfuscated or minified should be considered 
source.

> * So in the case of bug #817092 against libjs-handlebars, the
>   concatened JavaScript is not, in our opinion, source code.  This
>   would remain true even if the parser-generator input mentioned in
>   bug #830986 were available.

It should be considered dfsg-free.

>
>I think this would help save debian-devel a lot of annoying threads.

I 

Bug#822717: flann: FTBFS with GCC 6: call of overloaded 'abs(

[Andreas Metzler]

Control: tags -1 fixed upstream

On 2016-04-26 Martin Michlmayr  wrote:
> Package: flann
> Version: 1.8.4-4.1
[...]
> > /<>/examples/flann_example.cpp:36:1:   required from here
> > /<>/src/cpp/flann/algorithms/kdtree_index.h:666:39: error: 
> > call of overloaded 'abs(flann::KDTreeIndex > >::ElementType)' is ambiguous
[...]

This is fixed in 1.8.5.

http://github.com/mariusmuja/flann/releases
cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#831411: RFS: jigzo/0.6.1-7 RC

[Elías Alejandro]

Package: sponsorship-requests
  Severity: RC

  Dear mentors,

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

 * Package name: jigzo
   Version : 0.6.1-7
   Upstream Author : Maarten de Boer 
 * URL : http://www.resorama.com/jigzo
 * License : GPL-2+
   Section : games

  It builds those binary packages:

jigzo - Photo puzzle game for children
jigzo-data - data of Photo puzzle game for children

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

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


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

dget -x
https://mentors.debian.net/debian/pool/main/j/jigzo/jigzo_0.6.1-7.dsc

  Changes since the last upload:

  jigzo (0.6.1-7) unstable; urgency=medium

  * Fix FTBFS with gcc6: add patch 07_gcc_6.patch (Closes: #811796)
  * Bump Standards-Version to 3.9.8
  * Bump debhelper build-dep and compat to 9
  * debian/rules with extra option to make hardening better
  * Improving hardening: add 08_hardening.patch
  * debian/copyright update
  * Remove jigzo.menu (Closes: #737932)
  * jigzo.desktop: add keywords entry


  Regards,
   Elías Alejandro

Bug#831181: patch

[Gianfranco Costamagna]

control: tags -1 patch
control: tags -1 pending

Hi maintainer, the patch for this issue has been uploaded on deferred/5, and 
attached
to this email.

G.


debdiff
Description: Binary data

Bug#831109: mathic: FTBFS with GCC 6: dh_makeshlibs: failing due to earlier errors

[Doug Torrance]

Control: tags -1 pending

On 07/14/2016 04:06 AM, Lucas Nussbaum wrote:

Source: mathic
Version: 1.0~git20160320-3
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160713 qa-ftbfs
Justification: FTBFS with GCC 6 on amd64

Hi,

During a rebuild of all packages in sid using the gcc-defaults package
available in experimental to make GCC default to version 6, your package failed
to build on amd64. For more information about GCC 6 and Stretch, see:
- https://wiki.debian.org/GCC6
- https://lists.debian.org/debian-devel-announce/2016/06/msg7.html

Relevant part (hopefully):

make[1]: Entering directory '/«PKGBUILDDIR»'
dh_strip --dbgsym-migration='libmathic-dbg (<< 1.0~git20160320-1~)'
make[1]: Leaving directory '/«PKGBUILDDIR»'
dh_makeshlibs -a
dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libmathic0v5/DEBIAN/symbols doesn't match 
completely debian/libmathic0v5.symbols
--- debian/libmathic0v5.symbols (libmathic0v5_1.0~git20160320-3_amd64)
+++ dpkg-gensymbols3hUTVg   2016-07-13 19:29:21.32400 +
@@ -102,7 +102,7 @@
   _ZNK6mathic10HelpAction5topicB5cxx11Ev@Base 1.0~git20160320
   _ZNK6mathic11BitTriangle12getMemoryUseEv@Base 1.0~git20130827
   
_ZNK6mathic11NameFactoryINS_6ActionEE15namesWithPrefixERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERSt6vectorIS8_SaIS8_EE@Base
 1.0~git20160320
- 
(optional)_ZNK6mathic11NameFactoryIPvE15namesWithPrefixERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERSt6vectorIS8_SaIS8_EE@Base
 1.0~git20160320
+#MISSING: 1.0~git20160320-3# 
(optional)_ZNK6mathic11NameFactoryIPvE15namesWithPrefixERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERSt6vectorIS8_SaIS8_EE@Base
 1.0~git20160320
   _ZNK6mathic13BoolParameter12argumentTypeB5cxx11Ev@Base 1.0~git20160320
   _ZNK6mathic13BoolParameter13valueAsStringB5cxx11Ev@Base 1.0~git20160320
   _ZNK6mathic13ColumnPrinter14getColumnCountEv@Base 1.0~git20130827
@@ -118,15 +118,15 @@
   
_ZNK6mathic9CliParser29pushBackRegisteredActionNamesERSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE@Base
 1.0~git20160320
   
_ZNSt10unique_ptrIN6mathic13ColumnPrinter3ColESt14default_deleteIS2_EED1Ev@Base 
1.0~git20160320
   
_ZNSt10unique_ptrIN6mathic13ColumnPrinter3ColESt14default_deleteIS2_EED2Ev@Base 
1.0~git20160320
- 
_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE19_M_emplace_back_auxIIRKS5_EEEvDpOT_@Base
 1.0~git20160320
+#MISSING: 1.0~git20160320-3# 
_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE19_M_emplace_back_auxIIRKS5_EEEvDpOT_@Base
 1.0~git20160320
   
_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE19_M_emplace_back_auxIJRKS5_EEEvDpOT_@Base
 1.0~git20160320
   
_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EED1Ev@Base
 1.0~git20160320
   
_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EED2Ev@Base
 1.0~git20160320
- 
_ZNSt6vectorISt10unique_ptrIN6mathic13ColumnPrinter3ColESt14default_deleteIS3_EESaIS6_EE19_M_emplace_back_auxIIS6_EEEvDpOT_@Base
 1.0~git20130827
+#MISSING: 1.0~git20160320-3# 
_ZNSt6vectorISt10unique_ptrIN6mathic13ColumnPrinter3ColESt14default_deleteIS3_EESaIS6_EE19_M_emplace_back_auxIIS6_EEEvDpOT_@Base
 1.0~git20130827
   
_ZNSt6vectorISt10unique_ptrIN6mathic13ColumnPrinter3ColESt14default_deleteIS3_EESaIS6_EE19_M_emplace_back_auxIJS6_EEEvDpOT_@Base
 1.0~git20130827
   
_ZNSt6vectorISt10unique_ptrIN6mathic13ColumnPrinter3ColESt14default_deleteIS3_EESaIS6_EED1Ev@Base
 1.0~git20130827
   
_ZNSt6vectorISt10unique_ptrIN6mathic13ColumnPrinter3ColESt14default_deleteIS3_EESaIS6_EED2Ev@Base
 1.0~git20130827
- 
_ZNSt6vectorISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPFSt10unique_ptrIPvSt14default_deleteIS8_EEvEESaISE_EE19_M_emplace_back_auxIISE_EEEvDpOT_@Base
 1.0~git20160320
+#MISSING: 1.0~git20160320-3# 
_ZNSt6vectorISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPFSt10unique_ptrIPvSt14default_deleteIS8_EEvEESaISE_EE19_M_emplace_back_auxIISE_EEEvDpOT_@Base
 1.0~git20160320
   
_ZNSt6vectorISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPFSt10unique_ptrIPvSt14default_deleteIS8_EEvEESaISE_EE19_M_emplace_back_auxIJSE_EEEvDpOT_@Base
 1.0~git20160320
   _ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED0Ev@Base 
1.0~git20160320
   _ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED1Ev@Base 
1.0~git20160320
dh_makeshlibs: failing due to earlier errors
make: *** [binary-arch] Error 255


The full build log is available from:

http://people.debian.org/~lucas/logs/2016/07/13/mathic_1.0~git20160320-3_unstable_gcc6.log


Thanks for the report!

I have pushed a fix to git marking the offending tags as optional [1] 
and have requested sponsorship for an upload of the new version.


Doug

[1] 

Bug#831403: xmlgraphics-commons: FTBFS: Could not initialize class org.mockito.Mockito

[Emmanuel Bourg]

Control: reassign -1 mockito 1.10.19-1
Control: affects -1 xmlgraphics-commons

On 07/15/2016 06:24 PM, Chris Lamb wrote:

>   [junit] Caused by: java.lang.ClassNotFoundException: 
> net.sf.cglib.proxy.Callback
>   [junit] at 
> java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>   [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   [junit] at 
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
>   [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

Thank you for the report Chris. This issue was caused by the latest
mockito update, the mockito jar no longer has a Class-Path attribute and
this package relied on it. I'll fix mockito.

Bug#831409: ltsp-client lacks gnupg / gnupg2 for apt-key to work

[Wolfgang Schweer]

Source: ltsp
Version: 5.5.7
Severity: important
User: debian-...@lists.debian.org
Usertag: debian-edu

Hi,

while testing Debian Edu stretch I noticed that the LTSP chroot failed 
to build.

This is most probably caused by a recent change to apt, see: #830696

I faced this error too:
Error: gnupg or gnupg2 do not seem to be installed,
Error: but apt-key requires gnupg or gnupg2 for this operation.

Adding gnupg or gnupg2 to the early packages list was to no avail.
But after commenting out the apt-key call the chroot was built.

Not quite sure, but I guess gnupg2 | gnupg might be needed as 
Pre-Depends of ltsp-client.

Wolfgang


signature.asc
Description: Digital signature

Bug#830978: Browserified javascript and DFSG 2

[Ian Jackson]

Ian Jackson writes ("Re: Bug#830978: Browserified javascript and DFSG 2"):
> I would like to comment briefly

I'm sorry that I so evidently failed !

Ian.

Bug#831408: ITP: bcolz -- compressed data container for NumPy

[Daniel Stender]

Package: wnpp
Severity: wishlist
Owner: Daniel Stender 

* Package name: bcolz
  Version : 1.1.0
  Upstream Author : Francesc Alted 
* URL : https://github.com/Blosc/bcolz
* License : BSD-3-Clause
  Programming Lang: Python
  Description : compressed data container for NumPy

Bcolz [1] features data containers for NumPy, which are compressed
either on disk or also in-memory, and are accessible chunkwise [2]. For
compression it uses Blosc [3]. It has also import/export facilities for
HDF5 or PyTables data, and Pandas data frames.

I'm going to package this for the Debian Science Group. The binary is
going to be python3-bcolz (maybe also with Python 2 package).

Thanks,
DS

[1] http://bcolz.blosc.org/en/latest/

[2] https://www.youtube.com/watch?v=-AlKImuKTcs (presentation by the author)

[3] https://packages.qa.debian.org/c/c-blosc.html

Bug#830978: Browserified javascript and DFSG 2

[Ian Jackson]

Sam Hartman writes ("Bug#830978: Browserified javascript and DFSG 2"):
> Speaking as an individual TC member, here's my personal reading of the
> TC discussion.
> 
> It's not clear that the TC is the right body for this discussion.  We
> certainly could offer advice, but it's not clear that the ftpmasters or
> release team--the parties most likely to need such advice-- would
> benefit from our advice.

I would like to comment briefly on the general idea about the TC
offering advice and making statements of opinion.


If someone in authority in the project, such as a maintainer of the
ftpmasters or the release team, is doing something which the TC thinks
is wrong, then (if the question is important) I think it would be
entirely appropriate for the TC to issue a statement of opinion,
disagreeing with the other authority.

Conversely, if a contributor has been criticised, they may welcome a
message of support from the TC.  That may help lay to rest an
unfounded criticism and save the contributor the energy required to
wonder whether they're really right, rebut any public criticisms, and
so on.

And finally if a question needs authoritative input but the relevant
authority in Debian has not made a clear decision, TC involvement
might help get the matter properly resolved.


In this case I think that it would be worth TC members considering,
for themselves, briefly, and without too much back-and-forth enquiry,
what their initial assessments of the merits of the situation are.

If TC members feel that the submitter of #817092 (Luke, who is
complaining that the aggregated file is not source, along with Ben,
Jonas etc.) are right, they could ask the release team and the
ftpmasters (informally, perhaps) whether the release team would
welcome a supportive TC intervention.

That would allow the TC to help settle this long-running question
(which keeps coming up on -devel and is frankly quite annoying).

This is true even though it seems the specific case of
libjs-handlebars has a more clear-cut problem, as found by Ansgar and
described in #830986.


Concretely, as one of the people who agree with the submitter of
#817092, I would like to see the TC pass a resolution along these
lines:

 The TC gives a non-binding statement of opinion:

 * The point of having the source code (with an appropriate licence
   etc.) is so that all our contributors, downstreams, and users are
   able to modify the code and to share their modifications with each
   other, with Debian, and with upstream.

 * In particular, Debian will often want to share modifications with
   upstream, which means that we need to be working with the software
   in a form which lets us do so.

 * For Debian, therefore, the source code for a file or program is the
   form which can be conveniently modified and shared; specifically,
   the form in which upstream will accept patches.

 * There may be exceptions to this principle but none of them apply in
   the case of libjs-handlebars.  We do not expect that any such
   exception would be applicable to other concatenated or
   `browserified' JavaScript files generated with tools like Grunt,
   even if the JavaScript output is not minified or obfuscated.

 * So in the case of bug #817092 against libjs-handlebars, the
   concatened JavaScript is not, in our opinion, source code.  This
   would remain true even if the parser-generator input mentioned in
   bug #830986 were available.


I think this would help save debian-devel a lot of annoying threads.

Ian.

Bug#831410: [linux-source-4.6] aufs patches need updating

[OmegaPhil]

Package: linux-source-4.6
Version: 4.6.3-1
Severity: normal

Attempting to build the aufs module from the 4.6 branch failed due to
some patch changes upstream (e.g. the first failure is due to the new
exposure of the update_time function):

https://github.com/sfjro/aufs4-standalone/commit/244642729f45fd79cb3b91874ff0c82b4cfba328

Please can you update the patches for the Debian kernel source.

Thanks


--- System information. ---
Architecture: amd64
Kernel:   Linux 4.5.0-2-amd64

Debian Release: stretch/sid
  990 testing 10.1.0.3   500 unstable10.1.0.3   500
testing-debug   debug.mirrors.debian.org   500 quodlibet-unstable
lazka.github.io 1 experimental10.1.0.3
--- Package information. ---
Depends   (Version) | Installed
===-+-===
binutils| 2.26.1-1
xz-utils| 5.1.1alpha+20120614-2.1


Recommends  (Version) | Installed
=-+-===
libc6-dev | 2.23-1
 OR libc-dev  | gcc   | 4:5.3.1-3
make  | 4.1-9
bc| 1.06.95-9+b1


Suggests(Version) | Installed
=-+-===
libncurses-dev|  OR ncurses-dev   |
libqt4-dev| 4:4.8.7+dfsg-8
pkg-config| 0.29-4



signature.asc
Description: OpenPGP digital signature

Bug#831407: nvidia-kernel-dkms: module FTBFS for kernels with the grsec patch

[Andreas Beckmann]

Package: nvidia-kernel-dkms
Severity: minor
Tags: help

Hi,

the nvidia kernel modules currently fail to build for the grsec kernels.

I don't know if there is much point in supporting this configuration -
effectively you have a security hardened kernel that gets tainted by
loading a proprietary kernel module.


Andreas

Bug#820794: related/same as 821801

[Christian Hilgers]

Dear all

I assume a fix for #821801 smbclient: Problems with smbclient since badlock 
update
will fix this issue too. As I get the same error message
as visible in #17 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821801#17

Christian
-- 
Christian Hilgers   ch...@familie-hilgers.com

Bug#823742: RFS: hdf-compass/0.6.0-1 [ITP]

[Mattia Rizzolo]

On Thu, Jul 07, 2016 at 12:34:10PM +0100, Ghislain Vaillant wrote:
> I have addressed Mattia's comments regarding the tests and manpage. I
> am now happy with the state of the package and believe it to be fit for
> upload.
> 
> The new version is available on mentors:
> 
> 
> https://mentors.debian.net/debian/pool/main/h/hdf-compass/hdf-compass_0.6.0-1.dsc

the git repository is not up to date, please push, I prefer doing stuff
over git for team maintained packages where git is used.
besides, the previous version was versioned 0.6.0b5-1 which is greater
than this one.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#831406: yorick: FTBFS: dpkg-shlibdeps: error: no dependency information found for /usr/lib/libmpich.so.12 (used by debian/yorick-mpy-mpich2/usr/lib/yorick/bin/mpy.mpich2)

[Chris Lamb]

Source: yorick
Version: 2.2.04+dfsg1-5
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

yorick fails to build from source in unstable/amd64:

  [..]

  "manual/yorick_prt.html"
  mkdir -p ../../build/doc/images
  cp -p images/*.* ../../build/doc//images/
  mkdir -p ../../build/doc/
  cp skull.css style.css ../../build/doc/
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160715182504.pdcokDfkyE.yorick/yorick-2.2.04+dfsg1/doc/html'
  cp doc/html/packinfo.txt build/00yorick.packinfo
  cp doc/html/keywords.txt build/00yorick.keywords
  cp doc/html/aliases.txt build/00yorick.aliases
  find build/doc/manual -name "*.html" -not -name yorick_prt.html | xargs sed 
-e 's|^http://dhmunro.github.io/yorick-doc/;>Web HomeGetting StartedManualPackagesQuick 
Reference|' -e 's||&|' -i
  sed 's|yorick_1.html|index.html|' -i build/doc/*.html build/doc/*/*.html
  touch build-indep-stamp
   fakeroot debian/rules binary
  dh_testdir
  xvfb-run relocate/bin/yorick -batch testfull.i
   Begin Yorick parser test...
   Test 17x10x10 binary operators...
   Test unary operators...
   Test array manipulation functions...
   Test struct instancing and indexing...
   Test range functions...
   Test math functions...
   Test informational functions...
   Test func declarations...
   Test binary I/O functions...
   Test binary I/O to netCDF...
   Test ASCII I/O functions...
   Test string manipulation functions...
   Test list functions...
   Test catch function...
  End of Yorick parser test, 0 goofs
   begin string manipulation test...
  end string manipulation test, 0 goofs
   PASSED oxy test1
   PASSED oxy test2
   PASSED oxy test3
   PASSED closure called with no arguments
   PASSED all closure tests
   PASSED alternate closure tests
   PASSED oxy friend test
   PASSED oxy sibling test
   
   Zeroth test is pdtest files:
   Testing sun_primitives db1 write...
   Testing dec_primitives db1 write...
   Testing cray_primitives db1 write...
   Testing mac_primitives db1 write...
   Testing macl_primitives db1 write...
   Testing pc_primitives db1 write...
   Testing sun3_primitives db1 write...
   Testing vax_primitives db1 write...
   Testing vaxg_primitives db1 write...
   Testing xdr_primitives db1 write...
   Testing sun_primitives db1 write w/PDB-style pointers...
   Testing dec_primitives db1 write w/PDB-style pointers...
   Testing cray_primitives db1 write w/PDB-style pointers...
   Testing native db1 write...
   
 First test is to write flat files:
   Write using native formats
   Write using DEC primitive formats
   Write using Sun primitive formats
   Write using Cray primitive formats
   
Second test is to write files with pointers:
   Write using native formats
   Write using DEC primitive formats
   Write using Sun primitive formats
   Write using Cray primitive formats
   
Third test is to update pointered files with flat data:
   Update using native formats
   Update using DEC primitive formats
   Update using Sun primitive formats
   Update using Cray primitive formats
   
Fourth test is exhaustive check of other primitive formats:
   Testing Sun format
   Testing i86 format
   Testing alpha format
   Testing sgi64 format
   Testing DEC format
   Testing Cray format
   Testing XDR format
   Testing Mac format
   Testing Mac long-double format
   Testing IBM PC format
   Testing VAX format
   Testing VAX G-double format
   Testing Sun-3/Sun-2 format
   Testing native format
 Timing Category CPU sec  System secWall sec
  Time to write/test all formats   0.004   0.000   0.007
   
Fifth test is check of Contents Log machinery:
   Contents Log -- testing Sun format
   Contents Log -- testing DEC format
   Contents Log -- testing Cray format
   Contents Log -- testing VAX format
   Contents Log -- testing native format
   Non-PDB Contents Log -- testing Sun format
   Non-PDB Contents Log -- testing DEC format
   Non-PDB Contents Log -- testing Cray format
   Non-PDB Contents Log -- testing VAX format
   Non-PDB Contents Log -- testing native format
   
Sixth test is flat history files (be patient):
   History -- testing Sun format
   History -- testing DEC format
   History -- testing Cray format
   History -- testing VAX format
   History -- testing native format
 Timing Category CPU sec  System secWall sec
 Time to write history files   0.060   0.000   0.063
   
Seventh test is a pointered history file:
   
Eighth test is vsave in-memory files:
   
Ninth test is vpack in-memory files:
   
  Shock tracker timing test:
 Timing Category CPU sec  System secWall sec
   Time per pass   0.002   0.000   0.002
  Total time   0.036   0.000   0.036
   
  Escape factor timing test:
  

Bug#830999: [pkg-bacula-devel] Bug#830999: bacula-director-mysql db-config installation fails with reference to ${db_name}

[Nish Aravamudan]

On 15.07.2016 [17:48:08 +0200], Carsten Leonhardt wrote:
> tags 830999 + confirmed patch
> thanks
> 
> Dear Nish,
> 
> > That seems very right to me, I will try and test it here too.
> >
> > update_mysql_tables.in
> > update_mysql_tables_10_to_11.in
> > update_mysql_tables_11_to_12.in
> >
> > may need similar changes (they did in 7.4.1+dfsg-1, and I haven't
> > rebased yet to check if they still apply).
> 
> I've committed a different fix to git now which doesn't need to touch
> all these files.

Great, thanks!

> > Also, depending on the source, you may want to ensure that
> > update_mysql_tables.in's db_name assignemnt properly uses the
> > ${db_name:-@db_name@} so that environment variables can be used with it.
> 
> You mean for people not using dbconfig-common?

Yeah, iirc, the scripts end up living in /usr/share/bacula-director/ and
are sometimes referenced online as a way to manually do migrations, etc.

I believe upstream has made the referenced changed already, in a bugfix:
http://www.bacula.org/git/cgit.cgi/bacula/commit/?h=Branch-7.4=074419ac0c9dbbde2e4d2f5ccb6d4ca85c6ec8a9

Bug#831405: xserver-xorg-video-openchrome: please make the build reproducible

[Chris Lamb]

Source: xserver-xorg-video-openchrome
Version: 1:0.3.3+git20160310-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed
that xserver-xorg-video-openchrome could not be built reproducibly.

Patch attached. Please send it upstream if possible.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/src/Makefile.am   2016-07-15 17:56:15.066700891 +0200
--- b/src/Makefile.am   2016-07-15 18:22:08.362042386 +0200
@@ -113,6 +113,9 @@
 if [ -d .svn ]; then \
echo '#define BUILDCOMMENT "(development build, at revision '\
"`svnversion -nc .. | sed -e s/^[^:]*://`"')"' > 
$@.tmp; \
+elif [ "$$SOURCE_DATE_EPOCH" ]; then \
+   printf '#define BUILDCOMMENT "(compiled with SOURCE_DATE_EPOCH: 
%s)"' $$SOURCE_DATE_EPOCH \
+   > $@.tmp; \
 else \
date +'#define BUILDCOMMENT "(development build, compiled on 
%c)"' \
> $@.tmp; \

Bug#831404: yersinia: please make the build reproducible

[Chris Lamb]

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

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed
that yersinia could not be built reproducibly.

Patch attached. Please send it upstream if possible.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible_build.patch   1970-01-01 02:00:00.0 
+0200
--- b/debian/patches/reproducible_build.patch   2016-07-15 18:13:23.933606372 
+0200
@@ -0,0 +1,19 @@
+Author: Chris Lamb 
+Last-Update: 2016-07-15
+
+--- yersinia-0.7.3.orig/configure.in
 yersinia-0.7.3/configure.in
+@@ -839,6 +839,13 @@ info_kern="`uname -s`"
+ info_kern_ver="`uname -r`"
+ info_platform="`uname -m`"
+ 
++if test -n "$SOURCE_DATE_EPOCH"; then
++  info_date="`LC_ALL=C date --utc --date=@$SOURCE_DATE_EPOCH '+%a 
%d-%b-%Y %H:%M'`"
++  info_kern="`lsb_release --short --id`"
++  info_kern_ver="`lsb_release --short --id`"
++  info_platform="`uname --short --id`"
++fi
++
+ AC_DEFINE_UNQUOTED(INFO_KERN, "$info_kern")
+ AC_DEFINE_UNQUOTED(INFO_KERN_VER, "$info_kern_ver")
+ AC_DEFINE_UNQUOTED(INFO_PLATFORM, "$info_platform")
--- a/debian/patches/series 1970-01-01 02:00:00.0 +0200
--- b/debian/patches/series 2016-07-15 18:13:12.665242744 +0200
@@ -0,0 +1 @@
+reproducible_build.patch

Bug#831403: xmlgraphics-commons: FTBFS: Could not initialize class org.mockito.Mockito

[Chris Lamb]

Source: xmlgraphics-commons
Version: 2.1-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

xmlgraphics-commons fails to build from source in unstable/amd64:

  [..]

  [junit] 
  [junit] - Standard Output ---
  [junit] Skipping endianness test for ImageIO-based TIFF writer because 
JAI ImageIO Tools is not available!
  [junit] Skipping endianness test for ImageIO-based TIFF writer because 
JAI ImageIO Tools is not available!
  [junit] -  ---
  [junit] Testsuite: 
org.apache.xmlgraphics.io.TempResourceURIGeneratorTestCase
  [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.071 sec
  [junit] 
  [junit] Testsuite: org.apache.xmlgraphics.io.URIResolverAdapterTestCase
  [junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 
0.087 sec
  [junit] 
  [junit] Testcase: 
testCatalogResolver(org.apache.xmlgraphics.io.URIResolverAdapterTestCase):SKIPPED:
 Literally no idea why this doesn't work... Gonna look at the catalog resolver 
source
  [junit] Testcase: 
testCatalogResolverInAdapter(org.apache.xmlgraphics.io.URIResolverAdapterTestCase):SKIPPED:
 Literally no idea why this doesn't work... Gonna look at the catalog resolver 
source
  [junit] Testsuite: org.apache.xmlgraphics.io.XmlSourceUtilTestCase
  [junit] Tests run: 14, Failures: 0, Errors: 14, Skipped: 0, Time elapsed: 
0.113 sec
  [junit] 
  [junit] Testcase: 
testCloseQuietlyStreamSource(org.apache.xmlgraphics.io.XmlSourceUtilTestCase):  
Caused an ERROR
  [junit] net/sf/cglib/proxy/Callback
  [junit] java.lang.NoClassDefFoundError: net/sf/cglib/proxy/Callback
  [junit]   at java.lang.Class.forName0(Native Method)
  [junit]   at java.lang.Class.forName(Class.java:264)
  [junit]   at 
org.mockito.internal.configuration.plugins.PluginLoader.loadPlugin(PluginLoader.java:33)
  [junit]   at 
org.mockito.internal.configuration.plugins.PluginRegistry.(PluginRegistry.java:13)
  [junit]   at 
org.mockito.internal.configuration.plugins.Plugins.(Plugins.java:11)
  [junit]   at org.mockito.internal.util.MockUtil.(MockUtil.java:24)
  [junit]   at org.mockito.internal.MockitoCore.(MockitoCore.java:44)
  [junit]   at org.mockito.Mockito.(Mockito.java:975)
  [junit]   at 
org.apache.xmlgraphics.io.XmlSourceUtilTestCase.setUp(XmlSourceUtilTestCase.java:71)
  [junit] Caused by: java.lang.ClassNotFoundException: 
net.sf.cglib.proxy.Callback
  [junit]   at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
  [junit]   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
  [junit]   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
  [junit]   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
  [junit] 
  [junit] 
  [junit] Testcase: 
testNeedInputStreamFailureCaseStreamImage(org.apache.xmlgraphics.io.XmlSourceUtilTestCase):
 Caused an ERROR
  [junit] Could not initialize class org.mockito.Mockito
  [junit] java.lang.NoClassDefFoundError: Could not initialize class 
org.mockito.Mockito
  [junit]   at 
org.apache.xmlgraphics.io.XmlSourceUtilTestCase.setUp(XmlSourceUtilTestCase.java:71)
  [junit] 
  [junit] 
  [junit] Testcase: 
testHasInputStream(org.apache.xmlgraphics.io.XmlSourceUtilTestCase):Caused 
an ERROR
  [junit] Could not initialize class org.mockito.Mockito
  [junit] java.lang.NoClassDefFoundError: Could not initialize class 
org.mockito.Mockito
  [junit]   at 
org.apache.xmlgraphics.io.XmlSourceUtilTestCase.setUp(XmlSourceUtilTestCase.java:71)
  [junit] 
  [junit] 
  [junit] Testcase: 
testCloseQuietlyImageSource(org.apache.xmlgraphics.io.XmlSourceUtilTestCase):   
Caused an ERROR
  [junit] Could not initialize class org.mockito.Mockito
  [junit] java.lang.NoClassDefFoundError: Could not initialize class 
org.mockito.Mockito
  [junit]   at 
org.apache.xmlgraphics.io.XmlSourceUtilTestCase.setUp(XmlSourceUtilTestCase.java:71)
  [junit] 
  [junit] 
  [junit] Testcase: 
testCloseQuietlySaxSource(org.apache.xmlgraphics.io.XmlSourceUtilTestCase): 
Caused an ERROR
  [junit] Could not initialize class org.mockito.Mockito
  [junit] java.lang.NoClassDefFoundError: Could not initialize class 
org.mockito.Mockito
  [junit]   at 
org.apache.xmlgraphics.io.XmlSourceUtilTestCase.setUp(XmlSourceUtilTestCase.java:71)
  [junit] 
  [junit] 
  [junit] Testcase: 
testNeedInputStreamFailureCaseSAXSource(org.apache.xmlgraphics.io.XmlSourceUtilTestCase):
   Caused an ERROR
  [junit] Could not initialize class org.mockito.Mockito
  [junit] java.lang.NoClassDefFoundError: Could not initialize class 
org.mockito.Mockito
  [junit]   at 

Bug#794650: pulseaudio: please ship the pulseaudio equalizer UI (qpaeq)

[Felipe Sateler]

On 15 July 2016 at 08:56, Willem Mulder <14mrh4...@gmail.com> wrote:
> On Mon, 4 Jul 2016 11:08:17 -0300 Felipe Sateler 
> wrote:
>> On 4 July 2016 at 09:56, Yuri D'Elia  wrote:
>> > Package: pulseaudio
>> > Version: 9.0-1
>> > Followup-For: Bug #794650
>> >
>> > I would second having a separate pulseaudio-qpaeq, as well as moving the
>> > actual
>> > plugin (so) to this package.
>> >
>> > Having the equalizer plugin without having the interface to control
> it is
>> > completely useless.
>>
>> Agreed. But I have not had time to do this. Patches welcome ;)
>
> I was slightly annoyed about this, so I decided to create a patch :)

Thanks! :)

> I based the patch on the package's git repo. I'd also like some feedback
> on it, since this is the first time I actually did something like this.

The patch looks good, but there are some questions that need to be
resolved first:

1. Is the equalizer sink useful without qpaeq?
2. Do users actually want the module, or the equalizer?

As I understand it, the answer to 1 is: not at the moment, qpaeq is
the only available client; this makes the answer to 2 "no". Therefore,
I think the new package should be called qpaeq, and describe the
equalizer application.

Other than that, it looks good. The only unfortunate thing is that it
won't work by default as the dbus module is not loaded in the default
configuration. But fixing this would mean patching upstream code,
which is more work (and I don't think it should block actually
shipping the app).

Did you test that the (python) dependencies you added are enough to
run the app? Ie, install on a clean system/chroot and that it starts?

-- 

Saludos,
Felipe Sateler

Bug#753410: ITP: node-chalk -- Terminal string styling

[Ross Gammon]

Hi Mathias,

On 15/07/16 16:44, Mathias Behrle wrote:

Hi Ross,

I just took over the RFPs for node-nomnom and node-supports-color, node-nomnom
being a dependency for node-po2json/tryton-sao.

As you stated on [1] you are currently busy. So may I ask if you already made
some progress on the packaging of node-chalk?

Regards,

Mathias

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774567


Excellent news! It is always good when a node package ends up being 
needed by something else and the workload gets shared ;.)


I can't remember exactly why I was stalled on node-chalk. It may have 
been that it turned out to have a lot more dependencies than expected. 
Even if that was the case, the packaging was probably left in the 
Javacript Team git repo by Bas for easy resurrection.


Feel free to take ownership of this ITP, and push it forward. There is 
no shortage of other node packages that I can start on when I next get a 
free slot.


Regards,

Ross

Bug#831391: [Pkg-ime-devel] Bug#831391: U+2601 CLOUD 反而像電信桿而非雲

[積丹尼 Dan Jacobson]

$ fc-match Sans -s
wqy-zenhei.ttc: "文泉驛正黑" "Regular"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
luxisr.ttf: "Luxi Sans" "Regular"
n019003l.pfb: "Nimbus Sans L" "Regular"
wenquanyi_10pt.pcf: "WenQuanYi Bitmap Song" "Regular"
wenquanyi_9pt.pcf: "WenQuanYi Bitmap Song" "Regular"
wenquanyi_13px.pcf: "WenQuanYi Bitmap Song" "Regular"
FreeSans.ttf: "FreeSans" "нормален"
FreeSansBold.ttf: "FreeSans" "получерен"
unifont.ttf: "Unifont" "Medium"
unifont_csur.ttf: "Unifont CSUR" "Medium"
unifont_upper.ttf: "Unifont Upper" "Medium"
unifont_upper_csur.ttf: "Unifont Upper CSUR" "Medium"
wqy-zenhei.ttc: "文泉驛等寬正黑" "Regular"
luximr.ttf: "Luxi Mono" "Regular"
ukai.ttc: "AR PL UKai CN" "Book"
ukai.ttc: "AR PL UKai HK" "Book"
s05l.pfb: "Standard Symbols L" "Regular"
uming.ttc: "AR PL UMing CN" "Light"
LiberationSerif-Italic.ttf: "Liberation Serif" "Italic"