Bug#887585: stealth: missing build dependency on texlive-latex-extra

[Adrian Bunk]

Source: stealth
Version: 4.01.09-1
Severity: serious

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

...
No post-processing required for this latex conversion
cp stealth.sty ../../tmp/manual/LaTeX
latex stealth.latex
This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) 
(preloaded format=latex)
 restricted \write18 enabled.
entering extended mode
(./stealth.latex
LaTeX2e <2017-04-15>
Babel <3.16> and hyphenation patterns for 3 language(s) loaded.
Original Yodl file: ../../release.yo
(/usr/share/texlive/texmf-dist/tex/latex/base/report.cls
Document Class: report 2014/09/29 v1.4h Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/generic/epsf/epsf.sty
This is `epsf.tex' v2.7.4 <14 February 2011>
) (./stealth.sty)
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/hobsub-hyperref.sty
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/hobsub-generic.sty))
(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
(/usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty)
(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/auxhook.sty)
(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/kvoptions.sty)
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def)
(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/hyperref.cfg)

Package hyperref Warning: Values of option `pdfpagemode':
(hyperref)* `UseNone'
(hyperref)* `UseOutlines'
(hyperref)* `UseThumbs'
(hyperref)* `FullScreen'
(hyperref)* `UseOC' (PDF 1.5)
(hyperref)* `UseAttachments' (PDF 1.6)
(hyperref)* An empty value disables the option.
(hyperref)Unknown value `None' on input line 4374.

(/usr/share/texlive/texmf-dist/tex/latex/url/url.sty))

Package hyperref Message: Driver (default): hdvips.

(/usr/share/texlive/texmf-dist/tex/latex/hyperref/hdvips.def
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/pdfmark.def
(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty)))
(/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/t1enc.def))

! LaTeX Error: File `makecell.sty' not found.

Type X to quit or  to proceed,
or enter new name. (Default extension: sty)

Enter file name: 
! Emergency stop.
 
 
l.23 ^^M

Bug#887581: c++-annotations FTBFS with yodl 4.02.00-2

[Frank B. Brokken]

Dear Adrian Bunk, you wrote:
> 
> Source: c++-annotations
> Version: 10.9.0-1
> Severity: serious
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/c++-annotations.html
> 
> ...
> yodl2txt --no-warnings -o ../tmp/docs/txt/cplusplus.txt -l3 cplusplus
> Yodl2html 4.02.00
> Yodl: including file preamble
> preamble.yo:208: DEFINEMACRO: `nbsp' multiply defined

Oops... Thanks: I'll fix that later today.

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA

Bug#887583: libjs-fetch FTBFS with mocha 4.0.1-3

[Adrian Bunk]

Source: libjs-fetch
Version: 2.0.3-1
Severity: serious

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

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/1st/libjs-fetch-2.0.3'
xvfb-run -a -s "-screen 0 640x480x16" ./script/test
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-pbuilder1'
Error loading resource http://localhost:3901/node_modules/mocha/mocha.css 
(203). Details: Error transferring 
http://localhost:3901/node_modules/mocha/mocha.css - server replied: Not Found
Error loading resource 
http://localhost:3901/node_modules/url-search-params/build/url-search-params.js 
(203). Details: Error transferring 
http://localhost:3901/node_modules/url-search-params/build/url-search-params.js 
- server replied: Not Found
Error loading resource http://localhost:3901/node_modules/mocha/mocha.js (203). 
Details: Error transferring http://localhost:3901/node_modules/mocha/mocha.js - 
server replied: Not Found
ReferenceError: Can't find variable: Mocha
ReferenceError: Can't find variable: suite
TypeError: mocha.run is not a function. (In 'mocha.run()', 'mocha.run' is 
undefined)
Likely due to external resource loading and timing, your tests require calling 
`window.initMochaPhantomJS()` before calling any mocha setup functions. See 
https://github.com/nathanboktae/mocha-phantomjs-core/issues/12
TypeError: Attempting to change the setter of an unconfigurable property.
TypeError: Attempting to change the setter of an unconfigurable property.
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-pbuilder1'
Error loading resource http://localhost:3901/node_modules/mocha/mocha.css 
(203). Details: Error transferring 
http://localhost:3901/node_modules/mocha/mocha.css - server replied: Not Found
Error loading resource 
http://localhost:3901/node_modules/url-search-params/build/url-search-params.js 
(203). Details: Error transferring 
http://localhost:3901/node_modules/url-search-params/build/url-search-params.js 
- server replied: Not Found
Error loading resource http://localhost:3901/node_modules/mocha/mocha.js (203). 
Details: Error transferring http://localhost:3901/node_modules/mocha/mocha.js - 
server replied: Not Found
ReferenceError: Can't find variable: Mocha
Likely due to external resource loading and timing, your tests require calling 
`window.initMochaPhantomJS()` before calling any mocha setup functions. See 
https://github.com/nathanboktae/mocha-phantomjs-core/issues/12
TypeError: Attempting to change the setter of an unconfigurable property.
TypeError: Attempting to change the setter of an unconfigurable property.
debian/rules:28: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1

Bug#887584: Constructing a special file can cause libfreeimage3 to crash

[wang yan]

Subject: Constructing a special file can cause libfreeimage3 to crash
Package: libfreeimage3
Version: 3.17.0+ds1-5
Tags: upstream
Severity: important

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

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

Versions of packages libfreeimage3 depends on:
ii  libc62.24-11+deb9u1
ii  libgcc1  1:6.3.0-18
ii  libilmbase12 2.2.0-12
ii  libjpeg62-turbo  1:1.5.1-2
ii  libjxr0  1.1-6+b1
ii  libopenexr22 2.2.0-11+b1
ii  libopenjp2-7 2.1.2-1.1+deb9u2
ii  libpng16-16  1.6.28-1
ii  libraw15 0.17.2-6+deb9u1
ii  libstdc++6   6.3.0-18
ii  libtiff5 4.0.8-2+deb9u1
ii  libwebp6 0.5.2-1
ii  libwebpmux2  0.5.2-1
ii  zlib1g   1:1.2.8.dfsg-5

root@debian:~/Desktop# dpkg --list libfreeimage3
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)
||/ Name   Version  Architecture Description
+++-==---=
ii  libfreeimage3: 3.17.0+ds1-5 amd64Support library for graphics imag


root@debian:/opt# ls
FreeImage_Fuzzer.c
root@debian:/opt# g++ FreeImage_Fuzzer.c 
/usr/lib/x86_64-linux-gnu/libfreeimage-3.17.0.so -o FreeImage_Fuzz
root@debian:/opt# ./FreeImage_Fuzz id_000196,sig_11,src_002098,op_flip1,pos_2
Segmentation fault
root@debian:/opt#

This Dos is suitable for all Freeimage applications.

Reference link:
https://sourceforge.net/projects/freeimage/





#include 
#include 
#include 
#include 
#include
using namespace std;  


#include "FreeImage.h"





FIBITMAP* GenericLoader(const char* lpszPathName, int flag) {
FREE_IMAGE_FORMAT fif = FIF_UNKNOWN;

// check the file signature and deduce its format
// (the second argument is currently not used by FreeImage)
fif = FreeImage_GetFileType(lpszPathName, 0);
if(fif == FIF_UNKNOWN) {
// no signature ?
// try to guess the file format from the file extension
fif = FreeImage_GetFIFFromFilename(lpszPathName);
}
// check that the plugin has reading capabilities ...
if((fif != FIF_UNKNOWN) && FreeImage_FIFSupportsReading(fif)) {
// ok, let's load the file
FIBITMAP *dib = FreeImage_Load(fif, lpszPathName, flag);
// unless a bad file format, we are done !
return dib;
}
return NULL;
}

/** Generic image writer
@param dib Pointer to the dib to be saved
@param lpszPathName Pointer to the full file name
@param flag Optional save flag constant
@return Returns true if successful, returns false otherwise
*/
bool GenericWriter(FIBITMAP* dib, const char* lpszPathName, int flag) {
FREE_IMAGE_FORMAT fif = FIF_UNKNOWN;
BOOL bSuccess = false;

if (dib) {
// try to guess the file format from the file extension
fif = FreeImage_GetFIFFromFilename(lpszPathName);
if (fif != FIF_UNKNOWN) {
// check that the plugin has sufficient writing and 
export capabilities ...
WORD bpp = FreeImage_GetBPP(dib);
if (FreeImage_FIFSupportsWriting(fif) && 
FreeImage_FIFSupportsExportBPP(fif, bpp)) {
// ok, we can save the file
bSuccess = FreeImage_Save(fif, dib, 
lpszPathName, flag);
// unless an abnormal bug, we are done !
}
}
}
return (bSuccess == true) ? true : false;
}

/**
FreeImage error handler
@param fif Format / Plugin responsible for the error
@param message Error message
*/
void FreeImageErrorHandler(FREE_IMAGE_FORMAT fif, const char *message) {
cout << "\n*** ";
if (fif != FIF_UNKNOWN) {
cout << FreeImage_GetFormatFromFIF(fif) << " Format\n";
}
cout << message;
cout << " ***\n";
}

bool FreeImage_Fuzzer(char* lpFileName)
{
// Load the bitmap
FIBITMAP *dib = GenericLoader(lpFileName, 0);
if (!dib)
return false;

int width = FreeImage_GetWidth(dib);
int height = FreeImage_GetHeight(dib);

FreeImage_Unload(dib);
return true;
}


int main(int argc, char *argv[])
{
// call this ONLY when linking with FreeImage as a static library
#ifdef FREEIMAGE_LIB
FreeImage_Initialise();
#endif // FREEIMAGE_LIB

// initialize your own FreeImage error handler

Bug#887571: [debhelper-devel] Bug#887571: debhelper: dh lies about what it does, breaks builds by creating new files, etc

[Norbert Preining]

Hi Niels,

> I suspect it might be the shell.  Make resets SHELL to /bin/sh AFAIR and
> the error smells like a bashism with a non-bash shell.

> export CONFIG_SHELL=/bin/sh

This has been there since around 6 years ... so I am a bit surprised
that this might have an influence, but I am retesting just now ...

Thanks

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#887582: FTBFS: test suite failures on 32-bit arches

[Tristan Seligmann]

Source: fish
Version: 2.7.1-2
Severity: serious
Tags: upstream
Justification: FTBFS

The test suite is failing on 32-bit arches in a somewhat inscrutable way. I am
investigating this but filing a bug to track the status so long.

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

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

-- no debconf information

Bug#887571: [debhelper-devel] Bug#887571: debhelper: dh lies about what it does, breaks builds by creating new files, etc

[Niels Thykier]

Niels Thykier:
> Control: tags -1 moreinfo
> 
> Norbert Preining:
>> Package: debhelper
>> Version: 11.1.2
>> Severity: serious
>> Justification: breaks other packages
>>
>> Dear DebHelper developers,
>>
>> thanks for your efforts, but it would be very helpful if debhelper/dh
>> would stick to what itself says it is doing.
>>
>> I am trying to build texlive-bin, and somewhere at/around the configure
>> stage files
>>   configure.lineno
>> are created, which break building:
>>   checking whether g++ accepts -g... no
>>   checking dependency style of g++... none
>>   checking what warning flags to pass to the Objective C++ compiler...
>>   ../../../texk/web2c/configure: 20010: ./configure.lineno: Syntax error: 
>> Bad fd number
>>   === configuring in web2c failed
>>
>> I confirmed the following:
>> * doing the same invocation of configure manually does NOT create
>>   configure.lineno and the build succeeds.
> 
> I suspect it might be the shell.  Make resets SHELL to /bin/sh AFAIR and
> the error smells like a bashism with a non-bash shell.
> 
> Could you please retest with "export SHELL=/bin/bash" set in your
> debian/rules (or a SHELL=/bin/bash in front of the dh_auto_configure call).
> 

Ah, just noticed you have the following in top of the rules file which
makes my above statement redundant.

"""
#!/usr/bin/make -f
# debian/rules file for texlive-bin

export SHELL=/bin/bash
export CONFIG_SHELL=/bin/sh
"""

 * When you test manually, do you also set CONFIG_SHELL to /bin/sh?
   (Just to eliminate a source of error/difference)

Thanks,
~Niels

Bug#887571: [debhelper-devel] Bug#887571: debhelper: dh lies about what it does, breaks builds by creating new files, etc

[Niels Thykier]

Control: tags -1 moreinfo

Norbert Preining:
> Package: debhelper
> Version: 11.1.2
> Severity: serious
> Justification: breaks other packages
> 
> Dear DebHelper developers,
> 
> thanks for your efforts, but it would be very helpful if debhelper/dh
> would stick to what itself says it is doing.
> 
> I am trying to build texlive-bin, and somewhere at/around the configure
> stage files
>   configure.lineno
> are created, which break building:
>   checking whether g++ accepts -g... no
>   checking dependency style of g++... none
>   checking what warning flags to pass to the Objective C++ compiler...
>   ../../../texk/web2c/configure: 20010: ./configure.lineno: Syntax error: Bad 
> fd number
>   === configuring in web2c failed
> 
> I confirmed the following:
> * doing the same invocation of configure manually does NOT create
>   configure.lineno and the build succeeds.

I suspect it might be the shell.  Make resets SHELL to /bin/sh AFAIR and
the error smells like a bashism with a non-bash shell.

Could you please retest with "export SHELL=/bin/bash" set in your
debian/rules (or a SHELL=/bin/bash in front of the dh_auto_configure call).

> * what dh says it is doing with 
> dh binary --no-act ...
>   is *different* from what is actually happening, since doing the exact
>   same things as listed by dh binary --no-act immediately breaks
> 
> Example for this (the reautoconf stage has already been done):
>   $ dh binary --no-act --with autoreconf --builddirectory Work
>   debian/rules override_dh_auto_configure
>   dh_auto_build -O--builddirectory=Work
>   dh_auto_test -O--builddirectory=Work
> > [...]
> 
> Best
> 
> Norbert
> 
> [...]

The missing options/incomplete cmd-line is related to #552276.

Thanks,
~Niels

Bug#838809: spam: [testing] my report is spam so please just ignore

[황병희]

For detail test, i send again followup message, sorry again... final test
at this PR.

On Thu, 18 Jan 2018 16:04:46 +0900 =?UTF-8?B?7Zmp67OR7Z2s?= <
soyeo...@doraji.xyz> wrote:
> X-Debbugs-CC: soyeo...@gmail.com
>
> For now i'm working for translation BTS section, so please ignore ...
>
> On Sun, 25 Sep 2016 18:37:54 +0900 Byung-Hee HWANG 
> wrote:
> > Package: spam
> > Severity: wishlist
> >
> > Dear Maintainer,
> > *** Please consider answering these questions, where appropriate ***
> >
> > This is Ubuntu, it is test reportbug, so please ignore, thanks!
> >

Bug#838809: spam: [testing] my report is spam so please just ignore

[황병희]

X-Debbugs-CC: soyeo...@gmail.com

For now i'm working for translation BTS section, so please ignore ...

On Sun, 25 Sep 2016 18:37:54 +0900 Byung-Hee HWANG 
wrote:
> Package: spam
> Severity: wishlist
>
> Dear Maintainer,
> *** Please consider answering these questions, where appropriate ***
>
> This is Ubuntu, it is test reportbug, so please ignore, thanks!
>

Bug#887581: c++-annotations FTBFS with yodl 4.02.00-2

[Adrian Bunk]

Source: c++-annotations
Version: 10.9.0-1
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/c++-annotations.html

...
yodl2txt --no-warnings -o ../tmp/docs/txt/cplusplus.txt -l3 cplusplus
Yodl2html 4.02.00
Yodl: including file preamble
preamble.yo:208: DEFINEMACRO: `nbsp' multiply defined
Yodl: including file abstract
Yodl is processing a(n) report
Document title: C++ Annotations
Version 10.9.0
Yodl: including file overview
Yodl: including file intro
Yodl: including file intro/intro
Yodl: including file whatsnew
Yodl: including file intro/history
Yodl: including file intro/annohistory
Yodl: including file intro/cascpp
Yodl: including file intro/compiling
Yodl: including file intro/mswindows
Yodl: including file intro/compilesources
Yodl: including file intro/advantage
Yodl: including file intro/object
Yodl: including file intro/differences
Yodl: including file intro/main
Yodl: including file intro/eoln
Yodl: including file intro/type
Yodl: including file intro/overload
Yodl: including file intro/default
Yodl: including file intro/null
Yodl: including file intro/void
Yodl: including file intro/cplus
Yodl: including file intro/cfunc
Yodl: including file intro/header
Yodl: including file intro/local
Yodl: including file intro/typedef
Yodl: including file intro/struct
Yodl: including file intro/evaluation
Yodl: including file intro/attributes
Yodl: including file first
Yodl: including file first/first
Yodl: including file first/extensions
Yodl: including file first/const
Yodl: including file first/namespaces
Yodl: including file first/scope
Yodl: including file first/cout
Yodl: including file first/structs
Yodl: including file first/public
Yodl: including file first/cvscpp
Yodl: including file first/references
Yodl: including file first/rvalueref
Yodl: including file first/lvalues
Yodl: including file first/stronglytyped
Yodl: including file first/initializer
Yodl: including file first/auto
Yodl: including file first/binding
Yodl: including file first/using
Yodl: including file first/rangebased
Yodl: including file first/rawstring
Yodl: including file first/binary
Yodl: including file first/selectinit
Yodl: including file first/attributes
Yodl: including file first/datatypes
Yodl: including file first/bool
Yodl: including file first/wchar
Yodl: including file first/unicode
Yodl: including file first/longlongint
Yodl: including file first/sizet
Yodl: including file first/separators
Yodl: including file first/cast
Yodl: including file first/staticcast
Yodl: including file first/constcast
Yodl: including file first/reinterpretcast
Yodl: including file first/dynamiccast
Yodl: including file first/sharedcast
Yodl: including file first/keywords
Yodl: including file namespaces
Yodl: including file namespaces/intro
Yodl: including file namespaces/defining
Yodl: including file namespaces/declaring
Yodl: including file namespaces/closed
Yodl: including file namespaces/referring
Yodl: including file namespaces/directive
Yodl: including file namespaces/koenig
Yodl: including file namespaces/std
Yodl: including file namespaces/nesting
Yodl: including file namespaces/outside
Yodl: including file string
Yodl: including file string/string
Yodl: including file string/ops
Yodl: including file string/overview
Yodl: including file string/initializers
Yodl: including file string/iterators
Yodl: including file string/operators
Yodl: including file string/members
Yodl: including file string/convertors
Yodl: including file iostreams
Yodl: including file iostreams/intro
Yodl: including file iostreams/headers
Yodl: including file iostreams/iosbase
Yodl: including file iostreams/ios
Yodl: including file iostreams/conditions
Yodl: including file iostreams/formatting
Yodl: including file iostreams/formatmembers
Yodl: including file iostreams/flags
Yodl: including file iostreams/output
Yodl: including file iostreams/ostream
Yodl: including file iostreams/ostreamwrite
Yodl: including file iostreams/ostreamseek
Yodl: including file iostreams/ostreamflush
Yodl: including file iostreams/ofstream
Yodl: including file iostreams/outmodes
Yodl: including file iostreams/ostringstream
Yodl: including file iostreams/input
Yodl: including file iostreams/istream
Yodl: including file iostreams/istreamread
Yodl: including file iostreams/istreamseek
Yodl: including file iostreams/ifstream
Yodl: including file iostreams/istringstream
Yodl: including file iostreams/copying
Yodl: including file iostreams/coupling
Yodl: including file iostreams/moving
Yodl: including file iostreams/redirection
Yodl: including file iostreams/readwrite
Yodl: including file classes
Yodl: including file classes/intro
Yodl: including file classes/construc
Yodl: including file classes/application
Yodl: including file classes/arguments
Yodl: including file classes/order
Yodl: including file classes/ambiguity
Yodl: including file classes/types
Yodl: including file classes/parentheses
Yodl: including file classes/existingtypes
Yodl: 

Bug#887575: castle-game-engine FTBFS with fpc 3.0.4

[Michalis Kamburelis]

The problem is caused by the different directories used by new FPC
3.0.4 packages (compared to previous versions of FPC in Debian).

Doing

  ./fpmake --globalunitdir="/usr/lib/fpc/3.0.4"

doesn't work, since /usr/lib/fpc/3.0.4 does not exist. This works:

  ./fpmake --globalunitdir="/usr/lib/x86_64-linux-gnu/fpc/3.0.4"

To fix this, I suggest to

- Change / define the $FPCDIR variable inside Debian build scripts, to
point to the new correct directory.

- Or create a symlink /usr/lib/fpc/3.0.4 ->
/usr/lib/x86_64-linux-gnu/fpc/3.0.4 .

Regards,
Michalis

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Bastian Blank]

On Tue, Jan 09, 2018 at 07:29:51PM -0500, Sam Hartman wrote:
> A build profile seems like a great way to express the flag, and like
> many things in Debian, the work would fall on those who would benefit
> from it.
> So, I do support the use of build profiles for use flags.
> I also believe there's sufficient utility for downstreams and users to
> justify this.

Okay.  As you think they are worth to think about: Please take one such
a flag; provide a description what it should do, both for the user and
on the system level; describe both the advantages and the drawbacks.
Oh, and please provide a list of packages you would start with applying
this change.

Bastian

-- 
Suffocating together ... would create heroic camaraderie.
-- Khan Noonian Singh, "Space Seed", stardate 3142.8

Bug#819649: Proposal

[Melisa Mehmet]

did you receive my investment proposal ?

Bug#887512: e2fsprogs: please add Vcs-*: fields to debian packaging

[Daniel Kahn Gillmor]

Hi Ted--

On Wed 2018-01-17 22:18:07 -0500, Theodore Ts'o wrote:
> Well I'm a bit hesitant to set up the automated fields because it
> may very well mislead people.
>
> First of all, the preferred git repository is at git.kernel.org (both
> for web browsing and git cloning):
>
>   https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
>
> The next issue is the branch in which the development takes place.

I understand your hesitation -- your situation doesn't map cleanly onto
the Vcs-Git: semantics.

That said, in the situation you're in, i'd just put the above value into
both the Vcs-Browser: and Vcs-Git: fields and call it a day.

The choice of which branch to use is less obvious, and you can elect to
simply omit it to avoid confusion.  The main question that the Vcs-*
fields aim to answer is "where is the best place to find revision
control that includes the debian packaging?", and with this e-mail i
think you've answered the question.

let me know if you want me to send a revised patch :)

  --dkg

Bug#887580: gmime2.6 FTBFS with gtk-doc-tools 1.27-1

[Adrian Bunk]

Source: gmime2.6
Version: 2.6.23+dfsg1-1
Severity: serious

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

...
gtkdoc-mkdb --module=gmime --output-format=xml --expand-content-files="" 
--main-sgml-file=gmime-docs.sgml ${_source_dir} --sgml-mode --output-format=xml 
--ignore-files=trio
Traceback (most recent call last):
  File "/usr/bin/gtkdoc-mkdb", line 61, in 
mkdb.Run(options)
  File "/usr/share/gtk-doc/python/gtkdoc/mkdb.py", line 282, in Run
ReadSourceDocumentation(sdir, suffix_list, source_dirs, ignore_files)
  File "/usr/share/gtk-doc/python/gtkdoc/mkdb.py", line 3641, in 
ReadSourceDocumentation
ScanSourceFile(fname, ignore_files)
  File "/usr/share/gtk-doc/python/gtkdoc/mkdb.py", line 3682, in ScanSourceFile
for line in SRCFILE:
  File "/usr/lib/python2.7/codecs.py", line 701, in next
return self.reader.next()
  File "/usr/lib/python2.7/codecs.py", line 632, in next
line = self.readline()
  File "/usr/lib/python2.7/codecs.py", line 547, in readline
data = self.read(readsize, firstline=True)
  File "/usr/lib/python2.7/codecs.py", line 494, in read
newchars, decodedbytes = self.decode(data, self.errors)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xad in position 0: invalid 
start byte
Makefile:730: recipe for target 'sgml-build.stamp' failed
make[5]: *** [sgml-build.stamp] Error 1

Bug#887579: binaryornot FTBFS with python-hypothesis 3.44.1-1

[Adrian Bunk]

Source: binaryornot
Version: 0.4.4+dfsg-1
Severity: serious

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

...
==
ERROR: test_never_crashes (tests.test_check.TestDetectionProperties)
--
Traceback (most recent call last):
  File "/build/1st/binaryornot-0.4.4+dfsg/tests/test_check.py", line 214, in 
test_never_crashes
def test_never_crashes(self, data):
  File "/usr/lib/python2.7/dist-packages/hypothesis/core.py", line 1002, in 
wrapped_test
state.run()
  File "/usr/lib/python2.7/dist-packages/hypothesis/core.py", line 727, in run
runner.run()
  File 
"/usr/lib/python2.7/dist-packages/hypothesis/internal/conjecture/engine.py", 
line 470, in run
self._run()
  File 
"/usr/lib/python2.7/dist-packages/hypothesis/internal/conjecture/engine.py", 
line 868, in _run
self.generate_new_examples()
  File 
"/usr/lib/python2.7/dist-packages/hypothesis/internal/conjecture/engine.py", 
line 760, in generate_new_examples
HealthCheck.large_base_example
  File "/usr/lib/python2.7/dist-packages/hypothesis/internal/healthcheck.py", 
line 38, in fail_health_check
raise FailedHealthCheck(message, label)
FailedHealthCheck: The smallest natural example for your test is extremely 
large. This makes it difficult for Hypothesis to generate good examples, 
especially when trying to reduce failing ones at the end. Consider reducing the 
size of your data if it is of a fixed size. You could also fix this by 
improving how your data shrinks (see 
https://hypothesis.readthedocs.io/en/latest/data.html#shrinking for details), 
or by introducing default values inside your strategy. e.g. could you replace 
some arguments with their defaults by using one_of(none(), 
some_complex_strategy)?
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.large_base_example to the suppress_health_check settings for this 
test.

--
Ran 44 tests in 0.985s

FAILED (errors=1, expected failures=1)
Test failed: 
You can add @seed(221414468027289032423022124386177593491) to this test to 
reproduce this failure.
error: Test failed: 
E: pybuild pybuild:283: test: plugin distutils failed with: exit code=1: 
python2.7 setup.py test 
dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
debian/rules:7: recipe for target 'build' failed
make: *** [build] Error 25

Bug#887578: bioperl-run FTBFS: t/Bowtie.t failures

[Adrian Bunk]

Source: bioperl-run
Version: 1.7.2-2
Severity: serious

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

...
Test Summary Report
---
t/Bowtie.t  (Wstat: 512 Tests: 61 Failed: 2)
  Failed tests:  43, 45
  Non-zero exit status: 2
Files=72, Tests=1690, 314 wallclock secs ( 0.57 usr  0.21 sys + 243.57 cusr 
10.84 csys = 255.19 CPU)
Result: FAIL
Failed 1/72 test programs. 2/1690 subtests failed.
dh_auto_test: perl Build test --verbose 1 returned exit code 255
debian/rules:32: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 2

Bug#887340: [Debichem-devel] Bug#887340: gromacs: FTBFS on x32: tests 2 and 13 time out

[Aaron M. Ucko]

Nicholas Breen  writes:

> It's probably a bug in OpenMPI instead (since the exact same tests pass on x32
> when using MPICH as the MPI implementation).  I don't have an x32 system
> available for testing, but it would be very interesting to know if the tests
> pass with the 3.0.x version of OpenMPI out of experimental.

The only 3.0.x version available for x32 is 3.0.0-1, because newer
versions build-depend on pmix, which in turn build-depends on pandoc,
which is unavailable there.  (I think the Haskell stack generally is.)
With that version installed in my laptop's x32 chroot and everything
else left at the versions available in unstable, I get *different*
errors per the attached log, excerpted below.  (Using unstable across
the board yields the same errors as on the autobuilder.)

   9/24 Test  #9: GpuUtilsUnitTests ***Timeout  30.01 sec
  [==] Running 30 tests from 6 test cases.
  [--] Global test environment set-up.
  [--] 7 tests from HostAllocatorTest/0, where TypeParam = int
  [ RUN  ] HostAllocatorTest/0.EmptyMemoryAlwaysWorks
  [   OK ] HostAllocatorTest/0.EmptyMemoryAlwaysWorks (0 ms)
  [ RUN  ] HostAllocatorTest/0.VectorsWithDefaultHostAllocatorAlwaysWorks
  [   OK ] HostAllocatorTest/0.VectorsWithDefaultHostAllocatorAlwaysWorks 
(0 ms)
  [ RUN  ] HostAllocatorTest/0.TransfersWithoutPinningWork
  [   OK ] HostAllocatorTest/0.TransfersWithoutPinningWork (0 ms)
  [ RUN  ] HostAllocatorTest/0.FillInputAlsoWorksAfterCallingReserve
  [   OK ] HostAllocatorTest/0.FillInputAlsoWorksAfterCallingReserve (0 ms)
  [ RUN  ] HostAllocatorTest/0.ChangingPinningPolicyRequiresCuda
  
  [WARNING] 
/home/amu/src/gromacs/gromacs-git/src/external/gmock-1.7.0/gtest/src/gtest-death-test.cc:825::
 Death tests use fork(), which is unsafe particularly in a threaded context. 
For this test, Google Test couldn't detect the number of threads.
  [...]
  13/24 Test #13: MdrunUtilityMpiUnitTests .***Failed0.02 sec
  --
  There are not enough slots available in the system to satisfy the 4 slots
  that were requested by the application:
/home/amu/src/gromacs/gromacs-git/build/openmpi/bin/mdrunutility-mpi-test
  
  Either request fewer slots for your application, or make more slots available
  for use.
  --
  [...]
  The following tests FAILED:
  9 - GpuUtilsUnitTests (Timeout)
 13 - MdrunUtilityMpiUnitTests (Failed)
  Errors while running CTest

I can retest on a more powerful system if you think that's likely to
make a difference; I just didn't yet have an x32 chroot there at all,
and would need to reboot it to enable the necessary kernel parameter
(syscall.x32=y).

I hope that information helps!

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



gromacs_2018-1_x64.build.xz
Description: Binary data

Bug#887577: ocamlnet FTBFS with nettle 3.4-1

[Adrian Bunk]

Source: ocamlnet
Version: 4.1.2-2
Severity: serious

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

...
In file included from nettls_nettle_bindings_stubs.c:24:0:
nettls_nettle_bindings_stubs.c:120:36: error: 'nettle_get_ciphers' declared as 
function returning an array
 const struct nettle_cipher * const nettle_ciphers[] = {
^
nettls_nettle_bindings_stubs.c:120:14: error: function 'nettle_get_ciphers' is 
initialized like a variable
 const struct nettle_cipher * const nettle_ciphers[] = {
  ^
In file included from nettls_nettle_bindings_stubs.c:24:0:
nettls_nettle_bindings_stubs.c:120:36: error: conflicting types for 
'nettle_get_ciphers'
 const struct nettle_cipher * const nettle_ciphers[] = {
^
/usr/include/nettle/nettle-meta.h:73:1: note: previous declaration of 
'nettle_get_ciphers' was here
 nettle_get_ciphers (void);
 ^~
nettls_nettle_bindings_stubs.c:121:3: error: invalid initializer
   _aes128,
   ^

Bug#887576: mupen64plus-qt FTBFS with libquazip5-headers 0.7.3-3

[Adrian Bunk]

Source: mupen64plus-qt
Version: 1.10-2
Severity: serious

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

...
src/emulation/emulatorhandler.cpp:42:10: fatal error: quazip/quazip.h: No such 
file or directory
 #include 
  ^
compilation terminated.
Makefile:608: recipe for target 'emulatorhandler.o' failed
make[1]: *** [emulatorhandler.o] Error 1

Bug#887574: texlive-lang-other: broken symlinks: /usr/share/texlive/texmf-dist/fonts/truetype/public/padauk/PadaukBook*.ttf

[Norbert Preining]

tags 887574 + pending
thanks

>   
> /usr/share/texlive/texmf-dist/fonts/truetype/public/padauk/PadaukBook-Regular.ttf
>  -> ../../../../../../fonts/truetype/padauk/Padauk-book.ttf
>   
> /usr/share/texlive/texmf-dist/fonts/truetype/public/padauk/PadaukBook-Bold.ttf
>  -> ../../../../../../fonts/truetype/padauk/Padauk-bookbold.ttf
>   
> /usr/share/texlive/texmf-dist/fonts/truetype/public/padauk/Padauk-Regular.ttf 
> -> ../../../../../../fonts/truetype/padauk/Padauk.ttf
>   /usr/share/texlive/texmf-dist/fonts/truetype/public/padauk/Padauk-Bold.ttf 
> -> ../../../../../../fonts/truetype/padauk/Padauk-bold.ttf

Thanks, the new upstream version of the padauk fonts changed the font
names. I have adjusted the links and added a version to the dependency
to ensure the correct version with correct font names is installed.

Thanks for the report

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#887575: castle-game-engine FTBFS with fpc 3.0.4

[Adrian Bunk]

Source: castle-game-engine
Version: 6.2+dfsg1-1
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/castle-game-engine.html

...
--- Building
dh_testdir
# Build the real engine
/usr/bin/make all
make[1]: Entering directory '/build/1st/castle-game-engine-6.2+dfsg1'
/usr/bin/make --no-print-directory build-using-fpmake
fpc fpmake.pp
Free Pascal Compiler version 3.0.4+dfsg-13 [2018/01/12] for x86_64
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling fpmake.pp
Linking fpmake
/usr/bin/ld.bfd: warning: link.res contains output sections; did you forget -T?
351 lines compiled, 0.4 sec
Running fpmake. If this fails saying that "rtl" is not found, remember to set 
FPCDIR environment variable, see http://wiki.freepascal.org/FPMake .
if [ '(' -n "/usr/lib/fpc/3.0.4" ')' -a \
 '(' 3.0.4 '!=' '2.6.4' ')' -a \
 '(' 3.0.4 '!=' '2.6.2' ')' ]; then \
   ./fpmake --globalunitdir="/usr/lib/fpc/3.0.4" -v -o -Ur; \
else \
   ./fpmake -v -o -Ur; \
fi
The installer encountered the following error:
Could not find unit directory for dependency package "rtl"
Makefile:60: recipe for target 'build-using-fpmake' failed
make[2]: *** [build-using-fpmake] Error 1

Bug#887512: e2fsprogs: please add Vcs-*: fields to debian packaging

[Theodore Ts'o]

On Wed, Jan 17, 2018 at 11:24:31AM -0500, Daniel Kahn Gillmor wrote:
> Package: e2fsprogs
> Version: 1.43.8-2
> Severity: wishlist
> Tags: patch
> 
> Adding Vcs-* fields to debian packaging makes it easier for other
> contributors to find the work and contribute.
> 
> The attached patch assumes that you're doing the packaging in the
> "debian-packaging" branch, though i note that you've also got a branch
> named "debian-branch".  please amend the location in both Vcs-Browser
> and Vcs-Git if you prefer "debian-branch" over "debian-packaging" for
> whatever reason.

Well I'm a bit hesitant to set up the automated fields because it
may very well mislead people.

First of all, the preferred git repository is at git.kernel.org (both
for web browsing and git cloning):

https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git

The next issue is the branch in which the development takes place.  In
fact, most of the packging work is done in the primary "upstream"
branches.  Which is to say, at the moment the "maint" branch for
1.43.x, and the "master" and "next" branches for the
soon-to-be-released 1.44.x.

The debian-packaging branch is only really used just before I do the
next debian release, and there have been times when I haven't bothered
with the debian-packaging branch at all --- I'll just release straight
from the "master" or the "maint" branch.

The reason why I'll use debian-packaging is when I need to diverge
from the primary git branches; for example, if I need to cherry-pick a
fix that has landed in master or maint, but for whatever reason I
don't want to push out a new upstream release.  At the moment, the
primary reason why debian-packaging exists because I have enabled
metadata checksums by default even though it isn't enabled that way
for upstream.

So that's the problem --- if the goal is allow other poeple to
contribute, they should just send patches against the maint branch
(for 1.43.x).  In a month or two, I'll have released 1.44, and for a
while the master branch be 1.44, but after a stablization release or
two, oldmaint will track 1.43.x (and I may or may not publish it),
maint will then track 1.44.x, and the master/next branches will be
tracking new development work that will be in the 1.45.x release.

If they want download exactly what was used for a particular release,
they can either grab the sources from a tag such as debian-1.43.8-2,
or debian-packaging will point at the most recently released debian
package.

So the question of which branch to use is complicated, and it's hard
to compress it into a simple Vcs-git: tag.  In fact, packaging is
present in *all* of the branches (for example, I build packages for
the not-yet-released 1.44 branch for gce-xfstests[1] from the next
branch fairly regularly).

[1] https://thunk.org/gce-xfstests

Cheers,

- Ted

Bug#887574: texlive-lang-other: broken symlinks: /usr/share/texlive/texmf-dist/fonts/truetype/public/padauk/PadaukBook*.ttf

[Andreas Beckmann]

Package: texlive-lang-other
Version: 2017.20180110-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

1m12.7s ERROR: FAIL: Broken symlinks:
  
/usr/share/texlive/texmf-dist/fonts/truetype/public/padauk/PadaukBook-Regular.ttf
 -> ../../../../../../fonts/truetype/padauk/Padauk-book.ttf
  
/usr/share/texlive/texmf-dist/fonts/truetype/public/padauk/PadaukBook-Bold.ttf 
-> ../../../../../../fonts/truetype/padauk/Padauk-bookbold.ttf
  /usr/share/texlive/texmf-dist/fonts/truetype/public/padauk/Padauk-Regular.ttf 
-> ../../../../../../fonts/truetype/padauk/Padauk.ttf
  /usr/share/texlive/texmf-dist/fonts/truetype/public/padauk/Padauk-Bold.ttf -> 
../../../../../../fonts/truetype/padauk/Padauk-bold.ttf


The following files are potential candidate targets for tehse links:

fonts-sil-padauk: /usr/share/fonts/truetype/padauk/Padauk-Bold.ttf
fonts-sil-padauk: /usr/share/fonts/truetype/padauk/Padauk-Regular.ttf
fonts-sil-padauk: /usr/share/fonts/truetype/padauk/PadaukBook-Bold.ttf
fonts-sil-padauk: /usr/share/fonts/truetype/padauk/PadaukBook-Regular.ttf


cheers,

Andreas


texlive-lang-other_2017.20180110-1.log.gz
Description: application/gzip

Bug#887573: pytest-pylint: FTBFS and Debci failure with python3-astroid 1.6.0-1

[Adrian Bunk]

Source: pytest-pylint
Version: 0.7.1-1
Severity: serious

https://ci.debian.net/packages/p/pytest-pylint/unstable/amd64/
https://tests.reproducible-builds.org/debian/history/pytest-pylint.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pytest-pylint.html

...
I: pybuild base:184: python3.6 -m pytest -v -x --ignore debian
= test session starts ==
platform linux -- Python 3.6.4, pytest-3.2.1, py-1.4.34, pluggy-0.4.0 -- 
/usr/bin/python3.6
cachedir: .cache
rootdir: /build/1st/pytest-pylint-0.7.1, inifile: tox.ini
plugins: pylint-0.7.1
collecting ... collected 10 items
-
Linting files
-

pytest_pylint.py FAILED

=== FAILURES ===
__ [pylint] pytest_pylint.py ___
W: 25, 0: Unused variable '__class__' (unused-variable)
W: 25, 0: Unused variable '__class__' (unused-variable)
W:160, 0: Unused variable '__class__' (unused-variable)
W:160, 0: Unused variable '__class__' (unused-variable)
W:160, 0: Unused variable '__class__' (unused-variable)
W:160, 0: Unused variable '__class__' (unused-variable)
 Interrupted: stopping after 1 failures 
=== 1 failed in 4.42 seconds ===
Unable to create directory /nonexistent/first-build/.pylint.d
Unable to create file /nonexistent/first-build/.pylint.d/pytest_pylint1.stats: 
[Errno 2] No such file or directory: 
'/nonexistent/first-build/.pylint.d/pytest_pylint1.stats'
E: pybuild pybuild:283: test: plugin custom failed with: exit code=2: python3.6 
-m pytest -v -x --ignore debian
dh_auto_test: pybuild --test --test-pytest -i python{version} -p 3.6 returned 
exit code 13
debian/rules:12: recipe for target 'override_dh_auto_install' failed
make[1]: *** [override_dh_auto_install] Error 25

Bug#887572: libkres-dev: missing Depends: libkres4 (= ${binary:Version})

[Andreas Beckmann]

Package: libkres-dev
Version: 1.5.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m23.7s ERROR: FAIL: Broken symlinks:
  /usr/lib/libkres.so -> libkres.so.4


cheers,

Andreas


libkres-dev_1.5.1-1.log.gz
Description: application/gzip

Bug#887570: libsuitesparse-dev: missing Depends: libgraphblas1 (= ${binary:Version})

[Andreas Beckmann]

Package: libsuitesparse-dev
Version: 1:5.1.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m26.2s ERROR: FAIL: Broken symlinks:
  /usr/lib/x86_64-linux-gnu/libgraphblas.so -> libgraphblas.so.1


cheers,

Andreas


libsuitesparse-dev_1:5.1.2-1.log.gz
Description: application/gzip

Bug#887571: debhelper: dh lies about what it does, breaks builds by creating new files, etc

[Norbert Preining]

Package: debhelper
Version: 11.1.2
Severity: serious
Justification: breaks other packages

Dear DebHelper developers,

thanks for your efforts, but it would be very helpful if debhelper/dh
would stick to what itself says it is doing.

I am trying to build texlive-bin, and somewhere at/around the configure
stage files
  configure.lineno
are created, which break building:
  checking whether g++ accepts -g... no
  checking dependency style of g++... none
  checking what warning flags to pass to the Objective C++ compiler...
  ../../../texk/web2c/configure: 20010: ./configure.lineno: Syntax error: Bad 
fd number
  === configuring in web2c failed

I confirmed the following:
* doing the same invocation of configure manually does NOT create
  configure.lineno and the build succeeds.
* what dh says it is doing with 
dh binary --no-act ...
  is *different* from what is actually happening, since doing the exact
  same things as listed by dh binary --no-act immediately breaks

Example for this (the reautoconf stage has already been done):
  $ dh binary --no-act --with autoreconf --builddirectory Work
  debian/rules override_dh_auto_configure
  dh_auto_build -O--builddirectory=Work
  dh_auto_test -O--builddirectory=Work

But doing
  $ debian/rules override_dh_auto_configure
breaks becasue it does not change into Work before calling configure.

Adding the obviously necessary
  DH_INTERNAL_BUILDFLAGS=1
  DH_INTERNAL_OPTIONS=-O--builddirectory=Work
  DH_INTERNAL_OVERRIDE=dh_auto_configure
make the above command work, but somewhere/somehow starts creating
configure.lineno files, while doing the configure.

Calling make -f debian/rules binary I see the following:
$ make -f debian/rules binary
dh binary --with autoreconf --builddirectory Work
   debian/rules override_dh_auto_configure
make[1]: Entering directory 
'/home/norbert/Development/TeX/debian/git/build-area/texlive-bin-2018.20180118.46355'
# we have to make sure that the mendex test case that is added
# by a patch is executable
chmod 0755 texk/mendexk/tests/mendex.test
# run out configure script
dh_auto_configure -- -C --prefix=/usr   \
--datarootdir=/usr/share/texlive\
--disable-native-texlive-build  \
 OTHER configure args
--enable-ipc
cd Work && ../configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdi
  
configure: creating cache config.cache
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for gcc... gcc

and at this time
  configure.lineno
is already existing, and propagated down the tree and breaking the build
builds.

But doing by hand, EVEN with the above three env variables set, doing
only the
  cd Work && ../configure --build=x86_64-lin ...
part does NOT create configure.lineno.


Also running
  dh_auto_configure -- -C --prefix=/usr \
--datarootdir=/usr/share/texlive\
  
does NOT create configure.lineno.

As a consequence, the only remaining candidate is that 
  dh
does *something*else* before calling the targets or setting env vars.

This is extremely difficult to debug without a proper documentation and
completely unreproducible behaviour from dh.

It is hard to guess what happens here, and I would be very grateful for
an expanation what else dh is doing before calling the actual things it
says it is calling.

Best

Norbert

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

Kernel: Linux 4.14.13 (SMP w/4 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 debhelper depends on:
ii  autotools-dev20171216.1
ii  binutils 2.29.1-13
ii  dh-autoreconf15
ii  dh-strip-nondeterminism  0.040-1
ii  dpkg 1.19.0.4
ii  dpkg-dev 1.19.0.4
ii  file 1:5.32-1
ii  libdpkg-perl 1.19.0.4
ii  man-db   2.7.6.1-4
ii  perl 5.26.1-4
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  
pn  dwz  

-- no debconf information

Bug#887569: lldpad-dev: missing Depends: lldpad (= ${binary:Version})

[Andreas Beckmann]

Package: lldpad-dev
Version: 1.0.1+git20150824.036e314-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m23.0s ERROR: FAIL: Broken symlinks:
  /usr/lib/x86_64-linux-gnu/liblldp_clif.so -> liblldp_clif.so.1.0.0


I'm only slightly questioning the package names ...


cheers,

Andreas


lldpad-dev_1.0.1+git20150824.036e314-1.log.gz
Description: application/gzip

Bug#884321: redis-sentinel: Please remove dependency on redis-server

[Andreas Beckmann]

Followup-For: Bug #884321
Control: reopen -1
Control: severity -1 serious

As a result /usr/bin/redis-sentinel is now a broken symlink:
  /usr/bin/redis-sentinel -> redis-server
which should render the package unusable ...


Andreas

Bug#887568: cb2bib: broken symlink: /usr/share/doc/man/man1/c2bimport.1 -> cb2bib.1

[Andreas Beckmann]

Package: cb2bib
Version: 1.9.7-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m54.2s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/man/man1/c2bimport.1 -> cb2bib.1

That should probably have been c2bimport.1.gz -> cb2bib.1.gz


cheers,

Andreas


cb2bib_1.9.7-1.log.gz
Description: application/gzip

Bug#865283: ITP: fontmake -- Compile fonts from sources (UFO, Glyphs) to binary (OpenType, TrueType)

[Jeremy Bicha]

Control: tags -1 +pending

I uploaded fontmake to Debian's NEW queue. Packaging is at
https://salsa.debian.org/fonts-team/fontmake

Thanks,
Jeremy Bicha

Bug#887567: node-node-uuid: broken symlink: /usr/lib/nodejs/node-uuid/index.js -> ../../../share/javascript/node-uuid/node-uuid.js

[Andreas Beckmann]

Package: node-node-uuid
Version: 1.4.7-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + node-sqlite3

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m34.3s ERROR: FAIL: Broken symlinks:
  /usr/lib/nodejs/node-uuid/index.js -> 
../../../share/javascript/node-uuid/node-uuid.js


libjs-node-uuid only ships /usr/share/javascript/node-uuid/uuid.js


cheers,

Andreas


node-sqlite3_3.1.8+ds1-2+b2.log.gz
Description: application/gzip

Bug#887566: r-cran-rhandsontable: broken symlink: /usr/lib/R/site-library/rhandsontable/htmlwidgets/lib/jquery/jquery.min.js -> usr/share/javascript/jquery/jquery.min.js

[Andreas Beckmann]

Package: r-cran-rhandsontable
Version: 0.3.4+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

1m2.1s ERROR: FAIL: Broken symlinks:
  /usr/lib/R/site-library/rhandsontable/htmlwidgets/lib/jquery/jquery.min.js -> 
usr/share/javascript/jquery/jquery.min.js

That target should probably have been absolute ...


Assuming the missing jquery breaks functionality, I'm setting the severity to 
serious.



cheers,

Andreas


r-cran-rhandsontable_0.3.4+dfsg-1.log.gz
Description: application/gzip

Bug#887565: Please package python3-vlc

[Mike Abrahall]

Package: src:vlc
Version: 3.0.0~rc5-1
Severity: wishlist

I have a Python app that uses VLC via the standard bindings.
This is already upstream 
https://git.videolan.org/?p=vlc/bindings/python.git;a=tree
I can ship that file myself, but when VLC updates my app breaks.
It would be much easier if this was just packaged alongside the VLC packages.

Bug#392187: Proposal

[Melisa Mehmet]

did you receive my investment proposal ?

Bug#640150: Proposal

[Melisa Mehmet]

did you receive my investment proposal ?

Bug#885570: linux-image-4.9.0-5-amd64

[Daniel Collier]

On Mon, 08 Jan 2018 20:48:36 +0100 Pierre Parent 
wrote:
> Hi,
>
> Same problem with linux-image-4.9.0-5-amd64.
>
> The bad thing is: now we have the choice between being protected against
> meltdown and have terrible artifacts, or go back to
linux-image-4.9.0-3-amd64,
> but being vulnerable to meltdown.
>
> Pierre.
>

Hi Pierre,

Adding command line param as described here
https://01.org/comment/2855#comment-2855 worked for me. Still get
occasional flickering with switching windows/keystrokes but no crash.

Solution allows meltdown cover and usable machine.

Regards

Daniel

Bug#887564: sip4: SIP 4.19.6 segfaults when running code generator

[Scott Talbert]

Source: sip4
Version: 4.19.6+dfsg-1
Severity: important
Tags: upstream patch

Dear Maintainer,

SIP 4.19.6 segfaults when running the code generator as part of building 
wxPython Phoenix.  This has been fixed upstream, but it would be good if 
the patch could be cherry-picked.

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

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

# HG changeset patch
# User Phil Thompson 
# Date 1515952150 0
# Node ID 8f9c478295d36b07066fba1c2ac8daacf632dde7
# Parent  e37301b91a57db62ed77ad5c912fcda30d85c997
Fixed the generated of a default value that is a global unscoped enum.

diff -r e37301b91a57 -r 8f9c478295d3 sipgen/gencode.c
--- a/sipgen/gencode.c  Tue Jan 09 14:16:47 2018 +
+++ b/sipgen/gencode.c  Sun Jan 14 17:49:10 2018 +
@@ -7585,7 +7585,7 @@
 {
 if (isScopedEnum(ed))
 prcode(fp, "%E", ed);
-else
+else if (ed->ecd != NULL)
 prEnumMemberScope(ed->members, fp);
 
 prcode(fp, "::%s", ed->members->cname);

Bug#887456: init-system-helpers: deb-systemd-helper does not honor the same package-relevant unit paths as systemd

[Michael Biebl]

Am 17.01.2018 um 11:35 schrieb Guillem Jover:
> --- a/script/deb-systemd-helper
> +++ b/script/deb-systemd-helper
> @@ -122,6 +122,8 @@ sub find_unit {
>  $service_path = "/etc/systemd/system/$scriptname";
>  } elsif (-f "/lib/systemd/system/$scriptname") {
>  $service_path = "/lib/systemd/system/$scriptname";
> +} elsif (-f "/usr/lib/systemd/system/$scriptname") {
> +$service_path = "/usr/lib/systemd/system/$scriptname";
>  }
>  return $service_path;
>  }

Looks ok to me on a cursory glance.
With merged-usr in mind, I wonder though if we should prefer
/usr/lib/systemd over /lib/systemd. The latter will be a symlink in such
a case and by prefering /usr/lib/systemd we'd avoid one indirection.

Felipe, wdyt?


-- 
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#887424: texlive-plain-extra: autopict.sty is broken

[Norbert Preining]

tags 887424 + pending
thanks

> the autopict.sty file (generated from ltpictur.dtx during package build)
> contains only comments and \endinput and lacks the definitions of essential

Fixed in TL subversion already, will be included in the next upload of
the TeX Live packages. Thanks for your report!

All the best

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#873417: pocl: Please update to llvm-toolchain 4.0 or, better, 5.0

[Andreas Beckmann]

On 2018-01-17 06:31, Andreas Beckmann wrote:
> Looks like we need to move to pocl 1.0 and llvm 4.0, unfortunately
> that will need another pass through NEW, since the SOVERSION was bumped.

1.0 is in experimental/NEW, still using llvm 3.9 to avoid the build
failure on i386

0.14 has been switched to llvm 4.0 in sid, the failure on i386 is
expected, primarily this was to test whether any other architecture
builds pocl with 4.0 (and collect symbols)

next upload will be pocl-1.0+llvm-4.0 once 1.0 has cleared NEW and I did
something against this single failure (probably by ignoring it)

The repository is now on salsa.debian.org, the old one on alioth is locked.

https://salsa.debian.org/opencl-team/pocl.git
g...@salsa.debian.org:opencl-team/pocl.git


Andreas

Bug#887563: correction in source package

[Nish Aravamudan]

Note that my suggestion 1) is actually partially in src:pacemaker (the
systemd change).

Bug#887563: corosync prerm will stop pacemaker and not start it again

[Nishanth Aravamudan]

Source: corosync
Severity: normal

Dear Maintainer,

We have a report in Ubuntu,
https://bugs.launchpad.net/charm-hacluster/+bug/1740892, which I believe
is reproducible in Debian Sid as well. In particular, I set up a Sid
LXD:

# apt install corosync pacemaker
...
# systemctl status corosync pacemaker
● corosync.service - Corosync Cluster Engine
...
   Active: active (running) since Wed 2018-01-17 23:14:56 UTC; 9s ago
...
● pacemaker.service - Pacemaker High Availability Cluster Manager
...
   Active: active (running) since Wed 2018-01-17 23:15:00 UTC; 5s ago
# apt install --reinstall corosync
...
# systemctl status corosync pacemaker
● corosync.service - Corosync Cluster Engine
...
   Active: active (running) since Wed 2018-01-17 23:15:23 UTC; 3s ago
● pacemaker.service - Pacemaker High Availability Cluster Manager
...
   Active: inactive (dead) since Wed 2018-01-17 23:15:22 UTC; 4s ago

I believe this is because the prerm of corosync.service has

# Automatically added by dh_installinit
if [ -x "/etc/init.d/corosync" ]; then
invoke-rc.d corosync stop || exit $?
fi

which unconditionally stops corosync for all Debian and Ubuntu releases
(as the init script is installed even if unused by systemd). When
corosync stops, pacemaker fails to connect to corosync (and the
pacemaker systemd unit file specifies that pacemaker Requires corosync)
and also stops.

When the postinst for corosync runs:

if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ]; then
if [ -x "/etc/init.d/corosync" ]; then
update-rc.d corosync defaults >/dev/null
invoke-rc.d corosync start || exit $?
fi
fi

corosync will start, but there is no connection between corosync
starting (systemd or SysV) and pacemaker.

I think there are two necessary changes to the packaging/upstream to fix
this:

1) The systemd unit file should indicate pacemaker is PartOf corosync,
which will propogate restarts of corosync to pacemaker. This will also
propogate stops, but as mentioned above, pacemaker already stops when
corosync stops, so I think it's harmless. Additionally, the SysV init
file should be updated to check if the pacemaker SysV status was running
before stopping corosync in the restart path and start pacemaker as well
after starting corosync.

2) d/rules should call dh_installinit with --restart-after-upgrade. This
is the default in compat >= 10 (2.4.2-3 is still at 9). That will change
the prerm and postinst to not stop/start the service on upgrade, but
simply restart it in the postinst (removals will still stop the
service).

Now, neither of these actually fix the existing packages unfortunately,
which will stop pacemaker on the upgrade to a fixed package and thus
stop pacemaker. I have no idea if there actually is any way to fix this
for existing packages, since the 'old' prerm will be invoked by dpkg on
the upgrade path.

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

Kernel: Linux 4.13.0-25-generic (SMP w/4 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)
LSM: AppArmor: enabled

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

Bug#887562: RFS: ries/2017.02.12-1 [ITP]

[Nicolas Braud-Santoni]

Package: sponsorship-requests
Severity: wishlist
Control: block 887561 by -1
X-Debbugs-CC: j...@debian.org

Dear mentors,

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

 * Package name: ries
   Version : 2017.02.12
   Upstream Author : Robert P. Munafo
 * URL : https://mrob.com/pub/ries/
 * License : GPL-3+
   Programming Lang: C
   Description : find algebraic equations, given their solution

Given a number, ries searches for algebraic equations in one
variable that have a solution (root) near that number. It avoids
trivial or reducible solutions like ``x/x = 1''. If rhe input is
an integer, ries can find an exact solution
expressed in terms of single-digit integers.

The output gives progressively ``more complex'' equations
that come progressively closer to matching the input number.


It builds a single binary package: ries.


The packaging repository is available on alioth.d.o:

https://anonscm.debian.org/git/collab-maint/ries.git


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#887561: ITP: ries -- find algebraic equations, given their solution

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ries
  Version : 2017.02.12
  Upstream Author : Robert P. Munafo
* URL : https://mrob.com/pub/ries/
* License : GPL-3+
  Programming Lang: C
  Description : find algebraic equations, given their solution

Given a number, ries searches for algebraic equations in one
variable that have a solution (root) near that number. It avoids
trivial or reducible solutions like ``x/x = 1''. If rhe input is
an integer, ries can find an exact solution
expressed in terms of single-digit integers.

The output gives progressively ``more complex'' equations
that come progressively closer to matching the input number.


signature.asc
Description: PGP signature

Bug#887520: nbd-client: does not connect if export is named "server-media"

[Gregor Zattler]

Hi Wouter,
* Wouter Verhelst  [2018-01-17; 18:33]:
> On Wed, Jan 17, 2018 at 06:12:59PM +0100, Gregor Zattler wrote:
>> There is a nbd server version 1:3.16.2-1 running on a debian
>> testing/buster server with amongst others this definition of an
>> export in /etc/nbd-server/config:
>> 
>> [server-media]
>> exportname = /dev/sda5
>
> If you're doing that, you need to ensure that the NBD server has access
> to /dev/sda5, at least read access (but possibly write access, too). Out
> of the box, this is not possible (you can export files too).
>
> In order to do so, you have two options:
>
> - Either tell udev to change ownership and/or permissions of /dev/sda5
>   so that a process running as the "nbd" user and/or group can read (and
>   possibly write) to the device;
> - Or comment out or change the "user" and/or "group" setting in the
>   configuration file, so that the user and/or group are no longer set to
>   "nbd" but instead to "disk" or left as "root".
>
> If you don't do either of those, then the nbd-server will not have
> access to the partitions and cannot possibly export it.
>
>> flush = true
>> fua = true
>> 
>> When I connect to this export with nbd-client version 1:3.15.2-3
>> from a debian stretch system I get:
>> 
>> $ sudo nbd-client  -name server-media shi /dev/nbd1
>> Negotiation: ..Error: Read failed: End of file
>> Exiting.
>
> This is the normal error message you get when the server cannot access
> the device in question.

IMHO this is not a permissions problem, as shown with this log of
my actions:

on server (shi):
$ egrep "user|group" /etc/nbd-server/config
# If you want to run everything as root rather than the nbd user, you
user = nbd
group = nbd
$ sudo systemctl restart nbd-server.service
$ ls -l /dev/sda*|grep nbd
brw-rw 1 root nbd  8, 5 Jan 17 23:44 /dev/sda5
brw-rw 1 root nbd  8, 6 Jan 17 17:48 /dev/sda6

on client (len):
$ sudo nbd-client -l shi
Negotiation: ..
crypt-server-backup
shi-media
$ sudo nbd-client  -name "shi-media" shi /dev/nbd1
Negotiation: ..size = 921600MB
bs=1024, sz=966367641600 bytes

now on server again:
$ sudo sed -i -e "s/shi-media/server-media/" /etc/nbd-server/config
$ sudo systemctl restart nbd-server.service
$ ls -l /dev/sda*|grep nbd
brw-rw 1 root nbd  8, 5 Jan 17 23:50 /dev/sda5
brw-rw 1 root nbd  8, 6 Jan 17 17:48 /dev/sda6

back to client:
$ sudo nbd-client -l shi
Negotiation: ..
crypt-server-backup
server-media
$ sudo nbd-client  -name "server-media" shi /dev/nbd1
Negotiation: ..Error: Read failed: End of file
Exiting.

what happened to the permissions on the server?:
$ ls -l /dev/sda*|grep nbd
brw-rw 1 root nbd  8, 5 Jan 17 23:50 /dev/sda5
brw-rw 1 root nbd  8, 6 Jan 17 17:48 /dev/sda6


Now on server I change my nbd-server config not to use nbd as
user/group:

$ egrep "user|group" /etc/nbd-server/config
# If you want to run everything as root rather than the nbd user, you
#   user = nbd
#   group = nbd
$ sudo chgrp disk /dev/sda5
$ ls -l /dev/sda5
brw-rw 1 root disk 8, 5 Jan 17 23:50 /dev/sda5
$ sudo systemctl restart nbd-server.service

and back to client:
$ sudo nbd-client -l shi
Negotiation: ..
crypt-server-backup
server-media
$ sudo nbd-client -c /dev/nbd1 || echo not connected
not connected
$ sudo nbd-client  -name "server-media" shi /dev/nbd1
Negotiation: ..Error: Read failed: End of file
Exiting.


Changing the exports name helps while changing the user/group does
not help with this problem.


>> When I rename this export on the server to "shi-media", restart the
>> nbd-server.service and do:
>> 
>> $ sudo nbd-client  -name shi-media shi /dev/nbd1
>> Negotiation: ..size = 921600MB
>> bs=1024, sz=966367641600 bytes
>
> I suspect that something changed related to permissions in between the
> two runs, and that that, rather than the name change, is responsible for
> it succeeding the second time.
>
>> I would assume this bug applies to all export names beginning
>> with "server-".
>> 
>> It should be possible to use export names beginning with
>> "server-" or at least this restriction should be documented.
>
> There is no such restriction. The only restrictions existing for export
> names are one of length (4096 bytes maximum, although "only" 256 should
> be used if one desires to remain compatible with other implementations)
> and a practical one of legal characters for section headers implemented
> by glib's GKeyFile API.

Thanks for looking into this.

Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Bug#348909: recode: This is a problem with iconv's API

[Reuben Thomas]

Package: recode
Version: 3.6-22
Followup-For: Bug #348909

I looked into this bug. The problem starts with the fact that iconv returns
EILSEQ (invalid input) when in fact the input is simply untranslatable.

It is possible to diagnose this situation by running another conversion with
the output encoding the same as the input (so that it will always succeed on
valid input) at the same point.

Unfortunately, I can’t work out what to do next: in particular, there’s no C
API I can use in general to skip the valid but untranslatable character. (At
least, none I can see; ideas welcome!)

For now, I’ve implemented a partial workaround: untranslatable text is
detected, and one byte is skipped. The typical result is that invalid input
is diagnosed on the next step, resulting in the same problem as at present.

There are two possible workarounds:

1. Set abort_level to RECODE_UNTRANSLATABLE.
2. Don’t use iconv.

I have documented these.

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages recode depends on:
ii  libc6   2.23-0ubuntu10
ii  librecode0  3.6-22

recode recommends no packages.

recode suggests no packages.

-- no debconf information

Bug#887560: horizon: [INTL:fr] French debconf translation update

[Alban Vidal]

Package: horizon
Version: 3_12.0.0-6
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Please find attached the French debconf templates update, proofread by the
debian-l10n-french mailing list contributors.

Best regards,

Alban Vidal
# Translation of horizon debconf templates to French.
# Copyright (C) 2013, 2018, French l10n team 

# This file is distributed under the same license as the HORIZON package.
#
# Translators:
# Julien Patriarca , 2013.
# Alban Vidal , 2018.
msgid ""
msgstr ""
"Project-Id-Version: horizon 3_12.0.0-6\n"
"Report-Msgid-Bugs-To: hori...@packages.debian.org\n"
"POT-Creation-Date: 2017-11-15 21:55+\n"
"PO-Revision-Date: 2018-01-14 19:00+0100\n"
"Last-Translator: Alban Vidal \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 2.0\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:2001
msgid "Activate Dashboard and disable default VirtualHost?"
msgstr ""
"Faut-il activer OpenStack Dashboard et désactiver l'hôte virtuel par défaut ?"

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:2001
msgid ""
"The Apache package sets up a default web site and a default page, configured "
"in /etc/apache2/sites-available/default."
msgstr ""
"Le paquet Apache installe un site Web et une page par défaut, configurés dans "
"/etc/apache2/sites-available/default."

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:2001
msgid ""
"If this option is not selected, Horizon will be installed using /horizon "
"instead of the webroot."
msgstr ""
"Si cette option n'est pas sélectionnée, Horizon sera installé sur /horizon "
"plutôt qu'à la racine du serveur Web."

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:2001
msgid ""
"Choose this option to replace that default with the OpenStack Dashboard "
"configuration."
msgstr ""
"Choisissez cette option pour remplacer le réglage par défaut par la "
"configuration d'OpenStack Dashboard."

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:3001
msgid "Should the Dashboard use HTTPS?"
msgstr "Faut-il utiliser HTTPS pour OpenStack Dashboard ?"

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:3001
msgid ""
"Select this option if you would like Horizon to be served over HTTPS only, "
"with a redirection to HTTPS if HTTP is in use."
msgstr ""
"Veuillez choisir cette option si vous souhaitez qu'Horizon soit installé sur "
"HTTPS uniquement, avec une redirection vers HTTPS si HTTP est utilisé."

#. Type: string
#. Description
#: ../openstack-dashboard.templates:2001
msgid "Allowed hostname(s)"
msgstr "Nom(s) d'hôte autorisé(s)"

#. Type: string
#. Description
#: ../openstack-dashboard.templates:2001
msgid ""
"Please enter the list of hostnames that can be used to reach your OpenStack "
"Dashboard server. This is a security measure to prevent HTTP Host header "
"attacks, which are possible even under many seemingly-safe web server "
"configurations."
msgstr ""
"Veuillez saisir la liste des noms d'hôte qui peuvent être utilisés pour "
"joindre votre serveur OpenStack Dashboard. Il s'agit d'une mesure de "
"sécurité afin de prévenir les attaques HTTP, au travers des en-têtes d'hôte, "
"qui sont possibles sur de nombreux serveurs Web dont la configuration "
"paraît sécurisée."

#. Type: string
#. Description
#: ../openstack-dashboard.templates:2001
msgid ""
"Enter values separated by commas. Any space will be removed, so you can add "
"some to make it more readable."
msgstr ""
"Entrez les valeurs séparées par des virgules. Les espaces seront supprimées, "
"mais vous pouvez en ajouter pour plus de lisibilité."

#. Type: string
#. Description
#: ../openstack-dashboard.templates:2001
msgid ""
"Values in this list can be fully qualified names like \"www.example.com\", "
"in which case they will be matched against the request's Host header exactly "
"(case-insensitive, not including port). A value beginning with a period can "
"be used as a subdomain wildcard: \".example.com\" will match example.com, "
"www.example.com, and any other subdomain of example.com. A value of \"*\" "
"will match anything; in this case you are responsible for providing your own "
"validation of the Host header (perhaps in middleware; if so this middleware "
"must be listed first in MIDDLEWARE)."
msgstr ""
"Les valeurs de cette liste peuvent être les noms d'hôte complètement "
"qualifiés tels que « www.example.com », et, dans ce cas, elles seront 
comparées "
"exactement avec les en-têtes Host de la requête (casse indifférente, sans "
"inclure le numéro de port). Une valeur commençant par un point peut être "
"utilisée en tant que joker 

Bug#807044: Okular scales down A4 to A5 on printing

[Marc Haber]

On Tue, Jan 16, 2018 at 06:08:16PM +0100, Michael Weghorn wrote:
> On Thu, 27 Apr 2017 19:53:45 +0200 Adi Kriegisch  wrote:
> > There seem to be several upstream issues dealing with this, eg.
> > https://bugs.kde.org/show_bug.cgi?id=348171
> > 
> > Okular in its current version in Stretch (16.08.2-1+b1) cannot be used for
> > printing.
> 
> The mentioned upstream bug has been closed in the meanwhile.
> Does the problem still occur with the Okular version in current Debian
> unstable/testing?

Affirmative.

> If so, could you please provide more detailed steps how to reproduce and
> possibly attach a PDF document that is affected?

https://www.eisenbahn-unfalluntersuchung.de/SharedDocs/Downloads/EUB/Untersuchungsberichte/2015/104_Duisburg-Wedau_-_Lintorf.pdf
- click on "herunterladen" and use the resulting PDF.

> (If I understand correctly, the use case which breaks for you is
> printing an A4 document to A4 paper,

Yes.

> which has been working fine for me
> so far.)

I do have the issue on two Systems.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#884294: Anyone looking at this bug?

[olivier sallou]

This bug introduce reverse dependency package issues that will lead to
their removal.
For some packages in debianmed, i could patch to remove python influxdb use
(which makes use of pandas). This would remove some features but would keep
packages in the meanwhile
 But this may not be so simple for other packages.

Thanks

Olivier

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Adrian Bunk]

On Tue, Jan 09, 2018 at 07:29:51PM -0500, Sam Hartman wrote:
> > "Adrian" == Adrian Bunk  writes:
> 
> Adrian> On Tue, Jan 09, 2018 at 01:23:32PM +0100, Guillem Jover wrote:
> >> ...  Given the background of build-profiles, I'm very much in
> >> favor of introducing the equivalent usage as Gentoo USE flags,
> >> which was its main intention! :) It could make Debian a viable
> >> source-based distribution to use or base on, could make many of
> >> the embedded specific distribution solutions obsolete, ...
> 
> Adrian> Who would then implement, maintain and support this in all
> Adrian> packages?
> 
> No one.  People would implement and test the feature where it was
> sufficiently useful to implement and test.  I don't think all of the use
> flags combinations are tested in source distributions that have them
> today.
>
> Even so, users find those flags useful enough to spend a fair bit of
> work on them.

To "make many of the embedded specific distribution solutions obsolete",
Debian would have to provide all this in stable releases at a quality
comparable to Yocto.

> A build profile seems like a great way to express the flag, and like
> many things in Debian, the work would fall on those who would benefit
> from it.
> 
> So, I do support the use of build profiles for use flags.
> I also believe there's sufficient utility for downstreams and users to
> justify this.

For many use flags the only benefit is an unused library less on
the system when the flag is disabled, and this also applies to the
proposed nosystemd profile discussed in this bug.

Support for nosystemd in only 95% of all libsystemd-using packages would
still result in libsystemd being installed - if just one maintainer 
would refuse to apply a nosystemd patch, the people working on nosystemd
in Debian basically have to rely on CTTE overruling the maintainer.


Your "build profiles for use flags" can easily require changes to 
hundreds of packages just for one flag, often including non-trivial 
changes to e.g. debian/rules or .install files.

This only makes sense if there is consensus that this is a useful
direction, and that this should be fully supported in future stable
releases of Debian.


> --Sam

cu
Adrian

[1] Raspberry Pi Zero is already big enough to not require use flags

-- 

   "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#887556: non deterministic behavior of network-online.target

[Michael Biebl]

Am 17.01.2018 um 22:11 schrieb Michael Biebl:

> It's not systemd that pulls in network-online.target. You should contact
> the ifupdown maintainers why apparently network-online.target does not
> work for you.

btw, in your syslog.fail, it seems like network-online.target is not
started at all. Either your log is incomplete or something else prevents
this target from being pulled in.

You should check, if you have any dependency loops (you mentioned custom
services) which could result in services/targets not being started.

For that add systemd.log_level=debug to the kernel command line and follow

https://unix.stackexchange.com/questions/193714/generic-methodology-to-debug-ordering-cycles-in-systemd
-- 
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#887559: jessie-pu: package nvidia-graphics-drivers/340.106-1

[Andreas Beckmann]

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

For meltdown/spectre mitigation, we need to update to a new upstream
version of the proprietary nvidia driver.
Packaging diff attached. This includes several improvements as well that
are needed to keep the packaging between the different driver versions
in sync.
As usual the Debian revision is -1 instead of -0+deb8u1 to avoid version
number explosion in nvidia-graphics-modules.

This driver version is available in sid in the
nvidia-graphics-drivers-legacy-340xx package (which will get a separate
update request for stretch).

A corresponding nvidia-graphics-drivers update for stretch is still
being prepared, since it involves several packages to be updated
because of a change of the major version: 375 -> 384.


Andreas
Index: debian/README.source
===
--- debian/README.source(.../tags/340.102-1)(revision 7819)
+++ debian/README.source(.../branches/340)  (revision 7819)
@@ -1,3 +1,17 @@
+Building "bleeding edge" from SVN for users
+
+As new upstream versions of the proprietary driver are released, upload
+might not happen immediately. This might be for various reasons, including
+waiting for new binary packages to clear the NEW queue.
+Users wishing to try to build new version locally can follow the
+instructions on the Debian wiki:
+
+
https://wiki.debian.org/NvidiaGraphicsDrivers#Building_newer_releases_from_SVN
+
+WARNING: these will most likely be work in progress, and the final upload
+may be different and may not support clean upgrades from/to the versions
+uploaded in the archive.
+
 Importing a New Upstream Release
 
 The *.orig.tar.gz file for nvidia-graphics-drivers contains just a
Index: debian/nvidia-kernel-source.README.Debian.in
===
--- debian/nvidia-kernel-source.README.Debian.in(.../tags/340.102-1)
(revision 7819)
+++ debian/nvidia-kernel-source.README.Debian.in(.../branches/340)  
(revision 7819)
@@ -178,7 +178,7 @@
 
 
 For any news on this package check
-http://bugs.debian.org/#NVIDIA#-kernel-source
+https://bugs.debian.org/#NVIDIA#-kernel-source
 
 
  -- Russ Allbery , Sat, 25 Sep 2010 23:30:28 -0700
Index: debian/build-module-packages.sh.in
===
--- debian/build-module-packages.sh.in  (.../tags/340.102-1)(revision 7819)
+++ debian/build-module-packages.sh.in  (.../branches/340)  (revision 7819)
@@ -4,16 +4,32 @@
 
 cd /usr/src
 
-kernels="$(ls -d1 /lib/modules/*/build 2>/dev/null | cut -d/ -f4)"
+kernels=
+slenrek=
+failed=
+for k in $(ls -dvr1 /lib/modules/*/build 2>/dev/null | cut -d/ -f4) ; do
+   case $k in
+   *)
+   kernels="$kernels $k"
+   slenrek="$k $slenrek"
+   ;;
+   esac
+done
 modules=#NVIDIA#-kernel
 
 module-assistant clean $modules
-module-assistant build --text-mode --force --kvers-list "$kernels" $modules
+for k in $kernels ; do
+   module-assistant build --text-mode --force --kvers-list "$k" $modules 
|| failed="$failed $k"
+done
 
-ls -l *.deb
+ls -l *.deb || true
 for m in $modules ; do
-   for k in $kernels ; do
+   for k in $slenrek ; do
echo "* ${m} ${k}:"
-   ls -l ${m}-${k}_*.deb
+   ls -l ${m}-${k}_*.deb || true
done
 done
+
+for k in $failed ; do
+   echo "$modules MODULE BUILD FAILED FOR $k"
+done
Index: debian/libnvidia-ml1.lintian-overrides
===
--- debian/libnvidia-ml1.lintian-overrides  (.../tags/340.102-1)
(revision 7819)
+++ debian/libnvidia-ml1.lintian-overrides  (.../branches/340)  
(revision 7819)
@@ -1,6 +1,7 @@
 # The NVIDIA license does not allow any form of modification.
 [i386 armhf]: binary-file-built-without-LFS-support
 [i386]: shlib-with-non-pic-code
+[amd64 i386]: spelling-error-in-binary
 hardening-no-bindnow
 hardening-no-fortify-functions
 hardening-no-relro
Index: debian/nvidia-libopencl1.lintian-overrides
===
--- debian/nvidia-libopencl1.lintian-overrides  (.../tags/340.102-1)
(revision 7819)
+++ debian/nvidia-libopencl1.lintian-overrides  (.../branches/340)  
(revision 7819)
@@ -11,7 +11,7 @@
 
 # The free libOpenCL.so.1 library is preferred.
 symbols-declares-dependency-on-other-package ocl-icd-libopencl1
-symbols-declares-dependency-on-other-package ocl-icd-libopencl1 (>= 1.0)
+symbols-declares-dependency-on-other-package ocl-icd-libopencl1 (>= *)
 
 # Package built with debhelper/jessie but checked with lintian/sid.
 maintscript-calls-ldconfig
Index: debian/copyright

Bug#887558: wine-development FTBFS on armel: selected processor does not support `strd r4,[sp]' in ARM mode

[Jens Reyer]

Source: wine-development
Version: 3.0~rc3-2
Severity: serious
Forwarded: https://bugs.winehq.org/show_bug.cgi?id=44365
Tags: upstream


gcc -c -o relay.o relay.c -I. -I../../include -D__WINESRC__ -D_NTSYSTEM_
-D_REENTRANT -fPIC -Wall \
  -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body
-Wignored-qualifiers \
  -Wno-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes
-Wtype-limits \
  -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith
-Wlogical-op -gdwarf-2 \
  -gstrict-dwarf -Werror -Wdate-time -g -O2
-fdebug-prefix-map=/<>=.
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong
-Wformat -Werror=format-security -march=armv5t -Wno-error -marm
-mfloat-abi=soft
[...]
{standard input}: Assembler messages:
{standard input}:51: Error: selected processor does not support `strd
r4,[sp]' in ARM mode
Makefile:521: recipe for target 'relay.o' failed
make[2]: *** [relay.o] Error 1
make[2]: Leaving directory '/<>/dlls/ntdll'
Makefile:13147: recipe for target 'dlls/ntdll' failed
make[1]: *** [dlls/ntdll] Error 2


I hope upstream fixes this soon.  Otherwise we'd have to remove armel
from the architecture list and file an RM bug against ftp.debian.org for
removal of the stale old armel packages (advice copied from #881446).

Previously I had mistaken a change in 3.0-rc3 to fix this, therefore the
wrong changelog entry in that version.

Greets
jre

Bug#887479: Pending fixes for bugs in the libpdfbox2-java package

[pkg-java-maintainers]

tag 887479 + pending
thanks

Some bugs in the libpdfbox2-java package are closed in revision
5851ceda4cdf927b9d575b213152d8e3fd7c4823 in branch 'master' by Markus
Koschany

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/libpdfbox2-java.git/commit/?id=5851ced

Commit message:

Remove obsolete rm command in debian/rules.

Closes: #887479
Thanks: Adrian Bunk for the report.

Bug#887556: non deterministic behavior of network-online.target

[Michael Biebl]

Am 17.01.2018 um 21:39 schrieb Vladislav Kurz:
> Package: systemd
> Version: 232-25+deb9u1
> Severity: normal
> 
> Hello,
> 
> This is a followup to archived bug #870361
> 
> I have been installing new servers with similar setup as last time, and
> ran into the same problem. I think I have narrowed the problem down to
> network-online.target
> 
> The problem affects not only my custom service unit but also the generated
> unit for isc-dhcp-server.
> This is /var/run/systemd/generator.late/isc-dhcp-server.service
> 
> # Automatically generated by systemd-sysv-generator
> 
> [Unit]
> Documentation=man:systemd-sysv-generator(8)
> SourcePath=/etc/init.d/isc-dhcp-server
> Description=LSB: DHCP server
> Before=multi-user.target
> Before=multi-user.target
> Before=multi-user.target
> Before=graphical.target
> After=remote-fs.target
> After=network-online.target
> After=slapd.service
> After=nss-lookup.target
> Wants=network-online.target
> 
> [Service]
> Type=forking
> Restart=no
> TimeoutSec=5min
> IgnoreSIGPIPE=no
> KillMode=process
> GuessMainPID=no
> RemainAfterExit=yes
> SuccessExitStatus=5 6
> ExecStart=/etc/init.d/isc-dhcp-server start
> ExecStop=/etc/init.d/isc-dhcp-server stop
> 
>  EOF 
> 
> You see it has After=network-online.target, and yet my server failed to
> start DHCP server in 3 out of 4 reboots, with this in syslog:
> 
> Jan 17 15:40:43 gw dhcpd[1269]: No subnet declaration for eno2 (no IPv4 
> addresses).
> Jan 17 15:40:43 gw dhcpd[1269]: ** Ignoring requests on eno2.  If this
> is not what
> Jan 17 15:40:43 gw dhcpd[1269]:you want, please write a subnet
> declaration
> Jan 17 15:40:43 gw dhcpd[1269]:in your dhcpd.conf file for the
> network segment
> Jan 17 15:40:43 gw dhcpd[1269]:to which interface eno2 is attached. **
> Jan 17 15:40:43 gw dhcpd[1269]:
> Jan 17 15:40:43 gw dhcpd[1269]:
> Jan 17 15:40:43 gw dhcpd[1269]: Not configured to listen on any interfaces!
> 
>  EOF 
> 
> Yet after logging to the server eno2 was configured and I was able to
> start dhcp server manually. The dhcpd.conf is:
> 
> option domain-name "example.com";
> option domain-name-servers 192.168.45.1;
> option netbios-name-servers 192.168.45.1;
> option ntp-servers 192.168.45.1;
> option log-servers 192.168.45.1;
> default-lease-time 86400;
> max-lease-time 604800;
> ddns-update-style none;
> authoritative;
> log-facility local7;
> subnet 192.168.45.0 netmask 255.255.255.0 {
>   range 192.168.45.10 192.168.45.99;
>   option routers 192.168.45.1;
> }
> 
>  EOF 
> 
> I'm not using any network manager or anything...
> eno1 is using dhclient, but will be moved to static when it goes to 
> production. eno2 (dhcp server interface) is static IPv4
> 
> /etc/network/interfaces:
> 
> # The loopback network interface
> auto lo
> iface lo inet loopback
> 
> # The primary network interface
> auto eno1
> iface eno1 inet dhcp
> #address 192.168.1.2
> #netmask 255.255.255.0
> #gateway 192.168.1.1
> 
> # The local network interface
> auto eno2
> iface eno2 inet static
> address 192.168.45.1
> netmask 255.255.255.0
> 
>  EOF 
> 
> In /etc/default/isc-dhcp-server I have only:
> 
> INTERFACESv4="eno2"
> INTERFACESv6=""
> 
> My own service unit for mounting encrypted filesystem was failing at
> exactly the same reboot attempts as dhcp server, so I think this is not
> a bug in my unit or dhcp server but in systemd itself.
> 
> My unit is:
> 
> [Unit]
> Description=Mount encrypted disks (webstep script)
> ConditionPathExists=/usr/local/sbin/mount_enc_disks.sh
> After=network-online.target
> Wants=network-online.target
> Before=zfs-import-cache.service
> 
> [Service]
> Type=oneshot
> ExecStart=/usr/local/sbin/mount_enc_disks.sh
> StandardOutput=journal
> RemainAfterExit=yes
> 
> [Install]
> WantedBy=zfs.target
> 
>  EOF 
> 
> 
> I'm attaching a censored syslog from both good and bad boot. You can see
> that in failed case our script and dhcp server is started before
> dhclient, and on sucessful case it is staretd after dhclient. And I dare
> say that sucessfull assignment of IP address by dhclient should be a
> required before network-online.target is finished.
> 
> My colleague has had a similar case with other server, where our script
> was not run at all, but zfs-import-cache was started early in boot
> process. And after a reboot (without any config change) everything went
> fine. Screenshot comparing the significant parts of boot is attached.
> 
> If you want more config files I can send them.
> 
> If you still think that it is not a fault of systemd, then please tell
> me what I have done wrong, and what should I put in unit files to keep
> them in this order:
> 
> 1. network is fully functional (IP adresses assigned to all interfaces)
> 2. our script is run (wget key and decrypt filesystems) 
> 3. zfs imports and mounts the filesystems
> 4. services that have data on encrypted zfs are started
> 

It's not systemd that pulls in 

Bug#887557: www.debian.org: tech-ctte membership updates

[Niko Tyni]

Package: www.debian.org
Tags: patch
X-Debbugs-Cc: debian-c...@lists.debian.org

Hi, please find attached a patch to update
 https://www.debian.org/intro/organization 
for the recent tech-ctte membership changes.

It also updates the rather outdated list of past members on
 https://www.debian.org/devel/tech-ctte

I'm copying the tech-ctte list; eyeballs would be welcome.
Please speak up if you spot an error or omission.

Thanks for your work on Debian,
-- 
Niko Tyni   nt...@debian.org
Index: english/intro/organization.data
===
RCS file: /cvs/webwml/webwml/english/intro/organization.data,v
retrieving revision 1.564
diff -u -r1.564 organization.data
--- english/intro/organization.data	21 Dec 2017 06:52:58 -	1.564
+++ english/intro/organization.data	17 Jan 2018 21:00:23 -
@@ -65,15 +65,14 @@
 
   Leader> 
 
-  Technical Committee> 
+  Technical Committee>  
 Didier Raboud
 Philip Hands
-Sam Hartman
 Tollef Fog Heen
-Keith Packard
 Margarita Manterola
 David Bremner
 Niko Tyni
+Gunnar Wolf
   Secretary>  
 Kurt Roeckx
 
Index: english/devel/tech-ctte.wml
===
RCS file: /cvs/webwml/webwml/english/devel/tech-ctte.wml,v
retrieving revision 1.71
diff -u -r1.71 tech-ctte.wml
--- english/devel/tech-ctte.wml	29 Jan 2017 03:32:44 -	1.71
+++ english/devel/tech-ctte.wml	17 Jan 2018 21:00:23 -
@@ -316,6 +316,12 @@
 Thanks to the following people who have served on the committee:
 
 
+Keith Packard (2013-11-29 - 2017-12-31)
+Sam Hartman (2015-03-08 - 2017-11-09)
+Don Armstrong (2009-09-11 - 2016-12-31)
+Andreas Barth (2006-01-04 - 2016-12-31)
+Steve Langasek (2006-01-04 - 2015-12-31)
+Bdale Garbee (2001-04-17 - 2015-12-31)
 Colin Watson (2011-08-24 - 2015-03-05)
 Ian Jackson (to 2014-11-19)
 Russ Allbery (2009-01-11 - 2014-11-16)

Bug#887555: new upstream (20171222)

[Daniel Baumann]

Package: parallel
Severity: wishlist

Hi,

thanks for maintaining parallel in debian. It would be nice if you could
upgrade the package to the current upstream releases (20171222).

Regards,
Daniel

Bug#887554: RM: ibm-3270 -- ROM

[Bastian Blank]

Package: ftp.debian.org
Severity: normal

Please remove package ibm-3270.

Bastian

Bug#887553: xmltooling-schemas: backport to wheezy update for CVE-2018-0486

[cwseys]

Package: xmltooling-schemas
Version: 1.5.3-2~bpo70+1
Severity: wishlist

Hello,
  Could the security fix for CVE-2018-0486 in 1.5.3+deb8u2 be pretty please
backported to wheezy?
  I don't remember the details, but 1.5.3 supports encryption type that
the wheezy's does not.

Thanks!
C.

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information

Bug#886163: closed by Chris Lamb <la...@debian.org> (Bug#886163: fixed in lintian 2.5.68)

[Adrian Bunk]

Control: reopen -1

On Tue, Jan 09, 2018 at 03:39:22PM +, Debian Bug Tracking System wrote:
>...
>* t/tests/files-multiarch-foreign-files:
>  + [CL] Ensure that we install to a multiarch directory on all
>architectures to prevent a FTBFS on, for example, i386.
>(Closes: #886163)
>...

This seems to have only moved the test failure:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/lintian.html

...
-E: libfoo-dev: multiarch-foreign-cmake-file usr/lib/TRIPLET/cmake/foo.cmake
-E: libfoo-dev: multiarch-foreign-pkgconfig usr/lib/TRIPLET/pkgconfig/libfoo.pc
-E: libfoo-dev: multiarch-foreign-static-library usr/lib/TRIPLET/libfoo.a
+E: libfoo-dev: triplet-dir-and-architecture-mismatch usr/lib/TRIPLET/ is for 
amd64
...

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#868170: libemail-address-perl: Email::Address->parse() is vulnerable to CVE-2015-7686

[Pali Rohár]

On Friday 17 November 2017 23:42:19 Moritz Muehlenhoff wrote:
> On Fri, Nov 17, 2017 at 09:36:46PM +0100, Pali Rohár wrote:
> > On Friday 17 November 2017 12:36:54 Moritz Muehlenhoff wrote:
> > > On Fri, Nov 17, 2017 at 12:03:26PM +0100, Pali Rohár wrote:
> > > > What
> > > > about next, do you have some script or any other tool which can create
> > > > those wishlist bugs for all packages which depend on
> > > > libemail-address-perl package?
> > > 
> > > There's a mass-bug script in 'devscripts", but since there's less than
> > > 20 packages you could also simply file these manually.
> > 
> > Will you or any other maintainer of perl packages do that?
> 
> Anyone can file bugs in the Debian BTS, so why not do it yourself?

Done:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887535
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887536
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887537
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887538
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887539
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887542
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887543
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887544
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887545
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887546
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887547
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887548
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887549
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887550
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887551

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#887475: dh-golang: support comma-separated import paths in dh_golang_autopkgtest

[Alexandre Viau]

Hello,

This version of the patch is simpler. It removes the awk usage and uses
an array.

Cheers,

-- 
Alexandre Viau
av...@debian.org
From fcc17f957630976a5a95a48a17b44e55472a8b4d Mon Sep 17 00:00:00 2001
From: aviau 
Date: Wed, 17 Jan 2018 14:54:58 -0500
Subject: [PATCH] dh_golang_autopkgtest support for several import paths

---
 script/dh_golang_autopkgtest | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/script/dh_golang_autopkgtest b/script/dh_golang_autopkgtest
index c15447a..399daef 100755
--- a/script/dh_golang_autopkgtest
+++ b/script/dh_golang_autopkgtest
@@ -57,19 +57,27 @@ call_rules() {
 }
 
 get_import_path() {
-# Find package's import path from debian/rules or debian/control.
-pkg=$(call_rules apt-print-DH_GOPKG)
+# Find package's main import path from debian/rules or debian/control.
+pkgs=$(call_rules apt-print-DH_GOPKG)
 
-if [ -z "$pkg" ]; then
+if [ -z "$pkgs" ]; then
 # DH_GOPKG not set, find it in control file.
-pkg=$(perl -w -MDpkg::Control::Info -e '
+pkgs=$(perl -w -MDpkg::Control::Info -e '
 my $s = Dpkg::Control::Info->new()->get_source();
 print $s->{"XS-Go-Import-Path"} || "";')
 fi
-if [ -z "$pkg" ]; then
-error "Can't find import path."
+
+if [ -z "$pkgs" ]; then
+error "Can't find import paths."
 fi
-echo "$pkg"
+
+# Transform into a single comma-separated line.
+# Then, replace commas by spaces.
+# Place the result into an array.
+pkgs=($(echo $pkgs | tr -d " \n" | tr "," " "))
+
+# Only return the first import path.
+echo "${pkgs[0]}"
 }
 
 add_configure_override() {
-- 
2.14.2



signature.asc
Description: OpenPGP digital signature

Bug#887552: tox: new version available upstream

[Jeff Cliff]

Source: tox
Version: new version available upstream
Severity: normal

Dear Maintainer,

A new version of tox is apparently available upstream.  At least 2.6, but 
according to the debian PTS up to 2.9.1
https://packages.qa.debian.org/t/tox.html
http://pypi.debian.net/tox/tox-2.9.1.tar.gz
also there is a github repository that seems to have it as well
https://github.com/tox-dev/tox/releases
if that is accurate, the version in debian dates from Nov 16, 2016, 11 releases 
ago.

changelog:
https://tox.readthedocs.io/en/latest/changelog.html

Thank you for your time,
Jeff Cliff

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

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

Bug#887551: request-tracker4 depends on libemail-address-perl

[Pali Rohár]

Package: request-tracker4
Version: 4.4.2-1
Severity: wishlist

Hi! Package request-tracker4 depends on libemail-address-perl which is
vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
provides perl module Email::Address which is now unmaintained. There is
a new perl module Email::Address::XS which is API compatible replacement
for Email::Address and is available in libemail-address-xs-perl. Please
port request-tracker4 package to use libemail-address-xs-perl. If you need
help with porting let me know.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#887550: license-reconcile depends on libemail-address-perl

[Pali Rohár]

Package: license-reconcile
Version: 0.14
Severity: wishlist

Hi! Package license-reconcile depends on libemail-address-perl which is
vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
provides perl module Email::Address which is now unmaintained. There is
a new perl module Email::Address::XS which is API compatible replacement
for Email::Address and is available in libemail-address-xs-perl. Please
port license-reconcile package to use libemail-address-xs-perl. If you need
help with porting let me know.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#887549: libsvn-notify-perl depends on libemail-address-perl

[Pali Rohár]

Package: libsvn-notify-perl
Version: 2.86-1
Severity: wishlist

Hi! Package libsvn-notify-perl depends on libemail-address-perl which is
vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
provides perl module Email::Address which is now unmaintained. There is
a new perl module Email::Address::XS which is API compatible replacement
for Email::Address and is available in libemail-address-xs-perl. Please
port libsvn-notify-perl package to use libemail-address-xs-perl. If you need
help with porting let me know.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#887548: libregexp-common-email-address-perl depends on libemail-address-perl

[Pali Rohár]

Package: libregexp-common-email-address-perl
Version: 1.01-4
Severity: wishlist

Hi! Package libregexp-common-email-address-perl depends on 
libemail-address-perl which is
vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
provides perl module Email::Address which is now unmaintained. There is
a new perl module Email::Address::XS which is API compatible replacement
for Email::Address and is available in libemail-address-xs-perl. Please
port libregexp-common-email-address-perl package to use 
libemail-address-xs-perl. If you need
help with porting let me know.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#887544: libemail-reply-perl depends on libemail-address-perl

[Pali Rohár]

Package: libemail-reply-perl
Version: 1.204-1
Severity: wishlist

Hi! Package libemail-reply-perl depends on libemail-address-perl which is
vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
provides perl module Email::Address which is now unmaintained. There is
a new perl module Email::Address::XS which is API compatible replacement
for Email::Address and is available in libemail-address-xs-perl. Please
port libemail-reply-perl package to use libemail-address-xs-perl. If you need
help with porting let me know.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#887546: libnet-abuse-utils-perl depends on libemail-address-perl

[Pali Rohár]

Package: libnet-abuse-utils-perl
Version: 0.25-1
Severity: wishlist

Hi! Package libnet-abuse-utils-perl depends on libemail-address-perl which is
vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
provides perl module Email::Address which is now unmaintained. There is
a new perl module Email::Address::XS which is API compatible replacement
for Email::Address and is available in libemail-address-xs-perl. Please
port libnet-abuse-utils-perl package to use libemail-address-xs-perl. If you 
need
help with porting let me know.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#887547: libperl-critic-perl depends on libemail-address-perl

[Pali Rohár]

Package: libperl-critic-perl
Version: 1.130-1
Severity: wishlist

Hi! Package libperl-critic-perl depends on libemail-address-perl which is
vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
provides perl module Email::Address which is now unmaintained. There is
a new perl module Email::Address::XS which is API compatible replacement
for Email::Address and is available in libemail-address-xs-perl. Please
port libperl-critic-perl package to use libemail-address-xs-perl. If you need
help with porting let me know.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#887545: libemail-sender-perl depends on libemail-address-perl

[Pali Rohár]

Package: libemail-sender-perl
Version: 1.300031-1
Severity: wishlist

Hi! Package libemail-sender-perl depends on libemail-address-perl which is
vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
provides perl module Email::Address which is now unmaintained. There is
a new perl module Email::Address::XS which is API compatible replacement
for Email::Address and is available in libemail-address-xs-perl. Please
port libemail-sender-perl package to use libemail-address-xs-perl. If you need
help with porting let me know.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#887543: libemail-find-perl depends on libemail-address-perl

[Pali Rohár]

Package: libemail-find-perl
Version: 0.10-dfsg-3
Severity: wishlist

Hi! Package libemail-find-perl depends on libemail-address-perl which is
vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
provides perl module Email::Address which is now unmaintained. There is
a new perl module Email::Address::XS which is API compatible replacement
for Email::Address and is available in libemail-address-xs-perl. Please
port libemail-find-perl package to use libemail-address-xs-perl. If you need
help with porting let me know.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#887542: libemail-address-list-perl depends on libemail-address-perl

[Pali Rohár]

Package: libemail-address-list-perl
Version: 0.05-1
Severity: wishlist

Hi! Package libemail-address-list-perl depends on libemail-address-perl which is
vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
provides perl module Email::Address which is now unmaintained. There is
a new perl module Email::Address::XS which is API compatible replacement
for Email::Address and is available in libemail-address-xs-perl. Please
port libemail-address-list-perl package to use libemail-address-xs-perl. If you 
need
help with porting let me know.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#887539: libdist-zilla-localetextdomain-perl depends on libemail-address-perl

[Pali Rohár]

Package: libdist-zilla-localetextdomain-perl
Version: 0.91-1
Severity: wishlist

Hi! Package libdist-zilla-localetextdomain-perl depends on 
libemail-address-perl which is
vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
provides perl module Email::Address which is now unmaintained. There is
a new perl module Email::Address::XS which is API compatible replacement
for Email::Address and is available in libemail-address-xs-perl. Please
port libdist-zilla-localetextdomain-perl package to use 
libemail-address-xs-perl. If you need
help with porting let me know.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#887540: RM: python-dvdvideo -- ROM

[Bastian Blank]

Package: ftp.debian.org
Severity: normal

Please remove package python-dvdvideo.

Bastian

Bug#887541: RM: uucp-lmtp -- ROM

[Bastian Blank]

Package: ftp.debian.org
Severity: normal

Please remove package uucp-lmtp.

Bastian

Bug#887538: libdata-validate-email-perl depends on libemail-address-perl

[Pali Rohár]

Package: libdata-validate-email-perl
Version: 0.06-1
Severity: wishlist

Hi! Package libdata-validate-email-perl depends on libemail-address-perl which 
is
vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
provides perl module Email::Address which is now unmaintained. There is
a new perl module Email::Address::XS which is API compatible replacement
for Email::Address and is available in libemail-address-xs-perl. Please
port libdata-validate-email-perl package to use libemail-address-xs-perl. If 
you need
help with porting let me know.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#887537: libcourriel-perl depends on libemail-address-perl

[Pali Rohár]

Package: libcourriel-perl
Version: 0.45-1
Severity: wishlist

Hi! Package libcourriel-perl depends on libemail-address-perl which is
vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
provides perl module Email::Address which is now unmaintained. There is
a new perl module Email::Address::XS which is API compatible replacement
for Email::Address and is available in libemail-address-xs-perl. Please
port libcourriel-perl package to use libemail-address-xs-perl. If you need
help with porting let me know.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#887535: ciderwebmail depends on libemail-address-perl

[Pali Rohár]

Package: ciderwebmail
Version: 1.05+20150729-3
Severity: wishlist

Hi! Package ciderwebmail depends on libemail-address-perl which is
vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
provides perl module Email::Address which is now unmaintained. There is
a new perl module Email::Address::XS which is API compatible replacement
for Email::Address and is available in libemail-address-xs-perl. Please
port ciderwebmail package to use libemail-address-xs-perl. If you need
help with porting let me know.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#887536: dh-make-perl depends on libemail-address-perl

[Pali Rohár]

Package: dh-make-perl
Version: 0.98
Severity: wishlist

Hi! Package dh-make-perl depends on libemail-address-perl which is
vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
provides perl module Email::Address which is now unmaintained. There is
a new perl module Email::Address::XS which is API compatible replacement
for Email::Address and is available in libemail-address-xs-perl. Please
port dh-make-perl package to use libemail-address-xs-perl. If you need
help with porting let me know.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#886506: Installing busybox-static worked

[Gerhard Hellmann]

Can confirm that installing busybox-static allowed me to boot the
kernel. Thanks for the suggestion and the analysis.


signature.asc
Description: PGP signature

Bug#887534: plume-creator FTBFS with libquazip5-headers 0.7.3-3

[Adrian Bunk]

Source: plume-creator
Version: 0.66+dfsg1-3.1
Severity: serious
Tags: buster sid

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

...
g++ -c -pipe -O2 -Wall -W -D_REENTRANT -fPIC -DVERSIONSTR=\"0.67\" 
-DDATADIR=\"/usr/share/plume-creator\" -DQT_NO_DEBUG -DQT_PRINTSUPPORT_LIB 
-DQT_WIDGETS_LIB -DQT_MULTIMEDIA_LIB -DQT_GUI_LIB -DQT_XML_LIB -DQT_NETWORK_LIB 
-DQT_CORE_LIB -I. -I. -Isrc -Iexternals/qtsingleapplication/src -isystem 
/usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtMultimedia -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtXml -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -I. -isystem /usr/include/libdrm -I. 
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o main.o src/main.cpp
In file included from src/zipper/zipchecker.h:28:0,
 from src/zipper/zipper.h:25,
 from src/hub.h:33,
 from src/mainwindow.h:28,
 from src/main.cpp:27:
src/common/utils.h:25:10: fatal error: quazip/JlCompress.h: No such file or 
directory
 #include 
  ^
compilation terminated.
Makefile:2631: recipe for target 'main.o' failed
make[1]: *** [main.o] Error 1

Bug#887250: systemd should depend on e2fsprogs explicitly

[Helmut Grohne]

Control: severity -1 minor

I think thus far, nobody has done the analysis part for systemd.

On Sun, Jan 14, 2018 at 08:11:47PM +0100, Helmut Grohne wrote:
> /bin/journalctl contains chattr. According to file it is a ELF 64-bit LSB 
> shared object, x86-64, version 1 (SYSV)
> /bin/systemd-tmpfiles contains chattr. According to file it is a ELF 64-bit 
> LSB shared object, x86-64, version 1 (SYSV)

False positives: chattr_fd

> /lib/systemd/libsystemd-shared-236.so contains chattr and debugfs. According 
> to file it is a ELF 64-bit LSB shared object, x86-64, version 1 (SYSV)

False positives:
 * chattr_fd
 * chattr_path
 * chattr-util.c
 * ..."consider turning off the copy-on-write file attribute on the
   journal directory, using chattr +C."
 * debugfs is used in a filesystem type list.

> /lib/systemd/system-generators/systemd-cryptsetup-generator contains mke2fs. 
> According to file it is a ELF 64-bit LSB shared object, x86-64, version 1 
> (SYSV)

Actually generates a .service file with:

ExecStartPost=/sbin/mke2fs '/dev/mapper/%s'

It's used when a crypttab entry uses the tmp= option. This is
not part of any default install as we tend to use a tmpfs for /tmp
there. Despite the crypttab option supporting fstype, the generator
really only supports mke2fs. Yes, it will create an ext2 filesystem.
Does anybody really use that feature?

> /lib/systemd/system/sys-kernel-debug.mount contains debugfs. According to 
> file it is a ASCII text

False positive. Yeah, it's about the kernel filesystem type.

> /lib/udev/rules.d/99-systemd.rules contains mke2fs. According to file it is a 
> ASCII text

False positive. It does contain mke2fs in a comment.

Given these, the only actual use is the systemd-cryptsetup-generator.
The relevant option is not used by default. The option parsing is
inconsistent with cryptsetup's description of the option. (Should I file
a bug about that?) Poking random developers at the option resulted in
"weird option".

I think it warrants a "Suggests" at most.

I'm in favour of just closing the bug. Does anyone disagree?

Helmut

Bug#887533: RM: shelxle [armel armhf] -- RoQA; no loner builds on architectures where Qt5 uses OpenGL ES

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal


shelxle (1.0.888-1) unstable; urgency=medium
...
  * debian/control (Build-Depends): Use libqt5opengl5-desktop-dev instead of
libqt5opengl5-dev (closes: #887458). ...
...
 -- Daniel Leidert   Wed, 17 Jan 2018 17:11:02 +0100

Bug#887532: wicd: Does not take into account hard rfkill when turning on Wifi.

[Jeremy Ouellet]

Package: wicd
Version: 1.7.4+tb2-5
Severity: important

Dear Maintainer,

I noticed that when using the airplane mode switch on my laptop (that toggles
both soft and hard rfkill), wicd does not check the hard rfkill status before
toggling the soft rfkill. This causes a problem as the switch simply toggles
both rfkills which makes it so that pressing the airplane mode switch again
disables the hard lock but re-enables the soft lock, and so on.

The workaround is to press airplane mode again, then go into wicd, press the
"Turn On Wifi" button and finnally press the airplane mode switch again.

A solution would be to stop the user from removing the soft rfkill if a hard
rfkill is in place.

Also the label for the "Turn On Wifi" and "Turn Off Wifi" does not change when
rfkill is manually changed, adding to the confusion.



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

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

Versions of packages wicd depends on:
ii  wicd-curses [wicd-client]  1.7.4+tb2-5
ii  wicd-daemon1.7.4+tb2-5
ii  wicd-gtk [wicd-client] 1.7.4+tb2-5

wicd recommends no packages.

wicd suggests no packages.

Versions of packages wicd-gtk depends on:
ii  python 2.7.14-4
ii  python-glade2  2.24.0-5.1+b1
ii  python-gtk22.24.0-5.1+b1
ii  wicd-daemon1.7.4+tb2-5

Versions of packages wicd-gtk recommends:
ii  gksu   2.0.2-9+b1
ii  python-notify  0.1.1-4

Versions of packages wicd-curses depends on:
ii  python2.7.14-4
ii  python-urwid  1.3.1-2+b2
ii  wicd-daemon   1.7.4+tb2-5

Versions of packages wicd-curses recommends:
ii  sudo  1.8.21p2-3

Versions of packages wicd-daemon depends on:
ii  adduser  3.116
ii  dbus 1.12.2-1
ii  debconf  1.5.65
ii  iputils-ping 3:20161105-1
ii  isc-dhcp-client  4.3.5-3+b2
ii  lsb-base 9.20170808
ii  psmisc   23.1-1
ii  python   2.7.14-4
ii  python-dbus  1.2.4-1+b4
ii  python-gobject   3.26.1-2
ii  python-wicd  1.7.4+tb2-5
ii  wireless-tools   30~pre9-12+b1
ii  wpasupplicant2:2.6-15

Versions of packages wicd-daemon recommends:
ii  rfkill 0.5-3
ii  wicd-curses [wicd-client]  1.7.4+tb2-5
ii  wicd-gtk [wicd-client] 1.7.4+tb2-5

Versions of packages wicd-daemon suggests:
pn  pm-utils  

Versions of packages python-wicd depends on:
ii  net-tools  1.60+git20161116.90da8a0-1
ii  python 2.7.14-4

Versions of packages python-wicd suggests:
ii  ethtool   1:4.11-1
ii  iproute2  4.14.1-1

-- debconf information:
* wicd/users:

Bug#887482: xorg-server: FTBFS: dh_autoreconf can only be run once

[Sven Joachim]

On 2018-01-17 00:40 -0800, Daniel Schepler wrote:

> Source: xorg-server
> Version: 2:1.19.5-1
> Severity: serious
>
> From my pbuilder build log:
>
> ...
> make[6]: Leaving directory
> '/build/xorg-server-1.19.5/debian/build/udeb/test/xi2'
> make[5]: Leaving directory '/build/xorg-server-1.19.5/debian/build/udeb/test'
> make[4]: Leaving directory '/build/xorg-server-1.19.5/debian/build/udeb/test'
> make[4]: Entering directory '/build/xorg-server-1.19.5/debian/build/udeb'
> make[4]: Nothing to be done for 'all-am'.
> make[4]: Leaving directory '/build/xorg-server-1.19.5/debian/build/udeb'
> make[3]: Leaving directory '/build/xorg-server-1.19.5/debian/build/udeb'
> make[2]: Leaving directory '/build/xorg-server-1.19.5'
>   debian/rules override_dh_auto_test
> make[2]: Entering directory '/build/xorg-server-1.19.5'
> dh_auto_test -- -j1 VERBOSE=1
> make[2]: Leaving directory '/build/xorg-server-1.19.5'
> make[1]: Leaving directory '/build/xorg-server-1.19.5'
>   dh_quilt_patch -O--parallel -Nxserver-common -Nxorg-server-source
> File series fully applied, ends at patch 06_use-intel-only-on-pre-gen4.diff
>   dh_update_autotools_config -O--parallel -Nxserver-common 
> -Nxorg-server-source
>   dh_autoreconf -O--parallel -Nxserver-common -Nxorg-server-source
> dh_autoreconf: Can only be run once, see dh-autoreconf(7)
> debian/rules:8: recipe for target 'build' failed
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
>
> On further testing, it seems that on a freshly unpacked source, either
> "dpkg-buildpackage -B" or "dpkg-buildpackage -A" separately will work;
> but "dpkg-buildpackage -b" will fail with the above error.

This seems to have been triggered by the sequence handling rewrite in
debhelper 11.1, at least I was not able to reproduce it anymore after
downgrading debhelper to version 11.

In debhelper 11, the sequence of commands dh runs is this:

,
| $ dh build --no-act
|dh_testdir
|dh_update_autotools_config
|debian/rules override_dh_auto_configure
|debian/rules override_dh_auto_build
|debian/rules override_dh_auto_test
|debian/rules build-indep
`

Whereas in 11.1.2 dh runs the following sequence:

,
| $ dh build --no-act
|debian/rules build-indep
|dh_testdir -Nxserver-common -Nxorg-server-source
|dh_update_autotools_config -Nxserver-common -Nxorg-server-source
|debian/rules override_dh_auto_configure
|debian/rules override_dh_auto_build
|debian/rules override_dh_auto_test
`

This causes dh_autoreconf to be run twice, first via the build-indep
rule and then as part of the standard dh sequence.  Some advice from the
debhelper maintainer (CC'ed) would be appreciated.

Cheers,
   Sven

Bug#887531: python-asdf FTBFS: test failures

[Adrian Bunk]

Source: python-asdf
Version: 1.3.1-1
Severity: serious

Some recent change in unstable makes python-asdf FTBFS:

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

...
=== FAILURES ===
_ test_urlopen[tree0] __

tree = {'not_shared': array([10,  9,  8,  7,  6,  5,  4,  3,  2,  1], 
dtype=uint8), 'science_data': array([ 0.,  1.,  2.,  3.,  4.,  5.,  6.,  7.,  
8.,  9.]), 'skipping': array([ 0.,  2.,  4.,  6.,  8.]), 'subset': array([ 3.,  
4.,  5.,  6.])}
httpserver = 

@pytest.mark.skipif(INTERNET_OFF, reason="Astropy has disabled internet 
access")
@pytest.mark.skipif(sys.platform.startswith('win'),
reason="Windows firewall prevents test")
def test_urlopen(tree, httpserver):
path = os.path.join(httpserver.tmpdir, 'test.asdf')

def get_write_fd():
return generic_io.get_file(open(path, 'wb'), mode='w')

def get_read_fd():
return generic_io.get_file(
urllib_request.urlopen(
httpserver.url + "test.asdf"))

>   with _roundtrip(tree, get_write_fd, get_read_fd) as ff:

asdf/tests/test_generic_io.py:270: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
asdf/tests/test_generic_io.py:72: in _roundtrip
with get_read_fd() as fd:
asdf/tests/test_generic_io.py:268: in get_read_fd
httpserver.url + "test.asdf"))
/usr/lib/python2.7/urllib2.py:154: in urlopen
return opener.open(url, data, timeout)
/usr/lib/python2.7/urllib2.py:429: in open
response = self._open(req, data)
/usr/lib/python2.7/urllib2.py:447: in _open
'_open', req)
/usr/lib/python2.7/urllib2.py:407: in _call_chain
result = func(*args)
/usr/lib/python2.7/urllib2.py:1228: in http_open
return self.do_open(httplib.HTTPConnection, req)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = 
http_class = 
req = , http_conn_args = {}
host = '127.0.0.1:9', h = 
err = error(111, 'Connection refused')

def do_open(self, http_class, req, **http_conn_args):
"""Return an addinfourl object for the request, using http_class.

http_class must implement the HTTPConnection API from httplib.
The addinfourl return value is a file-like object.  It also
has methods and attributes including:
- info(): return a mimetools.Message object for the headers
- geturl(): return the original request URL
- code: HTTP status code
"""
host = req.get_host()
if not host:
raise URLError('no host given')

# will parse host:port
h = http_class(host, timeout=req.timeout, **http_conn_args)
h.set_debuglevel(self._debuglevel)

headers = dict(req.unredirected_hdrs)
headers.update(dict((k, v) for k, v in req.headers.items()
if k not in headers))

# We want to make an HTTP/1.1 request, but the addinfourl
# class isn't prepared to deal with a persistent connection.
# It will try to read all remaining data from the socket,
# which will block while the server waits for the next request.
# So make sure the connection gets closed after the (only)
# request.
headers["Connection"] = "close"
headers = dict(
(name.title(), val) for name, val in headers.items())

if req._tunnel_host:
tunnel_headers = {}
proxy_auth_hdr = "Proxy-Authorization"
if proxy_auth_hdr in headers:
tunnel_headers[proxy_auth_hdr] = headers[proxy_auth_hdr]
# Proxy-Authorization should not be sent to origin
# server.
del headers[proxy_auth_hdr]
h.set_tunnel(req._tunnel_host, headers=tunnel_headers)

try:
h.request(req.get_method(), req.get_selector(), req.data, headers)
except socket.error, err: # XXX what error?
h.close()
>   raise URLError(err)
E   URLError: 

/usr/lib/python2.7/urllib2.py:1198: URLError
_ test_urlopen[tree1] __

tree = {'more': array([[[ 0.5047124 ,  0.67230725,  0.54438082, ...,  0.6181783 
,
  0.86328092,  0.20516376, ...,...738, ...,  0.77406934,
 0.85... 0.98452297,  0.2701272 , ...,  0.70554981,
 0.99484383,  0.83053795]])}
httpserver = 

@pytest.mark.skipif(INTERNET_OFF, reason="Astropy has disabled internet 
access")
@pytest.mark.skipif(sys.platform.startswith('win'),
reason="Windows firewall prevents test")
def test_urlopen(tree, httpserver):
path = 

Bug#878633: python-pgpy FTBFS with more than one supported Python3 version

[Michael Greene]

I haven't tried this in the rules file myself, but these commands
should work:
# python 3  LC_ALL=C.UTF-8 py.test-3 tests/
# python 2LC_ALL=C.UTF-8 py.test tests/
On Fri, 2018-01-12 at 14:18 -0500, Daniel Kahn Gillmor wrote:
> On Sun 2017-10-15 13:50:56 +0300, Adrian Bunk wrote:
> > ...
> >debian/rules override_dh_auto_test
> > make[1]: Entering directory '/build/1st/python-pgpy-0.4.3'
> > LC_ALL=C.UTF-8 dh_auto_test -O--buildsystem=pybuild
> > I: pybuild base:184: cd /build/1st/python-pgpy-
> > 0.4.3/.pybuild/pythonX.Y_3.5/build; python3.5 -m pytest tests
> > Traceback (most recent call last):
> >   File "/usr/lib/python3/dist-packages/_pytest/config.py", line
> > 342, in _getconftestmodules
> > return self._path2confmods[path]
> > KeyError: local('/build/1st/python-pgpy-
> > 0.4.3/.pybuild/pythonX.Y_3.5/build/tests')
> > 
> > During handling of the above exception, another exception occurred:
> > Traceback (most recent call last):
> >   File "/usr/lib/python3/dist-packages/_pytest/config.py", line
> > 373, in _importconftest
> > return self._conftestpath2mod[conftestpath]
> > KeyError: local('/build/1st/python-pgpy-
> > 0.4.3/.pybuild/pythonX.Y_3.5/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.5/importlib/__init__.py", line 126, in
> > import_module
> > return _bootstrap._gcd_import(name[level:], package, level)
> >   File "", line 985, in _gcd_import
> >   File "", line 968, in _find_and_load
> >   File "", line 955, in
> > _find_and_load_unlocked
> > ImportError: 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.py", line
> > 379, in _importconftest
> > mod = conftestpath.pyimport()
> >   File "/usr/lib/python3/dist-packages/py/_path/local.py", line
> > 662, in pyimport
> > __import__(modname)
> >   File "/usr/lib/python3/dist-
> > packages/_pytest/assertion/rewrite.py", line 212, in load_module
> > py.builtin.exec_(co, mod.__dict__)
> >   File "/build/1st/python-pgpy-
> > 0.4.3/.pybuild/pythonX.Y_3.5/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.5/importlib/__init__.py", line 126, in
> > import_module
> > return _bootstrap._gcd_import(name[level:], package, level)
> > ImportError: No module named '_gpgme'
> > ERROR: could not load /build/1st/python-pgpy-
> > 0.4.3/.pybuild/pythonX.Y_3.5/build/tests/conftest.py
> > 
> > E: pybuild pybuild:283: test: plugin distutils failed with: exit
> > code=4: cd /build/1st/python-pgpy-
> > 0.4.3/.pybuild/pythonX.Y_3.5/build; python3.5 -m pytest tests
> > dh_auto_test: pybuild --test --test-pytest -i python{version} -p
> > "3.5 3.6" returned exit code 13
> > debian/rules:13: recipe for target 'override_dh_auto_test' failed
> > make[1]: *** [override_dh_auto_test] Error 25
> > 
> > Either #866555 needs fixing or as workaround the tests
> > should run only with the default python3 version.
> 
> this does indeed seem to be related to #866555, which doesn't seem
> like
> it will be fixed upstream, and i don't want to carry a diff for.  so
> i
> suppose we should limit python-pgpy  to only run the tests against
> the
> default python3 version.  If there's a canonical way to do that, i'd
> be
> happy to see the pointers to it, otherwise i'll just blunder along
> and
> see what i can figure out.
> 
> --dkg

-- 
Michael Greene
Software Engineer
mgre...@securityinnovation.com

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

Bug#887530: cen64-qt FTBFS with libquazip5-headers 0.7.3-3

[Adrian Bunk]

Source: cen64-qt
Version: 20160829-alpha-1
Severity: serious

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

...
g++ -c -pipe -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -Wall -W -D_REENTRANT -fPIC -DQT_NO_DEBUG 
-DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_XML_LIB -DQT_SQL_LIB 
-DQT_CORE_LIB -I. -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtXml -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtSql -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -I. -isystem /usr/include/libdrm -I. 
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o common.o src/common.cpp
src/common.cpp:43:10: fatal error: quazip/quazip.h: No such file or directory
 #include 
  ^
compilation terminated.
Makefile:554: recipe for target 'common.o' failed
make[1]: *** [common.o] Error 1

Bug#887529: aiohttp-cors FTBFS: test errors

[Adrian Bunk]

Source: aiohttp-cors
Version: 0.5.3-1
Severity: serious

Some recent change in unstable makes aiohttp-cors FTBFS:

https://tests.reproducible-builds.org/debian/history/aiohttp-cors.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/aiohttp-cors.html

...
 ERRORS 
_ ERROR at teardown of TestMain.test_preflight_default _

self = 

def tearDown(self):
self.session.close()

if self.server is not None:
>   self.loop.run_until_complete(self.shutdown_server())

tests/integration/test_main.py:70: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3.6/asyncio/base_events.py:467: in run_until_complete
return future.result()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = 

@asyncio.coroutine
def shutdown_server(self):
"""Shutdown server."""
assert self.server is not None

self.server.close()
>   yield from self.handler.finish_connections()
E   AttributeError: 'Server' object has no attribute 'finish_connections'

tests/integration/test_main.py:101: AttributeError
__ ERROR at teardown of TestMain.test_simple_default ___

self = 

def tearDown(self):
self.session.close()

if self.server is not None:
>   self.loop.run_until_complete(self.shutdown_server())

tests/integration/test_main.py:70: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3.6/asyncio/base_events.py:467: in run_until_complete
return future.result()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = 

@asyncio.coroutine
def shutdown_server(self):
"""Shutdown server."""
assert self.server is not None

self.server.close()
>   yield from self.handler.finish_connections()
E   AttributeError: 'Server' object has no attribute 'finish_connections'

tests/integration/test_main.py:101: AttributeError
___ ERROR at teardown of TestMain.test_simple_expose_headers ___

self = 

def tearDown(self):
self.session.close()

if self.server is not None:
>   self.loop.run_until_complete(self.shutdown_server())

tests/integration/test_main.py:70: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3.6/asyncio/base_events.py:467: in run_until_complete
return future.result()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = 

@asyncio.coroutine
def shutdown_server(self):
"""Shutdown server."""
assert self.server is not None

self.server.close()
>   yield from self.handler.finish_connections()
E   AttributeError: 'Server' object has no attribute 'finish_connections'

tests/integration/test_main.py:101: AttributeError
__ ERROR at teardown of TestMain.test_simple_with_credentials __

self = 

def tearDown(self):
self.session.close()

if self.server is not None:
>   self.loop.run_until_complete(self.shutdown_server())

tests/integration/test_main.py:70: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3.6/asyncio/base_events.py:467: in run_until_complete
return future.result()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = 

@asyncio.coroutine
def shutdown_server(self):
"""Shutdown server."""
assert self.server is not None

self.server.close()
>   yield from self.handler.finish_connections()
E   AttributeError: 'Server' object has no attribute 'finish_connections'

tests/integration/test_main.py:101: AttributeError
=== FAILURES ===
__ TestMain.test_dummy_setup ___

self = 

def tearDown(self):
self.session.close()

if self.server is not None:
>   self.loop.run_until_complete(self.shutdown_server())

tests/integration/test_main.py:70: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3.6/asyncio/base_events.py:467: in run_until_complete
return future.result()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = 

@asyncio.coroutine
def shutdown_server(self):
"""Shutdown server."""
assert self.server is not None

self.server.close()
>   yield from self.handler.finish_connections()
E   AttributeError: 'Server' object has no attribute 'finish_connections'

tests/integration/test_main.py:101: AttributeError
_ TestMain.test_dummy_setup_roundtrip __

Bug#887528: libgctp0d: broken dependency in symbols file

[Adrian Bunk]

Package: libgctp0d
Version: 2.0-3
Severity: serious
Control: affects -1 src:hdf-eos4 src:hdf-eos5 src:ncl src:ruby-hdfeos5

The syntax of the dependency in the new symbols file is not correct:

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

...
dpkg-shlibdeps: error: invalid dependency got generated: libhdf5-100, libgctp0d 
2.0-1, libhe5-hdfeos0, libruby2.3 (>= 2.3.0~preview2), libc6 (>= 2.14), 
libgmp10 
dh_shlibdeps: dpkg-shlibdeps -Tdebian/ruby-hdfeos5.substvars 
debian/ruby-hdfeos5/usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/2.3.0/numru/hdfeos5raw.so
 returned exit code 255
dh_shlibdeps: Aborting due to earlier error
debian/rules:17: recipe for target 'binary' failed
make: *** [binary] Error 25

Bug#887527: ITP: pico2wave -- command line text-to-speech converter

[Paolo Greppi]

Package: wnpp
Severity: wishlist
Owner: Paolo Greppi 

* Package name: pico2wave
  Version : 1.0.0
  Upstream Author : Paolo Greppi 
* URL : https://salsa.debian.org/paolog-guest/pico2wave
* License : Apache-2.0
  Programming Lang: C
  Description : command line text-to-speech converter

 pico2wave is a command-line utility to convert text to speech
 using the SVOX Pico engine.
 It accepts the text either on the command line or from stdin,
 and writes to a WAV file.

The pico2wave utility is already available in debian.
The binary ATM is somewhat confusingly provided by libttspico-utils.

AS per https://bugs.debian.org/883156, svox version 1.0+git20130326-8 already 
includes my patch to support stdin, albeit up to 32767 characters.

The idea is to separate the libttspico-utils binary package from the svox 
source package.
In this way it will have its own version number, plus the code would not be in 
a patch but in plaintext.

It will produce a new binary pico2wave and a transitional libttspico-utils as 
per:
https://wiki.debian.org/RenamingPackages

The plan is also to overcome the 32767 characters limitation by:
1. breaking up the text in chunks of < 32767 characters using some sort of 
elementary Sentence Boundary Detection algorithm
2. process the chunks in the synthesis loop

sthibault has agreed to sponsor the upload.

Paolo

Bug#887526: nuget: Nuget does not install packages

[Simon Heath]

Package: nuget
Version: 2.8.7+md510+dhx1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Upon trying to use nuget to install a package I get a message along the lines 
of:

$ nuget install nunit
> X already has a dependency defined for Y.

The exact X and Y vary depending on the package I'm trying to build, but I've 
been
unable to install any packages at all.

This appears to be the same bug described here:

https://stackoverflow.com/questions/25725545/nuget-x-already-has-a-dependency-defined-for-y#25844391

Running `nuget update -self` resolves the problem.

Thank you,
Simon Heath


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

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

Versions of packages nuget depends on:
ii  libmono-corlib4.5-cil 4.6.2.7+dfsg-1
ii  libmono-microsoft-build-engine4.0-cil 4.6.2.7+dfsg-1
ii  libmono-microsoft-build-framework4.0-cil  4.6.2.7+dfsg-1
ii  libmono-microsoft-build4.0-cil4.6.2.7+dfsg-1
ii  libmono-microsoft-csharp4.0-cil   4.6.2.7+dfsg-1
ii  libmono-system-componentmodel-composition4.0-cil  4.6.2.7+dfsg-1
ii  libmono-system-core4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-xml-linq4.0-cil4.6.2.7+dfsg-1
ii  libmono-system4.0-cil 4.6.2.7+dfsg-1
ii  libnuget-core-cil 2.8.7+md510+dhx1-1
ii  mono-runtime  4.6.2.7+dfsg-1

nuget recommends no packages.

nuget suggests no packages.

-- no debconf information

Bug#865592: chromium version 59: xml/xslt pages crashe in aw, Snap!

[Joseph Rawson]

It seems that this bug only happens in chromium builds with shared libxml.

https://bugs.chromium.org/p/chromium/issues/detail?id=736026#c29

This has actually been happening for me long before the initial bug
report.  I have been using firefox to access our state's legislature, under
the impression that I had an extension interfering.  Hopefully upstream
will have a fix soon.

Bug#887525: poppler FTBFS with gtk-doc-tools 1.27-1

[Adrian Bunk]

Source: poppler
Version: 0.61.1-2
Severity: serious

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

...
make[3]: Entering directory '/build/1st/poppler-0.61.1/obj-x86_64-linux-gnu'
cd /build/1st/poppler-0.61.1/obj-x86_64-linux-gnu && /usr/bin/cmake -E 
cmake_depends "Unix Makefiles" /build/1st/poppler-0.61.1 
/build/1st/poppler-0.61.1/qt5/tests 
/build/1st/poppler-0.61.1/obj-x86_64-linux-gnu 
/build/1st/poppler-0.61.1/obj-x86_64-linux-gnu/qt5/tests 
/build/1st/poppler-0.61.1/obj-x86_64-linux-gnu/qt5/tests/CMakeFiles/check_qt5_search.dir/DependInfo.cmake
 --color=
WARNING:root:Running scanner failed: [Errno 2] No such file or directory, 
command: LD_LIBRARY_PATH=/build/1st/poppler-0.61.1/obj-x86_64-linux-gnu/glib 
./poppler-scan
Traceback (most recent call last):
  File "../../../make-glib-api-docs", line 66, in 
gtkdoc.generate(not args.skip_html)
  File "/build/1st/poppler-0.61.1/gtkdoc.py", line 143, in generate
self._run_gtkdoc_scangobj()
  File "/build/1st/poppler-0.61.1/gtkdoc.py", line 338, in _run_gtkdoc_scangobj
env=env, cwd=self.output_dir)
  File "/build/1st/poppler-0.61.1/gtkdoc.py", line 209, in _run_command
% (args[0], process.returncode))
Exception: gtkdoc-scangobj produced a non-zero return code 1
glib/reference/CMakeFiles/glib-docs.dir/build.make:63: recipe for target 
'glib/reference/glib-docs-build.stamp' failed
make[3]: *** [glib/reference/glib-docs-build.stamp] Error 1

Bug#887520: nbd-client: does not connect if export is named "server-media"

[Wouter Verhelst]

Hi Gregor,

On Wed, Jan 17, 2018 at 06:12:59PM +0100, Gregor Zattler wrote:
> Package: nbd-client
> Version: 1:3.15.2-3
> Severity: normal
> 
> Dear Maintainer,
> 
> I do not know if this is a nbd-client or nbd-server related bug:
> 
> There is a nbd server version 1:3.16.2-1 running on a debian
> testing/buster server with amongst others this definition of an
> export in /etc/nbd-server/config:
> 
> [server-media]
> exportname = /dev/sda5

If you're doing that, you need to ensure that the NBD server has access
to /dev/sda5, at least read access (but possibly write access, too). Out
of the box, this is not possible (you can export files too).

In order to do so, you have two options:

- Either tell udev to change ownership and/or permissions of /dev/sda5
  so that a process running as the "nbd" user and/or group can read (and
  possibly write) to the device;
- Or comment out or change the "user" and/or "group" setting in the
  configuration file, so that the user and/or group are no longer set to
  "nbd" but instead to "disk" or left as "root".

If you don't do either of those, then the nbd-server will not have
access to the partitions and cannot possibly export it.

> flush = true
> fua = true
> 
> When I connect to this export with nbd-client version 1:3.15.2-3
> from a debian stretch system I get:
> 
> $ sudo nbd-client  -name server-media shi /dev/nbd1
> Negotiation: ..Error: Read failed: End of file
> Exiting.

This is the normal error message you get when the server cannot access
the device in question.

> When I rename this export on the server to "shi-media", restart the
> nbd-server.service and do:
> 
> $ sudo nbd-client  -name shi-media shi /dev/nbd1
> Negotiation: ..size = 921600MB
> bs=1024, sz=966367641600 bytes

I suspect that something changed related to permissions in between the
two runs, and that that, rather than the name change, is responsible for
it succeeding the second time.

> I would assume this bug applies to all export names beginning
> with "server-".
> 
> It should be possible to use export names beginning with
> "server-" or at least this restriction should be documented.

There is no such restriction. The only restrictions existing for export
names are one of length (4096 bytes maximum, although "only" 256 should
be used if one desires to remain compatible with other implementations)
and a practical one of legal characters for section headers implemented
by glib's GKeyFile API.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#887524: fish FTBFS: install-translations fails

[Adrian Bunk]

Source: fish
Version: 2.7.1-1
Severity: serious

https://buildd.debian.org/status/package.php?p=fish=sid

...
Installing translations...
/usr/bin/install: cannot create directory ‘/test’: Permission denied
/usr/bin/install: cannot create regular file 
'/test/root/./share/locale/en/LC_MESSAGES/fish.mo': No such file or directory
/usr/bin/install: cannot create directory ‘/test’: Permission denied
/usr/bin/install: cannot create regular file 
'/test/root/./share/locale/nn/LC_MESSAGES/fish.mo': No such file or directory
/usr/bin/install: cannot create directory ‘/test’: Permission denied
/usr/bin/install: cannot create regular file 
'/test/root/./share/locale/nb/LC_MESSAGES/fish.mo': No such file or directory
/usr/bin/install: cannot create directory ‘/test’: Permission denied
/usr/bin/install: cannot create regular file 
'/test/root/./share/locale/sv/LC_MESSAGES/fish.mo': No such file or directory
/usr/bin/install: cannot create directory ‘/test’: Permission denied
/usr/bin/install: cannot create regular file 
'/test/root/./share/locale/fr/LC_MESSAGES/fish.mo': No such file or directory
/usr/bin/install: cannot create directory ‘/test’: Permission denied
/usr/bin/install: cannot create regular file 
'/test/root/./share/locale/de/LC_MESSAGES/fish.mo': No such file or directory
/usr/bin/install: cannot create directory ‘/test’: Permission denied
/usr/bin/install: cannot create regular file 
'/test/root/./share/locale/pt_BR/LC_MESSAGES/fish.mo': No such file or directory
/usr/bin/install: cannot create directory ‘/test’: Permission denied
/usr/bin/install: cannot create regular file 
'/test/root/./share/locale/pl/LC_MESSAGES/fish.mo': No such file or directory
/usr/bin/install: cannot create directory ‘/test’: Permission denied
/usr/bin/install: cannot create regular file 
'/test/root/./share/locale/zh_CN/LC_MESSAGES/fish.mo': No such file or directory
Makefile:775: recipe for target 'install-translations' failed
make[2]: *** [install-translations] Error 1