Bug#909935: exact() fixes/works around it

[Kingsley G. Morse Jr.]

A gnumeric maintainer whose name rhymes with
"Amadeus" suggested using exact().

On GIMPNet's #gnumeric channel.

Like

=if(exact("♂","♀"),"The same","different")

He seemed to think it's intentional.

I dunno. 

But exact() seems to work for me.

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#909999: ghostscript (via pdf2ps) crashes on most inputs following upgrade to 9.06~dfsg-2+deb8u9

[Milko Krachounov]

I can confirm this issue. Downgrading back to

ghostscript_9.06~dfsg-2+deb8u8_amd64.deb
ghostscript-x_9.06~dfsg-2+deb8u8_amd64.deb
libgs9_9.06~dfsg-2+deb8u8_amd64.deb
libgs9-common_9.06~dfsg-2+deb8u8_all.deb

fixes the issue for me.

Trying to convert a XeLaTeX-produced document leads to this error:

$ pdf2ps article.pdf
Error: /rangecheck in .installpagedevice
Operand stack:
   --nostringval--   --dict:174/176(ro)(L)--   --nostringval--  
--nostringval--   false
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--  
--nostringval--   2   %stopped_push   --nostringval--  
--nostringval--   --nostringval--   false   1   %stopped_push   1910  
1   3   %oparray_pop   1909   1   3   %oparray_pop   1893   1   3  
%oparray_pop   --nostringval--   1839   1   4   %oparray_pop  
--nostringval--   1823   1   4   %oparray_pop   --nostringval--  
--nostringval--
Dictionary stack:
   --dict:939/1684(ro)(G)--   --dict:1/20(G)--   --dict:77/200(L)--  
--dict:77/200(L)--
Current allocation mode is local
GPL Ghostscript 9.06: Unrecoverable error, exit code 1

Bug#907996: capistrano: FTBFS randomly (failing tests)

[Samuel Henrique]

Hello Santiago,

I've managed to reproduce this, I will have a look ASAP, soory for taking
so long to reply, I somehow didn't see this bugreport.

Regards,

-- 
Samuel Henrique 

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Trek]

On Mon, 1 Oct 2018 01:11:30 +0200
Michael Biebl  wrote:

> The only supported way in udev to signal readiness is the sd-notify
> API. My gut feeling is, that having an sd-notify wrapper for
> non-systemd systems (e.g. directly built into start-stop-daemon via
> say an --wait-for-sd-notify switch) would be the cleanest and most
> robust way. This might even benefit other daemons besides udevd.

nice catch, but probably it cannot be done in time for buster freeze

after another code inspection, I wrote a simpler version of the patch,
as it only checks for the existence of the control file

it should be sufficient as udev --daemon forks and exits just after
calling listen_fds(), that creates the control file via bind()

to Bill Brelsford: please, can you try again if this new patch fixes the
problem? thank you!

ciao>From e1322be4d6416259a0e3e1e4370e8ff722cda146 Mon Sep 17 00:00:00 2001
From: Trek 
Date: Mon, 1 Oct 2018 06:38:35 +0200
Subject: [PATCH] Wait for udev to be ready before trigger under sysvinit

The start-stop-daemon command with the --background argument returns
immediately, too soon to trigger events on some systems. Update the
SysV init script to wait until udev is ready, checking the control file.

Closes: #908796
---
 debian/udev.init | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/debian/udev.init b/debian/udev.init
index 9c394bb..374df4e 100644
--- a/debian/udev.init
+++ b/debian/udev.init
@@ -170,11 +170,16 @@ case "$1" in
 # prevents udevd to be killed by sendsigs (see #791944)
 mkdir -p $OMITDIR
 ln -sf $PIDFILE $OMITDIR/$NAME
-log_end_msg $?
+
+# wait for udev to be ready (see #908796)
+timeout=150
+until [ -S $CTRLFILE -o $timeout -le 0 ]; do
+timeout=$((timeout - 1))
+sleep 0.1
+done
+[ -S $CTRLFILE ] && log_success_msg || log_failure_msg
 else
-log_warning_msg $?
-log_warning_msg "Waiting 15 seconds and trying to continue anyway"
-sleep 15
+log_failure_msg
 fi
 
 log_action_begin_msg "Synthesizing the initial hotplug events"
-- 
2.1.4

Bug#906730: calendar-exchange-provider: New Extension for TB >= 60

[Mechtilde Stehmann]

Package: calendar-exchange-provider
Version: 4.0.0~beta5+20180823.git218f6f4-1
Followup-For: Bug #906730

Hello

waiting that the package tbsync in the New Queue will be approved

For testing I upload it to people.debian.org

Here the entry for the source.List

http://people.debian.org/~mechtilde/TbSync ./

Kind regards

-- 
Mechtilde Stehmann
## Debian Developer
## Loook, calender-exchange-provider, libreoffice-canzeley-client
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#910001: gnuradio-companion requires python-gtk2 but it is not depended on

[russm]

Package: gnuradio
Version: 3.7.13.4-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Without python-gtk2 installed, gnuradio-companion fails to launch:

user@debian:~$ gnuradio-companion 
ImportError

Failed to initialize GTK. If you are running over ssh, did you enable X 
forwarding and start ssh with -X?

(No module named gtk)
user@debian:~$ 


installing python-gtk2 allows gnuradio-companion to run.


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

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

Versions of packages gnuradio depends on:
ii  libasound21.1.6-1
ii  libboost-atomic1.62.0 1.62.0+dfsg-10
ii  libboost-chrono1.62.0 1.62.0+dfsg-10
ii  libboost-date-time1.62.0  1.62.0+dfsg-10
ii  libboost-filesystem1.62.0 1.62.0+dfsg-10
ii  libboost-program-options1.62.01.62.0+dfsg-10
ii  libboost-regex1.62.0  1.62.0+dfsg-10
ii  libboost-system1.62.0 1.62.0+dfsg-10
ii  libboost-thread1.62.0 1.62.0+dfsg-10
ii  libc6 2.27-6
ii  libcodec2-0.8.1   0.8.1-1
ii  libcomedi00.10.2-4+b6
ii  libfftw3-single3  3.3.8-2
ii  libgcc1   1:8.2.0-7
ii  libgnuradio-analog3.7.13  3.7.13.4-1
ii  libgnuradio-atsc3.7.133.7.13.4-1
ii  libgnuradio-audio3.7.13   3.7.13.4-1
ii  libgnuradio-blocks3.7.13  3.7.13.4-1
ii  libgnuradio-channels3.7.133.7.13.4-1
ii  libgnuradio-comedi3.7.13  3.7.13.4-1
ii  libgnuradio-digital3.7.13 3.7.13.4-1
ii  libgnuradio-dtv3.7.13 3.7.13.4-1
ii  libgnuradio-fcd3.7.13 3.7.13.4-1
ii  libgnuradio-fec3.7.13 3.7.13.4-1
ii  libgnuradio-fft3.7.13 3.7.13.4-1
ii  libgnuradio-filter3.7.13  3.7.13.4-1
ii  libgnuradio-noaa3.7.133.7.13.4-1
ii  libgnuradio-pager3.7.13   3.7.13.4-1
ii  libgnuradio-pmt3.7.13 3.7.13.4-1
ii  libgnuradio-qtgui3.7.13   3.7.13.4-1
ii  libgnuradio-runtime3.7.13 3.7.13.4-1
ii  libgnuradio-trellis3.7.13 3.7.13.4-1
ii  libgnuradio-uhd3.7.13 3.7.13.4-1
ii  libgnuradio-video-sdl3.7.13   3.7.13.4-1
ii  libgnuradio-vocoder3.7.13 3.7.13.4-1
ii  libgnuradio-wavelet3.7.13 3.7.13.4-1
ii  libgnuradio-wxgui3.7.13   3.7.13.4-1
ii  libgnuradio-zeromq3.7.13  3.7.13.4-1
ii  libgsl23  2.5+dfsg-5
ii  libgslcblas0  2.5+dfsg-5
ii  libgsm1   1.0.13-4+b2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  liblog4cpp5v5 1.1.3-1
ii  libportaudio2 19.6.0-1
ii  libpython2.7  2.7.15-4
ii  libqt5core5a  5.11.1+dfsg-9
ii  libqt5gui55.11.1+dfsg-9
ii  libqt5widgets55.11.1+dfsg-9
ii  libqwt-qt5-6  6.1.3-1
ii  libsdl1.2debian   1.2.15+dfsg2-2
ii  libstdc++68.2.0-7
ii  libuhd3.12.0  3.12.0.0-3
ii  libusb-1.0-0  2:1.0.22-2
ii  libvolk1-bin  1.4-3
ii  libvolk1.41.4-3
ii  libzmq5   4.2.5-2
ii  python2.7.15-3
ii  python-cheetah3.1.0-2+b1
ii  python-gobject-2  2.28.6-13+b1
ii  python-lxml   4.2.5-1
ii  python-numpy  1:1.14.5-1+b1
ii  python-opengl 3.1.0+dfsg-2
ii  python-pyqt5  5.11.2+dfsg-1+b1
ii  python-sip4.19.12+dfsg-1
ii  python-wxgtk3.0   3.0.2.0+dfsg-8
ii  python-zmq17.1.0-1

Versions of packages gnuradio recommends:
ii  gnuradio-dev   3.7.13.4-1
ii  python-matplotlib  2.2.2-4+b1
ii  python-networkx2.1-1
pn  python-qwt-qt5 
ii  python-scipy   1.1.0-1+b1
ii  python-tk  2.7.15-1
ii  rtl-sdr0.5.4-1
ii  uhd-host   3.12.0.0-3

Versions of packages gnuradio suggests:
ii  gr-fosphor  3.7.0.2.7b6b996-3+b1
pn  gr-osmosdr  

-- no debconf information

Bug#887747: ITP: gnome-shell-extension-easyscreencast -- video recording extension for the GNOME shell

[Samuel Henrique]

Hello everyone,

I see that the last email here is from January 21th, so I decided to myself
package gnome-shell-extension-easyscreencast,

It is almost ready at salsa[0], it just need a final review of d/copyright
to check if there were new copyright holders added on the new release. I
did not committed under gnome's team organization, but I can do so if asked
(I didn't because I don't know if this is what the team wants).

Please let me know if you've made any progress on your package, if you want
to do any changes on top of mine or if you want to co-maintain it.

If there's no opinions against, I will do the upload soon.

Thanks,

[0]https://salsa.debian.org/debian/gnome-shell-extension-easyscreencast

-- 
Samuel Henrique 

Bug#910000: RFA: xtables-addons -- additional modules for iptables

[Dmitry Smirnov]

Package: wnpp
Severity: normal

xtables-addons deserves more attention than I could offer lately...

Maintaining this package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see [1] for detailed 
instructions how to adopt a package properly.

[1]: https://www.debian.org/devel/wnpp/index.html#howto-o

-- 
Regards,
 Dmitry Smirnov.


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

Bug#606287: d-i manual: should add a "what is the Debian Installer" section

[Holger Wansing]

Control: tags -1 + pending

Brian Potkin  wrote:
> On Sun 30 Sep 2018 at 23:28:25 +0200, Holger Wansing wrote:
> > > > 
> > > > The installer goes back to the boot-floppies project, and it was
> > > 
> > >  ^
> > >"has its origin in" is an alternative. Nit picking
> > 
> > Unsure, which one is better...
> 
> So am I. "goes back to" implies that the start of d-i was about the
> same time when the boot-floppies project existed. "has its origin in"
> makes a more causal link in that it says that d-i was developed from
> the boot-floppies project.

Ok, changed. Thanks

Tagging this bug as pending


Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#909998: RFS: groonga/8.0.7-1

[Kentaro Hayashi]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: groonga
  Version : 8.0.7-1
  Upstream Author : Groonga Project 
* Url : http://groonga.org/
* Licenses: LGPL-2.1
  Section : database

It builds those binary packages:

  * groonga
  * groonga-server-common
  * groonga-server-gqtp
  * libgroonga-dev
  * libgroonga0
  * groonga-tokenizer-mecab
  * groonga-token-filter-stem
  * groonga-plugin-suggest
  * groonga-bin
  * groonga-httpd
  * groonga-doc
  * groonga-examples
  * groonga-munin-plugins

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

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

Alternatively, one can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/g/groonga/groonga_8.0.7-1.dsc

More information about groonga can be obtained from
http://groonga.org/

Changes since last upload:

  * New upstream version 8.0.7.
  * debian/patches/fix-nginx-FTBFS-on-kfreebsd.patch
- Refresh patch to fix FTBFS on kFreeBSD.

Regards,


pgpxLX61ZpkUT.pgp
Description: PGP signature

Bug#909997: kimwitu-doc: FTBFS (Error: Closing Ghostscript)

[Santiago Vila]

Package: src:kimwitu-doc
Version: 10a+1-2.2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]

hare/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmssi9.pfb>
Output written on tp.man.pdf (53 pages, 540974 bytes).
Transcript written on tp.man.log.
thumbpdf tp.man
THUMBPDF 3.16, 2014/07/15 - Copyright (c) 1999-2014 by Heiko Oberdiek.
*** make png files / run Ghostscript ***
!!! Warning: MediaBox not found, using default resolution: 9 DPI
GPL Ghostscript 9.25: Unrecoverable error, exit code 1
*** clear temp files ***
!!! Error: Closing Ghostscript (exit status: 1)!
make[1]: *** [Makefile:126: tp.man.pdf] Error 1
make[1]: Leaving directory '/<>/kimwitu-doc-10a+1'
make: *** [debian/rules:7: build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2


This is how it fails in my autobuilder with dpkg-buildpackage -A but it also 
fails here:

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

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Michael Biebl]

Am 01.10.18 um 00:55 schrieb Trek:
> On Sat, 29 Sep 2018 18:41:45 +0200
> Michael Biebl  wrote:
> 
>>> +# wait for udev to be ready (see #908796)
>>> +timeout=15
>>> +until udevadm control -S || [ $timeout -le 0 ]; do
>>> +timeout=$((timeout-1))
>>> +sleep 1
>>> +done
>>> +udevadm control -S && log_success_msg || log_failure_msg
>>
>> This repeatedly tries to start the execution queue.
>> Besides having this side-effect, why is this a proper test to check if
>> udev is ready?
> 
> this probably shows my ignorance about udev (and lack of documentation),
> but it seems to me there isn't a proper way to test if udev is ready

The only supported way in udev to signal readiness is the sd-notify API.
My gut feeling is, that having an sd-notify wrapper for non-systemd
systems (e.g. directly built into start-stop-daemon via say an
--wait-for-sd-notify switch) would be the cleanest and most robust way.
This might even benefit other daemons besides udevd.

Similar to what apulse is for PulseAudio clients without a PulseAudio
daemon.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#909996: vdirsyncer: FTBFS (TypeError: 'NoneType' object is not iterable)

[Santiago Vila]

Package: src:vdirsyncer
Version: 0.16.2-4
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python3,sphinxdoc --buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python3.7 setup.py config 
running config
/usr/lib/python3/dist-packages/setuptools_scm/version.py:191: UserWarning: meta 
invoked without explicit configuration, will use defaults where required.
  "meta invoked without explicit configuration,"
I: pybuild base:217: python3.6 setup.py config 
running config
/usr/lib/python3/dist-packages/setuptools_scm/version.py:191: UserWarning: meta 
invoked without explicit configuration, will use defaults where required.
  "meta invoked without explicit configuration,"
   debian/rules override_dh_auto_build

[... snipped ...]

tests/storage/test_singlefile.py ... [ 49%]
.ss.ss   [ 53%]
tests/storage/dav/test_caldav.py sss [ 62%]
sss  [ 65%]
tests/storage/dav/test_carddav.py ss [ 71%]
tests/storage/dav/test_main.py . [ 71%]
tests/system/cli/test_config.py .[ 73%]
tests/system/cli/test_discover.py .  [ 74%]
tests/system/cli/test_fetchparams.py ..  [ 76%]
tests/system/cli/test_repair.py .[ 77%]
tests/system/cli/test_sync.py .  [ 81%]
tests/system/cli/test_utils.py ..[ 82%]
tests/system/utils/test_main.py .sssF[ 83%]
tests/unit/test_exceptions.py .  [ 83%]
tests/unit/test_metasync.py .[ 85%]
tests/unit/test_repair.py .. [ 87%]
tests/unit/test_sync.py ...  [ 94%]
tests/unit/cli/test_config.py .  [ 94%]
tests/unit/cli/test_discover.py ..   [ 96%]
tests/unit/utils/test_vobject.py ..  [100%]

=== FAILURES ===
__ TestFilesystemStorage.test_metadata_normalization ___
tests/storage/__init__.py:301: in test_metadata_normalization
st.none(),
E   hypothesis.errors.FailedHealthCheck: It looks like your strategy is 
filtering out a lot of data. Health check found 50 filtered examples but only 3 
good ones. This will make your tests much slower, and also will probably 
distort the data generation quite a lot. You should adapt your strategy to 
filter less. This can also be caused by a low max_leaves parameter in 
recursive() calls
E   See https://hypothesis.readthedocs.io/en/latest/healthchecks.html for more 
information about this. If you want to disable just this health check, add 
HealthCheck.filter_too_much to the suppress_health_check settings for this test.
-- Hypothesis --
You can add @seed(296577508032444947572819497154329054860) to this test or run 
pytest with --hypothesis-seed=296577508032444947572819497154329054860 to 
reproduce this failure.
 TestMemoryStorage.test_metadata_normalization _
tests/storage/__init__.py:301: in test_metadata_normalization
st.none(),
E   hypothesis.errors.FailedHealthCheck: It looks like your strategy is 
filtering out a lot of data. Health check found 50 filtered examples but only 5 
good ones. This will make your tests much slower, and also will probably 
distort the data generation quite a lot. You should adapt your strategy to 
filter less. This can also be caused by a low max_leaves parameter in 
recursive() calls
E   See https://hypothesis.readthedocs.io/en/latest/healthchecks.html for more 
information about this. If you want to disable just this health check, add 
HealthCheck.filter_too_much to the suppress_health_check settings for this test.
-- Hypothesis --
You can add @seed(135387776198974078022358545371536932831) to this test or run 
pytest with --hypothesis-seed=135387776198974078022358545371536932831 to 
reproduce this failure.
_ test_open_graphical_browser __
tests/system/utils/test_main.py:71: in test_open_graphical_browser

Bug#909994: python-pgpy: FTBFS (No module named '_gpgme')

[Santiago Vila]

Package: src:python-pgpy
Version: 0.4.3-3
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python3 --buildsystem pybuild
   dh_testdir -i -O--buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python3.7 setup.py config 
running config
I: pybuild base:217: python3.6 setup.py config 
running config
   debian/rules override_dh_auto_build-indep
make[1]: Entering directory '/<>'
dh_auto_build -O=--buildsystem=pybuild
I: pybuild base:217: /usr/bin/python3.7 setup.py build 

[... snipped ...]


During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 403, 
in _importconftest
return self._conftestpath2mod[conftestpath]
KeyError: 
local('/<>/.pybuild/cpython3_3.7_pgpy/build/tests/conftest.py')

During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gpg/gpgme.py", line 14, in 
swig_import_helper
return importlib.import_module(mname)
  File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1006, in _gcd_import
  File "", line 983, in _find_and_load
  File "", line 965, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'gpg._gpgme'

During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 409, 
in _importconftest
mod = conftestpath.pyimport()
  File "/usr/lib/python3/dist-packages/py/_path/local.py", line 668, in pyimport
__import__(modname)
  File "/usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py", line 226, 
in load_module
py.builtin.exec_(co, mod.__dict__)
  File "/<>/.pybuild/cpython3_3.7_pgpy/build/tests/conftest.py", 
line 5, in 
import gpg
  File "/usr/lib/python3/dist-packages/gpg/__init__.py", line 101, in 
from . import core
  File "/usr/lib/python3/dist-packages/gpg/core.py", line 34, in 
from . import gpgme
  File "/usr/lib/python3/dist-packages/gpg/gpgme.py", line 17, in 
_gpgme = swig_import_helper()
  File "/usr/lib/python3/dist-packages/gpg/gpgme.py", line 16, in 
swig_import_helper
return importlib.import_module('_gpgme')
  File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
ModuleNotFoundError: No module named '_gpgme'
ERROR: could not load 
/<>/.pybuild/cpython3_3.7_pgpy/build/tests/conftest.py

E: pybuild pybuild:338: test: plugin distutils failed with: exit code=4: cd 
/<>/.pybuild/cpython3_3.7_pgpy/build; python3.7 -m pytest tests
dh_auto_test: pybuild --test --test-pytest -i python{version} -p "3.7 3.6" 
returned exit code 13
make[1]: *** [debian/rules:25: override_dh_auto_test] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:6: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
but it also fails here:

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

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#909992: python-distutils-extra: FTBFS (AssertionError: 0 != 3)

[Santiago Vila]

Package: src:python-distutils-extra
Version: 2.41
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,python3 --buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python2.7 setup.py config 
running config
I: pybuild base:217: python3.7 setup.py config 
running config
I: pybuild base:217: python3.6 setup.py config 
running config
   dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:217: /usr/bin/python setup.py build 
running build

[... snipped ...]

Python packages ... ok
test_po (__main__.T)
gettext *.po files ... ok
test_policykit (__main__.T)
*.policy.in PolicyKit files ... ok
test_pot_auto (__main__.T)
PO template creation with automatic POTFILES.in ... ok
test_pot_auto_explicit (__main__.T)
PO template creation with automatic POTFILES.in and explicit scripts ... ok
test_pot_manual (__main__.T)
PO template creation with manual POTFILES.in ... ok
test_requires_provides (__main__.T)
automatic requires/provides ... 
/usr/lib/python3/dist-packages/pkg_resources/_vendor/pyparsing.py:943: 
DeprecationWarning: Using or importing the ABCs from 'collections' instead of 
from 'collections.abc' is deprecated, and in 3.8 it will stop working
  collections.MutableMapping.register(ParseResults)
/usr/lib/python3/dist-packages/pkg_resources/_vendor/pyparsing.py:3245: 
DeprecationWarning: Using or importing the ABCs from 'collections' instead of 
from 'collections.abc' is deprecated, and in 3.8 it will stop working
  elif isinstance( exprs, collections.Iterable ):
ok
test_scripts (__main__.T)
scripts ... ok
test_sdist (__main__.T)
default MANIFEST ... ok
test_standard_files (__main__.T)
Standard files (MANIFEST.in, COPYING, etc.) ... ok
test_ui (__main__.T)
GtkBuilder/Qt *.ui ... ok
test_utf8_filenames (__main__.T)
UTF-8 file names ... ok
test_vcs (__main__.T)
Ignores revision control files ... ok

==
FAIL: test_apport_hook (__main__.T)
Apport hooks
--
Traceback (most recent call last):
  File "test/auto.py", line 198, in test_apport_hook
self.assertEqual(len(f), 3, f) # 2 hook files plus .egg-info
AssertionError: 0 != 3 : []

--
Ran 26 tests in 6.143s

FAILED (failures=1)
make[1]: *** [debian/rules:9: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:4: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
but it also fails here:

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

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#909995: sdcc: FTBFS (LaTeX Error: File `MCS51_named' not found)

[Santiago Vila]

Package: src:sdcc
Version: 3.7.0+dfsg2-0.1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh_testdir
mkdir -p /<>/sdcc-3.7.0+dfsg2/build
touch sim/ucsim/config.guess sim/ucsim/config.sub
dh_autotools-dev_updateconfig
dh_autotools-dev_updateconfig: dh_autotools-dev_updateconfig is deprecated; 
please see dh_autotools-dev_updateconfig(1) for a replacement
dh_autotools-dev_updateconfig: This feature will be removed in compat 12.
for c_g in `find -type f -name config.guess` ; do if ! test -e 
"$c_g.dh-orig" ; then mv -f "$c_g" "$c_g.dh-orig" ; cp -f 
/usr/share/misc/config.guess "$c_g" ; fi ; done
for c_s in `find -type f -name config.sub`   ; do if ! test -e 
"$c_s.dh-orig" ; then mv -f "$c_s" "$c_s.dh-orig" ; cp -f 
/usr/share/misc/config.sub   "$c_s" ; fi ; done
CFLAGS="-g -O2 -fdebug-prefix-map=/<>/sdcc-3.7.0+dfsg2=. 
-fstack-protector-strong -Wformat -Werror=format-security" 
CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" CXXFLAGS="-g -O2 
-fdebug-prefix-map=/<>/sdcc-3.7.0+dfsg2=. -fstack-protector-strong 
-Wformat -Werror=format-security" LDFLAGS="-Wl,-z,relro" \
./configure \
--host=x86_64-linux-gnu \
--build=x86_64-linux-gnu \
--disable-non-free \

[... snipped ...]



LaTeX Warning: Reference `subsec:External-Stack' on page 35 undefined on input 
line 2114.

[35] [36]

LaTeX Warning: Reference `subsec:The-anatomy-of' on page 37 undefined on input 
line 2229.


Underfull \hbox (badness 1) in paragraph at lines 2247--2256


LaTeX Warning: Reference `subsec:Install-paths' on page 37 undefined on input l
ine 2272.


LaTeX Warning: Reference `subsec:Search-Paths' on page 37 undefined on input li
ne 2274.


LaTeX Warning: Reference `subsec:Search-Paths' on page 37 undefined on input li
ne 2276.

[37]

! LaTeX Error: File `MCS51_named' not found.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
 ...  
  
l.2298 \includegraphics{MCS51_named}

? 
! Emergency stop.
 ...  
  
l.2298 \includegraphics{MCS51_named}

Output written on sdccman.dvi (37 pages, 181596 bytes).
Transcript written on sdccman.log.
make[1]: *** [Makefile:67: sdccman.dvi] Error 1
make[1]: Leaving directory '/<>/sdcc-3.7.0+dfsg2/doc'
make: *** [debian/rules:71: build-indep-stamp] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
but it also fails here:

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

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#909985: ceilometer: FTBFS (Failed to import test module)

[Santiago Vila]

Package: src:ceilometer
Version: 1:11.0.0-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
dh build-indep  --with python3,systemd,sphinxdoc
   dh_update_autotools_config -i
   dh_autoreconf -i
   dh_auto_configure -i
dh_auto_configure: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_configure: This feature will be removed in compat 12.
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions

[... snipped ...]

+ TEST_PARALLEL_OPT=--parallel
+ PKGOS_USE_PY2=no
+ shift
+ [ no = yes ]
+ [ yes = yes ]
+ py3versions -vr
+ PYTHON3S=3.6
+ [ yes = no ]
+ [ disabled = disabled ]
+ continue
+ [ 3.6 = disabled ]
+ cut -d. -f1
+ echo 3.6
+ PYMAJOR=3
+ echo ===> Testing with python (python3)
===> Testing with python (python3)
+ [ 3 = 3 ]
+ pwd
+ [ -d /<>/debian/tmp/usr/lib/python3/dist-packages ]
+ [ -z /<>/debian/tmp/usr/lib/python3/dist-packages ]
+ [ -e .stestr.conf ]
+ rm -rf .stestr
+ subunit2pyunit
+ PYTHON=python3.6 python3-stestr run --subunit 
tests\.(?!(.*test_bin.*|.*functional.*|.*gabbi\.test_gabbi_prefix.*|.*meter\.test_notifications\.TestMeterProcessing\.test_fallback_meter_path.*|.*agent\.test_manager\.TestRunTasks\.test_batching_polled_samples_false.*))

=
Failures during discovery
=
b'--- import errors ---\nFailed to import test module: 
ceilometer.tests.unit.hardware.inspector.test_snmp\nTraceback (most recent call 
last):\n  File "/usr/lib/python3/dist-packages/unittest2/loader.py", line 456, 
in _find_test_path\nmodule = self._get_module_from_name(name)\n  File 
"/usr/lib/python3/dist-packages/unittest2/loader.py", line 395, in 
_get_module_from_name\n__import__(name)\n  File 
"/<>/ceilometer/tests/unit/hardware/inspector/test_snmp.py", line 
23, in \nfrom ceilometer.hardware.inspector import snmp\n  File 
"/<>/ceilometer/hardware/inspector/snmp.py", line 21, in 
\nfrom pysnmp.entity.rfc3413.oneliner import 
cmdgen\nModuleNotFoundError: No module named 
\'pysnmp.entity.rfc3413.oneliner\'\n'

The above traceback was encountered during test discovery which imports all the 
found test modules in the specified test_path.

--
Ran 0 tests in 1.567s

OK
+ python3-stestr slowest
+ clean_exit /tmp/CEILO-MONGODB-drAOR
+ local error_code=3
+ rm -rf /tmp/CEILO-MONGODB-drAOR
++ jobs -p
+ kill 11332 11374
+ return 3
make[1]: *** [debian/rules:32: override_dh_install] Error 3
make[1]: Leaving directory '/<>'
make: *** [debian/rules:7: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
but it also fails here:

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

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#909990: nibabel: FTBFS (Failed example)

[Santiago Vila]

Package: src:nibabel
Version: 2.3.0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=python_distutils --builddirectory=build 
--with=python2,python3
   dh_update_autotools_config -i -O--buildsystem=python_distutils 
-O--builddirectory=build
   dh_auto_configure -i -O--buildsystem=python_distutils 
-O--builddirectory=build
dh_auto_configure: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_configure: This feature will be removed in compat 12.
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build
dh_auto_build: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_build: This feature will be removed in compat 12.
python setup.py build --force
Missing optional package "dicom" provided by package "pydicom"; you may get 
run-time errors
running build

[... snipped ...]

  dslice = dslice.astype(out_dtype)
./<>/nibabel/volumeutils.py:818: ComplexWarning: Casting complex 
values to real discards the imaginary part
  dslice = dslice.astype(in_cast)

==
FAIL: Doctest: nibabel.deprecated.FutureWarningMixin
--
Traceback (most recent call last):
  File "/usr/lib/python3.7/doctest.py", line 2198, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for nibabel.deprecated.FutureWarningMixin
  File "/<>/nibabel/deprecated.py", line 42, in FutureWarningMixin

--
File "/<>/nibabel/deprecated.py", line 53, in 
nibabel.deprecated.FutureWarningMixin
Failed example:
with warnings.catch_warnings(record=True) as warns:
d = D()
warns[0].message
Expected:
FutureWarning("Please, don't use this class",)
Got:
FutureWarning("Please, don't use this class")


==
FAIL: nibabel.tests.test_testing.test_clear_and_catch_warnings
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File "/<>/nibabel/tests/test_testing.py", line 89, in 
test_clear_and_catch_warnings
assert_warn_len_equal(my_mod, 1)
  File "/<>/nibabel/tests/test_testing.py", line 72, in 
assert_warn_len_equal
assert_equal(len(mod_warns), 2)  # including 'version'
AssertionError: 1 != 2

--
Ran 7721 tests in 68.265s

FAILED (SKIP=55, failures=2)
make[2]: *** [Makefile:94: unittest] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:43: python-test3.7] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:18: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
but it also fails here:

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

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#885654: gwaei: Please drop Build-Depends on rarian-compat

[Norbert Preining]

> Your latest gwaei upload fails to buid from source. I'm attaching a
> patch to fix this issue.

Bummer, not committed change it was. Sorry. Redoing it now with VCS
updates, too.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#909993: python-google-auth: FTBFS (AssertionError: Pattern 'Incorrect padding' not found)

[Santiago Vila]

Package: src:python-google-auth
Version: 1.3.0-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
dh build-indep --buildsystem=python_distutils --with python2,python3
   dh_update_autotools_config -i -O--buildsystem=python_distutils
   dh_autoreconf -i -O--buildsystem=python_distutils
   dh_auto_configure -i -O--buildsystem=python_distutils
dh_auto_configure: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_configure: This feature will be removed in compat 12.
   dh_auto_build -i -O--buildsystem=python_distutils
dh_auto_build: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_build: This feature will be removed in compat 12.
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions

[... snipped ...]

tests/transport/test_requests.py ..  [ 94%]
tests/transport/test_urllib3.py .[100%]

 243 passed, 4 skipped in 21.73 seconds 
= test session starts ==
platform linux -- Python 3.7.0, pytest-3.6.4, py-1.6.0, pluggy-0.6.0
rootdir: /<>, inifile:
plugins: localserver-0.3.7
collected 247 items

tests/test__cloud_sdk.py [  4%]
tests/test__default.py ..[ 15%]
tests/test__helpers.py ..[ 22%]
tests/test__oauth2client.py .[ 26%]
tests/test__service_account_info.py  [ 27%]
tests/test_app_engine.py .   [ 33%]
tests/test_credentials.py    [ 38%]
tests/test_iam.py    [ 39%]
tests/test_jwt.py ..F.   [ 57%]
tests/compute_engine/test__metadata.py   [ 62%]
tests/compute_engine/test_credentials.py [ 63%]
tests/crypt/test__python_rsa.py ..   [ 71%]
tests/crypt/test_crypt.py .. [ 72%]
tests/oauth2/test__client.py ..  [ 76%]
tests/oauth2/test_credentials.py [ 77%]
tests/oauth2/test_id_token.py .. [ 80%]
tests/oauth2/test_service_account.py ... [ 86%]
tests/transport/test__http_client.py ... [ 89%]
tests/transport/test_grpc.py [ 90%]
tests/transport/test_requests.py ..  [ 94%]
tests/transport/test_urllib3.py .[100%]

=== FAILURES ===
___ test_decode_bad_token_not_base64 ___

def test_decode_bad_token_not_base64():
with pytest.raises((ValueError, TypeError)) as excinfo:
jwt.decode('1.2.3', PUBLIC_CERT_BYTES)
>   assert excinfo.match(r'Incorrect padding')
E   AssertionError: Pattern 'Incorrect padding' not found in 'Invalid 
base64-encoded string: length cannot be 1 more than a multiple of 4'

tests/test_jwt.py:121: AssertionError
=== 1 failed, 242 passed, 4 skipped in 21.91 seconds ===
make[1]: *** [debian/rules:14: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:7: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
but it also fails here:

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

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#909991: python-ceilometermiddleware: FTBFS (RuntimeError: generator raised StopIteration)

[Santiago Vila]

Package: src:python-ceilometermiddleware
Version: 1.2.0-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
dh build-indep --buildsystem=python_distutils --with python2,python3,sphinxdoc
   dh_update_autotools_config -i -O--buildsystem=python_distutils
   dh_autoreconf -i -O--buildsystem=python_distutils
   dh_auto_configure -i -O--buildsystem=python_distutils
dh_auto_configure: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_configure: This feature will be removed in compat 12.
   dh_auto_build -i -O--buildsystem=python_distutils
dh_auto_build: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_build: This feature will be removed in compat 12.
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions

[... snipped ...]


==
FAIL: ceilometermiddleware.tests.test_swift.TestSwift.test_put_with_swift_source
ceilometermiddleware.tests.test_swift.TestSwift.test_put_with_swift_source
--
_StringException: Traceback (most recent call last):
  File "/<>/ceilometermiddleware/swift.py", line 270, in 
iter_response
chunk = next(iterator)
StopIteration

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/mock/mock.py", line 1305, in patched
return func(*args, **keywargs)
  File "/<>/ceilometermiddleware/tests/test_swift.py", line 432, 
in test_put_with_swift_source
list(app(req.environ, self.start_response))
RuntimeError: generator raised StopIteration


==
FAIL: ceilometermiddleware.tests.test_swift.TestSwift.test_reseller_prefix
ceilometermiddleware.tests.test_swift.TestSwift.test_reseller_prefix
--
_StringException: Traceback (most recent call last):
  File "/<>/ceilometermiddleware/swift.py", line 270, in 
iter_response
chunk = next(iterator)
StopIteration

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/mock/mock.py", line 1305, in patched
return func(*args, **keywargs)
  File "/<>/ceilometermiddleware/tests/test_swift.py", line 331, 
in test_reseller_prefix
list(app(req.environ, self.start_response))
RuntimeError: generator raised StopIteration


--
Ran 25 tests in 0.983s

FAILED (failures=18)
make[1]: *** [debian/rules:14: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:7: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
but it also fails here:

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

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#909986: cloudpickle: FTBFS (TypeError: can't pickle _abc_data objects)

[Santiago Vila]

Package: src:cloudpickle
Version: 0.5.2-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,python3 --buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python2.7 setup.py config 
running config
I: pybuild base:217: python3.7 setup.py config 
running config
I: pybuild base:217: python3.6 setup.py config 
running config
   dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:217: /usr/bin/python setup.py build 
running build

[... snipped ...]

self.framer.commit_frame()

# Check for persistent id (defined by a subclass)
pid = self.persistent_id(obj)
if pid is not None and save_persistent_id:
self.save_pers(pid)
return

# Check the memo
x = self.memo.get(id(obj))
if x is not None:
self.write(self.get(x[0]))
return

# Check the type dispatch table
t = type(obj)
f = self.dispatch.get(t)
if f is not None:
f(self, obj) # Call unbound method with explicit self
return

# Check private dispatch table if any, or else copyreg.dispatch_table
reduce = getattr(self, 'dispatch_table', dispatch_table).get(t)
if reduce is not None:
rv = reduce(obj)
else:
# Check for a class with a custom metaclass; treat as regular class
try:
issc = issubclass(t, type)
except TypeError: # t is not a class (old Boost; see SF #502085)
issc = False
if issc:
self.save_global(obj)
return

# Check for a __reduce_ex__ method, fall back to __reduce__
reduce = getattr(obj, "__reduce_ex__", None)
if reduce is not None:
>   rv = reduce(self.proto)
E   TypeError: can't pickle _abc_data objects

/usr/lib/python3.7/pickle.py:524: TypeError
=== 2 failed, 101 passed, 7 skipped in 12.76 seconds ===
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.7_cloudpickle/build; python3.7 -m pytest -s
dh_auto_test: pybuild --test -i python{version} -p "3.7 3.6" returned exit code 
13
make: *** [debian/rules:8: build-indep] Error 25
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
but it also fails here:

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

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#909987: distro-info: FTBFS (RuntimeError: generator raised StopIteration)

[Santiago Vila]

Package: src:distro-info
Version: 0.18
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,python3
   dh_update_autotools_config -i
   dh_autoreconf -i
   dh_auto_configure -i
   dh_auto_build -i
make -j1 "INSTALL=install --strip-program=true"
make[1]: Entering directory '/<>'
cc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -Wextra -g -O2 
-std=gnu99 -Wl,-z,relro -Wl,-z,now -o debian-distro-info debian-distro-info.c
cc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -Wextra -g -O2 
-std=gnu99 -Wl,-z,relro -Wl,-z,now -o ubuntu-distro-info ubuntu-distro-info.c
make[1]: Leaving directory '/<>'
   dh_auto_test -i
make -j1 test
make[1]: Entering directory '/<>'

[... snipped ...]

cb(astroid)
  File "/usr/lib/python3/dist-packages/pylint/checkers/variables.py", line 
1245, in visit_import
module = next(node.infer_name_module(parts[0]))
  File "/usr/lib/python3/dist-packages/astroid/context.py", line 71, in 
cache_generator
for result in generator:
  File "/usr/lib/python3/dist-packages/astroid/decorators.py", line 89, in 
wrapped
res = next(generator)
  File "/usr/lib/python3/dist-packages/astroid/inference.py", line 194, in 
infer_import
yield self.do_import_module(name)
  File "/usr/lib/python3/dist-packages/astroid/mixins.py", line 119, in 
do_import_module
relative_only=level and level >= 1)
  File "/usr/lib/python3/dist-packages/astroid/scoped_nodes.py", line 593, in 
import_module
return MANAGER.ast_from_module_name(absmodname)
  File "/usr/lib/python3/dist-packages/astroid/manager.py", line 154, in 
ast_from_module_name
return self.ast_from_file(found_spec.location, modname, fallback=False)
  File "/usr/lib/python3/dist-packages/astroid/manager.py", line 80, in 
ast_from_file
return AstroidBuilder(self).file_build(filepath, modname)
  File "/usr/lib/python3/dist-packages/astroid/builder.py", line 153, in 
file_build
return self._post_build(module, encoding)
  File "/usr/lib/python3/dist-packages/astroid/builder.py", line 173, in 
_post_build
self.delayed_assattr(delayed)
  File "/usr/lib/python3/dist-packages/astroid/builder.py", line 232, in 
delayed_assattr
for inferred in node.expr.infer():
  File "/usr/lib/python3/dist-packages/astroid/decorators.py", line 89, in 
wrapped
res = next(generator)
  File "/usr/lib/python3/dist-packages/astroid/bases.py", line 95, in 
_infer_stmts
for inferred in stmt.infer(context=context):
  File "/usr/lib/python3/dist-packages/astroid/context.py", line 71, in 
cache_generator
for result in generator:
RuntimeError: generator raised StopIteration
pylint found issues:
* Module debian-distro-info
F:  1, 0: : generator raised StopIteration (astroid-error)
* Module ubuntu-distro-info
F:  1, 0: : generator raised StopIteration (astroid-error)

--
Ran 26 tests in 0.730s

FAILED (failures=1)
Test failed: 
error: Test failed: 
make[1]: *** [Makefile:45: test-python] Error 1
make[1]: Leaving directory '/<>'
dh_auto_test: make -j1 test returned exit code 2
make: *** [debian/rules:6: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
but it also fails here:

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

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#909988: ironic: FTBFS (Failures during discovery)

[Santiago Vila]

Package: src:ironic
Version: 1:11.1.0-3
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
dh build-indep --buildsystem=python_distutils --with python3,sphinxdoc,systemd
   dh_update_autotools_config -i -O--buildsystem=python_distutils
   dh_autoreconf -i -O--buildsystem=python_distutils
   dh_auto_configure -i -O--buildsystem=python_distutils
dh_auto_configure: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_configure: This feature will be removed in compat 12.
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions

[... snipped ...]

+ PKGOS_USE_PY3=yes
+ PKGOS_TEST_PARALLEL=yes
+ PYTHONS=disabled
+ PYTHON3S=disabled
+ TEST_PARALLEL_OPT=--parallel
+ PKGOS_USE_PY2=no
+ shift
+ [ no = yes ]
+ [ yes = yes ]
+ py3versions -vr
+ PYTHON3S=3.7 3.6
+ [ yes = no ]
+ [ disabled = disabled ]
+ continue
+ [ 3.7 = disabled ]
+ cut -d. -f1
+ echo 3.7
+ PYMAJOR=3
+ echo ===> Testing with python (python3)
===> Testing with python (python3)
+ [ 3 = 3 ]
+ pwd
+ [ -d /<>/debian/tmp/usr/lib/python3/dist-packages ]
+ [ -z  ]
+ pwd
+ export PYTHONPATH=/<>/debian/tmp/usr/lib/python3/dist-packages
+ [ -e .stestr.conf ]
+ rm -rf .stestr
+ subunit2pyunit
+ PYTHON=python3.7 python3-stestr run --subunit 
ironic\.tests\.unit\.(?!(.*api\.controllers\.v1\.test_chassis\.TestPost\.test_create_chassis_unicode_description.*))

=
Failures during discovery
=
b'--- stdout ---\n2018-09-27 16:06:32.223 18596 INFO keyring.backend [-] 
Loading KWallet\x1b[00m\n2018-09-27 16:06:32.239 18596 INFO keyring.backend [-] 
Loading SecretService\x1b[00m\n2018-09-27 16:06:32.245 18596 INFO 
keyring.backend [-] Loading Windows\x1b[00m\n2018-09-27 16:06:32.247 18596 INFO 
keyring.backend [-] Loading macOS\x1b[00m\n--- import errors ---\nFailed to 
import test module: ironic.tests.unit.drivers.modules.irmc.test_bios\nTraceback 
(most recent call last):\n  File 
"/usr/lib/python3/dist-packages/unittest2/loader.py", line 456, in 
_find_test_path\nmodule = self._get_module_from_name(name)\n  File 
"/usr/lib/python3/dist-packages/unittest2/loader.py", line 395, in 
_get_module_from_name\n__import__(name)\n  File 
"/<>/ironic/tests/unit/drivers/modules/irmc/test_bios.py", line 
29, in \nclass IRMCBIOSTestCase(test_common.BaseIRMCTest):\n  File 
"/<>/ironic/tests/unit/drivers/modules/irmc/test_bios.py", line 
41, in IRMCBIOSTestC
 ase\n@mock.patch.object(irmc_bios.irmc.elcm, 
\'set_bios_configuration\',\nAttributeError: \'NoneType\' object has no 
attribute \'elcm\'\n'

The above traceback was encountered during test discovery which imports all the 
found test modules in the specified test_path.

--
Ran 0 tests in 9.345s

OK
+ python3-stestr slowest
make[1]: *** [debian/rules:31: override_dh_install] Error 3
make[1]: Leaving directory '/<>'
make: *** [debian/rules:6: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
but it also fails here:

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

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#909989: keystone: FTBFS (failing tests)

[Santiago Vila]

Package: src:keystone
Version: 2:14.0.0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
dh build-indep --buildsystem=python_distutils --with python3,sphinxdoc,systemd
   dh_update_autotools_config -i -O--buildsystem=python_distutils
   dh_autoreconf -i -O--buildsystem=python_distutils
   dh_auto_configure -i -O--buildsystem=python_distutils
dh_auto_configure: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_configure: This feature will be removed in compat 12.
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions

[... snipped ...]

  File "/<>/keystone/common/sql/upgrades.py", line 62, in upgrade
self.schema_.runchange(ver, change, changeset.step)
  File "/usr/lib/python3/dist-packages/migrate/versioning/schema.py", line 93, 
in runchange
change.run(self.engine, step)
  File "/usr/lib/python3/dist-packages/migrate/versioning/script/py.py", line 
148, in run
script_func(engine)
  File 
"/<>/keystone/common/sql/contract_repo/versions/013_contract_protocol_cascade_delete_for_federated_user.py",
 line 26, in upgrade
refcolumns=[protocol_table.c.id, protocol_table.c.idp_id]).drop()
  File "/usr/lib/python3/dist-packages/migrate/changeset/constraint.py", line 
59, in drop
self.__do_imports('constraintdropper', *a, **kw)
  File "/usr/lib/python3/dist-packages/migrate/changeset/constraint.py", line 
32, in __do_imports
run_single_visitor(engine, visitorcallable, self, *a, **kw)
  File "/usr/lib/python3/dist-packages/migrate/changeset/databases/visitor.py", 
line 85, in run_single_visitor
fn(element, **kwargs)
  File "/usr/lib/python3/dist-packages/migrate/changeset/databases/sqlite.py", 
line 204, in visit_migrate_foreign_key_constraint
self.recreate_table(p[0].table, omit_constraints=[p[0].name])
  File "/usr/lib/python3/dist-packages/migrate/changeset/databases/sqlite.py", 
line 100, in recreate_table
self.execute()
  File "/usr/lib/python3/dist-packages/migrate/changeset/ansisql.py", line 44, 
in execute
return self.connection.execute(self.buffer.getvalue())
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 942, in 
execute
return self._execute_text(object, multiparams, params)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1104, 
in _execute_text
statement, parameters
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1200, 
in _execute_context
context)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1409, 
in _handle_dbapi_exception
util.raise_from_cause(newraise, exc_info)
  File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 203, in 
raise_from_cause
reraise(type(exception), exception, tb=exc_tb, cause=cause)
  File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 186, in 
reraise
raise value.with_traceback(tb)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1193, 
in _execute_context
context)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 508, 
in do_execute
cursor.execute(statement, parameters)
oslo_db.exception.DBNonExistentTable: (sqlite3.OperationalError) error in 
trigger federated_user_insert_trigger: no such table: main.migration_tmp [SQL: 
'ALTER TABLE federated_user RENAME TO migration_tmp'] (Background on this error 
at: http://sqlalche.me/e/e3q8)


--
Ran 5575 tests in 3360.083s

FAILED (failures=17, skipped=831)
make[1]: *** [debian/rules:55: override_dh_install] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:14: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
but it also fails here:

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

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Trek]

On Sat, 29 Sep 2018 18:41:45 +0200
Michael Biebl  wrote:

> > +# wait for udev to be ready (see #908796)
> > +timeout=15
> > +until udevadm control -S || [ $timeout -le 0 ]; do
> > +timeout=$((timeout-1))
> > +sleep 1
> > +done
> > +udevadm control -S && log_success_msg || log_failure_msg
> 
> This repeatedly tries to start the execution queue.
> Besides having this side-effect, why is this a proper test to check if
> udev is ready?

this probably shows my ignorance about udev (and lack of documentation),
but it seems to me there isn't a proper way to test if udev is ready

as the bug doesn't affect my system, I cannot know the state of udev
when the udevadm trigger is launched: it could be the control file is
missing or it's created but the daemon is not already accepting events

reading the source, there is a ping message that is recognized by the
control socket, sent internally by udevadm settle, but there isn't a
command line for that message in particular

it seems to me the least dangerous command is to start the execution
queue: in fact when udev is just started, the stop_exec_queue variable
is set to false, then the start of exec queue command will set again
stop_exec_queue to false and it should results in a no-op


we could simply rerun udevadm trigger until it's ok, but it seems not a
good idea https://github.com/kubernetes/kubernetes/issues/55007

may be their fix (calling settle with timeout before trigger) will work
for us? I don't know, as there are many possible side effects
depending on the hardware


it could be a good idea to ask the developers, but reading
https://github.com/systemd/systemd/issues/2477 it seems they are not
really interested about this type of issue and in forward compatibility
(it was running fine until they stopped to remove the control socked on
exit)


I hope I have answered your question, anyway tell me if I can do
something more

ciao!

Bug#909284: minidlna: Minidlna needs libavcodec.so.57 which is not a dependancy

[Dean]

Hello Andreas,


On Fri, 28 Sep 2018 13:23:33 +0200 Andreas Henriksson 
wrote:

> Hello,
>
>
> minidlna(d) has its dependencies generated by dpkg-shlibdeps which
> doesn't include libavcodec. I've verified that the binary has no
> DT_NEEDED on libavcodec.
>
>
> # readelf -d debian/minidlna/usr/sbin/minidlnad | grep libav
> 0x0001 (NEEDED) Shared library: [libavformat.so.58]
> 0x0001 (NEEDED) Shared library: [libavutil.so.56]
>
> Recursive shared library dependencies might pull in libavcodec though
> and as can be seen in your quoted error message the culprit is actually
> libchromaprint.so.1 !
>
> I've checked that libchromaprint1 actually has the proper dependency
> specified, so I guess you just happened to stumble upon this error

> in the middle of a libav transition.


Yes I agree that was probably the problem

>
> # apt-cache show libchromaprint1 | grep libavc
> Depends: libavcodec58 (>= 7:4.0) | libavcodec-extra58 (>= 7:4.0),
libavutil56 (>= 7:4.0), libc6 (>= 2.14), libgcc1 (>= 1:3.4), libstdc++6
(>= 5.2)
>
>
> I'm thus closing this bug report.

>


Thank you for investigating this, I really appreciate it.


> Regards,
> Andreas Henriksson
>


Regards,

Dean.

Bug#606287: d-i manual: should add a "what is the Debian Installer" section

[Brian Potkin]

On Sun 30 Sep 2018 at 23:28:25 +0200, Holger Wansing wrote:

> Hi,
> 
> Brian Potkin  wrote:
> > On Sun 30 Sep 2018 at 20:18:32 +0200, Holger Wansing wrote:
> > 
> > > 
> > > Miguel Figueiredo  wrote:
> > > > on 1.x add What is the Debian Installer (purpose and scope of the
> > > > installer)
> > > 
> > > I would like to apply the below patch from Miguel, if noone objects:
> > > 
> > > 
> > > 
> > > What is the Debian Installer?
> > > 
> > > 
> > > 
> > > Debian Installer, also known as "d-i", is the software system to install 
> > > a basic working Debian system. A wide range of hardware such as
> > > embedded devices, laptops, desktops and server machines is supported and a
> > > large set of free software for many purposes is offered.
> > > 
> > > 
> > 
> > Looks ok.
> >  
> > > The installation is conducted by answering a basic set of questions.
> > > Also available are an expert mode that allows to control every aspect of 
> > > the installation and an advanced feature to perform automated 
> > > installations.
> > > The installed system can be used as is or further customized.
> > > The installation can be performed from a multitude of sources: USB,
> >   ^
> >number (multitude is a bit more 
> > than 4)   
> > > CD/DVD/Blue Ray or the network.
> > > 
> > > 
> > > 
> > > The installer goes back to the boot-floppies project, and it was
> > 
> >  ^
> >"has its origin in" is an alternative. Nit picking
> 
> Unsure, which one is better...

So am I. "goes back to" implies that the start of d-i was about the
same time when the boot-floppies project existed. "has its origin in"
makes a more causal link in that it says that d-i was developed from
the boot-floppies project.

> > >  > > url="http://lists.debian.org/debian-boot/2000/06/msg00279.html;>first 
> > > mentioned by Joey Hess in 2000 [1]. Since then the installation 
> > > system 
> > > has been continuously developed by volunteers improving and adding more 
> > ^
> >continually (time, not space. I am in a minority.)
> 
> Sorry, I don't understand what is meant with "I am in a minority" ... ?
> Does it mean "Changing 'continuously' into 'continually' is a point to
> discuss about", or is it a sentence which describes why 'continuously' should 
> be
> changed into 'continually'.
> 
> Sorry, language barrier :-)

No, it was entirely my fault; I was too brief in what I said. Forget
I ever said it, please. "continuously" is fine.

-- 
Brian.

Bug#909984: ITP: vaapi-media-driver -- VA-API driver for Intel Gen8+ graphic cards

[Sebastian Ramacher]

Package: wnpp
Severity: wishlist
Owner: Sebastian Ramacher 
Control: block -1 by 909983

* Package name: vaapi-media-driver
  Version : 18.2.0
  Upstream Author : Intel Corporation
* URL : https://github.com/intel/media-driver
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : VA-API driver for Intel Gen8+ graphic cards

VA-API driver for BDW, SKL, BXT, APL, KBL, CF, CNL, ICL chips. This driver will
replace i965-va-driver for those chips.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#909983: ITP: gmmlib -- graphics memory management library

[Sebastian Ramacher]

Package: wnpp
Severity: wishlist
Owner: Sebastian Ramacher 

* Package name: gmmlib
  Version : 18.3.0
  Upstream Author : Intel Corporation, Gabi Melman
* URL : https://github.com/intel/gmmlib
* License : Expat
  Programming Lang: C++
  Description : graphics memory management library

The Intel Graphics Memory Management Library provides device specific and
buffer management for the Intel Graphics Compute Runtime for OpenCL and
the Media Driver for VAAPI.

Upcoming dependency of VAAPI driver implementation for Gen8+ graphic cards.
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#909846: libglib2.0-dev: absolute paths in gio-2.0.pc break reverse dependencies

[Simon McVittie]

On Sat, 29 Sep 2018 at 10:22:06 -0400, Jeremy Bicha wrote:
> I believe we don't consider this a bug in glib2.0.

The more I look at this bug, the less sure I am about the rationale
given for preferring absolute paths in these particular variables, so
I've reopened the upstream bug asking for clarification.

The recommendation given is appropriate for directories into which a
dependent package wants to install e.g. GIO plugins, but I'm not so sure
it's appropriate for build-time tools.

I'm not reverting the change and also not patching the dependent projects
right now, because we need to get this resolved upstream one way or
another (either going back to the previous .pc file contents consistently
across Autotools and Meson builds, or keeping the new .pc file contents
consistently across Autotools and Meson builds, and either way providing
clear recommendations for dependent projects).

smcv

Bug#909832: Debian VPP patches break vaGetImage

[Steinar H. Gunderson]

On Sun, Sep 30, 2018 at 11:51:29PM +0200, Sebastian Ramacher wrote:
>> Sure, I'll be happy to test, but I'm unsure exactly how? I mean, keeping 
>> .set_vpp = 1
>> _seems_ to work just fine for me, but I have no idea what it would break, if
>> anything.
> As long as the code doesn't hit another VA_STATUS_ERROR_UNIMPLEMENTED, I think
> it should be fine. All the missing shaders should trigger that error code if
> code relying on the shaders is called.

I suppose which code?

I can confirm that my own code (which does JPEG decoding and nothing else)
works just fine on Haswell if I re-enable set_vpp = 1. Is that enough testing
that we should just turn it on? Or do you want me to test something else?
If so, please be specific. :-)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#909832: Debian VPP patches break vaGetImage

[Sebastian Ramacher]

On 2018-09-29 13:44:49, Steinar H. Gunderson wrote:
> On Sat, Sep 29, 2018 at 01:37:40PM +0200, Sebastian Ramacher wrote:
> > That might be. I tried multiple times to get feedback from upstream what we 
> > need
> > to disable after removing the non-free shaders, but they simply ignore the
> > issue. So please, especially since you have the hardware to test it (I only
> > tried video decoding on Skylake - I don't have a Haswell machine), I'm 
> > happy to
> > take patches.
> 
> Sure, I'll be happy to test, but I'm unsure exactly how? I mean, keeping 
> .set_vpp = 1
> _seems_ to work just fine for me, but I have no idea what it would break, if
> anything.

As long as the code doesn't hit another VA_STATUS_ERROR_UNIMPLEMENTED, I think
it should be fine. All the missing shaders should trigger that error code if
code relying on the shaders is called.

Cheers

> 
> > FWIW all of that should be easier once we switch to the new driver currently
> > under development. It has an explicit switch to disable all non-free parts.
> 
> That sounds like good news, although I assume it won't reach buster.
> 
> /* Steinar */
> -- 
> Homepage: https://www.sesse.net/
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#909982: wings3d FTBFS with Erlang 21.1

[Adrian Bunk]

Source: wings3d
Version: 2.1.7-2
Severity: serious
Tags: ftbfs

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

...
make[3]: Entering directory '/build/1st/wings3d-2.1.7/e3d'
erlc -pa /build/1st/wings3d-2.1.7/wings-2.1.7/ebin -Werror +debug_info 
-o../ebin e3d_image.erl
erlc -pa /build/1st/wings3d-2.1.7/wings-2.1.7/ebin -Werror +debug_info 
-o../ebin e3d_mesh.erl
erlc -pa /build/1st/wings3d-2.1.7/wings-2.1.7/ebin -Werror +debug_info 
-o../ebin e3d_file.erl
erlc -pa /build/1st/wings3d-2.1.7/wings-2.1.7/ebin -Werror +debug_info 
-o../ebin e3d_obj.erl
erlc -pa /build/1st/wings3d-2.1.7/wings-2.1.7/ebin -Werror +debug_info 
-o../ebin e3d_tds.erl
erlc -pa /build/1st/wings3d-2.1.7/wings-2.1.7/ebin -Werror +debug_info 
-o../ebin e3d_transform.erl
erlc -pa /build/1st/wings3d-2.1.7/wings-2.1.7/ebin -Werror +debug_info 
-o../ebin e3d_mat.erl
erlc -pa /build/1st/wings3d-2.1.7/wings-2.1.7/ebin -Werror +debug_info 
-o../ebin e3d_util.erl
erlc -pa /build/1st/wings3d-2.1.7/wings-2.1.7/ebin -Werror +debug_info 
-o../ebin e3d_vec.erl
erlc -pa /build/1st/wings3d-2.1.7/wings-2.1.7/ebin -Werror +debug_info 
-o../ebin e3d_q.erl
erlc -pa /build/1st/wings3d-2.1.7/wings-2.1.7/ebin -Werror +debug_info 
-o../ebin e3d_qbvh.erl
erlc -pa /build/1st/wings3d-2.1.7/wings-2.1.7/ebin -Werror +debug_info 
-o../ebin e3d_bv.erl
erlc -pa /build/1st/wings3d-2.1.7/wings-2.1.7/ebin -Werror +debug_info 
-o../ebin e3d_kd3.erl
erlc -pa /build/1st/wings3d-2.1.7/wings-2.1.7/ebin -Werror +debug_info 
-o../ebin e3d__tri_quad.erl
erlc -pa /build/1st/wings3d-2.1.7/wings-2.1.7/ebin -Werror +debug_info 
-o../ebin e3d__meshclean.erl
erlc -pa /build/1st/wings3d-2.1.7/wings-2.1.7/ebin -Werror +debug_info 
-o../ebin e3d__bmp.erl
erlc -pa /build/1st/wings3d-2.1.7/wings-2.1.7/ebin -Werror +debug_info 
-o../ebin e3d__dds.erl
compile: warnings being treated as errors
e3d__dds.erl:42: erlang:get_stacktrace/0: deprecated; use the new try/catch 
syntax for retrieving the stack backtrace
make[3]: *** [Makefile:72: ../ebin/e3d__dds.beam] Error 1

Bug#909981: erlang-cherly FTBFS with Erlang 21.1

[Adrian Bunk]

Source: erlang-cherly
Version: 0.12.8+dfsg-9
Severity: serious
Tags: ftbfs

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

...
make[1]: Nothing to be done for 'configure'.
   dh_auto_build -O--buildsystem=rebar
make --no-print-directory -f /usr/share/dh-rebar/make/dh-rebar.Makefile 
build
rebar_compile
rebar compile skip_deps=true -vv
DEBUG: Consult config file "/build/1st/erlang-cherly-0.12.8+dfsg/rebar.config"
DEBUG: Rebar location: "/usr/bin/rebar"
DEBUG: Consult config file 
"/build/1st/erlang-cherly-0.12.8+dfsg/src/cherly.app.src"
DEBUG: Available deps: []
DEBUG: Missing deps  : []
DEBUG: Plugins requested while processing /build/1st/erlang-cherly-0.12.8+dfsg: 
[]
DEBUG: Predirs: []
==> erlang-cherly-0.12.8+dfsg (compile)
DEBUG: Matched required ERTS version: 10.1 -> .*
ERROR: OTP release 21 does not match required regex 
R14B04|R15B02|R15B03|R16B|17|18|19|20
ERROR: compile failed while processing /build/1st/erlang-cherly-0.12.8+dfsg: 
rebar_abort
make[1]: *** [/usr/share/dh-rebar/make/dh-rebar.Makefile:126: rebar_compile] 
Error 1

Bug#909980: averell FTBFS with Erlang 21.1

[Adrian Bunk]

Source: averell
Version: 1.2.5-1
Severity: serious
Tags: ftbfs buster sid

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

...
   dh_auto_build
make -j1
make[1]: Entering directory '/build/1st/averell-1.2.5'
 DEPEND averell.d
 ERLC   averell.erl averell_app.erl averell_cors.erl averell_cors_impl.erl 
averell_cors_policy.erl averell_handler.erl averell_infos.erl averell_log.erl 
averell_sup.erl
compile: warnings being treated as errors
src/averell_cors.erl:54: erlang:get_stacktrace/0: deprecated; use the new 
try/catch syntax for retrieving the stack backtrace
src/averell_cors.erl:207: erlang:get_stacktrace/0: deprecated; use the new 
try/catch syntax for retrieving the stack backtrace
make[2]: *** [erlang.mk:4941: ebin/averell.app] Error 1

Bug#909979: erlang-goldrush FTBFS with Erlang 21.1

[Adrian Bunk]

Source: erlang-goldrush
Version: 0.2.0-1
Severity: serious
Tags: ftbfs

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

...
module 'glc'
  glc: events_test_ (null query compiles)...[0.039 s] ok
  glc: events_test_ (params table exists)...[0.020 s] ok
  glc: events_test_ (null query exists)...[0.020 s] ok
  glc: events_test_ (no init counters test)...[0.012 s] ok
  glc: events_test_ (init counters test)...[0.020 s] ok
  glc: events_test_ (filtered events test)...[0.020 s] ok
  glc: events_test_ (nomatch event test)...[0.016 s] ok
  glc: events_test_ (opfilter equal test)...[0.016 s] ok
  glc: events_test_ (opfilter not equal test)...[0.016 s] ok
  glc: events_test_ (opfilter wildcard test)...[0.015 s] ok
  glc: events_test_ (opfilter notfound test)...[0.014 s] ok
  glc: events_test_ (opfilter greater than test)...[0.016 s] ok
  glc: events_test_ (opfilter greater than or equal to test)...[0.016 s] ok
  glc: events_test_ (opfilter less than test)...[0.015 s] ok
  glc: events_test_ (opfilter less than or equal to test)...[0.016 s] ok
  glc: events_test_ (allholds op test)...[0.040 s] ok
  glc: events_test_ (anyholds op test)...[0.018 s] ok
  glc: events_test_ (with function test)...[0.020 s] ok
  glc: events_test_ (with function storage test)...[0.018 s] ok
  glc: events_test_ (delete test)...[0.022 s] ok
  glc: events_test_ (delete test no stats)...[0.020 s] ok
  glc: events_test_ (reset counters test)...[0.044 s] ok
  glc: events_test_ (reset all counters test)...[0.024 s] ok
  glc: events_test_ (recompile without reset counters test)...[0.043 s] ok
  glc: events_test_ (ets data recovery test)...[0.035 s] ok
  glc: events_test_ (ets data recovery test no stats)...[0.021 s] ok
  glc: events_test_ (run timed job test)...[0.116 s] ok
  glc: events_test_ (reset job counters)...*failed*
in function glc:'-events_test_/0-fun-224-'/1 (src/glc.erl, line 964)
in call from glc:'-events_test_/0-fun-266-'/0 (src/glc.erl, line 964)
in call from eunit_test:run_testfun/1 (eunit_test.erl, line 71)
in call from eunit_proc:run_test/1 (eunit_proc.erl, line 510)
in call from eunit_proc:with_timeout/3 (eunit_proc.erl, line 335)
in call from eunit_proc:handle_test/2 (eunit_proc.erl, line 493)
in call from eunit_proc:tests_inorder/3 (eunit_proc.erl, line 435)
in call from eunit_proc:with_timeout/3 (eunit_proc.erl, line 325)
**error:{assertEqual,[{module,glc},
  {line,964},
  {expression,"Mod : info ( output )"},
  {expected,3},
  {value,4}]}
  output:<<"">>

  glc: events_test_ (reset job counters with no statistics)...[0.059 s] ok
  glc: events_test_ (variable storage test)...[0.022 s] ok
  glc: events_test_ (with multi function any test no stats)...[0.019 s] ok
  glc: events_test_ (with multi function any test)...[0.029 s] ok
  glc: events_test_ (with multi function all test)...[0.033 s] ok
  glc: events_test_ (with multi-function output match test)...[0.042 s] ok
  glc: events_test_ (with multi-function output double-match test)...[0.033 s] 
ok
  glc: events_test_ (with multi function complex match test)...[0.105 s] ok
  glc: events_test_ (with single-function run test)...[0.089 s] ok
  glc: events_test_ (with multi-function output run error test)...[0.178 s] ok
  glc: events_test_ (with pid storage test)...[0.028 s] ok
  glc: union_error_test...ok
  [done in 1.644 s]
===
  Failed: 1.  Skipped: 0.  Passed: 83.
Cover analysis: /build/1st/erlang-goldrush-0.2.0/.eunit/index.html
DEBUG: Reconstruct kernel [{logger_level,notice},
   {logger_sasl_compatible,false}]
DEBUG: Reconstruct compiler []
DEBUG: Reconstruct rebar []
DEBUG: Reconstruct syntax_tools []
DEBUG: Reconstruct goldrush []
DEBUG: Reconstruct stdlib []
DEBUG: Reconstruct crypto [{fips_mode,false},{rand_cache_size,896}]
DEBUG: No processes to kill
ERROR: One or more eunit tests failed.
ERROR: eunit failed while processing /build/1st/erlang-goldrush-0.2.0: 
rebar_abort
make[1]: *** [/usr/share/dh-rebar/make/dh-rebar.Makefile:138: rebar_eunit] 
Error 1

Bug#606287: d-i manual: should add a "what is the Debian Installer" section

[Holger Wansing]

Hi,

Brian Potkin  wrote:
> On Sun 30 Sep 2018 at 20:18:32 +0200, Holger Wansing wrote:
> 
> > 
> > Miguel Figueiredo  wrote:
> > > on 1.x add What is the Debian Installer (purpose and scope of the
> > > installer)
> > 
> > I would like to apply the below patch from Miguel, if noone objects:
> > 
> > 
> > 
> > What is the Debian Installer?
> > 
> > 
> > 
> > Debian Installer, also known as "d-i", is the software system to install 
> > a basic working Debian system. A wide range of hardware such as
> > embedded devices, laptops, desktops and server machines is supported and a
> > large set of free software for many purposes is offered.
> > 
> > 
> 
> Looks ok.
>  
> > The installation is conducted by answering a basic set of questions.
> > Also available are an expert mode that allows to control every aspect of 
> > the installation and an advanced feature to perform automated installations.
> > The installed system can be used as is or further customized.
> > The installation can be performed from a multitude of sources: USB,
>   ^
>number (multitude is a bit more 
> than 4)   
> > CD/DVD/Blue Ray or the network.
> > 
> > 
> > 
> > The installer goes back to the boot-floppies project, and it was
> 
>  ^
>"has its origin in" is an alternative. Nit picking

Unsure, which one is better...

> >  > url="http://lists.debian.org/debian-boot/2000/06/msg00279.html;>first 
> > mentioned by Joey Hess in 2000 [1]. Since then the installation 
> > system 
> > has been continuously developed by volunteers improving and adding more 
> ^
>continually (time, not space. I am in a minority.)

Sorry, I don't understand what is meant with "I am in a minority" ... ?
Does it mean "Changing 'continuously' into 'continually' is a point to
discuss about", or is it a sentence which describes why 'continuously' should be
changed into 'continually'.

Sorry, language barrier :-)


Thanks for proof-reading !

Holger


> > features.
> > 
> > 
> > 
> > More information can be found on the  > url="http://www.debian.org/devel/debian-installer/;>Debian Installer page
> > , on the http://wiki.debian.org/DebianInstalle;>Wiki
> >  and on the http://lists.debian.org/debian-boot/;>
> > debian-boot mailing list.
> > 
> > 
> > 
> >  
> 
> -- 
> Brian.


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#909978: erlang-cuttlefish FTBFS with Erlang 21.1

[Adrian Bunk]

Source: erlang-cuttlefish
Version: 2.0.11+dfsg-3
Severity: serious
Tags: ftbfs

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

...
   dh_auto_build -O--buildsystem=rebar
make --no-print-directory -f /usr/share/dh-rebar/make/dh-rebar.Makefile 
build
rebar_compile
rebar compile skip_deps=true -vv
DEBUG: Consult config file 
"/build/1st/erlang-cuttlefish-2.0.11+dfsg/rebar.config"
DEBUG: Rebar location: "/usr/bin/rebar"
DEBUG: Consult config file 
"/build/1st/erlang-cuttlefish-2.0.11+dfsg/src/cuttlefish.app.src"
DEBUG: Available deps: []
DEBUG: Missing deps  : []
DEBUG: Plugins requested while processing 
/build/1st/erlang-cuttlefish-2.0.11+dfsg: []
DEBUG: Predirs: []
==> erlang-cuttlefish-2.0.11+dfsg (compile)
DEBUG: Matched required ERTS version: 10.1 -> .*
ERROR: OTP release 21 does not match required regex R16|17|18|19|20
ERROR: compile failed while processing 
/build/1st/erlang-cuttlefish-2.0.11+dfsg: rebar_abort
make[1]: *** [/usr/share/dh-rebar/make/dh-rebar.Makefile:126: rebar_compile] 
Error 1

Bug#875112: fixed upstream

[matt]

this has been fixed upstream:
https://github.com/projectM-visualizer/projectm/pull/5

though upstream has moved:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909977



pEpkey.asc
Description: application/pgp-keys

Bug#909977: projectm: upstream has moved

[matt]

Source: projectm
Severity: wishlist

Dear Maintainer,

The upstream source for projectm has moved to 
https://github.com/projectM-visualizer/projectm .  An announcement post in the 
SourceForge page is available here: 
https://sourceforge.net/p/projectm/news/2018/09/visit-github-for-updates/ , and 
an update to the SF front page is pending: 
https://github.com/projectM-visualizer/projectm/issues/108 .  Updating from the 
new source should also resolve #875112, as they've updated to using qt5 as of 
last February: https://github.com/projectM-visualizer/projectm/pull/5 .

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

Kernel: Linux 4.9.0-8-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)

Bug#906366: Seems to be fixed in 1.28-1

[Santiago Vila]

found 906366 1.28-1
thanks

On Sat, 22 Sep 2018, Adrian Bunk wrote:

> Seems to be fixed in 1.28-1:
> https://tests.reproducible-builds.org/debian/history/ivyplusplus.html

It does not seem fixed right now:

https://tests.reproducible-builds.org/debian/history/ivyplusplus.html

Apologies to the maintainers if the current failure is a different
issue than the one I originally reported. I'm going to recycle the bug
anyway because there are no references to this bug in the changelog
and the subject still holds (i.e. FTBFS in buster/sid).

Thanks.

Bug#909740: libsdl2-dev: No longer multi-arch co-installable

[Simon McVittie]

On Sun, 30 Sep 2018 at 22:02:59 +0300, Adrian Bunk wrote:
> Wouldn't the least invasive option be a combination of
> 1. my --includedir=\$${prefix}/include/$(DEB_HOST_MULTIARCH) suggestion plus
> 2. the sdl2-config patching from Hugh

Maybe. You'd have to patch sdl2-config somewhat more extensively than
Hugh's patch, though, to remove the references to the configured
@includedir@ (which would vary by architecture if you use that
--includedir, making /usr/bin/sdl2-config non-co-installable until it
was removed).

Does someone want to put together and test a complete implementation
of this?

> When doing 1. the build system will use the correct paths in the 
> pkg-config and cmake files.

Ugh, I'd missed that there's a third API for building dependent software
(the CMake files). The autopkgtest that I added should ideally test this
one too, but I think that'll probably need a proper CMake build system
(at least one CMakeLists.txt), not just a one-liner?

I think the forwarding header should work OK with this approach, and your
plan with --includedir=\$${prefix}/include/$(DEB_HOST_MULTIARCH) would
obviously also work, but any approach that involves patching the .pc.in
file would also have to patch the .cmake.in file.

smcv

Bug#909530: Please help debugging (Was: Bug#909530: t-coffee: autopkgtest regression)

[Andreas Tille]

Control: tags -1 help

Hi,

On Fri, Sep 28, 2018 at 02:38:19PM +0200, Andreas Tille wrote:
> > Strange.  I'm able to reproduce this here even on my local machine in a
> > shell where I did some `unset HOME`.  I wonder why this error was not
> > produced with version 11.00.8cbe486-6 before.  Anyway, now since the
> > issue can be easily reproduced I'll find a fix soonish.
> 
> While that is now really fixed[1] the other issues seem to be caused
> by something else.  This is really only happening in the package in
> unstable.  Back to gdb ... :-(

I've tried to track down the issue using gdb + fprintf[2] to fix the
coredump issue.  Unfortunately I did not finalised and will not have any
time for the next seven days.

Any help would be welcome

   Andreas.

 
> [1] 
> https://salsa.debian.org/med-team/t-coffee/commit/9cffa995e4603e396054062c6f3dbff1568bf243
[2] 
https://salsa.debian.org/med-team/t-coffee/blob/master/debian/patches/debug.patch

-- 
http://fam-tille.de

Bug#909976: aeskulap: please use the external libglademm2.4 again

[Adrian Bunk]

Source: aeskulap
Version: 0.2.2b1+git20161206-5
Severity: normal

libglademm-2.4 has been adopted and will be in buster.

Bug#869896: backports.ssl-match-hostname should be removed for buster

[Ivo De Decker]

clone 869896 -1
retitle -1 remove unneeded dependency on backports.ssl-match-hostname
block 869896 by -1
clone -1 -2 -3 -4 -5
reassign -1 libcloud
reassign -2 python-docker
reassign -3 websocket-client
reassign -4 docker-compose
reassign -5 sagemath
thanks

On Thu, Jul 27, 2017 at 03:10:33PM +0200, Matthias Klose wrote:
> The python3 and python2 versions already have that fix (and had it in stretch
> too).  This package should  be removed for the buster release.

Making clones for the rdeps to track the removal there.

Ivo

Bug#907829: p4est: FTBFS on single CPU machines

[Adrian Bunk]

On Sun, Sep 30, 2018 at 09:08:30PM +0200, Santiago Vila wrote:
>...
> There needs to be a *very* powerful reason for a package to "need"
> more than one CPU, and so far I have never found a package which
> "legitimately" needs more than one CPU.
>...

Noone disagrees that these are bugs.

But it is simply rude trying to use RC bugs saying
  To reproduce, please try building with sbuild on a single-CPU machine, as I 
did.
for forcing this as high priority upon other people.

For the binary packages we are providing as part of our releases to
our users it is not relevant whether a single-CPU machine can build 
a package, and as already explained there are plenty of other reasons why
some supported machine might not be able to build some specific package.

It is fine if you have your personal pet project of keeping packages 
buildable on single-CPU machines, and there is some overlap with other
peoples pet projects like keeping the hppa port of Debian alive.

If someone wants to works on keeping Debian buildable on single-CPU 
machines or keeping the hppa port alive that is fine - everyone has
the right to decide what he wants to do with his own time.

But trying to use RC bugs for forcing other people to do the work
on such a pet project like keeping Debian buildable on single-CPU
machines or keeping the hppa port alive is not OK - there is no
excuse for trying to force other people to work on your pet project.

Already for some time your attempts to force doing the work on your 
pet project upon other people has generated perfectly understandable
hostility from other developers towards you that obscures all the
useful other work you are doing.

And yes, this is nothing more than your personal pet project.
Noone else doing build testing would even consider using
a single-CPU machine for that in 2018.

> > The result is the same in both cases - a machine supported by Debian 
> > cannot build a package.
> 
> Except that in one case we have a bug and we both agree that it's a
> bug, and in the other case it is not a bug and we both agree that it's
> not a bug.
>...

Please do not make incorrect claims about what I said.

Let me repeat what I actually said about RAM usage:

<--  snip  -->

Bugs that are nearly always involved is that every major release of gcc 
regresses on memory usage.

Including cases where even "-O0 -g0" uses 2 GB RAM:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79030

For anyone who cares about building on low-end machines fixing such bugs 
should be the highest priority.

<--  snip  -->

Your "it is not a bug" claim is also completely wrong in the cases where 
the memory usage of the compiler exceeds the virtual address space on a 
32bit architecture, I am constantly submitting workaround patches for 
such cases - and different from single-CPU building these memory 
exhaustion bugs are RC build failures that do happen on our buildds.

> Thanks.

cu
Adrian

-- 

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

Bug#909969: crtmpserver hard code include search path for dlfcn.h

[Helmut Grohne]

Source: crtmpserver
Version: 1.0~dfsg-5.5
Tags: patch upstream
Control: block 798955 by -1

crtmpserver sarches for dlfcn.h on a hard coded search path that happens
to not include Debian's multiarch directory. Thus crtmpserver will fail
to build against non-glibc libcs and against a multiarched glibc
(#798955). The attached patch replaces the search for the header with a
call to CHECK_INCLUDE_FILE, which uses the compiler's search path.
Please consider applying the attached patch.

Helmut
--- crtmpserver-1.0~dfsg.orig/cmake_find_modules/Find_dl.cmake
+++ crtmpserver-1.0~dfsg/cmake_find_modules/Find_dl.cmake
@@ -1,13 +1,6 @@
 MESSAGE(STATUS "Looking for dl")
-FIND_PATH(DL_INCLUDE_PATH 
-	NAMES
-		dlfcn.h
-	PATHS
-		/usr/include
-		/usr/local/include
-		/sw/include
-		/opt/local/include
-		NO_DEFAULT_PATH)
+include(CheckIncludeFile)
+CHECK_INCLUDE_FILE("dlfcn.h" HAVE_DLFCN_H)
 
 SET(CMAKE_FIND_LIBRARY_SUFFIXES .so.2 ${CMAKE_FIND_LIBRARY_SUFFIXES})
 
@@ -26,18 +19,18 @@
 
 MESSAGE("DL_LIBRARY_PATH: ${DL_LIBRARY_PATH}")
 
-IF(DL_INCLUDE_PATH)
+IF(HAVE_DLFCN_H)
 	SET(DL_FOUND 1 CACHE STRING "Set to 1 if dl is found, 0 otherwise")
 	MESSAGE(STATUS "Looking for libdl headers - found")
-ELSE(DL_INCLUDE_PATH)
+ELSE(HAVE_DLFCN_H)
 	SET(DL_FOUND 0 CACHE STRING "Set to 1 if dl is found, 0 otherwise")
 	MESSAGE(FATAL_ERROR "Looking for libdl headers - not found")
-ENDIF(DL_INCLUDE_PATH)
+ENDIF(HAVE_DLFCN_H)
 
 IF(DL_LIBRARY_PATH)
 	SET(DL_FOUND 1 CACHE STRING "Set to 1 if dl is found, 0 otherwise")
 	MESSAGE(STATUS "Looking for libdl library - found")
-ELSE(DL_LIBRddARY_PATH)
+ELSE(DL_LIBRARY_PATH)
 	SET(DL_LIBRARY_PATH "")
 ENDIF(DL_LIBRARY_PATH)
 

Bug#909970: RFP: astroid -- A graphical threads-with-tags style, lightweight and fast, e-mail client for Notmuch

[Varac]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: astroid
  Version : 0.14 
  Upstream Author : Gaute Hope 
* URL : http://astroidmail.github.io
* License : GPL3
  Programming Lang: C++
  Description : A graphical threads-with-tags style, lightweight and fast, 
e-mail client for Notmuch

Astroid is a lightweight and fast Mail User Agent that provides a graphical 
interface to searching, displaying and composing email, organized in threads 
and tags. Astroid uses the notmuch backend for blazingly fast searches through 
tons of email. Astroid searches, displays and composes emails - and rely on 
other programs for fetching, syncing and sending email.

-BEGIN PGP SIGNATURE-

iQJEBAEBCgAuFiEESvqqiCmYrIkee91NVGXnfnh27QQFAluxMjoQHHZhcmFjQHZh
cmFjLm5ldAAKCRBUZed+eHbtBHemD/wPBsdFDlptq4gBwTZ1GD2IwsOGeouy7z5e
mLG1Bhx1nykm3IAgMa50r+0zUU9Bblrxo9RclUwiDssW9Mwom816VuC6TCjL+lwk
uY3cbUN89u2sNNo7nN7R8Wdbi3ri9IeHLT81LeiRZIHDRA9lgJoRmrBKM2euB9S7
UkVrlu2GvB65TKihSE3lyiMbFTTlxBPIQ7ASDg6CemmyIWLf8ggdb10F19BEqALf
e+i3G6AdXJA8hTsavxMSnfC/08MZeBCshtENipOvZ/BrqaM0v6VVAy0gLKq/m59m
+nanYsG7PM4/MS/al6eFZ+9v2gYTbHHRIQy0scDzu4i1rpEDcbMcZ2Ve+Td5Dfzz
V8ZUXK0H0LB2oHXttUUiLJuD9Pz4fOPS4UQJBas4Y1Eopj7VbQ/kiFknW35GOG1U
oydNI8sTDmMoVdJuH+cl/FUlskafaNwgUCD6FHjLori+tj73V515ZejpxFgPLWbf
ly4v8JonukfwEEYURpkluCsaOPGJ08TnbxQn7Z4tt1GJtEWm9VVePbV9D91uRcWM
px1QgasitYLP0p/32v+Hr+doGCK35Ic7zaNwKFBVME+8YYgHTWbRkrXngOqW8gok
1r/Bf+F/o8+QtITbKMjTZ5tys8ThX62BYSU3UydPU4KJyIT6Fs+zPUkMhJ1xBv6i
Jz+SUdjduQ==
=cKja
-END PGP SIGNATURE-

Bug#829709: libxcb-randr0-dev: Should use Requires.private in pkg-config file

[Andrea Bolognani]

Looks like the issue was addressed at some point during the past
two years:

  $ grep xcb-render /usr/lib/x86_64-linux-gnu/pkgconfig/xcb-randr.pc
  Requires.private: xcb xcb-render
  $

And accordingly:

  $ pkg-config --libs xcb-randr
  -lxcb-randr
  $

I believe the bug can be closed now.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#909545: SSL CERTIFICATE_VERIFY_FAILED when using gs (Google Cloud Storage) backend.

[Witold Baryluk]

Needed a small change to your patch:

Line 126 in boto/https_connection.py  in connect function needs to be
protected by check::

126 if self.key_file:
127 context.load_cert_chain(certfile=self.cert_file,
keyfile=self.key_file)


otherwise I got:

  File "/usr/lib/python2.7/httplib.py", line 844, in send
self.connect()
  File "/usr/lib/python2.7/dist-packages/boto/https_connection.py", line
126, in connect
context.load_cert_chain(certfile=self.cert_file, keyfile=self.key_file)
 TypeError: coercing to Unicode: need string or buffer, NoneType found


This is because I do not use client certificates.

After that I got duplicity working again and it connects just fine now.


sob., 29 wrz 2018 o 21:54 Sebastian Andrzej Siewior 
napisał(a):

> control: tags -1 patch
>
> On 2018-09-25 03:04:49 [+0200], Witold Baryluk wrote:
> > Now it takes few minutes on any command, and then errors out:
> > Cleaning older backups
> > Traceback (innermost last):
> …
> >  SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed
> (_ssl.c:726)
>
> It looks like missing SNI support.
> Could you please try if the patch attached works? It is completly
> untested it just looks like it might work…
>
> Sebastian
>


-- 
Witold Baryluk
My PGP keys for 2017-02-17 - 2019-02-17:
5B8C 48CB 8B2F CF53 CA55  0995 16D9 6FA2 20A8 F130
https://functor.xyz/pgp/witold.baryluk-gmail.gpg.asc
https://keys.mailvelope.com/pks/lookup?op=get=0x16D96FA220A8F130

Bug#909968: ITP: vitetris -- Virtual terminal *tris clone

[Baptiste BEAUPLAT]

Package: wnpp
Severity: wishlist
Owner: lykn...@cilg.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: vitetris
  Version : 0.57.2
  Upstream Author : Victor Geraldsson
* URL : http://www.victornils.net/tetris/
* License : BSD-2-Clause
  Programming Lang: C
  Description : Virtual terminal *tris clone

Viteris is a tetris clone with multiplayer, netplay and joystick support.
This is a terminal based, standalone game with no dependencies.

Note that this would be my first attempt at creating a Debian package. I
choose this one because it's a nice game and it's a very simple program
to begin with. I will need a sponsor to upload this package.

Regards,

- --

Baptiste BEAUPLAT - lyknode

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQQt4kiVMTxdp/CJ4U4XSUsQeV3XMwUCW7Ek6QAKCRAXSUsQeV3X
M+3OAP4jqQ1rrkV9G3dlJ0l94K3YvwfnWRlmsY4HuwtAM2EiygEAy8Q2zmDfNiOV
OMWbhDgIQx1l6BodydAjAx3acaT+qAA=
=mZ4l
-END PGP SIGNATURE-

Bug#909967: audit hard codes location of stdint.h

[Helmut Grohne]

Source: audit
Version: 1:2.8.4-2
Tags: patch upstream
Control: block 798955 by -1

auditswig.i hard codes the path to stdint.h. That will fail to work with
non-glibc libcs and after moving glibc's headers (#798955). The path is
hard coded, because swig's %include does not search the standard header
search path. Rather than using %include here, we can use #include,
because stdint.h does not declare any functions. Thus swig entirely
ignores stdint.h and leaves the search to the C compiler. Please
consider applying the attached patch.

Helmut
--- audit-2.8.4.orig/bindings/swig/src/auditswig.i
+++ audit-2.8.4/bindings/swig/src/auditswig.i
@@ -41,6 +41,6 @@
 typedef unsigned uid_t;
 %include "/usr/include/linux/audit.h"
 #define __extension__ /*nothing*/
-%include "/usr/include/stdint.h"
+#include 
 %include "../lib/libaudit.h"
 

Bug#909966: apparmor hard codes location of netinet/in.h header

[Helmut Grohne]

Source: apparmor
Version: 2.13-8
Tags: patch upstream
Control: block 798955 by -1

apparmor hard codes the location of  to extract macros
from it. Doing so will break with non-glibc libcs on Debian and with
glibc headers moved to multiarch locations (#798955). Please consider
extracting the header by calling the compiler instead. The attached
patch implements that.

Helmut
--- apparmor-2.13.orig/libraries/libapparmor/src/Makefile.am
+++ apparmor-2.13/libraries/libapparmor/src/Makefile.am
@@ -42,8 +42,8 @@
 
 scanner.c: scanner.l
 
-af_protos.h: /usr/include/netinet/in.h
-	 LC_ALL=C  sed  -n -e "/IPPROTO_MAX/d"  -e "s/^\#define[ \\t]\\+IPPROTO_\\([A-Z0-9_]\\+\\)\\(.*\\)$$/AA_GEN_PROTO_ENT(\\UIPPROTO_\\1, \"\\L\\1\")/p" $< > $@
+af_protos.h:
+	 echo '#include ' | gcc -E -dM - | LC_ALL=C  sed  -n -e "/IPPROTO_MAX/d"  -e "s/^\#define[ \\t]\\+IPPROTO_\\([A-Z0-9_]\\+\\)\\(.*\\)$$/AA_GEN_PROTO_ENT(\\UIPPROTO_\\1, \"\\L\\1\")/p" > $@
 
 lib_LTLIBRARIES = libapparmor.la
 noinst_HEADERS = grammar.h parser.h scanner.h af_protos.h private.h PMurHash.h

Bug#909785: python-pcl: Incomplete debian/copyright and/or "freeware" source code?

[Chris Lamb]

Hi Jochen,

> I added comments here:
> 
> https://salsa.debian.org/python-team/modules/python-pcl/commit/bff3480ce174fe28192abe3e256a195081a2013d
> 
> Also, I added a comment to the PCL copyright:
> 
> https://salsa.debian.org/science-team/pcl/commit/df7d3a72113e1b55f2820ae4b5d8773572df43f5

Great stuff; thanks! The only thing I would add would be something that
explicitly addresses the the "freeware" term - it is a bit of a
"trigger word" for people looking for DFSG violations.


Regards,

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

Bug#606287: d-i manual: should add a "what is the Debian Installer" section

[Brian Potkin]

On Sun 30 Sep 2018 at 20:18:32 +0200, Holger Wansing wrote:

> 
> Miguel Figueiredo  wrote:
> > on 1.x add What is the Debian Installer (purpose and scope of the
> > installer)
> 
> I would like to apply the below patch from Miguel, if noone objects:
> 
> 
> 
> What is the Debian Installer?
> 
> 
> 
> Debian Installer, also known as "d-i", is the software system to install 
> a basic working Debian system. A wide range of hardware such as
> embedded devices, laptops, desktops and server machines is supported and a
> large set of free software for many purposes is offered.
> 
> 

Looks ok.
 
> The installation is conducted by answering a basic set of questions.
> Also available are an expert mode that allows to control every aspect of 
> the installation and an advanced feature to perform automated installations.
> The installed system can be used as is or further customized.
> The installation can be performed from a multitude of sources: USB,
  ^
   number (multitude is a bit more than 
4)   
> CD/DVD/Blue Ray or the network.
> 
> 
> 
> The installer goes back to the boot-floppies project, and it was

 ^
   "has its origin in" is an alternative. Nit picking

> http://lists.debian.org/debian-boot/2000/06/msg00279.html;>first 
> mentioned by Joey Hess in 2000 [1]. Since then the installation 
> system 
> has been continuously developed by volunteers improving and adding more 
^
   continually (time, not space. I am in a minority.)

> features.
> 
> 
> 
> More information can be found on the  url="http://www.debian.org/devel/debian-installer/;>Debian Installer page
> , on the http://wiki.debian.org/DebianInstalle;>Wiki
>  and on the http://lists.debian.org/debian-boot/;>
> debian-boot mailing list.
> 
> 
> 
>  

-- 
Brian.

Bug#909965: apcalc hard codes location of standard C headers

[Helmut Grohne]

Source: apcalc
Version: 2.12.5.0-1
Tags: patch upstream
Control: block 798955 by -1

apcalc checks header existence by searching them in a few file system
locations. Unfortunately, Debian's /usr/include/ is not among
those locations and that makes apcalc fail to build when built against a
non-glibc or a glibc with multiarch headers (#798955). The attached
patch replaces those file existence tests with compile tests. The
compiler knows much better whether headers exists and thus the
complexity of the Makefile is reduced. Please consider applying the
attached patch.

Helmut
--- apcalc-2.12.5.0.orig/Makefile
+++ apcalc-2.12.5.0/Makefile
@@ -2254,22 +2254,13 @@
${Q} echo '' >> endian_calc.h
${Q} echo '/* what byte order are we? */' >> endian_calc.h
-${Q} if [ X"${CALC_BYTE_ORDER}" = X ]; then \
-   if [ -f ${INCDIR}/endian.h ]; then \
-   echo '#include ' >> endian_calc.h; \
-   echo '#define CALC_BYTE_ORDER BYTE_ORDER' >> endian_calc.h; \
-   elif [ -f ${INCDIR}/machine/endian.h ]; then \
-   echo '#include ' >> endian_calc.h; \
-   echo '#define CALC_BYTE_ORDER BYTE_ORDER' >> endian_calc.h; \
-   elif [ -f ${INCDIR}/sys/endian.h ]; then \
-   echo '#include ' >> endian_calc.h; \
-   echo '#define CALC_BYTE_ORDER BYTE_ORDER' >> endian_calc.h; \
-   elif [ -f /usr/include/endian.h ]; then \
+   if echo '#include ' | ${CC} -E - >/dev/null 2>&1; then \
echo '#include ' >> endian_calc.h; \
echo '#define CALC_BYTE_ORDER BYTE_ORDER' >> endian_calc.h; \
-   elif [ -f /usr/include/machine/endian.h ]; then \
+   elif echo '#include ' | ${CC} -E - >/dev/null 
2>&1; then \
echo '#include ' >> endian_calc.h; \
echo '#define CALC_BYTE_ORDER BYTE_ORDER' >> endian_calc.h; \
-   elif [ -f /usr/include/sys/endian.h ]; then \
+   elif echo '#include ' | ${CC} -E- >/dev/null 2>&1; 
then \
echo '#include ' >> endian_calc.h; \
echo '#define CALC_BYTE_ORDER BYTE_ORDER' >> endian_calc.h; \
else \
@@ -2336,9 +2327,7 @@
echo '#define HAVE_TIMES_H  /* yes */' >> have_times.h; \
elif [ X"${HAVE_TIMES_H}" = X"NO" ]; then \
echo '#undef HAVE_TIMES_H  /* no */' >> have_times.h; \
-   elif [ -f ${INCDIR}/times.h ]; then \
-   echo '#define HAVE_TIMES_H  /* yes */' >> have_times.h; \
-   elif [ -f /usr/include/times.h ]; then \
+   elif echo '#include ' | ${CC} -E - >/dev/null 2>&1; then \
echo '#define HAVE_TIMES_H  /* yes */' >> have_times.h; \
else \
echo '#undef HAVE_TIMES_H  /* no */' >> have_times.h; \
@@ -2347,9 +2336,7 @@
echo '#define HAVE_SYS_TIMES_H  /* yes */' >> have_times.h; \
elif [ X"${HAVE_SYS_TIMES_H}" = X"NO" ]; then \
echo '#undef HAVE_SYS_TIMES_H  /* no */' >> have_times.h; \
-   elif [ -f ${INCDIR}/sys/times.h ]; then \
-   echo '#define HAVE_SYS_TIMES_H  /* yes */' >> have_times.h; \
-   elif [ -f /usr/include/sys/times.h ]; then \
+   elif echo '#include ' | ${CC} -E - >/dev/null 2>&1; then \
echo '#define HAVE_SYS_TIMES_H  /* yes */' >> have_times.h; \
else \
echo '#undef HAVE_SYS_TIMES_H  /* no */' >> have_times.h; \
@@ -2358,9 +2345,7 @@
echo '#define HAVE_TIME_H   /* yes */' >> have_times.h; \
elif [ X"${HAVE_TIME_H}" = X"NO" ]; then \
echo '#undef HAVE_TIME_H  /* no */' >> have_times.h; \
-   elif [ -f ${INCDIR}/time.h ]; then \
-   echo '#define HAVE_TIME_H  /* yes */' >> have_times.h; \
-   elif [ -f /usr/include/time.h ]; then \
+   elif echo '#include ' | ${CC} -E - >/dev/null 2>&1; then \
echo '#define HAVE_TIME_H  /* yes */' >> have_times.h; \
else \
echo '#undef HAVE_TIME_H  /* no */' >> have_times.h; \
@@ -2369,9 +2354,7 @@
echo '#define HAVE_SYS_TIME_H   /* yes */' >> have_times.h; \
elif [ X"${HAVE_SYS_TIME_H}" = X"NO" ]; then \
echo '#undef HAVE_SYS_TIME_H  /* no */' >> have_times.h; \
-   elif [ -f ${INCDIR}/sys/time.h ]; then \
-   echo '#define HAVE_SYS_TIME_H  /* yes */' >> have_times.h; \
-   elif [ -f /usr/include/sys/time.h ]; then \
+   elif echo '#include ' | ${CC} -E - >/dev/null 2>&1; then \
echo '#define HAVE_SYS_TIME_H  /* yes */' >> have_times.h; \
else \
echo '#undef HAVE_SYS_TIME_H  /* no */' >> have_times.h; \
@@ -2407,9 +2390,7 @@
echo '#define HAVE_STDLIB_H /* yes */' >> have_stdlib.h; \
elif [ X"${HAVE_STDLIB_H}" = X"NO" ]; then \
echo '#undef HAVE_STDLIB_H  /* no */' >> have_stdlib.h; \
-   elif [ -f ${INCDIR}/stdlib.h ]; then \
-   echo '#define HAVE_STDLIB_H  /* yes */' >> have_stdlib.h; \
-   elif [ -f 

Bug#907829: p4est: FTBFS on single CPU machines

[Santiago Vila]

> building != running
> 
> And I am getting really annoyed of your double standard regarding
> build requirements.

We have to put things in perspective before claiming double-standards.

> If a package cannot be built on a single-core machine with 256 MB RAM 
> due to the number of CPUs, you claim this would be an enormous problem 
> equal to dropping support for running Debian on that machine.

Because I can build approximately 99.99% of all Debian packages with a
single-core machine.

There needs to be a *very* powerful reason for a package to "need"
more than one CPU, and so far I have never found a package which
"legitimately" needs more than one CPU.

I have yet to see a case where more than one CPU is actually *required*.

> But if a package cannot be built on a single-core machine with
> 256 MB RAM due to the amount of RAM, this is apparently fine for you.

Because only 40% - 50% of Debian packages may be built with such
amount of memory, and also, because if a package is not buildable with
a given amount of memory, it's usually not the package's fault, but
a real requirement from gcc.

> The result is the same in both cases - a machine supported by Debian 
> cannot build a package.

Except that in one case we have a bug and we both agree that it's a
bug, and in the other case it is not a bug and we both agree that it's
not a bug.

I don't see what double standards you refer here. Why should I be
equally upset for something which is a bug and has an easy fix and for
something which is not a bug and it does not have any easy fix at all?

Thanks.

Bug#769616: tasksel: fails to preseed desktop on kfreebsd, hurd

[Holger Wansing]

Hi guys,


> Steven Chamberlain, le Sun 10 May 2015 22:41:57 +0100, a écrit :
> > Samuel Thibault wrote:
> > > I believe it's completely fixed by now: using
> > > 
> > > tasksel tasksel/first multiselect standard, xfce-desktop
> > > 
> > > works to preseed the desktop on !linux, and the tasksel/desktop
> > > preseeding works as expected.
> > 
> > The same is also true on linux jessie and sid.
> 
> I just meant that it used to be disfunctional for !linux before, and the
> arch difference was fixed in time for jessie.
> 
> > This preseeds to install XFCE:
> > 
> > tasksel tasksel/first multiselect standard, xfce-desktop
> > 
> > whereas this (traditional way) no longer does anything, and you would
> > still get GNOME or whatever is default:
> > 
> > tasksel tasksel/desktop multiselect xfce
> 
> Right, the latter doesn't seem to be propagated to the former when only
> the latter is preseeded.
> 
> Samuel

What's the status here? Can we close this bug?


Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#909740: libsdl2-dev: No longer multi-arch co-installable

[Adrian Bunk]

On Sun, Sep 30, 2018 at 07:08:26PM +0100, Simon McVittie wrote:
>...
> I prefer this approach because it's relatively self-contained, and
> doesn't require us to carry non-upstreamable patches to upstream code
> or rely on a relatively obscure Debian-specific compiler option.
> 
> The alternative would be to modify the build system so that
> at least SDL_config.h (and possibly all the headers) are in
> /usr/include//SDL2, arrange for the pkg-config metadata to
> include -I/usr/include//SDL2 (and possibly /usr/include/SDL2)
> in the Cflags, and arrange for sdl2-config to output the same CFLAGS as
> -pkg-config without itself having architecture-varying content,
> most likely by using a `cc -print-multiarch` trick similar to the one
> Hugh suggested.
>...

Wouldn't the least invasive option be a combination of
1. my --includedir=\$${prefix}/include/$(DEB_HOST_MULTIARCH) suggestion plus
2. the sdl2-config patching from Hugh

When doing 1. the build system will use the correct paths in the 
pkg-config and cmake files.

The only remaining issue would be sdl2-config, and this would be covered 
by 2.

This sounds better to me than adding some Debian-specific header.

It would move all headers under the multiarch location, but 1.5 MB 
diskspace additional usage are a non-issue for someone compiling for 
more than one architecture.

Anything I miss here?

cu
Adrian

-- 

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

Bug#788429: spamassassin: /etc/init.d/spamassassin restart fails on Jessie/sysvinit

[Noah Meyerhans]

On Thu, Jun 11, 2015 at 11:40:48AM +0200, Marko von Oppen wrote:
> root@host:~# /etc/init.d/spamassassin restart
> Restarting SpamAssassin Mail Filter Daemon: No /usr/sbin/spamd found running; 
> none killed.
> server socket setup failed, retry 1: spamd: could not create IO::Socket::IP 
> socket on [0.0.0.0]:783: Die Adresse wird bereits verwendet
> ...
> 
> So the 'start-stop-daemon --stop' calls in /etc/init.d/spamassassin are not 
> able to identify the running spamd processes.
> 
> The error message is right:
> root@host:~# ps -ef | grep spam
> root  2177 1  0 09:36 ?00:00:04 /usr/bin/perl -T -w 
> /usr/sbin/spamd -i 0.0.0.0 -A 127.0.0.1,::1 -x -u nobody --sql-config 
> --max-children=10 --helper-home-dir --allow-tell -D pyzor -d 
> --pidfile=/var/run/spamd.pid
> nobody2257  2177  0 09:36 ?00:00:20 spamd child
> nobody2258  2177  0 09:36 ?00:00:00 spamd child
> root  9064  8904  0 11:01 pts/100:00:00 grep spam
> 
> Solution:
> remove the '--name $DAEMON' argument from the 'start-stop-daemon --stop' 
> calls.
> 
> start-stop-daemon easily identifies the spamd process using the pidfile.

I have managed to reproduce this problem on current sid systems with
sysvinit. The problem appears to be that _sometimes_ spamd runs but does
not reset $0, so start-stop-daemon isn't able to properly identify the
process with the --name restriction in place. This does not happen 100%
of the time, and I don't know what circumstances trigger it.

Dropping the --name flag from start-stop-daemon isn't safe to do
generally, as it means that the pid file is the only source of
information, and it's entirely possible for that file to become out of
sync with reality. The additional safety change of --name is required to
ensure we don't ever kill the wrong process.

As has been indicated elsewhere in this report, the problem does not on
default installations, which use systemd.



signature.asc
Description: PGP signature

Bug#909964: amphetamine hard codes location of standard C headers

[Helmut Grohne]

Source: amphetamine
Version: 0.8.10-20
Tags: patch
Control: block 798955 by -1

When building amphetamine against a non-glibc libc or against a glibc
with multiarch headers (#798955), amphetamine fails to build from
source, because it hard codes header locations. It uses them as
dependencies in its Makefile, but that's useless as there are no rules
to generate them. Just dropping those dependencies makes it build here.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru amphetamine-0.8.10/debian/changelog 
amphetamine-0.8.10/debian/changelog
--- amphetamine-0.8.10/debian/changelog 2018-05-17 13:11:39.0 +0200
+++ amphetamine-0.8.10/debian/changelog 2018-09-30 20:55:54.0 +0200
@@ -1,3 +1,10 @@
+amphetamine (0.8.10-20.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not hard code locations of standard C headers. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 30 Sep 2018 20:55:54 +0200
+
 amphetamine (0.8.10-20) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru amphetamine-0.8.10/debian/patches/000_data_path.diff 
amphetamine-0.8.10/debian/patches/000_data_path.diff
--- amphetamine-0.8.10/debian/patches/000_data_path.diff2018-05-17 
13:11:39.0 +0200
+++ amphetamine-0.8.10/debian/patches/000_data_path.diff2018-09-30 
20:55:46.0 +0200
@@ -38,12 +38,88 @@
  
  # This is what makemake added
  
-@@ -194,7 +194,7 @@
+@@ -146,57 +146,57 @@
  
- ./src/Surface.o: ./src/AmpHead.hpp ./src/Clut.hpp ./src/ConstVal.hpp 
./src/Graphfil.hpp ./src/Shape.hpp ./src/ShapeLd.hpp ./src/Surface.hpp 
./src/System.hpp /usr/include/limits.h /usr/include/math.h /usr/include/stdio.h 
/usr/include/stdlib.h
+ # DO NOT DELETE THIS LINE -- makemake depends on it.
+ 
+-./src/Appl.o: ./src/AmpHead.hpp ./src/Appl.hpp ./src/Bullet.hpp 
./src/Clut.hpp ./src/ConstVal.hpp ./src/Element.hpp ./src/File.hpp 
./src/Graphfil.hpp ./src/Gui.hpp ./src/Level.hpp ./src/Monster.hpp 
./src/ObjInfo.hpp ./src/Object.hpp ./src/Player.hpp ./src/Pltform.hpp 
./src/Shape.hpp ./src/ShapeLd.hpp ./src/SndSys.hpp ./src/SoundList.hpp 
./src/Surface.hpp ./src/System.hpp ./src/Thing.hpp ./src/Weapon.hpp 
/usr/include/limits.h /usr/include/math.h /usr/include/stdio.h 
/usr/include/stdlib.h
++./src/Appl.o: ./src/AmpHead.hpp ./src/Appl.hpp ./src/Bullet.hpp 
./src/Clut.hpp ./src/ConstVal.hpp ./src/Element.hpp ./src/File.hpp 
./src/Graphfil.hpp ./src/Gui.hpp ./src/Level.hpp ./src/Monster.hpp 
./src/ObjInfo.hpp ./src/Object.hpp ./src/Player.hpp ./src/Pltform.hpp 
./src/Shape.hpp ./src/ShapeLd.hpp ./src/SndSys.hpp ./src/SoundList.hpp 
./src/Surface.hpp ./src/System.hpp ./src/Thing.hpp ./src/Weapon.hpp
+ 
+-./src/Bullet.o: ./src/AmpHead.hpp ./src/Appl.hpp ./src/Bullet.hpp 
./src/Clut.hpp ./src/ConstVal.hpp ./src/Element.hpp ./src/File.hpp 
./src/Graphfil.hpp ./src/Level.hpp ./src/Monster.hpp ./src/ObjInfo.hpp 
./src/Object.hpp ./src/Pltform.hpp ./src/Shape.hpp ./src/ShapeLd.hpp 
./src/SndSys.hpp ./src/SoundList.hpp ./src/Surface.hpp ./src/System.hpp 
./src/Thing.hpp ./src/Weapon.hpp /usr/include/limits.h /usr/include/math.h 
/usr/include/stdio.h /usr/include/stdlib.h
++./src/Bullet.o: ./src/AmpHead.hpp ./src/Appl.hpp ./src/Bullet.hpp 
./src/Clut.hpp ./src/ConstVal.hpp ./src/Element.hpp ./src/File.hpp 
./src/Graphfil.hpp ./src/Level.hpp ./src/Monster.hpp ./src/ObjInfo.hpp 
./src/Object.hpp ./src/Pltform.hpp ./src/Shape.hpp ./src/ShapeLd.hpp 
./src/SndSys.hpp ./src/SoundList.hpp ./src/Surface.hpp ./src/System.hpp 
./src/Thing.hpp ./src/Weapon.hpp
+ 
+-./src/Clut.o: ./src/AmpHead.hpp ./src/Clut.hpp ./src/ConstVal.hpp 
./src/Element.hpp ./src/File.hpp ./src/Graphfil.hpp ./src/Level.hpp 
./src/ObjInfo.hpp ./src/Object.hpp ./src/Pltform.hpp ./src/Shape.hpp 
./src/ShapeLd.hpp ./src/Surface.hpp ./src/System.hpp ./src/Thing.hpp 
/usr/include/limits.h /usr/include/math.h /usr/include/stdio.h 
/usr/include/stdlib.h
++./src/Clut.o: ./src/AmpHead.hpp ./src/Clut.hpp ./src/ConstVal.hpp 
./src/Element.hpp ./src/File.hpp ./src/Graphfil.hpp ./src/Level.hpp 
./src/ObjInfo.hpp ./src/Object.hpp ./src/Pltform.hpp ./src/Shape.hpp 
./src/ShapeLd.hpp ./src/Surface.hpp ./src/System.hpp ./src/Thing.hpp
+ 
+-./src/ConstVal.o: ./src/AmpHead.hpp ./src/ConstVal.hpp ./src/System.hpp 
/usr/include/limits.h /usr/include/math.h /usr/include/stdio.h 
/usr/include/stdlib.h /usr/include/string.h
++./src/ConstVal.o: ./src/AmpHead.hpp ./src/ConstVal.hpp ./src/System.hpp
+ 
+-./src/Creeper.o: ./src/AmpHead.hpp ./src/Creeper.hpp ./src/File.hpp 
./src/Graphfil.hpp ./src/Monster.hpp ./src/ObjInfo.hpp ./src/Object.hpp 
./src/Shape.hpp ./src/SoundList.hpp ./src/Surface.hpp ./src/System.hpp 
./src/Thing.hpp ./src/Weapon.hpp /usr/include/limits.h /usr/include/math.h 
/usr/include/stdio.h /usr/include/stdlib.h
++./src/Creeper.o: ./src/AmpHead.hpp ./src/Creeper.hpp ./src/File.hpp 
./src/Graphfil.hpp ./src/Monster.hpp ./src/ObjInfo.hpp ./src/Object.hpp 
./src/Shape.hpp ./src/SoundList.hpp ./src/Surface.hpp ./src/System.hpp 

Bug#909963: hexedit: Malformed address in first line

[Joao Eriberto Mota Filho]

Package: hexedit
Version: 1.4.2-3
Severity: normal
Tags: upstream

hexedit is truncanting the address in first line. See below:

0   46 6F 72 6D  61 74 3A 20  68 74 74 70  73 3A 2F 2F  77 77 77 2E  64 65 62 
69  Format: https://www.debi
0018   61 6E 2E 6F  72 67 2F 64  6F 63 2F 70  61 63 6B 61  67 69 6E 67  2D 
6D 61 6E  an.org/doc/packaging-man
0030   75 61 6C 73  2F 63 6F 70  79 72 69 67  68 74 2D 66  6F 72 6D 61  74 
2F 31 2E  uals/copyright-format/1.
0048   30 2F 0A 55  70 73 74 72  65 61 6D 2D  4E 61 6D 65  3A 20 68 65  78 
65 64 69  0/.Upstream-Name: hexedi
0060   74 0A 53 6F  75 72 63 65  3A 20 68 74  74 70 3A 2F  2F 72 69 67  61 
75 78 2E  t.Source: http://rigaux.
0078   6F 72 67 2F  68 65 78 65  64 69 74 2E  68 74 6D 6C  20 6F 72 0A  20 
20 20 20  org/hexedit.html or.
0090   20 20 20 20  68 74 74 70  73 3A 2F 2F  67 69 74 68  75 62 2E 63  6F 
6D 2F 70  https://github.com/p
00A8   69 78 65 6C  2F 68 65 78  65 64 69 74  0A 0A 46 69  6C 65 73 3A  20 
2A 0A 43  ixel/hexedit..Files: *.C

Eriberto

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

Kernel: Linux 4.13.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages hexedit depends on:
ii  libc62.27-6
ii  libncurses6  6.1+20180714-1
ii  libtinfo66.1+20180714-1

hexedit recommends no packages.

hexedit suggests no packages.

-- no debconf information

Bug#606287: d-i manual: should add a "what is the Debian Installer" section

[Samuel Thibault]

Holger Wansing, le dim. 30 sept. 2018 20:18:32 +0200, a ecrit:
> 
> Miguel Figueiredo  wrote:
> > on 1.x add What is the Debian Installer (purpose and scope of the
> > installer)
> 
> I would like to apply the below patch from Miguel, if noone objects:
> 
> What is the Debian Installer?

No objection from me, I even thought such a section was already there :)

Samuel

> 
> 
> Debian Installer, also known as "d-i", is the software system to install 
> a basic working Debian system. A wide range of hardware such as
> embedded devices, laptops, desktops and server machines is supported and a
> large set of free software for many purposes is offered.
> 
> 
> 
> The installation is conducted by answering a basic set of questions.
> Also available are an expert mode that allows to control every aspect of 
> the installation and an advanced feature to perform automated installations.
> The installed system can be used as is or further customized.
> The installation can be performed from a multitude of sources: USB,
> CD/DVD/Blue Ray or the network.
> 
> 
> 
> The installer goes back to the boot-floppies project, and it was 
> http://lists.debian.org/debian-boot/2000/06/msg00279.html;>first 
> mentioned by Joey Hess in 2000 [1]. Since then the installation 
> system 
> has been continuously developed by volunteers improving and adding more 
> features.
> 
> 
> 
> More information can be found on the  url="http://www.debian.org/devel/debian-installer/;>Debian Installer page
> , on the http://wiki.debian.org/DebianInstalle;>Wiki
>  and on the http://lists.debian.org/debian-boot/;>
> debian-boot mailing list.
> 
> 
> 
>  
> 
> 
> 
> -- 
> Holger Wansing 
> PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
> 

-- 
Samuel
 Les roots ne sont plus ce qu'ils étaient...Maintenant il sont dioxinés,
 c'est de la m... ! Avant on les élevaient avec du bon unix mais ça été
 remplacé par des farines industrielles nouvelles technologies (NT).
 -+- JdK in NPC : Exigez un root élevé sous la mère ! -+-

Bug#909375: Bug #909375: Re: nautilus: Trace/breakpoint trap

[Michael Biebl]

On Sun, 23 Sep 2018 14:33:36 +0200 =?UTF-8?Q?Bernhard_=c3=9cbelacker?=
 wrote:
> Hello Christoph Anton Mitterer,
> I just tried to reproduce this issue.
> 
> It looks like this issue got introduced in upstream commit [1].
> There an error message got added that leads to an immediate process exit.
> This error is shown when file 
> /usr/share/tracker/domain-ontologies/default.rule
> is not found that belongs to package "tracker".
> 
> Therefore a workaround would possibly be to install the package "tracker".
> 
> Attached is a patch that converts the call to "g_error" to the
> error handling style used some lines above with "g_error_new".
> 
> With just libtracker-sparql-2.0-0 built using that patch,
> nautilus just writes some warning but opens and is usable,
> without having package "tracker" installed.
> 
> Could not find any entry in upstream issue tracker [2].
> But I think in the end this should be forwarded and fixed upstream.

Raising this issue of handling a missing ontologies file more gracefully
with the tracker upstream developers seems like a reasonable idea and I
would prefer this solution.

At worst they will reject the idea.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#885654: gwaei: Please drop Build-Depends on rarian-compat

[Jeremy Bicha]

Control: reopen -1
Control: severity -1 serious
Control: tags -1 +patch +ftbfs

Your latest gwaei upload fails to buid from source. I'm attaching a
patch to fix this issue.

Thanks,
Jeremy Bicha
From cc682c8b189dcd837d06f603cc0623e21ab53066 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Sun, 30 Sep 2018 14:33:23 -0400
Subject: [PATCH] debian/rules: Use the --disable-scrollkeeper option for
 configure

Closes: #885654
---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index a4bdbe4..45de313 100755
--- a/debian/rules
+++ b/debian/rules
@@ -52,7 +52,8 @@ config-stamp: configure
 	dh_autoreconf
 	CFLAGS="$(CFLAGS)" ./configure --prefix=/usr	\
 		--sysconfdir=/usr/share	\
-		--mandir=/usr/share/man
+		--mandir=/usr/share/man \
+		--disable-scrollkeeper
 	# convert png icons to xpm so that we can use them with menu system
 	#for i in 16x16 24x24 32x32 ; do \
 	#  convert src/images/$$i/gwaei.png src/images/$$i/gwaei.xpm ; \
-- 
2.17.1

Bug#779366: task-kde-desktop: nepomuk-core-runtime missing while nepomuk-core-data with non-working shortcuts exists

[Holger Wansing]

Control: reassign -1 kdelibs-bin

Vincas Dargis  wrote:
> > I have installed Jessie amd64 form RC1 netinst iso with KDE and OpenSSH 
> > tasks
> > selected in virtual machine.
> > 
> > In app list I can see "Nepomuk Cleaner" and "Nepomuk Backup" shortcuts, but 
> > then
> > I click I get message:
> > "KDEInit could not launch 'nepomukcleaner':
> > Could not find 'nepomukcleaner' executable.

Cyril Brulebois  wrote:
> I don't see any hit for nepomuk in tasksel, so I suppose that should be
> reassigned to some kde package.

In the meantime (more than 3 years later), nepomuk-core-runtime and 
nepomuk-core-data have been removed from the archive, thus this bug is probably 
no longer relevant.
Reassigning to kdelibs-bin nevertheless.
(Sorry, if this is not the correct package.)


Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#909962: USB DVB-T em28xx Pinnacle not working

[example]

Package: linux-image
Version: 4.17.0-1-amd64/now 4.17.8-1

With kernel 4.16 I was able to use my USB DVB-T card. I can't with
kernel 4.17 on my Debian buster/sid.

The demonstration of the problem is pretty obvious from two enclosed
files created within a few minutes on the same hardware and Debian only
booting one way or another.


Don't hesitate to ask me for more information.



$ uname -a
Linux x201 4.16.0-2-amd64 #1 SMP Debian 4.16.16-2 (2018-06-22) x86_64 GNU/Linux

root@x201:~# lsusb
Bus 002 Device 003: ID 05c6:9204 Qualcomm, Inc. 
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 007: ID 17ef:4816 Lenovo Integrated Webcam
Bus 001 Device 005: ID 0a5c:217f Broadcom Corp. BCM2045B (BDC-2.1)
Bus 001 Device 004: ID 147e:2016 Upek Biometric Touchchip/Touchstrip 
Fingerprint Sensor
Bus 001 Device 010: ID 0951:16b7 Kingston Technology 
Bus 001 Device 009: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical
Bus 001 Device 008: ID 17a0:0001 Samson Technologies Corp. C01U condenser 
microphone
Bus 001 Device 006: ID 2304:0226 Pinnacle Systems, Inc. PCTV 330e
Bus 001 Device 003: ID 1a40:0201 Terminus Technology Inc. FE 2.1 7-port Hub
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

root@x201:~# lspci
00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated 
Graphics Controller (rev 02)
00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series 
Chipset HECI Controller (rev 06)
00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network 
Connection (rev 06)
00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 
Enhanced Host Controller (rev 06)
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High 
Definition Audio (rev 06)
00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express 
Root Port 1 (rev 06)
00:1c.3 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express 
Root Port 4 (rev 06)
00:1c.4 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express 
Root Port 5 (rev 06)
00:1d.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 
Enhanced Host Controller (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation QM57 Chipset LPC Interface Controller 
(rev 06)
00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6 port 
SATA AHCI Controller (rev 06)
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller 
(rev 06)
00:1f.6 Signal processing controller: Intel Corporation 5 Series/3400 Series 
Chipset Thermal Subsystem (rev 06)
02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6200 (rev 35)
ff:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture 
Generic Non-core Registers (rev 02)
ff:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture 
System Address Decoder (rev 02)
ff:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 02)
ff:02.1 Host bridge: Intel Corporation 1st Generation Core i3/5/7 Processor QPI 
Physical 0 (rev 02)
ff:02.2 Host bridge: Intel Corporation 1st Generation Core i3/5/7 Processor 
Reserved (rev 02)
ff:02.3 Host bridge: Intel Corporation 1st Generation Core i3/5/7 Processor 
Reserved (rev 02)

root@x201:~# lsmod 
Module  Size  Used by
rfcomm 86016  16
fuse  118784  3
ctr16384  6
ccm20480  9
bnep   24576  2
rc_pinnacle_pctv_hd16384  0
em28xx_rc  20480  0
rc_core49152  3 rc_pinnacle_pctv_hd,em28xx_rc
drxd   32768  1
em28xx_dvb 36864  2
dvb_core  139264  1 em28xx_dvb
em28xx_alsa24576  1
btusb  53248  0
btrtl  16384  1 btusb
snd_usb_audio 221184  1
btbcm  16384  1 btusb
btintel24576  1 btusb
snd_usbmidi_lib36864  1 snd_usb_audio
tuner_xc2028   32768  2
bluetooth 626688  37 btrtl,btintel,bnep,btbcm,rfcomm,btusb
snd_rawmidi40960  1 snd_usbmidi_lib
tuner  32768  1
snd_seq_device 16384  1 snd_rawmidi
tvp515024576  1
em28xx_v4l 53248  0
qcserial   20480  0
usb_wwan   20480  1 qcserial
uvcvideo  106496  0
usbserial  53248  2 qcserial,usb_wwan
videobuf2_vmalloc  16384  2 uvcvideo,em28xx_v4l
videobuf2_memops   16384  1 videobuf2_vmalloc
videobuf2_v4l2 28672  2 uvcvideo,em28xx_v4l
videobuf2_common   49152  3 uvcvideo,em28xx_v4l,videobuf2_v4l2
drbg   28672  1
ansi_cprng 16384  0

Bug#909961: ITP: termrec -- terminal session recorder/player/converter

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: termrec
  Version : 0.18
  Upstream Author : yours truly
* URL : https://angband.pl/termrec.html
* License : LGPL2+noAffero
  Programming Lang: C
  Description : terminal session recorder/player/converter

termrec can record and replay a "video" of a terminal session, akin to and
compatible with ttyrec, nh-recorder, DosRecorder and asciinema.  Unlike
these programs, you can go back during replay (like less vs more).  The
recordings can be compressed on the fly, and/or streamed over various
protocols.  You can also convert between supported formats.

The UI is pretty weak, but a library is provided so you can write something
better.

Bug#739489: spamassassin: Failed to update

[Noah Meyerhans]

On Sun, Feb 23, 2014 at 07:05:29PM -0700, Bob Proulx wrote:
> Best would be if spamassassin itself was able to understand that this
> directory is not fully populated yet and ignore it until it is so that
> it could avoid the "no rules" error itself.  If there is a bug to be
> pointed at I think that is the place to point.

I can confirm that this bug is still present in the recently released
3.4.2. If /var/lib/spamassassin/3.004002 exists but is empty, spamd will
fail to start.



signature.asc
Description: PGP signature

Bug#907829: p4est: FTBFS on single CPU machines

[Adrian Bunk]

On Sun, Sep 30, 2018 at 06:13:13PM +0200, Santiago Vila wrote:
>...
> > Building all packages on the baseline is never possible, and I already 
> > tried to explain to you that your "1 CPU with unlimited RAM" scenario is 
> > pretty far away from the real-world problems.
> 
> This is double standards again. Not being able to build all packages
> on the baseline has never been an excuse to not submit baseline
> violations (when we find them) as serious.
> 
> You do that, and I fully support it, but for some strange reason
> assumming multi-core is "ok to the point of downgrading this bug"
> while assuming, say, SSE on i386, is not.
> 
> Please explain that.

building != running

And I am getting really annoyed of your double standard regarding
build requirements.

If a package cannot be built on a single-core machine with 256 MB RAM 
due to the number of CPUs, you claim this would be an enormous problem 
equal to dropping support for running Debian on that machine.

But if a package cannot be built on a single-core machine with
256 MB RAM due to the amount of RAM, this is apparently fine for you.

The result is the same in both cases - a machine supported by Debian 
cannot build a package.

Feel free to talk to ask the release team if you think I misinterpret
them when saying that single-core FTBFS are not RC, there is nothing
left to be discussed between you and me on that topic.

> Thanks.

cu
Adrian

-- 

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

Bug#897982: tasksel: Please drop tamil-gtk2im from the task-tamil-gnome-desktop Recommends list

[Holger Wansing]

Hi,

Hugh McMaster  wrote:
> Hi Holger,
> 
> On Sunday, 30 September 2018 7:34 AM, Holger Wansing wrote:
> > Any objections against me committing this?
> 
> I did a QA upload for tamil-gtk2im in June, as it was blocking some changes 
> in gtk+2.0.
> However, the package has been orphaned for at least two years. And, as I 
> wrote in the 
> original bug report, it only supports gtk2.
> 
> After doing some reading, ibus-m17n looks to be the best input method for 
> Tamil.
> Of course, I don't know the language at all, so I can't be certain.
> 
> How will switching to ibus-m17n affect the user experience or installation?

That's out of my skills, sorry.


Holger

-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#606287: d-i manual: should add a "what is the Debian Installer" section

[Holger Wansing]

Miguel Figueiredo  wrote:
> on 1.x add What is the Debian Installer (purpose and scope of the
> installer)

I would like to apply the below patch from Miguel, if noone objects:



What is the Debian Installer?



Debian Installer, also known as "d-i", is the software system to install 
a basic working Debian system. A wide range of hardware such as
embedded devices, laptops, desktops and server machines is supported and a
large set of free software for many purposes is offered.



The installation is conducted by answering a basic set of questions.
Also available are an expert mode that allows to control every aspect of 
the installation and an advanced feature to perform automated installations.
The installed system can be used as is or further customized.
The installation can be performed from a multitude of sources: USB,
CD/DVD/Blue Ray or the network.



The installer goes back to the boot-floppies project, and it was 
http://lists.debian.org/debian-boot/2000/06/msg00279.html;>first 
mentioned by Joey Hess in 2000 [1]. Since then the installation system 
has been continuously developed by volunteers improving and adding more 
features.



More information can be found on the http://www.debian.org/devel/debian-installer/;>Debian Installer page
, on the http://wiki.debian.org/DebianInstalle;>Wiki
 and on the http://lists.debian.org/debian-boot/;>
debian-boot mailing list.



 



-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#909740: libsdl2-dev: No longer multi-arch co-installable

[Simon McVittie]

On Sun, 30 Sep 2018 at 15:54:05 +0100, Simon McVittie wrote:
> For the short term, I'm preparing a NMU that reverts the multiarch change
> and adds an autopkgtest that confirms that the package is usable, because
> libsdl2-dev is currently unusable, and that's a considerably worse bug
> than not being multiarch-friendly.

I have done this, so I'm moving this discussion to #909740. (Adrian,
please let us know if you'd like to be removed from Cc now that SDL2
should have stopped causing FTBFSs.)

> After that, I think it would make most sense for the SDL maintainer
> team to choose one of the working approaches to multiarch, check that
> it does in fact work, and use it to re-close the multiarch bug.

I attach a possible patch for one of the proposed approaches (the
forwarding header that I suggested). I have confirmed that this does not
break compilation of a SDL2 game engine (I used ioquake3) and the
autopkgtest added in my NMU passes. I haven't done a "full stack" test
of cross-compilation yet, but it's symmetrical across architectures, so
hopefully it should work:

$ x86_64-linux-gnu-pkg-config --cflags --libs sdl2
-D_REENTRANT -I/usr/include/SDL2 -lSDL2
$ i686-linux-gnu-pkg-config --cflags --libs sdl2
-D_REENTRANT -I/usr/include/SDL2 -lSDL2
$ sdl2-config --cflags --libs
-I/usr/include/SDL2 -D_REENTRANT
-lSDL2
$ CC='gcc -m32' sdl2-config --cflags --libs
-I/usr/include/SDL2 -D_REENTRANT
-lSDL2

Also available here:
https://salsa.debian.org/smcv/libsdl2/commits/multiarch-forwarding-header

I prefer this approach because it's relatively self-contained, and
doesn't require us to carry non-upstreamable patches to upstream code
or rely on a relatively obscure Debian-specific compiler option.

The alternative would be to modify the build system so that
at least SDL_config.h (and possibly all the headers) are in
/usr/include//SDL2, arrange for the pkg-config metadata to
include -I/usr/include//SDL2 (and possibly /usr/include/SDL2)
in the Cflags, and arrange for sdl2-config to output the same CFLAGS as
-pkg-config without itself having architecture-varying content,
most likely by using a `cc -print-multiarch` trick similar to the one
Hugh suggested.

I started to prototype a patch for that myself, but it
quickly becomes fairly ugly: for example, Hugh's patch from

is not sufficient, because sdl2.pc will still contain only
the non-multiarch @includedir@, unless SDL2 is configured with
--includedir=/usr/include/${DEB_HOST_MULTIARCH}, in which case sdl2-config
will need a different patch to make it non-architecture-varying. As a
result, I'm leaving it to someone who advocates this approach to prepare
a candidate patch for it if they want to.

If someone would prefer this approach, please put together
a complete, tested patch that passes at least these tests:

* libsdl2-dev:amd64 and libsdl2-dev:i386 are co-installable
* the debian/tests/build autopkgtest passes
* x86_64-linux-gnu-pkg-config --cflags --libs sdl2,
  i686-linux-gnu-pkg-config --cflags --libs sdl2 and
  sdl2-config --cflags --libs give reasonable results
* if using Hugh's approach with $CC,
  "CC=i686-linux-gnu-cc sdl2-config --cflags --libs" and
  "CC='gcc -m32' sdl2-config --cflags --libs" also give
  reasonable results

and preferably also test "full stack" cross-compilation of some SDL2
application or game.

SDL2 maintainers: Before releasing a version of SDL2 with *anyone's*
patch applied - including mine! - please make sure that you have tested
it thoroughly, and in particular successfully compiled and run at least
one SDL2 application or game against it.

You should also consider applying Helmut's patch from #907711, which is
on a similar theme (enabling cross-compilation) and seems correct and
upstreamable (but please note that I haven't actually tested it).

smcv
>From db7d3e2dc883e44f1305c9c61a334502b40e9f7b Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 30 Sep 2018 15:17:47 +0100
Subject: [PATCH] Make libsdl2-dev Multi-Arch: same, with working
 

Fix inclusion of  by installing a Debian-specific
forwarding header that includes an appropriate architecture-specific
copy of SDL_config.h.

Closes: #909740
---
 debian/SDL_config.h| 4 
 debian/changelog   | 9 +
 debian/control | 1 +
 debian/libsdl2-dev.install | 2 ++
 debian/rules   | 5 +
 5 files changed, 21 insertions(+)
 create mode 100644 debian/SDL_config.h

diff --git a/debian/SDL_config.h b/debian/SDL_config.h
new file mode 100644
index 000..bbad0f5
--- /dev/null
+++ b/debian/SDL_config.h
@@ -0,0 +1,4 @@
+/* Debian-specific indirection to an architecture-specific copy of
+ * SDL_config.h in one of the compiler's default include directories.
+ * Please do not include _real_SDL_config.h directly. */
+#include 
diff --git a/debian/changelog b/debian/changelog
index 51774eb..c8454ae 100644
--- a/debian/changelog
+++ 

Bug#909960: RFS: shotwell/0.30.1-1

[Andrej Shadura]

Hi,

I nobody uploaded it yet, I can have a look now.

On Sun, 30 Sep 2018, 19:29 Jörg Frings-Fürst,  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
>   I am looking for a sponsor for my package "shotwell"
>
>Package name: shotwell
>Version : 0.30.1-1
>Upstream Author : Jim Nelson 
>URL : https://wiki.gnome.org/Apps/Shotwell
>License : LGPL-2.1, GPL-2+
>Section : gnome
>
> It builds those binary packages:
>
>  shotwell   - digital photo organizer
>  shotwell-common - digital photo organizer - common files
>
> To access further information about this package, please visit the
> following URL:
>
>   https://mentors.debian.net/package/shotwell
>
>
> Alternatively, one can download the package with dget using this
> command:
>
>   dget -x
> https://mentors.debian.net/debian/pool/main/s/shotwell/shotwell_0.30.1-1.dsc
>
> or
>
>   git https://jff.email/cgit/shotwell.git/?h=release%2Fdebian%2F0.30.1-1
>
>
>   Changes since the last upload:
>
>   * New upstream release.
> - Switch to buildsystem meson:
>   + debian/control: Add gnome-pkg-tools, meson and ninja-build to
> Build-Depends.
>   + debian/rules: Add --buildsystem=meson --with gnome,
> remove override_dh_auto_configure and add override_dh_gnome_clean
>

Bug#781794: URI_OBFU_WWW

[Noah Meyerhans]

On Tue, Feb 23, 2016 at 11:32:24AM -0330, Allan Goulding wrote:
> For the record, we have a similar situation with this test. Messages
> were tagged with the same URI_OBFU_WWW test because the domain name was
> embedded in the message signature.
> 
> In this case, the domain is www.ace-net.ca
> 
> It is the -net (or -com) in the domain name that is the key to
> triggering this match. Easily reproducible with a message that contains
> a single line of text that contains the domain name.

This bug has been addressed by upstream for some time. The URI_OBFU_WWW
rule is not present at all in current rulesets, and no rule misfires on
domains such as www.ace-net.ca

Closing this bug.



signature.asc
Description: PGP signature

Bug#909960: RFS: shotwell/0.30.1-1

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

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

It builds those binary packages:

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

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

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


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

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

or

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


  Changes since the last upload:

  * New upstream release.
- Switch to buildsystem meson:
  + debian/control: Add gnome-pkg-tools, meson and ninja-build to
Build-Depends.
  + debian/rules: Add --buildsystem=meson --with gnome,
remove override_dh_auto_configure and add override_dh_gnome_clean.
- debian/shotwell.docs: change README to README.md.
- Refresh debian/copyright.
  * Declare compliance with Debian Policy 4.2.1 (No changes needed).
  * debian/rules: remove unused calculation of B_DATE.
  * debian/shotwell.install: Add usr/share/metainfo (Closes: #906143).

  Regards,
   Jörg Frings-Fürst

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

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

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


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

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


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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAluxB/sACgkQCfifPIyh
0l0b4g/9FPGlj9d/Ko0RycRv42t6rKyUGg68cml/ZOrwTzAG5f0IXW7Dk3Msl9nq
W3HoCmBSW0fggBfiC2e244tw6L/9uiR8OZ+nmOzgBg73jL7tOVBL4/x8ZL6k3ZtV
XaatEOq99YCECuc0ph/0OJn5HHFBdEOmY64vVZi42hMTiZx/S8t73f3AnosZ04qT
ZNoANPZEY+i9hpZUanfrYIOollfJ0cD55Ruz7tGQI3KIn/bTfXSEXpqfKlf1jQMd
DI4rMsw3y3+xM66C5VI0zlpJVReC8npsbN71fQrwtCgJgFiYg7qKJy+N/4FdFqpo
Macfv3RaUUa+R3koq9RwVRfCrBK8ccYr8xN2gIyQszhiwQ4wNCLaDtE3NduYvT0r
2J6rHz4lWnWY1cX75UboD6MMiJlu3YjMfZgod1ocwYD30gsWSE9hKAuKJ3oyiGE1
v6aOtYyFQWCOsak0TO9fto0ABMhmWVBB57HC1+mTANka327iEYFz4AiWQgxrL65G
KIGXHSGtfKhLVhXkTXrta+at+yNXkTu2UkaUhYDsjH7KzPqcbU5ngUbcb4RPuUUp
WmpJPhUn8/hXiQ36i9qA+Q9zPssDYB1l/P2V9qfK7XRV101NMNN9Ju5VdFHkfpN4
i3n9P7/86Xsw0fccG7kUP775xxpEtfMnc5wtW/qkIyzlKkjKAp8=
=R2/9
-END PGP SIGNATURE-

Bug#857184: firefox: Please compile firefox with "ac_add_options --enable-alsa"

[jim_p]

Package: firefox
Followup-For: Bug #857184

Dear Maintainer,

I think this bug can be closed now. Firefox-esr 60 is built with alsa support.
As for stable and beta firefox, the ones in unstable and experimental, although
they are not built with alsa support, they can be used along with apulse
(apulse firefox), just by adding "/dev/snd/" to
"security.sandbox.content.write_path_whitelist" option inside about:config.



-- Package-specific info:


-- Addons package information

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

Kernel: Linux 4.18.0-1-amd64 (SMP w/2 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 firefox depends on:
ii  debianutils   4.8.6
ii  fontconfig2.13.0-5
ii  libatk1.0-0   2.30.0-1
ii  libc6 2.27-6
ii  libcairo-gobject2 1.15.12-1
ii  libcairo2 1.15.12-1
ii  libdbus-1-3   1.12.10-1
ii  libdbus-glib-1-2  0.110-3
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.13.0-5
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.2.0-7
ii  libgdk-pixbuf2.0-02.38.0+dfsg-6
ii  libglib2.0-0  2.58.1-2
ii  libgtk-3-03.24.0-3
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.39-1
ii  libpango-1.0-01.42.4-3
ii  libsqlite3-0  3.25.0-1
ii  libstartup-notification0  0.12-5
ii  libstdc++68.2.0-7
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.6-1
ii  libx11-xcb1   2:1.6.6-1
ii  libxcb-shm0   1.13-3
ii  libxcb1   1.13-3
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.15-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages firefox recommends:
ii  libavcodec58  10:4.0.2-dmo3

Versions of packages firefox suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-6
ii  libgssapi-krb5-2   1.16-2
ii  libgtk2.0-02.24.32-3
pn  pulseaudio 

-- no debconf information

Bug#902472: sdl2: can deadlock after hiding a window

[Simon McVittie]

Version: 2.0.6+dfsg1-1

On Wed, 27 Jun 2018 at 01:28:42 +0200, ydir...@free.fr wrote:
> This behaviour has been fixed in 2.0.6

Closing the bug as fixed in testing/unstable. It remains valid for
stretch, but BTS version tracking will keep track of that.

smcv

Bug#864683: gnome-terminal: Integrate with gnome-shell search

[Simon McVittie]

Control: retitle -1 gnome-terminal: Integrate command-line history with 
gnome-shell search
Control: tags -1 + wontfix

On Mon, 12 Jun 2017 at 22:13:13 +0200, Carlo Marchiori wrote:
> what about integrating the command line history with the search functionality
> provided by the gnome-shell?

This is unlikely to be feasible, because command-line history is not
actually part of gnome-terminal: it's implemented by the shell that you
run inside gnome-terminal, usually bash or dash.

In general, the Debian GNOME maintainers do not have the resources to
implement new features or pursue feature requests upstream (and we would
probably not advocate feature requests upstream as effectively as you
would, because you are the person who wants the feature, and we are not).

smcv

Bug#909792: gnome-terminal: Japanese input always fails using ibus ,after another new window is opened.

[Simon McVittie]

Control: tags -1 + moreinfo

On Fri, 28 Sep 2018 at 21:45:05 +0900, nozzy123no...@gmail.com wrote:
>  I found gnome-terminal always fails to input Japanese text using ibus,
> after new window of gnome-terminal  is opened.

If you upgrade GTK+ to version 3.24.1 or later, does that solve this bug?
Version 3.24.1-1 is available in Debian experimental, and I've just
uploaded 3.24.1-2 to unstable (it should be available soon).

> ii  libgtk-3-03.24.0-3

This version temporarily reverted
,
which we had to do to solve a regression,
. 3.24.1
has a fixed version of that commit, from
.

Thanks,
smcv

Bug#909959: dpkg: should break libapt-pkg5.0 rather than apt

[Sven Joachim]

Package: dpkg
Version: 1.19.1
Severity: minor

The latest dpkg upload has added a Breaks on apt (<< 1.7~b) for
--status-fd duplicate removals, but the warnings that could be seen with
earlier apt versions actually came from libapt-pkg, as I have also seen
them in aptitude.  Therefore dpkg should break libapt-pkg5.0 rather than
apt, although this hardly matters in practice, since it affects only
users who have kept libapt-pkg5.0 at 1.7.0~alpha3 or don't have apt
installed at all.

The faulty check[1] has been added in apt 1.4~beta1, and the last ABI
change of libapt-pkg was in apt 1.1~exp9, so earlier libapt-pkg*
versions are not affected.


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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-9
ii  libc62.27-6
ii  liblzma5 5.2.2-1.3
ii  libselinux1  2.8-1+b1
ii  tar  1.30+dfsg-2
ii  zlib1g   1:1.2.11.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt1.7.0~rc2
pn  debsig-verify  

-- no debconf information


1. 
https://salsa.debian.org/apt-team/apt/commit/dabe9e2482180ada77d2adda2b3c03db22059fb8

Bug#907675: transition: x264

[Niels Thykier]

Sebastian Ramacher:
> On 2018-09-30 08:30:00, Niels Thykier wrote:
>> Control: tags -1 confirmed pending
>>
>> Sebastian Ramacher:
>>> On 2018-08-31 11:01:21, Sebastian Ramacher wrote:
 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: transition
 Control: forwarded -1 
 https://release.debian.org/transitions/html/auto-x264.html
 Control: block -1 by 907659

 x264 bumped its SONAME and needs a transition. Besides opal (not in 
 testing due
 to another build failure, #896893), nageru is the only blocker (#907659). 
 nageru
 has a patch and the maintainer is looking at it.
>>>
>>> I've uploaded it to sid and it built everywhere. Please schedule the 
>>> binNMUs. If
>>> you need help, I'd be happy to them on my own.
>>>
>>> Cheers
>>>
>>
>> I have scheduled binNMUs for this transition.  Please check up on them
>> tomorrow and see if there are unexpected issues.
> 
> Thank you. Please give back ffmpeg with dep wait on libsdl2-dev >=
> 2.0.8+dfsg1-3.1 (failed due to ##909778) and also schedule the binNMUs for
> nageru.
> 
> Cheers
> 

Done.

Thanks,
~Niels

Bug#901774: [pkg-uWSGI-devel] Bug#901774: Crash on SIGQUIT with plugin-python3

[Yuri D'Elia]

On Sun, Sep 30 2018, Jonas Smedegaard wrote:
> Quoting wavexx (2018-07-12 11:32:38)
>> This is still true for 2.0.17. uwsgi-plugin-python3 cannot be
>> gracefully shutdown:
>
> I cherry-picked some upstream improvements for python3 module:
> Could you please test if still an issue with uwsgi 2.0.17.1-6?

I just tested and I don't get any crash during reload or shutdown.
Thanks a lot for digging into this!

Bug#907829: p4est: FTBFS on single CPU machines

[Santiago Vila]

On Sun, Sep 30, 2018 at 06:22:23PM +0300, Adrian Bunk wrote:

> Noone is talking about no longer supporting running Debian on 
> single-core systems.

Well, you are talking about dropping (or lowering) support for
building Debian on single-core systems.

But we are not a proprietary software company where what you call
"using" is the "usual thing" and building is a "special thing",
secondary in importance, that it is only guaranteed to work in the
official buildds.

We are a free software project, and being able to build the package is
essential to what we offer. There is no excuse to take away this
essential freedom just because "it builds ok in the buildds", the same
way there would not be an excuse to ship packages that do not work
just because "they work in the buildds".

Just becase less people try the packages by building them does not
mean that building is less important than "using" them.

So I'll ask again: Why do you want to deprecate building on
single-core and not "using" in single-core? If we followed your
"real-world" arguments, support for both things should be on par.

> Building all packages on the baseline is never possible, and I already 
> tried to explain to you that your "1 CPU with unlimited RAM" scenario is 
> pretty far away from the real-world problems.

This is double standards again. Not being able to build all packages
on the baseline has never been an excuse to not submit baseline
violations (when we find them) as serious.

You do that, and I fully support it, but for some strange reason
assumming multi-core is "ok to the point of downgrading this bug"
while assuming, say, SSE on i386, is not.

Please explain that.

Thanks.

Bug#907675: transition: x264

[Sebastian Ramacher]

On 2018-09-30 08:30:00, Niels Thykier wrote:
> Control: tags -1 confirmed pending
> 
> Sebastian Ramacher:
> > On 2018-08-31 11:01:21, Sebastian Ramacher wrote:
> >> Package: release.debian.org
> >> Severity: normal
> >> User: release.debian@packages.debian.org
> >> Usertags: transition
> >> Control: forwarded -1 
> >> https://release.debian.org/transitions/html/auto-x264.html
> >> Control: block -1 by 907659
> >>
> >> x264 bumped its SONAME and needs a transition. Besides opal (not in 
> >> testing due
> >> to another build failure, #896893), nageru is the only blocker (#907659). 
> >> nageru
> >> has a patch and the maintainer is looking at it.
> > 
> > I've uploaded it to sid and it built everywhere. Please schedule the 
> > binNMUs. If
> > you need help, I'd be happy to them on my own.
> > 
> > Cheers
> > 
> 
> I have scheduled binNMUs for this transition.  Please check up on them
> tomorrow and see if there are unexpected issues.

Thank you. Please give back ffmpeg with dep wait on libsdl2-dev >=
2.0.8+dfsg1-3.1 (failed due to ##909778) and also schedule the binNMUs for
nageru.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#909958: network-manager: USB Tethering Connection Always Immediately Started - Cannot Turn Off

[Hans Streibel]

Package: network-manager
Version: 1.6.2-3
Severity: normal

Dear Maintainer,

I connect my PC (Debian9, Stretch) to the Internet via my mobile phone,
attached to my PC via a USB cable. Thus I use Tethering on my mobile phone.
Attaching the mobile phone this way to my PC gives me a USB network connection.

I configured that USB connection via the NetworkManager and told it NOT to
start the connection automatically. Connection name: "USB Samsung Galaxy S8".
And yes, its MAC address is correct.

Reboot.

When I plug-in the mobile phone (tethering connection) then I
immediately get a connection to the Internet, therefore:
- error: It was not configured so.

This might be a matter for the "network-manager-gnome package", I am not sure:
- the NetworkManager icon on the desktop gives the impression that I am
  not connected to the Internet (but well, in fact, I am): error
- Selecting the NetworkManager menu item "Ethernet Connected" shows up the
  sub menu item item:
  - Connect
  So what? I am already connected! Error.
  Clicking that menu item does not do anything.

Another option in the menu mentioned above is "Ethernet Connected -> Wired 
Settings".
When I select this menu item then I get a new window "Network" where the first 
item is
"USB Ethernet". Its menu topics are:
- USB Samsung Galaxy S8
  Last used: 7 days ago.
  What?! I am using it right now. At least I intend to use it right now.
  Yes, its MAC address is correct.
  Error.
- Ethernet
  This is my local cable connected Ethernet.
  Why is it shown here? I see a menu item "PCI Ethernet Connected" in my
  Desktop Menu, where it is mentioned, too. In my impression that is where it
  belongs.
  Anyway, that entry does not disturb here. Hopefully.
  Error?
- Wired Connection 1
  Where does this menu item come from? Who set it up? I did'nt.
  So it must have been set up automatically. It uses the default feature
  "auto-connect" which explains the behaviour that I am connected immediately.
  Obviously this is what is actually used for my mobile connection.
  Who set it up, and why? I personally did not configured that connection.
  The connection "USB Samsung Galaxy S8" should be used instead.
  Error
  BTW:
  There is no file for this connection "Wired Connection 1" in
  /etc/NetworkManager/system-connections

Hans


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

Kernel: Linux 4.9.0-8-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 network-manager depends on:
ii  adduser3.115
ii  dbus   1.10.26-0+deb9u1
ii  init-system-helpers1.48
ii  libaudit1  1:2.6.7-2
ii  libbluetooth3  5.43-2+deb9u1
ii  libc6  2.24-11+deb9u3
ii  libglib2.0-0   2.50.3-2
ii  libgnutls303.5.8-5+deb9u3
ii  libgudev-1.0-0 230-3
ii  libjansson42.9-1
ii  libmm-glib01.6.4-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.19-1+b1
ii  libnl-3-2003.2.27-2
ii  libnm0 1.6.2-3
ii  libpam-systemd 232-25+deb9u4
ii  libpolkit-agent-1-00.105-18
ii  libpolkit-gobject-1-0  0.105-18
ii  libreadline7   7.0-3
ii  libselinux12.6-3+b3
ii  libsoup2.4-1   2.56.0-2+deb9u2
ii  libsystemd0232-25+deb9u4
ii  libteamdctl0   1.26-1+b1
ii  libuuid1   2.29.2-1+deb9u1
ii  lsb-base   9.20161125
ii  policykit-10.105-18
ii  udev   232-25+deb9u4
ii  wpasupplicant  2:2.4-1+deb9u1

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base 2.76-5+deb9u1
ii  iptables 1.6.0+snapshot20161117-6
ii  iputils-arping   3:20161105-1
ii  isc-dhcp-client  4.3.5-3+deb9u1
ii  modemmanager 1.6.4-1
ii  ppp  2.4.7-1+4

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

Bug#909740: Bug#909778: libsdl2-dev: SDL_config.h no longer in cflags provided by pkg-config/sdl2-config

[Simon McVittie]

Control: reopen 909740
Control: found 909740 2.0.8+dfsg1-2
Control: fixed 909740 2.0.8+dfsg1-3
Control: found 909740 2.0.8+dfsg1-3.1

On Sun, 30 Sep 2018 at 17:44:10 +0200, Manuel A. Fernandez Montecelo wrote:
> Em dom, 30 de set de 2018 às 16:57, Simon McVittie  escreveu:
> > For the short term, I'm preparing a NMU that reverts the multiarch change
> > and adds an autopkgtest that confirms that the package is usable, because
> > libsdl2-dev is currently unusable, and that's a considerably worse bug
> > than not being multiarch-friendly.
> 
> For the record: I spoke to Simon and acked the NMU with no delay, to
> avoid affecting more packages.

I've uploaded without delay as requested. Please merge
https://salsa.debian.org/sdl-team/libsdl2/merge_requests/1 or see attached.

smcv
diffstat for libsdl2-2.0.8+dfsg1 libsdl2-2.0.8+dfsg1

 changelog   |   10 +++
 control |1 
 copyright   |2 +
 libsdl2-dev.install |1 
 rules   |5 ---
 tests/build |   70 
 tests/control   |3 ++
 7 files changed, 85 insertions(+), 7 deletions(-)

diff -Nru libsdl2-2.0.8+dfsg1/debian/changelog libsdl2-2.0.8+dfsg1/debian/changelog
--- libsdl2-2.0.8+dfsg1/debian/changelog	2018-09-27 15:21:47.0 +0100
+++ libsdl2-2.0.8+dfsg1/debian/changelog	2018-09-30 16:13:38.0 +0100
@@ -1,3 +1,13 @@
+libsdl2 (2.0.8+dfsg1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/tests/build: Add autopkgtest to check that dynamic linking with
+either pkg-config or sdl2-config works correctly
+  * Revert "Make libsdl2-dev coinstallable again"
+(Closes: #909778) (reopens: #909740)
+
+ -- Simon McVittie   Sun, 30 Sep 2018 16:13:38 +0100
+
 libsdl2 (2.0.8+dfsg1-3) unstable; urgency=medium
 
   [ Hugh McMaster  ]
diff -Nru libsdl2-2.0.8+dfsg1/debian/control libsdl2-2.0.8+dfsg1/debian/control
--- libsdl2-2.0.8+dfsg1/debian/control	2018-09-27 15:20:43.0 +0100
+++ libsdl2-2.0.8+dfsg1/debian/control	2018-09-30 16:13:38.0 +0100
@@ -66,7 +66,6 @@
 Package: libsdl2-dev
 Section: libdevel
 Architecture: any
-Multi-Arch: same
 Depends:
  libasound2-dev [linux-any],
  libdbus-1-dev,
diff -Nru libsdl2-2.0.8+dfsg1/debian/copyright libsdl2-2.0.8+dfsg1/debian/copyright
--- libsdl2-2.0.8+dfsg1/debian/copyright	2018-09-27 15:19:31.0 +0100
+++ libsdl2-2.0.8+dfsg1/debian/copyright	2018-09-30 16:13:38.0 +0100
@@ -113,6 +113,8 @@
2002-2007, Josselin Mouette 
2001, Christian T. Steigies 
2001, Branden Robinson 
+   2012, Canonical Ltd.
+   2018, Simon McVittie
 License: LGPL-2.1+
 
 License: SGI-Free-Software-License-B
diff -Nru libsdl2-2.0.8+dfsg1/debian/libsdl2-dev.install libsdl2-2.0.8+dfsg1/debian/libsdl2-dev.install
--- libsdl2-2.0.8+dfsg1/debian/libsdl2-dev.install	2018-09-27 15:20:49.0 +0100
+++ libsdl2-2.0.8+dfsg1/debian/libsdl2-dev.install	2018-09-30 16:13:38.0 +0100
@@ -1,5 +1,4 @@
 usr/bin/sdl2-config
-usr/include/*/SDL2
 usr/include/SDL2
 usr/lib/*/cmake/SDL2/sdl2-config.cmake
 usr/lib/*/libSDL2*.so
diff -Nru libsdl2-2.0.8+dfsg1/debian/rules libsdl2-2.0.8+dfsg1/debian/rules
--- libsdl2-2.0.8+dfsg1/debian/rules	2018-09-27 15:20:51.0 +0100
+++ libsdl2-2.0.8+dfsg1/debian/rules	2018-09-30 16:13:38.0 +0100
@@ -69,11 +69,6 @@
 	rm -f debian/examples.tar.gz
 	rm -rf output
 
-override_dh_install:
-	mkdir -p debian/tmp/usr/include/$(DEB_HOST_MULTIARCH)/SDL2
-	mv debian/tmp/usr/include/SDL2/SDL_config.h debian/tmp/usr/include/$(DEB_HOST_MULTIARCH)/SDL2
-	dh_install
-
 override_dh_missing:
 	dh_missing --fail-missing -XlibSDL2.la -XlibSDL2main.la -XlibSDL2_test.la
 
diff -Nru libsdl2-2.0.8+dfsg1/debian/tests/build libsdl2-2.0.8+dfsg1/debian/tests/build
--- libsdl2-2.0.8+dfsg1/debian/tests/build	1970-01-01 01:00:00.0 +0100
+++ libsdl2-2.0.8+dfsg1/debian/tests/build	2018-09-30 16:13:38.0 +0100
@@ -0,0 +1,70 @@
+#!/bin/sh
+# autopkgtest check: Build and run a program against SDL, to verify that the
+# headers and pkg-config file are installed correctly
+#
+# Based on glib2.0's debian/tests/build
+# (C) 2012 Canonical Ltd.
+# (C) 2018 Simon McVittie
+# Authors: Martin Pitt, Simon McVittie
+
+set -eux
+
+# Ideally this test could be re-run with mode=static. However, statically
+# linking libSDL2 doesn't actually work, because there is no libasound.a
+# in libasound-dev (since 1.0.27-3 in 2013).
+mode=dynamic
+
+WORKDIR=$(mktemp -d)
+trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
+cd $WORKDIR
+cat < use-sdl.c
+#undef NDEBUG
+#include 
+
+#include 
+
+int main(void)
+{
+SDL_version compiled;
+SDL_version linked;
+
+SDL_VERSION();
+SDL_GetVersion();
+
+assert(compiled.major == 2);
+assert(linked.major == 2);
+
+return 0;
+}
+EOF
+
+for tool in pkg-config sdl2-config; do
+cflags=
+pcflags=
+scflags=--libs
+
+case "$mode" in
+(static)
+

Bug#909735: yaml-cpp: Please update d/watch file so that new version can be detected

[Jean Baptiste Favre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Change already committed in VCS.

On 9/27/18 2:59 PM, Jean Baptiste Favre wrote:
> Source: yaml-cpp Severity: normal Tags: patch
> 
> Dear Maintainer,
> 
> Current debian/watch does not detect new versions anymore. An
> upstream change makes the filenamemangle option obsolete.
> 
> PLease find attached a patch to get a working debian/watch
> 
> Cheers, Jean Baptiste Favre
> 
> -- System Information: Debian Release: buster/sid APT prefers
> unstable APT policy: (500, 'unstable'), (500, 'testing'), (500,
> 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign
> Architectures: i386
> 
> Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale:
> LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to
> /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor:
> enabled
> 
> 

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEToRbojDLTUSJBphHtN1Tas99hzcFAluw8VNfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDRF
ODQ1QkEyMzBDQjRENDQ4OTA2OTg0N0I0REQ1MzZBQ0Y3RDg3MzcACgkQtN1Tas99
hzeTmhAAx7A5fnIliv3BP88ULJmSBEO6UuddAfwEFmhyOt7GZpodQrA4zgzMYBYh
pgx2s0QqJpmEIk6ScvvwPrmz1SHMGuDsAzbBp6ok4rqRRmuK/8xSoMvVxWVIq9nQ
/Ti5/0fmrnEN1l7NWR/2IjHyBtPl6vcTCiVb1RrHDsA7MwceXXeCyfKu5vkZIi3/
qk5er7H4dgw0nj+Pj2V2AquQDNGKqJlmz939KrhSoNIfgPWt83SxdbCJAU44bk3F
QazONEu6QRnWQF5uBVgCt93cdaZSHZst30eoFV7ZySVg779voxlxmsfsCmrDg7+I
doqJ8YVT3/yGh7AFp8fPASE/7cKgCYNb4SXqV5Q181mJN097xRjjgeRVRdB8w3ME
Uda58c3GkT/SVEmuCgbaxT56UNSuRDsBlwdDsb8HytOMeMyEBZ3kwZrRQQ0PpRAK
L1z6U9raOn93dqllxaVuH7Q+7CvrmFHRWYioOgZR6QlVHYcmZvXZEXtvInf/Alj+
oLH12qz2rpGk3WT0vLCSBxRS/IW+Vjz2vDU4d4caun7Nxiqbjbzx97/hM6bb4/28
m/Cql/pT3OeEU4SHjexeepUv/nbfKH4jAwNNaq5FJNH+cBR2kGyvDg43szrypo/u
xnaccsqWngPHjoeOcI6CFCriBXbDKNZOdmkIhtXDu9bqNKF5b5E=
=7TCz
-END PGP SIGNATURE-

Bug#909957: Regression in ghostscript when using pstoedit (/undefined in --setpagedevice--)

[Milan Holzäpfel]

Package: ghostscript
Version: 9.20~dfsg-3.2+deb9u5

After upgrade from ghostscript 9.20~dfsg-3.2+deb9u2 to 9.20~dfsg-3.2+deb9u5, 
pstoedit with the option "-psarg -r9600x9600" no longer works. The following 
commands can be used to reproduce the issue:


$ cat test.tex
\documentclass{article}
\begin{document}
text
\end{document}
$ pdflatex test.tex &> /dev/null
$ pstoedit -f plot-svg test.pdf test.svg -psarg -r9600x9600 
pstoedit: version 3.70 / DLL interface 108 (built: Oct 11 2016 - release build 
- g++ 6.2.1 20161215 - 64-bit) : Copyright (C) 1993 - 2014 Wolfgang Glunz
Error: /undefined in --setpagedevice--
Operand stack:
   false   --dict:1/1(L)--   --nostringval--   --dict:75/148(ro)(L)--   
--dict:1/1(L)--   --dict:5/76(L)--   --dict:5/76(L)--   HWResolution
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--   
--nostringval--   false   1   %stopped_push   1998   1   3   %oparray_pop   
1997   1   3   %oparray_pop   1981   1   3   %oparray_pop   1868   1   3   
%oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   
--nostringval--   --nostringval--   2   %stopped_push   --nostringval--   
--nostringval--   1961   1   3   %oparray_pop   --nostringval--
Dictionary stack:
   --dict:1213/1684(ro)(G)--   --dict:0/20(G)--   --dict:297/300(L)--
Current allocation mode is local
Last OS error: No such file or directory
Current file position is 85493
GPL Ghostscript 9.20: Unrecoverable error, exit code 1
PostScript/PDF Interpreter finished. Return status 256 executed command : 
/usr/bin/gs -q -dDELAYBIND -dWRITESYSTEMDICT -dNODISPLAY -dNOEPS -r9600x9600 
"/tmp/psinSrgqgy"
The interpreter seems to have failed, cannot proceed !
$ gs -v
GPL Ghostscript 9.20 (2016-09-26)
Copyright (C) 2016 Artifex Software, Inc.  All rights reserved.
joe@lenny ~/test $ dpkg -l ghostscript
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersionArchitecture 
  Description
+++-===-==-==-
ii  ghostscript 9.20~dfsg-3.2+deb9u5   amd64
  interpreter for the PostScript language and for PDF
$


After downgrading, the pstoedit command works as expected:


$ cat test.tex
\documentclass{article}
\begin{document}
text
\end{document}
$ pdflatex test.tex &> /dev/null
$ pstoedit -f plot-svg test.pdf test.svg -psarg -r9600x9600 
pstoedit: version 3.70 / DLL interface 108 (built: Oct 11 2016 - release build 
- g++ 6.2.1 20161215 - 64-bit) : Copyright (C) 1993 - 2014 Wolfgang Glunz
libplot: cannot retrieve font "JQDFPK+CMR10", using default "Helvetica"
$ gs -v
GPL Ghostscript 9.20 (2016-09-26)
Copyright (C) 2016 Artifex Software, Inc.  All rights reserved.
$ dpkg -l ghostscript 
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersionArchitecture 
  Description
+++-===-==-==-
ii  ghostscript 9.20~dfsg-3.2+deb9u2   amd64
  interpreter for the PostScript language and for PDF
$ 


Downgrade was performed with

apt install ghostscript=9.20~dfsg-3.2+deb9u2 libgs9=9.20~dfsg-3.2+deb9u2 
libgs9-common=9.20~dfsg-3.2+deb9u2 

As pstoedit works normally after downgrading ghostscript, I assume it is a 
regression in ghostscript. Could this be related to the regression fix 
mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908300 ?

This is on Debian 9 with pstoedit 3.70-3+b2. 

Bug#909778: libsdl2-dev: SDL_config.h no longer in cflags provided by pkg-config/sdl2-config

[Manuel A. Fernandez Montecelo]

Hi,

Em dom, 30 de set de 2018 às 16:57, Simon McVittie  escreveu:
>
> For the short term, I'm preparing a NMU that reverts the multiarch change
> and adds an autopkgtest that confirms that the package is usable, because
> libsdl2-dev is currently unusable, and that's a considerably worse bug
> than not being multiarch-friendly.

For the record: I spoke to Simon and acked the NMU with no delay, to
avoid affecting more packages.

Thanks Simon for fixing this!

-- 
Manuel A. Fernandez Montecelo 

Bug#909955: RFS: libt3widget/0.6.4-1

[Gertjan Halkes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: libt3widget
  Version : 0.6.4-1
  Upstream Author : Gertjan Halkes 
* URL : https://os.ghalkes.nl/t3/libt3widget.html
* License : GPLv3
  Section : libs

It builds those binary packages:

  libt3widget-dev - Development files for libt3widget
  libt3widget1 - C++ terminal dialog toolkit

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

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

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

dget -x
https://mentors.debian.net/debian/pool/main/libt/libt3widget/libt3widget_0.6.4-1.dsc

Changes since the last upload:

  * New upstream release.

Regards,
  Gertjan Halkes

Bug#909956: gitit: wrong Homepage

[Jonas Smedegaard]

Package: gitit
Version: 0.12.2.1+dfsg-2+b1
Severity: minor

Package lists http://gitit.net as Homepage - but that page is empty.

 - Jonas

Bug#909274: jansson: Please consider building jansson with -fPIC

[Jean Baptiste Favre]

Hello Alessandro,
You're right. The issue was on Trafficserver side.
Libjansson and libsjose were wrongly detected as static.
I fixed the issue and forwarded the patch upstream.

Thanks,
Jean Baptiste

On 9/22/18 5:49 PM, Alessandro Ghedini wrote:
> On Thu, Sep 20, 2018 at 09:09:39PM +0200, Jean Baptiste Favre wrote:
>> Source: jansson
>> Severity: wishlist
>>
>> Dear Maintainer,
>>
>> Next release of trafficserver provides a plugin depending on jansson.
>> Currently, jansson seems to be built staticaly:
>>
>> checking jansson.h usability... yes
>> checking jansson.h presence... yes
>> checking for jansson.h... yes
>> checking whether jansson is dynamic... no
>>
>> It also doen't use -fPIC, which prevent its use with trafficserver:
>>
>> libtool: link:  cc -shared  -fPIC -DPIC
>> experimental/uri_signing/.libs/uri_signing.o
>> experimental/uri_signing/.libs/config.o
>> experimental/uri_signing/.libs/cookie.o
>> experimental/uri_signing/.libs/jwt.o
>> experimental/uri_signing/.libs/match.o
>> experimental/uri_signing/.libs/parse.o
>> experimental/uri_signing/.libs/timing.o   -l:libjansson.a -l:libcjose.a
>> -lpcre -lm -lcrypto -lbrotlienc -lpthread -ldl  -g -mcx16 -g -O2
>> -fstack-protector-strong -O3 -Wl,-z -Wl,relro -Wl,-z -Wl,now
>> -Wl,-soname -Wl,uri_signing.so -Wl,-version-script
>> -Wl,experimental/uri_signing/.libs/uri_signing.ver -o
>> experimental/uri_signing/.libs/uri_signing.so
>> /usr/bin/ld:
>> /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libjansson.a(load.o):
>> relocation R_X86_64_PC32 against symbol `stdin@@GLIBC_2.2.5' can not be
>> used when making a shared object; recompile with -fPIC
>>
>> Could you please consider adding this flag ?
> 
> AFAICT jansson is already built with -fPIC, see build logs:
> https://buildd.debian.org/status/fetch.php?pkg=jansson=amd64=2.11-1=1518387251=0
> https://buildd.debian.org/status/fetch.php?pkg=jansson=i386=2.11-1=1518387065=0
> 
> Cheers
> 




signature.asc
Description: OpenPGP digital signature

Bug#909954: arduino FTBFS: jh_linkjars: symlink(/usr/share/java/ant-1.10.5.jar, app/lib/ant-1.10.5.jar) failed: File exists

[Adrian Bunk]

Package: javatools
Version: 0.66
Severity: serious
Control: affects -1 src:arduino

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

...
   debian/rules override_jh_build
make[1]: Entering directory '/build/1st/arduino-1.0.5+dfsg2'
jh_linkjars
jh_linkjars: symlink(/usr/share/java/ant-1.10.5.jar, app/lib/ant-1.10.5.jar) 
failed: File exists
make[1]: *** [debian/rules:22: override_jh_build] Error 17

Bug#909953: stretch-pu: package soundconverter/3.0.0~alpha1+git20151209-1+deb9u1

[Sebastian Ramacher]

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

Users requested a fix for #834598 (unable to encode as ogg) in stretch. It's
only a normal bug, but also only a one line change. Full diff is below. Please
let me know if it's okay to upload it.

Cheers


diff --git a/debian/changelog b/debian/changelog
index 8be335b..f3fc43e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+soundconverter (3.0.0~alpha1+git20151209-1+deb9u1) stretch; urgency=medium
+
+  * debian/gbp.conf: Work on stretch branch.
+  * debian/patches: Apply upstream patch to fix opus vbr setting. (Closes:
+#834598)
+
+ -- Sebastian Ramacher   Sun, 30 Sep 2018 17:29:01 +0200
+
 soundconverter (3.0.0~alpha1+git20151209-1) unstable; urgency=medium
 
   * New upstream snapshot.
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 1270436..14695eb 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,4 +1,4 @@
 [DEFAULT]
 pristine-tar = True
-debian-branch = master
+debian-branch = stretch
 upstream-branch = upstream
diff --git a/debian/patches/0001-Fix-opus-vbr-setting.patch 
b/debian/patches/0001-Fix-opus-vbr-setting.patch
new file mode 100644
index 000..3e794f3
--- /dev/null
+++ b/debian/patches/0001-Fix-opus-vbr-setting.patch
@@ -0,0 +1,22 @@
+From: kassoulet 
+Date: Fri, 2 Sep 2016 21:33:16 +0200
+Subject: Fix opus vbr setting
+
+Closes lp:1097610, thanks Alexander.
+---
+ soundconverter/gstreamer.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/soundconverter/gstreamer.py b/soundconverter/gstreamer.py
+index fe4d890..4d37ff8 100644
+--- a/soundconverter/gstreamer.py
 b/soundconverter/gstreamer.py
+@@ -630,7 +630,7 @@ class Converter(Decoder):
+ return 'faac bitrate=%s ! mp4mux' % (self.aac_quality * 1000)
+ 
+ def add_opus_encoder(self):
+-return 'opusenc bitrate=%s cbr=false bandwidth=auto ! oggmux' % 
(self.opus_quality * 1000)
++return 'opusenc bitrate=%s bitrate-type=vbr bandwidth=auto ! oggmux' 
% (self.opus_quality * 1000)
+ 
+ def add_audio_profile(self):
+ pipeline = audio_profiles_dict[self.audio_profile][2]
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..6a12c25
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+0001-Fix-opus-vbr-setting.patch

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#909952: RFP: bitlbee-mastodon -- Mastodon plugin for bitlbee IRC gateway

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: bitlbee-mastodon
  Version : 1.4.0
  Upstream Author : Alex Schroeder
* URL : https://alexschroeder.ch/software/Bitlbee_Mastodon
* License : GPL-2.1
  Programming Lang: C
  Description : Mastodon plugin for bitlbee IRC gateway

This plugin allows Bitlbee to communicate with Mastodon
instances. Mastodon is a free, open-source, decentralized
microblogging network. Bitlbee is an IRC server connecting to various
other text messaging services. You run Bitlbee and connect to it using
an IRC client, then configure Bitlbee to connect to other services,
such as a Mastodon instance where you already have an account. The
benefit is that you can now use any IRC client you want to connect to
Mastodon.

==

I've been using this for a while now and it works generally well,
although it doesn't have all the features of its equivalent Twitter
plugin (e.g. it replays old entries on reconnect).

I'd be happy to maintain, co-maintain, or see someone else package
this, but I'm not sure in which team it would belong.

Bug#909250: HPLIP - scanner HP_LaserJet_M1120n_MFP

[Brian Potkin]

Thank you for your report, Tancredi-Paul.


On Thu 20 Sep 2018 at 13:56:43 +0300, Tancredi-Paul Grozav wrote:

> Package: hplip
> Version: 3.16.11+repack0-3
> 
> I can not scan an image from a HP LaserJet M1120n MFP.
> I am using the hplip package provided by debian( HP Linux Imaging and
> Printing System (ver. 3.16.11))
> 
> Here is a transcript:
> root@scanner:/# SANE_DEBUG_DLL=255 SANE_DEBUG_NET=128 hp-scan
> ...
> [dll] load: searching backend `hpaio' in
> `/usr/lib/x86_64-linux-gnu/sane:/usr/lib/sane'
> [dll] load: trying to load `/usr/lib/x86_64-linux-gnu/sane/libsane-hpaio.so.1'
> [dll] load: dlopen()ing `/usr/lib/x86_64-linux-gnu/sane/libsane-hpaio.so.1'
> [dll] init: initializing backend `hpaio'
> [dll] init: backend `hpaio' is version 1.0.0
> [dll] sane_get_devices: found 1 devices
> Using device hpaio:/net/HP_LaserJet_M1120n_MFP?ip=192.168.200.16

Ok up to here.

> Opening connection to device...
> [dll] sane_open: trying to open
> `hpaio:/net/HP_LaserJet_M1120n_MFP?ip=192.168.200.16'
> error: SANE: Error during device I/O (code=9)

Things go wrong!

> root@scanner:/# tail /var/log/syslog
> Sep 20 13:49:20 scanner /hp-scan: hp-scan[260]: warning: hp-scan
> should not be run as root/superuser.
> Sep 20 13:49:29 scanner /hp-scan: io/hpmud/pp.c 627: unable to read
> device-id ret=-1
> Sep 20 13:49:30 scanner /hp-scan: hp-scan[260]: warning: No
> destinations specified. Adding 'file' destination by default.

Nothing to worry about. hp-scan will use hpscanxxx.png as the filename.

> Sep 20 13:49:39 scanner /hp-scan: io/hpmud/pp.c 627: unable to read
> device-id ret=-1

Looks worrying.

> Sep 20 13:49:40 scanner /hp-scan: common/utils.c 188: unable to load
> library libm.so: libm.so: cannot open shared object file: No such file
> or directory

libm.so isn't on my i386 system and scanning with hp-scan works. It is
in libc6-dev and this package wouldn't normally be installed (because
it is a -dev). I don't know how significant the message is.

> Sep 20 13:50:25 scanner /hp-scan: io/hpmud/jd.c 678: timeout
> read_channel sec=45 hp:/net/HP_LaserJet_M1120n_MFP?ip=192.168.200.16
> Sep 20 13:50:25 scanner /hp-scan: bb_marvell.c 346: invalid get_msg
> tmo=45 total=0 uri=hp:/net/HP_LaserJet_M1120n_MFP?ip=192.168.200.16
> Sep 20 13:50:25 scanner /hp-scan: hp-scan[260]: error: SANE: Error
> during device I/O (code=9)

[Snipped. Printing isn't really relevant.]

>  Can we add support for this? Or am I doing something wrong? The same
> command worked for this other printer: hp:/net/HP_LaserJet_3052
> 
> Info about my computer:
> root@scanner:/# cat /etc/debian_version
> 9.4
> root@scanner:/# uname -a
> Linux scanner.docker.paul.grozav.info 4.9.0-8-amd64 #1 SMP Debian
> 4.9.110-3+deb9u4 (2018-08-21) x86_64 GNU/Linux
> 
> The machine runs inside docker:
> pgrozav:~>docker version
> Client:
>  Version:   18.06.1-ce
>  API version:   1.38
>  Go version:go1.10.3
>  Git commit:e68fc7a
>  Built: Tue Aug 21 17:23:18 2018
>  OS/Arch:   linux/amd64
>  Experimental:  false
> 
> Server:
>  Engine:
>   Version:  18.06.1-ce
>   API version:  1.38 (minimum version 1.12)
>   Go version:   go1.10.3
>   Git commit:   e68fc7a
>   Built:Tue Aug 21 17:22:21 2018
>   OS/Arch:  linux/amd64
>   Experimental: false

I know nothing about Docker and containers

> I must say that the same problem occurs on the physical machine,

so this is useful to know.

> outside of docker. And I also have another container that is able to
> scan from hp:/net/HP_LaserJet_3052 .

The only package needed to scan over the network is libsane-hpaio. You
could install it in a container without its recommended packages
(--no-install-recommends) and try

hp-scan -d hpaio:/net/HP_LaserJet_M1120n_MFP?ip=192.168.200.16

and

scanimage -d hpaio:/net/HP_LaserJet_M1120n_MFP?ip=192.168.200.16 > image.pnm

(Obtain the correct plugin from

https://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/

Then

sh hplip--plugin.run --tar vxf

and

python installPlugin.py).

Regards,

Brian.

Bug#907829: p4est: FTBFS on single CPU machines

[Adrian Bunk]

On Sun, Sep 30, 2018 at 04:36:25PM +0200, Santiago Vila wrote:
> On Sun, Sep 30, 2018 at 04:32:17PM +0300, Adrian Bunk wrote:
>...
> But surely that's not an excuse good enough to deprecate Debian on
> single-core systems, which is what you apparently are trying to do
> here.
> 
> As far as following blindly the rule you say results in something as
> grave and deep as deprecating Debian on single-core systems,
>...

Please stop these unfounded accusations.

Noone is talking about no longer supporting running Debian on 
single-core systems.

Building all packages on the baseline is never possible, and I already 
tried to explain to you that your "1 CPU with unlimited RAM" scenario is 
pretty far away from the real-world problems.

A Raspberry Pi is a quad-core faster than our current armel/armhf buildds.
But ARM hardware with >= 8 GB RAM is prohibitively expensive.

> > Feel free to ask the release team for a definite statement on that
> > if you think I am misunderstanding the position of the release team.
> 
> So what are we really discussing about, severity or RC-ness?
> 
> They are related but they are not exactly the same.
> 
> Is it your claim in this bug that it should not be serious, or you
> agree that it's serious and you only claim that it should not be RC?

You don't make sense here.

"serious" is an RC bug severity.

> I ask because some time ago I was going to report FTBFS bugs on
> unbuildable packages (because of unmet build-depends) and you told me
> that it was too early in the release cycle of buster for that.

This was about not reporting issues *that are not present in unstable*.

It doesn't make sense that other people spend time debugging problems 
that are already fixed in unstable and where the fix might migrate to
testing in a few days.

> Thanks.

cu
Adrian

-- 

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

Bug#909942: mmdebstrap: breaks system it runs on, power cycle needed.

[Andreas Henriksson]

On Sun, Sep 30, 2018 at 04:49:07PM +0200, Andreas Henriksson wrote:
[...]
> > - cgroup mounts dissapearing
[...]

So a simple test like this (similar as what can be seen used in the
code) reveals the problem with all /sys sub-mounts dissapearing:

mount | grep /sys

mkdir /tmp/test
mount --rbind /sys /tmp/test

mount | grep /sys

umount --lazy --recursive /tmp/test

mount | grep /sys


(The same problem doesn't seem to occur without the --lazy flag, but
then mount errors out after doing most of the job.)

Regards,
Andreas Henriksson