Bug#907297: breeze-gtk-theme: Breaks xfce4-notes (invalid string constant in "/usr/share/themes/Breeze/gtk-2.0/widgets/styles")

[Dmitry Smirnov]

Package: breeze-gtk-theme
Version: 5.13.4-1
Severity: normal
Control: affects -1 xfce4-notes

breeze-gtk-theme breaks xfce4-notes:


$ xfce4-notes
/usr/share/themes/Breeze/gtk-2.0/widgets/styles:7: error: invalid string 
constant "notebook", expected valid string constant
/usr/share/themes/Breeze/gtk-2.0/widgets/styles:2: error: invalid string 
constant "scrollbar", expected valid string constant
/usr/share/themes/Breeze/gtk-2.0/widgets/styles:4: error: invalid string 
constant "entry", expected valid string constant
/usr/share/themes/Breeze/gtk-2.0/widgets/styles:4: error: invalid string 
constant "entry", expected valid string constant
/usr/share/themes/Breeze/gtk-2.0/widgets/styles:1: error: invalid string 
constant "default", expected valid string constant
/usr/share/themes/Breeze/gtk-2.0/widgets/styles:1: error: invalid string 
constant "default", expected valid string constant
/usr/share/themes/Breeze/gtk-2.0/widgets/styles:8: error: invalid string 
constant "range", expected valid string constant
^C


I could only use xfce4-notes after uninstalling "breeze-gtk-theme"...

-- 
Regards,
 Dmitry Smirnov

---

Continuous effort - not strength or intelligence - is the key to unlocking
our potential.
-- Winston Churchill


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

Bug#907296: libjackson-json-java: homepage of jackson should now be https://github.com/FasterXML/jackson

[shirish शिरीष]

Package: libjackson-json-java
Version: 1.9.2-9
Severity: normal

Dear Maintainer,

The old homepage http://jackson.codehaus.org seems to be expired.
There is no domain name by that name anymore and even whois can't
find it while https://github.com/FasterXML/jackson seems to be the
home nowadays. It  seems that 1.x is in maintainance mode while 2.x
series is the one being developed but that's a seperate issue
altogether.

Look forward to at least seeing the homepage info. being changed.


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

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

Versions of packages libjackson-json-java depends on:
ii  libjoda-time-java   2.10-1
ii  libjsr311-api-java  1.1.1-1

libjackson-json-java recommends no packages.

Versions of packages libjackson-json-java suggests:
pn  libjackson-json-java-doc  

-- no debconf information


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

Bug#907295: RFS: scrcpy/1.3-1 [ITP]

[Yangfl]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: scrcpy
   Version : 1.3-1
   Upstream Author : Genymobile
 * URL : https://github.com/Genymobile/scrcpy
 * License : Apache-2.0
   Section : net

It builds those binary packages:

  scrcpy - Display and control your Android device
 scrcpy-apk - Display and control your Android device - server binary

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

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


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

  dget -x https://mentors.debian.net/debian/pool/main/s/scrcpy/scrcpy_1.3-1.dsc

More information about hello can be obtained from https://www.example.com.

Changes since the last upload:

  * Initial release (Closes: #893279)


Regards,
 Yangfl

Bug#906375: Tried new upstream version

[Andreas Tille]

Hi,

On Sun, Aug 26, 2018 at 01:22:21AM +0200, Emmanuel Bourg wrote:
> > [ERROR]   The project com.itextpdf:itextpdf:5.5.13 
> > (/build/libitext5-java-5.5.13/itext/pom.xml) has 1 error
> > [ERROR] Non-resolvable parent POM for com.itextpdf:itextpdf:5.5.13: 
> > Cannot access central (https://repo.maven.apache.org/maven2) in offline 
> > mode and the artifact com.itextpdf:itext-parent:pom:1.0.0 has not been 
> > downloaded from it before. and 'parent.relativePath' points at no local POM 
> > @ line 5, column 11 -> [Help 2]
> 
> Adding --no-parent for the root pom.xml in debian/libitext5-java.poms
> will probably help. The project now uses multiple Maven modules, they'll
> have to be listed in the file too.

That was the case even before:


https://salsa.debian.org/java-team/libitext5-java/blob/master/debian/libitext5-java.poms

Kind regards

   Andreas.
 

-- 
http://fam-tille.de

Bug#907026: cups-filters: filter failed on Ricoh MP 3554 SP after upgrading to 1.21.0-1

[Wenbin Lv]

Package: cups-filters
Version: 1.21.0-1
Followup-For: Bug #907026

This bug has been fixed upstream, more info at
https://github.com/OpenPrinting/cups-filters/issues/57

I tested the upstream patch and it works.

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

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

Versions of packages cups-filters depends on:
ii  bc 1.07.1-2+b1
ii  cups-filters-core-drivers  1.21.0-1
ii  ghostscript9.22~dfsg-2.1
ii  libc6  2.27-5
ii  libcups2   2.2.8-5
ii  libcupsfilters11.21.0-1
ii  libcupsimage2  2.2.8-5
ii  libfontconfig1 2.13.0-5
ii  libfontembed1  1.21.0-1
ii  libgcc11:8.2.0-4
ii  libqpdf21  8.2.1-1
ii  libstdc++6 8.2.0-4
ii  poppler-utils  0.63.0-2

Versions of packages cups-filters recommends:
ii  colord   1.3.3-2
ii  imagemagick  8:6.9.10.8+dfsg-1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.8+dfsg-1
ii  liblouisutdml-bin2.7.0-2+b3

Versions of packages cups-filters suggests:
pn  antiword   
pn  docx2txt   
ii  foomatic-db-compressed-ppds [foomatic-db]  20180604-1

-- no debconf information

Bug#907294: completions/dpkg: installing dctrl-tools breaks completion for held packages with -L/--listfiles

[Paul Wise]

Package: bash-completion
Version: 1:2.8-1
Severity: normal
File: /usr/share/bash-completion/completions/dpkg
Tags: patch

The completion for dpkg -L/--listfiles does not list held packages when
grep-status (from dctrl-tools) is installed. This is because the
grep-status _comp_dpkg_purgeable_packages cares about the dpkg package
selection states (install/hold/deinstall/purge) while the other version
only cares about the dpkg package states (installed/unpacked/etc).

There is a similar issue for the _comp_dpkg_installed_packages function.

The fix for this is quite simple, just remove install/deinstall from
the arguments to the -FStatus options.

$ dpkg --get-selections | grep ^una
unace   install
unarinstall
unattended-upgrades hold

$ dpkg --listfiles una
unace  unar   

$ dpkg -L una
unace  unar   

$ grep -A1 listfiles /usr/share/bash-completion/completions/dpkg
-L|-P|--listfiles|--purge)
COMPREPLY=( $( _comp_dpkg_purgeable_packages "$cur" ) )

$ grep -B1 -A8 ^_comp_dpkg_purgeable_packages 
/usr/share/bash-completion/completions/dpkg
_have grep-status && {
_comp_dpkg_purgeable_packages()
{
grep-status -P -e "^$1" -a -FStatus 'install ok installed' -o -FStatus 
'deinstall ok config-files' -n -s Package
}
} || {
_comp_dpkg_purgeable_packages()
{
command grep -A 1 "Package: $1" /var/lib/dpkg/status 2>/dev/null | \
command grep -B 1 -Ee "ok installed|half-installed|unpacked| \
half-configured|config-files" \
-Ee "^Essential: yes" | \
awk "/Package: $1/ { print \$2 }" 2>/dev/null
}
}

$ diff -u /usr/share/bash-completion/completions/dpkg*
--- /usr/share/bash-completion/completions/dpkg 2018-03-31 07:07:32.0 
+0800
+++ /usr/share/bash-completion/completions/dpkg.fixed   2018-08-26 
12:02:49.488857999 +0800
@@ -3,7 +3,7 @@
 _have grep-status && {
 _comp_dpkg_installed_packages()
 {
-grep-status -P -e "^$1" -a -FStatus 'install ok installed' -n -s Package
+grep-status -P -e "^$1" -a -FStatus 'ok installed' -n -s Package
 }
 } || {
 _comp_dpkg_installed_packages()
@@ -19,7 +19,7 @@
 _have grep-status && {
 _comp_dpkg_purgeable_packages()
 {
-grep-status -P -e "^$1" -a -FStatus 'install ok installed' -o -FStatus 
'deinstall ok config-files' -n -s Package
+grep-status -P -e "^$1" -a -FStatus 'ok installed' -o -FStatus 'ok 
config-files' -n -s Package
 }
 } || {
 _comp_dpkg_purgeable_packages()

-- 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.17.0-2-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#907292: Can't find package list on server

[Stuart Prescott]

Control: tags -1 + moreinfo unreproducible

> Running debootstrap fails because it tries to fetch the package list
> shown in /var/lib/apt/lists named binary-i386_Packages.  But there is no
> such file on the server.  Instead there are files: binary-i386_Packages.gz
> and binary-i386_Packages.xz but it doesn't look for them.  I've run strace
> on it.  Here's the command I gave and results:
> 
> debootstrap --variant=minbase --verbose stretch /minboot
> http://debian.usu.edu/debian

Running this same command works just fine here. 

If 'unxz' from xz-utils is found, then the .xz version is used; bunzip2 will 
similarly be tried (but isn't on the mirror) and then gunzip is searched for 
and the .gz file is used.

From debootstrap.log:

Resolving debian.usu.edu (debian.usu.edu)... 129.123.104.15
Connecting to debian.usu.edu (debian.usu.edu)|129.123.104.15|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7098644 (6.8M) [application/octet-stream]
Saving to: '«tmpdir»/mini/var/lib/apt/lists/partial/
debian.usu.edu_debian_dists_stretch_main_binary-amd64_Packages.xz'

And stracing: 

execve("/usr/bin/wget", ["wget", "-O", "/home/stuart/tmp/mini/var/lib/apt/
lists/partial/debian.usu.edu_debian_dists_stretch_main_binary-
i386_Packages.xz", 
"http://debian.usu.edu/debian/dists/stretch/main/binary-i386/by-hash/SHA256/
d07f5e29da93524d0956a1bc00581413e5560156c3350bc22560ee633fb29b3a"]

Removing xz-utils, strace shows:

execve("/usr/bin/wget", ["wget", "-O", "«tmpdir»/mini/var/lib/apt/lists/
partial/debian.usu.edu_debian_dists_stretch_main_binary-amd64_Packages.gz", 
"http://debian.usu.edu/debian/dists/stretch/main/binary-amd64/by-hash/
SHA256/9e7870c3c3b5b0a7f8322c323a3fa641193b1eee792ee7e2eedb6eeebf9969f3"]

(tested against both i386 and amd64)

> debootstrap needs to find one of the compressed files. download it, and
> unconpress it.  But it doesn't.

That is what is supposed to happen (and does for me). Is it possible that you 
somehow do not have unxz and gunzip available in PATH? 

I see that you've created this bug report without using reportbug and from 
what looks like a non-Debian system -- is the version against which you have 
reported this bug incorrect? Is there additional information you can provide?

Cheers
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#907293: stops: Please consider making another upload and refreshing package

[Boyuan Yang]

Package: stops
Severity: wishlist
X-Debbugs-CC: fr...@debian.org

Dear stops maintainer (Hi Free Ekanayaka),

I was cleaning up packages that hasn't receive any upload in Debian for a long 
time and noticed that your package, stops, received no upload since 2007, 
which is quite a long period of time.

Making uploads to stops might be necessary according to [1] since we want to 
make Debian 100% reproducible in the future [2] and all packages built before 
December 2016 will need a rebuild. Meanwhile, It is unsure whether you are 
still actively maintaining this package and is willing to maintain it in the 
future after so many years. Besides, this package is using ancient packaging 
instructions (debhelper compat v5) and that needs refreshing.

As a result, I am wondering if you could make another upload for package stops 
recently, ideally before the Buster freeze. Since it hasn't receive any upload 
for 11 years, I am also considering initiating the MIA procedure[3] (targeting 
package only, not to the person because I know you look still active) if 
there's no reply after certain period of time (e.g., 60 days).

Thank you very much for your attention and understanding,

--
Best Regards,
Boyuan Yang


[1] https://lists.debian.org/debian-devel/2018/05/msg00499.html
[2] https://reproducible-builds.org/
[3] https://wiki.debian.org/Teams/MIA

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

Bug#906617: autopkgtest: Please consider defining directory environment variables

[Paul Hardy]

Paul,

First of all, I would like to say that I know that Martin has file an
RFH for autopkgtest because he no longer has the time he used to have
for its maintenance, so I sincerely appreciate the detailed reply that
he sent to me.

On Sat, Aug 25, 2018 at 1:06 PM Paul Gevers  wrote:
>
> Hi Paul,
>
> On 25-08-18 03:02, Paul Hardy wrote:
> ...
> Patches to the documentation are always welcome, especially to cover
> blind spots in our minds, even if only to get us in the right direction
> of what you are really looking for. However, as Martin already
> mentioned, try to do this not too specific for make as there are so many
> other frameworks.

I would have already done that, but felt anything I wrote would have
been conjecture.  My stumbling block is that I do not understand all
the virtual runtime environments that autopkgtest supports.

I can suggest additional text as a patch here, re-opening the bug (I
didn't want to do that before).  Then you can accept or reject the
text I suggest, and close the bug again.

> Also, I am trying to collect these kind of things and related stuff
> (which may be framework specific) here:
> https://wiki.debian.org/ContinuousIntegration/AutopkgtestBestPractices
> Feel free to add your remarks there.

I will be glad to do that once I think I have my facts straight.  In
the meantime though, with my less than perfect autopkgtest
understanding, I will load experimental packages and make sure the CI
stuff works first.

Thank you,


Paul Hardy

Bug#907292: Can't find package list on server

[David Lawyer]

Package: debootstrap
Version: 1.0.108

Running debootstrap fails because it tries to fetch the package list
shown in /var/lib/apt/lists named binary-i386_Packages.  But there is no
such file on the server.  Instead there are files: binary-i386_Packages.gz
and binary-i386_Packages.xz but it doesn't look for them.  I've run strace
on it.  Here's the command I gave and results:

debootstrap --variant=minbase --verbose stretch /minboot 
http://debian.usu.edu/debian

I: Retrieving InRelease 
I: Checking Release signature
I: Valid Release signature (key id 067E3C456BAE240ACEE88F6FEF0F382A1A7B6500)
I: Retrieving Packages 
E: Couldn't download 
http://debian.usu.edu/debian/dists/stretch/main/binary-i386/Packages

debootstrap needs to find one of the compressed files. download it, and
unconpress it.  But it doesn't.
David Lawyer

Bug#906963: keyword subscription does not always work

[Raphael Hertzog]

On Sun, 26 Aug 2018, Raphael Hertzog wrote:
> Are you observing the same thing?

I identified the problem. It's in the javascript, the code
is badly using jquery to find out the list of keywords. I have
a fix locally but I want to polish it further before releasing
it and I'd like to add a non-regression test because it's not
the first time we break it without noticing.

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#907291: ITP: libnativecall-perl -- Perl 5 interface to foreign functions in Perl code without XS

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libnativecall-perl
  Version : 0.006
  Upstream Author : Ed J 
* URL : https://metacpan.org/release/NativeCall
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl 5 interface to foreign functions in Perl code without 
XS

The NativeCall module calls into dynamic libraries that follow the C calling
convention in order to write simple library bindings.

It mimics the NativeCall module and interface from Perl 6.

Under the hood, it uses FFI::Platypus, inheritance and attributes.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#907290: propellor: Apt.trustsKey should not call apt-key

[David Bremner]

Package: propellor
Version: 5.3.6-1
Severity: normal

Prior to upstream commit 1d39a530, Propellor did something like

(proc "gpg" ["--no-default-keyring", "--keyring", f, "--import", "-"])

which created a a gpg keyring, and the format of those changed at some
point to something that apt-key does not support. To fix this breakage
Propeller switched to calling apt-key add, which works, for now, but
it complains, and will probably break at some point.

According to the apt-key manpage

 "Instead of using this [add] command a keyring should be placed
   directly in the /etc/apt/trusted.gpg.d/ directory with a
   descriptive name and either "gpg" or "asc" as file extension."

As far as I can tell, if the privdata is in the right format (which is
always an issue with propellor), no call to gpg should be necessary,
and trustsKey could be implimented e.g. with File.hasPrivContent.

The documentation / --set hints should probably be updated to
recommend gpg --export, since (again from the apt-key manpage)

 "Binary keyring files intended to be used with any apt version should
  therefore always be created with gpg --export."

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

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

Versions of packages propellor depends on:
ii  cabal-install  2.0.0.1-1
ii  ghc [libghc-transformers-dev]  8.2.2-4
ii  git1:2.18.0-1
ii  libc6  2.27-5
ii  libffi63.2.1-8
ii  libghc-ansi-terminal-dev   0.8.0.2-1
ii  libghc-async-dev   2.1.1.1-2
ii  libghc-exceptions-dev  0.8.3-8
ii  libghc-hashable-dev1.2.7.0-2
ii  libghc-hslogger-dev1.2.10+dfsg-4
ii  libghc-ifelse-dev  0.85-14
ii  libghc-mtl-dev 2.2.2-1
ii  libghc-network-dev 2.6.3.5-1
ii  libghc-propellor-dev   5.3.6-1
ii  libghc-split-dev   0.2.3.3-1
ii  libghc-stm-dev 2.4.5.0-1
ii  libghc-text-dev1.2.3.0-1
ii  libghc-unix-compat-dev 0.5.0.1-1
ii  libgmp10   2:6.1.2+dfsg-3

propellor recommends no packages.

propellor suggests no packages.

-- no debconf information

Bug#907289: [uscan] manpage should explain default behaviour if version/script not specified

[Julian Gilbey]

Package: devscripts
Version: 2.18.3
Severity: normal

The manpage for uscan says that version and script are optional in the
watchfile lines; it should also say that "debian" is the default
behaviour for "version" and that "no action" is the default behaviour
if no script is specified.

Best wishes,

   Julian

Bug#893995: Include searchable provides data alongside binaries in tracker

[Pirate Praveen]

On 2018, ഓഗസ്റ്റ് 26 5:06:52 AM IST, Raphael Hertzog  wrote:
>Hi,
>
>On Sun, 25 Mar 2018, Pirate Praveen wrote:
>> Currently provides data is missing from tracker.Debian.org
>> 
>> For example ruby-flipper provides ruby-flipper-active-record but this
>> information is missing currently from tracker.Debian.org
>
>Can you be more specific in your request?
>
>provides is data about a binary package and the tracker is centered
>around source package.
>
>Do you mean that provided packages should be considered when you search
>for a package?

Yes, this one.

tracker.debian.org/ruby-flipper-activerecord (or enter 
ruby-flipper-activerecord in search box) should redirect to 
tracker.debian.org/ruby-flipper.


>Or do you want to display this information somewhere?

Optionally, along with list of binary packages.

>Cheers,

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

Bug#907158: mpi-testsuite: FTBFS in buster/sid (ln: failed to create symbolic link)

[Santiago Vila]

On Sun, Aug 26, 2018 at 12:24:35AM +0300, Adrian Bunk wrote:
> Control: severity -1 important
> 
> On Fri, Aug 24, 2018 at 11:03:54AM +, Santiago Vila wrote:
> >...
> > for i in `find . -name "testlist" | grep -v ^..build`;  \
> > do  \
> >   if [ ! -e build-openmpi/$i ]; \
> >   then  \
> > ln -s `pwd`/$i `pwd`/build-openmpi/$i;  \
> >   fi;   \
> > done

Hmm, you say that the error message "failed to create symbolic link" is
"normal" in builds which do not fail.

Could it be that in those cases the failing "ln" command is just not
the last "ln" command in the for loop?

The fact that the output of "find" does not have a well defined order
would explain that it fails or not in a random fashion.

I think this is a violation of Policy 4.6, "Error trapping in makefiles".
(which would be "serious" again).

Thanks.

Bug#906963: keyword subscription does not always work

[Raphael Hertzog]

Control: severity -1 important

Hi,

On Wed, 22 Aug 2018, Marc Haber wrote:
> I would like to get the vcs messages, so I click on "Modify Keywords",
> and am surprised that everything is ticket there. Regardless on which
> change I make here, after clicking on "Save changes", nothing changes,
> neither in the overview view nor in the "Choose keywords" dialog.
> 
> Is this broken, or am I doing things wrong?

Do you have multiple emails configured in your account?

I do have two emails configured. For the packages subscribed to the first
email appearing on https://tracker.debian.org/accounts/subscriptions/
the "modify keyword" button seems to show the correct set of keywords.

But for the second email, it effectively looks likes that the checked
keywords do not match the real keywords.

However in both cases, clicking the "Save changes" button does modify
the associated keywords, they are however not refreshed in the current
page. You have to reload the entire page to see the change.

Are you observing the same thing?

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#907275: RFS: debian-timeline/39+nmu1

[Adam Borowski]

On Sat, Aug 25, 2018 at 09:11:51PM +0200, Birger Schacht wrote:
> There was a short discussion about the status of the `debian-timeline`
> package on the debian-publicity list [0], so i figured i could take a
> look and upload a current version of the package. I'm not sure if it
> really should be a NMU, but i'm happy to fix that if thats not adequate.

I don't believe this package should be NMUed (other than for a technical RC
bug or such).  On the other hand, marking it as a "Team upload" would be
very appropriate.

I'm not aware whether the Debian-Publicity team keeps a formal list of
members, but if there's one, you may consider getting onto it.  Many teams
use Salsa permissions as a technical implementation of such a list.

(Responding with a -mentors hat on, I'm not involved in any way with the
Publicity team.  Heck, I'm the kind of guy whose workmates don't let talk
to any customers. :p)

> [0] https://lists.debian.org/debian-publicity/2018/08/msg00019.html

Larjona: IIRC because of a prior issue when someone was both a DM and a DN,
and some tool not being able to handle a person being in two keyrings, DAK
got hacked to make DN imply DM rights.  Thus, if I'm correct, there's no
need to implement any special handling.  So you have no excuse for not
updating the package as often as you'd like.  :)

> I am looking for a sponsor for my package "debian-timeline"
> 
>  * Package name: debian-timeline
>Version : 39+nmu1

> Changes since the last upload:
>   * Non-maintainer upload.
> 
>   [Cédric Boutillier]
>   * Publication of Debian 8.10 and 9.3
> 
>   [Jean-Pierre Giraud]
>   * Git repo is now in salsa
> 
>   [Chris Lamb]
>   * Move under the care of the Publicity Team
> 
>   [Donald Norwood]
>   * Publication of Debian 8.11
> 
>   [Ana Guerrero López]
>   * Add DebConf 18
>   * Add `make mpublish` command
> 
>   [Laura Arjona Reina]
>   * Remove Chris Lamb from uploaders
> 
>   [Birger Schacht]
>   * Bump standards version
>   * add Mini-DebConf Hamburg

With so many contributors to the package, it's definitely not something for
a random sponsor to review/upload.  Thus, a RFS for it should go through
some other channels.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17]
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]

Bug#893995: Include searchable provides data alongside binaries in tracker

[Raphael Hertzog]

Hi,

On Sun, 25 Mar 2018, Pirate Praveen wrote:
> Currently provides data is missing from tracker.Debian.org
> 
> For example ruby-flipper provides ruby-flipper-active-record but this
> information is missing currently from tracker.Debian.org

Can you be more specific in your request?

provides is data about a binary package and the tracker is centered
around source package.

Do you mean that provided packages should be considered when you search
for a package?

Or do you want to display this information somewhere?

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#906375: Tried new upstream version

[Emmanuel Bourg]

On 25/08/2018 17:44, Andreas Tille wrote:

> No, it is different:
> [ERROR]   The project com.itextpdf:itextpdf:5.5.13 
> (/build/libitext5-java-5.5.13/itext/pom.xml) has 1 error
> [ERROR] Non-resolvable parent POM for com.itextpdf:itextpdf:5.5.13: 
> Cannot access central (https://repo.maven.apache.org/maven2) in offline mode 
> and the artifact com.itextpdf:itext-parent:pom:1.0.0 has not been downloaded 
> from it before. and 'parent.relativePath' points at no local POM @ line 5, 
> column 11 -> [Help 2]

Adding --no-parent for the root pom.xml in debian/libitext5-java.poms
will probably help. The project now uses multiple Maven modules, they'll
have to be listed in the file too.

Bug#842683: OVMF 32-bit build also needed here

[Josh Triplett]

I'd like to have the 32-bit build of OVMF as well, to make it possible
to test both 32-bit and 64-bit UEFI using KVM.

Bug#907288: isc-dhcp-server: Package use "ps" command in the startup script, but "procps" is not a dependency of the package

[BhEaN]

Package: isc-dhcp-server
Severity: normal
Tags: upstream

Hi,

I notice that isc-dhcp-server startup script (/etc/init.d/isc-dhcp-server) use
the "ps" command to confim if the daemon is running, but "ps" command is
provided by "procps" package, which is NOT a dependency of isc-dhcp-server.

If you try to install isc-dhcp-server in a server without "procps" package
(debian-min in Docker, for example) you always get an error when you try to
start the daemon, even if the service is started successfully.

Just add the "procps" to the package dependency should be work.

Thank you vey much, and regards from Spain!



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

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

Versions of packages isc-dhcp-server depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  debianutils4.8.6
ii  libc6  2.27-5
ii  libdns-export1102  1:9.11.4+dfsg-4
pn  libirs-export160   
ii  libisc-export169   1:9.11.4+dfsg-4
ii  lsb-base   9.20170808

Versions of packages isc-dhcp-server recommends:
ii  isc-dhcp-common  4.3.5-4+b1
pn  policycoreutils  

Versions of packages isc-dhcp-server suggests:
pn  isc-dhcp-server-ldap  
ii  policykit-1   0.105-21

Bug#906827: debhelper: distinction between news and changelog

[Peter Pentchev]

On Tue, Aug 21, 2018 at 03:59:36PM +, David Miguel Susano Pinto wrote:
> Package: debhelper
> Version: 11.3.5
> Severity: normal
> 
> Debian policy version 4.2.0 added the following change (excerpt from
> the Upgrade checklist):
> 
> Upstream release notes, when available, should be installed as
> /usr/share/doc/package/NEWS.gz. Upstream changelogs may be made
> available as /usr/share/doc/package/changelog.gz.
> 
> which seems to have steamed from the discussion in Debian bug #459427.
> 
[snip]
> I'm unsure the best way to address this issue with my short experience
> as packager.  My suggestion would be to look for files named:
> 
>   1 news
>   2 history
>   3 changes
>   4 changelog
> 
> in that order.  The first file found becomes the NEWS file and the
> second becomes the changelog.  This assumes that if there is only one
> of them, it will be a release notes type of file, while still enabling
> the two types.
> 
> I have taken a quick look at the source of dh_installchangelogs and
> this seems a doable change.

Hmm, dh_installchangelogs already looks for files with various names
when looking for an upstream changelog, and I've actually had many
different names for those in the packages I maintain (*.txt, *.md, no
extension at all, *wild* variations in capitalization, not to mention
the base name - changes, changelog, release-notes, news...).

I wonder if it might be a good idea to implement David's suggestion, but
with a slight twist: allow the autodetection of the "upstream release
notes" file (as opposed to "upstream changelog") to be overridden,
possibly in several ways, in order of increasing precedence:
- the standard dh_installchangelogs list of names to search, modified as
  per David's suggestion: the first one found is NEWS, the next one is
  changelog
- something specified by the debhelper build system module
- something specified in a debian/* file, e.g.  debian/pkgname.notes or
  something, not sure what would be a good name
- something specified on the dh_installchangelogs command line, e.g. by
  a new command-line option

This would cover several cases:
- for many packages, no change in the package itself would DTRT as per
  David's suggestion
- for some build systems, e.g. the ones related to Perl modules,
  debhelper's build system code would say "Changes goes to NEWS, no
  changelog by default"
- for some software groups, the Debian maintainers will be able to do
  a small packaging change: add a single-line debian/pkgname.something
  file instead of modifying the rules file
- for the outliers, there would be a way for the package maintainer to
  specify the weird filename for the upstream release notes file as
  a command-line option to dh_installchangelogs

So what do people think?

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#907287: linuxinfo: Reports "Intel Unknown […] processors" for "Intel(R) Core(TM) i7-6700T CPU" and others

[Axel Beckert]

Package: linuxinfo
Version: 3.1.0-1

Hi Helge,

as requested in the recent NEWS.Debian.gz entry:

→ linuxinfo
Linux c6 4.17.0-1-amd64 #1 SMP Debian 4.17.3-1 (2018-07-02)
Eight Intel Unknown 3510MHz processors, 44928.00 total bogomips, 64100M RAM
System library 2.27.0
→ fgrep "model name" /proc/cpuinfo
model name  : Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz
model name  : Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz
model name  : Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz
model name  : Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz
model name  : Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz
model name  : Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz
model name  : Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz

This is the machine on which this bug report has been written.

I have another machine, also Sid amd64, but a VM, to be more precise a
Xen DomU, where this happens:

→ linuxinfo
Linux kote1 4.14.0-3-amd64 #1 SMP Debian 4.14.12-2 (2018-01-06)
Four Intel Unknown 2294MHz processors, 18357.64 total bogomips, 6004M RAM
System library 2.27.0
→ fgrep "model name" /proc/cpuinfo
model name  : Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
model name  : Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
model name  : Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
model name  : Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz

(The CPU model in /proc/cpuinfo seems the host's CPU model.)

Also installed 3.1.0-1 manually on an Buster amd64 machine with an AMD
CPU:

% linuxinfo
Linux relay 4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29)
Four AMD Unknown 3393MHz processors, 16766.64 total bogomips, 15502M RAM
System library 2.27.0
% fgrep "model name" /proc/cpuinfo
model name  : AMD Opteron(tm) X3421 APU
model name  : AMD Opteron(tm) X3421 APU
model name  : AMD Opteron(tm) X3421 APU
model name  : AMD Opteron(tm) X3421 APU

And some Sid i386 cases:

[ASUS EeePC 900A]

→ linuxinfo
Linux nemo2 4.17.0-3-686-pae #1 SMP Debian 4.17.17-1 (2018-08-18)
Two Intel Unknown 1595MHz processors, 6383.96 total bogomips, 2008M RAM
System library 2.27.0
→ fgrep "model name" /proc/cpuinfo
model name  : Intel(R) Atom(TM) CPU N270   @ 1.60GHz
model name  : Intel(R) Atom(TM) CPU N270   @ 1.60GHz

[Thinkpad A31 with German locales]

→ linuxinfo
Linux loadrunner 4.17.0-1-686-pae #1 SMP Debian 4.17.6-2 (2018-07-15)
Ein Intel Unknown 1800MHz Prozessor, 3596.71 Bogomips gesamt, 1001 MB RAM
Systembibliothek 2.27.0
→ fgrep "model name" /proc/cpuinfo
model name  : Intel(R) Pentium(R) 4 Mobile CPU 1.80GHz

So bascially all x86 machines I ran it on showed "Unknown". So I suspect
this might be a more general issue than just some cases not being
caught.

-- Package-specific info:
/proc/cpuinfo:
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 94
model name  : Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz
stepping: 3
microcode   : 0xc2
cpu MHz : 3428.722
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 22
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl 
vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe 
popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb invpcid_single pti ibrs ibpb stibp tpr_shadow vnmi flexpriority 
ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx 
rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida 
arat pln pts hwp hwp_notify hwp_act_window hwp_epp
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
bogomips: 5616.00
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 94
model name  : Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz
stepping: 3
microcode   : 0xc2
cpu MHz : 3400.159
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 1
cpu cores   : 4
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 22
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl 
vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe 
popcnt 

Bug#906384: lucene-solr: FTBFS in buster/sid

[Markus Koschany]

Am 25.08.2018 um 23:27 schrieb Markus Koschany:
> Control: tags -1 pending
> 
> The FTBFS was caused by the latest upgrade of libwoodstox-java. The jar
> files were renamed and could not be found anymore.
> 
> I am quite sure this is related to #904063 somehow. Once #906447 is
> resolved I could try to verify this assumption.

Ok, I forgot to install OpenJDK 10 on this system hence I got hit by
#906447 too. I can confirm now that the libwoodstox-java upgrade caused
the build failure and the runtime error. I am going to upload the fix
shortly.

Markus




signature.asc
Description: OpenPGP digital signature

Bug#868724: debian/watch file for the ledgersmb package

[Robert James Clay]

On Thu, Aug 2, 2018 at 8:21 PM Robert James Clay  wrote:   

On Thu, Aug 2, 2018 at 1:58 PM Shengjing Zhu  wrote:   

>> And I think using upstream http release page is much simpler for you.  

> I'm inclined to agree and will look at using that site instead.  

  In testing with using the downloads.legdersmb.org site instead of the
github.com/ledgersmb/LedgerSMB site, it was able to both find the new or
current upstream version as well as automatically test the pgp signature
check.  So the next step will be to update it for the ds repack (not just
rename) and see how that works.  

   

Robert James Clay, j...@rocasa.us  

   

 

Bug#906447: tomcat8: Errors thrown when connecting

[Markus Koschany]

On Fri, 17 Aug 2018 20:50:14 +0300 Vassilis Virvilis 
wrote:
[...]
> With java8 installed I am getting the following. Isn't this the sign that is 
> compiled again against java9/java10?
> 
> 2018-08-17 16:20:46] [crit] java.lang.NoSuchMethodError: 
> java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer;

I believe we should tighten the dependency on default-jre-headless. We
currently have for tomcat8-common:

default-jre-headless | java8-runtime-headless | java8-runtime

We should simply change that to

default-jre-headless (>= 10) | java10-runtime-headless | java10-runtime


Tomcat 8 works with the current default-jre package but you must
manually install a Java 10 runtime at the moment since the dependency is
satisfied with Java 8. Just switch to OpenJDK 10 with the
update-alternatives mechanism and the error will go away.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#907286: ITP: python-xstatic-angular-vis -- Angular Vis XStatic support

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-xstatic-angular-vis
  Version : 4.16.0.0
  Upstream Author : Chris Jackson
* URL : https://github.com/openstack/xstatic-angular-vis
* License : Expat
  Programming Lang: Python, JS
  Description : Angular Vis XStatic support

 XStatic is a Python web development tool for handling required static data
 files from external projects, such as CSS, images, and JavaScript. It provides
 a lightweight infrastructure to manage them via Python modules that your app
 can depend on in a portable, virtualenv-friendly way instead of using embedded
 copies.
 .
 Angular-vis provides AngularJS directive for VisJS.
 .
 VisJS is a dynamic, browser based visualization library. The library is
 designed to be easy to use, to handle large amounts of dynamic data, and to
 enable manipulation of and interaction with the data. The library consists of
 the components DataSet, Timeline, Network, Graph2d and Graph3d. See visjs.org.

Note: This is a new dependency of heat-dahsboard (ie: OpenStack stuff...)

Bug#906384: lucene-solr: FTBFS in buster/sid

[Markus Koschany]

Control: tags -1 pending

The FTBFS was caused by the latest upgrade of libwoodstox-java. The jar
files were renamed and could not be found anymore.

I am quite sure this is related to #904063 somehow. Once #906447 is
resolved I could try to verify this assumption.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#907158: mpi-testsuite: FTBFS in buster/sid (ln: failed to create symbolic link)

[Adrian Bunk]

Control: severity -1 important

On Fri, Aug 24, 2018 at 11:03:54AM +, Santiago Vila wrote:
>...
> for i in `find . -name "testlist" | grep -v ^..build`;\
> do\
>   if [ ! -e build-openmpi/$i ];   \
>   then\
> ln -s `pwd`/$i `pwd`/build-openmpi/$i;\
>   fi; \
> done
> ln: failed to create symbolic link 
> '/<>/mpi-testsuite-3.2+dfsg/build-openmpi/./.pc/disable_large_tests.patch/group/testlist':
>  No such file or directory
> make[1]: *** [debian/rules:16: override_dh_auto_configure] Error 1
> make[1]: Leaving directory '/<>/mpi-testsuite-3.2+dfsg'
> make: *** [debian/rules:7: build-arch] Error 2
> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
> status 2
> 
> 
> I don't know why it does not fail in the same way in reproducible builds,
> but it is easy to see why it fails for me: The find command is finding
> things inside the .pc directory used by quilt and friends. I would do
> something like "find *" instead, if that's enough for the intended purpose.

This message is "normal", it is even in the arm64 build that just 
succeeded on a buildd.

I don't know what actually causes your build failure,
but this does not seem to be a problem on the buildds.

> Thanks.

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#907285: ITP: python-xstatic-angular-uuid -- Angular UUID XStatic support

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-xstatic-angular-uuid
  Version : 0.0.4.0
  Upstream Author : Ivan Hayes
* URL : https://github.com/openstack/xstatic-angular-uuid
* License : Expat
  Programming Lang: Python
  Description : Angular UUID XStatic support

 XStatic is a Python web development tool for handling required static data
 files from external projects, such as CSS, images, and JavaScript. It provides
 a lightweight infrastructure to manage them via Python modules that your app
 can depend on in a portable, virtualenv-friendly way instead of using embedded
 copies.
 .
 Angular-uuid is an AngularJS wrapper for Robert Kieffer's node-uuid, which
 provides simple, fast generation of RFC4122 UUIDS. It features:
 .
  * AngularJS service – no global scope pollution
  * Generate RFC4122 version 1 or version 4 UUIDs
  * Cryptographically strong random num generation on supporting platforms
  * Tiny file size when minified.

Note: this is a new dependency of heat-dashboard

Bug#907283: ITP: python-asteval -- minimalistic evaluator of Python 3 expression using ast module

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: python-asteval
  Version : 0.9.12
  Upstream Author : Matthew Newville 
* URL : https://github.com/newville/asteval
* License : MIT
  Programming Lang: Python
  Description : minimalistic evaluator of Python 3 expression using ast 
module
 ASTEVAL is a safe(ish) evaluator of Python expressions and statements,
 using Python's ast module. The idea is to provide a simple, safe, and
 robust miniature mathematical language that can handle user-input. The
 emphasis here is on mathematical expressions, and so many functions from
 numpy are imported and used if available.
 .
 Many Python lanquage constructs are supported by default, These include
 slicing, subscripting, list comprehension, conditionals (if-elif-else
 blocks and if expressions), flow control (for loops, while loops, and
 try-except-finally blocks). All data are Python objects, and built-in
 data structures (dictionaries, tuple, lists, numpy arrays, strings) are
 fully supported by default.
 .
 Many of the standard builtin Python functions are available, as are all
 mathemetical functions from the math module. If the numpy module is
 installed, many of its functions will also be available. Users can
 define and run their own functions within the confines of the
 limitations of asteval.
 .
 There are several absences and differences with Python, and asteval is
 by no means an attempt to reproduce Python with its own ast module. Some
 of the most important differences and absences are:
 .
   * Variable and function symbol names are held in a simple symbol table
 (a single dictionary), giving a flat namespace.
   * creating classes is not supported.
   * importing modules is not supported.
   * function decorators, yield, lambda, exec, and eval are not
 supported.
   * files can only be opened in read-only mode.
 .
 In addition, accessing many internal methods and classes of objects is
 forbidden in order to strengthen asteval against malicious user code. .

Remark: This package is maintained by Debian Science Maintainers at
   https://salsa.debian.org/science-team/python-asteval
This package is needed for the latest version of lmfit-py which needs
both Python 2 and Python 3 module.

Bug#905088: RFP: tld -- TLD lookup tool for Emacs

[Nicholas D Steeves]

clone 905088 -1
reassign -1 wnpp
retitle -1 RFP: tld -- TLD lookup tool for Emacs
severity -1 wishlist
user pkg-emacsen-add...@lists.alioth.debian.org
usertags -1 elpafy
--

On Tue, Jul 31, 2018 at 03:39:00PM +0800, David Bremner wrote:
> Package: emacs-goodies-el
> Version: 39.0
> Severity: normal
[...]
> The following have some (small?) extended functioniality, and a live
> upstream, so maybe someone (TM) wants to package them
> 
> - [ ] tld.el

Homepage: https://github.com/davep/tld.el
License: GPL-2
Copyright: 2000  Dave Pearson 
Description: TLD lookup tool for Emacs

This package will be dropped from emacs-goodies-el in the next upload.
If someone wants to package it, please use dh-elpa, and please CC
pkg-emacsen-add...@lists.alioth.debian.org so that we can add the
dependency to emacs-goodies-el so that users will have a smooth
transition.

Thanks,
Nicholas


signature.asc
Description: PGP signature

Bug#907276: lintian should give an error on Multi-Arch: same packages calling py{,3}compile in maintainer scripts

[Adrian Bunk]

On Sat, Aug 25, 2018 at 08:58:36PM +0100, Chris Lamb wrote:
> Hi Adrian,
> 
> > #889053 is an example why Multi-Arch: same packages
> > calling py{,3}compile in maintainer scripts is a
> > broken situation.
> > 
> > More background is in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812228#36
> 
> Thanks.
> 
> Can you provide some example text for the description? Happy to rework
> an initial draft, but getting the background from someone definitely
> "in the know" about the issue whilst it is fresh in their mind would be
> ideal.

pycompile and py3compile do not support installing several architectures 
of the same package.

If the contents of the package is not architecture-dependent,
it should usually be made binary-all.

If the contents of the package is architecture-dependent,
it should usually get a dependency on the python interpreter
for the same architecture.
Since installing multiple architecture versions of the
same python interpreter is not allowed, this makes the
Multi-Arch: same not have any effect.

<--  snip  -->


The above test uses "usually" to express that there can be special cases 
like gir1.2-ibus-1.0 that might end up being handled differently.

pycompile/py3compile with Multi-Arch: same is fatal in any case.


> Regards,

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#907282: Package should recommend fonts-hack instead of fonts-hack-ttf

[Thomas Viehweger]

Package: lxqt-common
Version: 0.11.2-2

The description of fonts-hack-ttf says:
This package used to contain the TTF variants of the Hack font, which
are now part of the consolidated fonts-hack package.
This package is a dummy transitional package. It can be safely removed.

Please update the Recommends field.

Bug#906505: qlandkartegt: FTBFS in buster/sid (unable to find string literal operator)

[Sebastiaan Couwenberg]

Control: tags -1 wontfix

On 8/25/18 7:45 PM, Christoph Biedl wrote:
> Christoph, who'd like to have a usable qlandkartegt in Debian - how is 
> QMapShack supposed to be a replacement?

Upstream stopped developing QLGT and switches his attention to QMS.

You will have to take over maintenance of qlandkartegt if you want to
keep it in Debian, but the package and upstream development. As long as
there is no one actively working on QLGT upstream the fate of the
package is sealed.

No one in the Debian GIS team is willing to maintain this EOL package
any longer, qmapshack is were we invest our effort.

Kind Regards,

Bas



signature.asc
Description: OpenPGP digital signature

Bug#907281: Package should recommend fonts-hack instead of fonts-hack-ttf

[Thomas Viehweger]

Package: plasma-desktop
Version: 4:5.13.4-1

The description of fonts-hack-ttf says:
This package used to contain the TTF variants of the Hack font, which
are now part of the consolidated fonts-hack package.
This package is a dummy transitional package. It can be safely removed.

Please update the Recommends field.

Bug#906284: CC0 is short

[Julian Gilbey]

On Sat, Aug 25, 2018 at 10:32:55AM +0200, Julien Puydt wrote:
> Hi,
> 
> the following also triggers the check, and I think it's a false positive,
> and would still be even with the proposed change:
> 
> License: CC0

Indeed - good catch.  We have to treat CC0 differently, as it's got
different license wording and it also appears in
/usr/share/common-licenses.  How about the following then:

if ($full_license and $short_license =~ m/cc-/) {
if ($full_license !~ /definitions/i and
$full_license !~ /copyright and related rights/i and
$full_license !~ m%/usr/share/common-licenses/CC) {
tag 'incomplete-creative-commons-license';
}
}

Best wishes,

   Julian

Bug#907280: Package should recommend fonts-hack instead of fonts-hack-ttf

[Thomas Viehweger]

Package: plasma-integration
Version: 5.13.4-1

The description of fonts-hack-ttf says:
This package used to contain the TTF variants of the Hack font, which
are now part of the consolidated fonts-hack package.
This package is a dummy transitional package. It can be safely removed.

Please update the Recommends field.

Bug#907279: Package should recommend fonts-hack instead of fonts-hack-ttf

[Thomas Viehweger]

Package: libqtermwidget5-0
Version: 0.9.0-1

The description of fonts-hack-ttf says:
This package used to contain the TTF variants of the Hack font, which
are now part of the consolidated fonts-hack package.
This package is a dummy transitional package. It can be safely removed.

Please update the Recommends field.

Bug#902853: ldap-utils: Logfile warnings after upgrade to 2.4.40+dfsg-1+deb8u4

[Stefan van Lieshout]

Hi Randy,

The deinstall of the module libsasl2-modules-ldap solved the issue. It was 
installed, but not in use and therefore not configured which results in the 
mentioned warnings.

Grtz,

Stefan

> Op 2 jul. 2018, om 19:02 heeft Ryan Tandy  het volgende 
> geschreven:
> 
> Hi Stefan,
> 
> On Mon, Jul 02, 2018 at 12:26:08PM +0200, Stefan van Lieshout wrote:
>> The upgrade to 2.4.40+dfsg-1+deb8u4 results in a lot of warnings in the 
>> logfile /var/log/auth.log
>> 
>> Jul  2 09:27:43 hostname apache2: ldapdb_canonuser_plug_init() failed in 
>> sasl_canonuser_add_plugin(): invalid parameter supplied
>> Jul  2 09:27:43 hostname apache2: _sasl_plugin_load failed on 
>> sasl_canonuser_init for plugin: ldapdb
>> 
>> This is not only for the apache2 process, also sssd_be, sm-mta & php spawn 
>> the same warnings.
>> 
>> A downgrade to 2.4.40+dfsg-1+deb8u3 did solve the issue.
> 
> Thank you for the report. Indeed one thing that changed in this version is 
> that libldap now initializes libsasl eagerly, instead on on first use, so 
> previously these messages might have only appeared when a process invoked 
> SASL via LDAP - or not at all.
> 
> You are the first to mention an issue like this, though, so I wonder if it's 
> caused by a local configuration on your side.
> 
> Is your libsasl2-modules-ldap up-to-date with libsasl2-2? What do you use it 
> for?

Bug#906538: Possibly still not fixed

[Matthias Klumpp]

Am Sa., 25. Aug. 2018 um 22:39 Uhr schrieb Alan W. Irwin
:
>
> For those (like me, it is a long story) who want to delay doing a full
> system update of Buster, I confirm that
>
> apt-get install --reinstall libappstream4
>
> fixed this severe problem in Debian Buster for me.
>
> I am surprised this issue migrated from Debian unstable to Buster at
> all.  According to ,
> 0.12.2-1 (the version with this severe bug that affects all apt-get
> updates) [...]

The bug was in there for a really long time, but it needed the right
conditions to be exposed. In this case it was the "stellarium" package
being updated with a new version that had an empty content_rating XML
tag, which resulted in some chaos in libappstream's caching code which
relied on list items being there to guess the right container type.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#906538: Possibly still not fixed

[Alan W. Irwin]

For those (like me, it is a long story) who want to delay doing a full
system update of Buster, I confirm that

apt-get install --reinstall libappstream4

fixed this severe problem in Debian Buster for me.

I am surprised this issue migrated from Debian unstable to Buster at
all.  According to ,
0.12.2-1 (the version with this severe bug that affects all apt-get
updates) was accepted into unstable on 2018-08-04 and only migrated to
Buster on 2018-08-15.  So there were 11 days when any user that ran
"apt-get update" for unstable would have seen the effects of this
severe bug.  But apparently no report of the issue occurred which
means that the whole point of Debian unstable (to winnow out the
showstopper bugs before they hit Debian testing = Buster) broke down
in this particular case.

That said, kudos to Matthias Klumpp for quickly fixing this severe bug once
a Debian Buster user had reported it.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#906472: horst: FTBFS in buster/sid (unable to open 'stdarg.h')

[Christoph Biedl]

Santiago Vila wrote...

>   make -j1 check
> make[1]: Entering directory '/<>'
> sparse -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -std=gnu99 -Wall -Wextra -g -I. -DDO_DEBUG 
> -I/usr/include/libnl3 *.[ch]
> /usr/include/err.h:25:11: error: unable to open 'stdarg.h'

To reproduce this it's important to remove gcc-7 from the build chroot
(apt purge libgcc-7-dev ; apt --purge autoremove).

Problem is, sparse appearently uses hardcoded paths and looks for
stdarg.h in (among other places)

| /usr/lib/gcc/x86_64-linux-gnu/7//include/stdarg.h
|   ^

... which fails.

Solution is to rebuild sparse, building horst was successful then.
If this is true (please check!), the interesting question is why this
wasn't a problem in earlier gcc version bumps.

Christoph


signature.asc
Description: PGP signature

Bug#907106: (no subject)

[Adrian Bunk]

On Fri, Aug 24, 2018 at 04:15:14PM +1200, Amos Jeffries wrote:
> For the record the specific autoconf macro:
> 
>  AC_SEARCH_LIBS([__atomic_load_8],[atomic], ...)
> 
> Produces this test code:
> 
> "
> | #ifdef __cplusplus
> | extern "C"
> | #endif
> | char __atomic_load_8 ();
> | int
> | main ()
> | {
> | return __atomic_load_8 ();
> |   ;
> |   return 0;
> | }
> "
> 
> Which produces this (on all buildd's including the working ones):
> 
> "
> conftest.cpp:56:6: error: new declaration 'char __atomic_load_8()'
> ambiguates built-in declaration 'long long unsigned int
> __atomic_load_8(const volatile void*, int)' [-fpermissive]
>  char __atomic_load_8 ();
>   ^~~
> conftest.cpp: In function 'int main()':
> conftest.cpp:60:25: error: too few arguments to function 'long long
> unsigned int __atomic_load_8(const volatile void*, int)'
>  return __atomic_load_8 ();
>  ^
> "
> 
> "checking for library containing __atomic_load_8... no"

Thanks for this debugging.

I wrongly thought this was just a case of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

But squid has this already workarounded upstream with -latomic.

I've opened #907277 for this regression with gcc 8.

> Amos

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#907278: [python-httplib2] Certificate verification fails without apparent reason for some CAs

[Giovanni Mascellani]

Package: python-httplib2
Version: 0.9.2+dfsg-1
Severity: normal

Hi,

the following small script throws an exception saying that the
certificate validation has failed:

import httplib2
h = httplib2.Http(ca_certs='/etc/ssl/certs/ca-certificates.crt')
h.request("https://www.google.com;)

However, s_client seems to indicate that Google's certificate is valid,
using the same CA list:

$ openssl s_client -connect www.google.com:443 -CAfile
/etc/ssl/certs/ca-certificates.crt
...
Verify return code: 0 (ok)
...

I believe that httplib2 should accept the connection as valid. For other
domains, like www.facebook.com, the certificate is accepted happily, so
I presume there is something that depends on the CA.

Thanks, Giovanni.


--- System information. ---
Architecture: Kernel:   Linux 4.17.0-1-amd64

Debian Release: buster/sid
  500 unstable-debug  debug.mirrors.debian.org   500 unstable
ftp.be.debian.org   500 testing ftp.be.debian.org   500 stable
   repository.spotify.com   500 stable  repo.skype.com   500
stable  dl.google.com 1 experimentalftp.be.debian.org
--- Package information. ---
Depends (Version) | Installed
=-+-==
python:any   (<< 2.8) | python:any  (>= 2.7.5-5~) |
ca-certificates   | 20180409


Package's Recommends field is empty.

Package's Suggests field is empty.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#902749: waiting for feedback

[Nicholas D Steeves]

Hi Dima,

On Fri, Jul 20, 2018 at 09:24:49PM -0400, Nicholas D Steeves wrote:
> On Mon, Jul 09, 2018 at 05:03:05PM -0300, David Bremner wrote:
> > 
> > control: tag -1 moreinfo
> > 
> > Please wait a bit for feedback from (at least) Dima before dropping
> > xrdb-mode.
> 
> Ok, I'll leave it alone.  Assuming both GNOME and KDE are configured
> to use Wayland for buster, and if this proves successful, how useful
> will xrdb-mode be in buster+1?  Even tiling WMs now have Wayland
> equivalents (eg: i3 -> Sway).
> 

A somewhat recent discussion on #debian-quebec leads me to believe
that Wayland probably won't be ready to use by default before
buster+2, so it would seem there is still a lot of usefulness left in
xrdb-mode ;-)

I'm planning to remove xrdb-mode from emacs-goodies-el for an upload
on the 12 September so that other people will have a chance to notice
its removal and react.  12 October feels too close to the soft freeze,
which is why I've decided on September.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#897263: python3-seaborn: New upstream version available

[Jan Medlock]

Package: python3-seaborn
Version: 0.8.0-1
Followup-For: Bug #897263

Dear Maintainer,
Upstream released version 0.9.0 on 16 July 2018.

This release has several new features and changes to the API:
https://seaborn.pydata.org/whatsnew.html#v0-9-0-july-2018

Again, please let me know if I can help.

Sincerely,
Jan Medlock

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

Kernel: Linux 4.17.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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-seaborn depends on:
ii  python3 3.6.6-1
ii  python3-matplotlib  2.2.2-4+b1
ii  python3-numpy   1:1.14.5-1+b1
ii  python3-pandas  0.23.3-1
ii  python3-scipy   1.1.0-1+b1

Versions of packages python3-seaborn recommends:
ii  python3-bs44.6.3-1
ii  python3-patsy  0.4.1+git34-ga5b54c2-1

python3-seaborn suggests no packages.

-- no debconf information

Bug#906617: autopkgtest: Please consider defining directory environment variables

[Paul Gevers]

Hi Paul,

On 25-08-18 03:02, Paul Hardy wrote:
> As someone else who filed a bug mentioned, these things are probably
> obvious to the autopkgtest team, but they are ambiguities for a
> someone trying to use autopkgtest for the first time.
> 
> I think adding just a little more about the runtime environment
> someone can expect would make it easier for people to get their CI
> scripts working on the first attempt.

Patches to the documentation are always welcome, especially to cover
blind spots in our minds, even if only to get us in the right direction
of what you are really looking for. However, as Martin already
mentioned, try to do this not too specific for make as there are so many
other frameworks.

Also, I am trying to collect these kind of things and related stuff
(which may be framework specific) here:
https://wiki.debian.org/ContinuousIntegration/AutopkgtestBestPractices
Feel free to add your remarks there.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#902631: devscripts: CI fails in unstable due to Python 3.7

[Thomas Goirand]

Hi Sando,

I do support uploading 2 source packages, one for py2, and one for py3.
This is the most reasonable solution. Worst case, if that cannot be
done, then we got to move forward and restore Py3 support (and
eventually drop Py2), but I prefer the former solution.

The issue has been opened for nearly 2 months now, with nearly a month
without any news, and this makes me a bit nervous, as I need the py3
support to be restored.

What's holding you off more?

Cheers,

Thomas Goirand (zigo)

Bug#907276: lintian should give an error on Multi-Arch: same packages calling py{,3}compile in maintainer scripts

[Chris Lamb]

Hi Adrian,

> #889053 is an example why Multi-Arch: same packages
> calling py{,3}compile in maintainer scripts is a
> broken situation.
> 
> More background is in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812228#36

Thanks.

Can you provide some example text for the description? Happy to rework
an initial draft, but getting the background from someone definitely
"in the know" about the issue whilst it is fresh in their mind would be
ideal.


Regards,

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

Bug#907277: autoconf: AC_SEARCH_LIBS with AC_LANG([C++]) broken when using gcc 8

[Adrian Bunk]

Package: autoconf
Version: 2.69-11
Severity: serious

Originally debugged by Amos Jeffries in #907106:

$ cat configure.ac 
AC_INIT
AC_PROG_CXX
AC_LANG([C++])
AC_SEARCH_LIBS([__atomic_load_8],[atomic])
$ autoconf
$ CXX=g++-7 ./configure 
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++-7 accepts -g... yes
checking for library containing __atomic_load_8... -latomic
$ CXX=g++-8 ./configure 
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++-8 accepts -g... yes
checking for library containing __atomic_load_8... no
$


config.log says:

...
| #ifdef __cplusplus
| extern "C"
| #endif
| char __atomic_load_8 ();
| int
| main ()
| {
| return __atomic_load_8 ();
|   ;
|   return 0;
| }
configure:2326: g++-8 -o conftest -g -O2   conftest.cpp -latomic   >&5
conftest.cpp:16:6: error: new declaration 'char __atomic_load_8()' ambiguates 
built-in declaration 'long unsigned int __atomic_load_8(const volatile void*, 
int)' [-fpermissive]
 char __atomic_load_8 ();
  ^~~
conftest.cpp: In function 'int main()':
conftest.cpp:20:25: error: too few arguments to function 'long unsigned int 
__atomic_load_8(const volatile void*, int)'
 return __atomic_load_8 ();
 ^
...

Bug#907143: New version 2.29.1 available

[Samuel Thibault]

Hello,

Sebastien Bacher, le ven. 24 août 2018 12:10:33 +0200, a ecrit:
> There is a new 2.29.1 version available, would be nice to get in
> experimental with the rest of the GNOME 3.29 updates

Why not indeed.  It however build-depends on atk >= 2.29.1, so we need
that in first.

Samuel

Bug#907264: faketime: timezone bugs: lax parsing, no way to specify UTC or TZ

[Wolfgang Hommel]

Ian,

thanks for the detailed report, which is clearly to confirm.

libfaketime internally relies on strptime() to parse the user-specified 
timestamp.



On current macOS, your examples work reasonably well in the following 
variation:


$ FAKETIME_FMT="%Y-%m-%d %T %z" ./faketime -f '2018-06-26 09:00:03 
+0200' gdate -R

Tue, 26 Jun 2018 09:00:03 +0200

$ FAKETIME_FMT="%Y-%m-%d %T %z" ./faketime -f '2018-06-26 09:00:03 
+0300' gdate -R

Tue, 26 Jun 2018 08:00:03 +0200

$ FAKETIME_FMT="%Y-%m-%d %T %z" ./faketime -f '2018-06-26 09:00:03 
+0400' gdate -R

Tue, 26 Jun 2018 07:00:03 +0200


Whereas on Debian, with the glibc implementation of strptime, we end up 
with your results:


$ FAKETIME_FMT="%Y-%m-%d %T %z" ./faketime -f '2018-06-26 09:00:03 
+0200' date -R

Tue, 26 Jun 2018 09:00:03 +0200

$ FAKETIME_FMT="%Y-%m-%d %T %z" ./faketime -f '2018-06-26 09:00:03 
+0300' date -R

Tue, 26 Jun 2018 09:00:03 +0200

$ FAKETIME_FMT="%Y-%m-%d %T %z" ./faketime -f '2018-06-26 09:00:03 
+0400' date -R

Tue, 26 Jun 2018 09:00:03 +0200


Apparently, glibc goes for a new tm->tm_gmtoff field and supports %z 
(but not %Z) fully yet. This might give some headaches regarding 
cross-platform compatibility, and implementing a completely own parser 
(i.e., not using strptime()) does not seem viable, either. So yes, this 
needs to be addressed, but will take some time.



As a workaround, you can throw anything at libfaketime what `date` can 
interpret, as in


$ LD_PRELOAD=./libfaketime.so.1 FAKETIME_FMT=%s FAKETIME="`date +%s 
-d'2018-06-26 09:00:03+0400'`" date -R

Tue, 26 Jun 2018 07:00:03 +0200


Best regards,
Wolfgang

Bug#907276: lintian should give an error on Multi-Arch: same packages calling py{,3}compile in maintainer scripts

[Adrian Bunk]

Package: lintian
Version: 2.5.97
Severity: normal

#889053 is an example why Multi-Arch: same packages
calling py{,3}compile in maintainer scripts is a
broken situation.

More background is in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812228#36

Bug#812228: Multi-Arch support for dh-python

[Adrian Bunk]

On Sun, Sep 18, 2016 at 05:54:17AM -0400, Joe Crayne wrote:
> I've attached a patch that will make dh-python Multi-Arch aware by making
> use of the environment variable DPKG_MAINTSCRIPT_ARCH which is provided in
> the environment by dpkg.
> 
> Specifying the architecture this way will prevent a failure that requires
> the human administrator to fix.  With version 3.5.1-4 of python3-minimal it
> will unfortunately redundantly compile packages when multiple architecture
> variants provide the same python modules.  However, I've submitted a patch
> to python3-minimal that would correct that behavior.
>...
> --- a/autoscripts/postinst-py3compile
> +++ b/autoscripts/postinst-py3compile
> @@ -1,3 +1,3 @@
>  if which py3compile >/dev/null 2>&1; then
> - py3compile -p #PACKAGE# #ARGS#
> + py3compile -p #PACKAGE#:$DPKG_MAINTSCRIPT_ARCH #ARGS#
>  fi
>...

The correct approach is actually to disallow py{,3}compile in
Multi-Arch: same packages.

It does not even make much sense since it is not possible to install 
multiple architectures of the python interpreter at the same time,
and in normal cases the package could just be binary-all.

gir1.2-ibus-1.0 is a bit special for that, and the approach taken for 
that is to have no byte-compilation (and no python dependencies).

The latter is not perfect, but seems to be acceptable for a very
special situation (the python module is an optional part of an 
architecture-specific package). If anything should be improved
on that, the python module should be split out of the package.

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#907274: lintian: global-files-wildcard-not-first-paragraph-in-dep5-copyright is too agressiv

[Chris Lamb]

Hi Helge,

> However, I can live with both versions, so if it is too late
> to fix lintian than so be it.

I wouldn't say it was too late, more that it has not been raised before
and it would require somewhat of a big reworking of the logic so would
be difficult to see this being prioritised.

It would also mean your package is  ipso facto different from others
which — as a general rule — is not a great idea.

> I personally like to have the licenses listed first, as the reader
> than has a clear view of what he is expecting, before getting the
> details.

(Curiously, I completely agree with your reasoning but would disagree
with the idea that the license blocks are the "non-detail" part.)


Regards,

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

Bug#907275: RFS: debian-timeline/39+nmu1

[Birger Schacht]

Package: sponsorship-requests
Severity: normal

Dear mentors,

There was a short discussion about the status of the `debian-timeline`
package on the debian-publicity list [0], so i figured i could take a
look and upload a current version of the package. I'm not sure if it
really should be a NMU, but i'm happy to fix that if thats not adequate.

[0] https://lists.debian.org/debian-publicity/2018/08/msg00019.html

There are two additional changes to the upload: i've added the Mini
DebConf in HH (merge request on [1]) and i've updated the changelog
(branch on [2]). I'll also write to d-publicity about this RFS ;)

[1] https://salsa.debian.org/publicity-team/debian-timeline/merge_requests/3
[2] https://salsa.debian.org/bisco-guest/debian-timeline/commits/d-h

I am looking for a sponsor for my package "debian-timeline"

 * Package name: debian-timeline
   Version : 39+nmu1
   Upstream Author : Debian Publicity Team
 * URL : http://timeline.debian.net/
 * License : Public Domain
   Section : web

It builds those binary packages:

  debian-timeline - Web-based timeline of the Debian Project

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

  https://mentors.debian.net/package/debian-timeline


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

  dget -x
https://mentors.debian.net/debian/pool/main/d/debian-timeline/debian-timeline_39+nmu1.dsc


Changes since the last upload:
  * Non-maintainer upload.

  [Cédric Boutillier]
  * Publication of Debian 8.10 and 9.3

  [Jean-Pierre Giraud]
  * Git repo is now in salsa

  [Chris Lamb]
  * Move under the care of the Publicity Team

  [Donald Norwood]
  * Publication of Debian 8.11

  [Ana Guerrero López]
  * Add DebConf 18
  * Add `make mpublish` command

  [Laura Arjona Reina]
  * Remove Chris Lamb from uploaders

  [Birger Schacht]
  * Bump standards version
  * add Mini-DebConf Hamburg

Regards,
 Birger Schacht (bisco)



signature.asc
Description: OpenPGP digital signature

Bug#906993: rsh-redone-client: Please include rexec

[Guus Sliepen]

On Sat, Aug 25, 2018 at 08:53:44PM +0200, Patrik Schindler wrote:

> > Hello Patrik, rsh-redone was made in a different era where computers were 
> > slow and encryption was expensive.
> 
> I encounter this reasoning from time to time in different contexts. With all 
> due respect for the hard work of package maintainers and devs: I think, this 
> decision should be left to the user. My personal reason: I'd like to see a 
> regular packaged rexec(d) for talking to my old AS/400 which has no 
> cryptographic options.

With my package maintainer hat on: it is not our duty to add
functionality to the software we package. With my upstream developer hat
on: I have only so much time I can spend myself on software development,
and because the reasons I have given I'm not going to spend that time on
rsh-redone.

> But I accept your reply and will go forward to create my own rexec(d) 
> packages then.

That is great! Feel free to base your work on the source code of
rsh-redone. If you want to take over development of rsh-redone, that is
fine as well, and then I'd be happy to upload new versions of it to
Debian.

I've uploaded the full history to GitHub and GitLab, so you can fork
the repository from there if you wish:

https://github.com/gsliepen/rsh-redone
https://gitlab.com/gsliepen/rsh-redone

> > rsh-redone is in maintenance mode; I will not add any more functionality to 
> > it.
> 
> Is there any way to mark this package accordingly?

There's no standard way to do so.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#907274: lintian: global-files-wildcard-not-first-paragraph-in-dep5-copyright is too agressiv

[Helge Kreutzmann]

Hello Chris,
On Sat, Aug 25, 2018 at 08:18:29PM +0100, Chris Lamb wrote:
> > So either the spec needs clarification (which I doubt) or the lintian 
> > check should be relaxed.
> 
> I ACK that this might be valid spec-wise. I note, however, that this
> has been in Lintian since early 2013:
> 
>   
> https://salsa.debian.org/lintian/lintian/commit/29bd97f6e86f795c97f33747691fcf4a2c6e1060
> 
> Does that alter your view on this at all?

I personally like to have the licenses listed first, as the reader
than has a clear view of what he is expecting, before getting the
details. However, I can live with both versions, so if it is too late
to fix lintian than so be it.

Greetings

   Helge

P.S. In one of my packages I now switched because having to include an
 entire license makes it hard to read otherwise.
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#907274: lintian: global-files-wildcard-not-first-paragraph-in-dep5-copyright is too agressiv

[Chris Lamb]

Hi Helge,

> So either the spec needs clarification (which I doubt) or the lintian 
> check should be relaxed.

I ACK that this might be valid spec-wise. I note, however, that this
has been in Lintian since early 2013:

  
https://salsa.debian.org/lintian/lintian/commit/29bd97f6e86f795c97f33747691fcf4a2c6e1060

Does that alter your view on this at all?


Best wishes,

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

Bug#906284: lintian: check for incomplete-creative-commons-license gives false positives: the "not a law firm" is a preamble, not a license

[Chris Lamb]

forcemerge 906284 907272
thanks

Hi,

This looks like #906284 - let's at least centralise the on-going
discussion there (and vice versa).


Regards,

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

Bug#906610: lintian should check that changes and changelog distribution are identical

[Adrian Bunk]

On Sat, Aug 18, 2018 at 10:43:07PM +0100, Chris Lamb wrote:
> tags 906610 + moreinfo
> thanks
> 
> Hi Adrian,
> 
> > > > https://lists.debian.org/debian-changes/2018/08/msg00012.html
> > > > 
> > > > Distribution: stretch
> > > >  python-stem (1.6.0-4~bpo9+1) stretch-backports; urgency=medium
> > > 
> > > Would this specific instance have been covered by #906155?
> > 
> > This specific instance, yes.
> > 
> > But not for example
> > https://tracker.debian.org/news/978910/accepted-sane-backends-1027-1experimental6-source-into-unstable/
> 
> Gotcha.
> 
> Julien, thoughts on expanding your previous tag to catch ones like
> this? I'm a little hesistant to simply warn on mismatching
> distributions; I'm sure there are some fancy "tricks" done for security
> foo that you might be aware of..

I would be surprised if there is any case where this has to happen.

Usually these are accidents due to a "feature" of sbuild.

> Regards,

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#906993: rsh-redone-client: Please include rexec

[Patrik Schindler]

Hello Guus,

Am 25.08.2018 um 16:29 schrieb Guus Sliepen :

> Hello Patrik, rsh-redone was made in a different era where computers were 
> slow and encryption was expensive.

I encounter this reasoning from time to time in different contexts. With all 
due respect for the hard work of package maintainers and devs: I think, this 
decision should be left to the user. My personal reason: I'd like to see a 
regular packaged rexec(d) for talking to my old AS/400 which has no 
cryptographic options.

But I accept your reply and will go forward to create my own rexec(d) packages 
then.

> rsh-redone is in maintenance mode; I will not add any more functionality to 
> it.

Is there any way to mark this package accordingly?

:wq! PoC

PGP-Key: DDD3 4ABF 6413 38DE

Bug#906505: qlandkartegt: FTBFS in buster/sid (unable to find string literal operator)

[Markus Heidelberg]

On Fri, 17 Aug 2018 19:22:33 + Santiago Vila  wrote:
> Package: src:qlandkartegt
> Version: 1.8.1+ds-8
> Severity: serious
> Tags: ftbfs
> 
> Dear maintainer:
> 
> I tried to build this package in buster but it failed:

Hi,

I had the same error (and some more) today when building the Arch Linux
package. Have a look at my patches here:
https://aur.archlinux.org/packages/qlandkartegt/

Do "Download snapshot" and get fix-ver_str.patch from there. Maybe
fix-qtgui-include.patch as well if more errors arise.

Markus

Bug#907274: lintian: global-files-wildcard-not-first-paragraph-in-dep5-copyright is too agressiv

[Helge Kreutzmann]

Package: lintian
Version: 2.5.97
Severity: normal

This tag wants the wildcard paragraph as first stanza in
debian/copyright. I use(d) to start with the license stanzas, like

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: goobox
Upstream-Contact: Paolo Bacchilega 
  Paolo Bacchilega  
  Paolo Bacchilega  
Source: https://ftp.gnome.org/pub/GNOME/sources/goobox/

License: GPL-2+
 This program is free software; you can redistribute it and/or modify
…

License: GPL-2
 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
…

Files: *
Copyright: 2004-2017 Paolo Bacchilega 
License: GPL-2+

…

As per my reading of the sepc this is perfectly valid, however, still flagged 
by lintian.

So either the spec needs clarification (which I doubt) or the lintian check 
should be relaxed.

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

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

Versions of packages lintian depends on:
ii  binutils  2.31.1-4
ii  bzip2 1.0.6-9
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.5+b1
ii  file  1:5.34-2
ii  gettext   0.19.8.1-7
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.34
ii  libarchive-zip-perl   1.63-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdpkg-perl  1.19.0.5
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.08-1
ii  libipc-run-perl   20180523.0-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-3+deb9u4
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.74-1
ii  libxml-simple-perl2.25-1
ii  libyaml-libyaml-perl  0.72+repack-1
ii  man-db2.8.4-2
ii  patchutils0.3.4-2
ii  perl [libdigest-sha-perl] 5.26.2-7
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
pn  libtext-template-perl  

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#907273: O: perl-doc-html -- Perl documentation suitable for viewing with a web browser

[Giovani Augusto Ferreira]

Package: wnpp
Severity: normal

I intend to orphan the perl-doc-html package.

The package description is:
 This is the same documentation as provided by the perl-doc package.
 However, it has been formatted into HTML, making it suitable for viewing
 with a local web browser or for serving up on an intranet for multiple
 users.

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.

Regards,

Giovani

Bug#907272: lintian: incomplete-creative-commons-license check does not work (correctly)

[Helge Kreutzmann]

Package: lintian
Version: 2.5.97
Severity: normal

In the package I maintain some files are licensed under a variant of
CC-BY-SA-3.0. Until recently, I had the following in my
debian/copyright:

License: CC-BY-SA-3.0-EXCEPTION
 This work is licensed under a Creative Commons
 Attribution-Share Alike 3.0 Unported License
 .
 As a special exception, the copyright holders give you permission to copy,
 modify, and distribute the example code contained in this document under the
 terms of your choosing, without restriction.
 .
 The plain license can be found at
 https://creativecommons.org/licenses/by-sa/3.0/

After lintian informing me of the problem, I updated debian/copyright by 
replacing the last paragraph with the full license, however, lintian
still complains with the same warning.

I attached the new copyright  (too big for pasting now).

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

Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils  2.31.1-4
ii  bzip2 1.0.6-9
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.5+b1
ii  file  1:5.34-2
ii  gettext   0.19.8.1-7
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.34
ii  libarchive-zip-perl   1.63-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdpkg-perl  1.19.0.5
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.08-1
ii  libipc-run-perl   20180523.0-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-3+deb9u4
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.74-1
ii  libxml-simple-perl2.25-1
ii  libyaml-libyaml-perl  0.72+repack-1
ii  man-db2.8.4-2
ii  patchutils0.3.4-2
ii  perl [libdigest-sha-perl] 5.26.2-7
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
pn  libtext-template-perl  

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: goobox
Upstream-Contact: Paolo Bacchilega 
  Paolo Bacchilega  
  Paolo Bacchilega  
Source: https://ftp.gnome.org/pub/GNOME/sources/goobox/

Files: *
Copyright: 2004-2017 Paolo Bacchilega 
License: GPL-2+

Files: configure.ac
Copyright: 2009-2017 Paolo Bacchilega 
   2012 György Balló 
   2016 Laurent Bigonville 
License: GPL-2+

Files: COPYING
Copyright: 1989,1991 Free Software Foundation, Inc.
   2004 Paolo Bacchilega 
   2014 Tadej Janež 
License: RESTRICTED

Files: INSTALL
Copyright: 1994-1996,1999-2002,2004-2008 Free Software Foundation, Inc.
   2004,2005,2009 Paolo Bacchilega 
License: FREEDOC
 
Files: Makefile.am
Copyright: 2004,2005,2007,2009,2012,2014 Paolo Bacchilega 
   2005 Tommi Vainikainen
License: GPL-2+

Files: data/org.gnome.Goobox.gschema.xml
Copyright: 2011-2013 Paolo Bacchilega 
   2011 Free Software Foundation
License: GPL-2+
 
Files: help/ChangeLog
Copyright: 2005 Paolo Bacchilega 
   2006 Daniel Nylander 
   2007 Jorge Gonzalez Gonzalez 
   2007 Jordi Mas 
   2007 Jose Sanchez Moreno
   2007 Joan Duran 
   2007 Yannig MARCHEGAY 
   2008 Claude Paroz 
   2008 Jens Seidel 
   2008 Helge Kreutzmann 
License: GPL-2+

Files: help/Makefile.am
Copyright: 2005,2009,2011-2013 Paolo Bacchilega 
   2005 Tommi Vainikainen
   2006 Daniel Nylander 
   2007 Jorge Gonzalez Gonzalez 
   2007 Jose Sanchez Moreno
   2007 Jordi Mas 
   2007 Yannig MARCHEGAY 
   2008 Claude Paroz 
   2008 Jens Seidel 
   2008 Helge Kreutzmann 
   2010 Petr Kovar 
 

Bug#907185: New version available

[Christoph Biedl]

Control: severity 907185 wishlist
Control: tags 907185 pending

Sebastien Bacher wrote...

> There is a new 1.10.0 version available which fixes some bugs, it
> would be nice to have it into Debian

Technically, 1.9.0+ds-2 in 10/buster and sid *is* 1.10 - I had
cherry-picked all upstream commits before upload and got surprised by a
new upstream version the next morning :)

Still the packaging could see some streamlining, will take care of your
request - by the time the freeze gets closer the latest.

Christoph


signature.asc
Description: PGP signature

Bug#907168: pytest-httpbin FTBFS with OpenSSL 1.1.1

[Kurt Roeckx]

This is caused by a Debian change to require a 2048 bit key by
default instead of a 1024 bit key. Since this is just for a test,
you can either just replace the certificates with larger keys,
or lower the security level for the test from 2 to 1. I suggest
you just create a new certificates.


Kurt

Bug#907022: puma: autopkgtest times out after update of openssl

[Kurt Roeckx]

The most likely reason for a timeout is this:
  *) SSL_MODE_AUTO_RETRY is enabled by default. Applications that use blocking
 I/O in combination with something like select() or poll() will hang. This
 can be turned off again using SSL_CTX_clear_mode().
 Many applications do not properly handle non-application data records, and
 TLS 1.3 sends more of such records. Setting SSL_MODE_AUTO_RETRY works
 around the problems in those applications, but can also break some.
 It's recommended to read the manpages about SSL_read(), SSL_write(),
 SSL_get_error(), SSL_shutdown(), SSL_CTX_set_mode() and
 SSL_CTX_set_read_ahead() again.


Kurt

Bug#907271: dosbox: doesn't capture mouse in windowed mode

[cacatoes]

Package: dosbox
Version: 0.74-4.3

Hello,

When in windowed mode, dosbox can't capture the mouse, so it is
unusable.

Hitting CTRL+F10 is meant to force capture, but it doesn't do, and I
can't move the mouse at all.

However, mouse works when in fullscreen mode.

Other commands (CPU speed adjustment, switching to full/windowed
mode...) do work. 

PS: I have tried with i3 (my current window manager) and Openbox. Both
exhibit the problem.

Regards,

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

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

Versions of packages dosbox depends on:
ii  libasound2   1.1.6-1
ii  libc62.27-5
ii  libgcc1  1:8.2.0-4
ii  libgl1   1.1.0-1
ii  libpng16-16  1.6.34-2
ii  libsdl-net1.21.2.8-5
ii  libsdl-sound1.2  1.0.3-8
ii  libsdl1.2debian  1.2.15+dfsg2-1
ii  libstdc++6   8.2.0-4
ii  libx11-6 2:1.6.5-1
ii  zlib1g   1:1.2.11.dfsg-1

dosbox recommends no packages.

dosbox suggests no packages.

-- no debconf information

Bug#907079: offlineimap: Not using SNI

[Kurt Roeckx]

For more information about this, see:
https://wiki.openssl.org/index.php/TLS1.3#Server_Name_Indication

Bug#906955: isync: can't verify some ssl certificate(e.g. imap.gmail.com)

[Kurt Roeckx]

This is google enforcing SNI when you use TLS 1.3, see
https://wiki.openssl.org/index.php/TLS1.3#Server_Name_Indication


Kurt

Bug#857644: widelands: appstream metadata error: missing icon

[Jeremy Bicha]

On Sat, Aug 25, 2018 at 1:46 PM Matthias Klumpp  wrote:
> Second, your issue is *way* simpler than you think. You don't need to
> make any changes to your metainfo file. Instead, just adapt the
> .desktop file. It has this line:
>
> ```
> Comment[zh_TW]=一款即時演變的策略遊戲
> Icon=/usr/share/games/widelands/data/images/logos/wl-ico-64.png
> TryExec=widelands
> ```
> "Icon" is an absolute path, hence the data extractor searches for the
> file in the same package and doesn't find it => data gets rejected.
> You *do* however ship higher quality icons. So just changing this to:

I agree and I proposed
https://salsa.debian.org/games-team/widelands/merge_requests/1

Thanks,
Jeremy Bicha

Bug#907270: RM: fraqtive [armel armhf] -- NBS; no longer built on armel/armhf

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

fraqtive (0.4.8-9) unstable; urgency=high

  * Change build dependency to libqt5opengl5-desktop-dev. fraqtive currently
does not build on armel and armhf.
Closes: #906667

 -- Patrick Matthäi   Fri, 24 Aug 2018 09:42:57 +0200

Bug#907135: boxbackup: FTBFS with OpenSSL 1.1.1

[Kurt Roeckx]

The log shows:
> ERROR:   SSL or crypto error: loading certificates from 
> testfiles/clientCerts.pem: error:140AB18F:SSL 
> routines:SSL_CTX_use_certificate:ee key too small

This is caused by a Debian change to require a 2048 bit key by
default instead of a 1024 bit key. Since this is just for a test,
you can either just replace the certificate with a larger key,
or lower the security level for the test from 2 to 1. I suggest
you just create a new certificate.


Kurt

Bug#906997: lua-sec: FTBFS with OpenSSL 1.1.1: test failure

[Kurt Roeckx]

Hi,

The problem is:
> Generating a 1024 bit RSA private key

Which then later results in:
> lua: server.lua:19: error loading certificate (ee key too small)

We've changed the default in Debian to require 2048 bit keys.


Kurt

Bug#907269: llvm-defaults: Add clang-diff tool

[Marco F]

Source: llvm-defaults
Version: 0.42exp1
Severity: wishlist

clang-diff is a new tool in clang-6.0 [1], however I couldn't install
it with the package manager [2]. Note that other tools, for example,
clang-format (1:6.0-42exp1) can be installed with the package
manager [3].

So please consider adding the new tool clang-diff.

--Marco

[1] https://github.com/llvm-mirror/clang/tree/release_60/tools/clang-diff
[2] https://packages.debian.org/experimental/clang-diff
[3] https://packages.debian.org/experimental/clang-format

Bug#857644: widelands: appstream metadata error: missing icon

[Matthias Klumpp]

Hey :-)

AppStream maintainer here.
First, if you only want to see issues that affect the validity of the
file (and also how important they are), use "appstreamcli" to
validate, from the "appstream" package (should be preinstalled):

appstreamcli validate yourfile.netainfo.xml

That is what the generator uses internally. To cover all the things,
validating with both validators is a good idea though, appstream-util
tends to make style issues fatally important.

Second, your issue is *way* simpler than you think. You don't need to
make any changes to your metainfo file. Instead, just adapt the
.desktop file. It has this line:

```
Comment[zh_TW]=一款即時演變的策略遊戲
Icon=/usr/share/games/widelands/data/images/logos/wl-ico-64.png
TryExec=widelands
```
"Icon" is an absolute path, hence the data extractor searches for the
file in the same package and doesn't find it => data gets rejected.
You *do* however ship higher quality icons. So just changing this to:

```
Comment[zh_TW]=一款即時演變的策略遊戲
Icon=widelands
TryExec=widelands
```

Will fix this error.

Third: Is there a reson why the content_rating tag is prefixed with
"x-"? It's an official tag now, so you could drop that.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#906505: qlandkartegt: FTBFS in buster/sid (unable to find string literal operator)

[Christoph Biedl]

Santiago Vila wrote...

> /<>/qlandkartegt-1.8.1+ds/3rdparty/map2gcm/main.cpp:43:46: error: 
> unable to find string literal operator 'operator""_MKSTR' with 'const char 
> [20]', 'long unsigned int' arguments
>  #define VER_STR 
> _MKSTR(VER_MAJOR)"."_MKSTR(VER_MINOR)"."_MKSTR(VER_STEP)
>   ^

That was easy to catch, earlier compiler versions gave according
warnings. But there is more, it seems (wild guess) the Qt header were
re-organized or there is another reason why several modules fail to
build with "error: invalid use of incomplete type 'class XXX'". Fix was
done by wild-guessing.

The result however is not usable - qlandkartegt stalls at the splash
screen, waiting for some data.

This is the point where somebody with Qt programming experience should
take over. Or I'll try to continue, but not today. Patches are attached.

Christoph, who'd like to have a usable qlandkartegt in Debian - how is 
QMapShack supposed to be a replacement?
--- a/3rdparty/cache2gtiff/main.cpp
+++ b/3rdparty/cache2gtiff/main.cpp
@@ -35,7 +35,7 @@
 #define _MKSTR(x)   _MKSTR_1(x)
 #endif
 
-#define VER_STR _MKSTR(VER_MAJOR)"."_MKSTR(VER_MINOR)"."_MKSTR(VER_STEP)
+#define VER_STR _MKSTR(VER_MAJOR) "." _MKSTR(VER_MINOR) "." _MKSTR(VER_STEP)
 #define WHAT_STR"cache2gtiff, Version " VER_STR
 
 
--- a/3rdparty/map2gcm/main.cpp
+++ b/3rdparty/map2gcm/main.cpp
@@ -40,7 +40,7 @@
 #define _MKSTR(x)   _MKSTR_1(x)
 #endif
 
-#define VER_STR _MKSTR(VER_MAJOR)"."_MKSTR(VER_MINOR)"."_MKSTR(VER_STEP)
+#define VER_STR _MKSTR(VER_MAJOR) "." _MKSTR(VER_MINOR) "." _MKSTR(VER_STEP)
 #define WHAT_STR"map2gcm, Version " VER_STR
 
 #define MAX_TILE_SIZE   1024
--- a/3rdparty/map2jnx/main.cpp
+++ b/3rdparty/map2jnx/main.cpp
@@ -51,7 +51,7 @@
 #define _MKSTR(x)   _MKSTR_1(x)
 #endif
 
-#define VER_STR _MKSTR(VER_MAJOR)"."_MKSTR(VER_MINOR)"."_MKSTR(VER_STEP)
+#define VER_STR _MKSTR(VER_MAJOR) "." _MKSTR(VER_MINOR) "." _MKSTR(VER_STEP)
 #define WHAT_STR"map2jnx, Version " VER_STR
 
 #define JNX_MAX_TILES   5 //6250
--- a/3rdparty/map2rmap/main.cpp
+++ b/3rdparty/map2rmap/main.cpp
@@ -33,7 +33,7 @@
 #define _MKSTR(x)   _MKSTR_1(x)
 #endif
 
-#define VER_STR _MKSTR(VER_MAJOR)"."_MKSTR(VER_MINOR)"."_MKSTR(VER_STEP)
+#define VER_STR _MKSTR(VER_MAJOR) "." _MKSTR(VER_MINOR) "." _MKSTR(VER_STEP)
 #define WHAT_STR"map2rmap, Version " VER_STR
 
 
--- a/3rdparty/map2rmp/CFileGenerator.cpp
+++ b/3rdparty/map2rmp/CFileGenerator.cpp
@@ -27,7 +27,7 @@
 #define _MKSTR(x)   _MKSTR_1(x)
 #endif
 
-#define VER_STR _MKSTR(VER_MAJOR)"."_MKSTR(VER_MINOR)"."_MKSTR(VER_STEP)
+#define VER_STR _MKSTR(VER_MAJOR) "." _MKSTR(VER_MINOR) "." _MKSTR(VER_STEP)
 
 
 extern "C"
--- a/3rdparty/map2rmp/main.cpp
+++ b/3rdparty/map2rmp/main.cpp
@@ -32,7 +32,7 @@
 #define _MKSTR(x)   _MKSTR_1(x)
 #endif
 
-#define VER_STR _MKSTR(VER_MAJOR)"."_MKSTR(VER_MINOR)"."_MKSTR(VER_STEP)
+#define VER_STR _MKSTR(VER_MAJOR) "." _MKSTR(VER_MINOR) "." _MKSTR(VER_STEP)
 #define WHAT_STR"map2rmp, Version " VER_STR
 
 int main(int argc, char ** argv)
--- a/src/version.h
+++ b/src/version.h
@@ -23,6 +23,6 @@
 #define _MKSTR(x)  _MKSTR_1(x)
 #endif
 
-#define VER_STR   _MKSTR(VER_MAJOR)"."_MKSTR(VER_MINOR)"."_MKSTR(VER_STEP)
+#define VER_STR   _MKSTR(VER_MAJOR) "." _MKSTR(VER_MINOR) "." _MKSTR(VER_STEP)
 #define WHAT_STR  "QLandkarte GT, Version " VER_STR
 #endif   //VERSION_H
--- a/src/CDlgProxy.cpp
+++ b/src/CDlgProxy.cpp
@@ -21,6 +21,7 @@
 #include "CMainWindow.h"
 
 #include 
+#include 
 
 CDlgProxy::CDlgProxy(QString , QString , QWidget *parent)
 : QDialog(parent)
--- a/src/CDiaryEdit.cpp
+++ b/src/CDiaryEdit.cpp
@@ -34,6 +34,7 @@
 #include "CSettings.h"
 
 #include 
+#include 
 #include 
 #include 
 #include 
--- a/src/CTextEditWidget.cpp
+++ b/src/CTextEditWidget.cpp
@@ -56,6 +56,7 @@
 #include "CCanvas.h"
 
 #include 
+#include 
 #include 
 
 CTextEditWidget::CTextEditWidget(QWidget * parent)
--- a/src/CLiveLogToolWidget.cpp
+++ b/src/CLiveLogToolWidget.cpp
@@ -20,6 +20,7 @@
 #include "CLiveLogDB.h"
 
 #include 
+#include 
 
 CLiveLogToolWidget::CLiveLogToolWidget(QTabWidget * parent)
 :QWidget(parent)


signature.asc
Description: PGP signature

Bug#906335: alot bug #906335

[Santiago Vila]

On Sat, Aug 25, 2018 at 03:08:25PM +0200, Johannes Schauer wrote:

> For what it's worth, here is a step by step instruction how to build alot in a
> Stretch container for unstable *without* running into the FTBFS:
> [...]

Great. I followed the recipe and this is a summary of what I tried so far:

- It builds ok in a n1-standard-1 machine from GCE.
- It fails in the described way in my KVM machine.
- I've reinstalled the KVM machine from scratch, and it still fails.

I infer that the chroot is ok and I'm not using sbuild improperly.

My theory is that the test suite makes some assumptions about the
underlying machine which may or may not hold (it could be overall
CPU speed, for example).

Thanks.

Bug#902470: Status?

[olivier sallou]

Hi,
My packages have been removed from testing due to this bug.
Can we remove failing test and lower bug severity waiting for upstream fix?

Else i will need to patch my packages to remove influx support, removing
features.

Bug impact looks quite low.

Thanks

Olivier

Bug#906139: debian-policy: versioned depends on libjs-sphinxdoc unsatisfiable on stretch

[Sean Whitton]

control: severity -1 serious
control: retitle -1 Demote libjs-sphinxdoc hard dependency to a recommendation
control: unblock -1 by 658238
control: tag -1 -help

Hello,

On Sat 25 Aug 2018 at 06:46PM +0200, Sven Joachim wrote:

> FWIW, this dependency is ATM also not satisfied in unstable because
> sphinx 1.7.7 was uploaded there today.  Since there are no binNMUs for
> Arch:all packages, debian-policy apparently needs a sourceful upload for
> every new sphinx upstream version.  And those appear rather frequently.

Urgh.

I am reluctantly (yet gratefully!) working on implementing Ian's
substvar hack.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#907268: xine-ui: lirc support missing because package compilation is unable to find liblirc_client.so

[Thomas Blume]

Package: xine-ui
Version: 0.99.9-1.3
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

installation of xine-ui

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

configured lirc and .lircrc, checked that it is working with mplayer

   * What was the outcome of this action?

lirc works with mplayer, irw, etc., only xine-ui ignores any remote key press

   * What outcome did you expect instead?

xine-ui should support lirc

Reason is that the xine-ui configure script doesn't check the directory:

/usr/lib/i386-linux-gnu/

where liblirc_client.so.0 is located.
You should probably extend the search routines in the configure script,
e.g.:

-->
$as_echo_n "checking for liblircclient... " >&6; }
for type in "$shrext" .a; do
  for lib in lib32 lib lib64; do
  for llirc in "$LIRC_PREFIX/$lib" /$lib /usr/$lib 
/usr/local/$lib /usr/$lib/i386-linux-gnu; do
--<

after adding this path and recompiling the package, lirc works as
expected in xine.


-- System Information:
Debian Release: 9.5
  APT prefers stable
  APT policy: (1000, 'stable'), (900, 'stable'), (750, 'testing'), (500, 
'stable-updates')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-6-686-pae (SMP w/1 CPU core)
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 xine-ui depends on:
ii  libc62.24-11+deb9u1
ii  libcurl3-gnutls  7.52.1-5+deb9u6
ii  libjpeg62-turbo  1:1.5.1-2
ii  libncurses5  6.0+20161126-1+deb9u2
ii  libpng16-16  1.6.28-1
ii  libreadline7 7.0-3
ii  libtinfo56.0+20161126-1+deb9u2
ii  libx11-6 2:1.6.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxft2  2.3.2-1+b2
ii  libxine2 1.2.6-1.3
ii  libxine2-ffmpeg  1.2.6-1.3
ii  libxine2-x   1.2.6-1.3
ii  libxinerama1 2:1.1.3-1+b3
ii  libxtst6 2:1.2.3-1
ii  libxv1   2:1.0.11-1
ii  libxxf86vm1  1:1.1.4-1+b2

Versions of packages xine-ui recommends:
ii  xdg-utils  1.1.1-1+deb9u1

xine-ui suggests no packages.

-- no debconf information

Bug#907267: openmpi: liggghts build on i386 times out

[Graham Inggs]

Source: openmpi
Version: 3.1.1.real-6
Severity: serious

Hi Alastair

The last two builds of liggghts on i386 [1] against openmpi
3.1.1.real-6 and 3.1.1.real-7 have timed out.

Regards
Graham


[1] https://buildd.debian.org/status/logs.php?pkg=liggghts=i386

Bug#814451: openmpi 1.10 has stderr output by default, breaking autopkg tests

[Graham Inggs]

In Ubuntu, I've noticed a couple of build and autopkgtest failures due
to this recently.
I've been using the following workaround:

export OMPI_MCA_btl_base_warn_component_unused=0

Bug#905023: quirrelmail 2:1.4.23~svn20120406-2+deb8u2 Lintian run failed (policy violation)

[Abhijith PA]

Hello.

I was preparing build for the latest CVEs of squirrelmail (#905023) and
found out the latest version in jessie have a grave lintian warning -
"squirrelmail source: license-problem-non-free-RFC
functions/decode/koi8_u.php". Have you noticed it :)


Thanks in advance
Abhijith PA

Bug#905696: debian-policy: Errors in README

[Sean Whitton]

control: tag -1 +pending

Hello,

On Wed 08 Aug 2018 at 09:55AM +0200, Helge Kreutzmann wrote:

> There are some errors in README.txt.gz:
> 1) git clone git://anonscm.debian.org/dbnpolicy/policy.git
>
> This repository does not exist (anymore?). Probably on salsa right
> now?
>
> 2)  : git merge master
> # Edit files to remove conflict
>  : git commit -s
>
> The double colon is not present in any of the other command line
> inputs.
>
> 3) local-branch-name is some convenient name designating your local
>
> Probably a substitution from HTML did not work here. There a several
> other instances of similar problems below in the README, e.g. below
> "Repository layout" and "Managing a bug"

All fixed, thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#907265: ftbfs in a sid chroot

[Jussi Pakkanen]

On Sat, Aug 25, 2018 at 7:40 PM, Marc Haber
 wrote:

>   File "/usr/lib/python3.6/multiprocessing/synchronize.py", line 162, in 
> __init__
> SemLock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx)
>   File "/usr/lib/python3.6/multiprocessing/synchronize.py", line 59, in 
> __init__
> unlink_now)
>
> PermissionError: [Errno 13] Permission denied
> I can provide a full build log if that helps.
>
> Am I doing something wrong? Should I do more than apt build-dep ./ and 
> debuild?

You need to have /dev/shm mounted in the build environment. Pbuilder
does this by default, don't know how other build envs do it.

Bug#907190: [PATCH] dgit-maint-debrebase(7): Add runes for inspecting history

[Ian Jackson]

I'm not sure if this is the right place but I wanted to publish this
information sooner rather than later.

Closes: #907190.

Signed-off-by: Ian Jackson 
---
 dgit-maint-debrebase.7.pod | 47 ++
 1 file changed, 47 insertions(+)

diff --git a/dgit-maint-debrebase.7.pod b/dgit-maint-debrebase.7.pod
index 16b65b39..b4330f9d 100644
--- a/dgit-maint-debrebase.7.pod
+++ b/dgit-maint-debrebase.7.pod
@@ -458,6 +458,53 @@ Note that this will introduce a new pseudomerge.
 After dgit pushing, be sure to git push to B, if
 you're using that.
 
+=head1 INSPECTING THE HISTORY
+
+The git history made by git-debrebase can seem complicated.
+Here are some suggestions for helpful invocations of gitk and git.
+They can be adapted for other tools like tig, git log, etc.
+
+=over
+
+=item History of package in Debian (disregarding history from upstream):
+
+% gitk --first-parent
+
+In a laundered branch, the delta queue is at the top.
+
+=item History of the packaging (excluding the delta queue)
+
+% gitk :/debian :!/debian/patches
+
+=item Just the delta queue (ie, Debian's changes to upstream):
+
+% gitk --first-parent -- :/ :!/debian
+
+=item Full history including old versions of the delta queue:
+
+% gitk --date-order
+
+The "Declare fast forward" commits you see have an older history
+(usually, an older delta queue) as one parent,
+and a newer history as the other.
+--date-order makes gitk show the delta queues in the right order.
+
+=item Show complete diff since the last upload:
+
+% git diff dgit/dgit/sid..HEAD -- :/ :!/debian/patches
+(Includes changes to upstream files.)
+
+=item Interdiff of delta queue since last upload, if you really want that:
+
+% git debrebase make-patches
+% git diff dgit/dgit/sid..HEAD -- debian/patches
+
+=back
+
+Also of course there is
+
+% git debrebase status
+
 =head1 HANDLING DFSG-NON-FREE MATERIAL
 
 =head2 Illegal material
-- 
2.11.0

Bug#905909: README.md: Formatting and publication to www.debian.org

[Sean Whitton]

control: tag -1 +pending

Hello,

On Sat 11 Aug 2018 at 11:21PM +0900, Osamu Aoki wrote:

> README.md of debian-policy at salsa doesn't show indexed list as
> expected.
>
> Also, it doesn't provide information on how it get published to
> www.debiasn.org site to track down issues.

Thank you for the patch -- applied.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#906139: debian-policy: versioned depends on libjs-sphinxdoc unsatisfiable on stretch

[Sven Joachim]

On 2018-08-14 11:59 -0700, Vagrant Cascadian wrote:

> Package: debian-policy
> Version: 4.2.0.1
> Severity: wishlist
>
> Thanks for maintaining debian-policy; it is one of the things that
> really distinguishes Debian in an excellent way!
>
>
> For many years, I've installed debian-policy from sid on a stable system
> to have it readily available, but recent versions of debian-policy have
> a versioned dependency that is unsatisfyable in stable:
>
>   Depends: libjs-sphinxdoc (<< 1.7.6.0~), libjs-sphinxdoc (>= 1.7.6)

FWIW, this dependency is ATM also not satisfied in unstable because
sphinx 1.7.7 was uploaded there today.  Since there are no binNMUs for
Arch:all packages, debian-policy apparently needs a sourceful upload for
every new sphinx upstream version.  And those appear rather frequently.

Cheers,
   Sven

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

[Sean Whitton]

Hello Jonathan,

On Mon 06 Aug 2018 at 06:24PM -0700, Jonathan Nieder wrote:

> Thanks for explaining your point of view.  I agree with relying on
> maintainer judgement, and the best way to do that is to avoid having a
> requirement in policy at all in some areas.
>
> I think it really does help to look at the motivating use cases.  If
> we focus on what it would be a good idea for a packager to do, then
> policy would become very long, and it would become much less useful as
> a precise source of information about Debian's packaging policies.
> Instead, I find it more useful to focus on the non-obvious bits where
> having a documented policy can help.

This is an important point to bear in mind when working on Policy;
thank you for noting it.

> If I understand correctly, you're saying that the following fall into
> that category:
>
> - don't abbreviate build commands unless DEB_BUILD_OPTIONS=terse
> - don't abbreviate test commands and output unless
>   DEB_BUILD_OPTIONS=terse
>
> Do I understand correctly?  Are there more examples in that category,
> or could we just document those two?

These are the only examples that come to my mind at present, indeed.

> [...]
>> 1) Add something like "In particular, build command lines should not be
>>abbreviated."  Then we are not leaving that particular case up to
>>maintainer judgement, without removing the general recommendation.
>
> This wouldn't help Clément's motivating example, since it would not
> clarify whether there is additional verbose output he needs to
> provide.
>
>> 2) Add some examples of what should usually not be included, or perhaps
>>just say that if some output makes a build log tens of megabytes in
>>size, it should not be included.
>
> I feel that this is trying to solve a problem that doesn't need
> solving: packagers generally have good taste, and for most purposes it
> is obvious to packagers what outputs they need to include (after all,
> the packager is the primary audience of these logs!)  Build command
> lines really are a special case since they are important to the
> toolchain maintainers.
>
> The size threshold you mentioned would suggest that the Linux kernel
> should not support unabbreviated build logs.

After reading the message to which I'm replying, I am no longer
confident in my previous opinion that recommending verbosity in general,
and providing some examples of where verbosity is most important, is
better than recommending verbosity in only specific cases (as you
advocate).

I would like to see opinions about this from people other than the few
of us who have been writing to this bug.  This bug will be closed on the
next upload since we addressed the original submitter's main concern,
but if you're still interested in driving this change to recommend
verbosity in only specific cases, please do clone this bug, or file a
new one (IMO the latter would be more useful at this point in the
discussion, but I appreciate that it is more work).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#907265: ftbfs in a sid chroot

[Marc Haber]

Package: meson
Version: 0.47-1
Severity: normal

Hi,

I am trying to build meson in a sid chroot like I always do when I begin
doing local stuff. This fails for me with a "permission denied":


test_compiler_c_stds (__main__.LinuxlikeTests) ... ok
test_compiler_check_flags_order (__main__.LinuxlikeTests) ... ok
test_compiler_cpp_stds (__main__.LinuxlikeTests) ... ok
test_coverage (__main__.LinuxlikeTests) ... skipped 'gcovr not found'
test_cpp_std_override (__main__.LinuxlikeTests) ... ok
test_cross_find_program (__main__.LinuxlikeTests) ... ok
test_custom_soname (__main__.LinuxlikeTests) ... ok
test_install_umask (__main__.LinuxlikeTests) ... ok
test_installed_modes (__main__.LinuxlikeTests) ... ok
test_installed_modes_extended (__main__.LinuxlikeTests) ... ok
test_installed_soname (__main__.LinuxlikeTests) ... ok
test_introspect_dependencies (__main__.LinuxlikeTests) ... skipped 'glib >= 
2.56.2 needed for the rest'
test_old_gnome_module_codepaths (__main__.LinuxlikeTests) ... ok
test_order_of_l_arguments (__main__.LinuxlikeTests) ... ok
test_pch_with_address_sanitizer (__main__.LinuxlikeTests) ... ok
test_pic (__main__.LinuxlikeTests) ... ok
test_pkg_unfound (__main__.LinuxlikeTests) ... ok
test_pkgconfig_formatting (__main__.LinuxlikeTests) ... ok
test_pkgconfig_gen (__main__.LinuxlikeTests) ... ok
test_pkgconfig_gen_deps (__main__.LinuxlikeTests) ... ok
test_pkgconfig_internal_libraries (__main__.LinuxlikeTests) ... ok
test_pkgconfig_usage (__main__.LinuxlikeTests) ... ok
test_qt5dependency_pkgconfig_detection (__main__.LinuxlikeTests) ... skipped 
'Qt not found with pkg-config'
test_qt5dependency_qmake_detection (__main__.LinuxlikeTests) ... ok
test_reconfigure (__main__.LinuxlikeTests) ... ok
test_run_installed (__main__.LinuxlikeTests) ... ok
test_soname (__main__.LinuxlikeTests) ... ok
test_unity_subproj (__main__.LinuxlikeTests) ... ok
test_usage_external_library (__main__.LinuxlikeTests) ... skipped 'workflow 
currently only works on macOS'
test_vala_c_warnings (__main__.LinuxlikeTests) ... ok
test_vala_generated_source_buildir_inside_source_tree (__main__.LinuxlikeTests) 
... ok
test_cflags_cross_environment_pollution (__main__.LinuxArmCrossCompileTests) 
... ok
test_cross_file_overrides_always_args (__main__.LinuxArmCrossCompileTests) ... 
ok

--
Ran 130 tests in 170.235s

OK (skipped=14)
Checking that configuring works...
Checking that building works...
Checking that testing works...
Checking that installing works...
Traceback (most recent call last):
  File "run_project_tests.py", line 699, in 
(passing_tests, failing_tests, skipped_tests) = run_tests(all_tests, 
'meson-test-run', options.extra_args)
  File "run_project_tests.py", line 531, in run_tests
return _run_tests(all_tests, log_name_base, extra_args)
  File "run_project_tests.py", line 558, in _run_tests
executor = ProcessPoolExecutor(max_workers=num_workers)
  File "/usr/lib/python3.6/concurrent/futures/process.py", line 402, in __init__
EXTRA_QUEUED_CALLS)
  File "/usr/lib/python3.6/multiprocessing/context.py", line 102, in Queue
return Queue(maxsize, ctx=self.get_context())
  File "/usr/lib/python3.6/multiprocessing/queues.py", line 42, in __init__
self._rlock = ctx.Lock()
  File "/usr/lib/python3.6/multiprocessing/context.py", line 67, in Lock
return Lock(ctx=self.get_context())
  File "/usr/lib/python3.6/multiprocessing/synchronize.py", line 162, in 
__init__
SemLock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx)
  File "/usr/lib/python3.6/multiprocessing/synchronize.py", line 59, in __init__
unlink_now)
PermissionError: [Errno 13] Permission denied
System information.
Architecture: ('64bit', 'ELF')
Machine: x86_64
Platform: Linux
Processor: 
System: Linux

Running unittests.

make[1]: *** [debian/rules:19: override_dh_auto_test] Error 1
make[1]: Leaving directory '/home/mh/packages/meson/meson-0.47.1'
make: *** [debian/rules:15: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
debuild: fatal error at line 1152:
dpkg-buildpackage -rfakeroot -us -uc -ui -j10 failed


I can provide a full build log if that helps.

Am I doing something wrong? Should I do more than apt build-dep ./ and debuild?

Greetings
Marc

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

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

Versions of packages meson depends on:
pn  ninja-build  
ii  python3  3.6.6-1

meson recommends no packages.

meson suggests no packages.

Bug#907266: RM: sra-sdk [i386] -- ROM; Does not build fir i386 any more - please remove old version of arch i386

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Please remove sra-sdk for architecture i386 to enable migration of a bug free 
amd64 version in sid.

Kind regards

Andreas.

Bug#906901: debian-policy: Perl script shebang requirement is disturbing and inconsistent with rest of policy

[Sean Whitton]

control: tag -1 +patch

Hello,

On Fri 24 Aug 2018 at 08:44PM -0700, Russ Allbery wrote:

> I'm looking for seconds for this patch to relax the current requirement
> back to a should.  After that, I think the next step would be to introduce
> automatic fixing of the #! line to debhelper, since that seems relatively
> uncontroversial, and then we can reconsider this later after that's had a
> chance to propagate through the archive.

I agree that this is how we should proceed.

> --- a/perl-policy.xml
> +++ b/perl-policy.xml
> @@ -533,7 +533,7 @@ $(MAKE) OPTIMIZE="-O2 -g -Wall"
>Script Magic
>
>
> -All packaged perl programs must start with
> +All packaged perl programs should start with
>  #!/usr/bin/perl and may append such flags as
>  are required.
>
> diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> index f31a3b4..bc87573 100644
> --- a/policy/ch-files.rst
> +++ b/policy/ch-files.rst
> @@ -186,7 +186,7 @@ All command scripts, including the package maintainer 
> scripts inside the
>  package and used by ``dpkg``, should have a ``#!`` line naming the shell
>  to be used to interpret them.
>
> -In the case of Perl scripts this must be ``#!/usr/bin/perl``.
> +In the case of Perl scripts this should be ``#!/usr/bin/perl``.
>
>  When scripts are installed into a directory in the system PATH, the
>  script name should not include an extension such as ``.sh`` or ``.pl``

Seconded, and given the other seconds, committed to git.

>> My personal view is that the rule is the correct one though. Installing
>> a different perl for some application specific purpose is not uncommon -
>> some people choose to not use the system perl at all when they are
>> deploying a perl application - and they should be free to do that by
>> putting a different perl in the path. That doesn't mean that they
>> suddenly have to worry about parts of the packaged Debian system
>> breaking.  I certainly couldn't name every part of Debian that I rely on
>> that's written in perl!
>
> Yes, this is my feeling as well.  It's all well and good to say that if
> local administrators install their own Perl and things break, they get to
> keep both pieces, but this seems unnecessarily fragile.

Yes.

My first thought when seeing this thread was dpkg-divert, which hasn't
been mentioned yet.  If a local admin wants to override perl such that
all Debian-installed Perl command scripts use their custom perl,
dpkg-divert seems like a semantically correct way to do that.  And this
method is far less susceptible to the various examples of breakage that
have been brought up in this thread so far.

> There are various ways in which some other Perl could be added earlier
> in the PATH without the administrator having any intention whatsoever
> to supplant system Perl with it.  Consider, for instance, some local
> application written using bleed Perl installed in some non-standard
> path, some other program that with the best of intentions prepends the
> location of that application to the PATH, and some program that this
> application happens to run without even necessarily knowing it's
> written in Perl.  It seems better to ensure that this sort of pattern
> just works.

Yes.  Users should not have to think very hard about the language in
which stuff that Debian installs into /usr/bin is implemented.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#907264: faketime: timezone bugs: lax parsing, no way to specify UTC or TZ

[Ian Jackson]

Package: faketime
Version: 0.9.6-7+b1

1. faketime does not properly validate the supplied advanced timestamp
   format:
  $ faketime -f '2018-06-26 09:00:03+02:00' date -R
  Tue, 26 Jun 2018 09:00:03 +0100
  $ date -R -d '2018-06-26 09:00:03+02:00'
  Tue, 26 Jun 2018 08:00:03 +0100
  $

2. There is no way to specify a time which does not depend on the
   timezone in force.  This is quite awkward, because there are some
   times which, in some timezones, cannot be represented in the
   offered `advanced timestamp format'.

  $ TZ=Europe/London date -d @$(( 1540683000 + 3600 * 0 )) -R
  Sun, 28 Oct 2018 00:30:00 +0100
  $ TZ=Europe/London date -d @$(( 1540683000 + 3600 * 1 )) -R
  Sun, 28 Oct 2018 01:30:00 +0100
  $ TZ=Europe/London date -d @$(( 1540683000 + 3600 * 2 )) -R
  Sun, 28 Oct 2018 01:30:00 +
  $ TZ=Europe/London date -d @$(( 1540683000 + 3600 * 3 )) -R
  Sun, 28 Oct 2018 02:30:00 +
  $ TZ=Europe/London faketime -f '2018-10-28 01:30:00' date -R
  Sun, 28 Oct 2018 01:30:00 +
  $

   The problem is that
 "2018-10-28 01:30:00 London time"
   occurs twice, at both of
 Sun, 28 Oct 2018 01:30:00 +0100 = Sun, 28 Oct 2018 00:30:00 +
   and
 Sun, 28 Oct 2018 01:30:00 +

   faketime makes it impossible to specify the former.

   This can be worked around by saving and restoring TZ:
 env TZ=UTC faketime -f  env TZ="$TZ" 

I suggest that these bugs be fixed by interpreting a numeric timezone
offset in RFC3339 format, as shown above.  This should be done for
both the absolute frozen time, and the start-at timestamp.

Thanks,
Ian.


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

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

Versions of packages faketime depends on:
ii  libc62.24-11+deb9u3
ii  libfaketime  0.9.6-7+b1

faketime recommends no packages.

faketime suggests no packages.

-- no debconf information

Bug#907261: lintian: do not warn for missing B-D: debhelper with debhelper-compat

[Chris Lamb]

tags 907261 + pending
thanks

Thanks Peter; applied in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/7409f5713b3631cf782e0fcdc25c50e52156156d

  checks/rules.pm   | 6 +++---
  data/debhelper/dh_addons-manual   | 4 ++--
  data/debhelper/dh_commands-manual | 4 ++--
  debian/changelog  | 4 
  4 files changed, 11 insertions(+), 7 deletions(-)


Regards,

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

Bug#907220: Some caps plugins are crashing

[trebmuh]

Tags: patch + pending

... couic ...


The attached patch fixes the issue on a debian stretch rebuild.
It hasn't been tried by me so far (hence this report and not a commit
to the debian salsa repository).


It should have been :

It hasn't been tried by me **on a Buster build** so far (hence this 
report

and not a commit to the debian salsa repository).

Olivier