Bug#895877: RM: python-casmoothing -- ROM; Not needed any more, Python 2 only, not working correctly

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi,

when I reported upstream[1] that python-casmoothing has an issue
when loading the module it turned out that it is not needed any
more.  Thus there is no reason to keep it in Debian.

Thanks for your work as ftpmaster

 Andreas.


[1] https://github.com/tfmoraes/python-casmoothing/issues/2

Bug#892458: Fwd: [Debian-astro-maintainers] ftools update

[Salvatore Bonaccorso]

Hi Sam,

On Tue, Apr 17, 2018 at 02:18:26PM +1000, Sam Fowler wrote:
> On 17/04/18 06:40, Salvatore Bonaccorso wrote:
> > Hi Sam,
> > 
> > On Mon, Apr 09, 2018 at 10:19:34AM +1000, Sam Fowler wrote:
> >> On Wed, 14 Mar 2018 16:22:19 +0100 Ole Streicher  
> >> wrote:
> >>> FYI
> >>>
> >>>
> >>>  Forwarded Message 
> >>> Subject: [Debian-astro-maintainers] ftools update
> >>> Date: Wed, 14 Mar 2018 10:42:25 -0400
> >>> From: Michael Arida 
> >>> To: debian-astro-maintain...@lists.alioth.debian.org
> >>>
> >>>
> >>> Dear Debian Astro Maintainers,
> >>>
> >>> As you may have noticed CFITSIO was updated Friday (March 2) for a
> >>> major bug fix.  Since you have a software bundle that uses what we
> >>> assume is CFITSIO somewhere under the hood, we wanted to let you know
> >>> that you should update that code.  We are also expecting another
> >>> update in April.
> >>>
> >>> If you have any questions or concerns, feel free to contact me.
> >>>
> >>> Regards,
> >>>  Mike Arida
> >>> 
> >>> Michael Arida (ADNET) ASD/HEASARC
> >>> 301.286.2291/1215 (voice/fax)  Code 660, NASA/GSFC
> >>> michael.ar...@nasa.gov Greenbelt, MD 20771
> >>>
> >>> ___
> >>> Debian-astro-maintainers mailing list
> >>> debian-astro-maintain...@lists.alioth.debian.org
> >>> https://lists.alioth.debian.org/mailman/listinfo/debian-astro-maintainers
> >>
> >> This has been assigned has been assigned CVE-2018-1000166.
> > 
> > Looking at
> > https://www.talosintelligence.com/vulnerability_reports/TALOS-2018-0531
> > https://www.talosintelligence.com/vulnerability_reports/TALOS-2018-0529
> > it looks for those issues already CVE-2018-3848, CVE-2018-3849 and
> > CVE-2018-3846 were assigned and CVE-2018-1000166 is duplicate. Can you
> > confirm? And if so ask for rejection of CVE-2018-1000166?
> > 
> > Regards,
> > Salvatore
> 
> Hi Salvatore,
> 
> Looks like you are correct. I've request a rejection of CVE-2018-1000166
> from DWF in favour of CVE-2018-3846. I've filed separate RH bugs for
> CVE-2018-3848 and CVE-2018-3849.
> 
> Thanks for the heads up,

Thanks a lot for confirming that quickly. I have removed as well any
CVE-2018-1000166 from our security-tracker now as well.

Regards,
Salvatore

Bug#871502: Bug#895839: src:zotero-standalone-build: New version available

[Andreas Tille]

On Mon, Apr 16, 2018 at 11:24:46PM +0200, Sébastien Villemot wrote:
> Control: forcemerge 871502 -1
> 
> Upgrading Zotero involves a lot of Javascript work, which is far beyond what I
> can possibly do, so please help as much as you can. See the discussion in
> #871502.

I admit I can not help much here.  But what about the Salsa
migration?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#895876: FTBFS: needs update for newer src-exts

[Clint Adams]

Source: haskell-derive
Version: 2.6.3-2
Severity: serious
Forwarded: https://github.com/ndmitchell/derive/issues/33

.

Bug#895875: rkward: build-depends on deprecated Frameworks -dev packages

[Pino Toscano]

Source: rkward
Version: 0.7.0-1
Severity: wishlist
Tags: patch

Dear Maintainer,

your package build-depends on deprecated Frameworks -dev packages,
which currently are transitional packages.

In particular, the replacements needed for this packages are:
- kdoctools-dev -> libkf5doctools-dev

Attached there is a patch for this.

The non-deprecated packages are already available in the current Debian
stable, i.e. Stretch.

Thanks,
-- 
Pino
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Build-Depends: cmake,
debhelper (>= 11.0.0),
libkf5webkit-dev,
libkf5texteditor-dev,
-   kdoctools-dev,
+   libkf5doctools-dev,
r-base-dev (>= 3.0.0)
 Standards-Version: 4.1.4
 Homepage: http://rkward.kde.org

Bug#895848: RFS: inotify-tools/3.14-5

[Sean Whitton]

control: tag -1 +moreinfo
control: owner -1 !

On Mon, Apr 16, 2018 at 10:25:01PM +0300, Dmitry Bogatov wrote:
> 
> I am looking for a sponsor for my package "inotify-tools"

FTBFS:

dpkg-gensymbols: warning: some symbols or patterns disappeared in the 
symbols file: see diff output below
dpkg-gensymbols: warning: debian/libinotifytools0/DEBIAN/symbols doesn't 
match completely debian/libinotifytools0.symbols
--- debian/libinotifytools0.symbols (libinotifytools0_3.14-5_amd64)
+++ dpkg-gensymbolsU60ncr   2018-04-17 04:48:11.369699111 +
@@ -1,7 +1,7 @@
 libinotifytools.so.0 libinotifytools0 #MINVER#
- __odr_asan.rb_null@Base 3.14-4~
- __odr_asan.tree_filename@Base 3.14-4~
- __odr_asan.tree_wd@Base 3.14-4~
+#MISSING: 3.14-5# __odr_asan.rb_null@Base 3.14-4~
+#MISSING: 3.14-5# __odr_asan.tree_filename@Base 3.14-4~
+#MISSING: 3.14-5# __odr_asan.tree_wd@Base 3.14-4~
  _niceassert@Base 3.11
  chrtostr@Base 3.11
  cleanup_tree@Base 3.12
dh_makeshlibs: failing due to earlier errors
make: *** [debian/rules:9: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
exit status 2

Looks like you need to update your symbols file.

Please be sure to `dch -r`.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#895636: meson: more tools missing from debcrossgen

[Helmut Grohne]

On Mon, Apr 16, 2018 at 09:23:37PM +, Jussi Pakkanen wrote:
> Feature freeze for the next version of Meson passed a few days ago,
> thus the proposed change can not be added to it. The next package
> upload will have an updated crossgen that contains objcopy and ld.

I don't need a fix tomorrow. Having a workaround is nice as it unblocks
qa testing for arm64, but I'm more interested in a long term solution.
If you fix this properly in buster, that'd be great.

I suppose that you'll release another version of Meson this year, so can
we work on that instead? I can work around missing objcopy and ld
locally if necessary.

Helmut

Bug#895874: git-email: Should depend on libmailtools-perl for Mail::Address

[Chen-Yu Tsai]

Package: git-email
Version: 1:2.17.0-1
Severity: normal

Dear Maintainer,

According to the Debian changelog entry for 1:2.17.0-1

  * debian/rules: add NO_USE_CPAN_FALLBACKS=1 to OPTS to avoid
installing bundled copies of perl modules.
  * debian/control: Build-Depends: libmailtools-perl, liberror-perl;
git-email: Depends: libmailtools-perl for Mail::Address.

git-email no longer bundles Mail::Address but depends on
libmailtools-perl for it instead. Indeed it is no longer included,
but the control file still lists libmailtools-perl in the Recommends:
entry, not the Depends: entry. This results in the following error
message on systems that don't install recommended packages by default:

BUG: The 'Mail::Address' module is not here, but NO_PERL_CPAN_FALLBACKS
was set!

Git needs this Perl module from the CPAN, and will by default ship
with a copy of it. This Git was built with NO_PERL_CPAN_FALLBACKS,
meaning that whoever built it promised to provide this module.

You're seeing this error because they broke that promise, and we can't
load our fallback version, since we were asked not to install it.

If you're seeing this error and didn't package Git yourself the
package you're using is broken, or your system is broken. This error
won't appear if Git is built without NO_PERL_CPAN_FALLBACKS (instead
we'll use our fallback version of the module). at
/usr/share/perl5/Git/LoadCPAN.pm line 76.
BEGIN failed--compilation aborted at
/usr/share/perl5/Git/LoadCPAN/Mail/Address.pm line 8.
Compilation failed in require at /usr/lib/git-core/git-send-email line
36.
BEGIN failed--compilation aborted at /usr/lib/git-core/git-send-email
line 36.

It seems the change for the second bullet point was missed or not
checked in. git-email in unstable still only recommends
libmailtools-perl [1].

I suggest double checking the control file for the package, and
uploading a revision fixing it.

[1] https://packages.debian.org/sid/git-email

P.S. The system information below shows that I have libmailtools-perl
installed. I installed it manually.

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

Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=zh_TW.Big5, LC_CTYPE=zh_TW.Big5 (charmap=BIG5), 
LANGUAGE=zh_TW.Big5 (charmap=BIG5)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages git-email depends on:
ii  git  1:2.17.0-1

Versions of packages git-email recommends:
pn  libauthen-sasl-perl
pn  libemail-valid-perl
ii  libio-socket-ssl-perl  2.056-1
ii  libmailtools-perl  2.18-1
ii  libnet-smtp-ssl-perl   1.04-1
ii  perl   5.26.1-6

Versions of packages git-email suggests:
pn  git-doc  

-- no debconf information

Bug#892458: Fwd: [Debian-astro-maintainers] ftools update

[Sam Fowler]

On 17/04/18 06:40, Salvatore Bonaccorso wrote:
> Hi Sam,
> 
> On Mon, Apr 09, 2018 at 10:19:34AM +1000, Sam Fowler wrote:
>> On Wed, 14 Mar 2018 16:22:19 +0100 Ole Streicher  wrote:
>>> FYI
>>>
>>>
>>>  Forwarded Message 
>>> Subject: [Debian-astro-maintainers] ftools update
>>> Date: Wed, 14 Mar 2018 10:42:25 -0400
>>> From: Michael Arida 
>>> To: debian-astro-maintain...@lists.alioth.debian.org
>>>
>>>
>>> Dear Debian Astro Maintainers,
>>>
>>> As you may have noticed CFITSIO was updated Friday (March 2) for a
>>> major bug fix.  Since you have a software bundle that uses what we
>>> assume is CFITSIO somewhere under the hood, we wanted to let you know
>>> that you should update that code.  We are also expecting another
>>> update in April.
>>>
>>> If you have any questions or concerns, feel free to contact me.
>>>
>>> Regards,
>>>  Mike Arida
>>> 
>>> Michael Arida (ADNET) ASD/HEASARC
>>> 301.286.2291/1215 (voice/fax)  Code 660, NASA/GSFC
>>> michael.ar...@nasa.gov Greenbelt, MD 20771
>>>
>>> ___
>>> Debian-astro-maintainers mailing list
>>> debian-astro-maintain...@lists.alioth.debian.org
>>> https://lists.alioth.debian.org/mailman/listinfo/debian-astro-maintainers
>>
>> This has been assigned has been assigned CVE-2018-1000166.
> 
> Looking at
> https://www.talosintelligence.com/vulnerability_reports/TALOS-2018-0531
> https://www.talosintelligence.com/vulnerability_reports/TALOS-2018-0529
> it looks for those issues already CVE-2018-3848, CVE-2018-3849 and
> CVE-2018-3846 were assigned and CVE-2018-1000166 is duplicate. Can you
> confirm? And if so ask for rejection of CVE-2018-1000166?
> 
> Regards,
> Salvatore

Hi Salvatore,

Looks like you are correct. I've request a rejection of CVE-2018-1000166
from DWF in favour of CVE-2018-3846. I've filed separate RH bugs for
CVE-2018-3848 and CVE-2018-3849.

Thanks for the heads up,
--
Sam Fowler, Red Hat Product Security

Bug#895873: zfs-linux: Invalid Vcs-Git field in debian/control

[Boyuan Yang]

Source: zfs-linux
Version: 0.7.6-1
Severity: normal
Justification: Policy 5.6.26
Tags: patch

Dear zfs-linux maintainers,

Current Vcs-Git field in d/control file is invalid and will make vcswatch fail:

https://sources.debian.org/src/zfs-linux/0.7.6-1/debian/control.in/

Vcs-Git: g...@salsa.debian.org:zfsonlinux-team/zfs.git

According to Debian Policy 5.6.26, In the case of Git, the value
consists of a URL. Current value is not a valid URL.

Considering that Salsa provides https access, we may change that to:

Vcs-Git: https://salsa.debian.org/zfsonlinux-team/zfs.git

--
Regards,
Boyuan Yang

Bug#895872: Crash if ~/.wget-hsts cannot be opened for writing

[Ben Hutchings]

Package: wget
Version: 1.18-5+deb9u1
Severity: important
Tags: patch upstream fixed-upstream

wget 1.18 has this code in hsts_store_open():

  FILE *fp = fopen (filename, "r");

  if (!fp || !hsts_read_database (store, fp, false))
{
  /* abort! */
  hsts_store_close (store);
  xfree (store);
  fclose (fp);
  goto out;
}

fclose(NULL) has undefined behaviour and in stretch the result is
a SIGSEGV.  So wget needs to check for NULL before calling fclose().

This is fixed in 1.19.

Ben.

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

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

Versions of packages wget depends on:
ii  libc62.27-2
ii  libgnutls30  3.5.18-1
ii  libidn2-02.0.4-1.1
ii  libnettle6   3.4-1
ii  libpcre3 2:8.39-9
ii  libpsl5  0.20.1-1
ii  libuuid1 2.31.1-0.5
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages wget recommends:
ii  ca-certificates  20170717

wget suggests no packages.

-- no debconf information
Author: Ben Hutchings 
Date: Tue, 17 Apr 2018 02:55:33 +0100
Description: wget: Fix fclose(NULL) in hsts_store_open()
 fclose(NULL) has undefined behaviour, so only call fclose() if fp != NULL.
--- a/src/hsts.c
+++ b/src/hsts.c
@@ -510,7 +510,8 @@ hsts_store_open (const char *filename)
   /* abort! */
   hsts_store_close (store);
   xfree (store);
-  fclose (fp);
+  if (fp)
+fclose (fp);
   goto out;
 }
 

Bug#879619: Autopkgtest for ncbi-tools6

[Aaron M. Ucko]

Liubov Chuprikova  writes:

> Sorry for a delay, but I was planning to make one more effort on extending
> the set of tests.

No problem.

> At the moment, the following commands are still lacking tests:
>
>- *asn2ff*, *gbseqget*, *findspl* (their output indicates they are
>obsolete and/or unsupported)

- asn2ff plays the same general role as asn2flat, and should be possible to
  test similarly.
- gbseqget is like insdseqget, but formally uses GenBank-specific
  notation; as such, it requires network access.
- findspl also requires network access, and will need to be patched in the
  same fashion as taxblast; I'll take care of it when I get a chance.

>- *asndhuff*, *nps2gps* (I can't figure out what kind of inputs they
>require)

- I'm not sure where you'd find input for asndhuff.
- nps2gps takes a text Bioseq-set or Seq-entry of class nuc-prot, as
  obtained by (for instance) idfetch -g1234.

>- *fa2htgs*, *spidey* (they look too complicated for me and require much
>time to understand how they work)

That's fair.  You can always come back to them later if you feel inspired.

>- *taxblast* doesn't generate an output file and only generates an
>*incomplete* html

I'm not sure what's up with that, but as previously noted, it requires
network access anyway.

>- *errhdr*, *sortbyquote* (I can't figure out even what they are
>supposed to do)

- errhdr is a developer tool, working with files of the format found in
  errmsg/.
- sortbyquote is also a developer tool, essentially a variant of sort
  that ignores everything outside quotation marks (and generally has far
  fewer options).

> If nothing critical is left without a test, then I'd like to ask you to
> sponsor the upload. If you need any additional information about *taxblast*,
> I'll be happy to provide it.

OK, thanks.  I'm not sure any of these is critical to test, but some
should be relatively straightforward to work in at this point, and as
noted I'm not quite ready to upload a new version anyway.

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

Bug#871835: Call for help: review patches for debootstrap

[Hideki Yamane]

Hi,

On Wed, 11 Apr 2018 13:06:22 +0200
Clément Hermann  wrote:
> I had a look today. It looks good to me, at first glance I had concerns
> (like using hash keys in boolean context without the exists function),
> but everytime I checked further, it looked fine in context. That for the
> perl part.
> 
> Other than that, if I may give my opinion, the commit messages make the
> patches pretty self explanatory, and the portability concerns are
> adressed (you still need grep -E but busybox can provide it, if your
> grep doesn't implement it). The changes make perfect sense and the
> performance boost is impresssive.
> 
> Barring any concern from someone more knowledgeable, I would definitely
> apply this :)

 Thanks for your check! :)
 And yes, performance improvement is so attractive for us.

 First review seems to be good status. And of course, more people
 are also welcome.

 
-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#895871: [gitlab] Markdown is not rendering, "Error loading viewer"

[Dmitry Smirnov]

Package: gitlab
Version: 10.6.3+dfsg-1
Severity: normal

Similar to #890757, Markdown rendering is broken, showing "Error loading
viewer" on project's Overview and Repository pages.


Completed 500 Internal Server Error in 82ms (ActiveRecord: 3.3ms)

ActionView::Template::Error (undefined method `html_escape' for
#
Did you mean?  html_safe?):
1: - blob = viewer.blob
2: - rendered_markup = blob.rendered_markup if
blob.respond_to?(:rendered_markup)
3: .file-content.wiki
4:   = markup(blob.name, blob.data, rendered: rendered_markup)
  lib/banzai/renderer/redcarpet/html.rb:9:in `block_code'
  lib/banzai/filter/markdown_engines/redcarpet.rb:27:in `render'
  lib/banzai/filter/markdown_engines/redcarpet.rb:27:in `render'
  lib/banzai/filter/markdown_filter.rb:12:in `call'
  lib/banzai/pipeline/base_pipeline.rb:21:in `block (2 levels) in
singleton class'
  lib/banzai/renderer.rb:108:in `render_result'
  lib/banzai/renderer.rb:139:in `block in cacheless_render'
  lib/gitlab/metrics/influx_db.rb:98:in `measure'
  lib/banzai/renderer.rb:138:in `cacheless_render'
  lib/banzai/renderer.rb:28:in `render'
  lib/banzai.rb:3:in `render'
  app/helpers/markup_helper.rb:244:in `markdown_unsafe'
  app/helpers/markup_helper.rb:143:in `markup_unsafe'
  app/helpers/markup_helper.rb:110:in `markup'
  app/views/projects/blob/viewers/_markup.html.haml:4:in
`_app_views_projects_blob_viewers__markup_html_haml__1729761416022180057_47095031404280'
  app/views/projects/blob/_viewer.html.haml:20:in
`_app_views_projects_blob__viewer_html_haml___2248780134913313564_47095031583720'
  app/controllers/application_controller.rb:252:in `view_to_html_string'
  app/controllers/concerns/renders_blob.rb:18:in `blob_json'
  app/controllers/projects/blob_controller.rb:200:in `show_json'
  app/controllers/projects/blob_controller.rb:47:in `block (2 levels) in
show'
  app/controllers/projects/blob_controller.rb:39:in `show'
  lib/gitlab/i18n.rb:50:in `with_locale'
  lib/gitlab/i18n.rb:56:in `with_user_locale'
  app/controllers/application_controller.rb:330:in `set_locale'
  lib/gitlab/middleware/multipart.rb:95:in `call'
  lib/gitlab/request_profiler/middleware.rb:14:in `call'
  lib/gitlab/middleware/go.rb:17:in `call'
  lib/gitlab/etag_caching/middleware.rb:11:in `call'
  lib/gitlab/middleware/read_only/controller.rb:28:in `call'
  lib/gitlab/middleware/read_only.rb:16:in `call'
  lib/gitlab/request_context.rb:18:in `call'
  lib/gitlab/metrics/requests_rack_middleware.rb:27:in `call'
  lib/gitlab/middleware/release_env.rb:10:in `call'


Regards,
 Dmitry.

Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Michael Shuler]

Thanks for the details. #895473 reported a similar error on locally
installed CA certificates, which I think may be related.

Each of the list of `rehash: skipping .. cannot open file` in your
errors appears to be on CAs that were removed in the package during this
update, so somewhere we have a problem with `openssl rehash` trying to
link to files we removed, but for some reason were not prefixed with '!'
in /etc/ca-certificates.conf.

I've tried a number of upgrades from a March 29 unstable chroot, as well
as from stretch to unstable on openstack instances, on both amd64 and
i386 (I don't think arch is dependent), and I've been unable to get a
similar error to present itself.

Each way I've tried, I get the package-removed certificates prefixed
properly and no errors, so haven't been able to reproduce this, yet. I
will keep trying with different options and see if I can figure out
where the problem is. If someone has a good way to reproduce, I'd
appreciate it!

-- 
Kind regards,
Michael

Bug#895870: RFS: deepin-music/3.1.8.1+ds-1

[Yanhao Mo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "deepin-music"

 * Package name: deepin-music
   Version : 3.1.8.1+ds-1
   Upstream Author : Deepin Technology Co., Ltd.
 * URL : https://github.com/linuxdeepin/deepin-music
 * License : GPL-3+
   Section : sound

It builds those binary packages:

  deepin-music - music player with brilliant and tweakful UI

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

  https://mentors.debian.net/package/deepin-music

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/deepin-music/deepin-music_3.1.8.1+ds-1.dsc

More information about hello can be obtained from 
https://salsa.debian.org/pkg-deepin-team/deepin-music

-- 
Yanhao Mo


signature.asc
Description: PGP signature

Bug#895869: NMU upload in progress for transmission 2.93

[Antoine Beaupre]

Source: transmission
Severity: normal
Tags: patch

Hi!

I have taken the liberty to upload the 2.93 release to unstable today,
through the DELAYED/10 queue. Let me know if I should delay it any
longer.

I've also pushed the result to collab-maint.

Thanks!

A.

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

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

Bug#895473: ca-certificates: Post-install script subprocess return error exit status 3 while upgrading

[Michael Shuler]

On 04/11/2018 04:01 PM, Pr0metheus wrote:
> 
>* What led up to the situation?
> 
> apt-get upgrade
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Cannot fix the problem
> 
>* What was the outcome of this action?
> 
> Setting up ca-certificates (20180409) ...
> Updating certificates in /etc/ssl/certs...
> rehash: skipping duplicate certificate in HaricaRootCA2011.pem
> rehash: skipping vpn.auth.gr.pem, cannot open file
> rehash: skipping AutCentralCAR5.pem, cannot open file
> dpkg: error processing package ca-certificates (--configure):
>  installed ca-certificates package post-installation script subprocess 
> returned
> error exit status 3
> Errors were encountered while processing:
>  ca-certificates
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
>* What outcome did you expect instead?
> 
> Like previous upgrades, maintain my existing list and update the rest.

Thanks for the bug report. I'm having trouble reproducing a similar
error reported in #895482 on package-removed CAs and have not merged
these reports because this error appears to be on locally installed
certificates. I believe they are related, however.

I will keep trying to reproduce and identify where the problem might be.

-- 
Kind regards,
Michael

Bug#895575:

[Kira Oliveira]

Eu quero participar.

Bug#894874: Fixed in mod_gnutls 0.8.4

[Daniel Kahn Gillmor]

Version: 0.8.4-1

On Sat 2018-04-14 11:56:42 +0200, Fiona Klute wrote:
> The issue is fixed in the 0.8.4 upstream release, please update the
> package. :-)

Thanks, Fiona!  I'm closing this ticket with the release of 0.8.4-1 into
unstable.

--dkg

Bug#895868: munin-cron: Fontconfig error: failed reading config file

[Calum Mackay]

Package: munin
Version: 2.0.37-1
Severity: important

I just upgraded munin from 2.0.34-3 to 2.0.37-1, amongst upgrading many
other pkgs too.

Since then, root is receiving emails from cron every 5 minutes:

Subject:

Cron  if [ -x /usr/bin/munin-cron ]; then 
/usr/bin/munin-cron; fi

Body:

Fontconfig error: failed reading config file
Fontconfig error: failed reading config file
Fontconfig error: failed reading config file
Fontconfig error: failed reading config file
Fontconfig error: failed reading config file


Although running it manually doesn't seem to:

$ sudo -u munin /usr/bin/munin-cron
$

thanks very much,
calum.

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

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

Versions of packages munin depends on:
ii  cron [cron-daemon]3.0pl1-130
ii  fonts-dejavu-core 2.37-1
ii  libdate-manip-perl6.70-1
pn  libdigest-md5-perl
ii  libfile-copy-recursive-perl   0.40-1
ii  libhtml-template-perl 2.97-1
ii  libio-socket-inet6-perl   2.72-2
ii  liblog-log4perl-perl  1.49-1
ii  libperl5.24 [libtime-hires-perl]  5.24.1-7
ii  libperl5.26 [libtime-hires-perl]  5.26.1-6
ii  librrds-perl  1.7.0-1+b1
pn  libstorable-perl  
ii  liburi-perl   1.73-1
ii  lsb-base  9.20170808
ii  munin-common  2.0.37-1
ii  perl  5.26.1-6
ii  rrdtool   1.7.0-1+b1
ii  systemd-sysv  238-4

Versions of packages munin recommends:
ii  libcgi-fast-perl  1:2.13-1
ii  munin-doc 2.0.37-1
ii  munin-node2.0.37-1

Versions of packages munin suggests:
ii  apache2 [httpd]   2.4.33-1
ii  elinks [www-browser]  0.12~pre6-13
ii  firefox-esr [www-browser] 52.7.3esr-1
ii  google-chrome-unstable [www-browser]  50.0.2657.0-1
pn  libapache2-mod-fcgid  
ii  libnet-ssleay-perl1.85-1
ii  links [www-browser]   2.14-5
ii  lynx [www-browser]2.8.9dev17-1
ii  w3m [www-browser] 0.5.3-36

-- Configuration Files:
/etc/munin/apache.conf changed:
Alias /munin /var/cache/munin/www

Require local
Options None
# This file can be used as a .htaccess file, or a part of your apache
# config file.
#
# For the .htaccess file option to work the munin www directory
# (/var/cache/munin/www) must have "AllowOverride all" or something 
# close to that set.
#
# AuthUserFile /etc/munin/munin-htpasswd
# AuthName "Munin"
# AuthType Basic
# require valid-user
# This next part requires mod_expires to be enabled.
#

# Set the default expiration time for files to 5 minutes 10 seconds from
# their creation (modification) time.  There are probably new files by
# that time. 
#

ExpiresActive On
ExpiresDefault M310

 
ScriptAlias /munin-cgi/munin-cgi-graph /usr/lib/munin/cgi/munin-cgi-graph

Require local
# AuthUserFile /etc/munin/munin-htpasswd
# AuthName "Munin"
# AuthType Basic
# require valid-user

SetHandler fcgid-script


SetHandler cgi-script


ScriptAlias /munin-cgi/munin-cgi-html /usr/lib/munin/cgi/munin-cgi-html

Require local
# AuthUserFile /etc/munin/munin-htpasswd
# AuthName "Munin"
# AuthType Basic
# require valid-user

SetHandler fcgid-script


SetHandler cgi-script



/etc/munin/apache24.conf changed:
Alias /munin /var/cache/munin/www


Require local
Require ip 192.168.254.0/24

Options None

ScriptAlias /munin-cgi/munin-cgi-graph /usr/lib/munin/cgi/munin-cgi-graph

Require local

SetHandler fcgid-script


SetHandler cgi-script




-- no debconf information

Bug#893806: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

[Hugo Lefeuvre]

Hi Salvatore,

> > I have successfully reproduced this issue in latest upstream master
> > branch and Buster but couldn't reproduce it neither in Wheezy nor in
> > Jessie or Stretch.
> > 
> > I am going to take a closer look, try to prepare a patch and declare
> > Wheezy, Jessie and Stretch unaffected if appropriate.
> 
> Please do it only mark as not-affected if you can confirm the
> vulneable source/issue is not there/why the issue is introduced later,
> but not only based on reproducibility. Just wanted to state that,
> although I think given you want to have a closer look, that implies
> already.

Sorry for my imprecision, with "take a closer look" I was meaning "I am
going to investigate the issue and, if applicable, prove that these
tiff versions are not affected by the issue". ;)

Cheers,
 Hugo

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA


signature.asc
Description: PGP signature

Bug#895866: tomcat8: Errors thrown when connecting to default HTTP connector (localhost:8080)

[Michael Welsh Duggan]

Package: tomcat8
Version: 8.5.30-1
Severity: normal

Dear Maintainer,

I had recently done an apt-get updgrade, and afterward I cannot connect
to localhost:8080, where I run a solr instance.  The logs have me
failing with the following error thrown:

16-Apr-2018 19:57:50.564 SEVERE [http-nio-8080-exec-1] 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error reading 
request, ignored
 java.lang.NoSuchMethodError: 
java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
at 
org.apache.coyote.http11.Http11InputBuffer.init(Http11InputBuffer.java:688)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:672)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:790)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1459)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)

The container is configured thusly:



Tomcat 8 is running under the following Java:
openjdk version "1.8.0_162"
OpenJDK Runtime Environment (build 1.8.0_162-8u162-b12-1-b12)
OpenJDK 64-Bit Server VM (build 25.162-b12, mixed mode)

I have attached a full log from starting tomcat8 until the failed server
request.

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

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

Versions of packages tomcat8 depends on:
ii  adduser3.117
ii  debconf [debconf-2.0]  1.5.66
ii  lsb-base   9.20170808
ii  tomcat8-common 8.5.30-1
ii  ucf3.0038

Versions of packages tomcat8 recommends:
ii  authbind   2.1.2
ii  libtcnative-1  1.2.16-1

Versions of packages tomcat8 suggests:
pn  tomcat8-admin 
pn  tomcat8-docs  
pn  tomcat8-examples  
pn  tomcat8-user  

-- debconf information:
  tomcat8/username: tomcat8
  tomcat8/javaopts: -Djava.awt.headless=true -XX:+UseConcMarkSweepGC
  tomcat8/groupname: tomcat8

-- 
Michael Welsh Duggan
(m...@md5i.com)

16-Apr-2018 19:57:31.158 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/var/lib/tomcat8/common/classes], exists: [false], isDirectory: 
[false], canRead: [false]
16-Apr-2018 19:57:31.160 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/var/lib/tomcat8/common], exists: [false], isDirectory: [false], 
canRead: [false]
16-Apr-2018 19:57:31.160 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/usr/share/tomcat8/common/classes], exists: [false], isDirectory: 
[false], canRead: [false]
16-Apr-2018 19:57:31.160 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/usr/share/tomcat8/common], exists: [false], isDirectory: [false], 
canRead: [false]
16-Apr-2018 19:57:31.161 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/var/lib/tomcat8/server/classes], exists: [false], isDirectory: 
[false], canRead: [false]
16-Apr-2018 19:57:31.162 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/var/lib/tomcat8/server], exists: [false], isDirectory: [false], 
canRead: [false]
16-Apr-2018 19:57:31.162 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/usr/share/tomcat8/server/classes], exists: [false], isDirectory: 
[false], canRead: [false]
16-Apr-2018 19:57:31.162 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/usr/share/tomcat8/server], exists: [false], isDirectory: [false], 
canRead: [false]
16-Apr-2018 19:57:31.162 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/var/lib/tomcat8/shared/classes], exists: [false], isDirectory: 
[false], canRead: [false]
16-Apr-2018 19:57:31.162 WARNING [main] 
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with 
directory [/var/lib/tomcat8/shared], exists: [false], isDirectory: [false], 

Bug#895867: RM: haskell-conduit-combinators -- ROM; DEPRECATED; functionality merged into the haskell-conduit

[Clint Adams]

Package: ftp.debian.org
Severity: normal

haskell-conduit-combinators is deprecated and obsolete.  All
of its functionality has been merged into haskell-conduit.

Bug#887725: what's holding up 2.93 from debian?

[Antoine Beaupré]

Control: forcemerge 890325 887725

Any reason why the newer version has not been packaged in Debian yet?

(Any plans on switching away from Alioth as well for git?)

A.

-- 
À mesure que l'opression s'étend à tous les secteurs de la vie,
la révolte prend l'allure d'une guerre sociale. 
Les émeutes renaissent et annoncent la révolution à venir.
- Jean-François Brient, de la servitude moderne

Bug#895575:

[Renata Pachiel]

I would like to participate in this list.

Bug#875460: Fwd: `rm *` count is incorrect with `setopt GLOB_DOTS`

[Bart Schaefer]

The below patch (with mangled whitespace corrected) should be in the
zsh 5.5.1 release.

-- Forwarded message --
From: Bart Schaefer 
Date: Fri, Apr 13, 2018 at 6:48 PM
Subject: Re: `rm *` count is incorrect with `setopt GLOB_DOTS`
To: zsh-work...@plast.id.au
Cc: "zsh-work...@zsh.org" 


On Fri, Apr 13, 2018 at 5:23 PM,   wrote:
>
> When I run `rm *`, zsh asks if I "want to delete all x files", where x
> is the number of files to be deleted. However, with `setopt GOB_DOTS`,
> this number appears to be two more than the actual number of files.

It's counting "." and ".." because, well, they begin with a dot.

It's actually wrong any time the directory contains files beginning
with ".", it's just LESS wrong when GLOB_DOTS.

Apologies if this gets line-folded badly:

diff --git a/Src/utils.c b/Src/utils.c
index 180693d..2a006b4 100644
--- a/Src/utils.c
+++ b/Src/utils.c
@@ -2775,10 +2775,11 @@ checkrmall(char *s)
 const int max_count = 100;
 if ((rmd = opendir(unmeta(s {
 int ignoredots = !isset(GLOBDOTS);
-/* ### TODO: Passing ignoredots here is wrong.  See workers/41672
-   aka .
- */
-while (zreaddir(rmd, ignoredots)) {
+char *fname;
+
+while ((fname = zreaddir(rmd, 1))) {
+if (ignoredots && *fname == '.')
+continue;
 count++;
 if (count > max_count)
 break;

Bug#850587: Processed: retitle to RFP: cohomcalg -- sheaf cohomology of line bundles on toric varieties

[Doug Torrance]

Control: retitle -1 ITP: cohomcalg -- sheaf cohomology of line bundles on toric 
varieties
Control: owner -1 !

On 04/14/2018 12:24 AM, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
>> retitle 850587 RFP: cohomcalg -- sheaf cohomology of line bundles on toric 
>> varieties
> Bug #850587 [wnpp] ITP: cohomcalg -- sheaf cohomology of line bundles on 
> toric varieties
> Changed Bug title to 'RFP: cohomcalg -- sheaf cohomology of line bundles on 
> toric varieties' from 'ITP: cohomcalg -- sheaf cohomology of line bundles on 
> toric varieties'.
>> noowner 850587
> Bug #850587 [wnpp] RFP: cohomcalg -- sheaf cohomology of line bundles on 
> toric varieties
> Removed annotation that Bug was owned by Doug Torrance 
> .
>> stop
> Stopping processing here.
> 
> Please contact me if you need assistance.

I'm still in the process of packaging cohomcalg.  (It's been rejected from NEW 
three times
for copyright issues...)

Doug

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

[Manuel A. Fernandez Montecelo]

Source: leptonlib
Version: 1.75.3-3
Severity: normal
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

We are in the process of bootstrapping a Debian port for the riscv64
architecture (https://wiki.debian.org/RISC-V).

The files config.{guess,sub} included in this package are too old to detect this
system.

This package is quite important as it's a dependency of ffmpeg, and thus of all
of its many reverse-dependencies.

Debian Policy §4.3 recommends to update these automatically [1], one of the best
ways to achieve this is to depend on newer versions of debhelper (the current
level used by this package is deprecated) and use dh-autoreconf.

If you need help or want us to provide a patch, prefer that we NMU, etc., please
tell.


[1] https://www.debian.org/doc/debian-policy/#changes-to-the-upstream-sources

"You should make sure that the configure utility detects the correct
architecture specification string (refer to Architecture specification
strings for details).

If your package includes the scripts config.sub and config.guess, you should
arrange for the versions provided by the package autotools-dev be used
instead (see autotools-dev documentation for details how to achieve
that). This ensures that these files can be updated distribution-wide at
build time when introducing new architectures."


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 

Bug#881099: libatk-adaptor: breaks LibreOffice TexMaths extension

[Samuel Thibault]

Control: reassign -1 libreoffice
Control: fixed -1 1:6.0.2-1+b1

Hello,

Alex ARNAUD, le mer. 08 nov. 2017 14:01:48 +0100, a ecrit:
> Thank Paul for forwarding us this issue.
> 
> I'm not sure it is due to libatk-adaptor itself. As I understand of the a11y
> stack on GNU/Linux, libatk-adaptor is the bridge between GTK applications
> and AT-SPI2. If libatk-adaptor is not installed, LibreOffice should provide
> no feedback to assistive technologies. So it seems it is an issue from
> LibreOffice itself.

I tend to think the same: atk-adaptor itself does not do much beyond
transmitting information from libreoffice to at-spi.  But that triggers
code inside libreoffice that wouldn't be executed otherwise, so I guess
the bug is only a side effect inside libreoffice of the presence of
atk-adaptor.

I could reproduce the issue in Stretch indeed (atk-adaptor 2.22.0,
libreoffice 5.2).

I tried to reproduce the bug with Buster (atk-adaptor 2.26.2,
libreoffice 6.0.2), things worked fine.

I also tried to use the straightforward backport of buster's atk-adaptor
2.26.2 into stretch, and could reproduce the issue.

So I believe the issue really was in libreoffice, and is now away.

Samuel

Bug#895857: coreutils: Additional information about coreutils from sid

[Claudio Giordano]

Package: coreutils
Version: 8.28-1
Followup-For: Bug #895857

Dear Maintainer,

same compile issue is present also on sid release on newer coreutils version:

$ ldd /usr/bin/sha1sum 
linux-vdso.so.1 (0x7ffc39ca8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fb2033b1000)
/lib64/ld-linux-x86-64.so.2 (0x7fb203977000)

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

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

Versions of packages coreutils depends on:
ii  libacl1  2.2.52-3+b1
ii  libattr1 1:2.4.47-2+b2
ii  libc62.27-3
ii  libselinux1  2.7-2+b2

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#895825: neovim: Package suggests python-neovim but there is no installation candidate.

[James McCoy]

On Mon, Apr 16, 2018 at 10:22:18AM -0400, Michael P. Soulier wrote:
> When I attempt to install neovim, the python-neovim package is
> suggested. But if I try to install that, I am told that there is no
> installation candidate.

That's because python(3)-neovim didn't make it into Stretch.  There's
not much that can be done about that now.

After neovim's next upstream release, we'll look at providing backports
for neovim and python(3)-neovim.  That's as close to a fix as we can
provide.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#895863: python-acme: Unroutable maintainer address

[Scott Kitterman]

Package: python-acme
Version: 0.22.2-1
Severity: serious
Justification: Policy 3.3

Dear Maintainer,

After a recent upload, the FTP team received this error:

This message was created automatically by mail delivery software.

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

  letsencrypt-de...@lists.alioth.debian.org
host alioth-lists-mx.debian.net [2001:ba8:0:2c77:0:4:0:1]
SMTP error from remote mail server after RCPT 
TO::
550 Unrouteable address

Policy 3.3 requires a working email address for the package maintainer.  This
may be an issue with the recent migration of alioth lists to a new host.

Scott K

Bug#895862: dxf2gcode: Crashes "UnboundLocalError: local variable 'entities' referenced before assignment"

[Paul "LeoNerd" Evans]

Package: dxf2gcode
Version: 20170925-3
Severity: normal

Attempting to load a .dxf file, the entire program crashes out with:

Loading file: /home/leo/electronics/eload/panels/top.dxf
Reading DXF Structure
Traceback (most recent call last):
  File "/usr/bin/dxf2gcode", line 727, in open
self.load()
  File "/usr/bin/dxf2gcode", line 844, in load
self.valuesDXF = ReadDXF(self.filename)
  File "/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/importer.py", line 
85, in __init__
self.entities = self.Read_Entities(sections_pos)
  File "/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/importer.py", line 
347, in Read_Entities
return entities
UnboundLocalError: local variable 'entities' referenced before assignment
Aborted

In case it's useful, I've attached the .dxf file in question. This .dxf
was exported by Inkscape:

  $ inkscape --version
  Inkscape 0.92.2 (5c3e80d, 2017-08-06)


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

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

Versions of packages dxf2gcode depends on:
ii  poppler-utils   0.61.1-2
ii  pstoedit3.70-5+b1
ii  python3 3.6.4-1
ii  python3-opengl  3.1.0+dfsg-1
ii  python3-pyqt5   5.9.2+dfsg-1+b1

dxf2gcode recommends no packages.

dxf2gcode suggests no packages.

-- no debconf information


-- 
Paul "LeoNerd" Evans

leon...@leonerd.org.uk  |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

Bug#893297: Pending fixes for bugs in the livetribe-jsr223 package

[pkg-java-maintainers]

tag 893297 + pending
thanks

Some bugs in the livetribe-jsr223 package are closed in revision
6dff5ac8bd90b87485758a46092bbd1695370420 in branch 'master' by Markus
Koschany

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/livetribe-jsr223.git/commit/?id=6dff5ac

Commit message:

Skip the tests.

Closes: #893297

Bug#895861: mutt: 886104-abort_noattach.patch dropped but the patch is not really upstream

[Mattia Rizzolo]

Package: mutt
Version: 1.9.5-1

Hi Antonio,

In 1.9.5-1 you removed the 886104-abort_noattach.patch patch as "applied
upstream", but upstream applied it only to master, it isn't merged into
stable and so it's not in the 1-9-5-rel tag.

Could you please bring it back? :)

-- 
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#895827: Confirm Fix in Open MPI 3.0.1-5 Build

[Ron Lovell]

 The issue is resolved for my system by the 3.0.1-5 build. I tested
interactively and as part of a Slurm batch job where I let Slurm provide
the task count to mpiexec(1). (No -np option.)

I also confirmed that installation of libpmix2 is not required.

Great work!

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#895327: Confirm Fix in Open MPI 3.0.1-5 Build

[Ron Lovell]

The issue is resolved for my system by the 3.0.1-5 build. I tested
interactively and as part of a Slurm batch job where I let Slurm provide
the task count to mpiexec(1). (No -np option.)

I also confirmed that installation of libpmix2 is not required.

Great work!

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#895859: gir-to-d: Unroutable maintainer address

[Scott Kitterman]

Package: gir-to-d
Version: 0.15.0-1
Severity: serious
Justification: Policy 3.3

Dear Maintainer,

After a recent upload, the FTP team received this error:

This message was created automatically by mail delivery software.

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

  pkg-d-de...@lists.alioth.debian.org
host alioth-lists-mx.debian.net [2001:ba8:0:2c77:0:4:0:1]
SMTP error from remote mail server after RCPT 
TO::
550 Unrouteable address

Policy 3.3 requires a working email address for the package maintainer.  This
may be an issue with the recent migration of alioth lists to a new host.

Scott K

Bug#895860: geany-plugins: Unroutable maintainer address

[Scott Kitterman]

Package: geany-plugins
Version: 1.33+dfsg-1
Severity: serious
Justification: Policy 3.3

Dear Maintainer,

After a recent upload, the FTP team received this error:

This message was created automatically by mail delivery software.

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

  pkg-geany-t...@lists.alioth.debian.org
host alioth-lists-mx.debian.net [2001:ba8:0:2c77:0:4:0:1]
SMTP error from remote mail server after RCPT 
TO::
550 Unrouteable address

Policy 3.3 requires a working email address for the package maintainer.  This
may be an issue with the recent migration of alioth lists to a new host.

Scott K

Bug#895856: portmidi: maintainer address bounces mail from Debian system

[Paul Brossier]

ouch, thanks for notifying, it seems spf config is borken on my host,
will fix it asap.

best, piem

On 04/16/2018 11:54 PM, Thorsten Glaser wrote:
> Source: portmidi
> Version: 1:217-6
> Severity: serious
> 
> -- Forwarded message --
> From: Mail Delivery System 
> Message-ID: 
> X-Spam-Status: Yes, hits=0.99 required=0.90, tests=bmf
> To: t...@debian.org
> Date: Mon, 16 Apr 2018 18:04:58 +
> Subject: Mail delivery failed: returning message to sender
> 
> This message was created automatically by mail delivery software.
> 
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
> 
>   p...@piem.org
> retry timeout exceeded
> 
> 
> 
> Reporting-MTA: dns; mailly.debian.org
> 
> Action: failed
> Final-Recipient: rfc822;p...@piem.org
> Status: 5.0.0
> 



signature.asc
Description: OpenPGP digital signature

Bug#895858: jumpnbump: update jumpnbump-menu to gtk3 will be required in the future

[Stéphane Blondon]

Package: jumpnbump
Version: 1.60-3
Severity: wishlist

Dear Maintainer,

the current version of jumpnbump-menu is written in python2 and use
gtk2.
Python2 will be in end of life in 2020 by the upstream.
gtk2 will be removed in one or two releases.


This is a draft (in attachments) for updating jumpnbump-menu to python3
and gtk3. The standalone mode and the options work, but there are still
some problems:
- server and client modes are not correctly selected
- the windows are not translated
- the about windows has a strange behavior when requested to close.

I don't have currently the time to work on it but I plan to do it in the
future.

Stéphane


jumpnbump.glade
Description: application/glade
#!/usr/bin/python3

# Copyright (C) 2002 Martin Willemoes Hansen 
# Copyright (C) 2018 Stéphane Blondon
#
# Jump 'n Bump is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# Jump 'n Bump is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, 
USA.

# Next two lines are a workaround for Debian bug 163794
import sys

import gi
gi.require_version("Gtk", "3.0")
from gi.repository import Gtk

from gi.repository import GObject

import os
import tempfile
import shutil
import gettext

RESOURCE_DIR = '/usr/share/games/jumpnbump'
BINARY_DIR = '/usr/games'
UNPACK_BIN = '/usr/games/jnbunpack'

application = "jumpnbump-menu"
gettext.install(application)


def populate_treeview():
levels = []
add_levels(levels, RESOURCE_DIR)
add_levels(levels, os.path.expanduser("~/.jumpnbump/levels"))

levels = sorted(levels, key=lambda level: level[0])

COLUMN_LEVEL = 0
COLUMN_DIR = 1
store = Gtk.ListStore(GObject.TYPE_STRING, GObject.TYPE_STRING)

for level in levels:
iter = store.append()
store.set(iter, COLUMN_LEVEL, level[0], COLUMN_DIR, level[1])

treeview.set_model(store)

renderer = Gtk.CellRendererText()
treeview.append_column(Gtk.TreeViewColumn(
_('Level'), renderer, text=COLUMN_LEVEL))


def add_levels(levels, dir):
try:
for file in os.listdir(dir):
if (file.endswith('.dat') or file.endswith('.DAT')):
levels.append((file, dir))
except OSError as err:
print("%s not found (%s)." % (dir,  str(err)))


def standalone_mode(widget):
disable_enable_level(1)
disable_enable_server(0)
num_clients.set_sensitive(0)
nogore.set_sensitive(1)
noflies.set_sensitive(1)


def client_mode(widget):
disable_enable_level(1)
disable_enable_server(1)
num_clients.set_sensitive(0)
nogore.set_sensitive(1)
noflies.set_sensitive(1)


def server_mode(widget):
disable_enable_level(1)
disable_enable_server(0)
num_clients.set_sensitive(1)
nogore.set_sensitive(1)
noflies.set_sensitive(1)


def disable_enable_server(setting):
server_entry.set_sensitive(setting)
player_num.set_sensitive(setting)


def disable_enable_level(setting):
treeview.set_sensitive(setting)
mirror.set_sensitive(setting)
if (not setting):
mirror.set_active(setting)


def level_changed(widget):
model, iter = treeview.get_selection().get_selected()
global choosen_level
choosen_level = '%s/%s' % (model.get_value(iter, 1),
   model.get_value(iter, 0))
unpackdir = None
try:
unpackdir = tempfile.mkdtemp("", "jumpnbump-menu-")
os.chdir(unpackdir)
os.spawnlp(os.P_WAIT, UNPACK_BIN,
   'unpack', choosen_level)
os.spawnlp(os.P_WAIT, 'convert', 'convert', '-scale',
   '50%', 'level.pcx', 'level_scaled.pcx')
os.spawnlp(os.P_WAIT, 'convert', 'convert',
   'level_scaled.pcx', 'level.png')
image.set_from_file('level.png')
except Exception as err:
print(err)
finally:
if unpackdir != None:
shutil.rmtree(unpackdir)

image.show()


def about(widget):
global about_dialog

if (not about_dialog):
#gui = Gtk.glade.XML(gladefile, 'about', domain=application)
#about_dialog = gui.get_widget('about')
#gui.signal_connect('ok', about_close)
gui = _get_builder()
about_dialog = gui.get_object('about')
about_dialog.show_all()
gui.connect_signals({'ok': about_close})


def about_close(widget):
global about_dialog

about_dialog.destroy()
about_dialog = None


def run(widget):
if 

Bug#895857: coreutils: sha1sum and other hashing tools are compiled without libcrypto support

[Matteo Croce]

Package: coreutils
Version: 8.26-3
Severity: normal

Dear Maintainer,

the sha{1,224,256,384,512}sum tools included in the coreutils package
can be compiled with libcrypto support. At the expense of a runtime dependency,
the speed gain of the hash calculation is quite noticeable under amd64:

matteo@saturno:~$ dd status=none if=/dev/zero bs=1G count=10 |time -p sha1sum
a0b6e2ca4e28360a929943e8eb966f703a69dc44  -
real 29.27
user 25.71
sys 1.68
matteo@saturno:~$ dd status=none if=/dev/zero bs=1G count=10 |time -p ./sha1sum
a0b6e2ca4e28360a929943e8eb966f703a69dc44  -
real 20.91
user 17.35
sys 1.67

while it's huge on aarch64:

matteo@macchiatobin:~$ dd status=none if=/dev/zero bs=1G count=10 |time -p 
sha1sum
a0b6e2ca4e28360a929943e8eb966f703a69dc44  -
real 49.37
user 44.34
sys 3.11
matteo@macchiatobin:~$ dd status=none if=/dev/zero bs=1G count=10 |time -p 
./sha1sum
a0b6e2ca4e28360a929943e8eb966f703a69dc44  -
real 15.53
user 9.88
sys 3.37

ldd output between Debian binary and the test one (grabbed from a Fedora 27 RPM)

matteo@saturno:~$ ldd /usr/bin/sha1sum
linux-vdso.so.1 (0x7fff4a5be000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f01debf3000)
/lib64/ld-linux-x86-64.so.2 (0x7f01df19e000)
matteo@saturno:~$ ldd ./sha1sum
linux-vdso.so.1 (0x7fffcabc7000)
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 
(0x7fb4a7086000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fb4a6ce7000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fb4a6ae3000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fb4a68c6000)
/lib64/ld-linux-x86-64.so.2 (0x7fb4a7724000)


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

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

Versions of packages coreutils depends on:
ii  libacl1  2.2.52-3+b1
ii  libattr1 1:2.4.47-2+b2
ii  libc62.24-11+deb9u3
ii  libselinux1  2.6-3+b3

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#895856: portmidi: maintainer address bounces mail from Debian system

[Thorsten Glaser]

Source: portmidi
Version: 1:217-6
Severity: serious

-- Forwarded message --
From: Mail Delivery System 
Message-ID: 
X-Spam-Status: Yes, hits=0.99 required=0.90, tests=bmf
To: t...@debian.org
Date: Mon, 16 Apr 2018 18:04:58 +
Subject: Mail delivery failed: returning message to sender

This message was created automatically by mail delivery software.

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

  p...@piem.org
retry timeout exceededReporting-MTA: dns; mailly.debian.org

Action: failed
Final-Recipient: rfc822;piem@piem.org
Status: 5.0.0
--- Begin Message ---
retitle 870787 liboss4-salsa*: please add six snd_{midi,seq}_* functions
affects 870787 src:portmidi
thanks

Hello again,

we also need the following symbols in oss-salsa:

• snd_midi_event_encode_byte
• snd_midi_event_free
• snd_midi_event_new
• snd_seq_delete_port
• snd_seq_disconnect_from

These are required to build src:portmidi, which is a new
dependency of src:musescore, and thus extending the scope
of this bugreport instead of creating a new one. Just to
remind, we also need this:

• snd_seq_event_length

Please d̲o̲ provide this!


Small side note: perhaps, given enough functions in oss-salsa,
portaudio19 could also use it, achieving feature parity. (Which
is why I Cc’d its maintainers as well.)

Thanks in advance,
//mirabilos
-- 
21:12⎜ sogar bei opensolaris haben die von der community so
ziemlich jeden mist eingebaut │ man sollte unices nich so machen das
desktopuser zuviel intresse kriegen │ das macht die code base kaputt
21:13⎜ linux war früher auch mal besser :D
--- End Message ---

Bug#895855: debian-handbook: apt-key add should not be used

[sergio]

Package: debian-handbook
Version: 8.20170125
Severity: normal

Dear Maintainer,

man APT-KEY(8) on stretch for the "add" command says

"Note: Instead of using this command a keyring should be placed directly
in the /etc/apt/trusted.gpg.d/ directory with a descriptive name and
either "gpg" or "asc" as file extension."

but "The Debian Administrator's Handbook" and
https://www.debian.org/doc/manuals/securing-debian-howto/ch7
still say to use apt-key add.



-- 
sergio.

Bug#895811: inotify-tools: do not enable sanitizers in production

[Chris Lamb]

Hi all,

FYI this was filed as wishlist bug against Lintian (#895831) which
is fixed in Git, pending upload:

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

  checks/rules.desc  | 18 ++
  data/rules/rules-should-not-use|  1 +
  debian/changelog   |  3 +++
  .../rules-sanitize-all-buildflag/debian/debian/rules   |  6 ++
  t/tests/rules-sanitize-all-buildflag/desc  |  5 +
  t/tests/rules-sanitize-all-buildflag/tags  |  1 +
  6 files changed, 34 insertions(+)


Regards,

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

Bug#895831: lintian should warn on sanitize=+all in debian/rules

[Chris Lamb]

tags 895831 + pending
thanks

Fixed in Git, pending upload:

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

  checks/rules.desc  | 18 ++
  data/rules/rules-should-not-use|  1 +
  debian/changelog   |  3 +++
  .../rules-sanitize-all-buildflag/debian/debian/rules   |  6 ++
  t/tests/rules-sanitize-all-buildflag/desc  |  5 +
  t/tests/rules-sanitize-all-buildflag/tags  |  1 +
  6 files changed, 34 insertions(+)


Regards,

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

Bug#879619: Autopkgtest for ncbi-tools6

[Liubov Chuprikova]

Hi Aaron,

On Fri, 13 Apr 2018 at 02:04 Aaron M. Ucko  wrote:

> Liubov Chuprikova  writes:
>
> > On Thu, 12 Apr 2018 at 17:30 Aaron M. Ucko  wrote:
> >
> >>
> >> That said, you did catch a bug in taxblast; I'll push a fix this
> >> evening.  (The binary will still require a network connection, just
> >> actually be able to use it now).
> >>
> >
> > Ok, thank you!
>
> Fix pushed, no problem.  I'd also be happy to sponsor the upload if
> you'd like.
>

Sorry for a delay, but I was planning to make one more effort on extending
the set of tests. At the moment, the following commands are still lacking
tests:

   - *asn2ff*, *gbseqget*, *findspl* (their output indicates they are
   obsolete and/or unsupported)
   - *asndhuff*, *nps2gps* (I can't figure out what kind of inputs they
   require)
   - *fa2htgs*, *spidey* (they look too complicated for me and require much
   time to understand how they work)
   - *taxblast* doesn't generate an output file and only generates an
   *incomplete* html
   - *errhdr*, *sortbyquote* (I can't figure out even what they are
   supposed to do)

If nothing critical is left without a test, then I'd like to ask you to
sponsor the upload. If you need any additional information about *taxblast*,
I'll be happy to provide it.

Thank you,
Liubov

Bug#895839: src:zotero-standalone-build: New version available

[Sébastien Villemot]

Control: forcemerge 871502 -1

Hi Andreas,

On Mon, Apr 16, 2018 at 07:41:38PM +0200, Andreas Tille wrote:
> Package: src:zotero-standalone-build
> Severity: wishlist

> upstream is at release 5.0.44.  It would be nice if this could be
> packaged for Debian.
> 
> Please also notice that the development platform Alioth is shut down in
> about two weeks.  I have migrated several packages to Salsa and since I
> have some interest in zotero I would volunteer to move the packaging.  I
> could also try to do the version upgrade as well as bumping
> Standards-Version and some general packaging upgrades.

Upgrading Zotero involves a lot of Javascript work, which is far beyond what I
can possibly do, so please help as much as you can. See the discussion in
#871502.

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#895636: meson: more tools missing from debcrossgen

[Jussi Pakkanen]

On Fri, Apr 13, 2018 at 7:17 PM, Helmut Grohne  wrote:

> For Debian systems, most architecture-dependent tools carry the GNU
> triplet as prefix. Thus we can assign "${DEB_HOST_GNU_TYPE}-" as the
> tool_prefix and solve most of missing entries.
>
> Please consider implementing the proposed tool_prefix rather than just
> adding ld and objcopy to debcrossgen.

Feature freeze for the next version of Meson passed a few days ago,
thus the proposed change can not be added to it. The next package
upload will have an updated crossgen that contains objcopy and ld.

Bug#895393: tracker.debian.org thinks 3.9.8 is the latest standards version

[Raphael Hertzog]

Control: tag -1 + newcomer

Hello,

On Wed, 11 Apr 2018, dequis wrote:
> The old package tracker complains that my package is "severely out of
> date", while the new one thinks it is up to date and doesn't complain
> about anything.
[...]
> < pabs> IIRC the tracker code looks at the version of the debian-policy
> package

Right, the package tracker looks at the version of the debian-policy
package at the time of the upload of the package. But it fails to redo
the check for old packages once that a new debian-policy version is
available...

If anyone wants to try to tackle this bug, the code is in
distro_tracker/stdver_warnings/tracker_tasks.py

This would be easier to fix if Tasks had persistent data associated
to them (which is planned as part of
https://salsa.debian.org/qa/distro-tracker/issues/8) but it's possible
to fix it already by detecting when debian-policy is among updated
packages (i.e. returned by get_packages_from_events()) and then decide
to reprocess all packages anyway.

In the mean time, I'm forcing a full run on all packages.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#894993: patch: CVE-2018-1000156: input validation vulnerability when processing patch files

[Chris Lamb]

Moritz Muehlenhoff wrote:

> We're not planning to issue a DSA for this, but Laszlo is working on
> updates for point releases. Best to sync up directly with him if only to 
> compare the debdiffs you came up with.

Nod, thanks. Well, I wouldn't want to duplicate work ("compare debdiffs").

Laszlo, would you like me to co-ordindate jessie-pu and stretch-pu's or have
you got this?  (Feel free to drop t...@security.debian.org on any reply..)


Best wishes,

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

Bug#895854: sphinx: autopkgtests fail because upstream removed tests/run.py

[Paul Gevers]

Source: sphinx
Version: 1.7.2-1
Severity: normal
User: debian...@lists.debian.org
Usertags: regression

Since the upload of sphinx version 1.7.2-1, the autopkgtest¹ fails. This
is apparently due to the removal of the script called by the test. There
is no tests/run.py anymore in the upstream code.

Could you please fix your autopkgtests?

Error messages:

autopkgtest [06:49:05]: test python-sphinx: [---
python2.7: can't open file 'tests/run.py': [Errno 2] No such file or
directory
autopkgtest [06:49:05]: test python-sphinx: ---]
autopkgtest [06:49:05]: test python-sphinx:  - - - - - - - - - - results
- - - - - - - - - -
python-sphinxFAIL non-zero exit status 123


autopkgtest [06:50:33]: test python3-sphinx: [---
python3.6: can't open file 'tests/run.py': [Errno 2] No such file or
directory
autopkgtest [06:50:33]: test python3-sphinx: ---]
autopkgtest [06:50:33]: test python3-sphinx:  - - - - - - - - - -
results - - - - - - - - - -
python3-sphinx   FAIL non-zero exit status 123

Paul

¹ https://ci.debian.net/packages/s/sphinx





signature.asc
Description: OpenPGP digital signature

Bug#895824: autopkgtest: autopkgtest failure on some architectures

[Graham Inggs]

Hi Paul

On 16 April 2018 at 20:38, Paul Gevers  wrote:
> os.listdir turns out to return in undefined order. So that needs
> sorting. I created a patch, could you please try it out? I verified it
> on amd64.

FWIW, I ran the tests against my Ubuntu PPA and they passed on all
Ubuntu's release architectures.  Attached are logs for i386 and s390x.

Regards
Graham


log-i386.gz
Description: application/gzip


log-s390x.gz
Description: application/gzip

Bug#892458: Fwd: [Debian-astro-maintainers] ftools update

[Salvatore Bonaccorso]

Hi Sam,

On Mon, Apr 09, 2018 at 10:19:34AM +1000, Sam Fowler wrote:
> On Wed, 14 Mar 2018 16:22:19 +0100 Ole Streicher  wrote:
> > FYI
> > 
> > 
> >  Forwarded Message 
> > Subject: [Debian-astro-maintainers] ftools update
> > Date: Wed, 14 Mar 2018 10:42:25 -0400
> > From: Michael Arida 
> > To: debian-astro-maintain...@lists.alioth.debian.org
> > 
> > 
> > Dear Debian Astro Maintainers,
> > 
> > As you may have noticed CFITSIO was updated Friday (March 2) for a
> > major bug fix.  Since you have a software bundle that uses what we
> > assume is CFITSIO somewhere under the hood, we wanted to let you know
> > that you should update that code.  We are also expecting another
> > update in April.
> > 
> > If you have any questions or concerns, feel free to contact me.
> > 
> > Regards,
> >  Mike Arida
> > 
> > Michael Arida (ADNET) ASD/HEASARC
> > 301.286.2291/1215 (voice/fax)  Code 660, NASA/GSFC
> > michael.ar...@nasa.gov Greenbelt, MD 20771
> > 
> > ___
> > Debian-astro-maintainers mailing list
> > debian-astro-maintain...@lists.alioth.debian.org
> > https://lists.alioth.debian.org/mailman/listinfo/debian-astro-maintainers
> 
> This has been assigned has been assigned CVE-2018-1000166.

Looking at
https://www.talosintelligence.com/vulnerability_reports/TALOS-2018-0531
https://www.talosintelligence.com/vulnerability_reports/TALOS-2018-0529
it looks for those issues already CVE-2018-3848, CVE-2018-3849 and
CVE-2018-3846 were assigned and CVE-2018-1000166 is duplicate. Can you
confirm? And if so ask for rejection of CVE-2018-1000166?

Regards,
Salvatore

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

[Moritz Muehlenhoff]

Stefan Fritsch wrote:
> On Monday, 16 April 2018 20:34:00 CEST Matthew Gabeler-Lee wrote:
> > On Sat, 14 Apr 2018, Stefan Fritsch wrote:
> > > This seems to be a systemd bug. Changing PrivateTmp from true to false in
> > > apache2.service fixes the issue. But even with PrivateTmp it works for
> > > some time. It would be interesting what is the trigger to make it fail
> > > later on.
> > 
> > Hmm ... I was having a problem on some systems where tmpreaper, in its
> > default configuration, will eventually delete all the directories
> > systemd creates to support PrivateTmp, which might explain this...
> 
> That seems a likely explanation. I have tmpreaper installed, too. The default 
> keep time is 7 days, which explains why the issue does not appear immediately.
> 
> So tmpreaper should exclude systemd-private-* files by default. Moritz, do 
> you 
> also have some cron job cleaning up stale files in /tmp ?

Good catch, in fact we do! And it's only enabled for our mediawiki 
installations,
which would also explain why we don't run into it with our other Apache 
installations
on stretch:
https://github.com/wikimedia/puppet/blob/production/modules/profile/manifests/mediawiki/common.pp#L16
and 
https://github.com/wikimedia/puppet/blob/production/modules/tmpreaper/manifests/init.pp

Cheers,
Moritz

Bug#887924: slurm-drmaa FTBFS with slurm-llnl 17.11.2-1

[Dominique Belhachemi]

The bug is also in Debian's slurm-llnl package. The location of the header
files is not consistent anymore.

slurm.h is including 

See
https://anonscm.debian.org/git/collab-maint/slurm-llnl.
git/commit/debian/libslurm-dev.install?id=08c387553a95e9a4a38047c82cf69a
4f733cee0d
https://anonscm.debian.org/git/collab-maint/slurm-llnl.git/tree/slurm/slurm.h.in?id=a886927a2c465f2b82d2773190daa6d77e8ffd4f#n63

Bug#895853: new upstream release (4.0.0~beta5)

[Daniel Baumann]

Package: calendar-exchange-provider
Severity: wishlist

Hi,

thank you for maintaining calendar-exchange-provider in Debian.

It would be nice if you could upgrade it to the current upstream version
(4.0.0~beta5).

Regards,
Daniel

Bug#895575: (no subject)

[Daniel Lenharo]

I want to see this list on Debian. I hope that Brazilians womens have a
channel that could use to organize and improve diversity in Brazil

-- 
Daniel Lenharo de Souza
http://www.lenharo.eti.br
GPG: 31D8 0509 460E FB31 DF4B
 9629 FB0E 132D DB0A A5B1



signature.asc
Description: OpenPGP digital signature

Bug#895851: sh: 1: /usr/local/share/gkrellm/GrabWeather: not found

[Roland Hieber]

Package: gkrellweather
Version: 2.0.8-2.1~ppa1
Followup-For: Bug #895851

Here is that patch I mentioned...
From: Roland Hieber 
Subject: set PREFIX to /usr, not /usr/local
 A distribution package should not need to refer to /usr/local at all.
 Specifically, this default leads to GrabWeather being searched in /usr/local,
 where it is obviously not installed.
Forwarded: not-needed

--- a/Makefile
+++ b/Makefile
@@ -3,7 +3,7 @@
 CFLAGS += -O2 -std=gnu99 -Wall -fPIC `pkg-config gtk+-2.0 --cflags`
 LIBS = `pkg-config gtk+-2.0 --libs`
 LDFLAGS += -shared
-PREFIX = /usr/local
+PREFIX = /usr
 
 LOCALEDIR := $(PREFIX)/share/locale
 

Bug#895852: chrony FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: chrony
Version: 3.3-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

chrony fails to cross build from source, because it uses the build
architecture compiler. The configure script expects cross builders to
supply a CC variable and feed uname results via --host-*. Since the
Debian package is only built for linux-any, We can pass
--host-system=Linux and ignore the other values as they are not relevant
on Linux. The attached patch implements that and makes chrony cross
buildable. Please consider applying it.

Helmut
--- chrony-3.3/debian/changelog
+++ chrony-3.3/debian/changelog
@@ -1,3 +1,10 @@
+chrony (3.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass CC to make and set --host-system. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 16 Apr 2018 22:04:26 +0200
+
 chrony (3.3-1) unstable; urgency=medium
 
   * Import upstream version 3.3:
--- chrony-3.3/debian/rules
+++ chrony-3.3/debian/rules
@@ -1,5 +1,8 @@
 #!/usr/bin/make -f
 
+-include /usr/share/dpkg/buildtools.mk
+export CC
+
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
 BASE=debian/chrony
@@ -9,6 +12,7 @@
 
 override_dh_auto_configure:
dh_auto_configure --  --mandir=/usr/share/man \
+   --host-system=Linux \
--sysconfdir=/etc/chrony \
--without-readline \
--with-user=_chrony \

Bug#895851: sh: 1: /usr/local/share/gkrellm/GrabWeather: not found

[Roland Hieber]

Package: gkrellweather
Version: 2.0.8-2.1
Severity: normal

Dear Maintainer,

when I start gkrellm from a terminal, enable the gkrellweather plugin
and set the station ID to EDVE (Braunschweig, Germany), it seems that
gkrellweather cannot fetch data. It repeatedly prints

  sh: 1: /usr/local/share/gkrellm/GrabWeather: not found

every few minutes or so, and temperature stays at -99°C.

I can edit ~/.gkrellm2/user-config and set the command to
/usr/share/gkrellm/GrabWeather manually, but it would be better to have
a sane default. Apparently, gkrellweather.c lines 724 and 989 say:

  snprintf(options.command, 512, PREFIX "/share/gkrellm/GrabWeather %s", 
options.station);

and PREFIX is hardcoded in Makefile as /usr/local, so I suggest to add
the attached patch ot change PREFIX to /usr.

Cheers,
 - Roland

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

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

Versions of packages gkrellweather depends on:
ii  gkrellm   2.3.10-1
ii  libc6 2.27-3
ii  libglib2.0-0  2.56.0-6
ii  libgtk2.0-0   2.24.32-1
ii  libwww-perl   6.33-1
ii  perl  5.26.1-5
ii  wget  1.19.4-1

gkrellweather recommends no packages.

gkrellweather suggests no packages.

-- no debconf information

Bug#895850: duplicate contact issue

[Daniel Pocock]

Package: evolution
Version: 3.22.6-1+deb9u1
Severity: important


I was looking for a particular contact and I typed the name in the
search box.

The contact appeared twice in the search results.

I'm running a standard Debian stretch installation.  The address book
comes from a DAViCal server on Debian stretch.

I looked in the PostgreSQL backend for DAViCal and found the contact
only exists once.  I searched by both name and email address to make
sure.  I also searched on other applications linked to the same DAViCal
(e.g. CardBook for Thunderbird) and they only find the contact once.

I looked at Evolution on another system (laptop) using the same DAViCal
account and it also had the same contact twice.

Looking in the cache file:
~/.cache/evolution/addressbook/foo/cache.xml

there are two entries.

In the GUI, I right clicked each of them and exported them to vcf files.

Here are some differences I observed:

First file Second file


FN = full name FN is the first name only
N = full name  N = full name
UID not in SQL UID matches the value in SQL
latest data: nolatest data: yes,
  includes an extra email address

REV:2015   REV:20180330...
  (when I added extra email addr)


I right clicked the address book and clicked "Refresh", the duplicate
was still there.

I looked at the Evolution preferences window to see if there was a way
to clear the cache, I couldn't find it.

I closed the GUI, killed all the evolution-addressobk* processes,
deleted the cache.xml file and started the GUI again.  The duplicate
contact (left column above) was not there any more.

Why does the cache not realize that one of the contacts doesn't exist on
the server?

I also notice other people have complained about duplicates appearing in
the calendar:

https://ask.fedoraproject.org/en/question/53400/duplicate-calendar-entries-in-evolution/

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

[Stefan Fritsch]

On Monday, 16 April 2018 20:34:00 CEST Matthew Gabeler-Lee wrote:
> On Sat, 14 Apr 2018, Stefan Fritsch wrote:
> > This seems to be a systemd bug. Changing PrivateTmp from true to false in
> > apache2.service fixes the issue. But even with PrivateTmp it works for
> > some time. It would be interesting what is the trigger to make it fail
> > later on.
> 
> Hmm ... I was having a problem on some systems where tmpreaper, in its
> default configuration, will eventually delete all the directories
> systemd creates to support PrivateTmp, which might explain this...

That seems a likely explanation. I have tmpreaper installed, too. The default 
keep time is 7 days, which explains why the issue does not appear immediately.

So tmpreaper should exclude systemd-private-* files by default. Moritz, do you 
also have some cron job cleaning up stale files in /tmp ?

Bug#895849: sphinxcontrib-autoprogram: Incompatible with Sphinx 1.7

[Bas Couwenberg]

Source: sphinxcontrib-autoprogram
Version: 0.1.2-1
Severity: important
Tags: upstream fixed-upstream
Forwarded: https://github.com/sphinx-contrib/autoprogram/pull/2

Dear Maintainer,

The package is currently not compatible with Sphinx 1.7:

 sphinx-build -b html -d _build/doctrees   . _build/html
 Running Sphinx v1.7.2

 Extension error:
 Could not import extension sphinxcontrib.autoprogram (exception: cannot import 
name 'Directive')

This is fixed upstream with:

 https://github.com/sphinx-contrib/autoprogram/pull/2/files

Please include these changes to fix the compatibility with Sphinx 1.7.

Kind Regards,

Bas

Bug#893268: Intend to take over libjbzip2-java and libnanoxml2-java into Debian Med team

[Andreas Tille]

Hi,

On Sun, Mar 25, 2018 at 11:59:14PM +0200, Emmanuel Bourg wrote:
> > I'm fine with moving libjbzip2-java (which I uploaded today) once
> > pkg-java has moved to Salsa (or did I missed the move?)
> 
> I'm working on the migration, I haven't finalized the notification hooks
> yet.

Besides the general migration libnanoxml2-java is currently in Debian
Med group on Salsa[1].  I would have moved a for to java-team but as
a "Developer" I have no permission to create repositories.  Feel free
to take over this (and ping me to remove it from Debian Med.)

The issue that the package does not build remains even with different
error:

...
cd Test/Lite && \
/usr/lib/jvm/default-java/bin/javac -source 1.8 -nowarn -cp 
.:../../nanoxml-lite.jar `find -iname *.java` && \
for TESTFILE in *.xml; do \
/usr/lib/jvm/default-java/bin/java -cp .:../../nanoxml-lite.jar 
DumpXML_Lite ${TESTFILE} > ${TESTFILE}.test_out ; \
if diff -u ${TESTFILE}.out ${TESTFILE}.test_out ; \
thenecho nanoxml-lite.jar failed ${TESTFILE}; \
exit 1; \
fi; \
done
Note: ./DumpXML_Lite.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
nanoxml-lite.jar failed comments.xml
...


Kind regards

  Andreas.


[1]  https://salsa.debian.org/med-team/libnanoxml2-java

-- 
http://fam-tille.de

Bug#895811: inotify-tools: do not enable sanitizers in production

[KAction]

[2018-04-16 11:25] James Cowgill 
> part 1.1.1 text/plain1507
> Source: inotify-tools
> Version: 3.14-4
> Severity: grave
> 
> Hi,
> 
> In inotify-tools 3.14-4, all the qa sanitizers were enabled in
> DEB_BUILD_MAINT_OPTIONS. This should not be done in production.
> 
> * The man page for dpkg-buildflags explicitly states these options
> should not be used in production builds and are for debugging only.
> [...]

My fault, definitely. Somehow I missed that warning in manpage.  Will
fix.

Bug#895812: Fwd: RFS: json-editor.js/0.7.28+ds-1 [ITP]

[Paolo Greppi]

Ho Joel, thanks for your contribution !

Looking at your work there are a couple of things that can be improved:

1. I see that you set the Maintainer = Debian Javascript Maintainers.
   In that team normally we use git repos to keep track of the packaging; more 
precisely we use the git-buildpackage workflow.

2. All new repos nowadays are on salsa (https://salsa.debian.org), you can 
easily set up a guest account there with the self service webfrontend.

3. If you wish to maintain this package within this team, I'd suggest that you 
join the team !
   Just drop a mail to the mailing list committing to follow the team policies, 
and indicate your salsa alias.
   One of the js-team group owners can then add you to the group on salsa.

4. The Debian Javascript Maintainers keeps all repos in the js-team group on 
salsa (https://salsa.debian.org/js-team);
   after moving your repo there you can update the Vcs-Browser and Vcs-Git 
fields in debian/control.

5. I tried to build your package, at the end lintian complains about:
   - co-maintained-package-with-no-vcs-fields (see previous point)
   - out-of-date-standards-version 4.1.1 (current is 4.1.4)
   - insecure-copyright-format-uri 
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
   - package-uses-old-debhelper-compat-version 10 (current is 11)
   - json-editor.js source: source-contains-prebuilt-javascript-object 
dist/jsoneditor.min.js see last point

6. This library comes with examples, so you could install those too.
   You can patch the examples so that they load the jsoneditor.js file from the 
default location /javascript/... 
   which should point to /usr/share/javascript/... assuming apache2 alias from 
the javascript-common package is enabled ...

7. You are repackaging to exclude certain examples because they "link to 
libraries in external CDNs";
   Sctually it should be possible to patch them to use the system installed 
libraries (I checked examples/select2.html, we do have jquery and libselect2)
   see: 
https://salsa.debian.org/js-team/vue.js/blob/master/debian/patches/00-examples.diff
   (those additional libraries needed to enjoy the examples could be 
recommended by the package...)

8. It would be super cool if we could enable tests ... but I am not sure how 
(selenium ?)
   Tests can be run during package build and in the debian CI infrastructure 
which helps improve the quality of debian and to avoid mishaps when 
dependencies are updated;

9. You must repackage for sure: to exclude dist.
   Else the package will certainly be rejected by the ftp-masters: the dist 
directory should be re-created from source during the debian build.
   Unfortunately debhelper does not yet support building with grunt out of the 
box (https://bugs.debian.org/845043) so you have to manually add that to 
debian/rules, see:
   https://codesearch.debian.net/search?q=grunt+build+path%3Adebian%2Frules
   https://wiki.debian.org/Javascript/Nodejs#Using_build_tools_like_grunt

Paolo

Bug#895848: RFS: inotify-tools/3.14-5

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "inotify-tools"

* Package name : inotify-tools
  Version  : 3.14-5
  Upstream Author  : Radu Voicilas 
* Url  : https://github.com/rvoicilas/inotify-tools/wiki/
* Licenses : LGPL-2.1+,GPL-2.1+
  Programming Lang : C
  Section  : misc

 Inotify is a Linux kernel feature enabling user space programs to
 monitor parts of the filesystem in a efficient way. libinotifytools
 is a thin layer on top of the kernel interface which makes it easy
 to set up watches on many files at once, read events without having
 to deal with low-level I/O, and several utility functions for inotify-
 related string formatting

It builds those binary packages:

  * libinotifytools0
  * libinotifytools0-dev
  * inotify-tools

This package succesfully builds on debomatic machine:

  http://debomatic-i386.debian.net/distribution#unstable/inotify-tools/3.14-5
To access further information about this package, visit the following URL:

https://mentors.debian.net/package/inotify-tools

Alternatively, one can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/i/inotify-tools/inotify-tools_3.14-5.dsc

Alternatively, you can access package debian/ directory via git from URL:
https://salsa.debian.org/iu-guest/inotify-tools.git

More information about inotify-tools can be obtained from
https://github.com/rvoicilas/inotify-tools/wiki/


Changes since last upload:

  * Disable sanitize build flags (Closes: #895811)

Regards,
  Dmitry Bogatov

Bug#787662: tracker.debian.org: please always show bug statistics (even when the bug count is zero!)

[Francesco Poli]

On Mon, 16 Apr 2018 10:38:28 +0200 Raphael Hertzog wrote:

> Hello,
> 
> On Wed, 03 Jun 2015, Francesco Poli (wintermute) wrote:
> > Please enable the bug statistics box even for packages with zero bugs.
> 
> Done in commit a7c5cecd629dbccb8bd47621e8492ff16405aa34 by Arthur Del
> Esposte .

Thanks to both of you!

> 
> Cheers,

Bye.


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


pgpY_3_00OMjj.pgp
Description: PGP signature

Bug#895844: openssl: CVE-2018-0737: Cache timing vulnerability in RSA Key Generation Source

[Salvatore Bonaccorso]

Hi Sebastian,

Impressive repsonse time :)

On Mon, Apr 16, 2018 at 09:07:59PM +0200, Sebastian Andrzej Siewior wrote:
> On 2018-04-16 20:51:26 [+0200], Salvatore Bonaccorso wrote:
> > Severity: important
> …
> > CVE-2018-0737[0]:
> > | The OpenSSL RSA Key generation algorithm has been shown to be
> > | vulnerable to a cache timing side channel attack. An attacker with
> > | sufficient access to mount cache timing attacks during the RSA key
> > | generation process could recover the private key. Fixed in OpenSSL
> > | 1.1.0i-dev (Affected 1.1.0-1.1.0h). Fixed in OpenSSL 1.0.2p-dev
> > | (Affected 1.0.2b-1.0.2o).
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> do you want me to go ahead and prepare an upload? Upstream said that
> they won't prepare a new release because it is classified with severity
> low (yet it is filled here as important).

I do not think they warrant a DSA, I have actually marked those
already as no-dsa/postponed, and a fix can be included in the next
update needed.

Regards,
Salvatore

Bug#712841: A bit late, but still an issue...

[Axel Sommerfeldt]

On Mon, Apr 16, 2018, at 20:12, Martin Michlmayr wrote:

> Axel, can you restore the original config and 1) see if you get the beeps
> and 2) whether running
> 
> qcontrol fanspeed stop
> 
> makes them stop. (change setfan in the config to do nothing, otherwise
> the fan will be turned on again)

1) Done
2) "qcontrol fanspeed stop" makes the beeping stop

> Do you know if /etc/default is Debian-specific or generic?

It's not part of the Filesystem Hierarchy Standard (3.0) but at least I can 
confirm that this directory exists in CentOS and Fedora, too, containing the 
files "grub" and "useradd".

> As a workaround, until this is fixed, users can create a file
> /etc/qcontrol.d/90_no_fan with:
> 
> function fan_error(  )
> end
> 
> function setfan( temp, speed )
> end
> 
> I believe this should work but is completely untested. (Alex,
> Christian, maybe you can test after restoring the original config.)

Creating /etc/qcontrol.d/90-no-fan.conf with the content above makes the 
beeping stop, too.

Log:
Apr 16 21:08:59 qnap-backup qcontrol[330]: confdir: loading from 
/etc/qcontrol.d...
Apr 16 21:08:59 qnap-backup qcontrol[330]: confdir: including 
/etc/qcontrol.d/90-no-fan.conf

Maybe it's a good idea to overwrite the temp() function in 
/etc/qcontrol.d/90-no-fan.conf, too? It could create a log entry if the 
temperature gets hot and make a beep (and a red blinking status led) if it gets 
too hot!?

Bug#875547: animals: can't be played as non root user

[alberto fuentes]

On Mon, Apr 16, 2018 at 7:34 PM, Markus Koschany  wrote:

> Control: tags -1 pending
>
> Dear maintainer,
>
> I've uploaded a new revision of animals versioned as 201207131226-2.1
> that addresses the issue. Please find attached the debdiff.
>

Thanks for uploading a fix!

Bug#895475: openshot-qt: non-DFSG assets in package

[Dr. Tobias Quathamer]

Am 11.04.2018 um 23:48 schrieb Alex Krusemark:
> Dear Maintainer,
> 
> I found that this package includes a bundled font "Ubuntu Regular",
> which was determined to be non-DFSG
> (https://bugs.launchpad.net/ubuntu-font-licence/+bug/769874). It
> installs to the path
> "/usr/lib/python3/dist-packages/openshot_qt/images/fonts/Ubuntu-R.ttf".
> I know that in some other packages with this issue, the font has been
> replaced with a DFSG font such as Cantarell or DejaVu Sans.

Hi Alex,

very good catch, thanks a lot! I'll prepare a fixed version soon.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#712841: A bit late, but still an issue...

[Martin Michlmayr]

* Ian Campbell  [2018-04-15 15:33]:
> > Ian, do you think it's worth asking the release team if they'd allow
> > an update for this in stable?
> 
> I think it is premature to consider that question without a specific
> fix in unstable to be backported in order to make the argument/decision
> based on it.

Yes, absolutely.  Of course we have to fix it in unstable first.

> > Getting the right device from /etc/mtdblock5 is easy, but I've no 
> > idea how to change the config based on that.
> 
> I think you mean /dev/mtdblock5? While mounting that to extract the

/dev/, yes.  But I agree with your concerns.

Anyway, after reading the bug log again and looking at the files,
here's what I think:

Devices affected:

* TS-109
* TS-109 II
* TS-119
* HS-210

The first two are ts-209 devices from the POV of qcontrol and the latter
two ts-219.

We have two problems:

1) fan_error() produces a beep.  Previous discussion suggests that turning
the fan off will make the fan_error() calls go away on devices without a
fan (at least on the TS-109).

Axel, can you restore the original config and 1) see if you get the beeps
and 2) whether running

qcontrol fanspeed stop

makes them stop. (change setfan in the config to do nothing, otherwise
the fan will be turned on again)

2) We have temp_low()/temp_high() on ts-209 and temp() on ts-219 which
regulates the temperature by calling setfan().

So imho the easiest fix would be a) for the init script to run `qcontrol
fanspeed stop` if HAS_FAN=no and for setfan() to be modified to do nothing
if HAS_FAN=no.

It would be up to users to add HAS_FAN=no to /dev/default/qcontrol

Ian, does that sound reasonable?

Do you know if /etc/default is Debian-specific or generic?  I'm just
wondering if the qcontrol configs should read from /etc/default/qcontrol
(Google suggests Red Hat and SUSE have it too, so I guess that should
be ok.)

As a workaround, until this is fixed, users can create a file
/etc/qcontrol.d/90_no_fan with:

function fan_error(  )
end

function setfan( temp, speed )
end

I believe this should work but is completely untested. (Alex,
Christian, maybe you can test after restoring the original config.)

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#564935: gmod: should this package be removed?

[Riku Voipio]

reassign 564935 ftp.debian.org
retitle 564935 gmod -- RoM; ancient; abandoned upstream;
thanks

On Mon, Apr 16, 2018 at 07:19:36PM +0200, Moritz Muehlenhoff wrote:
> On Tue, Jan 12, 2010 at 09:08:39PM +, Simon McVittie wrote:
> > Source: gmod
> > Severity: wishlist
> > User: debian...@lists.debian.org
> > Usertags: proposed-removal
> > 
> > gmod seems like a candidate for removal from Debian:
> > 
> > * RFA for a long time
> > * very low popcon (2 votes)
> > * alternatives that don't require specialized hardware exist (mikmod)
> > * nothing in Debian depends on it
> > 
> > If you want to keep this package around in Debian, please just close this 
> > bug.
> 
> Eight years without anyone voicing a concern seems like an acceptable grace 
> period
> to finally remove this? :-)

At this point the package is just dead weight. Please remove from Debian!

Riku

Bug#895847: RFS: pqiv/2.10.3-0.1 [NMU] -- Powerful image viewer with minimal UI

[Phillip Berndt]

Package: sponsorship-requests
Severity: normal


Dear mentors,

I am looking for a sponsor for my new revision of the pqiv package. I am the
upstream author.

* Package name: pqiv
  Version : 2.10.3-0.1
  Upstream Author : Phillip Berndt 
* URL : https://github.com/phillipberndt/pqiv
* License : GPL3
  Section : optional

The latest version in the Debian archives is 2.6, a bug report [1] with a
request to update to the intermediate versions has been open for 14 months now,
I have not been able to reach the maintainer since. QA request regarding that is
pending. I thought that a NMU might be my best chance of getting a more recent
release into the archives. I did my best to update the package to accord to the
latest packaging standards while at it.



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

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


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

dget -x https://mentors.debian.net/debian/pool/main/p/pqiv/pqiv_2.10.3-0.1.dsc



Regards,
Phillip Berndt

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

Bug#895844: openssl: CVE-2018-0737: Cache timing vulnerability in RSA Key Generation Source

[Sebastian Andrzej Siewior]

On 2018-04-16 20:51:26 [+0200], Salvatore Bonaccorso wrote:
> Severity: important
…
> CVE-2018-0737[0]:
> | The OpenSSL RSA Key generation algorithm has been shown to be
> | vulnerable to a cache timing side channel attack. An attacker with
> | sufficient access to mount cache timing attacks during the RSA key
> | generation process could recover the private key. Fixed in OpenSSL
> | 1.1.0i-dev (Affected 1.1.0-1.1.0h). Fixed in OpenSSL 1.0.2p-dev
> | (Affected 1.0.2b-1.0.2o).
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

do you want me to go ahead and prepare an upload? Upstream said that
they won't prepare a new release because it is classified with severity
low (yet it is filled here as important).
 
> Regards,
> Salvatore

Sebastian

Bug#895846: stretch-pu: package animals/201207131226-2+b1

[Markus Koschany]

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

Dear release team,

I would like to update the animals package in Stretch. At the moment
it is completely unusable due to insufficient file permissions. The
fix is trivial though. Please find attached the debdiff. Jessie is not
affected.

Regards,

Markus
diff -Nru animals-201207131226/debian/changelog 
animals-201207131226/debian/changelog
--- animals-201207131226/debian/changelog   2016-09-11 20:20:18.0 
+0200
+++ animals-201207131226/debian/changelog   2018-04-16 19:21:27.0 
+0200
@@ -1,3 +1,12 @@
+animals (201207131226-2.1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix typo overwrite -> override in debian/rules that prevented the use of
+correct file permissions and thus made the game unusable.
+Thanks to Aaron Howell for the report. (Closes: #875547)
+
+ -- Markus Koschany   Mon, 16 Apr 2018 19:21:27 +0200
+
 animals (201207131226-2) unstable; urgency=medium
 
   * Switch to dh
diff -Nru animals-201207131226/debian/rules animals-201207131226/debian/rules
--- animals-201207131226/debian/rules   2016-09-11 20:20:18.0 +0200
+++ animals-201207131226/debian/rules   2018-04-16 19:21:27.0 +0200
@@ -8,7 +8,7 @@
 override_dh_strip:
dh_strip --dbgsym-migration='animals-dbg (<<201207131226-1)'
 
-overwrite_dh_fixperms:
+override_dh_fixperms:
dh_fixperms
chown games:games $(CURDIR)/debian/animals/var/games/animals
chmod 06775 $(CURDIR)/debian/animals/var/games/animals

Bug#895452: some progress bootstrap completes for gcc 7.3.0

[Dennis Clarke]

Managed a bootstrap that didn't blow up.

At the moment the assembly output from a trivial test shows that the IBM
extended precision long double type is the default unless one actually
asks for the IEEE754-2008 128-bit datatype.

dclarke@nix:~/pgm/C/ieee754$ 
PATH=/usr/local/build/gcc-7.3.0_linux_4.15.0-2-powerpc64_ppc64.005/gcc:$PATH 
xgcc 
-I/usr/local/build/gcc-7.3.0_linux_4.15.0-2-powerpc64_ppc64.005/gcc/include 
-m64 -g -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec -mfull-toc 
-mregnames -mabi=ieeelongdouble -S -o ld.s ld.c

xgcc: warning: using IEEE extended precision long double
cc1: warning: using IEEE extended precision long double
dclarke@nix:~/pgm/C/ieee754$ grep "quad" ld.s | grep "0x"
.quad   0x4000921fb54442d1,0x8469898cc51701b8

That data is correct.

dclarke@nix:~/pgm/C/ieee754$ 
PATH=/usr/local/build/gcc-7.3.0_linux_4.15.0-2-powerpc64_ppc64.005/gcc:$PATH 
xgcc 
-I/usr/local/build/gcc-7.3.0_linux_4.15.0-2-powerpc64_ppc64.005/gcc/include 
-m64 -g -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec -mfull-toc 
-mregnames -mabi=ibmlongdouble -S -o ld.s ld.c

xgcc: warning: using IBM extended precision long double
cc1: warning: using IBM extended precision long double
dclarke@nix:~/pgm/C/ieee754$ grep "quad" ld.s | grep "0x"
.quad   0x400921fb54442d18,0x3ca1a62633145c06

That is a whole other beast of a different colour.

dclarke@nix:~/pgm/C/ieee754$ 
PATH=/usr/local/build/gcc-7.3.0_linux_4.15.0-2-powerpc64_ppc64.005/gcc:$PATH 
xgcc 
-I/usr/local/build/gcc-7.3.0_linux_4.15.0-2-powerpc64_ppc64.005/gcc/include 
-m64 -g -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec -mfull-toc 
-mregnames -S -o ld.s ld.c

dclarke@nix:~/pgm/C/ieee754$ grep "quad" ld.s | grep "0x"
.quad   0x400921fb54442d18,0x3ca1a62633145c06
dclarke@nix:~/pgm/C/ieee754$

So the default is the IBM type. No idea on the libquadmath yet.

I should have more info on this issue in another 16 or 20 hours.

Dennis

Bug#895844: openssl: CVE-2018-0737: Cache timing vulnerability in RSA Key Generation Source

[Salvatore Bonaccorso]

Source: openssl
Version: 1.1.0f-3
Severity: important
Tags: patch security upstream
Control: clone -1 -2
Control: reassign -2 openssl1.0 1.0.2l-2
Control: retitle -2 openssl1.0: CVE-2018-0737: Cache timing vulnerability in 
RSA Key Generation Source

Hi,

The following vulnerability was published for openssl.

CVE-2018-0737[0]:
| The OpenSSL RSA Key generation algorithm has been shown to be
| vulnerable to a cache timing side channel attack. An attacker with
| sufficient access to mount cache timing attacks during the RSA key
| generation process could recover the private key. Fixed in OpenSSL
| 1.1.0i-dev (Affected 1.1.0-1.1.0h). Fixed in OpenSSL 1.0.2p-dev
| (Affected 1.0.2b-1.0.2o).

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-0737
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0737
[1] https://www.openssl.org/news/secadv/20180416.txt

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

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

[Matthew Gabeler-Lee]

On Sat, 14 Apr 2018, Stefan Fritsch wrote:


This seems to be a systemd bug. Changing PrivateTmp from true to false in
apache2.service fixes the issue. But even with PrivateTmp it works for
some time. It would be interesting what is the trigger to make it fail
later on.


Hmm ... I was having a problem on some systems where tmpreaper, in its 
default configuration, will eventually delete all the directories 
systemd creates to support PrivateTmp, which might explain this...


--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

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

[Moritz Mühlenhoff]

On Mon, Apr 16, 2018 at 02:34:00PM -0400, Matthew Gabeler-Lee wrote:
> On Sat, 14 Apr 2018, Stefan Fritsch wrote:
> 
> > This seems to be a systemd bug. Changing PrivateTmp from true to false in
> > apache2.service fixes the issue. But even with PrivateTmp it works for
> > some time. It would be interesting what is the trigger to make it fail
> > later on.
> 
> Hmm ... I was having a problem on some systems where tmpreaper, in its
> default configuration, will eventually delete all the directories systemd
> creates to support PrivateTmp, which might explain this...

Just for the record, we've also tracked it down to the use of PrivateTmp
(but I hadn't followed up on this bug since we haven't analysed this to full
extent). The workaround deployed is here:
https://github.com/wikimedia/puppet/commit/388d0141ef3b78471eb81b59e1ccb196adf49872

It's specific to our configuration for Mediawiki application servers, but
those are fairly complex to begin with (e.g. there's various Mediawiki 
extensions
which shell out to external binaries (e.g. to convert musical typesheets edited 
in
Wikimedia projects)).

I wouldn't call this a bug in systemd, it's probably something local in the 
setup
of the various components using /tmp (and we don't have this problem on
our non-mediawiki stretch Apache setups). Using PrivateTmp in apache.service
by default seems totally sensible to me.

As such, I'd recommend to simply close this bug. Anyone searching for that
error message via a search engine will hopefully find it as a useful
reference.

Cheers,
Moritz

Bug#712841: A bit late, but still an issue...

[Ian Campbell]

On Mon, 2018-04-16 at 20:12 +0200, Martin Michlmayr wrote:
> Do you know if /etc/default is Debian-specific or generic?  I'm just
> wondering if the qcontrol configs should read from /etc/default/qcontrol
> (Google suggests Red Hat and SUSE have it too, so I guess that should
> be ok.)

They have a different name/path for it IIRC.

I don't think it's necessary to indirect via /etc/default anyway. Just
write the variable directly into the appropriate /etc/qcontrol/foo.conf
files and have necessary conditionals in there. I believe you can also
call the fan stop function from the config file, perhaps from the
system init module callback or just do it at the top level.

Ian.

Bug#895824: autopkgtest: autopkgtest failure on some architectures

[Paul Gevers]

Control: tags -1 patch

os.listdir turns out to return in undefined order. So that needs
sorting. I created a patch, could you please try it out? I verified it
on amd64.

Paul

diff --git a/tests/autopkgtest b/tests/autopkgtest
index ca6967a7..e37e504e 100755
--- a/tests/autopkgtest
+++ b/tests/autopkgtest
@@ -1956,8 +1956,8 @@ deb [trusted=yes arch=6510] http://foo.ubuntu.com/ fluffy-proposed main 6510
 ''')
 
 # should set up apt pinning
-self.assertEqual(os.listdir(os.path.join(apt_dir, 'preferences.d')),
- ['autopkgtest-fluffy-proposed', 'autopkgtest-default-release'])
+self.assertEqual(sorted(os.listdir(os.path.join(apt_dir, 'preferences.d'))),
+ ['autopkgtest-default-release', 'autopkgtest-fluffy-proposed'])
 with open(os.path.join(apt_dir, 'preferences.d', 'autopkgtest-fluffy-proposed')) as f:
 self.assertEqual(f.read(), '''Package: foo bar
 Pin: release a=fluffy-proposed
@@ -2058,8 +2058,8 @@ deb http://foo.ubuntu.com/ fluffy main non-free
 self.assertRegex(out, 'pass\s+PASS', out)
 
 # should set up apt pinning
-self.assertEqual(os.listdir(os.path.join(apt_dir, 'preferences.d')),
- ['autopkgtest-fluffy-proposed', 'autopkgtest-default-release'])
+self.assertEqual(sorted(os.listdir(os.path.join(apt_dir, 'preferences.d'))),
+ ['autopkgtest-default-release', 'autopkgtest-fluffy-proposed'])
 with open(os.path.join(apt_dir, 'preferences.d', 'autopkgtest-fluffy-proposed')) as f:
 self.assertEqual(f.read(), '''Package: foo bar
 Pin: release a=fluffy-proposed


signature.asc
Description: OpenPGP digital signature

Bug#895843: O: geshi

[Moritz Muehlenhoff]

Package: wnpp
Severity: normal

Geshi was originally maintained under the Mediawiki umbrella, but current 
releases
of Mediawiki no longer use geshi for syntax highlighting (instead Pygments is 
used).

Bug#895842: RM: axe -- RoQA; unmaintained, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove axe from the archive. It's orphaned without an adopter since 2010,
is non-free (and we have plenty of free editor alternatives...), dead upstream
and has code quality problems (quoting the former maintainer: "The codebase is
old and buggy: some features are no longer working, and difficult to fix
due to the fact that parts of it was copy-n-pasted from very old X11R5
and X11R4 code and then hacked.")

Cheers,
Moritz

Bug#712841: A bit late, but still an issue...

[Martin Michlmayr]

* Martin Michlmayr  [2018-04-16 20:12]:
> As a workaround, until this is fixed, users can create a file
> /etc/qcontrol.d/90_no_fan with:

It needs a .conf extension, so e.g. /etc/qcontrol.d/90-no-fan.conf

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#895841: lintian -- False positive on spelling-error-in-binary

[Thorsten Alteholz]

Package: lintian
Version: 2.5.80
Severity: normal

For osmo-trx 0.2.0 I get:
  I: osmo-trx: spelling-error-in-binary usr/bin/osmo-trx wIH with

But there is no wIH in the source:

 debian@devel:~/move-to-salsa/mobcom/osmo-trx/osmo-trx-0.2.0$ grep -R wIH
 debian@devel:~/move-to-salsa/mobcom/osmo-trx/osmo-trx-0.2.0$

and:

 debian@devel:~/move-to-salsa/mobcom/osmo-trx/builder1$ LANG=C grep -R wIH
 Binary file tmp/usr/bin/osmo-trx matches
 debian@devel:~/move-to-salsa/mobcom/osmo-trx/builder1$ strings 
tmp/usr/bin/osmo-trx|grep wIH
 wIH)

only garbage in the binary. So this seems to be a false positive.

 Thorsten

Bug#895840: sox: nroff typo in man page, switches from Times Roman to Courier

[Ben Wong]

Package: sox
Version: 14.4.1-5+b2
Severity: minor

Dear Maintainer,

There is a bug in the man page of sox that causes the font to switch
midway to Courier instead of Times Roman. You can see this problem by
viewing the man page as a PDF:

cd /usr/share/man/man1
zcat sox.1.gz | tbl -Tpdf | eqn -Tpdf | groff -Tpdf -man > ~/sox.pdf
mimeopen ~/sox.pdf

The problem starts at the end of page 6. The fix is simple. Simply
close the .EX tag using .EE.  

Here is the patch:

--- sox.1.orig  2014-12-24 11:33:55.0 -0800
+++ sox.1   2018-04-15 16:28:29.591641564 -0700
@@ -602,6 +602,7 @@
 file into two 30 second files and ignoring the rest.
 .EX
sox song.wav ringtone%1n.wav trim 0 30 : newfile : trim 0 30
+.EE
 .SS Stopping SoX
 Usually SoX will complete its processing and exit automatically once
 it has read all available audio data from the input files.



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

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

Versions of packages sox depends on:
ii  libc6 2.24-11+deb9u3
ii  libgomp1  6.3.0-18+deb9u1
ii  libsox-fmt-alsa   14.4.1-5+b2
ii  libsox-fmt-ao 14.4.1-5+b2
ii  libsox-fmt-base   14.4.1-5+b2
ii  libsox-fmt-oss14.4.1-5+b2
ii  libsox-fmt-pulse  14.4.1-5+b2
ii  libsox2   14.4.1-5+b2

sox recommends no packages.

Versions of packages sox suggests:
ii  libsox-fmt-all  14.4.1-5+b2

-- no debconf information

Bug#895199: /usr/games/antigrav: crash in start with segfault

[Markus Koschany]

Hi,

Am 16.04.2018 um 19:40 schrieb Ilari Halminen:
> If the games are unsupported now, then it is OK for me just forgetting
> the bug.
> 
> Just wondering if it was working before? Latest changes according
> changelog.Debian.gz
>  are made in unstable. And there is no other changelog.
> 
> By the way, did you really tested in computer similar mine, not in a new
> and shiny one?

Please keep the bug report in CC. I only know that the latest version
works and I didn't bother to investigate this issue on Jessie because
games will be unsupported there very soon. Though if you can reproduce
the segfault in Stretch or Sid we can take a closer look.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#895839: src:zotero-standalone-build: New version available

[Andreas Tille]

Package: src:zotero-standalone-build
Severity: wishlist

Hi,

upstream is at release 5.0.44.  It would be nice if this could be
packaged for Debian.

Please also notice that the development platform Alioth is shut down in
about two weeks.  I have migrated several packages to Salsa and since I
have some interest in zotero I would volunteer to move the packaging.  I
could also try to do the version upgrade as well as bumping
Standards-Version and some general packaging upgrades.

Please let me know if you want me to do this.

Kind regards

   Andreas.


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

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

Bug#895821: 873185 made which time service starts unreliable

[Michael Biebl]

Am 16.04.2018 um 19:17 schrieb Michael Biebl:
> Maybe the best we can do is to document in README.Debian, that users of
> an alternative NTP client, have to disable systemd-timesyncd manually.
> The Condition is only a hack and I'd rather not add it back. It's not a
> proper solution either, as it only checks for the existince of the
> binaries, not if the alternative NTP services are actually running.

The only other alternative I can think of, is splitting
systemd-timesyncd into a separate package, which has
Conflicts/Replaces/Provides: time-daemon

But that will open another can of worms.

First of all, I'm not too thrilled having a separate binary package for
a 44K binary.

Second, we want to have systemd-timesyncd installed and enabled by
default. A Recommends will not cut, as systemd is installed during early
debootstrap, where Recommends are not considered. There might also be
the risk, that by adding a Recommends, we trigger the uninstallation of
any already installed alternative, like ntp, which would most likely
not make people happy.
If we don't add a Recommends though, people without having installed
another alternative would suddenly not have systemd-timesyncd anymore,
so we'd create a regression as well.

So, I'm not sure if any changes to the status quo actually improve the
current situation, but I'm open to other ideas.

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#875547: animals: can't be played as non root user

[Markus Koschany]

Control: tags -1 pending

Dear maintainer,

I've uploaded a new revision of animals versioned as 201207131226-2.1
that addresses the issue. Please find attached the debdiff.

Regards,

Markus
diff -Nru animals-201207131226/debian/changelog 
animals-201207131226/debian/changelog
--- animals-201207131226/debian/changelog   2016-09-11 20:20:18.0 
+0200
+++ animals-201207131226/debian/changelog   2018-04-16 19:21:27.0 
+0200
@@ -1,3 +1,12 @@
+animals (201207131226-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix typo overwrite -> override in debian/rules that prevented the use of
+correct file permissions and thus made the game unusable.
+Thanks to Aaron Howell for the report. (Closes: #875547)
+
+ -- Markus Koschany   Mon, 16 Apr 2018 19:21:27 +0200
+
 animals (201207131226-2) unstable; urgency=medium
 
   * Switch to dh
diff -Nru animals-201207131226/debian/rules animals-201207131226/debian/rules
--- animals-201207131226/debian/rules   2016-09-11 20:20:18.0 +0200
+++ animals-201207131226/debian/rules   2018-04-16 19:21:27.0 +0200
@@ -8,7 +8,7 @@
 override_dh_strip:
dh_strip --dbgsym-migration='animals-dbg (<<201207131226-1)'
 
-overwrite_dh_fixperms:
+override_dh_fixperms:
dh_fixperms
chown games:games $(CURDIR)/debian/animals/var/games/animals
chmod 06775 $(CURDIR)/debian/animals/var/games/animals


signature.asc
Description: OpenPGP digital signature

Bug#895809: enlightenment: Fails to start

[Manolo Díaz]

On Monday, 16 Apr 2018 at 17:18 UTC
Andreas Metzler wrote:

> On 2018-04-16 Manolo Díaz  wrote:
> > Ross Vandegrift wrote:  
> [...]
> > > startx enlightenment_start  
>  
> > > FWIW, you might have a nicer experience with a display manager.
> > > Enlightenment will appear as a session option in gdm/kdm/lightdm/etc.  
>  
> > > Ross  
> 
> > For some reason 'startx enlightenment_start' doesn't work for me, but
> > creating a ~/.xinitrc file with 'enlightenment_start' as a sole line
> > does.  
> 
> Iirc startx only interprets an argument as to-be-run-command if there
> is a "/" in it
> startx `which enlightenment_start`
> 
> cu Andreas

True. It does work for me.

Thank you.
-- 
Manolo Díaz

Bug#895778: jruby: Several security vulnerabilities

[Miguel Landaeta]

On Sun, Apr 15, 2018 at 10:48:10PM +0200, Markus Koschany wrote:
> I intend to work on the patches for Jessie and Stretch. Unstable could
> be a bit more complicated due to the FTBFS with OpenJDK 9.

Hi Markus,

Thanks for taking care of jessie and stretch.

I expect to be able to update jruby in unstable soon, although there
is some pending work to do, as I mentioned in #895837.

These days I'm more involved with that project as upstream, so I haven't
find enough time to work on this package yet.

Cheers,
Miguel.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: PGP signature

Bug#895838: src:xlsx2csv: New version available

[Andreas Tille]

Package: src:xlsx2csv
Severity: wishlist

Hi,

the watch file says

  # Can't use; not using tags. See debian/copyright for VCS access.

but meanwhile upstream has set release tags[1] which contains more
up to date code than the current Debian package (despite the Debian
package is at "version" 0.20 while upstream has 0.7.3.

Moreover the package is currently maintained on Alioth which will be
shut down in about two weeks.  I have migrated several packages to Salsa
so I can offer migrating xlsx2csv to Salsa and when doing so upgrade to
the latest upstream version.

Please let me know if you want me to do the migration.

Kind regards and thanks for maintaining xlsx2csv

  Andreas.


[1] https://github.com/dilshod/xlsx2csv/releases

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

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

Bug#799358: Please package new upstream

[Kevin Williams]

Angband upstream is now version 4.1.2.  In addition, the current version
can be moved to main because it is now dual-licensed under both GPLv2 and
the old Moria license.

Bug#895837: jruby: Please package 9.1.16.0 or more recent releases

[Miguel Landaeta]

Package: src:jruby
Version: 9.1.13-1
Severity: wishlist

Recent jruby releases added support for Java 9.

So, in order to fix bugs like #893244, it's required to package recent
releases.

To do this, it's also required to introduce a package for ruby-json
Java extension (see #876910). I filed that bug because previous
ruby-json releases were bundling the Java extension in the
arch-dependent packages and that caused problems (e.g. #890046).


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

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

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: PGP signature

Bug#564935: gmod: should this package be removed?

[Moritz Muehlenhoff]

On Tue, Jan 12, 2010 at 09:08:39PM +, Simon McVittie wrote:
> Source: gmod
> Severity: wishlist
> User: debian...@lists.debian.org
> Usertags: proposed-removal
> 
> gmod seems like a candidate for removal from Debian:
> 
> * RFA for a long time
> * very low popcon (2 votes)
> * alternatives that don't require specialized hardware exist (mikmod)
> * nothing in Debian depends on it
> 
> If you want to keep this package around in Debian, please just close this bug.

Eight years without anyone voicing a concern seems like an acceptable grace 
period
to finally remove this? :-)

Cheers,
Moritz