Re: luajit2 vs luajit - cleanup
My memory on s390x was outdated and only applies to very old versions https://buildd.debian.org/status/logs.php?pkg=luajit=s390x But that does not change my opinion on upstream. On 2/19/24 12:51, Mo Zhou wrote: luajit2 supports s390x, while the original upstream is hard to collaborate with. I personally do not think switching to a more friendly upstream, and adding s390x support that will never be merged into the original upstream, are creating a mess. My personal opinion is to gradually deprecate src:luajit and switch to src:luajit2, and thus the current status of supporting both for a smoother migration. But, if the other maintainers and debian users are willing to continue work with the non-collaborative original upstream, please purge src:luajit2 and remove me from the co-maintainers. I'm not willing to work with original upstream. That's all. On 2/19/24 03:13, Ondřej Surý wrote: Hi Mo, since you package the luajit 2.1 for the second time as luajit2, could you also cleanup the mess you've created as there are now two packages providing luajit 2.1? You are listed as co-maintainer in the both packages, so the reason to package luajit2 is elusive to me. Since there are fewer dependencies for luajit2, it might be easier to just update luajit and drop luajit2. Ccing release and security teams - just FYI, not action needed, but double packaging of the same library has both release and security implications (more work). ### luajit 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 ettercap: libluajit-5.1-dev knot-resolver: libluajit-5.1-dev luajit lua-ljsyscall: luajit luakit: libluajit-5.1-dev luajit nageru: libluajit-5.1-dev neovim: luajit obs-studio: libluajit-5.1-dev openmw: libluajit-5.1-dev satdump: libluajit-5.1-dev snort: libluajit-5.1-dev suricata: libluajit-5.1-dev uftrace: libluajit-5.1-dev uwsgi-plugin-luajit: libluajit-5.1-dev vcmi/contrib: libluajit-5.1-dev wrk: libluajit-5.1-dev luajit Dependency problem found. ### luajit2 Checking reverse dependencies... # Broken Depends: lua-resty-core: lua-resty-core lua-resty-lrucache: lua-resty-lrucache luajit: libluajit-5.1-2 [s390x] libluajit-5.1-dev [s390x] luajit [s390x] # Broken Build-Depends: libnginx-mod-http-lua: libluajit2-5.1-dev love: libluajit2-5.1-dev sysbench: libluajit2-5.1-dev Dependency problem found. Thanks, -- Ondřej Surý (He/Him) ond...@sury.org
Re: luajit2 vs luajit - cleanup
luajit2 supports s390x, while the original upstream is hard to collaborate with. I personally do not think switching to a more friendly upstream, and adding s390x support that will never be merged into the original upstream, are creating a mess. My personal opinion is to gradually deprecate src:luajit and switch to src:luajit2, and thus the current status of supporting both for a smoother migration. But, if the other maintainers and debian users are willing to continue work with the non-collaborative original upstream, please purge src:luajit2 and remove me from the co-maintainers. I'm not willing to work with original upstream. That's all. On 2/19/24 03:13, Ondřej Surý wrote: Hi Mo, since you package the luajit 2.1 for the second time as luajit2, could you also cleanup the mess you've created as there are now two packages providing luajit 2.1? You are listed as co-maintainer in the both packages, so the reason to package luajit2 is elusive to me. Since there are fewer dependencies for luajit2, it might be easier to just update luajit and drop luajit2. Ccing release and security teams - just FYI, not action needed, but double packaging of the same library has both release and security implications (more work). ### luajit 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 ettercap: libluajit-5.1-dev knot-resolver: libluajit-5.1-dev luajit lua-ljsyscall: luajit luakit: libluajit-5.1-dev luajit nageru: libluajit-5.1-dev neovim: luajit obs-studio: libluajit-5.1-dev openmw: libluajit-5.1-dev satdump: libluajit-5.1-dev snort: libluajit-5.1-dev suricata: libluajit-5.1-dev uftrace: libluajit-5.1-dev uwsgi-plugin-luajit: libluajit-5.1-dev vcmi/contrib: libluajit-5.1-dev wrk: libluajit-5.1-dev luajit Dependency problem found. ### luajit2 Checking reverse dependencies... # Broken Depends: lua-resty-core: lua-resty-core lua-resty-lrucache: lua-resty-lrucache luajit: libluajit-5.1-2 [s390x] libluajit-5.1-dev [s390x] luajit [s390x] # Broken Build-Depends: libnginx-mod-http-lua: libluajit2-5.1-dev love: libluajit2-5.1-dev sysbench: libluajit2-5.1-dev Dependency problem found. Thanks, -- Ondřej Surý (He/Him) ond...@sury.org
Re: Bug#1060188: transition: flatbuffers
On 1/21/24 10:54, Sebastian Ramacher wrote: Control: tags -1 confirmed Should those that are not part of the transition tracker use the shared library or not? flatbuffers is like protobuf. I'm not sure how many rdeps among the list links against it statically.
Bug#1000553: transition: simdjson
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi release team, simdjson upstream has bumped the SOVERSION from 5 to 9. It has one (and only one) reverse dependency beyond my maintenance, so I'm opening this transition bug. the reverse depenency src:vast is successfully built locally. Ben file: title = "simdjson"; is_affected = .depends ~ "libsimdjson5" | .depends ~ "libsimdjson9"; is_good = .depends ~ "libsimdjson9"; is_bad = .depends ~ "libsimdjson5"; Thank you for using reportbug
Bug#976397: transition: opencv
On Thu, Dec 10, 2020 at 10:17:06PM +0100, Sebastian Ramacher wrote: > What's the status wrt to reverse dependencies? Do they all build with > the new version? Only 4 of them FTBFS. 3 of them failed due to other reasons. OKactiona_3.10.1-1.dsc OKauto-multiple-choice_1.4.0-5.dsc OKcaffe_1.0.0+git20180821.99bd997-8.dsc OKcimg_2.8.4+dfsg-1.dsc OKdarknet_0.0.0+git20180914.61c9d02e-2.dsc OKdigikam_7.1.0-1.dsc OKeviacam_2.1.4-2.dsc OKfreecad_0.19~pre1+git20201123.8d73c8f0+dfsg1-1.dsc FAIL (already FTBFS against opencv 4.0.1) freeture_1.3.0-1.dsc OKgmic_2.4.5-1.1.dsc OKgst-plugins-bad1.0_1.18.2-1.dsc FAIL (already FTBFS against opencv 4.0.1) limereg_1.4.1-4.dsc FAIL (already FTBFS against opencv 3.4.4, 4.0.1) mldemos_0.5.1+git.1.ee5d11f-4.dsc OKmonado_0.3.0-3.dsc FTBFS (#977247) mrpt_2.1.5-1.dsc OKnode-opencv_7.0.0+git20200310.6c13234-1.dsc OKnomacs_3.12.0+dfsg-3.dsc OKopencfu_4.0.0-1.dsc OKopenimageio_2.2.9.0+dfsg-1.dsc OKos-autoinst_4.5.1527308405.8b586d5-4.2.dsc OKotb_7.2.0+dfsg-1.dsc FTBFS (#977248) (header path) php-facedetect_1.1.0-19-g135c72a-1.dsc OKpytorch_1.7.0-2.dsc OKqimgv_0.9.1-2.dsc FTBFS (#977249) ros-opencv-apps_2.0.2-1.dsc FTBFS (#977250) ros-vision-opencv_1.15.0+ds-2.dsc OKsiril_0.99.6-1.dsc OKslowmovideo_0.5+git20190116-3.dsc OKvisp_3.3.0-5.dsc
Bug#976397: transition: opencv
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition The opencv version in unstable is relatively old. I'd like to make the latest version of opencv into the next stable release. Ben file: title = "opencv"; is_affected = .depends ~ "libopencv.*4\.2" | .depends ~ "libopencv.*4\.5"; is_good = .depends ~ "libopencv.*4\.5"; is_bad = .depends ~ "libopencv.*4\.2"; -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#956890: buster-pu: package zfs-linux/0.7.12-2+deb10u2
Hi Adam, Thanks for the notification! It has been uploaded just now. Was indulging in the pytorch related stuff. On Fri, May 01, 2020 at 11:22:54AM +0100, Adam D. Barratt wrote: > Ping? (On both this question and the zfs-linux upload.) > > The window for getting fixes into 10.4 closes during this weekend. > > Regards, > > Adam >
Bug#956890: buster-pu: package zfs-linux/0.7.12-2+deb10u2
On Sun, Apr 26, 2020 at 03:25:22PM +0100, Adam D. Barratt wrote: > On Wed, 2020-04-22 at 05:21 +0000, Mo Zhou wrote: > > The whole fix involes two parts: a part goes to src:zfs-linux and the > > other goes to src:spl-linux. Now that the updated src:spl-linux is > > already uploaded, and I'm now asking for the permission to upload the > > updated src:zfs-linux. Which includes two upstream commits fixing > > potential deadlock issues. > > What happens if a user tries using the current spl-dkms with the newer > zfs-dkms, or vice versa? I forgot to add Depends: spl-dkms (>= 0.7.12-2+deb10u1, s-p-u) into the debdiff of zfs-linux. Actually zfs-linux (= 0.7.12-2+deb10u1, buster) have no problem to build atop spl-linux (= 0.7.12-2, buster) or (= 0.7.12-2+deb10u1, s-p-u); while zfs-linux (= 0.7.12-2+deb10u2, s-p-u) will FTBFS atop spl-linux (= 0.7.12-2, buster) In that sense we'd better deal with spl-linux and zfs-linux synchronously. > Regards, > > Adam
Bug#956890: buster-pu: package zfs-linux/0.7.12-2+deb10u2
On Thu, Apr 16, 2020 at 03:40:09PM +0100, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > Control: tags 956889 + moreinfo > > On Thu, 2020-04-16 at 11:26 +0000, Mo Zhou wrote: > > (please explain the reason for this update here) > > > > We need to cherry-pick two patches in order to fix a deadlock issue > > for zfs > > https://github.com/openzfs/zfs/commit/98bb45e27ae80145a6ce028df90fccdb23f8901d > > https://github.com/openzfs/zfs/commit/01937958ce85b1cd8942dbaf9a3f9768c5b02a0a > > > > And the two patches have to be used in conjunction with a patch for > > src:spl-linux > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932251 > > (I'm uploading shortly) > > I'm afraid I'm slightly confused here. > > You've filed two copies of this bug, with slightly different content. Please ignore the result of a mutt crash. > Neither of them has a proposed diff attached, and they both claim to be see attached debdiff. > requesting updates for the "zfs-linux" package, but the upload you've > made is for the "spl-linux" package, for which there appears to be no > p-u bug. The whole fix involes two parts: a part goes to src:zfs-linux and the other goes to src:spl-linux. Now that the updated src:spl-linux is already uploaded, and I'm now asking for the permission to upload the updated src:zfs-linux. Which includes two upstream commits fixing potential deadlock issues. > Please could you clarify? > > Regards, > > Adam > diff -Nru zfs-linux-0.7.12/debian/changelog zfs-linux-0.7.12/debian/changelog --- zfs-linux-0.7.12/debian/changelog 2019-06-09 11:17:40.0 +0800 +++ zfs-linux-0.7.12/debian/changelog 2020-04-22 13:14:27.0 +0800 @@ -1,3 +1,11 @@ +zfs-linux (0.7.12-2+deb10u2) buster; urgency=medium + + * Cherry-pick two upstream patches to fix potential deadlock issues. ++ 01937958ce85b1cd8942dbaf9a3f9768c5b02a0a ++ 98bb45e27ae80145a6ce028df90fccdb23f8901d + + -- Mo Zhou Wed, 22 Apr 2020 13:14:27 +0800 + zfs-linux (0.7.12-2+deb10u1) testing-proposed-updates; urgency=high * Patch: Disable SIMD on 4.19.37+ or 5.0+ kernels. (Closes: #929929) diff -Nru zfs-linux-0.7.12/debian/patches/01937958ce85b1cd8942dbaf9a3f9768c5b02a0a.patch zfs-linux-0.7.12/debian/patches/01937958ce85b1cd8942dbaf9a3f9768c5b02a0a.patch --- zfs-linux-0.7.12/debian/patches/01937958ce85b1cd8942dbaf9a3f9768c5b02a0a.patch 1970-01-01 08:00:00.0 +0800 +++ zfs-linux-0.7.12/debian/patches/01937958ce85b1cd8942dbaf9a3f9768c5b02a0a.patch 2020-04-22 13:11:49.0 +0800 @@ -0,0 +1,327 @@ +From 01937958ce85b1cd8942dbaf9a3f9768c5b02a0a Mon Sep 17 00:00:00 2001 +From: Matthew Ahrens +Date: Thu, 31 May 2018 10:29:12 -0700 +Subject: [PATCH] OpenZFS 9577 - remove zfs_dbuf_evict_key tsd + +The zfs_dbuf_evict_key TSD (thread-specific data) is not necessary - +we can instead pass a flag down in a few places to prevent recursive +dbuf eviction. Making this change has 3 benefits: + +1. The code semantics are easier to understand. +2. On Linux, performance is improved, because creating/removing + TSD values (by setting to NULL vs non-NULL) is expensive, and + we do it very often. +3. According to Nexenta, the current semantics can cause a + deadlock when concurrently calling dmu_objset_evict_dbufs() + (which is rare today, but they are working on a "parallel + unmount" change that triggers this more easily): + +Porting Notes: +* Minor conflict with OpenZFS 9337 which has not yet been ported. + +Authored by: Matthew Ahrens +Reviewed by: George Wilson +Reviewed by: Serapheim Dimitropoulos +Reviewed by: Brad Lewis +Reviewed-by: George Melikov +Ported-by: Brian Behlendorf + +OpenZFS-issue: https://illumos.org/issues/9577 +OpenZFS-commit: https://github.com/openzfs/openzfs/pull/645 +External-issue: DLPX-58547 +Closes #7602 +--- + include/sys/dbuf.h | 4 +-- + include/sys/dnode.h | 4 +-- + module/zfs/dbuf.c | 69 ++--- + module/zfs/dnode.c | 7 +++-- + module/zfs/dnode_sync.c | 17 -- + 5 files changed, 46 insertions(+), 55 deletions(-) + +diff --git a/include/sys/dbuf.h b/include/sys/dbuf.h +index 127acad33c7..e007e97644e 100644 +--- a/include/sys/dbuf.h b/include/sys/dbuf.h +@@ -20,7 +20,7 @@ + */ + /* + * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved. +- * Copyright (c) 2012, 2015 by Delphix. All rights reserved. ++ * Copyright (c) 2012, 2018 by Delphix. All rights reserved. + * Copyright (c) 2013 by Saso Kiselkov. All rights reserved. + * Copyright (c) 2014 Spectra Logic Corporation, All rights reserved. + */ +@@ -294,7 +294,7 @@ boolean_t dbuf_try_add_ref(dmu_buf_t *db, objset_t *os, uint64_t obj, + uint64_t dbuf_refcount(dmu_buf_impl_t *db); + + void dbuf_rele(dmu_buf_impl_t *db, void *tag); +-void dbuf_rele_and_unlock(dmu_buf_impl_t *db, void *t
Bug#956889: Acknowledgement (buster-pu: package zfs-linux/0.7.12-2+deb10u2)
Control: close -1 This bug is duplicated with #956889. When sending this mail for the first time my mutt crashed somehow. Hence the duplicated submission. On Thu, Apr 16, 2020 at 11:27:04AM +, Debian Bug Tracking System wrote: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 956889: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956889. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian Release Team > > If you wish to submit further information on this problem, please > send it to 956...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 956889: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956889 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems
Bug#956890: buster-pu: package zfs-linux/0.7.12-2+deb10u2
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu (please explain the reason for this update here) We need to cherry-pick two patches in order to fix a deadlock issue for zfs https://github.com/openzfs/zfs/commit/98bb45e27ae80145a6ce028df90fccdb23f8901d https://github.com/openzfs/zfs/commit/01937958ce85b1cd8942dbaf9a3f9768c5b02a0a And the two patches have to be used in conjunction with a patch for src:spl-linux https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932251 (I'm uploading shortly) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#956889: buster-pu: package zfs-linux/0.7.12-2+deb10u2
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu We need to cherry-pick two upstream commits to fix a deadlock issue for zfs https://github.com/openzfs/zfs/commit/98bb45e27ae80145a6ce028df90fccdb23f8901d https://github.com/openzfs/zfs/commit/01937958ce85b1cd8942dbaf9a3f9768c5b02a0a The two patches have to be used in conjunction with https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932251 (I'm uploading it shortly) (please explain the reason for this update here) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#948638: transition: opencv
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition (please explain about the transition: impacted packages, reason, ... 4.1.2+dfsg-5 -> 4.2.0+dfsg-2 We need to handle the opencv SOVERSION bump along with new upstream release. Unlike the 3.2->4.1 transition we've done a couple of weeks ago, this 4.1->4.2 transition is expected to be much easier. The automatically generated ben file on the tracker is good enough: https://release.debian.org/transitions/html/auto-opencv.html -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#915721: transition: opencv
On 2019-10-10 11:03, Paul Gevers wrote: > Although the tracker doesn't show any collision, I'd like to finish the > perl transition first. Please go ahead when perl 5.30 migrates to > testing. Once uploaded raise the severity of all those FTBFS bugs. opencv 4.1.2 has landed onto unstable. The mipsel build got resurrected with the 3 tricks: seirla build + noopt + -gsplit-dwarf. It has finished the build in experimental in 30 hours, so I expect similar result on unstable. Binary packages for common architectures have already been propagated to mirrors. I'll shortly raise the severity of FTBFS bugs.
Bug#915721: transition: opencv
Control: block -1 by 915708 Control: block -1 by 915711 Control: block -1 by 915712 On 2019-10-10 11:03, Paul Gevers wrote: >>> AFAIK opencv 3.x -> 4.x breaks nearly all the reverse dependencies, due >>> to >>> API changes or header path change. >>> I have already filed FTBFS bugs against those correcponding packages >>> when opencv 4.0.1 landed onto experimental. Now it's 4.1.1 and I think >>> the result won't be different. > > Could you please check that I have found all these bugs that you filed? > Please add any that I missed. I've added 3 missing blockers. > Although the tracker doesn't show any collision, I'd like to finish the > perl transition first. Please go ahead when perl 5.30 migrates to > testing. Once uploaded raise the severity of all those FTBFS bugs. Got it. I'll postpone the unstable upload until the perl transition is finished.
Bug#915721: transition: opencv
ping? On 2019-09-30 09:02, Mo Zhou wrote: > Hi release team, > > Shall we proceed with the opencv transition? The opencv 3.2.0 in > unstable > is too ancient. The automatically generated ben file looks good: > > https://release.debian.org/transitions/html/auto-opencv.html > > I'm planning to remove the mipsel architecture since it suffers > a lot from OOM issue during compilation, so please ignore the FTBFS > on mipsel: > https://buildd.debian.org/status/package.php?p=opencv=experimental > > AFAIK opencv 3.x -> 4.x breaks nearly all the reverse dependencies, due > to > API changes or header path change. > I have already filed FTBFS bugs against those correcponding packages > when opencv 4.0.1 landed onto experimental. Now it's 4.1.1 and I think > the result won't be different. > > On 2019-01-14 15:44, Mo Zhou wrote: >> On Sun, Jan 13, 2019 at 08:06:57PM +0100, Emilio Pozuelo Monfort wrote: >>> >>> What is the status with the rdeps? I looked at two bugs and they worry me: >> >> I haven't had enough time to test rdeps for another round. But I guess >> the situation would be similar to the first round. >> >>> #915544 suggests the OpenCV C API is broken, and ffmpeg solved it by >>> disabling >>> ffmpeg support altogether. >>> >>> #915709 seems to point to the same brokenness. >> >> Quoted from upstream: >> https://github.com/opencv/opencv/issues/10963#issuecomment-369259044 >> >> | OpenCV 3.x doesn't not support C compilation mode officially. >> >> And if you look at upstream Pull Requests you will find that upstream >> is gradually removing legacy C APIs. >> >> So, those rdeps broken due to the C API are questionable because they >> are using non-officially supported (deprecated) part of opencv ... >> >> There are another failing pattern, which stems from changes in C++ class >> method, and is easy to fix ... >> >> I'm currently putting out the fire on the julia package so I cannot >> make a statistics. >> >>> The way it looks, I don't think we can go ahead with this at this stage. >> >> Both result are acceptable to me -- wether we can go ahead or not. >> Pausing the transition helps my laziness. Moving forward, although >> radical and breaks some questionable rdeps, brings some new features >> such as the DNN module which supports not only pre-trained tensorflow >> model.
Bug#915721: transition: opencv
Hi release team, Shall we proceed with the opencv transition? The opencv 3.2.0 in unstable is too ancient. The automatically generated ben file looks good: https://release.debian.org/transitions/html/auto-opencv.html I'm planning to remove the mipsel architecture since it suffers a lot from OOM issue during compilation, so please ignore the FTBFS on mipsel: https://buildd.debian.org/status/package.php?p=opencv=experimental AFAIK opencv 3.x -> 4.x breaks nearly all the reverse dependencies, due to API changes or header path change. I have already filed FTBFS bugs against those correcponding packages when opencv 4.0.1 landed onto experimental. Now it's 4.1.1 and I think the result won't be different. On 2019-01-14 15:44, Mo Zhou wrote: > On Sun, Jan 13, 2019 at 08:06:57PM +0100, Emilio Pozuelo Monfort wrote: >> >> What is the status with the rdeps? I looked at two bugs and they worry me: > > I haven't had enough time to test rdeps for another round. But I guess > the situation would be similar to the first round. > >> #915544 suggests the OpenCV C API is broken, and ffmpeg solved it by >> disabling >> ffmpeg support altogether. >> >> #915709 seems to point to the same brokenness. > > Quoted from upstream: > https://github.com/opencv/opencv/issues/10963#issuecomment-369259044 > > | OpenCV 3.x doesn't not support C compilation mode officially. > > And if you look at upstream Pull Requests you will find that upstream > is gradually removing legacy C APIs. > > So, those rdeps broken due to the C API are questionable because they > are using non-officially supported (deprecated) part of opencv ... > > There are another failing pattern, which stems from changes in C++ class > method, and is easy to fix ... > > I'm currently putting out the fire on the julia package so I cannot > make a statistics. > >> The way it looks, I don't think we can go ahead with this at this stage. > > Both result are acceptable to me -- wether we can go ahead or not. > Pausing the transition helps my laziness. Moving forward, although > radical and breaks some questionable rdeps, brings some new features > such as the DNN module which supports not only pre-trained tensorflow > model.
Bug#932948: transition: double-conversion
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition (please explain about the transition: impacted packages, reason, ... for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions) Upstream had already bumped their SOVERSION to 3 long time ago. We didn't bump it in the past because the ABI is actually compatible. According to the previous discussion on -devel, I'd better bump it to 3 following upstream. There is neither API nor ABI bump. Just a SOVERSION change. Ben file: title = "double-conversion"; is_affected = .depends ~ "libdouble-conversion1" | .depends ~ "libdouble-conversion3"; is_good = .depends ~ "libdouble-conversion3"; is_bad = .depends ~ "libdouble-conversion1"; -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#930238: unblock: zfs-linux/0.7.12-2+deb10u1 [t-p-u]
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package zfs-linux
Following
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#t-p-u
I've not uploaded it yet but asking for permission first.
(explain the reason for the unblock here)
Fix a GRAVE stable RC due to linux's unexporting several
fpu-related symbols:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929929
This is the very only purpose of this upload.
The solution in this upload is cherry-picked from upstream,
which directly disable the SIMD thing for linux (>= 4.19.38).
I scanned the rest historical patches we have applied to
zfs 0.7.12. Some of them fix crashes and segfaults but they
don't look fatal enough and would inflate the debdiff hence
incur rejection. Let's forget them.
I've tested this patch on Buster with a manually-built
4.19.48 kernel (make defconfig, make, make bindeb-pkg).
Full source:
https://people.debian.org/~lumin/upload/zfs-linux_0.7.12-2+deb10u1_source.changes
Debdiff: attached.
(include/attach the debdiff against the package in testing)
unblock zfs-linux/0.7.12-2+deb10u1
diff --git a/debian/changelog b/debian/changelog
index 41d4a9fe..e6aad323 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+zfs-linux (0.7.12-2+deb10u1) testing-proposed-updates; urgency=high
+
+ * Patch: Disable SIMD on 4.19.37+ or 5.0+ kernels. (Closes: #929929)
+
+ -- Mo Zhou Sun, 09 Jun 2019 03:17:40 +
+
zfs-linux (0.7.12-2) unstable; urgency=medium
[ Colin Ian King ]
diff --git a/debian/patches/e22bfd814960295029ca41c8e116e8d516d3e730.patch b/debian/patches/e22bfd814960295029ca41c8e116e8d516d3e730.patch
new file mode 100644
index ..ceb02ca2
--- /dev/null
+++ b/debian/patches/e22bfd814960295029ca41c8e116e8d516d3e730.patch
@@ -0,0 +1,404 @@
+From e22bfd814960295029ca41c8e116e8d516d3e730 Mon Sep 17 00:00:00 2001
+From: Tony Hutter
+Date: Fri, 11 Jan 2019 18:01:28 -0800
+Subject: [PATCH] Linux 5.0 compat: Disable vector instructions on 5.0+ kernels
+
+The 5.0 kernel no longer exports the functions we need to do vector
+(SSE/SSE2/SSE3/AVX...) instructions. Disable vector-based checksum
+algorithms when building against those kernels.
+
+Reviewed-by: Brian Behlendorf
+Signed-off-by: Tony Hutter
+Closes #8259
+---
+ config/kernel-fpu.m4 | 41 ++---
+ include/linux/simd_x86.h | 127 +++
+ 2 files changed, 134 insertions(+), 34 deletions(-)
+
+diff --git a/config/kernel-fpu.m4 b/config/kernel-fpu.m4
+index 1c5690969d4..671fe7ea54e 100644
+--- a/config/kernel-fpu.m4
b/config/kernel-fpu.m4
+@@ -1,18 +1,41 @@
++dnl #
++dnl # Handle differences in kernel FPU code.
+ dnl #
+-dnl # 4.2 API change
+-dnl # asm/i387.h is replaced by asm/fpu/api.h
++dnl # Kernel
++dnl # 5.0: All kernel fpu functions are GPL only, so we can't use them.
++dnl # (nothing defined)
++dnl #
++dnl # 4.2: Use __kernel_fpu_{begin,end}()
++dnl # HAVE_UNDERSCORE_KERNEL_FPU & KERNEL_EXPORTS_X86_FPU
++dnl #
++dnl # Pre-4.2: Use kernel_fpu_{begin,end}()
++dnl # HAVE_KERNEL_FPU & KERNEL_EXPORTS_X86_FPU
+ dnl #
+ AC_DEFUN([ZFS_AC_KERNEL_FPU], [
+- AC_MSG_CHECKING([whether asm/fpu/api.h exists])
++ AC_MSG_CHECKING([which kernel_fpu function to use])
+ ZFS_LINUX_TRY_COMPILE([
+- #include
+- #include
++ #include
++ #include
+ ],[
+- __kernel_fpu_begin();
++ kernel_fpu_begin();
++ kernel_fpu_end();
+ ],[
+- AC_MSG_RESULT(yes)
+- AC_DEFINE(HAVE_FPU_API_H, 1, [kernel has interface])
++ AC_MSG_RESULT(kernel_fpu_*)
++ AC_DEFINE(HAVE_KERNEL_FPU, 1, [kernel has kernel_fpu_* functions])
++ AC_DEFINE(KERNEL_EXPORTS_X86_FPU, 1, [kernel exports FPU functions])
+ ],[
+- AC_MSG_RESULT(no)
++ ZFS_LINUX_TRY_COMPILE([
++ #include
++ #include
++ ],[
++ __kernel_fpu_begin();
++ __kernel_fpu_end();
++ ],[
++ AC_MSG_RESULT(__kernel_fpu_*)
++ AC_DEFINE(HAVE_UNDERSCORE_KERNEL_FPU, 1, [kernel has __kernel_fpu_* functions])
++ AC_DEFINE(KERNEL_EXPORTS_X86_FPU, 1, [kernel exports FPU functions])
++ ],[
++ AC_MSG_RESULT(not exported)
++ ])
+ ])
+ ])
+diff --git a/include/linux/simd_x86.h b/include/linux/simd_x86.h
+index c9e3970c0cf..c55cb177893 100644
+--- a/include/linux/simd_x86.h
b/include/linux/simd_x86.h
+@@ -81,7 +81,7 @@
+ #endif
+
+ #if defined(_KERNEL)
+-#if defined(HAVE_FPU_API_H)
++#if defined(HAVE_UNDERSCORE_KERNEL_FPU)
+ #include
+ #include
+ #define kfpu_begin() \
+@@ -94,12 +94,18 @@
+ __kernel_fpu_end(); \
+ preempt_enable(); \
+ }
+-#else
++#elif defined(HAVE_KERNEL_FPU)
+ #include
+ #include
+ #define kfpu_begin() kernel_fpu_begin()
+ #define kfpu_end() kernel_fpu_end()
+-#endif /* defined(HAVE_FPU_API_H) */
++#else
++/* Kernel doesn't export any kernel_fpu_* functions */
++#include /* For kernel xgetbv() */
++#define kfpu_begin() panic("This code should never run")
++#define kfpu_end() panic("This code should never
Bug#928746: unblock: zfs-linux/0.7.13-1
control: retitle -1 unblock: zfs-linux/0.7.12-6 (or 0.7.13-1) control: close -1 Hi Release Team, On 2019-06-03 15:05, Mo Zhou wrote: > Patching the kernel is impossible because kernel maintainers > refused to do that. So that's an invalid solution. After a short discussion with Aron Xu, I realized that I made a mistake about the kernel SIMD problem. It's the ***LTS KERNEL UPDATE*** that breaks ZFS 0.7.12-2. It's not a bug of 0.7.12-2 at all. An LTS KERNEL UPDATE that BREAKS stuff indicates a grave RC. > I'll never argue about ZFS unblock again for Buster. Sorry and I decided to give up the unblock request. We[2] Debian ZoL maintainers decided to do nothing about the kernel SIMD issue and we'll file an RC bug against the kernel immediately after the 10.1 point release because it breaks stuff. [1] https://github.com/zfsonlinux/zfs/commit/e22bfd814960295029ca41c8e116e8d516d3e730 [2] Aron and Me.
Bug#926976: [pre-a] unblock: blis/0.5.1-13
control: close -1 Let's just leave the bug for Buster. It's not critical.
Bug#928741: [pre-a] unblock: julia/1.0.4+dfsg-1
control: close -1 Hi Paul, On 2019-05-30 19:29, Paul Gevers wrote: > On Thu, 09 May 2019 19:26:06 -0700 Mo Zhou wrote: >> The current version in testing is 1.0.3, I'm requesting >> unblock for 1.0.4 (not-yet-released) because Julia's >> 1.0.X series is strictly a bug-fix-only branch. As per >> upstream's call-for-community-testing announcement: > > I appreciate you want the latest you can get for you package into > buster. However, a new upstream (even for only bug fixes branches) does > not meet the freeze policy. Can you please indicate which bugs in the > changelog you consider important or more severe (in Debian BTS terms)? > How much of the changes would fall in that category? Thanks for the review. I quickly went through the commit history and didn't find a bug fix that is critical. So let's keep the testing version as is, and I'll later push these updates through bpo.
Bug#928746: unblock: zfs-linux/0.7.13-1
Hi Paul, On 2019-05-30 19:51, Paul Gevers wrote: > or more severe in Debian BTS terms. I may have been wrong, but then > please point me to the changes so important that you want them in > buster. Please also be prepared to undo the new upstream release and > just fix the bugs that are so important to you. I've already forgotten them and I'm tired to review the diff. Let's forget all the important stuff and only focus on the grave one: Due to a stable kernel change (4.19.37->4.19.38) that makes me sad, we got a grave RC for ZFS 0.7.12-2 (testing) which makes it not suitable for the Buster release: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929929 We have two solutions for this stable RC: 1. just unblock 0.7.13-1 . 2. revert debdiff(0.7.12-2,0.7.12-5), then cherry-pick the commits[1] that fix the build issue, then go through t-p-u for 0.7.12-6 . Patching the kernel is impossible because kernel maintainers refused to do that. So that's an invalid solution. > Be aware that requests like this one are draining energy from the > release team. It isn't nice to turn a maintainer down on a request, > repeating the process is worse. Your changes are huge (your explanation > is appreciated), we get several unblock requests per day and we have a > freeze policy in place to manage it. Please don't push your pet project > so hard if it doesn't meet the policy that you are driving the > volunteers in the release team away. Thanks for also considering our time. Sorry for that. My motivation is just that 0.7.13-1 is really expected to reduce the number of problems compared to 0.7.12-2... Please make a choice between the two proposed solution above. If release team doesn't trust every line of code, please just choose 2. I'll never argue about ZFS unblock again for Buster. [1] Patch: https://github.com/zfsonlinux/zfs/commit/e22bfd814960295029ca41c8e116e8d516d3e730
Bug#928741: Acknowledgement ([pre-a] unblock: julia/1.0.4+dfsg-1)
I've just uploaded 1.0.4+dfsg-1 to unstable. The debdiff is the same to the changes proposed previously. Plus, julia-doc (arch=all) needs a maintainer-upload rebuild against new unicode-data since binNMU doesn't deal with arch=all packages. And this is the maintainer upload. julia-lts.diff.zst Description: Binary data
Bug#928746: unblock: zfs-linux/0.7.13-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: a...@debian.org
Please unblock package zfs-linux
zfs-linux (= 0.7.13-1) is 66 days in unstable and there is no new bug
for it.
Compared to (0.7.12-2), the (0.7.13-1) version in unstable only
introduces
bug fixes. Aron has already applied for an unblock but it was rejected.
Here I'm requesting for unblock again.
The difference between upstream 0.7.12 and 0.7.13 includes
linux 5.0 compat fixes, and a series of bug fixes. I can revert
the linux 5.0 compat fixes if you think that's irrelated to
the Buster release with the 0.7.13-2 upload. I can also revert
some enhancement patches if release team doesn't like them. Even
if we reverted the linux 5.0 compat and some enhancements, it
is still better than letting 0.7.12-2 stay in Buster, because
in that way we still have bug fixes.
On the debian packaging side, the difference between 0.7.12-2
(testing) and 0.7.13-1 (unstable) includes manually cherry-picked
patches (by Colin Ian King(ubuntu diff), Aron Xu, and Me), fixes
for the problematic autopkgtest script I wrote, and a small update
for the Debian+OpenRC support patch. Most of the newly added patches
were already shipped by the ubuntu package more than 3 months ago.
zfs (0.7.12-5) was uploaded to unstable before (hardfreeze - 12 days).
zfs (0.7.13-1) was uploaded to unstable on (hardfreeze - 8 days).
I should have waited for some time for the 0.7.12-5 migration...
Anyway let's see the diffstat and I'll comment every bit of change in
detail. Please at least accept some bug fixes for Buster. And tell
me which of the enhancements (incl. linux 5.0 compat) are
not acceptible so that I can revert them.
(explain the reason for the unblock here)
```
~/D/z/zfs ❯❯❯ git diff debian/0.7.12-2 debian/0.7.13-1 --stat | cat
META | 2 +-
Makefile.in| 2 +
aclocal.m4 | 2 +
cmd/Makefile.in| 2 +
cmd/arc_summary/Makefile.in| 2 +
cmd/arcstat/Makefile.in| 2 +
cmd/dbufstat/Makefile.in | 2 +
cmd/fsck_zfs/Makefile.in | 2 +
cmd/mount_zfs/Makefile.am | 2 +
cmd/mount_zfs/Makefile.in | 4 +
cmd/raidz_test/Makefile.in | 2 +
cmd/vdev_id/Makefile.in| 2 +
[linux 5.0 compat]
*.am and *.in was updated for linux 5.0
cmd/vdev_id/vdev_id| 209 -
[enhancements]
2b8c3cb0c83681d7425fa5bf567e726b7ba975e9
vdev_id: extension for new scsi topology
41f7723e9cb260f313f99d667142e37617812fca
vdev_id: new slot type ses
c32c2f17d06cea5dc298b404fad7696921e490e0
Add enclosure_symlinks option to vdev_id
cmd/zdb/Makefile.in| 2 +
cmd/zed/Makefile.in| 2 +
cmd/zfs/Makefile.in| 2 +
cmd/zgenhostid/Makefile.in | 2 +
cmd/zhack/Makefile.in | 2 +
cmd/zinject/Makefile.in| 2 +
cmd/zpios/Makefile.in | 2 +
cmd/zpool/Makefile.in | 2 +
cmd/zstreamdump/Makefile.in| 2 +
cmd/ztest/Makefile.in | 2 +
[linux 5.0 compat]
all the *.in files above
cmd/ztest/ztest.c | 4 +-
[trivial C code change]
- .zo_pool = { 'z', 't', 'e', 's', 't', '\0' },
- .zo_dir = { '/', 't', 'm', 'p', '\0' },
+ .zo_pool = "ztest",
+ .zo_dir = "/tmp",
cmd/zvol_id/Makefile.in| 2 +
config/kernel-access-ok-type.m4| 21 +
config/kernel-bio_set_dev.m4 | 35 +-
config/kernel-fpu.m4 | 41 +-
config/kernel-misc-minor.m4| 26 +
config/kernel.m4 | 4 +-
[linux 5.0 compat]
the above several files were changed due to linux compat fix
configure | 599
++-
Mostly due to newly added kernel feature checks.
Deleted lines are due to version number bump.
configure.ac | 3 +
contrib/Makefile.in| 2 +
contrib/bash_completion.d/Makefile.in | 2 +
contrib/dracut/02zfsexpandknowledge/Makefile.in| 2 +
contrib/dracut/90zfs/Makefile.am | 1 +
contrib/dracut/90zfs/Makefile.in | 3 +
contrib/dracut/90zfs/module-setup.sh.in| 4 +-
contrib/dracut/Makefile.in
Bug#928741: [pre-a] unblock: julia/1.0.4+dfsg-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package julia (explain the reason for the unblock here) The current version in testing is 1.0.3, I'm requesting unblock for 1.0.4 (not-yet-released) because Julia's 1.0.X series is strictly a bug-fix-only branch. As per upstream's call-for-community-testing announcement: ``` The release-1.0 branch on the Julia repository now contains the set of commits we’re planning to tag as v1.0.4, the fourth patch release in the 1.0 series, which has long-term support. The list of commits included since v1.0.3 is available here 7. As a patch release, it should be strictly non-breaking for existing code and introduce no new features at all, just bug fixes, documentation improvements, and performance enhancements. ``` https://discourse.julialang.org/t/julia-1-0-4-testing-period/24051 This change is really only fixing bugs according to upstream commits: ``` | | Merge pull request #30954 from JuliaLang/backport-1.0.4 | * e5de4590bf fix #30679, call correct method for `invoke` calls in `jl_invoke` fallback (#31845) | * ef22206b0a Update Mozilla CA certificate store to latest (01-23-2019) for libgit2 SSL. (#31029) | * c1e1824327 Fix `-`, `conj`, and `conj!` for sparse matrices with invalid entries in `nzval` (#31187) | * 11b8f5991a fix #31758: out of bounds write in sparse broadcast (#31763) | * fa220625b7 minor fixes in multiplication with Diagonals (#31443) | * 639de07d43 fix parse(ComplexF64, "inf") | * a92bfbed6b inf or nan parsing should ignore leading spaces | * 07279a357d Upgrade `libssh2` version to `1.8.2` (#31775) | * 1d7087db99 Fix 29545: Implement unaliascopy for ReinterpretArray (#30296) | * 7fb55412bb Fix #30006, getindex accessing fields that might not exist (#30405) | * ec0cf97571 Pkg resolver update. | * 5313c54fae Don't modify existing MDNodes in SIMDloop pass. | * 707fdda67e Fix show_vector for long offset arrays with :limit=true (#31642) | * 9072796d61 Improve REPL completions (#30569) | * ce6b3cb3d2 build: LDFLAGS needed for FreeBSD build (#31586) | * a8758c48ef allow chop to take an empty string (#31312) | * fc773de17a bump MPFR to 4.0.2 (#31041) | * 65a22aa428 fix #29936, precompile should not assume UnionAlls have stable addresses (#31047) | * 0b651e0b77 Use XCode 8.3 for macOS on Travis (#30599) | * 2cb487a5f3 Bump Pkg to 1.0.4. | * 54a71f6e2b fix #30643, correctly propagate iterator traits through Stateful (#30644) | * 8ec20f467a Defensively fix patterns similar to #29983 | * fd1f187609 Fix SROA confusing new and old nodes | * 63414f7038 Fix #30006, getindex accessing fields that might not exist (#30405) | * 92ecdfdbbc Fix use counts for mutable struct SROA | * af03147f5d llvm: fix target triple (#30554) | * 347bca30d9 fix #30394, an unsoundness in ml_matches (#30396) | * ceccebd99b fix #30911, bug in `deepcopy` of `UnionAll` (#30930) | * f24bf8b471 fix `at-everywhere using` in Distributed stdlib (#30804) | * f9dddf8470 fix #30792, static param constraints between positional and kw args (#30798) | * 48f6ea7b2d update macOS icons to be less transparent (#30773) | * 083bc82ce3 Handle :error and :invalid expressions gracefully in REPL helpmode, (#30754) | * b6b74132a8 SHA,tests: cleanup tempdir (#30655) | * 2dc20f78af Add the scaled identity matrix to a random matrix to avoid getting a singular matrix (#30576) | * 7786f7856c fix `lambda-optimize-vars!` with complex assignment RHSs (#30564) | * bca2f420ad Add custom deserialize method for UmfpackLU to avoid memory leak (#30425) | * 4148b76322 generalize sparse matrix slicing to integer types (#30319) | * 0073e42fbc stacktrace: prevent OOB-error in sysimage lookup (#30369) | * 7e8d9b2c34 fix reinterpret for 0-dimensional arrays (#30376) | * 9d63c0f23c fix bug with max_values in union! (#30315) | * 97add1c3d5 Use `JL_AArch64_crc` instead of `HWCAP_CRC32` (#30324) |/ * 5b7e8d9d4e Set VERSION to 1.0.4-pre (#30440) * 099e826241 (tag: v1.0.3) Revert "Add test for llvmcall Function* interface" ``` Full git diff-stat between 1.0.3 and 1.0.4 (proposed), plus my comments: ``` .travis.yml| 2 +- VERSION| 2 +- base/abstractset.jl| 6 +- base/arrayshow.jl | 7 +- base/compiler/ssair/passes.jl | 30 +- base/deepcopy.jl | 2 +- base/iterators.jl | 5 +- base/parse.jl | 2 +- base/range.jl | 4 +- base/reinterpretarray.jl | 5 +- base/strings/util.jl | 3 + base/* are important files implementing basic language functionalities. They received bug fixes. contrib/mac/app/julia.icns | Bin 122007 -> 226356 bytes
Bug#928455: [pre-a] unblock: perl6-zef/0.6.2-2
control: tags -1 -moreinfo Uploaded to unstable. On Sun, May 05, 2019 at 11:51:00AM +, Niels Thykier wrote: > Please go ahead with the upload and remove the moreinfo tag when it is > in unstable and ready to be unblocked. ~/D/perl6 ❯❯❯ debdiff --diffstat perl6-zef_0.6.2-1.dsc perl6-zef_0.6.2-2.dsc diffstat for perl6-zef-0.6.2 perl6-zef-0.6.2 changelog|6 ++ patches/series |1 + patches/update-p6c-mirror-urls.patch | 19 +++ 3 files changed, 26 insertions(+) diff -Nru perl6-zef-0.6.2/debian/changelog perl6-zef-0.6.2/debian/changelog --- perl6-zef-0.6.2/debian/changelog2019-01-10 08:38:06.0 + +++ perl6-zef-0.6.2/debian/changelog2019-05-06 02:08:36.0 + @@ -1,3 +1,9 @@ +perl6-zef (0.6.2-2) unstable; urgency=medium + + * Patch: update-p6c-mirror-urls.patch (Closes: #928454) + + -- Mo Zhou <> Mon, 06 May 2019 02:08:36 + + perl6-zef (0.6.2-1) unstable; urgency=medium * New upstream version 0.6.2 diff -Nru perl6-zef-0.6.2/debian/patches/series perl6-zef-0.6.2/debian/patches/series --- perl6-zef-0.6.2/debian/patches/series 2018-09-12 14:54:50.0 + +++ perl6-zef-0.6.2/debian/patches/series 2019-05-06 01:57:24.0 + @@ -1 +1,2 @@ interpreter.diff +update-p6c-mirror-urls.patch diff -Nru perl6-zef-0.6.2/debian/patches/update-p6c-mirror-urls.patch perl6-zef-0.6.2/debian/patches/update-p6c-mirror-urls.patch --- perl6-zef-0.6.2/debian/patches/update-p6c-mirror-urls.patch 1970-01-01 00:00:00.0 + +++ perl6-zef-0.6.2/debian/patches/update-p6c-mirror-urls.patch 2019-05-06 01:59:56.0 + @@ -0,0 +1,19 @@ +Source: https://github.com/ugexe/zef/blob/master/resources/config.json#L60-L62 +Fixes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928454 +Index: perl6-zef/resources/config.json +=== +--- perl6-zef.orig/resources/config.json perl6-zef/resources/config.json +@@ -57,10 +57,9 @@ + "name" : "p6c", + "auto-update" : 1, + "mirrors" : [ +-"http://ecosystem-api.p6c.org/projects1.json;, +-"http://ecosystem-api.p6c.org/projects.json;, ++ "https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json;, + "git://github.com/ugexe/Perl6-ecosystems.git", +- "https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json; ++"http://ecosystem-api.p6c.org/projects1.json; + ] + } + }, > For future reference: > * We generally need to full debdiff to know exactly what we will be >approving. In this case, I assumed you need that change plus an >upload to d/changelog only (hopefully sparing us from a round trip) > * Assuming this is indeed the only change, it would have been faster >and easier for both parties if you had uploaded it to sid in parallel >with the unblock request. > - I appreciate that you may prefer a "rather safe than sorry"- > approach, which is greatly appreciated with potential risky > changes. Got it. Thanks for the hints.
Bug#928455: [pre-a] unblock: perl6-zef/0.6.2-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-CC: Robert Lemmen , Dominique Dumont Please unblock package perl6-zef (explain the reason for the unblock here) As I reported in #928454, the outdated mirror URL list renders zef, the perl6 package manager nearly unusable: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928454 Luckily we can fix the package for Buster by simply updating the list: https://github.com/ugexe/zef/blob/master/resources/config.json#L60-L62 I asked upstream author on IRC and they acked that the mirror list is not likely to be changed for the Buster lifecycle. (include/attach the debdiff against the package in testing) ``` --- config.json.orig2019-05-05 03:31:08.251673414 + +++ config.json 2019-05-05 03:32:01.71262 + @@ -57,10 +57,9 @@ "name" : "p6c", "auto-update" : 1, "mirrors" : [ -"http://ecosystem-api.p6c.org/projects1.json;, -"http://ecosystem-api.p6c.org/projects.json;, + "https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json;, "git://github.com/ugexe/Perl6-ecosystems.git", - "https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json; +"http://ecosystem-api.p6c.org/projects1.json; ] } }, ``` unblock perl6-zef/0.6.2-2 -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#928180: unblock: fortunes-zh/2.95
Hi Boyuan, On Mon, Apr 29, 2019 at 10:30:55AM -0400, Boyuan Yang wrote: > Control: retitle -1 unblock: fortune-zh/2.95 > > The source package should be called "fortune-zh" instead of > "fortunes-zh". Sorry for the typo. Yes, that's a pitfall. I didn't change the source package name to avoid getting through NEW again.
Bug#927958: [pre-a] unblock: utf8proc/2.3.0-1
control: tags -1 -moreinfo Hi Niels, utf8proc 2.3.0-1 has been successfully built by all architectures: https://buildd.debian.org/status/package.php?p=utf8proc it should be ready to be unblocked. On Sat, Apr 27, 2019 at 06:58:00AM +, Niels Thykier wrote: > Please go ahead with the proposed changes and remove the moreinfo tag > once it is in unstable and ready to be unblocked. > > Thanks, > ~Niels
Bug#928005: nmu: julia_1.0.3+dfsg-4
Hi everyone, A note from maintainer of src:julia : src:julia depends on unicode-data because one section of its documentations uses the data to automatically generate a character list. It is the "ALL" architecture that should be rebuilt instead of "ANY". Since "ALL" doesn't support binNMU, I think I need a 1.0.3+dfsg-5 upload somehow. One of julia's dependency, utf8proc is affected by the recent unicode-data version bump. I've checked the code of the new upstream release 2.3.0 and uploaded it to unstable. It introduces no breaking change so will not require transition / binNMU. On Fri, Apr 26, 2019 at 10:11:03AM +0100, Alastair McKinstry wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > nmu julia_1.0.3+dfsg-4 . ANY . unstable . -m "rebuild against unicode-data > 12.1.0~pre1-2" > > -- System Information: > Debian Release: buster/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) (ignored: > LC_ALL set to en_IE.UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled
Bug#927958: [pre-a] unblock: utf8proc/2.3.0-1
Hi,
Here are some incremental updates to 2.3.0-1 following the last mail:
+ * Patch: update unicode-data version strings to 12.1.0
Upstream code hard-coded unicode-data version in the code. I need to
patch those string literals.
+ * Patch: Upstream didn't bump minor version in build system and header.
Upstream forgot to bump "MINOR" from 2 to 3 in the build system.
+ * Install the newly-added pkgconfig file. (Closes: #927260)
a very simple pkg-config file.
On Sat, Apr 27, 2019 at 02:38:44AM +0000, Mo Zhou wrote:
> control: tags -1 -moreinfo
>
> Hi,
>
> Debdiff has been attached. The patch is enormously large (3MB) but
> 99.9% of the content is automatically generated from unicode-data.
> See my extremely detailed comments to diffstat below:
>
> On Fri, Apr 26, 2019 at 06:58:00PM +, Niels Thykier wrote:
> > Please include a full debdiff of the changes. The link to a master
> > branch with no clear marking of start/end commits makes it too time
> > consuming for us to evaluate the request.
>
> Dch:
> * New upstream version 2.3.0
> * Bump unicode-data requirement to (>= 12.1) && (<< 12.2).
> * Refresh use-unicode-data.patch; Remove pass-hardening-flags.patch
> (merged).
> * Patch: update utf8proc_data.c against unicode-data 12.1.0~pre1.
> * Add a new symbol.
>
> diffstat for utf8proc-2.2.0 utf8proc-2.3.0
>
> .travis.yml | 19
> CMakeLists.txt | 14
>
> | we use Makefile and don't use cmake for the debian package.
>
> MANIFEST |2
> Makefile | 38
>
> | upstream merged Debian's patch. most changes are due to it.
>
> NEWS.md | 106
> README.md|4
> bench/Makefile |3
>
> | again, makefile change due to merging Debian patch.
>
> data/Makefile| 23
>
> | again, makefile change due to merging Debian patch.
>
> data/charwidths.jl | 119
>
> | this is not used in the build process.
>
> debian/changelog | 10
> debian/control |4
>
> | I need to bump unicode-data requirement
>
> debian/libutf8proc2.symbols |1
>
> | + utf8proc_unicode_version@Base 2.3.0
> | harmless symbol addition.
>
> debian/patches/pass-hardening-flags.patch| 69
>
> | removed. merged by upstream.
>
> debian/patches/series|2
> debian/patches/unicode-data-12.1.0pre1.patch | 8979
>
> | utf8proc_data.c is automatically generated from unicode-data (= 12.0)
> | I have to update the file against unicode-data (= 12.1) in unstable.
> | The change is 100% auto-generated.
>
> debian/patches/use-unicode-data.patch| 25
>
> | rebased.
>
> libutf8proc.pc.in| 10
>
> | this pkgconfig file is newly added. Still not installed in debian package.
>
> test/graphemetest.c | 22
>
> | space trimming and just one more test case
>
> test/misc.c |4
>
> | just one more assertion
>
> utf8proc.c | 22
>
> | Simpler character-width computation, and the new symbol:
> |
> |+UTF8PROC_DLLEXPORT const char *utf8proc_unicode_version(void) {
> |+ return "12.0.0";
> |+}
> |
> | Well, I should patch it to "12.1.0" after sending this mail.
>
> utf8proc.h |8
>
> | comment updates and the prototype for the new symbol
>
> utf8proc_data.c |1
> +--
>
> | 100% auto-generated from unicode-data 12.1.0~pre1 (unstable)
>
> 22 files changed, 16417 insertions(+), 7511 deletions(-)
>
Bug#927958: [pre-a] unblock: utf8proc/2.3.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package utf8proc (explain the reason for the unblock here) I'm astonished that the unicode (11.* -> 12.*) transition happend at such a deep freeze stage. utf8proc is tightly coupled with the unicode-data version, and the new unicode-data version incured FTBFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927941 The simplest way to fix this bug is to bump utf8proc to 2.3.0 (include/attach the debdiff against the package in testing) According to upstream NEWs/changelog https://github.com/JuliaStrings/utf8proc/commit/eb39b060e7e518941a912e1f51bae1cc6316f547 And the commit history (97ef668 -> 454f601) https://github.com/JuliaStrings/utf8proc/commits/master The major change from 2.2.0 (testing) to 2.3.0 (not yet packaged) is the support for unicode-data (= 12). There is no breaking change. So I request an unblock for 2.3.0-1 unblock utf8proc/2.3.0-1 -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#926976: [pre-a] unblock: blis/0.5.1-13
Hi, On Wed, Apr 24, 2019 at 11:02:03AM +0200, Paul Gevers wrote: > On Sat, 13 Apr 2019 03:30:38 +0000 Mo Zhou wrote: > > I'm going to fix this bug (the severity is actually important): > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926909 > > Please fix the bug's meta info to reflect that. Done. > It causes a FTBFS (on non-release architectures) in a reverse dependent > package, why does that only happen in experimental and not in sid? The FTBFS is a special case. The slepc package doesn't depend on blis directly. Some of its dependencies require "libblas-dev | libblas.so", and for some reason (I'm not quite clear at this point) mpich archs (e.g. m68k, sh4) picked libblis-openmp-dev as the libblas.so provider. At the dpkg-shlibdeps stage, error happended because dpkg cannot find any dependency information for libblas.so.3 , because I didn't write that information in the symbols control file. So, slepc found libblas.so, but dpkg failed to resolve dependency when libblis-*-dev is used to build packages. The bug actually affects blis << 0.5.2-4 . > The package in experimental is fixed now, have you considered to ask for a > gb of slepc, to see if this all works now? Theoretically the bits about dpkg-shlibdeps are expected to work well, but I'll try to gb slepc to validate the fix. > > I plan to first upload (= 0.5.1-12) with this tiny patch, > > abusing buildd to refresh symbol lists for all architectures: > > https://salsa.debian.org/science-team/blis/commit/ca29b285093acc602b891a993fa38a33f79a > > Then I'll upload (= 0.5.1-13) with collected symbol patches. > > I was going to suggest you use experimental for this, but as I noted > above experimental is already in use for a newer version, with the > change you are suggesting here applied IIUC. Do you have proof that this > works as intended there. A similar fix for the package in unstable would work because the fix is associated with dpkg shlibdeps resolving, and is unrelated to the upstream version. Maybe we don't have to prove that dpkg's dependency resolving works when the missing information has been added to symbols control file? > > Is this (quality improvement) change acceptable to Buster? > > https://release.debian.org/buster/freeze_policy.html [Changes which can > be considered]: > 2. fixes for severity: important bugs in packages of priority: optional, > only when this can be done via unstable; Thanks. The current blis package in testing leads to problematic dpkg shlib dependency resolving. The bug would also affect amd64 if blis was the only libblas.so provider (theoretically). I'll remove the moreinfo tag when the g-b build turns out to be successful.
Bug#926976: [pre-a] unblock: blis/0.5.1-13
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock I'd like to apply for unblocking package blis in advance. (explain the reason for the unblock here) I'm going to fix this bug (the severity is actually important): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926909 BLIS is one of the two fastest free-software BLAS implementations, and sometimes it's even faster than MKL... which means a lot to scientific computing users. So I'm eager to fix this problem for Buster for sake of package quality. I plan to first upload (= 0.5.1-12) with this tiny patch, abusing buildd to refresh symbol lists for all architectures: https://salsa.debian.org/science-team/blis/commit/ca29b285093acc602b891a993fa38a33f79a Then I'll upload (= 0.5.1-13) with collected symbol patches. The packaging detail for the BLAS/LAPACK family is a bit complex. Each BLIS variant (there are 6 variants in total) binary package ships two shared objects, one of them is used as libblis.so.2 registered as an alternative to libblis.so.2-, and another is libblas.so.3 stored in its subdirectory, registered as an alternative to libblas.so.3-. The current (= 0.5.1-11) version in testing/sid doesn't provide a dependency template for libblas.so.3, and that appears to be problematic as a drop-in replacement for libblas-dev. See the aforementioned bug. The proposed patch should be able to fix that. Is this (quality improvement) change acceptable to Buster? (include/attach the debdiff against the package in testing) unblock blis/0.5.1-13 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#925898: [t-p-u, pre-approval] unblock: highwayhash/0~git20181002.c5ee50b-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package highwayhash (explain the reason for the unblock here) The C++ symbols changed somehow since the -3 upload, which renders dpkg-gensymbols failure. However, the newer snapshot in sid FTBFS on arm* so it would not migrate even if I fixed the symbol lists. That means, well unfortunately, I have to go through testing-proposed-updates. Does it worth the effort to save the package for Buster? src:highwayhash's popcon is quite low (~ 10), and it has no reverse dependency in the archive except src:tensorflow. If RT doesn't bother dealing with such a t-p-u case, please feel free to close this bug and I'm totally fine with that. (include/attach the debdiff against the package in testing) The difference will be merely some C++ symbol updates. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924840 unblock highwayhash/0~git20181002.c5ee50b-4 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#925532: unblock: fish/3.0.2-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package fish (explain the reason for the unblock here) Fish's completion script for systemctl starts to print garbage on the screen since systemd-241. This revision merely fixes the very annoying behaviour. Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925308 unblock fish/3.0.2-2 (include/attach the debdiff against the package in testing) ~/D/fish ❯❯❯ debdiff --diffstat fish_3.0.2-1.dsc fish_3.0.2-2.dsc dpkg-source: warning: extracting unsigned source package (/home/lumin/Debian/fish/fish_3.0.2-2.dsc) diffstat for fish-3.0.2 fish-3.0.2 changelog |7 +++ patches/c6ec4235136e82c709e8d7b455f7c463f9714b48.diff | 33 ++ patches/series|1 3 files changed, 41 insertions(+) (...) dch diff truncated diff -Nru fish-3.0.2/debian/patches/c6ec4235136e82c709e8d7b455f7c463f9714b48.diff fish-3.0.2/debian/patches/c6ec4235136e82c709e8d7b455f7c463f9714b48.diff --- fish-3.0.2/debian/patches/c6ec4235136e82c709e8d7b455f7c463f9714b48.diff 1970-01-01 00:00:00.0 + +++ fish-3.0.2/debian/patches/c6ec4235136e82c709e8d7b455f7c463f9714b48.diff 2019-03-26 13:14:08.0 + @@ -0,0 +1,33 @@ +Source: https://github.com/fish-shell/fish-shell/commit/c6ec4235136e82c709e8d7b455f7c463f9714b48 +Fixes: https://github.com/fish-shell/fish-shell/issues/5689 +Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925308 +diff --git a/share/completions/systemctl.fish b/share/completions/systemctl.fish +index e42c2aa63..eeeb58cf0 100644 +--- a/share/completions/systemctl.fish b/share/completions/systemctl.fish +@@ -1,13 +1,13 @@ +-set -l systemd_version (systemctl --version | string match "systemd*" | string replace -r "\D*(\d+)" '$1') ++set -l systemd_version (systemctl --version | string match "systemd*" | string replace -r "\D*(\d+)\D.*" '$1') + set -l commands list-units list-sockets start stop reload restart try-restart reload-or-restart reload-or-try-restart \ + isolate kill is-active is-failed status show get-cgroup-attr set-cgroup-attr unset-cgroup-attr set-cgroup help \ + reset-failed list-unit-files enable disable is-enabled reenable preset mask unmask link load list-jobs cancel dump \ + list-dependencies snapshot delete daemon-reload daemon-reexec show-environment set-environment unset-environment \ + default rescue emergency halt poweroff reboot kexec exit suspend hibernate hybrid-sleep switch-root list-timers \ + set-property +-if test $systemd_version -gt 208 ++if test $systemd_version -gt 208 2>/dev/null + set commands $commands cat +-if test $systemd_version -gt 217 ++if test $systemd_version -gt 217 2>/dev/null + set commands $commands edit + end + end +@@ -79,7 +79,7 @@ complete -f -c systemctl -l version -d 'Print a short version and exit' + complete -f -c systemctl -l no-pager -d 'Do not pipe output into a pager' + + # New options since systemd 220 +-if test $systemd_version -gt 219 ++if test $systemd_version -gt 219 2>/dev/null + complete -f -c systemctl -l firmware-setup -n "__fish_seen_subcommand_from reboot" -d "Reboot to EFI setup" + complete -f -c systemctl -l now -n "__fish_seen_subcommand_from enable" -d "Also start unit" + complete -f -c systemctl -l now -n "__fish_seen_subcommand_from disable mask" -d "Also stop unit" diff -Nru fish-3.0.2/debian/patches/series fish-3.0.2/debian/patches/series --- fish-3.0.2/debian/patches/series2019-02-11 16:26:40.0 + +++ fish-3.0.2/debian/patches/series2019-03-26 13:16:52.0 + @@ -1,3 +1,4 @@ use-system-python isolate-home-tests use-curdir-not-pwd +c6ec4235136e82c709e8d7b455f7c463f9714b48.diff -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#924182: [pre-approval] unblock: julia/1.0.3+dfsg-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock This is a pre-approval for unblocking julia 1.0.3+dfsg-5, which follows the unblock request for llvm-toolchain-6.0 (= 1:6.0.1-11). The difference between julia/testing and julia/1.0.3+dfsg-5 will be: * Drop the embedded LLVM tarball from debian directory. * Remove dirty hacks used for building the vendored LLVM. * Build julia against system LLVM instead of the vendored one. The vendored LLVM was temporarily added since 1.0.3+dfsg-3, so it's quite safe to switch back to the system LLVM since nearly all patches required by julia have been added to llvm-toolchain-6.0 (= 1:6.0.1-11). (include/attach the debdiff against the package in testing) debdiff not available yet. unblock julia/1.0.3+dfsg-5 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#924181: unblock: llvm-toolchain-6.0/1:6.0.1-11
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package llvm-toolchain-6.0 -- Summary -- * Remove 'Multi-Arch: same' in libclang (Closes: #874248) * Cherry-pick various llvm fixes for Julia (Closes: #919628) * Rebase and enable D51639-optim-issue.diff * Remove some useless patches -- Detail -- diffstat for llvm-toolchain-6.0-6.0.1 llvm-toolchain-6.0-6.0.1 changelog | 14 control |1 * Remove 'Multi-Arch: same' in libclang (Closes: #874248) orig-tar.sh |6 Just changed several "http" into "https", to trivial to write into log. patches/D51639-optim-issue.diff | 22 This patch has been rebased and re-enabled because it fixes an old problem: 79ca353 2018-09-06 20:51 +0200 Sylvestre Ledru I Fix an optimization issues (Closes: #907649) See upstream bug 38786 patches/fix-lldb-server-build | 73 Removed. Deprecated long time ago. patches/install-lldb-sb-headers.patch | 58 Removed. Merged into upstream long time ago. patches/julia/llvm-6.0-NVPTX-addrspaces.patch | 32 patches/julia/llvm-D27629-AArch64-large_model_6.0.1.patch | 24 patches/julia/llvm-D34078-vectorize-fdiv.patch| 53 patches/julia/llvm-D42262-jumpthreading-not-i1.patch | 82 patches/julia/llvm-D44892-Perf-integration.patch | 677 + patches/julia/llvm-D50010-VNCoercion-ni.patch | 89 patches/julia/llvm-D50167-scev-umin.patch | 1143 ++ patches/julia/llvm-rL326967-aligned-load.patch| 301 patches/julia/llvm-rL327898.patch | 6131 ++ patches/series| 33 Fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919628 These patches are important for julia. Details on what each patch does: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919628#37 16 files changed, 8587 insertions(+), 152 deletions(-) debdiff attached. unblock llvm-toolchain-6.0/1:6.0.1-11 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled llvm.diff.zst Description: Binary data
Bug#923944: unblock: double-conversion/3.1.0-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
I've cherry-picked upstream commits to fix an upstream bug:
https://github.com/google/double-conversion/issues/89
That's all changes from 3.1.0-2 (testing) to 3.1.0-3.
The -3 revision will land on unstable shortly.
debdiff attached.
Detail:
* 8751aafe993c4ec429ba172916596403a336d502.diff
fixes upstream issue #89
* 860b43156c1ba436aba9792407429bf46b9780a0.diff
fixes typo in unit tests introduced by the above patch
unblock double-conversion/3.1.0-3
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru double-conversion-3.1.0/debian/changelog double-conversion-3.1.0/debian/changelog
--- double-conversion-3.1.0/debian/changelog 2018-09-20 05:41:28.0 +
+++ double-conversion-3.1.0/debian/changelog 2019-03-07 14:15:09.0 +
@@ -1,3 +1,9 @@
+double-conversion (3.1.0-3) unstable; urgency=medium
+
+ * Cherry-pick upstream commits to fix incorrect downcasting of separator_.
+
+ -- Mo Zhou Thu, 07 Mar 2019 14:15:09 +
+
double-conversion (3.1.0-2) unstable; urgency=medium
* autopkgtest: Add one more test script unittest.sh .
diff -Nru double-conversion-3.1.0/debian/patches/860b43156c1ba436aba9792407429bf46b9780a0.diff double-conversion-3.1.0/debian/patches/860b43156c1ba436aba9792407429bf46b9780a0.diff
--- double-conversion-3.1.0/debian/patches/860b43156c1ba436aba9792407429bf46b9780a0.diff 1970-01-01 00:00:00.0 +
+++ double-conversion-3.1.0/debian/patches/860b43156c1ba436aba9792407429bf46b9780a0.diff 2019-03-07 14:06:42.0 +
@@ -0,0 +1,15 @@
+Modified from https://github.com/google/double-conversion/commit/860b43156c1ba436aba9792407429bf46b9780a0
+
+Index: double-conversion/test/cctest/test-conversions.cc
+===
+--- double-conversion.orig/test/cctest/test-conversions.cc
double-conversion/test/cctest/test-conversions.cc
+@@ -3603,7 +3603,7 @@ TEST(StringToDoubleSeparator) {
+ CHECK(all_used);
+
+ CHECK_EQ(3.0,
+- StrToD16("0x0@23.p0", flags, 0.0, , _used,
++ StrToD16("0x0@3.p0", flags, 0.0, , _used,
+ char_separator, separator));
+ CHECK(all_used);
+ }
diff -Nru double-conversion-3.1.0/debian/patches/8751aafe993c4ec429ba172916596403a336d502.diff double-conversion-3.1.0/debian/patches/8751aafe993c4ec429ba172916596403a336d502.diff
--- double-conversion-3.1.0/debian/patches/8751aafe993c4ec429ba172916596403a336d502.diff 1970-01-01 00:00:00.0 +
+++ double-conversion-3.1.0/debian/patches/8751aafe993c4ec429ba172916596403a336d502.diff 2019-03-07 14:06:42.0 +
@@ -0,0 +1,153 @@
+Fixes upstream bug: https://github.com/google/double-conversion/issues/89
+Cherry-picked from: https://github.com/google/double-conversion/commit/8751aafe993c4ec429ba172916596403a336d502
+
+Index: double-conversion/double-conversion/double-conversion.cc
+===
+--- double-conversion.orig/double-conversion/double-conversion.cc
double-conversion/double-conversion/double-conversion.cc
+@@ -553,7 +553,7 @@ static bool IsCharacterDigitForRadix(int
+
+ // Returns true, when the iterator is equal to end.
+ template
+-static bool Advance (Iterator* it, char separator, int base, Iterator& end) {
++static bool Advance (Iterator* it, uc16 separator, int base, Iterator& end) {
+ if (separator == StringToDoubleConverter::kNoSeparator) {
+ ++(*it);
+ return *it == end;
+@@ -581,7 +581,7 @@ static bool Advance (Iterator* it, char
+ template
+ static bool IsHexFloatString(Iterator start,
+ Iterator end,
+- char separator,
++ uc16 separator,
+ bool allow_trailing_junk) {
+ ASSERT(start != end);
+
+@@ -622,7 +622,7 @@ template (0x123456789),
++ StrToD16("0x1@2@3@4@5@6@7@8@9", flags, Double::NaN(),
++, _used, char_separator, separator));
++ CHECK(all_used);
++
++ CHECK_EQ(18.0, StrToD16(" 0x1@2 ", flags, 0.0,
++ , _used, char_separator, separator));
++ CHECK(all_used);
++
++ CHECK_EQ(static_cast(0xabcdef),
++ StrToD16("0xa@b@c@d@e@f", flags, 0.0,
++, _used, char_separator, separator));
++ CHECK(all_used);
++
++ CHECK_EQ(Double::NaN(),
++ St
Bug#923770: unblock: zfs-linux/0.7.13-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-CC: a...@debian.org Please unblock package zfs-linux which will land on unstable shortly. Please note that the upstream version of src:spl-linux must be aligned with src:zfs-linux, hence they should be unblocked at the same time. (explain the reason for the unblock here) [from 0.7.12-2 to 0.7.13-1] * New upstream release (released several hours ago) * Cherry-picked/backported many bug fixes from upstream. * linux 4.20 and 5.0 compatibility (include/attach the debdiff against the package in testing) More than 7000 lines of changes makes the all-in-one debdiff insane. Please review this instead: https://salsa.debian.org/zfsonlinux-team/zfs/compare/debian%2F0.7.12-2...debian%2F0.7.13-1 unblock zfs-linux/0.7.13-1 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#923769: unblock: spl-linux/0.7.13-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-CC: a...@debian.org Please unblock package spl-linux which will land on unstable shortly. (explain the reason for the unblock here) New upstream release (released several hours ago). (include/attach the debdiff against the package in testing) Maybe this is much better than the hard-to-review debdiff: https://salsa.debian.org/zfsonlinux-team/spl/compare/debian%2F0.7.12-2...debian%2F0.7.13-1 unblock spl-linux/0.7.13-1 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#868355: Any reason not to simply upload ceres-solver with adjusted version of libeigen3-dev
On Tue, Feb 26, 2019 at 11:25:49AM +0100, Andreas Tille wrote: > > The eigen3 maintainer and I are happy to simply rebuild affected > > packages after every eigen3 update, but Emilio considers it an upstream bug. > > Unfortunately I could not find anybody able to shed more light on the > > eigen3 topic. > > I agree that the topic seems to be more complex in general but for the > moment we need a fix for Buster and that fix is very simple - so I do > not see any reason to not fix it. You might like to reopen the relevant > bugs (I mean #868355 - I just asked for closing which was done and > #883619) with lower severity to keep on discussing for Buster+1. Similar to packages built against static libraries, eigen3 as a header-only library gives us no chance except for binNMU all the rdeps. There are a lot of header only packages in my packaging radar, and the transition problem really brings me headache. Fortunately they won't have to much rdeps at the beginning.
Bug#915721: transition: opencv
On Sun, Jan 13, 2019 at 08:06:57PM +0100, Emilio Pozuelo Monfort wrote: > > What is the status with the rdeps? I looked at two bugs and they worry me: I haven't had enough time to test rdeps for another round. But I guess the situation would be similar to the first round. > #915544 suggests the OpenCV C API is broken, and ffmpeg solved it by disabling > ffmpeg support altogether. > > #915709 seems to point to the same brokenness. Quoted from upstream: https://github.com/opencv/opencv/issues/10963#issuecomment-369259044 | OpenCV 3.x doesn't not support C compilation mode officially. And if you look at upstream Pull Requests you will find that upstream is gradually removing legacy C APIs. So, those rdeps broken due to the C API are questionable because they are using non-officially supported (deprecated) part of opencv ... There are another failing pattern, which stems from changes in C++ class method, and is easy to fix ... I'm currently putting out the fire on the julia package so I cannot make a statistics. > The way it looks, I don't think we can go ahead with this at this stage. Both result are acceptable to me -- wether we can go ahead or not. Pausing the transition helps my laziness. Moving forward, although radical and breaks some questionable rdeps, brings some new features such as the DNN module which supports not only pre-trained tensorflow model.
Bug#915721: transition: opencv
Hi,
Any updates? Transition freeze is close. The current version of OpenCV
(3.2.0) in Sid is quite ancient (Dec 23, 2016).
mips{,64}el buildd are again lagging behind the other architectures for
the last binNMU. And before any ack I'm not going to manually build it
again on mips box since I'm not buildd.
Builds for 3.4.5+dfsg-1~exp1 were successful so I don't expect any
problem for 3.4.5+dfsg-1~exp1+b1 .
On Mon, Dec 31, 2018 at 10:14:20AM +, Mo Zhou wrote:
> I've uploaded opencv 3.4.5 to experimental which fixed some issues found
> in the previous version. This time mipsel and mips64el is still lagging
> behind other other architectures. I'll build binaries by myself for the
> two architectures and I don't expect any buiid failure.
Bug#915721: transition: opencv
I've uploaded opencv 3.4.5 to experimental which fixed some issues found
in the previous version. This time mipsel and mips64el is still lagging
behind other other architectures. I'll build binaries by myself for the
two architectures and I don't expect any buiid failure.
3.4.5 Will be green on all official architectures in about 36 hours
(each build takes more than 12 hours)
On Thu, Dec 27, 2018 at 11:35:18AM +, Mo Zhou wrote:
> OpenCV 3.4.4 is green on all official architectures after uploading
> manually built mips{,64}el packages by using Yunqiang's machine.
>
> Shall we move on?
>
> On Mon, Dec 24, 2018 at 01:49:45AM +, Mo Zhou wrote:
> > On Wed, Dec 19, 2018 at 11:32:36AM +0100, Emilio Pozuelo Monfort wrote:
> > > I was going to ack this, but I noticed that opencv failed to build on some
> > > architectures:
> > >
> > > https://buildd.debian.org/status/package.php?p=opencv=experimental
> > >
> > > Please look at that before we start this.
> >
> > opencv was given-back on armel several days ago. minkus (mips) cannot
> > reproduce the FTBFS on mips so I assume the reason is similar to armel,
> > so I'll give-back it later. eller (mipsel/mips64el) has successfully
> > built the opencv package, although buildd still hasn't started the build
> > yet.
> >
> > Can we move on without waiting for mipsel and mips64el? The buildd
> > scheduler puts too small a weight for experimental distribution...
Bug#915721: transition: opencv
OpenCV 3.4.4 is green on all official architectures after uploading
manually built mips{,64}el packages by using Yunqiang's machine.
Shall we move on?
On Mon, Dec 24, 2018 at 01:49:45AM +, Mo Zhou wrote:
> On Wed, Dec 19, 2018 at 11:32:36AM +0100, Emilio Pozuelo Monfort wrote:
> > I was going to ack this, but I noticed that opencv failed to build on some
> > architectures:
> >
> > https://buildd.debian.org/status/package.php?p=opencv=experimental
> >
> > Please look at that before we start this.
>
> opencv was given-back on armel several days ago. minkus (mips) cannot
> reproduce the FTBFS on mips so I assume the reason is similar to armel,
> so I'll give-back it later. eller (mipsel/mips64el) has successfully
> built the opencv package, although buildd still hasn't started the build
> yet.
>
> Can we move on without waiting for mipsel and mips64el? The buildd
> scheduler puts too small a weight for experimental distribution...
>
Bug#915721: transition: opencv
On Wed, Dec 19, 2018 at 11:32:36AM +0100, Emilio Pozuelo Monfort wrote: > I was going to ack this, but I noticed that opencv failed to build on some > architectures: > > https://buildd.debian.org/status/package.php?p=opencv=experimental > > Please look at that before we start this. opencv was given-back on armel several days ago. minkus (mips) cannot reproduce the FTBFS on mips so I assume the reason is similar to armel, so I'll give-back it later. eller (mipsel/mips64el) has successfully built the opencv package, although buildd still hasn't started the build yet. Can we move on without waiting for mipsel and mips64el? The buildd scheduler puts too small a weight for experimental distribution...
Bug#915721: transition: opencv
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition opencv 3.4.4 introduced new features, bug fixes including CVE fixes. I'd like to request for a transition slot. The rebuild for all reverse build depends has been done locally, and here is the result: (12 packages FTBFS) actiona [skipped: already FTBFS with Qt 5.11 #909828] auto-multiple-choice [OK] beads [OK] caffe [OK] cheese [OK] cimg [skipped; arch=all] digikam [OK] eviacam [FTBFS #915708] ffmpeg [FTBFS #915544] freecad [OK] freemedforms-project [OK] freeture [skipped; already #914060 freeture FTBFS with boost 1.67] frei0r [FTBFS #915707] gmic [OK] gnome-dvb-daemon [OK] gnome-mousetrap [skipped; arch=all] gst-plugins-bad1.0 [FTBFS #915709] gstreamer-vaapi [OK] libkf5kface [FTBFS #915710] limereg [OK] mldemos [FTBFS #915711] mrpt [OK] nomacs [OK] oggvideotools [OK] openalpr [OK] opencfu [OK] openimageio [OK] os-autoinst [OK] otb [OK] php-facedetect [FTBFS #915712] psychopy [skipped: arch=all] remotecv [skipped: arch=all] ros-opencv-apps [FTBFS #915529] ros-vision-opencv [OK] saga [OK] sdaps [OK] siril [skipped, already ftbfs against glibc 2.28 #913854] sitplus [FTBFS #915592] thumbor [OK (test skipped)] uprightdiff [OK] visp [OK] webkit2gtk [OK] willow [skipped; arch=all] Ben file: title = "opencv"; is_affected = .depends ~ /\b(libopencv\-calib3d3\.2|libopencv\-contrib3\.2|libopencv\-core3\.2|libopencv\-features2d3\.2|libopencv\-flann3\.2|libopencv\-highgui3\.2|libopencv\-imgcodecs3\.2|libopencv\-imgproc3\.2|libopencv\-ml3\.2|libopencv\-objdetect3\.2|libopencv\-photo3\.2|libopencv\-shape3\.2|libopencv\-stitching3\.2|libopencv\-superres3\.2|libopencv\-video3\.2|libopencv\-videoio3\.2|libopencv\-videostab3\.2|libopencv\-viz3\.2|libopencv3\.2\-java|libopencv3\.2\-jni)\b/ | .depends ~ /\b(libopencv\-calib3d3\.4|libopencv\-contrib3\.4|libopencv\-core3\.4|libopencv\-dnn\-dev|libopencv\-dnn3\.4|libopencv\-features2d3\.4|libopencv\-flann3\.4|libopencv\-highgui3\.4|libopencv\-imgcodecs3\.4|libopencv\-imgproc3\.4|libopencv\-ml3\.4|libopencv\-objdetect3\.4|libopencv\-photo3\.4|libopencv\-shape3\.4|libopencv\-stitching3\.4|libopencv\-superres3\.4|libopencv\-video3\.4|libopencv\-videoio3\.4|libopencv\-videostab3\.4|libopencv\-viz3\.4|libopencv3\.4\-java|libopencv3\.4\-jni)\b/; is_good = .depends ~ /\b(libopencv\-calib3d3\.4|libopencv\-contrib3\.4|libopencv\-core3\.4|libopencv\-dnn\-dev|libopencv\-dnn3\.4|libopencv\-features2d3\.4|libopencv\-flann3\.4|libopencv\-highgui3\.4|libopencv\-imgcodecs3\.4|libopencv\-imgproc3\.4|libopencv\-ml3\.4|libopencv\-objdetect3\.4|libopencv\-photo3\.4|libopencv\-shape3\.4|libopencv\-stitching3\.4|libopencv\-superres3\.4|libopencv\-video3\.4|libopencv\-videoio3\.4|libopencv\-videostab3\.4|libopencv\-viz3\.4|libopencv3\.4\-java|libopencv3\.4\-jni)\b/; is_bad = .depends ~ /\b(libopencv\-calib3d3\.2|libopencv\-contrib3\.2|libopencv\-core3\.2|libopencv\-features2d3\.2|libopencv\-flann3\.2|libopencv\-highgui3\.2|libopencv\-imgcodecs3\.2|libopencv\-imgproc3\.2|libopencv\-ml3\.2|libopencv\-objdetect3\.2|libopencv\-photo3\.2|libopencv\-shape3\.2|libopencv\-stitching3\.2|libopencv\-superres3\.2|libopencv\-video3\.2|libopencv\-videoio3\.2|libopencv\-videostab3\.2|libopencv\-viz3\.2|libopencv3\.2\-java|libopencv3\.2\-jni)\b/; -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#893189: llvm-defaults to llvm-7 ? [was: Re: Bug#893189: transition: llvm-defaults to llvm 6.0]
Hi Sylvestre, F.Y.I. > * llvm 6.0 upstream won't have a new upstream release * I have been > focusing my Debian effort on 7 for a while, so, packaging is a much > better shape Julia upstream backported many patches from llvm-7 to their vendored llvm-6 source. However it's llvm-7 support is still under development and is not likely to be merged by the stable 1.0.X series. I may have to port some patches from llvm-7 to Debian's llvm-6 for julia 1.0.X, if upstream doesn't release julia 1.1 before Buster release, which would support llvm-7. > * Remove everything but 6 & 7 from the archive to release with only > two llvm versions. (maybe one if we are very lucky? :) IIRC Julia 1.0.X FTBFS with llvm-7. Sorry for the bad news :( If upstream can release 1.1.X before Buster freeze, julia won't block llvm-6 removal.
