Bug#1040516: ITP: rocdbgapi -- AMD GPU debugger support library
Package: wnpp Severity: wishlist Owner: Cordell Bloor X-Debbugs-Cc: debian-devel@lists.debian.org, c...@slerp.xyz, debian...@lists.debian.org * Package name: rocdbgapi Version : 5.6.0 * URL : https://github.com/ROCm-Developer-Tools/ROCdbgapi * License : Expat Programming Lang: C, C++ Description : AMD GPU debugger support library The ROCdbpgapi library provides debugging routines to inspect and control programs running on AMD GPUs. This library is used by debuggers to receive notifications of events, query the GPU state, and step through execution. However, operations such as symbolic mappings, code object decoding and stack unwinding are outside the scope of this library. The rocdbgapi is a dependency of gdb and, together with the kernel debug interface, allows users to debug GPU code in a similar manner to CPU code. This is therefore an important tool for developing and maintaining AMD GPU software. This package is part of AMD's ROCm stack and will be maintained under the Debian AI team umbrella.
Re: Replaces without Breaks or Conflicts harmful?
Hi Thorsten,
On Thu, Jul 06, 2023 at 05:26:43PM +, Thorsten Glaser wrote:
> Helmut Grohne dixit:
>
> > openjdk-8 (U)
>
> Should be convered by the Depends lines in the respective
> binary packages, e.g:
>
> Depends: openjdk-8-jre (>= ${source:Version}),
> openjdk-8-jdk (>= ${binary:Version}),
> ${misc:Depends}
> Replaces: openjdk-8-jdk (<< 8u20~b26-1~)
Yes, this is the kind of fpos I was mentioning as expected.
> > rng-tools-debian
>
> Also false positive:
>
> Replaces: intel-rng-tools, rng-tools
> Breaks: rng-tools (>= 5migratf), rng-tools (<< 5migrate)
> Conflicts: intel-rng-tools
This is *not* a false positive, but a real issue. It replaces any
rng-tools, but breaks only a subset. This would have to be fixed to
either drop the version constraint from Breaks (probably wrong) or add
it to Replaces. Can you handle that?
Helmut
Bug#1040380: ITP: spike -- Spike RISC-V ISA Simulator
On Thurs, Jul 06, 2023 at 07:33, Jessica Clarke wrote: > > I disagree. Spike exists to be an easy simulator for people extending > > the RISC-V ISA to hack on, and to give software developers something to > > start testing their code on as extensions are in-flight (both of which > > are also served by the Sail model, which is technically the official > > golden model, even if many still prefer to use Spike). However, if > > you're not using the latest version, any draft extension specifications > > implemented by it have likely moved on in the meantime to newer > > incompatible drafts, rendering them obsolete, and any frozen (or even > > ratified) specifications are likely to be implemented by QEMU. Plus QEMU > > will be much, much faster thanks to its JIT approach, and has a rich set > > of devices available, unlike Spike which has just a UART last I checked, > > not even any form of storage, meaning it can only run basic binaries or > > boot kernels with an in-memory filesystem. > > > > I therefore do not see any point in shipping some old version of Spike > in Debian. What is your use case for having it? I just want to provide a way to get pre-built Spike for people who may need that. As you say, it's useless for people who need hacking Spike. Also for people who just want to run RISC-V binary. I will use a unofficial way like PPA for this. So you can close this bug. Thanks for your explanation. Sorry for bothering.
Bug#1040380: ITP: spike -- Spike RISC-V ISA Simulator
On Wed, Jul 05, 2023 at 05:17:29PM +0800, Jax Young wrote: > Package: wnpp > Severity: wishlist > Owner: Jax Young > X-Debbugs-Cc: debian-devel@lists.debian.org, jaxvany...@gmail.com > > * Package name: spike > Version : 1.1.0 > Upstream Author : Andrew Waterman > * URL : https://github.com/riscv-software-src/riscv-isa-sim > * License : Custom license > Programming Lang: C, C++ > Description : Spike RISC-V ISA Simulator > > Spike has been published for several years, with the development of > RISC-V, I think it should be included in Debian packages. > - Spike is developed by the official RISC-V organization. It is a good >reference for RISC-V ISA Simulator, and it has 1.8K stars on GitHub. > - QEMU also supports RISC-V ISA simulation, but it acts more for >virtual environment. Spike focus on RISC-V, and it is more for >developing. > - I am new to package maintenance, so I need a sponsor. Spike's API is >fairly stable, the last version was released on Dec 17, 2021. But the >development is still ongoing. So the maintenance should be easy for a >noob like me. > I disagree. Spike exists to be an easy simulator for people extending the RISC-V ISA to hack on, and to give software developers something to start testing their code on as extensions are in-flight (both of which are also served by the Sail model, which is technically the official golden model, even if many still prefer to use Spike). However, if you're not using the latest version, any draft extension specifications implemented by it have likely moved on in the meantime to newer incompatible drafts, rendering them obsolete, and any frozen (or even ratified) specifications are likely to be implemented by QEMU. Plus QEMU will be much, much faster thanks to its JIT approach, and has a rich set of devices available, unlike Spike which has just a UART last I checked, not even any form of storage, meaning it can only run basic binaries or boot kernels with an in-memory filesystem. I therefore do not see any point in shipping some old version of Spike in Debian. What is your use case for having it? Jess
Work-needing packages report for Jul 7, 2023
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1183 (new: 1) Total number of packages offered up for adoption: 152 (new: 1) Total number of packages requested help for: 58 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: markdown-toc-el (#1040073), orphaned 4 days ago Description: Emacs TOC (table of contents) generator for markdown files Installations reported by Popcon: 91 Bug Report URL: https://bugs.debian.org/1040073 1182 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: anki (#1040433), offered yesterday Description: flashcard learning program, has migrated to Rust/Python/JavaScript combination Installations reported by Popcon: 738 Bug Report URL: https://bugs.debian.org/1040433 151 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#910917), requested 1727 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc bfh-container-server courier-webadmin cvsweb debbugs-web debian-edu-router-deployserver (126 more omitted) Installations reported by Popcon: 103232 Bug Report URL: https://bugs.debian.org/910917 apparmor (#1006872), requested 486 days ago Description: user-space parser utility for AppArmor Reverse Depends: apparmor-notify apparmor-profiles apparmor-profiles-extra apparmor-utils content-hub-testability dbus-broker dbus-daemon dbus-tests debian-cloud-images-packages dovecot-core (24 more omitted) Installations reported by Popcon: 204572 Bug Report URL: https://bugs.debian.org/1006872 autopkgtest (#846328), requested 2409 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker sbuild-qemu Installations reported by Popcon: 1157 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 4302 days ago Description: An e-mail client for GNOME Reverse Depends: balsa Installations reported by Popcon: 603 Bug Report URL: https://bugs.debian.org/642906 cargo (#860116), requested 2277 days ago Description: Rust package manager Reverse Depends: dh-cargo python3-setuptools-rust rust-all Installations reported by Popcon: 2925 Bug Report URL: https://bugs.debian.org/860116 chromium (#1016047), requested 345 days ago Description: web browser Reverse Depends: chromium chromium-driver chromium-l10n chromium-shell node-puppeteer qunit-selenium x2gothinclient-minidesktop Installations reported by Popcon: 24773 Bug Report URL: https://bugs.debian.org/1016047 courier (#978755), requested 917 days ago Description: Courier mail server Reverse Depends: courier-faxmail courier-filter-perl courier-imap courier-ldap courier-mlm courier-mta courier-pcp courier-pop courier-webadmin couriergrey (3 more omitted) Installations reported by Popcon: 744 Bug Report URL: https://bugs.debian.org/978755 cron (#984736), requested 851 days ago Description: new maintainer need Reverse Depends: apticron autolog backintime-common bcron btrfsmaintenance buildd checksecurity clamtk cricket cron (25 more omitted) Installations reported by Popcon: 219658 Bug Report URL: https://bugs.debian.org/984736 cyrus-imapd (#921717), requested 1609 days ago Description: Cyrus mail system - IMAP support Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication Installations reported by Popcon: 401 Bug Report URL: https://bugs.debian.org/921717 debtags (#962579), requested 1121 days ago Description: Debian Package Tags support tools Reverse Depends: packagesearch Installations reported by Popcon: 1354 Bug Report URL: https://bugs.debian.org/962579 dee (#831388), requested 2547 days ago Description: model to synchronize multiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 gir1.2-unity-7.0 libdee-dev libunity-dev libunity-protocol-private0 libunity-tools libunity9 zeitgeist-core Installations reported by Popcon: 52479 Bug R
Re: 64-bit time_t transition for 32-bit archs: a proposal
Simon McVittie dixit:
>opt-in to (2.) is available via -D_FILE_OFFSET_BITS=64 for the subset
>of libraries that can support it without breaking ABI, and similarly
Right, but e.g. refuses to work under it.
>That wasn't actually the reason for my concern. As far as I'm aware, the
>glibc dynamic linker doesn't guarantee not to look at libraries from other
>architectures' multiarch library directories, or even know which directory
>is for which architecture. There's only one /etc/ld.so.conf(.d), which
Oh okay.
>I agree that this is less like amd64 vs x32 vs i386, and more like arm vs
>armel vs armhf (all 32-bit ARM and all mutually incompatible). I believe
Indeed.
>32-bit mips also has more than one ABI ("o32" and "n32") which might be
n32 is 64-bit, but from a short research, let’s not look at how
MIPS did this because it’s apparently convoluted and “historical
reasons” enough to make people despair (and apparently one can
compile an o32 file for MIPS64…).
But, yes, e_flags seems to be the way to go.
>(Of course, orthogonally, it would be nice if we could finally stop
>shipping shared libraries in the non-multiarch directories before trixie.)
Wouldn’t help here, considering that the old i386 has to be there
for legacy reasons so people might manually throw in, oh idk, an
OpenSSL 0.x and libstdc++5 even. But, yeah, M-A is nice now that
it works.
bye,
//mirabilos
--
exceptions: a truly awful implementation of quite a nice idea.
just about the worst way you could do something like that, afaic.
it's like anti-design. that too… may I quote you on that?
sure, tho i doubt anyone will listen ;)
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Thu, 06 Jul 2023 at 16:33:22 +, Thorsten Glaser wrote:
> Simon McVittie dixit:
> >architecture would need to have a new dpkg architecture name, multiarch
> >tuple, GNU tuple (i?86-linux-gnut64?) and canonical ELF linker path.
>
> Bit of bikeshedding on the name, of course. timet64 (or a shortened
> version) is a possibility but I’d also want off_t to be 64 bit in it
> like the BSDs have been doing for decades, for example.
That's easy, because glibc doesn't support 64-bit time_t without also
having 64-bit off_t (to avoid combinatorial explosion), so there are
three possible 32-bit ABIs instead of the four that you might expect:
1. 32-bit everything
2. large file support (64-bit off_t and inode numbers) but 32-bit time_t
3. large file support as above, and also 64-bit time_t
The current (backwards-compatible) i386 port is (1.) by default. An
opt-in to (2.) is available via -D_FILE_OFFSET_BITS=64 for the subset
of libraries that can support it without breaking ABI, and similarly
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 is an opt-in to (3.).
Specifying -D_TIME_BITS=64 on its own is an error, to avoid creating
a fourth mutually incompatible ABI.
Newer 32-bit ports like x32 started as (2.) or maybe even (3.) by
default.
Your proposed port would be (3.) from the beginning.
On the backwards-compatible i386 port, a lot of libraries already opt-in
to (2.), because it's relatively rare to have off_t or struct stat in
the ABI, therefore a lot of libraries can safely do this without breaking
their own ABI (for example libdbus, GLib and SDL all do this).
*Some* libraries can safely opt-in to (3.) as well (for example I proposed
a merge request for libdbus, and it looks as though SDL is also going
to do this, at least in version 3), but time_t in the ABI seems to be a
lot more common than struct stat in the ABI, so not all libraries can
safely do this (for example, GLib can't do this because unfortunately
it has some time_t in its ABI), hence the need to consider doing this
as a more general transition.
> I would like for things to be coïnstallable, of course. But why would
> the dynamic linker attempt to load the respective foreign libraries…
> oh right, not all are in the M-A path yet
That wasn't actually the reason for my concern. As far as I'm aware, the
glibc dynamic linker doesn't guarantee not to look at libraries from other
architectures' multiarch library directories, or even know which directory
is for which architecture. There's only one /etc/ld.so.conf(.d), which
all architectures share, and similarly there's only one ld.so.cache, so
the dynamic linker needs to be able to distinguish between co-installable
architectures and avoid loading "wrong" libraries.
You can see this by the error message you get if you try to load a
dlopen'd plugin for the wrong architecture, for example running an i386
Vulkan app if you only have amd64 Vulkan drivers: it's often something
like "wrong ELF type", as opposed to the "not found" that you might
expect.
I agree that this is less like amd64 vs x32 vs i386, and more like arm vs
armel vs armhf (all 32-bit ARM and all mutually incompatible). I believe
32-bit mips also has more than one ABI ("o32" and "n32") which might be
useful prior art for what you can and can't do in the ELF header.
(Of course, orthogonally, it would be nice if we could finally stop
shipping shared libraries in the non-multiarch directories before trixie.)
smcv
Re: 64-bit time_t transition for 32-bit archs: a proposal
> "Helmut" == Helmut Grohne writes: Helmut> I concur. Given Simon's analysis and the replies even when Helmut> combined with earlier messages, I now see significantly more Helmut> voices for the opinion: Helmut> i386 primarily exists for running legacy binaries and Helmut> binary compatibility with legacy executables is more Helmut> important than correct representation of time beyond 2038. Helmut> I'm inclined to call this consensus now and therefore ask Helmut> those that do not agree with it to reply here - even if your Helmut> reply is only stating that you disagree. As such, I think we Helmut> can skip the GR part unless we get (5?) disagreeing replies Helmut> here. I agree this represents consensus of the thread here. signature.asc Description: PGP signature
Re: Second take at DEP17 - consensus call on /usr-merge matters
> "Russ" == Russ Allbery writes: Russ> Helmut Grohne writes: Russ> What Sam is trying to Russ> say, I think, is that a different phrasing offers a way to Russ> avoid that discussion and agree to disagree on the best Russ> architecture in the abstract by pointing out an additional Russ> constraint: how long we're willing to wait and how Russ> uncomfortable we're willing to make things for ourselves to Russ> try to force the dpkg changes to appear. Exactly. For example, in response to my rephrasing Helmut asserted (correctly of course) that there is no patch ready today. If we go down that road, we can repeat the discussion about whether the politics are a significant factor in why we have no patches today. I appreciate Helmut has a strong position on that issue, but some of us disagree with Helmut strongly on that point. BUT I don't think it matters. If we have a consensus we're unwilling to wait for a patch, it doesn't matter whether that's because: 1) Some of us think the patch would be a bad idea 2) Some of us think the patch will not happen because of politics 3) Some of us think the patch won't happen because no one cares enough to write it 4) Some of us think the patch will eventually get done 5) Some of us think the problem is too constrained and if we really wanted to make progress we could incrementally move toward it. Helmut effectively asked us to agree with 1. And I don't think there is a consensus on this. I have reviewed the DEP 17 draft at https://subdivi.de/~helmut/dep17.html Helmut asked for consensus on the problems and mitigations or at least I think he did. I think we don't need that. I think we need consensus on decisions and confirmation that everyone feels heard. WRT the problems, I confirm that the list of problems does (in my reading) accurately describe the problems people have brought up. I don't think we have (or should try to get) a consensus on which problems need to be fixed except in so far as that affects our consensus on a proposal. I will admit that even though I've followed the discussion fairly closely, I don't have a good feeling about the mitigations. I think that once a reasonable set of the mitigations have been applied, we'll be in a reasonably good place. My concern is about upgrades and about unstable. I would like to see a set of instructions that I could follow for moving files in my packages in the data.tar to their canonical locations. I'd like instructions that clearly allowed me to reason about upgrades, and about how my packages interact with other packages during the transition. Because several of the problems look kind of serious, and my reading of the mitigations is that hey, by the time we get done, it'll all be okay. Implicit is the idea that because of the moratorium these problems are rare. Except during the transition, there will be no moratorium, so perhaps these problems will not be rare. There are two many mitigations, and the interactions matter for me to think about safety. Proposed way to address this concern: A) Develop a proposal assuming no dpkg changes for moving files too canonical locations in data.tar. Assume bootstrap protocol 3B (assume bootstrap creates the initial symlinks). I will talk about expanding to bootstrap protocol 3C in a bit. B) Develop an argument for the safety of that proposal. C) Let's review and agree to that. D) Then think about bootstrap protocol 3C; see below. Regarding bootstrapping. I think Helmut and Josh have convinced me that my proposal for bootstrap protocol 3B is viable. We could do that if we want to. I do not find having more complexity for bootstrapping pre-stretch, or for having the bootstrap tools be required to have a bit of special knowledge to be blocking bugs. If we could make 3C work, I would not object to it. I think Josh has argued that 3C is a nice to have--some day. I do not see an argument that 3C is safe though. Luca is right that if it breaks unstable or breaks upgrades, it will be really bad. So I think that to argue for 3C you need a specific proposal about what happens. And you need a really strong argument that implementing that proposal is safe for upgrades and safe during the transition. It sounds like part of the argument of safety during transitions is that you will coordinate with ftpmaster to do some essential packages in lock-step. If you can show why that can be implemented and is safe, that's fine. But because we have another option (3B) that is viable, the safety argument needs to meet a high bar. If people like Luca are saying they are not convinced after reading it, even if they cannot articulate specific concerns, I would consider that blocking. Put another way. We have to do something about moving most data to canonical paths. We need a safety argument for that of course. The review criteria there would be at le
Re: Go (golang) packaging, using external libs
On Thu, Jul 06, 2023 at 06:46:46PM +, Valera Rozuvan wrote: > Is it at all possible to create a proper DEB package: > > - using golang > - to be published in the official Debian package repository > - using a golang library which is not in Debian It is, golang has a provision for vendoring libs in vendor/ directory and go compiler will pick these up while building. However, this is usually (very much) discouraged, unless there are genuine reasons to do so, and it is always a better route to package dependencies. > (such as https://pkg.go.dev/github.com/lib/pq - A pure Go postgres driver) This library is packaged in the archive and is present as golang-github-lib-pq-dev package. See https://tracker.debian.org/pkg/golang-github-lib-pq > I would greatly appreciate, if someone can point me at an example package > which is in Debian, and is using an external golang lib. You can have a look at cadvisor, libpod, singularity-container and gitaly packages as examples. Best, Nilesh signature.asc Description: PGP signature
Go (golang) packaging, using external libs
Hi, Is it at all possible to create a proper DEB package: - using golang - to be published in the official Debian package repository - using a golang library which is not in Debian (such as https://pkg.go.dev/github.com/lib/pq - A pure Go postgres driver) I would greatly appreciate, if someone can point me at an example package which is in Debian, and is using an external golang lib. -- Best regards, Valera Rozuvan
Re: Replaces without Breaks or Conflicts harmful?
Helmut Grohne dixit:
> openjdk-8 (U)
Should be convered by the Depends lines in the respective
binary packages, e.g:
Depends: openjdk-8-jre (>= ${source:Version}),
openjdk-8-jdk (>= ${binary:Version}),
${misc:Depends}
Replaces: openjdk-8-jdk (<< 8u20~b26-1~)
> rng-tools-debian
Also false positive:
Replaces: intel-rng-tools, rng-tools
Breaks: rng-tools (>= 5migratf), rng-tools (<< 5migrate)
Conflicts: intel-rng-tools
bye,
//mirabilos
--
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Thu, Jul 06, 2023 at 04:49:34PM +, Thorsten Glaser wrote: > The Wanderer dixit: > >> snes emulator. last upstream release 2007 > >>> zsnes deb otherosfs optional arch=any-i386 > >FWIW: though I haven't touched it in quite some while, I recall from all > FWIW, I occasionally use zsnes and it works well. > But yes, hand-written assembly was part of that IIRC. = [Date: Wed, 28 Jun 2023 15:25:56 -] [ftpmaster: Scott Kitterman] Removed the following packages from unstable: zsnes | 1.510+bz2-10.2 | source, i386 Closed bugs: 1039568 --- Reason --- ROM; i386-only, abandoned upstream, alternatives exist -- Also closing bug(s): 510238 544313 609524 610313 680073 727781 792420 1038482 1039564 Also closing WNPP bug(s): = -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: 64-bit time_t transition for 32-bit archs: a proposal
The Wanderer dixit: >> snes emulator. last upstream release 2007 >>> zsnes deb otherosfs optional arch=any-i386 > >FWIW: though I haven't touched it in quite some while, I recall from all FWIW, I occasionally use zsnes and it works well. But yes, hand-written assembly was part of that IIRC. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Bug#1040493: ITP: obs-ashmanix-blur-filter -- plugin for OBS Studio to set a blur filter on a source
Package: wnpp Severity: wishlist Owner: Joao Eriberto Mota Filho X-Debbugs-Cc: debian-devel@lists.debian.org, Ashmanix * Package name: obs-ashmanix-blur-filter Version : 0.0.2 Upstream Contact: Ashmanix * URL : https://obsproject.com/forum/resources/ashmanix-blur-filter.1742/ * License : GPL-2+ Programming Lang: C++ Description : plugin for OBS Studio to set a blur filter on a source This plugin lets to set a simple blur filter on any OBS source, such images, videos, texts, scenes, webcam, etc. To use it, just right click on an image or video source and select Filters.
Re: 64-bit time_t transition for 32-bit archs: a proposal
Simon McVittie dixit: >On Wed, 05 Jul 2023 at 17:22:14 +0100, Wookey wrote: […] >> i.e we could keep the existing i386 for the gamers and have i386t64 >> (or whatever we call it) for ongoing use of i386 as a real OS. > >On Fri, 09 Jun 2023 at 16:39:38 +, Thorsten Glaser wrote: >> Ideally we’d keep the old i386 around for legacy binary-only libraries >> and executables and add an i586 architecture with a differing dynamic >> linker path > >These are essentially the same suggestion, and if there are enough Right. However, my suggestion involves *reducing* the architecture baseline again to make it accessible to more real-existing systems. But that’s orthogonal from the rest. (In fact, we might even want to do that for both.) >Because legacy binaries already "know" that the backwards-compatible >architecture is labelled i386 and i?86-linux-gnu with its dynamic linker Oh, i?86-linux-gnu is a good point I had not considered. >architecture would need to have a new dpkg architecture name, multiarch >tuple, GNU tuple (i?86-linux-gnut64?) and canonical ELF linker path. Definitely (and let’s just use the multiarch path for the ELF linker). Bit of bikeshedding on the name, of course. timet64 (or a shortened version) is a possibility but I’d also want off_t to be 64 bit in it like the BSDs have been doing for decades, for example. Ideas welcome, but it’s not important upfront. >If the new architecture is fully co-installable and distinguishable via >ELF flags (like the way amd64, i386 and x32 are), then the procedure to It will unfortunately have to be more than just how these three differ. i386 is ELF32 (ELFCLASS32) with e_machine EM_386 and ELFOSABI_LINUX or possibly ELFOSABI_NONE(?). amd64 is ELF64 (ELFCLASS64) with e_machine EM_X86_64. x32 is ELF32 (ELFCLASS32) with e_machine EM_X86_64. The new architecture would also have to be ELFCLASS32 and EM_386. Maybe we can distinguish them using e_flags… using a new EI_OSABI or, worse, e_machine sounds bad. How do we distinguish arm, armel and armhf? They all use EM_ARM probably (armeb is probably distinguished via ELFDATA2MSB). >"crossgrade" core system packages to it. If it isn't distinguishable by >ELF flags (so the dynamic linker would attempt to load i386t64 libraries >into an i386 process or vice versa, and sometimes crash as a result) I would like for things to be coïnstallable, of course. But why would the dynamic linker attempt to load the respective foreign libraries… oh right, not all are in the M-A path yet (on my box, they are, but legacy i386 systems would not have that). So we need a way to distinguish them in the ELF header and possibly also patch the i386 loader to check the new bit? field? note? and not load the solib if set. We’ll also need a cpp define, like we have… #if defined(__amd64__) && defined(__ILP32__) // x32 #if defined(__amd64__) && !defined(__ILP32__) // amd64 … and 「echo | gcc -m32 -E -dD - | less」 does not yet have anything suitable. Either patch it into gcc… (I’ve patched gcc/config/**.h files before) or… apparently, /usr/include/stdc-predef.h is included by recent GCC, if that were in the M-A path it might work. Is there any cross-distro effort for such a thing that we’d need to coordinate with? >(It's perhaps also worth noting that it's possible to upgrade from >i386 to amd64 without a net increase in e-waste by switching from i386 >hardware to older amd64 hardware that has already been discarded by its >original owner: I'm typing this into a second-hand ex-corporate Lenovo >T480s, built in 2018 according to its serial number label, and the X220 >that was previously very popular with DDs was a UEFI-capable amd64 from >around 2012.) Right, that’s possible for part of the use cases, and not a bad idea anyway. (Radical idea: application and framework developers ought to still test their things on low-spec machines, to get a feeling for just how much bloat they introduce…) bye, //mirabilos -- den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt… oder netzteile, an die man auch den monitor angeschlossen hat und die dann für ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder LAN party │ damals, als der pizzateig noch auf dem monior "gegangen" ist
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Wed, 05 Jul 2023 at 17:22:14 +0100, Wookey wrote: > On 2023-06-06 11:45 +0100, Simon McVittie wrote: > > 1. i386 as a fully-featured architecture that you can run independently > >on 32-bit x86 systems from roughly the 2000-2010 era > > > > 2. i386 as a multiarch foreign architecture to run legacy binaries on > >modern x86_64 systems > > It is possible to have both these things, by treating this transtion > as a new-ABI (i.e new architecture) transition, not a within-arch ABI > transition. > > i.e we could keep the existing i386 for the gamers and have i386t64 > (or whatever we call it) for ongoing use of i386 as a real OS. On Fri, 09 Jun 2023 at 16:39:38 +, Thorsten Glaser wrote: > Ideally we’d keep the old i386 around for legacy binary-only libraries > and executables and add an i586 architecture with a differing dynamic > linker path These are essentially the same suggestion, and if there are enough developers interested in the use-case that I labelled (1.) above, then I agree that i386t64 (or i586t64 or ia32 or whatever its newly-formed porting team wants to call it) would be the way to achieve that. Because legacy binaries already "know" that the backwards-compatible architecture is labelled i386 and i?86-linux-gnu with its dynamic linker at /lib/ld-linux.so.2, and by definition legacy binaries don't have the opportunity to to change their assumptions, I think the new time64 architecture would need to have a new dpkg architecture name, multiarch tuple, GNU tuple (i?86-linux-gnut64?) and canonical ELF linker path. If the new architecture is fully co-installable and distinguishable via ELF flags (like the way amd64, i386 and x32 are), then the procedure to switch to it could be similar to switching from i386 to amd64, or armhf to arm64: either reinstall, or add it as a foreign architecture and gradually "crossgrade" core system packages to it. If it isn't distinguishable by ELF flags (so the dynamic linker would attempt to load i386t64 libraries into an i386 process or vice versa, and sometimes crash as a result) then a reinstall would be required. I am personally only interested in i386 for the use-case that I labelled (2.) above, but I don't want to prevent anyone else from working on (1.). (It's perhaps also worth noting that it's possible to upgrade from i386 to amd64 without a net increase in e-waste by switching from i386 hardware to older amd64 hardware that has already been discarded by its original owner: I'm typing this into a second-hand ex-corporate Lenovo T480s, built in 2018 according to its serial number label, and the X220 that was previously very popular with DDs was a UEFI-capable amd64 from around 2012.) smcv
Bug#1040465: ITP: libdbd-cassandra-perl -- Perl DBI database backend for Cassandra
Package: wnpp Severity: wishlist Owner: Yadd X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libdbd-cassandra-perl Version : 0.57 Upstream Contact: Tom van der Woerdt * URL : https://metacpan.org/release/DBD-Cassandra * License : GPL-1+ or Artistic Programming Lang: Perl Description : Perl DBI database backend for Cassandra DBD::Cassandra is a Perl5 Database Interface driver for Cassandra, using the CQL3 query language.
Bug#1040463: ITP: libanyevent-xspromises-perl -- Another Promises library, implemented in XS for performance
Package: wnpp Severity: wishlist Owner: Yadd X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libanyevent-xspromises-perl Version : 0.005 Upstream Contact: Tom van der Woerdt * URL : https://metacpan.org/release/AnyEvent-XSPromises * License : GPL-1+ or Artistic Programming Lang: Perl Description : Another Promises library, implemented in XS for performance AnyEvent::XSPromises provides a Promises interface, written in XS for performance, conforming to the Promises/A+ specification. This library is a dependency of libcassandra-client-perl (#924121) and will be maintained under Perl Team umbrella.
Re: systmd-analyze security as a release goal
"Trent W. Buck" writes: > e.g. I expect "SystemCallArchitectures=native" to break for a lot of > people (anyone doing dpkg --add-architecture) Short version: • SystemCallArchitectures=native + debianutils:i386 doesn't break dpkg-db-backup.service. • Probably savelog simply never calls an ARCHITECTURE-SPECIFIC syscall. • SystemCallArchitectures=native + nginx:i386 DOES break nginx.service. • Neither journalctl nor coredumpctl makes it obvious this is WHY nginx crashed. Boring detailed version follows. I tried to trigger this (SystemCallArchitectures=native vs. dpkg --add-architecture) just now, and I can't! On an amd64 Debian 12 VM, I tried dpkg --add-architecture i386 apt update apt install --allow-remove-essential debianutils:i386 debianutils:amd64- systemctl edit dpkg-db-backup # Adding these: [Service] ReadWritePaths=/var/backups CapabilityBoundingSet= NoNewPrivileges=yes PrivateDevices=yes ProtectClock=yes ProtectKernelLogs=yes ProtectControlGroups=yes ProtectKernelModules=yes SystemCallArchitectures=native systemctl start dpkg-db-backup systemctl status dpkg-db-backup It seems to be running savelog:i386 happily. Then I tried a completely alien architecture, in case i386-on-amd64 was somehow special: dpkg --add-architecture arm64 apt update apt install mg:arm64 qemu-user-static systemctl edit dpkg-db-backup # Adding these: [Service] ExecStart= ExecStart=mg tmp.txt [Service] ReadWritePaths=/var/backups CapabilityBoundingSet= NoNewPrivileges=yes PrivateDevices=yes ProtectClock=yes ProtectKernelLogs=yes ProtectControlGroups=yes ProtectKernelModules=yes SystemCallArchitectures=native systemctl start dpkg-db-backup systemctl status dpkg-db-backup mg[1552]: panic: standard input and output must be a terminal And that worked (in the sense that systemd ran mg enough for it to call printf). I also thought that it might not work in linux-image-cloud-amd64, so I switched to linux-image-amd64, but it didn't seem to help -- systemd wasn't blocking things. The main "user story" for SystemCallArchitectures=native is if an attacker replaces (say) /bin/sh with a compromised binary. Usually they use i386, so it works on both i386 and amd64 systems. So if you do SystemCallArchitectures=native on amd64, it SHOULD just go "haha no, this is i386, piss off". Ah OK, on rereading the manpage, https://manpages.debian.org/bookworm/systemd/systemd.exec.5.en.html#SystemCallArchitectures= it seems like this just blocks non-amd64 syscalls. So I guess a program like savelog doesn't trigger it, because it's so simple it never hits an architecture-specific syscall? Also (probably) when mg:arm64 transits through qemu-user-static, by the time the enforcing layer sees it, the syscalls are native amd64 syscalls. Let's test a more complicated program, like nginx:i386... OK, I can make that fail. Phew! I thought I was going mad. root@main:~# systemctl show -p SystemCallArchitectures nginx SystemCallArchitectures=native root@main:~# systemctl start nginx Job for nginx.service failed because a fatal signal was delivered causing the control process to dump core. See "systemctl status nginx.service" and "journalctl -xeu nginx.service" for details. root@main:~# systemctl status nginx × nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled) Drop-In: /etc/systemd/system/nginx.service.d └─hardening.conf Active: failed (Result: core-dump) since Thu 2023-07-06 18:32:40 AEST; 3s ago Duration: 2min 32.918s Docs: man:nginx(8) Process: 2919 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=dumped, signal=SYS) CPU: 2ms Jul 06 18:32:40 main.lan systemd[1]: Starting nginx.service - A high performance web server and a reverse proxy server... Jul 06 18:32:40 main.lan systemd[1]: nginx.service: Control process exited, code=dumped, status=31/SYS Jul 06 18:32:40 main.lan systemd[1]: nginx.service: Failed with result 'core-dump'. Jul 06 18:32:40 main.lan systemd[1]: Failed to start nginx.service - A high performance web server and a reverse proxy server. root@main:~# coredumpctl TIME PID UID GID SIGCOREFILE EXE SIZE Thu 2023-07-06 18:32:40 AEST 2919 0 0 SIGSYS present /usr/sbin/nginx 27.1K root@main:~# coredumpctl info PID: 2919 (nginx) UID: 0 (root) GID: 0 (root) Signal: 31 (SYS) Timestamp: Thu 2023-07-06 18:32:40 AEST (13s ago) Command Line: /usr/sbin/nginx -t -q -g $'daemon on; master_process on;' Execut
