Bug#911514: davmail: fails to install: wrong update-rc.d usage

2018-11-30 Thread Andreas Beckmann
On 2018-10-30 09:52, Alexandre Rossi wrote:
> Hi Geert,
> 
>> I've prepared updates for the davmail backport and its libhtmlcleaner
>> dependency :
>> https://sml.zincube.net/~niol/tmp/
>>
>> Those are awaiting sponsorship (the process for granting me upload
>> rights also to backports is ongoing).
> 
> Granting me upload rights to the backports archive does not seem to
> move forward. If you have some time to sponsor those uploads, please
> go on.

building the libhtmlcleaner-java backport in stretch fails:

[INFO] Building HtmlCleaner 2.21
[INFO] 
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
htmlcleaner ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/build/libhtmlcleaner-java-2.21/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ htmlcleaner ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ 
htmlcleaner ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 64 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
htmlcleaner ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-surefire-plugin:2.17:test (default-test) @ htmlcleaner ---
[INFO] Surefire report directory: 
/build/libhtmlcleaner-java-2.21/target/surefire-reports

---
 T E S T S
---
Error: Could not find or load main class 
org.apache.maven.surefire.booter.ForkedBooter

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 4.729 s
[INFO] Finished at: 2018-12-01T07:49:40+00:00
[INFO] Final Memory: 12M/365M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on 
project htmlcleaner: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: The forked VM 
terminated without properly saying goodbye. VM crash or System.exit called?
[ERROR] Command was /bin/sh -c cd /build/libhtmlcleaner-java-2.21 && 
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -jar 
/build/libhtmlcleaner-java-2.21/target/surefire/surefirebooter8827901967415424500.jar
 /build/libhtmlcleaner-java-2.21/target/surefire/surefire969640660163927236tmp 
/build/libhtmlcleaner-java-2.21/target/surefire/surefire_02387711883238815967tmp
[ERROR] -> [Help 1]


You may also want to update the devmail backport to the version in testing.


Andreas



Bug#915150: gzip FTBFS: ../../lib/fseeko.c:110:4: error: #error "Please port gnulib fseeko.c to your platform! Look at the code in fseeko.c, then report this to bug-gnulib."

2018-11-30 Thread Helmut Grohne
Control: clone -1 -2
Control: reassign -2 src:m4

On Sat, Dec 01, 2018 at 08:07:23AM +0100, Helmut Grohne wrote:
> gzip fails to build from source in unstable (since the glibc upgrade to
> 2.28):

m4 has another copy of the bug.

Helmut



Bug#915125: libasound2-data: Stretch Regression: alsa.conf.d not provided and breaks crouton audio build

2018-11-30 Thread Elimar Riesebieter
* Mike Fedyk  [2018-11-30 12:44 -0600]:

> Package: libasound2-data
> Version: 1.1.7-1
> Severity: normal
> 
> Hi,
> 
> I can install crouton with audio with stretch by running:
> 
> $ sudo bash ~/Downloads/crouton -r stretch -t audio
> 
> But it fails when I try with testing/buster:
> 
> $ sudo bash ~/Downloads/crouton -r buster -t audio
> 
> Looking into it, it fails on this line:
> 
> https://github.com/dnschneid/crouton/blob/master/targets/audio#L200
> which writes to /usr/share/alsa/alsa.conf.d/10-cras.conf, but that
> directory doesn't exist.

What tells:

$ dpkg -l | egrep "(libasou|alsa)" 

?

Elimar
-- 
  "Talking much about oneself can also
   be a means to conceal oneself."
 -Friedrich Nietzsche


signature.asc
Description: PGP signature


Bug#915150: gzip FTBFS: ../../lib/fseeko.c:110:4: error: #error "Please port gnulib fseeko.c to your platform! Look at the code in fseeko.c, then report this to bug-gnulib."

2018-11-30 Thread Helmut Grohne
Source: gzip
Version: 1.9-2.1
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
Control: clone -1 -2
Control: reassign -2 gnulib
Control: found -2 gnulib/20140202+stable-3
Control: retitle -2 gnulib does not work with glibc/2.28
Control: affects -2 + src:lbzip2

gzip fails to build from source in unstable (since the glibc upgrade to
2.28):

|   CC   fseeko.o
| ../../lib/fseeko.c: In function 'rpl_fseeko':
| ../../lib/fseeko.c:110:4: error: #error "Please port gnulib fseeko.c to your 
platform! Look at the code in fseeko.c, then report this to bug-gnulib."
|#error "Please port gnulib fseeko.c to your platform! Look at the code in 
fseeko.c, then report this to bug-gnulib."
| ^
| make[4]: *** [Makefile:1775: fseeko.o] Error 1
| make[4]: Leaving directory '/<>/builddir/lib'
| make[3]: *** [Makefile:1580: all] Error 2
| make[3]: Leaving directory '/<>/builddir/lib'
| make[2]: *** [Makefile:1746: all-recursive] Error 1
| make[2]: Leaving directory '/<>/builddir'
| make[1]: *** [Makefile:1527: all] Error 2
| make[1]: Leaving directory '/<>/builddir'
| make: *** [debian/rules:96: build-stamp] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

gnulib likes to use this construct to detect glibc:

| #if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, 
Haiku, Linux libc5 */

Unfortunately, _IO_ftrylockfile got removed from glibc/2.28 and
__GNU_LIBRARY__ is 6, so glibc is not a GNU libc.

gnulib has a history of breaking packages frequently. What makes matters
worse is that gnulib gets embedded rather than used like any other
component. So fixing this bug in gnulib does not fix gzip. I therefore
cloned a separate instance as it still breaks e.g. lbzip2.

Helmut



Bug#914814: spades: FTBFS with jemalloc/experimental

2018-11-30 Thread Andreas Tille
Control: tags -1 help

Hi Adam,

On Tue, Nov 27, 2018 at 05:15:48PM +0100, Adam Borowski wrote:
> I'm afraid that your package fails to build with jemalloc 5.1.0-1 (currently
> in experimental).  Transitioning to jemalloc 5 is long overdue, and some
> packages currently carry private copies of jemalloc which does not make the
> security and release teams happy.

Thanks for working on jemalloc update and checking its rdepends.

> Your package is the only RB-Dep that fails to build.

Spades is originally carrying a code copy.  I'm afraid upstream will
give the advise to use the code they are shipping which we want to
avoid.  Could you possibly provide some patch which I could use and
provide to upstream once tested?  Unfortunately I have no idea about
jemalloc.

Thanks again

  Andreas.

-- 
http://fam-tille.de



Bug#915149: figtree: autopkgtest always fails

2018-11-30 Thread Graham Inggs
Source: figtree
Version: 1.4.4-1
User: debian...@lists.debian.org
Usertags: issue

Hi Maintainer

The figtree package includes an autopkgtest, but it seems to have
always failed [1] with the following error:

autopkgtest [18:35:07]: test run-unit-test: [---
/usr/bin/figtree: 3: /usr/bin/figtree: java: not found
autopkgtest [18:35:07]: test run-unit-test: ---]
autopkgtest [18:35:07]: test run-unit-test:  - - - - - - - - - -
results - - - - - - - - - -
run-unit-testFAIL non-zero exit status 127

To me, it seems that the figtree package itself (and not its test
dependencies) is missing a dependency on at least default-jre.

Regards
Graham


[1] https://ci.debian.net/packages/f/figtree/testing/amd64/



Bug#915148: cmake: regression in ros-ros-comm build

2018-11-30 Thread Gianfranco Costamagna
control: affects -1 ros-ros-comm
control: notfound -1 3.12.3-3

fixing tags.

G.



Bug#914688: Default defines discrepancy

2018-11-30 Thread Gianfranco Costamagna
 Hello,
>I don't know how I can help here. Performous only fails on powerpc
>architectures which looks like a Boost bug to me. This only happened
>recently when we switched to 1.67, so maybe forward upstream and let's
>find out what the upstream developers think about that?

the boost patch is now part of the archive, and upstream codebase.I requested a 
give-back of the package, so it should build with no source changes now.
G.
  

Bug#911492: [Debian-med-packaging] Bug#911492: htslib breaks python-pysam autopkgtest

2018-11-30 Thread Graham Inggs
Control: severity -1 serious

Python-pysam in unstable is passing its autopkgtests against htslib
1.9, so all that might be needed here is for libhts2 to declare the
following breaks (or similar):

Breaks: python-pysam (<< 0.15~), python3-pysam (<< 0.15~)



Bug#915079: Potential Fix for Bug

2018-11-30 Thread Rob Gibson
I created a new install of Debian testing in a VM on Virtualbox.  I
installed the Gnome desktop and Audacity, and I installed the source
package for alsa-lib (1.1.7-1).

I then configure the build tools and applied the patch from the ALSA
project against the source and built the binary packages.  After
installation, I opened pavucontrol and Audacity and confirmed that
recording and playback options had Pulse available, and Audacity
displayed in pavucontrol with the ALSA plugin as it had in 1.1.6 and prior.

I recorded audio in Audacity and played it back successfully.

The patch I applied was this:

diff --git a/src/pcm/interval_inline.h b/src/pcm/interval_inline.h
index a68e292..d9a30b2 100644 (file)
--- a/src/pcm/interval_inline.h
+++ b/src/pcm/interval_inline.h
@@ -51,12 +51,14 @@ INTERVAL_INLINE int snd_interval_single(const
snd_interval_t *i)
 {
assert(!snd_interval_empty(i));
return (i->min == i->max ||
-   (i->min + 1 == i->max && i->openmax));
+   (i->min + 1 == i->max && (i->openmin || i->openmax)));
 }

 INTERVAL_INLINE int snd_interval_value(const snd_interval_t *i)
 {
assert(snd_interval_single(i));
+   if (i->openmin && !i->openmax)
+   return i->max;
return i->min;
 }

Rob Gibson

On Fri, 30 Nov 2018 22:05:15 -0500 Rob Gibson  wrote:
> I have rolled back to 1.1.6-1 on my install of testing, but I would
> prefer to upgrade.
> 
> A colleague running Arch filed a bug report over there that appears to
> now be fixed in 1.1.7.
> 
> https://bugs.archlinux.org/task/60591 - Original Issue
> https://bugs.archlinux.org/task/60579 - Detailed Issue Report
> http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=b420056604f06117c967b65d43d01536c5ffcbc9
> - Referenced patch from upstream repository
> 
> I'm not a developer, and I've not attempted to participate in Debian
> package development, but I am willing to try, unless someone else is
> able to perform this testing with more experience than I.
> 
> Rob Gibson
> 
> 



Bug#915088: multipath-tools: installing multipath-tools will force dracut to be removed while it shouldn't.

2018-11-30 Thread Ritesh Raj Sarraf
Hi Olivier,

I am not denying any of what you have said below. Dracut may be a great
tool. But unfortunately, it does not have the uptake in Debian, that
initramfs-tools has. Just look at the popcon stats.

multipath-tools needs tight integration with the plumbing layer to
ensure you have a stackable storage. For Debian, the work so far has
been done integrating it with initramfs-tools.


I am not opposed to adding dracut as an option. It is just that I have
never worked on it. Nor have any users/developers ever reported about
its integration here.

If dracut can serve as a drop-in replacement, I don't have any problem
adding it as an OR dependency in `sg3-utils-udev` package.


On Fri, 2018-11-30 at 16:13 +, LAHAYE Olivier wrote:
> Dracut is the only tool to create initramfs on many distros and it
> works fine with multipath so far. Dracut is to initramfs-tools what
> systemd is to basic initscripts.
> Dracut is modular and event driven while initramfs-tools is
> monolithic and linear static.
> 
> If you look at /usr/lib/dracut/modules.d you'll notice that a module
> already exists for multipathd. (/usr/lib/dracut/modules.d/90multipath
> and /usr/lib/dracut/modules.d/90multipath-hostonly)
> 
> man dracut
> man dracut.modules
> man dracut.cmdline
> 
> See also the module-setup.sh in both 90multipath and 90multipath-
> hostonly modules
> 
> Dracut is really a wonderful piece of code that is really easy to
> understand and that can create really powerful ramfs images.
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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


Bug#840388: fusedav non-functional

2018-11-30 Thread Eric Wong
Carsten Leonhardt  wrote:
> Control: severity -1 grave
> 
> This software appears to be non-functional. A tcpdump confirms that no
> network traffic between the client and the server is being generated.

Fwiw, I have filed many bugfixes against this package years ago
but the maintainer is not responsive.  All my fixes are at, and
I still use it daily (:

git clone https://bogomips.org/fusedav.git

AFAIK, there was one unresolved corner-case with readdirplus
support I never got around to fixing[1], but it works for common
cases with "ls"

[1] https://marc.info/?i=20140609094046.ga1...@dcvr.yhbt.net



Bug#840388: fusedav non-functional

2018-11-30 Thread Eric Wong
Eric Wong  wrote:
> AFAIK, there was one unresolved corner-case with readdirplus
> support I never got around to fixing[1], but it works for common
> cases with "ls"

[1] Sorry, correct URL is:
https://marc.info/?i=CAJfpeguWVhpPkUoTxGrW=kc43rrksjtwoq0ysczl0_oc9jl...@mail.gmail.com
for Miklos's response to my attempted patch.



Bug#915079: Potential Fix for Bug

2018-11-30 Thread Rob Gibson
I have rolled back to 1.1.6-1 on my install of testing, but I would
prefer to upgrade.

A colleague running Arch filed a bug report over there that appears to
now be fixed in 1.1.7.

https://bugs.archlinux.org/task/60591 - Original Issue
https://bugs.archlinux.org/task/60579 - Detailed Issue Report
http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=b420056604f06117c967b65d43d01536c5ffcbc9
- Referenced patch from upstream repository

I'm not a developer, and I've not attempted to participate in Debian
package development, but I am willing to try, unless someone else is
able to perform this testing with more experience than I.

Rob Gibson



Bug#915147: strongswan-charon: apparmor profile should allow writing to /etc/resolv.conf

2018-11-30 Thread Ximin Luo
Package: strongswan-charon
Version: 5.7.1-1
Severity: important
Tags: patch

Dear Maintainer,

If the VPN one is connecting to wants to add additional DNS servers, charon 
needs
write access to /etc/resolv.conf. Otherwise we get an error like the following:

  # ipsec up XXX
  [..]
  IKE_SA XXX{X} established between XXX...YYY
  adding DNS server failed
  adding DNS server failed
  handling INTERNAL_IP4_DNS attribute failed
  installing new virtual IP XXX
  [..]

And in dmesg logs:

  audit: type=1400 audit(NNN): apparmor="DENIED" operation="open" 
profile="/usr/lib/ipsec/charon" name="/etc/resolv.conf" pid=ZZZ comm="charon" 
requested_mask="wc" denied_mask="wc" fsuid=0 ouid=0
  audit: type=1400 audit(NNN): apparmor="DENIED" operation="unlink" 
profile="/usr/lib/ipsec/charon" name="/etc/resolv.conf" pid=ZZZ comm="charon" 
requested_mask="d" denied_mask="d" fsuid=0 ouid=0

Note that the "#include " that already exists in 
charon's profile, is only for *read* access to /etc/resolv.conf, but charon 
really does need write access.

A patch that worked for me was:

--- /etc/apparmor.d/usr.lib.ipsec.charon2018-11-30 19:02:12.585715570 
-0800
+++ /etc/apparmor.d/usr.lib.ipsec.charon2018-11-30 18:50:39.850426475 
-0800
@@ -68,6 +68,8 @@
 
   /var/lib/strongswan/* r,
 
+  /etc/resolv.conf  w,
+
   # Site-specific additions and overrides. See local/README for details.
   #include 
 }

X

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

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

Versions of packages strongswan-charon depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  iproute2   4.18.0-2
ii  libc6  2.27-8
pn  libstrongswan  
pn  strongswan-libcharon   
pn  strongswan-starter 

strongswan-charon recommends no packages.

strongswan-charon suggests no packages.



Bug#737921: WE HAVE REAL PROVIDER OF BG, SBLC, MT103, POF, SKR, DISCOUNTING AND LOANS FOR YOUR PROJECTS.

2018-11-30 Thread LLOYDS BANK PLC
Sir,

We Lloyds Bank Uk provide Loans,BG,SBLC,MTN,POF,LC,SKR
Discounting,Project Funding,Letter of credit, and lots more for client
all over the world.

Equally,we are ready to work with Brokers and financial
consultants/consulting firms in their respective countries.

we are equally ready to pay commission to those Brokers and financial
consultants/consulting firms.

For more information/detail contact us via
E-mail:evans.co...@lloydsbankplc-london.co.uk

Awaiting for your response.

Best Regards.

Advert Team.
Lloyds Bank Plc.
25 Gresham Street, London EC2V 7HN
United Kingdom.



Bug#915146: ioprocess: FTBFS with ld --as-needed

2018-11-30 Thread Logan Rosen
Package: ioprocess
Version: 0.15.1-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear Maintainer,

ioprocess fails to build from source when the ld linker is configured to
use the --as-needed option, which requires that libraries be in a
certain order. This is the default in Ubuntu.

While this isn't strictly necessary in Debian, it puts the libraries in the
right place and will let us avoid having to maintain a delta.

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

  * Merge from Debian unstable. Remaining changes:
- Use LDADD instead of LDFLAGS to fix FTBFS with ld --as-needed.

Thanks for considering the patch.

Logan

-- 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-11-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 ioprocess-0.15.1/debian/patches/ld-as-needed.patch 
ioprocess-0.15.1/debian/patches/ld-as-needed.patch
--- ioprocess-0.15.1/debian/patches/ld-as-needed.patch  1969-12-31 
19:00:00.0 -0500
+++ ioprocess-0.15.1/debian/patches/ld-as-needed.patch  2016-01-31 
23:54:06.0 -0500
@@ -0,0 +1,17 @@
+Description: use LDADD instead of LDFLAGS to fix FTBFS with ld --as-needed
+Author: Logan Rosen 
+Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1304958
+Last-Update: 2016-02-05
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/Makefile.am
 b/src/Makefile.am
+@@ -14,7 +14,7 @@
+  $(IOPROCESS_CFLAGS) \
+  $(AM_CFLAGS) \
+  $(NULL)
+-ioprocess_LDFLAGS = $(GLIB2_LIBS) \
++ioprocess_LDADD = $(GLIB2_LIBS) \
+   $(GTHREAD2_LIBS) \
+   $(YAJL_LIBS) \
+   $(AM_LDFLAGS) \
diff -Nru ioprocess-0.15.1/debian/patches/series 
ioprocess-0.15.1/debian/patches/series
--- ioprocess-0.15.1/debian/patches/series  2016-01-18 10:37:22.0 
-0500
+++ ioprocess-0.15.1/debian/patches/series  2018-07-11 12:57:55.0 
-0400
@@ -1 +1,2 @@
 paths.patch
+ld-as-needed.patch


Bug#914495: linux-image-4.18.0-3-amd64: The system hangs even before the screen font gets smaller. There's just a black screen.

2018-11-30 Thread R S Chakravarti
Package: src:linux
Version: 4.18.20-2
Followup-For: Bug #914495

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation? Booting into linux-image-4.18.0-3-amd64.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? I crashed the system by switching off the power and then 
booted into linux-image-4.18.0-2-amd64.
   * What was the outcome of this action? It works as before.
   * What outcome did you expect instead? I expected it to work.

*** End of the template - remove these template lines ***


-- Package-specific info: 
** Kernel log: boot messages should be attached I'll attach /var/log/kern.log 
if I can find out how to.


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

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

Versions of packages linux-image-4.18.0-3-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.132
ii  kmod25-2
ii  linux-base  4.5

Versions of packages linux-image-4.18.0-3-amd64 recommends:
ii  apparmor 2.13.1-3+b1
ii  firmware-linux-free  3.4
ii  irqbalance   1.5.0-0.1

Versions of packages linux-image-4.18.0-3-amd64 suggests:
ii  debian-kernel-handbook  1.0.19
ii  grub-pc 2.02+dfsg1-8
pn  linux-doc-4.18  

Versions of packages linux-image-4.18.0-3-amd64 is related to:
ii  firmware-amd-graphics 20180825+dfsg-1
ii  firmware-atheros  20180825+dfsg-1
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20180825+dfsg-1
pn  firmware-libertas 
ii  firmware-linux-nonfree20180825+dfsg-1
ii  firmware-misc-nonfree 20180825+dfsg-1
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
ii  firmware-realtek  20180825+dfsg-1
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information



Bug#717563:

2018-11-30 Thread Kay Mccormick
I managed to fix this (at least for the get_bugs case) but it required
changes
to python-debianbts package.

I have included two patches for feedback. There are some caveats:

* Other method calls need to be patched in reportbug/debbugs.py.
* pysimplesoap will use alternatve http transport libraries if httplib2 is
unavailable, and proxy support is unavailable for some of the other
transports such as urllib2.
* reportbug uses urllib2 over httplib2, and pysimplesoap uses httplib2 over
urllib2, but i don't think httplib2 is a dependency of reportbug -
therefore, that must changed also or pysimplesoap wont pick it up.
diff --git a/reportbug/checkversions.py b/reportbug/checkversions.py
index d94bf76..c37399d 100644
--- a/reportbug/checkversions.py
+++ b/reportbug/checkversions.py
@@ -84,7 +84,7 @@ def get_versions_available(package, timeout, dists=None, 
http_proxy=None, arch='
 # or to binary packages available on the current arch
 url += '&a=source,all,' + arch
 try:
-page = open_url(url)
+page = open_url(url, http_proxy, timeout)
 except NoNetwork:
 return {}
 except urllib.error.HTTPError as x:
diff --git a/reportbug/debbugs.py b/reportbug/debbugs.py
index 92db224..c6bd6d0 100644
--- a/reportbug/debbugs.py
+++ b/reportbug/debbugs.py
@@ -1069,6 +1069,13 @@ def get_reports(package, timeout, system='debian', 
mirrors=None, version=None,
 pkg_filter = 'src'
 else:
 pkg_filter = 'package'
+if http_proxy:
+from urllib.parse import urlparse
+parsed_url = urlparse(http_proxy)
+# Probably ought to use more info for the proxy, if applicable.
+debianbts.set_soap_proxy(dict(proxy_host=parsed_url.hostname,
+ proxy_port=parsed_url.port))
+
 bugs = debianbts.get_bugs(pkg_filter, package)
 else:
 bugs = list(map(int, package))
diff --git a/reportbug/urlutils.py b/reportbug/urlutils.py
index c16e48c..a3f2e20 100644
--- a/reportbug/urlutils.py
+++ b/reportbug/urlutils.py
@@ -146,6 +146,7 @@ def open_url(url, http_proxy=None, timeout=60):
 proxies = urllib.request.getproxies()
 if http_proxy:
 proxies['http'] = http_proxy
+proxies['https'] = http_proxy
 
 try:
 page = urlopen(url, proxies, timeout)


debian-bts.patch
Description: Binary data


Bug#915144: Restrict Tar to at least 1.29b for `--verbatim-files-from`

2018-11-30 Thread 殷啟聰 | Kai-Chung Yan
Package: pristine-tar
Version: 1.45
Severity: normal

I was checking out the tarball on Debian/kFreeBSD and got the following error:

```
seamlik@debian:~/Documents/debian/android-platform-system-core$ pristine-tar 
checkout ../android-platform-system-core_8.1.0+r23.orig.tar.xz 
tar: unrecognized option '--verbatim-files-from'
Try 'tar --help' or 'tar --usage' for more information.
pristine-tar: command failed: tar cf 
/tmp/pristine-tar.nwyer_kTay/recreatetarball --owner 0 --group 0 
--numeric-owner -C /tmp/pristine-tar.nwyer_kTay/workdir --no-recursion --mode 
0644 --verbatim-files-from --files-from /tmp/pristine-tar.nwyer_kTay/manifest
pristine-tar: failed to generate tarball
```

And on kFreeBSD Tar is only in 1.28 which does not support 
`--verbatime-files-from`.



signature.asc
Description: OpenPGP digital signature


Bug#911443: raspi3-firmware | Add board-specific firmware files for RPi 3B+ WiFi (!1)

2018-11-30 Thread Stefan Wahren
Hi Matthias,

> Matthias Luescher  hat am 30. November 2018 um 22:20 
> geschrieben:
> 
> 
> Hi Stefan
> 
> > Which RPi 3 variant do you use (B or B+)?
> 
> Today I have tested on the Raspberry Pi 3 B with arm64.

i want to play safe. Could you please check the Rev of your 3 B board? You can 
find it on the upside of the PCB below the GPIO pin header (e.g. i have Rev 
1.2).

> 
> I was able to reproduce it also with kernel 4.19.5. wlan0 remains absent
> with this newer kernel version.
> Based on 4.19.5 I reverted commit b1b8f45b3130dbd8704e5ea0d82b49b1d929498e
> and then wlan0 was back.

Btw the intention of this patch was to enable Wifi. Could you please provide a 
complete dmesg in case wlan0 is absent?

> 
>  > Could you please provide a reduced kernel config?
> 
> Here is more information:
> 
> Kernel configuration:
> https://drive.google.com/open?id=1ZI3MeGB2fkYMsEjzGQYXUk2wqr0h9h7R

Interesting SDHCI and BRCMFMAC are compiled as a module. Maybe this causes the 
issue. I tested today 4.20rc-1 with arm64/defconfig and wlan0 is always there. 
Could you please change your config to:

CONFIG_MMC_SDHCI_IPROC=y

and on the other side i will test your config.

Regards
Stefan

> 
> linux-image-4.19.5-v8_4.19.5-v8-1_arm64.deb (wlan0 is absent):
> https://drive.google.com/open?id=1QCNZcpxeeCBGNb0dsZBBZD9i2Y1kCeib
> 
> dtb with b1b8f45b3130dbd8704e5ea0d82b49b1d929498e reverted (wlan0 is back):
> https://drive.google.com/open?id=11O0c-StAUvV7IXFIs1UBlzeu-CTP3KVt
> 
>  > Is armhf (32 bit) affected, too?
> 
> I think so - but I did not test it yet.
> 
> Best regards
> Matthias



Bug#604078: Project Email

2018-11-30 Thread Lehmann Schulz
Did you receive the project I sent you ?

Bug#915094: Additional information.

2018-11-30 Thread Gong S.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

>Can you tell what version of the kernel you are using?
4.19.0-trunk-amd64. I guess that I am not getting any semblance of support with 
an experimental kernel.
However, when I upgrade from 4.19.0-rc7 to 4.19.0-trunk, the problem is still 
there, so it does not look like a kernel problem.
>How/when did you enable this feature?
Just me poking around options in the man page. I assume that I can save some 
space with small files.
>It looks like you were trying to upgrade some packages when you ran into this 
>issue.
It happened to random processes. It happened to "mandb", "perl" and "chromium" 
most frequently. Sometimes it happens to very basic processes like "ls" or "rm" 
(happened once when I try to remove Chromium's cache folder).
Also, if a process is stuck, the processes will be stuck again if I invoke that 
program again.
--
"And in the naked light, I saw ten thousand people, maybe m\
ore. People talking without speaking, people hearing withou\
t listening. People writing songs that voices never shared,\
no one dared disturb the sound of silence."
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsBcBAEBCAAQBQJcAdSQCRDYtWA5RV10HwAAi6QH/0wsTVCyYWSHzeegbkiz
pKLva43dlXwvd62AbB2CYyzSdytUacGyvk4LOSvAg9FtD0PsK1eayTJ3cQgV
VyIUc7zCLgWA9HXm36HiUoi8hTlkeqa+8Vy/AG0X4pTVIaZPLPyGiUu3yQyM
PCyfGTv9so26v244RQ+FJNQVYdOtE6ajM//570HXHTmb4/GykmHMGIk1iwIH
YDQa+4FlZFNPDo+Gi3Az2IKj+hDYQyZ+spJTs53GWuwu3W02lH3bno2HXYNJ
ciP+jo+l/PIj+8zqIUL4ddUOrBWglj+fJGAVN3YVxs+iKz3VD+IFOFv29eHw
t1NgJ3BV02yAjQNWWo+eOdQ=
=HkKt
-END PGP SIGNATURE-



publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc
Description: application/pgp-keys


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc.sig
Description: PGP signature


Bug#915142: Kicad does not install default plugins

2018-11-30 Thread Tomasz Napierala
Package: kicad
Version: 5.0.1+dfsg1-3~bpo9+1
Severity: normal

Dear Maintainer,

Kicad is not installing default plugins that are included in original
source package, e.g. eeschema/plugins/xsl_scripts/bom2csv.xsl ->
/usr/lib/kicad/plugins/bom2csv.xsl. This is not the case with stable
version 4.x. This way users do not have default BOM plugin, which is
referred in many examples and tutorials. Additionally, some of the
automated tools would also fail.

Note: this report was initially generated from the inside docker container.

ls -alh /usr/lib/kicad/_
_cvpcb.kiface   _eeschema.kiface_gerbview.kiface
_pcb_calculator.kiface  _pcbnew.kiface  _pl_editor.kiface
root@9f514b0ac861:~# ls -alh /usr/lib/kicad/
total 49M
drwxr-xr-x 2 root root 4.0K Nov 13 19:07 .
drwxr-xr-x 1 root root 4.0K Dec  1 00:01 ..
-rw-r--r-- 1 root root 8.7M Nov 11 17:54 _cvpcb.kiface
-rw-r--r-- 1 root root 7.8M Nov 11 17:54 _eeschema.kiface
-rw-r--r-- 1 root root 7.1M Nov 11 17:54 _gerbview.kiface
-rw-r--r-- 1 root root 1.8M Nov 11 17:54 _pcb_calculator.kiface
-rw-r--r-- 1 root root  21M Nov 11 17:54 _pcbnew.kiface
-rw-r--r-- 1 root root 2.4M Nov 11 17:54 _pl_editor.kiface

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

Kernel: Linux 4.9.93-linuxkit-aufs (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages kicad depends on:
ii  libc6 2.24-11+deb9u3
ii  libcairo2 1.14.8-1
ii  libcurl3  7.52.1-5+deb9u8
ii  libfreeimage3 3.17.0+ds1-5
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libglew2.02.0.0-3+b1
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libngspice0   29-1~bpo9+1
ii  liboce-foundation10   0.17.2-2
ii  liboce-modeling10 0.17.2-2
ii  liboce-ocaf-lite100.17.2-2
ii  liboce-ocaf10 0.17.2-2
ii  liboce-visualization100.17.2-2
ii  libpixman-1-0 0.34.0-1
ii  libpython2.7  2.7.13-2+deb9u3
ii  libssl1.1 1.1.0f-3+deb9u2
ii  libstdc++66.3.0-18+deb9u1
ii  libwxbase3.0-0v5  3.0.4+dfsg-4~bpo9+1
ii  libwxgtk3.0-0v5   3.0.4+dfsg-4~bpo9+1
ii  libx11-6  2:1.6.4-3+deb9u1
ii  libxext6  2:1.3.3-1+b2
ii  python2.7.13-2
ii  python-wxgtk3.0   3.0.2.0+dfsg-4

Versions of packages kicad recommends:
pn  kicad-demos  
ii  kicad-libraries  5.0.1+dfsg1-3~bpo9+1
pn  xsltproc 

Versions of packages kicad suggests:
pn  extra-xdg-menus

pn  kicad-doc-ca | kicad-doc-de | kicad-doc-en | kicad-doc-es | kicad-d

pn  kicad-packages3d
 


-- 
Tomasz 'Zen' Napierala
http://napierala.org
JID: tomasz[@]napierala[.]org


Bug#910917: RFA: apache2 -- Apache HTTP Server

2018-11-30 Thread eamanu15
Hello everybody!

I would like help on maintain apache2. I have some experience on packaging
(python projects) but I want to participate on a more complicate package.

I send request to join to the team. Could you please add me?

Thanks!
Regards!


-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest


Bug#906977: parley: diff for NMU version 4:17.08.3-1.1

2018-11-30 Thread gregor herrmann
Control: tags 906977 + pending


Dear maintainer,

I've prepared an NMU for parley (versioned as 4:17.08.3-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  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
   `-   
diff -Nru parley-17.08.3/debian/changelog parley-17.08.3/debian/changelog
--- parley-17.08.3/debian/changelog	2017-12-02 09:33:57.0 +0100
+++ parley-17.08.3/debian/changelog	2018-12-01 00:38:45.0 +0100
@@ -1,3 +1,12 @@
+parley (4:17.08.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "FTBFS in buster/sid ('QItemSelection' does not name a type)":
+add patch from upstream Git repo to fix build with Qt 5.11.
+(Closes: #906977)
+
+ -- gregor herrmann   Sat, 01 Dec 2018 00:38:45 +0100
+
 parley (4:17.08.3-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru parley-17.08.3/debian/patches/qt_5.11.patch parley-17.08.3/debian/patches/qt_5.11.patch
--- parley-17.08.3/debian/patches/qt_5.11.patch	1970-01-01 01:00:00.0 +0100
+++ parley-17.08.3/debian/patches/qt_5.11.patch	2018-12-01 00:38:28.0 +0100
@@ -0,0 +1,70 @@
+From f57328e2ba2074bd9e53794525984447d426c38b Mon Sep 17 00:00:00 2001
+From: Andreas Sturmlechner 
+Date: Sat, 17 Mar 2018 20:18:04 +0100
+Subject: Fix build with Qt 5.11 (missing headers)
+
+Reviewers: #kde_edu, aacid
+
+Reviewed By: aacid
+
+Tags: #kde_edu
+
+Differential Revision: https://phabricator.kde.org/D11428
+---
+ src/dashboard/buttondelegate.cpp  | 1 +
+ src/editor/latexwidget.h  | 1 +
+ src/practice/multiplechoicemodewidget.cpp | 1 +
+ src/statistics/statisticsmainwindow.cpp   | 1 +
+ 4 files changed, 4 insertions(+)
+
+diff --git a/src/dashboard/buttondelegate.cpp b/src/dashboard/buttondelegate.cpp
+index a99dcc3..315f069 100644
+--- a/src/dashboard/buttondelegate.cpp
 b/src/dashboard/buttondelegate.cpp
+@@ -19,6 +19,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+diff --git a/src/editor/latexwidget.h b/src/editor/latexwidget.h
+index 0424e43..e3156b0 100644
+--- a/src/editor/latexwidget.h
 b/src/editor/latexwidget.h
+@@ -16,6 +16,7 @@
+ #include "ui_latexwidget.h"
+ 
+ #include 
++#include 
+ #include 
+ 
+ class QDataWidgetMapper;
+diff --git a/src/practice/multiplechoicemodewidget.cpp b/src/practice/multiplechoicemodewidget.cpp
+index a4eff53..67bd6b5 100644
+--- a/src/practice/multiplechoicemodewidget.cpp
 b/src/practice/multiplechoicemodewidget.cpp
+@@ -18,6 +18,7 @@
+ 
+ #include "ui_practice_widget_multiplechoice.h"
+ 
++#include 
+ #include 
+ #include 
+ #include 
+diff --git a/src/statistics/statisticsmainwindow.cpp b/src/statistics/statisticsmainwindow.cpp
+index 834091c..fe59460 100644
+--- a/src/statistics/statisticsmainwindow.cpp
 b/src/statistics/statisticsmainwindow.cpp
+@@ -16,6 +16,7 @@
+ 
+ #include "statisticsmainwindow.h"
+ 
++#include 
+ #include 
+ 
+ #include 
+-- 
+cgit v0.11.2
+
diff -Nru parley-17.08.3/debian/patches/series parley-17.08.3/debian/patches/series
--- parley-17.08.3/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ parley-17.08.3/debian/patches/series	2018-12-01 00:38:28.0 +0100
@@ -0,0 +1 @@
+qt_5.11.patch


signature.asc
Description: Digital Signature


Bug#915141: RFS: rtags/2.21-1

2018-11-30 Thread Denis Danilov
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: rtags
   Version : 2.21-1
   Upstream Author : Anders Bakken
 * URL : https://github.com/Andersbakken/rtags
 * License : GPL-3+
   Section : devel

It builds those binary packages:

 elpa-ac-rtags - auto-complete back-end for RTags
 elpa-company-rtags - company back-end for RTags
 elpa-flycheck-rtags - flycheck integration for RTags
 elpa-helm-rtags - helm interface for RTags
 elpa-ivy-rtags - ivy back-end for RTags
 elpa-rtags - emacs front-end for RTags
 rtags - C/C++ client/server indexer with integration for Emacs

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

https://mentors.debian.net/package/rtags

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

dget -x https://mentors.debian.net/debian/pool/main/r/rtags/rtags_2.21-1.dsc

Changes since the last upload:

  * New upstream version 2.21
  * rebase patches
  * rename rc and rdm binaries (Closes: #914805)

Regards,
   Denis Danilov



Bug#906187: facter: diff for NMU version 3.11.0-1.1

2018-11-30 Thread gregor herrmann
Control: tags 906187 + patch
Control: tags 906187 + pending


Dear maintainer,

I've prepared an NMU for facter (versioned as 3.11.0-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  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
   `-   
diff -Nru facter-3.11.0/debian/changelog facter-3.11.0/debian/changelog
--- facter-3.11.0/debian/changelog	2018-03-29 12:13:41.0 +0200
+++ facter-3.11.0/debian/changelog	2018-12-01 00:19:32.0 +0100
@@ -1,3 +1,12 @@
+facter (3.11.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "missing Depends: libfacter3.11.0 (= ${binary:Version})":
+add the Depends, as suggested by Andreas Beckmann.
+(Closes: #906187)
+
+ -- gregor herrmann   Sat, 01 Dec 2018 00:19:32 +0100
+
 facter (3.11.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru facter-3.11.0/debian/control facter-3.11.0/debian/control
--- facter-3.11.0/debian/control	2018-03-29 12:13:41.0 +0200
+++ facter-3.11.0/debian/control	2018-12-01 00:16:40.0 +0100
@@ -72,7 +72,7 @@
 Package: facter-dev
 Architecture: any
 Multi-Arch: same
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, libfacter3.11.0 (= ${binary:Version})
 Description: collect and display facts about the system -- development files
  Facter is Puppet’s cross-platform system profiling library. It discovers and
  reports per-node facts, which are collected by the Puppet agent and are made


signature.asc
Description: Digital Signature


Bug#914051: python-freecontact FTBFS with boost 1.67

2018-11-30 Thread Andreas Tille
Control: tags -1 help

On Sun, Nov 18, 2018 at 10:42:22PM +0200, Adrian Bunk wrote:
> /usr/bin/ld: cannot find -lboost_python-py27

It seems libboost_python-py*.so is not provided by libboost > 1.63
since these do not provide any libboost-python package any more.

I have no idea how to work around this.

Kind regards

   Andreas.

-- 
http://fam-tille.de



Bug#915140: brightd: does not start on pinebook/arm64

2018-11-30 Thread Vagrant Cascadian
Package: brightd
Version: 0.4.1-2
Severity: normal

brightd appears to fail to start with the default configuration on
Pinebook (an arm64 laptop).

Trying to start it manually, brightd just displays the help text and
exits:

  $ brightd -v -w 5
  brightd 0.4.1
  A X11-daemon for iBook-like brightness management
  Copyright (c) 2006-2008, Phillip Berndt
  
  Options:
   -vBe verbose
   -dDaemonize
   -P  Create pid file
   -u n  Drop privileges to this user (Defaults to nobody)
   -w n  Wait n seconds before reducing brightness (Defaults to 3)
   -b n  The brightness setting for the dark screen (Defaults zu 0)
   -fReduce brightness even if on the highest brightness level
 Specify twice to also do so when on AC
   -e n  Filter event sources using regexp n (on /dev/input/by-path
   -c n  Set the backlight class to use (defaults to the first
 subnode of /sys/class/backlight)
   -xDon't query X11 Xss extension
   -r n  Create a FIFO, into which acpid may write the new level when the 
user
 changed display brightness

The exit code returned to the shell is 0, so it claims to have worked
correctly.

I've also tried running it as root with the same results, as this said
to be required in /usr/share/doc/brightd/README, though if that's
true, /etc/X11/Xsession.d/90brightd wouldn't possibly work.

/sys/class/backlight/backlight/brightness is writeable by the "video"
group, and the user is present in the "video" group.

The /sys/class/power_supply/AC doesn't exist, but fromt the attached
strace log, it doesn't appear to try to access it. I also built a
locally recompiled version patched hardcoding a different path for the
AC online status, but it behaved the same.

My hunch is some sort of missing assumed dependencies; this device
doesn't have ACPI for example.

live well,
  vagrant



brightd.strace.log
Description: Binary data


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (120, 'unstable'), (1, 
'experimental')
Architecture: arm64 (aarch64)

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

Versions of packages brightd depends on:
ii  libc6 2.27-8
ii  libx11-6  2:1.6.7-1
ii  libxss1   1:1.2.3-1

brightd recommends no packages.

brightd suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature


Bug#909383: xemacs21 stale

2018-11-30 Thread Stefan Hornburg (Racke)
I think the main problem is that xemacs21 is quite stale, latest upstream 
release dating back to 2013.
Thus it doesn't support (string-to-syntax) 

Regards
  Racke

-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.



Bug#914049: progressivemauve FTBFS with boost 1.67

2018-11-30 Thread Andreas Tille
Control: tags -1 help

On Sun, Nov 18, 2018 at 10:36:52PM +0200, Adrian Bunk wrote:
> /usr/include/c++/8/bits/stl_vector.h:1074:7: note: candidate: 'void 
> std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = 
> boost::tuples::tuple std::allocator >, std::vector std::allocator > >; _Alloc = 
> std::allocator int, std::allocator >, std::vector std::allocator > > >; std::vector<_Tp, _Alloc>::value_type 
> = boost::tuples::tuple std::allocator >, std::vector std::allocator > >]'
>push_back(const value_type& __x)
>^
> /usr/include/c++/8/bits/stl_vector.h:1074:7: note:   no known conversion for 
> argument 1 from 'GappedMatchRecord*' to 'const value_type&' {aka 'const 
> boost::tuples::tuple std::allocator >, std::vector std::allocator > >&'}
> /usr/include/c++/8/bits/stl_vector.h:1090:7: note: candidate: 'void 
> std::vector<_Tp, _Alloc>::push_back(std::vector<_Tp, _Alloc>::value_type&&) 
> [with _Tp = boost::tuples::tuple std::allocator >, std::vector std::allocator > >; _Alloc = 
> std::allocator int, std::allocator >, std::vector std::allocator > > >; std::vector<_Tp, _Alloc>::value_type 
> = boost::tuples::tuple std::allocator >, std::vector std::allocator > >]'
>push_back(value_type&& __x)
>^

Any idea how to replace push_back?

Kind regards

   Andreas.

-- 
http://fam-tille.de



Bug#909383: Fails to install

2018-11-30 Thread Stefan Hornburg (Racke)
This even happens on a normal system - looks like it enters an infinite loop:

Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...
Loading 20apel...
Loading 50flim...
Loading 50w3m-el...

Regards from BSP in Bern

   Racke



-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.



Bug#914914: debhelper: Consider setting common full-path variables to prevent reproducible build issues wrt usrmerge

2018-11-30 Thread Andreas Henriksson
Hello Niels,

Thanks for your quick followup.

On Thu, Nov 29, 2018 at 07:31:00AM +, Niels Thykier wrote:
> Hi Andreas,
> 
> Thanks for filing the bug.

Please feel free to wontfix/close this if you feel like it.

[...]
> This seems to still be a "whack-a-mole" strategy; we are just
> centralizing it to debhelper (which does have some merit).

There will for sure always be cases where we need to massage
the package to make it reproducible on usrmerge vs non-merged.
My thought was simply to cat a few cases before they even get
introduced. if possible (and worth it).

[...]
> Honestly, I am conflicted on this.  On one hand, I do not want to
> maintain such a list forever - which I would have if usrmerge will
> remain optional forever.  On the other hand, I can see how this would be
> useful in deflating the current (and future) d-d mail threads about
> usrmerge.
> 
> I will be considering it for now.

I've looked over the 32 (+ 1) cases and my unconfirmed view on them is
that if debhelper passed the following variables to configure:

PS alone fixes 2
GREP alone fixes 1,5 (positively effects 1 more)
CAT alone fixes 1 (positively effects 1 more)
TRUE alone fixes 1
GZIP alone fixes 1 (positively effects 1 more)
SED alone fixes 1 (positively effects 3 more)
ECHO alone fixes 1
MKTEMP alone fixes 1 (positively effects 1 more)

above (MKTEMP SED) plus BASH fixes 1 more
above (GREP SED) plus MKDIR_P fixes 1 more
above (GZIP CAT) plus SH fixes 1 more


Please note: All affected cases seems to either use autoconf or
Makefile.PL build system. I have no idea about perl so only autoconf
are part of above summary. Makefile.PL should be rare enough that it
shouldn't affect things much.

(The GREP -> 1,5 comes from that it fixes 2 but there's another comment
in one of them that is still causes unreproducibility, but that is fixed
by SED so could have said 2...).

I'm not sure what conclusions to draw from this exactly. I'm also not
sure what the reproducible build system staying on 32(+1) found for
a while now means. Has it tested all packages in archive yet or not?
If this is it, then I guess it's absolutely not worth bothering to do
anything in debhelper to handle this


Regards,
Andreas Henriksson



Bug#910882: cups-browsed: The default for UseCUPSGeneratePPDs should be "Yes"

2018-11-30 Thread Till Kamppeter

I have fixed the disappearing queue problem upstream in commit dd862c9b.

What happened is that one cannot reliably determine the temporary nature 
of a CUPS queue via printer-is-temporary. So I check whether the queue 
is shared instead and as any shared queue is permanent I do the 
procedure of setting and unsetting the shared bit on any unshared queue 
as it can be temporary. So with this I am sure that my queue is 
permanent and I do not interrupt the shared status of a shared queue.


   Till



Bug#915139: linux-image-4.18.0-2-amd64: Please set CONFIG_MEMCG_SWAP_ENABLED

2018-11-30 Thread Mikhail Morfikov
Package: src:linux
Version: 4.18.10-2+b1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Some processes in my system need to be limited when it comes to memory
consumption. I wanted to use cgroup v1 along with tools from the cgroup-tools
package to achieve the goal. Everything works well, but the limits can be
applied to RAM only. My machine has also a SWAP partition, and in such case,
when the limit is reached, kernel starts to use SWAP, and it does that without
any control. For instance, if I've set a limit of 1GiB of memory for firefox,
after reaching this limit, all the data would go to SWAP and fill it up slowing
also the system down. There's an option that could prevent this from happening:
CONFIG_MEMCG_SWAP_ENABLED , but it's not set and all the memory.memsw.* files
under /sys/fs/cgroup/memory/ don't exist. Could you set this option?




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlwBsqkACgkQzQRoEHcb
ZSB7JQ/9EY0WKSPpGpnoWhXSOEsKHZHFPHl9Pf8b9OqVyuopFQSHZZ2IidiqUfWO
qgXkU72ZJAwNTQVZPC10HScYuM6y7Us1Q4fLjk6FeLu5E+kttJmvxZt6D0DAM5zi
t4TttDwWIeybT7KF8ST6OcCzs3fq/EqzeL3WINq+QE/1PcMnWgI+4Rp3tj5pYbZH
owdXdN9+d065qIypdrIJHhxJ/ZfCbUonslQPh8En+8ml+tPBNWslpCkx5AFWp/Cw
cdrmqqmY3nEXeQAgy6MfSHhGytD01Fki/BmX9mIE+cAodNTVSz8/1oc+vk2sQRVh
yBnv5uuDmCgh2Fr81/Iz8yOJ5bcf9XTT9oAdHbdQ5FsHgLfdthOC7Y73hNLtoTXH
95gNO9D/iHSzH2U8isq2R57VD9G/TSX79y8jIp3eUmAEXJfJ75qNN7Q4T3R89Z1q
Yq1Qo1WWduy/8nlQNNcay4bAaHuD0qdBqqeQ1BGNhO7VIcVtgxfcd2y0fHx4CpOx
Y2xE3qOlatl2G9GwKHRoDZaciMUfmfc32c/25FstGsys4x9QpsUtNnZc5LISAT36
jiibihHLUA5pj0xbeWet0/ao8JW/hSxyOtiezv8WKwubOd0SO6NG2iAUEHRfei7I
j0ZPF+yGr8MEf24AgHAXYHl/nxwFfJLvmata2eTTlJWcamBjCtU=
=WmNH
-END PGP SIGNATURE-



Bug#914951: 4.19.5 fails to boot as Xen dom0

2018-11-30 Thread Hans van Kranenburg
On 11/29/18 2:38 AM, Hans van Kranenburg wrote:
> On 11/29/18 1:20 AM, Hans van Kranenburg wrote:
>> Package: src:linux
>> Version: 4.19.5-1~exp1
>> Severity: normal
>>
>> Hi,
>>
>> Latest 4.19 upload fails to boot as Xen dom0.
> 
> Copy at
> https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html
> 
> [...]

A fix has been written and tested:

https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03570.html

I tested it on top of 4.19.5-1~exp1.

I expect the first of those two patches (the actual fix) to show up in a
later 4.19.

Hans


Bug#915099: RFP: minetest-mod-rasperrypijam -- Minetest mod - (most of) Raspberry PI Minecraft API

2018-11-30 Thread Petter Reinholdtsen
Petter Reinholdtsen  writes:

> There is an alternative fork of the module on
> https://github.com/sprintingkiwi/pycraft_mod >.  It has seen more
> development the last few years.  Perhaps it is a better alternative?

I made draft packaging of this package available as
https://salsa.debian.org/games-team/unfinished/minetest-mod-pycraft >.

Had to fetch upstream HEAD from git.  Hopefully they will start tagging
releases.  Also, the d/copyright file need more love and care.

The build rules provide one minetest module, and the python library to
talk to the minetest server, alongside many example python scripts to
create and run various features.  The clock.py one was particularly
nice. :)

-- 
Happy hacking
Petter Reinholdtsen



Bug#915138: gimp: complains that "SVG file does not specify a size!"

2018-11-30 Thread Eric Cooper
Package: gimp
Version: 2.10.8-1
Severity: normal

Here is the header of an SVG file that:
(1) displays correctly in programs like inkscape and eog
(2) used to open without problem in earlier versions of Gimp


http://purl.org/dc/elements/1.1/";
   xmlns:cc="http://creativecommons.org/ns#";
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
   xmlns:svg="http://www.w3.org/2000/svg";
   xmlns="http://www.w3.org/2000/svg";
   id="svg9"
   preserveAspectRatio="xMidYMid meet"
   viewBox="0 0 920.0001 161.99292"
   height="202.49115"
   width="1150.0001"
   version="1.0">
  
  
Created by potrace 1.8, written by Peter Selinger 2001-2007

  
image/svg+xml
http://purl.org/dc/dcmitype/StillImage"; />

  

[...]

Gimp no longer recognizes the size.

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

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

Versions of packages gimp depends on:
ii  gimp-data2.10.8-1
ii  libaa1   1.4p5-44+b2
ii  libbabl-0.1-00.1.60-1
ii  libbz2-1.0   1.0.6-9
ii  libc62.27-8
ii  libcairo21.16.0-1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.2.0-9
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libgegl-0.4-00.4.12-1
ii  libgexiv2-2  0.10.8-1
ii  libgimp2.0   2.10.8-1
ii  libglib2.0-0 2.58.1-2
ii  libgs9   9.26~dfsg-1
ii  libgtk2.0-0  2.24.32-3
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b2.1.1-1+b1
ii  libheif1 1.3.2-1+b1
ii  libilmbase23 2.2.1-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  liblzma5 5.2.2-1.3
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2
ii  libopenexr23 2.2.1-4
ii  libopenjp2-7 2.3.0-1
ii  libpango-1.0-0   1.42.4-4
ii  libpangocairo-1.0-0  1.42.4-4
ii  libpangoft2-1.0-01.42.4-4
ii  libpng16-16  1.6.34-2
ii  libpoppler-glib8 0.69.0-2
ii  librsvg2-2   2.44.9-1
ii  libstdc++6   8.2.0-9
ii  libtiff5 4.0.10-3
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libwmf0.2-7  0.2.8.4-14
ii  libx11-6 2:1.6.7-1
ii  libxcursor1  1:1.1.15-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages gimp recommends:
ii  ghostscript  9.26~dfsg-1

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
pn  gimp-python   
pn  gvfs-backends 
ii  libasound21.1.7-1+b1

-- no debconf information



Bug#518254: ganglia-webfrontend: missing README.Debian

2018-11-30 Thread Jochen Hein
Package: ganglia-webfrontend
Followup-For: Bug #518254

Dear Maintainer,

in the current stable distribution we have:

# dpkg -L ganglia-webfrontend | grep README.Debian
/usr/share/doc/ganglia-webfrontend/README.Debian

I suggest closing this bug.

Jochen


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

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

Versions of packages ganglia-webfrontend depends on:
ii  apache2 [httpd-cgi] 2.4.25-3+deb9u6
ii  debconf 1.5.61
ii  libapache2-mod-php  1:7.0+49
ii  libapache2-mod-php7.0 [libapache2-mod-php]  7.0.30-0+deb9u1
ii  php 1:7.0+49
ii  php-xml 1:7.0+49
ii  php7.0 [php]7.0.30-0+deb9u1
ii  php7.0-xml [php-xml]7.0.30-0+deb9u1
ii  rrdtool 1.6.0-1+b2

Versions of packages ganglia-webfrontend recommends:
ii  gmetad  3.6.0-7+b1
ii  php-gd  1:7.0+49
ii  php7.0-gd [php-gd]  7.0.30-0+deb9u1

ganglia-webfrontend suggests no packages.

-- debconf information excluded



Bug#865795: radvd blocks when started over ssh

2018-11-30 Thread Daniel Reichelt
Eversince I opened this bug, I used my own patched package. Only now I
just tried 1:2.17-1~bpo9+1 and can confirm that the bug is no longer
present.

Thanks
Daniel



signature.asc
Description: OpenPGP digital signature


Bug#911443: raspi3-firmware | Add board-specific firmware files for RPi 3B+ WiFi (!1)

2018-11-30 Thread Matthias Luescher
Hi Stefan

> Which RPi 3 variant do you use (B or B+)?

Today I have tested on the Raspberry Pi 3 B with arm64.

I was able to reproduce it also with kernel 4.19.5. wlan0 remains absent
with this newer kernel version.
Based on 4.19.5 I reverted commit b1b8f45b3130dbd8704e5ea0d82b49b1d929498e
and then wlan0 was back.

 > Could you please provide a reduced kernel config?

Here is more information:

Kernel configuration:
https://drive.google.com/open?id=1ZI3MeGB2fkYMsEjzGQYXUk2wqr0h9h7R

linux-image-4.19.5-v8_4.19.5-v8-1_arm64.deb (wlan0 is absent):
https://drive.google.com/open?id=1QCNZcpxeeCBGNb0dsZBBZD9i2Y1kCeib

dtb with b1b8f45b3130dbd8704e5ea0d82b49b1d929498e reverted (wlan0 is back):
https://drive.google.com/open?id=11O0c-StAUvV7IXFIs1UBlzeu-CTP3KVt

 > Is armhf (32 bit) affected, too?

I think so - but I did not test it yet.

Best regards
Matthias


Bug#915136: Push is also not working

2018-11-30 Thread Er_Maqui
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I'm testing about this bug if a new commit resolve the problem. But commit
&& push does not work on the affected repository (i haven't checked other
repositories).

The message on the GIT client are:
BloudFire: maqui$ git push
Enumerando objetos: 17, listo.
Contando objetos: 100% (17/17), listo.
Compresi'on delta usando hasta 8 hilos
Comprimiendo objetos: 100% (9/9), listo.
Escribiendo objetos: 100% (9/9), 858 bytes | 858.00 KiB/s, listo.
Total 9 (delta 8), reusado 0 (delta 0)

remote: GitLab: API is not accessible
To git.example.com:Group/Project.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: fall'o el push de algunas referencias a 'git...@git.example.com:
Group/Project.git'

Error message at production.log are:

GRPC::DeadlineExceeded (4:Deadline Exceeded):

/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0/gems/grpc-1.16.0/src/ruby/lib/grpc/generic/active_call.rb:31:in
`check_status'

/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0/gems/grpc-1.16.0/src/ruby/lib/grpc/generic/active_call.rb:181:in
`attach_status_results_and_complete_call'

/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0/gems/grpc-1.16.0/src/ruby/lib/grpc/generic/active_call.rb:170:in
`receive_and_check_status'

/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0/gems/grpc-1.16.0/src/ruby/lib/grpc/generic/active_call.rb:338:in
`each_remote_read_then_finish'
  /usr/share/gitlab/lib/gitlab/gitaly_client/blob_service.rb:107:in `each'
  /usr/share/gitlab/lib/gitlab/gitaly_client/blob_service.rb:107:in
`flat_map'
  /usr/share/gitlab/lib/gitlab/gitaly_client/blob_service.rb:107:in
`map_lfs_pointers'
  /usr/share/gitlab/lib/gitlab/gitaly_client/blob_service.rb:90:in
`get_new_lfs_pointers'
  /usr/share/gitlab/lib/gitlab/git/lfs_changes.rb:10:in `new_pointers'
  /usr/share/gitlab/lib/gitlab/checks/lfs_integrity.rb:13:in
`objects_missing?'
  /usr/share/gitlab/lib/gitlab/checks/change_access.rb:197:in
`lfs_objects_exist_check'
  /usr/share/gitlab/lib/gitlab/checks/change_access.rb:41:in `exec'
  /usr/share/gitlab/lib/gitlab/git_access.rb:277:in
`check_single_change_access'
  /usr/share/gitlab/lib/gitlab/git_access.rb:265:in `block in
check_change_access!'
  /usr/share/gitlab/lib/gitlab/git_access.rb:260:in `each'
  /usr/share/gitlab/lib/gitlab/git_access.rb:260:in `with_index'
  /usr/share/gitlab/lib/gitlab/git_access.rb:260:in `check_change_access!'
  /usr/share/gitlab/lib/gitlab/git_access.rb:250:in `check_push_access!'
  /usr/share/gitlab/lib/gitlab/git_access.rb:69:in `check'
  /usr/share/gitlab/lib/api/internal.rb:60:in `block (2 levels) in
'
  /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:57:in `call'
  /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:57:in `block (2 levels) in
generate_api_method'
  /usr/lib/ruby/vendor_ruby/active_support/notifications.rb:166:in
`instrument'
  /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:56:in `block in
generate_api_method'
  /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:262:in `block in run'
  /usr/lib/ruby/vendor_ruby/active_support/notifications.rb:166:in
`instrument'
  /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:243:in `run'
  /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:313:in `block in build_stack'
  /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:31:in `call!'
  /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:24:in `call'
  /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:31:in `call!'
  /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:24:in `call'

/usr/share/rubygems-integration/all/gems/rack-oauth2-1.9.2/lib/rack/oauth2/server/resource.rb:20:in
`_call'

/usr/share/rubygems-integration/all/gems/rack-oauth2-1.9.2/lib/rack/oauth2/server/resource/bearer.rb:8:in
`_call'

/usr/share/rubygems-integration/all/gems/rack-oauth2-1.9.2/lib/rack/oauth2/server/abstract/handler.rb:17:in
`call'
  /usr/lib/ruby/vendor_ruby/grape/middleware/error.rb:38:in `block in call!'
  /usr/lib/ruby/vendor_ruby/grape/middleware/error.rb:37:in `catch'
  /usr/lib/ruby/vendor_ruby/grape/middleware/error.rb:37:in `call!'
  /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:24:in `call'

/usr/lib/ruby/vendor_ruby/grape_logging/middleware/request_logger.rb:60:in
`block in call!'

/usr/lib/ruby/vendor_ruby/grape_logging/middleware/request_logger.rb:58:in
`catch'

/usr/lib/ruby/vendor_ruby/grape_logging/middleware/request_logger.rb:58:in
`call!'
  /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:24:in `call'
  /usr/lib/ruby/vendor_ruby/rack/head.rb:13:in `call'
  /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:227:in `call!'
  /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:221:in `call'
  /usr/lib/ruby/vendor_ruby/grape/router/route.rb:72:in `exec'
  /usr/lib/ruby/vendor_ruby/grape/router.rb:121:in `process_route'
  /usr/lib/ruby/vendor_ruby/grape/router.rb:74:in `block in identity'
  /usr/lib/ruby/vendor_ruby/grape/router.rb:93:in `transaction'
  /usr/lib/ruby/vendor_ruby/grape/router.rb:72:in `identity'
  /usr/lib/ruby/vendor_ruby/grape/route

Bug#844321: unison: Please update to latest upstream version

2018-11-30 Thread Daniel Reichelt
Hi,

can we please get the latest upstream version into Buster?

I do realize, there's been a 2.48.4-1 release since I opened this bug.
However, that release is over a year old and upstream has included some
bugfixes since. The current upstream version is 2.48.15.

Thanks,
Daniel



signature.asc
Description: OpenPGP digital signature


Bug#914742: zeroc-ice ftbfs in unstable with Python 3.7

2018-11-30 Thread Jose Gutierrez de la Concha
That is already fixed upstream in
https://github.com/zeroc-ice/ice/commit/4aea9fc787892842af17d119332a7f6fef2f35c4

I will upload a patch

On Mon, Nov 26, 2018 at 10:15 PM Matthias Klose  wrote:

> Package: src:zeroc-ice
> Version: 3.7.1-5
> Severity: serious
> Tags: sid buster patch
>
> zeroc-ice ftbfs in unstable with Python 3.7
>
> x86_64-linux-gnu-g++ -g -O2 -fdebug-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -MT
> modules/IcePy/build/x86_64-linux-gnu/shared/pic/Proxy.o -MMD -MP -MF
> modules/IcePy/build/x86_64-linux-gnu/shared/pic/Proxy.Td -Wall -Wdeprecated
> -Werror -pthread -DNDEBUG -Imodules/IcePy -I../cpp/include
> -I../cpp/include/generated -I../cpp/src -I/usr/include/python3.7m
> -I/usr/include/python3.7m -Wno-unused-result -Wsign-compare -g
> -fdebug-prefix-map=/build/python3.7-0HyDJv/python3.7-3.7.1=.
> -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector -Wformat
> -Werror=format-security -DNDEBUG -g -fwrapv -O3 -Wall -fPIC
> -fvisibility=hidden
> -Wdate-time -D_FORTIFY_SOURCE=2 -c modules/IcePy/Proxy.cpp -o
> modules/IcePy/build/x86_64-linux-gnu/shared/pic/Proxy.o
> modules/IcePy/Communicator.cpp: In function ‘PyObject*
> communicatorWaitForShutdown(IcePy::CommunicatorObject*, PyObject*)’:
> modules/IcePy/Communicator.cpp:475:36: error: comparison of integer
> expressions
> of different signedness: ‘long unsigned int’ and ‘long int’
> [-Werror=sign-compare]
>  if(PyThread_get_thread_ident() == _mainThreadId)
> ^~~~
> cc1plus: all warnings being treated as errors
> make[2]: *** [Makefile:41:
> modules/IcePy/build/x86_64-linux-gnu/shared/pic/Communicator.o] Error 1
> make[2]: *** Waiting for unfinished jobs
>
>
> work around patch available at
> https://patches.ubuntu.com/z/zeroc-ice/zeroc-ice_3.7.1-5ubuntu1.patch
>


-- 
José Gutiérrez de la Concha
ZeroC, Inc.


Bug#915137: mupdf: CVE-2018-19777

2018-11-30 Thread Salvatore Bonaccorso
Source: mupdf
Version: 1.14.0+ds1-2
Severity: important
Tags: security upstream
Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=700301

Hi,

The following vulnerability was published for mupdf.

CVE-2018-19777[0]:
| In Artifex MuPDF 1.14.0, there is an infinite loop in the function
| svg_dev_end_tile in fitz/svg-device.c, as demonstrated by mutool.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-19777
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19777
[1] https://bugs.ghostscript.com/show_bug.cgi?id=700301

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#915136: Gitlab: Error 503 loading some projects

2018-11-30 Thread David L
Package: gitlab
Version: 11.3.10+dfsg-2
Severity: important

Hi,

I'm working with Gitlab 11.3.10, and after a commit & push, I cannot see one of 
my projects.

The error message are:

Started GET "/Group/Project/commits/master" for x.x.x.x at 2018-11-30 21:30:02 
+0100
Processing by Projects::CommitsController#show as HTML
  Parameters: {"namespace_id"=>"Group", "project_id"=>"Project", "id"=>"master"}

Gitlab::Git::CommandError (14:all SubConns are in TransientFailure):
  lib/gitlab/git/repository.rb:1010:in `rescue in wrapped_gitaly_errors'
  lib/gitlab/git/repository.rb:1003:in `wrapped_gitaly_errors'
  lib/gitlab/git/repository.rb:364:in `log'
  lib/gitlab/git/commit.rb:41:in `where'
  app/models/repository.rb:145:in `commits'
  app/controllers/projects/commits_controller.rb:63:in `set_commits'
  lib/gitlab/i18n.rb:53:in `with_locale'
  lib/gitlab/i18n.rb:59:in `with_user_locale'
  app/controllers/application_controller.rb:405:in `set_locale'
  lib/gitlab/middleware/multipart.rb:101:in `call'
  lib/gitlab/request_profiler/middleware.rb:14:in `call'
  lib/gitlab/middleware/go.rb:17:in `call'
  lib/gitlab/etag_caching/middleware.rb:11:in `call'
  lib/gitlab/middleware/read_only/controller.rb:38:in `call'
  lib/gitlab/middleware/read_only.rb:16:in `call'
  lib/gitlab/middleware/basic_health_check.rb:25:in `call'
  lib/gitlab/request_context.rb:18:in `call'
  lib/gitlab/metrics/requests_rack_middleware.rb:27:in `call'
  lib/gitlab/middleware/release_env.rb:10:in `call'

Completed 503 Service Unavailable in 600ms (Views: 277.3ms | ActiveRecord: 
12.2ms)

Same problem appears loading:
  - Project -> Details.
  - Repository -> Files.
  - Repository -> Commits.
  - Repository -> Branches.
  - Repository -> Tags.
  - Repository -> Contributos.
  - Repository -> Graph (with Error 2).
  - Repository -> Charts.

Repository has been working without any problem until a last commit. The commit 
are here:

commit 9827dcf92b7eccdac395697b650bc1ff0f3fadc7 (HEAD -> master, origin/master, 
origin/HEAD)
Merge: a6a31bdea f2a6999a9
Author: author2
Date:   Fri Nov 30 15:04:56 2018 +0100

Merge branch 'master' of git.example.com:Group/Project

commit a6a31bdea50006b4853b73e61c61bf971fc435b5
Author: author2
Date:   Fri Nov 30 15:04:19 2018 +0100

Actualizados los plugins segun el repo


Git commands are working without problem. rake gitlab:check does not report any 
problem. I've triggered repository check from admin interface, and none 
improvement.

Upgrading to gitlab 11.3.11 does not resolve the problem.



Error 2:

Gitlab::Git::CommandError (14:all SubConns are in TransientFailure):
  lib/gitlab/git/repository.rb:1010:in `rescue in wrapped_gitaly_errors'
  lib/gitlab/git/repository.rb:1003:in `wrapped_gitaly_errors'
  lib/gitlab/git/repository.rb:210:in `tags'
  lib/gitlab/git/repository.rb:481:in `refs_hash'
  app/models/repository.rb:486:in `method_missing'
  lib/gitlab/git/commit.rb:398:in `refs'
  lib/gitlab/git/commit.rb:294:in `ref_names'
  app/models/network/commit.rb:17:in `method_missing'
  app/models/network/graph.rb:134:in `include_ref?'
  app/models/network/graph.rb:123:in `block in commits_sort_by_ref'
  app/models/network/graph.rb:122:in `sort'
  app/models/network/graph.rb:122:in `commits_sort_by_ref'
  app/models/network/graph.rb:66:in `index_commits'
  app/models/network/graph.rb:19:in `initialize'
  app/controllers/projects/network_controller.rb:23:in `new'
  app/controllers/projects/network_controller.rb:23:in `block (2 levels) in 
show'
  app/controllers/projects/network_controller.rb:15:in `show'
  lib/gitlab/i18n.rb:53:in `with_locale'
  lib/gitlab/i18n.rb:59:in `with_user_locale'
  app/controllers/application_controller.rb:405:in `set_locale'
  lib/gitlab/middleware/multipart.rb:101:in `call'
  lib/gitlab/request_profiler/middleware.rb:14:in `call'
  lib/gitlab/middleware/go.rb:17:in `call'
  lib/gitlab/etag_caching/middleware.rb:11:in `call'
  lib/gitlab/middleware/read_only/controller.rb:38:in `call'
  lib/gitlab/middleware/read_only.rb:16:in `call'
  lib/gitlab/middleware/basic_health_check.rb:25:in `call'
  lib/gitlab/request_context.rb:18:in `call'
  lib/gitlab/metrics/requests_rack_middleware.rb:27:in `call'
  lib/gitlab/middleware/release_env.rb:10:in `call'



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

Kernel: Linux 4.9.23--grs-ipv6-64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gitlab depends on:
ii  asciidoctor1.5.8-1
ii  bc 1.07.1-2+b1
ii  bundler1.16.1-3
ii  bzip2  1.0.6-9
ii  dbconfig-pgsql 2.0.10
ii  debconf [debconf-2.0]  

Bug#909682: Bug #909682: Memory leak with gst_tag_list_add_id3_image

2018-11-30 Thread Anthony DeRobertis
So, as promised, I've been playing that album again, and it's again 
leaking memory. I tried a few things to get it to free the memory. 
Putting tracks from a different album in the middle didn't do it. 
Neither did deleting the rest of the album from the playlist and playing 
something else (in fact, it continued to leak — just <1MB at a time, 
presumably due to the new album having a single smaller picture). Maybe 
it's also really noticeable because there are 29 large pictures attached 
to each track.


I got a better backtrack from gdb:

Thread 23 "task116" hit Breakpoint 1, 0x7f89dd9fe320 in 
gst_tag_list_add_id3_image () from /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0
(gdb) bt
#0  0x7f89dd9fe320 in gst_tag_list_add_id3_image () at 
/usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0
#1  0x7f8998013b00 in gst_flac_parse_handle_picture (buffer=0x7f88d814bce0, 
flacparse=0x7f891e1c3690 [GstFlacParse])
at /usr/include/gstreamer-1.0/gst/base/gstbytereader.h:651
#2  0x7f8998013b00 in gst_flac_parse_handle_block_type 
(sbuffer=0x7f88d814bce0, type=6, flacparse=0x7f891e1c3690 [GstFlacParse])
at gstflacparse.c:1520
#3  0x7f8998013b00 in gst_flac_parse_parse_frame (frame=0x7f89250505e0, 
frame=0x7f89250505e0, size=301495, parse=0x7f891e1c3690 [GstFlacParse]) at 
gstflacparse.c:1574
#4  0x7f8998013b00 in gst_flac_parse_handle_frame (parse=0x7f891e1c3690 
[GstFlacParse], frame=0x7f89250505e0, skipsize=)
at gstflacparse.c:870
#5  0x7f89dcce46b2 in gst_base_parse_handle_buffer 
(parse=parse@entry=0x7f891e1c3690 [GstFlacParse], buffer=, 
skip=skip@entry=0x7f895fffe75c, flushed=flushed@entry=0x7f895fffe758) at 
gstbaseparse.c:2160
#6  0x7f89dcce4d8f in gst_base_parse_scan_frame (parse=parse@entry=0x7f891e1c3690 
[GstFlacParse], klass=)
at gstbaseparse.c:3464
#7  0x7f89dcce8302 in gst_base_parse_loop (pad=) at 
gstbaseparse.c:3543
#8  0x7f89dcc30f41 in gst_task_func (task=0x7f897c237050 [GstTask]) at 
gsttask.c:332
#9  0x7f89dcdb0ad3 in g_thread_pool_thread_proxy (data=) at 
../../../../glib/gthreadpool.c:307
#10 0x7f89dcdb0135 in g_thread_proxy (data=0x7f8924ffb0f0) at 
../../../../glib/gthread.c:784
#11 0x7f89dd154f2a in start_thread (arg=0x7f895700) at 
pthread_create.c:463
#12 0x7f89db094edf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) c
Continuing.

Looks like its some threaded workpool... I later added a breakpoint on 
pthread_create to try and see where the thread is coming from, and it 
looks like the threads are creating more threads and maybe never 
exiting? This appears to happen every track (the task number goes up by 
two each time; I didn't add the breakpoint on pthread_create in time to 
catch 116 creating 118, probably. Here is 118 creating 120, which then 
goes on to cal gst_tag_list_add_id3_image):


Thread 26 "task118" hit Breakpoint 2, __pthread_create_2_1 
(newthread=newthread@entry=0x7f89004337a0, attr=attr@entry=0x7f89717f5610,
start_routine=start_routine@entry=0x7f89dcdb00e0 , 
arg=arg@entry=0x7f8900433770) at pthread_create.c:610
610 in pthread_create.c
(gdb) bt
#0  0x7f89dd155210 in __pthread_create_2_1 
(newthread=newthread@entry=0x7f89004337a0, attr=attr@entry=0x7f89717f5610, 
start_routine=start_routine@entry=0x7f89dcdb00e0 , 
arg=arg@entry=0x7f8900433770) at pthread_create.c:610
#1  0x7f89dcdce2e0 in g_system_thread_new 
(thread_func=thread_func@entry=0x7f89dcdb00e0 , 
stack_size=stack_size@entry=0, error=error@entry=0x7f89717f56e0) at 
../../../../glib/gthread-posix.c:1177
#2  0x7f89dcdb043f in g_thread_new_internal (name=0x7f89dcde27c2 "pool", 
proxy=0x7f89dcdb00e0 , func=0x7f89dcdb0a60 , 
data=0x7f89b0050780, stack_size=0, error=0x7f89717f56e0) at ../../../../glib/gthread.c:874
#3  0x7f89dcdb07ad in g_thread_pool_start_thread 
(pool=pool@entry=0x7f89b0050780, error=error@entry=0x7f89717f56e0)
at ../../../../glib/gthreadpool.c:407
#4  0x7f89dcdb0da3 in g_thread_pool_start_thread (error=0x7f89717f56e0, 
pool=0x7f89b0050780) at ../../../../glib/gthreadpool.c:552
#5  0x7f89dcdb0da3 in g_thread_pool_push (pool=0x7f89b0050780, 
data=data@entry=0x7f8959f45f20, error=error@entry=0x7f89717f5750)
at ../../../../glib/gthreadpool.c:563
#6  0x7f89dcc31f6a in default_push (pool=0x7f89b0043920 [GstTaskPool], 
func=0x7f89dcc30dc0 , user_data=, 
error=0x7f89717f5750) at gsttaskpool.c:106
#7  0x7f89dcc31b26 in start_task (task=0x7f88e1746710 [GstTask]) at 
gsttask.c:652
#8  0x7f89dcc31b26 in gst_task_set_state (task=task@entry=0x7f88e1746710 
[GstTask], state=state@entry=GST_TASK_STARTED) at gsttask.c:704
#9  0x7f89dcc061bb in gst_pad_start_task (pad=0x7f890f81ac90 [GstPad], 
func=0x7f897056cd80 , user_data=0x7f890f81ac90, 
notify=0x0) at gstpad.c:6169
#10 0x7f89dcc003e6 in gst_pad_set_active (pad=pad@entry=0x7f890f81ac90 
[GstPad], active=1) at gstpad.c:1107
#11 0x7f89dcbde0ad in activate_pads (vpad=, 
ret=0x7f89717f58a0, active=0x7f89717f58fc) at

Bug#915135: exiv2: CVE-2018-19535

2018-11-30 Thread Salvatore Bonaccorso
Source: exiv2
Version: 0.25-4
Severity: important
Tags: patch security upstream
Forwarded: https://github.com/Exiv2/exiv2/issues/428

Hi,

The following vulnerability was published for exiv2.

CVE-2018-19535[0]:
| In Exiv2 0.26 and previous versions, PngChunk::readRawProfile in
| pngchunk_int.cpp may cause a denial of service (application crash due
| to a heap-based buffer over-read) via a crafted PNG file.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-19535
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19535
[1] https://github.com/Exiv2/exiv2/issues/428
[2] https://github.com/Exiv2/exiv2/pull/430

Please adjust the affected versions in the BTS as needed. The
vulnerable code is at least already present in 0.25-4 but I guess
even in stretch version (but not checked).

Regards,
Salvatore



Bug#915007: opensaml2 FTBFS with xmltooling 3

2018-11-30 Thread Sam Hartman
Don't wait for me on shibboleth-resolver or moonshot-gss-eap to file the
removal requests.
They are both basically broken in unstable, so there's no reason to
block.



Bug#849513: d/control: Conflicts can be removed

2018-11-30 Thread Felix Geyer

Hi,

On Mon, 19 Nov 2018 21:40:46 +0100 Mathieu Malaterre  wrote:

While the binary name is a long story, I believe it does not make
sense to continue keeping:

$ cat d/control
...
Conflicts: ninja


Indeed, I'll remove it with the next upload.


With regard to renaming the package:
I really don't think it's worth the trouble of going through NEW, doing the 
transitional
package dance and having all reverse (build-)dependencies updated.

The upstream domain is ninja-build.org, other distros also call it ninja-build 
so
it's not really a surprising name that is hard to find.

Felix



Bug#914948: [Pkg-utopia-maintainers] Bug#914948: Might be a kernel bug

2018-11-30 Thread Michael Biebl
You could try with a kernel from stretch-backports

Am 30. November 2018 19:56:33 MEZ schrieb EP :
>Hello!
>
>https://bugzilla.redhat.com/show_bug.cgi?id=1579046
>
>This bug report and some posts in debianforum.de make me think that it
>is an already fixed kernel bug (fixed in newer kernel versions).
>
>Best wishes
>
>___
>Pkg-utopia-maintainers mailing list
>pkg-utopia-maintain...@alioth-lists.debian.net
>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

2018-11-30 Thread Ansgar Burchardt
On Fri, 2018-11-30 at 19:40 +0100, Didier 'OdyX' Raboud wrote:
> Dear Hideki, dear src:debootstrap maintainers,
> 
> tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by 
> default now, or are you OK letting the TC decide on this subject?

There were discussions about enabling this by default years ago, I
don't think minor issues should be a reason to delay this change.

Note that it has been delayed for after the stretch release as there
were major issues back then (it was enabled by default for a short time
in stretch).  It took >5 months for someone to find a problem this time
which is pretty good for any change.

Ansgar



Bug#915134: exiv2: CVE-2018-19607

2018-11-30 Thread Salvatore Bonaccorso
Source: exiv2
Version: 0.26-1
Severity: grave
Tags: patch security upstream
Justification: user security hole
Forwarded: https://github.com/Exiv2/exiv2/issues/561

Hi,

The following vulnerability was published for exiv2, it only affects
experimental (thus filling as RC severity so does not enter unstable)

CVE-2018-19607[0]:
| Exiv2::isoSpeed in easyaccess.cpp in Exiv2 v0.27-RC2 allows remote
| attackers to cause a denial of service (NULL pointer dereference and
| application crash) via a crafted file.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-19607
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19607
[1] https://github.com/Exiv2/exiv2/issues/561

Regards,
Salvatore



Bug#914355: [Pkg-electronics-devel] Bug#914355: gnucap-python: FTBFS (dh_auto_configure fails)

2018-11-30 Thread Felix Salfelder
On Thu, Nov 22, 2018 at 04:35:20PM +, Santiago Vila wrote:
> Package: src:gnucap-python
> Version: 0.0.0-1
> Severity: serious
> Tags: ftbfs
> 
> Dear maintainer:
> 
> I tried to build this package but it failed:

Thank you.

there's a new package for the 0.0.1 release [1]. the build issue caused
by incomplete python dependencies is fixed. this was one reason for
914355.

i checked with cowbuilder for amd64 and i386. on i386, only the tests
fail due to numerical noise. please advise if that can wait until 0.0.2,
ETA unknown. (i don't think there is a use case for gnucap on i386..)

regards
felix

[1] https://salsa.debian.org/electronics-team/Gnucap/gnucap-python



Bug#914948: Might be a kernel bug

2018-11-30 Thread EP
Hello!

https://bugzilla.redhat.com/show_bug.cgi?id=1579046

This bug report and some posts in debianforum.de make me think that it
is an already fixed kernel bug (fixed in newer kernel versions).

Best wishes



Bug#915122: extra-cmake-modules: FindQHelpGenerator does not work for cross compilation

2018-11-30 Thread Dmitry Shachnev
Hi Helmut!

On Fri, Nov 30, 2018 at 07:23:20PM +0100, Helmut Grohne wrote:
> kconfig fails to cross build from source, because it fails to find
> qhelpgenerator using extra-cmake-modules. The failure is due to a
> combination of assumptions that don't add up. It's not entirely clear
> which of them is wrong so I'm filing the bug with extra-cmake-modules
> now even though it might need a fix elsewhere.
>
> kconfig uses FindQHelpGenerator. FindQHelpGenerator looks up Qt5::qmake.
> Since fixing #913499, qtbase-5-dev supplies
> /usr/lib/$DEB_HOST_MULTIARCH/qt5/bin/qmake, which is a symbolic link to
> /usr/bin/$DEB_HOST_GNU_TYPE-qmake, which is our cross wrapper for qmake.
> Now FindQHelpGenerator.cmake uses the directory part of Qt5::qmake and
> expects to find a qhelpgenerator inside that directory. Unfortunately,
> it doesn't find one. qhelpgenerator is only located in /usr/bin,
> /usr/lib/qt5/bin and /usr/lib/$DEB_BUILD_GNU_TYPE/qt5/bin.
>
> The assumption of FindQHelpGenerator.cmake that the directory of
> Qt5::qmake contains qhelpgenerator is not presently a valid one. I
> cannot tell whether it should be valid or not.

This is fixed upstream in [1]. With that change, FindQHelpGenerator
uses Qt5HelpConfigExtras.cmake which has the correct path:

  set(imported_location "${_qt5Help_install_prefix}/lib/qt5/bin/qhelpgenerator")

However as Qt5HelpConfigExtras.cmake is in qttools5-dev, the affected
packages will need to build-depend on it in order for the fix to work.

That commit will be in 5.53.0 release, to be released on December 8th.

[1]: https://cgit.kde.org/extra-cmake-modules.git/commit/?id=96d169b87292d935

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#888747: keepalived: ip_vs not loading on initial startup

2018-11-30 Thread Alexander Wirt
severity 888747 wishlist
thanks

On Mon, 29 Jan 2018, Thomas Baetzler wrote:

> Package: keepalived
> Version: 1:1.3.2-1
> Severity: important
> 
> Dear Maintainer,
> 
> the required module ip_vs is not automatically loaded on startup which
> prevents keepalived from working after a reboot.
> 
> The service works as expected after a manual "systemctl restart keepalived".
> 
> A workaround is to add the following line to the service definition:
ip_vs is not required to run keepalived. It is perfectly valid to just use
the VRRP part instead of ipvs (in fact most of my customer setups don't use
ipvs). I therefore think its not the best idea to enforce loading of ipvs,
that would lead to problems on systems without ipvs (in the past at least the
debian system admins ran such systems).

Alex



Bug#915127: cloud.debian.org: Please add AWS image for new ARM instances

2018-11-30 Thread Phil Endecott

Noah Meyerhans wrote:

It's on its way.


Glad to hear it, many thanks!



Bug#915133: python-coverage: autopkgtest needs update for new version of python3-defaults

2018-11-30 Thread Paul Gevers
Source: python-coverage
Version: 4.5.1+dfsg.1-1
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python3-defaults

[X-Debbugs-CC: debian...@lists.debian.org,
python3-defau...@packages.debian.org ]

Dear maintainers,

With a recent upload of python3-defaults (that switched the default
python3 from 3.6 to 3.7) the autopkgtest of python-coverage fails in
testing when that autopkgtest is run with the binary packages of
python3-defaults from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
python3-defaults   from testing3.7.1-2
python-coveragefrom testing4.5.1+dfsg.1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. The error
points at the situation where python3.6-minimal is installed, but not
python3.6. However, your autopkgtest uses $(py3versions -i) and assumes
that the zipfile module is installed, while it doesn't make sure that
it is. Your autopkgtest should have a dependency on python3-all if you
want to test all installed python3 versions (py3versions tells which
python3.*-minimal versions are installed).

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

Paul

[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-coverage/1408602/log.gz

autopkgtest [16:09:48]: test smoke-python3: [---
Python command: python3.6
Traceback (most recent call last):
  File "debian/tests/smoke_test.py", line 24, in 
import pkg_resources
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
26, in 
import zipfile
ModuleNotFoundError: No module named 'zipfile'
autopkgtest [16:09:49]: test smoke-python3: ---]



signature.asc
Description: OpenPGP digital signature


Bug#915132: pybitcointools: autopkgtest needs update for new version of python3-defaults

2018-11-30 Thread Paul Gevers
Source: pybitcointools
Version: 1.1.42-1
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python3-defaults

[X-Debbugs-CC: debian...@lists.debian.org,
python3-defau...@packages.debian.org ]

Dear maintainers,

With a recent upload of python3-defaults (that switched the default
python3 from 3.6 to 3.7) the autopkgtest of pybitcointools fails in
testing when that autopkgtest is run with the binary packages of
python3-defaults from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
python3-defaults   from testing3.7.1-2
pybitcointools from testing1.1.42-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. The error
points at the situation where python3.6-minimal is installed, but not
python3.6. However, your autopkgtest uses $(py3versions -i) and assumes
that the zipfile module is installed, while it doesn't make sure that
it is. Your autopkgtest should have a dependency on python3-all if you
want to test all installed python3 versions (py3versions tells which
python3.*-minimal versions are installed).

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

Paul

[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pybitcointools/1408619/log.gz

autopkgtest [16:17:09]: test smoke-python3: [---
Python command: python3.6
Traceback (most recent call last):
  File "debian/tests/smoke_test.py", line 26, in 
import pkg_resources
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
26, in 
import zipfile
ModuleNotFoundError: No module named 'zipfile'
autopkgtest [16:17:10]: test smoke-python3: ---]



signature.asc
Description: OpenPGP digital signature


Bug#890641: udev: fragile handling of uevent actions breaks with kernel 4.12+

2018-11-30 Thread Michael Biebl
Hi,

there is some discussion going on upstream atm at
https://github.com/systemd/systemd/issues/8221
and
https://github.com/systemd/systemd/issues/7587

Your ticket has been closed as not a bug in systemd.
https://github.com/systemd/systemd/issues/8221#issuecomment-443159165

Thought I'd let you know in case you want to chime in and provide your
feedback to the upstream discussion.

I didn't have the time yet to digest this particular information in
those upstream bug reports, but the prospect of declaring all udev rules
files using "positive" add or change events buggy, seems kinda meh.

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



signature.asc
Description: OpenPGP digital signature


Bug#915131: python3-ruamel.yaml: DeprecationWarning: Using or importing the ABCs from 'collections'

2018-11-30 Thread Jakub Wilk

Package: python3-ruamel.yaml
Version: 0.15.34-1+b1
Tags: fixed-upstream
Control: forwarded -1 https://bitbucket.org/ruamel/yaml/issues/210

I get the following warning:

  $ python3 -Wd -c 'import ruamel.yaml'
  /usr/lib/python3/dist-packages/ruamel/yaml/comments.py:14: 
DeprecationWarning: Using or importing the ABCs from 'collections' instead of 
from 'collections.abc' is deprecated, and in 3.8 it will stop working
from collections import MutableSet, Sized, Set

I believe this was fixed upstream in 0.15.46.


-- System Information:
Architecture: i386

Versions of packages python3-ruamel.yaml depends on:
ii  python3  3.7.1-2
ii  libc62.28-1

--
Jakub Wilk



Bug#915130: Further information

2018-11-30 Thread Yannik Sembritzki
I'd like to add the following instructions on how to reproduce the problem:

$ apt purge maria* # if mariadb was installed previously. also select
"remove all mariadb databases" during purging
$ debconf-set-selections <<< "mariadb-server-10.1
mysql-server/root_password password hello"
$ debconf-set-selections <<< "mariadb-server-10.1
mysql-server/root_password_again password hello"
$ debconf-get-selections |grep maria
mariadb-server-10.1    mysql-server/root_password    password    hello
mariadb-server-10.1    mysql-server/root_password_again    password    hello
$ apt install -y mariadb-server-10.1
$mysql mysql <<< "select Host,User,Password,plugin from user;"
Host    User    Password    plugin
localhost    root        unix_socket


Also, the password remains in the debconf database, which is a security
issue:
$ debconf-get-selections |grep maria
mariadb-server-10.1    mysql-server/root_password    password    hello
mariadb-server-10.1    mysql-server/root_password_again    password    hello
mariadb-server-10.1    mariadb-server-10.1/postrm_remove_databases   
boolean    false
mariadb-server-10.1    mariadb-server-10.1/old_data_directory_saved   
note   
mariadb-server-10.1    mariadb-server-10.1/nis_warning    note  

The same is valid when using mariadb-server-10.1/root_password as key:
$ debconf-get-selections |grep maria
mariadb-server-10.1    mariadb-server-10.1/root_password    password   
hello
mariadb-server-10.1    mariadb-server-10.1/root_password_again   
password    hello
mariadb-server-10.1    mariadb-server-10.1/nis_warning    note   
mariadb-server-10.1    mariadb-server-10.1/postrm_remove_databases   
boolean    false
mariadb-server-10.1    mariadb-server-10.1/old_data_directory_saved   
note   



Bug#915127: cloud.debian.org: Please add AWS image for new ARM instances

2018-11-30 Thread Noah Meyerhans
It's on its way. A newer ENA driver is required for working network, so that's 
kind of a blocker.


On November 30, 2018 10:17:06 AM PST, Phil Endecott 
 wrote:
>Package: cloud.debian.org
>Severity: wishlist
>
>Dear Maintainer,
>
>AWS have recently announced new instance types that use the 64-bit ARM 
>(aka aarch64) architecture.  Machine images are currently available for
>
>"Amazon Linux 2", RHEL, Ubuntu and Fedora.  It would be great to also 
>have official Debian images.
>
>
>Many thanks,  Phil.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#915130: mariadb-server-10.1: mariadb ignores debconf value root_password

2018-11-30 Thread Yannik Sembritzki
Package: mariadb-server-10.1
Version: 10.1.37-0+deb9u1
Severity: normal

Dear Maintainer,

it used to be possible to specify a root password pre-installation by
setting the debconf value root_password and root_password again like
this:

debconf-set-selections <<< "mysql-server mysql-server/root_password password 
secret"
debconf-set-selections <<< "mysql-server mysql-server/root_password_again 
password secret"

However, the password is not being set:
+---+--+--+-+
| Host  | User | Password | plugin  |
+---+--+--+-+
| localhost | root |  | unix_socket |
+---+--+--+-+

I have purged all mariadb packages (including mysql database files) before 
trying this.

Using

debconf-set-selections <<< "maria-db-10.1 mysql-server/root_password password 
secret"
debconf-set-selections <<< "maria-db-10.1 mysql-server/root_password_again 
password secret"

does not work either (same results as above).

Instructions regarding the root_password debconf value are still present
in the package control/postinst file, however I have not found out yet
why this functionality is broken in this version.

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

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

Versions of packages mariadb-server-10.1 depends on:
ii  adduser   3.115
ii  debconf [debconf-2.0] 1.5.61
ii  galera-3  25.3.19-2
ii  gawk  1:4.1.4+dfsg-1
ii  init-system-helpers   1.48
ii  iproute2  4.9.0-1+deb9u1
ii  libaio1   0.3.110-3
ii  libc6 2.24-11+deb9u3
ii  libdbi-perl   1.636-1+b1
ii  libpam0g  1.1.8-3.6
ii  libstdc++66.3.0-18+deb9u1
ii  libsystemd0   232-25+deb9u6
ii  lsb-base  9.20161125
ii  lsof  4.89+dfsg-0.1
ii  mariadb-client-10.1   10.1.37-0+deb9u1
ii  mariadb-common10.1.37-0+deb9u1
ii  mariadb-server-core-10.1  10.1.37-0+deb9u1
ii  passwd1:4.4-4.1
ii  perl  5.24.1-3+deb9u5
ii  psmisc22.21-2.1+b2
ii  rsync 3.1.2-1+deb9u1
ii  socat 1.7.3.1-2+deb9u1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages mariadb-server-10.1 recommends:
ii  libhtml-template-perl  2.95-2

-- debconf information:
  mariadb-server-10.1/nis_warning:
  mariadb-server-10.1/old_data_directory_saved:
  mariadb-server-10.1/postrm_remove_databases: false



Bug#897926: Update

2018-11-30 Thread Andrew Brown
It seems like the newest version of Nginx has been compiled with
`--with-compat`.

Just wanted to confirm this, and then if that's the case, this bug can
probably be closed.

Thanks!

-- 
Andrew M. Brown


Bug#915129: Stop using swftools

2018-11-30 Thread Moritz Muehlenhoff
Source: jquery-jplayer
Severity: serious

jquery-jplayer currently depends on swftools for Flash support. swftools
however is orphaned, has frequent security issues, is dead upstream
(as is Flash).

Also, per the package description Flash is entirely a fallback for
browsers which don't support HTML5 video (but those are the norm
today).

Cheers,
Moritz



Bug#915128: Dont't include in buster

2018-11-30 Thread Moritz Muehlenhoff
Source: swftools
Severity: serious

swftools is orphaned for a year, dead upstream and has frequent security
issues. Also, Flash is a thing of the past, so let's drop it from buster
(initially filing this bug to out it out of testing, will also sort out
the removal, which will take longer).

One one rev dep is left in testing (jquery-jplayer), I'll file a separate
bug against it.

Cheers,
Moritz



Bug#907060: linux: ratelimiting hides warnings about uninitialized crng usage

2018-11-30 Thread Daniel Kahn Gillmor
Control: found 907060 4.18.20-2

On Thu 2018-08-23 12:31:29 -0400, Daniel Kahn Gillmor wrote:
> root@test:~# cat /proc/cmdline 
> BOOT_IMAGE=/boot/vmlinuz-4.17.0-3-amd64 
> root=UUID=44659876-4a68-4a3a-b3fa-0403eeb0c6ca
>  ro console=ttyS0,115200n8
> root@test:~# dmesg | tail -n 3
> [2.880287] [drm] Initialized bochs-drm 1.0.0 20130925 for :00:02.0 on 
> minor 0
> [  107.680402] random: crng init done
> [  107.681132] random: 7 urandom warning(s) missed due to ratelimiting
> root@test:~# 

I'm continuing to see this problem on 4.18.20-2 (on multiple platforms,
actually, incluing 4.18.0-3-powerpc-smp, so it's likely to be generic)

i don't understand why the ratelimiting would be hide these useful messages.

  --dkg



Bug#915127: cloud.debian.org: Please add AWS image for new ARM instances

2018-11-30 Thread Phil Endecott
Package: cloud.debian.org
Severity: wishlist

Dear Maintainer,

AWS have recently announced new instance types that use the 64-bit ARM 
(aka aarch64) architecture.  Machine images are currently available for 
"Amazon Linux 2", RHEL, Ubuntu and Fedora.  It would be great to also 
have official Debian images.


Many thanks,  Phil.



Bug#915126: please update treestyletab to Ver.2.6.8 for Mozilla Firefox

2018-11-30 Thread shirish शिरीष
Package: webext-treestyletab
Version: 2.5.4-2
Severity: normal

Dear Maintainer,

Please update to Ver.2.6.8 or at the very least 2.6.0 for mozilla firefox.

Upstream has released updates at
https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/

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

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

webext-treestyletab depends on no packages.

Versions of packages webext-treestyletab recommends:
ii  firefox-esr  60.3.0esr-1

webext-treestyletab suggests no packages.

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8



Bug#915125: libasound2-data: Stretch Regression: alsa.conf.d not provided and breaks crouton audio build

2018-11-30 Thread Mike Fedyk
Package: libasound2-data
Version: 1.1.7-1
Severity: normal

Hi,

I can install crouton with audio with stretch by running:

$ sudo bash ~/Downloads/crouton -r stretch -t audio

But it fails when I try with testing/buster:

$ sudo bash ~/Downloads/crouton -r buster -t audio

Looking into it, it fails on this line:

https://github.com/dnschneid/crouton/blob/master/targets/audio#L200
which writes to /usr/share/alsa/alsa.conf.d/10-cras.conf, but that
directory doesn't exist.

https://github.com/dnschneid/crouton/blob/master/targets/audio#L84
shows that it is installing a minimal set of packages including
libasound2 and libasound2-dev.

Because libasound2-data doesn't provide /usr/share/alsa/alsa.conf.d/
anymore, the write to 10-cras.conf fails there and the crouton install 
fails there because of the error.

Bug 912680 makes libasound2-plugins provide that directory, but its
dependencies are not required to build CRAS, the Crouton Audio Server,
and in the interest of minimal installs, I think libasound2-data should
provide /usr/share/alsa/alsa.conf.d/ as well, or instead.

-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: armhf (armv7l)

Kernel: Linux 3.8.11 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

libasound2-data depends on no packages.

libasound2-data recommends no packages.

Versions of packages libasound2-data suggests:
ii  alsa-utils  1.1.7-1

-- no debconf information



Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

2018-11-30 Thread Didier 'OdyX' Raboud
Dear Hideki, dear src:debootstrap maintainers,

tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by 
default now, or are you OK letting the TC decide on this subject?

Longer version:

As you might be aware, #914897 (initially filed on src:debootstrap) has now 
been reassigned to the Technical Committee.  As, formally, the Maintainer of 
src:debootstrap is "debian-boot@l.d.o and the current Uploaders", I would like 
to make sure that the TC is not going to overrule unnecessarily.

Hideki, if I read the debootstrap history correctly, you enabled "merged /usr" 
by default in debootstrap 1.0.102.  Given the recent discussion in debian-
devel@ (starting at [0]) and on #914897, could you (or anyone speaking as with 
a "debootstrap maintainer" hat on) state if, either of:

* you would be willing to toggle the "merged /usr" default in debootstrap in a
  subsequent upload;
* you maintain that the "merged /usr" default (to yes) is here to stay.

Many thanks in advance for your consideration,

OdyX

[0] https://lists.debian.org/debian-devel/2018/11/msg00354.html

P.S. I'm aware that this might sound formal, or dismissive of Julien's
 statements.  I just _really_ don't want the TC to eventually overrule
 "the debootstrap maintainers" without need.



Bug#915124: xfsprogs: frequent misdetection of atari partition type

2018-11-30 Thread Marc Lehmann
Package: xfsprogs
Version: 4.9.0+nmu1
Severity: minor

Dear Maintainer,

I am currently in the process of changing the underlying encryption
on many devices. This involves copying data off, changing encryption
parameters, copying data back.

Changing the underlying encryption (e.g. from aes-cbc-essiv:sha256 to
aes-xts-plain64) should pretty much randomly scramble the existing data,
and looking at the first blocks, this seems to be the case. However,
mkfs.xfs has roughly a 30% chance here of misdetecting random data as
"atari partition table format" (this seems to increase with the size of
the device, the smallest device I used was 8TB):

   mkfs.xfs: /dev/mapper/nls112-11 appears to contain a partition table (atari).

Which of course is somewhat unsettling :)

Looking at http://drac030.krap.pl/APT_spec.pdf, the block doesn't resemble
an atari partition at all (no APT magic string and so on).

Given the high chance of msidetecting random data for a valid partition, I
think the atari partition table detection code should either be improved
or disabled by default, as it surely generates many more false positives
and true detections.

I haven't investigated this in more detail, but it is possible that the
code only checks wether a partition fits into the disk, and this would be
100% the case with devices >2TB.

Indeed, I can easily reproduce this by running this multiple times:

   lvcreate -n tempbig -L 4.5t vg_nlsb112 # once only of course :)
   dd if=/dev/urandom of=/dev/vg_nlsb112/tempbig bs=4096 count=512
   mkfs.xfs /dev/vg_nlsb112/tempbig

I get a roughly one in seven chance of getting an atari partition table.

-- System Information:
Debian Release: 9.6
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), 
(500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 
'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 4.18.20-041820-generic (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages xfsprogs depends on:
ii  libblkid1 2.29.2-1+deb9u1
ii  libc6 2.27-8
ii  libreadline5  5.2+dfsg-3+b1
ii  libuuid1  2.29.2-1+deb9u1

xfsprogs recommends no packages.

Versions of packages xfsprogs suggests:
ii  acl  2.2.52-3+b1
ii  attr 1:2.4.47-2+b2
pn  quota
ii  xfsdump  3.1.6+nmu2+b1

-- no debconf information



Bug#825970: status?

2018-11-30 Thread Mark Dymek
i see the last commit was back in august. is this stable yet? can it be
used or is active work still being done?


Bug#915123: goaccess: New upstream release 1.3 available

2018-11-30 Thread Clément Hermann
Package: goaccess
Version: 1:1.2-4
Severity: wishlist
Tags: patch

Hi,

There is a new upstreame release of goaccess (1.3).
Since I wanted to test it, I made an updated package myself.

Please check https://salsa.debian.org/debian/goaccess/merge_requests/1
on salsa, review, merge, and upload if it's OK :)

Cheers,

nodens

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

Kernel: Linux 4.18.0-2-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

Versions of packages goaccess depends on:
ii  libbz2-1.01.0.6-9
ii  libc6 2.28-1
ii  libgeoip1 1.6.12-1
ii  libncurses6   6.1+20181013-1
ii  libtinfo6 6.1+20181013-1
ii  libtokyocabinet9  1.4.48-12
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages goaccess recommends:
ii  geoip-database20181108-1
ii  geoip-database-extra  20181108-1

goaccess suggests no packages.

-- no debconf information



Bug#915122: extra-cmake-modules: FindQHelpGenerator does not work for cross compilation

2018-11-30 Thread Helmut Grohne
Package: extra-cmake-modules
Version: 5.51.0-1
File: /usr/share/ECM/find-modules/FindQHelpGenerator.cmake
Control: affects -1 + src:kconfig
User: helm...@debian.org
Usertags: rebootstrap

kconfig fails to cross build from source, because it fails to find
qhelpgenerator using extra-cmake-modules. The failure is due to a
combination of assumptions that don't add up. It's not entirely clear
which of them is wrong so I'm filing the bug with extra-cmake-modules
now even though it might need a fix elsewhere.

kconfig uses FindQHelpGenerator. FindQHelpGenerator looks up Qt5::qmake.
Since fixing #913499, qtbase-5-dev supplies
/usr/lib/$DEB_HOST_MULTIARCH/qt5/bin/qmake, which is a symbolic link to
/usr/bin/$DEB_HOST_GNU_TYPE-qmake, which is our cross wrapper for qmake.
Now FindQHelpGenerator.cmake uses the directory part of Qt5::qmake and
expects to find a qhelpgenerator inside that directory. Unfortunately,
it doesn't find one. qhelpgenerator is only located in /usr/bin,
/usr/lib/qt5/bin and /usr/lib/$DEB_BUILD_GNU_TYPE/qt5/bin.

The assumption of FindQHelpGenerator.cmake that the directory of
Qt5::qmake contains qhelpgenerator is not presently a valid one. I
cannot tell whether it should be valid or not.

If it should be valid, then some qt package should provide an additional
symlink for qhelpgenerator. Otherwise FindQHelpGenerator should use a
different way for finding qhelpgenerator.

I've Cced Dmitry and Lisandro and hope that they'll weigh in on how this
is supposed to work. Then we can figure out where this needs to be fixed
and how.

Thanks for your help

Helmut



Bug#903665: boost1.62: merge request for #903665

2018-11-30 Thread Giovanni Mascellani
control: retitle -1 boost1.67: bali-phy FTBFS on ppc64*
control: reassign -1 src:boost1.67 1.67.0-11

Il 13/11/18 18:34, Frédéric Bonnard ha scritto:
> Hi Giovanni,
> no worries. Thanks for the details, I appreciate your feedback.

Ow, I just uploaded boost1.67, but I forgot about this patch. I am
applying it now to the repository, so that I do not forget next time.

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature


Bug#915109: closed by David Kalnischkies (Re: Bug#915109: apt upgrade needs limit or date cap)

2018-11-30 Thread Roland Hughes
This is not satisfactory.


The bug/lacking feature IS DEFINITELY IN APT.


From: Debian Bug Tracking System 
Sent: Friday, November 30, 2018 11:33:06 AM
To: Roland Hughes
Subject: Bug#915109 closed by David Kalnischkies  (Re: 
Bug#915109: apt upgrade needs limit or date cap)

This is an automatic notification regarding your Bug report
which was filed against the apt package:

#915109: apt upgrade needs limit or date cap

It has been closed by David Kalnischkies .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact David Kalnischkies 
 by
replying to this email.


--
915109: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915109
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems





Disclaimer The information in this email and any attachments may contain 
proprietary and confidential information that is intended for the addressee(s) 
only. If you are not the intended recipient, you are hereby notified that any 
disclosure, copying, distribution, retention or use of the contents of this 
information is prohibited. When addressed to our clients or vendors, any 
information contained in this e-mail or any attachments is subject to the terms 
and conditions in any governing contract. If you have received this e-mail in 
error, please immediately contact the sender and delete the e-mail.


Bug#914332: Debian Bug report logs #914377 - python3: syntax error in rtupdate hook prevents configuration

2018-11-30 Thread Jean-Marc
Pyzo is not compatible with Python-3.7 because using of the reserved word 
'async.
See also Pyzo on github:
https://github.com/pyzo/pyzo/issues/529

Seems to be fixed in Pyzo 4.6.0 and 4.6.1.

This bug should be linked to
https://bugs.debian.org/914332

Jean-Marc 
https://6jf.be/keys/ED863AD1.txt


pgptjrKz6jaHa.pgp
Description: PGP signature


Bug#915099: RFP: minetest-mod-rasperrypijam -- Minetest mod - (most of) Raspberry PI Minecraft API

2018-11-30 Thread Petter Reinholdtsen


There is an alternative fork of the module on
https://github.com/sprintingkiwi/pycraft_mod >.  It has seen more
development the last few years.  Perhaps it is a better alternative?

I tested it, and it work great. :)

-- 
Happy hacking
Petter Reinholdtsen



Bug#910764: openjfx: segmentation fault in GtkNativeMainLoopThread

2018-11-30 Thread Markus Koschany
Am 30.11.18 um 18:21 schrieb Hans Georg Colle:
> Hello Markus,
> could you run your application using xorg instead of the xwayland
> server (i. e. choose "Gnome unter Xorg" in the gdm3 greeter settings
> before logging in), please, and report the result?
> I got the same issue running a JavaFX-UI application with xwayland,
> too, and its doing fine under Gnome/Xorg. So I believe its rather a
> problem concerning xwayland-server than OpenJFX.
> Greetings, Georg

Hello Georg,

I can confirm this issue only happens under Wayland. Upstream tracks the
bug at

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8210411

Regards,

Markus



signature.asc
Description: OpenPGP digital signature


Bug#839591: Update keytab-lilo to work on modern Debian systems

2018-11-30 Thread Raphaël Halimi
Hi,

Here is a refreshed patch (in Git format) to be applied on version 1:24.2-4.

Since it adds a quilt patch, the warnings about white space errors from
git am are normal.

Regards,

-- 
Raphaël Halimi
From 1854cbba093384d44bb670eb8237ece85f52d6e9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Halimi?= 
Date: Sun, 2 Oct 2016 16:14:04 +0200
Subject: [PATCH 1/2] Add patch to fix keytab-lilo.pl

---
 debian/patches/10_fix-keytab-lilo.patch | 45 +
 debian/patches/series   |  1 +
 2 files changed, 46 insertions(+)
 create mode 100644 debian/patches/10_fix-keytab-lilo.patch

diff --git a/debian/patches/10_fix-keytab-lilo.patch b/debian/patches/10_fix-keytab-lilo.patch
new file mode 100644
index 000..343e7b5
--- /dev/null
+++ b/debian/patches/10_fix-keytab-lilo.patch
@@ -0,0 +1,45 @@
+Description: Various fixes for keytab-lilo
+ This patch updates keytab-lilo to work on modern Debian systems:
+   - Support for kbd 2.0.3 format (from Olivier Brunel, see
+ http://www.syslinux.org/archives/2015-December/024690.html)
+   - Use new keymaps ".kmap" extension (from syslinux upstream)
+   - Add headers (from syslinux upstream)
+Author: Raphaël Halimi 
+Origin: other
+Last-Update: 2016-10-02
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/keytab-lilo.pl
 b/keytab-lilo.pl
+@@ -1,4 +1,8 @@
+ #!/usr/bin/perl
++
++eval { use bytes; };
++eval { binmode STDOUT; };
++
+ $DEFAULT_MAP = "us";
+ $DEFAULT_EXT = ".kmap";
+ 
+@@ -6,8 +10,8 @@
+ {
+ print STDERR
+   "usage: $0 [ -p old_code=new_code ] ...\n".
+-  (" "x(8+length $0))."[path]default_layout[.map] ] ".
+-  "[path]kbd_layout[.map]\n";
++  (" "x(8+length $0))."[path]default_layout[.kmap] ] ".
++  "[path]kbd_layout[.kmap]\n";
+ exit 1;
+ }
+ 
+@@ -44,9 +48,9 @@
+ $empty = 1;
+ while () {
+ 	chop;
+-	if (/^(static\s+)?u_short\s+(\S+)_map\[\S*\]\s+=\s+{\s*$/) {
++	if (/^(static\s+)?(u_|unsigned )short\s+(\S+)_map\[\S*\]\s+=\s+{\s*$/) {
+ 	die "active at beginning of map" if defined $current;
+-	$current = $pfx.":".$2;
++	$current = $pfx.":".$3;
+ 	next;
+ 	}
+ 	undef $current if /^};\s*$/;
diff --git a/debian/patches/series b/debian/patches/series
index 69f49c8..39129ad 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -5,3 +5,4 @@
 07_hardening-cflags+cppflags.patch
 08_small-typos-in-manpages.patch
 09_fix-manpage-lilo-conf-5.patch
+10_fix-keytab-lilo.patch
-- 
2.19.1



signature.asc
Description: OpenPGP digital signature


Bug#839596: Please provide keytab-lilo in its own package

2018-11-30 Thread Raphaël Halimi
Hi,

Here is a refreshed patch (in Git format) to be applied on version 1:24.2-4.

Regards,

-- 
Raphaël Halimi
From 93281bc01553c0ec1220abbf7253aa7cde26dd57 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Halimi?= 
Date: Sun, 2 Oct 2016 16:39:58 +0200
Subject: [PATCH 2/2] Split keytab-lilo into its own package

---
 debian/control  | 12 
 debian/keytab-lilo.dirs |  1 +
 debian/keytab-lilo.install  |  1 +
 debian/keytab-lilo.manpages |  1 +
 debian/lilo.install |  1 -
 debian/lilo.manpages|  1 -
 6 files changed, 15 insertions(+), 2 deletions(-)
 create mode 100644 debian/keytab-lilo.dirs
 create mode 100644 debian/keytab-lilo.install
 create mode 100644 debian/keytab-lilo.manpages

diff --git a/debian/control b/debian/control
index 16a9a17..b3653be 100644
--- a/debian/control
+++ b/debian/control
@@ -37,3 +37,15 @@ Description: LInux LOader - Documentation for the classic OS boot loader
  .
  This package contains the old HTML and README documentations of lilo
  version 21.5 (of year 2000).
+
+Package: keytab-lilo
+Architecture: all
+Depends: perl, console-data, ${misc:Depends}
+Description: LInux LOader - compile keytables files for use with LILO
+ You can use LILO to manage your Master Boot Record (with a simple text
+ screen, text menu or colorful splash graphics) or call LILO from other
+ Boot-Loaders to jump-start the Linux kernel.
+ .
+ This package contains the keytab-lilo tool, which is a Perl script that can
+ compile keytable files to use with LILO and other tools (for example SYSLINUX,
+ which uses the same keytable format).
diff --git a/debian/keytab-lilo.dirs b/debian/keytab-lilo.dirs
new file mode 100644
index 000..236670a
--- /dev/null
+++ b/debian/keytab-lilo.dirs
@@ -0,0 +1 @@
+usr/sbin
diff --git a/debian/keytab-lilo.install b/debian/keytab-lilo.install
new file mode 100644
index 000..c7a73f8
--- /dev/null
+++ b/debian/keytab-lilo.install
@@ -0,0 +1 @@
+usr/sbin/keytab-lilo
diff --git a/debian/keytab-lilo.manpages b/debian/keytab-lilo.manpages
new file mode 100644
index 000..b53d61e
--- /dev/null
+++ b/debian/keytab-lilo.manpages
@@ -0,0 +1 @@
+man/keytab-lilo.8
diff --git a/debian/lilo.install b/debian/lilo.install
index fbbeb91..89b5eb1 100644
--- a/debian/lilo.install
+++ b/debian/lilo.install
@@ -1,6 +1,5 @@
 sbin/lilo
 usr/sbin/mkrescue
-usr/sbin/keytab-lilo
 usr/sbin/liloconfig
 usr/sbin/lilo-uuid-diskid
 etc/kernel/post*
diff --git a/debian/lilo.manpages b/debian/lilo.manpages
index 23864c9..2ac0e7e 100644
--- a/debian/lilo.manpages
+++ b/debian/lilo.manpages
@@ -1,4 +1,3 @@
-man/keytab-lilo.8
 man/lilo.8
 man/lilo.conf.5
 man/mkrescue.8
-- 
2.19.1



signature.asc
Description: OpenPGP digital signature


Bug#915094: Processes stuck in "D" state with inline_data feature enabled.

2018-11-30 Thread Theodore Y. Ts'o
This is a kernel bug, not an e2fsprogs bug.

Can you tell what what version of the kernel you are using?

Inline_data is a feature I generally don't recommend using unless you
have a specific reason.  It's not on by default.  How/when did you
enable this feature?  And what were you hoping to achieve by enabling
it?

It looks like you were trying to upgrade some packages when you ran
into this issue.  Was that something you were doing manually?  Are you
automatically running "apt-get upgrade" out of cron?

Regards,

- Ted



Bug#915121: Typo in man page resulting in wrong indentation of several subsections

2018-11-30 Thread Raphaël Halimi
Package: screen
Version: 4.6.2-3
Severity: minor
Tags: patch

Hi,

Here is a patch to fix a nasty typo in the manpage.

In "CUSTOMIZATION" section, the "displays" subsection has an indented
paragraph, but it's not reverted afterwards, making several following
subsections (from "digraph" up to and including "resize") wrongly
indented twice. This small (one line) patch fixes that.

It's in quilt format, with DEP-3 headers.

Regards,

-- 
Raphaël Halimi
Description: Fix a typo in man page resulting in wrong indentation
 In "CUSTOMIZATION" section, the "displays" subsection has an indented
 paragraph, but it's not reverted afterwards, making several following
 subsections (from "digraph" up to and including "resize") wrongly indented
 twice. This small (one line) patch fixes that.
Author: Raphaël Halimi 
Forwarded: no
Last-Update: 2018-11-30
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/doc/screen.1
+++ b/doc/screen.1
@@ -1901,6 +1901,7 @@
 \*QDisplays\*U needs a region size of at least 10 characters wide and 5 
characters high in
 order to display.
 .RE
+.RE
 .TP
 .IR "\fBdigraph\fR " [ preset [ unicode-value ]]
 .RS 0


signature.asc
Description: OpenPGP digital signature


Bug#910764: openjfx: segmentation fault in GtkNativeMainLoopThread

2018-11-30 Thread Hans Georg Colle
Hello Markus,
could you run your application using xorg instead of the xwayland
server (i. e. choose "Gnome unter Xorg" in the gdm3 greeter settings
before logging in), please, and report the result?
I got the same issue running a JavaFX-UI application with xwayland,
too, and its doing fine under Gnome/Xorg. So I believe its rather a
problem concerning xwayland-server than OpenJFX.
Greetings, Georg



Bug#913069: python-uno is also mising in the transition page

2018-11-30 Thread Rene Engelhard
On Fri, Nov 30, 2018 at 02:06:07PM +0100, Eric Valette wrote:
> FYI : The build did succeed for several platform but unfortunately failed for 
> amd64 :-(

Yeah :(

Welcome to experimental ;-)

Builds fine on my system, though. I already did start a build
when you first posted it but then busy with other stuff/RL/unstable

I will upload my hand-build for now to get this fixed.

Yes, that is bad but this is experimental after all and we should get this 
tested
(even when this wouldn't be ready in time for buster which would be "squeezing 
it"
in anyway.)

Regards,

Rene



Bug#915120: shibboleth-sp2 FTBFS with xmltooling 3.0.2

2018-11-30 Thread Adrian Bunk
Source: shibboleth-sp2
Version: 2.6.1+dfsg1-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=shibboleth-sp2&suite=sid

...
SPConfig.cpp: In member function 'virtual bool 
shibsp::SPConfig::instantiate(const char*, bool)':
SPConfig.cpp:427:117: error: no matching function for call to 
'xmltooling::PluginManager, const 
xercesc_3_2::DOMElement*>::newPlugin(const char [4], xercesc_3_2::DOMElement*)'
 
setServiceProvider(ServiceProviderManager.newPlugin(XML_SERVICE_PROVIDER, 
dummydoc->getDocumentElement()));

 ^
In file included from SPConfig.h:38,
 from internal.h:48,
 from SPConfig.cpp:27:
/usr/include/xmltooling/PluginManager.h:97:12: note: candidate: 'T* 
xmltooling::PluginManager::newPlugin(const Key&, const Params&, 
bool) const [with T = shibsp::ServiceProvider; Key = 
std::__cxx11::basic_string; Params = const xercesc_3_2::DOMElement*]'
 T* newPlugin(const Key& type, const Params& p, bool 
deprecationSupport) const {
^
/usr/include/xmltooling/PluginManager.h:97:12: note:   candidate expects 3 
arguments, 2 provided
SPConfig.cpp:439:111: error: no matching function for call to 
'xmltooling::PluginManager, const 
xercesc_3_2::DOMElement*>::newPlugin(const char*, xercesc_3_2::DOMElement*)'
 
setServiceProvider(ServiceProviderManager.newPlugin(type.get(), 
dummydoc->getDocumentElement()));

   ^
In file included from SPConfig.h:38,
 from internal.h:48,
 from SPConfig.cpp:27:
/usr/include/xmltooling/PluginManager.h:97:12: note: candidate: 'T* 
xmltooling::PluginManager::newPlugin(const Key&, const Params&, 
bool) const [with T = shibsp::ServiceProvider; Key = 
std::__cxx11::basic_string; Params = const xercesc_3_2::DOMElement*]'
 T* newPlugin(const Key& type, const Params& p, bool 
deprecationSupport) const {
^
/usr/include/xmltooling/PluginManager.h:97:12: note:   candidate expects 3 
arguments, 2 provided
make[4]: *** [Makefile:2355: libshibsp_la-SPConfig.lo] Error 1



Bug#915119: dpkg-dev: dpkg-shlibdeps erroneously reports "symbol pthread_once used by libdnssec.so.6.0.0 found in none of the libraries"

2018-11-30 Thread Daniel Kahn Gillmor
Package: dpkg-dev
Version: 1.19.2
Severity: normal
Control: affects -1 libdnssec6

libdnssec.so.6.0.0 links against pthread, and uses pthread_once.

but dpkg-shlibdeps complains that it is found in none of the
libraries.

I think this is a bug in dpkg-shlibdeps.  If not, please let me know
what needs to be done to fix libdnssec.so.6.0.0 (feel free to reassign
the bug in that case.

Here's a shell transcript which describes the problem:

0 dkg@alice:~/src/pkg-dns/knot-dns$ dpkg-shlibdeps 
/usr/lib/x86_64-linux-gnu/libdnssec.so.6.0.0
dpkg-shlibdeps: warning: binaries to analyze should already be installed in 
their package's directory
dpkg-shlibdeps: warning: symbol pthread_once used by 
/usr/lib/x86_64-linux-gnu/libdnssec.so.6.0.0 found in none of the libraries
dpkg-shlibdeps: warning: package could avoid a useless dependency if 
/usr/lib/x86_64-linux-gnu/libdnssec.so.6.0.0 was not linked against libm.so.6 
(it uses none of the library's symbols)
0 dkg@alice:~/src/pkg-dns/knot-dns$ awk '($1 ~ /\.so/) { lib=$1 } /^ 
pthread_once@/{print lib ":" $0 }' /var/lib/dpkg/info/*.symbols
libpthread.so.0: pthread_once@GLIBC_2.2.5 2.2.5
libpthread.so.0: pthread_once@GLIBC_2.0 2.0
libpthread.so.0: pthread_once@GLIBC_2.16 2.16
libtsan.so.0: pthread_once@Base 4.9
0 dkg@alice:~/src/pkg-dns/knot-dns$ ldd 
/usr/lib/x86_64-linux-gnu/libdnssec.so.6.0.0  | grep pthread
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f98bd112000)
0 dkg@alice:~/src/pkg-dns/knot-dns$ 


thanks for maintaining dpkg-devscripts!

   --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.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dpkg-dev depends on:
ii  binutils  2.31.1-9
ii  bzip2 1.0.6-9
ii  libdpkg-perl  1.19.2
ii  make  4.2.1-1.2
ii  patch 2.7.6-3
ii  perl  5.28.0-4
ii  tar   1.30+dfsg-3
ii  xz-utils  5.2.2-1.3

Versions of packages dpkg-dev recommends:
ii  build-essential  12.5
ii  clang-4.0 [c-compiler]   1:4.0.1-10+b1
ii  clang-6.0 [c-compiler]   1:6.0.1-9.2
ii  fakeroot 1.23-1
ii  gcc  4:8.2.0-2
ii  gcc-6 [c-compiler]   6.5.0-1
ii  gcc-7 [c-compiler]   7.3.0-30
ii  gcc-8 [c-compiler]   8.2.0-9
ii  gnupg2.2.11-1
ii  gpgv 2.2.11-1
ii  gpgv22.2.11-1
pn  libalgorithm-merge-perl  
ii  tcc [c-compiler] 0.9.27-8

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2018.11.25

-- no debconf information



Bug#915088: multipath-tools: installing multipath-tools will force dracut to be removed while it shouldn't.

2018-11-30 Thread LAHAYE Olivier
Dracut is the only tool to create initramfs on many distros and it works fine 
with multipath so far. Dracut is to initramfs-tools what systemd is to basic 
initscripts.
Dracut is modular and event driven while initramfs-tools is monolithic and 
linear static.

If you look at /usr/lib/dracut/modules.d you'll notice that a module already 
exists for multipathd. (/usr/lib/dracut/modules.d/90multipath and 
/usr/lib/dracut/modules.d/90multipath-hostonly)

man dracut
man dracut.modules
man dracut.cmdline

See also the module-setup.sh in both 90multipath and 90multipath-hostonly 
modules

Dracut is really a wonderful piece of code that is really easy to understand 
and that can create really powerful ramfs images.

Cheers,

Le 30/11/2018 16:01, « Ritesh Raj Sarraf »  a écrit :

On Fri, 2018-11-30 at 09:10 +, Olivier Lahaye wrote:
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>  Installed multipath-tools using:
>  apt-get install --no-install-suggests multipath-tools
> 
>* What was the outcome of this action?
>  dracut was replaced with initramfs-tools because sg3-utils-udev
> is
>  required by multipath-tools and sg3-utils-udev conflicts with
>  dracut
> 
>* What outcome did you expect instead?
>  It should be possible to install multipath-tools and use it with
>  dracut. In other words, it should be possible to do:
>  apt-get install multipath-tools dracut

The problem is that nobody, afaik, has tested the combination of
multipath-tools and dracut together. dracut, afair, claims to be a
drop-in replacement for initramfs-tools. But I am not sure at all.

Right now, multipath-tools has tight integration with initramfs-tools.
Also the sg3-utils-udev package ships in modules to add further
integration.

If dracut can do the equivalent, then we can relax the dependencies.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System




Bug#915099: RFP: minetest-mod-rasperrypijam -- Minetest mod - (most of) Raspberry PI Minecraft API

2018-11-30 Thread Petter Reinholdtsen


Control: retitle -1 RFP: minetest-mod-rasperrypijam -- Minetest mod - (most of) 
Raspberry PI Minecraft API

[Julien Puydt]
> Hi,
>
> is that an ITP? a RFP?

Ah, sorry.  I ment it as a RFP for now.  I do not know enough about
minetest packaging to do it myself.  I joined #debian-games in case you
want to discuss this further.

> I haven't understood what this is about - and I'm not sure my kids
> will need such a mod, so I don't think I'll do anything about it.

It is about integrating minetest with tools to use scripting to create
thinks in minetest.  At least my kids find it very interesting to
program in python and sonic pi to make things happen in Minecraft, and I
would like them to also be able to do the same using minetest.

-- 
Happy hacking
Petter Reinholdtsen



Bug#915118: AppArmor profile is missing 'm' permission

2018-11-30 Thread Julian Andres Klode
Package: postsrsd
Version: 1.4-1
Severity: important

debian-changes removes the 'm' bit from the postsrsd binary, which means
it does not run because that permission was denied.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en



Bug#915116: In debian-9 QEMU 2.8.1 with accel=tcg segfaults when running in big load

2018-11-30 Thread Katerina Koukiou
Package: qemu-system-x86_64

root@libvirt-debian-9:/home/qemu# qemu-system-x86_64 -version
QEMU emulator version 2.8.1(Debian 1:2.8+dfsg-6+deb9u5)

While host is in load, (repoduced 100% while doing kernel compilation) if I try
to run qemu with tcg mode it crashes consistently:

ex: Set guest startup RAM size to X megs with: 
 
root@libvirt-debian-9:/home/qemu# gdb --args qemu-system-x86_64 -machine 
accel=tcg -m 100
(gdb) bt
#0  tcg_out_opc (opc=opc@entry=85, r=r@entry=0, rm=, x=x@entry=0,
s=) at ./tcg/i386/tcg-target.inc.c:460
#1  0x55829ed4 in tcg_out_push (reg=, s=0x561c6440 
)
at ./tcg/i386/tcg-target.inc.c:703
#2  tcg_target_qemu_prologue (s=0x561c6440 ) at 
./tcg/i386/tcg-target.inc.c:2343
#3  tcg_prologue_init (s=s@entry=0x561c6440 ) at ./tcg/tcg.c:394
#4  0x5582052e in tcg_exec_init (tb_size=) at 
./translate-all.c:831
#5  0x55945c35 in tcg_init (ms=) at ./accel.c:42
#6  0x55945d6e in accel_init_machine (ms=0x566df080, 
acc=0x566a82b0)
at ./accel.c:70
#7  configure_accelerator (ms=0x566df080) at ./accel.c:109
#8  0x5580fda9 in main (argc=, argv=,
envp=) at ./vl.c:4359


When host is not in load there is not problem, it works as expected.

root@libvirt-debian-9:/home/qemu# qemu-system-x86_64 -machine accel=tcg -m 
100
qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory

I am using Debian 9.

In debian-testing this is already fixed, so qemu version is the problem
here. I didn't bisect the commit that fixed it, if anyone is interesting
in backporting I can do that.

Thanks,

Katerina


signature.asc
Description: PGP signature


Bug#915117: xdg-desktop-portal: Recommend a backend?

2018-11-30 Thread Jeremy Bicha
Source: xdg-desktop-portal
Version: 1.0.3-1

xdg-desktop-portal's package description says
 xdg-desktop-portal is designed to be desktop-agnostic, and uses a
 desktop-environment-specific GUI backend such as xdg-desktop-portal-gtk
 to provide its functionality.

Should xdg-desktop-portal recommend the virtual package
xdg-desktop-portal-backend?

xdg-desktop-portal-kde in Testing now provides that virtual package,
but xdg-desktop-portal-kde was never backported to Stretch.

I see that Debian's Flatpak has this so maybe we should just copy it:
Recommends: xdg-desktop-portal-gtk | xdg-desktop-portal-backend

By the way, I filed https://bugs.debian.org/915115 to propose that
meta-kde install the KDE backend by default.

Thanks,
Jeremy Bicha



Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing

2018-11-30 Thread Jakob Haufe
On Fri, 30 Nov 2018 18:01:26 +0200
Jan Groenewald  wrote:

> There is  https://packages.gitlab.com/gitlab/gitlab-ce
> 
> (deb https://packages.gitlab.com/gitlab/gitlab-ce/debian/ stretch main)

Sorry, but no. Just no, no, no and no. Those binary dumps are horrible. They
are essentially just dumping 2/3 of an outdated(*) Linux system to /opt.

Pirate Praveen is doing an awesome job of packaging this very complex piece
of software in a proper way and I at least am very grateful for this.
Even if it is only available in unstable, it's a lot better than those
blobs provided upstream.

Cheers,
sur5r

(*)
- Postgres 9.6
- openSSL 1.0.0 (??!)
- Python 3.4
... the list goes on



Bug#915115: meta-kde: Install xdg-desktop-portal-kde by default

2018-11-30 Thread Jeremy Bicha
Source: meta-kde
Version: 5:102

Flatpak recommends xdg-desktop-portal-gtk | xdg-desktop-portal-backend

xdg-desktop-portal-backend is a virtual package provided by the GTK
and KDE backends.

Since there is a KDE backend, I think one of the KDE metapackage
should go ahead and install it by default so that a user who installs
Flatpak will get the correct KDE integration without needing to take
the further action of finding and installing the KDE backend.

For reference, the kubuntu-desktop and kubuntu-full metapackages
recommend xdg-desktop-portal-kde.

By the way, Snap will soon be using xdg-desktop-portal too.

Thanks,
Jeremy Bicha



Bug#915114: fontconfig-config: Unnecessary dependency on ucf

2018-11-30 Thread Simon McVittie
Package: fontconfig-config
Version: 2.13.1-2
Severity: minor

While investigating how to reduce the package list for a container in a
Debian derivative, I found that fontconfig-config Depends on ucf but
doesn't appear to need it.

Its only call to ucf since etch (2007) has been to remove all record of
/etc/fonts/local.conf when purged, but that's correctly guarded by
"if [ -x /usr/bin/ucf ]" (and the dependency is not helpful here in any
case, because when a package in the "config files remain" state is purged,
the only packages guaranteed to be present are the Essential set).

smcv



Bug#903190: ruby-sham-rack: diff for NMU version 1.4.1-1.1

2018-11-30 Thread Adrian Bunk
Control: tags 903190 + patch
Control: tags 903190 + pending

Dear maintainer,

I've prepared an NMU for ruby-sham-rack (versioned as 1.4.1-1.1) and 
uploaded it to DELAYED/15. 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 ruby-sham-rack-1.4.1/debian/changelog ruby-sham-rack-1.4.1/debian/changelog
--- ruby-sham-rack-1.4.1/debian/changelog	2017-08-20 19:19:03.0 +0300
+++ ruby-sham-rack-1.4.1/debian/changelog	2018-11-30 18:12:36.0 +0200
@@ -1,3 +1,11 @@
+ruby-sham-rack (1.4.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS by no longer trying to install
+a nonexisting README.markdown. (Closes: #903190)
+
+ -- Adrian Bunk   Fri, 30 Nov 2018 18:12:36 +0200
+
 ruby-sham-rack (1.4.1-1) unstable; urgency=medium
 
   * New upstream release (Closes: #868750)
diff -Nru ruby-sham-rack-1.4.1/debian/ruby-sham-rack.docs ruby-sham-rack-1.4.1/debian/ruby-sham-rack.docs
--- ruby-sham-rack-1.4.1/debian/ruby-sham-rack.docs	2017-08-20 19:19:03.0 +0300
+++ ruby-sham-rack-1.4.1/debian/ruby-sham-rack.docs	1970-01-01 02:00:00.0 +0200
@@ -1 +0,0 @@
-README.markdown


  1   2   3   >