Bug#976369: rust-csv_1.1.5-1_mips64el-buildd.changes REJECTED

[Aurelien Jarno]

Source: rust-csv
Version: 1.1.5-1
Severity: serious

- Forwarded message from Debian FTP Masters 
 -

From: Debian FTP Masters 
To: mips64el Build Daemon 
Date: Fri, 04 Dec 2020 01:51:38 +
Subject: rust-csv_1.1.5-1_mips64el-buildd.changes REJECTED
Message-Id: 

librust-csv-dev_1.1.5-1_mips64el.deb: has 66 file(s) with a timestamp too far 
in the past:
  usr/share/cargo/registry/csv-1.1.5/.gitignore (Thu Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/COPYING (Thu Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/ISSUE_TEMPLATE.md (Thu Jan  1 00:00:00 1970) 
 usr/share/cargo/registry/csv-1.1.5/LICENSE-MIT (Thu Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/README.md (Thu Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/UNLICENSE (Thu Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/benches/bench.rs (Thu Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/cookbook-read-basic.rs (Thu Jan  1 
00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/cookbook-read-colon.rs (Thu Jan  1 
00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/cookbook-read-no-headers.rs (Thu 
Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/cookbook-read-serde.rs (Thu Jan  1 
00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/cookbook-write-basic.rs (Thu Jan  1 
00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/cookbook-write-serde.rs (Thu Jan  1 
00:00:00 1970)  usr/share/cargo/registry/csv-1.1.5/examples/data/bench/game.csv 
(Thu Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/data/bench/gtfs-mbta-stop-times.csv 
(Thu Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/data/bench/nfl.csv (Thu Jan  1 
00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/data/bench/worldcitiespop.csv (Thu 
Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/data/smallpop-colon.csv (Thu Jan  1 
00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/data/smallpop-no-headers.csv (Thu 
Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/data/smallpop.csv (Thu Jan  1 
00:00:00 1970)  usr/share/cargo/registry/csv-1.1.5/examples/data/strange.csv 
(Thu Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/data/uspop-latin1.csv (Thu Jan  1 
00:00:00 1970)  usr/share/cargo/registry/csv-1.1.5/examples/data/uspop-null.csv 
(Thu Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/data/uspop.csv (Thu Jan  1 00:00:00 
1970)  usr/share/cargo/registry/csv-1.1.5/examples/tutorial-error-01.rs (Thu 
Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-error-02.rs (Thu Jan  1 
00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-error-03.rs (Thu Jan  1 
00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-error-04.rs (Thu Jan  1 
00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-perf-alloc-01.rs (Thu Jan  
1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-perf-alloc-02.rs (Thu Jan  
1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-perf-alloc-03.rs (Thu Jan  
1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-perf-core-01.rs (Thu Jan  
1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-perf-serde-01.rs (Thu Jan  
1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-perf-serde-02.rs (Thu Jan  
1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-perf-serde-03.rs (Thu Jan  
1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-pipeline-pop-01.rs (Thu 
Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-pipeline-search-01.rs (Thu 
Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-pipeline-search-02.rs (Thu 
Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-read-01.rs (Thu Jan  1 
00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-read-delimiter-01.rs (Thu 
Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-read-headers-01.rs (Thu 
Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-read-headers-02.rs (Thu 
Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-read-serde-01.rs (Thu Jan  
1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-read-serde-02.rs (Thu Jan  
1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-read-serde-03.rs (Thu Jan  
1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-read-serde-04.rs (Thu Jan  
1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-read-serde-invalid-01.rs 
(Thu Jan  1 00:00:00 1970)  
usr/share/cargo/registry/csv-1.1.5/examples/tutorial-read-serde-invalid-02.rs 
(Thu Jan  1 00:00:00 1970)  

Bug#976210: FTBFS against octave 6: error: Invalid call to fsolve

[Rafael Laboissière]

Control: tags -1 + upstream
Control forwarded -1

* Sébastien Villemot  [2020-12-01 15:45]:


Package: src:octave-interval
Version: 3.2.0-6
Severity: important
Tags: ftbfs

octave-interval FTBFS against octave 6.


The issue has been forwarded upstream: 
https://savannah.gnu.org/bugs/index.php?59617


Also, there is bug report on the upstream BTS regarding the failure of 
the unit tests against Octave 6: 
https://savannah.gnu.org/bugs/?func=detailitem_id=59334


Rafael Laboissière

Bug#976368: override: python2.7 and python-defaults binaries should be optional, not standard

[Matthias Klose]

Package: ftp.debian.org

python2.7 and python-defaults binaries should be optional, not standard.

Bug#976285: please enable redis plugin

[Felix Zielcke]

Am Freitag, den 04.12.2020, 11:05 +1100 schrieb Dmitry Smirnov:
> On Thursday, 3 December 2020 6:12:01 PM AEDT Felix Zielcke wrote:
> > So what's missing to enable Agent 2?
> 
> I think Agent 2 is not the issue.

In the docs it's listed for Agent 2:

https://www.zabbix.com/documentation/5.0/manual/config/templates_out_of_the_box/zabbix_agent2

So I guess it's needed?

> > zabbix_get [2294402]: Check access restrictions in Zabbix agent
> > configuration
> 
> Agent will only respond to requests from hosts listed in "Server=".
> 

Yeah, I found it out now that it was using IPv6 even though only
127.0.0.1 was allowed:

# zabbix_get -s 127.0.0.1 -k redis.ping
ZBX_NOTSUPPORTED: Unsupported item key.

Bug#976191: texlive-latex-base: Fails to build formats for LaTeX

[Hilmar Preuße]

Am 04.12.2020 um 01:07 teilte Norbert Preining mit:

Hi,


But be aware, that there might be further moves coming again reverting
this change (yes, I know the pain), since LaTeX upstream is doing this:
https://github.com/latex3/latex2e/issues/450


I guess you rather meant https://github.com/latex3/latex2e/pull/446 .

Anyway we need a fix for our issue right now, else the package won't 
move into testing. :-)



Thanks for all your work!


Thanks for your nice perl scripts, which makes live looot easier.

Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#976206: FTBFS against octave 6: Some tests failed

[Rafael Laboissière]

Control: tags -1 + upstream

* Sébastien Villemot  [2020-12-01 15:31]:


Package: src:octave-stk
Version: 2.6.1-4
Severity: important
Tags: ftbfs

octave-stk FTBFS against octave 6.


This issue has been reported upstream: 
https://savannah.gnu.org/bugs/?func=detailitem_id=59340


Rafael

Bug#972134: chromium: please, consider moving the package to team-maintainance to properly maintain it

[Rogério Theodoro de Brito]

First of all, thank you for including me on replies.

Regarding the subject, I think that the best way to proceed would be to, 
essentially, create a task force to maintain chromium properly.

I don't think that I have the computational means to compile chromium 
frequently (I hope that using ccache and/or distcc can be used), but I may be 
interested in, participating in the effort.

That being said, I think that inviting other people would be the way to go, 
including the maintainers from Linux Mint, and other distributions. There are 
other people maintaining chromium forks out there, IIRC, like a project called 
de-googled chromium, or something like that.

Inviting all those people in a task force and working openly (and with 
redundant human resources) is, IMVHO, something desired, not only for chromium, 
but for other software.

Since you mentioned armhf, Riku, we may try to get people from raspbian and 
other downstreams to also take part.

Also, given enough hands, splitting components/vendored libraries that chromium 
quite possibly includes (like the last time that I checked) could be something 
desired for, say, security purposes and, also, for other teams (IIRC, there is 
a bunch of multimedia libraries that were vendored).

(Of course, the "de-vendoring" should occur only when feasible).

That is my vision of how the packaging could go forward.

Thanks,

Rogério Brito.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Lars Wirzenius]

As it happens, David Edmonson (dme), added to cc, has been working on
adding arm64 support for the grub plugin. Part of his changes is that the
grub plugin will know the target archietecure, and choose the right grub
.deb package to install based on that.

Unfortunatly, the tests for his changes don't pass yet.

David, do you have any commnent on this?

On Sat, 2020-11-07 at 23:42 -0600, Gunnar Wolf wrote:
> Hello Lars,
> 
> I am writing to you regarding the bug report I am Cc:ing here. Please
> help me correctly answer to this! The submitter says, in the initial
> mail:
> 
> > I am trying to let autopkgtest-build-qemu work on arm64.
> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973038
> > for relevant report.
> > The original autopkgtest-build-qemu uses "grub: bios" for vmdb2,
> > which let vmdb2 install grub-pc on arm64, and fail.
> > 
> > So I try "grub: uefi" for vmdb2.
> > Then vmdb2 tries to install grub-efi-amd64,
> > and again fails.
> > There is no way to let vmdb2 to create a bootable image on arm64.
> > vmdb2 seems completely unusable on arm64 (and armhf, armel, etc.)
> > So I set severity grave.
> 
> He sent a workaround that does not fix the issue, but lets him build
> for his target system:
> 
> --- usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py-orig
> 2020-10-31 12:47:04.796899268 +0900
> +++ usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py 
> 2020-10-31 12:50:00.322817935 +0900
> @@ -112,8 +112,8 @@
>  raise Exception('"efi" or "efi-part" required in UEFI GRUB 
> installation')
>  
>  vmdb.progress("Installing GRUB for UEFI")
> -grub_package = "grub-efi-amd64"
> -grub_target = "x86_64-efi"
> +grub_package = "grub-efi-arm64"
> +grub_target = "arm64-efi"
>  self.install_grub(values, settings, state, grub_package, 
> grub_target)
>  
>  def install_bios(self, values, settings, state):
> 
> *If* there is any information to plugins as to which architecture is
> being built, the fix is basically trivial... But I could not find
> anything on that regard. Can you suggest anything?
> 
> Thanks a lot!

Bug#976367: cruft-ng: add support for plocate

[Paul Wise]

Package: cruft-ng
Version: 0.4.8
Severity: normalX-Debbugs-CC: ploc...@packages.debian.org

plocate is a new locate and now updatedb implementation that is much
faster than mlocate due to new on-disk formats and new Linux kernel
features like io_uring.

https://plocate.sesse.net/
https://blog.sesse.net/blog/tech/2020-12-03-19-45_plocate_1_1_0_released.html

It would be great if I could fully switch from mlocate to plocate; only
the lack of support for plocate in cruft-ng is preventing me from
removing mlocate from my system.

plocate is yet not portable to Hurd, kFreeBSD and non-systemd systems,
so support for mlocate shouldn't be removed from cruft-ng yet.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#973005: inventor: please enable builds on sparc64 and riscv64

[Graham Inggs]

Control: tags -1 + patch

Attached is a patch which replaces the long string of comparisons with
 __SIZEOF_LONG__, i.e.

-#if (_MIPS_SZPTR == 64 || __ia64 || __x86_64 || __alpha__ ||
__powerpc64__ || __s390x__ || __aarch64__)
+#if (__SIZEOF_LONG__ == 8)

I've uploaded inventor with this patch to Ubuntu and it built fine on
all architectures there [1], including riscv64.


[1] https://launchpad.net/ubuntu/+source/inventor/2.1.5-10-23ubuntu1
--- a/debian/patches/endianness.patch
+++ b/debian/patches/endianness.patch
@@ -53,7 +53,7 @@
  #endif
  
 +/* Added for Debian by Steve M. Robbins */
-+#if (_MIPS_SZPTR == 64 || __ia64 || __x86_64 || __alpha__ || __powerpc64__ || __s390x__ || __aarch64__)
++#if (__SIZEOF_LONG__ == 8)
 +#  define USE_64BIT_HACKS 1
 +#else
 +#  define USE_64BIT_HACKS 0

Bug#976366: Upgrade to 247 broke keyboard input on Wayland session

[duck]

Package: systemd
Version: 247.1-3
Severity: critical
Justification: breaks graphical session input
Control: affects -1 sway


Quack,

After upgrade from 246.6-5 to 247.1-3 I experienced impossibility to use 
my keyboard after login on graphical session.


I'm using Lightdm + Sway and could input with my usual keyboard for 
encrypted disk passphrase, GRUB, and lightdm login screen too. Console 
also was working fine. But after login on lightdm I could not input 
anything in Sway while the mouse worked fine (but I could not do much).


I was able to capture this error in sway log:
00:00:00.142 [ERROR] [backend/session/logind.c:75] Failed to take device 
'/dev/input/event5': No such device
00:00:00.143 [ERROR] [backend/session/logind.c:75] Failed to take device 
'/dev/input/event6': No such device


These files existed and were using the usual root:input rw/rw/- 
permissions. These are devices for my keyboard and LightDM X session 
enumerates them properly:
[31.282] (II) config/udev: Adding input device ckb1: Corsair Gaming 
K70 LUX RGB Keyboard vKB (/dev/input/event5)
[31.282] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: 
Applying InputClass "evdev pointer catchall"
[31.282] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: 
Applying InputClass "evdev keyboard catchall"
[31.282] (II) Using input driver 'evdev' for 'ckb1: Corsair Gaming 
K70 LUX RGB Keyboard vKB'
[31.282] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: always 
reports core events
[31.282] (**) Option "config_info" 
"udev:/sys/devices/virtual/input/input27/event5"
[31.282] (II) XINPUT: Adding extended input device "ckb1: Corsair 
Gaming K70 LUX RGB Keyboard vKB" (type: KEYBOARD, id 12)

[31.282] (**) Option "xkb_rules" "evdev"
[31.282] (**) Option "xkb_model" "pc105"
[31.282] (**) Option "xkb_layout" "us"
[31.282] (**) Option "xkb_variant" "altgr-intl"
[31.282] (**) Option "xkb_options" "compose:menu,level3:ralt_switch"
[31.283] (II) evdev: ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: 
initialized for relative axes.
[31.283] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: (accel) 
keeping acceleration scheme 1
[31.283] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: (accel) 
acceleration profile 0
[31.283] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: (accel) 
acceleration factor: 2.000
[31.283] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: (accel) 
acceleration threshold: 4
[31.284] (II) config/udev: Adding input device ckb1: Corsair Gaming 
K70 LUX RGB Keyboard vM (/dev/input/event6)
[31.284] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vM: Applying 
InputClass "evdev pointer catchall"
[31.284] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vM: Applying 
InputClass "evdev keyboard catchall"
[31.284] (II) Using input driver 'evdev' for 'ckb1: Corsair Gaming 
K70 LUX RGB Keyboard vM'
[31.284] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vM: always 
reports core events
[31.284] (**) evdev: ckb1: Corsair Gaming K70 LUX RGB Keyboard vM: 
Device: "/dev/input/event6"
[31.284] (--) evdev: ckb1: Corsair Gaming K70 LUX RGB Keyboard vM: 
Vendor 0x1b1c Product 0x1b33
[31.284] (**) Option "config_info" 
"udev:/sys/devices/virtual/input/input28/event6"
[31.284] (II) XINPUT: Adding extended input device "ckb1: Corsair 
Gaming K70 LUX RGB Keyboard vM" (type: KEYBOARD, id 13)


My /etc/systemd/logind.conf is unaltered from the default.

I did not find any apparmor denial.

I could not find anything meaningful in systemd logs or others. Then I 
checked what packages were upgraded recently and gave it a try 
downgrading to 246.6-5, and after a reboot it worked. Tell me if I can 
provide any other information.


Regards.
\_o<

--
Marc Dequènes

Bug#635666: groff(1) man page looks atrocious in emacs

[era]

On Fri, Dec 4, 2020, at 02:37, G. Branden Robinson wrote:
> I feel I am fluent enough in *roff to offer assistance is crafting
> regexes for this purpose, if you'd like help, though I know nothing of
> elisp; if I can help, please tell me what your requirements are.

This sounds like it should be communicated to the upstream Emacs bug tracker; 
Debian merely packages Emacs for making it available to Debian users. Normally 
we would just this for you (basically copy/paste your message into a new bug 
report in their bug tracker, and set this bug as "forwarded upstream"), but in 
this particular matter, it would feel more natural if you could open a new bug 
in their bug tracker yourself, and take it from there.

Just to reiterate, Debian doesn't develop Emacs, we just take whatever the GNU 
Emacs team releases, and adapt it to our system. We do track bugs which are 
reported here, but the ones which require changes to Emacs itself will be 
forwarded to the upstream maintainers.

They use the same bug tracking system; the web site front page for their bug 
tracker is at https://debbugs.gnu.org/Emacs.html

Please do follow up here as well, if only just so we can mark this as 
forwarded, with a pointer to the upstream bug.

Thanks,

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way

[Felix Lechner]

Hi,

> On Saturday, 8 August 2020 23:40:51 CEST gregor herrmann wrote:
> > I think having the data provided by debian-policy (in the package,
> > and maybe-for other purposes-also on the website) would be an
> > excellent idea, thanks for the offer.

Please have a look at this commit. It explains how to mitigate
expected upcoming breakage in your package.

   
https://salsa.debian.org/lintian/lintian/-/commit/d2f692f564ac725a0eb58a7d62abe57f66cdc753

Please load the policy data with:

my $data = $profile->load_data(...);

instead of

my $data = Lintian::Data->new(...);

That is a temporary fix; the interface is scheduled to change again in
the near future. Thank you!

Kind regards
Felix Lechner

Bug#976296: blender: Segmentation fault when importing background image

[Will C.]

On Thu, 03 Dec 2020 22:40:59 +0100 "Matteo F. Vescovi"  wrote:
> Hi!
>
>> [...]
> Exactly. Closing, in the meanwhile.
>
> Cheers.
>
>
> --
> Matteo F. Vescovi || Debian Developer
> GnuPG KeyID: 4096R/0x8062398983B2CF7A

Hi,

I ended up reinstalling Debian from the ground up again, but the bug
still persists without the packages pointed out above. Should I open a
new bug report?

Regards,
Will

Bug#976365: ITP: sphinx-a4doc -- Sphinx domain and autodoc for Antlr4 grammars

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi 

* Package name: sphinx-a4doc
  Version : 1.2.1
  Upstream Author : Vladimir Goncharov 
* URL : https://github.com/AmatanHead/sphinx-a4doc
* License : MIT
  Programming Lang: Python
  Description : Sphinx domain and autodoc for Antlr4 grammars

Binary package names: python3-sphinx-a4doc

 # Sphinx plugin for Antlr4
 .
 A4Doc is a sphinx plugin for documenting Antlr4 grammars.
 .
 It’s primary target is to provide some overview for DSL users
 (generated documentation may not include some nuances essential
 for compiler developers).
 .
 A4Doc's features are:
 .
 - a new domain with grammar and rule directives called ``a4``;
 - directives for rendering railroad diagrams;
 - directive for extracting documentation comments and rendering docs and
   diagrams from `.g4` source files.
 .
 .
 .
 .

Bug#949572: please set python and python-minimal's priority to optional so it's not installed in the standard task

[Witold Baryluk]

Source: python-defaults
Followup-For: Bug #949572
X-Debbugs-Cc: witold.bary...@gmail.com

Hi all,

any progress on this?

It is almost a year.

Everytime I install a Debian using debootstrap or live-build, I need to later 
remove python2

root@debian:~# apt purge  python2.7-minimal 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib libre2-8 
libstd-rust-1.47
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  python-is-python2* python2* python2-minimal* python2.7* python2.7-minimal*
0 upgraded, 0 newly installed, 5 to remove and 59 not upgraded.
After this operation, 4,348 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 735815 files and directories currently installed.)
Removing python-is-python2 (2.7.18-8) ...
Removing python2 (2.7.18-2) ...
Removing python2-minimal (2.7.18-2) ...
Removing python2.7 (2.7.18-1) ...
Removing python2.7-minimal (2.7.18-1) ...
Unlinking and removing bytecode for runtime python2.7
Processing triggers for desktop-file-utils (0.26-1) ...
Processing triggers for man-db (2.9.3-2) ...
Processing triggers for mailcap (3.67) ...
Processing triggers for bamfdaemon (0.5.4-2) ...
Rebuilding /usr/share/applications/bamf-2.index...
(Reading database ... 735756 files and directories currently installed.)
Purging configuration files for python2.7-minimal (2.7.18-1) ...
root@debian:~# 


There are no reverse dependencies.


Setting priority to optional in overrides for sid and bullseye / testing,
would be appreciated.


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

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

Bug#940914: uno-libs3: Segfault on launch in cppu::_copyConstructAnyFromData

[Witold Baryluk]

Hi Rene and others,

Libreoffice started working again for me, no more segfaults or apparmor issues.

I can't reproduce the original issue anymore.

linux-image-5.9.0-3-amd64 5.9.9-1
libreoffice 1:7.0.3-4+b1
apparmor 2.13.5-1+b1


Thanks,
Witold

Bug#976260: RFS: opentype-sanitizer/8.1.0-1 [ITP] -- tools to validate and sanitize OTF/TTF/WOFF/WOFF2 font files

[Paul Wise]

On Thu, Dec 3, 2020 at 1:09 PM Romain Porte wrote:

> Uploaded a new version +dfsg.1-1 on mentors with your explanation in
> debian/copyright as suggested by Lintian.

Here is a review of the package:

There do not appear to be any further issues that would block the upload.

So I am willing to sponsor the package on the condition that once
opentype-sanitizer enters Debian, you contribute a check for running
it to check-all-the-things.

https://github.com/collab-qa/check-all-the-things/

These issues would be nice to fix at some point:

The URLs pointed to by the Vcs-* fields in debian/control do not
appear to exist.

Please update the package to the new upstream release 8.1.1.

Please fix the remaining minor lintian complaints where possible.

Please remove the debmake template comments from debian/rules if you
aren't going to use them, although uncommenting the hardening one will
fix one lintian complaint.

The debian/copyright file indicates that the debian/ directory is
licensed under the GNU GPLv3+. Usually it is recommended to use the
same license as upstream, so that upstream can easily adopt anything
that Debian includes in our package. This is especially important for
manual pages and patches.

I suggest using wrap-and-sort with these arguments to make it easier
to read diffs of the debian/ directory. You seem to have already used
most of these.

wrap-and-sort --short-indent --wrap-always --sort-binary-packages
--trailing-comma

I note that the build process searches for freetype but the package
does not build-depend on it, is that intentional?

I note that the build uses a static library rather than a private
shared library for libots, which bloats the package slightly.

Please forward the GCC warnings from the build log (or a patch fixing
them) to upstream.

The following tools run by check-all-the-things produce output that
you may want to review and or forward upstream:

cppcheck
anorack
bashate
blhc
clang-check
clang-tidy
scan-build
codespell
cme check dpkg
doc8
duck
grep -nHrF http:
shellcheck
proselint
spellintian
wrap-and-sort
yamllint

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#953838: apt: "apt-cache pkgnames" lists source packages, breaking bash-completion

[Alexander Kernozhitsky]

Control: fixed -1 2.1.12

Just upgraded to apt 2.1.12, it seems that the bug is fixed now.

-- 
Alexander Kernozhitsky

Bug#976364: webext-debianbuttons: add ability to search the Debian codesearch service

[Paul Wise]

Package: webext-debianbuttons
Version: 2.3-2
Severity: wishlist

It would be great if the debianbuttons extension could do searches on
the Debian codesearch service, in both literal and regex mode:

https://codesearch.debian.net/search?literal=0=
https://codesearch.debian.net/search?literal=1=

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#789761: how-can-i-help: Report installed packages that are not reproducable?

[Vagrant Cascadian]

On 2015-06-24, Holger Levsen wrote:
> On Mittwoch, 24. Juni 2015, Petter Reinholdtsen wrote:
>> As the reproducable is gaining seriuos tracktion, perhaps it would be an
>> idea to allow how-can-i-help to notify about installed packages that are
>> not reproducable, and suggest to help out making the packages
>> reproducable?  I'm not quite sure what kind of data source is available
>> to know if a package is reproducable or not, but perhaps something from
>> https://reproducible.debian.net/reproducible.html > can be used?
>
> https://reproducible.debian.net/reproducible.json should have all the info 
> that's needed.

That link still works, though is there a better one now? Perhaps one
that only targets the current testing release (e.g. the one used by
udd.debian.org, maybe)?


> That said, I'm not sure reproducibility status of installed packages should 
> be 
> displayed by default *now* (already). It might be wiser to wait a bit before 
> making this the default... (because hardly actionable output quickly becomes 
> ignored noise.)

It has come a ong way since 2015, hovering around 94% for testing and
83% for unstable on amd64, so perhaps time to reconsider? :)


> *That* said, I totally welcome this feature request! :-)

Likewise!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#976187: runit-systemd => runit-run transition fails to enable unit

[Lorenzo]

Control: tag -1 -moreinfo
Control: tag -1 confirmed

On 12/2/20 9:30 PM, Jamie Heilman wrote:
>
> The only way to avoid the problem is to avoid having the
> runit-systemd.postrm script from runit-systemd <= 2.1.2-36 run after
> runit-run is installed. You could introduce a new version of a
> more-or-less empty transition runit-systemd package that runit-run
> depends on, to ensure a version of the runit-systemd.postrm script
> that doesn't disable the unit exists prior to purge, it's just ugly
> becuase sysvinit users would be forced into installing a package with
> "systemd" in the name (even though it shouldn't depend on systemd)
> which is going to cause confusion. The maintainer community will
> hopefully have better advice that results in a cleaner transition. 
Thanks for the suggestion, i'll see what I can do

Lorenzo

Bug#900837: update on mass-rebuild of packages for reproducible builds

[Vagrant Cascadian]

On 2019-03-05, Holger Levsen wrote:
> I ran Chris's script again on coccia, with the result that currently
> 6084 source packages in the archive need a rebuild for reproducible
> builds, as they were built with an old dpkg version not producing
> .buildinfo files.

I ran it just now, and we're down to 3433! Still a ways to go, but
getting there...

Updated list attached.

live well,
  vagrant
abego-treelayout
abicheck
accelio
adacontrol
aiksaurus
aiowsgi
airlift-slice
album
alqalam
amispammer
amoeba-data
amphetamine-data
amqp-specs
android-platform-external-rappor
angband-audio
apertium-oci
apertium-szl
api-sanity-checker
apt-config-auto-update
apt-src
apt-venv
archmbox
arduino
argparse4j
args4j
aribas
arrayfire
asciimathtml
asis
aspell-am
aspell-cs
aspell-cy
aspell-el
aspell-fr
aspell-hr
aspell-hsb
aspell-hu
aspell-hy
aspell-is
aspell-kk
aspell-pl
aspell-ro
aspell-sl
aspell-sv
aspell-uz
asql
asterisk-moh-opsound
asterisk-prompt-de
asterisk-prompt-es-co
asterisk-prompt-fr-armelle
asterisk-prompt-fr-proformatique
asterisk-prompt-it
astrodendro
astrometry-data-2mass
at-at-clojure
atmel-firmware
autoconf2.64
autodns-dhcp
autofill-forms
automaton
awit-dbackup
axmlrpc
bar-cursor-el
beancounter
beckon-clojure
bidiui
binstats
biomaj3-zipkin
blag-fortune
blosxom
bmt
boilerpipe
brag
brebis
broctl
bsaf
bsdowl
bsfilter
bytecode
c3
caffeine-cache
calculix-ccx-doc
calculix-ccx-test
carmetal
casacore-data-lines
casacore-data-sources
cava
cclive
cdlabelgen
cecil
cecil-flowanalysis
cereal
cfi
chartkick.js
checkbot
checksecurity
cheshire-clojure
chewmail
chronicle
cl-abnf
cl-asdf-finalizers
cl-asdf-flv
cl-asdf-system-connections
cl-closure-common
cl-command-line-arguments
cl-containers
cl-cxml
cl-daemon
cl-dynamic-classes
cl-garbage-pools
cl-github-v3
cl-launch
cl-log
cl-lparallel
cl-markdown
cl-metatilities-base
cl-mustache
cl-quri
cl-rfc2388
cl-salza2
cl-sqlite
cl-trivial-utf-8
cl-umlisp
cl-umlisp-orf
cl-utilities
cl-uuid
cl-yason
cl-zip
clamassassin
clamav-unofficial-sigs
class.js
classycle
clc-intercal
clj-http-clojure
clout-clojure
coco-cs
code2html
combat
commons-exec
commons-pool
compass-toolkit-plugin
compojure-clojure
concurrent-dfsg
configure-debian
conmux
cons
console-cyrillic
courier-filter-perl
couriergraph
cpath-clojure
crafty-bitmaps
crafty-books-medium
crafty-books-medtosmall
crafty-books-small
cream
crossfire-maps
crossfire-maps-small
crypto-equality-clojure
crypto-policies
crypto-random-clojure
cryptojs
crystalcursors
csmash-demosong
css3pie
ctapi
cthumb
ctop
curvesapi
cvs-buildpackage
cvsdelta
cvsutils
cvsweb
d3-tip.js
dailystrips
daptup
db4o
dbix-easy-perl
dbus-sharp
dbus-sharp-glib
dd-plist
ddtc
debaux
debdate
debdry
debget
debian-dad
debpear
debroster
delimmatch
devpi-common
dgen
dh-rebar
dhcpy6d
dia-shapes
dict-jargon
dictem
dictzip-java
dirgra
discover-data
dish
dizzy
django-hvad
django-measurement
dkimproxy
dl10n
dnlib
dns-browse
dns323-firmware-tools
doc-debian
doc-linux-fr
docbook
docbook-dsssl
docbook-ebnf
docbook-html-forms
docbook-mathml
docbook-slides
docbook-slides-demo
docbook-utils
docbook-website
docbook-xsl-doc
dokujclient
doom-wad-shareware
drbdlinks
drgeo-doc
drraw
dtd-parser
dtdparse
durep
dvcs-autosync
dvd-slideshow
dvi2ps-fontdata
dvi2ps-fontdesc-morisawa5
dynalang
dynamips
ebook-dev-alp
ecaccess
eclipselink-jpa-2.1-spec
edb
edgar
edict-el
ehcache
eigenbase-farrago
eigenbase-resgen
el-get
elektra
elida
elscreen
ember-media
emdebian-archive-keyring
epic4-help
es-module-loader-0.17.js
esnacc
etoys
evenement
explorercanvas
extra-xdg-menus
faenza-icon-theme
famfamfam-flag
famfamfam-silk
fasd
fast-zip-clojure
fb-music-high
fccexam
feed2imap
felix-framework
felix-gogo-command
felix-gogo-runtime
felix-gogo-shell
fest-assert
fest-test
fest-util
festival-ca
festvox-don
festvox-kallpc8k
festvox-kdlpc16k
festvox-kdlpc8k
festvox-rablpc8k
fetchyahoo
fheroes2-pkg
file-mmagic
filepp
fillets-ng-data
finance-yahooquote
fizmo
flake8-docstrings
flamethrower
flare
flask-mail
flatlatex
flotr
fluid-soundfont
flup
focalinux
foiltex
fonts-alegreya-sans
fonts-arkpandora
fonts-averia-gwf
fonts-averia-sans-gwf
fonts-averia-serif-gwf
fonts-babelstone-modern
fonts-crosextra-carlito
fonts-ddc-uchen
fonts-dzongkha
fonts-hosny-thabit
fonts-inconsolata
fonts-johnsmith-induni
fonts-junction
fonts-kaushanscript
fonts-khmeros
fonts-klaudia-berenika
fonts-kristi
fonts-larabie
fonts-leckerli-one
fonts-lg-aboriginal
fonts-lklug-sinhala
fonts-lobstertwo
fonts-nafees
fonts-ocr-b
fonts-oflb-asana-math
fonts-open-sans
fonts-quattrocento
fonts-radisnoir
fonts-sambhota-tsugring
fonts-sambhota-yigchung
fonts-sil-tagmukay
fonts-stix
fonts-tibetan-machine
fonts-tuffy
fonts-ubuntu-title
fonts-ukij-uyghur
fonty-rg
fort77
fortunes-bg
fortunes-br
fortunes-cs
fortunes-eo
fortunes-fr
fortunes-ga
fortunes-ru
freetable
fretsonfire-songs-muldjord
fretsonfire-songs-sectoid
fsharp
funnelweb-doc
funny-manpages
fuzzysort
galib
games-thumbnails
gap-transgrp
gav-themes
gearman-server
gedit-latex-plugin
geki3
genesisplusgx

Bug#976363: lintian: detect debmake template comments

[Paul Wise]

Package: lintian
Version: 2.104.0
Severity: wishlist

The debmake package is an alternative to dh_make. The debmake package
contains a number of packaging templates in the /usr/share/debmake/
directory that debmake uses when generating initial packaging, which
folks then customise for their use. 

There are a number of packages where the maintainer hasn't bothered to
remove unnecessary comments that the comments in the debmake templates
themselves also suggest removing.

https://codesearch.debian.net/search?q=You+must+remove+unused+comment+lines+for+the+released+package.=1

I think it would be good if lintian could detect situations where
comments from the debmake templates have not been removed.

I think the best way to implement this would be for lintian to grow a
script that is run at lintian release time and gathers all the comments
from the debmake templates into a set of files containing comments that
should be removed, filters out some that are reasonable to keep (such
as #export DH_VERBOSE=1) and then stores those in the lintian git
repository, separated out into the types of files each comment occurs
in. Then the lintian check for this issue can detect all of the
unnecessary debmake comments.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#956602: any possibility to drop the dependency on librestbed?

[Bastian Germann]

On Sun, 4 Oct 2020 12:43:43 +0200 Francesco Poli 
 wrote:

On Sat, 15 Aug 2020 13:28:44 -0400 Alexandre Viau wrote:

[...]
> Sadly I don't think they would consider doing so unless there was a
> comparable alternative.
> 
> Jami is built on Linux, Mac, Windows, Android, Iphone, Android TV,

> etc... and they had trouble finding a good http library that worked well
> on all those platforms.

What about persuading the upstream developers of librestbed to
re-license the library under more uncontroversially DFSG-free terms
(GNU GPL or more permissive)?

Do you think there is any chance of success?


The referenced bug was closed because the OpenSSL license situation 
changed in Debian. Also, upstream version 2019-11-15 introduced 
librestinio as an alternative to restbed and the package currently 
disables building with librestbed.


So the only thing missing is removing librestbed-dev from the build 
dependencies. This keeps the package from migrating.

Bug#976362: ITP: rssguard -- simple, light and easy-to-use RSS/ATOM feed aggregator

[Norbert Preining]

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

* Package name: rssguard
  Version : 3.8.3
  Upstream Author : Martin Rotter 
* URL : https://github.com/martinrotter/rssguard
* License : GPL-3
  Programming Lang: C++
  Description : simple, light and easy-to-use RSS/ATOM feed aggregator

RSS Guard is simple, light and easy-to-use RSS/ATOM feed aggregator
developed using Qt framework which supports online feed synchronization
with these services:
 - [Tiny Tiny RSS](https://tt-rss.org),
 - [Inoreader](https://www.inoreader.com),
 - [Nextcloud News](https://apps.nextcloud.com/apps/news),
 - [Gmail API](https://developers.google.com/gmail/api).

Bug#976361: cups: Cups*-2.3.3op1-2 can not start

[Tomoo Nomura]

Package: cups
Version: 2.3.3op1-2
Severity: important

Dear Maintainer,

When upgrading to 2.3.3op1-2, cups can not start with an error "Dependency 
failed for CUPS Scheduler".

here is a log;

tom-lin@root:/etc/cups# journalctl -xe
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit cups.socket has entered the 'failed' state with result 
'start-limit-hit'.
Dec 02 19:32:29 tom-lin systemd[1]: Failed to listen on CUPS Scheduler.
░░ Subject: A start job for unit cups.socket has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit cups.socket has finished with a failure.
░░
░░ The job identifier is 4029 and the job result is failed.
Dec 02 19:32:29 tom-lin systemd[1]: Dependency failed for CUPS Scheduler.
░░ Subject: A start job for unit cups.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit cups.service has finished with a failure.
░░
░░ The job identifier is 3927 and the job result is dependency. 

After downgrading to 2.3.3-1, it works well.


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

Kernel: Linux 5.9.0-4-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 cups depends on:
hi  cups-client2.3.3op1-2
hi  cups-common2.3.3op1-2
hi  cups-core-drivers  2.3.3op1-2
hi  cups-daemon2.3.3op1-2
ii  cups-filters   1.28.5-1
hi  cups-ppdc  2.3.3op1-2
hi  cups-server-common 2.3.3op1-2
ii  debconf [debconf-2.0]  1.5.74
ii  ghostscript9.52.1~dfsg-1
ii  libavahi-client3   0.8-3
ii  libavahi-common3   0.8-3
ii  libc6  2.31-4
hi  libcups2   2.3.3op1-2
ii  libgcc-s1  10.2.0-19
ii  libstdc++6 10.2.0-19
ii  libusb-1.0-0   2:1.0.23-2
ii  poppler-utils  20.09.0-3
ii  procps 2:3.3.16-5

Versions of packages cups recommends:
ii  avahi-daemon  0.8-3
ii  colord1.4.4-2

Versions of packages cups suggests:
hi  cups-bsd   2.3.3op1-2
pn  cups-pdf   
ii  foomatic-db-compressed-ppds [foomatic-db]  20200820-1
ii  smbclient  2:4.12.5+dfsg-3
ii  udev   246.6-4

-- debconf information excluded

Bug#710178: groff-base: some warnings now split on several lines, makes lintian reports useless

[G. Branden Robinson]

package groff-base
tag 710178 + fixed-upstream
thanks

This has been fixed in groff's Git repository and is expected in the
1.23.0 release.


signature.asc
Description: PGP signature

Bug#660512: CAN I TRUST YOU???

[philip Robbins]

Vážený pane,

Jsem nucen vznést tento velmi duležitý požadavek prostrednictvím tohoto mediánu 
kvuli jeho naléhavosti a duverné povaze. Jmenuji se Philip Robbins, právník ve 
Španelsku. Zastupuji Late Engr. Stefan, který byl bohatým obchodníkem pred svou 
smrtí v roce 2015. Sveruji se vám ve velmi zásadní záležitosti týkající se 
obrovského vkladu, který tento muj klient pred jeho smrtí udelal. Žádám o váš 
souhlas s oprávnením, abych vás mohl predstavovat jako príbuzného zesnulého a 
dát pokyn jeho bance, aby vám poukázala cástku 12,5 milionu USD uloženou na 
pozastaveném bankovním úctu. Depozitárská banka me poverila jako svého 
právníka, abych do konce roku predstavil svého dedice, abych požádal o uvolnení 
tohoto fondu, jinak mu banka bude zabavena, a proto je treba vás kontaktovat o 
pomoc. Rozhodl jsem se získat tento fond a použít jeho cást pro charitativní 
práci ve prospech méne privilegovaných a sirotcincu místo toho, abych mu 
umožnil jít do rukou nekterých zkorumpovaných vysokých bankovních úredníku, 
kterí jej nakonec použijí pro svuj osobní sobecký zájem .

Rozhodl jsem se, že bychom meli dát ctyricet procent fondu jakékoli charite 
podle našeho výberu, zatímco zbývajících šedesát procent sdílíme rovnomerne 
(každý po triceti procentech) za naši cestnou úcast a úsilí. Spoléhám na vás s 
úspechem této transakce. Chci, abyste vedeli, že to deláte v zásade z 
humanitárních duvodu a budete požehnáni.
Upozornujeme, že tato zamýšlená transakce bude provedena zákonným zpusobem, 
který vás ochrání pred jakýmkoli porušením zákona. Využiji svoji pozici 
právníka klienta k zajištení úspechu transakce. Dám vám více podrobností, až se 
mi ozvete /

S pozdravem,
Philip Robbins (ESQ.)
(Rodinné právo, dedictví a zprostredkování)
KANCELÁR: Haag, Nizozemsko

Bug#976191: texlive-latex-base: Fails to build formats for LaTeX

[Norbert Preining]

Hi Hilmar,

> > filemove;texlive-latex-recommended;texlive-latex-base;2020.20201203
> > 
> Done.

Thanks.

> Source packages are here, I'll upload tomorrow just texlive-base, changes
> are on github. I can confirm that the change solves the issue.

Perfect, thanks for testing.

But be aware, that there might be further moves coming again reverting
this change (yes, I know the pain), since LaTeX upstream is doing this:
https://github.com/latex3/latex2e/issues/450

Best

> I'll keep that in mind, soft freeze is on 2021-02-12, so maybe upload
> another snapshot on mid January to make sure all bugs are found before
> 2021-02-12.

Sounds good to me.

Thanks for all your work!

Best

Norbert

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

Bug#976285: please enable redis plugin

[Dmitry Smirnov]

On Thursday, 3 December 2020 6:12:01 PM AEDT Felix Zielcke wrote:
> So what's missing to enable Agent 2?

I think Agent 2 is not the issue.


> zabbix_get [2294402]: Check access restrictions in Zabbix agent
> configuration

Agent will only respond to requests from hosts listed in "Server=".

-- 
Regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Every new set of discoveries raises a host of questions which we were never
before wise enough even to ask.
-- Carl Sagan

---

The Seven-Step Path from Pandemic to Totalitarianism There are just seven
steps from pandemic declaration to permanent totalitarianism – and many
jurisdictions are about to start Step 5.
-- 
https://off-guardian.org/2020/04/23/the-seven-step-path-from-pandemic-to-totalitarianism


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

Bug#976360: gdcm: Doesn't build on ports without java

[Samuel Thibault]

Source: gdcm
Version: 3.0.7-3
Severity: important
Tags: patch

Hello,

gdcm currently doesn't build on ports that don't have java. The attached
patch fixes this simply by copying over the java-enabled arch list from
the libgdcm-java package to the libvtkgdcm-java package.

Samuel

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

Kernel: Linux 5.9.0-3-amd64 (SMP w/8 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

-- 
Samuel
...
 et Ctrl alt F2 pour aller sous console
 mais c koi pour passer d'un bureau a un autre !
 au fait c koi le raccourci pour passer d'un bureau a un autre 'question 
stupide"
 ça dépend du window manager et de ta conf
 ce qui fonctionne toujours c'est CTRL-ALT-BCKSP
-:- SignOff rv_: #linuxfr (Read error: EOF from client)
-:- rv_ [~rv@217.11.166.169] has joined #linuxfr
 Firebird: MEURT...
--- debian/control.original 2020-12-03 23:24:37.0 +
+++ debian/control  2020-12-03 23:24:40.0 +
@@ -229,7 +229,7 @@
  GDCM from Java environment.
 
 Package: libvtkgdcm-java
-Architecture: any
+Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x alpha 
ia64 m68k powerpc ppc64 riscv64 sh4 sparc64 x32
 Section: java
 Depends: ${shlibs:Depends},
  ${misc:Depends},

Bug#879942: [Pkg-ayatana-devel] Bug#879942: libqtdbusmock: FTBFS on mips: DBus.Error.BadAddress: '=' character not found

[Mike Gabriel]

Control: close -1
Control: fixed -1 0.7+bzr49+repack1-5

Hi,

On  Fr 27 Okt 2017 15:37:25 CEST, Aaron M. Ucko wrote:


Source: libqtdbusmock
Version: 0.7+bzr49+repack1-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-m...@lists.debian.org

The mips build of libqtdbusmock failed with BadAddress DBusExceptions
like those observed in #879937, which libqtdbutest managed to escape
there, per the below excerpts from
https://buildd.debian.org/status/fetch.php?pkg=libqtdbusmock=mips=0.7%2Bbzr49%2Brepack1-1=1509015569=0

Could you please take a look?

Thanks!



Running tests...
/usr/bin/ctest --force-new-ctest-process -j4
Test project /<>/libqtdbusmock-0.7+bzr49+repack1/obj-mips-linux-gnu
Start 1: unit-tests
1/1 Test #1: unit-tests ...***Failed   62.90 sec
[==] Running 8 tests from 1 test case.
[--] Global test environment set-up.
[--] 8 tests from TestDBusMock
[ RUN  ] TestDBusMock.StartsDBusMockSession
Traceback (most recent call last):
  File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/dbusmock/__main__.py", line  
81, in 

bus = dbusmock.testcase.DBusTestCase.get_dbus(args.system)
  File "/usr/lib/python3/dist-packages/dbusmock/testcase.py", line  
150, in get_dbus

return dbus.bus.BusConnection(os.environ['DBUS_SESSION_BUS_ADDRESS'])
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 122, in __new__
bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException:  
org.freedesktop.DBus.Error.BadAddress: '=' character not found or  
has no value following it

unknown file: Failure
C++ exception with description "Process [python3] for service  
[test.name] failed to appear on bus" thrown in the test body.

[  FAILED  ] TestDBusMock.StartsDBusMockSession (14849 ms)
[...]
[ RUN  ] TestDBusMock.GetMethodCalls
Traceback (most recent call last):
  File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/dbusmock/__main__.py", line  
81, in 

bus = dbusmock.testcase.DBusTestCase.get_dbus(args.system)
  File "/usr/lib/python3/dist-packages/dbusmock/testcase.py", line  
150, in get_dbus

return dbus.bus.BusConnection(os.environ['DBUS_SESSION_BUS_ADDRESS'])
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 122, in __new__
bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException:  
org.freedesktop.DBus.Error.BadAddress: '=' character not found or  
has no value following it

unknown file: Failure
C++ exception with description "Process [python3] for service  
[test.name] failed to appear on bus" thrown in the test body.

[  FAILED  ] TestDBusMock.GetMethodCalls (15257 ms)
[ RUN  ] TestDBusMock.GetAllMethodCalls
Traceback (most recent call last):
  File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/dbusmock/__main__.py", line  
81, in 

bus = dbusmock.testcase.DBusTestCase.get_dbus(args.system)
  File "/usr/lib/python3/dist-packages/dbusmock/testcase.py", line  
150, in get_dbus

return dbus.bus.BusConnection(os.environ['DBUS_SESSION_BUS_ADDRESS'])
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 122, in __new__
bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException:  
org.freedesktop.DBus.Error.BadAddress: '=' character not found or  
has no value following it

unknown file: Failure
C++ exception with description "Process [python3] for service  
[test.name] failed to appear on bus" thrown in the test body.

[  FAILED  ] TestDBusMock.GetAllMethodCalls (15001 ms)
[ RUN  ] TestDBusMock.AddMethods
Traceback (most recent call last):
  File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/dbusmock/__main__.py", line  
81, in 

bus = dbusmock.testcase.DBusTestCase.get_dbus(args.system)
  File "/usr/lib/python3/dist-packages/dbusmock/testcase.py", line  
150, in get_dbus

return dbus.bus.BusConnection(os.environ['DBUS_SESSION_BUS_ADDRESS'])
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 122, in __new__
bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException:  
org.freedesktop.DBus.Error.BadAddress: '=' character not found or  
has no value following it

unknown file: Failure
C++ exception with 

Bug#879937: [Pkg-ayatana-devel] Bug#879937: Bug#879937: libqtdbustest: FTBFS: unit test fails with BadAddress DBusException

[Mike Gabriel]

Control: fixed -1 0.2+bzr42+repack1-11
Control: close -1

On  Mo 30 Apr 2018 12:56:17 CEST, Mike Gabriel wrote:

I really need a way to reproduce the test failures on my local setup  
(sbuild).


This bug (#879937) has finally been resolved. By bumping DH compat  
level to version 13 (and thus working around the  
libpam-systemd/schroot problem that XDG_RUNTIME_DIR does not get  
assigned properly).


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

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



pgpZy9uTPP27I.pgp
Description: Digitale PGP-Signatur

Bug#976191: texlive-latex-base: Fails to build formats for LaTeX

[Hilmar Preuße]

Am 03.12.2020 um 06:21 teilte Norbert Preining mit:

Hi Norbert,


@Norbert: could fix this in upstream?


l3packages has moved from collection-latexrecommended to
collection-latex in svn 57048.


Great, thanks!


Thus, a new checkout with the respective
filemove;texlive-latex-recommended;texlive-latex-base;2020.20201203
needs to be added to tpm2deb.cfg, and rebuilt.


Done.

Source packages are here, I'll upload tomorrow just texlive-base, 
changes are on github. I can confirm that the change solves the issue.



It might be worth at some point (before the freeze), to also push the
cross TeX Live dependencies:
latest-version;texlive-bin;2020.20200327
texlive-base-version;2020.20200417
latest-version;texlive-base;2020.20200417
latest-version;texlive-extra;2020.20200417
latest-version;texlive-lang;2020.20200417
and move all of them forward to the latest version to ensure that there
is no squeeze in the installed packages.

I'll keep that in mind, soft freeze is on 2021-02-12, so maybe upload 
another snapshot on mid January to make sure all bugs are found before 
2021-02-12.


Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#918917: Please add Firefox to the favorites

[Norbert Preining]

Hi all,

since I am preparing 4.8 packages for unstable, I would love to get this
sorted out:

On Sun, 22 Nov 2020, Fabio Fantoni wrote:
> @Norbert @Maxy: what do you think is the better do? I think would be
> good have default favorite working in both debian stable/testing (with
> only firefox-esr) and ubuntu and derivates (with only firefox)

In this case it would be good - and if it isn't a problem - to simply
add *both* to the favorites, and only the one present will be shown.

Fabio, could you commit the respective change to the experimental
branch, please?

> cinnamon-desktop-environment actually have gnome-terminal as default and
> x-terminal-emulator as alternative (that include xfce4-terminal)

On Sun, 22 Nov 2020, Paul van der Vlis wrote:
> Hmm, you are right. But the menu does not show it. Maybe because of:
> OnlyShowIn=GNOME;Unity;
> in /usr/share/applications/org.gnome.Terminal.desktop
> So maybe better to use another terminal?

I suggest mate-terminal. It should show up in cinnamon (when I used it
it did). Again, Fabio, if you could push these changes to experimental
that would be great.

Thanks

Norbert

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

Bug#976359: debian-history: reproducible builds: Embedded timestamps in various documentation files

[Vagrant Cascadian]

Source: debian-history
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps timezone
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Several .pdf, .html, .txt and .epub files shipped in debian-history
embed the build date:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/debian-history.html

  /usr/share/doc/debian-history/docs/project-history.es.pdf
  4011·de·diciembre 40  9·de·noviembre
  41de·2021 41  de·2020

The two attached patches fix these issues, one by setting PUBDATE to use
UTC in debian/rules, and the other by setting FORCE_SOURCE_DATE=1 in
debian/rules, which texlive needs in order to respect SOURCE_DATE_EPOCH,
which is set during debian package builds to the timestamp in the latest
debian/changelog entry.

  https://reproducible-builds.org/docs/source-date-epoch/

These patches unfortunately do not fix all reproducibility issues in
debian-history; There are randomized bookid identifiers in the .epub
files I have not yet figured out how to fix, but will make it a little
easier to debug the remaining issues once the patches are applied.


live well,
  vagrant
From 34abded4cd0e9206eef2ac9cd0215a0ed5d1 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 3 Dec 2020 14:06:34 -0800
Subject: [PATCH 1/2] debian/rules: Use UTC for PUBDATE.

Without this, the timezone of the system can result in unreproducible
builds.

  https://reproducible-builds.org/docs/timezones/
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 2cdebb8..b4e2c2a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,7 +8,7 @@ include /usr/share/dpkg/pkg-info.mk
 # version of this Debian package (debian/changelog)
 PUBVERSION := $(DEB_VERSION)
 # short date of this Debian package (debian/changelog)
-PUBDATE := $(shell { date +'%Y-%m-%d' -d"@$(SOURCE_DATE_EPOCH)" ; })
+PUBDATE := $(shell { date +'%Y-%m-%d' --utc -d"@$(SOURCE_DATE_EPOCH)" ; })
 
 export PUBVERSION
 export PUBDATE
-- 
2.20.1

From 33f260b5e63dbad4886c79616b48c415a4b292cb Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 3 Dec 2020 14:09:53 -0800
Subject: [PATCH 2/2] debian/rules: Set FORCE_SOURCE_DATE=1 in order for
 texlive to respect SOURCE_DATE_EPOCH for reproducible timestamps.

https://reproducible-builds.org/docs/source-date-epoch/
---
 debian/rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/rules b/debian/rules
index b4e2c2a..92d5d65 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,6 +12,8 @@ PUBDATE := $(shell { date +'%Y-%m-%d' --utc -d"@$(SOURCE_DATE_EPOCH)" ; })
 
 export PUBVERSION
 export PUBDATE
+# Needed for texlive to respect SOURCE_DATE_EPOCH when setting date
+export FORCE_SOURCE_DATE=1
 
 ## --
 ## uncomment this to turn on verbose mode
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#976358: [bts] failed to open SMTP connection to reportbug.debian.org

[Picca Frédéric-Emmanuel]

Package: devscripts
Version: 2.20.5
Severity: normal
File: /usr/bin/bts
X-Debbugs-Cc: pi...@debian.org


Hello, while trying to use tagpending on one of my packages, I got this error 
message

$ tagpending
tagpending info: tagging these bugs pending: 975709
bts: failed to open SMTP connection to reportbug.debian.org
(SSL connect attempt failed error:1416F086:SSL 
routines:tls_process_server_certificate:certificate verify failed)

Cheers

-- Package-specific info:

--- /etc/devscripts.conf ---
BTS_SMTP_HOST=reportbug.debian.org

--- ~/.devscripts ---
Empty.

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
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 devscripts depends on:
ii  dpkg-dev  1.20.5
ii  fakeroot  1.25.3-1.1
ii  file  1:5.39-3
ii  gnupg 2.2.20-1
ii  gnupg22.2.20-1
ii  gpgv  2.2.20-1
ii  libc6 2.31-5
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.11-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.004004-1
ii  libwww-perl   6.49-1
ii  patchutils0.4.2-1
ii  perl  5.32.0-5
ii  python3   3.9.0-3
ii  sensible-utils0.0.12+nmu1
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.1.12
ii  curl7.72.0-1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2020.09.24
ii  dput-ng [dput]  1.31
ii  equivs  2.3.1
ii  libdistro-info-perl 0.24
ii  libdpkg-perl1.20.5
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.25-2
ii  liblist-compare-perl0.55-1
ii  liblwp-protocol-https-perl  6.09-1
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 5.05-1
ii  licensecheck3.0.47-1
ii  lintian 2.104.0
ii  man-db  2.9.3-2
ii  patch   2.7.6-6
ii  pristine-tar1.49
ii  python3-apt 2.1.6
ii  python3-debian  0.1.38
ii  python3-magic   2:0.4.15-5
ii  python3-requests2.24.0+dfsg-1
ii  python3-unidiff 0.5.5-2
ii  python3-xdg 0.26-3
ii  strace  5.5-3
ii  unzip   6.0-25
ii  wget1.20.3-1+b3
ii  xz-utils5.2.4-1+b1

Versions of packages devscripts suggests:
ii  adequate 0.15.3
ii  at   3.1.23-1.1
ii  autopkgtest  5.15
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-2
ii  build-essential  12.8
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.2.1
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
ii  gnuplot  5.4.0+dfsg1-1
ii  gnuplot-qt [gnuplot] 5.4.0+dfsg1-1
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-2
ii  libnet-smtps-perl0.10-1
pn  libterm-size-perl
ii  libtimedate-perl 2.3300-1
pn  libyaml-syck-perl
ii  mailutils [mailx]1:3.10-3+b1
pn  mmdebstrap   
pn  mozilla-devscripts   
ii  mutt 2.0.2-1
ii  openssh-client [ssh-client]  1:8.4p1-3
ii  piuparts 1.1.1
pn  postgresql-client
ii  quilt0.66-2.1
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
ii  w3m  0.5.3-38+b1

-- no debconf information

Bug#971570: [Pkg-julia-devel] Bug#971570: Bug#971570: Bug#971570: julia: libgit2 1.0 transition

[Norbert Preining]

Hi Ximin,

> In October I did a build which failed with SEGV:

as you said, rather unrelated to libgit. Tests are working now on as
many architectures we could fix them.

> In the meantime I will let the release team know not to block the libgit2 
> transition on julia.

Thanks

Best

Norbert

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

Bug#970428: Prepared new packages for cheggaaa/pb (v1 + v3)

[Andreas Henriksson]

Hello,

As already discussed in ITP #970428 I've been pondering packaging
v3 of what was initially called github.com/cheggaaa/pb later replaced
by gopkg.in/cheggaaa/pb.v1 (and v2) and is now again back under the
initial github.com/cheggaaa/pb import path again as both v1 and v3.

I've prepared an updated package in git[1] under the original name again
now including both v1 and the new v3. The new package
Provides, Replaces and Conflicts with golang-gopkg-chegga-pb.v1.
I've also added both import paths to debian/control and symlinked
the gopkg one to the new/original path.

I would be really happy if someone could review this and tell me
if/what I messed up.

I've personally only (so far) tested building the new upstream release
of mender-cli (v1.5.0) which needs cheggaaa/pb v3 as well as the
currently shipped debian package of mender-cli (v1.4.0) which uses
cheggaaa/pb v1 (with the original github.com/cheggaaa/pb import path).
(I will likely need to test another package which uses the gopkg.in
import path for v1 for full coverage.)

Your review comments about this would be greatly appreciated!

ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970428
[1]: https://salsa.debian.org/go-team/packages/golang-github-cheggaaa-pb

Regards,,
Andreas Henriksson

Bug#731082: Processed: severity of 731082 is normal

[Florian Weimer]

forwarded 731082 https://sourceware.org/bugzilla/show_bug.cgi?id=27008
tags 731082 + upstream
thanks

I happen to have a patch for this:



A bit by accident, it ended up as part of the glibc-hwcaps work.

Bug#976235: enlightenment: e switches off screen|monitor

[Ross Vandegrift]

On Thu, Dec 03, 2020 at 09:44:38PM +0100, enno wrote:
> This time after switching to blind VT2 it took several seconds, about 10, and 
> all of a sudden the VT switched back to live--my first trials to solve this 
> riddle included once waiting for more than 10 mins and nothing happened.  Now 
> I tried Alt-F7 and had half a second of something looking very much like 
> enlightenment--and then the screen went black again, including all VTs.
> 
> What is enlightenment_system and enlightenment_fm?  They don't have manpages 
> and they don't accept -h or --help. _fm says:
 
enlightenment_system implements privileged actions so enlightnement
doesn't need root to e.g. shutdown the system.

enlightenment_fm implements the file manager.

> If it is of help, here's the .xsession-errors from the most recent "crashed" 
> e-launch:

This is usually the most useful info.

[snip]
> ESTART: 1.98189 [0.2] - Screens Init
> ESTART: 1.98190 [0.2] -   screens: client
> ESTART: 1.98196 [0.6] - E_Screensaver Init
> ESTART: 1.98199 [0.2] -   screens: client volume
> ESTART: 1.98201 [0.2] -   screens: win
> ESTART: 2.05413 [0.07213] - Compositor Init
> RRR: . info get!
> RRR:  out LVDS
> RRR: .. lid_closed = 0 (1 && 0)
> RRR: .. connected 1
> RRR: .. modes 0x230a8c0
> RRR: 'LVDS' 0 0 1600x900
> RRR:  out DisplayPort-0
> RRR: .. lid_closed = 0 (0 && 0)
> RRR: .. connected 0
> RRR: .. modes (nil)
> RRR:  out DisplayPort-1
> RRR: .. lid_closed = 0 (0 && 0)
> RRR: .. connected 0
> RRR: .. modes (nil)
> RRR:  out DisplayPort-2
> RRR: .. lid_closed = 0 (0 && 0)
> RRR: .. connected 0
> RRR: .. modes (nil)
> RRR:  out VGA-0
> RRR: .. lid_closed = 0 (0 && 0)
> RRR: .. connected 0
> RRR: .. modes (nil)

This output shows that X has detected five outputs, and only one (LVDS)
is connected.

Do you have the lid closed on your laptop?  I wonder if it's running on
the closed laptop screen.  The later output about screen configuration
only shows actions for LVDS.

> BTW I'm writing this on flwm which works perfectly but just isn't e,
> especially not MY e.

Since other windows managers are able to start X normally, it might be
useful to see if you can start one yourself:

1) From a VT run `startx xterm` (or whatever terminal you use).
2) Assuming X starts correctly, you should see a terminal in the top
left.
3) Move the mouse in the term and run `enlightenment_start`.

Ross

Bug#976095: linux-image-amd64: kernel crash refcount_t: underflow; use-after-free.

[Salvatore Bonaccorso]

Hi Xavier,

On Sun, Nov 29, 2020 at 06:32:36PM +0100, Xavier Chantry wrote:
> Package: linux-image-amd64
> Version: 5.8.10-1~bpo10+1
> Severity: important
> 
> Version 5.8.10-1~bpo10+1 contains a critical bug that completely freezes the
> system with a very basic LibreOffice usage.
> This is apparently fixed here :
> https://www.mail-archive.com/nouveau@lists.freedesktop.org/msg36460.html
> 
> This patch appears in debian linux 5.9.9-1, so we are just waiting for a
> backport in buster-backports to confirm the fix.

Can you fetch the package from testing to confirm it fixes the issue
you are seeing so we can adjust the bug metadata accordingly?

Regards,
Salvatore

Bug#975874: buster-pu: package openjdk-11/11.0.9.1+1-1~deb10u1

[Thorsten Glaser]

On Thu, 3 Dec 2020, tony mancill wrote:

> Given that the JVM bug can affect any application seems to tilt the
> scale towards proceeding with the JDK update, so the release of an
> upgrade path for Jenkins is a relief.

How about versioning it differently? Make it 11.0.9-2 for a while?
Convince upstream to re-release it as 11.0.10 and stop using so
many periods in a version number (IMHO one is enough and two is
already questionable)?

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.

*

Bug#891561: librsvg2-2: With librsvg2-2 version 2.40.20 no svg-images are shown

[Simon McVittie]

On Thu, 03 Dec 2020 at 22:55:21 +0200, Martin-Éric Racine wrote:
> On this host (Geode LX800 i.e. an i686 minus PAE), the SVG library
> flat out crashes

It seems unlikely that this is the same bug that the original submitter
of #891561 had in 2018, since they were using an amd64 system and the
symptoms they describe (although relatively vague) do not include a crash.
Please report this separately.

If 2.40.x works and 2.44.x doesn't, that's consistent with the theory
that the rust compiler is emitting opcodes not supported by your CPU, since
librsvg 2.40.x was C code and 2.44.x was at least partially Rust.

smcv

Bug#976357: RFS: pysolfc/2.10.1-1 -- collection of more than 1000 solitaire card games

[Juhani Numminen]

Package: sponsorship-requests
Severity: normal
Control: block -1 by 976353

Dear mentors,

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

 * Package name: pysolfc
   Version : 2.10.1-1
   Upstream Author : Shlomi Fish, https://www.shlomifish.org/
 * URL : https://pysolfc.sourceforge.io/
 * License : TILE, TCL, GFDL-NIV, GPL-3+, FR, GPL-2+
 * Vcs : https://salsa.debian.org/games-team/pysolfc
   Section : games

It builds those binary packages:

  pysolfc - collection of more than 1000 solitaire card games

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pysolfc/pysolfc_2.10.1-1.dsc

Changes since the last upload:

 pysolfc (2.10.1-1) unstable; urgency=medium
 .
   * New upstream version 2.10.1.
 - Hanafuda card stacks have been fixed (Closes: #859047).
   * debian/patches: Refresh patches for new upstream release, remove merged 
ones
   * debian/control:
 - Add build-depends python3-setuptools and python3-attr.
 - Add build-depends and depends python3-pysol-cards.
 - Bump policy to 4.5.1.
   * Switch to debhelper-compat 13. "nocheck" test can be dropped in d/rules.
   * debian/rules:
 - Run unit tests.
 - override_dh_auto_build: Utilize upstream Makefile more.
   * Path usr/share/games/pysolfc/html must not be symlink to usr/share/doc/...
 The game will not function if the files are removed (Policy §12.3).
 Remove /usr/share/doc/pysolfc/html because dpkg makes it hard to keep both
 paths while changing symlink to dir.
   * Remove debian/doc-base. No HTML docs in /usr/share/doc anymore
 (lintian: doc-base-file-references-wrong-path).
   * debian/docs: Update list of useful documentation.
   * debian/clean: Update comments, add po/de.po.

Regards,
--
  Juhani Numminen

Bug#966653: same version of grpc rubygem from rubygems.org works

[Maximilian Stein]

Has there actually been any progress on these issues? With the latest 
update of gitlab I'm now forced to use the flawed versions of 
ruby-google-protobuf and ruby-grpc that keep on crashing ruby and rake 
processes... Before, I used to downgrade these packages after each 
upgrade as described above, but now the dependency of gitab is explicit.


Is there any workaround now?


Thanks for your help!

Best

Max

Bug#976356: biboumi: new upstream release 9.0

[Kim Alvefur (Zash)]

Package: biboumi
Version: 8.3-1
Severity: wishlist

Dear Maintainer,

A new upstream release of biboumi is available:
https://lab.louiz.org/louiz/biboumi/-/blob/9.0/CHANGELOG.rst

Packaging it would be greatly appreciated.

-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages biboumi depends on:
ii  adduser   3.118
ii  libbotan-2-9  2.9.0-2
ii  libc6 2.28-10
ii  libexpat1 2.2.6-2+deb10u1
ii  libgcc1   1:8.3.0-6
ii  libidn11  1.33-2.2
ii  libpq511.9-0+deb10u1
ii  libsqlite3-0  3.27.2-3
ii  libstdc++68.3.0-6
ii  libsystemd0   241-7~deb10u4
ii  libudns0  0.4-1+b1
ii  libuuid1  2.33.1-0.1

biboumi recommends no packages.

biboumi suggests no packages.

Bug#958169: lxterminal: diff for NMU version 0.3.2-1.1

[Mattia Rizzolo]

Control: tags 958169 + patch
Control: tags 958169 + pending


Dear maintainer,

I've prepared an NMU for lxterminal (versioned as 0.3.2-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
regards,
Mattia Rizzolo

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

 changelog |   11 ++
 lxterminal.prerm  |4 +-
 patches/fix-non-recognized-URLs.patch |   58 ++
 patches/series|1 
 rules |3 -
 5 files changed, 72 insertions(+), 5 deletions(-)

diff -Nru lxterminal-0.3.2/debian/changelog lxterminal-0.3.2/debian/changelog
--- lxterminal-0.3.2/debian/changelog	2018-09-23 03:07:58.0 +0200
+++ lxterminal-0.3.2/debian/changelog	2020-12-03 22:23:21.0 +0100
@@ -1,3 +1,14 @@
+lxterminal (0.3.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch from upstream to fix highlighting of URLs that was broken after
+VTE 0.60.  Closes: #958169
+  * Drop --dbgsym-migration option from dh_strip, the migration is long done.
+  * Remove the alternative only on remove, so not to drop manual selections
+users might have set during upgrades.
+
+ -- Mattia Rizzolo   Thu, 03 Dec 2020 22:23:21 +0100
+
 lxterminal (0.3.2-1) unstable; urgency=medium
 
   * New upstream release:
diff -Nru lxterminal-0.3.2/debian/lxterminal.prerm lxterminal-0.3.2/debian/lxterminal.prerm
--- lxterminal-0.3.2/debian/lxterminal.prerm	2018-09-23 03:07:58.0 +0200
+++ lxterminal-0.3.2/debian/lxterminal.prerm	2020-09-05 04:01:34.0 +0200
@@ -3,11 +3,11 @@
 set -e
 
 case "${1}" in
-	remove|upgrade|deconfigure)
+remove)
 		update-alternatives --remove x-terminal-emulator /usr/bin/lxterminal
 		;;
 
-	failed-upgrade)
+	upgrade|failed-upgrade|deconfigure)
 
 		;;
 
diff -Nru lxterminal-0.3.2/debian/patches/fix-non-recognized-URLs.patch lxterminal-0.3.2/debian/patches/fix-non-recognized-URLs.patch
--- lxterminal-0.3.2/debian/patches/fix-non-recognized-URLs.patch	1970-01-01 01:00:00.0 +0100
+++ lxterminal-0.3.2/debian/patches/fix-non-recognized-URLs.patch	2020-09-05 03:50:25.0 +0200
@@ -0,0 +1,58 @@
+From b1e3db193651b33db1e112a71ccc1e9868f37093 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ball=C3=B3=20Gy=C3=B6rgy?= 
+Date: Wed, 11 Mar 2020 10:07:58 -0400
+Subject: [PATCH] Don't use deprecated vte_terminal_match_add_gregex
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The URL highlighting feature of lxterminal breaks after updating vte3 from 0.58.3-1 to 0.60.0-1.
+VTE 0.60 removed the implementation for vte_terminal_match_add_gregex, which has been deprecated since VTE 0.46.
+
+Origin: upstream, https://github.com/lxde/lxterminal/commit/b1e3db193651b33db1e112a71ccc1e9868f37093
+Bug-Debian: https://bugs.debian.org/958169
+
+Signed-of-by: Balló György 
+Reviewed-by: Jonathan Thibault 
+---
+ src/lxterminal.c | 14 ++
+ 1 file changed, 14 insertions(+)
+
+diff --git a/src/lxterminal.c b/src/lxterminal.c
+index ac7d0fb..394f855 100644
+--- a/src/lxterminal.c
 b/src/lxterminal.c
+@@ -34,6 +34,11 @@
+ #include 
+ #include 
+ 
++#if VTE_CHECK_VERSION (0, 46, 0)
++#define PCRE2_CODE_UNIT_WIDTH 0
++#include 
++#endif
++
+ #include "lxterminal.h"
+ #include "setting.h"
+ #include "preferences.h"
+@@ -1168,12 +1173,21 @@ static Term * terminal_new(LXTerminal * terminal, const gchar * label, const gch
+ 
+ /* steal from tilda-0.09.6/src/tilda_terminal.c:145 */
+ /* Match URL's, etc. */
++#if VTE_CHECK_VERSION (0, 46, 0)
++VteRegex * dingus1 = vte_regex_new_for_match(DINGUS1, -1, PCRE2_UTF | PCRE2_NO_UTF_CHECK | PCRE2_UCP | PCRE2_MULTILINE, NULL);
++VteRegex * dingus2 = vte_regex_new_for_match(DINGUS2, -1, PCRE2_UTF | PCRE2_NO_UTF_CHECK | PCRE2_UCP | PCRE2_MULTILINE, NULL);
++gint ret = vte_terminal_match_add_regex(VTE_TERMINAL(term->vte), dingus1, 0);
++vte_terminal_match_set_cursor_type(VTE_TERMINAL(term->vte), ret, GDK_HAND2);
++ret = vte_terminal_match_add_regex(VTE_TERMINAL(term->vte), dingus2, 0);
++vte_terminal_match_set_cursor_type(VTE_TERMINAL(term->vte), ret, GDK_HAND2);
++#else
+ GRegex * dingus1 = g_regex_new(DINGUS1, G_REGEX_OPTIMIZE, 0, NULL);
+ GRegex * dingus2 = g_regex_new(DINGUS2, G_REGEX_OPTIMIZE, 0, NULL);
+ gint ret = vte_terminal_match_add_gregex(VTE_TERMINAL(term->vte), dingus1, 0);
+ vte_terminal_match_set_cursor_type(VTE_TERMINAL(term->vte), ret, GDK_HAND2);
+ ret = vte_terminal_match_add_gregex(VTE_TERMINAL(term->vte), dingus2, 0);
+ 

Bug#976355: liquidsoap: FTBFS type error in stream/frame.ml

[Ralf Treinen]

Source: liquidsoap
Version: 1.4.3-1
Severity: serious

Hi, liquidsoap fails to compile on an up-to-date amd64 sid machine:

OCAMLOPT -c stream/frame.ml
File "stream/frame.ml", line 363, characters 25-59:
363 | contents = [(!!size, create_content (type_of_kind kind))];
   ^^
Error: This expression has type
 (float array array, Video.t array, MIDI.buffer array) fields
   but an expression was expected of type
 content = (audio_t array, video_t array, midi_t array) fields
   Type float array is not compatible with type
 audio_t =
   (float, Bigarray.float32_elt, Bigarray.c_layout) Bigarray.Array1.t 

here is the output of the configure:

checking for a BSD-compatible install... /usr/bin/install -c
checking for GNU make... make
checking whether user liquidsoap exists... no
configure: WARNING: Won't be able to install log and PID directories!
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking for ocamlc... ocamlc
OCaml version is 4.11.1
checking if ocaml compiler supports first-class modules... yes
OCaml library path is /usr/lib/ocaml
checking for ocamlopt... ocamlopt
checking for ocamlc.opt... ocamlc.opt
checking for ocamlopt.opt... ocamlopt.opt
checking for ocaml... ocaml
checking for ocamldep... ocamldep
checking for ocamldep.opt... ocamldep.opt
checking for ocamlmktop... ocamlmktop
checking for ocamlmklib... ocamlmklib
checking for ocamldoc... ocamldoc
checking for ocamldoc.opt... ocamldoc.opt
checking for ocamlbuild... ocamlbuild
checking for camlidl... camlidl
checking for ocamllex... ocamllex
checking for ocamllex.opt... ocamllex.opt
checking for ocamlyacc... ocamlyacc
checking for camlp4... camlp4
checking for camlp4boot... camlp4boot
checking for camlp4o... camlp4o
checking for camlp4of... camlp4of
checking for camlp4oof... camlp4oof
checking for camlp4orf... camlp4orf
checking for camlp4prof... camlp4prof
checking for camlp4r... camlp4r
checking for camlp4rf... camlp4rf
checking for ocamlfind... ocamlfind
checking for ocaml standard library path... /usr/lib/ocaml
checking for caml/threads.h... yes
checking whether ocamlopt accepts -ffast-math... no
checking for ocamlc version... 4.11.1
checking for ocaml bytes module... ok
checking for ocaml pcre module... ok
checking for ocaml sedlex module >= 2.0... ok
checking for ocaml menhirLib module... ok
checking for ocaml dtools module >= 0.4.0... ok
checking for ocaml duppy module >= 0.6.0... ok
checking for ocaml cry module >= 0.6.0... ok
checking for ocaml mm module >= 0.5.0... ok
checking for ocaml xmlplaylist module >= 0.1.3... ok
checking for ocaml lastfm module >= 0.3.0... ok
checking for ocaml ogg module >= 0.5.0... ok
checking for ocaml vorbis module >= 0.7.0... ok
checking for ocaml opus module >= 0.1.3... ok
checking for ocaml speex module >= 0.2.1... ok
checking for ocaml mad module >= 0.4.4... ok
checking for ocaml flac module >= 0.1.5... ok
checking for ocaml flac.ogg module... ok
checking for ocaml dynlink module... ok
checking whether ocaml compiler supports dynlink... yes
checking for ocaml lame module >= 0.3.2... ok
checking for ocaml shine module >= 0.2.0... ok
checking for ocaml gstreamer module >= 0.3.0... ok
checking for ocaml frei0r module >= 0.1.0... ok
checking for ocaml fdkaac module >= 0.3.1... Not found.
checking for ocaml theora module >= 0.3.1... ok
checking for ocaml gavl module >= 0.1.4... ok
checking for ocaml ffmpeg module >= 0.4.1... ok
checking for ocaml bjack module >= 0.1.3... ok
checking for ocaml alsa module >= 0.2.1... ok
checking for ocaml ao module >= 0.2.0... ok
checking for ocaml samplerate module >= 0.1.1... ok
checking for ocaml taglib module >= 0.3.0... ok
checking sys/soundcard.h usability... yes
checking sys/soundcard.h presence... yes
checking for sys/soundcard.h... yes
checking for ocaml ssl module >= 0.5.2... ok
checking for ocaml osx-secure-transport module... Not found.
checking for ocaml magic module... ok
checking for ocaml camomile module >= 1.0.0... ok
checking for ocaml inotify module >= 1.5... ok
checking for ocaml yojson module... ok
checking 

Bug#976354: git - tests fail with dash

[Bastian Blank]

Package: git
Version: 1:2.29.2-1
Severity: serious

Some of the tests fail with dash, which is the default /bin/sh in
Debian.

Example:

| bbl@debian-sid:~/git-2.29.2+next.20201030/t$ bash ./t3070-wildmatch.sh | tail 
-n 3
| # still have 40 known breakage(s)
| # passed all remaining 1850 test(s)
| 1..1890
| bbl@debian-sid:~/git-2.29.2+next.20201030/t$ dash ./t3070-wildmatch.sh | tail 
-n 3
| # still have 28 known breakage(s)
| # failed 12 among remaining 1862 test(s)
| 1..1890

I was not able to see where exactly it's broken, but the result changes
with various options, so it might be a breakage in dash itself.

The easiest solution is to just use /bin/bash always.

Bastian

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

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

Versions of packages git depends on:
ii  git-man  1:2.29.2-1
ii  libc62.31-4
ii  libcurl3-gnutls  7.72.0-1
ii  liberror-perl0.17029-1
ii  libexpat12.2.10-1
ii  libpcre2-8-0 10.34-7
ii  perl 5.32.0-5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages git recommends:
ii  ca-certificates  20200601
ii  less 551-2
ii  openssh-client [ssh-client]  1:8.4p1-2
ii  patch2.7.6-6

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-10
ii  git-cvs   1:2.29.2-1
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
ii  gitk  1:2.29.2-1
pn  gitweb

-- no debconf information

Bug#974168: Bug #974168: bioperl-run: autopkgtest issue fixed, now different build time error

[Andreas Tille]

Control: tags -1 pending
Control: tags -1 help

Hi,

while the original issue of this bug report is fixed by adding the
missing libfile-sort-perl dependency it has a new build time error
in t/BEDTools.t.

Any help to fix this is welcome

  Andreas.

-- 
http://fam-tille.de

Bug#976353: RFS: python-pysol-cards/0.10.1-1 [ITP] -- Deal PySol FC Cards

[Juhani Numminen]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-pysol-cards":

 * Package name: python-pysol-cards
   Version : 0.10.1-1
   Upstream Author : Shlomi Fish, https://www.shlomifish.org/
 * URL : https://github.com/shlomif/pysol_cards
 * License : Apache-2.0, Expat
 * Vcs : 
https://salsa.debian.org/python-team/packages/python-pysol-cards
   Section : python

It builds those binary packages:

  python3-pysol-cards - Deal PySol FC Cards

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

  https://mentors.debian.net/package/python-pysol-cards/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-pysol-cards/python-pysol-cards_0.10.1-1.dsc

Changes for the initial release:

 python-pysol-cards (0.10.1-1) unstable; urgency=medium
 .
   * Initial release (Closes: #953574)

This Python module will be needed for the latest pysolfc, which is a collection
of 1000 solitaire games.

Regards,
--
  Juhani Numminen

Bug#976352: transition: libjsoncpp

[Gianfranco Costamagna]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal

Hello, I would like to finally do this libjsoncpp transition before freeze.
The version in sid has lots of bugs, and its really outdated.

We have ~30 reverse-dependencies, last time I checked they were all building 
fine, I'm doing test rebuilds again and will update this bug report in a day or 
two with a complete list.

Ben file:

title = "libjsoncpp";
is_affected = .depends ~ "libjsoncpp1" | .depends ~ "libjsoncpp24";
is_good = .depends ~ "libjsoncpp24";
is_bad = .depends ~ "libjsoncpp1";


thanks

Gianfranco

Bug#976310: [Pkg-javascript-devel] Bug#976310: node-compression-webpack-plugin: TypeError: (0 , _schemaUtils.validate) is not a function

[Pirate Praveen]

Control: reopen -1
Control: reassign -1 gitlab

On Thu, Dec 3, 2020 at 10:14, Xavier  wrote:

Does gitlab use `npm install` ? If so, we just have to fix
node-compression-webpack-plugin/package.json


This is indeed caused by mix of schema-utils 2 and 3. Version 2 is 
pulled by yarn and version 3 by debian.


I found a work around for now,

cd /usr/share/nodejs/compression-webpack-plugin/node_modules
ln -s /usr/share/nodejs/schema-utils/ .
cd /usr/share/nodejs/uglifyjs-webpack-plugin/node_modules
ln -s /usr/share/nodejs/schema-utils/ .
cd /usr/share/nodejs/webpack/node_modules
ln -s /usr/share/nodejs/schema-utils/ .
cd /usr/share/nodejs/cache-loader-loader/node_modules
ln -s /usr/share/nodejs/schema-utils/ .
mkdir /usr/share/nodejs/url-loader/node_modules
cd /usr/share/nodejs/url-loader/node_modules
ln -s /usr/share/nodejs/schema-utils/ .
mkdir /usr/share/nodejs/babel-loader/node_modules
cd /usr/share/nodejs/babel-loader/node_modules
ln -s /usr/share/nodejs/schema-utils/ .

I will try to get css-loader from debian working with gitlab as a 
proper fix.

Bug#891561: librsvg2-2: With librsvg2-2 version 2.40.20 no svg-images are shown

[Martin-Éric Racine]

Package: librsvg2-2
Version: 2.50.2+dfsg-1
Followup-For: Bug #891561

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On this host (Geode LX800 i.e. an i686 minus PAE), the SVG library flat out 
crashes:

[  204.840919] traps: gnome-session-f[939] trap invalid opcode ip:b4e7f86a 
sp:bfcc1460 error:0 in librsvg-2.so.2.47.0[b4e6d000+5b7000]

As a test, I downgraded all 3 packages (librsvg2-common, librsvg2-2, 
gir1.2-rsvg-2.0) to 2.44.10-2.1 from Buster/stable. Still no good.

I then downgraded to 2.40.16-1+b1 from oldstable, which shows the SVG expected 
content.

- -- 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-4-686 (SMP w/1 CPU thread)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
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 librsvg2-2 depends on:
ii  libc62.31-4
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libgcc-s110.2.0-19
ii  libgdk-pixbuf-2.0-0  2.40.0+dfsg-7
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-7
ii  libglib2.0-0 2.66.3-1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libxml2  2.9.10+dfsg-6.3

Versions of packages librsvg2-2 recommends:
ii  librsvg2-common  2.50.2+dfsg-1

Versions of packages librsvg2-2 suggests:
pn  librsvg2-bin  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAl/JULEACgkQrh+Cd8S0
17bk5w//VOynIb9LuT2IMCfNF+v59pNSLD94C/7fnkkUAYsB7kWAQUCKLmUugUfv
6EODK/BrBmDMUf+hcZ6KlAnMHZRGN5/CNFBHIiMDpq1FRl0JWe7Co0ThXlKz4Bed
9zfewZBupwr4dzs9Y9p6tyTeh8sTLbTroV4og7XwUANakRwDGGiXr4UNyBnuwpnL
OVmOlbESDDJQCfb7dSTKdbyxSin0hpJ74UlX/UtG3wGMS/glmkikoHFNidwuNrYO
kcnSRQo28mN43CdKc+Va9DLf0yWsxibs97TwbCr1BF+d33sXv5fpI5uyVXDb54iG
OID7DGMHuC0ioHUZTPvpcBaJmC/mlLtDDHRQfhEuWDcgH3oPT26cRwB1AM5SLTsx
EsLfd+9cUJuCngeuRaIdBi3W6pQ6eDaSqnOb1JMB6do60uKO9zicSzlZ2WmVIYMN
sh0jbIX03uBZc5sb8J4zw7a8iNEtgxHUdM61aILtacLq8p3Unz36mmE0B7rrDjBv
xeLmUIreJBAytHMc6+P/BKhonAZ59QAFraCH/ejF6FMe41dgS6kES/WEv1hC91lS
kJ1/ivTJkQKKz2EcHH2NS4GH5/1K00UmQrGxc210+RBlOPG9jnMcNIzK4Ws9/cr6
eU0KWdnOdFhhuBKA7yWmbsJj3dXOyzA+7+JGQ5A1iYNZ27ujyuk=
=EF24
-END PGP SIGNATURE-

Bug#973342: buster-pu: package libdbi-perl/1.642-1+deb10u2

[Xavier]

Le 03/12/2020 à 21:50, Salvatore Bonaccorso a écrit :
> Hi Xavier,
> 
> On Sun, Nov 22, 2020 at 06:14:05PM +, Adam D. Barratt wrote:
>> Control: tags -1 + confirmed
>>
>> On Thu, 2020-10-29 at 07:43 +0100, Xavier Guimard wrote:
>>> libdbi-perl is still vulnerable to CVE-2014-10401: DBD::File drivers
>>> can open files from folders other than those specifically passed via
>>> the f_dir attribute.
>>
>> +  * lib/DBD/File.pm: fix CVE-2014-10401 (Closes: #972180)
>>
>> That bug report claims to be related to CVE-2014-1040*2*, which is the
>> result of an incomplete initial fix for CVE-2014-10401.
>>
>> That seems worth clarifying, but in any case please go ahead.
> 
> Xavier, can you upload it? It won't make it though for 10.7 but can be
> batched then for the next one.
> 
> Many thanks for your work!
> 
> Regards,
> Salvatore

Sorry, I forgot to push it, done now. Many thanks!

Bug#975874: buster-pu: package openjdk-11/11.0.9.1+1-1~deb10u1

[tony mancill]

On Thu, Dec 03, 2020 at 05:34:25PM +, Adam D. Barratt wrote:
> On Thu, 2020-12-03 at 11:28 +, Adam D. Barratt wrote:
> > [adding d-java to Cc for greater visibility]
> > 
> > On Mon, 2020-11-30 at 09:21 +, Adam D. Barratt wrote:
> > > On Wed, 2020-11-25 at 20:23 -0800, tony mancill wrote:
> > > > I propose that openjdk-11 be updated to upstream 11.0.9.1+1 in
> > > > the
> > > > upcoming stable point release.  This update addresses a
> > > > regression
> > > > [1] introduced in upstream release 11.0.9+11, which is present in
> > > > buster via a security upload [2].  This keeps Debian on par with
> > > > other vendors - e.g. RedHat [3], Ubuntu [4], and AdoptOpenJDK [5]
> > > > -
> > > > and introduces the same upstream version currently available in
> > > > testing and unstable.
> > > 
> > > The versioning here appears to cause issues in at least Jenkins -
> > > see 
> > > https://issues.jenkins.io/projects/JENKINS/issues/JENKINS-64212
> > 
> > Have there been any further issues that people are aware of?
> > 
> > The Jenkins fix is not yet available to most users if I understand
> > correctly, so we need to consider the tradeoffs between the
> > regression on the OpenJDK side and requiring manual intervention on
> > Jenkins installations (and possibly other things confused by the
> > version string).
> 
> To tie up a couple of IRC conversations with Moritz, the fixed Jenkins
> versions have now been released, so we can probably just tell people
> they need to upgrade.

  I was trying to devise a moral calculus for the trade-off.

I haven't been able find any statistics about the prevalence of JVM
crashes due to the regression, and so reached out to the folks at
AdoptOpenJDK earlier today.  They said that they had seen a number of
occurrences prior to the patch.

Given that the JVM bug can affect any application seems to tilt the
scale towards proceeding with the JDK update, so the release of an
upgrade path for Jenkins is a relief.

Thank you to you and Moritz for your work on this.
tony

Bug#973414: libmozjs-78-0: invalid opcodes in libmozjs when launching GDM3

[Martin-Éric Racine]

ma 9. marrask. 2020 klo 20.05 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> su 8. marrask. 2020 klo 14.40 Simon McVittie (s...@debian.org) kirjoitti:
> > Because your syslog also included similar crashes in librsvg, which is
> > unrelated to mozjs except that both involve Rust code, I wonder whether
> > it might be the rust compiler rather than mozjs' JIT that is emitting
> > non-i586 opcodes on x86?
>
> Good observation. I'd really like to know this as well.

Seems that something broke there a while back. See bug #891561.

Martin-Éric

Bug#973342: buster-pu: package libdbi-perl/1.642-1+deb10u2

[Salvatore Bonaccorso]

Hi Xavier,

On Sun, Nov 22, 2020 at 06:14:05PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2020-10-29 at 07:43 +0100, Xavier Guimard wrote:
> > libdbi-perl is still vulnerable to CVE-2014-10401: DBD::File drivers
> > can open files from folders other than those specifically passed via
> > the f_dir attribute.
> 
> +  * lib/DBD/File.pm: fix CVE-2014-10401 (Closes: #972180)
> 
> That bug report claims to be related to CVE-2014-1040*2*, which is the
> result of an incomplete initial fix for CVE-2014-10401.
> 
> That seems worth clarifying, but in any case please go ahead.

Xavier, can you upload it? It won't make it though for 10.7 but can be
batched then for the next one.

Many thanks for your work!

Regards,
Salvatore

Bug#976235: enlightenment: e switches off screen|monitor

[enno]

> "Ross" == Ross Vandegrift  writes:
> Sounds like you found the right dialog - it is terse.  The
> options correspond to xrandr config for your displays.  Quick
> explanation:
> [...]

Thx, some of that I had been guessing by now.

> This should clear out all of your screen config, hopefully
> allowing you to start E again: rm
> ~/.e/e/config/standard/e_randr*.cfg

In fact I cleared all of my config via `rm -fr ~/.e', removed e and e-data from 
my system with aptitude and reinstalled them--no change.  I also tried good old 
`startx /usr/bin/enlightenment_start' to the same effect.  The monitor is 
switched off somehow, meaning all my virtual terminals are black, but I can 
type in commands blind on VT1 to 6.  So far I haven't been able to come up with 
a command to switch the screen back on.  I did a `ps ax' on the blind VT2 after 
logging into the blackout, i can't see anything unusual--BTW i utterly dislike 
endless attached lists of unrelated logfiles in presumed bug reports but i'm 
really at a loss here:

  PID TTY  STAT   TIME COMMAND
1 ?Ss 0:03 /sbin/init
2 ?S  0:00 [kthreadd]
3 ?I< 0:00 [rcu_gp]
4 ?I< 0:00 [rcu_par_gp]
6 ?I< 0:00 [kworker/0:0H-kblockd]
8 ?I< 0:00 [mm_percpu_wq]
9 ?S  0:00 [ksoftirqd/0]
   10 ?I  0:07 [rcu_sched]
   11 ?S  0:00 [migration/0]
   13 ?S  0:00 [cpuhp/0]
   14 ?S  0:00 [cpuhp/1]
   15 ?S  0:00 [migration/1]
   16 ?S  0:00 [ksoftirqd/1]
   18 ?I< 0:00 [kworker/1:0H-kblockd]
   19 ?S  0:00 [cpuhp/2]
   20 ?S  0:00 [migration/2]
   21 ?S  0:00 [ksoftirqd/2]
   23 ?I< 0:00 [kworker/2:0H-kblockd]
   24 ?S  0:00 [cpuhp/3]
   25 ?S  0:00 [migration/3]
   26 ?S  0:00 [ksoftirqd/3]
   28 ?I< 0:00 [kworker/3:0H-kblockd]
   29 ?S  0:00 [kdevtmpfs]
   30 ?I< 0:00 [netns]
   31 ?S  0:00 [kauditd]
   32 ?S  0:00 [khungtaskd]
   33 ?S  0:00 [oom_reaper]
   34 ?I< 0:00 [writeback]
   35 ?S  0:00 [kcompactd0]
   36 ?SN 0:00 [ksmd]
   37 ?SN 0:00 [khugepaged]
   79 ?I< 0:00 [kintegrityd]
   80 ?I< 0:00 [kblockd]
   81 ?I< 0:00 [blkcg_punt_bio]
   84 ?I< 0:00 [edac-poller]
   85 ?I< 0:00 [devfreq_wq]
   86 ?S  0:00 [kswapd0]
   87 ?I< 0:00 [kworker/u17:0-rb_allocator]
   88 ?I< 0:00 [kthrotld]
   89 ?S  0:00 [irq/26-pciehp]
   90 ?I< 0:00 [acpi_thermal_pm]
   92 ?I< 0:00 [ipv6_addrconf]
  103 ?I< 0:00 [kstrp]
  153 ?I< 0:00 [firewire]
  155 ?I< 0:00 [firewire_ohci]
  158 ?I< 0:00 [ata_sff]
  159 ?I< 0:00 [sdhci]
  161 ?S  0:00 [scsi_eh_0]
  162 ?I< 0:00 [scsi_tmf_0]
  163 ?S  0:00 [scsi_eh_1]
  164 ?I< 0:00 [scsi_tmf_1]
  165 ?S  0:00 [scsi_eh_2]
  166 ?I< 0:00 [scsi_tmf_2]
  167 ?S  0:00 [scsi_eh_3]
  168 ?I< 0:00 [scsi_tmf_3]
  169 ?S  0:00 [scsi_eh_4]
  170 ?I< 0:00 [scsi_tmf_4]
  171 ?S  0:00 [scsi_eh_5]
  172 ?I< 0:00 [scsi_tmf_5]
  173 ?I< 0:00 [e1000e]
  180 ?I< 0:00 [kworker/2:1H-kblockd]
  187 ?I< 0:00 [kworker/0:1H-kblockd]
  190 ?I< 0:00 [kworker/3:1H-kblockd]
  194 ?I< 0:00 [md]
  205 ?I< 0:00 [raid5wq]
  243 ?S  0:01 [jbd2/sda4-8]
  244 ?I< 0:00 [ext4-rsv-conver]
  251 ?I< 0:00 [kworker/1:1H-kblockd]
  294 ?Ss 0:01 /lib/systemd/systemd-journald
  298 ?I< 0:00 [rpciod]
  299 ?I< 0:00 [xprtiod]
  320 ?Ss 0:01 /lib/systemd/systemd-udevd
  362 ?I< 0:00 [tpm_dev_wq]
  365 ?S  0:00 [watchdogd]
  383 ?I< 0:00 [cfg80211]
  390 ?I< 0:00 [cryptd]
  428 ?S  2:15 [irq/40-iwlwifi]
  432 ?I< 0:00 [ttm_swap]
  493 ?Ss 0:00 /lib/systemd/systemd-networkd
  717 ?I< 0:01 [kworker/u17:1-rb_allocator]
  721 ?Ss 0:00 /sbin/wpa_supplicant -s -B -P 
/run/wpa_supplicant.wls.pid -i wls -D nl80211,wext -c 
/etc/wpa_supplicant/wpa_supplicant.conf
  737 ?Ss 0:00 /sbin/rpcbind -f -w
  738 ?Ss 0:00 /lib/systemd/systemd-resolved
  757 ?Ssl0:01 /usr/lib/accountsservice/accounts-daemon
  759 ?Ss 0:00 /usr/sbin/acpid
  760 ?SNs0:00 /usr/sbin/alsactl -E HOME=/run/alsa -s -n 19 -c 
rdaemon
  763 ?Ss 0:00 avahi-daemon: running [tapas.local]
  767 ?Ss 0:00 /usr/sbin/cron -f
  768 ?Ss 0:00 

Bug#967672: openjfx: might can do without GTK 2

[John Scott]

Control: forwarded -1 https://bugs.openjdk.java.net/browse/JDK-8198654

I'm not familiar with Java or OpenJFX, but suspect the GTK 2 build and runtime 
dependencies might can be dropped. It looks like using GTK 3 instead of GTK 2 
has been the default for a little while, so GTK 2 shouldn't be getting used 
but the choice is made at runtime.

$ ldd /usr/lib/x86_64-linux-gnu/jni/* | grep gtk
/usr/lib/x86_64-linux-gnu/jni/libglassgtk2.so:
libgtk-x11-2.0.so.0 => /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 
(0x7f262e089000)
/usr/lib/x86_64-linux-gnu/jni/libglassgtk3.so:
libgtk-3.so.0 => /lib/x86_64-linux-gnu/libgtk-3.so.0 
(0x7f9bd9d9d000)

Since GTK 3 is getting used anyway there doesn't seem to be any use disabling 
GTK 2 except for its own sake.

https://bugs.openjdk.java.net/browse/JDK-8198654
https://bugs.openjdk.java.net/browse/JDK-8229245

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

Bug#964284: guile-gnutls: update to use guile 3.0

[Vagrant Cascadian]

Control: found 964284 3.7.0-1
Control: affects 964284 guix

On 2020-07-04, Vagrant Cascadian wrote:
> The attached patch updates guile-gnutls to use guile 3.0, which is the
> current version of guile, available in unstable and bullseye. It would
> be ideal if the switch happened before bullseye was released.

This was reverted in the recent upload of 3.7.0-1. Well, mostly
reverted; the package now depends on guile-3.0 and guile-libs-2.2, but
does not ship any guile-3.0 files.

I presume this was due to build failures due to the test suite hanging
on arm64 on previous versions:

  
https://buildd.debian.org/status/fetch.php?pkg=gnutls28=arm64=3.6.15-5=1605401160=0

By process of elimination(e.g. all other tests claim to have PASSED),
the hanging test for 3.6.15-5 was:

  guile/tests/reauth.scm

I was never able to reproduce the failure locally on multiple occasions,
although once triggered a rebuild on the buildd machines that failed in
the same way.


Withouth guile-gnutls supporting guile-3.0, guix fails to build, as it
depends on guile-3.0. I could probably switch guix to guile-2.2 in the
short term, but I believe guix may soon drop support for guile-2.2, so
this issue is a significant blocker for guix.

Since several guile-* packages are largely in Debian as
build-dependencies of guix, this is also indirectly a blocker for
switching those packages to guile-3.0.


For more possibly relevent and related background:

  https://bugs.debian.org/969672 gnutls28: please upgrade to guile-3.0 soon, if 
feasible
  https://bugs.debian.org/966714 guile-gnutls: FTBFS against guile 3.0.4-1+b1


Any further ideas or help in resolving this would be much appreciated!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#976331: [Pkg-javascript-devel] Bug#976331: Bug#976331: [JS Policy] what to set in "Provides" field ?

[Xavier]

Le 03/12/2020 à 19:17, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-03 18:42:17)
>> Le 03/12/2020 à 18:21, Jonas Smedegaard a écrit :
>>> Quoting Xavier (2020-12-03 17:33:18)
 Le 03/12/2020 à 16:36, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-03 15:44:48)
>> Le 03/12/2020 à 15:12, Jonas Smedegaard a écrit :
>>> Quoting Xavier (2020-12-03 14:35:25)
 Le 03/12/2020 à 14:24, Xavier a écrit :
> Le 03/12/2020 à 12:44, Jonas Smedegaard a écrit :
>> These source packages embed nodejs module serialize-javascript 
>> without offering it as virtual binary package:
>>
>>  node-compression-webpack-plugin
>>  node-copy-webpack-plugin
>>  node-uglifyjs-webpack-plugin
>>
>> Please embed in only one source package provided as versioned 
>> virtual package, and drop in other source packages instead 
>> depending on the virtual package.
>>
>> Severity raised since the lack of virtual package blocks upgrading 
>> node-terser.
>>>
>>> [...]
>>>
> for now, dh-sequence-nodejs adds a "Provides" item for modules 
> installed in root nodejs directories. Do we want to declare a 
> "node-foo" for submodules (installed in a /node_modules 
> directory) ?
>>>
>>> Whatever that tool does, the resulting package should declare 
>>> Provides: for each embedded Nodejs module, properly versioned with 
>>> the module's own version as first segment then "~" then source 
>>> package version.
>>>
>>> I cannot see a reason for *any* embedded Nodejs module to stay 
>>> hidden, but if someone comes up with some exceptional cases for 
>>> that, then the reasoning should be explicitly documented in either 
>>> README.source or README.Debian (and possibly in long description 
>>> too).
>>
>> I chose that because such modules are not directly usable using a 
>> `require("foo")`, but I can change
>
> I am less interested in why historically some pattern was chosen.
>
> My interest is in what pattern to use going forward.
>
> Code in package have dependencies on code in other packages.
>
> We need to be able to declare dependencies between pieces of code.
>
> For JavaScript, code is grouped as "Nodejs modules".
>
> A a concrete example, Nodejs module rollup-plugin-terser depends on 
> Nodejs module serialize-javascript.
>
> Going forward (regardless of why historically some other pattern was 
> chosen), Debian package node-rollup-plugin-terser needs to be able to 
> express a build-dependency on Debian package providing the Nodejs module 
> serialize-javascript.
>
>
 Note that the future lintian database (classification tags) will 
 permit to see node modules everywhere.
>>>
>>> Everywhere?
>>
>> Sorry, I miss some explanations: lintian parses all files and emit a tag
>> each time it finds a node_module/foo/package.json or
>> /foo/package.json or > able to see nodejs embedded module in all Debian packages.
>
> Lintian can help check if a package is valid.
>
> Lintian cannot make a package declare as virtual Debian packages the 
> Nodejs modules it has embedded.
>
>
>> NB2, you can also take a look at
>> https://lintian.debian.org/tags/nodejs-module-not-declared.html : it
>> shows node module installed in nodejs main dirs (not in node_modules/
>> for now).
>
> A web page (generated by lintian or written any other way) cannot make a 
> package declare as virtual Debian packages the Nodejs modules it has 
> embedded.
>
>
>> If we decide to change this ~policy, nodejs-module-not-declared should 
>> also be updated.
>
> I am pretty sure that hiding generally usable embedded code violates a 
> "should" somewhere in Debian Policy.

 If so, lintian should reports "error", not info/warning when a JS lib is
 embedded. Ftpmasters didn't reject such packages (see jquery copies for
 example).
>>>
>>> Ideally lintian should identify and report all errors.
>>>
>>> Ideally all packaging work could be automated.
>>>
>>> Reality is slightly different. though.
>>>
>>>
>>>
> Therefore, if Debian JavaScript Policy says that generally useful 
> modules should be *hidden* instead of provided as virtual packages, then 
> I consider Debian JavaScript Policy broken.
>
>> But in this case, we will have some not-directly-usable node-* virtual 
>> packages.
>
> Why not-directly-usable?
>
> Obviously we should not _only_ declare "Provides:" but also make sure 
> that the code is actually placed in the correct location below 
> /usr/share/nodejs and check testsuite and establish autopkgtest and all 
> the other things that is required for packaging code.
>

Bug#976350: pngcheck: CVE-2020-27818

[Salvatore Bonaccorso]

Source: pngcheck
Version: 2.3.0-12
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2.3.0-7

Hi,

The following vulnerability was published for pngcheck.

CVE-2020-27818[0]:
| global buffer overflow was discovered in check_chunk_name function
| via crafted pngfile

Red Hat has a report in [1] and fixed their releases with [2].

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-27818
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27818
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1902011
[2] 
https://src.fedoraproject.org/rpms/pngcheck/blob/cc48791e34201caf7b686084b735d06cef66c974/f/pngcheck-2.4.0-overflow-bz1897485.patch

Regards,
Salvatore

Bug#976331: [Pkg-javascript-devel] Bug#976331: Bug#976331: Bug#976331: [JS Policy] what to set in "Provides" field ?

[Jonas Smedegaard]

Quoting Pirate Praveen (2020-12-03 20:09:05)
> I suggest you embed serialize-javascript in node-terser and if you 
> wish you can expose it as virtual package via Provides.

Yes, a possible solution to this issue is to introduce a 4th embedding.

That might be your understanding of keeping packaging simple.  Not mine.

That might be your understanding of team maintenance.  Not mine.


> Connecting unrelated packages together is making things complicated 
> for transitions and also increases installed packages size.

Yes, a possible solution to this issue is to introduce the embedded 
module in another package _instead_ of these three.  An example of a 
package providing tiny modules are real binary packages (which ftpmaster 
evidently had no problem accepting) is is node-file-entry-cache which 
also provides related packages node-flat-cache and node-write.  An 
example of a package providing a tiny module as virtual package is 
node-uuid also providing virtual package node-types-uuid.

Yes, another possible solution to this issue is to introduce the 
embedded module as part of a batch of related related modules, none of 
them being the "main" one (depending on the meaning of "main").  An 
example of that (evidently also acceptable to ftpmasters) is 
jsbundle-web-interfaces providing binary packages node-auth-header, 
node-standard-error, node-standard-http-error and 
node-webidl-conversions.


> Also 'should' is not 'must' in policy.

And apples are not oranges.

If you meant to put words into my mouth, then please don't.


 - 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#976349: libavif-bin: no encoder codec, making avifenc useless

[Nicolas George]

Package: libavif-bin
Version: 0.8.3-3
Severity: important

~ $ avifenc -h | grep Version
Version: 0.8.3 (dav1d [dec]:0.7.1, libgav1 [dec]:0.16.1)

Notice two [dec] but no [enc]. It makes the avifenc binary useless. If
it cannot be made to work, better make it clear from the start,
including in the package description.

IIUC, libgav1 can encode, but but libavif cannot use it, only aom, rav1e
and svt. See struct AvailableCodec availableCodecs in src/avif.c.

Regards,

-- 
  Nicolas George


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

Kernel: Linux 5.9.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=C, 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)

Versions of packages libavif-bin depends on:
ii  libavif8 0.8.3-3
ii  libc62.31-4
ii  libjpeg62-turbo  1:2.0.5-1.1
ii  libpng16-16  1.6.37-3

libavif-bin recommends no packages.

libavif-bin suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#973789: src:parsinsert: fails to migrate to testing for too long: FTBFS on armel, armhf, mips64el and ppc64el

[Andreas Tille]

Control: reopen -1
Control: tags -1 help
Control: tags -1 upstream
Control: forwarded -1 David Knox 

Hi David,

as you can see in the Debian bug the Build logs for mips64el[1] and
others[2] the build time tests for parsinsert are failing.  From my
naive perspective its basically a matter of rounding errors that might
became visible with gcc-10 but it would be great if this could be fixed.

Kind regards

 Andreas.


[1] 
https://buildd.debian.org/status/fetch.php?pkg=parsinsert=mips64el=1.04-9=1599659177=0
[2] https://buildd.debian.org/status/package.php?p=parsinsert

-- 
http://fam-tille.de

Bug#976318: u-boot: Style changes for the packaging

[Nicolas Boulenguez]

Source: u-boot
Followup-For: Bug #976318

With the attachments...
>From e73ab6b762a156523d12583fc80631236ac3018b Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Tue, 1 Dec 2020 19:21:02 +0100
Subject: Use specific dh_installman instead of dh_install

For example, dh_installman respects the nodoc build profile.

diff --git a/debian/u-boot-sunxi.install b/debian/u-boot-sunxi.install
index 833ce20943..7774d48f49 100755
--- a/debian/u-boot-sunxi.install
+++ b/debian/u-boot-sunxi.install
@@ -4,4 +4,3 @@ cp board/sunxi/mksunxi_fit_atf.sh debian/build/mksunxi_fit_atf
 echo debian/build/mksunxi_fit_atf /usr/bin/
 
 echo debian/bin/u-boot-install-sunxi64 /usr/bin/
-echo debian/manpages/u-boot-install-sunxi64.8 /usr/share/man/man8/
diff --git a/debian/u-boot-sunxi.manpages b/debian/u-boot-sunxi.manpages
new file mode 100644
index 00..f72604d63f
--- /dev/null
+++ b/debian/u-boot-sunxi.manpages
@@ -0,0 +1 @@
+debian/manpages/u-boot-install-sunxi64.8
diff --git a/debian/u-boot-tools.install b/debian/u-boot-tools.install
index 74e80d942c..80fbad26b7 100755
--- a/debian/u-boot-tools.install
+++ b/debian/u-boot-tools.install
@@ -8,9 +8,6 @@ done
 # install config
 echo ${builddir}/config /usr/share/doc/u-boot-tools/
 
-echo doc/mkimage.1 /usr/share/man/man1/
-echo doc/kwboot.1 /usr/share/man/man1/
-
 # example env configs
 for env_config in debian/env-configs/*.config tools/env/fw_env.config ; do
echo ${env_config} /usr/share/doc/u-boot-tools/examples/
diff --git a/debian/u-boot-tools.manpages b/debian/u-boot-tools.manpages
new file mode 100644
index 00..a250e967fd
--- /dev/null
+++ b/debian/u-boot-tools.manpages
@@ -0,0 +1,2 @@
+doc/kwboot.1
+doc/mkimage.1
>From b246be4e59602350b4df6d42bbcc7a9367e31f25 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Tue, 1 Dec 2020 19:22:47 +0100
Subject: Simplify debian/u-boot-tools.install

It was made executable when dpkg-architecture variables where needed.

diff --git a/debian/u-boot-tools.install b/debian/u-boot-tools.install
old mode 100755
new mode 100644
index 80fbad26b7..47e333dbdb
--- a/debian/u-boot-tools.install
+++ b/debian/u-boot-tools.install
@@ -1,14 +1,12 @@
-#!/bin/sh
-
-builddir=debian/build/tools
-for tool in dumpimage mkimage mkenvimage mksunxiboot kwboot ; do
-echo ${builddir}/tools/${tool} /usr/bin/
-done
+debian/build/tools/tools/dumpimage  usr/bin
+debian/build/tools/tools/kwboot usr/bin
+debian/build/tools/tools/mkenvimage usr/bin
+debian/build/tools/tools/mkimageusr/bin
+debian/build/tools/tools/mksunxibootusr/bin
 
 # install config
-echo ${builddir}/config /usr/share/doc/u-boot-tools/
+debian/build/tools/config   usr/share/doc/u-boot-tools
 
 # example env configs
-for env_config in debian/env-configs/*.config tools/env/fw_env.config ; do
-   echo ${env_config} /usr/share/doc/u-boot-tools/examples/
-done
+debian/env-configs/*.config usr/share/doc/u-boot-tools/examples
+tools/env/fw_env.config usr/share/doc/u-boot-tools/examples
>From fd075f84219564df6c9ffedb9073b61fbf9c78ae Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 3 Dec 2020 20:01:13 +0100
Subject: Simplify handling of DEB_BUILD_OPTIONS=parallel=N


diff --git a/debian/rules b/debian/rules
index 1bd0591119..ae6a32775c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,9 +10,7 @@ cross_build_tools ?= y
 endif
 
 # support parallel build using DEB_BUILD_OPTIONS=parallel=N
-ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
-  DEB_UBOOT_FLAGS += -j$(patsubst parallel=%,%,$(filter 
parallel=%,$(DEB_BUILD_OPTIONS)))
-endif
+DEB_UBOOT_FLAGS += $(patsubst parallel=%,-j%,$(filter 
parallel=%,$(DEB_BUILD_OPTIONS)))
 
 # Enable verbose build by default, disable when terse is specified.
 ifneq (,$(filter terse,$(DEB_BUILD_OPTIONS)))
>From 1c3702cb0811070b55162fccca75330dc28d4697 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 3 Dec 2020 20:03:23 +0100
Subject: In debian/rules, add prerequisite configs/*_defconfig it

This lets Make regenerate them if the source ever changes.

diff --git a/debian/rules b/debian/rules
index ae6a32775c..5069edb2af 100755
--- a/debian/rules
+++ b/debian/rules
@@ -36,11 +36,11 @@ endif
 %:
dh $@
 
-configs/novena-rawsd_defconfig:
+configs/novena-rawsd_defconfig: configs/novena_defconfig
sed -e 's,CONFIG_SPL_FS_FAT=y,# CONFIG_SPL_FS_FAT is not set,' \
configs/novena_defconfig > configs/novena-rawsd_defconfig
 
-configs/am335x_boneblack_defconfig:
+configs/am335x_boneblack_defconfig: configs/am335x_evm_defconfig
sed -e 's,CONFIG_OF_LIST=.*,CONFIG_OF_LIST="am335x-evm 
am335x-boneblack",g' \
configs/am335x_evm_defconfig > 
configs/am335x_boneblack_defconfig
 
>From 403e6a701e9bc17f5f29c6167a12473901c4c0b9 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 3 Dec 2020 20:04:51 +0100
Subject: In debian/rules, simplify DEB_BUILD_PROFILES=pkg.uboot.notools


diff --git 

Bug#976348: debian-faq: reproducible builds: Embedded timestamps in PDF files

[Vagrant Cascadian]

Source: debian-faq
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Several PDFs shipped in various debian-faq packages embed the build date:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/debian-faq.html
  
  /usr/share/doc/debian/FAQ/debian-faq.de.pdf.gz
  2 5.·Januar·2022  2   3.·Dezember·2020

The attached patch fixes this by setting FORCE_SOURCE_DATE=1 in
debian/rules, which texlive needs in order to respect SOURCE_DATE_EPOCH,
which is set during debian package builds to the timestamp in the latest
debian/changelog entry.

  https://reproducible-builds.org/docs/source-date-epoch/

live well,
  vagrant

From 7176b957c5e7d3adaa539ac9f9eb70285ad7ccea Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 3 Dec 2020 19:20:06 +
Subject: [PATCH] debian/rules: Set FORCE_SOURCE_DATE=1 in order for texlive to
 respect SOURCE_DATE_EPOCH for reproducible timestamps.

https://reproducible-builds.org/docs/source-date-epoch/
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 64bb6b8..f3f359d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,8 @@
 #!/usr/bin/make -f
 
+# Needed for texlive to respect SOURCE_DATE_EPOCH when setting date
+export FORCE_SOURCE_DATE=1
+
 %:
 	dh $@
 
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#976331: [Pkg-javascript-devel] Bug#976331: Bug#976331: Bug#976331: [JS Policy] what to set in "Provides" field ?

[Pirate Praveen]

On Thu, Dec 3, 2020 at 19:17, Jonas Smedegaard  wrote:

My understanding is that ftpmasters dislike small *source* packages.

Small source packages is a burden in *every* package tracking in 
Debian.


Small binary packages is also a burden in *some* package tracking.

Zero-size binary packages is also a burden in *some* package tracking,
but I don't hear ftpmasters complain about task packages.


This bug 976331 is *not* about repackaging embedded modules as 
separate
*source* packages, but only about exposing embedded modules as 
*binary*

packages - either virtual or real ones.




I suggest you embed serialize-javascript in node-terser and if you wish 
you can expose it as virtual package via Provides.


Connecting unrelated packages together is making things complicated for 
transitions and also increases installed packages size.


Also 'should' is not 'must' in policy.

Bug#976072: Upcoming fix

[Dave Steele]

Preparing to unpack topydo_0.13-5_all.deb ...
Unpacking topydo (0.13-5) over (0.13-2) ...
Setting up topydo (0.13-5) ...
update-alternatives: using /usr/bin/topydo to provide /usr/bin/todo.txt
(todo.txt) in auto mode
update-alternatives: using /usr/bin/topydo to provide /usr/bin/todo (todo)
in auto mode
Processing triggers for man-db (2.9.3-2) ...

Bug#971791: Extra information

[Lisandro Damián Nicanor Pérez Meyer]

Sorry if I break the thread, I'm currently using a broken MUA.

Apart from the missing firmware there is also
https://bugzilla.kernel.org/show_bug.cgi?id=208965 which seems to be
fixed by https://marc.info/?l=linux-bluetooth=160378222632366=2

So even installing the firmware would not be enough for current Debian unstable.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#971525: ITP: python3-briar-wrapper -- Wrapper around the Briar Headless REST API

[Nico Alt]

I posted some updates to the packaging of briar-headless in [0] which is 
currently blocking this ITP.


tl;dr: Plans to get into next Debian stable release were given up and 
The Briar Project will now focus on setting up their own APT repository [1].


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971526#10
[1] https://code.briarproject.org/briar/briar-debian/-/issues/3

Bug#976344: RM: ruby-diaspora-federation/0.2.6-2

[Pirate Praveen]

On Thu, Dec 3, 2020 at 19:26, Paul Gevers  wrote:
What I'm saying is that it helps to include such details in the 
original

request.


I already mentioned this,

"Both diaspora and ruby-diaspora-federation-rails is not in testing 
(because they don't work with rails version 6)".


I thought that was enough to convey ruby-diaspora-federation is not 
really useful being in testing.

Bug#976347: RFS: fonts-agave/35-1 [ITP] -- monospaces programming font

[Gürkan Myczko]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "fonts-agave":

 * Package name: fonts-agave
   Version : 35-1
   Upstream Author : type agaric 
 * URL : https://b.agaric.net/page/agave
 * License : MIT
 * Vcs : https://salsa.debian.org/fonts-team/fonts-agave
   Section : fonts

It builds those binary packages:

  fonts-agave - monospaces programming font

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


  https://mentors.debian.net/package/fonts-agave/

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


  dget -x 
https://mentors.debian.net/debian/pool/main/f/fonts-agave/fonts-agave_35-1.dsc


Changes for the initial release:

 fonts-agave (35-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #976345)

Regards,
--
  Gürkan Myczko

Bug#971524: ITP: briar-gtk -- Desktop and mobile client for Briar p2p messaging

[Nico Alt]

I posted some updates to the packaging of briar-headless in [0] which is 
currently blocking this ITP.


tl;dr: Plans to get into next Debian stable release were given up and 
The Briar Project will now focus on setting up their own APT repository [1].


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971526#10
[1] https://code.briarproject.org/briar/briar-debian/-/issues/3

Bug#976344: RM: ruby-diaspora-federation/0.2.6-2

[Paul Gevers]

Control: tags -1 pending

Hi Pirate,

On 03-12-2020 19:20, Pirate Praveen wrote:
> Are you saying we should not be proactively helping packages to migrate
> to testing?

What I'm saying is that it helps to include such details in the original
request.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#974691: German message catalogue

[Willem van den Akker]

fixed -1 1.1.1-1

Bug#976344: RM: ruby-diaspora-federation/0.2.6-2

[Pirate Praveen]

On Thu, Dec 3, 2020 at 19:13, Paul Gevers  wrote:

Which is uploaded today. What's the hurry that you can't just fix
ruby-diaspora-federation or wait for its autoremoval? You're one of 
it's

uploaders.


Because I don't think diaspora will be ready for bullseye (may be in 
bullseye-backports or bullseye-fasttrack), since it does not work with 
rails 6, so there is no incentive to fix ruby-diaspora-federation for 
bullseye. I don't think there is any point to delay ruby-faraday 1.0 
migration for a package that is not really needed in bullseye.


Are you saying we should not be proactively helping packages to migrate 
to testing?

Bug#954273: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#954273: fixed in gatb-core 1.4.2+dfsg-6)

[Paul Gevers]

Oops, nevermind.

Paul

On 03-12-2020 19:20, Paul Gevers wrote:
> Hi Andreas,
> 
> On 02-12-2020 18:06, Debian Bug Tracking System wrote:
>>  gatb-core (1.4.2+dfsg-6) unstable; urgency=medium
>>  .
>>* Use int as return of fgetc
>>  Closes: #954273
>>* Standards-Version: 4.5.1 (routine-update)
> 
> Are you sure this "Closes" isn't a typo? That bug was reported against
> simka.
> 
> Paul
> 



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976331: [Pkg-javascript-devel] Bug#976331: [JS Policy] what to set in "Provides" field ?

[Jonas Smedegaard]

Quoting Xavier (2020-12-03 17:33:18)
> I'm not in favor of your proposal: if I need a node-very-few-module 
> which is provided by a package with many dependencies, I'm not happy 
> to depend on it.

I don't recognize the above as being something I proposed (and I am not 
really sure what it says).

Maybe there is a misunderstanding somewhere, and we do not really 
disagree as much?

Please, let's try make sure we at least agree what we disagree on :-)

I do _not_ blame you on linguistic failures here, Xavier - it might 
_seem_ like I am better at english than you but I might very well be 
worse than you in explaining myself and understaning what you write...


 - 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#976331: [Pkg-javascript-devel] Bug#976331: Bug#976331: [JS Policy] what to set in "Provides" field ?

[Jonas Smedegaard]

Quoting Xavier (2020-12-03 18:42:17)
> Le 03/12/2020 à 18:21, Jonas Smedegaard a écrit :
> > Quoting Xavier (2020-12-03 17:33:18)
> >> Le 03/12/2020 à 16:36, Jonas Smedegaard a écrit :
> >>> Quoting Xavier (2020-12-03 15:44:48)
>  Le 03/12/2020 à 15:12, Jonas Smedegaard a écrit :
> > Quoting Xavier (2020-12-03 14:35:25)
> >> Le 03/12/2020 à 14:24, Xavier a écrit :
> >>> Le 03/12/2020 à 12:44, Jonas Smedegaard a écrit :
>  These source packages embed nodejs module serialize-javascript 
>  without offering it as virtual binary package:
> 
>   node-compression-webpack-plugin
>   node-copy-webpack-plugin
>   node-uglifyjs-webpack-plugin
> 
>  Please embed in only one source package provided as versioned 
>  virtual package, and drop in other source packages instead 
>  depending on the virtual package.
> 
>  Severity raised since the lack of virtual package blocks upgrading 
>  node-terser.
> >
> > [...]
> >
> >>> for now, dh-sequence-nodejs adds a "Provides" item for modules 
> >>> installed in root nodejs directories. Do we want to declare a 
> >>> "node-foo" for submodules (installed in a /node_modules 
> >>> directory) ?
> >
> > Whatever that tool does, the resulting package should declare 
> > Provides: for each embedded Nodejs module, properly versioned with 
> > the module's own version as first segment then "~" then source 
> > package version.
> >
> > I cannot see a reason for *any* embedded Nodejs module to stay 
> > hidden, but if someone comes up with some exceptional cases for 
> > that, then the reasoning should be explicitly documented in either 
> > README.source or README.Debian (and possibly in long description 
> > too).
> 
>  I chose that because such modules are not directly usable using a 
>  `require("foo")`, but I can change
> >>>
> >>> I am less interested in why historically some pattern was chosen.
> >>>
> >>> My interest is in what pattern to use going forward.
> >>>
> >>> Code in package have dependencies on code in other packages.
> >>>
> >>> We need to be able to declare dependencies between pieces of code.
> >>>
> >>> For JavaScript, code is grouped as "Nodejs modules".
> >>>
> >>> A a concrete example, Nodejs module rollup-plugin-terser depends on 
> >>> Nodejs module serialize-javascript.
> >>>
> >>> Going forward (regardless of why historically some other pattern was 
> >>> chosen), Debian package node-rollup-plugin-terser needs to be able to 
> >>> express a build-dependency on Debian package providing the Nodejs module 
> >>> serialize-javascript.
> >>>
> >>>
> >> Note that the future lintian database (classification tags) will 
> >> permit to see node modules everywhere.
> >
> > Everywhere?
> 
>  Sorry, I miss some explanations: lintian parses all files and emit a tag
>  each time it finds a node_module/foo/package.json or
>  /foo/package.json or   able to see nodejs embedded module in all Debian packages.
> >>>
> >>> Lintian can help check if a package is valid.
> >>>
> >>> Lintian cannot make a package declare as virtual Debian packages the 
> >>> Nodejs modules it has embedded.
> >>>
> >>>
>  NB2, you can also take a look at
>  https://lintian.debian.org/tags/nodejs-module-not-declared.html : it
>  shows node module installed in nodejs main dirs (not in node_modules/
>  for now).
> >>>
> >>> A web page (generated by lintian or written any other way) cannot make a 
> >>> package declare as virtual Debian packages the Nodejs modules it has 
> >>> embedded.
> >>>
> >>>
>  If we decide to change this ~policy, nodejs-module-not-declared should 
>  also be updated.
> >>>
> >>> I am pretty sure that hiding generally usable embedded code violates a 
> >>> "should" somewhere in Debian Policy.
> >>
> >> If so, lintian should reports "error", not info/warning when a JS lib is
> >> embedded. Ftpmasters didn't reject such packages (see jquery copies for
> >> example).
> > 
> > Ideally lintian should identify and report all errors.
> > 
> > Ideally all packaging work could be automated.
> > 
> > Reality is slightly different. though.
> > 
> > 
> > 
> >>> Therefore, if Debian JavaScript Policy says that generally useful 
> >>> modules should be *hidden* instead of provided as virtual packages, then 
> >>> I consider Debian JavaScript Policy broken.
> >>>
>  But in this case, we will have some not-directly-usable node-* virtual 
>  packages.
> >>>
> >>> Why not-directly-usable?
> >>>
> >>> Obviously we should not _only_ declare "Provides:" but also make sure 
> >>> that the code is actually placed in the correct location below 
> >>> /usr/share/nodejs and check testsuite and establish autopkgtest and all 
> >>> the other things that is required for packaging code.
> >>>
> >>> Embedded code is not magically excluded 

Bug#976346: RFS: hacktv/0+git20201203-1 -- Analogue TV transmitter for the HackRF

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: hacktv
   Version : 0+git20201203-1
   Upstream Author : Philip Heron 
 * URL : https://github.com/fsphil/hacktv
 * License : GPL-3+
 * Vcs : 
https://salsa.debian.org/debian-hamradio-team/hacktv

   Section : hamradio

It builds those binary packages:

  hacktv - Analogue TV transmitter for the HackRF

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/h/hacktv/hacktv_0+git20201203-1.dsc


Changes since the last upload:

 hacktv (0+git20201203-1) unstable; urgency=medium
 .
   * New upstream version.
   * d/upstream/metadata: added.
   * d/control: added Rules-Requires-Root.
   * d/copyright:
 - update copyright years.
 - added Upstream-Contact.
   * Bump debhelper version to 13, drop d/compat.

Regards,
--
  Gürkan Myczko

Bug#976345: ITP: fonts-agave -- monospaces programming font

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
debian-fo...@lists.debian.org


* Package name: fonts-agave
  Version : 35
  Upstream Author : type agaric 
* URL : https://b.agaric.net/page/agave
* License : MIT
  Description : monospaces programming font
 This was an attempt at making a small, monospaced, outline font that 
would be

 geometrically regular and simple. The endeavor was motivated by a deep
 adoration of old-school console bitmap fonts, of Consolas, of Pragmata 
Pro,

 as well as a novice's curiosity for typographical design.

It will be maintained in the Fonts team.

Bug#954273: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#954273: fixed in gatb-core 1.4.2+dfsg-6)

[Paul Gevers]

Hi Andreas,

On 02-12-2020 18:06, Debian Bug Tracking System wrote:
>  gatb-core (1.4.2+dfsg-6) unstable; urgency=medium
>  .
>* Use int as return of fgetc
>  Closes: #954273
>* Standards-Version: 4.5.1 (routine-update)

Are you sure this "Closes" isn't a typo? That bug was reported against
simka.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#974733: q2-quality-filter: unsatisfiable build-dependencies

[Étienne Mollier]

Hi Andreas,

On Thu, 3 Dec 2020 14:18:08 +0100 Andreas Tille  wrote:
> ==
> ERROR: test_q_score (q2_quality_filter.test.test_filter.FilterTests)
> --
> Traceback (most recent call last):
>   File 
> "/tmp/autopkgtest.Oa4qOC/autopkgtest_tmp/q2_quality_filter/test/test_filter.py",
>  line 108, in test_q_score
> with redirected_stdio(stdout=os.devnull):
>   File "/usr/lib/python3.9/contextlib.py", line 117, in __enter__
> return next(self.gen)
>   File "/usr/lib/python3/dist-packages/qiime2/util.py", line 24, in 
> redirected_stdio
> with _redirected_fd(to=stdout, stdio=sys.stdout):
>   File "/usr/lib/python3.9/contextlib.py", line 117, in __enter__
> return next(self.gen)
>   File "/usr/lib/python3/dist-packages/qiime2/util.py", line 43, in 
> _redirected_fd
> stdio_fd = _get_fileno(stdio)
>   File "/usr/lib/python3/dist-packages/qiime2/util.py", line 64, in 
> _get_fileno
> fd = getattr(file_or_fd, 'fileno', lambda: file_or_fd)()
> io.UnsupportedOperation: fileno
>  >> begin captured logging << 
> bibtexparser.bparser: DEBUG: Found Entry: ['Article', 'Bolyen2019', {'url': 
> 'https://doi.org/10.1038/s41587-019-0209-9', 'doi': 
> '10.1038/s41587-019-0209-9', 'issn': '1546-1696', 'pages': '852

The autopkgtest uses nosetests3, which does not cope with the
pytest-3 decorators.  Moving to py.test-3 solves this without
impeding the test coverage it seems.  I'll run a few tests to
make sure everything is okay, then I'll push to Salsa and, it
should be ready for upload.

Cheers,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/5, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#976344: RM: ruby-diaspora-federation/0.2.6-2

[Paul Gevers]

Control: tags -1 moreinfo

On 03-12-2020 19:01, Pirate Praveen wrote:
> This package is blocking ruby-faraday 1.0 migration to testing
> (#976343).

Which is like, minutes old.

> Its only reverse dependency is
> ruby-diaspora-federation-rails, which in turn has only one other reverse
> dependency diaspora.
> 
> Both diaspora and ruby-diaspora-federation-rails is not in testing
> (because they don't work with rails version 6).
> 
> Please remove this package from testing to allow migration of
> ruby-faraday 1.0 to testing.

Which is uploaded today. What's the hurry that you can't just fix
ruby-diaspora-federation or wait for its autoremoval? You're one of it's
uploaders.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976341: [Pkg-javascript-devel] Bug#976341: node-jest: please provide real (not virtual) package node-jest-worker

[Jonas Smedegaard]

Quoting Xavier (2020-12-03 18:30:54)
> Control: tags -1 + confirmed
> 
> Le 03/12/2020 à 18:07, Jonas Smedegaard a écrit :
> > node-rollup-plugin-terser has a runtime dependency on 
> > node-jest-worker.
> > 
> > Currently node-jest-worker is provided as a virtual package by jest. 
> > Problem with that is the size of the dependency tree...
> > 
> > rollup+node-rollup-plugin-terser+jest: 334 pkgs / 182 MB
> > 
> > rollup+node-rollup-plugin-terser+node-jest-worker: 136 pkgs / 107 MB
> > 
> > I.e. the size is approximately half with node-jest-worker separate 
> > from jest.
> > 
> > 
> > Please provide real (not virtual) package node-jest-worker,
> > and have jest depend on or recommend that, as appropriate.
> > 
> > 
> >  - Jonas
> > 
> > Hint: Introducing a new package causes a visit the the NEW queue,
> > which potentially can require some time for processing.  To avoid
> > such waiting time stalling other development of the jest package
> > it can be beneficial to first mae a release to experimental
> > (where it can linger while other releases are made to unstable).
> 
> According to https://people.debian.org/~yadd/jest-spaghetti-dish.png
> this makes sense. Do you see some other jest parts that should be separated?

Sorry, I have only closely examined the virtual package that I concrete 
have a need for.

It makes fine sense to me that node-jest-worker was provided only as a 
virtual package until now.  If you want to do more now than switching 
that one binary package from virtual to real, then the most sensible to 
me is to make sure _all_ embedded modules are provided as virtual 
packages to encourage _others_ to collaborate on that larger ongoing 
process of refining pakcage relations.

Viewed generally, decoupling binary packages can be separated into 
multiple steps...:

 1) provide embedded modules as packages - virtual or not - to allow 
declaring explicit package relations.

 2) declare explicit package relations.

 3) examine explicit package relations against virtual packages, to 
assess if some of them might benefit from being maintained as real 
binary packages.

Here concretely, I just happened to do 2) and 3) together.

For comparison, some size benefit might be in decoupling 
node-types-babel-code-frame from node-babel7 - but in that case I am 
_required_ to do examination first, because the virtual package lack 
versioning and therefore cannot be declared explicitly in packages 
depending on it.  By not providing versioned virtual packages, it is 
harder to identify places beneficial for decoupling, because exact 
relationship cannot be declared ahead of the examination.


 - 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#971526: ITP: briar-headless -- Core library exposing REST API

[Nico Alt]

Some updates on this:

* The Briar Project now offers official briar-headless.jar files at e.g. [0]
* briar-headless in Debian main is not only blocked by Kotlin, but also 
by Gradle; both need to be packaged with recent versions before 
packaging briar-headless can start
* Additionally, each (Gradle) dependency of briar-headless needs to be 
packaged separately for Debian main
* Plans to get into next Debian stable release with a Debian contrib 
binary were given up
* Efforts will now be focused on providing an official APT repository of 
The Briar Project [1]

* A mail to debian-java confirmed all of the above [2]

Updates to this ITP will also be published at [3].

[0] https://briarproject.org/jar/briar-headless-1.2.12.jar
[1] https://code.briarproject.org/briar/briar-debian/-/issues/3
[2] https://lists.debian.org/debian-java/2020/10/msg00010.html
[3] https://code.briarproject.org/briar/briar-debian/-/issues/1

Bug#976344: RM: ruby-diaspora-federation/0.2.6-2

[Pirate Praveen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

This package is blocking ruby-faraday 1.0 migration to testing 
(#976343). Its only reverse dependency is 
ruby-diaspora-federation-rails, which in turn has only one other 
reverse dependency diaspora.


Both diaspora and ruby-diaspora-federation-rails is not in testing 
(because they don't work with rails version 6).


Please remove this package from testing to allow migration of 
ruby-faraday 1.0 to testing.


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

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

Bug#976343: ruby-diaspora-federation: ftbfs with ruby-faraday 1.0

[Pirate Praveen]

Package: ruby-diaspora-federation
Severity: serious
Version: 0.2.6-2

ruby-diaspora-federation ftbfs/fails autopkgtest with ruby-faraday 1.0

/usr/lib/ruby/2.7.0/rubygems/dependency.rb:313:in `to_specs': Could not 
find 'faraday' (< 0.18.0, >= 0.9.0) - did find: [faraday-1.1.0] 
(Gem::MissingSpecVersionError)


Full log 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-diaspora-federation/8611484/log.gz

Bug#976007: adb: Adb completely broken after today's update in android-libboringssl (testing branch)

[jim_p]

Package: adb
Followup-For: Bug #976007
X-Debbugs-Cc: pitsior...@gmail.com

Fixed in v10.x that finally reached unstable earlier for amd64 and i386!

$ adb devices
List of devices attached
ABCDEF1234567890device

The same applies to #975707.
Thank you very much.



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

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

Versions of packages adb depends on:
ii  android-libadb   1:10.0.0+r36-1~stage1.3
ii  android-libbase  1:10.0.0+r36-1~stage1.3
ii  libc62.31-4
ii  libgcc-s110.2.0-19
ii  libstdc++6   10.2.0-19

Versions of packages adb recommends:
ii  android-sdk-platform-tools-common  27.0.0+12

adb suggests no packages.

-- no debconf information

Bug#976331: [Pkg-javascript-devel] Bug#976331: [JS Policy] what to set in "Provides" field ?

[Xavier]

Le 03/12/2020 à 18:21, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-03 17:33:18)
>> Le 03/12/2020 à 16:36, Jonas Smedegaard a écrit :
>>> Quoting Xavier (2020-12-03 15:44:48)
 Le 03/12/2020 à 15:12, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-03 14:35:25)
>> Le 03/12/2020 à 14:24, Xavier a écrit :
>>> Le 03/12/2020 à 12:44, Jonas Smedegaard a écrit :
 These source packages embed nodejs module serialize-javascript 
 without offering it as virtual binary package:

  node-compression-webpack-plugin
  node-copy-webpack-plugin
  node-uglifyjs-webpack-plugin

 Please embed in only one source package provided as versioned 
 virtual package, and drop in other source packages instead 
 depending on the virtual package.

 Severity raised since the lack of virtual package blocks upgrading 
 node-terser.
>
> [...]
>
>>> for now, dh-sequence-nodejs adds a "Provides" item for modules 
>>> installed in root nodejs directories. Do we want to declare a 
>>> "node-foo" for submodules (installed in a /node_modules 
>>> directory) ?
>
> Whatever that tool does, the resulting package should declare 
> Provides: for each embedded Nodejs module, properly versioned with 
> the module's own version as first segment then "~" then source 
> package version.
>
> I cannot see a reason for *any* embedded Nodejs module to stay 
> hidden, but if someone comes up with some exceptional cases for 
> that, then the reasoning should be explicitly documented in either 
> README.source or README.Debian (and possibly in long description 
> too).

 I chose that because such modules are not directly usable using a 
 `require("foo")`, but I can change
>>>
>>> I am less interested in why historically some pattern was chosen.
>>>
>>> My interest is in what pattern to use going forward.
>>>
>>> Code in package have dependencies on code in other packages.
>>>
>>> We need to be able to declare dependencies between pieces of code.
>>>
>>> For JavaScript, code is grouped as "Nodejs modules".
>>>
>>> A a concrete example, Nodejs module rollup-plugin-terser depends on 
>>> Nodejs module serialize-javascript.
>>>
>>> Going forward (regardless of why historically some other pattern was 
>>> chosen), Debian package node-rollup-plugin-terser needs to be able to 
>>> express a build-dependency on Debian package providing the Nodejs module 
>>> serialize-javascript.
>>>
>>>
>> Note that the future lintian database (classification tags) will 
>> permit to see node modules everywhere.
>
> Everywhere?

 Sorry, I miss some explanations: lintian parses all files and emit a tag
 each time it finds a node_module/foo/package.json or
 /foo/package.json or >>> able to see nodejs embedded module in all Debian packages.
>>>
>>> Lintian can help check if a package is valid.
>>>
>>> Lintian cannot make a package declare as virtual Debian packages the 
>>> Nodejs modules it has embedded.
>>>
>>>
 NB2, you can also take a look at
 https://lintian.debian.org/tags/nodejs-module-not-declared.html : it
 shows node module installed in nodejs main dirs (not in node_modules/
 for now).
>>>
>>> A web page (generated by lintian or written any other way) cannot make a 
>>> package declare as virtual Debian packages the Nodejs modules it has 
>>> embedded.
>>>
>>>
 If we decide to change this ~policy, nodejs-module-not-declared should 
 also be updated.
>>>
>>> I am pretty sure that hiding generally usable embedded code violates a 
>>> "should" somewhere in Debian Policy.
>>
>> If so, lintian should reports "error", not info/warning when a JS lib is
>> embedded. Ftpmasters didn't reject such packages (see jquery copies for
>> example).
> 
> Ideally lintian should identify and report all errors.
> 
> Ideally all packaging work could be automated.
> 
> Reality is slightly different. though.
> 
> 
> 
>>> Therefore, if Debian JavaScript Policy says that generally useful 
>>> modules should be *hidden* instead of provided as virtual packages, then 
>>> I consider Debian JavaScript Policy broken.
>>>
 But in this case, we will have some not-directly-usable node-* virtual 
 packages.
>>>
>>> Why not-directly-usable?
>>>
>>> Obviously we should not _only_ declare "Provides:" but also make sure 
>>> that the code is actually placed in the correct location below 
>>> /usr/share/nodejs and check testsuite and establish autopkgtest and all 
>>> the other things that is required for packaging code.
>>>
>>> Embedded code is not magically excluded from getting properly packaged.
>>
>> You're free to think that my packages are not properly packaged.
> 
> I am not targeting you, nor am I targeting dh-sequence-nodejs, nor am I 
> targeting lintian, nor am I targeting JavaScript Team Policy.  You 
> brought those up in this 

Bug#976331: [Pkg-javascript-devel] Bug#976331: Bug#976331: [JS Policy] what to set in "Provides" field ?

[Jonas Smedegaard]

Quoting Pirate Praveen (2020-12-03 18:07:56)
> 
> 
> On 2020, ഡിസംബർ 3 10:03:18 PM IST, Xavier  wrote:
> >I'm not in favor of your proposal: if I need a node-very-few-module
> >which is provided by a package with many dependencies, I'm not happy to
> >depend on it. To apply that, we should then choose with precaution in
> >which package we will embed each code. Packaging JS is already a hudge
> >work, I'm not sure we need more complexity.
> >
> >@JS-Team, does anyone have any other opinion? Else which option do you
> >choose? I'll update pkg-js-tools with your choice of course.
> 
> I agree with yadd here. We should not complicate js packaging more than it 
> already is.

Rubbish: This debate is not about more or less complicated packaging.

We should make our js packaging *less* complicated.

More importantly, we should make js *maintenance* less complicated!

But most importantly, we should obey all "should"s in Debian policy: 
https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies


 - 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#975874: buster-pu: package openjdk-11/11.0.9.1+1-1~deb10u1

[Adam D. Barratt]

On Thu, 2020-12-03 at 11:28 +, Adam D. Barratt wrote:
> [adding d-java to Cc for greater visibility]
> 
> On Mon, 2020-11-30 at 09:21 +, Adam D. Barratt wrote:
> > On Wed, 2020-11-25 at 20:23 -0800, tony mancill wrote:
> > > I propose that openjdk-11 be updated to upstream 11.0.9.1+1 in
> > > the
> > > upcoming stable point release.  This update addresses a
> > > regression
> > > [1] introduced in upstream release 11.0.9+11, which is present in
> > > buster via a security upload [2].  This keeps Debian on par with
> > > other vendors - e.g. RedHat [3], Ubuntu [4], and AdoptOpenJDK [5]
> > > -
> > > and introduces the same upstream version currently available in
> > > testing and unstable.
> > 
> > The versioning here appears to cause issues in at least Jenkins -
> > see 
> > https://issues.jenkins.io/projects/JENKINS/issues/JENKINS-64212
> 
> Have there been any further issues that people are aware of?
> 
> The Jenkins fix is not yet available to most users if I understand
> correctly, so we need to consider the tradeoffs between the
> regression on the OpenJDK side and requiring manual intervention on
> Jenkins installations (and possibly other things confused by the
> version string).

To tie up a couple of IRC conversations with Moritz, the fixed Jenkins
versions have now been released, so we can probably just tell people
they need to upgrade.

Regards,

Adam

Bug#976342: amdgpu-dkms: build of dkms module failure

[Olaf Zaplinski]

Package: amdgpu-dkms
Version: 1:5.6.5.24-1109583
Severity: important

Dear Maintainer,

dkms build fails with kernel 5.4.0-56-generic


make.log:

  AR  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/built-in.a
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/main.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/symbols.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_mn.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/scheduler/sched_main.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/scheduler/sched_fence.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_memory.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/scheduler/sched_entity.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/ttm/ttm_memory.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_ioctl.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/ttm/ttm_tt.o
  CC [M]
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_device_cgroup.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdgpu/amdgpu_drv.o
  CC [M]
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdgpu/amdgpu_device.o
  CC [M]
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_drm_cache.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_drm.o
  CC [M]
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_fence_array.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_fence.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_io.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdgpu/amdgpu_kms.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_kthread.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_mm.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_pci.o
  CC [M]
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_perf_event.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/ttm/ttm_bo.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/ttm/ttm_bo_util.o
  CC [M]
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_reservation.o
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_fence.c:30:1:
warning: ‘dma_fence_test_signaled_any’ defined but not used [-Wunused-function]
  30 | dma_fence_test_signaled_any(struct dma_fence **fences, uint32_t count,
  | ^~~
  CC [M]
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdgpu/amdgpu_atombios.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_suspend.o
  CC [M]
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_workqueue.o
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_seq_file.o
  LD [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/scheduler/amd-sched.o
  CC [M]
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_connector.o
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_pci.c: In function
‘amdkcl_pci_init’:
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_pci.c:103:84:
warning: passing argument 2 of ‘amdkcl_fp_setup’ discards ‘const’ qualifier
from pointer target type [-Wdiscarded-qualifiers]
  103 |  _kcl_pcie_link_speed = (const unsigned char *)
amdkcl_fp_setup("pcie_link_speed", _kcl_pcie_link_speed_stub);
  |
^
In file included from
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_pci.c:4:
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_common.h:12:63:
note: expected ‘void *’ but argument is of type ‘const unsigned char *’
   12 | static inline void *amdkcl_fp_setup(const char *symbol, void *fp_stup)
  | ~~^~~
  CC [M]
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_backlight.o
  CC [M]
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_drm_atomic_helper.o
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_reservation.c: In
function ‘amdkcl_reservation_init’:
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_reservation.c:59:10:
warning: passing argument 2 of ‘amdkcl_fp_setup’ discards ‘const’ qualifier
from pointer target type [-Wdiscarded-array-qualifiers]
   59 |  &_kcl_reservation_seqcount_string_stub);
  |  ^~
In file included from
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_reservation.c:33:
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/kcl_common.h:12:63:
note: expected ‘void *’ but argument is of type ‘const char (*)[21]’
   12 | static inline void *amdkcl_fp_setup(const char *symbol, void *fp_stup)
  | ~~^~~
  CC [M]  /var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdkcl/dma-buf/dma-
resv.o
  CC [M]
/var/lib/dkms/amdgpu/5.6.5.24-1109583/build/amd/amdgpu/atombios_crtc.o
  CC [M]

Bug#976341: node-jest: please provide real (not virtual) package node-jest-worker

[Xavier]

Control: tags -1 + confirmed

Le 03/12/2020 à 18:07, Jonas Smedegaard a écrit :
> Source: node-jest
> Version: 26.6.3+ds+~cs64.28.30-1
> Severity: normal
>
> node-rollup-plugin-terser has a runtime dependency on node-jest-worker.
> 
> Currently node-jest-worker is provided as a virtual package by jest.
> Problem with that is the size of the dependency tree...
> 
> rollup+node-rollup-plugin-terser+jest: 334 pkgs / 182 MB
> 
> rollup+node-rollup-plugin-terser+node-jest-worker: 136 pkgs / 107 MB
> 
> I.e. the size is approximately half with node-jest-worker separate from jest.
> 
> 
> Please provide real (not virtual) package node-jest-worker,
> and have jest depend on or recommend that, as appropriate.
> 
> 
>  - Jonas
> 
> Hint: Introducing a new package causes a visit the the NEW queue,
> which potentially can require some time for processing.  To avoid
> such waiting time stalling other development of the jest package
> it can be beneficial to first mae a release to experimental
> (where it can linger while other releases are made to unstable).

According to https://people.debian.org/~yadd/jest-spaghetti-dish.png
this makes sense. Do you see some other jest parts that should be separated?

Cheers,
Xavier

Bug#976332: /etc/xdg/autostart/org.kde.discover.notifier.desktop is marked executable

[Christian Göttsche]

Package: plasma-discover
Version: 5.19.5-4

systemd complaint:

systemd-xdg-autostart-generator[1216]: Configuration file
/etc/xdg/autostart/org.kde.discover.notifier.desktop is marked
executable. Please remove executable permission bits. Proceeding
anyway.

Bug#974646: ver2_02 is in firmware-misc-nonfree, ver2_01 is not

[Manfred Brandl]

reassign 974646 initramfs-tools

on latest bullseye:

manfred@thinkpad:~$ apt-file search rkl_dmc
firmware-misc-nonfree: /lib/firmware/i915/rkl_dmc_ver2_02.bin

root@thinkpad:~# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-5.0.9-4-686-pae
W: Possible missing firmware /lib/firmware/i915/rkl_dmc_ver2_01.bin for
module i915
update-initramfs: Generating /boot/initrd.img-5.0.9-3-686-pae
W: Possible missing firmware /lib/firmware/i915/rkl_dmc_ver2_01.bin for
module i915

this seems to be a problem with update-initramfs


Mit freundlichen Grüßen

--
Manfred Brandl
Verkehrsverbund Steiermark GmbH
Friedrichgasse 13, 8010 Graz
+43 316 812138-15
manfred.bra...@verbundlinie.at 
www.verbundlinie.at



Angaben gemäß § 14 UGB:
Verkehrsverbund Steiermark GmbH
Firmensitz: Friedrichgasse 13, 8010 Graz
Rechtsform: GmbH | FN: 38644f
Firmenbuchgericht: Landesgericht für ZRS Graz