Bug#415396: [debhelper-devel] Bug#415396: "dh_install --list-missing" should ignore manpages and other installed files

[Michael Stapelberg]

On Sat, Apr 8, 2017 at 7:54 AM, Niels Thykier  wrote:

> Michael Stapelberg:
> > On Mon, Apr 3, 2017 at 1:07 PM, Niels Thykier  wrote:
> >
> >> [...]
> >
> >
> > Thanks a lot!
> >
> > In turn, I created a branch in the freeradius packaging:
> > https://anonscm.debian.org/cgit/pkg-freeradius/freeradius.git/log/?h=dh_
> missing
> >
>
> Thanks for trying it out. :)
>
> > Maybe I did the wrong changes (?), but when building, I get an error:
> >
> > [...]
> >
> > Can you reproduce the issue?
> >
> >
> >
> > [...]
>
> I think it is a bug in the freeradius changes.  In this commit:
>
> https://anonscm.debian.org/cgit/pkg-freeradius/
> freeradius.git/commit/?h=dh_missing&id=58e693ff7dd6603598cb132d44c9e9
> a547f099ed
>
> The dh_install call is replaced by dh_missing, but AFAICT that
> dh_install is inside an override_dh_install, so dh_install is never called.
>

Thanks, you are spot on. After re-adding the dh_install command, most of
the errors vanish. Interestingly enough, this one remains:

dh_missing --fail-missing
dh_missing: usr/lib/freeradius/rlm_sql_freetds.so exists in debian/tmp but
is not installed to anywhere
The following debhelper tools have reported what they installed
* dh_install
* dh_installman
If the missing files are installed by another tool, please file a bug
against it
For a short-term work-around: Add the files to debian/not-installed
dh_missing: missing files, aborting

I’ve added it to debian/freeradius.install and updated the branch.

The only remaining issue as far as the freeradius packaging is concerned is
dh_installdocs not yet reporting which files it installs — hence the build
fails at
https://anonscm.debian.org/cgit/pkg-freeradius/freeradius.git/commit/?h=dh_missing&id=afbb47b0f8646de9fc116d8f494608ef4cef6a90

Either way, what you have in the dh_missing branch right now is already
useful :).


>
>  * Does it work if you add a dh_install in the bottom of the dh_install
>override target?
>
> Thanks,
> ~Niels
>
>
>


-- 
Best regards,
Michael

Bug#859863: unblock: heimdal/7.1.0+dfsg-11

[Brian May]

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

Please unblock package heimdal

Depreciated servers and clients were removed from both heimdal-clients
and heimdal-servers. However the meta information was not updated to
reflect these changes. As a result, the descriptions still referred to
programs that were removed, the provides was wrong, and the conflicts
was also wrong. This fixes #236902 and #859664.

(the changelog entry for -10 was wrong, despite being an otherwise good
upload, so I reuploaded as -11).

diff -Nru heimdal-7.1.0+dfsg/debian/changelog 
heimdal-7.1.0+dfsg/debian/changelog
--- heimdal-7.1.0+dfsg/debian/changelog 2017-01-09 09:36:15.0 +1100
+++ heimdal-7.1.0+dfsg/debian/changelog 2017-04-08 11:38:13.0 +1000
@@ -1,3 +1,10 @@
+heimdal (7.1.0+dfsg-11) unstable; urgency=medium
+
+  * Remove legacy provides/conflicts/replaces headers. Old daemons
+such as ftp have been removed. Closes: #236902, #859664.
+
+ -- Brian May   Sat, 08 Apr 2017 11:38:13 +1000
+
 heimdal (7.1.0+dfsg-9) unstable; urgency=medium
 
   * Switch back to collab-maint URL until pkg-heimdal permissions are
diff -Nru heimdal-7.1.0+dfsg/debian/control heimdal-7.1.0+dfsg/debian/control
--- heimdal-7.1.0+dfsg/debian/control   2017-01-09 09:35:46.0 +1100
+++ heimdal-7.1.0+dfsg/debian/control   2017-04-08 11:38:13.0 +1000
@@ -37,10 +37,6 @@
 Priority: extra
 Architecture: all
 Depends: dpkg (>= 1.15.4) | install-info, ${misc:Depends}
-Replaces: heimdal-lib (<< 0.3c-5),
-  heimdal-servers (<< 0.6.3-3),
-  libkrb5-15-heimdal
-Conflicts: heimdal-lib (<< 0.3c-5)
 Suggests: heimdal-clients, heimdal-servers
 Description: Heimdal Kerberos - documentation
  Heimdal is a free implementation of Kerberos 5 that aims to be
@@ -65,7 +61,6 @@
  ${misc:Depends},
  ${shlibs:Depends}
 Recommends: logrotate
-Replaces: heimdal-clients (<< 0.7.2-1), heimdal-servers (<< 0.4e-3)
 Suggests: heimdal-docs
 Description: Heimdal Kerberos - key distribution center (KDC)
  Heimdal is a free implementation of Kerberos 5 that aims to be
@@ -99,7 +94,7 @@
  libsl0-heimdal (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
-Replaces: heimdal-clients (<< 0.4e-7), heimdal-dev (<< 1.6~git20131117+dfsg-2)
+Replaces: heimdal-dev (<< 1.6~git20131117+dfsg-2)
 Suggests: heimdal-docs
 Description: Heimdal Kerberos - Multi-implementation Development
  Heimdal is a free implementation of Kerberos 5 that aims to be
@@ -128,23 +123,14 @@
 Priority: extra
 Architecture: any
 Depends: krb5-config, ${misc:Depends}, ${shlibs:Depends}
-Conflicts: ftp (<< 0.16-1),
-   heimdal-servers (<< 0.4e-7),
-   kerberos4kth-clients,
-   kerberos4kth-user,
-   netstd,
-   openafs-client (<< 1.2.2-3),
-   otp
-Provides: ftp
+Conflicts: otp
 Suggests: heimdal-docs, heimdal-kcm
-Replaces: heimdal-servers (<< 0.6.3-12)
 Description: Heimdal Kerberos - clients
  Heimdal is a free implementation of Kerberos 5 that aims to be
  compatible with MIT Kerberos.
  .
  This package includes Kerberos utilities like kadmin, kinit, kpasswd and
- klist. It also includes client programs like telnet and ftp that have been
- compiled with Kerberos support.
+ klist.
 
 Package: heimdal-kcm
 Priority: extra
@@ -167,21 +153,12 @@
  openbsd-inetd|inet-superserver,
  ${misc:Depends},
  ${shlibs:Depends}
-Conflicts: ftp-server,
-   heimdal-clients (<< 0.2l-2),
-   kerberos4kth-services,
-   netstd,
-   pop3-server,
-   wu-ftpd-academ (<< 2.5.0)
-Provides: ftp-server
 Suggests: heimdal-docs
-Replaces: heimdal-clients (<< 0.2l-2)
 Description: Heimdal Kerberos - server programs
  Heimdal is a free implementation of Kerberos 5 that aims to be
  compatible with MIT Kerberos.
  .
- This package includes servers such as telnetd and ftpd that have been
- compiled with Heimdal support.
+ This package contains the kfd server, for receiving forwarded tickets.
 
 Package: heimdal-dbg
 Multi-Arch: same
@@ -239,8 +216,6 @@
 Section: libs
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
-Replaces: heimdal-lib (<< 0.3e-5)
-Conflicts: heimdal-libs (<< 0.3e-5)
 Provides: heimdal-hdb-api-8
 Description: Heimdal Kerberos - kadmin server library
  Heimdal is a free implementation of Kerberos 5 that aims to be
diff -Nru heimdal-7.1.0+dfsg/debian/.gitignore 
heimdal-7.1.0+dfsg/debian/.gitignore
--- heimdal-7.1.0+dfsg/debian/.gitignore2016-12-22 05:43:09.0 
+1100
+++ heimdal-7.1.0+dfsg/debian/.gitignore1970-01-01 10:00:00.0 
+1000
@@ -1,34 +0,0 @@
-autoreconf.after
-autoreconf.before
-*.debhelper.log
-heimdal-clients-x
-heimdal-clients/
-heimdal-dev/
-heimdal-docs/
-heimdal-kdc/
-heimdal-multidev/
-tmp/
-*.substvars
-*.debhelper
-files
-heimdal-dbg/
-heimdal-kcm/
-heimdal-servers-x/
-heimdal-servers/
-libasn1-8-heimdal/
-lib

Bug#854554: dpkg: trigger problem with cracklib-runtime while upgrading libcrypt-cracklib-perl from jessie to stretch

[David Kalnischkies]

Control: reassign -1 libcrypt-cracklib-perl 1.7-2
# beware, this is an RC bug!

[CC'ed cracklib2 & perl maintainers as it seems to be some "funny"
interaction between packages in their responsibility space.]

On Sat, Apr 08, 2017 at 04:50:15AM +0200, Guillem Jover wrote:
> [ Please see the bug archive for more context. ]
[…]
> > So the fault is in apt ... and that's jessie's version of apt that is
> > running the upgrade :-(
> > 
> > If I start the upgrade with upgrading only apt (and its dependencies)
> > and thereafter running the dist-upgrade (with squeeze's version of apt),
> > I cannot reproduce the bug.
> 
> Thanks for verifying! Reassigned now to apt.

So, given that apt works in newer versions there remains no action for
the apt team. The responsibility of making an upgrade work with whatever
we have got (bugs included) is by the individual package maintainer(s)
– simply because we (or the release team, or …) can't handle 5
source packages in a reasonable way. [and upgrading apt/dpkg/others
first doesn't work all the time due to … wait for it … dependencies].


That said, we are happy to help of course. The basic idea of convincing
apt to do something it didn't do on its own is adding/removing
dependencies (mostly of the type Depends or Breaks/Conflicts) – that
tends to be helped by some "field knowledge" about the packages in
question which is why the maintainers are best, but given guessing and
creativity are involved anyone can help!

The easiest (although potentially time-consuming) way of finding the
right combination is to make a chroot with the "before upgrade" setup
(= as in the next step would be 'apt-get dist-upgrade' – so update
done), copy the entire chroot, modify the /var/lib/apt/lists/*Packages
file so that it has the "new" dependencies and run the dist-upgrade.
Repeat from copy until happy.

In your case you can potentially speed that up by looking at the output
of "-o Debug::pkgDpkgPm=1" – that shows how dpkg is called (it doesn't
call dpkg!) – which makes the iteration faster at the expense of you
trying to make sense of that: Having "--configure libcrack2" before the
other crack-related packages might be your target (see guess below).

Good luck & as said, ask if you are stuck (please provide the [lengthy]
output of -o Debug::pkgPackageManager=1 -o Debug::pkgDpkgPm=1). We are
reachable via de...@lists.debian.org or #debian-apt on IRC.


That said, educated guess follows:

Looks like apt acts on libcrypt-cracklib-perl early as it looks simple
enough (after upgrading perl) as the dependency on libcrack2 is already
satisfied at the start of the upgrade (as its a version before jessie).
As the dependencies of libcrack2 are very lightweight (just libc6 which
is done at that point) it might already work if you artificially require
a stretch-version here (= guess, not tested at all).


Best regards

David Kalnischkies, who is in a love-hate relationship with triggers


signature.asc
Description: PGP signature

Bug#859864: r-bioc-genomeinfodb: Reorganization of ftp://ftp.ncbi.nlm.nih.gov/genomes/all

[Graham Inggs]

Source: r-bioc-genomeinfodb
Version: 1.10.2-1
Severity: grave
Affects: r-bioc-annotationhub
Tags: upstream fixed-upstream

Hi Maintainer

Autopkgtests of r-bioc-annotationhub started failing on 2017-0126 [1]
with the following error:

Error in checkIdentical(setNames(rep(c(FALSE, TRUE), c(4, 1)), chr),
GenomeInfoDb::isCircular(gr1)) :
  FALSE

In addition: Warning messages:
1: In file(file, "rt") :
  URL 
'https://ftp.ncbi.nlm.nih.gov/genomes/ASSEMBLY_REPORTS/All/GCF_01405.13.assembly.txt':
status was '404 Not Found'
2: In file(file, "rt") :
  URL 
'https://ftp.ncbi.nlm.nih.gov/genomes/ASSEMBLY_REPORTS/All/GCF_01405.13.assembly.txt':
status was '404 Not Found'
require("xxx_foo")

Upon investigation, I found that NCBI recently reorganized the data on
the Genomes FTP site [2].
A new upstream version 1.10.3 is available [3], and it seems the only
changes relate to this reorganization.  I have not yet verified that
this fixes r-bioc-annotationhub's autopkgtests, or that it is the only
affected package.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-bioc-annotationhub/unstable/amd64/
[2] 
https://ftp.ncbi.nlm.nih.gov/genomes/ASSEMBLY_REPORTS/README_change_notice.txt
[3] https://bioconductor.org/packages/release/bioc/html/GenomeInfoDb.html

Bug#833803: oxygen-icon-theme: Gtk-WARNING **: Theme directory base/ of theme default.kde4 has no size field

[Maximiliano Curia]

Control: tag -1 + unreproducible moreinfo

¡Hola Fernando!

El 2016-08-08 a las 21:39 +0200, Fernando Santagata escribió:
Package: oxygen-icon-theme 
Version: 5:5.24.0-1 
Severity: normal 
Tags: patch


I'm running Debian sid. After one update/dist-upgrade cycle I found out that 
starting gvim from the terminal output this message:


(gvim:14295): Gtk-WARNING **: Theme directory base/ of theme default.kde4 has 
no size field


The directory of the theme default.kde4 is a link to the oxygen theme 
directory.



On my system "dpkg -S /usr/share/icons/oxygen" outputs this:


dragonplayer, korganizer, oxygen-icon-theme, kdepim-runtime, konq-plugins, 
kopete, kdepimlibs-data: /usr/share/icons/oxygen


Sorry that it took so long to get back to you.

Currently the issue seems to be no longer reproducible, if possible, can you 
check if the issue is gone for you with the newer versions as well?


so one of those packages wrote something incorrect in the index.theme file. 
When I delved into that file I found out that in the "Directories=" 
configuration parameter, among the other directories listed, there was a 
"base/", which does not have a corresponding section.


All the oxygen icons in this package are installed under base/ so the base/ in 
the index.theme should be fine, wasn't this the case back in 5.24?


Happy hacking,
--
"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense."
-- Edsger W. Dijkstra
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#415396: [debhelper-devel] Bug#415396: "dh_install --list-missing" should ignore manpages and other installed files

[Niels Thykier]

Michael Stapelberg:
> On Sat, Apr 8, 2017 at 7:54 AM, Niels Thykier  wrote:
> 
>> Michael Stapelberg:
>>> On Mon, Apr 3, 2017 at 1:07 PM, Niels Thykier  wrote:
>>>
 [...]
>>>
>>>
>>> Thanks a lot!
>>>
>>> In turn, I created a branch in the freeradius packaging:
>>> https://anonscm.debian.org/cgit/pkg-freeradius/freeradius.git/log/?h=dh_
>> missing
>>>
>>
>> Thanks for trying it out. :)
>>
>>> Maybe I did the wrong changes (?), but when building, I get an error:
>>>
>>> [...]
>>>
>>> Can you reproduce the issue?
>>>
>>>
>>>
>>> [...]
>>
>> I think it is a bug in the freeradius changes.  In this commit:
>>
>> https://anonscm.debian.org/cgit/pkg-freeradius/
>> freeradius.git/commit/?h=dh_missing&id=58e693ff7dd6603598cb132d44c9e9
>> a547f099ed
>>
>> The dh_install call is replaced by dh_missing, but AFAICT that
>> dh_install is inside an override_dh_install, so dh_install is never called.
>>
> 
> Thanks, you are spot on. After re-adding the dh_install command, most of
> the errors vanish. Interestingly enough, this one remains:
> 
> [...]
> 
> I’ve added it to debian/freeradius.install and updated the branch.
>

Sounds good.  I am a little surprised that this gave issues now and not
before.  This smells like it might cause breakage with this change.

Speaking of stuff that might break: We had forgotten to pass --sourcedir
to dh_missing when dh_install calls it (fixed now).

> The only remaining issue as far as the freeradius packaging is concerned is
> dh_installdocs not yet reporting which files it installs — hence the build
> fails at
> https://anonscm.debian.org/cgit/pkg-freeradius/freeradius.git/commit/?h=dh_missing&id=afbb47b0f8646de9fc116d8f494608ef4cef6a90
> 

Ah.  I have deliberately omitted dh_installdocs as I thought people
would normally use dh_install for that kind of thing.  I think I will
keep that behaviour for a while...

Maybe with a documentation change for dh_installdocs that dh_install
might be better for documentation installed by upstream's build system.

> Either way, what you have in the dh_missing branch right now is already
> useful :).
> 
> 
>[...]

Thanks for the initial patches and the testing. :)

~Niels

Bug#854554: dpkg: trigger problem with cracklib-runtime while upgrading libcrypt-cracklib-perl from jessie to stretch

[Niels Thykier]

Control: reassign -1 cracklib-runtime
Control: forcemerge -1 cracklib2
Control: severity 854554 grave

David Kalnischkies:
> Control: reassign -1 libcrypt-cracklib-perl 1.7-2
> # beware, this is an RC bug!
> 
> [CC'ed cracklib2 & perl maintainers as it seems to be some "funny"
> interaction between packages in their responsibility space.]
> 
> [...]
> 
> 
> That said, educated guess follows:
> 
> Looks like apt acts on libcrypt-cracklib-perl early as it looks simple
> enough (after upgrading perl) as the dependency on libcrack2 is already
> satisfied at the start of the upgrade (as its a version before jessie).
> As the dependencies of libcrack2 are very lightweight (just libc6 which
> is done at that point) it might already work if you artificially require
> a stretch-version here (= guess, not tested at all).
> 
> 
> Best regards
> 
> David Kalnischkies, who is in a love-hate relationship with triggers
>

Hi,

Actually, I think a much better solution would be to solve #859307,
which would be the correct long term solution and should solve this
upgrade issue (as -noawait triggers would not be subject to this problem).

Thanks,
~Niels

Bug#859865: [node-test] Package does not package test directory => FTBFS other package

[Bastien ROUCARIÈS]

Package: node-test
Version: 0.6.0-2
Severity: serious
owner: !

will do

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

Bug#415396: [debhelper-devel] Bug#415396: "dh_install --list-missing" should ignore manpages and other installed files

[Michael Stapelberg]

On Sat, Apr 8, 2017 at 10:33 AM, Niels Thykier  wrote:

> Michael Stapelberg:
> > On Sat, Apr 8, 2017 at 7:54 AM, Niels Thykier  wrote:
> >
> >> Michael Stapelberg:
> >>> On Mon, Apr 3, 2017 at 1:07 PM, Niels Thykier 
> wrote:
> >>>
>  [...]
> >>>
> >>>
> >>> Thanks a lot!
> >>>
> >>> In turn, I created a branch in the freeradius packaging:
> >>> https://anonscm.debian.org/cgit/pkg-freeradius/
> freeradius.git/log/?h=dh_
> >> missing
> >>>
> >>
> >> Thanks for trying it out. :)
> >>
> >>> Maybe I did the wrong changes (?), but when building, I get an error:
> >>>
> >>> [...]
> >>>
> >>> Can you reproduce the issue?
> >>>
> >>>
> >>>
> >>> [...]
> >>
> >> I think it is a bug in the freeradius changes.  In this commit:
> >>
> >> https://anonscm.debian.org/cgit/pkg-freeradius/
> >> freeradius.git/commit/?h=dh_missing&id=58e693ff7dd6603598cb132d44c9e9
> >> a547f099ed
> >>
> >> The dh_install call is replaced by dh_missing, but AFAICT that
> >> dh_install is inside an override_dh_install, so dh_install is never
> called.
> >>
> >
> > Thanks, you are spot on. After re-adding the dh_install command, most of
> > the errors vanish. Interestingly enough, this one remains:
> >
> > [...]
> >
> > I’ve added it to debian/freeradius.install and updated the branch.
> >
>
> Sounds good.  I am a little surprised that this gave issues now and not
> before.  This smells like it might cause breakage with this change.
>
> Speaking of stuff that might break: We had forgotten to pass --sourcedir
> to dh_missing when dh_install calls it (fixed now).
>
> > The only remaining issue as far as the freeradius packaging is concerned
> is
> > dh_installdocs not yet reporting which files it installs — hence the
> build
> > fails at
> > https://anonscm.debian.org/cgit/pkg-freeradius/
> freeradius.git/commit/?h=dh_missing&id=afbb47b0f8646de9fc116d8f494608
> ef4cef6a90
> >
>
> Ah.  I have deliberately omitted dh_installdocs as I thought people
> would normally use dh_install for that kind of thing.  I think I will
> keep that behaviour for a while...
>
> Maybe with a documentation change for dh_installdocs that dh_install
> might be better for documentation installed by upstream's build system.
>

Ah, this was news to me. I’ve changed the dh_missing branch to install the
files using dh_install, and now everything works fine :).


>
> > Either way, what you have in the dh_missing branch right now is already
> > useful :).
> >
> >
> >[...]
>
> Thanks for the initial patches and the testing. :)
>
> ~Niels
>
>
>
>


-- 
Best regards,
Michael

Bug#859866: sbuild transiently fails stating apt-get update failed

[Michael Stapelberg]

Package: sbuild
Version: 0.73.0-4
Severity: normal

I may very well be doing something wrong, but I repeatedly run into
the following problem and have no clue as to how to approach fixing
it.

Every once in a while, an sbuild invocation will fail with the
following message:

Reading package lists...
E: Could not open file 
/var/lib/apt/lists/deb.debian.org_debian_dists_sid_main_source_Sources.diff_Index
 - open (2: No such file or directory)
E: apt-get update failed

I can fix this issue by running “sbuild-update -u unstable” twice
(!). The first run fails with the same error message (but stores the
updated package lists), the second run will do the actual update.

Is this a misconfiguration on my end, or a bug in sbuild/schroot/apt?

Find a full session transcript attached.

Thanks in advance for any pointers.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel, arm64

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 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)

Versions of packages sbuild depends on:
ii  adduser 3.115
ii  libsbuild-perl  0.73.0-4
pn  perl:any

Versions of packages sbuild recommends:
ii  autopkgtest  4.3
ii  debootstrap  1.0.88
ii  schroot  1.6.10-3+b1

Versions of packages sbuild suggests:
ii  deborphan  1.7.28.8-0.3+b1
ii  kmod   23-2
ii  wget   1.18-5

-- no debconf information
$ gbp buildpackage --git-export-dir="$(pwd | sed 
's,^/home/michael/d/pkg,/home/michael/d/out,')"
gbp:info: Exporting 'HEAD' to '/home/michael/d/out/freeradius/freeradius-tmp'
gbp:info: Moving '/home/michael/d/out/freeradius/freeradius-tmp' to 
'/home/michael/d/out/freeradius/freeradius-3.0.12+dfsg'
dh clean --with autoreconf
   dh_testdir
   debian/rules override_dh_auto_clean
make[1]: Entering directory 
'/home/michael/d/out/freeradius/freeradius-3.0.12+dfsg'
[ ! -f Make.inc ] || dh_auto_clean
make[1]: Leaving directory 
'/home/michael/d/out/freeradius/freeradius-3.0.12+dfsg'
   dh_autoreconf_clean
   dh_clean
rm -f debian/debhelper-build-stamp
rm -f debian/freeradius.substvars
rm -f debian/freeradius.*.debhelper
rm -rf debian/freeradius/
rm -f debian/freeradius-common.substvars
rm -f debian/freeradius-common.*.debhelper
rm -rf debian/freeradius-common/
rm -f debian/freeradius-config.substvars
rm -f debian/freeradius-config.*.debhelper
rm -rf debian/freeradius-config/
rm -f debian/freeradius-utils.substvars
rm -f debian/freeradius-utils.*.debhelper
rm -rf debian/freeradius-utils/
rm -f debian/libfreeradius3.substvars
rm -f debian/libfreeradius3.*.debhelper
rm -rf debian/libfreeradius3/
rm -f debian/libfreeradius-dev.substvars
rm -f debian/libfreeradius-dev.*.debhelper
rm -rf debian/libfreeradius-dev/
rm -f debian/freeradius-dhcp.substvars
rm -f debian/freeradius-dhcp.*.debhelper
rm -rf debian/freeradius-dhcp/
rm -f debian/freeradius-krb5.substvars
rm -f debian/freeradius-krb5.*.debhelper
rm -rf debian/freeradius-krb5/
rm -f debian/freeradius-ldap.substvars
rm -f debian/freeradius-ldap.*.debhelper
rm -rf debian/freeradius-ldap/
rm -f debian/freeradius-rest.substvars
rm -f debian/freeradius-rest.*.debhelper
rm -rf debian/freeradius-rest/
rm -f debian/freeradius-postgresql.substvars
rm -f debian/freeradius-postgresql.*.debhelper
rm -rf debian/freeradius-postgresql/
rm -f debian/freeradius-mysql.substvars
rm -f debian/freeradius-mysql.*.debhelper
rm -rf debian/freeradius-mysql/
rm -f debian/freeradius-iodbc.substvars
rm -f debian/freeradius-iodbc.*.debhelper
rm -rf debian/freeradius-iodbc/
rm -f debian/freeradius-redis.substvars
rm -f debian/freeradius-redis.*.debhelper
rm -rf debian/freeradius-redis/
rm -f debian/freeradius-memcached.substvars
rm -f debian/freeradius-memcached.*.debhelper
rm -rf debian/freeradius-memcached/
rm -f debian/freeradius-yubikey.substvars
rm -f debian/freeradius-yubikey.*.debhelper
rm -rf debian/freeradius-yubikey/
rm -rf debian/.debhelper/
rm -f debian/*.debhelper.log
rm -f debian/files
find .  \( \( \
\( -path .\*/.git -o -path .\*/.svn -o -path .\*/.bzr -o -path 
.\*/.hg -o -path .\*/CVS \) -prune -o -type f -a \
\( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
 -o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
 -o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \
  

Bug#859867: Please add a package which automatically configures sbuild for Debian packaging

[Michael Stapelberg]

Package: sbuild
Version: 0.73.0-4
Severity: wishlist

I’ve been using sbuild instead of pbuilder for a few years now, and I
generally like it: it seems almost universally better than pbuilder.

One area where sbuild sorely lacks is configuration, though: pbuilder
is very easy to set up, whereas sbuild requires reading through
https://wiki.debian.org/sbuild, performing a bunch of steps, only to
end up with a setup which works fine for unstable, but seems very
clumsy when building packages for experimental or backports.

One solution to this issue that I can see is to add a new binary
package to src:sbuild which — possibly after a brief debconf prompt —
performs all the necessary steps to end up with a setup that just
works.

What are your thoughts on this? Would patches be welcome to add such a
package?

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel, arm64

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 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)

Versions of packages sbuild depends on:
ii  adduser 3.115
ii  libsbuild-perl  0.73.0-4
pn  perl:any

Versions of packages sbuild recommends:
ii  autopkgtest  4.3
ii  debootstrap  1.0.88
ii  schroot  1.6.10-3+b1

Versions of packages sbuild suggests:
ii  deborphan  1.7.28.8-0.3+b1
ii  kmod   23-2
ii  wget   1.18-5

-- no debconf information

Bug#859868: [npm2deb] When using replace version for depends is replaced version

[Bastien ROUCARIÈS]

Package: npm2deb
Version: 0.2.6-1
Severity: important

When using replace the version on depends should be the version of replace 
package not the replaced package version.

Please also warn to patch the .json file



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

Bug#859869: unhelpful completion of file name that contains equals sign and space

[Bruno Haible]

Package: bash-completion
Version: 1:2.1-4.2ubuntu1.1

Hi,

Using bash 4.3.46 (Ubuntu package version 4.3-14ubuntu1.1) and bash-completion
(Ubuntu package version 1:2.1-4.2ubuntu1.1).

In the current directory I have just one file:

$ ls -1
vlc-record-2017-03-28-02h03m23s-dvb-t___frequency=48200-Hits of the 90's.ts

When I type

  mv vlc

it completes to

  mv vlc-record-2017-03-28-02h03m23s-dvb-t___frequency\=48200-Hits\ of\ 
the\ 90\'s.ts 

which is OK. But when I type

  mv vlc-record-2017-03-28-02h03m23s-dvb-t___frequency=482

it completes to

  mv 
vlc-record-2017-03-28-02h03m23s-dvb-t___frequency=vlc-record-2017-03-28-02h03m23s-dvb-t___frequency\=48200-Hits\
 of\ the\ 90\'s.ts 

which no longer matches the file name. Likewise with 'vlc' instead of 'mv'.

Somehow the bash completion inserts the up to the equals sign, which makes
no sense for the programs 'mv' and 'vlc'.

The workaround is to type an extra double-quote [1]:

  mv "vlc-record-2017-03-28-02h03m23s-dvb-t___frequency=482

but *this should not be necessary*.

Bruno

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

Bug#859870: cockpit-ws: broken symlinks: /usr/share/cockpit/branding/*/*

[Andreas Beckmann]

Package: cockpit-ws
Version: 137-3
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m29.7s ERROR: FAIL: Broken symlinks:
  /usr/share/cockpit/branding/ubuntu/logo.png -> 
../../../plymouth/ubuntu-logo.png
  /usr/share/cockpit/branding/rhel/logo.png -> 
../../../pixmaps/system-logo-white.png
  /usr/share/cockpit/branding/rhel/favicon.ico -> /etc/favicon.png
  /usr/share/cockpit/branding/rhel/apple-touch-icon.png -> 
../../../pixmaps/fedora-logo-sprite.png
  /usr/share/cockpit/branding/fedora/logo.png -> 
../../../pixmaps/system-logo-white.png
  /usr/share/cockpit/branding/fedora/favicon.ico -> /etc/favicon.png
  /usr/share/cockpit/branding/fedora/apple-touch-icon.png -> 
../../../pixmaps/fedora-logo-sprite.png
  /usr/share/cockpit/branding/centos/logo.png -> 
../../../pixmaps/system-logo-white.png
  /usr/share/cockpit/branding/centos/favicon.ico -> /etc/favicon.png
  /usr/share/cockpit/branding/centos/apple-touch-icon.png -> 
../../../pixmaps/fedora-logo-sprite.png


cheers,

Andreas


cockpit-ws_137-3.log.gz
Description: application/gzip

Bug#495184: wodim --devices and -scanbus bugs 495184, 655878, 833346

[Thomas Schmitt]

Hi,

the wodim device scan bug vanished and re-appeared with the Debian versions
although /dev/scd* did not re-appear. So there must be some other influence.

I think i can prove from the source code that on kernels with minor
revision number below 6 wodim enumerates /dev/sg*, whereas on kernels with
minor revision number of 6 or larger it tries to enumerate /dev/scd*.

/dev/sg* exist for any device under control of the SCSI driver.
/dev/scd* have become out of fashion. (One can work around the bug by
manually creating links from /dev/scd* to /dev/sr*.)

So with kernel 3.2 of Wheezy the bug vanished and with 3.16 of Jessie it
re-appeared. Early 4.X will not show the bug, but beginning with 4.6 it
will be back again. So Stretch with kernel 4.9 will have it.

Source study:

  https://sources.debian.net/src/cdrkit/9:1.1.11-3/libusal/scsi-linux-sg.c/#L509

/* scan and maybe keep one open, sg_setup decides */
#define HDX 0
#define SCD 1
#define SG 2
...
for(h=HDX; h <= (fake_atabus ? HDX : SG) ; h++) {
...
switch(h) {
case(HDX): 
{
pattern="/dev/hd%c";
...
case(SCD):
{
if(!check_linux_26())
continue;
pattern="/dev/scd%d";
...
case(SG):
{
if(check_linux_26())
continue; 
...
pattern="/dev/sg%d";
...

So it looks for /dev/hd* (drives under old IDE driver) in any case.
If "check_linux_26()" is true, then it looks for /dev/scd*, which
are missing because out of fashion.
If "check_linux_26()" is false, then it looks for /dev/sg*, which exist.

Beginning with Linux 2.5.X it became possible to use /dev/sr*
for ioctl(SG_IO), which does the SCSI command transactions for wodim.
So obviously the test shall distinguish kernel 2.6 or younger from
kernel 2.5 or older.

But at
  https://sources.debian.net/src/cdrkit/9:1.1.11-3/libusal/scsi-linux-sg.c/#L251
there seems to be missing the check for the major kernel version:

BOOL check_linux_26() {
int gen, tmp;
struct utsname buf;
return ( 0==uname( &buf ) && sscanf(buf.release, "%d.%d", &gen, &tmp)>1 
&& tmp>=6);
}

I tested this code on my Jessie. tmp has the value 16 and thus the
function returns 1. So my wodim looks for /dev/scd*.


If there is maintainer interest, then i would propose two code changes:

-
In libusal/scsi-linux-sg.c, check_linux_26(), line 254:

-return ( 0==uname( &buf ) && sscanf(buf.release, "%d.%d", &gen, 
&tmp)>1 && tmp>=6);
+return ( 0==uname( &buf ) && sscanf(buf.release, "%d.%d", &gen, 
&tmp)>1 && (gen>2 || tmp>=6));

This will not change the function result in Jessie and Stretch but maybe
in a future release with kernel 5.X. 

-
In libusal/scsi-linux-sg.c, usalo_open(), line 532:

-   pattern="/dev/scd%d";
+   pattern="/dev/sr%d";

This will fix the enumeration bug on all kernels not older than 2.6.
On older kernels /dev/sg* is still the right path to use.

-


Have a nice day :)

Thomas

Bug#859871: r-cran-sp: autopkgtests depend on non-existent r-cran-rgeos

[Graham Inggs]

Source: r-cran-sp
Version: 1:1.2-4-1

Hi Maintainer

Autopkgtests of r-cran-sp have been failing since the upload of
1:1.2-4-1 [1] with the error:

badpkg: Test dependencies are unsatisfiable. A common reason is that
your testbed is out of date with respect to the archive, and you need
to use a current testbed or run apt-get update or use -U.
adt-run [11:11:21]: ERROR: erroneous package: Test dependencies are
unsatisfiable. A common reason is that your testbed is out of date
with respect to the archive, and you need to use a current testbed

debian/tests/control contains the following [2]:

Tests: run-unit-test
Depends: @, r-cran-runit, r-cran-rgeos
Restrictions: allow-stderr

But r-cran-geos is not in the archive.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-cran-sp/unstable/amd64/
[2] https://sources.debian.net/src/r-cran-sp/1:1.2-4-1/debian/tests/control/#L2

Bug#859776: sponsorship-requests: vis/0.3 [ITP] -- A a modern and legacy free Vim-like text editor

[Paride Legovini]

On 2017-04-07 19:54, Adam Borowski wrote:
> On Fri, Apr 07, 2017 at 05:52:21PM +0200, Paride Legovini wrote:
>> On 2017-04-07 15:39, Adam Borowski wrote:
>>> On Fri, Apr 07, 2017 at 12:54:22PM +0200, Paride Legovini wrote:
  * Package name: vis
Version : 0.3
> 
> Seems to be fine, except for two error messages I get:
> 
> /usr/share/vis/themes/default-256.lua:23: attempt to index a nil value (local 
> 'lexers')
> WARNING: could not find lpeg module
> 

The package now Recommends: lua-lpeg, that is the dependency you are
missing. The upstream README.md lists it as an "optional runtime
dependency", so I think Recommends: is appropriate.

I also changed the priorities for the alternatives for 'editor' and 'vi'
(see debian/postinst). The rationale is that it's OK to prefer vis to
very basic flavors of vim, lettings the ones with more features win. I
also didn't want to override nano, as it is the editor suggested to less
experienced users. Seems reasonable to me, but I'd like to have some
feedback.

Paride

Bug#859872: unblock (pre-approval): flask/0.12.1-1

[Ondřej Nový]

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

Please consider unblocking of flask 0.12.1-1.

This upstream bugfix release fixies this 4 upstream bugs:
- Prevent `flask run` from showing a NoAppException when an ImportError occurs
  within the imported application module.
- Fix encoding behavior of ``app.config.from_pyfile`` for Python 3. Fix
  ``#2118``.
- Use the ``SERVER_NAME`` config if it is present as default values for
  ``app.run``. ``#2109``, ``#2152``
- Call `ctx.auto_pop` with the exception object instead of `None`, in the
  event that a `BaseException` such as `KeyboardInterrupt` is raised in a
  request handler.

And fix unreproducibility build, which is simple fix in docs building.

Debdiff attached.

Thanks.

unblock flask/0.12.1-1

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

Kernel: Linux 4.9.0-2-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)
diff -Nru flask-0.12/CHANGES flask-0.12.1/CHANGES
--- flask-0.12/CHANGES  2016-12-21 21:19:09.0 +0100
+++ flask-0.12.1/CHANGES2017-03-31 18:43:21.0 +0200
@@ -3,6 +3,31 @@
 
 Here you can see the full list of changes between each Flask release.
 
+Version 0.13
+
+
+Major release, unreleased
+
+- Make `app.run()` into a noop if a Flask application is run from the
+  development server on the command line.  This avoids some behavior that
+  was confusing to debug for newcomers.
+- Change default configuration `JSONIFY_PRETTYPRINT_REGULAR=False`. jsonify()
+  method returns compressed response by default, and pretty response in
+  debug mode.
+
+Version 0.12.1
+--
+
+Bugfix release, released on March 31st 2017
+
+- Prevent `flask run` from showing a NoAppException when an ImportError occurs
+  within the imported application module.
+- Fix encoding behavior of ``app.config.from_pyfile`` for Python 3. Fix
+  ``#2118``.
+- Call `ctx.auto_pop` with the exception object instead of `None`, in the
+  event that a `BaseException` such as `KeyboardInterrupt` is raised in a
+  request handler.
+
 Version 0.12
 
 
diff -Nru flask-0.12/debian/changelog flask-0.12.1/debian/changelog
--- flask-0.12/debian/changelog 2016-12-25 16:01:11.0 +0100
+++ flask-0.12.1/debian/changelog   2017-01-13 10:48:48.0 +0100
@@ -1,3 +1,10 @@
+flask (0.12.1-1) UNRELEASED; urgency=medium
+
+  * New upstream bugfix release
+  * Use SOURCE_DATE_EPOCH for copyright year to make build reproducible
+
+ -- Ondřej Nový   Fri, 13 Jan 2017 10:48:48 +0100
+
 flask (0.12-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru flask-0.12/debian/.git-dpm flask-0.12.1/debian/.git-dpm
--- flask-0.12/debian/.git-dpm  2016-12-25 14:58:29.0 +0100
+++ flask-0.12.1/debian/.git-dpm2017-01-13 10:48:48.0 +0100
@@ -1,11 +1,11 @@
 # see git-dpm(1) from git-dpm package
-5219a1a4a282c1277f9c6b1cd4324e8c2d7b95f7
-5219a1a4a282c1277f9c6b1cd4324e8c2d7b95f7
-5219a1a4a282c1277f9c6b1cd4324e8c2d7b95f7
-5219a1a4a282c1277f9c6b1cd4324e8c2d7b95f7
-flask_0.12.orig.tar.gz
-73722d79e479d5f6b09bbb7b746c34a99b81b05c
-531923
+02ae596d3b6eb5e3c4fe1d938dbd86cee32f5b52
+02ae596d3b6eb5e3c4fe1d938dbd86cee32f5b52
+e2758a2dfc6ebddb68ccdfd8d3fa4cdd1a5ff03e
+e2758a2dfc6ebddb68ccdfd8d3fa4cdd1a5ff03e
+flask_0.12.1.orig.tar.gz
+b32d88f36f7a7d262eb6a336b4f0736cfa2a4252
+548511
 debianTag="debian/%e%v"
 patchedTag="patched/%e%v"
 upstreamTag="upstream/%e%u"
diff -Nru 
flask-0.12/debian/patches/0001-Use-SOURCE_DATE_EPOCH-for-copyright-year-to-make-bui.patch
 
flask-0.12.1/debian/patches/0001-Use-SOURCE_DATE_EPOCH-for-copyright-year-to-make-bui.patch
--- 
flask-0.12/debian/patches/0001-Use-SOURCE_DATE_EPOCH-for-copyright-year-to-make-bui.patch
   1970-01-01 01:00:00.0 +0100
+++ 
flask-0.12.1/debian/patches/0001-Use-SOURCE_DATE_EPOCH-for-copyright-year-to-make-bui.patch
 2017-01-13 10:48:48.0 +0100
@@ -0,0 +1,37 @@
+From 02ae596d3b6eb5e3c4fe1d938dbd86cee32f5b52 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ond=C5=99ej=20Nov=C3=BD?= 
+Date: Fri, 13 Jan 2017 10:46:21 +0100
+Subject: Use SOURCE_DATE_EPOCH for copyright year to make build reproducible
+
+---
+ docs/conf.py | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/docs/conf.py b/docs/conf.py
+index b37427a..81106a3 100644
+--- a/docs/conf.py
 b/docs/conf.py
+@@ -11,10 +11,13 @@
+ # All configuration values have a default; values that are commented out
+ # serve to show the default.
+ from __future__ import print_function
+-from datetime import datetime
+ import os
+ import sys
+ import pkg_resources
++import time
++import datetime
++
++BUILD_DATE = 
datetime.datetime.utcfromtimestamp(int(os.environ.get('SOURCE_DATE_EPOCH', 
time

Bug#859808: composite: Composite not ready for being qualified package of Debian yet.

[MAROQQO digital media]

Hi, thanks for your thoughts on this, Jaromir but:

On 04/08/2017 08:52 AM, Jaromír Mikeš wrote:

composite package builds fine and seems to have it's own users ... by popcon
https://qa.debian.org/popcon.php?package=composite


To simply say "well, it has its own users" by showing install graphs of 
150 installs is a very simplified point. Sure it has statistically it's 
"own users". Every available download has that. Pro audio users tend to 
test available software by just grabbing it for a go while they often 
miss a good overview at first. But it says nothing about its real usage. 
Pro audio users often even have no real clue about the OS they run. 
That's why there are so many pro audio multi-packaged bundles around. 
Since I have tested the package I can say that this a 100% copy of an 
old Hydrogen version without progression. Many new users will not know 
what they have here, since there is no explanation about it. It's a lil' 
bit like the mess with ffmpeg and libav and the misleading notice while 
installation back in the days. The reason for the install statistics 
even more prove my worries but do not invalidate them.


To be honest I really wonder about what qualifies a package to be added 
to the repositories of Debian, since I used to tend to the impression, 
that Debian is very picky about it (one of the reasons I choose Debian).


On 04/08/2017 08:52 AM, Jaromír Mikeš wrote:

I am very sorry that some hydrogen users are confused but I personally
don't think it is reason strong enough to remove composite from debian archive


Well, this is not the only reason if you read my start post and btw ... 
it actually is one of the smaller points actually, and "Some" is the 
wrong word here since - as I stated - Composite is a complete copy of an 
8 year old Hydrogen version package and many acknowledged users, who 
know which audio software is available on Linux don't even know this 
package. They were very confused when I told them about it. Even audio 
software developers were confused. It's odd and I can't believe that the 
fact that it is a simple copy of old code which has never started to 
grow and shows no progress isn't reason enough. I really winder how this 
even came in? I am sad that you don't go into any further details about 
all other points I stated and that a simple install graph which grows by 
itself over the years is reason enough for you to say it's ok.


Again:

 + Composite describes its own status as "a broken version of Hydrogen" 
(Look at the sources I have posted, its in their own words)

 + This status has never been changed since 2009
 + Composite stuck in early alpha and completely feels, acts, looks and 
works like Hydrogen, a well known and in active development being audio 
application with the exactly same GUI and features atm.

 + The road map shows that this package is in early state and only
confuses Hydrogen users now since this fork has never left any copy
 paste state yet despite of its name

I am even not sure if there isn't a copyright infringement going on 
since Hydrogen code is published on Github under GPL 2 license which 
resticts you to only use this code by using the same license, but the 
"author" of Composer has no license statement on their site at all. I am 
sorry for sounding offending here, this is not my purpose, but I really 
really wonder about all this ignored points.	

Bug#859873: Updating the torrus Uploaders list

[Mattia Rizzolo]

Source: torrus
Version: 2.09-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Jurij Smakov  has retired, so can't work on
the torrus package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#859873: Updating the torrus Uploaders list

[Marc Haber]

tags #859873 confirmed
thanks

Committed the change to git. Thanks!

Greetings
Marc

Bug#859874: samba-vfs-modules: Error 13005 Accessing Share with OS X 10.5.8/iTunes 10.6.3 when enabling vfs_fruit

[Patrik Schindler]

Package: samba-vfs-modules
Version: 2:4.2.14+dfsg-0+deb8u5
Severity: normal

I learned about vfs_fruit lately since it promises better integration with Macs.

Unfortunately, when Launching iTunes 10.6.3 within PPC Pac OS X 10.5.8, iTunes
complains about error 13005 while opening the iTunes Library. The only option
is to quit iTunes.

Remounting the same volume without vfs_fruit makes iTunes behave as expected.

Yes, these this is rather old software but I'm utilizing an old Mac as a
decent Music player for my living room.

Excerpt from smb.conf:

[global]
# Filesystem Settings
access based share enum = yes
acl map full control = no
client min protocol = NT1
default service = homes
delete readonly = yes
delete veto files = yes
guest ok = no
hide special files = yes
inherit permissions = yes
mangled names = no
map archive = no
map hidden = no
map system = no
read only = no
server signing = auto
unix charset = UTF8
use sendfile = yes
veto files = /.AppleDouble/.AppleDesktop/Network Trash Folder/
write cache size = 4096

[archiv]
comment = Archiv
path = /volumes/archiv
read only = no
valid users = @users
#vfs objects = fruit
#fruit:locking = netatalk
#fruit:copyfile = yes

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

Kernel: Linux 3.16.0-4-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/bash
Init: sysvinit (via /sbin/init)

Versions of packages samba-vfs-modules depends on:
ii  libaio1 0.3.110-1
ii  libattr11:2.4.47-2
ii  libbsd0 0.7.0-2
ii  libc6   2.19-18+deb8u7
ii  libtalloc2  2.1.2-0+deb8u1
ii  libtdb1 1.3.6-0+deb8u1
ii  libtevent0  0.9.28-0+deb8u1
ii  samba-libs  2:4.2.14+dfsg-0+deb8u5

samba-vfs-modules recommends no packages.

samba-vfs-modules suggests no packages.

-- no debconf information

Bug#859875: samba: Please enable avahi support

[Laurent Bigonville]

Source: samba
Version: 2:4.5.8+dfsg-1
Severity: wishlist

Hi,

Any reasons why the avahi support is disabled in debian?

I see the following entry in the debian/changelog file:

samba (2:3.4.1-2) unstable; urgency=low

  * ./configure --disable-avahi, to avoid accidentally picking up an avahi
dependency when libavahi-common-dev is installed.

 -- Steve Langasek   Sat, 26 Sep 2009 00:01:12 -0700

But I'm not sure about the rational behind this.

Quickly looking at the code, it seems that if avahi is not available,
the only thing that will happen is two new debug messages.

Cheers,

Laurent Bigonville

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

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

-- no debconf information

Bug#859876: unblock (pre-approval): python-tornado/4.4.3-1

[Ondřej Nový]

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

Please consider unblock of package python-tornado 4.4.3-1.

This is new upstream bugfix release, which fix this bug:
- The tornado.auth module has been updated for compatibility with a change
  to Facebook’s access_token endpoint.

This version no longer disable PIE during build which was disabled
because of bug which was passing -fPIE to the compiler even for
dynamic libraries.

Debdiff attached.

Thanks.

unblock python-tornado/4.4.3-1

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

Kernel: Linux 4.9.0-2-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/dashInit: systemd (via /run/systemd/system)

Bug#859808: composite: Composite not ready for being qualified package of Debian yet.

[Jonas Smedegaard]

Quoting MAROQQO digital media (2017-04-08 12:49:00)
> Since I have tested the package I can say that this a 100% copy of an 
> old Hydrogen version without progression.

Quite an interesting claim.


> To be honest I really wonder about what qualifies a package to be 
> added to the repositories of Debian, since I used to tend to the 
> impression, that Debian is very picky about it (one of the reasons I 
> choose Debian).

Please bring up that question at debian-devel mailinglist - this 
bugreport is the wrong place for that.


> On 04/08/2017 08:52 AM, Jaromír Mikeš wrote:
> > I am very sorry that some hydrogen users are confused but I 
> > personally don't think it is reason strong enough to remove 
> > composite from debian archive
> 
> Well, this is not the only reason if you read my start post and btw 
> ... it actually is one of the smaller points actually,

Please file separate bugreports for each concrete issue: Discussing "the 
isssue of this package having too many issues" is far easier to do when 
each issue is tracked individually.


 - Jonas

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

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


signature.asc
Description: signature

Bug#859808: composite: Composite not ready for being qualified package of Debian yet.

[James Cowgill]

Control: severity -1 important

[^ Prevent autoremoval while this is disputed]
[+CC Gabriel who may be interested]

Hi,

On 08/04/17 11:49, MAROQQO digital media wrote:
> To be honest I really wonder about what qualifies a package to be added
> to the repositories of Debian, since I used to tend to the impression,
> that Debian is very picky about it (one of the reasons I choose Debian).

These are the rules:
https://www.debian.org/doc/debian-policy/ch-archive.html#s-main

Beyond that there are no other hard rules other than the package should
have a maintainer willing to support it.

> On 04/08/2017 08:52 AM, Jaromír Mikeš wrote:
>> I am very sorry that some hydrogen users are confused but I personally
>> don't think it is reason strong enough to remove composite from debian
>> archive
> 
> Well, this is not the only reason if you read my start post and btw ...
> it actually is one of the smaller points actually, and "Some" is the
> wrong word here since - as I stated - Composite is a complete copy of an
> 8 year old Hydrogen version package and many acknowledged users, who
> know which audio software is available on Linux don't even know this
> package. They were very confused when I told them about it. Even audio
> software developers were confused. It's odd and I can't believe that the
> fact that it is a simple copy of old code which has never started to
> grow and shows no progress isn't reason enough. I really winder how this
> even came in? I am sad that you don't go into any further details about
> all other points I stated and that a simple install graph which grows by
> itself over the years is reason enough for you to say it's ok.
> 
> Again:
> 
>  + Composite describes its own status as "a broken version of Hydrogen"
> (Look at the sources I have posted, its in their own words)
>  + This status has never been changed since 2009
>  + Composite stuck in early alpha and completely feels, acts, looks and
> works like Hydrogen, a well known and in active development being audio
> application with the exactly same GUI and features atm.
>  + The road map shows that this package is in early state and only
> confuses Hydrogen users now since this fork has never left any copy
>  paste state yet despite of its name

[Disclaimer: I do not use hydrogen or composite]

While you have some good points, I don't think any of them are
sufficient reason to force the removal of this package or could even be
regarded as bugs. There are a lot of old packages in Debian which are
not going away any time soon.

If the functionality provided by composite is now in hydrogen or
elsewhere then maybe composite can be removed on the basis that it's
obsolete and has little upstream activity, but since I don't use these
packages I don't really have an opinion on this.

> I am even not sure if there isn't a copyright infringement going on
> since Hydrogen code is published on Github under GPL 2 license which
> resticts you to only use this code by using the same license, but the
> "author" of Composer has no license statement on their site at all. I am
> sorry for sounding offending here, this is not my purpose, but I really
> really wonder about all this ignored points.   

The source is correctly licensed under the GPL. Whether the license is
stated on the upstream website doesn't really matter.

James



signature.asc
Description: OpenPGP digital signature

Bug#859877: debian-maintainers: problem mit instalation HP DeskJet 2130 all-in-one

[kaiser]

Package: debian-maintainers
Severity: normal

näch instälätiön treiber ist pröblem mit pc send dätä züm drükerin ünd nix nüll 
kein drück prögräm weist wen ich knöpfe kräftknöpf :D däs ist älter prögräm für 
debiän 8.6 wärte än neüig ;D

-- System Information:
Debian Release: 8.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 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#859808: composite: Composite not ready for being qualified package of Debian yet.

[trebmuh]

Hi,

if I remember correctly, one of the main goal for the Composite fork of 
Hydrogen, was to get Hydrogen as a LV2 plug.
I just tried it with jalv.select, jalv, jalv.gtk, jalv.gtk3, jalv.gtkmm, 
and jalv.qt and all of them gaves me :

Feature http://lv2plug.in/ns/ext/event is not supported

So I would say that the LV2 versio doesn't work.

Last commit is from March 2013 : 
https://gitlab.com/composite/composite/commits/master


For my point of view, Composite doesn't bring in anything better that 
what Hydrogen does. Hence I'd approve for it to be removed.


Hope that helps,
Olivier

Bug#859878: ITP: ruby-rack-proxy -- request/response rewriting http proxy

[Pirate Praveen]

package: wnpp
severity: wishlist
owner: Pirate Praveen 

from rubygems.org/gems/rack-proxy




-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#859879: RFP: xterm.js -- terminal front-end component for the browser

[Ghislain Antony Vaillant]

Package: wnpp
Severity: wishlist

* Package name: xterm.js
  Version : 2.5.0
  Upstream Author : SourceLair Private Company 
* URL : https://github.com/sourcelair/xterm.js
* License : Expat
  Programming Lang: JavaScript
  Description : terminal front-end component for the browser

Long-Description:
 Xterm.js is a terminal front-end component written in JavaScript that works in
 the browser.
 .
 It enables applications to provide fully featured terminals to their users and
 create great development experiences.
 .
 Features:
 .
   - **Text-based application support**: Use xterm.js to work with applications
 like `bash`, `git` etc.
   - **Curses-based application support**: Use xterm.js to work with
 applications like `vim`, `tmux` etc.
   - **Mouse events support**: Xterm.js captures mouse events like click and
 scroll and passes them to the terminal's back-end controlling process
   - **CJK (Chinese, Japanese, Korean) character support**: Xterm.js renders
 CJK characters seamlessly
   - **IME support**: Insert international (including CJK) characters using IME
 input with your keyboard
   - **Self-contained library**: Xterm.js works on its own. It does not require
 any external libraries like jQuery or React to work
   - **Modular, event-based API**: Lets you build addons and themes with ease

This software is a runtime dependency for the integrated terminal plugin for
the Spyder IDE.

Bug#859880: ITP: spyder-terminal -- plugin to display a virtual terminal within the Spyder IDE

[Ghislain Antony Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: spyder-terminal
  Version : 0.1.0
  Upstream Author : Spyder Project Contributors
* URL : https://github.com/spyder-ide/spyder-terminal
* License : Expat
  Programming Lang: Python
  Description : plugin to display a virtual terminal within the Spyder IDE

Long-Description:
 Spyder Plugin for displaying a virtual terminal (OS independent) inside
 the main Spyder window. Currently it only supports Unix and Unix-like
 operating systems.
 .
 This plugin allows you to execute flawlessly any bash command inside
 spyder, even ncurses applications like nano or vi.

This package will be maintained by the Debian Science Team alongside
the other spyder plugins.

Bug#859808: composite: Composite not ready for being qualified package of Debian yet.

[diqidoq | MAROQQO]

Hello Jonas,

well there is maybe a language barrier causing this?

On 04/08/2017 01:26 PM, Jonas Smedegaard wrote:

Please bring up that question at debian-devel mailinglist - this
bugreport is the wrong place for that.


That was not another issue report. It was a rhetorical statement to 
explain parts of my motivation on this issue. This is not intended and 
never will be an issue to randomly discuss or consume time of you, me 
and others. It is part of my relation to Debian.Nothing else.


On 04/08/2017 01:26 PM, Jonas Smedegaard wrote:
> Please file separate bugreports for each concrete issue: Discussing
> "the isssue of this package having too many issues" is far easier to
> do when each issue is tracked individually.

Jonas, again, this is part of the points to make at this issue, it is 
part of the argumentation. If there would be no point to make, there 
would be no issue. These points are reasons for that issue, not other 
issues. Do you read the whole report completely? This is officialism and 
bureaucracy leads to nowhere. All the points were clearly stated and 
listed and underlined with sources. There is nothing more I can do for it.

Bug#859881: unblock: calendar-exchange-provider/3.9.0-4

[mechtilde]

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

Please unblock package calendar-exchange-provider

The package has a build dependency to thunderbird-dev instead of icedove-dev.
Icedove-dev isn't anymore in sid because of the mozilla exception.
It fix an urgly bug (#854025) too

(include/attach the debdiff against the package in testing)

unblock calendar-exchange-provider/3.9.0-4

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (400, 'testing'), (300, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)


diff -Nru calendar-exchange-provider-3.9.0/debian/changelog calendar-exchange-
provider-3.9.0/debian/changelog
--- calendar-exchange-provider-3.9.0/debian/changelog   2017-03-16
18:53:00.0 +0100
+++ calendar-exchange-provider-3.9.0/debian/changelog   2017-04-08
14:45:28.0 +0200
@@ -1,8 +1,16 @@
+calendar-exchange-provider (3.9.0-4) unstable; urgency=low
+
+  * debian/patches/bugfix-854025.patch:
+- Add patch: accepting events should work now (Closes: #854025)
+  * fixed typo in the last changelog entry
+
+ -- Mechtilde Stehmann   Sat, 08 Apr 2017 14:45:28 +0200
+
 calendar-exchange-provider (3.9.0-3) unstable; urgency=low

   * build for unstable (Closes: #857889)
 + after Thunderbird coming into Sid
-+ unblock request because of mizilla exeption
++ unblock request because of mozilla exception

  -- Mechtilde Stehmann   Thu, 16 Mar 2017 18:53:00 +0100

diff -Nru calendar-exchange-provider-3.9.0/debian/patches/bugfix-854025.patch
calendar-exchange-provider-3.9.0/debian/patches/bugfix-854025.patch
--- calendar-exchange-provider-3.9.0/debian/patches/bugfix-854025.patch
1970-01-01 01:00:00.0 +0100
+++ calendar-exchange-provider-3.9.0/debian/patches/bugfix-854025.patch
2017-04-08 14:43:22.0 +0200
@@ -0,0 +1,21 @@
+bugfix for Bug #854025
+
+--- a/interfaces/exchangeCalendar/mivExchangeCalendar.js
 b/interfaces/exchangeCalendar/mivExchangeCalendar.js
+@@ -5569,10 +5569,14 @@
+   var proposeStart =
this.tryToSetDateValue(input.proposeStart,"");
+   var proposeEnd   = this.tryToSetDateValue(input.proposeEnd,"");
+   var proposeNewTime = false;
+-
++
++  if ( proposeStart ) {
+   input.proposeStart =
cal.toRFC3339(proposeStart.getInTimezone(this.globalFunctions.ecUTC()));
++  }
++  if ( proposeEnd ) {
+   input.proposeEnd   = cal.toRFC3339(proposeEnd.getInTimezone(
this.globalFunctions.ecUTC()));
+-
++  }
++
+   if( input.proposeStart && input.proposeEnd ){
+   proposeNewTime = true;
+   }
diff -Nru calendar-exchange-provider-3.9.0/debian/patches/remove-update-
notification.patch calendar-exchange-provider-3.9.0/debian/patches/remove-
update-notification.patch
--- calendar-exchange-provider-3.9.0/debian/patches/remove-update-
notification.patch2017-03-16 18:51:42.0 +0100
+++ calendar-exchange-provider-3.9.0/debian/patches/remove-update-
notification.patch2017-04-08 14:11:48.0 +0200
@@ -1,4 +1,5 @@
 remove update notification
+
 --- a/defaults/preferences/update.js
 +++ b/defaults/preferences/update.js
 @@ -1 +1,3 @@
diff -Nru calendar-exchange-provider-3.9.0/debian/patches/series calendar-
exchange-provider-3.9.0/debian/patches/series
--- calendar-exchange-provider-3.9.0/debian/patches/series  2017-01-12
16:56:20.0 +0100
+++ calendar-exchange-provider-3.9.0/debian/patches/series  2017-04-08
13:13:34.0 +0200
@@ -1 +1,2 @@
 remove-update-notification.patch
+bugfix-854025.patch

Bug#859808: composite: Composite not ready for being qualified package of Debian yet.

[diqidoq | MAROQQO]

Thanks for your thoughts on this, James, but let me reply on this clearly:

On 04/08/2017 01:35 PM, James Cowgill wrote:

If the functionality provided by composite is now in hydrogen or
elsewhere then maybe composite can be removed on the basis that it's
obsolete and has little upstream activity, but since I don't use these
packages I don't really have an opinion on this.


I think you misunderstood sth here. It is rather upside down. Not the 
functionality provided by composite is now in hydrogen, IT IS Hydrogen 
and ever was, and Composite came later to just made a fork/clone of the 
code of Hydrogen by promising to make something else out of it what 
never happend.



On 04/08/2017 01:35 PM, James Cowgill wrote:
> While you have some good points, I don't think any of them are
> sufficient reason to force the removal

Another point where I thought it should be upside down. Shouldn't there 
be rather reasons to add a package, not reasons to remove one which is 
maybe a duplicate? What were the reasons of this package to be added?


On 04/08/2017 01:35 PM, James Cowgill wrote:
> Beyond that there are no other hard rules other than the package
> should have a maintainer willing to support it.

Wow. o.O ... This is a really hard statement. Are you aware of this? 
Does Debian security team agree with that?


On 04/08/2017 01:35 PM, James Cowgill wrote:
> There are a lot of old packages in Debian which are
> not going away any time soon.

This makes absolutely sense to me, but not with duplicated or mistakenly 
added packages without warnings. Debian has removed ffmpeg and replaced 
it by libav in the days when libav was forking and later has corrected 
this issue very quick in the next release cycle and brought back ffmpeg. 
So I think it is not about "every thing keeps being in when it is in" ...

Bug#859880: Add blocking bugs

[Ghislain Vaillant]

control: block -1 by 780187
control: block -1 by 859879

Bug#859178: pbuilder: source-only changes doesn't handle -sa passed to pbuilder --debbuildopts

[Mattia Rizzolo]

Control: tag -1 unreproducible

On Fri, Mar 31, 2017 at 10:18:01AM +0200, Yves-Alexis Perez wrote:
> I'm forcing the addition of orig.tar by using:
> 
> pdebuild --debbuildopts -sa
> 
> It works fine for _amd64.changes, but not for _sources.changes.

I can't reproduce it.  I haven't tried with linux-grsec, but with
dehydrated:

% pdebuild --debbuildopts -sa
...
 dpkg-genbuildinfo
 dpkg-genchanges -sa >../dehydrated_0.3.1-3_amd64.changes
dpkg-genchanges: info: including full source code in upload< this 
warning comes from the dpkg-genchanges called by dpkg-buildpackage, building 
the _amd64
 dpkg-source --after-build dehydrated-0.3.1
dpkg-buildpackage: info: full upload (original source is included)
dpkg-genchanges: info: including full source code in upload< this 
warning comes from the dpkg-genchanges called by pbuilder, building the _source
% grep orig ~/pbuilder/result/sid/amd64/dehydrated_0.3.1-3_source.changes 
 405ac61cfc74a22b710d3b8bde398bd697b714c6 71375 dehydrated_0.3.1.orig.tar.gz
 405bca85af3a29e1ad2c7c2c0a48fe8bb8ca10ba 488 dehydrated_0.3.1.orig.tar.gz.asc
 7c9b9475b442dd19dbc33a26426444054781e14a2f122d2a2405f81093484239 71375 
dehydrated_0.3.1.orig.tar.gz
 b3c052c0ee14a2646a85329280d5e0018561a80c71b5ecff1697f6c7c4db9972 488 
dehydrated_0.3.1.orig.tar.gz.asc
 7a3b92b963da6469c4a53f051d6efa24 71375 misc optional 
dehydrated_0.3.1.orig.tar.gz
 be73251799134241d786064d9151753e 488 misc optional 
dehydrated_0.3.1.orig.tar.gz.asc
% 


Is what you are observing specific to linux-grsec?  I'd be mostly
surprised by it.

-sa is properly supported by this switch here, as you can see:
https://anonscm.debian.org/git/pbuilder/pbuilder.git/tree/pbuilder-modules#n965

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#859882: libreoffice-l10n-es: Menu shortcuts is wrong when using es locale (Ctrl-N)

[Sebastian Silva]

Package: libreoffice-l10n-es
Version: 1:5.2.6-2
Severity: normal

Dear Maintainer,

I'm used to Ctrl-N for new documents. It's listed by the File Menu (in
Spanish), but in reality, it's accessible with Ctrl-U. Ctrl-N actually is bound
to setting text in Bold. This is a rather visible bug for any serious word
processing work and feels unprofessional. I was unable to find a workaround.

This has been reported upstream but because of the visibility of this bug I
felt it was relevant for upcoming Debian release.

Upstream bug: https://bugs.documentfoundation.org/show_bug.cgi?id=92237

Thanks



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

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

Versions of packages libreoffice-l10n-es depends on:
ii  dpkg1.18.23
ii  libreoffice-common  1:5.2.6-2
ii  locales 2.24-9

Versions of packages libreoffice-l10n-es recommends:
ii  libreoffice-core  1:5.2.6-2

Versions of packages libreoffice-l10n-es suggests:
pn  hyphen-es   
pn  libreoffice-grammarcheck-es 
pn  libreoffice-help-es 
ii  myspell-es [myspell-dictionary-es]  1.11-14
pn  mythes-es   

-- no debconf information

Bug#859883: ycmd: Don't hardcode path to tern for JavaScript completion

[Mirosław Zalewski]

Package: ycmd
Version: 0+20161219+git486b809-1
Severity: normal

Dear Maintainer,

ycmd currently looks for tern (needed for JavaScript completion) in 
~/node_modules/tern. As README.Debian states, this is what users would
get if they run `npm install tern`.

However, npm in Debian is in so bad shape, that it outright fails to
install some packages (see e.g. 780789). It has prompted discussion of
removal of npm from Debian altogether (see 857986). It is very likely
that people will use npm outside of Debian.

It seems that upstream currently prefers to install user-wide npm
modules into `~/.npm-global` (see [1]). ycmd users who follow upstream
instruction (i.e. majority of them) will fail to get tern running inside
ycmd, as paths diverge.

Please consider modifying package to allow for tern to be placed outside
of `~/node_modules/`.

Attached is revised 05-tern-support.patch that will look for tern in
$PATH and resort to ~/node_modules if it was not found.

Best regards,
Mirosław Zalewski

[1] https://docs.npmjs.com/getting-started/fixing-npm-permissions

*** debian/patches/05-tern-support.patch
Description: Debian doesn't have node-tern. This patch is making ycmd to
 use locally installed tern with `npm install tern` command.

Index: ycmd-0+20161219+git486b809/ycmd/completers/javascript/tern_completer.py
===
--- ycmd-0+20161219+git486b809.orig/ycmd/completers/javascript/tern_completer.py
+++ ycmd-0+20161219+git486b809/ycmd/completers/javascript/tern_completer.py
@@ -36,20 +36,14 @@ from ycmd.completers.completer_utils imp
 
 _logger = logging.getLogger( __name__ )
 
-PATH_TO_TERN_BINARY = os.path.abspath(
-  os.path.join(
-os.path.dirname( __file__ ),
-'..',
-'..',
-'..',
-'third_party',
-'tern_runtime',
-'node_modules',
-'tern',
-'bin',
-'tern' ) )
+PATH_TO_TERN_BINARY = utils.PathToFirstExistingExecutable( [ 'tern' ] )
+if not PATH_TO_TERN_BINARY:
+  PATH_TO_TERN_BINARY = os.path.join(
+os.path.expanduser('~'),
+'node_modules',
+'tern')
 
-PATH_TO_NODE = utils.PathToFirstExistingExecutable( [ 'node' ] )
+PATH_TO_NODE = utils.PathToFirstExistingExecutable( [ 'nodejs' ] )
 
 # host name/address on which the tern server should listen
 # note: we use 127.0.0.1 rather than localhost because on some platforms


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (400, 'unstable'), (102, 'experimental'), (10, 
'stable')
Architecture: amd64 (x86_64)

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

Versions of packages ycmd depends on:
ii  libboost-filesystem1.62.0  1.62.0+dfsg-4
ii  libboost-python1.62.0  1.62.0+dfsg-4
ii  libboost-regex1.62.0   1.62.0+dfsg-4
ii  libboost-system1.62.0  1.62.0+dfsg-4
ii  libc6  2.24-9
ii  libclang1-3.9  1:3.9.1-5
ii  libgcc11:6.3.0-11
ii  libpython2.7   2.7.13-2
ii  libstdc++6 6.3.0-11
ii  python-bottle  0.12.13-1
ii  python-frozendict  0.5-1
ii  python-future  0.15.2-4
ii  python-jedi0.10.0~git1+f05c071-1
ii  python-requests2.12.4-1
ii  python-waitress1.0.1-1
ii  python2.7  2.7.13-2
pn  python:any 

Versions of packages ycmd recommends:
pn  libclang-common-3.9-dev  
pn  node-typescript  
ii  vim-youcompleteme0+20161219+git194ff33-1

ycmd suggests no packages.

-- no debconf information

Bug#859808: composite: Composite not ready for being qualified package of Debian yet.

[Jaromír Mikeš]

2017-04-08 12:49 GMT+02:00 MAROQQO digital media :

Hi MAROQQO


> On 04/08/2017 08:52 AM, Jaromír Mikeš wrote:
>
>> composite package builds fine and seems to have it's own users ... by
>> popcon
>> https://qa.debian.org/popcon.php?package=composite
>>
>
> To simply say "well, it has its own users" by showing install graphs of
> 150 installs is a very simplified point.


Yes it is statistic


> Sure it has statistically it's "own users". Every available download has
> that. Pro audio users tend to test available software by just grabbing it
> for a go while they often miss a good overview at first. But it says
> nothing about its real usage. Pro audio users often even have no real clue
> about the OS they run.


Are you joking!!! I am pro_audio user by profession you think that
pro_audio users are so silly!!! You can't be serious!


> That's why there are so many pro audio multi-packaged bundles around.
> Since I have tested the package I can say that this a 100% copy of an old
> Hydrogen version without progression. Many new users will not know what
> they have here, since there is no explanation about it. It's a lil' bit
> like the mess with ffmpeg and libav and the misleading notice while
> installation back in the days. The reason for the install statistics even
> more prove my worries but do not invalidate them.
>

I still don't understand what scary you?

Having Hydrogen and Composite in archive together is totally harmless.
Only reported issue is some "confused Hydrogen users" ( or maybe you? ) ...
do you have some numbers how many of them ?

Maybe we can add note to Hydrogen manpages
"If you want launch Hydrogen double_click Hydrogen icon ... If you want
launch Composite double_click Composite icon"

Sorry for sarcasm, but really think we are solving here pseudo-problem. :/

mira

Bug#859793: fluidsynth: Package has infringed GPL

[Fabian Greffrath]

Am Freitag, den 07.04.2017, 14:16 +0200 schrieb Javier Serrano Polo:
> This source code is freely redistributable and may be used for
> any purpose.
> 
> The license does not grant the right to modify the software. Therefore,
> it is not compatible with GPL-2.1+ (sic) or LGPL-2.0+.

Well, it could be argued that software modification is a purpose in
itself, but I agree that the wording is unfortunate/ambigious.

 - Fabian


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

Bug#859808: composite: Composite not ready for being qualified package of Debian yet.

[James Cowgill]

On 08/04/17 14:01, diqidoq | MAROQQO wrote:
> Thanks for your thoughts on this, James, but let me reply on this clearly:
> 
> On 04/08/2017 01:35 PM, James Cowgill wrote:
>> If the functionality provided by composite is now in hydrogen or
>> elsewhere then maybe composite can be removed on the basis that it's
>> obsolete and has little upstream activity, but since I don't use these
>> packages I don't really have an opinion on this.
> 
> I think you misunderstood sth here. It is rather upside down. Not the
> functionality provided by composite is now in hydrogen, IT IS Hydrogen
> and ever was, and Composite came later to just made a fork/clone of the
> code of Hydrogen by promising to make something else out of it what
> never happend.

I don't think I misunderstood, I just don't know much about hydrogen or
composite. Obviously the GUIs look almost identical, and I think it
would be better to drop composite if users can be switched to hydrogen
with no loss in functionality.

> On 04/08/2017 01:35 PM, James Cowgill wrote:
>> While you have some good points, I don't think any of them are
>> sufficient reason to force the removal
> 
> Another point where I thought it should be upside down. Shouldn't there
> be rather reasons to add a package, not reasons to remove one which is
> maybe a duplicate? What were the reasons of this package to be added?

We're not talking about adding a package. We're talking about either
keeping or removing a package. I think (and hopefully you agree) that we
shouldn't be randomly removing packages without good reasons (some of
which we are currently discussing).

> On 04/08/2017 01:35 PM, James Cowgill wrote:
>> Beyond that there are no other hard rules other than the package
>> should have a maintainer willing to support it.
> 
> Wow. o.O ... This is a really hard statement. Are you aware of this?
> Does Debian security team agree with that?

I don't think there is anything wrong with what I said. Did you actually
read the link I posted?

It says:
> In addition, the packages in main
[...]
> must not be so buggy that we refuse to support them

That should cover the security team's concerns. In reality the release
team has the final say on all this, but they use policy as a guide.

> On 04/08/2017 01:35 PM, James Cowgill wrote:
>> There are a lot of old packages in Debian which are
>> not going away any time soon.
> 
> This makes absolutely sense to me, but not with duplicated or mistakenly
> added packages without warnings. Debian has removed ffmpeg and replaced
> it by libav in the days when libav was forking and later has corrected
> this issue very quick in the next release cycle and brought back ffmpeg.
> So I think it is not about "every thing keeps being in when it is in" ...

I think FFmpeg and libav was a special case where there was lots of
pressure to only have one of them shipping as part of a release. It's
not the same here.

James



signature.asc
Description: OpenPGP digital signature

Bug#859463: ruby-unf-ext FTBFS on ppc64el: unf/table.hh:13539:25: error: narrowing conversion of '-52' from 'int' to 'char' inside { } [-Wnarrowing]

[Niels Thykier]

Antonio Terceiro:
> On Tue, Apr 04, 2017 at 02:26:00PM +, Niels Thykier wrote:
>>[...]
> 
> Nope. That was actually done after the current upstream release that we
> have in Debian, actually tyring to _fix_ the issue. The actual fix comes
> a little later in
> https://github.com/knu/ruby-unf_ext/commit/8a6a735b51ef903200fc541112e35b7cea781856
> 
> I even proposed to revert that:
> https://github.com/knu/ruby-unf_ext/pull/27
> 
> Upstream seems to be cooking a new release, to be released at any time
> now I assume. With or without that special case for ARM, the code buids
> OK under ppc64el.
> 
> I will probably upload that, since the resulting upstream diff looks
> quite unproblematic (if they accept my proposal, the chunk for
> ext/unf_ext/extconf.rb will disappear from the final diff):
> 
> [...]
> 

Great, thanks for following up. :)

I am looking forward to hearing about upstream's take on it and seeing
the fix in stretch. :)

Thanks,
~Niels

Bug#859238: RFS: microsoft-gsl/0.1~2017.03.20~git16a6a41-1

[Коля Гурьев]

04.04.2017 03:22, Mattia Rizzolo пишет:

As others said already, 'microsoft' in the package name is a sad
situation.  Personally, is just a can of worms I do not want to open for
so little, so please rename it to something else (I like 'ms-gsl').


I changed package name to ms-gsl as you want (libmsgsl-dev for .deb 
package). These names sound as good as the previous ones, I think. 
Anyway, I don't know much about these law things.



 Version : 0.1~2017.03.20~git16a6a41-1


I recommend using 0 instead of 0.1 as base version.


Okay, I see this is a good idea. I also updated to a new version as well.


As I said privately, I'd enjoy having a git repository for this :)
Here I feel you could enjoy even more baing the repo out of upstream
git (see an example in the dehydrated package); or you can see my
pencil2d package for an example of a thing building tarball out of
upstream git, ready to be committed; as you prefer.


I temporally uploaded my repo to GitHub [1]. I believe alioth.debian.org 
will be a better location. I've registered there (my username is 
mymedia-guest) just now.


The first commit in that repository corresponds to what I uploaded to 
mentors.debian.net. I made final modifications (for this stage) in the 
last, 8dec145.


I also made get-orig-source target in d/rules. It clones the upstream 
repository and pack it in a tar archive. I made it because I hadn't 
found any tarball on upstream GitHub.



* test building, I noticed it didn't take advantage of my quad-core
  system; why didn't you use compat level 10?


I'm Ubuntu user, but there is only debhelper of version 9 in ubuntu 
repositories. So I added --parallel option into d/rules file as an 
interim solution.



* please send that UnitTest.patch upstream; that's clearly one of those
  cases their stupid system with a case-insensitive file system tricked
  them…
* that empty directory tests/unittest-cpp, why didn't you remove it?


It seems the upstream doesn't need this patch because they use a last 
version of UnitTeset++ framework where the header has capital letters.
Was I supposed to delete that directory? I thought it was in the 
upstream repo and I shouldn't have touch it.


04.04.2017 20:25, PICCORO McKAY Lenz пишет:

this "library" does not provide real funtionallity, its only to code "as
moscosoft like"


You got the wrong idea. This library is an implementation of C++ Core 
Guidelines written by Bjarne Stroustrup and Herb Sutter. It could very 
well be included into a future C++ Standard. You have not to regard this 
as a creature of evil Microsoft. See an old announce [2].


Theoretically, this may not be the only implementation, but I could not 
find another one. If you get a replacement, I'll be very glad. But right 
now your attacks are unconstructive and blatantly false.


[1] https://github.com/mymedia2/ms-gsl
[2] 
https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines

Bug#857137: squid3: on Debian Jessie: /etc/init.d/squid3 returncode is wrong with conf file with errors

[Amos Jeffries]

Control: notfixed -1 3.5.12-1

Apologies, I misread the diff. It was correct and I have applied the
patch for next unstable upload.

For Jesse both the upstream and Eric's patches need to be applied to
close this bug properly.

Amos

Bug#859859: Forwarded license problem

[Bastien ROUCARIES]

control: forwarded -1 https://github.com/RReverser/acorn-jsx/issues/68

They are some license issue that could be solved on debian side but
better upstream

Bug#859884: Later versions of flatpak requires rofiles-fuse from ostree package

[Sebastian Rasmussen]

Package: flatpak
Version: 0.9.1+git20170403

While attempting to do the steps in the GNOME newcomer wiki:
https://wiki.gnome.org/Newcomers/ I tried to compile gnome-maps
using GNOME Builder which in turn was based on my Debian/testing
system's flatpak 0.8.4-3. This worked perfectly. But when compiling
another program I ran into issues on #gnome-builder I was
recommended to upgrade to flatpak 0.9.1. After checking that the
dependencies would be fulfilled I installed:

http://ftp.us.debian.org/debian/pool/main/f/flatpak/flatpak_0.9.1+git20170403.1-2_amd64.deb
http://ftp.us.debian.org/debian/pool/main/f/flatpak/flatpak-builder_0.9.1+git20170403.1-2_amd64.deb
http://ftp.us.debian.org/debian/pool/main/f/flatpak/gir1.2-flatpak-1.0_0.9.1+git20170403.1-2_amd64.deb

As a first step I tried to compile gnome-maps which had worked
well with the previous version. But now I ran into the following error:

Error: Can't spawn rofiles-fuseFailed to execute child process
"rofiles-fuse" (No such file or directory)

The reason being that the rofiles-fuse binary was missing.
Running apt-file search rofiles-fuse revealed that this program
is included in ostree. And after installing this program the
compilation worked without a problem. Also the compilation
that required flatpak 0.9.1 was now successful.

This leads me to believe that flatpak ought to depend on
ostree to make rofiles-fuse available. I'm not 100% if flatpak,
flatpak-builder or libflatpak0 should depend on ostree (or
perhaps all three packages). That decisiion is left as an
exercise for the maintainer (the people on #gnome-builder
might be able to help out if you find it unclear). :)

 / Sebastian

Bug#858836: unblock: h5py/2.7.0-1 (pre-approval)

[Niels Thykier]

Control: tags -1 confirmed

Ghislain Vaillant:
> On Wed, 2017-04-05 at 17:23 +, Niels Thykier wrote:
>> Control: tags -1 moreinfo
>>
>> I am happy to ack the provided debdiff.  Alternatively, if you want the
>> 2.7 release, I would like to see the debdiff first.  It does sound like
>> it would make sense in this case.
> 
> It is the case, indeed. I have attached the corresponding debdiff for
> 2.7.0-1. Let me know whether you are happy with it.
> 
> Ghis
> 

Ack, please go with the new upstream release if you prefer that.

Please remove the moreinfo tag once the upload is complete and has been
built on all relevant release architectures.

Thanks,
~Niels

Bug#859238: RFS: microsoft-gsl/0.1~2017.03.20~git16a6a41-1

[Mattia Rizzolo]

Control: retitle 859221 ITP: ms-gsl -- Microsoft Guidelines Support Library
Control: reitle -1 RFS: ms-gsl/0~git20170403.ebab8ca-1

On Sat, Apr 08, 2017 at 05:33:35PM +0300, Коля Гурьев wrote:
> 04.04.2017 03:22, Mattia Rizzolo пишет:
> > As I said privately, I'd enjoy having a git repository for this :)
> > Here I feel you could enjoy even more baing the repo out of upstream
> > git (see an example in the dehydrated package); or you can see my
> > pencil2d package for an example of a thing building tarball out of
> > upstream git, ready to be committed; as you prefer.
> 
> I temporally uploaded my repo to GitHub [1]

Nice, would you also please push upstream and prisitine-tar branches?
(you may name upstream and debian branches as you see fit, just be sure
HEAD points to the packaging branch and debian/gbp.conf reflects the
reality if it's not the default)

> I believe alioth.debian.org
> will be a better location. I've registered there (my username is
> mymedia-guest) just now.

As you saw, I made a request for you to access collab-maint.

> I also made get-orig-source target in d/rules. It clones the upstream
> repository and pack it in a tar archive. I made it because I hadn't found
> any tarball on upstream GitHub.

Cool.

> > * test building, I noticed it didn't take advantage of my quad-core
> >   system; why didn't you use compat level 10?
> 
> I'm Ubuntu user, but there is only debhelper of version 9 in ubuntu
> repositories. So I added --parallel option into d/rules file as an interim
> solution.

Look better, debhelper >= 10 is available in xenial, yakkety and zesty.
Besides, in theory you are supposed to test your packages in Debian too
:P

Also, it shouldn't matter much, as you should be building your packages
in the current development version, using a chroot (see tools like
pbuilder or sbuild).


BTW, being an ubuntu user you might also consider to subscribe to the
launchpad package.  An Ubuntu developer (it wasn't me!) synced the
package in Ubuntu zesty already, and there is already a bug open there
too https://launchpad.net/ubuntu/+source/telegram-desktop (same for
ms-gsl once it will be there).
Just so you know, I have upload rights to Ubuntu's universe too (i.e. I
am a MOTU).

> > * please send that UnitTest.patch upstream; that's clearly one of those
> >   cases their stupid system with a case-insensitive file system tricked
> >   them…
> 
> It seems the upstream doesn't need this patch because they use a last
> version of UnitTeset++ framework where the header has capital letters.

| + In libunittest++ debian package others paths are.

The grammar of this sentence is off :)
I suggest "In the libunittest++ debian package the paths are different".
But is it really just a debian thing? :O  Or upstream changed something?

> [1] https://github.com/mymedia2/ms-gsl



-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#858281: hydrogen: Please remove GMkit content from the package due to license

[Jaromír Mikeš]

2017-03-22 8:14 GMT+01:00 Jaromír Mikeš :

>
>
> 2017-03-20 19:03 GMT+01:00 Roberto :
>
> Hi Roberto,
>
> Package: hydrogen
>> Severity: normal
>>
>> Content under directory data/drumkits/GMkit is derived from non-free
>> sources (seems to be taken from Roland XV-5080 internal sound libraries).
>> The file data/drumkits/GMkit/drumkit.xml only says "undefined license".
>>
>> Manufacturers of hardware synthesizers sometimes don't say which license
>> applies to their bundled sample libraries, but they are certainly not in
>> the public domain. They typically allow commercial content created with
>> them, without paying royalties, but they could complain if someone creates
>> a competing product derived from their sounds. A software synthesizer can
>> be seen as a competing product (there are precedents of this by Roland
>> Corporation in particular).
>>
>> Moreover, please consider documenting all files under "data" directory in
>> debian/copyright, it will make easier to spot this issues, I've been using
>> the Roland samples in this package for years without knowing.
>>
>
> Thank you for reporting this issue.
> Actually it is quite unfortunate ... If we would remove GMkit we would
> loose tutorial demo songs.
> Is there any alternative for GMkit around with friendly license
> which we could recommend to upstream author as replacement for GMkit?
>

Just for record ...
I have been discussing this issue with upstream developers ... GMkit should
be replaced
by something with friendly license. Hopefully in next release.

mira

Bug#859885: No longer necessary, should not be released with stretch

[Michael Biebl]

Package: gnome-shell-extension-refreshwifi
Version: 6.0-1
Severity: serious

Hi,

this extensions was originally developed to work around a bug in
gnome-shell:
https://bugzilla.gnome.org/show_bug.cgi?id=767918

This has been fixed in the mean time in gnome-shell 3.22.2 and that fix
is available in sid and stretch.

I therefor think this extension should not be shipped in stretch (or
even removed completely) as this is apparently confusing for users who
think they still need this. See e.g. the comments in 
https://plus.google.com/u/0/+ThorstenLeemhuis/posts/C4NwM8em9md

This was triggered by Jonathans blog post. Would be great if you can
update it accordingly and remove the reference to this particular
extension.

Regards,
Michael



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

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

Bug#859885: No longer necessary, should not be released with stretch

[Michael Biebl]

Am 08.04.2017 um 17:10 schrieb Michael Biebl:
> Package: gnome-shell-extension-refreshwifi
> Version: 6.0-1
> Severity: serious
> 
> Hi,
> 
> this extensions was originally developed to work around a bug in
> gnome-shell:
> https://bugzilla.gnome.org/show_bug.cgi?id=767918
> 
> This has been fixed in the mean time in gnome-shell 3.22.2 and that fix
> is available in sid and stretch.

https://git.gnome.org/browse/gnome-shell/commit/?h=gnome-3-22&id=3fd65055f93e67fcc3dd595c61c453096908ec09

That's the commit, that went into the gnome-3-22 branch


-- 
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#808006: plasma-framework: Networkmanager icons partially broken

[Maximiliano Curia]

Version: 5.18.0-1

¡Hola Petteri!

El 2015-12-15 a las 10:11 +0200, Petteri M escribió:
Package: plasma-framework 
Version: 5.16.0-1 
Severity: normal 
Tags: upstream


Debian 8.2.0 Testing from DVD1. After upgrading to Plasma 5.4.3 (plasma- 
framework-5.16.0-1) via APT from 5.4.2 (plasma-framework-5.15.0-1) 
Networkmanager system tray applet icons are partially missing for WWAN cards.


- Tray icon is missing entirely 
- WWAN on/off icon is missing entirely 
- Wired ethernet icon is inverted when off (inactive) so not visible when using 
Breeze Dark system theme 
- WWAN icons for network type are missing from the icon file (network.svgz):
UMTS, HSDPA, HSUPA, EDGE, GPRS so not displayed but a generic icon is displayed 
instead 
- LTE icons not tested


Tested to replace only the icon file at 
/usr/share/plasma/desktoptheme/default/icons/network.svgz with the one in 
plasma-framework-5.15.0-1. All the icons are displayed and function as they 
should.


Sorry that it took so long to get back to you.

I remember seeing some of these issues, I think these were fixed in 5.17.0 
upstream, and in 5.18.0-1 in Debian. I'm closing the issue based on my 
memory, please reopen if you can still reproduce these issue.


Happy hacking,
--
"I decry the current tendency to seek patents on algorithms. There are better
ways to earn a living than to prevent other people from making use of one's
contributions to computer science."
-- Donald Knuth
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#859886: opendict: ENTER doesn't work

[Christian Buhtz]

Package: opendict
Version: 0.6.7-1
Severity: important

Dear Maintainer,

when hitting ENTER in the "Word:" search field it has no effect. I have to use
the "Look Up" button to start the search.

But the tooltip of the search field indicates that it should work with ENTER.

kind



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

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

Versions of packages opendict depends on:
ii  python-wxgtk3.0  3.0.2.0+dfsg-3+b1
pn  python:any   

opendict recommends no packages.

Versions of packages opendict suggests:
pn  dictd 
pn  festival  

-- no debconf information

Bug#858642: jessie-pu: package libdatetime-timezone-perl/1:1.75-2+2017b

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2017-04-02 at 22:38 +0200, gregor herrmann wrote:
> On Sun, 02 Apr 2017 21:24:33 +0100, Adam D. Barratt wrote:
> 
> > On Fri, 2017-03-24 at 20:21 +0100, gregor herrmann wrote:
> > > I've prepared an update for libdatetime-timezone-perl in jessie,
> > > adding the changes from tzdata 2017b as a quilt patch.
> > 
> > Please go ahead.
> 
> Thank you; uploaded.

Flagged for acceptance; thanks.

Regards,

Adam

Bug#852998: jessie-pu: package dropbear/2014.65-1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2017-04-02 at 19:46 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2017-01-28 at 20:38 +0100, Guilhem Moulin wrote:
> > Moritz Mühlenhoff from the Security Team suggested to fix dropbear's
> > known vulnerabilities (CVE-2016-3116 and CVE-2016-740[6-8]) via a point
> > release, since they don't warrant a DSA.
> [...]
> > Could you consider to have it included in the upcoming point release?
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#858547: jessie-pu: package plv8/1.4.2.ds-2+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2017-04-02 at 21:41 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2017-03-23 at 11:42 +0100, Christoph Berg wrote:
> > I would like to upload plv8 to jessie. Is that acceptable?
> [...]
> > +plv8 (1.4.2.ds-2+deb8u1) jessie; urgency=high
> > +
> > +  * Security bugfix picked from 1.4.9: Check for permission to call 
> > functions.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#857434: jessie-pu: package synergy/1.4.16-1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2017-03-19 at 17:16 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2017-03-10 at 22:52 -0600, Joshua Honeycutt wrote:
> > I'm proposing this update to fix a crash in the synergy client on arm
> > arch.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#856171: jessie-pu: package nvidia-graphics-drivers/340.102-1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2017-04-02 at 21:44 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2017-02-25 at 22:55 +0100, Andreas Beckmann wrote:
> > to fix the next round of CVEs in nvidia-graphics-drivers, we need a new
> > upstream release in stable, again.
> > Intentionally no +deb8u1 suffix, since I want to prevent version
> > inflation in the followup pu request for nvidia-graphics-modules.
> > The Linux 4.10 support patches are not needed for stable, but make the
> > live easier for people running current kernels - this is also what we
> > ship in nvidia-graphics-drivers-legacy-340xx for stretch.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#856174: jessie-pu: package nvidia-graphics-drivers-legacy-304xx/304.135-1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2017-04-02 at 21:45 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2017-02-25 at 23:38 +0100, Andreas Beckmann wrote:
> > a new upstream release is needed to fix the latest CVE series in the
> > legacy driver too.
> > 
> > Intentionally no +deb8u1 suffix to reduce the version number inflation
> > when backporting this to wheezy(-backports).
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#855345: jessie-pu: package systemd/215-17+deb8u7

[Adam D. Barratt]

Control: tags -1 + pending

On Mon, 2017-04-03 at 01:06 +0200, Michael Biebl wrote:
> Am 02.04.2017 um 23:00 schrieb Cyril Brulebois:
> > Adam D. Barratt  (2017-04-02):
> >> Apologies for the delay in getting back to you.
> >>
> >> The proposed diff looks okay to me but, whilst afaics the udeb
> >> shouldn't be affected, I'd still appreciate a d-i ack; CCing and
> >> tagging appropriately.
> 
> Thanks for the review.
> 
> 
> > No objections (note the “via via” in the diff though)
> 
> Fixed that and uploaded.

Flagged for acceptance into p-u.

Regards,

Adam

Bug#859315: src:libsodium: There's check-in to VCS for latest releases

[Roger Shimizu]

On Thu, 6 Apr 2017 22:18:20 +0200
László Böszörményi (GCS)  wrote:

> On Sun, Apr 2, 2017 at 6:35 AM, Roger Shimizu  wrote:
> > d/control shows the VCS should be:
> >  - http://trismegisto.no-ip.org/hg/libsodium-debian
> >
> > But I cannot find latest releases in VCS above.
> > Please kindly help to push your latest work to some VCS repo.
>  While still not finished, I transition the VCS to:
> https://github.com/gcsideal/debian-libsodium

Really appreciated!
Please also kindly include the backports version.

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


pgp6LUbzqRCa2.pgp
Description: PGP signature

Bug#859751: xtrs: please pass buildflags

[G. Branden Robinson]

At 2017-04-07T20:08:05+0200, Graham Inggs wrote:
> On 7 April 2017 at 19:06, G. Branden Robinson
>  wrote:
> > All of this hardening stuff, as I understand it, involves mitigation
> > strategies for unsafe memory usage in the C language family in the ELF
> > object file format.
> 
> It's not only hardening stuff, it's whatever flags someone building
> the package locally would like, e.g.
> one could 'export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed' from
> debian/rules and expect everything to be linked with that option.

Ah, okay.  That melts my objections away like butter.

It looks like no great effort is required to address this; the problem
is that the compile_rom target in the Makefile is the only one that
invokes $(CC) without passing $(LDFLAGS).  With your argument above I
can even justify recommending this change to upstream.

Thanks for the discussion!

Regards,
Branden

Bug#859888: Impossible to install a kernel module for a specific kernel version in a clean manner

[Kraus, Sebastian]

Package: dkms
Version: 2.2.0.3-2
Architecture: all


Hello,


the script /usr/lib/dkms/dkms_autoinstaller includes the following command in 
line 42:


dkms autoinstall --kernelver $kernel .

This does not allow to install modules for a specific/exclusive kernel version 
and ignores the list of kernel versions set in /usr/lib/dkms/common.postinst . 
Having a look at the man page or the online help of dkms, you see that dkms 
command autoinstall does not accept any further option(s). Is this behaviour 
intended or a mistake?



Best greetings



Sebastian Kraus

Bug#858817: unblock: user-manager/4:5.8.5-2

[Maximiliano Curia]

Control: tag -1 - moreinfo

¡Hola Niels!

El 2017-04-05 a las 17:09 +, Niels Thykier escribió:

Maximiliano Curia:
Package: release.debian.org 
Severity: normal 
User: release.debian@packages.debian.org 
Usertags: unblock


KDE Plasma 5.8 is an LTS release that I consider fit to be updated in stretch. 
This particular request is for user-manager 5.8.5.



The fixes included in the user-manager 5.8.5 release are:
 translation updates 
 2 bug fixes:
  + Hide "automatic login" button in UserAccounts since is does absolutely 
nothing (4761ae3) KDE#363058 
This is fixed in 5.9 
  + Revert "Do not ask for root permissions when it's unnecessary" (f2c69db) 
KDE#373276 
This broke adding new users when not setting realname or adminflag (i.e. 
at present there is no way to create a !admin user at all).



On the Debian side there are no changes worth mentioning.



I'm attaching the full debdiff, the gitlogs of the upstream changes.


Currently the version 4:5.8.5-1 is in experimental, and I'll upload the 
4:5.8.5-2 version to unstable if this gets approved.



Please unblock package user-manager



Happy hacking,



unblock user-manager/4:5.8.5-2



Ack, please go ahead.


Thanks, uploaded and already built in all the release architectures.

Next time, please consider excluding the translations from the debdiff 
(filterdiff -x '**/*.po') as it would have made the review a lot easier.


Thanks for the tip. Would you prefer having both the full debdiff and the 
poless debdiff or just the second?


Happy hacking,
--
"Get your data structures correct first, and the rest of the program will
write itself"
-- David Jones
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#859885: No longer necessary, should not be released with stretch

[Michael Biebl]

Am 8. April 2017 18:25:06 MESZ schrieb Jonathan Carter :
>+1, package should be removed
>
  
Should I reassign this bug to ftp.debian.org so the package is removed 
completely?

Bug#859889: installation-reports: successful install on s390x, but no tasksel

[Philipp Kern]

Package: installation-reports
Severity: normal

-- Package-specific info:

Boot method: IPL from CMS
Image version: https://d-i.debian.org/daily-images/s390x/daily/ 2017-04-08 00:01
Date: 

Machine: IBM 2964 (z13)
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [-]
Load installer modules: [O]
Clock/timezone setup:   [-]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [E]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

I booted the installation using the current daily image. I got the new
persistent network card naming and networking/HDD/installation worked
just fine.

The final system booted fine, again with persistent network naming
and with an sshd pre-installed.

I was confused however, why tasksel was not shown to me at all. Given
that the sshd was actually there post-install that was in fact fine.
AFAICS priority:standard was installed by default.

-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20170408-00:00"
X_INSTALLATION_MEDIUM=generic

==
Installer hardware-summary:
==
uname -a: Linux ldebpk02 4.9.0-2-s390x #1 SMP Debian 4.9.18-1 (2017-03-30) 
s390x GNU/Linux
lsmod: Module  Size  Used by
lsmod: dm_mod147456  0
lsmod: md_mod155648  0
lsmod: xfs  1347584  0
lsmod: libcrc32c  16384  1 xfs
lsmod: btrfs1359872  0
lsmod: xor16384  1 btrfs
lsmod: zlib_deflate   32768  1 btrfs
lsmod: raid6_pq  102400  1 btrfs
lsmod: vfat   24576  0
lsmod: fat86016  1 vfat
lsmod: ext4  692224  1
lsmod: crc16  16384  1 ext4
lsmod: jbd2  126976  1 ext4
lsmod: crc32c_generic 16384  4
lsmod: fscrypto   32768  1 ext4
lsmod: mbcache16384  2 ext4
lsmod: qeth_l245056  1
lsmod: dasd_eckd_mod 118784  11
lsmod: dasd_mod   98304  6 dasd_eckd_mod
lsmod: qeth  126976  1 qeth_l2
lsmod: ccwgroup   20480  1 qeth
df: Filesystem   1K-blocks  Used Available Use% Mounted on
df: none41006444410020   0% /run
df: devtmpfs   2044972 0   2044972   0% /dev
df: /dev/dasda17033144740988   5915168  11% /target
df: /dev/dasda17033144740988   5915168  11% /dev/.static/dev
df: devtmpfs   2044972 0   2044972   0% /target/dev
free:  total used free   shared  buffers
free: Mem:   4100608   972440  31281686406064944
free: -/+ buffers: 907496  3193112
free: Swap:  19531160  1953116
/proc/cmdline: ro locale=C  
   s390-netdevice/choose_networktype=qeth 
s390-netdevice/qeth/layer2=true  
s390-netdevice/qeth/choose=0.0.0340-0.0.0341-0.0.0342   
netcfg/get_ipaddress=148.100.42.155 netcfg/get_netmask=255.255.255.128  
netcfg/get_gateway=148.100.42.129 netcfg/get_nameservers=8.8.8.8
netcfg/confirm_static=true netcfg/get_hostname=ldebpk02 
netcfg/get_domain=kern.pm   
network-console/authorized_keys_url=https://github.com/pkern.keys   
preseed/url=https://people.debian.org/~pkern/preseed-s390x-auto.cfg
/proc/cpuinfo: vendor_id   : IBM/S390
/proc/cpuinfo: # processors: 2
/proc/cpuinfo: bogomips per cpu: 20325.00
/proc/cpuinfo: max thread id   : 0
/proc/cpuinfo: features : esan3 zarch stfle msa ldisp eimm dfp etf3eh highgprs 
vx sie 
/proc/cpuinfo: cache0  : level=1 type=Data scope=Private size=128K 
line_size=256 associativity=8
/proc/cpuinfo: cache1  : level=1 type=Instruction scope=Private 
size=96K line_size=256 associativity=6
/proc/cpuinfo: cache2  : level=2 type=Data scope=Private size=2048K 
line_size=256 associativity=8
/proc/cpuinfo: cache3  : level=2 type=Instruction scope=Private 
size=2048K line_size=256 associativity=8
/proc/cpuinfo: cache

Bug#859890: savelog(8): -D documentation does not match the actual effect

[Ivan Shmakov]

Package:  debianutils
Version:  4.8.1
Severity: minor
Tags: patch

As currently implemented, the -D option does not match its
documentation.  Specifically, savelog(8) reads:

-D dateformat
override date format, in the form of [MMDDhhmm[[CC]YY][.ss]]

While in fact -D argument is passed to date(1) ‘+’ (see below),
and as such follows (a superset of) the strftime(3) format.

$ nl -ba < savelog 
…
87  DOT_Z=".gz"
88  DATUM=`date +%Y%m%d%H%M%S`
89  
…
   153  d) datum=1 ;;
   154  D) DATUM=$(date +$OPTARG) ;;
   155  t) touch=1 ;;

On a related note, while savelog has some extraneous quoting in
assignments (a="$b" is no different to a=$b), the lack of double
quotes around $OPTARG above means trouble.

Please thus consider the patches MIMEd.

  * savelog.8: Refer to date(1) for -D option format.  closes: #XXX.
  * savelog: Fix missing quotes around -D option argument.

-- 
FSF associate member #7257  np. На дальней станции сойду — Гражданская Оборона
--- a/savelog.8
+++ b/savelog.8
@@ -135,8 +135,13 @@
 use standard date for rolling
 .TP
 .B "\-D dateformat"
-override date format, in the form of
-.I [MMDDhhmm[[CC]YY][.ss]]
+override date format, in the form accepted by
+.BR date (1)
+(default:
+.BR "%Y%m%d%H%M%S" ","
+provided
+.B -d
+is used)
 .TP
 .B \-r
 use
--- a/savelog
+++ b/savelog
@@ -151,7 +151,7 @@ while getopts m:u:g:c:r:CdD:tlphjJ123456789x:nq opt ; do
 	r) rolldir="$OPTARG" ;;
 	C) forceclean=1 ;;
 	d) datum=1 ;;
-	D) DATUM=$(date +$OPTARG) ;;
+	D) DATUM=$(date +"$OPTARG") ;;
 	t) touch=1 ;;
 	j) COMPRESS="bzip2"; COMPRESS_OPTS="-f"; COMPRESS_STRENGTH_DEF="-9"; DOT_Z=".bz2" ;;
 	J) COMPRESS="xz"; COMPRESS_OPTS="-f"; COMPRESS_STRENGTH_DEF=""; DOT_Z=".xz" ;;

Bug#692962: policy-remove makes postinst fail when files are missing

[Stephen Kitt]

Control: reassign -1 cli-common
Control: tag -1 + patch

On Sun, Nov 11, 2012 at 02:26:47PM +0100, Eduard Bloch wrote:
> Just what the subject says. It must run through even when some files are
> lost.

The following patch fixes this:

diff -ur cli-common-0.9+nmu1.orig/policy-remove 
cli-common-0.9+nmu1/policy-remove
--- cli-common-0.9+nmu1.orig/policy-remove  2015-02-25 21:34:08.0 
+0100
+++ cli-common-0.9+nmu1/policy-remove   2017-04-08 20:47:09.029065259 +0200
@@ -11,4 +11,4 @@
 
 #echo "Removing GAC policy file ($POLICY) from available GACs"
 /usr/share/cli-common/gac-package-remove $POLICY > /dev/null
-rm /usr/share/cli-common/packages.d/$POLICY.installcligac
+rm -f /usr/share/cli-common/packages.d/$POLICY.installcligac


Regards,

Stephen


signature.asc
Description: PGP signature

Bug#859310: xserver-xorg-video-nvidia-legacy-304xx: Failed to load module nvidia (module does not exist, 0) No drivers available.

[A. F. Cano]

On Thu, Apr 06, 2017 at 12:44:32AM +0100, Luca Boccassi wrote:
> ...
> The problem is that your dpkg alternative is set to use mesa rather
> than nvidia to provide glx. That's why the symlink was missing.
> 
> You can fix this manually by running:
> 
> sudo update-glx --config glx

Mmm...  Running this returns:

There is only one alternative in link group glx (providing
/usr/lib/glx): /usr/lib/mesa-diverted
Nothing to configure.
Processing triggers for glx-alternative-mesa (0.7.4) ...
Processing triggers for libc-bin (2.24-9) ...

I wonder what else I need.  Libg11-nvidia-legacy-304xx-glx is
installed (version 304.135)

> And by choosing /usr/lib/nvidia at the selection menu.
> 
> I see you mention you had to fix things up "manually" when moving from
> nouveau to nvidia. I assume that's where things went wrong, as this is
> normally done automatically when installing through the nvidia-driver
> package.
> 
> Do you have a log with the exact steps you've taken after the upgrade?

>From my notes at the time:

In Jessie I was using the nvidia driver 304.131.  After the upgrade to
stretch was done, the nvidia driver 304.135 was installed and the X
server didn't start.

Not knowing what had happened, I started looking around and noticed that
there was "libnvidia-legacy-304xx-compiler" which was not installed, so
installed it.  It made no difference.  Then did:

dpkg-reconfigure nvidia-legacy-304xx-kernel-dkms

which unloaded the current driver, recompiled and re-installed it again.
but it made no difference.

Up to this point, /etc/X11/xorg.conf had a line to use the "nvidia"
driver.

Thinking that the 304 driver was not the right one, I uninstalled it
(via aptitude) and tried to use the nouveau driver (set xorg.conf to
use "nouveau" instead of "nvidia") that I hoped had been fixed enough
to work (it didn't before even in Jessie).

I had a good screen until it went blank because of the screen saver and
then it never reappeared.  I did realize I didn't have kde installed so
instlled kde-full (via aptitude) as that was what was installed in
Jessie - not sure why the upgrade to Stretch got rid of kde.

After I switched to "nouveau" in /etc/X11/xorg.conf I got a screen that
worked but the new kde didn't recognize any of the settings I had under
Jessie, so I had to manually re-configure just about everything to get it
to look like it did before, and I'm still not done.  It seems almost
impossible to get the same look.  Many of the  panel apps I had don't
seem to be available any more.

Furthermore, the nouveau driver had almost constant video artifacts,
like big triangles with apex at the top left corner that covered almost
the whole screen until I gave focus to different konsole windows and
then they went on top; and lock-ups which would require a reboot after
getting in via ssh.

When I realized that the 304xx driver was the correct one and noticed
that after the upgrade some packages for 340xx were installed, I removed
all the 340xx packages.

Then did:

dpkg-reconfigure nvidia-legacy-304xx-kernel-dkms

and it failed because the kernel headers were not installed (for kernel
4.9.0-2-686-pae),  Had to install linux-headers-686-pae.  This probably
happened because the kernel was upgraded at some point and the headers
were not.  After running the dpkg-reconfigure above, nouveau was still
being loaded.  The file /etc/nvidia/nvidia-blacklists-nouveau.conf
contains "blacklist nouveau" but it says in the comment I need to run
update-intiramfs -u, so I did.  No difference, the nouveau driver is
still being loaded.  This is probably a real bug; maybe the
nvidia-blacklists-nouveau.conf file is not referred to by the package
that needs to know about it?

Created /etc/modprobe.d/blaclist.conf and put in it:

blacklist nouveau

and that did it, now the nvidia driver was loaded per lsmod but the X
server still didn't see it.

It was then that I figured out I needed the symlink:

ln -s /usr/lib/nvidia/legacy-304xx/nvidia_drv.so
/usr/lib/xorg/modules/drivers/nvidia_drv.so

which was what made it work.

I have noticed other issues, like selecting the "tiny" border for
windows doesn't give borders any smaller than the normal ones.  Also
some fonts are extremely small and can't be changed.  I wonder if these
issues are related.

> Kind regards,
> Luca Boccassi

Thank you for replying.  If there are other things I should try please
let me know.

Augustine

Bug#859891: yaml-cpp: CVE-2017-5950

[Salvatore Bonaccorso]

Source: yaml-cpp
Version: 0.5.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/jbeder/yaml-cpp/issues/459
Control: clone -1 -2
Control: reassign -2 src:yaml-cpp0.3
Control: found -2 0.3.0-1.1
Control: retitle -2 yaml-cpp0.3: CVE-2017-5950

Hi,

the following vulnerability was published for yaml-cpp.

CVE-2017-5950[0]:
| The SingleDocParser::HandleNode function in yaml-cpp (aka LibYaml-C++)
| 0.5.3 allows remote attackers to cause a denial of service (stack
| consumption and application crash) via a crafted YAML file.

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

The issue is easily reproducible with the payload provided in the
upstream report, using the parser in util/parse.cpp and reduce the
stack size for easier reprodibility.

For further information see:

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

Regards,
Salvatore

Bug#859238: RFS: microsoft-gsl/0.1~2017.03.20~git16a6a41-1

[Коля Гурьев]

08.04.2017 18:07, Mattia Rizzolo пишет:

Nice, would you also please push upstream and prisitine-tar branches?
(you may name upstream and debian branches as you see fit, just be sure
HEAD points to the packaging branch and debian/gbp.conf reflects the
reality if it's not the default)


Done.


Look better, debhelper >= 10 is available in xenial, yakkety and zesty.
Besides, in theory you are supposed to test your packages in Debian too
:P

Also, it shouldn't matter much, as you should be building your packages
in the current development version, using a chroot (see tools like
pbuilder or sbuild).


Oh, I was a fool, I didn't note that this version is available in 
xenial-updates repository. I used xenial in chroot jail for ensure that 
all dependencies are specified correctly. But pbuilder or sbuild seem so 
complicated for me.



> It seems the upstream doesn't need this patch because they use a last

version of UnitTeset++ framework where the header has capital letters.


| + In libunittest++ debian package others paths are.

The grammar of this sentence is off :)
I suggest "In the libunittest++ debian package the paths are different".
But is it really just a debian thing? :O  Or upstream changed something?


Sorry, English isn't my native language (you already know it) :-(
As for libunittest++, I think it relates to old version of this package 
in Debian archive, v1.4. A new version v2.0 is available, but it looks 
that everything works okay.

Bug#859889: installation-reports: successful install on s390x, but no tasksel

[Philipp Kern]

I wasn't sure how to tell if reportbug already attached information. At
least d-i's syslog is attached to this mail.


syslog.gz
Description: application/gzip

Bug#858375: libmongo-client-doc: uninstallable after binNMU

[Ivo De Decker]

Control: tags -1 patch pending

Hi,

On Tue, Mar 21, 2017 at 06:44:57PM +0100, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package is no longer
> installable in sid:
> 
> The following packages have unmet dependencies:
>  libmongo-client-doc : Depends: libmongo-client0 (= 0.1.8-2) but 0.1.8-2+b2 
> is to be installed
> 
> The wrong dependencies are generated by using dh_installdocs --link-doc
> between arch:all and arch:any packages. (#766711)

I prepared an NMU (patch attached). I'll upload it shortly.

Cheers,

Ivo

diff -Nru libmongo-client-0.1.8/debian/changelog 
libmongo-client-0.1.8/debian/changelog
--- libmongo-client-0.1.8/debian/changelog  2015-07-08 14:42:04.0 
+0200
+++ libmongo-client-0.1.8/debian/changelog  2017-04-08 21:57:18.0 
+0200
@@ -1,3 +1,10 @@
+libmongo-client (0.1.8-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't use link-doc between arch:all and arch:any (Closes: #858375).
+
+ -- Ivo De Decker   Sat, 08 Apr 2017 21:57:18 +0200
+
 libmongo-client (0.1.8-2) unstable; urgency=medium
 
   * New Maintainer (Closes: #770801).
diff -Nru libmongo-client-0.1.8/debian/libmongo-client-doc.maintscript 
libmongo-client-0.1.8/debian/libmongo-client-doc.maintscript
--- libmongo-client-0.1.8/debian/libmongo-client-doc.maintscript
1970-01-01 01:00:00.0 +0100
+++ libmongo-client-0.1.8/debian/libmongo-client-doc.maintscript
2017-04-08 21:57:18.0 +0200
@@ -0,0 +1 @@
+symlink_to_dir /usr/share/doc/libmongo-client-doc 
/usr/share/doc/libmongo-client0 0.1.8-2.1~
diff -Nru libmongo-client-0.1.8/debian/rules libmongo-client-0.1.8/debian/rules
--- libmongo-client-0.1.8/debian/rules  2015-07-08 14:43:55.0 +0200
+++ libmongo-client-0.1.8/debian/rules  2017-04-08 21:57:18.0 +0200
@@ -55,9 +55,6 @@
 ##
 # Overrides common to both
 ##
-override_dh_installdocs:
-   dh_installdocs --link-doc=libmongo-client0
-
 override_dh_compress:
dh_compress -Xusr/share/doc/libmongo-client0/examples/ \
-Xusr/share/doc/libmongo-client0/html/

Bug#859893: qa.debian.org: counting typo on jenkins.debian.net about page

[Vagrant Cascadian]

Package: qa.debian.org
Severity: minor
Tags: patch

I noticed on https://jenkins.debian.net/userContent/about.html:

  five quad-cores (cbxi4a, cbxi4b, and ff4a) with 4gb ram, 

But it's clearly having counting troubles, there are only three
systems of that category.

Please merge "the-number-of-the-counting-shall-be-three" branch from:

  https://anonscm.debian.org/git/users/vagrant/jenkins.debian.net.git


Or if you'd rather, here's the one-liner patch:


diff --git a/README b/README
index a42e4882..0a5610a4 100644
--- a/README
+++ b/README
@@ -142,7 +142,7 @@ Installation tests inside chroot environments.
 ** for 'i386' we are also using four virtual machines, 
profitbricks-build(2+6+12+16)-i386, which have 10 or 9 cores and 36gb ram each. 
pb2+12 run emulated AMD Opteron CPUs and pb6+16 Intel Xeon CPUs. These nodes 
are also sponsored by 
link:https://jenkins.debian.net/userContent/thanks.html[Profitbricks].
 ** for 'amd64' we are using eight "moonshot" sleds, codethink-sled9-15-arm64, 
which have 8 cores and 64gb ram each. These nodes are sponsored by 
link:https://jenkins.debian.net/userContent/thanks.html[Codethink].
 ** To test 'armhf' we are using 24 small boards donated by vagrant@d.o:
-*** five quad-cores (cbxi4a, cbxi4b, and ff4a) with 4gb ram,
+*** three quad-cores (cbxi4a, cbxi4b, and ff4a) with 4gb ram,
 *** three octo-cores (odxu4, odxu4b and odxu4c) with 2gb ram,
 *** eleven quad-cores (wbq0, cbxi4pro0, ff2a, ff2b, odu3a, opi2a, opi2b, 
opi2c, jtk1a, p64b and p64c) with 2gb ram, 
 *** two dual-core (bbx15 and cb3a) with 2gb ram and,


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#859587: fixed in x2goserver 4.0.1.20-3

[Andreas Beckmann]

Control: found -1 4.0.1.20-3

On Fri, 07 Apr 2017 15:10:02 + Mike Gabriel 
wrote:

>* debian/control:
>  + Add to D (x2goserver-fmbindings): shared_mime-info. (Closes: #859587).

Wrong solution. Now the package fails to purge if shared-mime-info is no
longer installed.
Correct solution: Drop dependency again and drop useless
update-mime-database call from maintainer scripts. This is already
handled via triggers.


Andreas

Bug#859893: qa.debian.org: counting typo on jenkins.debian.net about page

[Mattia Rizzolo]

Control: reassign -1 jenkins.debian.org

On Sat, Apr 08, 2017 at 01:44:46PM -0700, Vagrant Cascadian wrote:
> Package: qa.debian.org

Leaving the merging to Holger, just letting you know that we now have a
jenkins.debian.org pseudo-package for jenkins stuff, please use that
instead.

(btw: are you subscribed to the debian-qa ML?)

> Severity: minor
> Tags: patch
> 
> I noticed on https://jenkins.debian.net/userContent/about.html:
> 
>   five quad-cores (cbxi4a, cbxi4b, and ff4a) with 4gb ram, 
> 
> But it's clearly having counting troubles, there are only three
> systems of that category.
> 
> Please merge "the-number-of-the-counting-shall-be-three" branch from:
> 
>   https://anonscm.debian.org/git/users/vagrant/jenkins.debian.net.git
> 
> 
> Or if you'd rather, here's the one-liner patch:
> 
> 
> diff --git a/README b/README
> index a42e4882..0a5610a4 100644
> --- a/README
> +++ b/README
> @@ -142,7 +142,7 @@ Installation tests inside chroot environments.
>  ** for 'i386' we are also using four virtual machines, 
> profitbricks-build(2+6+12+16)-i386, which have 10 or 9 cores and 36gb ram 
> each. pb2+12 run emulated AMD Opteron CPUs and pb6+16 Intel Xeon CPUs. These 
> nodes are also sponsored by 
> link:https://jenkins.debian.net/userContent/thanks.html[Profitbricks].
>  ** for 'amd64' we are using eight "moonshot" sleds, 
> codethink-sled9-15-arm64, which have 8 cores and 64gb ram each. These nodes 
> are sponsored by 
> link:https://jenkins.debian.net/userContent/thanks.html[Codethink].
>  ** To test 'armhf' we are using 24 small boards donated by vagrant@d.o:
> -*** five quad-cores (cbxi4a, cbxi4b, and ff4a) with 4gb ram,
> +*** three quad-cores (cbxi4a, cbxi4b, and ff4a) with 4gb ram,
>  *** three octo-cores (odxu4, odxu4b and odxu4c) with 2gb ram,
>  *** eleven quad-cores (wbq0, cbxi4pro0, ff2a, ff2b, odu3a, opi2a, opi2b, 
> opi2c, jtk1a, p64b and p64c) with 2gb ram, 
>  *** two dual-core (bbx15 and cb3a) with 2gb ram and,
> 
> 
> live well,
>   vagrant



-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#857852: dpkg-maintscript-helper: symlink_to_dir in maintscript file should act on specified package name

[Markus Koschany]

Hi,

Am 08.04.2017 um 05:05 schrieb Guillem Jover:
> On Fri, 2017-03-17 at 16:31:27 +0100, Markus Koschany wrote:
[...]

To me there seems to be some confusion which package should document the
information which I have requested in this bug report. In have no strong
preferences whatsoever but it should be documented somehow.

At the moment the man page of dpkg-maintscript-helper appears to be the
only source of information how to handle the four use cases of
(rm_conffile, mv_conffile, symlink_to_dir and dir_to_symlink). Aside
from man dh_installdeb I couldn't find any information in debhelper
about *.maintscript files and how to use them correctly.

If debhelper is the correct place to document this, then please reassign
to debhelper. Though at least I would expect a link or pointer to the
additional documentation in man dpkg-maintscript-helper.

>> It should be more obvious why the package argument is
>> needed at all when you have to create one $PACKAGE.maintscript file per 
>> package anyway.
> 
> This is rather confused, and has nothing to do with how
> dpkg-maintscript-helper operates, but rather how debhelper uses its
> files and how it might or might not add the package arguments on its
> own.

Exactly it is confusing and thus my bug report. According to
/usr/share/debhelper/autoscripts/maintscript-helper debhelper just calls
dpkg-maintscript-helper with the arguments provided in its maintscript
files. For me dpkg and debhelper are just two sides of the same coin.

>> Please also clarify that [package] does not imply that a single maintscript
>> file will act on the binary[package].
> 
> I'm no sure what you mean here exactly, but this seems to me it's
> something for debhelper to document if at all.

You need one maintscript file per binary package. I thought I could get
away with one maintscript file and use it like that

symlink_to_dir /usr/share/doc/holotz-castle
/usr/share/doc/holotz-castle-data 1.3.14-8~ holotz-castle
symlink_to_dir /usr/share/doc/holotz-castle-editor
/usr/share/doc/holotz-castle-data 1.3.14-8~ holotz-castle-editor

I understand that maintscript files work like every other debhelper file
now, but the reason what got me confused in the first place was the
[package] argument and the documentation in dpkg-maintscript-helper.

>> I think an example how to use dpkg-maintscript-helper with debhelper's
>> maintscript files would also be appreciated.
> 
> This would be a layer violation, I'm not planning on documenting how
> upper layers are using dpkg in this way. Please get debhelper to
> clarify any of this if it's not yet clear.

As I said at the beginning I have no strong preferences but honestly the
man page of dpkg-maintscript-helper is the best place to document use
cases. At least I would appreciate it if you pointed to additional
information about maintscript files because that's what a lot of
maintainers actually use.

Regards,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#859808: composite: Composite not ready for being qualified package of Debian yet.

[Gabriel Beddingfield]

Hi all,

I'm the developer of Composite. In my humble opinion, Composite should
never have been added to Debian. It was not ready. While it did offer a
little bit of useful functionality (the hydrogen drumkits as an LV2
plugin), it overall was the beginnings of a new project, and Debian added
it before it even developed a character of its own. It was never intended
that it would detract from or cause confusion with the original Hydrogen
project. The only reason why it looks like an old version of Hydrogen is
that I had not yet gotten around to a useable replacement UI. And while I
would love to go back to work on the project, for all intents and purposes
it's dead. I don't have time to work on it.

And as compiler changes and libraries move forward, I don't think the
Debian devs should bother maintaining this package.

Whoever added it to Debian I'm sure had good intentions, perhaps thinking
it would help the project. However, it did not help the project.

I support the removal of Composite from Debian.

-gabe

Bug#859894: not compatible with latest OMEMO standard and clients

[W. Martin Borgert]

Package: gajim-omemo
Version: 1.0.0-1
Severity: grave

Set to grave, because
"makes the package in question unusable by most ... users".

As outcome of a security audit of the OMEMO protocol (XMPP e2e
encryption method), it has been changed:

The auth tag is no longer appended to the payload, but now to
the key.

Because all clients now change to the new scheme, gajim-omemo
needs to change, too. Upstream is updated already.

Bug#859895: jenkins.debian.org: use jenkins.debian.org for bug reports

[Vagrant Cascadian]

Package: jenkins.debian.org
Severity: normal
Tags: patch

The about page:

  https://jenkins.debian.net/userContent/about.html

Appears to be out of date, as now the jenkins.debian.org
pseudo-package exists in the Debian bug tracking system, as well as
the qa-jenkins-dev list. Update the CONTRIBUTING document accordingly.


Patch available in "bts-jenkins.debian.org" branch at:

  https://anonscm.debian.org/cgit/users/vagrant/jenkins.debian.net.git


Also included here for reference:

commit 87dd1de8968ea737f11bb18a86f6fc04c8781702
Author: Vagrant Cascadian 
Date:   Sat Apr 8 14:50:00 2017 -0700

Use jenkins.debian.org and qa-jenkins-dev list for contributions.

diff --git a/CONTRIBUTING b/CONTRIBUTING
index ddd27e9b..e5f525ce 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -1,9 +1,9 @@
 === Contributing code to this project
 
 It's helpful to track fixes or new features via wishlist bugs against the
-'qa.debian.org' package, eg with the 'reportbug' tool ('devscripts' package).
+'jenkins.debian.org' package, eg with the 'reportbug' tool ('devscripts' 
package).
 The BTS will ensure the developers' mailing list
-   debian...@lists.debian.org
+   qa-jenkins-...@lists.debian.org
 is notified.
 
 The code is available in the 
link:https://anonscm.debian.org/git/qa/jenkins.debian.net.git/tree/[jenkins.debian.net.git
 repository].
@@ -24,7 +24,7 @@ One possible workflow:
   git commit -a
   git format-patch -M origin/master
 
-  reportbug qa.debian.org
+  reportbug jenkins.debian.org
   # 
 
 


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#840750: RFS: picocoin/0.1-2.gbp43047g

[Dave Steele]

Sorry for the delay.

Concerning your latest upload, 0.1-2+nmu1:

- The yellow flags on the mentors page should be cleared
  - This is not an NMU (non-maintainer upload). Look at
the help message associated with the lintian issue.
  - the home page and Vcs links are commented out in
control. Those should be enabled.
  - The watch file is important, and not complicated in
this case. Google 'debian watch github'.

- The package failed to build from source (FTBFS), using
  pdebuild. Is there a missing build dependency?

I haven't looked much farther than that.

Bug#788585: dsh: overwrites host list with a symlink

[Ivo De Decker]

Control: tags -1 patch pending

Hi,

On Thu, Apr 06, 2017 at 10:58:58PM +0200, Ivo De Decker wrote:
> On Sun, Nov 22, 2015 at 04:32:34PM +0100, Andreas Bombe wrote:
> > The symlink is not marked as a conffile because debhelper (specifically
> > dh_installdeb) does not mark symlinks to be installed in /etc as
> > conffiles. According to #421346 this is intentional as dpkg does not
> > work correctly with conffile symlinks (#421344, #690051). Thus the
> > apparent fix of marking it as a conffile explicitly is likely unwise.
> 
> The workaround is to stop shipping the symlink in the package, but create it
> in postinst (and remove it on purge in postrm). This probably needs some care
> to handle the upgrade.

I prepared an NMU that does that (patch attach). I will upload it shortly.

Cheers,

Ivo

diff -u dsh-0.25.10/debian/changelog dsh-0.25.10/debian/changelog
--- dsh-0.25.10/debian/changelog
+++ dsh-0.25.10/debian/changelog
@@ -1,3 +1,10 @@
+dsh (0.25.10-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't ship symlink for /etc/dsh/group/all. (Closes: #788585)
+
+ -- Ivo De Decker   Sat, 08 Apr 2017 23:58:21 +0200
+
 dsh (0.25.10-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u dsh-0.25.10/debian/postrm dsh-0.25.10/debian/postrm
--- dsh-0.25.10/debian/postrm
+++ dsh-0.25.10/debian/postrm
@@ -1,6 +1,9 @@
 #! /bin/sh
 
 if [ "$1" = "purge" ]; then
+  rm -f /etc/dsh/group/all
+  # might be created in preinst on upgrade
+  rm -f /etc/dsh/group/all.dpkg-backup
   rmdir --ignore-fail-on-non-empty /etc/dsh/group
   rmdir --ignore-fail-on-non-empty /etc/dsh
 fi
diff -u dsh-0.25.10/debian/rules dsh-0.25.10/debian/rules
--- dsh-0.25.10/debian/rules
+++ dsh-0.25.10/debian/rules
@@ -56,7 +56,6 @@
$(MAKE) install DESTDIR=$(CURDIR)/debian/dsh
cp $(CURDIR)/debian/machines.list 
$(CURDIR)/debian/dsh/etc/dsh/machines.list
cp $(CURDIR)/dsh.conf $(CURDIR)/debian/dsh/etc/dsh/dsh.conf
-   ln -s ../machines.list $(CURDIR)/debian/dsh/etc/dsh/group/all
install -d $(CURDIR)/debian/dsh/usr/lib/update-cluster
install -m 755 $(CURDIR)/debian/dsh.updatelist 
$(CURDIR)/debian/dsh/usr/lib/update-cluster/
 
diff -u dsh-0.25.10/debian/postinst dsh-0.25.10/debian/postinst
--- dsh-0.25.10.orig/debian/postinst
+++ dsh-0.25.10/debian/postinst
@@ -0,0 +1,27 @@
+#! /bin/sh
+
+if [ "$1" = "configure" ] && [ -z "$2" ]; then
+   if [ ! -e /etc/dsh/group/all ]
+   then
+   # manually create the symlink instead of shipping it
+   # see https://bugs.debian.org/788585
+   ln -s ../machines.list /etc/dsh/group/all
+   fi
+fi
+
+# see preinst
+SYMLINK="/etc/dsh/group/all"
+LASTVERSION="0.25.10-1.3~"
+
+if [ "$1" = "configure" ] &&
+   [ -n "$2" ] &&
+   dpkg --compare-versions -- "$2" le-nl "$LASTVERSION"; then
+   if [ -e ${SYMLINK}.dpkg-backup -o -h ${SYMLINK}.dpkg-backup ] &&
+  [ ! -e "$SYMLINK" ]
+   then
+   mv -f "${SYMLINK}.dpkg-backup" "$SYMLINK"
+   fi
+fi
+
+#DEBHELPER#
+
diff -u dsh-0.25.10/debian/preinst dsh-0.25.10/debian/preinst
--- dsh-0.25.10.orig/debian/preinst
+++ dsh-0.25.10/debian/preinst
@@ -0,0 +1,20 @@
+#! /bin/sh
+
+# Handle the upgrade from the symlink shipped in the package to the symlink
+# created by the postinst
+# see https://bugs.debian.org/788585
+
+# this code is based on symlink_to_dir in dpkg-maintscript-helper
+
+# note that this also works if /etc/dsh/group/all is not a symlink
+SYMLINK="/etc/dsh/group/all"
+LASTVERSION="0.25.10-1.3~"
+
+if [ "$1" = "install" -o "$1" = "upgrade" ] &&
+   [ -n "$2" ] && [ -h "$SYMLINK" -o -e "$SYMLINK" ] &&
+   dpkg --compare-versions -- "$2" le-nl "$LASTVERSION"; then
+   mv -f "$SYMLINK" "${SYMLINK}.dpkg-backup"
+fi
+
+#DEBHELPER#
+

Bug#859896: nmu: gtk-sharp3_2.99.3-2

[Andreas Beckmann]

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

nmu gtk-sharp3_2.99.3-2 . ANY . unstable . -m "Rebuild against mono 4"

gtk-sharp3 was last built in 2014 against mono 3.2.8+dfsg (in jessie) ...

adequate reports 

  libmono-profiler-gui-thread-check: missing-symbol-version-information 
/usr/lib/libmono-profiler-gui-thread-check.so.0.0.0 => 
/usr/lib/libmonoboehm-2.0.so.1

(that's the only package in sid getting this tag)

Rebuilding it against the current mono in sid/stretch (4.6.2.7+dfsg-1)
fixes this, it also switches a dependency from libmonoboehm-2.0-1 to
libmonosgen-2.0-1 (both from src:mono). It's probably better if that
happens before the release than by a security upload later on (if such
should happen). libmono-profiler-gui-thread-check is also the only
package outside src:mono still having a dependency on
libmonoboehm-2.0-1, while libmonosgen-2.0-1 has some users.


Andreas

Bug#858476: RFS: wolfssl/3.10.2+dfsg-1 [RC] -- wolfSSL encryption library

[Felix Lechner]

For some reason, the latest version enabled SHA-224 only on amd64. Upstream
advised that the algorithm should be available on all architectures. I
uploaded an updated package to Mentors
, but did not cross-build. Will
you please try again? Thank you!


On Fri, Apr 7, 2017 at 7:53 PM, Adam Borowski  wrote:

> On Wed, Mar 22, 2017 at 12:15:49PM -0700, Felix Lechner wrote:
> > I am looking for a sponsor for my package "wolfssl":
> >
> >   * Package name: wolfssl
> > Version : 3.10.2+dfsg-1
>
> > It builds those binary packages:
> >
> > libwolfssl10 - wolfSSL encryption library
>vs libwolfssl3 in unstable, but as there are no rdepends, no transition
> is needed, so that's ok
> > libwolfssl-dev - Development files for the wolfSSL encryption library
>
> >   Changes since the last upload:
> >
> >   * New upstream release.
> >   * New major version is 10
> >   * New maintainer email address
> >   * Fixes a low level vulnerability for buffer overflow when loading a
> > malformed temporary DH file
> >   * Fixes a medium level vulnerability for processing of OCSP response
> >   * Fixes CVE-2017-6076, a low level vulnerability for a potential cache
> attack
> > on RSA operations (Closes: #856114)
>
> I'm afraid it FTBFSes due to missing symbols on many architectures: out of
> those I tried, it succeeds on amd64 and x32, fails on armhf, arm64 and
> i386.
>
>
> --- debian/libwolfssl10.symbols (libwolfssl10_3.10.2+dfsg-1_armhf)
> +++ dpkg-gensymbolsptZH0b   2017-04-08 02:31:07.803935398 +
> @@ -135,7 +135,7 @@
>   wc_InitRng_ex@Base 3.10.2
>   wc_InitRsaKey@Base 3.10.2
>   wc_InitRsaKey_ex@Base 3.10.2
> - wc_InitSha224@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_InitSha224@Base 3.10.2
>   wc_InitSha256@Base 3.10.2
>   wc_InitSha384@Base 3.10.2
>   wc_InitSha512@Base 3.10.2
> @@ -209,10 +209,10 @@
>   wc_SetSubjectBuffer@Base 3.10.2
>   wc_SetSubjectKeyId@Base 3.10.2
>   wc_SetSubjectKeyIdFromPublicKey@Base 3.10.2
> - wc_Sha224Final@Base 3.10.2
> - wc_Sha224GetHash@Base 3.10.2
> - wc_Sha224Hash@Base 3.10.2
> - wc_Sha224Update@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_Sha224Final@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_Sha224GetHash@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_Sha224Hash@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_Sha224Update@Base 3.10.2
>   wc_Sha256Final@Base 3.10.2
>   wc_Sha256GetHash@Base 3.10.2
>   wc_Sha256Hash@Base 3.10.2
> @@ -749,7 +749,7 @@
>   wolfSSL_EVP_rc4@Base 3.10.2
>   wolfSSL_EVP_ripemd160@Base 3.10.2
>   wolfSSL_EVP_sha1@Base 3.10.2
> - wolfSSL_EVP_sha224@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wolfSSL_EVP_sha224@Base 3.10.2
>   wolfSSL_EVP_sha256@Base 3.10.2
>   wolfSSL_EVP_sha384@Base 3.10.2
>   wolfSSL_EVP_sha512@Base 3.10.2
> @@ -885,9 +885,9 @@
>   wolfSSL_SHA1_Final@Base 3.10.2
>   wolfSSL_SHA1_Init@Base 3.10.2
>   wolfSSL_SHA1_Update@Base 3.10.2
> - wolfSSL_SHA224_Final@Base 3.10.2
> - wolfSSL_SHA224_Init@Base 3.10.2
> - wolfSSL_SHA224_Update@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wolfSSL_SHA224_Final@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wolfSSL_SHA224_Init@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wolfSSL_SHA224_Update@Base 3.10.2
>   wolfSSL_SHA256_Final@Base 3.10.2
>   wolfSSL_SHA256_Init@Base 3.10.2
>   wolfSSL_SHA256_Update@Base 3.10.2
>
> --- debian/libwolfssl10.symbols (libwolfssl10_3.10.2+dfsg-1_arm64)
> +++ dpkg-gensymbolsUx3QLk   2017-04-08 02:39:25.711217905 +
> @@ -135,7 +135,7 @@
>   wc_InitRng_ex@Base 3.10.2
>   wc_InitRsaKey@Base 3.10.2
>   wc_InitRsaKey_ex@Base 3.10.2
> - wc_InitSha224@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_InitSha224@Base 3.10.2
>   wc_InitSha256@Base 3.10.2
>   wc_InitSha384@Base 3.10.2
>   wc_InitSha512@Base 3.10.2
> @@ -209,10 +209,10 @@
>   wc_SetSubjectBuffer@Base 3.10.2
>   wc_SetSubjectKeyId@Base 3.10.2
>   wc_SetSubjectKeyIdFromPublicKey@Base 3.10.2
> - wc_Sha224Final@Base 3.10.2
> - wc_Sha224GetHash@Base 3.10.2
> - wc_Sha224Hash@Base 3.10.2
> - wc_Sha224Update@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_Sha224Final@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_Sha224GetHash@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_Sha224Hash@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_Sha224Update@Base 3.10.2
>   wc_Sha256Final@Base 3.10.2
>   wc_Sha256GetHash@Base 3.10.2
>   wc_Sha256Hash@Base 3.10.2
> @@ -749,7 +749,7 @@
>   wolfSSL_EVP_rc4@Base 3.10.2
>   wolfSSL_EVP_ripemd160@Base 3.10.2
>   wolfSSL_EVP_sha1@Base 3.10.2
> - wolfSSL_EVP_sha224@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wolfSSL_EVP_sha224@Base 3.10.2
>   wolfSSL_EVP_sha256@Base 3.10.2
>   wolfSSL_EVP_sha384@Base 3.10.2
>   wolfSSL_EVP_sha512@Base 3.10.2
> @@ -885,9 +885,9 @@
>   wolfSSL_SHA1_Final@Base 3.10.2
>   wolfSSL_SHA1_Init@Base 3.10.2
>   wolfSSL_SHA1_Update@Base 3.10.2
> - wolfSSL_SHA224_Final@Base 3.10.2
> - wolfSSL_SHA224_Init@Base 3.10.2
> - wolfSSL_SHA224_Update@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wolfSSL_SHA224_Final@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wolfSSL_SHA224_Init@Base

Bug#859897: choose-mirror: Add entry to disable mirror use

[Samuel Thibault]

Package: choose-mirror
Version: 2.78
Severity: normal

Hello,

Currently, the user is faced with having to choose a network mirror,
and AFAIK, the only way to skip using a network mirror is to choose
"go back" at the mirror country selection menu. That is really not
intuitive, couldn't there be a "no mirror" entry among that list?

Samuel

-- System Information:
Debian Release: 9.0
  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.10.0 (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
>Ever heard of .cshrc?
That's a city in Bosnia.  Right?
(Discussion in comp.os.linux.misc on the intuitiveness of commands.)

Bug#662779: O: sclapp -- framework for Python command-line applications

[emzyof...@yahoo.com]

[]

Bug#859898: needrestart-session: System Services button not useful when needrestart-session was not run from the terminal

[Paul Wise]

Package: needrestart-session
Version: 0.3-4.1
Severity: normal

When needrestart-session was run by dbus or from the GNOME run dialog,
its stdout does not go anywhere visible to users (just to the systemd
user journal), which means that most of the time the button is not
useful to people who will see it and it will just make them confused.

-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates'), (800, 'unstable-debug'), (800, 'unstable'), (790, 
'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 
'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages needrestart-session depends on:
ii  adduser3.115
ii  libnet-dbus-perl   1.1.0-4+b1
ii  libproc-processtable-perl  0.53-2
ii  libwx-perl 1:0.9928-1+b1
ii  needrestart2.11-2
pn  perl:any   
ii  policykit-10.105-17
ii  wmctrl 1.07-7+b1

needrestart-session recommends no packages.

needrestart-session suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#859899: needrestart-session: Refresh button freezes the UI

[Paul Wise]

Package: needrestart-session
Version: 0.3-4.1
Severity: normal

Pressing the Refresh button freezes the UI, which can be annoying when
I've killed a few processes using pkill in the GNOME run dialog and
want to bring the window of a process to the foreground.
Please make the Refresh action asynchronous.

-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates'), (800, 'unstable-debug'), (800, 'unstable'), (790, 
'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 
'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages needrestart-session depends on:
ii  adduser3.115
ii  libnet-dbus-perl   1.1.0-4+b1
ii  libproc-processtable-perl  0.53-2
ii  libwx-perl 1:0.9928-1+b1
ii  needrestart2.11-2
pn  perl:any   
ii  policykit-10.105-17
ii  wmctrl 1.07-7+b1

needrestart-session recommends no packages.

needrestart-session suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#859900: apt: fails to install parl-desktop-world with --install-recommends

[Andreas Beckmann]

Package: apt
Version: 1.4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + parl-desktop-world parl-desktop-eu

Hi,

during a test with piuparts I noticed that parl-desktop-world could not
be tested with --install-recommends enabled.

This can be easily reproduced in a minimal chroot (where installing
Recommends is disabled by default) with

# apt-get install --install-recommends parl-desktop-world
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 parl-desktop-world : Depends: myspell-cs but it is not going to be installed
E: Unable to correct problems, you have held broken packages.


The relevant bits of the dependency chain seem to be:

Package: parl-desktop-world
Depends: icedove-l10n-cs, myspell-cs

Package: icedove-l10n-cs
Depends: thunderbird-l10n-cs

Package: thunderbird-l10n-cs
Recommends: hunspell-cs | myspell-cs-cz

Package: hunspell-cs
Conflicts: myspell-cs

Package: myspell-cs
Replaces: myspell-cs-cz
Provides: myspell-cs-cz
Conflicts: myspell-cs-cz


This command would succeed: 
# apt-get install parl-desktop-world

and this sequence would work as well:
# apt-get install myspell-cs
# apt-get install --install-recommends parl-desktop-world


I must admit that the dependencies in parl-desktop-world should be
updated, but nevertheless apt should be able to install it in its
current state.


piuparts logs if you are interested:
https://piuparts.debian.org/stretch-rcmd/fail/parl-desktop-eu_1.9.9.log
https://piuparts.debian.org/stretch-rcmd/fail/parl-desktop-world_1.9.9.log


Andreas

Bug#859901: needrestart-session: automatically refresh list when needrestart sends dbus notifications

[Paul Wise]

Package: needrestart-session
Version: 0.3-4.1
Severity: wishlist

I have a system with unattended-upgrades installed and enabled, with
minimal-steps enabled too. This means that unattended-upgrades runs apt
multiple times with small sets of packages and needrestart-session is
run by dbus on the first upgrade. The second and later upgrades run
needrestart but do not trigger the existing needrestart-session process
to update the list of processes. This means that when I return to my
session, the display of things needing a restart is inaccurate.
To fix this, I guess the needrestart-session need to listen on dbus and
trigger refreshes whenever it receives a notification from needrestart.

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
Unattended-Upgrade::MinimalSteps "true";

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#859885: No longer necessary, should not be released with stretch

[Michael Biebl]

control: clone -1 -2
reassign: -2 ftp.debian.org
retitle: -2 RM: gnome-shell-extension-refreshwifi -- ROM; obsolete

Am 08.04.2017 um 18:25 schrieb Jonathan Carter:
> +1, package should be removed
> 
> Last when I checked that extension, stretch hat a slightly older version
> of Gnome that didn't autorefresh. Will update my blog entry to reflect that.

Since you agree, let's turn this into a proper RM request.

Dear ftp-masters, please remove gnome-shell-extension-refreshwifi from
the archive. It was added to workaround a bug in gnome-shell which has
been fixed in the mean time. Nowadays the package is superfluous and
only confuses people.

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#859903: kuvert aborts with syslog enabled and UTF-8 chars in messages

[gregor herrmann]

Package: kuvert
Version: 2.1.0
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


kuvert failed to start for me today (i.e. at the first start after
upgrading to 2.1.0) with

Wide character in syswrite at /usr/lib/x86_64-linux-gnu/perl/5.24/Sys/Syslog.pm 
line 544.

Some digging around shows that this happens while reading the keys
and weeding out revoked keys, when "syslog" is turned on in the
config, and the message passed to the logit() function contains (in
this case [0]) cyrillic characters.

The same happens when writing to a logfile (after enabling the option
in the config):

Wide character in print at /usr/bin/kuvert line 1357.


So it looks like the messages need to be encoded again before being
passed to Sys::Sylog or written to a local file.


The attached patch seems to fix to problem for me and might serve as
an inspiration.


Cheers,
gregor


[0]

% gpg --list-key --list-options show-unusable-uids 0xEA12A906DE0E1C1B
gpg: please do a --check-trustdb
pub   dsa1024/0xEA12A906DE0E1C1B 2008-09-22 [SCA]
  Key fingerprint = 655A 86EB 653C 6D6C BB16  2550 EA12 A906 DE0E 1C1B
uid   [ unknown] Roman V. Nikolaev 
uid   [ revoked] Николаев Роман 
uid   [ revoked] Николаев Роман 
uid   [ revoked] Николаев Роман (РБС) 
uid   [ unknown] [jpeg image of size 4915]
uid   [ unknown] Roman V. Nikolaev 
uid   [ revoked] Николаев Роман (РБС) 

uid   [ unknown] Roman V. Nikolaev 
uid   [ unknown] Roman V. Nikolaev 
(http://search.cpan.org/~rshadow/) 
sub   elg2048/0xDBC0C083950A7796 2008-09-22 [E]



-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAljpfNNfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgb95RAAilg5KJGvAgyqoCO1kbC4mwqfmebt9CarumqVn56WjG/fniqCeHrQMSz9
5KWgybAh5qWHRYAn4R22/CLSS80FTxg1vSUzL6kaqk9f9b9gklwHNacEKYRQV+h+
Bm0Abgwau5p8syA5EBEBui8HA+5GDjGT1I4WW7L0eeqMj0k1GXkz/1+HOAHtphsb
dOxqoRMuJYh/HxE35I/MvW6zhwWCRCTp+HvVxbqNDi4oj8Entykf0k/zVXhdk2xA
NnYMVZxRFcnGAs8f8Ud9X1Hptyh3euURg80h5YPFSaMCPf57lv11oNv5Nz+lJLvT
shSVE+cz9K5OyGXBzz4fnYNeU51mlCt/eU4xd3dwL0JKKnier98k/ydCz8CyJtnQ
e/wAJX23eKT82xTLwVY6bTOrC/lKZbXBatB6vg7miDqTDkwTjmZjox/NZAB1MQqr
DQjMAsI3e3RgbDs2MYaWEhJjNZ9oeaq4ftV9VWyvdLnDpNYVej2KX9II9GdINeSe
sA46VkdJ2sEkesV4wfo1G4ffVwtw2ufO2p3ho9wSXSNUBsXgARH9VzbLmKmtzXU3
4jKlRBZxCzKwAMmEbt28ez/4Roacj+BINjCtH8OYjBROkneC9XsVhcfEiXuFfUs8
EvvpCADYchimFgxgToNE0QyJJrOaezCN43eLnVHWNY1GdFa+DbM=
=MVBI
-END PGP SIGNATURE-
--- a/usr/bin/kuvert2017-04-01 15:36:39.0 +0200
+++ b/usr/bin/kuvert2017-04-09 02:11:25.412361947 +0200
@@ -1344,6 +1344,7 @@
 {
my (@msgs)=@_;
 
+   my @umsgs = map {Encode::encode('utf-8', $_, Encode::FB_WARN)} @msgs;
if ($config{logfile})   # our own logfile?
{
if (!$config{logfh})# not open yet?
@@ -1354,14 +1355,14 @@
$config{logfh}->autoflush(1);
}
 
-   print { $config{logfh} } scalar(localtime)." 
".join("\n\t",@msgs)."\n";
+   print { $config{logfh} } scalar(localtime)." 
".join("\n\t",@umsgs)."\n";
}
 
if ($config{syslog})
{
setlogsock('unix');
openlog($progname,"pid,cons",$config{syslog});
-   syslog("notice",join("\n",@msgs));
+   syslog("notice",join("\n",@umsgs));
closelog;
}
 }

Bug#859073: RFS: groonga/7.0.1-1

[Adam Borowski]

On Thu, Mar 30, 2017 at 03:33:27PM +0900, Kentaro Hayashi wrote:
> I am looking for a sponsor for my package "groonga"
> 
> * Package name: groonga
>   Version : 7.0.1-1

> Changes since last upload:
> 
>   * New upstream release.
>   * debian/patches/fix-nginx-FTBFS-on-kfreebsd.patch
> - Refresh patch to fix FTBFS on kFreeBSD.

This is a complex package that's going to be a part of Stretch; it's really
not the time for a new major upstream version.

Thus, wouldn't you want to upload to experimental, and/or make a targetted
fix for the kfreebsd FTBFS?  We'll have time for unstable once Stretch is
released.  You can work in experimental for now.


-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!

Bug#859904: flashplugin-nonfree fails update

[parker]

Package: flashplugin-nonfree
Version: 1:3.6.1+deb8u1
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

update-flashplugin-nonfree --install
fails..



-- Package-specific info:
Debian version: 8.7
Architecture: amd64
Package version: 1:3.6.1+deb8u1
MD5 checksums:
29c85bc8504422120cf89702986ff8e1  
/var/cache/flashplugin-nonfree/get-upstream-version.pl
md5sum: /usr/lib/flashplugin-nonfree/libflashplayer.so: No such file or 
directory
Alternatives:
update-alternatives: error: no alternatives for flash-mozilla.so
ls: cannot access /usr/lib/mozilla/plugins/flash-mozilla.so: No such 
file or directory
/usr/lib/mozilla/plugins/flash-mozilla.so: cannot open 
`/usr/lib/mozilla/plugins/flash-mozilla.so' (No such file or directory)

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

Kernel: Linux 4.9.0-0.bpo.2-amd64 (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 flashplugin-nonfree depends on:
ii  binutils   2.25-5
ii  ca-certificates20141019+deb8u2
ii  debconf [debconf-2.0]  1.5.56
ii  gnupg  1.4.18-7+deb8u3
ii  libatk1.0-02.14.0-1
ii  libcairo2  1.14.0-2.1+deb8u2
ii  libcurl3-gnutls7.38.0-4+deb8u5
ii  libfontconfig1 2.11.0-6.3+deb8u1
ii  libfreetype6   2.5.2-3+deb8u1
ii  libgcc11:4.9.2-10
ii  libglib2.0-0   2.48.0-1~bpo8+1
ii  libgtk2.0-02.24.25-3+deb8u1
ii  libnspr4   2:4.12-1+debu8u1
ii  libnss32:3.26-1+debu8u1
ii  libpango1.0-0  1.36.8-3
ii  libstdc++6 4.9.2-10
ii  libx11-6   2:1.6.2-3
ii  libxext6   2:1.3.3-1
ii  libxt6 1:1.1.4-1+b1
ii  wget   1.16-1+deb8u1

flashplugin-nonfree recommends no packages.

Versions of packages flashplugin-nonfree suggests:
ii  fonts-dejavu   2.34-1
pn  hal
ii  iceweasel  45.8.0esr-1~deb8u1
pn  konqueror-nsplugins
pn  ttf-mscorefonts-installer  
pn  ttf-xfree86-nonfree

-- no debconf information

Bug#857406: libpcp3-dev: ships broken manpage symlinks that should rather be in libpcp-pmda3-dev

[Andreas Beckmann]

On 2017-04-09 01:53, Ken McDonell wrote:
> Andreas,
> 
> I've battled for half a day to get the Breaks/Replaces clauses right and
> failed spectacularly.
> 
> Could you point me at any documentation (neither google nor I can find it!)
> that shows exactly what to do in this case of a file moving from existing
> package A to existing package B where there are dependencies between A and
> B?

That would probably be the Debian Policy
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

Assuming the version you are preparing is 3.11.10
(why is that a native package anyway?) and you are moving
stuff from libpcp3-dev to libpcp-pmda3-dev, then you'll need
to add 
 
  Package:  libpcp-pmda3-dev
  Breaks:   libpcp3-dev (<< 3.11.10~)
  Replaces: libpcp3-dev (<< 3.11.10~)

I used the '~' suffix to get a version that also works out-of-the-box
(without any extra care or changes needed) in case the package gets
backported (which would become backport version 3.11.10~bpoX+1)


If you want me to review of your changes, send me a source debdiff
or the link to the respective commits (and keep the bug Cc:ed)

Andreas

PS: I did not look at all at your package to write this email :-)

> Thanks for any help you may be able to offer.
> 
>> -Original Message-
>> From: p...@groups.io [mailto:p...@groups.io] On Behalf Of Andreas Beckmann
>> Sent: Saturday, March 11, 2017 7:22 AM
>> To: p...@groups.io
>> Subject: [pcp] Bug#857406: libpcp3-dev: ships broken manpage symlinks that
>> should rather be in libpcp-pmda3-dev
>>
>> Package: libpcp3-dev
>> Version: 3.11.8
>> Severity: normal
>> User: debian...@lists.debian.org
>> Usertags: piuparts
>>
>> Hi,
>>
>> during a test with piuparts I noticed your package ships (or creates) a
> broken
>> symlink.
>>
>> >From the attached log (scroll to the bottom...):
>>
>> 0m32.3s ERROR: FAIL: Broken symlinks:
>>   /usr/share/man/man3/pmwebapi.3.gz -> PMWEBAPI.3.gz
>>   /usr/share/man/man3/pmdatext.3.gz -> pmdaText.3.gz
>>   /usr/share/man/man3/pmdastore.3.gz -> pmdaStore.3.gz
>>   /usr/share/man/man3/pmdarootconnect.3.gz -> pmdaRootConnect.3.gz
>>   /usr/share/man/man3/pmdaprofile.3.gz -> pmdaProfile.3.gz
>>   /usr/share/man/man3/pmdapmid.3.gz -> pmdaPMID.3.gz
>>   /usr/share/man/man3/pmdaopenlog.3.gz -> pmdaOpenLog.3.gz
>>   /usr/share/man/man3/pmdaname.3.gz -> pmdaName.3.gz
>>   /usr/share/man/man3/pmdainterfacemoved.3.gz -> pmdaInterfaceMoved.3.gz
>>   /usr/share/man/man3/pmdainstance.3.gz -> pmdaInstance.3.gz
>>   /usr/share/man/man3/pmdainit.3.gz -> pmdaInit.3.gz
>>   /usr/share/man/man3/pmdafetch.3.gz -> pmdaFetch.3.gz
>>   /usr/share/man/man3/pmdadso.3.gz -> pmdaDSO.3.gz
>>   /usr/share/man/man3/pmdadesc.3.gz -> pmdaDesc.3.gz
>>   /usr/share/man/man3/pmdadaemon.3.gz -> pmdaDaemon.3.gz
>>   /usr/share/man/man3/pmdaconnect.3.gz -> pmdaConnect.3.gz
>>   /usr/share/man/man3/pmdachildren.3.gz -> pmdaChildren.3.gz
>>   /usr/share/man/man3/pmdaattribute.3.gz -> pmdaAttribute.3.gz
>>   /usr/share/man/man3/pmda.3.gz -> PMDA.3.gz
>>
>> Since all these manpages used as symlink targets are in the package
> libpcp-
>> pmda3-dev, the links should rather be there, too.
>>
>> Don't forget to add appropriate Breaks+Replaces to libpcp-pmda3-dev if you
> are
>> moving the links there.
>>
>>
>> cheers,
>>
>> Andreas

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

ok i've raised this directly upstream with the mesa-dev team on
freedesktop.org and also done a little investigation, and found that
the processes are hanging waiting in a poll in libxcb.  the mesa-dev
team asked everyone who is affected *AND NOT* affected to report which
version of DRI is being used in their xorg.conf file (2 or 3) and also
which version of mesa is installed.

if that information could be sent here to 848895 then i can refer the
mesa-dev team to this bugreport.

i'm using DRI2 and mesa 13.0.6

btw if someone familiar with the debian bugtracker system could also
add the magic "control affects openscad" to this bugreport that would
be great.

l.

Bug#856396: dpkg-dev: dpkg-source displays warnings when gcc is not installed

[Guillem Jover]

Hi!

On Tue, 2017-02-28 at 15:23:49 +, CONSUEGRA Lenny - externe wrote:
> Package: dpkg-dev
> Version: 1.17.27
> Severity: minor
> Tags: upstream

> When building a package with dpkg-source, warnings are printed if gcc is
> not installed on the system :
> 
> root@build:/srv/build/tmp/test# dpkg-source -b ublock-origin-1.9.4+dfsg
>  sh: 1: gcc: not found
>  dpkg-source: warning: Couldn't determine gcc system type, falling back to 
> default (native compilation)

I've analyzed the code, and it does indeed not really require the host
architecture when building a source package, so I've got a couple of
commits that get rid of those messages.

The first disables the perl warnings for when the program is not found
(the equivalent of first line for 1.18.x, but w/o going via the shell),
and the second removes the need completely of calling gcc (so the
second line will not even be emitted).

I've queued these for 1.19.x.

> A bug report has already been filled for dpkg-dev 1.14.26 :
> 
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526132

Although this was for extraction which is a quite different code path,
so not a regression or anything.

Thanks,
Guillem

Bug#858579: /usr/share/man/man5/deb-changelog.5.gz: please support a comment syntax for Debian changelog files

[Guillem Jover]

Hi!

On Sat, 2017-03-25 at 19:27:55 -0400, G. Branden Robinson wrote:
> On Sat, Mar 25, 2017 at 03:07:32PM +0100, Guillem Jover wrote:
> > The implementation in dpkg-dev already supports all of this
> > (see man Dpkg::Changelog::Debian), including:
> 
> Section 3 manpages for Perl modules?  Will wonders never cease?  ;-)

I'm not sure if the wonder is becuse there's documentation at all for
those, or because secion is 3 instead of say 3perl. In any case, this
prompted me to check and fix the latter, so I've queued a patch for
1.19.x. :)

> Thanks--I was utterly unaware of this.

No problem!

> > So I guess your request would be to officialize (at least the proper
> > comment markers ‘#’) as supported, in the spec. I'll probably mention
> > this on the debian-policy mailing list, but I guess I should just do
> > it (perhaps all the currently accepted syntax) because if someone wants
> > to code an alternative implementation, they will have to replicate the
> > logic, or it will be unable to parse existing changelogs.
> > 
> > Also because dpkg can always be more lax than policy, and this is the
> > case right here.
> 
> Yes, that's precisely what I'm shooting for.
> 
> I urge you to go ahead and do it; it's obviously not a breaking change.

Ok, what about the attached patch, which I've queued for 1.19.x? I'm
not documenting the ancient formats, because I feel that might induce
people to use them, while this should be IMO pretty much just an
implementation detail.

Thanks,
Guillem
From a77397811e30e74500b79ea4eee4aa8d93a6e5ac Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 9 Apr 2017 03:51:03 +0200
Subject: [PATCH] man: Document currently accepted syntax for changelogs

The current implementation supports several comment lines, VCS and
editor variable settings which get ignored. In addition, to be able
to handle ancient changelog entries, the parser will detect those and
ignore while preserving them for output.

Closes: #858579
---
 man/deb-changelog.man| 10 +-
 scripts/Dpkg/Changelog/Debian.pm |  4 ++--
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/man/deb-changelog.man b/man/deb-changelog.man
index 2a424a4bb..4a058b1bd 100644
--- a/man/deb-changelog.man
+++ b/man/deb-changelog.man
@@ -7,7 +7,7 @@
 .\" Copyright © 2008, 2010 Russ Allbery 
 .\" Copyright © 2010 Charles Plessy 
 .\" Copyright © 2014 Bill Allombert 
-.\" Copyright © 2015 Guillem Jover 
+.\" Copyright © 2015-2017 Guillem Jover 
 .\"
 .\" This is free software; you can redistribute it and/or modify
 .\" it under the terms of the GNU General Public License as published by
@@ -141,6 +141,14 @@ preceded by exactly one space.
 The maintainer details and the date must be separated by exactly two
 spaces.
 .PP
+Any line that consists entirely (i.e. no leading whitespace) of \fB#\fP
+or \fB/* */\fP style comments, CVS keywords, vim variables or emacs local
+variables should be ignored.
+.PP
+Ancient changelog entries with other formats at the end of the file should
+be accepted and preserved on output, but their contents might be otherwise
+ignored and parsing stopped at that point.
+.PP
 The entire changelog must be encoded in UTF-8.
 .SH FILES
 .TP
diff --git a/scripts/Dpkg/Changelog/Debian.pm b/scripts/Dpkg/Changelog/Debian.pm
index 4ed04a943..a63e6eb19 100644
--- a/scripts/Dpkg/Changelog/Debian.pm
+++ b/scripts/Dpkg/Changelog/Debian.pm
@@ -1,7 +1,7 @@
 # Copyright © 1996 Ian Jackson
 # Copyright © 2005 Frank Lichtenheld 
 # Copyright © 2009 Raphaël Hertzog 
-# Copyright © 2012-2015 Guillem Jover 
+# Copyright © 2012-2017 Guillem Jover 
 #
 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -28,7 +28,7 @@ Dpkg::Changelog::Debian parses Debian changelogs as described in
 deb-changelog(5).
 
 The parser tries to ignore most cruft like # or /* */ style comments,
-CVS comments, vim variables, emacs local variables and stuff from
+CVS keywords, vim variables, emacs local variables and stuff from
 older changelogs with other formats at the end of the file.
 NOTE: most of these are ignored silently currently, there is no
 parser error issued for them. This should become configurable in the
-- 
2.12.2.715.g7642488e1d

Bug#856547: dpkg: please fix genchanges to replace Short-Desc/Long-Desc

[Guillem Jover]

Hi!

On Thu, 2017-03-02 at 09:57:43 +, Gianfranco Costamagna wrote:
> Source: dpkg
> Version: 1.8.22
> Severity: wishlist

> after that implementation, uploading a changes file results in a
> missing description on the PTS website.
> e.g. bglibs on experimental

> https://packages.qa.debian.org/b/bglibs/news/20170227T154835Z.html
> 
> do you think it can be fixed?

Sure, and the contents for this specific field are probably the only
ones that makes sense applying variable subsitutions for anyway.

I've fixed this now, and queued a patch for 1.19.x.

Do you know if there are many such problematic packages in the archive?
If so, given that it's a one-liner fix, I might be tempted to try to
get it merged in 1.18.x…

Thanks,
Guillem

Bug#740893: libjs-jquery-hotkeys: Incompatible ABI change

[Ben Finney]

On 06-Apr-2017, Philipp Hahn wrote:

> today I spent some time on investigating this issue

Thank you!

> 
> introduced an incompatible ABI change how events are registered:

So the https://github.com/jeresig/jquery.hotkeys> and the
https://github.com/tzuryby/jquery.hotkeys> repositories have
diverged, incompatibly. I didn't know that :-/

> So "coverage_html.js" uses the 'jeresig' API to pass the hotkey via
> "data", while the 'tzuryby' API "jquery.hotkeys.js" expects is via
> 'namespace'.

That's good investigation, thank you for that.

> libjs-jquery-hotkeys currently is used by 3 packages in Debian:
> - libghc-gitit-data
> - prometheus
> - python-pytest-cov

I count 6 binary packages:

=
$ apt-cache rdepends libjs-jquery-hotkeys
libjs-jquery-hotkeys
Reverse Depends:
  libghc-gitit-data
  python3-pytest-cov
  python-pytest-cov
  python3-coverage
  python-coverage
  prometheus
=

The source packages are:

* gitit
* python-coverage
* python-pytest-cov
* prometheus

Why are we getting different sets of packages that use
‘libjs-jquery-hotkeys’?

> Doing some source code `grep -n -r "[.]bind([\"']key"`:

When I use the pattern ‘[.]bind\(["']key’ for each of those source
packages with https://codesearch.debian.net/>, I get a different
set.

These queries show matches:

https://codesearch.debian.net/search?q=[.]bind\%28[%22%27]key+package%3Agitit>
https://codesearch.debian.net/search?q=[.]bind\%28[%22%27]key+package%3Apython-coverage>
https://codesearch.debian.net/search?q=[.]bind\%28[%22%27]key+package%3Aprometheus>

This does not:

https://codesearch.debian.net/search?q=[.]bind\%28[%22%27]key+package%3Apython-pytest-cov>

Does that mean ‘python-pytest-cov’ is not using the ‘jeresig’ API?

Is there a better regex pattern to use to determine what API is used?

> So all of them use the "jeresig" API, but 'libjs-jquery-hotkeys'
> packages the "tzuryby" API.

We get differing results, so I'd like to better understand before
choosing how to resolve this.

-- 
 \  “How many people here have telekenetic powers? Raise my hand.” |
  `\  —Emo Philips |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature