Re: The future of mipsel port
On 2023-07-19 11:23, Paul Wise wrote: > On Tue, 2023-07-18 at 12:45 +0800, YunQiang Su wrote: > > > As CIP United, we do maintain an unofficial port of mipsel. > > So I wish that Debian can still accept our patch to support mipsel > > port (source only). > > https://repo.oss.cipunited.com/debian/ > > The closest Debian has to source-only ports are the ones that are > supported in rebootstrap but not on debian-ports. You could also > migrate mipsel to debian-ports instead of dropping it entirely. Please note that maintaining a port in debian-ports in good state requires more work than an official port. Therefore this should only be done if there are people actually going to do the work, otherwise it's just a waste of time and resources. > https://wiki.debian.org/HelmutGrohne/rebootstrap > https://wiki.debian.org/PortsDocs/New > > > (And let's keep mips64el port). > > DSA would appreciate it if you could publicly document your plans for > trixie mips64el hardware qualification on the wiki, as riscv64 did: Yes. Please also clarify how do you plan to handle the NaN2008 issue for mips64el. Some of the newer buildds have NaN2008 FPU, while the port and the toolchain are configured for the old MIPS NaN. This causes some issues in some packages, a lot of headaches to packages maintainers and upstream that have to debug the issues, and eventually testsuites being fully or partially disabled. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Re: The future of mipsel port
Paul Wise 于2023年7月19日周三 11:23写道： > > On Tue, 2023-07-18 at 12:45 +0800, YunQiang Su wrote: > > > As CIP United, we do maintain an unofficial port of mipsel. > > So I wish that Debian can still accept our patch to support mipsel > > port (source only). > > https://repo.oss.cipunited.com/debian/ > > The closest Debian has to source-only ports are the ones that are > supported in rebootstrap but not on debian-ports. You could also > migrate mipsel to debian-ports instead of dropping it entirely. > Yes. It sound a good idea to migrate to debian-ports. Since we have only 15 years to 2038, I hope the ports in debian-ports should be y2038-free. > https://wiki.debian.org/HelmutGrohne/rebootstrap > https://wiki.debian.org/PortsDocs/New > > > (And let's keep mips64el port). > > DSA would appreciate it if you could publicly document your plans for > trixie mips64el hardware qualification on the wiki, as riscv64 did: > > https://dsa.debian.org/ports/hardware-requirements/ > https://wiki.debian.org/HardwareQualification > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise -- YunQiang Su
Re: The future of mipsel port
On Tue, 2023-07-18 at 12:45 +0800, YunQiang Su wrote: > As CIP United, we do maintain an unofficial port of mipsel. > So I wish that Debian can still accept our patch to support mipsel > port (source only). > https://repo.oss.cipunited.com/debian/ The closest Debian has to source-only ports are the ones that are supported in rebootstrap but not on debian-ports. You could also migrate mipsel to debian-ports instead of dropping it entirely. https://wiki.debian.org/HelmutGrohne/rebootstrap https://wiki.debian.org/PortsDocs/New > (And let's keep mips64el port). DSA would appreciate it if you could publicly document your plans for trixie mips64el hardware qualification on the wiki, as riscv64 did: https://dsa.debian.org/ports/hardware-requirements/ https://wiki.debian.org/HardwareQualification -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1041434: ITP: rust-cranelift -- low-level retargetable code generator
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-cranelift Version : 0.97.1 Upstream Contact: The Wasmtime Project Developers * URL : https://github.com/bytecodealliance/wasmtime * License : Apache-2.0 with LLVM exception Programming Lang: Rust Description : low-level retargetable code generator Cranelift is a low-level retargetable code generator. It translates a target-independent intermediate representation into executable machine code. This package is needed by swc (bug#991761). It will be maintained in the collaborative debian section of salsa at https://salsa.debian.org/debian/rust-wasmtime (wasmtime is a monorepo also containing Cranelift - if there is interest and the needed dependencies get packaged, the package may in future be extended to also provide wasmtime itself) - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS27GEACgkQLHwxRsGg ASHqog//QFxRjTnYEPBqPbJjOwnL+9kRs5IQgdOZdnO1O+Aw1A0mRamKiznbjWnI mBICExMTr4vvu29Z1NK63Ih28N1Yu4xo/bj2b5gDdNtnSs1uHsMeF3LWYhcS0AYd DhQ+DiMHX9sA0fLoXLouNd2RSBqNOhHDqSV4ry0/W5ugNw2v5likDEjASPCxV0jr 67NWeOV7lA3oxv0/8guyHGTHiyswh9oWC+qljHTGZ82oofAQa90PEq9jB/orrzpR Rr3y/haQLXz1NG2AwtIbKGtk8QGYkFKsWyoiA5bpg+anmJK+h67/h/mUu/0Lu2F/ y1+CF3Qx0BSmKP47EIOoghpwhi0l8SarXd1bzD1NWziONZCOV6pXSTHc6kWAIFBQ CWRoFD8LbXQ3dCGD0ZFWRl0os6xdCpC9pTH2UDkGSlIOFhUZQKLXK2KtlzuixOZJ j2GDXe2HfW4XFw6GyFJ+fIIuTHHkTD3XGy1oEKlylMnlokfmJLE2lI3IxElQANXS FzCARK5mujqH2eEbASSZy5Y/J0uROKOGL5oQCfbAV0h54iep96S2rMC8PvhZpawI 3eiAoTVdiQXj7bSJUEC2ghZqgjfH6SDsQkGEoC/TVl5y7E1xGpJnUMjo/3xVMoIz CYo+Dt3SmNDkWKqwrs87+WtsPGPjauc7pHXm1RKWFMbvqS+HdkY= =CTzG -END PGP SIGNATURE-
Bug#1041433: ITP: rust-id-arena -- simple id-based arena
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-id-arena Version : 2.2.1 Upstream Contact: Nick Fitzgerald * URL : https://github.com/fitzgen/id-arena * License : Apache-2.0 or Expat Programming Lang: Rust Description : simple id-based arena id-arena is a library to allocate objects and get an identifier for that object back, not a reference to the allocated object. Given an id, you can get a shared or exclusive reference to the allocated object from the arena. This id-based approach is useful for constructing mutable graph data structures. This package is needed by swc (bug#991761). It will be maintained in the collaborative debian section of salsa at https://salsa.debian.org/debian/rust-id-arena - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS25kQACgkQLHwxRsGg ASEEkhAAlbxqMawN2g8N0k39ooY+dMWMHpQqdkoqEmnYxbg1uYyRK6ioxyAXoiec Jj5/E4lzU9KXQOiiOIdpOgTvunhC+E5uPScOGs1rYnwUgHzI4tniN0SPRhcucpa8 QDdI9PFTSvPxSAeX+xVjFt1r06/lbXMMhNixVDYOu3M9GEX4Q2w0RzaKLwxBdOrW j6iviB6LtgB5pZaWrxsTy3XgB8gr43qgMnd/Mh+IY2ch8h+ge1N3/ti1/BPgxz3C ioc0ahisl+DruBFAZf4v3u+mcLitcv1g1nrfmE0bSV+JiudE2m7PJibpUXzPBWoK lCoEyBmA+jRzWynuiKqcZre1A6ckW/lQ2YkR+/IlHWHSLgQdCixUa4kiDE93hqcd +g+vEbqFtzWJwTr7g1XCs9oPejPe/b2XUz2qrxsSHaqxgPOJVE5Vrcp0ROt5umTz 7E6iQUhq6PeAvZz7uGp3r4uJqntdQT93zvv9085iexeBJR2PaJThspMCMBJyNNne gZrB8p1rlGXy/xft7VJPhF/7p+8uBEUXb6PYDFs4AcM3QeCBeRNqOlkX0J/fATis ODjEOyjR9sHwSO5XSAiazBh/BH+VnFUOl2dSW3jbeowrioYCFy+6GJbfIZ41NMkr YmFlGkjx+Eu9Cr1V/VsX7KOgBPACTXtODJ4HMU3sYPL2kj3/8lU= =AWM3 -END PGP SIGNATURE-
Bug#1041431: ITP: rust-souper-ir -- library for manipulating Souper IR
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-souper-ir Version : 2.1.0 Upstream Contact: Nick Fitzgerald * URL : https://github.com/fitzgen/souper-ir * License : Apache-2.0 or Expat Programming Lang: Rust Description : library for manipulating Souper IR souper-ir provides AST types for parsing or generating Souper IR. It is a suitable building block either for writing a custom LHS extractor, or for translating learned optimizations into your own peephole optimizations pass. This package is needed by swc (bug#991761). It will be maintained in the collaborative debian section of salsan at https://salsa.debian.org/debian/rust-souper-ir - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS24p4ACgkQLHwxRsGg ASFoNg//X+yn+nyVrFlZQIqTuazhXwczwIV4e/PEE4YqsCY3Ms21cDe1X//s4mUZ IRV5N4GUUkmcmqN4CUxpkYp3vTpin8izkpa1tmAh5gG3WKMkA/5QY5NcroOcHLcK IoL/IUAVjB2w1/nItUEkKiNJnc+DqpRZEz66xUE7JuwK1VR3xc00kwwoJSCpQXJ2 LSDwR7xpct/t7Atua5/rzQlXsaW0fGORFuGFTvkaR1JuqnmKN8KgxbJ5KfHYel5B AaGn7z23boQ69clJGXBKwBNeTP/sqE/q9byPJRqtNGuUtqZ9dxfwWuMhI82WZv9z 6G83lNDw9r2OeBviNGiWsmC/9OEoMXT26wm3F9zWPZgWRUi/Q+ZRcpVAX77xykyv R7gzJ5oBSFoQJGq3bfkFhgiU/1/g1g/D3HN8uBZR/ODl50yTHnScAR9quc06SK7u Lzesj6ON4F8ZDc6oYSVrakvwxcwsIRw+kko0BB6+euuMJutzAwX8BbDi17t50w0m 0WhaMc+i6nH//aHwQ1VgkhV3PMZ4VhC2cgux2Bcnr4NdPuG1XbhBLnJpSWtsUeVV kEJd00cV6ZNddNHtoqz8TDfi5ukJM+YfgbWWrwCRdaM4YnT3HB++cBgL3Qzgqe+A BRgok4h+4oi0opbS6xzyEDEbXGA2lIL2mxhSiixT4MkmlFzwwkw= =Ul/b -END PGP SIGNATURE-
Re: usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]
Hi Andreas and Ralf, On Mon, Jul 17, 2023 at 04:08:48PM +0200, Ralf Treinen wrote: > > Moving the usertag to the qa namespace sounds like a good idea. > > I agree Thank you > Sounds like a good idea. However, I do not think that usertags support > a hierarchy of tags. So maybe different specific usertags with a common > prefix, like > > fileconflict-installation (error occurs when one tries to install two > packages togther) > fileconflict-upgrade (error occurs when upgrading, due to missing > breaks/replaces) > fileconflict-directory (error occuring due to /usr merge) Can either of you elaborate on the need to further classify the kind of conflict (file / directory / symlink / ...) or the kind of cause (installation / upgrade / ...)? Are you ok with explicitly excluding issues that only arise as a result of /usr-merge. These have a temporary cause and will vanish before too long. Due to the automatic bug filing that I hope to be doing, I need very precise tagging for them. Often times, it is initially not trivial to figure out whether a conflict only arises from installation or upgrades. Rather I propose to have a grab-bag tag for all of them. That allows us to move forward with less complexity and makes it easier to understand for everyone. Most of these issues result in an unpack error one way or another, but the symlink vs something else conflicts may result in unpack-dependent behaviour. I think we have consensus on using the debian-qa list, but I've seen file-overwrite and fileconflict-* as proposals with varying subclassification now. While we don't have a tag hierarchy on a technical level, Paul indicated that we may establish a hierarchy using processes. Using fileconflict makes it easy to establish a fileconflict-* subclassification later (by having the qa bot automatically add the super tag when it sees a sub tag). Is this convincing enough to move forward with the generic debian...@lists.debian.org usertag fileconflict rather than something more detailed? Is this also convincing enough to extend it to cover non-file conflicts or do you want a different tag for that? Should the tag also cover m-a:same file conflicts? I certainly won't object to doing a subclassification and I'm happy to add the subclass tags if doing so does not incur unreasonable implementation cost, but I don't want to participate in designing them nor updating existing tags. My need here is automatically ignoring detected issues that already are reported and the generic variant is sufficient for doing that. Helmut
Bug#1041418: ITP: rust-slice-group-by -- iterators over groups in slices and strs
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-slice-group-by Version : 0.3.1 Upstream Contact: Clément Renault (Kerollmops) * URL : https://github.com/kerollmops/slice-group-by * License : Expat Programming Lang: Rust Description : iterators over groups in slices and strs slice-group-by is an implementation of the groupBy Haskell function, providing tools for efficiently iterating over `slice` and `str` by groups defined by a function that specifies if two elements are in the same group. This package is needed by swc (bug#991761). It will be maintained in the collaborative debian section of salsan at https://salsa.debian.org/debian/rust-slice-by-group - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS20pYACgkQLHwxRsGg ASEZnw//c5aQ3rBSG7lO+TAqSI36Z9s0X6Qm0igXKDtQS8Z3I38kDuMGB6nIFXh3 omM52+RT1RmrftP+/ijmx9qjjK3e99/XkWezzyKOQ/w6VV2nRgpKbwjo7joohspP 548xlwKDt8mi83OhbvF5yhPVSOVA4Cnw874KHanvJ2b1WMNGyShjMlD3x3k7f9q1 kUnL+V998+IUxITCXKHD/kVbowDYk5IagcGfKKWrGM+ZdjRD1pfYqmIY3XuEHX6t kIbgCHsa3qxtJcXF5GIBz5+B/Pt/CwGYzrDqjrqwMZfiu+5ChiYLIG3sdN7a1+aQ 5t2R7xS1TKFSza4TDlNH3+HZVm4eQ1C8acN/ZafyuapkL9V4lbRbQGiRKO/73bEi Lj+nHvtDIVTopD350vypEdOyGslq//jq7rInwfTe+x6ZYsSP3xqaGS+iOGfiFpKP 3dCzxVmZm8YqR2OMlRNsx0uvqTTGrEVwT/haWJ8uNXp5ovg/VeT7rOrTo74YVcG9 7H+UCjXMDOLsbotTf2FqCKWL673HjNEUt9FbAQ1lqyqHFk6QTtktIRpz4hh7Zx3Q WSZ/hcfUORXyDSu4nBJ0HkKUPAKs3wy90crU3J+XrttE7laAxmXVXzG6bA8PIw4a cE/v1/4uCpH8w1fZgQw8e2qGhr7lRPJsxQS0SoAlJ0r6etUP9OU= =RiOT -END PGP SIGNATURE-
Bug#1041417: ITP: rust-regalloc2 -- backtracking register allocator
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-regalloc2 Version : 0.9.1 Upstream Contact: Chris Fallin * URL : https://github.com/bytecodealliance/regalloc2 * License : Apache-2.0 with LLVM exception Programming Lang: Rust Description : backtracking register allocator regalloc2 is a register allocator that started life as, and is about 50% still, a port of IonMonkey's backtracking register allocator to Rust. In many regards, it has been generalized, optimized, and improved since the initial port. . In addition, it contains substantial amounts of testing infrastructure (fuzzing harnesses and checkers) that does not exist in the original IonMonkey allocator. This package is needed by swc (bug#991761). It will be maintained in the collaborative debian section of salsan at https://salsa.debian.org/debian/rust-regalloc2 - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS2zHcACgkQLHwxRsGg ASFRAA/7B0A4+Zm3LFQoPFLfv/uaqfkELXs1Fuf2eKgK/IwzR99U+ne2dNB4S1aF V0ZhF33WbidD63Em/WwNwENGYmeqUa/WUnxFrvEq45E/VyYUd0a3V+jYaGAsxEOA dZ/N7oLrdFcWaG4eF+K2+Xm5nQe7S7vNafVR2+WT69So9dLlht6gkvDYdM2QWS1u QxQ08vGgPD9qYWW3IVcvG/mTzL7MnU2PkN4CD17Lowz3pVqxqioEZoHNjxjsJdXC dhGfTE4a7B9CY8sq/8mBkaJqtOSL6VFKa26rCheMYfwg85XZQ0xS9G5ZiumFU7w9 yM1FPMR9s9YRrGm350wnWzhnKbjGbiyPqMZL79In9vVXak0AXkmUe/07Eii9budI vzaq8oPMDOfFV3R809q7I8qh3Riy27LrjPxXzB30/r2L0fGs7l6csqGuPll5NZ6O N0087VphdJoGUJw9Sro+4Dvs+vqqsmNKQ26H+5d8BWeQsfmu1MTD/iyBu4w+3GG1 3nbrMFpBR16eQ6gV4rYxBjTcocqGBPJU+BwgGs5wcQtwplIN25T0pGwoIz2ZhPUQ pl+5EQw4dMCPMWJlmS9HWcbz5bD2s/t1cHDGpw87Nh66JjV1n6sAMkqNkFtxirCD WTBN6RMFscwLD/7wrgS0Q/bSwNWe9IzbuuJZDUu1+INW7w+fPrk= =nXER -END PGP SIGNATURE-
Re: The future of mipsel port
On Tue, Jul 18, 2023 at 12:45:51PM +0800, YunQiang Su wrote: > Known supported hardwares: > MIPS P5600 > Ingenic X2000 > Loongson 3A4000 This sounds reasonable, but do you have a list of hardware currently supported by the mipsel port that would be left unsupported by this?
