Bug#1061368: ITP: gnome-prompt -- terminal for GNOME
Package: wnpp Severity: wishlist Owner: Gürkan Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: gnome-prompt Version : 46~alpha Upstream Authors: Christian Hergert URL : https://gitlab.gnome.org/chergert/prompt * License : GPL-3.0-or-later Description : terminal for GNOME This is a terminal for GNOME with first-class support for containers. Contrary to gnome-terminal this supports transparent backgrounds. This is to be maintained inside the GNOME-team in Debian.
Bug#1061367: ITP: loki-ecmwf -- Source-to-source code translator for Fortran
Package: wnpp Severity: wishlist Owner: Alastair McKinstry X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: loki-ecmwf Version : 0.1.6 Upstream Contact: Michael Lange (michael.la...@ecmwf.int) * URL : https://github.com/ecmwf-ifs/loki * License : Apache-2 Programming Lang: Python Description : Source-to-source code translator for Fortran Loki is an experimental tool to explore the possible use of source-to-source translation for ECMWF's Integrated Forecasting System (IFS) and associated Fortran software packages. Loki is based on compiler technology (visitor patterns and ASTs) and aims to provide an abstract, language-agnostic representation of a kernel, as well as a programmable (pythonic) interface that allows developers to experiment with different kernel implementations and optimizations. The aim is to allow changes to programming models and coding styles to be encoded and automated instead of hand-applying them, enabling advanced experimentation with large kernels as well as bulk processing of large numbers of source files to evaluate different kernel implementations and programming models. This software is now in use beyond ECMWF, and I intend to work and develop it with other Fortran environments in Debian. I intend to maintain it within Debian Science team as part of the Meteorology stack. As Loki is a pre-existing name in Debian, I intend to follow convention and rename the package loki-ecmwf.
Re: Bug#1061336: ITP: chatterino -- Chatterino is a chat client for Twitch chat. It aims to be an
Hi, On 1/23/24 05:25, matt wrote: * Package name: chatterino I might be interested in that. - I plan on maintaining it by compiling the latest package or use the deb they provide, inside a packaging team 🤔 I would need a need a sponsor I currently have a 60 hour workweek, so I can sponsor packages if that is low enough effort for me. To be blunt, "us[ing] the deb they provide" sounds like you are not all that familiar with packaging and package maintenance, so this would require a lot more mentoring than I can currently provide. What is the current state of your packaging efforts, is anything online that I can take a look at? Simon
Bug#1061336: ITP: chatterino -- Chatterino is a chat client for Twitch chat. It aims to be an
Package: wnpp Severity: wishlist Owner: matt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: chatterino Version : 2.4.6 Upstream Author : https://github.com/chatterino/chatterino2 * URL : https://chatterino.com/ * URL : * License : (MIT) Programming Lang: (C++) Description : Chatterino is a chat client for Twitch chat. Chatterino is a chat client for Twitch chat. It aims to be an improved/extended version of the Twitch web chat. - this package is useful to me because I don't need to open the browser to look at chat, it does not have dependencies for any other packages, I use it, gnome-twitch has similar functionality but is unmaintained and lacks features that chatterino has example banning seeing certain emotes, - I plan on maintaining it by compiling the latest package or use the deb they provide, inside a packaging team I would need a need a sponsor
Re: 64-bit time_t: package lists, counts du jour, dd-list for NMUs
On 2024-01-22, Simon McVittie wrote: > Unfortunately, perhaps because common build systems like Autotools, > Meson and CMake make it awkward to use non-numeric SONAME suffixes, With CMake it is actually quite simple. Even to a point where it is easy to get wrong: add_library(Foo SHARED foo.cpp) set_target_properties(Foo PROPERTIES VERSION 1vorlon.0.0 SOVERSION 1smcv) $ objdump -x libFoo.so | grep SONAME SONAME libFoo.so.1smcv ls: libFoo.so -> libFoo.so.1smcv libFoo.so.1smcv -> libFoo.so.1vorlon.0.0 libFoo.so.1vorlon.0.0 /Sune
Re: 64-bit time_t: package lists, counts du jour, dd-list for NMUs
On Mon, 22 Jan 2024 at 05:31:45 -0800, Steve Langasek wrote: > Others in this list have package names I don't understand, such as a 'd' > suffix that doesn't correspond to anything in the soname I believe this is conventionally used to mean "this is a Debian-specific SONAME that intentionally differs from upstream's ABI", either because the upstream project doesn't support building a shared library at all, the upstream builds a shared library but breaks the ABI without bumping the SONAME (and resists attempts to fix this upstream), or there is ABI added/removed in Debian delta. Ideally this would be addressed with an "upstream first" approach, or failing that, it should genuinely be part of the SONAME, as in e.g. libstemmer0d (which is static-only upstream, and Debian patches the build system to produce a libstemmer.so.0d shared library) and libleveldb1d (I haven't checked the history, but presumably it's similar). For packages in the libstemmer0d situation, since the ABI is Debian-specific *anyway*, the right route is perhaps to bump the SONAME to libstemmer.so.0d1 or libstemmer.so.1d and handle it like a normal transition? Unfortunately, perhaps because common build systems like Autotools, Meson and CMake make it awkward to use non-numeric SONAME suffixes, there are also libraries that use the 0d suffix but *don't* include the "d" in the SONAME, for example libcdd0d (libcdd.so.0). Looking at the cddlib (libcdd0d) changelog, it seems that 0d is a little misleading in this case, because the ABI is *not* Debian-specific: * Renamed libcdd0 to libcdd0d. The ABI changed since the last package, but upstream started using the SONAME 0 now. Since the package is not widely used, changing the package name, but not the SONAME, is enough. For the libcdd0d situation, it's "the same shape" as a toolchain ABI suffix like v5 or t64, so a rename to libcdd0t64 would probably be right (if this package is affected by 64-bit time_t, which I haven't checked). Another convention that is sometimes used if upstream doesn't really handle ABI breaks the way we would want, and there is a manageably small number of dependent packages in Debian, is to package the library libfoo.so.0 as libfoo0, then libfoo0a, libfoo0b, and so on. This is difficult to distinguish from the "0d" conventions above, if the ABI happens to have been broken exactly 4 times. Examples of this include libharfbuzz0b, libgjs0g, libcryptui0a. Again, for the libharfbuzz0b case, it's "the same shape" as a toolchain ABI suffix like v5 or t64, so a rename to libharfbuzz0t64 would probably be right (if this package is affected by time_t at all). > or libcoin80c Unfortunately the changelog just says "Renamed package dropping v5 suffix to c", without explaining why. Since this used libcoin80v5 for the libstdc++ v5 transition, I would guess that libcoin80t64 could be the right name for it now? But its maintainers would know better. smcv
Re: 64-bit time_t: package lists, counts du jour, dd-list for NMUs
In exercising scripts for the mass NMUs in a dry run, I've run into another little snag. $ grep -vEc '[0-9](c102|c2|g|ldbl|v5)?$' reports/runtime-libs 234 $ The package rename handling assumes that the affected runtime library packages have names matching a certain pattern (ends in a digit, plus a possible previous ABI qualifier). But 234 of the library patches don't match this pattern; some don't correspond to library sonames at all. Right off the bat, the first of these is 389-ds-base-libs. I don't want to rename it to '389-ds-base-libst64'. Also it turns out that there are no reverse-dependencies of this lib package. So I will omit this package from the transition. Others in this list have package names I don't understand, such as a 'd' suffix that doesn't correspond to anything in the soname, or libcoin80c. libdmtx0b and libvibrant6b at least have explanations in the changelog. So I guess I'll work on fleshing out a rename map for these. On Sun, Jan 21, 2024 at 12:57:17AM -0800, Steve Langasek wrote: > Hello, > > Here is an updated analysis of the transition. This is based on a full > rerun on Debian unstable as of 2024-01-17 and includes a number of > incremental fixes reducing the number of libraries to be transitioned. > Though this is not particularly significant; the number of source packages > to be NMUed drops from 1197+51=1248 to 1192+50=1242, and the number of > source packages to be binNMUed drops from 5442+170=5610 to 5415+170=5585. > > It also picks up a small number of source packages (5) that are new to > unstable since last month. I have no strong opinion about forcing a package > name change for these, since they likely don't have any reverse-dependencies > yet with a significant install base on 32-bit archs; but by default they're > included. > > > Output files from the new analysis can be found here: > > https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/ > > I am not making the same mistake as before and attempting to attach all of > the various supplementary files, thus hitting email size limits. Instead, I > have pushed them all to: > > https://people.canonical.com/~vorlon/armhf-time_t/ > > > You may have noticed that it is now past the original proposed date of > 2024-01-18. This was a knowingly aggressive target date on which to try to > converge; there are still discussion subthreads in flight on debian-devel > that I want to make sure settle out before we proceed, and also Guillem let > me know there was a dpkg upload planned that would conflict, pushing this > back to Monday, 22 Jan at minimum. Based on capacity and availability, I > would like to now start uploads to experimental this Friday, 26 Jan. > > I do not know how long it will take to build all 1200+ source packages and > upload them. I assume it will take a few days at least. Once the > transition has started, I will post again to debian-devel with projections > of when we might expect to start landing changes in unstable. > > Attached is the current dd-list for the packages that would have sourceful > NMUs. -- 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: Maintainers needed for debtags.debian.org
On Sun, Jan 21, 2024 at 10:52:02AM +0100, Jonas Smedegaard wrote: > I can offer to maintain hosting and packaging of debtags code projects. > Would that be helpful, or are/were you looking for new code maintainer? Thank you for your interest! Personally I am not motivated to look after Debtags anymore in any capacity. I see it similar to the old menu system: while interest in it is not strictly zero, I consider it fringe enough that it's not worth my effort to keep going. At the moment things are such that it's taking ages for me to even shut it down, because it would require me to prioritize an afternoon over many other things that have a higher priority for me at the moment. So, if you want to take over the whole leadership of the project, feel free and I'll request that you have access to the Debtags group, maintain the deployed codebase on debtags.debian.org, upload tag updates, and so on, and I can answer some questions on how things work at the moment, and wish you better luck than mine with it. Its design can certainly be downscaled furthermore into something that may keep alive goplay-like use cases. Otherwise, any course of action that means that Debtags is still primarily my problem is not the course of action that I'd like to take. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: X-Windows on PPC in Debian SID
On Sun, 21 Jan 2024 at 17:14:11 -0700, Stan Johnson wrote:
> The bottom line is that there appears to be a dependency issue in Debian
> SID at the moment
You can't *necessarily* draw this conclusion from a failure to
upgrade. You are using powerpc, which is a "ports" architecture that is
not really part of the Debian release process any more:
The last supported release for 32-bit PowerPC is Debian 8 ("jessie").
— https://www.debian.org/ports/powerpc/
For reference, Debian 8 "jessie" reached end-of-life in 2018.
powerpc enthusiasts continue to compile packages from the unstable (sid)
rolling release on powerpc, but "ports" architectures are not supported by
the Debian project as a whole. The mailing list for the big-endian powerpc
and ppc64 ports (and the little-endian ppc64el architecture, which *is*
supported) is debian-powerpc.
It is common for potentially large categories of packages to be temporarily
uninstallable in unstable, particularly in "ports" architectures, and you
cannot expect upgrades to go smoothly at all times. I would personally
suggest using an interactive apt user interface like aptitude to get a
better idea of what depends on what and why.
> that makes wdm (and other X-Windows packages such as
> the Xorg server) dependent on systemd, even if systemd is already
> installed, regardless of whether systemd is being used as the init
systemd is the default init system in Debian, and also provides the
default implementation of several other important systemd services
like logind. If you have chosen not to use systemd, you can expect
that you will have to take steps to select other non-default packages
(for example dbus-x11 instead of dbus-user-session, and libpam-elogind
instead of libpam-systemd). apt will not necessarily be able to do this
automatically.
Trying this on amd64, it appears that the problem you encountering is
probably that libelogind, elogind's partial replacement for libsystemd,
does not appear to provide all of the functions required by the current
versions of important packages like procps: procps currently requires
libsystemd0 (>= 254), and libelogind only provides a replacement for
version 252. I've reported this libelogind limitation as a bug in
elogind.
smcv
