Bug#877145: evolution-data-server: Evolution can't update radicale calendar events error code 411 Length required

[Diane Trout]

> 
> I tried building a copy of evolution-data-server with the patch in
> 3.26.0, but it didn't work for me. Although maybe I need to reboot.

I apparently hadn't installed enough evolution-data-server packages, or
hadn't restarted them. after installing more things and killing more e-
d-s processes the patch does work, and I was able to update an event.

https://git.gnome.org/browse/evolution-data-server/commit/?id=ef8b553fd

Bug#877145: evolution-data-server: Evolution can't update radicale calendar events error code 411 Length required

[Diane Trout]

Package: evolution-data-server
Version: 3.26.0-1
Severity: normal

Dear Maintainer,

A recent upgrade broke Evolutions ability to update calendar events on the
radicale caldav server.

The underlying problem is due to evolution-data-server gaining support
for Transport-encoding: chunked, and radicale not supporting chunked.

There's apparently a patch at
https://bugzilla.gnome.org/show_bug.cgi?id=787656

We also tried figuring it out on the Radical side
https://github.com/Kozea/Radicale/issues/709

I tried building a copy of evolution-data-server with the patch in
3.26.0, but it didn't work for me. Although maybe I need to reboot.

Diane

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

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

Versions of packages evolution-data-server depends on:
ii  evolution-data-server-common  3.26.0-1
ii  gnome-keyring 3.20.1-1
ii  libc6 2.24-17
ii  libcamel-1.2-60   3.26.0-1
ii  libdb5.3  5.3.28-13.1
ii  libebackend-1.2-103.26.0-1
ii  libebook-1.2-19   3.26.0-1
ii  libebook-contacts-1.2-2   3.26.0-1
ii  libecal-1.2-193.26.0-1
ii  libedata-book-1.2-25  3.26.0-1
ii  libedata-cal-1.2-28   3.26.0-1
ii  libedataserver-1.2-22 3.26.0-1
ii  libgcr-base-3-1   3.20.0-5.1
ii  libgcr-ui-3-1 3.20.0-5.1
ii  libgdata220.17.9-1
ii  libglib2.0-0  2.54.0-1
ii  libgoa-1.0-0b 3.26.0-1
ii  libgtk-3-03.22.21-1
ii  libgweather-3-6   3.26.0-1
ii  libical2  2.0.0-0.5+b1
ii  libldap-2.4-2 2.4.45+dfsg-1
ii  libpango-1.0-01.40.12-1
ii  libsecret-1-0 0.18.5-3.1
ii  libsoup2.4-1  2.60.0-1
ii  libxml2   2.9.4+dfsg1-4

evolution-data-server recommends no packages.

Versions of packages evolution-data-server suggests:
ii  evolution  3.26.0-1

-- no debconf information

Bug#877144: remote builder loses packages if master is unreachable

[Marc Haber]

Package: mini-buildd
Version: 1.0.31
Severity: important

Hi,

I have a mini-buildd "master" on amd64 which uses a Banana Pi as remote
to build packages for armhf. systemd on the armhf takes about ten hours
to build.

After such an ordeal, the mini-buildd on the Banana Pi decided that the
master was unreachable (it was, since the hardware was turned off at
night, I forgot that there was still a build running), duly logged that,
and threw away the packages it had built. At least ~mini-buildd is
empty.

The master still has the remote as "building", the remote says
"uploading, no route to host". I wonder which packages it is uploading.

A bit of error recovery is in order. While I would like mini-buildd to
recover automatically, I don't mind having to make a manual transaction
to trigger the upload, as long as no packages are lost.

And, how do I get rid of the debris?

Greetings
Marc

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf (armv7l)

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

Versions of packages mini-buildd depends on:
ii  adduser  3.116
ii  debconf  1.5.63
ii  debootstrap  1.0.91
ii  devscripts   2.17.10
ii  dirmngr  2.2.1-1
ii  dpkg-dev 1.18.24
ii  gnupg2.2.1-1
ii  init-system-helpers  1.49
ii  libjs-jquery 3.2.1-1
ii  libjs-sphinxdoc  1.6.4-1
ii  lintian  2.5.53
ii  lsb-base 9.20170808
ii  mini-buildd-common   1.0.31
ii  python   2.7.14-1
ii  python-cherrypy3 3.5.0-2
ii  python-daemon2.1.2-1
ii  python-mini-buildd   1.0.31
ii  python-pyftpdlib 1.5.1-4
ii  reprepro 5.1.1-1
ii  sbuild   0.73.0-4
ii  schroot  1.6.10-4
ii  sudo 1.8.21p2-1

Versions of packages mini-buildd recommends:
ii  python-apt  1.4.0~beta3+b1

Versions of packages mini-buildd suggests:
pn  binfmt-support
ii  btrfs-progs   4.12-1
ii  haveged   1.9.1-6
ii  lvm2  2.02.173-1
pn  qemu-user-static  

-- Configuration Files:
/etc/default/mini-buildd changed [not included]
/etc/schroot/mini-buildd/fstab-generic changed [not included]
/etc/schroot/setup.d/15mini-buildd-workarounds changed [not included]
/etc/sudoers.d/mini-buildd-sudoers [Errno 13] Permission denied: 
'/etc/sudoers.d/mini-buildd-sudoers'

-- debconf information excluded

Bug#877143: ITP: node-node-dir -- asynchronous file and directory operations for Node.js

[Pirate Praveen]

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

* Package name: node-node-dir
  Version : 0.1.17
  Upstream Author : Nathan Cartwright 
(https://github.com/fshost)
* URL : https://github.com/fshost
* License : Expat
  Programming Lang: JavaScript
  Description : asynchronous file and directory operations for Node.js

 A lightweight Node.js module with methods for some common directory and
file
 operations, including asynchronous, non-blocking methods for recursively
 getting an array of files, subdirectories, or both, and methods for
 recursively, sequentially reading and processing the contents of files in a
 directory and its subdirectories, with several options available for added
 flexibility if needed.
 .
 Node.js is an event-based server-side JavaScript engine.

In dependency chain of gitlab 9.5



signature.asc
Description: OpenPGP digital signature

Bug#874420: node-babel-cli: /usr/bin/babel is already provided by openbabel

[Pirate Praveen]

Control: tags -1 pending

On Mon, 25 Sep 2017 11:00:23 +0530 Pirate Praveen 
wrote:
> If not I'll rename babel to babeljs.

Changed babel to babeljs. Its waiting in NEW (changed from contrib to main).



signature.asc
Description: OpenPGP digital signature

Bug#873080: SDDM

[Michael Haag]

OK. It's not absolutely certain the problem lies ONLY with SDDM. But
since BIOS, Grub and KDE have no problem with Nvidia, it certainly does
seem LIKELY the problem is with SDDM. It's not like there hasn't been a
long history of issues with SDDM.

--
"Sometimes I sit and think, and sometimes I just sit." -- Courtney
Barnett

On Fri, Sep 29, 2017, at 04:44, Lisandro Damián Nicanor Pérez Meyer
wrote:
> On 27 September 2017 at 04:00, MH  wrote:
> > This bug, previously reported by me, still exists in sddm 0.15.0-1
> >
> > Additional information:
> >
> > The problem (black/blank screen) exhibits only when connected via an A/V
> > receiver.  Sddm displays normally when attached directly to the TV (4k).
> >
> > NVidia softare correctly enumerates the A/V device, so the latter must be
> > sending correct EDID info. Also, it reports 1080p resolution, which is the
> > maximum input resolution for the A/V device.
> >
> > The problem clearly lies with sddm.
> 
> Why? There is no full evidence of that.
> 
> SDDM might be using something the nVidia card does not supports, that
> wouldn't be the first time it happens I'm afraid. The fact that you
> see this only with SDDM doesn't means it's SDDM's fault.
> 
> Now if you could reproduce the bug with another video card, specially
> with open drivers, that would be another story (or not).

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Graham Inggs]

I've been working on this transition in Ubuntu and here are some of my notes:

rgtk2 and rggobi now FTBFS on s390x, they also fail in a Buster chroot
on zelenka.debian.org so I don't believe it is a regression in R, but
the binaries will need to be removed.

r-bioc-iranges, r-bioc-variantannotation and r-cran-dplyr need to be
updated to work with R 3.4.2.  You can see from the autopkgtest
results [1][2] that started failing on 2017-09-24.  Unfortunately,
r-cran-dplyr 0.5.0-1 has always failed its autopkgtests, so the
results aren't useful.


[1] https://ci.debian.net/packages/r/r-bioc-iranges/unstable/amd64/
[2] https://ci.debian.net/packages/r/r-bioc-variantannotation/unstable/amd64/

Bug#877142: lintian: tried to issue unknown tag example-script-uses-deprecated-nodejs-location at /srv/lintian.debian.org/lintian/checks/scripts.pm line 227.

[Niels Thykier]

Package: lintian
Version: 2.5.53
Severity: serious

Hi,

lintian is currently unable to process the following 3 packages due to
a bug in lintian:

[2017-09-29T00:01:46]:   [lintian] error processing node-argparse/1.0.7-1 
(time: 1.540s)
[2017-09-29T00:01:47]:   [lintian] error processing node-commander/2.4.0-1 
(time: 1.426s)
[2017-09-29T00:01:49]:   [lintian] error processing node-get/1.1.5+ds1-2 (time: 
1.478s)


The error is:

"""
N: Processing binary package node-get (version 1.1.5+ds1-2, arch all) ...
C: node-get binary (1.1.5+ds1-2) [all]: no-ctrl-scripts
I: node-get binary (1.1.5+ds1-2) [all]: 
extended-description-is-probably-too-short
W: node-get binary (1.1.5+ds1-2) [all]: wrong-section-according-to-package-name 
node-get => javascript
W: node-get binary (1.1.5+ds1-2) [all]: package-contains-timestamped-gzip 
usr/share/doc/node-get/buildinfo_all.gz
tried to issue unknown tag example-script-uses-deprecated-nodejs-location at 
/srv/lintian.debian.org/lintian/checks/scripts.pm line 227.
internal error: cannot run scripts check on package 
binary:node-get/1.1.5+ds1-2/all
warning: skipping check of binary:node-get/1.1.5+ds1-2/all
"""

(The same error occurs for all 3 binaries AFAICT).

This bug may prevent new uploads of these affected packages (as I
recall, the FTP master's reject uploads where lintian fails).
Accordingly, I have filed it as a serious bug.

Thanks,
~Niels

Bug#877141: qbittorrent doesn't report full disk

[Harald Dunkel]

Package: qbittorrent
Version: 3.3.15-1

If the destination disk is full, then qbittorrent doesn't 
tell.


Regards
Harri

Bug#874715: Re%3A Bug#874715 mesa Games like Counter-Strike Global Offensive dont%0A start after upgrading mesa to 17.2.0-2

[Dominik Kupschke]

Yes I am fine with changing the severity to important.

This issue affects all of my steam games (> 100), so the migration of the 
packet to testing could be bad for a lot of people.

Regards
Dominik

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

Bug#820659:

[Yangfl]

To whom interested in packing this,

I've tried packing this for some time (which is far from complete). I
have to say webmin is the most awkward and terrible project I've ever
seen, which contains tons of outdated sources and countless fixed
paths. If you really want to pack webmin, please make sure you have
enough time to deal with these.

Bug#877140: ITP: node-symbol-observable -- Symbol.observable ponyfill

[Pirate Praveen]

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

* Package name: node-symbol-observable
  Version : 1.0.4
  Upstream Author : Ben Lesh 
* URL : https://github.com/blesh/symbol-observable#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Symbol.observable ponyfill

 This module provides Symbol.observable for older JavaScript
environments which
 does not implement it natively.
 .
 Node.js is an event-based server-side JavaScript engine.

In dependency list of gitlab 9.5



signature.asc
Description: OpenPGP digital signature

Bug#876837: [Pkg-fonts-devel] Bug#876837: Bug#876837: Bug#876837: Bug#876837: fonttools bug

[Fabian Greffrath]

Am Freitag, den 29.09.2017, 00:05 + schrieb Holger Levsen:
> Sure, I'm happy to do that! Did you push everything to git?

Yes, I have pushed everything. The latest commit is my attempt to merge
both of our efforts, i.e. what *should* have become revision -4.

Please upload a new revision, I'll keep my fingers off of this package
until this happened. ;)

Cheers,

 - Fabian


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

Bug#877139: ITP: node-babel-preset-es3 -- Preset for Babel's ES3 transformations

[Pirate Praveen]

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

* Package name: node-babel-preset-es3
  Version : 1.0.1
  Upstream Author : Simen Bekkhus 
* URL : https://github.com/simenb/babel-preset-es3#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Preset for Babel's ES3 transformations

 Babel preset for two ES3 transforms
`transform-es3-member-expression-literals`
 and `transform-es3-property-literals`. This presets adds the two transforms
 for ES3 syntax compatibility.
 .
 Babel is a JavaScript compiler to use next generation JavaScript, today.
 .
 Node.js is an event-based server-side JavaScript engine.



signature.asc
Description: OpenPGP digital signature

Bug#871733: RFP: qcad -- computer-aided design (CAD) application for 2D design and drafting

[Yangfl]

Hi,

I'm interested in CAD but don't have much experience in CAD on linux.
Could you explain a bit how qcad is different from librecad?

Thanks.

On Fri, 11 Aug 2017 00:41:55 +0200 "W. Martin Borgert"
 wrote:
> Package: wnpp
> Severity: wishlist
>
> * Package name: qcad
>   Version : 3.16.1
>   Upstream Author : Andrew Mustun, RibbonSoft
> * URL : https://qcad.org/
> * License : GPL3
>   Programming Lang: C++
>   Description : computer-aided design (CAD) application for 2D design and 
> drafting
>
> QCAD was part of Debian until squeeze, but has been removed
> because of license problems and a fork, librecad, emerged.
> Meanwhile, it looks like the license problems of QCAD may be
> solved. Also, QCAD, according to some of its users, has
> developed features not yet present in librecad. It therefore
> makes sense to package QCAD in addition to librecad.
>
>

Bug#876095: O: bash-completion -- programmable completion for the bash shell

[Gabriel F. T. Gomes]

On 22 Sep 2017, Axel Beckert wrote:

>> I cloned the package repository and I understood how syncing with
>> upstream was designed (very clever, imo).  
>
>Nice! Didn't look that deep into the package.

At the time I sent my first email, I was unaware of the existence of
git-buildpackage.  It turned out that bash-completion is maintained
with it, so that's where the clever syncing with upstream comes from.

(As a side not, I'm glad I learned about it, because it helped me in
the other packaging I am working on (pragha).  I converted it to
git-builbpackage)

>> So, I synced it and I began working on the removal of the patches
>> that are no longer required, or that do not apply cleanly.

That's done (see links to git repo below).

>Yes, but IMHO it's definitely a good thing to synchronise these bug
>reports (well, those which are still valid) to Github or the Debian
>Bug Tracking system — especially since Alioth is going away towards
>end of this year.
>[...]
>Not sure if it might be a good idea to make a dump or copy of all
>these bug reports as I don't expect them to be preserved when Alioth
>is decommissioned.

I saved the results of your search filter as a CSV, so that I have more
time to work on it.  Should that be enough?

>Please tell me if not being a member of the bash-completion project on
>Alioth hinders you in doing that work. (That should still be
>possible.)

So far so good.

I'm keeping my work on a personal git server [1], but as I mentioned in
the RFS for pragha [2], I don't think that's a good place to keep these
files in the long term, because I do not fully trust myself as a
sysadmin.

[1]
http://git.inconstante.eti.br/?p=bash-completion-debian.git;a=shortlog;h=refs/heads/unstable
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876667#26


Finally, I'd like to ask for some help...

After I upgraded bash-completion to newer upstream releases, I got some
conflicts during the installation of the package.  For instance, it
complained about the existence of the completion file for adb:

dpkg: error processing archive 
/home/gftg/debian/bash-completion/bash-completion_2.7-1_all.deb (--install):
 trying to overwrite '/usr/share/bash-completion/completions/adb', which is 
also in package adb 1:7.0.0+r33-2

I know that bts (from packages devscripts) and mount/umount (from
package mount) have the same problem, because I locally removed them
from bash-completion (just to test).

However, I don't know what to do about it.  There should be certainly
more files that collide this way, but I only saw these in my computer,
because I have few packages installed.

If you have any tips on how to proceed, I'd be glad to listen. :)


Kind regards,
Gabriel


pgpDbLjhbMGuk.pgp
Description: OpenPGP digital signature

Bug#876154: digikam: FTBFS: error: missing binary operator before token "defined"

[Steve Robbins]

On Tuesday, September 19, 2017 12:27:56 PM CDT Nobuhiro Iwamatsu wrote:

>  #if not defined(__APPLE__) && defined(__GNUC__)
>  ^~~
> /build/digikam-5.3.0/core/libs/database/imagehistory/imagehistorygraph_boost
> .h:1557:9: error: missing binary operator before token "defined"


> Could you check this problem?

Thanks, confirmed.  It seems that someone has turned on -fno-operator-names.  
This was not present before [1].  RedHat has the same issue reported [2].


[1] https://buildd.debian.org/status/fetch.php?
pkg=digikam&arch=amd64&ver=4%3A5.3.0-1&stamp=1479074086&raw=0
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1423329


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

Bug#876752: libllvm5.0: Can not install libllvm5.0:i386 from latest unstable

[Gianluigi Tiesi]

Package: libllvm5.0
Version: 1:5.0-2
Followup-For: Bug #876752

Hi according buildd the package is not buildable on many architectures:

https://buildd.debian.org/status/package.php?p=llvm-toolchain-5.0&suite=sid

Dependency installability problem for llvm-toolchain-5.0 on i386:

llvm-toolchain-5.0 build-depends on:
- libctypes-ocaml-dev:i386
libctypes-ocaml-dev depends on missing:
- ocaml-nox-4.02.3:i386


I think it should depend on 4.05.0 if possible since
4.02.3 is gone

Regards


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

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

Versions of packages libllvm5.0 depends on:
ii  libc6   2.24-17
ii  libedit23.1-20170329-1
ii  libffi6 3.2.1-6
ii  libgcc1 1:7.2.0-7
ii  libstdc++6  7.2.0-7
ii  libtinfo5   6.0+20170902-1
ii  zlib1g  1:1.2.8.dfsg-5

libllvm5.0 recommends no packages.

libllvm5.0 suggests no packages.

Bug#876949: stretch-pu: package postfix/3.1.6-0+deb9u1

[Scott Kitterman]

On Thursday, September 28, 2017 12:45:50 PM Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On 2017-09-28 12:04, Scott Kitterman wrote:
> > On Thursday, September 28, 2017 06:50:26 AM Adam D. Barratt wrote:
> >> Control: tags -1 + moreinfo
> >> 
> >> On Wed, 2017-09-27 at 01:14 -0400, Scott Kitterman wrote:
> >> > This upload is intended to solve several problems.  While it's
> >> > somewhat
> >> > unusual, since it includes new upstream releases, the upstream
> >> > changes are
> >> > very targetted and all things that I believe are appropriate to fix
> >> > in a
> >> 
> >> > stable update:
> >> [...]
> >> 
> >> > Additionally, there's a packaging fix for a bug that broke multi-
> >> > instance.
> >> 
> >> The latter (#873957) doesn't appear to have been applied in unstable
> >> yet. Are the upstream fixes relevant to unstable and applied there?
> > 
> > The packaging fix has not yet been applied in unstable yet (it's in the
> > packaging git staged for the next upload, which I expect to be today or
> > tomorrow due to a new upstream release that just came out).
> > 
> > All the upstream fixes are already in Unstable/Buster.
> 
> Thanks for the information.
> 
> Given the timescales, please go ahead with the upload and we'll assume
> it's made it to unstable before the point release.

Both this and the unstable upload are done now.

Thanks,

Scott K

Bug#877138: ITP: node-any-observable -- Support any Observable library and polyfill

[Pirate Praveen]

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

* Package name: node-any-observable
  Version : 0.2.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/any-observable#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Support any Observable library and polyfill

 Let your library support any ES 2015 (ES6) compatible `Observable` and
leave
 the choice to application authors. The application can *optionally*
register
 its preferred `Observable` implementation and it will be exported when
 requiring `any-observable` from library code.
 .
 Node.js is an event-based server-side JavaScript engine.

In dependency chain of gitlab 9.5



signature.asc
Description: OpenPGP digital signature

Bug#877137: dman: broken error reporting

[astian]

Package: debian-goodies
Version: 0.75
Severity: minor

Dear Maintainer,

I think that commit 27ac5129ce187c6f571cac25ef70553bb9c9d475 broke the
error message dman used to produce when it failed to fetch some page.
It says "not found: " but it no longer says what it didn't find.

I actually run into this several weeks ago and was ready to send a patch
back then, but then I ended up rewriting most when I decided to
implement caching.

I can't remember where I read that the maintainer doesn't like
maintaining scripts longer than a couple hundred lines, and this one
grew to about 390 so in the end I didn't send it and forgot about the
bug report.  Today I remembered and here it is.

Cheers.

PS1: In case someone wants the modified script:
https://paste.debian.net/988250/

PS2: In the beginning I took notes of the changes made (later ones went
unrecorded): https://paste.debian.net/988249

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

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

Versions of packages debian-goodies depends on:
ii  curl  7.55.1-1
ii  dctrl-tools [grep-dctrl]  2.24-2+b1
ii  perl  5.26.0-8
ii  python3   3.5.3-3
ii  whiptail  0.52.20-1+b1

Versions of packages debian-goodies recommends:
ii  lsof  4.89+dfsg-0.1

Versions of packages debian-goodies suggests:
ii  lsb-release 9.20170808
ii  popularity-contest  1.65
ii  xdg-utils   1.1.1-1
ii  zenity  3.24.0-1

-- no debconf information

Bug#877136: ITP: node-any-promise -- Resolve any installed ES6 compatible promise

[Pirate Praveen]

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

* Package name: node-any-promise
  Version : 1.3.0
  Upstream Author : Kevin Beaty
* URL : http://github.com/kevinbeaty/any-promise
* License : Expat
  Programming Lang: JavaScript
  Description : Resolve any installed ES6 compatible promise

 Let your library support any ES 2015 (ES6) compatible `Promise` and
leave the
 choice to application authors. The application can *optionally*
register its
 preferred `Promise` implementation and it will be exported when requiring
 `any-promise` from library code.
 .
 Node.js is an event-based server-side JavaScript engine.

In gitlab 9.5 dependency chain.



signature.asc
Description: OpenPGP digital signature

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Dirk Eddelbuettel]

On 28 September 2017 at 22:22, Andreas Tille wrote:
| I wonder if we could teach dh-r to make sure that is added to arch:all
| packages.  I'm converting all packages I'm touching to dh-r anyway.
| 
| At least a lintian warning might help.
| 
| Kind regards
| 
|   Andreas (after having uploaded 4 arch:all packages and converted
|two of these from cdbs to dh-r)

Yes, maybe indeed. dh-r is one of those many things on the always-growing
TODO list that I have not yet gotten to.

Dirk

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

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Dirk Eddelbuettel]

On 28 September 2017 at 18:53, Sébastien Villemot wrote:
| On Thu, Sep 28, 2017 at 07:04:51AM -0500, Dirk Eddelbuettel wrote:
| > 
| > On 28 September 2017 at 13:20, Sébastien Villemot wrote:
| > | On Thu, Sep 28, 2017 at 12:53:10PM +0200, Graham Inggs wrote:
| > | > On 28/09/2017 12:28, Sébastien Villemot wrote:
| > | > > Note that there are many arch:all R packages that will need sourceful 
upload
| > | > > (they are easy to identify on the transition tracker whose URL is 
above).
| > | > 
| > | > Besides r-cran-nlp which doesn't show up in the tracker, I've found 
several
| > | > other arch:all packages that don't depend on r-api-3, but do pick up a
| > | > dependency on r-api-3.4 after a rebuild:
| > | 
| > | This makes me wonder whether arch:all packages really need a dependency 
on r-api-*.
| > | 
| > | If this value really tracks an API, as advertised, it makes sense. But if 
it
| > | actually tracks an ABI, as in the present case, then this situation is
| > | suboptimal and complicates transition.
| > | 
| > | Maybe the best solution would therefore be to dissociate API and ABI 
tracking.
| > | 
| > | Moreover, packages automatically pick up a versioned dependency on 
r-base-core.
| > | But this should not be necessary since we now have ABI tracking. It makes
| > | dependencies uselessly tight.
| > | 
| > | Anyways, these (potential) improvements should probably wait for the next
| > | transition (planned in April if I understand correctly).
| > 
| > There transitions, and then there are transitions.  Let me explain:
| > 
| > - right now a subset of 'source: any' package needs a rebuild; here we could
| >   in fact discuss leaving 'source: all' out
| > 
| > - R 3.5.0 will need a rebuild of all 'source: any' packages
| > 
| > - In the past we rebuilds for nonAPI reasons: reorganisation of R's internal
| >   help system (and internal file format) was one
| > 
| > So we may as well through the big mantle of the so-called "API" transition
| > around all dependent packages.  But we don't _have to_ right now.
| > 
| > Can be argued either way. Do as you see fit.
| 
| I now understand that we ideally need two API/ABI-like values instead of one:
| 
| - one that is bumped when only arch:any packages need to be rebuilt
| 
| - the other one that is bumped when both arch:any and arch:all packages should
|   be rebuilt
| 
| The first value would appear in the Depends of arch:any package, but not of
| arch:all ones; the second value would appear in the Depends of both arch:any
| and arch:all.
| 
| Because, for this transition and for the next one (in April), we will have to
| make sourceful uploads of ~170 arch:all packages… that actually do not need to
| be rebuilt. And this is very painful because it must be done manually 
(contrary
| to rebuilds of arch:any packages that can be trigerred easily).
| 
| If we adopted this scheme right now, that would save us a lot of work for the
| April transition (but not for this one, because we first have to convert
| arch:all packages to the new scheme).
| 
| Please tell me what you think.

Well, sorry, but that is your baby now. I argued _this very issue of it being
different for R_ for two months or more, but nobody bought into it.

You all insisted on this approach which you now find more complicate, so here
it is.  Your deal now.

(For what it is worth, and the R / Debian itersection in particular, the
RcppAPT (source) package allows you to query R's and Debian's package
meta-data.  That was part of my analysis so I won't repeat it.  Happy to help
if there are questions.)

I'll happily deal with / help with technical questions, I am not that
interested in managing a technical issue I argued (in vain) against for some
time.

Sorry, Dirk

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

Bug#877135: apt-cacher-ng: userinfo is not properly encoded: acngtool fails and/or leaks credentials

[astian]

astian:
> Consider:
>
>  - AdminAuth: unexpected.tld:80/secret

I forgot to mention: Even though this suggests that unintended network
requests could be made, therefore (partially) leaking credentials to DNS, I
have found that the wrapped `IDlConFactory` (into `maintfac`) in function
`maint_job` seems to thwart that route, since its `CreateConnected` method
ignores arguments.

Cheers.

Bug#877135: apt-cacher-ng: userinfo is not properly encoded: acngtool fails and/or leaks credentials

[astian]

Package: apt-cacher-ng
Version: 3-5
Severity: normal
Control: tags -1 + patch

Dear Maintainer,

When generating URLs, apt-cacher-ng (acngtool in particular) does not
properly encode the "userinfo" component (used for credentials in Basic
or Digest HTTP authentication).  As a result, when such URLs are later
parsed in order to make HTTP requests, the URL components are
misinterpreted.

I discovered this after investigating why acngtool failed every time
when invoked by cron to perform maintenance.  The bug was triggered by
my administration credentials having a "/" character.

Later I noticed that if the credentials contain a "@" character,
acngtool will (partially) leak them in the error message printed upon
failure.

Consider:

  - AdminAuth: unexpected.tld:80/secret

  - AdminAuth: @dministrator:secret

Below I include a patch for consideration by someone familiar with
the codebase.  In my test build it appears to have fixed both issues,
although, I would like to mention that IMHO the URL parsing/encoding/decoding
is still too ad-hoc/klugy and likely to contain bugs, so please review.

Cheers.

PS: Sorry for the admittedly low effort in keeping the code style, I
just couldn't bring myself to do some things.

-- Package-specific info:

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

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

Versions of packages apt-cacher-ng depends on:
ii  adduser  3.116
ii  debconf  1.5.63
ii  dpkg 1.18.24
ii  init-system-helpers  1.49
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.24-17
ii  libgcc1  1:7.2.0-7
ii  liblzma5 5.2.2-1.3
ii  libssl1.11.1.0f-5
ii  libstdc++6   7.2.0-7
ii  libsystemd0  234-3
ii  libwrap0 7.6.q-26
ii  lsb-base 9.20170808
ii  zlib1g   1:1.2.8.dfsg-5

apt-cacher-ng recommends no packages.

Versions of packages apt-cacher-ng suggests:
ii  avahi-daemon  0.7-3
pn  doc-base  
ii  libfuse2  2.9.7-1

-- Configuration Files:
/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: 
'/etc/apt-cacher-ng/security.conf'

-- debconf information:
  apt-cacher-ng/gentargetmode: No automated setup
  apt-cacher-ng/port: keep
  apt-cacher-ng/bindaddress: keep
  apt-cacher-ng/proxy: keep
  apt-cacher-ng/tunnelenable: false
  apt-cacher-ng/cachedir: keep

---

--- apt-cacher-ng-3.orig/include/meta.h
+++ apt-cacher-ng-3/include/meta.h
@@ -311,6 +311,8 @@ mstring DosEscape(cmstring &s);
 // just the bare minimum to make sure the string does not break HTML formating
 mstring html_sanitize(cmstring& in);
 
+mstring UserinfoEscape(cmstring &s);
+
 #define pathTidy(s) { if(startsWithSz(s, "." SZPATHSEP)) s.erase(0, 2); 
tStrPos n(0); \
for(n=0;stmiss!=n;) { n=s.find(SZPATHSEP SZPATHSEP, n); if(stmiss!=n) 
s.erase(n, 1);}; \
for(n=0;stmiss!=n;) { n=s.find(SZPATHSEP "." SZPATHSEP, n); 
if(stmiss!=n) s.erase(n, 2);}; }
--- apt-cacher-ng-3.orig/source/acngtool.cc
+++ apt-cacher-ng-3/source/acngtool.cc
@@ -577,7 +577,7 @@ int maint_job()
tSS urlPath;
urlPath << "http://";;
if (!cfg::adminauth.empty())
-   urlPath << cfg::adminauth << "@";
+   urlPath << UserinfoEscape(cfg::adminauth) << "@";
if (hostaddr[0] == '/')
urlPath << "localhost";
else
@@ -1032,7 +1032,7 @@ int wcat(LPCSTR surl, LPCSTR proxy, IFit
if(!surl)
return 2;
string xurl(surl);
-   if(!url.SetHttpUrl(xurl))
+   if(!url.SetHttpUrl(xurl, false))
return -2;
dlcon dl(true, nullptr, pDlconFac);
 
--- apt-cacher-ng-3.orig/source/meta.cc
+++ apt-cacher-ng-3/source/meta.cc
@@ -252,11 +252,11 @@ bool tHttpUrl::SetHttpUrl(cmstring &sUrl

sHost=url.substr(hStart, hEndSuc-hStart);
 
-   // credentials might in there, strip them of
+   // credentials might be in there, strip them off
l=sHost.rfind('@');
if(l!=mstring::npos)
{
-   sUserPass=sHost.substr(0, l);
+   sUserPass = UrlUnescape(sHost.substr(0, l));
sHost.erase(0, l+1);
}
 
@@ -275,16 +275,22 @@ bool tHttpUrl::SetHttpUrl(cmstring &sUrl

strip_ipv6_junk:

+   bool host_appears_to_be_ipv6 = false;
if(sHost[0]=='[')
{
+   host_appears_to_be_ipv6 = true;
bCheckBrac=true;
sHost.erase(0,1);
}

-   if(sHost[sHost.length()-1]==']')
+   if (sHost[sHost.length()-1] == ']') {
+

Bug#877134: assimp: FTBFS on i386: can't cd to obj-i386-linux-gnu/doc

[Andreas Beckmann]

Source: assimp
Version: 4.0.1~dfsg-1~exp1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

assimp FTBFS on i386:

https://buildd.debian.org/status/fetch.php?pkg=assimp&arch=i386&ver=4.0.1%7Edfsg-1%7Eexp1&stamp=1505108449&raw=0

[...]
[100%] Linking CXX executable assimp
cd "/<>/obj-i686-linux-gnu/tools/assimp_cmd" && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/assimp_cmd.dir/link.txt --verbose=1
/usr/bin/c++  -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fopenmp -g -fvisibility=hidden -fPIC -Wall -std=c++0x  
-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -rdynamic 
CMakeFiles/assimp_cmd.dir/CompareDump.cpp.o 
CMakeFiles/assimp_cmd.dir/ImageExtractor.cpp.o 
CMakeFiles/assimp_cmd.dir/Main.cpp.o CMakeFiles/assimp_cmd.dir/WriteDumb.cpp.o 
CMakeFiles/assimp_cmd.dir/Info.cpp.o CMakeFiles/assimp_cmd.dir/Export.cpp.o  -o 
assimp  -L"/<>/obj-i686-linux-gnu"  
-L"/<>/obj-i686-linux-gnu/lib" 
-Wl,-rpath,"/<>/obj-i686-linux-gnu:/<>/obj-i686-linux-gnu/lib:/<>/obj-i686-linux-gnu/code:"
 ../../code/libassimp.so.4.0.1 -lz ../../contrib/irrXML/libIrrXML.a -lminizip 
-lrt 
make[4]: Leaving directory '/<>/obj-i686-linux-gnu'
[100%] Built target assimp_cmd
make[3]: Leaving directory '/<>/obj-i686-linux-gnu'
/usr/bin/cmake -E cmake_progress_start 
"/<>/obj-i686-linux-gnu/CMakeFiles" 0
make[2]: Leaving directory '/<>/obj-i686-linux-gnu'
dh_auto_build --buildsystem=pybuild -- \
-d port/PyAssimp/
I: pybuild base:184: /usr/bin/python setup.py build 
running build
running build_py
creating /<>/.pybuild/pythonX.Y_2.7/build/pyassimp
copying pyassimp/helper.py -> 
/<>/.pybuild/pythonX.Y_2.7/build/pyassimp
copying pyassimp/postprocess.py -> 
/<>/.pybuild/pythonX.Y_2.7/build/pyassimp
copying pyassimp/structs.py -> 
/<>/.pybuild/pythonX.Y_2.7/build/pyassimp
copying pyassimp/core.py -> 
/<>/.pybuild/pythonX.Y_2.7/build/pyassimp
copying pyassimp/material.py -> 
/<>/.pybuild/pythonX.Y_2.7/build/pyassimp
copying pyassimp/errors.py -> 
/<>/.pybuild/pythonX.Y_2.7/build/pyassimp
copying pyassimp/formats.py -> 
/<>/.pybuild/pythonX.Y_2.7/build/pyassimp
copying pyassimp/__init__.py -> 
/<>/.pybuild/pythonX.Y_2.7/build/pyassimp
I: pybuild base:184: /usr/bin/python3.6 setup.py build 
running build
running build_py
creating /<>/.pybuild/pythonX.Y_3.6/build/pyassimp
copying pyassimp/helper.py -> 
/<>/.pybuild/pythonX.Y_3.6/build/pyassimp
copying pyassimp/postprocess.py -> 
/<>/.pybuild/pythonX.Y_3.6/build/pyassimp
copying pyassimp/structs.py -> 
/<>/.pybuild/pythonX.Y_3.6/build/pyassimp
copying pyassimp/core.py -> 
/<>/.pybuild/pythonX.Y_3.6/build/pyassimp
copying pyassimp/material.py -> 
/<>/.pybuild/pythonX.Y_3.6/build/pyassimp
copying pyassimp/errors.py -> 
/<>/.pybuild/pythonX.Y_3.6/build/pyassimp
copying pyassimp/formats.py -> 
/<>/.pybuild/pythonX.Y_3.6/build/pyassimp
copying pyassimp/__init__.py -> 
/<>/.pybuild/pythonX.Y_3.6/build/pyassimp
I: pybuild base:184: /usr/bin/python3 setup.py build 
running build
running build_py
creating /<>/.pybuild/pythonX.Y_3.5/build/pyassimp
copying pyassimp/helper.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/pyassimp
copying pyassimp/postprocess.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/pyassimp
copying pyassimp/structs.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/pyassimp
copying pyassimp/core.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/pyassimp
copying pyassimp/material.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/pyassimp
copying pyassimp/errors.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/pyassimp
copying pyassimp/formats.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/pyassimp
copying pyassimp/__init__.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/pyassimp
cd obj-i386-linux-gnu/doc && doxygen Doxyfile
/bin/sh: 1: cd: can't cd to obj-i386-linux-gnu/doc
debian/rules:52: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2

Looks there is a mixture of DEB_*_MULTIARCH and DEB_*_GNU_TYPE being used
by the build process. These are not identical on i386.


Andreas

Bug#854568: grub2: Add support for modern sparc64 hardware

[John Paul Adrian Glaubitz]

On 09/29/2017 02:40 AM, John Paul Adrian Glaubitz wrote:
> Attaching an updated patch for the current 2.02-2 package.

Slightly updated to fix an FTBFS because of -Wmaybe-uninitalized.

Adrian

-- 
 .''`.  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
Description: Add support for sparc64
Author: Eric Snowberg 
Last-Update: 2017-09-29
Source: https://github.com/esnowberg/grub2-sparc/tree/sparc-next-v4

Index: grub2-2.02/grub-core/Makefile.core.def
===
--- grub2-2.02.orig/grub-core/Makefile.core.def
+++ grub2-2.02/grub-core/Makefile.core.def
@@ -270,6 +270,7 @@ kernel = {
   sparc64_ieee1275 = kern/sparc64/cache.S;
   sparc64_ieee1275 = kern/sparc64/dl.c;
   sparc64_ieee1275 = kern/sparc64/ieee1275/ieee1275.c;
+  sparc64_ieee1275 = disk/ieee1275/obdisk.c;
 
   arm = kern/arm/dl.c;
   arm = kern/arm/dl_helper.c;
Index: grub2-2.02/grub-core/boot/sparc64/ieee1275/boot.S
===
--- grub2-2.02.orig/grub-core/boot/sparc64/ieee1275/boot.S
+++ grub2-2.02/grub-core/boot/sparc64/ieee1275/boot.S
@@ -69,6 +69,10 @@ prom_seek_name:		.asciz "seek"
 prom_read_name:		.asciz "read"
 prom_exit_name:		.asciz "exit"
 grub_name:		.asciz "GRUB "
+#ifdef CDBOOT
+prom_close_name:	.asciz "close"
+#endif
+
 #define GRUB_NAME_LEN	5
 
 	.align	4
@@ -213,6 +217,12 @@ bootpath_known:
 	call	prom_call_3_1_o1
 #ifdef CDBOOT
 	 LDUW_ABS(kernel_size, 0x00, %o3)
+
+	GET_ABS(prom_close_name, %o0)
+	mov	1, %g1
+	mov	0, %o5
+	call	prom_call
+	 mov	BOOTDEV_REG, %o1
 #else
 	 mov	512, %o3
 #endif
Index: grub2-2.02/grub-core/commands/ls.c
===
--- grub2-2.02.orig/grub-core/commands/ls.c
+++ grub2-2.02/grub-core/commands/ls.c
@@ -201,6 +201,8 @@ grub_ls_list_files (char *dirname, int l
   if (grub_errno == GRUB_ERR_UNKNOWN_FS)
 	grub_errno = GRUB_ERR_NONE;
 
+  grub_device_close (dev);
+  dev = NULL;
   grub_normal_print_device_info (device_name);
 }
   else if (fs)
Index: grub2-2.02/grub-core/commands/nativedisk.c
===
--- grub2-2.02.orig/grub-core/commands/nativedisk.c
+++ grub2-2.02/grub-core/commands/nativedisk.c
@@ -66,6 +66,7 @@ get_uuid (const char *name, char **uuid,
   /* Firmware disks.  */
 case GRUB_DISK_DEVICE_BIOSDISK_ID:
 case GRUB_DISK_DEVICE_OFDISK_ID:
+case GRUB_DISK_DEVICE_OBDISK_ID:
 case GRUB_DISK_DEVICE_EFIDISK_ID:
 case GRUB_DISK_DEVICE_NAND_ID:
 case GRUB_DISK_DEVICE_ARCDISK_ID:
Index: grub2-2.02/grub-core/disk/ieee1275/obdisk.c
===
--- /dev/null
+++ grub2-2.02/grub-core/disk/ieee1275/obdisk.c
@@ -0,0 +1,1079 @@
+/* obdisk.c - Open Boot disk access.  */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2017 Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct disk_dev
+{
+  struct disk_dev *next;
+  struct disk_dev **prev;
+  /* open boot canonical name */
+  char *name;
+  /* open boot raw disk name to access entire disk */
+  char *raw_name;
+  /* grub encoded device name */
+  char *grub_devpath;
+  /* grub encoded alias name  */
+  char *grub_alias_devpath;
+  /* grub unescaped name */
+  char *grub_decoded_devpath;
+  grub_ieee1275_ihandle_t ihandle;
+  grub_uint32_t block_size;
+  grub_uint64_t num_blocks;
+  unsigned int log_sector_size;
+  grub_uint32_t opened;
+  grub_uint32_t valid;
+  grub_uint32_t boot_dev;
+};
+
+struct parent_dev
+{
+  struct parent_dev *next;
+  struct parent_dev **prev;
+  /* canonical parent name */
+  char *name;
+  char *type;
+  grub_ieee1275_ihandle_t ihandle;
+  grub_uint32_t address_cells;
+};
+
+static struct grub_scsi_test_unit_ready tur =
+{
+  .opcode = grub_scsi_cmd_test_unit_ready,
+  .lun = 0,
+  .reserved1 = 0,
+  .reserved2 = 0,
+  .reserved3 = 0,
+  .control = 0,
+};
+
+static int disks_enumerated = 0;
+static struct disk_dev *disk_devs = NULL;
+static struct parent_dev *parent_devs = NULL;
+
+static const

Bug#721358: coreutils: use dummy man when cross build

[Michael Stone]

On Fri, Sep 29, 2017 at 12:45:57AM +0200, Manuel A. Fernandez Montecelo wrote:

I was thinking of preparing an NMU for this, help2man issues are very
annoying to (re)bootstrap ports.

Michael, do you have any preference about how the solution should look
like?  Or would you reject a NMU at all?


I'd rather have a standardized build option to skip the documentation 
than something that sometimes builds man pages that don't match what's 
being built. In dreamland I think an even better option would be a 
mechanism (maybe in dpkg-buildpackage?) to set a build flag indicating 
that this should be a minimal build for bootstrapping (skip anything 
that needs to run natively or that might otherwise cause problems) and 
automatically sets the version string to something indicating it's a 
less-than-complete package. Putting some kind of unique hack or magic 
side effect into dozens of packages seems like a less-than-optimal 
solution.


Mike Stone

Bug#877133: sysfsutils: Package upgrade failure when /etc/sysfs.conf contains entries that fail

[Mike Hommey]

Source: sysfsutils
Version: 2.1.0+repack-4+b2
Severity: important

I've had the following lines in my /etc/sysfs.conf for years:
  bus/pci/drivers/radeon/:02:00.0/power_method = profile
  bus/pci/drivers/radeon/:02:00.0/power_profile = low

Retrospectively, I think that's because at the time I installed the
machine, the radeon driver didn't have dpm yet, which it now does.

And since it does, the radeon driver actually throws an EINVAL when
writing those sysfs prefs above:

https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/radeon/radeon_pm.c#L437-L440

because dpm is now the default, and you can't switch away from it.

Anyways, this probably was failing already at startup, which I failed to
see, until I upgraded from jessie to stretch, the process of which
failed because of the sysfsutils service restart during the package
upgrade.

This might be fair game, but the real problem is that it's impossible to
debug in a straightforward way: the startup script for the "service" is a
shell script that doesn't output anything useful in case of errors. All
I got was:
  Setting sysfs variables...sh: echo: I/O error

which doesn't tell you which one has failed.

So next, I tried sh -x /etc/init.d/sysfsutils start, but thanks to
systemd, that just called systemctl which reinvoked the script without
-x. So I ended up adding set -x to the script, which finally allowed me
to get some more in the systemd log, namely, the following output:

+ [ -f /sys/bus/pci/drivers/radeon/:02:00.0/power_method ]
+ echo -n profile
+ echo profile
sh: echo: I/O error

I'm not saying the script should come with set -x set, but at the very
least, it should print out something useful when something fails to be
set for some reason.

Mike

Bug#877132: rozofs: FTBFS: undefined reference to `rozofs_storcli_transform_inverse_check'

[Andreas Beckmann]

Source: rozofs
Version: 2.0.18-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

rozofs FTBFS in a up-to-date sid/experimental amd64 environment:

[ 92%] Linking C executable storcli
cd /build/rozofs-2.0.18/obj-x86_64-linux-gnu/src/storcli && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/storcli.dir/link.txt --verbose=1
/usr/bin/cc -g -O2 -fdebug-prefix-map=/build/rozofs-2.0.18=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fmessage-length=0 -O3 -DNDEBUG -D_GNU_SOURCE  -g  
-Wl,-z,relro -Wl,-z,now -rdynamic 
CMakeFiles/storcli.dir/rozofs_storcli_send_new.c.o 
CMakeFiles/storcli.dir/rozofs_storcli_lbg_cnf_supervision.c.o 
CMakeFiles/storcli.dir/rozofs_storcli_transform_utility.c.o 
CMakeFiles/storcli.dir/rozofs_storcli_transform.c.o 
CMakeFiles/storcli.dir/rozofs_storcli_mgt.c.o 
CMakeFiles/storcli.dir/rozofs_storcli_write.c.o 
CMakeFiles/storcli.dir/rozofs_storcli_nblock_init.c.o 
CMakeFiles/storcli.dir/storcli_main.c.o 
CMakeFiles/storcli.dir/rozofs_storcli_north_intf.c.o 
CMakeFiles/storcli.dir/storcli_stub.c.o 
CMakeFiles/storcli.dir/rozofs_storcli_read.c.o 
CMakeFiles/storcli.dir/rozofs_storcli_rebuild_prj.c.o 
CMakeFiles/storcli.dir/rozofs_storcli_reload_storage_config.c.o 
CMakeFiles/storcli.dir/storage_lbg.c.o 
CMakeFiles/storcli.dir/rozofs_storcli_cnx_supervisio
 n.c.o CMakeFiles/storcli.dir/rozofs_storcli_truncate.c.o 
CMakeFiles/storcli.dir/storcli_ring.c.o 
CMakeFiles/storcli.dir/rozofs_storcli_mojette_thread.c.o 
CMakeFiles/storcli.dir/rozofs_storcli_mojette_thread_intf.c.o 
CMakeFiles/storcli.dir/rozofs_storcli_delete.c.o 
CMakeFiles/storcli.dir/rozofs_storcli_wr_repair.c.o  -o storcli  
-L/build/rozofs-2.0.18/obj-x86_64-linux-gnu/rozofs ../../rozofs/librozofs.a 
-lpthread -lcrypt -lconfig 
CMakeFiles/storcli.dir/rozofs_storcli_transform_utility.c.o: In function 
`rozofs_storcli_transform_inverse_check_for_thread':
./obj-x86_64-linux-gnu/src/storcli/./src/storcli/rozofs_storcli_transform_utility.c:518:
 undefined reference to `rozofs_storcli_transform_inverse_check'
collect2: error: ld returned 1 exit status
src/storcli/CMakeFiles/storcli.dir/build.make:621: recipe for target 
'src/storcli/storcli' failed
make[4]: *** [src/storcli/storcli] Error 1

full log attached


Andreas


rozofs_2.0.18-2.log.gz
Description: application/gzip

Bug#877131: lua-torch-image: FTBFS: ./image.lua:156: [read_png] Error during init_io: IDAT: chunk data is too large

[Andreas Beckmann]

Source: lua-torch-image
Version: 0~20170420-g5aa1881-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

lua-torch-image FTBFS for me in a sid/experimental amd64 pbuilder chroot
with some test failures:

[...]
luajit: /usr/share/lua/5.1/torch/Tester.lua:363: An error was found while 
running tests!
stack traceback:
[C]: in function 'assert'
/usr/share/lua/5.1/torch/Tester.lua:363: in function 'run'
./image/test.lua:708: in function 'test'
(command line):1: in main chunk
[C]: at 0x5617972f11d0
Completed 74 asserts in 41 tests with ESC[0;32m0 failuresESC[0m and ESC[0;35m2 
errorsESC[0m

LoadPNG
 Function call failed
./image.lua:156: [read_png] Error during init_io: IDAT: chunk data is too large
stack traceback:
[C]: in function 'load'
./image.lua:156: in function 'loader'
./image.lua:388: in function 'load'
./image/test.lua:538: in function 'checkPNG'
./image/test.lua:549: in function <./image/test.lua:546>
[C]: in function 'xpcall'
/usr/share/lua/5.1/torch/Tester.lua:477: in function '_pcall'
/usr/share/lua/5.1/torch/Tester.lua:436: in function '_run'
/usr/share/lua/5.1/torch/Tester.lua:355: in function 'run'
./image/test.lua:708: in function 'test'
(command line):1: in main chunk
[C]: at 0x5617972f11d0


DecompressPNG
 Function call failed
./image.lua:156: [read_png] Error during init_io: IDAT: chunk data is too large
stack traceback:
[C]: in function 'load'
./image.lua:156: in function 'loader'
./image.lua:388: in function 'load'
./image/test.lua:578: in function <./image/test.lua:576>
[C]: in function 'xpcall'
/usr/share/lua/5.1/torch/Tester.lua:477: in function '_pcall'
/usr/share/lua/5.1/torch/Tester.lua:436: in function '_run'
/usr/share/lua/5.1/torch/Tester.lua:355: in function 'run'
./image/test.lua:708: in function 'test'
(command line):1: in main chunk
[C]: at 0x5617972f11d0


debian/rules:14: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1

full log attached


Andreas


lua-torch-image_0~20170420-g5aa1881-2.log.gz
Description: application/gzip

Bug#854568: grub2: Add support for modern sparc64 hardware

[John Paul Adrian Glaubitz]

Hi!

Attaching an updated patch for the current 2.02-2 package.

I am working now on integrating GRUB for sparc and sparc64 in debian-installer
and upstream has gotten new maintainers who have promised to get the sparc64
patches merged soonish [1].

Adrian

> [1] http://lists.gnu.org/archive/html/grub-devel/2017-09/msg00086.html

-- 
 .''`.  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
Description: Add support for sparc64
Author: Eric Snowberg 
Last-Update: 2017-09-29
Source: https://github.com/esnowberg/grub2-sparc/tree/sparc-next-v4

Index: grub2-2.02/grub-core/Makefile.core.def
===
--- grub2-2.02.orig/grub-core/Makefile.core.def
+++ grub2-2.02/grub-core/Makefile.core.def
@@ -270,6 +270,7 @@ kernel = {
   sparc64_ieee1275 = kern/sparc64/cache.S;
   sparc64_ieee1275 = kern/sparc64/dl.c;
   sparc64_ieee1275 = kern/sparc64/ieee1275/ieee1275.c;
+  sparc64_ieee1275 = disk/ieee1275/obdisk.c;
 
   arm = kern/arm/dl.c;
   arm = kern/arm/dl_helper.c;
Index: grub2-2.02/grub-core/boot/sparc64/ieee1275/boot.S
===
--- grub2-2.02.orig/grub-core/boot/sparc64/ieee1275/boot.S
+++ grub2-2.02/grub-core/boot/sparc64/ieee1275/boot.S
@@ -69,6 +69,10 @@ prom_seek_name:		.asciz "seek"
 prom_read_name:		.asciz "read"
 prom_exit_name:		.asciz "exit"
 grub_name:		.asciz "GRUB "
+#ifdef CDBOOT
+prom_close_name:	.asciz "close"
+#endif
+
 #define GRUB_NAME_LEN	5
 
 	.align	4
@@ -213,6 +217,12 @@ bootpath_known:
 	call	prom_call_3_1_o1
 #ifdef CDBOOT
 	 LDUW_ABS(kernel_size, 0x00, %o3)
+
+	GET_ABS(prom_close_name, %o0)
+	mov	1, %g1
+	mov	0, %o5
+	call	prom_call
+	 mov	BOOTDEV_REG, %o1
 #else
 	 mov	512, %o3
 #endif
Index: grub2-2.02/grub-core/commands/ls.c
===
--- grub2-2.02.orig/grub-core/commands/ls.c
+++ grub2-2.02/grub-core/commands/ls.c
@@ -201,6 +201,8 @@ grub_ls_list_files (char *dirname, int l
   if (grub_errno == GRUB_ERR_UNKNOWN_FS)
 	grub_errno = GRUB_ERR_NONE;
 
+  grub_device_close (dev);
+  dev = NULL;
   grub_normal_print_device_info (device_name);
 }
   else if (fs)
Index: grub2-2.02/grub-core/commands/nativedisk.c
===
--- grub2-2.02.orig/grub-core/commands/nativedisk.c
+++ grub2-2.02/grub-core/commands/nativedisk.c
@@ -66,6 +66,7 @@ get_uuid (const char *name, char **uuid,
   /* Firmware disks.  */
 case GRUB_DISK_DEVICE_BIOSDISK_ID:
 case GRUB_DISK_DEVICE_OFDISK_ID:
+case GRUB_DISK_DEVICE_OBDISK_ID:
 case GRUB_DISK_DEVICE_EFIDISK_ID:
 case GRUB_DISK_DEVICE_NAND_ID:
 case GRUB_DISK_DEVICE_ARCDISK_ID:
Index: grub2-2.02/grub-core/disk/ieee1275/obdisk.c
===
--- /dev/null
+++ grub2-2.02/grub-core/disk/ieee1275/obdisk.c
@@ -0,0 +1,1079 @@
+/* obdisk.c - Open Boot disk access.  */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2017 Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct disk_dev
+{
+  struct disk_dev *next;
+  struct disk_dev **prev;
+  /* open boot canonical name */
+  char *name;
+  /* open boot raw disk name to access entire disk */
+  char *raw_name;
+  /* grub encoded device name */
+  char *grub_devpath;
+  /* grub encoded alias name  */
+  char *grub_alias_devpath;
+  /* grub unescaped name */
+  char *grub_decoded_devpath;
+  grub_ieee1275_ihandle_t ihandle;
+  grub_uint32_t block_size;
+  grub_uint64_t num_blocks;
+  unsigned int log_sector_size;
+  grub_uint32_t opened;
+  grub_uint32_t valid;
+  grub_uint32_t boot_dev;
+};
+
+struct parent_dev
+{
+  struct parent_dev *next;
+  struct parent_dev **prev;
+  /* canonical parent name */
+  char *name;
+  char *type;
+  grub_ieee1275_ihandle_t ihandle;
+  grub_uint32_t address_cells;
+};
+
+static struct grub_scsi_test_unit_ready tur =
+{
+  .opcode = grub_scsi_cmd_test_unit_ready,
+  .lun = 0,
+  .reserved1 = 0,
+  .reserved2 = 0,
+  .reserved3 = 0,
+  .control = 0,
+};
+
+

Bug#877130: highwayhash: FTBFS with GCC 7: symbols files need to be updated

[Andreas Beckmann]

Source: highwayhash
Version: 0~20170419-g1f4a24f-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

highwayhash FTBFS in experimental (at least) since GCC 7 was made the
default compiler:

   dh_makeshlibs
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libhighwayhash0/DEBIAN/symbols doesn't match 
completely debian/libhighwayhash0.symbols
--- debian/libhighwayhash0.symbols (libhighwayhash0_0~20170419-g1f4a24f-2_amd64)
+++ dpkg-gensymbolskVaSJy   2017-09-20 04:10:32.280762154 +
@@ -33,7 +33,7 @@
  
_ZN11highwayhash23MedianAbsoluteDeviationIfEET_RKSt6vectorIS1_SaIS1_EES1_@Base 
0~20170419-g1f4a24f
  _ZN11highwayhash24InvariantCyclesPerSecondEv@Base 0~20170419-g1f4a24f
  _ZN11highwayhash3NowEv@Base 0~20170419-g1f4a24f
- _ZN11highwayhash4ModeIjEET_PKS1_m@Base 0~20170419-g1f4a24f
+#MISSING: 0~20170419-g1f4a24f-2# _ZN11highwayhash4ModeIjEET_PKS1_m@Base 
0~20170419-g1f4a24f
  _ZN11highwayhash5CpuidEjjPj@Base 0~20170419-g1f4a24f
  _ZN11highwayhash6ApicIdEv@Base 0~20170419-g1f4a24f
  _ZN11highwayhash6MedianIfEET_PSt6vectorIS1_SaIS1_EE@Base 0~20170419-g1f4a24f
@@ -57,9 +57,12 @@
  _ZNK11highwayhash14HighwayHashCatILj4EEclERA4_KmPKNS_10StringViewEmPm@Base 
0~20170419-g1f4a24f
  
_ZNSt20discard_block_engineISt26subtract_with_carry_engineImLm48ELm5ELm12EELm389ELm11EEclEv@Base
 0~20170419-g1f4a24f
  
_ZNSt24uniform_int_distributionImEclISt20discard_block_engineISt26subtract_with_carry_engineImLm48ELm5ELm12EELm389ELm11mRT_RKNS0_10param_typeE@Base
 0~20170419-g1f4a24f
- _ZNSt6vectorISt4pairIjiESaIS1_EE19_M_emplace_back_auxIJS1_EEEvDpOT_@Base 
0~20170419-g1f4a24f
- _ZNSt6vectorIiSaIiEE19_M_emplace_back_auxIJiEEEvDpOT_@Base 0~20170419-g1f4a24f
- _ZNSt6vectorIjSaIjEE19_M_emplace_back_auxIJjEEEvDpOT_@Base 0~20170419-g1f4a24f
+ 
_ZNSt6vectorISt4pairIjiESaIS1_EE17_M_realloc_insertIJS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 0~20170419-g1f4a24f-2
+#MISSING: 0~20170419-g1f4a24f-2# 
_ZNSt6vectorISt4pairIjiESaIS1_EE19_M_emplace_back_auxIJS1_EEEvDpOT_@Base 
0~20170419-g1f4a24f
+ 
_ZNSt6vectorIiSaIiEE17_M_realloc_insertIJiEEEvN9__gnu_cxx17__normal_iteratorIPiS1_EEDpOT_@Base
 0~20170419-g1f4a24f-2
+#MISSING: 0~20170419-g1f4a24f-2# 
_ZNSt6vectorIiSaIiEE19_M_emplace_back_auxIJiEEEvDpOT_@Base 0~20170419-g1f4a24f
+ 
_ZNSt6vectorIjSaIjEE17_M_realloc_insertIJRKjEEEvN9__gnu_cxx17__normal_iteratorIPjS1_EEDpOT_@Base
 0~20170419-g1f4a24f-2
+#MISSING: 0~20170419-g1f4a24f-2# 
_ZNSt6vectorIjSaIjEE19_M_emplace_back_auxIJjEEEvDpOT_@Base 0~20170419-g1f4a24f
  
_ZNSt8_Rb_treeImSt4pairIKmSt6vectorIjSaIjEEESt10_Select1stIS5_ESt4lessImESaIS5_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS5_ERS1_@Base
 0~20170419-g1f4a24f
  
_ZNSt8_Rb_treeImSt4pairIKmSt6vectorIjSaIjEEESt10_Select1stIS5_ESt4lessImESaIS5_EE8_M_eraseEPSt13_Rb_tree_nodeIS5_E@Base
 0~20170419-g1f4a24f
  
_ZSt13__adjust_heapIN9__gnu_cxx17__normal_iteratorIPSt4pairIjiESt6vectorIS3_SaIS3_lS3_NS0_5__ops15_Iter_less_iterEEvT_T0_SC_T1_T2_@Base
 0~20170419-g1f4a24f
dh_makeshlibs: failing due to earlier errors


Full log attached.

Andreas


highwayhash_0~20170419-g1f4a24f-2.log.gz
Description: application/gzip

Bug#871648: qemu-system-x86: /usr/bin/qemu-system-i386 eats slowly but surely all the Dom0 memory

[astian]

Michael Tokarev:
> On Thu, 31 Aug 2017 12:11:00 + astian  wrote:
>> [snip]
> 
> Now that's interesting.
> 
> The thing is that I've never seen this email.  Now I come across it while 
> trying
> to understand what's going on here.

Hmm, I sent that message with an attached patch and formatted as MIME
multi-part.  I wonder if perhaps the BTS partially choked on it because of
that...  Maybe I should just inline patches?

> [snip]

Bug#851895: gmp: Please update symbols for sh3

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi,

2017-01-19 17:53 John Paul Adrian Glaubitz:

Source: gmp
Version: 2:6.1.2+dfsg-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi!

We're currently adding sh3 as a new architecture to rebootstrap which
allows to cross-bootstrap Debian for architectures. sh3 is an older
architecture which is currently being redesigned as an open source
CPU with the name J-Core.

While cross-bootstrapping, the build stopped because the symbols for
gmp need to be updated for sh3. This can be trivially achieved by
globally replacing "!sh4" with "!sh3 !sh4" in libgmp10.symbols:

 $ sed -i 's/!sh4/!sh3 !sh4/g' debian/libgmp10.symbols


I uploaded an NMU including this fix to delayed/10, please tell me if
you want me to cancel it or, otherwise, you are OK and we can make it
happen earlier.


Cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru gmp-6.1.2+dfsg/debian/changelog gmp-6.1.2+dfsg/debian/changelog
--- gmp-6.1.2+dfsg/debian/changelog 2016-12-21 06:39:47.0 +0100
+++ gmp-6.1.2+dfsg/debian/changelog 2017-09-29 02:22:49.0 +0200
@@ -1,3 +1,12 @@
+gmp (2:6.1.2+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update symbols for nios2, thanks Helmut Grohne (Closes: #814671)
+  * Update symbols for tilegx, thanks Helmut Grohne (Closes: #850010)
+  * Update symbols for sh3, thanks Adrian Glaubitz (Closes: #851895)
+
+ -- Manuel A. Fernandez Montecelo   Fri, 29 Sep 2017 02:22:49 
+0200
+
 gmp (2:6.1.2+dfsg-1) unstable; urgency=medium
 
   * New upstream.
diff -Nru gmp-6.1.2+dfsg/debian/libgmp10.symbols 
gmp-6.1.2+dfsg/debian/libgmp10.symbols
--- gmp-6.1.2+dfsg/debian/libgmp10.symbols  2015-11-17 12:07:24.0 
+0100
+++ gmp-6.1.2+dfsg/debian/libgmp10.symbols  2017-09-29 01:58:27.0 
+0200
@@ -215,7 +215,7 @@
  (arch=any-i386)__gmpn_add_n_pentium@Base 2:5.1.1
  __gmpn_add_n_sub_n@Base 2:5.1.1
  (arch=any-i386)__gmpn_add_n_x86@Base 2:5.1.1
- (arch=!hppa !mips !mipsel !m68k !s390x !sh4 !sparc !sparc64 
!any-i386)__gmpn_add_nc@Base 0
+ (arch=!hppa !mips !mipsel !m68k !nios2 !s390x !sh3 !sh4 !sparc !sparc64 
!tilegx !any-i386)__gmpn_add_nc@Base 0
  (arch=any-i386)__gmpn_add_nc_atom@Base 2:5.1.1
  (arch=any-i386)__gmpn_add_nc_k6@Base 2:5.1.1
  (arch=any-i386)__gmpn_add_nc_k7@Base 2:5.1.1
@@ -224,9 +224,9 @@
  (arch=any-i386)__gmpn_add_nc_pentium@Base 2:5.1.1
  (arch=any-i386)__gmpn_add_nc_x86@Base 2:5.1.1
  (arch=any-amd64)__gmpn_addaddmul_1msb0@Base 0
- (arch=!arm64 !hppa !mips !mipsel !mips64 !mips64el !m68k !sparc !sparc64 
!sh4)__gmpn_addlsh1_n@Base 0
+ (arch=!arm64 !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !sparc 
!sparc64 !sh3 !sh4 !tilegx)__gmpn_addlsh1_n@Base 0
  (arch=any-i386)__gmpn_addlsh1_n_init@Base 2:5.1.1
- (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k 
!powerpc !powerpcspe !s390x !sh4 !sparc !sparc64)__gmpn_addlsh2_n@Base 0
+ (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 
!powerpc !powerpcspe !s390x !sh3 !sh4 !sparc !sparc64 
!tilegx)__gmpn_addlsh2_n@Base 0
  (arch=any-i386)__gmpn_addlsh2_n_init@Base 2:5.1.1
  (arch=any-amd64)__gmpn_addlsh_n@Base 0
  __gmpn_addmul_1@Base 0
@@ -394,7 +394,7 @@
  __gmpn_hgcd_reduce_itch@Base 2:5.1.1
  __gmpn_hgcd_step@Base 2:5.1.1
  __gmpn_invert@Base 0
- (arch=!hppa !mips !mipsel !mips64 !mips64el !m68k !sparc !sparc64 !sh4 
!any-i386)__gmpn_invert_limb@Base 0
+ (arch=!hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !sparc !sparc64 !sh3 
!sh4 !tilegx !any-i386)__gmpn_invert_limb@Base 0
  __gmpn_invertappr@Base 0
  __gmpn_ior_n@Base 0
  __gmpn_iorn_n@Base 0
@@ -507,7 +507,7 @@
  (arch=any-i386)__gmpn_mul_1_pentium@Base 2:5.1.1
  (arch=any-i386)__gmpn_mul_1_pentium_mmx@Base 2:5.1.1
  (arch=any-i386)__gmpn_mul_1_x86@Base 2:5.1.1
- (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k 
!powerpc !powerpcspe !s390x !sh4 !sparc !sparc64 !any-i386)__gmpn_mul_1c@Base 0
+ (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 
!powerpc !powerpcspe !s390x !sh3 !sh4 !sparc !sparc64 !tilegx 
!any-i386)__gmpn_mul_1c@Base 0
  (arch=any-i386)__gmpn_mul_1c_atom_sse2@Base 2:5.1.1
  (arch=any-i386)__gmpn_mul_1c_k6@Base 2:5.1.1
  (arch=any-i386)__gmpn_mul_1c_k7@Base 2:5.1.1
@@ -548,7 +548,7 @@
  __gmpn_pow_1@Base 0
  __gmpn_powlo@Base 0
  __gmpn_powm@Base 0
- (arch=!m68k !ppc64 !ppc64el)__gmpn_preinv_divrem_1@Base 0
+ (arch=!m68k !ppc64 !ppc64el !tilegx)__gmpn_preinv_divrem_1@Base 0
  (arch=any-i386)__gmpn_preinv_divrem_1_atom_sse2@Base 2:5.1.1
  (arch=any-i386)__gmpn_preinv_divrem_1_init@Base 2:5.1.1
  (arch=any-i386)__gmpn_preinv_divrem_1_k7_mmx@Base 2:5.1.1
@@ -571,13 +571,13 @@
  __gmpn_redc_n@Base 0
  __gmpn_remove@Base 0
  __gmpn_rootrem@Base 0
- (arch=!alpha !arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k 
!powerpc !powerpcspe !sh4 !sparc !sparc64 !any-i386)__gmpn_rsblsh1_n@Base 0
- (arch=!alpha !arm64 !armel !armhf !hppa !mips !mipsel !mips64 !

Bug#850010: libgmp10: please update symbols for tilegx

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi,

2017-01-03 07:28 Helmut Grohne:

Package: libgmp10
Version: 2:6.1.2+dfsg-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Dear gmp maintainer,

gmp fails to build from source on tilegx (which is a new architecture
from a Debian point of view). dpkg-gensymbols fails missing a lot of
symbols. This is kinda expected for a new port. As it happens, tilegx
behaves exactly the same as m68k (and a few other architectures) from a
gmp symbols point of view. Thus

sed -i '/^ /s/!m68k /!tilegx &/' debian/libgmp10.symbols

can be used to make the gmp build succeed on tilegx. Can you apply this
fix?


I uploaded an NMU including this fix to delayed/10, please tell me if
you want me to cancel it or, otherwise, you are OK and we can make it
happen earlier.



Cheers.
--
Manuel A. Fernandez Montecelo 

diff -Nru gmp-6.1.2+dfsg/debian/changelog gmp-6.1.2+dfsg/debian/changelog
--- gmp-6.1.2+dfsg/debian/changelog 2016-12-21 06:39:47.0 +0100
+++ gmp-6.1.2+dfsg/debian/changelog 2017-09-29 02:22:49.0 +0200
@@ -1,3 +1,12 @@
+gmp (2:6.1.2+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update symbols for nios2, thanks Helmut Grohne (Closes: #814671)
+  * Update symbols for tilegx, thanks Helmut Grohne (Closes: #850010)
+  * Update symbols for sh3, thanks Adrian Glaubitz (Closes: #851895)
+
+ -- Manuel A. Fernandez Montecelo   Fri, 29 Sep 2017 02:22:49 
+0200
+
 gmp (2:6.1.2+dfsg-1) unstable; urgency=medium
 
   * New upstream.
diff -Nru gmp-6.1.2+dfsg/debian/libgmp10.symbols 
gmp-6.1.2+dfsg/debian/libgmp10.symbols
--- gmp-6.1.2+dfsg/debian/libgmp10.symbols  2015-11-17 12:07:24.0 
+0100
+++ gmp-6.1.2+dfsg/debian/libgmp10.symbols  2017-09-29 01:58:27.0 
+0200
@@ -215,7 +215,7 @@
  (arch=any-i386)__gmpn_add_n_pentium@Base 2:5.1.1
  __gmpn_add_n_sub_n@Base 2:5.1.1
  (arch=any-i386)__gmpn_add_n_x86@Base 2:5.1.1
- (arch=!hppa !mips !mipsel !m68k !s390x !sh4 !sparc !sparc64 
!any-i386)__gmpn_add_nc@Base 0
+ (arch=!hppa !mips !mipsel !m68k !nios2 !s390x !sh3 !sh4 !sparc !sparc64 
!tilegx !any-i386)__gmpn_add_nc@Base 0
  (arch=any-i386)__gmpn_add_nc_atom@Base 2:5.1.1
  (arch=any-i386)__gmpn_add_nc_k6@Base 2:5.1.1
  (arch=any-i386)__gmpn_add_nc_k7@Base 2:5.1.1
@@ -224,9 +224,9 @@
  (arch=any-i386)__gmpn_add_nc_pentium@Base 2:5.1.1
  (arch=any-i386)__gmpn_add_nc_x86@Base 2:5.1.1
  (arch=any-amd64)__gmpn_addaddmul_1msb0@Base 0
- (arch=!arm64 !hppa !mips !mipsel !mips64 !mips64el !m68k !sparc !sparc64 
!sh4)__gmpn_addlsh1_n@Base 0
+ (arch=!arm64 !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !sparc 
!sparc64 !sh3 !sh4 !tilegx)__gmpn_addlsh1_n@Base 0
  (arch=any-i386)__gmpn_addlsh1_n_init@Base 2:5.1.1
- (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k 
!powerpc !powerpcspe !s390x !sh4 !sparc !sparc64)__gmpn_addlsh2_n@Base 0
+ (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 
!powerpc !powerpcspe !s390x !sh3 !sh4 !sparc !sparc64 
!tilegx)__gmpn_addlsh2_n@Base 0
  (arch=any-i386)__gmpn_addlsh2_n_init@Base 2:5.1.1
  (arch=any-amd64)__gmpn_addlsh_n@Base 0
  __gmpn_addmul_1@Base 0
@@ -394,7 +394,7 @@
  __gmpn_hgcd_reduce_itch@Base 2:5.1.1
  __gmpn_hgcd_step@Base 2:5.1.1
  __gmpn_invert@Base 0
- (arch=!hppa !mips !mipsel !mips64 !mips64el !m68k !sparc !sparc64 !sh4 
!any-i386)__gmpn_invert_limb@Base 0
+ (arch=!hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !sparc !sparc64 !sh3 
!sh4 !tilegx !any-i386)__gmpn_invert_limb@Base 0
  __gmpn_invertappr@Base 0
  __gmpn_ior_n@Base 0
  __gmpn_iorn_n@Base 0
@@ -507,7 +507,7 @@
  (arch=any-i386)__gmpn_mul_1_pentium@Base 2:5.1.1
  (arch=any-i386)__gmpn_mul_1_pentium_mmx@Base 2:5.1.1
  (arch=any-i386)__gmpn_mul_1_x86@Base 2:5.1.1
- (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k 
!powerpc !powerpcspe !s390x !sh4 !sparc !sparc64 !any-i386)__gmpn_mul_1c@Base 0
+ (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 
!powerpc !powerpcspe !s390x !sh3 !sh4 !sparc !sparc64 !tilegx 
!any-i386)__gmpn_mul_1c@Base 0
  (arch=any-i386)__gmpn_mul_1c_atom_sse2@Base 2:5.1.1
  (arch=any-i386)__gmpn_mul_1c_k6@Base 2:5.1.1
  (arch=any-i386)__gmpn_mul_1c_k7@Base 2:5.1.1
@@ -548,7 +548,7 @@
  __gmpn_pow_1@Base 0
  __gmpn_powlo@Base 0
  __gmpn_powm@Base 0
- (arch=!m68k !ppc64 !ppc64el)__gmpn_preinv_divrem_1@Base 0
+ (arch=!m68k !ppc64 !ppc64el !tilegx)__gmpn_preinv_divrem_1@Base 0
  (arch=any-i386)__gmpn_preinv_divrem_1_atom_sse2@Base 2:5.1.1
  (arch=any-i386)__gmpn_preinv_divrem_1_init@Base 2:5.1.1
  (arch=any-i386)__gmpn_preinv_divrem_1_k7_mmx@Base 2:5.1.1
@@ -571,13 +571,13 @@
  __gmpn_redc_n@Base 0
  __gmpn_remove@Base 0
  __gmpn_rootrem@Base 0
- (arch=!alpha !arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k 
!powerpc !powerpcspe !sh4 !sparc !sparc64 !any-i386)__gmpn_rsblsh1_n@Base 0
- (arch=!alpha !arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k 
!powerpc !powerpcspe !s390x !sh4 !

Bug#814671: libgmp10: please update symbols for nios2

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


2016-02-13 21:56 Helmut Grohne:

Source: gmp
Version: 2:6.0.0+dfsg-6
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Dear gmp maintainer,

gmp fails to build from source on nios2 (which is a new architecture
from a Debian point of view). dpkg-gensymbols fails missing a lot of
symbols. This is kinda expected for a new port. As it happens, nios2
behaves exactly the same as mips (and a few other architectures) from a
gmp symbols point of view. Thus

   sed -i 's/!mips /!nios2 &/' debian/libgmp10.symbols

can be used to make the gmp build succeed on nios2. Can you apply this
fix?


I uploaded an NMU including this fix to delayed/10, please tell me if
you want me to cancel it or, otherwise, you are OK and we can make it
happen earlier.



Cheers.
--
Manuel A. Fernandez Montecelo 

diff -Nru gmp-6.1.2+dfsg/debian/changelog gmp-6.1.2+dfsg/debian/changelog
--- gmp-6.1.2+dfsg/debian/changelog 2016-12-21 06:39:47.0 +0100
+++ gmp-6.1.2+dfsg/debian/changelog 2017-09-29 02:22:49.0 +0200
@@ -1,3 +1,12 @@
+gmp (2:6.1.2+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update symbols for nios2, thanks Helmut Grohne (Closes: #814671)
+  * Update symbols for tilegx, thanks Helmut Grohne (Closes: #850010)
+  * Update symbols for sh3, thanks Adrian Glaubitz (Closes: #851895)
+
+ -- Manuel A. Fernandez Montecelo   Fri, 29 Sep 2017 02:22:49 
+0200
+
 gmp (2:6.1.2+dfsg-1) unstable; urgency=medium
 
   * New upstream.
diff -Nru gmp-6.1.2+dfsg/debian/libgmp10.symbols 
gmp-6.1.2+dfsg/debian/libgmp10.symbols
--- gmp-6.1.2+dfsg/debian/libgmp10.symbols  2015-11-17 12:07:24.0 
+0100
+++ gmp-6.1.2+dfsg/debian/libgmp10.symbols  2017-09-29 01:58:27.0 
+0200
@@ -215,7 +215,7 @@
  (arch=any-i386)__gmpn_add_n_pentium@Base 2:5.1.1
  __gmpn_add_n_sub_n@Base 2:5.1.1
  (arch=any-i386)__gmpn_add_n_x86@Base 2:5.1.1
- (arch=!hppa !mips !mipsel !m68k !s390x !sh4 !sparc !sparc64 
!any-i386)__gmpn_add_nc@Base 0
+ (arch=!hppa !mips !mipsel !m68k !nios2 !s390x !sh3 !sh4 !sparc !sparc64 
!tilegx !any-i386)__gmpn_add_nc@Base 0
  (arch=any-i386)__gmpn_add_nc_atom@Base 2:5.1.1
  (arch=any-i386)__gmpn_add_nc_k6@Base 2:5.1.1
  (arch=any-i386)__gmpn_add_nc_k7@Base 2:5.1.1
@@ -224,9 +224,9 @@
  (arch=any-i386)__gmpn_add_nc_pentium@Base 2:5.1.1
  (arch=any-i386)__gmpn_add_nc_x86@Base 2:5.1.1
  (arch=any-amd64)__gmpn_addaddmul_1msb0@Base 0
- (arch=!arm64 !hppa !mips !mipsel !mips64 !mips64el !m68k !sparc !sparc64 
!sh4)__gmpn_addlsh1_n@Base 0
+ (arch=!arm64 !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !sparc 
!sparc64 !sh3 !sh4 !tilegx)__gmpn_addlsh1_n@Base 0
  (arch=any-i386)__gmpn_addlsh1_n_init@Base 2:5.1.1
- (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k 
!powerpc !powerpcspe !s390x !sh4 !sparc !sparc64)__gmpn_addlsh2_n@Base 0
+ (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 
!powerpc !powerpcspe !s390x !sh3 !sh4 !sparc !sparc64 
!tilegx)__gmpn_addlsh2_n@Base 0
  (arch=any-i386)__gmpn_addlsh2_n_init@Base 2:5.1.1
  (arch=any-amd64)__gmpn_addlsh_n@Base 0
  __gmpn_addmul_1@Base 0
@@ -394,7 +394,7 @@
  __gmpn_hgcd_reduce_itch@Base 2:5.1.1
  __gmpn_hgcd_step@Base 2:5.1.1
  __gmpn_invert@Base 0
- (arch=!hppa !mips !mipsel !mips64 !mips64el !m68k !sparc !sparc64 !sh4 
!any-i386)__gmpn_invert_limb@Base 0
+ (arch=!hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !sparc !sparc64 !sh3 
!sh4 !tilegx !any-i386)__gmpn_invert_limb@Base 0
  __gmpn_invertappr@Base 0
  __gmpn_ior_n@Base 0
  __gmpn_iorn_n@Base 0
@@ -507,7 +507,7 @@
  (arch=any-i386)__gmpn_mul_1_pentium@Base 2:5.1.1
  (arch=any-i386)__gmpn_mul_1_pentium_mmx@Base 2:5.1.1
  (arch=any-i386)__gmpn_mul_1_x86@Base 2:5.1.1
- (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k 
!powerpc !powerpcspe !s390x !sh4 !sparc !sparc64 !any-i386)__gmpn_mul_1c@Base 0
+ (arch=!arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 
!powerpc !powerpcspe !s390x !sh3 !sh4 !sparc !sparc64 !tilegx 
!any-i386)__gmpn_mul_1c@Base 0
  (arch=any-i386)__gmpn_mul_1c_atom_sse2@Base 2:5.1.1
  (arch=any-i386)__gmpn_mul_1c_k6@Base 2:5.1.1
  (arch=any-i386)__gmpn_mul_1c_k7@Base 2:5.1.1
@@ -548,7 +548,7 @@
  __gmpn_pow_1@Base 0
  __gmpn_powlo@Base 0
  __gmpn_powm@Base 0
- (arch=!m68k !ppc64 !ppc64el)__gmpn_preinv_divrem_1@Base 0
+ (arch=!m68k !ppc64 !ppc64el !tilegx)__gmpn_preinv_divrem_1@Base 0
  (arch=any-i386)__gmpn_preinv_divrem_1_atom_sse2@Base 2:5.1.1
  (arch=any-i386)__gmpn_preinv_divrem_1_init@Base 2:5.1.1
  (arch=any-i386)__gmpn_preinv_divrem_1_k7_mmx@Base 2:5.1.1
@@ -571,13 +571,13 @@
  __gmpn_redc_n@Base 0
  __gmpn_remove@Base 0
  __gmpn_rootrem@Base 0
- (arch=!alpha !arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k 
!powerpc !powerpcspe !sh4 !sparc !sparc64 !any-i386)__gmpn_rsblsh1_n@Base 0
- (arch=!alpha !arm64 !armel !armhf !hppa !mips !mipsel !mips64 !mips64el !m68k 
!powerpc !powerpcspe !s390x !sh4 !sparc !sparc64 

Bug#862256: libgmp3-dev is not Multi-Arch compatible

[Manuel A. Fernandez Montecelo]

Hi,

2017-05-10 12:32 Francois Gouget:

Package: libgmp3-dev
Version: 2:6.1.2+dfsg-1
Severity: normal

Dear Maintainer,

There are still some packages that Depend and Build-Depend on
libgmp3-dev. Unfortunately libgmp3-dev is not multiarch-aware
which makes things harder than needed.

The packages depending on libgmp3-dev should definitely be updated
to depend on libgmp-dev but given that all libgmp3-dev does is pull
libgmp-dev which is compatible with multiarch, it should be trivial
to make libgmp3-dev multiarch-compatible too.


To the maintainers: are you OK with an NMU for this?

To François: would you please be able to provide a patch?


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#876837: [Pkg-fonts-devel] Bug#876837: Bug#876837: Bug#876837: fonttools bug

[Holger Levsen]

On Thu, Sep 28, 2017 at 10:12:36PM +0200, Fabian Greffrath wrote:
> I have already merged our branches and also the changelog, so it would
> probably be the cleanest solution to re-upload the current state in GIT
> as a new revision. :/

Sure, I'm happy to do that! Did you push everything to git?
 

-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#877129: python-cliff: FTBFS: test fail: ModuleNotFoundError: No module named 'docutils'

[Andreas Beckmann]

Source: python-cliff
Version: 2.8.0-1
Severity: serious
Justification: fails to build from source

Hi,

python-cliff/experimental FTBFS with

[...]
cliff.tests.test_show.TestShow.test_formatter_args
cliff.tests.test_show.TestShow.test_formatter_args ... ok
cliff.tests.test_show.TestShow.test_no_exist_column
cliff.tests.test_show.TestShow.test_no_exist_column ... ok
unittest2.loader._FailedTest.cliff.tests.test_sphinxext
unittest2.loader._FailedTest.cliff.tests.test_sphinxext ... FAIL
cliff.tests.test_utils.TestTerminalWidth.test
cliff.tests.test_utils.TestTerminalWidth.test ... ok
cliff.tests.test_utils.TestTerminalWidth.test_get_terminal_size
cliff.tests.test_utils.TestTerminalWidth.test_get_terminal_size ... ok
cliff.tests.test_utils.TestTerminalWidth.test_ioctl
cliff.tests.test_utils.TestTerminalWidth.test_ioctl ... skipped u'only needed 
for python 3.2 and before'
cliff.tests.test_utils.TestTerminalWidth.test_windows
cliff.tests.test_utils.TestTerminalWidth.test_windows ... skipped u'only needed 
for python 3.2 and before'
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ ./cliff  

==
FAIL: unittest2.loader._FailedTest.cliff.tests.test_sphinxext
unittest2.loader._FailedTest.cliff.tests.test_sphinxext
--
_StringException: Traceback (most recent call last):
ImportError: Failed to import test module: cliff.tests.test_sphinxext
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/unittest2/loader.py", line 456, in 
_find_test_path
module = self._get_module_from_name(name)
  File "/usr/lib/python3/dist-packages/unittest2/loader.py", line 395, in 
_get_module_from_name
__import__(name)
  File "/build/python-cliff-2.8.0/cliff/tests/test_sphinxext.py", line 18, in 

from cliff import sphinxext
  File "/build/python-cliff-2.8.0/cliff/sphinxext.py", line 19, in 
from docutils import nodes
ModuleNotFoundError: No module named 'docutils'


--
Ran 152 tests in 1.107s

FAILED (failures=1, skipped=2)
debian/rules:35: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1


Full log attached.


Andreas


python-cliff_2.8.0-1.log.gz
Description: application/gzip

Bug#877128: cudf: missing B-D: ocamlbuild

[Andreas Beckmann]

Source: cudf
Version: 0.8-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

this B-D was recentl added in sid, but the package in experimental FTBFS
now, too.


Andreas

Bug#877127: glances: nagging suggestion to upgrade using pip

[Ben Wong]

Package: glances
Version: 2.7.1.1-2
Severity: wishlist

Dear Maintainer,

When glances is not the latest version, it prints a message upon
quitting suggesting one should upgrade using 'pip'. While I trust the
Debian project enough to install upgrades, I do not trust pip. (In
fact, I think it raises grave security issues that people are now
trusting pip as a package manager, but that's another issue...)

Furthermore, since I'm running Debian stable, I expect my software
will be a few revisions behind and that's okay by me. Manually
installing individual software upgrades is pointless on a system like
Debian where the OS handles all that for me. I do not want or need pip.

Can the nag message please be removed?

Thank you.

P.S. This is related to, but not the same issue as BUG #850258
("glances: calling home?"). If the phone home feature is disabled,
that would have the benefit of also fixing this bug.


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

Kernel: Linux 4.9.0-3-amd64 (SMP w/2 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 glances depends on:
ii  adduser3.115
ii  libjs-angularjs1.5.10-1
ii  libjs-lodash   4.16.6+dfsg-2
ii  lsb-base   9.20161125
ii  python33.5.3-1
ii  python3-pkg-resources  33.1.1-1
ii  python3-psutil 5.0.1-1

Versions of packages glances recommends:
ii  hddtemp 0.3-beta15-52+b1
ii  lm-sensors  1:3.4.0-4
ii  python3-bottle  0.12.13-1
ii  python3-docker  1.9.0-1
pn  python3-influxdb
ii  python3-matplotlib  2.0.0+dfsg1-2
ii  python3-netifaces   0.10.4-0.1+b2
ii  python3-pysnmp4 4.3.2-2
ii  python3-pystache0.5.4-6

glances suggests no packages.

-- no debconf information

Bug#876489: closed by Thomas Goirand (Bug#876489: fixed in python-os-client-config 1.28.0-2)

[Andreas Beckmann]

Control: found -1 1.28.0-2

On 09/24/2017 12:24 AM, Debian Bug Tracking System wrote:
>  python-os-client-config (1.28.0-2) experimental; urgency=medium
>  .
>* Add missing python-openstackdocstheme build-depends (Closes: #876489).

Actually, that build dependency was already there. But since the problem
persists, it must be elsewhere.


Andreas

Bug#877126: thrift: B-D libmaven-ant-tasks-java is no longer available

[Andreas Beckmann]

Source: thrift
Version: 0.10.0-1
Severity: serious
Justification: fails to build from source

Hi,

thrift can no longer be built in experimental, since
libmaven-ant-tasks-java was recently removed from the archive.
A possible replacement is libaether-ant-tasks-java.


Andreas

Bug#876680: rhash-bindings: B-D on many no longer available packages

[Andreas Beckmann]

Hi,

On 09/25/2017 03:08 PM, RHash Admin wrote:
> I've uploaded fix several times (several years ago) to mentors.debian.net
> and also tried to find mentor on irq channel without success.

I see that you orphaned the package. If you still have the the changes
available, perhaps you could post them to this bug, just in case someone
wants to pick up the package.
The Vcs-{Git,Browser} urls in the package seem to point to the wrong
package (rhash itself), so I don't know whether there is actually a repo
for rhash-bindings.

> Regrettably, I have no time anymore to support rhash-bindings, so somebody
> should take over it or it should be removed from archive.
I'm not interested in rhash-bindings at all, I just did a rebuild of
experimental on amd64 and i386 and now I try to ensure that all
unbuildable cruft has proper FTBFS bugs...


Andreas

Bug#877125: dtc: build errors with swig for python lib

[Vagrant Cascadian]

Control: found 877124 1.4.5-1

On 2017-09-28, Héctor Orón Martínez wrote:
>   I have attempted to build python library for device tree compiler,
> however I ran out into build issues with swig components due to -Wall.
> I have tried to look for a bug tracking system to report it, but I
> have been unable to find one.

There appears to be a github page for it:

  https://github.com/dgibson/dtc


>   Find log attached with build issues in Debian/unstable build.

Had the same issue...


>   To enable python library builds we need to build depend on swig and
> python-dev and drop NO_PYTHON = 1 from rules file.

When I did that, for some reason I haven't identified, the package ended
up without documentation or manpages...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#836453: xserver-xorg-dev: please move xorg-server.pc to a multiarch path

[Manuel A. Fernandez Montecelo]

(Copying explicitly pochu since he's the most active uploader in the
last year)

Hi,

2016-09-03 13:10 Helmut Grohne:

[...]
Hi,

xserver-xorg-dev makes the aforementioned affected packages fail to
cross build from source, because pkg-config does not consider[1]
/usr/lib/pkgconfig/ during cross compilation. In contrast, it always
considers /usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig, so moving
xorg-server.pc there will make both native and cross builds happy.

The requested change is implemented in the attached patch for your
convenience.


How do you feel about applying this patch to help with cross-compilation
and (re)bootstrapping?

If it helps, I can prepare a NMU for it.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#799802: [roxterm] Dodgy filename locks up roxterm during rsync (100% CPU)

[Egmont Koblinger]

Hi,

I cannot reproduce the issue -- in fact, I came across it on the
bugs.debian.org website which is encoded in UTF-8 so it cannot represent
the non-UTF-8 you're talking about. I'm copy-pasting the command but it's
perfectly valid UTF-8 and no lockup happens. It would be great if you could
construct a command line that emits such locking non-UTF-8 (e.g. echo
"\x12\x34..."), whereas the command itself can be copy-pasted from UTF-8
websites.

That being said, I suspect that this bug might be the same as (or similar
to)
https://bugzilla.xfce.org/show_bug.cgi?id=13383
https://bugzilla.gnome.org/show_bug.cgi?id=33
https://bugzilla.gnome.org/show_bug.cgi?id=730154 comments 4-7

although that wouldn't explain the 100% CPU usage.

cheers,
egmont

Bug#799824: systemsettings: dead_greek characters not working with xmodmap since upgrading to kde5

[Matt Whitlock]

On Wed, 14 Jun 2017 16:45:21 +0200 Maximiliano Curia 
 wrote:
From the default Compose file, it seems that qt5 input ignores quite a number 
of the dead keys used there*:

 + dead_belowbreve
 + dead_belowcircumflex
 + dead_belowcomma
 + dead_belowdiaeresis
 + dead_belowmacron
 + dead_belowring
 + dead_belowtilde
 + dead_currency
 + dead_doublegrave
 + dead_greek
 + dead_invertedbreve
 + dead_psili
 + dead_stroke

This seems to be due to the missing definition of the corresponding qt 
constants (see: src/corelib/global/qnamespace.h:823-842 
 src/plugins/platforminputcontexts/compose/qcomposeplatforminputcontext.cpp:65-86

 src/plugins/platforms/xcb/qxcbkeyboard.cpp:412-431)


Hello. I have submitted a patch to Qt's Gerrit to add the missing dead key 
symbols (including several not listed above):


https://codereview.qt-project.org/207231

Bug#721358: coreutils: use dummy man when cross build

[Manuel A. Fernandez Montecelo]

Hi,

2016-03-12 19:41 Manuel A. Fernandez Montecelo:

User: helm...@debian.org
Usertags: rebootstrap


2016-03-12 17:03 To Eleanor Chen:

Hi,

2013-08-30 18:03 Eleanor Chen:

Package: src:coreutils

During cross build help2man may not run leading FTBFS, it would be
good if it uses dummy-man. Here is the patch for it, but I'm not sure
if it's an appropriate solution.


It would be very beneficial to have this patch applied, or an equivalent
solution, for cross-compilation / bootstrapping.

Several ports are in the works again, and being able to rebootstrap
easily and quickly such a fundamental package as coreutils is a very
worthwhile thing to have in some cases.

Of course the manual pages would not be "valid" initially, but even
without native recompilations of the same versions once
(re)bootstrapped, this would auto-heal when newer versions of the
package enter in the archive and get compiled for the new architecture.


Other possibilities suggested by Helmut include:

- ship pre-generated manual pages (probably a bit involved)

- to not build man pages with "nodoc" build options / profiles (so
cross-compilation could use this profile/options)

- have "Build-Depends: $self:native " and run help2man on the
binaries instead.

The latter has been applied for flex, for example, the patch is not very
intrusive:

https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=flex_help2man.debdiff;bug=762180;att=1;msg=5

If you are happy to apply this and prefer this solution, we can prepare
a patch.


I was thinking of preparing an NMU for this, help2man issues are very
annoying to (re)bootstrap ports.

Michael, do you have any preference about how the solution should look
like?  Or would you reject a NMU at all?

Cheers.

--
Manuel A. Fernandez Montecelo 

Bug#839879: mtr FTCBFS: uses build architecture tools

[Manuel A. Fernandez Montecelo]

Hi,

2017-01-03 23:05 Samuel Henrique:

Hi Robert,

Did you have a look at this one?

I'm in favor of using dh_auto_configure, just would like to check with you
if i'm missing something (like a regression).


IMO the patch proposed by Helmut is a good fix and improves the
packaging overall, not only for cross-compilation (if only by removing
lines).

A year went by, and we're past the freeze again, so I think that it's a
good time to apply this.

Would it help if I prepare an NMU, or sponsor a package prepared by
Samuel?


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#877125: dtc: build errors with swig for python lib

[Héctor Orón Martínez]

Package: device-tree-compiler
Version: 1.4.5
Seeverity: normal

Hello,

  I have attempted to build python library for device tree compiler,
however I ran out into build issues with swig components due to -Wall.
I have tried to look for a bug tracking system to report it, but I
have been unable to find one.

  Find log attached with build issues in Debian/unstable build.

  To enable python library builds we need to build depend on swig and
python-dev and drop NO_PYTHON = 1 from rules file.

P.S./ I have contacted upstream mailing list about it.

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.
 dpkg-buildpackage -rfakeroot -us -uc -i -I
dpkg-buildpackage: info: paquet font device-tree-compiler
dpkg-buildpackage: info: versió del font 1.4.5-1
dpkg-buildpackage: info: distribució del font unstable
dpkg-buildpackage: info: font canviat per Héctor Orón Martínez 

 dpkg-source -i -I --before-build device-tree-compiler
dpkg-buildpackage: info: arquitectura de l'amfitrió amd64
 fakeroot debian/rules clean
dh clean
   debian/rules override_dh_auto_clean
make[1]: Entering directory 
'/home/zumbi/SCM/GITAuth/Debian/device-tree-compiler'
dh_auto_clean
make -j4 clean
make[2]: Entering directory 
'/home/zumbi/SCM/GITAuth/Debian/device-tree-compiler'
 CLEAN (pylibfdt)
 CLEAN (tests)
 CLEAN (libfdt)
 CLEAN
make[2]: Leaving directory '/home/zumbi/SCM/GITAuth/Debian/device-tree-compiler'
[ ! -f Documentation/Makefile ] || /usr/bin/make -C Documentation clean
make[2]: Entering directory 
'/home/zumbi/SCM/GITAuth/Debian/device-tree-compiler/Documentation'
rm -f *.aux *.log *.dvi *.ps *.pdf dtc-manual.txt
make[2]: Leaving directory 
'/home/zumbi/SCM/GITAuth/Debian/device-tree-compiler/Documentation'
[ ! -d build ] || rm -rf build
make[1]: Leaving directory '/home/zumbi/SCM/GITAuth/Debian/device-tree-compiler'
   dh_autoreconf_clean
   dh_clean
 dpkg-source -i -I -b device-tree-compiler
dpkg-source: info: s'està emprant el format de font «3.0 (quilt)»
dpkg-source: info: s'està construint device-tree-compiler emprant 
./device-tree-compiler_1.4.5.orig.tar.gz existent
dpkg-source: info: s'està construint device-tree-compiler a 
device-tree-compiler_1.4.5-1.debian.tar.xz
dpkg-source: info: s'està construint device-tree-compiler a 
device-tree-compiler_1.4.5-1.dsc
 debian/rules build
dh build
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure
   debian/rules override_dh_auto_build
make[1]: Entering directory 
'/home/zumbi/SCM/GITAuth/Debian/device-tree-compiler'
dh_auto_build 
make -j4
make[2]: Entering directory 
'/home/zumbi/SCM/GITAuth/Debian/device-tree-compiler'
 DEP tests/dumptrees.c
 DEP tests/trees.S
 DEP tests/testutils.c
 DEP tests/value-labels.c
 DEP tests/asm_tree_dump.c
 DEP tests/truncated_property.c
 DEP tests/check_path.c
 DEP tests/overlay_bad_fixup.c
 DEP tests/overlay.c
 DEP tests/subnode_iterate.c
 DEP tests/property_iterate.c
 DEP tests/integer-expressions.c
 DEP tests/utilfdt_test.c
 DEP tests/path_offset_aliases.c
 DEP tests/add_subnode_with_nops.c
 DEP tests/dtbs_equal_unordered.c
 DEP tests/dtb_reverse.c
 DEP tests/dtbs_equal_ordered.c
 DEP tests/extra-terminating-null.c
 DEP tests/incbin.c
 DEP tests/boot-cpuid.c
 DEP tests/phandle_format.c
 DEP tests/path-references.c
 DEP tests/references.c
 DEP tests/string_escapes.c
 DEP tests/propname_escapes.c
 DEP tests/appendprop2.c
 DEP tests/appendprop1.c
 DEP tests/del_node.c
 DEP tests/del_property.c
 DEP tests/setprop.c
 DEP tests/set_name.c
 DEP tests/rw_tree1.c
 DEP tests/open_pack.c
 DEP tests/nopulate.c
 DEP tests/mangle-layout.c
 DEP tests/move_and_save.c
 DEP tests/sw_tree1.c
 DEP tests/nop_node.c
 DEP tests/nop_property.c
 DEP tests/setprop_inplace.c
 DEP tests/stringlist.c
 DEP tests/addr_size_cells.c
 DEP tests/notfound.c
 DEP tests/sized_cells.c
 DEP tests/char_literal.c
 DEP tests/get_alias.c
 DEP tests/node_offset_by_compatible.c
 DEP tests/node_check_compatible.c
 DEP tests/node_offset_by_phandle.c
 DEP tests/node_offset_by_prop_value.c
 DEP tests/parent_offset.c
 DEP tests/get_path.c
 DEP tests/supernode_atdepth_offset.c
 DEP tests/get_phandle.c
 DEP tests/get_name.c
 DEP tests/getprop.c
 DEP tests/path_offset.c
 DEP tests/subnode_offset.c
 DEP tests/find_property.c
 DEP tests/root_node.c
 DEP tests/get_mem_rsv.c
 DEP libfdt/fdt_overlay.c
 DEP libfdt/fdt_addresses.c
 DEP libfdt/fdt_empty_tree.c
 DEP libfdt/fdt_strerror.c
 

Bug#877124: ITP: pep9 -- Pep/9 assembler and simulator

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: pep9
  Version : 9.1-1
  Upstream Author : 2009 J. Stanley Warford, Pepperdine University
* URL : https://github.com/StanWarford/pep9 

* License : GPL-3+
  Programming Lang: C++
  Description : Pep/9 assembler and simulator




signature.asc
Description: OpenPGP digital signature

Bug#854149: libvte-2.91-0: x-terminals not properly compose unicode characters

[Egmont Koblinger]

Hi,

This is a truly interesting bug.

If you highlight and copy-paste only the printed "1" or "2" digits, you'll
notice that "1" carries the combining strikethrough with it. This is one
possible way of making sure that VTE's belief about where that combining
accent is is correct. The problem "only" occurs when it displays it.

To make it more complicated, the behavior:
- depends on which regular characters are used instead of "1" and "2";
- depends on the combining accent
- depends on the font;
- is consistent with gedit.

Let's replace "1" and "2" with "a" and "b", as well as "x" and "y". Let's
also try '\u0301' (accent acute) in addition to the strikethrough.

echo -e '1\u03012'
echo -e 'a\u0301b'
echo -e 'x\u0301y'
echo -e '1\u03362'
echo -e 'a\u0336b'
echo -e 'x\u0336y'

and also redirect the output and open the file in gedit.

And let's try a couple of fonts:

DejaVu Sans Mono Oblique =>
Only the 2nd out of the 6 commands appear correctly ("a" with accent).
The rest: in gedit there's another cell in between containing the accent
only, in vte the accent is on top of the second letter.

FreeMono Regular, Noto Mono Regular, Tlwg Mono Regular, Ubuntu Mono Regular
=>
In both apps: The accent is always on the first character, as expected.

Liberation Mono Regular, Nimbus Mono L Regular =>
In vte: The accent is always on top of the second letter.
In gedit: The acute accent is always on top of the second letter. The
strikethrough is always in an additional cell between the two letters (as
DejaVu in 5 out of 6 cases).

Monospace Regular =>
Like DejaVu, except that the 3rd case also renders correctly (x with acute
accent).

Some conclusions:

It's broken in VTE if and only if broken in Gedit as well.

In Gedit it can be broken in two different ways; either the accent appears
over the second letter, or combines into a glyph that looks double wide
(but actually the cursor or mouse highlight jumps through it in a single
step) and contains the base letter in the left part and the combining one
in the right part. Which of these two broken variants occurs might depend
on the combining character itself.

Whether broken or not might depend on the base character and might depend
on the combining character too.

The only rendering difference between gedit and vte can be explained very
well. Gedit renders the entire flow in one step. VTE instead renders every
cell separately (putting into it the contents it wishes to see there, and
it knows correctly that these combining characters belong to the first
cell). Whatever is painted there might overflow out of the cell (and is
still painted there), but for the next character it's another painting step
started at the location VTE believes is the correct starting position. So
wherever gedit seems to paint three columns looking like "a-b", vte instead
renders "a-" beginning at column 1, and then paints "b" beginning at column
2, effectively looking as if the letter "b" was striked through.

For all the rest, it's a total mystery to me. I have no clue if it's all
these fonts that are buggy, or Gtk+'s font rendering has some fundamental
flow, or what else.

Okay, so let's check Konsole, KDE's terminal emulator build on top of Qt
and KDE libs. Konsole is notorious for not rendering each cell
independently, but rather a continuous run of text in a single step (as
most apps typically do except for terminal emulators).

KDE's behavior is almost the same as gedit's. The only exception I've found
was that with Monospace it rendered exactly as with Dejavu, that is, only
the accent on top of "a" was correct, the one on top of "x" wasn't (it was
on top of "y").

At this point my primary suspects are all these monospace fonts, although
there's sure much more to this story, e.g. there might be some mapping to
precomposed characters or whatnot...

It would be great to get someone heavily experienced in fonts involved in
this thread.

cheers,
egmont

Bug#874434: severity is grave

[Tiago Stürmer Daitx]

Resending it with a .patch extension so hopefully BTS will identify it
as an actual text/plain file.

On Thu, 28 Sep 2017 15:18:20 -0700
=?UTF-8?Q?Tiago_St=C3=BCrmer_Daitx?=  wrote:
> Please consider removing the jvm.cfg checks. OpenJDK 7, 8, and 9 have
> been shipping a default jvm.cfg for quite some time now and it is used
> when a jvm.cfg is not present in the /etc/ directory.
>
> Patch is attached.
>
>
> thanks
diff -Nru ca-certificates-java-20170531+nmu1/debian/changelog ca-certificates-java-20170531+nmu1.1/debian/changelog
--- ca-certificates-java-20170531+nmu1/debian/changelog	2017-06-15 11:33:00.0 -0400
+++ ca-certificates-java-20170531+nmu1.1/debian/changelog	2017-09-28 16:54:50.0 -0400
@@ -1,3 +1,11 @@
+ca-certificates-java (20170531+nmu1.1) UNRELEASED; urgency=medium
+
+  * Remove jvm.cfg temporary generation as openjdk-8 already ships with a
+default jvm.cfg for cases wihere the one in /etc is missing or not yet
+setup. Closes: #874434. 
+
+ -- Tiago Stürmer Daitx   Thu, 28 Sep 2017 20:54:50 +
+
 ca-certificates-java (20170531+nmu1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru ca-certificates-java-20170531+nmu1/debian/jks-keystore.hook.in ca-certificates-java-20170531+nmu1.1/debian/jks-keystore.hook.in
--- ca-certificates-java-20170531+nmu1/debian/jks-keystore.hook.in	2017-05-31 08:39:26.0 -0400
+++ ca-certificates-java-20170531+nmu1.1/debian/jks-keystore.hook.in	2017-09-28 10:44:15.0 -0400
@@ -48,14 +48,6 @@
 export JAVA_HOME=/usr/lib/jvm/$jvm
 PATH=$JAVA_HOME/bin:$PATH
 
-temp_jvm_cfg=
-if [ ! -f /etc/${jvm%-$arch}/jvm-$arch.cfg ]; then
-# the jre is not yet configured, but jvm.cfg is needed to run it
-temp_jvm_cfg=/etc/${jvm%-$arch}/jvm-$arch.cfg
-mkdir -p /etc/${jvm%-$arch}
-printf -- "-server KNOWN\n" > $temp_jvm_cfg
-fi
-
 if dpkg-query --version >/dev/null; then
 nsspkg=$(dpkg-query -L "$(nsslib_name)" | sed -n 's,\(.*\)/libnss3\.so$,\1,p'|head -n 1)
 nsscfg=/etc/${jvm%-$arch}/security/nss.cfg
@@ -71,7 +63,6 @@
 
 do_cleanup()
 {
-[ -z "$temp_jvm_cfg" ] || rm -f $temp_jvm_cfg
 if [ -n "$nsspkg" ] && [ -n "$nssjdk" ] && [ "$nsspkg" != "$nssjdk" ]
 then
 rm -f $nssjdk/libnss3.so
diff -Nru ca-certificates-java-20170531+nmu1/debian/postinst.in ca-certificates-java-20170531+nmu1.1/debian/postinst.in
--- ca-certificates-java-20170531+nmu1/debian/postinst.in	2017-05-31 08:39:26.0 -0400
+++ ca-certificates-java-20170531+nmu1.1/debian/postinst.in	2017-09-28 10:43:16.0 -0400
@@ -72,7 +72,6 @@
 
 do_cleanup()
 {
-[ -z "$temp_jvm_cfg" ] || rm -f $temp_jvm_cfg
 if [ -n "$nsspkg" ] && [ -n "$nssjdk" ] && [ "$nsspkg" != "$nssjdk" ]
 then
 rm -f $nssjdk/libnss3.so
@@ -95,14 +94,6 @@
 exit 1
 fi
 
-temp_jvm_cfg=
-if [ ! -f /etc/${jvm%-$arch}/jvm-$arch.cfg ]; then
-# the jre is not yet configured, but jvm.cfg is needed to run it
-temp_jvm_cfg=/etc/${jvm%-$arch}/jvm-$arch.cfg
-mkdir -p /etc/${jvm%-$arch}
-printf -- "-server KNOWN\n" > $temp_jvm_cfg
-fi
-
 trap do_cleanup EXIT
 first_install
 fi

Bug#840813: mark xorg-docs-core Multi-Arch: foreign

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending
Control: tags 858469 + pending


Hi,

2016-10-15 09:49 Helmut Grohne:

Package: xorg-docs-core
Version: 1:1.7.1-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:xterm

xterm cannot be cross built from source, because its build dependency on
xorg-docs-core is unsatisfiable. In general, Architecture: all packages
that are not marked Multi-Arch: foreign cannot satisfy cross
Build-Depends at all. I propose marking it Multi-Arch: foreign, because
it is Architecture: all, has no maintainer scripts or depdendencies. The
same holds for xorg-docs. Please consider applying the attached patch.


I prepared an NMU with this fix, plus the fix for the broken symlink in
#858469, plus a change in the VCS from 2016 that has not been released
yet.

debdiff attached.

I uploaded to delayed/15, but if you want me to cancel or if it's OK to
change it to happen sooner, please let me know.


Cheers.
--
Manuel A. Fernandez Montecelo 

diff -u xorg-docs-1.7.1/debian/changelog xorg-docs-1.7.1/debian/changelog
--- xorg-docs-1.7.1/debian/changelog
+++ xorg-docs-1.7.1/debian/changelog
@@ -1,3 +1,21 @@
+xorg-docs (1:1.7.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Manuel A. Fernandez Montecelo ]
+  * Remove d/xorg-docs.links (Closes: #858469)
+- /usr/share/X11/doc was broken for years (the file was last modified
+  in 2010) without anybody complaining, so rather than fixing the
+  destination it's probably better to just remove this legacy bit
+
+  [ Julien Cristau ]
+  * Switch xorg.freedesktop.org URLs in packaging to https.
+
+  [ Helmut Grohne ]
+  * Mark all packages Multi-Arch: foreign. (Closes: #840813)
+
+ -- Manuel A. Fernandez Montecelo   Fri, 29 Sep 2017 00:05:13 
+0200
+
 xorg-docs (1:1.7.1-1) unstable; urgency=medium
 
   * Team upload.
diff -u xorg-docs-1.7.1/debian/control xorg-docs-1.7.1/debian/control
--- xorg-docs-1.7.1/debian/control
+++ xorg-docs-1.7.1/debian/control
@@ -24,6 +24,7 @@
 Depends: ${misc:Depends}
 Suggests: xorg-docs
 Replaces: xorg-docs ( << 1:1.4-5 )
+Multi-Arch: foreign
 Description: Core documentation for the X.org X Window System
  This package contains core documentation for the X.org X Window
  System. This currently includes only a set of manpages which are
@@ -34,6 +35,7 @@
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Conflicts: xprt-xprintorg (<= 1:0.1.0.alpha1-10)
 Replaces: xspecs (<= 1:1.2+git20061105-2), xprt-xprintorg (<= 
1:0.1.0.alpha1-10)
+Multi-Arch: foreign
 Description: Miscellaneous documentation for the X.org X Window System
  This package contains various documents on the X.org X Window System
  including the release notes for the current version and instructions on
diff -u xorg-docs-1.7.1/debian/copyright xorg-docs-1.7.1/debian/copyright
--- xorg-docs-1.7.1/debian/copyright
+++ xorg-docs-1.7.1/debian/copyright
@@ -1,5 +1,5 @@
 This package was downloaded from
-http://xorg.freedesktop.org/releases/individual/doc/.
+https://xorg.freedesktop.org/releases/individual/doc/.
 
 Packager's note: Taken from the generated general/License.txt
 
diff -u xorg-docs-1.7.1/debian/watch xorg-docs-1.7.1/debian/watch
--- xorg-docs-1.7.1/debian/watch
+++ xorg-docs-1.7.1/debian/watch
@@ -4 +4 @@
-http://xorg.freedesktop.org/releases/individual/doc/ xorg-docs-(.*)\.tar\.gz
+https://xorg.freedesktop.orgreleases/individual/doc/ xorg-docs-(.*)\.tar\.gz
reverted:
--- xorg-docs-1.7.1/debian/xorg-docs.links
+++ xorg-docs-1.7.1.orig/debian/xorg-docs.links
@@ -1 +0,0 @@
-usr/share/doc/xorg-docs/docs usr/share/X11/doc

Bug#874434: severity is grave

[Tiago Stürmer Daitx]

Please consider removing the jvm.cfg checks. OpenJDK 7, 8, and 9 have
been shipping a default jvm.cfg for quite some time now and it is used
when a jvm.cfg is not present in the /etc/ directory.

Patch is attached.


thanks


ca-certificates-java_20170531+nmu1_20170531+nmu1.1.debdiff
Description: Binary data

Bug#742829: closed by intrigeri (Bug#742829: fixed in apparmor 2.10.95-8)

[Guido Günther]

Hi,
On Thu, Sep 28, 2017 at 05:20:51PM -0400, Daniel Richard G. wrote:
> On Thu, 2017 Sep 28 22:07+0200, Guido Günther wrote:
> >
> > I would have hoped you'd simply report wishlist bug against chromium
> > with the new profile attached? This gives us a bug to track for futher
> > discussion. I'd do it myself but my profile is less well tested since
> > I just hacked it up a couple of days ago.
> 
> Lately, I'm not in a good position to get so involved here. Replying to
> inquiries is one thing; opening new bugs and starting new discussions
> is another.
> 
> I'll provide the profile, but someone else would have to handle the
> bug/discussion legwork needed to get it into Debian.

Attaching to this the report is fine. I can handle it from there.
 -- Guido

Bug#877123: RM: vdk-doc -- obsolete documentation for vdk 1

[Matthias Klose]

Package: ftp.debian.org
X-Debbugs-CC: m...@debian.org

Please remove the vdk-doc package, it has documentation for vdk1, which is not
shipped anymore in Debian, and there is a libvdk2-doc package.

Bug#873080: SDDM

[Lisandro Damián Nicanor Pérez Meyer]

On 27 September 2017 at 04:00, MH  wrote:
> This bug, previously reported by me, still exists in sddm 0.15.0-1
>
> Additional information:
>
> The problem (black/blank screen) exhibits only when connected via an A/V
> receiver.  Sddm displays normally when attached directly to the TV (4k).
>
> NVidia softare correctly enumerates the A/V device, so the latter must be
> sending correct EDID info. Also, it reports 1080p resolution, which is the
> maximum input resolution for the A/V device.
>
> The problem clearly lies with sddm.

Why? There is no full evidence of that.

SDDM might be using something the nVidia card does not supports, that
wouldn't be the first time it happens I'm afraid. The fact that you
see this only with SDDM doesn't means it's SDDM's fault.

Now if you could reproduce the bug with another video card, specially
with open drivers, that would be another story (or not).

Bug#871542: chromium: Chromium 60 UI is huge on HiDPI displays

[Yuri D'Elia]

Package: chromium
Version: 61.0.3163.100-2
Followup-For: Bug #871542

I was also hit by this bug with Chromium 61.
At 2560x1440 the UI is just overblown.

Using an 1.5 scale factor fixes the size to something acceptable, but
only when I'm using the laptop's screen. When booting with an external
screen, the DPI is lower, and thus the environment variable needs to be
changed.

I don't understand why Chromium is not using the reported DPI setting
(values reported by XRandR are correct!) and instead is introducing
another useless scaling factor!

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

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

Versions of packages chromium depends on:
ii  chromium-common  61.0.3163.100-2
ii  libasound2   1.1.3-5
ii  libatk1.0-0  2.26.0-2
ii  libavcodec57 10:3.3.4-dmo1
ii  libavformat5710:3.3.4-dmo1
ii  libavutil55  10:3.3.4-dmo1
ii  libc62.24-17
ii  libcairo21.14.10-1
ii  libcups2 2.2.4-7
ii  libdbus-1-3  1.11.18-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.3-1
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.12.3-0.2
ii  libfreetype6 2.8-0.2
ii  libgcc1  1:7.2.0-10.0+really6~reproducible1
ii  libgdk-pixbuf2.0-0   2.36.10-2
ii  libglib2.0-0 2.54.0-1
ii  libgtk2.0-0  2.24.31-2
ii  libharfbuzz0b1.4.2-1
ii  libicu57 57.1-6
ii  libjpeg62-turbo  1:1.5.2-2
ii  liblcms2-2   2.8-4
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.16-1
ii  libnss3  2:3.32-2
ii  libopus0 1.2.1-1
ii  libpango-1.0-0   1.40.12-1
ii  libpangocairo-1.0-0  1.40.12-1
ii  libpng16-16  1.6.32-3
ii  libpulse011.1-1
ii  libre2-3 20170101+dfsg-1
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   7.2.0-10.0+really6~reproducible1
ii  libvpx4  1.6.1-3
ii  libwebp6 0.6.0-3
ii  libwebpdemux20.6.0-3
ii  libwebpmux3  0.6.0-3
ii  libx11-6 2:1.6.4-3
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb1  1.12-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.14-3
ii  libxdamage1  1:1.1.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-4
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.29-2.1
ii  libxss1  1:1.2.2-1+b2
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-2

Versions of packages chromium suggests:
pn  chromium-driver
pn  chromium-l10n  
pn  chromium-shell 
pn  chromium-widevine  

Bug#877122: libengine-pkcs11-openssl1.1: Engine is installed into wrong directory on i386

[Konstantin Pavlov]

Package: libengine-pkcs11-openssl1.1
Version: 0.4.4-4
Severity: normal

Dear Maintainer,

pkcs11.so is installed to /usr/lib/i686-linux-gnu/engines-1.1/, which is
wrong for i386 architecture and openssl fails to load the engine:

# openssl engine pkcs11 -t
3073050944:error:25066067:DSO support routines:dlfcn_load:could not load the 
shared 
library:../crypto/dso/dso_dlfcn.c:113:filename(/usr/lib/i386-linux-gnu/engines-1.1/pkcs11.so):
 /usr/lib/i386-linux-gnu/engines-1.1/pkcs11.so: cannot open shared object file: 
No such file or directory
3073050944:error:25070067:DSO support routines:DSO_load:could not load the 
shared library:../crypto/dso/dso_lib.c:161:
3073050944:error:260B6084:engine routines:dynamic_load:dso not 
found:../crypto/engine/eng_dyn.c:414:
3073050944:error:2606A074:engine routines:ENGINE_by_id:no such 
engine:../crypto/engine/eng_list.c:339:id=pkcs11


Manually symlinking the file works, though:

root:/usr/lib/i386-linux-gnu/engines-1.1# LC_ALL=C ls -l
total 32
-rw-r--r-- 1 root root  5384 Jun  5 12:40 capi.so
-rw-r--r-- 1 root root 22056 Jun  5 12:40 padlock.so
root:/usr/lib/i386-linux-gnu/engines-1.1# ln -sf 
/usr/lib/i686-linux-gnu/engines-1.1/pkcs11.so 
root:/usr/lib/i386-linux-gnu/engines-1.1# LC_ALL=C ls -l
total 32
-rw-r--r-- 1 root root  5384 Jun  5 12:40 capi.so
-rw-r--r-- 1 root root 22056 Jun  5 12:40 padlock.so
lrwxrwxrwx 1 root root45 Sep 29 00:28 pkcs11.so -> 
/usr/lib/i686-linux-gnu/engines-1.1/pkcs11.so
root:/usr/lib/i386-linux-gnu/engines-1.1# openssl engine pkcs11 -t
(pkcs11) pkcs11 engine
 [ available ]


I guess his happens because DEB_HOST_GNU_TYPE is used in debian/rules
instead of DEB_HOST_MULTIARCH.


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

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

Versions of packages libengine-pkcs11-openssl1.1 depends on:
ii  libc6  2.24-11+deb9u1
ii  libssl1.1  1.1.0f-3
ii  p11-kit0.23.3-2

libengine-pkcs11-openssl1.1 recommends no packages.

libengine-pkcs11-openssl1.1 suggests no packages.

-- no debconf information

Bug#876033: primus: fix found?

[nils]

Package: primus
Version: 0~20150328-4
Followup-For: Bug #876033

Dear Maintainer,

I had the same problem after switching to glvnd on sid.
I edited /usr/bin/primusrun and found

PRIMUS_libGL=${PRIMUS_libGL:-'/usr/$LIB/primus'}

replacing the simple quotes by double quotes fixed it (in the commented
out parts, singne quotes needs to be replaced too).

Hope this is it,
Regards,
Nils

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

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

Versions of packages primus depends on:
ii  bumblebee  3.2.1-16
ii  primus-libs0~20150328-4
ii  socat  1.7.3.2-1
ii  xserver-xorg-core  2:1.19.3-2

Versions of packages primus recommends:
ii  primus-libs-ia32  0~20150328-4

primus suggests no packages.

-- no debconf information

Bug#742829: closed by intrigeri (Bug#742829: fixed in apparmor 2.10.95-8)

[Daniel Richard G.]

On Thu, 2017 Sep 28 22:07+0200, Guido Günther wrote:
>
> I would have hoped you'd simply report wishlist bug against chromium
> with the new profile attached? This gives us a bug to track for futher
> discussion. I'd do it myself but my profile is less well tested since
> I just hacked it up a couple of days ago.

Lately, I'm not in a good position to get so involved here. Replying to
inquiries is one thing; opening new bugs and starting new discussions
is another.

I'll provide the profile, but someone else would have to handle the
bug/discussion legwork needed to get it into Debian.

Bug#877120: RM: libcodemodel-java -- ROM; Binary package moved to src:jaxb

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal


Hi,

Please remove the src:libcodemodel-java package, its binary package 
libcodemodel-java
is now built by src:jaxb.

Thank you,

Emmanuel Bourg

Bug#877121: RM: xsom -- ROM; Binary package moved to src:jaxb

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal


Hi,

Please remove the src:xsom package, its binary package libxsom-java
is now built by src:jaxb.

Thank you,

Emmanuel Bourg

Bug#877119: RM: txw2 -- ROM; Binary package moved to src:jaxb

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal


Hi,

Please remove the src:txw2 package, its binary package libtxw2-java
is now built by src:jaxb.

Thank you,

Emmanuel Bourg

Bug#874656: libegl1-mesa: Makes team fortress 2 crash the entire machine

[Salvo Tomaselli]

I had downgraded my mesa. I wanted to try again but I can't upgrade it
because of some llvm breakage at the moment.

# aptitude dist-upgrade
I seguenti pacchetti NUOVI (NEW) saranno installati:
 libllvm5.0:i386{ab}
I seguenti pacchetti saranno RIMOSSI:
 libllvm3.9:i386{u}
I seguenti pacchetti saranno aggiornati:
 libgl1-mesa-dri libgl1-mesa-dri:i386 libllvm3.9 libopus0 login passwd
I seguenti pacchetti sono RACCOMANDATI ma NON verranno installati:
 libtxc-dxtn-s2tc
6 pacchetti aggiornati, 1 installati, 1 da rimuovere e 0 non aggiornati.
È necessario prelevare 42,7 MB di archivi. Dopo l'estrazione, verranno
occupati 51,9 MB.
I seguenti pacchetti hanno dipendenze non soddisfatte:
libllvm5.0 : Rompe: libllvm5.0:i386 (!= 1:5.0-2) but 1:5.0-1 is to be installed
libllvm5.0:i386 : Rompe: libllvm5.0 (!= 1:5.0-1) but 1:5.0-2 is installed
Le seguenti azioni permetteranno di soddisfare queste dipendenze:

Mantenere i seguenti pacchetti alla versione attuale:
1) libgl1-mesa-dri [13.0.6-1+b2 (now, testing)]
2) libgl1-mesa-dri:i386 [13.0.6-1+b2 (now, testing)]
3) libllvm3.9 [1:3.9.1-13 (now)]
4) libllvm3.9:i386 [1:3.9.1-13 (now, unstable)]
5) libllvm5.0:i386 [Non installato]

2017-09-28 19:46 GMT+02:00 Andreas Boll :
> On Sat, Sep 09, 2017 at 11:16:54PM +0300, Timo Aaltonen wrote:
>> On 09.09.2017 02:31, Salvo Tomaselli wrote:
>> > Well I had to downgrade to testing since it was making my machine crash.
>>
>> Doesn't crash my KBL now that I tested it. Try an older kernel maybe.
>
> Can you reproduce this issue with an older kernel (from snapshot.debian.org) 
> or a newer kernel (from experimental)?
>
> Thanks,
> Andreas



-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/

Bug#877118: RM: rngom -- ROM; Binary package moved to src:jaxb

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the src:rngom package, its binary package librngom-java
is now built by src:jaxb.

Thank you,

Emmanuel Bourg

Bug#874715: mesa Games like Counter-Strike Global Offensive dont start after upgrading mesa to 17.2.0-2

[Hillel Lubman]

Should such bugs be a blocker? Other games work fine with this Mesa. 
This stalls
migration of the package to testing for a lot of people. Just for the 
reference,
if you need a specific Mesa, you can always use older one locally 
(without touching

the system wide package) and run some game with it.

I don't think it's good to stall the package because of this for 
everyone else.

The severity here should be probably important, not grave.

Regards,
Hillel Lubman.

Bug#850753: fresh upstream (and ubuntu) is available (1.12.3)

[Balint Reczey]

Hi,

On Tue, 26 Sep 2017 12:44:11 +0200 Bastian Venthur 
wrote:
> Dear Maintainer,
>
> is there anything we can help to prepare a new upload to unstable?

I have just updated runc to 1.0.0~rc4 thus updating docker.io became easier.
I can't find time to update docker.io as well in the near future. :-(

Cheers,
Balint

>
>
> Cheers,
>
> Bastian
>
> On Mon, 24 Jul 2017 17:11:50 +0200 Bastian Venthur 
> wrote:
> > Hi,
> >
> > any updates on when a new update of docker will be available in
unstable?
> >
> >
> > Cheers,
> >
> > Bastian
> >
> > On Wed, 11 Jan 2017 10:12:52 -0800 Tianon Gravi 
wrote:
> > > On 9 January 2017 at 14:13, Yaroslav Halchenko
 wrote:
> > > > Ubuntu docker.io 1.12.3-0ubuntu4
http://packages.ubuntu.com/zesty/docker.io
> > >
> > > The reason Ubuntu is able to be more aggressive than Debian is that
> > > they've made an explicit release exception for using Docker's
> > > published "vendor" directory as-is rather than splitting it out into
> > > individual packages (which is what causes so much headache for us in
> > > Debian every new Docker release, and causes a greater number of issues
> > > such as #835686).
>
> --
> Dr. Bastian Venthur http://venthur.de
> Debian Developer venthur at debian org
>
>

Bug#877117: pdal FTBFS with Sphinx 1.6.4-1: dh_sphinxdoc: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX

[Adrian Bunk]

Source: pdal
Version: 1.5.0-3
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pdal.html

...
   dh_sphinxdoc -O--parallel
dh_sphinxdoc: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX
debian/rules:19: recipe for target 'binary' failed
make: *** [binary] Error 255


sphinx (1.6.4-1) unstable; urgency=medium
...
  * dh_sphinxdoc: Turn warning about missing SOURCELINK_SUFFIX to an error.
...
 -- Dmitry Shachnev   Tue, 26 Sep 2017 17:47:54 +0300

Bug#877116: bluetooth: UE Roll 2 bluetooth audio device does not appear after connecting

[Sam Morris]

Package: bluetooth
Version: 5.43-2+deb9u1
Severity: normal

Having connected via gnome-control-center, the bluetooth audio device
does not appear in the sound settings page.

bluez logs the following messages:

Sep 28 21:42:19 bluetoothd[533]: vendor 0x0 product: 0x0
Sep 28 21:42:19 bluetoothd[533]: a2dp-source profile connect failed for 
C0:28:8D:00:EE:61: Device or resource busy
Sep 28 21:42:22 bluetoothd[533]: /org/bluez/hci0/dev_C0_28_8D_00_EE_61/fd7: 
fd(36) ready

This seems similar to
. The device works
fine with my Android phone and has the latest firmware.

-- System Information:
Debian Release: 9.1
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'stable-debug'), (550, 'stable'), 
(530, 'testing'), (510, 'unstable-debug'), (510, 'unstable'), (400, 
'experimental-debug'), (400, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.12.0-0.bpo.1-amd64 (SMP w/2 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 bluetooth depends on:
ii  bluez  5.43-2+deb9u1

bluetooth recommends no packages.

Versions of packages bluetooth suggests:
pn  bluez-cups   
ii  bluez-obexd  5.43-2+deb9u1

-- debconf-show failed


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

Bug#877115: RM: iannix [armhf armel] -- RoQA; cannot build anymore due to Qt using OpenGL ES

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

Qt uses on armhf/armel OpenGL ES instead of OpenGL,
which makes iannix that also uses OpenGL directly unbuildable.

Bug#877114: python-scipy FTBFS with Sphinx 1.6.4-1: dh_sphinxdoc: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX

[Adrian Bunk]

Source: python-scipy
Version: 0.19.1-1
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-scipy.html

...
dh_sphinxdoc -i
dh_sphinxdoc: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX
debian/rules:122: recipe for target 'override_dh_installdocs-indep' failed
make[1]: *** [override_dh_installdocs-indep] Error 255


sphinx (1.6.4-1) unstable; urgency=medium
...
  * dh_sphinxdoc: Turn warning about missing SOURCELINK_SUFFIX to an error.
...
 -- Dmitry Shachnev   Tue, 26 Sep 2017 17:47:54 +0300

Bug#877112: python-pygit2 FTBFS with Sphinx 1.6.4-1: dh_sphinxdoc: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX

[Adrian Bunk]

Source: python-pygit2
Version: 0.26.0-2
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-pygit2.html

...
dh_sphinxdoc
dh_sphinxdoc: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX
debian/rules:10: recipe for target 'override_dh_sphinxdoc' failed
make[1]: *** [override_dh_sphinxdoc] Error 255


sphinx (1.6.4-1) unstable; urgency=medium
...
  * dh_sphinxdoc: Turn warning about missing SOURCELINK_SUFFIX to an error.
...
 -- Dmitry Shachnev   Tue, 26 Sep 2017 17:47:54 +0300

Bug#877113: python-numpy FTBFS with Sphinx 1.6.4-1: dh_sphinxdoc: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX

[Adrian Bunk]

Source: python-numpy
Version: 1:1.13.1-1
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-numpy.html

...
dh_sphinxdoc -i
dh_sphinxdoc: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX
debian/rules:132: recipe for target 'override_dh_installdocs-indep' failed
make[1]: *** [override_dh_installdocs-indep] Error 255


sphinx (1.6.4-1) unstable; urgency=medium
...
  * dh_sphinxdoc: Turn warning about missing SOURCELINK_SUFFIX to an error.
...
 -- Dmitry Shachnev   Tue, 26 Sep 2017 17:47:54 +0300

Bug#877110: python-mongoengine FTBFS with Sphinx 1.6.4-1: dh_sphinxdoc: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX

[Adrian Bunk]

Source: python-mongoengine
Version: 0.10.6-1
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-mongoengine.html

...
   dh_sphinxdoc -O--buildsystem=pybuild
dh_sphinxdoc: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX
debian/rules:6: recipe for target 'binary' failed
make: *** [binary] Error 255


sphinx (1.6.4-1) unstable; urgency=medium
...
  * dh_sphinxdoc: Turn warning about missing SOURCELINK_SUFFIX to an error.
...
 -- Dmitry Shachnev   Tue, 26 Sep 2017 17:47:54 +0300

Bug#877107: expeyes: [INTL:pt] Portuguese translation for debconf messages

[Traduz - DebianPT]

Package: expeyes
Version: 4.2.1+dfsg-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for expeyes's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
--
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org





















# Portuguese translation of Expeyes's debconf messages.
# Copyright (C) 2017
# This file is distributed under the same license as the Expeyes package.
# Rui Branco , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: Expeyes 4.2.1+dfsg-2\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2017-09-18 14:27+\n"
"PO-Revision-Date: 2017-09-22 14:50+0100\n"
"Last-Translator: Rui Branco \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: select
#. Description
#: ../expeyes-web.templates:1001
msgid "List of web servers to reconfigure automatically:"
msgstr "Lista de servidores web a reconfigurar automaticamente:"

#. Type: select
#. Description
#: ../expeyes-web.templates:1001
msgid "Expeyes-Web currently supports Apache2."
msgstr "O Expeyes-Web suporta actualmente o Apache2."

#. Type: select
#. Description
#: ../expeyes-web.templates:1001
msgid "If no web service is installed, choose \"none\"."
msgstr "Se nenhum serviço for instalado escolha \"nenhum\"."

#. Type: string
#. Description
#: ../expeyes-web.templates:2001
msgid "This should be the URL of the Expeyes service:"
msgstr "Este deve ser o URL do serviço Expeyes:"

#. Type: string
#. Description
#: ../expeyes-web.templates:2001
msgid ""
"Choose some fully qualified domain name, and make sure that this name will "
"be resolved by DNS servers to your server's IP address."
msgstr ""
"Escolha um nome de domínio totalmente qualificado e garanta que este nome "
"será resolvido pelos servidores DNS para o endereço IP do seu servidor."

#. Type: string
#. Description
#: ../expeyes-web.templates:3001
msgid "This should be the URL reachable by the \"Home\" link:"
msgstr "Este deverá ser o URL alvo do link \"Home\":"

#. Type: string
#. Description
#: ../expeyes-web.templates:3001
msgid ""
"The main page featured by the Expeyes service has a few active buttons in "
"its top. The \"Home\" button can be a link to a schools welcome page."
msgstr ""
"A página principal fornecida pelo serviço Expeyes possui alguns botões "
"activos no seu topo. O botão \"Home\" pode ser um link para uma página de "
"boas vindas de uma escola."

#. Type: string
#. Description
#: ../expeyes-web.templates:3001
msgid ""
"Choose some fully qualified domain name, and make sure that this name will "
"be resolved by DNS servers to your school server's IP address."
msgstr ""
"Escolha um nome de domínio totalmente qualificado e garanta que este nome "
"será resolvido pelos servidores DNS para o endereço IP da sua escola."

Bug#877109: pybtex FTBFS with Sphinx 1.6.4-1: dh_sphinxdoc: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX

[Adrian Bunk]

Source: pybtex
Version: 0.21-2
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pybtex.html

...
   dh_sphinxdoc -O--buildsystem=pybuild
dh_sphinxdoc: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX
debian/rules:18: recipe for target 'binary' failed
make: *** [binary] Error 255


sphinx (1.6.4-1) unstable; urgency=medium
...
  * dh_sphinxdoc: Turn warning about missing SOURCELINK_SUFFIX to an error.
...
 -- Dmitry Shachnev   Tue, 26 Sep 2017 17:47:54 +0300

Bug#877111: python-pysnmp4 FTBFS with Sphinx 1.6.4-1: dh_sphinxdoc: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX

[Adrian Bunk]

Source: python-pysnmp4
Version: 4.3.2-2
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-pysnmp4.html

...
   dh_sphinxdoc -O--buildsystem=pybuild
dh_sphinxdoc: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX
debian/rules:7: recipe for target 'binary' failed
make: *** [binary] Error 255


sphinx (1.6.4-1) unstable; urgency=medium
...
  * dh_sphinxdoc: Turn warning about missing SOURCELINK_SUFFIX to an error.
...
 -- Dmitry Shachnev   Tue, 26 Sep 2017 17:47:54 +0300

Bug#877055: qm-dsp FTBFS with multiarch atlas

[Debian/GNU]

On Thu, 28 Sep 2017 11:00:59 +0300 Adrian Bunk  wrote:
> Removing 02-fix_include.patch fixes the problem.

but this will most likely use the bundled clapack.h/cblas.h instead of
the system-provided one...



signature.asc
Description: OpenPGP digital signature

Bug#877108: maildrop: reformail: use-after-free in add_from_filter()

[Jakub Wilk]

Package: maildrop
Version: 2.8.4-2

When you run "reformail -f1" against a message with malformed Errors-To 
header, reformail uses memory that has been already freed:


  $ printf 'Errors-To:' | valgrind --quiet -- reformail -f1
  ==8668== Invalid read of size 1
  ==8668==at 0x10BEEA: add_from_filter() (reformail.C:186)
  ==8668==by 0x10B575: ReadLineAddHeader() (reformail.C:523)
  ==8668==by 0x10C417: ReadLine() (reformail.C:664)
  ==8668==by 0x10C78B: copy(int, char**, int) (reformail.C:721)
  ==8668==by 0x1093A2: main (reformail.C:1214)
  ==8668==  Address 0x4c3e121 is 9 bytes inside a block of size 512 free'd
  ==8668==at 0x482FE78: operator delete[](void*) (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
  ==8668==by 0x10BEE3: ~Buffer (buffer.h:25)
  ==8668==by 0x10BEE3: add_from_filter() (reformail.C:188)
  ==8668==by 0x10B575: ReadLineAddHeader() (reformail.C:523)
  ==8668==by 0x10C417: ReadLine() (reformail.C:664)
  ==8668==by 0x10C78B: copy(int, char**, int) (reformail.C:721)
  ==8668==by 0x1093A2: main (reformail.C:1214)
  ==8668==  Block was alloc'd at
  ==8668==at 0x482F00C: operator new[](unsigned int) (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
  ==8668==by 0x10D6D4: Buffer::append(int) (buffer.C:15)
  ==8668==by 0x10BCE5: push (buffer.h:41)
  ==8668==by 0x10BCE5: add_from_filter() (reformail.C:195)
  ==8668==by 0x10B575: ReadLineAddHeader() (reformail.C:523)
  ==8668==by 0x10C417: ReadLine() (reformail.C:664)
  ==8668==by 0x10C78B: copy(int, char**, int) (reformail.C:721)
  ==8668==by 0x1093A2: main (reformail.C:1214)
  ...


Found using American Fuzzy Lop:
http://lcamtuf.coredump.cx/afl/

-- System Information:
Architecture: i386

Versions of packages maildrop depends on:
ii  courier-authlib  0.68.0-4
ii  libc62.24-17
ii  libcourier-unicode1  1.4-3+b1
ii  libgcc1  1:7.2.0-7
ii  libgdbm3 1.8.3-14
ii  libpcre3 2:8.39-5
ii  libstdc++6   7.2.0-7

--
Jakub Wilk

Bug#876401: ITA: xdg-utils -- desktop integration utilities from freedesktop.org

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

Hi,

28.09.2017 14:58, Emilio Pozuelo Monfort пишет:
> I have approved your request to join pkg-freedesktop.
Thank you!

So I'll do as suggested by Laurent Bigonville. I'll put an email address
of the team in the Maintainer field and my name in the Uploaders list.
And then I'll be continuing my work on the package this weekend.

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Andreas Tille]

On Thu, Sep 28, 2017 at 06:53:26PM +0200, Sébastien Villemot wrote:
> On Thu, Sep 28, 2017 at 07:04:51AM -0500, Dirk Eddelbuettel wrote:
> 
> I now understand that we ideally need two API/ABI-like values instead of one:
> 
> - one that is bumped when only arch:any packages need to be rebuilt
> 
> - the other one that is bumped when both arch:any and arch:all packages should
>   be rebuilt
> 
> The first value would appear in the Depends of arch:any package, but not of
> arch:all ones; the second value would appear in the Depends of both arch:any
> and arch:all.
> 
> Because, for this transition and for the next one (in April), we will have to
> make sourceful uploads of ~170 arch:all packages… that actually do not need to
> be rebuilt. And this is very painful because it must be done manually 
> (contrary
> to rebuilds of arch:any packages that can be trigerred easily).
> 
> If we adopted this scheme right now, that would save us a lot of work for the
> April transition (but not for this one, because we first have to convert
> arch:all packages to the new scheme).
> 
> Please tell me what you think.

I wonder if we could teach dh-r to make sure that is added to arch:all
packages.  I'm converting all packages I'm touching to dh-r anyway.

At least a lintian warning might help.

Kind regards

  Andreas (after having uploaded 4 arch:all packages and converted
   two of these from cdbs to dh-r)


-- 
http://fam-tille.de

Bug#803930: game-data-packager: please add support to create icons from the game data

[Fabian Greffrath]

Am Donnerstag, den 14.09.2017, 20:18 +0100 schrieb Simon McVittie:
> I have no plans to implement this (other people are better at Doom
> than
> I am) but I'd be happy to review a patch. The place to put it would be in
> DoomTask.fill_extra_files, in the game_data_packager/games/doom_common.py
> "game plugin".

Unfortunately, I am illiterate in python. :/

> unreal.py in the same directory has some examples of converting game
> files into icons, although they're downloaded from the Internet Archive
> rather than extracted from game data. (Actually, that might not be a bad
> idea for Doom - it would avoid relying on deutex, which realistically not
> many people are going to have installed.)

I don't think you will find any game assets from Doom in the Internet
Archive, as the game is still actively sold. But I buy your argument
about deutex being an obscure tool which even the people playing Doom
are unlikely to have installed on their systems.

 - Fabian


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

Bug#876084: [libglvnd-dev] Can't upgrade libglvnd-dev anymore

[Timo Aaltonen]

On 18.09.2017 12:55, Bogdan Vatra wrote:
> Package: libglvnd-dev
> Severity: normal
> 
> --- Please enter the report below this line. ---
> When I'm trying to upgrade that package (which is needed by libgl1-mesa-dev)
> apt says that it depends on "libopengl0 (= 0.2.999+git20170802-4)" which it's 
> not available.

Sure is, but do you have libgl1-mesa-dev:i386 installed?



-- 
t

Bug#876837: [Pkg-fonts-devel] Bug#876837: Bug#876837: Bug#876837: fonttools bug

[Fabian Greffrath]

Am Donnerstag, den 28.09.2017, 19:37 + schrieb Holger Levsen:
> just revert my changes and apply your changes… (and then I can
> cherry-pick
> those changes of mine which you didnt do…)

I have already merged our branches and also the changelog, so it would
probably be the cleanest solution to re-upload the current state in GIT
as a new revision. :/

> thanks for your work on fonts-liberation(2)! 

Sure. ;)

 - Fabian


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

Bug#876041: transition: gl2ps

[Anton Gladky]

The package is successfully built on all relevant platforms.
Please, schedule binnmus.

Thank you,

Anton


2017-09-27 0:24 GMT+02:00 Emilio Pozuelo Monfort :
>
> Go ahead.
>
> Cheers,
> Emilio

Bug#868087: light-locker

[christopher mark]

Also, as it may be of relevance, I am running Nvidia properitary drivers.

Bug#877106: pinta: Pinta 1.6-2 crashes on image scaling and other image manipulation.

[nbi]

Package: pinta
Version: 1.6-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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

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

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



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

Kernel: Linux 4.9.2 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968), LANGUAGE=en_US.utf8 (charmap=locale: Cannot set LC_CTYPE to 
default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pinta depends on:
ii  gnome-icon-theme3.12.0-2
ii  libc6   2.24-11+deb9u1
ii  libcairo2   1.14.8-1
ii  libgdk-pixbuf2.0-0  2.36.5-2+deb9u1
ii  libglib2.0-cil  2.12.40-2
ii  libgtk2.0-cil   2.12.40-2
ii  libmono-addins-gui0.2-cil   1.0+git20130406.adcd75b-4
ii  libmono-addins0.2-cil   1.0+git20130406.adcd75b-4
ii  libmono-cairo4.0-cil4.6.2.7+dfsg-1
ii  libmono-corlib4.5-cil   4.6.2.7+dfsg-1
ii  libmono-posix4.0-cil4.6.2.7+dfsg-1
ii  libmono-sharpzip4.84-cil4.6.2.7+dfsg-1
ii  libmono-system-core4.0-cil  4.6.2.7+dfsg-1
ii  libmono-system-xml4.0-cil   4.6.2.7+dfsg-1
ii  libmono-system4.0-cil   4.6.2.7+dfsg-1
ii  mono-runtime4.6.2.7+dfsg-1

pinta recommends no packages.

pinta suggests no packages.

-- debconf information excluded

Bug#742829: closed by intrigeri (Bug#742829: fixed in apparmor 2.10.95-8)

[Guido Günther]

Hi,
On Thu, Sep 28, 2017 at 03:07:15PM -0400, Daniel Richard G. wrote:
> On Thu, 2017 Sep 28 11:21+0200, Guido Günther wrote:
> >
> > > That would amount to the Debian Chromium maintainers becoming the
> > > new upstream for the profile. (Apparmor is basically maintained by
> >
> > Or maybe people caring about the chromium profile like you, me and
> > others in this thread.
> 
> You still need someone to actually upload it to Debian. It doesn't do
> much good if I have a current profile in GitHub somewhere and
> Debian/Ubuntu fail to pick it up.
> 
> > > I don't know any of the Debian-Chromium folks to have a sense of
> > > what they're open to; would you?
> >
> > Unfortunately not.
> >
> > > I'll be happy to provide that updated Chromium profile if you
> > > want it.
> >
> > Could you attach this to new bug against Chromium. If you'd be willing
> > to maintain the profile longterm I'd add that to the report too.
> 
> I'll be happy to attach it; just let this thread know the new bug
> number.
> 
> Before that, however, you may want to bring this up on a Debian mailing
> list, to get a feel for things.

I would have hoped you'd simply report wishlist bug against chromium
with the new profile attached? This gives us a bug to track for futher
discussion. I'd do it myself but my profile is less well tested since I
just hacked it up a couple of days ago.
Cheers,
 -- Guido

Bug#805268: Adoption of syslinux

[Lukas Schwaighofer]

Control: owner -1 Debian CD Group 
Control: retitle -1 ITA: syslinux -- collection of bootloaders (DOS FAT and 
NTFS bootloader)

Hi,

I intend to work on syslinux as part of the Debian CD Group.  I'm open
to team maintenance and will probably need help every now and then
anyways, so if you read this and also want to step in just let me
know :) .

Regards
Lukas

Bug#872275: slic3r-prusa: diff for NMU version 1.37.0+dfsg-1.1

[gregor herrmann]

On Wed, 23 Aug 2017 19:32:43 +0200, gregor herrmann wrote:

> I've prepared an NMU for slic3r-prusa (versioned as 1.37.0+dfsg-1.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.

I [0] notice that the fix for this bug in 1.37.0+dfsg-1.1 has been
overwritten by the upload of 1.37.1+dfsg-1 which is a bit unfortunate
since now the package has 3 instead of 2 RC bugs.

Oh well.


Cheers,
gregor

[0] Actually it was ntyni, thanks!

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Alanis Morissette: Princes Familiar


signature.asc
Description: Digital Signature

Bug#854021: fwbuilder: Consider following fork / new upstream https://github.com/fwbuilder/

[Chris]

Hi,

On Fri, 03 Feb 2017 02:10:27 -0500 Matthew Gabeler-Lee
 wrote:
> Package: fwbuilder
> Version: 5.1.0-4+b2
> Severity: wishlist
> 
> There seems to be a new upstream, or at least an actively maintained fork:
> https://github.com/fwbuilder/fwbuilder, while the existing upstream has not
> shown any signs of life for several years.

it seems that the original authors have announced the suspension of the
development activity for fwbuilder at their sourceforge page:

https://sourceforge.net/p/fwbuilder/news/2013/04/announcement-/

Since then the fork has released various new versions (currently 5.3.7,
see https://github.com/fwbuilder/fwbuilder/blob/master/doc/ChangeLog) so
it looks to me like the fork would be the way to go here.

> -- System Information:
> Debian Release: 9.0
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages fwbuilder depends on:
> ii  fwbuilder-common  5.1.0-4
> ii  libc6 2.24-8
> ii  libgcc1   1:6.3.0-5
> ii  libqt4-network4:4.8.7+dfsg-11
> ii  libqtcore44:4.8.7+dfsg-11
> ii  libqtgui4 4:4.8.7+dfsg-11
> ii  libsnmp30 5.7.3+dfsg-1.7
> ii  libssl1.0.2   1.0.2j-5
> ii  libstdc++66.3.0-5
> ii  libxml2   2.9.4+dfsg1-2.1
> ii  libxslt1.11.1.29-2
> ii  zlib1g1:1.2.8.dfsg-4
> 
> Versions of packages fwbuilder recommends:
> ii  fwbuilder-doc  5.1.0-4
> pn  rcs
> 
> fwbuilder suggests no packages.
> 
> -- no debconf informatio

Bug#877047: RFS: sane-backends-extras/1.0.22.5 [QA]

[Herbert Fortes]

Hi Hugh McMaster,

> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "sane-backends-extras".
> 
> * Package name: sane-backends-extras
>Version: 1.0.22.5
>Upstream Author: SANE
> * URL: http://www.sane-project.org/
> * License: GPL v2
>Section: graphics
> 
> It builds the following binary packages:
>   * libsane-extras - API library for scanners -- extra backends
>   * libsane-extras-common - API library for scanners -- documentation and 
> support files
>   * 
> lihttp://deb.debian.org/debian/pool/main/b/bogofilter/bogofilter_1.2.4+dfsg1-10.dscbsane-extras-dev
>  - API development library for scanners [development files]
> 
> To access further information about this package, please visit the following 
> URL:
>   https://mentors.debian.net/package/sane-backends-extras
> 
> Alternatively, you may download the package with dget using this command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/s/sane-backends-extras/sane-backends-extras_1.0.22.5.dsc
> 
> Changes since the last upload:
>   * QA upload.
>   * debhelper update:
> - Update package compatibility to level 10
>   * debian/control:
> - Bump debhelper build-dep to >= 10~.
> - Remove autotools-dev from the Build-Depends list, as debhelper
>   enables the 'autoreconf' sequence by default.
> - Bump Standards-Version from 3.9.8 to 4.1.0 (no changes needed).
> - Convert libsane-extras-common to Architecture: all.
> - Mark libsane-extras-dev Multi-Arch: same (Closes: #862263).
>   * debian/extras-backends/geniusvp2:
> - Fix a spelling error in the BUGS file (lintian).
>   * debian/rules:
> - Remove '--with=autotools_dev' (now handled by debhelper level 10).
>   * doc/sane-geniusvp2.man:
> - Fix spelling errors (lintian).
>   * Rename configure.in to configure.ac (lintian).
> 
> Regards,
> 
> Hugh McMaster
> 

Uploaded. Thanks for you time.



Regards,
Herbert

Bug#876837: [Pkg-fonts-devel] Bug#876837: Bug#876837: fonttools bug

[Holger Levsen]

On Thu, Sep 28, 2017 at 09:09:52PM +0200, Fabian Greffrath wrote:
> Am Donnerstag, den 28.09.2017, 20:23 +0200 schrieb Fabian Greffrath:
> > I am on this, about to upload!
> 
> Sorry, I have uploaded this before I could realize you already changed
> the packaging in GIT.

arg, I ment to say so in my mail to this bug. Sorry that I've forgotten…!

> And then my upload was ACCEPTED before I could
> send the dcut token to cancel it. Now we have a different packaging
> state in GIT than in the archive. /o\

just revert my changes and apply your changes… (and then I can cherry-pick
those changes of mine which you didnt do…)

thanks for your work on fonts-liberation(2)! 


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#868871: Build diff-highlight

[Jack Bates]

tags 868871 patch
thanks

I have the same request -- I had been using:

git config --global pager.log 'perl /usr/share/doc/git/contrib/diff-highlight/diff-highlight | less' 


That way my diff-highlight script was always up to date.

I just APT-updated and it stopped working (since diff-highlight must now 
be built, as of this commit [1]).


I think the following will resolve this, by running the diff-highlight 
Makefile when the package is built (following the pattern in 
debian/rules for other contrib things):



diff --git a/debian/rules b/debian/rules
index f132a2605..ea018298b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -58,6 +58,7 @@ build-stamp:
 override_dh_auto_build-arch: build-stamp
$(MAKE) -C contrib/subtree all $(OPTS)
ln -s contrib/subtree/git-subtree
+   $(MAKE) -C contrib/diff-highlight $(OPTS)

 override_dh_auto_test-arch:
test -z '$(TEST)' || \


[1] 
https://github.com/git/git/commit/0c977dbc8180892af42d7ab9235fd3e51d6c4078

Bug#877081: meanwhile for the interested ppl

[Christoph Zysik - ztk.me]

meanwhile this solution is far away from clone but does the job I 
needed, maybe someone else might find it useful.

It's basically what I actually needed/expected.

1. On source system gather the installed packages and source

$apt-show-versions | awk -F'[ ]' '{print $1}' | awk -F'[:/]' '{print $1 
"\t" $3}' > pkg.list


I use that awkward awk since I have packages which didn't come from apt, 
 have no release or have been removed and $apt-show-versions lists them as:


gnupg-agent:amd64 not installed
jailkit:amd64 2.19-1 installed: No available version in archive


2. On destination I prepare my apt-preferences aswell as my sources lists

and since I use https source I'll

$apt-get update
$apt-get install apt-transport-https
$apt-get update


3. On destination I run

$./setup_list.py -i pkg.list

and wait :)

Yes, since apt-clone is in python3, this script aswell requires python, 
I attached it, maybe it's not nice and I won't guarantee it works for 
anyone else soo... missing License aswell so ... do whatever t f u want 
with that :)


The generated pkg.list syntax is:

\t

or a translated example:

curlstretch
#!/usr/bin/python3

import getopt, os, subprocess, sys

def printhelp():
  print("install_list.py -i ")
  print("install_list.py --ifile=")
  print("")
  print("inputfile should contain lines with: packagenamedebversion")
  print("where debversion shall be stable,testing and so on")


def main(argv):
  try:
opts, args = getopt.getopt(argv,"hi:",["ifile="])

  except getopt.GetoptError:
printhelp()
sys.exit(2)

  for opt, arg in opts:
if opt == '-h':
  printhelp()
  sys.exit()

elif opt in ("-i", "--ifile"):
  print ("reading "+arg+"...")
  lines = open(arg).read().splitlines()
  installList = {}
  with open(arg) as f:
  content = f.readlines()
  for x in content:
y = x.split("\t")
index = y[1].strip("\n")
if(index in installList):
  oldvalue = installList[index]
else:
  oldvalue = ""
installList[index] = "%s %s" % (oldvalue,  y[0])
  for k, v in installList.items():
if(k):
  command = "apt-get install -y -t {0} {1}".format(k, v)
  subprocess.run(command.split(), shell=False)


if __name__ == "__main__":
   main(sys.argv[1:])