Bug#907041: ITP: swupdate -- SWUpdate provides a reliable way to update the software on an embedded system

[Shyam Saini]

> Hi Shyam,

Hi Stefano,

>
> On 12/07/19 13:53, Shyam Saini wrote:
> > Hi,
> >
> > Is there any update on this?
> >
> > Any tentative date or time when It could be officially added.
> >
> > We need swupdate as official debian package for one of our customer.
> > If it would not be added in next few months then we would probably
> > like to use swupdate with yocto.
> >
>
> The package was pushed by SZ (see link) to debian and he expects it will
> be merged sonn, now that "buster" is released.

Could you please tell some more specific date or time ? Sorry

> [1] https://ftp-master.debian.org/new.html
>
> Anyway, (not yet merged) packages are available. You can use the link
> above, or SWUpdate has a -debian branch to build the package on your own.

okay, thanks for this update. This was helpful.

>
> >  please let us me know about the status so that we can make our
> > decision accordingly.
>
> Weird, decision to take debian or Yocto should not be based on
> SWUpdate's availability.

Indeed, it is. But that's what our customer demanded. We are trying to
convince them for other
option but so far we are failed to do so. But we never give up ;-)

Thanks a lot,
Shyam

Bug#931931: xastir: FTBFS with PROJ 6

[Bas Couwenberg]

Source: xastir
Version: 2.1.2-1
Severity: important
Tags: upstream patch
User: debian-...@lists.debian.org
Usertags: proj-6

Dear Maintainer,

Your package FTBFS with PROJ 6 from experimental.

The attached patch fixes the issue by defining 
ACCEPT_USE_OF_DEPRECATED_PROJ_API_H.

Note that this is only a temporary workaround, proj_api.h will be
removed in PROJ 7 scheduled for March 2020.

Upstream is aware of the issue, see:

 https://github.com/Xastir/Xastir/issues/47

Kind Regards,

Bas
diff -Nru xastir-2.1.2/debian/changelog xastir-2.1.2/debian/changelog
--- xastir-2.1.2/debian/changelog   2019-06-28 15:12:43.0 +0200
+++ xastir-2.1.2/debian/changelog   2019-07-12 15:36:00.0 +0200
@@ -1,3 +1,9 @@
+xastir (2.1.2-2) UNRELEASED; urgency=medium
+
+  * Rebuild with PROJ 6.
+
+ -- Christoph Berg   Fri, 12 Jul 2019 15:36:00 +0200
+
 xastir (2.1.2-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru xastir-2.1.2/debian/rules xastir-2.1.2/debian/rules
--- xastir-2.1.2/debian/rules   2019-06-28 15:08:11.0 +0200
+++ xastir-2.1.2/debian/rules   2019-07-12 15:35:50.0 +0200
@@ -2,6 +2,9 @@
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
+# Workaround for proj_api.h deprecation in PROJ 6.0.0
+export DEB_CFLAGS_MAINT_APPEND=-DACCEPT_USE_OF_DEPRECATED_PROJ_API_H
+
 %:
dh $@ --with autoreconf
 

Bug#931912: Please do not Depends/Recommends against gnome-icon-theme

[Hilmar Preuße]

tags 931912 + pending
stop

On 12.07.19 10:24, Laurent Bigonville wrote:

> I see that the info package Recommends gnome-icon-theme, I don't think
> it's a good idea.
> 
Fixed in git, tag pending.

https://github.com/debian-tex/texinfo/commit/f7b207eff865a40b3fd58b56155290c697e8afc2

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#931928: RFS: shotwell/0.30.4-1

[Adam Borowski]

On Fri, Jul 12, 2019 at 02:51:44PM +0200, Jörg Frings-Fürst wrote:
>Package name: shotwell
>Version : 0.30.4-1

Hi!
These two files have disappeared:
-rwxr-xr-x  root/root   
/usr/lib/x86_64-linux-gnu/shotwell/shotwell-settings-migrator
-rwxr-xr-x  root/root   
/usr/lib/x86_64-linux-gnu/shotwell/shotwell-video-thumbnailer
yet there's no hint for me whether this is intentional.

I have no clue about this package's inner workings, but neither yours nor
upstream changelogs mention this change.  As these tools are not within a
public namespace, it's possible that all is ok... but it's safer to me to
check with you.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned
⢿⡄⠘⠷⠚⠋  by a hacker".  So what's the problem?
⠈⠳⣄

Bug#931854: liblopsub: please make the output of lopsubgen reproducible

[Chris Lamb]

Herr Noll,

> > Whilst working on the Reproducible Builds effort [0], we noticed
> > that liblopsub generates output that is not reproducible.
[…]
> Good catch. I've applied your patch and made some minor edits to
> improve code readability and to fix the typo in the new comment.

Thanks again for your careful review of my haphazard and often-errant
programming style. I am perfectly OK with the quoted commit and I
look forward to it landing in Debian in short time.


Best wishes,

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

Bug#931930: firmware-misc-nonfree: Please, include i915/icl_dmc_ver1_07.bin

[Luiz Gustavo S. Real]

Package: firmware-misc-nonfree
Version: 20190114-1
Severity: wishlist

Dear Maintainer,

I am seeing this warning message:
W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_07.bin for 
module i915

Could we have it included, please?

Thank you.

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'unstable'), (600, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.0.0-trunk-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

firmware-misc-nonfree depends on no packages.

firmware-misc-nonfree recommends no packages.

Versions of packages firmware-misc-nonfree suggests:
ii  initramfs-tools  0.133

-- no debconf information

Bug#931422: Segmentation fault opening TIFF file

[Sergei Golovan]

Hi Christopher,

On Thu, Jul 4, 2019 at 5:09 PM Christopher Chavez  wrote:
>
> Using Debian 9.9 i386 (32-bit). I am not sure if this bug should instead be 
> reported against libtiff5 (4.0.8-2+deb9u4).
>
> A segmentation fault occurs when using the following 3-line script and an 
> example image obtained from 
> https://sourceforge.net/p/openil/svn/1479/tree/trunk/Test%20Images/TIF/libtiffpic/quad-jpeg.tif
>  . I am not aware of any other example images that exhibit the exact same 
> issue.

I confirm the bug. Also in 1.4.8+dfsg-1 which is currently in Debian
10. The bug is introduces by me when I forced libtk-img to use the
system-wide libtiff instead of the one bundled with the libtk-img
sources.

I'll fix it in unstable shortly, and then in stable and in oldstable
(it'll be available in the updates repository, and after a while in
the next point release).

Thank you for the bugreport!
-- 
Sergei Golovan

Bug#930062: enigmail: Engimail decrypt-passphrase window takes control of desktop

[Daniel Kahn Gillmor]

On Tue 2019-07-09 11:58:46 +0200, Emmanuel Revah wrote:
> I've followed these steps carefully, on 2 computers, both on Debian 
> Buster, 64 bit. The only thing that seems logic to me is that there 
> might be an issue with pinentry-qt itself.
>
> If I remove all pinentry-* except for qt and clean gpg-agent.conf file 
> (remove pinentry conf) I get the error "ERR 67108949 No pinentry  Agent>".
>
> Any combination of either, only having pinentry-qt installed, or the 
> config file pointing to it, will result in this error.

this sounds very frustrating, i'm sorry to hear it.

I just ran the following test that uses an empty GnuPG homedir:

GNUPGHOME=$(mktemp -d)
cat > "$GNUPGHOME/gpg-agent.conf" < I can use pinentry-qt to get a dialog window, it just does not work with 
> GPG in my case.
>
> If this isn't a bug (PEBKAC is always an option for me) or can't be 
> fixed, I will just use fltk or gtk2 and I'll be fine. If you'd like me 
> to try out more things, let me know.

Could you try out the test above?  Once you run it, if it gives you an
error, could you look at $GNUPGHOME/gpg-agent.log ?

   --dkg


signature.asc
Description: PGP signature

Bug#931929: ITP: r-cran-rdpack -- GNU R update and manipulate Rd documentation objects

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-rdpack -- GNU R update and manipulate Rd documentation 
objects
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-rdpack
  Version : 0.11
  Upstream Author : Georgi N. Boshnakov,
* URL : https://cran.r-project.org/package=Rdpack
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R update and manipulate Rd documentation objects
 Functions for manipulation of R documentation objects,
 including functions reprompt() and ereprompt() for updating 'Rd'
 documentation for functions, methods and classes; 'Rd' macros for
 citations and import of references from 'bibtex' files for use in
 'Rd' files and 'roxygen2' comments; 'Rd' macros for evaluating and
 inserting snippets of 'R' code and the results of its evaluation or
 creating graphics on the fly; and many functions for manipulation of
 references and Rd files.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-rdpack

Bug#931913: [Aptitude-devel] Bug#931913: aptitude: The certificate is NOT trusted when using https to fetch packages from security.debian.org in buster

[Axel Beckert]

Hi J.L.,

J. L. Lee wrote:
> In this case, Debian Wiki page on SourcesList
> (https://wiki.debian.org/SourcesList) needs to be rephrased slightly.

Thanks for this hint!

Done now: https://wiki.debian.org/SourcesList?action=diff=88=89

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

Bug#931928: RFS: shotwell/0.30.4-1

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

   Package name: shotwell
   Version : 0.30.4-1
   Upstream Author : Jim Nelson 
   URL : https://wiki.gnome.org/Apps/Shotwell
   License : LGPL-2.1, CC-BY-SA-3.0, GPL-2+
   Section : gnome

  It builds those binary packages:

 shotwell- digital photo organizer
 shotwell-common - digital photo organizer - common files

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/shotwell/shotwell_0.30.4-1.dsc

 or

  https://jff.email/cgit/shotwell.git/?h=release%2Fdebian%2F0.30.4-1



  Changes since the last upload:

  * New upstream release.
  * Declare compliance with Debian Policy 4.4.0 (No changes needed).
  * Add package-name-doesnt-match-sonames to lintian-overrides.
  * Refresh debian/copyright.
  * Migrate to debhelper 12:
- Change debian/compat to 12.
- Change debhelper version in debian/control to >= 12.
  * debian/copyright: Fix typo.


The build with sbuild and pdebuild and the tests with Lintain are ok.
Piuparts fails about "package purging left files on system" mostly from
a mime package. 

+--+
| Summary  |
+--+

Build Architecture: amd64
Build Type: full
Build-Space: 258220
Build-Time: 96
Distribution: sid
Host Architecture: amd64
Install-Time: 339
Job: /data/entwicklung/linux/debian/shotwell/shotwell_0.30.4-1.dsc
Lintian: info
Machine Architecture: amd64
Package: shotwell
Package-Time: 454
Piuparts: fail
Source-Version: 0.30.4-1
Space: 258220
Status: successful
Version: 0.30.4-1

Finished at 2019-07-12T10:53:15Z
Build needed 00:07:34, 258220k disk space

  Regards,
   Jörg Frings-Fürst
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.

Bug#931912: Please do not Depends/Recommends against gnome-icon-theme

[Laurent Bigonville]

Hello Hilmar,

That's indeed what I'm proposing.

Kind regards,

Laurent Bigonville

On 12/07/19 11:27, Hilmar Preuße wrote:

On 12.07.19 10:24, Laurent Bigonville wrote:

Hi Laurent,

thanks for the report and explanation!

Just to make sure what we have to do now:

1. replace the line "Icon=info" in /usr/share/applications/info.desktop
by "Icon=dialog-information"
2. Drop recommends against gnome-icon-theme and simply assume that an
incarnation of icon "dialog-information" is part of every desktop
installation.

Please confirm!

Thanks,
   Hilmar


I see that the info package Recommends gnome-icon-theme, I don't think
it's a good idea.

gnome-icon-theme is not maintained anymore. Also I don't think it's up
to a leaf application to define the icon theme that should be installed.

The best solution is to use a xdg icon name and expect that the user
will have an icon theme installed.

If you want a "light bulb" icon, you should probably use the name
"dialog-information" icon which is part of the xdg standard (see
https://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html)

I see this icon being part of most of the icon theme.

Bug#907041: ITP: swupdate -- SWUpdate provides a reliable way to update the software on an embedded system

[Stefano Babic]

Hi Shyam,

On 12/07/19 13:53, Shyam Saini wrote:
> Hi,
> 
> Is there any update on this?
> 
> Any tentative date or time when It could be officially added.
> 
> We need swupdate as official debian package for one of our customer.
> If it would not be added in next few months then we would probably
> like to use swupdate with yocto.
> 

The package was pushed by SZ (see link) to debian and he expects it will
be merged sonn, now that "buster" is released.

[1] https://ftp-master.debian.org/new.html

Anyway, (not yet merged) packages are available. You can use the link
above, or SWUpdate has a -debian branch to build the package on your own.

>  please let us me know about the status so that we can make our
> decision accordingly.

Weird, decision to take debian or Yocto should not be based on
SWUpdate's availability.

Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

Bug#931827: lighttpd: server returnd 400, if %C0 is included in the URL

[Helmut Grohne]

Hi,

On Thu, Jul 11, 2019 at 02:38:19AM +0200, OHNO Tetsuji wrote:
> lighttpd server is returnd ”400 Bad Request", if %C0 (or any other
> char.) is included in the URL.
> 
> for example,
> http://localhost/index.lighttpd.html : return OK (display index page)
> http://localhost/index.lighttpd.html?%C0 : 400 Bad Request
> http://localhost/index.lighttpd.html?%C1 : 400 Bad Request
> http://localhost/index.lighttpd.html?%C2 : OK
> 
> I can't understand this behavior.

Thank you for the detailed report. I don't fully understand this either
and am thus Ccing Glenn Strauss (upstream).

> -- Configuration Files:

Thank you for including the configuration.

> server.http-parseopts = (
>   "header-strict"   => "enable",# default
>   "host-strict" => "enable",# default
>   "host-normalize"  => "enable",# default
>   "url-normalize-unreserved"=> "enable",# recommended highly
>   "url-normalize-required"  => "enable",# recommended
>   "url-ctrls-reject"=> "enable",# recommended
>   "url-path-2f-decode"  => "enable",# recommended highly (unless breaks 
> app)
>  #"url-path-2f-reject"  => "enable",
>   "url-path-dotseg-remove"  => "enable",# recommended highly (unless breaks 
> app)
>  #"url-path-dotseg-reject"  => "enable",
>  #"url-query-20-plus"   => "enable",# consistency in query string
> )

You are using the new parsing defaults that Glenn implemented for
buster. I suspect that by changing one of these to disable, you can
restore the previous behaviour. (<- workaround)

I guess that the behaviour is connected to buffer_is_valid_UTF8 in some
way. If you pass the decoded buffer to buffer_is_valid_UTF8 you get 0
(invalid) for "\xc0" and for "\xc1", but not for "\xc2". However, those
cases where buffer_is_valid_UTF8 is involved would typically result in a
502 code rather than 400, so maybe this is wrong.

Glenn, can you comment on this?

Helmut

Bug#931926: tiger: removing tiger package fails in postrm because /var/log/tiger is removed before somehow

[Dominik Stadler]

Package: tiger
Version: 1:3.2.4~rc1-1
Severity: normal

Dear Maintainer,

I am installing debian machines via Ansible and also clean out some packages 
sometimes.

When trying to uninstalling tiger, sometimes the postrm script fails because 
/var/log/tiger 
does not exist any more when the postrm script is run.

I verified that before removal of the package the directory /var/log/tiger did 
still exist,
but uninstalling did still fail somehow, so it seems the uninstallation of 
tiger somehow
removes this directory as part of normal package removal and then the postrm 
script fails
because the directory is not available any more.

However it was not always reproducible and I could not pinpoint the exact 
circumstances for this
to happen.

Maybe the postrm script should handle this more gracefully by not failing when 
the directory
is not there any more.

This is the output of my Ansible playbook


TASK [Uninstall tiger first to work around a bug in postrm] 
*
task path: /opt/svn/Ansible/tasks/cleanout.yml:60
fatal: [bionic]: FAILED! => {
"changed": false,
"rc": 100
}

STDOUT:

Reading package lists...
Building dependency tree...
Reading state information...
The following packages were automatically installed and are no longer required:
  chkrootkit john john-data tripwire
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  tiger*
0 upgraded, 0 newly installed, 1 to remove and 3 not upgraded.
After this operation, 2545 kB disk space will be freed.
(Reading database ... 346436 files and directories currently installed.)
Removing tiger (1:3.2.4~rc1-1) ...
Processing triggers for mime-support (3.62) ...
Processing triggers for gnome-menus (3.31.4-3) ...
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for desktop-file-utils (0.23-4) ...
(Reading database ... 346061 files and directories currently installed.)
Purging configuration files for tiger (1:3.2.4~rc1-1) ...
find: '/var/log/tiger/': No such file or directory
dpkg: error processing package tiger (--purge):
 installed tiger package post-removal script subprocess returned error exit 
status 1
Errors were encountered while processing:
 tiger
libdvd-pkg: Checking orig.tar integrity...
/usr/src/libdvd-pkg/libdvdcss_1.4.2.orig.tar.bz2: OK
libdvd-pkg: `apt-get check` failed, you may have broken packages. Aborting...



STDERR:

E: Sub-process /usr/bin/dpkg returned an error code (1)



MSG:

'apt-get remove 'tiger'' failed: E: Sub-process /usr/bin/dpkg returned an error 
code (1)




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

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tiger depends on:
ii  binutils   2.31.1-16
ii  bsdmainutils   11.1.2+b1
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  net-tools  1.60+git20180626.aebd88e-1
ii  ucf3.0038+nmu1

Versions of packages tiger recommends:
ii  chkrootkit  0.52-3+b10
ii  john1.8.0-2+b1
ii  postfix [mail-transport-agent]  3.4.5-1
ii  tripwire2.4.3.7-1+b10

Versions of packages tiger suggests:
ii  lsof  4.91+dfsg-1

-- debconf information excluded

Bug#931925: ITP: r-cran-gbrd -- GNU R utilities for processing Rd objects and files

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-gbrd -- GNU R utilities for processing Rd objects and files
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-gbrd
  Version : 0.4
  Upstream Author : Georgi N. Boshnakov
* URL : https://cran.r-project.org/package=gbRd
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R utilities for processing Rd objects and files
 Provides utilities for processing Rd objects and files.
 Extract argument descriptions and other parts of the help pages
 of functions.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-gbrd

Bug#907041: ITP: swupdate -- SWUpdate provides a reliable way to update the software on an embedded system

[Shyam Saini]

Hi,

Is there any update on this?

Any tentative date or time when It could be officially added.

We need swupdate as official debian package for one of our customer.
If it would not be added in next few months then we would probably
like to use swupdate with yocto.

 please let us me know about the status so that we can make our
decision accordingly.

Thanks and regards,
Shyam

Bug#931924: ITP: r-cran-clubsandwich -- GNU R cluster-robust (Sandwich) variance estimators with small-sample

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-clubsandwich -- GNU R cluster-robust (Sandwich) variance 
estimators with small-sample
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-clubsandwich
  Version : 0.3.5
  Upstream Author : James Pustejovsky
* URL : https://cran.r-project.org/package=clubSandwich
* License : GPL-3
  Programming Lang: GNU R
  Description : GNU R cluster-robust (Sandwich) variance estimators with 
small-sample
 Corrections Provides several cluster-robust variance estimators
 (i.e., sandwich estimators) for ordinary and weighted least
 squares linear regression models, including the bias-reduced
 linearization estimator introduced by Bell and McCaffrey (2002)
 
 and developed further by Pustejovsky and Tipton (2017)
 . The package includes
 functions for estimating the variance- covariance matrix and for
 testing single- and multiple- contrast hypotheses based on Wald
 test statistics. Tests of single regression coefficients use
 Satterthwaite or saddle-point corrections. Tests of multiple-contrast
 hypotheses use an approximation to Hotelling's T-squared
 distribution. Methods are provided for a variety of fitted models,
 including lm() and mlm objects, glm(), ivreg() (from package
 'AER'), plm() (from package 'plm'), gls() and lme() (from 'nlme'),
 robu() (from 'robumeta'), and rma.uni() and rma.mv() (from
 'metafor').

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-clubsandwich

Bug#931923: gnupg: should support sha2 fingerprints

[Ansgar Burchardt]

Package: gnupg
Version: 2.2.12-1
Severity: normal
Tags: upstream

>From man:gpg(1):

+---
| This format is deduced from the length of the string and its content
| or the 0x prefix.  Note, that only the 20 byte version fingerprint
| is available with gpgsm (i.e. the SHA-1 hash of the certificate).
+---

SHA-2 fingerprints should be supported for X.509 as well.  Web
browsers have shown those for quite a while now.

The same is true for fingerprints of OpenPGP keys, but I'm not sure if
there is any standard for those...

Ansgar

Bug#931922: xygrib: FTBFS with PROJ 6

[Bas Couwenberg]

Source: xygrib
Version: 1.2.2-1
Severity: important
Tags: upstream patch
User: debian-...@lists.debian.org
Usertags: proj-6

Dear Maintainer,

Your package FTBFS with PROJ 6 from experimental.

The attached patch fixes the issue by defining 
ACCEPT_USE_OF_DEPRECATED_PROJ_API_H.

Note that this is only a temporary workaround, proj_api.h will be
removed in PROJ 7 scheduled for March 2020.

Upstream is aware of the issue, see:

 https://github.com/opengribs/XyGrib/issues/200

Kind Regards,

Bas
diff -Nru xygrib-1.2.2/debian/rules xygrib-1.2.2/debian/rules
--- xygrib-1.2.2/debian/rules   2019-01-21 11:25:25.0 +0100
+++ xygrib-1.2.2/debian/rules   2019-04-13 12:08:31.0 +0200
@@ -2,6 +2,9 @@
 
 export DH_VERBOSE=1
 
+# Workaround for proj_api.h deprecation in PROJ 6.0.0
+export DEB_CXXFLAGS_MAINT_APPEND=-DACCEPT_USE_OF_DEPRECATED_PROJ_API_H
+
 # The magic debhelper  rule
 %:
dh $@ --buildsystem=cmake

Bug#645788: openssh-server: Workaround

[Orlando Muñoz]

Package: openssh-server
Version: 1:7.9p1-10
Followup-For: Bug #645788

Dear Maintainer,

Authentication always failed when using sshd server launched from xinetd.
Issue was track down to the fact that sshd systemd script created a /run/sshd 
directory.
But that directory does not exist when called from xinetd.

Workarround was to place a conf file on /etc/tmffiles.d
---snip (sshd.conf)
d /run/sshd 0700 root root
---snip

This creates the required diretory during system startup on the dynamic /run 
(tmpfs).

I suggest removing the creation/deletion of the /run/sshd diretory from the 
ssh.service 
systemd service script, and placing a tmpfiles conf to do the same at startup.

That would work in both cases (standalone service and xinetd helper).

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

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

Versions of packages openssh-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  dpkg   1.19.7
ii  libaudit1  1:2.8.4-3
ii  libc6  2.28-10
ii  libcom-err21.44.5-1
ii  libgssapi-krb5-2   1.17-3
ii  libkrb5-3  1.17-3
ii  libpam-modules 1.3.1-5
ii  libpam-runtime 1.3.1-5
ii  libpam0g   1.3.1-5
ii  libselinux12.8-1+b1
ii  libssl1.1  1.1.1c-1
ii  libsystemd0241-5
ii  libwrap0   7.6.q-28
ii  lsb-base   10.2019051400
ii  openssh-client 1:7.9p1-10
ii  openssh-sftp-server1:7.9p1-10
ii  procps 2:3.3.15-2
ii  ucf3.0038+nmu1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages openssh-server recommends:
ii  libpam-systemd  241-5
ii  ncurses-term6.1+20181013-2
ii  xauth   1:1.0.10-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  rssh  
pn  ssh-askpass   
pn  ufw   

-- debconf information:
  openssh-server/permit-root-login: true
  openssh-server/password-authentication: true

Bug#802100: gnupg should fetch keys using hkps by default

[Guillem Jover]

Hi!

On Sat, 2015-10-17 at 15:31:22 +0100, Antoine Amarilli wrote:
> Package: gnupg
> Version: 1.4.19-5
> Severity: wishlist

> By default, gpg requests keys using HKP server . This allows a
> passive attacker to obtain information about the keys requested by the user,
> which may be harmful in terms of privacy.
> 
> I think that gpg should be using an HKPS server by default. See e.g.,
> 
> 
> See also a similar bug for dirmngr:
> .

It looks like this is fixed now, but not sure when it was first fixed,
will leave it up to the maintainers.

Thanks,
Guillem

Bug#931339: gnupg: Change default keyserver?

[Guillem Jover]

Hi!

On Tue, 2019-07-02 at 15:55:32 +0200, Guillem Jover wrote:
> Package: dirmngr
> Version: 2.2.16-2
> Severity: wishlist

> According to the dirmngr(8) man page, the default built-in server is
> «hkps://hkps.pool.sks-keyservers.net». Given the recent attacks, and
> the problems inherent in that network, could we just change the
> default to be «hkps://keys.openpgp.org» instead?

Thanks for implementing this Daniel! I guess this can be closed now,
although it would be nice to change or remove the references to
hkp://keys.gnupg.net in the docs which seem rather confusing given
the resemblance of both domain names, also because it does not use
hkps, and would be IMO bad advice given the current circumstances.

Thanks,
Guillem

Bug#927197: deluge-web: Updated systemd service for Debian 10

[Orlando Muñoz]

Package: deluge-web
Version: 1.3.15-2
Followup-For: Bug #927197

Dear Maintainer,

I suggest including the following updated version of the systemd service on 
Debian 10 versions.
(It would make life easier for headless systems.)

--- snip
[Unit]
Description=Deluge Bittorrent Client Web Interface
Documentation=man:deluge-web
After=network-online.target deluged.service
Wants=deluged.service
[Service]
Type=simple
User=debian-deluged
Group=debian-deluged
UMask=027
# This 5 second delay is necessary on some systems
# to ensure deluged has been fully started
ExecStartPre=/bin/sleep 5
ExecStart=/usr/bin/deluge-web -c /var/lib/deluged/config -p 8112
Restart=on-failure
[Install]
WantedBy=multi-user.target
--- snip

NOTES:
1) User and Group updated to match deluged service user and group
2) -c /var/lib/deluged/config included in daemon call to point to the same 
config deluged uses

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

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

Versions of packages deluge-web depends on:
ii  deluge-common  1.3.15-2
ii  python 2.7.16-1
ii  python-mako1.0.7+ds1-1

deluge-web recommends no packages.

deluge-web suggests no packages.

-- no debconf information

Bug#902828: pgpdump: autopkgtest regression: sh: 0: Can't open debian/test

[Gianfranco Costamagna]

control: severity -1 serious
control: tags -1 patch
On Sun, 1 Jul 2018 21:18:45 +0200 Paul Gevers  wrote:
> Source: pgpdump
> Version: 0.33-1
> User: debian...@lists.debian.org
> Usertags: regression
> 
> Dear maintainers,
> 
> Since the upload of 0.33-1, your package fails its autopkgtest in
> both unstable and testing, with the error copied below. It seems you
> dropped the file you wanted to test somewhere during packaging.
> 
> This regression is causing your package to have to wait 13 extra days to
> migrate to testing.
> 
> Thanks for consideration.
> 
> Paul
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/pgpdump/533316/log.gz
> 
> autopkgtest [19:13:36]: test command1: [---
> sh: 0: Can't open debian/test
> autopkgtest [19:13:36]: test command1: ---]
> 

This is now RC, and I'm uploading a fix in deferred/15, after testing the patch 
I'm attaching
to this bug.
Please let me know if I can speed it up, this is a really simple fix

You can see the test results here
http://debomatic-amd64.debian.net/distribution#unstable/pgpdump/0.33-1.1/autopkgtest

G.
diff -Nru pgpdump-0.33/debian/changelog pgpdump-0.33/debian/changelog
--- pgpdump-0.33/debian/changelog   2018-06-25 23:57:29.0 +0200
+++ pgpdump-0.33/debian/changelog   2019-07-12 12:33:15.0 +0200
@@ -1,3 +1,14 @@
+pgpdump (0.33-1.1) unstable; urgency=medium
+
+  [ Gianfranco Costamagna ]
+  * Fix testsuite, force UTC as timestamp
+  * Non-maintainer upload
+
+  [ Steve Langasek ]
+  * Restore dropped debian/test.  Closes: #902828.
+
+ -- Gianfranco Costamagna   Fri, 12 Jul 2019 
12:33:15 +0200
+
 pgpdump (0.33-1) unstable; urgency=medium
 
   * release to unstable
diff -Nru pgpdump-0.33/debian/test pgpdump-0.33/debian/test
--- pgpdump-0.33/debian/test1970-01-01 01:00:00.0 +0100
+++ pgpdump-0.33/debian/test2019-07-12 12:31:09.0 +0200
@@ -0,0 +1,22 @@
+#!/bin/sh
+
+set -e
+
+if [ -x ./pgpdump ]; then
+   PGPDUMP=./pgpdump
+else
+   PGPDUMP=pgpdump
+fi
+
+res=0
+for file in $(find data -name '*.res' -type f | env LANG=C sort); do
+src=$(basename "$file" .res)
+printf '%s' "$src"
+if env TZ=UTC "$PGPDUMP" "data/$src" | cmp -s - "$file"; then
+   echo " ok"
+else
+   echo " failed"
+res=1
+fi
+done
+exit "$res"

Bug#931921: clutter's autopkgtests hang when ran with a libglib2.0-0 built with gcc-9

[Iain Lane]

Source: gcc-9
Version: 9.1.0-8
Severity: important

Control: affects -1 gcc libglib2.0-0

Hiya,

I saw this on Ubuntu (9.1.0-8ubuntu1) but I've also reproduced this with
9.1.0-8 on sid (w/gcc-defaults from experimental to use gcc-9 by
default).

clutter's tests hang like this:

0x77b316f4 in __GI___poll (fds=0x558d0420, nfds=2, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
29  ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
(gdb) bt
#0  0x77b316f4 in __GI___poll (fds=0x558d0420, nfds=2, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x77c62c9e in g_main_context_poll (priority=, 
n_fds=2, fds=0x558d0420, timeout=,
context=0x555b0cd0) at ../glib/gmain.c:4213
#2  g_main_context_iterate (context=0x555b0cd0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=)
at ../glib/gmain.c:3909
#3  0x77c63023 in g_main_loop_run (loop=0x55f01d10) at 
../glib/gmain.c:4108
#4  0x6634 in verify_redraw (expected_paint_count=1, 
data=, data=)
at actor-offscreen-redirect.c:172

Here's the bit of code.

  
https://sources.debian.org/src/clutter-1.0/1.26.2+dfsg-10/tests/conform/actor-offscreen-redirect.c/#L172

It's adding some stuff to a main loop and expecting it to finish when a
particular signal handler is called.

There's obviously a lot of code going on here (this isn't anything like
a minimal testcase, and glib2.0's own testsuite & autopkgtests pass so
it's not like GMainLoop is completely broken).

I found an upstream report which I suspect is the same thing:

  https://gitlab.gnome.org/GNOME/clutter/issues/6

Things which make it work again

  - Building glib2.0 w/gcc-9 -O1 (and -O0)
  - Building w/gcc-8 (obviously)

Happy to help try to narrow this down to the optimisation that's
breaking glib and/or the code in glib that's breaking the optimisation.
Maybe in person at Debconf. For now I'm going to upload a glib2.0 that
builds with gcc-8 explicitly.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]

Bug#931920: freeradius: Init script does not stop daemon

[Benjamin Boudoir]

Package: freeradius
Version: 3.0.17+dfsg-1.1
Severity: normal

Dear Maintainer,

The program path is not set in init script when invoking killproc, which is 
requiered by the LSB spec.
Therefore, a "/etc/init.d/freeradius stop" does not stop the daemon as intended 
(at least, when using sysvinit).

Modified init script is included in the bug report.

Regards,

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages freeradius depends on:
ii  freeradius-common  3.0.17+dfsg-1.1
ii  freeradius-config  3.0.17+dfsg-1.1
ii  libc6  2.28-10
ii  libcap21:2.25-2
ii  libct4 1.00.104-1
ii  libfreeradius3 3.0.17+dfsg-1.1
ii  libgdbm6   1.18.1-4
ii  libpam0g   1.3.1-5
ii  libpcre3   2:8.39-12
ii  libperl5.285.28.1-6
ii  libreadline7   7.0-5
ii  libsqlite3-0   3.27.2-3
ii  libssl1.1  1.1.1c-1
ii  libtalloc2 2.1.14-2
ii  libwbclient0   2:4.9.5+dfsg-5
ii  lsb-base   10.2019051400

Versions of packages freeradius recommends:
ii  freeradius-utils  3.0.17+dfsg-1.1

Versions of packages freeradius suggests:
pn  freeradius-krb5
pn  freeradius-ldap
pn  freeradius-mysql   
pn  freeradius-postgresql  
pn  freeradius-python2 
ii  snmp   5.7.3+dfsg-5

-- Configuration Files:
/etc/init.d/freeradius changed:
PROG="freeradius"
PROGRAM="/usr/sbin/freeradius"
PIDFILE="/var/run/freeradius/freeradius.pid"
DESCR="FreeRADIUS daemon"
set -e
. /lib/lsb/init-functions
configtest() {
log_action_begin_msg "Checking $DESCR configuration"
out=`$PROGRAM -Cxl stdout $FREERADIUS_OPTIONS`; ret=$?
out=`echo "${out}" | tail -n 1 | sed 's/^\s*ERROR:\s*\(.*\)\s*$/\1/'`
log_action_end_msg $ret "$out"
return $ret
}
if [ -r /etc/default/$PROG ]; then
. /etc/default/$PROG
fi
test -f $PROGRAM || exit 0
if [ ! -d /var/run/freeradius ]; then
mkdir -p /var/run/freeradius
chown freerad:freerad /var/run/freeradius
fi
if [ -d "$FREERADIUS_CONF_LOCAL" -a -z "$FREERADIUS_OPTIONS" ]; then
  FREERADIUS_OPTIONS="-d $FREERADIUS_CONF_LOCAL"
fi
export PATH="${PATH:+$PATH:}/usr/sbin:/sbin"
ret=0
case "$1" in
start)
log_daemon_msg "Starting $DESCR" "$PROG"
# eval allows quoted arguments (config directories for example) to be 
passed in $FREERADIUS_OPTIONS
eval "start_daemon -p '$PIDFILE' '$PROGRAM' $FREERADIUS_OPTIONS" || 
ret=$?
log_end_msg $ret
;;
stop)
log_daemon_msg "Stopping $DESCR" "$PROG"
killproc -p "$PIDFILE" "$PROGRAM" || ret=$?
log_end_msg $ret
;;
restart|force-reload)
configtest || exit 150
$0 stop
$0 start
;;
reload)
configtest || exit 150
if status_of_proc -p "$PIDFILE" "$PROG" "$DESCR"; then
log_daemon_msg "Reloading $DESCR" "$PROG"
start-stop-daemon --stop --signal HUP --quiet --pidfile $PIDFILE || 
ret=$?
log_end_msg $ret
fi
;;
configtest|testconfig)
configtest || exit 150
;;
debug)
$0 status
if [ $? -eq 0 ]; then
echo "$PROGRAM already running; for live debugging see raddebug(8)"
exit 151
fi
$PROGRAM -X $FREERADIUS_OPTIONS || exit $?
;;
debug-threaded)
$0 status
if [ $? -eq 0 ]; then
echo "$PROGRAM already running; for live debugging see raddebug(8)"
exit 151
fi
$PROGRAM -f -xx -l stdout $FREERADIUS_OPTIONS || exit $?
;;
status)
status_of_proc -p "$PIDFILE" "$PROGRAM" "$PROG" && exit 0 || exit $?
;;
*)
echo "Usage: $0 
start|stop|restart|force-reload|reload|configtest|debug|debug-threaded|status"
exit 1
;;
esac
exit $ret


-- no debconf information

Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

[Michel Dänzer]

On 2019-07-12 12:07 p.m., Finn Thain wrote:
> On Fri, 12 Jul 2019, Michel D?nzer wrote:
>> On 2019-07-11 6:49 p.m., user...@yahoo.com wrote:
>>>
>>> b) I was not able to install Michel's patch -- I wasn't sure what 
>>> compile or other options to use.  It looks like I could build a new 
>>> kernel with that (patched) module; would that be the best way to 
>>> include the patch?  I see that a commit was made yesterday (Jul 10) 
>>> related to the patch, so I can just wait and test it when it's 
>>> available in Debian sid, or I can build a new kernel with the patch 
>>> included.  Please advise.
>>
>> It's an xf86-video-mach64 / xserver-xorg-video-mach64 patch, not a 
>> kernel one. And yes, it's been merged to upstream Git master: 
>> https://gitlab.freedesktop.org/xorg/driver/xf86-video-mach64/commit/37498721a520cd1cff367bc36b1ac74b343826ca
>>
> 
> Do you plan to backport this commit for Debian's packages?

I'm not involved in Debian packaging.


-- 
Earthling Michel Dänzer   |  https://www.amd.com
Libre software enthusiast | Mesa and X developer

Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

[Finn Thain]

On Fri, 12 Jul 2019, Michel D?nzer wrote:

> On 2019-07-11 6:49 p.m., user...@yahoo.com wrote:
> > 
> > b) I was not able to install Michel's patch -- I wasn't sure what 
> > compile or other options to use.  It looks like I could build a new 
> > kernel with that (patched) module; would that be the best way to 
> > include the patch?  I see that a commit was made yesterday (Jul 10) 
> > related to the patch, so I can just wait and test it when it's 
> > available in Debian sid, or I can build a new kernel with the patch 
> > included.  Please advise.
> 
> It's an xf86-video-mach64 / xserver-xorg-video-mach64 patch, not a 
> kernel one. And yes, it's been merged to upstream Git master: 
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-mach64/commit/37498721a520cd1cff367bc36b1ac74b343826ca
> 

Do you plan to backport this commit for Debian's packages?

-- 

Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

[Finn Thain]

On Thu, 11 Jul 2019, user...@yahoo.com wrote:

> On 7/11/19 8:15 PM, Finn Thain wrote:
> > On Thu, 11 Jul 2019, user...@yahoo.com wrote:
> > ...
> >>
> >> Shadowfb has no effect for mach64.
> > 
> > I haven't seen any results that confirm this. Your results seem to 
> > show that the xorg.conf change was bogus.
> > 
> > Moreover, the X server logs show that the shadow framebuffer was never 
> > actually enabled for any mach64 test.
> > 
> > So it's an open question.
> > ...
> 
> Please see Xorg_sid_mach64.log.
> 
> That file has this line:
> 
> [ 16529.773] (WW) MACH64(0): Cannot shadow an accelerated frame buffer.
> 
> I take that to mean that shadowing can not work for mach64, so it is 
> explicitly disabled regardless of whether it is specified in an 
> xorg.conf file (and it must be specified somewhere by default for 
> mach64, since I didn't use any custom xorg.conf files).

Alternatively, "cannot shadow an accelerated frame buffer" could imply 
that we need to disable acceleration for mach64.

> That same message, and no other message related to shadowing, appears in 
> the Xorg log regardless of whether shadowfb (or shadow_fb) is set to 
> "true" or "false" in a custom /etc/X11/xorg.conf file:
> 

But why would the above warning message show up if shadowfb were in fact 
disabled by xorg.conf? I take the warning to mean that the xorg.conf I 
provided is bogus.

Anyway, I can't offer a config that would enable/disable acceleration or 
enable/disable shadowed framebuffer, so I'll leave it with Michel to 
pursue that workaround if he wishes to.

-- 

Bug#931878: libonig: CVE-2019-13224 CVE-2019-13225

[Jörg Frings-Fürst]

tags 931878 +pending
thanks

Hello Salvatore,

I have the libonig release 6.9.2 with both upstream fixes for the CVEs
ready for upload.

It is uploaded to mentors[1] and into the git[2].

Should the upload of the package be handled by the security team? 
Or can I take care of it myself? 

My changes:

  * New upstream release:
- Refresh symbols file.
- Refresh debian/patches/0100-source_typos.patch.
  * Rewrite debain/watch.
  * New debian/patches/0105-CVE-2019-13224.patch and
  debian/patches/0110-CVE-2019-13225.patch (Closes: #931878):
- Fixes CVE-2019-13224 A use-after-free in onig_new_deluxe() in regext.c.
- Fixes CVE-2019-13225 A NULL Pointer Dereference in match_at()
   in regexec.c.
  * Declare compliance with Debian Policy 4.4.0 (No changes needed).
  * Migrate to debhelper 12:
- Change debian/compat to 12.
- Bump minimum debhelper version in debian/control to >= 12.
- debian/rules: Remove obsolete dh_install --fail-missing.

CU
Jörg


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.

Bug#931854: liblopsub: please make the output of lopsubgen reproducible

[Andre Noll]

On Thu, Jul 11, 10:43, Chris Lamb wrote

> Whilst working on the Reproducible Builds effort [0], we noticed
> that liblopsub generates output that is not reproducible. The
> lopsubgen utility does not respect SOURCE_DATE_EPOCH [1] and thus
> packages such as src:tfortune are rendered unreproducible as they
> then encode the build date and time.
> 
> Patch attached.

Good catch. I've applied your patch and made some minor edits to
improve code readability and to fix the typo in the new comment.

Are you OK with the commit below?

Thanks
Andre
---
commit 0a8299dd8da7dba7437550d12bf180d9e10d512b
Author: Chris Lamb 
Date:   Fri Jul 12 07:59:50 2019 +0200

lsg.c: Make the output of lopsubgen reproducible.

Whilst working on the Reproducible Builds effort [0], we noticed that
liblopsub generates output that is not reproducible. The lopsubgen
utility does not respect SOURCE_DATE_EPOCH [1] and thus packages such
as src:tfortune are rendered unreproducible as they then encode the
build date and time.

This patch makes lopsubgen honour SOURCE_DATE_EPOCH.

[0] https://reproducible-builds.org/
[1] https://reproducible-builds.org/specs/source-date-epoch/

Signed-off-by: Andre Noll 

diff --git a/lsg.c b/lsg.c
index 54b7816..83a72da 100644
--- a/lsg.c
+++ b/lsg.c
@@ -610,7 +610,7 @@ static char *get_output_path(const char *suffix, const char 
*arg,
 static void gen_man(struct lls_parse_result *lpr, const char *cmdline)
 {
int i;
-   time_t t;
+   time_t t = 0;
struct tm *tmp;
FILE *out;
char *outpath = get_output_path("man",
@@ -626,12 +626,22 @@ static void gen_man(struct lls_parse_result *lpr, const 
char *cmdline)
if (suite.commands[0].name.orig) {
char date[200];
const char *version_string;
-
if (!suite.date) {
-   t = time(NULL);
-   tmp = localtime();
+   /*
+* If the SOURCE_DATE_EPOCH environment variable
+* contains a positive integer in the time_t range, use
+* that instead of the current time. See:
+* 

+* for more information.
+*/
+   char *source_date_epoch = getenv("SOURCE_DATE_EPOCH");
+   if (source_date_epoch != NULL)
+   t = strtoll(source_date_epoch, NULL, 10);
+   if (t <= 0)
+   t = time(NULL);
+   tmp = gmtime();
if (tmp == NULL) {
-   perror("localtime");
+   perror("gmtime");
exit(EXIT_FAILURE);
}
if (strftime(date, sizeof(date), "%B %Y", tmp) == 0) {
-- 
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/


signature.asc
Description: PGP signature

Bug#925728: lagan: ftbfs with GCC-9

[Gianfranco Costamagna]

control: tags -1 patch

don't ask me why, but removing "inline" from findPrev function works...

--- lagan-2.0.orig/src/fchaos.c
+++ lagan-2.0/src/fchaos.c
@@ -430,7 +430,7 @@ int chain(LList* second, int off2, LList
 int tc =0;
 int wc = 0;
 
-inline void findPrev(LList* curr, int position, int offset, float baseval) {
+void findPrev(LList* curr, int position, int offset, float baseval) {
   int j,k;
   LList* temp;
   sle* iterator;

Bug#930996: closed by Thomas Goirand (Bug#930996: fixed in cloudkitty 8.0.0-5)

[Santiago Vila]

reopen 930996
found 930996 8.0.0-4
fixed 930996 8.0.0-5
thanks

Hi. Reopening because packages in buster must build in buster.

In addition to the fix in unstable, this should be fixed in
buster-proposed-updates as well.

Thanks.

Bug#931169: hfst: add Breaks: libhfst45-dev for smoother upgrades from stretch

[Andreas Beckmann]

Followup-For: Bug #931169
Control: tag -1 pending

Hi,

I just uploaded my patch as a NMU to DELAYED/10.
I'm planning to rebuild that package for buster to get the upgrade
problem fixed there in the next point release.

Andreas

Bug#931912: Please do not Depends/Recommends against gnome-icon-theme

[Hilmar Preuße]

On 12.07.19 10:24, Laurent Bigonville wrote:

Hi Laurent,

thanks for the report and explanation!

Just to make sure what we have to do now:

1. replace the line "Icon=info" in /usr/share/applications/info.desktop
by "Icon=dialog-information"
2. Drop recommends against gnome-icon-theme and simply assume that an
incarnation of icon "dialog-information" is part of every desktop
installation.

Please confirm!

Thanks,
  Hilmar

> I see that the info package Recommends gnome-icon-theme, I don't think
> it's a good idea.
> 
> gnome-icon-theme is not maintained anymore. Also I don't think it's up
> to a leaf application to define the icon theme that should be installed.
> 
> The best solution is to use a xdg icon name and expect that the user
> will have an icon theme installed.
> 
> If you want a "light bulb" icon, you should probably use the name
> "dialog-information" icon which is part of the xdg standard (see
> https://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html)
> 
> I see this icon being part of most of the icon theme.
> 

-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#674857: Disable pam_securetty by default?

[Sven Joachim]

On 2016-11-17 12:01 +0100, Olliver Schinagl wrote:

> Hey all,
>
> raising this one from the crypt
>
>>
>>> So the security benefit isn't in preventing users from logging in as root
>>> over certain serial lines, it's in preventing users from logging in as root
>>> over *pseudo*ttys.
>>
>> It is unix museumware from time when people didn't use ssh and su/sudo
>> all time.
>
> I just did a clean install of debian jessie (via debootstrap into a
> systemd-nspawn container) and noticed that I could not login using
> machinectl login 
>
> securtty bites us.
>
> The reason it bites is that by default, the container comes up with a
> console on pts/0.
>
> I see in securetty there are workarounds for LXC already and adding
> pts/0 as a work around for systemd-nspawn then makes me wonder, is
> this not a pseudo tty? And thus, the only argument made in 2012, with
> systemd containers will make that last argument fall? As you always
> need a pseudo-tty here.
>
> So I also suggest, opt-in vs opt-out on the pam_securetty module so
> that 'museums' can still enable them if needed.

FWIW, the latest login upload to unstable (1:4.7-1) dropped support for
/etc/securetty and removed that file on upgrades, due to the numerous
complaints it caused:

,
| shadow (1:4.7-1) unstable; urgency=medium
|
|   [ Balint Reczey ]
|   * Stop shipping and honoring /etc/securetty
| (Closes: #731656, #830255, #879903, #920764, #771675, #917893, #607073)
`

This lead to complaints by pam_unix in the system logs on every login,
see #931899.  I think it's time to disable pam_securetty by default, it
was useful twenty years ago but it no longer is.

Cheers,
   Sven

Bug#931919: debian-handbook: Debian Handbook for Debian Buster

[tkoeck]

Package: debian-handbook
Version: 8.20180830
Severity: wishlist

Dear Maintainer,

are there any plans to update the book to Debian Buster? As far as I
have seen it's just for Debian Jessie.

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

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

-- no debconf information

Bug#931911: user-setup: Fails to present no-root-password_first-user-sudoer option as a reasonable choice

[Philip Hands]

I've just pushed a branch to salsa:

  
https://salsa.debian.org/installer-team/user-setup/tree/bug-931911-empty-root-password-OK

that is an attempt to make this better.  Comments welcome.

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


signature.asc
Description: PGP signature

Bug#931918: Installation report

[Staffan Melin (Oscillator)]

Package: installation-reports

Boot method:
Installed Debian 10 from scratch using the non-free ISO, dd:ed to a USB stick.
A dual boot with the original Win10 intact.

Image version:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/10.0.0-live+nonfree/amd64/iso-hybrid/

Date: 2019-07-10

Machine: Lenovo Yoga 730
Processor: Core i5
Memory: 8GB
Partitions:
ilesystem Type 1K-blocks Used Available Use% Mounted on
udev   devtmpfs   39111960   3911196   0% /dev
tmpfs  tmpfs   788556 9540779016   2% /run
/dev/nvme0n1p5 ext4  92578456 11969172  75863508  14% /
tmpfs  tmpfs  394276845980   3896788   2% /dev/shm
tmpfs  tmpfs 51204  5116   1% /run/lock
tmpfs  tmpfs  39427680   3942768   0% /sys/fs/cgroup
/dev/nvme0n1p1 vfat26214439232222912  15% /boot/efi
tmpfs  tmpfs   7885528788544   1% /run/user/1000

Output of lspci -knn (or lspci -nn):
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3e34] (rev 0b)
Subsystem: Lenovo Device [17aa:3801]
00:02.0 VGA compatible controller [0300]: Intel Corporation UHD
Graphics 620 (Whiskey Lake) [8086:3ea0]
Subsystem: Lenovo UHD Graphics 620 (Whiskey Lake) [17aa:39fd]
Kernel driver in use: i915
Kernel modules: i915
00:04.0 Signal processing controller [1180]: Intel Corporation Skylake
Processor Thermal Subsystem [8086:1903] (rev 0b)
Subsystem: Lenovo Xeon E3-1200 v5/E3-1500 v5/6th Gen Core
Processor Thermal Subsystem [17aa:3821]
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device
00:08.0 System peripheral [0880]: Intel Corporation Skylake Gaussian
Mixture Model [8086:1911]
Subsystem: Lenovo Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen
Core Processor Gaussian Mixture Model [17aa:3851]
00:12.0 Signal processing controller [1180]: Intel Corporation Cannon
Point-LP Thermal Controller [8086:9df9] (rev 30)
Subsystem: Lenovo Cannon Point-LP Thermal Controller [17aa:3803]
Kernel driver in use: intel_pch_thermal
Kernel modules: intel_pch_thermal
00:14.0 USB controller [0c03]: Intel Corporation Cannon Point-LP USB
3.1 xHCI Controller [8086:9ded] (rev 30)
Subsystem: Lenovo Cannon Point-LP USB 3.1 xHCI Controller [17aa:3802]
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
00:14.2 RAM memory [0500]: Intel Corporation Cannon Point-LP Shared
SRAM [8086:9def] (rev 30)
Subsystem: Intel Corporation Cannon Point-LP Shared SRAM [8086:9def]
00:15.0 Serial bus controller [0c80]: Intel Corporation Device
[8086:9de8] (rev 30)
Subsystem: Lenovo Device [17aa:3804]
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci
00:15.1 Serial bus controller [0c80]: Intel Corporation Device
[8086:9de9] (rev 30)
Subsystem: Lenovo Device [17aa:3805]
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci
00:15.2 Serial bus controller [0c80]: Intel Corporation Device
[8086:9dea] (rev 30)
Subsystem: Lenovo Device [17aa:3806]
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci
00:16.0 Communication controller [0780]: Intel Corporation Cannon
Point-LP MEI Controller [8086:9de0] (rev 30)
Subsystem: Lenovo Cannon Point-LP MEI Controller [17aa:3807]
Kernel driver in use: mei_me
Kernel modules: mei_me
00:1c.0 PCI bridge [0604]: Intel Corporation Cannon Point-LP PCI
Express Root Port [8086:9dbc] (rev f0)
Kernel driver in use: pcieport
00:1c.7 PCI bridge [0604]: Intel Corporation Device [8086:9dbf] (rev f0)
Kernel driver in use: pcieport
00:1d.0 PCI bridge [0604]: Intel Corporation Cannon Point-LP PCI
Express Root Port [8086:9db0] (rev f0)
Kernel driver in use: pcieport
00:1d.4 PCI bridge [0604]: Intel Corporation Device [8086:9db4] (rev f0)
Kernel driver in use: pcieport
00:1f.0 ISA bridge [0601]: Intel Corporation Cannon Point-LP LPC
Controller [8086:9d84] (rev 30)
Subsystem: Lenovo Cannon Point-LP LPC Controller [17aa:380e]
00:1f.3 Audio device [0403]: Intel Corporation Cannon Point-LP High
Definition Audio Controller [8086:9dc8] (rev 30)
Subsystem: Lenovo Cannon Point-LP High Definition Audio Controller
[17aa:3810]
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel, snd_soc_skl
00:1f.4 SMBus [0c05]: Intel Corporation Cannon Point-LP SMBus
Controller [8086:9da3] (rev 30)
Subsystem: Lenovo Cannon Point-LP SMBus Controller [17aa:3811]
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801
00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon
Point-LP SPI Controller [8086:9da4] (rev 30)
Subsystem: Intel Corporation Cannon Point-LP SPI Controller [8086:7270]
39:00.0 Network controller [0280]: Intel Corporation Wireless-AC 9260
[8086:2526] (rev 29)
Subsystem: Intel Corporation Wireless-AC 9260 [8086:0014]
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
3b:00.0 Non-Volatile memory 

Bug#931917: grub-installer: call efibootmgr (if available) to keep track of boot order/options

[Cyril Brulebois]

Package: grub-installer
Version: 1.165
Severity: important

With stretch, we were getting efibootmgr's output in the installer's
syslog, which could help track down issues related to the boot sequence.

With buster, due to grub2's switch to using libefi* (since both the
2.02+dfsg1-14 and 2.02+dfsg1-15 uploads), efibootmgr is no longer used;
it's kept in Recommends (since 2.02+dfsg1-17) though.

It would be great to check whether efibootmgr is present and to call it
to get its output back into the installer's syslog.

This would have been helpful for the #931910 installation report, for
example.


Once it's implemented and tested in unstable/testing, I'll consider
backporting this for a buster point release.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Bug#931916: ITP: r-cran-spatialreg -- GNU R spatial regression analysis

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-spatialreg -- GNU R spatial regression analysis
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-spatialreg
  Version : 1.1
  Upstream Author : Roger Bivand,
* URL : https://cran.r-project.org/package=spatialreg
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R spatial regression analysis
 A collection of all the estimation functions for spatial cross-sectional
 models (on lattice/areal data using spatial weights matrices) contained
 up to now in 'spdep', 'sphet' and 'spse'. These model fitting functions
 include maximum likelihood methods for cross-sectional models proposed
 by 'Cliff' and 'Ord' (1973, ISBN:0850860369) and (1981,
 ISBN:0850860814), fitting methods initially described by 'Ord' (1975)
 . The models are further described
 by 'Anselin' (1988) . Spatial two stage
 least squares and spatial general method of moment models initially
 proposed by 'Kelejian' and 'Prucha' (1998) 
 and (1999)  are provided. Impact methods
 and MCMC fitting methods proposed by 'LeSage' and 'Pace' (2009)
  are implemented for the family of cross-
 sectional spatial regression models. Methods for fitting the log
 determinant term in maximum likelihood and MCMC fitting are compared by
 'Bivand et al.' (2013) , and model fitting
 methods by 'Bivand' and 'Piras' (2015) ; both
 of these articles include extensive lists of references. 'spatialreg' >=
 1.1-* correspond to 'spdep' >= 1.1-1, in which the model fitting
 functions are deprecated and pass through to 'spatialreg', but will mask
 those in 'spatialreg'. From versions 1.2-*, the functions will be made
 defunct in 'spdep'.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-spatialreg

Bug#931845: Cannot install solr-tomcat when building docker image

[Aki Tuomi]

On 12.7.2019 11.19, Emmanuel Bourg wrote:
> Le 12/07/2019 à 09:31, Aki Tuomi a écrit :
>
>> Seems that this can be worked around with setting during installation
>> SYSTEMCTL_INSTALL_CLIENT_SIDE=1 SYSTEMCTL_FORCE_BUS=1 SYSTEMD_OFFLINE=1
> As I understand from the systemd documentation [1] this disables the
> interactions with PID 1, so I guess it can only be used in a docker
> environment otherwise the service will end in a weird state. Does it
> work if you declare these variables in the dockerfile?
>
> Emmanuel Bourg
>
> [1] https://systemd.io/ENVIRONMENT.html

Yes.

Aki

Bug#931915: ifupdown: Interfaces with static IP get 169.254.x.x assigned by DHCP client

[Robert Dinse]

Package: ifupdown
Version: 0.8.35
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

 I upgraded a machine from stretch to buster.  It had an assigned static
IP of 204.122.16.15.  The machine ran fine for two days then disappeared from
the network.

 Upon investigation I found it had a 169.254.x.x address assigned in
addition to the staticly assigned address.  The routing table showed this
in with a route scope of local and my default route still there but the machine
would not route to the Internet with this IP address on the interface and the
bogus route in place.

 Removing the IP caused ALL routes to be deleted from the routing table,
and then manually adding them back in allowed the machine to work again for
a while, then it did it again.

 It seemed the DHCP client kept trying to assign this bogus address to
the interface.

 Deleting the DHCP client from the system fixed this issue but this should
not be necessary.  It should not add a second IP to an interface with an
assigned static IP AND even if it did the route should not have interfered
with the default route but it did.

 This is, to put it mildly, extremely unfriendly network behavior.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 Deleting the DHCP client fixed the issue for me but this is obviously
undesirable for people without static IP space.

   * What was the outcome of this action?
 
 After deleting the DHCP client my machine operated as expected.  Also,
it booted nearly instantly where as before there was considerable delay while
DHCP tried to acquire an address even though the Interface had a static IP.

   * What outcome did you expect instead?

 I expect that if I have an interface configured with a static IP via
the Network Manager, DHCP client should NOT run on that interface at all.
*** End of the template - remove these template lines ***


-- Package-specific info:
--- /etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

--- /etc/network/interfaces.d/*:
cat: '/etc/network/interfaces.d/*': No such file or directory

--- up and down scripts installed:
/etc/network/if-down.d:
total 0
lrwxrwxrwx 1 root root 32 Jun  6 06:16 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-post-down.d:
total 4
lrwxrwxrwx 1 root root   23 Oct 10  2018 avahi-daemon -> ../if-up.d/avahi-daemon
-rwxr-xr-x 1 root root 1409 Jun  5  2018 wireless-tools
lrwxrwxrwx 1 root root   32 Jun  6 06:16 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-pre-up.d:
total 8
-rwxr-xr-x 1 root root 4191 Sep 15  2018 wireless-tools
lrwxrwxrwx 1 root root   32 Jun  6 06:16 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-up.d:
total 4
-rwxr-xr-x 1 root root 484 Apr 27  2018 avahi-daemon
lrwxrwxrwx 1 root root  32 Jun  6 06:16 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ifupdown depends on:
ii  adduser   3.118
ii  iproute2  4.20.0-2
ii  libc6 2.28-10
ii  lsb-base  10.2019051400

Versions of packages ifupdown recommends:
pn  isc-dhcp-client | dhcp-client  

Versions of packages ifupdown suggests:
ii  ppp 2.4.7-2+4.1
pn  rdnssd  

-- no debconf information

Bug#931900: Program crashes with message "free(): double free detected in tcache 2"

[Bernhard Übelacker]

Hello 
the issue you observed might be already reported in:
https://bugs.debian.org/924925

Kind regards,
Bernhard

Bug#931914: octave-octproj: FTBFS with PROJ 6

[Bas Couwenberg]

Source: octave-octproj
Version: 1.1.5-4
Severity: important
Tags: upstream patch
User: debian-...@lists.debian.org
Usertags: proj-6

Dear Maintainer,

Your package FTBFS with PROJ 6 from experimental.

The attached patch fixes the issue by defining 
ACCEPT_USE_OF_DEPRECATED_PROJ_API_H.

Note that this is only a temporary workaround, proj_api.h will be
removed in PROJ 7 scheduled for March 2020.

Upstream is aware of the issue, see:

 https://savannah.gnu.org/bugs/index.php?56039

Kind Regards,

Bas
diff -Nru octave-octproj-1.1.5/debian/patches/proj6.patch 
octave-octproj-1.1.5/debian/patches/proj6.patch
--- octave-octproj-1.1.5/debian/patches/proj6.patch 1970-01-01 
01:00:00.0 +0100
+++ octave-octproj-1.1.5/debian/patches/proj6.patch 2019-03-08 
15:16:34.0 +0100
@@ -0,0 +1,24 @@
+Description: Define ACCEPT_USE_OF_DEPRECATED_PROJ_API_H for PROJ 6.0.0 
compatibility
+Author: Bas Couwenberg 
+Bug: https://savannah.gnu.org/bugs/index.php?56039
+
+--- a/src/Makefile
 b/src/Makefile
+@@ -11,7 +11,7 @@ CFLAGS+=-Wstrict-prototypes -Wnested-ext
+ #Flags for C++
+ CXXFLAGS=$(FLAGSCOMW) $(FLAGSCOMO)
+ #Flags for the linker
+-LDFLAGS=-lproj
++LDFLAGS=-lproj -DACCEPT_USE_OF_DEPRECATED_PROJ_API_H
+ #Export flags for compilers and linker
+ export CFLAGS CXXFLAGS
+ 
+@@ -20,7 +20,7 @@ all: compile
+ 
+ .PHONY: compile
+ compile:
+-  $(MKOCTFILE) -c projwrap.c -o projwrap.o
++  $(MKOCTFILE) -c projwrap.c -o projwrap.o 
-DACCEPT_USE_OF_DEPRECATED_PROJ_API_H
+   $(MKOCTFILE) -g _op_transform.cc projwrap.o $(LDFLAGS)
+   $(MKOCTFILE) -g _op_fwd.cc projwrap.o $(LDFLAGS)
+   $(MKOCTFILE) -g _op_inv.cc projwrap.o $(LDFLAGS)
diff -Nru octave-octproj-1.1.5/debian/patches/series 
octave-octproj-1.1.5/debian/patches/series
--- octave-octproj-1.1.5/debian/patches/series  2018-12-30 22:01:14.0 
+0100
+++ octave-octproj-1.1.5/debian/patches/series  2019-03-08 15:16:34.0 
+0100
@@ -1 +1,2 @@
 do-not-strip-debugging-symbols.patch
+proj6.patch

Bug#931844: libqt5gui5: Endless loop in konsole showing midnight commander with activated orca screenreader.

[Dmitry Shachnev]

Hi Bernhard!

On Fri, Jul 12, 2019 at 12:57:20AM +0200, Bernhard Übelacker wrote:
> Dear Maintainer,
> I created an upstream bug report and forward this bug to it.

Thanks for doing that! I have subscribed now, and when there is an
upstream fix, I will backport it.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#931913: aptitude: The certificate is NOT trusted when using https to fetch packages from security.debian.org in buster

[JL Lee]

Package: aptitude
Version: 0.8.11-7
Severity: normal

Dear Maintainer,

After a fresh install of buster on my notebook, I installed the package 
"aptitude" to manage my packages.

It reported to me there was an update (firefox-esr) available. At thispoint I 
exited the app and changed the sources.list file entries to make all future 
updates via https, instead of the default http.

When I run the aptitude app and did an update, it reports the following:

Failed to download some files

W: Failed to fetch 
https://security.debian.org/debian-security/dists/buster/updates/Release: 
Certificate verification failed. The certificate is NOT trusted...

E: Some index files failed to download. They have been ignored, or old one used 
instead.

The warning goes away if I changed back to http instead of https for the 
entries to security.debian.org in sources.list.



Thanks for your attention.

Lee 
 



-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.11
Compiler: g++ 8.2.0
Compiled against:
  apt version 5.0.2
  NCurses version 6.1
  libsigc++ version: 2.10.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.1.20181013
  cwidget version: 0.5.17
  Apt version: 5.0.2

aptitude linkage:
linux-vdso.so.1 (0x7ffe1419e000)
libapt-pkg.so.5.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7f28dc9f5000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7f28dc9bb000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f28dc98d000)
libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f28dc984000)
libcwidget.so.3 => /lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f28dc87e000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f28dc75c000)
libboost_iostreams.so.1.67.0 => 
/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7f28dc73c000)
libboost_system.so.1.67.0 => 
/lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7f28dc735000)
libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f28dc509000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f28dc4e8000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f28dc364000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f28dc1e1000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f28dc1c5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f28dc004000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f28dbfea000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f28dbdcc000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f28dbdb9000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f28dbd91000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7f28dbd7)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7f28dbcd)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f28dbcaa000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7f28dbc09000)
/lib64/ld-linux-x86-64.so.2 (0x7f28dd026000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f28dbc04000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f28dbbf8000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f28dbbef000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7f28dbad1000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7f28dbaae000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.11-7
ii  libapt-pkg5.0 1.8.2
ii  libboost-iostreams1.67.0  1.67.0-13
ii  libboost-system1.67.0 1.67.0-13
ii  libc6 2.28-10
ii  libcwidget3v5 0.5.17-11
ii  libgcc1   1:8.3.0-6
ii  libncursesw6  6.1+20181013-2
ii  libsigc++-2.0-0v5 2.10.1-2
ii  libsqlite3-0  3.27.2-3
ii  libstdc++68.3.0-6
ii  libtinfo6 6.1+20181013-2
ii  libxapian30   1.4.11-1

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-13
ii  sensible-utils 0.0.12

Versions of packages aptitude suggests:
pn  apt-xapian-index
pn  aptitude-doc-en | aptitude-doc  
pn  debtags 
ii  tasksel 

Bug#928931: The inability to use apt-setup/local0/repository makes it impossible to upgrade to Debian 10

[Cyril Brulebois]

Hi Magnus,

Magnus Määttä  (2019-07-12):
> I'm also having this issue which is making it impossible to upgrade to
> Debian 10 from Debian 9.
> 
> I'm depending on the possibility to add a repo during PXE-boot. Using
> late-commands is not an option as there doesn't seem to be any
> $selected_packages variable I can use to actually install the packages
> selected during installtion, while ignoring the fact that it's going
> to try to install them without the repo available, making the
> installation fail anyway.
> 
> Someone gave the recommendation to use different preseed files, but
> that also is not an option as the boot menu would need to have 50-100
> entries to accommodate for the most common options of package
> selections (which will make the size of the installation vary between
> 15GB and 80GB).
> 
> So for us, this is a real show stopper for using Debian 10 as it makes
> it impossible to install (manual installation is not an option)..

We're aware of the issue and we've already sketched out an outline to
get the fix into unstable (then migration to testing) but also into a
point release.

“Me too”-like messages mean distraction and wasted time, so it would be
great if we could avoid getting more of them.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#931845: Cannot install solr-tomcat when building docker image

[Emmanuel Bourg]

Le 12/07/2019 à 09:31, Aki Tuomi a écrit :

> Seems that this can be worked around with setting during installation
> SYSTEMCTL_INSTALL_CLIENT_SIDE=1 SYSTEMCTL_FORCE_BUS=1 SYSTEMD_OFFLINE=1

As I understand from the systemd documentation [1] this disables the
interactions with PID 1, so I guess it can only be used in a docker
environment otherwise the service will end in a weird state. Does it
work if you declare these variables in the dockerfile?

Emmanuel Bourg

[1] https://systemd.io/ENVIRONMENT.html

Bug#928931: The inability to use apt-setup/local0/repository makes it impossible to upgrade to Debian 10

[Philipp Huebner]

Hi,

> I'm also having this issue which is making it impossible to upgrade to
> Debian 10 from Debian 9.
> 
> I'm depending on the possibility to add a repo during PXE-boot. Using
> late-commands is not an option as there doesn't seem to be any
> $selected_packages variable I can use to actually install the packages
> selected during installtion, while ignoring the fact that it's
> going to try to install them without the repo available, making the
> installation fail anyway.

what about the other suggested workaround of simply adding the line

"d-i base-installer/includes string gnupg" to your preseed file?

Or if that's in use already you could use the early command like this:

d-i preseed/early_command string mkdir -p
/usr/lib/apt-setup/generators/; echo -e '#!/bin/sh\nchroot $ROOT apt-get
--yes --no-install-recommends install gnupg' >
/usr/lib/apt-setup/generators/59local; chmod a+x
/usr/lib/apt-setup/generators/59local


That said, I would also love to see this issue solved properly.


Best wishes
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#931912: Please do not Depends/Recommends against gnome-icon-theme

[Laurent Bigonville]

Package: info
Version: 6.6.0.dfsg.1-2
Severity: normal

Hi,

I see that the info package Recommends gnome-icon-theme, I don't think
it's a good idea.

gnome-icon-theme is not maintained anymore. Also I don't think it's up
to a leaf application to define the icon theme that should be installed.

The best solution is to use a xdg icon name and expect that the user
will have an icon theme installed.

If you want a "light bulb" icon, you should probably use the name
"dialog-information" icon which is part of the xdg standard (see
https://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html)

I see this icon being part of most of the icon theme.

Kind regards,

Laurent Bigonville

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages info depends on:
ii  install-info  6.6.0.dfsg.1-2
ii  libc6 2.28-10
ii  libtinfo6 6.1+20181013-2

Versions of packages info recommends:
ii  gnome-icon-theme  3.12.0-3

Versions of packages info suggests:
pn  texinfo-doc-nonfree  

-- no debconf information

Bug#931911: user-setup: Fails to present no-root-password_first-user-sudoer option as a reasonable choice

[Philip Hands]

Package: user-setup
Severity: normal

Prompted by this LWN comment relating to installing buster:

  https://lwn.net/Articles/792960/

  "The installer text specifically said that not setting a root password
   was a Very Bad Idea"

looking at the text in question, I was surprised at how negative it is
about the completely reasonable choice of selecting no root password in
order to provoke the first-user-is-sudoer setup.

  
https://salsa.debian.org/installer-team/user-setup/blob/master/debian/user-setup-udeb.templates#L37

I presume that this text is as it is because there is a previously
defined question about whether one wants a root login enabled, that
explains the way things will work with sudo if one chooses 'no':

  
https://salsa.debian.org/installer-team/user-setup/blob/master/debian/user-setup-udeb.templates#L25

however, that question is no longer presented to users by default, so
they get dropped into the rather scary sounding text about why one needs
to set a root password.

It seems to me that we need to reword this completely, so that choosing
to leave the password blank is described as a reasonable thing to do,
which will result in a perfectly decent, and often desired, sudo setup.

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

Bug#931909: Typo: spellshecking

[Uwe Kleine-König]

Package: roundcube
Version: 1.2.3+dfsg.1-4+deb9u3
Severity: minor

Hello,

I just noticed a typo in the word spellchecker (:-)) in
/etc/roundcube/config.inc.php.

s/spellshecking/spellchecking/

Best regards
Uwe

Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

[Michel Dänzer]

On 2019-07-11 6:49 p.m., user...@yahoo.com wrote:
> 
> b) I was not able to install Michel's patch -- I wasn't sure what
> compile or other options to use.  It looks like I could build a new
> kernel with that (patched) module; would that be the best way to include
> the patch?  I see that a commit was made yesterday (Jul 10) related to
> the patch, so I can just wait and test it when it's available in Debian
> sid, or I can build a new kernel with the patch included.  Please advise.

It's an xf86-video-mach64 / xserver-xorg-video-mach64 patch, not a
kernel one. And yes, it's been merged to upstream Git master:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-mach64/commit/37498721a520cd1cff367bc36b1ac74b343826ca


-- 
Earthling Michel Dänzer   |  https://www.amd.com
Libre software enthusiast | Mesa and X developer

Bug#899413: texlive-latex-extra: beamerthemeAachen.sty is missing package tangocolors

[Hilmar Preuße]

Hi Tobias,

> \RequirePackage{tangocolors}
> 
> but tangocolors.sty is nowhere to be found...

Nor is it on CTAN, so we (upstream TeX Live) cannot package it.

You might try to ask the author to upload it to CTAN, here is a link
to one of the files with an email of the author. When it is on CTAN, it
will enter into TeX Live, and via that finds it
way into Debian ;-)

http://legacydirs.umiacs.umd.edu/~jiarong/poster/icml12-inferning/styles/tangocolors.sty

We could also go the the way round and blacklist beamerthemeAachen.sty
in TL, i.e. remove broken/incomplete style files from Debian.

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#659772: landscape sciposter + hyperref + latex + dvips = center-mirrored image

[Hilmar Preuße]

Dear Michael,

We have not heard some time from you. I'm wondering whether some
progress has been done on the new sciposter release that could
potentially solve the problem?

Many thanks in advance,

Hilmar

On 13.07.2012 09:22, Michael H.F. Wilkinson wrote:
> Could be that I should either try to detect the usage of hyperref, or
> add a "hyperref option to sciposter.cls
>
> This mail was not sent to all involved, so here a repeat:
>
> This all chimes with my hunch that the postscript "specials" in the
> sciposter.cls code (inherited from a4poster) might be the problem. I
> have been working on a version 2.0 of sciposter.cls, and someone kindly
> sent me code replacing the page-setup code of sciposter with the calls
> to the geometry package. I will test if that solves the problem. As my
> personal beta version has been tested by quite a few and seems rock
> solid in other respects, I shall try to get a release version with
> manual ready. As I am overwhelmed by last minute exam stuff at work, I
> do not know whether I can do this before the summer vacation (starting
> July 21 for us).
>
> Cheers
>
> Michael
>
>
>
> On 13 July 2012 09:17, Frank Kuester  > wrote:
>
> Heiko Oberdiek  > writes:
>
>  > The PostScript language allows the setting of the page size:
>  > operator `setpagedevice', entry `PageSize', but entry `Orientation'
>  > is only intended for roll-fed media. Also there is no easy way
>  > to extract these data without a PostScript interpreter.
>  > At least there are DSC-comments that allows the specification
>  > of the page size and orientation. Thus there are several ways
>  > for specifying (partly also version dependent) and some will
>  > work on somewhere and others somewhere else.
>  >   Even worse if the width is greater than the height. That seems
>  > to be the main problem here.
>
> In other words, this is neither a bug in one of the involved packages,
> nor in dvips.  However, I fancy, it could be worked around if sciposter
> had some code for interaction with hyperref?
>
> Is this true?
>
> Regards, Frank
>
>


-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#928931: The inability to use apt-setup/local0/repository makes it impossible to upgrade to Debian 10

[Magnus Määttä]

Hi,

I'm also having this issue which is making it impossible to upgrade to 
Debian 10 from Debian 9.


I'm depending on the possibility to add a repo during PXE-boot. Using 
late-commands is not an option as there doesn't seem to be any
$selected_packages variable I can use to actually install the packages 
selected during installtion, while ignoring the fact that it's
going to try to install them without the repo available, making the 
installation fail anyway.


Someone gave the recommendation to use different preseed files, but that 
also is not an option as the boot menu would need to have
50-100 entries to accommodate for the most common options of package 
selections (which will make the size of the installation vary between

15GB and 80GB).

So for us, this is a real show stopper for using Debian 10 as it makes 
it impossible to install (manual installation is not an option)..



/Magnus

Bug#921820: fwupd: provide a network service file

[Mario.Limonciello]

I think for some people downloading metadata automatically in a timer/cron type 
way, may be useful but I think it's missing the last piece of integration to 
notify folks; motd messaging to let people know updates are available.

Would you please consider bringing this discussion upstream?  I think this even 
makes sense outside of Debian and would like to see it implemented in a future 
fwupd release directly.

> -Original Message-
> From: Ritesh Raj Sarraf  On Behalf Of Ritesh Raj Sarraf
> Sent: Thursday, July 11, 2019 6:53 AM
> To: Debian Bug Tracking System
> Subject: Bug#921820: fwupd: provide a network service file
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupd
> Version: 1.2.5-2
> Followup-For: Bug #921820
> 
> Hello Mario,
> 
> You also need to acknowledge the fact that there are many more users beyond
> the GNOME desktop. And then there's also the minimal, server and remote
> users. fwupd can work perfectly for those use cases.
> 
> Attached is a .service and a .timer file for this use case.
> 
> Please consider integrating them into the package.
> 
> And below is the results:
> 
> 
> Jul 11 19:10:05 priyasi systemd[1]: Starting Daily fwupd download 
> activities...
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: XPS 13 9370 System Firmware has
> firmware updates:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: GUID:
> 7ceaf7a8-0611-4480-
> 9e30-64d8de420c7c
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: ID:
> com.dell.uefi7ceaf7a8.firmware
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Version:  0.1.10.0
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Name: XPS 13 9370
> System Update
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Summary:  Firmware for
> the Dell XPS 13 9370
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Remote ID:lvfs
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Checksum:
> SHA1(ffeea823f8af0e10084c8db90bfd066ff80c4580)
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Location:
> https://fwupd.org/downloads/19395e228ff2e832797d74a5a9afaf6574f21ca7-
> XPS_9370_1.10.0.cab
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Description:  This stable
> release fixes the following issues:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: ID:
> com.dell.uefi7ceaf7a8.firmware
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Version:  0.1.9.0
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Name: XPS 13 9370
> System Update
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Summary:  Firmware for
> the Dell XPS 13 9370
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Remote ID:lvfs
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Checksum:
> SHA1(754e29b7c26299d10aa1069cc42e9d65cc318876)
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Location:
> https://fwupd.org/downloads/694da421c22f0f6457a820ce0f77ce29465de32f-
> XPS_9370_1.9.0.cab
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Description:  This stable
> release fixes the following issues:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:   • Firmware 
> updates to
> address security advisories INTEL-SA-00191(CVE-2018-12201, CVE-2018- 12202,
> CVE-2018-12203).
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:   • Fixed an 
> issue with
> Secure Boot Option ROM Signature Verification.
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:   • Not 
> Applicable.
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: ID:
> com.dell.uefi7ceaf7a8.firmware
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Version:  0.1.8.1
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Name: XPS 13 9370
> System Update
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Summary:  Firmware for
> the Dell XPS 13 9370
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Remote ID:lvfs
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Checksum:
> SHA1(d0fb3e0b49f70fb4bc07790a70073306fa356fa3)
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Location:
> https://fwupd.org/downloads/3730feea49972ec78c61a8776dd518f2ffa98403-
> Signed_1152921504627936323.cab
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Description:  This stable
> release fixes the following issues:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:  system is 
> started with
> Dell Thunderbolt Dock TB16 connected to it
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:   • This 
> update integrates
> the BIOSConnect feature into Dell SupportAssist OS Recovery. This feature
> connects 　the system to the Dell image server to download and recover the
> operating system
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:
> Jul 11 19:10:05 

Bug#931895: [b...@transient.nz: Bug#931895: unzip: zip bomb false positives in Java ecosystem]

[Santiago Vila]

Hello.

I applied your fix for the zip bomb issue to the Debian unzip package
and shortly afterwards I received this bug report from one of our users
(Ben Caradoc-Davies, in the Cc).

(Note: Our BTS is email-based, but I could also put an issue on github
if you prefer).

The full report is available here:

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

Thanks.

- Forwarded message from Ben Caradoc-Davies  -

Date: Fri, 12 Jul 2019 11:52:14 +1200
From: Ben Caradoc-Davies 
To: Debian Bug Tracking System 
Subject: Bug#931895: unzip: zip bomb false positives in Java ecosystem
X-Mailer: reportbug 7.5.2

Package: unzip
Version: 6.0-24
Severity: normal

Dear Maintainer,

zip bomb detection introduced in 6.0-24 (see #931433
 and CVE-2019-13232)
causes unzip to reject many jar files distributed in the Java ecosystem.

Workaround is to downgrade to unzip 6.0-23.

Examples:

$ find .gradle .m2 java -name "*.jar" -type f -size +0c -print -exec unzip -tq
{} \; 2>&1 | grep -B1 invalid
.gradle/wrapper/dists/gradle-5.2.1-bin/9lc4nzslqh3ep7ml2tp68fk8s/gradle-5.2.1/lib/groovy-
all-1.0-2.5.4.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.gradle/wrapper/dists/gradle-5.4.1-bin/e75iq110yv9r9wt1a6619x2xm/gradle-5.4.1/lib/gradle-
kotlin-dsl-5.4.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.gradle/wrapper/dists/gradle-5.4.1-bin/e75iq110yv9r9wt1a6619x2xm/gradle-5.4.1/lib/plugins/gradle-
kotlin-dsl-tooling-builders-5.4.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.gradle/wrapper/dists/gradle-5.4.1-bin/e75iq110yv9r9wt1a6619x2xm/gradle-5.4.1/lib/plugins/gradle-
kotlin-dsl-provider-plugins-5.4.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.gradle/wrapper/dists/gradle-5.4.1-bin/e75iq110yv9r9wt1a6619x2xm/gradle-5.4.1/lib/groovy-
all-1.0-2.5.4.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/ow2/asm/asm-tree/5.0.3/asm-tree-5.0.3-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/ow2/asm/asm-util/5.0.3/asm-util-5.0.3-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/ow2/asm/asm/5.0.3/asm-5.0.3-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/ow2/asm/asm-analysis/5.0.3/asm-analysis-5.0.3-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/springframework/spring-orm/4.2.5.RELEASE/spring-
orm-4.2.5.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/springframework/spring-orm/4.3.7.RELEASE/spring-
orm-4.3.7.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/springframework/spring-beans/4.3.16.RELEASE/spring-
beans-4.3.16.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/springframework/spring-beans/4.2.5.RELEASE/spring-
beans-4.2.5.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/springframework/spring-beans/4.3.18.RELEASE/spring-
beans-4.3.18.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/springframework/spring-beans/4.3.7.RELEASE/spring-
beans-4.3.7.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
java/gradle-5.5.1/lib/plugins/gradle-kotlin-dsl-tooling-builders-5.5.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
java/gradle-5.5.1/lib/plugins/gradle-kotlin-dsl-provider-plugins-5.5.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
java/gradle-5.5.1/lib/gradle-kotlin-dsl-5.5.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
java/gradle-5.5.1/lib/groovy-all-1.0-2.5.4.jar
error: invalid zip file with overlapped components (possible zip bomb)

Kind regards,
Ben.



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

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

Versions of packages unzip depends on:
ii  libbz2-1.0  1.0.6-9.2
ii  libc6   2.28-10

unzip recommends no packages.

Versions of packages unzip suggests:
ii  zip  3.0-11+b1

-- no debconf information

- End forwarded message -

Bug#931845: Cannot install solr-tomcat when building docker image

[Aki Tuomi]

On 11.7.2019 18.01, Markus Koschany wrote:
> Hello,
>
> this issue is caused by the command systemctl daemon-reload in
> solr-tomcat's postinst file. You can try to remove it and see if it
> works. However solr-tomcat is supposed to work in a systemd environment,
> I doubt that anyone has tested it with another init system or without one.
>
> Regards,
>
> Markus
>
Seems that this can be worked around with setting during installation
SYSTEMCTL_INSTALL_CLIENT_SIDE=1 SYSTEMCTL_FORCE_BUS=1 SYSTEMD_OFFLINE=1

Aki

Bug#931908: RM: libgeo-proj4-perl -- ROM; FTBFS with PROJ 6

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
Control: block -1 by 931906 931907

Please remove libgeo-proj4-perl from the archive, it FTBFS with PROJ 6
and is unlikely to get fixed upstream.

Kind Regards,

Bas

Bug#931907: RM: libgeo-point-perl -- ROM; Depends on Geo::Proj4 which FTBFS with PROJ 6

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove libgeo-point-perl from the archive, it requires Geo::Proj4
which FTBFS with PROJ 6.

Kind Regards,

Bas

Bug#931906: RM: libosm-gary68-perl -- ROM; Dead upstream, depends on Geo::Proj4 which FTBFS with PROJ 6

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
Control: block -1 by 931905

Please remove libosm-gary68-perl from the archive, it's dead upstream
and depends on Geo::Proj4 which FTBFS with PROJ 6.

Kind Regards,

Bas

Bug#931905: RM: rel2gpx -- ROM; Dead upstream, depends on Geo::Proj4 which FTBFS with PROJ 6

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove rel2gpx from the archive, it's dead upstream and depends
on Geo::Proj4 which FTBFS with PROJ 6.

Kind Regards,

Bas

Bug#931904: RM: gpx2shp -- ROM; Dead upstream, FTBFS with PROJ 6

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove gpx2shp from the archive, it's dead upstream for quite a
while and FTBFS with PROJ 6.

Kind Regards,

Bas

Bug#931903: node-acorn: fails to upgrade from 'sid' - trying to overwrite /usr/lib/nodejs/acorn-dynamic-import/lib/index.js

[Andreas Beckmann]

Package: node-acorn
Version: 
6.0.2+20181021git007b08d01eff070+ds+~0.3.1+~4.0.0+~0.3.0+~5.0.0+ds+~1.6.1+ds-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack 
.../node-acorn_6.0.2+20181021git007b08d01eff070+ds+~0.3.1+~4.0.0+~0.3.0+~5.0.0+ds+~1.6.1+ds-1_all.deb
 ...
  Unpacking node-acorn 
(6.0.2+20181021git007b08d01eff070+ds+~0.3.1+~4.0.0+~0.3.0+~5.0.0+ds+~1.6.1+ds-1)
 over (5.5.3+ds3-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/node-acorn_6.0.2+20181021git007b08d01eff070+ds+~0.3.1+~4.0.0+~0.3.0+~5.0.0+ds+~1.6.1+ds-1_all.deb
 (--unpack):
   trying to overwrite '/usr/lib/nodejs/acorn-dynamic-import/lib/index.js', 
which is also in package node-acorn-dynamic-import 4.0.0-1
  Errors were encountered while processing:
   
/var/cache/apt/archives/node-acorn_6.0.2+20181021git007b08d01eff070+ds+~0.3.1+~4.0.0+~0.3.0+~5.0.0+ds+~1.6.1+ds-1_all.deb


cheers,

Andreas


node-acorn-dynamic-import=4.0.0-1_node-acorn=6.0.2+20181021git007b08d01eff070+ds+~0.3.1+~4.0.0+~0.3.0+~5.0.0+ds+~1.6.1+ds-1.log.gz
Description: application/gzip

Bug#931902: cflow-doc,cflow-l10n: missing Breaks+Replaces: cflow (<< 1:1.6-2)

[Andreas Beckmann]

Package: cflow-doc,cflow-l10n
Version: 1:1.6-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../cflow-doc_1%3a1.6-2_all.deb ...
  Unpacking cflow-doc (1:1.6-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/cflow-doc_1%3a1.6-2_all.deb (--unpack):
   trying to overwrite '/usr/share/info/cflow.info.gz', which is also in 
package cflow 1:1.6-1
  Errors were encountered while processing:
   /var/cache/apt/archives/cflow-doc_1%3a1.6-2_all.deb

  Preparing to unpack .../cflow-l10n_1%3a1.6-2_all.deb ...
  Unpacking cflow-l10n (1:1.6-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/cflow-l10n_1%3a1.6-2_all.deb (--unpack):
   trying to overwrite '/usr/share/locale/da/LC_MESSAGES/cflow.mo', which is 
also in package cflow 1:1.6-1
  Errors were encountered while processing:
   /var/cache/apt/archives/cflow-l10n_1%3a1.6-2_all.deb


cheers,

Andreas


cflow=1:1.6-1_cflow-doc=1:1.6-2.log.gz
Description: application/gzip

Bug#931901: linux-image-4.19.0-5-amd64: incorrectly identifies some old Radeon HD as newer, preventing X from starting

[Phil Reynolds]

Package: src:linux
Version: 4.19.37-5
Severity: important

Dear Maintainer,

I did a clean install of buster to my Lenovo Thinkpad X131e-AMD, but the kernel
thinks the onboard Radeon HD 6310 is a newer card (newer than R600), requiring
firmware to support modeswitching (KMS). However, this is incorrect.

I did try, for good measure, installing the supposedly-appropriate firmware
package, but this was, of course, ineffective.

The only fix was to install the kernel from stretch. This machine worked on
stretch without a problem. This does allow X to be started, which the kernel
from buster prevents.

The problem is similar to bug #927219.

I would not expect the kernel to break my setup in this way. This is a clear
kernel regression.

-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-5 (2019-06-19)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 root=/dev/mapper/wincobank--vg-root ro quiet

** Not tainted

** Kernel log:
[   27.076119] input: ThinkPad Extra Buttons as 
/devices/platform/thinkpad_acpi/input/input16
[   27.171785] cdc_wdm 2-2:1.5: cdc-wdm0: USB WDM device
[   27.172015] cdc_wdm 2-2:1.8: cdc-wdm1: USB WDM device
[   27.172076] usbcore: registered new interface driver cdc_wdm
[   27.194745] cdc_acm 2-2:1.1: ttyACM0: USB ACM device
[   27.202836] cdc_acm 2-2:1.3: ttyACM1: USB ACM device
[   27.205795] cdc_acm 2-2:1.9: ttyACM2: USB ACM device
[   27.208880] usbcore: registered new interface driver cdc_acm
[   27.208886] cdc_acm: USB Abstract Control Model driver for USB modems and 
ISDN adapters
[   27.307695] media: Linux media interface: v0.10
[   27.500890] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   27.505621] input: HD-Audio Generic HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.1/sound/card0/input17
[   27.517532] videodev: Linux video capture interface: v2.00
[   27.522564] cdc_ncm 2-2:1.6: MAC-Address: 02:15:e0:ec:01:00
[   27.523769] cdc_ncm 2-2:1.6 wwan0: register 'cdc_ncm' at usb-:00:13.2-2, 
Mobile Broadband Network Device, 02:15:e0:ec:01:00
[   27.523868] usbcore: registered new interface driver cdc_ncm
[   27.560877] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC269VC: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   27.560890] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   27.560895] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 
(0x15/0x0/0x0/0x0/0x0)
[   27.560898] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0
[   27.560900] snd_hda_codec_realtek hdaudioC1D0:inputs:
[   27.560905] snd_hda_codec_realtek hdaudioC1D0:  Mic=0x18
[   27.560908] snd_hda_codec_realtek hdaudioC1D0:  Internal Mic=0x12
[   27.582462] input: HDA Digital PCBeep as 
/devices/pci:00/:00:14.2/sound/card1/input18
[   27.584134] input: HD-Audio Generic Mic as 
/devices/pci:00/:00:14.2/sound/card1/input19
[   27.584285] input: HD-Audio Generic Headphone as 
/devices/pci:00/:00:14.2/sound/card1/input20
[   27.670306] usbcore: registered new interface driver cdc_mbim
[   27.691695] kvm: disabled by bios
[   28.125316] Bluetooth: Core ver 2.22
[   28.125363] NET: Registered protocol family 31
[   28.125365] Bluetooth: HCI device and connection manager initialized
[   28.125374] Bluetooth: HCI socket layer initialized
[   28.125379] Bluetooth: L2CAP socket layer initialized
[   28.125394] Bluetooth: SCO socket layer initialized
[   28.156370] uvcvideo: Found UVC 1.00 device Integrated Camera (04f2:b2fe)
[   28.166694] uvcvideo 2-4:1.0: Entity type for entity Processing 2 was not 
initialized!
[   28.166702] uvcvideo 2-4:1.0: Entity type for entity Camera 1 was not 
initialized!
[   28.166706] uvcvideo 2-4:1.0: Entity type for entity Extension 4 was not 
initialized!
[   28.166899] input: Integrated Camera: Integrated C as 
/devices/pci:00/:00:13.2/usb2/2-4/2-4:1.0/input/input21
[   28.167067] usbcore: registered new interface driver uvcvideo
[   28.167069] USB Video Class driver (1.1.1)
[   28.394955] cdc_ncm 2-2:1.6 wwp0s19f2u2i6: renamed from wwan0
[   28.653165] usbcore: registered new interface driver btusb
[   28.766532] Bluetooth: hci0: BCM: chip id 63
[   28.768795] Bluetooth: hci0: BCM: features 0x07
[   28.787391] Bluetooth: hci0: wincobank
[   28.789437] Bluetooth: hci0: BCM20702A1 (001.002.014) build 
[   29.048786] bluetooth hci0: firmware: failed to load 
brcm/BCM20702A1-0a5c-21f3.hcd (-2)
[   29.048908] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   29.049026] bluetooth hci0: Direct firmware load for 
brcm/BCM20702A1-0a5c-21f3.hcd failed with error -2
[   29.049034] Bluetooth: hci0: BCM: Patch brcm/BCM20702A1-0a5c-21f3.hcd not 
found
[   29.703716] Adding 3723260k swap on /dev/mapper/wincobank--vg-swap_1.  
Priority:-2 extents:1 across:3723260k FS
[   30.646372] EXT4-fs (dm-1): mounted filesystem with ordered data mode. 

Bug#931900: Program crashes with message "free(): double free detected in tcache 2"

[Alex Relis]

Package: projectm-pulseaudio
Version: 2.1.0+dfsg-4+b4
Severity: grave

Dear Maintainer,

First off, I'm new to the BTS so excuse me for not doing this right.
projectm-pulseaudio crashes after a few seconds in Buster. Typing "N" to
go to the next visualization effect crashes the program instantly. Here
is a log:

user@debian:~$ projectM-pulseaudio
dir:/usr/share/projectM/config.inp
reading ~/.projectM/config.inp
[projectM] config file: /home/user/.projectM/config.inp
No Textures Loaded from "/usr"/share/projectM/textures
[projectM] Allocating idle preset...
[PresetFactory] path is Geiss & Sperl - Feedback (projectM idle HDR
mix).milk
[PresetFactory] url is idle://Geiss & Sperl - Feedback (projectM idle
HDR mix).milk
unconnected: connecting...
connectHelper:  "alsa_output.pci-_00_1b.0.analog-stereo.monitor"
CREATED
READY
[PresetFactory] path is
r/share/projectM/presets/phat_CloseIncounetersV2.milk
[PresetFactory] url is
/usr/share/projectM/presets/phat_CloseIncounetersV2.milk
free(): double free detected in tcache 2
Aborted

Not a programmer so I really don't know what "free(): double free
detected in tcache 2", but I can only assume that's where the problem lies.

Thank you, and have a great day/night.

-Alex Relis

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

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

Versions of packages projectm-pulseaudio depends on:
ii  libc6  2.28-10
ii  libftgl2   2.4.0-2
ii  libgcc11:8.3.0-6
ii  libglew2.1 2.1.0-4
ii  libprojectm-qt1v5  2.1.0+dfsg-4+b4
ii  libprojectm2v5 2.1.0+dfsg-4+b4
ii  libpulse0  12.2-4
ii  libqt4-opengl  4:4.8.7+dfsg-18
ii  libqtcore4 4:4.8.7+dfsg-18
ii  libqtgui4  4:4.8.7+dfsg-18
ii  libstdc++6 8.3.0-6
ii  pulseaudio 12.2-4

projectm-pulseaudio recommends no packages.

projectm-pulseaudio suggests no packages.

-- no debconf information




signature.asc
Description: OpenPGP digital signature

Bug#931899: login: still tries to open /etc/securetty

[Sven Joachim]

Package: login
Version: 1:4.7-1

According to the Debian changelog, login has stopped honoring
/etc/securetty, but journalctl shows that it complains about the now
missing file:

,
| Jul 12 08:47:31 turtle login[1039]: pam_unix(login:auth): Couldn't open 
/etc/securetty: No such file or directory
| Jul 12 08:47:34 turtle login[1039]: pam_unix(login:auth): Couldn't open 
/etc/securetty: No such file or directory
| Jul 12 08:47:34 turtle login[1039]: pam_unix(login:session): session opened 
for user sven by LOGIN(uid=0)
| Jul 12 08:47:34 turtle systemd-logind[419]: New session 1 of user sven.
`

So why does login still try to open /etc/securetty?


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

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

Versions of packages login depends on:
ii  libaudit1   1:2.8.5-1
ii  libc6   2.28-10
ii  libpam-modules  1.3.1-5
ii  libpam-runtime  1.3.1-5
ii  libpam0g1.3.1-5

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#923200: libpolkit-qt5-1-1 depends on libpam-systemd

[Demi]

I have to agree with Joshua -- programs like marble or kdenlive work
just fine without systemd, but this dependency keeps them from doing
so.

Since I have a couple of boxes that are pretty heavily tinkered with
(which makes them unattractive for systemd), I just tried it, apt-get
source-d libpolkit-qt5-1-1, removed the libpam-systemd dependency in
both places in debian/rules, built and installed the package, and the
(few) kde applications I've tried installed and ran without problem.

So -- it may be that some component of kde actually depends on
systemd, but given the wide-ranging consequences of this particular
dependency (essentially shutting out non-systemd boxes from KDE
applications) it'd be great if the dependency could be limited to
that particular component.

Bug#930118: libconfig-model-dpkg-perl: adds debian/compat despite debhelper-compat

[Alex Muntada]

Hi Dominique,

> Come to think of it, I've detailed the fix mechanism (sorry
> for the headache), but, in the end, the 'cme fix' command will
> cascade the fixes to end up with 'debhelper-compat (= 12)'
> (or whatever latest release). This is similar to the current
> mechanism where a cme fix for an old compat sets compat (and
> delhelper) to latest compat value.

It makes perfect sense :) Good job!

Cheers,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature