Re: Moving libdeflate from Debian-Med to a more appropriate team
Michael R. Crusoe left as an exercise for the reader: > libdeflate-dev has 3304 reverse-dependencies in "unstable"[0]. > I would like to move it from Debian-Med to a more appropriate team. > Are there any volunteers? I maintain it for Fedora, and would be happy to handle it in Debian; it's a dependency for one of my other packages (notcurses). Happy to enter into a team maintainership as well. -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: Moving libdeflate from Debian-Med to a more appropriate team
Michael R. Crusoe left as an exercise for the reader: > Please create a new group on salsa and then we can move the repo[0] from the > debian-med namespace. done: https://salsa.debian.org/deflate-team I've sent invites to you and Andrea. Feel free to ignore them. > Then you can formalize the change by uploading the new version[1] of > libdeflate with the new "Maintainer". > [1] https://github.com/ebiggers/libdeflate/releases/tag/v1.21 on it. -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: Removing more packages from unstable
Helmut Grohne left as an exercise for the reader: > notcurses i need decide whether i'm putting out a new upstream release with ffmpeg 7 support, or whether i ought patch it in debian (thanks to sebastian ramacher for originally bringing the issue to my attention). i suppose i can do the latter now without any real pain, and take the upstream when and if i bring it out. especially if there's a reasonable heads-up, this seems an effective way to gently remind developers of work they'd forgotten about, or were putting off. -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Bug#671385: ITP: omphalos -- Network enumeration and domination
Package: wnpp Severity: wishlist Owner: nick black * Package name: omphalos Version : 0.99.0 Upstream Author : Nick Black * URL : http://dank.qemfd.net/dankwiki/index.php/Omphalos * License : GPL Programming Lang: C Description : Network enumeration and domination Omphalos is a tool for visualizing and controlling a local network (though it will also process pcap savefiles). Captured packets are analyzed to build a database of hosts and services. Various scans can be performed to elicit informative packets. Spoofing and redirection at several layers allows flows to be redirected through the host machine, or silenced. Omphalos is fully IPv6 aware, and makes use of numerous service discovery protocols. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503175707.27008.64503.reportbug@localhost
Bug#700060: ITP: ITP: growlight -- Disk manipulation and system preparation tool -- Disk manipulation and system preparation tool
Package: wnpp Severity: wishlist Owner: Nick Black * Package name: growlight -- Disk manipulation and system preparation tool Version : 1.0.4.5 Upstream Author : Nick Black * URL : http://nick-black.com/dankwiki/index.php/Growlight * License : GPL Programming Lang: C Description : Disk manipulation and system preparation tool Growlight can manipulate both real and virtual (mdadm, device-mapper, and ZFS) disks, find bottlenecks in a storage setup, create partitions and filesystems, and prepare fstab files for new installations. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130208000853.4225.63766.reportbug@localhost
apt-show-versions rewrite
(CC'd kinda widely, eh; feel free to trim responses) Hello there, Christoph! I've used apt-show-versions for years, and found it quite useful. It's a bit slow, though, and its need to update a root-owned disk cache is kind of unfortunate. As part of my RAPTORIAL project (https://github.com/dankamongmen/raptorial), I've implemented "rapt-show-versions", an apt-show-versions clone making use of my libraptorial library. This multithreaded C engine ends up being quite a bit faster than apt-show-versions; a single core run comes in around .21s whereas apt-show-versions takes about 1.01s, while allowing it to use all 4 hyperthreaded cores drops this to .04s. We will soon begin shipping RAPTORIAL tools in SprezzOS. I'm aiming for feature-equivalence with apt-show-versions (the -i option becomes a no-op, since I don't use a cache), though I'm not yet there. Core functionality is present, and debugged. The code is, so far as I know, portable across POSIX systems. I'd like to show deference to you, as the author of apt-show-versions. How would you like to proceed on this? I figure there's three options: - The apt-show-versions package begins building my code, which I will version relative to current apt-show-versions, on which there would be no further development. - A new package, rapt-show-versions, is introduced, probably with alternatives and Provides support. - The code is not introduced into Debian anytime soon. Know that I am not (yet) a DD, though I'm happy to ITP this up if someone will help it through. Please take a look, and let me know how you'd like to move forward. Note that I don't by any means propose replacing other APT components with RAPTORIAL, yet. Thanks for your time. Hack on! --nick -- nick black http://www.sprezzatech.com -- unix and hpc consulting to make an apple pie from scratch, you need first invent a universe. signature.asc Description: Digital signature
Re: apt-show-versions rewrite
David Kalnischkies left as an exercise for the reader: > You forgot to provide the source for your rewrite; the "library" is rather > small to have a serious look at it even through a multithreaded cache would > be interesting, but it not even builds as I miss a "blossom.h" which apt-file > couldn't tell me where to find … My apologies for trying to get this started in parallel. It clearly got things off on the wrong foot. You'll find things quite a bit more developed now, I think; as I said on Monday, I was aiming for feature equivalence by Friday, and expect to hit it with completion of bug 681 tomorrow: https://github.com/dankamongmen/raptorial https://www.sprezzatech.com/bugs/show_bug.cgi?id=681 In any case, it appears that this is an idea which is only going to stir up resentment from the APT team -- understandably, I suppose -- and thus I cheerfully withdraw my suggestion that Debian and the APT Team look at it. I look forward to a non-glacial apt-show-versions in Debian, however it happens and whomever writes it. Feel free to package rapt-show-versions should that C++ apt-show-versions never get itself written. Be well! -- nick black http://www.sprezzatech.com -- unix and hpc consulting to make an apple pie from scratch, you need first invent a universe. signature.asc Description: Digital signature
Re: apt-show-versions rewrite
David, especially after reading http://raphaelhertzog.com/2010/12/10/people-behind-debian-david-kalnischkies-an-apt-developer/, I can see how my original post would totally get under your skin. I definitely didn't intend to do that; apologies! This project was motivated by one major thing: certain operations involving libapt are way slower than they need to be. You mention that "time spent rewriting parsing code is time that could add new features." That's surely true, but the functionality of APT as stands is sufficient for my needs. The performance of that functionality is not. I do *not* intend to rewrite the entirety of APT -- I hoped to rewrite the underbelly, the part furthest away from the user. As soon as I can, I'll then take the current APT code, and drape it over what I have. I suspected it would be easier to graft the toplayer onto a new bottom layer designed for multicore/fastdisk than it would be to retrofit the existing code. Reading your quoted words: "APT2 isn’t much more than the name—which I completely dislike—currently from a user point of view, so I can’t really comment on that. All of them make me sad as each line invested in boilerplate code like configuration file parsing would be in my eyes better be spent in a bugfix..." raptorial currently has 150 lines of lexing, a third of which is comments. Not that much boilerplate code. The emphasis here is on parallelism and algorithmic improvements. As you and others pointed out, mine is a "fairly limited" lexer. That is by design, as lexing files is a solved problem. I had hoped that by presenting advanced technology for the sinews holding things together, it would be assumed that I could handle copying over crap lexing state machines. Apparently not. "be spent in a bugfix or new feature instead, but I am not here to tell anyone what they should do in their free time…" If you accept my point of view that lackluster performance is a bug, I've been working on a bugfix, though admittedly a highly invasive one. One can't point at DBTS, perhaps, because if someone say went and filed a bug claiming "your shit is slow", I think we can all agree they'd be invited to provide patches and measurements, if the bug wasn't closed outright. Well, your shit is slow (though feature-awesome!), and my shit is fast (though feature-starved!), and I'll provide timings if you're interested, or I can happily just keep it in SprezzOS. But every time someone's wrenched from a solid work flow by waiting around on some APT ecosystem operation for that sick second that separates smooth interactivity from "slow piece of garbage computer!!", it's a bug to them. I'm on #debian-apt and will hang out there today. Perhaps threading out the existing APT core won't be as painful as I expected, especially since a viable design effecting proven speedup already exists? Let's talk. Hack on! --nick -- nick black http://www.sprezzatech.com -- unix and hpc consulting to make an apple pie from scratch, you need first invent a universe. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130315113042.ga22...@qemfd.net
sprezzos apt-show-rewrite complete (report + numbers)
This is a followup to my post to debian-devel, debian-derivatives, deity,
and sprezzos-dev last Monday entitled "apt-show-versions rewrite". This
post is strictly informative, and does not advocate any policy.
Documentation has been substantially embeefened, including design notes:
https://www.sprezzatech.com/wiki/index.php/Raptorial
https://github.com/dankamongmen/raptorial
rapt-show-versions(1), part of the RAPTORIAL suite, has become
feature-equivalent to the native apt-show-versions(1) tool, as predicted.
Despite fleshing out the features, I've managed to retain its speed.
[recombinator](0) $ ./rapt-show-versions -h
rapt-show-versions v0.1.5 by nick black
invoked as /home/dank/raptorial/.libs/lt-rapt-show-versions
usage: rapt-show-versions [ options ] packageregex
options:
-s|--status-file= Status file (def: /var/lib/dpkg/status)
-l|--list-dir= List directory (def: /var/lib/apt/lists)
-a|--allversionsPrint all available versions
-h|--help Display this usage summary
[recombinator](0) $
Anyone who was offended by discussion "without the code written" last
week ought hopefully be able to join in without bias now. The entirety of
the codebase, including the common libraptorial(3) library, is 1650 lines
of heavily-commented POSIX C:
[recombinator](0) $ wc -l src/bin/rapt-show-versions.c src/lib/*[ch]
217 src/bin/rapt-show-versions.c
233 src/lib/aac.c
31 src/lib/aac.h
96 src/lib/config.h
898 src/lib/packages.c
12 src/lib/paths.c
163 src/lib/raptorial.h
1650 total
[recombinator](0) $
All modes of apt-show-versions have been implemented:
- print packages from command line arguments, and status/upgrade info
- print all installed package, and status/upgrade info
- print all package versions using either of these two modes
And now, the timings [drumroll]
I am testing on two machines, a Core i7 2600K quadcore with HyperThreading,
overclocked to 5.0GHz ("skynet"), and a Core 2 Duo 6600 at stock 2.4GHz
("recombinator"). I ran each mode 10 times with each binary on each machine,
without interleaving. As the working set of each binary can be kept easily
within page cache on either machine, these tests probably do not reflect true
disk i/o. Disk I/O would be expected to only help RAPTORIAL relative to
apt-show-versions, given that RAPTORIAL will issue its disk reads in parallel,
rather than sequentially, and that they can all fit in page cache. These tests
use RAPTORIAL 0.1.5, Libblossom 1.2.2, and the native SprezzOS APT databases of
the machines.
Case 1: Print selected packages and status/upgrade info
Quadcore:
[skynet](0) $ for i in `seq 1 10` ; do /usr/bin/time -f "%ems real %Ums user
%P util" ./rapt-show-versions apt raptorial > /dev/null ; done
0.09ms real 0.21ms user 234% util
0.10ms real 0.22ms user 245% util
0.11ms real 0.22ms user 227% util
0.10ms real 0.23ms user 242% util
0.10ms real 0.22ms user 249% util
0.11ms real 0.24ms user 225% util
0.14ms real 0.30ms user 230% util
0.11ms real 0.24ms user 233% util
0.10ms real 0.25ms user 250% util
0.13ms real 0.29ms user 238% util
[skynet](0) $ for i in `seq 1 10` ; do /usr/bin/time -f "%ems real %Ums user
%P util" apt-show-versions apt raptorial > /dev/null ; done
0.36ms real 0.32ms user 97% util
0.35ms real 0.32ms user 98% util
0.35ms real 0.34ms user 98% util
0.36ms real 0.34ms user 97% util
0.36ms real 0.33ms user 97% util
0.35ms real 0.33ms user 97% util
0.37ms real 0.34ms user 97% util
0.35ms real 0.31ms user 97% util
0.36ms real 0.34ms user 97% util
0.35ms real 0.33ms user 98% util
[skynet](0) $
Dualcore:
[recombinator](0) $ for i in `seq 1 10` ; do /usr/bin/time -f "%es real %Us
user %P util" apt-show-versions apt raptorial > /dev/null ; done
0.52s real 0.48s user 98% util
0.52s real 0.42s user 97% util
0.52s real 0.46s user 97% util
0.52s real 0.44s user 97% util
0.52s real 0.46s user 97% util
0.52s real 0.46s user 97% util
0.52s real 0.48s user 97% util
0.51s real 0.45s user 98% util
0.52s real 0.50s user 97% util
0.52s real 0.44s user 97% util
[recombinator](0) $ for i in `seq 1 10` ; do /usr/bin/time -f "%es real %Us
user %P util" ./rapt-show-versions apt raptorial > /dev/null ; done
0.16s real 0.26s user 164% util
0.15s real 0.26s user 165% util
0.15s real 0.24s user 164% util
0.15s real 0.24s user 165% util
0.15s real 0.24s user 165% util
0.14s real 0.24s user 174% util
0.14s real 0.25s user 175% util
0.16s real 0.26s user 159% util
0.15s real 0.25s user 169% util
0.15s real 0.24s user 163% util
[recombinator](0) $
Call it 13ms vs 36ms on the quadcore and 15ms vs 51ms on the dualcore.
Quadcore winner: RAPTORIAL at 36% running time
Dualcore winner: RAPTORIAL at 29% running time
Champion: RAPTORIAL
Case 2: Print all installed packages and status/upgrade info
Quadcore:
[skyne
Re: apt-file performance characterization
nick black left as an exercise for the reader: > I've written up a performance characterization of apt-file(1) as stands. The > preliminary version is available here: > > http://nick-black.com/raptorial-file OK, finished this writeup. I've updated the file at the link above, and included it below. I'm going to go ahead and knock out bugs 705[0] and 698[1], which will together implement everything described herein. Hopefully that'll be done by tomorrow morningish, EDT. Hack on! --rigorously, nick [0] https://www.sprezzatech.com/bugs/show_bug.cgi?id=705 [1] https://www.sprezzatech.com/bugs/show_bug.cgi?id=698 Optimizing apt-file === All timings were taken on a quadcore Core i7 2600K overclocked to 5.0GHz, reading files from an Intel 320 SSD. All data sets fit within main memory. apt-file has a more complex performance space than did apt-show-versions. Understanding this space is critical to optimizing apt-file, and evaluating any optimizations made. apt-file doesn't perform string searches itself; it uses grep, zgrep and zfgrep. Furthermore, while apt-file is not multithreaded, it does run multiple processes (apt-file -> gzip | grep), and thus natively takes advantage of multiple cpus within a given Contents file. In this top(1) output, the last column is the CPU number: 8529 dank 7952 848 688 R 21.9 0:00.66 grep3 8522 dank 66508 17m 3436 S 11.6 0:00.35 apt-file0 8528 dank 8840 668 508 R 10.6 0:00.32 gzip2 Of course, on a unicore machine, this use of three different processes will provide no computational benefit (it might provide I/O benefit). It is worth noting that the -x (regex) functionality of apt-file appears to be broken or at least incomplete. Neither of the following searches, for instance, yield any matches for "compiz" (or indeed all of the matches for "frog"): [skynet](0) $ apt-file search -x frog\|compiz frog: /usr/bin/frog wmfrog: /usr/bin/wmfrog [skynet](0) $ apt-file search -x \(frog\)\|\(compiz\) frog: /usr/bin/frog wmfrog: /usr/bin/wmfrog [skynet](0) $ Running "apt-file frog compiz" finds all of the frog matches, but none of the compiz matches. It appears that apt-file cannot use multiple patterns off the command line, but it doesn't bother to warn the user about that. We can create a pattern file, however, and that works: [skynet](0) $ echo -e "frog\ncompiz" > searches [skynet](0) $ apt-file -f search searches | wc -l 3874 [skynet](0) $ apt-file search compiz | wc -l 1112 [skynet](0) $ apt-file search frog | wc -l 2762 [skynet](0) $ echo $((3874 - 1112)) 2762 [skynet](0) $ Characterizing apt-file performance === Background material: "Flexible Pattern Matching in Strings" by Navarro et al "Introduction to Algorithms" by Cormen et al String search algorithms tend to be optimized for one use or another. Searching within DNA, for instance, is a very different game than searching within UTF-32, which is very different from searching within UTF-8. We will consider only exact string matching, and not "fuzzy" string matching (i.e., matching within some string distance). Parameterizing the problem space under this condition yields: - alphabet size - needle length - haystack length - number of needles - needle heterogeneity - frequency of occurrence Note that in the presence of Kleene closure, there might be an infinite number of needles. In the case of an online algorithm, the haystack is of infinite size. All other parameters are finite. The alphabet size and haystack length are independent of apt-file(1). Let's explore performance when we vary the other parameters: Varying needle length = It would be nice to have short needles of various length which held the frequency of occurrence constant, but that'll have to come another day. It'll be easy, as we'll see, to vary frequency without varying length. [skynet](0) $ for i in compizabd compizab compiza compiz compi comp com co c ; do time apt-file search $i | wc -l ; done 0 real0m1.655s 0 real0m1.673s 0 real0m1.654s 1112 real0m1.854s 17293 real0m2.850s 86277 real0m4.971s 225415 real0m7.667s 998349 real0m22.491s 4019431 real1m30.639s [skynet](0) $ apt-file(1) clearly performs better for longer strings, although this could be due to their lesser frequency of occurrence. Times are approximately equal for the three longest strings, but they also have equal frequency (0 occurrences). This points to a backwards-skipping algorithm such as Boyer-Moore (with longer strings, we get longer skips, and the ratio of skipped text for different string lengths (
apt-file rewrite done
file(1) beats raptorial-file, or even ties it. That said, the gain on typical searches is only a 1.1x--1.2x speedup. That might not be worth replacing the well-tested apt-file(1) codebase with raptorial-file(1) by itself. However: (1) raptorial-file(1) uses the same codebase as rapt-show-versions(1), so why not have one if you have the other? (2) raptorial-file(1) is 84 lines of C to apt-file's 779 lines of perl (3) raptorial-file(1) will beat apt-file(1) more and more as cores are added (4) raptorial-file(1) is pretty standard C; there's no tricky code. maybe apt-file(1) is pretty standard perl. i wouldn't know. IMHO 779 lines of perl is unmaintainable perl, no offense to the apt-file(1) authors. (5) the apt-file(1) maintainer has recently requested to hand off the package, while the likely raptorial-file(1) maintainer is agitating for his package's inclusion :). I hope this builds excitement regarding RAPTORIAL and convinces folks that I'm on to something here. Hack on! --rigorously, nick Hacker-in-Charge, SprezzOS Project -- nick black http://www.sprezzatech.com -- unix and hpc consulting to make an apple pie from scratch, you need first invent a universe. signature.asc Description: Digital signature
Re: apt-file rewrite done
nick black left as an exercise for the reader: > I've got raptorial-file in a state for people to play with. The wins weren't > as impressive as apt-show-versions(1) for the common cases (more like 25%), > though some uncommon cases saw reductions in total time of >90%. Spoke too soon! After fixing a stupid bug [0], improvement is much more stark, closer to a 2x speedup. the case for raptorial-file(1) just became much more convincing: [skynet](130) $ for i in `seq 1 10` ; do /usr/bin/time ./raptorial-file compiz > /dev/null ; done 4.07user 1.29system 0:00.95elapsed 565%CPU (0avgtext+0avgdata 194304maxresident)k 0inputs+0outputs (0major+37572minor)pagefaults 0swaps 3.74user 1.89system 0:01.07elapsed 526%CPU (0avgtext+0avgdata 183116maxresident)k 0inputs+0outputs (0major+39856minor)pagefaults 0swaps 3.91user 1.21system 0:00.99elapsed 515%CPU (0avgtext+0avgdata 193564maxresident)k 0inputs+0outputs (0major+38071minor)pagefaults 0swaps 3.93user 1.31system 0:01.06elapsed 495%CPU (0avgtext+0avgdata 186644maxresident)k 0inputs+0outputs (0major+38400minor)pagefaults 0swaps 4.03user 1.54system 0:01.01elapsed 551%CPU (0avgtext+0avgdata 192504maxresident)k 0inputs+0outputs (0major+39826minor)pagefaults 0swaps 3.64user 1.03system 0:01.05elapsed 442%CPU (0avgtext+0avgdata 186892maxresident)k 0inputs+0outputs (0major+37151minor)pagefaults 0swaps 3.87user 1.84system 0:01.10elapsed 516%CPU (0avgtext+0avgdata 193324maxresident)k 0inputs+0outputs (0major+34636minor)pagefaults 0swaps 4.03user 1.84system 0:01.01elapsed 582%CPU (0avgtext+0avgdata 192576maxresident)k 0inputs+0outputs (0major+39498minor)pagefaults 0swaps 3.97user 1.65system 0:01.04elapsed 538%CPU (0avgtext+0avgdata 194552maxresident)k 0inputs+0outputs (0major+38737minor)pagefaults 0swaps 3.85user 1.18system 0:01.03elapsed 485%CPU (0avgtext+0avgdata 190348maxresident)k 0inputs+0outputs (0major+36283minor)pagefaults 0swaps [skynet](0) $ [skynet](1) $ for i in `seq 1 10` ; do /usr/bin/time apt-file search compiz > /dev/null ; done 2.06user 0.12system 0:01.77elapsed 123%CPU (0avgtext+0avgdata 12076maxresident)k 0inputs+0outputs (0major+19894minor)pagefaults 0swaps 2.07user 0.13system 0:01.80elapsed 122%CPU (0avgtext+0avgdata 12076maxresident)k 0inputs+0outputs (0major+19909minor)pagefaults 0swaps 2.10user 0.12system 0:01.82elapsed 122%CPU (0avgtext+0avgdata 12076maxresident)k 0inputs+0outputs (0major+19901minor)pagefaults 0swaps 2.03user 0.15system 0:01.78elapsed 122%CPU (0avgtext+0avgdata 12080maxresident)k 0inputs+0outputs (0major+19904minor)pagefaults 0swaps 2.17user 0.11system 0:01.85elapsed 123%CPU (0avgtext+0avgdata 12080maxresident)k 0inputs+0outputs (0major+19895minor)pagefaults 0swaps 2.15user 0.12system 0:01.84elapsed 123%CPU (0avgtext+0avgdata 12080maxresident)k 0inputs+0outputs (0major+19894minor)pagefaults 0swaps 2.04user 0.16system 0:01.79elapsed 122%CPU (0avgtext+0avgdata 12080maxresident)k 0inputs+0outputs (0major+19890minor)pagefaults 0swaps 2.03user 0.13system 0:01.77elapsed 122%CPU (0avgtext+0avgdata 12080maxresident)k 0inputs+0outputs (0major+19897minor)pagefaults 0swaps 2.05user 0.12system 0:01.77elapsed 122%CPU (0avgtext+0avgdata 12080maxresident)k 0inputs+0outputs (0major+19895minor)pagefaults 0swaps 2.08user 0.13system 0:01.80elapsed 122%CPU (0avgtext+0avgdata 12076maxresident)k 0inputs+0outputs (0major+19899minor)pagefaults 0swaps [skynet](0) $ RAPTORIAL: 1.01s apt-file: 1.77s CHAMPION: RAPTORIAL (57%) now *THAT'S* what i'm talkin' about! w00t w00t! man look at those cpus getting pegged! rawwhide! --hack on, nick Hacker-in-Charge, SprezzOS Project [0] https://github.com/dankamongmen/raptorial/commit/6818a945733f246511a408165d99620352b19963 -- nick black http://www.sprezzatech.com -- unix and hpc consulting to make an apple pie from scratch, you need first invent a universe. signature.asc Description: Digital signature
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
Adam Borowski left as an exercise for the reader: > Instead of RasPis as suggested by many in this thread, I'd instead suggest > whatever is the current model of Odroid-H2+: I was intrigued, but https://ameridroid.com/products/odroid-h2 suggests it's been out of stock since 2021? -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: 64-bit time_t transition for 32-bit archs: a proposal
Simon McVittie left as an exercise for the reader: > Debian-style multiarch or Fedora/Arch-style multilib is a much, much this is at least the second time you've drawn this distinction in this thread. for anyone else who, like me, was uneasy with their understanding of the concept: https://wiki.debian.org/ToolChain/Cross#Multiarch_vs_Multilib seems to be a solid resource (and sadly low on my google returns). -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: multiarch vs. multilib
Simon McVittie left as an exercise for the reader: > Sorry, I spend a lot of my work time immersed in this sort of thing and > how it differs between distributions, so I tend to forget that most > developers are able to stick to one distro and don't need to know this! no offense at all, and thanks tremendously for the detailed explanation! i've learned a lot in this thread. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Simon McVittie left as an exercise for the reader: > At the moment I believe the status quo for d-i is that networking is > managed by NetworkManager if a desktop task happens to have pulled it in, > or ifupdown otherwise? And that seems reasonable (although I personally > prefer to set up systemd-networkd on servers). i don't wish to start an argument, but just to ask: everyone has recommended NetworkManager for workstations. i've been running systemd-networkd on everything (servers, laptops, and workstations) for several years now, usually in conjunction with dnsmasq and wpa_supplicant, and it's been pretty great. what does NetworkManager offer that makes it superior to systemd-networkd on the desktop (which i'm interpreting to mean "for interactive use")? i'm not doubting its advantages, just ignorant of them. =] it seems to me that unifying the network stack has some value all its own. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Simon McVittie left as an exercise for the reader: > I was using "desktop" in the sense of task-gnome-desktop and friends, more > than as a class of hardware. Laptops and other portable computers are the > main thing that really needs easily user-configurable networking. > I think it makes sense for desktop/workstation hardware to be treated like > an oddly-shaped laptop by default, which means it gets the benefit of the > wider testing that goes into NM and its various user interfaces, rather > than having laptops and desktops behave differently for reasons that are > unlikely to be obvious to a new user. since sending that mail, i've looked into gnome, and it seems to have pretty deep integration with NM. given gnome's positioning in debian, that seems to satisfy my question in and of itself. it's clearly at a level well above wpa_gui etc. (which i don't use, but might have proffered for consideration). thanks as always for your detailed and thoughtful mails. > A secondary benefit of NM is that it works on non-systemd-booted systems, > whereas systemd-networkd isn't designed for that use. I'm personally > happy with systemd as pid 1, but some people consider requiring systemd > as pid 1 to be a deal-breaker, and if NM is a good candidate for being > our default *anyway* then we might as well get that secondary benefit too. i hadn't even considered this, thanks. one nice thing about systemd-networkd is that it's pretty extensive in terms of structured configurability; i've currently got two machines with "CombinedChannels 1" to run XDP programs which bind to queue 0, for instance. of course, these are advanced options and thus can assume non-default effort. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: Policy consensus on transition when removing initscripts.
Simon McVittie left as an exercise for the reader: > started as root and dropped privileges to some other uid, that permanently > restricts its ability to read information out of its own /proc, which is > not always desirable. If the daemon starts up unprivileged, then it can i assume by "its own /proc" you mean /proc/getpid()? i don't see how this is different from any other resource one might need consider acquiring prior to dropping privileges. if i want to open a privileged port, i'd better do that before i change my user (or otherwise yield CAP_NET_BIND_SERVICE). furthermore, this is only true when procfs is mounted with a nonzero hidepid, right? all my /proc/PID directories are 0755, with contents likewise generally world-readable. hidepid=off is the default according to https://www.kernel.org/doc/html/latest/filesystems/proc.html. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Helmut Grohne left as an exercise for the reader: > And yeah, please work on changing that ifupdown by default. I'm faced > with having to uninstall it from more and more systems. In case, you > do a straw poll, I vote for systemd-networkd, which happens to be > installed by default. Would there be any volunteers doing the d-i > integration? I'd be interested in taking this on, though I wouldn't want to step on anyone's toes, so if someone with a feeling of ownership would rather take it, please let yourself be known. I'd want clarity as to whose approval I need to merge code (and their buy-in to the effort overall) before starting. I've messed with d-i and systemd-networkd both a good bit, and like you (I assume) believe systemd-networkd to be the best option at this time, and also moving forward. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Sam Hartman left as an exercise for the reader: > In the wifi case though, I agree that netplan is a good idea. > It doesn't look like systemd-networkd supports setting up the > authentication for a wireless network. So, you'd need to be using > wpa_supplicant directly and systemd-networkd. I think using I might be misunderstanding your use of "directly" here, but systemd-networkd certainly supports driving wifi authentication through wpa_supplicant (though yes, the configuration is outsourced to wpa_supplicant, which seems desirable since it can then be picked up and used easily by other tools). It's not tightly integrated, though, so you usually need some "IgnoreCarrierLoss" chicanery if you don't want to reinitialize the interface when switching between BSSIDs. This is probably what you meant, but just wanted to be clear. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Sam Hartman left as an exercise for the reader: > >>>>> "nick" == nick black writes: > I consider anything that requires me to write wpa_supplicant config to > be a bad idea (unless I'm running an AP) and NetworkManager driving > wpa_supplicant is a better idea. i think everyone's agreed on this part. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe.
Re: Efforts to Improve Virtual Console
Aryeh Hillman left as an exercise for the reader: > I am looking to either find or help create a better virtual console > experience on linux, especially in Debian. I am talking about tty1, tty2, > tty3, ... typically mapped via CTRL-ALT-F1. how would you like to improve it? if you'd like to e.g. run a more advanced KMS-based console, you might want to try kmscon in place of [a]getty. >- where does the virtual console code live for debian? the virtual console is implemented in the kernel. console-setup handles...console setup, with keyboard-setup as an input. >- is virtual console code distro-specific or does it ship with the >kernel? kernel >- are there any known efforts in this domain? what domain? i requested that some of the default unicode mappings change back in 2020: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965029 i'm sitting on a few kernel patches that i need break up to improve color handling in the VC. Notcurses (https://notcurses.com/) pushes the current framebuffer console pretty much as far as it will go in terms of UI components if you're looking to build applications that will run both there and in X/Wayland terminal emulators. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: Default font: Transition from DejaVu to Noto
The Wanderer left as an exercise for the reader: > I have been considering how best to test this in something like a live > environment, and have not yet settled on something that seems both > sufficiently doable in my setup and also sufficiently likely to produce > accurate results about my observations. I've been doing a lot of font comparison on arbitrary text using font-manager recently, if that's all you need. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
lintian groff-message warning "can't set the locale"
Hello there! My Salsa CI pipeline is blowing up in the lintian step, with lots of warnings of the form: "W: notcurses-bin: groff-message usr/share/man/man1/notcurses-demo.1.gz can't set the locale; make sure $LC_* and $LANG are correct" This is printed for each man page I package. An example run is here: https://salsa.debian.org/debian/notcurses/-/jobs/1107065 The only reference I could find was https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606933, which didn't seem relevant. Is this due to having supra-ascii UTF8 characters in my man pages? Is there anything I can do to work around this? I tried exporting LANG to a UTF-8 locale in my salsa variables section, but that didn't help. I'm using pandoc to generate my man pages, and it happily accepts UTF-8, but I can see a case for restricting them to ASCII. Thanks! -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: lintian groff-message warning "can't set the locale"
Felix Lechner left as an exercise for the reader: > It's not a problem with your package. Lintian's own pipeline is > likewise affected, even though our test suite completes fine in an > unstable chroot. The issue is being tracked here: > https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/182 Thanks for the quick response, Felix. You say that "[you] will probably start setting $LANG in that part of Lintian." what LANG will you be using? Attempting to set LANG=en_US.UTF-8 in my salsa ci variables resulted in setlocale(3) failing all over the place, presumably due to the locale not having been generated. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: lintian groff-message warning "can't set the locale"
Simon McVittie left as an exercise for the reader: > If you care about portability to non-Debian systems, note that C.UTF-8 is > a somewhat popular extension (I think it originated in the Fedora/Red Hat > family before it was adopted by Debian and other distros) but is far from > universally available. In particular, I'm aware of Arch Linux specifically > *not* having it. The glibc maintainers consider the implementation used > in e.g. Fedora and Debian to be a hack rather than something they want to > maintain forever, but my understanding is that they would be willing to > accept a better implementation. As I "need" this only within the Debian Salsa CI (and only to deal with this groff lintian warning, which it sounds like will be handled another way), a Debian-specific solution would be fine =]. Thanks for the details -- C.UTF-8 sounds like the right way to go. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
glibc 2.32 before bullseye?
I was wondering whether glibc 2.32 is expected to land in Bullseye. I'm guessing not, as I don't see a 2.32+ upload in experimental. In that case, I'd really like to have the Unicode 13 support introduced by 2.32 (if not the complete support, at least the wcwidth() elements). These seem pretty self-contained changes, especially the wcwidth() tables; would a patch backporting the glibc 2.32 Unicode 13 work be welcomed? -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: glibc 2.32 before bullseye?
Paul Wise left as an exercise for the reader: > On Fri, Dec 18, 2020 at 4:46 AM Nick Black wrote: > > I was wondering whether glibc ... > These seem like questions for the glibc maintainers, probably via a bug > report. indeed =] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977691 -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe.
investigating autopkgtest failures
I managed to push an update [0] that unexpectedly died in autopkgtests [1]. I'm thankful that the tests brought this problem to light, and grateful for the bug report--chalk it up as a nice win for autopkgtests! I'm now pondering how best to track this down, however, and at something of a loss. So far as I'm aware, the only artifacts left over from the run are the logs [2], unless one uses the AUTOPKGTEST_ARTIFACTS mechanism [3] (which I intend to start using ASAP). Even with artifacts tweaked to grab a coredump or whatnot, is there any way to test a modified package in the autopkgtest environment without a full archive upload? This particular program is pretty hardware-sensitive, and attempts to reproduce the bug locally have not yet been fruitful (though given that the autopkgtest failed on all architectures, it's likely less hardware-dependent than I'm making out). Ideally, I'd be able to run the autopkgtests as part of Salsa CI, which [4] suggests to be doable. Going even further, I'd be able to ssh into a failed autopkgtest environment (for some (short) time), and run some one-off experiments therein. Am I missing an existing process through which this is possible? Thanks! --nick [0] https://tracker.debian.org/pkg/growlight [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982786 [2] https://ci.debian.net/data/autopkgtest/testing/amd64/g/growlight/10443325/log.gz [3] https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html [4] https://debconf20.debconf.org/talks/39-running-autopkgtest-for-your-package/ -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: investigating autopkgtest failures
Antonio Terceiro left as an exercise for the reader: > I can trivially reproduce your autopkgtest failure locally with: > > $ autopkgtest -apt-upgrade --no-built-binaries growlight -- \ > lxc --sudo autopkgtest-unstable-amd64 Beautiful, thank you so much Antonio! > Now, your tests are full of > Couldn't get blkid probe for /dev/dm-1 (No such file or directory), > retrying... > which tells me they should probably not be being executed in a > container. Well, there's value in testing the failure case, too =]. So you would recommend the isolation-machine restriction? --nick -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
partman, growlight, discoverable partitions, and fun
Hello there, debian-boot! I am just finishing up the implementation of Discoverable GPT Partitions [0] in my growlight tool, and it seems a good time to see if I can push this discussion [1] forward. I'd like to sound out especially the d-i shareholders on replacement of partman with growlight. I can already hear hackles raising; I invite you to watch [2]/read [3] my Debconf 21 presentation, "Parting Ways with Partman", where I hope I've made a fairly complete and not-too-incorrect assessment of the situation. Essentially, my argument is that a tool which can both (a) play the system preparation role of partman in d-i and (b) function as a mainstream post-install disk management/analysis tool is likely to minimize time to support of new features, and doesn't consume developer time that can't be used outside of d-i. If any longtime developers are truly wedded to partman, I don't want to step on any toes; I'm the new guy; I certainly don't see any immediately compelling technical reason to make a switch. If you enjoy volunteer hackery on partman, great. I suspect, however, that partman is no one's great love. Growlight is a tool I've maintained and expanded over a decade, and intend to continue improving, outside of any system installation role. Christian PERRIER wrote on debian-boot 2013-02-07 [4]: "It's quite likely that the first step is then to have growlight in main Debian, isn't it?" Just so, and that was accomplished last year [5]. So let's move on to the second step, and consider this major move. I very very much hope you'll read through [3] with an open mind. Thanks! --nick [0] https://systemd.io/DISCOVERABLE_PARTITIONS/ [1] https://lists.debian.org/debian-boot/2013/02/msg00122.html [2] https://nick-black.com/tabpower/debconf21-growlight.mkv [3] https://nick-black.com/dankwiki/index.php?title=File:Parting_ways_with_partman.pdf [4] https://lists.debian.org/debian-boot/2013/02/msg00164.html [5] https://tracker.debian.org/pkg/growlight -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: partman, growlight, discoverable partitions, and fun
It supports MBR, GPT, and APM: https://github.com/dankamongmen/growlight/blob/master/src/ptable.c#L51-L123 (sorry for the gmail-style top posting; i can't find your mail in my mbox for whatever reason) Any other partition schemes ought be trivial to add; they've not been added yet simply because I don't have means with which to test them. Looking at the "partition types" section of the Linux configuration, I see: Acorn, AIX, Alpha, Amiga, Atari, Macintosh, MSDOS, BSD, Minix, Solaris x86, Unixware, Windows LDM, SGI, Ultrix, Sun, Karma, EFI/GPT, and SYSV68. Looking at the disk-label code from partman, I see: gpt, msdos, amiga, atari, mac, sun So the only ones covered by partman and not covered by growlight would be: amiga, atari, sun, and mac (if mac is not the same as APM). I don't see any difficulty in adding these four, so long as there's someone with an Amiga or ATARI who'd be willing to test them out. If there are no such people, is it that important? On Thu, Sep 23, 2021 at 5:29 PM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hello! > > On 9/23/21 22:57, nick black wrote: > > I am just finishing up the implementation of Discoverable GPT > > Partitions [0] in my growlight tool, and it seems a good time to > > see if I can push this discussion [1] forward. > > Does it support partition tables other than GPT, in particular all > of the partition tables that parted supports? > > If not, I don't think it would be a viable replacement for partman. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > -- nick black to make an apple pie from scratch, one need first invent a universe.
Re: partman, growlight, discoverable partitions, and fun
Marco d'Itri left as an exercise for the reader: > On Sep 24, Marc Haber wrote: > > > But maybe an alternative? I find the partitioning step one of the most > > error-prone and hard-to-use parts of non-trivial Debian installations. > And the preseeding syntax is as powerful as it is inconvenient. > I had not heard of growlight before yesterday, but from what I have read > I think that it is very promising. > > Implementing support for more partition formats, if missing, should be > rather easy. > But which ones do we need for architectures which are not actually dead? So, as I responded to Adrian [0], the only missing partition types appear to be amiga, atari, and sun. Adding them ought be simple enough, though I'd need testers with the hardware, or access to the hardware. My biggest worry personally (aside from the realpolitik of getting this change through) regards the automated partitioning language available through the preseed system. Trying to emulate this bug-for-bug is a non-starter, I think, both from a technical and quality-of-life standpoint. If the emulation can't be perfectly accurate, I don't think it ought be attempted for such a critical, delicate procedure. If faithfully honoring the preseed language is seen as a hard requirement (not that I've heard this from anyone), it's probably not happening. How important is that? I could do a limited implementation, perhaps, where I clearly error out on a spec I can't handle, falling back to partman. If, on the other hand, it seems time to revamp the automatic partitioning specification DSL, I could probably get behind that. Maybe even the old one; I'd need see how complex it is (I recall some pain trying to write complicated partman specs in the past, but it was many years ago). So...how do I go about making this happen? fwiw, I'm but a lowly DM, not a DD. --nick [0] https://lists.debian.org/debian-devel/2021/09/msg00365.html -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: partman, growlight, discoverable partitions, and fun
Adam Borowski left as an exercise for the reader: > I do have a different wish, though. Could you please purge any references > to drivemakers' units (stuff like MiB = million bytes, which current > partitioner maliciously[1] swaps around with proper MB of 1048576B)? this really probably belongs over in the growlight bugtracker, but: * i actually use the "memory units" for almost all interfaces, because that gives you the numbers you expect. for instance, my Seagate Exos 12TBs are 5859442688 4GB AF physical sectors, addressable as 23437770752 512B logical sectors. using tebibytes, this is 10.914TiB, as opposed to 12.000TB. as you can see at [0], we see 12T. there's only one place off the top of my head where they're *not* used, which is... > Having them in the user interface is deeply harmful: people will get > unoptimal alignment unless they 1. know about it, and 2. are careful enough. * alignment =] there we absolutely want to be using MiB etc., and we do. > >From your comments before I see that you try to do proper alignment, but in > too many cases no matter how you try, the installer won't align well enough > because the hardware might be newer than the version of growlight, hide its > inner workings for marketing reason (like stealth SMR drives), etc. > On the other hand, a completely oblivious user will get good alignment if > you show numbers measured in gigabytes rather than gillionbytes. so i'm not sure i necessarily buy that claim. if i'm overriding the default alignment, i typically want to specify a value that's independent of the disk size, and i always want it to be in a *iB unit. oh, do you mean secondary and later partitions? iirc, i accept (in addition to absolute sector numbers) a "+" syntax where "+1M" would mean "the first possible 1MiB alignment within this empty space", equal to the beginning of the empty space when it happens to start on 1MiB multiple. i don't know, mang; if i'm explicitly supplying sectors for alignment purposes, i'm checking units pretty carefully. preferably, i'm never doing that -- the only reason i can see would be if i want to leave some large (larger than the desirable alignment) chunk of empty space between two partitions. and again, in any kind of alignment context, that's when you *want* to be using MiB. and in such a context, "M" by itself is interpreted that way. > I know of only one case of multi-GB alignment (some early versions of ipmctl > wanted a multiple of 32GB because certain vendor BIOSes had problems with > smaller blocks), but the required alignment there is 1GB for years. where here i assume you mean 1GiB aka 2³⁰ bytes, not 1GB aka 10⁹ bytes, correct? you could enter that as 1G, or 1GiB, or 1024MiB, or 1048576KiB, or 1073741824. Using 1GB or 1000MB or 100KB or 10 would force undesirable behavior. changes to the text/UI to gently nudge users to the correct behavior will be cheerfully considered! > And most importantly: thanks for this effort, it's greatly appreciated! thank you for your kind words! i'd love to see this happen. --nick [0] https://nick-black.com/images/growlight-2021-09-26.png -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: partman, growlight, discoverable partitions, and fun
John Paul Adrian Glaubitz left as an exercise for the reader: > So, you are not using libparted then? i am not. > Yes, it is important as we're supporting these architectures in Debian Ports > and I invested quite some time to get Atari partition support added [1], > for example. I'd be delighted to support them -- as in, I am honestly eager to add ATARI support; that sounds awesome -- I just need some way to test the implementations, either via someone running it on the environment, or getting access to such a machine. > I think it makes little sense to not use libparted as it already supports > all common and less common partition types and reimplementing everything > that libparted makes little sense to me. parted did not have ZFS support when I embarked on this project (it appears to have it now). i would not be opposed to leveraging libparted if it presents a definite advantage; supporting more partition types, so long as it exposes an API i can easily work with, would be such an advantage. i do note that libparted2 is 621K in the archive, whereas growlight itself is only 555K. it is of course possible that all that weight is desirable functionality. with that said, i would *still want to test on the target environment*, to make sure i'm using libparted correctly there. so that necessity remains. would this allay your concerns? --nick -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: partman, growlight, discoverable partitions, and fun
Marc Haber left as an exercise for the reader: > But maybe an alternative? I find the partitioning step one of the most > error-prone and hard-to-use parts of non-trivial Debian installations. so overall, i've got to say the feedback i heard here was a lot more positive than i was expecting, though there was a bit less than i had hoped for. but perhaps something that can be touched would see more interest? given that no one seemed to reject the idea out of hand, i'm going to go ahead and rebase my work from 2012 (or more likely look at it once and redo it) in a Salsa fork of d-i, and make some installation media available. forgive me for likely only having x86 available at first. i'll try to have this done within a week or so, and put it up on my server. people can then give it a whirl. it's hard to see how exactly i proceed from that point, save in a reactive fashion (not complaining, just saying). but we'll see what happens when an ISO is available! note that there would still be some questions where i'd need input from Project members (as noted in my Debconf [0] presentation), particularly regarding translation (even if i can lift significant portions from partman, i'd need it looked over) and facilitating accessibility technology. --nick [0] https://nick-black.com/dankwiki/images/b/b9/Parting_ways_with_partman.pdf -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: partman, growlight, discoverable partitions, and fun
Wouter Verhelst left as an exercise for the reader: > One thing that partman does is "support plug-ins", to allow for > configuring block devices before being able to partition them, where > needed. This can be useful for iSCSI, multipath, or (the one I care most > about) NBD. I wrote a "partman-nbd" a few years back to do just that: > https://salsa.debian.org/installer-team/partman-nbd Thanks a lot for pointing this out, Wouter -- this is *exactly* the kind of feedback I was hoping for! I allow loopback devices to be set up, but not in any reboot-crossing manner, and I have no NBD nor iSCSI functionality. https://github.com/dankamongmen/growlight/issues/150 -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: partman, growlight, discoverable partitions, and fun
Wouter Verhelst left as an exercise for the reader: > iSCSI works very differently and is way more complex, but I remember > from when I last played with it (which is a while ago, so the details > are hazy) that it's not possible to set up in a non-persistent manner > (i.e., all iSCSI connections survive reboot unless explicitly deleted, > although obviously partman-iscsi has to do some dark magic to ensure the > configuration is migrated from the d-i environment to the live system). i've actually worked pretty extensively with iSCSI--i presented on it at LPC2015 [0] =]. as far as i understand, iSCSI connections are initiated and managed by the iscsid userspace daemon (aside from root-on-iSCSI, which uses iscsistart, or at least did. UEFI/BIOS iSCSI can also server here). > There's also ATA-over-Ethernet, Fibrechannel-over-ethernet, multipath, > and a whole slew of other things, if you want to configure this from > growlight. as you note, most of this is not stuff i want to slap a UI on, but i'd certainly want to hit full partman feature parity...in time. if it's best early on, i feel no shame punting more esoteric setups to partman; as i've said, i would expect partman to remain present on the installation media for at least some significant time. > I could be wrong though, haven't looked at growlight in much detail, and > in the end it's your call, not mine :-D nope, pretty much totally correct. --nick [0] https://nick-black.com/dankwiki/images/e/ea/Public_LPC2015_-_Dynamic_iSCSI_at_Scale-_Remote_paging_at_Google.pdf -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: partman, growlight, discoverable partitions, and fun
Steve McIntyre left as an exercise for the reader: > 100% true - expect people are busy, rather than hostile! :-) i must have come across as far more disappointed than i felt -- i meant "hoped" in the literal sense, of "did not expect, but thought plausible and welcome" =]. no, this has been an A-, A interaction in my book--i half-expected flat rejection. so thanks, debian! i will return to my codehole and bring back something more tangible. but i found this quite promising. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5
Russ Allbery left as an exercise for the reader: > My intuition (I admit that I haven't done a survey) is that Files-Excluded > is less frequently used for cases where upstream has not done license > verification and is more frequently used for cases where upstream > disagrees with Debian over what is and is not free software. (IETF RFCs > are a sadly common example.) just as a personal example, i've got a fairly elaborate Files-Excluded [0] for freely-distributed but DFSG-incompatible media included with my upstream tarballs. doing so was easier than trying to recreate e.g. jpegs as GIMP xcfs. [0] https://salsa.debian.org/debian/notcurses/-/blob/master/debian/copyright#L9 -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
non-word "noone" in constitution
i was reading our Constitution, and §5.1.4 states: "Make any decision for whom noone else has responsibility." "noone" is a non-word [0], and while i doubt it'll ever be the basis of a court ruling or anything, "no one" was correctly used in the language added to 6.3.6 by Constitution v1.8, and another instance of "noone" was removed from §A.1.6. so unless it requires a vote or something, it should probably be fixed? i submitted an MR to doc-debian [1], but given that we're currently shipping the old Constitution v1.7 to /usr/share/doc/debian/constitution.txt.gz [2], that doesn't seem quite authoritative. who would i report this bug to? "project" pseudo-package, as suggested in [3]? --nick [0] https://writingexplained.org/noone-or-no-one-difference https://grammarist.com/spelling/no-one-noone/ etc [1] https://salsa.debian.org/ddp-team/doc-debian/-/merge_requests/1 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23839709 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=210879 -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: feedback for NEW packages: switch to using the BTS?
Paul Wise left as an exercise for the reader: > Packages with incomplete or incorrect debian/copyright information > currently would recieve a REJECT rather than acceptance. The proposal > would not change that, just turn that REJECT into a bug report, which > you could fix in a second upload to NEW and then the package would be > reprocessed and get an ACCEPT or another bug. currently, as far as i understand things, a REJECT can be issued for the first REJECT-worthy problem. if resolving the resulting bug report is the bar needing clearing to enter the archive, that does seem to require FTPmasters to create a complete statement of REJECT-worthy problems in each uploaded package, which seems like more work than they must currently do. if the resulting bug is *not* a complete statement of problems, and that is understood, this isn't an issue. just a thought. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: feedback for NEW packages: switch to using the BTS?
Paul Wise left as an exercise for the reader: > > if resolving the resulting bug report is the bar needing clearing to > > enter the archive, that does seem to require FTPmasters to create a > > complete statement of REJECT-worthy problems in each uploaded > > package, which seems like more work than they must currently do. > > The bar for acceptance would be the same as it is now, the proposal > just changes how the issues blocking acceptance are communicated. > Now you get a REJECT mail, under the proposal you get a serious bug. i understand. i suppose that what i'm saying is it will probably be worthwhile to convey in Mentors etc. documentation that "resolving the bugs filed thus far [regarding the package in NEW] does not imply that no further bugs will be filed." i'm just worried that people will get a bug filed that is not a complete, exhaustive analysis, and think that it's the only thing standing between them and archive glory. perhaps whatever files the bug ought indicate this in the text of the bug itself. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: feedback for NEW packages: switch to using the BTS?
Paul Wise left as an exercise for the reader: > I think the same problem and suggestions also apply with the current > system of prods and rejects, so please do add or propose adding it in > the appropriate documentation and templates. I will of course seek to > preserve these statements if I end up working on the BTS proposal. absolutely, there's just enough opacity in a current REJECT (in my fairly minimal experience) that i think it less susceptible to such invalid inferences. but yes, this is something that could go in the Mentors notes now. (to be sure, at no time did i intend to impugn your suggestions in this thread, which seem a definite improvement from the user's perspective.) -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
adduser 3.12x notes
Marc, your recent adduser notes have been really interesting reads; i've learned more about adduser from the past two releases than i think i ever knew. it seems good work, too. =] way to be. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: Transition proposal: pkg-config to pkgconf
Andrej Shadura left as an exercise for the reader: > It seems like the proposal went mostly unnoticed. Any comments, ideas, > anything? fwiw, every time i've looked at a difference between the two, pkgconf was superior in every way. i've worked with the primary author, ariadne conill, on some Alpine stuff and some Notcurses stuff, and she's as competent and sedulous as they come. i'd love to see this transition, and appreciate you working on it. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe.
Re: Intel CET Support?
Paul Wise left as an exercise for the reader: > On Mon, 2022-09-05 at 22:44 +0200, Felix Potthast wrote: > > > i just stumbled upon the fact that debian doesn't yet make use of the > > Intel CET security feature, while many other distributions > > (Ubuntu, Fedora, Suse, Arch Linux) do. > > Allegedly Intel CET provides weak protection, although perhaps it > improved since the 2016 analysis by grsecurity folks: > https://grsecurity.net/effectiveness_of_intel_cet_against_code_reuse_attacks ehh, CET seems like the kind of "make easy things hard" defense-in-depth that's the cornerstone of protecting against the highest level of attackers. ASLR and a dozen other things are in the same boat; they make attacks more difficult to generalize and make reliable. also, the grsecurity folk in my experience tend to speak very harshly regarding any other efforts in their space (and they prefix this article with disclosure that CET can be considered competing technology). see their comments on other software CFI implementations [0] and kspp [1]. they explicitly sum up that "CET is not advancing the state of the art", which indeed it might not be, but that doesn't mean it's a useless piece of engineering. it has a value that needs be weighed against its cost like most technologies. [0] https://grsecurity.net/rap_faq [1] https://lwn.net/Articles/698891/ -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: Intel CET Support?
nick black left as an exercise for the reader: > that's the cornerstone of protecting against the highest level s/the high/anyone but the high/ =\ -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab
i'm pretty sure that the corruption issues leading to the nodelalloc option were considered largely remedied by the "auto_da_alloc" capability introduced (and enabled by default) in 2.6.30? how would nodelalloc equal the performance of delalloc? nodelalloc was all about reliability for programs that weren't conforming to certain POSIX semantics, as i recall.
Re: RFH: Packaging Intel's userspace tools for Data Streaming Accelerator
Gunnar Wolf left as an exercise for the reader: > So... Is anybody among debian-devel readers interested in helping > Debian support this hardware feature? Extra points for people that > _have_ the suitable hardware! (I don't) my current professional plans include evaluating DSA and integrating it into my product if it proves itself, and this kind of thing is directly up my alley besides. i'm one of the newest DDs, but i'd be very happy to work with Jair and Miguel. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
need we support unshadowed passwords from the installer
it's 2023 and imho time to stop supporting unshadowed passwords from the installer. https://salsa.debian.org/installer-team/user-setup/-/merge_requests/5 1) nis (and possibly conserver?) seem the primary drivers of an unshadowed passwd.=20 let me freely admit that, despite the advanced age of forty-two (seventy-eight in UNIX years), that i know nothing about nis/yp except that there was a big o'reilly book about it back when one read the security book with the big safe on the front and the scripting book with the big drill. i suspect it's basically a halfway point between syncing /etc/passwd and /etc/hosts with cron+rsh, and hiring someone on whom you can inflict ldap? so please correct me wherever i'm woefully ignorant. ...but it appears that NIS can be made to work with shadowed passwords (though without their benefits). this is from a cursory reading of a FAQ last updated in 2003, so take it with a grain of salt. the "linux network administrators [sic] guide" seems to confirm this, and can also help you set up IPX or UUCP. 2) it seems that the unshadowing of passwords is only a "/sbin/shadowconfig off" away. somewhere down the long road, we appear to have lost shadowconfig.8, but this is what i gather from web searches. i'd almost suggest this might want to go into the "nis" package, avoiding "why do we even have that lever" situations, but i resolutely oppose feature creep for this MR. 3) if someone accidentally selects this during install, i can't think of any means by which they'd find out during the course of typical systems administration. 4) i don't have to answer this question in any other installer i've used in the past decade, i'm pretty certain. 5) arch appears to support NIS without any mention of shadowing? though admittedly that wiki page is "somewhat unfinished"[0] 6) fedora has recently discussed eliminating NIS support entirely. it's a done deal in RHEL. i'm absolutely not suggesting we stop supporting NIS or other programs which rely on unshadowed passwords. it's a big ol' tent, and we have more than enough room for you to carry forth the torch of Solaris 2. i just don't think this belongs in the installer anymore. --rigorously, nick [0] https://wiki.archlinux.org/title/NIS -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: need we support unshadowed passwords from the installer
Marc Haber left as an exercise for the reader: > On Fri, 13 Jan 2023 21:11:40 -0500, nick black > wrote: > >i'm absolutely not suggesting we stop supporting NIS or other > >programs which rely on unshadowed passwords. it's a big ol' > >tent, and we have more than enough room for you to carry forth > >the torch of Solaris 2. i just don't think this belongs in the > >installer anymore. > > Amen. NIS-based systems usually have professional administrators who > are well able to change the configuration. hahah, yes i thought you might support the idea based off adduser changelogs circa 2005 =]. thanks to you and peter for voicing your support. i will head off to #debian-boot and try to drum up a merge. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: need we support unshadowed passwords from the installer
Sam Hartman left as an exercise for the reader: > Yes, absolutely. > I am familiar with nis/PAM/shadow/LDAP, have deployed NIS (although not > nisplus), and have been around long enough to understand the issues. > > It is absolutely reasonable to expect people who need to do so to > unshadow their own passwords. thanks Steve McIntyre for the merge! as an aside, as a fairly new DD, i've seen a lot of worry in recent years about the difficulty of getting changes through given the distributed ownership of packages, etc. i was frankly worried about this being difficult to see through, despite it being a small and agreed-upon change (there was certainly no way i was going to NMU the installer). it was merged this morning after authoring the MR through salsa two evenings ago, quite painlessly. this is anecdotal and perhaps not representative of Project dynamics as a whole, but i for one feel more comfortable about proposing and executing small changes like this now. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Bug#950492: ITP: notcurses -- Character-mode graphics and TUI library
Package: wnpp Severity: wishlist Owner: Nick Black * Package name: notcurses Version : 1.1.4 Upstream Author : Nick Black * URL : https://nick-black.com/dankwiki/index.php/notcurses * License : Apache-2.0 Programming Lang: C, C++, Python Description : Character-mode graphics and TUI library notcurses facilitates the creation of modern TUI programs, making full use of Unicode and 24-bit direct color. It presents an API similar to that of Curses, and rides atop libtinfo. Work on notcurses began in November of 2019, and it has had Debian-compatible infrastructure (debhelper compat level 12) from the beginning. As of February 2020, it is rapidly stabilizing, and being used in several tools. I've rewritten my "growlight" disk management tool using notcurses instead of ncurses, cutting out several thousand lines of UI code along the way. Nestopia is about to merge notcurses support (coming out of maintenance mode to do so). I'm working on a console SDR visualization tool that will make working with remote SDRs much more pleasant, and expect to release it soon. Sid/unstable debs are available (and have been available for weeks) in my repo at https://www.dsscaw.com/apt (this repo is available in Wouter Verhelst's extrepo tool). The Debian packaging that I currently have can be seen here: https://github.com/dankamongmen/notcurses/tree/master/debian Notcurses can be regarded as a successor to ncurses. It provides much of the functionality of that package, with major improvements IMHO regarding Unicode, multithreading, and color support. 24-bit RGB with two bits of transparency is the fundamental color space, and input/output are entirely based off UTF8 and Unicode's Extended Grapheme Clusters. I've written many thousand lines of ncurses code in my life, and expect to write no more--notcurses will entirely supplant it in my projects. ncurses is a venerable, robust library, with a fantastic maintainer in Thomas E. Dickey, but it's fundamentally bound to X/OSI. It's time to move past 90s-era TUI APIs. As for maintaining the package, I've written 90%+ of the code in notcurses, and intend to maintain it for the long haul. I'm actively committed to maintaining the Debian/Ubuntu packaging, and indeed hope to use it as a springboard towards Debian Developer status. notcurses has been included in Arch's AUR since its 0.4.0 release in November 2019.
Re: RFC: "Recommended bloat", and how to possibly fix it
Colin Watson left as an exercise for the reader: > (https://peps.python.org/pep-0508/#extras): effectively groups of > additional dependencies to enable some kind of feature that you can opt > into if you need that feature, rather than having to pick from an > undifferentiated pile of Recommends, or do things like devscripts does the "undifferentiated" feels like it's doing some lifting here. arch's yay (and presumably other tools in the pacman family) shows a short justification for each optdepends[0] entry (when such information is provided). it would require not just control file changes but also UI work, of course. --nick [0] https://man.archlinux.org/man/PKGBUILD.5 -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: Musings about Usernames in adduser and Debian
Gioele Barabucci left as an exercise for the reader: > On 23/11/24 09:32, Johannes Schauer Marin Rodrigues wrote: > > But my 2 cents on the topic are: Lets please allow more than ascii in > > usernames. > > potentially insecure (homographs) and at > high-risk of breaking existing applications (lack of standardized > normalization form). i'm not sure why this is being repeated. https://unicode.org/reports/tr15/ -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe.
Re: Bits from DPL
Jeremy Stanley left as an exercise for the reader: > Would I bother to go through NM now if the process were more > simplified/streamlined? Maybe, but probably not. As you noted, > priorities matter and it's entirely possible to be involved in > Debian without that (depending on what exactly you want to do of > course). There's quite a lot that doesn't require upload permissions i became a DD in 2022, and thought it overall a low-effort process (it wasn't fast by any means, and getting sponsors/endorsers was a kinda unpleasant bit of mendicancy, but humility is endless). the actual application was entirely asynchronous, and just a matter of reading some document and man pages and distilling answers. i urge anyone reading this not to let the ~8 hours required keep them from applying. > in the archive, and also quite a lot of amazing people with upload > permissions who are happy to help on the occasions it's needed. the personal appeal of uploading privileges is the ability to work without a dependency on others, but it sounds like that's not a motivator for you. i do think current statistics wouldn't seem to capture contributors like you, despite your (perhaps indirect) impact being DD-comparable. still, this can't scale freely without a bottleneck at DDs. -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: Musings about Usernames in adduser and Debian
G. Branden Robinson left as an exercise for the reader: > It sounds like you want something isomorphic, if not identical, to, > Punycode. > > https://en.wikipedia.org/wiki/Punycode it's my understanding that Punycode's objective is to be "clean" with regards to things that match against the hostname character set, hence its pickup for IDN (where it's expected that DNS will be traversing all kinds of network middleware). a similar (obsolete) proposal was 7 bit-clean UTF-7. i don't see this as a necessity for this effort, as we have access to the entirety of the stack that'll be touching this material. it's just a matter of having that stack match, store, and display things properly. -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: Musings about Usernames in adduser and Debian
nick black left as an exercise for the reader: > it's my understanding that Punycode's objective is to be "clean" > with regards to things that match against the hostname character > set, hence its pickup for IDN (where it's expected that DNS > will be traversing all kinds of network middleware). a similar > (obsolete) proposal was 7 bit-clean UTF-7. it occurs to me that the properties of UTF-8 might not be in the forefront of everyone's minds. there are several good references to its properties and advantages [0] [1] [2]; i'll quote myself [3]: Unicode Technical Report #17 defines seven official Unicode character encoding schemes: UTF-8, UTF-16, UTF-16BE, UTF-16LE, UTF-32, UTF-32BE, and UTF-32LE. What a wealth of encodings! How is one to choose? The -16BE and -16LE forms are simply UTF-16 with a known byte order; a UTF-16 stream can (optionally!) be prefixed with a Byte-Order Mark, at which point the stream reduces to -16LE or -16BE (in the absence of a BOM, the best advice is to follow your heart). UTF-32 breaks down the same way. This question of endianness arises from the fact that UTF-16 and UTF-32 are coded in terms of 16- and 32-bit units. UTF-8, being coded in terms of individual bytes, has no need to define byte order. “Well, that BOM sounds kinda annoying,” I hear you asking. “What other advantages are offered by UTF-8?” Remember how ANSI X3.4-1986 maps precisely to the first 128 characters of UCS? UTF-8 (and only UTF-8, of the official encodings) encodes these 128 characters the same as US-ASCII! Boom! Every ASCII document you have—including most source code, configuration files, system files, etc.—is a perfectly valid UTF-8 document. Furthermore, UTF-8 never encodes non-ASCII characters to the ASCII bytes. So an arbitrary UTF-8 document may have plenty of high-bit bytes that your ASCII-aware, POSIX-locale program doesn’t understand, but it never sees a valid ASCII character where one wasn’t intended. UTF-8 encodes ASCII’s 0–0x7f to 0–0x7f, and otherwise never produces a byte in that range. This includes the all-important null character 0—Boom! Every nul-terminated C string is a valid UTF-8 string. Every UTF-8 string can be passed through standard C APIs cleanly, and they’ll more or less work. It’s furthermore self-synchronizing. If you pick up a UTF-8 stream in the middle, you know after reading a single byte whether you’re in the middle of a multibyte character. “Sweet! What’s the catch? Does it waste space?” RFC 3629 limits UTF-8’s range to the 17 ∗ 2^16-ary code space of UCS, in which case the maximum length of a single UTF-8-encoded UCS code point is four bytes [4]. It’s thus always as or more efficient than UCS-32. When the ASCII characters are used, UTF-8 is more efficient than either UTF-16 or UTF-32. Only for streams utterly dominated by BMP codepoints requiring three or more bytes from UTF-8 can UTF-16 encode more efficiently. “Sweet! What’s the catch? Is it super slow?” UTF-32, it is true, allows you to index into a string by character in O(1) (UTF-16 does not, unless you’re only dealing with BMP strings). UTF-32 also allows you to compute the bytes necessary for encoding in O(1), given the number of Unicode codepoints, but that’s only because it’s wasteful; if you’re willing to be similarly wasteful, you can do the same calculation with UTF-8 (and then trim any wastage at the end, if you wish). Any advantage UTF-32 might hold in lexing simplicity is likely a wash when UTF-8’s usual space efficiency is taken into account, owing to more effective use of cache and memory bandwidth. Nope, it’s not slow. *Always interoperate in UTF-8 by default.* UTF-16 is some truly stupid shit, fit only for jabronies. It only ever passed muster because people thought UCS was going to be a sixteen-bit character set. The moment a second Plane was added, UTF-16 ought have been shown the door. There’s an argument to be made for ripping it from the pages of books in your local library. If you must work on a UTF-16 system, use UTF-16 at the boundary, and then keep it around as UTF-32 or UTF-8. Always interoperate—including writing files—in UTF-8 by default. There are a dozen-odd similarly-named encodings which are useful for nothing but trivia. UCS-2 was UTF16, but for only the BMP. UCS-4 is just UTF-32. UTF-7 is a seven-bit-clean UTF-8 [5]. UTF-1 is UTF-8’s older, misshapen sister, locked away from sight in the attic. UTF-5 and UTF-6 were proposed encodings for IDN, but Punycode was selected instead. WTF-8 extends UTF-8 to handle invalid UTF-16 input. BOCU-1 and SCSU are compressing encodings that don’t compress as well as gzipped UTF-8. UTF-9 and UTF-18 were jokes. Is UTF-EBCDIC a thing? Of course UTF-EBCDIC is a thing. The one place where you won’t interoperate with UTF-8 is for domain name lookup, when converting IDNA into the LDH subset of ASCII. If you’re interested, consult RFC 3492, and Godspeed. --rigorously, nick [0] https://research
Re: Musings about Usernames in adduser and Debian
Marc Haber left as an exercise for the reader:
> > * any upstream tool could say "bad idea" and refuse patches,
> >requiring their long term management,
>
> Depending of how important this tool is, we could get away without
> patching and probably not even documenting this failure.
This kind of attitude seems self-defeating. Despite being
*strongly* in favor of this effort, I would oppose it if were
strictly a Debian thing. We can inspire the move, but going it
alone seems a recipe for present and future pain (think SSHing
from/to Debian and a non-Debian machine).
> > * the Linux framebuffer console is pretty limited in what
> >glyphs it has available, and the number of glyphs it can
> >support,
>
> Probably, yes. But people working on the Linux framebuffer console are
> unlikely to actually use UTF-8 user names, so the only really bad
With all due respect, this seems totally unsupported by anything
other than vibes =].
> > * broken localization (or failure to call setlocale()) could be
> >a bigger problem, especially for root/system accounts.
>
> I don't think we should allow UTF-8 charactes in the string "root" or in
> system account names. And if a local admin decides to do so, Debian
> packages should still restrict themselves to using US-ASCII in their
> system accounts.
Why? This would require multiple code paths for what seems to me a
very questionable objective. You point out later in your
response that there already exist diverging codepaths, but isn't
unifying such things always a goal?
> Do you have a suggestion for a perl regexp that allows this? My current
> development directory has "qr/[\p{Graph}*\.\${}><%'@]+/".
I do not. This is not a regex problem in my mind and experience;
you need full access to complicated libraries. Any such effort
should go through Annex 15 canonicalization before being
inspected at all. At that point, you're well past regular
languages so far as I can tell. I do not see this goal as
possible with small surgeries on the adduser code base, but
rather something that requires work across the chain.
> > Names containing invalid UTF-8 sequences ought be rejected.
> Agreed. How do I check for this in perl?
I have no idea. It's not very simple. Here's code from my
Notcurses library that extracts a single EGC from a UTF8 string:
https://github.com/dankamongmen/notcurses/blob/a5c7d2262a53bd5c3428c9397de4864c79ff/src/lib/egcpool.h#L87
> > My printer is administered by
> > i̸̒n̴͛e̵̎l̴͝u̷̾c̴̉t̵́å̵b̷͋l̷͐e̴̋m̸̆o̷̚d̴̐ä̸́l̶͝i̷̋t̷͗ẏ̷ȏ̵f̸̃t̶͘h̷͗e̴̿v̶͘i̷̛s̸̈́ì̵b̷̃l̶̎e̷͊.
> That really renders strangely here.
That was intended, to demonstrate the complexity of potential
strings we might have to deal with.
> > It cannot. "C" is not UTF-8. Assumption of UTF-8 requires a
> > properly set LANG and programs calling setlocale(). This, as
> > alluded to above, has the potential for a big mess.
> Our default is C.UTF-8 and has been like that for a while.
Yes, but that can be changed.
With all due respect, I admire your gung ho candoit spirit, but
adduser alone is not IMHO the place. This is a major change
requiring support from libraries, applications, and UI to do
right, and thus wide buyin. I love the idea, but it's not going
to happen with a few Perl regexes. Please don't read this as
commentary on you or your code.
--
nick black -=- https://nick-black.com
to make an apple pie from scratch,
you need first invent a universe.
signature.asc
Description: PGP signature
Re: Musings about Usernames in adduser and Debian
Gioele Barabucci left as an exercise for the reader: > You may have misunderstood that phrase. I was not referring to the fact that > there are no standardized normalization forms for Unicode (I explicitly > mention Annex 15 in [1]), but to the fact that there is no standard that > specifies which of the possible normalization forms should be used for > account names (and other fields in passwd). > POSIX explicitly limits itself of a subset of ASCII, so it is not going to > mandate any normalization form. Are there other standards (or initiatives) > in this area that you know of? I'm glad we're both on page for Annex 15, and indeed, POSIX does seem to explicitly exclude any work in this area. Assuming we're willing to go beyond POSIX (and again, this seems something where we'd want to loop in other distributions, and probably kernel developers), I'm honestly not sure which of the Annex 15 canonicalizations we'd want to use -- I'd like to hear from experts (or at least people with extensive experience outside of US-ASCII) as to which method is best. I have no dog in that hunt, save that everyone agrees on a method. It's for this reason that I think any work in this area needs be encapsulated in a common library. -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe.
getting ziggy with it
previous efforts have been made to package the zig programming language [0].
the most recent release of the zig programming language was 0.13.0 [1]
on 2024-06-07. bug #1012286 declares an ITP for zig 0.9.1 [2], but the work
there seems to have trailed off in the 0.10 era. jonathan carter started
working on it independently a few weeks back, but the work i've
done this weekend goes beyond his afaik [5]. i am interested in getting
zig in debian both on its own account, and as part of packaging ghostty [4].
i am not an expert regarding zig, but i believe the following to be true:
later that year, zig changed the way it bootstraps [3]. there was already a
"zig-bootstrap" repository and "zig" repository, both of which are released
together. the relevant elements: "zig-bootstrap" now ships with a binary WASM
file (zig1.wasm), which is converted to a c file (zig1.c) using a tool built
using the local c compiler (wasm2c). this c file is compiled using the system
compiler to produce zig.
this wasm file is, again, distributed with the zig-bootstrap and zig sources.
it is a binary and knocks us out of main. this file can be recreated, using
sources from within the zig repository, with a working zig. but even the
"zig-bootstrap" source cannot move forward without either this file or
a working zig with which to create it ("zig-bootstrap" is more about
vendoring LLVM).
the last release without this wasm component is 0.10.1, which i've been
targeting as "zig-10-bootstrap". it requires neither the wasm binary nor
a working zig. unfortunately, it does require llvm 15--not 14, not 17,
but 15. supporting a different llvm would require changing quite a bit
of tightly-coupled C++ that is no longer being maintained upstream.
llvm-15 is not in sid, btw, though llvm-14 is. so we would need bring
llvm-15 back into sid. attempting to build llvm-15 1:15.0.7-15 from source
on sid blew up; i didn't look deeply into it yet (i can confirm that
"zig-10-bootstrap" using its vendored LLVM 15 builds on sid, fwiw).
note the upstream's statement:
"Now, there is this WebAssembly binary, which is not source code, but is in
fact a build artifact. Some people, rightly, take these things very seriously -
see for example the Debian Free Software Guidelines. I openly acknowledge that
this cost is being paid, however, I strongly believe that it is worth it in the
end. I suspect that combined with an official language specification and a
growing popularity of Zig, we will see a third-party project start an alternate
Zig implementation in C, similar to how mrustc exists for Rust (despite not yet
having a spec). This would fill the necessary role to solve O(1) source
bootstrapping again."
perhaps.
so the choices as i see them:
- wait on this zig ex machina foretold by legend, perhaps until the sun
expands, consuming earth
- put zig in non-free. anything building with it is stuck in contrib.
pretty unappealing.
- maintain the ~20K lines of zigcpp myself. this will need to be
kept up with the historically rapidly evolving LLVM API.
similarly unappealing. maybe more.
- reintroduce llvm-15 to sid, get it working, introduce zig-10-bootstrap
to sid, make it a build-dep of zig, devendor zig, build with system llvm.
the devendoring has already been done. not terrible, but i'd like to
hear llvm team's thoughts and anyone else's thoughts. so far as i can
tell, this would require llvm-15 and zig-10-bootstrap to be carried
indefinitely into the future.
but perhaps someone else can think of something better?
[0] https://ziglang.org/
[1] https://ziglang.org/download/
[2] https://lists.debian.org/debian-mentors/2022/06/msg00023.html
[3] https://ziglang.org/news/goodbye-cpp/
[4] https://ghostty.org/
[5] https://salsa.debian.org/nickblack/zig-bootstrap,
https://salsa.debian.org/nickblack/zig-10-bootstrap,
https://salsa.debian.org/nickblack/zig
--
nick black -=- https://nick-black.com
to make an apple pie from scratch,
you need first invent a universe.
signature.asc
Description: PGP signature
Re: getting ziggy with it
nick black left as an exercise for the reader:
> this wasm file is, again, distributed with the zig-bootstrap and zig sources.
> it is a binary and knocks us out of main. this file can be recreated, using
> sources from within the zig repository, with a working zig. but even the
> "zig-bootstrap" source cannot move forward without either this file or
> a working zig with which to create it ("zig-bootstrap" is more about
> vendoring LLVM).
i looked at a few other distros:
- arch just builds it and is done with it
- guix, from what i can tell, is picking up a previous zig build of
their own and using that to bootstrap. i am 0% certain of this
interpretation [0].
- fedora looks promising; they certainly remove zig1.wasm before
building; i will examine this further.
[0] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/zig.scm
[1] https://src.fedoraproject.org/rpms/zig.git
--
nick black -=- https://nick-black.com
to make an apple pie from scratch,
you need first invent a universe.
signature.asc
Description: PGP signature
Re: A 2025 NewYear present: make dpkg --force-unsafe-io the default?
Julien Plissonneau Duquène left as an exercise for the reader: > - io_uring that allows asynchronous file operations; implementation would > require important changes in dpkg; potential performance gains in dpkg's use > case are not yet evaluated AFAIK but it looks like the right solution for > that use case. i've got a lot of experience with io_uring [0] [1], and have been closely tracking it, and would be interested in helping out here if it's thought that such an experiment would be useful and welcomed. be aware that taking full advantage of io_uring, especially in a program with concurrent computation, can require some pretty substantial restructuring. if the issue could be solved with e.g. parallel fsync operations, that might be a much quicker way to pick up much of the potential performance advantages. it seems outside dpkg's province to manipulate queue depth, but that would be an important parameter for using this most effectively. chained operations will likely be useful here. --nick [0] https://nick-black.com/dankwiki/index.php/Io_uring [1] https://nick-black.com/dankwiki/index.php/Io_uring_and_xdp_enter_2024 -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe.
Re: Musings about Usernames in adduser and Debian
Johannes Schauer Marin Rodrigues left as an exercise for the reader: > Quoting nick black (2024-11-23 08:48:10) > > You now have glyphs which occupy more than one column. Are your > > columnar/tabular programs prepared for that? ﷽𒁭𒐫i > > xfce-terminal renders this like this: https://mister-muffin.de/p/4o2v.png more correctly, it renders it like that when using your font, with its current font rendering engine. very little can be assumed here. thankfully, presentation shouldn't be that big of a deal outside of tabular UIs. -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: Musings about Usernames in adduser and Debian
Marc Haber left as an exercise for the reader: > (1) > Should Debian allow UTF-8 user names in the first place or should we > restrict names for regular users to some us-ascii near set as well? (I > think yes, we should) I feel strongly yes, despite POSIX admonitions (quoted elsewhere in this thread) and sure breakage any number of places. I think a test plan would be very desirable (off the top of my head, we'd want to check login, the DMs, PAM, OpenSSH, passwd, w, framebuffer console input, etc. It would probably also be a good idea to loop in other distributions. I recommend Chapter 7 of my free book, "Hacking the Planet with Notcurses: A Guide to TUIs and Character Semigraphics" for the full story (as I understand it) regarding Unicode presentation: https://nick-black.com/htp-notcurses.pdf (starts on page 41). Some serious concerns: * any upstream tool could say "bad idea" and refuse patches, requiring their long term management, * the Linux framebuffer console is pretty limited in what glyphs it has available, and the number of glyphs it can support, * you want installer support if you intend to do this right, * ubiquitous input for UTF-8 is a pretty complicated story, and * broken localization (or failure to call setlocale()) could be a bigger problem, especially for root/system accounts. Other concerns: You'll likely now be linking libunistring into some binaries where it wasn't previously used. Regarding the subset of Unicode characters you'd want to allow, this would be best decided using the General Category trait. Each codepoint is assigned one of a finite set of General Categories. We would probably want to allow Letters, Marks, and Numbers, and perhaps a whitelist from Punctuation and Symbols (Punctuation, connector and Punctuation, dash are probably all we'd want) extended from currently supported ispunct(3) characters. This data is available from libunistring (and probably other places). This eliminates a great swatch of known security issues. Names containing invalid UTF-8 sequences ought be rejected. Characters 0-127 would presumably be allowed iff they are now; UTF-8 preserves US-ASCII. We ought support combining characters up through the Extended Grapheme Cluster (a single user-perceived character, roughly a glyph, made up of one or more encoded characters). Generally a single backspace ought map to an entire EGC. Regarding canonicalization/normalization, this is a complex question without a necessarily correct technical answer. I think you'd want to follow the Principle of Least Astonishment; as to what would astonish the least, I'd like to hear wider input. But Unicode definitely defines multiple normal forms and equivalency classes. You now have glyphs which occupy more than one column. Are your columnar/tabular programs prepared for that? ﷽𒁭𒐫 > (2) > If the answer to (1) is "allow UTF-8", should we also do that for system > users? (I think no, we should not) I think you should, simply because otherwise you have two paths in more places. > (2a) > Which UTF-8 subset / code point classes should we allow and which should > we reject? (I don't have an opinion about that) Answered above. > (3) > I think that 32 characters/bytes (it's the same if we don't allow UTF-8) > is a good limitation for a system user name. But, should we increase > that for regular user names? (I think yes) I hesitate to comment here because who really cares, but does 32 save us something over 128? 128 seems the default "enough for everybody" these days, looking at IPv6 and ZFS. My printer is administered by i̸̒n̴͛e̵̎l̴͝u̷̾c̴̉t̵́å̵b̷͋l̷͐e̴̋m̸̆o̷̚d̴̐ä̸́l̶͝i̷̋t̷͗ẏ̷ȏ̵f̸̃t̶͘h̷͗e̴̿v̶͘i̷̛s̸̈́ì̵b̷̃l̶̎e̷͊. > (5) > Is it right to say "the user name in /etc/passwd is UTF-8 encoded" or > should I better say "the user name in /etc/passwd can be UTF-8 encoded"? "It is UTF-8 encoded." > (6) > Does it still make sense to give non-UTF-8-locales special handling > (which one?), or can adduser safely assume that any non-ascii locale is > UTF-8? Or must I check for locale and reject UTF-8 user names on > non-UTF-8 locales? (I hope that we can safely assume UTF-8) It cannot. "C" is not UTF-8. Assumption of UTF-8 requires a properly set LANG and programs calling setlocale(). This, as alluded to above, has the potential for a big mess. -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: getting ziggy with it
nick black left as an exercise for the reader: > > The bootstrap is circular and has to be kicked off with a binary blob that > > can't be recreated until one has finished the bootstrap, which is > > certainly not ideal, but is also not that atypical for compiler > > bootstrapping problems. I don't see how this is a violation of the DFSG or > > of the requirement that main be self-contained. It's obnoxious from a > > process standpoint (like a lot of compiler bootstrapping), and we may not > > want things to work this way, but I don't think that makes it non-free? > > what you say here makes perfect sense; i'll look at what gcc and > friends are doing, thanks! i had thought that there was a Policy directive prohibiting generated files in source packages, but rereading 4.7.0.2, i don't see such a thing. we do see in debmake-doc [0]: "Extraneous auto-generated contents in the upstream source. Debian package should rebuild them under the latest system." so yeah, this seems pretty reasonable, and i'm surprised i didn't think of it. i do think that it would be best to rebuild the binary wasm file after having bootstrapped up zig, though that wouldn't be strictly necessary to bootstrap. that way we're shipping something we built, and verify the toolchain can build it. thanks as always, russ! [0] https://www.debian.org/doc/manuals/debmake-doc/ch07.en.html -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: getting ziggy with it
Russ Allbery left as an exercise for the reader: > I think I'm missing something. Why does the use of this file knock the > package out of main? We are distributing the source code for this file, > and it is presumably under a free software license. but we are not distributing it in a way such that it can be built, as the compiler is available. > The bootstrap is circular and has to be kicked off with a binary blob that > can't be recreated until one has finished the bootstrap, which is > certainly not ideal, but is also not that atypical for compiler > bootstrapping problems. I don't see how this is a violation of the DFSG or > of the requirement that main be self-contained. It's obnoxious from a > process standpoint (like a lot of compiler bootstrapping), and we may not > want things to work this way, but I don't think that makes it non-free? what you say here makes perfect sense; i'll look at what gcc and friends are doing, thanks! -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe.
minisign support in uscan
i'm beginning to see use of minisign[0] as an alternative to GPG for signing releases[2]. i'm completely ambivalent with regards to the merits of minisign, but would like to be able to verify them with uscan. looking at the uscan man page and code[1], i don't see any way to specify an alternative to gpg, though uscan apparently looks for gpgv, sopv, rsop and friends, and there's already a tool-specific case in verify() (sopv and gpgv appear to be cli-incompatible). so adding code to invoke minisign looks pretty trivial. the problem would be: how do i tell uscan to use minisign, in the likely presence of gpgv? minisign probably cannot verify everything gpg can, so we want to continue using gpg by default. i could probably convert the minisig signature to a gpg one (not certain of that), but we'd need some way to tell uscan to do that, at which point we probably ought just use minisig. selecting a different verification backend seems orthogonal to the pgpmode= options of uscan, so it doesn't belong in that set. adding support would likely mean adding minisign as at least a Recommends for devscripts, and possibly a Depends. minisign is pretty small at 16.7 kB downloaded and 49.2 kB installed, but it does depend on libsodium23, which is depended on by a fair number of things (including vim for some reason). libsodium23 adds 165/438 kB for a total of 181.7 kB down and 487.2 installed. it is furthermore crypto-related and thus sensitive; i thought it prudent to ask the list. so, unless i'm missing something (totally possible), i'd like to: 1) add a `sigtype` option to uscan, defaulting to 'pgp', with alternative 'minisign'. other values are errors with exit. 2) explicit provision of `sigtype` in conjunction with either explicit or implicit `pgpmode=none` (i.e. due to mode=svn) will be considered an error and result in exit. change `pgpsigurimangle` to work this way as well (it is currently allowed in conjunction with pgpmode=none, which i dislike). 3) augment the binary-finding code in uscan to look exclusively for `minisign` when `sigtype=minisign` (and not look for it otherwise). failure to find it is error + exit. 4) augment the verification code in uscan to use `minisign` iff `pgpmode=minisign` and it was discovered in step 3. 5) add `minisign` as a Depends for `devscripts`. i don't think this justifies any kind of generalized verification system in uscan (and am not particularly interested in writing one), nor do i think it's worthwhile to alias or rename e.g. `pgpsigurlmangle` or `pgpmode`. i've checked, and a properly ASCII-armored minisign public key will satisfy uscan up through the verification attempt. are there objections? am i missing something? thanks! i think i could have this done todayish. --rigorously, nick [0] https://jedisct1.github.io/minisign/ [1] lib/Devscripts/Uscan/Keyring.pm (devscripts-2.24.10) [2] https://ziglang.org/download/ -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: minisign support in uscan
nick black left as an exercise for the reader: > i'm beginning to see use of minisign[0] as an alternative to GPG > for signing releases[2]. i'm completely ambivalent with regards to > the merits of minisign, but would like to be able to verify them > with uscan. so this is how watch might look for minisign packages[0]: version=4 # example URIs: # https://ziglang.org/download/0.13.0/zig-0.13.0.tar.xz # https://ziglang.org/download/0.13.0/zig-0.13.0.tar.xz.minisig opts="sigtype=minisign, \ pgpsigurlmangle=s/$/.minisig/, \ dversionmangle=s/\+dfsg(\.?\d+)?$//, \ repacksuffix=+dfsg" \ https://ziglang.org/download/ .*/zig-([0-9\.]*)\.tar\.xz \ debian uupdate no one needs change their packages except people who have pgpmode=none despite the presence of pgpsigurlmangle (which will become an error if i execute my plan as proposed). [0] https://salsa.debian.org/nickblack/zig/-/blob/main/debian/watch -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: minisign support in uscan
Simon Josefsson left as an exercise for the reader: > Sorry I confused it with signify: minisign is derived from (openbsd's) signify, so easily done! > See https://lists.debian.org/debian-devel/2024/10/msg00031.html thanks! -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: wiki.d.o on a git-backed engine
Ahmad Khalifa left as an exercise for the reader: > Wikis have their own version control and they're meant for a much wider > audience. I think general documentation definitely belongs on a wiki, not > git. Edit, fix typo, done in 30 seconds :) there are of course wiki-git bridges, at least for MediaWiki: https://www.mediawiki.org/wiki/Git-remote-mediawiki https://github.com/Eccenux/wiki-to-git https://github.com/Git-Mediawiki/Git-Mediawiki there's also the (unmaintained) FUSE implementation (not particularly relevant here, but illustrative of the ecosystem's breadth): https://wikipediafs.sourceforge.net/ fwiw, i've maintained several public-facing MediaWiki installations, my largest (dankwiki[0]) having run on the same install base since 2008. it's been largely a pleasure; i doubt i spend more than five hours annually on its administration, almost entirely for updates or adding new plugins. upstream has been friendly and helpful the two times i've engaged with them on IRC. there's a plugin for just about anything one might want to do, from transcluding Bugzilla queries to inline Youtube video to integrating with donation services. in addition, anyone with Wikipedia editing experience can immediately apply it to a MediaWiki. the only unpleasant aspects have been PHP (very rare, but sometimes i need go change properties of my PHP installation) and esoteric plugins falling out of sync with the main distribution. it also requires a mysql backend, and default search capabilities are of the garbage variety (though this has improved in recent years, to the point where i no longer consider SphinxSearch a mandatory coinstall, and indeed no longer use it myself). development is healthy and ongoing, and comfortably backed by the Wikimedia Foundation. but i have no familiarity with Debian requirements, especially surrounding authentication. --nick [0] https://nick-black.com -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: minisign support in uscan
Simon Josefsson left as an exercise for the reader: > nick black writes: > That would be great -- upstreams are using other mechanisms to sign > their releases today, like Sigsum, Sigstore, gitsign S/MIME etc, and I > don't think there is any reason why 'uscan' shouldn't support all of > them. i've created #1092818 for this, and am working on it in https://salsa.debian.org/nickblack/devscripts/-/tree/nickblack/uscan-minisign > This reminds me about the 'apt-get install minisign' package naming > concern that we tried to flesh out a migration policy for earlier. I > think I ultimately got lost trying to work out the migration flow for > how to achieve that... i'm not familiar with this. do you have a reference? -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Bug#973916: ITP: rust-libc-print -- Support for println and eprintln in a no_std context
Package: wnpp Severity: wishlist Owner: "Nick Black" X-Debbugs-Cc: debian-devel@lists.debian.org, dankamong...@gmail.com * Package name: rust-libc-print Version : 0.1.14 Upstream Author : Matt Mastracci * URL : https://github.com/mmastrac/rust-libc-print * License : Apache-2.0 or MIT Programming Lang: Rust Description : Support for println and eprintln in a no_std context An implementation of println! and eprintln! on the libc crate without requiring the use of an allocator, and thus suitable for a no_std context. This small package is a dependency for rust-notcurses (see #972542). This will be maintained by myself under the auspices of the Rust Packaging Team.
Bug#1002724: ITP: openfec -- Forward Error Correction codes
Package: wnpp Severity: wishlist Owner: "Nick Black (Public gmail account)" X-Debbugs-Cc: debian-devel@lists.debian.org, dankamong...@gmail.com Package name: openfec Version : 1.4.2.4 Upstream Author : Victor Gaydov et al URL : http://www.example.org/ License : CeCILL-C Programming Lang: C Description : Forward Error Correction codes Application-Level Forward Error Correction codes add redundancy in order to be able to recover from erasures. this library is required by the Roc Project, whose PipeWire modules are currently disabled. With the addition of this dependency, we will be able to build roc-toolkit, and thus enable the PipeWire Roc sink and source. indeed, this active fork of the original OpenFEC is maintained by Roc. It uses a CeCILL-C license; see [0] for discussion on debian-legal. In addition, small parts come under Radford Neal's LDPC simulator license and Luigi Rizzo's Reed-Solomon license ([1]); I have reviewed both, and they seem trivially compatible with the DFSG. As a lowly DM, I'll be uploading this through a Sponsor, Dylan Aïssi from the Utopia team. [0] https://lists.debian.org/debian-legal/2017/03/msg00019.html [1] http://openfec.org/patents.html
Bug#1027976: ITP: libcpucycles -- Microlibrary for counting CPU cycles
Package: wnpp Severity: wishlist Owner: nick black X-Debbugs-Cc: debian-devel@lists.debian.org, dankamong...@gmail.com * Package name: libcpucycles Version : 20230105 Upstream Contact: Daniel J. Bernstein * URL : https://cpucycles.cr.yp.to/download.html * License : Public domain Programming Lang: C Description : Microlibrary for counting CPU cycles libcpucycles understands machine-level cycle counters for amd64 (both PMC and TSC), arm32, arm64 (both PMC and VCT), mips64, ppc32, ppc64, riscv32, riscv64, sparc64, and x86. libcpucycles also understands four OS-level mechanisms, which give varying levels of accuracy: mach_absolute_time, perf_event, CLOCK_MONOTONIC, and, as a fallback, microsecond-resolution gettimeofday. When the program first calls cpucycles(), libcpucycles automatically benchmarks the available mechanisms and selects the mechanism that does the best job. Subsequent cpucycles() calls are thread-safe and very fast. An accompanying cpucycles-info program prints a summary of cycle-counter accuracy.
Bug#1092895: ITP: zig -- Imperative programming language easily mixed with C
Package: wnpp Severity: wishlist Owner: nick black X-Debbugs-Cc: debian-devel@lists.debian.org, dankamong...@gmail.com * Package name: zig Version : 0.13.0 Upstream Contact: Andrew Kelley * URL : https://ziglang.org/ * License : MIT Programming Lang: C++ Description : Imperative programming language easily mixed with C Zig is a general-purpose programming language and toolchain for maintaining robust, optimal and reusable software. It aims to be a better C, and interoperates very fluidly with C code. Zig is a language rapidly growing in popularity, battling it out with Rust (in a sense) for developer mindshare. It can easily subsume C repositories and supports incremental conversion. I'm using ghostty, written in Zig, and would like to package that for Debian as well. I would think a team the way to go. zigteam. Previous work attempted to package zig (#1012286, archived), but died out in the 0.10.x era. I'll be starting with 0.13.0.
Bug#1099105: ITP: icann-rdap -- ICANN terminal RDAP client and server
Package: wnpp Severity: wishlist Owner: Nick Black X-Debbugs-Cc: debian-devel@lists.debian.org, dankamong...@gmail.com * Package name: icann-rdap Version : 0.0.21 Upstream Contact: Andrew Newton * URL : https://github.com/icann/icann-rdap/wiki * License : MIT Programming Lang: Rust Description : ICANN RDAP server and terminal client ICANN's implementation of the Registry Data Access Protocol (RDAP). Provides a minimal server and a command line client capable of generating fullscreen or JSON output, or emulating WHOIS style.
