date:20180307

Package: fp-utils-3.0.4
Version: 3.0.4+dfsg-15
Severity: normal
File: /usr/bin/fpcmake

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

fpcmake doesn't work out of the box in Debian (maybe since the multiarch
changes, but I am not sure about that). E.g. in the Lazarus source tree I get 
this:
paul@testavoira ~/lazarus $ fpcmake -r -v
FPCMake Version 2.0.0 [2017-02-13 rev 35434]
Processing Makefile.fpc
 Targets: "x86_64-linux"
 Globals:
FPCDIR = ""
PACKAGESDIR = "$(FPCDIR)/packages $(FPCDIR)/packages/base 
$(FPCDIR)/packages/extra $(FPCDIR)/packages"
UNITSDIR = "$(FPCDIR)/units/$(FULLTARGET)"
BASEDIR = "/home/paul/packages/freepascal/lazarus"
 Required packages for linux-x86_64: rtl regexpr
 Package "rtl": Looking for Makefile.fpc: " /packages/rtl/Makefile.fpc 
/packages/base/rtl/Makefile.fpc /packages/extra/rtl/Makefile.fpc 
/packages/rtl/Makefile.fpc "
 Package "rtl": Looking for Package.fpc: " /units/x86_64-linux/rtl/Package.fpc "
Error: Target "linux", package "rtl" not found

Lazarus is defining FPCDIR in its d/rules file to prevent this like:
FPCDIR=/usr/share/fpcsrc/${FPCVER}

Transgui is/was doing it like:
FPCDIR=/usr/lib/fpc/${FPCDIR}

I believe neither should be needed. Also, which one of the two is correct (or
better, if neither is really correct)?

Paul

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

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

Versions of packages fp-utils-3.0.4 depends on:
ii  fpc-source-3.0.4  3.0.4+dfsg-15
ii  libc6 2.26-6

Versions of packages fp-utils-3.0.4 recommends:
ii  fp-compiler-3.0.4  3.0.4+dfsg-15

fp-utils-3.0.4 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlqgS6YACgkQnFyZ6wW9
dQpVjAf/WKH9mpTybtk9CC29DdxupoZ0yvpsA3fnGcbPC9cNLUGm5CqG7EtC2jY1
25mKsm+QzZXMu/gbexZfnqFK4mhEGCWfoXSK47QUsEspu+c3cuao97ySE75iIXJY
OSHtNUB9uHeN0jjbVXAE7fI2IEiTKYBwlSxXvhTC65tYikjcdqgdbFNa1jsYdjA3
Z/tNM2iI7SsSmubLvQiCQq/ZP3fYkAA9vydE+dw1/uIUh3/z7gIzVlpT2nd2uXpb
iidAMmLsMQ0gyZ079u8Yt+X2eNrAb3sre3mGjyRfjYkprqoWrbICHJZ8eN5Tc001
SjAE1D68CBzuvFAtyErMudwg06AWGg==
=4I4S
-END PGP SIGNATURE-

Bug#861649: Newer version uploaded

Control: tags -1 moreinfo

On Tue, 06 Mar 2018 16:24:53 +0100 Gard Spreemann  
> Upstream provided a patch that fixes this. I've updated
> 
>  https://mentors.debian.net/debian/pool/main/g/gudhi/gudhi_2.1.0+dfsg
-1.dsc

Thanks!

But the lintian stuff I complained about is not completly fixed, there
is even a new tag: 
I: gudhi source: quilt-patch-missing-description no-external-doc-
resources.patch

Please run lintian after every build! Best, include it into pbuilder or
like! Remember "some sponsors are evil and pedantic [1] when running
lintian. 

[1]  https://nthykier.wordpress.com/2012/02/23/some-sponsors-are-evil-a
nd-pedantic/

Those linitian messages should be fixed before an upload:
(As at least partially already asked for in earlier reviews)

N: Starting on group gudhi/2.1.0+dfsg-1
N: Unpacking packages in group gudhi/2.1.0+dfsg-1
N: 
N: Processing changes file gudhi (version 2.1.0+dfsg-1, arch source
amd64 all) ...
N: 
N: Processing source package gudhi (version 2.1.0+dfsg-1, arch source)
...
I: gudhi source: binary-control-field-duplicates-source field "section"
in package gudhui
P: gudhi source: file-contains-trailing-whitespace debian/control (line
110)
P: gudhi source: package-uses-old-debhelper-compat-version 10
I: gudhi source: quilt-patch-missing-description no-external-doc-
resources.patch
W: gudhi source: unnecessary-testsuite-autopkgtest-field
N: 
N: Processing binary package python3-gudhi (version 2.1.0+dfsg-1, arch
amd64) ...
I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist-
packages/gudhi.cpython-36m-x86_64-linux-gnu.so ment meant
I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist-
packages/gudhi.cpython-36m-x86_64-linux-gnu.so preambule preamble
I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist-
packages/gudhi.cpython-36m-x86_64-linux-gnu.so choosen chosen
N: 
N: Processing binary package libgudhi-examples (version 2.1.0+dfsg-1,
arch all) ...
W: libgudhi-examples: lib-recommends-documentation recommends:
libgudhi-doc
N: 
N: Processing binary package libgudhi-doc (version 2.1.0+dfsg-1, arch
all) ...
I: libgudhi-doc: possible-documentation-but-no-doc-base-registration
N: 
N: Processing binary package libgudhi-dev (version 2.1.0+dfsg-1, arch
all) ...
N: 
N: Processing binary package python3-gudhi-dbgsym (version 2.1.0+dfsg-
1, arch amd64) ...
N: 
N: Processing binary package gudhui (version 2.1.0+dfsg-1, arch amd64)
...
I: gudhui: spelling-error-in-binary usr/bin/gudhui preambule preamble
P: gudhui: no-upstream-changelog
W: gudhui: binary-without-manpage usr/bin/gudhui

 
Please review d/copyright. I found at least one undocumented file which
is licensed Apache 2.0 and another one under LGPL3+. Neither are in 
d/copyright.

Again, remove moreinfo when ready.

--

tobi

Bug#887967: [Pkg-pascal-devel] Bug#887967 closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)

Hi  all,

On 07-03-18 18:28, Michalis Kamburelis wrote:
> "2018-03-07 16:46 GMT+01:00 Graham Inggs :
>> On Tue, 23 Jan 2018 08:46:09 +0200 Adrian Bunk  wrote:
>>>
>>> This problem is unfortunately still present with fpc 3.0.4+dfsg-14:
>>>
>>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/transgui.html

Yes, but not for i386 and armhf. Weird.

>> This can be worked around by the following change in debian/rules:
>>
>> -export FPCDIR=/usr/lib/fpc/${FPCDIR}
>> +export FPCDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/fpc/default

@Graham, have you verified this?

> It seems that transgui is using an older "fpcmake" system (depending
> on Makefile which is auto-generated based on "Makefile.fpc" contents).
> The auto-detection is in a different place then, although it is also
> overridden by $FPCDIR environment variable.

transgui is calling fpcmake in d/rules, so it is regenerating all the
Makefiles (which is good). The failure happens DURING the call to fpcmake.

On arm64 the situation if fully different. Clean doesn't work (which
could be easily worked around in multiple ways). I.e. this should not be
blocking for building on arm64.

Paul

signature.asc
Description: OpenPGP digital signature

Bug#694068: netcfg: Wireless connectivity present during an install but absent afterwards

2018-03-07 Thread Brian Potkin

On Tue 06 Mar 2018 at 11:07:59 +1100, Trent W. Buck wrote:

> Brian Potkin wrote:
> > The number of users affected by this issue over the years is not
> > insignificant. Not a single one has written in support of the
> > situation.
> 
> This issue has bitten me at least twice so far.
> 
> This issue's history seems to be bogged down on whether interfaces(5)
> can be mode 0600 (to hide the cleartext passphrase).
> This is not necessary; the passphrase can go in a separate file.

Mode 0600 wasn't intially given as a reason:

https://lists.debian.org/debian-boot/2012/09/msg00282.html

 > I realise a default is only a default and the selection can be changed,
 > but I'm puzzled by the third option. Why treat a wireless install
 > differently from a wired install? It would expected that a user who has
 > chosen not to use a wired connection would still want connectivity after
 > booting into into the new system,

   The main reason for this is that as far as I know writing configs
   related to a wireless network to /e/n/i enforce using only that
   particular network later (of course if you don't modify the file) and
   also that the interface is unmanageable for other tools. The idea was
   to leave the network unconfigured, so that it can be managed later
   (perhaps via something else than NM).

Later in the thread:

https://lists.debian.org/debian-boot/2012/09/msg00313.html

 > On the other hand, we have users who chose not to install a desktop
 > environment but want their machine to migrate between networks when it's
 > moved. These users are going to need to do some form of sysadmin work
 > post-install, whether it's installing a desktop environment and wicd, or
 > editing /etc/network/interfaces on each fresh network, or bringing up
 > wifi connections by hand. So I can't see locking a default into
 > /etc/network/interfaces causing them much bother.

   IIRC we decided on this default before we added the code to change the
   access mode of /e/n/i if it contains a password. The main reason for
   defaulting to no configuration in this case was to avoid having
   passwords in there. If people think it should default to ifupdown in
   this case this can be changed.

The default (loopback only for wireless) was added without considering
mode 0600. At this stage in the history there appears to be a willingness
to use ifupdown and not loopback.

> Here is a minimal config, assuming WPA2 PSK (not Enterprise) and DHCP (not 
> static) for all SSIDs:
> 
> cat >/etc/network/interfaces < allow-auto lo $iface
> iface lo inet loopback
> iface default inet dhcp
> iface $iface inet manual
>   wpa-roam /etc/wpa_supplicant/wpa_supplicant-$iface.conf
> EOF
> 
> wpa_passphrase "$ssid" "$passphrase" 
> >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf"
> chmod 0600 "/etc/wpa_supplicant/wpa_supplicant-$iface.conf"
> 
> If you don't want to udebify wpa_passphrase, you can do it by hand:
> 
> cat >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf" < network={
>   ssid="$ssid"
>   psk="$passphrase"
> }
> EOF
> 
> If you really hate ifupdown, you can use systemd instead (not fully tested):
> 
> cat >/etc/systemd/network/$iface.network < [Match]
> iface=$iface
> [Network]
> DHCP=yes
> EOF
> 
> systemctl enable wpa_supplicant@$iface.service
> 
> wpa_passphrase "$ssid" "$passphrase" 
> >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf"
> chmod 0600 "/etc/wpa_supplicant/wpa_supplicant-$iface.conf"
> 
> If even these things are too much, can you AT LEAST install
> wpasupplicant?  Writing config files is much easier than ferrying
> .debs between computers by USB key.
> 
> If this bug is going to be kept ANOTHER Debian release, can you at
> least warn people about it in the buster Installation Guide?

Or dispense with loopback for an installation over wireless (an easy
enough change) and warn about 0600 in the Release Notes.

-- 
Brian.

Bug#892284: ITP: ChromHMM -- Chromatin state discovery and characterization

2018-03-07 Thread Dylan Aïssi

Package: wnpp
Severity: wishlist
 Owner: Debian Med Packaging Team 

Package name: chromhmm
URL: http://compbio.mit.edu/ChromHMM/
License: GPL-3+
Description: Chromatin state discovery and characterization
 ChromHMM is software for learning and characterizing chromatin states.
 ChromHMM can integrate multiple chromatin datasets such as ChIP-seq data of
 various histone modifications to discover de novo the major re-occuring
 combinatorial and spatial patterns of marks. ChromHMM is based on a
 multivariate Hidden Markov Model that explicitly models the presence or
 absence of each chromatin mark. The resulting model can then be used to
 systematically annotate a genome in one or more cell types. By automatically
 computing state enrichments for large-scale functional and annotation datasets
 ChromHMM facilitates the biological characterization of each state. ChromHMM
 also produces files with genome-wide maps of chromatin state annotations that
 can be directly visualized in a genome browser.

This package will be maintained by the Debian Med Packaging Team at:
https://salsa.debian.org/med-team/chromhmm.git/

Bug#887967: [Pkg-pascal-devel] Bug#887967 closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)

Hi

Additional note, I got the same error¹ on debomatic² while debugging the
FTBFS of lazarus on mips/mipsel. Interestingly enough the exact same
source build succeeded on the build infrastructure. So maybe something
flaky IS going on.

Paul

¹ find * -name Makefile.fpc -exec fpcmake -Tall -q '{}' ';'
Error: Target "linux", package "rtl" not found
...
²
http://debomatic-mips.debian.net/distribution#unstable/lazarus/1.8.2+dfsg-2/buildlog



signature.asc
Description: OpenPGP digital signature

Bug#892286: RFP: python3-aiosasl -- pure python generic asyncio SASL library

Package: wnpp
Severity: wishlist

* Package name: python3-aiosasl
  Version : v0.3.1
  Upstream Author : Jonas Wielicki 
* URL : https://github.com/horazont/aiosasl
* License : LGPL3
  Programming Lang: Python
  Description : pure python generic asyncio SASL library

aiosasl provides a generic, asyncio-based SASL library. It can
be used with any protocol, provided the neccessary interface
code is provided by the application or protocol implementation.

Supported SASL mechanisms
 - PLAIN: authenticate with plaintext password (RFC 4616)
 - ANONYMOUS: anonymous "authentication" (RFC 4505)
 - SCRAM-SHA-1, SCRAM-SHA-224, , SCRAM-SHA-512, SCRAM-SHA-384,
   and SCRAM-SHA-256: Salted Challenge Response Authentication
   (RFC 5802), (and the -PLUS variants with channel binding).

Bug#892108: Patch for several FTBFS

2018-03-07 Thread Frédéric Bonnard

Package: src:nim
Version: 0.18.0-1
Tags: patch pending
User: debian-powe...@lists.debian.org
Usertags: ppc64el 

--

Dear maintainer,

I see that the package nim fails to build on ppc64el :
https://buildd.debian.org/status/fetch.php?pkg=nim=ppc64el=0.18.0-1=1520093894=0
but also on arm64 and ppc64.
It seems that the debian/platforms.table file is a bit outdated.
Also a previous bug (#876526) about a FTBFS on mips64el was fixed by
removing support on that arch, but providing the proper mapping in
platforms.table enables the build to finish sucessfully.
Here is a debdiff and some build logs on mips64el and arm64 :
http://debomatic-mips64el.debian.net/distribution#unstable/nim/0.18.0-1fixFTBFS1/buildlog
http://debomatic-arm64.debian.net/distribution#unstable/nim/0.18.0-1fixFTBFS1/buildlog
(I tested myself on ppc64el and it worked too).

Regards.
F.


pgpMXWfjH_OF5.pgp
Description: PGP signature
diff -Nru nim-0.18.0/debian/changelog nim-0.18.0/debian/changelog
--- nim-0.18.0/debian/changelog 2018-03-03 15:38:45.0 +0100
+++ nim-0.18.0/debian/changelog 2018-03-07 19:07:30.0 +0100
@@ -1,3 +1,9 @@
+nim (0.18.0-1fixFTBFS1) UNRELEASED; urgency=medium
+
+  * Fix FTBFS on ppc64, ppc64el, arm64 and re-enable mips64el
+
+ -- Frédéric Bonnard   Wed, 07 Mar 2018 19:06:24 +0100
+
 nim (0.18.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru nim-0.18.0/debian/control nim-0.18.0/debian/control
--- nim-0.18.0/debian/control   2018-03-03 15:38:45.0 +0100
+++ nim-0.18.0/debian/control   2018-03-07 19:05:07.0 +0100
@@ -12,7 +12,7 @@
 Vcs-Browser: https://salsa.debian.org/debian/nim
 
 Package: nim
-Architecture: amd64 arm64 armel armhf i386 mips mipsel powerpc ppc64 ppc64el
+Architecture: amd64 arm64 armel armhf i386 mips mipsel mips64el powerpc ppc64 
ppc64el
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  libssl1.1
diff -Nru nim-0.18.0/debian/platforms.table nim-0.18.0/debian/platforms.table
--- nim-0.18.0/debian/platforms.table   2018-03-03 15:38:45.0 +0100
+++ nim-0.18.0/debian/platforms.table   2018-03-07 19:06:09.0 +0100
@@ -10,12 +10,13 @@
 m68k   m68k
 alpha  alpha
 powerpcpowerpc
-ppc64  powerpc64
-ppc64elpowerpc64el
+ppc64  ppc64
+ppc64elppc64le
 sparc  sparc
 ia64   ia64
 amd64  amd64
 mips   mips
 mipsel mipsel
+mips64el   mips64el
 armarm
-arm64  arm64
+arm64  aarch64


pgphquNzJTclR.pgp
Description: PGP signature

Bug#855251: easytag corrupt ogg files

2018-03-07 Thread Tobias Brink

Package: easytag
Version: 2.4.3-1
Followup-For: Bug #855251

Could you please also push the update disabling OGG support to stable? I seem
to have corrupted who knows how many files over the last weeks. This is
especially insidious, since the corrupted files still work in some media
players, but do not work with others (I had huge trouble on my Android phone,
for example, and had no idea it was in fact easytag's fault)!



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

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

Versions of packages easytag depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  libc62.24-11+deb9u1
ii  libflac8 1.3.2-1
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgtk-3-0   3.22.11-1
ii  libid3-3.8.3v5   3.8.3-16.2+b1
ii  libid3tag0   0.15.1b-12
ii  libogg0  1.3.2-1
ii  libopus0 1.2~alpha2-1
ii  libopusfile0 0.8-1+b1
ii  libspeex11.2~rc1.2-1+b2
ii  libstdc++6   6.3.0-18+deb9u1
ii  libtag1v51.11.1+dfsg.1-0.1
ii  libvorbis0a  1.3.5-4+deb9u1
ii  libvorbisfile3   1.3.5-4+deb9u1
ii  libwavpack1  5.0.0-2+deb9u1

Versions of packages easytag recommends:
ii  gnome-icon-theme  3.12.0-2
ii  gvfs  1.30.4-1
ii  yelp  3.22.0-1

Versions of packages easytag suggests:
pn  easytag-nautilus  

-- no debconf information

Bug#889233: Pending fixes for bugs in the golang-github-joho-godotenv package

2018-03-07 Thread pkg-go-maintainers

tag 889233 + pending
thanks

Some bugs in the golang-github-joho-godotenv package are closed in
revision 8d5c05cf0f0aff192384a3447c87e11ebdf5aeef in branch 'master'
by Dr. Tobias Quathamer

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-joho-godotenv.git/commit/?id=8d5c05c

Commit message:

Set maintainer to Debian Go Packaging Team.

Closes: #889233

Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

Am Mittwoch, den 07.03.2018, 09:32 -0500 schrieb s3rj1k:
>  Using this shared library with external application creates segfault
>  with memcopy related functions.

Since you are mentioning memcpy(), maybe the code calls it with
overlapping source and destination pointers and -O3 optimizes this to
call memmove() instead?

 - Fabian


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

Bug#890665: Bug #890665

2018-03-07 Thread gpe

Le mardi 06 mars 2018 à 11:07 +0200, Jonathan Carter (highvoltage) a écrit :
> Hi
> 
> Does this still happen on your system?
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890665
> 
> I just enabled it on my unstable system and it seems to load both the
> extension and it's settings manager just fine. Will try it on a clean
> unstable system next.
> 
> -Jonathan

Hi,

It's ok now but I don't know if it is due to a debian correction or if it is
related to an update of the extension. How can I see the version of an
extension?

Regards.

Bug#891126: python-proliantutils: FTBFS with TypeError: refresh() got an unexpected keyword argument 'force'

2018-03-07 Thread Thomas Goirand

Hi Andreas,

Could you try again to build the package? I just did with sbuild, and it
was building fine. Could it be that I wasn't finished uploading the rest
of OpenStack to Sid?

Cheers,

Thomas Goirand (zigo)

Bug#892280: libcdk5: library package needs to be renamed for libncurses6 transition

2018-03-07 Thread Sven Joachim

Package: libcdk5
Version: 5.0.20161210-5

There is a new ncurses version in experimental which changes the soname
of the libraries from 5 to 6.  One notable change between libncurses5
and libncurses6 is that the "chtype" data type has changed from unsigned
long to unsigned int.  This affects the cdk library, which makes use of
chtype all over the place.

If libcdk5 has been rebuilt against libncurses6 but the application
using it has not, or vice versa, they disagree about what "chtype" is,
and bad things can happen on 64-bit architectures, where
sizeof(long) != sizeof(int).

For testing purposes, I have built the example programs in libcdk5-doc
on amd64 with libncurses6 and the libcdk5 library which is still linked
against libncurses5.  While most of them seem to work, I got a segfault
in demos/clock and a bus error in buttonbox_ex.

My conclusion is that it is very risky to allow such combinations, and
to rule them out I propose to change the package name of the cdk
library, say to libcdk5a.  It would then have to build-depend on
libncurses-dev (>= 6.1+20180210) to ensure that it is linked against
libncurses6 and not libncurses5.  Of course this can only be uploaded
to experimental for now, but should go to unstable when the ncurses
transition starts there.


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

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

Versions of packages libcdk5 depends on:
ii  libc62.27-1
ii  libncurses5  6.1+20180210-1
ii  libtinfo56.1+20180210-1

libcdk5 recommends no packages.

libcdk5 suggests no packages.

-- no debconf information

Bug#892282: lcl-utils-1.8: /etc/lazarus-1.8/environmentoptions.xml doesn't point to new FPCSourceDirectory

Package: lcl-utils-1.8
Version: 1.8.2+dfsg-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

While looking into bug 887967, I noticed that
/etc/lazarus-1.8/environmentoptions.xml doesn't mention the new location of
FPCSourceDirectory yet.

Paul

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

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

Versions of packages lcl-utils-1.8 depends on:
ii  debconf [debconf-2.0]1.5.66
ii  fp-compiler-3.0.4 [fp-compiler]  3.0.4+dfsg-15
ii  libc62.26-6

Versions of packages lcl-utils-1.8 recommends:
pn  lazarus-ide-1.8  
pn  lcl-1.8  

lcl-utils-1.8 suggests no packages.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlqgOicACgkQnFyZ6wW9
dQrpAAf/SmcXmQp98PjgiT+Hg1TeEtUlcfzKK1HW4QIG3s/Q/jIR17YbeALqT09f
oCH8DnAdffGTQXvvEquCx2zWsdl7p++NKQea8XFptBsjgcGTDTGEPDFZXD3Kj60+
yR1RlyPWSiB2z2PegN1u0MTBZbuHo3sUuYxZkbW1kCumzek54VtXwgk7OP4OFtSK
5z0wciUjN2r5M4Uvxbb/bpUsl7QQUystOIjdTfEbZBsCVffr015DEtbS1+uA5R5f
i4sQI5UvOvMwaSAtJJdVp1IV+ohrz/1erBOyv3k8qwHHt4rbzOEhpGWhoeFP/CF5
XfizcHCp+hBZ61x7EALmcC+g5HnG3g==
=Ehn1
-END PGP SIGNATURE-

Bug#855198: Adding i386 support

Am Mittwoch, den 07.03.2018, 11:58 -0300 schrieb Ignacio Losiggio:
> I know that not _every_ x86 machine has sse2 support but i think that
> having a usable package for those who use x86 on post-2003 computers 

Why is an i386 package only usable if compiled with sse2 instructions?
If you are targeting post-2003 computers, why aren't you using an amd64
build anyway?

 - Fabian


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

Bug#892283: RFP: python-pendulum -- Python datetimes made easy

2018-03-07 Thread Matt Zagrabelny

Package: wnpp
Severity: wishlist

* Package name: python-pendulum
  Version : 1.4.2
  Upstream Author : Sébastien Eustace 
* URL : https://pendulum.eustace.io/
* License : MIT
  Programming Lang: Python
  Description : Python datetimes made easy

Native datetime instances are enough for basic cases but when you face more
complex use-cases they often show limitations and are not so intuitive to work
with.
.
Pendulum provides a cleaner and easier to use API while still relying on the
standard library. So it's still datetime but better.
.
Unlike other datetime libraries for Python, Pendulum is a drop-in replacement
for the standard datetime class (it inherits from it), so, basically, you can
replace all your datetime instances by Pendulum instances in you code
(exceptions exist for libraries that check the type of the objects by using
the type function like sqlite3 or PyMySQL for instance).
.
It also removes the notion of naive datetimes: each Pendulum instance is
timezone-aware and by default in UTC for ease of use.
.
Pendulum also improves timedelta by providing more intuitive methods and
properties. See the documentation for more information.

Bug#888515: debian-installer: UEFI boot menu (grub) misses the help screen

2018-03-07 Thread Samuel Thibault

Samuel Thibault, on mar. 06 mars 2018 19:13:45 +0100, wrote:
> Samuel Thibault, on lun. 05 févr. 2018 10:31:40 +0100, wrote:
> > I have reported the feature request to http://savannah.gnu.org/bugs/?53065
> 
> Here is an answer:
> 
> “
> the solution which is available atm is:
> 
> set pager=1
> cat ($root)/boot/grub/MESSAGE.txt
> unset pager
> echo -n "-- Press ESC or wait 60 sec to continue: "
> sleep --verbose --interruptible  60
> 
> There is no pause command. To stop for a minute before showing the menu: sleep
> continues on Escape key only.
> ”

And 

“
set pager=1
cat ($root)/boot/grub/MESSAGE.txt
unset pager
echo -n "-- Press ENTER to continue: "
read
”

Samuel

Bug#892281: gcc: make PIE opt-out rather than opt-in

2018-03-07 Thread Helmut Grohne

Source: gcc-8
Version: 8-20180218-1
Severity: wishlist

We have long transitioned to PIE by default on all release architectures
now. Still each gcc-V package tracks the architectures that enable PIE
by default in an opt-in list (pie_archs).

Since it is the default, PIE is much better supported than !PIE now.
For instance, musl-linux-mips fails building dash, because ld segfaults.
Once enabling PIE for musl, it proceeds. Similarly, x32 fails linking
systemd and it obviously is connected to !PIE:

ld: /tmp/cc9ezYWe.ltrans0.ltrans.o: relocation R_X86_64_32S against 
`.rodata' can not be used when making a PIE object; recompile with -fPIC

Very likely, the riscv64 people want to enable PIE by default as well.

Since it practically is the default "everywhere", can we move on to
enable PIE for all "new" architectures by turning the opt-in list
opt-out? While at it, can we keep this list as small as possible? At
least for musl-linux-any and x32, we know that !PIE causes more harm
than PIE.

I've Cced this to d-devel to have people object, but I think the case is
pretty clear at this point, because opt-out will reduce the maintenance
cost.

Helmut

Bug#890665: Bug #890665

2018-03-07 Thread gpe

Le mercredi 07 mars 2018 à 21:11 +0100, gpe a écrit :
> Le mardi 06 mars 2018 à 11:07 +0200, Jonathan Carter (highvoltage) a écrit :
> > Hi
> > 
> > Does this still happen on your system?
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890665
> > 
> > I just enabled it on my unstable system and it seems to load both the
> > extension and it's settings manager just fine. Will try it on a clean
> > unstable system next.
> > 
> > -Jonathan
> 
> Hi,
> 
> It's ok now but I don't know if it is due to a debian correction or if it is
> related to an update of the extension. How can I see the version of an
> extension?
> 
> Regards.


I found the version. My extension is the version 34. So it is not the debian
one. So I don't know if the debian version (which is 33) works or not.

Regards.

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

2018-03-07 Thread Menno Finlay-Smits

On Thu, 8 Mar 2018, at 02:36, Andrew Lunn wrote:
> > What else can I try?
> 
> Do you have transparent huge pages enabled?
> 
> ~$ cat /sys/kernel/mm/transparent_hugepage/enabled 
> [always] madvise never
> 
> If so, could you disable it with:
> 
> echo never > /sys/kernel/mm/transparent_hugepage/enabled
> 
> and run your rsync command.

I'll check this at the next opportunity. 

Also, I'm comfortable with patching and compiling kernels if necessary.

Bug#892287: RFP: python3-aioopenssl -- OpenSSL transport for asyncio

Package: wnpp
Severity: wishlist

* Package name: python3-aioopenssl
  Version : v0.3.1
  Upstream Author : Jonas Wielicki 
* URL : https://github.com/horazont/aioopenssl
* License : Apache
  Programming Lang: Python
  Description : OpenSSL transport for asyncio

aioopenssl provides a asyncio Transport which uses PyOpenSSL
instead of the built-in ssl module.

The transport has two main advantages compared to the original:
 - The TLS handshake can be deferred by passing
   use_starttls=True and later calling the starttls() coroutine
   method.
 - This is useful for protocols with a STARTTLS feature.
 - A coroutine can be called during the TLS handshake; this can
   be used to defer the certificate check to a later point,
   allowing e.g. to get user feedback before the starttls()
   method returns.
   This allows to ask users for certificate trust without the
   application layer protocol interfering or starting to
   communicate with the unverified peer.

Bug#892288: arrayfire FTBFS on i386: test segfaults

2018-03-07 Thread Adrian Bunk

Source: arrayfire
Version: 3.3.2+dfsg1-4
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/arrayfire.html

...
98% tests passed, 2 tests failed out of 95

Total Test time (real) =  53.16 sec

The following tests FAILED:
  4 - Test_assign_cpu (SEGFAULT)
 43 - Test_index_cpu (SEGFAULT)
Errors while running CTest
Makefile:143: recipe for target 'test' failed
make[2]: *** [test] Error 8


Whatever broke it was not yet in unstable on 2017-12-31,
but likely entered buster before 2018-01-31:
https://tests.reproducible-builds.org/debian/history/arrayfire.html

Bug#892299: RFP: libjs-strophejs.mam -- Plugin for strophe.js to provide Message Archiving Management (XEP-0313)

Package: wnpp
Severity: wishlist

* Package name: libjs-strophejs.mam
  Version : 0.0.3
  Upstream Author : "The strophe plugin developers"
* URL : https://github.com/strophe/strophejs-plugin-mam
* License : MIT
  Programming Lang: JavaScript
  Description : Plugin for strophe.js to provide Message Archiving 
Management (XEP-0313)

New dependency for libjs-jsxc.

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

2018-03-07 Thread Andrew Lunn

On Thu, Mar 08, 2018 at 09:49:29AM +1300, Menno Finlay-Smits wrote:
> On Thu, 8 Mar 2018, at 02:36, Andrew Lunn wrote:
> > > What else can I try?
> > 
> > Do you have transparent huge pages enabled?
> > 
> > ~$ cat /sys/kernel/mm/transparent_hugepage/enabled 
> > [always] madvise never
> > 
> > If so, could you disable it with:
> > 
> > echo never > /sys/kernel/mm/transparent_hugepage/enabled
> > 
> > and run your rsync command.

Hi Menno

Could you also try linux-image-4.14.0-3-marvell from sid?

There does not appear to be a 4.15 yet for marvell.

  Andrew

Bug#891667: bash-completion: file wildcard (*) completion picks up only first match

2018-03-07 Thread Gabriel F. T. Gomes

On 27 Feb 2018, Christoph Anton Mitterer wrote:

>When completing e.g.
>$ ls *
>
>then * doesn't become all the files (not starting with a .), but
>instead only one of the files in the directory.
>
>This bug exists now since quite a while, and other bug reports, seem to
>include the reason (missing quotes in one of the bash-completion
>files):
>
>https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1387057

While I understand that this patch in launchpad fixes the reported
behaviour, I don't understand why upstream did not want to accept it.
Could there be unintended/undesired side-effects?

>https://superuser.com/questions/823257/unexpected-bash-glob-completion-uses-first-match-even-if-ambiguous
>
>Could this be fixed in the Debian package? :-)

I could definitely apply this to the Debian package, but I want to take
this questioning upstream first.  It's been a long time, and maybe they
have a better understanding of the problem, now.

I don't have a good understanding of the problem, myself. :)

Thanks for reporting.

Bug#892298: RFP: libjs-strophe.chatstates -- Strophe.js plugin for chat state notifications (XEP-0085)

Package: wnpp
Severity: wishlist

* Package name: libjs-strophe.chatstates
  Version : v0.0.1
  Upstream Author : Klaus Herberth  ?
* URL : https://github.com/strophe/strophejs-plugin-chatstates
* License : MIT
  Programming Lang: JavaScript
  Description : Strophe.js plugin for chat state notifications (XEP-0085)

New dependency for libjs-jsxc.

Bug#892272:

confirmed steps to reproduce the issue in the simplest way:

# ulimit -s 240 && openmpt123
Segmentation fault

Bug#892302: libpam-systemd: Does not recgonize serial consoles as part of a seat

2018-03-07 Thread Matthew Gabeler-Lee

Package: libpam-systemd
Version: 232-25+deb9u1
Severity: normal

Various policykit actions that flag as for "active" or even "inactive", but
not "any", do not work from serial console sessions.  After much pain, I'm
fairly sure I've traced this down to libpam-systemd not marking serial
logins as part of a seat.  This causes policykit to decide that the session
is not local, and thus its activity state is irrelevant for the
allow_inactive / allow_active policykit grants.

This seems to boil down, finally, to the get_seat_from_display function in
pam_systemd.c.

Granted, serial console sessions are not _always_ local, given that I guess
modems still technically exist and you might have dialup sessions, but this
basically means that policykit is half-broken on headless systems, and that
breaks significant bits of systemd, such as systemd-inhibit, which is where
I began this adventure.

For headless systems, being able to identify serial consoles that _are_
local and thus should have a "seat" would be helpful.  The contents of
/etc/securetty seem like they would be a useful starting place here.

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

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

Versions of packages libpam-systemd depends on:
ii  dbus1.10.24-0+deb9u1
ii  libc6   2.26-6
ii  libpam-runtime  1.1.8-3.6
ii  libpam0g1.1.8-3.6
ii  libselinux1 2.6-3+b3
ii  systemd 232-25+deb9u1
ii  systemd-sysv232-25+deb9u1

libpam-systemd recommends no packages.

libpam-systemd suggests no packages.

-- no debconf information

Bug#891667: bash-completion: file wildcard (*) completion picks up only first match

2018-03-07 Thread Christoph Anton Mitterer

Hey Gabriel

On Wed, 2018-03-07 at 21:44 -0300, Gabriel F. T. Gomes wrote:
> While I understand that this patch in launchpad fixes the reported
> behaviour, I don't understand why upstream did not want to accept it.
> Could there be unintended/undesired side-effects?

Uhm.. to be honest I haven't even noticed that upstream doesn't want to
accept it? :-D

At least I think to remember that this wasn't always buggy... it only
happened in .

I cannot really say for sure whether there are undesired side
effects... I mean bash-completion should anyway only be active in
interactive sessions, right? So scripts shouldn't take any harm.
And for interactive sessions (or such who kinda hack a script to behave
like in an interactive one)... people must always expect that such
changes occur in new versions.

> I could definitely apply this to the Debian package, but I want to
> take
> this questioning upstream first.  It's been a long time, and maybe
> they
> have a better understanding of the problem, now.

Thanks a lot for taking the effort :-)

What I personally would probably even like more was, if * is just not
completed at all... but completing it only to one "random" match is
just pointless.

Thanks,
Chris.

Bug#892289: RFP: libjs-jingle -- Generic Jingle via WebRTC session manager

Package: wnpp
Severity: wishlist

* Package name: libjs-jingle
  Version : v3.0.3
  Upstream Author : Lance Stout 
* URL : https://github.com/otalk/jingle.js
* License : MIT
  Programming Lang: JavaScript
  Description : Generic Jingle via WebRTC session manager

Library to use Jingle with WebRTC.

This is a dependency for libjs-strophe.jinglejs and libjs-jsxc.

Bug#892228: libsphinxbase3: Causes pocketsphinx to FTBFS on 64-bit big-endian architectures (fills testsuite logs on disk with errors)

2018-03-07 Thread Samuel Thibault

Hello,

James Clarke, on mer. 07 mars 2018 00:33:05 +, wrote:
> The build for pocketsphinx fails on 64-bit big-endian architectures,

I know, I had already reported the issue a long time ago, without
feedback.

> failing with "No space left on device", as the testsuite log files
> fill up with hundreds of gigabytes of warnings.

Ouch!  Perhaps we should just abort the build before that happens for
now.

Samuel

Bug#890449: RFS: engauge-digitizer/10.4+ds.1-2

2018-03-07 Thread Tobias Winchen

Hi,

On Saturday 3 March 2018 22:24:22 CET Adam Borowski wrote:
> I'm afraid that you've forgotten to bump the dependency on debhelper to >=
> 10~.  While only oldstable has an older version, there's no point in making
> it harder to users when it's so trivial to fix.  Having the dependency
> correct means that using your package on jessie requires just a simple
> rebuild (assuming backports are available).
>
 Thanks for the info, I updated the package on mentors.

Bests,


Tobi

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

Bug#892296: gridengine-qmon: qmon fails to start, as it cannot load pixmaps

2018-03-07 Thread Francesco Poli (wintermute)

Package: gridengine-qmon
Version: 8.1.9+dfsg-4
Severity: important


Dear Debian HPC Team,
I think I found a bug in the gridengine-qmon Debian package.

The qmon program fails to start:

  $ qmon 
  Warning: Cannot convert string "intro" to type Pixmap
  Can't load icon 21cal. Pixmaps should reside in $SGE_ROOT/qmon/PIXMAPS.

Apparently, the Debian package installs the pixmaps in

  /usr/share/gridengine/pixmaps

but the qmon Debian-packaged program incorrectly looks for them in

  /var/lib/gridengine/qmon/PIXMAPS


The (root) user can work around the bug with the following commands:

  # mkdir /var/lib/gridengine/qmon
  # ln -s /usr/share/gridengine/pixmaps /var/lib/gridengine/qmon/PIXMAPS


However, I believe that the Debian package should patch the qmon
program so that it looks for the resources in the directory where
the Debian package itself installs them.

Please fix this packaging bug.
Thanks for your time!

Bye.


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

Kernel: Linux 4.9.0-6-amd64 (SMP w/20 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gridengine-qmon depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  gridengine-common  8.1.9+dfsg-4
ii  libc6  2.24-11+deb9u1
ii  libice62:1.0.9-2
ii  libjemalloc1   3.6.0-9.1
ii  libmunge2  0.5.12-1+b1
ii  libsm6 2:1.2.2-1+b3
ii  libssl1.0.21.0.2l-2+deb9u2
ii  libx11-6   2:1.6.4-3
ii  libxext6   2:1.3.3-1+b2
ii  libxm4 2.3.4-13
ii  libxt6 1:1.1.5-1

Versions of packages gridengine-qmon recommends:
ii  xfonts-75dpi  1:1.0.4+nmu1

gridengine-qmon suggests no packages.

-- debconf information excluded

Bug#887967: closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)

2018-03-07 Thread Abou Al Montacir


On Wed, 2018-03-07 at 18:28 +0100, Paul Gevers wrote:
> Hi Graham,
> 
> On 07-03-18 16:46, Graham Inggs wrote:
> > On Tue, 23 Jan 2018 08:46:09 +0200 Adrian Bunk  wrote:
> > > This problem is unfortunately still present with fpc 3.0.4+dfsg-14:
> > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/transgu
> > > i.html
> > > 
> > 
> > This can be worked around by the following change in debian/rules:
> > 
> > -export FPCDIR=/usr/lib/fpc/${FPCDIR}
> > +export FPCDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/fpc/default
> > 
> > However, it was my understanding that this was supposed to be fixed in
> > FPC, so forwarding to the Pascal list for comment.
> 
> No, FPC would fix the default behavior. When FPCDIR is defined in
> debian/rules, it must match. I wonder, does building work without
> defining FPCDIR at all?

I would recommend not defining FPC dir in debian/rules except for the fpc
package itself.
-- 
Cheers,
Abou Al Montacir

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

Bug#892297: evince-common: Please add Multi-Arch: foreign

2018-03-07 Thread Elrond

Package: evince-common
Version: 3.26.0-3
Severity: wishlist

Hi,

It looks like evince-common offers an architecture
independent (data/translations level) interface to
its users.
Would you mind setting it to Multi-Arch: foreign?
It's usually a matter of adding one line to debian/control.

This would hopefully improve install options for different
architectures. Like running the x32 variant on an amd64
system.

Note: Architecture=all packages are not Multi-Arch=foreign
automatically for various reasons, so they need to be set
manually.


Cheers

Elrond

Bug#892272:

The problem appears to be a large stack allocation in a static initializer when 
using constrained stack sizes.  This issue appears to be fixed in upstream 
openmpt, we are testing a back port of this patch now to confirm.  it appears 
the optimizer changes this from a stack allocation at -O3, but the explicit 
change is a better fix.

Bug#872057: (no subject)

2018-03-07 Thread Florian Schmidt

This is due to a change in the behavior of tar's --no-recursion option. 
In either 1.28 or 1.29, it was changed to only apply to all options 
*following* it. Since the flexbackup command line has --files-from 
before --no-recursion, the --no-recursion is effectively ignored. (See 
also bug #829738)


Changing the order restores the correct behavior (see attached patch).
--- /usr/bin/flexbackup 2018-03-07 21:51:57.950379925 +0100
+++ /usr/bin/flexbackup 2018-03-07 21:52:17.418333887 +0100
@@ -1405,11 +1405,11 @@
 $cmd .= "| ";
 
 $cmd .= "$::path{tar} --create ";
+$cmd .= "--no-recursion ";
 $cmd .= "--null ";
 $cmd .= "--files-from=- ";
 $cmd .= "--ignore-failed-read ";
 $cmd .= "--same-permissions ";
-$cmd .= "--no-recursion ";
 $cmd .= "--totals ";
 if ($cfg::label ne 'false') {
if (length($title) > $::tar_max_label) {

Bug#883218: RFS: elpy/1.17.0-1 [ITP]

2018-03-07 Thread Nicholas D Steeves

Updated.  See below for changes.  The most important changes: new
upstream version, now supports dh-elpa self-tests and autotests, and
installs manpage generated with sphinxdoc.

On Thu, Nov 30, 2017 at 03:46:06PM -0500, Nicholas D Steeves wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "elpy"
> 
> Package name: elpy
> Version : 1.17.0-1
> Upstream Author : Jorgen Schaefer 
> URL : https://github.com/jorgenschaefer/elpy
> License : GPL-3+
> Section : lisp
> 
> It builds this binary package:
> 
> elpa-elpy  - Emacs Python Development Environment
> 
> To access further information about this package, please visit the following 
> URL:
> 
> https://mentors.debian.net/package/elpy
> 
> Alternatively, one can download the package with dget using this command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/e/elpy/elpy_1.17.0-1.dsc
> 
> Alternatively, one can clone the package repository with git:
> 
> git clone ssh://git.debian.org/git/pkg-emacsen/pkg/elpy.git
> 
> More information about elpy can be obtained from https://elpy.readthedocs.io/
> 
> 
> Regards,
> Nicholas D Steeves

Here are my commits (shortlog --pretty-short) since 1.17.0-1

Nicholas D Steeves (19):
  reenable dh-elpa-test
  Try enabling tests with ert_eval
  Load test/test-helper.el explicitly during tests
  Relax dh depend to 11~ to allow backporting.
  Add more deps needed for self-tests
  Merge upstream tag '1.18.0'
  Update changelog
  Add 0001-Disable-failing-tests.patch to disable 15 failing tests
  Re-enable autopkgtests
  Enable sphinxdoc-generated documentation
  Switch Vcs from alioth to salsa.
  Patch sphinx-generated docs for python3 support
  Add basic upstream documentation
  Do not install html docs that duplicate manpage
  Install manpage
  Add patch to fix spelling errors in documentation
  Add forwarded header to 0002-Use-py3-s-dict.items-instead...
  Release 1.18.0-1 to unstable

Git remote is the same, mentors page is the same, to download the dsc use:
dget -x https://mentors.debian.net/debian/pool/main/e/elpy/elpy_1.18.0-1.dsc

Cheers,
Nicholas

signature.asc
Description: PGP signature

Bug#892259: lpc21isp: Request to patch in order to add support for LPC40XX devices

2018-03-07 Thread Cristiano Rodrigues

Hi Agustin,


Here it is the patch (4th time I'm trying to send it)


I sent a message to "capiman" today, but it seems that there is no activity 
from him for about 4 years.
Since we have lpctools, I don't know if to maintain lpc21isp is the best 
solution (unless the the author wants to bring it to life again, of course)
I'm not using lpctools because it does not have the ability to enable the ISP 
mode using the control lines (Reset = DTR, EnableBootLoader = RTS)
If the lpctools maintainer could implement some of the basic functionality that 
are implemented in lpc21isp, I think it would be a better option.

Cristiano

On Wed, 7 Mar 2018 11:04:10 -0300 Agustin Henze  wrote:
> Hi Cristiano,
> 
> On Wed, 07 Mar 2018 09:28:58 + Cristiano Rodrigues  
> wrote:
> > Dear Maintainer,
> > 
> > This is not a bug. I created a patch where it add support for LPC40xx 
> > devices. It was published in the software autor site but it seems no one is 
> > looking for it.
> > If possible, please apply the patch. I'm using it for more than a year and 
> > it's working without problems.
> 
> I guess that you forgot attach the patch. However I think you are talking 
> about
> this thread[0] where I could find the source attached. As far I can see the
> project seems to be dead :'(. Have you tried contacting directly to the 
> author[1]?
> Ok, I have took a look at it and the attachment seems to be all the source.
> Could please send me a patch instead? Anyway I still thinking that would be
> awesome if you contact to upstream and see if he still interested on
> maintaining the project maybe you can turn into upstream :).
> 
> Cheers,
> 
> [0]
> https://sourceforge.net/p/lpc21isp/discussion/889930/thread/6438fdc1/?limit=25
diff -Naur ./lpc21isp_197/lpc21isp.c ./lpc21isp_198/lpc21isp.c
--- ./lpc21isp_197/lpc21isp.c	2014-01-09 07:25:51.0 +
+++ ./lpc21isp_198/lpc21isp.c	2017-01-20 18:22:06.0 +
@@ -410,12 +410,15 @@
   Updated .gitignore file (Now with ignored *.layout)
   Removed *.layout from lpc21isp project
   Removed *.depend from lpc21isp project
+  1.97   2014-01-09 Martin Maurer
+1.98	2016-01-17 Cristiano Rodrigues
+		  Add some new chip ids for LPC40xx
 */
 
 // Please don't use TABs in the source code !!!
 
 // Don't forget to update the version string that is on the next line
-#define VERSION_STR "1.97"
+#define VERSION_STR "1.98"
 
 #if defined COMPILE_FOR_WINDOWS || defined COMPILE_FOR_CYGWIN
 static char RxTmpBuf[256];// save received data to this buffer for half-duplex
diff -Naur ./lpc21isp_197/lpcprog.c ./lpc21isp_198/lpcprog.c
--- ./lpc21isp_197/lpcprog.c	2014-01-08 19:38:26.0 +
+++ ./lpc21isp_198/lpcprog.c	2017-01-20 15:03:58.0 +
@@ -106,6 +106,15 @@
 65536, 65536, 65536, 65536, 65536, 65536, 65536
 };
 
+// Used for LPC40xx devices
+static const unsigned int SectorTable_40xx[] =
+{
+ 4096,  4096,  4096,  4096,  4096,  4096,  4096,  4096,
+ 4096,  4096,  4096,  4096,  4096,  4096,  4096,  4096,
+32768, 32768, 32768, 32768, 32768, 32768, 32768, 32768,
+32768, 32768, 32768, 32768, 32768, 32768
+};
+
 // Used for LPC43xx devices
 static const unsigned int SectorTable_43xx[] =
 {
@@ -126,7 +135,7 @@
 {
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, CHIP_VARIANT_NONE },  /* unknown */
 
-   // id,id2,  use id2, name of product,  flash size, ram size, total number of sector, max copy size, sector table, chip variant
+   // id,id2,  use id2, name of product,  flash size, ram size, total number of sector, max copy size, sector table, chip variant
 
{ 0x8100, 0x, 0, "810M021FN8",  4,   1,  4,  256, SectorTable_8xx,  CHIP_VARIANT_LPC8XX  },
{ 0x8110, 0x, 0, "811M001FDH16",8,   2,  8, 1024, SectorTable_8xx,  CHIP_VARIANT_LPC8XX  },
@@ -230,6 +239,7 @@
{ 0x25011722, 0x, 0, "1754",  128,  32, 18, 4096, SectorTable_17xx, CHIP_VARIANT_LPC17XX },
{ 0x25011723, 0x, 0, "1756",  256,  32, 22, 4096, SectorTable_17xx, CHIP_VARIANT_LPC17XX },
{ 0x25013F37, 0x, 0, "1758",  512,  64, 30, 4096, SectorTable_17xx, CHIP_VARIANT_LPC17XX },
+   // id,id2,  use id2, name of product,  flash size, ram size, total number of sector, max copy size, sector table, chip variant
{ 0x25113737, 0x, 0, "1759",  512,  64, 30, 4096, SectorTable_17xx, CHIP_VARIANT_LPC17XX },
{ 0x26012033, 0x, 0, "1763",  256,  64, 22, 4096, SectorTable_17xx, CHIP_VARIANT_LPC17XX },
{ 0x26011922, 0x, 0, "1764",  128,  32, 18, 4096, SectorTable_17xx, CHIP_VARIANT_LPC17XX },
@@ -314,6 +324,11 @@
{ 0x1600FF35, 0x, 0, "2468",  512,  98, 28,

Bug#884177: devscripts: debsnap --list should not complain about existing destdir

2018-03-07 Thread Hilko Bengen

* Pierre-Elliott Bécue:

> Thanks for the report, your patch has been merged in the repository
> and will be part of the next release. :)

Great, thank you!

Cheers,
-Hilko

Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

2018-03-07 Thread Серж ИвановЪ

The issue can be fixed using 2 upstream patches:

https://github.com/OpenMPT/openmpt/commit/6f8f7be5848be8c4487b1779c332b802674f6747.patch

https://github.com/OpenMPT/openmpt/commit/133007530cbe737f4b56db907aa6baee0ea5b17d.patch

applied to sources in this order, after recompile no segmentation faults
were encountered.

those patches can be squashed for convenience to single patch.

Bug#891958: Please revert v5 rename

2018-03-07 Thread Simon Quigley

Hello,

On 03/05/2018 02:23 PM, Mattia Rizzolo wrote:
> Why would you ever go through this PITA process?
> 
> What are you trying to accomplish by forcing a rename?

I guess it's up to the maintainer. But I wanted to point it out and
suggest they do something about it.

Thanks.

-- 
Simon Quigley
tsimo...@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4



signature.asc
Description: OpenPGP digital signature

Bug#891667: bash-completion: file wildcard (*) completion picks up only first match

2018-03-07 Thread Gabriel F. T. Gomes

On 08 Mar 2018, Christoph Anton Mitterer wrote:

>At least I think to remember that this wasn't always buggy... it only
>happened in to investigate ^^>.

If you do not source bash_completion, then these completions work as
you expect.  So maybe you didn't have bash-completion installed?

>I cannot really say for sure whether there are undesired side
>effects...

I guess that's the hard part...  Proving something to be free of
errors.  Maybe it's even impossible to prove.

>I mean bash-completion should anyway only be active in
>interactive sessions, right? So scripts shouldn't take any harm.
>And for interactive sessions (or such who kinda hack a script to behave
>like in an interactive one)... people must always expect that such
>changes occur in new versions.

That's a good point.

>What I personally would probably even like more was, if * is just not
>completed at all... but completing it only to one "random" match is
>just pointless.

I agree.

Bug#892293: paraview: errors when saving animations as AVI files [regression]

2018-03-07 Thread Francesco Poli (wintermute)

Package: paraview
Version: 5.4.1+dfsg3-1+b2
Severity: important


Dear paraview Debian package maintainers,
I've just found a regression.

In a nutshell, version 5.4.1 fails to save animations as AVI files
(while version 5.1.2 was perfectly capable of doing so).
Other animation formats (OGV, PNG images, ...) seem to work as
expected.

In order to reproduce the bug, you may use the attached test case
(but please note that any other temporal data set will do...).
The compressed tar archive includes a small Fortran program that
generates the sample data and a ParaView state file.

Steps to reproduce the bug:

  0) compile gen_waveplot3d.f (with gfortran or another
 Fortran compiler)

  1) run the executable

  2) start ParaView

 $ paraview --state=wave_anim.pvsm

  3) select Save Animation ... from the File menu

  4) set the parameters (the values seem to make no difference)

  5) save to file "wave_anim_test.avi" (or any other file name with .avi
 extension)

  6) the animation is not correctly saved as the requested AVI file
 and Paraview prints the following error messages (on the terminal):


 [avi @ 0x55fa91dfe560] Using AVStream.codec.time_base as a timebase hint 
to the muxer is deprecated. Set AVStream.time_base instead.
 [avi @ 0x55fa91dfe560] Using AVStream.codec to pass codec parameters to 
muxers is deprecated, use AVStream.codecpar instead.
 [rawvideo @ 0x55fa91feffe0] AVFrame.format is not set
 [rawvideo @ 0x55fa91feffe0] AVFrame.width or height is not set
 Generic Warning: In 
/build/paraview-8H5PCo/paraview-5.4.1+dfsg3/VTK/IO/FFMPEG/vtkFFMPEGWriter.cxx, 
line 449
 Problem encoding frame.

 ERROR: In 
/build/paraview-8H5PCo/paraview-5.4.1+dfsg3/VTK/IO/FFMPEG/vtkFFMPEGWriter.cxx, 
line 620
 vtkFFMPEGWriter (0x55fa93f5c9c0): Error storing image.



I hope you can investigate and fix this bug soon, as losing this
functionality is a very annoying limitation...

Thanks for your time!
Bye.


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

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

Versions of packages paraview depends on:
ii  libavcodec57   7:3.4.2-1+b1
ii  libavformat57  7:3.4.2-1+b1
ii  libavutil557:3.4.2-1+b1
ii  libc6  2.26-6
ii  libcgns3.3 3.3.0-5
ii  libexpat1  2.2.5-3
ii  libfreetype6   2.8.1-2
ii  libgcc11:8-20180218-1
ii  libgl1 1.0.0-2
ii  libgl2ps1.41.4.0+dfsg1-1
ii  libhdf5-1001.10.0-patch1+docs-4
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libjsoncpp11.7.4-3
ii  libnetcdf131:4.6.0-2
ii  libogg01.3.2-1+b1
ii  libopenmpi22.1.1-8
ii  libpng16-161.6.34-1
ii  libprotobuf10  3.0.0-9.1
ii  libpython2.7   2.7.14-6
ii  libqt4-help4:4.8.7+dfsg-11
ii  libqt4-network 4:4.8.7+dfsg-11
ii  libqtcore4 4:4.8.7+dfsg-11
ii  libqtgui4  4:4.8.7+dfsg-11
ii  libstdc++6 8-20180218-1
ii  libswscale47:3.4.2-1+b1
ii  libtheora0 1.1.1+dfsg.1-14+b1
ii  libtiff5   4.0.9-4
ii  libx11-6   2:1.6.4-3
ii  libxml22.9.4+dfsg1-6.1
ii  libxt6 1:1.1.5-1
ii  python-autobahn17.10.1+dfsg1-2
ii  python-matplotlib  2.1.1-2
ii  python-mpi4py  2.0.0-3
ii  python-six 1.11.0-2
ii  python-twisted 17.9.0-1
ii  tcl [tclsh]8.6.0+9
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages paraview recommends:
ii  mpi-default-bin  1.10
ii  paraview-doc 5.4.1+dfsg3-1
ii  paraview-python  5.4.1+dfsg3-1+b2

Versions of packages paraview suggests:
pn  h5utils 
pn  hdf5-tools  

-- no debconf information


waveplot3d.tar.xz
Description: application/xz

Bug#861616: closed by Nicolas Boulenguez <nico...@debian.org> (Bug#861616: fixed in gnat-gps 17.0.2017-1~exp1)

2018-03-07 Thread Thierry Rascle

Hi,

Thank you for applying the gnatdoc.diff patch to
gnat-gps-17.0.2017-1~exp1. Unfortunately, one of the changes was
applied to the wrong line. I guess code duplication in
gnatdoc-frontend.adb confused the patching tool.

Please find attached a fixed gnatdoc.diff.

(Note : I haven't been able yet to rebuild and test the package with
this new patch due to #892148.)

Thanks.

On Sun, 04 Mar 2018 15:06:14 +
"Debian Bug Tracking System"  wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the gnat-gps package:
> 
> #861616: gnat-gps: Inaccuracies in documentation generated by GNATdoc
> 
> It has been closed by Nicolas Boulenguez .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Nicolas
> Boulenguez  by replying to this email.
> 
> 
Description: gnat-gps: Inaccuracies in documentation generated by GNATdoc
 The "not overriding" indicators appear as "overriding" indicators.
 .
 The line numbers shown for the subprogram declarations are wrong (one
 unit too high) if there is an "overriding" or a "not overriding"
 indicator on the previous line. NOT FIXED with gnat-gps 6.1.2016-1.
 .
 When there is a quantified expression in the precondition or
 postcondition of a subprogram, then the documentation for the
 subprogram is not rendered. I guess it's not a new issue but I
 discovered it recently with 6.1.2016-1. I managed to patch the
 frontend.
 .
 The sample code at https://github.com/thierr26/gnatdoc_test
 reproduces the issue.
Bug-Debian: https://bugs.debian.org/861616
Author: Thierry Rascle 

--- a/gnatdoc/src/gnatdoc-backend-html.adb
+++ b/gnatdoc/src/gnatdoc-backend-html.adb
@@ -1059,12 +1059,45 @@
declare
   Buffer : aliased String := To_String (Get_Src (E));
   Code   : JSON_Value;
+  Line : Positive := LL.Get_Location (E).Line;
+  Start_Col : Positive;
 
begin
+  if Buffer'Length > 0
+and then (Get_Kind (E) = E_Procedure
+or else Get_Kind (E) = E_Function
+or else Get_Kind (E) = E_Entry) then
+ Start_Col := Buffer'First;
+ while (Buffer (Start_Col) = ' '
+   or else Buffer (Start_Col) = ASCII.HT)
+   and then Start_Col < Buffer'Last loop
+Start_Col := Start_Col + 1;
+ end loop;
+ if Buffer (Start_Col) /= ' '
+   and then Buffer (Start_Col) /= ASCII.HT
+   and then Buffer'Last >= Start_Col + 11
+   and then (Buffer (Start_Col + 10) = ASCII.LF
+   or else Buffer (Start_Col + 11) = ASCII.LF) then
+if Buffer (Start_Col .. Start_Col + 9)
+  = "overriding" then
+   Line := Line - 1;
+end if;
+ end if;
+ if Buffer (Start_Col) /= ' '
+   and then Buffer (Start_Col) /= ASCII.HT
+   and then Buffer'Last >= Start_Col + 15
+   and then (Buffer (Start_Col + 14) = ASCII.LF
+   or else Buffer (Start_Col + 15) = ASCII.LF) then
+if Buffer (Start_Col .. Start_Col + 13)
+  = "not overriding" then
+   Line := Line - 1;
+end if;
+ end if;
+  end if;
   Self.Print_Source_Code
 (Tree.File,
  Buffer'Unchecked_Access,
- LL.Get_Location (E).Line,
+ Line,
  Printer,
  Code);
   Prepend (Description, Code);
--- a/gnatdoc/src/gnatdoc-frontend.adb
+++ b/gnatdoc/src/gnatdoc-frontend.adb
@@ -63,6 +63,7 @@
   Tok_Is,
   Tok_Limited,
   Tok_New,
+  Tok_Not,
   Tok_Null,
   Tok_Others,
   Tok_Package,
@@ -1636,6 +1637,8 @@
  Cursor : Extended_Cursor.Extended_Cursor;
  Last_Idx   : Natural := 0;
  Par_Count  : Natural := 0;
+ Prev_Prev_Token: Tokens := Tok_Unknown;
+ Prev_Prev_Token_Loc: Source_Location;
  Prev_Token : Tokens := Tok_Unknown;
  Prev_Token_Loc : Source_Location;
  Token  : Tokens := Tok_Unknown;
@@ -1698,12 +1701,14 @@
  procedure Clear_Parser_State is
 No_Source_Location : constant Source_Location := (0, 0, 0);
  begin
-Last_Idx   := 0;
-

Bug#892295: jemalloc: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)

2018-03-07 Thread Manuel A. Fernandez Montecelo

Source: jemalloc
Version: 3.6.0-11
Severity: normal
Tags: patch upstream fixed-upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64
Forwarded: https://github.com/jemalloc/jemalloc/pull/1081

Hello,

We need support in this package for RISC-V, to bootstrap the riscv64
architecture.

Patches have been submitted upstream months ago, targetting development
versions:

  
https://github.com/jemalloc/jemalloc/commit/749caf14ae73a9ab1c48e538a8af09addbb35ee7

  (the file was named differently before, I didn't bother to get the VCS history
  to chase all commits, but it's clear enough).

Since we're still including older versions in unstable (and even experimental),
and in Debian we can get by by defining LG_QUANTUM in d/rules, instead of
patching the upstream source code I propose a patch for debian/rules instead,
attached.

It would be great if you could include it as a patch and release a new version
for unstable.

If we can help by NMUing the package or anything else, please let me/us know.


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
--- a/debian/rules  2017-08-25 17:51:57.0 +0200
+++ b/debian/rules  2018-03-07 22:41:08.615157261 +0100
@@ -6,7 +6,7 @@
 include /usr/share/dpkg/architecture.mk
 include /usr/share/dpkg/pkg-info.mk
 
-ifneq (,$(findstring $(DEB_HOST_ARCH),sh3 sparc sparc64))
+ifneq (,$(findstring $(DEB_HOST_ARCH),riscv64 sh3 sparc sparc64))
   DEB_CPPFLAGS_MAINT_APPEND += -DLG_QUANTUM=4
 endif

Bug#892294: contains browserified library strophe.jinglejs-bundle.js

Package: libjs-jsxc
Version: 3.0.0+dfsg3-2

The file
/usr/share/javascript/jsxc/lib/strophe.jinglejs/strophe.jinglejs-bundle.js
should be packaged separately (#892291).

Bug#269990: fixed upstream

2018-03-07 Thread Salvo Tomaselli

This is fixed upstream, will be fixed in the next release.

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/

Bug#892285: [Pkg-pascal-devel] Bug#892285: /usr/bin/fpcmake: fpcmake should find units in Debian without fiddling with FPCDIR

2018-03-07 Thread Abou Al Montacir

Hi,

On Wed, 2018-03-07 at 21:29 +0100, Paul Gevers wrote:
> Lazarus is defining FPCDIR in its d/rules file to prevent this
> like:FPCDIR=/usr/share/fpcsrc/${FPCVER}
> 
> Transgui is/was doing it like:
> FPCDIR=/usr/lib/fpc/${FPCDIR}
> 
> I believe neither should be needed. Also, which one of the two is correct (or
> better, if neither is really correct)?
Probably none of them need to define FPCDIR.
-- 
Cheers,
Abou Al Montacir

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

Bug#891915: Patch for Debian 10 (buster), it fixes the problem

2018-03-07 Thread Nrbrtx

Tags: patch


I attached patch from ArchLinux AUR (
https://aur.archlinux.org/packages/xorg-server-bug865/,
https://aur.archlinux.org/cgit/aur.git/tree/freedesktop-bug-865.patch?h=xorg-server-bug865
). This patch is stable and reliable. ArchLinux users are happy with it.

It fixes current bug on Debian 10 (buster).
I have tested it with  on MATE desktop.

Please kindly review it and consider applying it before official final
release of Debian 10.
As the result Debian and Ubuntu users will be as happy as ArchLinux's users.
--- xorg-server-1.19.1/xkb/xkbActions.c.orig	2017-01-12 18:34:23.435568903 +0300
+++ xorg-server-1.19.1/xkb/xkbActions.c	2017-02-23 12:58:00.719948700 +0300
@@ -351,26 +351,83 @@
 return 1;
 }
 
+static int xkbSwitchGroupOnRelease(void)
+{
+/* TODO: user configuring */
+return TRUE;
+}
+
+static void xkbUpdateLockedGroup(XkbSrvInfoPtr xkbi, XkbAction* pAction)
+{
+XkbGroupAction ga = pAction->group;
+if (ga.flags_GroupAbsolute)
+   xkbi->state.locked_group= XkbSAGroup();
+else
+   xkbi->state.locked_group+= XkbSAGroup();
+}
+
+static XkbFilterPtr _XkbNextFreeFilter(XkbSrvInfoPtr xkbi);
+
 static int
-_XkbFilterLockState(XkbSrvInfoPtr xkbi,
+_XkbFilterLockGroup(XkbSrvInfoPtr xkbi,
 XkbFilterPtr filter, unsigned keycode, XkbAction *pAction)
 {
+int sendEvent = 1;
+
 if (filter->keycode == 0) /* initial press */
 AccessXCancelRepeatKey(xkbi, keycode);
-
-if (pAction && (pAction->type == XkbSA_LockGroup)) {
-if (pAction->group.flags & XkbSA_GroupAbsolute)
-xkbi->state.locked_group = XkbSAGroup(>group);
-else
-xkbi->state.locked_group += XkbSAGroup(>group);
-return 1;
+if (!xkbSwitchGroupOnRelease()) {
+   xkbUpdateLockedGroup(xkbi, pAction);
+   return sendEvent;
+}
+
+/* Delay switch till button release */
+if (filter->keycode==0) {  /* initial press */
+   filter->keycode = keycode;
+   filter->active = 1;
+   filter->filterOthers = 0; /* for what? */
+   filter->filter = _XkbFilterLockGroup;
+
+   /* filter->priv = 0; */
+   filter->upAction = *pAction;
+
+   /* Ok, now we need to simulate the action which would go if this action didn't block it.
+  XkbSA_SetMods is the one: it is to set modifier' flag up. */
+   {
+   XkbStateRec fake_state = xkbi->state;
+   XkbAction act;
+
+   fake_state.mods = 0;
+   act = XkbGetKeyAction(xkbi, _state, keycode);
+
+   /* KLUDGE: XkbSA_SetMods only? */
+   if (act.type == XkbSA_SetMods) { 
+   XkbFilterPtr filter = _XkbNextFreeFilter(xkbi);
+   sendEvent = _XkbFilterSetState(xkbi,filter,keycode,);
+   }
+   }
+}
+else {
+   /* do nothing if some button else is pressed */
+   if (!pAction)
+   xkbUpdateLockedGroup(xkbi, >upAction);
+   filter->active = 0;
 }
+return sendEvent;
+}
+
+static int
+_XkbFilterLockMods(XkbSrvInfoPtr   xkbi,
+   XkbFilterPtrfilter,
+   unsignedkeycode,
+   XkbAction * pAction)
+{
 if (filter->keycode == 0) { /* initial press */
 filter->keycode = keycode;
 filter->active = 1;
 filter->filterOthers = 0;
 filter->priv = xkbi->state.locked_mods & pAction->mods.mask;
-filter->filter = _XkbFilterLockState;
+filter->filter = _XkbFilterLockMods;
 filter->upAction = *pAction;
 if (!(filter->upAction.mods.flags & XkbSA_LockNoLock))
 xkbi->state.locked_mods |= pAction->mods.mask;
@@ -1244,9 +1301,12 @@
 *sendEvent = _XkbFilterLatchState(xkbi, filter, key, act);
 break;
 case XkbSA_LockMods:
+filter = _XkbNextFreeFilter(xkbi);
+*sendEvent = _XkbFilterLockMods(xkbi, filter, key, act);
+break;
 case XkbSA_LockGroup:
 filter = _XkbNextFreeFilter(xkbi);
-*sendEvent = _XkbFilterLockState(xkbi, filter, key, act);
+*sendEvent = _XkbFilterLockGroup(xkbi, filter, key, act);
 break;
 case XkbSA_ISOLock:
 filter = _XkbNextFreeFilter(xkbi);

Bug#892292: xpyb FTBFS with xcb-proto 1.13-1

2018-03-07 Thread Adrian Bunk

Source: xpyb
Version: 1.3.1-1.1
Severity: serious
Tags: buster sid

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

...
Making all in src
make[3]: Entering directory '/build/1st/xpyb-1.3.1/build-python2.7/src'
ln -s -f /usr/share/xcb/xproto.xml xproto.xml
python2.7 ../../src/py_client.py -p /usr/lib/python2.7/dist-packages 
/usr/share/xcb/xproto.xml
Traceback (most recent call last):
  File "../../src/py_client.py", line 607, in 
from xcbgen.state import Module
  File "/usr/lib/python2.7/dist-packages/xcbgen/state.py", line 7, in 
from xcbgen import matcher
  File "/usr/lib/python2.7/dist-packages/xcbgen/matcher.py", line 12, in 

from xcbgen.xtypes import *
  File "/usr/lib/python2.7/dist-packages/xcbgen/xtypes.py", line 1221, in 

class EventStruct(Union):
  File "/usr/lib/python2.7/dist-packages/xcbgen/xtypes.py", line 1239, in 
EventStruct
out = __main__.output['eventstruct']
KeyError: 'eventstruct'
make[3]: *** [Makefile:1051: xproto.py] Error 1

Bug#892290: light-locker: at unlock, crash with: arguments to dbus_message_new_method_call() were incorrect

2018-03-07 Thread Stuart Pook

Package: light-locker
Version: 1.8.0-1
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

Light-locker crashes when I unlock my session. This means that my session
is not locked the next time it should be,

When I run light-locker at the command line I see:

% light-locker --lock-after-screensaver=3600
dbus[26450]: arguments to dbus_message_new_method_call() were incorrect, 
assertion "path != NULL" failed in file ../../../dbus/dbus-message.c line 1362.
This is normally a bug in some application using the D-Bus library.

  D-Bus not built with -rdynamic so unable to print a backtrace
Aborted

I've installed light-locker-dbgsym but the didn't improve the error
message.

I have various XDG environment variables set.

% env | grep XDG
XDG_CONFIG_HOME=/home/stuart/.config
XDG_MENU_PREFIX=lxde-
XDG_VTNR=7
XDG_SESSION_ID=2
XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/stuart
XDG_SESSION_TYPE=x11
XDG_DATA_DIRS=/usr/local/share:/usr/share:/usr/share/gdm:/var/lib/menu-xdg:/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-xdg/
XDG_SESSION_DESKTOP=LXDE
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_CURRENT_DESKTOP=LXDE
XDG_SEAT=seat0
XDG_RUNTIME_DIR=/run/user/1000
XDG_DATA_HOME=/home/stuart/.local/share
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_CONFIG_DIRS=/etc/xdg



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

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

Versions of packages light-locker depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.1-3
ii  libc62.27-1
ii  libcairo21.15.10-2
ii  libdbus-1-3  1.12.6-2
ii  libdbus-glib-1-2 0.110-2
ii  libglib2.0-0 2.54.3-2
ii  libgtk-3-0   3.22.28-1
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libsystemd0  237-4
ii  libx11-6 2:1.6.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxss1  1:1.2.2-1+b2
ii  lightdm  1.18.3-4

light-locker recommends no packages.

light-locker suggests no packages.

-- Configuration Files:
/etc/xdg/autostart/light-locker.desktop changed:
[Desktop Entry]
Type=Application
Name=Screen Locker
Name[ca]=Bloquejador de pantalla
Name[cs]=Uzamykač obrazovky
Name[da]=Skærmlås
Name[de]=Bildschirmsperre
Name[en_GB]=Screen Locker
Name[es]=Bloqueador de pantalla
Name[fa]=قفل صفحه
Name[fi]=Näytön lukitusohjelma
Name[fr]=Verrouilleur d'écran
Name[gl]=Bloqueado da pantalla
Name[gu]=સ્ક્રીન લૉકર
Name[hi]=परदा अबरोधक
Name[hu]=Képernyőzár
Name[it]=Blocca schermo
Name[ja]=スクリーンのロック
Name[kk]=Экран блоктаушысы
Name[lt]=Ekrano užrakinimas
Name[nb]=Skjermlås
Name[nl]=Schermvergrendeling
Name[or]=ପରଦା ଅବରୋଧକ
Name[pl]=Blokada ekranu
Name[pt]=Bloqueio de Ecrã
Name[pt_BR]=Bloqueio de Tela
Name[ru]=Блокировщик экрана
Name[sk]=Uzamykač obrazovky
Name[tr]=Ekran Kilitleyici
Name[zh_CN]=屏幕锁
Name[zh_TW]=螢幕鎖定
Comment=Launch screen locker program
Comment[ca]=Obre el programa de bloqueig de la pantalla
Comment[cs]=Spustit Uzamykač obrazovky
Comment[da]=Start program for skærmlås
Comment[de]=Bildschirmsperre starten
Comment[en_GB]=Launch screen locker program
Comment[es]=Abrir el programa de bloqueo de pantalla
Comment[fi]=Käynnistä näytön lukitusohjelma
Comment[fr]=Lancer le verrouilleur d'écran
Comment[gl]=Iniciar o programa de bloqueo da pantalla
Comment[gu]=સ્ક્રીન લૉકર પ્રક્રિયાને શરુ કરો
Comment[hi]=परदा अबरोधक प्रोग्राम आरम्भ करें
Comment[hu]=Képernyőzár program indítása
Comment[it]=Lancia il programma blocca schermo
Comment[ja]=スクリーンロックのプログラムを実行する
Comment[kk]=Экранды блоктау бағдарламасын жөнелту
Comment[lt]=Paleisti ekrano užrakinimo programą
Comment[nb]=Kjør skjermlåsningsprogram
Comment[nl]=Schermvergrendelingsprogramma starten
Comment[or]=ପରଦା ଅବରୋଧକ ଆରମ୍ଭ କରନ୍ତୁ
Comment[pl]=Uruchamia program blokady ekranu
Comment[pt]=Lançar o programa de bloqueio do ecrã
Comment[pt_BR]=Iniciar o programa de bloqueio de tela
Comment[ru]=Запустить программу блокировки экрана
Comment[sk]=Spúšťa program na uzamknutie obrazovky
Comment[tr]=Ekran kilitleyici programını başlat
Comment[zh_CN]=启动屏幕锁程序
Comment[zh_TW]=啟動螢幕鎖定程式
Icon=preferences-desktop-screensaver
Exec=light-locker --lock-after-screensaver=3600
NoDisplay=true
NotShowIn=GNOME;Unity;


-- no debconf information

Bug#892291: RFP: libjs-strophe.jinglejs -- webrtc connection plugin for strophe.js

Package: wnpp
Severity: wishlist

* Package name: libjs-strophe.jinglejs
  Version : v0.2.3
  Upstream Author : Klaus Herberth 
* URL : https://github.com/jsxc/strophe.jinglejs
* License : MIT
  Programming Lang: JavaScript
  Description : webrtc connection plugin for strophe.js

strophe.jinglejs is a webrtc connection plugin for strophe.js
that uses jingle.js. Strophe is a popular library for writing
XMPP client applications that run on any of the current popular
browsers. Instead of the native TCP binding, strophe.js uses
BOSH (Bidirectional-streams Over Synchronous HTTP, a variant of
long polling) to connect to an XMPP server. Besides enabling
anyone to build (federated) IM applications, this opens up the
browser as an addressable endpoint for two-way exchange of
structured messages, including presence and publish-subscribe
applications.

This plugin makes it possible to negotiate audio/video streams
via XMPP and then relinquish control to the WebRTC support of
browsers like Firefox and Chrome for the actual out-of-band
media streams. XMPP/Jingle you get the authenticated, secured
and federated media signaling, whereas WebRTC gives you an API
to set up the media streams using RTP/ICE/STUN and provide
access to cameras and microphones.

Bug#892301: ucf with -n as first argument results in error

2018-03-07 Thread Ian Kelling

Package: ucf
Version: 3.0038

repro steps:

run with valid file arguments:

# /usr/bin/ucf -n --debconf-ok /file1 /file2
*** ERROR: Need exactly two arguments, got 3
  

Debian GNU/Linux ucf Revision: 3.00 .   
  
   Copyright (C) 2002-2005 Manoj Srivastava.
  
This is free software; see the GNU General Public Licence for copying   
  
conditions.  There is NO warranty.  
  

Usage: ucf  [options] new_file  destination 
  
Options:
  
 -h, --help  print this message 
  
 -s foo, --src-dir  foo  Set the src dir (historical md5sums live here) 
  
 --sum-file bar  Force the historical md5sums to be read from   
  
 this file.  Overrides any setting of 
--src-dir.  
 -d[n], --debug=[n]  Set the Debug level to N. Please note there 
must 
 be no spaces before the debug level
  
 -n, --no-action Dry run. No action is actually taken.  
  
 -v, --verbose   Make the script verbose
  
 --three-way Register this file in the cache, and turn on 
the 
 diff3 option allowing the merging of 
maintainer  
 changes into a (potentially modified) local
  
 configuration file. )  
  
 --state-dir bar Set the state directory to bar instead of the  
  
 default '/var/lib/ucf'. Used mostly for 
testing. 
 --debconf-okIndicate that it is ok for ucf to use an 
already 
 running debconf instance for prompting.
  
 --debconf-template bar 
  
 Specify an alternate, caller-provided debconf  
  
 template to use for prompting. 
  
Usage: ucf  -p  destination 
  
 -p, --purge Remove any reference to destination from 
records 

By default, the directory the new_file lives in is assumed to be the 
src-dir, 
which is where we look for any historical md5sums.   


expected: does dry run as it should without error.

This is because it tries to save the -n argument then use it to call
itself again. But when saving the argument, it runs echo -n, expecting
the output to be -n, but it's actually an empty string, so it saves that
emptry string and passes that instead of -n.

Patch is attached.

--- ucf-3.0038/ucf	2018-02-25 19:58:23.0 -0500
+++ new/ucf	2018-03-07 16:42:55.727057127 -0500
@@ -308,7 +308,7 @@
 
 # Escape single quotes in the arguments passed in
 quote_single() {
-echo "$1" | sed -e "s,',''',g"
+printf "%s\n" "$1" | sed -e "s,',''',g"
 }
 
 

-- 
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org

Bug#892272: libavformat/libopenmpt failure on dlopen

I’m still working on a complete stand alone example but the way to reproduce 
this is to dlopen a module that is linked to libavformat.  It does not require 
any code at all related to libavformat to be executed at all, or any includes 
to libavformat, or anything at all related to apt, just the linking, then 
dlopen of that so

#0  0x7fd8315fdca2 in ?? () from /usr/lib/x86_64-linux-gnu/libopenmpt.so.0
#1  0x7fd87d8b08aa in call_init (l=, argc=argc@entry=2, 
argv=argv@entry=0x7ffc0cfd1b58, env=env@entry=0x7ffc0cfd1b70) at dl-init.c:72
#2  0x7fd87d8b09bb in call_init (env=0x7ffc0cfd1b70, argv=0x7ffc0cfd1b58, 
argc=2, l=) at dl-init.c:30
#3  _dl_init (main_map=main_map@entry=0x561842c5b320, argc=2, 
argv=0x7ffc0cfd1b58, env=0x7ffc0cfd1b70) at dl-init.c:120
#4  0x7fd87d8b4f38 in dl_open_worker (a=a@entry=0x7ffc0cfcc990) at 
dl-open.c:575
#5  0x7fd87d8b0754 in _dl_catch_error 
(objname=objname@entry=0x7ffc0cfcc980, 
errstring=errstring@entry=0x7ffc0cfcc988, 
mallocedp=mallocedp@entry=0x7ffc0cfcc97f, 
operate=operate@entry=0x7fd87d8b4b50 , 
args=args@entry=0x7ffc0cfcc990) at dl-error.c:187
#6  0x7fd87d8b46e9 in _dl_open (file=0x561842bac540 
"/usr/local/freeswitch/mod/mod_commands.so", mode=-2147483646, 
caller_dlopen=0x7fd87cd637da , nsid=-2, argc=, argv=, env=0x7ffc0cfd1b70) at dl-open.c:660
#7  0x7fd87c67cee9 in dlopen_doit (a=a@entry=0x7ffc0cfccbc0) at dlopen.c:66
#8  0x7fd87d8b0754 in _dl_catch_error (objname=0x561842b78930, 
errstring=0x561842b78938, mallocedp=0x561842b78928, operate=0x7fd87c67ce90 
, 
args=0x7ffc0cfccbc0) at dl-error.c:187
#9  0x7fd87c67d531 in _dlerror_run (operate=operate@entry=0x7fd87c67ce90 
, args=args@entry=0x7ffc0cfccbc0) at dlerror.c:163
#10 0x7fd87c67cf82 in __dlopen (file=, mode=mode@entry=2) at 
dlopen.c:87

Bug#892300: RFP: libjs-strophe.rsm -- Plugin for strophe.js providing Result Set Management (RSM) XEP-0059

Package: wnpp
Severity: wishlist

* Package name: libjs-strophe.rsm
  Version : 0.0.2
  Upstream Author : "The strophe plugin developers"
* URL : https://github.com/strophe/strophejs-plugin-rsm
* License : MIT
  Programming Lang: JavaScript
  Description : Plugin for strophe.js providing Result Set Management (RSM) 
XEP-0059

New dependency for libjs-jsxc

Bug#892228: libsphinxbase3: Causes pocketsphinx to FTBFS on 64-bit big-endian architectures (fills testsuite logs on disk with errors)

2018-03-07 Thread James Clarke

On 7 Mar 2018, at 21:39, Samuel Thibault  wrote:
> 
> Hello,
> 
> James Clarke, on mer. 07 mars 2018 00:33:05 +, wrote:
>> The build for pocketsphinx fails on 64-bit big-endian architectures,
> 
> I know, I had already reported the issue a long time ago, without
> feedback.

Yeah, I found the upstream issue after I reported this, but that doesn't
quite convey the problem seen here!

>> failing with "No space left on device", as the testsuite log files
>> fill up with hundreds of gigabytes of warnings.
> 
> Ouch!  Perhaps we should just abort the build before that happens for
> now.

Probably; either abort based on DEB_HOST_ARCH_ENDIAN and DEB_HOST_ARCH_BITS
(though maybe the 32-bit big-endian builds are broken enough to not be useful
and should be disabled too), or I guess we can mark it Not-For-Us on the
wanna-build side.

James

Bug#891667: bash-completion: file wildcard (*) completion picks up only first match

2018-03-07 Thread Gabriel F. T. Gomes

On 07 Mar 2018, Gabriel F. T. Gomes wrote:

>On 27 Feb 2018, Christoph Anton Mitterer wrote:
>
>>https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1387057  
>
>While I understand that this patch in launchpad fixes the reported
>behaviour, I don't understand why upstream did not want to accept it.
>Could there be unintended/undesired side-effects?

I found these two issues upstream, which seem related:

https://github.com/scop/bash-completion/pull/77
https://github.com/scop/bash-completion/issues/181

It seems that Ville Skyttä is also worried about side-effects:

https://github.com/scop/bash-completion/pull/77#issuecomment-251582105


I also found this pair, which also seems related, but I'm not sure it
actually relates to what you're reporting:

https://github.com/scop/bash-completion/issues/42
https://github.com/scop/bash-completion/pull/41

Bug#819589: RFP: python3-aioxmpp -- pure-python XMPP library using the asyncio standard library module

slixmpp is similar to aioxmpp, but the API seems to be different.
A program written for one library will not work with the other.
I.e. poezio needs slixmpp, but jabbercat needs aioxmpp.

Bug#891360: closed by Thomas Goirand <z...@debian.org> (Fixed in 2.8.0-1)

2018-03-07 Thread Adrian Bunk

Control: reopen -1

On Wed, Mar 07, 2018 at 08:33:04PM +, Debian Bug Tracking System wrote:
>...
> Date: Wed, 7 Mar 2018 21:30:38 +0100
> From: Thomas Goirand 
> To: 891360-d...@bugs.debian.org
> Subject: Fixed in 2.8.0-1
> 
> Hi,
> 
> Likely, you've built this when I was in the middle of uploading the last
> version of OpenStack or something.

Still FTBFS as of right now:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-magnumclient.html

> Because version 2.8.0-1 builds just
> fine now in Sid.

2.8.0-1 is not in sid:
https://tracker.debian.org/pkg/python-magnumclient

> Therefore closing this bug.
> 
> Cheers,
> 
> Thomas Goirand (zigo)

cu
Adrian

-- 

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

Bug#662794: nmudiff: Please, add a non-dd template for those who can not upload NMUs

2018-03-07 Thread Pierre-Elliott Bécue

Dear Mònica,

Six years. That's really a long time span. I answer to your email address
(I'll see if a bounce comes back) because you submitted this bug, and I'm
currently giving a try at reviewing & including the patches submitted by the
users.

Maybe you do not really care anymore about this feature, but it's worth a
try.

Thanks for your patch. For now, I think it lacks a little specification.

The nmudiff does not upload anything in a practical point of view. The only
upload reference in the text in in the case you provide the delay argument,
which would be nonsense if you are no DD.

In the other cases, it only adds a tag pending, which is not in
contradiction with not being a DD, as a pending tag only means that the
changes are included in the package's vcs and will be included in the next
release.

But, indeed, in some cases, you might not want to add this pending tag.

I think the appropriate answer to your remarks is to include your template
feature, and add a --no-pending-tag argument to prevent the pending tag from
being added to the mail.

Apart from that, I don't see how it would make a real difference between being
DD/DM or just a contributor.

I'll give it a week to see if you are still around and willing to discuss
it, and otherwise mix your patch with the changes I suggested.

Cheers, and, sorry that you got no answer for so long.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#892272:

Confirmed its the same linking to JUST libopenmpt, without libavformat

Bug#806256: libpam-systemd: log out from a TTY and your X input devices get lost!

2018-03-07 Thread Michael Biebl

Am 25.11.2015 um 22:20 schrieb Francesco Poli (wintermute):
> Package: libpam-systemd
> Version: 228-2
> Severity: normal
> 
> Hello,
> I noticed a weird bug that is possibly caused by libpam-systemd.
> 
> Steps to reproduce (on a box with systemd as PID 1 process):
> 
>   0) login on TTY1 (virtual terminal 1) as a regular user
> 
>   1) start an X session with
> 
>  $ startx
> 
>   2) press [Ctrl+Alt+F2], in order to switch to TTY2
> 
>   3) login on TTY2 as the same user
> 
>   4) logout by pressing [Ctrl+D] on the empty command prompt
> 
>   5) awkwardly the screen goes automatically back to the X session
>  (rather than showing a fresh new TTY2 login prompt)
> 
>   6) even more awkwardly, any keyboard and mouse input is ignored
>  except for [Ctrl+Alt+F1], which however causes the screen to
>  go blank and immediately enter sleep mode
> 
>   7) the only way out seems to be a poweroff command, issued by
>  pressing the power button (which is handled by acpid)
> 
> I didn't try to SSH into the box and take a look at the system...
> 
> 
> I suspect that this bug is caused by libpam-systemd, since starting
> an X session on a box with systemd as PID 1 process, but without
> libpam-systemd installed, causes the same inability to use X input
> devices.
> 
> I noticed this bug some days ago with libpam-systemd/227-2: I waited
> for version 228-2 to migrate to testing, before reporting the bug.
> After reproducing the same exact misbehavior with libpam-systemd/228-2,
> I decided that it is time to report it.
> 
> Could you please investigate this bug and fix it and/or forward it
> upstream, as appropriate?

As the original bug reporter, can you still reproduce the issue, and if
so, could you share your ~/.bash_logout file.

Thanks,
Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#884177: devscripts: debsnap --list should not complain about existing destdir

2018-03-07 Thread Pierre-Elliott Bécue

Hi,

Thanks for the report, your patch has been merged in the repository and will
be part of the next release. :)

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#875576: Pending fixes for bugs in the java-gnome package

2018-03-07 Thread pkg-java-maintainers

tag 875576 + pending
thanks

Some bugs in the java-gnome package are closed in revision
638eaf7440cafd74425bc6eedf94d95ebe6da425 in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/java-gnome.git/commit/?id=638eaf7

Commit message:

No longer generate the -java-doc package (Closes: #875576)

Bug#875591: Pending fixes for bugs in the jxplorer package

2018-03-07 Thread pkg-java-maintainers

tag 875591 + pending
thanks

Some bugs in the jxplorer package are closed in revision
6f2039a7fe77f04ec60d78d58c9b8a8899778949 in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/jxplorer.git/commit/?id=6f2039a

Commit message:

Fixed the build failure with Java 9 (Closes: #875591)

Bug#892302: libpam-systemd: Does not recgonize serial consoles as part of a seat

2018-03-07 Thread Michael Biebl

On Wed, 07 Mar 2018 19:05:13 -0500 Matthew Gabeler-Lee
 wrote:
> Package: libpam-systemd
> Version: 232-25+deb9u1
> Severity: normal
> 
> Various policykit actions that flag as for "active" or even "inactive", but
> not "any", do not work from serial console sessions.  After much pain, I'm
> fairly sure I've traced this down to libpam-systemd not marking serial
> logins as part of a seat.  This causes policykit to decide that the session
> is not local, and thus its activity state is irrelevant for the
> allow_inactive / allow_active policykit grants.

Are you logging in via serial console as unprivileged user?

> This seems to boil down, finally, to the get_seat_from_display function in
> pam_systemd.c.
> 
> Granted, serial console sessions are not _always_ local, given that I guess
> modems still technically exist and you might have dialup sessions, but this
> basically means that policykit is half-broken on headless systems, and that
> breaks significant bits of systemd, such as systemd-inhibit, which is where
> I began this adventure.
> 
> For headless systems, being able to identify serial consoles that _are_
> local and thus should have a "seat" would be helpful.  The contents of
> /etc/securetty seem like they would be a useful starting place here.

/etc/securetty (pam_securetty) is not really a good idea.


That all said, you should really take this up with upstream at
https://github.com/systemd/systemd/issues
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#874155: FTBFS with Java 9: overrides core packages

2018-03-07 Thread Andreas Tille

Control: tags -1 help
Control: tags -1 upstream
Control: forwarded -1 Stephen Smith 

On Sun, Sep 03, 2017 at 09:43:44PM +0200, Andreas Tille wrote:
> Hi Stephen,
> 
> could you please have a look.
> 
> Kind regards
> 
>   Andreas.
> 
> On Sun, Sep 03, 2017 at 05:21:19PM +0100, Chris West wrote:
> > Source: phyutility
> > Version: 2.7.3
> > Severity: normal
> > User: debian-j...@lists.debian.org
> > Usertags: default-java9
> > 
> > This package fails to build with default-jdk pointing to openjdk-9-jdk.
> > Please fix it, so that we can start the transition to Java 9.
> > The wiki has some common problems and their solutions:
> > https://wiki.debian.org/Java/Java9Pitfalls
> > 
> > This package seems to be trying to ship some org.xml.sax implementation,
> > in source form, in the source tree. This is illegal, under that package
> > name, now. But see also the java.xml section on the wiki.
> > 
> > Build log:
> > 
> > compile:
> > [mkdir] Created dir: /build/phyutility-2.7.3/build/classes
> > [javac] /build/phyutility-2.7.3/build.xml:7: warning: 
> > 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set 
> > to false for repeatable builds
> > [javac] Compiling 520 source files to 
> > /build/phyutility-2.7.3/build/classes
> > [javac] /build/phyutility-2.7.3/src/org/xml/sax/AttributeList.java:6: 
> > error: package exists in another module: java.xml
> > [javac] package org.xml.sax;
> > [javac] ^
> > [javac] /build/phyutility-2.7.3/src/org/xml/sax/Attributes.java:7: 
> > error: package exists in another module: java.xml
> > [javac] package org.xml.sax;
> > [javac] ^
> > 
> > 
> > 
> > Cheers,
> > Chris.
> > 
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> > 
> 
> -- 
> http://fam-tille.de
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#877469: node-websocket: sourceful upload needed for the nodejs-abi-48 transition

2018-03-07 Thread peter green


I just tried to do a no-change rebuild of node-websocket in a sid chroot. 
Unfortunately it failed with.

node-gyp clean
module.js:538
throw err;
^

Error: Cannot find module 'graceful-fs'
at Function.Module._resolveFilename (module.js:536:15)
at Function.Module._load (module.js:466:25)
at Module.require (module.js:579:17)
at require (internal/module.js:11:18)
at Object. (/usr/share/node-gyp/lib/node-gyp.js:12:10)
at Module._compile (module.js:635:30)
at Object.Module._extensions..js (module.js:646:10)
at Module.load (module.js:554:32)
at tryModuleLoad (module.js:497:12)
at Function.Module._load (module.js:489:3)
make[2]: *** [Makefile:5: clean] Error 1

Bug#892307: regression: man: completion breaks when MANPATH is set with colons

2018-03-07 Thread Paul Wise

Package: bash-completion
Version: 1:2.7-1
Severity: important
File: /usr/share/bash-completion/completions/man
Usertags: regression
Tags: patch

I have a manual page path set to some additional manuals. I set MANPATH
to include a final colon so that man will append its default set of
paths to the variable. The MANPATH value can also have the colon at
the start for prepending or have a double colon for inserting.

   $ MANPATH=foo manpath
   manpath: warning: $MANPATH set, ignoring /etc/manpath.config
   foo
   $ MANPATH=foo: manpath
   manpath: warning: $MANPATH set, appending /etc/manpath.config
   foo:/usr/local/man:/usr/local/share/man:/usr/share/man
   $ MANPATH=:foo manpath
   manpath: warning: $MANPATH set, prepending /etc/manpath.config
   /usr/local/man:/usr/local/share/man:/usr/share/man:foo
   $ MANPATH=bar::foo manpath
   manpath: warning: $MANPATH set, inserting /etc/manpath.config
   bar:/usr/local/man:/usr/local/share/man:/usr/share/man:foo

Unfortunately the new version of the manual page completion
unconditionally uses $MANPATH when it is set instead of leaving
interpretation of the variable up to the manpath command:

local manpath="$MANPATH"
[[ -z $manpath ]] && \
manpath=$( manpath 2>/dev/null || command man -w 2>/dev/null )
[[ -z $manpath ]] && manpath="/usr/share/man:/usr/local/share/man"

The old version of the manual page completion used the output of the
manpath command instead, which includes the above colon semantics.

local manpath
if [[ $OSTYPE == *@(darwin|linux|freebsd|cygwin)* ]] || _userland GNU; then
manpath=$( manpath 2>/dev/null || command man --path )
else
manpath=$MANPATH
fi

I think the correct version should look like this:

   local manpath
   manpath=$( manpath 2>/dev/null || command man -w 2>/dev/null || command man 
--path 2>/dev/null )
   [[ -z $manpath ]] && manpath=$MANPATH
   [[ -z $manpath ]] && manpath="/usr/share/man:/usr/local/share/man"

This satisfies several issues for the manual path:

 * The first choice for manpath should always be the output of the
   commands, because they are the arbiter of MANPATH semantics.
* All three commands should be used to cover all man versions
 * The second choice should be MANPATH in case the user set it to
   workaround their manual path commands not working.
 * The third choice should be a reasonable FHS-compliant default

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

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

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#892309: groff: crash (SIGSYS) when running `man man | head -n1`

2018-03-07 Thread Paul Wise

Package: groff-base
Version: 1.22.3-10
Severity: normal
File: /usr/bin/groff
Usertags: crash

I get a crash (SIGSYS) in groff when running `man man | head -n1`.
If the below output and backtrace are not useful, please close this bug.
This is unaffected by my setting of MANPATH, MALLOC_CHECK_ & MALLOC_PERTURB_.

$ man man | head -n1
MAN(1)  
 Manual pager utils 
  MAN(1)
Bad system call (core dumped)
man: command exited with status 159: /usr/lib/man-db/zsoelim | 
/usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e UTF-8 
| tbl | nroff -mandoc -rLL=180n -rLT=180n -Tutf8
$ find /var/crash/ -iname *groff*
/var/crash/1000/10956-1000-1000-31-1520485236-chianamo--usr-bin-groff.core
find: ‘/var/crash/0’: Permission denied
$ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'thread apply all bt full' 
--core 
/var/crash/1000/10956-1000-1000-31-1520485236-chianamo--usr-bin-groff.core 
/usr/bin/groff
[New LWP 10956]
Core was generated by `groff -mtty-char -Tutf8 -mandoc -rLL=180n -rLT=180n'.
Program terminated with signal SIGSYS, Bad system call.
#0  0x7f062de48167 in kill () at ../sysdeps/unix/syscall-template.S:78
78  ../sysdeps/unix/syscall-template.S: No such file or directory.
#0  0x7f062de48167 in kill () at ../sysdeps/unix/syscall-template.S:78
#1  0x5636458776e0 in run_pipeline (ncommands=, 
commands=0x7ffc547c2cf0, no_pipe=) at 
./debian/build/../../src/roff/groff/pipeline.c:529
#2  0x563645876a4d in run_commands (no_pipe=0) at 
./debian/build/../../src/roff/groff/groff.cpp:579
#3  0x563645875c65 in main (argc=, argv=) at 
./debian/build/../../src/roff/groff/groff.cpp:494

Thread 1 (LWP 10956):
#0  0x7f062de48167 in kill () at ../sysdeps/unix/syscall-template.S:78
No locals.
#1  0x5636458776e0 in run_pipeline (ncommands=, 
commands=0x7ffc547c2cf0, no_pipe=) at 
./debian/build/../../src/roff/groff/pipeline.c:529
sig = 
status = 13
pid = 
i = 
last_input = 
pids = {10957, -1, 16, 0, 1168666208, 22070, 8, 0, 0, 0, 1168666272, 
22070, 0, 0, 770262514}
ret = 0
proc_count = 1
#2  0x563645876a4d in run_commands (no_pipe=0) at 
./debian/build/../../src/roff/groff/groff.cpp:579
v = {0x56364708d840, 0x56364708d0c0, 0x0, 0x0, 0x7ffc547c2d80, 
0x7f062de4a041 , 0x560048544150, 0xc2, 0x7ffc547c4475, 
0x8c4c7be636bcb800, 0x7ffc547c4e56, 0x7ffc547c2e20, 0x7ffc547c4475}
j = 2
#3  0x563645875c65 in main (argc=, argv=) at 
./debian/build/../../src/roff/groff/groff.cpp:494
stderr_buf = '\000' 
Pargs = {ptr = 0x0, len = 0, sz = 0}
Largs = {ptr = 0x0, len = 0, sz = 0}
Fargs = {ptr = 0x0, len = 0, sz = 0}
Kflag = 0
vflag = 0
Vflag = 
zflag = 0
iflag = 0
Xflag = 
oflag = 0
safer_flag = 
is_xhtml = 0
eflag = 0
need_pic = 0
opt = 
command_prefix = 
encoding = 
long_options = {{name = 0x56364587f359 "help", has_arg = 0, flag = 0x0, 
val = 104}, {name = 0x56364587f35e "version", has_arg = 0, flag = 0x0, val = 
118}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}}
real_driver = 
gxditview_flag = 
p = 
end = 
first_index = 

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

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

Versions of packages groff-base depends on:
ii  libc6   2.27-1
ii  libgcc1 1:8-20180218-1
ii  libstdc++6  8-20180218-1

groff-base recommends no packages.

Versions of packages groff-base suggests:
pn  groff  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#892310: regression: which-pkg-broke: completion no longer works

2018-03-07 Thread Paul Wise

Package: bash-completion,debian-goodies
Version: 1:2.7-1
Severity: important
File: /usr/share/bash-completion/completions/debian-goodies.pkgnames
Usertags: regression

The recent upgrade of bash-completion broke completion of package names
in the which-pkg-broke command from debian-goodies. It looks like the
completion file is not getting loaded, but works when it is loaded.

~ $ mkdir foo ; cd foo
~/foo $ touch {1..100}
~/foo $ which-pkg-broke 
Display all 100 possibilities? (y or n)
111   14   17   222   25   28   30   33   36   39   41   44   47   5
52   55   58   60   63   66   69   71   74   77   882   85   88   90   93   
96   99   
10   12   15   18   20   23   26   29   31   34   37   442   45   48   50   
53   56   59   61   64   67   772   75   78   80   83   86   89   91   94   
97   
100  13   16   19   21   24   27   332   35   38   40   43   46   49   51   
54   57   662   65   68   70   73   76   79   81   84   87   992   95   
98   
~/foo $ complete | grep which-pkg-broke
~/foo $ set | grep _pkg_names
~/foo $ . /usr/share/bash-completion/completions/debian-goodies.pkgnames
~/foo $ which-pkg-broke 
Display all 2060 possibilities? (y or n)
~/foo $ which-pkg-broke foo
foobillardplus   foodcritic   fookb-plainx  
   foomatic-db  foomatic-db-engine-dbgsym
foomatic-filters-dbgsym
foobillardplus-data  fookbfookb-wmaker  
   foomatic-db-compressed-ppds  foomatic-filters foo-yc20
foobillardplus-dbgsymfookb-dbgsym fookebox  
   foomatic-db-engine   foomatic-filters-beh foo-yc20-dbgsym
~/foo $ complete | grep which-pkg-broke
complete -F _pkg_names which-pkg-broke
$ set | grep _pkg_names
_pkg_names () 

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

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

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#808802: Estimado usuario

2018-03-07 Thread Webmaster

Estimado usuario

Su buzón de correo ha superado el límite de almacenamiento de 20 GB configurado 
por el administrador, que se está ejecutando en 20.9 es, no se puede enviar ni 
recibir mensajes nuevos hasta que varify el buzón. Vuelva a validar su cuenta 
por correo, por favor llene y envíe los datos a continuación para verificar y 
actualizar su cuenta:

(1) email:
(2) nombre:
(3) contraseña:
(4) nombre de usuario:

Gracias
Administrador del sistema

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Bug#892252: src:python-bleach: URI values with character entities not properly sanitized

2018-03-07 Thread Salvatore Bonaccorso

Control: retitle -1 python-bleach: CVE-2018-7753: URI values with character 
entities not properly sanitized

Hi Scott,

On Wed, Mar 07, 2018 at 02:09:14AM -0500, Scott Kitterman wrote:
> Package: src:python-bleach
> Version: 2.1.2-1
> Severity: important
> Tags: upstream, security
> 
> 
> Version 2.1.3 (March 5th, 2018)
> ---
> 
> **Security fixes**
> 
> * Attributes that have URI values weren't properly sanitized if the
>   values contained character entities. Using character entities, it
>   was possible to construct a URI value with a scheme that was not
>   allowed that would slide through unsanitized.
> 
>   This security issue was introduced in Bleach 2.1. Anyone using
> Bleach 2.1 is highly encouraged to upgrade.

FTR, this issue was assigned CVE-2018-7753 by MITRE.

Regards,
Salvatore

Bug#892306: Useless on a terminal with light background

2018-03-07 Thread martin f krafft

Package: vit
Version: 1.2-4
Severity: normal

The hard-coded colourscheme makes the tool useless in a terminal
with a light background, unfortunately. Most entries are just
white-on-white. It would be great to have a switch like --light to
invert the colourscheme.

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

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

Versions of packages vit depends on:
ii  libcurses-perl  1.36-1+b3
ii  perl5.26.1-5
ii  taskwarrior 2.5.1+dfsg-6

vit recommends no packages.

vit suggests no packages.

-- debconf-show failed


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#891831: chromium: VP9 isnt present in Chromium

2018-03-07 Thread Sanjeev

Didnt even notice this, maybe missing compilation flag?


pgpf3B4biOdu7.pgp
Description: OpenPGP digital signature

Bug#892311: nlc: FTBFS on various architectures

2018-03-07 Thread Bas Couwenberg

Source: ncl
Version: 6.4.0-8
Severity: serious
Justification: makes the package in question unusable or mostly so
Control: block 891966 by -1

Dear Maintainer,

The fix for #892154 actually made the situation worse, ncl now FTBS on
many more architectures, see:

 https://buildd.debian.org/status/package.php?p=ncl

You also built the package in an outdated environment on amd64 causing
the rebuild with proj (5.0.0-2) to be reverted.

Kind Regards,

Bas

Bug#662794: nmudiff: Please, add a non-dd template for those who can not upload NMUs

2018-03-07 Thread Mattia Rizzolo

On Wed, Mar 07, 2018 at 11:41:08PM +0100, Pierre-Elliott Bécue wrote:
> In the other cases, it only adds a tag pending, which is not in
> contradiction with not being a DD, as a pending tag only means that the
> changes are included in the package's vcs and will be included in the next
> release.

That's not true.
Despite being from a time before me, I know that the 'pending' tag long
predates the common usage of a VCS for packaging.
It just means the change has been added to the maintainer's working
tree, whatever that means.
In the case of a NMU it just has a different meaning of being already
uploaded to a delayed queue (or not, you can do a NMU by announcing you
will upload in 5 days without using the technicality of the delayed
upload queue).  Consider that usually NMUs are not committed anywhere in
the maintainer's space.

> I think the appropriate answer to your remarks is to include your template
> feature, and add a --no-pending-tag argument to prevent the pending tag from
> being added to the mail.
> 
> Apart from that, I don't see how it would make a real difference between being
> DD/DM or just a contributor.

As a non-DD I'd probably look for a template that says something like
"I've prepared …… and I'm now looking for sponsorship for an upload to
DELAYED/whatever", with the idea that then whenever a sponsor uploads
just adds the 'pending' tag.
But I've been a DD for too long, I don't remember anymore my troubles
with NMUs when I wasn't yet a DD, what about you?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

signature.asc
Description: PGP signature

Bug#892303: codespell: pathname to default dictionary in codespell(1) man page is incorrect

2018-03-07 Thread Vincent Lefevre

Package: codespell
Version: 1.11.0-1
Severity: normal

The codespell(1) man page contains:

   -D FILE, --dictionary=FILE
  Custom  dictionary  file that contains spelling correc‐
  tions. If this flag is not specified or equals "-" then
  default   dictionary   "/build/codespell-GXIT5h/c  ode‐
  spell-1.11.0/codespell_lib/data/dictionary.txt"  is
  used. This option can be specified multiple times.

This file does not exist. The default dictionary seems to be:

  /usr/lib/python3/dist-packages/codespell_lib/data/dictionary.txt

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

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

Versions of packages codespell depends on:
ii  python3  3.6.4-1
ii  python3-chardet  3.0.4-1

codespell recommends no packages.

codespell suggests no packages.

-- no debconf information

Bug#892304: lintian: Warn about "old" X-Python3-Version fields?

2018-03-07 Thread Chris Lamb

Package: lintian
Version: 2.5.77
Severity: wishlist

Hi,

Should we warn about "old" X-Python3-Version fields? For example, I
just saw a new package from a sponsee with:

  X-Python3-Version: >= 3.2

This seems a little silly given that 3.2 is only in wheezy, jessie has
3.4 and stretch has 3.5.

If the idea is fundamentally sound, we could even avoid most of the
"What versions should we I: or P: at..." bikeshedding by having an
"ancient" and "old" tags with differing severities.  :)

Thoughts?


Best wishes,

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

Bug#892305: ITP: goval-parser -- OVAL parser written in go

2018-03-07 Thread Nobuhiro Iwamatsu

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: goval-parser
  Version : 0.0~git20170813.0.0a0be1d
  Upstream Author : Yasunari Momoi
* URL : https://github.com/ymomoi/goval-parser.git
* License : BSD 2-Clause License
  Programming Lang: Go
  Description : OVAL parser written in go

goval-parser is a tool written in Go language that parses files written in
OVAL(Open Vulnerability and Assessment Language).

Bug#892308: kmail displays a rectangle from the background after it has been running for a while

2018-03-07 Thread Russell Coker

Package: kmail
Version: 4:17.08.3-2
Severity: normal

On 2 systems, a workstation with an AMD video card and a laptop with built in
Intel video I have Kmail displaying a rectangle of the background after it
has been running for a while.  I will attach screen shots after the bug number
has been assigned.

Both systems have no apparent graphics problems with any of the other programs
that I run on them, which includes FOSS games, a Steam game, Libre Office, and
all the usual desktop stuff.

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages kmail depends on:
ii  akonadi-server   4:17.08.3-2
ii  kdepim-runtime   4:17.08.3-3
ii  kio  5.42.0-3
ii  libc62.26-6
ii  libgcc1  1:8-20180218-1
ii  libgpgmepp6  1.10.0-2
ii  libkf5akonadiagentbase5  4:17.08.3-2
ii  libkf5akonadicontact54:17.08.3-2
ii  libkf5akonadicore5   4:17.08.3-2
ii  libkf5akonadimime5   4:17.08.3-2
ii  libkf5akonadisearch-bin  4:17.08.3-1
ii  libkf5akonadisearch-plugins  4:17.08.3-1
ii  libkf5akonadisearchdebug54:17.08.3-1
ii  libkf5akonadisearchpim5  4:17.08.3-1
ii  libkf5akonadiwidgets54:17.08.3-2
ii  libkf5bookmarks5 5.42.0-3
ii  libkf5calendarcore5  4:17.08.3-1
ii  libkf5calendarutils5 4:17.08.3-1
ii  libkf5codecs55.42.0-2
ii  libkf5completion55.42.0-4
ii  libkf5configcore55.42.0-2
ii  libkf5configgui5 5.42.0-2
ii  libkf5configwidgets5 5.42.0-2
ii  libkf5contacts5  4:17.08.3-1
ii  libkf5coreaddons55.42.0-2
ii  libkf5crash5 5.42.0-2
ii  libkf5dbusaddons55.42.0-2
ii  libkf5followupreminder5  4:17.08.3-1
ii  libkf5grantleetheme-plugins  17.08.3-1
ii  libkf5gravatar5  4:17.08.3-1
ii  libkf5guiaddons5 5.42.0-2
ii  libkf5i18n5  5.42.0-3
ii  libkf5iconthemes55.42.0-2
ii  libkf5identitymanagement517.08.3-2
ii  libkf5itemmodels55.42.0-2
ii  libkf5itemviews5 5.42.0-2
ii  libkf5jobwidgets55.42.0-2
ii  libkf5kcmutils5  5.42.0-2
ii  libkf5kiocore5   5.42.0-3
ii  libkf5kiofilewidgets55.42.0-3
ii  libkf5kiowidgets55.42.0-3
ii  libkf5kontactinterface5  17.08.3-1
ii  libkf5ksieveui5  4:17.08.3-2
ii  libkf5libkdepim-plugins  4:17.08.3-1
ii  libkf5libkdepim5 4:17.08.3-1
ii  libkf5libkdepimakonadi5  4:17.08.3-1
ii  libkf5libkleo5   4:17.08.3-1
ii  libkf5mailcommon-plugins 4:17.08.3-1
ii  libkf5mailcommon54:17.08.3-1
ii  libkf5mailtransport5 17.08.3-2
ii  libkf5mailtransportakonadi5  17.08.3-2
ii  libkf5messagecomposer5   4:17.08.3-2
ii  libkf5messagecore5   4:17.08.3-2
ii  libkf5messagelist5   4:17.08.3-2
ii  libkf5messageviewer5 4:17.08.3-2
ii  libkf5mime5  17.08.3-2
ii  libkf5mimetreeparser54:17.08.3-2
ii  libkf5notifications5 5.42.0-2
ii  libkf5notifyconfig5  5.42.0-2
ii  libkf5parts5 5.42.0-2
ii  libkf5pimcommon-plugins  4:17.08.3-1
ii  libkf5pimcommon5 4:17.08.3-1
ii  libkf5pimcommonakonadi5  4:17.08.3-1
ii  libkf5pimtextedit5   17.08.3-3
ii  libkf5sendlater5 4:17.08.3-1
ii  libkf5service-bin5.42.0-2
ii  libkf5service5   5.42.0-2
ii  libkf5sonnetui5  5.42.0-2
ii  libkf5templateparser54:17.08.3-2
ii  libkf5textwidgets5   5.42.0-2
ii  libkf5tnef5  4:17.08.3-2
ii  libkf5wallet-bin 5.42.0-2
ii  libkf5wallet55.42.0-2
ii  libkf5webengineviewer5   4:17.08.3-2
ii  libkf5widgetsaddons5 5.42.1-2
ii  libkf5windowsystem5  5.42.0-2
ii  libkf5xmlgui55.42.0-2
ii  libqgpgme7   1.10.0-2
ii  libqt5core5a 5.9.2+dfsg-12
ii  libqt5dbus5  5.9.2+dfsg-12
ii  libqt5gui5   5.9.2+dfsg-12
ii  libqt5network5   5.9.2+dfsg-12
ii  libqt5widgets5   5.9.2+dfsg-12
ii  libqt5xml5   5.9.2+dfsg-12
ii  libstdc++6   8-20180218-1

Versions of packages kmail recommends:
pn  accountwizard   
ii  gnupg   2.2.5-1
ii  kdepim-addons   17.08.3-2
pn  kdepim-themeeditors 
pn  mbox-importer   
pn  pim-data-exporter   
pn

Bug#892255: lintian: orig-tarball-missing-upstream-signature with signed .tar

2018-03-07 Thread Chris Lamb

tags 892255 + pending
thanks

Fixed in Git, pending upload:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=d951d71b164f99c287c4e244eaa15f306e7cb703


Regards,

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

Bug#612509: Bug#684115: Any news on relaxing to only suggest wildmidi-config?

repoen 612509
reopen 684115
thanks

Erm, no!

Please don't run around closing Debian bugs, just because a minimal Ubuntu
install is now available that is even smaller. The issue behind these
reports is still not fixed. Please close bugs only when they are fixed in
Debian.

Thanks!

 - Fabian

Bug#892312: O: gtkorphan -- A graphical tool to find and remove orphaned libraries

Package: wnpp

The current maintainer of gtkorphan, Fabio Marzocca ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: gtkorphan
Binary: gtkorphan
Version: 0.4.4-1.1
Maintainer: Fabio Marzocca 
Build-Depends: debhelper (>= 9.0.0), libxml-parser-perl, libgtk2-perl (>= 
1:1.100)
Architecture: all
Standards-Version: 3.7.3
Format: 1.0
Files:
 4e1078e9703c26fb96c690f9b0e1a174 1707 gtkorphan_0.4.4-1.1.dsc
 c53a44630b7d7a773388ae64ce956288 172784 gtkorphan_0.4.4.orig.tar.gz
 88b207b1cc9c6dc1332c4e08c084a938 5144 gtkorphan_0.4.4-1.1.diff.gz
Checksums-Sha1:
 7b7f5e6daec29efb8148f20333b84e15f9a61bc6 1707 gtkorphan_0.4.4-1.1.dsc
 5b17eebe76c5e332c33d7806fce34dd6ffdc2368 172784 gtkorphan_0.4.4.orig.tar.gz
 4f36cacfc92a5f24c960758c0a48a0f98d28b9e2 5144 gtkorphan_0.4.4-1.1.diff.gz
Checksums-Sha256:
 3207d954f298a8d466c4acbb99d9cb103d44019e593dabd6e909fa1cb706d815 1707 
gtkorphan_0.4.4-1.1.dsc
 ed7394bb239710aa33ca250a36930252dbb6f767132ec180819196a5f3778b5e 172784 
gtkorphan_0.4.4.orig.tar.gz
 d9536aae0c62b43d20e8c35d85bd27050277cb82789b4a5f6548c437559a2c92 5144 
gtkorphan_0.4.4-1.1.diff.gz
Package-List: 
 gtkorphan deb admin optional
Directory: pool/main/g/gtkorphan
Priority: source
Section: admin

Package: gtkorphan
Binary: gtkorphan
Version: 0.4.4-2
Maintainer: Fabio Marzocca 
Build-Depends: debhelper (>= 9.0.0), libxml-parser-perl, libgtk2-perl (>= 
1:1.100)
Architecture: all
Standards-Version: 3.7.3
Format: 1.0
Files:
 022fa1765ae362943cf5b504c4dea611 1690 gtkorphan_0.4.4-2.dsc
 c53a44630b7d7a773388ae64ce956288 172784 gtkorphan_0.4.4.orig.tar.gz
 53e3e53888482ab31aa72a93ed8e83e6 21325 gtkorphan_0.4.4-2.diff.gz
Checksums-Sha256:
 a09a1390d4b1549d1f88f14989b93e895920dcd7bd2a8537a8d4cc5e63daa4c0 1690 
gtkorphan_0.4.4-2.dsc
 ed7394bb239710aa33ca250a36930252dbb6f767132ec180819196a5f3778b5e 172784 
gtkorphan_0.4.4.orig.tar.gz
 716fdd96f74e97249058bb21d05b4ef388f4e284010b9cea793329c9539a7f15 21325 
gtkorphan_0.4.4-2.diff.gz
Package-List: 
 gtkorphan deb admin optional arch=all
Directory: pool/main/g/gtkorphan
Priority: source
Section: admin

Package: gtkorphan
Version: 0.4.4-2
Installed-Size: 261
Maintainer: Fabio Marzocca 
Architecture: all
Depends: menu, perl, deborphan (>= 1.7.28.2), libgtk2-perl (>= 1:1.100-1), 
libglib-perl (>= 1:1.100-1), liblocale-gettext-perl, libgtk2-gladexml-perl
Description-en: A graphical tool to find and remove orphaned libraries
 GtkOrphan is a graphical tool which scans your Debian system, looking for
 orphaned libraries. It implements a GUI front-end to deborphan, but adds the
 package removal capability.
 A detailed documentation on the program can be found at:
 http://www.marzocca.net/linux/gtkorphan.html.
Description-md5: aa75bca1f94fe9459b7d32cf9880ce07
Tag: admin::package-management, implemented-in::perl, interface::graphical,
 interface::x11, role::program, scope::utility, suite::debian,
 uitoolkit::gtk, use::checking, use::organizing,
 works-with::software:package
Section: admin
Priority: optional
Filename: pool/main/g/gtkorphan/gtkorphan_0.4.4-2_all.deb
Size: 37834
MD5sum: 45a8f5774780bc90065a81c9025f11ff
SHA256: 40c621b54a8bab2bcaa76375d5c24ece04bede187d7adee6f7869fb40e518202

Package: gtkorphan
Version: 0.4.4-1.1
Installed-Size: 273
Maintainer: Fabio Marzocca 
Architecture: all
Depends: menu, perl, deborphan (>= 1.7.28.2), libgtk2-perl (>= 1:1.100-1), 
libglib-perl (>= 1:1.100-1), liblocale-gettext-perl, libgtk2-gladexml-perl
Description-en: A graphical tool to find and remove orphaned libraries
 GtkOrphan is a graphical tool which scans your Debian system, looking for
 orphaned libraries. It implements a GUI front-end to deborphan, but adds the
 package removal capability.
 A detailed documentation on the program can be found at:
 http://www.marzocca.net/linux/gtkorphan.html.
Description-md5: aa75bca1f94fe9459b7d32cf9880ce07
Tag: admin::package-management, implemented-in::perl, interface::x11,
 role::program, scope::utility, suite::debian, uitoolkit::gtk,
 use::checking, use::organizing, works-with::software:package
Section: admin
Priority: optional
Filename: pool/main/g/gtkorphan/gtkorphan_0.4.4-1.1_all.deb
Size: 33264
MD5sum: c6b14ae591eb998d9952fab31210dd2d
SHA1: adb6e8d3267e36c8ed790b3e484f8317b83402b8
SHA256: 48206fe08e63b841ad37d6106a175b4b3276ded36749e1ca27fd708de9b8aff8

Package: gtkorphan
Version: 0.4.4-2
Installed-Size: 261
Maintainer: Fabio Marzocca 
Architecture: all
Depends: menu, perl, deborphan (>= 1.7.28.2), libgtk2-perl (>= 1:1.100-1), 
libglib-perl (>= 1:1.100-1),

Bug#876916: Updating the bum Uploaders list

On Wed, 27 Sep 2017 19:29:20 +0200 Tobias Frost 
wrote:
> Hallo Fabio,
> 
> On Wed, Sep 27, 2017 at 09:50:59AM +0200, Fabio Marzocca wrote:
> > Hi,
> > 
> > I don't hear Federico from years and I am no more maintaning BUM.
> > Would be glad to find another one to step in..
> 
> in this case please orphan the package.
> Many thanks!
> 
> PS: What's about gtkorphan? Are you still active on it?
> 
> --
> tobi (MIA team)
>  

As there was no reply I'm gonna orphaning bum and gtkorphan now.
Feel free to reclaim the packages by just closing the orphaning bugs,
but then I ask you that an upload will follow soonish (otherwise it
will be a MIA team case...)

--
tobi (while doing MIA team housekeeping)

Bug#892313: O: bum -- graphical runlevel editor

Package: wnpp

The current maintainer of bum, Fabio Marzocca ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: bum
Binary: bum
Version: 2.5.2-1
Maintainer: Fabio Marzocca 
Uploaders: Federico Di Gregorio 
Build-Depends: debhelper (>= 5)
Build-Depends-Indep: libxml-parser-perl, libgtk2-perl (>= 1:1.100), intltool
Architecture: all
Standards-Version: 3.8.3
Format: 1.0
Files:
 3f8cb22f26da64f2797ce85759b77fb1 1089 bum_2.5.2-1.dsc
 f16e3fa5b8bc1fd3ada4a93226fc7cb9 229490 bum_2.5.2.orig.tar.gz
 09070cd220eaf122b3aa217948f111e5 2917 bum_2.5.2-1.diff.gz
Checksums-Sha1:
 8df3adff4e3f7929152f70188a8ee93fd0cd665c 1089 bum_2.5.2-1.dsc
 851c7edacc86aead4231385165c7ce33c2e7ae81 229490 bum_2.5.2.orig.tar.gz
 4b6ae3a1e3a43f292870d11a9bd1e9d3d7233d1a 2917 bum_2.5.2-1.diff.gz
Checksums-Sha256:
 6bee7034a048e18198b06b0e347fb1fb61f40b7dc186e5b92db4816f6854306b 1089 
bum_2.5.2-1.dsc
 366bb7b811ca93d9c1c862ce30a4629cf4e6db2f63b7ba6f87f8e07b1d09 229490 
bum_2.5.2.orig.tar.gz
 b259ecc43bf8eeb95955832210342766e151612b2f2c2997797768fb8f600735 2917 
bum_2.5.2-1.diff.gz
Homepage: http://www.marzocca.net/linux/bum.html
Directory: pool/main/b/bum
Priority: source
Section: admin

Package: bum
Binary: bum
Version: 2.5.2-1
Maintainer: Fabio Marzocca 
Uploaders: Federico Di Gregorio 
Build-Depends: debhelper (>= 5)
Build-Depends-Indep: libxml-parser-perl, libgtk2-perl (>= 1:1.100), intltool
Architecture: all
Standards-Version: 3.8.3
Format: 1.0
Files:
 3f8cb22f26da64f2797ce85759b77fb1 1089 bum_2.5.2-1.dsc
 f16e3fa5b8bc1fd3ada4a93226fc7cb9 229490 bum_2.5.2.orig.tar.gz
 09070cd220eaf122b3aa217948f111e5 2917 bum_2.5.2-1.diff.gz
Checksums-Sha256:
 6bee7034a048e18198b06b0e347fb1fb61f40b7dc186e5b92db4816f6854306b 1089 
bum_2.5.2-1.dsc
 366bb7b811ca93d9c1c862ce30a4629cf4e6db2f63b7ba6f87f8e07b1d09 229490 
bum_2.5.2.orig.tar.gz
 b259ecc43bf8eeb95955832210342766e151612b2f2c2997797768fb8f600735 2917 
bum_2.5.2-1.diff.gz
Homepage: http://www.marzocca.net/linux/bum.html
Directory: pool/main/b/bum
Priority: source
Section: admin

Package: bum
Version: 2.5.2-1
Installed-Size: 520
Maintainer: Fabio Marzocca 
Architecture: all
Depends: menu, sysv-rc, perl, libgtk2-perl (>= 1:1.100-1), libglib-perl (>= 
1:1.100-1), liblocale-gettext-perl
Conflicts: file-rc
Description-en: graphical runlevel editor
 Boot-Up Manager is a graphical tool to allow easy configuration
 of init services in user and system runlevels, as far as changing
 Start/Stop services priority.
Description-md5: 0f8b097911bac7d9bd24934ad91bfb00
Homepage: http://www.marzocca.net/linux/bum.html
Tag: admin::boot, admin::configuring, implemented-in::perl, interface::x11,
 role::program, scope::utility, uitoolkit::gtk, use::configuring,
 x11::application
Section: admin
Priority: optional
Filename: pool/main/b/bum/bum_2.5.2-1_all.deb
Size: 85122
MD5sum: b5c87c18099340949cbc38ae3401f0b9
SHA1: 0d3fd8bd876f449f880b03e683a3487fb656f422
SHA256: 3a3c246404a4e8c28a948aaa068165086983b9f01903f8d80d0702715c141871

Package: bum
Version: 2.5.2-1
Installed-Size: 520
Maintainer: Fabio Marzocca 
Architecture: all
Depends: menu, sysv-rc, perl, libgtk2-perl (>= 1:1.100-1), libglib-perl (>= 
1:1.100-1), liblocale-gettext-perl
Conflicts: file-rc
Description-en: graphical runlevel editor
 Boot-Up Manager is a graphical tool to allow easy configuration
 of init services in user and system runlevels, as far as changing
 Start/Stop services priority.
Description-md5: 0f8b097911bac7d9bd24934ad91bfb00
Homepage: http://www.marzocca.net/linux/bum.html
Tag: admin::boot, admin::configuring, implemented-in::perl, interface::x11,
 role::program, scope::utility, uitoolkit::gtk, use::configuring,
 x11::application
Section: admin
Priority: optional
Filename: pool/main/b/bum/bum_2.5.2-1_all.deb
Size: 85122
MD5sum: b5c87c18099340949cbc38ae3401f0b9
SHA1: 0d3fd8bd876f449f880b03e683a3487fb656f422
SHA256: 3a3c246404a4e8c28a948aaa068165086983b9f01903f8d80d0702715c141871

Bug#892285: [Pkg-pascal-devel] Bug#892285: Bug#892285: /usr/bin/fpcmake: fpcmake should find units in Debian without fiddling with FPCDIR

Hi Abou,

On 07-03-18 22:57, Abou Al Montacir wrote:
> On Wed, 2018-03-07 at 21:29 +0100, Paul Gevers wrote:
>> Lazarus is defining FPCDIR in its d/rules file to prevent this like:
>> FPCDIR=/usr/share/fpcsrc/${FPCVER}
>>
>> Transgui is/was doing it like:
>> FPCDIR=/usr/lib/fpc/${FPCDIR}
>>
>> I believe neither should be needed. Also, which one of the two is correct (or
>> better, if neither is really correct)?
> Probably none of them need to define FPCDIR.

Currently Lazarus FTBFS without it.¹

Paul

¹
http://debomatic-amd64.debian.net/distribution#unstable/lazarus/1.8.2+dfsg-4/buildlog



signature.asc
Description: OpenPGP digital signature

Bug#892279: fai-setup-storage gets BOOT_DEVICE wrong when /boot is in lvm-on-md

2018-03-07 Thread Matthew Vernon

package: fai-setup-storage
version: 5.5.3
X-Debbugs-CC: l...@sanger.ac.uk

Hi,

If you have a disk config like the below, with a single / partition
(i.e. no separate /boot) on LVM on md-raid, then BOOT_DEVICE is set
incorrectly, such that the fai GRUB setup scripts won't manage to
install GRUB correctly.

For example, in the below example, BOOT_DEVICE is set to
/dev/vg_fai/root ; while the example GRUB_PC/10-setup understands
devices like /dev/mdXX (and installs grub correctly on the underlying
devices), it doesn't understand LVM device names.

It seems to me that there are 3 possible solutions:

i) fai-setup-storage knows that / is on LVM, so should set BOOT_DEVICE
to the underlying pv (which GRUB_PC/10-setup would grok)

ii) fai-setup-storage's config file should be extended so you can
explicitly set boot_device (e.g. the below would have "rad1 -
disk1.1,disk2.1 - - BOOT_DEVICE)

iii) GRUB_PC/10-setup could spot an LVM BOOT_DEVICE and find the
underlying pv, e.g.

x=$(readlink -f $BOOT_DEVICE)
if [ "${x%%-*}" = "/dev/dm" ]; then
  BOOT_DEVICE=$( lvs --noheadings -o devices $BOOT_DEVICE | sed -e 's/^
*\([^(]*\)(.*$/\1/' )
fi

and then let the rest of the script do its thing as before. [if you'd
like a proper patch of this form, let me know :) ]

example disk config:

#

# Root partition with RAID and LVM, single root partition

disk_config disk1 disklabel:gpt-bios fstabkey:uuid align-at:1M bootable:1

primary - 120G- - -

disk_config disk2 sameas:disk1

disk_config raid fstabkey:uuid
raid1 - disk1.1,disk2.1  -  -

disk_config lvm fstabkey:uuid

vg vg_fai md0
vg_fai-root   /100G- ext3 errors=remount-ro
vg_fai-swap   swap 16G   swap sw

Thanks,

Matthew


-- 
 The Wellcome Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.

Bug#887967: [Pkg-pascal-devel] Bug#887967 closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)

2018-03-07 Thread Michalis Kamburelis

"2018-03-07 16:46 GMT+01:00 Graham Inggs :
> On Tue, 23 Jan 2018 08:46:09 +0200 Adrian Bunk  wrote:
>>
>> This problem is unfortunately still present with fpc 3.0.4+dfsg-14:
>>
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/transgui.html
>
>
> This can be worked around by the following change in debian/rules:
>
> -export FPCDIR=/usr/lib/fpc/${FPCDIR}
> +export FPCDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/fpc/default
>
> However, it was my understanding that this was supposed to be fixed in FPC,
> so forwarding to the Pascal list for comment.
>

The recent fix in the Debian package of FPC was for the FpMake build
system, http://wiki.freepascal.org/FPMake . It tries to auto-detect
the standard units location, but can be overridden by $FPCDIR
environment variable. The auto-detection was fixed in this case,
removing the need for $FPCDIR.

It seems that transgui is using an older "fpcmake" system (depending
on Makefile which is auto-generated based on "Makefile.fpc" contents).
The auto-detection is in a different place then, although it is also
overridden by $FPCDIR environment variable.

You can see how this works in case of transgui :

- This is the source file:
https://github.com/transmission-remote-gui/transgui/blob/master/Makefile.fpc
- And developer calls "fpcmake" to generate a Makefile like this:
https://github.com/transmission-remote-gui/transgui/blob/master/Makefile

Searching the generated Makefile, there is a line that tries to
auto-guess the FPC library location:
https://github.com/transmission-remote-gui/transgui/blob/master/Makefile#L226
. So possibly it can be fixed in FPC package in Debian too.

Regards,
Michalis

Bug#887967: [Pkg-pascal-devel] Bug#887967 closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)

Hi Graham,

On 07-03-18 16:46, Graham Inggs wrote:
> On Tue, 23 Jan 2018 08:46:09 +0200 Adrian Bunk  wrote:
>> This problem is unfortunately still present with fpc 3.0.4+dfsg-14:
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/transgui.html
>>
> 
> This can be worked around by the following change in debian/rules:
> 
> -export FPCDIR=/usr/lib/fpc/${FPCDIR}
> +export FPCDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/fpc/default
> 
> However, it was my understanding that this was supposed to be fixed in
> FPC, so forwarding to the Pascal list for comment.

No, FPC would fix the default behavior. When FPCDIR is defined in
debian/rules, it must match. I wonder, does building work without
defining FPCDIR at all?

Paul




signature.asc
Description: OpenPGP digital signature

Bug#892136: /usr/bin/loimpress: Libreoffice Impress sometimes silently deletes a slide from the presentation

2018-03-07 Thread Wojtek Zabolotny

On 07.03.2018 07:36, Rene Engelhard wrote:

On Tue, Mar 06, 2018 at 03:44:00PM +0100, Wojtek Zabolotny wrote:

On 06.03.2018 10:01, Rene Engelhard wrote:

tag 892136 + moreinfo
thanks
Would you also file the same bug if people using vi would do 1dd
or %y or so blindly in command mode and wondering whether 1 lines or your
file contents are gone?

No, however if deletion occurs during normal edition (scrolling, entering of
normal characters) it is obviously a reason to fill the bug report.

You yourself said:

"Probably certain user activity (a special dragging the slides in the
left
pannel, or using a special key sequence?) causes Impress to delete a
slide without any warning or confirmation request."

"special key sequence" is not the same as "entering of normal
characters", neither is "a special dragging" the same as scrolling.

Generally the problem occurs during normal editing. When I change the slides
order in the left pannel, or when I switch between moving slides and normal
editing in the main window.
Unfortunately, I can't recreate that behavior. Whenever I try to trigger the problem, and do strangest operations in the left pannel (e.g. dropping one slide on another, dragging the group of slides
etc.) nothing happens.

As soon as I start normal editing and focus on the work not on the GUI
operations, the problem randomly occurs.
If I detect it quickly enough, I can recover the slide with CTRL+Z. If I notice it after significant changes are done, the only workaround is to save the corrupted presentation in another file, then
recover the original presentation with CTRL+Z, and finally merge them both.

Regards,
Wojtek

--
Wojciech M Zabolotny, PhD
Institute of Electronic Systems
Faculty of Electronics and Information Technology
Warsaw University of Technology

Bug#890944: new packages should not receive emails before email alias is created

2018-03-07 Thread Raphael Hertzog

Hi,

On Tue, 06 Mar 2018, Thorsten Alteholz wrote:
> On Mon, 5 Mar 2018, Luca Falavigna wrote:
> > OK. Can you please indicate which header is used to reference the
> > source package when sending mails to dispatch@tracker.d.o?
> 
> does [1] make sense for this?
> [1] https://salsa.debian.org/ftp-team/dak/merge_requests/9

LGTM (but I don't know dak well enough)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#891855: fonts-monoid: installs no less than 4000 font files!