Bug#887585: stealth: missing build dependency on texlive-latex-extra
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
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
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
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 FreeImage_SetOutputMessage(F
Bug#887571: [debhelper-devel] Bug#887571: debhelper: dh lies about what it does, breaks builds by creating new files, etc
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
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: > 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
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
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: incl
Bug#887575: castle-game-engine FTBFS with fpc 3.0.4
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)
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
did you receive my investment proposal ?
Bug#887512: e2fsprogs: please add Vcs-*: fields to debian packaging
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
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
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
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
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
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 &nettle_aes128, ^
Bug#887576: mupen64plus-qt FTBFS with libquazip5-headers 0.7.3-3
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
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
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
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
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
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})
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})
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
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})
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
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
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)
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
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
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
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
did you receive my investment proposal ?
Bug#640150: Proposal
did you receive my investment proposal ?
Bug#885570: linux-image-4.9.0-5-amd64
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
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
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
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
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
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
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]
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
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"
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
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
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 de sous-domaine : « .example.com » fonctionnera " "pour « example.com », « www.example.com », ou tout autre sous-domaine de " "« example.com ». La v
Bug#807044: Okular scales down A4 to A5 on printing
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?
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)
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
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
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 === --- debian
Bug#887558: wine-development FTBFS on armel: selected processor does not support `strd r4,[sp]' in ARM mode
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
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
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 network-online.ta
Bug#887557: www.debian.org: tech-ctte membership updates
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)
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
Package: ftp.debian.org Severity: normal Please remove package ibm-3270. Bastian
Bug#887553: xmltooling-schemas: backport to wheezy update for CVE-2018-0486
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 (Bug#886163: fixed in lintian 2.5.68)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Package: ftp.debian.org Severity: normal Please remove package python-dvdvideo. Bastian
Bug#887541: RM: uucp-lmtp -- ROM
Package: ftp.debian.org Severity: normal Please remove package uucp-lmtp. Bastian
Bug#887538: libdata-validate-email-perl depends on libemail-address-perl
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
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
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
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
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
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
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
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.
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
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
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 = os.path.join(httpserver.tmpd
Bug#878633: python-pgpy FTBFS with more than one supported Python3 version
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
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
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 __ self
Bug#887528: libgctp0d: broken dependency in symbols file
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
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
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!
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
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"
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
Source: fish Version: 2.7.1-1 Severity: serious https://buildd.debian.org/status/package.php?p=fish&suite=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