Bug#845348: What is going on with gtkdatabox?

[Petter Reinholdtsen]

[Andreas Tille]
>> xoscope: build-depends on libgtkdatabox-0.9.2-0-dev explicitly

I'll take care of this one, if the maintainer do not fix it quickly.  I
just submitted a patch to BTS solving the build problem by changing
libgtkdatabox-0.9.2-0-dev go libgtkdatabox-dev.

Thank you for the warning.  I had not noticed the versioned build
dependency in xoscope.

-- 
Happy hacking
Petter Reinholdtsen

Bug#845500: nftables: notrack target fails with No such file or directory

[Arturo Borrero Gonzalez]

On 24 November 2016 at 01:34, Peter Colberg  wrote:
>
> While the nftables package in Debian stretch will support notrack, the
> corresponding kernel support was committed after the 4.9 merge window:
>
> https://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/commit/net/netfilter/nft_ct.c?id=254432613c588640f8b8b5c3641a3c27bbe14688
>
> Assuming 4.9 becomes the stretch kernel, could you backport the patch?


Debian stretch will include linux 4.10 [0], so no problem.


[0] https://lists.debian.org/debian-devel-announce/2016/03/msg0.html

Bug#845349: xoscope build-depends on obsolete package libgtkdatabox-0.9.2-0-dev

[Petter Reinholdtsen]

Control: tags -1 + patch

[Peter green]
> xoscope build-depends on libgtkdatabox-0.9.2-0-dev which is no longer built
> by source package libgtkdatabox

The following patch solve the build problem.  Unless the maintainer expresses
a wish to do this upload himself, I plan to upload a NMU to fix it.  A new
upload should also, according to the xoscope developer, make xoscope use
the dotted grids feature in libgtkdatabox.  This new feature is the background
for the request for the new libgtkdatabox upload.

diff --git a/debian/control b/debian/control
index b66ca4c..5b963fc 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Build-Depends:
  quilt,
  libcomedi-dev [!hurd-any],
  libfftw3-dev,
- libgtkdatabox-0.9.2-0-dev
+ libgtkdatabox-dev
 Standards-Version: 3.9.8
 Homepage: http://xoscope.sourceforge.net/
 
-- 
Happy hacking
Petter Reinholdtsen

Bug#838887: please dont bomb out on nofail option

[Michael Biebl]

On Mon, 26 Sep 2016 07:02:01 +0200 Marc Haber
 wrote:
> Package: initramfs-tools
> Severity: wishlist
> 
> Hi,
> 
> when I looked for the last time (a few months ago), fstab entries
> parsed by initramfs-tools or in initramfs MUST NOT contain the
> "nofail" option. This is kind of surprising since some other fstab
> entries MUST contain the "nofail" option to avoid systemd from bombing
> out on boot.
> 
> This inconsistence makey it necessary to think in which lines to put
> the nofail option and in which lines not.
> 
> Please consider tweaking initramfs-tools so that "nofail" can be in
> all lines, with it being ignored in initramfs.

This looks like a duplicate of #845302.

In this bug report a user had the "auto" option for /usr in /etc/fstab.
The busybox and klibc-utils mount implementations did not cope with this
and failed to mount /usr as a result

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845302#161 I have a
proposed patch which uses the mount implmentation from util-linux, which
is also used on the real system.

This should avoid issues like Mark or the bug reporter from  #845302 are
encountering.




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#845488: ITP: linux-firmware-raspi3 -- Raspberry Pi 3 GPU firmware and bootloaders

[Michael Stapelberg]

Thanks for the hint. I am following that effort already, but AIUI it’s not
in good enough shape yet to be able to actually boot Linux. Hopefully it
will get there eventually :).

On Thu, Nov 24, 2016 at 6:47 AM, Paul Wise  wrote:

> On Thu, Nov 24, 2016 at 5:37 AM, Michael Stapelberg wrote:
>
> >  This package contains all the proprietary files necessary to boot a
> >  Raspberry Pi 3 board.
>
> You may eventually want to look at the open source RPi firmware:
>
> https://github.com/christinaa/rpi-open-firmware
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>



-- 
Best regards,
Michael

Bug#845090: [Pkg-alsa-devel] Bug#845090: /usr/bin/alsamixer: alsamixer -c0 starts pulseaudio

[Elimar Riesebieter]

Control: tags -1 unreproducible

* Juha Jäykkä  [2016-11-20 18:15 +]:

> > alsamixer doesn't fire up any puls daemon. Please check whether
> > puls is running before starting alsamixer.
> 
> It should not, but it certainly does:
> 
> juhaj@meissa 18:07:16 ~> ps -flyu juhaj|grep pulseau
> S juhaj 9740  9724  0  99  19  2204  3488 -  18:07 pts/400:00:00 
> grep pulseau
> Today is 20.11.2016, I am running on tty 4 and currently controlling 0 jobs
> juhaj@meissa 18:07:31 ~> alsamixer -c0
> /usr/bin/pulseaudio: line 3: /var/log/mpd/mpd.runs.pulseaudio.at: Permission 
> denied
> W: [pulseaudio.real] main.c: /proc/self/exe does not point to /usr/bin/
> pulseaudio, cannot self execute. Are you playing games?
> Today is 20.11.2016, I am running on tty 4 and currently controlling 0 jobs
> juhaj@meissa 18:07:39 ~> ps -flyu juhaj|grep pulseau
> S juhaj 9746 1  7  69 -11 10840 166267 - 18:07 ?00:00:00 /
> usr/bin/pulseaudio.real --start --log-target=syslog
> S juhaj 9752  9746  0  80   0  5336 30992 -  18:07 ?00:00:00 /
> usr/lib/pulseaudio/pulse/gconf-helper
> S juhaj 9756  9724  0  99  19  2160  3488 -  18:07 pts/400:00:00 
> grep pulseau
> Today is 20.11.2016, I am running on tty 4 and currently controlling 0 jobs
> juhaj@meissa 18:07:40 ~> 

What do you want to tell me here? It seems your pulseaudio
installation is a bit buggy. I can't reproduce.

> I do not think this behaviour is correct. The user juhaj is pristine, and 
> default.pa comes from the deb, except I've added

default.pa comes from pulseaudio or xrdp package. There is no
instruction to start pulse in any alsa package.

> load-module module-alsa-sink device=dmix:CARD=AudioPCI,DEV=1
> 
> just before 
> 
> .ifexists module-udev-detect.so
> load-module module-udev-detect
> .else
> ### Use the static hardware detection module (for systems that lack udev 
> support)
> load-module module-detect
> .endif
> 
> > BTW: do you have more then one soundcard installed? If not just run
> > alsamixer without any option.
> 
> Your guess is correct. A total of three soundcards, although only two are 
> relevant here: the third one is a webcam which only has a microphone, no 
> speakers.
> 
> Now that you mention it, while alsamixer -c1 and alsamixer -c2 also start 
> pulseaudio, only alsamixer -c0 causes any volumes to change.
> 
> Which makes me wonder perhaps 
> 
> load-module module-alsa-sink device=dmix:CARD=AudioPCI,DEV=1
> 
> has something to do with the changing of the mute setting. Having said that, 
> I 
> don't really mind if pulseaudio gets started as long as it does not screw up 
> the mixer settings in the process: I can always configure other software to 
> use alsa explicitly if I need to.
> 
> So I still think the problem is that pulseaudio gets started in the first 
> place.

It seems that pulse is fired up by mpd?

Elimar
-- 
  355/113: Not the famous irrational number pi,
   but an incredible simulation!
-unknown

Bug#842859: network-manager patches

[Michael Biebl]

Hi

Am 24.11.2016 um 08:12 schrieb Andrew Shadura:
> Could you please cherry-pick upstream NM commits
> 3cc06c3db679c1ff2f61a301396393300d36adbb and
> d0c01cc79daf62b83e52eea4d6302ddc42f1f5f0? I have applied them in a local
> build, and they fix my networking issues and I suppose they may fix
> #842859 which may or may not be the same bug.

I would prefer, if those patches were cherry-picked into the nm-1-4 branch.
Andrew, could you poke upstream about this.

Ian, since Andrew was mentioning #842859, would you mind testing those
patches and see if they fix the issue you are seeing.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#845348: What is going on with gtkdatabox?

[Andreas Tille]

Hi Peter,

On Thu, Nov 24, 2016 at 02:49:56AM +, peter green wrote:
> As a derivative maintainer I noticed that there appears to be a gtkdatabox
> transition going on. Looking at the list archives for debian-release I see
> no mention of it on there.

That might have been a race condition since the package was uploaded
long before transition freeze and was hanging some time in the new
queue.
 
> Specifically it seems that the libgtkdatabox source package has renamed
> every binary package it generates.
> 
> libgtkdatabox-0.9.2-0 -> libgtkdatabox-0.9.3-0
> libgtkdatabox-0.9.2-0-glade -> libgtkdatabox-0.9.3-0-glade
> libgtkdatabox-0.9.2-0-libglade -> libgtkdatabox-0.9.3-0-libglade
> libgtkdatabox-0.9.2-0-dev -> libgtkdatabox-dev
> libgtkdatabox-0.9.2-0-doc -> libgtkdatabox-doc
> 
> I see at least the following reverse depdencies that will need sourceful
> changes.
> 
> brp-pacu: has a build-dependency on libgtkdatabox-0.9.2-0-dev |
> libgtkdatabox-dev . Unfortunately buildds only look at the first option and
> even if they did they have no way of telling if a package is cruft or not.
> gtkdataboxmm: build-depends on libgtkdatabox-0.9.2-0-dev explicitly
> xoscope: build-depends on libgtkdatabox-0.9.2-0-dev explicitly

I admit that I missed brp-pacu as dependency.  The migration to
libgtkdatabox-0.9.3 was explicitly requested for xoscope 
 
> I have filed bug reports for gtkdataboxmm and xoscope, for which I have
> received no matainer response. I have not yet filed one for brp-pacu.

I'll checkout gtkdataboxmm myself since I was once sponsering this - no
idea whether Daniele remains active on this package.
 
Kind regards

 Andreas.
 

-- 
http://fam-tille.de

Bug#844501: [Pkg-alsa-devel] Bug#844501: alsa-firmware-loaders: udev rule causes race condition which blocks us-122 initialisation (with fix!)

[Elimar Riesebieter]

Control: severity -1 normal

The package isn't unusable for always most users.

* Jaime T  [2016-11-16 13:34 +]:

> On 16 November 2016 at 10:50, jaimet  wrote:
> > My udev-fu is very weak, but after stumbling around with "udevadm
> > monitor" for a bit, I replaced that udev rule line with:
> >
> > SUBSYSTEM=="sound", ACTION=="add", KERNEL=="hwC2D0", 
> > RUN+="/lib/udev/tascam_fpga"
> 
> It now appears that my udev-fu is even weaker than I thought: "hwC2D0"
> is obviously an "arbitrary-card-ordering-dependent" reference which
> breaks if my sound cards are discovered in a different order. A much
> better alternative (that is *not* order-dependent) is:
> 
> SUBSYSTEM=="sound", ACTION=="add", ATTR{id}=="USX2Y",
> RUN+="/lib/udev/tascam_fpga"
> 
> Apologies for the noise. J :-)

So should we close this bug?

Elimar
-- 
  Experience is something you don't get until
  just after you need it!

Bug#845495: src:python-tz: Non-maintainer upload of python-tz/2016.7-0.1 to DELAYED/5

[Arnaud Fontaine]

Hello,

Thanks for taking care of this.

> diff --git a/debian/python-tz.install b/debian/python-tz.install
> new file mode 100644
> index 000..dbdb301
> --- /dev/null
> +++ b/debian/python-tz.install
> @@ -0,0 +1 @@
> +/usr/lib/python2*
> diff --git a/debian/python3-tz.install b/debian/python3-tz.install
> new file mode 100644
> index 000..fef6392
> --- /dev/null
> +++ b/debian/python3-tz.install
> @@ -0,0 +1 @@
> +/usr/lib/python3*
> diff --git a/debian/rules b/debian/rules
> index 399f7d5..f1d5e38 100755
> --- a/debian/rules
> +++ b/debian/rules
>  override_dh_install:
> - dh_install
> + dh_install --fail-missing

Files  will  be automatically  copied  by  pybuild  if you  add  'export
PYBUILD_NAME=tz' to debian/rules, so  you don't need the dh_auto_install
override, nor the *.install files. See the following link:
  https://wiki.debian.org/Python/LibraryStyleGuide#debian.2Frules

> --- a/debian/rules
> +++ b/debian/rules
> [...]
> -override_dh_auto_test:
> - python -m unittest discover -v pytz/tests
> - for python in $(PY3VERS); do \
> - $$python -m unittest discover -v pytz/tests; \
> - done
> -

I tested this and it seems that no tests are being ran:

 dh_auto_test -O--buildsystem=pybuild -O--test-pytest
  I: pybuild base:184: cd /tmp/pytz-2016.7/.pybuild/pythonX.Y_2.7/build; 
python2.7 -m unittest discover -v 
  
  --
  Ran 0 tests in 0.000s
  
  OK
  I: pybuild base:184: cd /tmp/pytz-2016.7/.pybuild/pythonX.Y_3.5/build; 
python3.5 -m unittest discover -v 
  
  --
  Ran 0 tests in 0.000s
  
  OK

Here are  the 2  ways I  know to run  Unit Tests  at build  time (source
package of 2015.7 uses debian/test-pytz):

  * Use python-pytest:
+ Add to debian/rules:
  export PYBUILD_TEST_PYTEST=1
  export PYBUILD_TEST_ARGS=--doctest-modules
+ Add Build-Depends against python-pytest and python3-pytest.
+ Remove override_dh_auto_install and debian/test-pytz as they are
  not needed anymore.

  * Or, copy debian/test-pytz before running tests (PYBUILD_BEFORE_TEST)
and  override  dh_auto_test. Not  sure  if  there  is a  better  way
though...

Cheers,
-- 
Arnaud Fontaine


signature.asc
Description: PGP signature

Bug#840080: please make flex useful for cross building again

[Helmut Grohne]

Control: tags -1 + pending

Hi Manoj,

On Sat, Oct 08, 2016 at 06:58:16AM +0200, Helmut Grohne wrote:
> Can we please find a solution to this as it breaks very many packages
> close to the base system?

Given your unexpected silence on this matter, I have NMUed flex to
DELAYED/10 with the attached patch. It implements the solution that you
preferred in our previous discussion. I'll also carry out the MBF you
announced[1] and revalidated 270 packages, of which about 50 need an
additional dependency.

If any of this does not fit with you, please speak up soon so we can
cancel the upload.

Helmut

[1] https://lists.debian.org/debian-devel/2016/03/msg00162.html
diff -u flex-2.6.1/debian/NEWS.Debian flex-2.6.1/debian/NEWS.Debian
--- flex-2.6.1/debian/NEWS.Debian
+++ flex-2.6.1/debian/NEWS.Debian
@@ -1,3 +1,13 @@
+flex (2.6.1-1.1) UNRELEASED; urgency=medium
+
+   In this upload, the flex package drops its dependency on libfl-dev, because
+   it is impossible to forward the correct architecture constraint. It contains
+   the FlexLexer.h header and is thus required for using the FlexLexer C++
+   interface. Packages using this library need to add libfl-dev to their
+   Build-Depends.
+
+ -- Helmut Grohne   Wed, 23 Nov 2016 13:18:32 +0100
+
 flex (2.5.33-7) unstable; urgency=low
 
This version of Flex is a major upgrade from previous versions. There
diff -u flex-2.6.1/debian/changelog flex-2.6.1/debian/changelog
--- flex-2.6.1/debian/changelog
+++ flex-2.6.1/debian/changelog
@@ -1,3 +1,12 @@
+flex (2.6.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Demote flex dependency on libfl-dev to Recommends.
+  * Have libfl-dev depend on flex to enforce the same-version constraint.
+  * Annotate flex Multi-Arch: foreign again (Closes: #840080).
+
+ -- Helmut Grohne   Thu, 24 Nov 2016 07:34:27 +0100
+
 flex (2.6.1-1) unstable; urgency=low
 
   * New upstream version. The development of flex ias transitionaing to
diff -u flex-2.6.1/debian/control flex-2.6.1/debian/control
--- flex-2.6.1/debian/control
+++ flex-2.6.1/debian/control
@@ -14,10 +14,11 @@
 Package: flex
 Architecture: any
 Pre-Depends: debconf | debconf-2.0
-Depends: ${shlibs:Depends}, m4, libfl-dev (= ${binary:Version}),
+Depends: ${shlibs:Depends}, m4,
  dpkg (>= 1.15.4) |  install-info, ${misc:Depends}
-Recommends: gcc | c-compiler
+Recommends: gcc | c-compiler, libfl-dev
 Suggests: bison, build-essential
+Multi-Arch: foreign
 Description: fast lexical analyzer generator
  Flex is a tool for generating scanners: programs which recognized lexical
  patterns in text. It reads the given input files for a description of a
@@ -48,7 +49,7 @@
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Depends: ${misc:Depends}, ${shlibs:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}, flex (= ${binary:Version})
 Replaces: flex (<< 2.5.39), flex-old (<= 2.5.4a-10)
 Breaks: flex (<< 2.5.39), flex-old (<= 2.5.4a-10)
 Description: static library for flex (a fast lexical analyzer generator)

Bug#845281: mediawiki: backport version does not play well with extensions

[duck]

Quack,

On 2016-11-24 14:41, Kunal Mehta wrote:


This is somewhat intentional as the new package only contains some of
those packages (those that are shipped by upstream as part of the
tarball), while the mediawiki-extensions-base package was a somewhat
arbitrary list of extensions.


I understand, but when I saw the APT proposal, I quickly said NO to 
avoid breakage, but still had no clue what to do.



The package already has provides for those three packages (base, geshi,
and confirmedit), but I think it will still need to break
mediawiki-extensions since none of the extensions in that package are
compatible with the newer version and not all of them are provided by
the new package. I also have no plans on updating the
mediawiki-extensions-* packages. So I'm not sure really what other 
steps

can be taken...


Which package has these provides? mediawiki does not, 
mediawiki-extensions does not either, I just checked again.


IMHO, removing the mediawiki-extensions package & co in unstable, with a 
NEWS.Debian explaining the situation in the mediawiki package, is fine 
for the next release. The user can review its extensions, packaged or 
not; it is part of the machine's planned upgrade to switch release, so 
no big issue here.


As for bpo, this is much different. bpo are here to provide a 
convenience upgrade for some specific package, but is not meant to be a 
major disruption. If you leave the users without any upgrade path, then 
this is not nice. As you do not plan to support packaged extensions, 
then probably you should not have proposed a backport in the first 
place. In this case, to avoid surprise, I think using debconf and 
cancelling install in preinst would be better.


You may also ask for more advice on mailing-lists.

Hope this was helpful.
Regards.
\_o<

--
Marc Dequènes

Bug#845516: xtables-addons-common: libxtables11 outdated dependancy

[Nikolai Lusan]

Package: xtables-addons-common
Version: 2.11-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   A regular update include an upgrade of iptables - with an upgrade to 
libxtables12
   xtables-addons-common depends on libxtables11
   libxtables11 breaks libxtables12
   
   All the xtables-addons package had to be removed, they are unusable until 
the dependancy on libxtables11 is upgraded to libxtables12


-- 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/6 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#845505: sra-sdk 2.7.0-1 is broken libncbi-vdb2 2.8.0+dfsg-1

[Andreas Tille]

Hi Charles,

On Thu, Nov 24, 2016 at 01:38:11PM +0900, Charles Plessy wrote:
> Package: sra-sdk
> Severity: grave
> 
> Hi all,
> 
> quick note from work; sorry to not being able to go deeper.
> 
> A colleague has reported to me that sra-sdk 2.7.0-1 is broken
> libncbi-vdb2 2.8.0+dfsg-1.  For instance:
> 
> fastq-dump
> fastq-dump: symbol lookup error:
> /usr/lib/x86_64-linux-gnu/libncbi-vdb.so.2: undefined symbol:
> mbedtls_ctr_drbg_seed
> 
> Downgrading libncbi-vdb2 to 2.7.0+dfsg-4~bpo8+1.
> 
> There are no build logs for sra-sdk on amd64, but I guess that sra-sdk
> 2.7.0-1 could have been built against 2.7.0+dfsg-4 by mistake (given
> that they have been uploaded on the same day, I assume that they were
> intended to be used together).  Note that now, with source-only uploads,
> it is easier to get build logs.
> 
> If we are lucky, maybe a binNMU will be enough ?  On the other hand,
> maybe the only way to prevent problems for the users upgrading form
> Testing would be to tighten the dependency.

I tried hard to get sra-sdk 2.8.0 packaged - but as always this is quite
a time draining job since with every release upstream changes the build
system.  I would really appreciate any help to get sra-sdk 2.8.0 out
since this might be the more sustainable solution that fiddling around
with the old version.

Any volunteers?

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#845515: please update node-rimraf to latest upstream version

[Pirate Praveen]

package: node-rimraf
version: 2.2.8-1
severity: wishlist

with current version node-y18n tests fail, once rimraf is updated, we
can enable node-y18n tests. Also many other libs would benefit from a
recent version.



signature.asc
Description: OpenPGP digital signature

Bug#845413: fixed in 0.6+snapshot20161117-2

[Håvard Moen]

I see this is fixed in the just uploaded 0.6+snapshot20161117-2

-- 
Håvard

Bug#845514: ITP: node-get-stream -- Get a stream as a string, buffer, or array

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-npm-run-path
  Version : 2.0.2
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/npm-run-path#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Get your PATH prepended with locally installed binaries



signature.asc
Description: OpenPGP digital signature

Bug#845511: patch should tell/share some examples of how it could be used

[shirish शिरीष]

Package: patch
Version: 2.7.5-1
Severity: normal

Dear Maintainer,
Patch has no examples. It would be nice if it included at least two
examples, for e.g. -

Inside a debian source package with a patch to make a new binary debian package

$ patch -p1 < ../$some.patch

Simiarly if there a a debdiff, it is the same thing as patch -

$ patch -p1 < ../$some.debdiff

So at least people would have some idea of how to use it.

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

Kernel: Linux 4.8.0-1-amd64 (SMP w/2 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 patch depends on:
ii  libc6  2.24-5

patch recommends no packages.

Versions of packages patch suggests:
pn  diffutils-doc  
ii  ed 1.10-2.1

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#845513: ITP: node-npm-run-path -- Get your PATH prepended with locally installed binaries

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-npm-run-path
  Version : 2.0.2
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/npm-run-path#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Get your PATH prepended with locally installed binaries



signature.asc
Description: OpenPGP digital signature

Bug#845512: FTBFS: failing tests on various architectures: FAIL: elf/tst-prelink-cmp

[Michael Biebl]

Source: glibc
Version: 2.24-6
Severity: serious

glibc FTBFS on various architectures with
FAIL: elf/tst-prelink-cmp

Full builds log at https://buildd.debian.org/status/package.php?p=glibc


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

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

Bug#808517: ruby-rails-autolink: FTBFS: uninitialized constant ActionDispatch::Assertions::DomAssertions (NameError)

[Pirate Praveen]

On Sun, 20 Dec 2015 15:29:18 + "Chris West (Faux)"
 wrote:
> 
> Dear Maintainer,
> 
> The package fails to build:

This was packaged as a dependency of diaspora, but it no longer depends
on it. I have uploaded a new version of diaspora which does not declare
a dependency on ruby-rails-autolink, once that enters testing, we can
remove ruby-rails-autolink.



signature.asc
Description: OpenPGP digital signature

Bug#845510: debdelta: Can't check signature: No public key while getting debdelta sources

[shirish शिरीष]

Package: debdelta
Version: 0.55
Severity: normal

Dear Maintainer,
There is no public key when downloading debdelta sources. While
downloading the sources see this warning message -

┌─[shirish@debian] - [~/games] - [6413]
└─[$] apt-get source debdelta

[Reading package lists... Done
NOTICE: 'debdelta' packaging is maintained in the 'Git' version
control system at:
git://anonscm.debian.org/collab-maint/debdelta.git
Please use:
git clone git://anonscm.debian.org/collab-maint/debdelta.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 290 kB of source archives.
Get:1 http://mirror.kku.ac.th/debian testing/main debdelta 0.55 (dsc) [891 B]
Get:2 http://mirror.kku.ac.th/debian testing/main debdelta 0.55 (tar) [289 kB]
Fetched 290 kB in 49s (5,906 B/s)
gpgv: Signature made Sun 30 Nov 2014 11:01:30 PM IST
gpgv:using DSA key F41FED8E33FC40A4
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./debdelta_0.55.dsc
dpkg-source: info: extracting debdelta in debdelta-0.55
dpkg-source: info: unpacking debdelta_0.55.tar.gz

Can you fix the above warning please otherwise there could be trust issues.

Look forward to your reply.

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


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#823029: a patch

[Adam Borowski]

Control: tags -1 +patch

The upstream has said he's not going to make a release anytime soon, despite
4.5 years and over 1000 commits of unreleased work:
https://savannah.gnu.org/bugs/index.php?49666

As this bug prevents other fonts from supplying non-broken glyphs in this
range, and freefont is installed by default on most Debian GUI installs,
let's fix this for stretch.

Thus, here's a patch.

-- 
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings.  What should the
historians do?
Description: drop broken Braille range
 The Braille range here is useless at any but very large fonts sizes.
 Upstream SVN already includes drop of these glyphs, and a new set placed
 in FreeSerif rather than FreeMono.
 .
 As FreeMono is a part of Debian's default GUI installation, and our setup
 makes fontconfig prefer taking glyphs from here rather than other fonts that
 have them in working order, the effect is making this range unreadable
 without a specific user change of configuration.
 .
 This is done as a patch to .sfd rather than a fontforge strip script because
 1. it's simpler (but uglier), 2. won't stay around when the new upstream
 release finally happens.

--- fonts-freefont-20120503.orig/sfd/FreeMono.sfd
+++ fonts-freefont-20120503/sfd/FreeMono.sfd
@@ -52687,4560 +52687,6 @@ EndSplineSet
 Validated: 3073
 EndChar
 
-StartChar: uni2800
-Encoding: 10240 10240 2241
-Width: 600
-VWidth: 1024
-Flags: HMW
-LayerCount: 2
-Fore
-Refer: 3552 -1 N 1 0 0 1 220 -660 2
-Refer: 3552 -1 N 1 0 0 1 0 -660 2
-Refer: 3552 -1 N 1 0 0 1 220 -440 2
-Refer: 3552 -1 N 1 0 0 1 220 -220 2
-Refer: 3552 -1 N 1 0 0 1 220 0 2
-Refer: 3552 -1 N 1 0 0 1 0 -440 2
-Refer: 3552 -1 N 1 0 0 1 0 -220 2
-Refer: 3552 -1 N 1 0 0 1 0 0 2
-Validated: 32769
-EndChar
-
-StartChar: uni2801
-Encoding: 10241 10241 2242
-Width: 600
-VWidth: 1024
-Flags: HMW
-LayerCount: 2
-Fore
-Refer: 3552 -1 N 1 0 0 1 220 -660 2
-Refer: 3552 -1 N 1 0 0 1 0 -660 2
-Refer: 3552 -1 N 1 0 0 1 220 -440 2
-Refer: 3552 -1 N 1 0 0 1 220 -220 2
-Refer: 3552 -1 N 1 0 0 1 220 0 2
-Refer: 3552 -1 N 1 0 0 1 0 -440 2
-Refer: 3552 -1 N 1 0 0 1 0 -220 2
-Refer: 3553 -1 N 1 0 0 1 0 0 2
-Validated: 32769
-EndChar
-
-StartChar: uni2802
-Encoding: 10242 10242 2243
-Width: 600
-VWidth: 1024
-Flags: HMW
-LayerCount: 2
-Fore
-Refer: 3552 -1 N 1 0 0 1 220 -660 2
-Refer: 3552 -1 N 1 0 0 1 0 -660 2
-Refer: 3552 -1 N 1 0 0 1 220 -440 2
-Refer: 3552 -1 N 1 0 0 1 220 -220 2
-Refer: 3552 -1 N 1 0 0 1 220 0 2
-Refer: 3552 -1 N 1 0 0 1 0 -440 2
-Refer: 3553 -1 N 1 0 0 1 0 -220 2
-Refer: 3552 -1 N 1 0 0 1 0 0 2
-Validated: 32769
-EndChar
-
-StartChar: uni2803
-Encoding: 10243 10243 2244
-Width: 600
-VWidth: 1024
-Flags: HMW
-LayerCount: 2
-Fore
-Refer: 3552 -1 N 1 0 0 1 220 -660 2
-Refer: 3552 -1 N 1 0 0 1 0 -660 2
-Refer: 3552 -1 N 1 0 0 1 220 -440 2
-Refer: 3552 -1 N 1 0 0 1 220 -220 2
-Refer: 3552 -1 N 1 0 0 1 220 0 2
-Refer: 3552 -1 N 1 0 0 1 0 -440 2
-Refer: 3553 -1 N 1 0 0 1 0 -220 2
-Refer: 3553 -1 N 1 0 0 1 0 0 2
-Validated: 32769
-EndChar
-
-StartChar: uni2804
-Encoding: 10244 10244 2245
-Width: 600
-VWidth: 1024
-Flags: HMW
-LayerCount: 2
-Fore
-Refer: 3552 -1 N 1 0 0 1 220 -660 2
-Refer: 3552 -1 N 1 0 0 1 0 -660 2
-Refer: 3552 -1 N 1 0 0 1 220 -440 2
-Refer: 3552 -1 N 1 0 0 1 220 -220 2
-Refer: 3552 -1 N 1 0 0 1 220 0 2
-Refer: 3553 -1 N 1 0 0 1 0 -440 2
-Refer: 3552 -1 N 1 0 0 1 0 -220 2
-Refer: 3552 -1 N 1 0 0 1 0 0 2
-Validated: 32769
-EndChar
-
-StartChar: uni2805
-Encoding: 10245 10245 2246
-Width: 600
-VWidth: 1024
-Flags: HMW
-LayerCount: 2
-Fore
-Refer: 3552 -1 N 1 0 0 1 220 -660 2
-Refer: 3552 -1 N 1 0 0 1 0 -660 2
-Refer: 3552 -1 N 1 0 0 1 220 -440 2
-Refer: 3552 -1 N 1 0 0 1 220 -220 2
-Refer: 3552 -1 N 1 0 0 1 220 0 2
-Refer: 3553 -1 N 1 0 0 1 0 -440 2
-Refer: 3552 -1 N 1 0 0 1 0 -220 2
-Refer: 3553 -1 N 1 0 0 1 0 0 2
-Validated: 32769
-EndChar
-
-StartChar: uni2806
-Encoding: 10246 10246 2247
-Width: 600
-VWidth: 1024
-Flags: HMW
-LayerCount: 2
-Fore
-Refer: 3552 -1 N 1 0 0 1 220 -660 2
-Refer: 3552 -1 N 1 0 0 1 0 -660 2
-Refer: 3552 -1 N 1 0 0 1 220 -440 2
-Refer: 3552 -1 N 1 0 0 1 220 -220 2
-Refer: 3552 -1 N 1 0 0 1 220 0 2
-Refer: 3553 -1 N 1 0 0 1 0 -440 2
-Refer: 3553 -1 N 1 0 0 1 0 -220 2
-Refer: 3552 -1 N 1 0 0 1 0 0 2
-Validated: 32769
-EndChar
-
-StartChar: uni2807
-Encoding: 10247 10247 2248
-Width: 600
-VWidth: 1024
-Flags: HMW
-LayerCount: 2
-Fore
-Refer: 3552 -1 N 1 0 0 1 220 -660 2
-Refer: 3552 -1 N 1 0 0 1 0 -660 2
-Refer: 3552 -1 N 1 0 0 1 220 -440 2
-Refer: 3552 -1 N 1 0 0 1 220 -220 2
-Refer: 3552 -1 N 1 0 0 1 220 0 2
-Refer: 3553 -1 N 1 0 0 1 0 -440 2
-Refer: 3553 -1 N 1 0 0 1 0 -220 2
-Refer: 3553 -1 N 1 0 0 1 0 0 2
-Validated: 32769
-EndChar
-
-StartChar: uni2808
-Encoding: 10248 10248 2249
-Width: 600
-VWidth: 1024
-Flags: HMW
-LayerCount: 2
-Fore
-Refer: 3552 -1 N 1 0 0 1 220 -660 2
-Refer: 3552 -1 N 1 0 0 1 0 -660 2
-Refer: 3552 -1 N 1 0 0 1 220 -440 2
-Refer: 3552 -1 N 1 0 0 1 220 -22

Bug#704022: patch

[Adam Borowski]

Control: tags -1 +patch

The upstream has said he's not going to make a release anytime soon, despite
4.5 years and over 1000 commits of unreleased work:
https://savannah.gnu.org/bugs/index.php?49666

Thus, here's a patch.

-- 
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings.  What should the
historians do?
Description: fix reversed floorleft and floorright in FreeSans
 These two glyphs are inverted.
 .
 Already fixed in upstream SVN but we won't see a release anytime soon.

--- fonts-freefont-20120503.orig/sfd/FreeSans.sfd
+++ fonts-freefont-20120503/sfd/FreeSans.sfd
@@ -49643,7 +49643,7 @@ Validated: 3073
 EndChar
 
 StartChar: floorleft
-Encoding: 8970 8970 2380
+Encoding: 8971 8971 2380
 Width: 456
 Flags: HMW
 LayerCount: 2
@@ -49689,7 +49689,7 @@ Validated: 3073
 EndChar
 
 StartChar: floorright
-Encoding: 8971 8971 2383
+Encoding: 8970 8970 2383
 Width: 455
 Flags: HMW
 LayerCount: 2

Bug#845488: ITP: linux-firmware-raspi3 -- Raspberry Pi 3 GPU firmware and bootloaders

[Paul Wise]

On Thu, Nov 24, 2016 at 5:37 AM, Michael Stapelberg wrote:

>  This package contains all the proprietary files necessary to boot a
>  Raspberry Pi 3 board.

You may eventually want to look at the open source RPi firmware:

https://github.com/christinaa/rpi-open-firmware

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#845281: mediawiki: backport version does not play well with extensions

[Kunal Mehta]

Hi,

On 11/21/2016 09:55 PM, Marc Dequènes (duck) wrote:
> If you try to upgrade to the bpo version and you already add
> mediawiki-extensions installed, the later is to be uninstalled. I
> understand that the new mediawiki package replaces (and in fact
> provides) the content of mediawiki-extensions-base now, same for
> mediawiki-extensions-confirmedit and mediawiki-extensions-geshi, but
> mediawiki-extensions dragged more packages which are then removed as well.

This is somewhat intentional as the new package only contains some of
those packages (those that are shipped by upstream as part of the
tarball), while the mediawiki-extensions-base package was a somewhat
arbitrary list of extensions.

> So, it seems to me you package should "Provides" these three packages,
> in order to play well with mediawiki-extensions. The exact upgrade path
> needs to be tested. Or you could package a new version of
> mediawiki-extensions without them and change the minimum requirement in
> mediawiki. I'll leave finding the best solution to your care.

The package already has provides for those three packages (base, geshi,
and confirmedit), but I think it will still need to break
mediawiki-extensions since none of the extensions in that package are
compatible with the newer version and not all of them are provided by
the new package. I also have no plans on updating the
mediawiki-extensions-* packages. So I'm not sure really what other steps
can be taken...

-- Kunal




signature.asc
Description: OpenPGP digital signature

Bug#845509: Please update the font for the Lao language

[Gunnar Hjalmarsson]

Package: fonts-lao
Version: 0.0.20060226-9
Severity: wishlist

As pointed out at , the Phetsarath OT 
font, which is currently installed by the fonts-lao package, is ancient. 
A more recent and complete option is available at 
. It would be great if 
fonts-lao could be updated to install the Phetsarath OT.ttf file from 
there instead.


The license seems to be ok (SIL OFL, embedded in the .ttf), and I have 
made a quick-and-dirty upload to Ubuntu:


https://launchpad.net/ubuntu/+source/fonts-lao/0.0.20060226-9ubuntu1

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

Bug#845508: radicale: Config example for well-known paths does not work

[Martín Ferrari]

Package: radicale
Version: 1.1.1+20160115-2
Severity: normal

For a long time I thought that Radicale's support of well-known locations was
broken, until today I realised I was getting a redirect to a silly location:

$ GET -Sd -C XXX:YYY https://my.domain/radicale/.well-known/caldav/
GET https://my.domain/radicale/.well-known/caldav/
401 Unauthorized
GET https://my.domain/radicale/.well-known/caldav/
303 See Other
GET https://my.domain/radicale/.well-known/caldav/'/XXX/caldav/'
403 Forbidden

It turns out the quotes in the sample config are taken literally, please remove
them!

Also, using a relative path would be useful to more people:

caldav = ../../%(user)s/calendar.ics/
carddav = ../../%(user)s/addressbook.vcf/


-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (900, 'stable'), (70, 'testing'), (50, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages radicale depends on:
ii  adduser  3.113+nmu3
ii  python   2.7.9-1
ii  python-radicale  1.1.1+20160115-2

radicale recommends no packages.

Versions of packages radicale suggests:
ii  apache2-utils   2.4.10-10+deb8u7
pn  courier-authdaemon  
ii  python-dulwich  0.9.7-3
pn  python-ldap 
pn  python-pampy
pn  python-passlib  
ii  python-requests 2.8.1-1~bpo8+1
pn  python-sqlalchemy   

-- Configuration Files:
/etc/default/radicale changed [not included]
/etc/radicale/config changed [not included]
/etc/radicale/logging changed [not included]

-- no debconf information

Bug#845507: having gnupg as Recommends instead of Depends breaks apt-key and tools that use apt-key

[David Lechner]

Package: apt
Version: 1.3.1

In apt (1.3~exp1), the following change was made:

  * move gnupg|gnupg2 from apt Depends to Recommends


This breaks the apt-key command, which is part of the apt package.

Example:

$ apt-key list
Error: gnupg, gnupg2 and gnupg1 do not seem to be installed,
Error: but apt-key requires gnupg, gnupg2 or gnupg1 for this operation.


This also breaks tools like pbuilder which uses apt-key to add keyrings.

Example:

$ pbuilder 
Creating /home/david/pbuilder-ev3dev/debian/base-stretch-armhf.tgz
...
I: adding apt key file /usr/share/keyrings/ev3dev-archive-keyring.gpg.
Error: gnupg, gnupg2 and gnupg1 do not seem to be installed,
Error: but apt-key requires gnupg, gnupg2 or gnupg1 for this operation.


Please change gnupg|gnupg2 back to Depends

Bug#845506: [Pkg-openldap-devel] Bug#845506: FTBFS arch-indep only

[Ryan Tandy]

On Thu, Nov 24, 2016 at 06:21:24AM +0100, Daniel Baumann wrote:

openldap now fails to build when building architecture-independent
packages only.


Ah, right, I guess we have one of those now. :/

please make the chmod ldiftopasswd in rules either conditional on 
existence of the file, or better, improve the rules file with the 
respective targets in order to do the chmod only when building 
binary-arch packages.


Thanks for the suggestions, I'll look into this ASAP.

Bug#845506: FTBFS arch-indep only

[Daniel Baumann]

Package: openldap
Version: 2.4.44+dfsg-1

Hi,

openldap now fails to build when building architecture-independent
packages only. please make the chmod ldiftopasswd in rules either
conditional on existence of the file, or better, improve the rules file
with the respective targets in order to do the chmod only when building
binary-arch packages.

Regards,
Daniel

Bug#845193: dpkg: recent -specs PIE changes break openssl

[Guillem Jover]

Control: retitle -1 dpkg: openssl1.0 broken on x32 due to PIE -specs

Hi!

On Mon, 2016-11-21 at 12:01:21 +0100, Thorsten Glaser wrote:
> Source: dpkg
> Version: 1.18.15
> Severity: important

> I cannot build openssl1.0 any longer. Downgrading all binary
> packages from src:dpkg to 1.18.10 makes the build succeed.
> 
> I’m suspecting it tries to compile library code (which must
> be PIC) as PIE, or something. I got this advice from the
> openssl maintainer:

Yes, from the log it seems so.

> >I have no idea what those specs things do, and can only suggest
> >you try to tell dpkg-buildflags not to do that.

Those specs files should make it possible to build stuff with PIE
unconditionally as long as they declare correctly what they are
intended to be. So if the object is supposed to be PIC (and the
compiler is explicitly told so) then the specs will not enable
PIE by themselves.

> This does not happen on most architectures because it appears
> to be a result of dpkg adding weird -specs=* flags only on
> some of them. Please make this cross-architecture consistent:
> do it on all or none.

Precisely to make the behavior consistent on all architectures, dpkg
enables PIE (conditionally if no other flags marks it as to be
disabled) on all architectures were gcc has not enabled this by
default. And it appears to build on every of those too, except for
x32, so I suspect something is broken there, either in the toolchain
or in the openssl1.0 setup?

> Full build log attached.

[…]
> make[3]: Entering directory '/tmp/buildd/openssl1.0-1.0.2j'
> [ -z "" ] || gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT 
> -DDSO_DLFCN -DHAVE_DLFCN_H -mx32 -DL_ENDIAN -g -O2 
> -fdebug-prefix-map=/tmp/buildd/openssl1.0-1.0.2j=. 
> -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
> -specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro -Wa,--noexecstack -Wall 
> -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM 
> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM 
> -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -Iinclude \
>   -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso  \
>   fips_premain.c fipscanister.o \
>   libcrypto.a -ldl
> make[4]: Entering directory '/tmp/buildd/openssl1.0-1.0.2j'
> make[5]: Entering directory '/tmp/buildd/openssl1.0-1.0.2j'
> /usr/bin/ld: libcrypto.a(cryptlib.o): relocation R_X86_64_PC32 against symbol 
> `stderr@@GLIBC_2.16' can not be used when making a shared object; recompile 
> with -fPIC
> /usr/bin/ld: final link failed: Bad value
> collect2: error: ld returned 1 exit status
> Makefile.shared:169: recipe for target 'link_a.gnu' failed
> make[5]: *** [link_a.gnu] Error 1

Checking the buile system it seems that the link_a.gnu target (instead
of link_o.gnu) tries to link a static library composed of PIE objects
into a shared library, which makes it fail. You might need to track
down why that happens only on x32?

So, I think I'll reassign this to openssl1.0, if no other feedback
is provided showing that this is a problem in dpkg itself, such as
PIE not working at all there, and a request to disable it for x32 in
dpkg as non-functional. Also BTW the gcc maintainer asked that porters
interested could request PIE to be enabled by default in gcc.

Thanks,
Guillem

Bug#844789: [Debian-science-sagemath] Bug#844789: iS: issue related to compressed manual.six

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Again,

On 24/11/16 02:52, Jerome BENOIT wrote:
> 
> 
> On 23/11/16 09:59, Bill Allombert wrote:
>> Can you generate a full strace dump ?
> 
> Yes. Unfortunately I have not yet succeeded to decipher them.
> 
> There is a `Broken pipe' somewhere.
> The piping seems to be related to the uncompresion of a `manual.siz.gx'.

There are a myriad of processes: the messages around the `Broken pipe' are:

execve("/bin/gunzip", ["gunzip"], [/* 90 vars */]) = 0
[...]
rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGHUP, NULL, {SIG_IGN, [], 0}, 8) = 0
rt_sigaction(SIGPIPE, NULL, {SIG_IGN, [], 0}, 8) = 0
rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGXCPU, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGXFSZ, NULL, {SIG_IGN, [], 0}, 8) = 0
rt_sigaction(SIGINT, {0x4035c0, [INT TERM XCPU], SA_RESTORER, 0x7eff302e1040}, 
NULL, 8) = 0
rt_sigaction(SIGTERM, {0x4035c0, [INT TERM XCPU], SA_RESTORER, 0x7eff302e1040}, 
NULL, 8) = 0
rt_sigaction(SIGXCPU, {0x4035c0, [INT TERM XCPU], SA_RESTORER, 0x7eff302e1040}, 
NULL, 8) = 0
ioctl(0, TCGETS, 0x7ffef9ddf1c0)= -1 ENOTTY (Inappropriate ioctl for 
device)
fstat(0, {st_mode=S_IFREG|0644, st_size=171476, ...}) = 0
read(0, 
"\37\213\10\0\0\0\0\0\2\3\244\\\331\222\324H\226}\317\257\220\345\274T\233\1\346\3732c\363\240"...,
 32768) = 32768
brk(NULL)   = 0x669000
brk(0x68a000)   = 0x68a000
write(1, "#SIXFORMAT  GapDocGAP\nHELPBOOKIN"..., 32768) = 32768
write(1, ".4-1\", [ 20, 4, 1 ], 98, 246, \"l"..., 32768) = 32768
write(1, " \"35.3-5\", [ 35, 3, 5 ], 310, 46"..., 32768) = 16384
- --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=9643, si_uid=1000} ---
write(1, "033[101X\", \"41.10-2\", \n  [ 4"..., 16384) = -1 EPIPE (Broken 
pipe)
- --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=9643, si_uid=1000} ---
write(2, "\ngzip: ", 7) = 7
write(2, "stdout: Broken pipe\n", 20)   = 20
rt_sigprocmask(SIG_BLOCK, [INT TERM XCPU], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
lseek(0, 0, SEEK_CUR)   = 32768
close(0)= 0
close(1)= 0
close(2)= 0
exit_group(1)   = ?
+++ exited with 1 +++

[[/bin/gunzip is in fact a shell script that wraps `gzip -d' ]]

It looks like that it happens what is described in the following link:

https://blog.nelhage.com/2010/02/a-very-subtle-bug/

that is to say, python/sage manipulates SIGPIPE in such a way that any gzip 
piping
becomes hazardous. If so, I guess that we have to consider to use zlib instead
of pipe+gunzip.

> 
> A closer look to the gap code convinces me that zlib for gzip uncompression
> instead of piping through gunzip.
> 
> Thanks,
> Jerome

Thanks,
Jerome


> 

> 
> 
> ___
> Debian-science-sagemath mailing list
> debian-science-sagem...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/debian-science-sagemath
> 

- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJYNnK/AAoJED+SGaZ/NsaLB/ggAIvESfrk0VkldQcYQEWwMgu9
UvtWA21uFPD/CkCxzYLsAUcVeIVxqnBPE7OIadL7QUYslhUvGdOML1hPiVZEGzTJ
7x61ZqwwuckOZDooBVINDwup7FE4PUGcbH3ELWB6Rdn0ox6VtkS9TLR3kaaC7edg
HZ1QYTmAjBgdi9J0VFJbkXNqThyENKhQZuqkCi4AKSbCKEPq5sQExodx6VAUezQK
b6SfB09Xfn8cZiyv5yPMhYLa+0AiZP7lCtWh0Lb7bXf3dx9L+UepXxoDQYBGky/a
yqGb81EiTo0tlpYGBfNE5HmtKla2Mn5cWimPft23VjToy65AkUOQGcnLO4/pWPOc
H3TmsMVJz4frK3SyYOGkhqid+n8+ZFud7nOQ+UriuXcSfdu9H0S0tqVRZnxYGzls
lotnyWxoVqSCgNS6GnOjoj9QBDi03mdlpJDNU+69YHVhjxF25KkGfZDf1H2yAyej
y4UpYdAjLUT+FsDZWyhZhN9eWGas9KJAvHaHUg7rOYPhXpLDZOVBpcuOXAKQvDjW
R/c6FYOll9QfiPiBL/570d6DQEtOGiyFXvBjiMSHYD+oxxh0G/3ZMj+7uSD1WIe8
/LW+mtjffkk4g2AxkMCaqvmc6/Pg2ftBzYAENCGDIKLVhUJEpXV0mH1WeJ3ovAmm
17fHLhICTE7q2A5xxxcSGt9yOA6p+ZjOXEfhsRAGtK+dCqnzEQkkfymUeqiZNDeK
T3kqrZjyflWCrC6gt2u4/jyDGBsOtukTPZmhAslymy2NaiGWCu06Boe/dO6FU5n/
fGBgQlzcmbJmnQZx5VJXlnWPMSSQIicoeICTI/cLTAt9f78vWeLonGvna5fZhI+t
HX8OI5uRQq7DNOrSDmNJIpu1xt16a2ALUPUZC90JvUeiCbAGms2x1QcCINbYs61u
E4jh/CUsQkj5dginkHD3SIOc8VUODZK+8Uf0FH8p1xjGjzkz0LM3ZPA7kzKEbGH+
olBXVE2yveGJgYkANij9iZE8Xhjdkxv4Rde+yEZRpJGJnk6tHQyOY7Phoi41UcG3
CfNuzLo+aVv/VFdZykHcNeDwwZCvnhx2rzg++iTFjgnhC15bAxSwdZKLKe1Eyy7l
8AeG5om1mHnMOcwkYVsK0qhAC777IwTFXQtbidN/hcKupc1EKlVbv6t0C8K4C0Co
5nlyasOo4I5dDPMuwakN9DoeT1xe1aFaR1375VeVLv2mZi/u1AQINJDwxIrVlM7j
679iV+0g6EgTw1hS8LlJgZNFUk1OuQN3KI1CoPIF5XkcZ4uJelM56EDTV7pGaP4q
WTFtLDxd/NjOZ4W4UTVFGkSYXlSW7NLonPKlmdadVkFAeL5zTAT51r71wCdBPKw=
=ngla
-END PGP SIGNATURE-

Bug#845505: sra-sdk 2.7.0-1 is broken libncbi-vdb2 2.8.0+dfsg-1

[Charles Plessy]

Package: sra-sdk
Severity: grave

Hi all,

quick note from work; sorry to not being able to go deeper.

A colleague has reported to me that sra-sdk 2.7.0-1 is broken
libncbi-vdb2 2.8.0+dfsg-1.  For instance:

fastq-dump
fastq-dump: symbol lookup error:
/usr/lib/x86_64-linux-gnu/libncbi-vdb.so.2: undefined symbol:
mbedtls_ctr_drbg_seed

Downgrading libncbi-vdb2 to 2.7.0+dfsg-4~bpo8+1.

There are no build logs for sra-sdk on amd64, but I guess that sra-sdk
2.7.0-1 could have been built against 2.7.0+dfsg-4 by mistake (given
that they have been uploaded on the same day, I assume that they were
intended to be used together).  Note that now, with source-only uploads,
it is easier to get build logs.

If we are lucky, maybe a binNMU will be enough ?  On the other hand,
maybe the only way to prevent problems for the users upgrading form
Testing would be to tighten the dependency.

Have a nice day,

-- 
Charles

Bug#789581: marked as pending

[Guillem Jover]

Hi!

On Wed, 2016-11-23 at 18:11:37 +, James McCoy wrote:
> commit 607c5911b44ca61cf352e80397b5707ee23d9eec
> Merge: 1f82d5b 064dc31
> Author: James McCoy 
> Date:   Wed Nov 23 12:53:49 2016 -0500
> 
> Merge branch 'debuild-slimming'
> 
> Refactor debuild to be a much thinner wrapper around dpkg-buildpackage.
> There is no longer any emulation of dpkg-buildpackage, and unknown
> options will be passed through to dpkg-buildpackage.

Wow, great! Thanks for this.

It seems that in commit 6bf94e623894dc2b7da41f6a45d9b4368d250ce2
there's a swapped hook name and it should be:

  'final-clean' => 'postclean',

?

Also checking what's missing, I guess I could add a new --sign-option,
in which case iff when passed, I could make --sign-command receive just
the file to sign, so that you could pass debsign/debrsign? I think that
would allow eliminating another good chunk of code?

Also probably we should move the Ubuntu checks into a new hook in
Dpkg::Vendor::Ubuntu?

Should DPKG_.* environment variables also be preserved?

Thanks,
Guillem

Bug#845138: mate 1.16.1 released. Please upload version 1.16.1 ASAP into debian sid, so that it integrates into debian stable 9 stretch

[Zaxebo Yaxebo]

Mike Gabriel>> 'the current plan is that Debian 9 will come even with
MATE 1.18...  I'll go through all packages that require an upload over
the coming
weekend.'

Ohh. Having That Version 3.18 will be the greatest thing to have in debian 9.
That will make our our future happiest for next many years, with
debian stable 9. Thanks a lot in advance. :-)

- zaxebo

Bug#844789: [Debian-science-sagemath] Bug#844789: iS: issue related to compressed manual.six

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 23/11/16 09:59, Bill Allombert wrote:
> Can you generate a full strace dump ?

Yes. Unfortunately I have not yet succeeded to decipher them.

There is a `Broken pipe' somewhere.
The piping seems to be related to the uncompresion of a `manual.siz.gx'.

A closer look to the gap code convinces me that zlib for gzip uncompression
instead of piping through gunzip.

Thanks,
Jerome
> 
>> > 

- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJYNlXyAAoJED+SGaZ/NsaLSdIgALyOX40WQADiGiR2asVAxMQW
ZkOnyhukZUD6ijzAeEb1BVr51qI7ft8iSuQOlSimN38e+TE+YDje8Sk2mWwjjb1d
GtxBAvmGYd7tFh2zH4BrI5GO6e/kPdGrr1tyn1zosa0LnAnKf1/Mfyn82JyBPRjq
VcLTonEI9VkRGOmmREFRZ+AcEpvN113z3dRGpihrOgJay7yqbbG/zxpY81XFsJS7
MSunx/9chfPA4CfKMyVyDDzYDEcToUOOYGMOhhljkQf6he7TkN049HMTHeaBoxvL
6dF8x8qVEz/VeGC9NLMJGSJ1VXIF+HGcUAtRuLWHaqsQ1bi1L/bz9xiDiHlbIHYl
I/eQYSSd6ZzE3+VYTe1c72ml1Er1vnIaSuaOtB6lksEcyQIqg2AZlBJFCm+78JRG
MdnEogFVFf4q88c81a48cVt4aktGZ6zeZDIkfDkBxivhpgRBHYzCDxBzCoaVSA6z
q5awkgELBJtnvoJXR5qxfzyGejIov9nN/Zrm2JMH35tgegrvz1JPHVqT9K2LfN2v
2dMEV6GZ5xqoK1bhwXCy0zcm6gLfqW+q/0lbAF7HstBEaP3cRTvZboV9a7Cp8EsT
0+In3zJWdxxmjEQEH8/eIErTwSWkxBH+sbK2NEKkCcnax5PV1EK91Qx+E+KPY5ZZ
ixLGcgALrAIQ3l0tUt3jKLXK6W7JVa5OvdWlbkFDKgBqsnsjDVQGs/QfhgGoEDwm
JNW4kTQ83p9OaXEtgykZ2iX8YBAkfiEGByMshemXw3RE3+PZTaKSzdgygPQ2lY5C
zJGgxY8L/yGl7o93x1g5IzE+8jNCogQqHMXsQ5JrcDHobnhqgR9FvQN61eXr68SE
I5nb97UD42Jq0IZLxDTneq4e47hnOc39oMogiCqMLiZ2HR8aIkIGpFIFEJz9azm3
RYLTXwBJZxU+QnFBuUWhvi4MLf4p0JeOMv00D+j2Odq+4Tz61NvlWdkpHudJF6QZ
Sujb7orVTj5Kjnav2oAvtcihED3t6u6sbIwmqZvUbh70LlTScsZ23rF/urYIvXC2
BiCnpyVuqGRwW/Ah3+KPZLOe68jRmjDgcg8E0Okoi22sOjkfx4upgI2x/nTcNrNv
+5Le6UWac5zRz1BoPIvYy/K/gTg7ar1Ag5u27uB2y3YTacx+aRC7tWHMtpnF9U1V
KtyA0GIroQqMj/GA1HMzbD15hNLa/bKo4lhMdZ1QmBYhmFqr16ZPxs54d20ATa5m
G6Q+1gApgNYZb3QvUJTdJaVOBfdTYYVJ9vGzlTLRqeJ+4/KW2E4dsRKRUTBvFBrw
4kNYvlm5yvGTamSS0BqGa/YJPOv+BdrS5oLoOfelj9oWCfV2hKQ6fg8lsIDWKZo=
=1ddT
-END PGP SIGNATURE-

Bug#843402: reprepro cannot handle .changes files that reference .buildinfo files

[Guillem Jover]

[ Please remember to CC people, otherwise only the maintainer and
people subscribed to the bug (hich requires explicit action) might
see your replies. :) I just noticed when scanning the web interface. ]

Hi!

On Tue, 2016-11-22 at 00:31:47 +0100, Slávek Banko wrote:
> I tried to update reprepro on Jessie by packages from Jan Wagner and also 
> from Stephan Sürken but I noticing problems. When I use "reprepro 
> processincoming", I got:
> 
> There have been errors!
> 
> Nothing else == just this one brief sentence.
> When I use "reprepro include", I got:
> 
> reprepro: checkin.c:680: changes_fixfields: Assertion `((e->type) == 
> fe_DIFF || (e->type) == fe_ORIG || (e->type) == fe_TAR || (e->type) == 
> fe_DSC || (e->type) == fe_UNKNOWN || (e->type) == fe_ALTSRC) || 
> ((e->type) == fe_DEB || (e->type) == fe_UDEB)' failed.
> Aborted

Hmm, oh it seems I missed updating one of the spots! Could you try
with the updated patch attached? (I've also updated the one in the
hadrons.org for people that might be pulling that one.)

Thanks,
Guillem
From 69d47432d9d434196b45276f0aac5cabed66860d Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Fri, 18 Nov 2016 14:11:58 +0100
Subject: [PATCH] Add preliminary .buildinfo support

---
 changes.c   |  5 +++-
 changes.h   |  3 ++-
 checkin.c   | 55 +---
 distribution.h  |  1 +
 docs/reprepro.1 |  3 +++
 incoming.c  | 78 +
 needbuild.c |  2 +-
 tracking.c  | 10 ++--
 trackingt.h |  1 +
 9 files changed, 144 insertions(+), 14 deletions(-)

diff --git a/changes.c b/changes.c
index 5d01754..2cafca3 100644
--- a/changes.c
+++ b/changes.c
@@ -237,6 +237,9 @@ retvalue changes_parsefileline(const char *fileline, /*@out@*/filetype *result_t
 		} else if (l > 6 && strncmp(p-6, ".build", 6) == 0) {
 			type = fe_LOG;
 			eoi = p - 6;
+		} else if (l > 10 && strncmp(p-10, ".buildinfo", 10) == 0) {
+			type = fe_BUILDINFO;
+			eoi = p - 10;
 		}
 		if (type != fe_UNKNOWN) {
 			/* check for a proper version */
@@ -255,7 +258,7 @@ retvalue changes_parsefileline(const char *fileline, /*@out@*/filetype *result_t
 	return RET_ERROR;
 }
 checkfilename = true;
-			} else if (type == fe_LOG) {
+			} else if (type == fe_LOG || type == fe_BUILDINFO) {
 if (*p == '_') {
 	archstart = p + 1;
 	archend = eoi;
diff --git a/changes.h b/changes.h
index 30ad136..f2b72c3 100644
--- a/changes.h
+++ b/changes.h
@@ -10,7 +10,8 @@ typedef enum {
 	fe_DEB, fe_UDEB,
 	fe_DSC, fe_DIFF, fe_ORIG, fe_TAR,
 	fe_ALTSRC,
-	fe_BYHAND, fe_LOG, fe_CHANGES
+	fe_BYHAND, fe_LOG, fe_CHANGES,
+	fe_BUILDINFO
 } filetype;
 
 #define FE_PACKAGE(ft) ((ft) == fe_DEB || (ft) == fe_UDEB || (ft) == fe_DSC)
diff --git a/checkin.c b/checkin.c
index 3b1ec32..be46256 100644
--- a/checkin.c
+++ b/checkin.c
@@ -161,7 +161,7 @@ static void changes_free(/*@only@*/struct changes *changes) {
 }
 
 
-static retvalue newentry(struct fileentry **entry, const char *fileline, const struct atomlist *packagetypes, const struct atomlist *forcearchitectures, const char *sourcename, bool includebyhand, bool includelogs, bool *ignoredlines_p, bool skip_binaries) {
+static retvalue newentry(struct fileentry **entry, const char *fileline, const struct atomlist *packagetypes, const struct atomlist *forcearchitectures, const char *sourcename, bool includebyhand, bool includelogs, bool includebuildinfos, bool *ignoredlines_p, bool skip_binaries) {
 	struct fileentry *e;
 	retvalue r;
 
@@ -207,7 +207,7 @@ static retvalue newentry(struct fileentry **entry, const char *fileline, const s
 		*ignoredlines_p = true;
 		return RET_NOTHING;
 	}
-	if (e->type != fe_LOG &&
+	if (e->type != fe_LOG && e->type != fe_BUILDINFO &&
 			e->architecture_into == architecture_source &&
 			strcmp(e->name, sourcename) != 0) {
 		fprintf(stderr,
@@ -242,6 +242,34 @@ static retvalue newentry(struct fileentry **entry, const char *fileline, const s
 			*ignoredlines_p = true;
 			return RET_NOTHING;
 		}
+	} else if (e->type == fe_BUILDINFO) {
+		if (strcmp(e->name, sourcename) != 0) {
+			fprintf(stderr,
+"Warning: File '%s' looks like buildinfo but does not start with '%s_'!\n",
+	e->basename, sourcename);
+		}
+		if (!includebuildinfos) {
+			// TODO: at least check them and fail if wrong?
+			fprintf(stderr, "Ignoring buildinfo file: '%s'!\n",
+			e->basename);
+			freeentries(e);
+			*ignoredlines_p = true;
+			return RET_NOTHING;
+		}
+		if (atom_defined(e->architecture_into) &&
+limitations_missed(forcearchitectures,
+	e->architecture_into)) {
+			if (verbose > 1)
+fprintf(stderr,
+"Skipping '%s' as not for architecture ",
+	e->basename);
+			atomlist_fprint(stderr, at_architecture,
+	forcearchitectures);
+			fputs(".\n", stderr);
+			freeentries(e);
+			*ignoredlines_p = true;
+			return RET_NOTHING;
+		}
 	} else if (forcearchitectures != NULL) {
 		if (e->architecture_into == architecture_all &&
 	

Bug#845478: dpkg postinst script fails to move files in /etc

[Guillem Jover]

Control: tags -1 moreinfo

On Wed, 2016-11-23 at 21:10:06 +0100, HJ wrote:
> Package: dpkg
> Version: 1.18.15
> Severity: normal

> since I upgaded to sid the following postinstall script doest work
> anymore(https://github.com/sixsixfive/Hedera/blob/master/debian/postinst)
> 
> commands that fail:
> 
> https://github.com/sixsixfive/Hedera/blob/master/debian/postinst#L45
> https://github.com/sixsixfive/Hedera/blob/master/debian/postinst#L73
> https://github.com/sixsixfive/Hedera/blob/master/debian/postinst#L95
> 
> its also a complete mystery to me that it worked in the past and that it still
> works on siduction, ubuntu/KDE neon

After quickly scanning over that postinst, I'm not entirely sure how
this is related to dpkg itself, instead of say the layout of the gtk
or Qt packages. Giving more verbose output, and what happens now and
what you'd expect would be helpful in trying to diagnose this. Also
perhaps you could also add set -x at the beginning of the script to
see what's going on.

Please send logs! :)

Thanks,
Guillem

Bug#845504: /usr/bin/ppdep-3.0.0: Claims to understand conditional defines, but doesn't handle {$ELSE}

[Ben Longbons]

Package: fp-utils-3.0.0
Version: 3.0.0+dfsg-9
Severity: important
File: /usr/bin/ppdep-3.0.0

Dear Maintainer,


In the `gearhead` package, `ppdep gharena.pas` produces almost no
output, whereas `ppdep -dSDLMODE gharena.pas` produces plenty.

Relevant source snippet:

{$IFDEF SDLMODE}
uses gears,sdlgfx,arenahq,sdlmenus,randchar,navigate,sdlmap;
{$ELSE}
uses gears,congfx,arenahq,conmenus,randchar,navigate,context,mapedit;
{$ENDIF}

Expected output:
gharena: gharena.pas 
foo.ppu: foo.pp 

Actual output:
gharena: gharena.pas

Workaround:

{$IFNDEF SDLMODE}
{$DEFINE TUIMODE}
{$ENDIF}

{$IFDEF SDLMODE}
uses gears,sdlgfx,arenahq,sdlmenus,randchar,navigate,sdlmap;
{$ENDIF}
{$IFDEF TUIMODE}
uses gears,congfx,arenahq,conmenus,randchar,navigate,context,mapedit;
{$ENDIF}

... and so on, 269 more times. Assuming none of those {$ELSE}s is for
something "else" besides {$IFDEF SDLMODE}.


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

Kernel: Linux 4.7.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 fp-utils-3.0.0 depends on:
ii  fpc-source-3.0.0  3.0.0+dfsg-9
ii  libc6 2.24-5

Versions of packages fp-utils-3.0.0 recommends:
ii  fp-compiler-3.0.0  3.0.0+dfsg-9

fp-utils-3.0.0 suggests no packages.

-- no debconf information

Bug#845484: libdpkg-perl: broken /usr/share/dpkg/no-pie-compile.specs

[Guillem Jover]

Hi!

On Wed, 2016-11-23 at 23:42:56 +0300, Roman Tsisyk wrote:
> Package: libdpkg-perl
> Version: 1.18.15
> Severity: serious

> I use cdbs with cmake, which automatically adds the following
> compilation flags gcc/g++/ld:
> 
> -DCMAKE_C_FLAGS="-g -O2 -fdebug-prefix-map= =. 
> -specs=/usr/share/dpkg/no-pie-compile.specs -Wformat -Werror=format-security 
> -Wdate-time -D_FORTIFY_SOURCE=2" 
> -DCMAKE_CXX_FLAGS="-g -O2 -fdebug-prefix-map==. 
> -specs=/usr/share/dpkg/no-pie-compile.specs -Wformat -Werror=format-security 
> -Wdate-time -D_FORTIFY_SOURCE=2" 
> -DCMAKE_MODULE_LINKER_FLAGS="-specs=/usr/share/dpkg/no-pie-link.specs 
> -Wl,-z,relro" 
> -DCMAKE_SHARED_LINKER_FLAGS="-specs=/usr/share/dpkg/no-pie-link.specs 
> -Wl,-z,relro" 

> gcc can't compile even a simple C program using this spec:
> 
> --
> #include 
> 
> int
> main(void)
> {
>     printf("hello\n");
>     return 0;
> }
> --
> 
> --
> gcc xx.c -o xx -specs=/usr/share/dpkg/no-pie-compile.specs
> /usr/bin/ld: /tmp/ccEbzEVn.o: relocation R_X86_64_32 against `.rodata' can 
> not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> --
> 
> This spec file is owned by libdpkg-perl package.  Please consider to
> fix this spec or to revert the latest changes.

The problem is that whatever is linking that code is not passing the
correct flags. There is a missing LDFLAGS somewhere. If you retry with:

  $ gcc -o xx xx.c \
  -specs=/usr/share/dpkg/no-pie-compile.specs \
  -specs=/usr/share/dpkg/no-pie-link.specs

it will work.

> Severity is serious because this spec file is completely unusable
> for everyone.

Only if used incorrectly. ;) Otherwise big parts of the Debian archive
would be already completely broken!

So I'd like more information to know to what package to reassign this
to? Either cdbs, cmake or perhaps this is a problem in the package you
are trying to build (either in Debian or local)? Otherise I'll just
close this bug as invalid (at least when it comes to libdpkg-perl
itself).

Regards,
Guillem

Bug#839580: request-tracker4: FTBFS in testing (failed tests)

[Daniel Kahn Gillmor]

On Tue 2016-10-11 23:48:15 -0400, Daniel Kahn Gillmor wrote:
> Those patches are posted here:
>
>  https://github.com/bestpractical/gnupg-interface/pull/1
>
> I'd like to upload them to debian as well, though they are *not*
> interoperable with versions of GnuPG prior to 2.1.x, due to GnuPG's
> non-portable interface :/ I've pushed a proposed upload to experimental
> to the move-to-modern-gnupg branch on
> https://anonscm.debian.org/git/pkg-perl/packages/libgnupg-interface-perl.git
>
> (see also discussion around this portability issue here:
> https://lists.gnupg.org/pipermail/gnupg-devel/2016-October/031800.html)
>
> sigh...
>
> Any thoughts on the right thing to do with libgnupg-interface-perl?

I haven't heard anything about this -- either from upstream, or from
other debian perl or gnupg folks.  I've gone ahead with the experimental
upload, so please let me know if you see this causing trouble.

--dkg


signature.asc
Description: PGP signature

Bug#784070: Newly-created arrays don't auto-assemble - related to hostname change?

[Andy Smith]

Hi,

On Wed, Nov 23, 2016 at 12:03:49PM +0300, Michael Tokarev wrote:
> It was long ago when we disabled incremental assembly when
> you turned it on by default, and kept old static way to
> assemble arrays, because neither our initrd nor regular
> userpsace weren't ready for that.

Okay, so, on Debian jessie then, it is expected that md arrays on
devices that are only present after the initramfs is done working
will not be automatically (incrementally) started?

I saw Yann mentioned that in stretch the GOTO="md_inc_end" has been
removed again. Does that mean that incremental assembly on device
change is expected to work again in stretch (I have not tested it,
and most likely will not have time to do so with this hardware).

Thanks,
Andy

Bug#845503: bluetooth: blueman fatal D-Bus exceptions (Bluetooth ver: <= 4.0, CHIP: CSR8510 A10 and ath3k based)

[Lorenzo Ancora]

Package: bluetooth
Version: 5.23-2
Severity: important

Dear Maintainer,
blueman cannot send or receive files with OBEX and cannot send or receive
sounds with any connected adapter. It is also unstable (sometimes fails the
connection, other times starts an audio connection without user interaction)
and shows GUI errors  when using a Bluetooth 4.0 (CE and CSR 4.0 compliant)
adapter.

With Bluetooth 4.0 (CSR8510 A10) blueman-adapters crashes immediately with the
error "org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with
unknown return code 1" and then continues to work with reduced and faulty
functionality.
Screenshot: https://s21.postimg.org/wm7sikzif/bluez_crash.png

With other adapters (Atheros based) it does not show GUI errors, but the
functionality is reduced like in the previous case.

In both cases the bluetooth peer (a mobile Android phone) can pair and connect,
but the connection fails after a few seconds and only the Debian side notices
it.
Also, any file transfer fails silently if started on Android and a connection
timeout error is shown if started on the workstation.

The bluez suite correctly identifies the surrounding devices and the pairing
partially succeeds, but the user cannot send or receive files and any attempt
of a voice connection fails with "blueman.bluez.errors.DBusFailedError: No such
file or directory".

I think that the Debian syslog has important informations for us:
[...]
org.blueman.Mechanism[963]: conf_service()
org.blueman.Mechanism[963]: dbus.exceptions.DBusException:
org.freedesktop.DBus.Error.AccessDenied: Connection ":1.201" is not allowed to
own the service "org.blueman.Mechanism" due to security policies in the
configuration file
dbus[963]: [system] Activated service 'org.blueman.Mechanism' failed:
Launch helper exited with unknown return code 1
dbus[963]: [system] Activating service name='org.blueman.Mechanism'
(using servicehelper)
[...]

I hope that the problem can be solved with a simple configuration change.
Thank you for your patience.



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

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

Versions of packages bluetooth depends on:
ii  bluez  5.23-2+b1

bluetooth recommends no packages.

Versions of packages bluetooth suggests:
ii  bluez-cups   5.23-2+b1
ii  bluez-obexd  5.23-2+b1

-- no debconf information

Bug#305471: huj

[serina johnson]

Hi,My name is Serina Johnson ,I would like you to respond to this mail as I 
have something very important to tell you,

Cares

Serina

Bug#845500: nftables: notrack target fails with No such file or directory

[Peter Colberg]

On Thu, Nov 24, 2016 at 01:55:01AM +0100, Jens Reyer wrote:
> According to
> https://lists.debian.org/debian-devel-announce/2016/03/msg0.html it
> will be 4.10.

That would be great. After the recent announcement that 4.9 will
probably be the next LTS kernel I assumed that the same version
would also be shipped with stretch.

http://kroah.com/log/blog/2016/09/06/4-dot-9-equals-equals-next-lts-kernel/

Peter

Bug#845500: nftables: notrack target fails with No such file or directory

[Peter Colberg]

On Wed, Nov 23, 2016 at 07:34:42PM -0500, Peter Colberg wrote:
> Assuming 4.9 becomes the stretch kernel, could you backport the patch?

The same applies to kernel support for the "fib" expression that may
be used for reverse path filtering (analogous to iptables rp_filter).

https://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/commit?id=f6d0cbcf09c506b9b022df8f9d7693a7cec3c732

That patch is more extensive and there are many more commits needed to
sync nftables kernel support with userspace. Backporting does not make
much sense. I am crossing fingers for 4.10 making it into stretch.

Peter

Bug#845500: nftables: notrack target fails with No such file or directory

[Jens Reyer]

On 24.11.2016 01:34, Peter Colberg wrote:
> Assuming 4.9 becomes the stretch kernel, could you backport the patch?

According to
https://lists.debian.org/debian-devel-announce/2016/03/msg0.html it
will be 4.10.

Greets
jre

Bug#845502: [Popcon-developers] Bug#845502: popularity-contest: Please add powerpcspe architecture

[Bill Allombert]

On Thu, Nov 24, 2016 at 01:19:38AM +0100, John Paul Adrian Glaubitz wrote:
> Source: popularity-contest
> Version: 1.64
> Severity: normal
> User: debian-powe...@lists.debian.org
> Usertags: powerpcspe
> 
> Hi!
> 
> Although 'powerpcspe' has been part of Debian Ports for a while now,
> it's still not showing up as an architecture in popcon.debian.org [1].
> 
> Could you do the necessary modifications to the website and/or the
> popularity-contest package so that we can also see the statistics
> for powerpcspe?

The list is generated dynamically. If powerpcspe is not listed, it is
because no such system is reporting to popcon.

Cheers,
Bill.

Bug#845500: nftables: notrack target fails with No such file or directory

[Peter Colberg]

Control: reassign -1 linux 4.9~rc5-1~exp1

Dear Maintainer,

nftables recently added support for a notrack target, which is used to
disable connection tracking for selected packets, e.g., on a web server.

http://git.netfilter.org/nftables/commit/?id=a84921d7c0de950632ab4630dd4f7ad763e9e453

While the nftables package in Debian stretch will support notrack, the
corresponding kernel support was committed after the 4.9 merge window:

https://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/commit/net/netfilter/nft_ct.c?id=254432613c588640f8b8b5c3641a3c27bbe14688

Assuming 4.9 becomes the stretch kernel, could you backport the patch?

Regards,
Peter

Bug#845502: popularity-contest: Please add powerpcspe architecture

[John Paul Adrian Glaubitz]

Source: popularity-contest
Version: 1.64
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: powerpcspe

Hi!

Although 'powerpcspe' has been part of Debian Ports for a while now,
it's still not showing up as an architecture in popcon.debian.org [1].

Could you do the necessary modifications to the website and/or the
popularity-contest package so that we can also see the statistics
for powerpcspe?

Thanks,
Adrian

> [1] http://popcon.debian.org/

--
 .''`.  John Paul Adrian Glaubitz
 : :' :  Debian Developer - glaub...@debian.org
 `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#845500: nftables: notrack target fails with No such file or directory

[Peter Colberg]

Control: tags -1 upstream

On Wed, Nov 23, 2016 at 06:34:06PM -0500, Peter Colberg wrote:
> The latest snapshot of nftables adds a notrack target that may
> be used to disable connection tracking for selected packets:

This is the corresponding patch for netfilter:

https://patchwork.ozlabs.org/patch/684684/

https://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/tree/net/netfilter/nft_ct.c

Looks like it has simply not been merged yet:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/netfilter/nft_ct.c

Peter

Bug#794890: [Pkg-javascript-devel] Bug#794890: npm: new upstream version

[Jérémy Lal]

2016-11-24 0:42 GMT+01:00 Joerg Jaspert :
> On 14500 March 1977, Michael Prokop wrote:
>
>>> > Overall, I'm not sure we are providing our users something good with
>>> > the current situation. Though what realistic options do we have get
>>> > forward here? Any thoughts?
>
> It neither helps Users nor Debian.
>
>>> Most, if not all, npm dependencies are shipped by upstream "bundled",
>>> meaning they actually take care of updating the dependencies when
>>> doing a release of npm. That means it would be maintainable (and
>>> certainly much easier to do so) by simply distributing all the
>>> bundled submodules as part of the npm debian package - and by
>>> considering the release tarball to be the one distributed on upstream
>>> website, and not the one tagged from the git repository.
>
> Hrm.
>
>>> If ftp masters are all right with this, i'm willing to do the work.
>
> This is an ugly two sided sword.
>
> On the one side we do hate embedded code copies. For good reasons.
>
> On the other side the whole Javascript in Debian is a mess. And while I
> hate JS with a passion, thats not a nice thing to have such a mess.
>
> Now, until now, whenever those tons of little packages got a suggestion
> to make sensible and useful bundles, it got yelled down to "impossible",
> "bad", blabla.
>
> Which I can understand if it means doing it yourself.
>
> Which doesn't seem to be the case here. So taking such an upstream
> bundled package seems to be good.
>
> So yay, go for it.
>
> With a caveat or two:
>
>  - This is not a blanket for having embedded code copies all over the
>place.
>So yes, this should Provide: all those submodules and make them
>usable by whoever depends on it.
>
>  - This must be rebuildable in Debian. That is, the package should, in
>its source, contain what upstreams source uses to build its final
>files. Ie. whatever their build script downloads to bundle the
>files together. Not just the final
>"browserified"/"mangled"/"whateverthecurrentspeakis" version only.
>And be able to redo that build process using them.
>
>  - Good luck in listing the copyrights. :)

Totally agreed. Will try to wrap it this week-end.

Jérémy.

Bug#845459: [Letsencrypt-devel] Bug#845459: certbot: Private keys are stored with world readable

[Harlan Lieberman-Berg]

severity 845459 normal
merge 819107 845459
thanks

Nikolaus Rath  writes:
> Certbot from jessie-backports stores private keys
> (/etc/letsencrypt/archive/*/privkey*.pem) world readable (with 0644
> permissions). It seems to me they really ought to be 0600 instead.

Hello!

Thank you for this report.  This is a known issue, but doesn't have any
impact on security; the directory the keys are in is chmod 700.  We
eventually plan to migrate to the Debian /etc/ssl style structure,
including permissions, however this requires a lot of work and isn't
immediately a priority.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#845490: dput: Please push 0.11.0 to git.debian.org -- the git repo is stale

[Ben Finney]

On Thu, 2016-11-24 10:29 +1100, Ben Finney  wrote:
> I'm inclined to collaborate via separate repositories. Feel free to
> propose changes by merge request from a fork!

This means that the VCS-Git URL should change, but I had not yet settled
on a home for the repository.

For now, it's https://notabug.org/bignose/dput.git>.

-- 
 \
  `\
_o__) Ben Finney 

Bug#845501: rdiff-backup: Does not erase pid on loss of connection

[Arnold Metselaar]

Package: rdiff-backup
Version: 1.2.8-7
Severity: normal

Dear Maintainer,

After an automated backup process failed due to the remote host closing the 
connection, 
subsequent backup processes failed as well because rdiff-backup still checked, 
or tried to check,
whether a process with the process id of the failed backup was running.

I think that rdiff-backup should clear its pidfile whenever it stops due loss 
of connection with the remote host,
or other fatal problems.

Kind regards,
Arnold Metselaar


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

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

Versions of packages rdiff-backup depends on:
ii  libc6  2.19-18+deb8u6
ii  librsync1  0.9.7-10
ii  python 2.7.9-1
ii  python2.7  2.7.9-2+deb8u1

Versions of packages rdiff-backup recommends:
ii  python-pylibacl  0.5.2-1
ii  python-pyxattr   0.5.3-1

rdiff-backup suggests no packages.

-- no debconf information

Bug#794890: [Pkg-javascript-devel] Bug#794890: npm: new upstream version

[Joerg Jaspert]

On 14500 March 1977, Michael Prokop wrote:

>> > Overall, I'm not sure we are providing our users something good with
>> > the current situation. Though what realistic options do we have get
>> > forward here? Any thoughts?

It neither helps Users nor Debian.

>> Most, if not all, npm dependencies are shipped by upstream "bundled",
>> meaning they actually take care of updating the dependencies when
>> doing a release of npm. That means it would be maintainable (and
>> certainly much easier to do so) by simply distributing all the
>> bundled submodules as part of the npm debian package - and by
>> considering the release tarball to be the one distributed on upstream
>> website, and not the one tagged from the git repository.

Hrm.

>> If ftp masters are all right with this, i'm willing to do the work.

This is an ugly two sided sword.

On the one side we do hate embedded code copies. For good reasons.

On the other side the whole Javascript in Debian is a mess. And while I
hate JS with a passion, thats not a nice thing to have such a mess.

Now, until now, whenever those tons of little packages got a suggestion
to make sensible and useful bundles, it got yelled down to "impossible",
"bad", blabla.

Which I can understand if it means doing it yourself.

Which doesn't seem to be the case here. So taking such an upstream
bundled package seems to be good.

So yay, go for it.

With a caveat or two:

 - This is not a blanket for having embedded code copies all over the
   place.
   So yes, this should Provide: all those submodules and make them
   usable by whoever depends on it.

 - This must be rebuildable in Debian. That is, the package should, in
   its source, contain what upstreams source uses to build its final
   files. Ie. whatever their build script downloads to bundle the
   files together. Not just the final
   "browserified"/"mangled"/"whateverthecurrentspeakis" version only.
   And be able to redo that build process using them.

 - Good luck in listing the copyrights. :)

-- 
bye, Joerg

Bug#835127: tellico: Tellico always crashes at boot time

[Luigi]

Package: tellico
Version: 2.3.9+dfsg.1-1.1
Followup-For: Bug #835127

I use a clean install too, a debian unstable; 
it is a different one from the previous email but tellico crashes anyway.
Which informations do you need and how can i retrieve them?

Thanks in advance.
Luigi

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

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

Versions of packages tellico depends on:
ii  kde-runtime4:16.08.2-1
ii  libc6  2.24-6
ii  libexempi3 2.3.0-2
ii  libkabc4   4:4.14.10-7
ii  libkcal4   4:4.14.10-7
ii  libkdecore54:4.14.25-1
ii  libkdeui5  4:4.14.25-1
ii  libkhtml5  4:4.14.25-1
ii  libkio54:4.14.25-1
ii  libknewstuff3-44:4.14.25-1
ii  libkparts4 4:4.14.25-1
ii  libkresources4 4:4.14.10-7
ii  libksane0  4:15.08.3-1
ii  libkxmlrpcclient4  4:4.14.10-7
ii  libnepomuk44:4.14.25-1
ii  libpoppler-qt4-4   0.48.0-2
ii  libqimageblitz41:0.0.6-4
ii  libqjson0  0.8.1-3
ii  libqt4-dbus4:4.8.7+dfsg-11
ii  libqt4-network 4:4.8.7+dfsg-11
ii  libqt4-xml 4:4.8.7+dfsg-11
ii  libqtcore4 4:4.8.7+dfsg-11
ii  libqtgui4  4:4.8.7+dfsg-11
ii  libsolid4  4:4.14.25-1
ii  libstdc++6 6.2.1-4
ii  libtag1v5  1.11.1-0.1
ii  libxml22.9.4+dfsg1-2.1
ii  libxslt1.1 1.1.29-2
ii  libyaz44.2.30-4+b4
ii  tellico-data   2.3.9+dfsg.1-1.1
ii  tellico-scripts2.3.9+dfsg.1-1.1

Versions of packages tellico recommends:
ii  khelpcenter4  4:16.08.2-1
ii  tellico-doc   2.3.9+dfsg.1-1.1

tellico suggests no packages.

-- no debconf information

Bug#845500: nftables: notrack target fails with No such file or directory

[Peter Colberg]

Package: nftables
Version: 0.6+snapshot20161117-2
Severity: normal

Dear Maintainer,

The latest snapshot of nftables adds a notrack target that may
be used to disable connection tracking for selected packets:

#!/usr/sbin/nft -f

flush ruleset

table inet raw {
chain prerouting {
type filter hook prerouting priority -300;
iif lo notrack
}
chain output {
type filter hook output priority -300;
oif lo notrack
}
}

table inet filter {
chain input {
type filter hook input priority 0; policy drop;
ct state established,related,untracked accept
}
chain forward {
type filter hook forward priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
}
}


Loading the above ruleset fails with

# /etc/nftables.conf 
/etc/nftables.conf:5:1-2: Error: Could not process rule: No such file or 
directory
table inet raw {
^^
/etc/nftables.conf:5:1-2: Error: Could not process rule: No such file or 
directory
table inet raw {
^^

I tried both linux-image-4.8.0-1-amd64 and linux-image-4.9.0-rc5-amd64-unsigned.

Regards,
Peter

Bug#845499: lirc: FTBFS on !linux

[Samuel Thibault]

Source: lirc
Version: 0.9.4c-4
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

lirc currently FTBFS on !linux archs because it build-depends on
systemd, hardwires having uinput, and tries to install the systemd
files. The attached first patch fixes this. It also needs a

chmod +x debian/install

to make dh-exec work.

There are however various build issues, the attached patch fixes them.
(upstream had a convoluted way of calling Linux: "!BSD" :) )

Samuel

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

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

-- 
Samuel
/* Amuse the user. */
printk(
"  \\|/  \\|/\n"
"  \"@'/ ,. \\`@\"\n"
"  /_| \\__/ |_\\\n"
" \\__U_/\n");
(From linux/arch/sparc/kernel/traps.c:die_if_kernel())
--- debian/control.original 2016-11-23 22:35:48.0 +
+++ debian/control  2016-11-23 23:33:20.0 +
@@ -14,6 +14,7 @@
  dh-autoreconf,
  dh-systemd,
  dh-python,
+ dh-exec,
  doxygen,
  kmod [linux-any],
  libasound2-dev [linux-any kfreebsd-any],
@@ -28,7 +29,7 @@
  portaudio19-dev,
  python3,
  python3-yaml,
- systemd,
+ systemd [linux-any],
  xsltproc
 # libjs-jquery
 
--- debian/rules.original   2016-11-23 23:02:38.0 +
+++ debian/rules2016-11-23 23:02:39.0 +
@@ -9,8 +9,10 @@
 override_dh_autoreconf:
dh_autoreconf $(CURDIR)/autogen.sh
 
+ifeq ($(DEB_HOST_ARCH_OS),linux)
 override_dh_auto_configure:
dh_auto_configure -- HAVE_UINPUT=1
+endif
 
 override_dh_shlibdeps:
dh_shlibdeps -l $(CURDIR)/debian/tmp/usr/lib/*/lirc/plugins
--- debian/install.original 2016-11-23 23:13:41.0 +
+++ debian/install  2016-11-23 23:13:43.0 +
@@ -1,5 +1,6 @@
+#! /usr/bin/dh-exec
 etc/lirc
-lib/systemd/*
+[linux-any] lib/systemd/*
 usr/lib/*/python3*/*
 usr/lib/tmpfiles.d/*
 usr/lib/*/lirc
Index: lirc-0.9.4c/Makefile.am
===
--- lirc-0.9.4c.orig/Makefile.am
+++ lirc-0.9.4c/Makefile.am
@@ -38,7 +38,7 @@ dist_lirc_conf_DATA = lircd.conf \
 lircdconfigdir = $(sysconfdir)/lirc/lircd.conf.d
 dist_lircdconfig_DATA  = README.conf.d 
 
-if !BSD
+if LINUX
 dist_lircdconfig_DATA  += devinput.lircd.conf
 endif
 
Index: lirc-0.9.4c/configure.ac
===
--- lirc-0.9.4c.orig/configure.ac
+++ lirc-0.9.4c/configure.ac
@@ -19,7 +19,7 @@ AC_PATH_PROG(SH_PATH,[sh])
 AC_CHECK_PROGS([MODINFO], [modinfo], [no], [$PATH:/sbin:/usr/sbin])
 if test x$MODINFO = xno; then
   AC_MSG_WARN(["No modinfo command found - skipping kernel drivers."])
-  MODINFO="/usr/bin/false"
+  MODINFO="/bin/false"
 else
   MODINFO=$( PATH=$PATH:/sbin:/usr/sbin which modinfo )
 fi
@@ -93,11 +93,13 @@ case $host_os in
;;
 *bsd*) osflags='-DFREEBSD'
;;
+linux*) osflags='-DLINUX'
+   ;;
 *)  osflags=''
 esac
 
 AM_CONDITIONAL([DARWIN], [test "$osflags" = "-DDARWIN"])
-AM_CONDITIONAL([BSD], [test -n "$osflags"])
+AM_CONDITIONAL([LINUX], [test "$osflags" = "-DLINUX"])
 AC_SUBST(osflags)
 
 x_progs="irxevent xmode2"
@@ -514,7 +516,7 @@ AC_REPORT_CONDITIONAL([SYSTEMD_INSTALL])
 AC_REPORT_CONDITIONAL([DEVEL])
 AC_REPORT_CONDITIONAL([HAVE_UINPUT])
 AC_REPORT_CONDITIONAL([DARWIN])
-AC_REPORT_CONDITIONAL([BSD])
+AC_REPORT_CONDITIONAL([LINUX])
 
 echo
 
Index: lirc-0.9.4c/lib/Makefile.am
===
--- lirc-0.9.4c.orig/lib/Makefile.am
+++ lirc-0.9.4c/lib/Makefile.am
@@ -104,7 +104,7 @@ input_map.lo: lirc/input_map.inc
 
 input_map.inc: lirc/input_map.inc
 
-if BSD
+if !LINUX
 lirc/input_map.inc:
touch $@
touch touch input_map.inc
Index: lirc-0.9.4c/plugins/Makefile.am
===
--- lirc-0.9.4c.orig/plugins/Makefile.am
+++ lirc-0.9.4c/plugins/Makefile.am
@@ -41,7 +41,7 @@ srm7500libusb_la_SOURCES= srm7500lib
 srm7500libusb_la_LDFLAGS= $(AM_LDFLAGS) @usb_libs@
 srm7500libusb_la_CFLAGS = $(AM_CFLAGS) $(LIBUSB_CFLAGS)
 
-if !BSD
+if LINUX
 plugin_LTLIBRARIES  += commandir.la
 commandir_la_SOURCES= commandir.c
 commandir_la_LDFLAGS= $(AM_LDFLAGS) @usb_libs@
@@ -113,7 +113,7 @@ osx_usbraw_la_SOURCES   = osx_usbraw
 osx_usbraw_la_LDFLAGS   = $(AM_LDFLAGS) -framework IOKit -framework Cocoa
 endif
 
-if !BSD
+if LINUX
 plugin_LTLIBRARIES  += default.la
 defa

Bug#845497: liblasi-dev: has packaging issues with dependencies

[Alan W. Irwin]

Package: liblasi-dev
Version: 1.1.0-1.1
Severity: normal

Dear Maintainer,

The Depends: line for liblasi-dev is incomplete, i.e., only the
corresponding library package is mentioned now.  Although, I only have
the Debian stable version installed, I notice this bad situation
persists in the unstable version of this package (see
).

This package is linked to the pango/cairo subset of the GTK+ suite of
libraries so at minimum you should add the appropriate libpango
development package (libpango1.0-dev in sid) to the dependencies of this 
package.
That package in turn depends on libcairo2-dev (amongst many others)
which in turn depends on libfreetype6-dev (amongst many others).

As a result of this liblasi-dev dependency bug, one well-known PLplot
developer (Hazen Babcock) has recently reported a PLplot build bug on
Ubuntu due to this situation.  He had liblasi-dev installed, but not
libfreetype6-dev and the result was the following build error for the
psttf device driver (which depends on liblasi):

> Scanning dependencies of target psttf
> [ 20%] Building CXX object drivers/CMakeFiles/psttf.dir/psttf.cc.o
> In file included from
> /home/travis/build/HazenBabcock/PLplot/drivers/psttf.cc:44:0:
> /usr/include/LASi.h:14:30: fatal error: freetype/ftglyph.h: No such file or 
> directory
> compilation terminated.
> make[2]: *** [drivers/CMakeFiles/psttf.dir/psttf.cc.o] Error 1
> make[1]: *** [drivers/CMakeFiles/psttf.dir/all] Error 2
> make: *** [all] Error 2

Addressing this dependency issue for the liblasi-dev package should
solve this build bug (which of course can be worked around for now by
installing libfreetype6-dev and any other missing liblasi-dev direct
or indirect development package dependencies).

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

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

Versions of packages liblasi-dev depends on:
ii  liblasi0  1.1.0-1.1

liblasi-dev recommends no packages.

liblasi-dev suggests no packages.

-- no debconf information

Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[Ben Longbons]

Package: fp-compiler-3.0.0
Version: 3.0.0+dfsg-9
Severity: wishlist
File: /usr/bin/fpc-3.0.0

Dear Maintainer,

According to `fpc -help`,
-P  Set target CPU 
(arm,avr,i386,jvm,m68k,mips,mipsel,powerpc,powerpc64,sparc,x86_64)

However, if I try any of those besides the current CPU, I get:

Error: ppc386 can't be executed, error message: Failed to execute "ppc386", 
error code: 127

(note: while, multiarch would work for x86_64 -> i386, it won't work for
anything else, so you really do need a native ppc386 binary, etc)

You'll probably have to also tell it to use ${triple}-ld, etc.


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

Kernel: Linux 4.7.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 fp-compiler-3.0.0 depends on:
ii  binutils   2.27.51.20161108-1
ii  debconf [debconf-2.0]  1.5.59
ii  fp-units-rtl-3.0.0 3.0.0+dfsg-9
ii  libc6  2.24-5

Versions of packages fp-compiler-3.0.0 recommends:
ii  fp-utils-3.0.0  3.0.0+dfsg-9

Versions of packages fp-compiler-3.0.0 suggests:
pn  fp-docs-3.0.0 
pn  mingw32-binutils  

-- debconf information excluded

Bug#845490: dput: Please push 0.11.0 to git.debian.org -- the git repo is stale

[Ben Finney]

On Wed, 2016-11-23 16:55 -0500, Daniel Kahn Gillmor
 wrote:
> the git repo at https://anonscm.debian.org/git/collab-maint/dput.git
> only has tags up to release/0.10.2 -- please the push the latest work
> to the git repo to make it easier to collaborate!

I'm inclined to collaborate via separate repositories. Feel free to
propose changes by merge request from a fork!

-- 
 \
  `\
_o__) Ben Finney 

Bug#845496: /var/log/syslog spam host brltty[204]: file system mount error: usbfs[brltty-usbfs] -> /var/run/brltty/usbfs: No such device

[Patrick Schleizer]

Package: brltty
Severity: normal
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

brltty keeps spamming /var/log/syslog.

host brltty[204]: file system mount error: usbfs[brltty-usbfs] ->
/var/run/brltty/usbfs: No such device

Like 20 messages every 2 minutes or so.

Running on Debian jessie (Whonix) inside a VirtualBox VM.

Cheers,
Patrick

Bug#844081: Reproducer

[Filip Pytloun]

On 2016/11/24 00:00, Santiago Vila wrote:
> Try using a chroot without union-type=overlay.

Unfortunately it will result in the same error :-/


signature.asc
Description: Digital signature

Bug#845495: src:python-tz: Non-maintainer upload of python-tz/2016.7-0.1 to DELAYED/5

[Hilko Bengen]

Package: src:python-tz
Severity: normal

Dear Maintainer,

I have just uploaded version 2016.7-0.1 to DELAYED/5. Other than
importing a new upstream version, I have made some changes to the
package, including fixing RC bug #839460. Patches over 2015.7+dfsg-0.1
are attached.

Feel free to reschedule or cancel my upload as you see fit.

Cheers,
-Hilko
>From 14ed4482253c54f81cabf605f68236b0eb2e9873 Mon Sep 17 00:00:00 2001
From: Hilko Bengen 
Date: Wed, 23 Nov 2016 23:22:59 +0100
Subject: [PATCH 1/5] Add tzdata build-dependency (Closes: #839460)

---
 debian/control | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index b272261..bbac7af 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,8 @@ Build-Depends: debhelper (>= 7.0.50~), dh-python,
python-all (>= 2.6.6-3~),
python3-all,
python-setuptools,
-   python3-setuptools
+   python3-setuptools,
+   tzdata,
 Standards-Version: 3.9.3
 Homepage: http://pypi.python.org/pypi/pytz/
 X-Python-Version: >= 2.4
-- 
2.10.2

>From 54f3b591b049a2d193271f5574d96f887cbac5f8 Mon Sep 17 00:00:00 2001
From: Hilko Bengen 
Date: Wed, 23 Nov 2016 23:24:47 +0100
Subject: [PATCH 2/5] Bump Standards-Version

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index bbac7af..fc95c2b 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Build-Depends: debhelper (>= 7.0.50~), dh-python,
python-setuptools,
python3-setuptools,
tzdata,
-Standards-Version: 3.9.3
+Standards-Version: 3.9.8
 Homepage: http://pypi.python.org/pypi/pytz/
 X-Python-Version: >= 2.4
 X-Python3-Version: >= 3.1
-- 
2.10.2

>From 5231d4140042e5ee6cbbf57f0bcbdef0dbf31a91 Mon Sep 17 00:00:00 2001
From: Hilko Bengen 
Date: Wed, 23 Nov 2016 23:28:49 +0100
Subject: [PATCH 3/5] Bump Debhelper version, simplify debian/rules

---
 debian/compat |  2 +-
 debian/control|  2 +-
 debian/python-tz.install  |  1 +
 debian/python3-tz.install |  1 +
 debian/rules  | 37 ++---
 5 files changed, 6 insertions(+), 37 deletions(-)
 create mode 100644 debian/python-tz.install
 create mode 100644 debian/python3-tz.install

diff --git a/debian/compat b/debian/compat
index 7f8f011..ec63514 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-7
+9
diff --git a/debian/control b/debian/control
index fc95c2b..eafaa56 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: optional
 Maintainer: Debian/Ubuntu Zope Team 
 Uploaders: Brian Sutherland ,
Fabio Tranchitella 
-Build-Depends: debhelper (>= 7.0.50~), dh-python,
+Build-Depends: debhelper (>= 9~), dh-python,
python-all (>= 2.6.6-3~),
python3-all,
python-setuptools,
diff --git a/debian/python-tz.install b/debian/python-tz.install
new file mode 100644
index 000..dbdb301
--- /dev/null
+++ b/debian/python-tz.install
@@ -0,0 +1 @@
+/usr/lib/python2*
diff --git a/debian/python3-tz.install b/debian/python3-tz.install
new file mode 100644
index 000..fef6392
--- /dev/null
+++ b/debian/python3-tz.install
@@ -0,0 +1 @@
+/usr/lib/python3*
diff --git a/debian/rules b/debian/rules
index 399f7d5..f1d5e38 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,43 +1,10 @@
 #!/usr/bin/make -f
 
-PACKAGE=python-tz
-PACKAGE_PYTHON3=python3-tz
-
-PYVERS:=$(shell pyversions -r)
-PY3VERS:=$(shell py3versions -r)
-
 %:
-	dh --with python2 --with python3 $@
-
-override_dh_auto_build:
-	dh_auto_build -p$(PACKAGE)
-
-	set -e; \
-	for python in $(PY3VERS); do \
-		$$python setup.py build; \
-	done
-
-override_dh_auto_install:
-	dh_auto_install -p$(PACKAGE) --destdir=$(CURDIR)/debian/$(PACKAGE)
-
-	set -ex; \
-	for python in $(PY3VERS); do \
-		$$python setup.py install --install-layout=deb \
-			--root=$(CURDIR)/debian/$(PACKAGE_PYTHON3); \
-	done
-
-override_dh_auto_test:
-	python -m unittest discover -v pytz/tests
-	for python in $(PY3VERS); do \
-	$$python -m unittest discover -v pytz/tests; \
-	done
-
-override_dh_clean:
-	dh_clean
-	rm -rf build
+	dh $@ --with=python2,python3 --buildsystem=pybuild
 
 override_dh_install:
-	dh_install
+	dh_install --fail-missing
 
 	# install our testing package
 	install -D debian/test-pytz debian/python-tz/usr/lib/python-tz/test-pytz.py
-- 
2.10.2

>From 440b2bdfee582ab92395acfaade527faf53052de Mon Sep 17 00:00:00 2001
From: Hilko Bengen 
Date: Wed, 23 Nov 2016 23:41:14 +0100
Subject: [PATCH 4/5] Re-enable, rebase zoneinfo patch

---
 debian/patches/series |  1 +
 debian/patches/tzdata | 49 +
 2 files changed, 26 insertions(+), 24 deletions(-)

diff --git a/debian/patches/series b/debian/patches/series
index e69de29..0883ff0 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -0,0 +1 @@
+tzda

Bug#845201: [Pkg-rust-maintainers] Patch for Lintian updates for Rust packaging in /usr/share/cargo/registry

[Josh Triplett]

On Wed, Nov 23, 2016 at 01:47:49PM +0100, Sylvestre Ledru wrote:
> Le 23/11/2016 à 12:58, Josh Triplett a écrit :
> > Control: tags -1 + patch
> > 
> > The attached patch implements these changes.
>  Having a test would be great!
> Thanks for doing that

Done; new patch attached.

- Josh Triplett
>From 138d46ba4520aa54c483d0e334fb1d99c42d4537 Mon Sep 17 00:00:00 2001
From: Josh Triplett 
Date: Wed, 23 Nov 2016 03:48:50 -0800
Subject: [PATCH] Exclude files under /usr/share/cargo/registry/ from a few
 checks

That directory contains unmodified upstream sources.
(Closes: #845201)
---
 checks/files.pm| 5 -
 checks/scripts.pm  | 1 +
 debian/changelog   | 5 +
 t/tests/files-package-contains-foo/debian/debian/rules | 6 ++
 4 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/checks/files.pm b/checks/files.pm
index b19b3bf..50b6381 100644
--- a/checks/files.pm
+++ b/checks/files.pm
@@ -1218,6 +1218,8 @@ sub run {
 and not $fname =~ m,^usr/share/man/(?:[^/]+/)?man\d/,o
 # liblicense (again)
 and not $fname =~ m,^usr/share/pyshared-data/,o
+# Rust crate unmodified upstream sources
+and not $fname =~ m,^usr/share/cargo/registry/,o
 # Some GNOME/GTK software uses these to show the "license
 # header".
 and not $fname =~ m,
@@ -1365,7 +1367,8 @@ sub run {
 }
 
 #  vcs control files
-if ($fname =~ m,$VCS_FILES_OR_ALL,) {
+if ($fname =~ m,$VCS_FILES_OR_ALL,
+and $fname !~ m,^usr/share/cargo/registry/,) {
 tag 'package-contains-vcs-control-file', $file;
 }
 
diff --git a/checks/scripts.pm b/checks/scripts.pm
index f40fddd..bf1700f 100644
--- a/checks/scripts.pm
+++ b/checks/scripts.pm
@@ -311,6 +311,7 @@ sub run {
 or $filename =~ m,^usr/(?:lib|share)/.*\.pm,
 or $filename =~ m,^usr/(?:lib|share)/.*\.py,
 or $filename =~ m,^usr/(?:lib|share)/ruby/.*\.rb,
+or $filename =~ m,^usr/share/cargo/registry/,
 or $filename =~ m,^usr/share/debconf/confmodule(?:\.sh)?$,
 or $filename =~ m,\.in$,
 or $filename =~ m,\.erb$,
diff --git a/debian/changelog b/debian/changelog
index eeeaef0..1c87d05 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -20,6 +20,11 @@ lintian (2.5.50) UNRELEASED; urgency=medium
   * data/files/privacy-breaker-websites:
 + [BR] Detect more logos.
 
+  * checks/{files,scripts}.pm:
++ [JT] Exclude files under /usr/share/cargo/registry/ from a few checks,
+  as that directory contains unmodified upstream sources.
+  (Closes: #845201)
+
  -- Niels Thykier   Wed, 26 Oct 2016 20:42:18 +
 
 lintian (2.5.49) unstable; urgency=medium
diff --git a/t/tests/files-package-contains-foo/debian/debian/rules b/t/tests/files-package-contains-foo/debian/debian/rules
index e90d722..03bb6b8 100644
--- a/t/tests/files-package-contains-foo/debian/debian/rules
+++ b/t/tests/files-package-contains-foo/debian/debian/rules
@@ -49,3 +49,9 @@ override_dh_install:
 	mkdir -p $(SHARE)/cmake-3.1/Modules
 	touch $(SHARE)/cmake-3.1/FindFoo.cmake
 	touch $(SHARE)/cmake-3.1/Modules/FindVar.cmake
+
+	# Ignored Cargo sources
+	mkdir -p $(SHARE)/cargo/registry/crate-1.0.0
+	touch $(SHARE)/cargo/registry/crate-1.0.0/.gitignore
+	touch $(SHARE)/cargo/registry/crate-1.0.0/LICENSE
+	echo '#!/bin/sh' > $(SHARE)/cargo/registry/crate-1.0.0/test.sh
-- 
2.10.2

Bug#845471: ITP: java-diff-utils -- library for computing diffs, applying patches, and generation of side-by-side view in Java

[Wookey]

On 2016-11-23 12:17 -0800, tony mancill wrote:
> On Wed, Nov 23, 2016 at 07:47:51PM +, Wookey wrote:
> > On 2016-11-23 11:06 -0800, tony mancill wrote:
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: tony mancill 
> > > 
> > > * Package name: java-diff-utils
> > 
> > OK. So my copyright file contains this:
> > 
> > Upstream-contact: Dmitry Naumenko 
> > Source: http://code.google.com/p/java-diff-utils/
> > Comment: Much of this code was derived from JRCS, written by Juancarlo Añez
> >  , which was originally Apache-1.1 and later
> >  relicenced to LGPL-2.1. This version was derived from the 2003.06 LGPL
> >  vintage of JRCS at http://code.google.com/p/jrcs. Clarified in emails
> >  from Juancarlo Añez and Dmitry Naumenko. This is inconsistent with
> >  the headers provided by upstream at
> >  http://code.google.com/p/java-diff-utils/
> > 
> > Files: *
> > Copyright: Copyright 2010 Dmitry Naumenko 
> > License: Apache-2.0
> > 
> > Files: test/*
> > Copyright: Copyright 2010 Dmitry Naumenko 
> > License: GPL-v3+
> > 
> > Files: diffutils/myers/*
> > Copyright: Copyright 1999-2003 The Apache Software Foundation
> > License: LGPL-2.1
> > 
> > This tooks me weeks to sort out IIRC, so that should be helpful. I did this
> > in 2013 for v1.2.1 so you will need to update for 2.1.1
> 
> 
> You bring up a good point regarding the license.  I am adding Oliver
> Kopp to the cc: so he is aware of potential license implications for
> JabRef. 

From memory and looking at the file here, I think the issue is
that Dmitry claimed java-diff-utils is all apache2, but it was forked
after Juancarlo had changed the license from apache 1.1 to
lgpl2.1. Dmitry can't just change this unilaterally (from either
apache or from lgpl2.1). So for the code that is defo as-is (the myers
stuff) that's still LGPL2.1.

I found the original mail thread and will forward it in a
mo. Juancarlos suggested that I just use his (jrcs) version because
the licencing on that was clear, but that didn't suit upstream. Dmitry
only replied once to say that he'd derived from the LGPL version in
2010, but if that's true then the headers on his release are all
wrong. I don't know if he's fixed that since 2013.

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


signature.asc
Description: Digital signature

Bug#845442: udev: does not honor configuration files in /etc/udev/hwdb.d

[Norbert Preining]

Hi Michael,

thanks for taking this up.

> > /etc/udev/hwdb.d/61-keyboard-local.hwdb
> > containing:
> > evdev:input:b0003v045Ep00DB*
> >  KEYBOARD_KEY_c022d=pageup
> >  KEYBOARD_KEY_c022e=pagedown
> > to remap the default "zoomin" and "zoomout" to pageup and pagedown.
> > 
> > And indeed, after doing:
> > udevadm hwdb --update
> > udevadm trigger /dev/input/eventXX
> > and unplugging/replugging the keyboard the additional key
> > can be used for scrolling.
> > 
> 
> Do you have a /etc/udev/hwdb.bin?

Yes.

> If so, udev should use that one instead of the one from
> /lib/udev/hwdb.bin. Can you provide us with a debug log from udev and/or
> strace.

Output of journalctl with udev log level set to debug is attached.

Few words about my setup: system is on whole disk md_crypt and
initramfs uncrypts it and then uses the partitions from there 
including /

All the best

Norbert

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


journal.log.gz
Description: application/gzip

Bug#845494: emacs-goodies-el: minibuffer-complete-cycle.el make-overlay in xemacs21

[Kevin Ryde]

Package: emacs-goodies-el
Version: 36.3
Severity: normal
File: /usr/share/emacs/site-lisp/emacs-goodies-el/minibuffer-complete-cycle.el

minibuffer-complete-cycle.el uses make-overlay which is not pre-loaded
in xemacs 21.4.24-4,

xemacs -q
C-x C-f
=>
Symbol's function definition is void: make-overlay

It worked for me to do

(require 'overlay)

which brings the compatibilty into xemacs, and is ok for emacs too (or
do it when not fboundp make-overlay if preferred).  But I don't know if
minibuffer-complete-cycle.el is actually meant for xemacs.  If not then
of course would skip entirely in the usual way.

Has this arisen because now an autoload puts mcc-define-keys into
minibuffer-setup-hook by default (where it didn't before)?
Would that be a matter of user preference, or is it always helpful,
or never harmful, etc ...?


-- System Information:
Debian Release: stretch/sid
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages emacs-goodies-el depends on:
ii  bash   4.4-2
ii  dpkg   1.18.15
ii  emacs  46.1
ii  emacs23-lucid [emacsen]23.4+1-4.1+b1
ii  emacs24-lucid [emacsen]24.5+1-7
ii  emacsen-common 2.0.8
ii  install-info   6.3.0.dfsg.1-1+b1
ii  xemacs21-mule [emacsen]21.4.24-4
ii  xemacs21-mule-canna-wnn [emacsen]  21.4.24-4

Versions of packages emacs-goodies-el recommends:
ii  perl-doc  5.24.1~rc3-3
ii  wget  1.18-4

emacs-goodies-el suggests no packages.

-- no debconf information

Bug#844822: xymon: FTBFS: build-dependency not installable: libssl-dev (>= 1.0.2d-2~)

[Axel Beckert]

Control: unblock -1 by 828236
Control: reassign -1 apache2-dev
Control: forcemerge 845033 -1

Hi,

Axel Beckert wrote:
> Lucas Nussbaum wrote:
> > > Merged Build-Depends: debhelper (>= 9~), dh-apache2, dpkg-dev (>= 
> > > 1.16.1~), imagemagick, libc-ares-dev, libldap2-dev (>= 2.4.25-2~), 
> > > libpcre3-dev (>= 8.12-4~), librrd-dev, libssl-dev (>= 1.0.2d-2~), 
> > > po-debconf, procps
> > > Filtered Build-Depends: debhelper (>= 9~), dh-apache2, dpkg-dev (>= 
> > > 1.16.1~), imagemagick, libc-ares-dev, libldap2-dev (>= 2.4.25-2~), 
> > > libpcre3-dev (>= 8.12-4~), librrd-dev, libssl-dev (>= 1.0.2d-2~), 
> > > po-debconf, procps
> [...]
> > > The following packages have unmet dependencies:
> > >  sbuild-build-depends-xymon-dummy : Depends: libssl-dev (>= 1.0.2d-2~) 
> > > but it is not going to be installed
> 
> This is because apache2-dev (which provides dh-apache2) depends on
> "libssl1.0-dev | libssl-dev (<< 1.1)". So the reason are conflicting
> build-dependencies because some build-dependencies are ready for
> OpenSSL 1.1 and others are not.
> 
> I'm not sure if this is really an issue of xymon. It could be
> workarounded by using "libssl1.0-dev | libssl-dev" in xymon, but then
> xymon in Debian needlessly would be build against OpenSSL 1.0.x which
> I at most consider a temporary solution.

This has been fixed in the apache2 source package by splitting off an
apache2-ssl-dev package from apache2-dev. Merging this bug report with
#845033 (https://bugs.debian.org/845033) as it has been done with the
according FTBFS bug report against cgit.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#844081: Reproducer

[Santiago Vila]

On Wed, Nov 23, 2016 at 11:34:41PM +0100, Filip Pytloun wrote:
> So I got access to affected host and was able to reproduce it there.
> Spent some time debugging it and unfortunately I am still clueless why this is
> happening.
> 
> Found out that it doesn't matter if eatmydata is used or not, test is
> occasionally failing in both cases.
> 
> I tried my patch and it didn't help - even when I raised the sleep to 5
> seconds or call coll.update_db() multiple times it's failing with the same
> error.
> 
> ICS file seems to be correctly written on disk:
> 
>   File:
>   
> '/tmp/pytest-of-filip/pytest-63/test_default_calendar1/foobar/0c9c883e-21a7-447b-b218-54f7e667aa87.ics'
> Size: 282 Blocks: 8  IO Block: 4096   regular file
> Device: fe01h/65025dInode: 516304  Links: 1
> Access: (0600/-rw---)  Uid: ( 1000/   filip)   Gid: ( 1000/   filip)
> Access: 2016-11-23 22:29:28.086145354 +
> Modify: 2016-11-23 22:29:28.086145354 +
> Change: 2016-11-23 22:29:28.086145354 +
>  Birth: -
> 
> Any ideas how to debug this or what more to try?

Try using a chroot without union-type=overlay.

Thanks.

Bug#842291: notmuch processes frequently stuck in select()

[David Bremner]

Daniel Kahn Gillmor  writes:
>
>  0) turn off CRL updates entirely during s/mime signature verification
>
>  1) do s/mime signature verification without CRL updates, but schedule
> CRL checks to happen in the background for dirmngr, so that future
> verifications will reflect the cert validity
>
>  2) have dirmngr avoid checking CRLs that it knows it has already
> updated recently
>
>  3) tell dirmngr to use much shorter CRL fetch timeouts
>

>
> Any thoughts on the best way to pursue this?
>
> --dkg

Maybe the issue is in gmime's usage of gpgme. If I understand correctly
(which is far from a sure thing), pkcs7_verify calls gpgme_op_verify
which is synchronous, and (apparently) does not support timeouts. An
alternate strategy would be to call gpgme_op_verify_start, and then call
gpgme_wait, which has a nonblocking mode. I don't really understand the
S/MIME model, but naively it seems OK for signature verification to fail
if the CRL check doesn't finish quickly.

d

Bug#845493: g++-6: Internal compiler error in tsubst, at cp/pt.c:13073

[Daniel Schepler]

Package: g++-6
Version: 6.2.0-13
Severity: minor

While developing a custom implementation of std::make_index_sequence
for compatibility with previous versions of gcc, I ran into an
internal compiler error.  I'm attaching the output of creduce on the
source code, which still gives the same ICE.

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

Kernel: Linux 4.8.0-1-amd64 (SMP w/8 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 g++-6 depends on:
ii  gcc-66.2.0-13
ii  gcc-6-base   6.2.0-13
ii  libc62.24-5
ii  libgmp10 2:6.1.1+dfsg-1
ii  libisl15 0.17.1-1
ii  libmpc3  1.0.3-1
ii  libmpfr4 3.1.5-1
ii  libstdc++-6-dev  6.2.0-13
ii  zlib1g   1:1.2.8.dfsg-2+b3

g++-6 recommends no packages.

Versions of packages g++-6 suggests:
pn  g++-6-multilib
pn  gcc-6-doc 
pn  libstdc++6-6-dbg  

-- no debconf information
typedef long unsigned a;
template  struct b;
template  struct b { typedef p c; };
template  using e = typename b::c;
template  struct g;
template  struct h;
template  struct h> { using c = g; };
template  struct j;
template  struct j> {
  using c = g;
};
template  struct k;
template  struct k> { using c = g; };
template  struct k> {
  using c = typename h::c>::c;
};
template  struct k> {
  using c = typename j::c>::c;
};
template  using m = typename k::c;
template  template  using n = g;
template  using o = m;
template  void increasing(n) {
  increasing(o<10>{});
}

Bug#845468: RFS: qtstyleplugins-src/5.0.0+git20161024-0.1 [NMU]

[Pino Toscano]

In data mercoledì 23 novembre 2016 22:45:24 CET, Gianfranco Costamagna ha 
scritto:
> thanks Pino for taking care of it, I hope it will save some of your time,
> I know Mateusz has good skills and good intentions, just maybe he didn't
> pay much attention to the policy :)

This has nothing to do with "policy", but with common sense and
cooperation: if I want to work on some package, I don't just blindly
NMU it without even bothering to work (nor even contact) the active
maintainers of it. This is called hijacking.

-- 
Pino Toscano

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

Bug#845468: RFS: qtstyleplugins-src/5.0.0+git20161024-0.1 [NMU]

[Gianfranco Costamagna]

control: close -1


ciao Pino,

>"my"? Since when? I don't see your name neither in Maintainer nor
>Uploaders, and there are no other forms of cooperation with us about
>this.


please don't pay much attention to this, it is something "autogenerated"
by debexpo and mentors website :)

>... and noone of the packagers got any request for this.
>Mateusz, RFS is *not* supposed to be a maintainer hijack -- the usual
>way of *cooperating* with existing maintainers still works.


NMU isn't a package hijack, but you are right :)

>Next weekend, yes. And even if I cannot personally, there are other
>people of the debian-qt-kde team who can help with this.
>(Which means: Gianfranco, please do not NMU this at all.)


I owned the bug and tagged it moreinfo just for this reason: I don't
want to NMU it, and I want to avoid other people doing that.
Now, that you have answered, we can close this request.

Mateusz, please read the NMU policy [1] [2], about putting debdiff in the bug
you are closing, keeping changes minimal, giving the maintainer enough
time to answer and so on
[1] https://wiki.debian.org/NonMaintainerUpload

[2] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu

thanks Pino for taking care of it, I hope it will save some of your time,
I know Mateusz has good skills and good intentions, just maybe he didn't
pay much attention to the policy :)

thanks again,

Gianfranco

Bug#844666: libpam-ldap-186: regression: reads from the wrong conf file

[Brian Kroth]

FYI, the patch I had attached last time is wrong.  I'd just copied and 
pasted from the old one, but that used cdbs, whereas this doesn't.  I 
think this one should be better, though I'm no packaging expert.


Let me know if you have any comments or questions.

Thanks,
Brian
diff -u -ruN pam-ldap.bak/libpam-ldap-186/debian/changelog pam-ldap/libpam-ldap-186.cae/debian/changelog
--- pam-ldap.bak/libpam-ldap-186/debian/changelog	2016-04-09 16:14:51.0 -0500
+++ pam-ldap/libpam-ldap-186.cae/debian/changelog	2016-11-23 14:42:06.996563643 -0600
@@ -1,3 +1,15 @@
+libpam-ldap (186-1+caejessie3) cae-jessie-backports; urgency=medium
+
+  * Non-maintainer upload.
+  * Backporting for jessie (RT #430785).
+  * Also update debian/rules to use the old /etc/pam_ldap.conf file by default
+instead of /etc/ldap.conf
+  * Fixup build rules for pure dh instead of cdbs.
+  * Don't let it copy the /etc/ldap.conf file in - let debconf handle that as
+before.
+
+ -- Brian Kroth   Fri, 28 Oct 2016 17:13:57 -0500
+
 libpam-ldap (186-1) unstable; urgency=medium
 
   * New upstream release
diff -u -ruN pam-ldap.bak/libpam-ldap-186/debian/rules pam-ldap/libpam-ldap-186.cae/debian/rules
--- pam-ldap.bak/libpam-ldap-186/debian/rules	2016-04-04 00:47:35.0 -0500
+++ pam-ldap/libpam-ldap-186.cae/debian/rules	2016-11-23 14:42:29.804817626 -0600
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+#export DH_VERBOSE=1
+
 export DEB_BUILD_MAINT_OPTIONS= hardening=+bindnow
 
 %:
@@ -7,4 +9,30 @@
 
 override_dh_auto_configure:
 	dh_auto_configure -- --libdir=/lib/$(DEB_HOST_MULTIARCH) \
-	--with-ldap-lib=openldap
+	--with-ldap-lib=openldap \
+	--with-ldap-conf-file=/etc/pam_ldap.conf \
+	--with-ldap-secret-file=/etc/pam_ldap.secret
+
+override_dh_install:
+	dh_install
+	
+	# remove the provided ldap.conf file from /etc
+	# (the old debian package didn't provide one directly either)
+	rm -f debian/libpam-ldap/etc/ldap.conf
+	rm -f debian/libpam-ldap/etc/pam_ldap.conf
+	# same goes for the ldap.secret file
+	rm -f debian/libpam-ldap/etc/ldap.secret
+	rm -f debian/libpam-ldap/etc/pam_ldap.secret
+	# rename man page
+	mv debian/libpam-ldap/usr/share/man/man5/pam_ldap.5 \
+		debian/libpam-ldap/usr/share/man/man5/pam_ldap.conf.5
+	# change all references from /etc/ldap.{conf,secret} to /etc/pam_ldap.{conf,secret}
+	for file in debian/libpam-ldap/usr/share/man/man5/pam_ldap.conf.5 \
+	debian/libpam-ldap/usr/share/libpam-ldap/ldap.conf \
+	debian/libpam-ldap/usr/share/doc/libpam-ldap/examples/chfn \
+	debian/libpam-ldap/usr/share/doc/libpam-ldap/examples/chsh ; do \
+		sed	-e 's,ldap.conf,pam_ldap.conf,' \
+			-e 's,ldap.secret,pam_ldap.secret,' \
+			< $$file > $$file-sed; \
+		mv $$file-sed $$file; \
+	done

Bug#844938: The new node-tap is causing FTBFS in node-inline-source-map

[Jérémy Lal]

2016-11-23 21:47 GMT+01:00 Ross Gammon :
> tag 844938 + upstream
> forwarded 844938 https://github.com/thlorenz/inline-source-map/issues/18
> thanks
>
> Hi,
>
> I have just investigated what has changed that might be causing this
> failure of the upstream testsuite, and it appears to be the recent
> update of node-tap to Version 8.0.0.
>
> The bug has been passed upstream
> (https://github.com/thlorenz/inline-source-map/issues/18), but if there
> are any node-tap experts reading this, I would be grateful for a patch
> to send there (as the Stretch release is looming).

Done !

Bug#549089: apt: Please add support for temporary packages

[Tianon Gravi]

On 23 November 2016 at 14:37, Tianon Gravi  wrote:
> I realized that a clean way to handle this would be some way to just
> tell "apt-get install" to _not_ mark the packages as manually
> installed -- if they're already marked, leave their markings alone,
> otherwise mark them as auto (akin to Gentoo's "emerge --oneshot" or
> what's possible with Alpine's "apk --virtual").  This way, new
> packages could be installed willy nilly, and easily removed with
> "apt-get autoremove".
>
> I can mimic this behavior currently by doing some dancing with
> "apt-mark" before and after install, but it'd be really awesome if APT
> itself had either a flag or a "-o" option for adjusting the package
> marking behavior.
>
> If it seems like this is really a separate wishlist item (and not as
> overlapping as I thought), I'm also happy to file a new wishlist issue
> instead. :)

Looks like this is already essentially what's suggested over in
#745769, but if I'm right in my hunch that the use cases are
reasonably overlapping, the two could probably be combined (or marked
fixed by the same feature addition). :)


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

Bug#549089: apt: Please add support for temporary packages

[Tianon Gravi]

On Wed, 30 Sep 2009 19:34:58 +0200 Gabriele Tozzi
 wrote:
> It would be nice to having a function to mark a package (and all it's
> automatically installed dependencies) as "temporary" when installing
> it. So one can safely test a software and then remove it without leaving
> a lot of unnecessary junk in the system.

I came across this request while looking for something similar to fit
my own needs, and I think I've got an idea that could solve both use
cases in a reasonably simple APT-like way.

My own use case is that I want to ensure some package is installed
(without knowing ahead of time whether it is), do something with it,
then remove it, but only remove it if it was not already previously
installed (as part of a script), including dependencies.

I realized that a clean way to handle this would be some way to just
tell "apt-get install" to _not_ mark the packages as manually
installed -- if they're already marked, leave their markings alone,
otherwise mark them as auto (akin to Gentoo's "emerge --oneshot" or
what's possible with Alpine's "apk --virtual").  This way, new
packages could be installed willy nilly, and easily removed with
"apt-get autoremove".

I can mimic this behavior currently by doing some dancing with
"apt-mark" before and after install, but it'd be really awesome if APT
itself had either a flag or a "-o" option for adjusting the package
marking behavior.

If it seems like this is really a separate wishlist item (and not as
overlapping as I thought), I'm also happy to file a new wishlist issue
instead. :)

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

Bug#844081: Reproducer

[Filip Pytloun]

So I got access to affected host and was able to reproduce it there.
Spent some time debugging it and unfortunately I am still clueless why this is
happening.

Found out that it doesn't matter if eatmydata is used or not, test is
occasionally failing in both cases.

I tried my patch and it didn't help - even when I raised the sleep to 5
seconds or call coll.update_db() multiple times it's failing with the same
error.

ICS file seems to be correctly written on disk:

  File:
  
'/tmp/pytest-of-filip/pytest-63/test_default_calendar1/foobar/0c9c883e-21a7-447b-b218-54f7e667aa87.ics'
Size: 282 Blocks: 8  IO Block: 4096   regular file
Device: fe01h/65025dInode: 516304  Links: 1
Access: (0600/-rw---)  Uid: ( 1000/   filip)   Gid: ( 1000/   filip)
Access: 2016-11-23 22:29:28.086145354 +
Modify: 2016-11-23 22:29:28.086145354 +
Change: 2016-11-23 22:29:28.086145354 +
 Birth: -

Any ideas how to debug this or what more to try?

Filip


signature.asc
Description: Digital signature

Bug#845225: mytop: Incorrectly parses quoted values in .my.cnf

[Werner Detter]

Hi,

just create a custom ~/.mytop file like follows (see perldoc mytop for
more information):

werner@debian:~$ cat ~/.mytop
user=youruser
pass=my#password
host=localhost

And your ~/.my.cnf remains:
[client]
password="my#password"

mytop and the mysql client are working this way.

Thanks,
Werner


Am 21/11/2016 um 17:39 schrieb Matthew Hawker:
> Package: mytop
> Version: 1.9.1-2
> Severity: normal
> 
> Dear Maintainer,
> 
> The mysql client allows values in .my.cnf to be quoted, while mytop 
> understands quotes around the values in the file as being part of the value.  
> As a result, there is no way to write .my.cnf in a way that'll allow hash 
> symbols (#) in passwords. 
> 
> For example, this works in mysql but fails in mytop:
> 
> [client]
> password="my#password"
> 
> However, this works in mytop but fails in mysql:
> 
> [client]
> password=my#password
> 
> Thanks and best regards,
> 
> Matt
> 
> -- System Information:
> Debian Release: 8.6
>   APT prefers stable
>   APT policy: (500, 'stable'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 2.6.32-45-pve (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 mytop depends on:
> ii  libconfig-inifiles-perl  2.83-3
> ii  libdbd-mysql-perl4.028-2+deb8u2
> ii  libdbi-perl  1.631-3+b1
> ii  libterm-readkey-perl 2.32-1+b1
> ii  perl 5.20.2-3+deb8u6
> 
> Versions of packages mytop recommends:
> ii  perl [libtime-hires-perl]  5.20.2-3+deb8u6
> 
> mytop suggests no packages.
> 
> -- no debconf information
> 

Bug#843999: jessie-pu: package wot/20131118-2

[W. Martin Borgert]

On 2016-11-20 18:02, Jonathan Wiltshire wrote:
> In principle 'yes'; please prepare the diff and attach to this bug for
> review.

Attached.
diff --git a/debian/NEWS b/debian/NEWS
new file mode 100644
index 000..18ab932
--- /dev/null
+++ b/debian/NEWS
@@ -0,0 +1,14 @@
+wot (20151208-3) unstable; urgency=high
+
+  * WOT has been identified as malware or spyware.
+At least since 2015-04, it passes all complete URLs with an
+additional user or browser id to their company server.
+The company sells the data unfiltered and unanonimized to
+paying customers.
+
+This package is an empty, transitional package to remove
+WOT safely from your computer.
+Make sure, that users don't have WOT installed by other
+means than as Debian package.
+
+ -- W. Martin Borgert   Wed, 09 Nov 2016 20:25:45 +
diff --git a/debian/changelog b/debian/changelog
index b1c9a53..e22783d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+wot (20131118-2) stable; urgency=high
+
+  * Team upload
+  * Removed all code, because this is malware (Closes: #842939)
+  * Changed homepage to Debian wiki page about the malware incident
+
+ -- W. Martin Borgert   Wed, 23 Nov 2016 22:22:56 +
+
 wot (20131118-1) unstable; urgency=low
 
   * Team upload
diff --git a/debian/control b/debian/control
index 3a1c365..273976b 100644
--- a/debian/control
+++ b/debian/control
@@ -2,10 +2,10 @@ Source: wot
 Section: web
 Priority: optional
 Maintainer: Debian Mozilla Extension Maintainers 
-Uploaders: Fabrizio Regalli 
-Build-Depends: debhelper (>= 8), mozilla-devscripts (>= 0.29~), node-uglify
+Uploaders: David Prévot 
+Build-Depends: debhelper (>= 8)
 Standards-Version: 3.9.5
-Homepage: https://www.mywot.com
+Homepage: https://wiki.debian.org/Mozilla/WOT
 Vcs-Git: git://anonscm.debian.org/pkg-mozext/wot.git
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-mozext/wot.git
 
@@ -16,8 +16,8 @@ Recommends: ${xpi:Recommends}
 Provides: ${xpi:Provides}
 Enhances: ${xpi:Enhances}
 Breaks: ${xpi:Breaks}
-Description: show which websites are trustworthy
- WOT is the leading website reputation rating tool and one of 
- Mozilla’s most popular add-ons. WOT uses an intuitive
- traffic-light style rating system to help you know which
- websites are trusted when you search, surf and shop online.
+Description: Transitional package to safely remove WOT
+ WOT is a malware providing users browser habits to paying
+ customers. It has therefore been disabled in Debian.
+ .
+ This package can be safely removed after upgrade.
diff --git a/debian/rules b/debian/rules
index e3f9169..41276fa 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,17 +1,9 @@
 #!/usr/bin/make -f
 %:
-	dh $@ --with xul-ext --buildsystem=xul_ext
-
-override_dh_auto_build:
-	mv $(CURDIR)/chrome/wot.jar\!/content/libs/jquery.js $(CURDIR)/debian/jquery.js.bkp
-	uglifyjs -o $(CURDIR)/chrome/wot.jar\!/content/libs/jquery.js \
-		$(CURDIR)/chrome/wot.jar\!/content/libs/jquery-ui-1.9.2.custom.js
-	dh_auto_build -O--buildsystem=xul_ext
-	mv $(CURDIR)/debian/jquery.js.bkp $(CURDIR)/chrome/wot.jar\!/content/libs/jquery.js
+	dh $@
 
 override_dh_auto_install:
-	install-xpi --remove-license-files xul-ext-wot.xpi
-	rm -r $(CURDIR)/debian/xul-ext-wot/usr/share/xul-ext/wot/META-INF
+	true
 
 override_dh_installchangelogs:
 	dh_installchangelogs $(CURDIR)/debian/upstream-changelog

Bug#747244: gnome-terminal: mouse cursor hides when typing and won't unhide when moving it again

[Egmont Koblinger]

Hi,

I belive this is the same as the upstream bug at
https://bugzilla.gnome.org/show_bug.cgi?id=725342, which in turn boiled
down to the Gtk+ focus-out issue:
https://bugzilla.gnome.org/show_bug.cgi?id=677329.

If so, it's fixed in gtk+ 3.18.9.

cheers,
e.

Bug#794890: [Pkg-javascript-devel] Bug#794890: npm: new upstream version

[Michael Prokop]

Cc-ing ftpmas...@debian.org hereby with a (nearly) fullquote below -
it's about #794890 and the situation of the npm package within
Debian, we'd appreciate your input/feedback on this matter. Thanks!

regards,
-mika-

* Jérémy Lal [Wed Nov 23, 2016 at 02:42:23PM +0100]:
> 2016-11-23 14:18 GMT+01:00 Michael Prokop :

> > I looked into it and as Paolo mentioned in this bugreport (see
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794890#44) many
> > new packages would have to be packaged to get a newer npm package
> > into Debian. But it seems to also require updating *existing*
> > packages. Looking at e.g. the current state of the node-request
> > dependency (~2.78.0):
[...]
> > ... I'm afraid the situation of node-* packages in Debian is worse
> > than I expected. node-request's upstream release of version 2.26.1
> > dates back to August 2013 and nowadays upstream is at version 2.79.
> > There's #844072 against node-request (where someone is asking for a
> > newer version of node-request in Debian), but it was filed just this
> > month (November 2016) and between 2013 and 2016 there was not a
> > single package upload for node-request in Debian.

> > Asking around what other Debian contributors and users usually do when
> > they've to deal with npm + nodejs: either "npm install -g npm"(sic!)
> > and then use npm to install the actual node packages or directly
> > head towards upstream (like https://deb.nodesource.com/setup_4.x).

> > Now one reason why we have node-* packages in Debian is that they
> > are dependencies of further packages. To have some numbers: I see
> > 601 packages named "node-*" in sid/amd64 as of today, and when
> > looking at their reverse dependencies I see only those 24 binary
> > packages with node-* packages in their depends/recommends/suggests:

> > * chai
> > * cleancss
> > * emscripten
> > * flightgear-phi
> > * fonts-font-awesome
> > * gis-osm
> > * groovebasin
> > * grunt
> > * jison
> > * lava-dev
> > * libjs-jquery-ui-docs
> > * libjs-util
> > * libjs-validator
> > * livescript
> > * mocha
> > * nikola
> > * npm
> > * npm2deb
> > * python-livereload
> > * python-webassets
> > * python3-livereload
> > * python3-webassets
> > * twitter-recess
> > * ycmd

> > Reducing it to dependencies only (no recommends or suggests) we
> > seem to have only those 18 packages left:

> > * chai
> > * cleancss
> > * emscripten
> > * flightgear-phi
> > * fonts-font-awesome
> > * groovebasin
> > * grunt
> > * jison
> > * lava-dev
> > * libjs-jquery-ui-docs
> > * libjs-util
> > * libjs-validator
> > * livescript
> > * mocha
> > * npm
> > * npm2deb
> > * twitter-recess

> > [JFTR: I didn't consider and look into build-depends for my numbers
> > and didn't verify my list with UDD or similar yet. If my numbers are
> > wrong please correct me.]

> > I might be wrong (please correct me), but my impression is that
> > people are uploading node-* packages mainly to satisfy a
> > (build-)dependency they have in a package and then don't really care
> > about those packages any longer. I also count 196 node-* packages
> > without *any* rdepends on them (http://paste.grml.org/2868/ is the
> > full list), aren't people working on those things interested in an
> > up2date npm package?

> I believe as well it is true for most of them.
> Bundling dependencies (only when upstream actually takes care of
> updating them when doing a release) would solve the issue in many ways.

> > Back to the npm situation: I was reporting
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794890#34 because
> > Debian's npm can't be really used reliably nowadays (the
> > "@module/names" not supported at all). Looking through the
> > bugreports of the npm package I'd call it unmaintained, there's even
> > an open CVE (https://security-tracker.debian.org/tracker/CVE-2016-3956).
> > The last upload was in 2014 and no one felt to call for help with
> > its packaging since then (especially now with stretch freeze on our
> > horizon), orphan the package etc. or am I missing something here?

> > Overall, I'm not sure we are providing our users something good with
> > the current situation. Though what realistic options do we have get
> > forward here? Any thoughts?

> Most, if not all, npm dependencies are shipped by upstream "bundled",
> meaning they actually take care of updating the dependencies when
> doing a release of npm.
> That means it would be maintainable (and certainly much easier to do so)
> by simply distributing all the bundled submodules as part of the npm
> debian package - and by considering the release tarball to be the one
> distributed on upstream website, and not the one tagged from the git 
> repository.

> If ftp masters are all right with this, i'm willing to do the work.

> A question is left open: should the npm package "Provides" all those 
> submodules
> and install them to be used by everyone ? Or should it keep them for its own
> internal use ?
> If bundled submodules are listed in "Provides", i

Bug#845480: /bin/ps depends on /usr/lib/... which makes the system unbootable

[Axel Beckert]

Hi Craig,

Craig Small wrote:
> Actually its not ps, its libsystemd that is pulling this dependency in. ps
> is linked to libsystemd which is in /lib and
> $ ldd /lib/x86_64-linux-gnu/libsystemd.so | grep usr
> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7fa2cf30)
> 
> There is also this on the systemd bug
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843809
> 
> I am not sure at this point where to go, but it is either intentional or a
> bug, but its not ps' bug.

Well, depends. I don't see a reason why a simple program like ps needs
to be linked against libsystemd. So maybe the simple solution is to
not link ps against libsystemd in the first place.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#845492: graphviz: Double free() for dot files with multiple digraphs

[Stephan Diestelhorst]

Package: graphviz
Version: 2.38.0-12ubuntu2
Severity: important

Dear Maintainer,

   The dot tool has had random crahses for dot files with multiple
   digraphs, sometimes leading to glib detected malloc / free
   corruption.

   I have tested this with the Address Sanitizer and Valgrind Memcheck,
   and found a simple memory leak (that I fixed), and a double free of
   the ranks (that I also fixed), and several lost memory allocations
   aka leaks, that I have not managed to fix, as they are somewhat
   secondary.

   This is an Ubuntu package, but I believe the issue to be still
   present in the Debian package.  Upstream bug tracking is tedious, so
   I am submitting here, instead.

   Thanks,
 Stephan

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-47-generic (SMP w/2 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 graphviz depends on:
ii  libc6   2.23-0ubuntu4
ii  libcdt5 2.38.0-12ubuntu2
ii  libcgraph6  2.38.0-12ubuntu2
ii  libexpat1   2.1.0-7ubuntu0.16.04.2
ii  libgd3  2.1.1-4ubuntu0.16.04.5
ii  libgvc6 2.38.0-12ubuntu2
ii  libgvpr22.38.0-12ubuntu2
ii  libx11-62:1.6.3-1ubuntu2
ii  libxaw7 2:1.0.13-1
ii  libxmu6 2:1.1.2-2
ii  libxt6  1:1.1.5-0ubuntu1

Versions of packages graphviz recommends:
ii  fonts-liberation  1.07.4-1

Versions of packages graphviz suggests:
pn  graphviz-doc  
ii  gsfonts   1:8.11+urwcyr1.0.7~pre44-4.2ubuntu1

-- no debconf information
--- graphviz.old/graphviz-2.38.0/lib/dotgen/dotinit.c	2014-04-13 21:40:25.0 +0100
+++ graphviz/graphviz-2.38.0/lib/dotgen/dotinit.c	2016-11-23 19:32:53.0 +
@@ -162,6 +162,8 @@
 
 free_list(GD_comp(g));
 if (GD_rank(g)) {
+	// SD: The deallocates here will also deallocate the .v field which
+	// aliases; and were causing double free errors
 	for (i = GD_minrank(g); i <= GD_maxrank(g); i++)
 	free(GD_rank(g)[i].av);
 	if (GD_minrank(g) == -1)
--- graphviz.old/graphviz-2.38.0/lib/dotgen/flat.c	2014-04-13 21:40:25.0 +0100
+++ graphviz/graphviz-2.38.0/lib/dotgen/flat.c	2016-11-23 19:31:59.0 +
@@ -22,6 +22,11 @@
 
 v = GD_rank(g)[r].v =
 	ALLOC(GD_rank(g)[r].n + 2, GD_rank(g)[r].v, node_t *);
+
+// Keep v and av in sync; ALLOC may move the previous allocation of .v and
+// they are supposed to stay in sync
+GD_rank(g)[r].av = GD_rank(g)[r].v;
+
 for (i = GD_rank(g)[r].n; i > pos; i--) {
 	v[i] = v[i - 1];
 	ND_order(v[i])++;
--- graphviz.old/graphviz-2.38.0/lib/dotgen/mincross.c	2014-04-13 21:40:25.0 +0100
+++ graphviz/graphviz-2.38.0/lib/dotgen/mincross.c	2016-11-23 19:33:41.0 +
@@ -1053,7 +1053,14 @@
 GD_rank(g) = N_NEW(GD_maxrank(g) + 2, rank_t);
 for (r = GD_minrank(g); r <= GD_maxrank(g); r++) {
 	GD_rank(g)[r].an = GD_rank(g)[r].n = cn[r];
+	// SD: Below allocation is unsafe, as these get deallocated differently
+	//
+	// node_t **v;		/* ordered list of nodes in rank*/
+	// node_t **av;		/* allocated list of nodes in rank  */
 	GD_rank(g)[r].av = GD_rank(g)[r].v = N_NEW(cn[r] + 1, node_t *);
+	// SD: Trying to have separate allocations does not work, below
+	//GD_rank(g)[r].av = N_NEW(cn[r] + 1, node_t *);
+	//GD_rank(g)[r].v  = N_NEW(cn[r] + 1, node_t *);
 }
 free(cn);
 }
--- graphviz.old/graphviz-2.38.0/lib/gvpr/mkdefs.c	2014-04-13 21:40:25.0 +0100
+++ graphviz/graphviz-2.38.0/lib/gvpr/mkdefs.c	2016-11-23 10:50:27.0 +
@@ -147,6 +147,7 @@
 	}
 	buf = malloc(BSIZE);
 }
+free(buf);
 
 fp = fopen(filename, "w");
 if (!fp) {

Bug#845490: dput: Please push 0.11.0 to git.debian.org -- the git repo is stale

[Daniel Kahn Gillmor]

Package: dput
Version: 0.11.0
Severity: wishlist

the git repo at https://anonscm.debian.org/git/collab-maint/dput.git
only has tags up to release/0.10.2 -- please the push the latest work
to the git repo to make it easier to collaborate!

Thanks,

--dkg

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

Kernel: Linux 4.8.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)

Bug#845471: ITP: java-diff-utils -- library for computing diffs, applying patches, and generation of side-by-side view in Java

[tony mancill]

On Wed, Nov 23, 2016 at 10:19:06PM +0100, Emmanuel Bourg wrote:
> This is probably a duplicate of #696165, i.e. an ITP for the same
> library when it was hosted on Google Code. Unfortunately the original
> code has a license issue.

Bah! Thank you for the pointer - it is most definitely a duplicate. I
was searching here [1] for other ITPs but didn't consider looking for
archived ITPs.

Cheers,
tony 

[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=wnpp


signature.asc
Description: PGP signature

Bug#845297: [www.debian.org] Website transition from CVS to Git

[Laura Arjona Reina]

Package: www.debian.org

Hello again

I have created another branch:

"untranslatable", for the approach of "a git repo hosting the
untranslatable files, until we migrate everything to git".

Work in this branch/approach is towards designing a new workflow in
order to allow people to use a git repo to commit changes to certain
files only (the .def, .data, etc) that are not translatable and thus,
could be "copied" or "pulled" into the website tree at build time, right
after or before we do the "cvs update".

I guess that we should remove in this branch:
* the files that are translatable in the /english folder
* all the language folders

(and if we agree this is the way to go, then we should remove, from the
CVS repo, the files that are in the git repo created with this branch).

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

Bug#845489: lsb-release: lsb_release.py : FileNotFound and Python 2.7

[Tobias Bora]

Package: lsb-release
Version: 9.20161101
Severity: important
Tags: upstream

Dear Maintainer,

The script lsb_release.py in

/usr/lib/python2.7/dist-packages/lsb_release.py

is buggy. Indeed, it uses 'FileNotFoundError' which is not defined in
Python 2.7. This results into bugs when you run the python function

lsb_release.get_distro_information()

when the file /usr/share/distro-info/%s.csv does not exists (it is for
example the case on my raspberrypi which runs raspbian) :

 release = lsb_release.get_distro_information()
 File "/usr/lib/python2.7/dist-packages/lsb_release.py", line 341,
in get_distro_information
 distinfo = guess_debian_release()
 File "/usr/lib/python2.7/dist-packages/lsb_release.py", line 239,
in guess_debian_release
 get_distro_info(distinfo['ID'])
 File "/usr/lib/python2.7/dist-packages/lsb_release.py", line 33, in
get_distro_info
  except FileNotFoundError:
  NameError: global name 'FileNotFoundError' is not defined


The fix should be pretty trivial, but it would be nice to make it
working. Thank you in advance for solving this bug,

tobiasBora.

-- Package-specific info:
lsb_release output
-*- -*- -*- -*- -*-
Distributor ID: Debian
Description:Debian GNU/Linux unstable (sid)
Release:unstable
Codename:   sid
-*- -*- -*- -*- -*-
Apt policy
-*- -*- -*- -*- -*-
Package files:
 100 /var/lib/dpkg/status
 release a=now
 500
http://ppa.launchpad.net/webcamstudio/webcamstudio-dailybuilds/ubuntu
xenial/main i386 Packages
 release
v=16.04,o=LP-PPA-webcamstudio-webcamstudio-dailybuilds,a=xenial,n=xenial,l=WebcamStudio
PPA (Daily Builds),c=main,b=i386
 origin ppa.launchpad.net
 500
http://ppa.launchpad.net/webcamstudio/webcamstudio-dailybuilds/ubuntu
xenial/main amd64 Packages
 release
v=16.04,o=LP-PPA-webcamstudio-webcamstudio-dailybuilds,a=xenial,n=xenial,l=WebcamStudio
PPA (Daily Builds),c=main,b=amd64
 origin ppa.launchpad.net
 500 https://pkg.tox.chat/debian nightly/sid i386 Packages
 release o=pkg.tox.chat,a=nightly,n=nightly,l=pkg.tox.chat,c=sid,b=i386
 origin pkg.tox.chat
 500 https://pkg.tox.chat/debian nightly/sid amd64 Packages
 release o=pkg.tox.chat,a=nightly,n=nightly,l=pkg.tox.chat,c=sid,b=amd64
 origin pkg.tox.chat
 500 https://dl.bintray.com/sbt/debian  Packages
 release o=Bintray,l=Bintray,c=
 origin dl.bintray.com
 500
http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Debian_8.0 
Packages
 release
o=obs://build.opensuse.org/isv:ownCloud:desktop/Debian_8.0,n=Debian_8.0,l=isv:ownCloud:desktop,c=
 origin download.opensuse.org
 500 http://download.fpcomplete.com/debian jessie/main amd64 Packages
 release n=jessie,c=main,b=amd64
 origin download.fpcomplete.com
 500 https://apt.dockerproject.org/repo debian-stretch/main amd64 Packages
 release o=Docker,a=debian-stretch,n=debian-stretch,l=Docker APT
Repository,c=main,b=amd64
 origin apt.dockerproject.org
 500 https://packages.chef.io/repos/apt/stable jessie/main i386 Packages
 release o=Artifactory,a=jessie,n=jessie,l=Artifactory,c=main,b=i386
 origin packages.chef.io
 500 https://packages.chef.io/repos/apt/stable jessie/main amd64 Packages
 release o=Artifactory,a=jessie,n=jessie,l=Artifactory,c=main,b=amd64
 origin packages.chef.io
 500 http://security.debian.org/debian-security wheezy/updates/main i386
Packages
 release
v=7.0,o=Debian,a=oldstable,n=wheezy,l=Debian-Security,c=main,b=i386
 origin security.debian.org
 500 http://security.debian.org/debian-security wheezy/updates/main
amd64 Packages
 release
v=7.0,o=Debian,a=oldstable,n=wheezy,l=Debian-Security,c=main,b=amd64
 origin security.debian.org
   1 http://ftp.debian.org/debian experimental/non-free i386 Packages
 release
o=Debian,a=experimental,n=experimental,l=Debian,c=non-free,b=i386
 origin ftp.debian.org
   1 http://ftp.debian.org/debian experimental/non-free amd64 Packages
 release
o=Debian,a=experimental,n=experimental,l=Debian,c=non-free,b=amd64
 origin ftp.debian.org
   1 http://ftp.debian.org/debian experimental/contrib i386 Packages
 release
o=Debian,a=experimental,n=experimental,l=Debian,c=contrib,b=i386
 origin ftp.debian.org
   1 http://ftp.debian.org/debian experimental/contrib amd64 Packages
 release
o=Debian,a=experimental,n=experimental,l=Debian,c=contrib,b=amd64
 origin ftp.debian.org
   1 http://ftp.debian.org/debian experimental/main i386 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=main,b=i386
 origin ftp.debian.org
   1 http://ftp.debian.org/debian experimental/main amd64 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=main,b=amd64
 origin ftp.debian.org
   1 http://httpredir.debian.org/debian experimental/main i386 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=main,b=i386
 origin httpredir.debian.org
   1 http://httpredir.debian.org/debian experimental

Bug#842850: vpnc: please support main mode

[Florian Schlichting]

Hi Benoit,

> While debugging an issue connecting with vpnc to a mikrotik firewall, I more
> or less pinpointed the problem in vpnc only trying aggressive mode
> and not 'main' mode.
> 
> Could a config option be added to also allow main mode?

I'm not sure what 'aggressive mode' is and I cannot find anything about
that in the source. But if you're able to develop a patch (and if
possible, post that patch to the upstream development list in addition
to this bug report), I can certainly add that patch to the Debian
package.

Florian

Bug#845488: ITP: linux-firmware-raspi3 -- Raspberry Pi 3 GPU firmware and bootloaders

[Michael Stapelberg]

Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg 

* Package name: linux-firmware-raspi3
  Version : 1.20161123
  Upstream Author : Raspberry Pi Foundation
* URL : https://github.com/raspberrypi/firmware
* License : Proprietary
  Description : Raspberry Pi 3 GPU firmware and bootloaders

 This package contains all the proprietary files necessary to boot a
 Raspberry Pi 3 board.
 .
 Raspberry Pi is a trademark of the Raspberry Pi Foundation.

This package will be maintained by the newly created pkg-raspi team, and
is one of the last few pieces of the puzzle to create Debian images for
the Raspberry Pi 3. The package is based on the linux-firmware-raspi2
package from Ubuntu.

Bug#844922: [Pkg-javascript-devel] Bug#844922: Bug#844922: Node-string-decoder

[Ross Gammon]

On 11/23/2016 08:59 AM, Jérémy Lal wrote:
> 2016-11-23 8:53 GMT+01:00 Ross Gammon :
>> Hi,
>>
>> This node module was originally packaged as it was a dependency of something
>> (I can't remember).
>>
>> If there is nothing depending on it, we should probably remove it from the
>> archive. The string-decoder function from the core nodejs should be used
>> instead (patching the module that needs it if required). Node-string-decoder
>> is mainly used when a nodejs project wants to stick to an old version of
>> this function.
>>
>> Regards,
> 
> All right, can you fill the ftp.debian.org RM request please ?
> 
> Jérémy
> 

Done!



signature.asc
Description: OpenPGP digital signature

Bug#845487: binutils-arm-none-eabi: defaulting to --check-sections breaks previously working linker scripts

[Andy Isaacson]

Package: binutils-arm-none-eabi
Version: 2.27-9+9
Severity: important

Dear Maintainer,

My project links OK if I downgrade to

binutils-arm-none-eabi:amd64 2.26-4+8

but linking fails when running

binutils-arm-none-eabi:amd64 2.27-9+9

with

/usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/bin/ld: section 
.bootdata VMA [40024ff0,40024fff] overlaps section .bkpsram VMA 
[40024000,40024fff]

Changing my link command to

arm-none-eabi-g++ -Wl,--no-check-sections

resolves the problem.

Now, my linker script may well be incorrect but it's unfortunate that the 
default
for --check-sections changed without any documentation in Changelog or NEWS 
afaics.

my previously working commandline was:

arm-none-eabi-g++ -Wl,-Map=proj.map -Tproj.ld -Wl,--gc-sections,-u,-IVT 
-nostdlib -Wl,--no-wchar-size-warning -o proj_tmp.elf $(OBJS) $(LIBS)

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

Kernel: Linux 4.7.0 (SMP w/4 CPU cores)
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)

Versions of packages binutils-arm-none-eabi depends on:
ii  libc6   2.24-5
ii  zlib1g  1:1.2.8.dfsg-2+b3

binutils-arm-none-eabi recommends no packages.

binutils-arm-none-eabi suggests no packages.

-- no debconf information

Bug#844233: Fixed upstream

[Harlan Lieberman-Berg]

tag 844233 -upstream, +fixed-upstream
thanks

According to the maintainer, this has been fixed in the 1.7.0 release.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#330907: /usr/sbin/gnome-pty-helper: writes arbitrary utmp records

[Egmont Koblinger]

FYI:

VTE (Debian package name: libvte-2.91-0) no longer ships gnome-pty-helper
as of version 0.42.

VTE, and in turn gnome-terminal, no longer does utmp/wtmp logging at all.

See https://git.gnome.org/browse/vte/commit/?id=299c700 and
https://bugzilla.gnome.org/show_bug.cgi?id=747046 for further details.

cheers,
egmont

Bug#845486: RM: node-string-decoder -- ROM; No longer required.

[Ross Gammon]

Package: ftp.debian.org
Severity: normal

Package has begun to FTBFS in Debian, and has not been touched upstream for 2
years.
Actually, the package is no longer required. Packages depending on node-string-
decoder can use the string-decoder function from core nodejs instead.

Bug#807241: xdg-menu-convert: changing from ITP to RFP

[Adrian Bunk]

retitle -1 RFP: xdg-menu-convert -- Convert freedesktop files to a format used 
by various WMs
noowner -1
thanks

Due to no activity for a long time I am changing the 
xdg-menu-convert WNPP bug from ITP to RFP.

cu
Adrian

-- 

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

Bug#845297: [www.debian.org] Website transition from CVS to Git

[Laura Arjona Reina]

Package: www.debian.org

Dear all
I have created a git repo importing the CVS repo with git, and pushed it
to Alioth

https://anonscm.debian.org/cgit/webwml/webwml2git.git/

For now, you will find there 3 branches:

1.- "master"

I'll keep in sync with the CVS repo (I'll try to update daily). This is
intended read-only, please don't commit there.

For the initial import, I did this:

$ CVSROOT=":pserver:anonym...@anonscm.debian.org:/cvs/webwml"
$ git cvsimport -d "$CVSROOT" -C ./webwml -o master -R webwml

(the "-R" is particularly important, because it creates the file
.git/cvs-revisions matching each filename+cvs_revision to its commit_id)

Then I created a new empty repo, and fetched the master branch there.
Then I pushed this new repo to alioth.

The initial cvs import took 2 days approximately.

The daily updates will only add the new commits and update the file
"cvs-revisions" and will take minutes only.

2.- "githashes" is the branch where work can be done in order to prepare
the scripts needed for using git hashes or commit_ids instead of
cvs_version_numbers.

This would allow to keep most of the workflow we use for translation,
coordination pages, etc unchanged.
In this branch, most of the work should be done, I guess, in:
* the Perl folder (where some scripts live),
* the build scripts (they are at
https://anonscm.debian.org/gitweb/?p=debwww/cron.git
and the current build logs for the web site can be found at
https://www-master.debian.org/build-logs/ ).

3.- "po4a" is the branch where work can be done in order to use .po
files to generate the language wml files, and thus, no need to compare
versions numbers or hashes.

This would require design a new workflow for commits in the english
folder, a new workflow for translators, and adapt the build scripts, but
we wouldn't need to compare version numbers/hashes, since we'd use the
po4a capabilities to keep the .pot and .po files updated (the changes in
strings are marked as fuzzy, and we can choose not generate the wml
files if the .po is not translated 100%, and show the old translation,
if it exists).

If you want to help:
* First step is to know how the website currently works, please read
https://www.debian.org/devel/website/ and its subpages.

* Then have a look a the wiki page created for the migration, where
different approaches are explained
https://wiki.debian.org/WebsiteGitTransition

* Review this bug report.

* Choose one of this 2 approaches, and work in the corresponding branch,
or update the wiki page with your ideas, create a branch yourself, and
work there.

* If you have no commit permissions, just send the patches here to the
bug report or point us to the URL of your branch in your local copy.

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