Bug#1033733: vkd3d: new upstream release 1.11
Hi, I'm a vkd3d upstream developer. Unfortunately I haven't had a lot of time for Debian for a few years, but I'm happy to help here if needed. Il 28/05/24 19:36, Simon McVittie ha scritto: Since then there have been several more upstream releases and it is currently at v1.11. And now v1.12, just yesterday. I need .deb packages of this version for a work project, so I've been looking at updating the packaging used for Debian as a starting point for that Please consider merging this: Updated version at: https://salsa.debian.org/smcv-guest/vkd3d wip/1.11 Once again I used `uscan --download` to get the orig.tar.* I used for test-builds. debian/patches/fixes/byte-comparison.patch no longer applies; I dropped it for now (and the package builds successfully in my environment), but if it's still necessary for other build environments, it will need some adjustment. It would be ideal if this issue could be reported upstream and fixed there. compare_uint() and compare_color() are now in tests/utils.h. I don't really understand in which cases that patch is supposed to help, but it's true that vkd3d assumes every now and then that the architecture is one of i386, amd64, arm or arm64 (i.e., the architectures meaningful for Windows). So it's totally possible that a little endian assumption has trickled in somewhere, though it's not immediately clear to me how endianness should break something here. For the failing tests, as you might already have noticed, most vkd3d developers use AMD GPUs. I'm slowly trying to clean up the tests on llvmpipe, Intel and NVIDIA GPUs (and also more exotic Vulkan implementations, like MoltenVK and mobile GPUs), but that tends to be relatively low priority. Gio.
Bug#1067312: spirv-tools: FTBFS: operand.kinds-unified1.inc:566:97: error: ‘SPV_OPERAND_TYPE_NAMED_MAXIMUM_NUMBER_OF_REGISTERS’ was not declared in this scope
Hi, On Wed, 20 Mar 2024 21:58:27 +0100 Lucas Nussbaum wrote:> During a rebuild of all packages in sid, your package failed to build on amd64. I'm having the same problem. As a data point, builds succeeds as soon as I revert spirv-headers to 1.6.1+1.3.275.0-1. HTH, Gio.
Bug#1051710: Cannot use Ctrl-C to interrupt remote command with ControlMaster=auto
Package: openssh-client Version: 1:9.4p1-1 Severity: normal My SSH is configured with these directives: ControlMaster auto ControlPath ~/.ssh/control/%r@%h:%p.sock ControlPersist yes Suppose I connect to some host and launch a command potentially running for a long or infinite time: $ ssh host tail -F some/file Up to version 1:9.3p2-1 I could stop the remote command and the SSH process pressing Ctrl-C (i.e., by sending SIGINT to the SSH process). This doesn't work any more. It works instead if I disable the control session: $ ssh -o ControlMaster=no host tail -F some/file Thanks for maintaining the package, Giovanni. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openssh-client depends on: ii adduser 3.137 ii libc6 2.37-8 ii libedit2 3.1-20221030-2 ii libfido2-11.13.0-1+b1 ii libgssapi-krb5-2 1.20.1-3 ii libselinux1 3.5-1 ii libssl3 3.0.10-1 ii passwd1:4.13+dfsg1-1+b1 ii zlib1g1:1.2.13.dfsg-3 Versions of packages openssh-client recommends: ii xauth 1:1.1.2-1 Versions of packages openssh-client suggests: pn keychain pn libpam-ssh pn monkeysphere ii ssh-askpass 1:1.2.4.1-16 -- no debconf information
Bug#1008573: Workaround for Nitrokey Start
Hi, I have a Nitrokey Start that has the same problem, but the suggested workaround was not enough for me. After a few attempts, I discovered that I need this in my ssh_config file: KexAlgorithms -sntrup761x25519-sha...@openssh.com HostKeyAlgorithms -ecdsa-sha2-nistp256 Notice that after this change connections to hosts that previously used a ecdsa-sha2-nistp256 host key will fail key verification and trigger the usual scary message about a MITM attack. Thanks, Giovanni. -- Giovanni Mascellani
Bug#1016321: boost1.74: FTBFS: runtime error: file /<>/tools/boostbook/xsl/annotation.xsl line 432 element element xsl:element: The effective name '' is not a valid QName.
Hi, On Thu, 18 Aug 2022 15:32:41 +0200 Giovanni Mascellani wrote:> If you still have version 1.1.34 (or downgrade), then everything will work and the output file output.boostbook will be generated (a couple of warnings will be printed, but they are not problematic; or, at least, they are a different problem). As a further step, I bisected libxslt and determined that the regression (if it is a regression) is caused by commit [1], which claims to solve [2]. Apparently libxslt was evaluating XSLT templates in the wrong order, and that commit fixed that, but I guess that boostbook depended on that order to work properly. [1] https://gitlab.gnome.org/GNOME/libxslt/-/commit/b0074eeca3c6b21b4da14fdf712b853900c51635 [2] https://gitlab.gnome.org/GNOME/libxslt/-/issues/55 Giovanni.
Bug#1016321: boost1.74: FTBFS: runtime error: file /<>/tools/boostbook/xsl/annotation.xsl line 432 element element xsl:element: The effective name '' is not a valid QName.
Il 12/08/22 21:32, Giovanni Mascellani ha scritto: Thanks for filing the bug. It seems that Boost builds fine with xsltproc and libxslt1version 1.1.34 (instead of 1.1.35 currently in sid). I am not an XSLT master and it seems that nobody upstream has noticed yet, maybe because 1.1.35 is still relatively recent. I'll file a bug upstream to see if they can work out a solution. I sent an email to the Boost development mailing list[1], which is unfortunately not getting any attention for the moment. [1] https://lists.boost.org/Archives/boost/2022/08/253369.php In the meantime, I also created a minimal test case, so that somebody who knows about XSLT can look at that without having to deal with the Boost building system. In order to reproduce the bug, you have to: 1. Download the attached reproduce.tar.gz 2. Extract it in /tmp. You can also use another directory, but then you have to fix an absolute path, se below. 3. Install docbook-xml, docbook-xsl and xsltproc. 4. If you didn't extract in /tmp, edit the absolute path in reproduce/boostbook/boostbook_catalog.xml appropriately. 5. Go to /tmp/reproduce, or wherever you extracted it, and launch ./execute.sh (which is just a wrapper over the appropriate xsltproc command line). If you already have xsltproc and libxslt1.1 version 1.1.35, then you will see a lot of errors of this form: runtime error: file boostbook/xsl/annotation.xsl line 432 element element xsl:element: The effective name '' is not a valid QName. If you still have version 1.1.34 (or downgrade), then everything will work and the output file output.boostbook will be generated (a couple of warnings will be printed, but they are not problematic; or, at least, they are a different problem). If anybody knows how to fix libxslt or the boostbook XSLTs, then please let me know! Thanks, Giovanni. -- Giovanni Mascellani reproduce.tar.gz Description: application/gzip
Bug#1016321: boost1.74: FTBFS: runtime error: file /<>/tools/boostbook/xsl/annotation.xsl line 432 element element xsl:element: The effective name '' is not a valid QName.
Hi, Il 29/07/22 20:32, Lucas Nussbaum ha scritto: During a rebuild of all packages in sid, your package failed to build on amd64. Thanks for filing the bug. It seems that Boost builds fine with xsltproc and libxslt1version 1.1.34 (instead of 1.1.35 currently in sid). I am not an XSLT master and it seems that nobody upstream has noticed yet, maybe because 1.1.35 is still relatively recent. I'll file a bug upstream to see if they can work out a solution. Giovanni.
Bug#978748: libboost-dev: Boost 1.75
Hi, Il 14/04/22 04:24, strager ha scritto: Is there anything I can do to help get a newer version of Boost into the Debian repository? Unfortunately I am not having a lot of time to care about Boost right now, even if I'll get to it as soon as possible. I don't know what is your experience with Debian packaging, but Boost if you're a beginner I don't feel it's the right package to start with. As you say, vendoring code is usually not considered a good idea in Debian, but in can be a reasonable interim solution, I'd say, as long as you're happy to switch back to the packaged dependency once it is available. I would suggest you to investigate this road for quick-lint-js. I won't be able to provide much help, though. Thanks, Giovanni. -- Giovanni Mascellani
Bug#1005201: boost1.74: outdated embedded data copy: unicode-data
Hi, thanks for reopening the bug on the new Boost package. I agree that these issues should be solved; unfortunately I am very low on time to do that. Thanks, Giovanni. Il 09/02/22 00:25, Paul Wise ha scritto: Source: boost1.74 Severity: normal Usertags: embed Unicode 14 was released and unicode-data 14.0.0-1.1 was uploaded. The boost1.74 source package contains very very outdated embedded data copies of several files from Unicode 5.2.0:
Bug#985661: libboostM.mm-dev no .pc file
Hi Valerio, Il 10/02/22 23:28, Valerio Messina ha scritto: as now I had the package "libboost1.67-dev" installed, I'm on Debian 10. I checked in package installed files, no .pc is there. The bug got closed because Boost 1.71 was removed from Debian. Version 1.74 is new the default one, so I reopened the bug and assigned to 1.74. That said, I don't know when I'll have the time to actually think about the bug itself. Giovanni. -- Giovanni Mascellani
Bug#960565: Here too
Hi, Happening for me too. Worked around by commenting the "exit 0" line in /etc/grub.d/30_os-prober. It's strange, though, because the bug was originally reported half 2020; while my computer (installed during 2021) started displaying the bug only today. Probably the bug is triggered by some combination of other factors. Giovanni. -- Giovanni Mascellani
Bug#1000974: copy_move_algo.hpp:1083:10: error: ‘__fallthrough__’ was not declared in this scope; did you mean ‘fallthrough’?
reassign 1000974 xfslibs-dev
severity 1000974 important
retitle 1000974 xfs/linux.h defines common word "fallthrough" breaking
unrelated headers
thanks
Hi,
On 04/12/21 23:36, Thomas Goirand wrote:
On 12/4/21 5:11 PM, Giovanni Mascellani wrote:
Could you try running that compilation command with g++ -E, so you can
see what BOOST_FALLTHROUGH is actually begin replaced with?
Oh, sorry, now I get what you meant (did a c++ --help to understand what
-E was doing). Here's the result in
CMakeFiles/seastar.dir/src/core/file.cc.o:
__attribute__((__attribute__((__fallthrough__;
Probably, there's a mistake, and it should really be:
__attribute__((__fallthrough__));
instead, which is the source of the trouble?
It seems that the problem goes this way:
* Boost defines in /usr/include/boost/config/compiler/gcc.hpp:
#define BOOST_FALLTHROUGH __attribute__((fallthrough))
* But /usr/include/xfs/linux.h defines:
#define fallthrough __attribute__((__fallthrough__))
So the "fallthrough" in Boost's definition is expanded again and causes
the problem.
I think xfs/linux.h is at fault here, because it aggressively defines a
common word (while Boost namespaces all its definitions with a BOOST_
prefix). Unfortunately the C/C++ preprocessor makes it easy to break
other headers if you define stuff too liberally. This wold also, for
example, break any program that use the name "fallthrough" for a
variable, which is a completely reasonable name to use. A simple example
could be:
---
#include
int main() {
int fallthrough = 0;
return fallthrough;
}
---
which fails compilation with:
---
$ LANG=C gcc test.c
test.c: In function 'main':
test.c:4:5: warning: 'fallthrough' attribute not followed by ';'
[-Wattributes]
4 | int fallthrough = 0;
| ^~~
test.c:4:21: error: expected identifier or '(' before '=' token
4 | int fallthrough = 0;
| ^
In file included from test.c:1:
test.c:5:12: error: expected expression before '__attribute__'
5 | return fallthrough;
|^~~
---
You can probably work around this problem by undefining "fallthrough"
just after the xfs/linux.h header. In the meantime I am reassigning this
bug to xfslibs-dev.
Giovanni.
--
Giovanni Mascellani
Bug#1000974: copy_move_algo.hpp:1083:10: error: ‘__fallthrough__’ was not declared in this scope; did you mean ‘fallthrough’?
Hi, On 01/12/21 22:21, Thomas Goirand wrote: Hi there! When building Ceph (current version in Experimental), since a few days/weeks, I get this: In file included from /root/ceph/ceph/src/seastar/src/core/file.cc:28: /usr/include/boost/container/detail/copy_move_algo.hpp: In function ‘typename boost::move_detail::enable_if_c<(boost::container::dtl::is_memtransfer_copy_assignable::value && true), void>::type boost::container::deep_swap_alloc_n(A llocator&, F, typename boost::container::allocator_traits::size_type, G, typename boost::container::allocator_traits::size_type)’: /usr/include/boost/container/detail/copy_move_algo.hpp:1083:10: error: ‘__fallthrough__’ was not declared in this scope; did you mean ‘fallthrough’? 1083 | BOOST_FALLTHROUGH; | ^ Uhm, that's strange. For gcc that macro should resolve to __attribute__((fallthrough)), which should just work[1]. [1] https://sources.debian.org/src/boost1.74/1.74.0-13/libs/config/include/boost/config/compiler/gcc.hpp/#L323 I don't like the idea of using the new [[...]] syntax, because that would break all the code that is not compiling at least with C++17. Could you try running that compilation command with g++ -E, so you can see what BOOST_FALLTHROUGH is actually begin replaced with? Giovanni. -- Giovanni Mascellani
Bug#1000506: boost1.71 FTBFS with Python 3.10
Hi, On 24/11/21 12:53, Adrian Bunk wrote: Source: boost1.71 Version: 1.71.0-7+b3 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=boost1.71&ver=1.71.0-7%2Bb3 ... libs/python/src/exec.cpp:109:14: error: ‘_Py_fopen’ was not declared in this scope; did you mean ‘_Py_wfopen’? 109 | FILE *fs = _Py_fopen(f, "r"); | ^ | _Py_wfopen ... Thanks for reporting this. Ideally the best way to fix this bug would be to get rid of boost1.71, given that boost1.74 already exists (also, a new version should be packaged, but that's another story). Giovanni. -- Giovanni Mascellani
Bug#995162: cannot install together with i386
Hi Mattia, Il 29/09/21 19:28, Mattia Rizzolo ha scritto: This is triggered by the binNMU, which varies the date of the changelog, so that dh_strip_nondeterminism will normalize the metadata of the .png to the binNMU build time instead of the time of the source upload as it was before. Thanks for the info. Unless I am mistaken, this means that any package which installs a shared PNG breaks at every binNMU, unless the binNMU is for all architectures. Wouldn't it be better if dh_strip_nondeterminism used the last sourceful upload as reference timestamp? Was this option considered? Thanks, Giovanni. -- Giovanni Mascellani
Bug#995162: cannot install together with i386
Package: libp11-kit-dev Version: 0.24.0-2+b1 Severity: important Hi! libp11-kit-dev:amd64 cannot be installed together with :i386: # LANG=C apt install libp11-kit-dev Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: linux-doc-5.10 linux-image-5.10.0-7-amd64 linux-image-5.10.0-8-amd64 Use 'apt autoremove' to remove them. The following NEW packages will be installed: libp11-kit-dev 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/222 kB of archives. After this operation, 742 kB of additional disk space will be used. Selecting previously unselected package libp11-kit-dev:amd64. (Reading database ... 853319 files and directories currently installed.) Preparing to unpack .../libp11-kit-dev_0.24.0-2+b1_amd64.deb ... Unpacking libp11-kit-dev:amd64 (0.24.0-2+b1) ... dpkg: error processing archive /var/cache/apt/archives/libp11-kit- dev_0.24.0-2+b1_amd64.deb (--unpack): trying to overwrite shared '/usr/share/gtk-doc/html/p11-kit/home.png', which is different from other instances of package libp11-kit-dev:amd64 Errors were encountered while processing: /var/cache/apt/archives/libp11-kit-dev_0.24.0-2+b1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Thanks for caring about this package! :-) Giovanni. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#889822: Can the bug for the Bullseye release still be fixed?
Hi, Il 19/03/21 09:23, Matthias Klein ha scritto: Is there any chance / possibility to fix the problem? Maybe even still for bullseye? No, I think it is too late for bullseye, and I wouldn't have the time to work on it anyway, sorry. Though I generally agree that it would be nicer to have Multi-Arch: same for boost -dev package. Giovanni. -- Giovanni Mascellani
Bug#983860: segfaults because tries to use non-free kernels
Hi, Il 02/03/21 13:08, Sebastian Ramacher ha scritto: Thanks, in that case it's most likely the issue at https://github.com/intel/media-driver/issues/1132 Seems likely, thanks. Giovanni. -- Giovanni Mascellani
Bug#983860: segfaults because tries to use non-free kernels
Il 02/03/21 12:29, Sebastian Ramacher ha scritto: Which CPU/GPU is that? Sorry, I forgot: $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 158 model name : Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz stepping: 10 microcode : 0xde cpu MHz : 2781.102 cache size : 12288 KB physical id : 0 siblings: 12 core id : 0 cpu cores : 6 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple pml ept_mode_based_exec bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds bogomips: 5799.77 clflush size: 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: > [...] Thanks, Giovanni. -- Giovanni Mascellani
Bug#983860: segfaults because tries to use non-free kernels
Package: intel-media-va-driver Version: 21.1.1+dfsg1-1 Severity: important On my CPU iHD_drv_video.so segfaults when decoding an MP4 movie. I can for example reproduce it by installing gstreamer1.0-vaapi and running: $ gst-launch-1.0 playbin uri=https://test- videos.co.uk/vids/bigbuckbunny/mp4/h264/360/Big_Buck_Bunny_360_10s_1MB.mp4 Gdb shows this backtrace (truncated, because it's more than 100 frames, and the interesting ones are at the top): #0 KernelDll_AllocateStates(void*, uint32_t, void*, uint32_t, Kdll_RuleEntry const*, void (*)(PKdll_State)) (pKernelBin=pKernelBin@entry=0x7fffd42e59f0, uKernelSize=0x0, pFcPatchCache=pFcPatchCache@entry=0x0, uFcPatchCacheSize=, pDefaultRules=0x0, ModifyFunctionPointers=0x0) at ./media_driver/agnostic/common/vp/kdll/hal_kerneldll.c:3350 #1 0x7fffd296bfdb in VphalRenderer::Initialize(VphalSettings const*, bool) (this=0x7fffd4327e30, pSettings=0x71745ac0, isApoEnabled=) at ./media_driver/agnostic/common/vp/hal/vphal_renderer.cpp:1414 #2 0x7fffd2952e15 in VphalState::Allocate(VphalSettings const*) (pVpHalSettings=0x71745ac0, this=0x7fffd42e23a0) at ./media_driver/agnostic/common/vp/hal/vphal.cpp:146 #3 VphalState::Allocate(VphalSettings const*) (this=0x7fffd42e23a0, pVpHalSettings=0x71745ac0) at ./media_driver/agnostic/common/vp/hal/vphal.cpp:75 #4 0x7fffd2b56105 in DdiVp_InitVpHal(DDI_VP_CONTEXT*) (pVpCtx=0x7fffd42c1680) at ./media_driver/linux/common/vp/ddi/media_libva_vp.c:1800 #5 0x7fffd2b5a59f in DdiVp_InitCtx(VADriverContext*, DDI_VP_CONTEXT*) (pVaDrvCtx=, pVpCtx=0x7fffd42c1680) at ./media_driver/linux/common/vp/ddi/media_libva_vp.c:1660 #6 0x7fffd2b5a99e in DdiVp_CreateContext(VADriverContext*, unsigned int, int, int, int, unsigned int*, int, unsigned int*) (pVaDrvCtx=pVaDrvCtx@entry=0x7fffd4265240, vaConfigID=vaConfigID@entry=0x0, iWidth=iWidth@entry=0x0, iHeight=iHeight@entry=0x0, iFlag=iFlag@entry=0x0, vaSurfIDs=vaSurfIDs@entry=0x0, iNumSurfs=0x0, pVaCtxID=0x71745dec) at ./media_driver/linux/common/vp/ddi/media_libva_vp.c:3109 #7 0x7fffd2b21be2 in DdiMedia_PutImage(VADriverContext*, unsigned int, unsigned int, int, int, unsigned int, unsigned int, int, int, unsigned int, unsigned int) (ctx=0x7fffd4265240, surface=0x0, image=, src_x=0x0, src_y=0x0, src_width=0x40, src_height=0x40, dest_x=0x0, dest_y=0x0, dest_width=0x40, dest_height=0x40) at ./media_driver/linux/common/ddi/media_libva.cpp:5407 #8 0x7006a17c in vaPutImage () at /usr/lib/x86_64-linux-gnu/libva.so.2 #9 0x700efb2c in gst_vaapi_surface_put_image (surface=surface@entry=0x7fffd4252d60, image=image@entry=0x7fffd42742d0) at ../gst-libs/gst/vaapi/gstvaapisurface.c:761 #10 0x700ae476 in extract_allowed_surface_formats (img_formats=0x7fffd425c290, display=0x7fffec0046c0 [GstVaapiDisplay|vaapidisplayglx0]) at ../gst/vaapi/gstvaapipluginbase.c:1451 #11 ensure_allowed_raw_caps (plugin=0x7fffd424e910) at ../gst/vaapi/gstvaapipluginbase.c:1483 #12 gst_vaapi_plugin_base_get_allowed_sinkpad_raw_caps (plugin=plugin@entry=0x7fffd424e910) at ../gst/vaapi/gstvaapipluginbase.c:1515 #13 0x700b567e in ensure_allowed_sinkpad_caps (postproc=0x7fffd424e910) at ../gst/vaapi/gstvaapipostproc.c:1312 #14 gst_vaapipostproc_transform_caps_impl (direction=, trans=0x7fffd424e910 [GstBaseTransform|vaapipostproc0]) at ../gst/vaapi/gstvaapipostproc.c:1422 #15 gst_vaapipostproc_transform_caps (trans=0x7fffd424e910 [GstBaseTransform|vaapipostproc0], direction=, caps=0x7fffd4264ad0, filter=0x7fffd4264c50) at ../gst/vaapi/gstvaapipostproc.c:1445 #16 0x767154b3 in gst_base_transform_transform_caps (trans=trans@entry=0x7fffd424e910 [GstBaseTransform|vaapipostproc0], direction=GST_PAD_SRC, caps=caps@entry=0x7fffd4264ad0, filter=filter@entry=0x7fffd4264c50) at ../libs/gst/base/gstbasetransform.c:474 #17 0x76718e6d in gst_base_transform_query_caps (filter=0x7fffd4264c50, pad=0x7fffd41f9840 [GstPad|sink], trans=0x7fffd424e910 [GstBaseTransform|vaapipostproc0]) at ../libs/gst/base/gstbasetransform.c:698 #18 gst_base_transform_default_query (trans=0x7fffd424e910 [GstBaseTransform|vaapipostproc0], direction=, query=0x7fffd4264ca0) at ../libs/gst/base/gstbasetransform.c:1597 #19 0x77eace58 in gst_pad_query (pad=pad@entry=0x7fffd41f9840 [GstPad|sink], query=query@entry=0x7fffd4264ca0) at ../gst/gstpad.c:4144 #20 0x77ead5bb in gst_pad_peer_query (pad=pad@entry=0x7fffd41f95f0 [GstPad|src], query=query@entry=0x7fffd4264ca0) at ../gst/gstpad.c:4276 Debugging more in depth, I discovered that pKernelBin and uKernelSize (parameters of KernelDll_AllocateStates, frame #0) are not initialized by the caller. The caller (VphalRenderer::Initialize in media_driver/agnostic/common/vp/hal/vphal_renderer.cpp) should initialize the parameters from VphalRenderer members pcKernelBin and dwKernelBinSize, but these members are in turn never changed from their default zero value. Initialization should happen (on my CPU, at least) in VphalRendererG9::Ini
Bug#983100: libboost-python1.74-dev: multiarchify python dependency
Hi, Il 18/02/21 20:46, Helmut Grohne ha scritto: The affected packages cannot satisfy their cross Build-Depends, because their transitive dependency on the host architecture Python interpreter is not installable. The host architecture Python interpreter is required from libboost-python1.74-dev -> python3-dev -> python3. For building python extensions, one usually wants a build architecture python and the host architecture python development files. This is expressed as "python3-dev:any, libpython3-dev". For single-architecture installations, nothing changes. Please consider applying the attached patch. I'd say that's ok for me. Could you please NMU? Sorry for the delay, Giovanni. -- Giovanni Mascellani
Bug#978748: libboost-dev: Boost 1.75
Hi, Il 31/12/20 10:20, Olaf van der Spek ha scritto: Could Boost 1.75 be packaged? Eventually it will be (either 1.75 or a newer version), but I don't know when. 1.74 will be in bullseye, there is no point rushing a new transition now. Giovanni. -- Giovanni Mascellani
Bug#975446: libzeep: FTBFS against boost_1.74
Hi, On Mon, 23 Nov 2020 08:19:29 +0100 "Maarten L. Hekkelman" wrote: Hi Anton, Previous versions of libboost-tools-dev used to install a file called boost-build.jam in /usr/share/boost-build. Version 1.74 however no longer does this. Is this a permanent change? In the previous setup one could simply use bjam to build but with version 1.74 this no longer works. So before I change my build scripts, I'd like to know if the omission of /usr/share/boost-build/boost-build.jam is an error or was intended to be dropped. No, it's not intentional. As soon as I have time, I will check why it's not installed any more. Giovanni. -- Giovanni Mascellani
Bug#973302: libboost-python1.71.0,: _Py_NewReference undefined in library
Hi, thanks for the report! Il 28/10/20 15:57, Alastair McKinstry ha scritto: _Py_NewReference undefined in library breaks the package as used in python-escript. See bug #973225 I cannot reproduce that, because if I try to build python-escript with sbuild it fails much earlier: dh_update_autotools_config -O-v dh_autoreconf -O-v debian/rules override_dh_auto_build make[1]: Entering directory '/<>' # Build steps for py3 mkdir -p /<>/debian/stage3 scons -j12 cc_optim=' -O3 ' build_dir=/<>/debian/tmp3 verbose=on prefix=/<>/debian/stage3 options_file=debian/sid_options.py docs scons: Reading SConscript files ... 3.8.6 (default, Sep 25 2020, 09:36:53) [GCC 10.2.0] Building with the following additional flags from debian: [['cpp_flags', '-Wdate-time -D_FORTIFY_SOURCE=2'], ['cxx_extra', '-g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wno-uninitialized'], ['ld_extra', '-Wl,-z,relro -Wl,-z,now']] Using options in debian/sid_options.py. /bin/sh: 1: svnversion: not found Using svn revision information from file. Got revision = 6948 Checking whether the C++ compiler works... no Cannot run C++ compiler 'g++' (check config.log) make[1]: *** [debian/rules:66: override_dh_auto_build] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:39: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 This does not seem to be related to Boost. Do you know how to fix this? On the other hand, I see there is another package (caffe) which fails with the same error with Boost 1.71, but succeeds with Boost 1.74 that I recently uploaded and will eventually became the default version. Hopefully this is the same problem and will be fixed as well. Giovanni. -- Giovanni Mascellani
Bug#972324: [Pkg-javascript-devel] Bug#972324: Fails with "FROZEN_CACHE disallows building system libs: libc.a"
Hi, Il 16/10/20 10:55, Jonas Smedegaard ha scritto: > I am working on an update - just takes an awful lot of time for each > build - hopefully ready this afternoon :-) Lovely, although no rush on my side. I just noticed that my system was updating emscripten, and I thought about finally trying the tutorial. Giovanni. -- Giovanni Mascellani
Bug#972324: Fails with "FROZEN_CACHE disallows building system libs: libc.a"
Package: emscripten
Version: 2.0.7~dfsg-3
Severity: important
Hi, I am completely newbie with emscripten, but trying to follow the first
tutorial I found on the Internet[1] quickly led me to a dead end.
[1] https://emscripten.org/docs/getting_started/Tutorial.html
More precisely, I created a file hello.c with content:
---
#include
int main() {
printf("hello, world!\n");
return 0;
}
---
and then tries to compile it, obtaining this scary Python stack trace:
$ emcc hello.c
Traceback (most recent call last):
File "/usr/share/emscripten/emcc.py", line 3254, in
sys.exit(run(sys.argv))
File "/usr/share/emscripten/emcc.py", line 2116, in run
extra_files_to_link += system_libs.calculate([f for _, f in
sorted(temp_files)] + extra_files_to_link, link_as_cxx, forced=forced_stdlibs)
File "/usr/share/emscripten/tools/system_libs.py", line 1565, in calculate
add_library(system_libs_map['libc'])
File "/usr/share/emscripten/tools/system_libs.py", line 1508, in add_library
libs_to_link.append((lib.get_path(), need_whole_archive))
File "/usr/share/emscripten/tools/system_libs.py", line 335, in get_path
return shared.Cache.get(self.get_filename(), self.build)
File "/usr/share/emscripten/tools/cache.py", line 117, in get
raise Exception('FROZEN_CACHE disallows building system libs: %s' %
shortname)
Exception: FROZEN_CACHE disallows building system libs: libc.a
I can't find relevant information on the Internet. I tried removing
~/.emscripten*,
but that problem remains. I had tinkered with non-Debian-packaged versions of
emscripten in the past, but I don't think there should be leftovers interfering
with the Debian-package version now, so I believe there is a chance this is an
actual
bug in the Debian packaging.
I am setting severity "important" because this package seems completely
unusable for
me at the moment, but feel free to change it.
Thanks for maintaining emscripten!
All the best, Giovanni.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.7.0-3-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages emscripten depends on:
ii binaryen 97-1
ii clang 1:9.0-49.1
ii clang-11 1:11.0.0-2
ii cmake 3.18.2-1
ii lld-11 1:11.0.0-2
ii llvm 1:9.0-49.1
ii llvm-111:11.0.0-2
ii node-debbundle-acorn [node-acorn] 8.0.4+ds+~cs13.19.27-3
ii nodejs 12.19.0~dfsg-1
ii python33.8.6-1
Versions of packages emscripten recommends:
ii libjs-d3 3.5.17-2
ii python3-numpy 1:1.19.2-2+b1
Versions of packages emscripten suggests:
ii adb 1:8.1.0+r23-8
pn closure-compiler
ii wabt 1.0.19-1
-- no debconf information
Bug#972213: boost1.71: Please indicate some way which python versions you support
Hi, Il 16/10/20 02:53, Drew Parsons ha scritto: > Source: boost1.71 > Followup-For: Bug #972213 > X-Debbugs-Cc: debian-pyt...@lists.debian.org > > Would it make sense to use the Built-Using [1] header? > e.g. > Built-Using: python3.8 python3.9 > > dh_python3 knows if the module includes extensions > (*_python*.so.) and could inject the pythons into Built-Using. > > [...] > > [1] > https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using The precise web page you are linking hints that this use of Built-Using would be improper: "This field should be used only when there are license or DFSG requirements to retain the referenced source packages. It should not be added solely as a way to locate packages that need to be rebuilt against newer versions of their build dependencies". That said, I forgot to mention that the Python versions Boost is compiled against is also tracked in the package names provided by libboost-python1.71.0, which are currently libboost-python1.71.0-py38 and libboost-python1.71-py39. Is this better? More in general, there can be dozens of ways to advertise which Python versions are used to build Boost.Python, but it is not clear to me how this information should be consumed. Giovanni. -- Giovanni Mascellani
Bug#972213: boost1.71: Please indicate some way which python versions you support
Hi, Il 14/10/20 15:52, Alastair McKinstry ha scritto: > I maintain the package "ecflow" which uses libboost-python-dev. Now > with the transition to python3.9, ecflow will support (where > possible) multiple python versions. Currently it supports python3.8 > but not python3.9 ; this may be fixed in a binNMU or next version, > but I cannot tell whether my failure to build python3.9 support for > ecflow is due to missing py3.9 support in boost, or a bug in my > packaging. BTW, a binNMU was just requested to add Python 3.9 support. > Can some mechanism be added to enable tracability ? In general, Boost supports all the Python versions currently supported by the Python team, except that someone has to file a binNMU for them to appear once a new Python version is packaged. To check which Python versions are supported by a specific package version, it is enough to check the content of the libboost-python1.71.0 package (replace 1.71.0 with future versions where applicable): $ dpkg -L libboost-python1.71.0 | grep libboost_python /usr/lib/x86_64-linux-gnu/libboost_python38.so.1.71.0 /usr/lib/x86_64-linux-gnu/libboost_python39.so.1.71.0 (until yesterday you did not have the python39 variant) Does this answer your question? Giovanni. -- Giovanni Mascellani
Bug#969385: Bullseye
Hi, Il 11/10/20 19:56, Olaf van der Spek ha scritto: > Would it make sense to package 1.74 first to minimize the differences > when 1.75 becomes available? It might make sense. However, the part of writing the copyright file must be done before packaging anyway, because a package cannot be uploaded without proper copyright file. I am already working on that part. Giovanni. -- Giovanni Mascellani
Bug#969385: Bullseye
Hi, Il 10/10/20 07:28, Olaf van der Spek ha scritto: > Hi, > > What's the plan for Bullseye? > It'd be nice if Boost 1.75, expected December 9, could be included. I agree. On the other hand, transition freeze will be mid January or so, so the available time is not a lot. The two things requiring a lot of time when packaging a new Boost release are writing the debian/copyright file (for which I have some automated scripts, but that require some manual work anyway) and filing patches for the reverse dependencies that break. Fortunately I can start working on both things before Boost is actually released. I will try. Giovanni. -- Giovanni Mascellani
Bug#929520: [debian-mysql] Bug#929520: Problem starting mariadb
Hi, Il 21/09/20 22:22, Otto Kekäläinen ha scritto: > Is this still an issue? I don't even remember on which server this happened, so cannot check any more. I remember I kept the workaround and, so far, all my MySQL/MariaDB services seem to be working. Giovanni. -- Giovanni Mascellani signature.asc Description: OpenPGP digital signature
Bug#954905: Possibly duplicated
This seems to be the same as #963980 [1], where a workaround is provided. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963980 Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles
Bug#968673: libboost-all-dev: Can't use boost 1.71 with C++20 (gcc 10)
Hi, Il 19/08/20 16:41, BogDan Vatra ha scritto: > I tried to use boost with C++ 20 (gcc 10), and I got the following errors. > I also tried boost 1.73 (from conan.io) and everything compiles. Thanks for the report. Could you please provide a test program that fails compilation and its compilation command line? Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#967068: RM: freehep-graphicsio-pdf -- ROM; obsoleted by freehep-vectorgraphics
Package: ftp.debian.org Severity: normal Package freehep-vectorgraphics provide a more recent version of freehep-graphicsio-pdf, so the latter can be removed. Thanks!
Bug#967072: RM: freehep-graphicsio-tests -- ROM; obsoleted by freehep-vectorgraphics
Package: ftp.debian.org Severity: normal Package freehep-vectorgraphics provide a more recent version of freehep-graphicsio-tests, so the latter can be removed. Thanks!
Bug#967071: RM: freehep-graphicsio-swf -- ROM; obsoleted by freehep-vectorgraphics
Package: ftp.debian.org Severity: normal Package freehep-vectorgraphics provide a more recent version of freehep-graphicsio-swf, so the latter can be removed. Thanks!
Bug#967070: RM: freehep-graphicsio-svg -- ROM; obsoleted by freehep-vectorgraphics
Package: ftp.debian.org Severity: normal Package freehep-vectorgraphics provide a more recent version of freehep-graphicsio-svg, so the latter can be removed. Thanks!
Bug#967069: RM: freehep-graphicsio-ps -- ROM; obsoleted by freehep-vectorgraphics
Package: ftp.debian.org Severity: normal Package freehep-vectorgraphics provide a more recent version of freehep-graphicsio-ps, so the latter can be removed. Thanks!
Bug#967067: RM: freehep-graphicsio-java -- ROM; obsoleted by freehep-vectorgraphics
Package: ftp.debian.org Severity: normal Package freehep-vectorgraphics provide a more recent version of freehep-graphicsio-java, so the latter can be removed. Thanks!
Bug#967066: RM: freehep-graphicsio-emf -- ROM; obsoleted by freehep-vectorgraphics
Package: ftp.debian.org Severity: normal Package freehep-vectorgraphics provide a more recent version of freehep-graphicsio-emf, so the latter can be removed. Thanks!
Bug#967065: RM: freehep-graphicsio -- ROM; obsoleted by freehep-vectorgraphics
Package: ftp.debian.org Severity: normal Package freehep-vectorgraphics provide a more recent version of freehep-graphicsio, so the latter can be removed. Thanks!
Bug#967064: RM: freehep-graphics2d -- ROM; obsoleted by freehep-vectorgraphics
Package: ftp.debian.org Severity: normal Package freehep-vectorgraphics provide a more recent version of freehep- graphics2d, so the latter can be removed. Thanks!
Bug#964070: Upgrading freehep to latest upstream (needed by cdk and probably others)
Hi, Il 22/07/20 16:01, mer...@debian.org ha scritto: > I have uploaded freehep to unstable today, please go on with patching > geogebra. cdk, however, will have to wait, as it currently FTBFSes in > sid (#963435). Thanks, I just pushed geogebra. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles
Bug#964070: Upgrading freehep to latest upstream (needed by cdk and probably others)
Hi, Il 15/07/20 14:59, Andreas Tille ha scritto: > It has cleared new now and I commited some changes ready for a > source-only upload but since I did not followed the full discussion > I'm hesitating with dput. Feel free to upload what I commited > according to your preference. I have no problem with your changes, but since merkys should be back shortly we can leave it to him to do the upload. Once that is done, I will push geogebra with the updated patches. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles
Bug#905234: Interested in urbackup
I am also interested in this package, but having a look at the source code it seems that upstream is bundling and even modifying a lot of other code (I saw sqlite3, but it seems there is more), which makes it quite problematic: the bundled copies should be replaced with the Debian-provided versions, but if upstream is really assuming one specific version (or some specific patches) instead of using the general API, then breakages might happen. All in all, it seems rather hard to support whatever comes out. I believe the first step would be to identify all the bundled copies of third party softwares and determine whether they are modified or not, and whether the dependency on one specific version is required. I'd like to help, but unfortunately I don't have time right now. The best I can do is to wish good work to those who will have time. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#964070: Upgrading freehep to latest upstream (needed by cdk and probably others)
Hi,
Il 09/07/20 08:38, mer...@debian.org ha scritto:
> * As soon as new FreeHEP is accepted to experimental, I initiate the
> appropriate transition.
>
> * As GeoGebra will FTBFS with the new FreeHEP, I will ask to remove the
> former from testing to complete the transition.
There is no need for this step. I have already a patched version that
compiles with the new FreeHEP. The thing I ask you is to add this patch
to freehep-vectorgraphics:
> diff --git
> a/freehep-graphicsio-svg/src/main/java/org/freehep/graphicsio/svg/SVGGraphics2D.java
>
> b/freehep-graphicsio-svg/src/main/java/org/freehep/graphicsio/svg/SVGGraphics2D.java
> index 27fcb1d..84004cc 100644
> ---
> a/freehep-graphicsio-svg/src/main/java/org/freehep/graphicsio/svg/SVGGraphics2D.java
> +++
> b/freehep-graphicsio-svg/src/main/java/org/freehep/graphicsio/svg/SVGGraphics2D.java
> @@ -155,7 +155,7 @@ public class SVGGraphics2D extends
> AbstractVectorGraphicsIO {
> // The private writer used for this file.
> private OutputStream ros;
>
> -private PrintWriter os;
> +protected PrintWriter os;
>
> // table for gradients
> Hashtable gradients = new
> Hashtable();
Notice that this patch is harmless to other reverse dependencies of
freehep-vectorgraphics, because it makes a field available to
subclasses, but doesn't change the behavior for subclasses that don't
touch it.
Thanks, Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
Bug#964452: ITP: bgrep -- Tool to search substrings in binary files
Package: wnpp Severity: wishlist Owner: Giovanni Mascellani * Package name: bgrep Version : git5ca1302 Upstream Author : Felix Domke * URL : https://github.com/tmbinc/bgrep * License : BSD Programming Lang: C Description : Tool to search substrings in binary files Bgrep is a small utility similar to grep, but searching for binary substrings into binary files.
Bug#964070: Upgrading freehep to latest upstream (needed by cdk and probably others)
Hi, Il 02/07/20 01:34, Emmanuel Bourg ha scritto: > Sorry for the late reply I'm noticing this thread only now. Even if the > geogebra package is outdated it's still fairly popular. Would it be > possible to package an older version of FreeHEP so we can preserve geogebra? On second thought, it seems that it would not be too difficult to port GeoGebra to the new FreeHEP, so maybe we can consider this a little bit more carefully. FTP masters, please wait a little bit before executing this RM. The required changes are: * GeoGebra must be patched to avoid EMFPlus exporting. Easy to do, and I doubt anyone will cry over that missing feature. * FreeHEP should be patched so that the field "os" in SVGGraphics2D is protected instead of private, because a class in GeoGebra wants to access it to extend the superclass behavior. While this is not intended by FreeHEP authors, it does not appear to be a big problem either. GeoGebra uses that field "at its own responsibility", and clearly this change cannot cause malfunctions to any other reasonable software which just ignores that field. So it seems a totally legitimate patch for the FreeHEP version in Debian, given that it allows to have GeoGebra (even if an old version). * If the FreeHEP patch is considered completely unacceptable, I believe it is possible to modify GeoGebra so that it does not depend on it. For example, a drastic change would be to disable SVG exportation altogether, like it would be done for EMFPlus. However, SVG is a much more relevant exportation format than EMFPlus, so I would try to avoid this. Looking briefly at the code, the only thing the FreeHEP patch is required for by GeoGebra is to insert grouping information in the exported SVG. Probably the same graphic result can be obtained without the groups. All in all, I believe that it would be sensible to have the FreeHEP patch. Even if grouping is not required for the graphical result, it is a nice feature when one wants to further edit the exported image. And the patch in FreeHEP is from my point of view really minor. What do you think about this? Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles
Bug#964070: RM: geogebra -- ROM; obsolete, cannot update due to license, blocks updating of other packages
Package: ftp.debian.org Severity: normal Please remove the geogebra package. Since years I cannot update it due to new releases being under a non-free license. Now it is blocking the updating of reverse dependencies, so it's finally a good moment to get rid of it. It's unfortunate, because it's still a great software, but upstream wanted to make it non-free. Thanks, Gio.
Bug#933506: Fixed in Boost 1.71
FYI, this seems to be fixed in Boost 1.71, so I am not reassigning this bug. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#962320: facter crashes with "free(): invalid pointer"
Il 13/06/20 11:05, Giovanni Mascellani ha scritto: > No problems in line of principle, but I am not sure I understand what > would this solve: the conflict between two different versions of Boost > arises when the same executable links against both (through different > dependencies). There is no problem in having both versions installed at > the same time. > > So, given that we have to make sure that bullseye packages link only > against 1.71 (or whatever it will be, but just one version), what is to > be gained by having the Break: indication? Ping? Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#960379: FTBFS again
Bitcoin is FTBFSing again because of a missing dependency on bsdextrautils (from which hexdump is used). Therefore I am uploading another NMU fixing this. I am not delaying it, since I had no objections on the first NMU and I believe this one to be uncontroversial. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#949196: libzypp: diff for NMU version 17.7.0-1.1
Hi, Il 20/06/20 19:01, Mike Gabriel ha scritto: > Thanks for patching libzypp. Your NMU is ok, I will include your > .debdiff on its VCS. In fact, I am considering orphaning libzypp and > zypper in Debian. Do you have interest in taking over? Ugh, I just realized I stupidly embedded the amd64 architecture in my patch, leading to obvious FTBFS on the other archs. It is ok for you if I directly NMU libzypp replacing x86_64-linux-gnu with $(DEB_HOST_MULTIARCH)? Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#949196: libzypp: diff for NMU version 17.7.0-1.1
Hi, Il 20/06/20 19:01, Mike Gabriel ha scritto: > Thanks for patching libzypp. Your NMU is ok, I will include your > .debdiff on its VCS. In fact, I am considering orphaning libzypp and > zypper in Debian. Do you have interest in taking over? No, I have no interest. Actually, I barely know what they do: I am just doing some RC sniping. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#949196: libzypp: diff for NMU version 17.7.0-1.1
Control: tags 949196 + patch
Control: tags 949196 + pending
Dear maintainer,
I've prepared an NMU for libzypp (versioned as 17.7.0-1.1) and
uploaded it to DELAYED/02. Please feel free to tell me if I
should delay it longer.
Regards.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
diff -Nru libzypp-17.7.0/debian/changelog libzypp-17.7.0/debian/changelog
--- libzypp-17.7.0/debian/changelog 2018-09-17 13:31:02.0 +0200
+++ libzypp-17.7.0/debian/changelog 2020-06-20 16:35:50.0 +0200
@@ -1,3 +1,12 @@
+libzypp (17.7.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Work around broken libsolv detection (closes: #949196).
+ * Fix build with Boost 1.71.
+ * Treat libxml as a C++ library.
+
+ -- Giovanni Mascellani Sat, 20 Jun 2020 16:35:50 +0200
+
libzypp (17.7.0-1) unstable; urgency=medium
* New upstream release.
diff -Nru libzypp-17.7.0/debian/patches/40e772a952ed8b0525430bca6a226e054826c662.patch libzypp-17.7.0/debian/patches/40e772a952ed8b0525430bca6a226e054826c662.patch
--- libzypp-17.7.0/debian/patches/40e772a952ed8b0525430bca6a226e054826c662.patch 1970-01-01 01:00:00.0 +0100
+++ libzypp-17.7.0/debian/patches/40e772a952ed8b0525430bca6a226e054826c662.patch 2020-06-20 16:35:50.0 +0200
@@ -0,0 +1,69 @@
+From 40e772a952ed8b0525430bca6a226e054826c662 Mon Sep 17 00:00:00 2001
+From: Adam Majer
+Date: Wed, 28 Nov 2018 16:56:15 +0100
+Subject: [PATCH] Need to explitily cast of Tribool to boolean
+
+Only explicit casts are allowed as of Boost 1.69
+---
+ zypp/RepoInfo.cc | 8
+ zypp/RepoManager.cc| 2 +-
+ zypp/repo/Applydeltarpm.cc | 2 +-
+ 3 files changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/zypp/RepoInfo.cc b/zypp/RepoInfo.cc
+index 0a3575bc8..db230c727 100644
+--- a/zypp/RepoInfo.cc
b/zypp/RepoInfo.cc
+@@ -387,11 +387,11 @@ namespace zypp
+
+
+ bool RepoInfo::repoGpgCheck() const
+- { return gpgCheck() || _pimpl->cfgRepoGpgCheck(); }
++ { return gpgCheck() || bool(_pimpl->cfgRepoGpgCheck()); }
+
+ bool RepoInfo::repoGpgCheckIsMandatory() const
+ {
+-bool ret = ( gpgCheck() && indeterminate(_pimpl->cfgRepoGpgCheck()) ) || _pimpl->cfgRepoGpgCheck();
++bool ret = ( gpgCheck() && indeterminate(_pimpl->cfgRepoGpgCheck()) ) || bool(_pimpl->cfgRepoGpgCheck());
+ if ( ret && _pimpl->internalUnsignedConfirmed() ) // relax if unsigned repo was confirmed in the past
+ ret = false;
+ return ret;
+@@ -402,10 +402,10 @@ namespace zypp
+
+
+ bool RepoInfo::pkgGpgCheck() const
+- { return _pimpl->cfgPkgGpgCheck() || ( gpgCheck() && !bool(validRepoSignature())/*enforced*/ ) ; }
++ { return bool(_pimpl->cfgPkgGpgCheck()) || ( gpgCheck() && !bool(validRepoSignature())/*enforced*/ ) ; }
+
+ bool RepoInfo::pkgGpgCheckIsMandatory() const
+- { return _pimpl->cfgPkgGpgCheck() || ( gpgCheck() && indeterminate(_pimpl->cfgPkgGpgCheck()) && !bool(validRepoSignature())/*enforced*/ ); }
++ { return bool(_pimpl->cfgPkgGpgCheck()) || ( gpgCheck() && indeterminate(_pimpl->cfgPkgGpgCheck()) && !bool(validRepoSignature())/*enforced*/ ); }
+
+ void RepoInfo::setPkgGpgCheck( TriBool value_r )
+ { _pimpl->rawPkgGpgCheck( value_r ); }
+diff --git a/zypp/RepoManager.cc b/zypp/RepoManager.cc
+index dbcf7a1b5..ad53013fe 100644
+--- a/zypp/RepoManager.cc
b/zypp/RepoManager.cc
+@@ -2243,7 +2243,7 @@ namespace zypp
+
+ // Make sure the service repo is created with the appropriate enablement
+ if ( ! indeterminate(toBeEnabled) )
+- it->setEnabled( toBeEnabled );
++ it->setEnabled( ( bool ) toBeEnabled );
+
+ DBG << "Service adds repo " << it->alias() << " " << (it->enabled()?"enabled":"disabled") << endl;
+ addRepository( *it );
+diff --git a/zypp/repo/Applydeltarpm.cc b/zypp/repo/Applydeltarpm.cc
+index 7b382be9b..0a1b8ad7e 100644
+--- a/zypp/repo/Applydeltarpm.cc
b/zypp/repo/Applydeltarpm.cc
+@@ -82,7 +82,7 @@ namespace zypp
+ else
+ WAR << "No executable " << prog << endl;
+ }
+- return _last;
++ return ( bool ) _last;
+ }
+
+ /**
diff -Nru libzypp-17.7.0/debian/patches/867c6b3190dafcd07f0ac5d8eef39268cc925141.patch libzypp-17.7.0/debian/patches/867c6b3190dafcd07f0ac5d8eef39268cc925141.patch
--- libzypp-17.7.0/debian/patches/867c6b3190dafcd07f0ac5d8eef39268cc925141.patch 1970-01-01 01:00:00.0 +0100
+++ libzypp-17.7.0/debian/patches/867c6b3190dafcd07f0ac5d8eef39268cc925141.patch 2020-06-20 16:35:50.0 +0200
@@ -0,0 +1,24 @@
+From 867c6b3190dafcd07f0ac5d8eef39268cc925141 Mon Sep 17 00:00:00 2001
+From: Adam Majer
+Date: Tue, 27 Nov 2018 15:45:43 +0100
+Subject: [PATCH] Boost.Tribool requir
Bug#922579: FTBFS against opencv 4.0.1 (exp)
Control: block 962950 by -1 On Tue, 23 Apr 2019 14:13:22 + (GMT) Chiara Marmo wrote: > Hi, > > sorry, I'm a bit confused about this bug. > > This is a problem with opencv4 in experimental distribution, right? > Not with power pc architecture... No, the same thing definitely happens on amd64 as well. I tried adding a "-I/usr/include/opencv4" to the compiler command line to see if the same code worked with OpenCV 4, but apparently it does not. It is probably necessary to manually port the code to the new version. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#936483: Possible fix
Il 19/06/20 16:51, Giovanni Mascellani ha scritto: > Basically I am replacing PyInt_Check with PyLong_Check, under the > assumption that "long" is the new name of "int" in Python 3. This > assumptions is corroborated by PyGame having this line in > /usr/include/python3.8m/pygame/pgcompat.h: > > #define PyInt_Check(op) PyLong_Check(op) > > That said, I wouldn't mind some competent Python developer to review the > patch. Comparing with [1], it seems my patch is ok. https://github.com/enki-community/enki/commit/db813cdb7b669231b6670ccc9ee8f562aed29807 Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#960379: bitcoin: diff for NMU version 0.18.1~dfsg-1.1
Control: tags 960379 + patch
Control: tags 960379 + pending
Dear maintainer,
I've prepared an NMU for bitcoin (versioned as 0.18.1~dfsg-1.1) and
uploaded it to DELAYED/02. Please feel free to tell me if I
should delay it longer.
Regards.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
diff -Nru bitcoin-0.18.1~dfsg/debian/changelog bitcoin-0.18.1~dfsg/debian/changelog
--- bitcoin-0.18.1~dfsg/debian/changelog 2019-08-19 11:50:52.0 +0200
+++ bitcoin-0.18.1~dfsg/debian/changelog 2020-06-19 18:20:38.0 +0200
@@ -1,3 +1,10 @@
+bitcoin (0.18.1~dfsg-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS with new Univalue interface (closes: #960379).
+
+ -- Giovanni Mascellani Fri, 19 Jun 2020 18:20:38 +0200
+
bitcoin (0.18.1~dfsg-1) unstable; urgency=medium
[ upstream ]
diff -Nru bitcoin-0.18.1~dfsg/debian/patches/0006-Fix-FTBFS-with-new-Univalue-Interface.patch bitcoin-0.18.1~dfsg/debian/patches/0006-Fix-FTBFS-with-new-Univalue-Interface.patch
--- bitcoin-0.18.1~dfsg/debian/patches/0006-Fix-FTBFS-with-new-Univalue-Interface.patch 1970-01-01 01:00:00.0 +0100
+++ bitcoin-0.18.1~dfsg/debian/patches/0006-Fix-FTBFS-with-new-Univalue-Interface.patch 2020-06-19 18:20:38.0 +0200
@@ -0,0 +1,21 @@
+From: Giovanni Mascellani
+Date: Wed, 17 Jun 2020 19:05:43 +0200
+Subject: Fix FTBFS with new Univalue Interface.
+
+---
+ src/rpc/blockchain.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/rpc/blockchain.cpp b/src/rpc/blockchain.cpp
+index bd35163..52fcd3c 100644
+--- a/src/rpc/blockchain.cpp
b/src/rpc/blockchain.cpp
+@@ -2198,7 +2198,7 @@ UniValue scantxoutset(const JSONRPCRequest& request)
+ // no scan in progress
+ return NullUniValue;
+ }
+-result.pushKV("progress", g_scan_progress);
++result.pushKV("progress", int(g_scan_progress));
+ return result;
+ } else if (request.params[0].get_str() == "abort") {
+ CoinsViewScanReserver reserver;
diff -Nru bitcoin-0.18.1~dfsg/debian/patches/series bitcoin-0.18.1~dfsg/debian/patches/series
--- bitcoin-0.18.1~dfsg/debian/patches/series 2019-08-19 11:50:52.0 +0200
+++ bitcoin-0.18.1~dfsg/debian/patches/series 2020-06-19 18:20:38.0 +0200
@@ -3,3 +3,4 @@
1003_man_proper_header.patch
2001_avoid_embedded_libs.patch
2002_avoid_network_tests.patch
+0006-Fix-FTBFS-with-new-Univalue-Interface.patch
Bug#936483: Possible fix
Hi, the attached patch seems to fix the FTBFS with Python 3. I am not completely sure it is the right fix, though, meaning that the package compiles with my patch, but I am not sure the logic is correct. Basically I am replacing PyInt_Check with PyLong_Check, under the assumption that "long" is the new name of "int" in Python 3. This assumptions is corroborated by PyGame having this line in /usr/include/python3.8m/pygame/pgcompat.h: #define PyInt_Check(op) PyLong_Check(op) That said, I wouldn't mind some competent Python developer to review the patch. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles diff --git a/python/enki.cpp b/python/enki.cpp index b18e6ea..216ae41 100644 --- a/python/enki.cpp +++ b/python/enki.cpp @@ -105,11 +105,11 @@ struct Vector_from_python PyObject* item0(PyTuple_GetItem(objPtr, 0)); assert (item0); - if (!(PyFloat_Check(item0) || PyInt_Check(item0))) + if (!(PyFloat_Check(item0) || PyLong_Check(item0))) return 0; PyObject* item1(PyTuple_GetItem(objPtr, 1)); assert (item1); - if (!(PyFloat_Check(item1) || PyInt_Check(item1))) + if (!(PyFloat_Check(item1) || PyLong_Check(item1))) return 0; } else @@ -120,11 +120,11 @@ struct Vector_from_python PyObject* item0(PyList_GetItem(objPtr, 0)); assert (item0); - if (!(PyFloat_Check(item0) || PyInt_Check(item0))) + if (!(PyFloat_Check(item0) || PyLong_Check(item0))) return 0; PyObject* item1(PyList_GetItem(objPtr, 1)); assert (item1); - if (!(PyFloat_Check(item1) || PyInt_Check(item1))) + if (!(PyFloat_Check(item1) || PyLong_Check(item1))) return 0; } signature.asc Description: OpenPGP digital signature
Bug#960379: Patch
Hi, the attached patch seems to work. I don't have time right now to
send in an NMU.
Thanks, Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
From 247b1d32c5e5ddf0a1f629b85147209718255044 Mon Sep 17 00:00:00 2001
From: Giovanni Mascellani
Date: Wed, 17 Jun 2020 19:06:20 +0200
Subject: [PATCH] Fix FTBFS with Boost 1.71.
---
.../0006-Fix-FTBFS-with-Boost-1.71.patch | 21 +++
debian/patches/series | 1 +
2 files changed, 22 insertions(+)
create mode 100644 debian/patches/0006-Fix-FTBFS-with-Boost-1.71.patch
diff --git a/debian/patches/0006-Fix-FTBFS-with-Boost-1.71.patch b/debian/patches/0006-Fix-FTBFS-with-Boost-1.71.patch
new file mode 100644
index 0..b102e1227
--- /dev/null
+++ b/debian/patches/0006-Fix-FTBFS-with-Boost-1.71.patch
@@ -0,0 +1,21 @@
+From: Giovanni Mascellani
+Date: Wed, 17 Jun 2020 19:05:43 +0200
+Subject: Fix FTBFS with Boost 1.71.
+
+---
+ src/rpc/blockchain.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/rpc/blockchain.cpp b/src/rpc/blockchain.cpp
+index bd35163..52fcd3c 100644
+--- a/src/rpc/blockchain.cpp
b/src/rpc/blockchain.cpp
+@@ -2198,7 +2198,7 @@ UniValue scantxoutset(const JSONRPCRequest& request)
+ // no scan in progress
+ return NullUniValue;
+ }
+-result.pushKV("progress", g_scan_progress);
++result.pushKV("progress", int(g_scan_progress));
+ return result;
+ } else if (request.params[0].get_str() == "abort") {
+ CoinsViewScanReserver reserver;
diff --git a/debian/patches/series b/debian/patches/series
index 31faa743e..4257bd031 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@
1003_man_proper_header.patch
2001_avoid_embedded_libs.patch
2002_avoid_network_tests.patch
+0006-Fix-FTBFS-with-Boost-1.71.patch
--
2.27.0
signature.asc
Description: OpenPGP digital signature
Bug#936227: boost1.67: Python2 removal in sid/bullseye
Hi, Il 17/06/20 06:10, Sandro Tosi ha scritto: > great! I see the transition is almost completed - i'm wondering when > it's going to be the time we can remove src:boost1.67 from unstable: > it is now the only remaining rdep of cython, which in turn it's the > only remaining rdep of src:python-numpy which i'd like to remove soon I see xnox just filed a RM bug asking for a force removal: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962950 That seems a little aggressive, but I have no idea what's the FTP team's idea on that. On the social side, it seems there is disagreement with the kig maintainer (pino) on how to handle the transition and the fact that kig does not yet support Python 3: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962348 Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#962320: facter crashes with "free(): invalid pointer"
Hi, Il 09/06/20 17:06, Adrian Bunk ha scritto: > For avoiding similar problems for people upgrading from buster, > it would be good if for both 1.71 and whatever version of Boost > will be released in Buster the library packages will add a Breaks: > on the corresponding libboost-*1.67.0 package. No problems in line of principle, but I am not sure I understand what would this solve: the conflict between two different versions of Boost arises when the same executable links against both (through different dependencies). There is no problem in having both versions installed at the same time. So, given that we have to make sure that bullseye packages link only against 1.71 (or whatever it will be, but just one version), what is to be gained by having the Break: indication? Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#962444: [renderdoc] qrenderdoc: error while loading shared libraries: libSPIRV-Tools.so: cannot open shared object file: No such file or directory
Package: renderdoc Version: 1.7+dfsg-2 Severity: important Dear maintainer, qrenderdoc immediately crashes with this error: qrenderdoc: error while loading shared libraries: libSPIRV-Tools.so: cannot open shared object file: No such file or directory Since > $ dlocate libSPIR > spirv-tools: /usr/lib/x86_64-linux-gnu/libSPIRV-Tools-link.a > spirv-tools: /usr/lib/x86_64-linux-gnu/libSPIRV-Tools-opt.a > spirv-tools: /usr/lib/x86_64-linux-gnu/libSPIRV-Tools-reduce.a > spirv-tools: /usr/lib/x86_64-linux-gnu/libSPIRV-Tools-shared.so > spirv-tools: /usr/lib/x86_64-linux-gnu/libSPIRV-Tools.a it might be that the library changed name to libSPIRV-Tools-shared.so. Maybe https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956510 can help, but I am not sure I understand the details. Thanks, Giovanni. --- System information. --- Architecture: Kernel: Linux 5.6.0-2-amd64 Debian Release: bullseye/sid 500 xenial updates.signal.org 500 unstable-debug debug.mirrors.debian.org 500 unstabledeb.debian.org 500 testing deb.debian.org 500 stable repo.skype.com 500 stable dl.google.com 1 experimentaldeb.debian.org --- Package information. --- Depends(Version) | Installed -+- libc6 (>= 2.29) | libgcc-s1 (>= 3.0) | libgl1 | libpython3.8 (>= 3.8.2) | libqt5core5a (>= 5.12.2) | libqt5gui5 (>= 5.6.0~beta) | OR libqt5gui5-gles (>= 5.6.0~beta) | libqt5network5 (>= 5.0.2) | libqt5svg5 (>= 5.6.0~beta) | libqt5widgets5 (>= 5.11.0~rc1) | libqt5x11extras5 (>= 5.6.0) | libstb0 (>= 0.0~git20180212.15.e6afb9c) | libstdc++6 (>= 9) | libx11-6 | libx11-xcb1 (>= 2:1.6.9) | libxcb-keysyms1 (>= 0.4.0) | libxcb1 | python3 | spirv-tools | Package's Recommends field is empty. Package's Suggests field is empty. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#945746: Please remove wotsap
Hi, I believe it is better to remove wotsap. Nobody is caring about it upstream, it is still Python 2 and data sources are mostly unmaintained. Should the scenario change, I'd be happy to repackage it. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#961995: transition: boost-defaults
Il 02/06/20 09:37, Sebastian Ramacher ha scritto: > boost1.71 got built against the new icu everywhere, so feel free to go > ahead with the upload to unstable. Done, thanks! Gio. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#936227: boost1.67: Python2 removal in sid/bullseye
Il 01/06/20 20:11, Giovanni Mascellani ha scritto: > I just requested a transition for Boost. Forgot to mention: the bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961995 Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#936227: boost1.67: Python2 removal in sid/bullseye
Hi, Il 01/06/20 09:04, Sandro Tosi ha scritto: > where are we with the python2 removal for boost1.67? i see the bag was > marked as closed in 1.71 but 1.67 is still the default in unstable, > and there's no transition bug open on release.d.o I just requested a transition for Boost. My understanding is that release team should give the go quite soon[1]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960193#99 Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#961995: transition: boost-defaults
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I am requesting a transition slot to upload boost-defaults and promote Boost 1.71 to our default Boost version. Known FTBFS have already been filed with usertags: https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=team%2Bboost%40tracker.debian.org&tag=boost1.71 Many of them already have patches in the BTS. Thanks for your help and all the best, Giovanni. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-2-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#960193: transition: icu
Hi, Il 23/05/20 15:43, Sebastian Ramacher ha scritto: > The tracker is now available at > https://release.debian.org/transitions/html/boost1.71.html. If there are > no other major issues, I think we can start this after the r-api-4.0 > (#955211) transition finished. That's ok for me. Most of the bugs already have patches, and hopefully the missing ones should not be too difficult. Unfortunately my time for Debian is still rather limited because of other commitments, but I will do my best to not leave things lingering around for too long. Should I file a transition request bug already? Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#920727: Status?
Hi, Il 13/05/20 11:09, Olaf van der Spek ha scritto: > How's progress on Boost packaging? Version 1.71 has been in unstable for quite some time now. It is not the default yet, but bugs are filed against packages that fail to build with it[1], so it could be possible to start a transition at some point. [1] https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=team%2Bboost%40tracker.debian.org&tag=boost1.71 Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#960193: transition: icu
Hi, Il 12/05/20 10:05, Sebastian Ramacher ha scritto: > I can help with filing those bugs so we can get that transition ready. Thanks. According to my notes, the packages that fail to build with 1.71 (and do not fail with 1.67) that still require bug filing are these: cupt dds ecflow facter flightgear gatb-core leatherman libkolabxml libpwiz meson mongodb ncbi-blast+ progressivemauve simgear svgpp thrift zypper (although the bug is in libzypp, I believe) This list was created some months ago, so things might have shifted a little bit by now. It should be more or less representative, though. The build logs I got are here: https://people.debian.org/~gio/boost_migration/ Attached, in case it helps, is the mail template I am using for this run. If you want to use another one no problem, but please include the usertag data. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles Subject: FTBFS with Boost 1.71 To: sub...@bugs.debian.org Package: Version: Severity: wishlist Tags: patch User: team+bo...@tracker.debian.org Usertags: boost1.71 Dear Maintainer, your package fails to build with boost1.71. You can find a build log attached. If you want to attempt the build yourself, an updated version of boost-defaults which brings in boost1.71 dependencies can be found adding this line to your sources.list file: deb https://people.debian.org/~gio/reprepro gio main This bug has severity whishlist for the moment, but it will raised to RC as soon as version 1.71 of Boost is promoted to default. More specifically, your package fails building because The attached patch should fix the bug. Thanks and all the best, Giovanni. signature.asc Description: OpenPGP digital signature
Bug#960193: transition: icu
Hi, Il 11/05/20 14:26, Adrian Bunk ha scritto: > Is there a good reason why the boost 1.67 -> 1.71 transition has already > happened in Ubuntu but not yet in Debian? The reason I know about is that I am the only person working on it at the moment, and I don't have much time myself. I am filing bugs and patches for packages not building any more[1] and will request a transition once things seem to be ready. [1] https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=team%2Bboost%40tracker.debian.org&tag=boost1.71 Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#959480: FTBFS with Boost 1.71
Package: frogatto
Version: 1.3.1+dfsg-4
Severity: wishlist
Tags: patch
User: team+bo...@tracker.debian.org
Usertags: boost1.71
Dear Maintainer,
your package fails to build with boost1.71. You can find a build log
attached. If you want to attempt the build yourself, an updated version
of boost-defaults which brings in boost1.71 dependencies can be found
adding this line to your sources.list file:
deb https://people.debian.org/~gio/reprepro gio main
This bug has severity whishlist for the moment, but it will raised to RC
as soon as version 1.71 of Boost is promoted to default.
More specifically, your package fails building because it uses a retired
API from Boost.Asio. The attached patch should fix the bug.
Thanks and all the best, Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
Index: frogatto-1.3.1+dfsg/src/http_server.cpp
===
--- frogatto-1.3.1+dfsg.orig/src/http_server.cpp
+++ frogatto-1.3.1+dfsg/src/http_server.cpp
@@ -31,7 +31,7 @@ web_server::web_server(boost::asio::io_s
void web_server::start_accept()
{
- socket_ptr socket(new tcp::socket(acceptor_.get_io_service()));
+ socket_ptr socket(new tcp::socket(acceptor_.get_executor()));
acceptor_.async_accept(*socket, boost::bind(&web_server::handle_accept, this, socket, boost::asio::placeholders::error));
}
frogatto.log.gz
Description: application/gzip
signature.asc
Description: OpenPGP digital signature
Bug#959479: FTBFS with Boost 1.71
Package: dogecoin Version: 1.10.0-7.1 Severity: wishlist User: team+bo...@tracker.debian.org Usertags: boost1.71 Dear Maintainer, your package fails to build with boost1.71. You can find a build log attached. If you want to attempt the build yourself, an updated version of boost-defaults which brings in boost1.71 dependencies can be found adding this line to your sources.list file: deb https://people.debian.org/~gio/reprepro gio main This bug has severity whishlist for the moment, but it will raised to RC as soon as version 1.71 of Boost is promoted to default. More specifically, your package fails building because it uses some retired API from Boost.Asio. It appears, though, that upstream dogecoin has since long stopped using Asio, switching to libevent2 as IO library since commit 40b556d3742a1f65d67e2d4c760d0b13fe8be5b7 (dated Fri Jan 23 07:53:17 2015 +0100). I believe it would be more advisable to package an updated version of dogecoin rather than patch it for Boost 1.71. Thanks and all the best, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles dogecoin.log.gz Description: application/gzip signature.asc Description: OpenPGP digital signature
Bug#959466: RFP: mindustry -- A sandbox tower-defense game
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org Package name: mindustry Version: 104.6 Upstream Author: Anton "Anuken" Kramskoi URL: https://github.com/Anuken/Mindustry License: GPL-3.0 Description: A sandbox tower-defense game Mindustry is a hybrid tower-defense sandbox factory game. Create elaborate supply chains of conveyor belts to feed ammo into your turrets, produce materials to use for building, and defend your structures from waves of enemies. Features include a map editor, 24 built-in maps, cross-platform multiplayer and large-scale PvP unit battles. The game is written in Java and built over libGDX. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#959439: FTBFS with Boost 1.71
Package: supercollider Version: 1:3.10.0+repack-1 Severity: wishlist User: team+bo...@tracker.debian.org Usertags: boost1.71 Dear Maintainer, your package fails to build with boost1.71. You can find a build log attached. If you want to attempt the build yourself, an updated version of boost-defaults which brings in boost1.71 dependencies can be found adding this line to your sources.list file: deb https://people.debian.org/~gio/reprepro gio main This bug has severity whishlist for the moment, but it will raised to RC as soon as version 1.71 of Boost is promoted to default. More specifically, your package fails building because it uses some retired API from Boost.Asio and other small things. Patches in this upstream pull request[1] should address all the problems. [1] https://github.com/supercollider/supercollider/pull/4612 Thanks and all the best, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles supercollider.log.gz Description: application/gzip signature.asc Description: OpenPGP digital signature
Bug#959437: FTBFS with Boost 1.71
Package: sslsniff
Version: 0.8-8
Severity: wishlist
Tags: patch
User: team+bo...@tracker.debian.org
Usertags: boost1.71
Dear Maintainer,
your package fails to build with boost1.71. You can find a build log
attached. If you want to attempt the build yourself, an updated version
of boost-defaults which brings in boost1.71 dependencies can be found
adding this line to your sources.list file:
deb https://people.debian.org/~gio/reprepro gio main
This bug has severity whishlist for the moment, but it will raised to RC
as soon as version 1.71 of Boost is promoted to default.
More specifically, your package fails building because it uses some
retired API from Boost.Asio. The attached patch should fix the bug.
Thanks and all the best, Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
From a53724afc0bb86f3551f981e386576eb060d8c78 Mon Sep 17 00:00:00 2001
From: Giovanni Mascellani
Date: Sat, 2 May 2020 11:25:41 +0200
Subject: [PATCH] Fix FTBFS with Boost 1.71.
---
debian/changelog | 7 +
.../patches/Fix-FTBFS-with-Boost-1.71.patch | 181 ++
debian/patches/series | 1 +
3 files changed, 189 insertions(+)
create mode 100644 debian/patches/Fix-FTBFS-with-Boost-1.71.patch
diff --git a/debian/changelog b/debian/changelog
index 123d278..196c6b4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+sslsniff (0.8-8.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS with Boost 1.71.
+
+ -- Giovanni Mascellani Sat, 02 May 2020 11:25:51 +0200
+
sslsniff (0.8-8) unstable; urgency=medium
* Fix build with wl,asneeded (Closes: #849695)
diff --git a/debian/patches/Fix-FTBFS-with-Boost-1.71.patch b/debian/patches/Fix-FTBFS-with-Boost-1.71.patch
new file mode 100644
index 000..80cba0d
--- /dev/null
+++ b/debian/patches/Fix-FTBFS-with-Boost-1.71.patch
@@ -0,0 +1,181 @@
+From: Giovanni Mascellani
+Date: Sat, 2 May 2020 11:24:55 +0200
+Subject: Fix FTBFS with Boost 1.71.
+
+---
+ RawBridge.hpp | 21 +
+ SSLConnectionManager.cpp | 6 +++---
+ http/HttpBridge.hpp| 25 +
+ http/HttpConnectionManager.cpp | 4 ++--
+ 4 files changed, 51 insertions(+), 5 deletions(-)
+
+diff --git a/RawBridge.hpp b/RawBridge.hpp
+index 9206faa..7a1255e 100644
+--- a/RawBridge.hpp
b/RawBridge.hpp
+@@ -36,6 +36,16 @@ private:
+ ip::tcp::socket serverSocket;
+ ip::tcp::endpoint destination;
+
++#if BOOST_VERSION >= 107000
++ const boost::asio::executor &executor;
++
++ RawBridge(boost::shared_ptr clientSocket,
++ ip::tcp::endpoint& destination,
++ const boost::asio::executor & executor) :
++clientSocket(clientSocket), serverSocket(executor),
++executor(executor), destination(destination), closed(0)
++ {}
++#else
+ boost::asio::io_service &io_service;
+
+ RawBridge(boost::shared_ptr clientSocket,
+@@ -44,6 +54,7 @@ private:
+ clientSocket(clientSocket), serverSocket(io_service),
+ io_service(io_service), destination(destination), closed(0)
+ {}
++#endif
+
+ void handleConnect(Bridge::ptr bridge, const boost::system::error_code &error) {
+ if (!error) Bridge::shuttle(&(*clientSocket), &serverSocket);
+@@ -55,6 +66,15 @@ protected:
+
+ public:
+
++#if BOOST_VERSION >= 107000
++ static ptr create(boost::shared_ptr clientSocket,
++ ip::tcp::endpoint& destination,
++ const boost::asio::executor & executor)
++
++ {
++return ptr(new RawBridge(clientSocket, destination, executor));
++ }
++#else
+ static ptr create(boost::shared_ptr clientSocket,
+ ip::tcp::endpoint& destination,
+ boost::asio::io_service & io_service)
+@@ -62,6 +82,7 @@ public:
+ {
+ return ptr(new RawBridge(clientSocket, destination, io_service));
+ }
++#endif
+
+ virtual ip::tcp::socket& getClientSocket() {
+ return *clientSocket;
+diff --git a/SSLConnectionManager.cpp b/SSLConnectionManager.cpp
+index 9beed10..6087f65 100644
+--- a/SSLConnectionManager.cpp
b/SSLConnectionManager.cpp
+@@ -44,7 +44,7 @@ SSLConnectionManager::SSLConnectionManager(io_service &io_service,
+ }
+
+ void SSLConnectionManager::acceptIncomingConnection() {
+- boost::shared_ptr socket(new ip::tcp::socket(acceptor.get_io_service()));
++ boost::shared_ptr socket(new ip::tcp::socket(acceptor.get_executor()));
+
+ acceptor.async_accept(*socket, boost::bind(&SSLConnectionManager::handleClientConnection,
+ this, socket, placeholders::error));
+@@ -76,7 +76,7 @@ void SSLConnectionManager::shuttleConnection(boost::shared_ptr
+ ip::tcp::endpoint &destination)
+
+ {
+- Bridge::ptr bridge = RawBridge::create(clientSocket, destination, acceptor.get_io_service());
++ Bridge::ptr bridge = RawBridge::create(clientSocket, destination, acceptor.get_executor());
+ bridge->shuttle();
+ }
Bug#959417: FTBFS with Boost 1.71
Package: vcmi
Version: 0.99+dfsg+git20190113.f06c8a87-1
Severity: wishlist
Tags: patch
User: team+bo...@tracker.debian.org
Usertags: boost1.71
Dear Maintainer,
your package fails to build with boost1.71. You can find a build log
attached. If you want to attempt the build yourself, an updated version
of boost-defaults which brings in boost1.71 dependencies can be found
adding this line to your sources.list file:
deb https://people.debian.org/~gio/reprepro gio main
This bug has severity whishlist for the moment, but it will raised to RC
as soon as version 1.71 of Boost is promoted to default.
More specifically, your package fails building because it uses some
retired API from Boost.Asio. The attached patch (cherry picked from
upstream) should fix the bug.
Thanks and all the best, Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
From ecbb568f09b6025179200a6c7b492356d0493bb2 Mon Sep 17 00:00:00 2001
From: Giovanni Mascellani
Date: Sat, 2 May 2020 09:29:28 +0200
Subject: [PATCH] Fix FTBFS with Boost 1.71.
---
...d0f7b42fb535748ec311ba877a6e6216567b.patch | 62 +++
debian/patches/series | 1 +
2 files changed, 63 insertions(+)
create mode 100644 debian/patches/ac81d0f7b42fb535748ec311ba877a6e6216567b.patch
diff --git a/debian/patches/ac81d0f7b42fb535748ec311ba877a6e6216567b.patch b/debian/patches/ac81d0f7b42fb535748ec311ba877a6e6216567b.patch
new file mode 100644
index 000..6e024d6
--- /dev/null
+++ b/debian/patches/ac81d0f7b42fb535748ec311ba877a6e6216567b.patch
@@ -0,0 +1,62 @@
+From ac81d0f7b42fb535748ec311ba877a6e6216567b Mon Sep 17 00:00:00 2001
+From: krkos
+Date: Tue, 21 Jan 2020 09:55:28 +0100
+Subject: [PATCH] Fix build with Boost versioni >= 1.70 (#615)
+
+---
+ lib/serializer/Connection.h | 7 +++
+ server/CVCMIServer.cpp | 8 ++--
+ 2 files changed, 13 insertions(+), 2 deletions(-)
+
+diff --git a/lib/serializer/Connection.h b/lib/serializer/Connection.h
+index e6bfcfd86..6ba68d269 100644
+--- a/lib/serializer/Connection.h
b/lib/serializer/Connection.h
+@@ -14,6 +14,11 @@
+
+ struct CPack;
+
++#if BOOST_VERSION >= 107000 // Boost version >= 1.70
++#include
++typedef boost::asio::basic_stream_socket < boost::asio::ip::tcp > TSocket;
++typedef boost::asio::basic_socket_acceptor < boost::asio::ip::tcp > TAcceptor;
++#else
+ namespace boost
+ {
+ namespace asio
+@@ -43,6 +48,8 @@ namespace boost
+
+ typedef boost::asio::basic_stream_socket < boost::asio::ip::tcp , boost::asio::stream_socket_service > TSocket;
+ typedef boost::asio::basic_socket_acceptor > TAcceptor;
++#endif
++
+
+ /// Main class for network communication
+ /// Allows establishing connection and bidirectional read-write
+diff --git a/server/CVCMIServer.cpp b/server/CVCMIServer.cpp
+index 730ddba96..dfcfefe4e 100644
+--- a/server/CVCMIServer.cpp
b/server/CVCMIServer.cpp
+@@ -214,8 +214,8 @@ void CVCMIServer::threadAnnounceLobby()
+
+ if(acceptor)
+ {
+-acceptor->get_io_service().reset();
+-acceptor->get_io_service().poll();
++io->reset();
++io->poll();
+ }
+ }
+
+@@ -272,7 +272,11 @@ void CVCMIServer::startAsyncAccept()
+ assert(!upcomingConnection);
+ assert(acceptor);
+
++#if BOOST_VERSION >= 107000 // Boost version >= 1.70
++ upcomingConnection = std::make_shared(acceptor->get_executor());
++#else
+ upcomingConnection = std::make_shared(acceptor->get_io_service());
++#endif
+ acceptor->async_accept(*upcomingConnection, std::bind(&CVCMIServer::connectionAccepted, this, _1));
+ }
+
diff --git a/debian/patches/series b/debian/patches/series
index 4ab4eca..747bb14 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
disable-privacy-breach
minizip_maxu32
+ac81d0f7b42fb535748ec311ba877a6e6216567b.patch
--
2.26.2
vcmi.log.gz
Description: application/gzip
signature.asc
Description: OpenPGP digital signature
Bug#875584: Can jhdf be uploaded?
Apparently jhdf has a patch committed in Salsa which would fix a FTBFS (which currently prevents hdfview from installing in sid). Is there are reason for not uploading it? Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#958156: FTBFS with Boost 1.71
Package: slic3r
Version: 1.3.0+dfsg1-3
Severity: wishlist
Tags: patch
User: team+bo...@tracker.debian.org
Usertags: boost1.71
Dear Maintainer,
your package fails to build with boost1.71. You can find a build log
attached. If you want to attempt the build yourself, an updated version
of boost-defaults which brings in boost1.71 dependencies can be found
adding this line to your sources.list file:
deb https://people.debian.org/~gio/reprepro gio main
This bug has severity whishlist for the moment, but it will raised to RC
as soon as version 1.71 of Boost is promoted to default.
More specifically, your package fails building because of a missing
Boost header. The attached patch should fix the bug.
Thanks and all the best, Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
From b97e351586a8aa3d73912e1a05d66e46368f39f0 Mon Sep 17 00:00:00 2001
From: Giovanni Mascellani
Date: Sun, 19 Apr 2020 08:31:27 +0200
Subject: [PATCH] Fix FTBFS with Boost 1.71.
---
debian/changelog | 7 +++
.../0006-Fix-FTBFS-with-Boost-1.71.patch | 20 +++
debian/patches/series | 1 +
3 files changed, 28 insertions(+)
create mode 100644 debian/patches/0006-Fix-FTBFS-with-Boost-1.71.patch
diff --git a/debian/changelog b/debian/changelog
index 4a0d3574..c242e76c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+slic3r (1.3.0+dfsg1-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS with Boost 1.71.
+
+ -- Giovanni Mascellani Sun, 19 Apr 2020 08:31:34 +0200
+
slic3r (1.3.0+dfsg1-3) unstable; urgency=medium
* [b61cf9b] Import patch to fix admesh compilation bug (Closes: #907346)
diff --git a/debian/patches/0006-Fix-FTBFS-with-Boost-1.71.patch b/debian/patches/0006-Fix-FTBFS-with-Boost-1.71.patch
new file mode 100644
index ..191f76fa
--- /dev/null
+++ b/debian/patches/0006-Fix-FTBFS-with-Boost-1.71.patch
@@ -0,0 +1,20 @@
+From: Giovanni Mascellani
+Date: Sun, 19 Apr 2020 08:31:04 +0200
+Subject: Fix FTBFS with Boost 1.71.
+
+---
+ xs/src/libslic3r/GCodeSender.hpp | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/xs/src/libslic3r/GCodeSender.hpp b/xs/src/libslic3r/GCodeSender.hpp
+index cc0b298..0f39f5a 100644
+--- a/xs/src/libslic3r/GCodeSender.hpp
b/xs/src/libslic3r/GCodeSender.hpp
+@@ -9,6 +9,7 @@
+ #include
+ #include
+ #include
++#include
+
+ namespace Slic3r {
+
diff --git a/debian/patches/series b/debian/patches/series
index 30db8c78..18e45788 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@ Downgrade-Encode-Locale-requirement.patch
Add-usr-lib-slic3r-to-lib-search-path.patch
Use-system-expat.h.patch
Drop-error-admesh-works-correctly-on-little-endian-machin.patch
+0006-Fix-FTBFS-with-Boost-1.71.patch
--
2.26.1
slic3r.log.gz
Description: application/gzip
signature.asc
Description: OpenPGP digital signature
Bug#953873: Patch is ok, then there is another problem
Hi, the patch suggested by upstream fixes the compilation, but then the Debian-specific installation fails: > -- Installing: > /<>/debian/tmp/usr/share/ompl/plannerarena/www/plannerarena.css > -- Installing: > /<>/debian/tmp/usr/share/ompl/plannerarena/www/plannerarena.js > -- Installing: > /<>/debian/tmp/usr/share/ompl/plannerarena/global.R > -- Installing: > /<>/debian/tmp/usr/share/ompl/plannerarena/plannerarena > -- Installing: /<>/debian/tmp/usr/share/ompl/plannerarena/ui.R > -- Installing: > /<>/debian/tmp/usr/share/ompl/plannerarena/server.R > -- Installing: /<>/debian/tmp/usr/bin/plannerarena > -- Installing: > /<>/debian/tmp/usr/share/man/man1/ompl_benchmark_statistics.1 > -- Installing: /<>/debian/tmp/usr/share/man/man1/plannerarena.1 > make[2]: Leaving directory '/<>/build' > make[1]: Leaving directory '/<>' >dh_install -O--builddirectory=build -O--buildsystem=cmake > Failed to copy 'usr/bin/ompl_benchmark_statistics.py': No such file or > directory at /usr/share/dh-exec/dh-exec-install-rename line 51, <> line 2. > dh_install: error: debian/ompl-demos.install (executable config) returned > exit code 127 > make: *** [debian/rules:39: binary] Error 25 > dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned > exit status 2 I don't know what the problem is here. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#955581: FTBFS with Boost 1.71
Package: xmms2 Version: 0.8+dfsg-18.2 Severity: wishlist User: team+bo...@tracker.debian.org Usertags: boost1.71 Dear Maintainer, your package fails to build with boost1.71. If you want to attempt the build yourself, an updated version of boost-defaults which brings in boost1.71 dependencies can be found adding this line to your sources.list file: deb https://people.debian.org/~gio/reprepro gio main This bug has severity whishlist for the moment, but it will raised to RC as soon as version 1.71 of Boost is promoted to default. More specifically, your package fails building because it depends on package libboost-signals-dev, which is going to be removed. In order to fix the bug, it is enough to remove such dependency. Thanks and all the best, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#955579: FTBFS with Boost 1.71
Package: sinfo Version: 0.0.48-2 Severity: wishlist Tags: patch User: team+bo...@tracker.debian.org Usertags: boost1.71 Dear Maintainer, your package fails to build with boost1.71. If you want to attempt the build yourself, an updated version of boost-defaults which brings in boost1.71 dependencies can be found adding this line to your sources.list file: deb https://people.debian.org/~gio/reprepro gio main This bug has severity whishlist for the moment, but it will raised to RC as soon as version 1.71 of Boost is promoted to default. More specifically, your package fails building because it depends on package libboost-signals-dev, which is going to disappear. The attached patch should fix the bug. Thanks and all the best, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles From 8c2c9f8e5ad42007996dc8d600ba51e0e26dfc16 Mon Sep 17 00:00:00 2001 From: Giovanni Mascellani Date: Thu, 2 Apr 2020 21:00:25 +0200 Subject: [PATCH] Fix FTBFS with Boost 1.71. --- debian/changelog | 7 +++ debian/control | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index a79d5c9..a77f3c5 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +sinfo (0.0.48-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Remove dependency on libboost-signals-dev, which was removed. + + -- Giovanni Mascellani Thu, 02 Apr 2020 21:00:07 +0200 + sinfo (0.0.48-2) unstable; urgency=medium * [38b4d44] pt_BR debconf template translation (Closes: #844667) diff --git a/debian/control b/debian/control index 539f799..ca7c097 100644 --- a/debian/control +++ b/debian/control @@ -3,7 +3,7 @@ Section: net Priority: optional Maintainer: Jürgen Rinas Uploaders: Gaudenz Steinlin -Build-Depends: debhelper (>= 9.20160709~), autotools-dev, libncurses5-dev, libboost-dev, libboost-signals-dev, libboost-regex-dev, libboost-system-dev, po-debconf, groff +Build-Depends: debhelper (>= 9.20160709~), autotools-dev, libncurses5-dev, libboost-dev, libboost-regex-dev, libboost-system-dev, po-debconf, groff Standards-Version: 4.2.1 Vcs-Git: https://salsa.debian.org/debian/sinfo.git Vcs-Browser: https://salsa.debian.org/debian/sinfo -- 2.26.0 signature.asc Description: OpenPGP digital signature
Bug#954711: FTBFS with Boost 1.71
Package: sight Version: 19.0.0-5 Severity: wishlist Tags: patch User: team+bo...@tracker.debian.org Usertags: boost1.71 Dear Maintainer, your package fails to build with boost1.71. You can find a build log attached. If you want to attempt the build yourself, an updated version of boost-defaults which brings in boost1.71 dependencies can be found adding this line to your sources.list file: deb https://people.debian.org/~gio/reprepro gio main This bug has severity whishlist for the moment, but it will raised to RC as soon as version 1.71 of Boost is promoted to default. More specifically, your package fails building because CMake scripts use capitalized Boost library names, while they should be lowercase. The attached patch should fix the bug. Thanks and all the best, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles From e2c25111e5f0df526cf46ba9039b49b50eba3fa5 Mon Sep 17 00:00:00 2001 From: Giovanni Mascellani Date: Sun, 22 Mar 2020 14:35:17 +0100 Subject: [PATCH] Fix FTBFS with Boost 1.71. --- debian/changelog | 7 .../0007-Fix-FTBFS-with-Boost-1.71.patch | 34 +++ debian/patches/series | 1 + 3 files changed, 42 insertions(+) create mode 100644 debian/patches/0007-Fix-FTBFS-with-Boost-1.71.patch diff --git a/debian/changelog b/debian/changelog index 60579b5a..39ca5f34 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +sight (19.0.0-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix Boost library names in CMake scripts. + + -- Giovanni Mascellani Sun, 22 Mar 2020 14:35:31 +0100 + sight (19.0.0-5) unstable; urgency=medium * Team upload. diff --git a/debian/patches/0007-Fix-FTBFS-with-Boost-1.71.patch b/debian/patches/0007-Fix-FTBFS-with-Boost-1.71.patch new file mode 100644 index ..c94167ff --- /dev/null +++ b/debian/patches/0007-Fix-FTBFS-with-Boost-1.71.patch @@ -0,0 +1,34 @@ +From: Giovanni Mascellani +Date: Sun, 22 Mar 2020 14:34:26 +0100 +Subject: Fix FTBFS with Boost 1.71. + +Apparently CMake expects library names to be lowercase. +--- + Bundles/ui/guiQml/CMakeLists.txt | 2 +- + Bundles/ui/guiQt/CMakeLists.txt | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +diff --git a/Bundles/ui/guiQml/CMakeLists.txt b/Bundles/ui/guiQml/CMakeLists.txt +index 42c008e..7f9c228 100644 +--- a/Bundles/ui/guiQml/CMakeLists.txt b/Bundles/ui/guiQml/CMakeLists.txt +@@ -1,6 +1,6 @@ + fwLoadProperties() + +-find_package(Boost QUIET COMPONENTS Regex REQUIRED) ++find_package(Boost QUIET COMPONENTS regex REQUIRED) + find_package(Qt5 QUIET COMPONENTS Core Gui Quick Qml QuickControls2 REQUIRED) + + +diff --git a/Bundles/ui/guiQt/CMakeLists.txt b/Bundles/ui/guiQt/CMakeLists.txt +index 3aff5d1..ff52b89 100644 +--- a/Bundles/ui/guiQt/CMakeLists.txt b/Bundles/ui/guiQt/CMakeLists.txt +@@ -1,6 +1,6 @@ + fwLoadProperties() + +-find_package(Boost QUIET COMPONENTS Regex REQUIRED) ++find_package(Boost QUIET COMPONENTS regex REQUIRED) + find_package(Qt5 QUIET COMPONENTS Core Gui Widgets REQUIRED) + + diff --git a/debian/patches/series b/debian/patches/series index bcd8be4b..98f20a36 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -4,3 +4,4 @@ fix_version_getter.patch fix_launcher_library_path.patch fix_dcmtk_scp_cfg.patch revert_qVTK_widget.patch +0007-Fix-FTBFS-with-Boost-1.71.patch -- 2.26.0.rc2 sight.log.gz Description: application/gzip signature.asc Description: OpenPGP digital signature
Bug#954653: FTBFS with Boost 1.71
Package: ros-ros-comm
Version: 1.14.3+ds1-11
Severity: wishlist
Tags: patch
User: team+bo...@tracker.debian.org
Usertags: boost1.71
Dear Maintainer,
your package fails to build with boost1.71. You can find a build log
attached. If you want to attempt the build yourself, an updated version
of boost-defaults which brings in boost1.71 dependencies can be found
adding this line to your sources.list file:
deb https://people.debian.org/~gio/reprepro gio main
This bug has severity whishlist for the moment, but it will raised to RC
as soon as version 1.71 of Boost is promoted to default.
More specifically, your package fails building because it depends on
package libboost-signals-dev, which does not exist any more.
The attached patch should fix the bug.
Thanks and all the best, Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
From 073810177ac6dec06f9d2967e705e4016e7cca7f Mon Sep 17 00:00:00 2001
From: Giovanni Mascellani
Date: Sun, 22 Mar 2020 11:23:16 +0100
Subject: [PATCH] Fix FTBFS with Boost 1.71.
---
debian/changelog | 7 +++
debian/control| 6 +--
...09-Do-not-use-Boost.Signals-any-more.patch | 50 +++
debian/patches/series | 1 +
4 files changed, 61 insertions(+), 3 deletions(-)
create mode 100644 debian/patches/0009-Do-not-use-Boost.Signals-any-more.patch
diff --git a/debian/changelog b/debian/changelog
index e2f9e67..6da802f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ros-ros-comm (1.14.3+ds1-11.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Do not depend on libboost-signals-dev, which does not exist any more.
+
+ -- Giovanni Mascellani Sun, 22 Mar 2020 11:23:01 +0100
+
ros-ros-comm (1.14.3+ds1-11) unstable; urgency=medium
* Add https://github.com/ros/ros_comm/pull/1741 (Fix CVE-2019-13445)
diff --git a/debian/control b/debian/control
index 7ffe5be..e31ee90 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Priority: optional
Build-Depends: debhelper-compat (= 12), catkin (>= 0.7.14-5), dh-exec, libroscpp-core-dev,
python3-rosunit, libconsole-bridge-dev, libboost-date-time-dev,
libboost-filesystem-dev, libboost-program-options-dev, libboost-regex-dev,
- libboost-system-dev, libboost-thread-dev, libboost-signals-dev, liblz4-dev,
+ libboost-system-dev, libboost-thread-dev, liblz4-dev,
ros-message-generation, libbz2-dev, libros-rosgraph-msgs-dev, libstd-msgs-dev,
dh-python, python3-dev, liblog4cxx-dev, libstd-srvs-dev, libboost-chrono-dev, libb64-dev, librosconsole-dev, pluginlib-dev, libgpgme-dev, python3-empy
Standards-Version: 4.4.1
@@ -26,7 +26,7 @@ Package: libroscpp-dev
Section: libdevel
Architecture: any
Multi-Arch: same
-Depends: libroscpp2d (= ${binary:Version}), ${misc:Depends}, python3, libboost-signals-dev, libboost-filesystem-dev, libboost-system-dev, librosconsole-dev, libros-rosgraph-msgs-dev, libxmlrpcpp-dev, libroscpp-msg-dev
+Depends: libroscpp2d (= ${binary:Version}), ${misc:Depends}, python3, libboost-filesystem-dev, libboost-system-dev, librosconsole-dev, libros-rosgraph-msgs-dev, libxmlrpcpp-dev, libroscpp-msg-dev
Description: Robot OS development files for libroscpp
This package is part of Robot OS (ROS). roscpp is a C++
implementation of ROS. It provides a client library that enables C++
@@ -467,7 +467,7 @@ Package: libmessage-filters-dev
Section: libdevel
Architecture: any
Multi-Arch: same
-Depends: libmessage-filters1d (= ${binary:Version}), ${misc:Depends}, libroscpp-dev, libboost-signals-dev, libboost-thread-dev
+Depends: libmessage-filters1d (= ${binary:Version}), ${misc:Depends}, libroscpp-dev, libboost-thread-dev
Description: Development files for Robot OS message-filters
This package is part of Robot OS (ROS). It contains the development
files for libmessage-filters, which implements a set of message
diff --git a/debian/patches/0009-Do-not-use-Boost.Signals-any-more.patch b/debian/patches/0009-Do-not-use-Boost.Signals-any-more.patch
new file mode 100644
index 000..663abc4
--- /dev/null
+++ b/debian/patches/0009-Do-not-use-Boost.Signals-any-more.patch
@@ -0,0 +1,50 @@
+From: Giovanni Mascellani
+Date: Sun, 22 Mar 2020 11:25:41 +0100
+Subject: Do not use Boost.Signals any more.
+
+Boost.Signals was replaced by Boost.Signals2, which is header-only.
+---
+ clients/roscpp/CMakeLists.txt| 2 +-
+ test/test_roscpp/CMakeLists.txt | 2 +-
+ utilities/message_filters/CMakeLists.txt | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/clients/roscpp/CMakeLists.txt b/clients/roscpp/CMakeLists.txt
+index 4fb5dc3..faaa4aa 100644
+--- a/clients/roscpp/CMakeLists.txt
b/clients/roscpp/CMakeLists.txt
+@@ -22,7 +22,7 @@ list(GET roscpp_VERSION_LIST 2 roscpp_VERSION_PATCH)
+
+ configure_file(${CMAKE_CURRENT_SOURCE_DIR}/include/ros/common.h.in ${CATKIN_DEVEL_PREFIX}/${CATKIN_GLOBAL_INCLUDE_DESTINAT
Bug#954649: FTBFS with Boost 1.71
Package: rlvm Version: 0.14-4 Severity: wishlist Tags: patch User: team+bo...@tracker.debian.org Usertags: boost1.71 Dear Maintainer, your package fails to build with boost1.71. You can find a build log attached. If you want to attempt the build yourself, an updated version of boost-defaults which brings in boost1.71 dependencies can be found adding this line to your sources.list file: deb https://people.debian.org/~gio/reprepro gio main This bug has severity whishlist for the moment, but it will raised to RC as soon as version 1.71 of Boost is promoted to default. More specifically, your package fails building because it depends on libboost-signals-dev, which does not exist anymore. Also, there is a missing header in a file. The attached patch should fix the bug. Thanks and all the best, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles diff --git a/debian/changelog b/debian/changelog index b0344d6..2483f74 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +rlvm (0.14-4.1) unstable; urgency=medium + + * Non-maintainer upload. + * Remove dependency on package libboost-signals-dev, which does not exist +any more. + * Fix compilation adding a missing header. + + -- Giovanni Mascellani Sun, 22 Mar 2020 10:23:35 +0100 + rlvm (0.14-4) unstable; urgency=low * Add 004_port_to_python3.patch: porting to python3 (Closes: #947579) diff --git a/debian/control b/debian/control index 8f4d11f..3e63d64 100644 --- a/debian/control +++ b/debian/control @@ -11,7 +11,6 @@ Build-Depends: debhelper (>= 10), libboost-program-options-dev, libboost-python-dev, libboost-serialization-dev, - libboost-signals-dev, libboost-thread-dev, libfreetype6-dev, libgl1-mesa-dev, diff --git a/debian/patches/fix-missing-header.patch b/debian/patches/fix-missing-header.patch new file mode 100644 index 000..66a822c --- /dev/null +++ b/debian/patches/fix-missing-header.patch @@ -0,0 +1,17 @@ +From: Giovanni Mascellani +Date: Sun, 22 Mar 2020 10:23:31 +0100 +Subject: Fix missing header + + +--- + +--- rlvm-0.14.orig/src/systems/base/gan_graphics_object_data.cc rlvm-0.14/src/systems/base/gan_graphics_object_data.cc +@@ -38,6 +38,7 @@ + #include + #include + #include ++#include + + #include "libreallive/defs.h" + #include "machine/serialization.h" diff --git a/debian/patches/series b/debian/patches/series index 90ae9f1..fb420e4 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -2,3 +2,4 @@ 002_include-iostream.patch 003_use_pkg-config_for_freetype2.patch 004_port_to_python3.patch +fix-missing-header.patch diff --git a/src/systems/base/gan_graphics_object_data.cc b/src/systems/base/gan_graphics_object_data.cc index 4178d11..96c1bcd 100644 --- a/src/systems/base/gan_graphics_object_data.cc +++ b/src/systems/base/gan_graphics_object_data.cc @@ -38,6 +38,7 @@ #include #include #include +#include #include "libreallive/defs.h" #include "machine/serialization.h" rlvm.log.gz Description: application/gzip signature.asc Description: OpenPGP digital signature
Bug#954648: FTBFS with Boost 1.71
Package: rivet
Version: 1.8.3-3
Severity: wishlist
User: team+bo...@tracker.debian.org
Usertags: boost1.71
Forwarded: https://github.com/boostorg/assign/issues/33
Dear Maintainer,
your package fails to build with boost1.71. You can find a build log
attached. If you want to attempt the build yourself, an updated version
of boost-defaults which brings in boost1.71 dependencies can be found
adding this line to your sources.list file:
deb https://people.debian.org/~gio/reprepro gio main
This bug has severity whishlist for the moment, but it will raised to RC
as soon as version 1.71 of Boost is promoted to default.
More specifically, your package fails building because it seems that a
certain usage of operator+= seems to be not supported any more by
Boost.Assign. I asked upstream about whether it should be considered
legitimate or not:
https://github.com/boostorg/assign/issues/33
From the build log:
> In file included from /usr/include/boost/assign/std/vector.hpp:18,
> from /usr/include/boost/assign/std.hpp:18,
> from /usr/include/boost/assign.hpp:19,
> from ../../include/Rivet/RivetBoost.hh:6,
> from ../../include/Rivet/Math/MathUtils.hh:6,
> from ../../include/Rivet/Rivet.hh:42,
> from RivetPaths.cc:1:
> /usr/include/boost/assign/list_inserter.hpp: In instantiation of 'void
> boost::assign_detail::call_push_back::operator()(T&&) [with T =
> std::vector >; C =
> std::vector >]':
> /usr/include/boost/assign/list_inserter.hpp:414:13: required from 'void
> boost::assign::list_inserter Argument>::insert(boost::assign::list_inserter Argument>::single_arg_type, T&&) [with T =
> std::vector >; Function =
> boost::assign_detail::call_push_back
> > >; Argument = std::__cxx11::basic_string]'
> /usr/include/boost/assign/list_inserter.hpp:406:13: required from
> 'boost::assign::list_inserter&
> boost::assign::list_inserter::operator()(Ts&& ...) [with
> Ts = {std::vector,
> std::allocator >, std::allocator std::char_traits, std::allocator > > >}; Function =
> boost::assign_detail::call_push_back
> > >; Argument = std::__cxx11::basic_string]'
> /usr/include/boost/assign/std/vector.hpp:42:30: required from
> 'boost::assign::list_inserter _Alloc> >, V> boost::assign::operator+=(std::vector<_Tp, _Alloc>&, V2&&)
> [with V = std::__cxx11::basic_string; A =
> std::allocator >; V2 =
> std::vector >]'
> RivetPaths.cc:57:28: required from here
> /usr/include/boost/assign/list_inserter.hpp:91:13: error: no matching
> function for call to 'std::vector
> >::push_back(std::vector >)'
>91 | c_.push_back(boost::forward(r));
> | ^~
> In file included from /usr/include/c++/9/vector:67,
> from ../../include/Rivet/RivetSTL.hh:11,
> from ../../include/Rivet/Rivet.hh:8,
> from RivetPaths.cc:1:
> /usr/include/c++/9/bits/stl_vector.h:1184:7: note: candidate: 'void
> std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp =
> std::__cxx11::basic_string; _Alloc =
> std::allocator >; std::vector<_Tp,
> _Alloc>::value_type = std::__cxx11::basic_string]'
> 1184 | push_back(const value_type& __x)
> | ^
> /usr/include/c++/9/bits/stl_vector.h:1184:35: note: no known conversion for
> argument 1 from 'std::vector >' to 'const
> value_type&' {aka 'const std::__cxx11::basic_string&'}
> 1184 | push_back(const value_type& __x)
> | ~~^~~
> /usr/include/c++/9/bits/stl_vector.h:1200:7: note: candidate: 'void
> std::vector<_Tp, _Alloc>::push_back(std::vector<_Tp, _Alloc>::value_type&&)
> [with _Tp = std::__cxx11::basic_string; _Alloc =
> std::allocator >; std::vector<_Tp,
> _Alloc>::value_type = std::__cxx11::basic_string]'
> 1200 | push_back(value_type&& __x)
> | ^
> /usr/include/c++/9/bits/stl_vector.h:1200:30: note: no known conversion for
> argument 1 from 'std::vector >' to
> 'std::vector >::value_type&&' {aka
> 'std::__cxx11::basic_string&&'}
> 1200 | push_back(value_type&& __x)
> | ~^~~
Thanks and all the best, Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
rivet.log.gz
Description: application/gzip
signature.asc
Description: OpenPGP digital signature
Bug#954351: FTBFS with Boost 1.71
Package: rdkit Version: 201909.1-2 Severity: wishlist User: team+bo...@tracker.debian.org Usertags: boost1.71 Dear Maintainer, your package fails to build with boost1.71. You can find a build log attached. If you want to attempt the build yourself, an updated version of boost-defaults which brings in boost1.71 dependencies can be found adding this line to your sources.list file: deb https://people.debian.org/~gio/reprepro gio main This bug has severity whishlist for the moment, but it will raised to RC as soon as version 1.71 of Boost is promoted to default. More specifically, your package fails building because some problem in the CMake scripts. I don't really understand the problem, because the log clearly states that Boost libraries are found, but then for some reason they cannot be used. I am not really expert of CMake, so I am not sure of how to debug this. From the log: > -- Found Boost: > /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found > suitable version "1.71.0", minimum required is "1.56.0") found components: > serialization > == Using strict rotor definition > -- Found Boost: > /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found > suitable version "1.71.0", minimum required is "1.56.0") found components: > system iostreams > -- maeparser include dir set as '/usr/include' > -- maeparser libraries set as '/usr/lib/x86_64-linux-gnu/libmaeparser.so' > -- Found maeparser: /usr/include > -- coordgen include dir set as /usr/include > -- coordgen libraries set as '/usr/lib/x86_64-linux-gnu/libcoordgen.so' > -- Found coordgen: /usr/include > Downloading > https://github.com/rareylab/RingDecomposerLib/archive/v1.1.3_rdkit.tar.gz... > == Updating Filters.cpp from pains file > == Done updating pains files > -- Configuring done > CMake Error at Code/cmake/Modules/RDKitUtils.cmake:153 (add_executable): > Target "testCoordGen" links to target "Boost::system" but the target was > not found. Perhaps a find_package() call is missing for an IMPORTED > target, or an ALIAS target is missing? > Call Stack (most recent call first): > External/CoordGen/CMakeLists.txt:110 (rdkit_test) Thanks and all the best, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles rdkit.log.gz Description: application/gzip signature.asc Description: OpenPGP digital signature
Bug#953884: FTBFS with Boost 1.71
Package: orthanc
Version: 1.5.8+dfsg-3
Severity: wishlist
Tags: patch
User: team+bo...@tracker.debian.org
Usertags: boost1.71
Dear Maintainer,
your package fails to build with boost1.71. You can find a build log
attached. If you want to attempt the build yourself, an updated version
of boost-defaults which brings in boost1.71 dependencies can be found
adding this line to your sources.list file:
deb https://people.debian.org/~gio/reprepro gio main
This bug has severity whishlist for the moment, but it will raised to RC
as soon as version 1.71 of Boost is promoted to default.
More specifically, your package fails building because of a little
problem in the CMake script that probes Boost components. The attached
patch should fix the bug.
The same bug also happens in other orthanc-* packages, which appear to
embed an orthanc source copy inside a tarball. Please, fix those as well
because they are failing in the same way. If you want, I can file bugs.
(as a side note: is the code embedding really necessary? In general I
believe it should be avoided, but that's a different issue)
Thanks and all the best, Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
From 0a55a43c53500ac8cf466d2c6dd8e801679cb7e7 Mon Sep 17 00:00:00 2001
From: Giovanni Mascellani
Date: Sat, 14 Mar 2020 14:43:34 +0100
Subject: [PATCH] Fix FTBFS with Boost 1.71.
---
debian/changelog | 7 ++
.../0001-Fix-FTBFS-with-Boost-1.71.patch | 24 +++
debian/patches/series | 1 +
3 files changed, 32 insertions(+)
create mode 100644 debian/patches/0001-Fix-FTBFS-with-Boost-1.71.patch
diff --git a/debian/changelog b/debian/changelog
index 5a425c8..abd335c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+orthanc (1.5.8+dfsg-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Patch CMake scripts to prevent FTBFS with Boost 1.71.
+
+ -- Giovanni Mascellani Sat, 14 Mar 2020 14:42:52 +0100
+
orthanc (1.5.8+dfsg-3) unstable; urgency=medium
[ Alexandre Mestiashvili ]
diff --git a/debian/patches/0001-Fix-FTBFS-with-Boost-1.71.patch b/debian/patches/0001-Fix-FTBFS-with-Boost-1.71.patch
new file mode 100644
index 000..d154248
--- /dev/null
+++ b/debian/patches/0001-Fix-FTBFS-with-Boost-1.71.patch
@@ -0,0 +1,24 @@
+From: Giovanni Mascellani
+Date: Sat, 14 Mar 2020 14:41:50 +0100
+Subject: Fix FTBFS with Boost 1.71.
+
+I am not a specialist of CMake, but I believe that quoting the
+component list makes scripts unable to interpret it as a list, similar
+to what would happen with bash.
+---
+ Resources/CMake/BoostConfiguration.cmake | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Resources/CMake/BoostConfiguration.cmake b/Resources/CMake/BoostConfiguration.cmake
+index 7666df6..376bef4 100644
+--- a/Resources/CMake/BoostConfiguration.cmake
b/Resources/CMake/BoostConfiguration.cmake
+@@ -12,7 +12,7 @@ else()
+ endif()
+
+ list(APPEND ORTHANC_BOOST_COMPONENTS filesystem thread system date_time regex)
+- find_package(Boost COMPONENTS "${ORTHANC_BOOST_COMPONENTS}")
++ find_package(Boost COMPONENTS ${ORTHANC_BOOST_COMPONENTS})
+
+ if (NOT Boost_FOUND)
+ foreach (item ${ORTHANC_BOOST_COMPONENTS})
diff --git a/debian/patches/series b/debian/patches/series
index e69de29..8416969 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -0,0 +1 @@
+0001-Fix-FTBFS-with-Boost-1.71.patch
--
2.25.1
orthanc.log.gz
Description: application/gzip
signature.asc
Description: OpenPGP digital signature
Bug#953871: FTBFS with Boost 1.71
Package: plee-the-bear Version: 0.6.0-6 Severity: wishlist Tags: patch User: team+bo...@tracker.debian.org Usertags: boost1.71 Dear Maintainer, your package fails to build with boost1.71. If you want to attempt the build yourself, an updated version of boost-defaults which brings in boost1.71 dependencies can be found adding this line to your sources.list file: deb https://people.debian.org/~gio/reprepro gio main This bug has severity whishlist for the moment, but it will raised to RC as soon as version 1.71 of Boost is promoted to default. More specifically, your package fails building because it uses the old libboost-signals-dev package, which has now disappeared. The attached patch should fix the bug. Thanks and all the best, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles From 6a23544a8d2d932f02d68f1d314707f4fd47e49b Mon Sep 17 00:00:00 2001 From: Giovanni Mascellani Date: Sat, 14 Mar 2020 11:08:04 +0100 Subject: [PATCH] Fix FTBFS with Boost 1.71. --- debian/changelog | 7 debian/control| 1 - .../0008-Fix-FTBFS-with-Boost-1.71.patch | 36 +++ debian/patches/series | 1 + 4 files changed, 44 insertions(+), 1 deletion(-) create mode 100644 debian/patches/0008-Fix-FTBFS-with-Boost-1.71.patch diff --git a/debian/changelog b/debian/changelog index e82a372..442251a 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +plee-the-bear (0.6.0-6.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Do not depend on libboost-signals-dev, that does not exit any more. + + -- Giovanni Mascellani Sat, 14 Mar 2020 11:07:48 +0100 + plee-the-bear (0.6.0-6) unstable; urgency=medium * Team upload. diff --git a/debian/control b/debian/control index 39d2804..6881ca0 100644 --- a/debian/control +++ b/debian/control @@ -13,7 +13,6 @@ Build-Depends: debhelper-compat (= 12), libboost-filesystem-dev (>= 1.45), libboost-regex-dev (>= 1.45), libboost-thread-dev (>= 1.45), - libboost-signals-dev (>= 1.45), mesa-common-dev (>= 6.5), libclaw-dev (>= 1.7.0), libclaw-graphic-dev (>= 1.7.0), diff --git a/debian/patches/0008-Fix-FTBFS-with-Boost-1.71.patch b/debian/patches/0008-Fix-FTBFS-with-Boost-1.71.patch new file mode 100644 index 000..2a2d39c --- /dev/null +++ b/debian/patches/0008-Fix-FTBFS-with-Boost-1.71.patch @@ -0,0 +1,36 @@ +From: Giovanni Mascellani +Date: Sat, 14 Mar 2020 11:11:32 +0100 +Subject: Fix FTBFS with Boost 1.71. + +In Boost 1.71 the Signals library has disappears in favour or Signals2. +--- + bear-engine/CMakeLists.txt | 2 +- + plee-the-bear/CMakeLists.txt | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +diff --git a/bear-engine/CMakeLists.txt b/bear-engine/CMakeLists.txt +index e65f040..3054347 100644 +--- a/bear-engine/CMakeLists.txt b/bear-engine/CMakeLists.txt +@@ -50,7 +50,7 @@ link_directories( + include(FindBoost) + + find_package( +- Boost 1.42 REQUIRED COMPONENTS filesystem regex signals system thread ++ Boost 1.42 REQUIRED COMPONENTS filesystem regex system thread + ) + if( NOT Boost_FOUND ) + message( FATAL_ERROR +diff --git a/plee-the-bear/CMakeLists.txt b/plee-the-bear/CMakeLists.txt +index ab6d7be..04f886f 100644 +--- a/plee-the-bear/CMakeLists.txt b/plee-the-bear/CMakeLists.txt +@@ -88,7 +88,7 @@ link_directories( + # Boost + include(FindBoost) + +-find_package( Boost 1.35 REQUIRED COMPONENTS signals) ++find_package( Boost 1.35 REQUIRED COMPONENTS) + + if( NOT Boost_FOUND ) + message( FATAL_ERROR diff --git a/debian/patches/series b/debian/patches/series index 9b147a8..aa6d850 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -5,3 +5,4 @@ ptb-signals-v2.diff full-path-menu-icon.diff wx3.0-compat.patch absolute-path-in-desktop-file.patch +0008-Fix-FTBFS-with-Boost-1.71.patch -- 2.25.1 signature.asc Description: OpenPGP digital signature
Bug#953819: FTBFS with Boost 1.71
Package: src:ns3 Version: 3.30+dfsg-4 Severity: wishlist User: team+bo...@tracker.debian.org Usertags: boost1.71 Dear Maintainer, your package fails to build with boost1.71. If you want to attempt the build yourself, an updated version of boost-defaults which brings in boost1.71 dependencies can be found adding this line to your sources.list file: deb https://people.debian.org/~gio/reprepro gio main This bug has severity whishlist for the moment, but it will raised to RC as soon as version 1.71 of Boost is promoted to default. More specifically, your package fails building because it depends on libboost-signals-dev, which does not exist anymore. However, it doesn't really use Boost.Signals, so removing the dependency is enough to fix the FTBFS. Thanks and all the best, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#951253: FTBFS with Boost 1.71
Hi, Il 13/02/20 13:56, Bas Couwenberg ha scritto: >> Er, no actual reason. This setup works for me and nobody ever asked me >> to upload to experimental. I can do that anyway, if that's better for >> you. > > Yes, please. Done. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles
Bug#951253: FTBFS with Boost 1.71
Hi, Il 13/02/20 12:11, Bas Couwenberg ha scritto: >> deb https://people.debian.org/~gio/reprepro gio main > > Why isn't the new boost-defaults (also) in experimental? Er, no actual reason. This setup works for me and nobody ever asked me to upload to experimental. I can do that anyway, if that's better for you. > Thanks for looking into the upstream fix. > > It seems Gentoo people already reported the issue for Boost 1.70: > > https://github.com/mapnik/mapnik/issues/4098 > > Which contains the comment: > > " > Boost Spirit 1.71 has a small bug which is fixed on 1.72 > " > > Can't we transition to 1.72 in Debian as well, or cherry-pick the spirit > fix? I won't start working on any newer Boost version until 1.71 is made default. However there is still a lot of time for bullseye, so I'd say it's quite probable that we will have Boost >= 1.72 in bullseye. In this case I think it is reasonable to temporarily make mapnik depend on Boost 1.67 and fix it once 1.72+ is in. At the same time I don't have any problem in backporting the fix Boost.Spirit needs (if it's a reasonable patch), except that I don't quite understand which one it is. > Mapnik releases have become much more infrequent, there is not much > demand for releases from Mapbox which uses development snapshots. Right. Actually, artemp mentions in the upstream issue that he's planning to release 3.0.23 asap, but I don't really know when this will happen. And, still, we would need to fix Boost 1.71. I asked for pointers on the upstream issue. > If we can't get mapnik to work with the default boost in bullseye, we'll > just not ship it and its rdeps. Hopefully this extreme solution won't be required. :-) Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles
Bug#951253: FTBFS with Boost 1.71
ly upstream has fixed compatibility with Boost 1.71 in master, but that patch is not released yet and it doesn't apply to the tree currently in Debian. I think the easiest solution would be to just package the next upstream version as soon as it is released. Do you have an idea on when this might happen? In the meantime, once Boost 1.71 is promoted to default, you can update your dependencies to explicitly use Boost 1.67, which will not be removed immediately from unstable (unless, of course, you want to write a patch for mapnik, but to me that seems a waste of time). However, the plan is to not release Boost 1.67 with bullseye, so I hope that upstream will release before Debian will. Do you think this is a viable plan? Thanks and all the best, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles mapnik.log.gz Description: application/gzip signature.asc Description: OpenPGP digital signature
Bug#951223: FTBFS with Boost 1.71
Package: lyx Version: 2.3.4-1 Severity: wishlist User: team+bo...@tracker.debian.org Usertags: boost1.71 Dear Maintainer, your package fails to build with boost1.71. You can find a build log attached. If you want to attempt the build yourself, an updated version of boost-defaults which brings in boost1.71 dependencies can be found adding this line to your sources.list file: deb https://people.debian.org/~gio/reprepro gio main This bug has severity whishlist for the moment, but it will raised to RC as soon as version 1.71 of Boost is promoted to default. More specifically, your package fails building because it depends on libboost-signals-dev, which does not exist anymore. However, it doesn't really use Boost.Signals, so removing the dependency is enough to fix the FTBFS. Thanks and all the best, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles lyx.log.gz Description: application/gzip signature.asc Description: OpenPGP digital signature
Bug#951221: FTBFS with Boost 1.71
Package: librime Version: 1.5.3+dfsg1- Severity: wishlist User: team+bo...@tracker.debian.org Usertags: boost1.71 Dear Maintainer, your package fails to build with boost1.71. You can find a build log attached. If you want to attempt the build yourself, an updated version of boost-defaults which brings in boost1.71 dependencies can be found adding this line to your sources.list file: deb https://people.debian.org/~gio/reprepro gio main This bug has severity whishlist for the moment, but it will raised to RC as soon as version 1.71 of Boost is promoted to default. More specifically, your package fails building because it depends on package libboost-signals-dev, which does not exist anymore. Good news, however: librime does not really use Boot.Signals. So you can just remove the dependency and the package should compile just fine. Thanks and all the best, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles librime.log.gz Description: application/gzip signature.asc Description: OpenPGP digital signature
Bug#949837: FTBFS with Boost 1.71
Package: innoextract
Version: 1.8-1
Severity: wishlist
Tags: patch
User: team+bo...@tracker.debian.org
Usertags: boost1.71
Dear Maintainer,
your package fails to build with boost1.71. You can find a build log
attached. If you want to attempt the build yourself, an updated version
of boost-defaults which brings in boost1.71 dependencies can be found
adding this line to your sources.list file:
deb https://people.debian.org/~gio/reprepro gio main
This bug has severity whishlist for the moment, but it will raised to RC
as soon as version 1.71 of Boost is promoted to default.
More specifically, your package fails building because CMake scripts
provided by the package incorrectly detect a failure in linking Boost,
while Boost links just fine.
The attached patch should fix the bug.
Thanks and all the best, Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
From d183f7b741e7add6ca3d66eefdef0786cdd57d01 Mon Sep 17 00:00:00 2001
From: Giovanni Mascellani
Date: Sat, 25 Jan 2020 19:00:03 +0100
Subject: [PATCH] Fix building with Boost 1.71.
---
.../0001-Fix-building-with-Boost-1.71.patch | 24 +++
debian/patches/series | 1 +
2 files changed, 25 insertions(+)
create mode 100644 debian/patches/0001-Fix-building-with-Boost-1.71.patch
create mode 100644 debian/patches/series
diff --git a/debian/patches/0001-Fix-building-with-Boost-1.71.patch b/debian/patches/0001-Fix-building-with-Boost-1.71.patch
new file mode 100644
index 000..e58e57f
--- /dev/null
+++ b/debian/patches/0001-Fix-building-with-Boost-1.71.patch
@@ -0,0 +1,24 @@
+From: Giovanni Mascellani
+Date: Sat, 25 Jan 2020 18:58:59 +0100
+Subject: Fix building with Boost 1.71.
+
+CMake scripts try to check if we can actually link with Boost libraries,
+but they are not smart enough and think we can't, while we actually
+can.
+---
+ CMakeLists.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index b98e59d..4cdaa60 100644
+--- a/CMakeLists.txt
b/CMakeLists.txt
+@@ -176,7 +176,7 @@ find_package(Boost REQUIRED COMPONENTS
+ system
+ program_options
+ )
+-check_link_library(Boost Boost_LIBRARIES)
++#check_link_library(Boost Boost_LIBRARIES)
+ list(APPEND LIBRARIES ${Boost_LIBRARIES})
+ link_directories(${Boost_LIBRARY_DIRS})
+ include_directories(SYSTEM ${Boost_INCLUDE_DIR})
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..3c27bac
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+0001-Fix-building-with-Boost-1.71.patch
--
2.25.0
innoextract.log.gz
Description: application/gzip
signature.asc
Description: OpenPGP digital signature
Bug#949836: FTBFS with Boost 1.71
Package: icinga2
Version: 2.11.2-2
Severity: wishlist
Tags: patch
User: team+bo...@tracker.debian.org
Usertags: boost1.71
Dear Maintainer,
your package fails to build with boost1.71. You can find a build log
attached. If you want to attempt the build yourself, an updated version
of boost-defaults which brings in boost1.71 dependencies can be found
adding this line to your sources.list file:
deb https://people.debian.org/~gio/reprepro gio main
This bug has severity whishlist for the moment, but it will raised to RC
as soon as version 1.71 of Boost is promoted to default.
More specifically, your package fails building because a CMake routine
incorrectly thinks it is using a very old version of Boost. This is due
to that routine expecting the Boost version in a format different from
the current one.
The attached patch should fix the bug.
Thanks and all the best, Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
From 68f57c3398d4ee5da547b8d9bee74512fe68954c Mon Sep 17 00:00:00 2001
From: Giovanni Mascellani
Date: Sat, 25 Jan 2020 18:39:25 +0100
Subject: [PATCH] Fix building with Boost 1.71.
---
.../0003-Fix-building-with-Boost-1.71.patch | 79 +++
debian/patches/series | 1 +
2 files changed, 80 insertions(+)
create mode 100644 debian/patches/0003-Fix-building-with-Boost-1.71.patch
diff --git a/debian/patches/0003-Fix-building-with-Boost-1.71.patch b/debian/patches/0003-Fix-building-with-Boost-1.71.patch
new file mode 100644
index ..adaf898a
--- /dev/null
+++ b/debian/patches/0003-Fix-building-with-Boost-1.71.patch
@@ -0,0 +1,79 @@
+From: Giovanni Mascellani
+Date: Sat, 25 Jan 2020 18:37:57 +0100
+Subject: Fix building with Boost 1.71.
+
+The CMake file that detects Boost.Test version uses an older version
+format, and incorrectly thinks that the available Boost version is
+very old. This patch removes the version check, since Debian already
+has a sufficiently recent Boost version.
+---
+ third-party/cmake/BoostTestTargets.cmake | 38
+ 1 file changed, 19 insertions(+), 19 deletions(-)
+
+diff --git a/third-party/cmake/BoostTestTargets.cmake b/third-party/cmake/BoostTestTargets.cmake
+index 8c26324..98f0602 100644
+--- a/third-party/cmake/BoostTestTargets.cmake
b/third-party/cmake/BoostTestTargets.cmake
+@@ -47,27 +47,27 @@ set(BOOST_TEST_TARGET_PREFIX "boosttest")
+ if(NOT Boost_FOUND)
+ find_package(Boost 1.34.0 QUIET)
+ endif()
+-if("${Boost_VERSION}0" LESS "1034000")
+- set(_shared_msg
+- "NOTE: boost::test-based targets and tests cannot "
+- "be added: boost >= 1.34.0 required but not found. "
+- "(found: '${Boost_VERSION}'; want >=103400) ")
+- if(BUILD_TESTING)
+- message(FATAL_ERROR
+- ${_shared_msg}
+- "You may disable BUILD_TESTING to continue without the "
+- "tests.")
+- else()
+- message(STATUS
+- ${_shared_msg}
+- "BUILD_TESTING disabled, so continuing anyway.")
+- endif()
+-endif()
++# if("${Boost_VERSION}0" LESS "1034000")
++# set(_shared_msg
++# "NOTE: boost::test-based targets and tests cannot "
++# "be added: boost >= 1.34.0 required but not found. "
++# "(found: '${Boost_VERSION}'; want >=103400) ")
++# if(BUILD_TESTING)
++# message(FATAL_ERROR
++# ${_shared_msg}
++# "You may disable BUILD_TESTING to continue without the "
++# "tests.")
++# else()
++# message(STATUS
++# ${_shared_msg}
++# "BUILD_TESTING disabled, so continuing anyway.")
++# endif()
++# endif()
+
+ include(GetForceIncludeDefinitions)
+ include(CopyResourcesToBuildTree)
+
+-if(Boost_FOUND AND NOT "${Boost_VERSION}0" LESS "1034000")
++if(Boost_FOUND)
+ set(_boosttesttargets_libs)
+ set(_boostConfig "BoostTestTargetsIncluded.h")
+ if(NOT Boost_UNIT_TEST_FRAMEWORK_LIBRARY)
+@@ -144,7 +144,7 @@ function(add_boost_test _name)
+ "Syntax error in use of add_boost_test: at least one source file required!")
+ endif()
+
+- if(Boost_FOUND AND NOT "${Boost_VERSION}0" LESS "1034000")
++ if(Boost_FOUND)
+
+ include_directories(${Boost_INCLUDE_DIRS})
+
+@@ -236,7 +236,7 @@ function(add_boost_test _name)
+ set(_test_command ${_target_name})
+ endif()
+
+- if(TESTS AND "${Boost_VERSION}" VERSION_GREATER "103799")
++ if(TESTS)
+ foreach(_test ${TESTS})
+ add_test(NAME
+ ${_name}-${_test}
diff --git a/debian/patches/series b/debian/patches/series
index 6bcd4174..189d1033 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
21_config_changes
postgres-checkcommand.patch
+0003-Fix-building-with-Boost-1.71.patch
--
2.25.0
icinga2.log.gz
Description: application/gzip
signature.asc
Description: OpenPGP digital signature
Bug#948665: FTBFS with Boost 1.71
Package: ciftilib Version: 1.5.3-2 Severity: wishlist Tags: patch User: team+bo...@tracker.debian.org Usertags: boost1.71 Dear Maintainer, your package fails to build with boost1.71. You can find a build log attached. If you want to attempt the build yourself, an updated version of boost-defaults which brings in boost1.71 dependencies can be found adding this line to your sources.list file: deb https://people.debian.org/~gio/reprepro gio main This bug has severity whishlist for the moment, but it will raised to RC as soon as version 1.71 of Boost is promoted to default. More specifically, your package fails building because it uses some deprecated Boost.Filesystem API. The attached patch should fix the bug. Thanks and all the best, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles From aec27618a020df16effa5819f842e7467131cdc1 Mon Sep 17 00:00:00 2001 From: Giovanni Mascellani Date: Sat, 11 Jan 2020 15:46:34 +0100 Subject: [PATCH] Fix compilation with Boost 1.71. --- ...0002-Fix-compilation-with-Boost-1.71.patch | 31 +++ debian/patches/series | 1 + 2 files changed, 32 insertions(+) create mode 100644 debian/patches/0002-Fix-compilation-with-Boost-1.71.patch diff --git a/debian/patches/0002-Fix-compilation-with-Boost-1.71.patch b/debian/patches/0002-Fix-compilation-with-Boost-1.71.patch new file mode 100644 index 000..0fe8348 --- /dev/null +++ b/debian/patches/0002-Fix-compilation-with-Boost-1.71.patch @@ -0,0 +1,31 @@ +From: Giovanni Mascellani +Date: Sat, 11 Jan 2020 15:44:14 +0100 +Subject: Fix compilation with Boost 1.71. + +Method file_string() is now obsolete and just calls string(). +--- + src/CiftiFile.cxx | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/src/CiftiFile.cxx b/src/CiftiFile.cxx +index 9bbb16d..6b15311 100644 +--- a/src/CiftiFile.cxx b/src/CiftiFile.cxx +@@ -100,7 +100,7 @@ namespace + return QFileInfo(mypath).absoluteFilePath(); + #else + #ifdef CIFTILIB_BOOST_NO_FSV3 +- return filesystem::complete(AString_to_std_string(mypath)).file_string(); ++ return filesystem::complete(AString_to_std_string(mypath)).string(); + #else + return filesystem::absolute(AString_to_std_string(mypath)).native(); + #endif +@@ -113,7 +113,7 @@ namespace + return QFileInfo(mypath).canonicalFilePath(); + #else + #ifdef CIFTILIB_BOOST_NO_FSV3 +-return filesystem::complete(AString_to_std_string(mypath)).file_string(); ++return filesystem::complete(AString_to_std_string(mypath)).string(); + #else + #ifdef CIFTILIB_BOOST_NO_CANONICAL + filesystem::path temp = AString_to_std_string(mypath); diff --git a/debian/patches/series b/debian/patches/series index 1348bdb..8dde55d 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1 +1,2 @@ 0001-force-endian-of-datatype-example-to-make-tests-pass-.patch +0002-Fix-compilation-with-Boost-1.71.patch -- 2.25.0.rc2 ciftilib.log.gz Description: application/gzip signature.asc Description: OpenPGP digital signature
Bug#948407: Wrong attachments!
Argh, I am a disaster, the original attachments are wrong. Here you have
the correct ones!
Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
From 4e04dd26bbcae06751eb6c4250835eb0a5013708 Mon Sep 17 00:00:00 2001
From: Giovanni Mascellani
Date: Wed, 8 Jan 2020 11:17:48 +0100
Subject: [PATCH] Fix build with Boost 1.71.
---
debian/patches/fix_boost | 17 +
debian/patches/series| 1 +
2 files changed, 18 insertions(+)
create mode 100644 debian/patches/fix_boost
create mode 100644 debian/patches/series
diff --git a/debian/patches/fix_boost b/debian/patches/fix_boost
new file mode 100644
index 000..0c44320
--- /dev/null
+++ b/debian/patches/fix_boost
@@ -0,0 +1,17 @@
+Subject: Fix build with Boost 1.71.
+From: Giovanni Mascellani
+
+CMake scripts search for a Boost component named "PYTHONXY", while
+they should search for "pythonXY".
+
+--- calamares-3.2.17.1.orig/CMakeModules/BoostPython3.cmake
calamares-3.2.17.1/CMakeModules/BoostPython3.cmake
+@@ -37,7 +37,7 @@ macro( _find_boost_python3_int boost_ver
+ find_package( Boost ${boost_version} QUIET COMPONENTS ${_fbp_name} )
+ string( TOUPPER ${_fbp_name} _fbp_uc_name )
+ if( Boost_${_fbp_uc_name}_FOUND )
+-set( ${found_var} ${_fbp_uc_name} )
++set( ${found_var} ${_fbp_name} )
+ break()
+ endif()
+ endforeach()
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..52c492b
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+fix_boost
--
2.25.0.rc1
calamares.log.gz
Description: application/gzip
signature.asc
Description: OpenPGP digital signature
