Bug#896062: pgrep: >15 characters warning when long regex doesn't match

[Jan Braun]

Jan Braun schrob:
> My solution/hack would probably be to just add a
> 
> >&& (strchr(opt_pattern,'[') != NULL)

Gah. That ought to be a == NULL.
If the opt_pattern does not contain [ print the message.

Bug#896062: pgrep: >15 characters warning when long regex doesn't match

[Jan Braun]

Package: procps
Version: 2:3.3.14-1
Severity: normal
Tags: upstream

Dear Maintainer,

I just upgraded procps from 2:3.3.12-4 to 2:3.3.14-1 and my scripting
started to produce unexpected and (in my case) pointless messages on
stderr, because apparently I like to do the following:

| $ pgrep  "something|otherthing"
| pgrep: pattern that searches for process name longer than 15 characters will 
result in zero matches
| Try `pgrep -f' option to match against the complete command line.
| $ 

This is a regression, and I seem to have no reasonable workaround:

My pattern is indeed a (posix extended) regex, which tends to be longer than
the string matched, and thus can easily be longer than 15 chars. There might
legitimately be no matching process running. I mustn't match on the whole
command line, as that would match, for example, "/usr/local/bin/retry 
something".
I don't want to blindly throw away stderr, in case there ever are actual
errors.

So please make that text go away, or at least give me a way to disable it.




Looking at the code in pgrep.c shows the following condition:

> if ((!matches) && (!opt_full) && opt_pattern && (strlen(opt_pattern) > 15))
>xwarnx(_("pattern that

My solution/hack would probably be to just add a

>&& (strchr(opt_pattern,'[') != NULL)

there, allowing me to silence the warning by doing

$ pgrep "s[o]mething|otherthing"

and if neccessary blame people for not testing regexes. But I'd be fine with

$ pgrep --i-know-about-the-length-restriction-shut-up-already 
"something|otherthing"

too, whatever you/upstream consider reasonable. ;)
If you decide on a fix and want it implemented or a patch you want
tested, please holler, I'd be happy to help.

Thanks for maintaining procps,
regards,
Jan

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

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

Versions of packages procps depends on:
ii  init-system-helpers  1.51
ii  libc62.27-3
ii  libncurses5  6.1-1
ii  libncursesw5 6.1-1
ii  libprocps6   2:3.3.14-1
ii  libtinfo56.1-1
ii  lsb-base 9.20170808

Versions of packages procps recommends:
ii  psmisc  23.1-1

procps suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#896057: gcc-7: doesn't look for "as" in dir specified by -B

[Helmut Grohne]

Hi Jakub,

On Thu, Apr 19, 2018 at 12:31:03AM +0200, Jakub Wilk wrote:
> GCC no longer looks for "as" in the directory specified by the -B option:

Yes, I asked Matthias for passing --with-as to gcc.

> This breaks afl-gcc (part of the afl package), which uses the -B option to
> talk GCC into using a hacked version of the assembler.
> 
> I guess this is fallout from fixing #895251.

I am sorry for having broken afl-gcc along the way and imposing the
work of discovering why on you.

> Previously it worked like this:
> 
>   $ gcc --version | head -n1
>   gcc (Debian 7.3.0-15) 7.3.0
> 
>   $ strace -f -o '| grep -w as' gcc -B/foo/bar/ -c -x c /dev/null
>   3770  stat("/foo/bar/x86_64-linux-gnu/7/as", 0x7ffd82351450) = -1 ENOENT 
> (No such file or directory)
>   3770  stat("/foo/bar/x86_64-linux-gnu/as", 0x7ffd82351450) = -1 ENOENT (No 
> such file or directory)
>   3770  stat("/foo/bar/as", 0x7ffd82351450) = -1 ENOENT (No such file or 
> directory)
>   3770  stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffd82351450) = -1 
> ENOENT (No such file or directory)
>   3770  stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffd82351450) = -1 
> ENOENT (No such file or directory)
>   3770  stat("/usr/lib/gcc/x86_64-linux-gnu/as", 0x7ffd82351450) = -1 ENOENT 
> (No such file or directory)
>   3770  stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffd82351450) = -1 
> ENOENT (No such file or directory)
>   3770  stat("/usr/lib/gcc/x86_64-linux-gnu/as", 0x7ffd82351450) = -1 ENOENT 
> (No such file or directory)
>   3770  
> stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/7/as",
>  0x7ffd82351450) = -1 ENOENT (No such file or directory)
>   3770  
> stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/as",
>  0x7ffd82351450) = -1 ENOENT (No such file or directory)
>   3770  
> stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/as", 
> 0x7ffd82351450) = -1 ENOENT (No such file or directory)
>   3773  execve("/usr/local/bin/as", ["as", "--64", "-o", "null.o", 
> "/tmp/ccFhN057.s"], 0xbe46d0 /* 24 vars */) = -1 ENOENT (No such file or 
> directory)
>   3773  execve("/usr/bin/as", ["as", "--64", "-o", "null.o", 
> "/tmp/ccFhN057.s"], 0xbe46d0 /* 24 vars */ 
> 
> As you can see, GCC was already looking for "as" in a triplet-specific
> directory. So perhaphs gcc-7 should ship an appropriate symlink in
> /usr/lib/gcc//7/, instead of hardcoding path to "as" at configure
> time?

Your suggestion makes a lot of sense. The devil is in the detail though:
 * Does it work the same way for ld?
 * Do cross toolchains also need such a symlink?
 * If yes, where to place it? (They use a different directory layout.)
 * Which make variable contains the correct path?

Plan:
 * I think it is reasonable to simply revert #895251 for the time being.
   That should fix this bug.
 * I'll look into the details and will propose an improved patch.

Helmut

Bug#850156: Please firmly deprecate vendor-specific series files

[Steve Langasek]

On Wed, Apr 18, 2018 at 02:36:14PM +0200, Mike Gabriel wrote:
> > This feature is a very bad idea. I can see why people thought it
> > might be nice: it means you can use the same (or very similar) .dsc
> > (and perhaps vcs history) on different distros.

> Disagreeing here...

> The vendor.series file is a really helpful thing if you share packaging
> workload with people from different Debian derivatives.

> My main context when working for Debian derivates is: get everything into
> Debian, bind the derivatives' devs' (wo)man(or other) power to Debian and
> allow them to achieve their goals for their derivative distro at the same
> time. Maintaining several slightly different src:package versions in Debian
> and derivative X, Y and Z costs a lot of time.

> The vendor.series file is a tiny helper tool, that eases people's day if
> working in a context I described above.

> With Ubuntu, where the vendor.series (i.e. ubuntu.series) file is used here
> and there in my team contexts, you sometimes encounter Ubuntu patches in
> third party package (which you don't have impact on) that break a certain
> behaviour in a vanilla Debian package. Thus, having the mechanism to easily
> patch the Ubuntu build of your package is very handy.

This post makes me think it all the more urgent that it be disallowed, to
the point that I am considering whether Ubuntu should patch dpkg downstream
to disregard vendor.series files.

There are two perfectly well supported workflows here for Ubuntu: you can
make your patches upstreamable (to Debian or to upstream) such that they can
be applied to the source and any per-distro behavior differences can be
accommodated via build-time flags; or you can keep your patches downstream
in Ubuntu only, and handle new Debian package versions via a manual merge.

There is no need for a third workflow to accommodate improperly-upstreamed
patches and breaking the behavior of dpkg-source.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#896012: Regression from gcc-7 7.3.0-16

[Mario.Limonciello]

> -Original Message-
> From: Matthias Klose [mailto:d...@debian.org]
> Sent: Wednesday, April 18, 2018 9:29 PM
> To: Limonciello, Mario; 896...@bugs.debian.org
> Subject: Re: Bug#896012: Regression from gcc-7 7.3.0-16
> 
> On 18.04.2018 19:34, mario.limoncie...@dell.com wrote:
> > Package: gcc-7
> > Version: 7.3.0-16
> >
> > The fwupd project as one of the CI tasks runs packaged builds and lintian 
> > after the
> build.
> > CI recently started failing with this error:
> >
> > E: fwupd: library-not-linked-against-libc 
> > usr/lib/x86_64-linux-gnu/fwupd-plugins-
> 3/libfu_plugin_upower.so
> > E: fwupd-tests: library-not-linked-against-libc 
> > usr/lib/x86_64-linux-gnu/fwupd-
> plugins-3/libfu_plugin_test.so
> >
> > We narrowed it down to be caused after upgrading to GCC 7.3.0-16 from Debian
> testing.
> > Builds with 7.3.0-15 and no source changes to fwupd are not affected.
> >
> > We also found that changing compiler optimization (-O2 to -O0) with the new 
> > GCC
> this error
> > goes away.
> 
> please could you attach the linker command, run with -v, and maybe all linker
> scripts?

Here are both compiler and linker commands when run with -v.

# cc  -Iplugins/test/fu_plugin_test@sha -Iplugins/test -I../plugins/test 
-Iplugins/test/../.. -I../plugins/test/../.. -Iplugins/test/../../src 
-I../plugins/test/../../src -Iplugins/test/../../libfwupd 
-I../plugins/test/../../libfwupd -I/usr/include/libappstream-glib 
-I/usr/include/uuid -I/usr/include/gio-unix-2.0/ -I/usr/include/libgcab-1.0 
-I/usr/include/libsoup-2.4 -I/usr/include/libxml2 -I/usr/include/gdk-pixbuf-2.0 
-I/usr/include/libpng16 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gusb-1 
-I/usr/include/libusb-1.0 -fdiagnostics-color=always -pipe 
-D_FILE_OFFSET_BITS=64 -std=c99 -fstack-protector-strong -Waggregate-return 
-Wunused -Warray-bounds -Wcast-align -Wclobbered -Wdeclaration-after-statement 
-Wduplicated-branches -Wduplicated-cond -Wempty-body -Wformat=2 
-Wformat-nonliteral -Wformat-security -Wformat-signedness -Wignored-qualifiers 
-Wimplicit-function-declaration -Winit-self -Wlogical-op -Wmissing-declarations 
-Wmissing-format-attribute -Wmissing-include-dirs -Wmissing-noreturn 
-Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs -Wno-error=cpp 
-Wno-unknown-pragmas -Wno-discarded-qualifiers -Wno-missing-field-initializers 
-Wno-strict-aliasing -Wno-suggest-attribute=format -Wno-unused-parameter 
-Wnull-dereference -Wold-style-definition -Woverride-init -Wpointer-arith 
-Wredundant-decls -Wreturn-type -Wshadow -Wsign-compare -Wstrict-aliasing 
-Wstrict-prototypes -Wswitch-default -Wtype-limits -Wundef -Wuninitialized 
-Wunused-but-set-variable -Wunused-variable -Wwrite-strings -D_DEFAULT_SOURCE 
-DFWUPD_DISABLE_DEPRECATED -D_GNU_SOURCE -g -O2 
-fdebug-prefix-map=/build/build=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread 
'-DG_LOG_DOMAIN="FuPluginTest"' -MD -MQ 
'plugins/test/fu_plugin_test@sha/fu-plugin-test.c.o' -MF 
'plugins/test/fu_plugin_test@sha/fu-plugin-test.c.o.d' -o 
'plugins/test/fu_plugin_test@sha/fu-plugin-test.c.o' -c 
../plugins/test/fu-plugin-test.c -v
Using built-in specs.
COLLECT_GCC=cc
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.3.0-16' 
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as 
--with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-7 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Debian 7.3.0-16) 
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-I' 
'plugins/test/fu_plugin_test@sha' '-I' 'plugins/test' '-I' '../plugins/test' 
'-I' 'plugins/test/../..' '-I' '../plugins/test/../..' '-I' 
'plugins/test/../../src' '-I' '../plugins/test/../../src' '-I' 
'plugins/test/../../libfwupd' '-I' '../plugins/test/../../libfwupd' '-I' 
'/usr/include/libappstream-glib' '-I' '/usr/include/uuid' '-I' 
'/usr/include/gio-unix-2.0/' '-I' '/usr/include/libgcab-1.0' '-I' 
'/usr/include/libsoup-2.4' 

Bug#566364: ITA: doc-central

[Trout, Diane E.]

retitle 566364 ITA: doc-central -- web-based documentation browser
owner 566364 !
thanks

I'd like to go ahead and adopt doc-central, I do use it occasionally
and it really could stand to be updated to late 2010 coding styles.

Diane

Bug#850156: Please firmly deprecate vendor-specific series files [and 1 more messages]

[Steve Langasek]

On Wed, Apr 18, 2018 at 09:15:25AM -0700, Sean Whitton wrote:
> Hello,
> 
> On Wed, Apr 18 2018, Ian Jackson wrote:
> 
> > FAOD I feel very strongly about this.  The bug is over a year old.
> > Can the Policy Editors please tell me when it would be apprropiate to
> > escalate this to the TC ?

> Sorry, I wrote my other e-mail before reading this.

> ISTM that we can move towards consensus on this bug by developing
> tooling that allows downstreams to make better use of dgit.  That is, we
> offer them something that does the work that vendor-specific series
> files are doing.

I don't think that should be a precondition.

The examples given are for series.ubuntu, which is certainly the case I've
seen in the wild.  Ubuntu, as a project, did not ask for this.  As an Ubuntu
developer, it has never benefitted me.  I have only ever seen it used by
Debian developers who for some reason considered it useful to "merge" an
Ubuntu delta without actually merging it.  This is a development
antipattern; the source package that is then automatically synced to Ubuntu
from Debian is then neither under the guidance of an Ubuntu developer caring
for its quality, nor benefitting from the testing of the package in Debian,
because the source is no longer the same.  There isn't even a guarantee that
what gets synced to Ubuntu has ever been unpacked - or *can* be unpacked -
with dpkg-source.

So yes, please get rid of these vendor series files.  It's not how any
downstream is actually managing their delta from Debian.

> We are actively working on the relevant processes and tools right now.
> Let's see what things look like once we reach the end of that work
> before escalating this bug anywhere.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[KAction]

control: tags -1 help

[2018-04-18 14:11] Jeremy Bicha 
> Source: inotify-tools
> Version: 3.14-5
> 
> Please consider using the dgit-maint-gbp workflow instead of the
> dgit-maint-merge workflow.
> 
> The recent switch from 3.0 (quilt) eliminates useful context and
> metadata from the Debian package itself. That metadata is now only
> available in the git repo.
> [...]

Honestly, I now consider switch to 1.0 a mistake. But I do not know how
to convert back to 3.0 in a way, that `dgit quilt-fixup` will succeed.

Bug#895866: tomcat8: Errors thrown when connecting to default HTTP connector (localhost:8080)

[Michael Welsh Duggan]

Emmanuel Bourg  writes:

> Le 18/04/2018 à 19:26, Michael Welsh Duggan a écrit :
>
>> Thanks.  This would be good, as a Debian system will use
>> /usr/lib/jre/default-java to run tomcat8 by default, and that symlink is
>> not one changed by the alternatives system.  As a result, this will not
>> run without changing JAVA_HOME in /etc/default/tomcat8.
>
> Note that the default JRE has already been switched to OpenJDK 9, so if
> you haven't changed JAVA_HOME in /etc/default/tomcat8 it should run fine.

Indeed.  I didn't notice because I have a package that depends on
default-jre 1.8 for some stupid reason.  Speaking of which, however, if
tomcat8 requires jre 9, it should probably depend on it. 

-- 
Michael Welsh Duggan
(m...@md5i.com)

Bug#867368: udevadm settle timeout 120s with PV nested in LV

[Justin Vallon]

I created a PV in an LV, and initrd delays for about 2 minutes.

Debian 9.3, systemd is 232-25+deb9u3.

I added --debug to "systemd-udevd", and some additional tracing to
INITRD/scripts/init-top/udev.  timestamps show that "udevadm" is
exiting with error after 120 seconds (its default timeout).

+ date
Thu Apr 19 02:38:44 UTC 2018
+ udevadm --debug settle || echo "udevadm settle returned non-zero: $?"
...
seq 1248 queued, 'change' 'block'
...
seq 1248 running
...
seq 1248 '/devices/virtual/block/dm-4' is taking a long time
udevadm settle returned non-zero: 1
+ date
Thu Apr 19 02:40:44 UTC 2018

/dev/dm-4 is the PV of the nested VG:
$ ls -l  /dev/outer-vg/nested-pv
lrwxrwxrwx 1 root root 7 Apr 18 22:42 /dev/outer-vg/nested-pv -> ../dm-4

"seq 1281" is the "change block" event for one of the LVs in the
nested VG, and it completes, so it seems to be getting into the nested
VG and getting at least something done:

$ grep 1281 initramfs.debug
seq 1281 queued, 'change' 'block'
seq 1281 running
seq 1281 processed

I don't know how to read the --debug to figure out what 1248 is
waiting for.

-- 
-Justin
justinval...@gmail.com

Bug#895979: bleachbit: deep scan never finishes

[Hugo Lefeuvre]

Hi,

Looks like issue #209[0]. I'll forward it to upstream.

Thanks for reporting bugs.

Regards,
 Hugo (hle)

[0] https://github.com/bleachbit/bleachbit/issues/209

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA


signature.asc
Description: PGP signature

Bug#896012: Regression from gcc-7 7.3.0-16

[Matthias Klose]

On 18.04.2018 19:34, mario.limoncie...@dell.com wrote:
> Package: gcc-7
> Version: 7.3.0-16
> 
> The fwupd project as one of the CI tasks runs packaged builds and lintian 
> after the build.
> CI recently started failing with this error:
> 
> E: fwupd: library-not-linked-against-libc 
> usr/lib/x86_64-linux-gnu/fwupd-plugins-3/libfu_plugin_upower.so
> E: fwupd-tests: library-not-linked-against-libc 
> usr/lib/x86_64-linux-gnu/fwupd-plugins-3/libfu_plugin_test.so
> 
> We narrowed it down to be caused after upgrading to GCC 7.3.0-16 from Debian 
> testing.
> Builds with 7.3.0-15 and no source changes to fwupd are not affected.
> 
> We also found that changing compiler optimization (-O2 to -O0) with the new 
> GCC this error
> goes away.

please could you attach the linker command, run with -v, and maybe all linker
scripts?

Bug#879642: simple-cdd: build-simple-cdd fails with unsigned local repository

[fin4478 fin4478]

How to avoid these errors with Debian testing/sid when using

-o Acquire::AllowInsecureRepositories=true

:

xfce@amlogic:~/Downloads/cd$ build-simple-cdd --dist sid --local-packages 
/home/xfce/Downloads/cd/debs/ --profiles desktop
2018-04-19 01:44:43 ERROR build/debian-cd exited with code 2
2018-04-19 01:44:43 ERROR Last 5 lines of standard error:
2018-04-19 01:44:43 ERROR build/debian-cd: ERROR: The certificate of 
'd-i.debian.org' is not trusted.
2018-04-19 01:44:43 ERROR build/debian-cd: ERROR: The certificate of 
'd-i.debian.org' hasn't got a known issuer.
2018-04-19 01:44:43 ERROR build/debian-cd: ERROR: The certificate of 
'd-i.debian.org' was signed using an insecure algorithm.
2018-04-19 01:44:43 ERROR build/debian-cd: Failed to start disc 1, error 
1280
2018-04-19 01:44:43 ERROR build/debian-cd: make: *** [image-trees] Error 5
2018-04-19 01:44:43 ERROR build/debian-cd exited with code 2, full log can be 
found in /home/xfce/Downloads/cd/tmp/log/build-debian-cd

Bug#732551: make --foreign / qemu-user-static easier

[Ben Hutchings]

On Wed, 2018-04-18 at 15:41 -0700, Vagrant Cascadian wrote:
> On 2013-12-18, Joey Hess  wrote:
> > If debootstrap installed qemu-user-static into the chroot
> > when --foreign was used, it could then immediately chroot in
> > and run commands (assuming the host system has binfmt-support
> > installed). 
> > 
> > This would allow debootstrap to go ahead and run the second stage
> > itself, under qemu emulation, and leave the user with a foreign chroot
> > that could be transparently chrooted into.
> 
> With version 2.12~rc3 (currently in unstable), qemu-user-static doesn't
> require copying the qemu-ARCH-static binary into the chroot.
> 
> You can simply call:
> 
>   debootstrap --arch=ARCH sid CHROOT
> 
> ... and it just works now, without any debootstrap --foreign or
> qemu-debootstrap wrappers!
> 
> You might still want the binary copied into the chroot to make it easier
> if moving the chroot to another machine, but that seems well outside the
> scope of what debootstrap should worry about.

I think this depends on a new feature in binfmt_misc in Linux 4.8, so
the copy will also be needed on a jessie or wheezy host.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.



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

Bug#896061: instead: Please package the new release 3.2.0

[Boyuan Yang]

Source: instead
Version: 3.1.2-2
Severity: normal

Dear Maintainer,

Instead upstream has released a new version 3.2.0:

http://instead.syscall.ru/2018/02/10/3-2-0/

Please consider pushing it into Debian.

--
Regards,
Boyuan Yang



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

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

Bug#895980: zathura: symbol lookup error: zathura: undefined symbol: synctex_next_result

[Norbert Preining]

Hi

thanks for the report

> Control: retitle -1 libsynctex1: drops public symbols without SONAME bump

Indeed, what a pity. I opened an issue on the github page:
  https://github.com/jlaurens/synctex/issues/23

> including a SONAME bump. FWIW, synctex_result_next was a public symbol in

I guess you mean synctex_next_result. Yes, indeed
synctex_parser_readme.md mentions this :-(
* rename `synctex_next_result` to `synctex_scanner_next_result`

> Additionally, synctex-version.h seems to be missing from the -dev package:

That is strange and unintended, I will fix it. Thanks for the report.

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#896059: Info received (Bug#896059: Acknowledgement (ncmpc: Defaults to non-policy-compliant configuration file))

[Gunnar Wolf]

tags 896059 + patch
thanks

I believe the following very simple patch will take care of this bug:

diff --git a/debian/rules b/debian/rules
index 042e001..48e323a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -27,6 +27,7 @@ config.status: configure
./configure --host=$(DEB_HOST_GNU_TYPE) \
--build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr \
--mandir=\$${prefix}/share/man \
+   --sysconfidir=/etc \
--disable-mini \
--enable-wide \
--enable-multibyte \


Thanks!


signature.asc
Description: PGP signature

Bug#896060: python3-scipy: New upstream version available

[Jan Medlock]

Package: python3-scipy
Version: 0.19.1-2
Severity: minor

Dear Maintainer,
Upstream released version 1.0.0 on 25 October 2017.

In particular, new differential-equation and optimization solvers have
been added.

Please let me know if I can help.

Sincerely,
Jan Medlock

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

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

Versions of packages python3-scipy depends on:
ii  libatlas3-base [liblapack.so.3] 3.10.3-5
ii  libblas3 [libblas.so.3] 3.7.1-4
ii  libc6   2.27-3
ii  libgcc1 1:8-20180414-1
ii  libgfortran47.3.0-16
ii  liblapack3 [liblapack.so.3] 3.7.1-4
ii  libquadmath08-20180414-1
ii  libstdc++6  8-20180414-1
ii  python3 3.6.5-3
ii  python3-decorator   4.1.2-1
ii  python3-numpy [python3-numpy-abi9]  1:1.13.3-2

Versions of packages python3-scipy recommends:
ii  g++ [c++-compiler]4:7.3.0-3
ii  g++-7 [c++-compiler]  7.3.0-16
ii  python3-pil   5.1.0-1

Versions of packages python3-scipy suggests:
ii  python-scipy-doc  0.19.1-2

-- no debconf information

Bug#896059: Acknowledgement (ncmpc: Defaults to non-policy-compliant configuration file)

[Gunnar Wolf]

I see this issue was long ago brought up - Bug #306260, 13 years
ago. Said bug is archived, so I cannot reopen it.

I verified this by:

# mkdir /etc/ncmpc
# echo host=fake.example.com > /etc/ncmpc/config
# exit
$ ncmpc

It still connects to localhost. However,

# mkdir /usr/etc
# mv /etc/ncmpc /usr/etc
# exit
$ ncmpc

tries to connect to fake.example.com

Bug#896059: ncmpc: Defaults to non-policy-compliant configuration file

[Gunnar Wolf]

Package: ncmpc
Version: 0.27-1
Severity: normal

When querying ncmpc for its version information, it displays:

$ ncmpc --version
ncmpc version: 0.27
build options: multibyte wide locale nls colors lirc getmouse artist-screen 
help-screen search-screen song-screen key-screen lyrics-screen outputs-screen 
chat-screen

configuration files:
 /home/gwolf/.ncmpc/config
 /usr/etc/ncmpc/config

That is, were I to want to set systemwide defaults, I would have to do
it in /usr/etc — Which is contrary to regular Debian usage. Please
change it to use /etc/nmcpc/config or something like that!

Thanks,

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

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

Versions of packages ncmpc depends on:
ii  libc62.27-3
ii  libglib2.0-0 2.56.0-6
ii  liblirc-client0  0.10.0-2+b1
ii  libmpdclient22.11-1
ii  libncursesw5 6.1-1
ii  libtinfo56.1-1

ncmpc recommends no packages.

Versions of packages ncmpc suggests:
ii  mpd   0.20.18-1
pn  ncmpc-lyrics  

-- no debconf information

Bug#895851: sh: 1: /usr/local/share/gkrellm/GrabWeather: not found

[Roland Hieber]

On Wed, Apr 18, 2018 at 02:19:02PM -0400, Norbert Veber wrote:
> Thanks.   Unfortunately my Debian key was removed for being too old (weak).
> I haven't been able to find anyone to sign a new one yet.
> 
> Feel free to NMU if you can.

I cannot (not a DD/DM), so someone else has to step in.

 - Roland

Bug#891039: libusbip: error: port number exceeds 128

[Ben Hutchings]

Control: tag -1 moreinfo

On Wed, 21 Feb 2018 19:26:14 +0100 "wzabo...@elektron.elka.pw.edu.pl"
 wrote:
> Package: usbip
> Version: 2.0+4.14.13-1
> Severity: important
> 
> Dear Maintainer,
> 
> When I try to access the USB devices exported with usbip from another
> machine,
> even before I try to access the remote usbip server I gaet the strange
> error:
> 
> # modprobe vhci-hcd
> # usbip port
> libusbip: error: port number exceeds 128
> usbip: error: open vhci_driver
> usbip: error: list imported devices
> 
> Of course I'm not able to attach any device.
> 
> # usbip attach -b 4-1 -r 192.168.0.82
> libusbip: error: port number exceeds 128
> usbip: error: open vhci_driver
> usbip: error: query
[...]

Has this been fixed by the kernel config change in version 4.14.17-1?

  * usbip: Reduce USBIP_VHCI_HC_PORTS to 15, the maximum allowed for SuperSpeed
hubs (Closes: #878866)

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.



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

Bug#690210: Bug 690210 : debootstrap : debian-ports support

[Vagrant Cascadian]

On 2018-04-17, Hideki Yamane  wrote:
> control: tags -1 +pending
>
> On Sat, 27 May 2017 11:27:06 +0200 jhcha54008  wrote:
>> I am testing the updated ([1],[2]) version attached of a 
>> debootstrap script to accomodate the peculiarities of non 
>> released port architectures from www.debian-ports.org : 
> (snip)
>> I would be thankful for feedback if someone has the opportunity 
>> to test it.
>
>  Adjust it to current git code, could you check it, please?

I built debootstrap with current git + this patch, and it seems to work!

Successfully built a riscv64 chroot on amd64:

  debootstrap --arch=riscv64 sid debian-riscv64-chroot 
http://deb.debian.org/debian-ports
  
I've got a package available at:

  deb [signed-by=/usr/share/keyrings/debian-keyring.gpg] 
https://people.debian.org/~vagrant/debian-riscv64 UNRELEASED main


I would suggest not setting a default for PORTS_ARCH, and adding a
commandline flag for it, as this is a hard-coded list that changes over
time, and might make it harder to transition from a debian-ports
architecture to a to a fully supported debian architecture or
vice-versa. This is especially if this hard-coded list lands in a stable
release.

This is really great, though, thanks!


I ran into another bug using https mirrors, but that appears to be a
problem with 1.0.97 too (1.0.96 seems unaffected). I'll look more into
that and file a separate bug or follow-up on any of the existing bugs.


live well,
  vagrant

> From 11239566371afdf3080ee0d383ab17a84860ec68 Mon Sep 17 00:00:00 2001
> From: Hideki Yamane 
> Date: Wed, 18 Apr 2018 14:23:36 +0900
> Subject: [PATCH] Add debian-ports support (Closes: #690210)
>
> Thanks to jhcha54008  for the initial patch
> ---
>  functions | 249 +-
>  scripts/debian-common |   7 +-
>  scripts/sid   |  46 +++-
>  3 files changed, 297 insertions(+), 5 deletions(-)
>
> diff --git a/functions b/functions
> index 0e70f6f..dde66e4 100644
> --- a/functions
> +++ b/functions
> @@ -436,6 +436,13 @@ download () {
>  download_indices () {
>   mk_download_dirs
>   "$DOWNLOAD_INDICES" "$(echo "$@" | tr ' ' '\n' | sort)"
> + # debian-ports also needs "unreleased" architecture
> + if [ -n "$PORT" ]; then
> + local mem_SUITE
> + mem_SUITE="$SUITE"
> + SUITE="unreleased" "$DOWNLOAD_INDICES" $(echo "$@" | tr ' ' 
> '\n' | sort)
> + SUITE="$mem_SUITE"
> + fi
>  }
>  
>  debfor () {
> @@ -487,6 +494,36 @@ apt_dest () {
>   esac
>  }
>  
> +
> +merge_packages_files () {
> + local TEMP_COMPONENTS m c c1 path pkgdest path1 pkgdest1
> +
> + COMPONENTS_WITHOUT_UNRELEASED=$(echo $COMPONENTS|tr ' ' 
> '\n'|sort|uniq|tr '\n' ' ')
> + TEMP_COMPONENTS="$COMPONENTS_WITHOUT_UNRELEASED"
> +
> + for m in $MIRRORS; do
> + for c in $COMPONENTS_WITHOUT_UNRELEASED; do
> + path="dists/unreleased/$c/binary-$ARCH/Packages"
> + pkgdest="$TARGET/$($DLDEST pkg "unreleased" "$c" 
> "$ARCH" "$m" "$path")"
> + path1="dists/$SUITE/$c/binary-$ARCH/Packages"
> + pkgdest1="$TARGET/$($DLDEST pkg "$SUITE" "$c" "$ARCH" 
> "$m" "$path1")"
> +
> + cat "$pkgdest1" "$pkgdest" > "${pkgdest1}.concatenate"
> + "$SORT_PKGS" "${pkgdest1}.concatenate" > 
> "${pkgdest1}.merged"
> + if [ -s "${pkgdest1}.merged" ] ; then
> + if [ -n "$DEBOOTSTRAP_MERGE_KEEP_ORIGINAL" ] ; 
> then
> + mv "$pkgdest1" "${pkgdest1}.original"
> + fi
> + mv "${pkgdest1}.merged" "$pkgdest1"; rm -f 
> "${pkgdest2}.concatenate"
> + fi
> + done
> + done
> +
> + TEMP_COMPONENTS="$(echo $TEMP_COMPONENTS|tr ' ' '\n'|sort|uniq|tr '\n' 
> ' ')"
> + if [ "$TEMP_COMPONENTS" != "$COMPONENTS_WITHOUT_UNRELEASED" ] ; then
> + COMPONENTS="$TEMP_COMPONENTS"
> + fi
> +}
>  ## download
>  
>  get_release_checksum () {
> @@ -1062,13 +1099,18 @@ mv_invalid_to () {
>  setup_apt_sources () {
>   mkdir -p "$TARGET/etc/apt"
>   for m in "$@"; do
> - local cs c path pkgdest
> - for c in ${COMPONENTS:-$USE_COMPONENTS}; do
> + local cs cs1 c path path1 pkgdest pkgdest1
> + for c in ${COMPONENTS_WITHOUT_UNRELEASED:-$USE_COMPONENTS}; do
>   path="dists/$SUITE/$c/binary-$ARCH/Packages"
>   pkgdest="$TARGET/$($DLDEST pkg "$SUITE" "$c" "$ARCH" 
> "$m" "$path")"
>   if [ -e "$pkgdest" ]; then cs="$cs $c"; fi
> + # for "unreleased" archive (debian-ports)
> + 

Bug#896058: --filter missing from man page

[積丹尼 Dan Jacobson]

Package: git-man
Version: 1:2.17.0+next.20180411-1
File: /usr/share/man/man1/git-clone.1.gz

"--filter" missing from man page.

Bug#895981: please cleanup /var/cache/nscd on restart

[Aurelien Jarno]

Hi,

On 2018-04-18 10:18, Harald Dunkel wrote:
> Package: nscd
> Version: 2.24-11+deb9u3
> 
> If I change nscd.conf (to adjust some ttl or to disable some cache)
> and restart the service, then the cache files in /var/cache/nscd
> are not adjusted accordingly, AFIACS. In worst case the passwd cache
> is kept forever and never adjusted, even though it has been disabled
> in nscd.conf.

Could you please tell me if you use systemd or sysvinit, to know if the
systemd service file is used, or the old init script.

> nscd's caches should be deleted or recreated at service start or
> restart, as applicable.

With both the systemd service and the old init script, the caches should
be invalidated through nscd -i, which is the proper way to start with a
clean cache. Now there might be a case which is not handled correctly.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#732551: make --foreign / qemu-user-static easier

[Vagrant Cascadian]

On 2013-12-18, Joey Hess  wrote:
> If debootstrap installed qemu-user-static into the chroot
> when --foreign was used, it could then immediately chroot in
> and run commands (assuming the host system has binfmt-support
> installed). 
>
> This would allow debootstrap to go ahead and run the second stage
> itself, under qemu emulation, and leave the user with a foreign chroot
> that could be transparently chrooted into.

With version 2.12~rc3 (currently in unstable), qemu-user-static doesn't
require copying the qemu-ARCH-static binary into the chroot.

You can simply call:

  debootstrap --arch=ARCH sid CHROOT

... and it just works now, without any debootstrap --foreign or
qemu-debootstrap wrappers!

You might still want the binary copied into the chroot to make it easier
if moving the chroot to another machine, but that seems well outside the
scope of what debootstrap should worry about.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#895959: [Pkg-openssl-devel] Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1 in exp

[Kurt Roeckx]

On Wed, Apr 18, 2018 at 09:46:06PM +0200, Sebastian Andrzej Siewior wrote:
> On 2018-04-18 16:14:37 [+0200], Kurt Roeckx wrote:
> > I can't see a reason why TLS 1.3 would be different in this regard,
> > I expect the same behaviour for all SSL/TLS version. Anyway, it
> > could just have been some code refactor that "fixed" it so that it
> > generates the error now. Or maybe the old code generated an error
> > on SSL_write() instead of the SIGPIPE?
> > 
> > It would at least be good to know how the old version behaved.
> 
> As per bisect, openssl commit 30f05b19d3ba ("Create the NewSessionTicket
> message in TLSv1.3") is responsible for the SIGPIPE.
> But I *think* this is unrelated. The perl testcase triggers reliable. My
> C test case I used yestrday triggers only under strace (but I think this
> was not the case yesterday). So I *think* this commit changed the
> timming and now the SIGPIPE is more likely.

So if I understand things, the write now happes after the other
side does the shutdown(), while it happened before previously?

Anyway, it seems to me that they should use SSL_shutdown() before
closing the connection.


Kurt

Bug#896057: gcc-7: doesn't look for "as" in dir specified by -B

[Jakub Wilk]

Package: gcc-7
Version: 7.3.0-16
Control: block 895618 with -1

GCC no longer looks for "as" in the directory specified by the -B 
option:


  $ gcc --version | head -n1
  gcc (Debian 7.3.0-16) 7.3.0

  $ strace -f -o '| grep -w as' gcc -B/foo/bar/ -c -x c /dev/null
  3641  access("/usr/bin/x86_64-linux-gnu-as", X_OK) = 0
  3644  execve("/usr/bin/x86_64-linux-gnu-as", ["/usr/bin/x86_64-linux-gnu-as", "--64", "-o", 
"null.o", "/tmp/cc40S4xu.s"], 0x1ca26d0 /* 24 vars */ 

This breaks afl-gcc (part of the afl package), which uses the -B option 
to talk GCC into using a hacked version of the assembler.


I guess this is fallout from fixing #895251.

Previously it worked like this:

  $ gcc --version | head -n1
  gcc (Debian 7.3.0-15) 7.3.0

  $ strace -f -o '| grep -w as' gcc -B/foo/bar/ -c -x c /dev/null
  3770  stat("/foo/bar/x86_64-linux-gnu/7/as", 0x7ffd82351450) = -1 ENOENT (No 
such file or directory)
  3770  stat("/foo/bar/x86_64-linux-gnu/as", 0x7ffd82351450) = -1 ENOENT (No 
such file or directory)
  3770  stat("/foo/bar/as", 0x7ffd82351450) = -1 ENOENT (No such file or 
directory)
  3770  stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffd82351450) = -1 ENOENT 
(No such file or directory)
  3770  stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffd82351450) = -1 ENOENT 
(No such file or directory)
  3770  stat("/usr/lib/gcc/x86_64-linux-gnu/as", 0x7ffd82351450) = -1 ENOENT 
(No such file or directory)
  3770  stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffd82351450) = -1 ENOENT 
(No such file or directory)
  3770  stat("/usr/lib/gcc/x86_64-linux-gnu/as", 0x7ffd82351450) = -1 ENOENT 
(No such file or directory)
  3770  
stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/7/as",
 0x7ffd82351450) = -1 ENOENT (No such file or directory)
  3770  
stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/as",
 0x7ffd82351450) = -1 ENOENT (No such file or directory)
  3770  
stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/as", 
0x7ffd82351450) = -1 ENOENT (No such file or directory)
  3773  execve("/usr/local/bin/as", ["as", "--64", "-o", "null.o", 
"/tmp/ccFhN057.s"], 0xbe46d0 /* 24 vars */) = -1 ENOENT (No such file or directory)
  3773  execve("/usr/bin/as", ["as", "--64", "-o", "null.o", "/tmp/ccFhN057.s"], 
0xbe46d0 /* 24 vars */ 

As you can see, GCC was already looking for "as" in a triplet-specific 
directory. So perhaphs gcc-7 should ship an appropriate symlink in 
/usr/lib/gcc//7/, instead of hardcoding path to "as" at 
configure time?



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

Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=pl_PL.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 gcc-7 depends on:
ii  binutils  2.30-15
ii  cpp-7 7.3.0-16
ii  gcc-7-base7.3.0-16
ii  libc6 2.27-3
ii  libcc1-0  8-20180414-1
ii  libgcc-7-dev  7.3.0-16
ii  libgcc1   1:8-20180414-1
ii  libgmp10  2:6.1.2+dfsg-3
ii  libisl19  0.19-1
ii  libmpc3   1.1.0-1
ii  libmpfr6  4.0.1-1
ii  libstdc++68-20180414-1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages gcc-7 recommends:
ii  libc6-dev  2.27-3

--
Jakub Wilk

Bug#803667: Business proposal

[Lucia Duran]

De: Lucia Duran
Enviado el: miércoles, 18 de abril de 2018 07:21 p.m.
Para: Lucia Duran
Asunto: Business proposal

I have a Business proposal for you. If interested For more details Respond 
directly to this Email :  ( hans.witteb...@gmail.com )

Bug#895362: Acknowledgement (Testing CD/DVD Missing algif_skcipher on Power64LE (so cannot use encrypted volumes))

[Ben Hutchings]

Control: reassign -1 src:linux 4.15.11-1

On Thu, 2018-04-12 at 10:34 -0400, Matt Corallo wrote:
> Also missing at least the ecb module, which is needed to initialize the
> xts mode to do a default encrypted-partition install.

It turns out that ecb was already included in nic-wireless-modules, so
it was available in most installations where disk encryption is wanted
- but not on ppc64el, where we don't build a nic-wireless-modules
package.  I'll move it to crypto-modules.

On Tue, 2018-04-10 at 10:50 -0400, Matt Corallo wrote:
> Package: linux-image-powerpc64le
> Version: 4.15+91
> 
> (I know its not the right package as this is an issue only in the
> testing CD, not a running system, but I can't seem to find the right
> package to file against, and figure this will at least CC the right
> people, sorry about that).
> 
> Pretty self-explanatory, algif_skcipher mod is missing on the weekly
> buster install CD/DVD, so any time you try to use encrypted volumes you
> get a cryptic error in the install prompt and a "Error allocating crypto
> tfm" error in dmesg.

We don't include algif_skcipher on amd64, and I've just tested that the
ppc64el snapshot starts working if I only add ecb.  So I won't add
algif_skcipher.

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


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

Bug#896056: Further information

[Sean M. Pappalardo]

Hello again.

For further testing, I did the following:

sudo dpkg -r python-paramiko
pip install paramiko==1.18.5

And the problem still appears just the same as with a newer Paramiko.
(Does that mean this problem is not related to Paramiko then?)



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#896056: python-paramiko: SSH key login fails since 2.0.0

[Sean M. Pappalardo]

Package: python-paramiko
Version: 2.4.0-1
Severity: important

Dear Maintainer,

I use SSH keys on a PKCS#11 smart card (via OpenSC) to authenticate to various 
machines via SSH.
I also use Fabric to automate certain tasks on some remote machines and have 
been doing so since Jessie. It worked fine then.
Ever since upgrading to Stretch, Fabric can no longer authenticate to remote 
machines, either with my SSH key or my correct password, while normal direct 
ssh continues to work correctly with keys (and passwords if I remove keys from 
the agent.)
(Fabric uses the Paramiko library to make its SSH connections.)

Running ssh-agent in debug mode shows the error "process_sign_request2: 
sshkey_sign: error in libcrypto" when paramiko attempts to authenticate to the 
remote host, itself saying "SSHException: key cannot be used for signing".

It does this on the second key on my card while the fourth one is the correct 
one for a particular remote machine. It lists that it is trying the other keys 
but gives no further debug information about them.

Running ssh -vvv  does not show any such error about signing 
when it tries that same key. (The server just rejects it so the client moves on 
to the next key.)

My ssh-agent is linked against libssl 1.0.2.

#paramiko on Freenode mentioned that Paramiko v2.0.0 changed their dependency 
from PyCrypto to cryptography.io which may be related.


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

Kernel: Linux 4.9.0-6-amd64 (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 python-paramiko depends on:
ii  python   2.7.13-2
ii  python-bcrypt3.1.2-1
ii  python-cryptography  1.7.1-3
ii  python-nacl  1.0.1-2
ii  python-pyasn10.1.9-2

python-paramiko recommends no packages.

Versions of packages python-paramiko suggests:
pn  python-gssapi  

-- no debconf information

Bug#895976: src:linux: Add i2c_exynos5 to kernel-image udeb for network support on Odroid

[Jochen Sprickerhof]

* Ben Hutchings  [2018-04-18 22:27]:

So I think i2c_exynos5 belongs in i2c-modules, and that's where I'll
put it.


That sounds much better, thx :).


signature.asc
Description: PGP signature

Bug#894217: [reprotest] kk_KZ.RK1048 again

[Ximin Luo]

Agustin Henze:
> Hi Ximin,
> 
> On Tue, 17 Apr 2018 21:01:00 + Ximin Luo  wrote:
>> Inaki Malerba:
>>> Hi Ximin
 More generally, I'd argue that build programs shouldn't fail simply when 
 LC_ALL is unrecognised, for example gcc works perfectly fine.

 $ LC_ALL=ououi gcc -c /dev/null 2>/dev/null; echo $?
 0
>>>
>>> Totally agree.
>>> Normally, it should fallback to a known config, but, as you can see in
>>> the following example, the problem it's not exactly that the LC_ALL is
>>> unrecognized but the LC itself.
>>> A similar problem happens with Sphinx.
>>>
>>> Sorry if that's not what you meant.
>>>
>>> ```
>>> # LC_ALL=kk_KZ.RK1048 help2man
>>> Unknown encoding 'RK1048' at /usr/bin/help2man line 56.
>>>
>>> # LC_ALL=bleble help2man
>>> perl: warning: Setting locale failed.
>>> perl: warning: Please check that your locale settings:
>>> [..]
>> Well, this detail does not change my main point. Why should any program 
>> silently accept LC_ALL=oeuieoui (and print warnings, that's fine) but blow 
>> up when running LC_ALL=kk_KZ.X? It should at most print a warning, not 
>> crash. Try it yourself:
>>
>> $ LC_ALL=kk_KZ.XX gcc -c /dev/null 2>/dev/null; echo $?
>> 0
>>
> 
> Thank you for taking time testing it :). This example does work for me as 
> well.
> 
>> BTW help2man seems to work fine on my Debian testing+unstable system with 
>> both LC_ALL=kk_KZ.RK1048 and LC_ALL=kk_KZ.XX and perl 5.26.1-5; I can't 
>> reproduce the behaviour you're describing.
>>
> 
> Doesn't work for me, please find attached a Dockerfile and its output (I've
> stripped out the non-important parts).

Your perl/python tests miss the point. I think it's fine for .encode() to crash 
or raise an exception when given an unrecognised encoding, because it's an 
explicit command. I don't think it's fine for LC_ALL to crash or raise an 
exception, because it's meant to be an opportunistic override.

Have you tried:

$ LC_ALL=kk_KZ.XX perl -e 'print "yes\n";'
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_GB:en",
LC_ALL = "kk_KZ.XX",
LANG = "en_GB.utf8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_GB.utf8").
yes

$ LC_ALL=kk_KZ.XX python2 -c 'print "yes\n";'
yes

They work fine on my computer but since I was unable to reproduce the bug here 
anyways, I am not sure if it means much. But these tests are more "to the 
point" than your tests in your output.txt.

IMO the time spent discussing this on this bug report would have been better 
spent writing patches for the affected programs.

I really don't think reprotest should be coded to ignore known problems. If you 
want to avoid these bugs (in other programs), give `reprotest --vary=-locales` 
then the problem is evident visually on the command-line and not "brushed under 
the carpet" and you can still continue with your other tests.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#895976: src:linux: Add i2c_exynos5 to kernel-image udeb for network support on Odroid

[Ben Hutchings]

On Wed, 2018-04-18 at 09:21 +0200, Jochen Sprickerhof wrote:
> Package: src:linux
> Severity: normal
> Tags: patch
> 
> Hi,
> 
> Please include the i2c_exynos5 module into the kernel-image udeb, so the
> Debian installer detects the network card of the Odroid XU4 and supports
> installation over network. I believe this partly solves #880494 as well.
> 
> The attached patch should fix this.

I don't think it should be added to the kernel-image udeb.  i2c_exynos5
depends on i2c-core which is notionally in i2c-modules, but the package
dependency is the other way around.  At the moment i2c-core is actually
built-in, but if that ever changes the this dependency inversion would
break the build.

So I think i2c_exynos5 belongs in i2c-modules, and that's where I'll
put it.

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky



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

Bug#667611: n-m-openvpn shuts down VPN when openvpn soft-restarts

[Vladimir K]

Adding just this to NetworkManager environment seems to be a sufficient 
workaround:

$ cat /etc/systemd/system/NetworkManager.service.d/openvpn-workaround.conf
[Service]
Environment="NM_OPENVPN_CHROOT="

At least the connection survives SIGUSR1 to openvpn process.

I presume the correct solution would be to have 
/usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper inside chroot?

Bug#895994: ocaml-nox: Stop recommending deprecated camlp4

[Ralf Treinen]

Hi,

On Wed, Apr 18, 2018 at 02:45:54PM +0200, Ralf Jung wrote:

> I just realized that ocaml-nox is the reason I still have camlp4 installed on 
> my
> system even though I have no intentions of using it.  In fact, the upstream
> website at https://github.com/ocaml/camlp4 says:
> 
> > Since 2017, Camlp4 is not actively maintained anymore, and only receives
> > occasional fixes for compatibility with new OCaml versions. Maintainers of
> > Camlp4-using projects are actively encouraged to switch to other systems.
> 
> Sounds like it is time to drop the Recommends: camlp4 from ocaml-nox?

Indeed. Speaking for myself, I never used any of camlp4 or camlp5 for
my own projects. Fixed in git.

Thanks for your bug report -Ralf.

Bug#896055: ITP: mbrola-tl1 -- Telugu female voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-tl1
  Version : 0.0.20010627
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Telugu female voice for Mbrola
 This package contains a Telugu diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Telugu female voice to be used with the MBROLA
 program.

Bug#896053: ITP: mbrola-nl3 -- Dutch female voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-nl3
  Version : 0.1
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Dutch female voice for Mbrola
 This package contains a Dutch diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Dutch female voice to be used with the MBROLA
 program.

Bug#896045: ITP: mbrola-in2 -- Hindi female voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-in2
  Version : 0.0.20010202
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Hindi female voice for Mbrola
 This package contains a Hindi diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Hindi female voice to be used with the MBROLA
 program.

Bug#896054: ITP: mbrola-nz1 -- Maori male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-nz1
  Version : 0.2
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Maori male voice for Mbrola
 This package contains a Maori diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Maori male voice to be used with the MBROLA
 program.

Bug#887107: [Debian-l10n-devel] https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23 - too much packages to add to the ignore_list

[Laura Arjona Reina]

Hi Nicolas

Thanks for your help.

El 18/04/18 a las 03:35, Nicolas François escribió:
> Can you try adding
> $text = undef;
> after the line 178 in
> https://salsa.debian.org/l10n-team/dl10n/blob/master/lib/Debian/Pkg/Tar.pm
>
> You will still have the error messages (Unable to open..., read() on closed
> filehandle..., Failed to read...) but I hope this will avoid the crash ('x'
> outside of string in unpack...)
> (sorry, I could not test).
I have tested this, and it helps the script to go further (see attached
log). So I have committed your suggestion to the repo.
However, as it can be seen in the log, there is a bunch more packages
that would have to be added as exceptions, and we're still in letter "F".

All the errors seem to be of this type:

Failed to read
`/srv/mirrors/debian//pool/main/f/packagename/packagename-version.debian.tar.xz':
Bad file descriptor at /srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
Unable to open
/srv/mirrors/debian//pool/main/f/packagename/packagename-version.orig.tar.gz
at /srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
read() on closed filehandle GEN at
/srv/i18n.debian.org//dl10n/git/lib/Debian/Pkg/Tar.pm line 176.

And then at the end a different error:

Unable to open
/srv/mirrors/debian//pool/main/f/otherpackage/otherpackage.diff.gz at
/srv/i18n.debian.org//dl10n/git/lib/Debian/Pkg/Tar.pm line 785.

The offending code:

    $opts{parse_dft} ||= $self->{parse_last};
    $self->{patch} = Debian::Pkg::Diff->new($file, %opts);
    $self->{patch}->parse();

    foreach ($self->{patch}->list_files()) {
    $self->{data}->{files}->{$_}->{dchars} =
$self->{patch}->{data}->{files}->{$_}->{dchars};
    }

And then I guess there is a similar issue of what was happening in
Tar.pm, this time in
https://salsa.debian.org/l10n-team/dl10n/blob/master/lib/Debian/Pkg/Diff.pm

but there are several "Unable to open" there and I don't know how to fix
the issue.

> Note: The tools were designed at a time when CPU and disk were limited
> (there might have been more diversity in the packaging formats). This may
> not be the case now, and if somebody is interested in a (major) rewrite, it
> might be easier to just extract each source packages using dpkg-source (+
> heuristic to apply patches) than to do this in-memory extract and patch
> mechanism.
This also is beyond my skills; if anybody else can help...
Thanks

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Cannot run: gzip -9f -c 
"/srv/i18n.debian.org//tmp/gen-material/firefox-esr/firefox-52.7.3esr/python/mozbuild/mozbuild/locale/en-US/LC_MESSAGES/mozbuild.po"
 > 
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/unstable/main/f/firefox-esr/firefox-52.7.3esr/python/mozbuild/mozbuild/locale/en-US/LC_MESSAGES/firefox-esr_52.7.3esr-1_mozbuild.po.gz":
 No such file or directory
Cannot run: gzip -9f -c 
"/srv/i18n.debian.org//tmp/gen-material/firefox-esr/firefox-52.7.3esr/python/mach/mach/locale/en_US/LC_MESSAGES/alias.po"
 > 
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/unstable/main/f/firefox-esr/firefox-52.7.3esr/python/mach/mach/locale/en_US/LC_MESSAGES/firefox-esr_52.7.3esr-1_alias.po.gz":
 No such file or directory
Unable to open 
/srv/mirrors/debian//pool/main/f/firejail/firejail_0.9.52-2.debian.tar.xz at 
/srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
read() on closed filehandle GEN2839 at 
/srv/i18n.debian.org//dl10n/git/lib/Debian/Pkg/Tar.pm line 176.
Failed to read 
`/srv/mirrors/debian//pool/main/f/firejail/firejail_0.9.52-2.debian.tar.xz': 
Bad file descriptor at /srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
Unable to open 
/srv/mirrors/debian//pool/main/f/firejail/firejail_0.9.52.orig.tar.xz at 
/srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
read() on closed filehandle GEN2838 at 
/srv/i18n.debian.org//dl10n/git/lib/Debian/Pkg/Tar.pm line 176.
Failed to read 
`/srv/mirrors/debian//pool/main/f/firejail/firejail_0.9.52.orig.tar.xz': Bad 
file descriptor at /srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
Error: can't find debian/control; skipping package firejail.
Unable to open 
/srv/mirrors/debian//pool/main/f/firetools/firetools_0.9.52-1.debian.tar.xz at 
/srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
read() on closed filehandle GEN2841 at 
/srv/i18n.debian.org//dl10n/git/lib/Debian/Pkg/Tar.pm line 176.
Failed to read 
`/srv/mirrors/debian//pool/main/f/firetools/firetools_0.9.52-1.debian.tar.xz': 
Bad file descriptor at /srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
Unable to open 
/srv/mirrors/debian//pool/main/f/firetools/firetools_0.9.52.orig.tar.xz at 
/srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
read() on closed filehandle GEN2840 at 
/srv/i18n.debian.org//dl10n/git/lib/Debian/Pkg/Tar.pm line 176.
Failed to read 
`/srv/mirrors/debian//pool/main/f/firetools/firetools_0.9.52.orig.tar.xz': Bad 
file descriptor at /srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
Error: can't find 

Bug#896051: ITP: mbrola-ma1 -- Malay female voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-ma1
  Version : 0.0.20040816
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Malay female voice for Mbrola
 This package contains a Malay diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Malay female voice to be used with the MBROLA
 program.

Bug#896052: ITP: mbrola-nl1 -- Dutch male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-nl1
  Version : 0.2
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Dutch male voice for Mbrola
 This package contains a Dutch diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Dutch male voice to be used with the MBROLA
 program.

Bug#896050: ITP: mbrola-jp3 -- Japanese female voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-jp3
  Version : 0.0.20021022
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Japanese female voice for Mbrola
 This package contains a Japanese diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Japanese female voice to be used with the MBROLA
 program.

Bug#896043: ITP: mbrola-hn1 -- Korean male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-hn1
  Version : 4
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Korean male voice for Mbrola
 This package contains a Korean diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Korean male voice to be used with the MBROLA
 program.

Bug#896048: ITP: mbrola-jp1 -- Japanese male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-jp1
  Version : 0.0.2314
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Japanese male voice for Mbrola
 This package contains a Japanese diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Japanese male voice to be used with the MBROLA
 program.

Bug#896046: ITP: mbrola-it1 -- Italian male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-it1
  Version : 0.1
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Italian male voice for Mbrola
 This package contains an Italian diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides an Italian male voice to be used with the MBROLA
 program.

Bug#896049: ITP: mbrola-jp2 -- Japanese female voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-jp2
  Version : 0.1
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Japanese female voice for Mbrola
 This package contains a Japanese diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Japanese female voice to be used with the MBROLA
 program.

Bug#896047: ITP: mbrola-it2 -- Italian female voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-it2
  Version : 0.1
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Italian female voice for Mbrola
 This package contains an Italian diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides an Italian female voice to be used with the MBROLA
 program.

Bug#896044: ITP: mbrola-in1 -- Hindi male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-in1
  Version : 0.0.20010206
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Hindi male voice for Mbrola
 This package contains a Hindi diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Hindi male voice to be used with the MBROLA
 program.

Bug#896042: ITP: mbrola-hb2 -- Hebrew female voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-hb2
  Version : 0.0.20040902
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Hebrew female voice for Mbrola
 This package contains a Hebrew diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Hebrew female voice to be used with the MBROLA
 program.

Bug#896041: ITP: mbrola-hb1 -- Hebrew male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-hb1
  Version : 0.0.2308
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Hebrew male voice for Mbrola
 This package contains a Hebrew diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Hebrew male voice to be used with the MBROLA
 program.

Bug#896030: ITP: mbrola-ca2 -- Canadian French male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-ca2
  Version : 0.0.20031022
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Canadian French male voice for Mbrola
 This package contains a Canadian French diphone database provided in the 
context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Canadian French male voice to be used with the MBROLA
 program.

Bug#896036: ITP: mbrola-fr2 -- French female voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-fr2
  Version : 2.060
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : French female voice for Mbrola
 This package contains a French diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a French female voice to be used with the MBROLA
 program.

Bug#896035: ITP: mbrola-es4 -- Spanish male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-es4
  Version : 0.0.20020903
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Spanish male voice for Mbrola
 This package contains a Spanish diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Spanish male voice to be used with the MBROLA
 program.

Bug#896040: ITP: mbrola-fr7 -- French Belgian male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-fr7
  Version : 2.00b
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : French Belgian male voice for Mbrola
 This package contains a French Belgian diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a French Belgian male voice to be used with the MBROLA
 program.

Bug#896026: ITP: mbrola-ar1 -- Arabic male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-ar1
  Version : 1.0
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Arabic male voice for Mbrola
 This package contains an Arabic diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides an Arabic male voice to be used with the MBROLA
 program.

Bug#896039: ITP: mbrola-fr6 -- French male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-fr6
  Version : 0.0.20010330
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : French male voice for Mbrola
 This package contains a French diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a French male voice to be used with the MBROLA
 program.

Bug#896033: ITP: mbrola-de8 -- German-Bavarian male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-de8
  Version : 0.0.20040811
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : German-Bavarian male voice for Mbrola
 This package contains a German-Bavarian diphone database provided in the 
context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a German-Bavarian male voice to be used with the MBROLA
 program.

Bug#896028: ITP: mbrola-bz1 -- Breton female voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-bz1
  Version : 0.99
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Breton female voice for Mbrola
 This package contains a Breton diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Breton female voice to be used with the MBROLA
 program.

Bug#896034: ITP: mbrola-es3 -- Spanish female voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-es3
  Version : 0.0.20141124
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Spanish female voice for Mbrola
 This package contains a Spanish diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Spanish female voice to be used with the MBROLA
 program.

Bug#896038: ITP: mbrola-fr5 -- French Belgian male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-fr5
  Version : 2.060
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : French Belgian male voice for Mbrola
 This package contains a French Belgian diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a French Belgian male voice to be used with the MBROLA
 program.

Bug#896037: ITP: mbrola-fr3 -- French male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-fr3
  Version : 2.060
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : French male voice for Mbrola
 This package contains a French diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a French male voice to be used with the MBROLA
 program.

Bug#896031: ITP: mbrola-cn1 -- Chinese female voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-cn1
  Version : 0.0.20
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Chinese female voice for Mbrola
 This package contains a Chinese diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Chinese female voice to be used with the MBROLA
 program.

Bug#896032: ITP: mbrola-cz1 -- Czech female voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-cz1
  Version : 0.1
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Czech female voice for Mbrola
 This package contains a Czech diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Czech female voice to be used with the MBROLA
 program.

Bug#896027: ITP: mbrola-ar2 -- Arabic male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-ar2
  Version : 0.0.20001015
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Arabic male voice for Mbrola
 This package contains an Arabic diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides an Arabic male voice to be used with the MBROLA
 program.

Bug#896029: ITP: mbrola-ca1 -- Canadian French male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2018-04-18
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mbrola-ca1
  Version : 1.00
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Canadian French male voice for Mbrola
 This package contains a Canadian French diphone database provided in the 
context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Canadian French male voice to be used with the MBROLA
 program.

Bug#896025: python-mne FTBFS with python-matplotlib 2.2.2-1

[Adrian Bunk]

Source: python-mne
Version: 0.15.2+dfsg-2
Severity: serious

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

...
=== FAILURES ===
___ [doctest] mne.viz.misc.plot_ideal_filter ___
840 .. versionadded:: 0.14
841 
842 Examples
843 
844 Plot a simple ideal band-pass filter::
845 
846 >>> from mne.viz import plot_ideal_filter
847 >>> freq = [0, 1, 40, 50]
848 >>> gain = [0, 1, 1, 0]
849 >>> plot_ideal_filter(freq, gain, flim=(0.1, 100))  #doctest: 
+ELLIPSIS
Expected:

Got:


/build/1st/python-mne-0.15.2+dfsg/mne/viz/misc.py:849: DocTestFailure
 test_plot_connectivity_circle _

def test_plot_connectivity_circle():
"""Test plotting connectivity circle
"""
import matplotlib.pyplot as plt
node_order = ['frontalpole-lh', 'parsorbitalis-lh',
  'lateralorbitofrontal-lh', 'rostralmiddlefrontal-lh',
  'medialorbitofrontal-lh', 'parstriangularis-lh',
  'rostralanteriorcingulate-lh', 'temporalpole-lh',
  'parsopercularis-lh', 'caudalanteriorcingulate-lh',
  'entorhinal-lh', 'superiorfrontal-lh', 'insula-lh',
  'caudalmiddlefrontal-lh', 'superiortemporal-lh',
  'parahippocampal-lh', 'middletemporal-lh',
  'inferiortemporal-lh', 'precentral-lh',
  'transversetemporal-lh', 'posteriorcingulate-lh',
  'fusiform-lh', 'postcentral-lh', 'bankssts-lh',
  'supramarginal-lh', 'isthmuscingulate-lh', 
'paracentral-lh',
  'lingual-lh', 'precuneus-lh', 'inferiorparietal-lh',
  'superiorparietal-lh', 'pericalcarine-lh',
  'lateraloccipital-lh', 'cuneus-lh', 'cuneus-rh',
  'lateraloccipital-rh', 'pericalcarine-rh',
  'superiorparietal-rh', 'inferiorparietal-rh', 
'precuneus-rh',
  'lingual-rh', 'paracentral-rh', 'isthmuscingulate-rh',
  'supramarginal-rh', 'bankssts-rh', 'postcentral-rh',
  'fusiform-rh', 'posteriorcingulate-rh',
  'transversetemporal-rh', 'precentral-rh',
  'inferiortemporal-rh', 'middletemporal-rh',
  'parahippocampal-rh', 'superiortemporal-rh',
  'caudalmiddlefrontal-rh', 'insula-rh', 
'superiorfrontal-rh',
  'entorhinal-rh', 'caudalanteriorcingulate-rh',
  'parsopercularis-rh', 'temporalpole-rh',
  'rostralanteriorcingulate-rh', 'parstriangularis-rh',
  'medialorbitofrontal-rh', 'rostralmiddlefrontal-rh',
  'lateralorbitofrontal-rh', 'parsorbitalis-rh',
  'frontalpole-rh']
label_names = ['bankssts-lh', 'bankssts-rh', 
'caudalanteriorcingulate-lh',
   'caudalanteriorcingulate-rh', 'caudalmiddlefrontal-lh',
   'caudalmiddlefrontal-rh', 'cuneus-lh', 'cuneus-rh',
   'entorhinal-lh', 'entorhinal-rh', 'frontalpole-lh',
   'frontalpole-rh', 'fusiform-lh', 'fusiform-rh',
   'inferiorparietal-lh', 'inferiorparietal-rh',
   'inferiortemporal-lh', 'inferiortemporal-rh', 
'insula-lh',
   'insula-rh', 'isthmuscingulate-lh', 
'isthmuscingulate-rh',
   'lateraloccipital-lh', 'lateraloccipital-rh',
   'lateralorbitofrontal-lh', 'lateralorbitofrontal-rh',
   'lingual-lh', 'lingual-rh', 'medialorbitofrontal-lh',
   'medialorbitofrontal-rh', 'middletemporal-lh',
   'middletemporal-rh', 'paracentral-lh', 'paracentral-rh',
   'parahippocampal-lh', 'parahippocampal-rh',
   'parsopercularis-lh', 'parsopercularis-rh',
   'parsorbitalis-lh', 'parsorbitalis-rh',
   'parstriangularis-lh', 'parstriangularis-rh',
   'pericalcarine-lh', 'pericalcarine-rh', 'postcentral-lh',
   'postcentral-rh', 'posteriorcingulate-lh',
   'posteriorcingulate-rh', 'precentral-lh', 
'precentral-rh',
   'precuneus-lh', 'precuneus-rh',
   'rostralanteriorcingulate-lh',
   'rostralanteriorcingulate-rh', 'rostralmiddlefrontal-lh',
   'rostralmiddlefrontal-rh', 'superiorfrontal-lh',
   'superiorfrontal-rh', 'superiorparietal-lh',
   'superiorparietal-rh', 'superiortemporal-lh',
   'superiortemporal-rh', 

Bug#896024: www.debian.org: Invalid footnote links in the online version of the Debian Policy Manual v4.1.4.1

[Fernando Silveira]

Package: www.debian.org
Severity: normal

While reading the online version of the Debian Policy Manual v4.1.4.1
I could see that the footnote links are not working correctly. Multiple
parts of the text uses the same id name and conflicts when you try to
reach them.

An example is when I go to a paragraph of the section 5 ending with the
phrase below and click the footnote link number 7:

> For example, the following parts are in sorted order from earliest to
> latest: ~~, ~~a, ~, the empty part, a. [7]

Doing this incorrectly leads you to an unrelated part of the manual,
regarding a rationale of the section number 4, while the correct part
is the following:

> [7] One common use of ~ is for upstream pre-releases. For example,
> 1.0~beta1~svn1245 sorts earlier than 1.0~beta1, which sorts earlier
> than 1.0.

The link I'm using is https://www.debian.org/doc/debian-policy/.

PS: This problem doesn't happen when I read the offline version Debian
Policy Manual v3.9.5.0 (fetched in Ubuntu 14.04 from it's official APT
repository).


-- System Information:
Debian Release: 6.0.10
  APT prefers squeeze-lts
  APT policy: (500, 'squeeze-lts')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-62-generic (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#657443: synergy: Missing IPv6 support

[Kevin Otte]

Upstream has said they have no intention of merging the changes because
it is not consistent with their profit motive:

https://github.com/symless/synergy-core/pull/6178

Bug#896023: autopkgtest: dependency issue triggered mismatch between package version and its test

[Paul Gevers]

This Ubuntu bug is remotely related:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1760810

The suggestion there is to use a different resolver in the fallback
(that would probably have prevented the current case of the issue, but
not the general problem I guess).

Quote:
'''
Julian Andres Klode (juliank) wrote on 2018-04-03:  #3

sbuild passes:

--solver aspcud -o APT::Solver::Strict-Pinning=false -o
'APT::Solver::aspcud::Preferences=-removed,-changed,-new,+sum(solution,apt-pin)'

That probably works here too. I guess I'd try without, and then fall
back to it if pure APT can't handle it.
'''



signature.asc
Description: OpenPGP digital signature

Bug#896016: strace: please make the build reproducible

[Chris Lamb]

forwarded 896016 https://github.com/strace/strace/pull/68
thanks

I've forwarded this upstream here:

  https://github.com/strace/strace/pull/68


Regards,

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

Bug#896023: autopkgtest: dependency issue triggered mismatch between package version and its test

[Paul Gevers]

Source: autopkgtest
Version: 5.2
Severity: normal
User: debian...@lists.debian.org
Usertags: issue

In the case of migration testing, the following issue may occur.

autopkgtest inspects the test of package A from testing, as that is what
it wants to run. Then, it requests apt to install package B (the package
under investigation for migration) from unstable. Due to dependency
issues (not clear to me where this goes wrong yet in this case, but
there is an autopkgtest fallback mode ongoing), package A may actually
be installed from unstable and there is a mismatch between the test
version and the tested version of package A, causing undesired failure.

A current example is fig2dev which is run for texlive-base (log
attached, taken from
https://ci.debian.net/data/autopkgtest/testing/amd64/f/fig2dev/180600/log.gz).


1:3.2.6a-6  2018-04-18 12:51:38 UTC migration-reference/0   0h 1m 2s
passdebci log   test logartifacts

1:3.2.6a-6  2018-04-18 12:51:36 UTC texlive-base/2018.20180416-1
0h 1m
3s  faildebci log   test logartifacts

1:3.2.7-2   2018-04-15 10:13:43 UTC fig2dev/1:3.2.7-2   0h 1m 
16s   pass
debci log   test logartifacts

I am filling this bug to store the information. I don't know yet what
autopkgtest should actually do in this case. Maybe the solution lies
even with britney, that could become smarter in triggering. If it
already knows there is a dependency issue, it could trigger the set,
such that the test suite is already taken from unstable to begin with.

Paul



fig2dev_testing_with_texlive-base.log.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature

Bug#896022: autopkgtest: dependency issue triggered mismatch between package version and its test

[Paul Gevers]

Source: autopktest
Version: 5.2
Severity: normal
User: debian...@lists.debian.org
Usertags: issue

In the case of migration testing, the following issue may occur.

Autopkgtest inspects the test of package A from testing, as that is what
it wants to run. Then, it requests apt to install package B (the package
under investigation for migration) from unstable. Due to dependency
issues (not clear to me where this goes wrong yet in this case, but
there is an autopkgtest fallback mode ongoing), package A may actually
be installed from unstable and there is a mismatch between the test
version and the tested version of package A, causing undesired failure.

A current example is fig2dev which is run for texlive-base (log
attached, taken from
https://ci.debian.net/data/autopkgtest/testing/amd64/f/fig2dev/180600/log.gz).


1:3.2.6a-6  2018-04-18 12:51:38 UTC migration-reference/0   0h 1m 2s
passdebci log   test logartifacts

1:3.2.6a-6  2018-04-18 12:51:36 UTC texlive-base/2018.20180416-1
0h 1m
3s  faildebci log   test logartifacts

1:3.2.7-2   2018-04-15 10:13:43 UTC fig2dev/1:3.2.7-2   0h 1m 
16s   pass
debci log   test logartifacts

I am filling this bug to store the information. I don't know yet what
autopkgtest should actually do in this case. Maybe the solution lies
even with britney, that could become smarter in triggering. If it
already knows there is a dependency issue, it could trigger the set,
such that the test suite is already taken from unstable to begin with.

Paul


fig2dev_testing_with_texlive-base.log.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature

Bug#895959: [Pkg-openssl-devel] Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1 in exp

[Sebastian Andrzej Siewior]

On 2018-04-18 16:14:37 [+0200], Kurt Roeckx wrote:
> I can't see a reason why TLS 1.3 would be different in this regard,
> I expect the same behaviour for all SSL/TLS version. Anyway, it
> could just have been some code refactor that "fixed" it so that it
> generates the error now. Or maybe the old code generated an error
> on SSL_write() instead of the SIGPIPE?
> 
> It would at least be good to know how the old version behaved.

As per bisect, openssl commit 30f05b19d3ba ("Create the NewSessionTicket
message in TLSv1.3") is responsible for the SIGPIPE.
But I *think* this is unrelated. The perl testcase triggers reliable. My
C test case I used yestrday triggers only under strace (but I think this
was not the case yesterday). So I *think* this commit changed the
timming and now the SIGPIPE is more likely.

> Kurt

Sebastian

Bug#896021: mruby: CVE-2018-10199: Use after free in File#initilialize_copy

[Salvatore Bonaccorso]

Source: mruby
Version: 1.4.0-1
Severity: grave
Tags: patch security upstream
Forwarded: https://github.com/mruby/mruby/issues/4001

Hi,

The following vulnerability was published for mruby.

CVE-2018-10199[0]:
| In versions of mruby up to and including 1.4.0, a use-after-free
| vulnerability exists in src/io.c::File#initilialize_copy(). An attacker
| that can cause Ruby code to be run can possibly use this to execute
| arbitrary code.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-10199
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10199
[1] https://github.com/mruby/mruby/issues/4001
[2] 
https://github.com/mruby/mruby/commit/b51b21fc63c9805862322551387d9036f2b63433

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#895866: tomcat8: Errors thrown when connecting to default HTTP connector (localhost:8080)

[Emmanuel Bourg]

Le 18/04/2018 à 19:26, Michael Welsh Duggan a écrit :

> Thanks.  This would be good, as a Debian system will use
> /usr/lib/jre/default-java to run tomcat8 by default, and that symlink is
> not one changed by the alternatives system.  As a result, this will not
> run without changing JAVA_HOME in /etc/default/tomcat8.

Note that the default JRE has already been switched to OpenJDK 9, so if
you haven't changed JAVA_HOME in /etc/default/tomcat8 it should run fine.

Bug#895184: roundcube: CVE-2018-9846: check_request() bypass in archive plugin

[Guilhem Moulin]

Hi Salvatore,

On Sun, 08 Apr 2018 at 10:27:10 +0200, Salvatore Bonaccorso wrote:
> The following vulnerability was published for roundcube.
> 
> CVE-2018-9846[0]:
> | In Roundcube from versions 1.2.0 to 1.3.5, with the archive plugin
> | enabled and configured, it's possible to exploit the unsanitized,
> | user-controlled "_uid" parameter (in an archive.php
> | _task=mail_mbox=INBOX_action=plugin.move2archive request) to 
> perform
> | an MX (IMAP) injection attack by placing an IMAP command after a %0d%0a
> | sequence. NOTE: this is less easily exploitable in 1.3.4 and later
> | because of a Same Origin Policy protection mechanism.
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

1.2.8 was released yesterday.  Attached is a debdiff with the following
upstream commits cherry-picked (ignoring changes to CHANGELOG):


https://github.com/roundcube/roundcubemail/commit/cdeb6234a2e029c499898c3432fdf5b2cf093640

https://github.com/roundcube/roundcubemail/commit/5b7e9a2c960eb4fd2364921297020a5dcd2d7dbc

https://github.com/roundcube/roundcubemail/commit/c69b851b8a704f6483ec9d1cae7cd1ecd33c3343

https://github.com/roundcube/roundcubemail/commit/7901047474729a7f466eb8c59c92a36fc7cf0e70

Should we go via stretch-security, or aim for the next stable point
release?

-- 
Guilhem.
diff -Nru roundcube-1.2.3+dfsg.1/debian/changelog 
roundcube-1.2.3+dfsg.1/debian/changelog
--- roundcube-1.2.3+dfsg.1/debian/changelog 2017-11-09 06:45:05.0 
+0100
+++ roundcube-1.2.3+dfsg.1/debian/changelog 2018-04-18 21:00:09.0 
+0200
@@ -1,3 +1,13 @@
+roundcube (1.2.3+dfsg.1-4+deb9u2) stretch-security; urgency=high
+
+  * Backport fix for CVE-2018-9846: When the archive plugin enabled and
+configured, it's possible to exploit the unsanitized, user-controlled
+"_uid" parameter to perform an MX (IMAP) injection attack.
+https://github.com/roundcube/roundcubemail/issues/6238
+(Closes: #895184).
+
+ -- Guilhem Moulin   Wed, 18 Apr 2018 21:00:09 +0200
+
 roundcube (1.2.3+dfsg.1-4+deb9u1) stretch-security; urgency=high
 
   * Backport fix for CVE-2017-16651: File disclosure vulnerability caused by
diff -Nru roundcube-1.2.3+dfsg.1/debian/patches/CVE-2018-9846.patch 
roundcube-1.2.3+dfsg.1/debian/patches/CVE-2018-9846.patch
--- roundcube-1.2.3+dfsg.1/debian/patches/CVE-2018-9846.patch   1970-01-01 
01:00:00.0 +0100
+++ roundcube-1.2.3+dfsg.1/debian/patches/CVE-2018-9846.patch   2018-04-18 
21:00:09.0 +0200
@@ -0,0 +1,84 @@
+---
+ plugins/archive/archive.php  |6 --
+ plugins/managesieve/managesieve.php  |4 ++--
+ plugins/markasjunk/markasjunk.php|9 ++---
+ program/lib/Roundcube/rcube_imap_generic.php |   10 ++
+ 4 files changed, 18 insertions(+), 11 deletions(-)
+
+--- a/program/lib/Roundcube/rcube_imap_generic.php
 b/program/lib/Roundcube/rcube_imap_generic.php
+@@ -3836,13 +3836,13 @@ class rcube_imap_generic
+ 
+ if (!is_array($messages)) {
+ // if less than 255 bytes long, let's not bother
+-if (!$force && strlen($messages)<255) {
+-return $messages;
++if (!$force && strlen($messages) < 255) {
++return preg_match('/[^0-9:,*]/', $messages) ? 'INVALID' : 
$messages;
+ }
+ 
+ // see if it's already been compressed
+ if (strpos($messages, ':') !== false) {
+-return $messages;
++return preg_match('/[^0-9:,*]/', $messages) ? 'INVALID' : 
$messages;
+ }
+ 
+ // separate, then sort
+@@ -3877,7 +3877,9 @@ class rcube_imap_generic
+ }
+ 
+ // return as comma separated string
+-return implode(',', $result);
++$result = implode(',', $result);
++
++return preg_match('/[^0-9:,]/', $result) ? 'INVALID' : $result;
+ }
+ 
+ /**
+--- a/plugins/archive/archive.php
 b/plugins/archive/archive.php
+@@ -122,8 +122,10 @@ class archive extends rcube_plugin
+   $index = $storage->index(null, rcmail_sort_column(), 
rcmail_sort_order());
+   $messageset = array($current_mbox => $index->get());
+ }
+-else {
+-  $messageset = rcmail::get_uids();
++else if (!empty($uids)) {
++  $messageset = rcmail::get_uids($uids, $current_mbox);
++} else {
++  $messageset = array();
+ }
+ 
+ foreach ($messageset as $mbox => $uids) {
+--- a/plugins/managesieve/managesieve.php
 b/plugins/managesieve/managesieve.php
+@@ -190,8 +190,8 @@ class managesieve extends rcube_plugin
+ function managesieve_actions()
+ {
+ // handle fetching email headers for the new filter form
+-if ($uid = rcube_utils::get_input_value('_uid', 
rcube_utils::INPUT_POST)) {
+-$uids= rcmail::get_uids();
++if ($_uid = rcube_utils::get_input_value('_uid', 

Bug#896019: libglib2.0-0: undefined symbol g_date_copy breaking many programs

[Michael Biebl]

Am 18.04.2018 um 20:43 schrieb rektide de la faye:
> Package: libglib2.0-0
> Version: 2.56.1-2
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> I recently updated a number of packages on my Debian/testing laptop, via 
> aptitude
> and included in that upgrade to satisfy dependencies was libglib-2.0-0.
> 
> Since installing, many many programs on my system refuse to start. Trying
> to run nmcli, for example, returns:
> 
> nmcli: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0: 
> undefined symbol: g_date_copy
> 
> I also see like errors trying to run lightdm, urxvt, vi.
> This file appears to be a symlink, pointing at 
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.1.
> 
> There is a .4200.0 in that directory. I tried symlinking to that, but got a 
> different set of undefined
> symbol errors keeping me from running things- g_option_group_unref.
> 


Where is that .4200.0 file coming from?
This looks pretty much like a duplicate of #894763


-- 
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#896020: mruby: CVE-2018-10191: Use after free caused by integer overflow in environment stack

[Salvatore Bonaccorso]

Source: mruby
Version: 1.0.0+20141015+gitb4cc962c-1
Severity: grave
Tags: patch security upstream
Forwarded: https://github.com/mruby/mruby/issues/3995

Hi,

The following vulnerability was published for mruby.

CVE-2018-10191[0]:
| In versions of mruby up to and including 1.4.0, an integer overflow
| exists in src/vm.c::mrb_vm_exec() when handling OP_GETUPVAR in the
| presence of deep scope nesting, resulting in a use-after-free. An
| attacker that can cause Ruby code to be run can use this to possibly
| execute arbitrary code.

Demostrable/verifiable with an ASAN build of mruby:

dummy@sid:~$ ./mruby-1.4.0/bin/mruby ./use_after_free.rb 
=
==3180==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62514100 
at pc 0x004a77c3 bp 0x7ffef79d70d0 sp 0x7ffef79d70c8
READ of size 16 at 0x62514100 thread T0
#0 0x4a77c2 in mrb_vm_exec src/vm.c:1196
#1 0x4ac408 in mrb_vm_run src/vm.c:935
#2 0x52df53 in mrb_load_exec mrbgems/mruby-compiler/core/parse.y:5840
#3 0x404036 in main mrbgems/mruby-bin-mruby/tools/mruby/mruby.c:227
#4 0x7ffb5b242a86 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x21a86)
#5 0x405b89 in _start (/home/dummy/mruby-1.4.0/bin/mruby+0x405b89)

Address 0x62514100 is a wild pointer.
SUMMARY: AddressSanitizer: heap-buffer-overflow src/vm.c:1196 in mrb_vm_exec
Shadow bytes around the buggy address:
  0x0c4a7fffa7d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fffa7e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fffa7f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fffa800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fffa810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c4a7fffa820:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fffa830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fffa840: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fffa850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fffa860: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fffa870: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==3180==ABORTING
dummy@sid:~$

dummy@sid:~$ ./mruby-1.4.0/bin/mruby ./null_ptr_deref.rb 
/root/mruby-1.4.0/src/class.c:94:11: runtime error: member access within null 
pointer of type 'struct RClass'
ASAN:DEADLYSIGNAL
=
==3189==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
0x004b03b3 bp 0x7ffe636d25b0 sp 0x7ffe636d2560 T0)
==3189==The signal is caused by a READ memory access.
==3189==Hint: address points to the zero page.
#0 0x4b03b2 in prepare_singleton_class src/class.c:94
#1 0x4c18da in mrb_singleton_class src/class.c:1320
#2 0x4858fa in mrb_vm_exec src/vm.c:2895
#3 0x4ac408 in mrb_vm_run src/vm.c:935
#4 0x52df53 in mrb_load_exec mrbgems/mruby-compiler/core/parse.y:5840
#5 0x404036 in main mrbgems/mruby-bin-mruby/tools/mruby/mruby.c:227
#6 0x7fe21ffe5a86 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x21a86)
#7 0x405b89 in _start (/home/dummy/mruby-1.4.0/bin/mruby+0x405b89)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV src/class.c:94 in prepare_singleton_class
==3189==ABORTING
dummy@sid:~$

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-10191
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10191
[1] https://github.com/mruby/mruby/issues/3995

Regards,
Salvatore

Bug#891294: plasma-discover: Discover->settings->software sources does nothing

[luca pedrielli]

I receive a " SECURITY information for user " email that says:

machine : Apr 18 21:07:59 : user : 1 incorrect password attempt ; TTY=pts/4 ; 
PWD=/home/user ; USER=root ; 
COMMAND=/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu_stub -


It seems that a wrong password is passed

PWD=/home/user

Bug#862883: Port from libnm-glib/libnm-util to libnm

[Michael Biebl]

Am 18.04.2018 um 19:55 schrieb Pino Toscano:
> In data mercoledì 18 aprile 2018 19:35:01 CEST, Michael Biebl ha scritto:
>> Control: tags -1 + patch
>>
>> I made some more minor tweaks to v2:
>>
>> - Update debian/changelog
>> - Drop debian/patches/add_glib_for_nm, no longer necessary
>>
>> v3 of the debdiff is attached. I was told that it's probably not worth
>> forwarding this upstream, as KDE4 development is pretty much dormant.
> 
> While the KDE 4 development is basically stopped, the code here was
> basically copied into the compatibility framework kdelibs4support;
> hence I'd prefer to see the resolution of #862877 (or at least upstream
> feedback on the patch for it), so the same fix can be backported here
> too.

So, we have upstream feedback now, but I'm not sure what to make of it.
It seems the preference is to simply drop NM support in networkstatus,
given that NM support in kdelibs4support was never actually enabled and
kde-runtime is basically on its way out anyway.

I have no preference either way.

Can you please let me know how you intend to proceed?

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



signature.asc
Description: OpenPGP digital signature

Bug#895452: libquadmath and quadmath.h do not exist on ppc64

[Dennis Clarke]

I will test gcc-8-20180415 and see what results I get.

Bug#896019: libglib2.0-0: undefined symbol g_date_copy breaking many programs

[rektide de la faye]

Package: libglib2.0-0
Version: 2.56.1-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I recently updated a number of packages on my Debian/testing laptop, via 
aptitude
and included in that upgrade to satisfy dependencies was libglib-2.0-0.

Since installing, many many programs on my system refuse to start. Trying
to run nmcli, for example, returns:

nmcli: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0: 
undefined symbol: g_date_copy

I also see like errors trying to run lightdm, urxvt, vi.
This file appears to be a symlink, pointing at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.1.

There is a .4200.0 in that directory. I tried symlinking to that, but got a 
different set of undefined
symbol errors keeping me from running things- g_option_group_unref.

This does appear to gravely reduce the functionality of my workstation.

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

Kernel: Linux 4.4.1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/zsh

Versions of packages libglib2.0-0 depends on:
ii  libc62.27-3
ii  libffi6  3.2.1-4
ii  libmount12.30.2-0.1
ii  libpcre3 8.39-9
ii  libselinux1  2.6-3+b1
ii  zlib1g   2.8.dfsg-2+b1

Versions of packages libglib2.0-0 recommends:
ii  libglib2.0-data   2.56.1-2
ii  shared-mime-info  1.7-1
ii  xdg-user-dirs 0.15-2

libglib2.0-0 suggests no packages.

-- no debconf information

Bug#896018: imagemagick: CVE-2018-10177: Infinite loop in ReadOneMNGImage

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.8.9.9-5
Severity: important
Tags: patch security upstream
Forwarded: https://github.com/ImageMagick/ImageMagick/issues/1095

Hi,

The following vulnerability was published for imagemagick.

CVE-2018-10177[0]:
| In ImageMagick 7.0.7-28, there is an infinite loop in the
| ReadOneMNGImage function of the coders/png.c file. Remote attackers
| could leverage this vulnerability to cause a denial of service via a
| crafted mng file.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-10177
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10177
[1] https://github.com/ImageMagick/ImageMagick/issues/1095

Regards,
Salvatore

Bug#896011: expat: Make source package bootstrappable

[GCS]

Hi Daniel,

On Wed, Apr 18, 2018 at 7:17 PM, Daniel Schepler  wrote:
> The expat source package is involved in a build dependency cycle:
[...]
> It would be good if you could provide a build profile to be able to
> bootstrap without docbook2x being installable.
 With the following patch, you can bootstrap expat without docbook2x -
hope it's enough for you.

Regards,
Laszlo/GCS
diff -Nru expat-2.2.5/debian/control expat-2.2.5/debian/control
--- expat-2.2.5/debian/control	2017-12-17 07:33:25.0 +
+++ expat-2.2.5/debian/control	2018-04-18 17:49:19.0 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Laszlo Boszormenyi (GCS) 
 Standards-Version: 4.1.2
-Build-Depends: debhelper (>= 11), docbook-to-man, docbook2x,
+Build-Depends: debhelper (>= 11), docbook-to-man,
  libbsd-dev [kfreebsd-amd64 kfreebsd-i386 hurd-i386]
 Homepage: https://libexpat.github.io/
 Vcs-Browser: http://svn.debian.org/wsvn/debian-xml-sgml/packages/expat/trunk/
diff -Nru expat-2.2.5/debian/expat.install expat-2.2.5/debian/expat.install
--- expat-2.2.5/debian/expat.install	2016-06-21 15:47:13.0 +
+++ expat-2.2.5/debian/expat.install	2018-04-18 17:49:19.0 +
@@ -1,2 +1 @@
 usr/bin
-usr/share/man
diff -Nru expat-2.2.5/debian/rules expat-2.2.5/debian/rules
--- expat-2.2.5/debian/rules	2017-12-16 07:24:56.0 +
+++ expat-2.2.5/debian/rules	2018-04-18 17:49:19.0 +
@@ -54,12 +54,12 @@
 build/config.status: config-common-stamp
 	dh_testdir
 	(mkdir -p $(@D); cd $(@D); CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" \
-	 ../src/configure $(CONFFLAGS) --prefix=/usr --mandir=\$${prefix}/share/man --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH))
+	 ../src/configure $(CONFFLAGS) --prefix=/usr --mandir=\$${prefix}/share/man --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) --without-docbook)
 
 buildw/config.status: config-common-stamp
 	dh_testdir
 	(mkdir -p $(@D); cd $(@D); CFLAGS="$(CFLAGS) -DXML_UNICODE" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" \
-	 ../srcw/configure $(CONFFLAGS) --prefix=/usr --mandir=\$${prefix}/share/man --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH))
+	 ../srcw/configure $(CONFFLAGS) --prefix=/usr --mandir=\$${prefix}/share/man --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) --without-docbook)
 
 clean:
 	dh_testdir
@@ -75,7 +75,7 @@
 build-indep: build-stamp
 build-stamp: build/config.status buildw/config.status
 	dh_testdir
-	$(MAKE) $(NJOBS) -C build/
+	$(MAKE) $(NJOBS) -C build/ lib xmlwf tests examples
 	$(MAKE) $(NJOBS) -C buildw/lib all
 #	docbook-to-man doc/xmlwf.sgml > debian/xmlwf.1
 	touch $@
@@ -85,7 +85,7 @@
 	dh_testroot
 	dh_prep
 	dh_installdirs
-	$(MAKE) -C build/ install DESTDIR=$(CURDIR)/debian/tmp
+	$(MAKE) -C build/ install-exec install-pkgconfigDATA DESTDIR=$(CURDIR)/debian/tmp
 	$(MAKE) -C buildw/lib install DESTDIR=$(CURDIR)/debian/tmp APIHEADER=
 	# Move libexpat.so.* to /lib so that zfsutils can use it.
 	mkdir -p $(CURDIR)/debian/tmp/lib/$(DEB_HOST_MULTIARCH)

Bug#895851: sh: 1: /usr/local/share/gkrellm/GrabWeather: not found

[Norbert Veber]

Thanks.   Unfortunately my Debian key was removed for being too old 
(weak).  I haven't been able to find anyone to sign a new one yet.


Feel free to NMU if you can.

On 2018-04-16 16:12, Roland Hieber wrote:

Package: gkrellweather
Version: 2.0.8-2.1~ppa1
Followup-For: Bug #895851

Here is that patch I mentioned...

Bug#895598: sparse: 0.5.2 release

[Uwe Kleine-König]

Control: tag -1 + pending

On Fri, Apr 13, 2018 at 11:26:23AM +0200, Mathieu Malaterre wrote:
> Looks like there is a new version for sparse:
> 
> https://git.kernel.org/pub/scm/devel/sparse/sparse.git/tag/?h=v0.5.2
> 
> Would be nice to package.

I started to work on this, there are a few minor things I want to fix
before uploading, I hope to get these done tomorrow and upload then.
The version bump is already pushed to the packaging git.

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#896016: strace: please make the build reproducible

[Chris Lamb]

Source: strace
Version: 4.21-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that strace could not be built reproducibly as it encodes a
timezone-varying date in the manpage.

Patch attached that uses SOURCE_DATE_EPOCH [1].

  [0] https://reproducible-builds.org/
  [1] https://reproducible-builds.org/specs/source-date-epoch/


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/reproducible-build 2018-04-18 18:48:03.072934833 +0100
@@ -0,0 +1,24 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2018-04-18
+
+--- strace-4.21.orig/file-date-gen
 strace-4.21/file-date-gen
+@@ -20,6 +20,11 @@ date=
+ 
+ [ -f "${DATE_FILE}" ] && date="$(cat "${DATE_FILE}")"
+ 
++# Use SOURCE_DATE_EPOCH if it exists.
++# 
++[ -n "${SOURCE_DATE_EPOCH}" ] ||
++  date="@${SOURCE_DATE_EPOCH}"
++
+ [ -n "${date}" ] ||
+   date="$(git log -n 1 --format=format:%cD --no-patch "${FILE}")"
+ 
+@@ -32,4 +37,4 @@ date=
+   exit 1
+ }
+ 
+-exec printf "%s" $(date "+${DATE_FORMAT}" -d "${date}")
++exec printf "%s" $(date -u "+${DATE_FORMAT}" -d "${date}")
--- a/debian/patches/series 2018-04-18 18:43:14.655180095 +0100
--- b/debian/patches/series 2018-04-18 18:48:01.920928268 +0100
@@ -1 +1,2 @@
 no-arm-unaligned-access
+reproducible-build

Bug#862877: Port from libnm-glib/libnm-util to libnm

[Michael Biebl]

Hi Pino

Am 18.04.2018 um 19:50 schrieb Pino Toscano:
> In data mercoledì 18 aprile 2018 19:01:53 CEST, Michael Biebl ha scritto:
>> Control: tags -1 + patch
>>
>> Attached is a debdiff which is based on lubo's patch.
>>
>> Changes to the initial patch
>> - Use Q_SLOTS instead of slots, instead of simply commenting it out
>> - Use nm-dbus-interface.h include instead of NetworkManager.h, so we
>> don't pull in any glib/gio related headers
>> - Drop NM_CHECK_VERSION define, no longer needed.
>>
>> I've submitted the same patch upstream.
> 
> Do you have the link to the upstream submission? Note that these days
> upstream uses phabricator [1] for patch reviews.

The bug report has been tagged accordingly already, but for completeness
sake, the upstream bug report is
https://bugs.kde.org/show_bug.cgi?id=393255


-- 
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#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[Jeremy Bicha]

Source: inotify-tools
Version: 3.14-5

Please consider using the dgit-maint-gbp workflow instead of the
dgit-maint-merge workflow.

The recent switch from 3.0 (quilt) eliminates useful context and
metadata from the Debian package itself. That metadata is now only
available in the git repo.

Direct changes to the upstream sources as done in the 1.0 source
format don't enforce a clean separation between upstream sources and
the Debian changes. This makes it more challenging for a downstream
like Ubuntu to apply security updates and it is harder to review
debdiffs.

Thanks,
Jeremy Bicha

Bug#896013: developers-reference: Should include stable-proposed-updates / stable-updates distinction

[Sean Whitton]

Package: developers-reference
Version: 3.4.19
Severity: wishlist

A subset of packages in stable-proposed-updates are copied to the
stable-updates suite, per [1].

devref's discussion of uploading to stable-proposed-updates should
probably mention this, just because it can sometimes be confusing what
the difference is between these two suites, because their names are so
similar.

[1]  https://lists.debian.org/debian-devel-announce/2011/03/msg00010.html

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#896015: developers-reference: Changes to conventions for uploading to stable-proposed-updates

[Sean Whitton]

Package: developers-reference
Version: 3.4.19
Severity: normal

On Mon, Apr 16 2018, Adam D. Barratt wrote:

> Historically, the workflow for stable updates has been to file a bug against
> the release.debian.org pseudo-package and wait for confirmation from a member
> of the Release Team before proceeding with the upload. We're aware that the
> time before a response can sometimes be quite long and that, in any case,
> having to perform the upload at a later point can be inconvenient.
>
> We are therefore introducing a slight change to the process, which we hope 
> will
> benefit both you and us - if you are confident that the upload will be 
> accepted
> without changes, please feel free to upload at the same time as filing the
> release.debian.org bug. If you're unsure about the changes or would like
> further guidance or discussion, then simply wait for a response as now. Please
> continue to file the bug in any case, both for tracking purposes and a 
> location
> for discussion should any turn out to be required.

devref's discussion of uploading to stable-proposed-updates needs
updating for this change.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#895574: lintian: binary-compiled-with-profiling-enabled test fails on Ubuntu's armhf

[Chris Lamb]

[Replying to st...@eilval.com!]

Hey Sledge,

>>I suspect the underlying problem is that we are not detecting
>>profiling information on armhf correctly. The relevant code is:
>>
>>  
>> https://salsa.debian.org/lintian/lintian/blob/master/checks/binaries.pm#L192-207
>>
>>I have attached the "readelf -WltdVs" output of "basic.c" compiled
>>on the harris.debian.org porterbox.
>>
>>Whilst I see a "GLIBC_" section, I do see an mcount:
>>
>>117:  0 FUNCGLOBAL DEFAULT  UND __gnu_mcount_nc@@GLIBC_2.8
>>
>>Can someone with some ELF knowledge chime in here? :)
>
>I can have a look. So we're looking at the same thing, what's in "basic.c"?

Ooh, thanks! So this is basic.c:

  #include 
  #include 
  
  int
  main(int argc, char *argv[])
  {
  char t[10];
  printf("Hello world!\n");
  /* forces a stack protector */
  (void) strcpy(t,argv[0]);
  return (int) t[0];
  }

Or, canonically:

  
https://salsa.debian.org/lintian/lintian/blob/master/t/tests/binaries-general/debian/basic.c

Some of the C code might be to trigger other things, so I can't
vouch for it being a minimal testcase here alas.


Best wishes,

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

Bug#895969: webkit2gtk: FTBFS on riscv64 due to not linking against libatomic

[Karsten Merker]

On Wed, Apr 18, 2018 at 11:36:16AM +0200, Alberto Garcia wrote:
> On Wed, Apr 18, 2018 at 08:36:29AM +0200, Karsten Merker wrote:
> > Source: webkit2gtk
> > Version: 2.20.1-1
> > X-Debbugs-CC: debian-ri...@lists.debian.org
> > User: debian-ri...@lists.debian.org
> > Usertags: riscv64
> > 
> > Hello,
> > 
> > webkit2gtk 2.20.1-1 FTBFS on the riscv64 architecture with "undefined
> > reference to `__atomic_compare_exchange_1'". Full log at:
> 
> Is there any way that I can have access to / set up a riscv64 build
> environment in order to debug this problem?

Hello,

we don't yet have a "regular" porterbox for riscv64, but you can
run a local qemu-based riscv64 virtual machine.  A step-by-step
description of how to set it up is available in the Debian wiki
at

https://wiki.debian.org/RISC-V#Setting_up_a_riscv64_virtual_machine

If there should be any problems with the setup, feel free to ask
me.

> Or, do you have a working patch for this ?

Unfortunately not.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#895866: tomcat8: Errors thrown when connecting to default HTTP connector (localhost:8080)

[Michael Welsh Duggan]

Emmanuel Bourg  writes:

> Thank you for reporting this issue Michael. This issue happens because
> tomcat8/8.5.30-1 was built with OpenJDK 9 and can no longer run with
> OpenJDK 8 due to the use of new java.nio.ByteBuffer methods.If you
> switch to OpenJDK 9 to run Tomcat the issue should go away.
>
> I'll make tomcat8 runnable again with OpenJDK 8 in the next update.

Thanks.  This would be good, as a Debian system will use
/usr/lib/jre/default-java to run tomcat8 by default, and that symlink is
not one changed by the alternatives system.  As a result, this will not
run without changing JAVA_HOME in /etc/default/tomcat8.

-- 
Michael Welsh Duggan
(m...@md5i.com)

Bug#862883: Port from libnm-glib/libnm-util to libnm

[Pino Toscano]

In data mercoledì 18 aprile 2018 19:35:01 CEST, Michael Biebl ha scritto:
> Control: tags -1 + patch
> 
> I made some more minor tweaks to v2:
> 
> - Update debian/changelog
> - Drop debian/patches/add_glib_for_nm, no longer necessary
> 
> v3 of the debdiff is attached. I was told that it's probably not worth
> forwarding this upstream, as KDE4 development is pretty much dormant.

While the KDE 4 development is basically stopped, the code here was
basically copied into the compatibility framework kdelibs4support;
hence I'd prefer to see the resolution of #862877 (or at least upstream
feedback on the patch for it), so the same fix can be backported here
too.

> I plan to NMU kde-runtime in a week or so and upload to DELAYED/10
> unless I hear back from you. Please holler, if you have any objections.

See above.  Also, there are local changes in the packaging git, and
possibly I should land one/two more (although I have not worked on them
yet).

-- 
Pino Toscano

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

Bug#895452: libquadmath and quadmath.h do not exist on ppc64

[Dennis Clarke]

New GCC bigid is being flipped around by Jakub Jelinek ( Red Hat )
who claims this issue is fixed for ppc64 in GCC version 8 that
does not exist anywhere.  Not even in the git repo.

I am trying to figure out what is going on here.

see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686

see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440

What a mess .. seems like a new secret gcc codebase exists somewhere
and no one can see it.

Dennis

Bug#862877: Port from libnm-glib/libnm-util to libnm

[Pino Toscano]

In data mercoledì 18 aprile 2018 19:01:53 CEST, Michael Biebl ha scritto:
> Control: tags -1 + patch
> 
> Attached is a debdiff which is based on lubo's patch.
> 
> Changes to the initial patch
> - Use Q_SLOTS instead of slots, instead of simply commenting it out
> - Use nm-dbus-interface.h include instead of NetworkManager.h, so we
> don't pull in any glib/gio related headers
> - Drop NM_CHECK_VERSION define, no longer needed.
> 
> I've submitted the same patch upstream.

Do you have the link to the upstream submission? Note that these days
upstream uses phabricator [1] for patch reviews.

[1] https://phabricator.kde.org/

> I plan to NMU in a week or so and upload to DELAYED/10 unless I hear
> back from you.

I'd rather prefer to get first the feedback from upstream, so we can
possibly even just backport the upstream commit.

-- 
Pino Toscano

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