Bug#1000949: Please drop the julia backend
tags 1000949 + patch
Le 01/12/2021 à 08:06, Stéphane Glondu a écrit :
> Please remove the julia backend. Julia itself seems unmaintained in
> Debian [1], prevents the obsolete package llvm-toolchain-9 from being
> removed, which in turn blocks some OCaml packages out of testing.
Attached is a patch, uploaded with dgit to DELAYED/10.
Cheers,
--
StéphaneFrom 3f615c45851a1424f908bacee9716f2eb2b4fa2d Mon Sep 17 00:00:00 2001
From: Stephane Glondu
Date: Wed, 1 Dec 2021 07:55:50 +0100
Subject: [PATCH] Drop the julia backend (Closes: #1000949)
---
debian/changelog | 7 +++
debian/control | 20 +---
debian/not-installed | 1 +
3 files changed, 9 insertions(+), 19 deletions(-)
create mode 100644 debian/not-installed
diff --git a/debian/changelog b/debian/changelog
index 7e91fc9..b9ef865 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+cantor (4:21.08.2-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop the julia backend (Closes: #1000949)
+
+ -- Stéphane Glondu Wed, 01 Dec 2021 08:15:32 +0100
+
cantor (4:21.08.2-1) unstable; urgency=medium
* Team upload.
diff --git a/debian/control b/debian/control
index bf67919..5dd4887 100644
--- a/debian/control
+++ b/debian/control
@@ -8,10 +8,8 @@ Build-Depends: cmake (>= 3.13~),
debhelper-compat (= 13),
extra-cmake-modules (>= 5.49.0~),
gettext,
- julia [amd64],
libanalitza-dev (>> 4:15.08),
libglib2.0-dev,
- libjulia-dev [amd64],
libkf5archive-dev (>= 5.70.0~),
libkf5completion-dev (>= 5.70.0~),
libkf5config-dev (>= 5.70.0~),
@@ -55,7 +53,7 @@ Architecture: any
Section: math
Depends: ${misc:Depends}, ${shlibs:Depends}
Recommends: cantor-backend-qalculate, texlive-binaries, texlive-latex-base
-Suggests: cantor-backend-julia [amd64],
+Suggests:
cantor-backend-kalgebra,
cantor-backend-lua [i386 amd64],
cantor-backend-maxima,
@@ -80,7 +78,6 @@ Description: interface for mathematical applications
* Scilab (cantor-backend-scilab)
* Qalculate! (cantor-backend-qalculate)
* Lua (cantor-backend-lua)
- * Julia (cantor-backend-julia)
.
This package is part of the KDE education module.
@@ -254,18 +251,3 @@ Description: Scilab backend for Cantor
package for numerical computations (https://www.scilab.org) in Cantor.
.
This package is part of the KDE education module.
-
-Package: cantor-backend-julia
-Architecture: amd64
-Section: math
-Depends: ${misc:Depends}, ${shlibs:Depends}
-Description: Julia backend for Cantor
- Cantor is an application to allow you to you use your favorite mathematical
- applications from within an elegant worksheet interface. It provides dialogs
- to assist with common tasks and allows you to share your worksheets
- with others.
- .
- This package provides the backend for using the Julia programming language
- (https://julialang.org) in Cantor.
- .
- This package is part of the KDE education module.
diff --git a/debian/not-installed b/debian/not-installed
new file mode 100644
index 000..c477561
--- /dev/null
+++ b/debian/not-installed
@@ -0,0 +1 @@
+usr/share/icons/hicolor/48x48/apps/juliabackend.png
--
2.33.0
Bug#995353: Info
We need to restart the autopkgtest runs as soon as the fixed version of ruby- rspec-memory hits Testing. Regards, Daniel -- Regards, Daniel Leidert | https://www.wgdd.de/ GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78 https://www.fiverr.com/dleidert https://www.patreon.com/join/dleidert signature.asc Description: This is a digitally signed message part
Bug#1000950: python3-mshr: error processing line 3 of /usr/lib/python3/dist-packages/mshr.pth
Package: python3-mshr Version: 2019.2.0~git20200924.c27eb18+dfsg1-7 Hello, When installing python3-mshr in clean sid chroot, the following message is displayed multiple times: """ Error processing line 3 of /usr/lib/python3/dist-packages/mshr.pth: Traceback (most recent call last): File "/usr/lib/python3.9/site.py", line 175, in addpackage exec(line) File "", line 1, in FileNotFoundError: [Errno 2] No such file or directory: '/usr/lib/petsc/include/petscconf.h' Remainder of file ignored """ Despite the message, python3-mshr seems to install successfully. Nevertheless the message gives an impression of installation failure [1]. [1] https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2021-November/095683.html Andrius
Bug#974779: Update of julia to 1.6.x
Hi Stéphane, > Then, julia should be removed (from testing at least). Agreed. > And cantor is key because kdeedu depends on it. I see you're an uploader > of cantor, could you remove its julia backend, please? Unfortunately I cannot upload anything anymore, the uploader status is incorrect. Sorry Norbert -- PREINING Norbert https://www.preining.info Fujitsu Research + IFMGA Guide + TU Wien + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#1000949: Please drop the julia backend
Source: cantor Version: 4:21.08.2-1 Severity: important X-Debbugs-Cc: pkg-julia-de...@lists.alioth.debian.org, pkg-llvm-t...@lists.alioth.debian.org, debian-ocaml-ma...@lists.debian.org Dear Maintainer, Please remove the julia backend. Julia itself seems unmaintained in Debian [1], prevents the obsolete package llvm-toolchain-9 from being removed, which in turn blocks some OCaml packages out of testing. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974779#126 Cheers, -- Stéphane -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1000924: libclang-perl: Please upgrade to llvm-toolchain-12 or 13
Hi, Sylvestre Ledru (2021-12-01): > As part of the effort to limit the number of llvm packages in the > archive, it would be great if you could upgrade to -13 (or -12). > > Bookworm won't ship with llvm-toolchain-11 > > llvm-defaults is now pointing to -13. I understand a binNMU would be sufficient to fix this problem (that will become RC during the Bookworm dev cycle). But perhaps we could instead remove this package from testing/sid: - low popcon - leaf package - Last activity by the upstream maintainer on the GitHub project seems to be from 6 years ago. And indeed, 6 years ago, upstream wrote "I'm not really using the project myself" (https://bugs.debian.org/803645#60). Thoughts? Lucas, I see you ITP'ed this package and introduced it in the archive, so perhaps you're aware of good reasons to keep it around? Cheers!
Bug#1000339: r-cran-raster breaks r-cran-satellite autopkgtest: unable to find an inherited method for function 'extend'
Dear Robert, Am Tue, Nov 30, 2021 at 09:18:18PM -0800 schrieb Robert J. Hijmans: > Dear Andreas, > > raster 3-5.2 depends on terra; but it does not specify which version of > terra. I believe it needs to be terra 1.4-11 to not get this error. Is it *exactly* this version or >= 1.4-11? We had once packaged terra just for raster startung with 1.4-11 and than moved on upgrading it to the current version 1.4-22. > From what you sent I cannot see which version of terra is installed, but I > am guessing it is an earlier version. Is that something you can check? There was never any earlier version than 1.4-11 in Debian. The Debian bug report links to a full log of the test[1] which installs ... Get:117 http://deb.debian.org/debian testing/main amd64 r-cran-terra amd64 1.4-11-2 [2,358 kB] Get:118 http://deb.debian.org/debian unstable/main amd64 r-cran-raster amd64 3.5-2-1 [3,063 kB] ... > I can dig a bit more if needed, please let me know. Your help would be really appreciated Andreas. [1] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-satellite/16823806/log.gz -- http://fam-tille.de
Bug#1000899: python-pyproj: no longer builds for all Python versions; blocks build of pyresample
Control: severity -1 important Control: tags -1 pending Control: block -1 by 1000422 On 11/30/21 22:22, Sebastian Ramacher wrote: This is not helpful during a transition where support for Python 3.10 is added. This prevents pyresample from being built. Please revert This has been done in git some time ago, but pyproj cannot be rebuilt with python3.10 until pandas is built successfully on all architectures. It also won't be able to migrate to testing until numpy can, a bunch of autopkgtest failures prevent that. Please help resolve those issues. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
All, I have uploaded a new GSL release (2.7.1) which I hope fixes the libtool version numbers On 11/21/21 3:27 PM, Dirk Eddelbuettel wrote: Hi Patrick, Can you please chime in (as you did in the earlier exchanges when Sebastian explained to us how to set valus triplet for libtool via configure.ac) ? On 21 November 2021 at 23:00, Sebastian Ramacher wrote: | On 2021-11-09 12:54:44 -0600, Dirk Eddelbuettel wrote: | > | > On 8 November 2021 at 22:14, Sebastian Ramacher wrote: | > | Control: tags -1 moreinfo | > | Control: forwarded -1 https://release.debian.org/transitions/html/auto-gsl.html | > | | > | On 2021-10-31 14:29:40 -0500, Dirk Eddelbuettel wrote: | > | > | > | > Package: release.debian.org | > | > Severity: normal | > | > User: release.debian@packages.debian.org | > | > Usertags: transition | > | > | > | > GNU GSL 2.7 was release a few months ago, and we now realised (in the | > | > discussion of #993324 which also included upstream) that the upstream libtool | > | > instruction were in error by _not_ leading to a new sonumber. This was | > | > corrected in (source package) gsl upload 2.7-3 to experimental, which built | > | > well. | > | | > | What's the status of the fix upstream? Was there any progress? Otherwise | > | we're gonna repeat that with the next upstream release. | > | > Those are two distinct issues. Upstream, I think we all agreed in the thread | > also recorded in the BTS, made an omission in this release where a new soname | > was needed, but wasn't given. This happens. So now we need a new soname | > __because the ABI/API changed__. | | Yes, the ABI changed and we need a new SONAME. This would ideally be | done upstream, though. Even better would be a new release with that change. Yes or no. We could proceed with the patch based on your suggestion. That would be "lighterweight" as we would not require upstream work right now. | As far as I am aware, the bug report lacks any mail from Patrick which He did participate earlier. Some of it may have been private mail between him and myself; I'd have to check. | would currently mean that we'd have a Debian-specific SONAME. If we go | ahead with that, we will end up in on of the following cases: | | 1. Upstream bumps the SONAME as we discussed it in the bug report. | Given the changes in [1], the next release of gsl would then have a | SONAME of libgsl.so.26, but with an incompatible ABI compared to what we | would have in the archive. I didn't catch that aspect. Yes us moving to libgsl.so.26 by ourself now would make it impossible to use that soname later :-/ | 2. Upstream bumps the SONAME to a version higher than 26. (That would be my stylistic preference. If the next GSL is 2.8, why not take 28? I may be unaware of other style 'customs' here.) | (3. Upstream simply ignores the issue) | | If 1. happens, we'd be unable to sync up with upstream's SONAME (there's | a good reason why we tend to avoid Debian-specific SONAMEs). | | Patrick, what are your planes? We're all ears :) Dirk | Best | Sebastian | | [1] https://git.savannah.gnu.org/cgit/gsl.git/commit/?id=191bf01a38e590dd0df8aa571accbbd331bfee07 | | > | > That has happened before, and that is why we had transitions in the past. | | | | > | > But not all previous releases had soname changes. I have maintained GSL here | > for about 20 years and I think this is about the third transition. I would | > call that defensible. | > | > The release team does of course have a broader view, and I am always keen to | > hear your thoughts. | > | > Cheers, Dirk | > | > | Cheers | > | | > | > | > | > I would like to ask for a formal transition. As we saw with failing tests in | > | > dependent packages, binNMUs will not work for all package (but possibly | > | > "most"). | > | > | > | > Tentative ben file below. | > | > | > | > - | > | > title = "gsl 2.7 transition"; | > | > is_affected = .depends ~ /libgsl-dev/; | > | > is_good = .depends ~ "libgsl26"; | > | > is_bad = .depends ~ "libgsl25"; | > | > - | > | > | > | > Let me know if I can help otherwise. | > | > | > | > Cheers, Dirk | > | > | > | > | > | > -- | > | > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | > | > | > | | > | -- | > | Sebastian Ramacher | > | x[DELETED ATTACHMENT signature.asc, application/pgp-signature] | > | > -- | > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | > | | -- | Sebastian Ramacher | [DELETED ATTACHMENT signature.asc, application/pgp-signature]
Bug#1000339: r-cran-raster breaks r-cran-satellite autopkgtest: unable to find an inherited method for function 'extend'
Dear Andreas, raster 3-5.2 depends on terra; but it does not specify which version of terra. I believe it needs to be terra 1.4-11 to not get this error. >From what you sent I cannot see which version of terra is installed, but I am guessing it is an earlier version. Is that something you can check? I can dig a bit more if needed, please let me know. Robert On Tue, Nov 30, 2021 at 12:48 AM Andreas Tille wrote: > Control: forwarded -1 Robert J. Hijmans , Florian > Detsch > Control: tags -1 upstream > Control: tags -1 help > > Hi Robert and Florian, > > I'm contacting you as the maintainers or raster and satellite. As you > can see below in the Debian packaged versions of these packages some > conflict was raised in the test of satellite after the latest version of > raster was uploaded. > > I'm perfectly aware that the packages are tested on CRAN and thus I > assume that possibly some special circumstances in the Debian packaged > version might lead to the issue that is reported in the bug below. I > wonder whether you can give some hints how to solve the conflict in the > test (at the very end of this mail). > > Thanks a lot for your help > > Andreas. > > Am Sun, Nov 21, 2021 at 09:24:52PM +0100 schrieb Paul Gevers: > > Source: r-cran-raster, r-cran-satellite > > Control: found -1 r-cran-raster/3.5-2-1 > > Control: found -1 r-cran-satellite/1.0.4-1 > > Severity: serious > > Tags: sid bookworm > > X-Debbugs-CC: debian...@lists.debian.org > > User: debian...@lists.debian.org > > Usertags: breaks needs-update > > > > Dear maintainer(s), > > > > With a recent upload of r-cran-raster the autopkgtest of r-cran-satellite > > fails in testing when that autopkgtest is run with the binary packages of > > r-cran-raster from unstable. It passes when run with only packages from > > testing. In tabular form: > > > >passfail > > r-cran-raster from testing3.5-2-1 > > r-cran-satellite from testing1.0.4-1 > > all others from testingfrom testing > > > > I copied some of the output at the bottom of this report. > > > > Currently this regression is blocking the migration of r-cran-raster to > > testing [1]. Due to the nature of this issue, I filed this bug report > > against both packages. Can you please investigate the situation and > reassign > > the bug to the right package? > > > > More information about this bug and the reason for filing it can be > found on > > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > > > Paul > > > > [1] https://qa.debian.org/excuses.php?package=r-cran-raster > > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-satellite/16823806/log.gz > > > > BEGIN TEST testthat.R > > > > R version 4.1.2 (2021-11-01) -- "Bird Hippie" > > Copyright (C) 2021 The R Foundation for Statistical Computing > > Platform: x86_64-pc-linux-gnu (64-bit) > > > > R is free software and comes with ABSOLUTELY NO WARRANTY. > > You are welcome to redistribute it under certain conditions. > > Type 'license()' or 'licence()' for distribution details. > > > > R is a collaborative project with many contributors. > > Type 'contributors()' for more information and > > 'citation()' on how to cite R or R packages in publications. > > > > Type 'demo()' for some demos, 'help()' for on-line help, or > > 'help.start()' for an HTML browser interface to help. > > Type 'q()' to quit R. > > > > > library(testthat) > > > library(satellite) > > Loading required package: raster > > Loading required package: sp > > code for methods in class "Rcpp_SpatCategories" was not checked for > > suspicious field assignments (recommended package 'codetools' not > > available?) > > code for methods in class "Rcpp_SpatCategories" was not checked for > > suspicious field assignments (recommended package 'codetools' not > > available?) > > code for methods in class "Rcpp_SpatDataFrame" was not checked for > > suspicious field assignments (recommended package 'codetools' not > > available?) > > code for methods in class "Rcpp_SpatDataFrame" was not checked for > > suspicious field assignments (recommended package 'codetools' not > > available?) > > code for methods in class "Rcpp_SpatExtent" was not checked for > suspicious > > field assignments (recommended package 'codetools' not available?) > > code for methods in class "Rcpp_SpatExtent" was not checked for > suspicious > > field assignments (recommended package 'codetools' not available?) > > code for methods in class "Rcpp_SpatMessages" was not checked for > suspicious > > field assignments (recommended package 'codetools' not available?) > > code for methods in class "Rcpp_SpatMessages" was not checked for > suspicious > > field assignments (recommended package 'codetools' not available?) > > code for methods in class "Rcpp_SpatOptions" was not checked for > suspicious > > field assignments (recommended package 'codetools' not available?) > > code for methods in class
Bug#978911: transmission: diff for NMU version 3.00-1.1
Control: tags -1 -pending Hi, 在 2021-11-30星期二的 18:09 -0500，Sandro Tosi写道： > > I've prepared an NMU for transmission (versioned as 3.00-1.1) and > > uploaded it to DELAYED/5. Please feel free to tell me if I > > should delay it longer. > > please remove it from the delayed queue, there's no need for a nmu here I have cancelled the upload and removed it from the delayed queue. Since this will leave this RC bug open, may I ask how will it be fixed then? Thanks, Boyuan Yang
Bug#1000948: grub2: Could not make LUKS2 work
Source: grub2
Version: 2.04-20
Severity: normal
Quack,
My system originally was created as LUKS2 and then I found out GRUB did
not support it and converted it to LUKS1. That was a while ago but that
is to say it's already using PBKDF2 so it's easy to switch back and
forth.
I upgraded my system with the recent release and the signed packaged
came yesterday and now GRUB is properly displaying "2.06".
I had enabled GRUB_ENABLE_CRYPTODISK=y in /etc/default/grub already. I
thus used the Debian installer rescue mode to convert with:
cryptsetup convert --type=luks2 /dev/nvme0n1p2
I then got into the root fs (via the rescue menu) and issued an
update-grub.
I rebooted and then was dropped into the GRUB shell.
I also added GRUB_PRELOAD_MODULES=luks2 just in case before switching to
LUKS2 but that did not help. For the record while debugging in the GRUB
shell I got:
grub> insmod cryptodisk
grub> insmod luks2
error: file `/boot/grub/x86_64-efi/luks2.mod' not found.
IIUC it would need to be added to debian/build-efi-images.
I also found out the new grub.cfg does not contain any cryptodisk or
luks* modules, so it seems grub-mkconfig is unable to generate a proper
configuration in this case. I'm adding the working and broken
configuration files as a reference.
My /etc/crypttab:
#
nvme0n1p2_crypt /dev/nvme0n1p2 none luks
Could you give me a hand?
Regards.
\_o<
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=fr_FR.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
--
Marc Dequènes#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
insmod luks2
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_gpt
insmod cryptodisk
insmod luks
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod lvm
insmod ext2
cryptomount -u ff654a895d9f47869f38dddc1e1f509b
set
root='lvmid/fqOzjT-qps1-L6jh-vNnF-6WzJ-S0rU-Ptuez8/bDh7ac-60Aj-0xmp-rcri-TbP1-taiW-Bv5eqZ'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='lvmid/fqOzjT-qps1-L6jh-vNnF-6WzJ-S0rU-Ptuez8/bDh7ac-60Aj-0xmp-rcri-TbP1-taiW-Bv5eqZ'
abcc3b9a-9e49-493b-80f5-825eaec521a1
else
search --no-floppy --fs-uuid --set=root abcc3b9a-9e49-493b-80f5-825eaec521a1
fi
font="/usr/share/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=C
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod cryptodisk
insmod luks
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod lvm
insmod ext2
cryptomount -u ff654a895d9f47869f38dddc1e1f509b
set
root='lvmid/fqOzjT-qps1-L6jh-vNnF-6WzJ-S0rU-Ptuez8/bDh7ac-60Aj-0xmp-rcri-TbP1-taiW-Bv5eqZ'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='lvmid/fqOzjT-qps1-L6jh-vNnF-6WzJ-S0rU-Ptuez8/bDh7ac-60Aj-0xmp-rcri-TbP1-taiW-Bv5eqZ'
abcc3b9a-9e49-493b-80f5-825eaec521a1
else
search --no-floppy --fs-uuid --set=root abcc3b9a-9e49-493b-80f5-825eaec521a1
fi
insmod png
if background_image /usr/share/desktop-base/spacefun-theme/grub/grub-16x9.png;
then
set color_normal=light-gray/black
set color_highlight=white/black
else
set
Bug#1000947: jacal: JACAL should probably default to SCM
Package: jacal Version: 1c7-2 Severity: normal Dear Maintainer, The current versions of mit-scheme, guile-3.0 and guile-2.2 on sid do not work with jacal. mit-scheme fails with: ;The object "\x80;:@\x0;", passed as an argument to string-set!, is not the correct type. ;To continue, call RESTART with an option number: ; (RESTART 1) => Return to read-eval-print level 1. While guile-2.2 and guile-3.0 both fail with: ERROR: In procedure open-file: In procedure open-file: Permission denied: "/usr/share/guile/site/2.2/slibcat" jacal scm starts up and works fine. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/12 CPU threads) 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 Versions of packages jacal depends on: ii guile-2.2 [guile] 2.2.7+1-6+b1 ii guile-3.0 [guile] 3.0.7-1+b1 ii scm5f2-2+b2 ii slib 3b6-3 jacal recommends no packages. jacal suggests no packages. -- no debconf information
Bug#1000936: ccls: Please upgrade to llvm-toolchain-12 or 13
Hi, On Wed, Dec 01, 2021 at 12:10:57AM +0100, Sylvestre Ledru wrote: > Source: ccls > Severity: important > > Dear Maintainer, > > As part of the effort to limit the number of llvm packages in the > archive, it would be great if you could upgrade to -13 (or -12). > > Bookworm won't ship with llvm-toolchain-11 > > llvm-defaults is now pointing to -13. ccls is safe to binNMU. Have you asked release team to setup llvm-defaults transition, so they will binNMU packages when needed.
Bug#995354: Requires to package ruby-thread-local
Fixing this issue requires to update the gem version to 0.56.x. However in this version a new dependency was added on thread-local: https://github.com/socketry/thread-local Regards, Daniel -- Regards, Daniel Leidert | https://www.wgdd.de/ GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78 https://www.fiverr.com/dleidert https://www.patreon.com/join/dleidert signature.asc Description: This is a digitally signed message part
Bug#1000946: gcc-riscv64-unknown-elf: reproducible builds: embeds path to various binaries
Source: gcc-riscv64-unknown-elf
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge shell
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org, kei...@keithp.com
The paths to various binaries are embedded which differs on a usrmerge
vs. non-usrmerge system.
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/gcc-riscv64-unknown-elf.html
/usr/lib/gcc/riscv64-unknown-elf/8.3.0/install-tools/fixincl
/bin/sed
vs.
/usr/bin/sed
/usr/lib/gcc/riscv64-unknown-elf/8.3.0/install-tools/mkheaders
mkinstalldirs="/bin/bash·${itoolsdir}/mkinstalldirs"
vs.
mkinstalldirs="/bin/sh·${itoolsdir}/mkinstalldirs"
Patch attached which passes variables to configure to use the
non-usrmerge locations, as usrmerge installations typically have
compatibility symlinks, but not vice-versa. The patch also sets
variables to ensure consistent values for bash, which can be triggered
when /bin/sh points to bash.
This patch alone does not fix all reproducibility issues (e.g. build
paths, which are only tested on unstable and experimental), but should
build reproducibly in bookworm/testing once binutils-riscv64-unknown-elf
is built with deterministic archives enabled.
Thanks for maintaining gcc-riscv64-unknown-elf!
live well,
vagrant
p.s. more deja-vu?
From 6e8817705e2734392483bc332f1ba1df0212 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Wed, 1 Dec 2021 03:13:30 +
Subject: [PATCH] debian/rules: Pass variables to configure to make the package
build reproducibly regardless of usrmerge.
The variables SED, SHELL, BASH and CONFIG_SHELL should all point to
their non-usrmerge locations.
https://tests.reproducible-builds.org/debian/issues/paths_vary_due_to_usrmerge_issue.html
---
debian/rules | 4
1 file changed, 4 insertions(+)
diff --git a/debian/rules b/debian/rules
index 86fbda13298..c54382b8e4b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -57,6 +57,10 @@ configure_flags = \
--with-gnu-ld \
--with-as=$(target_bin)as \
--with-ld=$(target_bin)ld \
+SED=/bin/sed \
+SHELL=/bin/sh \
+BASH=/bin/bash \
+CONFIG_SHELL=/bin/bash \
$(target_tools) \
$(build_flags) \
CFLAGS_FOR_TARGET='-Os -mcmodel=medany' CXXFLAGS_FOR_TARGET='-Os -mcmodel=medany'
--
2.30.2
signature.asc
Description: PGP signature
Bug#1000945: binutils-riscv64-unknown-elf: reproducible builds: Enable deterministic archives
Package: binutils-riscv64-unknown-elf Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps toolchain Control: affects -1 gcc-riscv64-unknown-elf X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org, kei...@keithp.com binutils-riscv64-unknown-elf is not built with deterministic archives enabled, which causes reproducibility issues in packages using it: https://tests.reproducible-builds.org/debian/issues/unstable/timestamps_in_static_libraries_issue.html The attached patch adds --enable-deterministic-archives to the configure arguments in debian/rules. FWIW, the --enable-deterministic-archives feature was enabled Debian's "binutils" package in 2015. With this feature enabled in binutils-riscv64-unknown-elf, it makes gcc-riscv64-unknown-elf much closer to building reproducibly when using a stable build path. Thanks for maintaining binutils-riscv64-unknown-elf! live well, vagrant p.s. this feels a bit like deja-vu, only the architecture has changed. From d16ad8b64115ff3a6dd51f8e8abd84296fd824cc Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Wed, 1 Dec 2021 02:41:29 + Subject: [PATCH] debian/rules: Pass --enable-deterministic-archives to configure. https://tests.reproducible-builds.org/debian/issues/unstable/timestamps_in_static_libraries_issue.html --- debian/rules | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/rules b/debian/rules index 607373b811..ec0cce3b49 100755 --- a/debian/rules +++ b/debian/rules @@ -27,6 +27,7 @@ configure_flags = \ --enable-plugins \ --enable-interwork \ --with-system-zlib \ + --enable-deterministic-archives \ "--with-pkgversion=$(deb_version)" \ $(buildflags) -- 2.30.2 signature.asc Description: PGP signature
Bug#1000944: apbs: reproducible builds: Timestamps and timing information in io.mc examples
Source: apbs Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Various example io.mc files include timestamps and timing information: https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/apbs.html /usr/share/apbs/examples/FKBP/io.mc #·Creation·Date·and·Time:··Mon·Nov·29·17:45:07·2021 vs. #·Creation·Date·and·Time:··Tue·Jan··3·05:37:35·2023 Vacc_SASA:·Time·elapsed:·1.315417 vs. Vacc_SASA:·Time·elapsed:·1.368298 The attached patch fixes this by removing these files from debian/rules in the dh_auto_install override. If it is not appropriate to remove the io.mc files, another approach might be to sanitize out all the timestamps and timing information, although this would seem likely to be a game of whack-a-mole over time. With this patch applied, apbs should build reproducibly on tests.reproducible-builds.org once it migrates to the the testing/bookworm suite, although unstable and experimental also vary build paths which trigger other issues. Thanks for maintaining apbs! live well, vagrant From 342fc07647699e1987dd8d012f413c4d90898fbd Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Wed, 1 Dec 2021 02:23:08 + Subject: [PATCH] debian/rules: Remove io.mc test suite logs from examples. These files include timestamps and precise timing information which will almost always vary between two builds. https://reproducible-builds.org/docs/timestamps/ --- debian/rules | 3 +++ 1 file changed, 3 insertions(+) diff --git a/debian/rules b/debian/rules index bb4201a..3409962 100755 --- a/debian/rules +++ b/debian/rules @@ -30,6 +30,9 @@ override_dh_auto_build: override_dh_auto_install: dh_auto_install --sourcedir=apbs --destdir=$(CURDIR)/debian/tmp/ + # Remove test suite log files, which include timing + # information which cause reproducibility issues + find debian/tmp/ -name io.mc -delete -print override_dh_auto_clean: dh_auto_clean --sourcedir=apbs -- 2.34.1 signature.asc Description: PGP signature
Bug#987544: RFP: envoyproxy -- high performance C++ distributed proxy designed for single services and applications
On 2021-04-25 11:57 +, Jelmer Vernooij wrote: > * Package name: envoyproxy > * URL : http://envoyproxy.io/ I have just been asked about packaging this so was wondering if anyone has done any work on it yet? There are some binaries but no source at https://deb.dl.getenvoy.io/public/deb/debian/dists With installation described at https://www.envoyproxy.io/docs/envoy/latest/start/install#install-envoy-on-debian-gnu-linux I did try posting to envoy-dev about the above packages last week https://groups.google.com/g/envoy-dev/c/39fGcNZx0NM but no response yet. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#999665: dh_strip_nondeterminism breaks Multi-Arch: same in binNMUs
Hi all, >> As such, I propose that debhelper automatically disables >> dh_strip_nondeterminism if and only if both relevant conditions are met. >> What do you think about this? > > If we go that route, then the conditional would belong in > dh_strip_nondeterminism to disable itself. Just as a bit of throat-clearing, if you've not heard anything from the Reproducible Builds folks (or at least from me…) then the underlying reason is more that I am just not well-versed enough with the binNMU and builddd apparatus to have an informed opinion on this fairly technical and quite wide-reaching topic. In other words, it's not a lack of interest or an uncaring disregard for other parts of Debian (!), something that other mails in this thread might have accidentally implied. I'd be more than happy to change dh_strip_nondeterminism now to fix this longstanding issue for all of us, although with the proviso that the solution we want to get behind can be outlined in brief; and we seem to be close to there. > [Option:] > * We phase out dh_strip_nondeterminism in the next compat level. Not the ideal place for this info but unfortunately I don't think the rest of the archive is in a place to drop strip-nondeterminism on the next compat level. From memory, this is chiefly due to some key toolchain packages, where the required changes are not forthcoming, changes are blocking on upstream, patches have not been applied in Debian, or the discussion has stalled for various reasons. I do very much share your desire to phase out this tool completely and I even introduced a deprecation roadmap for every change that strip-nondeterminism makes for this very reason. But we're just not there... yet. > [Option:] > * debhelper works around dh_strip_nondeterminism deficiencies. Just to be explicit, I totally agree with this. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#975025: flex: reproducible builds: example Makefiles contain build paths
On 2021-01-01, Vagrant Cascadian wrote: > On 2020-11-17, Vagrant Cascadian wrote: >> From 4b9384cc7b73f984507c75f15f293982896135a4 Mon Sep 17 00:00:00 2001 >> From: Vagrant Cascadian >> Date: Wed, 18 Nov 2020 04:04:02 + >> Subject: [PATCH] debian/rules: Remove example autogenerated Makefiles which >> contain build paths. >> >> --- >> debian/rules | 9 + >> 1 file changed, 9 insertions(+) >> >> diff --git a/debian/rules b/debian/rules >> index d0d5597..31a4c72 100755 >> --- a/debian/rules >> +++ b/debian/rules >> @@ -91,6 +91,15 @@ ifneq (,$(filter flex-doc, $(shell dh_listpackages))) >> debian/flex-doc/usr/share/doc/flex-doc/ >> endif >> >> +override_dh_installexamples: >> +dh_installexamples >> +# Remove autogenerated Makefiles which contain embedded build >> +# paths in order to ensure reproducible builds. >> +test ! -f debian/flex/usr/share/doc/flex/examples/fastwc/Makefile || \ >> +rm -f debian/flex/usr/share/doc/flex/examples/fastwc/Makefile >> +test ! -f debian/flex/usr/share/doc/flex/examples/manual/Makefile || \ >> +rm -f debian/flex/usr/share/doc/flex/examples/manual/Makefile >> + >> override_dh_auto_build: >> dh_auto_build >> ifneq (,$(filter flex-doc, $(shell dh_listpackages))) >> -- >> 2.29.2 > > Would very much like to see this land in bullseye... would you consider > uploading soon, or be amenable to an NMU? Still hoping to see this fixed for bookworm! live well, vagrant signature.asc Description: PGP signature
Bug#1000518: logcheck: separate filtering for apt term.log and or unattended-upgrades-dpkg.log etc?
On Tue, 2021-11-30 at 23:05 +0100, Ola Lundqvist wrote: > Emails are sent by default only when apt fails. > > All output is logged to the cron-apt log file. > > Logs are sent to syslog on "upgrade". > By default upgrade is not enabled. Thanks for that info. If this feature gets implemented in logcheck, there could be cron-apt options to apply it to either syslog or mails for each of the types of output cron-apt sends. An option to send mail/syslog for success too would be good for users of this logcheck feature and possibly also users who do processing of the results either in a mail client plugin or in a syslog database and search system like Elasticsearch or Loki. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1000872: [Parl-devel] Bug#1000872: parl-desktop-world depends on removed package.
On Tue, 2021-11-30 at 14:44 +, peter green wrote: > parl-desktop-world depends on thunderbird-l10n-si which is no longer > built from the thunderbird source package, it is still present in > unstable as a cruft package but is completely gone from testing. I suggest to depend on thunderbird-l10n-all, firefox-esr-l10n-all, instead of depending on the individual *-l10n-* packages. You might also want to request -all metapackages for libreoffice/hunspell/etc. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#997756: python-meshplex: FTBFS: sed: no input files
tags 997756 patch thanks Hi, I ran across this FTBFS today and investigated. Here's a patch. The forkme sed now appears unneeded, and the other one needs a URL update. -Dan diff -Nru python-meshplex-0.15.13/debian/rules python-meshplex-0.15.13/debian/rules --- python-meshplex-0.15.13/debian/rules 2021-03-16 04:39:31.0 -0600 +++ python-meshplex-0.15.13/debian/rules 2021-11-30 15:35:13.0 -0700 @@ -4,6 +4,7 @@ #export DH_VERBOSE = 1 export PYBUILD_NAME=meshplex +latestjs=https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js %: dh $@ --with python3,sphinxdoc --buildsystem=pybuild @@ -21,5 +22,4 @@ override_dh_sphinxdoc-indep: dh_sphinxdoc -i - grep "https://cdnjs.cloudflare.com/ajax/libs/mathjax/.*/latest.js; debian/python-meshplex-doc/usr/share/doc/python-meshplex-doc/* -r --files-with-matches | xargs sed "s|src=\"https://cdnjs.cloudflare.com/ajax/libs/mathjax/.*/latest.js|src=\"file://usr/share/javascript/mathjax/unpacked/latest.js|g" -i - grep "https://s3.amazonaws.com/github/ribbons/forkme_right_darkblue_121621.png; debian/python-meshplex-doc/usr/share/doc/python-meshplex-doc/* -r --files-with-matches | xargs sed "s|src=\"https://s3.amazonaws.com/github/ribbons/forkme_right_darkblue_121621.png|src=\"_static/forkme_right_darkblue_121621.png|g" -i + grep "$(latestjs)" debian/python-meshplex-doc/usr/share/doc/python-meshplex-doc/* -r --files-with-matches | xargs sed "s|src=\"$(latestjs)|src=\"file://usr/share/javascript/mathjax/unpacked/latest.js|g" -i
Bug#1000943: python3-libsass: unnecessarily installs test file
Package: python3-libsass Version: 0.20.1-3+b1 Severity: normal Tags: patch I just noticed that python3-libsass installs: /usr/lib/python3/dist-packages/sasstests.py which is a test file. This should probably be excluded from the distributed package, most simply by creating the file debian/python3-libsass.pyremove with the single line: sasstests.py Best wishes, Julian
Bug#1000886: CVE-2013-7445: Direct Rendering Manager (DRM) subsystem in the Linux Kernel through 4.x mishandles requests for GEM object
On 11/30/21 3:02 PM, Salvatore Bonaccorso wrote: Control: tags -1 + security Control: notfound -1 4.0 Hi Salvatore, Thank you for your reply. Thank you. It's usually not necessary to fill bugs for CVEs for src:linux, we are already tracking them and are aware. > In the Sorry for the noise. particular case you can look up CVE-2013-7445 and it's unlikely that it will be addressed. Furthermore CVEs for linux are specifically tracked in the kernel-team as well. What about the other CVEs in the unreported list? (https://security-tracker.debian.org/tracker/status/unreported) Is it worthwhile to try to get them reported? Or is this a low priority because they've already been triaged? Thanks again, Jeremiah
Bug#1000942: rust-zbus-macros - autopkgtest failure, makes reverse dependencies FTBFS.
Package: rust-zbus-macros Version: 1.0.0-3 Severity: serious x-debbugs-cc: deb...@nilux.be The rust-zbus-macros autopkgtest is failing: error[E0432]: unresolved import `zbus` --> /tmp/tmp.2o6G5gYnNc/registry/zbus-1.0.0/src/object_server.rs:54:1 | 54 | #[dbus_interface(name = "org.freedesktop.DBus.Introspectable")] | ^^^ no `Type` in the root | = note: this error originates in the attribute macro `dbus_interface` (in Nightly builds, run with -Z macro-backtrace for more info) I also did test-builds of the reverse dependencies rust-zbus and rust-libslirp (note: I had to manually build mio-0.6 to test rust-libslirp as it is currently sitting in new) and they failed with similar errors, so this is not just an autopkgtest issue. I don't know for certain but I assume that just relaxing the dependency was not enough to make it work correctly with the new version of rust-proc-macro-crate. I also tried doing a test rebuild of rust-libslirp (which afaict is the only binary crate that depends on I took a look in the upstream VCS and found a patch for rust-proc-macro-crate 1 and tried applying it, unfortunately it dependeded on a bunch of other upstream commits. Updating to the latest stable upstream helped a bit with getting the patches to apply and I was able to get a succesful build of rust-zbus-macros 1.9.2 with a pile of upstream patches. Unfortunately when running it's autopkgtests I ran into another issue. It seems that rust-zbus has a strictly versioned dependency on the identical version rust-zbus-macros and rust-zbus 1.9.2 brings several new dependencies. dpkg-checkbuilddeps: error: Unmet build dependencies: librust-async-io-1+default-dev (>= 1.3.1-~~) librust-nb-connect-1+default-dev (>= 1.0.2-~~) librust-polling-2+default-dev (>= 2.0.2-~~) That is pretty much as far as i'm prepared to go. I have pushed my attempts to https://salsa.debian.org/rust-team/debcargo-conf/-/tree/zbus-1.9.2 if anyone else wants to pick them up. The other option would be to prepare/upload a rust-proc-macro-crate-0.1 package and then revert the dependency in rust-zbus-macros. I may do that if noone comes up with a better solution.
Bug#1000941: RM: llvm-toolchain-11 -- ROM; Limit the number of llvm versions
Package: ftp.debian.org Severity: normal Just like with bug #974789 for -9 and #974788 for -10 and many others before, I am opening this to keep track of all the changes needed to be able to get rid of llvm-toolchain-11. Sylvestre
Bug#1000940: ITP: python-scss -- Python binding for libsass
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-sass Version : 2.3 Upstream Author : Sergey Kirillov * URL : https://github.com/pistolero/python-scss * License : Apache 2.0 Programming Lang: Python Description : Python binding for libsass This Python package provides a Python binding for libsass, providing the single method compile_string() to compile Sass strings to CSS. This package is a dependency of qtsass, which is itself a (recursive) dependency of the new version of Spyder. It will be maintained within the Python Packaging Team. Best wishes, Julian
Bug#1000871: [Pkg-tigervnc-devel] Bug#1000871: tigervnc-standalone-server: server fails to start
Primarily the segfault, although the problem is compounded by the absence of documentation, which makes it difficult to know whether I'm doing something wrong with my invocation. On Tue, 30 Nov 2021 23:07:11 +0100 Ola Lundqvist wrote: > Hi > > Just a check question. Is your bug about the lack of useful documentation > or the fact that it segfaults? > It should not segfault... > > // Ola > > On Tue, 30 Nov 2021 at 15:03, Celejar wrote: > > > Package: tigervnc-standalone-server > > Version: 1.11.0+dfsg-3 > > Severity: important > > X-Debbugs-Cc: cele...@gmail.com > > > > This package contains no useful documentation or explanation of how to > > start the server in /usr/share/doc. As per 'man tigervncserver', I > > tried: > > > > * > > > > ~$ tigervncserver > > > > * > > > > And the server promptly segfaulted: > > > > * > > > > New Xtigervnc server '.:1 ()' on port 5901 for > > display :1. > > Use xtigervncviewer -SecurityTypes VncAuth -passwd > > /home//.vnc/passwd :1 to connect to the VNC server. > > > > > > === tail /home//.vnc/.:5901.log > > === > > Segmentation fault > > X connection to :1 broken (explicit kill or server shutdown). > > ComparingUpdateTracker: 0 pixels in / 0 pixels out > > ComparingUpdateTracker: (1:-nan ratio) > > Killing Xtigervnc process ID 9433... success! > > > > == > > > > Session startup via '/etc/X11/Xtigervnc-session' 'startxfce4' cleanly > > exited too early (< 3 seconds)! > > > > Maybe try something simple first, e.g., > > tigervncserver -xstartup /usr/bin/xterm > > The Xtigervnc server cleanly exited! > > The X session cleanly exited! > > > > * > > > > As per the above output, I tried: > > > > * > > > > ~$ tigervncserver -xstartup /usr/bin/xterm > > > > * > > > > No segfault, but it still didn't work: > > > > * > > > > New Xtigervnc server '.:1 ()' on port 5901 for > > display :1. > > Use xtigervncviewer -SecurityTypes VncAuth -passwd > > /home//.vnc/passwd :1 to connect to the VNC server. > > > > > > === tail /home//.vnc/.:5901.log > > === > > > > == > > > > Session startup via '/usr/bin/xterm' 'startxfce4' cleanly exited too early > > (< 3 seconds)! > > > > Maybe try something simple first, e.g., > > tigervncserver -xstartup /usr/bin/xterm > > The X session cleanly exited! > > Killing Xtigervnc process ID 9525... success! > > > > * > > > > -- System Information: > > Debian Release: bookworm/sid > > APT prefers unstable > > APT policy: (500, 'unstable') > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) > > 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 > > > > Versions of packages tigervnc-standalone-server depends on: > > ii libaudit1 1:3.0.6-1+b1 > > ii libbsd0 0.11.3-1 > > ii libc6 2.32-4 > > ii libfile-readbackwards-perl 1.06-1 > > ii libgcrypt20 1.9.4-4 > > ii libgl1 1.3.4-2+b1 > > ii libgnutls30 3.7.2-2 > > ii libjpeg62-turbo 1:2.1.2-1 > > ii libpam0g1.4.0-10 > > ii libpixman-1-0 0.40.0-1 > > ii libselinux1 3.3-1+b1 > > ii libstdc++6 11.2.0-12 > > ii libsystemd0 249.7-1 > > ii libunwind8 1.3.2-2 > > ii libxau6 1:1.0.9-1 > > ii libxdmcp6 1:1.1.2-3 > > ii libxfont2 1:2.0.5-1 > > ii perl5.32.1-6 > > ii tigervnc-common 1.11.0+dfsg-3 > > ii x11-xkb-utils 7.7+5 > > ii xauth 1:1.1-1 > > ii xkb-data2.33-1 > > ii zlib1g 1:1.2.11.dfsg-2 > > > > Versions of packages tigervnc-standalone-server recommends: > > ii libgl1-mesa-dri21.2.6-1 > > ii x11-xserver-utils 7.7+9 > > ii xfonts-base1:1.0.5 > > > > Versions of packages tigervnc-standalone-server suggests: > > ii xfonts-100dpi1:1.0.4+nmu1.1 > > ii xfonts-75dpi 1:1.0.4+nmu1.1 > > ii xfonts-scalable 1:1.0.3-1.2 > > > > -- no debconf information > > > > ___ > > Pkg-tigervnc-devel mailing list > > pkg-tigervnc-de...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-tigervnc-devel > > > > > -- > - Ola Lundqvist --- > / o...@debian.org
Bug#1000939: aiscm: Please upgrade to llvm-toolchain-12 or 13
Source: aiscm Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000938: autofdo: Please upgrade to llvm-toolchain-12 or 13
Source: autofdo Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000937: bpftrace: Please upgrade to llvm-toolchain-12 or 13
Source: bpftrace Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000936: ccls: Please upgrade to llvm-toolchain-12 or 13
Source: ccls Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000935: astra-toolbox/contrib: Please upgrade to llvm-toolchain-12 or 13
Source: astra-toolbox/contrib Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000934: clazy: Please upgrade to llvm-toolchain-12 or 13
Source: clazy Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000933: bpfcc: Please upgrade to llvm-toolchain-12 or 13
Source: bpfcc Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000932: doxygen: Please upgrade to llvm-toolchain-12 or 13
Source: doxygen Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000931: castxml: Please upgrade to llvm-toolchain-12 or 13
Source: castxml Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000930: faust: Please upgrade to llvm-toolchain-12 or 13
Source: faust Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#978911: transmission: diff for NMU version 3.00-1.1
> I've prepared an NMU for transmission (versioned as 3.00-1.1) and > uploaded it to DELAYED/5. Please feel free to tell me if I > should delay it longer. please remove it from the delayed queue, there's no need for a nmu here -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#1000929: ghc: Please upgrade to llvm-toolchain-12 or 13
Source: ghc Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000928: codelite: Please upgrade to llvm-toolchain-12 or 13
Source: codelite Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000927: creduce: Please upgrade to llvm-toolchain-12 or 13
Source: creduce Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000926: gnome-builder: Please upgrade to llvm-toolchain-12 or 13
Source: gnome-builder Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000925: kdevelop: Please upgrade to llvm-toolchain-12 or 13
Source: kdevelop Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000924: libclang-perl: Please upgrade to llvm-toolchain-12 or 13
Source: libclang-perl Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000923: ghdl: Please upgrade to llvm-toolchain-12 or 13
Source: ghdl Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000922: llvmlite: Please upgrade to llvm-toolchain-12 or 13
Source: llvmlite Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000921: syncevolution: reproducible builds: Embedded build timestamps in README and manpage
Source: syncevolution
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
The README, README.html and syncevolution manpage embeds the build
timestamp:
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/syncevolution.html
/usr/share/doc/syncevolution/README.gz
:Date:·2022-12-28
vs.
:Date:·2021-11-25
/usr/share/man/man1/syncevolution.1.gz
.TH·"SYNCEVOLUTION"·1·"2022-12-28"·"2.0.0"·""
vs.
.TH·"SYNCEVOLUTION"·1·"2021-11-25"·"2.0.0"·""
The attached patch fixes these files by not replacing the release date
in these files from Makefile.am.
An alternate approach might be to remove the dates from the relevent
source files entirely.
With this patch applied, syncevolution should build reproducibly on
tests.reproducible-builds.org.
Thanks for maintaining syncevolution!
live well,
vagrant
From dc3eb847d180baf0b3ec0151123fa66ebeb15108 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Tue, 30 Nov 2021 22:33:15 +
Subject: [PATCH] Makefile.am: Do not update the datestatmps in the various
.rst files.
https://reproducible-builds.org/docs/timestamps/
---
Makefile.am | 2 --
1 file changed, 2 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 9c550951..68533f9c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -351,7 +351,6 @@ README.patched.rst: README.rst src/syncevolution
-e 'sub run { $$cmd = shift; $$buffer = `env LD_LIBRARY_PATH=src/syncevo/.libs:src/gdbusxx/.libs:src/build-synthesis/src/.libs:$$ENV{LD_LIBRARY_PATH} $$cmd`; $(RUN_SYNCEVOLUTION_CHECK) }' \
-e 'while (<>) {' \
-e 's/^:Version: .*/:Version: $(VERSION)/;' \
- -e 's/:Date: .*/":Date: " . `date +%Y-%m-%d`/e;' \
-e 'if (s;(<< see "syncevolution --sync-property ." >>\n);run("src/syncevolution --daemon=no --sync-property ?") || $$1;e) { $$syncfound=1; }' \
-e 'if (s;(<< see "syncevolution --datastore-property ." >>\n);run("src/syncevolution --daemon=no --source-property ?") || $$1;e) { $$sourcefound=1; }' \
-e 'print;' \
@@ -365,7 +364,6 @@ else
README.patched.rst: README.rst
$(AM_V_GEN)perl -p \
-e 's/^:Version: .*/:Version: $(VERSION)/;' \
- -e 's/:Date: .*/":Date: " . `date +%Y-%m-%d`/e;' \
$< >$@
endif
CLEANFILES += README.patched.rst
--
2.34.1
signature.asc
Description: PGP signature
Bug#1000920: rtags: Please upgrade to llvm-toolchain-12 or 13
Source: rtags Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000919: ldc: Please upgrade to llvm-toolchain-12 or 13
Source: ldc Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000918: sparse: Please upgrade to llvm-toolchain-12 or 13
Source: sparse Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000917: libclc: Please upgrade to llvm-toolchain-12 or 13
Source: libclc Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000916: vboot-utils: Please upgrade to llvm-toolchain-12 or 13
Source: vboot-utils Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000915: postgresql-14: Please upgrade to llvm-toolchain-12 or 13
Source: postgresql-14 Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000914: pyside2: Please upgrade to llvm-toolchain-12 or 13
Source: pyside2 Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000913: qtcreator: Please upgrade to llvm-toolchain-12 or 13
Source: qtcreator Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000912: qttools-opensource-src: Please upgrade to llvm-toolchain-12 or 13
Source: qttools-opensource-src Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000910: wasi-libc: Please upgrade to llvm-toolchain-12 or 13
Source: wasi-libc Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000911: rust-bindgen: Please upgrade to llvm-toolchain-12 or 13
Source: rust-bindgen Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000909: ycmd: Please upgrade to llvm-toolchain-12 or 13
Source: ycmd Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -13 (or -12). Bookworm won't ship with llvm-toolchain-11 llvm-defaults is now pointing to -13. Thanks, Sylvestre
Bug#1000908: procps ships with a file in /usr/lib/sysctl.d/ that does not start with a pair of digits
Package: procps Version: 2:3.3.17-5 Hi, Procps includes a sysctl configuration file in /usr/lib/sysctl.d/ that disallows root from overwriting group-writable files in setgid directories. As this interferes with our backup script, we initially tried to override it with a local file in /etc/sysctl.d, but this at first failed due to the "interesting" way how systemd manages priorities among those configuration files. Apparently, systemd recommends to call those files NN-xyz.conf, with NN being a pair of decimals to be used for ordering, as detailed in Lennart Poettering's answer to this bug-report: https://github.com/systemd/systemd/issues/20919 Procps' protect-links.conf file does unfortunately not follow this convention. If for example the file was called 10-protect-links.conf, sysadmins could easily override it by calling their file 99-allow-links.conf We solved the issue locally by calling our file zz-allow-links.conf, but I thought I'd mention this here in order to spare a lengthy search to fellow sysadmins who might have the same need. Thanks, Alain
Bug#1000907: ITP: heaptrace -- helps visualize heap operations for pwn and debugging
Package: wnpp Severity: wishlist * Package name: heaptrace Version : 2.2.8 * URL : https://github.com/Arinerron/heaptrace Binary URL : https://github.com/Arinerron/heaptrace/releases/download/2.2.8/heaptrace_2.2.8-0_x86_64.deb * License : BSD-3-Clause Programming Lang: C Description : helps visualize heap operations for pwn and debugging heaptrace is a heap debugger for tracking glibc heap operations in ELF64 (x86_64) binaries. Its purpose is to help visualize heap operations when debugging binaries or doing heap pwn. It would be nice to be able to have this package in the Debian repositories so that it's easier to install and without building.
Bug#1000722: [Pkg-javascript-devel] Bug#1000722: Bug#1000722: Bug#1000722: Bug#1000722: Please ship TypeScript definitions
Le mardi 30 novembre 2021 à 23:25 +0100, Jonas Smedegaard a écrit : > > > Sorry, let me clarify: > > This command: > > apt-cache show node-lodash-packages |grep Version > > does not reliably tell you if TypeScript definitions are provided, so > is > dependent on someone telling you which magic version to look for. > > > This command, however: > > apt-cache search node-types-lodash.escape > > tells you which binary package either is or virtually provides the > package "node-types-lodash.escape". > Ah, but I knew which package I wanted already -- I just needed to see if the right experimental version was available, so apt-cache show was the right thing. Cheers, J.Puydt
Bug#1000906: RM: bareos -- RoQA; Really RC-buggy, unmaintained
Package: ftp.debian.org Severity: normal Please remove bareos. It has nine open RC bugs, the last maintainer upload was in Feb 2019 and there was no objection to my removal proposal at #995837 for two months. Cheers, Moritz
Bug#1000905: base-files: Internal laptop keyboard not recognized and not working
Package: base-files Version: 11.1+deb11u1 Severity: important X-Debbugs-Cc: nikk0s.mo...@gmail.com Dear Maintainer, * What led up to the situation? System startup on an ASUS Zenbook UM425QA-KI072T * What exactly did you do (or not do) that was effective (or ineffective)? NA * What was the outcome of this action? Keyboard only available in GRUB boot menu, then unavailable after system startup, nor with Debian installer. Try to configure keyboard in System settings, with no success. Workaround : using external USB keyboard Note : Problem observed in other "derived" Debian distributions like Mint 20.2, but keyboard fully functional with Manjaro 21.1.6 * What outcome did you expect instead? Internal keyboard recognized and functional -- System Information: Debian Release: 11.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/16 CPU threads) 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 Versions of packages base-files depends on: ii mawk [awk] 1.3.4.20200120-2 base-files recommends no packages. base-files suggests no packages. -- no debconf information
Bug#1000904: RM: pycalendar -- RoQA; Depends on Python 2, dead upstream, unmaintained
Package: ftp.debian.org Severity: normal Please remove pycalendar. It depends on Python 2, is dead upstream (upstream issue for Py3 support is open since 2017 without action), there are no reverse dependencies (just a Recommends: by caldav-tester, but it's dropped from testing since a year for being RC-buggy as well) and the last maintainer upload was in 2017. Cheers, Moritz
Bug#1000903: ITP: qtsass -- Python package to bridge the gap between SASS and Qt-CSS
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: qtsass Version : 0.3.0+git20200324.06f1519 Upstream Author : Spyder Project Contributors * URL : https://github.com/spyder-ide/qtsass * License : MIT Programming Lang: Python Description : Python package to bridge the gap between SASS and Qt-CSS SASS brings countless amazing features to CSS. Besides being used in web development, CSS is also the way to stylize Qt-based desktop applications. However, Qt's CSS has a few variations that prevent the direct use of SASS compiler. The purpose of this tool is to fill the gap between SASS and Qt-CSS by handling those variations. The goal of QtSASS is to be able to generate a Qt-CSS stylesheet based on a 100% valid SASS file. This package is a (recursive) dependency of the new version of Spyder. It will be maintained within the Debian Python Team. Best wishes, Julian
Bug#1000902: RM: python-mode -- RoQA; orphaned, RC-buggy
Package: ftp.debian.org Severity: normal Please remove python-mode. It's RC-buggy (missed Bullseye, dropped from testing for > 15 months) and orphaned without an adopter since Sep 2020. Cheers, Moritz
Bug#978911: transmission: diff for NMU version 3.00-1.1
Control: tags 978911 + pending
Dear maintainer,
I've prepared an NMU for transmission (versioned as 3.00-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru transmission-3.00/debian/changelog transmission-
3.00/debian/changelog
--- transmission-3.00/debian/changelog 2020-05-28 22:05:37.0 -0400
+++ transmission-3.00/debian/changelog 2021-11-30 17:18:21.0 -0500
@@ -1,3 +1,10 @@
+transmission (3.00-1.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Fix FTBFS with autoconf 2.70. (Closes: #978911)
+
+ -- Boyuan Yang Tue, 30 Nov 2021 17:18:21 -0500
+
transmission (3.00-1) unstable; urgency=medium
* New upstream release; Closes: #960362
diff -Nru transmission-3.00/debian/patches/build_new_autoconf.patch
transmission-3.00/debian/patches/build_new_autoconf.patch
--- transmission-3.00/debian/patches/build_new_autoconf.patch 1969-12-31
19:00:00.0 -0500
+++ transmission-3.00/debian/patches/build_new_autoconf.patch 2021-11-30
17:17:10.0 -0500
@@ -0,0 +1,24 @@
+From: Sebastien Bacher
+Date: Fri, 12 Nov 2021 16:38:40 +0100
+Subject: Fix FTBFS with autoconf 2.70
+
+Bug-Debian: https://bugs.debian.org/978911
+---
+ configure.ac | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 211ca36..c457351 100644
+--- a/configure.ac
b/configure.ac
+@@ -555,9 +555,7 @@ dnl it should be safe to re-edit 0.40 back down to 0.23
+ use_nls=no
+ if test "x$enable_nls" = "xyes" ; then
+ use_nls=yes
+-m4_ifdef([IT_PROG_INTLTOOL],
+- [IT_PROG_INTLTOOL([0.35.0],[no-xml])],
+- [AC_MSG_ERROR("--enable-nls requires intltool to be
installed.")])
++IT_PROG_INTLTOOL([0.35.0],[no-xml])
+ AC_CHECK_HEADERS([libintl.h])
+ GETTEXT_PACKAGE=transmission-gtk
+ AC_SUBST(GETTEXT_PACKAGE)
diff -Nru transmission-3.00/debian/patches/series transmission-
3.00/debian/patches/series
--- transmission-3.00/debian/patches/series 2020-05-28 22:05:37.0
-0400
+++ transmission-3.00/debian/patches/series 2021-11-30 17:17:34.0
-0500
@@ -3,3 +3,4 @@
transmission-daemon_execstop_service.patch
ayatana-indicators.patch
patch-vendored-libdht.patch
+build_new_autoconf.patch
signature.asc
Description: This is a digitally signed message part
Bug#1000722: [Pkg-javascript-devel] Bug#1000722: Bug#1000722: Bug#1000722: Bug#1000722: Please ship TypeScript definitions
Quoting Julien Puydt (2021-11-30 22:14:17) > Le dimanche 28 novembre 2021 à 17:30 +0100, Jonas Smedegaard a écrit : > > Quoting Julien Puydt (2021-11-28 17:01:56) > > > Le dimanche 28 novembre 2021 à 15:38 +0100, Yadd a écrit : > > > > > > > > please try with node-lodash-packages > > > > 4.17.21+dfsg+~cs8.31.198.20210220- > > > > 2 > > > > from experimental. > > > > > > I don't see it yet: > > > apt-cache show node-lodash-packages |grep Version > > > Version: 4.17.21+dfsg+~cs8.31.196.20210220-2 > > > > Not sure, but seems the above command is unreliable, and this one > > works: > > > > apt-cache search node-types-lodash.escape > > > > No, it's reliable, but I think I was using a mirror and it took time > to get in sync. Now I could install the new package, and it looks like > it would do the trick. Sorry, let me clarify: This command: apt-cache show node-lodash-packages |grep Version does not reliably tell you if TypeScript definitions are provided, so is dependent on someone telling you which magic version to look for. This command, however: apt-cache search node-types-lodash.escape tells you which binary package either is or virtually provides the package "node-types-lodash.escape". - 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#1000511: bullseye-pu: package debian-edu-config/2.11.56+deb11u2
Hi Adam, [ Adam D. Barratt, 2021-11-30 ] > Control: tags -1 + moreinfo > > On Wed, 2021-11-24 at 13:29 +0100, Wolfgang Schweer wrote: > > It has been detected on real world deployments that some needed > > changes > > due to the re-written LTSP in bullseye have not been addressed > > properly > > or are missing, so: > > (1) Fix TFTP server path (/var/lib/tftpboot-> /srv/tftp), #995610 > > (2) Add real support for LTSP chroot setup and maintenance, #996103 > > > > The metadata for the first bug implies that it affects unstable and is > not yet fixed there. Could you please confirm the status? Yes, the bug is also fixed in unstable, please see the first changelog entry: https://tracker.debian.org/news/1266906/accepted-debian-edu-config-2125-source-into-unstable/ Kind regards, Wolfgang signature.asc Description: PGP signature
Bug#1000871: [Pkg-tigervnc-devel] Bug#1000871: tigervnc-standalone-server: server fails to start
Hi Just a check question. Is your bug about the lack of useful documentation or the fact that it segfaults? It should not segfault... // Ola On Tue, 30 Nov 2021 at 15:03, Celejar wrote: > Package: tigervnc-standalone-server > Version: 1.11.0+dfsg-3 > Severity: important > X-Debbugs-Cc: cele...@gmail.com > > This package contains no useful documentation or explanation of how to > start the server in /usr/share/doc. As per 'man tigervncserver', I > tried: > > * > > ~$ tigervncserver > > * > > And the server promptly segfaulted: > > * > > New Xtigervnc server '.:1 ()' on port 5901 for > display :1. > Use xtigervncviewer -SecurityTypes VncAuth -passwd > /home//.vnc/passwd :1 to connect to the VNC server. > > > === tail /home//.vnc/.:5901.log > === > Segmentation fault > X connection to :1 broken (explicit kill or server shutdown). > ComparingUpdateTracker: 0 pixels in / 0 pixels out > ComparingUpdateTracker: (1:-nan ratio) > Killing Xtigervnc process ID 9433... success! > > == > > Session startup via '/etc/X11/Xtigervnc-session' 'startxfce4' cleanly > exited too early (< 3 seconds)! > > Maybe try something simple first, e.g., > tigervncserver -xstartup /usr/bin/xterm > The Xtigervnc server cleanly exited! > The X session cleanly exited! > > * > > As per the above output, I tried: > > * > > ~$ tigervncserver -xstartup /usr/bin/xterm > > * > > No segfault, but it still didn't work: > > * > > New Xtigervnc server '.:1 ()' on port 5901 for > display :1. > Use xtigervncviewer -SecurityTypes VncAuth -passwd > /home//.vnc/passwd :1 to connect to the VNC server. > > > === tail /home//.vnc/.:5901.log > === > > == > > Session startup via '/usr/bin/xterm' 'startxfce4' cleanly exited too early > (< 3 seconds)! > > Maybe try something simple first, e.g., > tigervncserver -xstartup /usr/bin/xterm > The X session cleanly exited! > Killing Xtigervnc process ID 9525... success! > > * > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) > 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 > > Versions of packages tigervnc-standalone-server depends on: > ii libaudit1 1:3.0.6-1+b1 > ii libbsd0 0.11.3-1 > ii libc6 2.32-4 > ii libfile-readbackwards-perl 1.06-1 > ii libgcrypt20 1.9.4-4 > ii libgl1 1.3.4-2+b1 > ii libgnutls30 3.7.2-2 > ii libjpeg62-turbo 1:2.1.2-1 > ii libpam0g1.4.0-10 > ii libpixman-1-0 0.40.0-1 > ii libselinux1 3.3-1+b1 > ii libstdc++6 11.2.0-12 > ii libsystemd0 249.7-1 > ii libunwind8 1.3.2-2 > ii libxau6 1:1.0.9-1 > ii libxdmcp6 1:1.1.2-3 > ii libxfont2 1:2.0.5-1 > ii perl5.32.1-6 > ii tigervnc-common 1.11.0+dfsg-3 > ii x11-xkb-utils 7.7+5 > ii xauth 1:1.1-1 > ii xkb-data2.33-1 > ii zlib1g 1:1.2.11.dfsg-2 > > Versions of packages tigervnc-standalone-server recommends: > ii libgl1-mesa-dri21.2.6-1 > ii x11-xserver-utils 7.7+9 > ii xfonts-base1:1.0.5 > > Versions of packages tigervnc-standalone-server suggests: > ii xfonts-100dpi1:1.0.4+nmu1.1 > ii xfonts-75dpi 1:1.0.4+nmu1.1 > ii xfonts-scalable 1:1.0.3-1.2 > > -- no debconf information > > ___ > Pkg-tigervnc-devel mailing list > pkg-tigervnc-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-tigervnc-devel > -- - Ola Lundqvist --- / o...@debian.org o...@inguza.com \ | http://inguza.com/ +46 (0)70-332 1551 | ---
Bug#1000518: logcheck: separate filtering for apt term.log and or unattended-upgrades-dpkg.log etc?
Hi Paul If my memory is correct. I should know since I wrote the cron-apt software but it was quite some time ago. ... Checking the code now to refresh my memory... Emails are sent by default only when apt fails. All output is logged to the cron-apt log file. Logs are sent to syslog on "upgrade". By default upgrade is not enabled. I'm not sure this helps in any way, but I thought I could at least respond with what I know. Cheers // Ola On Wed, 24 Nov 2021 at 14:42, Paul Wise wrote: > Package: logcheck > Severity: wishlist > X-Debbugs-CC: a...@packages.debian.org, > unattended-upgra...@packages.debian.org, cron-...@packages.debian.org, > aptitude-ro...@packages.debian.org > > Currently logcheck focuses on /var/log/syslog and /var/log/auth.log but > it would be nice to have separate filtering for other types of logs > that normally don't get merged into syslog or the journal. > > One of those types of logs is apt upgrade logs. When apt itself is > invoked, it sends terminal output (including \r but not colours) to the > apt term.log file. If unattended-upgrades is being run then the same > output and also output of the apt hooks goes to the additional log file > unattended-upgrades-dpkg.log (which also contains \r but not colours). > The unattended-upgrades code may also send a mail with that log output > but without any \r or colors. > > The unattended-upgrades wrapper around apt print various uninteresting > messages. The cron-apt/aptitude-robot alternatives probably also do the > same. apt itself prints a lot of messages that aren't interesting. > The apt hooks shipped by various packages print various uninteresting > messages. The maintainer scripts shipped by various packages print > various uninteresting messages. > > I'm currently using the attached hacky script with lots of regexes to > implement apt upgrade log filtering. It seems to me that a better way > to do this would be to integrate separate apt filtering into logcheck > and then integrate into each package (including apt) logcheck ignore > configs containing the regexes that represent uninteresting messages. > > There could be an apt hook to use logcheck to filter the apt term.log > to an apt term-interesting.log and an unattended-upgrades hook to > filter unattended-upgrades-dpkg.log to a corresponding file and an > option/hook to filter unattended-upgrades mails. The same could be done > for cron-apt/aptitude-robot. > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise > -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
Bug#1000900: linux-image-5.10.0-9-armmp: Kernel panic on boot with Ethernet cable plugged in
Control: severity -1 important Control: tags -1 + moreinfo Hi, On Tue, Nov 30, 2021 at 10:35:39PM +0100, inasprecali wrote: > Package: src:linux > Version: 5.10.70-1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > the system I'm currently writing this report from (a BeagleBone black) > apparently failed to boot after upgrading the kernel to > linux-image-5.10.0-9-armp (the latest stable version at the moment). > > Booting again with a serial terminal connected, I was able to determine > that there was a kernel panic on boot. Unfortunately, my experience with > Linux kernel devleopment is too limited to make sense of the backtrace > (which I'm going to provide below). > > Curiously enough, booting without an Ethernet cable plugged in and > connecting it only /after/ the system boots up seems to work as expected. > The board works and it is able to connect to the network. > This issue is present only in linux-image-5.10.0-9-armp. 5.10.0-8, the > previous version, did not have this issue, which is why I'm currently > using that kernel. > > -- Kernel backtrace: > > [ 15.189004] 8<--- cut here --- > [ 15.192362] Unable to handle kernel NULL pointer dereference at virtual > address 0008 > [ 15.200830] pgd = (ptrval) > [ 15.203650] [0008] *pgd= > [ 15.207413] Internal error: Oops: 5 [#1] SMP ARM > [ 15.212225] Modules linked in: musb_dsps(E) musb_hdrc(E) udc_core(E) > usbcore(E) phy_am335x(E+) phy_am335x_control(E) phy_generic(E) > [ 15.224588] CPU: 0 PID: 68 Comm: kworker/0:6 Tainted: GE > 5.10.0-9-armmp #1 Debian 5.10.70-1 > [ 15.234733] Hardware name: Generic AM33XX (Flattened Device Tree) > [ 15.241098] Workqueue: events deferred_probe_work_func > [ 15.246466] PC is at dsps_musb_init+0x38/0x1e8 [musb_dsps] > [ 15.252224] LR is at musb_probe+0x1cc/0xdd8 [musb_hdrc] > [ 15.257668] pc : []lr : []psr: a00f0013 > [ 15.264191] sp : cf173c98 ip : cf173cc8 fp : cf173cc4 > [ 15.269630] r10: 000f r9 : bf103048 r8 : > [ 15.275069] r7 : bf105580 r6 : c1951040 r5 : c1950040 r4 : cf2db010 > [ 15.281865] r3 : bf021298 r2 : bf022344 r1 : 0200 r0 : cf0c0c00 > [ 15.288664] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment > none > [ 15.296095] Control: 10c5387d Table: 8f2bc019 DAC: 0051 > [ 15.302078] Process kworker/0:6 (pid: 68, stack limit = 0x(ptrval)) > [ 15.308603] Stack: (0xcf173c98 to 0xcf174000) > [ 15.313140] 3c80: > c0d0e22c > [ 15.321660] 3ca0: cf173cc4 c1950040 e400 c1951040 bf105580 c15ed5ec > cf173d8c cf173cc8 > [ 15.330179] 3cc0: bf0eb5cc bf0212a4 c0ae5e98 c0d0e22c cf173d28 > c105a4b0 df96e300 > [ 15.338699] 3ce0: cf173d1c cf173cf0 0034 c0ae5e20 cf2db010 > cf2db000 cf15f5c0 > [ 15.347220] 3d00: bf103048 c15ed5ec bf103048 cf173d64 cf173d20 > c0ae649c c0ae5ed0 > [ 15.355742] 3d20: c10a3558 > > [ 15.364263] 3d40: 90fccf43 cf173d84 cf2db010 > cf173d7c 90fccf43 > [ 15.372783] 3d60: c09ab5f8 cf2db010 bf103048 c15ed5ec > bf103048 000f > [ 15.381303] 3d80: cf173dac cf173d90 c0991a34 bf0eb40c cf2db010 c15ed5e4 > > [ 15.389821] 3da0: cf173dec cf173db0 c098ee58 c09919e8 cf2db010 cf2db010 > cf2db118 > [ 15.398341] 3dc0: cf173dec cf2db010 bf103048 cf173e74 cf2db010 > c1068510 c1590788 > [ 15.406863] 3de0: cf173e1c cf173df0 c098f6f0 c098ed5c cf173e74 cf2db010 > 0001 bf103048 > [ 15.415384] 3e00: cf173e74 cf2db010 c1068510 cf173e3c cf173e20 > c098f9b8 c098f5fc > [ 15.423904] 3e20: cf173e74 c098f924 c1554d60 cf173e6c cf173e40 > c098c718 c098f930 > [ 15.432423] 3e40: cf173e6c c18fbc6c cf3c57b8 90fccf43 cf2db010 cf2db010 > 0001 cf2db054 > [ 15.440942] 3e60: cf173e9c cf173e70 c098f32c c098c694 c1554d0c cf2db010 > 0001 90fccf43 > [ 15.449463] 3e80: cf173eb4 cf3c5e54 c1554fd8 cf2db010 cf173eac cf173ea0 > c098fa38 c098f258 > [ 15.457982] 3ea0: cf173ecc cf173eb0 c098dc78 c098fa28 cf3c5e54 cf2db010 > c1554d0c c1554d60 > [ 15.466505] 3ec0: cf173efc cf173ed0 c098e5d8 c098dbf0 c098e530 c1554d44 > cf151d80 df940500 > [ 15.475022] 3ee0: df943900 cf173f3c cf173f00 > c036dcf8 c098e53c > [ 15.483542] 3f00: cf148000 cf172000 cf173f24 cf173f18 c036f3a8 cf151d80 > df940500 cf151d94 > [ 15.492061] 3f20: df940518 c1404d00 0008 df940500 cf173f74 cf173f40 > c036e0b4 c036db28 > [ 15.500580] 3f40: cf173f64 cf172000 cf173f74 cf153940 cf153100 > cf172000 c036e04c > [ 15.509101] 3f60: cf151d80 cf171e84 cf173fac cf173f78 c0374be0 c036e058 > e000 cf153964 > [ 15.517619] 3f80: cf173fac cf153100 c0374a78 > > [ 15.526139] 3fa0: cf173fb0
Bug#1000901: ITP: aml -- Andri's Main Loop library
Package: wnpp Severity: wishlist Owner: Boyuan Yang * Package name: aml Version : 0.2.0 Upstream Author : Andri Yngvason * URL : https://github.com/any1/aml/ * License : ISC Programming Lang: C/C++ Description : Andri's Main Loop library Libaml provides an event loop library that aims at portability, utility and simplicity. This package is a dependency of wayvnc ( https://github.com/any1/wayvnc ). -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1000881: firmware-iwlwifi: No Bluetooth controller detected with kernel 5.15
Control: tags -1 + moreinfo On Tue, Nov 30, 2021 at 12:42:03PM +0100, Léo Girardin wrote: > Package: firmware-iwlwifi > Version: 20210818-1 > Severity: important > > Dear Maintainer, > >* What led up to the situation? > Kernel upgrade from 5.14.0-4 to 5.15.0-1 > >* What exactly did you do (or not do) that was effective (or > ineffective)? > Open the Bluetooth window in Gnome preferences to pair my laptop with > an external device. > > Also, enter `show` in bluetoothctl prompt. > >* What was the outcome of this action? > In Gnome preferences, it is written (in French) "Pas de réseau > Bluetooth trouvé", which translates as "No detected Bluetooth network" > (I guess). > > In bluetoothctl, `show` returns No default controller available. > >* What outcome did you expect instead? > Before the kernel upgrade Bluetooth was working fine. My laptop has an > Intel AX200 wireless controller that requires firmware-iwlwifi. Wifi > is still functionning as usual. > If I reboot and select in Grub the previous kernel 5.14.0-4, Bluetooth > is working again. I suspect this is the same as #1000403, please can you retest with 5.15.5-1 in unstable (and 5.16~rc3-1~exp1 from experimental)? Regards, Salvatore
Bug#1000899: python-pyproj: no longer builds for all Python versions; blocks build of pyresample
Source: python-pyproj Version: 3.3.0-1 Severity: serious python-pyproj (3.3.0-1) unstable; urgency=medium . * New upstream release. * Only build for the default Python, numpy has not been built with 3.10 yet. * Move from experimental to unstable. This is not helpful during a transition where support for Python 3.10 is added. This prevents pyresample from being built. Please revert Cheers -- Sebastian Ramacher
Bug#895874: Same bug still present, same fix, in bullseye
I can confirm the same bug and the same solution (libmailtools-perl) present in debian 11 bullseye... --Simon
Bug#1000722: [Pkg-javascript-devel] Bug#1000722: Bug#1000722: Bug#1000722: Please ship TypeScript definitions
Le dimanche 28 novembre 2021 à 17:30 +0100, Jonas Smedegaard a écrit : > Quoting Julien Puydt (2021-11-28 17:01:56) > > Le dimanche 28 novembre 2021 à 15:38 +0100, Yadd a écrit : > > > > > > please try with node-lodash-packages > > > 4.17.21+dfsg+~cs8.31.198.20210220- > > > 2 > > > from experimental. > > > > I don't see it yet: > > apt-cache show node-lodash-packages |grep Version > > Version: 4.17.21+dfsg+~cs8.31.196.20210220-2 > > Not sure, but seems the above command is unreliable, and this one > works: > > apt-cache search node-types-lodash.escape > No, it's reliable, but I think I was using a mirror and it took time to get in sync. Now I could install the new package, and it looks like it would do the trick. Cheers, J.Puydt
Bug#1000897: lift: reproducible builds: Embedded timestamps in man pages dependent on timezone
Source: lift Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org The build timestamp in various manpages varies dependent on timezone: https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/i386/diffoscope-results/lift.html /usr/share/man/man1/lift.1.gz .TH·"LIFT"·1·"2016-09-25"·"2.5.0"·"Lift·Manual" vs. .TH·"LIFT"·1·"2016-09-26"·"2.5.0"·"Lift·Manual" The attached patch fixes by removing the date in the two doc/*.rst files used to generate the manpages. With this patch applied, lift should build reproducibly on tests.reproducible-builds.org. Thanks for maintaining lift! live well, vagrant From f57c8830c2bc9b8b98787a6ffed03db0cc9354c1 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Tue, 30 Nov 2021 21:01:35 + Subject: [PATCH] doc/lift*.rst: Remove date from documentation to build reproducibly. Embedding the build date without updating the content of the document is not a particularly useful date. https://reproducible-builds.org/docs/timestamps/ --- doc/lift.rst | 1 - doc/lift.yaml.rst | 1 - 2 files changed, 2 deletions(-) diff --git a/doc/lift.rst b/doc/lift.rst index 598536b..49e62af 100644 --- a/doc/lift.rst +++ b/doc/lift.rst @@ -9,7 +9,6 @@ Run a Lift test suite :Authors: Written an maintained by Nicolas Delvaux :Version: 2.5.0 -:Date: |date| :Copyright: GPL2+ :Manual section: 1 :Manual group: Lift Manual diff --git a/doc/lift.yaml.rst b/doc/lift.yaml.rst index 82588d5..d5b11ec 100644 --- a/doc/lift.yaml.rst +++ b/doc/lift.yaml.rst @@ -9,7 +9,6 @@ Define a Lift test suite :Authors: Written an maintained by Nicolas Delvaux :Version: 2.5.0 -:Date: |date| :Copyright: GPL2+ :Manual section: 1 :Manual group: Lift Manual -- 2.30.2 signature.asc Description: PGP signature
Bug#1000898: forensics-extra: allow co-installation with exfat-utils
Package: forensics-extra Version: 2.29 Severity: normal Dear Maintainer, 'forensics-extra' currently has a hard dependency on 'exfatprogs'. 'exfatprogs' provides tools to work with exfat filesystems, but it is only one of (at least) two implementations. the alternative implementation is packaged in 'exfat-utils'. Since both 'exfatprogs' and 'exfat-utils' obviously provide the same files, they "Conflict" with each other. For unrelated reasons i need the 'exfat-utils' installed on my system. due to the "Conflicts" this means, i cannot update 'forensics-extra' anymore, which i find a pity. since 'forensics-extra' is practically a convenience package to pull in a plethora of forensics packages, i don't see a reason to impose such hard restrictions on my system. i would suggest to make 'forensics-extra' a bit more forgiving when it comes to dependencies. either by implementing one or all of the following: - using (soft) "Recommends" instead of (hard) "Depends" for dependencies (e.g. the various *-task packages never use Depends, only Recommends) - allowing either of the two conflicting packages to satisfy the dependency (using "exfatprogs | exfat-utils" as a dependency) cheers. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages forensics-extra depends on: ii ancient 1.0-2 ii arc 5.21q-8 ii bfbtester 2.0.1-7.1+b2 ii bind9-dnsutils 1:9.17.20-3 ii binutils2.37-10 ii brotli 1.0.9-2+b3 ii bruteforce-luks 1.3.1-1+b1 ii bzip2 1.0.8-4 ii cabextract 1.9-3 ii chntpw 1.0-1.1 ii clzip 1.12-3 ii comprez 2.7.3-2 ii crunch 3.6-3 ii cryptmount 5.3.3-1 ii curl7.79.1-2 ii dact0.8.42-5 ii dares 0.6.5+repack-2+b1 ii dcfldd 1.7.1-1 ii ddrutility 2.8-3 ii dhcpdump1.8-2.2+b1 ii dictconv0.2-7+b2 ii diffstat1.64-1 ii disktype9-11 ii dmitry 1.3a-1.1 ii dtach 0.9-5+b1 ii erofs-utils 1.4-1 ii ethstatus 0.4.9+b1 ii ethtool 1:5.15-1 ii exfat-fuse 1.3.0-2 ii exfat-utils 1.3.0-2 ii exif0.6.22-2 ii exiftags1.01-7 ii exiv2 0.27.3-3.1 ii fatcat 1.0.5-1+b1 ii fdupes 1:2.1.2-1 ii foremost1.5.7-11+b1 ii funcoeszz 21.1-1 ii gddrescue 1.23-2+b1 ii gdisk 1.0.8-3 ii geoip-bin 1.6.12-8 ii gifshuffle 2.0-1+b1 ii hcxdumptool 6.2.4-1 ii heartbleeder0.1.1-9+b5 ii hexcompare 1.0.4-1+b1 ii hexedit 1.5-5 ii horst 5.1-2 ii hping3 3.a2.ds2-10 ii hwinfo 21.72-1 ii imageindex 1.1-4 ii inxi3.3.07-1-1 ii ipgrab 0.9.10-4 ii ipv6toolkit 2.0+ds.1-1 ii jdupes 1.20.2-1 ii less551-2 ii libimage-exiftool-perl 12.36+dfsg-1 ii lltdscan0+20180223-1 ii lrzip 0.641-1 ii lshw02.19.git.2021.06.19.996aaad9c7-2 ii lynis 3.0.6-1 ii lz4 1.9.3-2 ii lzop1.04-2 ii mblaze 1.1-1 ii mboxgrep0.7.9-5 ii mc 3:4.8.27-1 ii mdns-scan 0.5-5+b1 ii membernator 1.1.0-3 ii memstat 1.1+b1 ii minizip 1.1-8+b1 ii mpack 1.6-18 ii mscompress 0.4-9 ii nasm2.15.05-1 ii nast0.2.0-9 ii ncompress 4.2.4.6-5 ii netcat-openbsd 1.218-2 ii netdiscover 0.8.1-2 ii ngrep 1.47+ds1-5 ii nomarch 1.4-4 ii nstreams1.0.4-1+b1 ii ntfs-3g 1:2021.8.22-3 ii nwipe 0.31-1+b1 ii openpace1.1.0+ds-1+b1 ii p7zip-full 16.02+dfsg-8 ii packit 1.8-1 ii parted 3.4-1 ii pcapfix 1.1.7-1 ii pcaputils
Bug#1000819: udev: please revert removal of cd/dvd compat rules
Am 29.11.2021 um 23:03 schrieb Matt Zagrabelny: On Mon, Nov 29, 2021 at 3:51 PM Michael Biebl wrote: Am 29.11.2021 um 18:22 schrieb Matt Zagrabelny: Package: udev Version: 249.7-1 Severity: normal Greetings, Thank you for your work in Debian. I noticed that when I plug in my USB DVD drive I no longer get the /dev/dvd link. It breaks things like "lsdvd" and "mplayer dvd://1". In order to solve #991639 by removing the compat file (rules/80-debian-compat.rules) it ends up breaking simple use-cases, such as those of us with a single optical drive and wanting to use applications that expect to use /dev/dvd. Would you consider reverting a66d122048b? https://salsa.debian.org/systemd-team/systemd/-/commit/a66d122048b8d0d6c057c0504880f1b37e222cab This is not planned. Keep in mind, that this udev rule has always been Debian specific, so if software is actually buggy in that regard, it should be fixed in any case. The best we can do is to file bug reports against affected packages. Since we are early in the bookworm release cycle, we have plenty of time for that. Would you mind filing bug reports if you encounter such issues? I can file bug reports. What should the report look like? "Debian's default udev/systemd installation no longer provides This is not systemd specific, only udev. symlinks for /dev/dvd and your software no longer works without intervention. This sounds quite drastic. I would assume the affected packages still work (mostly) fine and only certain functionality would be affected. Please implement foobar so your software will work with the way things are being done now." I don't know what "foobar" is in the above. I only know what I read in your commit message: """ [...] older software which wasn't able to automatically discover those types of devices """ Applications like lsdvd and mplayer should be able to "discover" the DVD drives? Hmmm... I'm guessing those applications, which are indeed "old", yet venerable, might balk at the extra application code when creating the symlink at the OS level seems so easy. Either way... if you let me know what those applications "should" be doing, I'll submit bug reports. Use libudev to enumerate and watch for devices. Some DEs also provide higher level abstractions like udisks or GIO, which one could use. Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1000511: bullseye-pu: package debian-edu-config/2.11.56+deb11u2
Control: tags -1 + moreinfo On Wed, 2021-11-24 at 13:29 +0100, Wolfgang Schweer wrote: > It has been detected on real world deployments that some needed > changes > due to the re-written LTSP in bullseye have not been addressed > properly > or are missing, so: > (1) Fix TFTP server path (/var/lib/tftpboot-> /srv/tftp), #995610 > (2) Add real support for LTSP chroot setup and maintenance, #996103 > The metadata for the first bug implies that it affects unstable and is not yet fixed there. Could you please confirm the status? Regards, Adam
Bug#1000896: src:libipc-shareable-perl: fails to migrate to testing for too long: autopkgtest regression
Source: libipc-shareable-perl Version: 0.61-2 Severity: serious Control: close -1 1.06-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 997829 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:libipc-shareable-perl has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package has an unresolved autopkgtest regression. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=libipc-shareable-perl OpenPGP_signature Description: OpenPGP digital signature
Bug#1000895: exfat-utils: make package coinstallable with 'exfatprogs'
Package: exfat-utils Version: 1.3.0-2 Severity: normal Dear Maintainer, 'exfatprogs' and 'exfat-utils' provide different implementations of the same tools. as a consequence (as they probably install the files of the same name), the two packages declare a "Conflicts" situtaion. this is suboptimal, as it breaks some dependency chains on my system e.g. i want to be able to install 'forensics-extra' (depending on 'exfatprogs') and 'exfat-fuse' (depending on 'exfat-utils') at the same time. i think it would be great if both 'exfat-utils' and 'exfatprogs' could use the update-alternatives mechanism to resolve file-conflicts and allow the user to pick their preferred programs while having both packages installed. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages exfat-utils depends on: ii libc6 2.32-4 Versions of packages exfat-utils recommends: ii exfat-fuse 1.3.0-2 exfat-utils suggests no packages. -- no debconf information
Bug#1000894: src:magnum: fails to migrate to testing for too long: FTBFS
Source: magnum Version: 12.0.0-2 Severity: serious Control: close -1 13.0.0-1 Tags: sid bookworm ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:magnum has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package FTBFS. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=magnum
Bug#996108: Useless in Debian
Le Mon, Oct 11, 2021 at 06:44:55AM -0400, David Prévot a écrit : > Package: php-doctrine-bundle > Version: 2.2.3-1 > Severity: serious > Tags: sid bookworm > > [ Filled as an RC-bug by the maintainer to see the package auto-removed > from testing. ] > > I packaged php-doctrine-bundle as used by symfony, but symfony does not > use is anymore (well, the next version in experimental will not use it, > but it should soon be uploaded to unstable, before this package gets > removed anyway). There is a priori little point to ship > php-doctrine-bundle in the next stable Debian release. > > I intend to follow up with an RM request in a few months if nobody > objects (but feel free to beat me to it). Seeing upstream activity on php-doctrine-bundle, I wonder if it may become used (and thus useful) again for other packages in Debian in the near future. I withdraw my intend to get it removed right away from Debian, in order not to bother the archive team with NEW processing if that happens soon. Regards David signature.asc Description: PGP signature
Bug#1000893: bind9: reproducible builds: Embedded timestamps in man pages due to timezone
Source: bind9 Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org The build timestamp in various manpages varies dependent on timezone: https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/i386/diffoscope-results/bind9.html /usr/share/man/man1/dig.1.gz .TH·"DIG"·"1"·"2021-10-12"·"9.17.19-3-Debian"·"BIND·9" vs. .TH·"DIG"·"1"·"2021-10-14"·"9.17.19-3-Debian"·"BIND·9" The attached patch fixes this by adjusting the call to "date" in configure.ac to explicitly use the UTC timezone. Unfortunately, this does not resolve all reproducibility issues (e.g. build path), but with this patch applied, bind9 should build reproducibly on tests.reproducible-builds.org when it migrates to the testing/bookworm suite (where build paths are not tested). Thanks for maintaining bind9! live well, vagrant From afc3707e3935645c5c6388ca19b3ee825e0d3395 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Tue, 30 Nov 2021 20:31:20 + Subject: [PATCH] configure.ac: Set release_date using UTC timezone. https://reproducible-builds.org/docs/timestamps/ --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index ffcc69f..126182f 100644 --- a/configure.ac +++ b/configure.ac @@ -1238,7 +1238,7 @@ AM_CONDITIONAL([HAVE_XELATEX], [test "$XELATEX" != ":" && test "$LATEXMK" != ":" # Pull release date from CHANGES file last modification date # for reproducible builds # -release_date=`date -r CHANGES +%Y-%m-%d` +release_date=`date -u -r CHANGES +%Y-%m-%d` AC_SUBST([RELEASE_DATE], $release_date) # -- 2.30.2 signature.asc Description: PGP signature
Bug#1000386: mailman 2.1.29-1+deb10u3 flagged for acceptance
package release.debian.org tags 1000386 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: mailman Version: 2.1.29-1+deb10u3 Explanation: fix cross-site scripting issue [CVE-2021-43331]; fix "a list moderator can crack the list admin password encrypted in a CSRF token" [CVE-2021-43332]
Bug#1000858: release.debian.org: block llvm-toolchain-9 binNMU 1:9.0.1-20+b1 from migrating to testing
Hi Andreas On 2021-11-30 11:41:57, Andreas Beckmann wrote: > Package: release.debian.org > Severity: normal > > Please block yesterdays llvm-toolchain-9 binNMU 1:9.0.1-20+b1 (and > probably any further binNMUs as well) from migrating to testing. > It introduces a regression when compiling OpenCL code from pocl by > segfaulting in libclang-cpp9 (#1000838). Simple reproducer: > apt-get install pocl-opencl-icd clinfo > clinfo > So far I could observe these segmentation faults on amd64, i386, arm64. > > According to Sylvestre, this will be fixed only by the removal of > llvm-toolchain-9. Some of those binNMUs already migrated. The others are stuck behind ocaml-ctypes. Given that pocl is one of the two packages keeping llvm-toolchain-9 in unstable, what's your plan? I want to remove it sooner than later. Four llvm-toolchain version in testing is simply too much. Cheers -- Sebastian Ramacher
Bug#1000218: wavpack 5.1.0-6+deb10u1 flagged for acceptance
package release.debian.org tags 1000218 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: wavpack Version: 5.1.0-6+deb10u1 Explanation: fix use of uninitialized vlaues [CVE-2019-1010317 CVE-2019-1010319]
Bug#1000892: cvise: Please upgrade to llvm-toolchain-12 or 13
Source: cvise Version: 2.1.0-1 Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, please upgrade to -13 (or -12). It has: llvm-9-dev [armel armhf], libclang-9-dev [armel armhf], clang-9 [armel armhf], clang-format-9 [armel armhf], Thanks, Sylvestre -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (600, 'unstable'), (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1000208: upload of pcmemtest
Thanks, uploaded. Feel free to contact me if there is a new version. Since you are already a DM maintaining a couple of packages, I would give you upload rights then. Regards, Stephan On Tue, Nov 30, 2021 at 8:41 PM Felix Zielcke wrote: > > Thanks again. > Yes somehow I missed it. > Changed now the salsa-ci.yml file to your latest suggestion. > > > Am Dienstag, dem 30.11.2021 um 20:28 +0100 schrieb Stephan Lachnit: > > Hi Felix, > > > > it seems like you missed my comment on Salsa [1]. Please take a look > > at it, should be quick to do. > > > > Regards, > > Stephan > > > > [1 > > ]https://salsa.debian.org/fzielcke/pcmemtest/-/merge_requests/1#note_285216 > > > > On Tue, Nov 30, 2021 at 8:23 PM Felix Zielcke > > wrote: > > > > > > Hi Stephan, > > > > > > did you already upload pcmemtest to NEW? > > > I didn't get a mail and I don't see it in the list. > > > > > > Regards > > > Felix >
Bug#1000891: creduce: Please upgrade to llvm-toolchain-12 or 13
Source: creduce Version: 2.9~20181016-1 Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, please upgrade to -13 (or -12). Thanks, Sylvestre -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (600, 'unstable'), (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#994614: Fixed upstream
Hello again! I have applied that fix in Git repository last week. You can test a preliminary package built on Salsa CI. https://salsa.debian.org/debian/rlottie/-/jobs/2224295/artifacts/browse/debian/output/ So far I am not planning on uploading the new version to the main archive till New Year. signature.asc Description: This is a digitally signed message part
Bug#1000785: bullseye-pu: package curl/7.74.0-1.3+deb11u1
Control: tags -1 + moreinfo On Sun, 2021-11-28 at 21:39 +0100, Helmut Grohne wrote: > libcurl4-gnutls-dev is not multiarch-coinstallable in bullseye > despite being marked Multi-Arch: same. When attempting to coinstall > it, dpkg issues an unpack error. That's a very bad thing to do. > ACK. > The issue has been reported as #990128 and has been fixed in > unstable. > Reproducible builds added compiler flags that include the build > directory (which varies per build) and those build flags made it into > curl-config. As such, reproducible builds made curl unreproducible. > This > issue has been well understood and for a different compiler flag, a > workaround was already in place in debian/rules. The solution was to > extend the workaround in the obvious way (stripping that other flag). > > I think that the risk/benefit ratio is good. The only affected piece > is > curl-config, the change is fairly obvious and it makes unpack errors > from dpkg go away. What's the potential impact of the change? Is "curl-config --configure" consumed by anything, other than human eyeballs? Regards, Adam
Bug#1000473: gmp 6.1.2+dfsg-4+deb10u1 flagged for acceptance
package release.debian.org tags 1000473 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: gmp Version: 6.1.2+dfsg-4+deb10u1 Explanation: fix integer and buffer overflow issue [CVE-2021-43618]
Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1
Am Tue, Nov 30, 2021 at 06:00:57PM + schrieb Adam D. Barratt: > I was assuming the plan was for the Firefox and Thunderbird updates to > be released via the security archive. Definitely! For the last ESR round DSA deployed a change to make the security chroots include buster-proposed-updates. Not sure, if that is still the case, but we'll need the same for the bullseye chroots. This will also be needed for the openjdk-11 buster-security update after jtreg/jtharness are in buster-proposed-updates. Cheers, Moritz
