Bug#812713: python3-click: broken python 3 code

[Brian May]

Package: python3-click
Version: 6.2-1
Severity: important

(sid-amd64)root@prune:/tmp/brian/tmp9rNvFP/build/amd64# mkdocs
Traceback (most recent call last):
  File "/usr/bin/mkdocs", line 9, in 
load_entry_point('mkdocs==0.14.0', 'console_scripts', 'mkdocs')()
  File "/usr/lib/python3/dist-packages/click/core.py", line 716, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 675, in main
_verify_python3_env()
  File "/usr/lib/python3/dist-packages/click/_unicodefun.py", line 70, in 
_verify_python3_env
if locale.lower().endswith(('.utf-8', '.utf8')):
TypeError: a bytes-like object is required, not 'str'

This is causing problems with mkdocs and djangorestframework (See #812672).

Bug#812634: janest-core: FTBFS - build-depends on non-existent libcore-kernel-ocaml-dev

[Hilko Bengen]

* Michael Tautschnig:

> The full build log is attached; please do let me know if the problem is
> unreproducible, in which case I shall try to investigate further.

src:janest-core-kernel which provides libcore-kernel-ocaml-dev is still
waiting in NEW.

Cheers
-Hilko

Bug#812714: node-redis: FTBFS - tests fail, redis-server not killed if tests fail

[Michael Tautschnig]

Package: node-redis
Version: 0.12.1-2
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.

[...]
addr=127.0.0.1:34379 fd=126 name= age=3046349 idle=793 flags=N db=0 sub=0 
psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=zrange

Uncaught exception: AssertionError: 266 === 4
at checkResult 
(/srv/jenkins-slave/workspace/sid-goto-cc-node-redis/node-redis-0.12.1/test.js:662:16)
at 
/srv/jenkins-slave/workspace/sid-goto-cc-node-redis/node-redis-0.12.1/test.js:670:9
at try_callback 
(/srv/jenkins-slave/workspace/sid-goto-cc-node-redis/node-redis-0.12.1/index.js:592:9)
at RedisClient.return_reply 
(/srv/jenkins-slave/workspace/sid-goto-cc-node-redis/node-redis-0.12.1/index.js:685:13)
at ReplyParser. 
(/srv/jenkins-slave/workspace/sid-goto-cc-node-redis/node-redis-0.12.1/index.js:321:14)
at emitOne (events.js:77:13)
at ReplyParser.emit (events.js:169:7)
at ReplyParser.send_reply 
(/srv/jenkins-slave/workspace/sid-goto-cc-node-redis/node-redis-0.12.1/lib/parser/javascript.js:300:10)
at ReplyParser.execute 
(/srv/jenkins-slave/workspace/sid-goto-cc-node-redis/node-redis-0.12.1/lib/parser/javascript.js:203:22)
at RedisClient.on_data 
(/srv/jenkins-slave/workspace/sid-goto-cc-node-redis/node-redis-0.12.1/index.js:547:27)

assert.js:89
  throw new assert.AssertionError({
  ^
AssertionError: true == false
at process. 
(/srv/jenkins-slave/workspace/sid-goto-cc-node-redis/node-redis-0.12.1/test.js:2292:12)
at emitOne (events.js:77:13)
at process.emit (events.js:169:7)
at process.exit (node.js:749:17)
at process. 
(/srv/jenkins-slave/workspace/sid-goto-cc-node-redis/node-redis-0.12.1/test.js:2287:13)
at emitOne (events.js:77:13)
at process.emit (events.js:169:7)
at process._fatalException (node.js:223:26)
debian/rules:13: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 7
make[1]: Leaving directory 
'/srv/jenkins-slave/workspace/sid-goto-cc-node-redis/node-redis-0.12.1'
debian/rules:8: recipe for target 'build' failed
make: *** [build] Error 2

The full build log is attached; please do let me know if the problem is
unreproducible, in which case I shall try to investigate further.

Furthermore the redis-server instance is left running in this failing case:
redis_server_child.kill() would only be invoked after the assertions (line 2293
of test.js).

Best,
Michael


node-redis-build-log.txt.gz
Description: application/gunzip


signature.asc
Description: PGP signature

Bug#812567: qtcreator: Crash editor

[Adam Majer]

On Tue, Jan 26, 2016 at 03:19:02AM +0300, ioann sys wrote:
> and i see one bug. After start QtCreator and going to settings for change
> colors in editor - application crashed.

Everything works fine here. I think something is wrong with your
installation. At very least, you may want to run `debsums` on
qtcreator and dependencies.

- Adam


-- 
Adam Majer
ad...@zombino.com

Bug#811266: pulseaudio: log is flooded sometimes when combined with torsocks (torify)

[Felipe Sateler]

Control: reassign -1 torsocks
Control: found -1 2.1.0-2
Control: retitle -1 torsocks: accept{,4} should allow a NULL addr parameter

On 19 January 2016 at 14:58, Andreas B. Mundt  wrote:
> Hi Felipe,
>
> thanks for your fast reply.
>
> On Mon, Jan 18, 2016 at 04:16:19PM -0300, Felipe Sateler wrote:
>> On 18 January 2016 at 15:54, Andreas B. Mundt  wrote:
>
> [...]
>
>> Hmm, so this suggests that there is some problem when autospawning
>> pulseaudio. The contents of ~/.config/pulse/client.conf include only
>> the autospawn setting, right? This would be consistent with the
>> observation that it only breaks the first time since boot.
>
> Yes, normally ~/.config/pulse/client.conf does not exist here.
>
>> Can you reproduce the problem if you try using mpg321 without torify
>> first, and then with torify?
>
> Indeed.  I can reproduce always with:
>
>  killall pulseaudio
>  torify mpg321 http://mp3stream1.apasf.apa.at:8000
>
> whereas:
>
>  killall pulseaudio
>  mpg321 http://mp3stream1.apasf.apa.at:8000
>  torify mpg321 http://mp3stream1.apasf.apa.at:8000
>
> works fine.

The problem is that torsocks does not allow a NULL addr pointer in the
accept{,4} wrappers[1], and sets errno to EFAULT in that case. The
manpage of accept4[2] explicitly allows setting addr to NULL, so the
torsocks wrapper should allow it.

AFAICT, the version in stable has this problem as well.

[1] http://sources.debian.net/src/torsocks/2.1.0-2/src/lib/accept.c/#L114
[2] http://linux.die.net/man/2/accept4


-- 

Saludos,
Felipe Sateler

Bug#812567: qtcreator: Crash editor

[Adam Majer]

On Tue, Jan 26, 2016 at 03:22:47AM +0300, ioann sys wrote:
> Program received signal SIGABRT, Aborted.
> 0x7616b657 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) bt
> #0  0x7616b657 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x7616ca2a in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x761a9bb3 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #3  0x761af00e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #4  0x761af7eb in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #5  0x7fffdf220a0a in ?? () from
> /usr/lib/x86_64-linux-gnu/qt5/plugins/styles/breeze.so
> #6  0x7fffdf21f6cc in ?? () from
> /usr/lib/x86_64-linux-gnu/qt5/plugins/styles/breeze.so
> #7  0x772feff8 in QWidget::event(QEvent*) () from

Thank you! Now, can you switch to a different style than breeze? Maybe
some default one and see if this still happens? It looks like there is
some problem with Qt style.

- Adam



-- 
Adam Majer
ad...@zombino.com

Bug#812672: mkdocs locale error building djangorestframework

[Adam Borowski]

On Tue, Jan 26, 2016 at 11:29:07AM +1100, Brian May wrote:
> python3-click has checks to ensure it is called with a non-ASCII
> locale. Or if it is an ASCII locale, it raises a fatal error. Or at
> least it tries to raise a fatal error.
[...]
> The problem is that when building djangorestframework, I need to have a
> utf8 locale available. C.UTF-8 is fine. However, I don't think there is
> any guarantee (??) that a utf8 locale will be available when building
> packages. This I believe is the root cause of #812672.
> 
> So should I somehow be trying to get the UTF-8 locale (is this possible
> from debian/rules?)

C.UTF-8 is always available on Debian since a long time ago, precisely to
be a guaranteed UTF-8 locale.  It's included in the libc-bin package which
is Essential:yes.

My guess as to the cause of #812672 is that you have LC_CTYPE or LC_ALL set
to an ancient locale.  These variables override LANG, the order is
LC_ALL>LC_CTYPE>LANG.

> should I submit another bug report against
> python3-click saying that it really should work in ASCII environments?

My personal preference would be to drop support for non-UTF8 locales as soon
as possible.  They're a heap of work; that effort could be better spent
fixing remaining problems in UTF-8 locales.

-- 
A tit a day keeps the vet away.

Bug#812207: CVE-2016-0728

[Ben Hutchings]

On Mon, 2016-01-25 at 15:23 -0800, Zachary Loafman wrote:
> Can this issue be treated with high importance?

You would have got a faster response if you had reported the bug
against a real package name in the first place.

> Right now, there is no
> version of jessie-stable or wheezy-backports which is both safe from this
> AUFS hang and safe from CVE-2016-0728, which has a public exploit. The
> current recommendation on https://github.com/docker/docker/issues/18180 is
> to downgrade to a kernel version which is vulnerable to this CVE (I
> believe).

You can possibly mitigate this by using systemtap to disable use of the
keyctl system call, if you don't run anything that needs it (such as an
NFS client).

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.

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

Bug#812672: mkdocs locale error building djangorestframework

[Brian May]

Adam Borowski  writes:

> My guess as to the cause of #812672 is that you have LC_CTYPE or LC_ALL set
> to an ancient locale.  These variables override LANG, the order is
> LC_ALL>LC_CTYPE>LANG.

Interesting thought. Unfortunately, I can't tell from the supplied build
logs what these are set to.

I probably should change the line from:

LANG=C.UTF-8 mkdocs build && mv site docs.debian/html

To something like:

LANG=C.UTF-8 LC_CTYPE= LC_ALL= mkdocs build && mv site docs.debian/html

Just in case.
-- 
Brian May 

Bug#812621: libsdl2-ttf: FTBFS - format not a string literal and no format arguments

[Markus Koschany]

On Mon, 25 Jan 2016 16:34:31 + Michael Tautschnig  wrote:
> Package: libsdl2-ttf
> Version: 2.0.12+dfsg1-2
> Severity: serious
> Usertags: goto-cc
> 
> During a rebuild of all Debian packages in a clean sid chroot (using 
> cowbuilder
> and pbuilder) the build failed with the following error.
> 
> [...]
> make[1]: Entering directory 
> '/srv/jenkins-slave/workspace/sid-goto-cc-libsdl2-ttf/libsdl2-ttf-2.0.12+dfsg1'
> /bin/bash ./libtool  --tag=CC   --mode=compile gcc -DPACKAGE_NAME=\"\" 
> -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" 
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
> -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
> -DPACKAGE=\"SDL2_ttf\" -DVERSION=\"2.0.12\" -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 
> -I.   -Wdate-time  -g -O0 -fstack-protector-strong -Wformat 
> -Werror=format-security -pipe -Wall -I/usr/include/freetype2 -D_REENTRANT 
> -I/usr/include/SDL2  -DHAVE_OPENGL -c -o SDL_ttf.lo SDL_ttf.c
> libtool: compile:  gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" 
> -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" 
> -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 
> -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 
> -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"SDL2_ttf\" -DVERSION=\"2.0.12\" 
> -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -I. -Wdate-time -g -O0 
> -fstack-protector-strong -Wformat -Werror=format-security -pipe -Wall 
> -I/usr/include/freetype2 -D_REENTRANT -I/usr/include/SDL2 -DHAVE_OPENGL -c 
> SDL_ttf.c  -fPIC -DPIC -o .libs/SDL_ttf.o
> SDL_ttf.c: In function 'TTF_SetFTError':
> SDL_ttf.c:331:5: error: format not a string literal and no format arguments 
> [-Werror=format-security]
>  TTF_SetError(msg);

[...]

FYI, pygame-sdl2 is also affected and I believe it is related to the
last upload of SDL2 2.0.4.

https://bugs.debian.org/812695

It definitely worked four days ago when I built pygame-sdl2.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#812672: mkdocs locale error building djangorestframework

[Adam Borowski]

On Tue, Jan 26, 2016 at 11:57:17AM +1100, Brian May wrote:
> Adam Borowski  writes:
> > My guess as to the cause of #812672 is that you have LC_CTYPE or LC_ALL set
> > to an ancient locale.  These variables override LANG, the order is
> > LC_ALL>LC_CTYPE>LANG.
> 
> I probably should change the line from:
> 
> LANG=C.UTF-8 mkdocs build && mv site docs.debian/html
> 
> To something like:
> 
> LANG=C.UTF-8 LC_CTYPE= LC_ALL= mkdocs build && mv site docs.debian/html

LC_ALL=C.UTF-8 is enough, it overrides the other variables.

-- 
A tit a day keeps the vet away.

Bug#812672: [Python-modules-team] Bug#812672: djangorestframework: FTBFS - TypeError: a bytes-like object is required, not 'str'

[Brian May]

Hello,

We have a theory that this is due to LC_CTYPE and LC_ALL environment
being set to legacy values.

Are you able to tell me what the environment variables LC_CTYPE and
LC_ALL are set to during the failed boot?

If this is the case I can fix the problem by unsetting these before
calling mkdocs.

Thanks.
-- 
Brian May 

Bug#812716: openmx: YOUSO10 defined with varying values, causing conflicting array sizes

[Michael Tautschnig]

Package: openmx
Version: 3.7.6-1
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error. Please note that we
use our research compiler tool-chain (using tools from the cbmc package), which
permits extended reporting on type inconsistencies at link time.

file tran_variables.h line 19: error: conflicting array sizes for variable 
`TRAN_hksoutfilename'
old definition in module `openmx' file tran_variables.h line 19
char [500l]
new definition in module `TRAN_Allocate' file tran_variables.h line 19
char [100l]

makefile:212: recipe for target 'openmx' failed
make[1]: *** [openmx] Error 1
make[1]: Leaving directory 
'/srv/jenkins-slave/workspace/sid-goto-cc-openmx/openmx-3.7.6/source'
dh_auto_build: make -j1 returned exit code 2

It seems that the value of YOUSO10 is being set in various places, sometimes to
100 (which is also the fall-back in case it is not defined), but also to 500
(e.g., in source/openmx_common.h). The linker will make some decision (likely it
will pick the largest one), but the compiler will be limited to the information
local to the translation unit. It may choose to perform optimisations on that
basis, which might cause bugs here.

Having said that, Inputtools.c is scary as it is prone to buffer overflows: the
size of the ret-buffer is not passed along, and could thus be smaller than
BUFSIZE.

Best,
Michael



signature.asc
Description: PGP signature

Bug#812715: praat: FTBFS using clang instead of gcc

[Arthur Marble]

Package: praat
Severity: minor
Tags: patch
User: pkg-llvm-t...@lists.alioth.debian.org
Usertags: clang-ftbfs

Hello,

Using the rebuild infrastructure, your package fails to build with clang
(instead of gcc).

Detected this kind of error:
http://clang.debian.net/status.php?version=3.6.0&key=MISSING_PROTOTYPE

Full build log is available here:
http://clang.debian.net/logs/2015-03-25/praat_5.4.0-1_unstable_clang.log

I have attached a patch to fix this error.


Regards,
--Arthur Marble


-- System Information:
Debian Release: sid (unstable)
Architecture: amd64 (x86_64)
Kernel: Linux 4.2.0-1-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE="en_US.UTF-8"
Shell: /bin/sh linked to /bin/dash
Compiler: Debian clang version 3.6.2-3 (based on LLVM 3.6.2)
--- a/external/espeak/compiledict.cpp
+++ b/external/espeak/compiledict.cpp
@@ -138,6 +138,13 @@
 	int group3_ix;
 } RGROUP;
 
+// Function prototypes
+const char *LookupMnemName(MNEM_TAB *table, const int value);
+char *print_dictionary_flags(unsigned int *flags);
+char *DecodeRule(const char *group_chars, int group_length, char *rule, int control);
+int isHexDigit(int c);
+int  string_sorter(char **a, char **b);
+
 
 int isspace2(unsigned int c)
 {//=
--- a/external/espeak/dictionary.cpp
+++ b/external/espeak/dictionary.cpp
@@ -40,6 +40,10 @@
 extern char *print_dictionary_flags(unsigned int *flags);
 extern char *DecodeRule(const char *group_chars, int group_length, char *rule, int control);
 
+// Function prototypes
+int HashDictionary(const char *string);
+int IsVowel(Translator *tr, int letter);
+
 // accented characters which indicate (in some languages) the start of a separate syllable
 //static const unsigned short diereses_list[7] = {L'ä',L'ë',L'ï',L'ö',L'ü',L'ÿ',0};
 static const unsigned short diereses_list[7] = {0xe4,0xeb,0xef,0xf6,0xfc,0xff,0};
--- a/external/espeak/klatt.cpp
+++ b/external/espeak/klatt.cpp
@@ -71,6 +71,11 @@
 static klatt_frame_t  kt_frame;
 static klatt_global_t kt_globals;
 
+// Function prototypes
+int Wavegen_Klatt(int resume);
+void SetSynth_Klatt(int length, int modn, frame_t *fr1, frame_t *fr2, voice_t *v, int control);
+
+
 /*
 function RESONATOR
 
--- a/external/espeak/numbers.cpp
+++ b/external/espeak/numbers.cpp
@@ -389,6 +389,10 @@
 LIGATURE('t','s',M_CURL),
 };
 
+// Function prototypes
+bool CheckThousandsGroup(char *word, int group_len);
+
+
 static int LookupLetter2(Translator *tr, unsigned int letter, char *ph_buf)
 {//
 	int len;
--- a/external/espeak/readclause.cpp
+++ b/external/espeak/readclause.cpp
@@ -1381,6 +1381,9 @@
 }  // end of attr_prosody_value
 
 
+// Function prototypes
+int AddNameData(const char *name, int wide);
+
 int AddNameData(const char *name, int wide)
 {//
 // Add the name to the namedata and return its position
--- a/external/espeak/speak_lib.cpp
+++ b/external/espeak/speak_lib.cpp
@@ -742,7 +742,7 @@
 	uri_callback = UriCallback;
 }
 
-
+ESPEAK_API void espeak_SetPhonemeCallback(int (* PhonemeCallback)(const char*));
 ESPEAK_API void espeak_SetPhonemeCallback(int (* PhonemeCallback)(const char*))
 {//===
 	phoneme_callback = PhonemeCallback;
--- a/external/espeak/synthdata.cpp
+++ b/external/espeak/synthdata.cpp
@@ -177,6 +177,7 @@
 }  //  end of LoadPhData
 
 
+void FreePhData(void);
 void FreePhData(void)
 {//==
 #ifndef DATA_FROM_SOURCECODE_FILES
--- a/external/espeak/synthesize.cpp
+++ b/external/espeak/synthesize.cpp
@@ -613,6 +613,7 @@
 }
 
 
+int FormantTransition2(frameref_t *seq, int &n_frames, unsigned int data1, unsigned int data2, PHONEME_TAB *other_ph, int which);
 int FormantTransition2(frameref_t *seq, int &n_frames, unsigned int data1, unsigned int data2, PHONEME_TAB *other_ph, int which)
 {//==
 	int ix;
--- a/external/espeak/tr_languages.cpp
+++ b/external/espeak/tr_languages.cpp
@@ -319,6 +319,7 @@
 }  // end of SetCyrillicLetters
 
 
+void SetIndicLetters(Translator *tr);
 void SetIndicLetters(Translator *tr)
 {//=
 	// Set letter types for Indic scripts, Devanagari, Tamill, etc
@@ -345,6 +346,7 @@
 }
 
 
+void SetupTranslator(Translator *tr, const short *lengths, const unsigned char *amps);
 void SetupTranslator(Translator *tr, const short *lengths, const unsigned char *amps)
 {//==
 	if(lengths != NULL)
--- a/external/espeak/translate.cpp
+++ b/external/espeak/translate.cpp
@@ -437,6 +437,7 @@
 	return(0);
 }
 
+int IsSpace(unsigned int c);
 int IsSpace(unsigned int c)
 {//
 	if(c == 0)
@@ -607,6 +608,7 @@
 }
 
 
+int IsAllUpper(const char *word);
 int IsAllUpper(const char *word)
 {//==

Bug#812695: pygame-sdl2: FTBFS: format not a string literal and no format arguments

[Markus Koschany]

Control: tags -1 confirmed pending

Am 25.01.2016 um 23:51 schrieb Aaron M. Ucko:
> Source: pygame-sdl2
> Version: 6.99.8-1
> Severity: serious
> Justification: fails to build from source
> 
> Builds of pygame-sdl2 with modern hardening flags have been failing:
> 
> gen/pygame_sdl2.error.c: In function 
> ‘__pyx_pf_11pygame_sdl2_5error_2set_error’:
> gen/pygame_sdl2.error.c:1072:3: error: format not a string literal and no 
> format arguments [-Werror=format-security]
>SDL_SetError(__pyx_t_3);
>^
> cc1: some warnings being treated as errors
> error: command 'aarch64-linux-gnu-gcc' failed with exit status 1
> 
> Could you please take a look?  I presume you'll want to arrange for this
> call to wind up as
> 
>SDL_SetError("%s", __pyx_t_3);
> 
> Thanks!


Thanks for the report. I believe this is some sort of regression in SDL2
2.0.4. Four days ago pygame-sdl2 built fine with SDL2 2.0.2.
pygame_sdl2.error.c is auto-generated at build-time and the error
message,(__pyx_t_3) is controlled by SDL_GetError(), so there is not
much I can do here. I will disable this specific -format hardening check
for now and re-enable it as soon as this issue is resolved in
src:libsdl2 and related packages.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#811551: gdm3: Unresponsive blank screen after logging out

[Francois Gouget]

I ran into this bug again and this time /var/log/urser.log contained 
what seem like more interesting traces. Here is how things played out 
this time:
 * At 8:22:38 the laptop got suspended.
 * At 11:34:13 it got resumed.
 * I swiped the screen to get the user list.
 * Picked an account, typed the password and validated.
 * And then I got a black screen. Fortunately I was able to use Alt+F1 
   to log in to the console and grab /var/log/user.log. Based on that 
   log it looks like there was some problem with D-Bus.


-- 
Francois Gouget   http://fgouget.free.fr/
A particle is an irreducible representation of the Poincaré Group - Eugene 
WignerJan 25 08:22:37 hawai /usr/lib/gdm3/gdm-x-session[29154]: (II) systemd-logind: 
releasing fd for 13:68
Jan 25 08:22:38 hawai /usr/lib/gdm3/gdm-x-session[29154]: (II) Server 
terminated successfully (0). Closing log file.
Jan 25 08:22:38 hawai org.freedesktop.Tracker1[29172]: Received 
signal:15->'Complété'
Jan 25 08:22:38 hawai gnome-session[1513]: (gnome-shell:1521): Clutter-WARNING 
**: Could not open device /dev/input/event12: 
GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Operation not permitted
Jan 25 11:33:13 hawai /usr/lib/gdm3/gdm-x-session[9106]: (II) systemd-logind: 
got resume for 13:68
Jan 25 11:33:13 hawai /usr/lib/gdm3/gdm-x-session[9106]: (II) systemd-logind: 
got resume for 13:74
Jan 25 11:33:13 hawai /usr/lib/gdm3/gdm-x-session[9106]: (II) systemd-logind: 
got resume for 13:77
Jan 25 11:33:13 hawai /usr/lib/gdm3/gdm-x-session[9106]: (II) systemd-logind: 
got resume for 13:65
Jan 25 11:33:13 hawai /usr/lib/gdm3/gdm-x-session[9106]: (II) systemd-logind: 
got resume for 226:0
Jan 25 11:33:13 hawai /usr/lib/gdm3/gdm-x-session[9106]: (II) AIGLX: Resuming 
AIGLX clients after VT switch
Jan 25 11:33:13 hawai /usr/lib/gdm3/gdm-x-session[9106]: (II) intel(0): switch 
to mode 1366x768@60.0 on LVDS1 using pipe 0, position (0, 0), rotation normal, 
reflection none
Jan 25 11:33:14 hawai /usr/lib/gdm3/gdm-x-session[9106]: (--) synaptics: ETPS/2 
Elantech Touchpad: touchpad found
Jan 25 11:33:14 hawai /usr/lib/gdm3/gdm-x-session[9106]: (II) systemd-logind: 
got resume for 13:73
Jan 25 11:33:14 hawai /usr/lib/gdm3/gdm-x-session[9106]: (II) systemd-logind: 
got resume for 13:64
Jan 25 11:33:14 hawai /usr/lib/gdm3/gdm-x-session[9106]: (II) systemd-logind: 
got resume for 13:75
Jan 25 11:33:14 hawai /usr/lib/gdm3/gdm-x-session[9106]: (II) systemd-logind: 
got resume for 13:67
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: The XKEYBOARD keymap 
compiler (xkbcomp) reports:
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: > Warning:  
Type "ONE_LEVEL" has 1 levels, but  has 2 symbols
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: >   
Ignoring extra symbols
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: Errors from xkbcomp 
are not fatal to the X server
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: The XKEYBOARD keymap 
compiler (xkbcomp) reports:
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: > Warning:  
Type "ONE_LEVEL" has 1 levels, but  has 2 symbols
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: >   
Ignoring extra symbols
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: Errors from xkbcomp 
are not fatal to the X server
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: The XKEYBOARD keymap 
compiler (xkbcomp) reports:
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: > Warning:  
Type "ONE_LEVEL" has 1 levels, but  has 2 symbols
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: >   
Ignoring extra symbols
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: Errors from xkbcomp 
are not fatal to the X server
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: The XKEYBOARD keymap 
compiler (xkbcomp) reports:
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: > Warning:  
Type "ONE_LEVEL" has 1 levels, but  has 2 symbols
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: >   
Ignoring extra symbols
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: Errors from xkbcomp 
are not fatal to the X server
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: The XKEYBOARD keymap 
compiler (xkbcomp) reports:
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: > Warning:  
Type "ONE_LEVEL" has 1 levels, but  has 2 symbols
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: >   
Ignoring extra symbols
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: Errors from xkbcomp 
are not fatal to the X server
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: The XKEYBOARD keymap 
compiler (xkbcomp) reports:
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: > Warning:  
Type "ONE_LEVEL" has 1 levels, but  has 2 symbols
Jan 25 11:33:23 hawai /usr/lib/gdm3/gdm-x-session[9106]: >

Bug#642040: flex: input rules are too complicated (>= 32000 NFA states)"

[Manoj Srivastava]

Hi,

> Increase the definitions in flexdef.h for:
> 
> #define JAMSTATE -32766 /* marks a reference to the state that always jams */
> #define MAXIMUM_MNS 31999
> #define BAD_SUBSCRIPT -32767

> recompile everything, and it should all work.

What would good defaults be? I am somewhat worried about our
 extended set of architectures which might not quite be as robust as
 others. 

manoj
-- 
"You can't make a program without broken egos."
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature

Bug#812717: pygame: FTBFS using clang instead of gcc

[Arthur Marble]

Package: pygame
Severity: minor
Tags: patch
User: pkg-llvm-t...@lists.alioth.debian.org
Usertags: clang-ftbfs

Hello,

Using the rebuild infrastructure, your package fails to build with clang
(instead of gcc).

Detected this kind of error:
http://clang.debian.net/status.php?version=3.6.0&key=INVALID_INSTRUCTION_MNEMONIC

Full build log is available here:
http://clang.debian.net/logs/2015-03-25/pygame_1.9.1release+dfsg-10_unstable_clang.log

I have attached a patch to fix this error.


Regards,
--Arthur Marble


-- System Information:
Debian Release: sid (unstable)
Architecture: amd64 (x86_64)
Kernel: Linux 4.2.0-1-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE="en_US.UTF-8"
Shell: /bin/sh linked to /bin/dash
Compiler: Debian clang version 3.6.2-3 (based on LLVM 3.6.2)
--- a/src/scale_mmx64.c
+++ b/src/scale_mmx64.c
@@ -425,7 +425,7 @@
  " movl %5,  %%ecx;   "
  " pxor  %%mm0,  %%mm0;   "
  "1:  "
- " movsxl (%3),  %%rax;   " /* get xidx0[x] */
+ " movslq (%3),  %%rax;   " /* get xidx0[x] */
  " add  $4, %3;   "
  " movq   (%0),  %%mm1;   " /* load mult0 */
  " add  $8, %0;   "
@@ -500,7 +500,7 @@
  " movl %5,  %%ecx;   "
  " pxor  %%mm0,  %%mm0;   "
  "1:  "
- " movsxl (%3),  %%rax;   " /* get xidx0[x] */
+ " movslq (%3),  %%rax;   " /* get xidx0[x] */
  " add  $4, %3;   "
  " movq   (%0),  %%mm1;   " /* load mult0 */
  " add  $8, %0;   "

Bug#812207: CVE-2016-0728

[Ben Hutchings]

On Mon, 2016-01-25 at 17:06 -0800, Zachary Loafman wrote:
> On Jan 25, 2016 4:49 PM, "Ben Hutchings"  wrote:
> > 
> > On Mon, 2016-01-25 at 15:23 -0800, Zachary Loafman wrote:
> > > Can this issue be treated with high importance?
> > 
> > You would have got a faster response if you had reported the bug
> > against a real package name in the first place.
> 
> Apologies, I'm not actually original reporter. I was notified of the bug
> report today and it matches something we found in internal testing after
> using an image that had the CVE fixed. Anyone who updates to fix that CVE
> may run across the same.

Sorry, I should have looked at the messages more closely.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.

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

Bug#812718: chiark-tcl: FTBFS with clang instead of gcc

[Arthur Marble]

Package: chiark-tcl
Severity: minor
Tags: patch
User: pkg-llvm-t...@lists.alioth.debian.org
Usertags: clang-ftbfs

Hello,

Using the rebuild infrastructure, your package fails to build with clang
(instead of gcc).

Detected this kind of error:
http://clang.debian.net/status.php?version=3.6.0&key=VARIABLE_UNINITIALIZED_HERE

Full build log is available here:
http://clang.debian.net/logs/2015-03-25/chiark-tcl_1.1.3_unstable_clang.log

I have attached a patch to fix this error.


Regards,
--Arthur Marble


-- System Information:
Debian Release: sid (unstable)
Architecture: amd64 (x86_64)
Kernel: Linux 4.2.0-1-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE="en_US.UTF-8"
Shell: /bin/sh linked to /bin/dash
Compiler: Debian clang version 3.6.2-3 (based on LLVM 3.6.2)
--- a/cdb/writeable.c
+++ b/cdb/writeable.c
@@ -74,7 +74,7 @@
 } HashValue;
 
 static HashValue *htv_prep(int len) {
-  HashValue *hd;
+  HashValue *hd = malloc(sizeof(*hd));
   hd= TALLOC((hd->data - (Byte*)hd) + len);
   hd->len= len;
   return hd;

Bug#812672: [Python-modules-team] Bug#812672: djangorestframework: FTBFS - TypeError: a bytes-like object is required, not 'str'

[Michael Tautschnig]

Hi,

Thanks a lot for chasing this up so quickly!

On Tue, Jan 26, 2016 at 12:04:59 +1100, Brian May wrote:
> Hello,
> 
> We have a theory that this is due to LC_CTYPE and LC_ALL environment
> being set to legacy values.
> 

Yes, I did notice that discussion on d-devel:

> Are you able to tell me what the environment variables LC_CTYPE and
> LC_ALL are set to during the failed boot?
> 
> If this is the case I can fix the problem by unsetting these before
> calling mkdocs.
> 

I'm investigating, it may just take a bit until my build servers become
available again. I'll get back to you as soon as possible.

Best,
Michael



signature.asc
Description: PGP signature

Bug#812207: CVE-2016-0728

[Akihiro Suda]

> You would have got a faster response if you had reported the bug
> against a real package name in the first place.

I'm sorry for that.

2016-01-26 10:29 GMT+09:00 Ben Hutchings :
> On Mon, 2016-01-25 at 17:06 -0800, Zachary Loafman wrote:
>> On Jan 25, 2016 4:49 PM, "Ben Hutchings"  wrote:
>> >
>> > On Mon, 2016-01-25 at 15:23 -0800, Zachary Loafman wrote:
>> > > Can this issue be treated with high importance?
>> >
>> > You would have got a faster response if you had reported the bug
>> > against a real package name in the first place.
>>
>> Apologies, I'm not actually original reporter. I was notified of the bug
>> report today and it matches something we found in internal testing after
>> using an image that had the CVE fixed. Anyone who updates to fix that CVE
>> may run across the same.
>
> Sorry, I should have looked at the messages more closely.
>
> Ben.
>
> --
> Ben Hutchings
> Q.  Which is the greater problem in the world today, ignorance or apathy?
> A.  I don't know and I couldn't care less.

Bug#812207: linux: AUFS can hang up; Please update to v20160111 or later

[Ben Hutchings]

Control: tag -1 patch moreinfo

On Thu, 21 Jan 2016 15:08:17 + Akihiro Suda  wrote:
> Source: linux-image-3.16.0-4

Please use 'reportbug kernel' to report any future kernel bugs, as that
will select the correct package name automatically.

> Version: 3.16.7-ckt20
> Severity: important
> 
> Dear Maintainer,
> 
> AUFS can hang up (more precisely, produces unkillable processes) with kernel 
> 3.16.7-ckt20 due to commit 296291cdd1629c308114504b850dc343eabc278 appeared 
> in ckt20.
> http://kernel.ubuntu.com/git/ubuntu/linux.git/tag/?h=linux-3.16.y&id=v3.16.7-ckt20
> http://kernel.ubuntu.com/git/ubuntu/linux.git/commit/?h=linux-3.16.y&id=475a23000dd8d2f264bab9d6eb71a2a6b9d4de72
> 
> Many docker users have been experiencing this issue: 
> https://github.com/docker/docker/issues/18180
> 
> The issue has been fixed since AUFS v20160111: 
> http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/5345
> So I suggest updating AUFS to v20160111 or later.

We can't do that because it is no longer supported on Linux 3.x (and
not all the changes would be suitable for a stable update, anyway).

> Although I didn't test for 3.16.7, I think merging this commit is enough: 
> https://github.com/sfjro/aufs4-linux/commit/f60d586b7b8cae42bacc603d192810db85278d3c

That and the previous commit appear to be sufficient, though they
needed some minor changes.  Please can you test whether the attached
patches work, following the procedure at
.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.From: "J. R. Okajima" 
Date: Mon, 4 Jan 2016 23:31:56 +0900
Subject: aufs: tiny, extract a new func xino_fwrite_wkq()
Origin: https://github.com/sfjro/aufs4-standalone/commit/44c72b4050c2563cc6053b91c47885e0409943a5
Bug-Debian: https://bugs.debian.org/812207

Signed-off-by: J. R. Okajima 
[bwh: Backported to aufs3.16:
 - s/vfs_writef_t/au_writef_t/
 - Adjust context]
---
 fs/aufs/xino.c | 47 +++
 1 file changed, 27 insertions(+), 20 deletions(-)

diff --git a/fs/aufs/xino.c b/fs/aufs/xino.c
index 44bbede..cde6ce7 100644
--- a/fs/aufs/xino.c
+++ b/fs/aufs/xino.c
@@ -95,35 +95,42 @@ static void call_do_xino_fwrite(void *args)
 	*a->errp = do_xino_fwrite(a->func, a->file, a->buf, a->size, a->pos);
 }
 
+static ssize_t xino_fwrite_wkq(au_writef_t func, struct file *file, void *buf,
+			   size_t size, loff_t *pos)
+{
+	ssize_t err;
+	int wkq_err;
+	struct do_xino_fwrite_args args = {
+		.errp	= &err,
+		.func	= func,
+		.file	= file,
+		.buf	= buf,
+		.size	= size,
+		.pos	= pos
+	};
+
+	/*
+	 * it breaks RLIMIT_FSIZE and normal user's limit,
+	 * users should care about quota and real 'filesystem full.'
+	 */
+	wkq_err = au_wkq_wait(call_do_xino_fwrite, &args);
+	if (unlikely(wkq_err))
+		err = wkq_err;
+
+	return err;
+}
+
 ssize_t xino_fwrite(au_writef_t func, struct file *file, void *buf, size_t size,
 		loff_t *pos)
 {
 	ssize_t err;
 
-	/* todo: signal block and no wkq? */
 	if (rlimit(RLIMIT_FSIZE) == RLIM_INFINITY) {
 		lockdep_off();
 		err = do_xino_fwrite(func, file, buf, size, pos);
 		lockdep_on();
-	} else {
-		/*
-		 * it breaks RLIMIT_FSIZE and normal user's limit,
-		 * users should care about quota and real 'filesystem full.'
-		 */
-		int wkq_err;
-		struct do_xino_fwrite_args args = {
-			.errp	= &err,
-			.func	= func,
-			.file	= file,
-			.buf	= buf,
-			.size	= size,
-			.pos	= pos
-		};
-
-		wkq_err = au_wkq_wait(call_do_xino_fwrite, &args);
-		if (unlikely(wkq_err))
-			err = wkq_err;
-	}
+	} else
+		err = xino_fwrite_wkq(func, file, buf, size, pos);
 
 	return err;
 }
From: "J. R. Okajima" 
Date: Mon, 4 Jan 2016 23:33:09 +0900
Subject: aufs: for 4.3, XINO handles EINTR from the dying process
Origin: https://github.com/sfjro/aufs4-standalone/commit/5e439ff30c92143d9a9ee3401a84e34c9852533b
Bug-Debian: https://bugs.debian.org/812207

By the commit
	296291c 2015-10-23 mm: make sendfile(2) killable
new_sync_write() (or ->write()) may return EINTR ealier even if it can
succeed the operation. It causes an endless loop in aufs
do_xino_fwrite().
Here is a dirty workaround to retry do_xino_fwrite() in another context
(workqueue).

Reported-by: Akihiro Suda 
Tested-by: Akihiro Suda 
See-also: http://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg05231.html
Signed-off-by: J. R. Okajima 
[bwh: Backported to aufs3.16: s/vfs_writef_t/au_writef_t/]
---
 fs/aufs/xino.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/fs/aufs/xino.c b/fs/aufs/xino.c
index cde6ce7..e3cab07 100644
--- a/fs/aufs/xino.c
+++ b/fs/aufs/xino.c
@@ -53,6 +53,9 @@ ssize_t xino_fread(vfs_readf_t func, struct file *file, void *kbuf, size_t size,
 
 /* -- */
 
+static ssize_t xino_fwrite_wkq(au_writef_t func, struct file *f

Bug#812719: apticron: check for mailx as s-nail not working

[Nick Coleman]

Package: apticron
Version: 1.1.58
Severity: normal
Tags: upstream patch



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

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

Versions of packages apticron depends on:
ii  apt1.2
ii  bzip2  1.0.6-8
pn  cron | cron-daemon 
ii  debconf [debconf-2.0]  1.5.58
ii  dpkg   1.18.4
ii  s-nail [mailx] 14.8.6-1
ii  ucf3.0032

Versions of packages apticron recommends:
ii  apt-listchanges  2.85.14
ii  iproute2 4.3.0-1

apticron suggests no packages.

-- debconf information:
  apticron/notification: root

Problem
---

Currently, for users using s-nail on their systems, apticron mail
reporting is broken. This is also true for apticron's cron reporting
back to the user.

Although apticron does check for the system mailx as being
heirloom-mailx or bsd-mailx, it doesn't check for s-nail correctly. It
relies on 'readlink -e /usr/bin/mailx' to return "heirloom-mailx",
whereas on my sid system it returns "s-nail".

The reporting email is never sent.

Fix
---

The fix is to check specifically for s-nail rather than rely on readlink
to return a reference to s-nail, as currently it returns mailx instead
of s-nail.


How is this a problem?
--

s-nail uses the '-a' parameter differently to previous versions of
mailx.  With previous versions, -a indicated an additional email header
to be included, whereas s-nail uses -a to specify an attachment to be
included with the email.

Since apticron uses -a to set a number of headers, s-nail throws errors
about such as "MIME-Version: 1.0: No such file or directory".
"MIME-Version: 1.0" is meant to be an email header.
--- apticron	2016-01-15 22:16:05.0 +0800
+++ /tmp/apticron	2016-01-26 09:25:49.359961187 +0800
@@ -4,7 +4,8 @@
 # implementations in Debian. Make sure we send proper headers, and a
 # text/plain content type.
 Mailx() {
-	if [ "x`readlink -e /usr/bin/mailx`" = "x/usr/bin/heirloom-mailx" ]
+	local MAILER="`readlink -e /usr/bin/mailx`"
+	if [ x$MAILER = "x/usr/bin/heirloom-mailx" -o x$MAILER = "x/usr/bin/s-nail" ]
 	then
 		# heirloom-mailx creates correct headers, but needs help
 		# if the terminal charset (LC_CTYPE) is no UTF-8 locale

Bug#812720: fotoxx: FTBFS using clang instead of gcc

[Arthur Marble]

Package: fotoxx
Severity: minor
Tags: patch
User: pkg-llvm-t...@lists.alioth.debian.org
Usertags: clang-ftbfs

Hello,

Using the rebuild infrastructure, your package fails to build with clang
(instead of gcc).

Detected this kind of error:
http://clang.debian.net/status.php?version=3.6.0&key=FUNCTION_DIFFER_RETURN_CANNOT_OVERLOADED

Full build log is available here:
http://clang.debian.net/logs/2015-03-25/fotoxx_14.10.2-1_unstable_clang.log

I have attached a patch to fix this error.


Regards,
--Arthur Marble


-- System Information:
Debian Release: sid (unstable)
Architecture: amd64 (x86_64)
Kernel: Linux 4.2.0-1-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE="en_US.UTF-8"
Shell: /bin/sh linked to /bin/dash
Compiler: Debian clang version 3.6.2-3 (based on LLVM 3.6.2)
--- a/f.repair.cc
+++ b/f.repair.cc
@@ -2235,7 +2235,7 @@
 int smart_erase_dialog_event(zdialog *zd, const char *event)   //  overhauled
 {
void smart_erase_func(int mode);
-   void smart_erase_blur(float radius);
+   int smart_erase_blur(float radius);
 
float   radius;
int cc;

Bug#810830: closed by Manoj Srivastava (Flex produces some basic errors in lex.yy.c)

[André Z.D.A.]

I ask you to be more kind with this issue, and I have reasons to consider
it a clear problem in Flex (this is the reason why I reported it as a
bug).

"Using flex normally seems to work." -> Why do you consider the way I used
flex as not normal? I think I did the most normal and common steps that
everyone should do. Let me describe.

First, I have a machine where everything works: gcc, make, and everything
else related to compiling and running programs work flawlessly. So it also
has a valid setup of LD_LIBRARY_PATH variable that will be used by any
programs that need it.

Now I want to use flex. So I download its source code, compile it, and
install according the documentation that comes with it. What is the
result? It doesn't work! And the original bug report shows all the details
I think that are relevant to point the problem, and (I hope) to fix the
problem. Is it related to flex? Of course! It got a working setup machine
and could not work with it! We need a correct setup and flex do not have
it.


-=-=-=-=-= Certo dia, Debian Bug Tracking System escreveu: =-=-=-=-=-
> This is an automatic notification regarding your Bug report
> which was filed against the flex package:
>
> #810830: Flex produces some basic errors in lex.yy.c
>
> It has been closed by Manoj Srivastava .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Manoj Srivastava
>  by
> replying to this email.
>
>
> --
> 810830: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810830
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#812672: [Python-modules-team] Bug#812672: djangorestframework: FTBFS - TypeError: a bytes-like object is required, not 'str'

[Michael Tautschnig]

Hi again,

On Tue, Jan 26, 2016 at  1:25:14 +, Michael Tautschnig wrote:
[...]
> > Are you able to tell me what the environment variables LC_CTYPE and
> > LC_ALL are set to during the failed boot?
> > 
> > If this is the case I can fix the problem by unsetting these before
> > calling mkdocs.
> > 
> 
> I'm investigating, it may just take a bit until my build servers become
> available again. I'll get back to you as soon as possible.
> 

To confirm: yes, this is the correct analysis and also a working fix. I'm not
quite sure whether pbuilder is (still?) doing the right thing here in setting
LC_ALL to C, but that's a matter for #376404 I'd say.

Best,
Michael



signature.asc
Description: PGP signature

Bug#762180: FTCBFS: runs host arch binaries during build via help2man

[Manoj Srivastava]

Hi,

Unfortunately, the patch requires some reworking; It fails with
 the error that it could not get the --man output from flex. I’ll take a
 closer look at this later.

manoj
-- 
Try to relax and enjoy the crisis. Ashleigh Brilliant
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature

Bug#812659: lex FTCBFS: runs tests even when DEB_BUILD_OPTIONS contains nocheck

[Manoj Srivastava]

Hi,

The patch requires some thought: just removing tests from
 subdirs also means that the clean does not recurse, which leaves test
 artifacts lying around, which are an unrepresentable change to the
 source.

manoj
-- 
Only a mediocre person is always at his best. Laurence Peter
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature

Bug#812722: Boot-time scan should be quiet when "quiet" kernel parameter is used

[Ben Hutchings]

Package: btrfs-tools
Version: 4.3-1
Severity: normal
Tags: patch

Currently btrfs's boot script that runs in the initramfs always prints
messages, even if there are no btrfs filesystems present and no
errors.  This should not happen when the "quiet" kernel parameter is
used.  Please apply the attached patch.

Ben.

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

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

Versions of packages btrfs-tools depends on:
ii  e2fslibs1.42.13-1
ii  libblkid1   2.27.1-1
ii  libc6   2.21-6
ii  libcomerr2  1.42.13-1
ii  liblzo2-2   2.08-1.2
ii  libuuid12.27.1-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

btrfs-tools recommends no packages.

btrfs-tools suggests no packages.

-- no debconf information
>From 2bc737c624c8307af7a9084b9e87ae2a3f912358 Mon Sep 17 00:00:00 2001
From: Ben Hutchings 
Date: Tue, 26 Jan 2016 03:51:30 +
Subject: [PATCH] Show only errors from boot-time "btrfs scan" if "quiet" is
 used

When the "quiet" kernel parameter is used, redirect stdout in the
initramfs boot script to /dev/null.  Stop redirecting stderr, as
any errors should still be shown.
---
 debian/local/btrfs.local-premount | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/local/btrfs.local-premount b/debian/local/btrfs.local-premount
index 7f7bf27..aea7128 100644
--- a/debian/local/btrfs.local-premount
+++ b/debian/local/btrfs.local-premount
@@ -19,5 +19,7 @@ esac
 if [ -x /bin/btrfs ]
 then
 	modprobe btrfs
-	/bin/btrfs device scan 2> /dev/null
+	# If asked to be quiet, show only errors
+	[ "${quiet}" = "y" ] && exec >/dev/null
+	/bin/btrfs device scan
 fi

Bug#812721: gbp could filter out Files-Excluded: entries when committing to the pristine-tar branch

[Sean Whitton]

Package: git-buildpackage
Version: 0.7.1
Severity: wishlist

Dear Maintainer,

When uscan is used to generate an upstream tarball, it filters out files
listed in the Files-Excluded: section of the debian/copyright file and
appends +dfsg to the tarball's version.  This can then be imported to
the packaging repository with gbp import-orig.

Nowadays, many upstreams do not ship tarballs.  When preparing the
Debian packaging for such a project, it is convenient to simply clone
upstream's git repository and add a branch to that for Debian
packaging.

Suppose that upstream tags a release 1.2.3 in the git repository.  The
Debian package maintainer must then manually delete the files listed in
Files-Excluded: and then tag a new version 1.2.3+dfsg.  gbp can then
create a tarball of this tag and commit it to the pristine-tar branch.

It would be great if gbp could produce the 1.2.3+dfsg tag itself by
reading debian/copyright and excluding the Files-Excluded: files.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#810299: debdiff

[Neil Roeth]

I have uploaded an NMU of sgml2x to the DELAYED/5 queue.  Please let me
know if I should delay longer or cancel.  Debdiff attached.

-- 
Neil Roeth

diff -u sgml2x-1.0.0/debian/changelog sgml2x-1.0.0/debian/changelog
--- sgml2x-1.0.0/debian/changelog
+++ sgml2x-1.0.0/debian/changelog
@@ -1,3 +1,11 @@
+sgml2x (1.0.0-11.4) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Removed dependencies on jade and openjade1.3 which are
+obsolete. (Closes: #810299).
+
+ -- Neil Roeth   Mon, 25 Jan 2016 20:30:28 -0500
+
 sgml2x (1.0.0-11.3) unstable; urgency=low
 
   * Non-maintainer upload.
diff -u sgml2x-1.0.0/debian/control sgml2x-1.0.0/debian/control
--- sgml2x-1.0.0/debian/control
+++ sgml2x-1.0.0/debian/control
@@ -3,12 +3,12 @@
 Priority: optional
 Maintainer: Yann Dirson 
 Build-Depends: debhelper (>> 5.0.0)
-Build-Depends-Indep: docbook-to-man, elinks, opensp, openjade1.3, openjade, 
docbook-dsssl
+Build-Depends-Indep: docbook-to-man, elinks, opensp, openjade, docbook-dsssl
 Standards-Version: 3.7.3
 
 Package: sgml2x
 Architecture: all
-Depends: opensp, openjade1.3 | openjade | jade, openjade, jadetex, 
${misc:Depends}
+Depends: opensp, openjade, jadetex, ${misc:Depends}
 Recommends: docbook-dsssl | docbook-stylesheets | alcovebook-sgml | 
sgmltools-lite | gtk-doc-tools (>= 1.1-1)
 Suggests: docbook-dsssl, sgmltools-lite, gtk-doc-tools, alcovebook-sgml
 Replaces: alcovebook-sgml (<< 0.0.999)
@@ -30,3 +29,0 @@
- .
- This package requires the DSSSL DTD from package openjade, although
- it can be used with any variant of jade.

Bug#812611: u-boot should have update-u-boot automatic in postinst like update-grub

[Rick Thomas]

On Jan 25, 2016, at 8:07 AM, Kilian Krause  wrote:

> Package: u-boot
> Severity: wishlist
> Tags: d-i
> 
> Hi Vagrant,
> 
> as just discussed the d-i mimic of installing u-boot should also be
> available when updating u-boot packages in an installed system.
> 
> There may be cases, where automatic updates may not be desired or where
> defaults are just simply not matching, so there should probably be a
> /etc/defaults/u-boot with:
> - an option to ENABLE/DISABLE
> - dd parameters like offset
> - the u-boot flavor and image file (if one would want to override it)
> 
> When enabled the u-boot postinst should ensure the latest code is
> auto-activated just like at the end of d-i when installing the system.
> 
> Since duplicating d-i code is not what we want, this probably means also
> creating a udeb with the u-boot-tools (and especially this "installer")
> and moving the relevant installer heuristic over to u-boot and replacing
> it in d-i with a matching structure to call this new tool.
> 
> Best,
> Kilian

With all due respect...

Please don't do this!

Installing u-boot is not at all like installing grub.

If something goes wrong with installing grub, you can boot from a CD or via 
ethernet and recover or re-install.
If something goes wrong with installing u-boot, you have bricked your device.  
The only recourse is J-tag.  Not fun at all!

Installing u-boot is something that should only be undertaken very carefully if 
you know what you're doing and are prepared to recover from a mishap.  Doing it 
automatically every time there's an update is not wise.

Thanks for including me in the discussion!

Rick

Bug#812636: cross-gcc-4.9-ppc64el: FTBFS - build-depends gcc-4.9-source (= 4.9.3-5) when 4.9.3-11 is current

[Dima Kogan]

Michael Tautschnig  writes:

> Package: cross-gcc-4.9-ppc64el
> Version: 54
> Severity: serious
> Usertags: goto-cc
>
> During a rebuild of all Debian packages in a clean sid chroot (using 
> cowbuilder
> and pbuilder) the build failed with the following error.
>
> [...]
>  -> Considering build-dep gcc-4.9-source (= 4.9.3-5)
>   Tried versions: 4.9.3-11
>-> Does not satisfy version, not trying
> E: Could not satisfy build-dependency.

Hi. This is due to cross-gcc-dev being updated, but cross-gcc-4.9-xxx
not having been updated yet. I'll do that shortly.

Bug#812723: lintian: package-contains-broken-symlink should look at dependencies

[Sean Whitton]

Package: lintian
Version: 2.5.40.2
Severity: normal

Dear maintainers,

package-contains-broken-symlink gives a false positive when a package
contains a symlink to a file provided by another package, even when the
package with the warning depends on the package providing the target of
the symlink.

For an example, see the source package ublock-origin version
1.5.6+dfsg-1 in the Debian archive.

Thanks.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.3.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils  2.25.90.20160101-2
ii  bzip2 1.0.6-8
ii  diffstat  1.60-1
ii  file  1:5.25-2
ii  gettext   0.19.7-2
ii  hardening-includes2.8+nmu2
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.29+b5
ii  libarchive-zip-perl   1.56-2
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-1+b1
ii  libdpkg-perl  1.18.4
ii  libemail-valid-perl   1.198-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.413-1+b1
ii  libparse-debianchangelog-perl 1.2.0-8
ii  libperl5.22 [libdigest-sha-perl]  5.22.1-4
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  man-db2.7.5-1
ii  patchutils0.3.4-1
ii  perl  5.22.1-4
ii  t1utils   1.39-2
ii  xz-utils  5.1.1alpha+20120614-2.1

Versions of packages lintian recommends:
ii  dpkg 1.18.4
ii  libperlio-gzip-perl  0.19-1+b1
ii  perl 5.22.1-4
ii  perl-modules-5.22 [libautodie-perl]  5.22.1-4

Versions of packages lintian suggests:
ii  binutils-multiarch 2.25.90.20160101-2
ii  dpkg-dev   1.18.4
ii  libhtml-parser-perl3.71-2+b1
ii  libtext-template-perl  1.46-1
ii  libyaml-perl   1.15-1

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#812695: pygame-sdl2: FTBFS: format not a string literal and no format arguments

[Aaron M. Ucko]

Markus Koschany  writes:

> Thanks for the report. I believe this is some sort of regression in SDL2
> 2.0.4. Four days ago pygame-sdl2 built fine with SDL2 2.0.2.
> pygame_sdl2.error.c is auto-generated at build-time and the error
> message,(__pyx_t_3) is controlled by SDL_GetError(), so there is not
> much I can do here. I will disable this specific -format hardening check
> for now and re-enable it as soon as this issue is resolved in
> src:libsdl2 and related packages.

Ah, yes, I see that SDL_SetError hadn't previously been annotated as
printf-like.  It would be best if whatever generated pygame_sdl2.error.c
(cython?) respected this annotation itself.

At any rate, thanks for the quick response and workaround!

-- 
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

Bug#804281: Acknowledgement (python-setuptools: get_site_dirs in easy_install.py does not return the right path including dist-packages)

[Philipp Edelmann]

Control: found -1 18.8-1

The problem is still present in the current version of setuptools in sid
(18.8-1). I updated my patch to this version.

If I can do anything else to help fixing this in Debian, please let me
know.
diff -Nru python-setuptools-18.8/debian/changelog python-setuptools-18.8/debian/changelog
--- python-setuptools-18.8/debian/changelog	2015-12-13 22:51:45.0 +0900
+++ python-setuptools-18.8/debian/changelog	2016-01-26 13:43:21.0 +0900
@@ -1,3 +1,9 @@
+python-setuptools (18.8-1.1~tux1) unstable; urgency=medium
+
+  * Correct return value for get_site_dirs to use dist-packages.
+
+ -- Philipp Edelmann   Fri, 06 Nov 2015 21:06:34 +0100
+
 python-setuptools (18.8-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru python-setuptools-18.8/debian/patches/install-layout.diff python-setuptools-18.8/debian/patches/install-layout.diff
--- python-setuptools-18.8/debian/patches/install-layout.diff	2015-12-13 22:51:57.0 +0900
+++ python-setuptools-18.8/debian/patches/install-layout.diff	2016-01-26 13:48:16.0 +0900
@@ -1,5 +1,3 @@
-Index: b/setuptools/command/easy_install.py
-===
 --- a/setuptools/command/easy_install.py
 +++ b/setuptools/command/easy_install.py
 @@ -135,13 +135,15 @@ class easy_install(Command):
@@ -108,25 +106,26 @@
  for attr, val in scheme.items():
  if getattr(self, attr, None) is None:
  setattr(self, attr, val)
-@@ -1329,9 +1373,14 @@ def get_site_dirs():
-   "site-packages"),
-  os.path.join(prefix, "lib", "site-python")])
- else:
+@@ -1323,11 +1367,14 @@ def get_site_dirs():
+ if sys.platform in ('os2emx', 'riscos'):
+ sitedirs.append(os.path.join(prefix, "Lib", "site-packages"))
+ elif os.sep == '/':
+-sitedirs.extend([os.path.join(prefix,
+-  "lib",
+-  "python" + sys.version[:3],
+-  "site-packages"),
+- os.path.join(prefix, "lib", "site-python")])
 +if sys.version[:3] in ('2.3', '2.4', '2.5'):
 +sdir = "site-packages"
 +else:
 +sdir = "dist-packages"
- sitedirs.extend(
--[prefix, os.path.join(prefix, "lib", "site-packages")]
--)
++sitedirs.extend(
 +[os.path.join(prefix, "local/lib", "python" + sys.version[:3], sdir),
 + os.path.join(prefix, "lib", "python" + sys.version[:3], sdir)]
 +)
- if sys.platform == 'darwin':
- # for framework builds *only* we add the standard Apple
- # locations. Currently only per-user, but /Library and
-Index: b/setuptools/command/install_egg_info.py
-===
+ else:
+ sitedirs.extend(
+ [prefix, os.path.join(prefix, "lib", "site-packages")]
 --- a/setuptools/command/install_egg_info.py
 +++ b/setuptools/command/install_egg_info.py
 @@ -1,5 +1,5 @@


signature.asc
Description: PGP signature

Bug#811460: [Debian-med-packaging] Bug#811460: ITP: fast5 -- library for reading Oxford Nanopore Fast5 files

[Afif Elghraoui]

Hi, Steffen,

على الإثنين 25 كانون الثاني 2016 ‫07:27، كتب Steffen Möller:
> Hi, I happily help with sponsoring 

That is much appreciated, but this package (together with nanopolish)
was already accepted :)

> and any feedback on how nice the
> nanopore is working for you would be appreciated :)

I myself have mostly just been working with Pacific Biosciences data,
but I thought Debian could get ahead and be prepared with software for
analysis of nanopore data.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#812724: gitlab: Failed to install. Should gitlab depend on nginx?

[Viktor Malyarchuk]

Package: gitlab
Version: 8.4.0+dfsg~rc2-2
Severity: important

Dear Maintainer,

gitlab fail to install with

/var/lib/dpkg/info/gitlab.postinst: 63: /var/lib/dpkg/info/gitlab.postinst: 
cannot create /etc/nginx/sites-available/localhost: Directory nonexistent
dpkg: error processing package gitlab (--configure):
 subprocess installed post-installation script returned error exit status 2

Nginx is not installed on the system. Should gitlab depend on it?

Best regards,
Viktor

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

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

Versions of packages gitlab depends on:
ii  adduser3.113+nmu3
ii  asciidoctor1.5.3-1
ii  bc 1.06.95-9+b1
ii  debconf [debconf-2.0]  1.5.58
ii  gitlab-shell   2.6.10-1
ii  gitlab-workhorse   0.5.0-1
ii  libjs-chartjs  1.0.2-1
ii  libjs-clipboard1.4.2-1
ii  libjs-fuzzaldrin-plus  0.3.1-1
ii  libjs-graphael 0.5+dfsg-1
ii  libjs-jquery-cookie10-2
ii  libjs-jquery-history   10-2
ii  libjs-jquery-nicescroll3.6.6-1
ii  nodejs 5.5.0~dfsg-1
ii  postgresql 9.5+172
ii  postgresql-client-9.5 [postgresql-client]  9.5.0-2
ii  redis-server   2:3.2~rc1-3
ii  ruby   1:2.2.4
ii  ruby-ace-rails-ap  3.0.3-2
ii  ruby-activerecord-deprecated-finders   1.0.4-1
ii  ruby-activerecord-session-store0.1.1-2
ii  ruby-acts-as-taggable-on   3.5.0-2
ii  ruby-addressable   2.3.8-1
ii  ruby-after-commit-queue1.3.0-1
ii  ruby-allocations   1.0.3-1
ii  ruby-asana 0.4.0-1
ii  ruby-babosa1.0.2-1
ii  ruby-bootstrap-sass3.3.5.1-3
ii  ruby-browser   1.0.1-1
ii  ruby-cal-heatmap-rails 3.5.1+dfsg-1
ii  ruby-carrierwave   0.10.0+gh-1
ii  ruby-charlock-holmes   0.7.3+dfsg-2
ii  ruby-coffee-rails  4.1.0-2
ii  ruby-colored   1.2-2
ii  ruby-colorize  0.7.7-1
ii  ruby-creole0.5.0-2
ii  ruby-d3-rails  3.5.6+dfsg-1
ii  ruby-default-value-for 3.0.1-1
ii  ruby-devise3.5.2-3
ii  ruby-devise-async  0.9.0-1
ii  ruby-devise-two-factor 2.0.0-1
ii  ruby-diffy 3.0.6-1
ii  ruby-doorkeeper2.2.1-1
ii  ruby-dropzonejs-rails  0.7.1-1
ii  ruby-email-reply-parser0.5.8-1
ii  ruby-enumerize 1.0.0-1
ii  ruby-fog   1.34.0-2
ii  ruby-fogbugz   0.2.1-2
ii  ruby-font-awesome-rails4.3.0.0-1
ii  ruby-gemnasium-gitlab-service  0.2.6-1
ii  ruby-github-linguist   4.7.2-1
ii  ruby-github-markup 1.3.3+dfsg-1
ii  ruby-gitlab-emoji  0.2.1-1
ii  ruby-gitlab-flowdock-git-hook  1.0.1-1
ii  ruby-gitlab-git7.2.22-1
ii  ruby-gollum-lib4.1.0-3
ii  ruby-gon   6.0.1-1
ii  ruby-grack 2.0.2-1
ii  ruby-grape 0.13.0-1
ii  ruby-grape-entity  0.4.5-1
ii  ruby-haml-rails0.9.0-4
ii  ruby-hipchat   1.5.2-1
ii  ruby-html-pipeline 1.11.0-1
ii  ruby-httparty  0.13.5-1
ii  ruby-jquery-atwho-rails1.3.2-2
ii  ruby-jquery-rails  4.0.5-1
ii  ruby-jquery-scrollto-rails 1.4.3+dfsg-1
ii  ruby-jquery-turbolinks 2.1.0~dfsg-1
ii  ruby-jquery-ui-rails   5.0.5-3
ii  ruby-kaminari  0.16.3-1
ii  ruby-mail-room 0.6.1-1
ii  ruby-method-source 0.8.2-2
ii  ruby-mousetrap-rails

Bug#812325: amavisd-new fails recognizing viruses on non-English systems if the AV scanner writes localized messages to stdout

[Mike Gabriel]

Hi Brian,

thanks for reacting on this so promptly.

On  Mo 25 Jan 2016 23:28:13 CET, Brian May wrote:


Mike Gabriel  writes:


Please consider applying this change (launch amavisd with LANG=C) to
amavisd-new in Debian testing/stretch and also possibly via
security.debian.org in older releases of Debian. (Feedback from the
security team is appreciated on this).


Out of the three init.d scripts, which one need this change?

/etc/init.d/amavis-mc
/etc/init.d/amavisd-snmp-subagent
/etc/init.d/amavis

Once I have a working tested patch, I will contact the release team
about a stable update. However first I need to be sure I understand
which files I should be updating.

...If I had to guess, I would say amavis-mc and amavis but not
amavisd-snmp-subagent.


At the site where the issue was discovered, I only use  
/etc/init.d/amavis. But from reading the docs of amavis-mc, that init  
script may also be affected. As amavisd-snmp-subagent does not launch  
AV scanner child processes, I'd say nothing is needed there.


Thus, I agree with your guess.

Greets,
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/mailxchange/kronolith/fb.php?u=m.gabriel%40das-netzwerkteam.de


pgp1vcBLYtK_4.pgp
Description: Digitale PGP-Signatur

Bug#812723: lintian: package-contains-broken-symlink should look at dependencies

[Adam D. Barratt]

On Mon, 2016-01-25 at 21:19 -0700, Sean Whitton wrote:
> package-contains-broken-symlink gives a false positive when a package
> contains a symlink to a file provided by another package, even when the
> package with the warning depends on the package providing the target of
> the symlink.
> 
> For an example, see the source package ublock-origin version
> 1.5.6+dfsg-1 in the Debian archive.

The tag description explicitly indicates that this is expected in the
situation you describe:

"The package contains a symlink but the destination for the link does
not exist in the package nor in its direct dependencies built from the
same source package."

xul-ext-ublock-origin and fonts-fonts-awesome are /not/ built from the
same source package.

Regards,

Adam

Bug#812725: make-dfsg has unsatisfiable cross build dependendencies in a bootstrap setting: libbsd-resource-perl

[Helmut Grohne]

Source: make-dfsg
Version: 4.1-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi Manoj,

In your 4.1-5 upload, you added libbsd-resource-perl to Build-Depends.
Unfortunately, this package is not available during architecture
bootstrap for the host architecture when we need to build make-dfsg.
Looking closer one can see that libbsd-resource-perl is only used for
running tests. During cross building we generally inhibit running tests
via DEB_BUILD_OPTIONS=nocheck. This works well for make-dfsg as well
(thanks). So we actually do not need the libbsd-resource-perl dependency
there. I therefore suggest annotating it with the  profile and
attach a patch for your convenience.

Helmut
diff -u make-dfsg-4.1/debian/changelog make-dfsg-4.1/debian/changelog
--- make-dfsg-4.1/debian/changelog
+++ make-dfsg-4.1/debian/changelog
@@ -1,3 +1,11 @@
+make-dfsg (4.1-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Satsifiable cross build dependencies: libbsd-resource-perl is only needed
+for running tests (Closes: #-1).
+
+ -- Helmut Grohne   Tue, 26 Jan 2016 06:40:09 +0100
+
 make-dfsg (4.1-5) unstable; urgency=low
 
   * While increasing the timeout is a solution, it still did not work for
diff -u make-dfsg-4.1/debian/control make-dfsg-4.1/debian/control
--- make-dfsg-4.1/debian/control
+++ make-dfsg-4.1/debian/control
@@ -8,7 +8,7 @@
 Homepage: http://www.gnu.org/software/make/
 Build-Depends: gettext, po-debconf, debhelper (>= 9.0.0), dh-autoreconf,
autoconf, automake | automaken, autopoint, file, pkg-config,
-   guile-2.0-dev, procps, libbsd-resource-perl
+   guile-2.0-dev, procps, libbsd-resource-perl 
 
 Package: make
 Suggests: make-doc

Bug#812577: gummi: Gummi fails to locate pictures after ugrade to 0.6.5-3+deb8u1

[Daniel Stender]

Control: tags + confirmed

Yes, that's right. Please excuse that mistake.

I'm in contact with upstream and he's going to release a new upstream tarball
including a fix for CVE 2015-7758 which doesn't has that side effect in the next
days. I'm going to package it immediately and provide an update for Jessie, as
soon as it's possible.

DS

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#812325: amavisd-new fails recognizing viruses on non-English systems if the AV scanner writes localized messages to stdout

[Brian May]

Mike Gabriel  writes:

> thanks for reacting on this so promptly.

I have been told just today that setting LC_ALL overrides LC_CTYPE and
LANG, so just setting LC_ALL should be sufficient.

Can you please test the following change to the init.d script and let me
know if it works for you?


diff --git a/debian/amavisd-new.amavis-mc.init 
b/debian/amavisd-new.amavis-mc.init
index 8de156e..eb7fb17 100644
--- a/debian/amavisd-new.amavis-mc.init
+++ b/debian/amavisd-new.amavis-mc.init
@@ -62,6 +62,7 @@ do_start()
rm -f $PIDFILE
fi
fi
+   export LC_ALL; LC_ALL=C
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
$DAEMON_ARGS \
|| return 2
diff --git a/debian/amavisd-new.amavis.init b/debian/amavisd-new.amavis.init
index f36ed0b..7890ce7 100644
--- a/debian/amavisd-new.amavis.init
+++ b/debian/amavisd-new.amavis.init
@@ -90,6 +90,7 @@ case "$1" in
echo -n "Starting $DESC: "
fixdirs
check_noncompatible_upgrade
+   export LC_ALL; LC_ALL=C
if start-stop-daemon ${START} -- ${PARAMS} start >/dev/null ; then
echo "amavisd-new."
else

-- 
Brian May 

Bug#756316: iked failes to start

[Andreas Messer]

Hello,

the problem is caused by a bug in glibc package: 

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810322

The problem can only reproduced on systems using TSX mutexes like Skylake 
or Broadwell CPUs. Workaround:

diff -r -u ike-orig/source/libith/libith.cpp ike/source/libith/libith.cpp
--- ike-orig/source/libith/libith.cpp   2012-02-10 08:05:36.0 +0100
+++ ike/source/libith/libith.cpp2016-01-08 11:42:32.0 +0100
@@ -94,7 +94,7 @@
 {
memset( obj_name, 0, 20 );
pthread_mutexattr_init( &attr );
-   pthread_mutexattr_settype( &attr, PTHREAD_MUTEX_ERRORCHECK );
+   pthread_mutexattr_settype( &attr, PTHREAD_MUTEX_NORMAL );
pthread_mutex_init( &mutex, &attr );
 }

Works for me without problems so far.

Andreas

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

Bug#812685: mapserver: conflicting types of variable msyystring_icase

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: tags -1 pending

Hi Michael,

On 25-01-16 22:14, Michael Tautschnig wrote:
> During a rebuild of all Debian packages in a clean sid chroot
> (using cowbuilder and pbuilder) the build failed with the following
> error. Please note that we use our research compiler tool-chain
> (using tools from the cbmc package), which permits extended
> reporting on type inconsistencies at link time.
> 
> mapfile.c line 65: error: conflicting types for variable
> `msyystring_icase' old definition in module `maplexer' file
> maplexer.l line 51 signed int new definition in module `mapfile'
> file mapfile.c line 65 char
> 
> Depending on endianness of the platform, the lexer may use the
> wrong byte of msyystring_icase. The attached patch fixes this
> problem.

Thanks for the patch, I've included it in the mapserver package and
forwarded it upstream: https://github.com/mapserver/mapserver/pull/5227

A new upload to unstable is being prepared.

Kind Regards,

Bas

- -- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWpxQnAAoJEGdQ8QrojUrxJtQQAK1wBG0iu6RBpNRO3/0T4WSd
Y5wdOh4Z7tcUNe4wmZA/g0wShxPfXcIRYH8yyr9xF5qvR9OeoBf2ovzgmfSuEA5q
tX1p9MNsCFj3BNv3eDzv/RvYqZ5s0c0w7BfwnMn41wFuw7mxg82/pY+FcvwLoQ7O
M9m6GWtJnLMsG8T+tevt/p8VaB/HjU2in4njm7PuOAtaMtUyx8g77ub8JAIC2xyr
iw0orT/qgXz14YAnXuJo/3i45f6pGiscDOvObFOQzjIeG8cjOy9nNwF2pGOm96pL
mTNx62IBg8AbS+uEy3jUUqdrEHr0hojJDkNbNy6Zo3snqsEr8aH0f8BAxMpKHXQp
u2qqNmyFDB2jvlQOJloc/eQX4k2+tsJCIPxFfXnrahJGdX3YaiQtU10+ew0CffIB
VUxf8any7C+COtJb6DFyVl+7hS5o9agExXnqGw8K45Vo/zrQPrD/sbTlX3vcmUeu
kir0/VdvUYbxR6u9+kqJa5UzVR+nb9vRYprE+2yEZlNsr/WBw16nbF39EjllQWt4
WHj7ZP5DsnfOLG1q07Hw145rAZkDPecXKpWL8jHA++GjNbTNAzSlefqxobsKkR8H
uLWTw9CKsEeqp72WKyYQ0YdpLGtTDIxvbV9mVlK7aQPtj03hPj8yp/gVCzAE9ICs
ObN0fLoyS7O9bcVdz6gf
=OxXS
-END PGP SIGNATURE-

Bug#765639: Bug#802159: New OpenSSL upstream version

[Adam D. Barratt]

On Thu, 2015-12-17 at 23:38 +, Adam D. Barratt wrote:
> However 1.0.1q hasn't been in stable at all, which is presumably what
> you'd be proposing introducing to oldstable at this juncture. (and which
> we'd therefore need to introduce to stable first, if we were to agree to
> follow that path.)

Picking this up again (I hadn't realised the above was so many weeks
ago :-|), updating OpenSSL in Wheezy to anything newer than 1.0.1k
really needs a newer upstream version to be in Jessie first. We also
likely only have two opportunities to get a package in to "Wheezy
proper" before it moves to LTS status - likely a point release in March
and then a "mop up" after the EOL of the base suite.

> Admittedly, the description of the changes between 1.0.1k and 1.0.1q,
> according to NEWS/CHANGES don't immediately look crazy.

Comparing those against the package changelog and Security Tracker and
ignoring changes which are apparently only relevant if SSLv2 is enabled
leaves us with:

  *) dhparam: generate 2048-bit parameters by default.
 [Kurt Roeckx and Emilia Kasper]

  *) Rewrite EVP_DecodeUpdate (base64 decoding) to fix several bugs.
 This changes the decoding behaviour for some invalid messages,
 though the change is mostly in the more lenient direction, and
 legacy behaviour is preserved as much as possible.
 [Emilia Käsper]

  *) In DSA_generate_parameters_ex, if the provided seed is too short,
 return an error
 [Rich Salz and Ismo Puustinen ]

  *) Build fixes for the Windows and OpenVMS platforms
 [Matt Caswell and Richard Levitte]

The last of those is obviously irrelevant. Have there been any reports
of issues related to the other fixes listed?

Regards,

Adam

Bug#812721: gbp could filter out Files-Excluded: entries when committing to the pristine-tar branch

[Guido Günther]

Hi,
On Mon, Jan 25, 2016 at 09:02:50PM -0700, Sean Whitton wrote:
> Package: git-buildpackage
> Version: 0.7.1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> When uscan is used to generate an upstream tarball, it filters out files
> listed in the Files-Excluded: section of the debian/copyright file and
> appends +dfsg to the tarball's version.  This can then be imported to
> the packaging repository with gbp import-orig.
> 
> Nowadays, many upstreams do not ship tarballs.  When preparing the
> Debian packaging for such a project, it is convenient to simply clone
> upstream's git repository and add a branch to that for Debian
> packaging.
> 
> Suppose that upstream tags a release 1.2.3 in the git repository.  The
> Debian package maintainer must then manually delete the files listed in
> Files-Excluded: and then tag a new version 1.2.3+dfsg.  gbp can then
> create a tarball of this tag and commit it to the pristine-tar branch.

I would rather do this with a dfsg-clean branch. You delete once and
then use git tools from there on.

> It would be great if gbp could produce the 1.2.3+dfsg tag itself by
> reading debian/copyright and excluding the Files-Excluded: files.

If somebody comes up with a clean patch I'm happy to merge that.

Cheers,
 -- Guido

Bug#788005: libfreerdp-plugins-standard: urbdrc-client.so missing (USB redirection)

[Alex 'AdUser' Z]

Package: freerdp
Followup-For: Bug #788005

You may also want another patch, that fixes linkage urbdrc-client-libusb.so 
against udev.

If you see message like this right after login:

> undefined symbol 'udev_new'

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- a/channels/urbdrc/client/libusb/CMakeLists.txt	2016-01-26 15:25:32.979436442 +1000
+++ b/channels/urbdrc/client/libusb/CMakeLists.txt	2016-01-26 15:25:45.767436886 +1000
@@ -39,6 +39,7 @@
 set(${MODULE_PREFIX}_LIBS ${${MODULE_PREFIX}_LIBS}
 ${DBUS_GLIB_LIBRARIES}
 ${UUID_LIBRARIES}
+${UDEV_LIBRARIES}
 ${LIBUSB_1_LIBRARIES}
 )
 

Bug#662523: tracker: Please Build-Depends on libpng-dev, change from libpng12-dev

[Tobias Frost]

On Thu, 21 Jan 2016 17:58:47 +0100 Michael Biebl 
wrote:
> Hi Gianfranco
> 
> Am 21.01.2016 um 16:12 schrieb Gianfranco Costamagna:
> > 
> >> If you want to make a team-upload for this change, would be ok
with
> >> me as well.
> > 
> > I did the changes on collab-maint, and uploaded on delayed/7
> 
> Since I already acked the change, feel free to upload directly
without
> delay (you probably have to dcut the existing upload to DELAYED
first)
> 

Thanks for the head-up... 
Rescheduled to 0-day queue.

tobi@edoras:~$ dcut reschedule -d 0 -f tracker_1.6.1-2_amd64.changes
Uploading commands file to ftp.upload.debian.org (incoming: /pub/Upload
Queue/)

--
tobi

Bug#810206: swfmill: Please update dependency on libpng-dev

[Tobias Frost]

Control: retitle -1 Please drop B-D on libpng12-dev
Control: severity normal
Contrpl: usertag -1 =


Yes, that will not block the transition.
However, it should still be removed as libpng12-dev will be retired.
(libpng-dev is also bpo save already)

--
tobi 

On Fri, 22 Jan 2016 11:59:48 +0100 Gianfranco Costamagna  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi, the package already have libpng-dev | libpng12-dev, so I don't
> think there is an issue right now.
> 
> cheers,
> 
> Gianfranco
> 
> On Thu, 07 Jan 2016 10:19:28 +0100 t...@debian.org wrote:
> > Package: swfmill Severity: important User:
> > lib...@packages.debian.org Usertags: libpng16-transition
> > 
> > Dear swfmill maintainers,
> > 
> > Currently we are preparing the transition of libpng1.2 to
> > libpng1.6. The transition bug is #650601.
> > 
> > A rebuild of all packages depending on libpng-dev and 
> > libpng(3,12,12-0)-dev has been done. The result with buildlogs can
> > be found here: https://libpng.sviech.de/
> > 
> > swfmill builds fine with libpng16, you can see the buildlog here: 
> > https://libpng.sviech.de/swfmill.build
> > 
> > Howver, swfmill (build-)depends an versioned development package 
> > libpng12-dev. Please update your (build-)depends to libpng-dev to 
> > help in the transition.
> > 
> > This bug will become RC as soon as the transition starts, as it is 
> > planned to remove libpng12.
> > 
> > Thanks! -- tobi
> > 
> > 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQIcBAEBCAAGBQJWogukAAoJEPNPCXROn13ZUVUP+wcusoIsLUJ0Z97UbTeHoEcJ
> kvRRXc/THdYiv4qsCdyjEdi56V5LD1WsvxYjfjUr9HfFzJi1/zGoG99FBFiyQUIg
> WDuVeu1Az5zetHz1ZXy+bUrw2Y0+RwOJKgEGbpFHSNQlBlXSBBIe9iWQmsb/O3wf
> +o+knJpWxcZz41AnqmcKkzgApABoVwT47h4cN9xNTPuGYsr/hIg8glin2sPKyVE2
> pkHYkzMqoa7J6cIGFEBhGo/YslXMc4PZuo69tVjBjRXOv6QTzWc5c/JUyZAmz4pB
> YfIVW0zTVNcnmFKjvCCi05xV9AbL8/FXULkaSvopfDirpVdmsQjlwEz+NWDA9wtD
> nJiWhc7UMA2AZLPxfQZkWEAlX2sTpOKbxLjaMirQpYTmBS+08aI+RK4EKs2Y+G7o
> RkK95KBtE5ztk60D/bXwJ5zf+m6KH8hJ1C5Dp1tZSdNulEVwFSNUaaqw2FjBuOdW
> YgzJaoWZU813Y2cJUzJ7g9d8mipr6XQqLi7lyeW+aw8xh8+ZSTdSBrMwJCHVq+qb
> YWwTyesfyxC+JVsKhy2JwD7KZfLdzaPUzaODRU6qng9ZJbdQ/WvhAIrgCrTRnqhh
> zraSbpt5LQ4WDdQ+dPwOODyWwsLKJxTgOSk6aSWOooaBrQOjhrT7YeHZg7tu1biM
> LmOmZSUe6V9XNJ8OAbYV
> =CHiG
> -END PGP SIGNATURE-
> 
> 

Bug#812726: [PATCH] Fix autopkgtest

[Martin Pitt]

Package: numexpr
Version: 2.4.3-1
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch xenial

Hello,

numexpr's autopkgtest fails [1] because the test tries to import
pkg_resources which is missing.

Trivial patch attached (which I uploaded to Ubuntu), I tested that
this makes all four tests pass.

Thanks for considering,

Martin

[1] https://ci.debian.net/packages/n/numexpr/unstable/amd64/
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
diff -Nru numexpr-2.4.3/debian/changelog numexpr-2.4.3/debian/changelog
--- numexpr-2.4.3/debian/changelog  2016-01-19 01:41:52.0 +0100
+++ numexpr-2.4.3/debian/changelog  2016-01-26 07:55:34.0 +0100
@@ -1,3 +1,9 @@
+numexpr (2.4.3-1ubuntu1) xenial; urgency=medium
+
+  * Add missing python[3]-pkg-resources test dependency.
+
+ -- Martin Pitt   Tue, 26 Jan 2016 07:55:19 +0100
+
 numexpr (2.4.3-1build1) xenial; urgency=medium
 
   * No-change rebuild to drop python3.4 support.
diff -Nru numexpr-2.4.3/debian/tests/control numexpr-2.4.3/debian/tests/control
--- numexpr-2.4.3/debian/tests/control  2015-08-16 13:32:00.0 +0200
+++ numexpr-2.4.3/debian/tests/control  2016-01-26 07:55:16.0 +0100
@@ -1,12 +1,12 @@
 Tests: python2
-Depends: python-numexpr, python-all
+Depends: python-numexpr, python-all, python-pkg-resources
 
 Tests: python2-dbg
-Depends: python-numexpr-dbg, python-all-dbg
+Depends: python-numexpr-dbg, python-all-dbg, python-pkg-resources
 
 Tests: python3
-Depends: python3-numexpr, python3-all
+Depends: python3-numexpr, python3-all, python3-pkg-resources
 
 Tests: python3-dbg
-Depends: python3-numexpr-dbg, python3-all-dbg
+Depends: python3-numexpr-dbg, python3-all-dbg, python3-pkg-resources
 

Bug#812727: vmdebootstrap: better document SIZE setting

[Matt Taggart]

Package: vmdebootstrap
Version: 1.4-1
Severity: minor

The vmdebootstrap man page does not explain what units size is in or what 
unit suffixes are allowed. It appears it's just passing the setting to 
qemu-img directly, so maybe it should refer to that man page or just 
provide a summary (or both). Here is what qemu-img(1) says:

  size
   is the disk image size in bytes. Optional suffixes "k" or "K"
   (kilobyte, 1024) "M" (megabyte, 1024k) and "G" (gigabyte, 1024M)
   and T (terabyte, 1024G) are supported.  "b" is ignored.

So maybe it could say something like

 --size=SIZE
   create a disk image of size SIZE, in bytes (suffixes k,K,M,G,T
   are supported, see qemu-img(1) for more detail). (Default 1G)

Thanks,

-- 
Matt Taggart
tagg...@debian.org

Bug#812728: RFS: identity4c/1.0-1 [ITP] -- friendly greeter

[Richard Levenberg]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

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

 * Package name: identity4c
   Version : 1.0-1
   Upstream Author : Richard Levenberg 
 * URL : https://github.com/ufpidentity/identity4c
 * License : GPL-2+
   Section : utils

  It builds those binary packages:

libufpidentity-dev - UFP Identity development library for C applications
 libufpidentity1 - UFP Identity library for C applications

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

  http://mentors.debian.net/package/identity4c


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

dget -x
http://mentors.debian.net/debian/pool/main/i/identity4c/identity4c_1.0-1.dsc

  More information about identity4c can be obtained from
https://github.com/ufpidentity/identity4c.

I need some additional help to make sure the binaries are installed
correctly with install-strip rather than install and I would appreciate
comments and criticism regarding the debian packaging.

This is precursor work to a PAM library that requires this library to
work. This library also works standalone for any C applications that
needs to integrate e.g. libnss, slapd plugins, etc.

  Regards,
   Richard Levenberg

Bug#811464: vmdebootstrap: fails to download packages

[Matt Taggart]

I encounter the same error again and figured out what the problem was!

In my original problem report I specified "--size=1". Well that 
value is in _bytes_ so that is only 100M. So the image was filling up due 
to the kernel(large) and zlib(last alphabetically).

I filed a separate bug suggesting better documentation of the size option 
(#812727).

It would have been nice if vmdebootstrap detected this problem and gave a 
more specific error. If it's too complicated to detect the image full 
issue, a sanity check on reasonable values of SIZE would have caught it too.

Will change to wishlist.

Thanks,

-- 
Matt Taggart
tagg...@debian.org

Bug#809923: New package proposal: nordlicht

[Peter Spiess-Knafl]

Hi Sebastian,

I modified the package including the following changes:

* New upstream release 0.4.4 (Fixes over-/underlinking, library
versioning, export symbol visibility)
* Add multiarch-support
* Add autopkgtest
* Fixed the symbols file


I pushed the changes to collab-maint [1].

I will send in an application to join debian-multimedia right now. If I
get accepted, I guess I also have to change the Maintainer-field in
d/control.

Thank you for your effort.

Greetings
Peter


[1]: http://anonscm.debian.org/cgit/collab-maint/nordlicht.git/

Bug#693928: sbuild: Please support building without providing a version number

[Johannes Schauer]

Control: tag -1 + pending

Hi,

On Wed, 21 Nov 2012 20:56:50 + Roger Leigh  wrote:
> Mainly just notes so I don't forget:
> 
> Currently, sbuild uses a package_version syntax to specify the package and
> version to use when downloading the source package.  It would be useful in
> many cases to be able to just specify the package name only, and obtain the
> latest version in the specified distribution.

so today I realized how often I used the following pattern:

$ apt-get source --download-only foo
$ sbuild foo*.dsc

so I sat down and looked at how to implement this feature.

> Currently, Sbuild::Build copes with no version being provided.  It's just a
> matter of disabling the "invalid source" check.  But fetch_source_files
> currently has some requirements for knowing the version up-front, and will
> require some refactoring (or an alternative block for versionless source
> downloading) to handle this.  It will also need some logic adding to find the
> correct .dsc after the download is done; since we download into a temporary
> directory, only one ${package}*.dsc should match that glob; also need to
> check how multiple source versions are handled.
> 
> Not quite as simple as I initially thought, but it's pretty much contained
> within fetch_source_files.  So long as we reset $dsc and 'DSC File', that
> should be sufficient.

Turned out to be even harder than you initially thought because the version is
also required for log filtering (PKGBUILDDIR and BUILDDIR), for all kinds of
log status printing, for external command percentage escapes %d and %p, for
opening the build log at package_ver.build, making the build log symlink and
some more status printing...

Though I think I managed to implement it now. It is now in the sbuild git. Here
the commit message for details of how it was done:

Allow to build by only passing source package name without version (closes: 
#693928)

The packagename_version format was a handy way to fulfill the assumption
sbuild makes that the source package version is available right from the
start. Sbuild then uses the version for things like log filtering,
status output, external command percentage escapes or the build log file
name.

This patch makes it optional that the version is known from the start.
In case it is not known it will:

 - not print version information in the build log
 - not let external command percentage escapes be defined
 - use only the package name for the build log filename
 - set up log filtering much later when the version is definitely known

To not break existing setups, all the old behavior is kept if the
version is known from the start. To distinguish the version being known
from not being known, the user-supplied argument is checked for the
presence of an underscore. If an underscore exists, then either a dsc is
passed or the pkgname_version format was used and in both cases, the old
behavior can be executed. If no underscore can be found, then it is a
bare package name and the different behavior explained above will kick
in.

The man page has been adapted to document the new behavior.

While I was at it, I also rewrote the code downloading the source
package:

 - The old code triggered an "apt-get update" if the source package
   could not be found. This is not necessary because the source package
   is fetched after the chroot is updated. Furthermore it allows to
   "apt-get update" to be run without eventual failures be caught by the
   respective external command hooks. Lastly, this would ignore the
   --no-apt-update command line option.

 - "apt-cache showsrc" was run without --only-source

 - The "apt-cache showsrc" output was parsed using Perl regexes.
   Dpkg::Index is used now.

 - The Files field is now parsed using Dpkg::Checksums instead of using
   perl regexes.

 - the @fetched array was only filled but never used by anybody


Thanks!

cheers, josch


signature.asc
Description: signature

Bug#812672: mkdocs locale error building djangorestframework

[Vincent Bernat]

 ❦ 26 janvier 2016 11:57 +1100, Brian May  :

> I probably should change the line from:
>
> LANG=C.UTF-8 mkdocs build && mv site docs.debian/html
>
> To something like:
>
> LANG=C.UTF-8 LC_CTYPE= LC_ALL= mkdocs build && mv site docs.debian/html


This may not apply to your case, but there is a localehelper package for
this kind of situations.
-- 
Make input easy to prepare and output self-explanatory.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature