Bug#933271: libreoffice: Should recommend libreoffice-gnome

[Rene Engelhard]

Hi,

On Sun, Jul 28, 2019 at 11:06:16PM +0200, Yvan Masson wrote:
> > On Sun, Jul 28, 2019 at 09:17:05PM +0200, Yvan Masson wrote:
> > > > So apt install libreoffice would have shown that. But yes, tasksel
> > > > wouldn't have shown it.
> > > > 
> > > That is exactly `apt show libreoffice` that gave me the answer :-)
> > > The point is that not everybody has the abilities to use this command and
> > > find that libreoffice-gnome is the pacakge to install.
> > 
> > For them is the desktop task (task-desktop).
> > 
> > As outlined that installs libreoffice-gnome unless you choose an other
> > desktop yourself.
> 
> I don't understand: task-desktop does not recommend libreoffice-gnome.

Wrong, it does, as I showed. See my reply at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933271#12

It recommends task-gnome-desktop...

> During install, if you choose for example: "Desktop environment", "LXQT",
^^
... but that isn't in effect
when you choose one
yourself ...

> "print server" and "standard system utilities", then libreoffice-gnome won't
> be installed.

True, didn*t deny that.

Regards,

Rene

Bug#932021: RM: liblas -- ROM; Dead upstream, outstanding security issues, FTBFS with GDAL 3

[Sebastiaan Couwenberg]

Control: tags -1 - moreinfo

On 7/21/19 11:03 PM, Scott Kitterman wrote:
> On Sun, 14 Jul 2019 09:03:38 +0200 Bas Couwenberg  wrote:
>> Package: ftp.debian.org
>> Severity: normal
>> Control: block -1 by 932020
>>
>> Please remove liblas from the archive, it's dead upstream, has
>> outstanding security issues, and FTBFS with GDAL 3.
> 
> Please remove the moreinfo tag once the blocking bug is addressed.

cloudcompare (2.10.3-2) is now in unstable which no longer (build)
depends on liblas.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#932915: RFS: qcoan/2.0-6

[Adam Borowski]

On Sun, Jul 28, 2019 at 11:17:10AM +0200, Elmar Stellnberger wrote:
> I have now installed a plain Bullseye chroot with debootstrap, installed all
> packages in build-depends and then run dpkg-buildpackage and see it builds
> without any problem. There needs to be something messed up with your build
> environment. Please have a look!

Full log:
http://ix.io/1PTG

It's obvious there's a missing Build-Dependency, although qmake's error
message is not very helpful.  I don't know QT well enough to assist you
there.

My build environment is for all matters that matter here identical with
official buildds[1] -- so even if I injected that dependency into my
chroot, the package would fail to build after upload.

I'd recommend testing in a tool such as pbuilder that ensures a build
environment without extra packages.


Meow!

[1]. I run 5.2 kernel, they run 4.19 or 4.9; for some uses filesystem matters
as well.  Or amount of memory or cores.  Or microarchitecture.
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄

Bug#933313: uscan doesn't detect new versions

[Joseph Nahmias]

Package: msmtp
Version: 1.6.6-1
Severity: normal
Tags: patch

Hello,

It seems the debian/watch file is out of date and thus uscan doesn't detect new 
upstream versions.  Here's a new one that works.

Enjoy,
--Joe
version=4

https://marlam.de/msmtp/download/ ../releases/msmtp-([\d\.]+)@ARCHIVE_EXT@ 
debian uupdate

Bug#933312: ITP: golang-github-cloudflare-circl -- Cloudflare Interoperable Reusable Cryptographic Library

[Eric Dorland]

Package: wnpp
Severity: wishlist
Owner: Eric Dorland 

* Package name: golang-github-cloudflare-circl
  Version : 1.0.0
  Upstream Author : Cloudflare
* URL : https://github.com/cloudflare/circl
* License : BSD
  Programming Lang: Go
  Description : Cloudflare Interoperable Reusable Cryptographic Library

CIRCL is a collection of cryptographic primitives written in Go. The goal of 
this library is to be used as a tool for experimental deployment of 
cryptographic algorithms targeting Post-Quantum (PQ) and Elliptic Curve 
Cryptography (ECC).

Bug#933311: bitcoin-qt: symbol lookup error: bitcoin-qt: undefined symbol: _ZN7leveldb4port5Mutex6UnlockEv

[RegEx]

Package: bitcoin-qt
Version: 0.18.0~dfsg-1
Severity: important

Dear Maintainer,

after apt upgrade today, bitcoin-qt does not start anymore.
It fails with this error message:
bitcoin-qt: symbol lookup error: bitcoin-qt: undefined symbol:
_ZN7leveldb4port5Mutex6UnlockEv



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

Kernel: Linux 4.17.5 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bitcoin-qt depends on:
ii  libboost-chrono1.67.0  1.67.0-13
ii  libboost-filesystem1.67.0  1.67.0-13
ii  libboost-system1.67.0  1.67.0-13
ii  libboost-thread1.67.0  1.67.0-13
ii  libc6  2.28-10
ii  libdb5.3++ 5.3.28+dfsg1-0.6
ii  libevent-2.1-6 2.1.8-stable-4
ii  libevent-pthreads-2.1-62.1.8-stable-4
ii  libgcc11:9.1.0-10
ii  libleveldb1d   1.22-3
ii  libminiupnpc17 2.1-1+b1
ii  libprotobuf17  3.6.1.3-2
ii  libqrencode4   4.0.2-1
ii  libqt5core5a   5.11.3+dfsg1-2
ii  libqt5dbus55.11.3+dfsg1-2
ii  libqt5gui5 5.11.3+dfsg1-2
ii  libqt5network5 5.11.3+dfsg1-2
ii  libqt5widgets5 5.11.3+dfsg1-2
ii  libsecp256k1-0 0.1~20170810-2
ii  libssl1.1  1.1.1c-1
ii  libstdc++6 9.1.0-10
ii  libunivalue0   1.0.4-2
ii  libzmq54.3.2-1

bitcoin-qt recommends no packages.

bitcoin-qt suggests no packages.

-- no debconf information

Bug#933310: dot2tex: new upstream version 2.11.3

[Joseph Nahmias]

Package: dot2tex
Version: 2.9.0-3
Severity: wishlist

Dear Maintainer,

There is a new version of dot2tex since March 2019 that includes support
for python3.  It would be great if you packaged this.

Thanks,
--Joe

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

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

Versions of packages dot2tex depends on:
ii  graphviz  2.40.1-6
ii  libjs-sphinxdoc   1.8.4-1
ii  python2.7.16-1
ii  python-pyparsing  2.2.0+dfsg1-2

Versions of packages dot2tex recommends:
ii  preview-latex-style  11.91-2
ii  texlive-latex-base   2018.20190227-2
ii  texlive-pictures 2018.20190227-2
ii  texlive-pstricks 2018.20190227-2

dot2tex suggests no packages.

-- no debconf information

Bug#933192: lintian-brush: complains repository is dirty, but git status lists no files

[Felipe Sateler]

On Sun, Jul 28, 2019, 18:36 Jelmer Vernooij  wrote:

> Hi Felipe,
>
> Thanks for the bug report.
>
> On Sat, Jul 27, 2019 at 08:54:17AM -0400, Felipe Sateler wrote:
> > lintian-brush complains repository is dirty, but repo is clean:
> >
> > felipe@felipedell:csound% lintian-brush
> > /home/felipe/src/deb/pkg-multimedia/csound: Please commit pending
> changes first.
> > % git status
> > On branch master
> > Your branch is ahead of 'origin/master' by 3 commits.
> >   (use "git push" to publish your local commits)
> >
> > nothing to commit, working tree clean
> >
> >
> > Turns out there are gitignored files:
> >
> > % git clean -fdX
> > Removing .pc/
> > Removing .vscode/
> > Removing test.wav
> >
> > After this lintian-brush can work.
> >
> > I think lintian-brush should also ignore gitignored files
>
> lintian-brush attempts to ignore gitignored files, but it seems that
> this doesn't always work.
>
> In this particular case, it appears that it does properly ignore
> test.wav because "*.wav" exists in .gitignore.
>
> I don't see any matches for .pc/ or .vscode/ in .gitignore though. Do
> you perhaps have them in ~/.git/ignore ?


Yes, I have .vscode in the global gitignore.


Were there any files under
> .pc/ or .vscode/ that you can remember?
>

I don't know if .pc had anything in it, but .vscode probably did.

I wonder why not just rely on git status (or the plumbing equivalent)
instead of detecting changes manually?

>

Bug#933264: gradle: update SID version to new version?

[殷啟聰 | Kai-Chung Yan]

Newer version of Gradle requires Kotlin, which is being worked on right now. 
See https://java-team.pages.debian.net/gsoc-kotlin-blog



signature.asc
Description: OpenPGP digital signature

Bug#933308: diffoscope: OpenJDK jmod file format support (ZIP-like)

[Emmanuel Bourg]

Package: diffoscope
Version: 118
Severity: normal

Hi,

Starting with the version 9 and the new module system OpenJDK has .jmod files
containing compiled classes and resources. This file format isn't supported
by diffoscope yet. It's basically a ZIP file but with an extra 4 bytes header:
the "JM" string followed by 01 and 00 (the format version 1.0 I guess), so
the first bytes are "4A 4D 01 00", immediately followed by the usual ZIP
header "50 4B 03 04".

Could you please implement this new container format? That would greatly help
analyzing the reproducibility issues in OpenJDK 9 and later.

The jmod files can be found in the openjdk-11-jdk and openjdk-12-jdk packages.
You can test the implementation with:

  diffoscope /usr/lib/jvm/java-11-openjdk-amd64/jmods/java.management.jmod 
/usr/lib/jvm/java-12-openjdk-amd64/jmods/java.management.jmod

Thank you,

Emmanuel Bourg

Bug#933139: Fwd: Bug#933139: bind9 fails on startup: can't find /var/cache/bind

[Ross Boylan]

And for the bug report:
-- Forwarded message -
From: Ross Boylan 
Date: Sun, Jul 28, 2019 at 5:11 PM
Subject: Re: Bug#933139: bind9 fails on startup: can't find /var/cache/bind
To: Bernhard Schmidt 


On Sun, Jul 28, 2019 at 12:36 PM Ross Boylan
 wrote:

> On Sun, Jul 28, 2019 at 11:42 AM Bernhard Schmidt  wrote:
.
> > > The root partition includes /var/cache, but no /var/cache/bind.
> > > When the partition with /var is mounted it has a /var/cache/bind
> > > directory.
> >
> > Is there a reason for this? I think having a non-empty mount target is
> > somewhat unusual, maybe this is causing the systemd mount dependency
> > logic to fail.
>
> I think it's a historical accident of how I setup the system; I don't
> have any principled reason for the setup.
>
> I can try making /var empty on the root partition and test the next
> time I have a chance to reboot.
Emptying /var seemed to work once in conjunction with adding a
dependency on /var for bind9-resolvconf, but then it failed.
It has also proven difficult to keep the root partitions /var clear of
content.  I'm suspecting an interaction between bind9,
bind9-resolvconf, and resolvconf itself with a bind9 extension.

In order:

1. Deleted everything under root's var and restarted.  Same failure to
start bind9 as before.
root's var had an empty tmp directory, timestamped well before
restart, and a run subdirectory timestamped at the system start.  It
had only named/named.resolvers, a stub file with only
// named.conf fragment automatically generated by /etc/resolvconf/update.d/bind9
// DO NOT EDIT THIS FILE.  Instead edit /etc/bind/named.conf.options .
This directed my attention to named-resolvconf, to which I added an
override to tell it to wait for /var.
I may have forgotten to clear out root's var.

2. Success!  However, root's var still has named.resolvers,
timestamped with the time from step 1, and the directories above it.
The named directory is timestamped at this steps startup; run (above
it) has step 1's timestamp.  named.resolvers has the same trivial
contents as before.
rm all files and dirs below root's var. Reboot.

3. Failure!  root's /var has the same files as in 2, now all
timestamped with step 3 startup time.  Delete them all and  reboot.

4. Still failure.  I notice that scripts in resolvconf (see below) may
be involved and added a RequiresMountsFor=var to resolvconf.service.
I have not had a chance to test that.

Comments on the relations between the services:
Comment 1
The startup order appears to be resolvconf first, then bind9, and
finally bind9-resolvconf, where each must complete before the next
starts.  resolvconf is Before network.target while bind9 is After it;
bind9-resolvconf is After bind9. However, bind9.service.wants has a
link to bind9-resolvconf (I may have added that), which contradicts
bind9 resolvconf's After directive.  I think the Wants will be
ignored, but maybe it's part of the problem?

Comment 2
The resolvconf service runs the resolvconf program, which in turn
triggers the update.d/bind9 script shown  below.  This script writes
to /var/run/named/named.resolvers, exactly the file mentioned above as
appearing on the root partition's var.  The script is based on those
formerly distributed with bind, though I don't think it's in the
current release (I recall it was carved out of a more elaborate
script).

bind9-resolvconf also calls the resolvconf script, presumably
triggering the same update.d/bind9 script.

The rest of this message lists the contents of different files.

# systemctl cat bind9 ---
# /lib/systemd/system/bind9.service
[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target
Wants=nss-lookup.target
Before=nss-lookup.target

[Service]
Type=forking
EnvironmentFile=-/etc/default/bind9
ExecStart=/usr/sbin/named $OPTIONS
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/bind9.service.d/override.conf
[Unit]
RequiresMountsFor=/var

# systemctl cat bind9-resolvconf --
# /lib/systemd/system/bind9-resolvconf.service
[Unit]
Description=local BIND via resolvconf
Documentation=man:named(8) man:resolvconf(8)
PartOf=bind9.service
After=bind9.service
ConditionFileIsExecutable=/sbin/resolvconf

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'echo nameserver 127.0.0.1 | /sbin/resolvconf -a lo.named'
ExecStop=/sbin/resolvconf -d lo.named

[Install]
WantedBy=bind9.service

# /etc/systemd/system/bind9-resolvconf.service.d/override.conf
[Unit]
RequiresMountsFor=/var

# systemctl cat resolvconf
---
# /lib/systemd/system/resolvconf.service
[Unit]
Description=Nameserver information manager
Documentation=man:resolvconf(8)
DefaultDependencies=no
Before=networking.service

[Service]
RemainAfterExit=yes
ExecStartPre=/bin/mkdir -p 

Bug#933139: Fwd: Bug#933139: bind9 fails on startup: can't find /var/cache/bind

[Ross Boylan]

Oops, forgot to cc the bug.

-- Forwarded message -
From: Ross Boylan 
Date: Sun, Jul 28, 2019 at 12:36 PM
Subject: Re: Bug#933139: bind9 fails on startup: can't find /var/cache/bind
To: Bernhard Schmidt 
Cc: Ross Boylan 


Thank you for your response.  Answers interpolated below.

On Sun, Jul 28, 2019 at 11:42 AM Bernhard Schmidt  wrote:
>
> Control: tags -1 moreinfo
>
> Am 26.07.19 um 22:50 schrieb Ross Boylan:
>
> Hi Ross,
>
> > * What led up to the situation?
> >
> >Start or restart the system.  bind9 attempts to start, but fails
> >with the error that it is unable to cd to /var/cache/bind.  This
> >happens every time.
> >
> >New installation of buster with existing customizations from an old
> >system ported over, with adoptions.
> >
> >resolvconf in use.
> >
> >/var is a separate partition.  See details below for my theory the
> >failure arises from a race condition in which bind starts before
> >/var is mounted.
>
> I think this is more of a systemd bug or local misconfiguration than a
> bind9 bug.

That's my main suspicion, but I thought it best to start with the
package reporting the error.
Also, it would be nice if bind9 worked with mountable /var out of the
box (if that is the problem).

BTW I have attempted to sign up for the general (but called
"developer") systemd list at freedesktop, but have not received the
confirming message to which I must reply.

>
> > The root partition includes /var/cache, but no /var/cache/bind.
> > When the partition with /var is mounted it has a /var/cache/bind
> > directory.
>
> Is there a reason for this? I think having a non-empty mount target is
> somewhat unusual, maybe this is causing the systemd mount dependency
> logic to fail.

I think it's a historical accident of how I setup the system; I don't
have any principled reason for the setup.

I can try making /var empty on the root partition and test the next
time I have a chance to reboot.
>
> > /var is encrypted on top of lvm, so it takes a bunch of steps to mount
> > it.  However, it does not require me to enter any new passwords to
> > decrypt it.  The root partition does require me to enter a password,
> > which happens early in startup.
>
> Are there manual steps involved mounting /var?
Given that / is mounted, no.
>
> How does your /etc/fstab look like?
UUIDs obscured:
--fstab-
/dev/mapper/vgbarley-root_crypt /   ext4
errors=remount-ro 0   1
UUID=xx /boot   ext2defaults0   2
/dev/mapper/vgbarley-home_crypt /home   ext4defaults
 0   2
/dev/mapper/vgbarley-usr /usrext4defaults0   2
/dev/mapper/vgbarley-var_crypt /varext4defaults0   2
/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0
/dev/vgbarley/media10 /srv/media10  xfs noatime,nodiratime,allocsize=512m 0 0
/dev/vgbarley/cache   /var/local/cacheext4 defaults,noatime  0 0

--crypttab
vgbarley-home_crypt UUID=yy none luks,discard
vgbarley-root_crypt UUID=zz none luks,discard
vgbarley-var_crypt UUID=ww none luks,discard
---
The UUIDs in crypttab point at the correspondingly named logical
volumes on vgbarley, e.g., vgbarley/var for var.

So on startup lvm must activate vgbarley, and attempts to activate
some other volume groups.  This is a bit tricky, since some of the
other volume groups are missing some physical disks, introducing delay
and partial activation for those groups.
I also have encrypted physical partitions and RAID; again neither is
involved with vgbarley.
Once vgbarley is active some of its logical volumes, including root
and var, must be decrypted.
This requires entering a password on startup; since the same one works
for root and var, there is no separate prompt for var.
Underlying disks are GPT.

Ross

Bug#933307: ITS: convertall

[Lisandro Damián Nicanor Pérez Meyer]

Source: convertall
Version: 0.7.3-1.1
Severity: important

Hi! I hereby offering myself to co-maintain/salvage the package convertall, 
applying the following [criteria]:

- Package maintainance seems to have been incative for more than a year
- Last NMU comes from myself.
- There is at least one new version available.
- I use it from time to time and even rely on it.

I admit I am not precisely knowledgeable wrt python, but I do know some Qt 
stuff.

[criteria] 


If I where to salvage it I would certainly put it under the Qt/KDe's team 
umbrella, "extra" section:



Kinds regards, Lisandro.


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- debconf-show failed

Bug#926401: initramfs-tools: update-initramfs -k all -c does not create initrd images anymore

[Marc Lehmann]

On Sat, Jul 27, 2019 at 11:19:06PM +0100, Ben Hutchings  
wrote:
> > images for all kernels, in 0.133, it is a nop.
> 
> Not quite.  In older versions, "-k all" would apply to every initramfs
> image that initramfs-tools remembered generating (as recorded in
> /var/lib/initramfs-tools).

Well, I guess the phrase "all kernel versions known to update-initramfs"
is not very precise,e specially as it's not clear how to make kernel
versons known to it :)

> > The reason is that get_sorted_versions now only lists kernels with
> > existing initrd images, which makes the -c option somewhat useless.
> 
> Yes, though I can't see how the previous behaviour was useful either. 
> Do you delete existing initramfs images, using something other than
> "update-initramfs -d", before you run "update-initramfs -k all -c"?

Not explicitly, but the result is that the file is not there when I run the
command.

The workaround in place now enumerates all installed kernel versions
explicitly via upsate-initramfs -c -k .

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#933306: ghc: Cross-build fails because host and build architecture do not match

[John Paul Adrian Glaubitz]

Source: ghc
Version: 8.6.5+dfsg1-2
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hello!

Trying to cross-build ghc currently fails with:

GHC build  : x86_64-unknown-linux
GHC host   : powerpc-unknown-linux
GHC target : powerpc-unknown-linux
LLVM target: powerpc-unknown-linux
checking for path to top of build tree... /<>
checking for powerpc-linux-gnu-windres... no
checking for powerpc-linux-gnu-dllwrap... no
checking for powerpc-linux-gnu-objdump... powerpc-linux-gnu-objdump
configure: error: 
You've selected:

  BUILD:  x86_64-unknown-linux   (the architecture we're building on)
  HOST:   powerpc-unknown-linux(the architecture the compiler we're 
building will execute on)
  TARGET: powerpc-unknown-linux  (the architecture the compiler we're building 
will produce code for)

BUILD must equal HOST; that is, we do not support building GHC itself
with a cross-compiler.  To cross-compile GHC itself, set TARGET: stage
1 will be a cross-compiler, and stage 2 will be the cross-compiled
GHC.

This can be reproduced when building ghc with:

 sbuild -d sid --host=powerpc --profile=cross --no-arch-all

I was able to fix this problem with the following trivial change:

--- debian/rules~   2019-07-28 18:31:28.0 +0200
+++ debian/rules2019-07-29 01:39:31.863510243 +0200
@@ -23,7 +23,7 @@
 export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 export DEB_HOST_ARCH  ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
 
-EXTRA_CONFIGURE_FLAGS += --target $(DEB_HOST_GNU_TYPE)
+EXTRA_CONFIGURE_FLAGS += --host $(DEB_BUILD_GNU_TYPE) --build 
$(DEB_BUILD_GNU_TYPE) --target $(DEB_HOST_GNU_TYPE)
 # We're cross-building if DEB_BUILD_GNU_TYPE != DEB_HOST_GNU_TYPE
 ifneq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
   EXTRA_CONFIGURE_FLAGS += --enable-unregisterised

Would be great if something like that could be done for the next upload,
so it's easier to cross-bootstrap ghc again for powerpc and sh4.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#932367: GAP_Initialize signature changed

[Martin von Gagern]

I tried locally rebuilding sagemath against GAP 4r10p2-2. It seems we
need 
https://github.com/sagemath/sage/commit/e6e80bfa0f36688904716f93e04ad0121b7a4136.patch
to account for changes to the GAP_Initialize signature from
https://github.com/gap-system/gap/commit/5dad0ef01e5527d83d7ade6677891b855381aee3
and 
https://github.com/gap-system/gap/commit/eab71117db3a3afd1adec9a87e96b3b4a9414f60.

Unfortunately the patch doesn't apply cleanly, and I don't have time
just now to massage it. So I'm sending what information I have in case
someone else can cherry-pick it in.

Without this, I get a SIGSEGV when loading sage.libs.gap.libgap
because the address of a data structure (the old env argument) is
treated as a function pointer that gets called during garbage
collection. The error doesn't stop the build at that point, but it
causes the documentation build to hang indefinitely eventually,
similar to bug #901532. Check sage/logs/dochtml.log for the actual
problem report.

Bug#933230: acpid: Race during startup can result in event devices not being opened

[Ted Felix]

On 7/27/19 4:21 PM, ano...@users.sourceforge.net wrote:

On my system, this race happens frequently for /dev/input/event8 "Video
Bus" during boot, preventing acpid from handling my system's brightness
keys.


  Thanks for the patch.  I've posted the patch and this report upstream:

https://sourceforge.net/p/acpid2/tickets/18/

  Probably will do a new release with this in a month or so.

Bug#878777: please drop transitional package nowebm

[Nicolas Boulenguez]

Source: noweb
Version: 2.11b-11
Followup-For: Bug #878777
Control: tag -1 + patch

Hello.
The attached changes fix this issue.
They also update the packaging to source format 3.0 and debhelper 12.
I hope they will be useful.


noweb.tar.gz
Description: application/gzip

Bug#933300: libocatve-dev should not depend on a toolchain

[Mike Miller]

Hi Helmut, Rafael,

On Mon, Jul 29, 2019 at 00:15:39 +0200, Rafael Laboissière wrote:
> * Helmut Grohne  [2019-07-28 22:32]:
> 
> >  Package: liboctave-dev
> >  Version: 4.4.1-6
> >  Tags: patch
> >  User: debian-cr...@lists.debian.org
> >  Usertags: cross-satisfiability
> >  Control: affects -1 + src:mathgl
> > 
> > mathgl fails to satisfy its cross Build-Depends, because its dependency
> > on liboctave-dev is not satisfiable. liboctave-dev depends on toolchain
> > packages such as gcc, g++ or gfortran. This is very unusual. Most
> > commonly, C-libraries can depend on other C-libraries, but users are
> > expected to install their desired toolchain themselves. These
> > dependencies need toolchain dependency translation in order to work for
> > cross building. Unfortunately, toolchain dependency translation is not
> > yet implemented. Thus I think removing these dependencies is required. I
> > looked into debian/changelog for why they were added and couldn't find a
> > reason. Can we simply drop them?
> 
> I think that the reason is historical.  At least since version 2.1.64-3,
> released 14 years ago, g++ and g77 | fort77 appear as dependencies of
> octave2.1-headers. [1] The package octave2.1-headers is the predecessor of
> liboctave-dev.

I think the reason for the dependency is because liboctave-dev also
ships /usr/bin/mkoctfile, which is a wrapper for gcc|g++|gfortran to
compile Octave extensions. Users install liboctave-dev and expect to be
able to run mkoctfile to build native .mex or .oct files.

One solution may be to introduce a new package, say 'octave-dev-tools',
that would ship /usr/bin/mkoctfile and Depends: liboctave-dev. This
might allow the possibility of cross-building with liboctave-dev. This
would have a large impact on documentation, FAQs, and other accumulated
knowledge that tells users to install 'liboctave-dev' to be able to
compile and install packages.

I want to also mention that liboctave-dev includes a small number of
header files in /usr/include that are generated and include
arch-specific contents:

usr/include/octave-5.1.0/octave/mxarray.h
usr/include/octave-5.1.0/octave/octave-config.h
usr/include/octave-5.1.0/octave/version.h

Does this require any specific handling with respect to multi-arch and
cross-building?

-- 
mike


signature.asc
Description: PGP signature

Bug#933192: lintian-brush: complains repository is dirty, but git status lists no files

[Jelmer Vernooij]

Hi Felipe,

Thanks for the bug report.

On Sat, Jul 27, 2019 at 08:54:17AM -0400, Felipe Sateler wrote:
> lintian-brush complains repository is dirty, but repo is clean:
> 
> felipe@felipedell:csound% lintian-brush
> /home/felipe/src/deb/pkg-multimedia/csound: Please commit pending changes 
> first.
> % git status
> On branch master
> Your branch is ahead of 'origin/master' by 3 commits.
>   (use "git push" to publish your local commits)
> 
> nothing to commit, working tree clean
> 
> 
> Turns out there are gitignored files:
> 
> % git clean -fdX
> Removing .pc/
> Removing .vscode/
> Removing test.wav
> 
> After this lintian-brush can work.
> 
> I think lintian-brush should also ignore gitignored files

lintian-brush attempts to ignore gitignored files, but it seems that
this doesn't always work.

In this particular case, it appears that it does properly ignore
test.wav because "*.wav" exists in .gitignore.

I don't see any matches for .pc/ or .vscode/ in .gitignore though. Do
you perhaps have them in ~/.git/ignore ? Were there any files under
.pc/ or .vscode/ that you can remember?

Bug#933305: lintian: pedantic complaint about duplicate items in a single debian/changelog entry

[Paul Wise]

Package: lintian
Severity: wishlist

This morning I saw a package upgrade that had a changelog entry with
these two lines in it.

  * debian/control: Use debhelper-compat 12
  * debian/control: Use debhelper-compat 12

I think a pedantic complaint about the duplicate items would be
appropriate to have in lintian.

I would suggest each item in the changelog entry should be stripped of
whitespace before comparing them so that trailing whitespace in one of
them still triggers the complaint.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#933304: lintian: suggest switching from debian/compat to debhelper-compat

[Paul Wise]

Package: lintian
Severity: wishlist

debhelper has replaced debian/compat with the debhelper-compat virtual
package for most circumstances. Many packages made the switch already.

https://manpages.debian.org/unstable/debhelper/debhelper.7.en.html#COMPATIBILITY_LEVELS

I would like a pedantic reminder from lintian to switch from the
debian/compat file to the debhelper-compat virtual package.

Please note that there are some circumstances in which lintian should
not complain about use of debian/compat:

   Note that debhelper does not provide debhelper-compat for
   experimental or beta compatibility levels; packages experimenting
   with those compatibility levels should use debian/compat or
   DH_COMPAT.

In addition, it would probably be correct to not emit this if the
debhelper build-dep allows versions before the debhelper version that
added this feature (11.1.5~alpha1) or for uploads to stretch-backports
or earlier suites (the feature is in debhelper in stretch-backports but
isn't available in stretch itself):

   debhelper (11.1.5~alpha1) experimental; urgency=medium

 ...
 * Dh_Lib: Add an experimental feature to determine the requested
   compat level from the Build-Depends field.

-- Niels Thykier   Sat, 24 Feb 2018 16:01:31 +

   debhelper  | 9.20150101+deb8u2 | oldoldstable  | source, all
   debhelper  | 10.2.5| oldstable | source, all
   debhelper  | 12.1.1~bpo9+1 | stretch-backports | source, all
   debhelper  | 12.1.1| stable| source, all
   debhelper  | 12.2.3| testing   | source, all
   debhelper  | 12.2.3| unstable  | source, all

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#923034: O: freeradius -- high-performance and highly configurable RADIUS server

[Bernhard Schmidt]

Am 17.07.19 um 13:09 schrieb Sven Hartge:

Hi Sven,

>>> I am orphaning this package effective immediately. I have never personally 
>>> used
>>> FreeRADIUS, and only stepped in to help when I saw the package was in bad 
>>> shape.
>>
>> A few days ago I was talking to a co-worker who is with the group
>> running our RADIUS infrastructure for the university on FreeRADIUS. He
>> might be interested to help maintaining it in Debian. He's not a DD/DM
>> and will need a bit of procedural help, but that would be a start.
>>
>> What's the current status regarding the "FreeRADIUS Packaging Team"?
>> There are five persons listed in Uploaders, with Bugs filed for two of
>> them to be removed and Michael stepping down. Sam, judging from #806617,
>> is no longer interested as well. That would leave Mark (Cced). Dimiti
>> (also Cced) is among Michael the only member of the Salsa Group.
> 
> Hello all!
> 
> While I have no intention nor the time to maintain FreeRADIUS in Debian,
> I needed an up-to-date version for some internal tests and did some
> prep-work for the current 3.0.19 release, available here:
> 
> https://salsa.debian.org/hartge-guest/freeradius
> 
> Maybe this is help- or useful.

Thanks a lot, I have pulled the changes and pushed them into the git
repo. I've also added a few of my own. I will do an upload soon,
probably move it into the debian group on salsa and retitle this bug to RFH.

I don't really want to fully maintain it either, and definitely not
alone, but maybe there are enough maintainers around that can fix the
occasional bug to keep it up to date. I still hope to get my colleague
interested in it, which should now be easier with salsa-ci enabled.

Bernhard

Bug#933300: libocatve-dev should not depend on a toolchain

[Rafael Laboissière]

* Helmut Grohne  [2019-07-28 22:32]:


 Package: liboctave-dev
 Version: 4.4.1-6
 Tags: patch
 User: debian-cr...@lists.debian.org
 Usertags: cross-satisfiability
 Control: affects -1 + src:mathgl

mathgl fails to satisfy its cross Build-Depends, because its dependency 
on liboctave-dev is not satisfiable. liboctave-dev depends on toolchain 
packages such as gcc, g++ or gfortran. This is very unusual. Most 
commonly, C-libraries can depend on other C-libraries, but users are 
expected to install their desired toolchain themselves. These 
dependencies need toolchain dependency translation in order to work for 
cross building. Unfortunately, toolchain dependency translation is not 
yet implemented. Thus I think removing these dependencies is required. I 
looked into debian/changelog for why they were added and couldn't find a 
reason. Can we simply drop them?


I think that the reason is historical.  At least since version 2.1.64-3, 
released 14 years ago, g++ and g77 | fort77 appear as dependencies of 
octave2.1-headers. [1] The package octave2.1-headers is the predecessor 
of liboctave-dev.


This dependency may have been introduced before this version, but version 
control started at that point and there is no way to figure out now when 
and why those dependencies were introduced.


I would say that it is okay to drop the dependencies on gcc, g++ and 
gfortran, as you suggest, but I will let the other members of the 
Debian Octave comment on this issue.


Rafaek

[1] 
https://salsa.debian.org/pkg-octave-team/octave/blob/be338881462f4e5b45483eb2d18b7fab059c057e/debian/control

Bug#933303: gnome-control-center: Google Online Account setup crashes under Wayland

[Nathan A. Stine]

Package: gnome-control-center
Version: 1:3.30.3-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I ran gnome-control-center in a terminal window and then went to Online
Accounts and then Google under Add an account.  The program crashed with this
error:

Gdk-Message: 18:04:35.031: Error 71 (Protocol error) dispatching to Wayland
display.

   * What exactly did you do (or not do) that was effective (or ineffective)?

I ran "GDK_BACKEND=x11 gnome-control-center" in the terminal and followed the
same steps.

   * What was the outcome of this action?

I was successfully able to add my Google accounts.



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

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

Versions of packages gnome-control-center depends on:
ii  accountsservice0.6.45-2
ii  apg2.2.3.dfsg.1-5
ii  colord 1.4.3-4
ii  desktop-base   10.0.2
ii  desktop-file-utils 0.23-4
ii  gnome-control-center-data  1:3.30.3-1
ii  gnome-desktop3-data3.30.2.1-2
ii  gnome-settings-daemon  3.30.2-3
ii  gsettings-desktop-schemas  3.28.1-1
ii  libaccountsservice00.6.45-2
ii  libatk1.0-02.30.0-2
ii  libc6  2.28-10
ii  libcairo-gobject2  1.16.0-4
ii  libcairo2  1.16.0-4
ii  libcanberra-gtk3-0 0.30-7
ii  libcanberra0   0.30-7
ii  libcheese-gtk253.31.90-1
ii  libcheese8 3.31.90-1
ii  libclutter-1.0-0   1.26.2+dfsg-10
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libcolord-gtk1 0.1.26-2
ii  libcolord2 1.4.3-4
ii  libcups2   2.2.10-6
ii  libfontconfig1 2.13.1-2
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libglib2.0-0   2.58.3-2
ii  libgnome-bluetooth13   3.28.2-3
ii  libgnome-desktop-3-17  3.30.2.1-2
ii  libgoa-1.0-0b  3.30.1-2
ii  libgoa-backend-1.0-1   3.30.1-2
ii  libgrilo-0.3-0 0.3.7-1
ii  libgtk-3-0 3.24.5-1
ii  libgtop-2.0-11 2.38.0-4
ii  libgudev-1.0-0 232-2
ii  libibus-1.0-5  1.5.19-4
ii  libkrb5-3  1.17-3
ii  libmm-glib01.10.0-1
ii  libnm0 1.14.6-2
ii  libnma01.8.20-1.1
ii  libpango-1.0-0 1.42.4-6
ii  libpangocairo-1.0-01.42.4-6
ii  libpolkit-gobject-1-0  0.105-25
ii  libpulse-mainloop-glib012.2-4
ii  libpulse0  12.2-4
ii  libpwquality1  1.4.0-3
ii  libsecret-1-0  0.18.7-1
ii  libsmbclient   2:4.9.5+dfsg-5
ii  libsoup2.4-1   2.64.2-2
ii  libupower-glib30.99.10-1
ii  libwacom2  0.32-1
ii  libwayland-server0 1.16.0-1
ii  libx11-6   2:1.6.7-1
ii  libxi6 2:1.7.9-1
ii  libxml22.9.4+dfsg1-7+b3

Versions of packages gnome-control-center recommends:
ii  cracklib-runtime  2.9.6-2
ii  cups-pk-helper0.2.6-1+b1
ii  gkbd-capplet  3.26.1-1
ii  gnome-online-accounts 3.30.1-2
ii  gnome-user-docs   3.30.2-1
ii  gnome-user-share  3.28.0-2
ii  iso-codes 4.2-1
ii  libcanberra-pulse 0.30-7
ii  libnss-myhostname 241-5
ii  mousetweaks   3.12.0-5
ii  network-manager-gnome 1.8.20-1.1
ii  policykit-1   0.105-25
ii  pulseaudio-module-bluetooth   12.2-4
ii  realmd0.16.3-2
ii  rygel 0.36.2-4
ii  rygel-tracker 0.36.2-4
ii  system-config-printer-common  1.5.11-4

Versions of packages gnome-control-center suggests:
ii  gnome-software   3.30.6-5
ii  gstreamer1.0-pulseaudio  1.14.4-1
pn  libcanberra-gtk-module   
ii  libcanberra-gtk3-module  0.30-7
ii  x11-xserver-utils7.7+8

-- no debconf information

Bug#932985: [932985] Please remove Python 2 support

[Jean-Michel Vourgère]

Hi Thomas

Thank you for your patch. I just made an upload based on it.

I had to remove python3-django-session-security.install since pybuild put the 
files directly in the correct location.

Also I changed your sphinx changes. Originally:

> override_dh_auto_build:
>   dh_auto_build -O--buildsystem=python_distutils

Your version
> override_dh_sphinxdoc:
> ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
>   python3 setup.py build_sphinx
>   dh_sphinxdoc
> endif
doesn't quite work as dh_sphinxdoc run after dh_install, that fails because 
the files are not there.

My final version:
> override_dh_auto_build:
>   dh_auto_build
> ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
>   python3 setup.py build_sphinx
> endif
works, and doesn't mix the build systems, which I believe was your point.

If you have a better idea, it will be welcome.

Thanks again

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

Bug#933302: firmware-realtek: RTL8723DE not working

[Matteo Semplice]

Package: firmware-realtek
Version: 20190114-1
Severity: important

Dear Maintainer,

on a fresh Debian 10 installation on an HP 15-bw061nl, despite having installed 
firmware-realtek, the wifi card does not work.
(I have set up the laptop as dual boot and the card works in Windows 10)

lspci reports

03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723DE 
802.11b/g/n PCIe Adapter
Subsystem: Hewlett-Packard Company RTL8723DE 802.11b/g/n PCIe Adapter
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

Bug#933299: isohybrid.pl should not be architecture dependent

[Lukas Schwaighofer]

Hi Timothy,

thanks for reporting.  The whole file organization of syslinux (both
which file is in which package, as well as the location of files) needs
improvement.  This is something I intend to work on during the bullseye
cycle.

As part of that, I'll also look into whether we need both the perl
script and the binary of "isohybrid" and in which package they should
be placed.  It'll still be a while until I get to it though (most
likely towards the end of this year).


@Thomas: If I remember correctly, isohybrid.pl only needs perl-base
(which is an essential package and does not require a dependency).
I'll double check that too.

Regards
Lukas

Bug#933301: mpd: systemd service doesn't use user configured UNIX socket since last update

[Simon Désaulniers]

Package: mpd
Version: 0.21.11-1
Severity: normal

Dear Maintainer,

After upgrading from 0.21.5-3 to 0.21.11-1, systemd's mpd service doesn't seem
to use the UNIX socket configured from my mpd configuration located at
/home/simon/.config/mpd/mpd.conf. I safely assume this due to the fact that
calling `mpd --no-daemon` myself (the same command found in `ExecStart=` line)
lead to mpd using the UNIX socket `~/.mpd/socket` that I configured which is not
the case for the systemd service. More precisely:

* Using systemd service:
  1) systemctl --user mask --now mpd
  2) rm -f ~/.mpd/socket
  3) systemctl --user unmask mpd; systemctl --user start mpd
  4) ls ~/.mpd # and notice the file is not there
* Using manual luanch:
  1) systemctl --user mask --now mpd
  2) rm -f ~/.mpd/socket
  3) mpd --no-daemon
  4) ls ~/.mpd # and notice the file is there

Therefore, the following configuration line from my personal file is read in the
second case, but not in the first:

  bind_to_address   "/home/simon/.mpd/socket"

I'm not really sure what's causing this.

Regards,

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


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=eo 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mpd depends on:
ii  adduser   3.118
ii  init-system-helpers   1.57
ii  libadplug-2.2.1-0v5   2.2.1+dfsg3-1
ii  libao41.2.2+20180113-1
ii  libasound21.1.8-1
ii  libaudiofile1 0.3.6-5
ii  libavahi-client3  0.7-4+b1
ii  libavahi-common3  0.7-4+b1
ii  libavcodec58  7:4.1.3-1
ii  libavformat58 7:4.1.3-1
ii  libavutil56   7:4.1.3-1
ii  libbz2-1.01.0.6-9.2
ii  libc6 2.28-10
ii  libcdio-cdda2 10.2+0.94+2-4
ii  libcdio-paranoia2 10.2+0.94+2-4
ii  libcdio18 2.0.0-2
ii  libcurl3-gnutls   7.65.1-1
ii  libdbus-1-3   1.12.16-1
ii  libexpat1 2.2.7-1
ii  libfaad2  2.8.8-3
ii  libflac8  1.3.2-3
ii  libfluidsynth11.1.11-1+b1
ii  libgcc1   1:9.1.0-10
ii  libgcrypt20   1.8.4-5
ii  libgme0   0.6.2-1
ii  libicu63  63.2-2
ii  libid3tag00.15.1b-14
ii  libiso9660-11 2.0.0-2
ii  libixml10 1:1.8.4-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
ii  libjs-sphinxdoc   1.8.5-2
ii  libmad0   0.15.1b-10
ii  libmikmod33.3.11.1-4
ii  libmms0   0.6.4-3
ii  libmodplug1   1:0.8.9.0-2
ii  libmp3lame0   3.100-2+b1
ii  libmpcdec62:0.1~r495-1+b2
ii  libmpdclient2 2.16-1
ii  libmpg123-0   1.25.10-2
ii  libnfs12  3.0.0-2
ii  libogg0   1.3.2-1+b1
ii  libopenal11:1.19.1-1
ii  libopus0  1.3-1
ii  libpcre3  2:8.39-12
ii  libpulse0 12.2-4
ii  libsamplerate00.1.9-2
ii  libshout3 2.4.1-2
ii  libsidplayfp4 1.8.8-1
ii  libsmbclient  2:4.9.11+dfsg-1
ii  libsndfile1   1.0.28-6
ii  libsoxr0  0.1.2-3
ii  libsqlite3-0  3.29.0-1
ii  libstdc++69.1.0-10
ii  libsystemd0   241-7
ii  libupnp13 1:1.8.4-2
ii  libvorbis0a   1.3.6-2
ii  libvorbisenc2 1.3.6-2
ii  libwavpack1   5.1.0-7
ii  libwildmidi2  0.4.3-1
ii  libyajl2  2.1.0-3
ii  libzzip-0-13  0.13.62-3.2
ii  lsb-base  10.2019051400
ii  zlib1g1:1.2.11.dfsg-1

mpd recommends no packages.

Versions of packages mpd suggests:
ii  avahi-daemon  0.7-4+b1
pn  icecast2  
ii  mpc [mpd-client]  0.31-1
ii  ncmpcpp [mpd-client]  0.8.2-0.1+b1
ii  pulseaudio12.2-4

-- no debconf information

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc

Bug#933271: libreoffice: Should recommend libreoffice-gnome

[Yvan Masson]

Le 28/07/2019 à 21:45, Rene Engelhard a écrit :

Hi,

On Sun, Jul 28, 2019 at 09:17:05PM +0200, Yvan Masson wrote:

So apt install libreoffice would have shown that. But yes, tasksel
wouldn't have shown it.


That is exactly `apt show libreoffice` that gave me the answer :-)
The point is that not everybody has the abilities to use this command and
find that libreoffice-gnome is the pacakge to install.


For them is the desktop task (task-desktop).

As outlined that installs libreoffice-gnome unless you choose an other
desktop yourself.


I don't understand: task-desktop does not recommend libreoffice-gnome. 
During install, if you choose for example: "Desktop environment", 
"LXQT", "print server" and "standard system utilities", then 
libreoffice-gnome won't be installed.


If you choose an other desktop, why would you want someting
GNOME-specific? And if you want, you then need to install what is
missing.


From what I know, GVFS is used by all proposed DE except KDE
- caja recommends gvfs-backends
- thunar recommends gvfs
- pcmanfm and pcmanfm-qt recommend gvfs-backends and gvfs-fuse


And if you don't use the task apt shows the Suggests when apt
install'ing libreoffice.
I don't see a need for a change.

Regards,

Rene


Regards,
Yvan

Bug#933299: isohybrid.pl should not be architecture dependent

[Thomas Schmitt]

Hi,

shouldn't the package which offers isohybrid.pl depend on perl ?
Note that isohybrid.pl prepares an ISOLINUX ISO only for BIOS booting.
Not for EFI, as does isohybrid from the C source.

isohybrid from isohybrid.c would have to be in a package with
  Architecture: any
to produce binary executables for each CPU type.
"Architecture: all" produces only one binary package for all CPUs.
syslinux debian/control file has no "Architecture: any" package yet.


Have a nice day :)

Thomas

Bug#933151: mariadb-10.3: FTBFS on riscv64

[Aurelien Jarno]

Hi,

On 2019-07-26 22:17, Otto Kekäläinen wrote:
> Package: mariadb-10.3
> X-Debbugs-CC: debian-ri...@lists.debian.org
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> 
> The version of the package currently FTBFS on the riscv64 port.
> 
> From 
> https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.3=riscv64=1%3A10.3.16-1=1561225015=0
> 
> 
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.L0 ':
> ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/util/dynamic_bloom.h:177:
> undefined reference to `__atomic_fetch_or_1'
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.LVL1731':
> ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/util/dynamic_bloom.h:179:
> undefined reference to `__atomic_fetch_or_1'
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `SaveValue':
> ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/db/memtable.cc:596:
> undefined reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.L0 ':
> /usr/include/c++/8/bits/atomic_base.h:434: undefined reference to
> `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: 
> librocksdblib.a(memtable.cc.o):/usr/include/c++/8/bits/atomic_base.h:434:
> more undefined references to `__atomic_compare_exchange_1' follow
> collect2: error: ld returned 1 exit status
> 
> If you are an RISC expert, feel free to fork
> https://salsa.debian.org/mariadb-team/mariadb-10.3, play around, and
> make a merge request.

The problem is that RISC-V only provides 4- and 8-byte atomic
instructions, so 1-byte atomic support has to be emulated by libatomic.
There is code for that in the rocksdb build system (however it probably
needs to be patch for riscv64), but it looks like more complex to do in
the mariadb build system.

Note that the issue likely affects some 32-bit architectures that do not
have 8-byte atomic instructions, however rocksdb support is disabled by
default for 32-bit architectures. It's also the strategy we have used
for the version we currently have in unreleased [1]. Here is the
corresponding patch:


diff -Nru mariadb-10.3-10.3.16/debian/rules mariadb-10.3-10.3.16/debian/rules
--- mariadb-10.3-10.3.16/debian/rules   2019-06-19 21:28:52.0 +0200
+++ mariadb-10.3-10.3.16/debian/rules   2019-07-23 17:48:12.0 +0200
@@ -47,6 +47,11 @@
 CMAKEFLAGS += -DWITHOUT_ROCKSDB=true
 endif
 
+# Skip RocksDB on riscv64, as it requires fixes wrt libatomic
+ifeq ($(DEB_HOST_ARCH),riscv64)
+CMAKEFLAGS += -DWITHOUT_ROCKSDB=true
+endif
+
 # Skip TokuDB if arch is not amd64 (also disable for kfreebsd-amd64 as it 
FTBFS)
 # Skipped on the x32 ABI too; untested, but unlikely to work given i386 is not
 # supported.


I don't know if it is something you want to merge in the package or if
you prefer to have a real fix with to the rocksdb support.

Aurelien

[1] http://ftp.ports.debian.org/debian-ports/pool-riscv64/main/m/mariadb-10.3/

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

Bug#933128: Would you be willing to pass Parse::DebianChangelog upstream development to someone else?

[Axel Beckert]

Hi Frank,

the Debian Perl Team maintained libparse-debianchangelog-perl for
quite some years now using debian-specific patches against your
upstream version 1.2.0 from http://www.djpig.de/software/.

Being sick of doing upstream work in form of debian-specific patches,
the Debian Perl Team is currently trying to get rid of
libparse-debianchangelog-perl completely (see
https://bugs.debian.org/933128) which again requires changes in quite
some other packages including prominent ones like lintian,
dh-make-perl and aptitude, see
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=libparse-debian-changelog-perl-removal=debian-perl%40lists.debian.org
(aptitude still missing there).

So some of us wonder if you would generally allow Debian Perl Team
members (or maybe even someone else) to also officially take over the
upstream development of Parse::DebianChangelog — as you seem to have
done for the packaging back in 2015.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Bug#933093: [Pkg-fonts-devel] Bug#933093: Bug#933093: fonts-mononoki: please build from source, -> main

[Fabian Greffrath]

control: tags -1 + patch
control: forwarded -1 https://github.com/googlefonts/ufo2ft/issues/339

Am Freitag, den 26.07.2019, 21:33 +0200 schrieb Fabian Greffrath:
> Currently, it FTBFS:

It seems the following patch is necessary to builf the font from its
glyphs source:

--- a/src/mononoki.glyphs
+++ b/src/mononoki.glyphs
@@ -37,7 +37,7 @@ name = Languagesystems;
 features = (
 {
 automatic = 1;
-code = "feature locl;\012feature frac;\012feature ordn;\012";
+code = "";
 name = aalt;
 }
 );

Though, it is apparently still impossible to generate interpolated
instances, i.e. fontmake has to be called without the `-i` option.

See https://github.com/googlefonts/ufo2ft/issues/339 for some context.

 - Fabian



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

Bug#933300: libocatve-dev should not depend on a toolchain

[Helmut Grohne]

Package: liboctave-dev
Version: 4.4.1-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:mathgl

mathgl fails to satisfy its cross Build-Depends, because its dependency
on liboctave-dev is not satisfiable. liboctave-dev depends on toolchain
packages such as gcc, g++ or gfortran. This is very unusual. Most
commonly, C-libraries can depend on other C-libraries, but users are
expected to install their desired toolchain themselves. These
dependencies need toolchain dependency translation in order to work for
cross building. Unfortunately, toolchain dependency translation is not
yet implemented. Thus I think removing these dependencies is required. I
looked into debian/changelog for why they were added and couldn't find a
reason. Can we simply drop them?

Helmut
diff --minimal -Nru octave-4.4.1/debian/changelog octave-4.4.1/debian/changelog
--- octave-4.4.1/debian/changelog   2019-05-07 11:36:11.0 +0200
+++ octave-4.4.1/debian/changelog   2019-07-28 22:13:38.0 +0200
@@ -1,3 +1,10 @@
+octave (4.4.1-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop toolchain dependencies from liboctave-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 28 Jul 2019 22:13:38 +0200
+
 octave (4.4.1-6) unstable; urgency=medium
 
   * d/copyright: add entry for etc/fonts/* (Closes: #926047)
diff --minimal -Nru octave-4.4.1/debian/control octave-4.4.1/debian/control
--- octave-4.4.1/debian/control 2019-05-07 11:36:11.0 +0200
+++ octave-4.4.1/debian/control 2019-07-28 22:13:38.0 +0200
@@ -173,9 +173,6 @@
  libblas-dev | libblas.so,
  liblapack-dev | liblapack.so,
  libfftw3-dev,
- gfortran,
- gcc,
- g++
 Enhances: octave
 Description: development files for the GNU Octave language
  Octave is a (mostly Matlab (R) compatible) high-level language, primarily

Bug#933247: e2fsprogs FTCBFS: DEB_BUILD_OPTIONS=nocheck no longer works

[Theodore Y. Ts'o]

On Sun, Jul 28, 2019 at 06:21:57PM +0200, Helmut Grohne wrote:
> Hi Ted,
> 
> On Sun, Jul 28, 2019 at 10:04:48AM -0400, Theodore Y. Ts'o wrote:
> > Yes, I had noticed that this was breaking some of the ports build as
> > well, and so I have a similar patch in my tree already.  I was going
> > to wait a few days to see if there were any other issues, and to allow
> > 1.45.3-3 to enter testing before I was going to do another upload.  Is
> > it urgent for you such that you would prefer an upload sooner?
> 
> If you defer it, I'll have to add the patch to rebootstrap.git and later
> revert it. That's unfortunate, but certainly possible. I'll need some
> fix (either in e2fsprogs or rebootstrap), because otherwise I'm blind to
> later failures. Knowing your plans is key here. I'll assume that you
> defer it unless you mail back with 12h.

When I say "defer" I mean for less than a week.  3 days so e2fsprogs
can enter testing, and then usually with the greater exposure, more
bugs get reported, and then a handul of days for me to fix up problems
and re-upload.  If I re-upload now, it resets the unstable->testing
countdown timer, and it further bloats things like
snapshots.debian.org.  I've already uploaded 3 releases in 3 days, so
I figured it might be considered polite if a batched up some changes
instead of continuing to follow a "add a git commit, push a debian
package release" pattern.

How critical is it for rebootstrap.git to be returning a problem for a
handful days?  I guess I'm missing something about why a few days of
it reporting breakage is such a big issue?

> It just occured to me that there might be a simpler implementation
> (untested):
> 
> override_dh_auto_test:
>   dh_auto_test -- V=1

Possibly.  I'm still waiting back from the ia-64 porting folks about
why the m_hugefile test is failing when run on the ia-64 buildd, but
it works just fine when I run it on a ia-64 development machine.  So I
may need to do something special for ia-64, and I haven't yet decided
how to pass in some kind of request (probably using an environment
variable, but I haven't decided for sure yet) so that we skip the
m_hugefile test on ia-64.  (I'm guessing it's due to lack of disk
space, since it requires 1.1G of space in /tmp to run the test, but
I'm not 100% sure.)

So that's another issue that's pending a debian package release, and
another reason why it didn't seem like breaking cross builds for a few
days is such an unacceptable tragedy?  I do like to batch up fixes,
instead of rolling new releases every day or two.

Cheers,

 - Ted

Bug#832369: context: consider symlinking srgb.icc from icc-profiles-free

[Hilmar Preuße]

Am 24.07.2016 um 20:47 teilte Sean Whitton mit:

Hi Norbert, hi Sean,

> For creating PDF/A files, I believe that the colour profile sRGB.icc
> from the icc-profiles-free package is a suitable replacement for the
> non-free srgb.icc that was recently removed from the context package.
> 
> I haven't tested this myself, but my package ocrmypdf uses the free
> sRGB.icc to generate PDF/A files, so I thought it would be worth
> suggesting that you look into it.  If it is indeed a suitable
> replacement, you could have context depend on icc-profiles-free and
> install a symlink in texmf-dist/tex/context/colors/icc/profiles/
> 
Technically I don't have any objections: the new dep just pulls in
1.5MB, which is small in comparison to context itself.

@Sean: context has no files in texmf-dist, hence I'd install in
usr/share/texmf/tex/context/colors/icc/profiles/

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#933299: isohybrid.pl should not be architecture dependent

[Timothy Pearson]

Package: syslinux-utils
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-1

There are two versions of the hybrid ISO utility, a native C implementation and 
a Perl version.  Neither of these should be in the architecture-dependent 
(x86-only) syslinux-utils package, but especially the Perl version of the 
script should be moved to syslinux-common (which is architecture-independent).

Bug#519640:

[Vikas Vikas]

Bug#933298: qcontrold systemd unit possible typo

[Matthieu CERDA]

Package: qcontrol
Version: 0.5.6-4~bpo9+1
Severity: important
Tags: patch

Hello maintainer!

There seems to be a small typo, related to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781886,
in the qcontrold systemd unit.

The unit depends on:
/dev/input/by-path/platform-gpio_keys-event

The actual file to watch for seems to be:
/dev/input/by-path/platform-gpio-keys-event

Here's a patch:
---8<---
--- a/lib/systemd/system/qcontrold.service  2018-05-27 12:00:11.0 
+0200
+++ b/etc/systemd/system/qcontrold.service  2019-07-28 21:22:34.048521392 
+0200
@@ -1,7 +1,7 @@
 [Unit]
 Description=qcontrold
-Requires=dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device
-After=dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device
+Requires=dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device
+After=dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device
 # If the config file is there, we assume qcontrol works on this machine.
 ConditionPathExists=/etc/qcontrol.conf
 
---8<---

Thank you!

-- System Information:
Debian Release: 9.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: armel (armv5tel)

Kernel: Linux 4.19.0-0.bpo.5-marvell
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qcontrol depends on:
ii  libc62.24-11+deb9u4
ii  liblua5.1-0  5.1.5-8.1+b2
ii  udev 232-25+deb9u11

qcontrol recommends no packages.

qcontrol suggests no packages.

-- no debconf information

Bug#933297: RFS: dmagnetic/0.17-1

[dettus]

Package: sponsorship-requests
  Severity: wishlist

  Dear mentors,

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

 * Package name: dmagnetic
   Version : 0.17-1
   Upstream Author : Thomas Dettbarn 
 * URL : http://www.dettus.net/dMagnetic
 * License : BSD 2 clause
   Section : games

  It builds those binary packages:

dmagnetic - A Magnetic Scrolls Interpreter
 It can be used to play classic text adventure games, such as "The Pawn",
"The guild of Thieves", "Jinxter", "Fish!", "Myth", "Corruption" and
"Wonderland".

The beautiful graphics are being rendered in glorious ANSI-Art, or even

ASCII-Art, if you prefer. But see for yourself:
  
> GO EAST



STONE BRIDGE 0/3

...::.:::.:::.:::...
...++-=++-=++-=+=...
...+++=+=...
:-====+++=++*=-:--===-==
==+=++*#x#x*$XX+xx#x*x+++$$X*x+*
+++**x$*$XX+xxx*x*#xx*++*#xx$x***xx*
++##XXX+++**=x$x*xx#x**$x$xx*xx*
++*x#$Xx++x$+**$*+=+x*#xxx*xx*x#xx#x
****x#$*++x#**xx*+++x$$xxx**##xxX$x*x*x#x*x#
x*x*=++xx*x*xxx#xxx$x#x*x$xx*$#x$xx*x##xxx#**x**
xxx**x#x*=*#*++***=+xx$#$#X#x$$xx#$#*x*xx#**
***x*x$$xx**xx**xx*+=*x*#$#$$$xxx$$$#x**xx**
x*##xxx#$xx*xxx#xx===+*x+xx###$$#x#$xx$#*x*x$xxx
xxx*+*xx*xx#==+***+xx###$#xx+*+*
==+***xxx$*#x+++*+#xx$xx$$###xxx
==+x#x$xx$*x+*x*=$xx#*#$#xx*
xx#$xx$x*#**xx*++#+x$*$$=$$#
*xxx$xx#x+#x===*+==*#*##x$$+x$$#
#$x#$x+xx+*=*x*++=x#xX#xx$#x
#$x#X#x#x+++*xxx*x##*X$$$X#*
Stone Bridge
You are  near the  edge of  a cliff.  To the  east, a  stone
bridge spans a  deep ravine at  the bottom of  which runs  a
fast  flowing  river.  Westward  leads  onto  an  extensive,
grassy plain.

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dmagnetic/dmagnetic_0.17-1.dsc

  More information about dmagnetic can be obtained from 
http://www.dettus.net/dMagnetic

  Changes since the last upload:

  I updated from release 0.16 to 0.17. And I am desperately waiting for a 
sponsor.


  Regards,
   Thomas Dettbarn

Bug#933296: libcollectdclient1 should not recommend collectd

[Bernhard Schmidt]

Package: libcollectdclient1
Version: 5.8.1-1.3
Severity: normal

Hi,

freeradius (more exactly, freeradius-utils) is currently depending on 
libcollectdclient1 . libcollectdclient1 recommends collectd, which in turn
pulls in 200 packages including Gtk, the OpenJDK JRE, bind9 (!), ceph (!!),
etc.

The following NEW packages will be installed:
  adwaita-icon-theme at-spi2-core ca-certificates-java collectd
  collectd-core dbus-user-session dconf-gsettings-backend dconf-service
  default-jre-headless fontconfig fontconfig-config fonts-dejavu-core
  freeradius freeradius-common freeradius-config freeradius-utils
  freetds-common glib-networking glib-networking-common
  glib-networking-services gsettings-desktop-schemas gtk-update-icon-cache
  hicolor-icon-theme intel-cmt-cat java-common libapr1 libasound2
  libasound2-data libatasmart4 libatk-bridge2.0-0 libatk1.0-0
  libatk1.0-data libatspi2.0-0 libavahi-client3 libavahi-common-data
  libavahi-common3 libbluetooth3 libc-ares2 libcairo-gobject2 libcairo2
  libcollectdclient1 libcolord2 libconfuse-common libconfuse2 libcroco3
  libct4 libcups2 libcurl3-gnutls libdatrie1 libdbi-perl libdbi1 libdconf1
  libepoxy0 libesmtp6 libfontconfig1 libfreeradius3 libfribidi0 libftdi1-2
  libganglia1 libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-bin
  libgdk-pixbuf2.0-common libgoogle-perftools4 libgps23 libgraphite2-3
  libgrpc++1 libgrpc6 libgtk-3-0 libgtk-3-bin libgtk-3-common libharfbuzz0b
  libhiredis0.14 libi2c0 libjansson4 libjbig0 libjpeg62-turbo
  libjson-glib-1.0-0 libjson-glib-1.0-common liblcms2-2 liblua5.1-0
  liblua5.3-0 libmemcached11 libmicrohttpd12 libmodbus5 libmosquitto1
  libnl-3-200 libnl-route-3-200 libnotify4 libnspr4 libnss3 libnuma1
  liboping0 libow-3.2-3 libowcapi-3.2-3 libpango-1.0-0 libpangocairo-1.0-0
  libpangoft2-1.0-0 libpcap0.8 libpcsclite1 libpixman-1-0 libpq5
  libprotobuf17 libproxy1v5 libpython2.7 librabbitmq4 librdkafka1
  librest-0.7-0 libriemann-client0 librrd8 librsvg2-2 librsvg2-common
  librte-acl18.11 librte-bbdev18.11 librte-bitratestats18.11
  librte-bpf18.11 librte-cfgfile18.11 librte-cmdline18.11
  librte-compressdev18.11 librte-cryptodev18.11 librte-distributor18.11
  librte-eal18.11 librte-efd18.11 librte-ethdev18.11 librte-eventdev18.11
  librte-flow-classify18.11 librte-gro18.11 librte-gso18.11
  librte-hash18.11 librte-ip-frag18.11 librte-jobstats18.11 librte-kni18.11
  librte-kvargs18.11 librte-latencystats18.11 librte-lpm18.11
  librte-mbuf18.11 librte-member18.11 librte-mempool18.11 librte-meter18.11
  librte-metrics18.11 librte-net18.11 librte-pci18.11 librte-pdump18.11
  librte-pipeline18.11 librte-port18.11 librte-power18.11
  librte-rawdev18.11 librte-reorder18.11 librte-ring18.11 librte-sched18.11
  librte-security18.11 librte-table18.11 librte-telemetry18.11
  librte-timer18.11 librte-vhost18.11 libsoup-gnome2.4-1 libsoup2.4-1
  libtalloc2 libtcmalloc-minimal4 libthai-data libthai0 libtiff5
  libtokyocabinet9 libtokyotyrant3 libunwind8 libupsclient4 libvarnishapi2
  libvirt0 libwayland-client0 libwayland-cursor0 libwayland-egl1
  libwbclient0 libwebp6 libxcb-render0 libxcb-shm0 libxcomposite1
  libxcursor1 libxdamage1 libxencall1 libxendevicemodel1 libxenevtchn1
  libxenforeignmemory1 libxengnttab1 libxenmisc4.11 libxenstore3.0
  libxentoolcore1 libxentoollog1 libxfixes3 libxi6 libxinerama1
  libxkbcommon0 libxrandr2 libxrender1 libxtst6 libyajl2 make
  notification-daemon openjdk-11-jre-headless owfs-common rrdtool
  x11-common
0 upgraded, 200 newly installed, 0 to remove and 0 not upgraded.
Need to get 88.8 MB of archives.
After this operation, 334 MB of additional disk space will be used.

Dropping the recommends from libcollectdclient1 to collectd reduces this list
to 15 packages, 3200 kB getting downloaded, and 10.5 MB getting used.

IMHO a supporting library should not pull in such a large packet list (yes, I
know you can disable Recommends).

Bernhard

Bug#933295: squid: Race-condition in start script when cache dir structure doesn't exist

[Daniel Reichelt]

Package: squid
Version: 4.6-1
Severity: normal
Tags: patch

Hi,

first of all: I'm running sysvinit-core instead of systemd.

When squid starts and the cache directory structure below /var/spool/squid
doesn't exist yet, /etc/init.d/squid calls `squid -z -f $CONFIG` to create the
directories and start-stop-daemon thereafter for the actual launch. `squid -z`
however seems to fork to the background, making start-stop-daemon think it's
already running (return code 1).

Adding -N to `squid -z` (No daemon mode) solved the issue for me: `squid -z`
only returns after the directory structure has been created, letting
start-stop-daemon do its job.


Cheers
Daniel


-- System Information:
Debian Release: 10.0
  APT prefers proposed-updates
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)

Bug#933271: libreoffice: Should recommend libreoffice-gnome

[Rene Engelhard]

Hi,

On Sun, Jul 28, 2019 at 09:17:05PM +0200, Yvan Masson wrote:
> > So apt install libreoffice would have shown that. But yes, tasksel
> > wouldn't have shown it.
> > 
> That is exactly `apt show libreoffice` that gave me the answer :-)
> The point is that not everybody has the abilities to use this command and
> find that libreoffice-gnome is the pacakge to install.

For them is the desktop task (task-desktop).

As outlined that installs libreoffice-gnome unless you choose an other
desktop yourself.

If you choose an other desktop, why would you want someting
GNOME-specific? And if you want, you then need to install what is
missing.

And if you don't use the task apt shows the Suggests when apt
install'ing libreoffice.

I don't see a need for a change.

Regards,

Rene

Bug#933274: thunderbird: TB recreates .icedove profile dir if missing, will not start at next launch

[Carsten Schoenert]

Hello Andrea,

Am 28.07.19 um 19:50 schrieb Andrea Borgia:

> This system has gone through the thunderbird->icedove->thunderbird
> conversions; launching thunderbird with a real .thunderbird profile
> directory and no .icedove, thunderbird will recreate .icedove as a
> directory,

this is with recent versions of Thunderbird not possible anymore as this
is hard coded within the sources. I never had experienced something like
you have described.
And further more the logic in the starting wrapper script checks exactly
this as first use case and will leave the loop for checking things as
having ~/.thunderbird folder the default again.

> so that following attempts to run it will fail with a conversion
> error.  If I remove the .icedove directory and replace it with a symlink to
> .thunderbird, the program will start happily.

For sure, as this one of the conditions the wrapper is checking.
But why do you delete any folder if Thunderbird working correctly?
Please don't try to be smarter than the binary is working.

Any Apparmore profile for TB activated?

> Thinking it might have been an incomplete conversion, I quit the program,
> removed the .icedove symlink, renamed .thunderbird to .icedove and restarted
> the program.  Once the conversion was done, I closed the program and
> verified I had my ".icedove" (formerly .thunderbird) directory and a new
> .thunderbird symlink.  I deleted this symlink and renamed .icedove to
> .thunderbird: no luck, again .icedove as real dir at the first run and an
> error at the next.
> 
> First I though this was #857029 again but it turned out that, for some
> reason, this profile still had a "prefs.js" which referenced ".icedove":
> manually editing this file fixed the issue for good.  Shouldn't this file be
> migrated too?

This is on the user side as one packaging rule strictly says we don't
change anything within the users folder while package installation or
upgrade. And adding a symlink that probably will never break things
within the users home folder is quite the maximum we can do.

I was thinking about some external helping script that could do this
migration but due lack of interests and urgency I haven't work further
here. And it's mainly just the moving of '.icedove' to '.thunderbird' in
the prefs.js file. But other extensions can have there own setting
withing the TB profile!

-- 
Regards
Carsten Schoenert

Bug#932845: TS-219 RTC issue with Debian Buster

[Uwe Kleine-König]

Control: tag -1 + fixed-upstream pending

Hello Oliver,

I tried to reproduce your problem on v5.3 and there the problem doesn't
occur even without CONFIG_RTC_INTF_DEV_UIE_EMUL. The reason can be found
in

https://git.kernel.org/linus/c0e12848be091e8410fb427f080f2e0149123443

which got into 5.3-rc1. With this hwclock (from util-linux) still tries
to enable UIE (which fails) but reading out the date and time still
works.

I backported that fix to the buster branch, see https://deb.li/PDJ2 .

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Bug#933278: kmail: Kmail printing Mails prints blank pages

[Scott Kitterman]

On July 28, 2019 6:00:28 PM UTC, "Michael Müller"  wrote:
>Package: kmail
>Version: 4:18.08.3-1
>Severity: normal
>
>Dear Maintainer,
>
>when printing mails, kmail only prints blank pages, also when printing
>to PDF or in the pre-view.
>
I have run into this problem too, but I hadn't gotten around to filing a bug.

Scott K


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

Bug#933294: qcontrol fails to do anything on QNAP TS-109

[Matthieu CERDA]

Package: qcontrol
Version: 0.5.6-4~bpo9+1
Severity: important

Greetings, package maintainer!

I am running a QNAP TS-109 NAS on Debian, and post installation I noticed that 
qcontrol seemed not
to work properly: the NAS does not beep post-boot, and the status led stays 
red/green blinking.

Trying to use qcontrol directly outputs no error, but does nothing:
---8<---
root@vault:~# qcontrol --direct statusled greenon
Register evdev on /dev/input/by-path/platform-gpio-keys-event
confdir: loading from /etc/qcontrol.d...
(no led change)
root@vault:~# qcontrol --direct buzzer short
Register evdev on /dev/input/by-path/platform-gpio-keys-event
confdir: loading from /etc/qcontrol.d...
(no buzzer sound)
---8<---

It looks like it might be a kernel-related problem, as I can see in dmesg:
---8<---
root@vault:~# dmesg|grep gpio
[   21.616406] synth uevent: /gpiochip0: failed to send uevent
[   21.616455] gpio gpiochip0: uevent: failed to send synthetic uevent
[   31.732294] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[   34.725122] synth uevent: /gpiochip0: failed to send uevent
[   34.725173] gpio gpiochip0: uevent: failed to send synthetic uevent
---8<---

-- System Information:
Debian Release: 9.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: armel (armv5tel)

Kernel: Linux 4.19.0-0.bpo.5-marvell
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qcontrol depends on:
ii  libc62.24-11+deb9u4
ii  liblua5.1-0  5.1.5-8.1+b2
ii  udev 232-25+deb9u11

qcontrol recommends no packages.

qcontrol suggests no packages.

-- no debconf information

Bug#826174: pgf: \pgfuseplotmark{triangle*} results in an offset triangle

[Hilmar Preuße]

Am 03.06.2016 um 01:23 teilte mwilkins mit:

Hi Matt,

I tried to reproduce the problem. Even w/ 1200% magnification I don't
see any difference. Attached are two pdf files, one w/ the original
pgflibraryplotmarks.code.tex one time w/ the described fix.

Can you still reproduce the problem?

Hilmar

> The file
>/usr/share/texmf/tex/generic/pgf/libraries/pgflibraryplotmarks.code.tex
> is buggy.  When you use the tex command
>\pgfuseplotmark{triangle*}
> the triangle does not appear in the correct position, it is shifted to
> the right by a little bit.  You can google this problem and see that
> the solution is to append % to the lines in the definition of
> \pgfdeclareplotmark{triangle*}.  You know in tex, newlines in
> definitions often muck things up, you need to stick the comment on the
> end of the line to fix it up.   Actually you probably could patch all
> the other definitions in the file, but I only used the triangle* and
> triangle so only tested it with those.
> 
> Here is a small test case for you:
> 
>\documentclass{article}
> 
>\usepackage{tikz}
>\usetikzlibrary{plotmarks}
> 
>\begin{document}
>\begin{tikzpicture}
>\draw (-1, 0) -- (1, 0);
>\draw (0, -1) -- (0, 1);
>\node at (0,0) {\pgfuseplotmark{triangle*}};
>\end{tikzpicture}
> 
>\end{document}
> 
> Just save it in a .tex file, pdflatex it, and view the pdf file.  The
> triangle is not at (0, 0).  Then edit 
>/usr/share/texmf/tex/generic/pgf/libraries/pgflibraryplotmarks.code.tex
> making sure the triangle* section looks like this
> 
>% A stroke-filled triangle mark
> 
>\pgfdeclareplotmark{triangle*}
>{%
>  \pgfpathmoveto{\pgfqpoint{0pt}{\pgfplotmarksize}}%
>  \pgfpathlineto{\pgfqpointpolar{-30}{\pgfplotmarksize}}%
>  \pgfpathlineto{\pgfqpointpolar{-150}{\pgfplotmarksize}}%
>  \pgfpathclose%
>  \pgfusepathqfillstroke
>}
> 
> and everything will be fine, the triangle will appear exactly at (0, 0).
> 
> I did attempt to get this fixed upstream, but never got anywhere with them.
> Perhaps we can just have a patch in debian?  Or you could try to push
> it upstream and you will have more traction than I?
> 


-- 
sigfault
#206401 http://counter.li.org


826174.pdf
Description: Adobe PDF document


826174_1.pdf
Description: Adobe PDF document


signature.asc
Description: OpenPGP digital signature

Bug#933271: libreoffice: Should recommend libreoffice-gnome

[Yvan Masson]

Le 28/07/2019 à 17:38, Rene Engelhard a écrit :

Hi,

On Sun, Jul 28, 2019 at 05:34:41PM +0200, Rene Engelhard wrote:

Could you make libreoffice (or another package like task-desktop) recommends
libreoffice-gnome?


As shown above, task-desktop recommends task-gnome-desktop which already
does what you want.


And just for the record:

$ apt-cache show libreoffice
Package: libreoffice
Version: 1:6.1.5-3+deb10u2
Installed-Size: 92
Maintainer: Debian LibreOffice Maintainers

Architecture: amd64
Depends: libreoffice-base, libreoffice-calc, libreoffice-core (=
1:6.1.5-3+deb10u2), libreoffice-draw, libreoffice-impress,
libreoffice-math, libreoffice-report-builder-bin, libreoffice-writer,
libreoffice-avmedia-backend-gstreamer | libreoffice-avmedia-backend-vlc,
python3-uno (>= 4.4.0~beta2)
Suggests: cups-bsd, firefox-esr | thunderbird | firefox, ghostscript,
gnupg, gpa, hunspell-dictionary, hyphen-hyphenation-patterns,
imagemagick | graphicsmagick-imagemagick-compat, libgl1,
libreoffice-gnome | libreoffice-kde5, [...]

So apt install libreoffice would have shown that. But yes, tasksel
wouldn't have shown it.


That is exactly `apt show libreoffice` that gave me the answer :-)
The point is that not everybody has the abilities to use this command 
and find that libreoffice-gnome is the pacakge to install.


Regards,
Yvan

Bug#933293: /usr/bin/debchange: dch: any and all uploads to experimental should have urgency=low

[Thorsten Glaser]

Package: devscripts
Version: 2.19.5
Severity: normal
File: /usr/bin/debchange

Due to #831699 any and all uploads to experimental should have
“urgency=low”.

Please adjust the default urgency for things like “dch -i”,
“dch --qa”, “dch --team”, etc. when the previous upload was
to experimental already and/or the distribution is set to
experimental, o̲r̲ consider reverting the change of the default
urgency to medium.

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBCHANGE_AUTO_NMU=no
DEBCHANGE_MAINTTRAILER=no
DEBCHANGE_MULTIMAINT_MERGE=yes
DEBCHANGE_RELEASE_HEURISTIC=log

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.7
ii  fakeroot  1.23-1
ii  file  1:5.35-4
ii  gnupg 2.2.13-2
ii  gnupg22.2.13-2
ii  gpgv  2.2.13-2
ii  libc6 2.28-10
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-1
ii  libmoo-perl   2.003004-2
ii  libwww-perl   6.36-2
ii  patchutils0.3.4-2
ii  perl  5.28.1-6
ii  python3   3.7.3-1
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.2
ii  at  3.1.23-1
ii  curl7.64.0-4
ii  dctrl-tools 2.24-3
ii  debian-keyring  2019.06.25
ii  dput1.0.3
ii  equivs  2.2.0
pn  libdistro-info-perl 
ii  libdpkg-perl1.19.7
ii  libencode-locale-perl   1.05-1
pn  libgit-wrapper-perl 
pn  libgitlab-api-v4-perl   
pn  liblist-compare-perl
ii  liblwp-protocol-https-perl  6.07-2
pn  libsoap-lite-perl   
pn  libstring-shellquote-perl   
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
pn  licensecheck
ii  lintian 2.15.0
ii  man-db  2.8.5-2
ii  patch   2.7.6-4
ii  python3-apt 1.8.4
ii  python3-debian  0.1.35
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.21.0-1
pn  python3-unidiff 
pn  python3-xdg 
ii  strace  4.26-0.2
ii  unzip   6.0-23
ii  wget1.20.1-1.1
ii  xz-utils5.2.4-1

Versions of packages devscripts suggests:
ii  adequate  0.15.2
pn  autopkgtest   
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20180807cvs-1
ii  build-essential   12.6
pn  check-all-the-things  
pn  cvs-buildpackage  
ii  debhelper 12.1.1
pn  devscripts-el 
ii  diffoscope116
pn  disorderfs
pn  dose-extra
pn  duck  
pn  faketime  
pn  gnuplot   
pn  how-can-i-help
pn  libauthen-sasl-perl   
ii  libdbd-pg-perl3.7.4-3
pn  libfile-desktopentry-perl 
pn  libnet-smtps-perl 
pn  libterm-size-perl 
ii  libtimedate-perl  2.3000-2
ii  libyaml-syck-perl 1.31-1+b1
pn  mozilla-devscripts
pn  mutt  
ii  openssh-client [ssh-client]   1:7.9p1-10
pn  piuparts  
ii  postgresql-client-11 [postgresql-client]  11.4-1
ii  quilt 0.65-3
pn  ratt  
pn  reprotest 
pn  svn-buildpackage  
ii  w3m   0.5.3-37

-- no debconf information

Bug#933292: libcurl4-openssl-dev: CURL_OPENSSL_3 is not included in package. Dependent packages fail.

[Reto]

Package: libcurl4-openssl-dev
Version: 7.64.0-4
Severity: normal
Tags: a11y

Dear Maintainer,

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

   * What led up to the situation?
   ** We run a package on the system which depends on the "CURL_OPENSSL_3" 
library
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   ** We have tried a workaround or so
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages libcurl4-openssl-dev depends on:
ii  libcurl4  7.64.0-4

libcurl4-openssl-dev recommends no packages.

Versions of packages libcurl4-openssl-dev suggests:
pn  libcurl4-doc   
pn  libidn11-dev   
pn  libkrb5-dev
pn  libldap2-dev   
pn  librtmp-dev
pn  libssh2-1-dev  
ii  libssl-dev 1.1.1c-1
pn  pkg-config 
pn  zlib1g-dev 

-- no debconf information

Bug#537284: Ligature fi becoming ø in avant garde

[Hilmar Preuße]

Control: forwarded 537284 https://puszcza.gnu.org.ua/bugs/index.php?433

Am 16.07.2009 um 19:27 teilte Anthony DeRobertis mit:

> The following input:
> 
> with the following command:
> 
>   mk4ht htlatex a.tex "html,uni-html4,css2,charset=utf-8,info" " -cunihtf 
> -utf8"
> 
> gets the following HTML output:
> 
>   first
> 
>   ørst 
> 
> Notice how the fi (fi; U+FB01) ligature becomes ø (small o stroke; U+00F8).
> 
Forwarded to upstream for now.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#933291: RM: lazarus-1.8 lazarus-doc-1.8 lazarus-src-1.8 -- NBS; Cruft, not build anymore

[Paul Gevers]

Package: ftp.debian.org
Severity: normal

The lazarus source package builds several packages with the upstream
version in the name to enable developers to keep older versions
installed when we update to a new version, although in Debian we only
ship one version.

There are three arch:all packages involved. lazarus-1.8 lazarus-doc-1.8
lazarus-src-1.8 are still left from the previous upstream release.

Please remove:
lazarus-1.8 arch:all
lazarus-doc-1.8 arch:all
lazarus-src-1.8 arch:all

Thanks,
Paul



signature.asc
Description: OpenPGP digital signature

Bug#933139: bind9 fails on startup: can't find /var/cache/bind

[Bernhard Schmidt]

Control: tags -1 moreinfo

Am 26.07.19 um 22:50 schrieb Ross Boylan:

Hi Ross,

> * What led up to the situation?
> 
>Start or restart the system.  bind9 attempts to start, but fails
>with the error that it is unable to cd to /var/cache/bind.  This
>happens every time.
> 
>New installation of buster with existing customizations from an old
>system ported over, with adoptions.
> 
>resolvconf in use.
> 
>/var is a separate partition.  See details below for my theory the
>failure arises from a race condition in which bind starts before
>/var is mounted.

I think this is more of a systemd bug or local misconfiguration than a
bind9 bug.

> The root partition includes /var/cache, but no /var/cache/bind.
> When the partition with /var is mounted it has a /var/cache/bind
> directory.

Is there a reason for this? I think having a non-empty mount target is
somewhat unusual, maybe this is causing the systemd mount dependency
logic to fail.

> /var is encrypted on top of lvm, so it takes a bunch of steps to mount
> it.  However, it does not require me to enter any new passwords to
> decrypt it.  The root partition does require me to enter a password,
> which happens early in startup.

Are there manual steps involved mounting /var?

How does your /etc/fstab look like?

Bernhard

Bug#933280: BD on texlive-generic-extra which isn't build anymore and isn't in bullseye

[Paul Gevers]

Source: breathe
Version: 4.11.1-1
Severity: serious
Tags: ftbfs sid bullseye

Recently the texlive-base package has stopped building the transitional
package texlive-generic-extra. This is an issue for your package as it
build-depends on it. Please update the building of your package to use
texlive-plain-generic instead.

Unfortunately the migration software doesn't detected this kind of
situation yet, so your package also FTBFS in bullseye since 2019-07-16.

Paul





signature.asc
Description: OpenPGP digital signature

Bug#933279: pytables: BD on texlive-generic-extra which isn't build anymore and isn't in bullseye

[Paul Gevers]

Source: pytables
Version: 3.4.4-2
Severity: serious
Tags: ftbfs sid bullseye

Recently the texlive-base package has stopped building the transitional
package texlive-generic-extra. This is an issue for your package as it
build-depends on it. Please update the building of your package to use
texlive-plain-generic instead.

Unfortunately the migration software doesn't detected this kind of
situation yet, so your package also FTBFS in bullseye since 2019-07-16.

This is currently also blocking migration of your package to testing.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#933278: kmail: Kmail printing Mails prints blank pages

[Michael Müller]

Package: kmail
Version: 4:18.08.3-1
Severity: normal

Dear Maintainer,

when printing mails, kmail only prints blank pages, also when printing to PDF 
or in the pre-view.

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages kmail depends on:
ii  akonadi-server   4:18.08.3-5
ii  kdepim-runtime   4:18.08.3-4
ii  kio  5.54.1-1
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libgpgmepp6  1.12.0-6
ii  libkf5akonadiagentbase5  4:18.08.3-5
ii  libkf5akonadicontact54:18.08.3-1
ii  libkf5akonadicore5abi2   4:18.08.3-5
ii  libkf5akonadimime5   4:18.08.3-1
ii  libkf5akonadisearch-bin  4:18.08.3-1
ii  libkf5akonadisearch-plugins  4:18.08.3-1
ii  libkf5akonadisearchdebug54:18.08.3-1
ii  libkf5akonadisearchpim5  4:18.08.3-1
ii  libkf5akonadiwidgets5abi14:18.08.3-5
ii  libkf5bookmarks5 5.54.0-1
ii  libkf5calendarcore5abi2  4:18.08.3-1
ii  libkf5calendarutils5 4:18.08.3-2
ii  libkf5codecs55.54.0-1
ii  libkf5completion55.54.0-1
ii  libkf5configcore55.54.0-1
ii  libkf5configgui5 5.54.0-1
ii  libkf5configwidgets5 5.54.0-1
ii  libkf5contacts5  4:18.08.3-1
ii  libkf5coreaddons55.54.0-1
ii  libkf5crash5 5.54.0-1
ii  libkf5dbusaddons55.54.0-1
ii  libkf5followupreminder5  4:18.08.3-2
ii  libkf5grantleetheme-plugins  18.08.3-1
ii  libkf5gravatar5abi2  4:18.08.3-1
ii  libkf5guiaddons5 5.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5iconthemes55.54.0-1
ii  libkf5identitymanagement518.08.3-2
ii  libkf5itemmodels55.54.0-1
ii  libkf5itemviews5 5.54.0-1
ii  libkf5jobwidgets55.54.0-1
ii  libkf5kcmutils5  5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5kiofilewidgets55.54.1-1
ii  libkf5kiowidgets55.54.1-1
ii  libkf5kontactinterface5  18.08.3-1
ii  libkf5ksieveui5  4:18.08.3-2
ii  libkf5libkdepim-plugins  4:18.08.3-2
ii  libkf5libkdepim5 4:18.08.3-2
ii  libkf5libkdepimakonadi5  4:18.08.3-2
ii  libkf5libkleo5   4:18.08.3-2
ii  libkf5mailcommon5abi24:18.08.3-2
ii  libkf5mailtransport5 18.08.3-2
ii  libkf5mailtransportakonadi5  18.08.3-2
ii  libkf5messagecomposer5abi1   4:18.08.3-2
ii  libkf5messagecore5abi1   4:18.08.3-2
ii  libkf5messagelist5abi1   4:18.08.3-2
ii  libkf5messageviewer5abi1 4:18.08.3-2
ii  libkf5mime5abi1  18.08.3-1
ii  libkf5mimetreeparser5abi14:18.08.3-2
ii  libkf5notifications5 5.54.0-1
ii  libkf5notifyconfig5  5.54.0-1
ii  libkf5parts5 5.54.0-1
ii  libkf5pimcommon5abi2 4:18.08.3-2
ii  libkf5pimcommonakonadi5abi1  4:18.08.3-2
ii  libkf5pimtextedit5abi2   18.08.3-1
ii  libkf5sendlater5 4:18.08.3-2
ii  libkf5service-bin5.54.0-1
ii  libkf5service5   5.54.0-1
ii  libkf5sonnetui5  5.54.0-1
ii  libkf5templateparser54:18.08.3-2
ii  libkf5textwidgets5   5.54.0-1
ii  libkf5tnef5  4:18.08.3-1
ii  libkf5wallet-bin 5.54.0-1
ii  libkf5wallet55.54.0-1
ii  libkf5webengineviewer5abi1   4:18.08.3-2
ii  libkf5widgetsaddons5 5.54.0-1
ii  libkf5windowsystem5  5.54.0-1
ii  libkf5xmlgui55.54.0-1
ii  libqgpgme7   1.12.0-6
ii  libqt5core5a 5.11.3+dfsg1-1
ii  libqt5dbus5  5.11.3+dfsg1-1
ii  libqt5gui5   5.11.3+dfsg1-1
ii  libqt5network5   5.11.3+dfsg1-1
ii  libqt5widgets5   5.11.3+dfsg1-1
ii  libqt5xml5   5.11.3+dfsg1-1
ii  libstdc++6   8.3.0-6

Versions of packages kmail recommends:
ii  accountwizard   4:18.08.3-1
ii  gnupg   2.2.12-1
ii  kdepim-addons   18.08.3-2
ii  kdepim-themeeditors 4:18.08.3-1
ii  mbox-importer   4:18.08.3-1
ii  pim-data-exporter   4:18.08.3-1
ii  pim-sieve-editor4:18.08.3-1
ii  pinentry-qt [pinentry-x11]  1.1.0-2

Versions of packages kmail 

Bug#933277: [agent-transfer] Depends on dummy transitional package

[Felix Lechner]

Package: agent-transfer
Severity: minor

Dear Maintainer,

The package 'agent-transfer' depends on the dummy transitional package
'gnupg-agent'. Please update the dependency to the similarly named
'gpg-agent', or offer the latter as an installation alternative.

Users of your software can then remove the transitional package, as
recommended its description, or avoid the installation altogether.

Kind regards
Felix Lechner

Bug#933276: libboost-all-dev: Depends on libboost-context-dev which does not exist on x32, causing BD-Uninstallable

[Thorsten Glaser]

Package: libboost-all-dev
Version: 1.67.0.1
Severity: important

Dependency installability problem for performous on x32:

performous build-depends on:
- libboost-all-dev:x32 (>= 1.67.0.1)
libboost-all-dev depends on:
- libboost-context-dev:x32
libboost-context-dev depends on missing:
- libboost-context1.67-dev:x32

Apparently, libboost-all-dev depends on libboost-context-dev only
on platforms where libboost-context-dev actually exists… and x32.

Please fix, this ought to be easy.

Thanks in advance!

-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libboost-all-dev depends on:
pn  libboost-atomic-dev   
pn  libboost-chrono-dev   
pn  libboost-container-dev
pn  libboost-context-dev  
pn  libboost-coroutine-dev
pn  libboost-date-time-dev
pn  libboost-dev  
pn  libboost-exception-dev
pn  libboost-fiber-dev
pn  libboost-filesystem-dev   
pn  libboost-graph-dev
pn  libboost-graph-parallel-dev   
pn  libboost-iostreams-dev
pn  libboost-locale-dev   
pn  libboost-log-dev  
pn  libboost-math-dev 
pn  libboost-mpi-dev  
pn  libboost-mpi-python-dev   
pn  libboost-numpy-dev
pn  libboost-program-options-dev  
pn  libboost-python-dev   
pn  libboost-random-dev   
pn  libboost-regex-dev
pn  libboost-serialization-dev
pn  libboost-signals-dev  
pn  libboost-stacktrace-dev   
pn  libboost-system-dev   
pn  libboost-test-dev 
pn  libboost-thread-dev   
pn  libboost-timer-dev
pn  libboost-tools-dev
pn  libboost-type-erasure-dev 
pn  libboost-wave-dev 

libboost-all-dev recommends no packages.

libboost-all-dev suggests no packages.

Bug#931974: O: festvox-ru - Russian male speaker for Festival

[Samuel Thibault]

control: retitle -1 ITA: festvox-ru - Russian male speaker for Festival
control: tags -1 + pending

Sergey B Kirpichev, le dim. 28 juil. 2019 20:16:12 +0300, a ecrit:
> Thank you, I did.  Hopefully, everything ok.

Yep, I could push the maintenance switch.

Samuel

Bug#931974: O: festvox-ru - Russian male speaker for Festival

[Samuel Thibault]

Sergey B Kirpichev, le dim. 28 juil. 2019 20:16:12 +0300, a ecrit:
> Thank you, I did.  Hopefully, everything ok.

Yep, thanks!

Samuel

Bug#917663: vdr-plugin-dvbhddevice: FTBFS: dvbhdffdevice.c:569:33: error: 'AUDIO_GET_PTS' was not declared in this scope

[Tobias Grimm]

Version: 2.2.0-10

Bug#931965: New Debian package squashfs-tools-ng_0.4.2

[David Oberhollenzer]

Hi,

I published an early 0.5 release based on the latest "stable point" of the
git tree:

https://infraroot.at/pub/squashfs/squashfs-tools-ng-0.5.tar.xz

The stable point has been chosen to be right after fixing stuff from multiple
hours of chewing on the Debian live CD squashfs image and pushing the Coverity
defect density below 0.1, and right before starting on a new feature that isn't
quite stable yet.

It doesn't contain everything I wanted for this release but at least it
contains the important fixes and the updated README.


If there really is a dispute now over the *two sentences* from the
description in the control file, how about this:

> New set of tools for working with SquashFS images
> 
> SquashFS is a highly compressed read-only filesystem for Linux, optimized
> for small size and high packing density. It is widely used in embedded
> systems and bootable live media.
>
> SquashFS supports many different compression formats, such as zstd, xz,
> zlib or lzo for both data and metadata compression. It has many features
> expected from popular filesystems, such as extended attributes and support
> for NFS export.
>
> As the name suggests, this is not the original user space tooling for
> SquashFS. Here are some of the features that primarily distinguish this
> package from the original:
>   - reproducible, deterministic packing without any local time stamps,
>   - Linux `gen_init_cpio` like file listing for micro managing the
> file system contents, permissions, and ownership without having to
> replicate the file system (and especially permissions) locally,
>   - support for SELinux contexts file (see selabel_file(5)) to generate
> SELinux labels.
>   - support for directly turning a tarball into a SquashFS image and back


Regards,

David

Bug#933275: expects valgrind in own binary dir, fails to run tests with --valgrind option

[Simon Richter]

Package: piglit
Version: 0~git20180515-62ef6b0db-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

running piglit tests with the --valgrind option gives a results file with
all tests marked as skipped:

"result": "skip",
"command": "/usr/lib/x86_64-linux-gnu/piglit/bin/valgrind",
"out": "An internal exception that should have been handled was 
not:\nTest executable not found.\n",

   Simon

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages piglit depends on:
ii  libc62.28-10
ii  libdrm-intel12.4.97-1
ii  libdrm2  2.4.97-1
ii  libegl1  1.1.0-1
ii  libgbm1  18.3.6-2
ii  libgcc1  1:8.3.0-6
ii  libgl1   1.1.0-1
ii  libstdc++6   8.3.0-6
ii  libwaffle-1-01.5.2-4
ii  libwayland-client0   1.16.0-1
ii  libwayland-egl1  1.16.0-1
ii  libx11-6 2:1.6.7-1
ii  libxcb-dri2-01.13.1-2
ii  libxcb1  1.13.1-2
ii  libxkbcommon00.8.2-1
ii  ocl-icd-libopencl1 [libopencl1]  2.2.12-2
ii  python3  3.7.3-1
ii  python3-mako 1.0.7+ds1-1
ii  python3-six  1.12.0-1

piglit recommends no packages.

piglit suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFDBAEBCgAtFiEEtjuqOJSXmNjSiX3Tfr04e7CZCBEFAl094XsPHHNqckBkZWJp
YW4ub3JnAAoJEH69OHuwmQgRztwH/ilPtSuR38jTd/69IECI+fmnLK7gNCnA11rh
jAe/no1ANIDH+0jbX+v8eb9cxmzHOVfkkMToxu0Q15w/6y+j8iigS6DC4QAF5VjJ
7PjNOJFNtPyhBCvZgcXJjjw4EZVicKzMmxBfZxndmOq0zRgWA1OTizwmUxS0cwSf
t7JIKg2ZP5qI1Pgzt1hNI8WQAZdztqNvcwIkA515B3kOFofUmt0xGe05AdeRs6JC
JRDSd7gJ3QU3mMr668FEiw2rVe/nyvB6BtTpKJxjOAZJmvgbN1IR/Q5YP+4yRuT8
FFWR5CuC6LrcgE/S6NtbEWYdVDan0GZ1F4l/va4NHVLkWF8PM5s=
=hsb0
-END PGP SIGNATURE-

Bug#931358: release.debian.org: buster-pu (pre-approval): musescore/2.3.2+dfsg2-7~deb10u1

[Thorsten Glaser]

Hi again, sorry for bothering, but…

… in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931040#10
it was indicated this should go into the first point release,
and https://lists.debian.org/debian-devel-announce/2019/07/msg2.html
indicates that that will be done in little more than a weel, so…

>On Wed, 2019-07-03 at 06:43 +0100, Adam D. Barratt wrote:
>
>> and target would indeed be "buster". Please attach a debdiff of the
>> proposed upload to this report (but do not upload it at this stage).
>
>Is it OK to upload now?

TIA,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r

Bug#933274: thunderbird: TB recreates .icedove profile dir if missing, will not start at next launch

[Andrea Borgia]

Package: thunderbird
Version: 1:60.8.0-1
Severity: normal

Dear Maintainer,

This system has gone through the thunderbird->icedove->thunderbird
conversions; launching thunderbird with a real .thunderbird profile
directory and no .icedove, thunderbird will recreate .icedove as a
directory, so that following attempts to run it will fail with a conversion
error.  If I remove the .icedove directory and replace it with a symlink to
.thunderbird, the program will start happily.

Thinking it might have been an incomplete conversion, I quit the program,
removed the .icedove symlink, renamed .thunderbird to .icedove and restarted
the program.  Once the conversion was done, I closed the program and
verified I had my ".icedove" (formerly .thunderbird) directory and a new
.thunderbird symlink.  I deleted this symlink and renamed .icedove to
.thunderbird: no luck, again .icedove as real dir at the first run and an
error at the next.

First I though this was #857029 again but it turned out that, for some
reason, this profile still had a "prefs.js" which referenced ".icedove":
manually editing this file fixed the issue for good.  Shouldn't this file be
migrated too?

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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6.3
ii  fontconfig2.13.1-2
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3
ii  libgcc1   1:9.1.0-10
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-3
ii  libgtk-3-03.24.5-1
ii  libgtk2.0-0   2.24.32-3
ii  libhunspell-1.7-0 1.7.0-2+b1
ii  libicu63  63.2-2
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.21-1
ii  libnss3   2:3.45-1
ii  libpango-1.0-01.42.4-6
ii  libsqlite3-0  3.29.0-1
ii  libstartup-notification0  0.12-6
ii  libstdc++69.1.0-10
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  psmisc23.2-1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1
ii  hunspell-it [hunspell-dictionary] 1:6.3.0~rc1-1
ii  lightning 1:60.8.0-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.3-3
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.17-5

-- no debconf information

Bug#913102: Re[2]: Bug#913102: pulseaudio does not restore correct mic/speaker state

[Алексей Шилин]

This is a pulseaudio bug [1]. It is triggered by recent changes in GDM (which 
began to
terminate itself shortly after a user logs in) and seems to affect all GDM 
users.
 
Given that GDM is part of a default Debian desktop installation, is it possible 
to fix this
issue in the next stable point release?
 
(The patch that I sent previously was cherry-picked from pulseaudio git master.)
 
 [1]  https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/667
--
Алексей Шилин
 

Bug#931548: Migration to Sphinx

[Sean Whitton]

Hello,

On Sat 27 Jul 2019 at 06:31pm +09, Osamu Aoki wrote:

> Yes.  Eventually ;-)
>
> I also see the translation of Policy is building only HTML.

We can add others upon request.

> I think I am going to rewrite build script more symmetrically to make it
> easy to build all formats for all languages.
>
> Just give me some time with developers-reference get this sorted out.

Okay -- Policy's build is already quite complex so please try to keep
the patch as small as possible.

-- 
Sean Whitton

Bug#931974: O: festvox-ru - Russian male speaker for Festival

[Sergey B Kirpichev]

On Sun, Jul 28, 2019 at 05:23:17PM +0200, Samuel Thibault wrote:
> Sergey B Kirpichev, le dim. 28 juil. 2019 17:52:29 +0300, a ecrit:
> > On Sun, Jul 28, 2019 at 04:44:25PM +0200, Samuel Thibault wrote:
> > > We can maintain this along the other voices under the tts-team umbrella.
> > > I have added you to the tts-team group on salsa, I guess this is enough
> > > for you to transfer the salsa project?
> > 
> > What exactly I should do?
> 
> On salsa, on your festvox-ru project page, in the Settings panel, in the
> General subpanel, Expand the Advanced section, and in the Transfert
> Project box, you should be able to choose "Debian TTS Maintainers". If
> it doesn't appear in the list, I'll increase your access to the group.

Thank you, I did.  Hopefully, everything ok.

Bug#932328: logrotate.timer "breaks" activity report of /etc/cron.daily/exim4-base

[Sven Hartge]

On 28.07.19 18:53, Andreas Metzler wrote:

> I /think/ setting Before= in *both* .service and .timer is strange.

I think you just need it in the Service. But I am not sure. The
documentation was a bit sparse on that matter. Other times, just as the
apt ones you mentioned have it in both places.

Please ask the systemd guys for clarification on that matter.

But in the end it shouldn't hurt to have it in both the timer and the
service.

> Is this supposed to work like this?
> 1. When systemd looks at the timers it finds that both logratoe and exim
> have identical time specifications. With the Before= setting it
> triggers logrotate.service after exim.service. Otherwise it might work
> out the other way round, or they are started in parallel.
> 2. When running exim.service systemd again finds a Before= and waits
> with starting log-rotation until after exim's job has finished?

Exactly. At least that is how it works in my systems.

My main system is fast enough so that both exim4-base.service and
logrotate.service get started in the same second, but I see from the
logreport from exim4-base that it uses the whole logfile from the last
day, whereas before my changes I got a report spanning from 00:00 to 00:26.

On another system, which is very slow and has a very very slow storage,
I can see logrotate.service being clearly startet after
exim4-base.service finishes.

Looks like this in the logs:

Jul 28 00:00:22 svenhartge systemd[1]: Starting Daily man-db regeneration...
Jul 28 00:00:22 svenhartge systemd[1]: Starting exim4-base housekeeping...
Jul 28 00:00:38 svenhartge systemd[1]: Started exim4-base housekeeping.
Jul 28 00:00:38 svenhartge systemd[1]: Starting Rotate log files...
Jul 28 00:00:44 svenhartge systemd[1]: man-db.service: Succeeded.
Jul 28 00:00:44 svenhartge systemd[1]: Started Daily man-db regeneration.

logrotate.service waits until exim4-base.service is done, which is
exactly the way you want this to be.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#933273: nullmailer logcheck rules no longer work

[Marc SCHAEFER]

Package: nullmailer
Version: 1:2.2-3

In buster, nullmailer now seems to report as nullmailer-send in syslog:

   Jul 28 08:02:08 falken nullmailer-send[586]: Trigger pulled.
   Jul 28 08:02:08 falken nullmailer-send[586]: Rescanning queue.
   Jul 28 08:02:08 falken nullmailer-send[586]: Starting delivery, 1 message(s) 
in queue.
   Jul 28 08:02:08 falken nullmailer-send[586]: Starting delivery: [ ... ]

thus

   sed --in-place 's/nullmailer/nullmailer-send/' 
/etc/logcheck/ignore.d.server/nullmailer

is required (and maybe everywhere else).

Also some more lines needs filtering (e.g. Message-Id: <.+>) and the order in 
Starting delivery
changed.

Here is the diff that works for me (using ignore.d.server):

--- /tmp/nullmailer.ORIG2019-07-28 19:07:10.497156131 +0200
+++ /etc/logcheck/ignore.d.server/nullmailer2019-07-28 15:06:22.544887446 
+0200
@@ -1,7 +1,8 @@
-nullmailer\[[0-9]+\]: Rescanning queue\.
-nullmailer\[[0-9]+\]: Trigger pulled\.
-nullmailer\[[0-9]+\]: Starting delivery, [0-9]+ message\(s\) in queue\.
-nullmailer\[[0-9]+\]: Starting delivery: protocol: [a-z]+ host: .+ file: 
[0-9\.]+
-nullmailer\[[0-9]+\]: Sent file\.
-nullmailer\[[0-9]+\]: Delivery complete, 0 message\(s\) remain\.
-nullmailer\[[0-9]+\]: smtp: Succeeded:
+nullmailer-send\[[0-9]+\]: Rescanning queue\.
+nullmailer-send\[[0-9]+\]: Trigger pulled\.
+nullmailer-send\[[0-9]+\]: Starting delivery, [0-9]+ message\(s\) in queue\.
+nullmailer-send\[[0-9]+\]: Starting delivery: host: .+ protocol: [a-z]+ file: 
[0-9\.]+
+nullmailer-send\[[0-9]+\]: Sent file\.
+nullmailer-send\[[0-9]+\]: Delivery complete, 0 message\(s\) remain\.
+nullmailer-send\[[0-9]+\]: smtp: Succeeded:
+nullmailer-send\[[0-9]+\]: Message-Id: <.+>

Bug#581960: tex4ht: wrong charset in htlatex output

[Hilmar Preuße]

Control: forwarded 581960 https://puszcza.gnu.org.ua/bugs/index.php?432

Am 17.05.2010 um 13:54 teilte jsb...@mimuw.edu.pl mit:

> Please have a look at the attached example.
> 
> This is a regression, it work correctly several years ago...
> 
Forwarded to upstream.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#933252: apt-listbugs should use https by default, patches included

[Francesco Poli]

On Sun, 28 Jul 2019 12:23:22 + hty81z+5ruj6wk24x...@guerrillamail.com wrote:

> https://lists.debian.org/debian-legal/2004/05/msg00595.html

A URL without any comment is a bit laconic.

What do you mean?
That I should add an OpenSSL linking exception to the GPLv2-or-later
license of apt-listbugs?

It's not that simple: please read the [bug log] I have already cited.
Especially [message #45], which states, in part:

[...]
| apt-listbugs is GPL-licensed and loads a number of
| GPL-licensed Ruby libraries
[...]

[bug log]: 
[message #45]: 

I cannot grant a linking exception on behalf of other copyright
holders, and I am not the sole copyright holder for apt-listbugs, nor
do I hold any copyright in the other GPL-licensed libraries loaded by
apt-listbugs.
I should ask all those other people for that linking exception,
something which I am not going to pursue.
Moreover, I do not want to grant that linking exception myself.


On the other hand, if you meant something else, sorry for
misunderstanding you, but please try and be more explicit.

Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpIT__QmKzVc.pgp
Description: PGP signature

Bug#932328: logrotate.timer "breaks" activity report of /etc/cron.daily/exim4-base

[Andreas Metzler]

On 2019-07-18 Sven Hartge  wrote:
> On 17.07.19 20:46, Sven Hartge wrote:

>> Possible solution (untested): Also create a exim4-base.timer and
>> .service and create a Before= dependency on logrotate.service.

> I've whipped up a little Proof-of-Concept to test this, available also
> at https://salsa.debian.org/hartge-guest/exim4/tree/systemd-timer

> I'm testing this right now on two of my systems to see how this behaves,
> especially the Before=logrotate.{service,timer} ordering.

Hello Sven,

I /think/ setting Before= in *both* .service and .timer is strange.

Is this supposed to work like this?
1. When systemd looks at the timers it finds that both logratoe and exim
have identical time specifications. With the Before= setting it
triggers logrotate.service after exim.service. Otherwise it might work
out the other way round, or they are started in parallel.
2. When running exim.service systemd again finds a Before= and waits
with starting log-rotation until after exim's job has finished?

Thanks for the hand holding.

(FWIW on my system I have only a single timer/service pair that uses
Before/After - apt-daily-upgrade/apt-daily and they do it exactly the
way you suggested.)

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#933272: python-mode: Emacs initialisation reports python-mode problem after fresh install

[Andreas Ames]

Package: python-mode
Version: 1:6.2.3-1.1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

I am starting emacs daemon from a terminal.  After a full-upgrade to buster the 
output
from "emacs --daemon" started showing problems with initialising python-mode and
haskell-mode.  So, I purged all (?) emacs-related packages including the elpa-* 
ones,
especially pythn-mode and haskell-mode.  Now, the initialisation with 
haskell-mode (or
rather elpa-haskell-mode) seem to be gone, but "emacs --daemon" still shows the 
following
issue with python-mode:

Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/00debian.el (source)...done
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...done
Loading /etc/emacs/site-start.d/50cmake-data.el (source)...
Loading /etc/emacs/site-start.d/50cmake-data.el (source)...done
Loading /etc/emacs/site-start.d/50coq.el (source)...
Loading /etc/emacs/site-start.d/50coq.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
Loading debian-ispell...
Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)...
Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)...done
Loading debian-ispell...done
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done
Loading /etc/emacs/site-start.d/50global.el (source)...
Loading /etc/emacs/site-start.d/50global.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)...
Loading /usr/share/emacs/site-lisp/latex-cjk-common/cjk-enc.el (source)...
Loading /usr/share/emacs/site-lisp/latex-cjk-common/cjk-enc.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-thai.el (source)...
Loading /etc/emacs/site-start.d/50latex-cjk-thai.el (source)...done
Loading /etc/emacs/site-start.d/50ocaml-mode.el (source)...
Loading /etc/emacs/site-start.d/50ocaml-mode.el (source)...done
Loading /etc/emacs/site-start.d/50proofgeneral.el (source)...
Loading /etc/emacs/site-start.d/50proofgeneral.el (source)...done
Loading /etc/emacs/site-start.d/50pylint.el (source)...
Loading /etc/emacs/site-start.d/50pylint.el (source)...done
Loading /etc/emacs/site-start.d/50pymacs.el (source)...
Loading /etc/emacs/site-start.d/50pymacs.el (source)...done
Loading /etc/emacs/site-start.d/50python-docutils.el (source)...
Loading /etc/emacs/site-start.d/50python-docutils.el (source)...done
Loading /etc/emacs/site-start.d/50python-mode.el (source)...
Package python-mode not fully installed.  Skipping setup.
Loading /etc/emacs/site-start.d/50python-mode.el (source)...done
Loading /etc/emacs/site-start.d/50tcsh.el (source)...
Loading /etc/emacs/site-start.d/50tcsh.el (source)...done
Loading /etc/emacs/site-start.d/50texlive-lang-english.el (source)...
Loading /etc/emacs/site-start.d/50texlive-lang-english.el (source)...done
Loading /etc/emacs/site-start.d/50why3.el (source)...
Loading /etc/emacs/site-start.d/50why3.el (source)...done
Loading delsel...
Loading delsel...done
Loading paren...
Loading paren...done
Loading /home/aa/.emacs.d/emacs-lisp/cc-mode-config.el (source)...
Loading /home/aa/.emacs.d/emacs-lisp/ppindent.el (source)...
Loading /home/aa/.emacs.d/emacs-lisp/ppindent.el (source)...done
Loading /home/aa/.emacs.d/emacs-lisp/cc-mode-config.el (source)...done
Starting Emacs daemon.

Issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905305 seems to be
related, but it is closed.

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

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

Versions of packages python-mode depends on:
ii  emacsen-common  3.0.4
ii  python  2.7.16-1

Versions of packages python-mode recommends:
ii  pychecker  0.8.19-17
ii  pymacs 0.25-2

Versions of packages python-mode suggests:
ii  pylint   1.9.4-1
ii  python-ropemacs  0.8-1

-- no debconf information

Thanks in advance,

Andreas

Bug#893574: Auto-suspend

[Andrey Skvortsov]

My use-case is slightly different, but very annoying.

1) user1 logged in GNOME session for a while. 
2) user2 wants to use its account.
3) user1 locks its session.
4) user2 selects 'switch user' and then ...
system is surprisingly suspended after switching to greeter. User2 has
to wakeup system to login.


I've made suggested changes to /etc/gdm3/greeter.dconf-defaults as a
workaround for this behavior:

[org/gnome/settings-daemon/plugins/power]
sleep-inactive-ac-timeout=0
sleep-inactive-battery-timeout=0

I understand that most likely defaults will not be changed, because
they were modify to comply with European and American power-saving
regulations.
Changes in /etc/gdm3/greeter.dconf-defaults have solved my problem,
but other users probably have the same problem.

The problem seems that activity in other seats doesn't reset
inactivity timer in greeter session. As soon as greeter session is
active again (switch user/logout) inactivity timer triggers automatic
system suspend. It would be nice if inactivity timer would be reset on
session switching.

-- 
Best regards,
Andrey Skvortsov


signature.asc
Description: PGP signature

Bug#554637: tex4ht: Leaves intermediate files

[Hilmar Preuße]

Control: tags 554637 + wontfix
Control: notforwarded 554637

Am 05.11.2009 um 21:40 teilte Andrey mit:

Hi,

I've got a reply that some intermediate files are really needed for
reprocessing input files. Therefore they refuse to change the code. If
you really need to delete them, please use a wrapper around the tex4ht
processor.

Tag as "will not fix".

Hilmar

> I've noticed that running
> 
> htlatex test.tex "xhtml,ooffice,enumerate+" "ooffice/! -cunihtf -utf8" "-coo"
> 
> pollutes current directory with the following intermediate files:
> 
> test.4ct
> test.4tc
> test.dvi
> test.idv
> test.tmp
> test.xref
> 
> As htlatex is actually trying to do some cleanup, I think these should
> be removed as well. I only expect the following files to stay:
> 
> test.lg
> test.odt
> 


-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#615596: tex4ht: mk4ht dblatex file.tex fails with xtpipes error

[Hilmar Preuße]

Control: tags 615596 + patch fixed-upstream pending notforwarded

Am 27.02.2011 um 18:05 teilte Martin Dietze mit:

Hi,

> Calling mk4ht dblatex some_file.tex results in this error:
> 
> System call: java -classpath /usr/share/tex4ht/tex4ht.jar xtpipes -i
> /usr/share/texmf/tex4ht/xtpipes/ -o some_file.xml some_file.tmp
> --- xtpipes error 32 --- Missing 4xt script file name
> --- Warning --- System return: 256
> 
> This makes it impossible to create docbook files from a LaTeX
> source.
> 
The patch from upstream solved the issue for me, tagging as patch available.

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#933247: e2fsprogs FTCBFS: DEB_BUILD_OPTIONS=nocheck no longer works

[Helmut Grohne]

Hi Ted,

On Sun, Jul 28, 2019 at 10:04:48AM -0400, Theodore Y. Ts'o wrote:
> Yes, I had noticed that this was breaking some of the ports build as
> well, and so I have a similar patch in my tree already.  I was going
> to wait a few days to see if there were any other issues, and to allow
> 1.45.3-3 to enter testing before I was going to do another upload.  Is
> it urgent for you such that you would prefer an upload sooner?

If you defer it, I'll have to add the patch to rebootstrap.git and later
revert it. That's unfortunate, but certainly possible. I'll need some
fix (either in e2fsprogs or rebootstrap), because otherwise I'm blind to
later failures. Knowing your plans is key here. I'll assume that you
defer it unless you mail back with 12h.

>  override_dh_auto_test:
> +ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
>   $(MAKE) -C ${stdbuilddir} V=1 check
> +endif
>  
>  test_printenv:
>   printenv | sort

It just occured to me that there might be a simpler implementation
(untested):

override_dh_auto_test:
dh_auto_test -- V=1

Helmut

Bug#637127: biblatex: Version 1.6-1 breaks "refsection=part" functionality

[Hilmar Preuße]

Am 08.08.2011 um 18:53 teilte Gunnar Wolf mit:

Hi Gunnar,

> Upon installing biblatex 1.6-1, my book (which includes a references
> section per part) no longer generates the partial *.blx.aux files when
> being built. My preamble includes:
> 
> \usepackage[style=authoryear, backref=true, backrefstyle=two,
> refsection=part, block=ragged]{biblatex}
> \ExecuteBibliographyOptions{ autocite=inline, sortcites=true,
> labelyear=true, uniquename=true}
> \bibliography{seco3}
> 
> So, from the seco3.bib file, four files (one per part --
> seco31.blx.aux, seco32.blx.aux, seco33.blx.aux, seco34.blx.aux) should
> be generated, and bibtex is run for each. Of course, if I run bibtex
> on the core seco3.aux file, the complete reference section is repeated
> at the end of each part.
> 
> Downgrading to 1.4c-1 fixes the problem.
> 
Quite old bug, I know. We didn't work on the issue for a while and then
it was closed b/c the package was removed from the archive. The code
however is still in the archive and could be buggy.

1. Are you still able to reproduce the issue?
2. If yes, do you have still some sample code? The git repository
   mentioned does not exist any more.

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#933271: libreoffice: Should recommend libreoffice-gnome

[Rene Engelhard]

Hi,

On Sun, Jul 28, 2019 at 05:34:41PM +0200, Rene Engelhard wrote:
> > Could you make libreoffice (or another package like task-desktop) recommends
> > libreoffice-gnome?
> 
> As shown above, task-desktop recommends task-gnome-desktop which already
> does what you want.

And just for the record:

$ apt-cache show libreoffice
Package: libreoffice
Version: 1:6.1.5-3+deb10u2
Installed-Size: 92
Maintainer: Debian LibreOffice Maintainers

Architecture: amd64
Depends: libreoffice-base, libreoffice-calc, libreoffice-core (=
1:6.1.5-3+deb10u2), libreoffice-draw, libreoffice-impress,
libreoffice-math, libreoffice-report-builder-bin, libreoffice-writer,
libreoffice-avmedia-backend-gstreamer | libreoffice-avmedia-backend-vlc,
python3-uno (>= 4.4.0~beta2)
Suggests: cups-bsd, firefox-esr | thunderbird | firefox, ghostscript,
gnupg, gpa, hunspell-dictionary, hyphen-hyphenation-patterns,
imagemagick | graphicsmagick-imagemagick-compat, libgl1,
libreoffice-gnome | libreoffice-kde5, [...]

So apt install libreoffice would have shown that. But yes, tasksel
wouldn't have shown it.

Regards,
 
Rene

Bug#933271: libreoffice: Should recommend libreoffice-gnome

[Rene Engelhard]

severity 933271 wishlist
thanks

Hi,

On Sun, Jul 28, 2019 at 05:16:31PM +0200, Yvan Masson wrote:
> LibreOffice is not able to read/write to GVFS mounts (GIO) if
> libreoffice-gnome is not installed. If I am not wrong, libreoffice-gnome is
> installed automatically only in the following cases when installing a Debian
> computer:
> - when choosing task-gnome-desktop (which recommends libreoffice-gnome)
> - when choosing task-gnome-cinammon (which depends on
> cinnamon-desktop-environment, which recommends libreoffice-gnome)
> 
> This means that when installing Debian with a desktop environment,
> LibreOffice is not able to read/write files on GVFS mounts on:

Wrong. GNOME is a desktop environment. In fact, it is the default
desktop environment.

$ apt-cache show task-desktop
Package: task-desktop
Source: tasksel
Version: 3.53
Installed-Size: 6
Maintainer: Debian Install System Team 
Architecture: all
Depends: tasksel (= 3.53), xorg, xserver-xorg-video-all,
xserver-xorg-input-all, desktop-base
Recommends: task-gnome-desktop | [...]
[...]

> - KDE (I think it uses KIO instead of GIO, so it might work in another way)

So why would installing -gnome help here?

> Could you make libreoffice (or another package like task-desktop) recommends
> libreoffice-gnome?

As shown above, task-desktop recommends task-gnome-desktop which already
does what you want.

Regards,

Rene

Bug#933267: linux-image-amd64: CONFIG_TRACE_IRQFLAGS missing from config kernel file.

[Corcodel Marian]

I want to see CONFIG_TRACE_IRQFLAGS on config file like 
CONFIG_TRACE_IRQFLAGS is not set but not see that please send this 
request on linux developers.


On 7/28/19 3:04 PM, Ben Hutchings wrote:

Control: reassign -1 src:linux 4.9.168-1+deb9u4
Control: severity -1 wishlist
Control: tag -1 wontfix

On Sun, 2019-07-28 at 14:05 +0200, Corcodel Marian wrote:

Package: linux-image-amd64
Version: 4.9+80+deb9u7
Severity: normal

May bee on irqflags.h header file try to replace
CONFIG_TRACE_IRQFLAGS with
CONFIG_TRACE_IRQFLAGS_SUPPORT on order to enable trace.

This option is not enabled directly, but through CONFIG_PROVE_LOCKING
or CONFIG_IRQSOFF_TRACER.  We don't enable those as they have make the
kernel larger and have a significant performance cost.

Ben.

Bug#931974: O: festvox-ru - Russian male speaker for Festival

[Samuel Thibault]

Sergey B Kirpichev, le dim. 28 juil. 2019 17:52:29 +0300, a ecrit:
> On Sun, Jul 28, 2019 at 04:44:25PM +0200, Samuel Thibault wrote:
> > We can maintain this along the other voices under the tts-team umbrella.
> > I have added you to the tts-team group on salsa, I guess this is enough
> > for you to transfer the salsa project?
> 
> What exactly I should do?

On salsa, on your festvox-ru project page, in the Settings panel, in the
General subpanel, Expand the Advanced section, and in the Transfert
Project box, you should be able to choose "Debian TTS Maintainers". If
it doesn't appear in the list, I'll increase your access to the group.

Samuel

Bug#933271: libreoffice: Should recommend libreoffice-gnome

[Yvan Masson]

Source: libreoffice
Severity: normal

Dear Maintainers,

LibreOffice is not able to read/write to GVFS mounts (GIO) if 
libreoffice-gnome is not installed. If I am not wrong, libreoffice-gnome 
is installed automatically only in the following cases when installing a 
Debian computer:

- when choosing task-gnome-desktop (which recommends libreoffice-gnome)
- when choosing task-gnome-cinammon (which depends on 
cinnamon-desktop-environment, which recommends libreoffice-gnome)


This means that when installing Debian with a desktop environment, 
LibreOffice is not able to read/write files on GVFS mounts on:

- KDE (I think it uses KIO instead of GIO, so it might work in another way)
- Mate
- XFCE
- LXDE
- LXQT

I believe that installing a Debian desktop with "recommended" 
dependencies enabled should automatically install libreoffice-gnome so 
that this functionality is not broken. Especially because when 
LibreOffice fails it is very difficult to understand where it comes from 
(it could be an issue with the SMB share or with GVFS).


Could you make libreoffice (or another package like task-desktop) 
recommends libreoffice-gnome?


Thanks for your time and work,
Yvan

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#799090: Still present in buster version (3.30.1.1-1)

[Ivan Kohler]

On Sat, Jul 27, 2019 at 05:10:31PM +0200, Jörg Frings-Fürst wrote:
> tags 799090 - upstream
> thanks
> 
> 
> Hello,
> 
> in my mail from 14-07-2019 I asked to open a new bug report if the bug
> still exists.

That makes no sense and is not now the bug tracker is used.  The bug is 
still present, I am re-opening the original bug to save all history, not 
bloat the bug tracker with new copies of the same bugs every few years.

If there is some additional information you require other than the 
verification the bug is still present on buster, please feel free ask 
for it.  It seems bog-simple straightforward to reproduce to me, but 
perhaps my multiple different systems over the years have some 
configuration that is unusual.

Again, my thanks for packaging up a great scanning program that runs 
under multiple desktop environments, and my thanks to upstream for the 
application.

-- 
_ivan

Bug#923369: asymptote: split noX package

[Norbert Preining]

On Sun, 28 Jul 2019, Hilmar Preuße wrote:
> Yes, please. I'm not permitted to do it.

I pushed two more commits and are building it now.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#923369: asymptote: split noX package

[Hilmar Preuße]

Am 28.07.2019 um 16:54 teilte Norbert Preining mit:
> On Sun, 28 Jul 2019, Hilmar Preuße wrote:

Hi,

>> Go ahead!!!
> 
> Do you mean I should upload it, right?
> 
Yes, please. I'm not permitted to do it.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#932684: buster-pu: package gnupg2/2.2.12-1+deb10u1

[Daniel Kahn Gillmor]

On Sun 2019-07-21 15:55:28 -0400, Daniel Kahn Gillmor wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> Control: affects -1 src:gnupg2
>
> The version of GnuPG in debian buster (2.2.12-1) has a number of
> outstanding bugs related to OpenPGP certificate management and network
> access.  Many of these concerns are addressed in some of the patches
> in upstream's STABLE-BRANCH-2-2 series.
>
> The debdiff (attached) is basically a slew of bugfix, documentation,
> stability, and efficiency patches cherry-picked from upstream, plus
> some additional changes to reduce the exposure of debian users to
> malicious attack on the SKS keyserver network, and some improvements
> in the continuous integration test suite.

ping on this?  i'd appreciate any feedback about its prospects for
fixing problems for users of debian buster.

   --dkg


signature.asc
Description: PGP signature

Bug#931974: O: festvox-ru - Russian male speaker for Festival

[Sergey B Kirpichev]

On Sun, Jul 28, 2019 at 04:44:25PM +0200, Samuel Thibault wrote:
> We can maintain this along the other voices under the tts-team umbrella.
> I have added you to the tts-team group on salsa, I guess this is enough
> for you to transfer the salsa project?

What exactly I should do?

Bug#923369: asymptote: split noX package

[Norbert Preining]

On Sun, 28 Jul 2019, Hilmar Preuße wrote:
> Go ahead!!!

Do you mean I should upload it, right?

> BTW: do we still need the experimental branch on github?

I keep it normally, then merge master in case I do exp versions prior to
release. But it can be recreated, so no strong opinion.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#931087: fdisk/sfdisk: creates scripts that don't work

[Matthias Urlichs]

https://github.com/karelzak/util-linux/issues/830


-- 
-- Matthias Urlichs

Bug#931974: O: festvox-ru - Russian male speaker for Festival

[Samuel Thibault]

Hello,

Sergey B Kirpichev, le sam. 13 juil. 2019 09:13:11 +0300, a ecrit:
> I am winding down my involvement in Debian to a minimum and I have
> no intentions to support this package anymore.
> 
> Maintaining a package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.

We can maintain this along the other voices under the tts-team umbrella.
I have added you to the tts-team group on salsa, I guess this is enough
for you to transfer the salsa project?

Samuel

Bug#933267: linux-image-amd64: CONFIG_TRACE_IRQFLAGS missing from config kernel file.

[Corcodel Marian]

This aniway is a bug because CONFIG_TRACE_IRQFLAGS in not found in 
config file.


On 7/28/19 3:04 PM, Ben Hutchings wrote:

Control: reassign -1 src:linux 4.9.168-1+deb9u4
Control: severity -1 wishlist
Control: tag -1 wontfix

On Sun, 2019-07-28 at 14:05 +0200, Corcodel Marian wrote:

Package: linux-image-amd64
Version: 4.9+80+deb9u7
Severity: normal

May bee on irqflags.h header file try to replace
CONFIG_TRACE_IRQFLAGS with
CONFIG_TRACE_IRQFLAGS_SUPPORT on order to enable trace.

This option is not enabled directly, but through CONFIG_PROVE_LOCKING
or CONFIG_IRQSOFF_TRACER.  We don't enable those as they have make the
kernel larger and have a significant performance cost.

Ben.

Bug#923369: asymptote: split noX package

[Hilmar Preuße]

Am 28.07.2019 um 15:12 teilte Norbert Preining mit:

Hi,

> @Hilmar, if you don't have anything else, you can upload this package.
> 
> Again, probably we need a binary upload due to NEW queue processing.
> 
Hmm, forgot about that (as you noticed already). Hope that I get a
reject E-mail shortly and ...


ACL dm: NEW uploads are not allowed

binary:asymptote-x11 is NEW.


Go ahead!!!

Hilmar

BTW: do we still need the experimental branch on github?
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#931386: stretch-pu: package fribidi/0.19.7-1.1

[Samuel Thibault]

Jonathan Wiltshire, le sam. 27 juil. 2019 20:36:00 -0300, a ecrit:
> On Wed, Jul 03, 2019 at 07:36:55PM +0200, Samuel Thibault wrote:
> > As reported on #917909, the text-based debian installer support for
> > right-to-left languages is completely broken, only due to a path
> > mismatch. This was fixed in Buster in January with the attached change,
> > which I have uploaded to stretch as 0.19.7-1.1, could you accept it?
> 
> That's an unusual version; did you mean to +deb9u1 it instead?

Oops, sorry about this.  I have reuploaded it as 0.19.7-1+deb9u1 with
the attached changes.

Samuel
diff -Nru fribidi-0.19.7/debian/changelog fribidi-0.19.7/debian/changelog
--- fribidi-0.19.7/debian/changelog 2015-08-12 07:32:03.0 +0200
+++ fribidi-0.19.7/debian/changelog 2019-06-08 22:39:38.0 +0200
@@ -1,3 +1,12 @@
+fribidi (0.19.7-1+deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * libfribidi0-udeb: Fix right-to-left output in textual version of
+d-i by installing the shared library files into a multi-arch libdir
+(Closes: #917909).
+
+ -- Samuel Thibault   Sat, 08 Jun 2019 22:39:38 +0200
+
 fribidi (0.19.7-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru fribidi-0.19.7/debian/libfribidi0-udeb.install 
fribidi-0.19.7/debian/libfribidi0-udeb.install
--- fribidi-0.19.7/debian/libfribidi0-udeb.install  2015-08-12 
07:32:03.0 +0200
+++ fribidi-0.19.7/debian/libfribidi0-udeb.install  2019-06-08 
22:39:38.0 +0200
@@ -1 +1 @@
-usr/lib/*/libfribidi.so.* lib
+usr/lib/*/libfribidi.so.*

Bug#933270: RFS: erlang-metrics/2.5.0-1 [ITP] -- generic interface to different metrics systems in Erlang

[James Valleroy]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "erlang-metrics"

 * Package name: erlang-metrics
   Version : 2.5.0-1
   Upstream Author : Benoît Chesneau 
 * URL : https://github.com/benoitc/erlang-metrics
 * License : BSD-3-clause
   Section : devel

It builds those binary packages:

  erlang-metrics - generic interface to different metrics systems in Erlang

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

https://mentors.debian.net/package/erlang-metrics

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

  dget -x
https://mentors.debian.net/debian/pool/main/e/erlang-metrics/erlang-metrics_2.5.0-1.dsc

Regards,
James Valleroy



signature.asc
Description: OpenPGP digital signature

Bug#933151: mariadb-10.3: FTBFS on riscv64

[Héctor Orón Martínez]

Hello,

Missatge de Hector Oron  del dia dg., 28 de jul.
2019 a les 1:45:
> The code including atomic must link using `-latomic`, that is
> apparently GCC bug, which it is not often seen in other architectures.
> I have been unable to test the assumption.

>From irc://OFTC/debian-riscv channel someone suggests to link -pthread.

Regards
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#932795: Ethics of FTBFS bug reporting

[Ian Jackson]

Simon McVittie writes ("Bug#932795: Ethics of FTBFS bug reporting"):
> For the specific question of whether a single CPU core is a "reasonable"
> build environment, my answer at the moment is "I don't know".

There are two issues here:

1. "Is a 1-cpu system `reasonable' or `supported'" (or whatever)

2. We don't have anywhere to write down the answer to these kind of
questions.  (That there was nowhere to write down the answer, in
particular, nowhere in policy, is I think a large underlying cause of
why Santiago is frustrated.  Because it means that the answer isn't
written down despite it being quite relevant.)

I think most people here would be happy to have (1) decided (one way
or the other) by the release team.  Solving (2) seems like a job for
the -policy list, since it's mostly wordsmithing.

The detailed questions you ask downthread seem like good questions to
be asking to help aswer (1) but maybe now would be a good time to
bring in -release ?

Ian.