Bug#1086695: linux: Enable X86 userspace shadow stack
Source: linux Version: 6.11.5-1 Severity: wishlist Tags: patch X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, jair.gonza...@linux.intel.com Dear Maintainer, Please enable the "X86 userspace shadow stack" (X86_USER_SHADOW_STACK). Shadow stack protection is a hardware feature that detects function return address corruption. This helps mitigate ROP (Return-oriented programming) attacks. Applications must be enabled to use it, and old userspace does not get protection "for free". Shadow stack works by maintaining a secondary (shadow) stack that cannot be directly modified by applications. When executing a CALL instruction, the processor pushes the return address to both the normal stack and to the special permission shadow stack. Upon RET, the processor pops the shadow stack copy and compares it to the normal stack copy. If the two differ, the processor raises a control protection fault. This implementation supports shadow stack on 64 bit kernels only, with support for 32 bit only via IA32 emulation. CPUs supporting shadow stacks were first released in 2020. See https://docs.kernel.org/arch/x86/shstk.html for more information. A MR was created with this proposal at: https://salsa.debian.org/kernel-team/linux/-/merge_requests/1253 Thanks, Miguel Bernal Marin
Bug#1086682: iso-codes: Updated Portuguese translation iso_3166-1/pt.po
Package: iso-codes Version: 4.17.0-1 Severity: wishlist Tags: l10n patch Updated Portuguese translation for: iso_3166-1/pt.po Feel free to use it. -- Best regards, Miguel Figueiredo Portuguese Translation Team https://www.DebianPT.org # Translation of ISO 3166-1 to Portuguese # Codes for the representation of names of countries and their subdivisions # Part 1: Country codes # . # This file is distributed under the same license as the iso-codes package. # . # Notes: # Please follow this official pointer when translating to Portuguese # http://www.min-nestrangeiros.pt/mne/estrangeiro/indice.html # http://publications.europa.eu/code/pt/pt-5000500.htm # Copyright © # Miguel Figueiredo , 2005-2013. # Ayalos , 2018. # Rui Mendes , 2019. # Chris Leonard , 2019. # Miguel Figueiredo , 2022, 2024 msgid "" msgstr "" "Project-Id-Version: iso_3166-1\n" "Report-Msgid-Bugs-To: https://salsa.debian.org/iso-codes-team/iso-codes/"; "issues\n" "POT-Creation-Date: 2023-02-24 21:26+0100\n" "PO-Revision-Date: 2024-11-03 18:48+\n" "Last-Translator: Miguel Figueiredo \n" "Language-Team: Portuguese <https://hosted.weblate.org/projects/iso-codes/"; "iso-3166-1/pt/>\n" "Language: pt\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=n > 1;\n" "X-Generator: Weblate 4.15-dev\n" #. Name for ABW msgid "Aruba" msgstr "Aruba" #. Name for AFG msgid "Afghanistan" msgstr "Afeganistão" #. Official name for AFG msgid "Islamic Republic of Afghanistan" msgstr "República Islâmica do Afeganistão" #. Name for AGO msgid "Angola" msgstr "Angola" #. Official name for AGO msgid "Republic of Angola" msgstr "República de Angola" #. Name for AIA msgid "Anguilla" msgstr "Anguilla" #. Name for ALA msgid "Åland Islands" msgstr "Ilhas Alanda" #. Name for ALB msgid "Albania" msgstr "Albânia" #. Official name for ALB msgid "Republic of Albania" msgstr "República da Albânia" #. Name for AND msgid "Andorra" msgstr "Andorra" #. Official name for AND msgid "Principality of Andorra" msgstr "Principado de Andorra" #. Name for ARE msgid "United Arab Emirates" msgstr "Emirados Árabes Unidos" #. Name for ARG msgid "Argentina" msgstr "Argentina" #. Official name for ARG msgid "Argentine Republic" msgstr "República Argentina" #. Name for ARM msgid "Armenia" msgstr "Arménia" #. Official name for ARM msgid "Republic of Armenia" msgstr "República da Arménia" #. Name for ASM msgid "American Samoa" msgstr "Samoa Americana" #. Name for ATA msgid "Antarctica" msgstr "Antártida" #. Name for ATF msgid "French Southern Territories" msgstr "Territórios Franceses do Sul" #. Name for ATG msgid "Antigua and Barbuda" msgstr "Antígua e Barbuda" #. Name for AUS msgid "Australia" msgstr "Austrália" #. Name for AUT msgid "Austria" msgstr "Áustria" #. Official name for AUT msgid "Republic of Austria" msgstr "República da Áustria" #. Name for AZE msgid "Azerbaijan" msgstr "Azerbaijão" #. Official name for AZE msgid "Republic of Azerbaijan" msgstr "República do Azerbaijão" #. Name for BDI msgid "Burundi" msgstr "Burundi" #. Official name for BDI msgid "Republic of Burundi" msgstr "República do Burundi" #. Name for BEL msgid "Belgium" msgstr "Bélgica" #. Official name for BEL msgid "Kingdom of Belgium" msgstr "Reino da Bélgica" #. Name for BEN msgid "Benin" msgstr "Benim" #. Official name for BEN msgid "Republic of Benin" msgstr "República do Benim" #. Name for BES, Official name for BES msgid "Bonaire, Sint Eustatius and Saba" msgstr "Bonaire, Santo Eustáquio e Saba" #. Name for BFA msgid "Burkina Faso" msgstr "Burkina Faso" #. Name for BGD msgid "Bangladesh" msgstr "Bangladeche" #. Official name for BGD msgid "People's Republic of Bangladesh" msgstr "República Popular do Bangladeche" #. Name for BGR msgid "Bulgaria" msgstr "Bulgária" #. Official name for BGR msgid "Republic of Bulgaria" msgstr "República da Bulgária" #. Name for BHR msgid "Bahrain" msgstr "Barém" #. Official name for BHR msgid "Kingdom of Bahrain" msgstr "
Bug#1086648: RFS: localepurge/0.7.3.11 -- reclaim disk space by removing unneeded localizations
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "localepurge": * Package name : localepurge Version : 0.7.3.11 Upstream contact : * URL : https://salsa.debian.org/elmig-guest/localepurge * License : GPL-2+ * Vcs : https://salsa.debian.org/elmig-guest/localepurge Section : admin The source builds the following binary packages: localepurge - reclaim disk space by removing unneeded localizations To access further information about this package, please visit the following URL: https://mentors.debian.net/package/localepurge/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/l/localepurge/localepurge_0.7.3.11.dsc Changes since the last upload: localepurge (0.7.3.11) UNRELEASED; urgency=medium . * Add Romanian translation (ro.po), thanks to Remus-Gabriel. (Closes: #1032341) * Fix VERBOSE variable case * Remove repeated /usr/share/aptitude * Replace fgrep and egrep for grep, thanks to Axel Beckert. (Closes: #1019494) -- Best regards, Miguel Figueiredo
Bug#1086510: bindgen: bug triggers future kernel build error (fixed upstream)
Package: bindgen
X-Debbugs-Cc: oj...@kernel.org, werdah...@riseup.net, noisyc...@disroot.org
Version: 0.66.1-7+b2
Severity: important
Tags: patch, fixed-upstream
Hi,
Current Sid's `bindgen` will run into a kernel build failure in the
future (in a few weeks, when the new tracepoints support gets merged):
$ bindgen --version --verbose
bindgen 0.66.1
Clang: Debian clang version 19.1.2 (2)
$ make LLVM=1 samples/rust/rust_print.o
...
error[E0425]: cannot find value `__tracepoint_rust_sample_loaded` in crate
`$crate::bindings`
--> samples/rust/rust_print.rs:87:5
...
The issue triggers with `bindgen` < 0.69.5 && `libclang` >= 19.1. Debian
Testing is fine (at least the `debian:testing` image), since `libclang`
is older there.
Upstream has a fix (released for 0.70.0 and backported to 0.69.5) at:
https://github.com/rust-lang/rust-bindgen/pull/2824
600f63895f73 ("Use clang_getFileLocation instead of
clang_getSpellingLocation")
35f0f9aafc9b ("Use clang_getFileLocation instead of
clang_getSpellingLocation")
It is a single line change which can be cleanly cherry-picked into
`bindgen` 0.66.1.
I confirmed the change would fix the issue (using `debian:sid` image): I
downloaded the Sid package sources (rust-bindgen and rust-bindgen-cli),
built the kernel to confirm the issue is there, then applied the single
line change to the sources, built the kernel again successfully.
Upgrading to `bindgen 0.70.x` should also fix the issue.
The consequence of not doing anything would be that kernel developers
using Debian would need to install a custom/newer `bindgen`, possibly
via `cargo`, instead of using their distribution package, which would be
inconvenient for them -- we are trying to keep the kernel buildable with
distributions' toolchains, e.g. see our instructions for Debian at:
https://docs.kernel.org/rust/quick-start.html#debian
Backport PR by NoisyCoil at:
https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/771
Thanks!
Cheers,
Miguel
Bug#1086023: binutils: Please drop cross-support for ia64
> On Oct 25, 2024, at 00:57, John Paul Adrian Glaubitz > wrote: > > Thus, I suggest we drop cross-support for ia64 from binutils for the time > being in order to reduce the footprint of the binutils package. > This is sad but I think we have to come to terms with the fact that Itanium has moved from working platform to history books. For the very few of us fans, it will be called Vintage. For everyone else, oblivion. It doesn't help that there isn't a proper software Itanium emulator - not one to the level of QEMU, for example. Or some piece of personal hardware that was popular, as it is the case for m68k. That might has helped keeping the platform alive. With just scant access to big iron physical servers, there is just no critical mass to keep the platform going just on ephemeral volunteer hours.
Bug#1086054: linux: Enable DRM_ACCEL in amd64
Source: linux Version: 6.11.4-1 Severity: wishlist Tags: patch X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, jair.gonza...@linux.intel.com Dear Maintainer, Please enable the Compute Acceleration device configuration DRM_ACCEL on amd64. This framework provides support for compute acceleration devices, such as, but not limited to, Machine-Learning and Deep-Learning acceleration devices Currently in the BTS https://bugs.debian.org/1079170, was asked to enable DRM_ACCEL_HABANALABS and DRM_ACCEL_IVPU, but both depend on the Compute Acceleration Framework (DRM_ACCEL), and the later was not enabled. Therefore Habana's AI Processors (AIP) and Intel NPU (formerly called Intel VPU) are not enabled. DRM_ACCEL is a menuconfig option so it is safe to said =y here. A MR was created with this proposal at: https://salsa.debian.org/kernel-team/linux/-/merge_requests/1246 Thanks, Miguel Bernal Marin
Bug#1058645: Do you need help with this package?
Hi Guilherme, Thanks for working on hare package as well. As you may have noticed already, I also uploaded hare this weekend: https://ftp-master.debian.org/new/hare_0.24.2-1.html I didn't find any blockers so I went ahead with the upload. There are still some very pedantic/minor lintian warnings about manpages markup and I observed an issue during tests but only on sbuild, but I think those issues can be worked on once the packages are hopefully accepted in the archive soon. Sorry for the long time it took me to work on the uploads. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. "Faith means not wanting to know what is true." -- Nietzsche
Bug#1085046: ITP: harec -- Hare compiler for POSIX-compatible systems
Package: wnpp Severity: wishlist Owner: Miguel Landaeta X-Debbugs-Cc: debian-de...@lists.debian.org, guilhe...@puida.xyz * Package name: harec Version : 0.24.2 Upstream Contact: Drew DeVault * URL : https://harelang.org/ * License : MPL-2.0 Programming Lang: C Description : Hare compiler for POSIX-compatible systems Hare is a systems programming language designed to be simple, stable and robust. Hare uses a static type system, manual memory management, and a minimal runtime. It is well suited to writing operating systems, system tools, compilers, networking software, and other low-level, high performance tasks. . This package installs the Hare compiler. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. "Faith means not wanting to know what is true." -- Nietzsche
Bug#1058645: Do you need help with this package?
On Mon, Sep 23, 2024 at 12:19:29AM -0300, Guilherme Puida Moreira wrote: > [...] > > 3. harec is missing a manpage. I'll write one later. I just wrote one following the convention you used for qbe one. > [...] > > If you could spare some time to review, I would greatly appreciate it. I reviewed your harec package and looks good to me. I'll be uploading harec shortly and then I'll start reviewing hare. -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. "Faith means not wanting to know what is true." -- Nietzsche
Bug#1083229: ITP: intel-qpl -- Intel Query Processing Library (Intel QPL)
Hi, On Thu, Oct 03, 2024 at 04:19:33PM +0200, Brice Goglin wrote: > Hello > > The text about "next generation xeon" is severely outdataed. Sapphire Rapids > in the previous previous generation Xeon. Then we had Emerald Rapids, and > very recently Granite Rapids. > You are right, thanks for the update. > Brice > > > Le 03/10/2024 à 15:35, Miguel Bernal Marin a écrit : > > Package: wnpp > > Severity: wishlist > > Owner: Miguel Bernal Marin > > X-Debbugs-Cc: debian-de...@lists.debian.org, miguel.bernal.ma...@gmail.com > > > > * Package name: intel-qpl > >Version : 1.6.0 > >Upstream Contact: Maria Zhukova > > * URL : https://github.com/intel/qpl > > * License : MIT > >Programming Lang: Assembly, C, C++ > >Description : Intel Query Processing Library (Intel QPL) > > > > The Intel Query Processing Library (Intel QPL) is an open-source library > > to provide high-performance query processing operations on Intel CPUs. > > Intel QPL is aimed to support capabilities of the new > > Intel In-Memory Analytics Accelerator (Intel IAA) available on Next > > Generation Intel® Xeon® Scalable processors, codenamed Sapphire Rapids Here should said: current and future Intel® Xeon® Scalable processors, as Sapphire Rapids, Emerald Rapids, Granite Rapids, Sierra Forest > > processor, such as very high throughput compression and decompression > > combined with primitive analytic functions, as well as to provide > > highly-optimized SW fallback on other Intel CPUs. Intel QPL primarily > > targets applications such as big-data and in-memory analytic databases. > > > > Intel QPL provides Low-Level C API. You can use it from C/C++ applications. > > > > See also: > > https://www.intel.com/content/www/us/en/developer/tools/query-processing-library/overview.html > > > > I intend to maintain this Debian package, and tracking recent releases, > > checking the code for any security issues and programming issues using > > static analysis tools and contributing to the upstream project with any > > fixes I make during as I support this package. > > > > Sincerely, Regards, Miguel Bernal Marin
Bug#1083229: ITP: intel-qpl -- Intel Query Processing Library (Intel QPL)
Package: wnpp Severity: wishlist Owner: Miguel Bernal Marin X-Debbugs-Cc: debian-de...@lists.debian.org, miguel.bernal.ma...@gmail.com * Package name: intel-qpl Version : 1.6.0 Upstream Contact: Maria Zhukova * URL : https://github.com/intel/qpl * License : MIT Programming Lang: Assembly, C, C++ Description : Intel Query Processing Library (Intel QPL) The Intel Query Processing Library (Intel QPL) is an open-source library to provide high-performance query processing operations on Intel CPUs. Intel QPL is aimed to support capabilities of the new Intel In-Memory Analytics Accelerator (Intel IAA) available on Next Generation Intel® Xeon® Scalable processors, codenamed Sapphire Rapids processor, such as very high throughput compression and decompression combined with primitive analytic functions, as well as to provide highly-optimized SW fallback on other Intel CPUs. Intel QPL primarily targets applications such as big-data and in-memory analytic databases. Intel QPL provides Low-Level C API. You can use it from C/C++ applications. See also: https://www.intel.com/content/www/us/en/developer/tools/query-processing-library/overview.html I intend to maintain this Debian package, and tracking recent releases, checking the code for any security issues and programming issues using static analysis tools and contributing to the upstream project with any fixes I make during as I support this package. Sincerely, Miguel Bernal Marin
Bug#1058645: Do you need help with this package?
On Mon, Sep 23, 2024 at 4:19 AM Guilherme Puida Moreira wrote: > [...] > > By the way, I feel like both hare and harec should be team-maintained. > Do you have a strong opinion about this? > I agree it should be team-maintained. Otherwise, we risk being in a situation where a maintainer could become a blocker if they are busy for any reason. I have worked in teams in Debian before but I don't have experience setting up one from scratch, so I'd say since it's still early days for Hare and the package is still not uploaded to main (mostly my fault, but I'll commit to work on it this during October) we can be co-maintainers and figure out (or ask for help) later on how to set up the team. I'll go back over your changes soon and will send an update on this bug report. If it takes too long feel free to ping me directly. -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/ "Faith means not wanting to know what is true." -- Nietzsche
Bug#1082114: libcairo2: cairo 1.18.2 caused regressions with PDF export/printing in xournal/evince (fix available)
On Wed, Sep 18, 2024 at 02:48:50PM +0100, Tim Müller wrote: > Package: libcairo2 > Version: 1.18.2-1 > Severity: important > Tags: patch upstream > Dear maintainer, I've the the same issue, and I created a MR whith the fix at: https://salsa.debian.org/gnome-team/cairo/-/merge_requests/3 Could you please so a new release with this path? Thanks, > Hi, > > Since the cairo upgrade to 1.18.2 I've seen major regressions with PDF export > and printing in Xournal, Xournalpp and Evince. > > In Xournal(pp) it fails with an 'out of memory' error when exporting to PDF. > > This matches this issue in upstream cairo: > > https://gitlab.freedesktop.org/cairo/cairo/-/issues/870 > > which was closed upstream by this Merge Request: > > https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/595 > > Patch: > > https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/595.patch > > It would be great if you could pull that fix into the debian package until > there's a new cairo release. > > (As advised by upstream in the issue above.) > > Many thanks! > > Tim
Bug#1082602: Request to backport Duply 2.5 to bookworm-backports for compatibilty with the backported duplicity
Package: duply Version: 2.4.1-1 Hi, This is not really a bug, but I thought I'd raise an issue so that no-one else creates duplicates if they run into the problem. I wanted to ask if it would be possible to add Duply 2.5.3 to Bookworm's backports repository? Would this be something either the duply maintainer or the duplicity backports maintainer could support? Context: Alexander Zangerl has already added duplicity 2.1.4 to backports [1]. Duplicity 2.x has some breaking changes to the flags. In particular, `--file-to-restore` is now `--path-to-restore`. This breaks the ability to use duply in Debian Bookworm with the newer (backported) duplicity, because duply hardcodes `--file-to-restore` in its 'fetch' subcommand. This issue is fixed in Duply 2.5.0. You can see Ubuntu users got hit even harder by this in 24.04 (without any 'backported' version). So I recognise that the issue is less dire in Debian (stable versions of the two packages work just fine together :) ), but for those of us who need the newer Duplicity from backports, it would be great to have a newer Duply as well. Thanks to both the duplicity and duply Debian maintainers for their hard work! [1] https://packages.debian.org/bookworm-backports/duplicity [2] https://bugs.launchpad.net/ubuntu/+source/duply/+bug/2065559 signature.asc Description: PGP signature
Bug#1058645: Do you need help with this package?
On Tue, Sep 17, 2024 at 9:18 PM Guilherme Puida Moreira wrote: > > Hi! > > On Tue, 30 Apr 2024 00:02:48 +0100 Miguel Landaeta wrote: > > The next step for me here is to get back to this bug report soon with > > a link to the salsa repo for hare so other folks can take a look, > > provide feedback and get this package uploaded in a reasonable time > > frame. > > Did you end up pushing your work somewhere? I'm willing to help if you > need a hand. :^) > Hi Guilherme, Thank you for the help offered. As it's evident it has taken me too long to work on this and it will take me a while until I have some time to properly focus on it. If you can help, I have some cycles to spare for code review though. I worked on this package last December but after that never found time to polish it or even push the repo as promised, so thanks for the reminder. Please take a look at: https://salsa.debian.org/debian/hare Thanks, Miguel. -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/ "Faith means not wanting to know what is true." -- Nietzsche
Bug#1031046: Backport to bookworm
On 06/09/24 17:27, Jonas Smedegaard wrote: Please subscribe to our mailinglist and discuss more there, and please join our Salsa team - see details athttps://wiki.debian.org/Teams/VoIP/ I'm a long time subscriber from your mailinglist... and I've just applied for a Salsa account.
Bug#1031046: Backport to bookworm
On 06/09/24 16:35, Jonas Smedegaard wrote: I can do the task of releasing patches-applied updates, so you need not be an official Debian developer to help. All you need is dedication to keep an eye on stable and oldstable branches of Debian, and the ability to*try* to apply patches. If you notice a needed patch, try to apply it, and that fails, then we are a team, and you can ask me to try as well - and you can shout out to Debian developers at large on the debian-devel mailinglist as well. This bugreport is about the lack of helping hands. I could volunteer to help, but I could not give dedicate too much time to it, because there is not much spare time on my side. I've no problems in patching, compiling, and making packages for Debian, but would have problems to find the appropriate patches for old Asterisk releases and would probably would not have the skills to test if the patches are really doing what they are supposed to do. If you are fine with those restrictions, please count with me... just tell me were to start :-)
Bug#1031046: Backport to bookworm
Hi Jonas, I was thinking that it would be possible to go directly from unstable to backports. Quoting from https://backports.debian.org/: "(In a few cases, usually for security updates, backports are also created from the Debian unstable distribution.)". If Asterisk does not fit in that category of "few cases", I would be happy to build my own private backport from unstable. I prefer that instead of building directly from the sources, because I value a lot the work done my Debian devs in releasing stable and secure packages (even if they are only available from the unstable release). Thank you and best regards, José Miguel Gonçalves
Bug#1031046: Backport to bookworm
Hi Jonas, Thank you for your quick response. Please do not consider my questions as I was demanding anything. I just wanted a confirmation that Asterisk was still going to be packaged in Debian in the near future (at least, during the life of Asterisk 20). I only have appreciations for the Debian project, in the maintenance of very stable systems that I use in my work and private life. Going to a more specific question, are you considering packaging Asterisk 20 for bookworm-backports? Best regards, José Miguel Gonçalves On 06/09/24 14:10, Jonas Smedegaard wrote: Hi José, Quoting José Miguel Gonçalves (2024-09-06 13:14:26) I was wondering, what is the current maintenance status of Asterisk on Debian? Nothing has changed since my older responses in this bugreport, so please read my other posts here and ask more specifically if there is something you don't find covered there already. I see that there are packages published on unstable, but the current version has a reported security vulnerability (CVE-2024-42365 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078574>) since August 12, that was still not addressed. Yes, there are bugs filed against Asterisk. Please go examine which of those bugs you consider affecting your use of Asterisk. Is the goal to still maintain Asterisk packages in Debian or there is lack of man-power for that? As also reflected by my older resonses in this bugreport, the goal is to maintain Asterisk packages in Debian, but having that goal is not adequate exactly due to lack of man power: I have enough time to keep Asterisk afloat for unstable, but lack the time to care for stable releases of Debian. I'm using these packages since 2015 and I need to upgrade some servers that I support form Asterisk 16 to 20 and I was wondering if could continue to use Debian packages (even if I need to backport them from unstable to bookworm) or if I need to go in other direction (find some alternative Debian packaging, or compile/package it myself). Whether you find the current level of care for Asterisk in Debian superior or inferior to whatever support you can achieve elsewhere is something I cannot really answer. You do not *need* to go elsewhere, if that is really what you are asking here. Kind regards, and thanks for your interest in Debian and Asterisk, - Jonas
Bug#1031046: Backport to bookworm
Hi all, I was wondering, what is the current maintenance status of Asterisk on Debian? I see that there are packages published on unstable, but the current version has a reported security vulnerability (CVE-2024-42365 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078574>) since August 12, that was still not addressed. Is the goal to still maintain Asterisk packages in Debian or there is lack of man-power for that? I'm using these packages since 2015 and I need to upgrade some servers that I support form Asterisk 16 to 20 and I was wondering if could continue to use Debian packages (even if I need to backport them from unstable to bookworm) or if I need to go in other direction (find some alternative Debian packaging, or compile/package it myself). Best regards, José Miguel Gonçalves
Bug#1062703: (no subject)
Control: retitle -1 firmware-iwlwifi: Please update to newest kernel version Hi there, any updates on this bug on when the new version will be uploaded? Regards
Bug#1069191: glibc: GLIBC-SA-2024-0004/CVE-2024-2961: ISO-2022-CN-EXT: fix^J out-of-bound writes when writing escape sequence
On Mon, 22 Apr 2024 09:31:39 +0200 Charlemagne Lasse wrote: > Hi, > > Can this be backported to older Debian versions via the security repo? > This bug can be used to execute code when using the PHP engine: > > * https://www.offensivecon.org/speakers/2024/charles-fol.html > * https://www.openwall.com/lists/oss-security/2024/04/18/4 > Indeed.. I know that buster is old-old stable, but starting to get nervous that it doesn't contain the fix that Bullseye and Bookworm have. Especially as we approach the date of a security conference that will talk about this issue. Is anyone on the LTS team working on it for Buster? That might also help trickle down to ELTS for Stretch/Jessie? signature.asc Description: PGP signature
Bug#1058646: ITP: qbe -- Small embeddable C compiler backend
On Sun, Apr 28, 2024 at 11:51 PM Guilherme Puida Moreira wrote: > > Hi Miguel, > > On Sun, Apr 28, 2024 at 10:54:54PM +0100, Miguel Landaeta wrote: > > Can you also reach out to upstream and send your man page contribution > > there, so you can gather feedback and other users can benefit if they > > decide to merge it? > > Will do. Thanks for the ping! qbe: https://ftp-master.debian.org/new/qbe_1.2-1.html > By the way, you mentioned that you had a preliminary hare package on > #1058645. If you need any help, just let me know. I'll double check what's pending. Luckily these packages should be very straightforward. I remember one concern from one of the co-maintainers about maybe introducing a separate package for harec and I think I also spotted a directory in the binary package that could be not compliant with the Debian policy and the expected filesystem layout. However, those issues should be quick to sort, I hope. I'll check what's up and post an update on the hare ITP bug (#1058645) soon. -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/ "Faith means not wanting to know what is true." -- Nietzsche
Bug#1058645: Do you need help with this package?
I apologize for dropping the ball on this one. I just uploaded qbe to the archive and it's now waiting for NEW processing. https://ftp-master.debian.org/new/qbe_1.2-1.html The next step for me here is to get back to this bug report soon with a link to the salsa repo for hare so other folks can take a look, provide feedback and get this package uploaded in a reasonable time frame. -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/ "Faith means not wanting to know what is true." -- Nietzsche
Bug#1058646: ITP: qbe -- Small embeddable C compiler backend
Hi folks, I apologize I took me this long to work on qbe upload. Guilherme, thanks for contributing a man page for qbe. I just included it in the package. Can you also reach out to upstream and send your man page contribution there, so you can gather feedback and other users can benefit if they decide to merge it? Amin, I took some bias for action and I just uploaded the latest changes in debian/latest to the archive. However, my upload just got rejected because I forgot to include the source changes and did only a binary upload. I don't have time today to fix that and retry so I'll do that tomorrow unless you do it first (if you want or if you have more changes pending that you want to include in the first upload). I'll paste a link to this package NEW queue entry later so other users can have visibility on the progress. Thanks for your contributions! Cheers, -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/ "Faith means not wanting to know what is true." -- Nietzsche
Bug#1058646: ITP: qbe -- Small embeddable C compiler backend
On Wed, Apr 10, 2024 at 2:51 PM Guilherme Puida Moreira wrote: > > Hi Miguel, > > [...] > > I have written a very simple man page for qbe (see attached patch). I > have never actually used qbe directly, so I'm not sure what else should > be documented there. I figured that the cli options were a good starting > point, though. > Hi Guilherme, Thanks for the patch! As you mentioned, this package is almost ready to be uploaded so I'll try to prioritize it and upload it during the weekend. Cheers, Miguel. -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/ "Faith means not wanting to know what is true." -- Nietzsche
Bug#1065831: document package specifiers for `upgrade`
Hi all, >> No. Without a package as an argument it won't. Thanks! You're right. Let me write it down here again: - "apt upgrade" (no argument) will never remove a package, only upgrade or install - "apt upgrade pkg_name" will remove, upgrade or install the required package to satisfy its dependencies. - "apt upgrade foo- bar+": advanced option that can be used to specifically removed or install packages. >> Julian provided an explanation in #74, 20240312113620.ga1944...@debian.org I can't access this link.. >> I'm not a Debian developer, never have been. Just someone who submitted a patch or two. And your comments have been really valuable in figuring out what's going on! Again, my confusion was because this was the first time I reported a bug AND several people jumped in the conversation! It is not usually the case ;) Regards
Bug#1065831: document package specifiers for `upgrade`
Hi all, >> (modifiers btw is not a good word. I guess it was never documented so far partly as this is a rather advanced feature and mainly because naming things is hard) yes, we brought it up in our conversation but I agree it was not directly related to the subject as it was an apt advanced option. But it was good because we were able to compare different situations (to spice things up). We even talked about "apt-get" and "aptitude" but I understand they are different commands and the purpose was not to compare behaviours among different tools. >> Well, does it really matter who is and who isn't? No, it doesn't as long as they have the right information ;) Of course, the more people involved in the issue, the better perspective we have on the problem. But it is important to know how apt is *currently* behaving to avoid misunderstanding and wrong assumptions (even from my side as well). We discovered that it is a documentation bug but my initial premise when I opened the bug was that the resolver wasn't working properly. With the right information, we usuallly get faster to the solution. Thank you all, guys! >> Nobody is born an APT developer, they are chosen based on their patch offerings! ;)
Bug#1065831: document package specifiers for `upgrade`
Hi there, > If "apt upgrade" is saying that it removes packages, that is a bug, yes. @david: it is not a bug, apparently. To put everything in a nutshell: - "apt upgrade" can remove packages - "apt upgrade" accepts specific packages to be upgraded Therefore, this behaviour is expected and documentation needs to be modified. In the meantime, while the documentation is modified, can some developer provide some explanation to the current "apt upgrade" behaviour? (*) Thanks (*) I'm a bit confused because I don't know which of the people involved in this bug are actually a developer of the apt package ;)
Bug#1065831: apt upgrade : it removes packages when it shouldn't.
Control: retitle -1 apt upgrade : it removes packages when it shouldn't.
Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)
Control: retitle -1 apt upgrade : it removes packages when it shouldn't. The case you mentioned is a tricky one, yes: *apt upgrade foo+ bar-* (I really don't know how apt handles it internally but having this option is very useful. Of course, I wouldn't remove it). I think it makes a lot of sense for "apt upgrade" to allow packages as arguments. There should be a possibility to upgrade only a set of packages and it comes in handy in some situations (i.e.: t64 upgrade). "apt upgrade" also doesn't mark upgraded packages as manually installed (as expected). But "apt install" does mark them as manually installed (as expected too). Therefore, I see 2 options here: a) Change apt documentation to include the current behaviour. But if so, it should *NOT* remove any packages. b) Remove the possibility to specify packages to upgrade as arguments (which I don't really recommend for the reasons stated above). Anyway, I think some clarification is needed from the developers to shed some light on this. Regards On Tue, Mar 12, 2024 at 3:12 AM Wesley Schwengle wrote: > On Mon, Mar 11, 2024 at 11:32:24PM +0100, Miguel Angel Rojas wrote: > > > I see. It looks like `apt upgrade ' behaves as `apt install > > > '. Which (to me) is unexpected behaviour, as the man page is > > quite > > >clear on its behaviour (man 8 apt-get): > > > > Well, clearly it shouldn’t. To begin with, “apt install” should mark a > > package as manual installed while “apt upgrade” shouldn’t (my > assumption). > > And you’re right that “apt install” can remove a package if needed to > > satisfy dependencies. > > > > On top of that, documentation clearly states that “apt upgrade” should > not > > remove any package, but it does when you specify an individual package to > > upgrade. > > > > If this is not the expected behavior, maybe this is a bug (unless I am > > missing something here). > > I do not know what the bug here is, it could be one of these options: > > 1) apt-get/apt upgrade accepts packages to upgrade where the docs state it >doesn't. The behaviour needs to change to not accept packages. > > 2) apt-get/apt upgrade accepts packages and removes packages to satisfy > deps >where the docs state it doesn't. The behaviour need to change to not > remove >any packages. There is a small edge case where you can say: `apt > upgrade foo >bar-'. Technically, it shouldn't remove packages, yet you want and > instruct >it to remove bar. > > FWIW, aptitude does not remove packages where you call `aptitude > safe-upgrade > foo'. It does remove packages when you call `aptitude full-upgrade foo'. It > also removes bar when you run `aptitude safe-upgrade foo bar-'. > > I'll leave this for the maintainers to answer. > > Cheers, > Wesley > >
Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)
> I see. It looks like `apt upgrade ' behaves as `apt install > '. Which (to me) is unexpected behaviour, as the man page is quite >clear on its behaviour (man 8 apt-get): Well, clearly it shouldn’t. To begin with, “apt install” should mark a package as manual installed while “apt upgrade” shouldn’t (my assumption). And you’re right that “apt install” can remove a package if needed to satisfy dependencies. On top of that, documentation clearly states that “apt upgrade” should not remove any package, but it does when you specify an individual package to upgrade. If this is not the expected behavior, maybe this is a bug (unless I am missing something here).
Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)
Hi Wesley, David, > You keep saying `apt upgrade' yet your command was `apt full-upgrade'. Yes, maybe it didn't express itself properly. After your suggestion about not using "apt full-upgrade" during this t64 migration, I followed your advice and used only "apt upgrade" for individual upgrades. I was referring to this comment you made below: > My advice to you is: don't expect full-upgrade to work until the transitioning > is done. You can do `apt upgrade' without too much hassle. If you feel like it > you can inspect individual upgrades possibilities via `apt list --upgradable' > and upgrade each package individually. Therefore, that's the advice I'm following right now. Now, If I type"apt upgrade" doesn't give me any option to update anything: # apt upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: linux-headers-6.6.15-amd64 linux-headers-6.6.15-common linux-image-6.6.15-amd64 linux-kbuild-6.6.15 Use 'apt autoremove' to remove them. The following packages have been kept back: gstreamer1.0-plugins-bad gstreamer1.0-plugins-good gstreamer1.0-plugins-ugly kaddressbook kmail knotes libgstreamer-plugins-bad1.0-0 libkf5akonadisearch-bin libkf5akonadisearch-plugins libkf5messagecomposer5abi1 libkf5messagecore5abi1 libkf5messagelist5abi1 libkf5messageviewer5abi1 libkf5mimetreeparser5abi1 libkf5pimcommonakonadi5abi1 libkf5templateparser5 libkf5webengineviewer5abi1 libkpimaddressbookimportexport5 libldb2 libopenconnect5 libqt5webengine5 ppp samba-libs 0 upgraded, 0 newly installed, 0 to remove and 23 not upgraded. But, in some situations, as you mentioned, individual package upgrades can work and remove some problems. So what I did was to try some "apt upgrade" on individual packages from that list. This time I try the ppp package: # apt upgrade ppp Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: linux-headers-6.6.15-amd64 linux-headers-6.6.15-common linux-image-6.6.15-amd64 linux-kbuild-6.6.15 Use 'apt autoremove' to remove them. The following packages will be REMOVED: <--- PACKAGE TO BE REMOVED libpcap0.8 The following NEW packages will be installed: libpcap0.8t64 The following packages have been kept back: gstreamer1.0-plugins-bad gstreamer1.0-plugins-good gstreamer1.0-plugins-ugly kaddressbook kmail knotes libgstreamer-plugins-bad1.0-0 libkf5akonadisearch-bin libkf5akonadisearch-plugins libkf5messagecomposer5abi1 libkf5messagecore5abi1 libkf5messagelist5abi1 libkf5messageviewer5abi1 libkf5mimetreeparser5abi1 libkf5pimcommonakonadi5abi1 libkf5templateparser5 libkf5webengineviewer5abi1 libkpimaddressbookimportexport5 libldb2 libopenconnect5 libqt5webengine5 samba-libs The following packages will be upgraded: ppp 1 upgraded, 1 newly installed, 1 to remove and 22 not upgraded. Need to get 511 kB of archives. After this operation, 15.4 kB disk space will be freed. , As you can see here, I'm typing "apt upgrade ppp" and it removes a package in this case: libpcap0.8 (sometimes more packages are removed). Which is good, because libpcap0.8 is replaced by libpcap0.8t64 (as expected in this t64 migration) but "apt upgrade ppp" is REMOVING a package (which contradicts the specification). @David: I will send you the file as you requested. Regards On Mon, Mar 11, 2024 at 5:44 PM Wesley Schwengle wrote: > > Hi Miguel, > > On Mon, Mar 11, 2024 at 05:09:47PM +0100, Miguel Angel Rojas wrote: > > > I do not know, at times I'm also wondering why it doesn't do it, but I > > didn't > > > take time to look at the code to understand what the resolver is doing. > > Also, > > > it was sort of expected. I think we can probably solve this is a more > > > controlled manner. With the current t64 transitioning in unstable it is > > > difficult to track down. Many updates so the situation now may differ > > from the > > > situation in an hour from now. > > > > Yes, it is confusing for me too. Without considering this t64 migration, > > “apt upgrade” should *NOT* remove any package (just upgrading a package > to > > a newer version or install new dependencies). But it is removing packages > > right now! i.e. again, with this t64 migration, it makes the old > libraries > > to be uninstalled and install the new *t64 version. > > > > Any thoughts why “apt upgrade” is removing packages even when > documentation > > says it shouldn’t? or is it a bug? > > You keep saying `apt upgrade' yet your command was `apt full-upgrade'. As > said > earlier, full-upgrade does indeed remove packages to be able to perform an > upgrade. I haven't seen `apt upgrade' do that. So I cannot comment on apt > doing > something wrong when it isn't :) > > Cheers, > Wesley >
Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)
Hi Wesley, Good conversation here. Let me give you some comments from my side: > No, there is (or was) something going on with the dependencies of gdm-minimal > for sure. I think it is related to libdebuginfod1, which has a t64 variant. > This one has a dependency to libelf1 and libdw1. Now the libdebuginfod1t64 > depends on libelf1t64 and libdw1t64. These two replace libelf1 and libdw1, the > former having a relative high count of reverse dependencies. I didn’t catch this one (and I spent a fair amount of time trying to find out what was going on) ;) Thank you for spotting it! > I do not know, at times I'm also wondering why it doesn't do it, but I didn't > take time to look at the code to understand what the resolver is doing. Also, > it was sort of expected. I think we can probably solve this is a more > controlled manner. With the current t64 transitioning in unstable it is > difficult to track down. Many updates so the situation now may differ from the > situation in an hour from now. Yes, it is confusing for me too. Without considering this t64 migration, “apt upgrade” should *NOT* remove any package (just upgrading a package to a newer version or install new dependencies). But it is removing packages right now! i.e. again, with this t64 migration, it makes the old libraries to be uninstalled and install the new *t64 version. Any thoughts why “apt upgrade” is removing packages even when documentation says it shouldn’t? or is it a bug? > I disagree (or agree) to some extent. The gdb-minimal has been held back on my > system for a long time. I removed it after I saw it was a remnant of a KDE > experiment I did. The fact that I can install it now is a change from a couple > of days ago. The bug may be the same, but with how unstable it is now with > this big transition, it's wise to leave it where we are now and break it down > into a more controlled reproduction path, where we don't have so many moving > pieces. Yes, I fully agreed with that! Let’s wait until packages are fully settled down. I have a feeling that it is the same bug but there is no way to probe it with this transition going on. Regards On Mon, Mar 11, 2024 at 3:04 PM Wesley Schwengle wrote: > > Hello Miguel, > > On Mon, Mar 11, 2024 at 09:50:12AM +0100, Miguel Angel Rojas wrote: > > > >This problem isn't because of apt, the problem is that gdb-minimal/gdb > > > dependencies cannot be satified. A full-upgrade is the equivalent of a > > > dist-upgrade which will remove packages to resolve the dependencies. > The > > > problem you are facing is the t64 transition[1][2] where not all > packages > > are > > > transitioned. > > > > I haven't detected any "gdb | gdb-minimal dependencies that can't be > > satisfied at this point. Everything seems to be OK with those packages. > > No, there is (or was) something going on with the dependencies of > gdm-minimal > for sure. I think it is related to libdebuginfod1, which has a t64 variant. > This one has a dependency to libelf1 and libdw1. Now the libdebuginfod1t64 > depends on libelf1t64 and libdw1t64. These two replace libelf1 and libdw1, > the > former having a relative high count of reverse dependencies. > > > > My advice to you is: don't expect full-upgrade to work until the > > transitioning > > > is done. > > > > You nail it here! I have managed to upgrade package by package but it is > a > > tedious process until the whole transition is completed. > > Some of them yes, but often after doing one, you can use `apt upgrade' to > see if it resolved other problems (which in my case it does from time to > time). > > > But "apt upgrade" > > should not remove any packages according to its documentation (man apt) > > That is correct, but you were executing full-upgrade: > > > > On Sun, Mar 10, 2024 at 02:13:34PM +0100, Miguel Angel wrote: > > > > > > > # apt full-upgrade > > > > Reading package lists... Done > > > > Building dependency tree... Done > > > > Reading state information... Done > > > > Calculating upgrade... Error! > > > > Some packages could not be installed. This may mean that you have > > > > requested an impossible situation or if you are using the unstable > > > > distribution that some required packages have not yet been created > > > > or been moved out of Incoming. > > > > The following information may help to resolve the situation: > > > Why is this t64 upgrade working then as it is removing deprecated > packages > > for *t64 packages? > > I do not know, at times I'm also wondering wh
Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)
Hi Wesley, >This problem isn't because of apt, the problem is that gdb-minimal/gdb > dependencies cannot be satified. A full-upgrade is the equivalent of a > dist-upgrade which will remove packages to resolve the dependencies. The > problem you are facing is the t64 transition[1][2] where not all packages are > transitioned. I haven't detected any "gdb | gdb-minimal dependencies that can't be satisfied at this point. Everything seems to be OK with those packages. > My advice to you is: don't expect full-upgrade to work until the transitioning > is done. You nail it here! I have managed to upgrade package by package but it is a tedious process until the whole transition is completed. But "apt upgrade" should not remove any packages according to its documentation (man apt) *"upgrade is used to install available upgrades of all packages currently installed on the system from the sources configured via sources.list(5). New packages will be installed if required to satisfy dependencies, but existing packages will never be removed. If an upgrade for apackage requires the remove of an installed package the upgrade for thispackage isn't performed."* Why is this t64 upgrade working then as it is removing deprecated packages for *t64 packages? > This seems to be an more of an actual issue where dependencies are declared but >apt doing something weird. But that is an issue on bookworm where we aren't >getting poluted results because of a transitioning. I'm glad you were able to replicate in bookworm (stable) it but I don't think (at least in this case) it is related to the t64 transition. Same errors on both distributions and I checked that gdb dependencies were satisfied in unstable (I don't have a system running stable). > I don't know either and that question should be redirected to the > plasma-workspace maintainer. good advice! I will. Appreciate your support. Thanks! On Sun, Mar 10, 2024 at 8:20 PM Wesley Schwengle wrote: > On Sun, Mar 10, 2024 at 02:13:34PM +0100, Miguel Angel wrote: > > > # apt full-upgrade > > Reading package lists... Done > > Building dependency tree... Done > > Reading state information... Done > > Calculating upgrade... Error! > > Some packages could not be installed. This may mean that you have > > requested an impossible situation or if you are using the unstable > > distribution that some required packages have not yet been created > > or been moved out of Incoming. > > The following information may help to resolve the situation: > > > > The following packages have unmet dependencies: > > plasma-workspace : Depends: gdb-minimal but it is not going to be > installed or > > gdb > > E: Error, pkgProblemResolver::Resolve generated breaks, this may be > caused by held packages. > > > > This problem isn't because of apt, the problem is that gdb-minimal/gdb > dependencies cannot be satified. A full-upgrade is the equivalent of a > dist-upgrade which will remove packages to resolve the dependencies. The > problem you are facing is the t64 transition[1][2] where not all packages > are > transitioned. > > My advice to you is: don't expect full-upgrade to work until the > transitioning > is done. You can do `apt upgrade' without too much hassle. If you feel > like it > you can inspect individual upgrades possibilities via `apt list > --upgradable' > and upgrade each package individually. That has worked well for me in the > past > week with aptitude, but it requires going through many offered solutions. > > > I've seen other users are experimenting the same issue: > > https://groups.google.com/g/linux.debian.user/c/7gpQImSH-Cs > > This seems to be an more of an actual issue where dependencies are > declared but > apt doing something weird. But that is an issue on bookworm where we aren't > getting poluted results because of a transitioning. It differs from yours > because your apt output says "gdb-minimal but it is not going to be > installed > or gdb" so apt sees the alternative, but cannot install it either. IMHO, > that should > be filed as a seperate bug against apt on bookworm. And if possible > checked on > testing as well. FWIW, I can reproduce it on bookwork with apt, apt-get and > aptitude, where the latter offers a solution to install gdb and not > deinstall > plasma-workspace. > > > I don't know why plasma-workspace depends on gdb > > I don't know either and that question should be redirected to the > plasma-workspace maintainer. > > Cheers, > Wesley > > [1] https://lists.debian.org/debian-devel-announce/2024/02/msg0.html > [2] > https://www.reddit.com/r/debian/comments/1b2ncdn/64bit_time_t_transition_in_progress_in_unstable/ > >
Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)
Package: apt Version: 2.7.13+b1 Severity: normal X-Debbugs-Cc: mianro...@gmail.com # apt full-upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Error! Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: plasma-workspace : Depends: gdb-minimal but it is not going to be installed or gdb E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. I don't know why plasma-workspace depends on gdb, but nevertheless, full-upgrade doesn't work. I've seen other users are experimenting the same issue: https://groups.google.com/g/linux.debian.user/c/7gpQImSH-Cs If you mark plasma-workspace as hold, apt is still trying to remove other kde & plasma package (its reverse dependencies). -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Key ""; APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-.*"; APT::VersionedKernelPackages:: "kfreebsd-.*"; APT::VersionedKernelPackages:: "gnumach-.*"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "tasks"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Update ""; APT::Update::Post-Invoke-Success ""; APT::Update::Post-Invoke-Success:: "/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null"; APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/swcatalog -a -e /usr/bin/appstreamcli; then appstreamcli refresh --source=os > /dev/null || true; fi"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::zstd ""; APT::Compressor::zstd::Name "zstd"; APT::Compressor::zstd::Extension ".zst"; APT::Compressor::zstd::Binary "zstd"; APT::Compressor::zstd::Cost "60"; APT::Compressor::zstd::CompressArg ""; APT::Compressor::zstd::CompressArg:: "-19"; APT::Compressor::zstd::UncompressArg ""; APT::Compressor::zstd::UncompressArg:: "-d"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "false"; APT::Compressor::lz4::Cost "50"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-6n"; APT::Compressor::gzip::UncompressArg ""; APT::Compressor::gzip::UncompressArg:: "-d"; APT::Compressor::xz ""; APT::Compressor::xz::Name "xz"; APT::Compressor::xz::Extension ".xz"; APT::Compressor::xz::Binary "xz"; APT::Compressor::xz::Cost "200"; APT::Compressor::xz::CompressArg ""; APT::Compressor::xz::CompressArg:: "-6"; APT::Compressor::xz::UncompressArg ""; APT::Compressor::xz::UncompressArg:: "-d"; APT::Compressor::bzip2 ""; APT::Compressor::bzip2::Name "bzip2"; APT::Compressor::bzip2::Extension ".bz2"; APT::Compressor::bzip2::Binary "bzip2"; APT::Compressor::bzip2::Cost "300"; APT::Compressor::bzip2::CompressArg ""; APT::Compressor::bzip2::CompressArg:: "-6"; APT::Compressor::bzip2::UncompressArg ""; APT::Compressor::bzip2::UncompressArg:: "-d"; APT::Compressor::lzma ""; APT::Compressor::lzma::Name "lzma"; APT::Compressor::lzma::Extension ".lzma"; APT::Compressor::lzma::Binary "xz"; APT::Compressor::lzma::Cost "400"; APT::Compressor::lzma::CompressArg ""; APT::Compressor::lzma::CompressArg:: "--format=lzma"; APT::Compressor::lzma::CompressArg:: "-6"; APT::Compressor::lzma::UncompressArg ""; APT::Compressor::lzma::UncompressArg:: "--format=lzma"; APT::Compressor::lzma::UncompressArg:
Bug#1058646: ITP: qbe -- Small embeddable C compiler backend
On Thu, Feb 22, 2024 at 09:46:00PM +, Amin Bandali wrote: > On Thu, Feb 22, 2024 at 09:23:20PM +0000, Miguel Landaeta wrote: > > On Thu, Feb 22, 2024 at 02:19:21AM +, Amin Bandali wrote: > > > Hi Miguel, > > > > > > I'm interested in helping with this. Do you have the current state > > > of your work available on Salsa or elsewhere that I could pull in > > > and work on? Otherwise I'll just start with a repo under my own > > > account and we could later transfer it to the 'debian' group or > > > elsewhere. > > > > Hi Amin, thanks for reaching out. > > > > I'll push my repo tomorrow or during the weekend to salsa and > > update this thread with the link. Hi again Amin, I just pushed my repo to Salsa: https://salsa.debian.org/debian/qbe The package builds fine on my machine but I didn't test this qbe release yet with hare. I'll try to do that tomorrow when I push my hare repo as well. I think qbe is almost ready for an upload but it's missing a man page and probably just need a review from another DD to be sure I didn't miss anything important. Cheers, Miguel. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. "Faith means not wanting to know what is true." -- Nietzsche
Bug#1058645: Do you need help with this package?
On Thu, Jan 18, 2024 at 07:50:29PM +0100, Martin Quinson wrote: > Hello, > > I'm wondering whether you need some help with the packaging of Hare. Is your > current state available somewhere? Hi Martin, I apologize that I somehow missed this message in January. I prepared a package a few weeks ago but I was waiting for qbe new upstream release (#1058646) before proceeding with uploads to the archive. Since I'm now noticing there are more folks interested in collaborating, I'll prioritize this to push my repo to salsa this weekend so other folks can help to get it ready or just reuse bits from other packaging efforts if they meet Debian archive expectations. I don't have my debian laptop handy but tomorrow I'll spend some time on this and update this bug report with the repo link. Cheers, Miguel. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. "Faith means not wanting to know what is true." -- Nietzsche
Bug#1058646: ITP: qbe -- Small embeddable C compiler backend
On Thu, Feb 22, 2024 at 02:19:21AM +, Amin Bandali wrote: > Hi Miguel, > > I'm interested in helping with this. Do you have the current state > of your work available on Salsa or elsewhere that I could pull in > and work on? Otherwise I'll just start with a repo under my own > account and we could later transfer it to the 'debian' group or > elsewhere. Hi Amin, thanks for reaching out. I'll push my repo tomorrow or during the weekend to salsa and update this thread with the link. I started to work on this package a few weeks ago but I decided to wait for qbe 1.2 before uploading a package and I just noticed it finally happened this week so I was planning to resume my work on it. I don't have time to work on it this weekend but I'll publish it in a few hours to unblock you and other folks interested in collaborating. If you want, I can add you as co-maintainer. Cheers, Miguel. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. "Faith means not wanting to know what is true." -- Nietzsche
Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2
Hi Diederik, > While 'annoying', this is expected behavior. It tries to load the newest (-83) Yes, this is the expected behavior from our Linux kernel. However, I agree with you and these messages are very annoying and should be removed. > It could be it wouldn't be shown if it had already found one of the earlier logged firmware files. Interesting theory! When the new version of the firmware packages is uploaded, we can check again if the "'iwl-debug-yoyo.bin" message disappears Why are you confused with the numbers? >Bit confused about that version number, but looks like success. And yes, wifi is working fine although I haven't properly done any performance test yet. Regards On Sun, Feb 11, 2024 at 4:15 PM Diederik de Haas wrote: > Hi Miguel, > > On Sunday, 11 February 2024 16:03:20 CET Miguel A. Rojas wrote: > > I forgot to include you the dmesg as promised: > > > > [2.235947] iwlwifi :00:14.3: enabling device ( -> 0002) > > [2.237778] iwlwifi :00:14.3: Detected crf-id 0x1300504, cnv-id > > 0x80401 wfpm id 0x8030 > > [2.237805] iwlwifi :00:14.3: PCI dev 7a70/0074, rev=0x430, > > rfid=0x10a100 > > [2.237845] iwlwifi :00:14.3: firmware: failed to load > > iwlwifi-so-a0-hr-b0-83.ucode (-2) > > [2.237867] iwlwifi :00:14.3: firmware: failed to load > > iwlwifi-so-a0-hr-b0-83.ucode (-2) > > ... more firmware load failures > > [2.238098] iwlwifi :00:14.3: Direct firmware load for > > iwlwifi-so-a0-hr-b0-73.ucode failed with error -2 > > [2.241012] iwlwifi :00:14.3: firmware: direct-loading firmware > > iwlwifi-so-a0-hr-b0-72.ucode > > While 'annoying', this is expected behavior. It tries to load the newest > (-83) > and when it can't find that, it tries an older one and ends up with '-72'. > > > [2.247819] iwlwifi :00:14.3: api flags index 2 larger than > > supported by driver > > [2.247832] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: > > 0.0.2.36 > > [2.248049] iwlwifi :00:14.3: firmware: failed to load > > iwl-debug-yoyo.bin (-2) > <- > > [2.248067] iwlwifi :00:14.3: firmware: failed to load > > iwl-debug-yoyo.bin (-2) > <- > > This 'iwl-debug-yoyo.bin' is a familiar one, but this file is NOT > available in > the upstream linux-firmware repo. > It could be it wouldn't be shown if it had already found one of the > earlier > logged firmware files. > I might look into this particular issue at some later date. > > > [2.248078] iwlwifi :00:14.3: loaded firmware version > > 72.daa05125.0 so-a0-hr-b0-72.ucode op_mode iwlmvm > > Bit confused about that version number, but looks like success ... > > > [2.653952] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6 AX201 > > 160MHz, REV=0x430 > > [2.769070] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f > > [2.769102] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f > > [2.769110] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90 > > [2.769118] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10 > > [2.769154] iwlwifi :00:14.3: Detected RF HR B3, rfid=0x10a100 > > [2.834751] iwlwifi :00:14.3: base HW address: bc:09:1b:d3:e2:ee > > [2.849492] iwlwifi :00:14.3 wlp0s20f3: renamed from wlan0 > > [6.570171] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f > > [6.570263] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f > > [6.570275] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90 > > [6.570307] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10 > > [6.644756] iwlwifi :00:14.3: Registered PHC clock: iwlwifi-PTP, > > with index: 0 > > [6.809353] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f > > [6.809386] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f > > [6.809397] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90 > > [6.809408] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10 > > ... and from this it seems the device appears to be working properly? > > If that's indeed the case then this bug would essentially be a request for > a > new upstream version. > > Cheers, > Diederik
Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2
Hi Diederik, I forgot to include you the dmesg as promised: [ 2.235947] iwlwifi :00:14.3: enabling device ( -> 0002) [ 2.237778] iwlwifi :00:14.3: Detected crf-id 0x1300504, cnv-id 0x80401 wfpm id 0x8030 [ 2.237805] iwlwifi :00:14.3: PCI dev 7a70/0074, rev=0x430, rfid=0x10a100 [ 2.237845] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-83.ucode (-2) [ 2.237867] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-83.ucode (-2) [ 2.237874] iwlwifi :00:14.3: Direct firmware load for iwlwifi-so-a0-hr-b0-83.ucode failed with error -2 <- [ 2.237879] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-82.ucode (-2) [ 2.237890] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-82.ucode (-2) [ 2.237896] iwlwifi :00:14.3: Direct firmware load for iwlwifi-so-a0-hr-b0-82.ucode failed with error -2 [ 2.237900] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-81.ucode (-2) [ 2.237916] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-81.ucode (-2) [ 2.237927] iwlwifi :00:14.3: Direct firmware load for iwlwifi-so-a0-hr-b0-81.ucode failed with error -2 [ 2.237932] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-80.ucode (-2) [ 2.237945] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-80.ucode (-2) [ 2.237955] iwlwifi :00:14.3: Direct firmware load for iwlwifi-so-a0-hr-b0-80.ucode failed with error -2 [ 2.237958] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-79.ucode (-2) [ 2.237968] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-79.ucode (-2) [ 2.237975] iwlwifi :00:14.3: Direct firmware load for iwlwifi-so-a0-hr-b0-79.ucode failed with error -2 [ 2.237978] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-78.ucode (-2) [ 2.237988] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-78.ucode (-2) [ 2.237994] iwlwifi :00:14.3: Direct firmware load for iwlwifi-so-a0-hr-b0-78.ucode failed with error -2 [ 2.237998] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-77.ucode (-2) [ 2.238007] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-77.ucode (-2) [ 2.238014] iwlwifi :00:14.3: Direct firmware load for iwlwifi-so-a0-hr-b0-77.ucode failed with error -2 [ 2.238018] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-76.ucode (-2) [ 2.238027] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-76.ucode (-2) [ 2.238034] iwlwifi :00:14.3: Direct firmware load for iwlwifi-so-a0-hr-b0-76.ucode failed with error -2 [ 2.238038] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-75.ucode (-2) [ 2.238052] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-75.ucode (-2) [ 2.238059] iwlwifi :00:14.3: Direct firmware load for iwlwifi-so-a0-hr-b0-75.ucode failed with error -2 [ 2.238062] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-74.ucode (-2) [ 2.238072] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-74.ucode (-2) [ 2.238078] iwlwifi :00:14.3: Direct firmware load for iwlwifi-so-a0-hr-b0-74.ucode failed with error -2 [ 2.238082] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-73.ucode (-2) [ 2.238091] iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-73.ucode (-2) [ 2.238098] iwlwifi :00:14.3: Direct firmware load for iwlwifi-so-a0-hr-b0-73.ucode failed with error -2 [ 2.241012] iwlwifi :00:14.3: firmware: direct-loading firmware iwlwifi-so-a0-hr-b0-72.ucode [ 2.247819] iwlwifi :00:14.3: api flags index 2 larger than supported by driver [ 2.247832] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.2.36 [ 2.248049] iwlwifi :00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2) <- [ 2.248067] iwlwifi :00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2) <- [ 2.248078] iwlwifi :00:14.3: loaded firmware version 72.daa05125.0 so-a0-hr-b0-72.ucode op_mode iwlmvm [ 2.653952] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=0x430 [ 2.769070] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f [ 2.769102] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f [ 2.769110] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90 [ 2.769118] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10 [ 2.769154] iwlwifi :00:14.3: Detected RF HR B3, rfid=0x10a100 [ 2.834751] iwlwifi :00:14.3: base HW address: bc:09:1b:d3:e2:ee [ 2.849492] iwlwifi :00:14.3 wlp0s20f3: renamed from wlan0 [ 6.570171] iwlwifi :00:14.3: WF
Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2
Hi Diederik, My bad. Let me explain again. Taking into account the firmware errors: - Realtek messages are fixed now. There are no actions to be done here. - iwlwifi: If you are still working on a new version containing the -83 file, that should fix some warning messages but not all of them. There is another message (*firmware: failed to load iwl-debug-yoyo.bin (-2)*) that I think is related to bug #966218. This bug has been there for a while, so I don't know what's happening here. Nobody explains what's going on or why this file is not included in the firmware package. Thanks! On Fri, Feb 9, 2024 at 7:48 PM Diederik de Haas wrote: > Control: tag -1 moreinfo > > Hi, > > On Friday, 9 February 2024 19:35:01 CET Miguel A. Rojas wrote: > > A few days ago, I went to > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git > > and update the missing loaded modules. > > > > Indeed, I noticed that I have another messages related to the iwlwifi > > module: "kernel: iwlwifi :00:14.3: firmware: failed to load > > iwlwifi-so-a0-hr-b0-83.ucode (-2)". > > The reason I asked for more dmesg lines is that it likely then tried > (f.e.) > -81, then -79 and then probably succeeded at some point. > The Debian kernel (unfortunately imo) 'promoted' warning/info messages to > errors, which make it appear more severe then they actually are. > > > I think the the root cause is that the current Debian packages firmware > > packages are 6 months old and they need to be updated accordingly. New > > Debian Linux kernel expects a specific version of the firmware or the > > name of the firmware has changed. > > I do think that the old package versions are a problem, so I have been > working > on Merge Requests for updating them. > Version 20230804 would make the -83 file available. > But the device using and older version should still work. If it doesn't > work > with an older version, but it does work with a newer, that's important > info. > > But I'm still a bit confused as this bug is about *realtek* firmware, not > iwlwifi? Can you answer the question I asked previously?
Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2
Hi Diederik, A few days ago, I went to https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git and update the missing loaded modules. Indeed, I noticed that I have another messages related to the iwlwifi module: "kernel: iwlwifi :00:14.3: firmware: failed to load iwlwifi-so-a0-hr-b0-83.ucode (-2)". I think the the root cause is that the current Debian packages firmware packages are 6 months old and they need to be updated accordingly. New Debian Linux kernel expects a specific version of the firmware or the name of the firmware has changed. Regards O
Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2
Package: firmware-realtek Version: 20230625-2 Severity: important X-Debbugs-Cc: mianro...@gmail.com At system boot, the following message is shown: "Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2". It seesm that the firmware is not properly loaded by kernel at boot. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-realtek depends on no packages. firmware-realtek recommends no packages. Versions of packages firmware-realtek suggests: ii initramfs-tools 0.142 -- no debconf information
Bug#1056612: retweet: Please remove this package
Control: severity -1 normal Control: retitle -1 RM: retweet -- RoQA; unusable Please remove retweet. It is unusable because of #996800 and even conceptually now that the Twitter API was hidden from public access.
Bug#1058646: ITP: qbe -- Small embeddable C compiler backend
Package: wnpp Severity: wishlist Owner: Miguel Landaeta X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: qbe Version : 1.1 Upstream Contact: Quentin Carbonneaux * URL : https://c9x.me/compile/ * License : MIT Programming Lang: C Description : Small embeddable C compiler backend QBE is a compiler backend that aims to provide 70% of the performance of industrial optimizing compilers in 10% of the code. QBE fosters language innovation by offering a compact user-friendly and performant backend. The size limit constrains QBE to focus on the essential and prevents embarking on a never-ending path of diminishing returns. QBE is a build-dependency of Hare. See https://c9x.me/compile/users.html for other QBE language frontends.
Bug#1058645: ITP: hare -- Hare is a systems programming language designed to be simple, stable, and robust.
Package: wnpp Severity: wishlist Owner: Miguel Landaeta X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: hare Version : 2023.12.02 Upstream Contact: Drew DeVault * URL : https://harelang.org/ * License : MPL/GPL-3 Programming Lang: Hare Description : Hare is a systems programming language designed to be simple, stable, and robust. Hare uses a static type system, manual memory management, and a minimal runtime. It is well-suited to writing operating systems, system tools, compilers, networking software, and other low-level, high performance tasks.
Bug#1057843: (no subject)
If it helps people, this is what I did on systems that automatically had rebooted into the problematic kernel. First, I uninstalled the 6.1.0-14 kernel and rebooted back into 6.1.0-13. Then I used `last` to identify the time between the problematic reboot into 6.1.0-14 and the deliberate reboot (back in to 6.1.0-13) This showed me that the 'problem time' was between 2023-12-10 06:00:00 and 2023-12-10 19:00:00 (UTC). >From there, I ran the followin gcommand to show me all files that were >modified more or less between that time. I ignore a bunch of things I don't >care about such as /var/log and other volatile parts of the filesystem. find / -type f -newermt "2023-12-10 05:59:00" \! -newermt "2023-12-10 19:00:00" | egrep -v "/proc|/run|/sys|/var/log" At least this gave me a somewhat small subset of files to manually check, which made it feel less daunting. Naturally it depends on your filesystem what files might've changed. I was fortunate that none of the client applications I use, seem to use O_DIRECT, so I found no corrupted files (so far). Note that use of O_DIRECT is not a system-wide setting (e.g not one in /etc/fstab for the ext4 filesystem), it's something that each application can choose to use when working with files. For example, I have changed MySQL's innodb_flush_method to be O_DIRECT in the past (for performance), but it's not the default. Out of the box, things like postgresql use fsync (not direct IO) by default. I used some tools like 'git fsck' in git repositories that had changed during my 'problematic' time, and there were no issues - hopefully git does not use O_DIRECT. I have not been able to find any definitive list of programs that use O_DIRECT out-of-the box. Maybe someone else will come up with such a list (if there even *are* programs that do so). As others have said here, things like fsck won't likely help you, unfortunately. The nature of the bug is not one that corrupts the journaling/filesystem structure, it is more about the *contents* of the file, which fsck can't comment on. Finally, I wanted to note: if you did `apt purge linux-image-6.1.0-14-amd64`, you might need to `apt install linux-image-amd64` (the meta package) before you can successfully pick up the new linux-image-6.1.0-15-amd64 automatically as a dependency (say, when doing apt update; apt dist-upgrade). At least, I needed to, as I think the purge automatically removed the meta package, leaving me with no *automatic* upgrade to the new kernel via those commands. Good luck!
Bug#1042129: jruby: FTBFS: [ERROR] /<>/core/src/main/java/org/jruby/ext/strscan/RubyStringScanner.java:[653,34] error: cannot find symbol
On Thu, Dec 7, 2023 at 3:46 PM Jérôme Charaoui wrote: > > For the record, the upload is ready to go. I'm now only waiting for a > new build-dependency to pass through NEW, jruby-mavengem. > Sounds great, I'll take a look at the new package. Thanks for working on the 9.4 release. On my side in the meantime, I recently have been refreshing and updating several jruby build-dependencies like jnr-* package and a few other related packages.
Bug#1057363: RM: twitterwatch -- RoQA; Upstream Dead; Useless with Twitter API Changes
On Tue, Dec 05, 2023 at 12:04:31AM -0500, Boyuan Yang wrote: > > I am not the package maintainer for db2twitter or retweet, so I am not in the > position > of saying whether I should object or not. > > I see that you are also a Debian Developer; you should have the same > permission or right > on RM bug submission as I do. Ack. I already pinged directly the maintainer for the packages I mentioned and I'll take action soon if no answer is received. I thought twitterwatch removal was asked as part of general QA process so that's why I asked for those packages in the first place. Cheers, Miguel.
Bug#1057363: RM: twitterwatch -- RoQA; Upstream Dead; Useless with Twitter API Changes
On Mon, Dec 4, 2023 at 12:09 AM Boyuan Yang wrote: > > [...] > > Dear Debian FTP Masters, > > As discussed in https://bugs.debian.org/1056613 , package twitterwatch makes > use > of Twitter API, which is gone since 2023. Its upstream shows no activity for > 7 years, > and the Debian package received no maintainer updates since 2016. As a > result, I > believe we should have package twitterwatch removed from Debian archive. > Hi Boyuan, Thanks for submitting this bug. Do you have any objection to doing the same for db2twitter and retweet packages? I think they are in the same situation. Cheers, Miguel. -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/ "Faith means not wanting to know what is true." -- Nietzsche
Bug#1054747: ruby-octokit: FTBFS: ERROR: Test "ruby3.1" failed: Failure/Error: require 'pry-byebug'
On Fri, Oct 27, 2023 at 09:20:42PM +0200, Lucas Nussbaum wrote: > Source: ruby-octokit > Version: 4.20.0-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20231027 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > Failure/Error: require 'pry-byebug' > > > > Gem::MissingSpecError: > > Could not find 'pry' (~> 0.13.0) among 122 total gem(s) A possible fix for this issue could be to just update pry-byebug package to a more recent release. https://github.com/deivid-rodriguez/pry-byebug/commit/a915f21fc63aa94473bbe7cb752c0fabacc3e567 pry-byebug 3.10.1 depends on a pry version that's in the archive. https://packages.debian.org/source/unstable/pry
Bug#1057324: jcsp: Upgrade to 1.1.10
Source: jcsp Version: 1.1-rc4-2.1 Severity: wishlist I'm filing this mostly as help for the next maintainer (maybe myself in the future). Upstream migrated to Github: https://github.com/CSPforJAVA/jcsp 1.1.10 release should be compatible with what is in the archive, however upstream switched their Java package name from "org.jcsp" to "jcsp", so probably new patches will be needed for some dependencies. I don't have time now for work on this, that's why this is wishlist. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1057042: [patch] Drop dependency on libjsr166y-java
tags 1057042 + patch
thanks
https://salsa.debian.org/clojure-team/clojure/-/merge_requests/3
diff --git a/debian/changelog b/debian/changelog
index bab9d0f0..138cc6b0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+clojure (1.11.1-3) UNRELEASED; urgency=medium
+
+ * Team upload.
+ * Drop dependency on libjsr166y-java. (Closes: #1057042)
+
+ -- Miguel Landaeta Sat, 02 Dec 2023 21:16:06 +
+
clojure (1.11.1-2) unstable; urgency=medium
* Change the symlinked maven artifact for libclojure-java from 1.11.x to
diff --git a/debian/control b/debian/control
index 0ccfb227..0d3523b4 100644
--- a/debian/control
+++ b/debian/control
@@ -50,7 +50,6 @@ Description: Lisp dialect for the JVM
Package: libclojure-java
Architecture: all
Depends:
- libjsr166y-java,
${java:Depends},
${misc:Depends}
Breaks: clojure (<< 1.9.0-3), clojure1.8 (<< 1.8.0-6), libclojure1.8-java (<<
1.8.0-6)
diff --git a/debian/changelog b/debian/changelog
index bab9d0f0..138cc6b0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+clojure (1.11.1-3) UNRELEASED; urgency=medium
+
+ * Team upload.
+ * Drop dependency on libjsr166y-java. (Closes: #1057042)
+
+ -- Miguel Landaeta Sat, 02 Dec 2023 21:16:06 +
+
clojure (1.11.1-2) unstable; urgency=medium
* Change the symlinked maven artifact for libclojure-java from 1.11.x to
diff --git a/debian/control b/debian/control
index 0ccfb227..0d3523b4 100644
--- a/debian/control
+++ b/debian/control
@@ -50,7 +50,6 @@ Description: Lisp dialect for the JVM
Package: libclojure-java
Architecture: all
Depends:
- libjsr166y-java,
${java:Depends},
${misc:Depends}
Breaks: clojure (<< 1.9.0-3), clojure1.8 (<< 1.8.0-6), libclojure1.8-java (<< 1.8.0-6)
Bug#1056902: RM: libbytelist-java -- ROM; unused, obsolete
retitle 1056902 RM: libbytelist-java -- ROM; unused, obsolete severity 1056902 normal reassign 1056902 ftp.debian.org thanks As title says. This package was used by JRuby but is obsolete nowadays. All packages in the archive depending on this were migrated or removed, so there is no more reason to keep it around. Thanks, Miguel.
Bug#1057042: libclojure-java: Please remove dependency on libjsr166y-java
Package: libclojure-java Severity: normal User: nomad...@debian.org Usertags: cleanup Dear Maintainer, I think the dependency on libjsr166y-java should be dropped: https://salsa.debian.org/clojure-team/clojure/-/blob/1c17628638ddee0073c7dfbfa911cd913f708ce1/debian/control#L53 clojure.parallel has been deprecated since several years ago: https://groups.google.com/g/clojure-dev/c/zjm4eHy9vDE?pli=1 https://github.com/clojure/clojure/blob/master/src/clj/clojure/parallel.clj#L9 The code also provide instructions for anyone who still relies on that deprecated feature on how to make it work. I'd like to be able to ask for libjsr166y-java for removal from the archive at some point in the future, if possible. Thanks, -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libclojure-java depends on: pn libcore-specs-alpha-clojure pn libjsr166y-java pn libspec-alpha-clojure libclojure-java recommends no packages. libclojure-java suggests no packages.
Bug#1056692: libhamlib4: Add protective diversion for udev rules shared file
On Mon, Nov 27, 2023 at 6:54 AM tony mancill wrote: > Hello Miguel, > > Thank you for the patch. I have applied it and tested locally and > everything appears to be working correctly. I have an upload ready > prepared, but wanted to confirm with you that this lintian error is > expected after applying the patch: > > E: libhamlib4: diversion-for-unknown-file > lib/udev/rules.d/60-libhamlib4.rules [preinst:14] > N: > N: The named maintainer script adds a diversion for a file that is not > being provided by this package. > N: > N: Visibility: error > N: Show-Always: no > N: Check: maintainer-scripts/diversion > > Should I add a lintian-override for it? Hi Tony! Yes, you are right. I forgot to add the lintian override in my patch. An override like the following should work for this: https://salsa.debian.org/debian/libnjb/-/blob/master/debian/libnjb5.lintian-overrides Thanks for looking at this patch. -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/ "Faith means not wanting to know what is true." -- Nietzsche
Bug#1056932: kakasi: Packaged version breaks transliteration to hiragana, doesn't happen with vanilla source build
Package: kakasi Version: 2.3.6-4.1 Severity: important X-Debbugs-Cc: eseeseha...@yahoo.es Dear Maintainer, When using the prepackaged version of Kakasi in Debian 12, some texts are not correctly transliterated from kanji to hiragana. Some characters just are discarded. I think it did not happen in previous Debian releases but I'm not fully sure. What I can certify is that: - It works when building Kakasi from source in Debian 12, such as: $ apt-get source kakasi; rm -rf kakasi-2.3.6; tar xf kakasi-2.3.6.orig.tar.xz $ cd kakasi-2.3.6 ; ./configure ; make $ su -c "make install" - It also works even when building Kakasi on Windows using MSVC (!) To test the bug, execute the following command: $ kakasi -iutf8 -s -JH Then input the following text (the word "subetteru", "it's slipping"): 滑ってる！？ The correct (expected) result should be: すべって る ！？ The current (broken) result is: て る ！？ Some transliterations are fine, some others are not. I don't know if it's a build flag or what is exactly happening, but as I have managed to reproduce, building Kakasi from source even in weird architectures (Android and Windows) does not exhibit this behavior. I am using the Kakasi dictionaries from Debian, just rebuilding the executable / library. Thank you, Miguel -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/3 CPU threads; PREEMPT) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages kakasi depends on: ii kakasi-dic 2.3.6-4.1 ii libc6 2.36-9+deb12u3 kakasi recommends no packages. kakasi suggests no packages. -- no debconf information
Bug#1056902: libbytelist-java: Package is obsolete and should be removed before trixie release
Package: libbytelist-java Version: 1.0.15-1 Severity: serious Filing this to get the package removed from testing. No packages should add dependencies on libbytelist-java since this package is obsolete. Its functionality is now included in JRuby (jruby.jar). See note at https://github.com/jruby/bytelist Once jvyamlb is removed (#1056899) from archive and ruby-psych its the dependency on this package, it should be removed from unstable. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libbytelist-java depends on: ii libjcodings-java 1.0.58-1 libbytelist-java recommends no packages. libbytelist-java suggests no packages. -- no debconf information
Bug#1056899: RM: jvyamlb -- ROM; obsolete, unneeded, dead upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: jvya...@packages.debian.org Control: affects -1 + src:jvyamlb As title says. This package is unmaintained at upstream and in Debian. No other packages are depending on this. There are alternatives like SnakeYAML, Psych and others.
Bug#1042129: jruby: FTBFS: [ERROR] /<>/core/src/main/java/org/jruby/ext/strscan/RubyStringScanner.java:[653,34] error: cannot find symbol
On Sat, Nov 25, 2023 at 12:29 AM Jérôme Charaoui wrote: > > [...] > > I've been working on a 9.4 release, you can see the progress here: > https://salsa.debian.org/lavamind/jruby > > I plan to upload this version to experimental within a few days, I still > have some minor issues with the testsuite to iron out before. Excellent, that's good to hear. There is no point then just backporting the fix if you are close to finishing preparing an upload. Let me know if there is something else I can help with. I think I'll take a look at some jnr-* dependencies packages that could use a new upstream release and/or bugfixes. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/ "Faith means not wanting to know what is true." -- Nietzsche
Bug#1042129: jruby: FTBFS: [ERROR] /<>/core/src/main/java/org/jruby/ext/strscan/RubyStringScanner.java:[653,34] error: cannot find symbol
Thomas and Jérôme, Do you have any concerns with me uploading a fix for this issue? I'm working with some folks here in Cambridge MiniDebConf and I also have some cycles to spare to work on JRuby and maybe prepare a new upstream release for 9.3 and/or 9.4 series (experimental).
Bug#1042129: jruby: FTBFS: [ERROR] /<>/core/src/main/java/org/jruby/ext/strscan/RubyStringScanner.java:[653,34] error: cannot find symbol
tags 1042129 + patch
thanks
Upstream handled this when they upgraded Joni dependency to 2.2 on
JRuby 9.4 series.
https://github.com/jruby/jruby/commit/3c94d31f1e198f294e9bfcb96b4188c315252b6b
https://github.com/jruby/jruby/commit/783d14bcb140477bb2577310a90742d594a48896
See attached a fix for this issue.
diff -Nru jruby-9.3.9.0+ds/debian/changelog jruby-9.3.9.0+ds/debian/changelog
--- jruby-9.3.9.0+ds/debian/changelog 2023-01-16 21:08:51.0 +
+++ jruby-9.3.9.0+ds/debian/changelog 2023-11-24 11:48:05.0 +
@@ -1,3 +1,11 @@
+jruby (9.3.9.0+ds-9~miguel1) UNRELEASED; urgency=medium
+
+ * Fix FTBFS: adapt and backport changes from 9.4 releases
+to accomodate for changes in regexp library Joni 2.2.
+(Closes: #1042129)
+
+ -- Miguel Landaeta Fri, 24 Nov 2023 11:48:05 +
+
jruby (9.3.9.0+ds-8) unstable; urgency=medium
* d/tests: flag jirb test as flaky
diff -Nru
jruby-9.3.9.0+ds/debian/patches/0012-Use-Region-accessors-in-prep-for-privatizing-fields.patch
jruby-9.3.9.0+ds/debian/patches/0012-Use-Region-accessors-in-prep-for-privatizing-fields.patch
---
jruby-9.3.9.0+ds/debian/patches/0012-Use-Region-accessors-in-prep-for-privatizing-fields.patch
1970-01-01 01:00:00.0 +0100
+++
jruby-9.3.9.0+ds/debian/patches/0012-Use-Region-accessors-in-prep-for-privatizing-fields.patch
2023-11-24 11:48:05.0 +
@@ -0,0 +1,390 @@
+Subject: Use Region accessors in prep for privatizing fields
+Forwarded:
https://github.com/jruby/jruby/commit/3c94d31f1e198f294e9bfcb96b4188c315252b6b
+--
+diff --git a/core/src/main/java/org/jruby/RubyMatchData.java
b/core/src/main/java/org/jruby/RubyMatchData.java
+index 48fa92b..87e7c9d 100644
+--- a/core/src/main/java/org/jruby/RubyMatchData.java
b/core/src/main/java/org/jruby/RubyMatchData.java
+@@ -175,11 +175,11 @@ public class RubyMatchData extends RubyObject {
+ private void updateCharOffsetOnlyOneReg(ByteList value, Encoding
encoding) {
+ if (charOffsetUpdated) return;
+
+-if (charOffsets == null || charOffsets.numRegs < 1) charOffsets = new
Region(1);
++if (charOffsets == null || charOffsets.getNumRegs() < 1) charOffsets
= new Region(1);
+
+ if (encoding.maxLength() == 1) {
+-charOffsets.beg[0] = begin;
+-charOffsets.end[0] = end;
++charOffsets.setBeg(0, begin);
++charOffsets.setEnd(0, end);
+ charOffsetUpdated = true;
+ return;
+ }
+@@ -195,14 +195,14 @@ public class RubyMatchData extends RubyObject {
+ updatePairs(value, encoding, pairs);
+
+ if (begin < 0) {
+-charOffsets.beg[0] = charOffsets.end[0] = -1;
++charOffsets.setBeg(0, charOffsets.setEnd(0, -1));
+ return;
+ }
+ Pair key = new Pair();
+ key.bytePos = begin;
+-charOffsets.beg[0] = pairs[Arrays.binarySearch(pairs, key)].charPos;
++charOffsets.setBeg(0, pairs[Arrays.binarySearch(pairs, key)].charPos);
+ key.bytePos = end;
+-charOffsets.end[0] = pairs[Arrays.binarySearch(pairs, key)].charPos;
++charOffsets.setEnd(0, pairs[Arrays.binarySearch(pairs, key)].charPos);
+
+ charOffsetUpdated = true;
+ }
+@@ -211,14 +211,14 @@ public class RubyMatchData extends RubyObject {
+ if (charOffsetUpdated) return;
+
+ final Region regs = this.regs;
+-int numRegs = regs.numRegs;
++int numRegs = regs.getNumRegs();
+
+-if (charOffsets == null || charOffsets.numRegs < numRegs) charOffsets
= new Region(numRegs);
++if (charOffsets == null || charOffsets.getNumRegs() < numRegs)
charOffsets = new Region(numRegs);
+
+ if (encoding.maxLength() == 1) {
+ for (int i = 0; i < numRegs; i++) {
+-charOffsets.beg[i] = regs.beg[i];
+-charOffsets.end[i] = regs.end[i];
++charOffsets.setBeg(i, regs.getBeg(i));
++charOffsets.setEnd(i, regs.getEnd(i));
+ }
+ charOffsetUpdated = true;
+ return;
+@@ -229,23 +229,23 @@ public class RubyMatchData extends RubyObject {
+
+ int numPos = 0;
+ for (int i = 0; i < numRegs; i++) {
+-if (regs.beg[i] < 0) continue;
+-pairs[numPos++].bytePos = regs.beg[i];
+-pairs[numPos++].bytePos = regs.end[i];
++if (regs.getBeg(i) < 0) continue;
++pairs[numPos++].bytePos = regs.getBeg(i);
++pairs[numPos++].bytePos = regs.getEnd(i);
+ }
+
+ updatePairs(value, encoding, pairs);
+
+ Pair key = new Pair();
+-for (int i = 0; i < regs.numRegs; i++) {
+-if (regs.beg[i] < 0) {
+-charOffsets.beg[i] = charOffsets.end[i] = -1;
++for (int i = 0; i < regs.getNumRegs(); i++) {
++if (regs.getBeg(i) < 0) {
++charOff
Bug#1056692: libhamlib4: Add protective diversion for udev rules shared file
Package: libhamlib4 Version: 4.5.5-2 Severity: important Tags: patch User: helm...@debian.org Usertags: dep17p7 X-Debbugs-Cc: helm...@debian.org Dear Maintainer, libhamlib4 contains udev rules which are installed to /lib; these files need to be moved to /usr/lib as part of Debian's usr-merge effort. Because libhamlib4 is Multi-Arch: same, an unfortunate corner-case can occur whereby shared files (such as the udev rules) may be erroneously removed on upgrades (please see DEP17[1] P7: Shared multiarch file loss). I attached a patch which avoids the problem by implementating DEP17 M10 (Protective diversions for shared files) for the affected files. Please consider applying this patch at your earliest convenience. This bug will be upgraded to release critical soon, as it blocks the overall usr-merge effort which is being undertaken for the trixie release. Best regards, Miguel. 1. https://subdivi.de/~helmut/dep17.html diff -Nru hamlib-4.5.5/debian/changelog hamlib-4.5.5/debian/changelog --- hamlib-4.5.5/debian/changelog 2023-06-18 20:00:08.0 +0100 +++ hamlib-4.5.5/debian/changelog 2023-11-24 14:19:21.0 + @@ -1,3 +1,9 @@ +hamlib (4.5.5-3) UNRELEASED; urgency=medium + + * Install libhamlib4.rules into /usr, with protective diversion. + + -- Miguel Landaeta Fri, 24 Nov 2023 14:19:21 + + hamlib (4.5.5-2) unstable; urgency=medium * Remove transitional packages libhamlib2-perl, libhamlib2-tcl, diff -Nru hamlib-4.5.5/debian/libhamlib4.install hamlib-4.5.5/debian/libhamlib4.install --- hamlib-4.5.5/debian/libhamlib4.install 2021-01-01 23:20:20.0 + +++ hamlib-4.5.5/debian/libhamlib4.install 2023-11-24 14:19:21.0 + @@ -1 +1,2 @@ usr/lib/*/libhamlib.so.* +debian/60-libhamlib4.rules usr/lib/udev/rules.d diff -Nru hamlib-4.5.5/debian/libhamlib4.postinst hamlib-4.5.5/debian/libhamlib4.postinst --- hamlib-4.5.5/debian/libhamlib4.postinst 1970-01-01 01:00:00.0 +0100 +++ hamlib-4.5.5/debian/libhamlib4.postinst 2023-11-24 14:19:21.0 + @@ -0,0 +1,23 @@ +#!/bin/sh +# postinst script for lihamlib + +set -e + +dpkg-maintscript-helper rm_conffile /etc/udev/60-libhamlib4.rules -- "$@" + +rm -f /etc/udev/rules.d/60-libhamlib4.rules + +# begin-remove-after: released:forky +# protective diversion of files moved from / to /usr, to avoid file loss. +# Only for upgrades. +if [ "$1" = "configure" ]; then +# At this point, the package will have installed the same file in */usr*. +dpkg-divert --package usr-is-merged --no-rename \ +--divert /lib/udev/rules.d/60-libhamlib4.rules.usr-is-merged \ +--remove /lib/udev/rules.d/60-libhamlib4.rules +fi +# end-remove-after + +#DEBHELPER# + +exit 0 diff -Nru hamlib-4.5.5/debian/libhamlib4.postrm hamlib-4.5.5/debian/libhamlib4.postrm --- hamlib-4.5.5/debian/libhamlib4.postrm 1970-01-01 01:00:00.0 +0100 +++ hamlib-4.5.5/debian/libhamlib4.postrm 2023-11-24 14:19:21.0 + @@ -0,0 +1,21 @@ +#!/bin/sh +# postrm script for libhamlib + +set -e + +dpkg-maintscript-helper rm_conffile /etc/udev/60-libhamlib4.rules -- "$@" + +# begin-remove-after: released:forky +# protective diversion of files moved from / to /usr, to avoid file loss. +# Only for upgrades. +if [ "$1" = "remove" ] && [ "$DPKG_MAINTSCRIPT_PACKAGE_REFCOUNT" = "1" ]; then +# Cleanup in case package is removed before upgrade is finished (postinst ran). +dpkg-divert --package usr-is-merged --no-rename \ +--divert /lib/udev/rules.d/60-libhamlib4.rules.usr-is-merged \ +--remove /lib/udev/rules.d/60-libhamlib4.rules +fi +# end-remove-after + +#DEBHELPER# + +exit 0 diff -Nru hamlib-4.5.5/debian/libhamlib4.preinst hamlib-4.5.5/debian/libhamlib4.preinst --- hamlib-4.5.5/debian/libhamlib4.preinst 1970-01-01 01:00:00.0 +0100 +++ hamlib-4.5.5/debian/libhamlib4.preinst 2023-11-24 14:19:21.0 + @@ -0,0 +1,20 @@ +#!/bin/sh +# preinst script for libhamlib + +set -e + +dpkg-maintscript-helper rm_conffile /etc/udev/60-libhamlib4.rules -- "$@" + +# begin-remove-after: released:forky +# protective diversion of files moved from / to /usr, to avoid file loss. +# Only for upgrades. +if [ "$1" = "upgrade" ]; then +dpkg-divert --package usr-is-merged --no-rename \ +--divert /lib/udev/rules.d/60-libhamlib4.rules.usr-is-merged \ +--add /lib/udev/rules.d/60-libhamlib4.rules +fi +# end-remove-after + +#DEBHELPER# + +exit 0 diff -Nru hamlib-4.5.5/debian/60-libhamlib4.rules hamlib-4.5.5/debian/60-libhamlib4.rules --- hamlib-4.5.5/debian/60-libhamlib4.rules 1970-01-01 01:00:00.0 +0100 +++ hamlib-4.5.5/debian/60-libhamlib4.rules 2021-01-02 00:27:23.0 + @@ -0,0 +1,12 @@ +# +# Enable uaccess for common embedded USB-serial converters so that +# applications which call usb_detac
Bug#1056625: RM: xhtmlrenderer -- ROM; outdated, unused
Package: ftp.debian.org Severity: normal As title says. This package is obsolete. No other package is the archive is depending on this.
Bug#1056623: RM: unsafe-mock -- ROM; unused, outdate
Package: ftp.debian.org Severity: normal As title says. This package was used by JRuby during the transition to JDK >8. There is no use for this anymore.
Bug#1056622: RM: unsafe-fences -- ROM; unused, obsolete
Package: ftp.debian.org Severity: normal As title says. This package was used by JRuby during the transition to JDK >8. There is no use for this anymore.
Bug#1056617: RM: yecht -- ROM; outdated, unused
Package: ftp.debian.org Severity: normal As title says. JRuby stopped depending on yecht years ago. There are no dependencies on this package in the archive.
Bug#1056614: RM: tweepy -- ROM; broken, obsolete, associated service doesn't exist anymore
Package: ftp.debian.org Severity: normal As title says. This package and all Twitter related packages should be removed from the archive. Twitter API access is broken, so there is no point keeping this in the archive.
Bug#1056613: twitterwatch: Please remove this package
Package: twitterwatch Severity: important Hi, I intend to remove tweepy package from the archive since Twitter service doesn't exist anymore and its API access is also gone from quite some time, I believe. Can you remove this package from the archive? I don't think there is any use left for any Twitter related package in Debian at this point. -- System Information: Debian Release: 11.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-26-amd64 (SMP w/1 CPU thread) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages twitterwatch depends on: ii python3 3.9.2-3 pn python3-tweepy twitterwatch recommends no packages. twitterwatch suggests no packages.
Bug#1056612: retweet: Please remove this package
Package: retweet Severity: important Hi, I intend to remove tweepy package from the archive since Twitter service doesn't exist anymore and its API access is also gone from quite some time, I believe. Can you remove this package from the archive? I don't think there is any use left for any Twitter related package in Debian at this point. -- System Information: Debian Release: 11.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-26-amd64 (SMP w/1 CPU thread) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1056611: db2twitter: Please remove this package
Package: db2twitter Severity: important Hi, I intend to remove tweepy package from the archive since Twitter service doesn't exist anymore and its API access is also gone from quite some time, I believe. Can you remove this package from the archive? I don't think there is any use left for any Twitter related package in Debian at this point. -- System Information: Debian Release: 11.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-26-amd64 (SMP w/1 CPU thread) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages db2twitter depends on: ii python3 3.9.2-3 pn python3-pil pn python3-sqlalchemy pn python3-tweepy db2twitter recommends no packages. db2twitter suggests no packages.
Bug#1056610: RM: truffle-dsl-processor -- ROM; unused, outdated
Package: ftp.debian.org Severity: normal It should be removed together with truffle. See https://bugs.debian.org/1056609.
Bug#1056609: RM: truffle -- ROM; unused, outdated
Package: ftp.debian.org Severity: normal This package was never really used for anything, it was also never updated and as result the current version in the archive is really outdated. In its current state, it makes more sense to remove it, until someone really has a real use and can provide an updated version.
Bug#1056607: RM: modulator -- ROM; unused, obsolete
Package: ftp.debian.org Severity: normal As title says. There is no use for this package and should be removed from the archive.
Bug#1010048: fs-uae-launcher: GUI is corrupted.
What a plot twist! :-) Do you think there is any possibility to have fs-uae-launcher back in Debian anytime soon? Configuring FS-UAE by hand is tedious. we really need fs-uae-launcher back in Debian Thank you
Bug#1056339: graphicsmagick: providing graphicsmagick build with alternative quantum-depth
Source: graphicsmagick Version: 1.4+really1.3.40-4 Severity: wishlist X-Debbugs-Cc: carandraug+...@gmail.com Dear Maintainer, A long time ago GraphicsMagick (and ImageMagick) were built with the --quantum-depth option set to 8. Both are now being built with it set to 16. I think that change was quite reasonable and a good default. I'm requesting to have an alternative package built with quantum depth set to 8. This will reduce memory usage by half and make operations faster for 8 bit (per channel) images (the vast majority). The current package names already encode the quantum-depth option used and in the case of ImageMagick, here's even packages built with and without hdr support. Because of this, I feel that a lot of the work is already in place. I'm happy to provide patches if this request meets with positive interest and someone is willing to review the patches. Best wishes David -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1010048: fs-uae-launcher: GUI is corrupted.
Hello I revisited https://github.com/FrodeSolheim/fs-uae-launcher/issues/143 and I noticed user glaubitz is open to make the changes needed to have this package back in Debian. Dear maintainer, please explain to GitHub / glaubitz what is needed to have fs-uae-launcher back in Debian. Thank you
Bug#966218: firmware: failed to load iwl-debug-yoyo.bin (-2)
found 966218 linux/6.5.6-1 found 966218 firmware-iwlwifi/20230515-3 Bug still running around ;) regards
Bug#1053886: apt autoremove removes old kernel (ignoring default configuration)
Hi there,
I think this could be related to the fact that current kernel packages
naming convention don't match the regular expression in
/etc/apt/apt.conf.d/01autoremove.
There are some '.' that the regular expression doesn't take care of.
NeverAutoRemove
{
"^firmware-linux.*";
"^linux-firmware$";
"^linux-image-[a-z0-9]*$";
"^linux-image-[a-z0-9]*-[a-z0-9]*$";
};
Regards
Bug#1053886: apt autoremove removes old kernel (ignoring default configuration)
Package: apt Version: 2.7.3 Severity: normal X-Debbugs-Cc: mianro...@gmail.com Beside the fact that kernel packages should not removed by default (according to /etc/apt/apt.conf.d/01autoremove), older kernel packages are removed after executing 'apt autoremove'. Regards -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-.*"; APT::VersionedKernelPackages:: "kfreebsd-.*"; APT::VersionedKernelPackages:: "gnumach-.*"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "tasks"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Update ""; APT::Update::Post-Invoke-Success ""; APT::Update::Post-Invoke-Success:: "/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null"; APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/swcatalog -a -e /usr/bin/appstreamcli; then appstreamcli refresh --source=os > /dev/null || true; fi"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::zstd ""; APT::Compressor::zstd::Name "zstd"; APT::Compressor::zstd::Extension ".zst"; APT::Compressor::zstd::Binary "zstd"; APT::Compressor::zstd::Cost "60"; APT::Compressor::zstd::CompressArg ""; APT::Compressor::zstd::CompressArg:: "-19"; APT::Compressor::zstd::UncompressArg ""; APT::Compressor::zstd::UncompressArg:: "-d"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "false"; APT::Compressor::lz4::Cost "50"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-6n"; APT::Compressor::gzip::UncompressArg ""; APT::Compressor::gzip::UncompressArg:: "-d"; APT::Compressor::xz ""; APT::Compressor::xz::Name "xz"; APT::Compressor::xz::Extension ".xz"; APT::Compressor::xz::Binary "xz"; APT::Compressor::xz::Cost "200"; APT::Compressor::xz::CompressArg ""; APT::Compressor::xz::CompressArg:: "-6"; APT::Compressor::xz::UncompressArg ""; APT::Compressor::xz::UncompressArg:: "-d"; APT::Compressor::bzip2 ""; APT::Compressor::bzip2::Name "bzip2"; APT::Compressor::bzip2::Extension ".bz2"; APT::Compressor::bzip2::Binary "bzip2"; APT::Compressor::bzip2::Cost "300"; APT::Compressor::bzip2::CompressArg ""; APT::Compressor::bzip2::CompressArg:: "-6"; APT::Compressor::bzip2::UncompressArg ""; APT::Compressor::bzip2::UncompressArg:: "-d"; APT::Compressor::lzma ""; APT::Compressor::lzma::Name "lzma"; APT::Compressor::lzma::Extension ".lzma"; APT::Compressor::lzma::Binary "xz"; APT::Compressor::lzma::Cost "400"; APT::Compressor::lzma::CompressArg ""; APT::Compressor::lzma::CompressArg:: "--format=lzma"; APT::Compressor::lzma::CompressArg:: "-6"; APT::Compressor::lzma::UncompressArg ""; APT::Compressor::lzma::UncompressArg:: "--format=lzma"; APT::Compressor::lzma::UncompressArg:: "-d"; Dir "/"; Dir::State "var/lib/apt"; Dir::State::lists "lists/"; Dir::State::cdroms "cdroms.list"; Dir::State::extended_states "extended_states"; Dir::State::status "/var/lib/dpkg/status"; Dir::Cache "var/cache/apt"; Dir::Cache::archives "archives/"; Dir::Cache::srcpkgcache "srcpkgcache.bin"; Dir::Cache::pkgcache "pkgcache.bin"; Dir::Etc "etc/apt"; Dir::Etc::sourcelist "sources.list"; Dir::Etc::sourceparts "sources.list.d"; Dir::Etc::main "apt.conf"; Dir::Etc::netrc "auth.conf"; Dir::Etc::netrcparts "auth.conf.d"; Dir::Etc::parts "apt.conf.d"; Dir::Etc::preferences "preferences"; Dir::Etc::preferencesparts "preferences.d"; Dir::Etc::trusted "trusted.gpg"; Dir::Etc::trustedparts "trusted.gpg.d"; Dir::Etc::apt-file-main "apt-file.conf"; Dir::Bin ""; Dir::Bin::methods "/usr/lib/apt/methods"; Dir::Bin::solvers ""; Dir::Bin::solvers:: "/usr/lib/apt/solvers"; Dir::Bin::planners ""; Dir::Bin::planner
Bug#1051873: libcpucycles: Library was not compiled with architecture-specific options in some architectures like riscv64 or arm64
tags 1051873 + pending thanks https://salsa.debian.org/debian/libcpucycles/-/commit/6c83d7f861af9ed0db449407edfe792890e6bdc2 -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. "Faith means not wanting to know what is true." -- Nietzsche
Bug#1052012: plasma-workspace: sddm presents a white screen with no background nor buttons
Hi, When I described it as "horrible", I wanted to mean what you described (very small size and each character is 1 pixel or less, ;)). In my case, I have no background either and the button to select between X11 and Wayland can't be seen. # ls -l /usr/share/sddm/themes/debian-breeze(4:5.27.7-2) total 32 -rw-r--r-- 1 root root 23515 Aug 7 16:42 Main.qml -rw-r--r-- 1 root root 543 Aug 7 16:42 metadata.desktop -rw-r--r-- 1 root root 209 Aug 7 16:42 theme.conf # ls -l /usr/share/sddm/themes/debian-breeze(4:5.27.8-1) total 24 -rw-r--r-- 1 root root 23515 Sep 13 22:24 Main.qml At least, metadata.desktop and theme.conf have disappeared with the new version of the package. When you restored those files from the previous packages, sddm seems to work fine (I haven't done any additional testing beside that the screen seems to look as it was). Regards On 16/9/23 12:55, Alexis Murzeau wrote: Hi, On Sat, 16 Sep 2023 00:55:12 +0200 Miguel Angel Rojas wrote: Hi there, Downgrading the following packages: - sddm-themes-breeze - sddm-theme-debian-breeze to version 4:5.27.7-2 makes sddm fully usable again with no issues. It seems some changes have been made on version 4:5.27.8-1 that have broken sddm. I hope this helps. Regards I have issues too with sddm-theme-debian-breeze 5.27.8-1, but the symptom is different. I get a correct screen, but the password field has a very small font size and each character is 1 pixel. Using diffoscope, it appears sddm-theme-debian-breeze 5.27.8-1 doesn't have the theme.conf file. Adding back theme.conf from version 5.27.7-2 with 5.27.8-1 installed fix the issue for me. Note: metadata.desktop was also removed in 5.27.8-1, maybe it shouldn't too. @Miguel, can you try to do the same to check if theme.conf is also the cause of your issues ? That is, adding `/usr/share/sddm/themes/debian-breeze/theme.conf` with this content: ``` [General] showlogo=hidden logo=/usr/share/sddm/themes/breeze/default-logo.svg type=image color=#1d99f3 fontSize=10 background=/usr/share/desktop-base/active-theme/login/background.svg needsFullUserModel=false ``` -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (950, 'unstable'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) 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) Versions of packages sddm-theme-debian-breeze depends on: ii plasma-framework 5.107.0-1 ii plasma-workspace 4:5.27.8-1 ii sddm-theme-breeze 4:5.27.8-1 Versions of packages sddm-theme-debian-breeze recommends: ii desktop-base 12.0.6+nmu1 ii sddm 0.20.0-1 sddm-theme-debian-breeze suggests no packages. -- no debconf information
Bug#1052012: plasma-workspace: sddm presents a white screen with no background nor buttons
Hi there, Downgrading the following packages: - sddm-themes-breeze - sddm-theme-debian-breeze to version 4:5.27.7-2 makes sddm fully usable again with no issues. It seems some changes have been made on version 4:5.27.8-1 that have broken sddm. I hope this helps. Regards
Bug#1052012: plasma-workspace: sddm presents a white screen with no background nor buttons
Package: plasma-workspace Version: 4:5.27.8-1 Severity: important X-Debbugs-Cc: mianro...@gmail.com After upgrading from 4:5.27-7-1, sddm because unusuable. Background is ignored (white), there are no button on the screen and the only thing you can see on the screen is the icon showing the user and password field below it (with very tiny asterisks) in a horrible format. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-1-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages plasma-workspace depends on: ii dbus-user-session [default-dbus-session-bus] 1.14.10-1 ii drkonqi 5.27.8-1 ii frameworkintegration 5.107.0-1 ii gdb-minimal [gdb]13.2-1 ii init-system-helpers 1.65.2 ii iso-codes4.15.0-1 ii kactivitymanagerd5.27.8-1 ii kded55.107.0-1 ii kinit5.107.0-1 ii kio 5.107.0-1 ii kpackagetool55.107.0-1 ii kwin-common 4:5.27.8-1 ii libappstreamqt2 0.16.3-1 ii libc62.37-9 ii libcolorcorrect5 4:5.27.8-1 ii libcrypt11:4.4.36-2 ii libfontconfig1 2.14.2-6 ii libfreetype6 2.13.2+dfsg-1 ii libgcc-s113.2.0-4 ii libgps30 3.25-2 ii libice6 2:1.0.10-1 ii libicu72 72.1-3 ii libkf5activities55.107.0-1 ii libkf5activitiesstats1 5.107.0-1 ii libkf5archive5 5.107.0-1 ii libkf5authcore5 5.107.0-1 ii libkf5baloo5 5.107.0-1 ii libkf5bookmarks5 5.107.0-1 ii libkf5calendarevents55.107.0-1 ii libkf5completion55.107.0-1 ii libkf5config-bin 5.107.0-1 ii libkf5configcore55.107.0-1 ii libkf5configgui5 5.107.0-1 ii libkf5configwidgets5 5.107.0-2 ii libkf5coreaddons55.107.0-1 ii libkf5crash5 5.107.0-1 ii libkf5dbusaddons55.107.0-1 ii libkf5declarative5 5.107.0-1 ii libkf5globalaccel-bin5.107.0-2 ii libkf5globalaccel5 5.107.0-2 ii libkf5guiaddons5 5.107.0-1 ii libkf5holidays5 1:5.107.0-1 ii libkf5i18n5 5.107.0-1+b1 ii libkf5iconthemes55.107.0-1+b1 ii libkf5idletime5 5.107.0-1 ii libkf5jobwidgets55.107.0-1 ii libkf5kcmutils5 5.107.0-2 ii libkf5kexiv2-15.0.0 23.04.2-2 ii libkf5kiocore5 5.107.0-1 ii libkf5kiofilewidgets55.107.0-1 ii libkf5kiogui55.107.0-1 ii libkf5kiowidgets55.107.0-1 ii libkf5networkmanagerqt6 5.107.0-1 ii libkf5newstuff5 5.107.0-1 ii libkf5newstuffcore5 5.107.0-1 ii libkf5newstuffwidgets5 5.107.0-1 ii libkf5notifications5 5.107.0-1 ii libkf5notifyconfig5 5.107.0-1 ii libkf5package5 5.107.0-1 ii libkf5parts5 5.107.0-1 ii libkf5people55.107.0-1 ii libkf5peoplewidgets
Bug#1051873: libcpucycles: Library was not compiled with architecture-specific options in some architectures like riscv64 or arm64
Source: libcpucycles Version: 0~20230115-1 Severity: normal After uploading 0~20230115-1 I inspected buildd logs and I noticed that on several architectures like riscv64, arm64, ppc64el and a few others, the package build failed to detect and use architecture-specific timer features and ended using the default common OS-level mechanisms. More details at: https://buildd.debian.org/status/package.php?p=libcpucycles&suite=sid riscv64 example: [...] riscv32-rdcycle.c:15:2: error: #error this code is only for riscv32 platforms 15 | #error this code is only for riscv32 platforms | ^ compilation terminated. skipping option that did not compile [...] See more examples with full logs below: https://buildd.debian.org/status/fetch.php?pkg=libcpucycles&arch=arm64&ver=0%7E20230115-1&stamp=1694543693&raw=0 https://buildd.debian.org/status/fetch.php?pkg=libcpucycles&arch=ppc64el&ver=0%7E20230115-1&stamp=1694543637&raw=0 https://buildd.debian.org/status/fetch.php?pkg=libcpucycles&arch=riscv64&ver=0%7E20230115-1&stamp=1694545286&raw=0 -- System Information: Debian Release: 11.7 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-24-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. "Faith means not wanting to know what is true." -- Nietzsche
Bug#1032341: [INTL:ro] Romanian debconf templates translation of localepurge
tags 1032341 + fixed peding
Bug#1051301: Package wavemon is outdated
Package: wavemon Version: 0.9.1-1+b1 Severity: normal Please, update the package wavemon. Current version in Debian unstable is 0.9.1-1+b1 but the last version published is 0.9.4 A lot of improvements have been made, for example, splitting the TX and RX lines (which solved bug 996671) or ipv6 support Please upgrade it Thanks in advance
Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot
Just after sending my previous message I noticed the following versions were available after an apt upgrade: grub2-common 2.12~rc1-9 grub-common 2.12~rc1-9 grub-efi-amd64 2.12~rc1-9 grub-efi-amd64-bin 2.12~rc1-9 grub-efi-amd64-signed 2.12~rc1-7 so I bit the bullet and made an upgrade. It works. The computer boots normally. The only thing I noticed is the grub screen saying version rc-1.7... Shouldn't it be version rc-1.9? Anyway, it works. Thank you!
Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot
Hello Just for your information. I managed to get all grub packages grub2-common grub-common grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed updated to 2.12~rc1-7 and the system DOES NOT BOOT. I downgraded all those grub packages to 2.06-3~deb11u5 (the one found in stable) and it boots without problems. So, I'm concerned if the 2.12~rc1-9 version will boot on my machine.
Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot
M. Zhou wrote: > But after that I noticed that the most important > package grub-efi-amd64-signed:amd64 (1+2.06+13, > 1+2.12~rc1+7) was not upgraded along with the other > grub packages. You are right. I revised apt log and grub-efi-amd64-signed was NOT updated, in fact, the version I have installed now is 1+2.06+13, but all other grub packages have 2.06-3~deb11u5. Now, if I run apt update, and apt list --upgradable it shows: grub-common/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06-3~deb11u5] grub-efi-amd64-bin/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06-3~deb11u5] grub-efi-amd64-signed/unstable 1+2.12~rc1+7 amd64 [upgradable from: 1+2.06+13] grub-efi-amd64/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06-3~deb11u5] grub2-common/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06-3~deb11u5] All of them with version 2.12~rc1-7 Is it safe to upgrade now? I'll wait a bit until I hear from the package maintainers.
Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot
Package: grub2 Version: 2.12~rc1-7 Severity: critical This morning I noticed an apt upgrade in Debian unstable/Sid upgraded grub-common, grub2-common, grub-efi-amd64 and grub-efi-amd64-bin. The upgrade went normally and no errors were shown. Then I turned the computer off and after a few hours I tried to turn it on, but it didn't boot, it tried to boot but finally showed the bios screen. After booting with a live USB and chroot into the hard drive, I downgraded those four packages to version 2.06-3~deb11u5, and after run install-grub, the computer booted normally. Anyone can confirm problems with version 2.12~rc1-7 and UEFI machines? Thanks in advance.
Bug#1019494: localepurge: uses egrep and fgrep: fgrep/egrep: warning: egrep is obsolescent; using grep -F/-E
tags 1019494 + fixed pending
Bug#1050940: linux: Enable Correctable Errors Collector RAS_CEC feature
Source: linux Version: 6.5~rc7-1~exp1 Severity: wishlist Tags: patch X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, jair.gonza...@linux.intel.com Dear Maintainer, Please enable the Reliability, Availability and Serviceability (RAS) Correctable Errors Collector (RAS_CEC) feature on arch amd64/x86_64, on Debian Trixie. RAS_CEC introduce a simple data structure for collecting correctable errors along with accessors. This is a small cache which collects correctable memory errors per 4K page PFN and counts their repeated occurrence. Once the counter for a PFN overflows, we try to soft-offline that page as we take it to mean that it has reached a relatively high error count and would probably be best if we don't use it anymore. The error decoding is done with the decoding chain now and mce_first_notifier() gets to see the error first and the CEC decides whether to log it and then the rest of the chain doesn't hear about it - basically the main reason for the CE collector - or to continue running the notifiers. When the CEC hits the action threshold, it will try to soft-offine the page containing the ECC and then the whole decoding chain gets to see the error. To disable the Correctable Errors Collector, a kernel parameter is used: > ras=cec_disable A MR was created with this proposal at: https://salsa.debian.org/kernel-team/linux/-/merge_requests/827 Thanks, Miguel Bernal Marin
Bug#1027976: ITP: libcpucycles -- Microlibrary for counting CPU cycles
https://ftp-master.debian.org/new/libcpucycles_0~20230115-1.html
Bug#1050353: linux: Enable System Trace Modules and Intel_TH_STH
Source: linux Version: 6.5~rc6-1~exp1 Severity: wishlist Tags: patch X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, jair.gonza...@linux.intel.com Dear Maintainer, Please enable the System Trace Module (STM) and the Intel Trace Hub Software Trace Hub on arch amd64/x86_64, on Debian Trixie. CONFIG_STM=m CONFIG_STM_PROTO_BASIC=m CONFIG_STM_PROTO_SYS_T=m CONFIG_STM_DUMMY=m CONFIG_STM_SOURCE_CONSOLE=m CONFIG_STM_SOURCE_HEARTBEAT=m CONFIG_STM_SOURCE_FTRACE=m CONFIG_INTEL_TH_STH=m System Trace Module (STM) is a kind of trace source device [1], which can not only collect trace data from software sources, but also monitor hardware events. Any software program no matter where it is in kernel space or user space can write STM device with message string (i.e. trace data), like using print functions. Each software or hardware trace source is assigned a unique pair of master and channel, so that a decoder can know which source the trace data come from by this. As a kind of resource, the number of masters and channels are limited, for example *Intel STH* has up to 65,536 masters and up to 256 channels per master. Unlike some traditional tracing approach which would lose all traces once system crashed since the traces are stored in system memory, tracing with STM can survive this kind of case because all traces collected via STM would end up in sink device which can be still alive even the system is dead so long as the hardware design allows it.There’s another benefit of using STM to collect software traces or monitor hardware events. Since everything is logged to the same STM with timestamps, it is possible to correlate events happening in the entire system rather than being confined to the logging facility of a single entity. A MR was created with this proposal at: https://salsa.debian.org/kernel-team/linux/-/merge_requests/815 [1] https://www.linaro.org/blog/stm-and-its-usage/ Thanks, Miguel Bernal Marin
Bug#1050342: linux: Enable Intel Trace Hub ACPI controller
Source: linux Version: 6.5~rc7-1~exp1 Severity: wishlist Tags: patch X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, jair.gonza...@linux.intel.com Dear Maintainer, Please enable the CONFIG_INTEL_TH_ACPI on arch amd64/x86_64 in Debian Trixie. The Trace Hub devices now can be enumerated as ACPI devices, which translates into "Host Debugger mode". There are two IDs: one for PCH Trace Hub, and one for the uncore Trace Hub. These are expected to stay the same across all platforms. CONFIG_INTEL_TH_ACPI: Intel(R) Trace Hub may exist as an ACPI device. This option enables support glue layer for ACPI-based Intel TH. This typically implies 'host debugger' mode, that is, the trace configuration and capture is handled by an external debug host and corresponding controls will not be available on the target. A MR was created with this proposal at: https://salsa.debian.org/kernel-team/linux/-/merge_requests/814 Thanks, Miguel Bernal Marin
Bug#1027976: Subject: Re: ITP: libcpucycles -- Microlibrary for counting CPU cycles
libcpucycles is ready to be uploaded. I just pushed a new git repo for this package. https://salsa.debian.org/debian/libcpucycles I'll have to wait a few days to be able to upload the package, I just updated my PGP key to add new subkeys, because the ones in the debian keyring expired as I have been inactive for quite some time. I attempted an upload 2 days ago and it didn't go through, so the archive tooling must be failing to validate my upload signature. Anyway, I'll wait for a few days or nag a DD to do the upload on my behalf.
Bug#1049901: linux: Enable Memory Hotplug default online
Source: linux Version: 6.5~rc6-1~exp1 Severity: wishlist Tags: patch X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, jair.gonza...@linux.intel.com Dear Maintainer, Please enable the CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE on arch amd64/x86_64, on Debian Trixie. Currently all newly hot-plugged memory remains in 'offline' state and manual actions are required to bring it online. To make things work automagically CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE option was introduced. This option sets the default policy setting for memory hotplug onlining policy (/sys/devices/system/memory/auto_online_blocks) which determines what happens to newly added memory regions. Policy setting can always be changed at runtime. A MR was created with this proposal at: https://salsa.debian.org/kernel-team/linux/-/merge_requests/810 Thanks, Miguel Bernal Marin
Bug#1027976: ITP: libcpucycles -- Microlibrary for counting CPU cycles
owner 1027976 ! thanks Nick reached out via private email and we agreed to share maintenance for this package. I'll prepare an upload in the next few days. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. "Faith means not wanting to know what is true." -- Nietzsche
