Bug#1079610: ITP: pass-report -- pass extension to report age and length of passwords
Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬)
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: pass-report
Version : 0.0.4
Upstream Contact: Kevin Decherf
* URL : https://github.com/Kdecherf/pass-report
* License : GPL-3+
Programming Lang: bash
Description : pass extension to report age and length of passwords
A pass extension that shows the date and age of the last change of a
set of passwords, and an indication of their length.
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
Re: DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?
Il 25/08/2024 08:27, Gioele Barabucci ha scritto: On 25/08/24 01:46, gregor herrmann wrote: Many of the packages are trivial, so updating them (including autopkgtests and blhc and lintian and whatnot) doesn't take longer than 5 minutes. So I can decide to wait for salsa CI for 10 minutes or update 2 more packages in the same time. (Or try to context switch and keep a stack of where I was etc.) This is why "tag2upload once pipeline passes" is needed. (And more runners.) Actually I push keeping "UNRELEASED" even in cases where is near sure to be ready because I want see salsa CI result and do fixes/improvements if needed before release, shortly after in major of case I did a release commit with only finalize the d/changelog and I skip salsa CI on that (with "-o ci.skip" on git push) to avoid waste salsa CI resource for same result of the previous. Will tag2upload be usable in that case (with CI skipped on latest commit with only finalize of d/changelog, and successfull of the previous) or will there be a need for salsa CI successfully completedon the specific release commit? OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1079616: ITP: pass-extension-copyq -- pass extension to support copyq
Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬)
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: pass-extension-copyq
Version : 0~20240825
Upstream Contact: Volkan Yazici
* URL : https://github.com/vy/pass-extension-copyq
* License : Apache-2
Programming Lang: bash
Description : pass extension to support copyq
A pass extension that copies a stored password using copyq with a certain
timeout. After timeout, the clipboard is either restored to its previous
state or cleared.
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
Re: DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?
On Sun, 25 Aug 2024 13:31:45 +0200, Fabio Fantoni wrote: >Actually I push keeping "UNRELEASED" even in cases where is near sure to >be ready because I want see salsa CI result and do fixes/improvements if >needed before release, shortly after in major of case I did a release >commit with only finalize the d/changelog and I skip salsa CI on that >(with "-o ci.skip" on git push) to avoid waste salsa CI resource for >same result of the previous. > >Will tag2upload be usable in that case (with CI skipped on latest commit >with only finalize of d/changelog, and successfull of the previous) or >will there be a need for salsa CI successfully completedon the specific >release commit? CI could skip if only changelog changed. That would be helpful for my packages and my workflow as well. Greetings Marc -- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: RFC: packages that can be installed by the user but not used as build dependencies
On Tue Aug 20, 2024 at 12:17 AM BST, Lisandro Damián Nicanor Pérez Meyer wrote: > But users would love to have something like 'qt6-full-dev'. And the > reason we never provided them with this meta-package is that package > maintainers would use it almost everywhere, dragging the whole Qt > installation on each package depending on it... This is a _huge_ waste > of resources and buildd time (or is it not??) I think it would be better to use social methods to prevent maintainers from doing this, rather than technical ones. > At one point I thought of adding a Lintian test checking for this kind > of usage, but first and foremost I would like to know if you think > this is a viable/acceptable idea, maybe even adding a special section > in our policy. I like the idea of a Lintian check, assuming Lintian accepts checks which don't correspond to Policy. I'm not sure it makes sense to try and encode this restriction in Policy itself. Best wishes, -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Re: Intent to MBF: move from fuse to fuse3
Hi, Thanks for adding me, I can't follow -devel. On Wed, Aug 21, 2024 at 11:24 PM Chris Hofstaedtler wrote: > Updated MBF text proposal: [...] > Does that sound good? This sounds right to me, except that the fuse package should be removed in the Trixie release already. It was obsoleted more than five years ago and it's time to move on. The libfuse2 package might remain, but dependent packages had enough time to migrate already. Unfortunately it is known in other distributions as well [1] that for some reason (laziness probably) projects don't migrate to fuse3. Regards, Laszlo/GCS [1] https://github.com/NixOS/nixpkgs/issues/150502#issuecomment-2017295190
New loong64 porterbox available
Hello, thanks to a generous donation by Loongson Technology Corporation Limited, we now have a beefy porterbox for Debian's new loong64 port. The new server features two Loongson 3C5000 processors with 16 cores each clocked at 2.20 GHz, 2 TB of disk space for home directories as well as 256 GB of RAM [1]. The machine is called shenzhou and reachable over IPv6-only as shenzhou.debian.net I have tested that creating a schroot and building packages work, but there might still be something that I might have missed. So if you run into any problems, please let me know. Thanks, Adrian > [1] https://db.debian.org/machines.cgi?host=shenzhou -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1079642: ITP: mfiutil -- Utility for managing LSI MegaRAID SAS controllers
Package: wnpp Severity: wishlist Owner: WHR X-Debbugs-Cc: debian-devel@lists.debian.org, w...@rivoreo.one * Package name: mfiutil Version : 1.0.15-rivoreo-r1 Upstream Contact: WHR * URL : https://sourceforge.net/projects/mfiutil/ * License : BSD-3-Clause Programming Lang: C Description : Utility for managing LSI MegaRAID SAS controllers A lightweight utility providing basic management functionality for LSI MegaRAID SAS controllers, ported from FreeBSD. It works with Linux megaraid_sas driver, and supports 2nd and later generations of MegaRAID SAS conntrollers. Additional information: To my knowledge, this is the only free management tool available for the LSI MegaRAID SAS conntrollers. With this package readily available will enabling users to perform usual maintenance tasks on their MegaRAID SAS conntrollers, without having to run the vendor-provided proprietary tools. This tool has been tested with following controllers: * Dell PERC H310 Mini * Dell PERC H330 Mini * Dell PERC H710 Mini * Dell PERC H730 Mini * Dell PERC H840 I plan to make the first release source tarbell available in next few days; after that a Debian source package will be created from it. I didn't find an obvious matching team for this package. I do need a sponsor.
Bug#1079654: ITP: libsaf-dev -- SAF - Minimal abstract interface for simple games
Package: wnpp Severity: wishlist Owner: Julio Sangrador-Paton X-Debbugs-Cc: debian-devel@lists.debian.org, jsangrad...@gmail.com * Package name: libsaf-dev Version : 1.012d Upstream Contact: Miloslav Číž * URL : https://codeberg.org/drummyfish/SAF * License : Public Domain Programming Lang: C Description : SAF - Minimal abstract interface for simple games My aim is to package for Debian some small games I have developed using this SAF public domain library (some of them reachable throught the library homepage itself). It is a header-only C99 library in the public domain. I might just as well copy the single file saf.h side by side with my own code for the games but I find it more useful to have it publicly available for all Debian users who could benefit from it. In full disclosure, my games are developed using a very slightly modified version of upstream, which I also plan to package for Debian under the tentative name libsafjsp-dev (SAF Julio Sangrador-Paton), but I feel it is owing to the original spirit of the library to also package it in its original form. (long description excerpt from upstream follows) SAF is a very minimal C interface for programming mainly small games that will run on many small gaming consoles, but SAF will also run on PCs and other "big" platforms, and can be used to create not just games but also other "toy" programs. You can look at SAF in different ways: It's a bit like SDL for tiny computers, mainly open consoles such as Pokitto and Arduboy, it provides abstraction, portability and convenience functions. It spares people of constantly having to manually port games over and over to new consoles. It's a bit like a fantasy console, it intentionally limits you so that the programming is simple, comfy, and your games will inevitably be nostalgic and "retro". Thanks to this, SAF can be supported even on very small 8 bit consoles. It's a library that will save you from implementing and debugging many things over and over. And it will make it much easier to program games for platforms that don't come with emulators. It is an API, an interface, a standard, which has many advantages, it is e.g. easy to switch backends, automatically process the code etc. It behaves a bit like an emulator, it gives you the possibility to record inputs, speed up or slow down time, use pixel art upscaling etc.
Re: Intent to MBF: move from fuse to fuse3
Hi, * László Böszörményi (GCS) [240825 18:30]: > Thanks for adding me, I can't follow -devel. Sorry for not thinking about that earlier > On Wed, Aug 21, 2024 at 11:24 PM Chris Hofstaedtler wrote: > > Updated MBF text proposal: > [...] > > Does that sound good? > This sounds right to me, except that the fuse package should be > removed in the Trixie release already. It was obsoleted more than five > years ago and it's time to move on. Yeah, I agree. Do you want to upload a new src:fuse package dropping the fuse binary package? fuse3 already Provides: fuse, so that should be fine. > The libfuse2 package might remain, > but dependent packages had enough time to migrate already. > Unfortunately it is known in other distributions as well [1] that for > some reason (laziness probably) projects don't migrate to fuse3. Ack, for now libfuse2(-dev) should stay :-( > Regards, > Laszlo/GCS Best, Chris > [1] https://github.com/NixOS/nixpkgs/issues/150502#issuecomment-2017295190
Re: DEP18 follow-up: Salsa CI vs Debusine
Hi Helmut! > > Let me suggest that there are more ways to do this. Freexian is putting > > a ton of effort into https://debusine.debian.net. It can do much of the > > same tasks as salsa-ci already (with less flexibility). Extending it to > > act as an upload-proxy that forwards your upload to the archive if > > builds pass could be another option of improving unstable quality. In > > earlier times, debomatic.debian.net was used as a pre-upload QA tool if > > I remember correctly. > > I used to use debomatic.debian.net, and I have been reading about > Debusine and the funding it gets from the Sovereign Fund. I tried to > use Debusine back in March, but the client requires Python 3.11+ which > my system does not have. I will need to make a new attempt soon. Thus, Ok, I tested Debusine again and managed to build a package following the tutorial with the build definition: ``` build_components: - any - all environment: debian/match:codename=trixie:variant=sbuild host_architecture: amd64 input: source_artifact: 507533 ``` However, I struggle to figure out how to do something similar to what Salsa CI. Do you happen to have at hand a complete build+test definition I could copy-paste and test? Also, I see the build reports 'success' despite Lintian failing on an error. Additionally, seems this system does not send out email notifications? At https://freexian-team.pages.debian.net/debusine/reference/faq.html it says in two ways that the core design philosophy is to invent something new instead of using something existing, as the existing thing isn't controlled by Debian. That makes sense in some situations, but in the case of a code forge with review, build and test features, it seems that trying to build a new custom thing from scratch is perhaps a bit too ambitious? GitLab isn't perfect, but I'd say that the setup Debian has now with salsa.debian.org is pretty good, and I'd rather polish it than fund building a new system from scratch. I am however willing to test Debusine a bit more to see if it has hidden powers that could be amazing.
Status of OpenMAX IL
Hi, it seems the only OpenMAX implementation got removed from unstable, and ffmpeg drops OpenMAX support as well because that implementation was providing the header files. That is a bit suboptimal for me, because the VisionFive2 hardware video encoder is also interfaced using OpenMAX IL. Does it make sense to package the OpenMAX headers separately so the interface is available at least? These are Khronos Group headers, so the situation is a bit similar to OpenGL. (Also, Google seem to have added several extensions to it in Android -- these would be nice to have but Khronos is a bit behind here) Simon
Bug#1079669: ITP: libntruprime -- Streamlined NTRU Prime (sntrup) microlibrary
Package: wnpp Severity: wishlist Owner: Simon Josefsson X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libntruprime Version : 20240825 Upstream Authort: Daniel J. Bernstein * URL : https://libntruprime.cr.yp.to/ * License : LicenseRef-PD-hp OR CC0-1.0 OR 0BSD OR MIT-0 OR MIT Programming Lang: C Description : Streamlined NTRU Prime (sntrup) microlibrary libntruprime is a microlibrary for the Streamlined NTRU Prime cryptosystem. Streamlined NTRU Prime (sntrup) is a lattice-based cryptosystem with the following features: - Stability: Almost all details of sntrup match a May 2016 publication. The only exceptions are small changes to encoding and hashing published in April 2019. - Patent-freeness: April 2019 predates almost all post-quantum patents. Analyses of various lattice patents filed before April 2019 indicate no problems for sntrup. - Deployment: The popular OpenSSH tool switched to sntrup761 by default in April 2022, following initial integration of sntrup into TinySSH. - Affordability: Keys and ciphertexts are about 1KB for sntrup761, and computations are fast. - Careful design: Subject to the requirement of being a small lattice-based cryptosystem, sntrup is systematically designed to eliminate unnecessary complications in security review. It eliminates decryption failures, for example, and eliminates cyclotomics. The cryptosystem has never needed a security patch. - Risk management: A much higher sntrup1277 security level is fully supported, and is recommended whenever 2KB keys and ciphertexts are affordable, to reduce risks from improvements in lattice attacks. - Flexibility: The sntrup design allows a full spectrum of tradeoffs between size and security level, so applications with intermediate size limits aren't forced into much lower security levels. Six different sizes have been selected for support. libntruprime has a very simple stateless API based on the SUPERCOP API, with wire-format inputs and outputs, providing functions that directly match the KEM operations provided by the sntrup specification, such as functions sntrup1277_keypair sntrup1277_enc sntrup1277_dec for the sntrup1277 KEM. Internally, libntruprime includes implementations designed to work portably across CPUs, and implementations designed for higher performance on Intel/AMD CPUs with AVX2 instructions. libntruprime includes automatic run-time selection of implementations. libntruprime is intended to be called by larger multi-function libraries (such as traditional cryptographic libraries), including libraries in other languages via FFI. The idea is that libntruprime takes responsibility for the details of sntrup computation, including optimization, timing-attack protection, and (in ongoing work) verification, freeing up the calling libraries to concentrate on application-specific needs such as protocol integration. Applications can also call libntruprime directly. I hope to maintain this at https://salsa.debian.org/jas/libntruprime /Simon signature.asc Description: PGP signature
removing a non-static version of qemu-user?
Hi! I'd love to get some input about an idea which I expressed in https://bugs.debian.org/1079603 - namely, to move static qemu-user emulation binaries from qemu-user-static package to qemu-user package (which contains dynamically-linked binaries with exactly the same functionality), effectively keeping just one, static, build of qemu-user instead of two. I see no reason of building two versions of qemu-user binaries, since static version is well-suited for all usages, while dynamically-linked one, while obviously smaller, is limited to just a few use cases. The details are expressed in the bugreport mentioned above. The resulting layout is compatible with current expectations, so nothing should be (immediatly) changed in existing packages/habits. If there are other reasons to keep non-static build of qemu-user which I didn't think of, please tell me. Thanks, /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
