Re: Limited security support for Go/Rust? Re ssh3
On Mon, Jan 15, 2024 at 10:17:17AM +0100, Bastian Blank wrote: > On Sun, Jan 14, 2024 at 04:24:57PM +0100, Simon Josefsson wrote: > > Isn't that what the text refers to? Vendoring and static linking are > > two examples of the same problem that the security team may encounter. > > We accept vendoring of autoconf/automake/gnulib distro wide. We _did_ accept that in the past, but these days you get smacked with a RC bug for not building from source. > Please show practical problems with it? * not working on new archs (most of the work of making sure autoconfage gets rebuilt was done by arm64 porters when it was a new thing) * not being able to fix bugs in autoconfage * failing to adapt to changes in the toolchain > The vendoring of gnulib, well, is old and maybe you could > show that it is a problem in the sources that have it, aka they don't > handle security fixes and at the same time don't change the library. Gnulib has not been useful for ages, thus packages still shipping vendored copies are harmless -- functions that gnulib was meant to provide implementation for were missing on ancient unices like HP-UX or SCO that are long dead by now. A glance at recent commits in gnulib shows a lot of retrocomputing names: Windows, OS/2, MacOS 10.5, AIX, on hardware of that level of recency. It's not used for new ports: the most recent reference to riscv in commit messages is from _2018_. Thus, I say the problem with vendored libraries is mostly unrelated to that of static linking, and thus they don't need to share a solution. > Here the problem is embedded into the language oekosystem itself. It is > not a choice of the software author to do static linking. It's mostly an issue with the deployment scheme at Google: I heard they recompile all their software and reinstall it on their fleet EVERY WEEK. This is about the only case where non-special-case (/sbin/ldconfig etc) static linking works. Then they shared their internal project with the world (good) without caring how it affects others (bad). Unlike them, we can't rebuild the world every time a bug is fixed (security or not). Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁'Russkiy voyennyi korabl, idi nakhuy' ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Re: Bug#1053165: ITS: nunit
On Thu, Sep 28, 2023 at 03:45:14PM +, Scott Kitterman wrote: > On September 28, 2023 3:22:20 PM UTC, Bastian Germann wrote: > >Okay. What do you suggest for "team maintained" packages where there is > >no active team member? File MIA processes for each of the uploaders? > >And then? The MIA team's bugs are not RC bugs, so you cannot even NMU > >them based on the MIA bug. > > > >I think, just letting such packages rot for one or two decades does not > > help anybody, certainly not our users. > Any team member can orphan the package. A team with 99 MIA members one active is not the problem here. But we have oh so many packages where the whole team is gone. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ ⠈⠳⣄
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
On Tue, Sep 19, 2023 at 11:39:49AM +0200, Johannes Schauer Marin Rodrigues wrote: > I was about to say that zdebootstrap by Adam Borowski used to be a thing four > years ago but now I see another commit from two days ago so maybe it's still > alive and usable? > > https://git.sr.ht/~kilobyte/zdebootstrap At the moment, all it can do is unpack packages, but a blocker for even continuing with dpkg would be registering triggers. Other problems: * the base set includes diverts now; I would need to know them _beforehand_. This means available from the control tarball, or preferably even Packages. Shipping a list would notoriously get out of sync, thus is only an option for past packages. * parallel debootstrapping is for obvious reasons utterly incompatible with usrmerge or any other kind of random package sabotaging the layout behind dpkg's back. When/if DEP17 gets implemented, such alias mangling would be doable but symlinks would still be a nasty thing. I'd also need to see what Pre-Depends can't be cheated away; as far as I've found so far, all are needed for upgrades or preinst, otherwise degrading them to Depends is workable -- but potential for breakage is huge. Likewise cheating on preinst. Also I'd really need to mark zdebootstrapped systems as tainted somehow, as they wouldn't be trustworthy until a lot of polishing and testing is done. > There is also my package mmdebstrap which gives you a Debian chroot a few > times > faster than debootstrap does. Here are some benchmarks from my laptop: > > | variant | mmdebstrap | debootstrap | > | - | -- | | > | essential | 9.52 s | n.a | > | apt | 10.98 s| n.a | > | minbase | 13.54 s| 26.37 s | > | buildd| 21.31 s| 34.85 s | > | standard | 23.01 s| 48.83 s | That's so insanely bad... if we only could put dpkg developers' time to some productive task instead of you-know-what. Even without breaking any of current guarantees, you can easily: * parallelize unpack stages * replace the status database with something not terrible WRT the second point: the only benefit of the current scheme is that, on a filesystem that corrupts the data on crash even if you do everything right, the user can do hail-mary manual recovery. If you stop caring about ext2 and vfat, we can do much better. And even dropping the flat text file format wouldn't be required if we 1. extended the "updates" log, 2. didn't rewrite the status file so often. Of course, this would require all readers to understand "updates" at which point we can just as well go with a binary database, but it's not like good key-value stores are far between, nor hard to devise from scratch. It's depressing how lesser distributions can be so much faster, despite us being supposed to be the bestest, prettiest, and so on :p (I'd continue this discussion, but ATM stuck in Abu Dhabi for 14 hours with no power source, then needing a week of sleep...) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Packager's rule #1: upstream _always_ screws something up. This ⢿⡄⠘⠷⠚⠋⠀ is true especially if you're packaging your own project. ⠈⠳⣄
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
On Sat, Sep 16, 2023 at 10:31:20AM +0530, Hideki Yamane wrote:
> Today I want to propose you to change default compression format in .deb,
> {data,control}.tar."xz" to ."zst".
> According to https://www.speedtest.net/global-index, broadband bandwidth
> in Nicaragua becomes almost 10x
>
> - 2012: 1.7Mbps
> - 2023: 17.4Mbps
>
> 10x faster than past: it means that file size is not so much problem for us
That's broadband, a lot of folks have nothing but crappy 5G.
I just happen to have a package converted to multiple formats on the disk
because I tested/benchmarked format 0.939 vs 2.0[1]. And:
-h bytes
tar 5.5G5839735844
gz 897M 939926960
xz 375M 392874208
zst 774M 811105258
For this particular package zst gives over twice as big file. You can pick
a stronger compression level but at that point we're just going up the
tradeoff curve.
> ## More CPUs
>
> 2012: ThinkPad L530 has Core i5-3320M (2 cores, 4 threads)
> 2023: ThinkPad L15 has Core i5-1335U (10 cores, 12 threads)
>
>
> https://www.cpubenchmark.net/compare/817vs5294/Intel-i5-3320M-vs-Intel-i5-1335U
> - i5-3320M: single 1614, multicore 2654
> - i5-1335U: single 3650, multicore 18076 points.
>
> And, xz cannot use multi core CPUs for decompression but zstd can.
> It means that if we use xz, we just get 2x CPU power, but change to zst,
> we can get more than 10x CPU power than 2012.
As someone with a 64-way amd64 desktop, and a purchased-but-not-delivered
64-core riscv64 box on the way, I understand the sentiment -- but, what
about parallelizing by unpacking multiple packages at the same time instead?
That's safer and doesn't cost compressing ratio[2]. I've prototyped this,
and even with current dpkg internals it shouldn't be hard to do (even if
dpkg runs keep switching between unpacking and configuring too often).
> It reduces a lot of time for package installation.
There's a lot lot lot of other places in dpkg that could use a speedup, and
they don't come with such a tradeoff. Especially fsync abuse: dpkg writes
all of its status every. single. step., fully. flushing. it. to. persistent.
storage. even. if. it's. a. dingy. SD. card. So it does for every file it
unpacks; to a semi-ignorant onlooker it seems as if it uses some sort of
range coder just so it can fsync between fractional bits.
Even though there's no good generic way to ensure consistency of extracted
payload (POSIX lacks such API, you can use btrfs snapshots), at least the
dpkg state could win a lot by stopping assuming the limitations of ext2
apply to other filesystems. On ext2 a crash may do unbounded damage to
the filesystem, using flat text files and fsyncs between every operation
improves recoverability, but any filesystem newer than that adds better
guarantees. There are so many techniques that would avoid full state
rewrites...
> ## More storage bandwidth
>
> SSD + PCIe 3/4/5 is enough, not be a blocker for decompression, now.
So wishing Optane NVDIMMs didn't get cancelled... :/
On the other hand, we could switch the compression for _some_ packages.
There's stuff that gets unpacked by buildds over and over. Compilers and
library headers are not used much by end-users on dingy connections (and
us hackers tend to prioritize computing device spending compared to regular
people), thus what about switching stuff that's 1. not in build-essential
but 2. in a set shared by many Build-Deps?
Meow!
[1]. https://lists.debian.org/debian-dpkg/2023/09/msg00014.html
[2]. Parallel compression, and especially decompression, is done by
flushing and dropping old state every block.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Bestest pickup line:
⢿⡄⠘⠷⠚⠋⠀ "Cutie, your name must be Suicide, cuz I think of you every day."
⠈⠳⣄
Re: Default font: Transition from DejaVu to Noto
On Wed, Sep 13, 2023 at 09:09:00PM +0200, Gunnar Hjalmarsson wrote: > There is a problem with fonts-noto-core, though, as several people have > mentioned already: For non-LCG scripts it provides one font per script. And > there are quite a few of those. So for a user, who wants to actively and > often select font in a font picker, the list of font options gets horribly > long. > > Personally I see that as a shortcoming in the font pickers. They ought to > offer some "favorites" functionality, in the same manner as it works with > keyboard layouts. Unfortunately they don't, at least as far as I know. Why "favorities"? No other font assumes itself to be special enough to require such an extra functionality. And in good font pickers (eg. GTK2 but spefically _not_ GTK3), each font family gives a single entry, with styles being a secondary choice. Also, for pickers that are helpful enough to provide a sample outright, being told that a family is family means they need to load and render the sample from only one font file. I don't see a real way to speed that up (can parallelize, but that's about it). Fontconfig's caches let you avoid having to open the font files to fetch metadata, but there's too many details that can alter rendering samples (connected monitors, font size, etc) to cache the images reasonably. > So we have a conflict of goals here. The good news is that a user who speaks > some latin language, and who thinks it's important to be able to easily > select font directly in various applications, can do: I wouldn't care about Latin languages at all here. About any font can do this well, and there are thousands of fonts that do it better than Noto (plus hundreds of thousands that do it worse). Heck, my favourite font I use for non-monospace browser setting is Aroania (bin:fonts-ancient-scripts) -- a byproduct of a random script I can't even read nor I care about. > But the many fonts is not only a disadvantage. It allows you to prefer Noto > fonts for some non-latin scripts, and other fonts for other ditto. This > flexibility is effectively blocked if DejaVu Sans, where everything is > bundled into the same font, is installed and default. This can be done by giving high-quality optional packages a higher score than the fallback default. > Since it already has been changed back to DejaVu Sans Mono for monospace, > let's talk about sans-serif/serif here. I wouldn't call either Dejavu Sans Mono nor Noto Mono contenders for a good Latin monospace font, it's a pretty crowded competition. Things were different the previous millenium when Dejavu was made, but we can do better. > you need to be attentive to the font rendering settings. As an example I > think that enabling 10-sub-pixel-rgb.conf is a good idea for many screens > when using Noto fonts. That's a bad default as it produces a distinctly bad result on any non-RGB (usually rotated) screen. Monochrome AA is safe, and while it might be even good to enable sub-pixel RGB _dynamically_, changing sub-pixel dynamically is not a thing yet as far as I'm aware. Thus, let's pick an AA default that's good enough but works for everyone. Requiring RGB to look good is another strike against Noto. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ I was born a dumb, ugly and work-loving kid, then I got swapped on ⢿⡄⠘⠷⠚⠋⠀ the maternity ward. ⠈⠳⣄
Re: bookworm+½ needed (Arc GPUs, ...)
On Tue, Sep 12, 2023 at 10:31:17AM -0400, M. Zhou wrote: > Intel is also slow in upstreaming their SYCL implementation to LLVM > upstream. So that there is still a very far way to go towards > the pytorch variant that can use intel ARC GPU. Yeah, but that's not a problem for the installer. Nor for a random user who wants to do some coding, browsing, and maybe play a game sometimes. I know that it's frustrating for you, but for now I'd care about more basic uses. As far as I know, Intel cares about SYCL mostly for server GPUs like Ponte Vecchio with ARC being only an afterthought. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Elemental clouds: ⣾⠁⢠⠒⠀⣿⡁ • earth: cumulogranite (aviation) ⢿⡄⠘⠷⠚⠋⠀ • fire: pyrocumulus (forestry, volcanism) ⠈⠳⣄ No known relations of clouds to air or water.
Re: Default font: Transition from DejaVu to Noto
On Tue, Sep 12, 2023 at 09:19:26AM +0200, Gioele Barabucci wrote: > On 12/09/23 08:24, Fabian Greffrath wrote: > > the fonts-noto-core package installs a full pack of 268 (!) font files. > > This is discussed in detail in #983291 [1]. > > The issues is not that there are too many files, but that these files become > extra entries in font pickers (1 entry for every ~3 files). > > Why not collapse all these font files into a few new font files using > fontforge or a variant of nototools's merge_fonts.py? You don't need to physically merge font files, fontconfig is fine with many fonts sharing the same name. You can't then request a specific font, but taking missing glyphs from others still works. (Haven't looked at this in a while, would need to test.) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Latin: meow 4 characters, 4 columns, 4 bytes ⣾⠁⢠⠒⠀⣿⡁ Greek: μεου 4 characters, 4 columns, 8 bytes ⢿⡄⠘⠷⠚⠋⠀ Runes: ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes ⠈⠳⣄ Chinese: 喵 1 character, 2 columns, 3 bytes <-- best!
Re: bookworm+½ needed (Arc GPUs, ...)
On Tue, Sep 12, 2023 at 08:32:17AM +0200, Fabian Greffrath wrote: > > Before we go and bother the relevant folks (or maybe even do part of the > > work ourselves...), could someone name other pieces of hardware that > > would be wanted for Bookworm+½? > > not sure of that's what you mean, but the Realtek RTL8852BE Wi-Fi > adapter is only properly supported by Linux 6.2. Then it would require no other action but grabbing a backported kernel, thus is already included in any reasonable Bookworm+½ plan (we don't do frankenkernels). But even in this case, it is still good to know that, to include such an adapter in documentation. Obviously there's no point in listing every newly supported piece of hardware as every kernel version adds hundreds of them, but some are more prominent than others. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁'Russkiy voyennyi korabl, idi nakhuy' ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
bookworm+½ needed (Arc GPUs, ...)
So... If you've watched our Dear Leader's talk, a prominent problem listed was problems with new graphics cards. While he didn't elaborate, I assume it was about Intel Arc -- ie, new DG2 discrete GPUs. And the problem is, proper support didn't hit the kernel until after 6.1. You can kinda-sorta run on 6.1 by whitelisting it by PCIe ID on the kernel cmdline, and it even works (6.0 couldn't cope with my setup, 6.1 was ok), but such an intentional block doesn't suggest it's something wise for a normal user to do. I'm not sure if firmware shipped with Bookworm is good enough, either (having grabbed a copy of the files much earlier, would need to test). Of course, this wasn't Debian's fault. The group at Intel responsible for upstreaming kernel/etc bits was too slow, not providing drivers until after the hardware has already been shipping to regular non-NDAed customers. But then, hardware makers do this all the time. Intel Arc just gives a more prominent reason to have an installer with backported kernel+stuff. Before we go and bother the relevant folks (or maybe even do part of the work ourselves...), could someone name other pieces of hardware that would be wanted for Bookworm+½? Meow? -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
On Wed, May 31, 2023 at 10:10:56PM +, Andrew M.A. Cater wrote: > As someone who owned and happily used an Asus eePC several years ago: very > nice, silent - it also had a flash disk from the earliest days of flash disks. Instead of RasPis as suggested by many in this thread, I'd instead suggest whatever is the current model of Odroid-H2+: * x86 * no moving parts * either my meter is broken or it's 4.6W under full load (specs say 14W?!?) * fat i/o * 2×2.5Gbe > The same arguments that I would now apply to the i386 port I'd also > apply to early AMD64 hardware - whoever had my first machine with it, > it should now be long gone as power inefficient beyond words and > 15 years old. At that time the concept of a daily driver capable machine taking low power was in its infancy, they just can't come close to newer designs. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ An imaginary friend squared is a real enemy. ⠈⠳⣄
Re: Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)]
On Sat, May 20, 2023 at 09:15:00AM +0200, Josh Triplett wrote: > How easily could we add 64-bit system detection to the i386 installer, > and a message saying something like: > > "You're installing the i386 architecture on a 64-bit system. While this > will work, this is the last release it'll be supported. We recommend > installing the 64-bit amd64 architecture instead. This is not a valid use for i386. Running the i386 kernel on _modern_ hardware is insecure, slower (esp. if you have a non-tiny amount of memory), etc. We should put a big fat warnings for _that_. On the other hand, it's okayish to run 32-bit userland -- in fact, in some cases it might be quite a bit faster¹, as long as you use the appropriate kernel. Which is 32-bit for ancient hardware (including some first 64-bit-capable models), and 64-bit today. Meow! [¹]. Sometimes amd64 wins by a lot due to more wider registers and SSE, sometimes i386 win hugely due to halved pointers and better code density, which allows using a higher-tier cache. We could have been using x32 to get both, but oh well... -- ⢀⣴⠾⠻⢶⣦⠀ The ill-thought conversion to time64_t will make us suffer from ⣾⠁⢠⠒⠀⣿⡁ the Y292B problem. So let's move the Epoch by 43545140006400 ⢿⡄⠘⠷⠚⠋⠀ (plus a safety margin in case of bad physicists) and make it ⠈⠳⣄ unsigned -- that'll almost double the range.
Re: Re-enabling os-prober for live images?
On Mon, Mar 06, 2023 at 02:38:53PM +, Steve McIntyre wrote: > j...@debian.org wrote: > >Since the grub 2.06 upload, os-prober is now disabled by default. This > >means that other operating systems are no longer detected and added to > >grub by default in Debian 12. > >I haven't followed further on to which solution they went with, but > >since it's so late in the development cycle, wouldn't it make sense to > I'm also pondering tweaking things in d-i to re-enable os-prober if > the system looks like it might have some other OS installed. Yes, I > realise that may sound odd(!), but I can see a number of users > complaining that their dual-boot system doesn't work any more... :-/ At this point, I'd just enable os-prober unconditionally, and think of a wrapped solution for the future. The "disable os-prober" change trades a major usage regression for hardening an issue that can be trivially exploited in a number of other ways anyway. Our current current state of resistance against physical access is bad enough that _today_ I'd say this sacrifice is not worth it. I don't quite see any short-term developments that would improve it (there's plenty of snakeoil, disturbing DRM schemes, while no one bothers to deploy projects that'd make physical security friendly to the user. But /rant.). Thus my suggestions would be either: * just re-enabling os-prober, or * checking if we're on an encrypted filesystem. Your idea of checking whether there's a second OS installed has its merit, but would mysteriously fail to offer boot choice if we're the old OS (ie, possibly the one being replaced and kept just in case). Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Q: Is it ok to combine wired, wifi, and/or bluetooth connections ⢿⡄⠘⠷⠚⠋⠀in wearable computing? ⠈⠳⣄ A: No, that would be mixed fabric, which Lev19:19 forbids.
Re: Please, minimize your build chroots
On Sat, Jan 28, 2023 at 01:59:40PM +0100, Santiago Vila wrote: > El 28/1/23 a las 12:50, Andreas Henriksson escribió: > > > Claiming there's no point to free software when the problem is simply > > that you are using an *unsupported* setup?!?! > > Unsupported by whom? What is supported or unsupported is explained in policy. > Policy says it must work. Therefore it should be supported (by fixing the > bugs). Policy §2.5: # "required" #Packages which are necessary for the proper functioning of the #system (usually, this means that dpkg functionality depends on #these packages). Removing a "required" package may cause your #system to become totally broken and you may not even be able to use #"dpkg" to put things back, so only do so if you know what you are #doing. > That's a straw man. I'm not proposing anything of the sort. Policy says > packages must build when essential and build-essential packages > are installed (plus build-dependencies). Build-essential _packages_. Not the "build-essential" package which very clearly says its dependencies are purely informational. > You and others are essentially saying I should not follow policy No, we are saying that we believe your understanding of the policy is flawed. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Re: depends-on-obsolete-package lsb-base
On Wed, Jan 18, 2023 at 08:19:15AM -0800, Otto Kekäläinen wrote: > Lintian just started erroring on 'depends-on-obsolete-package > lsb-base' on many of my packages yesterday. It's a very low priority cleanup; the Depends is redundant but harmless. > There are no new uploads of lsb-base recently Relevant changes are from September. The lsb-base package is empty, and would have been gone completely if debootstrap understood Provides. > and I did not find any news about this topic. The > Lintian page https://lintian.debian.org/tags/depends-on-obsolete-package > is only about the error in general, not any mention of lsb-base > specific changes. The description of "$PACKAGE1 => $PACKAGE2" are clear enough, of "$PACKAGE => nothing" a bit less, indeed. You can just drop the dependency. > Does somebody know what is going on? > > Example: > E: mariadb-server: depends-on-obsolete-package Depends: lsb-base (>= 3.0-10) The severity of this warning is grossly overstated. It shouldn't be an "error" but a "mild warning to fix if you're bored". Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Re: setting sysctl net.ipv4.ping_group_range
On Tue, Jan 03, 2023 at 12:43:31AM +0100, Marco d'Itri wrote: > On Jan 02, Noah Meyerhans wrote: > > I'm entirely happy to reassign this request to systemd and have the > > setting applied more broadly. > Some options: > - conflict with systemd < version_with_the_new_default > - wait for a full release and then just drop it > - when sysctl in postinst reports the new default > - a mix of the last two options Debian's default sysctl settings should reside in procps (as it owns /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated package. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos? ⠈⠳⣄
Re: Bug#1026087: ITP: distribution-gpg-keys -- GPG keys by various Linux distributions
On Thu, Dec 15, 2022 at 03:12:21PM +0100, Guillem Jover wrote: > On Wed, 2022-12-14 at 15:27:18 +0100, Juri Grabowski wrote: > > * Package name: distribution-gpg-keys > > Upstream Author : Miroslav Suchý > > * URL : https://github.com/xsuchy/distribution-gpg-keys/ > > Description : GPG keys by various Linux distributions > > > > used by various Linux distributions to sign packages. > > > > needed by mock/3.5 and I need a sponsor for this package. See current > > packaging in > > https://salsa.debian.org/pkg-rpm-team/distribution-gpg-keys > > After I know ITP bug number I upload this source package to > > https://mentors.debian.net/package/distribution-gpg-keys/ > (If this project is also intended to only cover RPM-based distributions, > as Adam brought up, you might want to further ask them to make that clear > from the project name, say rpm-distribution-openpgp-keys or similar. When in that project's native environment, ie a RPM distribution, the name _is_ adequate. It's only in Debian (/Alpine/Arch/Gentoo/...) where the name can be confusing. But then, there's no requirement for the package name to match upstream. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos? ⠈⠳⣄
Re: Bug#1026087: ITP: distribution-gpg-keys -- GPG keys by various Linux distributions
On Wed, Dec 14, 2022 at 03:27:18PM +0100, Juri Grabowski wrote: > * Package name: distribution-gpg-keys > Upstream Author : Miroslav Suchý > * URL : https://github.com/xsuchy/distribution-gpg-keys/ > Description : GPG keys by various Linux distributions > > used by various Linux distributions to sign packages. These are all RPM distributions, which is definitely not what one would expect in our context. At the very least the short desc would need to mention that, and I'd recommend having that in the name as well. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos? ⠈⠳⣄
Bug#1023305: ITP: zst -- CLI tool for zstd (and other) compression
Package: wnpp Severity: wishlist Owner: Adam Borowski X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: zst Version : not released yet Upstream Author : yours truly * URL : https://github.com/kilobyte/zst Programming Lang: C Description : CLI tool for zstd (and other) compression This is an alternate tool for zstd compression, one that takes a lot less space than the official one. It also behaves in a way consistent with other Unix compressors: the level goes only up to 9, the original copy of the file is not kept, etc. . The executable can also replace gzip xz bzip2. A bunch of features are not yet ready, but I'm filing this ITP now that the core functionality is already working but there's still time for design changes. Stuff that's aimed for important/Essential needs to be discussed well... Existing compressors: | tool | lib --+--+- gzip | Ess | Ess bzip2 | std | Ess (but it'd be nice to remove it) xz| std | Ess zstd | opt | Ess lz4 | opt | libsystemd0 but not libelogind0
Re: FTBS bugs -- MBF?
On Sun, Oct 02, 2022 at 01:06:31PM +0200, Mattia Rizzolo wrote: > On Sun, Oct 02, 2022 at 10:57:11AM +0100, Simon McVittie wrote: > > > Packages that only build Architecture: all binary packages tend to use > > > Build-Depends-Indep. > > > > Policy is quite clear about that being a bug. I think a better rule of > > thumb for maintainers in a hurry would be: if you don't have time to think > > about which dependency list is the right one, and preferably test the > > result (with a source-only build like Adam has been doing, a --build=all > > build, and a --build=any build), then the safe option is to put everything > > in B-D. > > I totally agree, and I consider that a RC bug in my mind. > > I would support filing all the bugs as sev:important, and bump them > right after the bookworm release (so we don't add all these RC bugs so > near the freeze, even if they are trivial to fix). I've filed a few of those, let's see if there's any pushback or comments. https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-qa%40lists.debian.org=ftbs Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Genetics say, virgin birth may not possibly produce male offspring. ⣾⠁⢠⠒⠀⣿⡁ Thus, either Jesus was fathered by (Abdes?) Pantera, or she was trans. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄ In neither case Joseph is involved, making Jesus a bastard.
Re: packages expected to fail on some archs
On Tue, Sep 27, 2022 at 12:23:57AM +0300, Adrian Bunk wrote: > If we limit the problem to avoiding build failures in cases that > upstream does not support, there would be the trivial solution of > having a package ship Provides like: > - architecture-is-64bit > - architecture-is-32bit > - architecture-is-little-endian > - architecture-is-big-endian > - architecture-has-64bit-timet > Build-Depends: architecture-is-64bit, architecture-is-little-endian,... > would be a package that only supports 64bit little endian architectures, > and that would never be attempted to build on 32bit or big endian > architectures. > > The buildd page would then show for i386: > mypackage build-depends on missing: > - architecture-is-64bit Alas, this scheme won't work for cross-building or multi-arch :( Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Genetics say, virgin birth may not possibly produce male offspring. ⣾⠁⢠⠒⠀⣿⡁ Thus, either Jesus was fathered by (Abdes?) Pantera, or she was trans. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄ In neither case Joseph is involved, making Jesus a bastard.
Re: FTBS bugs -- MBF?
On Sun, Oct 02, 2022 at 09:51:52PM +0200, Lucas Nussbaum wrote: > On 02/10/22 at 04:23 +0200, Adam Borowski wrote: > > I did another _source_ rebuild of the archive -- checking if every package > > is capable of repacking its source. Ie, if you can unpack it, (possibly > > modify), and pack again. > All those source packages are Architecture: all. > > To make this easier to detect (and avoid regressions in the long term), > I wonder if sbuild should have an option that would make it do, for a > source+all build: > - install B-D > - run clean > - install B-D-I > - build the binary packages There is nothing that stops B-D-A being necessary for clean for an arch:any package. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Genetics say, virgin birth may not possibly produce male offspring. ⣾⠁⢠⠒⠀⣿⡁ Thus, either Jesus was fathered by (Abdes?) Pantera, or she was trans. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄ In neither case Joseph is involved, making Jesus a bastard.
Re: FTBS bugs -- MBF?
On Sun, Oct 02, 2022 at 08:40:04AM +0200, Lucas Nussbaum wrote: > On 02/10/22 at 04:23 +0200, Adam Borowski wrote: > > I did another _source_ rebuild of the archive -- checking if every package > > is capable of repacking its source. Ie, if you can unpack it, (possibly > > modify), and pack again. [...] > > This leaves one big set: packages that fail the clean step due to > > undeclared B-Depends. [...] > > ... which makes sense as you might be interested in only an arch:all or > > arch:any build, and we have no clean-indep/clean-arch targets. [...] > > As 291 packages fail this requirement, I'm posting here before (instead?) > > filing bugs. There's also a question of severity. > Are you saying that those 291 packages fail when only > Build-Depends/Build-Conflicts are satisfied, but do not fail when > Build-Depends-Indep is also satisfied? Yes, exactly. > FWIW, when I do archive rebuilds, I rebuild the source, but that's with > Build-Depends-Indep installed. Apparently there's not a single package that needs B-D-Arch. I've just looked in case if sbuild installs those by default, but it's not the case. A sample package (acmetool) for example says: dh clean --buildsystem=golang --with=golang,apache2 dh_auto_clean -O--buildsystem=golang Can't exec "go": No such file or directory at /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443. Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443. Can't exec "go": No such file or directory at /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449. Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449. Use of uninitialized value $_gcc_major in multiplication (*) at /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 450. dh_autoreconf_clean -O--buildsystem=golang dh_clean -O--buildsystem=golang dpkg-source -b . but succeeds. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Genetics say, virgin birth may not possibly produce male offspring. ⣾⠁⢠⠒⠀⣿⡁ Thus, either Jesus was fathered by (Abdes?) Pantera, or she was trans. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄ In neither case Joseph is involved, making Jesus a bastard.
FTBS bugs -- MBF?
Nǐmen hǎo! I did another _source_ rebuild of the archive -- checking if every package is capable of repacking its source. Ie, if you can unpack it, (possibly modify), and pack again. Putting aside packages that are broken in other ways as well (B-Depends non-installable, FTBFS or a RC bug), there seems to be no new fancy types of breakage that haven't been fixed in 2020. This leaves one big set: packages that fail the clean step due to undeclared B-Depends. According to the Policy: # "clean" #Only the "Build-Depends" and "Build-Conflicts" fields must be #satisfied when this target is invoked. ... which makes sense as you might be interested in only an arch:all or arch:any build, and we have no clean-indep/clean-arch targets. For sbuild, the incantation is: alias sbuild-source='sbuild -s --source-only-changes --no-arch-all --no-arch-any --no-run-autopkgtest' As 291 packages fail this requirement, I'm posting here before (instead?) filing bugs. There's also a question of severity. Raw list and dd-list attached. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ A tit a day keeps the vet away. ⠈⠳⣄ adduser arandr aspell-bn aspell-gu aspell-hi aspell-it aspell-kn aspell-ml aspell-mr aspell-or aspell-pa aspell-pl aspell-sl aspell-ta aspell-te beaker biojava4-live bkchem bleachbit blends bless c++-annotations c3p0 caveconverter cecil cecil-flowanalysis cl-asdf-finalizers cl-asdf-system-connections cl-closure-common cl-command-line-arguments cl-containers cl-curry-compose-reader-macros cl-cxml cl-daemon cl-db3 cl-dynamic-classes cl-ftp cl-garbage-pools cl-github-v3 cl-graph cl-ieee-floats cl-ixf cl-local-time cl-log cl-lparallel cl-markdown cl-metatilities-base cl-mssql cl-parse-number cl-py-configparser cl-qmynd cl-quri cl-rfc2388 cl-salza2 cl-sqlite cl-trivial-utf-8 cl-utilities cl-uuid cl-who cl-yason cl-zip cl-zs3 classycle cmd2 colplot confy context-nonfree coq-doc darcula db4o dbus-sharp dbus-sharp-glib debian-astro debian-electronics debian-fbx debian-gis debian-hamradio debian-junior debian-med debian-multimedia debian-pan debian-science debichem developers-reference dhcpy6d django-axes django-cacheops django-filter django-graphene django-graphiql-debug-toolbar django-ipware django-pglocks django-rich django-rq django-simple-captcha django-tables django-taggit djvubind docbook-xml dput drf-yasg-nonfree dstat dtrx dynalang easygit editorconfig-core-py elasticsearch-curator fonts-arundina foolscap fop fortunes-debian-hints freeplane funnyboat ghp-import git-publish gramps graphql-core graphql-relay graxxia gvb hachoir howm hunchentoot imagej isenkram isorelax jaligner jclic jcommander jheatchart jlha-utils jline jruby-joni jsxgraph jtb jupyter-sphinx-theme jvyamlb jxplorer jython klaus kunststoff latex-make latex2html lazygal lfm libcobra-java libitext1-java libjlha-java libjspeex-java libjt400-java liblastfm-java libpal-java libpdfbox-java libpixie-java libproxool-java libsoftware-copyright-perl libswarmcache-java libvorbisspi-java libyanfs-java logging-tree logilab-constraint mcomix mergedeep messagingmenu-sharp metastudent mkdocs-autorefs mkdocs-material-extensions mkdocs-redirects mkdocstrings mkdocstrings-python-handlers mkdocstrings-python-legacy mobile-atlas-creator monajat mono-addins mono-tools mpd-sima nagstamon nant nekohtml net-luminis-build-plugin nini notify-sharp-3.0 ognl onionbalance osmnx othman pagekite paste pastescript pdfposter piccolo pixelmed pixelmed-codec plm png-sixlegs postgis-java psycopg3 puddletag pygments pyracerz pyro4 pyroma pyroute2 python-amqp python-arrow python-bleach python-bottle python-box python-cookies python-daemon python-django-braces python-django-crispy-forms python-django-crispy-forms-foundation python-django-debug-toolbar python-django-tagging python-docutils python-dotenv python-elasticsearch python-flickrapi python-funcy python-gitlab python-graphene python-griffe python-irc python-k8sclient python-l20n python-ldappool python-libusb1 python-lunr python-markdown-include python-markuppy python-marshmallow python-network python-nmap python-opcodes python-prometheus-client python-promise python-pydub python-q python-readme-renderer python-repoze.tm2 python-requests-toolbelt python-roman python-smstrade python-socksipychain python-stem python-tablib python-tempita python-text-unidecode python-u2flib-server pytkdocs pyvo pyyaml-env-tag recommonmark resteasy3.0 rst2pdf runsnakerun safeeyes sat4j seahorse-adventures sentry-python serpent simplyhtml smuxi solaar sphinx squaremap svgsalamander swagger-spec-validator swing-layout swtcalendar taoframework terraintool towncrier tp-smapi translate-toolkit tunnelx uncertainties unittest2 urlscan velocity-tools virtualenvwrapper w3c-linkchecker weather-util webtest xhtml2pdf xom yapps2 yapsy yaret yorick-cubeview Aggelos Avgerinos elasticsearch-curator (U) Agustin Henze yapsy Alexandre Rossi lazygal (U) Andrea Colangelo python-roman (U) Andreas Tille blends (U) debian-gis (U) debian-med
Re: R³ by default: not for bookworm
On Sun, Sep 18, 2022 at 03:58:57AM +0200, Guillem Jover wrote: > On Sun, 2022-09-18 at 03:39:43 +0200, Adam Borowski wrote: > > A few packages had a value of R³ other than "no" / "binary-targets", > > these are deprecated now; bugs filed. > > Deprecated by who or what? I had the impression https://bugs.debian.org/975637 has passed. > > The process of adding/changing a field in "control" differs between the > > three source formats we have. > > Hmm, I'm not sure I understand this statement. In 3.0 formats, you can unpack a tarball (whose name differs by format), update debian/control, repack -- no need to apply the quiltage or touch any other fragile bits. In 1.0 you need to go through all the motions -- I don't even see (in dpkg-source's man page) how to skip running "clean" which in turn requires B-Deps and can fail. > > Of these, the most involved format is 1.0 -- you need to repack the > > whole source. And quite a bunch of packages fail that step, not even > > letting me to modify anything. I guess FTBS bugs need to be enforced... > > Nor this one. Could you give more details? Fails To Build Source. Ie, ｢dpkg-source -x｣ then ｢dpkg-source -b｣ fails. I tend to use sbuild for repacking, the whole incantation is: alias sbuild-source='sbuild -s --source-only-changes --no-arch-all --no-arch-any --no-run-autopkgtest' > > Almost any format 1.0 package with R³ unset does so not because of an > > actual need for fakeroot, but because of an ancient build system and a > > decade or two of neglect. > > Lack of debhelper/dh usage certainly makes adding the field more > challenging, yes. Another common error are hardcoded whoami checks. > > Format "3.0 (native)": > > The complete list of packages that FTBFS if you set them to R³:no is: > > Format "3.0 (quilt)": > > In a pile of build logs that looks incomplete: > > 408 Status: attempted > > 12387 Status: successful > > Thanks for these checks! But in addition to checking whether these failed, > did you check that they ended up with the same user:group and perms (such > as SUID), as before setting the field? I only checked whether they build; that'd be the next step if the change to the default looked plausible. > > Thus: let's revisit R³ being required after Bookworm. > > My current thinking though, has been to change the default via something > like: > > <https://wiki.debian.org/Teams/Dpkg/Spec/DpkgDevCompatLevel> Adding a yet another field everyone has to bump would be costly in human time. I wonder, perhaps it'd be better to hijack dh compat -- at the cost of a bogus b-dependency for a small fraction of packages? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ * *** ⠈⠳⣄
Re: transition to usrmerge to start around 2022-09-15 (next Thursday)
On Sat, Sep 17, 2022 at 02:30:45AM +0100, Luca Boccassi wrote: > Unless any new issue pops up, I'll upload i-s-h to unstable to start > the transition tomorrow evening. ... and you ignored anything you don't like, and uploaded ANYWAY. Despite even the GR talk, which you folks _explicitely requested_. Not amussed. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
R³ by default: not for bookworm
Hi!
A few months ago I ran a test rebuild of packages that lack
Rules-Requires-Root settings. Alas, I've forgotten to post the
results, doing so now.
A few packages had a value of R³ other than "no" / "binary-targets",
these are deprecated now; bugs filed.
This leaves three states: "no", "binary-targets", unset.
The process of adding/changing a field in "control" differs between the
three source formats we have.
Of these, the most involved format is 1.0 -- you need to repack the
whole source. And quite a bunch of packages fail that step, not even
letting me to modify anything. I guess FTBS bugs need to be enforced...
Almost any format 1.0 package with R³ unset does so not because of an
actual need for fakeroot, but because of an ancient build system and a
decade or two of neglect.
Verdict: outside of the X Strike Force, these packages need their
debian/rules nuked from the orbit, and not for R³ reasons.
Format "3.0 (native)":
The complete list of packages that FTBFS if you set them to R³:no is:
apt-xapian-index
base-files
bombardier
bootcd
cvs-buildpackage
debdelta
debian-installer-netboot-images
debian-policy
dict-gcide
ethstatus
extrepo
gcc-10-cross-mipsen
gcc-10-cross
gcc-11-cross-mipsen
gcc-11-cross-ports
gcc-11-cross
gcc-12-cross-mipsen
gcc-12-cross
gopher
gup
hpsockd
latex-cjk-chinese-arphic
mailcap
menu
molly-guard
moonshot-trust-router
murrine-themes
nagios-plugins-contrib
palo
shellia
shim-helpers-amd64-signed
simplesnap
sleepd
statnews
synaptic
ucf
umegaya
witalian
wspanish
wzip
fwupd-{arm64,armhf,i386}-signed, partman-prep, pmon-update, s390-*,
shim-helpers-{arm64,i386}-signed, zipl-installer are !amd64 -- skipped.
Format "3.0 (quilt)":
In a pile of build logs that looks incomplete:
408 Status: attempted
6 Status: failed
32 Status: given-back
15 Status: skipped
12387 Status: successful
This doesn't look low enough to warrant a MBF.
Thus: let's revisit R³ being required after Bookworm.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Bestest pickup line:
⢿⡄⠘⠷⠚⠋⠀ "Cutie, your name must be Suicide, cuz I think of you every day."
⠈⠳⣄
Re: transition to usrmerge to start around 2022-09-15 (next Thursday)
On Thu, Sep 15, 2022 at 10:57:52PM +0100, Luca Boccassi wrote: > On Sat, 2022-09-10 at 15:37 +0200, Ansgar wrote: > > the transition to usrmerge as described in [1] is planned to start > > around 2022-09-15 (next Thursday). > I have just come back home from LPC so did not have much time > today, will have a look at the latter two tomorrow and then upload to > unstable once the situation is clearer. ... unstable of what distribution? I seriously hope you're not talking about Debian. Have you fixed the issues listed, as discussed on IRC? Implemented at least the configurable list of aliases compromise, as agreed? If not, the only transition that can work is one to a scheme supported by dpkg, which usrmerge is not. Meow. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out, ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the ⠈⠳⣄ sky. Your cat demands food. The priority should be obvious...
Bug#1019703: ITP: inkscape-silhouette -- inkscape extension to drive a Silhouette plotter
Package: wnpp Severity: wishlist Owner: Adam Borowski X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: inkscape-silhouette Version : 1.26+ Upstream Author : Juergen Weigert and contributors * URL : https://github.com/fablabnbg/inkscape-silhouette * License : GPL Programming Lang: Python Description : inkscape extension to drive a Silhouette plotter An extension to drive a Silhoutte Cameo and similar plotter devices from within inkscape. . You can access it via “Extensions -> Export -> Send to Silhouette” and “ ... -> Silhouette Multi Action”. . Supported devices: * Silhouette Portrait * Silhouette Portrait 2 * Silhouette Portrait 3 * Silhouette Cameo * Silhouette Cameo 2 * Silhouette Cameo 3 * Silhouette Cameo 4 * Silhouette Cameo 4 Pro * Silhouette Curio * Craft Robo CC200-20 * Craft Robo CC300-20 * Silhouette SD 1 * Silhouette SD 2
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Thu, Sep 08, 2022 at 05:58:25PM +0200, Dylan Aïssi wrote: > I have been asked several times regarding when Debian will switch its default > sound server from PulseAudio to PipeWire without having an official answer. > Thus, I suppose it's the right time to start a discussion about that. If we're going to default to PipeWire in Bookworm, please switch NOW. Our custom is to make all the big changes the day before freeze, ending up with untested and buggy stuff. > for screen-sharing. PipeWire was not mature enough to use it as default > sound server for Bullseye, but since it gained stability PulseAudio is notorious for failing to work on _some_ machines or working badly (eg. http://angband.pl/tmp/clem/pulse.flac), so even in the worst case we trade one set of bugs for another. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ʀᴜꜱꜱɪᴀɴᴇꜱ ᴇᴜɴᴛ ᴅᴏᴍᴜꜱ ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Re: Idea: autopkgtest on big-endian for 'Architecture: all' packages to catch endian bugs
On Sun, Aug 28, 2022 at 04:56:26PM +, Thorsten Glaser wrote: > Didier 'OdyX' Raboud dixit: > >If these tests are run at build-time, errors halt the build and that provides > > That may not be enough, though; there are cases where the build > architecture determines artefact endianness (e.g. with PCF bitmap > fonts), and that may even be enough (X servers can load PCFs from > reverse-endian builds), but it may be a bug. So you’d ideally use > both. Funny thing: there's not a single release architecture that's both bad-endian and supports X (they do build X related packages because the dependency graph is quite dense, but there are no users). So this particular problem has solved itself :) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ You're alive. But that's just a phase. ⠈⠳⣄
…/doc …/log: .gz → .zst
Meow! Because of the trimming changelogs discussion, I just wondered whether it'd be beneficial to switch compression from .gz to .zst (gzip to zstd). Numbers I got from the desktop I sit at: * du of a copy of /usr/share/doc 366692 * rm ! -name "*.gz" 194184 * decompress 656852 * repack as zstd 163340 31MB saving, decent but not world shattering. Let's do so...? But then, I looked at /var/log * du 257612 * rm ! -name "*.gz" 53028 * decompress 471892 * repack as zstd 16360 Holy apt! Now this is a find! This box is a desktop thus doesn't produce a lot of logs (just sbuild spam), but there's quite a few of my boxen where logs get very bulky. Thus: let's switch logrotate from gzip to zstd? As changing the default would upset scripts, let's do it at the same time as enabling dateext... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ You're alive. But that's just a phase. ⠈⠳⣄
Re: Changing the epoch of widelands package
On Tue, Aug 16, 2022 at 02:26:27PM +0200, Martin Quinson wrote: > as per policy 5.6.12, I'm seeking for a consensus for upgrading the epoch of > the > widelands package. The version currently in Debian is 1:21-2, corresponding to > the upstream build21. > > Last year, upstream released their v1.0 after maybe two decades of > developemnt, > but our watch file didn't detect it because 1.0 < 21. [...] > I thus think that we should package the new version as 2:1.0-1. It already has an epoch, incrementing it won't make the version any uglier. And your provided a good reason. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ You're alive. But that's just a phase. ⠈⠳⣄
Re: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
On Tue, Jul 19, 2022 at 05:43:35PM -0600, Sam Hartman wrote: > > "Guillem" == Guillem Jover writes: > Guillem> Hi! There's been talk about switching away from > Guillem> netkit-telnet and netkit-telnetd as the default > Guillem> implementations for some time now, and replacing them with > > I've reviewed your plan. Over the years I've maintained a telnet > upstream so I have some familiarity with the space even though I am no > longer involved in the telnet server universe. > I definitely think Debian should still have a telnet server, although it > is very much a niche application Available in the archive yes, installed by default no way. That makes this current thread mostly moot, as when not installed by default (or a metapackage) you don't need any particular implementation to be blessed. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Loongarch's name is loong. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Re: enabling LTO by default is vastly inappropriate (was Re: Bug#1015386: dietlibc: ftbfs with LTO (link time optimization) enabled)
On Tue, Jul 19, 2022 at 05:15:32PM +, Thorsten Glaser wrote: > Matthias Klose dixit: > >The goal is to enable this optimization by default in an upcoming > >Debian release in dpkg-buildflags for 64bit architectures. The goal > >is to get this package to build with link time optimizations, or to > >explicitly disable link time optimizations for this package build. > > This is daring, especially from the GCC maintainer. > > GCC (both in Debian and upstream) have been ignoring many known > bugs related to LTO (both in the -fwhole-program --combine and I have tried LTO when it came out, on a number of quite large complex codebases. In the 4.* days it was indeed full of bugs. But today, the I would say it is good enough for being enabled by default. > These bugs are subtile miscompilations. In mksh, only one test > by accident fails due to the GCC LTO bug. It’s definitely *not* What was the last version of gcc that you have tested? > (As for dietlibc, it’s inappropriate there anyway, so it opts out.) That's a shame, as it's specifically a library that could use reduced size due to the compiler being able to notice and excise unnecessary bits. A glance at the failure log shows that first we have an obvious bug that has been uncovered now: extern int main(int argc,char* argv[],char* envp[]); vs int main(int argc,char *argv[]) then some linker games. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ What kind of a drug are "base" and "red pill"? I think acid is ⢿⡄⠘⠷⠚⠋⠀ LSD, which would make base... ? Judging from the behaviour of ⠈⠳⣄ those "based and redpilled", something nasty.
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
On Tue, Jul 19, 2022 at 06:08:16PM +0200, Andrej Shadura wrote: > On Tue, 19 Jul 2022, at 16:57, Adam Borowski wrote: > > On Tue, Jul 19, 2022 at 01:48:17PM +0200, Andrej Shadura wrote: > >> Take Misha/Miša/Миша or Petya/Peťa/Петя. In Russian tradition, these are > >> very likely masculine names, from Mikhail and Petr. > > > If only this piece of software had a distinction between "almost always > > male", "leaning male", "neutral", "leaning female", "almost always > > female"... Oh wait, it does! > > Precisely for the reason you mention. > > No, it does not and cannot, since some names are almost always male in one > culture but almost always female in another one. In other words, if you don't pick a culture, the _global_ dataset (ie, the default one) must not assume either. It takes a lot of work to prepare such a database, that's why this package is good to have. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ At least spammers get it right: "Hello beautiful!". ⠈⠳⣄
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
On Tue, Jul 19, 2022 at 01:48:17PM +0200, Andrej Shadura wrote: > No need to go that far. > Andrea in Germany is traditionally a woman’s name, Andrea in Italy is a > masculine name. How can we tell if a certain specific Andrea is named > according to the German (Czech, Slovak etc) tradition (and hence likely a > woman) or the Italian (and hence probably a man)? There’s no way to > generally tell this based on the name alone. > > Take Misha/Miša/Миша or Petya/Peťa/Петя. In Russian tradition, these are > very likely masculine names, from Mikhail and Petr. If only this piece of software had a distinction between "almost always male", "leaning male", "neutral", "leaning female", "almost always female"... Oh wait, it does! Precisely for the reason you mention. > And we haven’t yet touched the topic of people who were given non-traditional > names. In which case it says "unknown". Meow! -- ⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased ⣾⠁⢠⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts. ⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got ⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.
Re: Bug#1015269: ITP: gnome-shell-extension-runcat -- desktop icon for showing CPU usage with cats
On Mon, Jul 18, 2022 at 05:33:00PM +0100, Shannon wrote: > Package Name: gnome-shell-extension-runcat > Version: 18 > Upstream Author: Sergei Kolesnikov > Description:desktop icon for showing CPU usage with cats > RunCat provides a key-frame animation to the GNOME Shell top bar. > Animation speed changes depending on CPU usage. > https://salsa.debian.org/gnome-team/shell-extensions/gnome-shell-extension-runcat/ Does it come with alternate animations? Like, say, a specific one drawn by Bruno Bellamy? :p Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ How to exploit the Bible for weight loss: ⢿⡄⠘⠷⠚⠋⠀ Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat. ⠈⠳⣄
Re: A mail relay server for Debian Members is live
On Sun, Jul 17, 2022 at 10:35:21AM +0200, Ansgar wrote: > On Sun, 2022-07-17 at 10:02 +0200, Mattia Rizzolo wrote: > > At this point, what about SPF? Ignoring potential whitelists on mail > > receivers, I think using this service doesn't provide extra > > advantages than signing on our own servers. > > Why SPF? It doesn't provide any extra advantages over DKIM. Both SPF and DKIM suck. They are both needed, though, to increase your chances to get delivered to poor souls who use Gmail (although you can never be sure your mail won't be silently dropped). Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Yo momma uses IPv4! ⢿⡄⠘⠷⠚⠋⠀ (And DC22 does too, meh...) ⠈⠳⣄
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
On Thu, Jul 14, 2022 at 08:14:13AM -0700, Russ Allbery wrote:
> Edward Betts writes:
>
> > I've been writing some code to work out the gender balance of speakers
> > at a conference. It parses the pentabarf XML of the schedule and feeds
> > the speaker names to this module.
>
> > Here's the results for Debconf 22.
>
> > 72 speakers
>
> > male 48 66.7%
> > unknown 16 22.2%
> > female 45.6%
> > mostly_male22.8%
> > andy 11.4%
> > mostly_female 11.4%
>
> I fear this may be an example of statistics that look meaningful but
> probably aren't because the error bar is much higher than the typical
> consumer of the statistic intuitively thinks it is. Although maybe that's
> not a worry in this case since the program itself says that it totally
> failed to make a guess about a quarter of the time.
So instead of making a knowingly-bad guess it says it doesn't know?
That's an upside in my book.
> I don't really have any objections to the package being in the archive;
> this is certainly something that a lot of people seem to want to do and
> thus seem to find some utility in doing. But unless one has a
> higher-quality source of data than just names (preferred pronouns, direct
> self-identification, etc.)
Real people who want to switch their visible gender (ie, how others view
them) do pick a name that matches the gender they want to present to the
world.
As of actually using first names for statistics:
Several years ago, I did stats on who does uploads in Debian.
My methodology was:
1. limit packages to "key packages" (RT meaning, ie popcon/d-i/{b-,}deps)
2. take the last changed-by of every package (this avoids maintainers
who haven't been seen in 20 years, etc)
3. for every unique name, manually:
a. do I recognize that person? If so, use gender I know.
b. is the first name gender-specific? (I know western and slavic names)
c. ~60 seconds of web search using DDG (I seemed to extend suspected
females to >15 minutes somehow...)
d. if none of the above gave an answer, say '?'
4. weight every name by the # of packages from 2. (ie, give count of
packages)
Obviously every step introduces inaccuracies; eg. I used first-[mid...]-last
name combinations, merging distinct spellings only when I spotted them by
hand. I seem to recall there are two DDs with the same name (I don't
remember who though), they'd be unified by this methodology. Of course
there'll be no error if they're of the same gender but that's not the case
for other uses of the input data.
Thus, my stats are _not perfect_. But, as long as I divulge my methodology,
it is sound science.
A famous example is one of first phone surveys, that worked by randomly
selecting phone numbers. The results turned out to be totally wrong -- with
individual-owned phones being still a quite new thing, phone owners tended
to be affluent and tech-friendly people, and their responses were not
representative of the population at large.
Thus, to be valid science, any use of statistics should disclose the
methodology used. But, that doesn't make the results any less valid,
it merely attaches a caveat. Barring some other error (eg. bogus random
generator, ignoring people who hang up, etc), that survey still provided
accurate info on the population of phone owners.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ Ash nazg durbatulûk,
⣾⠁⢠⠒⠀⣿⡁ ash nazg gimbatul,
⢿⡄⠘⠷⠚⠋⠀ ash nazg thrakatulûk
⠈⠳⣄ agh burzum-ishi krimpatul.
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
On Thu, Jul 14, 2022 at 04:05:35PM +0200, Jeremy Bicha wrote: > > > >* Package name: gender-guesser > Debian has a Diversity Statement [1] which says that Debian welcomes > people regardless of how they identify themselves. Trans people and > non-binary people face a lot of discrimination, harrassment and > bullying around the world. That bad treatment of these people is > against Debian's core values. Unless they're Jewish, believe that a woman should be allowed to abort a Down syndrome fetus, believe that there's more than just a name to the gender, or have a kind of transsexualism that matches their life's experiences and is detectable by brain imaging but the loud group says doesn't exist. The inconsistency here is astounding. > Therefore, the Debian Project wouldn't > want to distribute software that appears to facilitate that kind of > harassment, regardless of the software license it is released under. > We might not want to distribute such software even if it also has > non-harmful uses. While not 100% accurate and thus shouldn't be used to determine the gender of an _individual_, it's a very useful tools for analyzing larger datasets. And where it comes to diversity, we so much need data rather than assumptions. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ I was born a dumb, ugly and work-loving kid, then I got swapped on ⢿⡄⠘⠷⠚⠋⠀ the maternity ward. ⠈⠳⣄
Re: enabling link time optimizations in package builds
On Fri, Jun 17, 2022 at 12:40:34PM +0300, Nicholas Guriev wrote: > LTO significantly increase memory requirements for buildd machines. Do we > have > enough RAM and swap on each build server? > > > Link time optimizations are also at least turned on in other distros like > > Fedora, OpenSuse (two years) and Ubuntu (one year). > > I know Ubuntu has builders with 8 GB RAM + 4 GB swap which is not enough in > all cases. https://answers.launchpad.net/launchpad/+question/694428 This is on 퐚퐦퐝ퟔퟒ. You can have 24퐓B RAM boxen these days. Assigning 8GB to a buildd is a configuration error -- it's not about building package X at home or porting it to a bitty box. >> The proposal is to turn on LTO by default on most 64bit release >> architectures. As doko CCed -ports: With the hat of one of riscv64 porters on: hardware that is deemed sufficient for buildds has 16 GB RAM and nvme, with very slow CPUs. Thus, please include riscv64 among LTO archs, barring compiler issues of course. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ What kind of a drug are "base" and "red pill"? I think acid is ⢿⡄⠘⠷⠚⠋⠀ LSD, which would make base... ? Judging from the behaviour of ⠈⠳⣄ those "based and redpilled", something nasty.
Re: enabling link time optimizations in package builds
On Fri, Jul 01, 2022 at 07:52:16PM +0300, Adrian Bunk wrote: > On Fri, Jun 17, 2022 at 10:18:43AM +0200, Matthias Klose wrote: > > The proposal is to turn on LTO by default on most 64bit release > > architectures. > > By what factor does -ffat-lto-objects increase disk space usage during > package builds? > > Please coordinate with DSA to ensure that the buildds on these > architectures have sufficient diskspace. > > amd64 buildds have/had(?) only 74 GB of diskspace, which has even > without LTO already forced some packages to do manual cleanup steps > during the build to stay within the limited disk space. As amd64 is a fat arch these days, there's no excuse to not simply throw more hardware at this particular problems. We do have excess money and sponsors. > A bigger worry is the schedule of such a change. > A major toolchain change shortly before the freeze means the vast > majority of packages will be shipped with non-LTO builds in the release, So let's do such changes NOW rather than in December. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ What kind of a drug are "base" and "red pill"? I think acid is ⢿⡄⠘⠷⠚⠋⠀ LSD, which would make base... ? Judging from the behaviour of ⠈⠳⣄ those "based and redpilled", something nasty.
Re: how to convey package porting details?
On Mon, Jun 06, 2022 at 10:47:38AM +0200, Marco d'Itri wrote: > On Jun 06, Paul Wise wrote: > > > There are lots of packages that need porting to every new architecture > > that comes along. There are others that don't require porting but > > benefit in some way from porting to some aspect of the architecture. > Is this really worth the effort, considering that probably RISC-V is > going to be our last port for a very long time? loongarch has just been merged into mainline kernel, is in binutils 2.38 and gcc 12, and those guys seems to be doing some serious work to get into distributions. Besides CPU archs, it looks worthwhile to investigate replacing glibc with musl, which would represented as a new arch. We may also want to raise ISA baseline in eg. amd64 -- with the amount of old hardware in the wild, it'd certainly be done like armel->armhf rather than i386->(really i686). Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Loongarch's name is loong. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Bug#1012050: ITP: alpine-chroot-install -- bootstrap Alpine Linux into a chroot
Package: wnpp Severity: wishlist Owner: Adam Borowski X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: alpine-chroot-install Version : 0.13.3 Upstream Author : Jakub Kirutka * URL : https://github.com/alpinelinux/alpine-chroot-install * License : MIT Programming Lang: shell Description : bootstrap Alpine Linux into a chroot This script builds an Alpine Linux chroot, fetching packages from a network mirror. The installed system is quite minimal, but contains enough to let you install whatever you need using "apk". . In other words, it's alpine's debootstrap. This package will let us spy on the competition, steal their enablement of musl, and possibly similar naughty deeds. In theory it could also be used to port your stuff to Alpine, but that'd be treason, right?
Bug#1011230: ITP: miniasync -- library for asynchronous programming in C
Package: wnpp Severity: wishlist Owner: Adam Borowski X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: miniasync Version : 0.1.0~rc1 Upstream Author : Intel * URL : https://github.com/pmem/miniasync * License : BSD-3 Programming Lang: C Description : library for asynchronous programming in C miniasync is a minimalistic library used for asynchronous programming in C, based on futures that are an abstraction representing a task or a collection of tasks. . The library provides a "virtual data mover", an abstraction for asynchronous memory operations that avoids hard dependencies on any specific hardware offload.
Re: Firmware: Scope of non-free-firmware
On Wed, May 11, 2022 at 09:48:56AM +0800, Paul Wise wrote: > The only exception is things like firmware-sof-signed, which is libre > firmware except the binaries are built and signed by Intel, so Debian > can't build the firmware binaries ourselves, unless the approach taken > with the Secure Boot shim signing is possible. First reproducibly build > the binaries, then if they match Intel's signature, attach Intel's sig. > That relies on Intel using the same cross-compiler as Debian though. You may want to talk to people responsible for that firmware, reproducible builds sounds like an attainable goal to me. On the other hand, an update to the compiler can make it produce different binaries, making the signature invalid. Pinning the exact version of the compiler would be unpleasant. > > As examples to consider, do we want to include the following in our > > practical divergence from software freedom purity? > > Since clearly there will always be users with install use-cases that > aren't covered by main or even main plus non-free/firmware, perhaps we > should have multiple sets of images for different audiences with > different sets of non-free things? Each of them would explain what is > non-free and the consequences of that both on the page itself and in > prompts within the image itself. I'd say that closed encrypted signed firmware that you need to load on every boot is strictly more free than the same firmware burned into ROM. While you lack the usual Free Software freedoms, you at least can upgrade to whatever versions the vendor deigns to provide, downgrade to an old version you prefer, get bug fixes including security fixes, etc. With firmware burned into ROM the firmware stays broken. Thus, even though that closed proprietary software continues to be a problem, people who demand "pure" images are covering their eyes to not see that evil, reducing their freedom in practice. I prefer the nasty proprietary thing to be where I can see it. It's not different from Microsoft "Secure" Boot signature we ship in main -- a nasty thing that's required to use hardware you paid for. > Some of the packages (like firmware-siano) are not in any way needed by > the Debian installation process, despite containing firmware according > to reasonable definitions of that. They aren't needed for basic > functionality of a system either, just for specialised things > (receiving TV signals for eg). So they very likely aren't needed on the > non-free/firmware images and thus aren't needed in non-free/firmware? I don't see a reason to single out debian-installer, which is just a special case of a live CD. We already produce multiple size varieties of the installer (minimal, netinst, full) that pick which packages to install. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Aryans: split from other Indo-Europeans ~2900-2000BC → Ural → ⣾⠁⢠⠒⠀⣿⡁ Bactria → settled 2000-1000BC in northwest India. ⢿⡄⠘⠷⠚⠋⠀ Gypsies: came ~1000AD from northern India; aryan. ⠈⠳⣄ Germans: IE people who came ~2800BC to Scandinavia; not aryan.
Re: isa-support -- exit strategy?
On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote:
> On Fri, Mar 25, 2022 at 11:34:17PM +0100, Adam Borowski wrote:
> > * while a hard Depends: works for leafy packages, on a library it
> > disallows having alternate implementations that don't need the
> > library in question. Eg, libvectorscan5 blocks a program that
> > uses it from just checking the regexes one by one.
> glibc 2.33 added a modernized version of the old hwcaps.
> If a package builds a library several times with different optimizations
> and installs them into the correct directories in the binary package,
> the dynamic linker will automatically select the fastest one supported
> by the hardware.
>
> SIMDe (or similar approaches) could be used to build variant(s) of the
> library that have compile-time emulation of SIMD instructions in the
> lower baseline builds of vectorscan.
In this particular case, it'd probably be faster to use non-SIMD ways
instead of emulating them. This means two code paths, which particular
users may or may not want to do the effort to implement.
> For binaries, I have seen packages in the Debian Med (?) team that build
> several variants of a program and have a tiny wrapper program that chooses
> the correct one at startup.
This may take substantial work to implement, which for typical Debian Med
packages is an utter waste of time.
I wonder why vectorscan requires SSE4.2 while hyperscan that it's a fork of
is happy with SSE3; a personal mail server may be perfectly adequate on
hardware lacking either -- but no SSE4.2 is still realistic while no SSE3
on amd64 requires some pretty specific dumpster diving (it's lacking only
on early steppings of Athlon 64). Still, by our rules, SSE3 is not in the
arch baseline, thus it's a RC bug not to run without.
And thus, a Debian Med package is required to provide non-SSE3 builds that
are almost untestable without hard-to-get hardware, that's a pure waste of
maintainer time.
While that mail server may be fully happy with checking the patterns with
libpcre one by one. What {vector,hyper}scan are good for is matching _many_
regexes on _many_ lines of data; if there's either few patterns or little
data, the serial slow way is as good or better.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ Eight legs good, four legs bad! -- when your drider pwns a
⣾⠁⢠⠒⠀⣿⡁ smelly goodie centaur.
⢿⡄⠘⠷⠚⠋⠀ Rearkick OP -- my grandpa's brother-in-law got one-shotted
⠈⠳⣄ from full hp in RL, please nerf!
Re: What to do with merged /usr and dpkg-fsys-usrunmess
On Wed, Apr 06, 2022 at 12:03:55PM +0200, Krzysztof Sobiecki wrote: > Hi, > I saw warning and it advised me to use dpkg-fsys-usrunmess: > But now I see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008486 > And even without that there are problems with that tool: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991218 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991192 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008316 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008478 > > Now what I'm supposed to do? Wait for dpkg-fsys-usrunmess-unmess? > Is my system broken because I have used dpkg-fsys-usrunmess(that dpkg > advised me to do?). > As a Debian user I'm confused and a bit angry. For an user: these boats are currently unstable, it's best to sit tight -- they topple only if you move around, especially when jumping between them. > What is way forward? That's the subject of a series of flamewars second in length and intensity only to the systemd debacle. You don't want to go there. The usrmerged state, while wished for by some, is currently pretty broken unless you refrain from a number of actions that are natural for packagers (inside and outside Debian) and users to do, this is considered unacceptable by the dpkg maintainer and eg. me. There is a proposal for a constructive patch set to dpkg that _may_ resolve this without nasty hacks everywhere; the patches themselves haven't been AFAIK implemented yet but there is much hope. If that fails, the drama will resume, with the big question being "WHY?". Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Eight legs good, four legs bad! -- when your drider pwns a ⣾⠁⢠⠒⠀⣿⡁ smelly goodie centaur. ⢿⡄⠘⠷⠚⠋⠀ Rearkick OP -- my grandpa's brother-in-law got one-shotted ⠈⠳⣄ from full hp in RL, please nerf!
isa-support -- exit strategy?
Hi! While packages are allowed to not support entire architectures outright, there's a problem when some code requires a feature that is not present in the arch's baseline. Effectively, this punishes an arch for keeping compatibility. The package's maintainers are then required to conform to the baseline even when this requires a significant work and/or is a pointless exercise (eg. scientific number-crunching code makes no sense to run on a 2002 box). With that in mind, in 2017 I added "isa-support" which implements install-time checks via a dependency. Alas, this doesn't work as well as it should: * new installs fail quite late into installation process, leaving you with a bunch of packages unpacked but unconfigured; some apt frontends don't take this situation gracefully. * upgrades when an existing package drops support for old hardware are even worse. * while a hard Depends: works for leafy packages, on a library it disallows having alternate implementations that don't need the library in question. Eg, libvectorscan5 blocks a program that uses it from just checking the regexes one by one. Suggestions? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Eight legs good, four legs bad! -- when your drider pwns a ⣾⠁⢠⠒⠀⣿⡁ smelly goodie centaur. ⢿⡄⠘⠷⠚⠋⠀ Rearkick OP -- my grandpa's brother-in-law got one-shotted ⠈⠳⣄ from full hp in RL, please nerf!
Re: proposed MBF: packages still using source format 1.0
On Tue, Mar 15, 2022 at 10:46:10AM +, Ian Jackson wrote:
> Ian Jackson writes ("Re: proposed MBF: packages still using source format
> 1.0"):
> > But I see now that the MBF has gone ahead anyway.
> For example, consider a package maintained by a sponsee of mine:
>
> Debian is not upstream, so it has a Debian revision. The package is
> maintained in git, and the source package is very small and it is not
> uploaded frequently. So we use a native source format. This means
> that we must use format 1.0 because dpkg hates 3.0 native with debian
> revision.
So the package is really non-native; your beef here is with requiring a
tarball. Your workaround is to [mis]use the native format.
But even legitimely native packages do want a Debian revision sometimes.
Eg. the natural versioning for valgrind-if-available would track
corresponding valgrind versions. The 3.0 format restriction forbids
that.
So the bad thing is tying the internal format with version numbers.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁'Russkiy voyennyi korabl, idi nakhuy'
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄
Re: Bug#1006885: ITP: lumin -- pattern match highlighter
On Mon, Mar 07, 2022 at 05:50:43PM +0100, Stephen Kitt wrote: > * Package name: lumin > Version : 1.0.0 > * URL : https://github.com/johnkerl/lumin > Description : pattern match highlighter > > lumin highlights matches to a specified pattern (string or regular > expression) in files, using color. This is similar to grep with > colorized output, but it outputs all lines in the given files, not > only matching lines. .--[ ~/bin/hl ] #!/bin/sh sed 's/'"$*"'/\c[[1;33m&\c[[0m/g' ` > This is a new dependency of Miller 6.1.0. Meow!> -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁'Russkiy voyennyi korabl, idi nakhuy' ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Re: proposed MBF: packages still using source format 1.0
On Mon, Mar 07, 2022 at 05:35:43PM +0200, Wouter Verhelst wrote: > On Sun, Mar 06, 2022 at 09:25:45PM +0100, Lucas Nussbaum wrote: > > Wouter Verhelst > >aspic > >logtool > > Yeah, no. These will be reduced to "wishlist" and probably tagged > "wontfix". Both of these packages have no patch system, so the whole work is: mkdir -p debian/source echo '3.0 (quilt)' >debian/source/format echo single-debian-patch >debian/source/options Less effort than typing an answer to the bug report. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁'Russkiy voyennyi korabl, idi nakhuy' ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Re: MBF: valgrind-if-available
On Sun, Feb 27, 2022 at 01:40:48AM +0100, Ben Hutchings wrote: > On Sun, 2022-02-20 at 22:43 +0100, Adam Borowski wrote: > > if which valgrind >/dev/null; then > > This should use "command -v", not which, I think? No, and the recent debacle revealed enough reasons that I'm pondering a MBF to change that _back_ in packages which followed the bad advice. Among others, "command -v" * gets confused by aliases * it fails to check +x perm both in dash and bash. While this is something required by POSIX, neither shell in unstable checks that, reporting the command as executable if it's not. * built-ins get reported as available. And busybox has even "dpkg" built-in, with a pretty bad implementation. while the only reason to migrate was: * one less tool to maintain Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁'Russkiy voyennyi korabl, idi nakhuy' ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Re: MBF: valgrind-if-available
On Sun, Feb 20, 2022 at 04:32:43PM -0500, Jeremy Bicha wrote: > On Sun, Feb 20, 2022 at 1:46 PM Adam Borowski wrote: > > The correct answer currently is: > > [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64] > > but it keeps changing, and you don't want to track it by hand if I can do > > that for you. > > > > Thus: please [b-]depend on valgrind-if-available. > Do you have any suggestions on how to handle this when the valgrind > test is set by a configure flag? Is the configure flag required to enable valgrind tests? If not, the very point of "configure" scripts is to auto-detect presence of tools. > The way I've been handling it is to just keep a hard-coded list of > valgrind architectures in sync between my debian/control and > debian/rules. if which valgrind >/dev/null; then Meow! -- ⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased ⣾⠁⢠⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts. ⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got ⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.
MBF: valgrind-if-available
Hi ladies and gentelhackers! A lot of packages Build-Depend on valgrind, in order to run checks for memory leaks, data races and what not during the testsuite. Alas, valgrind is not available on some architectures, even release (armel) or want-to-be- release (riscv64). Keeping the list current requires watching the valgrind package, and not just the list it declares but archs where it actually builds on (not x32...) and works (as of today all, but that wasn't always the case). You can now replace that list by: Build-Depends: valgrind-if-available or preferably: Build-Depends: valgrind-if-available If you want to temporarily exclude an arch please do that with: Build-Depends: valgrind-if-available [!zx-spectrum !pdp11] instead of repeating the whole valgrind list. Getting the list wrong results either in: * failing to build on some archs, see eg. https://buildd.debian.org/status/package.php?p=libdnf * not running valgrind tests, letting bugs slide And most packages get it wrong; the counts are: 7 valgrind [amd64 arm64 armhf i386 mips mips64el mipsel powerpc ppc64 ppc64el s390x] 5 valgrind 3 valgrind [amd64 i386 powerpc] 2 valgrind [amd64 i386] 2 valgrind [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64] 2 valgrind [!riscv64] 2 valgrind 1 valgrind-mpi [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64] 1 valgrind [i386 amd64 powerpc armhf] 1 valgrind [amd64] 1 valgrind [amd64 i386] 1 valgrind [amd64 i386 armhf arm64] 1 valgrind [amd64 armhf i386 mips mipsel powerpc s390x] 1 valgrind [amd64 armhf arm64 i386 mips64el mipsel ppc64 ppc64el s390x] 1 valgrind [amd64 arm64 armhf i386 ppc64el s390x powerpc ppc64] 1 valgrind [amd64 arm64 armhf i386 powerpc ppc64el x32] 1 valgrind [amd64 arm64 armhf i386 powerpc ppc64 ppc64el s390x] 1 valgrind [amd64 arm64 armhf i386 mipsel mips64el powerpc ppc64 ppc64el s390x] 1 valgrind [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x] 1 valgrind [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64 x32] 1 valgrind [amd64 arm64 armhf i386 mips64el mipsel powerpc ppc64 ppc64el s390x] 1 valgrind [amd64 arm64 armhf i386 mips64 mips64el mips mipsel powerpc ppc64 ppc64el s390x] 1 valgrind [amd64 arm64 armhf i386 mips mipsel mips64 mips64el powerpc ppc64 ppc64el s390x x32] 1 valgrind [amd64 arm64 armhf i386 mips mips64el powerpc ppc64el s390x] 1 valgrind [amd64 arm64 armhf i386 mips mips64 powerpc ppc64 ppc64el s390x] 1 valgrind [amd64 arm64 armhf i386 mips mips64 mips64el mipsel powerpc ppc64 ppc64el s390x] 1 valgrind [!riscv64], valgrind (>= 1:3.15.0) [arm64] 1 valgrind [!ia64 !riscv64 !x32 !mips !sparc64 !sh4 !ppc64 !powerpcspe !hppa !alpha !mips64el !armhf !armel !mipsel !m68k] 1 valgrind [!arm64 !ppc64el !armel !alpha !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !m68k !powerpcspe !sh4 !sparc64 !x32] 1 valgrind [!arm64 !ppc64el !armel !alpha !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !m68k !powerpcspe !sh4 !sparc64 !x32 !ia64 !riscv64] The correct answer currently is: [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64] but it keeps changing, and you don't want to track it by hand if I can do that for you. Thus: please [b-]depend on valgrind-if-available. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Being wise is hard, but wise-ass... ooh, this one I can deliver! ⠈⠳⣄ "Adam C. Powell, IV" mpich (U) petsc (U) slepc (U) Adam Borowski libpmemobj-cpp pmdk pmemkv vmemcache Alastair McKinstry mpich (U) Andreas Boll libdrm (U) mesa (U) Andreas Tille pyutilib (U) Andres Salomon chromium (U) Anton Gladky dyssol (U) sundials (U) Ayatana Packagers xorg-gtest Benjamin Drung rdma-core Bernd Zeimetz ceph (U) Ceph Packaging Team ceph ChangZhuo Chen (陳昌倬) jq Christophe Trophime freefem++ (U) getdp (U) Christopher James Halse Rogers mir (U) Debian Bridges Team libbloom Debian Chromium Team chromium Debian EFI fwupd Debian GCC Maintainers libabigail Debian GNOME Maintainers gnome-software Debian GSS Team gss Debian Mir Team mir Debian Multimedia Maintainers kodi Debian Octave Group octave Debian Perl Group libfurl-perl libtest-valgrind-perl Debian Python Modules Team pyutilib Debian Qt/KDE Maintainers qtmir (U) Debian Remote Maintainers arctica-greeter Debian Science Maintainers cthreadpool deal.ii dyssol freefem++ mpich petsc petsc4py slepc slepc4py Debian Science Team dolfin fenics-dolfinx fenicsx-performance-tests getdp mshr sundials Debian Shishi Team shishi Debian UBports Team mir (U) qtmir Debian X Strike Force libdrm mesa xserver-xorg-video-intel Debichem Team opendrop Dima Kogan sundials (U) Dimitrios Eftaxiopoulos freefem++ (U) Drew Parsons dolfin (U) fenics-dolfinx (U) fenicsx-performance-tests (
Re: Bug#1005324: ITP: valgrind-if-available -- dependency package to pull in Valgrind if it's available
On Fri, Feb 11, 2022 at 10:58:26AM +0100, Ansgar wrote: > On Fri, 2022-02-11 at 10:37 +0100, Adam Borowski wrote: > > This metapackage installs Valgrind on architectures where it is > > available. > > As the list of archs where Valgrind works changes quite often, > > The list is the same for all of oldoldstable, oldstable, stable, > testing and unstable though: > > +--- > | valgrind | 1:3.12.0~svn20160714-1+b1 | oldoldstable| amd64, arm64, > armhf, i386, mips, mips64el, mipsel, ppc64el, s390x > | valgrind | 1:3.14.0-3| oldstable | source, amd64, > arm64, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x > | valgrind | 1:3.16.1-1| stable | source, amd64, > arm64, armhf, i386, mips64el, mipsel, ppc64el, s390x > | valgrind | 1:3.18.1-1| testing | source, amd64, > arm64, armhf, i386, mips64el, mipsel, ppc64el, s390x > | valgrind | 1:3.18.1-1| unstable| source, amd64, > arm64, armhf, i386, mips64el, mipsel, ppc64el, s390x > +--- > > So this would just be "Depends: valgrind" on all architetures? There's no armel on your lists. There's no support for most -ports archs, including riscv64 which is supposed to be released with bookworm. And x32 is on valgrind's archs list but fails to build. We also had valgrind quite broken on some archs due to a glibc update, with no fix for a year (any threaded program segfaulted). Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Ash nazg durbatulûk, ⣾⠁⢠⠒⠀⣿⡁ ash nazg gimbatul, ⢿⡄⠘⠷⠚⠋⠀ ash nazg thrakatulûk ⠈⠳⣄ agh burzum-ishi krimpatul.
Bug#1005324: ITP: valgrind-if-available -- dependency package to pull in Valgrind if it's available
Package: wnpp Severity: wishlist Owner: Adam Borowski X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: valgrind-if-available Description : dependency package to pull in Valgrind if it's available This metapackage installs Valgrind on architectures where it is available. As the list of archs where Valgrind works changes quite often, explicitely listing it as a [Build-]Depend is cumbersome and prone to being outdated. Instead, you may use this metapackage. It's basically a Build-Recommend, except for doing the right thing during temporary non-installability of valgrind (ie, your package will wait in BD-Uninstallable if valgrind is _supposed_ to be available). There's a crapload of packages that B-Dep on valgrind on some arches, every one manually listing them. This is tedious. This metapackage could be built from src:valgrind, but conditionalizing every bit of build is tricky (all normal stuff needs to be suppressed). This separate source brings one instance of redundant list, but has less moving parts.
LESS copyright, not more!
Guys, once again we had a complaint about forcing people to waste their time on copyright matters then wait months or years for review of said matters -- just for the discussion degenerate into a proposal to bring even MORE copyright into our life! > - What is REUSE? > The REUSE specification [1] is a specification to make copyright > machine-readable in the source files itself. It is straightforward to > implement, add (e.g.) "SPDX-FileCopyrightText: 2019 Jane Doe [...] > The spec is made by the Free Software Foundation Europe (FSFE) and is > already implemented in several projects [3]. ... and this proposal includes gems such as an extra copyright-only file per every image. Dᴏ ɴᴏᴛ ᴡᴀɴᴛ! The Social Contract says clearly: "Our priorities are our users and free software" -- NOT copyright lawyers. I, and probably others, consider copyright to be a crime against humanity -- and this is not just a figure of speech[1]. We are forced to comply with these laws, risking fines and violence if we don't, but why should we put more effort than the minimum necessary? Other distributions have proven than doing less than we do is enough. And even perfect compliancy is no defense against a multi-decade lawsuit that generates massive costs. And us poring over copyrights of every file does cost us a lot -- the time of developers, especially highly skilled ones, does cost quite a penny. That most of Debian work is volunteer doesn't lessen the value of that time. Let's not waste it. Meow! [1]. diff(humans vs other animals) =~ transmission of ideas, etc -- ⢀⣴⠾⠻⢶⣦⠀ Aryans: split from other Indo-Europeans ~2900-2000BC → Ural → ⣾⠁⢠⠒⠀⣿⡁ Bactria → settled 2000-1000BC in northwest India. ⢿⡄⠘⠷⠚⠋⠀ Gypsies: came ~1000AD from northern India; aryan. ⠈⠳⣄ Germans: IE people who came ~2800BC to Scandinavia; not aryan.
Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
On Tue, Jan 25, 2022 at 09:38:01PM +0100, Vincent Bernat wrote: > For me, the copyright check is just a bad excuse. People upload > non-distributable stuff everywhere and it seems the world continue to go > round. What amount of non-distributable packages is stopped by the NEW > queue? > > I think we should forego the NEW queue. If people want to check > packages, they can do it once they are in unstable with regular bugs. Without the NEW queue, there would be no point at which packaging receives any sort of review. I'd prefer Debian to deliver at least some level of quality. Otherwise, we'd fall to the level of NPM. And there's ample examples what that would mean. > Current checks are partly done by Lintian and I suppose people could > watch new Lintian warnings and detect bad packages quickly. Lintian is just a dumb machine that can ease human reviews but not replace them. > This could be done when src is not NEW as a test. I've managed to trample upon someone else's package just yesterday -- and it escaped automated checks because a binary of that name already existed in the archive, just not on any arch which I test. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Aryans: split from other Indo-Europeans ~2900-2000BC → Ural → ⣾⠁⢠⠒⠀⣿⡁ Bactria → settled 2000-1000BC in northwest India. ⢿⡄⠘⠷⠚⠋⠀ Gypsies: came ~1000AD from northern India; aryan. ⠈⠳⣄ Germans: IE people who came ~2800BC to Scandinavia; not aryan.
Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
On Wed, Jan 26, 2022 at 10:44:37AM +0100, Gard Spreemann wrote: > Jonas Smedegaard writes: > > Quoting Vincent Bernat (2022-01-25 21:38:01) > >> I didn't comment at first because I thought someone else would raise > >> the idea. But it seems people still like the idea of a NEW queue. Not > >> me. The NEW queue is a hindrance. > > I don't like current copyright laws, and I suspect a fair amount of > > people involved in Free Software doesn't. I for one consider copyright theft, a crime against humanity[1], and a waste of time. Any second spent dealing with copyright is a second not spent adding features or fixing technical bugs. For practical reasons we have to obey the laws, no matter how oppressive they are. But I don't see why we should do more than eg. Fedora which has corporate backing with an actual legal team. For those of you without a Fedora box at hand, I made a tarball: https://angband.pl/tmp/fedora-licenses.tar.xz This is so less than we do! > > I just don't think the solution is to ignore copyright or licensing > > statements. On the other hand, "grep -r Copyright|uniq" plus a copy of non-standard licenses would be enough. > To me, the elephant in the room is this question: Does the way the NEW > queue currently works provide good (good enough?) assurances to > ourselves that we are *not* ignoring copyright or licensing? I think the NEW review is much needed, and currently grossly inadequate -- and that's because 95% of the FTPmaster time being spent on copyright crap rather than technical matters. Meow! [1]. The needs of a human go into two groups: 1. those shared with non-human animals (food, air, freedom, shelter, reproduction, not being killed, not being hurt, etc), and 2. those dependant on transmission of ideas. And transmission of ideas is directly hindered by copyright. -- ⢀⣴⠾⠻⢶⣦⠀ Ash nazg durbatulûk, ⣾⠁⢠⠒⠀⣿⡁ ash nazg gimbatul, ⢿⡄⠘⠷⠚⠋⠀ ash nazg thrakatulûk ⠈⠳⣄ agh burzum-ishi krimpatul.
Bug#1004287: ITP: rapidcheck -- C++ framework for property based testing
Package: wnpp Severity: wishlist Owner: Adam Borowski X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rapidcheck * URL : https://github.com/emil-e/rapidcheck * License : BSD-2 Programming Lang: C++ Description : C++ framework for property based testing RapidCheck is a C++ framework for property based testing inspired by QuickCheck and other similar frameworks. In property based testing, you state facts about your code that given certain precondition should always be true. RapidCheck then generates random test data to try and find a case for which the property doesn't hold. If such a case is found, RapidCheck tries to find the smallest case (for some definition of smallest) for which the property is still false and then displays this as a counterexample. For example, if the input is an integer, RapidCheck tries to find the smallest integer for which the property is false. I don't really care about this package, but it's a Build-Dependency.
Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
On Fri, Jan 21, 2022 at 01:28:54PM -0500, Scott Kitterman wrote: > 2. New binary package "steals" binary from another source. This is > sometimes > OK. Sometimes it's accidental. It could also be malicious (I don't remember > if I've every actually seen this done for an intentional "steal" or not, I > might have). Stealing a binary does not go through NEW. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Aryans: split from other Indo-Europeans ~2900-2000BC → Ural → ⣾⠁⢠⠒⠀⣿⡁ Bactria → settled 2000-1000BC in northwest India. ⢿⡄⠘⠷⠚⠋⠀ Gypsies: came ~1000AD from northern India; aryan. ⠈⠳⣄ Germans: IE people who came ~2800BC to Scandinavia; not aryan.
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
On Wed, Dec 29, 2021 at 04:35:22PM -0500, Scott Kitterman wrote: > The postfix package ships a script in /etc/resolvconf/update-libc.d/ to > restart > postfix when resolv.conf is updated. As far as I know, that still works if > the > resolvconf package is installed, but if not (i.e. Debian default), what's the > equivalent? Does systemd-resolved have an equivalent? Should users that > want > this functionality install resolvconf? The whole point is resolvconf is to be a common interface between producers: * ifup/ifdown * DHCP clients * PPP daemon * local name servers and consumers: * DNS caches * resolver libraries (including glibc) If systemd-resolved doesn't interface with resolvconf yet, then these tools should be taught to pass data, instead of inventing a yet another user-facing interface. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ No matter if fathered by Abdes Pantera or a deity, Jesus ⢿⡄⠘⠷⠚⠋⠀ was a bastard. ⠈⠳⣄
Re: Search content (.h files) of all (-dev) packages?
On Thu, Nov 11, 2021 at 04:27:47PM +0100, Alexander Traud wrote: > Question: Exists an (easy) way to 'grep' all headers files of all packages in > Debian? Codesearch indexes 퐬퐨퐮퐫퐜퐞 packages, it sounds like you want binaries. wget http://ftp.debian.org/debian/dists/sid/main/Contents-amd64.gz apt download `zgrep '\.h ' Contents-amd64.gz |rev|cut -d/ -f1|rev|sort|uniq` ... which fetches all packages that provide a .h file. On the other hand Contents-source uses a tab and no section: wget http://ftp.debian.org/debian/dists/sid/main/Contents-source.gz apt source `zgrep '\.h\t' Contents-source.gz |cut -d$'\t' -f2|sort|uniq` Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ “Exegi monumentum aere perennius” -- “I made a monument more ⢿⡄⠘⠷⠚⠋⠀ durable than bronze”. ⠈⠳⣄ -- Horace (65-8 BC), leaving the loo, constipated
Re: merged-/usr transition: debconf or not?
On Wed, Nov 10, 2021 at 07:01:15PM +0100, Marco d'Itri wrote: > On Nov 10, Sam Hartman wrote: > > > I'm sorry, but I think the only way in which that horse is dead is that > > no one has proposed patches to dpkg. > Indeed, because the sides of this argument are like three people (one of > them being the dpkg maintainer) versus everybody else. > Since some significant work on dpkg is reasonably not forthcoming then > this is clearly not a viable transition method. Until we have that in place, going any further with usrmerge is not viable. All the TC brought us so far is a wishlist, not a working implementation. Thus, I'd say it's time to consider whether the trouble we have (substantial, as evidenced by discussions still going and going) is worth the gains (are there even any?). So either you do the work to revive the horse or it stays put. Meow. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Polexit is brewing? Let's skip that smelly Polsha and reactivate ⢿⡄⠘⠷⠚⠋⠀ the Free City of Danzig and/or reapply to the Hansa. ⠈⠳⣄
Re: Q. What is the best practice about +dfsg and +ds extension?
On Sat, Oct 02, 2021 at 03:12:04PM +0200, Timo Röhling wrote: > * Jonas Smedegaard [2021-10-02 15:03]: > > I use ~ (tilde) as delimiter when possible, to make room for an eventual > > later release with the issues fixed, without needing ugly versioning or > > being forced to wait for a later upstream release. > Has this actually ever happened? I would expect that most upstream > authors would rather create a new patch release than retroactively > change the contents of an existing one. If the old version was 1.4, the one with the minor content change (like deleting some Windows binaries) is likely to be called 1.4-nocontrib, 1.4.1 or 1.4a. Using a too high character risks making the altered release to have a higher version than the upstream. + is 0x2b - is 0x2d . is 0x2e ~ is less than the empty string Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Being wise is hard, but wise-ass... ooh, this one I can deliver! ⠈⠳⣄
Re: partman, growlight, discoverable partitions, and fun
On Sun, Sep 26, 2021 at 01:41:18AM -0400, nick black wrote: > Marco d'Itri left as an exercise for the reader: > > And the preseeding syntax is as powerful as it is inconvenient. > > 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. I'd start with asking porters of m68k and sparc64 whether today's systems even run anything but Linux. I think there's little point in keeping compat with 80s' OSes. At a risk of drawing ire of m68k/sparc64 folks, I'd also suggest not putting your tuits there until this millenium's hardware is covered well. > 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. I personally think that preseed is nasty enough that users who do automation on a scale that would make learning it worthwhile already have a better way to do such automation. For me, d-i is for manual installs, scripted stuff wants a partitioner + glorified debootstrap. 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)? 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. >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. 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. And most importantly: thanks for this effort, it's greatly appreciated! Meow. [1]. The malice hasn't been invented by the implementor of the old partitioner -- it was done by marketing departments of disk vendors in the old days; they don't even do so anymore but as they tried going through standard bodies while fighting lawsuits, some damage lingers on. The fault of our old partitioner is that it didn't filter out the malice. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A white dwarf seeks a red giant for a binary relationship. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Bug#994958: ITP: critnib -- ordered map data structure with lock-free reads
Package: wnpp Severity: wishlist Owner: Adam Borowski X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: critnib Version : 1.0 Upstream Author : yours truly * URL : https://github.com/kilobyte/critnib * License : BSD-3 Programming Lang: C Description : ordered map data structure with lock-free reads Critnib is a data structure that provides a very fast equal and less-than/greater-than searches; it is a mix between DJBerstein's critbit and radix trees. While in bad cases it has worse memory use than binary trees, it works well on real-life data which tends to have a limited number of "decision bits": * fully random: divergence happens immediately * malloc addresses: clumps of distinct bits in the middle * sequences: only lowest bits are filled . This library ships only uintptr_t→uintptr_t mappings, optimized for reads from a very critical section but not so frequent writes. Other variants also exist (such as fully lock-free writes, keys of arbitrary length), and can be added upon request.
a[uto]p[kg]t[ests] on non-any (was: Re: say hello to our studious bookworm)
On Sun, Aug 15, 2021 at 12:02:00AM +0100, Jonathan Wiltshire wrote: > Following the release of bullseye, we can confirm that autopkgtests (when > provided) will continue to be considered across all architectures for > migration to bookworm. In other words, the tests need to succeed on all > release architectures for your package to migrate. Is this just the old "no regressions", or "no fails" as was announced somewhere as the plan for Bookworm? Britney still considers packages that are excluded on some archs¹ to be not fully passing, which currently means depriving such packages from the migration time bonus. But, if "no fails" is indeed your plan... Meow! ¹. ignoring armel mips64el mips s390x. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out, ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the ⠈⠳⣄ sky. Your cat demands food. The priority should be obvious...
Re: ARM architectures
On Sat, Jun 05, 2021 at 03:04:45PM +0300, Andrei POPESCU wrote: > Any of the boards from pine64.org should do and as far as I know have > quite good support (i.e. there are Debian Installer images for them) and > all are 64 bit ;) +1 to pine64 gear. > The PINE A64+ (2 GB RAM) is very stable for me, unless I put significant > load on the USB connection (specifically *heavy* writing to an external > HDD in a powered enclosure), but it could also be a power issue. It's only USB2 -- in a board that has reliable gigabit ethernet. Plus, there's no such thing as stable USB-connected disk, anywhere. I'd recommend using nbd instead. > For a cheap board now I'd probably go for a ROCK64 (USB3 instead of > USB2), or even a RockPro64 (better CPU, PCIe, unfortunately limited to 4 > GB RAM). Both Pine64 and RockPro64 come as laptops, by the way -- Pinebook and Pinebook Pro, respectively. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ The oldest dated printed book includes the following license grant: ⣾⠁⢠⠒⠀⣿⡁ Reverently made for universal free distribution by Wang Jie ⢿⡄⠘⠷⠚⠋⠀ on behalf of his two parents on the 15th of the 4th moon of ⠈⠳⣄ the 9th year of Xiantong [11 May 868].
Re: perl necessary for debootstrap, why?
On Sat, Jun 05, 2021 at 10:03:55AM +0200, Marc Haber wrote: > On Fri, 4 Jun 2021 21:54:16 +0200, RhineDevil > wrote: > >I've looked up /usr/share/debootstrap/functions and I've seen some perl code > >What does this code do exactly and why wasn't it translated to shell? > Writing it in shell would probably be way slower. And debootstrap is already unbearably slow. I don't think it's a good use of your time to work on improving it, though. We already have mmdebstrap functional -- it's an order of magnitude faster than debootstrap. It should just be integrated into d-i and the like. Then there's my zdebootstrap (unfinished PoC) that's extra two orders of magnitude faster than that. I had no time to hack on it in a while, though. Thus, I guess you'd want to adapt mmdebstrap to your needs. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ The oldest dated printed book includes the following license grant: ⣾⠁⢠⠒⠀⣿⡁ Reverently made for universal free distribution by Wang Jie ⢿⡄⠘⠷⠚⠋⠀ on behalf of his two parents on the 15th of the 4th moon of ⠈⠳⣄ the 9th year of Xiantong [11 May 868].
Re: Would you please share me any information about which version of Debian supports NVDIMM？
On Thu, May 27, 2021 at 06:31:42AM +, Yuhua Zou wrote: > Dear All, > I assume Debian have supported NVDIMM from the following links: > https://lists.debian.org/debian-devel/2016/12/msg00330.html > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829257 > > I can install package “ndctl” in Debian 10.9. > > I explored Debian wiki but couldn't find any information about which > versions are supporting NVDIMM. The package in Buster (Debian 10) is functional. Because the hardware is so new, though, I'd recommend instead using packages from buster-backports -- or perhaps the hard-frozen almost-released Bullseye (Debian 11). Same goes for other bits of userland stack, and for the kernel. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ The oldest dated printed book includes the following license grant: ⣾⠁⢠⠒⠀⣿⡁ Reverently made for universal free distribution by Wang Jie ⢿⡄⠘⠷⠚⠋⠀ on behalf of his two parents on the 15th of the 4th moon of ⠈⠳⣄ the 9th year of Xiantong [11 May 868].
Re: Bug#988864: ITP: emacs-doom-themes -- opinionated pack of modern Emacs color-themes
On Thu, May 20, 2021 at 08:01:24AM -0700, Raúl Benencia wrote: > * Package name: emacs-doom-themes > * URL : https://github.com/hlissner/emacs-doom-themes > Description : opinionated pack of modern Emacs color-themes > > DOOM Themes is an opinionated UI plugin and pack of themes. > Additionally, DOOM Themes includes 40+ extra themes. [...] > The “emacs-” prefix is left on the source package name to avoid > confusions with the Doom game. The binary package name will be > “elpa-doom-themes”. So I read this with half on an eye while watching something else, get excited... then I see "emacs". Boo :( :p Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Being wise is hard, but wise-ass... ooh, this one I can deliver! ⠈⠳⣄ y
Bug#987235: ITP: pcm -- tools for Intel-specific processor performance and energy metrics
Package: wnpp Severity: wishlist Owner: Adam Borowski X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pcm Upstream Author : Intel * URL : https://github.com/opcm/pcm/ * License : BSD-3 Programming Lang: C++ Description : tools for Intel-specific processor performance and energy metrics Processor Counter Monitor is a set of tools to access various performance metrics provided by newer Intel processors. Such metrics include: * instructions per cycle * core frequencies * memory/interconnect/PCIe bandwidth * cache misses and utilization * time spent in C-states * thermal headroom * energy consumption * NUMA accesses and more.
Re: Bug#986382: DPL Jonathan Carter's passport number is ****909
On Sun, Apr 04, 2021 at 09:22:16PM +0200, crazy.mo...@lavache.com wrote: > We are contributors to Debian > > The contribution of every one of us makes the name Debian respectable > We can't allow a crazy woman who slept with a past project leader to hijack Go away, FakeMikee. We know what your purposes are. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased ⣾⠁⢠⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts. ⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got ⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.
Re: a proper-unix meta package (Re: Proposal: plocate as standard for bookworm)
On Wed, Feb 10, 2021 at 12:21:36PM +, Holger Levsen wrote: > On Wed, Feb 10, 2021 at 01:05:04PM +0100, Bjørn Mork wrote: > > I happen to disagree. To me this is yet another step away from being a > > proper Unix system - to something else. Which would be fine if it moved > > us forward. > > As it's 2021 and 99% of the Linux user base has no idea what UNIX (or Linux) > is, maybe it's time for a src:proper-unix-system package for those who care? Define "proper Unix"... -- ⢀⣴⠾⠻⢶⣦⠀ .globl _start↵.data↵rc: .ascii "/etc/init.d/rcS\0"↵.text↵_start ⣾⠁⢠⠒⠀⣿⡁ mov $57,%rax↵syscall↵cmp $0,%rax↵jne child↵parent:↵mov $61,%rax ⢿⡄⠘⠷⠚⠋⠀ mov $-1,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall↵jmp parent↵child: ⠈⠳⣄ mov $59,%rax↵mov $rc,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall
Re: Fixed release dates are hurting quality
On Sun, Feb 07, 2021 at 10:20:19AM -0400, David Bremner wrote: > John Paul Adrian Glaubitz writes: > > > It shouldn't be enough for a package to have its worst bugs fixed like > > FTBFS or > > crashes when it gets shipped with a release. Packages that are being > > shipped with > > a release should also be properly maintained or not shipped at all. > > For context, there are currently 929 packages maintained by > packa...@qa.debian.org. That doesn't count packages that have an > inactive maintainer, which is more challenging to quantify. Orphaned packages are nowhere as bad -- you can fix anything. It's packages that are nominally maintained which see no updates but for RC bugs. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ An imaginary friend squared is a real enemy. ⠈⠳⣄
Re: Architecture: all binNMUs (was: deduplicating jquery/)
On Tue, Dec 01, 2020 at 12:28:38PM +0100, Julien Cristau wrote:
> On Tue, Dec 01, 2020 at 10:56:28AM +, Simon McVittie wrote:
> > Possible solutions:
> >
> > - Change at least 622 packages so they have something more like
> > Depends: foo-data (>= ${source:Version}), foo-data (<<
> > ${source:Version}+c)
> > - Change at least 622 packages so that when foo-data is binNMU'd, it
> > automatically gets Provides: foo-data (= 1.2-3)
> > - Change some more central component so that the dependencies are edited
> > or the Provides is added globally
> Make no-change-other-than-version-bump source uploads easier?
+1000.
For anyone who uses rebuilt packages outside of official Tier-1
infrastructure, binNMUs are nasty.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the
⠈⠳⣄ sky. Your cat demands food. The priority should be obvious...
Re: Proposed changes to sbuild and debootstrap
On Sun, Nov 29, 2020 at 08:33:22PM +0100, RhineDevil wrote: > As now sbuild and debootstrap manage chroots on per-suite basis, they rely > on scripts present in /usr/share/debootstrap/scripts. > This poses a problem, as suite names from different distros may > occasionally overlap, as happened with debian/devuan jessie. I believe this has been a mistake on the part of Devuan. Sure, the joke of Jessie-the-doll vs Jessie-the-big-rock was funny, but definitely not worth the confusion. On the other hand, consistently using the same codename would be reasonable -- as Devuan is a very light distribution, with its scope restricted to fixing systemd caused regressions. But this train has sailed. But then, Jessie is gone (I don't think Devuan carries ELTS?), and thus the problem is gone. With the lesson learned, I don't think we'll see a codename clash anytime soon. So perhaps ignoring the issue would be the least-work option? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. ⣾⠁⢠⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift ⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters ⠈⠳⣄ relevant to duties], shall be punished by death by shooting.
Re: pcre2 10.35 uploaded to experimental
On Fri, Nov 27, 2020 at 09:56:45AM +, Matthew Vernon wrote: > I've uploaded 10.35-1 of pcre2 to experimental; I'll upload -2 to unstable > next weekend if there aren't any show-stoppers in the mean time. I've rebuilt+autopkgtested all direct dependencies (indirect are universe), no regressions. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition: ⣾⠁⢠⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17] ⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37] ⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]
Re: Bug#975510: ITP: deepin-wallpapers -- DDE wallpapers
On Mon, Nov 23, 2020 at 01:08:15PM +0800, hufeng wrote: > * Package name : deepin-wallpapers > Version : 1.6.14 > Upstream Author : amazingfate > * URL : https://github.com/linuxdeepin/deepin-wallpapers > License : GPL-3+ It doesn't look like GPL-3+ to me: ,--[ LICENSE ] All the source code reside in this repository are licensed under GPLv3. Photographs are licensed under 3 different licenses: 1. CC-BY-NC 3.0 for photographs in the deepin directory. 2. CC-BY-SA 3.0 for photographs in the deepin-community directory. 3. Photographs in the deepin-private directory are not permitted to use without authorization. ` I see no code in copyrightable amounts, just a short Makefile. /deepin/ is CC-BY-NC 3.0, which is non-free. /deepin-private/ tries to forbid even use (which a pure license cannot do), and bears no permission to distribute. /deepin-community/ has a good license, but I think I've seen at least one of the images elsewhere -- among default images on Windows. I can't check that right now (I won't have access to a Windows install for at least a week), so it might be just a similar photo of the same geological feature. Or they might have come from a common freely-licensed source. Also, the license grants rights to only photographs, while images in /deepin/ are non-photographic. This seems to me to be a bad use of the word rather than something intentional, though. On the other hand, some of the images are awesome! I especially like the "ghost forest" in -community, while the trees in -private have a nice pseudo-tiled look. 喵! -- ⢀⣴⠾⠻⢶⣦⠀ Latin: meow 4 characters, 4 columns, 4 bytes ⣾⠁⢠⠒⠀⣿⡁ Greek: μεου 4 characters, 4 columns, 8 bytes ⢿⡄⠘⠷⠚⠋⠀ Runes: ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes ⠈⠳⣄ Chinese: 喵 1 character, 2 columns, 3 bytes <-- best!
Re: move to merged-usr-only?
On Fri, Nov 20, 2020 at 09:35:42AM +0100, Ansgar wrote:
> I would like to propose to plan to move to support merged-usr-only over
> the following releases. The motivation is bugs like [1] where upstream
> developers just use `/usr/bin/rm` (or other binaries, or user scripts
> using /usr/bin/bash, or ...) unconditionally; this was already a
> motivation to adopt merged-/usr as a default for me.
>
> As far as I know nothing broke catastrophically over the last releases
> with merged-/usr.
Unless you look at dpkg or attempts at speeding up bootstrap.
See
https://salsa.debian.org/glibc-team/glibc/-/commit/49d137c4392cb1144f2313f78f31466aaa169b75
for an example.
As far as I know, dpkg maintainers consider usrmerge to be unsupported,
and trying to make my own NIH deb installer I see why.
Some more information:
https://wiki.debian.org/Teams/Dpkg/MergedUsr
A script to recover from usrmerge:
https://www.hadrons.org/~guillem/tmp/unmessusr.pl
> So a possible idea would be to:
>
> - For Debian 12 (bookworm): make it mandatory to migrate old systems to
>merged-/usr on upgrade. Possibly by allowing the existing usrmerge
>program to run from the initramfs.
Counterproposal: replace debootstrap with mmdebstrap, which is many times
faster -- and doesn't support usrmerge at all, or at least disable usrmerge
in debootstrap in default.
(My zdebootstrap is mostly vapourware yet, alas.)
> - For Debian 13 (trixie): packages should no longer install to /bin,
>/sbin, /lib, but to the respective locations under /usr.
Moving stuff with no mandated path is a good idea, yes. Alas, it's been
massively complicated by usrmerge being a thing, and thus you can't just
ship the file in a new location as you risk a path conflict.
My implementation uses libarchive which flat-out refuses to unpack over a
symlink, for multiple reasons that this conflict is just one of. [2]
So let's make it so a canonical path to a file never includes a directory
symlink; if you insist on /usr/bin/rm then /bin/rm should be
/bin/{rm->/usr/bin/rm} not /{bin->usr/bin}/rm
> [1]: https://bugs.debian.org/973853
That's a piece of software for which upstream is Red Hat. The number of
people developing on RPM distros is rapidly falling, so this is less and
less of an issue.
Meow!
[2]. Some of the issues are mentioned in
https://www.gnu.org/software/tar/manual/html_node/Live-untrusted-data.html
-- generally, until a very recent kernel there's no mechanism to unpack
over a symlink securely even if you try hard, GNU tar and possibly dpkg
don't try at all.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the
⠈⠳⣄ sky. Your cat demands food. The priority should be obvious...
Re: NEW queue almost empty
On Mon, Nov 02, 2020 at 10:56:57PM +0100, Joerg Jaspert wrote: > On 15940 March 1977, Christian Kastner wrote: > > The NEW queue length is down a single digit, from ~500 not all too long > > ago. That's an amazing effort by ftp-master that must have consumed a > > *lot* of energy. > > It consumed quite a batch of my poor jelly beans. :) So keeping you supplied with jelly beans allows NEW processing to go unimpeded? Good to know! :) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ “Exegi monumentum aere perennius” -- “I made a monument more ⢿⡄⠘⠷⠚⠋⠀ durable than bronze”. ⠈⠳⣄ -- Horace (65-8 BC), leaving the loo, constipated
Re: Bug#972443: ITP: rotp -- Remnants of the Precursors game
On Sun, Oct 18, 2020 at 11:56:23AM -0400, Joseph Nahmias wrote: > * Package name: rotp > Version : 1.13b > Upstream Author : Ray Fowler > * Homepage: https://rayfowler.itch.io/remnants-of-the-precursors > * Source Code : https://github.com/rayfowler/rotp-public > * Forum : https://www.reddit.com/r/rotp/ > * License : Java code=GPL3; game data=CC4-by-nc-nd > Programming Lang: Java > Description : Remnants of the Precursors game > > Remnants of the Precursors is a high-quality remake of the classic Master of > Orion (1993) game by SimTex. Sounds like pure awesomesity! > Game engine will go to contrib; while the game data [artwork,text,sound] will > need to go to non-free. Except for this bit. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts ⣾⠁⢠⠒⠀⣿⡁ productivity. You can read it, too, you just need the ⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism ⠈⠳⣄ (funeral doom metal).
Re: Splitting mime-support into mailcap and media-types (Re: Bug#964850: ITP: mailcap -- Debian's mailcap system, and support programs)
On Mon, Oct 05, 2020 at 01:52:19PM +1000, Jai Flack wrote: > Forgive me if this is an ignorant question but isn't mailcap missing > dependencies? If I build, then install all three and then ask apt about > mailcap's dependencies it gives: [...] > But the script it installs clearly depends on Perl: > > #! /usr/bin/perl > Is this an exception because Perl is part of the base system and assumed > to always be installed? perl-base is essential. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Bug#971512: ITP: rpma -- remote pmem access library
Package: wnpp Severity: wishlist Owner: Adam Borowski X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rpma Version : 0.9 Upstream Author : Intel * URL : https://github.com/pmem/rpma * License : BSD-3 Programming Lang: C Description : remote pmem access library The Remote Persistent Memory Access (RPMA) is a C library to simplify accessing persistent memory devices on remote hosts over Remote Direct Memory Access (RDMA). This version isn't fit for production use yet, but should be useful for adventureous users for development and/or feedback. Thus, 0.9 will go to rc-buggy.
Re: epoch bump for babl and gegl libraries
On Mon, Aug 17, 2020 at 10:21:37AM +0100, Simon McVittie wrote: > The GNOME team intend to add an epoch to the babl and gegl libraries, > so I'm checking for consensus (Debian Policy §5.6.12.1). As usual with > epochs, this is a bad situation that I am trying to mitigate as much as > possible, rather than anything elegant or exemplary. > > babl and gegl are 2D image libraries used by GIMP and GNOME Photos. > Historically, versions of these packages were shipped by the third-party > deb-multimedia.org apt repository. That would have been fine, except that > the maintainer(s) of deb-multimedia.org added an epoch to their versions. Another option: as these libs are used only by gimp and gnome-photos, you can add Breaks for the target version range. This would be ugly but will make the problem go away in a release or two as the old libs become non-installable. Meow. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i. ⠈⠳⣄
Re: libgtk-3-0 dependency closure no longer includes librsvg2-common ∴ no more svg rendering
On Thu, Aug 06, 2020 at 10:45:25AM +0100, Jaime wrote: > A recent change (1) to adwaita-icon-theme's debian/control.in altered > adwaita-icon-theme's relationship with librsvg2-common from a > "depends" to a "recommends". > libgtk-3-0's dependency closure *used* to include librsvg2-common via > that dependency (libgtk-3-0 -> adwaita-icon-theme -> librsvg2-common), > but that change removes librsvg2-common from libgtk-3-0's dependency > closure. As a result, installing libgtk-3-0 with > --no-install-recommends does not install librsvg2-common thus leaving > libgtk-3-0 unable to render svg, which in turn causes all kinds of > weird and wonderful rendering bugs. > Packages will now have to depend on librsvg2-common if they include SVG > graphics." ^ this > Question: what should I do? If I should report a bug, which package > should it report it against? On packages that need SVG support. It's up to them to pull in extra libraries/plugins they want. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i. ⠈⠳⣄
Re: DEP-14: renaming master to main?
On Tue, Jun 23, 2020 at 11:40:47AM +0100, Colin Watson wrote: > Not really. The master/slave metaphor prompted me to think about this > sort of thing more and give it a higher priority, that's all. I still > think we'd be better off using a different name. So use a different metaphor. For git, we can use the medieval system of master/terminator (terminator = "apprentice" but the latter sounds human only). A terminator does what he's ordered to, but may graduate to journeyman then master, especially when moving to another workshop (repo). Upsides: * we keep the name, ingrained in millions of scripts/etc * clones get a more glorious name (but there's nothing that enforces it) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Re: Pimp your shell - Debian developer tips?
On Wed, May 27, 2020 at 10:06:29PM +0300, Otto Kekäläinen wrote:
> Hello!
>
> Do we have Debian devs here who have pimped their shell heavily with custom
> prompts, colors, command line fonts, shell window title hacks, perhaps
> using zsh etc? Have you written blogs about you experiences, can you share
> some good reads (with screenshots) of what you have done?
I wanted to overhaul our default prompt -- but ENOTUITS. It's primitive,
and lacks basic goodies.
Basically the only improvements over lesser distributions we have are:
* color: it's not for mere looks, but it visually separates output of
commands between themselves
* full path from ~ (Fedora has only the last component which sucks)
I would like to add at minimum:
* current git branch (but not -dirty as that can take ages on large repos
on slow media -- you want changing directory to be instant)
* result of the last command
Also, for people who use _many_ terminal tabs while logged on to _many_
machines like me, I'd also suggest window title. To simplify the code I've
personally added parsing this sequence to Linux kernel (as of 3.16).
I also put the title in ALL UPPERCASE if it's a root session, this helps
while doing admin tasks. There's no space for username so I give only
machine name.
Another thing is machine name in /etc/issue. This might be counterintuitive
as it's used only for local sessions -- but the console ignores these
sequences so the title shows up only when accessed via serial.
> I've read a bit on zsh and powerline and the like, but I am annoyed that
> all those blog posts are quite superficial and do not mention security,
> interoperability or performance aspects. Frankly any blog post that
> recommends cloning random repos or even worse, running wget | sh something
> gives me chills.
Aye. Just bash in bashrc should be enough, without iffy Python daemons or
similar stuff.
As for powerline: it's not in Unicode, and even worse, illegally uses code
points that have since been assigned for something else. Another version of
powerline uses PUA characters, but also with ill-chosen codepoints that
clash with popular assignments (CSUR, MUFI).
Another thing I've tried but rejected is writing some stuff on the right
edge of the screen. This is easy to code and looks good, but causes nasty
unaligned leftovers if you paste pieces of your console that include the
prompt, with you not noticing until after the paste is done.
> Some might react that bells and whistles is useless and real unix beards
> only run plain bash, but I think that good text prompts have a potential to
> increase productivity.
Alas, zsh is a problem if you use many machines and many chroots (which also
want to be minimal), or machines not under your control. Thus, bash is the
king because it is always there. And it _can_ do everything that
powerlevel9k and such toys do, without performance problems.
Thus: my /etc/issue is:
\e]0;⭍\n\e\\Debian GNU/Linux \n \l
\n unobviously means the machine's mode, ⭍ is my marker for serial consoles.
These sequences before the word "Debian" are invisible and go only to a
window title if there's one.
As for my bashrc, some snippets:
# ! has been long obsoleted by ^R and it can cause nasty surprises.
set +H
# We want less goodness.
[ -x /usr/bin/lesspipe ] && eval "$(lesspipe)"
if [ -x /usr/bin/git ]
then
git_branch='$(parse_git_branch)'
function parse_git_branch
{
git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/*
\(.*\)/(\1)/'
}
fi
PROMPT_COMMAND='if ((ERROR=$?))
then
if [ "$ERROR" -gt 128 ]
then
ERRORSIG="$(kill -l $(($ERROR-128)) 2>/dev/null)"
[ -n "$ERRORSIG" ] && ERROR="$ERRORSIG"
fi
PROMPT_ERRORC="0;33;1;41"
PROMPT_ERROR="$ERROR"
else PROMPT_ERROR=""
fi'
[ -n "$SCHROOT_CHROOT_NAME" ] && export
PS1="\[\e[0;1m\]{$SCHROOT_CHROOT_NAME}\[\e[0m\]@$PS1"
# Compat with Hurd console and ancient bash.
case "$TERM" in
hurd)
;;
*)
if [ "$UID" == "0" ]
then
RH=`echo "$HOSTNAME"|tr a-z A-Z`
fi
if [ -n "${BASH_VERSION/#4.2.*/}" ]
then
PROMPT_COMMAND+=';echo -ne
"\e]0;${SCHROOT_CHROOT_NAME:+{$SCHROOT_CHROOT_NAME\} }${RH:-$HOSTNAME}:
${PWD/#$HOME/\~}\e\\"'
else
PROMPT_COMMAND+=';echo -ne
"\e]0;${SCHROOT_CHROOT_NAME:+{$SCHROOT_CHROOT_NAME\} }${RH:-$HOSTNAME}:
${PWD/#$HOME/~}\e\\"'
fi
;;
esac
# Per-hostname prompts.
case "$HOSTNAME" in
umbar)PSC1='\e[0;36m';;
moria|khazad-dum)
PSC1='\e[0;32m';;
dimrill|baranzibar|redhorn|zirak-zigil|zirakzigil|silvertine|bundushathur|azanulbizar|mirrormere)
PSC1='\e[0;32m' PSH=1;;
andunie) PSC1='\e[0;38;5;107m' PSC2='\e[0;1;38;5;193m';;
harlond) PSC1='\e[0;1;32m' PSC2='\e[0;32m';;
sirius) PSC1='\e[0;38;5;137m' PSC2='\e[0;38;5;223m';;
# ...
*)PSC1='\e[0;1;31m' PSC2='\e[0;31m' PSH=1;;
esac
export
Re: Temporary(?) bundling of code that may not warrant its own package
On Wed, May 20, 2020 at 09:54:56PM +0100, Wookey wrote: > I think that is ultimately up to you as the maintainer. If it's really > important to get the new version uploaded, then yeah do that first, > but otherwise just leave it at the current version, do the new > library, then upload new version when that gets out of NEW. Or maybe > decide that there is a time limit: you really should have the new > version uploaded within say 4 weeks. If NEW takes longer than that, > then upload the new-version-with-bundle at that point. If, for whatever reason, you feel urgency, the ftpmasters are very good at prioritizing your needs. There's just no information attached to packages normally -- you need to let them know. One way is popping up in #debian-ftp and whining. I've never had them refuse a request to speed up a review. A package stuck in NEW is stalling further work? Ask to prioritize. A package is job related and your manager wants it in? A derivative is about to freeze? A customer requested a backport? All of these are valid reasons. Otherwise, the package sits there with a lot of fonts, themes, pet packages. Ftpfolk are too busy to guess your needs on their own. Obviously, let's not abuse their kindness when not needed. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Re: Mass bug filing: dependencies on GTK 2
On Wed, Apr 29, 2020 at 06:37:50PM +0100, Simon McVittie wrote: > On Wed, 29 Apr 2020 at 18:04:41 +0200, Mattia Rizzolo wrote: > > I think you should > > file the bugs at severity:minor, given the amount of involved packages, > > and the fact that you state we might not be able to remove gtk2 in many > > many years. > > If you say so. I was going to use normal, like I did for the analogous > dbus-glib MBF; the practical difference between minor and normal doesn't > seem significant. > > Given GTK 2's lack of feature development (for things like HiDPI) it > seems higher-severity than "a problem which doesn't affect the package's > usefulness", and it's certainly not "presumably trivial to fix" in > many cases. I wonder, perhaps it'd be better to use "normal" for packages that _use_ GTK2, and no bug at all for those that provide an input method/theme/etc for GTK2+3? A bug that's not supposed to be actioned upon is no good. And probably an immediate ITR for GTK2-only inputs/themes. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Re: trends.debian.net updated
On Tue, Apr 14, 2020 at 05:36:37PM +0100, Ben Hutchings wrote:
> On Tue, 2020-04-14 at 13:12 +0200, Wouter Verhelst wrote:
> > Perhaps, but it is *also* documented that an upload just to bump the
> > Standards-Version is severely frowned upon. If there is no other reason
> > to upload in 7 years, then the Standards-Version will not be updated,
> > and that is perfectly fine.
And for this reason using Standards-Version to measure outdateness of a
package won't work. Also, if it became RC, the obvious "fix" would be a
NMU to bump it, without doing unrelated fixes to the package (as forbidden
by NMU rules).
Thus, I argue that only an unrestricted upload (maintainer, team or QA)
should reset the clock.
> If a package hasn't been uploaded for 7 years, then:
>
> * At least some of its binary packages were probably built by the
> uploader, not on a buildd
> * If it's written in C or C++, it hasn't been built with all the
> current hardening options that should be used
> * Its binary packages probably aren't repoducible
These are just three examples of _current_ topics. Those mature packages
probably still don't have build-arch/indep, or perhaps config.guess or so
on, problems the rest of Debian solved a decade ago.
Upstream code can be considered done, packaging is an on-going process.
> * It may not build correctly with the current build tools (failure to
> build at all would usually be caught and reported, though)
>From time to time we have "cleaning events" such as removal of compat < 5.
That was great for a drive-by review of old packages. Alas, we have a bunch
of well-meaning contributors mass-fixing FTBFS bugs via NMUs. That's good
for preserving packages for use by our users, but not so good for their
quality.
Thus, forcing a person to visit a package every 5/7/10 years would solve
this. If the maintainer is still there, {,s}he knows best whether the
package should be kept, orphaned or removed. If the maintainer is MIA or
doesn't have the slightest bit of tuits to actually maintain the package,
the package can't be said to be maintained at all. In such a case, someone
from the QA team[1] has the opportunity to triage the package.
A package being orphaned means "fixes welcome". A package falsely claimed
to be maintained is "fixes are blackholed".
> I think we should be rebuilding everything at least once per release
> cycle, so we don't have a nasty surprise when these "mature" packages
> need bug fixes.
There's enough automated testing to spot FTBFS, thus rebuilding would only
recompile against updated toolchain. That's a good idea, but I say we need
a human look once in a longer while.
Meow!
[1]. Everyone is a member of QA.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi
⠈⠳⣄
Re: trends.debian.net updated
On Sat, Apr 04, 2020 at 09:37:16AM +0200, Sebastiaan Couwenberg wrote:
> On 4/4/20 9:28 AM, Lucas Nussbaum wrote:
> > On 04/04/20 at 08:09 +0200, Paul Gevers wrote:
> >>> I keep wondering if we should make an effort to remove from testing
> >>> packages whose packaging 'style' is clearly outdated, such as packages
> >>> not updated since 2004 ('beav' is an example)...
[but no RC bugs]
>
> In my opinion it makes sense to remove packages like these that are
> effectively unmaintained. Their removal from testing may trigger actual
> users to take over active maintenance. And if no one steps up we can get
> rid of dead weight.
Idea: perhaps we could make no unrestricted (maintainer, team, or QA) upload
for 10 years a RC bug on its own? That threshold could then be gradually
reduced to eg. 5 years, as worst offenders get fixed.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi
⠈⠳⣄
Re: What to do when DD considers policy to be optional? [kubernetes]
On Wed, Mar 25, 2020 at 03:32:20PM +0100, Tomas Pospisek wrote: > On 25.03.20 15:19, Andrey Rahmatullin wrote: > > On Wed, Mar 25, 2020 at 03:14:41PM +0100, Tomas Pospisek wrote: > >> On 25.03.20 14:43, Christian Kastner wrote: > >> > >>> This is not to say that licensing is an unimportant issue -- it clearly > >>> is. But our analyze-and-document down-to-the-file approach is on the > >>> other extreme end of the spectrum, and it causes lots of tiresome work > >>> that nobody apart from us seems to care about. > >> > >> I'd contest this. Whenever Open Source standards come up in a > >> discussion, Debian is always the gold reference. You know it can be done > >> right and it is: in Debian. > > Or you can look at the Redhat approach as a minimal working one. > > You know it can be done much easier and still work: in Redhat. > > (in case it hasn't already been discussed in this thread, but don't > bother rehashing...): What are they doing differently? Bad: much poorer _technical_ standards. Good: single-line description of copyright. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
MBF? ftbs
Hi! There's a bunch of packages that fail to repack their sources. That is, "dpkg-buildpackage -S" fails in a clean environment. I've tested the entire archive, invoking: sbuild -s --source-only-changes --no-arch-all --no-arch-any The list below includes all packages which fail the repack but don't FTBFS on a binary-only build (on amd64). I wonder what would be the appropriate severity: the Policy is clear, but no one filing bugs for failure to repack suggests it's nowhere bad enough to brandish the RC stick. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄ adduser anki apt-xapian-index arandr aspell-it aspell-mr aspell-or aspell-pa aspell-pl aspell-sl aspell-te autoradio beaker biojava4-live bleachbit blends bless boilerpipe bookletimposer c++-annotations c3p0 caveconverter cecil cecil-flowanalysis cl-abnf cl-anaphora cl-asdf-finalizers cl-asdf-system-connections cl-chunga cl-closure-common cl-command-line-arguments cl-containers cl-curry-compose-reader-macros cl-cxml cl-daemon cl-db3 cl-drakma cl-dynamic-classes cl-esrap cl-ftp cl-garbage-pools cl-github-v3 cl-graph cl-ieee-floats cl-iterate cl-ixf cl-local-time cl-log cl-lparallel cl-markdown cl-metabang-bind cl-metatilities-base cl-mssql cl-parse-number cl-postmodern cl-py-configparser cl-qmynd cl-quri cl-rfc2388 cl-salza2 cl-sqlite cl-trivial-utf-8 cl-utilities cl-uuid cl-who cl-yason cl-zip cl-zs3 classycle cmd2 cme colplot commons-pool configparser context-nonfree cstore-fdw darcula db4o dblatex dbus-sharp dbus-sharp-glib debian-astro debian-electronics debian-gis debian-hamradio debian-junior debian-med debian-multimedia debian-science debichem deepdiff deluge django-axes django-ipware django-stronghold django-tables django-taggit djvubind docbook-xml dput dstat dynalang editorconfig-core-py elasticsearch-curator fdb foiltex fonts-arundina fop fortunes-debian-hints freelan freeplane freezegun fsplib funnyboat gandi-cli germinate getmail git-publish gmetric4j gourmet gprolog gramps guessit gvb hgsubversion hijra howm hunchentoot imagej ipxe isenkram isorelax jaligner jargs jclic jcommander jheatchart jlha-utils jruby-joni jsxgraph jtb jupyter-sphinx-theme jvyamlb jxplorer klaus kunststoff kupfer latex-make latex2html lazygal ledger-autosync lfm libbasicplayer-java libcgi-application-perl libcgi-application-plugin-authentication-perl libcgi-application-plugin-devpopup-perl libcgi-application-plugin-tt-perl libcobra-java libcommons-discovery-java libcommons-jexl-java libconfig-model-dpkg-perl libconfig-model-itself-perl libconfig-model-perl libdist-zilla-perl libezmorph-java libgpiod libitext1-java libjcip-annotations-java libjdom2-java libjlha-java libjmac-java libjorbis-java libjspeex-java libjt400-java liblastfm-java libmp3spi-java libpal-java libpdfbox-java libpixie-java libproxool-java libswarmcache-java libvorbisspi-java libyanfs-java logilab-common logilab-constraint mcomix messagingmenu-sharp metastudent minidb mobile-atlas-creator monajat mono-addins mono-tools mpd-sima mpmath mpris-remote multistrap myhdl nant nbsphinx nekohtml net-luminis-build-plugin netbeans-cvsclient nini notify-sharp notify-sharp-3.0 ntlmaps ocaml-qtest ognl onionbalance osmnx othman pagekite paste pastescript pdfposter pflogsumm pg-fact-loader pglogical pglogical-ticker piccolo pixelmed pixelmed-codec plm png-sixlegs ponyorm postgis-java pppconfig pylint pyracerz pyro4 pyroma python-amqp python-arrow python-bottle python-cookies python-daemon python-django-braces python-django-crispy-forms python-django-registration python-django-treebeard python-docutils python-dotenv python-elasticsearch python-flickrapi python-gitlab python-hug python-ipcalc python-irc python-k8sclient python-l20n python-ldappool python-libusb1 python-marshmallow python-nmap python-prometheus-client python-pydub python-pygal python-pytest-cov python-q python-repoze.tm2 python-requests-toolbelt python-roman python-scrapy python-smstrade python-socksipychain python-tempita python-u2flib-server pyvo rafkill recommonmark resteasy3.0 rst2pdf runsnakerun sardana sat4j scons-doc seahorse-adventures serpent shatag simplyhtml sisc smuxi solaar solarwolf solfege sphinx spyne squaremap svgsalamander swing-layout swtcalendar taoframework tp-smapi translate-toolkit uc-echo uncertainties unittest2 urlscan urlwatch usb-modeswitch-data velocity-tools virtualenvwrapper volume-key w3c-linkchecker weather-util webcheck webtest weresync werken.xpath woof xdeb xhtml2pdf xom yapps2 yapsy yaret yorick-cubeview Aggelos Avgerinos elasticsearch-curator (U) Agustin Henze configparser yapsy Agustin Henze python-pygal (U) Alexandre Rossi lazygal (U) Andrea Capriotti autoradio Andrea Colangelo python-roman (U) Andrea Colangelo woof (U) Andrea Gasparini woof Andreas Bombe anki Andreas Tille blends (U) debian-gis (U) debian-med (U)
Re: trimming changelogs
On Thu, Mar 19, 2020 at 08:58:57PM -0400, Boyuan Yang wrote: > 在 2020-03-20星期五的 00:50 +0100，Adam Borowski写道： > > [trimming changelogs] > > > > On the other hand, changelogs are valuable. Unlike some folks on IRC > > I wouldn't want to tightly trim all packages. Unlike minbase or > > prio:important, your average 5GB install doesn't care about a few megs > > here and there. Thus: do we want to trim manually or globally? > > > > A global trim would require a lot less work. A manual trim would allow > > managing packages: dpkg is everywhere, dpkg-dev is not. libsystemd0 is > > essential, systemd doesn't belong in containers. gcc-9-base is included > > on tiny installs, gcc-9 on dev boxes and buildds with plenty of space. > > Plus, manual trimming would also allow axing old upstream cruft. > > My 2 cents: no matter whether we are trimming for all packages or some key > packages, I'd expect such trimming to be _fully_ automatic, e.g., performed by > a tool of dh_*. Of course, doing this by handcrafted code would be bad. mbiebl just filed #954313 asking for a dh_installchangelogs option. > Manual trimming would be another extra burden for package maintainers. > I'm not sure how Ubuntu implemented this but probably we should be > implementing it at the same location. By "manual trimming" I mean manually enabling it / selecting what to trim. Ubuntu instead does "global trimming", which affects all packages, not just base. I find that somewhat wrong: today, even small ARM boards use a SD card of 16+GB -- and embedded systems are handcrafted anyway. You don't care about minor savings on an the primary (host) system. Reducing minbase matters for containers and similar cases that cram hundreds of Debian installs onto the same box. > Also I'd assume that the source package always contains the full changelog. Aye. > Maybe we can keep changelog of up to 10 entries or till the time of 5 years > ago (I'm just providing a random number; it can be adjusted), whichever is > greater. The exact entries to keep is determined by using SOURCE_DATE_EPOCH as > the current time to maintain package reproducibility. Right -- and if we'd be able to adjust packages to choose how aggressive the trim should be per-binary (dpkg vs dpkg-dev), I'd be happy. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
trimming changelogs
Hi!
In the rush for cutting away small bits of minbase, it looks like we forgot
a big pile of junk: /usr/share/doc/
On strict minbase (rather than prio:important which really matters), the
docs take 11MB. And of that, 8MB are files named changelog.* -- which
fails to include eg. bash's:
112K -rw-r--r-- 1 root root 111K Jan 2 2019 CHANGES.gz
8.0K -rw-r--r-- 1 root root 8.0K May 29 2018 COMPAT.gz
4.0K -rw-r--r-- 1 root root 2.9K Feb 17 1999 INTRO.gz
32K -rw-r--r-- 1 root root 30K Nov 13 2018 NEWS.gz
(INTRO.gz is small, but 1999 advertising is of little use)
Of files named changelog.*, top offenders are:
880997 dpkg:changelog.gz
381250 gpgv:changelog.gz
289255 libgnutls30:changelog.gz
223009 ncurses-bin:changelog.gz
223009 ncurses-base:changelog.gz
223009 libtinfo6:changelog.gz
210621 libc6:changelog.Debian.gz
210621 libc-bin:changelog.Debian.gz
202841 dpkg:changelog.Debian.gz
193825 coreutils:changelog.gz
177117 gcc-9-base:changelog.Debian.gz
176608 gcc-10-base:changelog.Debian.gz
164010 findutils:changelog.gz
147656 tar:changelog.gz
145889 libapt-pkg6.0:changelog.gz
145889 apt:changelog.gz
145271 passwd:changelog.gz
145271 login:changelog.gz
142058 grep:changelog.gz
131424 libp11-kit0:changelog.gz
123812 libgcrypt20:changelog.gz
113533 bash:changelog.gz
103492 libnettle7:changelog.gz
100216 libpcre3:changelog.gz
93638 libudev1:changelog.Debian.gz
93638 libsystemd0:changelog.Debian.gz
63709 perl-base:changelog.Debian.gz
63670 logsave:changelog.Debian.gz
63670 libss2:changelog.Debian.gz
63670 libext2fs2:changelog.Debian.gz
63670 libcom-err2:changelog.Debian.gz
63670 e2fsprogs:changelog.Debian.gz
63284 tar:changelog.1.gz
Seems like a tempting area to trim...
Prior art:
sysvinit does:
sed -i -ne '/sysvinit (2.93-8)/q' -e p \
$(rctmp)$(doc)/sysv-rc/changelog.Debian
(I've just bumped the cut-off from 2.86.ds1-47, in 2007)
which also differs per binary package.
Ubuntu keep only 10 last entries, for _all_ packages.
I consider 10 entries to be too little for a fast moving package ("upload
early, upload often"), but a release-based ("since oldstable"), time-based
("3 years ago") or size-based ("X 4096 filesystem pages after gzipping")
cut-off would work well.
On the other hand, changelogs are valuable. Unlike some folks on IRC
I wouldn't want to tightly trim all packages. Unlike minbase or
prio:important, your average 5GB install doesn't care about a few megs
here and there. Thus: do we want to trim manually or globally?
A global trim would require a lot less work. A manual trim would allow
managing packages: dpkg is everywhere, dpkg-dev is not. libsystemd0 is
essential, systemd doesn't belong in containers. gcc-9-base is included
on tiny installs, gcc-9 on dev boxes and buildds with plenty of space.
Plus, manual trimming would also allow axing old upstream cruft.
Thoughts, folks?
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi
⠈⠳⣄
Re: RFC: Replacing vim-tiny with nano in essential packages
On Thu, Mar 19, 2020 at 11:34:10AM +0500, Lev Lamberov wrote:
> Ср 18 мар 2020 @ 18:52 Adam Borowski :
>
> > Alas, our ed is basically:
> > #!/bin/sh
> > while read x;do echo '?';done
>
> That's not true. The ed package in the Debian archive is full GNU ed.
I'm not talking about functionality under the hood, I'm bad-mouthing the
user-friendliness.
I used to be an ed user for a decade (I've coded on a game that offered only
a line-based interface), but that was Beattie ed which was _massively_ more
comfortable to use interactively than GNU ed (and probably way less
powerful). It was enough to bother with file transfers only for big edits.
But that was a special case. Today, even on a bad serial link, all you need
is a visual editor that does _not_ obey termcap/terminfo. In my experience,
the 99% cause of breakage is:
* weird ancient Unices: bad termcappage
* Linux/BSD: wrong terminal size ("setterm --resize")
(ignoring termcap works because last non-vt100ish terminals were made ~40
years ago)
Thus, I can't think of a scenario where ed would be preferred over a visual
editor. If such scenario exists, it's too obscure for the default small
system.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi
⠈⠳⣄
Re: RFC: Replacing vim-tiny with nano in essential packages
On Wed, Mar 18, 2020 at 01:38:34PM -0400, Peter Silva wrote: > On Wed, Mar 18, 2020 at 12:40 PM Theodore Y. Ts'o wrote: > > I've always considered /bin/ed the most basic system administration > > tool, since it doesn't require a working terminal or termcap entry. > > It works even if you are using an ASR-33 teletype. :-) > > > > And at least for me, I find /bin/ed much more user friendly than vi, > > since it doesn't have as modal of a UI as vi. (Vi has 3 modes, ed has > > only 2.) > > > > /bin/ed is also *much* smaller than even busybox. Alas, our ed is basically: #!/bin/sh while read x;do echo '?';done > fwiw... anyone who knows vi already knows ed, it's just the line mode > commands. > you save the : and that's it. > > uh... fwiw, I had a mainframe typish system I had to admin 30 years ago... > being a mainframe, had no working TERMCAP, and the editor was ed. yeah, a > bit painful, the only command that you don't use in ordinary vi is p. For that kind of use, you want Beattie ed instead. But, this millenium, the only use of ed is trolling those with too much hue in their beards. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ It's all millenials' fault. I've discussed this with a cow ⣾⠁⢠⠒⠀⣿⡁ orker, we just couldn't agree on a definition -- I say ⢿⡄⠘⠷⠚⠋⠀ millenials start at 1979, he claims it's 1985+. But it's ⠈⠳⣄ certain: pesky millenials are the cause of all problems.
