Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi Steve On 2024-01-05 20:26:56 -0800, Steve Langasek wrote: > On Fri, Jan 05, 2024 at 09:32:28PM +0100, Sebastian Ramacher wrote: > > On 2024-01-05 11:06:09 -0800, Steve Langasek wrote: > > > On Fri, Jan 05, 2024 at 06:53:50PM +0100, Sebastian Ramacher wrote: > > > > Hi Steve > > > > > > - perl will also get a sourceful upload, to manually handle 'perlapi' > > > > > Provides. > > > > > Can we combine this one with the upcoming perl transition? See #1055955. > > > > Pros and cons of combining: > > > > - it will save another rebuild of perl modules > > > - new perl upstream versions usually break at least some > > > reverse-dependencies in the archive, so this may slow down the time_t > > > transition to testing for other packages by entangling it with sourceful > > > perl changes. > > > > The release team has already suggested not entangling the two. > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055955#10 > > > That was two months ago and we were expecting some progress. There was > > however none so far. > > Sorry, what were you expecting exactly? I've had no communication from the > Release Team until now about expectations, including on the debian-devel > thread back in July. Sorry for being unclear. My comment was related to the perl transition. Perl 5.38 will start (ACKed yesterday, it was blocked on our side) before this one and we try to complete it before starting time_t. > > As perl 5.38 is already staged in exeperimental, there are only two > > options: time64_t waits until perl 5.38 is done or we entangle them. > > Rene and Paul raise this concern as well. However, there is another option. > > For any packages involved in this transition which currently have new > versions staged in experimental which are not yet ready to go to unstable, > we can simply exclude them from the upload to experimental, and do the > NEW processing for this subset of packages directly in unstable as part of > the second step. Sounds good to me (provided FPT master are happy to fast track those uploads). > > > > > 22 libobs-dev > > > > > That's a change to the plugin ABI only. > > > > Can you explain how you've reached that conclusion? This is a package > > > that failed to be analyzed in the latest run; an earlier run against > > > Ubuntu lunar showed no change in ABI at all. > > > libobs-dev and the shared library are an oddity of obs-studio. There > > only purpose is to build plugins. > > Ok, but it appears there are a large number of reverse-dependencies on > libobs0 from other source packages, and there is no OTHER encoding of > information about plugin ABI aside from this (no Provides: field on > obs-studio). So what do you suggest here with respect to ABI skew between > obs-studio and its plugins on armhf? I need some more time to check the current situation. > > > > > 9 libopenmpt-dev > > > > > Seems to be a false positive. > > > > > > > > Your responses here are to the contents of the `sorted-revdep-count` list. > > > This is the list of header packages that *we were unable to analyze with > > > abi-compliance-checker*, and so in the interest of avoiding ABI mismatches > > > and broken systems for users when upgrading on 32-bit archs, would get a > > > package rename to be safe. > > > > This is the plan I had outlined at: > > > > https://lists.debian.org/debian-devel/2023/07/msg00232.html > > > > I am happy for any help in the form of patches to > > > https://salsa.debian.org/adrien-n/armhf-time_t that fix the failures of > > > these header packages to be analyzed, or explanations for how a given > > > header > > > package's API changes cannot affect the ABI of the runtime libraries from > > > the source package so that we can manually exclude those libraries from > > > the > > > transition. I am not sure I would *recommend* that maintainers spend a > > > lot > > > of time on proving one or another individual library does not have an ABI > > > breakage, especially in the long tail of libraries with few > > > reverse-dependencies whose involvement in the transition is unlikely to > > > substantially slow down Debian development. I was looking at the repo but it is unclear to me how packages that can be skipped are handled there. What would a PR look like to exclude specific packages? > > > > Change to vlc plugin ABI. This does not require a change of the binary > > > > package name. > > > > There are other reverse-dependencies of libvlccore9 in the archive that > > > are > > > not VLC plugins (phonon4qt5-backend-vlc etc). Are these packages simply > > > mis-linked against that library? > > > No, they are not. The part that changes is exclusiv to plugins. I will > > deal with this change by updating the vlc-plugin-abi-$x Provides. > > This further reduces the count of reverse-dependencies needing rebuilt from > 5452+177 to 5450+178. A net gain of 1 package as a result of you handling > this manually instead for the plugin abi, and it's not even > p
Re: DebGPT: how LLM can help debian development? demo available.
Am Wed, Jan 03, 2024 at 01:06:25PM +0100 schrieb Andrey Rakhmatullin: > On Wed, Jan 03, 2024 at 11:33:06AM +0200, Andrius Merkys wrote: > > On 2024-01-03 11:12, Andrey Rakhmatullin wrote: > > > On Wed, Jan 03, 2024 at 09:58:33AM +0200, Andrius Merkys wrote: > > > > To me the most time consuming task in Debian recently is the Python > > > > transitions. I wonder whether DebGPT could help with them. Maybe there > > > > are > > > > other, non-Debian-specific GPTs for this task, but I would prefer a > > > > Debian > > > > one. > > > As "transitions" is too broad, can you list actual problems you spend time > > > on for them? > > > > Mostly failing tests, and mostly due to API changes between subsequent > > Python 3.x versions. > So the solution is either find a patch in the upstream repo (committed or > proposed in issues/PRs) or write one yourself. Not sure what can AI help > here with. Well, may be people replacing 'assertEquals' by the new name 'assertEqual'[1] could talk with some GPT first how much work all their downstreams might have due to this kind of estetic changes to find patches? In the last year I've seen quite some changes which do not obviously serve any better purpose than fitting some esthetics pattern breaking some API. (The s/assertEquals/assertEqual/ one is not the only example.) Kind regards Andreas. [1] https://salsa.debian.org/python-team/packages/pypandoc/-/blob/debian/master/debian/patches/0005-Python3.12.patch?ref_type=heads -- http://fam-tille.de
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Mon, 08 Jan 2024 at 15:01:11 -0800, Steve Langasek wrote:
> If a maintainer ignores the NMU and drops the rename, they'll be introducing
> a new library transition again on 32-bit archs. Won't they also be caught
> again in binary NEW, for those packages that don't have the same runtime
> library package name in experimental?
To have a concrete example of this, I think you are saying:
- NMU of src:foo renames libfoo0 to libfoo0t64
- maintainer ignores NMU and uploads, effectively renaming libfoo0t64
back to libfoo0
- you want the maintainer's upload to get stuck in NEW
I am not a ftp team member, but if I understand NEW correctly, this
will only trigger a new trip through NEW if the ftp team have already
removed libfoo0 from the overrides file ("decrufting"), which is not
done immediately, only after libfoo0 has not been built by src:foo for
a little while.
If libfoo0 exists in testing and/or stable, I'm not sure whether that
prevents the ftp team's processes from removing it from the overrides file.
If it does, then a new, maintainer upload of libfoo0 will certainly not be
considered NEW, and the safety-catch that you are thinking of will not be
effective.
smcv
Bug#1060312: ITP: node-yarn-plugin-apt -- Yarn plugin to resolve dependencies from packages installed in apt
Package: wnpp Severity: wishlist Owner: Robinson Uchechukwu X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-yarn-plugin-apt Version : 1.0.0 Upstream Author : Debian JavaScript Team * URL : https://salsa.debian.org/js-team/yarn-plugin-apt * License : Expat Programming Lang: JavaScript Description : Yarn plugin to resolve dependencies from packages installed in apt This yarn plugin allows apt installed packages satisfy a nodejs project's dependencies. The package is a valuable addition to Debian because if facilitates the management of nodejs projects dependencies by leveraging locally avaliable apt-installed packages . Node.js is an event-based server-side JavaScript engine.
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Mon, Jan 08, 2024 at 03:01:11PM -0800, Steve Langasek wrote: > On Fri, Jan 05, 2024 at 09:17:52PM +0100, Paul Gevers wrote: > > On 05-01-2024 17:36, Rene Engelhard wrote: > > > Also a problem is that experimental also might already contain totally > > > unrelated updates like new upstream versions... > > > I share this worry. Have you thought about how to handle the cases where you > > don't have experimental to upload to? How big is this problem? > > > Another worry, how will you provide the required changes to the maintainers > > of the packages? Via BTS? For those working on salsa: MR? Both? Something > > else? Obviously we should not end in the situation that a new upload goes > > back to the old name (or are the ftp-masters so keen on this transition that > > that won't happen? But what about newer versions with the old name already > > in experimental, conform the former worry?). I've seen NMU's being ignored > > by subsequent uploads by the maintainer, even when they fixed RC issues > > which were then reintroduced. > > I would intend to provide diffs via the BTS. This remains the standard > policy for NMUs in Debian per the Developer's Reference, and as far as I > know has worked effectively for all such previous ABI transitions. In the current situation, though, not having experimental available means that there's no opportunity for dumat to weigh in regarding usrmerge interactions, which seems problematic given Helmut's preliminary analysis. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1060319: ITP: sdl2-compat -- SDL 2 binary compatibility library wrapping SDL 3
Package: wnpp Severity: wishlist Owner: Simon McVittie X-Debbugs-Cc: debian-devel@lists.debian.org, debian-devel-ga...@lists.debian.org, pkg-sdl-maintain...@lists.alioth.debian.org * Package name: sdl2-compat Version : currently 2.28.50~git20240108 Upstream Contact: https://github.com/libsdl-org/sdl2-compat/issues * URL : https://github.com/libsdl-org/sdl2-compat * License : mainly Zlib, with various other permissive licenses Programming Lang: C Description : SDL 2 binary compatibility library wrapping SDL 3 sdl2-compat provides a binary compatible API for programs built against SDL 2, but using SDL 3. . If you are writing new code, please target SDL 3 directly (when it becomes stable) instead of using this layer. Debian packages should not depend or build-depend on this package: please use libsdl2-2.0-0 and libsdl2-dev instead. --- ITP on behalf of the SDL team, with much of the packaging and testing being done as part of my work at Collabora Ltd. A prerelease version is here: https://salsa.debian.org/sdl-team/sdl2-compat SDL 3 (in experimental) is not yet API- or ABI-stable, so "real" SDL 2 (src:libsdl2) continues to be the recommended runtime library for SDL games and other applications for now. When SDL 3 and sdl2-compat become stable, we will want to replace "real" SDL 2 with sdl2-compat (it's a drop-in replacement), the same way "real" SDL 1.2 was replaced with sdl12-compat after the Debian 12 release. I expect that SDL upstream will eventually stop producing new releases of "real" SDL 2 at all, and expect all SDL 2 users to replace it with sdl2-compat, the same way they already discontinued "real" SDL 1.2. Until we're ready for that transition, the sdl2-compat packaging will be very similar to the way sdl12-compat was packaged in Debian 12, with the main package being a non-default library that can be substituted via the SDL_DYNAMIC_API or LD_LIBRARY_PATH environment variables. As with SDL3, I want to get this into experimental well before it is ready for production use, so that it isn't too late to feed back test results and structural change suggestions to upstream.
Bug#1060341: ITP: kvazaar -- Kvazaar is an open-source HEVC encoder
Package: wnpp Severity: wishlist Owner: Joachim Bauch X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: kvazaar Version : 2.2.0 Upstream Author : Ari Lemmetti, Marko Viitanen, Alexandre Mercat, Jarno Vanne * URL : https://github.com/ultravideo/kvazaar * License : BSD 3-Clause Programming Lang: C, C++, ASM Description : Kvazaar is an open-source HEVC encoder Kvazaar is an award-winning academic open-source video encoder for the state-of-the-art High Efficiency Video Coding (HEVC/H.265) standard developed since 2012. Kvazaar is being developed in C and optimized in SSE/AVX intrinsics under the BSD-3-Clause license since v2.1. The development is being coordinated by Ultra Video Group and the implementation work is carried out on GitHub. The main development goals of Kvazaar are: - Coding efficiency close to HM - Easy portability to various platforms - Real- time coding speed - Optimized computation and memory resources Kvazaar includes all coding tools of Main, Main 10, and Main Still Picture profiles of HEVC and its modular source code facilitates parallelization on multi and manycore processors as well as algorithm acceleration on hardware. This cross-platform HEVC encoder is targeted at x86, x64, PowerPC, and ARM processors on Windows, Linux, and Mac. Kvazaar is also supported by de-facto standard multimedia frameworks FFmpeg and Libav. My main motivation for packaging Kvazaar is to be able to use it from the corresponding libheif plugin, but it could also be used by FFmpeg and Livav. A similar package would be x265 which is GPL licensed where Kvazaar uses BSD license. Kvazaar is faster than x265 for various inputs. I'm planing to maintain it from the Multimedia Team which I'm already a member of. For the first release I will need a sponsor, but I'm planning to apply to become a DD in the near future, so hopefully at that point I can maintain it without external help. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: DebGPT: how LLM can help debian development? demo available.
Hi! I've noticed that the most recent LLMs are actually very good at finding information, summarizing and giving code examples about Debian already without extra training. One just needs to double check that the answer was correct to not fall for when they are simply making up plausible sounding stuff. However, checking if an answer is correct is much faster than figuring it out something from scratch. Anyone can test it for themselves at https://chat.lmsys.org/ - no registration required, just participate in the research by reading the replies from two LLMs and telling the leaderboard which reply you think was better. Knowing there is so much repetitive petty work involved in Debian package maintenance that drains a of energy both from current and aspiring maintainers I have been skimming the README at https://salsa.debian.org/deeplearning-team/debgpt with high hopes for DebGPT to evolve over time. It would be great if there was a LLM with enough logic and context that it could do things like Lintian-brush (or even go all the way like Janitor and start filing MRs on Salsa for humans to review/finalize).
Static analyzer / linter for debian/rules?
Hi! Is anybody aware if there is some kind of static analyzer for the `debian/rules` file? I can do very basic syntax checking with `make --dry-run --makefile=debian/rules` which will error on serious syntax errors (which I already implemented in my CI workflow[1]). However, that or a general Makefile tool such as checkmake[2] or unmake[3] do not help much as the debian/rules is very Debian specific. Lintian has some checks for debian/rules contents, but it can't be run on a single debian/rules file or even the debian/ directory directly.[4] I occasionally come across simple syntax issues which a static analyzer / linter could easily pick up so I was wondering if it could be automated. For example in one case[5] exporting DPKG_GENSYMBOLS_CHECK_LEVEL did not take effect due to easily detectable incorrect (but not fatal) syntax. - Otto [1] https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/b1f1640d414e2c7631cdccbb7f5445a4b8ad56e4 [2] https://github.com/mrtazz/checkmake [3] https://github.com/mcandre/unmake [4] https://bugs.debian.org/262783 [5] https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/f2fe8d8300642c373ce325f19d1100d79adeed45
