Bug#1066942: Debugging xmrig FTBFS on armhf
I could not reproduce the issue on an armhf porterbox, which is concerning. I have just uploaded a new release that just tells cmake to force an ARMv7 build if DEB_HOST_ARCH is armhf. It also includes a handy patch that makes the build log give a couple clues so I can track down why my machine and the porterbox can't reproduce it but the buildd can. -- Ben Westover OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066942: Debugging xmrig FTBFS on armhf
It seems that the maes flag is automatically added if the ARM_TARGET CMake var is not set, which happens in cmake/cpu.cmake. The first thing I saw when I opened that file looked promising: if (CMAKE_SIZEOF_VOID_P EQUAL 8) set(XMRIG_64_BIT ON) add_definitions(-DXMRIG_64_BIT) else() set(XMRIG_64_BIT OFF) endif() I figured that maybe SIZEOF_VOID_P changed with the t64 transition and this caused it to get confused and think that we are building on x86_64. Then I looked closer at the buildd log and saw that XMRIG_64_BIT was (correctly) set to OFF, which means that this could not be the issue. The next lines of interest are here: if (CMAKE_SYSTEM_PROCESSOR MATCHES "^(aarch64|arm64|armv8-a)$") set(ARM_TARGET 8) elseif (CMAKE_SYSTEM_PROCESSOR MATCHES "^(armv7|armv7f|armv7s|armv7k|armv7-a|armv7l|armv7ve)$") set(ARM_TARGET 7) endif() There are no other functions modifying the ARM_TARGET other than the option to override this value by manually setting the ARM_V7 variable. This means that CMAKE_SYSTEM_PROCESSOR must not be matching one of the armv7* values on buildd and your machine, but does on all of mine. The build could be fixed by setting ARM_V7 in d/rules on armhf, but I would prefer properly resolving this issue instead of just working around it. -- Ben Westover OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066942: xmrig: FTBFS on armhf: cc: error: unrecognized command-line option ‘-maes’
Hello, Since my last message, I have tried to reproduce this in several ways, e.g. an sbuild chroot in both qemu-user-static and on actual hardware (Raspberry Pi 2), and also a direct build on an armhf VM. It always builds successfully. Since then, there has been a new upstream release of xmrig, so I figured I would just upload and see if it still fails buildd. On the buildd log, it indeed fails with the same maes error. This means xmrig thinks it's building on x86 and adds those flags, but this doesn't happen on arm64; only on armhf, only after the t64 transition. It also doesn't happen on any of my systems but does on buildd and apparently your system. I guess I'll request guest access to an armhf porterbox and hope FTBFS happens there so I can debug this. -- Ben Westover OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066942: xmrig: FTBFS on armhf: cc: error: unrecognized command-line option ‘-maes’
Sebastian, I can't seem to reproduce this on an armhf chroot, VM, or actual hardware (all unstable). When were you last able to reproduce this? It's possible (since unstable has changed rapidly in recent days) that the problem was something external that fixed itself between then and now. -- Ben Westover OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066942: xmrig: FTBFS on armhf: cc: error: unrecognized command-line option ‘-maes’
Hello, The package builds fine on my armhf VM as well as a Raspberry Pi 2 running armhf Debian bare metal. Maybe some transitioning library caused this issue? If xmrig gets binNMU'd, it will probably build successfully. I would do it, but I'm not a Debian Developer. Could you do it? Thanks, -- Ben Westover OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1067094: pacman-package-manager: FTBFS on armel/armh
It turned out to just be a test expecting the 32 bit limit. This is patched in the newest version which I have just uploaded. Build fixed! -- Ben Westover OpenPGP_signature.asc Description: PGP signature
Bug#1067094: pacman-package-manager: FTBFS on armel/armh
Hello, Arch Linux ARM supports armhf/armel just fine, so I think this can work with little to no patches. I haven't been able to take a look since the t64 transition because I have been busy with other things. I will likely have time tomorrow to fix this. -- Ben Westover
Bug#1056331: qemu-user-static: fails to run any binary with message "error while loading shared libraries" on Apple Silicon
Package: qemu-user-static Version: 1:8.1.2+ds-1 Severity: important X-Debbugs-Cc: tho...@glanzmann.de -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, On my M1 Mac Mini running Thomas Glanzmann's Asahi port, qemu-user-static fails with only the message "error while loading shared libraries:" and nothing else; this is when trying to run any binary in a fresh debootstrap chroot which should have all the libraries it needs. QEMU did used to have a bug affecting Apple Silicon, but this was fixed in 8.1.1. Folks in the IRC chat suggest that it may be a Debian packaging issue. Thanks, - -- Ben Westover - -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.5.0-asahi-00780-g62806c2c6f29 (SMP w/8 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled qemu-user-static depends on no packages. Versions of packages qemu-user-static recommends: ii systemd 254.5-1 qemu-user-static suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEOGnacqRhdU6eNmtFwxHF9U6JtpgFAmVcCBwACgkQwxHF9U6J tphu4Q/+Iply2hp9Pzdq14ZCwZ9hlvygugrYgCuriJy3zmlctsT0Puhdn2By7dDZ OBz2SkQtot9ddGaew3z/3iGh8IiBcjKjlWtPWIH6YN27iApYUAu2sXH5TvC7Ca7v 7QapiPF91BVf//tddE5D505hBU0CNjvNrmII+7TXDRGdoJIJd0jCYCMEuiAliE8Y RF3/JE+NQeXWKKFjHy13v2+055Uxvyh/C63UiCuvAxrpitfQLZdrB9tMgk+ADTi+ JB2yad164blFRNAv2A4Qke8PoSOhlbyTGHyAYVK1eFwx7ckl/8+K/0BpQciTD7KE U/6v7GRx4efHSfguPLTWlf6Pfvpekx+/aLjleeAOurMHDgg7AcdO7d2A7AGjhMTO ksdL9gNHfIYYxu8MhnNIrwjZHk3ntmEshh65e1L3PCARTsZt/qzKdimeziCmqKgR Aqsak/mNvWnGlQzA/F1JrPXoaiejbzwNWm2RZW4M3uWGFMpKVH5acF2yFd0CuFQO gGfc96HomMw7uZxtpGcPQALqDWvpsKHUlYaNRuC3XQI6qXoWJiaaBslVx9LII6Kk rAz9pG1PwG65c8s+ansZ4DMjwL8Sp2eBw+mwl6Bm17y/l1FThf0XmvPEA4B3NQ/b hAUkpOj6gb0LwgtOfJ4sx0DAEC5OqKsolEj8X0FPqRYixLgNMMY= =EY8G -END PGP SIGNATURE-
Bug#1055954: ITP: controku -- Control Roku devices from the comfort of your own desktop
Package: wnpp Severity: wishlist Owner: Ben Westover X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: controku Version : 1.1.0 Upstream Contact: Ben Westover * URL : https://github.com/benthetechguy/controku * License : GPL-3 Programming Lang: Python Description : Control Roku devices from the comfort of your own desktop Controku is a library and GTK3 application that allows you to control Roku devices from the comfort of your own desktop. I am the developer of this program. I find it very useful, and it would be nice to have in Debian. I plan to maintain it inside of the Python team. I will need a sponsor for the initial upload, as I am only a DM. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEOGnacqRhdU6eNmtFwxHF9U6JtpgFAmVTr6kACgkQwxHF9U6J tphZVxAAps/BL8t83IiPaA5EoTlx5SlIs1me9g266vzAVaootjg5vJ5uUa86snA1 efdCdKfBvNgXyECQxM1yK0TFp4utM0yRAYg1f4JfZ2pZBI2/cyNenlUizvD3Qdp7 jSzHpdBHpEv0O+yzhU9F6PhO+jfUBRubKMjFheUU/8n1VWYNnGdbLvH4hIIO2pEi aNtlqX95BA2jxNwpJldkMYqIxKKrY1pnu8iXaOGZ6gen8Ru6e1hQ4RxmHva5odh3 5ws6rwLsAW+Butlsa4dRWfS5+tpzbjsf780bvu2oI1Anqrp04CaiKyvGlIV2V0TA QLk6vFLVT8Y0TZHuTJxYmUHBYt+gZ9TVIj/hIkQZLCRpWRXEj2SKAPe8t2ZimcXU Zbes0u8QdakmMT52swvL1Wv8AOd+Xfi4DSuYhM8ZJ+18PQ/Cwa2X3Pqre9JGPkQ8 GPiHDY3ff57kaun7inSMrKU0gYqisuLVq2MrFSyt2YckEfdHenzp5o5xMg6Y22xI 1OKMNTh99N/qkrPl0v4ueX0B6XE2NagDF/Jo55U0jxmOc1Hin3i0iE8Xz9Wu2qwk eKZxbbwnF5x3CLAHcuDTSsqvE8deqxHSXJNuBFh9iMNm1JrnTqmWSDrpEG2lmpZz uAKMzGqgfeKQIT7cjqXM5Dk8mOwObthvR5weg2hTUg+LMDVtpJ4= =BtbR -END PGP SIGNATURE-
Bug#1013165: No longer interested
Control: retitle -1 RFP: python-certbot-dns-freenom -- Freenom DNS01 plugin for certbot Control: noowner -1 I don't use Freenom anymore, so I'm not interested in this package now. If anyone is, my existing work is available at [1] for anyone to pick up. Note that Freenom users can simply use the standard ACME DNS setup now that Freenom doesn't bug out setting the DNS record for it, so this hook is pretty much obsolete. -- Ben Westover [1] https://salsa.debian.org/letsencrypt-team/certbot/certbot-dns-freenom OpenPGP_signature.asc Description: PGP signature
Bug#994746: Upstream source now uses system gpac
Hello, Now that https://github.com/CCExtractor/ccextractor/pull/1535 has been merged, the upstream source uses system gpac instead of vendoring it. -- Ben Westover OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1043100: RFS: p2pool-io/3.5+ds-1 [ITP] -- Decentralized pool for Monero mining
Package: sponsorship-requests Severity: wishlist Control: block 1042708 by -1 Dear mentors, I am looking for a sponsor for my package "p2pool-io": * Package name : p2pool-io Version : 3.5+ds-1 Upstream contact : SChernykh * URL : https://p2pool.io * License : GPL-3 * Vcs : https://salsa.debian.org/cryptocoin-team/p2pool-io Section : utils The source builds the following binary packages: p2pool-io - Decentralized pool for Monero mining To access further information about this package, please visit the following URL: https://mentors.debian.net/package/p2pool-io/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/p2pool-io/p2pool-io_3.5+ds-1.dsc Changes for the initial release: p2pool-io (3.5+ds-1) unstable; urgency=medium . * Initial Package (Closes: #1042708) Regards, -- Ben Westover OpenPGP_signature.asc Description: PGP signature
Bug#1042780: ca-certificates-java: Segmentation fault during postinst
Package: ca-certificates-java X-Debbugs-Cc: m...@benthetechguy.net Version: 20230710 Severity: important Hello, During a piuparts job in Salsa CI, there was a segmentation fault during this package's postinst run. Processing triggers for ca-certificates-java (20230710) ... Segmentation fault (core dumped) dpkg: error processing package ca-certificates-java (--configure): installed ca-certificates-java package post-installation script subprocess returned error exit status 139 This caused the job to fail. Here's the full log: https://salsa.debian.org/BenTheTechGuy/prismlauncher/-/jobs/4497300 -- Ben Westover OpenPGP_signature.asc Description: PGP signature
Bug#657712: Other p2pool project
Control: retitle -1 RFP: p2pool-in -- Peer-to-peer Bitcoin mining pool Hello, There is another similar project https://p2pool.io for Monero, which I plan to package. Since this project is older, seems more popular, and already has an existing RFP, I've decided to name my package p2pool-io. I want it to provide p2pool, so I think it would make sense for this project's package, if it'll ever exist, to be named p2pool-in, and for both it and p2pool-io to provide p2pool. Thanks, -- Ben Westover OpenPGP_signature.asc Description: PGP signature
Bug#1042708: ITP: p2pool-io -- Decentralized pool for Monero mining
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Ben Westover X-Debbugs-Cc: m...@benthetechguy.net Severity: wishlist * Package name: p2pool-io Version : 3.5 Upstream Author : SChernykh * URL : http://p2pool.io * License : GPL-3 Programming Lang: C++ Description : Decentralized pool for Monero mining Node and pool software of p2pool, the decentralized Monero mining pool. I plan to maintain this package within the Debian Cryptocoin team, as that's where monero and xmrig, which this software is designed to be used with, are also packaged. As I am only a DM, I will need a DD to sponsor the initial upload. This package is called p2pool-io because there is another project using the p2pool name that is essentially the Bitcoin equivalent of this one. Even though the other p2pool is not packaged in Debian, it has existed longer, seems to be more popular, and has had an RFP bug since 2012. My solution is to name this package p2pool-io, suggest the other one (when packaged) to be named p2pool-in, and for both to provide p2pool. -- Ben Westover OpenPGP_signature.asc Description: PGP signature
Bug#870143: Expressing interest in packaging Citra
Hello, I may be interested in packaging this when they start doing actual releases instead of just having nightly builds. -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#959145: Done with this
On 6/20/23 2:24 AM, Ben Westover wrote: > Even before trying to package this program, I couldn't get it to > build on architectures other than amd64, which is kind of > unacceptable. So, I did some more research after this, and I found out some things: 1. One of the libraries it uses only supports 64 bit architectures, and another only supports x86 (and ARM after I got a patch merged), so only the amd64 and arm64 architectures would be supported. 2. The build script for the GUI arbitrarily won't let you build on ARM64 unless you're on macOS. In my bug report [1], the Proton team didn't give any practical reason for this other than "ARM on Linux is not supported" even though it builds and runs fine once you apply a one-line change to that build script to allow ARM builds on Linux. So, with a simple patch, you can upgrade the number of supported architectures from 1 to 2. That 64-bit-only library is pretty annoying. -- Ben Westover [1] https://github.com/ProtonMail/proton-bridge/issues/398 OpenPGP_signature Description: PGP signature
Bug#1040309: Packaged but no reason to upload
Control: unblock 861615 by -1 Hello, This RFP was created so I could package this library for use in prismlauncher, but prismlauncher uses its own incompatible fork. To find this out, though, I did package this library [1], so anyone else who has a use for it can upload and maintain the package. -- Ben Westover [1] https://salsa.debian.org/BenTheTechGuy/libnbtplusplus2 OpenPGP_signature Description: PGP signature
Bug#1022747: RFS: prismlauncher/5.0+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts
Control: tags -1 - moreinfo Hello, On 7/6/23 5:59 AM, Bastian Germann wrote: > I did not recognize that prismlauncher uses a fork. If you cannot make > up for that by including some of the fork's patches, please keep the > library copy in prismlauncher. I will do the latter. -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1022747: RFS: prismlauncher/5.0+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts
Hello, On 7/4/23 6:38 AM, Bastian Germann wrote: > Please make #1040309 (libnbt++2) your ITP and package it before we > continue with prismlauncher. When that is in the archive please untag > moreinfo. I have packaged libnbt++2 [1], but Prism Launcher doesn't build with the packaged version. It looks to me like Prism Launcher's fork of libnbt++ has too many custom changes for it to still build with the original. -- Ben Westover [1] https://salsa.debian.org/BenTheTechGuy/libnbtplusplus2 OpenPGP_signature Description: PGP signature
Bug#959145: Done with this
Control: title -1 RFP: protonmail-bridge -- Proton Mail Bridge for e-mail clients. I've given up packaging this; there are too many weird dependencies which I don't have the Go experience to handle, and the source for the actual Bridge is a mess to package. Even before trying to package this program, I couldn't get it to build on architectures other than amd64, which is kind of unacceptable. Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1037973: cryptsetup: option 'tcrypt-system' in crypttab is unknown
Package: cryptsetup Version: 2:2.6.1-4 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, I am dual-booted with a Windows install encrypted by VeraCrypt. I have the following entry in /etc/crypttab to decrypt the filesystem: cryptwin PARTUUID=dfefa23b-02 none tcrypt,tcrypt-system,veracrypt The tcrypt-system option is needed because this is a system partition. It's not documented in the crypttab(5) man page, but I read about it on the Arch Wiki and it worked for me on Debian bookworm. When I updated my system after bookworm's stable release, upgrading it to trixie, I got the warning "ignoring unknown option 'tcrypt-system'" and it failed to decrypt the partition. Checking crypttab(5) again, it still doesn't mention anything about the tcrypt-system option, but the cryptsetup(8) man page stil has the --tcrypt-system flag listed, so the feature wasn't removed. I can't find any information on how to decrypt a VeraCrypt system partition other than with this option. I can still manually use --tcrypt-system to open it with cryptsetup, but the option is now unknown in crypttab. What happened between bookworm and trixie? - -- Ben Westover - -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cryptsetup depends on: ii cryptsetup-bin 2:2.6.1-4 ii debconf [debconf-2.0] 1.5.82 ii dmsetup2:1.02.185-2 ii libc6 2.36-9 cryptsetup recommends no packages. Versions of packages cryptsetup suggests: ii cryptsetup-initramfs2:2.6.1-4 ii dosfstools 4.2-1 ii keyutils1.6.3-2 ii liblocale-gettext-perl 1.07-5 -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEOGnacqRhdU6eNmtFwxHF9U6JtpgFAmSKcDIACgkQwxHF9U6J tphJTA//UBx1n+3MleEXiizCZm26nkWovfBu17jiuedmXbx9MHBTjnkuD5SOvAr7 OwMJX4xRLtXR6ez6j02A2yqGaM6ZROmKT9lbXtYnzkPNyfOjrnKq0eWT2uPGx/hV qrHQdsAB1noiO/Y8uj8ovdYNxZ1yJuVuWHZE0Ugqip2wXpiOPQvVBGWeAaUwL2NP bnDpTclXimDEp3A4wfCXgJOwsUBLUpkVx7q1S0HPgzoyB4LQIfR1MSMbua9q+iwq wjxnNe1ySISFOCxoO4Dv+648tQfLC2GbnXNBang1Gl1VKfCMX7unirVuGBwivX1N 0KdNsEIzsMco4YCQ27nseKNb7ffE8uQ0EbcV35muCguACz2iHPHw0vRhlv/rPKa6 3/kquSG3Fc5+mje36e+y1dWNAiRw6xbR9jTzllhHE6HffCgOZf5C8apQkyYGrTuC zLSyav84SOragi8nFGEe8wb6D2l4sHtz4maaGTj8TnBDdsrj59xxD/E7sjbvmYXM mPhHFoZXl7XDJXKKC9gezhLyPWeyDtrsmXMfHRrzZipbtMkKEpBRXOyCyQivQvPy B504ktFdwCQnDe8RmM+qvIxySEDY3IC4SofId4vUjcgr3KxodIJ8RPNrzONipOw6 0CTIfpiQxd1qJfW4B0huzJ0nWSIp91jgqqAjjgvY3RsdlCplgEs= =2fkH -END PGP SIGNATURE-
Bug#1003976: RFS: xmrig/6.16.2-1 [ITP] -- High performance, open source CPU/GPU miner and RandomX benchmark.
Hello, On 5/2/23 5:41 AM, Bastian Germann wrote: Please have a closer look at the Copyright info. I have only had a look at a few files but already found the general copyright header being misrepresented in d/copyright. It has to contain the following names: > [snip] Also, please have a look at the src/backend/opencl/wrappers/AdlLib*, src/base/io/Async.*, src/base/net/http*, src/base/net/stratum/DaemonClient.*, src/base/tools/Cvt.cpp, and src/base/crypto/keccak.* files for additional Copyright info. I have gone back through the entire source and made the copyright info more accurate. Thanks, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1003976: RFS: xmrig/6.16.2-1 [ITP] -- High performance, open source CPU/GPU miner and RandomX benchmark.
Control: retitle -1 RFS: xmrig/6.16.2+dfsg-1 [ITP] -- High performance, open source CPU/GPU miner and RandomX benchmark. On 4/19/23 7:59 AM, Bastian Germann wrote: I have noticed this is a completely different implementation from the argon2 package in Debian. While there could be a way to patch successfully, it might influence the runtime behaviour significantly, so you can keep the argon2 as-is. Alright. What we have now looks ready to push to Mentors, so I just did. Thanks, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1003976: RFS: xmrig/6.16.2-1 [ITP] -- High performance, open source CPU/GPU miner and RandomX benchmark.
Hello, On 4/18/23 10:18 AM, Bastian Germann wrote: I looked into this when I first started packaging xmrig. Unfortunately, for many of these third party libraries, Debian's packaging of them won't work because the version included in xmrig is specially modified and contains lots of xmrig-specific functions that aren't easy to work around. For example, many of argon2's functions directly have xmrig in the name, and work a bit differently to those of the original project. The missing thing is hugepages support: https://github.com/xmrig/xmrig/commit/b1db0803cfdcb25fd51cef1df2dba46dc63fb0f7 src/crypto/randomx/dataset.cpp relies on some private argon2 implementation details. But as far as I can see you can just have some definitions to satisfy these needs. Ah, I see. I'm very inexperienced with C(++), so I didn't understand how easy or hard it would be to replace those specifics. Either patch or build with WITH_ARGON2=OFF. I wish I knew how to patch. I would build with argon2 off, but looking at cmake/randomx.cmake it seems like randomx, essential for mining XMR, requires argon2 to be enabled. The source also directly includes headers that exist in the original source but not a packaged version, and which are also modified specifically for xmrig. If I were to get rid of all the third party libraries that don't work easily with Debian's packaged versions, there wouldn't be much xmrig functionality left. The only thing that is not easily replacable from the original list is llhttp. Just keep this one. I have done the trivial replacements for CL, fmt, and rapidjson. hwloc is built with the system library anyway and adl is only used on Windows. Okay, there's my inexperience again. When I was first packaging this, I took a look at argon2 and assumed most of the other libraries were as hard to replace as it. Thanks for showing me how easy it really was. I've pushed what I have so far to Salsa; unless randomx is disabled, it won't build without argon2, and I don't know how to patch it. Can you please help me? Thanks, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1003976: RFS: xmrig/6.16.2-1 [ITP] -- High performance, open source CPU/GPU miner and RandomX benchmark.
Hello, On 4/17/23 2:13 PM, Bastian Germann wrote: Please see https://salsa.debian.org/cryptocoin-team/xmrig/-/commit/fa8aaf366f7168be3d30ba9c1d7e5fdaf9bb11bb to get an idea of what is to exclude. Please use the Debian replacements for those libraries. adl and libethash are not yet available (see also #1034528), so please build with WITH_KAWPOW=OFF and WITH_ADL=OFF. I looked into this when I first started packaging xmrig. Unfortunately, for many of these third party libraries, Debian's packaging of them won't work because the version included in xmrig is specially modified and contains lots of xmrig-specific functions that aren't easy to work around. For example, many of argon2's functions directly have xmrig in the name, and work a bit differently to those of the original project. The source also directly includes headers that exist in the original source but not a packaged version, and which are also modified specifically for xmrig. If I were to get rid of all the third party libraries that don't work easily with Debian's packaged versions, there wouldn't be much xmrig functionality left. Thanks, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1003976: RFS: xmrig/6.16.2-1 [ITP] -- High performance, open source CPU/GPU miner and RandomX benchmark.
Hi Bastian, If you submit the package for package maintenance in the Cryptocoin Team, I would be inclined to take a look. That sounds great! I wish I would've known of that team this whole time. I've listed team+cryptoc...@tracker.debian.org as the maintainer in my d/control file, and requested access to the Salsa group. Thanks, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1034104: RFS: ms-sys/2.8.0-1 [RFP] -- Program used to write Microsoft-compatible boot records
Package: sponsorship-requests Severity: normal Control: block 808414 by -1 Dear mentors, I am looking for a sponsor for my package "ms-sys": * Package name : ms-sys Version : 2.8.0-1 Upstream contact : Henrik Carlqvist * URL : https://ms-sys.sourceforge.net * License : GPL-3+, GPL-2+ * Vcs : https://salsa.debian.org/BenTheTechGuy/ms-sys Section : non-free/utils The source builds the following binary packages: ms-sys - Program used to write Microsoft-compatible boot records To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ms-sys/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/non-free/m/ms-sys/ms-sys_2.8.0-1.dsc Changes since the last upload: ms-sys (2.8.0-1) unstable; urgency=medium . * Initial Package (Closes: #808414) Regards, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#808414: RFP -> ITP
Control: retitle -1 ITP: ms-sys -- Program used to write Microsoft-compatible boot records Control: owner -1 ! Hello, From a quick skimming of mbr's manpage, it looks like you need to supply your own MBR for it to flash, which highly decreases the convenience factor since you need to track down the exact MBR that you need to use for the job, at which point you may as well just use dd. ms-sys has a good selection of MBRs and PBRs built in that you can use to build or repair many different operating system images. ms-sys-free also has a similar problem because most of the MBRs that make ms-sys useful are non-free, coming from proprietary Microsoft products. With ms-sys-free, all that's left is Rufus, FreeDOS, and a couple other free options. I've packaged ms-sys at https://salsa.debian.org/benthetechguy/ms-sys. Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1030629: RFS: libquazip1-qt5/1.4-1 [RC] -- Qt/C++ wrapper over minizip - Version 1 (Qt5)
Package: sponsorship-requests Severity: important X-Debbugs-CC: kilob...@angband.pl Control: block 1028641 by -1 Dear mentors, I am looking for a sponsor for my package "libquazip1-qt5": * Package name : libquazip1-qt5 Version : 1.4-1 Upstream contact : Sergey A. Tachenov * URL : https://github.com/stachenov/quazip * License : LGPL-2.1+ with static linking exception, zlib * Vcs : https://salsa.debian.org/BenTheTechGuy/libquazip1-qt5 Section : libs Changes since the last upload: libquazip1-qt5 (1.4-1) unstable; urgency=medium . * New upstream version * Add dependencies on Qt5 and zlib1g (Closes: #1028641) I am the maintainer of this package, and a previous version of it was successfully uploaded in October of last year. As I am a Debian Maintainer, I asked my sponsor for upload privileges, but didn't receive a response. Two months later, there was an RC bug #1028641 that I fixed, and I emailed again asking him to upload the fixed version, receiving no response. It has been another two months since then, and there has been a new upstream release. Since it's unlikely my original sponsor will respond at this point, I'm asking for a new one to upload this package and potentially grant me DM upload privileges for it. I'd like to note that the sister package libquazip1-qt6, with the same sponsor, has DM upload permissions, and its corresponding RC bug was fixed promptly. Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1014166: Is this still accurate?
Hello, On January 19, 2023 5:24:06 PM EST, Salvatore Bonaccorso wrote: > A CVE description might only refer to a specific point in time's state > and might not be accurate. It needs first to be confirmed the issue > would be fixed in 0.22.0. Oh, alright. I thought that since it listed a start and end version, the CVE was fixed past the end version. > What are the references confirming the CVE is fixed in 0.22.0? Can you > refer to them so we can re-check? None. I'm not familiar with the codebase or this CVE, just passing by and wondered about that start and end version listed in the description. Thanks, -- Ben Westover signature.asc Description: PGP signature
Bug#1014166: Is this still accurate?
Hello, The CVE description states that versions 0.12.0 - 0.21.1 are vulnerable, but this package is currently version 22.0. Can this bug be closed? Thanks, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1023160: ITP: libghc-filesystem -- Implementation of C++17 std::filesystem for C++11-20
Hello, On 1/8/23 10:59 AM, Bastian Germann wrote: > Looking at Prism Launcher's source, this library is really unnecessary. > Compiling with g++ -std set to c++17 or c++20 should do the trick. > Maybe you have to patch the build system not to look for the library. What in the source makes you think the library is unnecessary? I'm not experienced with C++, but it seems that launcher/FileSystem.cpp makes use of ghc::filesystem and some of its specific quirks. Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1020391: mesa: Updates to 22.2 RCs cause blank screen on some VirtIO graphics
Hello Fabio, On 1/3/23 06:35, Fabio Pedretti wrote: > You don't provide many details, but at a quick search your issue may > be this one: > https://gitlab.freedesktop.org/virgl/virglrenderer/-/issues/291 > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19655 I don't see how that issue is related to mine. It supposedly only occurs when XWayland is being used, while mine is happening on pure X11. Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1026990: ITP: golang-github-thought-machine-go-flags -- go command line option parser
Package: wnpp Severity: wishlist Owner: Ben Westover X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-thought-machine-go-flags Version : 1.6.2-1 Upstream Author : Peter Ebden * URL : https://github.com/thought-machine/go-flags * License : BSD-3-clause Programming Lang: Go Description : go command line option parser This library provides similar functionality to the builtin flag library of go, but provides much more functionality and nicer formatting. From the documentation: . Package flags provides an extensive command line option parser. The flags package is similar in functionality to the go builtin flag package but provides more options and uses reflection to provide a convenient and succinct way of specifying command line options. I am packaging this because rdpgw depends on it. I will need a sponsor as I am only a DM. Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1026989: ITP: golang-github-go-jose-go-jose -- An implementation of JOSE standards (JWE, JWS, JWT) in Go
Package: wnpp Severity: wishlist Owner: Ben Westover X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org Package: wnpp Severity: wishlist Owner: Ben Westover * Package name: golang-github-go-jose-go-jose Version : 3.0.0-1 Upstream Author : * URL : https://github.com/go-jose/go-jose * License : Apache-2.0 Programming Lang: Go Description : Go implementation of JOSE standards (JWE, JWS, JWT) Package jose aims to provide an implementation of the Javascript Object Signing and Encryption set of standards. This includes support for JSON Web Encryption, JSON Web Signature, and JSON Web Token standards. . The implementation follows the JSON Web Encryption (http://dx.doi.org/10.17487/RFC7516) (RFC 7516), JSON Web Signature (http://dx.doi.org/10.17487/RFC7515) (RFC 7515), and JSON Web Token (http://dx.doi.org/10.17487/RFC7519) (RFC 7519) specifications. Tables of supported algorithms are shown below. The library supports both the compact and JWS/JWE JSON Serialization formats, and has optional support for multiple recipients. It also comes with a small command- line utility (jose-util (https://github.com/go-jose/go-jose/tree/ master/jose-util)) for dealing with JOSE messages in a shell. I am packaging this because rdpgw, which I am also packaging, depends on it. I will need a sponsor as I am only a DM. Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1026987: ITP: rdpgw -- Remote Desktop Gateway in Go for deploying on Linux/BSD/Kubernetes
Package: wnpp Severity: wishlist Owner: Ben Westover X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: rdpgw Version : 9.0.1-1 Upstream Author : * URL : https://github.com/bolkedebruin/rdpgw * License : Apache-2.0 Programming Lang: Go Description : Remote Desktop Gateway in Go for deploying on Linux RDPGW is an implementation of the Remote Desktop Gateway protocol (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms- tsgu/0007d661-a86d-4e8f-89f7-7f77f8824188). This allows you to connect with the official Microsoft clients to remote desktops over HTTPS. These desktops could be, for example, XRDP (http://www.xrdp.org) desktops running in containers on Kubernetes. . RDPGW aims to provide a full open source replacement for MS Remote Desktop Gateway, including access policies. . RDPGW provides multi factor authentication out of the box with OpenID Connect integration. Thus you can integrate your remote desktops with Keycloak, Okta, Google, Azure, Apple or Facebook if you want. I am packaging this because I want to use my Debian server as an RDP gateway. I will need a sponsor to upload as I am only a DM. Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1020595: Marking releases as UNRELEASED instead of unstable
Control: tag -1 -pending Hello Andrea, When maintaining packages that are waiting to be sponsored, it's generally a good idea to mark the distribution in debian/changelog as UNRELEASED, because if it's listed as unstable, your ITP keeps getting marked pending every time you commit, and people can get the idea that a release is already in Debian if it's marked unstable. In the future, you should mark it UNRELEASED in Salsa and unstable in Mentors, then change it to unstable when the package is uploaded and passes NEW. Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1026244: gnome-remote-desktop: No support for VNC
Package: gnome-remote-desktop X-Debbugs-Cc: m...@benthetechguy.net Version: 43.2-1 Severity: important Dear Maintainer, When I run grdctl, none of the VNC-related options are available. I see that the Debian packaging has chosen not to build it. Why is this? I need to use VNC for my job, and gnome-remote-desktop is the only solution I know of that supports Wayland well. At the very least, if adding VNC back to the package isn't an option, can it at least be removed from the package description? > This daemon enables GNOME to offer remote desktop sharing using VNC > with PipeWire. It's a bit misleading to say your package supports VNC when it doesn't. Thanks, - -- Ben Westover -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.1.0-asahi (SMP w/8 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=C.UTF-8, LCCTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-remote-desktop depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-3 ii fuse33.12.0-1 ii init-system-helpers 1.65.2 ii libc62.36-6 ii libcairo21.16.0-7 ii libepoxy01.5.10-1 ii libfreerdp-server2-2 2.9.0+dfsg1-1 ii libfreerdp2-22.9.0+dfsg1-1 ii libfuse3-3 3.12.0-1 ii libglib2.0-0 2.74.2-1 ii libmutter-11-0 43.0-2 ii libnotify4 0.8.1-1 ii libpipewire-0.3-00.3.62-1 ii libsecret-1-00.20.5-3 ii libtss2-esys-3.0.2-0 3.2.0-4 ii libtss2-mu0 3.2.0-4 ii libtss2-rc0 3.2.0-4 ii libtss2-tctildr0 3.2.0-4 ii libwinpr2-2 2.9.0+dfsg1-1 ii libxkbcommon01.4.1-1 ii pipewire 0.3.62-1 ii wireplumber 0.4.12-1+b1 gnome-remote-desktop recommends no packages. gnome-remote-desktop suggests no packages. -- no debconf information OpenPGP_signature Description: PGP signature
Bug#1020595: Tests FTBFS on arm64
It seems to be fixed if `-DTOML_ENABLE_FLOAT16=0` is added in the configure step; this is what Prism Launcher, the application I was originally interested in packaging this for, does to work around it. On 11/21/22 11:08 PM, Ben Westover wrote: > Hello, > > All of the tests fail when building on arm64. Here is an example: > > In file included from ../tests/conformance_burntsushi_invalid.cpp:8: > ../tests/tests.h:15:2: error: #error TOML_FP16 was not deduced correctly > 15 | #error TOML_FP16 was not deduced correctly > | ^ > > A full log is attached. Build with nocheck profile is fine. > > Thanks, > -- > Ben Westover OpenPGP_signature Description: PGP signature
Bug#1023386: pacman-package-manager: Please backport to bullseye-backports
Bonjour Dylan, On 11/22/22 04:09, Dylan Aïssi wrote: > I just uploaded ppm 6.0.2-3~bpo11+1 to bullseye-backports with a delay of > 6 days to be sure 6.0.2-3 lands in bookworm first. > > I also reverted 2e079e6d because this change is not in 6.0.2-3. That commit was needed for the libraries to present the right version; without it, the their Debian revision is -3 which conflicts with the existing unstable/testing version of the package. That's why your upload just got rejected. Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1020595: Tests FTBFS on arm64
Hello, All of the tests fail when building on arm64. Here is an example: In file included from ../tests/conformance_burntsushi_invalid.cpp:8: ../tests/tests.h:15:2: error: #error TOML_FP16 was not deduced correctly 15 | #error TOML_FP16 was not deduced correctly | ^ A full log is attached. Build with nocheck profile is fine. Thanks, -- Ben Westover sbuild (Debian sbuild) 0.84.1 (15 November 2022) on debian +==+ | tomlplusplus 3.2.0+ds-1 (arm64) Tue, 22 Nov 2022 04:00:13 + | +==+ Package: tomlplusplus Version: 3.2.0+ds-1 Source Version: 3.2.0+ds-1 Distribution: unstable Machine Architecture: arm64 Host Architecture: arm64 Build Architecture: arm64 Build Type: binary I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-arm64-sbuild-8411e09e-0601-4c26-a03f-a7fc09a641fb' with '<>' I: NOTICE: Log filtering will replace 'build/tomlplusplus-gUfSxV/resolver-mI45Yl' with '<>' +--+ | Update chroot| +--+ Hit:1 http://localhost:3142/deb.debian.org/debian unstable InRelease Get:2 http://localhost:3142/deb.debian.org/debian unstable/main Sources [10.0 MB] Fetched 10.0 MB in 3s (3038 kB/s) Reading package lists... Reading package lists... Building dependency tree... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. +--+ | Fetch source files | +--+ Local sources - /home/ben/tomlplusplus_3.2.0+ds-1.dsc exists in /home/ben; copying to chroot I: NOTICE: Log filtering will replace 'build/tomlplusplus-gUfSxV/tomlplusplus-3.2.0+ds' with '<>' I: NOTICE: Log filtering will replace 'build/tomlplusplus-gUfSxV' with '<>' +--+ | Install package build dependencies | +--+ Setup apt archive - Merged Build-Depends: debhelper-compat (= 13), build-essential, fakeroot, catch2, cmake, cmark-gfm, locales-all, meson (>= 0.54.0), nlohmann-json3-dev, pkg-config Filtered Build-Depends: debhelper-compat (= 13), build-essential, fakeroot, catch2, cmake, cmark-gfm, locales-all, meson (>= 0.54.0), nlohmann-json3-dev, pkg-config dpkg-deb: building package 'sbuild-build-depends-main-dummy' in '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. Ign:1 copy:/<>/apt_archive ./ InRelease Get:2 copy:/<>/apt_archive ./ Release [580 B] Ign:3 copy:/<>/apt_archive ./ Release.gpg Get:4 copy:/<>/apt_archive ./ Sources [775 B] Get:5 copy:/<>/apt_archive ./ Packages [739 B] Fetched 2094 B in 0s (0 B/s) Reading package lists... Reading package lists... Install main build dependencies (apt-based resolver) Installing build dependencies Reading package lists... Building dependency tree... The following additional packages will be installed: autoconf automake autopoint autotools-dev bsdextrautils catch2 cmake cmake-data cmark-gfm debhelper dh-autoreconf dh-elpa-helper dh-strip-nondeterminism dwz emacsen-common file gettext gettext-base groff-base intltool-debian libarchive-zip-perl libarchive13 libbrotli1 libc-l10n libcmark-gfm-extensions0.29.0.gfm.6 libcmark-gfm0.29.0.gfm.6 libcurl4 libdebhelper-perl libelf1 libexpat1 libfile-stripnondeterminism-perl libicu72 libjsoncpp25 libldap-2.5-0 libmagic-mgc libmagic1 libmpdec3 libncurses6 libncursesw6 libnghttp2-14 libpipeline1 libpkgconf3 libprocps8 libpsl5 libpython3-stdlib libpython3.10-minimal libpython3.10-stdlib libreadline8 librhash0 librtmp1 libsasl2-2 libsasl2-modules-db libsqlite3-0 libssh2-1 libsub-override-perl libtool libuchardet0 libuv1 libxml2 locales-all m4 man-db media-types meson ninja-build nlohmann-json3-dev pkg-config pkgconf pkgconf-bin po-debconf procps python3 python3-distutils python3-lib2to3 python3-minimal python3-pkg-resources python3-setuptools python3.10 python3.10-minimal readline-common sensible-utils Suggested packages: autoconf-archive gnu-standards autoconf-doc cmake-doc cmake-format dh-make gettext-doc libasprintf-dev libgettextpo-dev groff lrzip libtool-doc gfortran | fortran95-compiler gcj-jdk m4-doc apparmor less www-browser libmail-box-perl python3-doc python3-tk python3-venv python-setuptools-doc python3.10-venv python3.10-d
Bug#1023386: Ready for upload
Control: notforwarded -1 Control: tags -1 +pending +bullseye Hello, All required changes for the backport of this package are completed and all that's needed is an upload to bullseye-backports. The package is still available at previously mentioned places (Mentors and Salsa branch debian/bullseye). Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1023386: pacman-package-manager: Please backport to bullseye-backports
Bonjour Dylan, On 11/14/22 09:41, Dylan Aïssi wrote: >> I've elected to just build it with the nocheck profile. > > Currently, without adding at least python3-distutils (and maybe other?) in BD, > pcm fails at the dh_auto_configure step with: > >> ModuleNotFoundError: No module named 'distutils.core' >> ../meson.build:31:0: ERROR: >> ['/usr/bin/python3']> is not a valid python or it is missing setuptools >> dh_auto_configure: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. >> --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc >> --localstatedir=/var --libdir=lib/x86_64-linux-gnu -Dkeyringd > > This is easily reproducible with salsa-ci by setting RELEASE to > bullseye like I did here: >> https://salsa.debian.org/daissi/pacman/-/jobs/3514447 > > My point is this issue is hidden in sid because python3-distutils is > pulled by dependencies, > but it (or python3-all) must be added in the Build-Deps of pcm even > for sid. Moreover, > based on the meson.build, it looks like python3 is not an optional build-deps. Interesting, didn't show up with my local sbuild runs for my personal archive. I had unmodified backports build fine with a nodoc flag. But if I test nodoc with Salsa it fails as you showed me. Strange. Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1020595: RFS
Hello Andrea, Since everyone that's interested in this seems to be busy, you could consider opening an RFS bug to notify possible sponsors about this package. A template is available at https://mentors.debian.net/sponsors/rfs-howto/tomlplusplus. Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1023386: pacman-package-manager: Please backport to bullseye-backports
Bonjour Dylan, On 11/8/22 12:15 PM, Dylan Aïssi wrote: > Thanks for preparing the package. I tried to build it with gbp buildpackage > in a clean bullseye environment but it failed. It seems some build-deps are > missing from the control file. At least python3-distutils needs to be added > but > then it fails to build with another error. Can you take a look? Correct me if I'm wrong, but I that believe for backports, keeping it minimally different from the original package is prioritized over things like functional tests, docs, etc. Thus, instead of adding the necessary dependencies and patching required to make the tests work on bullseye, I've elected to just build it with the nocheck profile. Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1023386: pacman-package-manager: Please backport to bullseye-backports
Hello Dylan, On 11/3/22 10:30 AM, Dylan Aïssi wrote: > The backport will have to go through the backport NEW queue, so you > need a DD to sponsor the initial version. I can sponsor it if you > want, I just need a git repo with a backport branch to build it :-). > Meanwhile, you can request to have your uid in the backports Access > Control Lists [1] for future updates. Thanks for the link. I have uploaded my backport to Mentors [1] for your sponsorship, and it's also available in the debian/bullseye branch of my package repo [2]. Can you provide DM access after it passes NEW? Thanks, -- Ben Westover [1] https://mentors.debian.net/package/pacman-package-manager/ [2] https://salsa.debian.org/BenTheTechGuy/pacman/-/tree/debian/bullseye OpenPGP_signature Description: PGP signature
Bug#1023386: pacman-package-manager: Please backport to bullseye-backports
Hello Christopher, On 11/3/22 4:53 AM, Christopher Obbard wrote:> We need pacman to install packages inside the built image, which is only > available for >bookworm. Since it's not feasible to upgrade our container > images to bookworm as it's still testing, would it be possible to backport > pacman-package-manager to bullseye-backports? > > From a first look, it seems that it _should_ be simple enough if the package > is compatible with libssl-dev 1.1.1n (there is no version requirement in > meson.build), the other build-deps are already available in bullseye. It's certainly possible with little to no modification of the package, as I have already backported pacman to bullseye in my personal repo [1]. I could officially get it in Debian backports for bullseye once I learn more about how the process works (I'm only a DM at the moment). Thanks, -- Ben Westover [1] https://apt.benthetechguy.net OpenPGP_signature Description: PGP signature
Bug#1023385: O: libquazip -- C++ wrapper for ZIP/UNZIP (documentation)
Note to anyone who plans to adopt this package: Don't upgrade it to version 1.x. The upstream wishes QuaZip 0.x and 1.x to be packaged separately, like Qt5 and Qt6 are. Packages libquazip1-qt5 and libquazip1-qt6 already exist for QuaZip 1.x. Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1023161: RFS: libghc-filesystem/1.15.12-1 [ITP] -- Implementation of C++17 std::filesystem for C++11-20
Hello, On 10/30/22 9:17 PM, Adam Borowski wrote: > # While ghc usually refers to Haskell packages, this package using the > # namespace ghc isn't related to Haskell; according to the upstream, it > # stands for "gulrak's helper classes". > wrong-section-according-to-package-name > ` > > Is there a reason you picked that specific name? Unlike some other > languages, there's no convention to name C++ packages after their > internal namespace, and this particular one clashes with Haskell, > confusing both machines and humans. No reason other than I don't know how C++ libraries/namespaces work and this is only my second time ever packaging a C++ library. What should I name it instead, libfilesystem? Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1023165: RFS: libtomlplusplus/3.2.0-1 [ITP] -- TOML config file parser and serializer for C++17
Package: sponsorship-requests Severity: wishlist Control: block 1023164 by -1 Dear mentors, I am looking for a sponsor for my package "libtomlplusplus": * Package name : libtomlplusplus Version : 3.2.0-1 Upstream contact : Mark Gillard * URL : https://marzer.github.io/tomlplusplus * License : Expat * Vcs : https://salsa.debian.org/BenTheTechGuy/libtomlplusplus Section : libs The source builds the following binary packages: libtomlplusplus-dev - TOML config file parser/serializer for C++17 - development files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libtomlplusplus/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libt/libtomlplusplus/libtomlplusplus_3.2.0-1.dsc Changes for the initial release: libtomlplusplus (3.2.0-1) unstable; urgency=medium . * Initial Package (Closes: #1023164) Regards, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1023164: ITP: libtomlplusplus -- TOML config file parser and serializer for C++17
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Ben Westover Severity: wishlist * Package name: libtomlplusplus Version : 3.2.0 Upstream Author : Mark Gillard * URL : https://marzer.github.io/tomlplusplus * License : Expat Programming Lang: C++ Description : TOML config file parser and serializer for C++17 toml++ is an optionally header-only TOML parser and serializer for C++17, plus some C++20 features where available, that also supports serializing to JSON and YAML and has proper UTF-8 handling including BOM. It doesn't require RTTI and works with or without exceptions. I am packaging this library because Prism Launcher depends on it. I do not plan to maintain this package inside a team unless one expresses interest. I'll need a sponsor for the initial upload as I am only a DM. -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1023161: RFS: libghc-filesystem/1.15.12-1 [ITP] -- Implementation of C++17 std::filesystem for C++11-20
Package: sponsorship-requests Severity: wishlist Control: block 1023160 by -1 Dear mentors, I am looking for a sponsor for my package "libghc-filesystem": * Package name : libghc-filesystem Version : 1.15.12-1 Upstream contact : Steffen Schümann * URL : https://github.com/gulrak/filesystem * License : Expat * Vcs : https://salsa.debian.org/BenTheTechGuy/libghc-filesystem Section : libs The source builds the following binary packages: libghc-filesystem-dev - C++17 std::filesystem for C++11-20 - development files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libghc-filesystem/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libg/libghc-filesystem/libghc-filesystem_1.15.12-1.dsc Changes for the initial release: libghc-filesystem (1.15.12-1) unstable; urgency=medium . * Initial Package (Closes: #1023160) Regards, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1023160: ITP: libghc-filesystem -- Implementation of C++17 std::filesystem for C++11-20
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org X-Debbugs-Cc: m...@benthetechguy.net Owner: Ben Westover Severity: wishlist * Package name: libghc-filesystem Version : 1.15.12 Upstream Author : Steffen Schümann * URL : https://github.com/gulrak/filesystem * License : Expat Programming Lang: C++ Description : C++17 std::filesystem implementation for C++11-20 ghc::filesystem is a header-only std::filesystem compatible helper library, based on the C++17 and C++20 specs, but implemented for C++11, C++14, C++17 or C++20 (tightly following the C++17 standard with very few documented exceptions). I am packaging this library because Prism Launcher depends on it. I do not plan to maintain this package inside a team unless one expresses interest. I'll need a sponsor for the initial upload as I am only a DM. -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1023086: RFS: libquazip1-qt5/1.3-1 [ITP] -- Qt/C++ wrapper over minizip - Version 1 (Qt5)
Package: sponsorship-requests Severity: wishlist Control: block 1023083 by -1 Dear mentors, I am looking for a sponsor for my package "libquazip1-qt5": * Package name : libquazip1-qt5 Version : 1.3-1 Upstream contact : Sergey A. Tachenov * URL : https://github.com/stachenov/quazip * License : zlib, LGPL-2.1+ with static linking exception * Vcs : https://salsa.debian.org/BenTheTechGuy/libquazip1-qt5 Section : libs The source builds the following binary packages: libquazip1-qt5-1 - Qt/C++ wrapper over minizip - Version 1 (Qt5) libquazip1-qt5-dev - Qt/C++ wrapper over minizip - Version 1 (Qt5) - development files libquazip1-qt5-doc - Qt/C++ wrapper over minizip - Version 1 (Qt5) - documentation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libquazip1-qt5/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libq/libquazip1-qt5/libquazip1-qt5_1.3-1.dsc Changes for the initial release: libquazip1-qt5 (1.3-1) unstable; urgency=medium . * Initial Package (Closes: #1023083) Regards, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1023083: ITP: libquazip1-qt5 -- Qt/C++ wrapper over minizip - Version 1 (Qt5)
Hello Nilesh, On 10/29/22 11:39 PM, Nilesh Patra wrote: > On Sun, Oct 30, 2022 at 03:12:18AM +0000, Ben Westover wrote: >> On 10/29/22 1:20 PM, Filippo Rusconi wrote: >>> On Tue, Sep 13, 2022 at 03:40:13PM +, Ben Westover wrote: >>>> On 9/13/22 8:28 AM, Filippo Rusconi wrote: >>>>>> I'd support any attempt to move the current libquazip[1] away >>>>>> from Debian Med team where it is just by chance since it was a >>>>>> dependency of some of our packages. It does not make any sense to >>>>>> maintain it inside the Debian Med team and I would love to hand it >>>>>> over. All maintainers except me do not respond to pings any more >>>>>> and thus can be droped from the list of Uploaders. >>>>> >>>>> I understand that, let's take it away from Debian Med and put it in >>>>> Debian at >>>>> large. Ben, if you would do the update, then I'd go over it and upload >>>>> it. That >>>>> would be very good. > > If you want to take it out of debian-med team, the right way is to * ask * the > med-team to transfer it somewhere else. What you are trying to do here is > considered > as a hostile takeover. You're replying to an old message by Filippo; I'm not *trying* to do anything. I have already explained to Filippo that this is not the correct way to do that. >>>> As stated above, the existing QuaZip *0.9* package (libquazip) and my >>>> new QuaZip *1.3* package (libquazip1-qt6) are unrelated. While they are >>>> both QuaZip packages, they are separate since QuaZip 0.x and 1.x are >>>> supposed to coexist, much like Qt5 and Qt6. The orphaning of libquazip >>>> is unrelated to my new libquazip1-qt6 being uploaded. My new package is >>>> outside of any team. >>>> The correct procedure here is to orphan libquazip, and anyone who is >>>> interested can adopt it. > > Why should the package be orphaned? The actual maintainers have said that they wish it to be. Read through the threads [1] and [2] and see the message [3]. >>>> Again, my new package libquazip1-qt6 is not >>>> related to the existing libquazip package or the Med Team. > > There are already some changes committed to git for version 1.1 in the med > team > package. If we happened to miss seeing this ITP, we might have ended up > stepping > on your toes. Again, the Med Team has asked me to create a new package instead of attempting to use their WIP 1.1 code. 0.x is supposed to be pacakged separately from 1.x. Please read the all messages of the last bug at [3] for full context. Also FYI, libquazip1-qt6 already exists; we've already gone through that whole thing. This is just an otherwise identical package for Qt5. Thanks, -- Ben Westover [1] https://alioth-lists.debian.net/pipermail/debian-med-packaging/2022-August/102963.html [2] https://alioth-lists.debian.net/pipermail/debian-med-packaging/2022-September/103264.html [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019507#42 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019507 OpenPGP_signature Description: PGP signature
Bug#1023083: ITP: libquazip1-qt5 -- Qt/C++ wrapper over minizip - Version 1 (Qt5)
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Ben Westover Severity: wishlist * Package name: libquazip1-qt5 Version : 1.3 Upstream Author : Sergey A. Tachenov * URL : https://github.com/stachenov/quazip * License : zlib, LGPL-2.1 with static linking exception Programming Lang: C, C++ Description : Qt/C++ wrapper over minizip - Version 1 (Qt5) QuaZip is the C++ wrapper for Gilles Vollant's ZIP/UNZIP package (AKA Minizip) using Trolltech's Qt library. While quazip is already packaged in Debian, it's version 0.9.1. The author of quazip has stated that versions 1.x are meant to be used alongside 0.x and not as an upgrade/replacement, like how Qt5 is still packaged alongside Qt6. This package is for versions 1.x of quazip built for Qt5. I'm packaging it at the request of Filippo Rusconi (context below). I do not plan to package this inside a team, unless one expresses interest. I will need a sponsor at first as I'm only a DM. Thanks, -- Ben Westover On 10/29/22 1:20 PM, Filippo Rusconi wrote: > Greetings, Ben, > > On Tue, Sep 13, 2022 at 03:40:13PM +0000, Ben Westover wrote: >> Hello, >> >> On 9/13/22 8:28 AM, Filippo Rusconi wrote: >>>> I'd support any attempt to move the current libquazip[1] away >>>> from Debian Med team where it is just by chance since it was a >>>> dependency of some of our packages. It does not make any sense to >>>> maintain it inside the Debian Med team and I would love to hand it >>>> over. All maintainers except me do not respond to pings any more >>>> and thus can be droped from the list of Uploaders. >>> >>> I understand that, let's take it away from Debian Med and put it in Debian >>> at >>> large. Ben, if you would do the update, then I'd go over it and upload it. >>> That >>> would be very good. >> >> As stated above, the existing QuaZip *0.9* package (libquazip) and my >> new QuaZip *1.3* package (libquazip1-qt6) are unrelated. While they are >> both QuaZip packages, they are separate since QuaZip 0.x and 1.x are >> supposed to coexist, much like Qt5 and Qt6. The orphaning of libquazip >> is unrelated to my new libquazip1-qt6 being uploaded. My new package is >> outside of any team. >> >> The correct procedure here is to orphan libquazip, and anyone who is >> interested can adopt it. Again, my new package libquazip1-qt6 is not >> related to the existing libquazip package or the Med Team. > > Yes, certainly. However, we have to support libquazip1.3 as a Qt5- and > Qt6-built > library. I would suggest that we make this package (Ben's) or the other > (Debian > med's) support both Qt libraries' versions. > > This would be pretty similar to what I have proposed for QCustomPlot ([0] any > comment about it, not a single comment about my previous emails, by the way). > > Ben, would you do this or would you accept pull requests ? > > Sincerely, > Filippo > > 0. https://salsa.debian.org/science-team/qcustomplot/-/tree/qt5-and-qt6 OpenPGP_signature Description: PGP signature
Bug#898972: Changing forks
Control: retitle -1 ITP: prismlauncher -- FOSS Minecraft launcher supporting multiple instances and accounts Due to some recent changes to PolyMC that I (and most people) don't agree with [1], I have decided to package the new Prism Launcher fork instead of PolyMC. Thanks, -- Ben Westover [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018255#16 OpenPGP_signature Description: PGP signature
Bug#861615: Changing forks
Due to some recent changes to PolyMC that I (and most people) don't agree with [1], I have decided to package the new Prism Launcher fork instead of PolyMC. Thanks, -- Ben Westover [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018255#16 OpenPGP_signature Description: PGP signature
Bug#898972: Changing forks
Control: retitle -1 ITP: polymc -- FOSS Minecraft launcher supporting multiple instances and accounts Due to some recent changes to PolyMC that I (and most people) don't agree with [1], I have decided to package the new Prism Launcher fork instead of PolyMC. Thanks, -- Ben Westover [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018255#16 OpenPGP_signature Description: PGP signature
Bug#1022747: RFS: prismlauncher/5.0+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts
Package: sponsorship-requests Severity: wishlist Control: block 898972 by -1 Dear mentors, I am looking for a sponsor for my package "prismlauncher": * Package name : prismlauncher Version : 5.0+ds-1 * URL : https://prismlauncher.org * License : GPL-3 and Apache-2.0 * Vcs : https://salsa.debian.org/BenTheTechGuy/prismlauncher Section : contrib/games The source builds the following binary packages: prismlauncher - FOSS Minecraft launcher supporting multiple instances and accounts To access further information about this package, please visit the following URL: https://mentors.debian.net/package/prismlauncher/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/contrib/p/prismlauncher/prismlauncher_5.0+ds-1.dsc Changes for the initial release: prismlauncher (5.0+ds-1) unstable; urgency=medium . * Initial Package (Closes: #898972) Regards, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1018255: Choosing new fork
Letting this simmer for about a week, I have decided to focus my efforts to packaging the new Prism Launcher fork instead of PolyMC, because it seems PolyMC is now a lost cause and the "real" upstream has moved on to Prism Launcher. Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1018255: RFS: polymc/1.4.1+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts
Bonjour Jérémy, On 10/18/22 4:24 PM, Jérémy Lal wrote: > > It seems that Lenny McLennigton, the main person behind upstream > went rouge in a way that is difficult > > to be aligned with Debian values (and CoC), as shown by their > response on [twitter]. > > Where in Debian is it stated that an open source project has to have a > Code of Conduct to be part of Debian ? I think he was saying the project doesn't align very well with the *Debian* Code of Conduct (https://debian.org/code_of_conduct). > I don't understand why the drama happening between upstream > project maintainers should concern Debian directly. To me the main issue is the fact that a known hostile entity has sole control over the meta severs that PolyMC interfaces with to download and execute arbitrary code, also potentially leaking personal information. I don't feel comfortable having that on my system, and I think most Debian users would agree. I don't at the moment want to support this current upstream by uploading their potentially hazardous package into Debian. -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#861615: RFS: polymc/1.4.1+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts
Hello, On Tue, 18 Oct 2022 11:03:09 +0200 Tobias Frost wrote: > There is currently some drama envoling with upstream, possibly this RFS/ITP > should be put on hold > until it is resolved (or maybe switched to one the forks that are currently > materializing [fork]) > > It seems that Lenny McLennigton, the main person behind upstream went rouge > in a way that is difficult > to be aligned with Debian values (and CoC), as shown by their response on > [twitter]. Disgusting. The moment I think I've found the perfect MultiMC fork with a thriving community and friendly upstream, the guy who set it up (and actually doesn't contribute all that much) turns out to be one of *those* people tarnishing our community, and ruins this work. I was suspicious of him right off the bat with the "sneed.church" email (some sort of 4chan cult, see [sneedacity] nightmare). For now I will remove my package from Mentors but keep the RFS/ITP open in hope that this issue is resolved in the near future. -- Ben Westover [sneedacity] https://github.com/tenacityteam/tenacity/issues/99 OpenPGP_signature Description: PGP signature
Bug#1018255: RFS: polymc/1.4.1+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts
Hello, On Tue, 18 Oct 2022 11:03:09 +0200 Tobias Frost wrote: > There is currently some drama envoling with upstream, possibly this RFS/ITP > should be put on hold > until it is resolved (or maybe switched to one the forks that are currently > materializing [fork]) > > It seems that Lenny McLennigton, the main person behind upstream went rouge > in a way that is difficult > to be aligned with Debian values (and CoC), as shown by their response on > [twitter]. Disgusting. The moment I think I've found the perfect MultiMC fork with a thriving community and friendly upstream, the guy who set it up (and actually doesn't contribute all that much) turns out to be one of *those* people tarnishing our community, and ruins this work. I was suspicious of him right off the bat with the "sneed.church" email (some sort of 4chan cult, see [sneedacity] nightmare). For now I will remove my package from Mentors but keep the RFS/ITP open in hope that this issue is resolved in the near future. -- Ben Westover [sneedacity] https://github.com/tenacityteam/tenacity/issues/99 OpenPGP_signature Description: PGP signature
Bug#1021230: ITP: golang-github-abiosoft-ishell -- Library for creating interactive cli applications
Package: wnpp Severity: wishlist Owner: Ben Westover X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-abiosoft-ishell Version : 2.0.2-1 Upstream Author : Abiola Ibrahim * URL : https://github.com/abiosoft/ishell * License : Expat Programming Lang: Go Description : Library for creating interactive cli applications ishell is an interactive shell library for creating interactive cli applications. I am packaging this library because it's a dependency of proton-bridge. -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1021228: ITP: golang-github-flynn-archive-go-shlex -- Fork of go-shlex from Google Code
Package: wnpp Severity: wishlist Owner: Ben Westover X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-flynn-archive-go-shlex Version : 0.0~git20150515.3f9db97-1 Upstream Author : Google Inc. * URL : https://github.com/flynn-archive/go-shlex * License : Apache-2.0 Programming Lang: Go Description : Fork of go-shlex from Google Code go-shlex is a simple lexer for go that supports shell-style quoting, commenting, and escaping. I am packaging this library because it's a dependency of proton-bridge. -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1021226: ITP: golang-github-chzyer-test -- test
Package: wnpp Severity: wishlist Owner: Ben Westover X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-chzyer-test Version : 1.0.0-1 Upstream Author : ChenYe * URL : https://github.com/chzyer/test * License : Expat Programming Lang: Go Description : test test I am packaging this library because it's a dependency of proton-bridge. -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1021225: ITP: golang-github-chzyer-logex -- Golang log library that supports tracking and level
Package: wnpp Severity: wishlist Owner: Ben Westover X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-chzyer-logex Version : 1.2.1-1 Upstream Author : ChenYe * URL : https://github.com/chzyer/logex * License : Expat Programming Lang: Go Description : Golang log library, supporting tracking and level Logex is a Golang log library that supports tracing and level, wrapped by the standard log library. I am packaging this library because it's a dependency of proton-bridge. -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1021224: ITP: golang-github-abiosoft-readline -- Pure Go implementation for GNU-Readline kind library
Package: wnpp Severity: wishlist Owner: Ben Westover X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-abiosoft-readline Version : 0.0~git20180607.155bce2-1 Upstream Author : Abiola Ibrahim * URL : https://github.com/abiosoft/readline * License : Expat Programming Lang: Go Description : Pure Go implementation of GNU-Readline kind library This is powerful readline Go library for Linux, macOS, Windows, Solaris, and more. I am packaging this library because it's a dependency of proton-bridge. -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1020450: ITP: golang-github-allan-simon-go-singleinstance -- Run only one instance of a software
Package: wnpp Severity: wishlist Owner: Ben Westover X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-allan-simon-go-singleinstance Version : 1.0.0-1 Upstream Author : Allan Simon * URL : https://github.com/allan-simon/go-singleinstance * License : Expat Programming Lang: Go Description : Have only one instance of a software running Cross plateform library to have only one instance of a software (based on python's tendo (https://github.com/pycontribs/tendo/blob/master/tendo/singleton.py)). I am packaging this library because it's a dependency of proton-bridge. -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1020391: mesa: Updates to 22.2 RCs cause blank screen on some VirtIO graphics
Source: mesa X-Debbugs-Cc: m...@benthetechguy.net Version: 22.2.0~rc1-1 Severity: important Dear Maintainer, After updating to mesa 22.2.0~rc1-1 on my UTM virtual machine on macOS (which uses VirtIO graphics), LightDM and anything else using Mesa is just completely black except for a cursor. This is still present in the latest version. The default graphics option of UTM is virtio-ramfb-gl, which is GPU accelerated; I tested virtio-ramfb, and it doesn't have this issue, though it's not ideal as I can't resize the window and it's not GPU accelerated. I tested all of the *-gl accelerated graphics options, and they all have this issue. I also tested a normal virt-manager VM on Linux, and it doesn't have this issue. -- Ben Westover P.S. Also reported in #1017499, but turned out to be a separate issue. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: arm64 (aarch64) Kernel: Linux 5.19.0-1-arm64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled OpenPGP_signature Description: PGP signature
Bug#1016936: dwz: fails while building assaultcube
Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=27375 OK, so it turns out this error is due to Clang's adoption of DWARFv5 [1] which dwz doesn't fully support yet [2]. Until that is fixed, the issue can be worked around by using DWARFv4 by adding `-gdwarf-4` to flags. -- Ben Westover [1] https://www.phoronix.com/news/LLVM-Clang-DWARFv5-Default [2] https://sourceware.org/bugzilla/show_bug.cgi?id=24726 OpenPGP_signature Description: OpenPGP digital signature
Bug#1016936: dwz: fails while building assaultcube
Control: retitle 1016936 dwz: Unknown debugging section .debug_addr causes some builds to fail Control: tags 1016936 + upstream Hello, This error also occurred for me when building PolyMC under Clang, but not GCC. It seems this problem is common for many Clang builds [1]. Fedora also seems to be having issues with this; Thus, I'm retitling this bug to be more generic, and adding an upstream tag. I will create a bug when my Bugzilla account creation request is approved by the admin. Thanks, -- Ben Westover [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997080#41 OpenPGP_signature Description: OpenPGP digital signature
Bug#1018255: RFS: polymc/1.4.1+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "polymc": * Package name: polymc Version : 1.4.1+ds-1 * URL : https://polymc.org * License : LGPL-3, LGPL-2.1, GPL-3, GPL-2, BSD-3-clause, BSD-2-clause, Apache-2.0, zlib, BSL-1.0, ISC, Expat * Vcs : https://salsa.debian.org/BenTheTechGuy/polymc Section : contrib/games The source builds the following binary package: polymc - FOSS Minecraft launcher supporting multiple instances and accounts To access further information about this package, please visit the following URL: https://mentors.debian.net/package/polymc/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/contrib/p/polymc/polymc_1.4.1+ds-1.dsc Changes for the initial release: polymc (1.4.1+ds-1) unstable; urgency=medium . * Initial Package (Closes: #898972) Regards, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1017499: Upstream bug report
tags 1017499 + upstream -- I was about to report the bug upstream, but it looks like Leandro beat me to it. https://gitlab.freedesktop.org/mesa/mesa/-/issues/7117 -- Ben Westover signature.asc Description: PGP signature
Bug#898972: Are you still packaging this?
owner 898972 ! retitle 898972 ITP: polymc -- FOSS Minecraft launcher supporting multiple instances and accounts -- * Package name: polymc Version : 1.4.1 Upstream Author : PolyMC Contributors * URL : https://polymc.org * License : GPL-3 and Apache-2.0 Programming Lang: C++ -- I have decided to package PolyMC instead of MultiMC. It's much more friendly to distributions using its name, and solves the Azure issue by leaving its API key available by default. This in general seems to be a much better project with more features and a nicer community. Thank you Zeb for informing me of this project! -- Ben Westover P.S. Forwarding this message that he forgot to copy the bug address in: On 8/20/22 3:33 PM, Zebulon McCorkle wrote: > No, I’m not still working in it. Honestly I forgot all about this > particular packaging project haha! I agree with your points there - you > might be better off packaging PolyMC, they formed off from MultiMC due > to upstream policies like this. > > On Sat, Aug 20, 2022 at 12:58 PM Ben Westover wrote: > > [snip] OpenPGP_signature Description: OpenPGP digital signature
Bug#898972: Are you still packaging this?
Hello, Are you still planning on packaging this? Your package was removed from Mentors years ago. If you don't want to do it anymore, I can take over. One thing to note is upstream's policy on others compiling their source code and trying to use the MultiMC name: > We keep Launcher open source because we think it's important to be > able to see the source code for a project like this, and we do so > using the Apache license. > > The license gives you access to the source MultiMC is built from, but: > * Not the name, logo and other branding. > * Not the API tokens required to talk to services the launcher >depends on. > > You must provide your own branding if you want to distribute your own > builds. > > You will also have to register your own app on Azure to be able to > handle Microsoft account logins. > > If you decide to fork the project, a mention of its origins in the > About dialog and the license is acceptable. However, it should be > abundantly clear that the project is a fork *without* implying that > you have our blessing. Not only will we need to make our own branding for a Debian MultiMC package (like iceweasel), but we will also need to create an Azure application if we want to allow players to log in using their Microsoft account (the majority of current Minecraft players who have migrated). I have attached a logo I created for fun, but we will need to figure out this Azure issue. Regards -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1017499: Mentioned issue is not related
Correction: Issue #7071 is *not* related to this issue; it's a similar issue, but specific to Vivante hardware and the etnaviv driver. -- Ben Westover signature.asc Description: PGP signature
Bug#1017499: Related upstream issue
Upstream issue #7071 [1] seems to be related, with similar artifacts and the issue being first reported in Mobian, which shares the same mesa package as Debian. If this is true, the offending commit would be 53445284a427f79e94607dc4ca2f8bd8ac293356. -- Ben Westover [1] https://gitlab.freedesktop.org/mesa/mesa/-/issues/7071 OpenPGP_signature Description: OpenPGP digital signature
Bug#1017499: mesa: Updates to 22.2 RCs cause artifacts on nouveau and blank screen on VirtIO
On 8/16/22 11:57 PM, Ben Westover wrote: > I also updated my Debian virtual machine in UTM on macOS, which uses > VirtIO graphics, and LightDM is just completely black there except for > a cursor. The default graphics option of UTM is virtio-ramfb-gl, which is GPU accelerated. I just tested virtio-ramfb, and it doesn't have this issue, though it's not ideal as I can't resize the window and it's not GPU accelerated. I tested all of the *-gl accelerated graphics options, and they all have this issue. I also tested a normal virt-manager VM on Linux, and it doesn't have this issue. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1017511: pacman-package-manager: fails to build reproducibly and embeds detected path in scripts
Hello Luca, On 8/17/22 5:56 AM, Luca Boccassi wrote: > It looks like the path to sh is detected at build time and embedded in > a bunch of scripts, which is bad as it breaks reproducibility, and also > breaks when building on usr-merged systems, which is expressely against > the Tech Committee resolution on this matter: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/pacman-package-manager.html > > 1 #!/bin/bash > 1 #!/usr/bin/bash > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110 Ah, thank you for this! Discovering the root of pacman's failure to build reproducibly was on my to-do list, but I have been very busy for the past week. Now that I know what to look for, this shouldn't be too hard to fix. Thanks, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1017499: mesa: Updates to 22.2 RCs cause artifacts on nouveau and blank screen on VirtIO
Source: mesa Version: 22.2.0~rc1-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Maintainer, After updating to mesa 22.2.0~rc1-1 on my 2008 Dell Precision laptop with a Quadro FX 1700M GPU, I began experiencing artifacts [1] as soon as lightdm started, and they still remained after launching Xfce [2]. I also updated my Debian virtual machine in UTM on macOS, which uses VirtIO graphics, and LightDM is just completely black there except for a cursor. After updating to 22.2.0~rc2-1, the nouveau laptop's artifacts were limited to only foreground objects, such as the login box of lightdm [3] or the menu and panel of Xfce [4]. The virtual machine stayed the same. - -- Ben Westover [1] https://i.ibb.co/mcw7phd/IMG-20220816-231123.jpg [2] https://i.ibb.co/QpRZMwV/IMG-20220816-231401.jpg [3] https://i.ibb.co/y5F1dsJ/IMG-20220816-233627.jpg [4] https://i.ibb.co/7z3X5sy/IMG-20220816-233611.jpg - -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEOGnacqRhdU6eNmtFwxHF9U6JtpgFAmL8ZzkACgkQwxHF9U6J tphg4A/9Fv5e8+V6K2BAXqeoJQPI+JPRWEqe4dW7XnEkvZAWPDw9t6SG9bJYZMwK axwxL+Iobj90WyxGtsUbAjXjFbNJJ0gPorgA/0d83KpPzLwJEDgk1yZKs/vraO64 secD1BBQ04X07NEhZoTzNKbqrUCJUmgZk7R21OfAzTBXdYmMk7CAa4WVoVSgYNcu VP0+GsvmQhETgidDFa4QfrzT4bKEzWo/Vcp3jXWM6u+ovrVtYKvbovE9/M3kRMyJ 0PEZfMYxkq54ggIdT4dEbh7wYN1eGvfubodQ6pDyk+lxaZ00dVZdBcmGhH3RQGLz AClLDr7ZQ+dXz6/HZgd1KXx1PEteI7Cx58yUbJkDcGXS9ddbwfXDLdJYZ9rFYWet CMFuBILn15FxzpjObNjQANzc8xzFAUwMGjq5g0HcAByTslvDipkZtz1Gc5lRyygs ixH8WKWh6dJv54n8KMppjLsr9miJq5Azf82x2AlD5A2Z4xN1zAkagjeijZVZGJwn t8gy2TwK0GsJET2M/hlLRD/1qbPpB4BrUJJIqSTMuNOPUQyRvu0MlcQv8rVYmXCi E9I6o8nG/4k/MeSh/YFXdk49iet1w1fbwQ2GaIvA8FdS/kd7AEQD5p1rW4hcIbBQ ogaKc+2IP2ZHjsr1i5oH7eaE3GgYLRR8Ym5oKKh8Z4fh5oiMiCM= =DQZd -END PGP SIGNATURE-
Bug#1016714: arch-install-scripts: Include pacstrap in arch-install-scripts since pacman is now in Debian
Hello, On 8/5/22 16:39, Unit 193 wrote: Yep, that's the plan. I was waiting on pacman-package-manager to pass NEW before I did the changes, so I haven't picked up the new version yet. Perfect. It just passed NEW about three hours ago, so it's not on many mirrors yet. A source-only reupload should be occurring soon to get the package built on buildds so it can migrate to testing. I plan to only have pacman-package-manager in suggests though as that's not what I use arch-install-scripts for myself, and I presume others likewise. That sounds like a good idea. pacstrap also requires a mirrorlist file, which I don't see a point to package in Debian, so putting it in Suggests is a good idea since pacstrap will be a more "advanced" use. It would be perfect to put "Closes: #1016714" in the changelog entry of your new version, so this bug will be automatically closed upon release. Thanks, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1016714: arch-install-scripts: Include pacstrap in arch-install-scripts since pacman is now in Debian
Package: arch-install-scripts X-Debbugs-Cc: kwestover...@gmail.com Version: 25-1 Severity: minor Dear Maintainer, pacstrap is currently not included in the arch-install-scripts package for Debian, which makes sense since it uses pacman. However, pacman as of today is in Debian as the package pacman-package-manager, so now it should be possible for pacstrap to be added. Version 26 of arch-install-scripts was also released last week, so it's currently a good time to update and include pacstrap at the same time. Thanks, -- Ben Westover -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: arm64 (aarch64) Kernel: Linux 5.18.0-3-arm64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information OpenPGP_signature Description: OpenPGP digital signature
Bug#1016465: ITP: python-ssdpy -- Lightweight, compatible SSDP library for Python
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Ben Westover X-Debbugs-Cc: kwestover...@gmail.com Severity: wishlist * Package name: python-ssdpy Version : 0.4.1 Upstream Author : Moshi Binyamini * URL : https://github.com/MoshiBin/ssdpy * License : Expat Programming Lang: Python Description : Lightweight, compatible SSDP library for Python SSDPy is a lightweight implementation of SSDP (Simple Service Discovery Protocol). It is designed for ease of use and high compatibility with the protocol in real-life use. It supports both the IETF and UPnP versions of the protocol. I am packaging this library because a program I'm developing depends on it. I will be maintaining the page inside the Python team. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1006020: RFS: pacman-package-manager/6.0.1-1 [ITP] -- Simple library-based package manager
Hi Luca, On 7/29/22 5:50 AM, Luca Boccassi wrote: > Still a couple of Lintian warnings to fix, then you can finalize the > changelog and I'll upload: > > I: pacman-package-manager source: duplicate-long-description libalpm-dev > libalpm13 [debian/control] > I: libalpm-dev: extended-description-is-probably-too-short Fixed > I: libalpm13: extended-description-is-probably-too-short There's not really much more information to say on libalpm; I don't know what else to put in the description without making it a word salad. > I: libalpm13: package-contains-empty-directory [usr/share/libalpm/hooks/] > I: makepkg: package-contains-empty-directory [usr/share/makepkg-template/] Fixed > This one doesn't need to be fixed in the package, just send a patch > upstream and it can be picked up in the next version: > > I: pacman-package-manager: typo-in-manual-page "allows to" "allows one to" > [usr/share/man/man8/pacman.8.gz:264] Sent the patch upstream. I didn't even know about these Lintian tags since lintian by default only shows warnings and above (these are info tags). I've updated my machine's Lintian config to show me everything, even down to pedantic. My (minor) changes have been pushed to Salsa and Mentors. Thanks, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1006020: RFS: pacman-package-manager/6.0.1-1 [ITP] -- Simple library-based package manager
Hello Luca and Michel,
On 7/28/22 5:50 PM, Michel Alexandre Salim wrote:
> Hi Ben,
> I was independently working on pacman, and (thanks to the name
> collision with the existing pacman package) didn't notice this until
> it's mostly done.
That existing package is orphaned anyway, so it's annoying that it's
already there and not even being maintained. I do think it's still a
good idea to keep the current package name so people don't get confused
and accidentally install a potentially dangerous package manager for
another distribution instead of an arcade game.
> My use case is helping make systemd/mkosi CI easier (since it's hosted
> on GitHub, which provides Ubuntu LTS builders) - I'll flag this to
> some relevant people so they can help get this sponsored.
>
> PS archlinux-keyring is on its way to unstable, and per some feedback
> the keyring target directory is moved to the standard Debian path:
>
> https://salsa.debian.org/michel/archlinux-keyring/-/blob/main/debian
> /patches/use_std_keyring_dir.diff
>
> might want to apply this to your pacman, and configure pacman to use
> this path:
>
> https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/11
Okay, I've added the patch to my package and configured the keyringdir
option in debian/rules.
On 7/28/22 6:27 PM, Luca Boccassi wrote:
> Hi,
>
> I can sponsor this.
>
> A few remarks, aside from the keyring change mentioned by Michel:
>
> - all the doc build-dependencies (asciidoc, doxygen, help2man) can be
> marked with so that nodoc builds can be done
> - are curl and fakechroot really needed to build the package, or are
> they just used by self tests? if they are used only by tests, mark them
> as
> - is pkgconf really needed instead of pkgconfig, which is the default?
> - you need to add a libalpm-dev and ship the headers, pkgconfig file,
> unversioned .so and manpage in it, instead of in libalpm13, and remove
> the lintian override
> - libalpm13 is missing Pre-Depends: ${misc:Pre-Depends}
> - no need to specify the libarchive-tools and libgpgme11 dependencies
> on libalpm13, they will be autogenerated
> - does libalpm13 really need to depend on the binary curl executable?
Thanks, all of those have been fixed.
> - makepkg should not depend on build-essential nor on sudo
I was under the impression that makepkg depended on sudo, but after a
deeper look into the code, it appears to fall back on su if sudo is not
detected. I put build-essential there since makepkg expects base-devel,
the Arch Linux equivalent of build-essential, to be installed. I've now
removed sudo from Depends and moved build-essential to Recommends since
in most cases you would want it installed but it's not required.
> - no need to manually specify the dependency on libalpm13 in makepkg,
> it will be autogenerated
> - libalpm13 is missing the symbols file, you can generate it after
> building the library with:
>dpkg-gensymbols -plibalpm13
> -edebian/tmp/usr/lib/x86_64-linux-gnu/libalpm.so.13.0.1
> -Odebian/libalpm13.symbols
> - makepkg is missing a dependency on ${perl:Depends}
Fixed
> - are you sure all of these can run on GNU/Hurd and debian/kFreeBSD? If
> not, use 'linux-any' instead of 'any' as the architecture
Funny you should say that; I actually have a Debian GNU/kFreeBSD system
that I installed out of curiosity last year. When I was originally
making this package, I tested it out on that system and it worked.
> - it is not necessary anymore to specify the build system in
> debian/rules, meson is autodetected
> - use execute_before_dh_auto_clean instead of override_
Fixed
> - 228 tests fail when running in a pbuilder chroot, this is a strong
> hint that the build might fail once uploaded
I use sbuild instead of pbuilder since it's considered to be legacy at
this point. As Michel noted, these failures are solved by two additional
build depends (one of which you should've already had) which I've added.
> - you should try and fix the reproducible build, rather than disabling
> it in the CI
I've tested reproducibility with reprotest and it's perfectly
reproducible. Salsa CI fails a bunch of tests on its second
reproducibility build, and I haven't been able to find the root cause.
It's been suggested to me that Salsa CI's reprotest job might be faulty.
I'll do some more research into the topic when I have time.
> - the GPL-2+ in debian/copyright says in the last paragraph:
>"On Debian systems, the full text of the GNU General Public
> License version 3 can be found in the file"
> instead of version 2
Fixed
Thank you both for your interest and deep review of this package! I
learned a lot of minor Debian things that I didn't know about before.
I've published my changes to Salsa and Mentors. You've helped me to
address the weaker points of my package th
Bug#1015830: ITP: python-update-checker -- Python module that checks for package updates
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Ben Westover X-Debbugs-Cc: kwestover...@gmail.com Severity: wishlist * Package name: python-update-checker Version : 0.18.0 Upstream Author : Bryce Boe * URL : bbzbr...@gmail.com * License : BSD-2-clause Programming Lang: Python Description : Python module that checks for package updates update_checker is a python module that checks for package updates. Only whitelisted packages can be checked for updates. Contact update_checker's author for information on adding a package to the whitelist. I am packaging this module because it is a dependency of praw, which I am updating. I will maintain it inside the Python team. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1014350: Disowning the package
Control: retitle -1 RFP: nuxhash -- NiceHash cryptocurrency mining client for Linux Control: noowner -1 I no longer own an NVIDIA graphics card, so I will not be able to fully test this package well outside of making sure it builds. The package was ready for upload, but never got sponsored. It's still available in Salsa at https://salsa.debian.org/python-team/packages/nuxhash. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1014574: sbuild-debian-developer-setup: Don't alias to sid/UNRELEASED if suite is not unstable
Package: sbuild-debian-developer-setup Version: 0.83.1 Severity: normal Tags: upstream Dear Maintainer, sbuild-debian-developer-setup aliases all schroots to sid and UNRELEASED. This can cause unexpected problems when using a suite other than unstable. sbuild-debian-developer-setup should only alias to sid if the suite is set to unstable, and only alias to UNRELEASED if the suite is set to unstable or there are no other existing sbuild chroots. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sbuild-debian-developer-setup depends on: ii apt-cacher-ng 3.7.4-1+b1 ii cron [cron-daemon] 3.0pl1-145 ii perl5.34.0-5 ii sbuild 0.83.1 ii schroot 1.6.10-16 sbuild-debian-developer-setup recommends no packages. sbuild-debian-developer-setup suggests no packages. -- no debconf information
Bug#1014573: sbuild-debian-developer-setup: Add option to use a specific mirror instead of apt-cacher-ng
Package: sbuild-debian-developer-setup Version: 0.83.1 Severity: normal Tags: upstream Dear Maintainer, I was trying to create an Ubuntu schroot for sbuild using the command sbuild-debian-developer-setup --distribution=ubuntu --suite=jammy and debootstrap failed because it tried to use apt-cacher-ng, which doesn't work for Ubuntu if you're on Debian, and vice versa. This would be solved with an option that can specify the mirror to use in place of apt-cacher-ng. Alternatively, sbuild-debian-developer-setup could do a sanity check on apt-cacher-ng, and if it fails, switch to http://deb.debian.org/debian or http://archive.ubuntu.com/ubuntu. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sbuild-debian-developer-setup depends on: ii apt-cacher-ng 3.7.4-1+b1 ii cron [cron-daemon] 3.0pl1-145 ii perl5.34.0-5 ii sbuild 0.83.1 ii schroot 1.6.10-16 sbuild-debian-developer-setup recommends no packages. sbuild-debian-developer-setup suggests no packages. -- no debconf information
Bug#1014367: ITP: xmrig-cuda -- NVIDIA CUDA plugin for XMRig
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Ben Westover X-Debbugs-Cc: kwestover...@gmail.com Severity: wishlist * Package name: xmrig-cuda Version : 6.17.0 Upstream Author : XMRig * URL : https://xmrig.com * License : GPL-3+ Programming Lang: C, C++, CUDA Description : NVIDIA CUDA plugin for XMRig xmrig-cuda is a CUDA plugin for XMRig that adds support for CUDA mining on NVIDIA graphics cards, which is faster than OpenCL in most cases. This package will be in contrib, because while xmrig-cuda itself is free, it depends on CUDA and the proprietary NVIDIA drivers which are both in non-free. I will not be maintaining this package within a team, so I will need a sponsor as I am not a DD. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1014350: ITP: nuxhash -- NiceHash cryptocurrency mining client for Linux
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Ben Westover X-Debbugs-Cc: kwestover...@gmail.com Severity: wishlist * Package name: nuxhash Version : None (program is in beta, using git HEAD currently) Upstream Author : Ryan Young * URL : https://github.com/YoRyan/nuxhash * License : GPL-3 Programming Lang: Python Description : NiceHash cryptocurrency mining client for Linux nuxhash is a NiceHash cryptocurrency mining client for Linux. It consists of a headless daemon and an optional wxPython-based GUI. I am packaging this so I can mine with NiceHash on my Debian machine. This package will be in contrib because while the package itself is free, it depends on NVIDIA's proprietary drivers and CUDA, which are in non-free. It also downloads and executes a proprietary miner called Excavator. I will maintain this package inside the Python team. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1014263: ITP: mtkclient -- Unofficial MTK reverse engineering and flash tool
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Ben Westover X-Debbugs-Cc: kwestover...@gmail.com Severity: wishlist * Package name: mtkclient Version : 1.52 Upstream Author : Bjoern Kerler * URL : https://github.com/bkerler/mtkclient * License : Expat Programming Lang: Python Description : Unofficial MTK reverse engineering and flash tool mtkclient is a tool for exploitation, reading/writing flash, and other interesting things on devices with MediaTek SoCs. I am packaging this tool because I use it to install custom operating systems on my LG K40, which normally has no way to flash new images or unlock the bootloader. I plan to maintain this package in the Python team. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#898333: CMake trouble
It turns out that the debian/rules line works if I remove the start and end characters (in this case the quotes). This should either be changed so that --ignore-line and the debian/rules string use the same format, or it should be documented. OpenPGP_signature Description: OpenPGP digital signature
Bug#898333: CMake trouble
Hello Simon, On 7/2/22 12:41 AM, Simon Ruderich wrote: to quote the man-page: Ignore lines matching the given Perl regex. regex is automatically anchored at the beginning and end of the line to prevent false negatives. NOTE: Not the input lines are checked, but the lines which are displayed in warnings (which have line continuation resolved). Something like --ignore-line '/usr/bin/cc.*\S+\.S' should work. Yes, that worked well. Thanks for the hint about the anchoring; I did read the man page, but it seems I missed that part. There is a new problem, however. I was testing --ignore-line so I could eventually put the resulting regex in debian/rules as per this part of the man page: To suppress false positives you can embed the following string in the build log: blhc: ignore-line-regexp: REGEXP All lines fully matching REGEXP (see --ignore-line for details) will be ignored. Please use this feature sparingly so that missing flags are not overlooked. If you find false positives which affect more packages please report a bug. To generate this string simply use echo in "debian/rules"; make sure to use @ to suppress the echo command itself as it could also trigger a false positive. If the build process takes a long time edit the ".build" file in place and tweak the ignore string until blhc --all --debian package.build no longer reports any false positives. I added this line to debian/rules: @echo "blhc: ignore-line-regexp: '/usr/bin/cc.*\S+\.S'" and also confirmed that it was echoed in the build log, but blhc is still triggered by those lines even though the regex is identical to one that worked with --ignore-line. What am I doing wrong this time? Thanks, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#898333: CMake trouble
Hello, I ran into this same problem while trying to package XMRig, which uses CMake, so I don't know how to just make it use CPPFLAGS for Assembly. CPPFLAGS missing (-D_FORTIFY_SOURCE=2): /usr/bin/cc -DCL_TARGET_OPENCL_VERSION=200 -DCL_USE_DEPRECATED_OPENCL_1_2_APIS -DHAVE_BUILTIN_CLEAR_CACHE -DHAVE_ROTR -DHAVE_SYSLOG_H -DRAPIDJSON_SSE2 -DUNICODE -DXMRIG_64_BIT -DXMRIG_ALGO_ARGON2 -DXMRIG_ALGO_CN_FEMTO -DXMRIG_ALGO_CN_HEAVY -DXMRIG_ALGO_CN_LITE -DXMRIG_ALGO_CN_PICO -DXMRIG_ALGO_GHOSTRIDER -DXMRIG_ALGO_KAWPOW -DXMRIG_ALGO_RANDOMX -DXMRIG_FEATURE_ADL -DXMRIG_FEATURE_API -DXMRIG_FEATURE_ASM -DXMRIG_FEATURE_BENCHMARK -DXMRIG_FEATURE_CUDA -DXMRIG_FEATURE_DMI -DXMRIG_FEATURE_ENV -DXMRIG_FEATURE_HTTP -DXMRIG_FEATURE_HWLOC -DXMRIG_FEATURE_MSR -DXMRIG_FEATURE_NVML -DXMRIG_FEATURE_OPENCL -DXMRIG_FEATURE_SSE4_1 -DXMRIG_FEATURE_TLS -DXMRIG_FIX_RYZEN -DXMRIG_JSON_SINGLE_LINE_ARRAY -DXMRIG_MINER_PROJECT -DXMRIG_OS_LINUX -DXMRIG_OS_UNIX -DXMRIG_STRICT_OPENCL_CACHE -DXMRIG_VAES -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D__STDC_FORMAT_MACROS -I/usr/include -I/<>/src -I/<>/src/3rdparty -o CMakeFiles/xmrig-asm.dir/src/crypto/cn/asm/cn_main_loop.S.o -c /<>/src/crypto/cn/asm/cn_main_loop.S CPPFLAGS missing (-D_FORTIFY_SOURCE=2): /usr/bin/cc -DCL_TARGET_OPENCL_VERSION=200 -DCL_USE_DEPRECATED_OPENCL_1_2_APIS -DHAVE_BUILTIN_CLEAR_CACHE -DHAVE_ROTR -DHAVE_SYSLOG_H -DRAPIDJSON_SSE2 -DUNICODE -DXMRIG_64_BIT -DXMRIG_ALGO_ARGON2 -DXMRIG_ALGO_CN_FEMTO -DXMRIG_ALGO_CN_HEAVY -DXMRIG_ALGO_CN_LITE -DXMRIG_ALGO_CN_PICO -DXMRIG_ALGO_GHOSTRIDER -DXMRIG_ALGO_KAWPOW -DXMRIG_ALGO_RANDOMX -DXMRIG_FEATURE_ADL -DXMRIG_FEATURE_API -DXMRIG_FEATURE_ASM -DXMRIG_FEATURE_BENCHMARK -DXMRIG_FEATURE_CUDA -DXMRIG_FEATURE_DMI -DXMRIG_FEATURE_ENV -DXMRIG_FEATURE_HTTP -DXMRIG_FEATURE_HWLOC -DXMRIG_FEATURE_MSR -DXMRIG_FEATURE_NVML -DXMRIG_FEATURE_OPENCL -DXMRIG_FEATURE_SSE4_1 -DXMRIG_FEATURE_TLS -DXMRIG_FIX_RYZEN -DXMRIG_JSON_SINGLE_LINE_ARRAY -DXMRIG_MINER_PROJECT -DXMRIG_OS_LINUX -DXMRIG_OS_UNIX -DXMRIG_STRICT_OPENCL_CACHE -DXMRIG_VAES -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D__STDC_FORMAT_MACROS -I/usr/include -I/<>/src -I/<>/src/3rdparty -o CMakeFiles/xmrig-asm.dir/src/crypto/cn/asm/CryptonightR_template.S.o -c /<>/src/crypto/cn/asm/CryptonightR_template.S I attempted to make blhc ignore this by echoing "blhc: ignore-line-regexp: \.S", but it didn't work. I also tried to run blhc with the actual --ignore-line flag, but it was still picking up those lines. I even did a simplified "--ignore-line asm", but it still doesn't work. Just in case, I tried again with "/asm/". This is all valid Perl regex, but it seems like blhc just isn't working at all here. Am I doing something wrong? Regards -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1001907: Progress?
Hello Juri, Have you had any progress on your packaging of pmbootstrap? If not, I'd be happy to help you finish the job. Regards -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1013168: ITP: python-freenom -- Unofficial Python implementation of Freenom API
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Ben Westover X-Debbugs-Cc: kwestover...@gmail.com Severity: wishlist * Package name: python-freenom Version : 0.0.2 Upstream Author : Nikolay Shamanovich * URL : https://github.com/Shm013/freenom-dns * License : Expat Programming Lang: Python Description : Unofficial Python implementation of Freenom API freenom-dns is an unofficial Python implementation of the Freenom API used to manage freenom.com DNS records. I am packaging this because it's a dependency of certbot-dns-freenom, which I am also packaging. I will maintain this package in the Python team. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
