Bug#975254: bridge-method-injector: Wrong homepage

[Davide Prina]

Package: bridge-method-injector
Version: 1.18-2
Severity: normal

I have see that the homepage
http://bridge-method-injector.infradna.com/
do not respond anymore

I think that the new homepage is:
https://github.com/infradna/bridge-method-injector

Ciao
Davide

Bug#975074: libefreet-bin has circular Depends on libeio1

[Ross Vandegrift]

Control: reassign 963881 src:efl
Control: reassign -1 src:efl
Control: merge 963881 -1
Control: retitle -1 efl binary packages should be reorganized to eliminate 
internal cycles

EFL's various libraries have dependency cycles between them.  We haven't been
able to robustly eliminate them with split binary packages.  The next step is
to bundle them into a single binary package.

Upstream is working on linking all of them into a single lib.  I'd like to hold
off on the bundling until that is ready or abandoned.

Some discussion on the issue is at [1].

Ross

[1] - 
https://alioth-lists.debian.net/pipermail/pkg-e-devel/2020-February/003674.html

Bug#975255: dblatex: Error when parameter table.in.float='0' and a table is spreaded on two pages

[Jérôme Arbez-Gindre]

Package: dblatex
Version: 0.3.11py3-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: jeromearbezgin...@gmail.com

Dear Maintainer,

 3 attached files minimal configuration to reproduce the issue

 The xsl file includes the following line:
 

 When I invoke the command:
 dblatex -V -o not.table.in.float.pdf -d --tmpdir=. 
--texstyle=./dblatex-conf.sty --xsl-user=dblatex-conf.xsl not.table.in.float.xml

 The command is failing with these errors on the output:
 not.table.in.float.tex:283: Something's wrong--perhaps a missing \item.
 not.table.in.float.tex:283: leading text: \end{center}

 Note that the pdf is generated, but I dont know if teh generation
 is complete.  Note also that if the parameter table.in.float is
 set to '1', there is no error (but of course the table is not spreaded on 
two pages !)

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dblatex depends on:
ii  docbook-xml   4.5-9
ii  python3   3.8.6-1
ii  python3-apt   2.1.5
ii  texlive   2020.20200925-1
ii  texlive-bibtex-extra  2020.20200925-1
ii  texlive-extra-utils   2020.20200925-1
ii  texlive-latex-extra   2020.20200925-1
ii  texlive-science   2020.20200925-1
ii  xsltproc  1.1.34-4

Versions of packages dblatex recommends:
ii  dblatex-doc0.3.11py3-1
ii  libxml2-utils  2.9.10+dfsg-6.2

Versions of packages dblatex suggests:
ii  docbook  4.5-6
ii  evince [pdf-viewer]  3.38.0-2
ii  fig2dev [transfig]   1:3.2.7b-5
ii  ghostscript  9.53.3~dfsg-5
ii  imagemagick  8:6.9.11.24+dfsg-1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.24+dfsg-1+b2
ii  inkscape 1.0.1-1
pn  latex-cjk-all
ii  lmodern  2.004.5-6
pn  opensp   
pn  texlive-lang-all 
pn  texlive-lang-cyrillic
pn  texlive-xetex
pn  xindy

-- no debconf information
%%
%% This style is derivated from the docbook one
%%


%% Just use the original package and pass the options
\RequirePackageWithOptions{docbook}

% Define front/main/back matter if not available
\def\frontmatter{\cleardoublepage\pagenumbering{roman}
  \fancyfoot[C]{
\DBKcopyright{} \\
\DBKlegalblock{}
  }
}

http://www.w3.org/1999/XSL/Transform; version='1.0'>











http://docbook.org/ns/docbook; 
xmlns:xl="http://www.w3.org/1999/xlink; version="5.0" xml:lang="en">

not.table.in.float
Something is wrong
{git-date}

Copyright text



Jérôme

jer...@example.com

J


{git-describe}
{git-date}
J



  Legal Notice Text



Subject
Eius populus ab incunabulis primis ad usque pueritiae tempus extremum,
quod annis circumcluditur fere trecentis, circummurana pertulit bella,
deinde aetatem ingressus adultam post multiplices bellorum aerumnas
Alpes transcendit et fretum, in iuvenem erectus et virum ex omni plaga
quam orbis ambit inmensus, reportavit laureas et triumphos, iamque
vergens in senium et nomine solo aliquotiens vincens ad tranquilliora
vitae discessit.
Eius populus ab incunabulis primis ad usque pueritiae tempus extremum,
quod annis circumcluditur fere trecentis, circummurana pertulit bella,
deinde aetatem ingressus adultam post multiplices bellorum aerumnas
Alpes transcendit et fretum, in iuvenem erectus et virum ex omni plaga
quam orbis ambit inmensus, reportavit laureas et triumphos, iamque
vergens in senium et nomine solo aliquotiens vincens ad tranquilliora
vitae discessit.
Eius populus ab incunabulis primis ad usque pueritiae tempus extremum,
quod annis circumcluditur fere trecentis, circummurana pertulit bella,
deinde aetatem ingressus adultam post multiplices bellorum aerumnas
Alpes transcendit et fretum, in iuvenem erectus et virum ex omni plaga
quam orbis ambit inmensus, reportavit laureas et triumphos, iamque
vergens in senium et nomine solo aliquotiens vincens ad tranquilliora
vitae discessit.
Eius populus ab incunabulis primis ad usque pueritiae tempus extremum,
quod annis circumcluditur fere trecentis, circummurana pertulit bella,
deinde aetatem ingressus adultam post multiplices bellorum aerumnas
Alpes transcendit et fretum, in iuvenem erectus et virum ex omni plaga
quam orbis ambit inmensus, reportavit laureas et triumphos, iamque
vergens in senium et nomine solo aliquotiens vincens ad tranquilliora
vitae discessit.
Eius populus ab incunabulis primis ad usque pueritiae tempus extremum,
quod annis circumcluditur fere trecentis, 

Bug#973285: freecad ftbfs with python3.9

[Tobias Frost]

On Wed, 28 Oct 2020 09:22:58 +0100 Matthias Klose  wrote:
> Package: src:freecad
> Version: 0.18.4+dfsg2-5
> Severity: serious
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: python3.9
> 
> to reproduce, you can use the repositories found at:
> 
> deb [trusted=yes] http://people.debian.org/~doko/tmp/python3.9 ./
> deb [trusted=yes] http://people.debian.org/~ginggs/python3.9-repo ./
> 
> this doesn't look 3.9 specific, but looks like a missing call to cython3.
Please
> make sure that cython is run for all files during the build.
> 
> [...]
> In file included from
> /<>/freecad-0.18.4+dfsg2/src/CXX/cxx_extensions.cxx:42:
> /<>/freecad-0.18.4+dfsg2/src/CXX/Python3/cxx_extensions.cxx: In
> constructor ‘Py::PythonType::PythonType(size_t, int, const char*)’:
> /<>/freecad-0.18.4+dfsg2/src/CXX/Python3/cxx_extensions.cxx:384:12:
> error: ‘PyTypeObject’ {aka ‘struct _typeobject’} has no member named
> ‘tp_print’
>   384 | table->tp_print = 0;
>   |^~~~
> /<>/freecad-0.18.4+dfsg2/src/CXX/Python3/cxx_extensions.cxx: In
member
> function ‘Py::PythonType& Py::PythonType::supportPrint()’:
> /<>/freecad-0.18.4+dfsg2/src/CXX/Python3/cxx_extensions.cxx:527:12:
> error: ‘PyTypeObject’ {aka ‘struct _typeobject’} has no member named
> ‘tp_print’
>   527 | table->tp_print = print_handler;
>   |^~~~
> 
> 

Discussed upstream and possibly patch available: 
https://forum.freecadweb.org/viewtopic.php?f=10=47348

--
tobi

Bug#971830: fonts-jetbrains-mono: please advertise which scripts are covered

[Jonas Smedegaard]

Quoting Romain Porte (2020-11-19 18:07:15)
> 2020-11-19 00:43 CET, Jonas Smedegaard:
> > I sure hope you had fun diving into this - and that I did not 
> > mislead you when suggesting to explore this.
> 
> I�sure did, it allowed me to learn how the substitution system and 
> dh_gencontrol work. It is just the result that I find disappointing in 
> the end.
> 
> > There must be code out there to automate the task of inspecting 
> > language coverage, but I have not yet found anything useful to 
> > package for Debian.  That would be nice, and I would certainly use 
> > it for package description of Noto fonts.
> 
> Would you not be concerned about introducing 145 lines listing the 
> languages in the long description? I think "long" should be "long 
> enough", not "exhaustive".
> 
> > >   List of supported scripts:
> > >- Default
> > >- Latin
> > >- Latin/Azeri
> > >- Latin/Catalan
> > >- Latin/Crimean
> > >- Latin/Kazakh
> > >- Latin/Moldavian
> > >- Latin/Romanian
> > >- Latin/Tatar
> > >- Latin/Turkish
> 
> Is this addition in the package's long decription worthwhile to you, 
> and if so, should I merge the proposed patch?
> 
> I see in the noto fonts package that the long description contains:
> 
> > The name "Noto" is short for "No Tofu",
> > describing the aim of covering all living Unicode scripts
> > (currently 65 are covered, at least partly.
> 
> Which is different from what I came with. I would be *happier* to 
> follow what noto currently does by piping in a `| wc -l` to mention 
> " scripts covered" instead of "list of supported scripts".
> 
> Do you agree with this approach? Or do you want to take my patch and 
> apply it to the noto fonts instead aswell? ;)

I would indeed not use raw listings of more than 50 entries, but would 
try find ways to summarize the information most sensibly.

With current tools, I do find it most sensible to do as I did for the 
Noto font families.  I am no authority here, but if you agree then sure, 
I do encourage you to try mimick that same style for jetbrains font.

What I mean by stating that I would "certainly use" more accurate 
language coverage analysis tools is that they could help replace that 
annoying trailing "at least partly" remark with more accurate facts.


 - 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#972651: fastd 18-3+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 972651 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: fastd
Version: 18-3+deb10u1

Explanation: fix memory leak when receiving too many invalid packets 
[CVE-2020-27638]

Bug#971685: fish 3.0.2-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 971685 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: fish
Version: 3.0.2-2+deb10u1

Explanation: ensure TTY options are restored on exit

Bug#973655: distro-info-data 0.41+deb10u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 973655 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: distro-info-data
Version: 0.41+deb10u3

Explanation: add Ubuntu 21.04, Hirsute Hippo

Bug#975016: OpenJDK 15 support state for Bullseye

[Adrian Bunk]

On Thu, Nov 19, 2020 at 07:47:14PM +0100, Moritz Mühlenhoff wrote:
> On Wed, Nov 18, 2020 at 10:31:30PM +0100, Thorsten Glaser wrote:
> > I think nobody wants to switch default-jdk to 17 or even not ship
> > 11 at all any more or stop supporting it during bullseye’s lifetime.
> > Maybe that also was too implicit?
> 
> Exactly, the supported Java release for the entire Bullseye lifetime will
> be 11 (which packages will build-depend on and what's provided by
> default-jdk.
> 
> The idea is to include 15/16 so that later on when 17 is ready, 17
> can be made available in addition via backports (since at some point
> later in the bullseye lifecycle might be software one wants to run
> which requires 17 as the next LTS.

17 can be in unstable before the release of bullseye.

If this is then eligible for testing migration except for the freeze,
it would enter testing in the first migration after the release.
With slight bending of the rules someone with ftp powers could then
copy the sources+binaries from bookworm/testing to bullseye-backports.

Slightly less bending of the rules and only marginally more effort would 
be to build ~bpo11+1 binaries for all bullseye release architectures
in unstable before the release of bullseye.

Either option sounds better to me than shipping 15 or 16 in a stable
release solely for bootstrapping 17 in backports.

> Cheers,
> Moritz

cu
Adrian

Bug#975272: osinfo-db: Indicate support for virtio in RHEL 8.0 and later

[Benjamin Moody]

Package: osinfo-db
Version: 0.20181120-1+deb10u1
Severity: normal

Dear Maintainer,

When creating a virtual machine using virt-manager, it prompts me to
select the operating system, and tries to select appropriate hardware,
based on what libosinfo knows about what devices are supported.

The consequence of this is that if I select "rhel-7.6" or
"rhel-7-unknown" as the OS, virt-manager will select virtio disk and
network devices.

However, if I select "rhel-8.0" or "rhel-8-unknown" or "rhel-unknown",
then virt-manager will select less efficient virtual devices (IDE disk
drive and e1000 network card.)

(It also won't include a virtual RNG device, which is arguably a bug
in virt-manager - I think adding a virtual RNG should be harmless for
OSes that don't support it, so it should be included unconditionally.)

It'd be possible to fix this and similar issues by constantly updating
the stable version of osinfo-db as new OSes are released.  However, it
would be wise to be more future-proof by default.  For OSes that are
*not yet released* (as RHEL 8.0 was not yet released at the time
osinfo-db was uploaded for Debian 10), in the absence of other
information, it seems best to assume they will support the same
hardware as the previous version.

(In particular, for RHEL, it seems unlikely that RHEL 9 will drop
support for the virtio devices that are provided by qemu in RHEL 8,
and so forth.)

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

Kernel: Linux 4.19.152-1.pvops.qubes.x86_64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#975275: ceph: CVE-2020-25660: CEPHX_V2 replay attack protection lost

[Salvatore Bonaccorso]

Source: ceph
Version: 14.2.9-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ceph.

CVE-2020-25660[0]:
| cephx authentication protocol does not verify ceph clients correctly

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-25660
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25660
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1890354

Regards,
Salvatore

Bug#975277: postgis: autopkgtests missing "skippable" keyword

[Gianfranco Costamagna]

Source: postgis
Version: 3.0.2+dfsg-4
Severity: serious
tags: patch


Hello, doing exit 77 helps in marking some tests as skippable,
but we need to add a Restriction: skippable too to let autopkgtests understand 
that this is intentional.

Restrictions: allow-stderr, skippable


Thanks for adding the restriction

Gianfranco

Bug#974969: The "-full-screen" option causes guest display to overflow outside the host screen

[bakhelit]

After, further testing (basically 2 days of reading all QEMU docs and 
changelogs I found and messing around with various QEMU options:) I was 
able to solve my problems with the "-full-screen" option.


The solution was to add the following option to my QEMU command:

-display gtk,gl=on,grab-on-hover=on,zoom-to-fit=on

The important bit that solved the display overflowing behavior is the 
"zoom-to-fit=on" suboption. This lets my VM to have the screen 
resolution I configure in it (e.g. 1920x1080) and when not in full 
screen mode it zooms the VM display to fit any QEMU window size without 
changing the screen resolution inside my VM. Although, the 
"-full-screen" option should probably work correctly on its own, so my 
solution is just a workaround.


Also, remember the problem with "-soundhw hda" option, which prevented 
VM from starting with QEMU version from Debian Backports 
(5.0-14~bpo10+1)? It seems to occur in a different way also in QEMU 
version from Debian Stable (3.1+dfsg-8+deb10u8). In QEMU version 
3.1+dfsg-8+deb10u8 my VM can start with the "-soundhw hda" option, but 
unfortunatelly the VM cannot produce any usable sound. I noticed there 
is already bug 949111 for this, so I described the details I observed in 
that bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949111#15).


Finally, the initial delay on VM start is still there and it still 
shortens after repeated VM starts.


Taken together, I guess QEMU is now usable enough for me on Debian 10, 
but it could be better if at least some of the problems I described are 
fixed properly.


Anyway, here is my QEMU test command (updated with the display 
overflowing workaround) if someone wants to try reproduce and debug the 
problems I described (it is single line in case email reformats it):


QEMU_PA_SERVER='/run/user/1000/pulse/native' QEMU_AUDIO_DRV='pa' 
qemu-system-x86_64 -display gtk,gl=on,grab-on-hover=on,zoom-to-fit=on 
-full-screen -enable-kvm -machine type=q35,accel=kvm -soundhw hda 
-netdev user,id=vnet -device e1000,netdev=vnet -cpu host -smp cores=2 -m 
2048 -drive file=DISK.raw,format=raw,index=0,media=disk -drive 
file=IMAGE.iso,index=2,media=cdrom


Regards
Bakhelit

Bug#892058: Thanks

[Dominique Dumont]

Thanks for this reminder.

More importantly, thanks for providing the right links to documentation. 
Setting the new expiry date (and sending the key) was done in less than 5mns.

All the best

Bug#974882: RFS: pentobi/18.3-1 [RC] -- clone of the strategy board game Blokus

[Juhani Numminen]

Control: retitle -1 RFS: pentobi/18.3-1 [RC] -- clone of the strategy board 
game Blokus
Control: severity -1 important

Dear mentors,

This upload would now fix an FTBFS bug because v18.3 of the software
has fixed compilation with Qt 5.15.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975128

Regards,
Juhani

Bug#974080: ITP: lua-binaryheap -- Binary heap implementation in lua

[Santiago Ruano Rincón]

El 19/11/20 a las 16:45, Jakub Ružička escribió:
> On 11/17/20 4:41 PM, Santiago Ruano Rincón wrote:
> > El 09/11/20 a las 13:31, Jakub Ružička escribió:
> >> Package: wnpp
> >> Severity: wishlist
> >> Owner: Jakub Ružička 
> >>
> >> * Package name: lua-binaryheap
> >>   Version : 0.4
> >>   Upstream Author : Thijs Schreijer 
> >> * URL : https://github.com/Tieske/binaryheap.lua
> >> * License : MIT
> >>   Programming Lang: lua
> >>   Description : binary heap implementation in lua
> >>
> >> binaryheap.lua is a binary heap (binary tree) implementaion in lua.
> >>
> > ...
> >
> > Jakub, thanks for packaging lua-binaryheap.
> Thanks for fast respone, Santiago :)
> >
> > Two lintian "major" comments from your current repo:
> >
> > W: lua-binaryheap source: ancient-standards-version 3.9.8 (released 
> > 2016-04-06) (current is 4.5.0)
> > W: lua-binaryheap source: package-uses-deprecated-debhelper-compat-version 9
> >
> > Do you have any reason for that standards-version and
> > debhelper-compat-version?
> Upstream packages support older distros including ubuntu xenial so it's
> just a leftover - I've updated these to current.
> >
> > These other lintian minor warnings could be easily fixed:
> >
> > I: lua-binaryheap: capitalization-error-in-description lua Lua
> > I: lua-binaryheap source: debian-watch-file-is-missing
> > I: lua-binaryheap source: vcs-field-not-canonical Vcs-Git
> >
> > Could you please consider them?
> I've fixed all of them except debian-watch-file-is-missing because
> upstream is using one the weirdest version tag scheme I've witnessed
> (version_0v4) and I'm not familiar with watch files enough to solve this
> efficiently.

Great, thanks!
I'll upload it later this evening.

> 
> I've pushed fixed debian/master and you can see lintian output in CI:
> 
> https://salsa.debian.org/jruzicka/lua-binaryheap/-/jobs/1176088#L27
> 
> Thank you for Salsa CI suggestion and help with enabling it. I like it
> and I'll probably use it for other packages too.

:-)

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#975109: antimony: FTBFS in testing and unstable

[Tobias Frost]

Source: antimony
Followup-For: Bug #975109
Control: tags -1 patch

This is a missing include on QPainterPath. Attaching patch.

--
tobi
--- a/app/viewport/control/control.h
+++ b/app/viewport/control/control.h
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 class NodeProxy;
--- a/app/viewport/control/control_instance.h
+++ b/app/viewport/control/control_instance.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 
 class Control;
 class ViewportView;
--- a/app/canvas/connection/base.h
+++ b/app/canvas/connection/base.h
@@ -1,6 +1,7 @@
 #pragma once
 
 #include 
+#include 
 
 class BaseConnection : public QGraphicsObject
 {

Bug#971515: Status as of last tech-ctte meeting

[Ian Jackson]

Russ Allbery writes ("Bug#971515: Status as of last tech-ctte meeting"):
> [much stuff]

Oh, wow, Russ.  Thank you very much.  What an excellent piece of
writing.  I agree entirely with all of it.

Ian.

(And I speak as someone who thinks that this newfangled "vendor
everything" and "just download that shit from the internet" approach
is hideously bad engineering practice.)

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#968114: /lib/runit-helper/runit-helper: 74: sv: not found

[Martin-Éric Racine]

Package: dh-runit
Followup-For: Bug #968114

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This bug is not really fixed.  The fix was only pushed to experimental.  
Meanwhile, packages in unstable still face this issue.  Given how close we are 
to the freeze, it would be a good idea to push this into unstable ASAP.

- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (1000, 'testing-debug'), (1000, 'testing'), (500, 'stable')
Architecture: i386 (i586)

Kernel: Linux 5.9.0-1-686 (SMP w/1 CPU thread)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dh-runit depends on:
ii  debhelper13.2.1
pn  libfile-copy-recursive-perl  
pn  libfile-slurp-perl   
pn  libtext-hogan-perl   

dh-runit recommends no packages.

dh-runit suggests no packages.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAl+2pG0ACgkQrh+Cd8S0
17ZyXA/7BxDfgQlSdDkaEFg4+v9Sqy3r8T7POR2XXq7v6yjhTxxIvGzC21M6rfFH
vb8e4wuV7c0B7oS5YwOkSinX3LIElvJqsPxwI/8CDapTK/F4SnO+c/+Z0qzb6MDL
fcBVVpY5tU/IyBWmQRzgGfsap8JkzKXK3o/GsqHb2vW+4nxC6g4b6cljxQIeASK7
CVoeVvgBo3lhGFLMFaIaFLgfmzwoJjo71juYoJAHkChBbELbfGTNVGo6qL9R2pKl
4zI0Ln83yyJQfL/obaoW93KkSZigjoeRgZ7d9IdDURsvfi3r0fnRcfdidlj/Mejk
q/jsmM+hPINc3+uxySpsdLIqVKWfSKa6wexuyQay6OyQCNeejDzQxjObbEiq2hAK
9vmVfDoxctLiH2wbm34OGZ30L1qCNQQX4MFkqTLAaEZl5DS+a+V8tAiDU+brkZxQ
W1qVBjbFfjizVQ1TswvDWwQnGgVGm2heTchktgHXNacrNVZAEOJN9i9nddj8/7XS
4mUKfHeObV1sdYOq23T7XsEXTnSxAlnQ2OblqMutA3oqdc2DJVfVrlvkYHG9sbQ9
WVkr0NiufpI8oQDt4JbAEvty2ahx302T27/Jr3++R2pf9DvJn8FS+btsWGuLKYHb
WrE2NzSkyG6H0NBNSxE+ts7bQIOqvFR8R4fubL+SusGH+kPmQzk=
=+vVK
-END PGP SIGNATURE-

Bug#576959: jnettop: No IPv6 on PPP interface

[Roman Mamedov]

Hello,

Just wanted to confirm that this remains an issue even though more than 10
years have passed since the initial bug report.

Thanks

-- 
With respect,
Roman

Bug#973741: gitlab: Yarn hasn't been able to find a cache folder it can use

[Xavier]

Le 19/11/2020 à 18:31, Michael Prokop a écrit :
> Hi,
> 
> * Pirate Praveen [Thu Nov 19, 2020 at 03:05:13PM +0530]:
> 
>> As you already found out, the problem is in node-yarnpkg. The fix is
>> a bit hard though as node-yarnpkg currently ftbfs due to babel 7
>> transition.
> 
>> A work around could be to install yarnpkg via npm. npm install -g
>> yarn and replace the yarnpkg command.
> 
> I noticed that yarnpkg currently isn't part of Debian/testing
> (according to https://tracker.debian.org/pkg/node-yarnpkg due to
> "Updating node-yarnpkg introduces new bugs: #960120, #972952, #973741").
> 
> It would be rather unfortunate if it wouldn't make it into bullseye.
> Sadly I can't really help with the mentioned bugreports myself, but is
> there a chance, to see yarnpkg back in Debian/testing (given that
> latest interaction in e.g. #960120 dates back to August) so it could
> make it into bullseye? :)
> 
> Thanks!
> 
> regards
> -mika-

Hi,

we opened bugs to upstream repo and are waiting for...

Cheers,
Xavier

Bug#975266: CVE-2020-27616

[Moritz Muehlenhoff]

Package: qemu
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2020-27616:
https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg06080.html

Cheers,
Moritz

Bug#975250: clarify gathering together of copyright information

[Sean Whitton]

Hello,

On Thu 19 Nov 2020 at 05:07PM +01, Marc Haber wrote:

> /usr/share/doc/debian-policy/copyright-format-1.0.txt.gz says
>
> |The Copyright field collects all relevant copyright notices for the files
> |of this paragraph. Not all copyright notices may apply to every 
> individual
> |file, and years of publication for one copyright holder may be gathered
> |together. For example, if file A has:
> |
> |  Copyright 2008 John Smith
> |  Copyright 2009 Angela Watts
> |
> |and file B has:
> |
> |  Copyright 2010 Angela Watts
> |
> |a single paragraph may still be used for both files. The Copyright field
> |for that paragraph would contain:
> |
> |  Copyright 2008 John Smith
> |  Copyright 2009, 2010 Angela Watts
>
> But what if file A says
>
> |  Copyright 2008 John Smith
> |  Copyright 2005-2015 Angela Watts
>
> and file B has:
>
> |  Copyright 2010 Angela Watts
>
> Can this be gathered together to:
>
> |  Copyright 2008 John Smith
> |  Copyright 2005-2015 Angela Watts
>
> or does it have to be
>
> |  Copyright 2008 John Smith
> |  Copyright 2009, 2005-2015 Angela Watts
>
> ?

The former.  If you'd like to propose a patch making this clearer we
could get it applied.

-- 
Sean Whitton

Bug#959422: 959422: Info received (Bug#959422: [20200502] ftp.nluug.nl: out-of-date)

[Julien Cristau]

Control: retitle -1 [20201119] ftp.nluug.nl: out-of-date

On Mon, May 04, 2020 at 02:44:09PM +0200, Mike Hulsman wrote:
> Hi,
> 
> I fixed the problem by changing to another source.
> In the mirror report I see 2 valid syncs.
> 
Hi Mike,

it looks like ftp.nluug is behind once again, see
https://mirror-master.debian.org/status/mirror-info/ftp.nluug.nl.html

Cheers,
Julien

Bug#975269: buster-pu: package linux/TBD - arm64 stolen time support

[Ben Hutchings]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: no...@debian.org

There are two parts to the proposed changes:

1. Support in arm64 KVM code for reporting stolen time to guests.
2. Support in arm64 paravirtualised guest code for requesting stolen
   time from the hypervisor and reporting it to user-space.

I think part 1 is not suitable for a stable update, but part 2 might
be.

[ Reason ]

Noah Meyerhans wrote in bug #969443:
> When used in virtual machine environments, Linux on amd64 is able to report
> "steal time" to the guest.  This functionality has been supported by Linux
> on amd64 for years, but was only added to arm64 with Linux 5.5.
> 
> As Debian and arm64 are increasingly used in virtual environments, including
> cloud environments, the ability to report steal time is increasingly
> important for system monitoring and performance analysis.  Thus, I'd like to
> request that CPU steal time accounting support for arm64 be backported to
> buster, if possible.

[ Impact ]

Without this, it's difficult to determine when VM performance is being
affected by stolen time.

[ Tests ]

Noah has tested the changes (at least part 2) in an arm64 KVM
environment with steal time reporting, presumably AWS EC2.

[ Risks ]

There is a potential to regress VM host and/or guest support on arm64
and armhf, depending on which part(s) are applied.

[ Changes ]

1. * KVM: arm64: Document PV-time interface
   * KVM: arm/arm64: Factor out hypercall handling from PSCI
   * KVM: arm64: Implement PV_TIME_FEATURES call
   * KVM: Implement kvm_put_guest()
   * KVM: arm64: Support stolen time reporting via shared
   * KVM: Allow kvm_device_ops to be const
   * KVM: arm64: Provide VCPU attributes for stolen time
2. * arm/arm64: smccc/psci: add arm_smccc_1_1_get_conduit()
   * arm/arm64: Provide a wrapper for SMCCC 1.1 calls
   * arm/arm64: Make use of the SMCCC 1.1 wrapper
   * arm64: Retrieve stolen time as paravirtualized guest

The actual patches are visible at
.

Ben.

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

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

Bug#975270: rdiff-backup: Can't talk to the version from buster

[Kurt Roeckx]

Package: rdiff-backup
Version: 2.0.5-1
Severity: important

Hi,

I recently found out that my backup has broken for months. It
seems that the version from testing doesn't want to talk to the
version from stable/buster.

It gives the following error:
Exception 'object.__new__(X): X is not a type object (classobj)' raised of 
class '':
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 304, in 
error_check_Main
try: Main(arglist)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 324, in 
Main
take_action(rps)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 278, in 
take_action
connection.PipeConnection(sys.stdin, sys.stdout).Server()
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/connection.py", line 355, 
in Server
self.get_response(-1)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/connection.py", line 315, 
in get_response
try: req_num, object = self._get()
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/connection.py", line 241, 
in _get
if format_string == "o": result = cPickle.loads(data)
  File "/usr/lib/python2.7/copy_reg.py", line 48, in _reconstructor
obj = object.__new__(cls)

Traceback (most recent call last):
  File "/usr/bin/rdiff-backup", line 30, in 
rdiff_backup.Main.error_check_Main(sys.argv[1:])
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 304, in 
error_check_Main
try: Main(arglist)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 324, in 
Main
take_action(rps)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 278, in 
take_action
connection.PipeConnection(sys.stdin, sys.stdout).Server()
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/connection.py", line 355, 
in Server
self.get_response(-1)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/connection.py", line 315, 
in get_response
try: req_num, object = self._get()
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/connection.py", line 241, 
in _get
if format_string == "o": result = cPickle.loads(data)
  File "/usr/lib/python2.7/copy_reg.py", line 48, in _reconstructor
obj = object.__new__(cls)
TypeError: object.__new__(X): X is not a type object (classobj)
Fatal Error: Truncated header string (problem probably originated remotely)

Couldn't start up the remote connection by executing

ssh -C X rdiff-backup --server

Remember that, under the default settings, rdiff-backup must be
installed in the PATH on the remote system.  See the man page for more
information on this.  This message may also be displayed if the remote
version of rdiff-backup is quite different from the local version (2.0.5).



If I downgrade to the local version 1.2.8-7, which is also the
remote version, things work.


Kurt

Bug#974695: buster-pu: package libxml2/2.9.4+dfsg1-7+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2020-11-13 at 22:33 +0100, Moritz Muehlenhoff wrote:
> This fixes a few low severity security fixes affecting libxml2,
> I've tested the package on a buster system with a few rdeps.
> 

Please go ahead.

Regards,

Adam

Bug#975251: bless: Wrong homepage + new version

[Davide Prina]

Package: bless
Version: 0.6.0-7
Severity: normal

I have see that the homepage
http://home.gna.org/bless/
do not respond anymore

I think that the new homepage is:
https://github.com/afrantzis/bless

Here there is the new version 0.6.3.

Ciao
Davide

Bug#973741: gitlab: Yarn hasn't been able to find a cache folder it can use

[Michael Prokop]

Hi,

* Pirate Praveen [Thu Nov 19, 2020 at 03:05:13PM +0530]:

> As you already found out, the problem is in node-yarnpkg. The fix is
> a bit hard though as node-yarnpkg currently ftbfs due to babel 7
> transition.

> A work around could be to install yarnpkg via npm. npm install -g
> yarn and replace the yarnpkg command.

I noticed that yarnpkg currently isn't part of Debian/testing
(according to https://tracker.debian.org/pkg/node-yarnpkg due to
"Updating node-yarnpkg introduces new bugs: #960120, #972952, #973741").

It would be rather unfortunate if it wouldn't make it into bullseye.
Sadly I can't really help with the mentioned bugreports myself, but is
there a chance, to see yarnpkg back in Debian/testing (given that
latest interaction in e.g. #960120 dates back to August) so it could
make it into bullseye? :)

Thanks!

regards
-mika-


signature.asc
Description: Digital signature

Bug#975208: Bug#975214: Bug#975210: libowl-directsemantics-perl: FTBFS: test failed

[gregor herrmann]

On Thu, 19 Nov 2020 12:28:53 +0100, gregor herrmann wrote:

> So this might be more of a problem in the recently updated
> libtype-tiny-perl (with or without involvement of perl 5.32, as
> Scalar::Util is dual-lifed).

As noted by Niko on IRC, the actual problem seems to be an ancient
Scalar::Util in inc/.

Now a proper fix would probably be to (convert to package from cdbs
to debhelper and) move inc/ away and back in d/rules (like we do for
other packages) and build-depend on the vendored modules; a
quick fix, tested with librdf-closure-perl, seems to work:

#v+
--- a/debian/rules
+++ b/debian/rules
@@ -47,3 +47,6 @@ CDBS_BUILD_DEPENDS +=, $(deps), $(deps-test)
 CDBS_DEPENDS_$(pkg) = $(deps)

 DEB_INSTALL_EXAMPLES_$(pkg) = examples/*
+
+clean::
+   $(RM) -rv $(CURDIR)/inc/Scalar
#v-


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: Beatles: Glass Onion


signature.asc
Description: Digital Signature

Bug#975102: Acknowledgement (RFS: fonts-jetbrains-mono/2.210-1 -- free and open-source typeface for developers)

[Romain Porte]

Hi,

Replying on the RFS as I have the impression that comments on the
mentors website does not notify people who commented the package.

Adding Gürkan Myczko in CC.

Gürkan Myczko on mentors.d.n:
> Add that Upstream-Contact: to your d/copyright...

Done.

Please review upload #2:
https://mentors.debian.net/package/fonts-jetbrains-mono/

Best regards,

Romain.


signature.asc
Description: PGP signature

Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

[Marco d'Itri]

On Nov 16, Niko Tyni  wrote:

> As to the fix, I suspect we need a pre-dependency from libc6 to libcrypt1
> for one release cycle, so that libc6 cannot be unpacked before libcrypt1
> is fully installed.
I think that Niko is right, so I would like to know the opinion of the 
glibc maintainers.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#975016: OpenJDK 15 support state for Bullseye

[Moritz Mühlenhoff]

On Wed, Nov 18, 2020 at 10:31:30PM +0100, Thorsten Glaser wrote:
> I think nobody wants to switch default-jdk to 17 or even not ship
> 11 at all any more or stop supporting it during bullseye’s lifetime.
> Maybe that also was too implicit?

Exactly, the supported Java release for the entire Bullseye lifetime will
be 11 (which packages will build-depend on and what's provided by
default-jdk.

The idea is to include 15/16 so that later on when 17 is ready, 17
can be made available in addition via backports (since at some point
later in the bullseye lifecycle might be software one wants to run
which requires 17 as the next LTS.

Cheers,
Moritz

Bug#975016: Python 2 / OpenJDK 15 support state for Bullseye

[Moritz Mühlenhoff]

On Wed, Nov 18, 2020 at 12:46:52PM +, Holger Levsen wrote:
> looks good to me!

Thanks for the upload.

> > One important thing: These only applies to Bullseye and
> > security-support-limited is currently independent of releases, so this
> > needs to be fixed or alternatively we need to stop rebuilding the current
> > unstable package for older releases and instead branch of per distro.
> 
> I've already switched to maintain the package in branches so this should be
> fairly easy. That said, splitting security-support-limited into
> security-support-limited.deb(9|10|11) still sounds reasonable to me as well.

Agreed, a split makes sense, it causes marginal additional overhead and makes
the whole setup more explicit.

Cheers,
Moritz

Bug#975037: recoll: watchfile broken

[Jean-Francois Dockes]

The url is now:
https://www.lesbonscomptes.com/recoll/pages/download.html
instead of
https://www.lesbonscomptes.com/recoll/download.html

J.F.

Tobias Frost writes:
 > Package: recoll
 > Severity: normal
 > 
 > Dear Maintainer,
 > 
 > tracker.d.o says "404" on the watch file, so it seems to be broken…
 > 
 > 
 > --
 > tobi

Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

[Sven Joachim]

On 2020-11-19 19:47 +0100, Marco d'Itri wrote:

> On Nov 16, Niko Tyni  wrote:
>
>> As to the fix, I suspect we need a pre-dependency from libc6 to libcrypt1
>> for one release cycle, so that libc6 cannot be unpacked before libcrypt1
>> is fully installed.
> I think that Niko is right, so I would like to know the opinion of the
> glibc maintainers.

I am not one of them, but AFAICS that would introduce a fatal circular
dependency between libc6 and libcrypt1: libc6 needs libcrypt1 to be
configured before it can be unpacked, but libcrypt1 depends on libc6 so
it cannot be configured before libc6 is at least unpacked.

Cheers,
   Sven

Bug#975274: RM: tarantool [arm64 armhf] -- RoQA; no longer builds on arm

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal
Control: block 972669 by -1

See #972669 for background.

Bug#975276: qemu: CVE-2020-25723

[Salvatore Bonaccorso]

Source: qemu
Version: 1:5.1+dfsg-4
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for qemu.

CVE-2020-25723[0]:
| assertion failure through usb_packet_unmap() in hw/usb/hcd-ehci.c

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-25723
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25723
[1] 
https://git.qemu.org/?p=qemu.git;a=commit;h=2fdb42d840400d58f2e706ecca82c142b97bcbd6

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#975252: ITP: r-cran-ff -- Memory-Efficient Fast-Access Storage of Large Data

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-ff -- Memory-Efficient Fast-Access Storage of Large Data
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-ff
  Version : 4.0.4
  Upstream Author : Daniel Adler
* URL : https://cran.r-project.org/package=ff
* License : GPL-2+
  Programming Lang: GNU R
  Description : Memory-Efficient Fast-Access Storage of Large Data
 The ff package provides data structures that are stored on
 disk but behave (almost) as if they were in RAM by transparently
 mapping only a section (pagesize) in main memory - the effective
 virtual memory consumption per ff object. ff supports R's standard
 atomic data types 'double', 'logical', 'raw' and 'integer' and
 non-standard atomic types boolean (1 bit), quad (2 bit unsigned),
 nibble (4 bit unsigned), byte (1 byte signed with NAs), ubyte (1 byte
 unsigned), short (2 byte signed with NAs), ushort (2 byte unsigned),
 single (4 byte float with NAs). For example 'quad' allows efficient
 storage of genomic data as an 'A','T','G','C' factor. The unsigned
 types support 'circular' arithmetic. There is also support for
 close-to-atomic types 'factor', 'ordered', 'POSIXct', 'Date' and
 custom close-to-atomic types.
 .
 ff not only has native C-support for vectors, matrices and arrays
 with flexible dimorder (major column-order, major row-order and
 generalizations for arrays). There is also a ffdf class not unlike
 data.frames and import/export filters for csv files.
 ff objects store raw data in binary flat files in native encoding,
 and complement this with metadata stored in R as physical and virtual
 attributes. ff objects have well-defined hybrid copying semantics,
 which gives rise to certain performance improvements through
 virtualization. ff objects can be stored and reopened across R
 sessions. ff files can be shared by multiple ff R objects
 (using different data en/de-coding schemes) in the same process
 or from multiple R processes to exploit parallelism. A wide choice of
 finalizer options allows to work with 'permanent' files as well as
 creating/removing 'temporary' ff files completely transparent to the
 user. On certain OS/Filesystem combinations, creating the ff files
 works without notable delay thanks to using sparse file allocation.
 Several access optimization techniques such as Hybrid Index
 Preprocessing and Virtualization are implemented to achieve good
 performance even with large datasets, for example virtual matrix
 transpose without touching a single byte on disk. Further, to reduce
 disk I/O, 'logicals' and non-standard data types get stored native and
 compact on binary flat files i.e. logicals take up exactly 2 bits to
 represent TRUE, FALSE and NA.
 .
 Beyond basic access functions, the ff package also provides
 compatibility functions that facilitate writing code for ff and ram
 objects and support for batch processing on ff objects (e.g. as.ram,
 as.ff, ffapply). ff interfaces closely with functionality from package
 'bit': chunked looping, fast bit operations and coercions between
 different objects that can store subscript information ('bit',
 'bitwhich', ff 'boolean', ri range index, hi hybrid index). This allows
 to work interactively with selections of large datasets and quickly
 modify selection criteria.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-ff

Bug#975253: bopm: Wrong homepage

[Davide Prina]

Package: bopm
Version: 3.1.3-3
Severity: normal

I have see that the homepage
http://wiki.blitzed.org/BOPM
do not respond anymore

I think that the new homepage is:
https://github.com/blitzed-org/bopm

In the README there is a note:
---8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--
This exists mostly as a history archive of the BOPM CVS, BOPM isn't really
maintained anymore.

You might be interested to look at hopm: https://github.com/ircd-hybrid/hopm
---8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--

and HOPM is already in Debian

Ciao
Davide

Bug#975260: RFS: dvbstreamer/2.1.0-5.1 [NMU] -- a console based streamer for DVB/ATSC service(s)

[Bastian Germann]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "dvbstreamer":

 * Package name: dvbstreamer
   Version : 2.1.0-5.1
   Upstream Author : Adam Charrett
 * URL : http://dvbstreamer.sf.net/
 * License : GPL-2
   Section : video

It builds those binary packages:

  dvbstreamer - a console based streamer for DVB/ATSC service(s)

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/d/dvbstreamer/dvbstreamer_2.1.0-5.1.dsc

Changes since the last upload:

 dvbstreamer (2.1.0-5.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Build with libedit (Closes: #966143).

Regards,
Bastian

Bug#961041: mirror submission for twitchdarkbot.com

[Julien Cristau]

Control: tag -1 moreinfo

On Tue, May 19, 2020 at 03:00:28PM +, Roul_ wrote:
> Submission-Type: new
> Site: twitchdarkbot.com

Hi,

I was checking some things in the Debian mirror universe and noticed
a problem with your mirror:

o we recommend mirrors not sync directly from service aliases such as
  ftp..debian.org (only http is guaranteed to be available at
  ftp..d.o sites).  Maybe change your config to sync from
  the site currently backing the ftp..debian.org service you sync
  from?

Thanks for mirroring Debian.

Cheers,
Julien

Bug#973285: freecad ftbfs with python3.9

[Tobias Frost]

> > 
> 
> Discussed upstream and possibly patch available: 
> https://forum.freecadweb.org/viewtopic.php?f=10=47348
> 
This was possibly a red herring only. sorry for the noise…

Bug#973416: mirror submission for uk.mirrors.clouvider.net

[Julien Cristau]

Control: tag -1 moreinfo

Hi,

I was checking some things in the Debian mirror universe and noticed
a problem with your mirror:

o we recommend mirrors not sync directly from service aliases such as
  ftp..debian.org (only http is guaranteed to be available at
  ftp..d.o sites).  Maybe change your config to sync from
  the site currently backing the ftp..debian.org service you sync
  from?

Cheers,
Julien

On Fri, Oct 30, 2020 at 11:19:22AM +, Maciej Kupiec wrote:
> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: uk.mirrors.clouvider.net
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> Maintainer: Maciej Kupiec 
> Country: GB United Kingdom
> Location: London
> Sponsor: Clouvider https://www.clouvider.co.uk
> Comment: Hello,
>  I'm Maciej from Clouvider Limited. We've setup 6 debian mirrors in:
>  London, UK
>  Amsterdam, NL
>  Frankfurt, DE
>  New York, US
>  Atlanta, US
>  Los Angeles, US
>  
>  All of them got 10gb/s connection.
>  
>  Kind regards,
>  Maciej Kupiec
> 
> 
> 
> 
> Trace Url: http://uk.mirrors.clouvider.net/debian/project/trace/
> Trace Url: 
> http://uk.mirrors.clouvider.net/debian/project/trace/ftp-master.debian.org
> Trace Url: 
> http://uk.mirrors.clouvider.net/debian/project/trace/uk.mirrors.clouvider.net
> 

Bug#975271: UnicodeDecodeError: 'utf-8' codec can't decode byte 0x89 in position 659: invalid start byte

[Davide Prina]

Package: piglit
Version: 0~git20200212-f4710c51b-1
Severity: normal
X-Debbugs-Cc: davide.pr...@gmail.com

Hi,

$ piglit run sanity results/sanity
Traceback (most recent call last):
  File "/usr/bin/piglit", line 178, in 
main()
  File "/usr/bin/piglit", line 174, in main
sys.exit(runner(args))
  File "/usr/lib/x86_64-linux-gnu/piglit/framework/exceptions.py", line 52, in 
_inner
func(*args, **kwargs)
  File "/usr/lib/x86_64-linux-gnu/piglit/framework/programs/run.py", line 362, 
in run
backend.initialize(_create_metadata(
  File "/usr/lib/x86_64-linux-gnu/piglit/framework/programs/run.py", line 268, 
in _create_metadata
metadata['info']['system'] = core.collect_system_info()
  File "/usr/lib/x86_64-linux-gnu/piglit/framework/core.py", line 182, in 
collect_system_info
result[name] = out.decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x89 in position 659: 
invalid start byte


I try to find the invalid character (I have modified the
/usr/lib/x86_64-linux-gnu/piglit/framework/core.py to print all the out
to a file; but I report here the output before those modifications)
and I found that clinfo print a line with strange characters,
characters that you don't see if you call clinfo from the command line,
but you can see if you redirect the clinfo output to a file:
  clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...)   P�|�%V

I look with and hex editor and I found that the string is

20 50 AD 7C EC 25 56 0A 20

This is a very strange output for clinfo, but I think that piglit will
need to work correctly

Ciao
Davide


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

Kernel: Linux 5.9.1-dp-20201024 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages piglit depends on:
ii  libc62.31-4
ii  libegl1  1.3.2-1
ii  libgcc-s110.2.0-16
ii  libgl1   1.3.2-1
ii  libstdc++6   10.2.0-16
ii  libwaffle-1-01.6.1-3
ii  libx11-6 2:1.6.12-1
ii  ocl-icd-libopencl1 [libopencl1]  2.2.13-1
ii  python3  3.8.6-1
ii  python3-mako 1.1.3+ds1-1
ii  python3-six  1.15.0-2

Versions of packages piglit recommends:
ii  waffle-utils  1.6.1-3

piglit suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/x86_64-linux-gnu/piglit/framework/core.py (from 
piglit package)

Bug#972903: buster-pu: package node-pathval/1.1.0-3+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2020-10-26 at 04:49 +0100, Xavier Guimard wrote:
> node-pathval is vulnerable to a prototype pollution (CVE-2020-7751,
> #972895)
> 

Please go ahead.

Regards,

Adam

Bug#974218: node-requirejs: Please embed typescript definitions

[Xavier]

Le 19/11/2020 à 15:21, Georges Khaznadar a écrit :
> Dear Xavier,
> 
> please feel free to adopt completely the package requirejs, you are
> most welcome!
> 
> I took the responsability of this package seven year ago,  when it was not
> maintained, and was a dependency to build the package jsxgraph, which
> I pushed.
> 
> I am not at ease with javascript packages, so requirejs will be much
> better maintained if you take it under your umbrella.
> 
> Best regards, Georges.

Thanks!

Indeed, the upstream source is totally out of node standards ! Not the
good one to learn JS packaging ;-)

I prepared a new package (https://salsa.debian.org/js-team/requirejs)
with typescript types embedded in it. I'll upload it with a new
node-typescript-types after current migration.

Cheers,
Xavier

> Xavier a écrit :
>> Le 14/11/2020 à 12:14, László Böszörményi (GCS) a écrit :
>>> Hi,
>>>
>>> On Wed, Nov 11, 2020 at 2:39 PM Xavier Guimard  wrote:
 Package: node-requirejs
>>> [...]
 to avoid version conflicts, JS team decided to remove typescript
 definitions (node-typescript-types) and embed them directly in the
 relevant packages.

 node-requirejs isn't under JS Team umbrella, so we can't do it for
 @types/requirejs. But we need to synchronize this work (needs to
 repack node-typescript-types and add a "Breaks" in your package).
 Could you do it or give us its maintenance?
>>>  If you ask me, feel free to take over. But please note that recent
>>> uploads are done by Georges. You should get his permission first as
>>> well.
>>>
>>> Regards,
>>> Laszlo/GCS
>>
>> Hi Georges,
>>
>> do you agree ?

Bug#963392: [Help] r-cran-bayestestr: autopkgtest regression

[Andreas Tille]

Control: tags 972074 pending
Control: block 972074 by 963392

On Thu, Nov 19, 2020 at 07:53:06AM -0600, Dirk Eddelbuettel wrote:
> | 
> | I do not have the slightest idea what this might mean.
> 
> ABI/API slippage in the stack. An interface changed but a package didn't 
> recompile.

It seems it is caused by r-cran-rstanarm which in turn has a test
suite issue itself:

...
g++ -std=gnu++14 -shared -L/usr/lib/R/lib -Wl,-z,relro -o sourceCpp_2.so 
file8f23649f86.o /usr/lib/R/site-library/rstan/lib/libStanServices.a 
-L/usr/lib/R/site-library/StanHeaders// -lStanHeaders 
-L/usr/lib/R/site-library/RcppParallel// -ltbb -L/usr/lib/R/lib -lR
/usr/bin/ld: cannot find -lStanHeaders
collect2: error: ld returned 1 exit status
make: *** [/usr/share/R/share/make/shlib.mk:10: sourceCpp_2.so] Error 1
── ERROR (test_stan_functions.R:70:1): (code run outside of `test_that()`) ─
Error: $ operator is invalid for atomic vectors
Backtrace:
█
 1. └─rstan::expose_stan_functions(stanc_ret, rebuild = TRUE, verbose = TRUE) 
test_stan_functions.R:70:0

══ testthat results  ═══
ERROR (test_stan_functions.R:70:1): (code run outside of `test_that()`)

[ FAIL 1 | WARN 0 | SKIP 0 | PASS 1 ]
Error: Test failures
Execution halted


This is actually the reason why r-cran-rstanarm 2.21.1 is in Git for
several weeks but not uploaded yet.
 
> | If nobody has any clue we should probably ask upstream about this.
> 
> That risks making you look foolish as upstream is (once again) 100% clean at
> CRAN which is (to a first approximation) the only measure a CRAN author cares
> about.  Copied and pasted from the results page [1] and lightly edited for
> column alignment:

We do not test the code provided by somebody else but what we package
for Debian.  You know we are sometimes replacing code copies you are
yourself maintaining r-cran-bh which is something else than what is
running on CRAN.  Thus I think its a sensible approach to test what we
package.
 
> CRAN Package Check Results for Package bayestestR
> Last updated on 2020-11-19 13:50:51 CET.
> 
> FlavorVersion TinstallTcheck  Ttotal  Status  Flags
> r-devel-linux-x86_64-debian-clang 0.7.5   12.67   406.54  419.21  OK  
> r-devel-linux-x86_64-debian-gcc   0.7.5   8.37295.67  304.04  
> OK  
> r-devel-linux-x86_64-fedora-clang 0.7.5   498.86  OK  
> r-devel-linux-x86_64-fedora-gcc   0.7.5   487.49  
> OK  
> r-devel-windows-ix86+x86_64   0.7.5   16.00   636.00  652.00  OK  
> r-patched-linux-x86_640.7.5   12.72   388.61  401.33  
> OK  
> r-patched-solaris-x86 0.7.5   725.40  OK  
> r-release-linux-x86_640.7.5   12.04   390.98  403.02  
> OK  
> r-release-macos-x86_640.7.5   
> OK  
> r-release-windows-ix86+x86_64 0.7.5   13.00   652.00  665.00  OK  
> r-oldrel-macos-x86_64 0.7.5   OK  
> r-oldrel-windows-ix86+x86_64  0.7.5   11.00   500.00  511.00  OK

Not sure what information this table should provide to us.  The fact
that things are running on those other systems is great but does not
answer why it is not running for us. 
 
> 'OK' on every platform is as clean as it gets. It is an ambitious package
> with a lot of Suggests. If you insist on loading all Suggests (which are,
> after all, optional) then you simply have to make sure they are all
> current. CRAN does that.  If you want to autotest you need to as well.

In most cases the error log was verbose about what is missing or what
is not current.  My try with the latest r-cran-rstanarm (that fails its
own test) shows that this is probably the cause for the test issue.

Kind regards

 Andreas.
 
> [1] https://cran.r-project.org/web/checks/check_results_bayestestR.html

-- 
http://fam-tille.de

Bug#975059: mirror listing update for repo.ifca.es

[Julien Cristau]

Control: tag -1 moreinfo

On Wed, Nov 18, 2020 at 02:20:31PM +, Alvaro Lopez Garcia wrote:
> Submission-Type: update
> Site: repo.ifca.es

Hi,

I was checking some things before inclusion and noticed a problem with
your mirror:

o we recommend mirrors not sync directly from service aliases such as
  ftp..debian.org (only http is guaranteed to be available at
  ftp..d.o sites).  Maybe change your config to sync from
  the site currently backing the ftp..debian.org service you sync
  from?

Thanks,
Julien

Bug#971515: Status as of last tech-ctte meeting

[Shengjing Zhu]

On Wed, Nov 18, 2020 at 10:26:21AM -0800, Russ Allbery wrote:
> 
> I maintain a bunch of Kubernetes clusters as part of my job.  Those
> clusters are run by other people (cloud providers, data centers, etc.).  I
> need clients to talk to those clusters.  When I first started working with
> Kubernetes, I realized I needed a client, worried about how much of a pain
> that would be, did an apt-cache search for kubernetes, found
> kubernetes-client, breathed a sigh of relief, and ran apt install
> kubernetes-client.  I have subsequently not given Kubernetes clients a
> second thought.
> 

In priciple, the kubectl compatibility matrix says it only supports one minor
version (older or newer). When you working with many clusters, the cluster
version may not be compatible with the kubectl version in Debian stable.

PS, in practice, the basic function of kubectl doesn't change much, and new
kubectl with old cluster seems to work.

As a user of upstream kubectl package user, I'm quite happy with it. I can
always install the latest, or any old version. They keep all old versions in
their apt repo. And with the nature of static link, their repo works well
other parts of the system, regardless I'm running Debian oldstable, stable,
or unstable.

IMO, we should admit that current Debian way doesn't fit well for such
softwares.


signature.asc
Description: PGP signature

Bug#975086: buster-pu: package dav4tbsync

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Wed, 2020-11-18 at 20:59 +0100, Mechtilde Stehmann wrote:
> Description: this package contains a fix to be compatible with
> thunderbird 78.x
> 
> It is a follow up to bug #0775020.

This appears to be missing a debdiff. (and I assume that bug number is
typoed.)

Regards,

Adam

Bug#973741: [Pkg-javascript-devel] Bug#973741: gitlab: Yarn hasn't been able to find a cache folder it can use

[Pirate Praveen]

On Thu, Nov 19, 2020 at 18:58, Xavier  wrote:

we opened bugs to upstream repo and are waiting for...


I don't think upstream will make any significant changes to 1.x branch 
any more. Someone who want to see yarn in debian bullseye will have to 
fix it.

Bug#975259: xcb-util: Please update to ≥ 0.3.9

[Dmitry Shachnev]

Source: xcb-util
Version: 0.3.8-3

Dear maintainers,

Debian currently ships xcb-util 0.3.8.

The new version of Qt (5.15.2) needs xcb-util ≥ 0.3.9 [1]. The latest
upstream version is 0.4.0, released in 2014. Please update to one of
those versions.

See [2] or [3] for the list of releases.

[1]: https://codereview.qt-project.org/c/qt/qtbase/+/313028
[2]: https://xcb.freedesktop.org/dist/
[3]: https://gitlab.freedesktop.org/xorg/lib/libxcb-util/-/tags

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#975261: diffoscope: install footprint is 2.6GB, please move some recommends to suggests

[Ximin Luo]

Package: diffoscope
Version: 161
Severity: important
File: diffoscope

Dear Maintainer,

The size of diffoscope is getting really quite ridiculous, all the recommends
now come to ~2.6 GB installed size, even though they are not used in the vast
majority of use cases. Not only is the disk space wasted, the extra packages
causes APT maintenance headaches when upgrading, it often wants to install
random extra dependencies not necessarily caused by diffoscope itself, but an
upgrade to one of its recommends.

Sometimes the grandchildren provides of the child recommends interact badly,
for example on my system installing diffoscope wants to install evince and
gnome3-desktop-data for some reason, even though I already have another PDF
viewer installed.

Debian Policy says:
"Recommends: This declares a strong, but not absolute, dependency."

and that is why apt-get installs these by default. However most of the current
Recommends are for rare use cases. Furthermore diffoscope already has very
nice run-time logic to detect when a needed program is not installed, and
tells you to install it.

I have managed to figure out that by moving the following Recommends to
Suggests one can cut the footprint from 2.6GB to about 64MB which is much more
reasonable. Therefore please do that. These are ordered roughly by size:

- ghc - 800MB
- ocaml-nox - 460MB
- llvm - 330MB
- fp-utils - 320MB
- default-jdk-headless | default-jdk | java-sdk - 240MB for default-jdk-headless
- python3-guestfs - 150MB
- python3-binwalk - 140MB
- gnumeric - 85MB
- apktool - 50MB
- mono-utils - 30MB
- radare2 - 30MB
- xmlbeans - 20MB
- ovmf - 14MB

This will make it much easier to keep having diffoscope on a system across
multiple system upgrades.

X

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

Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#975262: ITP: ruby-png-quantizator -- Small wrapper around pngquant

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

Packaging of https://rubygems.org/gems/png_quantizator

autopkgtest dependency of gitlab

Bug#975263: RM: py-asterisk -- RoQA; unmaintained, RC-buggy, no rdeps

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove py-asterisk. The last maintainer upload was in 2014, there are no 
reverse deps,
it depends on Python 2 and has been dropped from testing for almost a year now.

Cheers,
Moritz

Bug#975264: RM: oidua -- RoQA; Dead upstream, unmaintained, RC-buggy

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove oidua. It's dead upstream, depends on Python 2 (dropped from 
testing
for almost a year) and the last maintainer upload was in 2016 (without any 
followup
to the RC bugs)

Cheers,
Moritz

Bug#975208: Bug#975210: Bug#975214: Bug#975210: libowl-directsemantics-perl: FTBFS: test failed

[Jonas Smedegaard]

Quoting gregor herrmann (2020-11-19 18:40:21)
> On Thu, 19 Nov 2020 12:28:53 +0100, gregor herrmann wrote:
> 
> > So this might be more of a problem in the recently updated 
> > libtype-tiny-perl (with or without involvement of perl 5.32, as 
> > Scalar::Util is dual-lifed).
> 
> As noted by Niko on IRC, the actual problem seems to be an ancient 
> Scalar::Util in inc/.
> 
> Now a proper fix would probably be to (convert to package from cdbs to 
> debhelper and) move inc/ away and back in d/rules (like we do for 
> other packages) and build-depend on the vendored modules; a 
> quick fix, tested with librdf-closure-perl, seems to work:
> 
> #v+
> --- a/debian/rules
> +++ b/debian/rules
> @@ -47,3 +47,6 @@ CDBS_BUILD_DEPENDS +=, $(deps), $(deps-test)
>  CDBS_DEPENDS_$(pkg) = $(deps)
> 
>  DEB_INSTALL_EXAMPLES_$(pkg) = examples/*
> +
> +clean::
> +   $(RM) -rv $(CURDIR)/inc/Scalar
> #v-

Thanks for the analysis, Niko and Gregor.

I hope to find time later tonight or tomorrow to convert these packages 
to use short-form dh sequencer.

Can you point to specific examples of packages vendoring Scalar::Util 
for me to learn from, Gregor?


 - 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#963392: [Help] r-cran-bayestestr: autopkgtest regression

[Dirk Eddelbuettel]

On 19 November 2020 at 19:07, Andreas Tille wrote:
| Control: tags 972074 pending
| Control: block 972074 by 963392
| 
| On Thu, Nov 19, 2020 at 07:53:06AM -0600, Dirk Eddelbuettel wrote:
| > | 
| > | I do not have the slightest idea what this might mean.
| > 
| > ABI/API slippage in the stack. An interface changed but a package didn't 
recompile.
| 
| It seems it is caused by r-cran-rstanarm which in turn has a test
| suite issue itself:

[...]

| > CRAN Package Check Results for Package bayestestR
| > Last updated on 2020-11-19 13:50:51 CET.
| > 
| > Flavor  Version TinstallTcheck  Ttotal  Status  Flags
| > r-devel-linux-x86_64-debian-clang   0.7.5   12.67   406.54  419.21  OK  
| > r-devel-linux-x86_64-debian-gcc 0.7.5   8.37295.67  304.04  
OK  
| > r-devel-linux-x86_64-fedora-clang   0.7.5   498.86  OK  
| > r-devel-linux-x86_64-fedora-gcc 0.7.5   487.49  
OK  
| > r-devel-windows-ix86+x86_64 0.7.5   16.00   636.00  652.00  OK  
| > r-patched-linux-x86_64  0.7.5   12.72   388.61  401.33  
OK  
| > r-patched-solaris-x86   0.7.5   725.40  
OK  
| > r-release-linux-x86_64  0.7.5   12.04   390.98  403.02  
OK  
| > r-release-macos-x86_64  0.7.5   
OK  
| > r-release-windows-ix86+x86_64   0.7.5   13.00   652.00  665.00  
OK  
| > r-oldrel-macos-x86_64   0.7.5   
OK  
| > r-oldrel-windows-ix86+x86_640.7.5   11.00   500.00  511.00  
OK
| 
| Not sure what information this table should provide to us.  The fact

It makes it fairly obvious that you should not contact upstream -- because
there is no issue in the upstream code.

| that things are running on those other systems is great but does not
| answer why it is not running for us. 

Exactly. It's most-likely a self-inflicted wound.  

FWIW I see that myself too when I do reverse depenency tests for Rcpp or
related packages. rstanarm is a complicated package. You could consider not
installing it for the autopkgtests for this package.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#975208: Bug#975210: Bug#975214: Bug#975210: libowl-directsemantics-perl: FTBFS: test failed

[gregor herrmann]

On Thu, 19 Nov 2020 19:57:31 +0100, Jonas Smedegaard wrote:

> Can you point to specific examples of packages vendoring Scalar::Util 
> for me to learn from, Gregor?

Not sure if we have packages with specifically inc/Scalar/Util
but a general recipe, used in lots of packages, is at

https://perl-team.pages.debian.net/policy.html#Embedded_third-party_modules_in_inc%2F

and should work for this case as well.

(Summary: move inc/ away before dh_auto_configure and back after
dh_auto_clean.)


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: Status Quo: Something About You Baby I Lik


signature.asc
Description: Digital Signature

Bug#975267: freecad: FTBFS against boost_1.74

[Anton Gladky]

Package: freecad
Version: 0.18.4+dfsg2-5
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

[ 55%] Building CXX object 
src/Gui/CMakeFiles/FreeCADGui.dir/DAGView/DAGRectItem.cpp.o
cd /<>/debian/build-py3/src/Gui && /usr/bin/c++ -DBOOST_ALL_NO_LIB 
-DBOOST_ATOMIC_DYN_LINK -DBOOST_FILESYSTEM_DYN_LINK 
-DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_REGEX_DYN_LINK -DBOOST_SYSTEM_DYN_LINK 
-DBOOST_THREAD_DYN_LINK -DBUILD_ADDONMGR -DCMAKE_BUILD_TYPE=\"RelWithDebInfo\" 
-DFreeCADGui_EXPORTS -DHAVE_CONFIG_H -DQT_CORE_LIB -DQT_GUI_LIB 
-DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_PRINTSUPPORT_LIB 
-DQT_SVG_LIB -DQT_UITOOLS_LIB -DQT_WIDGETS_LIB -DQT_X11EXTRAS_LIB -DQT_XML_LIB 
-DSPNAV_FOUND -D_OCC64 -I/<>/debian/build-py3 
-I/<>/debian/build-py3/src -I/<>/src 
-I/<>/src/Gui -I/<>/src/Gui/Quarter 
-I/<>/debian/build-py3/src/Gui -I/<>/src/Gui/.. 
-I/<>/debian/build-py3/src/Gui/.. 
-I/<>/debian/build-py3/src/Gui/Language 
-I/<>/debian/build-py3/src/Gui/propertyeditor 
-I/<>/debian/build-py3/src/Gui/TaskView 
-I/<>/debian/build-py3/src/Gui/Quarter 
-I/<>/debian/build-py3/src/Gui/DAGView -I/usr/include/eigen3 
-I/usr/include/python3.8 -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtOpenGL -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtSvg -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtUiTools -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtX11Extras -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtXml -Wall -Wextra -Wno-write-strings -Wall 
-DHAVE_SWIG=1 -fpermissive -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=c++11 -D_OCC64 -O2 -g -DNDEBUG -fPIC -pthread 
-I/usr/include/hdf5/openmpi -I/usr/lib/x86_64-linux-gnu/openmpi/include 
-I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -fPIC -o 
CMakeFiles/FreeCADGui.dir/DAGView/DAGRectItem.cpp.o -c 
/<>/src/Gui/DAGView/DAGRectItem.cpp
/<>/src/Gui/DAGView/DAGView.cpp: In constructor 
‘Gui::DAG::View::View(QWidget*)’:
/<>/src/Gui/DAGView/DAGView.cpp:55:100: error: ‘_1’ was not 
declared in this scope
   55 |   
Application::Instance->signalActiveDocument.connect(boost::bind(::slotActiveDocument,
 this, _1));

It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/freecad_0.18.4+dfsg2-5_unstable_boost.log

Best regards

Anton

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+2w44RHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wYJ6A//TtEh7bUmrOuoqRkEDlzjcdKlem+QHEt8
F4R53dGULzAZ37aYX5leTEK8dgc0Hu2gSlOaFJD7IltfvSPM3FOoa2hdWGVboBaF
6oeY17VxtKUr3vLi+rt7Tkb29ta/iuTXm1FB+pj2FhmzwjuG1LQ7c4mVNrFHF1Fu
cArzsdF0y9D9t2ulWMw6Dc3i2VYAMlVIweUev1b3dy+qEzUX+262wwOsPGipA6zf
qPBJrZjMaolqIUjISXirux2KfWwUBQ78XJKhPUM3XfIYxi4ePiB2yu3UhrSANsUg
Kj9bE/ITW3tpLjTzCliFwElNdXMhT/PihxTRshaSGyvc9ff97Bfv2QqoguhQIQtj
zxpY3330gRTfCu+LcMHk0KNNUmA5/dxNvbVFhsAbtwbXgvfD52l5v0V3UDmyalZO
UE/fwuwrzfKNWTNLOAfuY4ANUSN88oNoO2ijUiMGI0zUriW1FXGcVhyhKXApuGEB
uKxWHx4uqV23l1tDmFJq67lqC3+/VNcpADthw9p2phy7LILdgRDAeEckUCRTRLp+
yIREdDPWcUYrYM5CEIri21pRkSqHiXGnVIG6w2VjTRvx1eNuAp6DtecGP2VZLzXm
OFkI2iF8LucyjhpPX+DTTLa0vrFPygP3L+y62MPlXOEJGxPGK5DulkO7Uh2ULFzE
ZauSByO74pw=
=bYr7
-END PGP SIGNATURE-

Bug#972115: sqlite3 3.27.2-3+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 972115 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: sqlite3
Version: 3.27.2-3+deb10u1

Explanation: fix division by zero [CVE-2019-16168], NULL pointer dereference 
[CVE-2019-19923], mishandling of NULL pathname during an update of a ZIP 
archive [CVE-2019-19925], mishandling of embedded NULs in filenames 
[CVE-2019-19959], possible crash with stacking unwinding [CVE-2019-20218], 
integer overflow [CVE-2020-13434], segmentation fault [CVE-2020-13435], 
use-after-free issue [CVE-2020-13630], NULL pointer dereference 
[CVE-2020-13632], heap overflow [CVE-2020-15358]

Bug#972351: ros-ros-comm 1.14.3+ds1-5+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 972351 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: ros-ros-comm
Version: 1.14.3+ds1-5+deb10u2

Explanation: fix integer overflow [CVE-2020-16124]

Bug#972839: systemd 241-7~deb10u5 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 972839 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: systemd
Version: 241-7~deb10u5

Explanation: basic/cap-list: parse/print numerical capabilities; recognise new 
capabilities from Linux kernel 5.8; networkd: do not generate MAC for bridge 
device

Bug#972814: pcaudiolib 1.1-3+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 972814 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: pcaudiolib
Version: 1.1-3+deb10u1

Explanation: cap cancellation latency to 10ms

Bug#975258: ITP: r-bioc-oligoclasses -- Classes for high-throughput arrays supported by oligo and crlmm

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-oligoclasses -- Classes for high-throughput arrays 
supported by oligo and crlmm
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-oligoclasses
  Version : 1.52.0
  Upstream Author : Benilton Carvalho
* URL : https://bioconductor.org/packages/oligoClasses/
* License : GPL-2+
  Programming Lang: GNU R
  Description : Classes for high-throughput arrays supported by oligo and 
crlmm
 This package contains class definitions, validity checks, and
 initialization methods for classes used by the oligo and crlmm packages.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-oligoclasses

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Sean Whitton]

Hello,

On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:

> I'd also like to address one other issue here. It would be easy to
> hypothesize, at this point, that some additional communication (or more
> verbose communication) from the maintainer might have helped here.
> However, I would express doubt that any more verbose version of "no"
> (e.g. a long-form explanation about undesired additional maintenance
> burden) would have led to any less escalation. I think the situation
> would still have ended up here, no matter how much time or energy was
> expended in writing responses.
>
> That seems particularly likely given the adversarial NMU directly
> attempting to override an active package maintainer's decision, which
> escalated the situation further. (Such adversarial NMUs have occurred in
> regard to alternative init support in the past, as well.) And I don't
> think anyone can reasonably suggest that they thought the change was
> made unintentionally (given that it was explicitly mentioned in the
> changelog), which makes the NMU a rather hostile escalation.
>
> I would ask anyone on the TC who feels that more verbose answers were
> desirable whether they think a more verbose answer would have had any
> effect on the outcome or subsequent escalations.

Assuming for a moment that the TC does not decline to rule, it is going
to be very hard for us to make a good decision if we lack more detailed
input from the package maintainer.

We can speculate as to whether the dispute would have proceeded better
or worse with more verbose messages from Michael before now, but it
would be beside the point.

-- 
Sean Whitton

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Sean Whitton]

Hello,

On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:

> I'd also like to address one other issue here. It would be easy to
> hypothesize, at this point, that some additional communication (or more
> verbose communication) from the maintainer might have helped here.
> However, I would express doubt that any more verbose version of "no"
> (e.g. a long-form explanation about undesired additional maintenance
> burden) would have led to any less escalation. I think the situation
> would still have ended up here, no matter how much time or energy was
> expended in writing responses.
>
> That seems particularly likely given the adversarial NMU directly
> attempting to override an active package maintainer's decision, which
> escalated the situation further. (Such adversarial NMUs have occurred in
> regard to alternative init support in the past, as well.) And I don't
> think anyone can reasonably suggest that they thought the change was
> made unintentionally (given that it was explicitly mentioned in the
> changelog), which makes the NMU a rather hostile escalation.
>
> I would ask anyone on the TC who feels that more verbose answers were
> desirable whether they think a more verbose answer would have had any
> effect on the outcome or subsequent escalations.

Assuming for a moment that the TC does not decline to rule, it is going
to be very hard for us to make a good decision if we lack more detailed
input from the package maintainer.

We can speculate as to whether the dispute would have proceeded better
or worse with more verbose messages from Michael before now, but it
would be beside the point.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#975265: CVE-2020-27616

[Moritz Muehlenhoff]

Package: qemu
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2020-27616:
https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg06080.h
https://www.openwall.com/lists/oss-security/2020/11/03/2

Cheers,
Moritz

Bug#975250: clarify gathering together of copyright information

[Russ Allbery]

Marc Haber  writes:

> But what if file A says

> |  Copyright 2008 John Smith
> |  Copyright 2005-2015 Angela Watts

> and file B has:

> |  Copyright 2010 Angela Watts

> Can this be gathered together to:

> |  Copyright 2008 John Smith
> |  Copyright 2005-2015 Angela Watts

I'm fairly sure the answer in practice is yes.  I've been uploading
packages like this for some time without any issues, and I would be very
surprised if ftp-master would object.

I think we may need to be a bit more verbose in explaining how copyright
statements can be coalesced to make this clear.  Some GNU projects use
wording like this:

   For any copyright year range specified as - in this file, the
   range specifies every single year in that closed interval.

and maybe we should import something like that into our specification as
well as say explicitly that you're allowed to coalesce copyright
statements from multiple files into a single copyright notice as long as
all of the listed authors and years are covered.

-- 
Russ Allbery (r...@debian.org)  

Bug#949111: Qemu soundhw hda is broken

[bakhelit]

I can confirm that the "-soundhw hda" option is still broken in 
3.1+dfsg-8+deb10u8. When playing a movie or a song with VLC Media Player 
inside a guest (running Debian 10) one can hear very short bits of audio 
from time to time as Teran McKinney describes.


Also, when I open Pulse Audio Volume Control in my host Debian 10 
system, I can see in the "Playback" tab that the stream for QEMU very 
frequently appears and disappears - as if it was activated and 
immediately deactivated in some kind of broken loop. This is why one can 
probably hear those short bits of audio from the guest (= when the 
stream is active it all works). The GUI monitoring for PulseAudio used 
in my test is provided by "pavucontrol" package in Debian.


Regards
Bakhelit

Bug#973706: buster-pu: package lttng-modules/2.10.8-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2020-11-03 at 11:51 -0500, Michael Jeanson wrote:
> The attached diff fixes a build failure of the dkms modules on the
> 4.19.0-11 buster linux kernel. This was reported at:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972321
> 

Please go ahead.

Regards,

Adam

Bug#973917: buster-pu: package tcpdump/4.9.3-1~deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2020-11-07 at 12:45 +, Romain Francoise wrote:
> I am seeking permission to upload a new version of tcpdump to
> stable-proposed-updates to address CVE-2020-8037 (bug #973877).
> 

Please go ahead.

Regards,

Adam

Bug#974739: gnome-passwordsafe: Gnome-passwordsafe fails to open

[il]

You are right. I completely forgot about that old pykeepass installation with 
pip.
pip uninstall pykeepass solved the problem. Gnome-passwordsafe works very well 
now.
My apologies for the confusion and thank you very much.


On Sat, 14 Nov 2020 19:38:30 +0100 Henry-Nicolas Tourneur  
wrote:
> Thanks for the bug report.
> 
> From the stack trace you provided, it appears that you are not using the 
> Debian
> distributed release of pykeepass but something installed from elsewhere (I
> presume via pip). See this line: the path is local for user "il" not the 
> system
> path which should be /usr/lib/python3/dist-packages/pykeepass
> 
> from pykeepass.exceptions import (
> ImportError: cannot import name 'CredentialsError' from 'pykeepass.exceptions'
> (/home/il/.local/lib/python3.8/site-packages/pykeepass/exceptions.py)
> 
> 
> There has been an unexpected change in the release 3.2.1 of pykeepass that
> introduced some new exceptions. The version of gnome-passwordsafe packaged in
> Debian requires on pykeepass >= 3.2.1 so that those exceptions exists.
> 
> I presume your locally installed version of pykeepass is older than 3.2.1.
> Can you please make sure that you are using the Debian package for pykeepass 
> and
> let me know if this problem persists?
> 
> Best regards,
> 
> 
> -- 
> Henry-Nicolas Tourneur
> mxid: @hntourne:matrix.nilux.be
> 
> 
> 

Bug#960906: shiny-server -- put Shiny web apps online

[Shayan Doust]

Hello Andreas,

As of now, there still stands a single dependency called [node-http-proxy].

Unfortunately, it looks like it relies on socket.io, which has not been packaged
yet.

Kind regards,
Shayan Doust



[node-http-proxy]: https://salsa.debian.org/js-team/node-http-proxy/


OpenPGP_0x6D7D441919D02395.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#972126: libopendbx: Please remove support for long-unmaintained sqlite 2

[Moritz Mühlenhoff]

severity 972126 serious
thanks

On Mon, Oct 12, 2020 at 11:35:23PM +0100, Simon McVittie wrote:
> Package: libopendbx1-sqlite
> Version: 1.4.6-14
> Severity: important
> Tags: bullseye sid
> User: debian...@lists.debian.org
> Usertags: libsqlite0
> Control: block 607969 by -1
> 
> libopendbx builds a libopendbx1-sqlite binary package. This is a wrapper
> for sqlite 2, which was superseded in 2004 and is planned to be removed
> (see #607969), and nothing in Debian seems to depend on it. Please remove
> the libopendbx1-sqlite binary package.
> 
> This bug is currently non-RC, but is very likely to become RC soon.

libopendbx is now the only reverse dependency blocking the removal
of sqlite, bumping to RC.

Cheers,
Moritz

Bug#975183: rsyslog: FTBFS: configure: error: Package requirements (libczmq >= 4.0.0) were not met

[Michael Biebl]

Am Donnerstag, den 19.11.2020, 18:00 +0100 schrieb László Böszörményi
(GCS):
> Version: 4.3.3-4
> 
> On Thu, Nov 19, 2020 at 1:27 PM Michael Biebl 
> wrote:
> > Am Donnerstag, den 19.11.2020, 10:45 +0100 schrieb Lucas Nussbaum:
> > > 
> > > > checking for libczmq >= 4.0.0... no
> > > > configure: error: Package requirements (libczmq >= 4.0.0) were
> > > > not
> > > > met
> > > > 
> > > > Package 'libbsd', required by 'libzmq', not found
> > It's a bug in libzmq3-dev, which lists libbsd as a dependency in
> > libczmq.pc.
>  Indeed, I broke it. Fix is uploaded and built on all architectures.
> Sorry for the inconvenience.


No worries and thanks for the quick fix!

Michael


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

Bug#974080: ITP: lua-binaryheap -- Binary heap implementation in lua

[Santiago Ruano Rincón]

El 19/11/20 a las 17:56, Santiago Ruano Rincón escribió:
> El 19/11/20 a las 16:45, Jakub Ružička escribió:
> > On 11/17/20 4:41 PM, Santiago Ruano Rincón wrote:
> > > El 09/11/20 a las 13:31, Jakub Ružička escribió:
> > >> Package: wnpp
> > >> Severity: wishlist
> > >> Owner: Jakub Ružička 
> > >>
> > >> * Package name: lua-binaryheap
> > >>   Version : 0.4
> > >>   Upstream Author : Thijs Schreijer 
> > >> * URL : https://github.com/Tieske/binaryheap.lua
> > >> * License : MIT
> > >>   Programming Lang: lua
> > >>   Description : binary heap implementation in lua
> > >>
> > >> binaryheap.lua is a binary heap (binary tree) implementaion in lua.
> > >>
> > > ...
> > >
> > > Jakub, thanks for packaging lua-binaryheap.
> > Thanks for fast respone, Santiago :)
> > >
> > > Two lintian "major" comments from your current repo:
> > >
> > > W: lua-binaryheap source: ancient-standards-version 3.9.8 (released 
> > > 2016-04-06) (current is 4.5.0)
> > > W: lua-binaryheap source: 
> > > package-uses-deprecated-debhelper-compat-version 9
> > >
> > > Do you have any reason for that standards-version and
> > > debhelper-compat-version?
> > Upstream packages support older distros including ubuntu xenial so it's
> > just a leftover - I've updated these to current.
> > >
> > > These other lintian minor warnings could be easily fixed:
> > >
> > > I: lua-binaryheap: capitalization-error-in-description lua Lua
> > > I: lua-binaryheap source: debian-watch-file-is-missing
> > > I: lua-binaryheap source: vcs-field-not-canonical Vcs-Git
> > >
> > > Could you please consider them?
> > I've fixed all of them except debian-watch-file-is-missing because
> > upstream is using one the weirdest version tag scheme I've witnessed
> > (version_0v4) and I'm not familiar with watch files enough to solve this
> > efficiently.
> 
> Great, thanks!
> I'll upload it later this evening.
...

Before uploading a wanted to take a look at the debian/watch file.
Attached you can find a work-in-progress version. I cannot work more on
it today. There is still an error after downloading the file. Would you
like to fix it?  (c.f. man uscan)

Cheers,

 -- S
version=4
opts="filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/-$1\.tar\.gz/,uversionmangle=s/v/./"
 \
  https://github.com/Tieske/binaryheap.lua/tags .*/version_?(\d\S*)\.tar\.gz


signature.asc
Description: PGP signature

Bug#964512: openzwave-controlpanel: FTBFS with invalid type conversion

[Gianfranco Costamagna]

control: tags -1 patch pending

Uploaded

G.

On Wed, 8 Jul 2020 11:27:57 -0400 Nicolas Mora  wrote:
> Hello,
> 
> On Wed, 08 Jul 2020 11:22:18 +0200 Andreas Beckmann  wrote:
> > 
> > openzwave-controlpanel recently started to FTBFS with
> > 
> 
> libmicrohttpd has recent API changes. The attached patch file should fix
> the ftbfs with libmicrohttpd 0.9.71. It also fixes a gcc warning with
> uninitialized value.
> 
> /Nicolas
diff -Nru openzwave-controlpanel-0.2a+git20161006.a390f35/debian/changelog 
openzwave-controlpanel-0.2a+git20161006.a390f35/debian/changelog
--- openzwave-controlpanel-0.2a+git20161006.a390f35/debian/changelog
2017-08-20 00:32:25.0 +0200
+++ openzwave-controlpanel-0.2a+git20161006.a390f35/debian/changelog
2020-11-19 22:01:52.0 +0100
@@ -1,3 +1,11 @@
+openzwave-controlpanel (0.2a+git20161006.a390f35-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch from Nicolas Mora to fix a build failure with recent 
libmicrohttpd
+Closes: #964512
+
+ -- Gianfranco Costamagna   Thu, 19 Nov 2020 
22:01:52 +0100
+
 openzwave-controlpanel (0.2a+git20161006.a390f35-2) unstable; urgency=medium
 
   * Append CPPFLAGS to CFLAGS to enable FORTIFY hardening.
diff -Nru 
openzwave-controlpanel-0.2a+git20161006.a390f35/debian/patches/0004-mhd.patch 
openzwave-controlpanel-0.2a+git20161006.a390f35/debian/patches/0004-mhd.patch
--- 
openzwave-controlpanel-0.2a+git20161006.a390f35/debian/patches/0004-mhd.patch   
1970-01-01 01:00:00.0 +0100
+++ 
openzwave-controlpanel-0.2a+git20161006.a390f35/debian/patches/0004-mhd.patch   
2020-11-19 22:01:12.0 +0100
@@ -0,0 +1,136 @@
+Index: openzwave-controlpanel-0.2a+git20161006.a390f35/webserver.cpp
+===
+--- openzwave-controlpanel-0.2a+git20161006.a390f35.orig/webserver.cpp
 openzwave-controlpanel-0.2a+git20161006.a390f35/webserver.cpp
+@@ -100,11 +100,11 @@ extern int debug;
+  * web_send_data
+  * Send internal HTML string
+  */
+-static int web_send_data (struct MHD_Connection *connection, const char *data,
++static enum MHD_Result web_send_data (struct MHD_Connection *connection, 
const char *data,
+   const int code, bool free, bool copy, const char *ct)
+ {
+   struct MHD_Response *response;
+-  int ret;
++  enum MHD_Result ret;
+ 
+   if (!copy && ! free)
+   response = MHD_create_response_from_buffer(strlen(data), (void 
*) data, MHD_RESPMEM_PERSISTENT);
+@@ -148,14 +148,14 @@ void web_close_file (void *cls)
+  * web_send_file
+  * Read files and send them out
+  */
+-int web_send_file (struct MHD_Connection *conn, const char *filename, const 
int code, const bool unl)
++enum MHD_Result web_send_file (struct MHD_Connection *conn, const char 
*filename, const int code, const bool unl)
+ {
+   struct stat buf;
+   FILE *fp;
+   struct MHD_Response *response;
+   const char *p;
+   const char *ct = NULL;
+-  int ret;
++  enum MHD_Result ret;
+ 
+   if ((p = strchr(filename, '.')) != NULL) {
+   p++;
+@@ -540,7 +540,7 @@ const char *Webserver::SendSceneResponse
+   char *fn;
+   int cnt;
+   int i;
+-  uint8 sid;
++  uint8 sid = 0;
+   TiXmlDeclaration* decl = new TiXmlDeclaration( "1.0", "utf-8", "" );
+   doc.LinkEndChild(decl);
+   TiXmlElement* scenesElement = new TiXmlElement("scenes");
+@@ -644,7 +644,7 @@ const char *Webserver::SendSceneResponse
+  * Process poll request from client and return
+  * data as xml.
+  */
+-int Webserver::SendPollResponse (struct MHD_Connection *conn)
++enum MHD_Result Webserver::SendPollResponse (struct MHD_Connection *conn)
+ {
+   TiXmlDocument doc;
+   struct stat buf;
+@@ -657,7 +657,7 @@ int Webserver::SendPollResponse (struct
+   char fntemp[32];
+   char *fn;
+   FILE *fp;
+-  int32 ret;
++  enum MHD_Result ret;
+ 
+   TiXmlDeclaration* decl = new TiXmlDeclaration( "1.0", "utf-8", "" );
+   doc.LinkEndChild(decl);
+@@ -811,14 +811,14 @@ int Webserver::SendPollResponse (struct
+  * Process request for Device List from client and return
+  * data as xml.
+  */
+-int Webserver::SendDeviceListResponse (struct MHD_Connection *conn)
++enum MHD_Result Webserver::SendDeviceListResponse (struct MHD_Connection 
*conn)
+ {
+   TiXmlDocument doc;
+   char str[16];
+   int32 i, j;
+   char fntemp[32];
+   char *fn;
+-  int32 ret;
++  enum MHD_Result ret;
+ 
+   TiXmlDeclaration* decl = new TiXmlDeclaration( "1.0", "utf-8", "" );
+   doc.LinkEndChild(decl);
+@@ -981,7 +981,7 @@ void web_controller_update (Driver::Cont
+  * Handle the post of the updated data
+  */
+ 
+-int web_config_post (void *cls, enum MHD_ValueKind kind, const char *key, 
const char *filename,
++enum MHD_Result web_config_post (void *cls, enum MHD_ValueKind kind, const 
char *key, const char *filename,
+   const char *content_type, 

Bug#975256: brutefir: Wrong homepage

[Davide Prina]

Package: brutefir
Version: 1.0o-2
Severity: normal

I have see that the homepage
http://www.ludd.luth.se/~torger/brutefir.html
do not respond anymore

I think that the new homepage is:
https://torger.se/anders/brutefir.html

Ciao
Davide

Bug#968283: closed by Tobias Frost (Re: Bug#968204: Removal of packges which depend on GTK2)

[Matthew Wakeling]

On Thu, 19 Nov 2020, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the jack package:

#968283: jack: Freedb has closed. Use gnudb instead.

It has been closed by Tobias Frost .


If jack has been removed from Debian, is there a recommended alternative? 
Was it removed because of a better alternative, or lack of development?


Many thanks,

Matthew

Bug#975257: libtool needs to be updated for darwin20 / MACOSX_DEPLOYMENT_TARGET=11.0

[Vincent Lefevre]

Package: libtool
Version: 2.4.6-14
Severity: important
Tags: upstream
Forwarded: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44605

Hi,

The libtool.m4 file (at least) is obsolete for darwin20 / 
MACOSX_DEPLOYMENT_TARGET=11.0

This is known to affect GCC:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865

Upstream bugs:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44605
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44684

-- 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.9.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libtool depends on:
ii  autotools-dev   20180224.1
ii  clang-10 [c-compiler]   1:10.0.1-8
ii  clang-3.5 [c-compiler]  1:3.5.2-5
ii  clang-3.6 [c-compiler]  1:3.6.2-4
ii  clang-3.7 [c-compiler]  1:3.7.1-3+b2
ii  clang-7 [c-compiler]1:7.0.1-12
ii  clang-8 [c-compiler]1:8.0.1-10+b1
ii  clang-9 [c-compiler]1:9.0.1-15
ii  cpp 4:10.2.0-1
ii  file1:5.38-5+local2
ii  gcc [c-compiler]4:10.2.0-1
ii  gcc-10 [c-compiler] 10.2.0-17
ii  gcc-4.6 [c-compiler]4.6.4-7
ii  gcc-4.8 [c-compiler]4.8.5-4
ii  gcc-4.9 [c-compiler]4.9.4-2
ii  gcc-5 [c-compiler]  5.5.0-12
ii  gcc-6 [c-compiler]  6.5.0-2
ii  gcc-8 [c-compiler]  8.4.0-4
ii  gcc-9 [c-compiler]  9.3.0-18
ii  libc6-dev [libc-dev]2.31-4
ii  tcc [c-compiler]0.9.27+git20200814.62c30a4a-1

Versions of packages libtool recommends:
ii  libltdl-dev  2.4.6-14+local1

Versions of packages libtool suggests:
ii  autoconf  2.69-11.1+local2
ii  automake [automaken]  1:1.16.2-4
pn  gcj-jdk   
ii  gfortran  4:10.2.0-1
ii  gfortran-10 [fortran95-compiler]  10.2.0-17
ii  libtool-doc   2.4.6-14

-- no debconf information

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

Bug#975268: gazebo: FTBFS against boost_1.74

[Anton Gladky]

Package: gazebo
Version: 11.1.0+dfsg-3
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

[100%] Built target MisalignmentPlugin
/<>/plugins/SimpleTrackedVehiclePlugin.cc:35:7: error: 
redefinition of ‘class std::hash >’
   35 | class hash> {
   

It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/gazebo_11.1.0+dfsg-3_unstable_boost.log

Best regards

Anton

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+2xX0RHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wYCXQ/9HlLnRGwg5Hrh98zxSXo4Z8oxnv9dzxHL
UI5kKDj9aLIGOdkR6Q1gwThPu7642d6isb50E5YW5+H9gJld6hs/S8LjOr640PP0
A9r2CcdFQLExrF6XIHFxlMGVK9hQEHWLNogZE71W4kXbM21KKnEEcl8xYXL8/4ly
oGHS3n6F7tl3tAUjdxZUYJR0Ilss2mGxUfq0S0XgC+1rQZ0bIR3N+IrditwKhkB1
yZ60uxQ9JCNwHc195dZOdORavOwZNqtvSG9ahI0MZ2y3N1xzwvIM11WSRgJMMeoj
poVAjz+mYu0zt8rmiyVX0Syk7UvxCPjUTf0eNZk7AvHR/baTYi6BEu1CTAMB9rF4
2jDz1D141n03zgu1stbgBJL1GQ8W593dseqPmjo2QUjaxbz2wXszaevbgsI3EdXH
USkh57uoJL16ZPNcbtokeyvHdHBGfD/Cj/MGJTzPQCDd6G6QUb6LdGzY3lH8MLC6
Vvf1eM/FKj75Gk0/y3i6Q+VnMluUn/Q3Gm8da/2G7PjHxpxAV6GUwTBS4crw88R1
Kb8yNffSXUWkQPe2b4D7KoKU/mYbL60/mAi6WJPMB+db3LU5dYnCKQZtgYjtBsLt
aiYaZdxXOQZP7nIrGdR5ygJtXmtlO8/kBsmXN5u4s+S0+xF+D8dzdQ/erc454ZAN
+npIio6v5ls=
=ISg2
-END PGP SIGNATURE-

Bug#975267: freecad: FTBFS against boost_1.74

[Tobias Frost]

Control: tags -1 patch fixed-upstream

https://github.com/FreeCAD/FreeCAD/pull/3571

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Sean Whitton]

Hello,

On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:

> First, as a point of order (for which some authoritative guidance from
> the Secretary, CCed, would potentially prove useful): while the
> technical committee is empowered to handle various types of disputes (up
> to and including overruling an individual developer if necessary), I do
> not believe it falls within the scope of the technical committee to
> override a decision already decided by a project-wide GR, or to
> "interpret" the text of a GR issuing a nontechnical policy document in
> ways that may undermine the decision made in that GR and document.  Any
> interpretation of the text of the GR would need to be based on the text
> and intent of the GR. (Intent could include discussion at the time, but
> would notably include the text of other options that did not prevail, as
> well as the status quo at the time that motivated a GR to change.)
> Changing that intent would require either another GR, or (per specific
> provisions included in the winning GR option) consensus among the
> project, not a TC ruling.
>
> Concretely, the GR explicitly acted by "Using its power under
> Constitution section 4.1 (5)", which is the power to "Issue, supersede
> and withdraw nontechnical policy documents and statements.". The
> Technical Committee does not have such "nontechnical policy documents
> and statements" within its ambit. Any interpretation of 'what it means
> to "support the efforts of developers" working on support for
> alternative init systems' would thus be an interpretation of such a
> nontechnical policy document.
>
> Thus, I would suggest that the technical committee should decline to
> rule on any matters already decided by the GR. This does not preclude
> the TC from offering advice, or potentially facilitating dispute
> resolution if asked to do so, or even as a *last resort* overruling a
> developer on a specific technical matter (if doing so does not go
> against the GR), but I don't believe it's within the scope of the TC to
> relitigate the GR to mandate support for alternative init systems. Any
> potential ruling here would need to avoid attempting to supersede the
> GR.

I have been thinking about this procedural issue and in the end I think
that it is moot.  Let me explain how things seem to me.

In our dispute resolution role, the TC is empowered to decide upon the
two things about the contents of the network-manager package that we
have been asked to decide upon, as a matter of last resort.  No-one
disputes that we can do this.

We have also been invited to rule that "Similar init-compatibility
changes should not be blocked by package maintainers unless they are
defective on their own merits".  Essentially we are being invited to
generalise the decision that we make about the network-manager package
to say that it would apply to similar cases.

We might decide that the reasons we have for whatever decision we make
about the network-manager package do not generalise, and so we may
decline the invitation to make any more general ruling.

But if we do think the reasons generalise, then we can generalise our
ruling without stepping outside of our dispute resolution role.  For
example, we might say "if another CTTE bug was filed about the contents
of a package which was similar to this one in the following respects
... then we would expect to issue the same ruling as we have here,
because we believe that our reasons for this ruling would apply to all
packages which are similar in the previously stated respects."

Clearly we would not want to say anything which we thought contravened
the GR.  However, I do not think there is any reason to think that
resolving this dispute would necessarily involve the TC interacting with
the GR in a way that the constitution does not permit.  We are being
asked to decide about one package, and being invited to generalise in a
way that falls within the scope of our dispute resolution role.

-- 
Sean Whitton

Bug#973741: gitlab: Yarn hasn't been able to find a cache folder it can use

[Pirate Praveen]

On 2020, നവംബർ 19 11:01:11 PM IST, Michael Prokop  wrote:
>Hi,
>
>* Pirate Praveen [Thu Nov 19, 2020 at 03:05:13PM +0530]:
>
>> As you already found out, the problem is in node-yarnpkg. The fix is
>> a bit hard though as node-yarnpkg currently ftbfs due to babel 7
>> transition.
>
>> A work around could be to install yarnpkg via npm. npm install -g
>> yarn and replace the yarnpkg command.
>
>I noticed that yarnpkg currently isn't part of Debian/testing
>(according to https://tracker.debian.org/pkg/node-yarnpkg due to
>"Updating node-yarnpkg introduces new bugs: #960120, #972952, #973741").
>
>It would be rather unfortunate if it wouldn't make it into bullseye.
>Sadly I can't really help with the mentioned bugreports myself, but is
>there a chance, to see yarnpkg back in Debian/testing (given that
>latest interaction in e.g. #960120 dates back to August) so it could
>make it into bullseye? :)

I can see 2 possibilities,

1. Someone make yarn 1.x build with babel 7
2. Yarn 2.x gets a stable release and it is updated

I'm not sure if either of it will happen in time for bullseye. I tried my best 
with option 1, but I'm not a js programmer to unblock it. I asked a few people 
for help, but was not successful in that attempt.

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

Bug#971884: raspi-firmware: could you enable dpkg-reconfigure raspi-firmware?

[Gunnar Wolf]

Please explain further as to what you mean; what do you mean by using
dpkg-reconfigure to configure something?

I can confirm to you that, when I change any values in
/etc/default/raspi*, 'dpkg-reconfigure raspi-firmware' enacts the
changes (that is, regenerates the relevant /boot/firmware/ files).

Thanks!

Bug#970999: glances 3.1.0-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 970999 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: glances
Version: 3.1.0-1+deb10u1

Explanation: listen only on localhost by default

Bug#972694: node-object-path 0.11.4-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 972694 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: node-object-path
Version: 0.11.4-2+deb10u1

Explanation: fix prototype pollution in set() [CVE-2020-15256]

Bug#931068: zenity: Window icon is not displayed under Wayland

[Yvan Masson]

On Tue, 25 Jun 2019 17:00:15 +0100 Simon McVittie  wrote:

On Tue, 25 Jun 2019 at 15:47:13 +0200, Yvan Masson wrote:
> Window icon (which can be chosen with --window-icon) does not work when
> using Wayland, but works using Gnome.

Wayland is a protocol, not an implementation.

What is the environment in which this doesn't work for you? Is it Weston,
or GNOME Shell 3.30 in Wayland mode, or KDE in Wayland mode, or Sway,
or something else?

What is the environment in which this does work for you? Is it GNOME Shell
3.30 in Wayland mode, or GNOME Shell 3.30 in Xorg mode, or something else?

The results I get are:

- GNOME Shell 3.30 in Xorg mode: chosen icon appears in top bar and dash
  (sidebar in overview)
- GNOME Shell 3.30 in Wayland mode: a "broken image" icon appears instead

smcv


Hi,

I am really embarrassed, I just realized that I forgot to reply…

The results you describe are exactly what I experienced. The issue is 
still here with zenity 3.32.0-6 and Gnome 3.38.1-2.


As you suggested, I checked with another desktop environment, KDE 
Wayland (using KDE Neon: plasma-desktop 
4:5.20.3-0xneon+20.04+focal+build16 and zenity 3.32.0-5): the issue is 
exactly the same. It works on X11 but not on Wayland.


Do you want me to report this upstream?

Regards,
Yvan

Bug#972183: libjpeg-turbo 1.5.2-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 972183 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: libjpeg-turbo
Version: 1.5.2-2+deb10u1

Explanation: fix denial of service [CVE-2018-1152], buffer over read 
[CVE-2018-14498], possible remote code execution [CVE-2019-2201], buffer over 
read [CVE-2020-13790]

Bug#972360: src:zeromq3: Wrong dependency on libpgm-5.2-0 for hppa and x32

[Luca Boccassi]

On Sun, 18 Oct 2020 14:24:04 +0200  wrote:
> Hi,
> 
> On Fri, Oct 16, 2020 at 10:21 PM Vasyl Gello 
wrote:
> > building kodi on x32 breaks on the following unsatisfiable
dependency:
> >
> > libpgm-5.2-0 (>= 5.1.116~dfsg) [hppa, x32].
> >
> > There is libpgm-5.3-0 already built for x32 but control file for
zeromq3
> > still lists that old pinned version.
>  This might look strange, but somewhat expected. Please note that
> while Debian supports twenty two architectures, these are divided
into
> two parts: primary (supported) and secondary (ports) architectures.
> Both hppa and x32 fall into the latter category.
> When a library transition happens, most often just the primary
> architectures are waited to build the new dependent library version.
> That's why when the applications binNMUed those might still build
with
> the old library version. This happened with hppa and x32 for libpgm.
> I've asked the x32 buildd admin to reschedule the binNMU. Going to
> close this bug report when that happens.
> I don't think I can do much about the hppa zeromq3 self-test failure.
> All I know is that until 4.2.5 it was working correctly. Then 4.3.1
> changed something and the self-testing started to work sporadically.
> With 4.3.3 it always fails on hppa. This means only the old libpgm
> dependent zeromq3 is available on that architecture. I put the
> upstream maintainer in Cc and he might look into it.
> 
> Regards,
> Laszlo/GCS

I think it was just one of the timing related failures, which should go
away with 4.3.3-4. I think this can be closed.

-- 
Kind regards,
Luca Boccassi

Bug#975279: mirror submission for mirror.lagoon.nc

[Tech]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.lagoon.nc
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Tech 
Country: NC New Caledonia
Location: Noumea
Sponsor: OFFRATEL/LAGOON https://www.lagoon.nc/
Comment: Hi,
 
 i corrected the issues mentioned in the bug #971342
 Thanks for pointing that out.
 Regards




Trace Url: http://mirror.lagoon.nc/debian/project/trace/
Trace Url: http://mirror.lagoon.nc/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.lagoon.nc/debian/project/trace/mirror.lagoon.nc

Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64

[Christian Kastner]

Hi Ryutaroh,

On 11/18/20 5:45 AM, Ryutaroh Matsumoto wrote:
> I made the attached patch against the latest upstream git source
> as attached. I also add "patch" tag to this bts.
> As far as I tested, the patch seems working well.
> I also added bind-mount of /proc and /dev/pts as recent version of
> grub seems to use them.

It's great to see progress with vmdb2 getting support for more
architectures, thank you for looking into this!

I haven't tested this version yet, but looking at the patch, I'd like to
two (minor) observations:

  * You could enhance the new "arch" field of the grub plugin by not
defaulting to amd64, but to the native host architecture. You can
get this using

subprocess.check_call(['dpkg', '--print-architecture'])

  * Instead of the generic Exception, you could raise
NotImplementedException when an unsupported architecture is
encountered

By the way, it would be really nice to eventually have example commands
for creating images in the documentation somewhere. Perhaps Lars is open
to extending README.md, or the manual, with some examples for other
architectures?

Best,
Christian

Bug#972477: #972477: mirror submission for mirror.bizflycloud.vn

[Trang Nguyen]

Hi,

I have just added tracefile matching my site name mirror.bizflycloud.vn 
and re-submit the mirror.


Please re-check mirror in this bug.

Thanks and regards.

---

Trang Nguyen

BizFly Cloud - Vietnam

Bug#974797: pocl: Please upgrade to llvm-toolchain-11

[Rebecca N. Palmer]

(libgpuarray maintainer)

This isn't testable in a qemu-armhf chroot, as pocl doesn't work there.

Do all the non-clblas tests pass?  (This can be checked by uninstalling 
libclblas-dev then running the tests - this will "error" the clblas 
tests but should at least not crash them.)


On 19/11/2020 14:39, Andreas Beckmann wrote:

It terminates with a segmentation fault in LLVM.


This is potentially an *LLVM* bug, as invalid input source code 
shouldn't crash the compiler, but that's less clear-cut when the 
compiler is being called as a library.


If it is, it doesn't seem to be known: there are no upstream LLVM bugs 
with this backtrace.



The CL kernel is a piece of generated source code created by the
(simplified) stack: python - libgpuarray - libclblas before it gets
handed over to pocl. While I managed to extract the CL kernel source, I


That's as expected.  Can you post this kernel source here?


#0  getEmissionKind () at 
/build/llvm-toolchain-10-hVI0Qp/llvm-toolchain-10-10.0.1/llvm/include/llvm/IR/DebugInfoMetadata.h:1244
#1  initialize () at 
/build/llvm-toolchain-10-hVI0Qp/llvm-toolchain-10-10.0.1/llvm/lib/CodeGen/LexicalScopes.cpp:53


Did you have libllvm10-dbgsym installed?  If not, does installing that 
give a more detailed backtrace?  (I suspect an invalid 'this', given 
that the crashing line accesses only a class member.)

Bug#975285: ITP: deepin-repair-tools -- Deepin system repair tools

[hufeng]

Package: wnpp
Severity: wishlist
Owner: Hu Feng 
X-Debbugs-Cc: debian-de...@lists.debian.org


* Package name : deepin-repair-tools
  Version  : 5.0.1
  Upstream Author  : 石博文 
* URL  : https://github.com/linuxdeepin/deepin-repair-tools
  License  : GPL-3+
  Programming Lang : C++
  Description  : Deepin system repair tools

Deepin Repair Tools is a useful tools for system repair and clean.
.
It is part of Deepin software and DDE (Deepin Desktop Environment).
.
I intend to co-maintain this package inside pkg-deepin group.

Bug#969319: wifi cannot connect after combined suspend & gateway reboot

[Andrew Zaborowski]

Hi,
NM's master branch has changes related to IWD hidden SSID support and
there's a possibility that it's working reliably.  Unfortunately the
changes didn't make it into the upcoming 1.28.0 so they'll probably
only be in 1.30.0 which may be a long time off.

Best regards

Bug#971515: Status as of last tech-ctte meeting

[Elana Hashman]

On Wed, Nov 18, 2020 at 11:36:09AM -0600, Gunnar Wolf wrote:
> ...
> I'm pasting here a bit of the discussion that happened later during
> the meeting: having this discussion K8S-specific, Elana mentioned that
> "that is a big part of the tension. sometimes, you have an upstream
> where the authors are less resourced and responsive than the
> downstream. this case is almost certainly the opposite".

To better illustrate this quote, I agreed to provide more context on the
scale of the Kubernetes project.

Kubernetes is a very large and active project. It has about 600
members,[0] 1000 voters,[1] 100 committers (which I define as members of
the milestone-maintainers team),[2] and over 50,000 contributors.[3] The
project has its own security[4] and release teams,[5] and the release
team includes a software licensing team. I am a SIG Chair and milestone
maintainer in the upstream Kubernetes project, which is comparable to
being a team lead and uploading developer in Debian.

As such, the scale of Kubernetes is similar to that of Debian itself.
Kubernetes as an upstream project is much better resourced than the
single downstream maintainer in Debian.

[0]: https://github.com/orgs/kubernetes/people
[1]: 
https://github.com/kubernetes/community/blob/8bdeb0a4d6e7a3fc9afdb874aa2cefa2ba88bc9c/events/elections/2020/voters.md
[2]: 
https://github.com/kubernetes/org/blob/adc0166a081ec7a613ebc8422d9676ff4035fc31/config/kubernetes/sig-release/teams.yaml#L17-L141
[3]: https://k8s.devstats.cncf.io/d/24/overall-project-statistics?orgId=1
[4]: https://github.com/kubernetes/security
[5]: https://github.com/kubernetes/community/tree/master/sig-release

> At this point, we found some friction as to _what_ we are discussing
> on: Is this bug specifically on Kubernetes, which should be taken as a
> special case? Or would we try to rule as the Technical Committee on
> vendoring in general in the Debian ecosystem? Elana repeated her
> assurance that the Kubernetes team is thorough in their
> freeness-checking and security practices; I insisted on "not
> discussing about K8S, but about a bundling practice to which K8S
> subscribes".

The scope of the bug as submitted is limited to the Kubernetes package.
I think it is better to try to limit our decision to that scope, as
Kubernetes is not comparable to a single-maintainer Golang project that
might have a similar number of vendored dependencies.

The resourcing and scale of the Kubernetes project gives us better
assurances that upstream has done due diligence for dependency
management. I don't think we could assume this for an arbitrary package.

Per yesterday's TC discussion,[6] I think it makes sense to handle
Kubernetes with consideration to its size and importance to users,
similar to how we special-case Firefox.

- e

[6]: 
http://meetbot.debian.net/debian-ctte/2020/debian-ctte.2020-11-18-17.58.html


signature.asc
Description: PGP signature

Bug#975280: ITP: prometheus-mqtt-exporter -- Prometheus exporter for metrics sent via MQTT topics

[Martina Ferrari]

Package: wnpp
Severity: wishlist
Owner: Martina Ferrari 

* Package name: prometheus-mqtt-exporter
  Version : 0.1.4-1
  Upstream Author : Christoph Petrausch
* URL : https://github.com/hikhvar/mqtt2prometheus
* License : Expat
  Programming Lang: Go
  Description : Prometheus exporter for metrics sent via MQTT topics

 This exporter translates from MQTT topics to prometheus metrics, allowing
 small/IoT devices that can't be polled directly to be monitored.
 .
 Clients push metrics as abritrary JSON messages via MQTT to an MQTT Broker.
 This exporter subscribes to the broker and publish the received messages as
 prometheus metrics.
 .
 While the upstream project is called `mqtt2prometheus`, the Debian packaging
 uses the name `prometheus-mqtt-exporter` for consistency with other exporters.