Bug#1060045: ITP: golang-github-jamiealquiza-envy -- expose environment variables for Go flags (library)
Package: wnpp Severity: wishlist Owner: Maytham Alsudany X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org Control: block 1059994 by -1 * Package name: golang-github-jamiealquiza-envy Version : 1.1.0 Upstream Contact: Jamie Alquiza * URL : https://github.com/jamiealquiza/envy * License : Expat Programming Lang: Go Description : expose environment variables for Go flags (library) Envy automatically exposes environment variables for all of your Go flags Envy takes a namespace prefix that will be used for environment variable lookups. Each flag registered in your app will be prefixed, uppercased, and hyphens exchanged for underscores; if a matching environment variable is found, it will set the respective flag value as long as the value is not otherwise explicitly set (see usage for precedence). Dependency of cam2ip. Will be maintained within the Go team, and will need a sponsor. -- Kind regards, Maytham Alsudany signature.asc Description: This is a digitally signed message part
Re: Bug#1060034: ITP: python-openai -- OpenAI Python API library
On Thu, 2024-01-04 at 21:30 -0500, Mo Zhou wrote: > Dependency of DebGPT. Will be maintained by deep learning team. > It will go to the contrib section based on policy section 2.2.2, > because this API client requires either > (1) paied access to the proprietary backend > (2) compatible open-source backend implementations are not yet > available in the archive. I'm confused. Will this package have a "Depends: some-proprietary- openai-thing"? Can't it talk to a web service providing the API? Does OpenAI even offer this "some-proprietary-openai-thing" package to the general public? Ansgar
Bug#1060048: ITP: golang-github-korandiz-v4l -- facade to the Video4Linux video capture interface (library)
Package: wnpp Severity: wishlist Owner: Maytham Alsudany X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org Control: block 1059994 by -1 * Package name: golang-github-korandiz-v4l Version : 1.1.0 Upstream Contact: 2016 Zoltán Korándi * URL : https://github.com/korandiz/v4l * License : GPL-3+ Programming Lang: Go Description : facade to the Video4Linux video capture interface (library) Package v4l is a facade to the Video4Linux video capture interface. Dependency of cam2ip. Will be maintained within the Go team, and will need a sponsor. -- Kind regards, Maytham Alsudany signature.asc Description: This is a digitally signed message part
Bug#1060049: ITP: golang-github-pbnjay-pixfont -- pixel font package for Go (library)
Package: wnpp Severity: wishlist Owner: Maytham Alsudany X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-pbnjay-pixfont Version : 0.0~git20200714.33b7446 Upstream Contact: https://github.com/pbnjay/pixfont/issues * URL : https://github.com/pbnjay/pixfont * License : Expat Programming Lang: Go Description : pixel font package for Go (library) pixfont is a simple, lightweight Pixel Font package for Go that works with the standard image/draw package. Dependency of cam2ip. Will be maintained within the Go team, and will need a sponsor. -- Kind regards, Maytham Alsudany signature.asc Description: This is a digitally signed message part
Re: Question regarding uscan check on UDD
On Tue, Jan 02, 2024 at 10:22:29PM -0800, Xiyue Deng wrote: > I noticed a discrepancy of the uscan @ANY_VERSION@ substitute string on > UDD and locally on my bookworm system. That's because UDD is running on bullseye, not on bookworm, with bullseye-backports' version of devscripts (which really really I should go back to work on and update…) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Bug#1060034: ITP: python-openai -- OpenAI Python API library
On 1/5/24 03:48, Ansgar wrote: On Thu, 2024-01-04 at 21:30 -0500, Mo Zhou wrote: Dependency of DebGPT. Will be maintained by deep learning team. It will go to the contrib section based on policy section 2.2.2, because this API client requires either (1) paied access to the proprietary backend (2) compatible open-source backend implementations are not yet available in the archive. I'm confused. Will this package have a "Depends: some-proprietary- openai-thing"? Can't it talk to a web service providing the API? No. All the dependencies are: python3-anyio,python3-distro, python3-httpx,python3-pydantic,python3-sniffio,python3-tqdm, python3-typing-extensions,python3:any. Can be satisfied using packages from main section. That said, this package does not work at all without (1) paid access token from OpenAI (2) open-source alternative https://github.com/lm-sys/FastChat/blob/main/docs/openai_api.md One just need to export OPENAI_BASE_URL or set it in program as openai.base_url = '...' to switch the server to connect. It is a client API package, and its compatible Does OpenAI even offer this "some-proprietary-openai-thing" package to the general public? No. They provide nothing else than this API client.
Bug#1060068: ITP: python3-asn1 -- Simple ASN.1 encoder and decoder for Python
Package: wnpp Severity: wishlist Owner: Jérémy Lal X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team * Package name: python3-asn1 Version : 2.7.0 Upstream Contact: Sebastien Andrivet * URL : https://github.com/andrivet/python-asn1 * License : Expat Programming Lang: Python Description : Simple ASN.1 encoder and decoder for Python This pure Python library features: * a BER decoder * a DER decoder and encoder (except indefinite lengths) This package has still an active upstream (contrary to pyasn1), and is a dependency of awx. Its maintenance will be done inside python-team.
Bug#1060071: ITP: libjs-jush -- JavaScript Syntax Highlighter
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: libjs-jush Version : 2.0.2+git20210206+1 Upstream Contact: Jakub Vrana * URL : https://jush.sourceforge.io/ * License : Apache-2.0 Programming Lang: JavaScript Description : JavaScript Syntax Highlighter JavaScript Syntax Highlighter can be used for client-side syntax highlighting of following languages: HTML, CSS, JavaScript, PHP, SQL, HTTP and SMTP protocol, php.ini and Apache config. This is required to build the database web interface adminerevo (ITP #1055329). This has been embedded in src:adminer for years. Part of it is available in src:jquery-goodies .
Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi! [ It seems the original post didn't get through to debian-devel (yet?), I found it on debian-release though https://lists.debian.org/debian-release/2024/01/msg00033.html, you might want to repost it here though, so that it can be commented on properly? :) ] On Fri, 2024-01-05 at 00:23:00 -0800, Steve Langasek wrote: > On Fri, Jan 05, 2024 at 12:17:04AM -0800, Steve Langasek wrote: > > == Results == > > > > The overall findings of this analysis are 1,745 "dev" packages which either > > are confirmed to have ABI changes or could not be checked; mapping to 2,154 > > runtime libraries (list attached) from 1,195 source packages (list attached) > > and 5,477 reverse-dependencies requiring no-change rebuilds (list attached). > > This is within the previously calculated range of "5300 to 5600", but there > > are a number of newly-identified packages that fail to compile and have a > > large number of reverse-dependencies. I will continue to work to identify > > false-positives here in the hopes of bringing this count down before pulling > > the trigger on an actual transition. > Guillem Jover >libaio >libmd >liburing I checked these, and it looks like libmd and liburing are false-positives? * libmd uses AC_SYS_LARGEFILE, and on 32-bit arches it is already built with LFS, the problem is that the header exposes off_t which means the code linking against it needs to match its build flags, otherwise they would already be broken now. You might want to look into this as a potential pattern for other false-positives probably. (I should probably update upstream the .pc file to include the -D_FILE_OFFSET_BITS=64 flags if enabled, but I don't think the analysis used .pc files anyway.) * liburing is marked as LFS-sensitive, but that comes from inline functions using off_t which end up casting that into an u32 type, so I don't think this should affect the ABI. It is also forcibly built with -D_FILE_OFFSET_BITS=64 in the upstream build system (and with future=+lfs for good measure in the packaging, which I'll switch to abi=+lfs). Thanks, Guillem
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi,
Am 05.01.24 um 09:17 schrieb Steve Langasek:
- Packages that could not be analyzed for whatever reason are still
assumed to have an ABI that's sensitive to time_t and have to be included
in the transition. Happily, due to improvements in this run of the number
of packages that could successfully be analyzed, the number of libraries
in this category has dropped from 1541 to 929, of which 69 have no
reverse-dependencies at all. The final list of these header packages that
could not be analyzed is attached, in case anyone still wants to identify
that a library on this list whose ABI is not affected by time_t and should
therefore be excluded from the transition. Note, however, that no effort
has been made to filter out dev packages from this list that come from
source packages containing OTHER dev packages that are known to have ABI
breakage; for a number of the packages listed, further analysis would not
change the outcome. (e.g. qt5-qmake failed to be analyzed, but
qtbase-opensource-src also ships qtbase5-private-dev which shows time_t
ABI sensitivity.)
[...]
My strawman proposal is to give this thread 2 weeks from today for feedback
and further refinement, and also to further reduce the number of
false-positives included in the transition. Then, starting on Jan 18:
- dpkg will be uploaded to experimental with 64-bit time_t in the default
flags
I think at that point in time one should know what breaks and whatnot.
Archive rebuild?
(Probably in stages)
- the source packages which need an ABI change
("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to
I get that you probably want NMUs for not needing to ping every
maintainer, but this is bad.
That e.g. would cause me to upload libreoffice 24.2 rc2 to sid
immediately when tagged end of next week to not have this caught in the
transition. (see also below for the comment about new upstream versions
in experimental.)
experimental with the new binary package names in order to clear binary
NEW, in coordination
And what about skipped ones? When will those be tried?
Those also will need clear NEW if needed.
(And they might even FTBFS because the ABI did change and ABI-assuming
test break? Though I don't assume so for time_t, but if time is passed
around... I don't assume so, but...
At least that would be the case for libreoffice (and
libreoffice-dev-common is in the affected set, which means some stuff
relies on it...))
(Maybe even needing asm fixes)
- once these packages have all cleared binary NEW, the new dpkg defaults
will be uploaded to unstable
- the sourceful NMUs of the libraries will be reuploaded to unstable
(without binaries, so that they can be promoted to testing without
additional uploads).
Please let me know of any problems with this plan.
Also a problem is that experimental also might already contain totally
unrelated updates like new upstream versions...
Regards,
Rene
Re: Bug#1060034: ITP: python-openai -- OpenAI Python API library
On Fri, 2024-01-05 at 08:50 -0500, Mo Zhou wrote: > > On 1/5/24 03:48, Ansgar wrote: > > On Thu, 2024-01-04 at 21:30 -0500, Mo Zhou wrote: > > > Dependency of DebGPT. Will be maintained by deep learning team. > > > It will go to the contrib section based on policy section 2.2.2, > > > because this API client requires either > > > (1) paied access to the proprietary backend > > > (2) compatible open-source backend implementations are not yet > > > available in the archive. > > > > > > I'm confused. Will this package have a "Depends: some- > > > proprietary- > > > openai-thing"? Can't it talk to a web service providing the API? > No. All the dependencies are: python3-anyio,python3-distro, > python3-httpx,python3-pydantic,python3-sniffio,python3-tqdm, > python3-typing-extensions,python3:any. > Can be satisfied using packages from main section. > > That said, this package does not work at all without (1) paid > access token from OpenAI (2) open-source alternative Then the package should be in main. We do not require external software to be free as well, be that Web APIs provided by Github, Twitter, or the NVidia firmware required for Nouveau, microcode or storage/keyboard/sound/printer firmware required for Linux, ... We would have to move pretty much everything to contrib if that was the case. Ansgar
Re: Bug#1060034: ITP: python-openai -- OpenAI Python API library
On 1/5/24 11:45, Ansgar wrote: Then the package should be in main. We do not require external software to be free as well, be that Web APIs provided by Github, Twitter, or the NVidia firmware required for Nouveau, microcode or storage/keyboard/sound/printer firmware required for Linux, ... We would have to move pretty much everything to contrib if that was the case. OK. It seems that I misunderstood it all the time. Mailed ftp-master to reject so I can change the section and reupload. That means src:debgpt can go to the main section as well.
Re: Bug#1060034: ITP: python-openai -- OpenAI Python API library
> "Mo" == Mo Zhou writes: Mo> On 1/5/24 11:45, Ansgar wrote: >> Then the package should be in main. >> >> We do not require external software to be free as well, be that >> Web APIs provided by Github, Twitter, or the NVidia firmware >> required for Nouveau, microcode or storage/keyboard/sound/printer >> firmware required for Linux, ... We would have to move pretty >> much everything to contrib if that was the case. Mo> OK. It seems that I misunderstood it all the time. Mailed Mo> ftp-master to reject so I can change the section and reupload. Also, I thought that there were several open-source implementations of this API, including from llama.cpp and ctransformers among others. My impression was the OpenAI API had become kind of a standard for gluing something like text-generation-webui to a hosted model not running locally. Or is that some *different* OpenAI API?
Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On 2024-01-05 00:23:00 -0800, Steve Langasek wrote: > On Fri, Jan 05, 2024 at 12:17:04AM -0800, Steve Langasek wrote: > > == Results == > > > > The overall findings of this analysis are 1,745 "dev" packages which either > > are confirmed to have ABI changes or could not be checked; mapping to 2,154 > > runtime libraries (list attached) from 1,195 source packages (list attached) > > and 5,477 reverse-dependencies requiring no-change rebuilds (list attached). > > This is within the previously calculated range of "5300 to 5600", but there > > are a number of newly-identified packages that fail to compile and have a > > large number of reverse-dependencies. I will continue to work to identify > > false-positives here in the hopes of bringing this count down before pulling > > the trigger on an actual transition. > > [...] > > > In addition, Guillem pointed out that if there are libraries whose ABIs are > > lfs-sensitive but not time_t-sensitive, and either they themselves depend on > > libraries which are time_t-sensitive or they have reverse-dependencies that > > do, so they will also need to be included in the transition. I have > > identified a list of 53 packages in this category (list attached); these in > > turn have 174 additional reverse-dependencies that would need rebuilt (list > > attached). > > I am also attaching here the dd-list output for the packages that will need > to be sourcefully NMUed for the transition, for your review. Why do the need sourceful NMUs if they just need to be rebuilt? Cheers -- Sebastian Ramacher
Re: Bug#1060034: ITP: python-openai -- OpenAI Python API library
On 1/5/24 12:32, Sam Hartman wrote: Also, I thought that there were several open-source implementations of this API, including from llama.cpp and ctransformers among others. My impression was the OpenAI API had become kind of a standard for gluing something like text-generation-webui to a hosted model not running locally. Or is that some *different* OpenAI API? You are correct. The OpenAI API spec is already a de-facto standard in this area. Every alternative will try to provide the same set of API.
Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi Sebastian,
On Fri, Jan 05, 2024 at 06:34:38PM +0100, Sebastian Ramacher wrote:
> On 2024-01-05 00:23:00 -0800, Steve Langasek wrote:
> > On Fri, Jan 05, 2024 at 12:17:04AM -0800, Steve Langasek wrote:
> > > == Results ==
> > > The overall findings of this analysis are 1,745 "dev" packages which
> > > either are confirmed to have ABI changes or could not be checked;
> > > mapping to 2,154 runtime libraries (list attached) from 1,195 source
> > > packages (list attached) and 5,477 reverse-dependencies requiring
> > > no-change rebuilds (list attached). This is within the previously
> > > calculated range of "5300 to 5600", but there are a number of
> > > newly-identified packages that fail to compile and have a large number
> > > of reverse-dependencies. I will continue to work to identify
> > > false-positives here in the hopes of bringing this count down before
> > > pulling the trigger on an actual transition.
> > [...]
> > > In addition, Guillem pointed out that if there are libraries whose
> > > ABIs are lfs-sensitive but not time_t-sensitive, and either they
> > > themselves depend on libraries which are time_t-sensitive or they have
> > > reverse-dependencies that do, so they will also need to be included in
> > > the transition. I have identified a list of 53 packages in this
> > > category (list attached); these in turn have 174 additional
> > > reverse-dependencies that would need rebuilt (list attached).
> > I am also attaching here the dd-list output for the packages that will need
> > to be sourcefully NMUed for the transition, for your review.
> Why do the need sourceful NMUs if they just need to be rebuilt?
Sorry, if the original message hadn't been lost somewhere in the mail
system before being delivered to debian-devel (I've now tried to resend it),
this might have been clearer from context. Guillem points out the mail has
been delivered to debian-release, so you can read the whole thing there:
https://lists.debian.org/debian-release/2024/01/msg00033.html
Anyway, this is the list of source packages containing libraries whose ABI
will change. So the packages need to be renamed in order to expose the ABI
incompatibility to reverse-dependencies. That's not a no-change rebuild.
This is consistent with historical practice in Debian for
toolchain-triggered ABI changes ('g' for libc5->glibc; c102; c2; v5; ldbl)
--
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: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 12:05:57PM +, Simon McVittie wrote: > On Fri, 05 Jan 2024 at 00:17:04 -0800, Steve Langasek wrote: > > - In multi-library packages, there is no reliable way to map from a set of > > headers in a dev package to specific shared libraries in a runtime library > > package that's not additionally computationally prohibitive; we therefore > > conservatively assume that if any headers from a source package show > > time_t ABI changes, all the runtime library packages from the source > > package are affected by the transition. > > 0 dbus-tests > Please ignore this specific binary package. The only public API/ABI > of src:dbus is in libdbus-1-3 + libdbus-1-dev, so analyzing those two > is enough. (dbus-tests accidentally contains one header file, but that's > a minor bug.) > libdbus-1-dev is widely depended-on, so I hope that taking src:dbus off > your list will avoid some unnecessary rebuilds? > > 0 gobject-introspection > Similarly the only public API/ABI of src:gobject-introspection is in > libgirepository1.0-dev, libgirepository-1.0-1, and (in experimental) > libgirepository-1.0-dev. gobject-introspection contains some source > and header files that are used by other packages' regression tests, > but they are not public ABI. Yes, sorry - the way my scripts are set up to do the analysis right now, these packages still show up in the `sorted-revdep-count` list but there are manual overrides mapping both of these to an empty set of runtime libraries. So you'll see they don't show up in the `runtime-libs` or `source-packages` lists, and none of the reverse-dependencies of libdbus or libgirepository are tagged for rebuild. https://salsa.debian.org/adrien-n/armhf-time_t/-/blob/c62a594236374469b2181e9c5578ed124b57c48c/packagelist.py#L304 -- 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: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
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. Here are some more comments on individual packages. > 22 libobs-dev That's a change to the plugin ABI only. > 14 gnuradio gnuradio bump its SONAME every other month. > 9 libopenmpt-dev Seems to be a false positive. > 9 libogre-1.9-dev > 9 libgirara-dev Why is this one on the list? > 5 gcc-10-plugin-dev Can be skipped, not part of testing. Should be RMed from the archive instead. > 4 llvm-15-dev llvm-toolchain-15 is scheduled for removal. Reverse dependencies should get an RC bug instead. > 4 libspatialaudio-dev Why is this package on the list? > 3 libdvbpsi-dev Seems to be a false positive > libavutil58 av_timegm is not used by any package in the archive. I'd skip ffmpeg and it's libraries. > libpoppler-cpp0v5 > libpoppler-glib8 > libpoppler-qt5-1 > libpoppler-qt6-3 > libpoppler126 Can be combined with the upcoming poppler transiton (see #1060019) > libvlc5 > libvlccore9 Change to vlc plugin ABI. This does not require a change of the binary package name. > g2clib Can be combined with the upcoming transition (see #1060077). Cheers -- Sebastian Ramacher
Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi Steve On 2024-01-05 09:42:06 -0800, Steve Langasek wrote: > Hi Sebastian, > > On Fri, Jan 05, 2024 at 06:34:38PM +0100, Sebastian Ramacher wrote: > > On 2024-01-05 00:23:00 -0800, Steve Langasek wrote: > > > On Fri, Jan 05, 2024 at 12:17:04AM -0800, Steve Langasek wrote: > > > > == Results == > > > > > The overall findings of this analysis are 1,745 "dev" packages which > > > > either are confirmed to have ABI changes or could not be checked; > > > > mapping to 2,154 runtime libraries (list attached) from 1,195 source > > > > packages (list attached) and 5,477 reverse-dependencies requiring > > > > no-change rebuilds (list attached). This is within the previously > > > > calculated range of "5300 to 5600", but there are a number of > > > > newly-identified packages that fail to compile and have a large number > > > > of reverse-dependencies. I will continue to work to identify > > > > false-positives here in the hopes of bringing this count down before > > > > pulling the trigger on an actual transition. > > > > [...] > > > > > In addition, Guillem pointed out that if there are libraries whose > > > > ABIs are lfs-sensitive but not time_t-sensitive, and either they > > > > themselves depend on libraries which are time_t-sensitive or they have > > > > reverse-dependencies that do, so they will also need to be included in > > > > the transition. I have identified a list of 53 packages in this > > > > category (list attached); these in turn have 174 additional > > > > reverse-dependencies that would need rebuilt (list attached). > > > > I am also attaching here the dd-list output for the packages that will > > > need > > > to be sourcefully NMUed for the transition, for your review. > > > Why do the need sourceful NMUs if they just need to be rebuilt? > > Sorry, if the original message hadn't been lost somewhere in the mail > system before being delivered to debian-devel (I've now tried to resend it), > this might have been clearer from context. Guillem points out the mail has > been delivered to debian-release, so you can read the whole thing there: > > https://lists.debian.org/debian-release/2024/01/msg00033.html > > Anyway, this is the list of source packages containing libraries whose ABI > will change. So the packages need to be renamed in order to expose the ABI > incompatibility to reverse-dependencies. I am confused. Above you say: > these in turn have 174 additional > reverse-dependencies that would need rebuilt (list attached). This sounds to me like those are packages that are involved in the transition and need rebuilds, but do not change their ABI. And in fact, for most of packages that I maintain on the list, the ABI does not change. Can you please clarify which of the packages in your lists require changes to the binary package names and which do not? Cheers -- Sebastian Ramacher
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
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 > Here are some more comments on individual packages. > > 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. Looks like the failure to analyze should be easily fixable (maybe libobs-dev shouldn't be shipping this header?) https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/logs/libobs-dev/base/log.txt > > 14 gnuradio > gnuradio bump its SONAME every other month. And usually takes time, at least from what I've seen on the Ubuntu side, to settle all reverse-dependencies out into a consistent state where they can migrate to testing > > 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. > > 5 gcc-10-plugin-dev > Can be skipped, not part of testing. Should be RMed from the archive > instead. Thanks, I had already manually excluded gcc-13-plugin-dev from the transition, but there are gcc-*-plugin-dev in the archive for 4 other versions of gcc. I've updated things here to exclude all of them now. I will not, in general, exclude a library from the transition only because it's currently not in testing; this could be a transient situation, and users' shouldn't wind up with broken partial upgrades of this library later if it returns to testing. > > 4 llvm-15-dev > llvm-toolchain-15 is scheduled for removal. Reverse dependencies should > get an RC bug instead. > > libavutil58 > av_timegm is not used by any package in the archive. I'd skip ffmpeg and > it's libraries. How did you determine that it's unused by any reverse-dependencies? I'd be happy to exclude it, but want to be sure we're not exposing users to bugs in the process. > > libpoppler-cpp0v5 > > libpoppler-glib8 > > libpoppler-qt5-1 > > libpoppler-qt6-3 > > libpoppler126 > Can be combined with the upcoming poppler transiton (see #1060019) Again, combining the time_t transition with transitions introducing sourceful changes (and possible API incompatibilities) to existing libraries risks slowing the transition down to Debian's detriment. > > libvlc5 > > libvlccore9 > 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? Thanks, -- 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: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi Steve, 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. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
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. 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. The same is true for all the other transitions (poppler, g2clib, ...) that are currently staged in experimental. So unless we want to tell everyone to stop preparing transitions in experimental (which is contrary to what we, the RT, tell maintainers to do all the time), get everything from experimental removed, etc, I expect that we have to entangle time64_t and all transitions that are staged in experimental. > > Here are some more comments on individual packages. > > > > 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. > > Looks like the failure to analyze should be easily fixable (maybe libobs-dev > shouldn't be shipping this header?) > https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/logs/libobs-dev/base/log.txt > > > > 14 gnuradio > > > gnuradio bump its SONAME every other month. > > And usually takes time, at least from what I've seen on the Ubuntu side, to > settle all reverse-dependencies out into a consistent state where they can > migrate to testing I wouldn't waste my time with gnuradio. The maintainers does not coordinate transitions. After January 10th assuming that AUTORM kicks in, it won't be relevant any more. > > > 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. Based on the number of false positives in the libraries that I maintain, the time it takes to prepare, upload, accept from binNEW, etc. with involvement from different teams, I wonder if would not be more efficient to give maintainers some time to check their packages. > > > 5 gcc-10-plugin-dev > > > Can be skipped, not part of testing. Should be RMed from the archive > > instead. > > Thanks, I had already manually excluded gcc-13-plugin-dev from the > transition, but there are gcc-*-plugin-dev in the archive for 4 other > versions of gcc. I've updated things here to exclude all of them now. > > I will not, in general, exclude a library from the transition only because > it's currently not in testing; this could be a transient situation, and > users' shouldn't wind up with broken partial upgrades of this library later > if it returns to testing. I added a hint so that gcc-10 cannot migrate back to testing. > > > 4 llvm-15-dev > > > llvm-toolchain-15 is scheduled for removal. Reverse dependencies should > > get an RC bug instead. > > > > libavutil58 > > > av_timegm is not used by any package in the archive. I'd skip ffmpeg and > > it's libraries. > > How did you determine that it's unused by any reverse-dependencies? I'd be > happy to exclude it, but want to be sure we're not exposing users to bugs in > th
64-bit time_t: updated archive analysis, proposed transition plan with timeline
[Sorry for breaking the thread; my previous message exceeded a size limit for debian-devel so I'm having to re-send with some of the attachments removed and put on a website instead. This mail also includes an updated 'sorted-revdep-count' list; I inadvertently had a stale local mirror in my sid apt config that was causing these numbers to be inflated, the new attachment is better.] Hi folks, Once again, coming back around to the question of an archive-wide migration for time_t[0]. We have a clear path forward on the toolchain side (https://bugs.debian.org/1037136), and we have an updated ABI analysis done against current Debian unstable as of 2023-12-18, superseding the previous preliminary analysis we had done on Ubuntu mantic. This re-analysis took a while to get done in large part because the earlier mailing list thread revealed gaps in the identification of "dev" packages[1], so we spent some time fixing this to ensure we had proper archive coverage. Output files from the new analysis can be found here: https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/ == Description of methodology == Before going into details of the plan I'm proposing for the migration, I want to surface to the list the methodology used for the analysis, so that people have an opportunity to identify any errors. - Packages are identified as "dev" packages if, according to Contents-armhf in the archive, they ship files with an extension of .h, .hpp, .hxx, or .hh in any directory outside of /usr/share/doc. - Packages are identified as "library" packages if, according to Contents, they ship files with an extension of .so or match the pattern *.so.*. - Source packages are candidates for ABI analysis as part of this transition if at least one of their binary packages is a "dev" package, at least one is a "library" package, and at least one ships a shlibs control file. - This means packages that provide plugin APIs are excluded from the transition (they couldn't be automated anyway), but might still have ABI breakage that will require handling. (ex: apache2-dev; but it looks like perl did get picked up correctly by way of libperl5.36) - In multi-library packages, there is no reliable way to map from a set of headers in a dev package to specific shared libraries in a runtime library package that's not additionally computationally prohibitive; we therefore conservatively assume that if any headers from a source package show time_t ABI changes, all the runtime library packages from the source package are affected by the transition. This seems sensible in general, but er, in the pathological case we have Source: zlib that now ships both zlib1g-dev and libminizip-dev, zlib1g-dev is confirmed to not be ABI breaking, libminizip-dev has failed to analyze, and we don't want to force a transition for zlib1g because of libminizip (!). Current plan is to simply special case zlib1g, but there could be other problem packages we haven't identified. - Packages that could not be analyzed for whatever reason are still assumed to have an ABI that's sensitive to time_t and have to be included in the transition. Happily, due to improvements in this run of the number of packages that could successfully be analyzed, the number of libraries in this category has dropped from 1541 to 929, of which 69 have no reverse-dependencies at all. The final list of these header packages that could not be analyzed is attached, in case anyone still wants to identify that a library on this list whose ABI is not affected by time_t and should therefore be excluded from the transition. Note, however, that no effort has been made to filter out dev packages from this list that come from source packages containing OTHER dev packages that are known to have ABI breakage; for a number of the packages listed, further analysis would not change the outcome. (e.g. qt5-qmake failed to be analyzed, but qtbase-opensource-src also ships qtbase5-private-dev which shows time_t ABI sensitivity.) == Results == The overall findings of this analysis are 1,745 "dev" packages which either are confirmed to have ABI changes or could not be checked; mapping to 2,154 runtime libraries[2] from 1,195 source packages (list attached) and 5,477 reverse-dependencies requiring no-change rebuilds[3]. This is within the previously calculated range of "5300 to 5600", but there are a number of newly-identified packages that fail to compile and have a large number of reverse-dependencies. I will continue to work to identify false-positives here in the hopes of bringing this count down before pulling the trigger on an actual transition. My understanding is that this will also result in a perl ABI transition, separately from the libperl ABI transition; since this dependency isn't calculated via shlibs it was not automatically included in this analysis. This seems to be at most about 600 additional packages to be included in
Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
> "Steve" == Steve Langasek writes: Steve> - In multi-library packages, there is no reliable way to map Steve> from a set of headers in a dev package to specific shared Steve> libraries in a runtime library package that's not Steve> additionally computationally prohibitive; we therefore Steve> conservatively assume that if any headers from a source Steve> package show time_t ABI changes, all the runtime library Steve> packages from the source package are affected by the Steve> transition. This seems sensible in general, but er, in the Steve> pathological case we have Source: zlib that now ships both Steve> zlib1g-dev and libminizip-dev, zlib1g-dev is confirmed to not Steve> be ABI breaking, libminizip-dev has failed to analyze, and we Steve> don't want to force a transition for zlib1g because of Steve> libminizip (!). Current plan is to simply special case Steve> zlib1g, but there could be other problem packages we haven't Steve> identified. I think krb5 may be in this category. In particular, it looks like time_t is only exposed in the kdb.h API, which appears to have no reverse depends outside of krb5. I actually think that the freeIPA server may have a plugin that depends on kdb.h, and Samba4 can be built in such a way that it depends on kdb.h, but it looks like neither of those applies to the Debian archive. At one level, krb5-multidev only has an rdep of 5, but I suspect the rdep count for libkrb5-dev is somewhat larger:-) I don't know how many packages would be removed from the transition if we decide most of the krb5 libraries do not need to transition. signature.asc Description: PGP signature
Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 06:59:20PM +0100, Sebastian Ramacher wrote: > > > > I am also attaching here the dd-list output for the packages that will > > > > need > > > > to be sourcefully NMUed for the transition, for your review. > > > Why do the need sourceful NMUs if they just need to be rebuilt? > > Sorry, if the original message hadn't been lost somewhere in the mail > > system before being delivered to debian-devel (I've now tried to resend it), > > this might have been clearer from context. Guillem points out the mail has > > been delivered to debian-release, so you can read the whole thing there: > > https://lists.debian.org/debian-release/2024/01/msg00033.html > > Anyway, this is the list of source packages containing libraries whose ABI > > will change. So the packages need to be renamed in order to expose the ABI > > incompatibility to reverse-dependencies. > I am confused. Above you say: > > these in turn have 174 additional > > reverse-dependencies that would need rebuilt (list attached). > This sounds to me like those are packages that are involved in the > transition and need rebuilds, but do not change their ABI. And in fact, > for most of packages that I maintain on the list, the ABI does not > change. > Can you please clarify which of the packages in your lists require > changes to the binary package names and which do not? Sorry for the confusion. The two lists requiring binary package name changes are the attachments named 'source-packages' and 'lfs-and-depends-time_t'. This is what I fed into dd-list, and encompass 1248 source packages (1195 + 53). -- 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
Bug#1060113: ITP: debgpt -- Chatting LLM with Debian-Specific Knowledge
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: debgpt Version : ? (CLI not yet stablized) Upstream Contact: me * URL : https://salsa.debian.org/deeplearning-team/debgpt * License : MIT/Expat Programming Lang: python Description : Chatting LLM with Debian-Specific Knowledge This tool is still under development. I may not upload it very soon, but an ITP number helps me silent lintian. I will not upload untill I finish the CLI re-design, and finish the documentation parts. There are some interesting findings while experimenting. For instance, I find this rather convenient: $ debgpt -HQ --cmd 'git diff --staged' -A 'Briefly describe the change as a git commit message.' So I further wrapped the git commit command into $ debgpt git commit which automatically generates a description for staged changes and commit them for you. Currently, some of the code of debgpt is written by debgpt, some of the git commit messages are written by `debgpt git commit`. I will try to explore more possibilities and add them in future releases. The only missing dependency before uploaindg this is only src:python-openai, which awaits in NEW as the time of writing. The following is the full package description: Large language models (LLMs) are newly emerged tools, which are capable of handling tasks that traditional software could never achieve, such as writing code based on the specification provided by the user. In this tool, we attempt to experiment and explore the possibility of leveraging LLMs to aid Debian development, in any extent. Essentially, the idea of this tool is to gather some pieces of Debian-specific knowledge, combine them together in a prompt, and then send them all to the LLM. This tool provides convenient functionality for automatically retrieving information from BTS, buildd, Debian Policy, system manual pages, tldr manuals, Debian Developer References, etc. It also provides convenient wrappers for external tools such as git, where debgpt can automatically generate the git commit message and commit the changes for you. This tool supports multiple frontends, including OpenAI and ZMQ. The ZMQ frontend/backend are provided in this tool to make it self-contained. Thank you for using reportbug
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
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. > 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. This should be an ABI change but not an API change; the rate of new build failures should be very small (small enough that I have not proposed any rebuild testing as part of this transition). As previously discussed, there may be some impact from -Werror=implicit-function-declaration but those can be quickly dealt with. Barring any existing testing migration blockages, I expect this whole assembly to be able to migrate to testing rather quickly. The main point is that we don't want to have a large window between landing dpkg in unstable, and uploading the libraries in unstable, due to NEW processing; because that will result in misbuilt and crashy combinations of packages on armhf until resolved. And if the time_t transition goes into unstable, has not yet migrated to testing, and some of the library transitions in question are ready to go to unstable, I don't mind; I'm happy to work with the maintainers of those libraries to get the transitions done, and also they can just ignore the previous NMUs because they're getting a new SONAME anyway. Does this seem practicable to you (and the release team generally)? > > > > 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? > > Looks like the failure to analyze should be easily fixable (maybe libobs-dev > > shouldn't be shipping this header?) > > https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/logs/libobs-dev/base/log.txt > > > > 14 gnuradio > > > gnuradio bump its SONAME every other month. > > And usually takes time, at least from what I've seen on the Ubuntu side, > > to settle all reverse-dependencies out into a consistent state where > > they can migrate to testing > I wouldn't waste my time with gnuradio. The maintainers does not > coordinate transitions. After January 10th assuming that AUTORM kicks > in, it won't be relevant any more. It wastes less of my time to *not* special-case it, then ;-) > > > > 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 p
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 05:36:10PM +0100, Rene Engelhard wrote:
> > My strawman proposal is to give this thread 2 weeks from today for feedback
> > and further refinement, and also to further reduce the number of
> > false-positives included in the transition. Then, starting on Jan 18:
> > - dpkg will be uploaded to experimental with 64-bit time_t in the default
> >flags
> I think at that point in time one should know what breaks and whatnot.
> Archive rebuild?
> (Probably in stages)
What kind of breakage are you looking to avoid here? As mentioned in other
points in the thread, regressions as a result of this change should be rare
and easy to fix. I do not think it's a good use of time / CPU power to do
test rebuilds for this instead of just landing the transition.
> > - the source packages which need an ABI change
> >("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to
> I get that you probably want NMUs for not needing to ping every maintainer,
> but this is bad.
> That e.g. would cause me to upload libreoffice 24.2 rc2 to sid immediately
> when tagged end of next week to not have this caught in the transition. (see
> also below for the comment about new upstream versions in experimental.)
What about the suggestion to not push changes to experimental for packages
that already have new versions in experimental, and do the binary package
renames in unstable instead, leaving the package in experimental alone?
libreoffice libs only have one reverse-dep, zemberek-ooo; so the risk of
entanglement here is small anyway.
I think the above proposal, to skip packages already in experimental from
the set of uploads to experimental, would address your concern. It's not as
if there is going to be any time that it's ok to tell maintainers they can't
use experimental at all because we're doing this transition.
> >experimental with the new binary package names in order to clear binary
> >NEW, in coordination
> And what about skipped ones? When will those be tried?
What do you mean here by "skipped ones"?
--
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: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 05:28:37PM +0100, Guillem Jover wrote: > > Guillem Jover > >libaio > >libmd > >liburing > I checked these, and it looks like libmd and liburing are > false-positives? > * libmd uses AC_SYS_LARGEFILE, and on 32-bit arches it is already built >with LFS, the problem is that the header exposes off_t which means >the code linking against it needs to match its build flags, >otherwise they would already be broken now. You might want to look >into this as a potential pattern for other false-positives probably. >(I should probably update upstream the .pc file to include the >-D_FILE_OFFSET_BITS=64 flags if enabled, but I don't think the >analysis used .pc files anyway.) Thanks - yes, the analysis didn't use .pc files, though I'm checking if that's something we could improve on. But as you say it doesn't help with the current libmd anyway, so I'm adding that to the manual exclusion list. Reduces the count of revdeps to be rebuilt from 5450+178 to 5450+169. > * liburing is marked as LFS-sensitive, but that comes from inline >functions using off_t which end up casting that into an u32 type, >so I don't think this should affect the ABI. It is also forcibly >built with -D_FILE_OFFSET_BITS=64 in the upstream build system >(and with future=+lfs for good measure in the packaging, which >I'll switch to abi=+lfs). io_uring_prep_fadvise and io_uring_prep_madvise appear to be symbols publicly exposed in the ABI of /usr/lib/x86_64-linux-gnu/liburing-ffi.so.2 so I don't think it's true that the marking is only because of inline functions? But as this is also already built with LFS and is a false-positive, I've removed this as well. Reduces the count of revdeps to be rebuilt from 5450+169 to 5450+168 (not much improvement :). -- 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: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 02:23:59PM -0700, Sam Hartman wrote: > > "Steve" == Steve Langasek writes: > Steve> - In multi-library packages, there is no reliable way to map > Steve> from a set of headers in a dev package to specific shared > Steve> libraries in a runtime library package that's not > Steve> additionally computationally prohibitive; we therefore > Steve> conservatively assume that if any headers from a source > Steve> package show time_t ABI changes, all the runtime library > Steve> packages from the source package are affected by the > Steve> transition. This seems sensible in general, but er, in the > Steve> pathological case we have Source: zlib that now ships both > Steve> zlib1g-dev and libminizip-dev, zlib1g-dev is confirmed to not > Steve> be ABI breaking, libminizip-dev has failed to analyze, and we > Steve> don't want to force a transition for zlib1g because of > Steve> libminizip (!). Current plan is to simply special case > Steve> zlib1g, but there could be other problem packages we haven't > Steve> identified. > I think krb5 may be in this category. > In particular, it looks like time_t is only exposed in the kdb.h API, > which appears to have no reverse depends outside of krb5. > I actually think that the freeIPA server may have a plugin that depends > on kdb.h, and Samba4 can be built in such a way that it depends on > kdb.h, but it looks like neither of those applies to the Debian archive. https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/compat_reports/libkrb5-dev/lfs_to_time_t/compat_report.html indicates that the CLIENT struct is affected because the cl_call function pointer takes a 'struct timeval' as an argument. So that's not internal to kdb, it looks like an actual ABI change? > At one level, krb5-multidev only has an rdep of 5, but I suspect the > rdep count for libkrb5-dev is somewhat larger:-) > I don't know how many packages would be removed from the transition if > we decide most of the krb5 libraries do not need to transition. If we determined only libkdb5-10 and libgssrpc4 were affected, that does significantly reduce the number of packages needing to be rebuilt because of krb5, though maybe most of those packages also depend on other libraries that are transitioning. -- 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
Bug#1060124: ITP: golang-github-azure-go-amqp -- aMQP 1.0 client library for Go (library)
Package: wnpp Severity: wishlist Owner: Maytham Alsudany X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org Control: block 1059083 by -1 * Package name: golang-github-azure-go-amqp Version : 1.0.2 Upstream Contact: https://github.com/Azure/go-amqp/issues * URL : https://github.com/Azure/go-amqp * License : Expat Programming Lang: Go Description : aMQP 1.0 client library for Go (library) The amqp module is an AMQP 1.0 client implementation for Go. . AMQP 1.0 is not compatible with AMQP 0-9-1 or 0-10. Needed for new version of golang-github-azure-azure-sdk-for-go -- Kind regards, Maytham Alsudany signature.asc Description: This is a digitally signed message part
Bug#1060126: ITP: golang-github-azuread-microsoft-authentication-extensions-for-go -- Microsoft Authentication Library (MSAL) Extensions for Go (library)
Package: wnpp Severity: wishlist Owner: Maytham Alsudany X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org Control: block 1059083 by -1 * Package name: golang-github-azuread-microsoft-authentication-extensions-for-go Version : 0.0~git20231002.7e3b8e2 Upstream Contact: https://github.com/AzureAD/microsoft-authentication-extensions-for-go/issues * URL : https://github.com/AzureAD/microsoft-authentication-extensions-for-go * License : Expat Programming Lang: Go Description : Microsoft Authentication Library (MSAL) Extensions for Go (library) This package contains extension modules for Microsoft Authentication Library (MSAL) for Go. Needed for new version of golang-github-azure-azure-sdk-for-go Will be maintained within the Go team, and will need a sponsor. -- Kind regards, Maytham Alsudany signature.asc Description: This is a digitally signed message part
Bug#1060128: ITP: python-sphinxcontrib-github-alt -- Sphinx extension for easy GitHub links
Package: wnpp Severity: wishlist Owner: Dale Richards X-Debbugs-Cc: debian-devel@lists.debian.org, d...@dalerichards.net * Package name: python-sphinxcontrib-github-alt Version : 1.2 Upstream Contact: Jupyter Development Team * URL : https://github.com/jupyter/sphinxcontrib_github_alt * License : BSD 2-clause Programming Lang: Python Description : Sphinx extension for easy GitHub links Link to GitHub issues, pull requests, commits and users for a particular project. I intend to maintain this package within the Debian Python Team.
