Bug#960326: json-c: CVE-2020-12762

[Salvatore Bonaccorso]

Hi,

On Fri, May 15, 2020 at 10:19:42PM +0200, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Mon, May 11, 2020 at 09:55:12PM +0200, Salvatore Bonaccorso wrote:
> > Source: json-c
> > Version: 0.13.1+dfsg-7
> > Severity: important
> > Tags: security upstream
> > Forwarded: https://github.com/json-c/json-c/pull/592
> > 
> > Hi,
> > 
> > The following vulnerability was published for json-c.
> > 
> > CVE-2020-12762[0]:
> > | json-c through 0.14 has an integer overflow and out-of-bounds write
> > | via a large JSON file, as demonstrated by printbuf_memappend.
> 
> The upstream fix introduces a regression, see in particular
> https://github.com/json-c/json-c/issues/599 .
> 
> FWIW, Ubuntu has as well reverted the fix, pending further
> investigation as per https://usn.ubuntu.com/4360-2/ 

Backports for other branches (as squashed commits for all those
needed):

https://github.com/json-c/json-c/pull/608

Regards,
Salvatore

Bug#958840: kmer: autopkgtest regression: No module named 'localAlignerInterface'

[Andreas Tille]

Hi Antoni,

since you once dived into this which was interrupted when Salsa was
offline:  Would you be able to finish this?

That would be really helpful.

Kind regards

  Andreas.

On Tue, Apr 28, 2020 at 08:43:55PM +0200, Andreas Tille wrote:
> On Tue, Apr 28, 2020 at 04:43:30PM +, Antoni Villalonga wrote:
> > 
> > I think I've faced that problem and fixed.
> > Fix should be included into '2to3.patch'
> > 
> > I think the relevant part is:
> > 
> > --- a/atac-driver/chainer/localalign/localAlignerInterfacemodule.C
> > +++ b/atac-driver/chainer/localalign/localAlignerInterfacemodule.C
> > @@ -227,8 +227,17 @@
> >  };
> >  
> >  
> > +static struct PyModuleDef cModMethods =
> > +{
> > +PyModuleDef_HEAD_INIT,
> > +"localAlignerInterface",  /* name of module */
> > +"",  /* module documentation, may be NULL */
> > +-1,  /* size of per-interpreter state of the module, or -1 if 
> > the module keeps state in global variables. */
> > +registration_table
> > +};
> > +
> >  extern "C"
> > -void initlocalAlignerInterface() {
> > -  Py_InitModule("localAlignerInterface", registration_table);
> > +void PyInit_localAlignerInterface() {
> > +  PyModule_Create();
> >  }
> 
> Thanks.  Looks promising.
>  
> > Sorry I can't access salsa due to a maintenance, also can't test autopkgtest
> > for testing for the same reason.
> 
> Salsa and other hosts seem to be back now.
>  
> > It worked fine for sid some days ago.
> 
> Kind regards and thanks a lot for your contribution
> 
>   Andreas. 
> 
> -- 
> http://fam-tille.de
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#757402: [PATCH] tests: skip small-stack tests on hppa architecture

[Greg Price]

On hppa these tests crash because the allocated stack space is too
small, even after it was doubled in b9a190789 (and the data size
doubled to match) to make it work on powerpc.  For this arch just
skip these tests, which is enough to make the whole suite pass.

Fixes: https://bugs.debian.org/757402
Based-on-patch-by: John David Anglin 
Signed-off-by: Greg Price 
---
 t/test-lib.sh | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/t/test-lib.sh b/t/test-lib.sh
index 0ea1e5a05..c62961a3e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1467,6 +1467,14 @@ FreeBSD)
;;
 esac
 
+# Detect arches where a few things don't work
+uname_m=$(uname -m)
+case $uname_m in
+parisc* | hppa*)
+   test_set_prereq HPPA
+   ;;
+esac
+
 ( COLUMNS=1 && test $COLUMNS = 1 ) && test_set_prereq COLUMNS_CAN_BE_1
 test -z "$NO_PERL" && test_set_prereq PERL
 test -z "$NO_PTHREADS" && test_set_prereq PTHREADS
@@ -1606,16 +1614,16 @@ run_with_limited_cmdline () {
 }
 
 test_lazy_prereq CMDLINE_LIMIT '
-   test_have_prereq !MINGW,!CYGWIN &&
+   test_have_prereq !HPPA,!MINGW,!CYGWIN &&
run_with_limited_cmdline true
 '
 
 run_with_limited_stack () {
(ulimit -s 128 && "$@")
 }
 
 test_lazy_prereq ULIMIT_STACK_SIZE '
-   test_have_prereq !MINGW,!CYGWIN &&
+   test_have_prereq !HPPA,!MINGW,!CYGWIN &&
run_with_limited_stack true
 '
 
-- 
2.26.2

Bug#960741: pavucontrol: crash (SIGSEGV) when pulseaudio exits

[Paul Wise]

Package: pavucontrol
Version: 4.0-2
Severity: normal
File: /usr/bin/pavucontrol
Usertags: crash

When pulseaudio exits (temporarily), pavucontrol crashes with SIGSEGV:

$ sh -c 'sleep 30s ; pulseaudio -k' &
[1] 61080

$ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex 
'thread apply all bt full' --args pavucontrol
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffef34b700 (LWP 61105)]
[New Thread 0x7fffeeb4a700 (LWP 61106)]
[New Thread 0x7fffee2a7700 (LWP 61107)]
[New Thread 0x7fffeda7e700 (LWP 61108)]

(pavucontrol:61101): GLib-GObject-WARNING **: 13:33:42.308: The property 
GtkMisc:xpad is deprecated and shouldn't be used anymore. It will be removed in 
a future version.

(pavucontrol:61101): GLib-GObject-WARNING **: 13:33:42.308: The property 
GtkMisc:ypad is deprecated and shouldn't be used anymore. It will be removed in 
a future version.

(pavucontrol:61101): GLib-GObject-WARNING **: 13:33:42.334: The property 
GtkAlignment:top-padding is deprecated and shouldn't be used anymore. It will 
be removed in a future version.

(pavucontrol:61101): GLib-GObject-WARNING **: 13:33:42.334: The property 
GtkAlignment:bottom-padding is deprecated and shouldn't be used anymore. It 
will be removed in a future version.

(pavucontrol:61101): GLib-GObject-WARNING **: 13:33:42.334: The property 
GtkAlignment:left-padding is deprecated and shouldn't be used anymore. It will 
be removed in a future version.

(pavucontrol:61101): GLib-GObject-WARNING **: 13:33:42.334: The property 
GtkAlignment:right-padding is deprecated and shouldn't be used anymore. It will 
be removed in a future version.

(pavucontrol:61101): GLib-GObject-WARNING **: 13:33:42.341: The property 
GtkContainer:resize-mode is deprecated and shouldn't be used anymore. It will 
be removed in a future version.

(pavucontrol:61101): GLib-GObject-WARNING **: 13:33:43.322: The property 
GtkImage:stock is deprecated and shouldn't be used anymore. It will be removed 
in a future version.

(pavucontrol:61101): GLib-GObject-WARNING **: 13:33:43.323: The property 
GtkButton:xalign is deprecated and shouldn't be used anymore. It will be 
removed in a future version.
[Thread 0x7fffeeb4a700 (LWP 61106) exited]

Thread 1 "pavucontrol" received signal SIGSEGV, Segmentation fault.
0x76c23ca3 in std::local_Rb_tree_increment (__x=0xd9d9d9d9d9d9d9d9, 
__x@entry=0x55ac2ed0) at 
../../../../../src/libstdc++-v3/src/c++98/tree.cc:65
65  ../../../../../src/libstdc++-v3/src/c++98/tree.cc: No such file or 
directory.
#0  0x76c23ca3 in std::local_Rb_tree_increment (__x=0xd9d9d9d9d9d9d9d9, 
__x@entry=0x55ac2ed0) at 
../../../../../src/libstdc++-v3/src/c++98/tree.cc:65
#1  std::_Rb_tree_increment(std::_Rb_tree_node_base*) 
(__x=__x@entry=0x55ac2ed0) at 
../../../../../src/libstdc++-v3/src/c++98/tree.cc:85
#2  0x555a62f3 in std::_Rb_tree_iterator >::operator++() (this=) at 
/usr/include/c++/9/bits/stl_tree.h:285
#3  MainWindow::removeAllWidgets() (this=this@entry=0x55a5eb00) at 
mainwindow.cc:1250
#4  0x555a9787 in context_state_callback(pa_context*, void*) 
(c=0x55a6b640, userdata=0x55a5eb00) at pavucontrol.cc:561
#5  0x76d454a9 in pa_context_set_state (c=0x55a6b640, 
st=PA_CONTEXT_FAILED) at pulse/context.c:308
#6  0x75b0e606 in do_pstream_read_write (p=0x55aef600) at 
pulsecore/pstream.c:271
#7  0x76d8b3e6 in dispatch_func (source=0x55758520, 
callback=, userdata=) at pulse/glib-mainloop.c:203
#8  0x76de160d in g_main_dispatch (context=0x55663e40) at 
../../../glib/gmain.c:3309
#9  g_main_context_dispatch (context=context@entry=0x55663e40) at 
../../../glib/gmain.c:3974
#10 0x76de1890 in g_main_context_iterate 
(context=context@entry=0x55663e40, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4047
#11 0x76de191f in g_main_context_iteration 
(context=context@entry=0x55663e40, may_block=may_block@entry=1) at 
../../../glib/gmain.c:4108
#12 0x7657205d in g_application_run (application=0x5560e210 
[gtkmm__GtkApplication], argc=, argv=) at 
../../../gio/gapplication.c:2559
#13 0x5558c005 in main(int, char**) (argc=1, argv=0x7fffd948) at 
pavuapplication.cc:182
#0  0x76c23ca3 in std::local_Rb_tree_increment (__x=0xd9d9d9d9d9d9d9d9, 
__x@entry=0x55ac2ed0) at 
../../../../../src/libstdc++-v3/src/c++98/tree.cc:65
#1  std::_Rb_tree_increment(std::_Rb_tree_node_base*) 
(__x=__x@entry=0x55ac2ed0) at 
../../../../../src/libstdc++-v3/src/c++98/tree.cc:85
#2  0x555a62f3 in std::_Rb_tree_iterator >::operator++() (this=) at 
/usr/include/c++/9/bits/stl_tree.h:285
it = {first = 3654932953, second = 0xd9d9d9d9d9d9d9d9}
#3  MainWindow::removeAllWidgets() (this=this@entry=0x55a5eb00) at 
mainwindow.cc:1250
it = {first = 3654932953, second = 

Bug#854019: 用中文描述下问题

[atzlinux 肖盛文]

这个 bug 报告，说的是，用阴历查询阳历，如果阴历时间是在当日晚上 23
点，则查到的阳历日期反而会提前一天。


-- 
肖盛文 Faris Xiao
微信：atzlinux
ＱＱ：909868357
铜豌豆 Linux 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com



signature.asc
Description: OpenPGP digital signature

Bug#960739: libc-bin: getaddrinfo() fails with EAI_AGAIN when the DNS query returns a large number of A and AAAA records.

[Michael Przybylski]

Package: libc-bin
Version: 2.30-7
Severity: important
Tags: ipv6

Dear Maintainer,

When attempting to follow the instructions for installing the latest version of 
Docker Engine at 
https://docs.docker.com/engine/install/debian/ I noticed that 'apt-get update' 
and curl were both
failing to resolve download.docker.com.  The error message from both ping and 
curl was 
"Temporary failure in name resolution"

However, running 'host download.docker.com' yielded the following results:

download.docker.com is an alias for d2h67oheeuigaw.cloudfront.net.
d2h67oheeuigaw.cloudfront.net has address 13.227.73.43
d2h67oheeuigaw.cloudfront.net has address 13.227.73.44
d2h67oheeuigaw.cloudfront.net has address 13.227.73.95
d2h67oheeuigaw.cloudfront.net has address 13.227.73.15
d2h67oheeuigaw.cloudfront.net has IPv6 address 
2600:9000:2202:c00:3:db06:4200:93a1
d2h67oheeuigaw.cloudfront.net has IPv6 address 
2600:9000:2202:5000:3:db06:4200:93a1
d2h67oheeuigaw.cloudfront.net has IPv6 address 
2600:9000:2202:7a00:3:db06:4200:93a1
d2h67oheeuigaw.cloudfront.net has IPv6 address 
2600:9000:2202:9200:3:db06:4200:93a1
d2h67oheeuigaw.cloudfront.net has IPv6 address 
2600:9000:2202:9600:3:db06:4200:93a1
d2h67oheeuigaw.cloudfront.net has IPv6 address 
2600:9000:2202:9c00:3:db06:4200:93a1
d2h67oheeuigaw.cloudfront.net has IPv6 address 
2600:9000:2202:a200:3:db06:4200:93a1
d2h67oheeuigaw.cloudfront.net has IPv6 address 
2600:9000:2202:f600:3:db06:4200:93a1

After examining the source code for iputils-ping, I was able to determine that 
the cause of the
error message was getaddrinfo() returning EAI_AGAIN

The following workarounds were effective:

* curl -4 https://download.docker.com/... (Forcing curl to use IPv4 only)
* ping -4 download.docker.com (Forcing IPv4 ping to use IPv4 only)
* Forcing apt to use IPv4 by adding 'Acquire::ForceIPv4 "true";' to apt.conf

It is also noteworthy that not all hostnames with both A and  records 
trigger this bug. In fact,
hostnames with a low total record count like www.google.com have no problem 
whatsoever


root@sandbox:~# host www.google.com
www.google.com has address 172.217.6.36
www.google.com has IPv6 address 2607:f8b0:4005:809::2004
...
root@sandbox:~# ping www.google.com
PING www.google.com (172.217.6.36) 56(84) bytes of data.
64 bytes from sfo03s08-in-f4.1e100.net (172.217.6.36): icmp_seq=1 ttl=63 
time=29.6 ms
...
^C
--- www.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2005ms
rtt min/avg/max/mdev = 29.572/37.733/42.045/5.774 ms


Please note that this bug also affects libc-bin 2.28-10 in buster.

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

Kernel: Linux 4.19.0-9-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

Versions of packages libc-bin depends on:
ii  libc6  2.30-7

Versions of packages libc-bin recommends:
ii  manpages  5.06-1

libc-bin suggests no packages.

-- Configuration Files:
/etc/gai.conf changed [not included]

-- no debconf information

Bug#757402: git: test suite fails on hppa, in run_with_limited_stack

[Greg Price]

On Wed, May 13, 2020 at 4:53 AM John David Anglin  wrote:
> On 2020-05-13 1:44 a.m., Greg Price wrote:
> > Probably cleanest to put this outside the `case $uname_s`.
> I put it where I did because the result of uname -m is somewhat OS dependent.
>
> The config.guess script attempts to guess a canonical system name for a 
> target.  It has all the gory
> details on the interpretation of uname -m.

I just took a look through that. Wow, I see what you mean!

case "$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
# ...
9000/7??:4.3bsd:*:* | 9000/8?[79]:4.3bsd:*:*)
echo hppa1.1-hp-bsd
exit ;;

And there are lots more like that one, and others with complex internal logic.

Still I'm not sure that that situation is helped by putting the `uname
-m` inside this case. This is the catchall `*)` case after looking
only for MINGW, CYGWIN, and FreeBSD, and those all appear to have
pretty sane `uname -m` behavior. (On FreeBSD, `uname -p` gets a bit
more specific but `uname -m` is already sane; I found the report here:
  https://github.com/mesonbuild/meson/issues/5766
informative.) If any of the OSes where config.guess has to do more
work were to get this far in building and testing Git, they'd end up
running any code we stick at this spot anyway. So I think it still
makes more sense to put the new `case` next to the existing one.

One other thought I have from that config.guess example, though --
there are some cases there like this:

parisc64:Linux:*:* | hppa64:Linux:*:*)
echo hppa64-unknown-linux-"$LIBC"
exit ;;

That suggests to me that the condition should perhaps look for "hppa", too, like

parisc* | hppa*)
test_set_prereq HPPA
;;

What do you think?

Cheers,
Greg

Bug#960644: valgrind: Doesn't support D programming language demangling

[Witold Baryluk]

Hi Mark.

I will do that, and try to submit a code to that. valgrind looks to be
used pretty outdated libiberify code. It does have some support for
the D, but it doesn't support latest ABIs, and doesn't detect it
automatically.

As you already know, the valgrind has autodetection for rust, and same
can be done for dlang, to make user experience easier. I will talk to
valgrind about it.

Thanks for maintaining valgrind packages in Debian! Cheers.

On Fri, 15 May 2020 at 12:32, Mark Wielaard  wrote:
>
> Hi,
>
> On Fri, 2020-05-15 at 02:28 +, Witold Baryluk wrote:
> > Package: valgrind
> > Version: 1:3.15.0-1
> > Severity: normal
> >
> > It looks like valgrind doesn't support D programming language symbol
> > mangling (as emitted by DMD, GDC or LDC2 compilers);
> >
> > ==29535== valgrind: Unrecognised instruction at address 0x1b38db.
> > ==29535==at 0x1B38DB: _D3rcu__T3RCUTSQn1AZQl6updateMFNbPQuZv
> > (rcu.d:390)
> > ==29535==by 0x1B2F6F: _D3rcu6writerFZv (rcu.d:96)
> > ==29535==by 0x1B3230: _D3rcu4mainFAAyaZ9__lambda3FZv (rcu.d:600)
> > ==29535==by 0x1E52B7: _D4core6thread8osthread6Thread3runMFZv (in
> > /home/user/vps1/home/baryluk/Projekty/rcu.d/rcu)
> > ==29535==by 0x1FE929: thread_entryPoint (in
> > /home/user/vps1/home/baryluk/Projekty/rcu.d/rcu)
> > ==29535==by 0x487DF26: start_thread (pthread_create.c:479)
> > ==29535==by 0x49AD31E: clone (clone.S:95)
> >
> > That is a bit unfortunate. Most of this compilers allow to emulate
> > "C"
> > mangling in debug symbols (ldc2 -gc), but it interferes with other
> > things, and is not supported everywhere.
> >
> > gdb and objdump do demangle D symbols very well. I hope valgrind
> > could pick it up too?
>
> Best to file this upstream.
> Yes, it shouldn't be too hard to support.
> valgrind uses the same demangler as gdb and binutils.
> So since this works:
>
> $ echo _D4core6thread8osthread6Thread3runMFZv | c++filt -s dlang
> core.thread.osthread.Thread.run()
>
> valgrind just needs to know when to switch to "dlang". See
> coregrind/m_demangle/demangle.c where it already checks for "rust"
> demangling.
>
> Cheers,
>
> Mark

Bug#711135: Deadline Approaching: CLOUD COMPUTING 2020 || October 25 - 29, 2020 - Nice, France

[CLOUD COMPUTING 2020]

Greetings,

Note that CLOUD COMPUTING 2020 scheduled earlier in the year has been moved to 
October 25 - 29, 2020 in Nice, France. As such, we have additional time to 
reopen submissions to the conference.

In order to accommodate a large number of situations, we are offering the 
option for either physical presence or virtual participation. We would be 
delighted if all authors manage to attend, but are aware that special 
circumstances are best handled by having flexible options.

The new submission deadline is June 1.

Please consider to contribute to and/or forward to the appropriate groups the 
following opportunity to submit and publish original scientific results to:

- CLOUD COMPUTING 2020: The Eleventh International Conference on Cloud 
Computing, GRIDs, and Virtualization

Authors of selected papers will be invited to submit extended article versions 
to one of the IARIA Journals: http://www.iariajournals.org

=


CLOUD COMPUTING 2020: The Eleventh International Conference on Cloud Computing, 
GRIDs, and Virtualization

Event schedule: October 25 - 29, 2020 - Nice, France

Main page: https://www.iaria.org/conferences2020/CLOUDCOMPUTING20.html

Submission: https://www.iaria.org/conferences2020/SubmitCLOUDCOMPUTING20.html


Contributions:

- regular papers [in the proceedings, digital library]

- short papers (work in progress) [in the proceedings, digital library]

- ideas: two pages [in the proceedings, digital library]

- extended abstracts: two pages [in the proceedings, digital library]

- posters: two pages [in the proceedings, digital library]

- posters:  slide only [slide-deck posted at www.iaria.org]

- presentations: slide only [slide-deck posted at www.iaria.org]

- demos: two pages [posted at www.iaria.org]


Deadlines

Submission: June 1, 2020

Notification: July 1, 2020

Registration: July 14, 2020

Camera-ready: July 20, 2020


Call for papers: https://www.iaria.org/conferences2020/CfPCLOUDCOMPUTING20.html

Committees: https://www.iaria.org/conferences2020/ComCLOUDCOMPUTING20.html



Extended versions of selected papers will be published in IARIA Journals:  
http://www.iariajournals.org

Print proceedings will be available via Curran Associates, Inc.: 
http://www.proceedings.com/9769.html

Articles will be archived in the free access ThinkMind Digital Library: 
http://www.thinkmind.org


The topics suggested by the conference can be discussed in term of concepts, 
state of the art, research, standards, implementations, running experiments, 
applications, and industrial case studies. Authors are invited to submit 
complete unpublished papers, which are not under review in any other conference 
or journal in the following, but not limited to, topic areas.

All tracks are open to both research and industry contributions, in terms of 
Regular papers, Posters, Work in progress, Technical/marketing/business 
presentations, Demos, Tutorials, and Panels.

Before submission, please check and comply with the editorial rules: 
http://www.iaria.org/editorialrules.html



Topics:

TRENDS: New trends

Fog-computing; Mobile Edge Computing; Cloudlets; Hosted Cloud services (WebRTC, 
Containers, Cloud micro-services); Cloud computing and SDN/NFV; Cloud computing 
and 5G; Cloud computing and LTE Pro 4.5; Cloud computing ad Big Data; High 
performance computing (HPC) in the Cloud; Superfluid Clouds; Mobile Apps to the 
public Clouds; Vehicular Cloud networks; Cloud orchestration features; 
Converged edge systems; Cloud federation; Micro-cloud provider federation; 
Open-implementation Cloud infrastructures; Untrusted Cloud environments; 
Multiple Clouds and data centers; Power Constrained VMs; Cloud Green 
abstraction layer

CLOUD: Cloud computing

Cloud economics; Core cloud services; Cloud technologies; Cloud computing; 
On-demand computing models; Hardware-as-a-service; Software-as-a-service [SaaS 
applications]; Platform-as-service; Storage as a service in cloud; 
Data-as-a-Service; Service-oriented architecture (SOA); Cloud computing 
programming and application development; Scalability, discovery of services and 
data in Cloud computing infrastructures; Trust and clouds; Client-cloud 
computing challenges; Geographical constraints for deploying clouds

CLOUD: Challenging features

Privacy, security, ownership and reliability issues; Performance and QoS; 
Dynamic resource provisioning; Power-efficiency and Cloud computing; Load 
balancing; Application streaming; Cloud SLAs; Business models and pricing 
policies; Cloud service subscription models; Cloud standardized SLA; 
Cloud-related privacy; Cloud-related control; Managing applications in the 
clouds; Mobile clouds; Roaming services in Clouds; Agent-based cloud computing; 
Cloud brokering; Cloud contracts (machine readable); Cloud security; Security 
and assurance properties in cloud environments; Big Data Analytics in clouds; 
Cloud computing back-end solutions; Cloud applications portability; 
Cloud-native application design; 

Bug#954907: python3-dateparser: Warning with autopkgtest when python3.8 is default

[Emmanuel Arias]

Hi,

The warning is still happen on 0.7.4-1 version.

```
/tmp/autopkgtest.anahCe/build.ib1/src/dateparser/date.py:138: FutureWarning: 
Date formats should be list, tuple or set of strings
  warn(_DateLocaleParser.DATE_FORMATS_ERROR_MESSAGE, FutureWarning)
```

I will investigate.

Cheers,
eamanu

Bug#960738: simple-cdd: Does not mirror non-free or contrib

[Oliver]

Package: simple-cdd
Version: 0.6.7
Severity: normal
Tags: d-i

Dear Maintainer,

I am trying to build a CD via simple-cdd by running

build-simple-cdd --conf ./cd.conf

The contents of that conf file are:

mirror_components="non-free main contrib"
server=debian.osuosl.org
debian_mirror="http://debian.osuosl.org/debian/;
locale="en_US"
keyboard=us
dist=buster
profiles=revl
auto_profiles=revl

It does not mirror non-free or contrib. The build exits with a valid CD
but outputs:

2020-05-15 16:24:57 ERROR Last 2 lines of standard error:
2020-05-15 16:24:57 ERROR distcheck:: Fatal error in module common/input.ml:
2020-05-15 16:24:57 ERROR distcheck::  Input file 
/home/oliver/Documents/code/revl/configs/site-box/preseed/tmp/cd-build/buster/CD1/dists/buster/contrib/binary-amd64/Packages.gz
 does not exist.

It is also the case that neither `non-free` nor `contrib` is not mirrored and 
the
`tmp/mirror/dists/buster/X/ ../Packages.gz` file exists but is empty for
X = non-free or contrib.

I did notice that if I change `mirror_components="main contrib
non-free"` to `mirror_components="non-free main"` then I do get non-free
and main packages and it all seems to work (luckily I don't actually
need anything from contrib).


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

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

Versions of packages simple-cdd depends on:
ii  dctrl-tools 2.24-3
ii  debian-cd   3.1.25
ii  lsb-release 10.2019051400
ii  python3 3.7.3-1
ii  python3-simple-cdd  0.6.7
ii  reprepro5.3.0-1
ii  rsync   3.1.3-6
ii  wget1.20.1-1.1

Versions of packages simple-cdd recommends:
ii  dose-distcheck  5.0.1-12

Versions of packages simple-cdd suggests:
pn  qemu-system | qemu-kvm  

-- no debconf information

Bug#960688: fwupd: missing Breaks: fwupdate (<< 12-7)

[Andreas Beckmann]

On 15/05/2020 20.54, mario.limoncie...@dell.com wrote:
> Hopefully that illustrates the timeline.  As fwupdate is a transition package 
> now,
> I don't know that it makes sense to add the Breaks now, please advise.

Nothing forces the transitional fwupdate to be installed, thus the
package relationships allow some kind of partial upgrade: the
combination of fwupdate/buster and fwupd/bullseye to be installed at the
same time, which creates the mess. The Breaks will fix this - either
fwupdate from buster gets removed or upgraded to the transitional
package in bullseye if fwupd from bullseye is being installed.

Andreas

PS: Yes, I am searching for corner cases where things may go wrong.

Bug#950585: binutils-dev: included log files introduce reproducibility issues

[Paul Wise]

On Mon, 24 Feb 2020 14:09:23 -0800 Vagrant Cascadian wrote:

> Exploring avenues to put files like this into some separate artifact for
> things that are not reproducible might be one avenue

There is already the BYHAND (and automatic BYHAND) mechanisms for files
that get installed outside of pool/ in the Debian apt repository. Each
one needs support from dak too though.

https://salsa.debian.org/ftp-team/dak/-/tree/master/scripts/debian/
https://codesearch.debian.net/search?q=byhand+path%3Adebian=0

The other option would be to put the files in a test results .deb file,
but that would still mean repro-builds folks would compare them, unless
there were a naming convention that could be used to ignore them.

It strikes me that these files are most similar to .buildinfo or the
build logs in that they are data *about* the builds. I've wanted
maintainers to be able to also upload build logs with their binary
builds and started a WIP patch for that.

https://salsa.debian.org/pabs/dak/-/commits/maintainer-build-logs

It looks like dpkg-genchanges can already add more files through the
debian/files input file. I managed to get my build log included in my
.changes file using this mechanism. I then attempted to upload it to
the Debian archive, queued gladly accepted the upload but dak rejected
it saying that it looks like a BYHAND package:

   whowatch_1.8.6-2_amd64.changes: whowatch_1.8.6-1_amd64.build.log looks like 
a byhand package, but is in section build

I suggest that the dpkg-dev maintainer and the ftp-masters should be
talked to about this topic. Probably the right mechanism is to have a
convention in debian/files similar to how dbgsyms are represented and
similar to byhand but the files go into the pool like .deb files do.

   whowatch_1.8.6-1_amd64.build build optional automatic=yes
   whowatch-dbgsym_1.8.6-2_amd64.deb debug optional automatic=yes

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#960590: wolfssl: please make the libwolfssl.a file reproducible

[Felix Lechner]

Hi Chris,

On Fri, May 15, 2020 at 3:58 PM Chris Lamb  wrote:
>
>   * The "ignored" message is a warning, not an error.

Thanks for pointing it out. As someone not well-versed in reproducible
builds, I did not immediately understand the cause and appropriate
remedies. I asked upstream to revert [1], and will release a patched
version even if upstream does not.

Kind regards
Felix Lechner

[1] 
https://github.com/wolfSSL/wolfssl/commit/1b9cff1c5d09adb0af858992e2a2df01b1d4dc58#commitcomment-39214117

Bug#960737: libc6: on the Unicode character U+1F928 and above, iswctype returns false for all properties

[Vincent Lefevre]

Package: libc6
Version: 2.30-8
Severity: normal

On the Unicode character U+1F928 and above, iswctype returns false for
all properties. It should have the graph, print and punct properties.

-- System Information:
Debian Release: bullseye/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 5.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=C.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 libc6 depends on:
ii  libcrypt1  1:4.4.16-1
ii  libgcc-s1  10.1.0-1

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.0-1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.74
ii  glibc-doc  2.30-8
ii  libc-l10n  2.30-8
ii  locales2.30-8

-- debconf information:
* glibc/restart-services: postfix cups cron atd
  glibc/upgrade: true
* libraries/restart-without-asking: false
  glibc/disable-screensaver:
  glibc/kernel-not-supported:
  glibc/kernel-too-old:
  glibc/restart-failed:

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

Bug#893481: libapache2-mod-php: Upgrade to php7.2 disables the php module

[Bryce Harrington]

It looks like the logic in the upgrader flags as an error if there are
previous enabled php mods enabled in apache.  It's a bit of a hack but
for ubuntu I changed the logic to make it disable those other mods; for
Ubuntu we always only support a single php version at a time, so this
should work for us.  I'm not sure this is suitable for Debian since
sometimes multiple php versions are supported.  However, at least this
could point to where a more generalized solution could be developed.

https://bugs.launchpad.net/ubuntu/+source/php7.4/+bug/1865218

On Mon, 19 Mar 2018 15:29:48 +0530 Sunil Mohan Adapa  wrote:
> Package: libapache2-mod-php
> Version: 1:7.2+60
> Severity: important
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear Maintainer,
> 
> When an older version of libapache2-mod-php depending on libapache2-mod-php7.0
> is installed and upgraded to newer version, no php module is enabled.
> 
> One way to reproduce is as follows: first install an older version of
> libapache2-mode-php, such as in a fresh install of Debian stretch. This
> installs
> libapache2-mod-php7.0. Now upgrade to latest libapache2-mod-php, such as by
> upgrade to testing. This installs libapache2-mod-php7.2. However, php7.2 
> module
> is not enabled as php7.0 module is already enabled. After that, during
> autoremove, libapache2-mod-php7.0 is removed. Now, php7.0 is not
> enabled/installed and php7.2 is not enabled.
> 
> I expect that when libapache2-mod-php is installed, a php apache2 module is
> enabled and it stays that way even during upgrade from stable to testing.
> Currently, all FreedomBox users on testing are facing this issue due to
> dependency on libapache2-mod-php and the use of unattended-upgrades which auto
> removes packages.
> 
> For more details, see the following session (full logs are attached):
> 
> # apt install libapache2-mod-php
> 
> Edit /etc/apt/sources.list and s/stretch/testing/g
> 
> # apt update
> # apt dist-upgrade
> 
> [...]
> Setting up php-common (1:60) ...
> [...]
> Setting up php7.0-common (7.0.28-1) ...
> [...]
> Setting up libapache2-mod-php7.2 (7.2.3-1) ...
> Package apache2 is not configured yet. Will defer actions by package
> libapache2-mod-php7.2.
> 
> Creating config file /etc/php/7.2/apache2/php.ini with new version
> libapache2-mod-php7.2: php7.0 module already enabled, not enabling PHP 7.2
> [...]
> Setting up libapache2-mod-php7.0 (7.0.28-1) ...
> libapache2-mod-php7.0: not switching MPM - already enabled
> [...]
> 
> # a2query -m php7.0
> php7.0 (enabled by maintainer script)
> # a2query -m php7.2
> No module matches php7.2
> 
> # apt autoremove
> [...]
> The following packages will be REMOVED:


signature.asc
Description: PGP signature

Bug#960736: fig2dev crash in compute_closed_spline

[David Petek]

Package: fig2dev
Version: 3.2.7a

fig2dev crashes when processing certain fig files.
The crash happens in "compute_closed_spline" when trying to process
specially formatted "closed approximated spline" figure.

Steps to reproduce:
fig2dev -L png compute_closed_spline.fig

ASAN output:

AddressSanitizer:DEADLYSIGNAL
=
==7007==ERROR: AddressSanitizer: SEGV on unknown address 0x0008 (pc
0x004fd10e bp 0x7ffdbc347150 sp 0x7ffdbc346ed0 T0)
==7007==The signal is caused by a READ memory access.
==7007==Hint: address points to the zero page.
#0 0x4fd10e in compute_closed_spline (/tmp/fig2dev+0x4fd10e)
#1 0x4fdba8 in create_line_with_spline (/tmp/fig2dev+0x4fdba8)
#2 0x4f154e in read_splineobject (/tmp/fig2dev+0x4f154e)
#3 0x4e9d8c in read_objects (/tmp/fig2dev+0x4e9d8c)
#4 0x4e8426 in readfp_fig (/tmp/fig2dev+0x4e8426)
#5 0x4e8238 in read_fig (/tmp/fig2dev+0x4e8238)
#6 0x4ddbfb in main (/tmp/fig2dev+0x4ddbfb)
#7 0x7fd39e9c50b2 in __libc_start_main
/build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16
#8 0x41c67d in _start (/tmp/fig2dev+0x41c67d)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/tmp/fig2dev+0x4fd10e) in
compute_closed_spline
==7007==ABORTING

I am sending "compute_closed_spline.fig" in attachment.


Kind regards,

-- 
David Petek

Bug#960735: nvidia-legacy-390xx-kernel-dkms: doesn't compile with linux 5.7

[Jiri Palecek]

Package: nvidia-legacy-390xx-kernel-dkms
Version: 390.132-4
Severity: normal
Tags: patch

Dear Maintainer,

I was trying to test nvidia drivers with the new kernel in experimental
5.7.0-rc5-686-pae. In the build log, I noticed it failed due to missing
functions set_memory_array_wb and friends. However, the code seemed to
be prepared for that possibility, so the problem must be the conftest.

I checked the output from the compilation checks and found some are
failing for the wrong reason, which causes some functions to be wrongly
detected as present (!) and some wrongly detected as missing. This would
probably apply to the other branches of nvidia drivers as well. I
prepared a patch for this, some comments:

- asm/page.h and asm/pgtable.h are needed for the pgprop_t type. Some
  arches have here, some have it there. Otherwise the compilation
  wrongly fails and detects the functions as present

- atomic_long_t is pulled by including linux/atomic.h, not
  asm/atomic.h. Otherwise it's detected wrongly as absent

- linux/acpi.h is needed for acpi_status type

I checked that these files were present in the linux kernel since
2.6.39, but haven't tested compilation with such old kernels. It should,
however, work.

Please have a look at this.

Regards
Jiri Palecek


Index: nvidia-legacy-390xx-390.132/conftest.sh
===
--- nvidia-legacy-390xx-390.132.orig/conftest.sh
+++ nvidia-legacy-390xx-390.132/conftest.sh
@@ -406,6 +406,8 @@ compile_test() {
 # Determine if the set_memory_uc() function is present.
 #
 CODE="
+#include 
+#include 
 #if defined(NV_ASM_SET_MEMORY_H_PRESENT)
 #include 
 #else
@@ -423,6 +425,8 @@ compile_test() {
 # Determine if the set_memory_array_uc() function is present.
 #
 CODE="
+#include 
+#include 
 #if defined(NV_ASM_SET_MEMORY_H_PRESENT)
 #include 
 #else
@@ -475,6 +479,8 @@ compile_test() {
 # Determine if the set_pages_uc() function is present.
 #
 CODE="
+#include 
+#include 
 #if defined(NV_ASM_SET_MEMORY_H_PRESENT)
 #include 
 #else
@@ -1837,7 +1843,7 @@ compile_test() {
 # Determine if atomic_long_t and associated functions are defined
 # Added in 2.6.16 2006-01-06 d3cb487149bd706aa6aeb02042332a450978dc1c
 CODE="
-#include 
+#include 
 void conftest_atomic_long(void) {
 atomic_long_t data;
 atomic_long_read();
@@ -1851,7 +1857,7 @@ compile_test() {
 atomic64_type)
 # Determine if atomic64_t and associated functions are defined
 CODE="
-#include 
+#include 
 void conftest_atomic64(void) {
 atomic64_t data;
 atomic64_read();
@@ -3485,7 +3491,7 @@ compile_test() {
 # 2008-01-25  9ee85241fdaab358dff1d8647f20a478cfa512a1
 #
 CODE="
-#include 
+#include 
 int conftest_register_acpi_notifier(void) {
 return register_acpi_notifier();
 }"

-- Package-specific info:
uname -a:
Linux debian 5.5.0-1-686-pae #1 SMP Debian 5.5.13-2 (2020-03-30) i686 GNU/Linux

/proc/version:
Linux version 5.5.0-1-686-pae (debian-ker...@lists.debian.org) (gcc version 
9.3.0 (Debian 9.3.0-8)) #1 SMP Debian 5.5.13-2 (2020-03-30)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86 Kernel Module  390.132  Thu Oct 31 23:12:54 PDT 
2019
GCC version:  gcc version 9.3.0 (Debian 9.3.0-11)

lspci 'display controller [030?]':
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF106 [GeForce GTS 
450] [10de:0dc4] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. GF106 [GeForce GTS 450] [1043:8366]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video  226,   0 May 15 18:09 /dev/dri/card0
crw-rw+ 1 root render 226, 128 May 15 18:09 /dev/dri/renderD128
crw-rw-rw-  1 root root   195, 254 May 15 20:07 /dev/nvidia-modeset
crw-rw-rw-  1 root root   195,   0 May 15 20:07 /dev/nvidia0
crw-rw-rw-  1 root root   195, 255 May 15 20:07 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 May 15 18:09 pci-:02:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 May 15 18:09 pci-:02:00.0-render -> ../renderD128
video:x:44:

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Feb  4 18:05 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 

Bug#960688: fwupd: missing Breaks: fwupdate (<< 12-7)

[Mario.Limonciello]

Let me elaborate the timeline.

* Originally fwupdate contained /usr/bin/fwupdate.
* It was merged into fwupd and fwupdate went into maintenance only mode.
* In Debian we made fwupdate a transition package with nothing in it.
This is when the Replaces got put into place.

* Because it was a transition package, there is a chance that a user already
removed /var/lib/fwupdate and so a request was put in for fwupd to clean that 
up.

* Later, a compatibility binary /usr/bin/fwupdate was added into fwupd.
This performs similar actions as the old fwupdate provided /usr/bin/fwupdate.

Hopefully that illustrates the timeline.  As fwupdate is a transition package 
now,
I don't know that it makes sense to add the Breaks now, please advise.


> -Original Message-
> From: Andreas Beckmann 
> Sent: Friday, May 15, 2020 7:28 AM
> To: Debian Bug Tracking System
> Subject: Bug#960688: fwupd: missing Breaks: fwupdate (<< 12-7)
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupd
> Version: 1.3.9-4
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts replaces-without-breaks
> 
> Hi,
> 
> during a test with piuparts and DOSE tools I noticed your package causes
> removal of files that also belong to another package.
> This is caused by using Replaces without corresponding Breaks.
> 
> The installation sequence to reproduce this problem is
> 
>   apt-get install fwupdate/stable
>   # (1)
>   apt-get install fwupd
>   apt-get remove fwupd
>   # (2)
> 
> The list of installed files at points (1) and (2) should be identical,
> but the following files have disappeared:
> 
>   /usr/bin/fwupdate
>   /usr/share/man/man1/fwupdate.1.gz
>   /var/lib/fwupdate/
> 
> This is a serious bug violating policy 7.6, see
> https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-
> files-and-replacing-packages-replaces
> and also see the footnote that describes this incorrect behavior:
> https://www.debian.org/doc/debian-policy/ch-relationships.html#id13
> 
> The fwupd package has the following relationships with fwupdate:
> 
>   Conflicts: n/a
>   Breaks:n/a
>   Replaces:  fwupdate (<< 12-7)
>   Provides:  fwupdate
> 
> >From the attached log (scroll to the bottom...):
> 
> 0m32.0s ERROR: FAIL: After purging files have disappeared:
>   /usr/bin/fwupdate  owned by: fwupd
>   /usr/share/man/man1/fwupdate.1.gz  owned by: fwupd
>   /var/lib/fwupdate/ owned by: fwupdate
> 
> 0m32.0s ERROR: FAIL: After purging files have been modified:
>   /var/lib/dpkg/info/fwupdate.list   not owned
> 
> 
> cheers,
> 
> Andreas

Bug#955469: initramfs-tools-core: Enable zstandard support

[Ben Hutchings]

On Wed, 2020-04-29 at 21:36 +0200, Norbert Lange wrote:
> Am Mittwoch, 29. April 2020 schrieb Ben Hutchings :
> 
> > On Tue, 2020-04-28 at 04:43 +0100, Ben Hutchings wrote:
> > > On Wed, 01 Apr 2020 09:05:22 +0200 Norbert Lange 
> > wrote:
> > > > Package: initramfs-tools-core
> > > > Version: 0.136
> > > > Severity: wishlist
> > > > Tags: patch
> > > > 
> > > > Hello,
> > > > 
> > > > there are Kernelpatches for zstandard initramfs support
> > > > available for several years, and will hopefully accepted
> > > > upstream soon.
> > > 
> > > If the kernel doesn't yet support it, I'm not sure what the point of
> > > supporting it in initramfs-tools is.
> > [...]
> > 
> > I see that the kernel support for this has been submitted recently,
> > though it's not clear which maintainer is being asked to apply the
> > patches.
> 
> It's been submitted multiple times over the years, I don't know the lkml
> workings, and apparently the author of these changes is missing some detail
> too.
> 
> Could you kindky point to what's missing? Sending the pull request directly
> (not cc) to a maintainer?
[...]

There doesn't seem to be a nominated maintainer for lib/decompress*.c,
but Andrew Morton  has signed-off most of
the changes there in the past few years.

So I would suggest bringing the kernel patch series to his attention. 
(He only works with patches, not pull requests.)

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.



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

Bug#960368: Patch to avoid segfault in kallisto

[Pranav Ballaney]

Hi,
I investigated the segfault issue in kallisto, and found a fix for it.
Details can be found at
https://github.com/pachterlab/kallisto/issues/254#issuecomment-629546051

I've written a patch to avoid the segfault, for the time being,
until upstream fixes it.
Please take a look.
https://salsa.debian.org/med-team/kallisto

Regards,
Pranav
ᐧ

Bug#960702: ethtool -m values change when output is redirected

[Ben Hutchings]

Control: tag -1 moreinfo

On Fri, 2020-05-15 at 15:02 +, Yannis Aribaud wrote:
> Package: ethtool
> Version: 1:4.19-1
> Severity: important
> I'm facing a very strange behavior. The command ethtool -m  report
> the transceiver DOM values correctly, but when the command output is
> redirected to an other program, values change to somthing else.
[...]
> As you can see alsmost all mesuring values (C, V, mA and dBm) change.
> The values when output is redirected are unreliable which makes it
> impossible to use in a script. 

I suspect that ethtool is actually getting garbage data from the
driver.

> I am using Debian GNU/Linux 10 (buster), kernel 4.19.0-9-amd64 #1 SMP
> Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux and libc6 2.28-10

And which network driver are you using?

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.




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

Bug#960692: src:netbeans: Please add support to build against libjson-simple-java >= 3

[Markus Koschany]

Hi Gilles,

Am 15.05.20 um 15:43 schrieb Gilles Filippini:
> Package: src:netbeans
> Version: 10.0-3
> Severity: normal
> Tags: patch
>
> Hi,
> 
> I'd like to transition json-simple 3.1.1 to unstable, but netbeans is a 
> blocker since it builds against libjson-simple-java << 3 only.

[...]

As I have previously announced on the debian-java mailing list, I
believe netbeans will be removed from Debian. It is already affected by
RC bugs, so I don't think it should be a blocker for json-simple. You
can just ignore it, if you don't want to be the maintainer of netbeans.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#957169: efl: ftbfs with GCC-10

[Ross Vandegrift]

Control: fixed -1 efl/1.24.0-1
Control: tags -1 fixed-in-experimental

On Fri, Apr 17, 2020 at 10:59:25AM +, Matthias Klose wrote:
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
> 
> The package fails to build in a test rebuild on at least amd64 with
> gcc-10/g++-10, but succeeds to build with gcc-9/g++-9.

Upstream release 1.24.0 (and later) contain a fix for builds w/gcc 10.  That is
now in experimental.  I've confirmed that the build succeeds.

Leaving open as requested.

Ross

Bug#960734: sensible-utils: does not execute shell in EDITOR and VISUAL

[brian m. carlson]

Package: sensible-utils
Version: 0.0.12+nmu1
Severity: normal
Tags: patch

It is generally possible in EDITOR and VISUAL to place arbitrary shell.
For example, one can write something like the following:

  export VISUAL='f(){ if [ -n "$DISPLAY" ]; then gvim -f "$@"; else vim "$@"; 
fi; };f'

This is supported by every program I can find which uses EDITOR and
VISUAL, including less, crontab, mutt, and git.  It is my understanding
that supporting this is intentional, because otherwise it is impossible
to place quoted arguments inside a shell value, like so:

  export VISUAL='vim +"setf perl"'

However, sensible-editor does not support that.  It does perform shell
word splitting, but shell word splitting is not sufficient to handle the
cases mentioned above.

I've submitted a merge request at
https://salsa.debian.org/debian/sensible-utils/-/merge_requests/4 to
implement this behavior, add a test, and improve the existing test to be
more robust.

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

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

-- no debconf information

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


signature.asc
Description: PGP signature

Bug#960733: rrdtool update with invalid DS format corrupts rrd file

[Joey Hess]

Package: rrdtool
Version: 1.7.2-3+b4
Severity: normal

joey@darkstar:~> rrdtool create foo.rrd DS:foo:GAUGE:1:10:1000 
RRA:AVERAGE:0.5:1:864000
joey@darkstar:~> rrdtool update foo.rrd N:100
joey@darkstar:~> rrdtool tune foo.rrd DS:xxx
ERROR: invalid DS format
- exit 1

That tune looks like it would have failed to do anything, but in fact
it's added a weird DS to the file.

So now updates will fail:

joey@darkstar:~> rrdtool update foo.rrd N:100
ERROR: foo.rrd: expected 2 data source readings (got 1) from N
- exit 1
joey@darkstar:~> rrdtool update foo.rrd N:100:1
ERROR: unknown data acquisition function '0'

rrdtool dump shows that it added a DS with an empty name and bogus type.


   
 0 
0
0.0002525175e-308
0.0001931016e-308


1
0.00e+00
 194 


The empty name also makes it hard to delete it, because "DEL:" will not
refer to it. The only way I found to recover my data was to edit the xml
dump, putting in a name, and then load and delete it.

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

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

Versions of packages rrdtool depends on:
ii  libc6 2.30-4
ii  libglib2.0-0  2.64.2-1
ii  librrd8   1.7.2-3+b4

rrdtool recommends no packages.

Versions of packages rrdtool suggests:
pn  librrds-perl  

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#960713: pkg-php-tools: Support loading debhelper addons from Build-Depends

[Robin Gustafsson]

Package: pkg-php-tools
Version: 1.39
Severity: wishlist
Tags: patch

Dear Maintainer,

Please consider supporting the newer (debhelper >= 11) way of loading
addon sequences directly from Build-Depends. That is, Provide the
virtual packages dh-sequence-phpcomposer and dh-sequence-phppear.

A (very small) patch is attached.

Regards,
Robin
>From 9ac466e0f2a059eb966fefd1a03786155dffb762 Mon Sep 17 00:00:00 2001
From: Robin Gustafsson 
Date: Fri, 15 May 2020 20:45:14 +0200
Subject: [PATCH] Provide dh add-on sequences for Build-Depends

The package now provides both dh-sequence-phpcomposer and
dh-sequence-phppear to support the alternative way of loading
debhelper add-on sequences through Build-Depends.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 7d39c47..2302f06 100644
--- a/debian/control
+++ b/debian/control
@@ -18,6 +18,7 @@ Package: pkg-php-tools
 Architecture: all
 Depends: debhelper, php-pear, php-cli, php-json, php-xml, ${misc:Depends}
 Suggests: dh-make
+Provides: dh-sequence-phpcomposer, dh-sequence-phppear
 Description: various packaging tools and scripts for PHP packages
  Provide an easy way to package PHP PEAR, PECL and Composer packages: Run
  dh_make, edit debian/rules and debian/control and that's it!
-- 
2.20.1

Bug#960590: wolfssl: please make the libwolfssl.a file reproducible

[Chris Lamb]

Felix,

> I would like to ask upstream to revert [1], but Ubuntu is a
> Debian-derivative. Should our binutils be built differently (or have
> they changed since [1] was authored)?

I read this question as a false dichotomy, or at we are focusing on
the wrong thing here. Let us take a few steps back -- here are my
assumptions and inferences, do let me know if any of them are wrong:

  * We do not want these timestamps inside the .ar archive.

  * It appears that wolfssl wishes to include them (infered from their
inclusion of "U")

  * The "ignored" message is a warning, not an error. On my local
system it does not appear to cause a failure to create an ar
archive.

  * Debian has configured binutils with --enable-deterministic-
archives since March 2015.

>From a narrow point of view, I do not mind what steps are taken so
that wolfssl does not embed this metadata, but I sincerely doubt
asking binutils to change a compile flag is the right way to go (or
will be effective).


Regards,

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

Bug#960732: Segmentation fault with true-color escape sequences in :term

[Josh Triplett]

Package: neovim
Version: 0.4.3-3
Severity: normal

Steps to reproduce:

Install the "mpv" package.
Run nvim.
Use :term to open a terminal.
Within the terminal, run "mpv --quiet --vo=tct some-video-file.webm".

The terminal will display garbage for a bit, then nvim will segfault.

This happens whether or not you run ":set termguicolors" first.

This does not happen with vim.

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

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

Versions of packages neovim depends on:
ii  libc62.30-8
ii  libluajit-5.1-2  2.1.0~beta3+dfsg-5.1
ii  libmsgpackc2 3.0.1-3
ii  libtermkey1  0.22-1
ii  libunibilium42.1.0-1
ii  libuv1   1.35.0-2
ii  libvterm00.1.3-1
ii  lua-luv  1.30.1-1-2
ii  neovim-runtime   0.4.3-3

Versions of packages neovim recommends:
pn  python3-neovim  
ii  xsel1.2.0+git9bfc13d.20180109-3
ii  xxd 2:8.2.0716-3

Versions of packages neovim suggests:
pn  ctags
ii  vim-scripts  20180807

-- no debconf information

Bug#925754: Fwd: Fixed in newer release of libopenshot / libopenshot-audio

[John Scott]

On Sat, 25 Apr 2020 21:40:14 -0400 FeRD  wrote:
> If Debian maintains JUCE as a distro package, and it would be a compatible
> alternative to our JUCE-based "libopenshot-audio", I don't see any reason we
> can't add an option to libopenshot's CMake configuration that tells it to
> just
> use those libs, completely replacing libopenshot-audio ? which would
> become entirely superfluous in that scenario.
> 
> This is the perfect time to do it, too, as I've been gutting and reworking
> large parts
> of libopenshot's build system recently ? sticking in a "USE_SYSTEM_JUCE"
> option would be no trouble at all.
> 
> Is there an importable CMake configuration for the distro JUCE package, by
> any chance, or should I put together a find module as well?

That would be terrific. The version of JUCE that you updated is almost the same 
version as the Debian package, so I expect that would work well.

There doesn't appear to be a CMake module. If you would create one or add an 
option to specify the path, that'd be the cleanest solution.

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

Bug#936804: knockpy - python3

[Scott Talbert]

Hi,

Looks like someone did a patch to port knockpy to Python 3:
https://github.com/guelfoweb/knock/pull/71

Regards,
Scott

Bug#960731: ITP: evil-winrm -- Ultimate WinRM shell for hacking/pentesting

[Pedro Loami Barbosa dos Santos]

Package: wnpp
Severity: wishlist
Owner: Pedro Loami Barbosa dos Santos 

* Package name: evil-winrm
  Version : 2.3
  Upstream Author : Óscar Alfonso Díaz 
* URL : https://github.com/Hackplayers/evil-winrm
* License : LGPL-3
  Programming Lang: ruby
  Description : Ultimate WinRM shell for hacking/pentesting

 This shell is the ultimate WinRM shell for hacking/pentesting.
 .
 WinRM (Windows Remote Management) is the Microsoft implementation of
 WS-Management Protocol. A standard SOAP based protocol that allows hardware
 and operating systems from different vendors to interoperate. Microsoft
 included it in their Operating Systems in order to make life easier to system
 administrators.
 .
 This program can be used on any Microsoft Windows Servers with this feature
 enabled (usually at port 5985), of course only if you have credentials and
 permissions to use it. So it can be said that it could be used in a post-
 exploitation hacking/pentesting phase. The purpose of this program is to
 provide nice and easy-to-use features for hacking. It can be used with
 legitimate purposes by system administrators as well but the most of its
 features are focused on hacking/pentesting stuff.



 This program is really useful while performing penetration testing,
 security auditing, vulnerability analysis, or just playing at some CTF
 box. With a system credential in hand, accessing winrm is usually an initial 
 foothold for entering the machine and starting running commands,
 and for that evil-winrm is great. It also allows other things like,  
 uploading/downloading files, loading binaries/scripts in memory, using 
pass-the-hash,etc.

 It should be a great package to Debian as it's a great tool to
 a security professional to have on his/her machine.

 I intend to maintain this package mentored by a friend DD, although any 
suggestions or contributions will be welcome.  

Bug#960730: libanyevent-irc-perl: does not verify TLS server certificates

[Benjamin Barenblat]

Package: libanyevent-irc-perl
Version: 0.97-2
Control: tag -1 + upstream

AnyEvent::IRC supports connecting to IRC servers over TLS. When
connecting, though, it does not verify that server certificates are
valid. An invalid TLS certificate is better than no TLS at all, but
users (and many developers) have come to expect that a successful TLS
connection guarantees confidentiality, authenticity, and integrity even
in the face of active interception. AnyEvent::IRC’s behavior is
inconsistent with that expectation.

Ideally, AnyEvent::IRC would refuse to connect to a server unless that
server presents a valid TLS certificate or the API consumer has
explicitly opted out of certificate verification. If backward
compatibility is a concern, AnyEvent::IRC could could preserve the
existing behavior by default but allow API consumers to opt in to
certificate verification; this is a smaller improvement, but it would be
an improvement nonetheless.

Bug#960728: openblas: please consider adding openblas_get_config() to libblas.so.3

[Mike Miller]

Source: openblas
Version: 0.3.9+ds-1
Severity: wishlist

Dear Maintainer,

Please consider including the 'openblas_get_config' extension function
in the libblas.so.3 shared library provided by all OpenBLAS flavors.

In previous versions of the libopenblas-base library package, it was
possible to have a program dynamically load libblas.so.3, then use dlsym
to look for the symbol 'openblas_get_config' to determine if OpenBLAS
was being used and display the version and configuration. As an example,
Octave uses this to determine if the BLAS library in use is OpenBLAS or
MKL or ATLAS or something else. This is no longer possible.

I also plan on adding a fallback to Octave to look for other OpenBLAS
symbols, so it can at least report that it's *some* OpenBLAS.

Thanks for all the great work maintaining OpenBLAS.

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#960729: autopkgtest-build-qemu fails to create ubuntu focal image due to missing ifupdown

[Andreas Beckmann]

Package: autopkgtest
Version: 5.13.1
Severity: normal

On a Debian (buster + some bullseye) host:

# autopkgtest-build-qemu focal 
/var/cache/autopkgtest/autopkgtest-focal-amd64.img 
http://archive.ubuntu.com/ubuntu amd64 
Detected local apt proxy, using http://10.0.2.2:3128 as virtual machine proxy
Load spec file /tmp/tmp.4DIXmjC38N
Exec: ['qemu-img', 'create', '-f', 'raw', 
'/var/cache/autopkgtest/autopkgtest-focal-amd64.img.raw', '25G']
Exec: ['parted', '-s', 
'/var/cache/autopkgtest/autopkgtest-focal-amd64.img.raw', 'mklabel', 'msdos']
Exec: ['parted', '-m', 
'/var/cache/autopkgtest/autopkgtest-focal-amd64.img.raw', 'print']
Exec: ['parted', '-s', 
'/var/cache/autopkgtest/autopkgtest-focal-amd64.img.raw', 'mkpart', 'primary', 
'ext2', '0%', '100%']
Exec: ['kpartx', '-asv', 
'/var/cache/autopkgtest/autopkgtest-focal-amd64.img.raw']
remembering /dev/mapper/loop0p1 as root
Exec: ['/sbin/mkfs', '-t', 'ext4', '/dev/mapper/loop0p1']
Exec: ['mount', '/dev/mapper/loop0p1', '/tmp/tmpan9mvw2f']
Exec: ['debootstrap', '--variant', '-', 'focal', '/tmp/tmpan9mvw2f', 
'http://archive.ubuntu.com/ubuntu']
Exec: ['chroot', '/tmp/tmpan9mvw2f', 'apt-get', 'update']
Exec: ['chroot', '/tmp/tmpan9mvw2f', 'apt-get', 'update']
Exec: ['chroot', '/tmp/tmpan9mvw2f', 'apt-get', '-y', '--no-show-progress', 
'install', 'eatmydata']
Exec: ['chroot', '/tmp/tmpan9mvw2f', 'eatmydata', 'apt-get', 'update']
Exec: ['chroot', '/tmp/tmpan9mvw2f', 'eatmydata', 'apt-get', '-y', 
'--no-show-progress', 'install', 'linux-image-virtual', 'ifupdown']
ERROR: Command failed: chroot /tmp/tmpan9mvw2f eatmydata apt-get -y 
--no-show-progress install linux-image-virtual ifupdown
b'Reading package lists...\nBuilding dependency tree...\nReading state 
information...\nPackage ifupdown is not available, but is referred to by 
another package.\nThis may mean that the package is missing, has been 
obsoleted, or\nis only available from another source\n\n'
b"E: Package 'ifupdown' has no installation candidate\n"
Something went wrong, cleaning up!
Exec: ['umount', '/tmp/tmpan9mvw2f']
Exec: ['kpartx', '-dsv', 
'/var/cache/autopkgtest/autopkgtest-focal-amd64.img.raw']

Looks like ifupdown is in universe since eoan.

The "newest" ubuntu image I could create was bionic, disco failed with a 
missing key ...


Andreas

-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (865, 'stable-updates'), (865, 'stable'), (864, 
'proposed-updates'), (700, 'testing'), (600, 'unstable'), (500, 
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'oldstable-updates'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldstable-debug'), (500, 'oldoldstable'), (500, 'oldstable'), (130, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages autopkgtest depends on:
ii  apt-utils   1.8.2
ii  libdpkg-perl1.19.7
ii  procps  2:3.3.15-2
ii  python3 3.7.3-1
ii  python3-debian  0.1.35

Versions of packages autopkgtest recommends:
ii  autodep8  0.22+nmu1

Versions of packages autopkgtest suggests:
pn  lxc   
pn  lxd   
ii  ovmf  0~20181115.85588389-3+deb10u1
ii  qemu-efi-aarch64  0~20181115.85588389-3+deb10u1
ii  qemu-efi-arm  0~20181115.85588389-3+deb10u1
ii  qemu-system   1:3.1+dfsg-8+deb10u5
ii  qemu-utils1:3.1+dfsg-8+deb10u5
ii  schroot   1.6.10-6+b1
ii  vmdb2 0.13.2+git20190215-1

-- no debconf information

Bug#960710: RFS: adios2/2.6.0-1 [ITP] -- ADIOS2 Adaptable IO system for simulations

[Kyle Edwards]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "adios2":

 * Package name: adios2
   Version : 2.6.0-1
   Upstream Author : UT-BATTELLE, LLC
 * URL : https://github.com/ornladios/ADIOS2
 * License : Apache
 * Vcs : https://gitlab.kitware.com/debian/adios2
   Section : libs

It builds those binary packages:

  adios2-scripts - ADIOS2 Adaptable IO system for simulations - scripts
  adios2-serial-bin - ADIOS2 Adaptable IO system for simulations -
binary tools (serial)
  libadios2-serial-core - ADIOS2 Adaptable IO system for simulations -
core libraries (serial)
  libadios2-serial-core-dev - ADIOS2 Adaptable IO system for
simulations - core development files (serial)
  libadios2-serial-c - ADIOS2 Adaptable IO system for simulations - C
binding libraries (serial)
  libadios2-serial-c-dev - ADIOS2 Adaptable IO system for simulations -
C binding development files (serial)
  libadios2-serial-c++11 - ADIOS2 Adaptable IO system for simulations -
C++11 binding libraries (serial)
  libadios2-serial-c++11-dev - ADIOS2 Adaptable IO system for
simulations - C++11 binding development files (serial)
  libadios2-serial-fortran - ADIOS2 Adaptable IO system for simulations
- Fortran binding libraries (serial)
  libadios2-serial-fortran-dev - ADIOS2 Adaptable IO system for
simulations - Fortran binding development files (serial)
  python3-adios2-serial - ADIOS2 Adaptable IO system for simulations -
Python bindings (serial)
  adios2-openmpi-bin - ADIOS2 Adaptable IO system for simulations -
binary tools (OpenMPI)
  libadios2-openmpi-core - ADIOS2 Adaptable IO system for simulations -
core libraries (OpenMPI)
  libadios2-openmpi-core-dev - ADIOS2 Adaptable IO system for
simulations - core development files (OpenMPI)
  libadios2-openmpi-c - ADIOS2 Adaptable IO system for simulations - C
binding libraries (OpenMPI)
  libadios2-openmpi-c-dev - ADIOS2 Adaptable IO system for simulations
- C binding development files (OpenMPI)
  libadios2-openmpi-c++11 - ADIOS2 Adaptable IO system for simulations
- C++11 binding libraries (OpenMPI)
  libadios2-openmpi-c++11-dev - ADIOS2 Adaptable IO system for
simulations - C++11 binding development files (OpenMPI)
  libadios2-openmpi-fortran - ADIOS2 Adaptable IO system for
simulations - Fortran binding libraries (OpenMPI)
  libadios2-openmpi-fortran-dev - ADIOS2 Adaptable IO system for
simulations - Fortran binding development files (OpenMPI)
  python3-adios2-openmpi - ADIOS2 Adaptable IO system for simulations -
Python bindings (OpenMPI)

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

  https://gitlab.kitware.com/debian/adios2

Regards,

--
  Kyle Edwards

Bug#960727: errors during upgrade

[Michael Biebl]

Package: python3-distutils
Version: 3.8.3-2
Severity: minor

During upgrade I got the following errors:

python3-lib2to3 (3.8.3-2) wird eingerichtet ...
find: ‘/usr/lib/python3.7/lib2to3’: Datei oder Verzeichnis nicht gefunden
find: ‘/usr/lib/python3.7/lib2to3’: Datei oder Verzeichnis nicht gefunden
find: ‘/usr/lib/python3.7’: Datei oder Verzeichnis nicht gefunden
gir1.2-ibus-1.0:amd64 (1.5.22-5) wird eingerichtet ...
libctf0:amd64 (2.34-8) wird eingerichtet ...
python3-distutils (3.8.3-2) wird eingerichtet ...
find: ‘/usr/lib/python3.7/distutils’: Datei oder Verzeichnis nicht gefunden
find: ‘/usr/lib/python3.7/distutils’: Datei oder Verzeichnis nicht gefunden
find: ‘/usr/lib/python3.7’: Datei oder Verzeichnis nicht gefunden

They appear to be harmless but are confusing nontheless.



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

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

Versions of packages python3-distutils depends on:
ii  python3  3.8.2-3
ii  python3-lib2to3  3.8.3-2

python3-distutils recommends no packages.

python3-distutils suggests no packages.

-- no debconf information

Bug#960726: firefox: connection failure to most https websites

[Vincent Lefevre]

Package: firefox
Version: 76.0.1-1
Severity: grave
Justification: renders package unusable

The connection to many https websites fails, e.g.

https://www.google.com/

  Secure Connection Failed

  An error occurred during a connection to www.google.com. The OCSP
  server experienced an internal error.

  Error code: SEC_ERROR_OCSP_SERVER_ERROR

(no issue with firefox-esr). Ditto for https://www.mpfr.org/ and others.

https://support.mozilla.org/1/firefox/76.0.1/Linux/en-US/connection-not-secure

  Secure Connection Failed

  The page you are trying to view cannot be shown because the
  authenticity of the received data could not be verified.

or the SEC_ERROR_OCSP_SERVER_ERROR error like above.

-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: bullseye/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 5.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=C.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 firefox depends on:
ii  debianutils 4.9.1
ii  fontconfig  2.13.1-4.2
ii  libatk1.0-0 2.36.0-2
ii  libc6   2.30-8
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libdbus-1-3 1.12.16-2
ii  libdbus-glib-1-20.110-5
ii  libevent-2.1-7  2.1.11-stable-1
ii  libffi7 3.3-4
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.1-2
ii  libgcc-s1   10.1.0-1
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-4
ii  libglib2.0-02.64.2-1
ii  libgtk-3-0  3.24.20-1
ii  libnspr42:4.25-1
ii  libnss3 2:3.52-1
ii  libpango-1.0-0  1.44.7-4
ii  libstdc++6  10.1.0-1
ii  libvpx6 1.8.2-1
ii  libx11-62:1.6.9-2+b1
ii  libx11-xcb1 2:1.6.9-2+b1
ii  libxcb-shm0 1.14-2
ii  libxcb1 1.14-2
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.5-2
ii  libxext62:1.3.3-1+b2
ii  libxfixes3  1:5.0.3-2
ii  libxrender1 1:0.9.10-1
ii  libxt6  1:1.1.5-1+b3
ii  procps  2:3.3.16-4
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages firefox recommends:
ii  libavcodec57  7:3.4.3-1
ii  libavcodec58  7:4.2.2-1+b1

Versions of packages firefox suggests:
ii  fonts-lmodern  2.004.5-6
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-7
ii  libgtk2.0-02.24.32-4
ii  pulseaudio 13.0-5

-- no debconf information

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

Bug#953205: Possibly fixed in Testing

[Soren Stoutner]

With the updates in Testing as of 5/15/20, this appears to no longer be 
an issue (probably because of some updated dependency). Now it is the 
opposite:  if `require "uri/generic"` is commented out, an error is 
produced.  If it is not commented out, updates to Redmine work correctly.


--
Soren Stoutner
Small Business Tech Solutions
623-262-6169
so...@smallbusinesstech.net

Bug#960725: libjs-popper.js: poper.js is a wrong symlink

[Francesco Potortì]

Package: libjs-popper.js
Version: 1.16.0+ds2-1
Severity: important

The symbolic link /usr/share/javascript/popper.js points to a directory,
rather than the popper.js file

$ ls -l /usr/share/javascript/popper.js
lrwxrwxrwx 1 root root 24 Dec  8 13:29 /usr/share/javascript/popper.js -> 
../nodejs/popper.js/dist

$ ls -ld /usr/share/nodejs/jquery/dist
drwxr-xr-x 2 root root 4096 May 11 06:49 /usr/share/nodejs/jquery/dist

$ ls -l /usr/share/nodejs/jquery/dist
total 672
-rw-r--r-- 1 root root 275451 May  6 11:09 jquery.js
-rw-r--r-- 1 root root  87681 May  6 11:09 jquery.min.js
-rw-r--r-- 1 root root  27652 May  6 11:09 jquery.min.js.br
-rw-r--r-- 1 root root  29483 May  6 11:09 jquery.min.js.gz
-rw-r--r-- 1 root root 135646 May  6 11:09 jquery.min.map
-rw-r--r-- 1 root root  49151 May  6 11:09 jquery.min.map.br
-rw-r--r-- 1 root root  51415 May  6 11:09 jquery.min.map.gz


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

Kernel: Linux 5.3.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=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=C:en_GB:en:en_US:it:fr:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libjs-popper.js depends on:
ii  javascript-common  11

Versions of packages libjs-popper.js recommends:
ii  node-jquery  3.5.1+dfsg-3

libjs-popper.js suggests no packages.

-- no debconf information

Bug#960724: mark golang-github-mitchellh-iochan-dev Multi-Arch: foreign

[Helmut Grohne]

Package: golang-github-mitchellh-iochan-dev
Version: 0.0~git20150529.0.87b45ff-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 src:gox src:packer

Please mark golang-github-mitchellh-iochan-dev to help making the
build-depends of the affected packages cross-satisfiable. In general,
Architecture: all packages can never satisfy cross Build-Depends unless
marked Multi-Arch: foreign or annotated :native. The foreign marking is
reasonable here as golang-github-mitchellh-iochan-dev entirely lacks
dependencies and maintainer scripts. From a multiarch pov, it is a data
package. Please consider applying the attached patch.

Helmut
diff --minimal -Nru 
golang-github-mitchellh-iochan-0.0~git20150529.0.87b45ff/debian/changelog 
golang-github-mitchellh-iochan-0.0~git20150529.0.87b45ff/debian/changelog
--- golang-github-mitchellh-iochan-0.0~git20150529.0.87b45ff/debian/changelog   
2017-07-27 13:43:58.0 +0200
+++ golang-github-mitchellh-iochan-0.0~git20150529.0.87b45ff/debian/changelog   
2020-05-15 23:03:44.0 +0200
@@ -1,3 +1,10 @@
+golang-github-mitchellh-iochan (0.0~git20150529.0.87b45ff-3.1) UNRELEASED; 
urgency=medium
+
+  * Non-maintainer upload.
+  * Mark golang-github-mitchellh-iochan-dev Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 15 May 2020 23:03:44 +0200
+
 golang-github-mitchellh-iochan (0.0~git20150529.0.87b45ff-3) unstable; 
urgency=medium
 
   * Adopt package (Closes: #865334).
diff --minimal -Nru 
golang-github-mitchellh-iochan-0.0~git20150529.0.87b45ff/debian/control 
golang-github-mitchellh-iochan-0.0~git20150529.0.87b45ff/debian/control
--- golang-github-mitchellh-iochan-0.0~git20150529.0.87b45ff/debian/control 
2017-07-27 13:43:58.0 +0200
+++ golang-github-mitchellh-iochan-0.0~git20150529.0.87b45ff/debian/control 
2020-05-15 23:03:43.0 +0200
@@ -15,6 +15,7 @@
 
 Package: golang-github-mitchellh-iochan-dev
 Architecture: all
+Multi-Arch: foreign
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Description: Go library for turning `io.Reader` into channels

Bug#960723: mark golang-github-kjk-lzma-dev Multi-Arch: foreign

[Helmut Grohne]

Package: golang-github-kjk-lzma-dev
Version: 1.0.0-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:aptly src:debiman src:golang-github-pointlander-peg 
src:minica src:pk4 src:ratt

Please mark golang-github-kjk-lzma-dev to help making the build-depends
of the affected packages cross-satisfiable. In general, Architecture:
all packages can never satisfy cross Build-Depends unless marked
Multi-Arch: foreign or annotated :native. The foreign marking is
reasonable here as golang-github-kjk-lzma-dev entirely lacks
dependencies and maintainer scripts. From a multiarch pov, it is a data
package. Please consider applying the attached patch.

Helmut
diff --minimal -Nru golang-github-kjk-lzma-1.0.0/debian/changelog 
golang-github-kjk-lzma-1.0.0/debian/changelog
--- golang-github-kjk-lzma-1.0.0/debian/changelog   2018-09-15 
08:36:44.0 +0200
+++ golang-github-kjk-lzma-1.0.0/debian/changelog   2020-05-15 
22:46:06.0 +0200
@@ -1,3 +1,10 @@
+golang-github-kjk-lzma (1.0.0-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark golang-github-kjk-lzma-dev Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 15 May 2020 22:46:06 +0200
+
 golang-github-kjk-lzma (1.0.0-5) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru golang-github-kjk-lzma-1.0.0/debian/control 
golang-github-kjk-lzma-1.0.0/debian/control
--- golang-github-kjk-lzma-1.0.0/debian/control 2018-09-15 08:36:44.0 
+0200
+++ golang-github-kjk-lzma-1.0.0/debian/control 2020-05-15 22:46:06.0 
+0200
@@ -15,6 +15,7 @@
 
 Package: golang-github-kjk-lzma-dev
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends},
  ${shlibs:Depends},
 Description: port of the lzma compression algorithm

Bug#960722: mark golang-github-influxdata-yamux-dev Multi-Arch: foreign

[Helmut Grohne]

Package: golang-github-influxdata-yamux-dev
Version: 0.0~git20171107.1f58ded-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:golang-github-influxdata-yarpc src:influxdb

Please mark golang-github-influxdata-yamux-dev to help making the
build-depends of the affected packages cross-satisfiable. In general,
Architecture: all packages can never satisfy cross Build-Depends unless
marked Multi-Arch: foreign or annotated :native. The foreign marking is
reasonable here as golang-github-influxdata-yamux-dev entirely lacks
dependencies and maintainer scripts. From a multiarch pov, it is a data
package. Please consider applying the attached patch.

Helmut
diff --minimal -Nru 
golang-github-influxdata-yamux-0.0~git20171107.1f58ded/debian/changelog 
golang-github-influxdata-yamux-0.0~git20171107.1f58ded/debian/changelog
--- golang-github-influxdata-yamux-0.0~git20171107.1f58ded/debian/changelog 
2018-02-06 05:45:50.0 +0100
+++ golang-github-influxdata-yamux-0.0~git20171107.1f58ded/debian/changelog 
2020-05-15 22:37:23.0 +0200
@@ -1,3 +1,10 @@
+golang-github-influxdata-yamux (0.0~git20171107.1f58ded-5.1) UNRELEASED; 
urgency=medium
+
+  * Non-maintainer upload.
+  * Mark golang-github-influxdata-yamux-dev Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 15 May 2020 22:37:23 +0200
+
 golang-github-influxdata-yamux (0.0~git20171107.1f58ded-5) unstable; 
urgency=medium
 
   * Team upload.
diff --minimal -Nru 
golang-github-influxdata-yamux-0.0~git20171107.1f58ded/debian/control 
golang-github-influxdata-yamux-0.0~git20171107.1f58ded/debian/control
--- golang-github-influxdata-yamux-0.0~git20171107.1f58ded/debian/control   
2018-02-06 05:45:50.0 +0100
+++ golang-github-influxdata-yamux-0.0~git20171107.1f58ded/debian/control   
2020-05-15 22:37:22.0 +0200
@@ -15,6 +15,7 @@
 
 Package: golang-github-influxdata-yamux-dev
 Architecture: all
+Multi-Arch: foreign
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Description: Golang connection multiplexing library

Bug#960105: node-redis: autopkgtest regressions against Redis 6.x

[Chris Lamb]

reassign 960721 node-redis
forcemerge 960105 960721
thanks

Hi,

I already filed this and it was actually fixed in 3.0.2-2:

 node-redis (3.0.2-2) unstable; urgency=medium

   * Disable error tests incompatible with redis ≥ 6 (Closes: #960105)

... hence merging. Thanks for filing these issues.


Best wishes,

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

Bug#958408: etherape: crashes with "critical: read_all() failed on control socket"

[rghetta]

On 15/05/20 15:22, Patrick Matthäi wrote:

@rghetta:
Do you want to merge it?

Patch merged. Thanks to all for your nice work.
I've cut a new release, 0.9.19

Ciao,
R

Bug#960721: redis breaks node-redis autopkgtest: 6/655

[Paul Gevers]

Source: redis, node-redis
Control: found -1 redis/5:6.0.0-2
Control: found -1 node-redis/3.0.2-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of redis the autopkgtest of node-redis fails in
testing when that autopkgtest is run with the binary packages of redis
from unstable. It passes when run with only packages from testing. In
tabular form:

   passfail
redis  from testing5:6.0.0-2
node-redis from testing3.0.2-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of redis 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

[1] https://qa.debian.org/excuses.php?package=redis

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-redis/5438964/log.gz

  649 passing (19s)
  6 failing

  1) publish/subscribe
   using options: detect_buffers: true;
 using IPv4
   fail for other commands while in pub sub mode
 return error if only pub sub commands are allowed:

  Uncaught AssertionError [ERR_ASSERTION]: The expression evaluated
to a falsy value:

  assert(/^ERR only \(P\)SUBSCRIBE \/ \(P\)UNSUBSCRIBE/.test(err.message))

  + expected - actual

  -false
  +true

  at
/tmp/autopkgtest-lxc.sefvg_kj/downtmp/autopkgtest_tmp/smokepiVdFl/test/pubsub.spec.js:590:25
  at Object.callbackOrEmit [as callback_or_emit]
(/usr/share/nodejs/redis/lib/utils.js:89:9)
  at RedisClient.return_error (/usr/share/nodejs/redis/index.js:641:11)
  at JavascriptRedisParser.returnError
(/usr/share/nodejs/redis/index.js:141:18)
  at JavascriptRedisParser.execute
(/usr/share/nodejs/redis-parser/lib/parser.js:572:12)
  at Socket. (/usr/share/nodejs/redis/index.js:218:27)
  at addChunk (_stream_readable.js:288:12)
  at readableAddChunk (_stream_readable.js:269:11)
  at Socket.Readable.push (_stream_readable.js:224:10)
  at TCP.onStreamRead [as onread]
(internal/stream_base_commons.js:94:17)

  2) publish/subscribe
   using options: detect_buffers: true;
 using IPv4
   fail for other commands while in pub sub mode
 return error if only pub sub commands are allowed:
 Error: done() called multiple times
  at multiple (/usr/share/nodejs/mocha/lib/runnable.js:314:26)
  at done (/usr/share/nodejs/mocha/lib/runnable.js:326:14)
  at /usr/share/nodejs/mocha/lib/runnable.js:443:7
  at Object.callbackOrEmit [as callback_or_emit]
(/usr/share/nodejs/redis/lib/utils.js:89:9)
  at Command.callback
(/usr/share/nodejs/redis/lib/individualCommands.js:93:15)
  at RedisClient.flush_and_error
(/usr/share/nodejs/redis/index.js:309:29)
  at RedisClient.connection_gone
(/usr/share/nodejs/redis/index.js:532:14)
  at Socket. (/usr/share/nodejs/redis/index.js:230:14)
  at endReadableNT (_stream_readable.js:1145:12)
  at process._tickCallback (internal/process/next_tick.js:63:19)

  3) publish/subscribe
   using options: detect_buffers: true;
 using IPv4
   fail for other commands while in pub sub mode
 emit error if only pub sub commands are allowed without
callback:

  Uncaught AssertionError [ERR_ASSERTION]: The expression evaluated
to a falsy value:

  assert(/^ERR only \(P\)SUBSCRIBE \/ \(P\)UNSUBSCRIBE/.test(err.message))

  + expected - actual

  -false
  +true

  at RedisClient. (test/pubsub.spec.js:600:25)
  at Object.callbackOrEmit [as callback_or_emit]
(/usr/share/nodejs/redis/lib/utils.js:91:14)
  at RedisClient.return_error (/usr/share/nodejs/redis/index.js:641:11)
  at JavascriptRedisParser.returnError
(/usr/share/nodejs/redis/index.js:141:18)
  at JavascriptRedisParser.execute
(/usr/share/nodejs/redis-parser/lib/parser.js:572:12)
  at Socket. (/usr/share/nodejs/redis/index.js:218:27)
  at addChunk (_stream_readable.js:288:12)
  at readableAddChunk (_stream_readable.js:269:11)
  at Socket.Readable.push (_stream_readable.js:224:10)
  at TCP.onStreamRead [as onread]
(internal/stream_base_commons.js:94:17)

  4) publish/subscribe
   using options: detect_buffers: false;
 using IPv4
   fail for other commands while in pub sub mode
 return error if only pub sub commands are allowed:

  Uncaught AssertionError [ERR_ASSERTION]: The expression evaluated
to a falsy value:

  assert(/^ERR only \(P\)SUBSCRIBE \/ \(P\)UNSUBSCRIBE/.test(err.message))

  + expected - actual

  

Bug#960326: json-c: CVE-2020-12762

[Salvatore Bonaccorso]

Hi,

On Mon, May 11, 2020 at 09:55:12PM +0200, Salvatore Bonaccorso wrote:
> Source: json-c
> Version: 0.13.1+dfsg-7
> Severity: important
> Tags: security upstream
> Forwarded: https://github.com/json-c/json-c/pull/592
> 
> Hi,
> 
> The following vulnerability was published for json-c.
> 
> CVE-2020-12762[0]:
> | json-c through 0.14 has an integer overflow and out-of-bounds write
> | via a large JSON file, as demonstrated by printbuf_memappend.

The upstream fix introduces a regression, see in particular
https://github.com/json-c/json-c/issues/599 .

FWIW, Ubuntu has as well reverted the fix, pending further
investigation as per https://usn.ubuntu.com/4360-2/ 

Regards,
Salvatore

Bug#960626: tests with other distributions

[cyrille]

Hello,

 

I've tried 2 other distribution and the scheme is the same:

 

1) Ubuntu: Doesn't work. Parted shows the same strange results

2) Fedora: Work. Parted shows a regular msdos partition table with 512
bytes logical sectors

Bug#960716: udev: systemd-udevd fails with "Process '/usr/sbin/alsactl -E HOME=/run/alsa restore 1' failed with exit code 99"

[Michael Biebl]

Control: reassign -1 alsa-utils

Am 15.05.2020 um 21:25 schrieb Nikolaus Rath:
> Package: udev
> Version: 241-7~deb10u4
> Severity: normal
> 
> Dear Maintainer,
> 
> On every boot, I'm getting a warning of the form
> 
> May 15 19:27:30 vostro.rath.org systemd-udevd[525]: Process 
> '/usr/sbin/alsactl -E


Since that rule is shipped by alsa-utils, let's reassign it.



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



signature.asc
Description: OpenPGP digital signature

Bug#960720: node-co: autopkgtest regression: no such file or directory, open 'LICENSE'

[Paul Gevers]

Source: node-co
Version: 4.6.0-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of node-co the autopkgtest of node-co fails in
testing when that autopkgtest is run with the binary packages of node-co
from unstable. It passes when run with only packages from testing. In
tabular form:

   passfail
node-cofrom testing4.6.0-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-co/5444788/log.gz

  39 passing (803ms)
  4 failing

  1) co(* -> yield [])
   should aggregate several thunks:
 Error: ENOENT: no such file or directory, open 'LICENSE'


  2) co(* -> yield {})
   should aggregate several thunks:
 Error: ENOENT: no such file or directory, open 'LICENSE'


  3) co() recursion
   should aggregate arrays within arrays:
 Error: ENOENT: no such file or directory, open 'LICENSE'


  4) co() recursion
   should aggregate objects within objects:
 Error: ENOENT: no such file or directory, open 'LICENSE'



signature.asc
Description: OpenPGP digital signature

Bug#944029: megahit_1.2.9-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

this is fixed in new upload.  Thanks a lot for your thorough checking

Andreas.

On Fri, May 15, 2020 at 06:00:09PM +, Thorsten Alteholz wrote:
> 
> Hi Andreas,
> 
> src/idba seems to be licensed under GPL2+, and the rest is licensed under 
> GPL-3+
> Please don't add the GPL license text to your debian/copyright.
> 
>   Thorsten
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#960716: udev: systemd-udevd fails with "Process '/usr/sbin/alsactl -E HOME=/run/alsa restore 1' failed with exit code 99"

[Michael Biebl]

Am 15.05.2020 um 22:10 schrieb Michael Biebl:
> Control: reassign -1 alsa-utils
> 
> Am 15.05.2020 um 21:25 schrieb Nikolaus Rath:
>> Package: udev
>> Version: 241-7~deb10u4
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> On every boot, I'm getting a warning of the form
>>
>> May 15 19:27:30 vostro.rath.org systemd-udevd[525]: Process 
>> '/usr/sbin/alsactl -E
> 
> 
> Since that rule is shipped by alsa-utils, let's reassign it.

Should probably be merged with
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848395


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



signature.asc
Description: OpenPGP digital signature

Bug#960509: ivar_1.2.2+dfsg-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

fixed in new upload - thanks a lot for checking.

Kind regards

 Andreas.

On Fri, May 15, 2020 at 06:00:09PM +, Thorsten Alteholz wrote:
> 
> Hi Andreas,
> 
> the license of this package seems to be GPL-3 only whereas some html files in 
> doc/ are GPL-2
> 
>   Thorsten
>  
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#960719: python-django-netfields: autopkgtest failure: No module named 'django_netfields'

[Paul Gevers]

Source: python-django-netfields
Version: 1.2.2-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. I copied some
of the output at the bottom of this report. Can you please investigate
the situation and fix it?

You're using autodep8 to trigger the test, but it seems your package
naming and Python module name aren't aligned for autodep8. autodep8
recently acquired a new feature that enables you to tell autode8 what
the real module name is that should be tested [1].

The release team has announced [2] that failing autopkgtest are now
considered RC in testing.

Paul

[1]
https://manpages.debian.org/unstable/autodep8/autodep8.1.en.html#PYTHON_PACKAGES
[2] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-django-netfields/5494902/log.gz

autopkgtest [17:13:47]: test autodep8-python3: set -e ; for py in
$(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing
with $py:" ; $py -c "import django_netfields; print(django_netfields)" ;
done
autopkgtest [17:13:47]: test autodep8-python3: [---
Testing with python3.8:
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'django_netfields'
autopkgtest [17:13:47]: test autodep8-python3: ---]



signature.asc
Description: OpenPGP digital signature

Bug#960405: mscgen crashes after libgd3 upload

[Steve Langasek]

Package: mscgen
Version: 0.20-13
Followup-For: Bug #960405
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Hi Niels,

This autopkgtest regression hit us also in Ubuntu, and I dug into it and
found mscgen was blindly subtracting 1 from the "width" returned by libgd
for the text bounding box; so if gd returned a bounding box of width 0,
mscgen would blithely return -1 instead and things would go sideways.

The attached patch handles this case and avoids returning a width of
(unsigned int)-1, though I have my doubts about the correctness of the
original code trying to fix up the bounding box width as well.

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
diff -Nru mscgen-0.20/debian/patches/series mscgen-0.20/debian/patches/series
--- mscgen-0.20/debian/patches/series   2013-12-29 04:43:25.0 -0800
+++ mscgen-0.20/debian/patches/series   2020-05-15 12:28:20.0 -0700
@@ -1 +1,2 @@
 language.y-parse-param.patch
+width-never-less-than-zero.patch
diff -Nru mscgen-0.20/debian/patches/width-never-less-than-zero.patch 
mscgen-0.20/debian/patches/width-never-less-than-zero.patch
--- mscgen-0.20/debian/patches/width-never-less-than-zero.patch 1969-12-31 
16:00:00.0 -0800
+++ mscgen-0.20/debian/patches/width-never-less-than-zero.patch 2020-05-15 
12:31:31.0 -0700
@@ -0,0 +1,23 @@
+Description: don't make width < 0 with an off-by-one fix-up
+ gdoTextWidth() tries to correct an off-by-one error in the calculated width
+ of a text bounding box; but doesn't account for the possibility that the
+ bounding box has a size of zero (which is the case in latest libgd for
+ zero-width text).  Account for this so we aren't accidentally returning
+ -1 where we mean 0.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/960405
+Last-Update: 2020-05-15
+
+Index: mscgen-0.20/src/gd_out.c
+===
+--- mscgen-0.20.orig/src/gd_out.c
 mscgen-0.20/src/gd_out.c
+@@ -212,7 +212,7 @@
+  *  the right of the last character for the fixed width
+  *  font.
+  */
+-return rect[2] - 1;
++return rect[2] ? rect[2] - 1 : 0;
+ #endif
+ }
+ 

Bug#960718: slirp4netns: autopkgtest failure: 5/7 tests

[Paul Gevers]

Source: slirp4netns
Version: 0.4.3-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. I copied some
of the output at the bottom of this report. Can you please investigate
the situation and fix it?

The release team has announced [1] that failing autopkgtest are now
considered RC in testing.

Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/s/slirp4netns/5495522/log.gz

autopkgtest [17:55:40]: test make-check: [---
+ make check
make  check-TESTS
make[1]: Entering directory
'/tmp/autopkgtest-lxc.s0_sz0m_/downtmp/build.yCj/src'
make[2]: Entering directory
'/tmp/autopkgtest-lxc.s0_sz0m_/downtmp/build.yCj/src'
FAIL: tests/test-slirp4netns.sh
FAIL: tests/test-slirp4netns-configure.sh
PASS: tests/test-slirp4netns-exit-fd.sh
PASS: tests/test-slirp4netns-ready-fd.sh
FAIL: tests/test-slirp4netns-api-socket.sh
FAIL: tests/test-slirp4netns-disable-host-loopback.sh
FAIL: tests/test-slirp4netns-cidr.sh

Testsuite summary for slirp4netns 0.4.3

# TOTAL: 7
# PASS:  2
# SKIP:  0
# XFAIL: 0
# FAIL:  5
# XPASS: 0
# ERROR: 0

See ./test-suite.log
Please report to https://github.com/rootless-containers/slirp4netns/issues

make[2]: *** [Makefile:1605: test-suite.log] Error 1
make[2]: Leaving directory
'/tmp/autopkgtest-lxc.s0_sz0m_/downtmp/build.yCj/src'
make[1]: *** [Makefile:1713: check-TESTS] Error 2
make[1]: Leaving directory
'/tmp/autopkgtest-lxc.s0_sz0m_/downtmp/build.yCj/src'
make: *** [Makefile:1967: check-am] Error 2
autopkgtest [18:00:23]: test make-check: ---]



signature.asc
Description: OpenPGP digital signature

Bug#960294: [Debian-med-packaging] Bug#960294: closed by Debian FTP Masters (reply to Etienne Mollier ) (Bug#960294: fixed in tigr-glimmer

[Étienne Mollier]

Hi Helmut,

Helmut Grohne, on 2020-05-15 08:02:04 +0200:
> Given that the previous fix of the bug was incomplete, I'd like to
> confirm that with this fix, it really fails instantly. Also verbose
> build logs help a lot. Thank you for bearing with me.

You're welcome, glad to read it does the job.  :)
Thank you for the confirmation!

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/

Bug#960717: openbox-menu: autopkgtest failure: openbox-menu: command not found

[Paul Gevers]

Source: openbox-menu
Version: 0.8.0+hg20161009-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. I copied some
of the output at the bottom of this report. Can you please investigate
the situation and fix it?

The release team has announced [1] that failing autopkgtest are now
considered RC in testing.

Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/o/openbox-menu/5496002/log.gz

autopkgtest [18:11:12]: test simple: [---
/tmp/autopkgtest-lxc.26cuvgvn/downtmp/build.6jr/src/debian/tests/simple:
line 3: openbox-menu: command not found
autopkgtest [18:11:13]: test simple: ---]



signature.asc
Description: OpenPGP digital signature

Bug#960715: cunit: autopkgtest failure: gcc: not found

[Paul Gevers]

Source: cunit
Version: 2.1-3-dfsg-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. I copied some
of the output at the bottom of this report. Can you please investigate
the situation and fix it? You seem to be missing a test dependency.

The release team has announced [1] that failing autopkgtest are now
considered RC in testing.

Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cunit/5496014/log.gz


autopkgtest [18:13:13]: test test.sh: [---
/tmp/autopkgtest-lxc.k5r5ej6m/downtmp/build.P6n/src/debian/tests/test.sh: 7:
gcc: not found
/tmp/autopkgtest-lxc.k5r5ej6m/downtmp/build.P6n/src/debian/tests/test.sh: 8:
/tmp/autopkgtest-lxc.k5r5ej6m/downtmp/autopkgtest_tmp/test: not found
/tmp/autopkgtest-lxc.k5r5ej6m/downtmp/build.P6n/src/debian/tests/test.sh: 7:
gcc: not found
/tmp/autopkgtest-lxc.k5r5ej6m/downtmp/build.P6n/src/debian/tests/test.sh: 8:
/tmp/autopkgtest-lxc.k5r5ej6m/downtmp/autopkgtest_tmp/test: not found
autopkgtest [18:13:13]: test test.sh: ---]



signature.asc
Description: OpenPGP digital signature

Bug#960714: libkeduvocdocument: autopkgtest failure: kdeinit5: not found

[Paul Gevers]

Source: libkeduvocdocument
Version: 4:17.08.3-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. I copied some
of the output at the bottom of this report. Can you please investigate
the situation and fix it? You seem to be missing a test dependency.

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

Paul

[1]
https://ci.debian.net/data/autopkgtest/testing/amd64/libk/libkeduvocdocument/5496019/log.gz

autopkgtest [18:12:57]: test testsuite: [---
debian/tests/testsuite.xsession: 4: kdeinit5: not found
dh_auto_test: warning: Compatibility levels before 10 are deprecated
(level 9 in use)
debian/tests/testsuite.xsession: 1: kdeinit5_shutdown: not found
autopkgtest [18:12:58]: test testsuite: ---]



signature.asc
Description: OpenPGP digital signature

Bug#954089: libplack-perl: Please verify server identity via SSL

[gregor herrmann]

On Thu, 19 Mar 2020 14:39:13 +0200, Damyan Ivanov wrote:

> > > But to fully measure the impact, it would be nice to have the number 
> > > of failing packages built with a patched HTTP::Tiny.
> > I have one small concern: As the change is about checking remote SSL
> > certs, and tests don't/can't/must not call out to the internet, is it
> > possible that we won't really catch all potential issues?
> Noted. The test rebuilds should be done without the usual isolation 
> from the Internet.
> I guess a closer inspection of the affected packages is needed.

Hi Dam and all,

did you or anyone else get to look into this rebuild effort?

If not, Dom said that he could also try the rebuilds on
perl.debian.net.

Notes:
- HTTP::Tiny is in perl core and in libhttp-tiny-perl;
- The required change looks like a one-character-patch:
  lib/HTTP/Tiny.pm:verify_SSL   => $args{verify_SSL} || 
$args{verify_ssl} || 0, # no verification by default
- The tests should be run with internet enabled as much as possible.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Simon & Garfunkel: Blessed


signature.asc
Description: Digital Signature

Bug#960693: phpliteadmin.desktop file is misconfigured

[Nicholas Guriev]

Hello,

As Desktop Entry Specification says[1], `Link` is a valid value of `Type` key in
*.desktop files, and unknown types should be silently ignored. So I doubt the
issue is in the phpliteadmin package. Although, I do not know which menu
supports such links. It might be worth switching to `Application` type and
invoking xdg-open.

I did not reproduce the problem by myself yet. Is it a fatal error that blocks
something or just a warning message?

 [1]: https://specifications.freedesktop.org/desktop-entry-spec/1.4/ar01s06.html

Bug#960206: olive-editor: does not start due to OpenColorIO error

[bartosz]

On 2020-05-15 16:25, Adrian Bunk wrote:

On Sun, May 10, 2020 at 06:00:04PM +0200, Bartosz Fenski wrote:

Package: olive-editor
Version: 20200210-1
Severity: grave

After fresh install olive doesn't start at all

fenio@udebian:~$ olive-editor
Using Qt version: 5.12.5
[OpenColorIO Info]: Color management disabled. (Specify the $OCIO 
environment variable to enable.)
terminate called after throwing an instance of 
'OpenColorIO::v1::Exception'
  what():  Error: Loading the OCIO profile failed. The specified file 
does not appear to be an OCIO configuration.

Aborted
...


Does it work after upgrading libyaml-cpp0.6 to 0.6.3-7?


Well now it works but I'm not the one to confirm that this upgrade fixed 
it.

But it happened yesterday on my laptop so it could fix it ;)

regards
Bartosz Fenski

Bug#959631: hy: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 returned exit code 13

[Tianon Gravi]

On Tue, 5 May 2020 at 10:55, Tianon Gravi  wrote:
> I was definitely over my head with this one, so I reached out to the
> Hy community and was pointed to https://bugs.python.org/issue39562,
> which does seem quite related from my own limited understanding, so
> this might technically be a bug in the Python package?
>
> I'm including the Debian Python list on CC to hopefully see if someone
> there can provide some assistance figuring out what's necessary here.
> O:)

Looking at results from ci.debian.net[1], our autopkgtests failed on
2020-05-07 and passed today (2020-05-15).  Comparing the logs, it
appears the difference is that the last failing build was against
python3.8 version 3.8.3~rc1-1, and the successful build from today was
against python3.8 version 3.8.3-1 (lending credence to the thought it
was probably a Python bug, and that it's now fixed).

[1]: https://ci.debian.net/packages/h/hy/

Can you re-test and verify that we no longer FTBFS in your testing? O:)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#960639: Bug#960639: src:orthanc-imagej: Please add support to build against libjson-simple-java >= 3

[Gilles Filippini]

Andreas Tille a écrit le 15/05/2020 à 12:49 :
> Hi Sébastien,
> 
> On Fri, May 15, 2020 at 07:50:01AM +0200, Sébastien Jodogne wrote:
>> As far as I'm concerned, I don't have time to have a look at this
>> problem in the upstream project before several months. The Orthanc
>> project is indeed under heavy pressure because of the COVID crisis, and
>> ImageJ support is not urgent in this context.
> 
> Thank you for your work on Orthanc upstream and in Debian.
>  
>> Regarding Debian packaging, I'm currently focused on the C++ packages
>> related to Orthanc, which doesn't include the "orthanc-imagej" package
>> (Java).
>>
>> I suggest thus two possibilities:
>>
>> (1) Someone else integrates Gilles' patch, or
> 
> Gilles, would you mind just doing a team upload?
>  
>> (2) orthanc-imagej is temporarily removed from unstable.
> 
> I do not se any relevance for this since the bug is not RC.
> 
>> As written above, unfortunately, I won't have a look at these two
>> possibilities by myself right now. Any help from another Debian
>> maintainer is thus welcome, feel free to take care of the
>> "orthanc-imagej" package.
> 
> Gilles, please let us know if this is urgent and you do not
> feel comfortable with doing it yourself.

It's not a problem doing the upload. this is the easy part :)
What I'm uncomfortable with is that I don't know how to test whether my
patch is correct. Is there any test suite or sample case available?

Thanks,

_g.

Bug#960469: libtool: for a shared library, -L. -lfoo works but libfoo.so is ignored

[Nicolas Boulenguez]

Package: src:libtool
Followup-For: Bug #960469

Hello.

An improved reproducer is attached. The patch just copies other
portions of the code and requires competent review.  On my machine,
* sh reproducer
  fails and demonstrates the problem.
* sh reproducer check_reproducer
  succeeds, so the reproducer seems minimal.
* sh reproducer check_fix
  succeeds, so the attached patch seems basically correct.
* (echo draft960469.diff >> debian/patches/series) && debian/rules build
  passes all non-skipped tests.
Do you see other things that I can check before forwarding it to
upstream as described at [1]?

Thanks.

[1] https://www.gnu.org/software/libtool/manual/libtool.html#Reporting-bugs
Description: allow libfoo.so as argument when linking a shared library
 This already works for programs, and is recommended instead of the
 ambiguous -L...  /-lfoo.
Bug-Debian: https://bugs.debian.org/960469
Author: Nicolas Boulenguez 

--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5517,6 +5517,13 @@
 	continue
 	;;
 
+  *.so)
+	# An explicit path to a shared library.
+	func_append deplibs " $arg"
+	func_append old_deplibs " $arg"
+	continue
+	;;
+
   *.la)
 	# A libtool-controlled library.
 
@@ -5871,6 +5878,16 @@
 	  func_resolve_sysroot "$deplib"
 	  lib=$func_resolve_sysroot_result
 	  ;;
+	*.so)
+	  # FIXME: linkmode=prog copies .so arguments without this stanza. Duplicate code?
+	  if test lib = "$linkmode"; then
+	deplibs="$deplib $deplibs"
+	test lib = "$linkmode" && newdependency_libs="$deplib $newdependency_libs"
+	  elif test prog != "$linkmode"; then
+	func_warning "shared library '$deplib' ignored for archive/object"
+	  fi
+	  continue
+	  ;;
 	*.$libext)
 	  if test conv = "$pass"; then
 	deplibs="$deplib $deplibs"
#!/bin/sh
set -Cefu

cat > hello.c <
void hello (void) {
  printf ("If you are reading this, all probably went OK.\n");
}
EOF

cat > direct.c < main.c < configure.ac < Makefile.am <> Makefile.am
elif test $# = 1 && test $1 = check_reproducer; then
# Check that all the rest of the build system works.
echo 'libdirect_la_LIBADD = -L. -l:libhello.so'  >> Makefile.am
echo 'EXTRA_libdirect_la_DEPENDENCIES = libhello.so' >> Makefile.am
elif test $# = 1 && test $1 = check_fix; then
echo 'libdirect_la_LIBADD = libhello.so' >> Makefile.am
check_fix=1
else
echo 'Wrong arguments'
exit 1
fi

autoreconf -i
./configure
if test $check_fix = 1; then
patch -p2 libtool draft960469.diff
fi
# --no-undefined forces the script to stop at the interesting lines.
# Without it, libtool would fail later when trying to link main.o.
make CFLAGS= DEFS= LDFLAGS=-Wl,--no-undefined
LD_LIBRARY_PATH=. ./main

Bug#960674: golang-go: "fatal error: gc_trigger underflow" on mipsel

[Shengjing Zhu]

On Fri, May 15, 2020 at 6:03 PM Sascha Steinbiss  wrote:
>
> Package: golang-go
> Version: 2:1.14~1
> Severity: important
>
> Dear Maintainer,
>
> the current go binary crashes on mipsel when running non-trivial calls
> (a trivial call would be like 'go version', which succeeds) with the message
> 'fatal error: gc_trigger underflow'. Here's an example from the mipsel

I can confirm the go compiler is broken on mipsel currently.
An simple go source, like


$ cat test.go
package main

func main() {}
```

Then `go build test.go` will trigger the fault.

Looking at the buildd logs, it worked on 2020/4/26,
https://buildd.debian.org/status/package.php?p=runc

I suspect it's because the kernel is upgraded from 4.19.98-1 to 4.19.118-2.

@syq could you help look this?

--
Shengjing Zhu

Bug#960712: src:pychess: fails to migrate to testing for too long: maintainer built arch:all

[Paul Gevers]

Source: pychess
Version: 0.12.2-1
Severity: serious
Control: close -1 1.0.0-1
Tags: sid bullseye pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:pychess in
its current version in unstable has been trying to migrate for 60 days
[2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

Your package is only blocked because the arch:all binary package(s)
aren't built on a buildd. Unfortunately the Debian infrastructure
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
shortly do a no-changes source-only upload to DELAYED/15, closing this
bug. Please let me know if I should delay or cancel that upload.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=pychess




signature.asc
Description: OpenPGP digital signature

Bug#960405: mscgen: FTBFS and debci failure

[Niels Thykier]

Control: reassign -1 mscgen,libgd3
Control: affects -1 mscgen
control: retitle -1 mscgen crashes after libgd3 upload

On Tue, 12 May 2020 13:16:59 +0300 Adrian Bunk  wrote:
> Source: mscgen
> Version: 0.20-13
> Severity: serious
> Tags: ftbfs
> 
> https://ci.debian.net/packages/m/mscgen/unstable/amd64/
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mscgen.html
> 
> [...]

This started after libgd3 was uploaded to unstable.  Related #959591

~Niels

Bug#960702: ethtool -m values change when output is redirected

[Yannis Aribaud]

15 mai 2020 18:40 "Bjørn Mork"  a écrit:

> "Yannis Aribaud"  writes:
> 
> [...]
>
> To me it looks like you are just reading arbitrary numbers from the
> SFP+. Try replacing it and see if the results are more reliable.

I will try, but I am seeing the same behavior and similar values on 2 servers 
running the same hardware and the same software. The SFP+ modules model is 
commonly used on our equipements (servers, routers, switchs) and we never had 
such issues.

Values are clearly unreliable but not random at all. Values doesn't change 
between several runs of the command output redirected or not.

I mean values obviously change between redirected output and non redirected 
output runs, but not much between several runs redirected and neither between 
several runs non redirected.

Thus even if the values provided by the tranceivers are crazy, I see no reason 
seeing differences like those in values due to output redirect... I could not 
find any clue in the source code of ethtool, but I am no good developper at all.

Regards,

-- 
Yannis Aribaud

Bug#958169: lxterminal doesn't recognize URLs anymore

[Andriy Grytsenko]

control: tags -1 fixed-upstream

>Upstream LXTerminal has fixed this issue in the following commit:
>https://github.com/lxde/lxterminal/commit/b1e3db193651b33db1e112a71ccc1e9868f37093

Thank you very much for pointing on that.
Then it will be fixed on next upload which I hope happens soon.

Bug#936683: [Pkg-javascript-devel] Bug#936683: gyp: Python2 removal in sid/bullseye

[Jérémy Lal]

Le ven. 15 mai 2020 à 16:33, Mitsuya Shibata  a
écrit :

> Dear maintainer,
>
> I'm trying to create updated package that incorporates a new upstream
> version to support Python 3.
>
>   https://salsa.debian.org/shibata/gyp
>
> I tested by followings:
>
>   - A simple gyp script works on ubuntu/groovy without python2 environment.
>   - Mozc which needs gyp in Build-Depends can build on ubuntu/groovy
> with python2.
>
> However, I did not test nodejs and node-gyp, because I were not sure
> how to test it.
>
> Can I send Merge Request to master, upstream, pristine-tar in this state?
>
> Or should I create and attach debdiff as patch?
>
> Hi,

that is really nice.
However before doing that, i checked that node-gyp has actually ported gyp
to python3:
https://github.com/nodejs/node-gyp/tree/master/gyp

It would be nice of you if you compared your work and their work.

Jérémy

Bug#960696: chrome-gnome-shell: /usr/share/applications/org.gnome.ChromeGnomeShell.desktop is misconfigured

[Simon McVittie]

Control: reassign -1 chrome-gnome-shell,src:kservice
Control: found -1 kservice/5.62.0-1

On Fri, 15 May 2020 at 22:08:35 +0800, Jason L. Quinn wrote:
> Start of any QT application from the console produces the following chrome-
> gnome-shell related error message:
> 
> 
> kf5.kservice.services: The desktop entry file
> "/usr/share/applications/org.gnome.ChromeGnomeShell.desktop" has Type=
> "Application" but no Exec line
> kf5.kservice.sycoca: Invalid Service :
> "/usr/share/applications/org.gnome.ChromeGnomeShell.desktop"
> 

>From codesearch, this seems to be coming from the kservice source
package. It isn't clear to me whether this is a chrome-gnome-shell
bug, a kservice bug, or a bit of both, so I'm assigning it to both
packages for now.

> The probable fix is that "Service" is probably intended instead of
> "Application" for the Type.

That type is not documented in the Desktop Entry Specification

although there is a note that it exists as a historical KDE-specific
extension.

It looks as though the intention is that this application is only runnable
via D-Bus activation, and not via the traditional "run a child process"
route. The Desktop Entry Specification allows this, although does not
recommend it:

 The Exec key is required if DBusActivatable is not set to
 true. Even if DBusActivatable is true, Exec should be specified
 for compatibility with implementations that do not understand
 DBusActivatable.

(note "should", not "must")

Exec=/bin/false would presumably silence the warnings from kservice -
but chrome-gnome-shell's .desktop file seems to be valid according to
the specification, and it's here for integration with GNOME Shell (which
we know *does* implement DBusActivatable), so in practice the Exec line
will probably never be used anyway.

So perhaps this is just a kservice bug, and kservice should be more
tolerant?

Another thing that might be considered a kservice bug is that random Qt
applications probably shouldn't print diagnostic messages about unrelated
.desktop files? That seems like a recipe for spamming warnings that the
application's author cannot fix.

If these messages appear at all, I would expect them to only be printed
on request - perhaps something similar to GLib's g_debug(), which is a
no-op unless you set the G_MESSAGES_DEBUG environment variable to a
suitable value.

I also can't help wondering whether chrome-gnome-shell should be
OnlyShowIn=GNOME - I'm having a hard time seeing how a service to install
GNOME Shell extensions could possibly be useful or relevant while not
running GNOME Shell :-)

smcv

Bug#960294: closed by Debian FTP Masters (reply to Etienne Mollier ) (Bug#960294: fixed in tigr-glimmer 3.02b-5)

[Helmut Grohne]

On Thu, May 14, 2020 at 07:09:06AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:tigr-glimmer package:
> 
> #960294: tigr-glimmer does not trap errors from make

Given that the previous fix of the bug was incomplete, I'd like to
confirm that with this fix, it really fails instantly. Also verbose
build logs help a lot. Thank you for bearing with me.

Helmut

Bug#953437: Upstream has a proposed fix

[Thibaut Paumard]

Le 15/05/2020 à 11:07, Julien Puydt a écrit :
> It should, but since I haven't been able to reproduce your problem on
> eller.debian.org...
> 

Interesting. I just re-compiled my test-case in a fresh chroot on eller,
and it still segfaults. The base system is sid-mips64el.

Regards, Thibaut.



signature.asc
Description: OpenPGP digital signature

Bug#960709: unattended-upgrades: Exception: 'NoneType' object has no attribute 'dependencies'

[Evgeny Kapun]

Package: unattended-upgrades
Version: 1.11.2

I'm using unattended-upgrades on a Debian Buster system. Some time ago, it 
stopped working. When run from terminal, it prints:

Exception: 'NoneType' object has no attribute 'dependencies'

This line doesn't appear in logs.

After some manual editing, I managed to pull a stack trace:

Traceback (most recent call last):
  File "/usr/bin/unattended-upgrade", line 1208, in do_install
options.verbose or options.debug)
  File "/usr/bin/unattended-upgrade", line 651, in upgrade_in_minimal_steps
for pkgname in upgrade_order(to_upgrade, cache):
  File "/usr/bin/unattended-upgrade", line 810, in upgrade_order
len(transitive_dependencies(pkg, cache).intersection(to_upgrade))
  File "/usr/bin/unattended-upgrade", line 793, in transitive_dependencies
transitive_dependencies(cache[base_dep.name], cache, acc)
  File "/usr/bin/unattended-upgrade", line 793, in transitive_dependencies
transitive_dependencies(cache[base_dep.name], cache, acc)
  File "/usr/bin/unattended-upgrade", line 793, in transitive_dependencies
transitive_dependencies(cache[base_dep.name], cache, acc)
  [Previous line repeated 5 more times]
  File "/usr/bin/unattended-upgrade", line 788, in transitive_dependencies
for dep in pkg.candidate.dependencies:
AttributeError: 'NoneType' object has no attribute 'dependencies'

Bug#960708: dupload: please allow mailtx to work for non-standard distributions

[Richard Lewis]

Package: dupload
Version: 2.9.4
Severity: wishlist

Dear Maintainer,

In dupload.conf, mailto sends a mail for duploads to stable and mailtx
works for unstable and experimental, but there's nothing for
non-standard (eg private distributions/names). 

Perhaps a 'mailty' is needed?

Thanks
Richard


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

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

Versions of packages dupload depends on:
ii  libdpkg-perl  1.19.7
ii  perl  5.28.1-6

Versions of packages dupload recommends:
ii  openssh-client  1:7.9p1-10+deb10u2

Versions of packages dupload suggests:
ii  exim4-daemon-light [mail-transport-agent]  4.92-8+deb10u3
ii  lintian2.15.0

-- no debconf information

Bug#960707: libalure1: Binary rebuild with current libfluidsynth2

[Bastian Germann]

Package: libalure1
Priority: normal
Version: 1.2-6

libalure1 recommends libfluidsynth1. Please rebuild the package so that
it uses the libfluidsynth2 ABI and recommends the current package version.

Bug#956903: clang-tidy-6.0: Depends on cruft package python-yaml

[Scott Kitterman]

NMU diff to drop the clang-tidy-6.0 binary as discussed.  I'll upload this 
shortly.

Scott Kdiff -Nru llvm-toolchain-6.0-6.0.1/debian/changelog llvm-toolchain-6.0-6.0.1/debian/changelog
--- llvm-toolchain-6.0-6.0.1/debian/changelog	2020-03-23 06:59:23.0 -0400
+++ llvm-toolchain-6.0-6.0.1/debian/changelog	2020-05-15 12:25:16.0 -0400
@@ -1,3 +1,12 @@
+llvm-toolchain-6.0 (1:6.0.1-14.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Maintainer agreed NMU to drop clang-tidy-6.0 since it is not needed to
+support ghc, the only remaining llvm-6.0 user, and allows progress on
+python2 removal (Closes: #956903)
+
+ -- Scott Kitterman   Fri, 15 May 2020 12:25:16 -0400
+
 llvm-toolchain-6.0 (1:6.0.1-14) unstable; urgency=medium
 
   * debian/patches/947f9692440836dcb8d88b74b69dd379d85974ce.patch:
diff -Nru llvm-toolchain-6.0-6.0.1/debian/control llvm-toolchain-6.0-6.0.1/debian/control
--- llvm-toolchain-6.0-6.0.1/debian/control	2020-03-22 13:28:44.0 -0400
+++ llvm-toolchain-6.0-6.0.1/debian/control	2020-05-15 12:25:13.0 -0400
@@ -69,19 +69,6 @@
  .
  This package also provides vim and emacs plugins.
 
-Package: clang-tidy-6.0
-Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, python2,
- libllvm6.0 (= ${binary:Version}), libclang-common-6.0-dev,
- clang-tools-6.0, python-yaml
-Replaces: clang-modernize-6.0, clang-6.0 (<< 1:6.0~svn250696-1)
-Breaks: clang-modernize-6.0, clang-6.0 (<< 1:6.0~svn250696-1)
-Description: clang-based C++ linter tool
- Provide an extensible framework for diagnosing and fixing typical programming
- errors, like style violations, interface misuse, or bugs that can be deduced
- via static analysis. clang-tidy is modular and provides a convenient interface
- for writing new checks.
-
 Package: libclang1-6.0
 Section: libs
 Architecture: any
diff -Nru llvm-toolchain-6.0-6.0.1/debian/rules llvm-toolchain-6.0-6.0.1/debian/rules
--- llvm-toolchain-6.0-6.0.1/debian/rules	2020-03-22 17:03:20.0 -0400
+++ llvm-toolchain-6.0-6.0.1/debian/rules	2020-05-15 12:25:13.0 -0400
@@ -519,6 +519,12 @@
 	rm -rf $(CURDIR)/debian/tmp/usr/lib/llvm-$(LLVM_VERSION)/lib/cmake/polly/*.cmake
 endif
 endif
+	# clang-tidy no longer built
+	rm -rf $(CURDIR)/debian/tmp/usr/bin/clang-tidy-6.0
+	rm -rf $(CURDIR)/debian/tmp/usr/lib/llvm-6.0/bin/clang-tidy
+	rm -rf $(CURDIR)/debian/tmp/usr/lib/llvm-6.0/share/clang/run-clang-tidy.py
+	rm -rf $(CURDIR)/debian/tmp/usr/lib/llvm-6.0/share/clang/clang-tidy-diff.py
+
 	dh_install --fail-missing
 
 override_dh_installdeb:


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

Bug#960702: ethtool -m values change when output is redirected

[Bjørn Mork]

"Yannis Aribaud"  writes:

> Package: ethtool
> Version: 1:4.19-1
> Severity: important
> I'm facing a very strange behavior. The command ethtool -m  report the 
> transceiver DOM values correctly, but when the command output is redirected 
> to an other program, values change to somthing else.

AFAICS, your SFP+ is reporting strange values in either case.  I do not
think any of these are correct.  Looking at the non-redirected one:

>  Laser output power : 3.0768 mW / 4.88 dBm

This is insanely high.

>  Receiver signal average optical power : 1.2298 mW / 0.90 dBm
>  Module temperature : 48.47 degrees C / 119.24 degrees F
>  Module voltage : 1.2336 V

Should be 3.3 V

>  Laser bias current high alarm threshold : 4.744 mA
>  Laser bias current low alarm threshold : 49.896 mA

Right...

>  Laser output power high alarm threshold : 2.5701 mW / 4.10 dBm

I don't think this can be trusted either, but I do note that it is lower
than your current output.

>  Laser output power low alarm threshold : 0.8224 mW / -0.85 dBm
>  Laser output power high warning threshold : 0.8224 mW / -0.85 dBm
>  Laser output power low warning threshold : 0.8224 mW / -0.85 dBm

Strange limits.  There are too many -0.85 dBm values here.

>  Module temperature high alarm threshold : 0.00 degrees C / 32.00 degrees F
>  Module temperature low alarm threshold : 0.00 degrees C / 32.00 degrees F
>  Module temperature high warning threshold : 0.00 degrees C / 32.00 degrees F
>  Module temperature low warning threshold : 0.00 degrees C / 32.00 degrees F

Makes no sense at all.

>  Module voltage high alarm threshold : 0.4356 V
>  Module voltage low alarm threshold : 0. V
>  Module voltage high warning threshold : 0. V
>  Module voltage low warning threshold : 0. V

Makes even less sense.  


>  Laser rx power high alarm threshold : 0.8224 mW / -0.85 dBm
>  Laser rx power low alarm threshold : 0.8224 mW / -0.85 dBm
>  Laser rx power high warning threshold : 0.8224 mW / -0.85 dBm
>  Laser rx power low warning threshold : 0.8224 mW / -0.85 dBm

...



To me it looks like you are just reading arbitrary numbers from the
SFP+.  Try replacing it and see if the results are more reliable.



Bjørn

Bug#960575: buster-pu: package node-dot-prop/4.1.1-1+deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2020-05-14 at 09:45 +0200, Xavier Guimard wrote:
> CVE-2020-8116 fix introduced a regression that affects npm (#960283).
> This little fix solves the problem.
> 

Hrm, we really should have spotted that sooner. :-( Is there any way we
can improve the tests to notice this?

Please go ahead.

Regards,

Adam

Bug#960395: buster-pu: package lemonldap-ng/2.0.2+ds-7+deb10u4

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2020-05-12 at 11:07 +0200, Xavier Guimard wrote:
> I introduced a bug in nginx configuration while fixing CVE-2019-
> 19791.
> 

Please go ahead.

Regards,

Adam

Bug#913640: This can be closed (see #913511)

[Bastian Germann]

This ticket is a duplicate of #913511 and can be closed as well.

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Francesco Poli]

On Fri, 15 May 2020 09:04:00 +0900 Mike Hommey wrote:

[...]
> Can you test 68.8.0esr-1~deb10u1?
> https://packages.debian.org/source/stable/firefox-esr

After upgrading (my Debian testing system) to the version currently
included in stable-security:

  [INSTALL, DEPENDENCIES] libevent-2.1-6:amd64 2.1.8-stable-4
  [INSTALL, DEPENDENCIES] libffi6:amd64 3.2.1-9
  [INSTALL, DEPENDENCIES] libvpx5:amd64 1.7.0-3+deb10u1
  [UPGRADE] firefox-esr:amd64 68.7.0esr-1 -> 68.8.0esr-1~deb10u1

I tested again: the microphone was still unseen by the browser.

Hence, it seems that the current test situation is:

firefox-esr microphone
==
68.7.0esr-1  OK
68.8.0esr-1 fails
68.8.0esr-1  w/force-PKCS11-patch   fails
68.8.0esr-1~deb10u1 fails



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


pgpN5PvUR6FnL.pgp
Description: PGP signature

Bug#960376: buster-pu: package libyang/0.16.105-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2020-05-12 at 09:16 +0200, Ondřej Surý wrote:
> there are two low-priority CVEs affecting libyang and the security
> team suggested updating this via SRM, so I am doing that.
[...]
>* Fix CVE-2019-19333 & CVE-2019-19334 (Closes: #946217)
>* Fix cache corruption crash (upstream bug 752)
> 

Please go ahead.

Regards,

Adam

Bug#959890: buster-pu: package confget/2.2.0-4+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2020-05-06 at 19:26 +0300, Peter Pentchev wrote:
> First of all, thanks for all your work on keeping Debian sane!

That's debatable at times. :-)

> The Python implementation in the confget package had an upstream bug
> in parsing values containing an equal sign, as explained in
> https://bugs.debian.org/959887 and fixed in confget/2.3.4-1 in
> unstable and testing.
> 
> Attached is a debdiff updating the buster package of confget with two
> patches, one of them introducing a test for this and another one
> fixing the bug in the Python implementation.

Please go ahead.

Regards,

Adam

Bug#959661: buster-pu: package borgbackup/1.1.9-2+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-05-03 at 17:25 +0200, Andrej Shadura wrote:
> I’m proposing to upload an upstream patch fixing an index corruption
> in borgbackup leading to a data loss, see #953615.
> 
> Please find the attached debdiff for more details.

Please go ahead.

Regards,

Adam

Bug#960705: apt: --allow-remove-essential doesn't work as expected (regression)

[Lorenzo Puliti]

Package: apt
Version: 2.1.2
Severity: normal

Hi,

recent changes in apt makes harder than it was to install runit-init:

with the current (2.1.2) apt:

# apt-get install --allow-remove-essential runit-init
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 runit-init : Conflicts: sysvinit-core but 2.96-3 is to be installed
E: Unable to correct problems, you have held broken packages.



I can only perform the install in two step

# apt-get remove --allow-remove-essential init
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer required:
  initscripts insserv startpar sysv-rc
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  init
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  init
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 21.5 kB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 12861 files and directories currently installed.)
Removing init (1.57) ...
root@8208a6e6a7c8:/var/cache/apt/archives# apt-get install runit-init
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  fgetty getty-run
The following packages will be REMOVED:
  libnss-systemd libpam-systemd systemd-sysv
The following NEW packages will be installed:
  fgetty getty-run runit-init
0 upgraded, 3 newly installed, 3 to remove and 0 not upgraded.
Need to get 71.1 kB of archives.
After this operation, 863 kB disk space will be freed.
Do you want to continue? [Y/n] 


This is a regression, and it breaks runit autopkgtest about init-switch,
which used to work;
downgrading apt, apt-utils and libapt-pkg6 to 2.0.2
# dpkg -l | grep apt
ii  apt   2.0.2   amd64commandline 
package manager
ii  apt-utils 2.0.2   amd64package 
management related utility programs
ii  libapt-pkg6.0:amd64   2.0.2   amd64package 
management runtime library

# apt-get install --allow-remove-essential runit-init
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  fgetty getty-run
The following packages will be REMOVED:
  init libnss-systemd libpam-systemd systemd-sysv
The following NEW packages will be installed:
  fgetty getty-run runit-init
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  init systemd-sysv (due to init)
0 upgraded, 3 newly installed, 4 to remove and 3 not upgraded.
Need to get 71.1 kB of archives.
After this operation, 885 kB disk space will be freed.
Do you want to continue? [Y/n] 


I guess this is karma striking back to me from trying to dump #953875 on you..

Regards,
Lorenzo 


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-.*-3\.18\.5-bfs1$";
APT::NeverAutoRemove:: "^linux-.*-4\.0\.1-van$";
APT::NeverAutoRemove:: "^linux-.*-4\.1\.3-van$";
APT::NeverAutoRemove:: "^linux-.*-4\.14\.11-van$";
APT::NeverAutoRemove:: "^linux-.*-4\.14\.2-van$";
APT::NeverAutoRemove:: "^linux-.*-4\.15\.12-van$";
APT::NeverAutoRemove:: "^linux-.*-4\.17\.3-van$";
APT::NeverAutoRemove:: "^linux-.*-4\.19\.0-5-amd64-unsigned$";
APT::NeverAutoRemove:: "^linux-.*-4\.6\.4-van$";
APT::NeverAutoRemove:: "^linux-.*-5\.3\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-.*-5\.3\.0-2-amd64-unsigned$";
APT::NeverAutoRemove:: "^linux-.*-5\.5\.9-van$";
APT::NeverAutoRemove:: "^kfreebsd-.*-3\.18\.5-bfs1$";
APT::NeverAutoRemove:: "^kfreebsd-.*-4\.0\.1-van$";
APT::NeverAutoRemove:: "^kfreebsd-.*-4\.1\.3-van$";
APT::NeverAutoRemove:: "^kfreebsd-.*-4\.14\.11-van$";
APT::NeverAutoRemove:: "^kfreebsd-.*-4\.14\.2-van$";
APT::NeverAutoRemove:: "^kfreebsd-.*-4\.15\.12-van$";
APT::NeverAutoRemove:: "^kfreebsd-.*-4\.17\.3-van$";

Bug#925128: Correction.

[Scott Leggett]

Hi,

I've reviewed these suggestions (and patches, thanks!) and unfortunately
I don't think either of them are a good idea for this package.

> Firstly, the post-install script.
> If "ifupdown" is configured, use it instead.

Debian policy says that daemons should be auto-enabled and disabling can
be done by the sysadmin. As your system configuration is highly unusual
I think it is reasonable to require you to manually disable the service
if that's what you want to do.

> Secondly, the config file.
> Many networks are IPv4-only, especially college networks.
> So you should still use "clientid".

The config file that ships with this package is a sample only and comes
directly from upstream.

However, this is still not a good idea. IPv4-only is not relevant here.
Even for DHCPv4 MAC address IDs are expressly discouraged. See
https://tools.ietf.org/html/rfc4361#section-6.1

Thanks for the suggestions and patches anyway.

-- 
Regards,
Scott Leggett.


signature.asc
Description: PGP signature

Bug#827611: No automatic log-out of ssh connected users when switching from ISC dhcp client to dhcpcd

[Scott Leggett]

On Sat, 18 Jun 2016 17:34:58 +0200 Comer352L  wrote:
> When switching from the ISC dhcp client to dhcpcd (uninstalling packages
> isc-dhcp-client, isc-dhcp-common, installing package dhcpcd5)
> users which are logged in via SSH are no longer logged out automatically
> when the system is shut down.
> Switching back to isc-dhcp-client restores the correct behavior.

Hi,

Can you still reproduce this behaviour in Buster?

-- 
Regards,
Scott Leggett.


signature.asc
Description: PGP signature

Bug#960704: cp: --dereference -a gives different behaviour to -a --dereference

[Richard Lewis]

Package: coreutils
Version: 8.30-3
Severity: normal

Dear Maintainer,

'cp -a --dereference'  exhibits different behaviour to
'cp --dereference -a'  -- one makes a file, the other a symlink:

touch file
ln -s file symlink

# the following works as expected: copy is a file
cp -a --dereference symlink copy

# but swapping the order makes copy2 a symlink -> file
cp --dereference -a symlink copy2

# expected: both copy and copy2 to be a file
# observed: one is a file, one is a symlink

# at least, i found it unexpected that in the second version,
# --dereference was ignored. 
# 
# (if it is meant to be like this, i think the manpage should be
#  updated?)

Thanks
Richard

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

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

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-4
ii  libattr1 1:2.4.48-4
ii  libc62.28-10
ii  libselinux1  2.8-1+b1

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#876201: ITA: dnsproxy -- proxy for DNS queries

[Alberto Molina Coballes]

Package: wnpp
Severity: normal

I intend to adopt the dnsproxy package.

The tentative repository for this package in salsa is:

https://salsa.debian.org/alberto/pkg-dnsproxy

Bug#958169: lxterminal doesn't recognize URLs anymore

[Iemand Die Boos Is]

That's caused by the following commit removing a deprecated API from
libvte: 
https://gitlab.gnome.org/GNOME/vte/-/commit/a0bb8222f3a0a29e4f22817bf3d7053d185b7afb

Upstream LXTerminal has fixed this issue in the following commit:
https://github.com/lxde/lxterminal/commit/b1e3db193651b33db1e112a71ccc1e9868f37093

Bug#960615: libbssolv-perl: Build-Depends on cruft package libsolv0-dev

[gregor herrmann]

Control: retitle -1 libbssolv-perl: Build-Depends on cruft package libsolv0-dev 
and FTBFS with libsolv-dev 0.7.11-1
Control: tag -1 + upstream confirmed

On Thu, 14 May 2020 10:05:29 -0700, Daniel Schepler wrote:

> The source package libbssolv-perl Build-Depends on libsolv0-dev,
> whereas the current version of src:libsolv builds only libsolv1-dev.

(Actually libsolv-dev.)

And it fails to build with libsolv-dev 0.7.11-1:

   dh_auto_build
make -j4
make[1]: Entering directory '/build/libbssolv-perl-0.17'
Running Mkbootstrap for BSSolv ()
"/usr/bin/perl" "/usr/share/perl/5.30/ExtUtils/xsubpp"  -typemap 
'/usr/share/perl/5.30/ExtUtils/typemap' -typemap '/build/
chmod 644 "BSSolv.bs"
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- BSSolv.bs 
blib/arch/auto/BSSolv/BSSolv.bs 644
cp BSSolv.pm blib/lib/BSSolv.pm
mv BSSolv.xsc BSSolv.c
x86_64-linux-gnu-gcc -c  -I/usr/include/`dpkg-architecture 
-qDEB_BUILD_MULTIARCH`/solv -D_REENTRANT -D_GNU_SOURCE -DDEBIAN
BSSolv.xs:18:10: fatal error: solvversion.h: No such file or directory
   18 | #include "solvversion.h"
  |  ^~~
compilation terminated.
make[1]: *** [Makefile:334: BSSolv.o] Error 1
make[1]: Leaving directory '/build/libbssolv-perl-0.17'
dh_auto_build: error: make -j4 returned exit code 2
make: *** [debian/rules:6: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


Aha, this looks like it's caused by 
debian/patches/2001_libsolv-dev-installs-to-multiarch-dest.patch.

Indeed, disabling the patch makes the build and the tests succeed.

Cheers,
gregor, uploading shortly

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Josh With: My father is a husbandman


signature.asc
Description: Digital Signature

Bug#545193: [licensecheck] Automatically check all files with -r

[Jonas Smedegaard]

Package: licensecheck
Version: 3.0.46-1
Followup-For: Bug #545193

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: block -1 by 960695

Hi Kartik,

I agree that current defaults of licensecheck is not ideal.

My current plan to address this is to first introduce a new option
"--usage" which changes defaults, and then later (with bumping minor or
major version number) switch from current usage=legacy to e.g.
usage=debian.

If you have opinions/ideas/criticism for that general conceptual, then
please contribute at bug#960695.

Let's continue to track here the specifics of option "--recursive".

This is (a subset of) current "licensecheck --help":

 -c STR --check STR regular expression of files to include
(default value: common source files)
 -i STR --ignore STRregular expression of files to skip
(default value: some backup and VCS files)
 -r --recursive traverse directories recursively

How do you think about this future "licensecheck --help":

 -c STR --check STR files to include;
with usage=legacy a regular expression
replacing previous or default value
and default being common source files,
with any other usage a comma-separated list
adding onto previous and default values
except an empty value which clears the list
and default being all files
(default value: common source files)
 -i STR --ignore STRfiles to skip;
with usage=legacy a regular expression
replacing previous or default value,
with any other usage a comma-separated list
adding onto previous and default values
except an empty value which clears the list
(default value: some backup and VCS files)
 -r --recursive traverse directories recursively

I.e. change nothing for the option --recursive itself, only for the
options --include and --exclude (both listed here, even if only some of
my envisioned changes are relevant for this issue).

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl6+t8oACgkQLHwxRsGg
ASHq4g/9HR3XU6XO+Y85AnPEuOAEE2lnpH5o/NismOmR7QplzK3qAKGc+u4lDBZO
p8yMgfn66ig7zQzo0N7qYwQFSoyIm7QqDBlA9Qhp7+I4ccrqIyOukij1ByQVA9eq
PTacVe2a4s+Zw/FBecbq7fk2VN85+OCM6HLxR7cRO4CMS+1SxrYMaZup+JcloaRl
C/ucLOi6BTV9IVgocYAfqTWGjkZdxX6epRXwHdntqG/uDHWrav5FZ/MPC9hXFkbg
sxt74XwC5dygk+dEY6RIQgQa3y9PMVBl7q/f8S/HVAjp0hAK1OdcnGUu5EYmh6YP
QBc+Bd+yGBx+iRfs2XgGaQszgOHaVa6TrJgfcr/am0cnRWxvT4ctSrvzp4izQKwb
RA6OyNNZprRfUqFr7ZIchXBY9XIqDbDQUSqkoaxFHv+e4t9zj8YWW242id2soeEq
zCKmr6ybMgPKSTbdpqO/4jEPNLNqsaNm9bQ7KM5bXepy2GwUac+mlawOmplM+Ne4
BFPdJC5+zMw/L7dqN8wBXzhW5R5kqRODbwcTkjXdt9cLKDEQWrNC3gbOVMoCyrQG
zz3f3IvO6f3XNRJndtUXtADzDK01YoR+ad2coaItX2lwaJUUa1gDfvkKAVXSwjt+
J4zMk535tmTCtLK3MwNe8GkEGR0CNJff2TDkDD2IfVa372Pp300=
=fb4S
-END PGP SIGNATURE-

Bug#960703: mrpt: FTBFS on amd64: test failures

[Sebastian Ramacher]

Source: mrpt
Version: 1:2.0.3-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

mrpt failed to build on the amd64 buildd:
https://buildd.debian.org/status/fetch.php?pkg=mrpt=amd64=1%3A2.0.3-2=1589545331=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#960326: // after this bug fix json processing broken on 16.04,18.04 and 20.04

[gjakop]

Hi,
today many people using our program faced with strange crashes and problems.
Digging into it we found that it's because json upgrade
Following is simple program built using "g++ main.cpp -ljson-c"

#include 
#include 

int main() {

const char* json =
R"({"SyncResponse":{"status":"success","StreamCheckerMode":false,"UniqueVisitors":false,"RoutesHash":"","Routes":[],"IpRanges":[],"ServerAuthorizationProperties":{"ServerAuthPropertiesHash":""},"CamerasHash":"","Cameras":[],"StreamsHash":"","Streams":[],"RtmpSettings":{"hash":"1589511271996","interfaces":[{"ip":"172.16.3.100","port":1935,"ssl":false}],"login":"","password":"","duration":6,"chunk_count":4,"hls_part_duration":1000,"dash_template":"NUMBER","generate_icecast_metadata":true,"protocols":["HLS","RTMP","MPEG2TS","ICECAST","DASH","RTSP","SLDP"],"apps":[{"app":"local","login":"root","password":"psw","duration":6,"chunk_count":4,"hls_part_duration":1000,"dash_template":"TIME","generate_icecast_metadata":true,"protocols":["HLS","RTMP","MPEG2TS","ICECAST","DASH","RTSP","SLDP"]}],"abr":[]},"RtspSettings":{"hash":"1589502370997","interfaces":[]},"IcecastSettings":{"hash":"1589502373053","interfaces":[]},"LivePullSettings":{"hash":"1589502491133","streams":[]},"RtmpPublishSettings":{"hash":"1589502499024","settings":[]},"RtspPublishSettings":{"hash":"1589502497581","settings":[]},"ManagedTasks":
{"hash":"0", "tasks": []},"HlsDRMSettings": {"hash":"0", "url":"",
"key":"", "KeyServerSettings":
{}},"HttpOriginApps":{"hash":"0","apps":[]},"Aliases":{"hash":"0","settings":[]},"DataSlicesInfo":{"hash":"1","data_slices":[{"id":"54118","tz":0}]},"UDPSenderSettings":{"hash":"0","settings":[]},"PayPerPublishSettings":{"hash":"0","url":"","auth_group_interval":500,"apps":[]},"DvrSettings":{"hash":"1589502502894","settings":[]},"UserAgentGroupSettings":{"hash":"0","settings":[]},"RefererGroupSettings":{"hash":"0","settings":[]},"VideoEncodersInfo":{"hash":"0","encoders":[]},"AudioEncodersInfo":{"hash":"0","encoders":[]},"StreamOverrideSettings":{"hash":"0","settings":[]},"IcecastStreamSettings":
{"hash":"1589502513135","settings":
[]},"AuthHandlerSettings":{"hash":""},"ServerSettings":{"MaxCacheSize":64,"MaxFileCacheSize":4096,"LogMode":"debug"}}})";
json_object *rules = json_tokener_parse(json);
if(!rules) {
return -1;
}
printf("json parsed\n");
json_object_put(rules);

return 0;
}

if I run it when latest "libjson-c3:amd64
0.12.1-1.3ubuntu0.1" installed on my ubuntu 18.04 I get crash with
"lh_table_new: calloc failed" message
but if I downgrade to previous libjson-c3:amd64 0.12.1-1.3
it works fine

Bug#960702: ethtool -m values change when output is redirected

[Yannis Aribaud]

Package: ethtool
Version: 1:4.19-1
Severity: important
I'm facing a very strange behavior. The command ethtool -m  report the 
transceiver DOM values correctly, but when the command output is redirected to 
an other program, values change to somthing else.

Here is a transcript:
root@localhost:~# ethtool -m enp10s0; echo -e 'nnn'; ethtool -m enp10s0 | cat
 Identifier : 0x03 (SFP)
 Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
 Connector : 0x07 (LC)
 Transceiver codes : 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
 Transceiver type : 10G Ethernet: 10G Base-SR
 Encoding : 0x06 (64B/66B)
 BR, Nominal : 10300MBd
 Rate identifier : 0x00 (unspecified)
 Length (SMF,km) : 0km
 Length (SMF) : 0m
 Length (50um) : 80m
 Length (62.5um) : 20m
 Length (Copper) : 0m
 Length (OM3) : 300m
 Laser wavelength : 850nm
 Vendor name : Pureoptics
 Vendor OUI : 00:00:00
 Vendor PN : EX-SFP-10GE-SR
 Vendor rev : B4
 Option values : 0x00 0x1a
 Option : RX_LOS implemented
 Option : TX_FAULT implemented
 Option : TX_DISABLE implemented
 BR margin, max : 0%
 BR margin, min : 0%
 Vendor SN : M4351243
 Date code : 190515
 Optical diagnostics support : Yes
 Laser bias current : 16.480 mA
 Laser output power : 3.0768 mW / 4.88 dBm
 Receiver signal average optical power : 1.2298 mW / 0.90 dBm
 Module temperature : 48.47 degrees C / 119.24 degrees F
 Module voltage : 1.2336 V
 Alarm/warning flags implemented : Yes
 Laser bias current high alarm : Off
 Laser bias current low alarm : Off
 Laser bias current high warning : Off
 Laser bias current low warning : Off
 Laser output power high alarm : Off
 Laser output power low alarm : Off
 Laser output power high warning : Off
 Laser output power low warning : Off
 Module temperature high alarm : Off
 Module temperature low alarm : Off
 Module temperature high warning : Off
 Module temperature low warning : Off
 Module voltage high alarm : Off
 Module voltage low alarm : Off
 Module voltage high warning : Off
 Module voltage low warning : Off
 Laser rx power high alarm : Off
 Laser rx power low alarm : Off
 Laser rx power high warning : Off
 Laser rx power low warning : Off
 Laser bias current high alarm threshold : 4.744 mA
 Laser bias current low alarm threshold : 49.896 mA
 Laser bias current high warning threshold : 51.776 mA
 Laser bias current low warning threshold : 50.910 mA
 Laser output power high alarm threshold : 2.5701 mW / 4.10 dBm
 Laser output power low alarm threshold : 0.8224 mW / -0.85 dBm
 Laser output power high warning threshold : 0.8224 mW / -0.85 dBm
 Laser output power low warning threshold : 0.8224 mW / -0.85 dBm
 Module temperature high alarm threshold : 0.00 degrees C / 32.00 degrees F
 Module temperature low alarm threshold : 0.00 degrees C / 32.00 degrees F
 Module temperature high warning threshold : 0.00 degrees C / 32.00 degrees F
 Module temperature low warning threshold : 0.00 degrees C / 32.00 degrees F
 Module voltage high alarm threshold : 0.4356 V
 Module voltage low alarm threshold : 0. V
 Module voltage high warning threshold : 0. V
 Module voltage low warning threshold : 0. V
 Laser rx power high alarm threshold : 0.8224 mW / -0.85 dBm
 Laser rx power low alarm threshold : 0.8224 mW / -0.85 dBm
 Laser rx power high warning threshold : 0.8224 mW / -0.85 dBm
 Laser rx power low warning threshold : 0.8224 mW / -0.85 dBm
 Identifier : 0x03 (SFP)
 Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
 Connector : 0x07 (LC)
 Transceiver codes : 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
 Transceiver type : 10G Ethernet: 10G Base-SR
 Encoding : 0x06 (64B/66B)
 BR, Nominal : 10300MBd
 Rate identifier : 0x00 (unspecified)
 Length (SMF,km) : 0km
 Length (SMF) : 0m
 Length (50um) : 80m
 Length (62.5um) : 20m
 Length (Copper) : 0m
 Length (OM3) : 300m
 Laser wavelength : 850nm
 Vendor name : Pureoptics
 Vendor OUI : 00:00:00
 Vendor PN : EX-SFP-10GE-SR
 Vendor rev : B4
 Option values : 0x00 0x1a
 Option : RX_LOS implemented
 Option : TX_FAULT implemented
 Option : TX_DISABLE implemented
 BR margin, max : 0%
 BR margin, min : 0%
 Vendor SN : M4351243
 Date code : 190515
 Optical diagnostics support : Yes
 Laser bias current : 16.448 mA
 Laser output power : 0.8224 mW / -0.85 dBm
 Receiver signal average optical power : 0.8224 mW / -0.85 dBm
 Module temperature : 32.12 degrees C / 89.83 degrees F
 Module voltage : 0.8224 V
 Alarm/warning flags implemented : Yes
 Laser bias current high alarm : Off
 Laser bias current low alarm : Off
 Laser bias current high warning : Off
 Laser bias current low warning : Off
 Laser output power high alarm : Off
 Laser output power low alarm : Off
 Laser output power high warning : Off
 Laser output power low warning : Off
 Module temperature high alarm : Off
 Module temperature low alarm : Off
 Module temperature high warning : Off
 Module temperature low warning : Off
 Module voltage high alarm : On
 Module voltage low alarm : Off
 Module voltage high warning : On
 Module voltage low 

Bug#872432: licensecheck patch for "additional ignores"

[Jonas Smedegaard]

Control: retitle -1 licensecheck: should support adding (nor replacing) ignores
Control: block -1 by 960695

[ resposting with 7bit headers to please Debian MTAs ]

Quoting IOhannes m zmölnig (2017-10-06 10:29:21)
> here's a smallish patch that allows to specify a regex for 
> *additionally* ignored files when doing a licensecheck, as requested 
> in #872432.
> 
> this is kept separately from the original "--ignore|-i" flag to not 
> break any existing uses of licensecheck. also i think that "-x" is 
> easier to remember than "--install^Wignore" :-)

Thanks (and sorry for several years of silence!).

I dislike adding more options for same functionality, and I dislike that 
the option --ignore is a regex.  Instead, I consider adding new option 
"--usage" to change behaviour and defaults of other options, treating 
current behaviours as --usage=legacy.  See bug#960695 for details.

This is current "licensecheck --help":

 -i STR --ignore STRregular expression of files to skip
(default value: some backup and VCS files)


How do you think about this future "licensecheck --help":

 -i STR --ignore STRfiles to skip;
with usage=legacy a regular expression
replacing previous or default value,
with any other usage a comma-separated list 
adding onto previous and default values
except an empty value which clears the list
(default value: some backup and VCS files)


 - 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#960206: olive-editor: does not start due to OpenColorIO error

[Adrian Bunk]

Control: reassign -1 libyaml-cpp0.6
Control: forcemerge 959201 -1

On Fri, May 15, 2020 at 04:33:13PM +0200, bart...@fenski.pl wrote:
> On 2020-05-15 16:25, Adrian Bunk wrote:
> > On Sun, May 10, 2020 at 06:00:04PM +0200, Bartosz Fenski wrote:
> > > Package: olive-editor
> > > Version: 20200210-1
> > > Severity: grave
> > > 
> > > After fresh install olive doesn't start at all
> > > 
> > > fenio@udebian:~$ olive-editor
> > > Using Qt version: 5.12.5
> > > [OpenColorIO Info]: Color management disabled. (Specify the $OCIO
> > > environment variable to enable.)
> > > terminate called after throwing an instance of
> > > 'OpenColorIO::v1::Exception'
> > >   what():  Error: Loading the OCIO profile failed. The specified
> > > file does not appear to be an OCIO configuration.
> > > Aborted
> > > ...
> > 
> > Does it work after upgrading libyaml-cpp0.6 to 0.6.3-7?
> 
> Well now it works but I'm not the one to confirm that this upgrade fixed it.
> But it happened yesterday on my laptop so it could fix it ;)

Thanks, this is sufficient to confirm that it was this bug.

> regards
> Bartosz Fenski

cu
Adrian