Bug#921612: ITP: icingaweb2-module-x509 -- track certificates by scanning networks for TLS services

[Kunz David]

Package: wnpp
Owner: david.k...@dknet.ch

* Package name: icingaweb2-module-x509
  Upstream Author : Icinga Development Team 
* License : GPL-2
  Description : track certificates by scanning networks for TLS
services (icingaweb2 extension)

  Icinga Web 2 is a very modular, fast and simple web interface for 
  your Icinga monitoring environment.
  .
  The X.509 module keeps track of certificates as they are
  deployed in a network environment by scanning networks for TLS
  services.

Greetings,
David

Bug#921351: [pkg-go] Bug#921351: prometheus-postfix-exporter: Init script missing

[Michael Stapelberg]

On Thu, Feb 7, 2019 at 8:46 AM Scott Kitterman  wrote:

> No.  It's an actual policy violation, so the bug is correct.  I'd leave it
> as is and ask the release team to mark it buster-ignore.
>

Could you kindly point me to where the process is described for this? I’m
not sure what I’d need to do to get it marked buster-ignore. Thanks.


>
> Scott K
>
> On February 7, 2019 7:29:01 AM UTC, Michael Stapelberg <
> stapelb...@debian.org> wrote:
> >On Wed, Feb 6, 2019 at 11:01 PM Scott Kitterman 
> >wrote:
> >
> >> It's not the FTP Team's job to fix policy compliance issues in
> >packages.
> >> If you have a problem with that being a policy must, then you should
> >take
> >> it up with the policy team.
> >>
> >
> >Yeah, I’ll post to #911165
> >
> >
> >>
> >> I completely understand the frustration, but in my own packages I
> >take the
> >> time to do it because Debian policy says it's required, not because I
> >> particularly care about sysvinit.
> >>
> >
> >I don’t think fulfilling the policy for fulfilling the policy’s sake is
> >a
> >good use of anyone’s time.
> >
> >Can we close this bug until someone comes along who actually cares? :)
> >
> >
> >>
> >> Scott K
> >>
> >> On February 6, 2019 9:23:46 PM UTC, Michael Stapelberg <
> >> stapelb...@debian.org> wrote:
> >> >Can you provide a patch if you care about sysvinit please? The Go
> >> >packaging
> >> >team is pretty manpower-constrained and non-systemd is a niche case,
> >so
> >> >any
> >> >help is appreciated. Thanks!
> >> >
> >> >On Wed, Feb 6, 2019 at 7:49 PM Scott Kitterman
> >
> >> >wrote:
> >> >
> >> >> Package: prometheus-postfix-exporter
> >> >> Version: 0.1.2-1
> >> >> Severity: serious
> >> >> Justification: Policy 9.11
> >> >>
> >> >> Excerpt from policy 9.11:
> >> >>
> >> >> However, any package integrating with other init systems
> >> >> must also be backwards-compatible with sysvinit by providing a
> >SysV-
> >> >> style init script with the same name as and equivalent
> >functionality
> >> >> to any init-specific job, as this is the only start-up
> >configuration
> >> >> method guaranteed to be supported by all init implementations.
> >> >>
> >> >> The package violates a policy must by not providing s sysvint init
> >> >script.
> >> >>
> >> >> Scott K
> >> >>
> >> >> ___
> >> >> Pkg-go-maintainers mailing list
> >> >> pkg-go-maintain...@alioth-lists.debian.net
> >> >>
> >> >
> >>
> >
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
> >>
>


-- 
Best regards,
Michael

Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name

[Michael Stapelberg]

Hi,

I have recently been made aware that this policy is still around when
someone filed a bug asking for a package to be made compliant. I had
assumed that the requirement would have been dropped by now, so let me
echo/add a few thoughts.

When I have previously voiced discontent about the work required to
support multiple architectures in Debian, porters have reassured me that
they would help with that. In the same spirit, I have effectively been
relying on contributions for sysvinit support in all of my packages.

It was almost 10 years ago (!) that I have first read about systemd. I
have been using systemd exclusively for many many years. My working
knowledge of sysvinit has degraded over the years, and I have no
motivation or time left to even test sysvinit support in any capacity.

At this point, there are many computer users who have not ever used
anything but systemd. I worry that _demanding_ (instead of encouraging)
sysvinit support via policy is too much effort for package maintainers,
for very little practical gain. I can say with certainty that my time is
better spent elsewhere, and I think many others feel the same way.

My personal suggestion is to change policy to require support for
Debian’s most relevant init system and architecture combination
(i.e. package maintainers should ensure systemd/amd64 works). Anything
beyond that should be encouraged, but kept optional, so as to unburden
the package maintainers.

-- 
Best regards,
Michael

Bug#921351: [pkg-go] Bug#921351: prometheus-postfix-exporter: Init script missing

[Scott Kitterman]

No.  It's an actual policy violation, so the bug is correct.  I'd leave it as 
is and ask the release team to mark it buster-ignore.

Scott K

On February 7, 2019 7:29:01 AM UTC, Michael Stapelberg  
wrote:
>On Wed, Feb 6, 2019 at 11:01 PM Scott Kitterman 
>wrote:
>
>> It's not the FTP Team's job to fix policy compliance issues in
>packages.
>> If you have a problem with that being a policy must, then you should
>take
>> it up with the policy team.
>>
>
>Yeah, I’ll post to #911165
>
>
>>
>> I completely understand the frustration, but in my own packages I
>take the
>> time to do it because Debian policy says it's required, not because I
>> particularly care about sysvinit.
>>
>
>I don’t think fulfilling the policy for fulfilling the policy’s sake is
>a
>good use of anyone’s time.
>
>Can we close this bug until someone comes along who actually cares? :)
>
>
>>
>> Scott K
>>
>> On February 6, 2019 9:23:46 PM UTC, Michael Stapelberg <
>> stapelb...@debian.org> wrote:
>> >Can you provide a patch if you care about sysvinit please? The Go
>> >packaging
>> >team is pretty manpower-constrained and non-systemd is a niche case,
>so
>> >any
>> >help is appreciated. Thanks!
>> >
>> >On Wed, Feb 6, 2019 at 7:49 PM Scott Kitterman
>
>> >wrote:
>> >
>> >> Package: prometheus-postfix-exporter
>> >> Version: 0.1.2-1
>> >> Severity: serious
>> >> Justification: Policy 9.11
>> >>
>> >> Excerpt from policy 9.11:
>> >>
>> >> However, any package integrating with other init systems
>> >> must also be backwards-compatible with sysvinit by providing a
>SysV-
>> >> style init script with the same name as and equivalent
>functionality
>> >> to any init-specific job, as this is the only start-up
>configuration
>> >> method guaranteed to be supported by all init implementations.
>> >>
>> >> The package violates a policy must by not providing s sysvint init
>> >script.
>> >>
>> >> Scott K
>> >>
>> >> ___
>> >> Pkg-go-maintainers mailing list
>> >> pkg-go-maintain...@alioth-lists.debian.net
>> >>
>> >
>>
>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
>>

Bug#921611: clblas: crashes (not just fails) on compile failure

[Rebecca N. Palmer]

Package: clblas
Version: 2.12-1
Control: tags -1 patch

(Split from #881054: cloning a merged bug is not allowed, and both 
original reports better match the other part.)


After a compile failure (e.g. due to #881054), clblas crashes trying to 
dereference a NULL pointer.


Fix:

diff --git a/src/library/blas/generic/common2.cc 
b/src/library/blas/generic/common2.cc

index 05bbdc6..609e5de 100644
--- a/src/library/blas/generic/common2.cc
+++ b/src/library/blas/generic/common2.cc
@@ -85,9 +85,11 @@ extern "C" Kernel* makeKernelCached(cl_device_id device,
  buildOpts,
  error);

-bl.setProgram(kernel->program);
-
-bl.populateCache();
+if (kernel != NULL)
+{
+bl.setProgram(kernel->program);
+bl.populateCache();
+}

 return kernel;
 }

Bug#772378: texlive-latex-extra-doc: bashism in /bin/sh script

[Norbert Preining]

Hi Hilmar,

> What do we do with that issue?

Ignore. Nothing that is a real issue whatsoever.

If you have energy, report upstream and try a reorganization of these
makedoc and other build scripts by moving them into the "srcfiles"
category, which would result with them not being installed.

But I think this is wasted time for not much -- no gain.

I'll probably upload today a new (the last?) checkout.

Norbert

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

Bug#810822: MooseFS > LizardFS

[Dmitry Smirnov]

Some years passed and situation changed again... Although LizardFS is still 
ahead of MooseFS in terms of features (EC and XOR chunks; master/slave fail-
over), it is quickly becoming obsolete with upstream development stalled 
without progress for a while... LizardFS is affected by upstream bugs with 
little hope for fixing and naturally community is moving back to MooseFS.

With loyal community MooseFS is doing well and the project is stronger than 
ever. MooseFS is actively developed, bug reports are being answered, etc. 
Just as Jakub was saying, MooseFS is appreciated for its performance and 
stability. Sadly LizardFS is quickly losing trust in those areas...

-- 
All the best,
 Dmitry Smirnov.

---

To predict the behavior of ordinary people in advance, you only have to
assume that they will always try to escape a disagreeable situation with
the smallest possible expenditure of intelligence.
-- Friedrich Nietzsche


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

Bug#921610: xmldiff: update package to 2.2 with python3 support

[魏銘廷]

Source: xmldiff
Version: 0.6.10-3
Severity: normal

This package has new upstream version 2.2, and python3 support is
missing from this package.

I am updating glyphslib and its test on new package depends on xmldiff
2.2 on python3.  I can temporarily disable test during freeze to upload
glyphslib, but this package should be using python3 for buster+1 that
python2 should be removed.

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

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


signature.asc
Description: PGP signature

Bug#772378: texlive-latex-extra-doc: bashism in /bin/sh script

[Hilmar Preuße]

Am 06.12.2014 um 15:06 teilte Raphael Geissert mit:

Hi Norbert,


I've ran checkbashisms (from the 'devscripts' package) over the whole
archive and I found that your package has a /bin/sh script that uses a
"bashism".

checkbashisms' output:

possible bashism in ./usr/share/doc/texlive-doc/latex/flabels/makedoc line
31 (unsafe echo with backslash):
echo "\batchmode">> ltxdoc.cfg



What do we do with that issue?

I my opinion it doesn't make sense to deliver a makedoc file in the
final documentation package. Hence I'd simply not install it. Will you
remove it from upstream packages?

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

Bug#921351: [pkg-go] Bug#921351: prometheus-postfix-exporter: Init script missing

[Michael Stapelberg]

On Wed, Feb 6, 2019 at 11:01 PM Scott Kitterman 
wrote:

> It's not the FTP Team's job to fix policy compliance issues in packages.
> If you have a problem with that being a policy must, then you should take
> it up with the policy team.
>

Yeah, I’ll post to #911165


>
> I completely understand the frustration, but in my own packages I take the
> time to do it because Debian policy says it's required, not because I
> particularly care about sysvinit.
>

I don’t think fulfilling the policy for fulfilling the policy’s sake is a
good use of anyone’s time.

Can we close this bug until someone comes along who actually cares? :)


>
> Scott K
>
> On February 6, 2019 9:23:46 PM UTC, Michael Stapelberg <
> stapelb...@debian.org> wrote:
> >Can you provide a patch if you care about sysvinit please? The Go
> >packaging
> >team is pretty manpower-constrained and non-systemd is a niche case, so
> >any
> >help is appreciated. Thanks!
> >
> >On Wed, Feb 6, 2019 at 7:49 PM Scott Kitterman 
> >wrote:
> >
> >> Package: prometheus-postfix-exporter
> >> Version: 0.1.2-1
> >> Severity: serious
> >> Justification: Policy 9.11
> >>
> >> Excerpt from policy 9.11:
> >>
> >> However, any package integrating with other init systems
> >> must also be backwards-compatible with sysvinit by providing a SysV-
> >> style init script with the same name as and equivalent functionality
> >> to any init-specific job, as this is the only start-up configuration
> >> method guaranteed to be supported by all init implementations.
> >>
> >> The package violates a policy must by not providing s sysvint init
> >script.
> >>
> >> Scott K
> >>
> >> ___
> >> Pkg-go-maintainers mailing list
> >> pkg-go-maintain...@alioth-lists.debian.net
> >>
> >
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
>


-- 
Best regards,
Michael

Bug#921420: Acknowledgement (linux-image-4.19.0-1-amd64: Does not work with higher resolutions (above 1920))

[Ben Mesman]

Some extra information: I did some tests on an older system (HP t620) and it worked fine. The t620 seems to be using the radeon kernel module, while the t630 (with the bug) is using the amdgpu module.

 

(Maybe the bug title needs to include either the system name 't630' or the graphics card 'Carrizo/0x9874'?)

Bug#921609: gnutls28 does not build with pkcs11 support, breaks certificate pinning in glib-networkign and libgcr

[Michael Gratton]

Package: gnutls28
Version: 3.6.6-2

Currently, gnutls28 is built with the following CONFIGUREARGS[0]:

>  --with-default-trust-store-file=/etc/ssl/certs/ca-certificates.crt \

This breaks a number of things, including pinning certificates with 
libgcr and having that respected by glib-networking[1] (requiring 
applications such as Geary to implement non-trivial worarounds[2] to 
make this work on Debian systems) and using GnuTLS and GIO with things 
like smart cards and other PKCS11 components.


Per [1], please consider not building with 
`-with-default-trust-store-file` and build with 
`--with-default-trust-store-pkcs11="pkcs11:"` instead.


Cheers,
//Mike


[0] - 


[1] - 
[2] - 

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 

Bug#919743: Uploading....

[Jonathan Carter]

Looks good, uploading...

Bug#833931: c++: Fail to build when and the noreturn keyword is used

[Petter Reinholdtsen]

Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89232

I registered the issue upstream.
-- 
Happy hacking
Petter Reinholdtsen

Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

[Andreas Tille]

Hi,

On Wed, Feb 06, 2019 at 01:20:48PM +0100, Andreas Tille wrote:
> On Mon, Feb 04, 2019 at 05:26:08PM +0100, Fabian Klötzl wrote:
> > So I improved the upstream libmurmurhash, adapted the package and filed an
> > ITP (#921353). I even managed to locally build mash against the new package.
> > So hereby I kindly ask you to fix the last lintian issue about NMU which I
> > don't fully understand and then maybe sponsor an upload.
> 
> I uploaded to new with my Automake patches and pinged ftpmaster via IRC.

I confirm I've tested mash with the now accepted libmurmurhash.
Unfortunately it does not pass its build time tests any more now that I
rebuild it for uploading.  I get lots of diffs in the expected and
calculated results.  It starts like this:

   dh_auto_test
make -j4 test VERBOSE=1
make[1]: Entering directory '/build/mash-2.1+dfsg'
cd test ; ../mash sketch -o genomes.msh genome1.fna genome2.fna genome3.fna
cd test ; ../mash sketch -r -I reads reads1.fastq reads2.fastq -o reads.msh
Sketching genome1.fna...
Sketching genome2.fna...
Sketching genome3.fna...
Estimated genome size: 127897
Estimated coverage:1.113
Writing to reads.msh...
Writing to genomes.msh...
./mash info -d test/genomes.msh > test/genomes.json
./mash dist test/genomes.msh test/reads.msh > test/genomes.dist
cd test ; ../mash screen genomes.msh reads1.fastq reads2.fastq > screen
Loading genomes.msh...
   1412 distinct hashes.
Streaming from 2 inputs...
./mash info -d test/reads.msh > test/reads.json
diff test/genomes.dist test/ref/genomes.dist
1,3c1,3
< genome1.fna   reads   0.1244911.3814e-218 38/1000
< genome2.fna   reads   0.1402581.1397e-151 27/1000
< genome3.fna   reads   0.1244911.37891e-21838/1000
---
> genome1.fna   reads   0.12101 4.48626e-21441/1000
> genome2.fna   reads   0.12827 2.61074e-18035/1000
> genome3.fna   reads   0.12101 4.45454e-21441/1000
make[1]: *** [Makefile:97: testDist] Error 1
make[1]: *** Waiting for unfinished jobs
diff test/genomes.json test/ref/genomes.json
7c7
<   "hashType" : "MurmurHash3_x86_32",
---
>   "hashType" : "MurmurHash3_x64_128",
18,1017c18,1017
...


I'm stoping here since this this is a suspicious one that might
(or might not) explain all the following diffs.  Any clue how to
solve this?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#921607: Please exec the actual mupdf from the shell script

[martin f krafft]

Package: mupdf
Version: 1.14.0+ds1-3
Severity: normal
Tags: patch

Currently, a shell script spawns the actual mupdf. If the shell 
script is killed, it does not take the mupdf process with it. There 
is also no reason why the shell script needs to stay around. Please 
use 'exec' as per this patch:


--- /usr/bin/mupdf  2019-01-19 16:01:19.0 +1300
+++ /usr/bin/mupdf  2019-02-07 17:32:54.678896649 +1300
@@ -42,7 +42,7 @@
trap 'rm -f "$tmp"' EXIT

if [ "$file" = "" ]; then
-$cmd || true
+exec $cmd
else
-$cmd "$file" || true
+exec $cmd "$file"
fi

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

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

Versions of packages mupdf depends on:
ii  libc62.28-5
ii  libfreetype6 2.9.1-3
ii  libharfbuzz0b2.3.0-1
ii  libjbig2dec0 0.15-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libopenjp2-7 2.3.0-1.1
ii  libssl1.11.1.1a-1
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  zlib1g   1:1.2.11.dfsg-1

mupdf recommends no packages.

Versions of packages mupdf suggests:
ii  mupdf-tools  1.14.0+ds1-3

--
no debconf information


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


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

Bug#921608: gdebi: installed other deb packages successfully then gdebi gui can not be closed

[i]

Package: gdebi
Version: 0.9.5.7+nmu1
Severity: normal

Dear Maintainer,

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

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

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



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

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

Versions of packages gdebi depends on:
ii  gdebi-core0.9.5.7+nmu1
ii  gir1.2-gtk-3.03.22.11-1
ii  gir1.2-vte-2.91   0.46.1-1
ii  gksu  2.0.2-9+b1
ii  gnome-icon-theme  3.12.0-2
ii  python3   3.5.3-1
ii  python3-gi3.22.0-2

Versions of packages gdebi recommends:
ii  libgtk2-perl  2:1.2499-1
ii  lintian   2.5.50.4
ii  shared-mime-info  1.8-1+deb9u1

gdebi suggests no packages.

-- no debconf information

Bug#921606: gdebi: installed other deb packages successfully then gdebi gui can not be closed

[i]

Package: gdebi
Version: 0.9.5.7+nmu1
Severity: normal

Dear Maintainer,

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

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

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



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

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

Versions of packages gdebi depends on:
ii  gdebi-core0.9.5.7+nmu1
ii  gir1.2-gtk-3.03.22.11-1
ii  gir1.2-vte-2.91   0.46.1-1
ii  gksu  2.0.2-9+b1
ii  gnome-icon-theme  3.12.0-2
ii  python3   3.5.3-1
ii  python3-gi3.22.0-2

Versions of packages gdebi recommends:
ii  libgtk2-perl  2:1.2499-1
ii  lintian   2.5.50.4
ii  shared-mime-info  1.8-1+deb9u1

gdebi suggests no packages.

-- no debconf information

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

[Diane Trout]

version: 0.17+repack-3
tag: pending

I have a new version (hopefully uploaded successfully) where I fixed
dnssec-trigger-control-setup to not generate new keys or certificates
if called repeatedly. So now the code to delete small keys should get
called.

I also included upstream's fix for the segfault we were having.
(Also reported as #921227)

Unfortunately a bug #921538 showed up in unbound that is causing my CItests to 
fail 

Bug#916912: [pre-approval] stretch-pu: package freerdp/1.1.0~git20140921.1.440916e+dfsg1-13+deb9u3

[Mike Gabriel]

Hi Adam,

On  Do 07 Feb 2019 06:59:25 CET, Adam D. Barratt wrote:


On Wed, 2019-02-06 at 23:03 +, Mike Gabriel wrote:

Maybe you can help... I just uploaded freerdp, BUT...

the src:pkg contains an unwanted file: the .debdiff between +deb9u2  
and +deb9u3.


It does? I may possibly just not have had enough coffee, but: where? ht
tps://release.debian.org/proposed-
updates/stable_diffs/freerdp_1.1.0~git20140921.1.440916e+dfsg1-
13+deb9u3.debdiff is the automatically generated source debdiff based
on your upload.


Ah, interesting. After uploading I found the .debdiff in the sources  
folder that I sent to this bug in the first place. So, I assumed that  
it ended up in the just uploaded Debian source package. It is  
obviously not in the uploaded src:pkg as your .debdiff URL shows. So,  
all seems to be well.



If you have means to reject it still, please do. Otherwise, we need
to live with it.


We can reject packages from stable-new (the holding queue in front on
p-u). That's fine, I'd just like to confirm that it's really needed in
this case.


No, it's not needed. It can go into p-u. Thanks for feedback! Excuse  
my unnecessary panic attack. ;-)


light+love
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpzQfLnZ_hzF.pgp
Description: Digitale PGP-Signatur

Bug#921605: gdebi: installed deb packages then can not be closed

[i]

Package: gdebi
Version: 0.9.5.7+nmu1
Severity: normal

Dear Maintainer,

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

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

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



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

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

Versions of packages gdebi depends on:
ii  gdebi-core0.9.5.7+nmu1
ii  gir1.2-gtk-3.03.22.11-1
ii  gir1.2-vte-2.91   0.46.1-1
ii  gksu  2.0.2-9+b1
ii  gnome-icon-theme  3.12.0-2
ii  python3   3.5.3-1
ii  python3-gi3.22.0-2

Versions of packages gdebi recommends:
ii  libgtk2-perl  2:1.2499-1
ii  lintian   2.5.50.4
ii  shared-mime-info  1.8-1+deb9u1

gdebi suggests no packages.

-- no debconf information

Bug#921538: Fails to start since upgrade to 1.9.0-1

[Trout, Diane E.]

> 
> It seems like chroot'ing to /etc/unbound is attempted. To workaround
you
> can try this:
> 
> cat << EOF > /etc/unbound/unbound.conf.d/chroot.conf
> server:
>   chroot: ""
> EOF
> service unbound restart

This fix worked for me.

Bug#916912: [pre-approval] stretch-pu: package freerdp/1.1.0~git20140921.1.440916e+dfsg1-13+deb9u3

[Adam D. Barratt]

On Wed, 2019-02-06 at 23:03 +, Mike Gabriel wrote:
> Maybe you can help... I just uploaded freerdp, BUT...
> 
> the src:pkg contains an unwanted file: the .debdiff between +deb9u2  
> and +deb9u3.

It does? I may possibly just not have had enough coffee, but: where? ht
tps://release.debian.org/proposed-
updates/stable_diffs/freerdp_1.1.0~git20140921.1.440916e+dfsg1-
13+deb9u3.debdiff is the automatically generated source debdiff based
on your upload.

> If you have means to reject it still, please do. Otherwise, we need
> to live with it.

We can reject packages from stable-new (the holding queue in front on
p-u). That's fine, I'd just like to confirm that it's really needed in
this case.

Regards,

Adam

Bug#833931: c++: Fail to build when and the noreturn keyword is used

[Petter Reinholdtsen]

Control: reopen -1
Control: reassign -1 g++-8
Control: found -1 8.2.0-14

I had a look, and this issue still exist with GCC 8.2.  Reassigning as
appropriate.

% gcc c++-noreturn.c 
c++-noreturn.c: In function 'stop_now':
c++-noreturn.c:10:1: warning: 'noreturn' function does return
 }
 ^
% clang c++-noreturn.c 
c++-noreturn.c:10:1: warning: function declared 'noreturn' should not return 
[-Winvalid-noreturn]
}
^
1 warning generated.
% c++ c++-noreturn.c 
c++-noreturn.c:7:1: error: 'noreturn' does not name a type
 noreturn void stop_now(int i) // or _Noreturn void stop_now(int i)
 ^~~~
c++-noreturn.c: In function 'int main()':
c++-noreturn.c:15:3: error: 'stop_now' was not declared in this scope
   stop_now(2);
   ^~~~
% c++ --version
c++ (Debian 8.2.0-14) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

%

-- 
Happy hacking
Petter Reinholdtsen

Bug#921573: lintian: binary-from-other-architecture only works sometimes

[Helmut Grohne]

Hi Chris,

On Wed, Feb 06, 2019 at 10:01:44PM +0100, Chris Lamb wrote:
> Replying quickly; do you happen to have the .deb still handy? If
> so, would be great to attach to this bug report as it will save
> folks the cross-build step. :)

I actaully don't. Recording such artifacts is beyond the capacity of my
storage system. On the other hand I think this is not useful: sbuild
reports a Package-Time of 20 here. The time you took writing the mail
already took longer than just building it[1]:

sbuild -d sid --host=mips64el procmail

At this point in time, we have the unfortunate situation where glibc is
skewed between amd64 and mips64el, so the build actually fails (just
tried). A build in buster should work, but I don't happen to have a
buster chroot around. The sid build should work in 6h or 12h.

Hope this helps

Helmut

[1] That was before the glibc upload. ;)

Bug#920878: lintian: please check for missing Build-Depends: qt5-qmake:native when using lrelease

[Helmut Grohne]

Hi Dmitry,

On Thu, Jan 31, 2019 at 10:56:37PM +0300, Dmitry Shachnev wrote:
> One thing bothers me: it is perfectly possible to use lrelease without qmake
> at all. All you need is have qttools5-dev-tools:native installed and call
> /usr/lib/qt5/bin/lrelease during build. You can do it from any non-qmake
> buildsystem, or even directly from debian/rules. I have a package that calls
> lrelease from Python’s setup.py (though this package is pure Python, so it is
> not affected in any case).

I've seen packages that call lrelease directly from debian/rules. I'm
not sure how you use lrelease without qmake though. When qmake is
missing, lrelease prints

WARNING: Could not find qmake configuration file linux-g++.
lrelease error: cannot process project file '$PROJECT.pro'.

and exits successfully without having done the work it was tasked to do.
Given that it fails silently (in violation of policy 4.6), I cannot
easily detect them.

So I agree that you can run lrelease outside qmake, but that doesn't
mean that it actually works or does anything useful in the absence of
qmake.

> Do you have a list of packages where adding qt5-qmake:native will actually
> make them cross-buildable?

#889752 #896699 #901212 #920850

Helmut

Bug#921121: reported upstream

[franckr]

Hi Sven & Kathryn,

Sven, thanks for your workaround.
FYI regarding "Does anyone know how to contact the admins of this service?"
Someone reported the same issue to mozilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=1524830
Apparently it is more than just the aus server pointing to the wrong widevine 
version, it is firefox that do not fetch esr version.

Thus another workaround was proposed in above bugzilla report:
cd /usr/lib/firefox-esr/defaults/pref
  edit channel-prefs.js and change the line:
pref("app.update.channel", "default");
  to
pref("app.update.channel", "esr");
  then restart firefox.
It worked for me: 60.5.0esr-1~deb9u1 then automatically gets widevine 
4.10.1196.0 instead of 1.4.8.1008

Regards,
Franck

Bug#921604: RFP: python-srht-meta -- sr.ht core account services

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: python-srht-meta
  Version : 0.21.5
  Upstream Author : Drew DeVault ( @s...@cmpwn.com )
* URL : https://git.sr.ht/~sircmpwn/meta.sr.ht
* License : Affero GPLv3
  Programming Lang: python/javascript
  Description : sr.ht core account services

sr.ht account management & billing service.
ie you need an account, along with the core functionality to use any
of the sr.ht modules.

Bug#921583: apt: improper integration with package apt-listbugs

[Boruch Baum]

On 2019-02-07 11:25, Stuart Prescott wrote:
> Control: reassign -1 apt-listbugs 0.1.28
> Control: severity -1 wishlist
> Control: retitle -1 apt-listbugs: simplify wording for pinning description

> ...

> I've reassigned this bug to apt-listbugs as that is the appropriate
> package. If you can suggest an appropriate improvement to the wording
> of the above help text then that would be useful.

Well, since you asked ...

1) Maybe for the user prompt, adopt the style of 'reportbug'; something
   like:

   How to deal with the listed bugs [y|n|a|#..|p..|i..|w|?]?" Y

   This intentionally breaks the convention of upper-casing the default,
   since the default is written anyway, and because ...

2) My druthers would be for option 'a' to be made an upper-case 'I' and
   the unqualified option 'p' be made an upper-case 'P'.

3) If there already exists an option 'n' that can stop the APT
   installation, why can't an unqualified 'p' option do the same? What
   further operation are you expecting a user to do after 'p'? Requiring
   an extra manual step introduces an unnecessary opportunity for
   user-error, and introduces confusion of when and how to perform the
   abort.

4) The extended prompt, and the man page documentation, make it seem
   like pinning is done for all or none of a package's listed bugs; it's
   unclear whether in a case of two or more bugs being listed for a
   single package, if its possible to pin only a sub-set of the bug
   list, eg. 'p ' or 'p b'.

5) The 'p' option seems to be able to handle a list of packages, which
   is a nice convenience, but the parallel option 'i' isn't annotated
   that way.

6) There doesn't seem to be a command-line method to recover from a
   keying error or a decision-change regarding pinning or ignoring a bug
   - something like a 'u' option to undo a particular change, and a 'U'
   option to undo all changes. For those options to be practical, it
   would be useful to have yet another option 'R' to redisplay all bugs,
   including those prior marked 'ignored' or 'pinned'.

7) So your simple request did eventually get me here, with the following
   for the extended prompt, which definitely pre-supposes changes to
   option keys and functionality:

   | How to deal with the listed bugs [y|n|P|I|U|R|r|w|#..|p..|i..|u..|?]?" Y
   |
   | y - install anyway. Do not mark the bugs 'ignored'.
   | n - stop the APT installation.
   | P - pin all the listed bugs, and stop the APT install
   | I - continue the install. Mark the bugs 'ignored'.
   | U - remove all pins and ignore states.
   | r - redisplay the bug list
   | R - redisplay the bug list, with ALL pins and 'ignored' bugs.
   | w - redisplay the bug list in HTML
   | ? - redisplay this help.
   |
   |   In the following options  may be an entry b, a
   |   debian bug number  or #, or a package names. 
   |   may be a list of those, in any combination.
   |
   |  - display bug detail, using querybts
   | p   - pin pkgs (Later, you must select 'n' to enable this).
   | i   - ignore bugs on future APT runs.
   | u   - remove pin and 'ignore' states


Regards.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Bug#821397: Fwd: sway 1.0-rc1

[Sean Whitton]

Hello Birger,

On Wed 06 Feb 2019 at 12:00PM +01, Birger Schacht wrote:

> Forgot to cc the bugreport:
>
> Hi,
>
> On 2/6/19 7:41 AM, Birger Schacht wrote:
>> But both swayidle and swaylock don't depend on wlroots, so i can start
>> with those.
>
> thats now #921496 and #921497.

You need to set Maintainer: and Uploaders: to be the same as the sway
package, since we're doing a split.

I haven't done a full review yet.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#899984: sddm: Password automatically shown in clear at every user login

[tv.deb...@googlemail.com]

Hi, I got very surprised by this feature too, if you are using the 
"breeze" or "debian breeze" theme the little "eye" icon is hidden with 
the default theme. Try clicking at the very end (right) of the password 
field and you should be able to toggle password visibility.


Now I  am trying to reproduce this very hard, but I am convinced that 
some interaction with the keyboard (maybe a key-combo) also triggers the 
password visibility toggle, because I never touch my trackball at this 
point and was caught by this a few times before.


It happens regardless of the number of monitors connected for me, but 
with multiple screens the user is sometimes forced to click in the 
desired password field to make it active, thus increasing the risk of 
hitting the hidden "eye" icon. Very bad during a presentation...


Cheers.

Bug#921603: installation-reports: Buster installer fails to detect CD when installing from flash drive (USB)

[Carl Fink]

Package: installation-reports
Severity: important
Tags: d-i



-- Package-specific info:

Boot method: USB flash drive
Image version: Buster Alpha3 AMD64 (downloaded 7 February 2019), also 
unetbootin image downloaded 8 Feb
Date: 

Machine: Intel NUC8i5BEK
Partitions: 

root@debian-NUCi5:~# fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: CT1000MX500SSD4 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x073bcfcf

Device BootStartEndSectors   Size Id Type
/dev/sda1  *2048   58593279   5859123228G 83 Linux
/dev/sda2   58595326 1953523711 1894928386 903.6G  5 Extended
/dev/sda5   58595328   91865087   33269760  15.9G 82 Linux swap / Solaris
/dev/sda6   91867136 1953523711 1861656576 887.7G 83 Linux

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [E]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

I tried to install Debian on my Intel NUC.

First I used unetbootin to create a Testing (Buster) netinstall USB drive.

First of all, it's hard to get it to boot from a USB drive. You have to get
into the BIOS, which on this device by default is not prompted when you
power it up. You have to use Intel's secret handshake: turn off the NUC,
then hold the power button down for three (but not four!) seconds, which
gets you their special power-button menu, where you can turn on the BIOS
prompt (and also change the BIOS directly from that menu). You also have to
turn on legacy boot, of course, to boot from the USB drive.

... and when the installer got to installing kernel modules, it could not do
that because the kernel version on the downloadable image doesn't match the
version in the repository. I'm assuming this is a transient thing with this
particular weekly image.

So I downloaded the CD image, and used unetbootin to put that on the USB
key. Now the installer failed with the message that it could not mount the
install CD ... which was imaged onto the same USB drive I had just booted
from, so ... something weird there.

I flashed the Intel BIOS to the latest version. This had no effect I could
see.

Then I downloaded the DVD image and used K3B to burn THAT to a different 
Flash drive (I was wondering about a flaw in the drive I was using). Same 
error, could not mount the CD (despite having just read ITSELF off that 
same drive).

Finally, rather than try to figure out the installer issue, I dug out my DVD
burner (not used for over a year), burned an actual DVD image and plugged
the USB optical drive into the NUC, which detected it, and the install then
ran smoothly. (To clarify, I didn't reboot, the installer had run from the
USB drive, and then I plugged in the optical drive which was detected as
"the CD" (actually a DVD+RW).

The HDMI audio didn't work, but restarting PulseAudio fixed that.

Before anyone asks: yes, I'm going to submit this through reportbug. I
wanted this here as well, at least partly to help anyone experiencing the
same problems (since this mailing list is more likely to turn up in web
searches than Debian bug reports).




-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20190204-00:03:01"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux debian-NUCi5 4.19.0-2-amd64 #1 SMP Debian 4.19.16-1 
(2019-01-17) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3ed0] 
(rev 08)
lspci -knn: Subsystem: Intel Corporation Device [8086:2074]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device 
[8086:3ea5] (rev 01)
lspci -knn: Subsystem: Intel Corporation Device [8086:2074]
lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation Skylake 
Gaussian Mixture Model [8086:1911]
lspci -knn: Subsystem: Intel Corporation Device [8086:2074]
lspci -knn: 00:12.0 Signal processing controller [1180]: Intel Corporation 
Device [8086:9df9] (rev 30)
lspci -knn: Subsystem: Intel 

Bug#921600: docker.io: use of iptables-legacy is incompatible with nftables-based iptables

[Arnaud Rebillout]

  Hi,

did you report that issue upstream? I found a related thread at:

  https://github.com/moby/moby/issues/26824

This thread mentions a workaround: deactivate the iptables integration
via |--iptables=false| and then set the right rules for nftables by hand.

I'm not so really familiar with network filtering, but I think we can't
do much here, only upstream can work on that. Feel free to share your
use-case with them :)

  Arnaud

On 2/7/19 9:53 AM, brian m. carlson wrote:
> Package: docker.io
> Version: 18.09.1+dfsg1-5
> Severity: important
>
> I run Docker on my laptop to allow me to test various environments,
> such as Debian stable. I also use ufw to provide a firewall to restrict
> access to most ports.
>
> However, these two programs are incompatible. ufw uses the
> nftables-based iptables and restricts forwarding. Docker uses
> iptables-legacy, but because the nftables-based rules take precedence,
> forwarding doesn't occur, and hence networking is broken (TCP and UDP
> don't work).
>
> Since programs are going to increasingly use the regular iptables, it's
> important that Docker function with whatever option is the default.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
> (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages docker.io depends on:
> ii  adduser 3.118
> ii  iptables1.8.2-3
> ii  libc6   2.28-6
> ii  libdevmapper1.02.1  2:1.02.155-2
> ii  libltdl72.4.6-9
> ii  libnspr42:4.20-1
> ii  libnss3 2:3.42-1
> ii  libseccomp2 2.3.3-3
> ii  libsystemd0 240-5
> ii  lsb-base10.2018112800
> ii  runc1.0.0~rc6+dfsg1-1
> ii  tini0.18.0-1
>
> Versions of packages docker.io recommends:
> ii  ca-certificates  20190110
> ii  cgroupfs-mount   1.4
> ii  git  1:2.20.1+next.20190129-1
> pn  needrestart  
> ii  xz-utils 5.2.4-1
>
> Versions of packages docker.io suggests:
> pn  aufs-tools   
> pn  btrfs-progs  
> ii  debootstrap  1.0.114
> pn  docker-doc   
> ii  e2fsprogs1.44.5-1
> ii  rinse3.3
> pn  xfsprogs 
> pn  zfs-fuse | zfsutils  
>
> -- no debconf information
>

Bug#921602: Update biogenesis

[Alexey Loginov]

Package: biogenesis
Version: 0.8

There is biogenesis-0.9:
https://sourceforge.net/projects/biogenesis/files/biogenesis/0.9/
There is manual:
https://sourceforge.net/projects/biogenesis/files/user%20manuals/
If manual is installed, then it is available offline.

spec file: 
http://svnweb.mageia.org/packages/cauldron/biogenesis/current/SPECS/biogenesis.spec?view=markup

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

[Frank Heckenbach]

> > My suggestion of 2018-11-25 still stands. But if you want me to do
> > my part of it, please do your review quickly and tell me soon
> > (or, if it's indeed necessary for the soft freeze, immediately) to
> > avoid running out of time.
> 
> Your plan sounds OK.  Changing packages after the release, with time,
> should be OK.  I can submit automatic bug reports for the affected
> packages.

OK.

> Maybe it would even be possible to have the applications set a global
> variable, e.g.:
> 
>   enum class Render { Default = 1, Basic };
>   FTGL->setRender(Render  renderType);
> 
> and then the Render() function(s) would dispatch to either
> RenderDefault() or RenderBasic() versions as appropriate?

I generally don't much like global flags, but in this particular
case, it might be the least painful approach.

It wouldn't be foolproof. If two pieces of code, e.g. libraries,
that are used in the same program, use Render() with different
settings of this flag, one of them would do the wrong thing. (And
manually changing this flag every time code from the other library
may be used would be a maintenance nightmare.)

So maybe the following is even easier to implement, while also not
foolproof:

- No RenderDefault() and RenderBasic(), just Render() as is.

- A flag similar to your proposal (though I wouldn't actually call
  it "Render..."; if we aren't renaming the Render functions, we can
  use a more specific name), such as LegacyOpenGLState, and it can
  be a bool actually.

- However, ftgl will only allow setting this flag to one value ever
  (but any number of times, so libraries that expect the same
  setting can work together). I.e., if it's set to false, further
  calls setting it to false will succeed, but a call setting it to
  true will abort, indicating a mix of incompatible code pieces; and
  vice versa.

  If it's never set, if will default to true (legacy behaviour);
  I'll have to accept that.

- In my code I'll set it to false; likewise for others relying on
  this behaviour. (My code actually contains libraries using ftgl,
  so I'll make sure to set it from within the libraries, rather than
  the programs using them.)

- Programs relying on the "old" behaviour need no change
  immediately, but should soon (so for Debian, after the release of
  Buster), add a "true" call. This would be a single line change
  near the start, so easy to do even if it affects a number of
  packages.

- Both kinds of program will need to require ftgl>=2.4.0 because of
  the new call.

- Sometime in the future, I hope I can require setting this flag,
  first with a warning, later with an error if it's not set before
  the first rendering. Provided you've added the call to all
  packages by then, nothing will break.

Cheers,
Frank

Bug#917582: Please prevent autoremoval of freedombox

[Sunil Mohan Adapa]

Hello,

The two bugs #917582 and #917584 are threatening removal of freedombox
from testing. As soft freeze is fast approaching, and once removed, we
won't be able to add freedombox back into buster. Please consider
uploading soon the newer upstream 0.9.0 which will hopefully eliminate
the two bugs.

Thank you,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#921601: ITP: terminus -- Drop-down or in-window terminal for X11 and Wayland

[Barak A. Pearlmutter]

Package: wnpp
Owner: Barak A. Pearlmutter 
Severity: wishlist

* Package name: terminus
  Version : 1.3.0
  Upstream Author : Sergio Costas 
* URL or Web page : https://gitlab.com/rastersoft/terminus
* License : GPL-3.0+
  Description : Drop-down or in-window terminal for X11 and Wayland
 This is a new-generation (post-Guake) terminal for X11 and Wayland,
 which features a hot-key Quake-console-like drop-down mode.  Other
 features include a scroll-back buffer, tabs, split screen both
 horizontal and vertical, and the usual compatibility features.

Bug#921600: docker.io: use of iptables-legacy is incompatible with nftables-based iptables

[brian m. carlson]

Package: docker.io
Version: 18.09.1+dfsg1-5
Severity: important

I run Docker on my laptop to allow me to test various environments,
such as Debian stable. I also use ufw to provide a firewall to restrict
access to most ports.

However, these two programs are incompatible. ufw uses the
nftables-based iptables and restricts forwarding. Docker uses
iptables-legacy, but because the nftables-based rules take precedence,
forwarding doesn't occur, and hence networking is broken (TCP and UDP
don't work).

Since programs are going to increasingly use the regular iptables, it's
important that Docker function with whatever option is the default.

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

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

Versions of packages docker.io depends on:
ii  adduser 3.118
ii  iptables1.8.2-3
ii  libc6   2.28-6
ii  libdevmapper1.02.1  2:1.02.155-2
ii  libltdl72.4.6-9
ii  libnspr42:4.20-1
ii  libnss3 2:3.42-1
ii  libseccomp2 2.3.3-3
ii  libsystemd0 240-5
ii  lsb-base10.2018112800
ii  runc1.0.0~rc6+dfsg1-1
ii  tini0.18.0-1

Versions of packages docker.io recommends:
ii  ca-certificates  20190110
ii  cgroupfs-mount   1.4
ii  git  1:2.20.1+next.20190129-1
pn  needrestart  
ii  xz-utils 5.2.4-1

Versions of packages docker.io suggests:
pn  aufs-tools   
pn  btrfs-progs  
ii  debootstrap  1.0.114
pn  docker-doc   
ii  e2fsprogs1.44.5-1
ii  rinse3.3
pn  xfsprogs 
pn  zfs-fuse | zfsutils  

-- no debconf information

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#900241: no root.key provided by libunbound2

[Simon Deziel]

On 2019-01-20 3:59 p.m., Ondřej Surý wrote:
> That seems overly complicated for a little gain. dns-root-data has the 
> current root key and keeps it up-to-date for all DNS related packages.

Here's a much simpler fix:

https://salsa.debian.org/dns-team/unbound/merge_requests/4

Regards,
Simon

Bug#792490: [Pkg-openssl-devel] Bug#792490: openssl s_client doesn't allow for certificate pinning anymore!

[Jean-Marc]

On Mon, 7 Sep 2015 15:24:33 +0200 Kurt Roeckx  wrote:
> On Mon, Sep 07, 2015 at 02:56:44PM +0200, Florent Daigniere wrote:
> > 
> > Agreed. The catch is that it's useless as a debugging tool too with the
> > new behaviour (see bug #792396). There's no indication whatsoever that
> > the system's CA path has been added to the certificate chain... and the
> > manual goes as far as suggesting that it isn't:
> > 
> > "   
> > -CApath directory
> > The directory to use for server certificate verification. [...]
> > "

The bug reports a problem because "openssl s_client is not providing any way to 
disregard the system's trusted CAs anymore" found in version openssl/1.0.2d-1.

I tested the option -no-CApath on a Debian stable (openssl 1.1.0j-1~deb9u1) and 
on a Debian testing/sid (openssl 1.1.1a-1) and it forced openssl to disregard 
the local system's CAs.

Can you tell me if this is what you are looking for ?

In this case, we can maybe ask to close this bug.

Regards,

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


pgpY4sc1b3lAD.pgp
Description: PGP signature

Bug#921598: No METAR available since noaa.gov switched to https

[Gabriel F. T. Gomes]

Package: flightgear
Version: 1:2018.3.2+dfsg-2

Dear maintainers,

Very recently, noaa.gov switched to https, which makes flightgear unable
to download METAR data, thus unable to provide 'live' weather conditions
for the simulation.

I have created a merge request on salsa [1] with a possible, albeit not
ideal, solution to the problem.  Since this is about a hardcoded URL in
the source, which might potentially require rebuilds, and since we are
close to the freeze for buster, I decided to share this with you sooner
than later, so that you have more time to evaluate.

(as noted in the merge request, the flightgear forum has suggestions of
fixes that do not require a rebuild, but I haven't checked that they
actually work.  I did check that the merge request fixes the problem)

[1] https://salsa.debian.org/debian/flightgear/merge_requests/1

Bug#921599: python-mysqldb: always connects to localhost ignoring host entry in option file

[Alan Krempler]

Package: python-mysqldb
Version: 1.3.10-2
Severity: normal

When connecting like this:
connection = MySQLdb.connect(read_default_file=dbconfig)
lines in the option file specifying a remote host are ignored.
Whatever host is specified in the option file, python-mysqldb always attempts a
connection to localhost.

Named host parameters to MySQLdb.connect() are handled correctly.

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

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

Versions of packages python-mysqldb depends on:
ii  libc62.28-5
ii  libmariadb3  1:10.3.12-2
ii  libssl1.11.1.1a-1
ii  python   2.7.15-4
ii  zlib1g   1:1.2.11.dfsg-1

python-mysqldb recommends no packages.

Versions of packages python-mysqldb suggests:
ii  mariadb-server-10.3 [virtual-mysql-server]  1:10.3.12-2
pn  python-egenix-mxdatetime
pn  python-mysqldb-dbg  

-- no debconf information

Bug#921597: RFP: libtimidity -- MIDI to WAVE converter library

[Nikolas Nyby]

Package: wnpp
Severity: wishlist

* Package name: libtimidity
  Version : 0.2.6
  Upstream Author : Ozkan Sezer 
* URL : https://sourceforge.net/projects/libtimidity/
* License : LGPL
  Programming Lang: C
  Description : MIDI to WAVE converter library

This library is based on the TiMidity decoder from SDL_sound library.
Purpose to create this library is to avoid unnecessary dependences.
SDL_sound requires SDL and some other libraries, that not needed to
process MIDI files. In addition libTiMidity provides more suitable
API to work with MIDI songs, it enables to specify full path to the
timidity configuration file, and have function to retrieve meta data
from MIDI song.


This library was active 15 years ago, and has recently seen new activity
with a string of new releases over the past year.

Some packages already in Debian's collection would find this useful.
OpenTTD is one example.

I'm looking for a maintainer, but if no one is interested I can be the
maintainer.

Bug#921596: capstone: new upstream version 4.0.1

[Jan Nordholz]

Source: capstone
Version: 3.0.5-3
Severity: minor

Hi,

I know, it's a bad time to do SONAME bumping, but maybe this could at least
hit experimental (it has to go through NEW anyway), so people could grab it
from there if they wanted to? There's at least one annoying bug affecting
radare2 via libcapstone that's been fixed upstream months ago.

Anyway, I've prepared a tentative new version here[1], featuring:
  - library version bump (libcapstone3 -> libcapstone4)
  - fixed last changelog entry to make Lintian happy
  - added a simple manpage for cstool based on its '--help'
  - refreshed patch
  - disabled a new extensive test that's run as part of 'make check' which
appears to require an external(?) fuzzing data corpus

The whole thing is now lintian-clean as far as I can tell. Additionally,
I've test-built and test-run radare2 (deb), seems fine. Qemu (upstream HEAD)
doesn't build with capstone4 due to a positive change in capstone's pkgconfig
file, but it's trivial to fix - see this gem[2] for the explanation.

I'm sorry for not honoring the new git-based packaging workflow, but when I
last did package maintenance, that wasn't a thing yet, and I can't afford
the time to dive into that right now. I hope you can interpolate from my dsc.

Thanks for considering

Jan

[1]: https://mc.svnsa.tu-berlin.de/deb/capstone_4.0.1-1.dsc
[2]: https://github.com/radare/radare2/blob/master/doc/capstone.md
-- 
Prof. Dr.-Ing. Jan Nordholz 
Sichere und vertrauenswürdige netzangebundene Systemarchitekturen
Technische Universität Berlin / Physikalisch-Technische Bundesanstalt

Bug#921595: man alsa-info.sh --> man alsa-info

[積丹尼 Dan Jacobson]

Package: alsa-utils
Version: 1.1.7-1
File: /usr/share/man/man1/alsa-info.sh.1.gz

This man page's filename and its contents must have ".sh" removed,
to match what is in /usr/sbin. P.S., those are also put in section 8 of
the manual, not section 1.

Bug#921594: /etc/etc/ImageMagick-6

[積丹尼 Dan Jacobson]

Package: imagemagick-6-common

Today I found

  /etc/etc/ImageMagick-6:
  drwxr-xr-x 2 root   4096 2016-01-05  .
  drwxr-xr-x 3 root   4096 2016-01-05  ..
  -rw-r--r-- 1 root842 2015-12-29  coder.xml
  -rw-r--r-- 1 root   1383 2015-12-29  colors.xml
  -rw-r--r-- 1 root  14432 2015-12-29  delegates.xml
  -rw-r--r-- 1 root956 2015-12-29  log.xml
  -rw-r--r-- 1 root888 2015-12-29  magic.xml...

Can I safely remove it?
Why not have a dpkg conf script that cleans it up?

Bug#921593: bibtex2html should transate math characters with overhead accents

[James Van Zandt]

Package: bibtex2html
Version: 1.99-2.1
Severity: wishlist
Tags: upstream

Dear Maintainer,

I wish bibtex2html could translate math characters that have accents.

In my .bib collection, I have a few abstracts with math characters
that have accents.  One such document is at
http://arxiv.org/pdf/1508.04874v1.pdf.  Here's a sample .bib entry for
it, with an abridged abstract:

@Misc{   lee-sidford-wong15cutting,
  author = {Yin Tat Lee and Aaron Sidford and Sam Chiu-wai Wong},
  title = {A Faster Cutting Plane Method and its Implications
  for Combinatorial and Convex Optimization},
  eprinttype =   {arxiv},
  eprint =   {1508.04874v1},
  url =  {http://arxiv.org/pdf/1508.04874v1.pdf},
  month = aug,
  year = 2015,
  abstract = {We obtain a running time of $\tilde O ( n ( n^2 +
  m^\omega + S ))$, improving upon the previous best
  of $\tilde O ( n ( n^\omega + m^\omega + S ))$ for
  the regime $S$ is small.},
  pdf =   {lee-sidford-wong15cutting.pdf}
}

Unicode can add bars and such over characters, using characters with
combining class "above".  In TeX, the accent macro precedes the base
character, while the Unicode combining character must follow the base
character.  I think these TeX macro definitions should accomplish the
exchange:

\def\overleftarrow#1{#1⃖}  % over left arrow  U+20d6
\def\overrightarrow#1{#1⃗} % over right arrow U+20d7
\def\bar#1{#1̅}% overbar accent   U+0305
\def\tilde#1{#1̃}  % tilde accent U+0303

However none of these actually work because ``bibtex2html does not
handle macros arguments; arguments are simply discarded.''

I think the translations could be done with ocaml, but I'm not even
sure how to spell that.

Please ask the upstream author(s) to consider implementing translations for
accented math characters.

  - Jim Van Zandt


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

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

Versions of packages bibtex2html depends on:
ii  ocaml-base-nox [ocaml-base-nox-4.05.0]  4.05.0-11
ii  perl5.28.1-4
ii  texlive-base2018.20190131-1

bibtex2html recommends no packages.

Versions of packages bibtex2html suggests:
pn  hlins  

-- no debconf information

Bug#921591: RM: nwchem freemat wsjtx [kfreebsd-amd64] -- RoQA; Out of date, required for gcc-6 removal

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

See subj.

Bug#921592: RM: herwig++ pdl herwig++-dev libpdl-graphics-gnuplot-perl libpdl-io-hdf5-perl libpdl-io-matlab-perl libpdl-linearalgebra-perl libpdl-netcdf-perl libpdl-stats-perl libtfbs-perl [kfreebsd-i

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

See subj.

Bug#921587: RM: libgretl1 libgnatcoll-sqlite-bin libgnatcoll-sqlite-bin [hurd-i386] -- RoQA; Out of date, required for gcc-6 removal

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

See subj.

Bug#921590: xen-utils-4.11: pygrub bails out with "ImportError: No module named fsimage"

[Axel Beckert]

Package: xen-utils-4.11,xen-utils-common
Version: 4.11.1-1
Severity: serious
Control: affects -1 xen-tools

Hi,

both, /usr/lib/xen-4.11/bin/pygrub as well as /usr/bin/pygrub bail out
for me as follows on Buster:

# /usr/bin/pygrub
Traceback (most recent call last):
  File "/usr/bin/pygrub", line 23, in 
import fsimage
ImportError: No module named fsimage

This is a regression from Stretch and breaks many DomUs after upgrade as
well as most DomUs generated with xen-tools' defaults (which uses
pygrub). It especially severly harms the release testing for the
xen-tools pending 4.8 release. :-(

This seems related (and partially mentioned), but not identical to
#912441 as pygrub is present for me, just not working at all. Which
means: This bug report is about pygrub being present, but completely
broken.

There aren't many differences between pygrub in Stretch and Buster:

1c1
< #! /usr/bin/python2.7
---
> #! /usr/bin/python
22,23d21
< 
< sys.path.insert(1, sys.path[0] + '/../lib/python')

That's all differences.

The latter removal of a search path is very likely the reason for this
issue. (Already hinted towards that in #912441, too.)

As a (very ugly) workaround I tried to copy over pygrub from a Stretch
Dom0, i.e. from xen-utils-4.8, but this helped only partially:

# pygrub
Traceback (most recent call last):
  File "/usr/bin/pygrub", line 25, in 
import fsimage
ImportError: libfsimage.so: cannot open shared object file: No such file or 
directory

Note the different error message on the last line. Now it doesn't find
libfsimage.so.

"strace /usr/lib/xen-4.11/bin/pygrub" reveals that pygrub from
xen-utils-4.8, when copied onto a Buster system, indeed tries to access
that /usr/lib/xen-4.11/lib/python/fsimage.so, just doesn't use it:

# strace /usr/lib/xen-4.11/bin/pygrub |& fgrep -A20 lib/python/fsimage.so 
--color
openat(AT_FDCWD, "/usr/lib/xen-4.11/bin/../lib/python/fsimage.so", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=16128, ...}) = 0
openat(AT_FDCWD, "/usr/lib/xen-4.11/bin/../lib/python/fsimage.so", 
O_RDONLY|O_CLOEXEC) = 4
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\21\0\0\0\0\0\0"..., 
832) = 832
fstat(4, {st_mode=S_IFREG|0644, st_size=16128, ...}) = 0
mmap(NULL, 18352, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7f1af1082000
mmap(0x7f1af1083000, 4096, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1000) = 0x7f1af1083000
mmap(0x7f1af1084000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 
0x2000) = 0x7f1af1084000
mmap(0x7f1af1085000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0x7f1af1085000
close(4)= 0
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=49493, ...}) = 0
mmap(NULL, 49493, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7f1af0f92000
close(4)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/x86_64/x86_64/libfsimage.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib/x86_64-linux-gnu/tls/x86_64/x86_64", 0x7fff92e70430) = -1 ENOENT (No 
such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/x86_64/libfsimage.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib/x86_64-linux-gnu/tls/x86_64", 0x7fff92e70430) = -1 ENOENT (No such 
file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/x86_64/libfsimage.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib/x86_64-linux-gnu/tls/x86_64", 0x7fff92e70430) = -1 ENOENT (No such 
file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/libfsimage.so", O_RDONLY|O_CLOEXEC) 
= -1 ENOENT (No such file or directory)
stat("/lib/x86_64-linux-gnu/tls", 0x7fff92e70430) = -1 ENOENT (No such file or 
directory)

Reason for this seems to be that the linker doesn't find libfsimage.so:

# ldd /usr/lib/xen-4.11/lib/python/fsimage.so
linux-vdso.so.1 (0x7fff1bbb5000)
libfsimage.so => not found
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f657bd3a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f657bb72000)
/lib64/ld-linux-x86-64.so.2 (0x7f657bd7a000)

What finally works is using pygrub from Stretch _and_ setting
LD_LIBRARY_PATH=/usr/lib/xen-4.11/lib/x86_64-linux-gnu:

# env LD_LIBRARY_PATH=/usr/lib/xen-4.11/lib/x86_64-linux-gnu pygrub
Usage: /usr/bin/pygrub [-q|--quiet] [-i|--interactive] [-l|--list-entries] 
[-n|--not-really] [--output=] [--kernel=] [--ramdisk=] [--args=] [--entry=] 
[--output-directory=] [--output-format=sxp|simple|simple0] [--offset=] 

So using that LD_LIBRARY_PATH when calling xl and the pygrub from
stretch, I can boot pygrub/grub-legacy based DomUs again.

Even if this doesn't affect the general usage of Xen, this is a severe
regression from Stretch and needs to be fixed for Buster. Hence the RC

Bug#921588: RM: libmagplus3v5 magics++ python-magics++ python3-magics++ cdo libmagics++-dev libmagics++-metview-dev python-cdo python3-cdo [hurd-i386 kfreebsd-amd64 kfreebsd-i386] -- RoQA; Out of date

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

See subj

Bug#921589: RM: metview [kfreebsd-amd64 kfreebsd-i386] -- RoQA; Out of date, required for gcc-6 removal

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

See subj.

Bug#920406: RFA: pymacs -- interface between Emacs Lisp and Python

[eamanu15]

Control: retitle -1 ITA: pymacs -- interface between Emacs Lisp and Python

Control owner -1 emmanuelaria...@gmail.com

I would like to adopt this package

Thanks!
Regards

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

Bug#849841: Facing same error

[Khaled Z Mahmoud]

I am not sure what is going wrong  Can you confirm this is solved ?

uname -a : Linux david 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6 
(2018-10-08) x86_64 GNU/Linux

dpkg -l |grep linux-image
rc  linux-image-4.9.0-4-amd64 4.9.65-3+deb9u1   
amd64Linux 4.9 for 64-bit PCs
ii  linux-image-4.9.0-6-amd64 4.9.88-1+deb9u1   
amd64Linux 4.9 for 64-bit PCs
ii  linux-image-4.9.0-8-amd64 4.9.110-3+deb9u6  
amd64Linux 4.9 for 64-bit PCs
ii  linux-image-amd64 4.9+80+deb9u6 
amd64Linux for 64-bit PCs (meta-package)

Bug#921586: RFS: pymacs/0.25-1.2 [ITA]

[eamanu15]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: pymacs
 Version : 0.25-1.2
 Upstream Author : François Pinard 
* URL : http://pymacs.progiciels-bpi.ca/
* License : GPL-2+
 Section : python

It builds those binary packages:

  pymacs - interface between Emacs Lisp and Python

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

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


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

  dget -x
https://mentors.debian.net/debian/pool/main/p/pymacs/pymacs_0.25-1.2.dsc

More information about pymacs can be obtained from
http://pymacs.progiciels-bpi.ca/

Changes since the last upload:

[Ondřej Nový]
* Fixed VCS URL (https)
* d/control: Set Vcs-* to salsa.debian.org
* d/copyright: Use https protocol in Format field
* d/control: Remove ancient X-Python-Version field
* Convert git repository from git-dpm to gbp layout

[Emmanuel Arias]
* New Maintainer. Closes (#920406).
  - Update d/control. Add me to Uploaders field.
  - Update d/contorl. Add DPMT to Maintainer field.
* Update d/control.
  - Bump debhelper compatibility to debhelper-compat 11
(from 8).
* Delete d/compat file. This is becauase on d/control
  is set debhelper-compat on version 12.
* Update d/copyright file. Add me on debian/* files copyright.
* Update d/rules. Modify delete --list-missing
  from dh_install from override_dh_install. And add a
  override_dh_missing target where add dh_missing --list-missing
* Bump Standards-Version to 4.3.0 (from 3.9.5)


Regards,
Emmanuel Arias

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

Bug#883826: Intent to initiate a L10N-NMU for libvisual-plugins on/after 2019-02-01

[Eriberto]

Em sáb, 2 de fev de 2019 às 06:28, Helge Kreutzmann
 escreveu:
>
> Is the patch understandable? Or should I proceed with an NMU and you
> pick it up afterwards?
>
> (Due to the approaching freeze an upload in the next days is
> necessary).

Hi Helge,

Sorry for my delay. I am preparing the package to upload in few minutes.

Thanks for your help.

Regards,

Eriberto

Bug#921585: "wdiff -d" output is incorrect

[Vincent Lefevre]

Control: tags -1 upstream

I've reported the bug upstream.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

[Manuel A. Fernandez Montecelo]

Em qua, 6 de fev de 2019 às 04:15, Frank Heckenbach
 escreveu:
>
> > Em qui, 3 de jan de 2019 às 22:56, Frank Heckenbach
> >  escreveu:
> > >
> > > According to https://release.debian.org/buster/freeze_policy.html:
> > >
> > > 2019-01-12 - Transition freeze
> > >
> > > Is there still time yet to get a fix in, or is it FUBAR already?
> >
> > Transition freeze means ABI changes in libraries are forbidden.  We're
> > almost in soft-freeze now, more info at:
> > https://lists.debian.org/debian-devel-announce/2019/01/msg8.html
>
> So do we have time until the soft freeze on 2019-02-12 (I hope not)
> or the full freeze (2019-03-12) to get a 2.4.0 uploaded?

I believe so, yes, maybe even for the soft freeze (I am not sure how
much the time shortens for migrating packages fixing important bugs,
it varies).


> > I have to review the situation again, I completely swapped it out of
> > my memory.
>
> My suggestion of 2018-11-25 still stands. But if you want me to do
> my part of it, please do your review quickly and tell me soon
> (or, if it's indeed necessary for the soft freeze, immediately) to
> avoid running out of time.

Your plan sounds OK.  Changing packages after the release, with time,
should be OK.  I can submit automatic bug reports for the affected
packages.

Maybe it would even be possible to have the applications set a global
variable, e.g.:

  enum class Render { Default = 1, Basic };
  FTGL->setRender(Render  renderType);

and then the Render() function(s) would dispatch to either
RenderDefault() or RenderBasic() versions as appropriate?


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#921583: apt: improper integration with package apt-listbugs

[Stuart Prescott]

Control: reassign -1 apt-listbugs 0.1.28
Control: severity -1 wishlist
Control: retitle -1 apt-listbugs: simplify wording for pinning description

Hi Boruch,

> Today, when I performed 'apt-get upgrade', apt correctly invoked
> apt-listbugs, notified me of a grave bug in a package, and asked me if I
> wanted to continue. When I said no, it exited.
> 
> This is a bug.
> 
> If apt is going to integrate apt-listbugs (which it has decided to do),

This isn't quite correct btw. apt-listbugs has added itself to your apt 
configuration. There are lots of packages that can do that and bugs in them 
are not bugs in apt.

> it should remove the noted package (and any sole dependencies) from
> the list of packages to be upgraded in the current go, and proceed, or
> not, based upon the user's answer to the usual prompt. Apt should not
> abort the entire install because an objection to a single package.

This is not quite correct. apt-listbugs has the functionality you request:

Are you sure you want to install/upgrade the above packages? [Y/n/?/...] ? 
y - continue the APT installation, but do not mark the bugs 
as ignored. 
a - continue the APT installation and mark all the above bugs 
as ignored. 
n - stop the APT installation. 
 - query the specified bug number 
(uses querybts as user stuart). 
 #   - same as . 
  b   - same as , but query the bug identified by . 
r - redisplay bug lists. 
p  - pin pkgs (restart APT session to enable). 
p - pin all the above pkgs (restart APT session to enable). 
i- mark bug number  as ignored. 
i b   - mark the bug identified by  as ignored. 
? - print this help. 
w - display bug lists in HTML 

(you want p)

Yes, this requires the user to know a bit about apt, but so does running 
unstable.

I've reassigned this bug to apt-listbugs as that is the appropriate package. 
If you can suggest an appropriate improvement to the wording of the above help 
text then that would be useful.

regards
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#867290: ITP: libjs-blueimp-md5 -- MD5 implementation in JavaScript

[Jonas Smedegaard]

Quoting Johannes Schauer (2017-07-05 16:28:20)
> Package: wnpp
> Severity: wishlist
> Owner: Johannes Schauer 
> 
> * Package name: libjs-blueimp-md5
>   Version : 2.7.0
>   Upstream Author : Sebastian Tschan 
> * URL : https://github.com/blueimp/JavaScript-MD5
> * License : Expat
>   Programming Lang: JavaScript
>   Description : MD5 implementation in JavaScript
> 
> An implementation of the MD5 hash function in JavaScript. Works
> client-side as well as in server-side environments like Node.js.
> 
> The janus-demos package is currently in contrib because
> libjs-blueimp-md5 is not yet packaged for Debian. Packaging
> libjs-blueimp-md5 gets us one step closer to moving janus-demos into
> main.

Seems we'll have to wait for Bullseye to get janus-demos into main.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#867288: ITP: libjs-toastr -- Javascript library for non-blocking notifications

[Jonas Smedegaard]

Quoting Johannes Schauer (2017-07-05 16:13:50)
> Package: wnpp
> Severity: wishlist
> Owner: Johannes Schauer 
> 
> * Package name: libjs-toastr
>   Version : 2.1.3
>   Upstream Author : John Papa , Tim Ferrell 
> 
> * URL : http://codeseven.github.io/toastr/
> * License : Expat
>   Programming Lang: JavaScript
>   Description : Javascript library for non-blocking notifications
> 
> A client-side jQuery based JavaScript library providing temporary,
> non-blocking pop-up notifications. These can be used to display brief,
> auto-expiring windows of information like notifications, warnings or
> errors to the user of a web application.
> 
> The janus-demos package is currently in contrib because libjs-toastr is
> not yet packaged for Debian. Packaging libjs-toastr gets us one step
> closer to moving janus-demos into main.

Seems we'll have to wait a couple more years to get janus-demos in main.


 - Jonas


-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#921584: Free the results when QSqlQuery::finished() is called

[Sandro Knauß]

Ah short report, why those patches are needed. 

Without the patches all DB requests will pile up in RAM and Akonadi will use 
more and more RAM with time. Keeping the query around in the caches cause them 
to use insane amount of memory, if the last query happened to return a lot of 
results.

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

Bug#921284: build-using should only include copylefted files

[Michael Hudson-Doyle]

On Thu, 7 Feb 2019 at 04:09, Antoine Beaupré  wrote:

> On 2019-02-03 17:21:35, Antoine Beaupre wrote:
> > My first submissions for the dmarc-cat package (#920385) were refused
> > by the FTP masters because the built-using field did not respect §7.8
> > of the Debian policy.
>
> That's actually inaccurate: the package was refused because the
> dependencies specified in `built-using` were missing and indeed, one of
> the dependencies hadn't passed NEW when dmarc-cat was uploaded. For
> example, here's the last REJECTION I had:
>
> An exception was raised while processing the package:
> Traceback (most recent call last):
>   File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 109,
> in wrapper
> function(upload, srcqueue, comments, transaction)
>   File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 222,
> in comment_accept
> extra_archives=[upload.target_suite.archive],
>   File "/srv/ftp-master.debian.org/dak/dak/daklib/archive.py", line 451,
> in copy_binary
> self._ensure_extra_source_exists(filename, db_source, archive,
> extra_archives=extra_archives)
>   File "/srv/ftp-master.debian.org/dak/dak/daklib/archive.py", line 245,
> in _ensure_extra_source_exists
> raise ArchiveException('{0}: Built-Using refers to package {1} (= {2})
> not in target archive {3}.'.format(filename, source.source, source.version,
> archive.archive_name))
> ArchiveException: d/dmarc-cat/dmarc-cat_0.9.1-1_amd64.deb: Built-Using
> refers to package golang-github-ivpusic-grpool (= 1.0.0-1) not in target
> archive ftp-master.
>
> When grpool was ACCEPTED, dmarc-cat also was ACCEPTED by the
> FTP-masters. So this is not a blocker for the FTP masters.
>
> > Extract from #debian-ftp:
> >
> > 16:55:59  Built-Using is only meant to be used when the result
> is GPL/MPL/similar and you've statically linked (/bundled) another source
> package
> > 16:56:33  okay, so to comply with licensing issues?
> > 16:56:47  it also seems useful to track rdeps for golang as
> well, no?
> > 16:57:03  no, built-using is _not_ for tracking dependencies
> > 16:57:10  it is for license compliance
> > 16:57:26  and bsd licensed software does not require that
> >
> > So in the case of dmarc-cat, dependencides like
> > golang-github-stretchr-testify-dev should actually not be listed in
> > the Built-Using field.
>
> It's true, however, that the Debian policy specifies built-using is for
> copyright reasons.
>
>
> https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using
>
> Specifically, the last pargraph reads:
>
> > This field should not be added solely for purposes other than
> > satisfying license or DFSG requirements to provide full source
> > code. In particular, it should not be added solely to enable finding
> > packages that should be rebuilt against newer versions of their build
> > dependencies.
>
> Yet, from what I understand, that is *exactly* how that field is used in
> the golang team. Is that correct?
>
> It should be noted this is a SHOULD NOT and not a MUST NOT, so it's a
> little more relaxed - may we are allowed to abuse it like this.
>
> I do wonder if it's deliberate, however. It seems to me this should be
> clarified, both in dh-golang and in policy, either way.
>

It's a pretty recent change in policy to clarify that how go packages use
it is not the intended use. When go packages started using Built-Using,
they were 100% compliant with the wording (if not the intent) of policy :)

Cheers,
mwh

Bug#921535: Some patches for Akonadi

[Sandro Knauß]

Ah short report, why those patches are needed. 

Without the patches all DB requests will pile up in RAM and Akonadi will use 
more and more RAM with time. Keeping the query around in the caches cause them 
to use insane amount of memory, if the last query happened to return a lot of 
results.


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

Bug#921585: "wdiff -d" output is incorrect

[Vincent Lefevre]

Package: wdiff
Version: 1.2.2-2+b1
Severity: normal

On the diff file (also attached)

--- a
+++ b
@@ -1,7 +1,6 @@
 1a
 2a
 3a
-c e f g h i j k l m n o
 5a
 6a
 7a
@@ -9,6 +9,7 @@
 1b
 2b
 3b
+c d e f g h i j k l m n p
 5b
 6b
 7b

the command "wdiff -d" outputs

[--- a-]{+++ b+}
@@ -1,7 +1,6 @@
1a
2a
3a
{+5a
6a
7a
@@ -9,6 +9,7 @@
1b
2b
3b+}
c {+d+} e f g h i j k l m n [-o
5a
6a
7a
@@ -9,6 +9,7 @@
1b
2b
3b-] {+p+}
5b
6b
7b

and "wdiff -n -d" outputs

[--- a-]{+++ b+}
@@ -1,7 +1,6 @@
1a
2a
3a
{+5a+}
{+6a+}
{+7a+}
{+@@ -9,6 +9,7 @@+}
{+1b+}
{+2b+}
{+3b+}
c {+d+} e f g h i j k l m n [-o-]
[-5a-]
[-6a-]
[-7a-]
[-@@ -9,6 +9,7 @@-]
[-1b-]
[-2b-]
[-3b-] {+p+}
5b
6b
7b

which are both invalid (as "@@ -9,6 +9,7 @@" is regarded as text)
instead of

[--- a-]{+++ b+}
@@ -1,7 +1,6 @@
1a
2a
3a
[-c e f g h i j k l m n o-]
5a
6a
7a
@@ -9,6 +9,7 @@
1b
2b
3b
{+c d e f g h i j k l m n p+}
5b
6b
7b

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

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

Versions of packages wdiff depends on:
ii  libc6  2.28-5
ii  libtinfo6  6.1+20181013-1

wdiff recommends no packages.

Versions of packages wdiff suggests:
ii  wdiff-doc  1.2.2-2

-- no debconf information
--- a
+++ b
@@ -1,7 +1,6 @@
 1a
 2a
 3a
-c e f g h i j k l m n o
 5a
 6a
 7a
@@ -9,6 +9,7 @@
 1b
 2b
 3b
+c d e f g h i j k l m n p
 5b
 6b
 7b

Bug#921583: apt: improper integration with package apt-listbugs

[Boruch Baum]

Subject: apt: improper integration with package apt-listbugs
Package: apt
Version: 1.8.0~rc2
Severity: normal

Dear Maintainer,

Today, when I performed 'apt-get upgrade', apt correctly invoked
apt-listbugs, notified me of a grave bug in a package, and asked me if I
wanted to continue. When I said no, it exited.

This is a bug.

If apt is going to integrate apt-listbugs (which it has decided to do),
it should remove the noted package (and any sole dependencies) from
the list of packages to be upgraded in the current go, and proceed, or
not, based upon the user's answer to the usual prompt. Apt should not
abort the entire install because an objection to a single package.


-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 2.0.0 (ascii)
Release:2.0.0
Codename:   ascii
Architecture: x86_64

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

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2018.1
ii  gpgv2.2.12-1
ii  libapt-pkg5.0   1.8.0~beta1
ii  libc6   2.28-5
ii  libgcc1 1:8.2.0-15
ii  libgnutls30 3.6.6-2
ii  libseccomp2 2.3.3-3
ii  libstdc++6  8.2.0-15

Versions of packages apt recommends:
ii  ca-certificates  20190110

Versions of packages apt suggests:
iu  apt-doc 1.8.0~rc2
ii  aptitude0.8.11-6
ii  dpkg-dev1.19.4
ii  gnupg   2.2.12-1
ii  gnupg2  2.2.12-1
ii  powermgmt-base  1.33
ii  synaptic0.84.5

-- no debconf information




-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Bug#921195: mcabber: does not connect to Jabber via IPv6 (fails Etch release goal)

[W. Martin Borgert]

Control: reassign -1 libloudmouth1-0
Control: retitle -1 libloudmouth1-0: does not support IPv6 (fails Squeeze 
release goal)
Control: tag -1 + patch

On 2019-02-03 09:32, W. Martin Borgert wrote:
> I'm in the same network, and mcabber works for me.

After testing again, I believe, that my computer just
re-connected to the other (IPv4-capable) network.

With this commit (patch applies), IPv6 seems to work:

https://github.com/mcabber/loudmouth/commit/95078ef12ab30735b4280675837c64686cf9faaa

Bug#921582: RFP: node-stream-spec -- executable specification for stream

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-stream-spec
  Version : 0.3.6
  Upstream Author : Dominic Tarr 
* URL : https://notabug.org/makenotabuggreatagain/stream-spec
* License : MIT
  Programming Lang: javascript
  Description : executable specification for stream

Automatic checking of the Stream implementations. stream-spec 
instruments your stream to verify that it has correct behaviour.
All you need to do to test a stream is to wrap it with 
stream-spec, and then pipe some test data through it. 
it's purpose it to make it easy to test user-land streams have 
correct behavour.

Bug#921581: Typo in error message regarding csv format

[Brian Murray]

Package: distro-info
Version: 0.20
Severity: minor
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco

The string in the following error message should be "exactly" not
"excatly".

if(unlikely(strcmp(CSV_HEADER, line) != 0)) {
fprintf(stderr, NAME ": Header `%s' in file `%s' does not match
"
"excatly `" CSV_HEADER "'.\n", line, filename);
failures++;
}

Thanks,
--
Brian Murray @ubuntu.com

Bug#916912: [pre-approval] stretch-pu: package freerdp/1.1.0~git20140921.1.440916e+dfsg1-13+deb9u3

[Mike Gabriel]

Hi Adam,

maybe some help from your side is needed...

On  Mo 04 Feb 2019 22:24:16 CET, Adam D. Barratt wrote:


Control: tags -1 + confirmed

Hi,

On Thu, 2019-01-31 at 22:14 +, Mike Gabriel wrote:

HI Adam,

On  Do 31 Jan 2019 21:28:43 CET, Adam D. Barratt wrote:

> On Fri, 2019-01-11 at 15:26 +0100, Mike Gabriel wrote:
> > Please review the attached .debdiff (for stretch) and give your
> > go
> > for uploading to stretch.
>

[...]

>   * debian/control:
> + B-D on libssh1.0-dev (instead of libssh-dev).

It's libssh1.0-dev for stretch and nothing needs to be changed.


Well, no. As you go on to say yourself below, it's libss*l*1.0-dev


> This change doesn't appear to have actually been included. (Which
> is
> just as well, as there is no such package in Debian.)

Yeah, I guess I mixed those up in the changelog. The  
debian/jessie/updates branch needs a switch-back [1] from  
libssl1.0-dev to libssl-dev whereas the debian/stretch/updates
branch   does not need a change here.

[...]

I will also publish a blog post that will appear on Planet Debian
> > that links to built binaries that users may be table to test.
>
> Has there been much take-up / feedback there?

Over the last 8 days my webserver has registered 18 downloads of  
freerdp-x11 (either for jessie or for stretch). Without any
positive feedback given (which I requested explicitly).


That's unfortunate. Let's hope it simply means that people couldn't be
bothered to provide feedback.

Please go ahead.

Regards,

Adam


Maybe you can help... I just uploaded freerdp, BUT...

the src:pkg contains an unwanted file: the .debdiff between +deb9u2  
and +deb9u3.


If you have means to reject it still, please do. Otherwise, we need to  
live with it.


I also pinged #debian-ftp on IRC. Maybe someone is on it and this mail  
is obsolete.


Thanks+Greets,
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpwiGLsGO_Sn.pgp
Description: Digitale PGP-Signatur

Bug#921562: [Pkg-javascript-devel] Bug#921562: ITP: libjs-vue-router

[Xavier]

Complements:

* Package name: node-vue-router
  Version : 3.0.2+ds
  Upstream Author : Evan You
* URL : https://github.com/vuejs/vue-router#readme
* License : Expat
  Programming Lang: JavaScript
  Description : official router for Vue.js

vue-router deeply integrates with Vue.js core to make building Single
Page Applications with Vue.js a breeze. Features include:
  - Nested route/view mapping
  - Modular, component-based router configuration
  - Route params, query, wildcards
  - View transition effects powered by Vue.js' transition system
  - Fine-grained navigation control
  - Links with automatic active CSS classes
  - HTML5 history mode or hash mode, with auto-fallback in IE9
  - Customizable Scroll Behavior

This package is a build dependency of Laminar (#919181)

Cheers,
Xavier

Bug#921580: golang-google-cloud must version the golang-google-genproto-dev build dependency on a post-buster version

[Adrian Bunk]

Source: golang-google-cloud
Version: 0.9.0-8
Severity: serious

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

...
# cloud.google.com/go/profiler/mocks
src/cloud.google.com/go/profiler/mocks/mock_profiler_client.go:49:86: 
undefined: cloudprofiler.CreateOfflineProfileRequest
...

Bug#911356: ikiwiki: "po" plugin can insert raw ".po" file contents with [[!inline ... ]] directives

[Chris Lamb]

Hi Simon et al.,

> I would particularly appreciate review and testing from intrigeri, who wrote
> the code that I'm deleting and hopefully has a better picture of why it was/is
> necessary.

ACK. FYI this is being tracked in Tails at:

  https://redmine.tails.boum.org/code/issues/6907


Best wishes,

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

Bug#921548: taurus-pyqtgraph/0.1-1 -- extension for taurus

[Carlos Pascual]

No. It provides a module called taurus_pyqtgraph which in itself uses 
taurus-defined entrypoints to plug into different parts of taurus . I've looked 
at other packages providing plugins, and the current name seems the most 
appropriate...

On February 6, 2019 9:20:54 PM GMT+01:00, PICCA Frederic-Emmanuel 
 wrote:
>Hello carlos,
>
>If your package provide this pyhton module
>
>taurus.pyqtgraph,
>
>then the binary package should be named
>
>python-taurus.pyqtgraph.
>
>
>Cheers
>
>Frederic

Bug#920878: lintian: please check for missing Build-Depends: qt5-qmake:native when using lrelease

[Chris Lamb]

tags 920878 + moreinfo
thanks

Dmitry Shachnev wrote:

> […]

(Tagging as moreinfo for the time being until we resolve this question...)


Regards,

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

Bug#921579: ghc: GHC version 8.2 or later is required to compile GHC

[itd]

Package: ghc
Version: ghc_8.6.3+dfsg1-1
Severity: minor

Dear Maintainer,

I tried to build ghc 8.6.3 on a stretch host. This failed with:


configure: error: GHC version 8.2 or later is required to compile GHC.


(stretch has ghc 8.0.1.)

Please consider updating the version constraint for ghc in 
debian/control.


Thank you.

Regards,
itd

Bug#921351: [pkg-go] Bug#921351: prometheus-postfix-exporter: Init script missing

[Scott Kitterman]

It's not the FTP Team's job to fix policy compliance issues in packages.  If 
you have a problem with that being a policy must, then you should take it up 
with the policy team.

I completely understand the frustration, but in my own packages I take the time 
to do it because Debian policy says it's required, not because I particularly 
care about sysvinit.

Scott K

On February 6, 2019 9:23:46 PM UTC, Michael Stapelberg  
wrote:
>Can you provide a patch if you care about sysvinit please? The Go
>packaging
>team is pretty manpower-constrained and non-systemd is a niche case, so
>any
>help is appreciated. Thanks!
>
>On Wed, Feb 6, 2019 at 7:49 PM Scott Kitterman 
>wrote:
>
>> Package: prometheus-postfix-exporter
>> Version: 0.1.2-1
>> Severity: serious
>> Justification: Policy 9.11
>>
>> Excerpt from policy 9.11:
>>
>> However, any package integrating with other init systems
>> must also be backwards-compatible with sysvinit by providing a SysV-
>> style init script with the same name as and equivalent functionality
>> to any init-specific job, as this is the only start-up configuration
>> method guaranteed to be supported by all init implementations.
>>
>> The package violates a policy must by not providing s sysvint init
>script.
>>
>> Scott K
>>
>> ___
>> Pkg-go-maintainers mailing list
>> pkg-go-maintain...@alioth-lists.debian.net
>>
>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#921578: libnfs: autopkgtest failures on Ubuntu

[Jeremy Bicha]

Source: libnfs
Version: 3.0.0-1

Could you please look into the autopkgtests on Ubuntu? They have never passed.

It would be nice to get the tests passing as part of the Ubuntu Main
Inclusion Request
https://launchpad.net/bugs/1746598

http://autopkgtest.ubuntu.com/packages/libn/libnfs

Thanks,
Jeremy Bicha

Bug#921473: [deb...@kitterman.com: Bug#921473: calibre: Invalid maintainer address]

[Norbert Preining]

Hi all

On Tue, 05 Feb 2019, Nicholas D Steeves wrote:
> Shall I update d/control to use "Norbert Preining
> "?  If not, I'll need to move the salsa project
> to a new namespace--either collab-maint or my own.

Please see https://github.com/norbusan/calibre-debian which has all
these changes, including the VCS updates as well as the email adr
change.

And yes, please complain to DAM about this mess.

> Thank you for bringing this to my attention, as far as I know, Norbert
> I've contacted him using his other email address, to ask to use that
> address as maintainer.

It is already used in the packages I published on my website, as well 
as in the github repository which is the current correct and only 
repository for packaging calibre.

> Worst case scenario, what is the deadline to adopt Calibre?  I believe
> Norbert is still the maintainer, but am willing to adopt the package

Wait, first of all, what is the 3.39.1 that was uploaded to unstable?
Please use the github repository for packaging,

SALSA IS DEPRECATED WITH RESPECT TO MY PACKAGES

And it would be nice to inform me about uploads before doing them,
thanks.

And no, the package is not orphaned, so don't adopt it.

Best

Norbert

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

Bug#921510: [Debichem-devel] Bug#921510: qutemol: segfaults at startup when compiled with GCC 8

[Adrian Bunk]

Control: tags -1 patch

On Wed, Feb 06, 2019 at 08:50:21PM +0200, Graham Inggs wrote:
> Commenting out AOgpu2::init() avoids the problem with GCC 8 and so far
> I haven't noticed any side-effects.
> 
> --- a/src/Common.cpp
> +++ b/src/Common.cpp
> @@ -1054,7 +1054,7 @@
>if (!shadowmap.init()) res|=ERRGL_NO_FBO_SHADOWMAP;
>if (!shadowmap.initHalo()) res|=ERRGL_NO_FBO_HALO;
> 
> -  if (! AOgpu2::init()) res|=ERRGL_NO_FBO_AO;
> +//  if (! AOgpu2::init()) res|=ERRGL_NO_FBO_AO;

With -Wall gcc even tells what the actual bug is:
  src/ShadowMap.cpp: In static member function 'static bool AOgpu2::init()':
  src/ShadowMap.cpp:250:25: warning: control reaches end of non-void function 
[-Wreturn-type]

Proper fix attached.

cu
Adrian

-- 

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

diff -Nru qutemol-0.4.1~cvs2008/debian/control 
qutemol-0.4.1~cvs2008/debian/control
--- qutemol-0.4.1~cvs2008/debian/control2019-02-06 13:20:00.0 
+0200
+++ qutemol-0.4.1~cvs2008/debian/control2019-02-06 23:42:28.0 
+0200
@@ -6,7 +6,6 @@
 Section: science
 Priority: optional
 Build-Depends: debhelper (>= 12~),
-   g++-7,
libgif-dev (>= 5),
libglew-dev,
libpng-dev,
diff -Nru qutemol-0.4.1~cvs2008/debian/patches/41_aogpu2_init_return.patch 
qutemol-0.4.1~cvs2008/debian/patches/41_aogpu2_init_return.patch
--- qutemol-0.4.1~cvs2008/debian/patches/41_aogpu2_init_return.patch
1970-01-01 02:00:00.0 +0200
+++ qutemol-0.4.1~cvs2008/debian/patches/41_aogpu2_init_return.patch
2019-02-06 23:47:20.0 +0200
@@ -0,0 +1,14 @@
+Description: Fix segfault due to not returning true in AOgpu2::init()
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/921510
+
+--- qutemol-0.4.1~cvs2008.orig/src/ShadowMap.cpp
 qutemol-0.4.1~cvs2008/src/ShadowMap.cpp
+@@ -248,6 +248,7 @@ bool ShadowMap::initHalo(){
+ bool AOgpu2::init(){
+   if (!moltextureCanvas.Test()) return false;
+   mainCanvas.SetAsOutput();
++  return true;
+ }
+ 
+ float myrand();
diff -Nru qutemol-0.4.1~cvs2008/debian/patches/series 
qutemol-0.4.1~cvs2008/debian/patches/series
--- qutemol-0.4.1~cvs2008/debian/patches/series 2019-02-04 
13:28:00.0 +0200
+++ qutemol-0.4.1~cvs2008/debian/patches/series 2019-02-06 
23:47:20.0 +0200
@@ -36,3 +36,4 @@
 38_libpng15.patch
 39_reproducible_build.patch
 40_c++11_compatibility.patch
+41_aogpu2_init_return.patch
Binary files /tmp/mefexQx1b2/qutemol-0.4.1~cvs2008/debian/qutemol.png and 
/tmp/eIepoe2zGj/qutemol-0.4.1~cvs2008/debian/qutemol.png differ
diff -Nru qutemol-0.4.1~cvs2008/debian/rules 
qutemol-0.4.1~cvs2008/debian/rules
--- qutemol-0.4.1~cvs2008/debian/rules  2019-02-06 13:20:00.0 
+0200
+++ qutemol-0.4.1~cvs2008/debian/rules  2019-02-06 23:47:20.0 
+0200
@@ -2,7 +2,7 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
-export CXX = g++-7
+export DEB_CXXFLAGS_MAINT_APPEND = -Wall
 
 %:
dh $@

Bug#921577: smcroute autopkgtests fail consistently

[Steve Langasek]

Source: smcroute
Version: 2.4.2-3
Severity: improtant
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco

Hi Joachim,

The smcroute package has autopkgtests which are being skipped when run on
Debian infrastructure
(https://ci.debian.net/packages/s/smcroute/unstable/amd64/) because they
require machine-level isolation, and Debian runs its autopkgtests in a
container.  Ubuntu, OTOH, does run these tests in VMs instead of containers,
and the tests consistently fail:

[...]
autopkgtest [14:38:02]: test mr-cache-ipv4: [---
1..9
ok 1 - smcroute is running (pid 1166)
ok 2 - At least one multicast capable interface found: ens2
ok 3 - Multicast routing cache is empty
smcroutectl: Same outbound interface (ens2) as inbound (ens2)?
not ok 4 - adding multicast route 10.0.0.1->ens2->ens2->224.0.1.20 doesn't fail 
(return code: 1)
#   Failed test 'adding multicast route 10.0.0.1->ens2->ens2->224.0.1.20 doesn't
 fail (return code: 1)'
#   at /tmp/autopkgtest.bsTJaj/build.zvn/src/debian/tests/mr-cache-ipv4 line 41.
#  got: '1'
# expected: '0'
ok 5 - adding multicast route 10.0.0.1->ens2->ens2->224.0.1.20 doesn't generate 
any console output
not ok 6 - Multicast routing cache now contains one entry
#   Failed test 'Multicast routing cache now contains one entry'
#   at /tmp/autopkgtest.bsTJaj/build.zvn/src/debian/tests/mr-cache-ipv4 line 45.
#  got: '0'
# expected: '1'
# GroupOrigin   Iif PktsBytesWrong Oifs
smcroutectl: Same outbound interface (ens2) as inbound (ens2)?
not ok 7 - removing multicast route 10.0.0.1->ens2->ens2->224.0.1.20 doesn't 
fail (return code: 1)
#   Failed test 'removing multicast route 10.0.0.1->ens2->ens2->224.0.1.20 
doesn't fail (return code: 1)'
#   at /tmp/autopkgtest.bsTJaj/build.zvn/src/debian/tests/mr-cache-ipv4 line 50.
#  got: '1'
# expected: '0'
ok 8 - removing multicast route 10.0.0.1->ens2->ens2->224.0.1.20 doesn't 
generate any console output
ok 9 - Multicast routing cache is empty again
# Looks like you failed 3 tests of 9.
autopkgtest [14:38:02]: test mr-cache-ipv4: ---]
[...]

  (http://autopkgtest.ubuntu.com/packages/s/smcroute/disco/amd64)

It looks like the tests might require not only machine isolation, but also
special hardware? (multiple network devices?)  Or is the test simply showing
that the package is broken?

Either way, with a failing test, this version of smcroute will not migrate
into an Ubuntu release.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#921274: teeworlds: baseline violation on i386

[Markus Koschany]

On Sun, 03 Feb 2019 22:35:22 +0200 Adrian Bunk  wrote:
> Source: teeworlds
> Version: 0.7.2-2
> Severity: serious
> Tags: patch
> 
> SSE is not part of the i386 baseline, fix attached.

Could you go into more detail why this is release-critical and what
issue we are trying to solve?

Markus



signature.asc
Description: OpenPGP digital signature

Bug#921576: ITP: libhtml-tidy5-perl -- HTML validation in a Perl object

[gregor herrmann]

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

* Package name: libhtml-tidy5-perl
  Version : 1.04
  Upstream Author : Andy Lester 
* URL : https://metacpan.org/release/HTML-Tidy5
* License : Artistic-2.0
  Programming Lang: Perl
  Description : HTML validation in a Perl object

HTML::Tidy5 is an HTML checker object using libtidy. It's meant as a
replacement for HTML::Lint or HTML::Tidy.

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#921575: golang-go.opencensus: FTBFS randomly (got "endednendednendedn" want "endednendednendednendedn")

[Santiago Vila]

Package: src:golang-go.opencensus
Version: 0.19.0-1
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_autoreconf -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go install 
-gcflags=all=\"-trimpath=/<>/obj-x86_64-linux-gnu/src\" 
-asmflags=all=\"-trimpath=/<>/obj-x86_64-linux-gnu/src\" -v -p 1 
go.opencensus.io go.opencensus.io/exemplar go.opencensus.io/exporter/jaeger 
go.opencensus.io/exporter/jaeger/internal/gen-go/jaeger 
go.opencensus.io/exporter/prometheus 
go.opencensus.io/exporter/stackdriver/propagation 
go.opencensus.io/exporter/zipkin go.opencensus.io/internal 
go.opencensus.io/internal/readme go.opencensus.io/internal/tagencoding 
go.opencensus.io/internal/testpb go.opencensus.io/metric 
go.opencensus.io/metric/metricdata go.opencensus.io/metric/metricexport 
go.opencensus.io/plugin/ocgrpc go.opencensus.io/plugin/ochttp 
go.opencensus.io/plugin/ochttp/propagation/b3 
go.opencensus.io/plugin/ochttp/propagation/tracecontext 
go.opencensus.io/resource go.opencensus.io/stats 
go.opencensus.io/stats/internal go.opencensus.io/stats/view 
go.opencensus.io/tag go.opencensus.io/trace go.opencensus.io/
 trace/internal go.opencensus.io/trace/propagation 
go.opencensus.io/trace/tracestate go.opencensus.io/zpages 
go.opencensus.io/zpages/internal
go.opencensus.io
errors
internal/race
internal/cpu
internal/bytealg
runtime/internal/atomic
runtime/internal/sys
runtime
sync/atomic
sync
io
math
syscall
time
internal/poll
internal/syscall/unix
internal/testlog
os
math/bits
unicode/utf8
strconv
unicode
reflect
fmt
context
go.opencensus.io/exemplar
bytes
encoding/binary
database/sql/driver
bufio
sort
compress/flate
hash
hash/crc32
compress/gzip
hash/adler32
compress/zlib
container/list
crypto
crypto/internal/subtle
crypto/subtle
crypto/cipher
crypto/aes
crypto/des
math/rand
strings
math/big
crypto/elliptic
crypto/internal/randutil
crypto/sha512
encoding/asn1
crypto/ecdsa
crypto/hmac
crypto/md5
crypto/rand
crypto/rc4
crypto/rsa
crypto/sha1
crypto/sha256
crypto/dsa
encoding/hex
crypto/x509/pkix
encoding/base64
encoding/pem
vendor/golang_org/x/crypto/cryptobyte/asn1
vendor/golang_org/x/crypto/cryptobyte
path/filepath
io/ioutil
vendor/golang_org/x/net/dns/dnsmessage
internal/nettrace
internal/singleflight
runtime/cgo
net
net/url
crypto/x509
vendor/golang_org/x/crypto/internal/chacha20
vendor/golang_org/x/crypto/poly1305
vendor/golang_org/x/crypto/chacha20poly1305
vendor/golang_org/x/crypto/curve25519
crypto/tls
encoding
unicode/utf16
encoding/json
log
vendor/golang_org/x/text/transform
vendor/golang_org/x/text/unicode/bidi
vendor/golang_org/x/text/secure/bidirule
vendor/golang_org/x/text/unicode/norm
vendor/golang_org/x/net/idna
net/textproto
vendor/golang_org/x/net/http/httpguts
vendor/golang_org/x/net/http/httpproxy
vendor/golang_org/x/net/http2/hpack
mime
mime/quotedprintable
mime/multipart
net/http/httptrace
net/http/internal
path
net/http
runtime/debug
thrift
go.opencensus.io/exporter/jaeger/internal/gen-go/jaeger
go.opencensus.io/internal
go.opencensus.io/trace/internal
regexp/syntax
regexp
go.opencensus.io/trace/tracestate
runtime/trace
go.opencensus.io/trace
golang.org/x/net/context
golang.org/x/sync/semaphore
google.golang.org/api/support/bundler
go.opencensus.io/exporter/jaeger
expvar
github.com/beorn7/perks/quantile
github.com/golang/protobuf/proto
github.com/prometheus/client_model/go
github.com/prometheus/client_golang/prometheus/internal
github.com/matttproud/golang_protobuf_extensions/pbutil
github.com/prometheus/common/internal/bitbucket.org/ww/goautoneg
github.com/prometheus/common/model
github.com/prometheus/common/expfmt
github.com/prometheus/procfs/internal/util
github.com/prometheus/procfs/nfs
github.com/prometheus/procfs/xfs
github.com/prometheus/procfs
github.com/prometheus/client_golang/prometheus
github.com/prometheus/client_golang/prometheus/promhttp
go.opencensus.io/internal/tagencoding
text/tabwriter
runtime/pprof
go.opencensus.io/tag
go.opencensus.io/stats/internal
go.opencensus.io/stats
go.opencensus.io/stats/view
go.opencensus.io/exporter/prometheus
go.opencensus.io/trace/propagation
go.opencensus.io/exporter/stackdriver/propagation
github.com/openzipkin/zipkin-go/model
github.com/openzipkin/zipkin-go/reporter
go.opencensus.io/exporter/zipkin
go.opencensus.io/internal/readme
google.golang.org/grpc/codes
google.golang.org/grpc/grpclog
google.golang.org/grpc/metadata
google.golang.org/grpc/stats
github.com/golang/protobuf/ptypes/any
github.com/golang/protobuf/ptypes/duration
github.com/golang/protobuf/ptypes/timestamp
github.com/golang/protobuf/ptypes
google.golang.org/genproto/googleapis/rpc/status
google.golang.org/grpc/status

Bug#917620: stretch-pu: package glibc/2.24-11+deb9u4

[Aurelien Jarno]

On 2019-02-06 18:31, Cyril Brulebois wrote:
> Hi,
> 
> Adam D. Barratt  (2019-01-31):
> > This looks OK to me, subject to the usual KiBi-ack. Sorry for the
> > delay.
> 
> All my local d-i tests look good; no objections.
> 

Thanks for the review, I have just uploaded it.

Cheers,
Aurelien

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


signature.asc
Description: PGP signature

Bug#916696: initramfs-tools: search for nonexistent resume device

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 17 Dec 2018 15:48:12 +0100 Trek  wrote:
> Package: initramfs-tools
> Version: 0.132
> 
> at boot, initramfs blocks searching for a resume device
> 
> Begin: Waiting for suspend/resume device ...
> Begin: Running /scripts/local-block ... done.
> 
> 
> I'm using sysvinit and two encrypted swap partitions
> 
> the file /etc/initramfs-tools/conf.d/resume does not exist
> 
> the contents of /etc/crypttab are:
> 
> sda5_crypt /dev/disk/by-id/ata-XX-XX_-part5 /dev/urandom
> cipher=aes-xts-plain64,size=256,swap
> sdb5_crypt /dev/disk/by-id/ata-XX-XX_-part5 /dev/urandom
> cipher=aes-xts-plain64,size=256,swap
> 
> 
> if I disable swap (swapoff -a) and rebuild the initrd, the problem
> disappears
> 
> 
> can I do something to further investigate the issue?

The RESUME variable doesn't have to be set in any particular file.
Please check with:

grep -rw RESUME /etc/initramfs-tools/initramfs.conf \
/etc/initramfs-tools/conf.d \
/usr/share/initramfs-tools/conf.d/

If it's definitely not set, then please:

1. Upgrade to initramfs-tools version 0.133 (I just uploaded this so
   you will have to wait a few hours for it to be available)
2. Run "update-initramfs -u -v >initramfs.log 2>&1"
3. Look in initramfs.log for "Calling hook resume" and send the
   messages after that

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain.
  - Lily Tomlin



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

Bug#921351: [pkg-go] Bug#921351: prometheus-postfix-exporter: Init script missing

[Michael Stapelberg]

Can you provide a patch if you care about sysvinit please? The Go packaging
team is pretty manpower-constrained and non-systemd is a niche case, so any
help is appreciated. Thanks!

On Wed, Feb 6, 2019 at 7:49 PM Scott Kitterman  wrote:

> Package: prometheus-postfix-exporter
> Version: 0.1.2-1
> Severity: serious
> Justification: Policy 9.11
>
> Excerpt from policy 9.11:
>
> However, any package integrating with other init systems
> must also be backwards-compatible with sysvinit by providing a SysV-
> style init script with the same name as and equivalent functionality
> to any init-specific job, as this is the only start-up configuration
> method guaranteed to be supported by all init implementations.
>
> The package violates a policy must by not providing s sysvint init script.
>
> Scott K
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers



-- 
Best regards,
Michael

Bug#921573: lintian: binary-from-other-architecture only works sometimes

[Chris Lamb]

Helmut Grohne wrote:

> Please cross build the procmail package for arm64 and for mips64el on an
> amd64 build machine. In both cases, you'll get a successful build, but
> the binaries inside the package are amd64 binaries despite the
> arm64/mips64el architecture tag.

Replying quickly; do you happen to have the .deb still handy? If
so, would be great to attach to this bug report as it will save
folks the cross-build step. :)


Best wishes,

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

Bug#921574: RM: libalkimia -- ROM; old name of src:alkimia

[Pino Toscano]

Package: ftp.debian.org
Severity: normal

Hi,

please remove src:libalkimia: the Qt5 version of it was uploaded as
src:alkimia, like its upstream name (there was a SONAME bump).

The only dependency of it was kmymoney, recently switched to Qt5.

Thanks,
-- 
Pino

Bug#921573: lintian: binary-from-other-architecture only works sometimes

[Helmut Grohne]

Package: lintian
Version: 2.5.124

Please cross build the procmail package for arm64 and for mips64el on an
amd64 build machine. In both cases, you'll get a successful build, but
the binaries inside the package are amd64 binaries despite the
arm64/mips64el architecture tag. As such, lintian should emit tags:

| E: procmail: binary-from-other-architecture usr/bin/formail
| E: procmail: binary-from-other-architecture usr/bin/lockfile
| E: procmail: binary-from-other-architecture usr/bin/procmail

For the broken arm64 cross build, these tags are correctly emitted.
However, the broken mips64el build is not recognized as broken by
lintian. The binary-from-other-architecture tag is strangely missing
there.

Helmut

Bug#921572: mercurial breaks hg-git autopkgtest: ProgrammingError: callcommand() cannot be used after commands are sent

[Paul Gevers]

Source: mercurial, hg-git
Control: found -1 mercurial/4.9-1
Control: found -1 hg-git/0.8.12-1
Severity: important
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of mercurial the autopkgtest of hg-git fails in
testing when that autopkgtest is run with the binary packages of
mercurial from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
mercurial  from testing4.9-1
hg-git from testing0.8.12-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. There are lots
of deprecation warnings that hg-git must fix one way or the other (for
real, or in the reference data), but there are other failures that I am
not sure about. Please check the full log.

Currently this regression is blocking the migration of mercurial to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/h/hg-git/1866935/log.gz

--- /tmp/autopkgtest-lxc.f_shsdii/downtmp/build.dXo/src/tests/test-pull.t
+++
/tmp/autopkgtest-lxc.f_shsdii/downtmp/build.dXo/src/tests/test-pull.t.err
@@ -24,24 +24,103 @@
   $ echo "default=$TESTTMP/gitrepo" >> hgrepo/.hg/hgrc
   $ hg -R hgrepo pull -r t_alpha
   pulling from $TESTTMP/gitrepo
-  importing git objects into hg
-  (run 'hg update' to get a working copy)
+  ** Unknown exception encountered with possibly-broken third-party
extension hggit
+  ** which supports versions 4.7 of Mercurial.
+  ** Please disable hggit and try your action again.
+  ** If that fixes the bug please report it to
https://bitbucket.org/durin42/hg-git/issues
+  ** Python 2.7.15+ (default, Feb  3 2019, 13:13:16) [GCC 8.2.0]
+  ** Mercurial Distributed SCM (version 4.9)
+  ** Extensions loaded: hggit, strip, mq
+  ** ProgrammingError: callcommand() cannot be used after commands are sent
+  Traceback (most recent call last):
+File "/usr/bin/hg", line 43, in 
+  dispatch.run()
+File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line
99, in run
+  status = dispatch(req)
+File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line
225, in dispatch
+  ret = _runcatch(req) or 0
+File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line
376, in _runcatch
+  return _callcatch(ui, _runcatchfunc)
+File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line
384, in _callcatch
+  return scmutil.callcatch(ui, func)
+File "/usr/lib/python2.7/dist-packages/mercurial/scmutil.py", line
165, in callcatch
+  return func()
+File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line
367, in _runcatchfunc
+  return _dispatch(req)
+File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line
1021, in _dispatch
+  cmdpats, cmdoptions)
+File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line
756, in runcommand
+  ret = _runcommand(ui, options, cmd, d)
+File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line
1030, in _runcommand
+  return cmdfunc()
+File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line
1018, in 
+  d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
+File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line
1672, in check
+  return func(*args, **kwargs)
+File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line
1672, in check
+  return func(*args, **kwargs)
+File "/usr/lib/python2.7/dist-packages/hgext/mq.py", line 3633, in
mqcommand
+  return orig(ui, repo, *args, **kwargs)
+File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line
1672, in check
+  return func(*args, **kwargs)
+File "/usr/lib/python2.7/dist-packages/mercurial/commands.py", line
4451, in pull
+  fnodes.append(e.callcommand('lookup', {'key': r}))
+File
"/usr/lib/python2.7/dist-packages/mercurial/wireprotov1peer.py", line
133, in callcommand
+  raise error.ProgrammingError('callcommand() cannot be used '
+  mercurial.error.ProgrammingError: callcommand() cannot be used after
commands are sent
+  [1]
   $ hg -R hgrepo update t_alpha
-  1 files updated, 0 files 

Bug#921571: afnix FTBFS on armhf when built on arm64 hardware

[Adrian Bunk]

Source: afnix
Version: 2.9.2-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=afnix=armhf=2.9.2-1=1548047247=0

...
running: SEC0003.als
exception : assert-error
in file   : SEC0003.als at or around line 113
afnix-aexec: failure SEC0003.als
make[6]: *** [../../../../cnf/mak/afnix-rule.mak:270: SEC0003.als] Error 1


This is likely an unaligned access problem.

Bug#892288: arrayfire test crash

[Rebecca N. Palmer]

On i386 with the above patches (plus the gcc8 build fix from the other 
bug), all tests pass in the build but Test_gfor_cpu fails in the 
autopkgtest; I don't yet know why.

Bug#921511: python-octaviaclient: please make the build reproducible

[Michael Johnson]

The proposed fix has now merged here: https://review.openstack.org/#/c/635194/

Michael

Bug#921547: u-boot: Please consider making u-boot-sunxi arch:all

[Vagrant Cascadian]

On 2019-02-06, Jonathan McDowell wrote:
> The u-boot-sunxi package contains a bunch of u-boot images which can be
> written to SD cards or sent over USB to the device via sunxi-fel.
> There's no binary which actually runs under Linux. As such I think it's
> appropriate to switch to arch:all, allowing it's installation on other
> machines which are creating the SD image or remotely debugging the sunxi
> device.

Interesting timing... yesterday I worked on updating Ivo De Decker's
work on cross-building u-boot images for multiple architectures and
building an arch:all u-boot-qemu package:

  https://bugs.debian.org/907573

Which demonstrates that in theory it would be possible to make almost
all of the u-boot packages arch:all... essentially any architecture with
working cross-compilers for amd64.


On the other hand, people went through a lot of trouble to make
multi-arch a reality, and you can also install u-boot-sunxi packages
using multi-arch.


I'm not sure what all of the implications are for building more u-boot
packages as arch:all ... some that come to mind:

All of the u-boot-sunxi platforms for both armhf and arm64 would end up
in a single package, which might be unfortunate on some
resource-constrained systems...

Ideally for the end-user, there would be one package per u-boot target,
but I've thus far only broken it up by rough approximations of SoC
families to mitigate the proliferation of many small packages and
getting stuck in NEW for every new platform added.

Being able to do development on a faster platform (e.g. amd64) would be
nice, although in most cases u-boot is already fairly cross-buildable
for any target where this would be feasible, so that seems a mixed
argument.


One thought would be to build a single arch:all package with all of the
cross-buildable targets, and appropriate Provides and Conflicts on other
u-boot-* packages, while still building natively as well... maybe a
little redundant essentially having the same u-boot images in two
places.


Certainly too late for buster, of course, but an interesting idea to
mull over for bullseye...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#921548: taurus-pyqtgraph/0.1-1 -- extension for taurus

[PICCA Frederic-Emmanuel]

Hello carlos,

If your package provide this pyhton module

taurus.pyqtgraph,

then the binary package should be named

python-taurus.pyqtgraph.


Cheers

Frederic

Bug#921565: netmask: buffer overflow vulnerability

[Guilhem Moulin]

Hi Salvatore,

On Wed, 06 Feb 2019 at 20:59:50 +0100, Salvatore Bonaccorso wrote:
> Given there is (not yet) a CVE for this issue add a unique identifier
> via a Debian BTS bug for the issue for tracking.

Oops, I should have done that before uploading 2.4.4-1…  Sorry for the
extra work, and thanks for filing!

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#921570: haskell-cborg FTBFS on 32bit

[Adrian Bunk]

Source: haskell-cborg
Version: 0.2.0.0-1
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=haskell-cborg=sid

...
[10 of 14] Compiling Codec.CBOR.Read  ( src/Codec/CBOR/Read.hs, 
dist-ghc/build/Codec/CBOR/Read.o )

src/Codec/CBOR/Read.hs:368:29: error:
* Couldn't match a lifted type with an unlifted type
  When matching types
p2 :: *
Word# :: TYPE 'WordRep
* In the first argument of `w_out_of_range', namely `w#'
  In the expression: w_out_of_range w#
  In the expression:
case w_out_of_range w# of
  0#
| isWordCanonical sz w# -> k w# >>= go_fast (BS.unsafeDrop sz bs)
  _ -> go_fast_end bs da
|
368 | case w_out_of_range w# of
| ^^

src/Codec/CBOR/Read.hs:413:29: error:
* Couldn't match a lifted type with an unlifted type
  When matching types
p3 :: *
Int# :: TYPE 'IntRep
* In the first argument of `n_out_of_range', namely `n#'
  In the expression: n_out_of_range n#
  In the expression:
case n_out_of_range n# of
  0# | isIntCanonical sz n# -> k n# >>= go_fast (BS.unsafeDrop sz bs)
  _ -> go_fast_end bs da
|
413 | case n_out_of_range n# of
| ^^

src/Codec/CBOR/Read.hs:482:9: error:
* Couldn't match expected type `Bool'
  with actual type `Int -> Word64# -> Bool'
* Probable cause: `isWord64Canonical' is applied to too few arguments
  In the expression: isWord64Canonical
  In a stmt of a pattern guard for
 a case alternative:
isWord64Canonical
  In a case alternative:
  DecodedToken sz (W64# w#)
| isWord64Canonical -> k w# >>= go_fast (BS.unsafeDrop sz bs)
| otherwise -> go_fast_end bs da
|
482 |   | isWord64Canonical -> k w# >>= go_fast (BS.unsafeDrop sz bs)
| ^

src/Codec/CBOR/Read.hs:504:31: error:
* Variable not in scope: int64ToWord64 :: Int64# -> Word64#
* Perhaps you meant `int64ToWord64#' (imported from GHC.IntWord64)
|
504 |   | isWord64Canonical sz (int64ToWord64 i#) -> k i# >>= go_fast 
(BS.unsafeDrop sz bs)
|   ^

src/Codec/CBOR/Read.hs:512:31: error:
* Variable not in scope: int64ToWord64 :: Int64# -> Word64#
* Perhaps you meant `int64ToWord64#' (imported from GHC.IntWord64)
|
512 |   | isWord64Canonical sz (int64ToWord64 i#) -> k i# >>= go_fast 
(BS.unsafeDrop sz bs)
|   ^

src/Codec/CBOR/Read.hs:806:54: error:
* Couldn't match a lifted type with an unlifted type
  When matching types
p0 :: *
Word# :: TYPE 'WordRep
* In the first argument of `w_out_of_range', namely `w#'
  In the expression: w_out_of_range w#
  In the expression:
case w_out_of_range w# of
  0#
| isWordCanonical sz w#
-> k w# >>= go_fast_end (BS.unsafeDrop sz bs)
| otherwise -> return $! SlowFail bs "non-canonical word32"
  _ -> return $! SlowFail bs "expected word32"
|
806 |   DecodedToken sz (W# w#) -> case w_out_of_range w# of
|  ^^

src/Codec/CBOR/Read.hs:854:29: error:
* Couldn't match a lifted type with an unlifted type
  When matching types
p1 :: *
Int# :: TYPE 'IntRep
* In the first argument of `n_out_of_range', namely `n#'
  In the expression: n_out_of_range n#
  In the expression:
case n_out_of_range n# of
  0#
| isIntCanonical sz n#
-> k n# >>= go_fast_end (BS.unsafeDrop sz bs)
| otherwise -> return $! SlowFail bs "non-canonical int32"
  _ -> return $! SlowFail bs "expected int32"
|
854 | case n_out_of_range n# of
| ^^

src/Codec/CBOR/Read.hs:1361:40: error:
* Couldn't match expected type `Word64#' with actual type `Word#'
* In the second argument of `leWord64#', namely `0x17##'
  In the first argument of `isTrue#', namely
`(w# `leWord64#` 0x17##)'
  In the second argument of `(&&)', namely
`isTrue# (w# `leWord64#` 0x17##)'
 |
1361 |   | sz == 2 && isTrue# (w# `leWord64#` 0x17##)   = False
 |^^

src/Codec/CBOR/Read.hs:1362:40: error:
* Couldn't match expected type `Word64#' with actual type `Word#'
* In the second argument of `leWord64#', namely `0xff##'
  In the first argument of `isTrue#', namely
`(w# `leWord64#` 0xff##)'
  In the second argument of `(&&)', namely
`isTrue# (w# `leWord64#` 0xff##)'
 |
1362 |   | sz == 3 && isTrue# (w# `leWord64#` 0xff##)   = False
 |^^

src/Codec/CBOR/Read.hs:1363:40: error:
* Couldn't match expected type `Word64#' with 

Bug#920826: (no subject)

[Danny Colin]

I would also like to see that patch in the debian package. After testing 
it, I can also confirm the patch works as expected.