Bug#1060188: transition: flatbuffers
On Sun, 2024-01-21 at 16:54 +0100, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > Should those that are not part of the transition tracker use the > shared > library or not? No. In order to make this simpler, I notified all reverse dependencies to rebuild against the latest flatbuffers, and marked the bugs as affects src:flatbuffers. armnn [OK] Bug#1076173 buildbot [OK] Bug#1076174 facet-analyser [not in testing; FTBFS already] gnome-keysign [OK] Bug#1076175 kodi [OK] Bug#1076176 libsigmf [OK] Bug#1076177 magic-wormhole [OK] Bug#1076178 magic-wormhole-mailbox-server [FTBFS already; irrelevant, #1058173] paraview [OK] Bug#1076179 python-autobahn [OK] Bug#1076180 python-daphne [OK] Bug#1076181 python-django-channels [OK] Bug#1076182 pytorch [OK]Bug#1076183 starlette [OK] Bug#1076184 vast [not in testing; FTBFS already] zaqar [OK] Bug#1076185 zlmdb [OK] Bug#1076186 Shall we proceed and upload to unstable?
Bug#1060188: transition: flatbuffers
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: flatbuff...@packages.debian.org Control: affects -1 + src:flatbuffers The flatbuffers version in unstable is rather old. I'd like to start the transition. All reverse dependencies can be built on amd64. Note, the package list in transition tracker is not complete. I get the list by for each binary package from src:flatbuffers: build-rdeps package The following list should be the complete version: armnn [OK] buildbot [OK] facet-analyser [not in testing; FTBFS already] gnome-keysign [OK] kodi [OK] libsigmf [OK] magic-wormhole [OK] magic-wormhole-mailbox-server [FTBFS already; irrelevant, #1058173] paraview [OK] python-autobahn [OK] python-daphne [OK] python-django-channels [OK] pytorch [OK] [1] starlette [OK] vast [not in testing; FTBFS already] zaqar [OK] zlmdb [OK] [1] pytorch is undergoing uncoordinated transition, because pytorch is the only reverse dependency of libdnnl2/libdnnl3 and both maintained by me. The pytorch/experimental (awaits in NEW) can be successfully built against new flatbuffers. I don't know how to write the ben file because not all of them depend on libflatbuffers2 . Ben file: title = "flatbuffers"; is_affected = .depends ~ "libflatbuffers2" | .depends ~ "libflatbuffers23.5.26"; is_good = .depends ~ "libflatbuffers23.5.26"; is_bad = .depends ~ "libflatbuffers2"; Thank you for using reportbug
Bug#1060182: transition: simdjson
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: simdj...@packages.debian.org Control: affects -1 + src:simdjson Hi, simdjson upstream bumped SOVERSION from 16 to 19 in the latest release. All reverse dependencies can be rebuilt against 19 on amd64. pcm [ok] cloudflare-ddns [ok] The automatic ben file on transition tracker is correct. https://release.debian.org/transitions/html/auto-simdjson.html Ben file: title = "simdjson"; is_affected = .depends ~ "libsimdjson16" | .depends ~ "libsimdjson19"; is_good = .depends ~ "libsimdjson19"; is_bad = .depends ~ "libsimdjson16"; Thank you for using reportbug
Bug#1059235: bookworm-pu: package fish/3.6.0-3.1+deb12u1
On Thu, 2023-12-21 at 21:48 +, Jonathan Wiltshire wrote: > Control: tag -1 confirmed > > On Thu, Dec 21, 2023 at 10:06:23PM +0100, Salvatore Bonaccorso wrote: > > Can you as well add a bug closer for #1057455? > > And a brief description of what the vulnerability actually is, please. You > can go ahead with those changes. Thanks. I added the missing information as follows, and will upload it shortly. --- diff --git a/debian/changelog b/debian/changelog index 0c1065b..3f18ea1 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,6 +1,10 @@ fish (3.6.0-3.1+deb12u1) bookworm; urgency=medium - * Cherry-pick upstream fix for CVE-2023-49284. + * Cherry-pick upstream fix for CVE-2023-49284. (Closes: #1057455) +fish shell uses certain Unicode non-characters internally for marking +wildcards and expansions. It will incorrectly allow these markers to be +read on command substitution output, rather than transforming them into +a safe internal representation. -- Mo Zhou Thu, 21 Dec 2023 14:47:56 -0500 diff --git a/debian/patches/CVE-2023-49284.patch b/debian/patches/CVE-2023-49284.patch index a6fb924..5830277 100644 --- a/debian/patches/CVE-2023-49284.patch +++ b/debian/patches/CVE-2023-49284.patch @@ -4,6 +4,16 @@ Description: fixes CVE-2023-49284 The corresponding fix can be found at https://github.com/fish-shell/fish-shell/commit/09986f5563e31e2c900a606438f1d60d008f3a14 This patch is rebased from the upstream fix. + . + fish shell uses certain Unicode non-characters internally for marking + wildcards and expansions. It will incorrectly allow these markers to be read + on command substitution output, rather than transforming them into a safe + internal representation. + . + While this may cause unexpected behavior with direct input (for example, echo + \UFDD2HOME has the same output as echo $HOME), this may become a minor security + problem if the output is being fed from an external program into a command + substitution where this output may not be expected.
Bug#1059235: bookworm-pu: package fish/3.6.0-3.1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: f...@packages.debian.org
Control: affects -1 + src:fish
[ Reason ]
Cherry-pick upstream fix to CVE-2023-49284
[ Impact ]
This is a low severity security issue that affects basically
all historical releases of fish. The upstream created new
releases (i.e. 3.6.2) solely for fixing this bug.
https://github.com/fish-shell/fish-shell/commits/Integration_3.6.2/
So it would be good if we can integrate the fix into stable.
[ Tests ]
The fix is already included in fish/3.6.4-1 (sid).
The rebased patch passed my local sbuild test.
I installed the package in a chroot and tested it.
[ Risks ]
low.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Only one change. Please refer to the patch header for explanation.
[ Other info ]
diff -Nru fish-3.6.0/debian/changelog fish-3.6.0/debian/changelog
--- fish-3.6.0/debian/changelog 2023-05-01 13:01:01.0 -0400
+++ fish-3.6.0/debian/changelog 2023-12-21 14:47:56.0 -0500
@@ -1,3 +1,9 @@
+fish (3.6.0-3.1+deb12u1) bookworm; urgency=medium
+
+ * Cherry-pick upstream fix for CVE-2023-49284.
+
+ -- Mo Zhou Thu, 21 Dec 2023 14:47:56 -0500
+
fish (3.6.0-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru fish-3.6.0/debian/patches/CVE-2023-49284.patch
fish-3.6.0/debian/patches/CVE-2023-49284.patch
--- fish-3.6.0/debian/patches/CVE-2023-49284.patch 1969-12-31
19:00:00.0 -0500
+++ fish-3.6.0/debian/patches/CVE-2023-49284.patch 2023-12-21
14:44:13.0 -0500
@@ -0,0 +1,31 @@
+Description: fixes CVE-2023-49284
+ The CVE report can be found at
+
https://github.com/fish-shell/fish-shell/security/advisories/GHSA-2j9r-pm96-wp4f
+ The corresponding fix can be found at
+
https://github.com/fish-shell/fish-shell/commit/09986f5563e31e2c900a606438f1d60d008f3a14
+ This patch is rebased from the upstream fix.
+diff --git a/src/common.cpp b/src/common.cpp
+index baee97a..0e76bf1 100644
+--- a/src/common.cpp
b/src/common.cpp
+@@ -345,9 +345,7 @@ static wcstring str2wcs_internal(const char *in, const
size_t in_len) {
+ } else {
+ ret = std::mbrtowc(&wc, &in[in_pos], in_len - in_pos, &state);
+ // Determine whether to encode this character with our crazy
scheme.
+-if (wc >= ENCODE_DIRECT_BASE && wc < ENCODE_DIRECT_BASE + 256) {
+-use_encode_direct = true;
+-} else if (wc == INTERNAL_SEPARATOR) {
++if (fish_reserved_codepoint(wc)) {
+ use_encode_direct = true;
+ } else if (ret == static_cast(-2)) {
+ // Incomplete sequence.
+@@ -1323,6 +1321,9 @@ maybe_t read_unquoted_escape(const wc
+ }
+
+ if (result_char_or_none.has_value()) {
++if (fish_reserved_codepoint(*result_char_or_none)) {
++return none();
++}
+ result->push_back(*result_char_or_none);
+ }
+
diff -Nru fish-3.6.0/debian/patches/series fish-3.6.0/debian/patches
--- fish-3.6.0/debian/patches/series2023-05-01 13:01:01.
+++ fish-3.6.0/debian/patches/series2023-12-21 14:44:23.
@@ -1,3 +1,4 @@
0001-reader-make-Escape-during-history-search-restore-com.patch
0002-reader-Remove-assert-in-history-search.patch
0003-workaround-for-Midnight-Commander.patch
+CVE-2023-49284.patch
Bug#1054659: transition: utf8proc
Done. It's green on all release archs. On Fri, 2023-10-27 at 18:40 +, Graham Inggs wrote: > Control: tags -1 confirmed > > Hi Mo > > On Fri, 27 Oct 2023 at 15:36, M. Zhou wrote: > > We can start the transition for utf8proc, which recently got an > > SOVERSION bump from 2 to 3. I tested the reverse dependencies > > on ppc64el and all of them are fine. The results for amd64 should > > be the same. > > Please go ahead. > > Regards > Graham >
Bug#1054659: transition: utf8proc
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: utf8p...@packages.debian.org Control: affects -1 + src:utf8proc Dear release team, We can start the transition for utf8proc, which recently got an SOVERSION bump from 2 to 3. I tested the reverse dependencies on ppc64el and all of them are fine. The results for amd64 should be the same. Reverse Build-depends in main: -- bibledit [ok] bibledit-cloud [ok] ccextractor [ok] deepin-terminal [ok] fcft [ok] fnott [ok] foot [ok] fuzzel [ok] mame [ok] pnetcdf [ok] qterminal [ok] qtermwidget [ok] securefs [ok] subversion [ok] yambar [ok] the automatic ben file is correct: https://release.debian.org/transitions/html/auto-utf8proc.html Ben file: title = "utf8proc"; is_affected = .depends ~ "libutf8proc2" | .depends ~ "libutf8proc3"; is_good = .depends ~ "libutf8proc3"; is_bad = .depends ~ "libutf8proc2"; Thank you for using reportbug
Re: Upcoming changes to Debian Linux kernel packages
On Mon, 2023-09-25 at 04:35 +0200, Andreas Beckmann wrote: > On 25/09/2023 00.50, Bastian Blank wrote: > > Already built modules remain until someone deletes it. So you can > > also > > switch back to the still installed older kernel version and it will > > have > > the still working module available. > > This is what I expect not to work. > > Assume I have Linux 6.6 and a third-party gpu driver module installed > (so there are dkms and the Linux 6.6 headers as well) and everything > is > working fine. > Then I upgrade the system, which brings Linux 6.7 (along linux-image- > 6.6 > which is kept installed) and a new version of the gpu driver (which > adds > support for 6.7). So the old gpu module for 6.6 gets removed and a > new > one is built for 6.7 only (since there are only 6.7 headers now). > Unfortunately 6.7 breaks some exotic in-tree driver (which I > desperately > need), so I need to go back to 6.6. Oops, there is no gpu driver > module > any more. Recovery now needs manual intervention. Same concern here. We cannot pose strong assumption on the user's upgrade path. The said scenario may happen for any dkms package when the newer kernel version is not supported. > I'm not sure which class of bugs you are trying to solve with this > proposed unversioned linux-headers change. IMO the current scheme of > linux-headers-$version-$abi-$flavor matching > linux-image-$version-$abi-$flavor works well. But perhaps something > could be improved on the metapackage side. Ideally a user should > install > either meta-linux-image-without-headers-$flavor OR > meta-linux-image-with-headers-$flavor (and ideally installing dkms > should "automatically switch" to the with-headers variant, not sure > how > this could be done). The current scheme of having to install > linux-image-$flavor AND linux-headers-$flavor is a bit tricky. > I'm open to implement improvements on the dkms side. I could not understand the benefit of it neither. Apart from the dkms part, the user-customized kernel packages cannot be omitted as well. For instance, if I build a customized kernel from debian's kernel source, using `make bindeb-pkg`, I get those: linux-headers-6.5.3_6.5.3-2_amd64.deb linux-image-6.5.3_6.5.3-2_amd64.deb linux-libc-dev_6.5.3-2_amd64.deb Currently they are well integrated into the system, and IIRC dkms also works for them. If versioning is gone, how to make it compatible with user's local kernel package? There must be two copies of kernel headers in the system in this case because we cannot remove user's local customized headers on our own. Then the design still has to support multi version co-existence.
Bug#1042871: transition: simdjson
Yesterday I made a mistake to reply to the old simdjson transition bug #1024380 which dates back to 1 year ago. Anyway, it has been uploaded to unstable, and successfully built for all release architectures. On Sat, 2023-08-05 at 15:50 +0200, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > On 2023-08-01 22:07:33 -0700, M. Zhou wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: simdj...@packages.debian.org > > Control: affects -1 + src:simdjson > > > > Hi release team, > > > > The simdjson upstream has bumped the ABI version along with their > > new release. Thus the transition request. > > > > It has only two reverse dependencies in testing. src:vast is not > > in testing. All reverse dependencies compiles against the new > > version. > > Please go ahead > > Cheers
Bug#1042871: transition: simdjson
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: simdj...@packages.debian.org Control: affects -1 + src:simdjson Hi release team, The simdjson upstream has bumped the ABI version along with their new release. Thus the transition request. It has only two reverse dependencies in testing. src:vast is not in testing. All reverse dependencies compiles against the new version. Reverse-Build-Depends = * pcm [ok] * vast [skipped. not in testing] Reverse-Build-Depends-Arch == * cloudflare-ddns [ok] The automatic transition tracker is correct. Thank you! Ben file: title = "simdjson"; is_affected = .depends ~ "libsimdjson14" | .depends ~ "libsimdjson16"; is_good = .depends ~ "libsimdjson16"; is_bad = .depends ~ "libsimdjson14"; Thank you for using reportbug
Bug#1035024: unblock: nvidia-cudnn/8.7.0.84~cuda11.8+1 (pre-approval)
On Sun, 2023-05-07 at 22:03 +0200, Paul Gevers wrote: > Control: tags -1 moreinfo > > Hi Mo, > > On 27-04-2023 21:31, M. Zhou wrote: > > So, generally updating the package is simply to update the binary > > tarball URL in the script, along with the exact version number, > > which is very trivial. > > So why didn't you ask for only this? I thought about this choice. This package is hardly useful without the the fake library (for fixing dh_shlibdeps resolving), because it cannot serve as a component in the dependency chain for its future reverse dependencies. Even if the current testing package entered the next stable, it is still hardly useful. So if this is not going to be approved, I would prefer to get it removed from testing and prepare for the stable backports instead. > > 4. debconf template default choice is changed to "I Agree". > > This package is in non-free section. Only by setting the debconf > > default choice > > to "I Agree", can we correctly build pytorch-cuda in sbuild without > > the cuDNN > > libraries not downloaded but the bin:nvidia-cudnn package installed. > > Are we legally allowed to do this? If so, why even ask the question? According to the upstream license and the package content, the URL points to a distributable tarball depending on the user's agreement. The debconf questions shows the full license texts and asks the user whether to accept the terms. These terms, was deemed problematic by ftp-masters if we directly upload the binary blobs into the archive. At least, building the reverse dependency pytorch-cuda via sbuild, where the binary blobs will be pulled and linked against, is legal according to the license. Uploading the binary form of pytorch-cuda is ok as well. Other binary distributions like ArchLinux, Anaconda, and even PyTorch upstream have been redistributing the cuDNN binaries for years though. Although I hate dealing with annoying non-free license texts, I think it not safe to remove the debconf question prompt, because the license seems to pose even more restrictions than its dependency CUDA devkit. > Paul > PS wasn't an autopkgtest feasible such that this didn't need to be on > our radar? (too late for that now, but still) It looks like I have to refresh my memory, I thought autopkgtest won't be run for non-free packages. Writing the test scripts are easy, but I think that's not needed if I can get a manual removal or refusal. I checked the license, some simple test scripts for testing the downloader script, and do some testing compilation / linking will not violate the license. Will add them in the future. Both would work for me. I'm ok with stable backports. Afterall pytorch-cuda will only be available through backports. P.S. I really hate dealing with this package with a complicated end user agreement. It leads to my years long procrastination for the pytorch-cuda preparation. But, I was still forced to get it done solely due to the nvidia monopoly if we want a mature and high-performance version of pytorch. That said, the debian-ai@l.d.o team is diligently working on AMD's open-source ROCm, which provides alternatives for nvidia CUDA and cuDNN. When the ROCm stack is ready in our archive, I want to gradually give up the cuda branch and the corresponding effort -- pytorch-rocm can enter main, while pytorch-cuda can never.
Bug#1035354: unblock: fish/3.6.0-3.1
I'm the previous uploader of src:fish. The change looks good to me. Please feel free to go ahead with the nmu once the release managers say OK. On Mon, 2023-05-01 at 19:13 +0200, Andrej Shadura wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-Cc: f...@packages.debian.org, Mo Zhou > Control: affects -1 + src:fish > > Please unblock package fish > > As described in #1000351, mc ships fragile prompt extraction code which > was broken by a change in fish 3.3.0, leaving fish unusable in > conjunction with mc. I had hoped that this bug would be fixed in mc by > the time of bookworm release, but this didn’t happen. Instead, the > upstream developers of fish proposed a workaround and shipped it > in the bugfix release 3.6.1. > > I intend to either upload an NMU or let Mo Zhou do a maintainer’s > upload. > > This fix has very limited impact, as it specifically checks for the > presence of an mc-specific environment variable, and is a no-op > otherwise. The workaround itself is also straightforward. > > The impact of not shipping this patch is that all users of both fish and > mc (like myself) will have to put fish on hold and stay on the version > shipped in bullseye. > > [ Checklist ] > [x] all changes are documented in the d/changelog > [x] I reviewed all changes and I approve them > [x] attach debdiff against the package in testing > > > Links: > > [1]: https://bugs.debian.org/1035353: the original mc bug > [2]: https://bugs.debian.org/1000351: a clone of the above for the > package fish > [3]: https://github.com/fish-shell/fish-shell/pull/9540: a pull request > in the upstream package. > > unblock fish/3.6.0-3.1
Bug#1035024: unblock: nvidia-cudnn/8.7.0.84~cuda11.8+1 (pre-approval)
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: nvidia-cu...@packages.debian.org
Control: affects -1 + src:nvidia-cudnn
Please unblock package nvidia-cudnn. Not yet uploaded to unstable,
just asking for a pre-approval.
[ Reason ]
Our current package version in testing is 8.5.0.96~cuda11.7,
but the nvidia-cuda-toolkit version in testing is 11.8.89~11.8.0-2.
So there is a little minor version mismatch in the cuda version
(one 11.7, and the other 11.8).
This package is a downloader script that downloads the Nvidia
binary blob releases of the cuDNN library, and installs the library
to the system directories for building reverse dependencies.
So, generally updating the package is simply to update the binary
tarball URL in the script, along with the exact version number,
which is very trivial.
But unfortunately, during the cuda11.7 to cuda11.8 update,
I also introduced many changes to the package to the maintainer
scripts to let the package correctly support the pytorch-cuda build.
I'm the upstream of this package, and this looks like a low risk
update to me. But I'm not sure how the release team will think.
So asking for uploading permission in advance.
[ Impact ]
(What is the impact for the user if the unblock isn't granted?)
Nearly no impact. This package is new and does not exist
in the previous stable releases. To the best of my knowledge,
there is only one tentative reverse dependency pytorch-cuda,
which is not present in testing.
[ Tests ]
(What automated or manual tests cover the affected code?)
The updated package is now able to correctly support the
build of pytorch-cuda. I tested the built package with both
Nvidia MX250 (laptop) and RTX 2060 (laptop) GPUs. It works
correctly.
[ Risks ]
There is a small risk. The additional code is very simple.
It does not have reverse dependency in testing. There
is no alternative to this package. I'm the upstream author
of the script, and I can provide stable updates on my own
even if something goes wrong.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
(Anything else the release team should know.)
The debdiff contains necessary changes to make the package
correctly support the pytorch-cuda build (with sbuild).
Specifically:
1. A fake library is compiled (from a nearly empty C file cudnn-fake.c)
with the soname of the library to be downloaded. This seems to be
the only way to make apt/dpkg believe that the libcudnn.so.* is
really provided by this binary package.
This solves the libcudnn_* cannot be found in any system package
error from dh_shlibdeps.
2. Added curl as an alternative binary blob downloader.
3. Updated the postinst and prerm script for handling installed files.
In the current testing version, when we want to remove this package,
we use some manually written glob patterns to remove the downloaded
cudnn library. This implementation is not very safe when the user manually
install another instance of cudnn to the system. The glob pattern will also
include them to make them removed during postrm.
In the proposed version (see debdiff), I record a list of files that are
installed
from the tarball to the system. And the postrm process will use the exact
recorded installation paths for removal. I think this is a safer
implementation
than removal by glob pattern match.
4. debconf template default choice is changed to "I Agree".
This package is in non-free section. Only by setting the debconf default
choice
to "I Agree", can we correctly build pytorch-cuda in sbuild without the
cuDNN
libraries not downloaded but the bin:nvidia-cudnn package installed.
5. More code comments (maintainence notes) in the script, and the upgraded
binary blob URL.
unblock nvidia-cudnn/8.7.0.84~cuda11.8+1
Thank you for using reportbug
diff -Nru nvidia-cudnn-8.5.0.96~cuda11.7/cudnn-fake.c nvidia-cudnn-8.7.0.84~cuda11.8/cudnn-fake.c
--- nvidia-cudnn-8.5.0.96~cuda11.7/cudnn-fake.c 1969-12-31 19:00:00.0 -0500
+++ nvidia-cudnn-8.7.0.84~cuda11.8/cudnn-fake.c 2023-03-21 18:49:17.0 -0400
@@ -0,0 +1,8 @@
+/* This is a fake library. We want dpkg-shlibdeps to believe that the
+ * shared object libcudnn.so.8 is provided in this package.
+ */
+int
+__cudnn_fake_library__()
+{
+return 0;
+}
diff -Nru nvidia-cudnn-8.5.0.96~cuda11.7/debian/changelog nvidia-cudnn-8.7.0.84~cuda11.8/debian/changelog
--- nvidia-cudnn-8.5.0.96~cuda11.7/debian/changelog 2023-02-17 23:24:39.0 -0500
+++ nvidia-cudnn-8.7.0.84~cuda11.8/debian/changelog 2023-03-21 18:49:17.0 -0400
@@ -1,3 +1,33 @@
+nvidia-cudnn (8.7.0.84~cuda11.8) experimental; urgency=medium
+
+ * Upgrade to cuDNN v8.7.0.84
+ * Set the debconf template default choice to "I Agree".
+Only in this way can we use the binary packa
Bug#1033464: unblock: fish/3.6.0-3
On Sun, 2023-03-26 at 20:31 +0200, Luna Jernberg wrote: > Not to whine but is the plan to build 3.6.1 that was released yesterday > aswell? It's the hard freeze stage for Debian. Introducing a massive change, such as the full 3.6.1 upgrade will not likely successfully make it in testing according to the freeze policy. The 3.6.1 upgrade is postponed after the upcoming stable release.
Bug#1033464: unblock: fish/3.6.0-3
Control: tags -1 - moreinfo On Sun, 2023-03-26 at 07:28 +0200, Paul Gevers wrote: > Control: tags -1 confirmed moreinfo > > Hi Mo, > > On 25-03-2023 15:39, M. Zhou wrote: > > Please unblock package fish > > Not yet uploaded. This package does not have a proper > > autopkgtest, manual unblock needed. > > Please go ahead and remove the moreinfo tag once that happened. It has been uploaded to unstable. And turned green on all release archs: https://buildd.debian.org/status/package.php?p=fish
Bug#1033464: unblock: fish/3.6.0-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package fish
Not yet uploaded. This package does not have a proper
autopkgtest, manual unblock needed.
[ Reason ]
I cherry picked two upstream fixes. One of them fixes
crash, while the other fixes undesired behavior.
https://github.com/fish-shell/fish-shell/commit/e84f588d11a86d38ff708d4c16aab1316ac09b6c
https://github.com/fish-shell/fish-shell/commit/37575c5f7983cb5338a1ba23541bbd86a4fd2a4e
And I also added the missing dependency on procps.
It absence leads to unwanted and unnecessary errors:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029940
[ Impact ]
Fish is an interactive shell. These changes would fix unwanted
behavior of the shell.
[ Tests ]
The patches are cherry-picked from the upstream 3.6.1 release
and has been coverted by their CI. My default shell is fish and
it has been locally tested on both sid and the current stable.
[ Risks ]
The two patches are simple. Adding dependency on procps induces
zero risk.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock fish/3.6.0-3
Thank you for using reportbug
diff -Nru fish-3.6.0/debian/changelog fish-3.6.0/debian/changelog
--- fish-3.6.0/debian/changelog 2023-02-17 20:05:29.0 -0500
+++ fish-3.6.0/debian/changelog 2023-03-25 10:20:50.0 -0400
@@ -1,3 +1,10 @@
+fish (3.6.0-3) unstable; urgency=medium
+
+ * Cherry-pick upstream fixes from the v3.6.1 branch.
+ * Add the missing Depends on procps (Closes: #1029940).
+
+ -- Mo Zhou Sat, 25 Mar 2023 10:20:50 -0400
+
fish (3.6.0-2) unstable; urgency=medium
* Ignore several flaky tests for armel.
diff -Nru fish-3.6.0/debian/control fish-3.6.0/debian/control
--- fish-3.6.0/debian/control 2023-01-07 11:28:46.0 -0500
+++ fish-3.6.0/debian/control 2023-03-25 10:19:55.0 -0400
@@ -26,6 +26,7 @@
bsdextrautils,
groff-base,
man-db,
+ procps,
python3,
${misc:Depends},
${shlibs:Depends}
diff -Nru fish-3.6.0/debian/patches/0001-reader-make-Escape-during-history-search-restore-com.patch fish-3.6.0/debian/patches/0001-reader-make-Escape-during-history-search-restore-com.patch
--- fish-3.6.0/debian/patches/0001-reader-make-Escape-during-history-search-restore-com.patch 1969-12-31 19:00:00.0 -0500
+++ fish-3.6.0/debian/patches/0001-reader-make-Escape-during-history-search-restore-com.patch 2023-03-25 10:18:29.0 -0400
@@ -0,0 +1,58 @@
+From: Johannes Altmanninger
+Date: Tue, 17 Jan 2023 09:14:54 +0100
+Subject: reader: make Escape during history search restore commandline again
+
+Commit 3b30d92b6 (Commit transient edit when closing pager, 2022-08-31)
+inadvertently introduced two regressions to history search:
+
+1. It made Escape keeps the selected history entry,
+ instead of restoring the commandline before history search.
+2. It made history search commands add undo entries.
+
+Fix both of this issues.
+---
+ src/reader.cpp| 3 ++-
+ tests/checks/tmux-history-search.fish | 12
+ 2 files changed, 14 insertions(+), 1 deletion(-)
+
+diff --git a/src/reader.cpp b/src/reader.cpp
+index c50426f..9fe2d7e 100644
+--- a/src/reader.cpp
b/src/reader.cpp
+@@ -4477,7 +4477,8 @@ maybe_t reader_data_t::readline(int nchars_or_0) {
+
+ // Clear the pager if necessary.
+ bool focused_on_search_field = (active_edit_line() == &pager.search_field_line);
+-if (command_ends_paging(readline_cmd, focused_on_search_field)) {
++if (!history_search.active() &&
++command_ends_paging(readline_cmd, focused_on_search_field)) {
+ clear_pager();
+ }
+
+diff --git a/tests/checks/tmux-history-search.fish b/tests/checks/tmux-history-search.fish
+index 9dc1b4f..92bab0b 100644
+--- a/tests/checks/tmux-history-search.fish
b/tests/checks/tmux-history-search.fish
+@@ -3,6 +3,9 @@
+ # disable on github actions because it's flakey
+ #REQUIRES: test -z "$CI"
+
++set -g isolated_tmux_fish_extra_args -C '
++set -g fish_autosuggestion_enabled 0
++'
+ isolated-tmux-start
+
+ isolated-tmux send-keys 'true needle' Enter
+@@ -15,3 +18,12 @@ isolated-tmux send-keys C-p C-a M-f M-f M-f M-.
+ # CHECK: prompt 2> true hay needle hay
+ tmux-sleep
+ isolated-tmux capture-pane -p
++
++isolated-tmux send-keys C-e C-u true Up Up Escape
++tmux-sleep
++isolated-tmux capture-pane -p | grep 'prompt 2'
++# CHECK: prompt 2> true
++isolated-tmux send-keys C-z _
++tmux-sleep
++isolated-tmux capture-pane -p | grep 'prompt 2'
++# CHECK: prompt 2> _
diff -Nru fish-3.6.0/debian/patches/0002-reader-Remove-assert-in-history-search.patch fish-3.6.0/debian/patches/0002-reader-Remove-assert-in-history-search.patch
--- fish-3.6.0/debian/patches/0002-reader-Remove-assert-in-his
Bug#1027686: transition: rakudo
I have uploaded moarvm, nqp, and rakudo to unstable. They turned green on release architectures. The ppc64el buildd lags a little bit but I believe the result will be green as well based on the previous no-change build in experimental. On Sun, 2023-01-15 at 19:09 +0100, Sebastian Ramacher wrote: > Control: tags -1 = confirmed > > On 2023-01-15 18:49:24 +0100, Dominique Dumont wrote: > > On Sunday, 15 January 2023 15:21:55 CET Sebastian Ramacher wrote: > > > > I've found where compiler-id is computed. I'm going patch > > > > rakudo in > > > > experimental so that compiler-id depends only on source files > > > > and nqp > > > > version. This patch will land in experimental. > > > > > > Okay, please let me know once it's available in experimental. > > > > Done with rakudo 2022.12-1~exp3 > > > > I've patched the compiler id to be a sha1 of "Debian- > version>". > > > > I've verified that compiler id is the same for the arch that are > > built. > > > > Is it still time to trigger a transition to fix all raku modules ? > > (there's no > > impact outside of raku modules) > > Thanks, please go ahead. > > Cheers
Bug#1027686: transition: rakudo
I missed the detail that the compiler ID even changes for different architecture.. which may not be good. Is it possible for us to slightly modify the postinst script to recompile the cache locally when the compiler id mismatches? The fallback script rakudo-helper.pl can at least make sure a raku-* package is still functional even without a matching compiler ID. In that case we don't have to add the compiler ID to the virtual package name, and every architecture can track the same and consistent virtual package dependency. On Sat, 2023-01-07 at 18:40 +0100, Dominique Dumont wrote: > On Saturday, 7 January 2023 11:58:29 CET you wrote: > > > Unfortunately, the compiler-id also depends on the build > > > directory. Which > > > means that the compiler id changes between arches. > > > > This should be fixed first. Otherwise every rebuild of the compiler > > will > > require all reverse dependencies to be rebuilt too. That does not > > sound > > like a good solution. > > Agreed, but that's a long story with upstream: > > https://github.com/rakudo/rakudo/issues/5099 > > All the best >
Bug#1027686: transition: rakudo
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: rak...@packages.debian.org Control: affects -1 + src:rakudo Dear release team, We would like to start the transition for rakudo, updating rakudo to the latest version in unstable. It involves three packages, src:moarvm, src:nqp, and src:rakudo. They are built successfully in experimental. The s390x buildd is super slow this week -- I waited for a week and it has not started a build yet All other architectures look good. This upload also aims to trigger rebuild for all reverse dependencies to mitigate some issues about the compiler ID. Specifically, the pre-compiled cache shipped in reverse dependencies relies on a matching compiler ID. Hence, we added the compiler ID into the virtual package to ensure cache compatibility: raku-api-2022.12+e556a5c0 The compiler ID will change when code is modified. Albeit adding the compiler ID may not sound like an ideal solution, this seems like what we can do before the freeze. Ben file: title = "rakudo"; is_affected = .depends ~ "raku-api-2022.07" | .depends ~ "raku-api-2022.12+e556a5c0"; is_good = .depends ~ "raku-api-2022.12+e556a5c0"; is_bad = .depends ~ "raku-api-2022.07"; Thank you for using reportbug
Re: Python 3.11 for bookworm?
It seems I was a little bit out of date. Diane Trout has tried with an unreleased snapshot which looks good with llvm-14 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024795 Will work on it soon. On Thu, 2022-12-22 at 18:04 -0500, M. Zhou wrote: > I'm the regular uploader of python3-llvmlite. > > Please give up with numba. Its core dependency llvmlite is not even > ready for llvm != 11, while Sid had already get llvm-11 removed. > I have tried to cherry-pick an upstream fix to bump llvmlite's > llvm dependency to 12/14, but the autopkgtest shows numba would > be vastly broken. > > Unless they bump LLVM dependency to a newer version: > https://github.com/numba/llvmlite/issues/897 > https://github.com/numba/llvmlite/pull/830 > there is zero chance to get numba in stable. I do not want to > bump LLVM by force and leave a broken package in stable. > > llvmlite's python 3.11 support is still on the way: > https://github.com/numba/llvmlite/issues/885 > > One possibility is that we may apply for freeze exception > and wait for the llvmlite v0.40.0 release and see whether > they will bump llvm dependency. > > > On Thu, 2022-12-22 at 18:46 +, Stefano Rivera wrote: > > Hi Timo (2022.12.22_12:56:20_+) > > > > There have been rebuilds in Ubuntu that give us some idea of how much > > > > work remains. I think it's tractable, but also will have some package > > > > casualties. > > > I have some spare time right now, and I am happy to help > > > work on problematic cases, so hopefully nobody will feel left out in > > > the cold with their favorite packages. > > > > Offhand, the one I most expect trouble with is numba. We were reliant on > > upstream for the 3.10 transition, and probably will be for 3.11. > > > > Thanks for your help with pony ORM, Timo. I didn't think we'd be able to > > port that without upstream, but it did end up being tractable. > > > > I'm expecting to have more time in the upcoming weeks, too. > > > > So, release team, I still think we should go ahead! > > > > SR > > >
Re: Python 3.11 for bookworm?
I'm the regular uploader of python3-llvmlite. Please give up with numba. Its core dependency llvmlite is not even ready for llvm != 11, while Sid had already get llvm-11 removed. I have tried to cherry-pick an upstream fix to bump llvmlite's llvm dependency to 12/14, but the autopkgtest shows numba would be vastly broken. Unless they bump LLVM dependency to a newer version: https://github.com/numba/llvmlite/issues/897 https://github.com/numba/llvmlite/pull/830 there is zero chance to get numba in stable. I do not want to bump LLVM by force and leave a broken package in stable. llvmlite's python 3.11 support is still on the way: https://github.com/numba/llvmlite/issues/885 One possibility is that we may apply for freeze exception and wait for the llvmlite v0.40.0 release and see whether they will bump llvm dependency. On Thu, 2022-12-22 at 18:46 +, Stefano Rivera wrote: > Hi Timo (2022.12.22_12:56:20_+) > > > There have been rebuilds in Ubuntu that give us some idea of how much > > > work remains. I think it's tractable, but also will have some package > > > casualties. > > I have some spare time right now, and I am happy to help > > work on problematic cases, so hopefully nobody will feel left out in > > the cold with their favorite packages. > > Offhand, the one I most expect trouble with is numba. We were reliant on > upstream for the 3.10 transition, and probably will be for 3.11. > > Thanks for your help with pony ORM, Timo. I didn't think we'd be able to > port that without upstream, but it did end up being tractable. > > I'm expecting to have more time in the upcoming weeks, too. > > So, release team, I still think we should go ahead! > > SR >
Re: Python 3.11 for bookworm?
There is not yet an accurate estimate of time required to fix the python packages during the transition -- and I still remember the transition from python3.9 -> python3.10 took a very long period that does not seem short enough to be covered by the freeze schedule. Apart from that, package maintainers have their own plans as well. I believe that at the current stage, many people have assumed that the next stable will ship python3.10, and have their packages finalized for freeze already. Making that transition at the current stage will push a number of maintainers into a rush of updating their packages again -- in the worst case, the package upstreams might be not even ready for python 3.11. A significant Python performance improvement in 3.11 is good. But note, when python performance has really become an issue, people already have mature solutions, e.g. offloading the performance critical part onto a compiled language. I think the risk of greatly breaking the release plan outweighs the gain. On Wed, 2022-12-21 at 20:21 -0500, Nicholas D Steeves wrote: > Sandro Tosi writes: > > > thoughts from a concerned maintainer > > > > Sandro, thank you for writing this email. > > > > > it seems this email advocates for a "let's wing it"[1] type of > > transition. > > > > [1] https://en.wiktionary.org/wiki/wing_it > > > > It appears there has been little work in preparing the work to > > introduce python3.11 from its maintainer, instead that works has > > been > > pushed downstream to maintainers. > > > > if we continue with the plan as described above, several python > > libraries/applications maintainers will be left with the short end > > of > > the stick and deal with an unknown amount of issues (upstream fixes > > not available, not ready and or/ not released, rushed, etc) with > > less > > than a month from the beginning of the transition freeze[2] > > > > Agreed. At a bare minimum, complete data from ratt (Rebuild All The > Things) should be required at this point. > > > [2] https://release.debian.org/bullseye/freeze_policy.html > > > > [2] also highlights at the very beginning "Plan your changes for > > bullseye", this change appears as if it was not planned and we > > should > > be skeptical to proceed without further (and in advance) > > understanding > > of the impact it may have on Bullseye. > > > > 100% +1 I'm especially concerned about how a clear plan was not > communicated to other teams--whose work will be broken by the > proposed > transition, were an exception to be granted. > > Debian is not a paragon of community if it makes late, unannounced > changes that result in a yet-undetermined number of projects being > dropped from bookworm's release. If Python 3.11 as the only > supported > version is a release goal, then the freeze schedule would need to be > modified. > > Regards, > Nicholas
Bug#1024380: transition: simdjson
Uploaded to unstable. Successfully built on all release archs: https://buildd.debian.org/status/package.php?p=simdjson On Sat, 2022-11-19 at 20:19 +0100, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > On 2022-11-18 09:42:10 -0500, M. Zhou wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Dear release team, > > > > There was some minor API updates in the latest version of simdjson, > > which resulted an SOVERSION bump from 13 to 14. I've tried to build > > its reverse dependencies locally on an amd64 host, and the results > > are all good: > > > > cloudflare-ddns [ok] > > pcm [ok] > > > > I'd like to transit and let the next stable release > > ship the latest version. > > Please go ahead. > > Cheers
Bug#1024380: transition: simdjson
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear release team, There was some minor API updates in the latest version of simdjson, which resulted an SOVERSION bump from 13 to 14. I've tried to build its reverse dependencies locally on an amd64 host, and the results are all good: cloudflare-ddns [ok] pcm [ok] I'd like to transit and let the next stable release ship the latest version. Ben file: title = "simdjson"; is_affected = .depends ~ "libsimdjson13" | .depends ~ "libsimdjson14"; is_good = .depends ~ "libsimdjson14"; is_bad = .depends ~ "libsimdjson13"; Thank you for using reportbug
Bug#1021205: transition: simdjson
Thanks. It has been uploaded to unstable. On Fri, 2022-10-07 at 10:23 +0200, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 03/10/2022 19:22, M. Zhou wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Hi release team, > > > > I'd like to start the transition of simdjson. It has only two > > reverse > > dependencies in testing: > > > > cloudflare-ddns > > pcm > > > > Both of them passed my local test with amd64 host. > > Go ahead. > > Cheers, > Emilio >
Bug#1021205: transition: simdjson
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi release team, I'd like to start the transition of simdjson. It has only two reverse dependencies in testing: cloudflare-ddns pcm Both of them passed my local test with amd64 host. Ben file: title = "simdjson"; is_affected = .depends ~ "libsimdjson9" | .depends ~ "libsimdjson13"; is_good = .depends ~ "libsimdjson13"; is_bad = .depends ~ "libsimdjson9"; Thank you for using reportbug
Bug#1020541: transition: rakudo
Thanks. rakudo 2022.07-1 has been uploaded to unstable. On Sun, 2022-09-25 at 15:49 +0200, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > On 2022-09-22 19:23:13 -0400, M. Zhou wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Dear release team, > > > > We would like to upload rakudo 2022.07 to unstable (2022.04). > > Hence requesting this transition to rebuild all raku packages. > > Please go ahead > > Cheers > > > > > > > Ben file: > > > > title = "rakudo"; > > is_affected = .depends ~ "raku-api-2022.04" | .depends ~ "raku-api- > > 2022.07"; > > is_good = .depends ~ "raku-api-2022.07"; > > is_bad = .depends ~ "raku-api-2022.04"; > > Thank you for using reportbug > > >
Bug#1020541: transition: rakudo
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear release team, We would like to upload rakudo 2022.07 to unstable (2022.04). Hence requesting this transition to rebuild all raku packages. Ben file: title = "rakudo"; is_affected = .depends ~ "raku-api-2022.04" | .depends ~ "raku-api-2022.07"; is_good = .depends ~ "raku-api-2022.07"; is_bad = .depends ~ "raku-api-2022.04"; Thank you for using reportbug
Bug#1007222: transition: onetbb
I've filed the RM bug here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014990 Seems that we still have a bunch of blockers -- so this is not likely happening soon. On Fri, 2022-07-15 at 20:16 +0200, Graham Inggs wrote: > Hi > > libtbb2 is now gone from testing. Please file a RM bug for src:tbb > against ftp.debian.org, but maybe tag it 'moreinfo' until it is clear > what will happen to libtbb2's reverse-dependencies still in unstable. > > Regards > Graham
Bug#1014569: transition: flatbuffers
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition PyTorch 1.12 will need flatbuffers 2.X . Specifically I'm going to upload flatbuffers 2.0.6+dfsg1 to unstable. It has three reverse dependencies as per build-rdeps. vast [already ftbfs due to libfmt] #1001527 kodi [already ftbfs due to ffmpeg] #1004612 armnn [ok] 20.08-10 Seems that we can go ahead with this. Ben file: title = "flatbuffers"; is_affected = .depends ~ "libflatbuffers1" | .depends ~ "libflatbuffers2"; is_good = .depends ~ "libflatbuffers2"; is_bad = .depends ~ "libflatbuffers1"; Thank you for using reportbug
Bug#1012362: transition: luajit
Hi Paul, I did not file the corresponding bugs. According to our workflow, will I or the release team file those bugs? If it is me who should file those bugs, I think the default severity should be serious. When all related bugs are resolved by reverse dependencies, I plan to remove ppc64el architecture from both src:luajit and src:luajit2, so that malfunctional binary packages are no longer built for it. On Mon, 2022-06-20 at 22:10 +0200, Paul Gevers wrote: > Hi Mo, > > On 13-06-2022 05:20, M. Zhou wrote: > > So let's inform the reverse dependencies to remove ppc64el support, > > or switch back to lua. > > Just curious, have you already done so? If yes, care to share the bug > report numbers? Otherwise I assume you expected me to file those bugs? > > Paul > > elbrus@coccia:~$ dak rm --no-action -R --suite testing luajit > --architecture=ppc64elW: -a/--architecture implies -p/--partial. > Will remove the following packages from testing: > > libluajit-5.1-2 | 2.1.0~beta3+dfsg-6 | ppc64el > libluajit-5.1-dev | 2.1.0~beta3+dfsg-6 | ppc64el > luajit | 2.1.0~beta3+dfsg-6 | source, ppc64el > > Maintainer: Enrico Tassi > > --- Reason --- > > -- > > Checking reverse dependencies... > # Broken Depends: > lua-ljsyscall: lua-ljsyscall > > # Broken Build-Depends: > bpfcc: libluajit-5.1-dev > luajit > cantor: libluajit-5.1-dev > dnsjit: libluajit-5.1-dev > luajit > efl: libluajit-5.1-dev > fastnetmon: libluajit-5.1-dev > love: libluajit-5.1-dev > lua-ljsyscall: luajit > nageru: libluajit-5.1-dev > nginx: libluajit-5.1-dev > obs-studio: libluajit-5.1-dev > suricata: libluajit-5.1-dev > uftrace: libluajit-5.1-dev > wrk: libluajit-5.1-dev > luajit > > Dependency problem found.
Bug#1007222: transition: onetbb
Hi Andrius, Thank you so much for the help! I was still looking for time slot to login into a build server to deal with this hard-to-build package. Nowadays I sort of started to dislike packages that my laptop cannot easily build within a few minutes :-) On Mon, 2022-06-13 at 11:57 +0300, Andrius Merkys wrote: > Hi, > > On 2022-06-12 10:29, Graham Inggs wrote: > > Please go ahead with the upload of onetbb to unstable. > > Uploaded. Thanks for the guidance! > > Best wishes, > Andrius >
Bug#1012362: transition: luajit
On Sun, 2022-06-12 at 21:19 +0200, Paul Gevers wrote: > Hi Mo, > > On 10-06-2022 08:00, M. Zhou wrote: > > > There are some compilation flags tweakable. I'll try with > > > qemu to see whether I can make it work. > > > > I tried to tweak some compilation flags, and did not manage to make it > > work on ppc64el (qemu), even if I use the -DLUAJIT_DISABLE_JIT macro. > > Segfault persists. > > > > So src:luajit2 is still seemingly badly broken for ppc64el. > > Do you have a proposal how to continue? If you believe this can be fixed > soon (with help from upstream?) I'm OK with trying, but otherwise we > should inform the reverse dependencies on ppc64el that they have to > either remove themselves on ppc64el or switch to lua if that works for > them too. I don't want this lingering for months. src:luajit is > out-of-sync between testing and unstable since January already. After browsing the corresponding github issues I think there is virtually nobody working on the ppc64el port. And I don't have any idea on how to fix it. So let's inform the reverse dependencies to remove ppc64el support, or switch back to lua. The only outcome for this luajit2 transition is that s390x seems working.
Bug#1012362: transition: luajit
On Thu, 2022-06-09 at 21:51 -0700, M. Zhou wrote: > > > lua-moses autopkgtest failure [2] looks bad (still a segmentation fault): > > autopkgtest [07:20:14]: test command9: luajit debian/tests/simple.lua > > autopkgtest [07:20:14]: test command9: [--- > > bash: line 1: 1240 Segmentation fault bash -ec 'luajit > > debian/tests/simple.lua' 2> >(tee -a > > /tmp/autopkgtest-lxc.u7chaju_/downtmp/command9-stderr >&2) > >(tee -a > > /tmp/autopkgtest-lxc.u7chaju_/downtmp/command9-stdout) > > autopkgtest [07:20:14]: test command9: ---] > > There are some compilation flags tweakable. I'll try with > qemu to see whether I can make it work. I tried to tweak some compilation flags, and did not manage to make it work on ppc64el (qemu), even if I use the -DLUAJIT_DISABLE_JIT macro. Segfault persists. So src:luajit2 is still seemingly badly broken for ppc64el.
Bug#1012362: transition: luajit
On Thu, 2022-06-09 at 13:58 +0200, Paul Gevers wrote: > Hi Mo, > > You may want to look at the FTBFS on mipsel for python-lupa. > > https://buildd.debian.org/status/fetch.php?pkg=python-lupa&arch=mipsel&ver=1.13%2Bdfsg-1%2Bb2&stamp=1654771416&raw=0 Yunqiang Su (@syq) volunteers to look into luajit issues on mips* architecture.
Bug#1012362: transition: luajit
On Thu, 2022-06-09 at 10:47 +0200, Paul Gevers wrote: > > I think there one more *test* issue, the first test in src:luajit > doens't explicitly declare dependencies, which means it implicitly has > has '@'. Quoting [1]: > > > Which means that autopkgtest asks apt to make sure all packages from > src:luajit are installed, but the dependency tree of bin:luajit > conflicts with some. This can be solved by only depending on luajit, as > that pulls in the required packages anyways. > Yes. The libluajit-5.1-common has conflicts. Fixed in git: https://salsa.debian.org/lua-team/luajit/-/commit/0489ec840f2ab240785ecd8190962cb779858c29 > lua-moses autopkgtest failure [2] looks bad (still a segmentation fault): > autopkgtest [07:20:14]: test command9: luajit debian/tests/simple.lua > autopkgtest [07:20:14]: test command9: [--- > bash: line 1: 1240 Segmentation fault bash -ec 'luajit > debian/tests/simple.lua' 2> >(tee -a > /tmp/autopkgtest-lxc.u7chaju_/downtmp/command9-stderr >&2) > >(tee -a > /tmp/autopkgtest-lxc.u7chaju_/downtmp/command9-stdout) > autopkgtest [07:20:14]: test command9: ---] There are some compilation flags tweakable. I'll try with qemu to see whether I can make it work.
Bug#1012362: transition: luajit
https://qa.debian.org/excuses.php?package=luajit autopkgtest on ibm archs encountered somewhat regression, since I only removed Conflicts+Replaces from the src:luajit side. I fixed this issue and uploaded src:luajit2 https://salsa.debian.org/lua-team/luajit2/-/commit/12818940efdf76cf48b8e2cfea2dfaa5dc11664a luajit2 (2.1-20220411-5) unstable Now it should be fine after several hours when we retry the autopkgtest. On Tue, 2022-06-07 at 22:28 -0700, M. Zhou wrote: > https://buildd.debian.org/status/package.php?p=luajit > All green, including ppc64el and s390x > (arch-specific transitional dummy package) > > Seems we are ready to start the rebuild? > > On Tue, 2022-06-07 at 20:37 -0700, M. Zhou wrote: > > On Tue, 2022-06-07 at 20:03 -0700, M. Zhou wrote: > > > > > > > > > > > Yes, except for the part about patching d/control. We'll have to find > > > > another way. An alternative to what I wrote before is a extension of > > > > the > > > > description to say that the binary is empty on s390x and ppc64el. > > > > > > So both patching control and double stanza do not work. Currently > > > the only solution that I can think of is to upload a NEW empty > > > dummy source package: > > > > > > src:luajit-ibm-transition > > > * bin:luajit > > >Architecture: ppc64el s390x > > >Depends: luajit2 > > > * ... > > > > > > > I realized that the solution is very simple. > > I can simply re-enable ppc64el s390x, and install nothing into the binary > > packages. Simple tweak on Depends/Conclicts/Replaces should be enough: > > https://salsa.debian.org/lua-team/luajit/-/commit/0cc94e0caf8f78568c42c8fdf8db0c34766710fa > > > > I built the package locally, and additionally with sbuild/qemu ppc64el. > > See following the trimmed debc information. I'm uploading this revision > > shortly. > > > > = > > > > > > libluajit-5.1-2_2.1.0~beta3+git20220320+dfsg-2_amd64.deb > > > > new Debian package, version 2.0. > > size 256424 bytes: control archive=1760 bytes. > > 833 bytes,20 lines control > > 240 bytes, 3 lines md5sums > > 66 bytes, 1 lines shlibs > > 4702 bytes, 148 lines symbols > > 67 bytes, 2 lines triggers > > Package: libluajit-5.1-2 > > Source: luajit > > Version: 2.1.0~beta3+git20220320+dfsg-2 > > Architecture: amd64 > > Maintainer: Debian Lua Team > > Installed-Size: 581 > > Depends: libluajit-5.1-common (= 2.1.0~beta3+git20220320+dfsg-2), libc6 > > (>= 2.29), libgcc-s1 (>= 3.3) > > Conflicts: libluajit2-5.1-2 > > Replaces: libluajit2-5.1-2 > > > > libluajit-5.1-common_2.1.0~beta3+git20220320+dfsg-2_all.deb > > --- > > new Debian package, version 2.0. > > size 49592 bytes: control archive=1104 bytes. > > 523 bytes,15 lines control > > 1503 bytes,19 lines md5sums > > Package: libluajit-5.1-common > > Source: luajit > > Version: 2.1.0~beta3+git20220320+dfsg-2 > > Architecture: all > > Maintainer: Debian Lua Team > > Installed-Size: 218 > > Conflicts: libluajit2-5.1-common > > Replaces: libluajit2-5.1-common > > > > libluajit-5.1-dev_2.1.0~beta3+git20220320+dfsg-2_amd64.deb > > -- > > new Debian package, version 2.0. > > size 275064 bytes: control archive=916 bytes. > > 537 bytes,16 lines control > > 710 bytes,10 lines md5sums > > Package: libluajit-5.1-dev > > Source: luajit > > Version: 2.1.0~beta3+git20220320+dfsg-2 > > Architecture: amd64 > > Maintainer: Debian Lua Team > > Installed-Size: 771 > > Depends: libluajit-5.1-2 (= 2.1.0~beta3+git20220320+dfsg-2) > > Conflicts: libluajit2-5.1-dev > > Replaces: libluajit2-5.1-dev > > > > luajit_2.1.0~beta3+git20220320+dfsg-2_amd64.deb > > --- > > new Debian package, version 2.0. > > size 262800 bytes: control archive=888 bytes. > > 857 bytes,19 lines control > > 254 bytes, 4 lines md5sums > > Package: luajit > > Version: 2.1.0~beta3+git20220320+dfsg-2 > > Architecture: amd64 > > Maintainer: Debian Lua Team > > Installed-Size: 592 >
Bug#1012362: transition: luajit
https://buildd.debian.org/status/package.php?p=luajit All green, including ppc64el and s390x (arch-specific transitional dummy package) Seems we are ready to start the rebuild? On Tue, 2022-06-07 at 20:37 -0700, M. Zhou wrote: > On Tue, 2022-06-07 at 20:03 -0700, M. Zhou wrote: > > > > > > > > Yes, except for the part about patching d/control. We'll have to find > > > another way. An alternative to what I wrote before is a extension of the > > > description to say that the binary is empty on s390x and ppc64el. > > > > So both patching control and double stanza do not work. Currently > > the only solution that I can think of is to upload a NEW empty > > dummy source package: > > > > src:luajit-ibm-transition > > * bin:luajit > >Architecture: ppc64el s390x > >Depends: luajit2 > > * ... > > > > I realized that the solution is very simple. > I can simply re-enable ppc64el s390x, and install nothing into the binary > packages. Simple tweak on Depends/Conclicts/Replaces should be enough: > https://salsa.debian.org/lua-team/luajit/-/commit/0cc94e0caf8f78568c42c8fdf8db0c34766710fa > > I built the package locally, and additionally with sbuild/qemu ppc64el. > See following the trimmed debc information. I'm uploading this revision > shortly. > > = > > > libluajit-5.1-2_2.1.0~beta3+git20220320+dfsg-2_amd64.deb > > new Debian package, version 2.0. > size 256424 bytes: control archive=1760 bytes. > 833 bytes,20 lines control > 240 bytes, 3 lines md5sums > 66 bytes, 1 lines shlibs > 4702 bytes, 148 lines symbols > 67 bytes, 2 lines triggers > Package: libluajit-5.1-2 > Source: luajit > Version: 2.1.0~beta3+git20220320+dfsg-2 > Architecture: amd64 > Maintainer: Debian Lua Team > Installed-Size: 581 > Depends: libluajit-5.1-common (= 2.1.0~beta3+git20220320+dfsg-2), libc6 (>= > 2.29), libgcc-s1 (>= 3.3) > Conflicts: libluajit2-5.1-2 > Replaces: libluajit2-5.1-2 > > libluajit-5.1-common_2.1.0~beta3+git20220320+dfsg-2_all.deb > --- > new Debian package, version 2.0. > size 49592 bytes: control archive=1104 bytes. > 523 bytes,15 lines control > 1503 bytes,19 lines md5sums > Package: libluajit-5.1-common > Source: luajit > Version: 2.1.0~beta3+git20220320+dfsg-2 > Architecture: all > Maintainer: Debian Lua Team > Installed-Size: 218 > Conflicts: libluajit2-5.1-common > Replaces: libluajit2-5.1-common > > libluajit-5.1-dev_2.1.0~beta3+git20220320+dfsg-2_amd64.deb > -- > new Debian package, version 2.0. > size 275064 bytes: control archive=916 bytes. > 537 bytes,16 lines control > 710 bytes,10 lines md5sums > Package: libluajit-5.1-dev > Source: luajit > Version: 2.1.0~beta3+git20220320+dfsg-2 > Architecture: amd64 > Maintainer: Debian Lua Team > Installed-Size: 771 > Depends: libluajit-5.1-2 (= 2.1.0~beta3+git20220320+dfsg-2) > Conflicts: libluajit2-5.1-dev > Replaces: libluajit2-5.1-dev > > luajit_2.1.0~beta3+git20220320+dfsg-2_amd64.deb > --- > new Debian package, version 2.0. > size 262800 bytes: control archive=888 bytes. > 857 bytes,19 lines control > 254 bytes, 4 lines md5sums > Package: luajit > Version: 2.1.0~beta3+git20220320+dfsg-2 > Architecture: amd64 > Maintainer: Debian Lua Team > Installed-Size: 592 > Depends: libluajit-5.1-2 (= 2.1.0~beta3+git20220320+dfsg-2), > libluajit-5.1-common (= 2.1.0~beta3+git20220320+dfsg-2), > libc6 (>= 2.29), libgcc-s1 (>= 3.3) > Conflicts: luajit2 > Replaces: luajit2 > > == > > libluajit-5.1-2_2.1.0~beta3+git20220320+dfsg-2_ppc64el.deb > -- > new Debian package, version 2.0. > size 7584 bytes: control archive=780 bytes. > 703 bytes,18 lines control > 158 bytes, 2 lines md5sums > Package: libluajit-5.1-2 > Source: luajit > Version: 2.1.0~beta3+git20220320+dfsg-2 > Architecture: ppc64el > Maintainer: Debian Lua Team > Installed-Size: 15 > Depends: libluajit2-5.1-2 > > libluajit-5.1-common_2.1.0~beta3+git20220320+dfsg-2_all.deb > --- > new
Bug#1012362: transition: luajit
On Tue, 2022-06-07 at 20:03 -0700, M. Zhou wrote: > > > > > Yes, except for the part about patching d/control. We'll have to find > > another way. An alternative to what I wrote before is a extension of the > > description to say that the binary is empty on s390x and ppc64el. > > So both patching control and double stanza do not work. Currently > the only solution that I can think of is to upload a NEW empty > dummy source package: > > src:luajit-ibm-transition > * bin:luajit >Architecture: ppc64el s390x >Depends: luajit2 > * ... > I realized that the solution is very simple. I can simply re-enable ppc64el s390x, and install nothing into the binary packages. Simple tweak on Depends/Conclicts/Replaces should be enough: https://salsa.debian.org/lua-team/luajit/-/commit/0cc94e0caf8f78568c42c8fdf8db0c34766710fa I built the package locally, and additionally with sbuild/qemu ppc64el. See following the trimmed debc information. I'm uploading this revision shortly. = libluajit-5.1-2_2.1.0~beta3+git20220320+dfsg-2_amd64.deb new Debian package, version 2.0. size 256424 bytes: control archive=1760 bytes. 833 bytes,20 lines control 240 bytes, 3 lines md5sums 66 bytes, 1 lines shlibs 4702 bytes, 148 lines symbols 67 bytes, 2 lines triggers Package: libluajit-5.1-2 Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: amd64 Maintainer: Debian Lua Team Installed-Size: 581 Depends: libluajit-5.1-common (= 2.1.0~beta3+git20220320+dfsg-2), libc6 (>= 2.29), libgcc-s1 (>= 3.3) Conflicts: libluajit2-5.1-2 Replaces: libluajit2-5.1-2 libluajit-5.1-common_2.1.0~beta3+git20220320+dfsg-2_all.deb --- new Debian package, version 2.0. size 49592 bytes: control archive=1104 bytes. 523 bytes,15 lines control 1503 bytes,19 lines md5sums Package: libluajit-5.1-common Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: all Maintainer: Debian Lua Team Installed-Size: 218 Conflicts: libluajit2-5.1-common Replaces: libluajit2-5.1-common libluajit-5.1-dev_2.1.0~beta3+git20220320+dfsg-2_amd64.deb -- new Debian package, version 2.0. size 275064 bytes: control archive=916 bytes. 537 bytes,16 lines control 710 bytes,10 lines md5sums Package: libluajit-5.1-dev Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: amd64 Maintainer: Debian Lua Team Installed-Size: 771 Depends: libluajit-5.1-2 (= 2.1.0~beta3+git20220320+dfsg-2) Conflicts: libluajit2-5.1-dev Replaces: libluajit2-5.1-dev luajit_2.1.0~beta3+git20220320+dfsg-2_amd64.deb --- new Debian package, version 2.0. size 262800 bytes: control archive=888 bytes. 857 bytes,19 lines control 254 bytes, 4 lines md5sums Package: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: amd64 Maintainer: Debian Lua Team Installed-Size: 592 Depends: libluajit-5.1-2 (= 2.1.0~beta3+git20220320+dfsg-2), libluajit-5.1-common (= 2.1.0~beta3+git20220320+dfsg-2), libc6 (>= 2.29), libgcc-s1 (>= 3.3) Conflicts: luajit2 Replaces: luajit2 == libluajit-5.1-2_2.1.0~beta3+git20220320+dfsg-2_ppc64el.deb -- new Debian package, version 2.0. size 7584 bytes: control archive=780 bytes. 703 bytes,18 lines control 158 bytes, 2 lines md5sums Package: libluajit-5.1-2 Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: ppc64el Maintainer: Debian Lua Team Installed-Size: 15 Depends: libluajit2-5.1-2 libluajit-5.1-common_2.1.0~beta3+git20220320+dfsg-2_all.deb --- new Debian package, version 2.0. size 49592 bytes: control archive=1104 bytes. 523 bytes,15 lines control 1503 bytes,19 lines md5sums Package: libluajit-5.1-common Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: all Maintainer: Debian Lua Team Installed-Size: 218 Conflicts: libluajit2-5.1-common Replaces: libluajit2-5.1-common libluajit-5.1-dev_2.1.0~beta3+git20220320+dfsg-2_ppc64el.deb new Debian package, version 2.0. size 7444 bytes: control archive=636 bytes. 447 bytes,14 lines control 162 bytes, 2 lines md5sums Package: libluajit-5.1-dev Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: ppc64el Maintainer: Debian Lua Team In
Bug#1012362: transition: luajit
On Tue, 2022-06-07 at 21:21 +0200, Paul Gevers wrote: > Hi Mo, > > On 07-06-2022 17:36, M. Zhou wrote: > > This should be achievable by patching debian/control > > during build once detected IBM architectures. > > This is not allowed. I currently fail to find where that's written down, > but I'm fairly sure that the relevant parties agree that debian/control > must not be mangled with during build. The ftp-reject list touches upon > it, albeit for a different reason [1]. debian/control has to be > unchanged in source. But, maybe you can try to add two stanza's for the > same binary name, one with the Archs !s390x !ppc64el and another for > s390x and ppc64el. I'm not totally sure if that's allowed and if the > tools handle it well, but may be worth a try. Indeed that's not allowed, although I should have seen some of such examples years ago IIRC. Apart from that, additional binary package entry with different architecture will be deemed as duplicate: dh: error: debian/control has a duplicate entry for luajit > > IIRC adding new architecture without new binary package > > does not have to go through NEW. > > Indeed, they don't. > > > Does that sound good? > > Yes, except for the part about patching d/control. We'll have to find > another way. An alternative to what I wrote before is a extension of the > description to say that the binary is empty on s390x and ppc64el. So both patching control and double stanza do not work. Currently the only solution that I can think of is to upload a NEW empty dummy source package: src:luajit-ibm-transition * bin:luajit Architecture: ppc64el s390x Depends: luajit2 * ... > Paul > > [1] https://ftp-master.debian.org/REJECT-FAQ.html : debian/control > breakage #2 > """ > which basically means that everything must be defined at the beginning > of the build. > """ Thanks. I was not aware of this.
Bug#1012362: transition: luajit
I have uploaded luajit/unstable 2.1.0~beta3+git20210112+dfsg-2, but please hold on. I should have split the ppc64el architecture removal to a future revision... Now that the ppc64el architecture is missing for src:luajit, and we still cannot safely remove luajit:ppc64el without manually changing their build depends into libluajit2-5.1-2 [ppc64el s390x] | libluajit-5.1-2 ... I'm thinking of yet another solution for the IBM architecture transition. It's to add ppc64el and s390x back into src:luajit, but make all binary packages transitional dummy packages, i.e. Package: libluajit-5.1-2 Architecture: ppc64el s390x Depends: libluajit2-5.1-2 Description: transitional dummy package This should be achievable by patching debian/control during build once detected IBM architectures. IIRC adding new architecture without new binary package does not have to go through NEW. So this architecture-specific transitional dummy package solution should be able to help us smoothly deal with IBM architectures. Does that sound good? If so I'll prepare another upload before we really start the transition. On Mon, 2022-06-06 at 20:45 +0200, Paul Gevers wrote: > Control: tag -1 confirmed > Control: forwarded -1 > https://release.debian.org/transitions/html/libluajit2-support.html > > Hi Mo, > > On 05-06-2022 19:30, M. Zhou wrote: > > So, currently I have a pending commit[2] modifying the dependency > > template[1], > > so that src:luajit reverse dependencies can be rebuilt without source > > modification to allow library fallback. > > > > Specifically, before transition, luajit reverse dependencies will have: > >Depends: libluajit-5.1-2 > > After transition, they should have: > >Depends: libluajit-5.1-2 | libluajit2-5.1-2 > > And the only thing we need to do is to upload the pending commit[2] > > once approved. Then we just trigger a rebuild for all luajit reverse > > dependencies. > > Please go ahead. > > Paul
Re: kind of special transition for luajit{,2}?
On Sun, 2022-06-05 at 19:37 +0200, Paul Gevers wrote: > Hi, > > On 05-06-2022 19:35, M. Zhou wrote: > > > But if this is really the result of the rebuild. I think we just > > > discovered a serious flaw. The alternative dependency on libluajit-5.1-2 > > > just lost its version constraint, as it's only added to libluajit2-5.1-2. > > > > U... Yes, that's a good catch. > > > > I fixed this versioned dependency issue with the following commit: > > https://salsa.debian.org/lua-team/luajit/-/commit/561f846d9c845876715eef086aeb9ff0fd80 > > (pending to upload to unstable upon transition approval) > > Ha, but because libluajit2-5.1-2 is new, it doesn't require a version > AFAICT. Technically yes. And the first version of src:luajit2 is greater than that number. But logically luajit2 (<= 2.1~) may be really missing symbols based on the src:luajit symbol control file tracking record. So either way works for us. Let's go ahead with it.
Re: kind of special transition for luajit{,2}?
On Sun, 2022-06-05 at 11:43 +0200, Paul Gevers wrote: > > > sbuild --no-clean -c sid -d unstable love_11.3-1.dsc --extra-package > > ../luajit.pkg/ > > debc love_11.3-1_amd64.changes > > > > Package: love > > Version: 11.3-1 > > Architecture: amd64 > > Maintainer: Debian Games Team > > Installed-Size: 4521 > > Depends: libc6 (>= 2.33), libfreetype6 (>= 2.2.1), libgcc-s1 (>= 3.4), > > libluajit-5.1-2 | libluajit2-5.1-2 (>= > > 2.0.4+dfsg), libmodplug1 (>= 1:0.8.8.5), libmpg123-0 (>= 1.28.0), libogg0 > > (>= 1.1.4~dfsg), libopenal1 (>= 1.14), > > But if this is really the result of the rebuild. I think we just > discovered a serious flaw. The alternative dependency on libluajit-5.1-2 > just lost its version constraint, as it's only added to libluajit2-5.1-2. U... Yes, that's a good catch. I fixed this versioned dependency issue with the following commit: https://salsa.debian.org/lua-team/luajit/-/commit/561f846d9c845876715eef086aeb9ff0fd80 (pending to upload to unstable upon transition approval) And the generated dependency looks like this: Package: love Version: 11.3-1 Architecture: amd64 Maintainer: Debian Games Team Installed-Size: 4521 Depends: libc6 (>= 2.33), libfreetype6 (>= 2.2.1), libgcc-s1 (>= 3.4), libluajit-5.1-2 (>= 2.0.4+dfsg) | libluajit2- 5.1-2 (>= 2.1~), libmodplug1 (>= 1:0.8.8.5), libmpg123-0 (>= 1.28.0), libogg0 (>= 1.1.4~dfsg), libopenal1 (>= 1.14), libsdl2-2.0-0 (>= 2.0.12), libstdc++6 (>= 11), libtheora0 (>= 1.0), libvorbisfile3 (>= 1.1.2), zlib1g (>= 1:1.2.0) > > To me (there are other Release Members more involved in transitions) > this feels a bit like an "add supported version" like we do for e.g. > Python and Ruby. Those are normally not interfering with other > transitions as any rebuilt binary can just migrate (once src:luajit2 is > in testing) on its own. > Yes. Theoretically this won't break anything. FTBFS issues (if any) will have different reasons. > Please file the transition bug and I expect we can just proceed > (assuming my colleagues don't object), and that version issue is > investigated. > The transition bug is opened here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012362 and the versioned depenency issue has been fixed in git.
Bug#1012362: transition: luajit
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition This bug is follow-up for this thread: https://lists.debian.org/debian-release/2022/06/msg9.html The original LuaJIT upstream does not care about IBM architectures, which causes problem in downstreams including us. I packaged src:luajit2 which seems to be working well for IBM architectures. src:luajit2 can be used as a drop-in replacement for src:luajit. So, currently I have a pending commit[2] modifying the dependency template[1], so that src:luajit reverse dependencies can be rebuilt without source modification to allow library fallback. Specifically, before transition, luajit reverse dependencies will have: Depends: libluajit-5.1-2 After transition, they should have: Depends: libluajit-5.1-2 | libluajit2-5.1-2 And the only thing we need to do is to upload the pending commit[2] once approved. Then we just trigger a rebuild for all luajit reverse dependencies. This is a special transition that should not break any package at all, as it is just inserting an alternative dependency. (I don't know how to write a correct ben file for such special case.) Ben file: title = "luajit"; is_affected = .depends ~ "libluajit-5.1-2" | .depends ~ "libluajit-5.1-2"; is_good = .depends ~ "libluajit2-5.1-2"; is_bad = .depends ~ "libluajit-5.1-2"; Thank you for using reportbug [1] deb-symbols(5), this is an less-known advanced usage. [2] https://salsa.debian.org/lua-team/luajit/-/commit/561f846d9c845876715eef086aeb9ff0fd80
Re: kind of special transition for luajit{,2}?
On Sat, 2022-06-04 at 08:19 +0200, Paul Gevers wrote: > > > So I uploaded luajit2, which at least passed hello world smoke > > test on IBM arches including ppc64el and s390x. > > https://buildd.debian.org/status/package.php?p=luajit2 > > May I ask what your reason is to have both? Why not replace luajit with > luajit2 and be done with it? Currently I have no idea whether src:luajit2 can completely replace src:luajit. I plan to keep them both for a while and see. That said, due to the uncooperative fact of the src:luajit upstream, I lean toward removing it once we're confident about the replacement. > > So I changed the dependency template for bin:libluajit-5.1-2 > > You use the word template several times in your message. Do you mean > template in the sense that it's manually applied in all places, or is > there automation involved I'm not aware of? Please see deb-symbols(5), the symbols control file contains a part supporting advanced usage that not all Debian developers know: main-dependency-template | alternative-dependency-template The examples section of deb-symbols(5) is instructive about this feature. More than one of packages I maintain has leveraged such feature (like BLAS alternatives). I can give an extra example to prove this: currently I have a pending commit to change the src:luajit dependency template: https://salsa.debian.org/lua-team/luajit/-/commit/06f74ff251646e159afba9b9a8dc2488ec848a75 We take src:love as example. The current bin:love package has the following dependency: Package: love Version: 11.3-1 Priority: optional Section: games Maintainer: Debian Games Team Installed-Size: 4,593 kB Depends: libc6 (>= 2.29), libfreetype6 (>= 2.2.1), libgcc-s1 (>= 3.4), libluajit-5.1-2 (>= 2.0.4+dfsg), libmodplug1 (>= 1:0.8.8.5), libmpg123-0 (>= 1.13.7), libogg0 (>= 1.1.4~dfsg), libopenal1 (>= 1.14), libsdl2-2.0-0 (>= 2.0.10), libstdc++6 (>= 5.2), libtheora0 (>= 1.0), libvorbisfile3 (>= 1.1.2), zlib1g (>= 1:1.2.0) Recommends: binfmt-support Then I rebuild it against with the above luajit commit pending to upload: sbuild --no-clean -c sid -d unstable love_11.3-1.dsc --extra-package ../luajit.pkg/ debc love_11.3-1_amd64.changes Package: love Version: 11.3-1 Architecture: amd64 Maintainer: Debian Games Team Installed-Size: 4521 Depends: libc6 (>= 2.33), libfreetype6 (>= 2.2.1), libgcc-s1 (>= 3.4), libluajit-5.1-2 | libluajit2-5.1-2 (>= 2.0.4+dfsg), libmodplug1 (>= 1:0.8.8.5), libmpg123-0 (>= 1.28.0), libogg0 (>= 1.1.4~dfsg), libopenal1 (>= 1.14), libsdl2-2.0-0 (>= 2.0.12), libstdc++6 (>= 11), libtheora0 (>= 1.0), libvorbisfile3 (>= 1.1.2), zlib1g (>= 1:1.2.0) See the dependency change? Note, there is ZERO change for the src:love package at all. This is a super awesome feature of Debian dependency tree. > > from > >libluajit-5.1-2 > > into > >libluajit-5.1-2 | libluajit2-5.1-2 > > Related to my question of why keep both, why not the reverse order? At the current stage, I'm not completely confident that src:luajit2 can fully replace src:luajit . We can reverse the order in the future, or directly remove src:luajit in the future. > > Since both packages Provides libluajit-5.1.so.* > > > > Thus, this is not a usual transition with ABI bump. I want to > > rebuild all luajit reverse dependencies so that the dependency > > Rebuild, or change source and reupload? Given the above illustration of dependency template, I indeed mean rebuild reverse dependencies without any change of source. > > template for them will be updated. In that case the corresponding > > reverse dependencies can smoothly start to use libluajit2-5.1-2, > > especially for ppc64el architecture. > > If you're not changing the source of all those reverse dependencies, how > does that work? deb-symbols(5). This is a great feature and advanced usage. > > When the rebuild is done, we should be able to safely remove > > ppc64el architecture for src:luajit . > > Well, as I filed RC bugs against all reverse dependencies of src:luajit > to switch their (build-)dependency on ppc64el to lua, we'll be able to > do this shortly anyways. Maybe less work is required given the possibility to change dependency without modifying the code of reverse dependencies? :-) > Paul > PS: I'd rather had it that you'd file a bug already to have this > discussion. It's much easier to track than our high volume mail list as > it keeps the pieces together. OK, understood. I'll later submit a bug pointing at this ML post.
kind of special transition for luajit{,2}?
Dear release team, I feel the case I encountered is an unusual transition, so I'd like to ask first before filing the bug. Long story short, src:luajit does not work on ppc64el because the upstream is completely not interested in supporing IBM archs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011297 So I uploaded luajit2, which at least passed hello world smoke test on IBM arches including ppc64el and s390x. https://buildd.debian.org/status/package.php?p=luajit2 Currently, src:luajit2 produces bin:luajit2, which Conflicts+Replaces bin:luajit. Meanwhile there is bin:libluajit2-5.1-2, which Conflicts +Replaces bin:libluajit-5.1-2 from original src:luajit. luajit and luajit2 are expected to be compatible in binary level. So I changed the dependency template for bin:libluajit-5.1-2 from libluajit-5.1-2 into libluajit-5.1-2 | libluajit2-5.1-2 Since both packages Provides libluajit-5.1.so.* Thus, this is not a usual transition with ABI bump. I want to rebuild all luajit reverse dependencies so that the dependency template for them will be updated. In that case the corresponding reverse dependencies can smoothly start to use libluajit2-5.1-2, especially for ppc64el architecture. When the rebuild is done, we should be able to safely remove ppc64el architecture for src:luajit . I did not change the dependency template for libluajit2-5.1-2, because it supports a wider range of architectures than the original version. Once compiled against src:luajit2, I don't hope a package fallback to use original src:luajit and crash. May I ask some suggestions on the correct way to handle such a special transition? And it is complicated as a ppc64el RC bug is involved https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011297
Bug#1007222: transition: onetbb
On Wed, 2022-06-01 at 20:29 +0200, Graham Inggs wrote: > Control: tags -1 + moreinfo > > I noticed some packages in the tracker not appearing in your list; > e.g. openimageio, pcl and yade. These packages have transitive > build-dependencies on libtbb-dev through e.g. libopenvdb-dev or > libvtk9-dev, and should be investigated as well. My bad. So solely `reverse-depends -b` may miss something. I'll investigate and append results to the transition bug. > Note that we will require fixes, or at least patches, for "key > packages" [1] before starting with this transition, and at least > trilinos is currently on that list. > > It may be worth considering again Matthias' suggestion in #1006920 to > keep the old tbb package around as libtbb2-dev and libtbb2-doc in > order to allow packages like numba to get the new tbb soon, and other > packages stuck with the old tbb more time to get fixed. I personally dislike making the old package libtbb2-dev. How about we make the old src:tbb package go through NEW again with the following renames: libtbb-dev -> libtbb-legacy-dev, this sounds much better than libtbb2-dev because it explains itself to be a to-be-deprecated version. In this way we can finish the transition very quickly and leave longer time for broken packages to migrate to onetbb. For me, submitting patches is as well much easier as I only have to change libtbb-dev -> libtbb-legacy-dev for broken packages.
Bug#1011345: transition: rakudo
On Sat, 2022-05-28 at 12:16 +0200, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > On 2022-05-20 10:36:34 -0400, M. Zhou wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Dear release team, > > > > We have uploaded rakudo 2022.04 to experimental, and would like to > > start the transition and rebuild packages > > Please go ahead > Uploaded to unstable.
Bug#1007222: transition: onetbb
This is the most uneasy transition I've ever handled. There was massive upstream code overhaul breaking basically everything. Build system has changed so I rewritten the d/rules, this took me a while. Going through NEW due to upstream rename took a while. Then only amd64 does not FTBFS. I wrote patches to make it green on release architectures, this took me a while. Then there is package split, which means we have to go through NEW again. This is relatively fast IIRC. Throughout the whole process I'm dealing with paper submission deadline which has passed several days ago. Before that I wasn't able to allocate time for the massive reverse dependency build. This took a while as well. Now we can finally go ahead. On Wed, 2022-05-25 at 20:07 -0400, M. Zhou wrote: > Control: tags -1 -moreinfo > > Reverse-Build-Depends > * blender [irrelevant; ftpfs, no matching function for call to > openvdb... ] #1011653 > * bowtie [ok] > * bowtie2 [ok] > * casparcg-server [ftbfs, TBB not found during cmake] #1011654 > * deal.ii [ftbfs, cmake could not find tbb] #1011655 > * embree [ok] > * flexbar [ftbfs, cannot find tbb header] #1011656 > * gazebo [irrelevant; ftbfs, missing symbol from libtiff] #1011657 > * gudhi [ok] > * libatomic-queue [ok] > * libpmemobj-cpp [ftbfs, tbb api break] #1011658 > * macaulay2 [unknown, timeout for doc build during ThreadedGB ... > Minimal.out] > * madness [ok] > * mathicgb [ok] > * mpqc3 [irrelevant; eigen3 api break; already FTBFS] > * numba [irrelevant; incompatible with py3.10] > * onednn [ok] > * open3d [ok] > * opencascade [ftbfs; tbb api break] #1011659 > * opencv [ok] > * opensubdiv [ftbfs; tbb api break] #1011660 > * openturns [ok] > * openvdb [irrelevant; help2man error during manpage build; already > FTBFS] > * pmemkv [ok] > * ptl [ok] > * r-cran-markovchain [ftbfs; tbb api break] #1011661 > * r-cran-rcppparallel [ok] > * r-cran-uwot [ok] > * salmon [ftbfs; tbb api break] #1011662 > * slic3r-prusa [FTBFS, TBB api break] #1011663 > * sysdig [ok] > * tiledarray [irrelevant: other build depenency uninstallable] > * tiny-dnn [ftbfs, TBB not found during cmake] #1011664 > * trilinos [irrelevant: isinf not defined] > * vtk9 [ok] > > > On Sun, 2022-03-13 at 22:28 +0100, Sebastian Ramacher wrote: > Control: forwarded -1 > https://release.debian.org/transitions/html/onetbb.html > Control: tags -1 moreinfo > > On 2022-03-13 16:59:48 -0400, M. Zhou wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Hi release team, > > > > This involves an upstream source name change (from tbb to onetbb), > > as well as SOVERSION bump (from 2 to 12), along with a major API > > change including some changes in the core API. > > > > I should have submitted this after my local build test for the > > reverse dependencies of libtbb-dev, but fellow developers from > > debian-science are eager to see this in unstable to unblock > > their works. > > > > I have not tested by myself, but I heard from an archlinux > > developer that this API bump breaks a lot packages. And > > some upstreams decided to disable or drop tbb support as > > a result. I guess we can take similar measures for short > > term workaround. > > Please remove the moreinfo tag once these issues have been > investigated > and bugs have been filed. > > Cheers > > > > > Ben file: > > > > title = "tbb"; > > is_affected = .depends ~ "libtbb2" | .depends ~ "libtbb12"; > > is_good = .depends ~ "libtbb12"; > > is_bad = .depends ~ "libtbb2"; > > Thank you for using reportbug > > >
Bug#1007222: transition: onetbb
Control: tags -1 -moreinfo Reverse-Build-Depends * blender [irrelevant; ftpfs, no matching function for call to openvdb... ] #1011653 * bowtie [ok] * bowtie2 [ok] * casparcg-server [ftbfs, TBB not found during cmake] #1011654 * deal.ii [ftbfs, cmake could not find tbb] #1011655 * embree [ok] * flexbar [ftbfs, cannot find tbb header] #1011656 * gazebo [irrelevant; ftbfs, missing symbol from libtiff] #1011657 * gudhi [ok] * libatomic-queue [ok] * libpmemobj-cpp [ftbfs, tbb api break] #1011658 * macaulay2 [unknown, timeout for doc build during ThreadedGB ... Minimal.out] * madness [ok] * mathicgb [ok] * mpqc3 [irrelevant; eigen3 api break; already FTBFS] * numba [irrelevant; incompatible with py3.10] * onednn [ok] * open3d [ok] * opencascade [ftbfs; tbb api break] #1011659 * opencv [ok] * opensubdiv [ftbfs; tbb api break] #1011660 * openturns [ok] * openvdb [irrelevant; help2man error during manpage build; already FTBFS] * pmemkv [ok] * ptl [ok] * r-cran-markovchain [ftbfs; tbb api break] #1011661 * r-cran-rcppparallel [ok] * r-cran-uwot [ok] * salmon [ftbfs; tbb api break] #1011662 * slic3r-prusa [FTBFS, TBB api break] #1011663 * sysdig [ok] * tiledarray [irrelevant: other build depenency uninstallable] * tiny-dnn [ftbfs, TBB not found during cmake] #1011664 * trilinos [irrelevant: isinf not defined] * vtk9 [ok] On Sun, 2022-03-13 at 22:28 +0100, Sebastian Ramacher wrote: Control: forwarded -1 https://release.debian.org/transitions/html/onetbb.html Control: tags -1 moreinfo On 2022-03-13 16:59:48 -0400, M. Zhou wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi release team, > > This involves an upstream source name change (from tbb to onetbb), > as well as SOVERSION bump (from 2 to 12), along with a major API > change including some changes in the core API. > > I should have submitted this after my local build test for the > reverse dependencies of libtbb-dev, but fellow developers from > debian-science are eager to see this in unstable to unblock > their works. > > I have not tested by myself, but I heard from an archlinux > developer that this API bump breaks a lot packages. And > some upstreams decided to disable or drop tbb support as > a result. I guess we can take similar measures for short > term workaround. Please remove the moreinfo tag once these issues have been investigated and bugs have been filed. Cheers > > Ben file: > > title = "tbb"; > is_affected = .depends ~ "libtbb2" | .depends ~ "libtbb12"; > is_good = .depends ~ "libtbb12"; > is_bad = .depends ~ "libtbb2"; > Thank you for using reportbug >
Bug#1011345: transition: rakudo
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear release team, We have uploaded rakudo 2022.04 to experimental, and would like to start the transition and rebuild packages Ben file: title = "rakudo"; is_affected = .depends ~ "raku-api-2022.02" | .depends ~ "raku-api-2022.04"; is_good = .depends ~ "raku-api-2022.04"; is_bad = .depends ~ "raku-api-2022.02"; Thank you for using reportbug
Bug#1007222: transition: onetbb
On Thu, 2022-03-24 at 17:55 +0100, Sebastian Ramacher wrote: > > > > libtbb2 and libtbb12 contains some common files hence the conflict. > > I'd rather wait for all the reverse deps to be ready for this > > transition, compared to going through NEW again due to binary > > package change. > > This makes the transition and upgrades more painful than necessary. > The > files shared between both packages are actually shared libraries with > their own SONAME that did not change. Why are the contained in > libtbb12 > if they do not follow the same version as libtbb itself? Ok. Before we start, a user said "Following this up, the split of the libraries is breaking some common use cases in the robotics community" at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006920 But I did not figure out what bad could happen from the links provided. I'm requesting more information there. Once confirmed I'll merge doko's patches and go through NEW again.
Bug#1007222: transition: onetbb
On Thu, 2022-03-24 at 13:12 +0100, Paul Gevers wrote: > > > > "I heard from archlinux" is not good enough. I sent you email about > > this without getting a reply, then filed #1006920, without getting a > > reply, now this incomplete proposal. you may want to look at all the > > build rdeps for libtbb2-dev in Ubuntu to get an overview what at least > > breaks: Sorry for the late response but I think that's what usually happens when the maintainer is occupied by research and studies. I would not have submitted this incomplete transition slot if I did not hear so much request. I think the solution for allowing the co-existence of tbb and onetbb is not the best. Because tbb will not have upstream support in the future due to deprecation. > > > this breaks everything immediately because of the conflicting libtbb2 > > and libtbb12. Please fix this first. > > Can you please respond to these remarks? They raise valid points for us. libtbb2 and libtbb12 contains some common files hence the conflict. I'd rather wait for all the reverse deps to be ready for this transition, compared to going through NEW again due to binary package change. I've started rebuilding the reverse dependencies and filing bugs, will get back to you soon.
Bug#1007222: transition: onetbb
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi release team, This involves an upstream source name change (from tbb to onetbb), as well as SOVERSION bump (from 2 to 12), along with a major API change including some changes in the core API. I should have submitted this after my local build test for the reverse dependencies of libtbb-dev, but fellow developers from debian-science are eager to see this in unstable to unblock their works. I have not tested by myself, but I heard from an archlinux developer that this API bump breaks a lot packages. And some upstreams decided to disable or drop tbb support as a result. I guess we can take similar measures for short term workaround. Ben file: title = "tbb"; is_affected = .depends ~ "libtbb2" | .depends ~ "libtbb12"; is_good = .depends ~ "libtbb12"; is_bad = .depends ~ "libtbb2"; Thank you for using reportbug
Bug#1006274: transition: rakudo
On Tue, 2022-02-22 at 21:52 +0100, Sebastian Ramacher wrote: > > > > Rakudo upstream has released 2022.02 version, and I have uploaded it to > > experimental. In the past few weeks the architecture of the raku-* > > packages has been changed to any, which means binnmus should be possible. > > Shall we start the rakudo 2022.02 transition? > > Please go ahead Uploaded.
Bug#1006274: transition: rakudo
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear release team, Rakudo upstream has released 2022.02 version, and I have uploaded it to experimental. In the past few weeks the architecture of the raku-* packages has been changed to any, which means binnmus should be possible. Shall we start the rakudo 2022.02 transition? BTW, since we have a permanent transition tracker https://release.debian.org/transitions/html/rakudo.html Do we have to request for transition slot every time? Thanks! Ben file: title = "rakudo"; is_affected = .depends ~ "raku-api-2021.12" | .depends ~ "raku-api-2022.02"; is_good = .depends ~ "raku-api-2022.02"; is_bad = .depends ~ "raku-api-2021.12"; Thank you for using reportbug
Re: rakudo permanent tracker and transition
Now that every issue seems to have been fixed. I've uploaded the fixes (changing arch from all to any) to raku* packages as well. Transition tracker all green now. The next time when a raku-api-* bump is needed, we should be able to do it automatically with a regular transition slot. On Sat, 2022-02-05 at 20:02 +0100, Paul Gevers wrote: > Hi, > > On 05-02-2022 15:54, Dominique Dumont wrote: > > On Thursday, 3 February 2022 09:16:54 CET Paul Gevers wrote: > > > I'm slightly surprised that perl6-readline isn't picked up by the > > > tracker. We'll need to check why that is. > > > > I've a possible explanation. > > Thanks for thinking along. > > > perl6-readline depends field is: > > > > Depends: libreadline8, raku-api-2021.09 > > > > rakudo tracker is set with: > > > > Affected: .depends ~ /^raku-api-/ > > > > This fails if the regexp is applied to the *whole* Depends field > > value because > > the regexp is anchored to the beginning of the string. > > True, that's why I was pretty sure that ben only considers individual > entries. But I just checked the ben documentation [1] and believe you > are right. Particularly this: > """ > Packages fields may contain a list of values comma-separated. Ben > splits > the list before looking with "…" for a match. > """ > which suggest that doesn't apply to regular expressions and I see > loads > of (^|\s) in other ben files. > > Paul > > [1] https://debian.pages.debian.net/ben/#_query_language
rakudo permanent tracker and transition
Hi release team, Some time ago the rakudo tracker is set up https://release.debian.org/transitions/html/rakudo.html At that time packages like raku-tap-harness depends on raku-api-2021.09 , which is provided by rakudo 2021.09 Now that rakudo 2021.12 has landed onto unstable, and the API has been bumped to raku-api-2021.12 . But it did not trigger an automatic rebuild for packages depending on raku-api-2021.09 . I don't know how the transition tracker works. Could you please provide some advice on the transition?
Bug#1000553: transition: simdjson
On Wed, 2021-11-24 at 21:53 +0100, Sebastian Ramacher wrote: > Control: tags -1 confirmed > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-simdjson.html > > > Please go ahead > > Cheers > Done. All green on the tracker -- looks good.
Bug#990398: unblock: zfs-linux/2.0.3-9 (pre-approval)
Control: tags -1 -moreinfo zfs-linux 2.0.3-9 has been uploaded to unstable. On Tue, 2021-06-29 at 20:59 +0200, Sebastian Ramacher wrote: > Control: tags -1 moreinfo confirmed > > On 2021-06-28 09:01:04 +, M. Zhou wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > > > Please unblock package zfs-linux > > > > [ Reason ] > > > > We want to cherry-pick a three-line fix for an important bug. > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989373 > > > > diff --git a/module/os/linux/zfs/zpl_file.c > > b/module/os/linux/zfs/zpl_file.c > > index 421aebefe46..524c43dcded 100644 > > --- a/module/os/linux/zfs/zpl_file.c > > +++ b/module/os/linux/zfs/zpl_file.c > > @@ -342,9 +342,6 @@ zpl_iter_write(struct kiocb *kiocb, struct > > iov_iter > > *from) > > ssize_t wrote = count - uio.uio_resid; > > kiocb->ki_pos += wrote; > > > > - if (wrote > 0) > > - iov_iter_advance(from, wrote); > > - > > return (wrote); > > } > > > > > > [ Impact ] > > > > Potential memory corruption / data loss. > > > > [ Risks ] > > > > This has been sufficiently tested by ZFS upstream. And > > this fix is a part of their new stable release: > > https://github.com/openzfs/zfs/commit/412b69dfabe223a69159c8579ba808b49f0982e0 > > > > > > unblock zfs-linux/2.0.3-9 > > Thank you for using reportbug > > ACK, please go ahead and remove the moreinfo tag once the new version > is > available in unstable. > > Cheers
Bug#990398: unblock: zfs-linux/2.0.3-9 (pre-approval)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package zfs-linux [ Reason ] We want to cherry-pick a three-line fix for an important bug. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989373 diff --git a/module/os/linux/zfs/zpl_file.c b/module/os/linux/zfs/zpl_file.c index 421aebefe46..524c43dcded 100644 --- a/module/os/linux/zfs/zpl_file.c +++ b/module/os/linux/zfs/zpl_file.c @@ -342,9 +342,6 @@ zpl_iter_write(struct kiocb *kiocb, struct iov_iter *from) ssize_t wrote = count - uio.uio_resid; kiocb->ki_pos += wrote; - if (wrote > 0) - iov_iter_advance(from, wrote); - return (wrote); } [ Impact ] Potential memory corruption / data loss. [ Risks ] This has been sufficiently tested by ZFS upstream. And this fix is a part of their new stable release: https://github.com/openzfs/zfs/commit/412b69dfabe223a69159c8579ba808b49f0982e0 unblock zfs-linux/2.0.3-9 Thank you for using reportbug
Bug#986618: unblock: zfs-linux/2.0.3-6
Hi, On Sat, 2021-04-10 at 15:59 +0200, Paul Gevers wrote: > > If you also fix the armhf failure, we don't even need to discuss > anything in this unblock request. In my trial, installing > linux-hearders-armmp seemed to work. Thanks for the pointer. Fixed in 2.0.3-7 > If you fix your autopktest, then please also improve dkms-zfs-test to > use the (new) Architecture field to skip architectures where you Specified Architecture in 2.0.3-7 Then if nothing goes wrong, it should be able to migrate automatically. Should we close this bug or wait for the ci result?
Bug#985589: unblock: jsonnet/0.17.0+ds-2
Control: tags -1 -moreinfo src:jsonnet (=0.17.0+ds-2) has been uploaded onto unstable, and built on all release architectures. On Sun, 2021-03-21 at 14:31 +0100, Sebastian Ramacher wrote: > Control: tags -1 + confirmed moreinfo > > On 2021-03-20 13:49:44 +, M. Zhou wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > > > > > Please unblock package jsonnet > > > > [ Reason ] > > > > I missed the lib package in the Depends: field of its -dev package, > > resulting in dangling symlinks during anbe's tests. Not yet > > uploaded. > > Looks good. Please remove the moreinfo tag once it's available in > unstable. > > Cheers
Bug#985589: unblock: jsonnet/0.17.0+ds-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package jsonnet
[ Reason ]
I missed the lib package in the Depends: field of its -dev package,
resulting in dangling symlinks during anbe's tests. Not yet uploaded.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock jsonnet/0.17.0+ds-2
--- debdiff ---
diff -Nru jsonnet-0.17.0+ds/debian/changelog jsonnet-
0.17.0+ds/debian/changelog
--- jsonnet-0.17.0+ds/debian/changelog 2020-12-01 11:12:06.0
+0800
+++ jsonnet-0.17.0+ds/debian/changelog 2021-03-20 21:44:30.0
+0800
@@ -1,3 +1,9 @@
+jsonnet (0.17.0+ds-2) UNRELEASED; urgency=medium
+
+ * Fix broken symlinks in libjsonnet-dev due to missing deps (Closes:
#985511)
+
+ -- Mo Zhou Sat, 20 Mar 2021 21:44:30 +0800
+
jsonnet (0.17.0+ds-1) unstable; urgency=medium
* New upstream version 0.17.0+ds
diff -Nru jsonnet-0.17.0+ds/debian/control jsonnet-
0.17.0+ds/debian/control
--- jsonnet-0.17.0+ds/debian/control2020-12-01 11:12:06.0
+0800
+++ jsonnet-0.17.0+ds/debian/control2021-03-20 21:27:53.0
+0800
@@ -64,7 +64,7 @@
Package: libjsonnet-dev
Section: libdevel
Architecture: any
-Depends: ${misc:Depends},
+Depends: ${misc:Depends}, libjsonnet0 (= ${binary:Version})
Description: data templating language (devel)
A data templating language for app and tool developers
.
Bug#915721: transition: opencv
Hi pochu, To make things explicit, do I still have chance to continue with the opencv transition after the gdal one? And do I need to apply for freeze exception for opencv?
