Re: The future of mipsel port
Aurelien Jarno 于2023年7月19日周三 14:43写道： > > 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. > I am working on getting more NaN1985 hardware for Debian. > Regards > Aurelien > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://aurel32.net -- YunQiang Su
Bug#1041463: ITP: rust-wasmtime -- cross-platform engine for running WebAssembly programs
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-wasmtime Version : 10.0.1 Upstream Contact: The Wasmtime Project Developers * URL : https://github.com/bytecodealliance/wasmtime * License : Apache-2.0 with LLVM exception Programming Lang: Rust Description : cross-platform engine for running WebAssembly programs rust-wasmtime is the Rust embedding API for the Wasmtime project: a cross-platform engine for running WebAssembly programs. This is a pseudo-ITP: The source package is already maintained for the subset covering core Cranelift crates, since they are part of same monorepo. The intent tracked here is extending that source package to provide binary packages librust-wasmtime* which involves additional dependencies unneeded for Cranelift. Please shout if there is need for wasmtime, and especially if there is interest in helping get the needed dependencies packaged. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS3pT0ACgkQLHwxRsGg ASHK0Q//T+JkDOAzi2aWZVLT0106beLktA52VWg0mivPwwM915X+mV3Ay1WcM022 3it2jJNtm3i/srEm1whOK/hB74kW2QvXuCRt9s9f4LQgchhvdp3RrjCdWFZwhgtI fy4ukekVJeDDa8gVY7BoTVMDRKBBNs7oLKnOhj08HPGi/mn+bB9tg1BCPL5DpZJt k/VpwFQFCG/Oe3ddlVRRyiZ/KnrprlEbOstMhgDyHMNPbaDgBuBl4Zjdv2TknHzH D2/aWPjdQncD53ub+MKOZIlhHs1CN6jZt0eEek3mFXtotG12jXDxwlvuhLuNTbVa HjudFhavVuHM1ugOYvfh9ucLUbBNx+P8pZjW2JDhNBQp2wOVCT6HYLo6uv0R1eGS fWu1LoY4mRx5X6wvTuZGB7LoOBds0dZo/96o7YPz/gnuhMR/5jfEUyQy1RZhYYe6 cEWSLQdjSVlHHfYgZ50uOdx99T+yd4jeimTCyb5CBYWtSIS3MBLLAaurapfxlIqC laFzGQ02qx+LOfsRahzsjLzf++fK5xMM16ombKEgyMHT5zu/2BwXiUCZunv5TURT A2bgXzyTaumrsvAHNrY4FWarXNywNd7srjaAsGwSN9iN75KAhS4Pkk0r9pPposBl v3TkcJv9mfc780lefjqyVJc1uzJ6VSNKS98G2JKCoaaqYN77W0A= =t/RV -END PGP SIGNATURE-
Re: debian-devel-digest Digest V2023 #271
Unsubscribe On Tue, Jul 18, 2023 at 1:33 PM < debian-devel-digest-requ...@lists.debian.org> wrote: > Content-Type: text/plain > > debian-devel-digest Digest Volume 2023 : > Issue 271 > > Today's Topics: > Re: Proposed MBF: Removal of libfree [ Hugh McMaster >Bug#1041318: ITP: rust-json-event-pa [ Jonas Smedegaard ] > Re: Proposed MBF: Removal of libfree [ Hugh McMaster >Re: usertagging file conflicts [Was: [ Ralf Treinen > ] > Re: usertagging file conflicts [Was: [ Paul Wise ] > The future of mipsel port [ YunQiang Su ] > Re: systemd-analyze security as a re [ "Trent W. Buck" < > trentb...@gmail.co ] > Re: The future of mipsel port [ Matthew Garrett >Bug#1041417: ITP: rust-regalloc2 -- [ Jonas Smedegaard ] > Date: Mon, 17 Jul 2023 21:45:13 +1000 > From: Hugh McMaster > To: Simon McVittie > Cc: debian-devel@lists.debian.org > Subject: Re: Proposed MBF: Removal of libfreetype6-dev > Message-ID: > < > sy6p282mb3236a4620329b1388fa28a6ff2...@sy6p282mb3236.ausp282.prod.outlook.com > > > Content-Type: text/plain; charset="UTF-8" > > Hi Simon, > > On Mon, 17 Jul 2023 at 00:07, Simon McVittie wrote: > > > > On Sun, 16 Jul 2023 at 22:38:20 +1000, Hugh McMaster wrote: > > > Currently, there are 219 build-dependencies and 29 (direct) > > > dependencies on libfreetype6-dev, which has been released with > > > bullseye and bookworm. > > > > Lintian diagnoses this as "[build-]depends-on-obsolete-package" since > > 2.116.0 (MR at [1], instances of the relevant tags listed at [2] and > > [3]) which will hopefully help progress towards dropping the transitional > > package. > > Thanks for pointing this out. I wasn't aware Lintian had started > flagging dependencies on obsolete packages some 10 months ago. > > Having Lintian issue a warning or error instead of bug filing is > preferable. > > > [1] https://salsa.debian.org/lintian/lintian/-/merge_requests/417 > > (partially reverted in > > https://salsa.debian.org/lintian/lintian/-/merge_requests/452 but > the > > freetype part remains) > > [2] > https://udd.debian.org/lintian-tag.cgi?tag=build-depends-on-obsolete-package > > [3] > https://udd.debian.org/lintian-tag.cgi?tag=depends-on-obsolete-package > > > > Unfortunately lintian.debian.org is not currently updating, so please > > don't use that as a source. > Date: Mon, 17 Jul 2023 14:06:35 +0200 > From: Jonas Smedegaard > To: Debian Bug Tracking System > Subject: Bug#1041318: ITP: rust-json-event-parser -- JSON event parser and > serializer > Message-ID: < > 168959559567.3829237.16286019313710125242.report...@auryn.jones.dk> > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > > Package: wnpp > Severity: wishlist > Owner: Jonas Smedegaard > X-Debbugs-Cc: debian-devel@lists.debian.org > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > * Package name: rust-json-event-parser > Version : 0.1.1 > Upstream Contact: Tpt > * URL : https://github.com/oxigraph/json-event-parser > * License : Apache-2.0 or Expat > Programming Lang: Rust > Description : JSON event parser and serializer > > JSON event parser > is a simple streaming JSON parser and serializer implementation in Rust. > . > It does not aim > to be the fastest or the more versatile JSON parser possible > but to be an as simple as possible implementation. > > This package is needed for oxigraph (bug#996504). > It will be maintained in the collaborative debian section of salsa, at > https://salsa.debian.org/debian/rust-json-event-parser > > - Jonas > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS1LsgACgkQLHwxRsGg > ASGuZxAAnGaRse4xNrc1A8yia/ZGZPbilR93QiVzblYfKtAvPp7sMUkpvjPhkdP6 > EEXdvcHUP72p/yQj6wmRzptLtDxNd6/K4V0DQpZj1wA11i3BJHiiX4udVqqBQlvQ > FpCgMw28c4VzYW84JGAYEb7Dqsd85U8rZLdpSmaZ+eAIzeRAjfoldLKn7wfoxZKk > iB/veI19T/oAHyRYnG1ptukLBexUvjxQxZczhr1/6e5Njk0glY1/oNLQ7ewv7NGS > 1Pcislx9jEsxPmtxGEzBifoV/H+2lYvir3HqNEx6pWF4BqiUEFDTfaRPUiQ/PsTQ > azbJNcZzSiRLKFw6dZzXqnAZgQCgicO4a8GEoBNDaRWlbe7PL9BidfshcOnKXX/i > 4x943xCCOhXSGCTrbIW2nwM8etz9QRXn7zmqHjCAH2arFPjRCv3E4dABhO1J/lP/ > sNnMwKNtljuAG++ucBkXaN0JYV4JSQGRoCocegDbjYQBOsDG7ARgEJyJBdPbBoIH > PF6HVgWCCvhJ9V8sEFy2/aY26ycfUzwKst7Qz80V35A3wyZMTrHQHs0A+dAVRhU1 > foxNCFRhUdO/4HDB7opVfyZ7hOuagRiv0ccxa/jKzMtduh6JMYQf291NyN08valq > yMTE83L5588OnZv/Z+AcRZQbtPOQZqyrqEEBtFTyo9qCUjtbUrk= > =oDlV > -END PGP SIGNATURE- > Date: Mon, 17 Jul 2023 21:55:33 +1000 > From: Hugh McMaster > To: Sven Joachim > Cc: debian-devel@lists.debian.org > Subject: Re: Proposed MBF: Removal of libfreetype6-dev > Message-ID: > < > sy6p282mb3236611881c1fec58f7f47b4f2...@sy6p282mb3236.ausp282.prod.outlook.com > > > Content-Type: text/plain; charset="UTF-8" > > Hi Sven, > > On Mon, 17 Jul 2023 at 01:13, Sven Joachim wrote: > > > > On 2023-07-16 22:38 +1000, Hugh McMaster wrote: > > > > > I will be removing the transitional packag
64-bit time_t: an update
Hi folks, Two months ago, I posted with a proposal for how to handle a transition to 64-bit time_t on 32-bit archs in the trixie cycle. https://lists.debian.org/debian-devel/2023/05/msg00168.html We have pretty good consensus on the path forward; however, at the time I posted I had hoped to have an archive analysis done within a month, so that this could be staged as the first major transition after trixie opened. This timeline proved to be very optimistic. The problem is that, to understand the impact that a change to the size of time_t will have on a library's ABI, it must be possible to compile the headers that expose that API; and we have a significant number of -dev packages in the archive that for one reason or another don't straightforwardly compile out of the box. The Ubuntu Foundations team have been putting in effort over the past two months, package-by-package, to figure out how to make them compile so that we know if their ABI is affected. However, despite a significant investment of effort, we still have roughly 1500 -dev packages still in need of analysis, and have sustained a rate of processing only around 50 -dev packages a week. The "good" news is that, although there are over 1500 -dev packages yet to be analyzed, we have prioritized libraries based on the number of reverse-dependencies and therefore these 1500 -dev packages have among them less than 300 reverse-build-dependencies that have not already been identified as part of the transition (800 of these -dev packages have no reverse-build-dependencies at all). Therefore, I would like to propose the following. - Assume the remaining 1500 -dev packages are affected by the ABI breakage. This will increase the number of library packages included in the transition requiring sourceful uploads from < 500 to 2000[1], but will only increase the number of packages requiring rebuilds from 5300 to 5600. - Agree a target window together with the Release Team for when the transition will be uploaded to unstable; and based on this, set a deadline beforehand for finalizing the list of library packages whose binary package names will be changed. - We in Ubuntu Foundations will continue on a best effort basis to drive down the list of -dev packages which cannot be analyzed, until that deadline. - Any party (maintainer or otherwise) interested in having some of these library packages excluded from the transition is welcome to contribute fixes up to that deadline that will let us analyze them and show that the ABI has not changed. Your thoughts? -- 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 [1] All numbers approximate: the analysis that has been completed so far has been done against Ubuntu lunar as a stable reference base. The Debian transition will of course be done based on a complete analysis of unstable, which is in progress separately. libgnome-rr-4-dev libhfsp-dev libhx-dev libibnetdisc-dev libip6tc-dev libipmiconsole-dev libipset-dev libisns-dev libisoburn-dev libixion-dev libjpeg-turbo8-dev libklibc-dev libkrad-dev libksba-dev liblasso3-dev libldacbt-abr-dev libldb-dev liblouisutdml-dev liblrm2-dev libmaa-dev libmircommon-dev libmiroil-dev libmirplatform-dev libmirwayland-dev libmlir-14-dev libmozjs-102-dev libmutter-11-dev libnetplan-dev libntirpc-dev libnutscan-dev liborcus-dev libotf-dev libpils2-dev libportal-dev libpskc-dev libptexenc-dev libpython3.10-dev libpython3.11-dev libradosstriper-dev libreoffice-dev libsource-highlight-dev libsss-certmap-dev libsss-simpleifp-dev libstdc++-11-dev libstdc++-12-dev libstonith1-dev libsysmetrics-dev libtotem-dev libunwind-14-dev libunwind-15-dev libusbredirhost-dev libuwac0-dev libverto-dev libvolume-key-dev libwhoopsie-dev libwhoopsie-preferences-dev lua-rrd-dev python3-ldb-dev python3-talloc-dev rhythmbox-dev ruby3.0-dev ruby3.1-dev samba-dev slapi-dev libblimps3-dev libfishcamp-dev libopenvr-dev libparmetis-dev libtestu01-0-dev libttspico-dev 389-ds-base-dev android-libandroidfw-dev android-libselinux-dev android-libsepol-dev android-libunwind-dev angelscript-dev atfs-dev cairo-dock-dev casacore-dev cauchy-dev codeblocks-dev coinor-libbonmin-dev coinor-libcbc-dev libfprint-2-tod-dev dovecot-dev irssi-dev isc-dhcp-dev libaal-dev libapache2-mod-perl2-dev bind9-dev libcanberra-gtk-common-dev libclc-14-dev libclc-15-dev libd3dadapter9-mesa-dev libdpkg-dev libfreeradius-dev libglvnd-core-dev libmirrenderer-dev libpinyin-common-dev libpolly-15-dev libradospp-dev libreiser4-dev libreofficekit-dev libubi-dev mir-renderer-gl-dev ocfs2-tools-dev php8.1-dev rados-objclass-dev remmina-dev zsh-dev libamgcl-dev libjulius-dev libthrust-dev notion-dev ableton-link-dev android-libbase-dev android-libcutils-dev android-lib
Bug#1041509: ITP: gitui -- blazing fast terminal-ui for git
Package: wnpp Severity: wishlist Owner: Johann Felix Soden X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : gitui Version : 0.23.0 Upstream Contact: extrawurst * URL : https://github.com/extrawurst/gitui * License : MIT Programming Lang: Rust Description : blazing fast terminal-ui for git gitui is a blazing fast terminal-ui for git with following features: - Fast and intuitive keyboard only control - Context based help (no need to memorize tons of hot-keys) - Inspect, commit, and amend changes - Stage, unstage, revert and reset files, hunks and lines - Stashing (save, pop, apply, drop, and inspect) - Push/Fetch to/from remote - Branch List (create, rename, delete, checkout, remotes) - Browse commit log, diff committed changes - Scalable terminal UI layout - Async git API for fluid control - Submodule support
Re: 64-bit time_t: an update
On Wed, 19 Jul 2023 at 14:27:21 -0700, Steve Langasek wrote: > to understand the impact that a change to the size of > time_t will have on a library's ABI, it must be possible to compile the > headers that expose that API Would the results of this analysis also be suitable for telling interested maintainers whether it's safe to opt-in a library to LFS and/or 64-bit time_t on i386, so that it will use 64-bit-time_t-safe glibc functions internally? (For example libdbus is already opted-in to LFS, and I'm reasonably sure it doesn't break public ABI under 64-bit time_t either, because it has a policy of avoiding most inclusions of system headers in its own public API) > The Ubuntu Foundations team have been putting in effort over the past two > months, package-by-package, to figure out how to make them compile so that > we know if their ABI is affected. Is there a reasonably simple way that interested developers can try this process for a package that they maintain? I realise your analysis has been done on armhf, but i386 would probably be an easier (and faster!) 32-bit architecture to deal with for many developers, even though we don't intend to do the 64-bit time_t transition systematically on i386. > The "good" news is that, although there are over 1500 -dev packages yet to > be analyzed, we have prioritized libraries based on the number of > reverse-dependencies Is the list you attached already in descending order by number of rdeps? > libsdl1.2-compat-dev The source package src:sdl12-compat recently took over libsdl1.2-dev and libsdl1.2debian from the older src:libsdl1.2, which gives it quite a lot of rdeps (I know because I did a mass bug filing for them!), so having an answer for that one might reduce the rebuilds better than you might think. I suspect it actually won't have time_t in its ABI, although I could be wrong. smcv
