Bug#918525: r-base-core: library lapack.so shouldn't be linked to libopenblas.so.0

[Jörg-Volker Peetz]

Hallo Dirk,

the problem I see, shows when inspecting /usr/lib/R/modules/lapack.so with

$ ldd /usr/lib/R/modules/lapack.so | grep blas
libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 
(0x7f58c61b5000)
libopenblas.so.0 => /usr/lib/x86_64-linux-gnu/libopenblas.so.0 
(0x7f58c2dbb000)

Thus, lapack.so of package r-base-core is linked to libopenblas.so.0
which means that r-base-core won't work without package libopenblas-base.
And that is not intended AFAIU.

Regards und Grüße aus Bonn,
Jörg.

Bug#918532: emacs: Daemon mode does not apply font preferences

[ಚಿರಾಗ್ ನಟರಾಜ್]

Package: emacs
Version: 1:26.1+1-3
Severity: normal
Tags: l10n

Dear Maintainer,

Here are the steps to reproduce the problem:

1. Install fonts-knda so that all three available fonts are installed.
2. Note that, by default, emacs (at least my emacs) prefers to use Gubbi to 
render the font. This is an issue because specific characters are rendered 
badly (a bug in its own right, but not something I'm overly concerned with at 
the moment).
3. Try to fix this by inserting `(set-fontset-font "fontset-default" (cons 
(decode-char 'ucs #x0c80) (decode-char 'ucs #x0cff)) "Lohit Kannada")` in your 
.emacs file.
4. Run `emacs` and note that the font preference is (correctly) applied.
5. Run `emacs --daemon` and note that the font preference is not applied.
6. After starting the daemon, if I go to my .emacs and evaluate that line 
manually, the preference is applied.

This occurs with both emacs-lucid and emacs-gtk.

If there is some more debugging info I can provide, please let me know.

Sincerely,

Chiraag

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

Kernel: Linux 4.19.5-chiraag (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=kn_IN.UTF-8, LC_CTYPE=kn_IN.UTF-8 (charmap=UTF-8), 
LANGUAGE=kn_IN.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 emacs depends on:
ii  emacs-lucid  1:26.1+1-3

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#918247: closed by Kyle Robbertze (Bug#918247: fixed in camlimages 1:4.2.6-2)

[Kyle Robbertze]

On 2019/01/05 12:34, Adrian Bunk wrote:
> Control: reopen -1
> 
> Unfortunately the problem is still there:
> https://buildd.debian.org/status/package.php?p=camlimages=sid

Damn... I'll have to play around on a porter box then.

Cheers
Kyle



signature.asc
Description: OpenPGP digital signature

Bug#895316: node-once repo on salsa

[Paolo Greppi]

FYI, I have manually migrated the git repo of node-once from:
https://alioth-archive.debian.org/git/collab-maint/node-once.git.tar.xz
to:
https://salsa.debian.org/js-team/node-once

I skipped all repos on collab-maint during the mass migration in April last 
year:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2018-April/025850.html
because my paolog-guest account had no write access to those

Paolo

Bug#918449: kate freeze when right-click the open/save file dialog

[Joe Ma]

Bernhard Übelacker 於 2019/1/6 下午10:31 寫道:

Hello Joe Ma,
the provided information might not be sufficient for
the maintainer to solve the issue.

If possible you might install the gdb package and run
following, while kate is frozen:

gdb -q --pid $(pidof kate) -ex 'set pagination off' -ex 'set width 0' -ex 'thread 
apply all bt full' -ex 'info share' -ex detach -ex q  2>&1 | tee -a 
gdb-kate_$(date +%Y-%m-%d_%H-%M-%S).log

This should create a file gdb-kate*.log that you may
forward to this bug.

Even better would be if the debug symbols are installed,
e.g. for kate that would be kate-dbgsym.
That package would reside in its own repository described in [1].

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols


Dear Bernhard,

Here is the log after executing your command.

The whole screen (plasmashell) freeze after right-click in the open/save 
file dialog (KDE one).


Kind regard,
Joe
Attaching to process 2737
[New LWP 2738]
[New LWP 2739]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f6b8e6d1be9 in poll () from /lib/x86_64-linux-gnu/libc.so.6

Thread 3 (Thread 0x7f6b76c16700 (LWP 2739)):
#0  0x7f6b8e6d1be9 in poll () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x7f6b89d389f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#2  0x7f6b89d38b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#3  0x7f6b8ef7e04f in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#4  0x7f6b8ef279ca in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#5  0x7f6b8ed550f3 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#6  0x7f6b8f18f6d5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
No symbol table info available.
#7  0x7f6b8ed59da8 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#8  0x7f6b8bc75fa3 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#9  0x7f6b8e6dc89f in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.

Thread 2 (Thread 0x7f6b7e936700 (LWP 2738)):
#0  0x7f6b8e6d1be9 in poll () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x7f6b8be9e150 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
No symbol table info available.
#2  0x7f6b8be9fee9 in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
No symbol table info available.
#3  0x7f6b80c9cb69 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
No symbol table info available.
#4  0x7f6b8ed59da8 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#5  0x7f6b8bc75fa3 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#6  0x7f6b8e6dc89f in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.

Thread 1 (Thread 0x7f6b81057d80 (LWP 2737)):
#0  0x7f6b8e6d1be9 in poll () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x7f6b89d389f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#2  0x7f6b89d38b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#3  0x7f6b8ef7e04f in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#4  0x7f6b8ef279ca in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#5  0x7f6b8fed931d in QMenu::exec(QPoint const&, QAction*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#6  0x7f6b7d8456ff in KDirOperator::activatedMenu(KFileItem const&, QPoint const&) () from /usr/lib/x86_64-linux-gnu/libKF5KIOFileWidgets.so.5
No symbol table info available.
#7  0x7f6b7d840b75 in KDirOperator::Private::_k_openContextMenu(QPoint const&) () from /usr/lib/x86_64-linux-gnu/libKF5KIOFileWidgets.so.5
No symbol table info available.
#8  0x7f6b7d848914 in ?? () from /usr/lib/x86_64-linux-gnu/libKF5KIOFileWidgets.so.5
No symbol table info available.
#9  0x7f6b8ef555e9 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#10 0x7f6b8fd95d25 in QWidget::customContextMenuRequested(QPoint const&) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#11 0x7f6b8fdb0f10 in QWidget::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table 

Bug#901149: searx: unexpected crash: name 'basestring' is not defined

[Johannes Schauer]

Hi Helmut,

On Sat, 9 Jun 2018 15:16:40 +0200 Helmut Grohne  wrote:
> I got the error "unexpected crash: name 'basestring' is not defined" from the
> hoogle backend. I guess this is due to searx.utils.to_string using basestring
> without defining it. Regardless of whether that's the cause, the use of
> basestring in to_string is certainly a bug.

I don't know which code exactly threw that error but.

 - the hoogle backend is now provided by the json_engine engine which does not
   reference basestring at all

 - all other references to basestring in the codebase seem to be set as str.

Can you confirm that the issue is solved with the upload of the new upstream
release 0.15.0?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#918530: RFP: python-keyboardleds -- keyboard LEDs manipulation

[Jakub Wilk]

Package: wnpp
Severity: wishlist

* Package name: python-keyboardleds
  Version : 0.3.4
  Upstream Author : Jakub Wilk 
* URL : http://jwilk.net/software/python-keyboardleds
* License : Expat
  Programming Lang: Python
  Description : keyboard LEDs manipulation

With python-keyboardleds you can interact with your keyboard's LEDs 
(scroll lock, caps lock, num lock).


--
Jakub Wilk

Bug#918531: RFP: trx -- realtime audio over IP

[Jakub Wilk]

Package: wnpp
Severity: wishlist

* Package name: trx
  Version : 0.3
  Upstream Author : Mark Hills 
* URL : http://www.pogo.org.uk/~mark/trx/
* License : GPL
  Programming Lang: C
  Description : realtime audio over IP

trx is a simple toolset for broadcasting live audio from Linux. It sends 
and receives encoded audio over IP networks, via a soundcard or audio 
interface.


It can be used for point-to-point audio links or multicast, eg. private 
transmitter links for a radio station or other live audio distribution. 
In contrast to traditional streaming, high quality wideband audio (such 
as music) can be sent with low-latency, typically as low as a few 
milliseconds, and incredibly fast recovery from dropouts.


It works favourable as a replacement for traditional ISDN lines and 
hardware ISDN codecs.


Features include:

* Very simple to set up
* Low latency with fast recovery from dropouts
* Full control over latency and buffers
* Supports IPv4 and IPv6, including multicast

--
Jakub Wilk

Bug#910902: akonadi-backend-mysql: akonadi fails to start creating new database/config - ~/.local/share/akonadi/db_data/ not created

[Jonathan Rubenstein]

Package: akonadi-backend-mysql
Version: 4:18.08.1-1
Followup-For: Bug #910902

I was able to reproduce the issue as Ian described, exactly as he described
it.

I had just reinstalled Debian and switched to KDE as my new desktop
environment. I tried opening KMail bu tthe Akonadi service wasn't able to run.
Looking in journalctl, I saw the same errors that Ian had described. Running
`akonadictl start` from the terminal verified this, and gave me the same
errors.

I then followed Ian's workaround and created the db_data directory myself
using the command `mkdir ~/.local/share/akonadi/db_data` and tried running
Akonadi again from the command line, which worked without error. I rebooted to
make sure Akonadi was completely offline, then ran KMail again, which worked
fine.

After quitting KMail and shutting down Akonadi with `akonadictl stop`, I
renamed the db_data directory to 'db_data.test', and ran `akonadictl start`
again, which gave me the same errors as before. Restoring the name from
'db_data.test' back to 'db_data' again fixed the issue.



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

Kernel: Linux 4.19.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=C, LC_CTYPE=C.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

Versions of packages akonadi-backend-mysql depends on:
ii  default-mysql-client-core 1.0.4
ii  default-mysql-server-core 1.0.4
ii  libqt5sql5-mysql  5.11.3+dfsg-2
ii  mariadb-client-core-10.1 [virtual-mysql-client-core]  1:10.1.37-3
ii  mariadb-server-core-10.1 [virtual-mysql-server-core]  1:10.1.37-3

Versions of packages akonadi-backend-mysql recommends:
ii  akonadi-server  4:18.08.1-1+b2

akonadi-backend-mysql suggests no packages.

-- no debconf information

Bug#918522: No sound with PulseAudio when an NVidia GPU is installed - workaround

[Julien Aubin]

Workaround :

In /etc/pulse/default.pa uncomment the following line :
load-module module-alsa-sink

Then everything goes back fine.

Looks like there's something wrong with PA detection module.

Bug#666219: not handling nostrip build option, Hardening flags missing

[Niels Thykier]

Gürkan Myczko:
> Hi Niels,
> 
>> Thanks for providing an updated package. :)
>>
>> Are you (still?) interested in becoming the maintainer of bchunk?  If
>> so, please lets file an "Intend To Salvage" bug, so you can become the
>> proper maintainer of this package. :)
> 
> Is Intend to Salvage possible keeping the old maintainer? (as making a
> team of two(or more)), by
> just adding oneself to the package as I already did? Since I do use
> bchunk (both
> for converting bin/cue to iso, and ripping audio from bin/cue), I guess
> I can as well (co-)maintain it.
> 

We can keep them by simply not removing them from the package (but it
would be wise mention that we intend to keep them as Uploader/Maintainer
in the original ITS mail).

>> I am happy to sponsor your upload with some minor changes once we get
>> there.  Alternatively, if you are not interested in maintaining bchunk,
>> then I will simply do a one-off NMU bchunck based on your changes and
>> adding a few of my own on top. :)
> 
> So you can add yourself too :)
> 
> Best,
> 
>> Thanks,
>> ~Niels

I probably won't add myself as I do not use bchunk.  I am here because I
noted bchunk does not successfully cross-build but it has a trivial
patch for it.  That is my goal (plus add a "Rules-Requires-Root:
binary-targets" while we are add it).

However, if I can help you along the way with improving bchunk, then I
am happy to do that. :)

Thanks,
~Niels

Bug#918499: libreoffice: fails with 'ERROR 4 forking process'

[Rene Engelhard]

On Sun, Jan 06, 2019 at 08:21:36PM -0500, David Zelinsky wrote:
> > No, you didn't.
> 
> Yes, I did.  If you think something may have gone wrong with it, then
> you might tell me that.  But if you think I'm lying, you're wrong.

I just said you didn't do a upgrade _recently_ because, see
below - purely based on looking at your versions.

> And yet, when I do 'apt upgrade libreoffice' it tells me this is most
> recent version.

1:6.1.3-2? Impossible. Testing got 1:6.1.4-1 long ago, and now has
1:6.1.4-3.

See https://packages.qa.debian.org/libr/libreoffice.html

Similar with other old versions of yours.

Maybe out of date mirror?

> >> libreoffice worked fine, but now fails to start.  From the menu,
> >
> > My laptop is runnig testing, too and this worked and works.
> 
> OK.  Are you saying you're having trouble replicating my problem?

Yes. No problem at all for weeks.

> >> nothing happens.  From command line, it fails with the subject error:
> >> 
> >>   % libreoffice
> >
> > And this works fine.
> 
> Riffing on your first comment, if a package works for one person, that
> is not necessarily proof that it doesn't have a problem.  Again, I was

True, but given how long these versios are in testing as of now if it
was a general or a problem experienced often problem the report would
have come far sooner..

> I have no idea what this means.  I did not explictly put OpenJDK 8 "in
> the config".  As I said, I'm not a Debian developer, and I don't spend
> all my time looking at all the config files on my system (though I do
> look at a number of them).

OK, but LO uses Java at parts. (It looks for /usr/bin/java.

Here:

rene@frodo:~/.config/libreoffice$ grep -r java *
4/user/config/javasettings_Linux_X86_64.xml:http://openoffice.org/2004/java/framework/1.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
4/user/config/javasettings_Linux_X86_64.xml:
4/user/config/javasettings_Linux_X86_64.xml:file:///usr/lib/jvm/java-11-openjdk-amd64
4/user/config/javasettings_Linux_X86_64.xml:
4/user/config/javasettings_Linux_X86_64.xml:

But in my experience it notices default changes and updates the path...
Apparently not, apparently only when the old version is gone...

And your reportbug-generated info shows this shows you have 

ii  default-jre [java6-runtime] 2:1.10-67 

installed

default-jdk | 2:1.11-71 | testing| amd64, arm64, armel,
armhf, i386, mips, mips64el, mipsel, ppc64el, s390x

and this since November (ok, -70 since November).

So, please, do a upgrade. With a clean, current testing.

Then let's see further.

Regards,

Rene

Bug#666219: not handling nostrip build option, Hardening flags missing

[Gürkan Myczko]

Hi Niels,


Thanks for providing an updated package. :)

Are you (still?) interested in becoming the maintainer of bchunk?  If
so, please lets file an "Intend To Salvage" bug, so you can become the
proper maintainer of this package. :)


Is Intend to Salvage possible keeping the old maintainer? (as making a 
team of two(or more)), by
just adding oneself to the package as I already did? Since I do use 
bchunk (both

for converting bin/cue to iso, and ripping audio from bin/cue), I guess
I can as well (co-)maintain it.


I am happy to sponsor your upload with some minor changes once we get
there.  Alternatively, if you are not interested in maintaining bchunk,
then I will simply do a one-off NMU bchunck based on your changes and
adding a few of my own on top. :)


So you can add yourself too :)

Best,


Thanks,
~Niels

Bug#918522: No sound with PulseAudio when an NVidia GPU is installed

[Julien Aubin]

Hi again,

I tested with pavucontrol and the Intel HDA audio controller simply
does not appear.

Looks like I'm not the only one affected, see :
https://unix.stackexchange.com/questions/452079/no-sound-unless-root-in-debian-buster

@Debian NVIDIA Maintainers -> the issue might also come from the
NVidia driver (misconfiguration), although it did not occur in Stretch
w/ BPO 390.87-4 driver.

Bug#918079: pandas: FTBFS: B-D on python-nbsphinx which is no longer installable nor built any more

[Jerome BENOIT]

Hello, 

On 07/01/2019 00:24, Paul Gevers wrote:
> On Thu, 3 Jan 2019 02:39:12 + (UTC) Thorsten Glaser 
> wrote:
>> See #917418 for “python-nbsphinx (0.4.1+ds-1) is not installable”.
>>
>> src:nbsphinx (0.4.1+ds-3) now only builds the py3k package.
>>
>> python-nbsphinx (= 0.3.5+ds-1) is installable and usable, but no
>> longer in Debian, so please move to python3-nbsphinx instead.
> 
> Please don't forget to update your autopkgtest as well. It is currently
> blocking multiple migrations due to this as your test depends on
> pyton-nbsphinx as well.
> 
> Paul

I am considering to provide Python 2 support for nbsphinx again for Buster.
I am sorry for my mistake. Please give some time.

Jerome

> 
> 

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature

Bug#905831: Fails to build on armhf

[Wookey]

On 2018-08-10 12:39 +0200, Sjoerd Simons wrote:
> Package: ne10
> Version: 1.2.1-3
> Severity: serious
> Tags: patch
> Justification: fails to build from source
> 
> As per
> https://buildd.debian.org/status/fetch.php?pkg=ne10=armhf=1.2.1-3=1478897528=0
> the build of ne10 fails on armhf. This is because it detects the build
> environment as targetting aarch64. From the log:
>   -- Target architecture : aarch64
> 
> Attached is the debdiff from a derivative we hvae which fixes the issue.

Thanks for this. I've been meaning to fix this for ages.

However there is already a patch in the Makefile to fix this, which I
think is cleaner than making an exception for armhf. Clearly the catch
is that it's not actually working...

native-build.patch:
Index: ne10-1.2.1/GNUlinux_config.cmake
===
--- ne10-1.2.1.orig/GNUlinux_config.cmake
+++ ne10-1.2.1/GNUlinux_config.cmake
@@ -43,6 +43,10 @@ else()
set(NE10_LINUX_TARGET_ARCH $ENV{NE10_LINUX_TARGET_ARCH})
 endif()
 
+# debian DEB_TARGET_GNU_CPU calls this as 'arm', not 'armv7'
+if(NE10_LINUX_TARGET_ARCH STREQUAL "arm")
+   set (NE10_LINUX_TARGET_ARCH "armv7")
+
 if(NE10_LINUX_TARGET_ARCH STREQUAL "armv7")
set(CMAKE_C_COMPILER arm-linux-gnueabihf-gcc)
set(CMAKE_CXX_COMPILER arm-linux-gnueabihf-g++)


OK. turns out I needed to patch CMakelists.txt as well:
--- ne10-1.2.1.orig/CMakeLists.txt
+++ ne10-1.2.1/CMakeLists.txt
@@ -61,8 +61,9 @@ if(DEFINED NE10_ANDROID_TARGET_ARCH)
 endif()
 endif()

+#On debian this CPU arch is 'arm'
 if(DEFINED NE10_LINUX_TARGET_ARCH)
-if(${NE10_LINUX_TARGET_ARCH} STREQUAL "armv7")
+if(${NE10_LINUX_TARGET_ARCH} STREQUAL "arm")
 set(NE10_TARGET_ARCH "armv7")
 else()
 set(NE10_TARGET_ARCH "aarch64")


I've uploaded a fixed package (which also does a beter (more general)
job of setting up toolchains by just using ENV{DEB_BUILD_GNU_TYPE})

Thanks for the prod - this stayed broken for way too long...

---
> diff -Nru ne10-1.2.1/debian/rules ne10-1.2.1/debian/rules
> --- ne10-1.2.1/debian/rules   2016-10-12 19:35:53.0 +0200
> +++ ne10-1.2.1/debian/rules   2018-08-10 12:26:57.0 +0200
> @@ -13,12 +13,19 @@
>  # package maintainers to append LDFLAGS
>  #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
>  
> +ifeq ($(DEB_TARGET_GNU_CPU),arm)
> + NE10_LINUX_TARGET_ARCH = armv7
> +else
> + NE10_LINUX_TARGET_ARCH = ${DEB_TARGET_GNU_CPU}
> +endif
> +
>  %:
>   dh $@ 
>  
>  override_dh_auto_configure:
> + 
>   dh_auto_configure -- \
> - -DNE10_LINUX_TARGET_ARCH=$(DEB_TARGET_GNU_CPU) \
> + -DNE10_LINUX_TARGET_ARCH=$(NE10_LINUX_TARGET_ARCH) \
>   -DGNULINUX_PLATFORM=ON \
>   -DNE10_BUILD_SHARED=ON

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#909752: #909752 fixed in git but not uploaded

[Kunal Mehta]

control: tags -1 pending

Hi Ondřej,

It looks like you fixed this #909752 in git back in November[1], but it
was never uploaded to the archive. Is there anything blocking its upload?

[1]
https://salsa.debian.org/php-team/pecl/php-apcu-bc/commit/a4c7df39a4775cbf2988bb97bb07153ffbdb5f9e

Thanks,
-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#918384: dgit: typo suggestions in man pages

[Paul Hardy]

Ian,

On Sun, Jan 6, 2019 at 11:39 AM Ian Jackson
 wrote:
> ...
> As for the rest, I agree with Sean's comments.  Paul, would you care
> to respin the patch ?  I'm planning an upload soon today but I can
> wait a few hours if that would get thwse changes included.

I trust that after you sent this you saw an email I sent beforehand
mentioning that I would be unavailable today.  I hope you did not
delay your dgit upload on my account.  I was not aware of the poor
timing.

Did any of the man pages change in your version 8.3 upload from
version 8.1?  If not, that will simplify my creating the modified
patch.

All the best,


Paul Hardy

Bug#864644: dictionary-el: No font face support for default font

[Aaron M. Ucko]

"Aaron M. Ucko"  writes:

> buffer's appearance up to customization, but will defer to upstream on
> the actual default appearance.  To that end, I turned your patch into a
> formal GitHub pull request:

Upstream already accepted this patch, so I'll incorporate it in full as
well.  Thanks again for preparing it!

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

Bug#914568: emacs25: Please build with xwidget support

[Dato Simó]

> check-security-status also says webkit2gtk is unsupported. So unless I
> miss something, nothing has significantly changed with respect to
> xwidgets.

Okay, fair enough.

It would still be nice, though, to have an emacs-xwidgets package.

Unfortunately, it is not feasible to have it built in unstable 
from the ‘emacs’ source package, because it would have to migrate 
to testing; it's not possible to migrate a subset of binary 
packages.

Two options I can think of are:

  1. have a separate emacs-xwidgets _source_ package, confined to 
 unstable.

  2. ‘abuse’ the experimental suite, and re-upload there every 
 unstable version verbatim, with xwidgets support

 2.a: ... in a separate emacs-xwidgets package, OR
 2.b: ... in the main emacs package

(2.a) would need checking with ftpmaster, just to be sure they're 
okay; (2.b) is simpler but misleading (upgrading from experimental 
to a higher version in unstable will _lose_ you features). (1) is 
typically frowned upon.

Just to be clear, I can volunteer to make these uploads if needed. 
I'm rebuilding form myself anyway. 

Cheers,

-d

Bug#918529: openconnect: version 8.01 available upstream

[Daniel Kahn Gillmor]

Package: openconnect
Version: 7.08-3
Severity: wishlist

on the mailing list, i see that openconnect 8.01 is available
upstream.  it's also tagged in the upstream git repository.

please package the new version for debian!

   --dkg


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

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

Versions of packages openconnect depends on:
ii  libc62.28-2
ii  libgnutls30  3.6.5-2
ii  libopenconnect5  7.08-3
ii  libproxy1v5  0.4.15-5
ii  libxml2  2.9.4+dfsg1-7+b3
ii  vpnc-scripts 0.1~git20180227-1

openconnect recommends no packages.

openconnect suggests no packages.

-- no debconf information

Bug#864644: dictionary-el: No font face support for default font

[Aaron M. Ucko]

Ben Wong  writes:

> Since emacs can handle nice variable width fonts, it makes sense to
> have dictionary.el use them by default. While there is support for
> changing some of the font faces, such as the buttons at the top, the
> package is mysteriously missing the ability to change the font of the
> definition itself.

Thanks for the suggestion (complete with patch), and sorry for not
replying earlier!  I'm happy to open this aspect of the *Dictionary*
buffer's appearance up to customization, but will defer to upstream on
the actual default appearance.  To that end, I turned your patch into a
formal GitHub pull request:

https://github.com/myrkr/dictionary-el/pull/3

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

Bug#917055: blktool FTBFS with glibc 2.28

[Logan Rosen]

Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * Add patch to fix FTBFS with glibc-2.28.

Thanks for considering the patch.

Logan Rosen

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

Kernel: Linux 4.18.0-13-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru blktool-4/debian/control blktool-4/debian/control
--- blktool-4/debian/control2018-04-03 08:15:06.0 -0400
+++ blktool-4/debian/control2019-01-06 21:50:30.0 -0500
@@ -1,8 +1,7 @@
 Source: blktool
 Section: admin
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Azat Khuzhin 
+Maintainer: Azat Khuzhin 
 Build-Depends: cdbs, debhelper (>= 9), libglib2.0-dev
 Standards-Version: 3.9.6
 Homepage: http://sourceforge.net/projects/gkernel/files/blktool/
diff -Nru blktool-4/debian/patches/0004-fix-FTBFS-with-glibc-2.28.patch 
blktool-4/debian/patches/0004-fix-FTBFS-with-glibc-2.28.patch
--- blktool-4/debian/patches/0004-fix-FTBFS-with-glibc-2.28.patch   
1969-12-31 19:00:00.0 -0500
+++ blktool-4/debian/patches/0004-fix-FTBFS-with-glibc-2.28.patch   
2019-01-06 21:50:28.0 -0500
@@ -0,0 +1,13 @@
+--- a/blktool.c
 b/blktool.c
+@@ -22,6 +22,10 @@
+ #include 
+ #include 
+ 
++#ifdef __GNU_LIBRARY__
++#include 
++#endif
++
+ #include 
+ #include 
+ #include 
diff -Nru blktool-4/debian/patches/series blktool-4/debian/patches/series
--- blktool-4/debian/patches/series 2015-06-12 18:05:10.0 -0400
+++ blktool-4/debian/patches/series 2019-01-06 21:47:12.0 -0500
@@ -1,3 +1,4 @@
 0001-fix-typos-in-manpage.patch
 0002-fix-string-error.patch
 0003-Fix-3-d-argument-for-BLKROSET-it-must-be-const-int.patch
+0004-fix-FTBFS-with-glibc-2.28.patch

Bug#885346: clicking mailto link in chromium silently sends empty mail

[Ryan Tandy]

I am not sure this is neomutt's fault or chromium's. It looks like the 
root cause is xdg-open not respecting Terminal=true in neomutt.desktop. 
There is an existing bug about that:


https://bugs.freedesktop.org/show_bug.cgi?id=92514

Wrapping the neomutt command in a terminal emulator works as a 
workaround for this specific bug, but is a bad fix in general since it 
would create a second, redundant terminal if launched from anything 
other than xdg-open.


I thought mailto: links used to work for me in chromium... I am not sure 
if something changed (probably in chromium) or if I imagined that.


BTW the reproducer can be even shorter: just enter 
mailto:some...@example.com in the address bar.

Bug#871019: sshfs: Please update to 3.x

[Mo Zhou]

On Sun, Jan 06, 2019 at 07:56:11PM +0100, Fabio Pedretti wrote:
> I don't think a transition is needed, now that fuse and fuse3 are
> co-installable. The packages that can migrate to fuse3 could do, the others

Source of "co-installable"???
I just installed fuse3, then apt removed gnome-core and fuse. And if I'm
going to reverse it:

~ ❯❯❯ sudo apt install fuse
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
[...]
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  fuse3 sshfs sshfs-dbgsym
The following NEW packages will be installed:
  fuse
0 upgraded, 1 newly installed, 3 to remove and 2 not upgraded.
Need to get 0 B/72.0 kB of archives.
After this operation, 243 kB disk space will be freed.
Do you want to continue? [Y/n]



How are they "co-installable"???

Bug#918499: libreoffice: fails with 'ERROR 4 forking process'

[David Zelinsky]

First, I apologize for any way in which I might be misusing the
bug-reporting system.  Really I thought I was doing a service by
reporting this.  As an aside, if, as I hope, you want to encourage
people to use Debian and to report bugs, I would suggest you might want
to adopt a more more civil tone.

Rene Engelhard  writes:

> tag 918499 + moreinfo
> tag 918499 + unreproducible
> severity 918499 important
> thanks
>
> Hi,
>
> On Sun, Jan 06, 2019 at 01:46:09PM -0500, David Zelinsky wrote:
>> Package: libreoffice
>> Version: 1:6.1.3-2
>> Severity: grave
>> Justification: renders package unusable
>
> Sorry, but not every problem one person has is a *release-critical*
> bug in said package. Especially not if that testing is ooold.

That's a fair point.  But, not being very experienced with the debian
bug reporting system, this seemed like category whose description best
fit what I was observing.  The package was clearly unusable for me (in
the intended manner), and I had no way of telling how it behaves on
other systems.

>> I'm running "testing", and recently did a dist-upgrade.  Previously
>
> No, you didn't.

Yes, I did.  If you think something may have gone wrong with it, then
you might tell me that.  But if you think I'm lying, you're wrong.

About a week ago, I ran 'apt update; apt upgrade' (or maybe it was 'apt
dist-uprade', I'm not sure.)  There was in fact an error, after which a
ran with 'fix-broken' and everything seemed OK.

The fact is that before that upgrade, libreoffice worked.  After it, it
did not.  Your denial is not very helpful.

> ... If you did you wouldn't have a loads of obsolete versions of stuff
> installed. Like default-jre pointing to 10 whereas it is 11 since
> looong. And LibreOffice 1:6.1.3-2 already was obsoleted. (At least
> that is what you report it against and your reportbug-generated info
> shows).

And yet, when I do 'apt upgrade libreoffice' it tells me this is most
recent version.


>> libreoffice worked fine, but now fails to start.  From the menu,
>
> My laptop is runnig testing, too and this worked and works.

OK.  Are you saying you're having trouble replicating my problem?


>> nothing happens.  From command line, it fails with the subject error:
>> 
>>   % libreoffice
>
> And this works fine.

Riffing on your first comment, if a package works for one person, that
is not necessarily proof that it doesn't have a problem.  Again, I was
trying to be helpful in identifying a problem that others might
experience.


>> read(6, "/usr/lib/jvm/java-8-openjdk-amd6"..., 4096) = 221
>
> So you use OpenJDK 8 in the config? Then see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925

I have no idea what this means.  I did not explictly put OpenJDK 8 "in
the config".  As I said, I'm not a Debian developer, and I don't spend
all my time looking at all the config files on my system (though I do
look at a number of them).

I did look at the bug report you referenced, but I'm not sure what the
implications are for my situation.  If it explains my problem, feel free
to say so.

> But at this stage (oosplash) this shouldn't matter yet...

As you say.

-David

Bug#918528: Suggesting non-existent package emacs-common-non-dfsg

[積丹尼 Dan Jacobson]

Package: emacs-gtk
Version: 1:26.1+1-3

Versions of packages emacs-gtk suggests:
pn  emacs-common-non-dfsg  

Bug#896295: Tensorflow is missing

[M. Zhou]

Hi,

On Mon, Jan 07, 2019 at 12:24:29AM +0100, Petter Reinholdtsen wrote:
> Is TensorFlow different from libtensorflow, already in unstable:
 
 experimental
 
> libtensorflow-cc1.10 - Computation using data flow graphs for scalable 
> machine learning (C++)
> libtensorflow-dev - Computation using data flow graphs for scalable machine 
> learning (dev)
> libtensorflow-framework1.10 - Computation using data flow graphs for scalable 
> machine learning
> libtensorflow1.10 - Computation using data flow graphs for scalable machine 
> learning (C)
> 
> If not, perhaps keras should be adjusted to use it, and its

No.  Please don't build any package that depends on TF 1.X because it is
literally an incomplete WIP.  You can do that untill TF 2.X landed onto
experimental with a (yet anotehr) totally re-written build system.

> package description updated?  The tensorflow source package
> entered unstable 2018-11-22.
  
  experimental
 
> As for the problem with running keras in unstable, perhaps it is a
> good idea to extend the autopkgtest script to detect such problems early?

Without autopkgtest I'm already aware of bunch of issues existing in the
present tensorflow package, which renders it inappropriate to enter even
unstable.

Bug#918527: Conflicting defaults on man page

[積丹尼 Dan Jacobson]

Package: procmail
Version: 3.22-26
Severity: minor
File: /usr/share/man/man5/procmailrc.5.gz

Maybe change

   hFeed the header to the pipe, file or mail destination (default).

   bFeed the body to the pipe, file or mail destination (default).

to

   hFeed just the header to the pipe, file or mail destination (default 
is hb).

   bFeed just the body to the pipe, file or mail destination (default 
is hb).

if indeed the case. Thank you.

Bug#867504: beanbag FTBFS with python 3.6 as supported version

[Logan Rosen]

Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * Grab PR from upstream Git to fix Python 3.6 compatibility, fixing FTBFS.

Thanks for considering the patch.

Logan Rosen

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

Kernel: Linux 4.18.0-13-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru beanbag-1.9.2/debian/patches/python-3.6-compat 
beanbag-1.9.2/debian/patches/python-3.6-compat
--- beanbag-1.9.2/debian/patches/python-3.6-compat  1969-12-31 
19:00:00.0 -0500
+++ beanbag-1.9.2/debian/patches/python-3.6-compat  2019-01-06 
21:03:30.0 -0500
@@ -0,0 +1,27 @@
+Description: Fix failing unit tests with Python 3.6+
+Author: Charalampos Stratakis 
+Bug: https://github.com/ajtowns/beanbag/pull/10
+Last-Update: 2019-01-06
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/beanbag/namespace.py
 b/beanbag/namespace.py
+@@ -102,6 +102,9 @@
+ basebases = (NamespaceBase,)
+ 
+ qn = None
++
++classcell = nmspc.pop('__classcell__', None)
++
+ if "__qualname__" in nmspc:
+ qn = nmspc["__qualname__"]
+ nmspc["__qualname__"] = qn + "Base"
+@@ -114,6 +117,8 @@
+ conv_nmspc["__module__"] = nmspc["__module__"]
+ if qn is not None:
+ conv_nmspc["__qualname__"] = qn
++if classcell is not None:
++conv_nmspc['__classcell__'] = classcell
+ 
+ cls = type.__new__(mcls, name, bases, conv_nmspc)
+ basecls.Namespace = cls
diff -Nru beanbag-1.9.2/debian/patches/series 
beanbag-1.9.2/debian/patches/series
--- beanbag-1.9.2/debian/patches/series 2017-03-09 07:17:47.0 -0500
+++ beanbag-1.9.2/debian/patches/series 2019-01-06 13:12:42.0 -0500
@@ -1 +1,2 @@
 fix-code-in-example-file
+python-3.6-compat

Bug#909828: actiona FTBFS with Qt 5.11

[Logan Rosen]

Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * Grab patch from upstream to fix FTBFS with Qt 5.11.
  * debian/docs: Change README to README.md.

Thanks for considering the patch.

Logan Rosen

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

Kernel: Linux 4.18.0-13-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru actiona-3.9.4/debian/docs actiona-3.9.4/debian/docs
--- actiona-3.9.4/debian/docs   2018-06-14 08:44:41.0 -0400
+++ actiona-3.9.4/debian/docs   2019-01-06 13:01:52.0 -0500
@@ -1 +1 @@
-README
+README.md
diff -Nru actiona-3.9.4/debian/patches/fix-ftbfs-qt-5.11.patch 
actiona-3.9.4/debian/patches/fix-ftbfs-qt-5.11.patch
--- actiona-3.9.4/debian/patches/fix-ftbfs-qt-5.11.patch1969-12-31 
19:00:00.0 -0500
+++ actiona-3.9.4/debian/patches/fix-ftbfs-qt-5.11.patch2019-01-06 
13:01:52.0 -0500
@@ -0,0 +1,32 @@
+Description: Fix compilation with Qt 5.11
+Author: Jmgr 
+Origin: upstream
+Bug: https://github.com/Jmgr/actiona/issues/78
+Applied-Upstream: 
https://github.com/Jmgr/actiona/commit/26437ea8e0ce7ff957e500b0cc0ec3d655d5c3c5
+Last-Update: 2019-01-06
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+diff --git a/actiontools/abstractcodeeditor.h 
b/actiontools/abstractcodeeditor.h
+index 0b9737e7..690a118a 100644
+--- a/actiontools/abstractcodeeditor.h
 b/actiontools/abstractcodeeditor.h
+@@ -24,6 +24,7 @@
+ #include "actiontools_global.h"
+ 
+ #include 
++#include 
+ 
+ class QAbstractItemModel;
+ 
+diff --git a/actiontools/coloredit.cpp b/actiontools/coloredit.cpp
+index e961885e..9f0d5824 100644
+--- a/actiontools/coloredit.cpp
 b/actiontools/coloredit.cpp
+@@ -23,6 +23,7 @@
+ 
+ #include 
+ #include 
++#include 
+ 
+ #if (QT_VERSION >= QT_VERSION_CHECK(5, 0, 0))
+ #include 
diff -Nru actiona-3.9.4/debian/patches/series 
actiona-3.9.4/debian/patches/series
--- actiona-3.9.4/debian/patches/series 2018-06-14 08:44:41.0 -0400
+++ actiona-3.9.4/debian/patches/series 2019-01-06 13:01:47.0 -0500
@@ -0,0 +1 @@
+fix-ftbfs-qt-5.11.patch

Bug#918340: pylint-django build depends on python3-factory-boy that is currently not in buster

[Joseph Herlant]

FYI, the new version of factory-boy is on the ftp-master queue. This
will solve itself in the next few days.
I'll close it once the package reaches testing.

Cheers,
Joseph

Bug#776450: Xen PVH support for grub-xen in Buster

[Hans van Kranenburg]

On 1/6/19 11:21 AM, Colin Watson wrote:
> On Sat, Jan 05, 2019 at 10:51:13PM +0100, Hans van Kranenburg wrote:
>> On 1/5/19 8:04 PM, Colin Watson wrote:
>>> I think I'm OK with cherry-picking the relevant patch stack.  Presumably
>>> this would need to be in new grub-xen-pvh-bin / grub-xen-pvh binary
>>> packages, as is usual for separate platform builds?
>>
>> I was thinking about having an additional...
>>
>> /usr/lib/grub-xen/grub-i386-xen_pvh.bin
>>
>> ...in the grub-xen-host package, built with the same config file
>> (debian/grub-xen-host_grub.cfg in the packaging) and then...
>>
>> /usr/lib/grub/i386-xen_pvh/*.mod
>>
>> ...in grub-xen-bin, just as an additional third option besides i386-xen
>> and x86_64-xen? This would be the most convenient "upgrade path". If you
>> want to switch to PVH, just change kernel line in the xen guest config
>> file, and set type='pvh'.
> 
> Ah yes, I'd forgotten that i386-xen and x86_64-xen were both in
> grub-xen-bin.  I agree it seems reasonable enough to combine them, which
> simplifies things, and given that the boot loader (at least the first
> stage - see below) is read from the dom0 filesystem, it makes sense to
> include an image in grub-xen-host, although we may or may not be able to
> use the exact same config file.

For the test I just did, I just reused the same config files, as you can
see. I don't know if the first half of it makes sense, with the
@@PVBOOT_ARCH@@ things, but I'm going to leave that alone for now, after
reading your comments below.

>>> Can you elaborate on what you mean by "use as kernel image for the Xen
>>> PVH virtual machine"?  In other words, what does the process of
>>> installing a boot loader in a PVH guest look like?
>>
>> You don't. There is no BIOS, no boot loader, it is like booting a PV
>> guest with grub. The whole 'trick' about PVH is that it's HVM, but then
>> without the qemu etc part.
>>
>> https://wiki.xen.org/wiki/Virtualization_Spectrum#Almost_fully_PV:_PVH_mode
>>
>> So, if I have this grub.cfg... (as example, not what we want for the
>> package)
> [...]
> 
> Thanks for clarifying all that.

Yes. So if the i386-xen_pvh stuff could be shipped in the same packages
(grub-xen-host) that users already have installed, then the user will
end up with a situation (without realizing) when upgrading a dom0 to
Buster (with Xen 4.11), in which the only thing (tm) that is needed to
do to convert a domU from PV to PVH is changing the kernel line in the
guest config file to the new grub-i386-xen_pvh.bin and adding a
type='pvh' line.

Well, for now that means that the only domU for which this will work is
one that has the debian buster 4.19 kernel, or the stretch-backports one
of course, but the future has to start somewhere. :)

>> So this is what I'm used to [0], but the way in which the Debian
>> grub-xen packages work is a bit different of course, since it tries to
>> do most of the process inside the virtual machine, and has a very
>> generic config file that delegates as much as possible to additional
>> grub config with access to modules inside the virtual machine itself.
> [...]
>>> (Compare
>>> https://salsa.debian.org/grub-team/grub/blob/master/debian/patches/grub-install-pvxen-paths.patch
>>> which we carry for PV guests, although I gather PVH is sufficiently
>>> different that the same approach probably doesn't work.)
>>
>> Hm, I have never seen this /boot/xen/pvboot-*.elf stuff before, and I
>> also don't see any of those files in the grub-xen-* packages?
> 
> Anything in /boot is copied/generated by grub-install rather than being
> shipped in the packages themselves.

Yes, I see now.

> Let me give some background here.  The Xen PV boot protocol was the
> result of a series of discussions between me, Ian Jackson (Xen), Ian
> Campbell (Xen), Vladimir Serbinenko (GRUB), and possibly a few others
> I've forgotten, and I don't recall to what extent we ever wrote down the
> entire rationale in one place.  In fact
> https://wiki.xen.org/wiki/PvGrub2 seems to have most of it now that I
> look, but I'll try to summarise it all here.
> 
> [...]

Thanks a lot for the explanation again, that really helps.

> Of course it was also possible to use pvgrub with the sort of scheme you
> describe, where the host declares how the guest kernel should boot.
> This works well enough in a small environment where there's a
> substantial amount of cooperation between the people running the host
> and the people running the guests, or where all the guests are
> sufficiently similar.  But it's not great for a larger or more generic
> environment, and we didn't want to rely on that degree of cooperation.
> (However, if you're operating a Xen host and that approach works for
> you, by all means go for it!  I understand that there exist environments
> where that approach is more convenient.)

Yup, that applies to our case at Mendix. We have roughly 7k domUs in
total (almost 15TiB of physical ram) running customer production
environments 

Bug#918481: gnuradio: FTBFS on hurd-i386

[Samuel Thibault]

Control: reopen -1
Control: found -1 3.7.13.4-3

Hello,

>  gnuradio (3.7.13.4-3) unstable; urgency=medium
>  .
>* improve hurd-i386 build. Thanks Samuel! (Closes: #918481)

Well, this upload was missing the python-pyqt5 Build-Depends part of my
patch?  And thus still FTBFS.  I have added it again in the attached
patch.  I have also fixed the runtime Depends of gnuradio, now that zmq
support is enabled.

Samuel
--- debian/control.original 2019-01-07 01:06:04.155255998 +0100
+++ debian/control  2019-01-07 01:06:17.305287936 +0100
@@ -45,7 +45,7 @@
python-lxml,
python-numpy,
python-opengl,
-  python-pyqt5 [!hurd-i386],
+  python-pyqt5,
python-scipy,
python-sphinx,
python-wxgtk3.0,
@@ -72,7 +72,7 @@
 python-pyqt5,
  python-sip,
  python-wxgtk3.0,
- python-zmq [!hurd-i386],
+ python-zmq,
  ${misc:Depends},
  ${python:Depends},
  ${shlibs:Depends}

Bug#918410: [qtcreator] qtcreator freezes during startup

[Bernhard Übelacker]

Hello Johannes,
thanks for your fast respone.

Can you repeat that gdb command with following additional
dbgsym packages installed, to complete the backtraces:

libxcb1-dbgsym libqt5gui5-dbgsym libqt5widgets5-dbgsym libqt5gui5-dbgsym 
libqt5dbus5-dbgsym libqt5core5a-dbgsym libglib2.0-0-dbgsym 
libgl1-mesa-dri-dbgsym libqt5qml5-dbgsym

As an distant observer I cannot say if the "clang code model"
thing deserves its own separate bug, has to be better decided by
the package maintainers...

If it shows up just sometimes you probably can describe your
cpu and number of cores?
Is it hanging too, if you start qtcreator with following command:

taskset -c 0 qtcreator

Kind regards,
Bernhard




signature.asc
Description: OpenPGP digital signature

Bug#833116: fgetty: Incorrect keystroke interpretation

[Ricardo Peliquero]

Your patch below works perfectly well. Again, I have implemented it with
and without my custom .rcrc and everything will work just as expected.

Thank you very much. I've learned a lot with this.

Kindest regards,

Ricardo Peliquero


> From 200b7d217ee3ac54b376116e7d64ce0844ecbed9 Mon Sep 17 00:00:00 2001
> From: Dmitry Bogatov 
> Date: Tue, 1 Jan 2019 22:52:18 +
> Subject: [PATCH] Fix #833116
> 
> ---
>  login2.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/login2.c b/login2.c
> index 8aaf6d6..156105b 100644
> --- a/login2.c
> +++ b/login2.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -61,6 +62,8 @@ main(int argc,char *argv[]) {
>char *shell=getenv("SHELL");
>char *Argv[]={"-sh",0};
>char *login=getenv("USER");
> +
> +  setenv("LANG", "C.UTF-8", 1);
>if (getuid()==0) { /* checkpassword honored "nosetuid" */
>  char *tmp=getenv("UID");
>  char *tty=getenv("TTY");
> 
> 

Bug#776450: Xen PVH support for grub-xen in Buster

[Colin Watson]

On Mon, Jan 07, 2019 at 12:43:12AM +0100, Hans van Kranenburg wrote:
> So, if I go to my upstream build directory and follow the same recipe:
> 
> -$ mkdir -p grub_dir/boot/grub
> -$ sed -e "s/@@PVBOOT_ARCH@@/i386-xen_pvh/" <
> ~/path/to/debian/grub/packaging/debian/grub-xen-host_grub.cfg >
> grub_dir/grub.cfg
> -$ tar -cf - -C grub_dir grub.cfg > grub_memdisk
> -$ ./grub-mkimage -O i386-xen_pvh -c
> ~/build/grub/grub/debian/grub-xen-host_grub-bootstrap.cfg -d
> ./grub-core/ ./grub-core/*.mod -m grub_memdisk -o grub-i386-xen_pvh.bin
> 
> Now I scp this grub-i386-xen_pvh.bin to my Xen dom0 and use it in the
> guest config:
> 
>  >8 
> kernel = "/root/grub-i386-xen_pvh.bin"
> type = "pvh"
>  >8 
> 
> Now I start with xl create -c and voila, a blue grub menu, a countdown
> of 5 seconds and the whole thing starts correctly!

Excellent!  Thanks for the test.

> I've been looking at the modules in the domU and even had copied
> everything into /boot/grub/i386-xen_pvh manually, but it seems this is
> not used at all. It also works if I remove all of that again. So I'm
> still wondering what that's for.

The modules in the domU are used if you use the two-stage system, but
you aren't doing that at this point.  It's also possible for them to be
used in a less reliable way in the one-stage system if your grub.cfg
involves (explicitly or implicitly) loading modules that aren't in the
core image that was created by grub-mkimage.  There are certainly
possible setups that wouldn't use modules from the domU.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#878340: libmariadbclient-dev-compat: mysqlclient.pc is not visible to pkg-config

[Nikolay Dimitrov]

Hi Otto, Helmut,

Thanks for fixing the bug and sharing the progress with me.

To be honest, I could have sent a patch for this issue even back then,
but I'm not familiar with Debian's contributors' policy and procedures,
and decided to not experiment with it (if it takes months for
experienced Debian developers to push patches through the system, there
aren't any high hopes for external contributors like me).

Thank you for making Debian a great distibution. Happy New Year!

Kind regards,
Nikolay Dimitrov
(A happy Debian user since 2003)


On 1/6/19 8:01 PM, Otto Kekäläinen wrote:

Hello Nikolay!

Thanks for submitting the bug report below in late 2017. Sorry that I
did not respond to it this year and apparently nobody else responded
to it last year either.
It should be fixed now in
https://salsa.debian.org/mariadb-team/mariadb-10.3/commits/bugfix/878340-mysqlclient.pc-path

One problem we have with the MariaDB package in Debian (and also in
upstream mariadb.org repos) is that there hasn't been any automated or
complete testing system for compiling software using the MariaDB libs.
I have now built something simple in
https://salsa.debian.org/mariadb-team/mariadb-10.3/blob/master/debian/gitlab-ci.yml#L200-234

I would appreciate very much if you would like to contribute to
MariaDB in Debian and extend that test code so that it would actually
build/compile a small sample program first using the libmysqlclient
libs and then re-doing it with the MariaDB equivalent installed.

I prefer contributions as merge requests on Debian's new Gitlab
instance called Salsa:
https://wiki.debian.org/Teams/MySQL/patches

Maintaining MariaDB in Debian is a very big task and I appreciate all
help I get that decreases my workload. Thanks for your previous
contributions and hopefully you can continue contributing!





pe 13. lokak. 2017 klo 1.48 Nikolay Dimitrov
(nikolay.dimit...@retrohub.org) kirjoitti:


Package: libmariadbclient-dev-compat
Version: 10.1.26-0+deb9u1
Severity: important

Dear Maintainer,

I'm trying to compile a software that requires a mysql client library. CMake
is unable to detect that libmariadbclient-dev-compat package is installed on my
system, and running pkg-config against the package shows an error:

$ pkg-config --cflags mysqlclient
Package mysqlclient was not found in the pkg-config search path.
Perhaps you should add the directory containing `mysqlclient.pc'
to the PKG_CONFIG_PATH environment variable
No package 'mysqlclient' found

It seems to me that libmariadbclient-dev-compat package installs mysqlclient.pc
at /usr/lib/x86_64-linux-gnu/, while pkg-config looks for .pc files at /usr/lib/
x86_64-linux-gnu/pkgconfig.

When I create a symlink mysqlclient.pc -> mariadb.pc located in /usr/lib/
x86_64-linux-gnu/pkgconfig, pkg-config is now able to detect the package:

$ pkg-config --cflags mysqlclient
-I/usr/include/mysql -I/usr/include/mysql/..

Can you please double-check whether mysqlclient.pc is installed at the proper 
path?

Kind regards,
Nikolay Dimitrov


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

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

Versions of packages libmariadbclient-dev-compat depends on:
ii  libmariadbclient-dev  10.1.26-0+deb9u1

libmariadbclient-dev-compat recommends no packages.

libmariadbclient-dev-compat suggests no packages.

-- no debconf information




--
Otto Kekäläinen
CEO
Seravo
+358 44 566 2204

Follow me at @ottokekalainen

Bug#776450: Xen PVH support for grub-xen in Buster

[Hans van Kranenburg]

On 1/6/19 11:28 AM, Colin Watson wrote:
> On Sun, Jan 06, 2019 at 01:45:53AM +0100, Hans van Kranenburg wrote:
>> Hm, so I have a PV (or PVH) domU in a test environment here, and I tried
>> to use it in the Debian way of booting it.
>>
>> If I install grub-xen-bin inside the domU then I get some stuff, but not
>> update-grub. When I just also install grub2 it drags in more stuff, and
>> then I end up with update-grub and a /boot/grub/grub.cfg file as result.
> 
> For the record, you wanted grub-xen rather than grub-xen-bin.

Yes, indeed, you're right.

>> I just copied *.mod that I got from my grub build (with the make blah
>> shown before) into /usr/lib/grub/i386-xen_pvh of the domU,
> 
> I'd expect them to need to be in /boot/grub/i386-xen_pvh/ in order for
> the boot loader to read them; grub-install copies modules there.
> (However, a standalone image normally shouldn't need to read modules
> from the guest anyway.)
> 
>> When trying to start that, I get:
>>
>> Reading (memdisk)/boot/grub/grub.cfg
>>
>> and then it exits back to the dom0 prompt and the domU is gone.
> 
> Seeing (memdisk) there suggests that $root is wrong.  I think that
> putting your bootstrap configuration file in /boot/grub/grub.cfg in the
> memdisk is a recipe for confusion; grub-xen-host puts it in /grub.cfg
> instead, and generally hooks things up a bit differently.  You can
> inspect debian/rules to see what it does.

Ok, I've read your explanation in the other email, I reread the xen wiki
page, and now is probably the moment to go back to where I started,
reading debian/rules, and see if I understand it a bit better now.

So, if I go to my upstream build directory and follow the same recipe:

-$ mkdir -p grub_dir/boot/grub
-$ sed -e "s/@@PVBOOT_ARCH@@/i386-xen_pvh/" <
~/path/to/debian/grub/packaging/debian/grub-xen-host_grub.cfg >
grub_dir/grub.cfg
-$ tar -cf - -C grub_dir grub.cfg > grub_memdisk
-$ ./grub-mkimage -O i386-xen_pvh -c
~/build/grub/grub/debian/grub-xen-host_grub-bootstrap.cfg -d
./grub-core/ ./grub-core/*.mod -m grub_memdisk -o grub-i386-xen_pvh.bin

Now I scp this grub-i386-xen_pvh.bin to my Xen dom0 and use it in the
guest config:

 >8 
kernel = "/root/grub-i386-xen_pvh.bin"
type = "pvh"
 >8 

Now I start with xl create -c and voila, a blue grub menu, a countdown
of 5 seconds and the whole thing starts correctly!

To confirm:

-# dmesg |grep PVH
[0.192293] Booting paravirtualized kernel on Xen PVH

I've been looking at the modules in the domU and even had copied
everything into /boot/grub/i386-xen_pvh manually, but it seems this is
not used at all. It also works if I remove all of that again. So I'm
still wondering what that's for. Maybe the amount of information and
different scenarios and routes that can be chosen is a little bit too
much for me to all grasp at once.

> Anyway, this sounds close enough that we can probably go for it and see
> where it lands :-)

Well, proof of concept (tm) is a great success already.

Hans

Bug#918526: mtail: FTBFS randomly

[Santiago Vila]

Package: src:mtail
Version: 3.0.0~rc16-1
Severity: important
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-arch
dh build-arch --buildsystem=golang --with=golang 
--builddirectory=/<>/build
   dh_update_autotools_config -a -O--buildsystem=golang 
-O--builddirectory=/<>/mtail-3.0.0\~rc16/build
   dh_autoreconf -a -O--buildsystem=golang 
-O--builddirectory=/<>/mtail-3.0.0\~rc16/build
   dh_auto_configure -a -O--buildsystem=golang 
-O--builddirectory=/<>/mtail-3.0.0\~rc16/build
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build -- -ldflags " -X main.Version=3.0.0~rc16 -X 
main.Revision=3.0.0~rc16-1"
cd build && go generate -v -ldflags " -X main.Version=3.0.0~rc16 -X 
main.Revision=3.0.0~rc16-1" github.com/google/mtail 
github.com/google/mtail/exporter github.com/google/mtail/logline 
github.com/google/mtail/metrics github.com/google/mtail/metrics/datum 
github.com/google/mtail/mtail github.com/google/mtail/tailer 
github.com/google/mtail/tailer/file github.com/google/mtail/testutil 
github.com/google/mtail/vm github.com/google/mtail/watcher
src/github.com/google/mtail/bench_test.go
src/github.com/google/mtail/ex_test.go
src/github.com/google/mtail/main.go
src/github.com/google/mtail/exporter/collectd.go
src/github.com/google/mtail/exporter/export.go

[... snipped ...]

--- PASS: TestInstrs/cmp_ge (0.00s)
--- PASS: TestInstrs/cmp_eq_string_string_true (0.00s)
--- PASS: TestInstrs/cmp_eq_string_string_false (0.00s)
--- PASS: TestInstrs/cmp_gt_int_float (0.00s)
--- PASS: TestInstrs/cmp_gt_float_float (0.00s)
--- PASS: TestInstrs/cmp_gt (0.00s)
--- PASS: TestInstrs/cmp_gt_float_int (0.00s)
--- PASS: TestInstrs/cmp_ne (0.00s)
--- PASS: TestInstrs/cmp_le (0.00s)
--- PASS: TestInstrs/cmp_eq (0.00s)
--- PASS: TestInstrs/cmp_lt (0.00s)
=== RUN   TestDatumSetInstrs
--- PASS: TestDatumSetInstrs (0.00s)
=== RUN   TestStrptimeWithTimezone
--- PASS: TestStrptimeWithTimezone (0.00s)
=== RUN   TestStrptimeWithoutTimezone
--- PASS: TestStrptimeWithoutTimezone (0.00s)
=== RUN   TestDatumFetchInstrs
--- PASS: TestDatumFetchInstrs (0.00s)
=== RUN   TestWalkPanicsOnUnknown
--- PASS: TestWalkPanicsOnUnknown (0.00s)
PASS
ok  github.com/google/mtail/vm  0.098s
=== RUN   TestFakeWatcher
--- PASS: TestFakeWatcher (0.00s)
=== RUN   TestFakeWatcherUnwatchedFiles
--- PASS: TestFakeWatcherUnwatchedFiles (0.00s)
=== RUN   TestNoSuchHandle
--- PASS: TestNoSuchHandle (0.00s)
=== RUN   TestLogWatcher
--- PASS: TestLogWatcher (0.00s)
=== RUN   TestNewLogWatcherError
--- PASS: TestNewLogWatcherError (0.00s)
=== RUN   TestLogWatcherAddError
--- PASS: TestLogWatcherAddError (0.00s)
=== RUN   TestLogWatcherAddWhilePermissionDenied
--- PASS: TestLogWatcherAddWhilePermissionDenied (0.00s)
=== RUN   TestWatcherErrors
E1208 18:50:34.156489   32599 log_watcher.go:85] fsnotify error: Injected error 
for test
--- PASS: TestWatcherErrors (0.00s)
PASS
ok  github.com/google/mtail/watcher 0.013s
dh_auto_test: cd build && go test -vet=off -v -p 2 github.com/google/mtail 
github.com/google/mtail/exporter github.com/google/mtail/logline 
github.com/google/mtail/metrics github.com/google/mtail/metrics/datum 
github.com/google/mtail/mtail github.com/google/mtail/tailer 
github.com/google/mtail/tailer/file github.com/google/mtail/testutil 
github.com/google/mtail/vm github.com/google/mtail/watcher returned exit code 1
make[1]: *** [debian/rules:25: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:18: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


This is just how the build ends and not necessarily the most relevant part,
so I've put a bunch of my build logs here:

https://people.debian.org/~sanvila/build-logs/mtail/

The test which usually fails for me is this one:

FAILgithub.com/google/mtail/tailer  0.018s

This does not seem to fail in reproducible-builds, but I found a build
failure here for mips64el, which is a release architecture:

https://buildd.debian.org/status/fetch.php?pkg=mtail=mips64el=3.0.0%7Erc16-1=1539028587=0

The fact that I can reproduce this as well on amd64 suggests that this not 
arch-specific
but instead some sort of race condition.

If you need a test machine to reproduce this, please say so (contact me 
privately for details).

Thanks.

Bug#918379: please decide: severity of "fails to purge" issues

[Andreas Beckmann]

>   h01ger: what does 'fails to purge' mean? the purge fails (gives
>  errors) or the purge 'succeeds', but files are left?

The failures intended to be raised to serious are all the cases where
maintainer scripts will fail - ususally in some corner cases depending
on (worst-case but dependency-wise valid) ordering of removal and purge
of the involved packages.
All known bugs of this kind (as of Dec.) are filed. New ones will either
be regressions or be newly introduced with new packages. The piuparts
failures of these already block migration, so filing the corresponding
bugs as serious seems to be justified.
In the old times, there were many packages using e.g. ucf incorrectly,
and would have caused a lot of RC bugs, but these have been fixed over
the years.

Leaving files around after purge is a separate that will continue to be
filed as important.


Andreas

Bug#918525: r-base-core: library lapack.so shouldn't be linked to libopenblas.so.0

[Dirk Eddelbuettel]

Hallo Jörg-Volker,

On 7 January 2019 at 00:09, Jörg-Volker Peetz wrote:
| Package: r-base-core
| Version: 3.5.2-1
| Severity: important
| 
| Hi Dirk,
| 
| the library /usr/lib/R/modules/lapack.so contained in this package is
| linked to /usr/lib/x86_64-linux-gnu/libopenblas.so.0 of the package
| libopenblas-base.  Package libopenblas-base provides the dependency
| libblas.so.3. The library libblas.so.3 contained in package
| libopenblas-base is already linked to libopenblas.so.0. Therefore, it is
| not necessary lo link it to /usr/lib/R/modules/lapack.so, I
| think. Rather, it is a bug to link it to /usr/lib/R/modules/lapack.so,
| since other packages providing a BLAS library don't contain or provide
| libopenblas.so.0.

I am little confused what your bug report is. Maybe you are confused too?

For 15 or 20 years Debian has had /virtual/ packages for BLAS and LAPACK.
r-base-core has a Depends: with

   Depends: zip, [...], libblas3 | libblas.so.3, [...], liblapack3 | 
liblapack.so.3

Here the libblas3 and liblapack3 three are the baseline fallback packages,
libblas.so.3 and liblapack.so.3 are the virtual package:

  edd@rob:~$ wajig show libblas.so.3   # wajig is a wrapper around 
dpkg+apt*
  No candidate version found for libblas.so.3
  Package: libblas.so.3
  State: not a real package
  Provided by: libatlas3-base (3.10.3-7build1), libblas3 (3.8.0-1build1), 
libopenblas-base (0.3.3+ds-1)
  edd@rob:~$ 

So if you installed, say, the atlas rather than openblas package and then did
ldd on R's lapack.so, another BLAS would appear.

We had this as a plug and play for a long time, and it works.  I see no bug 
here.


Tsch"uss aus Chicago,  Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#896295: Tensorflow is missing

[Petter Reinholdtsen]

[Lumin]
>> Is there some estimated time frame to package TensorFlow?
> 
> No estimated time frame for it. TensorFlow provides bazel build for
> linux and cmake build for windows.  Bazel itself is blocking for years,
> and a DD, Paul Liu, who worked on it in the past had said that it was
> hard to deal with. I guess the bazel build system is still blocking
> currently.

Is TensorFlow different from libtensorflow, already in unstable:

libtensorflow-cc1.10 - Computation using data flow graphs for scalable machine 
learning (C++)
libtensorflow-dev - Computation using data flow graphs for scalable machine 
learning (dev)
libtensorflow-framework1.10 - Computation using data flow graphs for scalable 
machine learning
libtensorflow1.10 - Computation using data flow graphs for scalable machine 
learning (C)

If not, perhaps keras should be adjusted to use it, and its
package description updated?  The tensorflow source package
entered unstable 2018-11-22.

As for the problem with running keras in unstable, perhaps it is a
good idea to extend the autopkgtest script to detect such problems early?
The current autopkgtest script succeed in testing and unstable.

-- 
Happy hacking
Petter Reinholdtsen

Bug#869626: node-ws: Please update to upstream version 3.0.0

[Jérémy Lal]

Package: node-ws
Followup-For: Bug #869626

Hi, how much is this still needed ? Any help would be appreciated
to update this package.

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

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

Bug#918525: r-base-core: library lapack.so shouldn't be linked to libopenblas.so.0

[Jörg-Volker Peetz]

Package: r-base-core
Version: 3.5.2-1
Severity: important

Hi Dirk,

the library /usr/lib/R/modules/lapack.so contained in this package is
linked to /usr/lib/x86_64-linux-gnu/libopenblas.so.0 of the package
libopenblas-base.  Package libopenblas-base provides the dependency
libblas.so.3. The library libblas.so.3 contained in package
libopenblas-base is already linked to libopenblas.so.0. Therefore, it is
not necessary lo link it to /usr/lib/R/modules/lapack.so, I
think. Rather, it is a bug to link it to /usr/lib/R/modules/lapack.so,
since other packages providing a BLAS library don't contain or provide
libopenblas.so.0.

Regards,
Jörg.

Bug#918524: ccdiff: Typo in package description

[gregor herrmann]

On Sun, 06 Jan 2019 23:47:01 +0100, Thomas Vincent wrote:

> I noticed a typo in the package description of ccdiff. Indeed, in the second 
> paragraph, 'addedd' should be spelled 'added'.

Thanks, fixed in git.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Walter Tessaris: 01/01/2000


signature.asc
Description: Digital Signature

Bug#918480: squashfs-tools: Please move to "squashfskit" fork

[GCS]

On Sun, Jan 6, 2019 at 11:18 PM Chris Lamb  wrote:
> Chris Lamb wrote:
> > https://git-tails.immerda.ch/squashfs-tools/plain/debian/patches/0011-If-SOURCE_DATE_EPOCH-is-set-use-that-timestamp-for-t.patch?h=debian
> >
> > … and:
> >
> > https://git-tails.immerda.ch/squashfs-tools/plain/debian/patches/0012-If-SOURCE_DATE_EPOCH-is-set-also-clamp-content-times.patch?h=debian
> >
> > … but I am not 100% sure just yet -- need to do a full
> > reproducibility test run here to confirm.
>
> I can now confirm that these make our images reproducible when a
> valid SOURCE_DATE_EPOCH is set in the environment. Could you apply
> them and upload?
 Just uploaded, may need a minute or two to be accepted.

> I can file another bug report that you can close if you wish; just
> let me know.
 There's no need for such a round-trip, thanks.

Regards,
Laszlo/GCS

Bug#918524: ccdiff: Typo in package description

[Thomas Vincent]

Package: ccdiff
Severity: minor

Dear Maintainer,

I noticed a typo in the package description of ccdiff. Indeed, in the second 
paragraph, 'addedd' should be spelled 'added'.

Thanks a lot for your work on ccdiff.
Thomas


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

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

Bug#851189: keyboard-configuration: ALT+Cursor-Left switches consoles instead of working on app in focus

[Samuel Thibault]

Hello,

Mike McGuire, le sam. 05 janv. 2019 03:25:42 +, a ecrit:
> This started happening to me recently, not sure what change could be to blame 
> but I found a lengthy thread on the ubuntu bug tracker that seems to confirm 
> things. Copying the relevant post: 
> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1508146/comments/66
> 
> ---
> 
> In my case, I traced the issue to the keyboard-configuration package postinst 
> script, which ends up calling 'setupcon --force --save' which in turn calls 
> 'kbd_mode -u'

Mmm, do you mean that this postinst script ends up calling setupcon
--force --save in a living Ubuntu system, not the installer of Ubuntu?

The script checks for the presence of the /lib/debian-installer.d
directory, does that directory really exist in an installed Ubuntu
system?  If so, that's the problem, that directory shouldn't exist on an
installed system.

> To reproduce:
> sudo apt install --reinstall keyboard-configuration

That doesn't trigger the issue on an installed Debian system (which
doesn't have /lib/debian-installer.d).

> It looks like the checks to avoid this behavior while a graphic environment 
> is active don't work in the context of the installer.

Err, since --force is passed, the checks are not used, so it's no
wonder. But it shouldn't be happening in a non-debian-installer case.

FTR: we do need --force because the Debian installer lives within a
bterm, and thus setupcon can not know that it's actually running within
a Linux console, just with bterm in between.

Samuel

Bug#918520: libfiu: FTBFS randomly when built with eatmydata

[Chris Lamb]

[Adding albert...@blitiri.com.ar to CC]

Dear Santiago,

> It is a "just in case". The offer to ssh into my machine is a blurb
> which I now add to all my bug reports when the problem is "weird",
> for example, when it does not seem to happen in buildd.debian.org or
> reproducible-builds.

Awesome -- I just checking as it is somewhat unusual to receive
that offer and I was just 100% confirming before I potenaily spent
cycles on this and I was missing something..

I'm tempted to think that upstream (CC'd) might have an idea at this
stage...? :)

> [..] sometimes the maintainer decides to never ssh to the machine,
> downgrade the bug, and keep saying it only happens to me, even when I
> can reproduce it in more than 20 different machines, the bug has also
> been found by other people doing QA, and there is not even a
> successful build log in buildd.debian.org. Amazing, isn't it?

Unfortunately this sort of unnecessary addition is not very
motivating. Sorry.


Regards,

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

Bug#918480: squashfs-tools: Please move to "squashfskit" fork

[Chris Lamb]

Chris Lamb wrote:

> https://git-tails.immerda.ch/squashfs-tools/plain/debian/patches/0011-If-SOURCE_DATE_EPOCH-is-set-use-that-timestamp-for-t.patch?h=debian
> 
> … and:
>   
> https://git-tails.immerda.ch/squashfs-tools/plain/debian/patches/0012-If-SOURCE_DATE_EPOCH-is-set-also-clamp-content-times.patch?h=debian
> 
> … but I am not 100% sure just yet -- need to do a full
> reproducibility test run here to confirm.

I can now confirm that these make our images reproducible when a
valid SOURCE_DATE_EPOCH is set in the environment. Could you apply
them and upload?

I can file another bug report that you can close if you wish; just
let me know.


Best wishes,

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

Bug#918520: libfiu: FTBFS randomly when built with eatmydata

[Santiago Vila]

On Sun, Jan 06, 2019 at 10:54:13PM +0100, Chris Lamb wrote:
> Hi Santiago,
> 
> > [ I can offer a machine for you to ssh into it and reproduce this if you
> >   need it, please contact me privately for details ].
> 
> Just out of interest, is there a good reason why I might not be
> able to reproduce this locally, or is this a "just in case"?

It is a "just in case". The offer to ssh into my machine is a blurb
which I now add to all my bug reports when the problem is "weird",
for example, when it does not seem to happen in buildd.debian.org or
reproducible-builds.

Sometimes this has the desired effect and the bug is fixed in record
time (see the great job of Cyril Brulebois with the clojure packages),
and sometimes the maintainer decides to never ssh to the machine,
downgrade the bug, and keep saying it only happens to me, even when I
can reproduce it in more than 20 different machines, the bug has also
been found by other people doing QA, and there is not even a
successful build log in buildd.debian.org. Amazing, isn't it?

Thanks.

Bug#917566: lintian: please warn about non-supported previous versions

[Chris Lamb]

tags 917566 - moreinfo
thanks

Hi Dmitry,

> Probably I missing something oblivious, but still: if you know that
> version X is latest

[…]

I think it was me who was missing oblivious; your pseudocode helped
clarify what you were after so thanks for persevering.

>   grep -v '#' $maintscript | grep -F "$v" ; then
   
Can we make this bit smarter? Or rather; can we? I'm wondering if
we might be grepping for "1.2-3" but the script uses "dpkg --
compare-versions $X -gte 1.2" or something like that..

> But issue is not sysvinit-specific. I have number of packages, that have
> code in maintainer scripts, that deals with upgrades from specific
> versions

Can you link to some concrete examples on this bug report if you
have a moment?


Best wishes,

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

Bug#918523: ITP: appimagelauncher -- Helper application for Linux distributions serving as a kind of "entry point" for running and integrating AppImages

[Scarlett Moore]

Package: wnpp
Severity: wishlist
Owner: Scarlett Moore 

* Package name: appimagelauncher
  Version : 1.0.0
  Upstream Author : TheAssassin 
* URL : https://github.com/TheAssassin/AppImageLauncher
* License : (MIT/X)
  Programming Lang: (C++)
  Description : Helper application for Linux distributions serving as a 
kind of "entry point" for running and integrating AppImages

I intend on maintaining this.

Bug#850798: tika: FTBFS: Could not resolve dependencies for project org.apache.tika:tika-parsers:jar:1.5

[Emmanuel Bourg]

Control: reassign -1 libvorbis-java
Control: affects -1 src:tika

I'm reassigning the bug to vorbis-java because the tika module should be
enabled there to fix this dependency issue. I'll look at the other
compilation errors separately.

Emmanuel Bourg

Bug#918520: libfiu: FTBFS randomly when built with eatmydata

[Chris Lamb]

Hi Santiago,

> [ I can offer a machine for you to ssh into it and reproduce this if you
>   need it, please contact me privately for details ].

Just out of interest, is there a good reason why I might not be
able to reproduce this locally, or is this a "just in case"?


Regards,

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

Bug#911944: neovim FTBFS: tests fail

[James McCoy]

Version: 0.3.2-1

On Sat, Nov 10, 2018 at 03:36:08PM -0500, James McCoy wrote:
> On Sat, Nov 10, 2018 at 04:09:55PM +0100, Helmut Grohne wrote:
> > I also tried in pbuilder and there I only got the utf_char2bytes
> > failure, not the ones with check_cores. This hints that something about
> > my build environment is fishy. If I understand correctly, my user's
> > resource limits "leak" through sbuild while they don't pass through
> > pbuilder. Would limiting the number of processes or virtual memory be a
> > plausible explanation for the failures?
> 
> Possibly.  I can more reliably hit the utf_char2bytes failure when I
> have other builds running in parallel.  It seems to correlate with
> resource contention.

The utf_char2bytes test was fixed in 0.3.2, and some of the more
reliably flaky tests are now getting skipped on Debian builds.

I'm going to close this particular report.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#918522: No sound with PulseAudio when an NVidia GPU is installed.

[Julien Aubin]

Package: pulseaudio
Version: 12.2-2
Severity: important

Hi,

The issue is reproducible on systems with an Intel Audio chip and a NVIDIA GPU
with HDMI output (detected as a soundcard).

When both conditions are met, PulseAudio does not detect the Intel Audio
soundcard anymore and no sound at all is output. The only workaround consists
in inserting garbage in /etc/pulse/daemon.conf to prevent it from loading (say,
a syntax error in the file). Then sound is back again.

I have NVidia blob 390.87, and I'm working with KDE.

Could you please fix the issue ?

Thanks a lot



-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  libasound2   1.1.7-2
ii  libasound2-plugins   1:1.1.7-dmo3
ii  libc62.28-2
ii  libcap2  1:2.25-1.2
ii  libdbus-1-3  1.12.12-1
ii  libgcc1  1:8.2.0-13
ii  libice6  2:1.0.9-2
ii  libltdl7 2.4.6-6
ii  liborc-0.4-0 1:0.4.28-3
ii  libpulse012.2-2
ii  libsm6   2:1.2.2-1+b3
ii  libsndfile1  1.0.28-4
ii  libsoxr0 0.1.2-3
ii  libspeexdsp1 1.2~rc1.2-1+b2
ii  libstdc++6   8.2.0-13
ii  libsystemd0  240-2
ii  libtdb1  1.3.16-2+b1
ii  libudev1 240-2
ii  libwebrtc-audio-processing1  0.3-1
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-2
ii  libxtst6 2:1.2.3-1
ii  lsb-base 10.2018112800
ii  pulseaudio-utils 12.2-2

Versions of packages pulseaudio recommends:
ii  dbus-user-session  1.12.12-1
ii  libpam-systemd 240-2
ii  rtkit  0.11-6

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
ii  pavucontrol  3.0-4
pn  pavumeter
ii  udev 240-2

-- Configuration Files:
/etc/pulse/daemon.conf changed [not included]

-- no debconf information

--===2823334201655246116==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="client.conf"

# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default,
usually 64 MiB

; auto-connect-localhost = no
; auto-connect-display = no

--===2823334201655246116==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="daemon.conf"

# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## 

Bug#915997: unyaffs: diff for NMU version 0.9.7-0.1

[Adrian Bunk]

Control: tags 805593 + patch
Control: tags 805593 + pending
Control: tags 915997 + pending
Control: tags 916117 + patch
Control: tags 916117 + pending

Dear maintainer,

I've prepared an NMU for unyaffs (versioned as 0.9.7-0.1) and uploaded 
it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

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

diff -Nru unyaffs-0.9.6/debian/changelog unyaffs-0.9.7/debian/changelog
--- unyaffs-0.9.6/debian/changelog	2013-04-09 17:50:32.0 +0300
+++ unyaffs-0.9.7/debian/changelog	2019-01-06 23:30:37.0 +0200
@@ -1,3 +1,15 @@
+unyaffs (0.9.7-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release.
+- Fixes FTBFS with glibc 2.28. (Closes: #915997)
+  * Build with default CFLAGS for non-empty -dbgsym.
+  * Use the upstream manpage. (Closes: #805593)
+  * Remove incorrect Vcs-Git and Vcs-Browser fields. (Closes: #916117)
+  * Priority: extra -> optional
+
+ -- Adrian Bunk   Sun, 06 Jan 2019 23:30:37 +0200
+
 unyaffs (0.9.6-1) unstable; urgency=low
 
   * Initial packaging (Closes: #703816)
diff -Nru unyaffs-0.9.6/debian/control unyaffs-0.9.7/debian/control
--- unyaffs-0.9.6/debian/control	2013-03-30 06:29:46.0 +0200
+++ unyaffs-0.9.7/debian/control	2019-01-06 23:30:37.0 +0200
@@ -1,12 +1,10 @@
 Source: unyaffs
 Section: devel
-Priority: extra
+Priority: optional
 Maintainer: Matthew Fischer 
 Build-Depends: debhelper (>= 9.0.0)
 Standards-Version: 3.9.4
 Homepage: https://github.com/ehlers/unyaffs
-Vcs-Git: git://github.com/ehlers/unyaffs.git
-Vcs-Browser: https://github.com/ehlers/unyaffs
 
 Package: unyaffs
 Architecture: any
diff -Nru unyaffs-0.9.6/debian/manpages unyaffs-0.9.7/debian/manpages
--- unyaffs-0.9.6/debian/manpages	2013-03-30 06:29:46.0 +0200
+++ unyaffs-0.9.7/debian/manpages	2019-01-06 23:30:37.0 +0200
@@ -1 +1 @@
-debian/unyaffs.1
+unyaffs.1
diff -Nru unyaffs-0.9.6/debian/rules unyaffs-0.9.7/debian/rules
--- unyaffs-0.9.6/debian/rules	2013-04-06 00:46:15.0 +0300
+++ unyaffs-0.9.7/debian/rules	2019-01-06 23:30:37.0 +0200
@@ -1,7 +1,4 @@
 #!/usr/bin/make -f
 
-override_dh_auto_build:
-	CFLAGS=-D_FORTIFY_SOURCE=2 dh_auto_build
-
 %:
 	dh $@
diff -Nru unyaffs-0.9.6/debian/unyaffs.1 unyaffs-0.9.7/debian/unyaffs.1
--- unyaffs-0.9.6/debian/unyaffs.1	2013-03-30 06:29:46.0 +0200
+++ unyaffs-0.9.7/debian/unyaffs.1	1970-01-01 02:00:00.0 +0200
@@ -1,31 +0,0 @@
-.\" (C) Copyright 2013 Matthew Fischer ,
-.TH UNYAFFS 1 "March 23, 2013"
-.SH NAME
-unyaffs \- extract files from a YAFFS2 file system image
-.SH SYNOPSIS
-.B unyaffs
-.RI [ options ]  []
-.SH DESCRIPTION
-.B unyaffs
-extracts files from a YAFFS2 file system image that was created with
-mkyaffs2image.
-.PP
-.SH OPTIONS
-.TP
-.B \-d
-detect of flash layout, no extraction
-.TP
-.B \-b
-spare contains bad block information
-.B \-c 
-get chunk size in KByte (default: autodetect, max: 16)
-.B \-s 
-set spare size in Byte  (default: autodetect, max: 512)
-.B \-t
-list image contents
-.B \-v
-verbose output
-.B \-V
-print version information
-.sp
-.LP
diff -Nru unyaffs-0.9.6/README unyaffs-0.9.7/README
--- unyaffs-0.9.6/README	2013-04-09 12:59:56.0 +0300
+++ unyaffs-0.9.7/README	2018-03-29 18:31:44.0 +0300
@@ -30,7 +30,7 @@
 
 
   Unyaffs should run on most unix-like operating systems.
-  A C compiler environment and make is neccessary to compile it.
+  A C compiler environment and make is necessary to compile it.
 
 
 Compiling
diff -Nru unyaffs-0.9.6/unyaffs.c unyaffs-0.9.7/unyaffs.c
--- unyaffs-0.9.6/unyaffs.c	2013-04-09 12:59:56.0 +0300
+++ unyaffs-0.9.7/unyaffs.c	2018-03-29 18:31:44.0 +0300
@@ -41,26 +41,32 @@
  *   Bug in verifying the -s (spare) parameter
  * V0.9.6  2013-04-09
  *   Added man page
+ * V0.9.7  2018-03-29
+ *   Directory creation doesn't fail, if it already exists
+ *   Fix compiler warnings for newer GCC
  */
 
-#define VERSION		"0.9.6"
+#define VERSION		"0.9.7"
 
 /* check if lutimes is available */
 #if defined(__linux__) || defined(__FreeBSD__) || defined(__NetBSD__) || (defined(__APPLE__) && defined(__MACH__))
 #define HAS_LUTIMES 1
 #endif
 
-#include 
-#include 
-#include 
-#include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#if defined(__linux__) || defined(__GLIBC__)
+#include 
+#endif
 #ifdef HAS_LUTIMES
 #include 
 #else
@@ -203,9 +209,11 @@
 	}
 	free(buf);
 
-	if (mkdir(name, mode) < 0 &&
-	(stat(name, ) < 0 || !S_ISDIR(st.st_mode)))
-		return -1;
+	if (mkdir(name, mode) < 0) {
+		if (stat(name, ) < 0 || !S_ISDIR(st.st_mode))
+			return -1;
+		chmod(name, mode);
+	}
 
 	return 0;
 }
@@ -522,7 +530,7 @@
 			break;
 		case 

Bug#914732: lists.debian.org: Request for new mailing list: debian-dug-muc

[Stefan Fritsch]

On Mon, 26 Nov 2018 20:12:24 +0100 Michael Banck  wrote:
> Please create the Debian User Group list debian-dug-muc for the Munich
> local area user group, https://wiki.debian.org/LocalGroups/DebianMuc

seconded.

Cheers,
Stefan

Bug#918509: qtwayland5 mixes together the client and server components of qtwayland

[Dmitry Shachnev]

Hi Martin!

On Sun, Jan 06, 2019 at 09:14:59PM +0100, Martin Graesslin wrote:
> QtWayland consists of a client part (providing the qpa platform plugin) and
> a compositor part (providing an API to implement a Wayland server).
> In Debian it's not possible to just install the client part. Thus the Plasma
> session requires to install the server components, although it doesn't
> use anything of it. This results in a wrong impression that KWin depends on
> Qt compositor. Overall this package is just weird.

Currently from the qtwayland source package we build multiple binary packages,
including separate binary packages for client shared library and header files,
compositor shared library and header files, and plugins.

All plugins are currently in the same binary package, qtwayland5. It contains:

1) /usr/lib/*/qt5/plugins/platforms/libqwayland*.so
2) /usr/lib/*/qt5/plugins/wayland-decoration-client/libbradient.so
3) /usr/lib/*/qt5/plugins/wayland-graphics-integration-client/*.so
4) /usr/lib/*/qt5/plugins/wayland-graphics-integration-server/*.so
5) /usr/lib/*/qt5/plugins/wayland-shell-integration/libivi-shell.so

Can you please suggest us how to further split this package?

Of these file groups, only 4) adds a dependency on libqt5waylandcompositor5.
Will splitting it into a separate package be enough?

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#868499: osmose-emulator: No sound

[Carlos Donizete Froes]

Hi, 

I agree that the plugdev device is obsolete. Although this is not a concrete
solution, it has been replaced from "plughw" by "default" in
"src/OsmoseCore.cpp".

Changed sound buffer writing method. Thanks to Kevin Joly (Kev-J).

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀   2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780


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

Bug#918521: vim FTCBFS: lots of reasons

[Helmut Grohne]

Source: vim
Version: 2:8.1.0693-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

vim fails to cross build from source for a larger pile of reasons. Let
me go through them step by step:

 * Build-Depends: ruby and Build-Depend: python3-dev asks for the host
   architecture interpreters respectively. Those interpreters are not
   runnable. What you need here is build architecture interpreters plus
   host architecture development packages for the respective languages.

 * The packaging does not instruct the build system to perform a cross
   build. You need to pass --host to ./src/configure. Unfortunately, the
   very first invocation happens via "make -C src scratch", so we need
   to stuff the relevant flags into CONF_ARGS.

 * ./src/configure fails in lots of places, because it cannot figure out
   the results without running stuff. We'll have to tell it to trust
   that getcwd, memmove and toupper work.

 * Some checks in ./src/configure fail unnecessarily. For instance
   sizeof(wchar_t) can easily be determined using AC_CHECK_SIZEOF.
   Checking whether tgetent actually works can be skipped and checking
   the tty group should be skipable as well as it is skipable during
   native builds.

 * After passing the first ./src/configure, debian/rules invokes it a
   number of further times. Again, we need to pass --host.

 * Finally, it fails finding ruby/config.h.

I have no clue how to fix the last issue, but the attached patch fixes
all the other ones. Does the patch make sense to you? Please close this
bug when addressing multiple of the points raised above even if vim
doesn't cross build. I tried making the embedded cross.patch
upstreamable. If these explanations are too succinct, don't hesitate to
ask for details.

Helmut
diff --minimal -Nru vim-8.1.0693/debian/changelog vim-8.1.0693/debian/changelog
--- vim-8.1.0693/debian/changelog   2019-01-05 21:53:12.0 +0100
+++ vim-8.1.0693/debian/changelog   2019-01-06 21:19:29.0 +0100
@@ -1,3 +1,15 @@
+vim (2:8.1.0693-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: (Closes: #-1)
++ Multiarchify python and ruby Build-Depends.
++ Add --host to ./src/configure via make scratch.
++ Export a pile of vim-specific autoconf cache variables.
++ cross.patch: Fix a few autoconf checks.
++ Also pass --host to CFGFLAGS.
+
+ -- Helmut Grohne   Sun, 06 Jan 2019 21:19:29 +0100
+
 vim (2:8.1.0693-2) unstable; urgency=medium
 
   * Separate /etc/vim and /usr/share/vim/vimfiles.  The former should be for
diff --minimal -Nru vim-8.1.0693/debian/control vim-8.1.0693/debian/control
--- vim-8.1.0693/debian/control 2019-01-05 21:53:12.0 +0100
+++ vim-8.1.0693/debian/control 2019-01-06 21:19:27.0 +0100
@@ -18,6 +18,7 @@
  libgtk2.0-dev,
  liblua5.2-dev,
  libperl-dev,
+ libpython3-dev,
  libselinux1-dev [linux-any],
  libncurses-dev,
 # Needed to run libvterm's tests
@@ -26,8 +27,8 @@
  libxpm-dev,
  libxt-dev,
  lua5.2,
- python3-dev,
- ruby,
+ python3-dev:any,
+ ruby:any,
  ruby-dev,
  tcl-dev,
 Build-Conflicts:
diff --minimal -Nru vim-8.1.0693/debian/patches/cross.patch 
vim-8.1.0693/debian/patches/cross.patch
--- vim-8.1.0693/debian/patches/cross.patch 1970-01-01 01:00:00.0 
+0100
+++ vim-8.1.0693/debian/patches/cross.patch 2019-01-06 21:19:29.0 
+0100
@@ -0,0 +1,51 @@
+--- vim-8.1.0693.orig/src/configure.ac
 vim-8.1.0693/src/configure.ac
+@@ -2319,23 +2319,17 @@
+ 
+ LDFLAGS="$ac_save_LDFLAGS"
+ 
+-AC_MSG_CHECKING(size of wchar_t is 2 bytes)
+-AC_CACHE_VAL(ac_cv_small_wchar_t,
+-  [AC_TRY_RUN([
++AC_CHECK_SIZEOF([wchar_t],,[
+ #include 
+ #if STDC_HEADERS
+ # include 
+ # include 
+ #endif
+-  main()
+-  {
+-if (sizeof(wchar_t) <= 2)
+-  exit(1);
+-exit(0);
+-  }],
+-  ac_cv_small_wchar_t="no",
+-  ac_cv_small_wchar_t="yes",
+-  AC_MSG_ERROR(failed to compile test program))])
++])
++AC_MSG_CHECKING(size of wchar_t is 2 bytes)
++AS_IF([test "$ac_cv_sizeof_wchar_t" -le 2],
++ac_cv_small_wchar_t="yes",
++ac_cv_small_wchar_t="no")
+ AC_MSG_RESULT($ac_cv_small_wchar_t)
+ if test "x$ac_cv_small_wchar_t" = "xyes" ; then
+   AC_DEFINE(SMALL_WCHAR_T)
+@@ -3464,7 +3458,7 @@
+ # include 
+ #endif
+ main() {char *s; s=(char *)tgoto("%p1%d", 0, 1); exit(0); }],
+-res="OK", res="FAIL", res="FAIL")
++res="OK", res="FAIL", res="OK")
+   if test "$res" = "OK"; then
+   break
+   fi
+@@ -3703,7 +3697,8 @@
+   vim_cv_tty_group=world
+   AC_MSG_RESULT([can't determine - assume ptys are world accessible])
+ ],[
+-  AC_MSG_ERROR(cross-compiling: please set 'vim_cv_tty_group' and 
'vim_cv_tty_mode')
++  vim_cv_tty_group=world
++  AC_MSG_RESULT([cross-compiling: - assume ptys are world accessible])
+   

Bug#918499: libreoffice: fails with 'ERROR 4 forking process'

[Rene Engelhard]

tag 918499 + moreinfo
tag 918499 + unreproducible
severity 918499 important
thanks

Hi,

On Sun, Jan 06, 2019 at 01:46:09PM -0500, David Zelinsky wrote:
> Package: libreoffice
> Version: 1:6.1.3-2
> Severity: grave
> Justification: renders package unusable

Sorry, but not every problem one person has is a *release-critical*
bug in said package. Especially not if that testing is ooold.

> I'm running "testing", and recently did a dist-upgrade.  Previously

No, you didn't. If you did you wouldn't have a loads of obsolete
versions of stuff installed. Like default-jre pointing to 10 whereas
it is 11 since looong. And LibreOffice 1:6.1.3-2 already was
obsoleted. (At least that is what you report it against and your
reportbug-generated info shows).

> libreoffice worked fine, but now fails to start.  From the menu,

My laptop is runnig testing, too and this worked and works.

> nothing happens.  From command line, it fails with the subject error:
> 
>   % libreoffice

And this works fine.

> read(6, "/usr/lib/jvm/java-8-openjdk-amd6"..., 4096) = 221

So you use OpenJDK 8 in the config? Then see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925

But at this stage (oosplash) this shouldn't matter yet...

Regards,

Rene

Bug#918520: libfiu: FTBFS randomly when built with eatmydata

[Santiago Vila]

Package: src:libfiu
Version: 0.98-1
Tags: ftbfs

Hello Chris.

I'm getting random build failures for this package:


[...]
 debian/rules build-arch
dh build-arch --with python3,python2
   dh_update_autotools_config -a
   dh_autoreconf -a
   dh_auto_configure -a
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
rst2html doc/posix.rst > doc/posix.html
rst2html doc/guide.rst > doc/guide.html
rst2html doc/remote_control.rst > doc/remote_control.html
dh_auto_build -- V=1
make -j2 "INSTALL=install --strip-program=true" V=1
make[2]: Entering directory '/<>'
make -C libfiu

[... snipped ...]

cc -I../../libfiu/ -L../../libfiu/ -L./ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC 
-DFIU_ENABLE=1 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 -pedantic 
-Wall -std=c99 -pedantic -Wall -L. binary.c -lfiu -lcoltest -o binary
LD_LIBRARY_PATH="./:../../libfiu/" ./binary
make[4]: Leaving directory '/<>/tests/collisions'
cc -I../../libfiu/ -L../../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC 
-DFIU_ENABLE=1 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 -pedantic 
-Wall -std=c99 -pedantic -Wall tests/fread.c -lfiu -o tests/fread.bin
ln -f ../preload/posix/fiu_posix_preload.so libs/
ln -f ../preload/run/fiu_run_preload.so libs/
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so 
../../preload/posix/fiu_posix_preload.so" ./tests/strdup.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so 
../../preload/posix/fiu_posix_preload.so" ./tests/fprintf.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so 
../../preload/posix/fiu_posix_preload.so" ./tests/kill.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so 
../../preload/posix/fiu_posix_preload.so" ./tests/open.bin
cc -I../libfiu/ -L../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC 
-DFIU_ENABLE=1 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 -pedantic 
-Wall test-parallel-wildcard.c -lfiu -lpthread -o test-parallel-wildcard
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so 
../../preload/posix/fiu_posix_preload.so" ./tests/pread.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so 
../../preload/posix/fiu_posix_preload.so" ./tests/malloc.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so 
../../preload/posix/fiu_posix_preload.so" ./tests/open64.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so 
../../preload/posix/fiu_posix_preload.so" ./tests/mmap.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so 
../../preload/posix/fiu_posix_preload.so" ./tests/pread64.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so 
../../preload/posix/fiu_posix_preload.so" ./tests/fopen.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so 
../../preload/posix/fiu_posix_preload.so" ./tests/fread.bin
rm tests/open.bin tests/fread.bin tests/open64.bin tests/strdup.bin 
tests/pread.bin tests/pread64.bin tests/malloc.bin tests/mmap.bin 
tests/fprintf.bin tests/kill.bin tests/fopen.bin
make[4]: Leaving directory '/<>/tests/generated'
cc -I../libfiu/ -L../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC 
-DFIU_ENABLE=1 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 -pedantic 
-Wall \
-rdynamic -fno-optimize-sibling-calls test-enable_stack.c -lfiu 
-lpthread -o test-enable_stack
test-enable_stack.c: In function 'main':
test-enable_stack.c:32:43: warning: ISO C forbids conversion of function 
pointer to object pointer type [-Wpedantic]
  r = fiu_enable_stack("fp-1", 1, NULL, 0, (void *) , -1);
   ^
cc -I../libfiu/ -L../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC 
-DFIU_ENABLE=1 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 -pedantic 
-Wall \
-rdynamic -fno-optimize-sibling-calls test-enable_stack_by_name.c -lfiu 
-lpthread -o test-enable_stack_by_name
cc -I../libfiu/ -L../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC 
-DFIU_ENABLE=1 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 -pedantic 
-Wall test-parallel.c -lfiu -lpthread -o test-parallel
cc -I../libfiu/ -L../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC 
-DFIU_ENABLE=1 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 -pedantic 
-Wall test-ferror.c -lfiu -lpthread -o test-ferror
LD_LIBRARY_PATH=../libfiu/ 
LD_PRELOAD=./libs/fiu_run_preload.so:./libs/fiu_posix_preload.so 

Bug#918519: libi8x: FTBFS on mips(el): Test calling a native function. ... Bus error

[Emilio Pozuelo Monfort]

Source: libi8x
Version: 0.0.5-1
Severity: serious
Tags: ftbfs

Hi,

Your package failed to build on mips/el on a rebuild without python3.6:

Test calling a native function. ... Bus error

Full logs at 
https://buildd.debian.org/status/package.php?p=libi8x=unstable

Emilio

Bug#918518: ITP: austin -- a frame stack sampler for CPython

[Gabriele]

Package: wnpp
Owner: Gabriele N. Tornetta 
Severity: wishlist

* Package name: austin
  Version : 0.6.1
  Upstream Author : Gabriele N. Tornetta 
* URL : https://github.com/P403n1x87/austin
* License : GPL
  Programming Lang: C
  Description : a frame stack sampler for CPython

Austin is a frame stack sampler for CPython, meant to be
used to create high-performance Python profilers with
minimal impact on the profiled program.
.
Austin does not require any code instrumentation and can be
used on production code at run-time with almost no overhead.
.
I'm looking for a mentor to sponsor this package. Austin is
a pure C application with no dependencies other than stdlib
and that compiles to a single tiny binary.

Bug#848948: ebtables FTCBFS: uses build architecture compiler

[Niels Thykier]

On Wed, 21 Dec 2016 06:21:44 +0100 Helmut Grohne  wrote:
> Source: ebtables
> Version: 2.0.10.4-3.5
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> ebtables fails to cross build from source, because it uses the build
> architecture compiler. dh_strip thus fails operating on build
> architecture ELF objects expecting host architecture ones. Prefixing the
> compiler with the host triplet solves this problem. Please consider
> applying the attached patch.
> 
> Helmut

Hi Alberto,

I see you recently uploaded a version of ebtables.  Could I convince you
to do another upload with this cross-building patch for buster (from
#848948)?

I am happy to sponsor it if you need that or simply do an NMU if it is
easier for you and you don't mind it. :)

Thanks,
~Niels



signature.asc
Description: OpenPGP digital signature

Bug#918517: grib-api: fails to remove packages

[Emilio Pozuelo Monfort]

Source: grib-api
Version: 1.28.0-1
Severity: grave

Hi,

Your packages fail to remove:

  (Reading database ... 4458 files and directories currently installed.)
  Purging configuration files for python-gribapi (1.28.0-1) ...
  rmdir: failed to remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran-mod-15': 
No such file or directory
  dpkg: error processing package python-gribapi (--purge):
   installed python-gribapi package post-removal script subprocess returned 
error exit status 1

This also happens with other packages from src:grib-api, see

https://piuparts.debian.org/sid/source/g/grib-api.html

Emilio

Bug#914317: dgit: sometimes ignores configured clean-mode

[Ian Jackson]

Sean Whitton writes ("Re: Bug#914317: dgit: sometimes ignores configured 
clean-mode"):
> On Sun 06 Jan 2019 at 01:13pm GMT, Ian Jackson wrote:
> > I tried quite hard to investigate this allegation that the clean mode
> > was honoured differently according to whether it was specified in the
> > git config, or on the command line; with no success.  I also traced
> > the code.  I think you are mistaken on that.
> 
> Fair enough!  I am able to reproduce as many times as you like, but I'm
> not going to send you my root filesystem image :)

You expressed confidence on irc too, so I thought we should compare
notes more systematically.  Here is my non-repro.

You said on irc:
 20:20  It's the repro from my original report
 20:20  Which is almost a script :)

Please find attached two scripts, and the combined stdout/stderr of
running the second one `repro-4'.  As you can see, it producs the same
bad error both times.  That is with dgit 8.1.

Also attached is log2 which is with my current master (8.2~).  In
that, as you can see, it produces the same better error both times.

On your setup, does my repro-{3,4} script pair behave consistently
regardless of how you ask it to set the clean mode ?

Ian.

#!/bin/bash

# run as
#   cd /home/ian/things/Dgit/Bugs/914317/git-annex
#   ../repro-3 CHROOT CONFIG-PFX CLEAN-OPT
#
# where
#   CONFIG-PFX is''   to have the clean mode set in config
#   CONFIG-PFX is:to NOT have the clean mode set in config
#
#   CLEAN_OPT is 
#
#  Eg
# ../repro-3 build '' ''
# ../repro-3 build : -wgf

set -ex

 chroot=$1; shift
 config_pfx=$1; shift
 clean_opt=$1; shift

 export HOME=$(cd .. && pwd)
 rm -f ../.gitconfig
 $config_pfx git config --global dgit.default.clean-mode git-ff
 git config -l

 git-deborig ||:

# Tidy up any previous stuff

 git clean -xdff
 git reset --hard c6dda1ee~1

# 1) Make some changes to upstream files
# 2) Stage them

 git cherry-pick -n c6dda1ee

# 3) dgit --include-dirty build-source

 dgit -wdd --include-dirty build-source

# 4) Now you have uncommitted debian/patches, but ignore that, and instead
#commit your upstream changes

 git commit -m X

# 5) dgit sbuild (or whatever), and you get:

 dgit $clean_opt sbuild -c $chroot -A

#!/bin/bash

set -x
# no -e

 ../repro-3 build '' ''
 ../repro-3 build : -wgf
+ ../repro-3 build '' ''
+ chroot=build
+ shift
+ config_pfx=
+ shift
+ clean_opt=
+ shift
++ cd ..
++ pwd
+ export HOME=/home/ian/things/Dgit/Bugs/914317
+ HOME=/home/ian/things/Dgit/Bugs/914317
+ rm -f ../.gitconfig
+ git config --global dgit.default.clean-mode git-ff
+ git config -l
dgit.default.clean-mode=git-ff
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=https://salsa.debian.org/haskell-team/git-annex
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master
+ git-deborig
../git-annex_7.20181121.orig.tar.xz already exists: not overwriting without -f
+ :
+ git clean -xdff
+ git reset --hard c6dda1ee~1
HEAD is now at b20ad8343 changelog
+ git cherry-pick -n c6dda1ee
+ dgit -wdd --include-dirty build-source
dpkg-buildpackage: info: source package git-annex
dpkg-buildpackage: info: source version 7.20181121-1
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by Sean Whitton 

 fakeroot debian/rules clean
dpkg-buildpackage: info: host architecture amd64
dh clean
   dh_auto_clean
make -j1 clean
make[1]: Entering directory '/home/ian/things/Dgit/Bugs/914317/git-annex'
if [ "./Setup" != ./Setup ] && [ "./Setup" != cabal ]; then ./Setup clean; fi
rm -rf tmp dist git-annex  configure  *.tix .hpc \
doc/.ikiwiki html dist tags Build/SysConfig Build/Version \
Setup Build/InstallDesktopFile \
Build/Standalone Build/OSXMkLibs Build/LinuxMkLibs \
Build/DistributionUpdate Build/BuildVersion Build/MakeMans \
git-annex-shell git-union-merge .tasty-rerun-log
find . -name \*.o -exec rm {} \;
find . -name \*.hi -exec rm {} \;
make[1]: Leaving directory '/home/ian/things/Dgit/Bugs/914317/git-annex'
   dh_clean
Format `3.0 (quilt)', need to check/update patch stack
starting quiltify (single-debian-patch)
dpkg-source: info: using options from work/debian/source/options: 
--single-debian-patch --auto-commit
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building git-annex using existing 
./git-annex_7.20181121.orig.tar.xz
dpkg-source: info: building git-annex in git-annex_7.20181121-1.debian.tar.xz
dpkg-source: info: building git-annex in git-annex_7.20181121-1.dsc
dpkg-source: warning: extracting unsigned source package 
(git-annex_7.20181121-1.dsc)
dpkg-source: info: extracting git-annex in git-annex-7.20181121
dpkg-source: info: unpacking git-annex_7.20181121.orig.tar.xz
dpkg-source: info: unpacking git-annex_7.20181121-1.debian.tar.xz
nothing quilty to commit, ok.
dpkg-source: info: using options from 

Bug#918516: git-lfs FTBFS with Go 1.11

[Adrian Bunk]

Source: git-lfs
Version: 2.6.1-1
Severity: serious
Tags: ftbfs

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

...
   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/1st/git-lfs-2.6.1'
cd obj-x86_64-linux-gnu/src/github.com/git-lfs/git-lfs && go generate ./commands
go: disabling cache (/nonexistent/first-build/.cache/go-build) due to 
initialization failure: mkdir /nonexistent: permission denied
go: cannot use modules with build cache disabled
make[1]: *** [debian/rules:18: override_dh_auto_build] Error 1

Bug#912324: BleachBit causing error since updating Firefox to Firefox Quantum 60.0 ESR

[Witold Baryluk]

Package: bleachbit
Followup-For: Bug #912324

Please downgrade the severity to important.

It is definitively not 'serious' bug by any means.

Thanks.

Bug#918322: initramfs-tools: kernel fails to boot with "Gave up waiting for root file system device"

[Michael Biebl]

Hi Axel

Am 06.01.19 um 13:32 schrieb Axel Ludszuweit:
> 
> Hello Michael,
> 
> I have try your udev240-3, unfortunately it fails in the same way as 
> udev240-2. Due to a lack of PS2 keyboard I can't run your suggested commands 
> in the initramfs shell.
> One  thing was other than I expected:
> I have booted with 4.18 initrd image running 4.18 kernel, checked via uname. 
> After installing 
> - udev_240-3~test0_amd64.deb
> - libudev-dev_240-3~test0_amd64.deb
> - libudev1_240-3~test0_amd64.deb
> via dpkg -i *.deb only initrd.img-4.19.0-1-amd64 was rebuilt, although 4.18 
> kernel was running.
> With the above mentioned udev packages I can boot into 4.18 but not into 4.19.

Thanks for testing the -3~test0 packages.
I've forwarded this particular issue to the upstream bug tracker and the
upstream developers wanted me to test a specific patch, which I applied
to the -3~test0 version.
See
https://github.com/systemd/systemd/issues/11314#issuecomment-451380551
Seems that didn't help :-/
I forwarded your results there.

Unfortunately I haven't figured out the conditions yet how to trigger
this issue, so I can't reproduce it myself yet.

Sorry for making you jump through hoops and trying to find the issue by
trial and error. I can imagine this is not fun to do.

Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#918322: initramfs-tools: kernel fails to boot with "Gave up waiting for root file system device"

[Michael Biebl]

Hi Laurence!

Am 06.01.19 um 19:29 schrieb Laurence Abbott:
> I'm pretty sure I came across the same issue yesterday: I ran a
> dist-upgrade on an X99-based system (the first for several months) and
> the system was left unbootable. My root system is on raid and booting
> failed with mdadm errors about it not being able to find any of the
> raid arrays listed in /etc/mdadm/mdadm.conf.
> 
> From the initramfs shell (having eventually found a PS/2 keyboard!), I
> could see no disks or partitions under /dev. I even tried booting off
> a (recent - downloaded to rescue this system!) testing installation
> DVD and had the same problem: it got so far and then lost the DVD
> drive! As before, a shell showed no disk or partition devices under
> /dev.
> 
> After a lot of panic, I eventually worked out that a simple "modprobe
> ahci" at the initramfs prompt and exiting it allowed the system to
> boot properly.
> 
> The problem (at least for me) is that the ahci module isn't getting
> loaded automatically on boot. Load it by hand and it boots normally. I
> suspect this would work for others with a similar setup.

Yeah, this seems to be the problem. The auto-loading of modules is no
longer properly triggered by udev.

> I don't know enough about the minutiae of the boot process to debug
> this much more but I assume that it is udev that should be pulling in
> any needed modules based on the hardware. As part of the upgrade
> (looking back now), udev was upgraded from 239-13 to 240-2.
> 
> I did think about trying to get the initrd to force loading the ahci
> module but that's never been needed in the past!

If you look into /usr/share/initramfs-tools/scripts/init-top/udev the
following command are/should be responsible for triggering the modules
auto-loading:

udevadm trigger --type=subsystems --action=add
udevadm trigger --type=devices --action=add

For some reason, this no longer works properly under certain conditions.

When you are dropped into a rescue shell, can you execute the above
commands (again). Do they trigger the auto-load of the modules or not?

Once we know that, we can further debug this.

Btw, if you are online via IRC, we might debug this more interactively.
If so, please come by #debian-systemd on oftc. My nick is mbiebl.

Regards,
Michael







signature.asc
Description: OpenPGP digital signature

Bug#918515: golang-github-aead-chacha20 FTBFS: relocation target runtime.support_avx not defined

[Adrian Bunk]

Source: golang-github-aead-chacha20
Version: 0.0~git20180214.c8d2937-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-github-aead-chacha20.html

...
   dh_auto_test -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go test -vet=off -v -p 16 
github.com/aead/chacha20 github.com/aead/chacha20/chacha
# github.com/aead/chacha20.test
github.com/aead/chacha20/chacha.supportsAVX2: relocation target 
runtime.support_avx not defined
github.com/aead/chacha20/chacha.supportsAVX2: relocation target 
runtime.support_avx2 not defined
FAILgithub.com/aead/chacha20 [build failed]
# github.com/aead/chacha20/chacha.test
github.com/aead/chacha20/chacha.supportsAVX2: relocation target 
runtime.support_avx not defined
github.com/aead/chacha20/chacha.supportsAVX2: relocation target 
runtime.support_avx2 not defined
FAILgithub.com/aead/chacha20/chacha [build failed]
dh_auto_test: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 16 
github.com/aead/chacha20 github.com/aead/chacha20/chacha returned exit code 2
make: *** [debian/rules:4: build] Error 2

Bug#918513: ITP: soupsieve -- A modern CSS selector implementation for BeautifulSoup

[Stefano Rivera]

Package: wnpp
Severity: wishlist
Owner: Stefano Rivera 

* Package name: soupsieve
  Version : 1.6.2
  Upstream Author : Isaac Muse 
* URL : https://github.com/facelessuser/soupsieve
* License : MIT/Expat
  Programming Lang: Python
  Description : A modern CSS selector implementation for BeautifulSoup

Soup Sieve is a CSS selector library designed to be used with Beautiful
Soup 4 (python-bs4 in Debian). It aims to provide selecting, matching,
and filtering using modern CSS selectors. Soup Sieve currently provides
selectors from the CSS level 1 specifications up through the latest CSS
level 4 drafts (though some are not yet implemented).

Soup Sieve was written with the intent to replace Beautiful Soup's
builtin select feature, and as of Beautiful Soup version 4.7.0, it now
is . Soup Sieve can also be imported in order to use its API directly
for more controlled, specialized parsing.

Bug#918514: golang-github-aead-poly1305 FTBFS: relocation target runtime.support_avx2 not defined

[Adrian Bunk]

Source: golang-github-aead-poly1305
Version: 0.0~git20170715.6cf43fd-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-github-aead-poly1305.html

...
   dh_auto_test -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go test -vet=off -v -p 16 
github.com/aead/poly1305
# github.com/aead/poly1305.test
github.com/aead/poly1305.supportsAVX2: relocation target runtime.support_avx2 
not defined
FAILgithub.com/aead/poly1305 [build failed]
dh_auto_test: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 16 
github.com/aead/poly1305 returned exit code 2
make: *** [debian/rules:4: build] Error 2

Bug#918079: pandas: FTBFS: B-D on python-nbsphinx which is no longer installable nor built any more

[Paul Gevers]

On Thu, 3 Jan 2019 02:39:12 + (UTC) Thorsten Glaser 
wrote:
> See #917418 for “python-nbsphinx (0.4.1+ds-1) is not installable”.
> 
> src:nbsphinx (0.4.1+ds-3) now only builds the py3k package.
> 
> python-nbsphinx (= 0.3.5+ds-1) is installable and usable, but no
> longer in Debian, so please move to python3-nbsphinx instead.

Please don't forget to update your autopkgtest as well. It is currently
blocking multiple migrations due to this as your test depends on
pyton-nbsphinx as well.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#918512: kwayland-integration incorrectly depends on qtwayland5

[Martin Graesslin]

Package: kwayland-integration
Version: 5.13.4-1
Severity: normal

Dear Maintainer,

kwayland-integration depends on qtwayland5. This package depends on both Qt's 
client and compositor API. It absolutely makes no sense that a Wayland *client* 
integration plugin depends on a compositor API. In fact kwayland-integration 
does not depend at all on qtwayland.
To a certain degree one could argue that it should runtime depend on the qpa 
platform plugin, but it's rather the other way around. If an application uses 
the wayland qpa, kwayland-integration can be used.

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

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

Versions of packages kwayland-integration depends on:
ii  libc6 2.27-8
ii  libkf5idletime5   5.49.0-1
ii  libkf5waylandclient5  4:5.49.0-1
ii  libkf5windowsystem5   5.49.0-1
ii  libqt5core5a  5.11.2+dfsg-4
ii  libqt5gui55.11.2+dfsg-4
ii  libqt5widgets55.11.2+dfsg-4
ii  libstdc++68.2.0-9
ii  qtwayland55.11.2-3

kwayland-integration recommends no packages.

kwayland-integration suggests no packages.

-- no debconf information

Bug#918511: golang-github-shopify-sarama-dev: missing dependency on golang-github-datadog-zstd-dev

[Adrian Bunk]

Package: golang-github-shopify-sarama-dev
Version: 1.20.0-1
Severity: serious
Control: affects -1 src:burrow

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

...
src/github.com/Shopify/sarama/zstd_cgo.go:5:8: cannot find package 
"github.com/DataDog/zstd" in any of:
/usr/lib/go-1.11/src/github.com/DataDog/zstd (from $GOROOT)

/build/1st/burrow-1.1.0/obj-x86_64-linux-gnu/src/github.com/DataDog/zstd (from 
$GOPATH)
...

Bug#918509: qtwayland5 mixes together the client and server components of qtwayland

[Martin Graesslin]

Package: qtwayland5
Version: 5.11.2-3
Severity: normal

Dear Maintainer,

QtWayland consists of a client part (providing the qpa platform plugin) and a 
compositor part (providing an API to implement a Wayland server).
In Debian it's not possible to just install the client part. Thus the Plasma 
session requires to install the server components, although it doesn't
use anything of it. This results in a wrong impression that KWin depends on Qt 
compositor. Overall this package is just weird.

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

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

Versions of packages qtwayland5 depends on:
ii  libc6 2.27-8
ii  libegl1   1.1.0-1
ii  libgcc1   1:8.2.0-9
ii  libgl11.1.0-1
ii  libqt5core5a [qtbase-abi-5-11-2]  5.11.2+dfsg-4
ii  libqt5gui55.11.2+dfsg-4
ii  libqt5waylandclient5  5.11.2-3
ii  libqt5waylandcompositor5  5.11.2-3
ii  libstdc++68.2.0-9
ii  libwayland-client01.16.0-1
ii  libwayland-egl1   1.16.0-1
ii  libwayland-server01.16.0-1
ii  libx11-6  2:1.6.7-1
ii  libxcomposite11:0.4.4-2

qtwayland5 recommends no packages.

qtwayland5 suggests no packages.

-- no debconf information

Bug#918384: dgit: typo suggestions in man pages

[Sean Whitton]

Hello,

On Sun 06 Jan 2019 at 07:39pm GMT, Ian Jackson wrote:

>> > > -Whether to setup a merge driver which uses dpkg-mergechangelogs for
>> > > +Whether to set up a merge driver which uses dpkg-mergechangelogs for
>> >
>> > I think this is wrong.  AIUI, 'setup' is a noun and 'set up' is a verb.
>>
>> Right, so it seemed it was being used as a verb; hence "set up".  One
>> way or another, everybody will know what is meant of course.
>
> I have a personal tendency to glue words together more than other
> people.  I think your (Paul's) analysis of this as a verb is correct
> (at least for general contemporary usage) and therefore Sean ought to
> agree with you that it should be `set up'.  I am fine with it being
> changed.

Whoops, yes, it should be 'set up'.  Thanks.

-- 
Sean Whitton

Bug#918510: kwin-wayland incorrectly depends on kwayland-integration

[Martin Graesslin]

Package: kwin-wayland
Version: 4:5.13.5-1+b1
Severity: normal

Dear Maintainer,

kwin-wayland incorrectly depends on kwayland-integration. KWin neither at build 
nor at run time uses anyting from kwayland-integration.

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

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

Versions of packages kwin-wayland depends on:
ii  kwayland-integration  5.13.4-1
ii  kwin-common   4:5.13.5-1+b1
ii  kwin-wayland-backend-drm  4:5.13.5-1+b1
ii  libc6 2.27-8
ii  libcap2   1:2.25-1.2
ii  libcap2-bin   1:2.25-1.2
ii  libepoxy0 1.5.3-0.1
ii  libfontconfig12.13.1-1
ii  libfreetype6  2.8.1-2
ii  libkf5coreaddons5 5.49.0-1
ii  libkf5i18n5   5.49.0-1
ii  libkf5idletime5   5.49.0-1
ii  libkf5quickaddons55.49.0-1
ii  libkf5waylandclient5  4:5.49.0-1
ii  libkf5waylandserver5  4:5.49.0-1
ii  libkf5windowsystem5   5.49.0-1
ii  libkwineffects11  4:5.13.5-1+b1
ii  libqt5core5a [qtbase-abi-5-11-2]  5.11.2+dfsg-4
ii  libqt5dbus5   5.11.2+dfsg-4
ii  libqt5gui55.11.2+dfsg-4
ii  libqt5widgets55.11.2+dfsg-4
ii  libstdc++68.2.0-9
ii  libwayland-egl1   1.16.0-1
ii  libxcb1   1.13.1-1
ii  xwayland  2:1.20.3-1

kwin-wayland recommends no packages.

kwin-wayland suggests no packages.

-- no debconf information

Bug#918508: Should golang-1.10 be shpped in buster?

[Adrian Bunk]

Source: golang-1.10
Severity: serious

With golang-1.11 as default now, should golang-1.10
be shipped in buster?

Bug#918507: RFS: osmose-emulator/1.4-1 - Sega Master System and Game Gear console emulator

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "osmose-emulator"

 * Package name: osmose-emulator
   Version : 1.4-1
   Upstream Author : Carlos Donizete Froes 
 * URL : https://gitlab.com/coringao/osmose-emulator
 * License : GPL-3+
   Section : games

  It builds those binary packages:

  osmose-emulator - Sega Master System and Game Gear console emulator

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

  https://mentors.debian.net/package/osmose-emulator

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/osmose-emulator/osmose-emulator_1.4-1.dsc

  More information about osmose-emulator can be obtained from 
https://gitlab.com/coringao/osmose-emulator/wikis.

  Changes since the last upload:

  osmose-emulator (1.4-1) unstable; urgency=medium

  * New upstream release (Closes: #868499)
  * Switch to compat level 12
  * debian/control:
+ Bump debhelper compat to 12
+ Declare compliance with Debian Policy 4.3.0

  Regards,
   Carlos Donizete Froes [a.k.a coringao]

Bug#918506: Installation fails with "This account is currently not available." when debian-spamd has no login shell

[debian-bugreports943]

Package: spamassassin
Version: 3.4.2-1~deb9u1

The installation or update of spamassassin
aborts with the following error message:

$ aptitude install spamassassin
[...]
Errors were encountered while processing:
spamassassin
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up spamassassin (3.4.2-1~deb9u1) ...
This account is currently not available.

This happens when the user account debian-spamd is setup with invalid
login shell, preventing manual login to the account:
$ grep debian-spamd /etc/passwd
debian-spamd:x:111:114::/var/lib/spamassassin:/usr/sbin/nologin

This is the (reasonable) default setup of the account, so I don't want
to assign a valid login shell to this account.

Instead I worked around this issue with the following change in the
postinst script /var/lib/dpkg/info/spamassassin.postinst
  Line 38
  su - $OWNER -c "sa-update \
 --gpghomedir /var/lib/spamassassin/sa-update-keys \
 --import /usr/share/spamassassin/GPG.KEY"
Replace: "su - $OWNER -c " --> "sudo -u $OWNER sh -c"

sudo does work with disabled accounts, su doesn't

Bug#918372: unblock: med-fichier/4.0.0+repack-6

[Adrian Bunk]

On Sun, Jan 06, 2019 at 08:28:33PM +0100, Paul Gevers wrote:
> Hi Adrian, Niels,

Hi Paul,

> On 06-01-2019 20:01, Adrian Bunk wrote:
> >> That is because gmsh from testing links to libmed1v5. Adding this
> >> *versioned* breaks to libmed11 (albeit being a bit ridiculous from the
> >> archive point of view) would do the right thing AFAICT.
> >> ...
> > 
> > despite libmed11 not being installed at all in the debci test?
> 
> britney reads this to determine which packages (based on SRC) need to
> come from unstable for testing in testing.
> 
> > You are saying that the (test) dependencies of gmsh/unstable matter when
> > testing gmsh/testing with med-fichier/unstable?
> 
> Yes, because they are processed by britney. So if gmsh/testing and
> med-fichier/unstable aren't a good match based on information that
> britney has available, it will request the test with both from unstable.
> britney looks at the regular Depends/Breaks/Conflicts fields as well as
> the test dependencies.
> 
> > That's unexpected compared to the normal dependency semantics.
> 
> I agree, but this is how it is done now until we change it. We're open
> for suggestions and I assume the release team is open for patches as well.

when there is a reason for a maintainer to declare that a new upload 
breaks the autopkgtest only of a reverse dependency, the logical
way would be someting like
  X-Breaks-Autopkgtest-Of: gmsh (<< 3.0.6+dfsg1-4+b1)

This would be a proper interface for maintainers that doesn't expose 
whatever black magic britney+debci are doing.

> >>> The root problem is that debci installs cruft packages from unstable.
> >>
> >> Care to elaborate what you mean here? debci doesn't install anything.
> >> It's apt that installs stuff. Based on a slightly odd configuration put
> >> in place by autopkgtest on request of debci which got its trigger from
> >> britney.
> > 
> > Britney says for med-fichier:
> > old binaries left on amd64: libmed1v5, libmedc1v5 (from 4.0.0+repack-1) 
> > (but ignoring cruft, so nevermind)
> > 
> > Installing one of these cruft packages that cannot ever migrate to 
> > testing is the problem.
> 
> Sure, but the root cause is that the combination to test isn't properly
> determined by britney. britney just doesn't know.

Britney says in excuses that the package is cruft.

> > Correct would be that this debci test does not pull in a single package
> > from unstable, since no non-cruft package depended on from gmsh/testing 
> > is being provided by med-fichier/unstable.
> 
> I don't agree. What we want to test is what happens if med-fichier has
> performed the transition from libmed5v1 to libmed11 and we try to move
> the set to testing.

Note that with smooth updates this is not a "set" - it does happen that 
a so-name changing library package migrates to testing before any of the 
reverse dependencies has been rebuilt.

With the new de facto default of 2 days for migrations it is not even rare.

The med-fichier binNMUs were 3 days after med-fichier was uploaded.
Without this debci issue med-fichier would have already migrated
before gmsh was binNMUed in unstable.

> Paul

cu
Adrian

-- 

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

Bug#918505: golang-goprotobuf breaks golang-google-cloud autopkgtest

[Paul Gevers]

Source: golang-goprotobuf, golang-google-cloud
Control: found -1 golang-goprotobuf/1.2.0-1
Control: found -1 golang-google-cloud/0.9.0-7
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of golang-goprotobuf the autopkgtest of
golang-google-cloud fails in testing when that autopkgtest is run with
the binary packages of golang-goprotobuf from unstable. It passes when
run with only packages from testing. In tabular form:
   passfail
golang-goprotobuf  from testing1.2.0-1
golang-google-cloudfrom testing0.9.0-7
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. Interesting,
it talks about references being different than the current output, but I
can't manually spot the difference.

Currently this regression is contributing to the delay of the migration
of golang-goprotobuf (and golang-google-appengine) to testing [1]. Due
to the nature of this issue, I filed this bug report against both
packages. Can you please investigate the situation and reassign the bug
to the right package? If needed, please change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
golang-google-appengine/1.4.0-1. I.e. due to versioned dependencies or
breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=golang-google-appengine

https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-google-cloud/1651974/log.gz

--- FAIL: TestResumeToken (1.00s)
read_test.go:1371: received rows:
[{fields: [name:"Key" type:  name:"Value"
type: ], val: [string_value:"foo-00"
string_value:"bar-00" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-01"
string_value:"bar-01" ]}]
; but want
[{fields: [name:"Key" type:  name:"Value"
type: ], val: [string_value:"foo-00"
string_value:"bar-00" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-01"
string_value:"bar-01" ]}]
read_test.go:1396: received rows:
[{fields: [name:"Key" type:  name:"Value"
type: ], val: [string_value:"foo-00"
string_value:"bar-00" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-01"
string_value:"bar-01" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-02"
string_value:"bar-02" ]}]
, want
[{fields: [name:"Key" type:  name:"Value"
type: ], val: [string_value:"foo-00"
string_value:"bar-00" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-01"
string_value:"bar-01" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-02"
string_value:"bar-02" ]}]
read_test.go:1407: receive rows:
[{fields: [name:"Key" type:  name:"Value"
type: ], val: [string_value:"foo-00"
string_value:"bar-00" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-01"
string_value:"bar-01" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-02"
string_value:"bar-02" ]}]
, want
[{fields: [name:"Key" type:  name:"Value"
type: ], val: [string_value:"foo-00"
string_value:"bar-00" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-01"
string_value:"bar-01" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-02"
string_value:"bar-02" ]}]
read_test.go:1427: received rows:
[{fields: [name:"Key" type:  name:"Value"
type: ], val: [string_value:"foo-00"
string_value:"bar-00" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-01"
string_value:"bar-01" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-02"
string_value:"bar-02" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-03"
string_value:"bar-03" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-04"
string_value:"bar-04" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-05"
string_value:"bar-05" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-06"
string_value:"bar-06" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-07"
string_value:"bar-07" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-08"
string_value:"bar-08" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-09"
string_value:"bar-09" ]} {fields: [name:"Key" type:
name:"Value" type: ], val: [string_value:"foo-10"
string_value:"bar-10" ]} {fields: [name:"Key" type:

Bug#918504: lyx: `lyx --export latex ` outputs loads of errors [patch attached]

[Georges Khaznadar]

Package: lyx
Version: 2.3.2-1
Severity: normal

lyx --export latex someFile.lyx outputs loads of errors, with this pattern:

Traceback (most recent call last):
  File "/usr/share/lyx/scripts/convertDefault.py", line 38, in 
output = output.decode()
AttributeError: 'str' object has no attribute 'decode'

PLease consider applying the attached patch, which fixes those errors.



-- System Information:
Debian Release: buster/sid
  APT prefers stable
  APT policy: (900, 'stable'), (499, 'testing'), (400, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages lyx depends on:
ii  libc62.28-2
ii  libenchant1c2a   1.6.0-11.1+b1
ii  libgcc1  1:8.2.0-12
ii  libmagic11:5.34-2
ii  libmythes-1.2-0  2:1.2.4-3
ii  libqt5core5a 5.11.2+dfsg-7
ii  libqt5gui5   5.11.2+dfsg-7
ii  libqt5svg5   5.11.2-2
ii  libqt5widgets5   5.11.2+dfsg-7
ii  libstdc++6   8.2.0-12
ii  lyx-common   2.3.2-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages lyx recommends:
ii  dvipng   1.15-1.1
ii  evince [pdf-viewer]  3.30.2-1
ii  fonts-lyx2.3.2-1
ii  ghostscript  9.26~dfsg-0+deb9u2
ii  imagemagick  8:6.9.10.14+dfsg-7
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.14+dfsg-7
ii  okular [pdf-viewer]  4:17.12.2-2.1
ii  poppler-utils0.69.0-2
ii  preview-latex-style  11.91-2
ii  psutils  1.17.dfsg-4
ii  texlive-fonts-recommended2018.20181214-1
ii  texlive-generic-extra2018.20181214-1
ii  texlive-generic-recommended  2018.20181214-1
ii  texlive-latex-extra  2018.20181214-1
ii  texlive-latex-recommended2018.20181214-1
ii  texlive-science  2018.20181214-1

Versions of packages lyx suggests:
pn  chktex  
pn  gnuhtml2latex   
pn  groff   
ii  inkscape0.92.3-7
pn  latex2rtf   
ii  librsvg2-bin2.44.10-1
pn  libtiff-tools   
pn  linuxdoc-tools  
pn  noweb   
pn  rcs 
pn  sgmltools-lite  
ii  tex4ht  20160814-1
ii  texlive-plain-generic [tex4ht]  2018.20181214-1
ii  texlive-xetex   2018.20181214-1
pn  writer2latex
pn  wv  

-- no debconf information
The newest version of Python3 yields str types when one calls os.popen('somme 
command').readline()
So, the test is now to know whether Python is 2 or 3, it is just to know 
whether the output is
of type str or not.

Index: lyx-2.3.2/lib/scripts/convertDefault.py
===
--- lyx-2.3.2.orig/lib/scripts/convertDefault.py
+++ lyx-2.3.2/lib/scripts/convertDefault.py
@@ -19,8 +19,6 @@
 from __future__ import print_function
 import os, re, sys
 
-PY2 = sys.version_info[0] == 2
-
 # We may need some extra options only supported by recent convert versions
 re_version = re.compile(r'^Version:.*ImageMagick\s*(\d*)\.(\d*)\.(\d*).*$')
 # imagemagick 7
@@ -34,7 +32,7 @@ if fout.close() != None:
 fout = os.popen('convert -version 2>&1')
 output = fout.readline()
 fout.close()
-if not PY2:
+if type(output) != str:
 output = output.decode()
 
 version = re_version.match(output)

Bug#918503: glusterfs-common: support files not separated from shared library

[Helmut Grohne]

Package: glusterfs-common
Version: 5.2-1
Severity: serious
Justification: 8.2
Tags: patch
Control: block 881526 by -1

glusterfs-common combines shared libraries with a lot of other files and
even a glusterfs user. Doing so violates the Debian policy section 8.2:

| If your package contains files whose names do not change with each
| change in the library shared object version, you must not put them in
| the shared library package.

It is quite evident that the python module, firewalld integration,
logrotate.d snippet and many other files will not change with an soname
bump. Given that other packages (e.g. fio) link libglusterfs0, it is
evident that libglusterfs0 is not a private shared library. Therefore
glusterfs-common violates a policy must.

The attached patch fixes that. I'm filing it as a separate bug, because
the policy violation is much narrower in scope than #881526 is.

Helmut
diff --minimal -Nru glusterfs-5.2/debian/changelog 
glusterfs-5.2/debian/changelog
--- glusterfs-5.2/debian/changelog  2018-12-27 12:47:15.0 +0100
+++ glusterfs-5.2/debian/changelog  2019-01-06 20:35:15.0 +0100
@@ -1,3 +1,10 @@
+glusterfs (5.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Split out libglusterfs0. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 06 Jan 2019 20:35:15 +0100
+
 glusterfs (5.2-1) unstable; urgency=high
 
   * New upstream release.
diff --minimal -Nru glusterfs-5.2/debian/control glusterfs-5.2/debian/control
--- glusterfs-5.2/debian/control2018-12-27 12:47:15.0 +0100
+++ glusterfs-5.2/debian/control2019-01-06 20:30:43.0 +0100
@@ -82,11 +82,9 @@
  xfsprogs,
  e2fsprogs,
  psmisc
-Conflicts: libglusterfs0,
- libglusterfs-dev
+Conflicts: libglusterfs-dev
 Breaks: glusterfs-server (<< 3.4.0~qa5)
 Replaces: glusterfs-server (<< 3.4.0~qa5),
- libglusterfs0,
  libglusterfs-dev
 Description: GlusterFS common libraries and translator modules
  GlusterFS is a clustered file-system capable of scaling to several
@@ -99,3 +97,22 @@
  .
  This package includes libglusterfs and glusterfs translator modules
  common to both GlusterFS server and client framework.
+
+Package: libglusterfs0
+Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Breaks: glusterfs-common (<< 5.2-1.1)
+Replaces: glusterfs-common (<< 5.2-1.1)
+Description: GlusterFS shared library
+ GlusterFS is a clustered file-system capable of scaling to several
+ petabytes. It aggregates various storage bricks over Infiniband RDMA
+ or TCP/IP interconnect into one large parallel network file
+ system. GlusterFS is one of the most sophisticated file system in
+ terms of features and extensibility. It borrows a powerful concept
+ called Translators from GNU Hurd kernel. Much of the code in GlusterFS
+ is in userspace and easily manageable.
+ .
+ This package contains libglusterfs.
diff --minimal -Nru glusterfs-5.2/debian/glusterfs-common.install 
glusterfs-5.2/debian/glusterfs-common.install
--- glusterfs-5.2/debian/glusterfs-common.install   2018-12-27 
12:47:15.0 +0100
+++ glusterfs-5.2/debian/glusterfs-common.install   2019-01-06 
20:34:11.0 +0100
@@ -3,7 +3,18 @@
 usr/sbin/gluster-mountbroker
 usr/sbin/gf_attach
 usr/sbin/gluster-setgfid2path
-usr/lib/*
+usr/lib/firewalld
+usr/lib/ocf
+usr/lib/python3
+usr/lib/*/glusterfs
+usr/lib/*/*.so
+usr/lib/*/*.la
+usr/lib/*/libgfapi.so.*
+usr/lib/*/libgfchangelog.so.*
+usr/lib/*/libgfdb.so.*
+usr/lib/*/libgfrpc.so.*
+usr/lib/*/libgfxdr.so.*
+usr/lib/*/pkgconfig
 usr/share/doc/glusterfs/glusterfs-mode.el usr/share/emacs/site-lisp/
 usr/share/doc/glusterfs/benchmarking/
 libglusterfs/src/*.h usr/include/glusterfs/
diff --minimal -Nru glusterfs-5.2/debian/glusterfs-common.lintian-overrides 
glusterfs-5.2/debian/glusterfs-common.lintian-overrides
--- glusterfs-5.2/debian/glusterfs-common.lintian-overrides 2018-12-27 
12:47:15.0 +0100
+++ glusterfs-5.2/debian/glusterfs-common.lintian-overrides 2019-01-06 
20:34:46.0 +0100
@@ -1,8 +1,7 @@
 glusterfs-common: spelling-error-in-binary 
usr/lib/*/glusterfs/*/xlator/features/gfid-access.so withthe with the
 glusterfs-common: spelling-error-in-binary 
usr/lib/*/glusterfs/*/xlator/protocol/server.so ofthe of the
 glusterfs-common: spelling-error-in-binary 
usr/lib/*/glusterfs/*/xlator/features/locks.so onthe on the
-glusterfs-common: package-name-doesnt-match-sonames libgfapi0 libgfchangelog0 
libgfdb0 libgfrpc0 libgfxdr0 libglusterfs0
-glusterfs-common: no-symbols-control-file usr/lib/*/libglusterfs.so.0.0.1
+glusterfs-common: package-name-doesnt-match-sonames libgfapi0 libgfchangelog0 
libgfdb0 libgfrpc0 libgfxdr0
 glusterfs-common: no-symbols-control-file usr/lib/*/libgfxdr.so.0.0.1
 glusterfs-common: no-symbols-control-file usr/lib/*/libgfrpc.so.0.0.1
 glusterfs-common: no-symbols-control-file usr/lib/*/libgfchangelog.so.0.0.1
diff --minimal -Nru glusterfs-5.2/debian/libglusterfs0.install 

Bug#918502: golang-github-opencontainers-runtime-tools: autopkgtest needs update for new version of golang-github-hashicorp-go-multierror

[Paul Gevers]

Source: golang-github-opencontainers-runtime-tools
Version: 0.7.0+dfsg-1
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:golang-github-hashicorp-go-multierror

Dear maintainers,

With a recent upload of golang-github-hashicorp-go-multierror the
autopkgtest of golang-github-opencontainers-runtime-tools fails in
testing when that autopkgtest is run with the binary packages of
golang-github-hashicorp-go-multierror from unstable. It passes when run
with only packages from testing. In tabular form:
   passfail
golang-github-hashicorp-go-multierror  from testing1.0.0-1
golang-github-opencontainers-runtime-tools from testing0.7.0+dfsg-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Looking at the
error, it seems you just need to update the reference.

Currently this regression is contributing to the delay of the migration
of golang-github-hashicorp-go-multierror to testing [1]. Of course,
golang-github-hashicorp-go-multierror shouldn't just break your
autopkgtest (or even worse, your package), but it seems to me that the
change in golang-github-hashicorp-go-multierror was intended and your
package needs to update to the new situation. If needed, please change
the bug's severity.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from
golang-github-hashicorp-go-multierror should really add a versioned
Breaks on the unfixed version of (one of your) package(s). Note: the
Breaks is nice even if the issue is only in the autopkgtest as it helps
the migration software to figure out the right versions to combine in
the tests.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
golang-github-hashicorp-go-multierror/1.0.0-1. I.e. due to versioned
dependencies or breaks/conflicts.
[1]
https://qa.debian.org/excuses.php?package=golang-github-hashicorp-go-multierror

https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-github-opencontainers-runtime-tools/1651937/log.gz

--- FAIL: TestCheckMandatoryFields (0.00s)
--- FAIL:
TestCheckMandatoryFields/1_error_occurred:__*_'Spec.Version'_should_not_be_empty
(0.00s)
validate_test.go:759:
Error Trace:validate_test.go:759
Error:  Not equal:
expected: "1 error occurred:\n\n*
'Spec.Version' should not be empty"
actual  : "1 error occurred:\n\t*
'Spec.Version' should not be empty\n\n"

Diff:
--- Expected
+++ Actual
@@ -1,3 +1,4 @@
 1 error occurred:
+   * 'Spec.Version' should not be empty

-* 'Spec.Version' should not be empty
+
Test:
TestCheckMandatoryFields/1_error_occurred:__*_'Spec.Version'_should_not_be_empty
--- FAIL:
TestCheckMandatoryFields/1_error_occurred:__*_Spec_can't_be_nil (0.00s)
validate_test.go:759:
Error Trace:validate_test.go:759
Error:  Not equal:
expected: "1 error occurred:\n\n* Spec can't
be nil"
actual  : "1 error occurred:\n\t* Spec can't
be nil\n\n"

Diff:
--- Expected
+++ Actual
@@ -1,3 +1,4 @@
 1 error occurred:
+   * Spec can't be nil

-* Spec can't be nil
+
Test:
TestCheckMandatoryFields/1_error_occurred:__*_Spec_can't_be_nil
--- PASS: TestCheckMandatoryFields/#00 (0.00s)
--- FAIL:
TestCheckMandatoryFields/1_error_occurred:__*_'Root.Path'_should_not_be_empty
(0.00s)
validate_test.go:759:
Error Trace:validate_test.go:759
Error:  Not equal:
expected: "1 error occurred:\n\n* 'Root.Path'
should not be empty"
actual  : "1 error occurred:\n\t* 'Root.Path'
should not be empty\n\n"

Diff:
--- Expected

Bug#918384: dgit: typo suggestions in man pages

[Ian Jackson]

Paul Hardy writes ("Bug#918384: dgit: typo suggestions in man pages"):
> On Sat, Jan 5, 2019 at 12:18 PM Sean Whitton  wrote:
> > Aren't either acceptable in contemporary English?  ('to' is what I would
> > expect myself to write)
> 
> I'm accustomed to "different from", but I am not a grammarian. :-)
> Whichever you prefer.

I am fine with `different to' and apparently write it myself or at
least read it without noticing.  So I would prefer to retain it.

> > > -Whether to setup a merge driver which uses dpkg-mergechangelogs for
> > > +Whether to set up a merge driver which uses dpkg-mergechangelogs for
> >
> > I think this is wrong.  AIUI, 'setup' is a noun and 'set up' is a verb.
> 
> Right, so it seemed it was being used as a verb; hence "set up".  One
> way or another, everybody will know what is meant of course.

I have a personal tendency to glue words together more than other
people.  I think your (Paul's) analysis of this as a verb is correct
(at least for general contemporary usage) and therefore Sean ought to
agree with you that it should be `set up'.  I am fine with it being
changed.

As for the rest, I agree with Sean's comments.  Paul, would you care
to respin the patch ?  I'm planning an upload soon today but I can
wait a few hours if that would get thwse changes included.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#918438: orig tarball components with uppercase letters

[Ian Jackson]

Mattia Rizzolo writes ("Re: Bug#918438: orig tarball components with uppercase 
letters"):
> We have packages (src:debhelper did for a long time) containing files
> with the same name and only case differences in them (in the case of
> debhelper, it was shipping a 'debian' and a 'Debian' directory).
> Are you say that you really want to go ahead and chase after all such
> things.

Thanks for your attention but I think you may have misunderstood.

Those files you mention are *inside* the source package.  I expect
lots of source packages have that kind of thing going on and getting
rid of it would be impossible even if it were desirable. [1]

The files I am talking about in this bug are the parts *of* the source
package, which must sometimes be transferred through ... other means.
Email attachments (sometimes perforce through awful email systems), cd
images, usb sticks, gatweway machines running weird stuff, filesharing
systems, the laptop of someone next to you at a conference.

> And don't use case insensitive file systems to do UNIX development.
> :)

I agree with this but I don't think it quite addresses my point ?

Thanks,
Ian.

[1] Indeed dgit itself has both Debian/ and debian/ subdirectories.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#918372: unblock: med-fichier/4.0.0+repack-6

[Paul Gevers]

Hi Adrian, Niels,

On 06-01-2019 20:01, Adrian Bunk wrote:
>> That is because gmsh from testing links to libmed1v5. Adding this
>> *versioned* breaks to libmed11 (albeit being a bit ridiculous from the
>> archive point of view) would do the right thing AFAICT.
>> ...
> 
> despite libmed11 not being installed at all in the debci test?

britney reads this to determine which packages (based on SRC) need to
come from unstable for testing in testing.

> You are saying that the (test) dependencies of gmsh/unstable matter when
> testing gmsh/testing with med-fichier/unstable?

Yes, because they are processed by britney. So if gmsh/testing and
med-fichier/unstable aren't a good match based on information that
britney has available, it will request the test with both from unstable.
britney looks at the regular Depends/Breaks/Conflicts fields as well as
the test dependencies.

> That's unexpected compared to the normal dependency semantics.

I agree, but this is how it is done now until we change it. We're open
for suggestions and I assume the release team is open for patches as well.

>>> The root problem is that debci installs cruft packages from unstable.
>>
>> Care to elaborate what you mean here? debci doesn't install anything.
>> It's apt that installs stuff. Based on a slightly odd configuration put
>> in place by autopkgtest on request of debci which got its trigger from
>> britney.
> 
> Britney says for med-fichier:
> old binaries left on amd64: libmed1v5, libmedc1v5 (from 4.0.0+repack-1) (but 
> ignoring cruft, so nevermind)
> 
> Installing one of these cruft packages that cannot ever migrate to 
> testing is the problem.

Sure, but the root cause is that the combination to test isn't properly
determined by britney. britney just doesn't know.

> Correct would be that this debci test does not pull in a single package
> from unstable, since no non-cruft package depended on from gmsh/testing 
> is being provided by med-fichier/unstable.

I don't agree. What we want to test is what happens if med-fichier has
performed the transition from libmed5v1 to libmed11 and we try to move
the set to testing.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#886861: ring: abort with assertion failed: (_gtk_rbtree_is_nil (tree->root))

[Petter Reinholdtsen]

Hi Alexandre,

[Alexandre Viau]
> Are you still getting this issue?

Yes.  It crashed a few seconds ago, when I tried to do a search in the
addresses field.

> There were a number of improvements in regards to gnome client crashes
> in the past months.

Did any of these improvements reach Debian stable?  As far as I can see
here, the ring version is still 20161221.2.7bd7d91~dfsg1-1.

-- 
Happy hacking
Petter Reinholdtsen

Bug#914732: lists.debian.org: Request for new mailing list: debian-dug-muc

[Michael Banck]

Hi,

On Tue, Dec 04, 2018 at 10:07:43PM +0100, Alexander Wirt wrote:
> This request is missing seconders. 

How many more do you need?


Michael

Bug#918501: transition: re2

[Stefano Rivera]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

re2 is a C++ regex library, requiring about a transition a year, for
various symbol changes.

Only 6 reverse dependencies in testing.
The automated ben file looks fine:
https://release.debian.org/transitions/html/auto-re2.html

I've uploaded to experimental and test-built all of the reverse-deps. No
regressions in amd64 buildability of them. Everything that's in testing
rebuilt without patching.

Still waiting for some MIPS*el builds, but those could take weeks... And
not expecting any new FTBFS - I've test-built them on the porterbox.

reportbug ben file:

title = "re3";
is_affected = .depends ~ "libre2-4" | .depends ~ "libre2-5";
is_good = .depends ~ "libre2-5";
is_bad = .depends ~ "libre2-4";

SR

Bug#918179: debci: configure error: undefined method `migrate'

[Paul Gevers]

reassign 918179 src:rails 2:5.2.0+dfsg-2
severity 918179 serious

Hi Scott,

On 04-01-2019 02:31, Scott Talbert wrote:
> I just updated my sid system today and ran into this error:
> 
> Setting up debci (1.14) ...
> Traceback (most recent call last):
>   1: from -e:1:in `'
> /usr/lib/ruby/vendor_ruby/debci/db.rb:18:in `migrate': undefined method 
> `migrate' for ActiveRecord::Migrator:Class (NoMethodError)
> dpkg: error processing package debci (--configure):

The same can be seen in the CI logs [1] for debci (and other packages)
that were triggered for rails/2:5.2.0+dfsg-2 [2]. The issue is caused by
a new version of rails.

Paul

[1]
https://ci.debian.net/data/autopkgtest/testing/amd64/d/debci/1654972/log.gz
[2] https://tracker.debian.org/pkg/rails



signature.asc
Description: OpenPGP digital signature

Bug#918500: duperemove FTCBFS: uses the wrong pkg-config

[Helmut Grohne]

Source: duperemove
Version: 0.11.1-2
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

duperemove fails to cross build from source, because the upstream
Makefile hard codes the build architecture pkg-config. After making it
substitutable, dh_auto_build's substitution takes effect and duperemove
becomes cross buildable. Please consider applying the attached patch.

Helmut
--- duperemove-0.11.1.orig/Makefile
+++ duperemove-0.11.1/Makefile
@@ -2,6 +2,7 @@
 RELEASE=v$(VER)
 
 CC ?= gcc
+PKG_CONFIG ?= pkg-config
 CFLAGS ?= -Wall -ggdb -O2
 
 MANPAGES=duperemove.8 btrfs-extent-same.8 hashstats.8 show-shared-extents.8
@@ -41,10 +42,10 @@
 install_progs = duperemove hashstats btrfs-extent-same show-shared-extents
 progs = $(install_progs) csum-test
 
-glib_CFLAGS=$(shell pkg-config --cflags glib-2.0)
-glib_LIBS=$(shell pkg-config --libs glib-2.0)
-sqlite_CFLAGS=$(shell pkg-config --cflags sqlite3)
-sqlite_LIBS=$(shell pkg-config --libs sqlite3)
+glib_CFLAGS=$(shell $(PKG_CONFIG) --cflags glib-2.0)
+glib_LIBS=$(shell $(PKG_CONFIG) --libs glib-2.0)
+sqlite_CFLAGS=$(shell $(PKG_CONFIG) --cflags sqlite3)
+sqlite_LIBS=$(shell $(PKG_CONFIG) --libs sqlite3)
 
 ifdef DEBUG
 	DEBUG_FLAGS = -ggdb3 -fsanitize=address -fno-omit-frame-pointer	\

Bug#918499: libreoffice: fails with 'ERROR 4 forking process'

[David Zelinsky]

Package: libreoffice
Version: 1:6.1.3-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I'm running "testing", and recently did a dist-upgrade.  Previously
libreoffice worked fine, but now fails to start.  From the menu,
nothing happens.  From command line, it fails with the subject error:

  % libreoffice
  ERROR 4 forking process

Poking around at the symlinks and scripts, it seems it is actually
trying to execute /usr/lib/libreoffice/program/oosplash:

  % /usr/lib/libreoffice/program/oosplash
  ERROR 4 forking process

I tried running with --strace and was surprised to find the
application actually opened and seemed to work normally.  Looking at
the script, with any of the debug options it runs soffice.bin instead
of oosplash, and indeed this works:

  % /usr/lib/libreoffice/program/soffice.bin  # runs normally

I don't know enough about libreoffice to know if any of this is
Debian-specific.  And don't have the wherewithal right now to download
a stock version from libreoffice.com to see if it exhibits the same
problem.

In case it's useful, I'll attache the strace output below.

Thanks.

-David

 begin strace output 

% strace /usr/lib/libreoffice/program/oosplash
execve("/usr/lib/libreoffice/program/oosplash", 
["/usr/lib/libreoffice/program/oos"...], 0x7ffdeaef6480 /* 54 vars */) = 0
brk(NULL)   = 0x55e538c94000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
readlink("/proc/self/exe", "/usr/lib/libreoffice/program/oos"..., 4096) = 37
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/usr/lib/libreoffice/program/tls/x86_64/x86_64/libXinerama.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/libreoffice/program/tls/x86_64/x86_64", 0x7ffe049e3460) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/libreoffice/program/tls/x86_64/libXinerama.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/libreoffice/program/tls/x86_64", 0x7ffe049e3460) = -1 ENOENT (No 
such file or directory)
openat(AT_FDCWD, "/usr/lib/libreoffice/program/tls/x86_64/libXinerama.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/libreoffice/program/tls/x86_64", 0x7ffe049e3460) = -1 ENOENT (No 
such file or directory)
openat(AT_FDCWD, "/usr/lib/libreoffice/program/tls/libXinerama.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/libreoffice/program/tls", 0x7ffe049e3460) = -1 ENOENT (No such 
file or directory)
openat(AT_FDCWD, "/usr/lib/libreoffice/program/x86_64/x86_64/libXinerama.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/libreoffice/program/x86_64/x86_64", 0x7ffe049e3460) = -1 ENOENT 
(No such file or directory)
openat(AT_FDCWD, "/usr/lib/libreoffice/program/x86_64/libXinerama.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/libreoffice/program/x86_64", 0x7ffe049e3460) = -1 ENOENT (No 
such file or directory)
openat(AT_FDCWD, "/usr/lib/libreoffice/program/x86_64/libXinerama.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/libreoffice/program/x86_64", 0x7ffe049e3460) = -1 ENOENT (No 
such file or directory)
openat(AT_FDCWD, "/usr/lib/libreoffice/program/libXinerama.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/libreoffice/program", {st_mode=S_IFDIR|0755, st_size=36864, 
...}) = 0
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=263520, ...}) = 0
mmap(NULL, 263520, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe1f54c
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libXinerama.so.1", 
O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\21\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14496, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fe1f54be000
mmap(NULL, 16680, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe1f54b9000
mmap(0x7fe1f54ba000, 4096, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7fe1f54ba000
mmap(0x7fe1f54bb000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x2000) = 0x7fe1f54bb000
mmap(0x7fe1f54bc000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fe1f54bc000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/libreoffice/program/libX11.so.6", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libX11.so.6", O_RDONLY|O_CLOEXEC) = 
3
read(3,