Bug#754418: xml2 version 0.5 avaliable

[Ferran Jorba]

Hmmm, too bad. I have this file, but it also can be found as part of Fedora
and FreeBSD repositories:

https://www.google.cat/search?q=xml2-0.5.tar.gz

Please upgrade it.  It is such a useful tool, and I know no alternative!  I
keep it using, and the newer version fixes those Debian bugs.

Thanks,

Ferran


2017-08-05 2:20 GMT+02:00 Vincent Lefevre :

> Control: retitle -1 xml2 version 0.5 available
>
> On 2014-07-10 22:45:24 +0200, Ferran Jorba wrote:
> > version 0.5 of xml2 is available at http://download.ofb.net/gale/
> > since May 2011. It fixes, among other things, utf-8 issues filled
> > against Debian bug system.
>
> This URL is not longer valid, and xml2 no longer seems to exist
> upstream any longer.
>
> --
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>

Bug#870795: Make TJENER installation more flexible

[Mike Gabriel]

Package: debian-edu-install
Severity: wishlist

The observation when setting up a TJENER (main server profile) is that

  (a) netinst tries to configure/find its uplink via DHCP
  (b) our network gateway (10.0.0.1) must not run a DHCP server
  during normal operation

So when installing a TJENER from netinst, the hack is:

  (a) set up a gateway, with 10.0.0.1 on the "internal" side
  (b) enable a DHCP server o 10.0.0.1
  (c) install TJENER from netinst, IP config is obtained from DHCP
  (d) reboot TJENER when installation succeeded
  (e) disable DHCP server on 10.0.0.1 (gateway)
  (f) after reboot of TJENER, it takes over being the DHCP server

Proposals to make the above awkward workflow be handled more easily:

  (a) set up a gateway with 10.0.0.1 serving to the internal "Edu" network
  (b) DHCP server on the gateway is not needed, because...

  (c) D-I tries to obtain an ip addres during netinst (and fails as there is
  not DHCP server around
  (d) D-I continues silently after some delay
  (e) sysadmin choose mainserver profile
  (f) D-I realizes, network is still down, then tries 10.0.2.2 with  
gw 10.0.0.1,

  bail out with a red-screen if that fails
  (g) sysadmin chooses other profile, D-I bails out with a red-screen

  (h) TJENER installation hopefully succeeds, TJENER reboots and is  
ready for service


Required changes:

  * suppress D-I's network DHCP configuration failure at first

  (A) main server installation
  * attempt static network setup after profile selection, in case main-server
has been selected (10.0.2.2/8 with gw 10.0.0.1)
  * throw an error message if tried-out static IP of main-server  
cannot connect

to the internet

  (B) other profile installation
  * throw an error message about missing network connectivity after profile
selection dialog for non-main-server installations

Comments? Feedback?

Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpyGI5f6SEna.pgp
Description: Digitale PGP-Signatur

Bug#870794: document how to setup gateway for Debian Edu network

[Mike Gabriel]

Package: debian-edu-doc

Discussing with Holger some initial deployment issues of a Debian Edu  
site installation, we found that the setup of a proper Debian Edu  
gateway is not sufficiently documented.


Proposal:

  - use firewall appliance / distribution, recommended pfSense
  - two NICs, uplink configures via DHCP, downlink statically
configured as 10.0.0.1/8
  - firewall must not run a DHCP server at normal operation
  - currently, for netinst based TJENER installation, a DHCP
service must be temporarily provided on 10.0.0.1
  - after TJENER installation, that DHCP service must be disabled
and TJENER takes over serving DHCP to 10.0.0.0/8

Greets,
Mike

--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpRLlVCYJRgP.pgp
Description: Digitale PGP-Signatur

Bug#870664: hkl: build-depends on obsolete emacs24

[Rob Browning]

PICCA Frederic-Emmanuel 
writes:

> I need to work on the hkl library next week for my work.  I must
> backport this for jessie-backport. I think that I will use emacs
> instead of emacs25/emacs24

Assuming I'm remembering current policy correctly, if hkl depends on
emacsen-common (>= 2.0.8), and if it has opted-in to the newer
arrangement via /usr/lib/emacsen-common/packages/compat/ then
it doesn't have to depend on any Emacs flavor.

Though it won't hurt to depend on "emacs", assuming xemacs is irrelevant
(if not, it should probably be "emacsen").

But all that said, I suspect it's better off depending on emacs25 (if
there is a dependency), since the package might end up being
incompatible with Emacs 26.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#870772: libgsl misses some breaks/replaces

[Dirk Eddelbuettel]

On 5 August 2017 at 00:04, Alf Gaida wrote:
| Package: libgsl23
| Version: 2.4+dfsg-3
| Severity: grave
| Tags: patch
| 
| Dear Maintainer, 
| 
| like the subject says libgsl lacks some breaks and replaces, that breaks the 
upgrade path:
| 
| % LANG=C sudo apt -f install  
:(
| Reading package lists... Done
| Building dependency tree   
| Reading state information... Done
| Correcting dependencies... Done
| The following additional packages will be installed:
|   libgsl23
| Suggested packages:
|   gsl-ref-psdoc | gsl-doc-pdf | gsl-doc-info | gsl-ref-html
| The following NEW packages will be installed:
|   libgsl23
| 0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
| 28 not fully installed or removed.
| Need to get 0 B/914 kB of archives.
| After this operation, 2.887 kB of additional disk space will be used.
| Do you want to continue? [Y/n] y
| (Reading database ... 537126 files and directories currently installed.)
| Preparing to unpack .../libgsl23_2.4+dfsg-3_amd64.deb ...
| Unpacking libgsl23:amd64 (2.4+dfsg-3) ...
| dpkg: error processing archive 
/var/cache/apt/archives/libgsl23_2.4+dfsg-3_amd64.deb (--unpack):
|  trying to overwrite '/usr/lib/x86_64-linux-gnu/libgslcblas.so.0.0.0', which 
is also in package libgsl2:amd64 2.4+dfsg-2
| dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
| Errors were encountered while processing:
|  /var/cache/apt/archives/libgsl23_2.4+dfsg-3_amd64.deb
| E: Sub-process /usr/bin/dpkg returned an error code (1)
| 
| 
| The following should fix that
| 
| diff --git a/debian/control b/debian/control
| index 5e12819..486169d 100644
| --- a/debian/control
| +++ b/debian/control
| @@ -12,8 +12,9 @@ Architecture: any
|  Multi-Arch: same
|  Pre-Depends: ${misc:Pre-Depends}
|  Depends: ${shlibs:Depends}, ${misc:Depends}
| +Breaks: libgsl2
|  Conflicts: gsl, libgsl0, libgsl0ldbl
| -Replaces: gsl, libgsl0 (<= 1.9-4), libgsl0ldbl (<= 1.16+dfsg-4)
| +Replaces: gsl, libgsl0 (<= 1.9-4), libgsl0ldbl (<= 1.16+dfsg-4), libgsl2
|  Suggests: gsl-ref-psdoc | gsl-doc-pdf | gsl-doc-info | gsl-ref-html
|  Description: GNU Scientific Library (GSL) -- library package 
|   The GNU Scientific Library (GSL) is a collection of routines for
| 

Thanks for that.

One possibly alternative would be to put libgslcblas.so.0.0.0  into its own
libgslcblas depend on it as this library has no soname.  But it is probably
easier to go with 'Breaks: ' as you suggest.

The thing that is unpleasant is that we probably need to keep adding the old
soname libraries to debian/control as this progresses.

Dirk
 
| Cheers Alf
| 
| -- System Information:
| Debian Release: buster/sid
|   APT prefers buildd-unstable
|   APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental')
| Architecture: amd64 (x86_64)
| Foreign Architectures: i386
| 
| Kernel: Linux 4.12.4-towo.2-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
| Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
| Shell: /bin/sh linked to /bin/dash
| Init: systemd (via /run/systemd/system)
| 
| Versions of packages libgsl23 depends on:
| ii  libc6  2.24-14
| 
| libgsl23 recommends no packages.
| 
| Versions of packages libgsl23 suggests:
| pn  gsl-ref-psdoc | gsl-doc-pdf | gsl-doc-info | gsl-ref-html  
| 
| -- no debconf information

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#862522: cuda 9.0 RC available

[Andreas Beckmann]

Hi,

On 2017-08-05 05:18, Lumin wrote:
> At the time of this writing the CUDA 9 RC package is available
> for registered users.
Nice. What about GCC-7 support? It's the default compiler for 12 hours
now :-)

We have an updated version of 8.0.xx in svn - has anyone gotten around
to test it, yet? Should I upload it?


Andreas

Bug#854733: Zoneminder issues fixed? (was: Re: Bug#854733 tagged as pending)

[Salvatore Bonaccorso]

Hi Chris,

On Wed, Aug 02, 2017 at 07:19:17PM +, Chris Lamb wrote:
> commit b56cefec7cd8ec186e9662a5c5f0c3ada030d456
> Author: Chris Lamb 
> Date:   Wed Aug 2 15:15:04 2017 -0400
> 
> New upstream release. (Closes: #854272, #854733)

The recent upload to unstable claims to fix several CVEs. While for
#854733 this is the case for CVE-2017-5595, I fail to find fixing
commits for the other two CVEs from that bug. Where are they fixed?
Can you help identifying the commits?

Similarly for #854272. all of those were reported to upstream without
response. A quick search does not lead me to aany commits later than
1.30 upstream.

if so can you update the security-tracker indicating the fixing
commits for the individual CVEs?

thanks already!

Regards,
Salvatore

Bug#859778: [supp...@mentors.debian.net: xtrs uploaded to mentors.debian.net]

[G. Branden Robinson]

At 2017-07-27T13:50:53-0700, Sean Whitton wrote:
> Hello Branden,
> 
> On Thu, Jun 15, 2017 at 04:35:23PM +0100, Sean Whitton wrote:
> > Please accept my apologies for letting this RFS sit for so long.  Thank
> > you for all your work.  Looking forward to uploading it soon.
> > 
> > Here's a full review of dc84e1861798b3aba0969e2fe81a2431f2ee17de:
> 
> Any progress on this?

Hi Sean,

Not much, as I've had a few distractions lately.  However, I do hope to
be able to make some progress on these items this coming week at
DebConf.  Not sure if you were aware, but I'll be there.  Since I see
your name in the keysigning-party keyring, I hope to meet you in person.

Looking forward to it!

Regards,
Branden


signature.asc
Description: PGP signature

Bug#862522: cuda 9.0 RC available

[Lumin]

Hello guys,

At the time of this writing the CUDA 9 RC package is available
for registered users. You can see the RC link in their main page:

https://developer.nvidia.com/cuda-toolkit

https://developer.nvidia.com/cuda-release-candidate-download

I'll try to make a patch for the 9.0 RC (9.0.103) version for amd64.

Bug#862602: Pending fixes for bugs in the core-cache-clojure package

[pkg-clojure-maintainers]

tag 862602 + pending
thanks

Some bugs in the core-cache-clojure package are closed in revision
cd2e3e05030bc35ad66bc57fe2a353fc4f8b5045 in branch 'master' by
Apollon Oikonomopoulos

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-clojure/core-cache-clojure.git/commit/?id=cd2e3e0

Commit message:

(Build-)Depend on data.priority-map

Closes: #862602

Bug#870791: gsequencer: musescore-soundfont-gm -> timgm6mb-soundfont

[Thorsten Glaser]

Source: gsequencer
Severity: normal

Hi,

please update the Suggests so it still works after removal
of the transitional package — the old soundfont was renamed.

Thanks!

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

Kernel: Linux 4.11.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Bug#870793: libsdl2-mixer-2.0-0: musescore-soundfont-gm -> timgm6mb-soundfont

[Thorsten Glaser]

Package: libsdl2-mixer-2.0-0
Severity: normal

Hi,

please update the Recommends so it still works after removal
of the transitional package — the old soundfont was renamed.

Thanks!

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

Kernel: Linux 4.11.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libsdl2-mixer-2.0-0 depends on:
ii  libc6   2.24-14
ii  libflac81.3.2-1
ii  libfluidsynth1  1.1.6-4
ii  libmad0 0.15.1b-8+b2
ii  libmodplug1 1:0.8.8.5-3
ii  libsdl2-2.0-0   2.0.5+dfsg1-3
ii  libvorbis0a 1.3.5-4
ii  libvorbisfile3  1.3.5-4

Versions of packages libsdl2-mixer-2.0-0 recommends:
ii  fluid-soundfont-gm  3.1-5.1

libsdl2-mixer-2.0-0 suggests no packages.

Bug#870792: libsdl-mixer1.2: musescore-soundfont-gm -> timgm6mb-soundfont

[Thorsten Glaser]

Package: libsdl-mixer1.2
Severity: normal

Hi,

please update the Recommends so it still works after removal
of the transitional package — the old soundfont was renamed.

Thanks!

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

Kernel: Linux 4.11.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libsdl-mixer1.2 depends on:
ii  libc62.24-14
ii  libflac8 1.3.2-1
ii  libfluidsynth1   1.1.6-4
ii  libmad0  0.15.1b-8+b2
ii  libmikmod3   3.3.11.1-1
ii  libsdl1.2debian  1.2.15+dfsg2-0.1
ii  libvorbis0a  1.3.5-4
ii  libvorbisfile3   1.3.5-4

Versions of packages libsdl-mixer1.2 recommends:
ii  fluid-soundfont-gm  3.1-5.1

libsdl-mixer1.2 suggests no packages.

Bug#870790: vlc-plugin-fluidsynth: musescore-soundfont-gm -> timgm6mb-soundfont

[Thorsten Glaser]

Package: vlc-plugin-fluidsynth
Severity: normal

Hi,

please update the dependency so it still works after removal
of the transitional package — the old soundfont was renamed.

Thanks!

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

Kernel: Linux 4.11.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages vlc-plugin-fluidsynth depends on:
ii  fluid-soundfont-gm  3.1-5.1
ii  libc6   2.24-14
ii  libfluidsynth1  1.1.6-4
pn  libvlccore8 

vlc-plugin-fluidsynth recommends no packages.

vlc-plugin-fluidsynth suggests no packages.

Bug#860396: retitle mozjs38 ITP to mozjs52

[Jeremy Bicha]

Control: retitle -1 ITP: mozjs52 -- SpiderMonkey JavaScript library

The Debian GNOME team is skipping mozjs38 and going straight to
mozjs52. mozjs52 is part of GNOME 3.26 and is the JavaScript engine
from Firefox 52 ESR, the only ESR supported at this time.

The packaging is derived from Debian's mozjs24 packaging.

The debian/copyright is from Firefox but with parts that don't apply
to this smaller source package removed.

Thanks,
Jeremy Bicha

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Sean Whitton]

Hello,

On Fri, Aug 04 2017, Adrian Bunk wrote:

> Autogenerating Uploaders like GNOME does [1] would be an alternative
> approach.
>
> [1]
> https://sources.debian.net/src/gnome-pkg-tools/0.19.9/1/rules/uploaders.mk/

I don't understand this suggestion.  If it can be automatically
generated, just generate it when you need it -- why store it in the
source package?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#870789: HTML::Gumbo documentation: Perl error in callback example

[Vincent Lefevre]

Package: libhtml-gumbo-perl
Version: 0.17-1+b2
Severity: minor

The callback example in the HTML::Gumbo documentation contains:

elsif ( $event eq /^(text|space|cdata|comment)$/ ) {

This is incorrect. "eq" should be replaced by "=~".

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

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

Versions of packages libhtml-gumbo-perl depends on:
ii  libc6   2.24-14
ii  libgumbo1   0.10.1+dfsg-2.1
ii  libhtml-tree-perl   5.03-2
ii  perl5.26.0-5
ii  perl-base [perlapi-5.26.0]  5.26.0-5

libhtml-gumbo-perl recommends no packages.

libhtml-gumbo-perl suggests no packages.

-- no debconf information

Bug#870788: Extract recent uploaders from d/changelog

[Sean Whitton]

Package: tracker.debian.org
Severity: wishlist

On Thu, Aug 03 2017, Holger Levsen wrote:

> Then, Tobias has a point, knowing which team members uploaded a package is
> useful. So I have a simple proposal to achieve that: make tracker.d.o
> show the last 10 uploaders for a given package (based on UDD), just like it
> parses the Uploaders: field from the packages now.

Such a feature would move this discussion forward, so I'm submitting it
as a feature request.

I think that the logic in who-uploads(1) is probably insufficient;
parsing d/changelog would catch people actually /contributing/ to the
package, not just those who signed the uploads.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#870787: liboss4-salsa*: please add snd_seq_event_length()

[Thorsten Glaser]

Source: oss4
Version: 4.2-build2010-5

Hi,

please add this small four-liner function so MuseScore can build
without a patch. I’m working around this in the upcoming upload
of src:musescore, but without such hackery is always better.

Perhaps get the kFreeBSD and Hurd porters to help making these
libraries more complete couldn’t hurt (pun not intended)?

Thanks,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

Bug#853490: Pending fixes for bugs in the libdomain-publicsuffix-perl package

[pkg-perl-maintainers]

tag 853490 + pending
thanks

Some bugs in the libdomain-publicsuffix-perl package are closed in
revision 143f3358125780d01e56171aec0cfef97129cac8 in branch 'master'
by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libdomain-publicsuffix-perl.git/commit/?id=143f335

Commit message:

Add patch from upstream git which fixes gcc-7 build failure.

Thanks: Gianfranco Costamagna for forwarding the patch.
Closes: #853490

Bug#868969: minimal test script

[Ben Finney]

On 03-Aug-2017, Tristan Lucas wrote:

> this seems to be introduced with updating libexpat1 from 2.2.0-2 ->
> 2.2.2-2

Thank you for doing some diagnosis on this bug.

> Please feel free to contact me in order to obtain a minimal
> test-script along with original and reordered translation files

Can you give the steps to reproduce this, and the script? You can
reply to this bug report, describe the steps to reproduce, and attach
the test script.

-- 
 \“The problem with television is that the people must sit and |
  `\keep their eyes glued on a screen: the average American family |
_o__) hasn't time for it.” —_The New York Times_, 1939 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#870783: mptp: FTBFS with lex_utree.l:22:25: fatal error: parse_utree.h: No such file or directory

[Andreas Tille]

Hi James,

On Sat, Aug 05, 2017 at 12:09:30AM +0100, James Clarke wrote:
> Source: mptp
> Version: 0.2.2-1
> Severity: serious
> 
> Hi,
> mptp FTBFS when built with sufficient levels of parallelism (15 is
> enough); the relevant tail of the log is given below:
> > ...
> > make[3]: *** Waiting for unfinished jobs
> > lex_rtree.l:22:25: fatal error: parse_rtree.h: No such file or directory
> >  #include "parse_rtree.h"
> >  ^
> > compilation terminated.
> > Makefile:473: recipe for target 'lex_rtree.o' failed

It looks to me as if --no-parallel would be a sensible solution for this
problem, right?

Kind regards

Andreas.
 

-- 
http://fam-tille.de

Bug#754418: xml2 version 0.5 avaliable

[Vincent Lefevre]

Control: retitle -1 xml2 version 0.5 available

On 2014-07-10 22:45:24 +0200, Ferran Jorba wrote:
> version 0.5 of xml2 is available at http://download.ofb.net/gale/
> since May 2011. It fixes, among other things, utf-8 issues filled
> against Debian bug system.

This URL is not longer valid, and xml2 no longer seems to exist
upstream any longer.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#824801: option to force native build

[Guido Günther]

Hi Eduard,
sorry for the delay. Hopefully I have your concerns covered:

On Mon, May 23, 2016 at 08:14:34PM +0200, Eduard Bloch wrote:
> Hallo,
> * Guido Günther [Sun, May 22 2016, 05:36:39PM]:
> > retitle 824801 buildpackage: option to force sloppy test builds
> > summary 824801 It should be simple to perform a build of the current HEAD 
> > without having to worry about upstream branches, pristine-tar and the like
> > 
> > On Fri, May 20, 2016 at 08:37:54AM +0200, Guido Günther wrote:
> > > On Thu, May 19, 2016 at 11:40:38PM +0200, Eduard Bloch wrote:
> > > > Package: git-buildpackage
> > > > Version: 0.7.4
> > > > Severity: wishlist
> > > > 
> > > > Hi,
> > > > 
> > > > I remember having reported a similar issue a couple of years ago and
> > > > back then it was closed with a useless coment. This time I stumbled upon
> > > > it again and still cannot find a SANE solution. With SANE, I mean
> > > > user-friendly. I, as user, wish to have an option to make a test build.
> > > > Without having an upstream tarball!
> > > > (that is the key point. The debian branch is a fork of the upstream
> > > > branch after all, it should just work).
> > > > 
> > > > WRT dpkg-buildpackage itself, I can easily force it to act like on a
> > > > native package and just build me my binary packages. But with gbp, this
> > > > simple task becomes PITA: it wants me to have some upstream reference or
> > > > else... (see below).
> > > > 
> > > > Sorry, there really should be an easy and user-friendly way to let me
> > > > just build it, no matter whether there is an upstream tag or not. I
> > > > did RTFM and nothing ringed a bell there. If there is an easy way,
> > > > please document it properly.

The sheer amount of options needed is not particularly user friendly but
you can force gbp to create a tarball from whatever you have in your
working copy since some time now:

   
https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.special.html#GBP.SPECIAL.SLOPPYTARBALL

> > > > dh_clean
> > > > rm -rf debian/apt-cacher-ng.service debian/apt-cacher-ng.tmpfile 
> > > > dbgen/dbgenerator.* dbgen/dbupdate
> > > > debconf-updatepo
> > > > ...
> > > > gbp:info: Orig tarball 'apt-cacher-ng_0.9.3.orig.tar.xz' not found at 
> > > > '../tarballs/'
> > > > gbp:error: Pristine-tar couldn't checkout 
> > > > "apt-cacher-ng_0.9.3.orig.tar.xz": fatal: Path 
> > > > 'apt-cacher-ng_0.9.3.orig.tar.xz.delta' does not exist in 
> > > > 'refs/heads/pristine-tar'
> > > > pristine-tar: git show 
> > > > refs/heads/pristine-tar:apt-cacher-ng_0.9.3.orig.tar.xz.delta failed
> > > 
> > > It's still the same as back then: don't sue pristine tar if you don't
> > > want it and tell gbp that you're fine with just picking the head of your
> > > upstrema branch.
> > 
> > That said an option that creates a tarball not from the upstream branch
> > but just takes the current tree, drops debian/ and creates an upstream
> > tarball from it would probably also helpful in the above situation (at
> > least for 3.0 (quilt).
> > 
> > This would also allow to test patches without having to move to a pq
> > first. We would just have to make sure we create a unique version number
> > just like -S in gbp dch.
> 
> Oookay, I am not that familiar with the details nor do I use any
> "advanced" workflow like pq. For simple packages, I prefer simple
> solutions and feel enslaved if some tool attempts to be too smart and
> to enforce it's own conventions, no matter whether they make sense or not.
> 
> Anyhow, And the good news, after some experiments it was possible to
> force the build that way with: 
> gbp buildpackage --git-no-pristine-tar --git-no-create-orig 
> --git-builder="fakeroot debian/rules binary"
> 
> So, thanks!
> 
> But it still does not feel right. I am trying to be constructive here...
> 
> First: it's about the usability of the package. I mean, for you it was obvious
> that pristine-tar is the culprit. For me, it was not.
> 
> IMHO, a helpful error message (after the pristine-tar barking) would say
> something ADDITIONAL like:
> 
> "pristine-tar method failed to construct upstream source. Please use one
> of the -git-upstream-* options or see documentation for other ways of
> upstream source configuration."
> 
> Second: even using --git-no-pristine-tar it still does not build.
> 
> gbp:info: Orig tarball 'apt-cacher-ng_0.9.3.orig.tar.xz' not found at 
> '../tarballs/'
> gbp:error: upstream/0.9.3 is not a valid treeish
> 
> Aapparently you need to specify --git-upstream-tree OR both,
> --git-upstream-branch and --git-upstream-tag set to HEAD (which does not
> feel right either because HEAD is not a tag, strictly speaking). Maybe
> HEAD is also wrong (works by accident? The manpage does not explain it).
> Anyhow, maybe the error message should be more explicit about the reason
> in case where upstream-branch is already set but that is not considered
> enough information to build the original source.
> 
> And, another inconvenient thing: I'd expect all 

Bug#824801: [git-buildpackage/master] gbp-buildpackage: Group manpage options

[Guido Günther]

tag 824801 pending
thanks

Date:   Fri Aug 4 19:44:48 2017 -0300
Author: Guido Günther 
Commit ID: e7bbd6523fbb68ce69be1be7ebbd231ab9f6ea36
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=e7bbd6523fbb68ce69be1be7ebbd231ab9f6ea36
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=e7bbd6523fbb68ce69be1be7ebbd231ab9f6ea36

gbp-buildpackage: Group manpage options

Closes: #824801

  

Bug#859407: abook dies with SIGSEGV on vcard convert

[Denis Briand]

tags 859407 pending patch
thanks

Hello,
Thank you for your bug report.
Here is a patch to fix the issue.
Next version is pending upload.

best regards

Denis Briand
Author: Denis Briand 
Bug-Debian: https://bugs.debian.org/859407
Description: if USER env variable isn't defined, use nobody account to avoid SIGSEGV with getpwnam

--- a/filter.c
+++ b/filter.c
@@ -186,6 +186,11 @@
 	int rtn;
 	char *tmp;
 
+	//if USER env variable isn't defined, use nobody account to avoid SIGSEGV with getpwnam
+	if (!username) {
+  username = "nobody";
+   }
+
 	pwent = getpwnam(username);
 
 	if((tmp = xstrdup(pwent->pw_gecos)) == NULL)


pgpnFpCNtc3Wb.pgp
Description: PGP signature

Bug#856139: certspotter: long description advertises commercial service

[Jonas Smedegaard]

Dear fellow Debian developers,

Am I alone in finding it wrong to promote commercial services in long 
descriptions of packages n Debian main?


Quoting Faidon Liambotis (2017-08-04 13:57:10)
> On Sat, Feb 25, 2017 at 03:53:13PM +0100, Jonas Smedegaard wrote:
> > Long description includes a paragraph starting with the following:
> > 
> > > Cert Spotter is also available as a hosted service by SSLMate that
> > > requires zero setup [...]
> > 
> > That paragraph is irrelevant for this package - please drop it.
[...]
> At worst, this is "irrelevant" as you put it,

No, at worst this is misuse of Debian ressources for commercial gain - 
i.e. using long description field for advertising a non-free service.

 - Jonas

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

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


signature.asc
Description: signature

Bug#870786: texlive-bin: Make source package bootstrappable

[Daniel Schepler]

Source: texlive-bin
Version: 2017.20170613.44572-3
Severity: wishlist

The relatively recently added build dependency of texlive-bin on
default-jdk introduced several build dependency cycles, such as:

default-jdk Depends on openjdk-8-jdk
openjdk-8 Build-Depends on libgtk2.0-dev
gtk+2.0 Build-Depends on shared-mime-info
shared-mime-info Build-Depends on docbook-utils
docbook-utils Depends on jadetex
jadetex (indirectly) Depends on texlive-binaries

Ideally, almost every package using texlive-binaries would put the
dependency in Build-Depends-Indep (splitting docs into an
Architecture: all package if necessary).  However, practically
speaking, I've found there are enough of these cycles that it's easier
for now just to build without tex4ht.jar.  It would be nice if there
were a stage1 or nojava build profile in the texlive-bin source
package that would do the same thing.

Of course, that would require either splitting out tex4ht.jar and
associated files into a separate package, or else the resulting
package would have to be renamed to something like
texlive-binaries-stage1 to reflect the changed package contents.
-- 
Daniel Schepler

Bug#506805: mangles UTF-8

[Vincent Lefevre]

Control: found -1 0.4-3.1
Control: severity -1 grave

Silent data loss on files with non-ASCII characters (very common
nowadays). Should be grave.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#870785: avahi: Drop libgtk2.0-dev build dependency from stage1 build profile

[Daniel Schepler]

Source: avahi
Version: 0.6.32-2
Severity: wishlist

The build dependency on libgtk2.0-dev introduces essentially the same
cycle as the libgtk-3-dev build dependency which was already dropped
in stage1:

avahi Build-Depends on libgtk2.0-dev
gtk+2.0 Build-Depends on libcups2-dev
cups Build-Depends on libavahi-client-dev

Besides, debian/control already drops libavahi-ui-dev, libavahi-ui0,
and avahi-discover from stage1 builds anyway, and those are the only
packages depending on Gtk+2.
-- 
Daniel Schepler

Bug#870784: mptp: Please stop building with -mtune=native

[James Clarke]

Source: mptp
Version: 0.2.2-1
User: reproducible-bui...@lists.alioth.debian.org
Usertags: cpu

Hi,
Currently mptp builds with -mtune=native from the upstream source;
please remove this for the following reasons:

 * Not all architectures support this option, causing the package to
 * FTBFS

 * GCC for PowerPC has a bug[0] stopping it from working on some CPUs,
   and this is triggered on the powerpcspe buildds

 * Whatever GCC decides is best on the buildds may not be efficient on
   users' machines

 * The package cannot be built reproducibly unless the CPUs used to
   build it are sufficiently similar for GCC to use the same tuning

Regards,
James

[0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010

Bug#870783: mptp: FTBFS with lex_utree.l:22:25: fatal error: parse_utree.h: No such file or directory

[James Clarke]

Source: mptp
Version: 0.2.2-1
Severity: serious

Hi,
mptp FTBFS when built with sufficient levels of parallelism (15 is
enough); the relevant tail of the log is given below:

> gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -I. -O3 
> -mtune=native -Wall -Wsign-compare -g -lgsl -lgslcblas -lm  -g -O2 
> -fdebug-prefix-map=/build/mptp-0.2.2=. -fstack-protector-strong -Wformat 
> -Werror=format-security -c -o lex_utree.o lex_utree.c
> gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -I. -O3 
> -mtune=native -Wall -Wsign-compare -g -lgsl -lgslcblas -lm  -g -O2 
> -fdebug-prefix-map=/build/mptp-0.2.2=. -fstack-protector-strong -Wformat 
> -Werror=format-security -c -o lex_rtree.o lex_rtree.c
> lex_utree.l:22:25: fatal error: parse_utree.h: No such file or directory
>  #include "parse_utree.h"
>  ^
> compilation terminated.
> Makefile:473: recipe for target 'lex_utree.o' failed
> make[3]: *** [lex_utree.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> lex_rtree.l:22:25: fatal error: parse_rtree.h: No such file or directory
>  #include "parse_rtree.h"
>  ^
> compilation terminated.
> Makefile:473: recipe for target 'lex_rtree.o' failed
> make[3]: *** [lex_rtree.o] Error 1
> updating parse_utree.h
> updating parse_rtree.h

Regards,
James

Bug#870782: licensecheck: please improve the man page.

[David Bremner]

Package: licensecheck
Version: 3.0.30-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

As a user, the only useful bits here are in the SYNOPSIS. It would be
great if at least a few of the main options were documented.


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

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

Versions of packages licensecheck depends on:
ii  libgetopt-long-descriptive-perl0.100-1
ii  libmoo-perl2.003002-1
ii  libnamespace-clean-perl0.27-1
ii  libpath-iterator-rule-perl 1.009-1
ii  libpath-tiny-perl  0.100-1
ii  libpod-constants-perl  0.19-1
ii  libscalar-list-utils-perl  1:1.48-1+b2
ii  libsort-key-perl   1.33-1+b5
ii  libstrictures-perl 2.03-1
ii  libstring-copyright-perl   0.003005-1
ii  libstring-escape-perl  2010.002-1
ii  libtry-tiny-perl   0.28-1
ii  perl   5.26.0-4
ii  perl-base [libscalar-list-utils-perl]  5.26.0-4

licensecheck recommends no packages.

Versions of packages licensecheck suggests:
ii  bash-completion  1:2.1-4.3

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlmE/I4ACgkQ8gKXHaSn
nix1Vgv/XeGiybu4jZUd0rAschwqTEHCADRY3yFfuXJgAB+f+LUk5SqMipt4fkvi
/4FLN4j8Vvfu9uVXWJoJ2pUP2wkG+zGNg//MzagSzFZA/+R0cxCcihgqd2l8EUGB
PfHF4NRHR0JqztRgNWhCW5gg/nXPsbnB9hOcG1SWqOPpcGe83r92/bKbHfI1PP26
l3Y23oxRSmE+eoa5z1XolgFSm8gJhYqr0OlYfTxTKSvu5Evz28HW7TgY2QupZNfE
oKtTKW94/kVvzJF8llzsOEWyOLW10HXagymMCCTWbw/fhKV6DQIxxdrTtoYP2lyV
VbUDH9Dy3ZBzmPRxeQGKsd2HWaEq8yB37DYDmHCpojsLekEL7rKEh0FgYkdfPFXP
LNDoTM2lzKaCY924981F+tqQawtyjh71btUVf/QaaNZ7e2BhjWO28eCCEzoNQrF4
ZAmW9BPLjGYtBjR9adXRc9kBAjFj15Z4H619V9DeYk7jIwlBghA0hvB4vcKXpQdE
AX7VUwUC
=pFie
-END PGP SIGNATURE-

Bug#870228: [a...@debian.org: Bug#870228: physamp: fails to upgrade from 'stretch' - trying to overwrite /usr/bin/bppphysamp]

[Andreas Tille]

Dear Julien,

On Fri, Aug 04, 2017 at 11:38:41PM +0200, Julien Yann Dutheil wrote:
> Indeed, the bppPhySamp program from bppsuite moved to its own separate
> package, which includes another program as well (bppAlnOptim). I have read
> the suggested policy, but I'm a bit unsure, as it is not really a package
> split as exemplified there. I now want bppphysamp to be installed
> independently of the other programs in bppsuite, so I am not sure the
> Replaces: tag is justified. Should I just add Conflicts: bppsuite (<<
> 1.3.0-1) in the physamp control file, would that be the ocrrect thing to do?

Yes, that's it.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#750946: libhtml-html5-parser-perl: UTF-8 character confuses the parser

[Vincent Lefevre]

Control: severity -1 grave

I'm raising this bug to grave since this is silent dataloss.

In short, this module is highly broken and no longer maintained.
It should probably be removed from Debian.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#646880: pptp-linux: pptpsetup creates /etc/ppp/peers/$PEERNAME world-readable

[James Cameron]

Christoph Biedl wrote:
> James Cameron wrote...
> > pptpsetup preserves mode on /etc/ppp/chap-secrets, but uses root
> > umask 0022 on /etc/ppp/peers/$TUNNEL, and group dip because of
> > setgid bit on /etc/ppp/peers.
> > 
> > My perl is rusty.  As far as I can see, it would be a call to chmod
> > after open, or a call to umask before open.  Latter seems easy, but
> > overrides user choice.
> ...
> > Patch attached, will be upstreamed after review.
> 
> That is almost the thing I was about to suggest, go for it.

Was pushed.  d33e18d.

> And, when convenient, please replace the two-argument form of open
> [...]

Was pushed.  c0dbacf.

-- 
James Cameron
http://quozl.netrek.org/

Bug#870781: RM: hostap-utils -- ROM; obsolete, abandoned upstream

[Faidon Liambotis]

Package: ftp.debian.org
Severity: normal

hostap-utils contains utilities to be used with the "hostap" kernel
driver, a driver for once popular 802.11b PCMCIA and PCI cards, Intersil
Prism 2, 2.5 and 3. The last of these chipsets was released in 2003 or
so. (Prism's 802.11b USB chipset, as well as the 802.11g chipsets, are
different and supported by other drivers).

The last version of hostap-utils was released by upstream in 2005, and
it was last uploaded to Debian in 2008. While the Linux kernel package
still builds the driver, I'd be surprised if the hardware is used by
anyone these days. Even if it is, I hardly expect these people to use
buster for them.

While the package probably still works, despite being horribly outdated,
I fail to see the point of maintaining it further. I think it's time to
let it go and remove it from Debian buster onwards.

Regards,
Faidon

Bug#870780: debian-archive-keyring: please remove trust packets from keyrings

[Daniel Kahn Gillmor]

Package: debian-archive-keyring
Version: 2017.5
Severity: normal

Hey there!

/usr/share/keyrings/debian-archive-keyring.gpg

   and

/usr/share/keyrings/debian-archive-removed-keys.gpg

contain more than just OpenPGP certificates -- they also contain
"Trust packets", which are basically underspecified blobs that
different PGP implementations can treat differently.

some implementations even choke when they encounter them, for example:

https://bitbucket.org/skskeyserver/sks-keyserver/issues/52

But whether other implementations handle them correctly or not,
there's no point in shipping them in the archive keyring.

You can filter them out (and sanitize the keyring) with:

gpg --import-options import-export --import < crufty.gpg > clean.gpg

I recommend removing them from the shipped keyrings entirely.

Thanks for maintaining the archive keyring in debian,

--dkg


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

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

Versions of packages debian-archive-keyring depends on:
ii  gpgv  2.1.21-4

Versions of packages debian-archive-keyring recommends:
ii  gnupg  2.1.21-4

debian-archive-keyring suggests no packages.

-- Configuration Files:
/etc/apt/trusted.gpg.d/debian-archive-jessie-automatic.gpg [Errno 2] No such 
file or directory: '/etc/apt/trusted.gpg.d/debian-archive-jessie-automatic.gpg'
/etc/apt/trusted.gpg.d/debian-archive-jessie-security-automatic.gpg [Errno 2] 
No such file or directory: 
'/etc/apt/trusted.gpg.d/debian-archive-jessie-security-automatic.gpg'
/etc/apt/trusted.gpg.d/debian-archive-jessie-stable.gpg [Errno 2] No such file 
or directory: '/etc/apt/trusted.gpg.d/debian-archive-jessie-stable.gpg'
/etc/apt/trusted.gpg.d/debian-archive-wheezy-automatic.gpg [Errno 2] No such 
file or directory: '/etc/apt/trusted.gpg.d/debian-archive-wheezy-automatic.gpg'
/etc/apt/trusted.gpg.d/debian-archive-wheezy-stable.gpg [Errno 2] No such file 
or directory: '/etc/apt/trusted.gpg.d/debian-archive-wheezy-stable.gpg'

-- no debconf information

Bug#870779: pev: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: pev
Version: 0.80-3
Severity: important
Tags: sid buster
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans

Please migrate to libssl-dev in the Buster cycle.

Sebastian

Bug#870777: casync: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: casync
Version: 2-1
Severity: important
Tags: sid buster
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans

Please migrate to libssl-dev in the Buster cycle.

Sebastian

Bug#870778: libtgvoip: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: libtgvoip
Version: 1.0~git20170704.445433f-2
Severity: important
Tags: sid buster
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans

Please migrate to libssl-dev in the Buster cycle.

Sebastian

Bug#870776: zbackup: Cannot change compression algorithm on command line

[Daniel Gröber]

Package: zbackup
Version: 1.4.4-2
Severity: important

Dear Maintainer,

lzma compression is too slow on my system so I tried to change to lzo,
however when I add `--compression lzo` to the command line as
suggested by the `--help` output like so:

zbackup --non-encrypted --compression lzo init ./repo

I get the following error:

Unsupported compression method:  lzo1x_1
.

Incidentally `--compression lzma` works just fine -- weird. I also
tried adding `--compression lzo` only to the `backup` command, that
didn't work either though.

--Daniel

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

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

Versions of packages zbackup depends on:
ii  libc6  2.24-11+deb9u1
ii  libgcc11:6.3.0-18
ii  liblzma5   5.2.2-1.2+b1
ii  libprotobuf10  3.0.0-9
ii  libssl1.1  1.1.0f-3
ii  libstdc++6 6.3.0-18
ii  zlib1g 1:1.2.8.dfsg-5

zbackup recommends no packages.

zbackup suggests no packages.

-- no debconf information

Bug#870775: boxbackup: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: boxbackup
Version: 0.12~gitcf52058f-3
Severity: important
Tags: sid buster
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans

Please migrate to libssl-dev in the Buster cycle.

Sebastian

Bug#798476: Maintainer information in source packages (was: Re: Returning to the requirement that Uploaders: contain humans)

[Jonathan Nieder]

Hi,

Ansgar Burchardt wrote:

> as a more radical change one could also ask the question where to
> maintain the maintainer information.  Currently we handle this in the
> source package via the Maintainer and Uploaders field, and via team
> memberships.
>
> This has several limitations: for teams, Uploaders will often be
> useless (you don't want to list all team members in every team-
> maintained package).  The Maintainer field only really applies to
> Debian, in derivatives someone else should be contacted.  In stable
> releases, the field can often be outdated (it records who maintained
> the package some time ago, not who currently maintains it).
>
> So I have been wondering several times whether we should move the
> maintainer information elsewhere.  For example, tracker.d.o could be
> extended to record maintainer information.  It could also understand
> the concept of "teams" listing team members and whom to send mails
> about individual packages.

This would make me pretty happy, for what it's worth.

Thanks,
Jonathan

> For legacy purposes, the Maintainer field would then list ${source}@tra
> cker.d.o and the Uploaders field could be removed.
>
> This would also address the fact that various bits of our
> infrastructure don't know about Uploaders (like bugs.d.o only
> contacting the Maintainer).
>
> Ansgar

Bug#870728: [Pkg-mc-devel] Bug#870728: mc: random crash on startup (SIGSEGV)

[Denis Briand]

On Sat, Aug 05, 2017 at 12:07:39AM +0200, Yury V. Zaytsev wrote:
> On Fri, 4 Aug 2017, Denis Briand wrote:
> 
> >No I can't reproduce it with git master master and the sid version,
> >because the start is too quick... ^^ My valgrind report is clean. I
> >attached the Paul valgrind report on the upstream bug ticket.
> 
> Well, it claims that the memory that viewer filename is pointing to is freed
> in set_display_type(), but I have no idea why this is happening, and why
> viewer is even involved here in the first place. Also, do you have a clue as
> to what Ctrl+x g is supposed to do?

Yes Ctrl+x g open a quick view panel.


pgp4v2mRXtnDN.pgp
Description: PGP signature

Bug#870280: xelatex: Undefined control sequence \l__xeCJK_listings_letter_bool

[W. Martin Borgert]

After Alexis gave a pure latex example without docbook/dblatex,
shouldn't the bug be assigned back to texlive-latex-recommended?


signature.asc
Description: PGP signature

Bug#870774: nmu: mpich 3.2-7

[Matthias Klose]

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

Please binNMU mpich on all architectures building with GCC 7 as the default (the
header files unfortunately encode the GCC version).

Bug#870522: [pkg-gnupg-maint] Bug#870522: gnupg1: Consider setting use-agent by default

[Daniel Kahn Gillmor]

On Wed 2017-08-02 19:15:08 -0400, Jeremy Bicha wrote:
> On Wed, Aug 2, 2017 at 7:08 PM, Daniel Kahn Gillmor
>  wrote:
>> What do you think about this patch instead of your proposed patch?
>> +opt.use_agent = 1;
>
> Sure, that sounds great.
>
>> The trouble, of course, is that now the gnupg1 package now effectively
>> Depends: gpg-agent, which brings with it a bunch of other dependencies,
>> which has historically caused a lot of grumbling.  Is it worthwhile to
>> pay that price?
>
> Since gnupg(2) already depends on gnupg-agent and we don't want to
> give people a good reason to use gnupg1, I'm hoping it won't be a
> problem.

ok, but gpg1 requires an explicitly set $GPG_AGENT_INFO variable.  For
users who are using X11, that should get handled by
/etc/X11/Xsession.d/90gpg-agent (though that mechanism can apparently
fail depending on some combination of display manager and session
manager that i've been unable to pin down).  And it doesn't wor for
folks on the text-mode console.

Should we warn the user about GPG_AGENT_INFO being unset?  should we
encourage them to set it explicitly with "gpgconf --list-dires
agent-socket"?  should we just try to execute "gpgconf --list-dirs
agent-socket" anyway if GPG_AGENT_INFO is unset?  or should we just tell
people "hey, you're using gpg1, you get to set that variable yourself"?

if we're telling users to "do it yourself", why don't we just tell them
that about setting "use-agent" in their gpg.conf as well, without making
any packaging changes?  they're using deprecated systems, they have to
do more work.  making a halfway change that's going to force work that
didn't used to be required (manually configuring GPG_AGENT_INFO) seems
like not a great outcome.

>> I don't want to spend a ton of time on gnupg1
>
> Me either; that's why I filed this bug report so it will just autosync
> to Ubuntu in the future. :)

makes sense.  sorry these details are difficult to sort out :/

thanks for talking it through with me.

   --dkg


signature.asc
Description: PGP signature

Bug#870773: motif: flex now has yyleng as an int again

[James Clarke]

Source: motif
Version: 2.3.4-13
Severity: important
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hi,
Currently src:motif FTBFS on sparc64 due to wml crashing with SIGBUS (no
build logs available, as libfl-dev was broken on sparc64 until just
recently, masking the issue). This is because wml.c has yyleng defined
as a size_t, which was correct for versions of flex between 2.5.36 and
2.6.1, but this violated POSIX[0] and so yyleng was reverted back to an
int in 2.6.1[1]. When building on sparc64, yyleng just happens to be
aligned to a 4-byte boundary but not an 8-byte boundary, so doing an
8-byte store to it is unaligned and traps, but on other architectures
this will silently zero out the next 4 bytes in memory.

Please apply the attached debdiff to revert wml.c back to defining
yyleng as an external int, and also add a version constraint to
libfl-dev to ensure motif is not accidentally built with an older
version of flex without reinstating the hunk. With it I can successfully
build motif on sparc64.

Regards,
James

[0] http://pubs.opengroup.org/onlinepubs/7908799/xcu/lex.html
[1] 
https://github.com/westes/flex/commit/7a7c3dfe1bcb8230447ba1656f926b4b4cdfc457
diff -Nru motif-2.3.7/debian/control motif-2.3.7/debian/control
--- motif-2.3.7/debian/control  2017-08-03 11:21:00.0 +0100
+++ motif-2.3.7/debian/control  2017-08-04 22:36:10.0 +0100
@@ -5,7 +5,7 @@
debhelper (>= 10),
dh-exec,
flex (>= 2.5.36),
-   libfl-dev,
+   libfl-dev (>= 2.6.1),
libfontconfig1-dev,
libjpeg-dev,
libpng-dev,
diff -Nru motif-2.3.7/debian/patches/fix-type-inconsistencies.patch 
motif-2.3.7/debian/patches/fix-type-inconsistencies.patch
--- motif-2.3.7/debian/patches/fix-type-inconsistencies.patch   2017-08-03 
10:54:00.0 +0100
+++ motif-2.3.7/debian/patches/fix-type-inconsistencies.patch   2017-08-04 
22:36:10.0 +0100
@@ -1,12 +1,10 @@
 Description: Fix type inconsistencies
  This patch fixes various type inconsistencies reported by goto-cc
  from the cbmc package.
- .
- The yyleng fix in tools/wml/wml.c requires flex >= 2.5.36.
 Author: Graham Inggs 
 Forwarded: http://bugs.motifzone.net/show_bug.cgi?id=1641
 Bug-Debian: http://bugs.debian.org/749417
-Last-Update: 2017-08-03
+Last-Update: 2017-08-04
 --- a/lib/Xm/EditresComI.h
 +++ b/lib/Xm/EditresComI.h
 @@ -8,7 +8,7 @@
@@ -49,17 +47,6 @@
  extern int _XmTabbedStackListCount _ARGS((XmTabbedStackList));
  
  #ifndef _NO_PROTO
 a/tools/wml/wml.c
-+++ b/tools/wml/wml.c
-@@ -153,7 +153,7 @@
- /*
-  * External variables
-  */
--externint yyleng;
-+externsize_t  yyleng;
- extern  int yyparse();
- 
- 
 --- a/demos/lib/Xmd/RegEdit.c
 +++ b/demos/lib/Xmd/RegEdit.c
 @@ -252,7 +252,7 @@

Bug#868550: reprepro seems to provide a repro

[Ian Jackson]

I added a workaround and some instrumentation to my test suite (push
to come soon).  I found that many (but not all) of the failing
invocations look like this

   gpg --ignore-time-conflict
 --no-options
 --no-default-keyring
 --homedir
 /tmp/apt-key-gpghome.yLlu1bwwPI
 --no-auto-check-trustdb
 --trust-model
 always
 --batch
 --import

I think this is during an invocation of apt-key by reprepro.  Retrying
those after 10s with the same options and command line seems to mostly
work...

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#870772: libgsl misses some breaks/replaces

[Alf Gaida]

Package: libgsl23
Version: 2.4+dfsg-3
Severity: grave
Tags: patch

Dear Maintainer, 

like the subject says libgsl lacks some breaks and replaces, that breaks the 
upgrade path:

% LANG=C sudo apt -f install
  :(
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  libgsl23
Suggested packages:
  gsl-ref-psdoc | gsl-doc-pdf | gsl-doc-info | gsl-ref-html
The following NEW packages will be installed:
  libgsl23
0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
28 not fully installed or removed.
Need to get 0 B/914 kB of archives.
After this operation, 2.887 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
(Reading database ... 537126 files and directories currently installed.)
Preparing to unpack .../libgsl23_2.4+dfsg-3_amd64.deb ...
Unpacking libgsl23:amd64 (2.4+dfsg-3) ...
dpkg: error processing archive 
/var/cache/apt/archives/libgsl23_2.4+dfsg-3_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/libgslcblas.so.0.0.0', which is 
also in package libgsl2:amd64 2.4+dfsg-2
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/libgsl23_2.4+dfsg-3_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


The following should fix that

diff --git a/debian/control b/debian/control
index 5e12819..486169d 100644
--- a/debian/control
+++ b/debian/control
@@ -12,8 +12,9 @@ Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
+Breaks: libgsl2
 Conflicts: gsl, libgsl0, libgsl0ldbl
-Replaces: gsl, libgsl0 (<= 1.9-4), libgsl0ldbl (<= 1.16+dfsg-4)
+Replaces: gsl, libgsl0 (<= 1.9-4), libgsl0ldbl (<= 1.16+dfsg-4), libgsl2
 Suggests: gsl-ref-psdoc | gsl-doc-pdf | gsl-doc-info | gsl-ref-html
 Description: GNU Scientific Library (GSL) -- library package 
  The GNU Scientific Library (GSL) is a collection of routines for


Cheers Alf

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

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

Versions of packages libgsl23 depends on:
ii  libc6  2.24-14

libgsl23 recommends no packages.

Versions of packages libgsl23 suggests:
pn  gsl-ref-psdoc | gsl-doc-pdf | gsl-doc-info | gsl-ref-html  

-- no debconf information

Bug#870728: [Pkg-mc-devel] Bug#870728: mc: random crash on startup (SIGSEGV)

[Yury V. Zaytsev]

On Fri, 4 Aug 2017, Denis Briand wrote:

No I can't reproduce it with git master master and the sid version, 
because the start is too quick... ^^ My valgrind report is clean. I 
attached the Paul valgrind report on the upstream bug ticket.


Well, it claims that the memory that viewer filename is pointing to is 
freed in set_display_type(), but I have no idea why this is happening, and 
why viewer is even involved here in the first place. Also, do you have a 
clue as to what Ctrl+x g is supposed to do?


Under valgrind, mc starts rather slowly for me in /usr/bin, but I can't 
reproduce it on 4.8.19...


--
Sincerely yours,
Yury V. Zaytsev

Bug#495400: apr_1.3.2-3(m68k/experimental): test suite fails

[John Paul Adrian Glaubitz]

On 08/04/2017 11:23 PM, Stefan Fritsch wrote:
> The bug has been open for 9 years and no m68k porter has looked at it. 
> Ususally apr test failures are toolchain/kernel/libc issues, so my 
> motivation to debug this for a very slow arch that has zero chance of ever 
> being part of a Debian release is very small.

If no email is send to inform any of the porters, no one is going
to know that there is an actual bug which needs to be worked on.

The port-specific mailing lists exist for this very reason. You
can't expect us to know about every bug filed on any package
within Debian.

If you have a problem with architecture X, talk to the people
maintaining it.

>> Here's a current build log [1]. m68k is alive and kicking with full
>> C++11 support and over 10700 out of 12000 packages being up-to-date.
> 
> Sorry, I did not know that the ports use the official buildd website 
> nowadays. Is there some tool like rmadison but that includes all 
> inofficial ports, too?

I'm not sure what the current status here is. James Clarke will know
more. He's been working on bringing these features to Debian Ports. There
is already a transition tracker for Debian Ports:

> https://ben.jrtc27.com/

> And the build log [1] seems to be built with "notest" so it does not help 
> for checking if the test failure still happens.

I can test that. There is also a way to set up your own m68k environment [1].

Adrian

> [1] https://wiki.debian.org/M68k/sbuildQEMU

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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Russ Allbery]

Adrian Bunk  writes:

> In a more general note, I am a bit puzzled that it is so controversial
> that machine-readable team membership information is important and
> should continue to be available.

One of the major points of disagreement in this thread is that you think
this information is currently available and useful, and other people (such
as myself) think that your understanding of Uploaders has little
relationship to how the field is currently used in the archive.

I'm dubious that it's worth the effort to maintain this, but regardless of
that discussion, machine-readable team information is not something we
have now.  We instead have a partial record of some people who have
previously worked on the package, without much information about whether
they're currently working on the package.  It's marginally more useful
than the debian/changelog entries, but only marginally.

-- 
Russ Allbery (r...@debian.org)   

Bug#870771: gnome-software: packages with AGPL-3 license are claimed to be non-free

[Marco Maria Francesco De Santis]

Package: gnome-software
Version: 3.22.5-1
Severity: normal

Dear Maintainer,
I have installed hoteldruid from the debain main archive (this package
is not listed in gnome-software if you don't install it, maybe because
of this bug) and it is reported as having a propietary license in
gnome-software. Its appstream metainfo file reports the AGPL-3+ license,
which is approved for debian main archive and OSI approved. The package
should be shown as having a free license.


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

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

Versions of packages gnome-software depends on:
ii  appstream0.11.2-1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  gnome-software-common3.22.5-1
ii  gsettings-desktop-schemas3.22.0-1
ii  libappstream-glib8   0.6.8-1
ii  libatk1.0-0  2.24.0-1
ii  libc62.24-12
ii  libcairo-gobject21.14.10-1
ii  libcairo21.14.10-1
ii  libenchant1c2a   1.6.0-11+b2
ii  libfwupd10.8.2-2
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.52.3-1
ii  libgnome-desktop-3-123.22.2-1
ii  libgtk-3-0   3.22.17-1
ii  libgtkspell3-3-0 3.0.9-1
ii  libgudev-1.0-0   230-3
ii  libjson-glib-1.0-0   1.2.8-1
ii  libpackagekit-glib2-18   1.1.6-2
ii  libpango-1.0-0   1.40.6-1
ii  libpangocairo-1.0-0  1.40.6-1
ii  libpolkit-gobject-1-00.105-18
ii  libsecret-1-00.18.5-3.1
ii  libsoup2.4-1 2.56.0-2
ii  libsqlite3-0 3.19.3-3
ii  packagekit   1.1.6-2
ii  software-properties-gtk  0.96.20.2-1

gnome-software recommends no packages.

Versions of packages gnome-software suggests:
pn  fwupd  
pn  gnome-software-plugin-flatpak  
pn  gnome-software-plugin-limba

-- no debconf information

Bug#870728: [Pkg-mc-devel] Bug#870728: mc: random crash on startup (SIGSEGV)

[Denis Briand]

On Fri, Aug 04, 2017 at 11:29:43PM +0200, Yury V. Zaytsev wrote:
> On Fri, 4 Aug 2017, Denis Briand wrote:
> 
> >Step to reproduce:
> >$ MALLOC_PERTURB_=254 MALLOC_CHECK_=2 mc
> >then during the startup: hit "Ctrl+x g" keys combo
> >
> >Important: you must hit "Ctrl+x g" keys before the panels are displayed.
> >To reproduce this long start, you have got 370 sub-directories in the
> >current directory.
> 
> Hi Denis,
> 
> Ah, so you've got a reproducer, great! Are you able to reproduce it on git
> master? Can you easily switch ASan on?
> 
> -- 
> Sincerely yours,
> Yury V. Zaytsev

Hi Yury,
No I can't reproduce it with git master master and the sid version,
because the start is too quick... ^^
My valgrind report is clean.
I attached the Paul valgrind report on the upstream bug ticket.

Denis


pgpl30bPOGwRP.pgp
Description: PGP signature

Bug#870252: pkg-perl-autopkgtest: skip t/00-compile/*.t

[Alex Muntada]

gregor herrmann:

> A quick glance at the commit says: looks good!

Looks good to me, too.

Cheers!
Alex



signature.asc
Description: PGP signature

Bug#870728: [Pkg-mc-devel] Bug#870728: mc: random crash on startup (SIGSEGV)

[Yury V. Zaytsev]

On Fri, 4 Aug 2017, Denis Briand wrote:


Step to reproduce:
$ MALLOC_PERTURB_=254 MALLOC_CHECK_=2 mc
then during the startup: hit "Ctrl+x g" keys combo

Important: you must hit "Ctrl+x g" keys before the panels are displayed.
To reproduce this long start, you have got 370 sub-directories in the
current directory.


Hi Denis,

Ah, so you've got a reproducer, great! Are you able to reproduce it on git 
master? Can you easily switch ASan on?


--
Sincerely yours,
Yury V. Zaytsev

Bug#870728: [Pkg-mc-devel] Bug#870728: mc: random crash on startup (SIGSEGV)

[Yury V. Zaytsev]

Hi Paul,

Thanks for the report! To be very honest, I'm not sure how actionable it 
is though :-/


The most obvious reason for the segfault would have been that somebody has 
freed `view->filename_vpath` without setting it to NULL, but a quick grep 
for `->filename_vpath` doesn't reveal anything suspicious :-(


So this makes me think that maybe something else corrupted the memory 
indirectly, but then I can't see how this can be reasonably investigated 
without a sanitizer like report or even better a reproducer...


--
Sincerely yours,
Yury V. Zaytsev

Bug#870769: libfl-dev: Does not provide suitable libfl.a for PIEs

[James Clarke]

Package: libfl-dev
Version: 2.6.1-1.3
Control: affects -1 src:motif
X-Debbugs-Cc: gin...@debian.org

Hi,
In order to build a PIE using libfl, there must be a static library
built with PIE (or PIC) enabled. On architectures with PIE by default,
this is the case, and libfl.a can be used normally. However, on other
architectures, libfl.a contains position-dependent code, and thus cannot
be used. There *is* a libfl_pic.a which could in theory be used, but it
actually is no different from libfl.a, as it was not built with -fPIC.
This was found by upstream, and since nobody had noticed this before,
they decided to drop it[0] rather than fix it (a trivial fix of adding
-fPIC to libfl_pic_la_CFLAGS). Motif uses libfl for some of its tools
built and used during the build, but also exports
DEB_BUILD_MAINT_OPTIONs=hardening+=all, so it builds these tools as
PIEs. Therefore, please either always built libfl.a with -fPIE, or
ensure libfl_pic.a is built with -fPIC (in this case, -fPIE should
suffice, as libfl provides main, which needs to be in the executable, so
it will never be linked into a shared library).

Graham: Depending on the solution, Motif may need to be changed to use
libfl_pic.a, but that belongs in a different bug.

Regards,
James

[0] 
https://github.com/westes/flex/commit/2bf2ad6d686f5e2a3b6329ecedc756ddfcf71453

Bug#870770: simutrans FTCBFS: uses the build architecture compiler for makeobj/

[Helmut Grohne]

Source: simutrans
Version: 120.2.2-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

simutrans fails to cross build from source, because it uses the build
architecture compiler for the makeobj folder (as a GNU make default).
Wrapping that invocation up in dh_auto_build fixes the issue as
debhelper knows ho to pass cross compilers. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru simutrans-120.2.2/debian/changelog 
simutrans-120.2.2/debian/changelog
--- simutrans-120.2.2/debian/changelog  2017-08-01 00:30:13.0 +0200
+++ simutrans-120.2.2/debian/changelog  2017-08-04 23:17:12.0 +0200
@@ -1,3 +1,10 @@
+simutrans (120.2.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross compilers to make. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 04 Aug 2017 23:17:12 +0200
+
 simutrans (120.2.2-2) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru simutrans-120.2.2/debian/rules 
simutrans-120.2.2/debian/rules
--- simutrans-120.2.2/debian/rules  2017-08-01 00:30:13.0 +0200
+++ simutrans-120.2.2/debian/rules  2017-08-04 23:17:08.0 +0200
@@ -20,7 +20,7 @@
 
 override_dh_auto_build:
dh_auto_build
-   $(MAKE) -C makeobj
+   dh_auto_build --sourcedirectory=makeobj
 
 override_dh_auto_clean:
dh_quilt_patch

Bug#495400: apr_1.3.2-3(m68k/experimental): test suite fails

[Stefan Fritsch]

On Fri, 4 Aug 2017, John Paul Adrian Glaubitz wrote:

> > Not sure if m68k is alive anymore. The build log urls are not reachable
> > anymore this bug report is no longer useful. Closing.
> 
> Well, maybe you should just ask people instead of just closing bug
> reports without further notice?
> 
> > I doubt that anyone is interested in debugging m68k issues
> 
> How do you know without sending an email to debian-68k@l.d.o?

The bug has been open for 9 years and no m68k porter has looked at it. 
Ususally apr test failures are toolchain/kernel/libc issues, so my 
motivation to debug this for a very slow arch that has zero chance of ever 
being part of a Debian release is very small.

> Here's a current build log [1]. m68k is alive and kicking with full
> C++11 support and over 10700 out of 12000 packages being up-to-date.

Sorry, I did not know that the ports use the official buildd website 
nowadays. Is there some tool like rmadison but that includes all 
inofficial ports, too?

And the build log [1] seems to be built with "notest" so it does not help 
for checking if the test failure still happens.

Cheers,
Stefan

> Adrian
> 
> > [1] 
> > https://buildd.debian.org/status/fetch.php?pkg=apr=m68k=1.6.2-1=1501871250=0
> 
> 

Bug#850421: patch for bug #850421 in libsqlcipher0

[Cyril Soler]

Also affects Retroshare. The software is impossible to release on stretch 
because of this bug.
Given the simplicity of the fix above, I dont understand why debian still ships 
with the crashing
libsqlcipher0.

Bug#701200: ferm

[Alexander Wirt]

On Fri, 04 Aug 2017, Adam McKenna wrote:

> Alright I guess I'll have to take this to debian-security then, this may
> even warrant a CVE
I completly disagree, but lets see what -security says.

Alex

Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid

[Barry Arndt]

On Thu, 27 Jul 2017 10:20:12 -0300 Breno Leitao  
wrote:
> Although lack of recent updates, we are still working on this problem.
> 
> Barry (on CC) is allocated to work on this issue and should have updates 
soon.
> 
> 
> 

The offending line of code that Breno mentioned earlier was part of a 
larger patch.  Looking at that larger patch, I'm afraid that just removing 
the offending line of code would make that patch incomplete and could 
possibly leave other errors behind.

We have a few patches for other issues in this area of code.  I tested a 
couple of them, but they did not resolve this issue.  I'm working with 
another developer (who is currently working on other items related to this 
one) to gather more debug information to narrow down to the correct fix.

Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`

[Alan Jenkins]

On 04/08/17 20:52, Michael Biebl wrote:

On Fri, 09 Jun 2017 17:48:59 +0100 Alan Jenkins

There were two reasons `mask` was used here.

1. #722521.  Removing a package naturally deletes most of its files, including
deleting the systemd service unit.  However the system V init script is
preserved, because it might include user changes.  This can work OK under
system V init, but systemd also picks up the initscript, and will show it
as a started service in messages, logs, `systemctl list-units` etc.

#722521 seems perfectly possible to resolve, without resorting to masking.

How?



You snipped my point 2, which also referred to #722521.  Sadly this was 
a typo. Point _2_ is the easy one to resolve.  Point 1 should have 
referred to #714903; I think it is the more fundamental issue.


Sorry!
Alan

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Don Armstrong]

On Fri, 04 Aug 2017, Adrian Bunk wrote:
> And in the other direction what you describe would leave no way for a
> person to make it visible that he has left the team.

It is rarely my experience that people leave teams in clean, definitive
breaks. If they did, packages wouldn't have to be orphaned by the QA
group. Maintainers would take care of that themselves.

> There is no Intent-To-Orphan bug.

Not currently, but one can be created.

> In a more general note, I am a bit puzzled that it is so controversial
> that machine-readable team membership information is important and
> should continue to be available.

Because maintaining such a field increases the burden on teams for
little to no benefit. I know I haven't bothered to be sure that the
Uploaders field in any of my packages only contains people who are
currently actively involved in maintaining that particular packages.

On Fri, 04 Aug 2017, Bill Allombert wrote:
> Nowadays orphaning is done by reuploading the package with the
> maintainer set to the QA group rather than using a O: wnpp bug.

Good point.

-- 
Don Armstrong  https://www.donarmstrong.com

The smallest quantity of bread that can be sliced and toasted has yet
to be experimentally determined. In the quantum limit we must
necessarily encounter fundamental toast particles which the author
will unflinchingly designate here as "croutons".
 -- Cser, Jim. Nanotechnology and the Physical Limits of Toastability.
AIR 1:3, June, 1995.

Bug#870768: debhelper: dh_systemd_enable generates maintscript code for all units despite --name parameter

[Luca Boccassi]

Package: debhelper
Version: 10.2.5
Severity: normal
Tags: patch

Dear maintainer,

When a package ships multiple units, and it uses dh_systemd_enable with
the --name parameter, eg with:

  debian/pkg1.foo1.service
  debian/pkg1.foo2.service

And calling:

override_dh_systemd_enable:
  dh_systemd_enable --name=foo1 --no-enable
  dh_systemd_enable --name=foo2

All calls act on all units despite the --name parameter. When using
additional parameters, such as --no-enable, the second call for foo2
will also write the maintainer script's snippet for foo1, enabling it,
despite the earlier --no-enable.

If the caller further restricts the run by passing the filename as
unnamed argument, which is redundant given the name of the file, then
false positive warnings are emitted at build time:

[  91s] dh_systemd_enable --name=foo1 foo1.service
[  91s] dh_systemd_enable: Could not find "foo1.service" in the
/lib/systemd/system directory of pkg2. This could be a typo, or using
Also= with a service file from another package. Please check carefully
that this message is harmless.
[  91s] dh_systemd_enable: Cannot open(foo1.service) for extracting the
Also= line(s)

Only by further restricting the run by passing -p pkg1 then this
warnings do not appear, as the helper will not try to find the units in
pkg2. Again this is redundant information, given the file is named
after the package it is supposed to be installed to.

A small patch is attached inline to fix this by restricting the sets of
units the helper acts on when --name is passed. Please do double, nay
triple check my Perl/regex though :-)

Thanks!

-- 
Kind regards,
Luca Boccassi


From e024276a141cb0b308e0cac6d9004cd479eb7546 Mon Sep 17 00:00:00 2001
From: Luca Boccassi 
Date: Fri, 4 Aug 2017 21:51:46 +0100
Subject: [PATCH] dh_systemd_enable: if --name is used act only on that unit

A possible use case when using --name is having multiple units:
  debian/pkg.foo1.service
  debian/pkg.foo2.service
and calling the helper twice:
  dh_systemd_enable --name=foo1 --no-enable
  dh_systemd_enable --name=foo2
in which case the snippets would be duplicated in the maintainer
scripts.
This becomes a bug when different parameters are used in each call,
eg: --no-enable, which gets overridden by generated code from the
second call and stealthly enabled against the wishes of the caller.
---
 dh_systemd_enable | 12 
 1 file changed, 12 insertions(+)

diff --git a/dh_systemd_enable b/dh_systemd_enable
index c06f3c0f..a2fe9e79 100755
--- a/dh_systemd_enable
+++ b/dh_systemd_enable
@@ -217,6 +217,18 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
@args = grep !/(^|\/)$x$/, @args;
}
 
+   # If --name was used, act only on matching units. A typical use case is 
having
+   # multiple units per package named debian/pkg.foo1.service 
debian/pkg.foo2.service
+   # and calling the helper twice:
+   #   dh_systemd_enable --name=foo1 --no-enable
+   #   dh_systemd_enable --name=foo2
+   # in which case the snippets would be duplicated in the maintainer 
scripts without
+   # this filtering. This becomes a bug when different parameters are used 
in each
+   # call, eg: --no-enable, which gets overridden by generated code from 
the second call.
+   if (defined $dh{NAME}) {
+   @args = grep 
/(^|\/)$dh{NAME}\.(mount|path|service|socket|target|tmpfile)$/, @args;
+   }
+
for my $name (@args) {
my $base = basename($name);
 
-- 
2.11.0


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

Bug#853405: fix ftbfs with GCC 7

[Matthias Klose]

Control: tags -1 + patch

patch at
http://launchpadlibrarian.net/331968322/freecontact_1.0.21-5build1_1.0.21-5ubuntu1.diff.gz

Bug#870766: android-platform-development FTCBFS: uses the build architecture toolchain

[Helmut Grohne]

Source: android-platform-development
Version: 7.0.0+r33-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

android-platform-development fails to cross build from source, because
it uses the build architecture toolchain. Wrapping make in dh_auto_build
fixes that as debhelper knows how to pass cross compilers to make.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru android-platform-development-7.0.0+r33/debian/changelog 
android-platform-development-7.0.0+r33/debian/changelog
--- android-platform-development-7.0.0+r33/debian/changelog 2017-04-24 
23:57:00.0 +0200
+++ android-platform-development-7.0.0+r33/debian/changelog 2017-08-04 
22:54:21.0 +0200
@@ -1,3 +1,10 @@
+android-platform-development (7.0.0+r33-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross compilers to make (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 04 Aug 2017 22:54:21 +0200
+
 android-platform-development (7.0.0+r33-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru android-platform-development-7.0.0+r33/debian/rules 
android-platform-development-7.0.0+r33/debian/rules
--- android-platform-development-7.0.0+r33/debian/rules 2017-04-24 
23:57:00.0 +0200
+++ android-platform-development-7.0.0+r33/debian/rules 2017-08-04 
22:54:18.0 +0200
@@ -10,7 +10,7 @@
dh $@
 
 override_dh_auto_build:
-   make -f debian/etc1tool.mk
+   dh_auto_build --buildsystem=makefile -- -f debian/etc1tool.mk
pandoc -s -o debian/etc1tool.1 debian/etc1tool.1.md
 
 override_dh_auto_clean:

Bug#869662: gvfs-backends: gvfs-nfs not possible to mount nfs exports with option secure

[Stefan Tatschner]

On Tue, Jul 25, 2017 at 7:33 PM, Simon McVittie  wrote:
> On Tue, 25 Jul 2017 at 14:47:46 +0200, Stefan Tatschner wrote:
>> it is not possible to mount an nfs share using nautilus (which in turn uses
>> gvfs-nfs) that is exported with the "secure" option. The nfs secure option is
>> the default for nfs exports. It means, that the nfs server does not accept 
>> connections
>> from an unprivileged source port (portno < 1024).
>
> The "secure" option is meant to mean exactly "only root can mount this".
> gvfs isn't root. You asked for it, you got it? :-)

root, or processes with cap_net_bind_service, which is also not root.
You mentioned it, you got it? Just kidding. :)

>> - Set the cap_net_bind_service capability on the binary 
>> "/usr/lib/gvfs/gvfsd-nfs"
>
> That would mean that servers believe that gvfsd-nfs is a trusted,
> root-owned process (inasmuch as they trust other machines on the network,
> which they probably should not), even when it isn't. Misguided though the
> "secure" option is, that seems misleading at best, and in the worst case
> potentially a security vulnerability.

The "secure" option at most prevents that malicious software on the
*client* mounts the nfs share. Beyond that, the secure options does
not add further protection on the client side, e.g. since if the nfs
share *is* already mounted, then a local attacker can access the
share. Nfs exports should only be exposed in trusted networks; such
networks can be created by authenticating each node using strong
cryptographic technologies like kerberos (nfsv4) or point to point vpn
tunnels (wireguard, ipsec, ...). From a security perspective the nfs
"secure" option is very weak and I cannot recommend to rely on that
option for system/network security.

At least I can see your point and IMO it makes sense to maybe not add
"cap_net_bind_service". Instead I suggest developping a polkit rule
that a user with admin caps must confirm an nfs mount request with his
password. Without any of these the gvfs GUI capabilities for nfs are
not usable. That might be the reason why the arch folks have added
cap_net_bind_service to the binary, as recommended in the
documentation (I have posted the relevant links in the first email).

Stefan

Bug#870767: gitlab: editing issues does not work

[Dominik George]

Package: gitlab
Version: 8.13.11+dfsg1-8
Severity: important

The "Save changes" button in "Edit issue" leads to a 404 error and does not 
save the issue.

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

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

Versions of packages gitlab depends on:
ii  adduser   3.115
ii  asciidoctor   1.5.4-2
ii  bc1.06.95-9+b3
ii  bundler   1.13.6-2
ii  dbconfig-pgsql2.0.8
ii  debconf [debconf-2.0] 1.5.61
ii  git   1:2.11.0-3
ii  gitlab-shell  3.6.6-4
ii  gitlab-workhorse  0.8.5+debian-3+b2
ii  init-system-helpers   1.48
ii  libjs-chartjs 1.0.2-1
ii  libjs-clipboard   1.4.2-1
ii  libjs-fuzzaldrin-plus 0.3.1+git.20161008.da2cb58+dfsg-4
ii  libjs-graphael0.5+dfsg-1
ii  libjs-jquery-cookie   11-3
ii  libjs-jquery-history  11-3
ii  libjs-jquery-nicescroll   3.6.6-1
ii  lsb-base  9.20161125
ii  nginx 1.10.3-1+deb9u1
ii  nginx-full [nginx]1.10.3-1+deb9u1
ii  nodejs4.8.2~dfsg-1
ii  openssh-client1:7.4p1-10+deb9u1
ii  postfix [mail-transport-agent]3.1.4-7
ii  postgresql-client 9.6+181
ii  postgresql-client-9.6 [postgresql-client  9.6.3-3
ii  postgresql-contrib9.6+181
ii  rake  10.5.0-2
ii  redis-server  3:3.2.6-1
ii  ruby  1:2.3.3
ii  ruby-ace-rails-ap 4.1.1-1
ii  ruby-activerecord-session-store   1.0.0-2
ii  ruby-acts-as-taggable-on  4.0.0-2
ii  ruby-addressable  2.4.0-1
ii  ruby-after-commit-queue   1.3.0-1
ii  ruby-akismet  2.0.0-1
ii  ruby-allocations  1.0.3-1+b2
ii  ruby-asana0.4.0-1
ii  ruby-attr-encrypted   3.0.1-2
ii  ruby-babosa   1.0.2-2
ii  ruby-base32   0.3.2-3
ii  ruby-bootstrap-sass   3.3.5.1-5
ii  ruby-browser  2.2.0-2
ii  ruby-cal-heatmap-rails3.6.0+dfsg-1
ii  ruby-carrierwave  0.10.0+gh-4
ii  ruby-charlock-holmes  0.7.3+dfsg-2+b3
ii  ruby-chronic  0.10.2-3
ii  ruby-chronic-duration 0.10.6-1
ii  ruby-coffee-rails 4.1.0-2
ii  ruby-coffee-script-source 1.10.0-1
ii  ruby-connection-pool  2.2.0-1
ii  ruby-creole   0.5.0-2
ii  ruby-d3-rails 3.5.6+dfsg-1
ii  ruby-default-value-for3.0.1-1
ii  ruby-devise   4.2.0-1
ii  ruby-devise-two-factor3.0.0-2
ii  ruby-diffy3.0.6-1
ii  ruby-doorkeeper   4.2.0-3
ii  ruby-dropzonejs-rails 0.7.1-1
ii  ruby-email-reply-parser   0.5.8-1
ii  ruby-fog-aws  0.12.0-1
ii  ruby-fog-azure0.0.2-1
ii  ruby-fog-core 1.42.0-1
ii  ruby-fog-google   0.3.2-1
ii  ruby-fog-local0.3.0-1
ii  ruby-fog-openstack0.1.6-4
ii  ruby-fog-rackspace0.1.1-4
ii  ruby-fogbugz  0.2.1-3
ii  ruby-font-awesome-rails   4.6.3.0-2
ii  ruby-gemnasium-gitlab-service 0.2.6-1
ii  ruby-gemojione3.1.0-2
ii  ruby-github-linguist  4.7.2-2
ii  ruby-github-markup1.5.1+dfsg-1
ii  ruby-gitlab-flowdock-git-hook 1.0.1-2
ii  ruby-gitlab-git   10.7.0-1
ii  ruby-gollum-lib   4.2.1+debian-1
ii  ruby-gon  6.1.0-1
ii  ruby-grape0.16.2-2
ii  ruby-grape-entity 0.6.0-1
ii  ruby-hamlit   2.7.5-1
ii  ruby-health-check 2.4.0-1
ii  

Bug#870728: mc: random crash on startup (SIGSEGV)

[Denis Briand]

severity 870728 minor
forwarded 870728 https://midnight-commander.org/ticket/3846
thanks

Thank you Paul.
As I said on IRC, it is a very particular case.
So I switch this bug to minor and I forward it to upstream.

To summarize here our IRC chat:

Step to reproduce:
$ MALLOC_PERTURB_=254 MALLOC_CHECK_=2 mc
then during the startup: hit "Ctrl+x g" keys combo

Important: you must hit "Ctrl+x g" keys before the panels are displayed.
To reproduce this long start, you have got 370 sub-directories in the
current directory.

regards

Denis Briand


pgpveE8t5APL0.pgp
Description: PGP signature

Bug#495400: apr_1.3.2-3(m68k/experimental): test suite fails

[John Paul Adrian Glaubitz]

> Not sure if m68k is alive anymore. The build log urls are not reachable
> anymore this bug report is no longer useful. Closing.

Well, maybe you should just ask people instead of just closing bug
reports without further notice?

> I doubt that anyone is interested in debugging m68k issues

How do you know without sending an email to debian-68k@l.d.o?

Here's a current build log [1]. m68k is alive and kicking with full
C++11 support and over 10700 out of 12000 packages being up-to-date.

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=apr=m68k=1.6.2-1=1501871250=0

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

Bug#870765: libdaemon: Move doxygen and lynx to Build-Depends-Indep

[Daniel Schepler]

Source: libdaemon
Version: 0.14-6
Severity: wishlist

libdaemon is currently involved in build dependency cycles such as:

libdaemon Build-Depends on lynx
lynx Build-Depends on openssh-client
openssh Build-Depends on libgtk-3-dev
gtk+3.0 Build-Depends on libcups2-dev
cups Build-Depends on libavahi-client-dev
avahi Build-Depends on libdaemon-dev

If src:libdaemon could move lynx to Build-Depends-Indep, that would
break this cycle - and as far as I can tell, lynx is only used to
create a README file which goes into lynx-doc anyway.  I would think
doxygen could also be moved to Build-Depends-Indep.
-- 
Daniel Schepler

Bug#870334: pkg-perl-autopkgtest: revisiting smoke prove --recurse

[Alex Muntada]

Niko Tyni:

> Any urgency this issue had is gone now that you did all the work of
> fixing the --recurse regressions. Many thanks for that :)
> 
> I think I'm leaving this for now. We can see if it becomes a problem
> later, and if not, just close this.

Agreed.

Thanks both for your work!
Alex



signature.asc
Description: PGP signature

Bug#862644: O: libproc-syncexec-perl -- spawn processes but report exec() errors properly

[Christoph Biedl]

retitle 862644 ITA: libproc-syncexec-perl -- spawn processes but report exec() 
errors properly
thanks

> The current maintainer of libproc-syncexec-perl, Roderick Schertler 
> ,
> is apparently not active anymore.  Therefore, I orphan this package now.

In spite of a pretty low popcon rank my gut feeling tells me this
package should stay in Debian. So I intent to put it under the pkg-perl
team's umbrella.

Christoph


signature.asc
Description: Digital signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Bill Allombert]

On Fri, Aug 04, 2017 at 11:59:40AM -0700, Don Armstrong wrote:
> > An O: bug means that it is confirmed that the package is orphaned, and
> > gives permission to everyone to adopt the package immediately.
> 
> So just file an an Intent-To-Orphan bug. [This why I suggested to file
> the bug against the package, and not against wnpp.]
> 
> In N days, the bug can be filed against 

Nowadays orphaning is done by reuploading the package with the
maintainer set to the QA group rather than using a O: wnpp bug.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#870764: pump FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: pump
Version: 0.8.24-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

pump fails to cross build from source, because it uses the build
architecture toolchain. Wrapping the $(MAKE) invocation through
dh_auto_build fixes the cross build, because dh_auto_build knows how to
pass the cross toolchain to make. Please consider applying the attached
patch.

Helmut
diff -u pump-0.8.24/debian/changelog pump-0.8.24/debian/changelog
--- pump-0.8.24/debian/changelog
+++ pump-0.8.24/debian/changelog
@@ -1,3 +1,10 @@
+pump (0.8.24-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross compilers to make (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 04 Aug 2017 22:38:42 +0200
+
 pump (0.8.24-7) unstable; urgency=low
 
   * Adopted package (Closes: #506508)
diff -u pump-0.8.24/debian/rules pump-0.8.24/debian/rules
--- pump-0.8.24/debian/rules
+++ pump-0.8.24/debian/rules
@@ -32,7 +32,7 @@
 build: setup
dh_testdir

-   $(MAKE) -C build pump SHOME=$(CURDIR)
+   dh_auto_build --sourcedirectory=build -- pump SHOME=$(CURDIR)
 
 clean: unpatch
dh_testdir
diff -u pump-0.8.24/debian/control pump-0.8.24/debian/control
--- pump-0.8.24/debian/control
+++ pump-0.8.24/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Philippe Coval 
 Standards-Version: 3.8.4
-Build-Depends: libpopt-dev, debhelper (>= 5), quilt
+Build-Depends: libpopt-dev, debhelper (>= 7), quilt
 Vcs-git: git://git.debian.org/git/collab-maint/pump.git
 Vcs-Browser: http://git.debian.org/?p=collab-maint/pump.git
 

Bug#839172: TC decision regarding #741573 menu policy not reflected yet

[Sean Whitton]

control: tag -1 +pending

Hello Didier,

On Fri, Aug 04, 2017 at 11:22:28AM +0200, Didier 'OdyX' Raboud wrote:
> I now gathered some old memories and remembered that there was indeed a bug 
> about this that got stalled: #707851 (which was the TC bug). See from message 
> #475 (September 2015), where I tried to push a wording quite similar to yours 
> to Policy:
> 
> > +Applications that are registred in the desktop menu shall not also
> > +provide a Debian menu file for the same application.
> [...]
> So… I'm fine with your wording, but thought it'd be useful to point at the 
> previous discussion about this very subject.

Thank you for digging this up!

I have no desire to argue in favour of either your patch or mine, but
since mine has been okayed by three TC members in this bug, in the
interests of getting this bug closed, I've gone ahead and applied it.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#841297: grub-efi: no symbol table, ask for key on boot

[Micha Lenk]

Package: grub-efi-amd64
Version: 2.02~beta3-5
Followup-For: Bug #841297

Since upgrading from Jessie to Stretch I am affected by this bug too.

A similar issue seems to be reported in the Ubuntu bug tracker here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1633839
There the suggested fix was to run 'grub-install' and 'update-grup' again,
which unfortunately did NOT fix the issue for me.

I wonder whether the issue could be related to my system only capable to boot a
32-bit EFI boot loader (i.e. no 64-bit EFI boot loader), even though the system
is running a 64 bit kernel.

How do I get rid of this extra delay when booting the system?

If you need more information, please let me know.

Cheers,
Micha


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/hardfisk--vg-root / xfs rw,relatime,attr2,inode64,noquota 0 0
/dev/sda2 /boot ext2 rw,relatime,block_validity,barrier,user_xattr,acl 0 0
/dev/sda1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
/dev/mapper/hardfisk--vg-home /home xfs rw,relatime,attr2,inode64,noquota 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  
3754402e-03a3-4c71-bc20-2610b76b8c92
else
  search --no-floppy --fs-uuid --set=root 3754402e-03a3-4c71-bc20-2610b76b8c92
fi
font="/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=de_DE
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  
3754402e-03a3-4c71-bc20-2610b76b8c92
else
  search --no-floppy --fs-uuid --set=root 3754402e-03a3-4c71-bc20-2610b76b8c92
fi
insmod png
if background_image /grub/.background_cache.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-b9c32958-bc41-40ef-9ae9-968ec54700d4' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  
3754402e-03a3-4c71-bc20-2610b76b8c92
else
  search --no-floppy --fs-uuid --set=root 
3754402e-03a3-4c71-bc20-2610b76b8c92
fi
echo'Linux 4.9.0-3-amd64 wird geladen …'
linux   /vmlinuz-4.9.0-3-amd64 root=/dev/mapper/hardfisk--vg-root ro  
quiet
echo'Initiale Ramdisk wird geladen …'
initrd  /initrd.img-4.9.0-3-amd64
}
submenu 'Erweiterte Optionen für Debian GNU/Linux' $menuentry_id_option 

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Fri, Aug 04, 2017 at 11:59:40AM -0700, Don Armstrong wrote:
> On Fri, 04 Aug 2017, Adrian Bunk wrote:
>...
> > Uploaders is not the only option for doing that, but any change should
> > include provising more reliable information - not less reliable
> > information.
> 
> In practice, Uploaders often only includes people who have ever uploaded
> the package, not everyone who is on (or still on) the team. I you'll
> have better luck with a who-uploads equivalent.

In practice, Uploaders often includes active team members who work
in git, but one specific team member does all the uploads.

I already gave the lintian package as an example for that.

And in the other direction what you describe would leave no way for
a person to make it visible that he has left the team.

> > An O: bug means that it is confirmed that the package is orphaned, and
> > gives permission to everyone to adopt the package immediately.
> 
> So just file an an Intent-To-Orphan bug. [This why I suggested to file
> the bug against the package, and not against wnpp.]
>...

There is no Intent-To-Orphan bug.

And whenever possible the process should work by first confirming
that a person or team is MIA, and then orphan everything that was 
maintained by that person or team.

In a more general note, I am a bit puzzled that it is so controversial 
that machine-readable team membership information is important and
should continue to be available.

cu
Adrian

-- 

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

Bug#870763: torsocks: Package description makes safety promises that upstream prefers not to

[intrigeri]

Source: torsocks
Version: 2.2.0-1
Severity: important

I've been made aware that it's trivial for an application wrapped with
torsocks to bypass torification. According to upstream, torsocks does
attempt (by design) to protect against a wrapped application that
actively tries to escape torification. So we should rephrase the
package description accordingly.

Bug#870762: filters FTCBFS: strips using the build architecture strip

[Helmut Grohne]

Source: filters
Version: 2.55-2
Severity: normal
Tags: upstream patch
User: helm...@debian.org
Usertags: rebootstrap

filters fails to cross build from source, because it strips at
installation time (via install -s). Since it uses the build architecture
strip, this breaks cross building and it also breaks -dbgsym packages.
After removing -s, filters cross builds successfully. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru filters-2.55/debian/changelog filters-2.55/debian/changelog
--- filters-2.55/debian/changelog   2016-12-08 17:08:58.0 +0100
+++ filters-2.55/debian/changelog   2017-08-04 22:16:40.0 +0200
@@ -1,3 +1,10 @@
+filters (2.55-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: do not strip during installation. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 04 Aug 2017 22:16:40 +0200
+
 filters (2.55-2) unstable; urgency=medium
 
   * Build-Depend on libfl-dev (Closes: #846423)
diff --minimal -Nru filters-2.55/debian/patches/nostrip.patch 
filters-2.55/debian/patches/nostrip.patch
--- filters-2.55/debian/patches/nostrip.patch   1970-01-01 01:00:00.0 
+0100
+++ filters-2.55/debian/patches/nostrip.patch   2017-08-04 22:16:37.0 
+0200
@@ -0,0 +1,21 @@
+From: Helmut Grohne 
+Subject: defer stripping to dh_strip
+
+Doing otherwise breaks cross building and -dbgsym packages.
+
+Index: filters-2.55/Makefile
+===
+--- filters-2.55.orig/Makefile
 filters-2.55/Makefile
+@@ -9,11 +9,6 @@
+ export CFLAGS
+ INSTALL_PROGRAM = install
+ 
+-# DEB_BUILD_OPTIONS suport, to control binary stripping.
+-ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
+-INSTALL_PROGRAM += -s
+-endif
+-
+ all:  $(OTHER) $(BUILD)
+ 
+ install:  $(BUILD) $(OTHER)
diff --minimal -Nru filters-2.55/debian/patches/series 
filters-2.55/debian/patches/series
--- filters-2.55/debian/patches/series  1970-01-01 01:00:00.0 +0100
+++ filters-2.55/debian/patches/series  2017-08-04 22:15:33.0 +0200
@@ -0,0 +1 @@
+nostrip.patch

Bug#839172: TC decision regarding #741573 menu policy not reflected yet

[David Bremner]

Sean Whitton  writes:

> diff --git a/policy.xml b/policy.xml
> index 3daa532..934a85b 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -8990,14 +8990,8 @@ Reloading description 
> configuration...done.
>  receive extra contributions such as translations.
>
>
> -Packages can, to be compatible with Debian additions to some
> -window managers that do not support the FreeDesktop standard, also
> -provide a Debian menu file, following the
> -Debian menu policy, which can be found in the
> -menu-policy files in the
> -debian-policy package.  It is also available
> -from the Debian web mirrors at  -
> url="https://www.debian.org/doc/packaging-manuals/menu-policy/;>https://www.debian.org/doc/packaging-manuals/menu-policy/.
> +If a package installs a FreeDesktop desktop entries, it must
> +not also install a Debian menu entry.
>
>  
>
> -- 
> Sean Whitton

I looked at the older version from Didier, and this one. Both ok for me,
but I have a slight preference for the shorter version. So consider
Sean's proposal seconded.

d


signature.asc
Description: PGP signature

Bug#865866: libreoffice-writer crash on startup Debian 9 i386 arch

[Hans]

Hi folks,

here is another trick:

1. Just install linux-image-4.9.0-0-*** from backports. 

2. Then boot with it, and libreoffice will start.

3. Now reboot and start with the actual kernel i.e. 4.11-**

4. Do NOT delete ~/.config/libreoffice!!!

5. Voila, libreoffice is starting again with the latest kernel.

6. Hint: backup ~/.config/libreoffice

Happy hacking!

Best

Hans

Bug#853409:

[Mario.Limonciello]

This particular problem is fixed upstream but not yet in a release of fwupdate.
https://github.com/rhboot/fwupdate/commit/cd8f7d79f84155d1dfbff3bb169558a8b06fb719

Bug#870615: debian-installer: FTBFS on armhf: missing firefly-rk3288/u-boot.img

[Vagrant Cascadian]

Control: tags 870615 pending

On 2017-08-03, Vagrant Cascadian wrote:
> Control: severity 870615 important
>
> On 2017-08-03, Vagrant Cascadian wrote:
>> On 2017-08-03, Cyril Brulebois wrote:
>>> d-i now FTBFSes on armhf, due to:
>>> ,---[ hd-media ]---
>>> | gen-hd-image: Installing /usr/lib/u-boot/firefly-rk3288/u-boot-spl.rksd 
>>> at sector 64 ...
>>> | gen-hd-image: Installing /usr/lib/u-boot/firefly-rk3288/u-boot.img at 
>>> sector 256 ...
>>> | config/armhf//hd-media.cfg:33: recipe for target 
>>> 'hd-media_images_concatenateable' failed
> ...
>>> I suppose this is due to this change in u-boot on 2017-08-01:
>>> |  u-boot (2017.07+dfsg1-2) unstable; urgency=medium
>>> |  .
>>> |* u-boot-rockchip:
>>> |  - Ship u-boot.bin in firefly-rk3288 instead of u-boot.img.
>>> |  - Add NEWS file explaining the change for firefly-rk3288.
>>>
>>> See https://tracker.debian.org/news/860117
> ...
>> This may actually require changing the d-i code(the new method requires
>> appending two things together before dd'ing them, rather that dd'ing two
>> things at specific locations), or more changes to u-boot (I could
>> pregenerate that part in u-boot, though that means shipping redundant
>> bits).

I went with the latter approach, so u-boot-rockchip includes a single
binary that debian-installer can use.


>> Might be best to temporarily disable the firefly-rk3288 in d-i until I
>> figure out what's best to do...
>
> I've disabled it in git for now, will explore a proper fix soon.

And now fixed in u-boot 2017.07+dfsg1-3 (just uploaded), corresponding
fix in debian-installer pushed to git.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#870761: micropolis-activity FTCBFS: uses the build architecture strip

[Helmut Grohne]

Source: micropolis-activity
Version: 0.0.20071228-8
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

micropolis-activity's build systems strips both at build time (via an
explicit strip invocation) and at installation time (via install -s).
Since both use the build architecture strip, micropolis-activity fails
to cross build from source. Stripping also breaks generation of -dbgsym
packages. The attached patch removes such stripping and makes a cross
build succeed. Please consider applying it.

Helmut
diff --minimal -Nru micropolis-activity-0.0.20071228/debian/changelog 
micropolis-activity-0.0.20071228/debian/changelog
--- micropolis-activity-0.0.20071228/debian/changelog   2015-10-31 
23:23:42.0 +0100
+++ micropolis-activity-0.0.20071228/debian/changelog   2017-08-04 
21:54:04.0 +0200
@@ -1,3 +1,10 @@
+micropolis-activity (0.0.20071228-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Do not strip during build or install. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 04 Aug 2017 21:54:04 +0200
+
 micropolis-activity (0.0.20071228-8) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru 
micropolis-activity-0.0.20071228/debian/patches/makefile.patch 
micropolis-activity-0.0.20071228/debian/patches/makefile.patch
--- micropolis-activity-0.0.20071228/debian/patches/makefile.patch  
2015-10-31 23:23:42.0 +0100
+++ micropolis-activity-0.0.20071228/debian/patches/makefile.patch  
2017-08-04 21:53:59.0 +0200
@@ -48,7 +48,7 @@
 index bdf5847..a09c6f5 100644
 --- a/src/sim/makefile
 +++ b/src/sim/makefile
-@@ -23,10 +23,12 @@ OPTFLAGS = -O3
+@@ -23,11 +23,13 @@
  DEFINES = -DIS_LINUX -DORIGINAL_MONSTER_BEHAVIOUR #-DNO_AIRCRASH
  
  CFLAGS += $(OPTFLAGS) $(DEFINES) -Wall
@@ -58,14 +58,16 @@
  #LDFLAGS = -Bstatic
  LDFLAGS=-L/usr/X11/lib -L/usr/X11R6/lib
 -
+-INSTALL = install -s
 +LDFLAGS += `dpkg-buildflags --get LDFLAGS`
- INSTALL = install -s
++INSTALL = install
  
  INCLUDES = \
+   -Iheaders \
 diff --git a/src/tcl/makefile b/src/tcl/makefile
 index 006b435..d38642e 100644
 --- a/src/tcl/makefile
 +++ b/src/tcl/makefile
 @@ -24,10 +24,11 @@
  
  TCL_LIBRARY = /usr/local/lib/tcl
@@ -248,3 +250,15 @@
  WIDGOBJS = \
tkbutton.o \
tkentry.o \
+Index: micropolis-activity-0.0.20071228/Makefile
+===
+--- micropolis-activity-0.0.20071228.orig/Makefile
 micropolis-activity-0.0.20071228/Makefile
+@@ -31,7 +31,6 @@
+ 
+ res/sim: src/sim/sim
+   cp src/sim/sim $@
+-  strip $@
+ 
+ src/sim/sim: tcl tk tclx sim
+   @#

Bug#709384: dh_installinit: Please add an option to no enable the service at installation

[Michael Biebl]

On Fri, 30 Dec 2016 22:33:52 +0100 Evgeni Golov  wrote:
> [ only 3 years later… ]
> 
> On Mon, Jan 27, 2014 at 01:32:35AM +0100, Laurent Bigonville wrote:
> > Le Sat, 25 Jan 2014 15:40:18 -0400,
> > Joey Hess  a écrit :
> > 
> > > Laurent Bigonville wrote:
> > > > Now that the usage of /etc/default/* file to prevent a service to
> > > > start is discouraged, it might be interesting to add an option that
> > > > allow the maintainer to not automatically enable the service at
> > > > installation.
> > > 
> > > Isn't that what dh_installinit --no-start does?
> > > 
> > 
> > dh_installinit --no-start prevents the service to be started at the
> > installation of the package. But the service is still enabled, this
> > means that the service will be started at the next reboot of the
> > machine.
> 
> --no-start will also prevent the service to be restarted during upgrade,
> which one still want to do, even if the service is not enabled-by-default.
> 
> > What I was proposing here is to prevent the call to update-rc.d.
> 
> Actually, you'd need a call to update-rc.d, but not with "defaults" as
> parameter, but with "disabled-if-new" (or similar, this is not-existant
> today) as you want:
>   * not to enable the service if it was disabled
>   * update the service if it was enabled

The canonical way to disable a SysV init script is to turn the SXX
symlinks into KXX symlinks.
You can use update-rc.d foo disable|enable nowadays for that.
See man update-rc.d.

A dh_installinit --no-enable could thus be implemented by generating
code to run
update-rc.d foo defaults
update-rc.d foo disable




signature.asc
Description: OpenPGP digital signature

Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`

[Michael Biebl]

On Fri, 09 Jun 2017 17:48:59 +0100 Alan Jenkins
> There were two reasons `mask` was used here.
> 
> 1. #722521.  Removing a package naturally deletes most of its files, including
>deleting the systemd service unit.  However the system V init script is
>preserved, because it might include user changes.  This can work OK under
>system V init, but systemd also picks up the initscript, and will show it
>as a started service in messages, logs, `systemctl list-units` etc.
> 
> #722521 seems perfectly possible to resolve, without resorting to masking.

How?



signature.asc
Description: OpenPGP digital signature

Bug#617285: pptpsetup: use absolute path for pptp in tunnel file

[Christoph Biedl]

tags upstream confirmed
thanks

Stefan Kisdaroczi wrote...

> Please consider applying the attached patch. It should not break anything for 
> users using pptp as root, but works for more secure setup's using a non-root 
> user too.

That still seems a wise thing to do. James?

Christoph


signature.asc
Description: Digital signature

Bug#835451: debian-policy: Building as root should be discouraged

[Sean Whitton]

On Thu, Aug 03, 2017 at 03:43:56PM +, Mike Gabriel wrote:
> I am not saying that the build target must not be empty. I can be empty but
> the build-a ... build-n dependecies have to be moved away from the binary
> target and have to be made dependencies of the build target (which can only
> have deps but no own instructions).
> 
> And if that makes packages buggy, then they are actually quite buggy,
> because the build-a ... build-n get executed in a fakeroot concept by design
> of dpkg-buildpackage. And IMHO this should definitely be avoided.

Just to be clear, I do agree with you that this situation where they are
deps of the binary target is bad.

Interested to hear what Santiago thinks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#809637: debian/copyright checks fail on upstream filenames containing blanks

[Sean Whitton]

Hello Mike,

On Thu, Aug 03, 2017 at 03:09:30PM +, Mike Gabriel wrote:
> How would differentiate between a blank in a file name and a blank as a
> separator?

If you needed blanks in filenames, you'd use a line-based list.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#870760: RFS: openldap/2.4.45+dfsg-1~bpo9+1

[Ryan Tandy]

Package: sponsorship-requests
Severity: normal

Dear mentors and backporters,

I am looking for a sponsor to upload openldap to stretch-backports. I 
have built and tested the package in a clean stretch chroot.


While the libraries and tools are fairly stable, the server (slapd) is 
more of a moving target, and users often request to be able to run the 
latest upstream version on stable. I have maintained openldap backports 
in wheezy-bpo and jessie-bpo for the same reason.


The source package can be found on mentors.d.n:

https://mentors.debian.net/debian/pool/main/o/openldap/openldap_2.4.45+dfsg-1~bpo9+1.dsc

This upload will be NEW in stretch-backports. The changes since the 
version in stretch are listed below.


Thanks for considering,

Ryan

openldap (2.4.45+dfsg-1~bpo9+1) stretch-backports; urgency=medium

 * Rebuild for stretch-backports.
 * Revert "Fix build with Heimdal 7.2.0" as stretch contains a lower version
   of heimdal.

-- Ryan Tandy   Wed, 02 Aug 2017 09:05:55 -0700

openldap (2.4.45+dfsg-1) unstable; urgency=medium

 * New upstream release.
   - fixed a use-after-free in GnuTLS options handling
 (ITS#8385) (Closes: #820244) (LP: #1557248)
   - fixed unsafe concurrent SASL calls causing memory corruption
 (ITS#8648) (Closes: #860947) (LP: #1688575)
   - fixed syncrepl infinite looping with multi-master delta-syncrepl
 (ITS#8432) (Closes: #868753)
 * Rebase patches to apply cleanly:
   - do-not-second-guess-sonames
   - no-AM_INIT_AUTOMAKE
 * Drop patches applied upstream:
   - ITS-8554-kFreeBSD-is-like-BSD.patch
   - ITS-8644-wait-for-slapd-to-start-in-test064.patch
   - ITS-8655-paged-results-double-free.patch
 * Upgrade to debhelper compat level 10.
   - Depend on debhelper 10.
   - Stop enabling parallel and autoreconf explicitly. They are now enabled
 by default.
   - Drop dh-autoreconf from build-depends since debhelper requires it.
 * Add -Wno-format-extra-args to CFLAGS to reduce the noise in the build
   logs, as this warning is emitted on each use of the Debug() macro.
 * Drop libldap-2.4-4-dbg and slapd-dbg binary packages in favour of
   automatic dbgsym packages.
 * Update Standards-Version to 4.0.0; no changes required.
 * Drop Priority and Section from binary package stanzas when they only
   duplicate information from the source stanza.
 * Update Priority of slapd-smbk5pwd and libldap2-dev to optional to match
   the archive.
 * Remove retired developer, Roland Bauerschmidt, from Uploaders.
   (Closes: #856422)
 * Remove Timo Aaltonen from Uploaders, with his agreement.
 * debian/patches/ITS8650-retry-gnutls_handshake-after-GNUTLS_E_AGAIN.patch:
   If gnutls_handshake() returns EAGAIN, call it again. Fixes TLS handshake
   failures when the ServerHello message exceeds 16K.
   (ITS#8650) (Closes: #861838)
 * Drop time from Build-Depends. The upstream testsuite no longer calls it.

-- Ryan Tandy   Thu, 27 Jul 2017 18:04:41 -0700

openldap (2.4.44+dfsg-8) unstable; urgency=medium

 * Disable test060-mt-hot on ppc64el temporarily to avoid failing tests until
   the underlying kernel bug #866122 is fixed.
 * Fix FTBFS with Heimdal 7.2.0: Drop patch heimdal-fix as the
   hdb_generate_key_set_password change was reverted in heimdal. Depend on an
   appropriate minimum version of heimdal.

-- Ryan Tandy   Sun, 16 Jul 2017 12:57:41 -0700

openldap (2.4.44+dfsg-7) unstable; urgency=medium

 * Relax the dependency of libldap-2.4-2 on libldap-common to also permit
   later versions. (Closes: #860774)

-- Ryan Tandy   Tue, 27 Jun 2017 18:53:12 -0700

openldap (2.4.44+dfsg-6) unstable; urgency=medium

 * Update the list of non-translatable strings for the
   slapd/ppolicy_schema_needs_update template. Thanks Ferenc Wágner.
 * Fix upgrade failure when olcSuffix contains a backslash. (Closes: #864719)

-- Ryan Tandy   Mon, 26 Jun 2017 19:42:02 -0700

Bug#646881: pptp-linux: pptpsetup fails to properly store password with quotation mark (") in /etc/ppp/chap-secrets

[Christoph Biedl]

tags 646881 confirmed upstream
thanks

Daniel Kahn Gillmor wrote...

> I was using a randomly-generated password that happened to have a
> quotation mark (") in it (let's pretend it was: sek"rit).  I entered it
> as requested by pptpsetup.
> 
> it stored it in /etc/ppp/chap-secrets like this:
> 
> dkg remoteendpoint "sek"rit" *

That should be pretty easy to fix by adding

$PASSWORD =~ s/([^\x20\x21\x23-\x7e])/sprintf ("\\x%02x", ord ($1))/eg;

before writing out. I took the opportunity to check how ppp deals with
characters in the secrets outside 7bit printable, including the \0 one.
Long story short, they *should* work but you can expect a bad time until
things work as expected. So they should best be avoided.

Christoph



signature.asc
Description: Digital signature

Bug#793057: ITP: godot -- open source MIT licensed game engine

[Kienan Stewart]

I'm also interested in helping to package godot for debian.

With the current stable of godot (2.1.3-stable), there's an incompatibility 
with the SSL version shipped in stretch (upstream issue: 
https://github.com/godotengine/godot/issues/8624)

I was able to build with: scons platform=x11 target=release_debug bits=64 
use_llvm=yes builtin_openssl=yes but I'm not sure if this will cause problems

Thanks,
Kienan


signature.asc
Description: PGP signature

Bug#870758: lintian: [checks/python] Please check for packages build-depending on "python-sphinx | python3-sphinx"

[Chris Lamb]

tags 870758 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=1bba812c0a588d7567fb542832ff2edf6f77555e


Regards,

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

Bug#870758: lintian: [checks/python] Please check for packages build-depending on "python-sphinx | python3-sphinx"

[Chris Lamb]

Package: lintian
Version: 2.5.52
Severity: wishlist

Hi,

Please check for packages that alternatively Build-Depend on the Python
2 or Python 3 version of the Sphinx documentation generator.

The 2.x series of Python is due for deprecation and will not be
maintained past 2020.


Regards,

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

Bug#870759: rman FTCBFS: fails running tests despite DEB_BUILD_OPTIONS=nocheck

[Helmut Grohne]

Source: rman
Version: 3.2-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

rman fails to cross build from source, because it fails running tests it
shouldn't be running under DEB_BUILD_OPTIONS=nocheck. After honouring
that flag, it cross builds successfully. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru rman-3.2/debian/changelog rman-3.2/debian/changelog
--- rman-3.2/debian/changelog   2013-05-08 22:56:54.0 +0200
+++ rman-3.2/debian/changelog   2017-08-04 21:25:02.0 +0200
@@ -1,3 +1,10 @@
+rman (3.2-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Honour DEB_BUILD_OPTIONS=nocheck (closes: #-1)
+
+ -- Helmut Grohne   Fri, 04 Aug 2017 21:25:02 +0200
+
 rman (3.2-7) unstable; urgency=low
 
   * [432cb27] Fix "format not a string" error.
diff --minimal -Nru rman-3.2/debian/rules rman-3.2/debian/rules
--- rman-3.2/debian/rules   2011-05-30 19:04:24.0 +0200
+++ rman-3.2/debian/rules   2017-08-04 21:25:00.0 +0200
@@ -2,8 +2,10 @@
 %:
dh $@
 
+ifeq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)
 override_dh_auto_test:
./debian/autotest/autotest
+endif
 
 override_dh_auto_install:
# Add here commands to install the package into debian/rman.