Bug#914862: Ark can't handle rar archives that contain files with square brackets (that is, "[" and "]") in the name
Package: ark Version: 4:18.04.1-1 Ark can't properly handle rar archives that contain files with square brackets (that is, "[" and "]") in the name. How to test: 1. Take an existing valid epub file and rename it as "Test file - [Bracket Test].epub" (without quotes) 2. Put the above file into a rar archive with the name "Test file - [Bracket Test].epub.rar" (without quotes) 3. Open "Test file - [Bracket Test].epub.rar" wiht Ark, Ark shows "Test file - [Bracket Test].epub" inside. 4. Click on the "Test file - [Bracket Test].epub" inside Ark trying to view it 5. Ark will not be able to open the "Test file - [Bracket Test].epub" file and instead will show error: "The archive /tmp/ark-ZZyYJC/Test file - [Bracket Test].epub was not found" 6. Repeat steps 1-5 using "Test file - No Brackets in the name.epub" instead of "Test file - [Bracket Test].epub", it should work without any errors. Thanks
Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
El martes, 27 de noviembre de 2018 17:19:32 -03 Dmitry Shachnev escribió: > Hi Rohan! > > On Tue, Nov 27, 2018 at 04:24:43PM +0100, Rohan Garg wrote: > > [...] > > > > I concur here. It was correctly pointed out in another reply that by using > > OpenGL we're specifically catering to software that doesn't support > > GLES while making performance worse for mature applications that > > do implement both OpenGL and GLES. The reality of the situation is that > > the market currently favors GLES over GL on ARM SBC's, delivered with > > proprietary blobs. I think a more pragmatic view of this reality would be > > to deliver the best FOSS user experience that's possible with the > > proprietary drivers while the open source drivers are being improved. To > > that extent, by switching to GLES we improve the overall situation since > > OpenGL applications can fall back to software rendering via mesa on > > platforms where mesa does not support the GPU. > > Here I agree with Luke Kenneth Casson Leighton’s opinion [1]. > > I think we should aim to provide the best possible experience with the free > software ecosystem. The experience with proprietary drivers should be the > second priority, if priority at all. I can't but agree here. -- Una vez que hemos eliminado lo imposible, lo que queda, por improbable que parezca, es la verdad. Sherlock Holmes Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
qtchooser_66-1_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 27 Nov 2018 23:22:49 +0300 Source: qtchooser Binary: qtchooser Architecture: source Version: 66-1 Distribution: unstable Urgency: medium Maintainer: Debian Qt/KDE Maintainers Changed-By: Dmitry Shachnev Description: qtchooser - Wrapper to select between Qt development binary versions Changes: qtchooser (66-1) unstable; urgency=medium . [ Simon Quigley ] * Add my name to Uploaders. . [ Dmitry Shachnev ] * New upstream release. * Drop fix_endsWith_check.diff, applied upstream. * Update Vcs fields for migration to salsa.debian.org. * Update debian/watch for the new tarballs location. * Bump debhelper compat level to 11. * Bump Standards-Version to 4.2.1, no changes needed. Checksums-Sha1: c5ad7eda7752d69a971bcaa292783ba28ee28423 2123 qtchooser_66-1.dsc 0d453875fc130519ce7ecb4bf0c19d69d3fa8f19 32008 qtchooser_66.orig.tar.xz f501502bf0379743bb1c31305a97fe413cd19b07 6216 qtchooser_66-1.debian.tar.xz e9f8d78c33e0a71a17b593ebbcb9d0482c29d6a9 10128 qtchooser_66-1_source.buildinfo Checksums-Sha256: ccac1d9c4421886576c9792242c5adb92a8a56a9dc90a4b8192debc3e0364a7c 2123 qtchooser_66-1.dsc b22c21df135d48fc775d26d771170c2c70555704d4625605383be2cd149c7cea 32008 qtchooser_66.orig.tar.xz 6f89d839426596a91dcf02c3c9187b05b5ea352e8152185cb7357d7d38a7ed19 6216 qtchooser_66-1.debian.tar.xz 4a81baded2d34f722d0d2da59e1ae93b13ade729863785b07cac9080983f231f 10128 qtchooser_66-1_source.buildinfo Files: 5f30bea24324b199a01e95ec57fb678e 2123 libdevel optional qtchooser_66-1.dsc 013caa87c2729d763822355c0b480dc2 32008 libdevel optional qtchooser_66.orig.tar.xz bc5294ffb76cd981d7c19c9594963bf7 6216 libdevel optional qtchooser_66-1.debian.tar.xz 1beace701e4f8826fc0e3220e3dff0e8 10128 libdevel optional qtchooser_66-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJHBAEBCgAxFiEEbEPcK+5mZmLK5jNU1v5xA2P4XdMFAlv9p8cTHG1pdHlhNTdA ZGViaWFuLm9yZwAKCRDW/nEDY/hd02xxEACfh84PafVHmOSluiVPsgJ8wiDSiVfp 27UL1TSb1Z1xF2E2iYdfIAv2kyV8mqjPo89IuZ9sBmQ3fM3VizPqzp+Rfn7Nq+dU Dkkx1iz3XCzKcYOR+Z375D4ae13xPCZJIoqKwg4rDDC1zmTjv1KwmpXG/kyJa3gV aZWXTlYvivKbnBs9VQedjBd4CT3QECOeIyKa8oF2SQgaDscKyinBXosbDQ1j3MUn TVHJCdFDeqhIB7lt+KhyaAJEn4J5F3x3q3vrYUm1qWNm8FvZYGOPkwvOoeA9oMfr 6dENd2ZsZUTA4Re6FRpL9pfFhqy3UUvZbj2KoEGNpZKolsdrAmR/dCdd569SM6bz GSQaYs40IAKwbWqA2bvqzntCuSyXHeDAcgLIoO5EsRymp/k3dqWxojuTneHU/7by WySpLiZBrGNToVlCNUFcatPH+bkJMauPR/ViFoRgrNQJaa7dt8wtdjmAkAm19Cum NuV1qYRsB41r7uNAuOjkfCd+kjoa+EyyIB5hfGXkrjpPZrb9QEatfvnWWeSQMsOf P5ZGv4pQc1JlOqOJNZ7K95MQp+yvTr6r9fDd274zIlsU6FAMo4zuv9+txCTuoFqq jA3ptOlsSeztzp9ftLiY+brSFhSYLwmqaKjsAIXgJmCwntHlezKvF+6PuOVccGMT y5GizY0RYLJUHw== =Ogbv -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of qtchooser_66-1_source.changes
qtchooser_66-1_source.changes uploaded successfully to localhost along with the files: qtchooser_66-1.dsc qtchooser_66.orig.tar.xz qtchooser_66-1.debian.tar.xz qtchooser_66-1_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
Hi Rohan! On Tue, Nov 27, 2018 at 04:24:43PM +0100, Rohan Garg wrote: > [...] > > I concur here. It was correctly pointed out in another reply that by using > OpenGL we're specifically catering to software that doesn't support > GLES while making performance worse for mature applications that > do implement both OpenGL and GLES. The reality of the situation is that > the market currently favors GLES over GL on ARM SBC's, delivered with > proprietary blobs. I think a more pragmatic view of this reality would be to > deliver the best FOSS user experience that's possible with the proprietary > drivers while the open source drivers are being improved. To that extent, > by switching to GLES we improve the overall situation since OpenGL > applications can fall back to software rendering via mesa on platforms > where mesa does not support the GPU. Here I agree with Luke Kenneth Casson Leighton’s opinion [1]. I think we should aim to provide the best possible experience with the free software ecosystem. The experience with proprietary drivers should be the second priority, if priority at all. > By choosing to build Qt with GLES on ARM64, we make Debian a more > attractive platform for vendors who'd like to target ARM64 boards. We should make it attractive for vendors to release their code under a free software (DFSG) license. That way anyone would be able to hack on it and add missing support for a different OpenGL variant, if needed. That said, as Lisandro announced, we will be happy to make any decision if there is either a consensus or a TC decision about it. [1]: https://lists.debian.org/debian-devel/2018/11/msg00622.html -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
Hey On Mon, Nov 26, 2018 at 12:38 PM Raphael Hertzog wrote: > > Hello Lisandro, > > TLDR: thank you for starting this discussion, it was required as it's not > an easy decision to take as there is no realistic perfect solution, but I > believe you took the wrong decision. Please consider deferring the > decision to the technical committe by seeking his advice (point 6.1.3 > of the constitution https://www.debian.org/devel/constitution.en.html#item-6). > Having worked on multiple ARM boards over the past 3 years, I agree very strongly with Raphael. > On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote: > > It seems now clear that the general consensus seems to expect: > > = Qt available for both Desktop and ES OpenGL flavours > > = If no change is possible, keep arm64 with Desktop OpenGL support > > I'm not pleased with how this discussion was handled. First of all, > you did not leave enough time for all stakeholders to participate in > the discussion (started on November 22th, closed November 25th, 3 days, > that's not a reasonable timeframe in particular when 2 of the 3 days > were in the week-end). I was aware of the discussion but did not > had the time to chime in, yet I was the person who re-opened the bug > #881333 in the first place. > As the person who opened #881333, I completely agree. I've been on vacation the past 10 days and haven't had a opportunity to chime in. > I also invited someone else who is working on a concrete project involving > Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available > now but he also did not have the time to contribute to the discussion. > I've had multiple concrete projects involving KDE, Qt and ARM over the past few years, over multiple ARM platforms such as the ODROID C1, C2 and the Pinebook. With my KDE hat on, we have a strong stake in having Plasma perform decently well on these devices. > Then I have read the whole discussion and I don't have the feeling that > any consensus has been reached. It was largely driven by Andy Simpkins > who explained his "gut feeling" as a tinkerer of arm* boards/devices and > Bret Curtis who contributes to some applications with very specific OpenGL > needs. While I value their contribution to the discussion, they both > represent very specific classes of users. > > What I remember from this discussion is that the Windows build of Qt > use GLES 2 by default. It would have been interesting to find out the > rationale for this... because maybe the right decision for us would be > to switch to GLES 2 by default as well (on all architectures as jcristau > suggested). Someone else who likely also tried to ensure Qt for Windows is > usable on most hardware made that choice. > > We got confirmation from many persons that almost all cards benefitting > from Desktop OpenGL would also work with OpenGL ES. So in terms of > hardware support, picking OpenGL ES is the right choice. In terms of > sofware support, it looks like that Desktop OpenGL is better as there > are a few applications that only work with Desktop OpenGL. > > Software can be fixed/improved to also work with OpenGL ES. However > hardware, once bought, cannot be fixed to support Desktop OpenGL > when it has been designed for OpenGL ES only. > I concur here. It was correctly pointed out in another reply that by using OpenGL we're specifically catering to software that doesn't support GLES while making performance worse for mature applications that do implement both OpenGL and GLES. The reality of the situation is that the market currently favors GLES over GL on ARM SBC's, delivered with proprietary blobs. I think a more pragmatic view of this reality would be to deliver the best FOSS user experience that's possible with the proprietary drivers while the open source drivers are being improved. To that extent, by switching to GLES we improve the overall situation since OpenGL applications can fall back to software rendering via mesa on platforms where mesa does not support the GPU. > When taking all this into account, I believe that the right solution is > to use OpenGL ES on all architectures. This will provide the required > incentives for application developers who stick only to Desktop OpenGL > to support OpenGL ES (even it it's at the cost of using some intermediary > layer like https://github.com/p3/regal) and would maximize hardware > support on all architectures. > > That said, I'm fine with a decision to change only arm64 since that's > an architecture were devices that support only OpenGL ES are in the > majority. > By choosing to build Qt with GLES on ARM64, we make Debian a more attractive platform for vendors who'd like to target ARM64 boards. Cheers Rohan Garg
Bug#881333: tracking OpenGL support for specific boards
> > https://github.com/Re4son/kali-gemini-multistrap-config/raw/files/Arm64List.xls > > > > Any feedback, correction and addition that could benefit this discussion > > would be appreciated. > > Great that you collected that dataset, and put it public. > > What would help further would be for such information having references > to sources, and each information point be referencable (not only the > dataset as a whole). > Isn't this already done for us here? https://gpuinfo.org/ If anything, it should be used to fill in that list. Many of those chipsets you list, as I understand, have a mesa driver for them that support opengl and gles. Such as freedreno which supports Mali A4XX series. https://mesamatrix.net/ Keep in mind, only the proprietary drivers seem to not support opengl while the hardware is perfectly capable of doing so. Cheers, Bret
Bug#881333: tracking OpenGL support for specific boards
Quoting Re4son (2018-11-27 11:38:14) > On 2018-11-27 02:46 +, Wookey wrote: > > > > > > Well, that's at very least an interesting data point. So yes, they exist, > > > but > > > they are new and expensive. Can I assume that this means most of our > > > arm64 > > > users do not yet get to them? > > > Not yet, no although I think you can just buy one (Gigabyte > > ThunderXstation) now. But Machiato-bin exists with working PCI and > > you can buy one > > (https://wiki.debian.org/InstallingDebianOn/Marvell/MACCHIATOBin), > > and nvidia-based hardware is available and supports GL (Jetson TX1) > > (https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TX1). > > There is more hardware coming which will support GL, so it is > > definately not as simple as 'available hardware is all GLES'. > > (Perhaps someone has made a list in this long thread). > > I have previously compiled this excel sheet with data relevant to this thread: > > https://github.com/Re4son/kali-gemini-multistrap-config/raw/files/Arm64List.xls > > Any feedback, correction and addition that could benefit this discussion > would be appreciated. Great that you collected that dataset, and put it public. What would help further would be for such information having references to sources, and each information point be referencable (not only the dataset as a whole). In other words, your data gets 2 stars: https://5stardata.info/en/ I maintain https://wiki.debian.org/CheapServerBoxHardware and have for a long time wanted to make that 5-star data (currently that has 3 stars). Would be great to include your dataset in that, but I would then need to know the sources for the datapoints to be able to verify. Also, ideal would be that you maintain your dataset yourself as 5-star reusable data instead of me needing to maintain a fork. A user-visible benefit of 5-star data is the possibility for not only browsing it as tabular data, but also navigating multiple dimensions e.g. like https://kumu.io/DigLife/digital-life-collective#our-network Please tell me if interested in helping out, and I will provide concrete examples of how to optimally organize data, as soon as I get it documented for my own work. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#881333: Upcoming Qt switch to OpenGL ES on arm64
Hi, On 2018-11-27 02:46 +, Wookey wrote: > > > > Well, that's at very least an interesting data point. So yes, they exist, > > but > > they are new and expensive. Can I assume that this means most of our arm64 > > users do not yet get to them? > Not yet, no although I think you can just buy one (Gigabyte > ThunderXstation) now. But Machiato-bin exists with working PCI and you > can buy one > (https://wiki.debian.org/InstallingDebianOn/Marvell/MACCHIATOBin), and > nvidia-based hardware is available and supports GL (Jetson TX1) > (https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TX1). There > is more hardware coming which will support GL, so it is definately not > as simple as 'available hardware is all GLES'. (Perhaps someone has > made a list in this long thread). I have previously compiled this excel sheet with data relevant to this thread: https://github.com/Re4son/kali-gemini-multistrap-config/raw/files/Arm64List.xls Any feedback, correction and addition that could benefit this discussion would be appreciated. > > > I recall Linaro doing some work on this back > > > when it started (to make it easier to switch between GL and > > > GLES). Possibly that work never actually got done, just talked out. > > > > It would really help, indeed. > > OK. It seems that this project was started, but not completed due to a > lack of interest at the time (2012) (people just started using GLES on > dev boards/phones). It's here: https://code.launchpad.net/glproxy > And here is the spec: > https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Specs/1105/GLProxy > Perhaps it is worth resurrecting this project if it would let us > acheive the nirvana of runtime selection between GL and GLES, thus > making everyone happy. > Jammy Zhou cc:ed can say how much was/wasn't done. That is extremely interesting, anything I can do to help? > Wookey Many thanks, Re4son
Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
Hi, On 26/11/18 11:54 pm, Riku Voipio wrote: > On Mon, Nov 26, 2018 at 12:37:57PM +0100, Raphael Hertzog wrote: >> were in the week-end). I was aware of the discussion but did not >> had the time to chime in, yet I was the person who re-opened the bug >> #881333 in the first place. > >> I also invited someone else who is working on a concrete project involving >> Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available >> now but he also did not have the time to contribute to the discussion. >> Software can be fixed/improved to also work with OpenGL ES. However >> hardware, once bought, cannot be fixed to support Desktop OpenGL >> when it has been designed for OpenGL ES only. > Reading from #881333 you mean Gemini PDA. It comes with Mediatek X27, > featuring Mali-T880. The hardware is not OpenGL ES only .. the > propiertary driver is. Mesa-based panfrost driver should support both > OpenGL and OpenGL ES: > > https://gitlab.freedesktop.org/panfrost > > The open source driver is of course not ready... ...but neither is > Debian ES 2.0. In the long run, making the driver ready is time better > spent than time spent trying to make Debian more friendly to a class > of propiertary drivers. I fully agree again. Looking at the lengthy progress so far and the limited resources available, I suggest supporting the development by switching to GLES and work on the drivers to support that first. Once that has been achieved we can aim for full OpenGL support and then we can switch back to desktop if there is actual user demand. I'm not suggesting to make Debian more friendly to proprietary drivers. The exact opposite: switching to GLES to fill the void will give us time to aim for one milestone at a time. The vast majority of devices we are talking about are embedded systems, let's aim to bring them the drivers and interfaces that have been designed for embedded systems before we reach for the stars. A lot of the discussion in this thread seems off topic and academic but I’m confident that the above approach is what we need to move on. > Riku > Many thanks
partitionmanager_3.3.1-4_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 27 Nov 2018 10:18:20 +0200 Source: partitionmanager Binary: partitionmanager Architecture: source Version: 3.3.1-4 Distribution: unstable Urgency: medium Maintainer: Debian KDE Extras Team Changed-By: Jonathan Carter Description: partitionmanager - file, disk and partition management for KDE Closes: 9122990 Changes: partitionmanager (3.3.1-4) unstable; urgency=medium . * debian/control: Add btrfs-progs to suggests field (Closes: #9122990) Checksums-Sha1: bb296437f2f96a57c38a42559e265366c514b662 2849 partitionmanager_3.3.1-4.dsc 1dae6ff7dfcb1a61097ab53e051f83d6b3036d3f 1332860 partitionmanager_3.3.1.orig.tar.xz 2e235aa98cecd4da5cd0068f0662e2c308a9e562 1241 partitionmanager_3.3.1.orig.tar.xz.asc ddacb069a1b0450a034f4c7fea8dbdd7c154608a 16600 partitionmanager_3.3.1-4.debian.tar.xz 08332555686fa2b4e59de92b4f82e75c26b393f0 13908 partitionmanager_3.3.1-4_source.buildinfo Checksums-Sha256: a80cb576bae4462e41e067e89ceabc39971a7cc1c6d8cf153b1558c2621de1af 2849 partitionmanager_3.3.1-4.dsc 5107955f9c70fc859bef04a54bffb28cd50efe355694232b9860e9d9c97a0f4a 1332860 partitionmanager_3.3.1.orig.tar.xz 7b1a45372b34599dea8e9c3c766b3c42ff667c18647cc4656602137e9212cdb4 1241 partitionmanager_3.3.1.orig.tar.xz.asc 78f87dd1b09ff953932833cc87f3114ef44de198436474491f6cb3cba34aadee 16600 partitionmanager_3.3.1-4.debian.tar.xz 7f300e74b7c60e96b2a9037313d34b0f6c37deb16935bf69278cacdd3b7dc7c4 13908 partitionmanager_3.3.1-4_source.buildinfo Files: 7643db1d6462a4948f824da7a3121914 2849 admin optional partitionmanager_3.3.1-4.dsc 3fb4020bd5d132e9adde59314230a943 1332860 admin optional partitionmanager_3.3.1.orig.tar.xz 4d46bb0fbf4d2421d3f7a85ad1c7a080 1241 admin optional partitionmanager_3.3.1.orig.tar.xz.asc 702d0afd534c7ded12723b11a094f203 16600 admin optional partitionmanager_3.3.1-4.debian.tar.xz c221ef49c7cfa0caffdfdc4fe9b880bc 13908 admin optional partitionmanager_3.3.1-4_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEExyA8CpIGcL+U8AuxsB0acqyNyaEFAlv8/kAPHGpjY0BkZWJp YW4ub3JnAAoJELAdGnKsjcmhPqoQAMFm3db1PvPlWopNInN90PmL9jSIq3Q7tj+i Tg1Fm7BCstIojN5c3XibT27wj2mSzs8Jdv7zrDbLQXeyd7J3Kqai3vQP1X/DysXZ uXGYUx009naOQbLWzJ1phWMucDEva/2Ow6wC7SumvQXmnWFlFhIoPVVI8BtnzeCr /zRhYfqUavX2oHZXlKFojXC3QXERyXubPuqnJIOxjtY4Xa9FOaTTfcCMZZY9uOXx nFZOB5Z5hZ0Aw/HEIOB7FYVOtxb0o5YNbrp3XvMhBLrpahjSEKyF/E3KMVy8bBkK YU61ZE06X9XI42PHBigf3OqcaX+ILZQdJp+ZZIWKbFLyngHmSXg2ucy5EgOlF4P2 p6jIFIMcbMQebroo+6yuc5eKntzpRzvXSAhvf/4cfuTS2RRe4hICdhn3ICQBA5M9 1l5n0RUZxwbXQ+1SeSop8ia5q19R8Z8YvcYCCMWVOxacLWaWbwumEkbGGhu95fZl Ahkwkn5OJryHHCHIv+4UpH1esXEKuFS7X96BlUSGqoxgxFfzw8m+wIr/p1HgYh5M orh48S0j9lPdlzzqvwCo9z5tYffpqLDvGYW2ywlKbaUiOWwXX3XduksL1qXvZbSB 37zkTcRZsZ7+RcKlPvRLlQJpBN5qqO2HNKjwcSRrg/V7wDBYB4UWtECuKKnu1XGr iJLPuPsD =jpFd -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of partitionmanager_3.3.1-4_source.changes
partitionmanager_3.3.1-4_source.changes uploaded successfully to localhost along with the files: partitionmanager_3.3.1-4.dsc partitionmanager_3.3.1.orig.tar.xz partitionmanager_3.3.1.orig.tar.xz.asc partitionmanager_3.3.1-4.debian.tar.xz partitionmanager_3.3.1-4_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#914784: cantor ftbfs on all archs except amd64
Package: src:cantor Version: 4:18.08.1-1 Severity; serious Tags: sid buster https://buildd.debian.org/status/package.php?p=cantor cantor ftbfs on all archs except amd64: Scanning dependencies of target renvvars cd /<>/obj-aarch64-linux-gnu/src/scripteditor && /usr/bin/cmake -E cmake_autogen /<>/obj-aarch64-linux-gnu/src/scripteditor/CMakeFiles/cantor_scripteditor_autogen.dir/AutogenInfo.cmake Debian make[4]: Leaving directory '/<>/obj-aarch64-linux-gnu' make -f src/backends/R/rserver/CMakeFiles/renvvars.dir/build.make src/backends/R/rserver/CMakeFiles/renvvars.dir/build make[4]: Entering directory '/<>/obj-aarch64-linux-gnu' cd /<>/obj-aarch64-linux-gnu/src/backends/R/rserver && /usr/bin/R --slave --file=/<>/src/backends/R/rserver/tools/envvars.r > /<>/obj-aarch64-linux-gnu/src/backends/R/rserver/renvvars.h /usr/bin/R: line 209: /usr/bin/sed: No such file or directory /usr/bin/R: line 209: /usr/bin/sed: No such file or directory make[4]: *** [src/backends/R/rserver/CMakeFiles/renvvars.dir/build.make:60: src/backends/R/rserver/CMakeFiles/renvvars] Error 2 make[4]: Leaving directory '/<>/obj-aarch64-linux-gnu' make[3]: *** [CMakeFiles/Makefile2:3139: src/backends/R/rserver/CMakeFiles/renvvars.dir/all] Error 2 make[3]: *** Waiting for unfinished jobs make[4]: Leaving directory '/<>/obj-aarch64-linux-gnu' [ 7%] Built target cantor_scripteditor_autogen make[4]: Leaving directory '/<>/obj-aarch64-linux-gnu' [ 7%] Built target cantorlibs_autogen make[3]: Leaving directory '/<>/obj-aarch64-linux-gnu' make[2]: *** [Makefile:144: all] Error 2 make[2]: Leaving directory '/<>/obj-aarch64-linux-gnu' dh_auto_build: cd obj-aarch64-linux-gnu && make V=1 -j3 "INSTALL=install --strip-program=true" returned exit code 2 make[1]: *** [/usr/share/pkg-kde-tools/qt-kde-team/3/dhmk.mk:97: pre_build-arch_dh_auto_build] Error 2 make[1]: Leaving directory '/<>' make: *** [/usr/share/pkg-kde-tools/qt-kde-team/3/dhmk.mk:112: debian/dhmk_build-arch] Error 2 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2
