Bug#1040616: ITP: rocm-validation-suite -- AMD GPU system validation tools
Package: wnpp Severity: wishlist Owner: Cordell Bloor X-Debbugs-Cc: debian-devel@lists.debian.org, c...@slerp.xyz, debian...@lists.debian.org * Package name: rocm-validation-suite Version : 5.6.0 * URL : https://github.com/ROCm-Developer-Tools/ROCmValidationSuite * License : Expat Programming Lang: C++ Description : AMD GPU system validation tools The ROCm Validation Suite (RVS) is a collection of utilities for verifying the correct functioning of the AMD GPUs installed on a system. It provides system administrators with tests, benchmarks and other tools for troubleshooting common problems found in high-performance computing environments. . RVS provides utilities for querying GPU properties, monitoring GPU information, monitoring the PCI Express link speeds and power, querying relevent PCI Express bus properties for a GPU, verifying the GPU SBIOS mapping, benchmarking peer-to-peer links between GPUs, benchmarking the PCI Express bus, stress-testing installed GPUs, stress-testing the system PSU, verifying GPU memory to detect hardware errors, and benchmarking device global memory. This package provides a variety of tools for checking the correct functioning of AMD GPU hardware, which would be valuable for ensuring that malfunctioning hardware and misconfigured systems are identified. It is useful for ruling out hardware problems when unexpected software behaviours are encountered. This package is part of AMD's ROCm stack and will be maintained under the Debian AI team umbrella.
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
> "Bastian" == Bastian Blank writes: Bastian> On Wed, Jul 05, 2023 at 09:06:24PM -0300, Santiago Ruano Rincón wrote: >> For the moment, ifupdown is still installed by the >> debian-installer as default network interfaces manager. And after >> sleeping over it, and discussing with debian fellows, I would >> like to call for consensus to rise Priority: Important to >> dhcpcd-base (as initially requested in #1038882), and switch to >> Recommends: dhcpcd-base | dhcp-client. Bastian> Why do we need to have the priority adjusted instead of fix Bastian> d-i to install what it knows the user needs? Because it's not just D-I, it's bootstrapping in general. For that reason I support raising the priority.
Re: Second take at DEP17 - consensus call on /usr-merge matters
> "Sam" == Sam Hartman writes: Sam> TL;DR: It looks like if we do not want to encode merged /usr Sam> into the bootstrap protocol, we must keep some aliases and Sam> cannot move all files in data.tar. I think removing all Sam> aliasing is important and so I am firmly in the camp of doing Sam> usrmerge in the bootstrap protocol. I was chatting with Klee Dienes this morning about this issue, and we had an interesting discussion I'd like to share here. I want to emphasize that Klee has not been following the discussion, so if he comes up with interesting ways to think about things, great, but he's not currently a participant in trying to come to consensus here. It sounds like we've convinced ourselves we have some sort of technical debt we're going to need to carry from the usrmerge transition, and we probably will never be able able to get away from it: 1) In Bootstrap option 3B, we encode doing the usrmerge symlinks into the bootstrap protocol. Even if we somehow later create the symlinks in a data.tar, we need to retain this debt in the bootstrap protocol as long as we want to be able to bootstrap versions of Debian that do not encode things in data.tar. 2) If we take Bootstrap 3C category 1, and some files never get moved to their canonical path, then we have technical debt we must maintain in essential packages, basically for ever. In effect, there is technical debt because the canonical locations of some files differs from their canonical interface locations. For example, /bin/sh will live at /usr/bin/sh. And as long as that's true (we expect for ever), we have to say that somewhere. Okay, so how do we decide where to put technical debt? Klee argued that one point of lower layers is to make things easier and cleaner for layers above them. I.E. there may be some magic in the bootstrap layer and that's good if it makes things cleaner or more pure for the layer above (the essential packages). Similarly, we put complexity in essential packages and make it easier to write non-essential packages. We've seen this over the years. For example, back in the day, bootstrap had to create devices. It still has to arrange for a /proc and a /sys. We managed to follow this principle by pushing devices down a layer further effectively into the kernel and udev, and because of that bootstrap is simpler than it used to be. But Klee argued that putting this in bootstrap is nice because you can handle it in one place rather than spreading it across every essential package containir a binary that cannot move. One assumption behind 3C at least initially is that we were avoiding a combinatorial explosion in changes to bootstrap tool. That's certainly true in https://lists.debian.org/20230517093036.ga4104...@subdivi.de That message assumes 3B is not really an option, and we're looking at changes to number of bootstrap tools times number of releases of Debian and all its derivatives. But as we've explored, we've learned that the combinatorial explosion is more like 2 (3 if you count cdebootstrap). Josh has agreed that we can implement 3B in a small number of lines of code in the bootstrap implementations, at least if we're willing to require people bootstrapping pre-stretch to say they do not want merged /usr. And so, we can concentrate the complexity of our technical debt into a smaller number of places if we adopt 3B. I also think it is possible (although unlikely) that as maintainer scripts in essential packages change over the years, the number of binaries affected by 3C category 1 may increase. I.E. we may find ourselves moving a binary out of /usr back to /bin or being unable to use that in a future maintainer script. That seems like a mess to me. I agree the set of circumstances where we need to do that is small, but I think itmay be nonzero. --Sam signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Wed, Jul 05, 2023 at 09:06:24PM -0300, Santiago Ruano Rincón wrote: > For the moment, ifupdown is still installed by the debian-installer as > default network interfaces manager. And after sleeping over it, and > discussing with debian fellows, I would like to call for consensus to > rise Priority: Important to dhcpcd-base (as initially requested in > #1038882), and switch to Recommends: dhcpcd-base | dhcp-client. Why do we need to have the priority adjusted instead of fix d-i to install what it knows the user needs? Bastian -- Where there's no emotion, there's no motive for violence. -- Spock, "Dagger of the Mind", stardate 2715.1
Bug#1040590: ITP: tecla -- keyboard layout viewer for the GNOME desktop
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Owner: jeremy.bi...@canonical.com Package Name: tecla Version: 45~alpha Upstream Author: Red Hat License: GPL-2+ Programming Lang: C Description: keyboard layout viewer for the GNOME desktop This app is a basic keyboard layout viewer for integration with the GNOME desktop. Other Info -- This package will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/tecla It is expected that Tecla will be a dependency of GNOME Shell & the GNOME Settings app (gnome-control-center) for GNOME 45 later this year. Tecla is a basic app written in GTK4 & libadwaita and would replace gkbd-capplet (provided by libgnomekbd) for the GNOME desktop. Thanks, Jeremy Bícha
Re: Replaces without Breaks or Conflicts harmful?
Helmut Grohne dixit: >> > 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 No, because the not-broken subset Depends on rng-tools-debian. (It’s a transitional package.) So, while it cannot be seen by “just” inspecting rng-tools-debian, all possible combinations are covered. (Also, the transition is done and rng-tools is gone.) bye, //mirabilos -- /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against ╳ HTML eMail! Also, ╱ ╲ header encryption!
Bug#1040556: ITP: aioquic -- Library for the QUIC network protocol in Python
Package: wnpp Severity: wishlist Owner: Scott Kitterman X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: aioquic Version : 0.9.21 Upstream Author : Jeremy Lainé * URL : https://github.com/aiortc/aioquic * License : BSD 3-Clause Programming Lang: Python Description : Library for the QUIC network protocol in Python Library for the QUIC network protocol in Python. It features a minimal TLS 1.3 implementation, a QUIC stack and an HTTP/3 stack. . QUIC was standardised in RFC 9000 and HTTP/3 in RFC 9114. aioquic is regularly tested for interoperability against other QUIC implementations. This is needed as a dependency for dnspython to support DoQ (DNS over QUIC). I intend to maintain this in the Debian Python Team
Bug#1040553: ITP: pylsqpack -- Python wrapper around the ls-qpack library
Package: wnpp Severity: wishlist Owner: Scott Kitterman X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pylsqpack Version : 0.3.17 Upstream Author : Jeremy Lainé * URL : https://github.com/aiortc/pylsqpack * License : BSD 3-Clause Programming Lang: Python Description : Python wrapper around the ls-qpack library Wrapper around the ls-qpack library. It provides Python Decoder and Encoder objects to read or write HTTP/3 headers compressed with QPACK. This is a dependency for aioquic, which is needed to support DoQ (DNS over QUIC) in dnspython. I intend to maintain this in the Debian Python Team
Re: Second take at DEP17 - consensus call on /usr-merge matters
TL;DR: It looks like if we do not want to encode merged /usr into the bootstrap protocol, we must keep some aliases and cannot move all files in data.tar. I think removing all aliasing is important and so I am firmly in the camp of doing usrmerge in the bootstrap protocol. > "Helmut" == Helmut Grohne writes: Helmut> Therefore, my premise of us agreeing on shipping the Helmut> symlinks in base-files likely is wrong despite the number of Helmut> vocal proponents. I think we'd like to do that if we can make it work. I think you convinced us the price of that is too high deep in the message you quote below. >> So I think that to argue for 3C you need a specific proposal >> about what happens. Helmut> https://lists.debian.org/20230517093036.ga4104...@subdivi.de Ah thanks. I will admit that mail didn't get the initial attention it perhaps deserved. And even reading it now I don't see a clearly articulated proposal for 3C. I was put off by a number of things in the mail including the idea that what we now call 3B would require encoding derivative-specific knowledge into the bootstrapping protocol. And so by the time you started talking about specifics of 3C I had already disagreed with enough of the message that I had tuned out. (I made those disagreements clear; my suspicion is that others who also disagreed with other earlier parts of the message tuned out the 3C specifics.) So, my understanding of the specific proposal is that: We in are in category 1: > 1. Don't move. We just keep those files that require a particular >location (such as /bin/sh or the dynamic loader) in their >non-canonical location. As such, maintainer scripts will be able to >run and perform the conversion to symbolic links afterwards. That is, there are some essential files that always remain in non-canonical locations. You also go through some analysis and make it clear that category 2 is fragile: > 2. Move and ship links. Since we unpack all essential data.tar before >running the first maintainer script, having one package contain the >compatibility symlinks is enough to fix the problem. I agree with your analysis that category 2 is fragile. I definitely had not payed adequate attention to this before, even though I did read chunks of the message. My understanding the argument for 3C is roughly the following: >This gets me to the core of my argument: the way that a Debian chroot should >look like should be described by the packages that get installed into the >chroot and not by an outside tool. Yes, an outside tool is needed to do the >installation but that tool should rely on the package metadata to make choices >instead of encoding timestamp or release name dependent codepaths. So it sounds like we are faced with two choices: 1) Keep some aliasing long-term in the data.tar files and get the bootstrap described by the packages rather than by the bootstrap protocol 2) Change the bootstrap protocol and remove aliasing entirely. I am firmly in camp 2. I think that unless we are going to fix dpkg to support aliasing, we need to remove aliasing entirely. signature.asc Description: PGP signature
Re: Second take at DEP17 - consensus call on /usr-merge matters
On Fri, Jul 07, 2023 at 09:55:05AM +0200, Helmut Grohne wrote: > Thus far, my impression was that temporarily (<1week, preferably <1day) > breaking the ability to debootstrap was an acceptable risk and is > something we experience every now and then anyway (with adduser most > recently). actually, python3-mininmal (#1040316) is the most recent case of debootstrap being broken, not adduser (#1039709). :) AFAIK. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If we'd ban all cars from cities tomorrow, next week we will wonder why we waited for so long. signature.asc Description: PGP signature
Bug#1040528: ITP: libsemantic-version-java -- single-class semantic version implementation for java
Package: wnpp Severity: wishlist Owner: "Andreas B. Mundt" X-Debbugs-Cc: debian-devel@lists.debian.org, a...@debian.org * Package name: libsemantic-version-java Version : 2.1.1 Upstream Contact: Simon Taddiken * URL : https://github.com/skuzzle * License : MIT Programming Lang: Java Description : single-class semantic version implementation for java Semantic-Version requires no further dependencies and is thereby easy to use within projects. Key features are: - Lightweight: Consists of only a single file, no dependencies. - Immutable: Strict immutability ensures easy handling and thread safety. - Serializable: Objects can be serialized using Java's ObjectOutputStream. - Fast: Many performance improvements make this the fastest semver implementation in java around (according to parsing and sorting performance. The package is needed as a dependency for filius (RFP: #982648). I plan to maintain it within the debian java team.
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón wrote: > > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió: > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió: > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > > > wrote: > > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > > > Greetings, > > > > > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > > > > > good time to re-visit Debian's choice of standard DHCP client shipping > > > > > with priority:important. > > > > > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > > > > > 1) already supported by ifupdown. > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > > > > separation. > > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > > > > configure both stacks. > > > > ... > > > > > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for > > > > the moment, and I'll make the relevant changes in ifupdown as soon as I > > > > can. Josué, any thoughts? > > > > > > 1) As someone pointed out in the thread, the reason why > > > isc-dhcp-client had priority:important probably was to ensure that > > > debootstrap would pull it, since debootstrap ignores Recommends and > > > packages with a priority lower than standard. > > > > > > 2) However, as long as ifupdown explictly depends on a package, it can > > > also pull dependencies with a lower priority. Right now ifupdown > > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would > > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead. > > > > > > 3) At that point, swapping the priority of isc-dhcp-client and > > > dhcpcd-base merely becomes "nice to have". Heck, the priority of both > > > could, in principle, be optional, just as long as ifupdown explicitly > > > Depends on a DHCP client, and the first alternative is a real package. > > > > I was about to bump dhcpcd-base as ifupdown dependency, but... if > > isc-client-dhcp is a Recommends, is because not all users want a dhcp > > client installed, where all the ipv4 is handled statically, and ipv6 is > > done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base the > > next upgrade. > > > > So I'd prefer to go forward with the steps proposed by Simon, and > > s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends: > > Unless there is a strong objection, I'll file the override bug report. > > (sorry for taking so long to come back to this) > > For the moment, ifupdown is still installed by the debian-installer as > default network interfaces manager. And after sleeping over it, and > discussing with debian fellows, I would like to call for consensus to > rise Priority: Important to dhcpcd-base (as initially requested in > #1038882), and switch to Recommends: dhcpcd-base | dhcp-client. > > This addresses two scenarios: keep some systems as small as possible > (ifupdown users can remove dhcpcd if they want) and having a useful dhcp > client available after installing/bootstrapping. > > So I would like to retitle #1038882 back as originally reported. (Sorry > for going back and forth) Objections? > > The situation regarding the default network interfaces manager could > change, even in the short term. But that could be discussed in another > thread. No objection. Raising the priority of dhcpcd-base to important works for me. Martin-Éric
Re: Second take at DEP17 - consensus call on /usr-merge matters
Hi, On 7/7/23 16:55, Helmut Grohne wrote: If we have a consensus we're unwilling to wait for a patch, it doesn't matter whether that's because: While you try to remove the reasoning for this point of view from the consensus, the "willing to wait" language implies a reason of "too slow" already. The main problem I see with that language is that it is entirely passive, as if a patch would appear by waiting for it to do so. Right now, I seem to be the only person working on one, which is clearly ridiculous, as I can invest maybe a total of four hours per week into it, so obviously I need to be realistic here and say that it is a bad idea for the project to wait for me to implement this, and I don't want to be in the position of having the project wait for me either because I already have that in 60 hours of my life between Monday and Friday. We also have quite some disagreement on what "the patch" is in terms of what semantics would help here. Yes, that's underspecified. I've tried to get started on this in [1], that is by no means complete but it has not generated any comments either. If there is interest in dpkg changes as a solution, then I could add this to the document. I carefully avoided adding reasoning to the proposed consensus as I was seeing our disagreement on reasoning. I now see how that second sentence could be read as precluding a dpkg patch in general. Would it help to add "+For the purpose of finalizing the transition,+ dpkg is not augmented ..." to leave open the possibility to add such a change but still implying that we are not waiting for it to happen? Yes, that was why I objected to that wording as well. I do agree that we need to move forward without waiting for a patch, if only out of the self-serving interest that I don't want to sit on the critical path. I think we need consensus on decisions and confirmation that everyone feels heard. Heh. I see how you get there. I agree with that latter part and tried to use the agreement on problems and mitigations as a vehicle for ensuring that everyone feels heard. Evidently, that does not work out either. It's the best way I can see to reach a consensus, but consensus, like voting, can only allocate resources and modify procedures. If we have a viable technical procedure that finishes the transition, then we can get consensus to implement it. If we have a technical procedure that requires changing a procedure to be viable (such as lock-step upgrade of packages in the archive so the installer is never presented with an inconsistent set), then we can get consensus to modify the procedure and implement the solution. However, if there are open questions about the technical viability of a solution, then the answer to those should be technical as well. Hence my suggestion to say we have consensus to focus our efforts on the solution space that doesn't require a dpkg change -- that is purely an allocation of resources, and the remainder of the document is a very useful collection of the knowledge we have gathered so far, the avenues that have been investigated and possible blockers for those. We can also try to get consensus or votes on expanding the solution space: - mitigations that require archive-side changes, like an upload check that a package doesn't trigger a known file loss condition - mitigations that require users to upgrade using a special procedure - mitigations that (further) violate policy by e.g. manipulating the dpkg database from the usrmerge package, or wrapping dpkg in a diversion - mitigations that require updating a stable release, such as shipping an updated debootstrap package I'm not sure all of these would be unanimous, but if there is a technical solution that becomes viable through something we can vote on, that is completely valid. In any case, the rough consensus on moving forward without major changes to dpkg (for reasons we disagree about) paves the road for selecting a subset of mitigations and proposing that as decision. The major missing piece to perform this selection is an agreement on how we protect aliasing symlinks from deletion (aka P9), because we still have quite strong disagreement on the mitigations selected there. The questions I see are - Can we get a full column of checkmarks by any combination of mitigations? - Are there procedural mitigations that can be useful? - Are these mitigations mutually compatible? Simon [1] https://lists.debian.org/debian-dpkg/2023/06/msg00050.html
Re: Second take at DEP17 - consensus call on /usr-merge matters
Hi Sam, On Thu, Jul 06, 2023 at 01:51:04PM -0600, Sam Hartman wrote: > 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: Indeed, this is not how I looked at it. It also is a view that I don't subscribe to, because I think commercial backing of the issue changes the equation. So if I were to see changing dpkg as a viable way now (I did earlier), I would be willing to wait for it, because we have recently made significant progress on defining what those semantics should be. While you try to remove the reasoning for this point of view from the consensus, the "willing to wait" language implies a reason of "too slow" already. > 1) Some of us think the patch would be a bad idea Additionally, people disagree on why it is 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. We also have quite some disagreement on what "the patch" is in terms of what semantics would help here. > Helmut effectively asked us to agree with 1. I disagree here. For reference, I am quoting the proposed consensus item: | The primary method for finalizing the /usr-merge transition is | moving files to their canonical locations (i.e. from / to /usr) | according to the dpkg fsys database (i.e. in data.tar of binary | packages). dpkg is not augmented with a general mechanism | supporting aliasing nor do we encode specific aliases into dpkg. I carefully avoided adding reasoning to the proposed consensus as I was seeing our disagreement on reasoning. I now see how that second sentence could be read as precluding a dpkg patch in general. Would it help to add "+For the purpose of finalizing the transition,+ dpkg is not augmented ..." to leave open the possibility to add such a change but still implying that we are not waiting for it to happen? > And I don't think there is a consensus on this. Even though I disagree on that's what I asked for, I agree that we don't have consensus on patching dpkg being a bad idea in general. So how do we get towards an agreeable consensus item? Evidently, the one I proposed does not work out and the "willing to wait" variant you proposed garners rough consensus, but not more. Would someone else be able to propose wording that passes muster? > > > 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. Heh. I see how you get there. I agree with that latter part and tried to use the agreement on problems and mitigations as a vehicle for ensuring that everyone feels heard. Evidently, that does not work out either. In any case, the rough consensus on moving forward without major changes to dpkg (for reasons we disagree about) paves the road for selecting a subset of mitigations and proposing that as decision. The major missing piece to perform this selection is an agreement on how we protect aliasing symlinks from deletion (aka P9), because we still have quite strong disagreement on the mitigations selected there. > WRT the problems, I confirm that the list of problems does (in my > reading) accurately describe the problems people have brought up. Thank you! > 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 was trying to imply that we need to address (more or less) all of these nine problems. I say address rather than fix, because we may choose to only fix them in certain environments and skip others (e.g. derivatives, addon repositories, backports, skip upgrades etc.). > 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. To me, that set of instructions is a later step, because those instructions strongly depend on the selection of the mitigations and the selection varies wildly with our disagreement of symlink protection. If I were to present instructions now (one way or another), people would rightfully disagree (different ones depending on the selection). > I'd like instructions that clearly allowed me to reas
