Troubleshooting experimental build - how to replicate the sbuild?
Hi, I recently uploaded a package to experimental and was suprised at the build failures [1]. I have built it locally and on a porter box without issue -- each time using a clean unstable chroot. [1] https://buildd.debian.org/status/fetch.php? pkg=insighttoolkit5&arch=amd64&ver=5.4.3-2&stamp=1745014062&raw=0 I am trying to run sbuild in an attempt to reproduce the precise environment. I am using this invocation: sbuild --purge=successful --dist=experimental --build-dep-resolver=aspcud insighttoolkit5_5.4.3-2.dsc However, this also succeeds locally. So clearly I'm not reproducing exactly the buildd environment. I have asked both google and chatgpt but haven't yet been able to uncover exactly what options are used on the buildd. Anyone know how to find this? Comparing the logs, I can see a couple differences: Buildd uses sbuild 0.88.4~bpo12+2 whereas I have 0.89.0. Buildd sets Build Type: any, whereas mine is binary. Beyond that, there's a bunch of packages installed that I haven't waded through yet, but it's tough to believe package versions matter. Except perhaps for fftw, which contains the header where the error occurs. All fftw packages are the same version in both buildd and local. Any help appreciated, -Steve signature.asc Description: This is a digitally signed message part.
Results for Debian Project Leader 2025 Election
Greetings,
This message is an automated, unofficial publication of vote results.
Official results shall follow, sent in by the vote taker, namely
Debian Project Secretary
This email is just a convenience for the impatient.
I remain, gentle folks,
Your humble servant,
Devotee (on behalf of Debian Project Secretary)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Starting results calculation at Sun Apr 20 00:02:11 2025
Option 1 "Gianfranco Costamagna"
Option 2 "Julian Andres Klode"
Option 3 "Andreas Tille"
Option 4 "Sruthi Chandran"
Option 5 "None of the above"
In the following table, tally[row x][col y] represents the votes that
option x received over option y.
Option
1 2 3 4 5
=== === === === ===
Option 1 11066 179 273
Option 2181 78 211 264
Option 3282 261 278 318
Option 41279566 225
Option 5 708139 112
Looking at row 2, column 1, Julian Andres Klode
received 181 votes over Gianfranco Costamagna
Looking at row 1, column 2, Gianfranco Costamagna
received 110 votes over Julian Andres Klode.
Option 1 Reached quorum: 273 > 46.8854988242634
Option 2 Reached quorum: 264 > 46.8854988242634
Option 3 Reached quorum: 318 > 46.8854988242634
Option 4 Reached quorum: 225 > 46.8854988242634
Option 1 passes Majority. 3.900 (273/70) >= 1
Option 2 passes Majority. 3.259 (264/81) >= 1
Option 3 passes Majority. 8.154 (318/39) >= 1
Option 4 passes Majority. 2.009 (225/112) >= 1
Option 2 defeats Option 1 by ( 181 - 110) = 71 votes.
Option 3 defeats Option 1 by ( 282 - 66) = 216 votes.
Option 1 defeats Option 4 by ( 179 - 127) = 52 votes.
Option 1 defeats Option 5 by ( 273 - 70) = 203 votes.
Option 3 defeats Option 2 by ( 261 - 78) = 183 votes.
Option 2 defeats Option 4 by ( 211 - 95) = 116 votes.
Option 2 defeats Option 5 by ( 264 - 81) = 183 votes.
Option 3 defeats Option 4 by ( 278 - 66) = 212 votes.
Option 3 defeats Option 5 by ( 318 - 39) = 279 votes.
Option 4 defeats Option 5 by ( 225 - 112) = 113 votes.
The Schwartz Set contains:
Option 3 "Andreas Tille"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The winners are:
Option 3 "Andreas Tille"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
The voters have spoken, the bastards... --unknown
DEbian VOTe EnginE
digraph Results {
ranksep=0.25;
"Gianfranco Costamagna\n3.90" [ style="filled" , fontname="Helvetica",
fontsize=10 ];
"Gianfranco Costamagna\n3.90" -> "Sruthi Chandran\n2.01" [ label="52" ];
"Gianfranco Costamagna\n3.90" -> "None of the above" [ label="203" ];
"Julian Andres Klode\n3.26" [ style="filled" , fontname="Helvetica",
fontsize=10 ];
"Julian Andres Klode\n3.26" -> "Gianfranco Costamagna\n3.90" [ label="71" ];
"Julian Andres Klode\n3.26" -> "Sruthi Chandran\n2.01" [ label="116" ];
"Julian Andres Klode\n3.26" -> "None of the above" [ label="183" ];
"Andreas Tille\n8.15" [ style="filled" , color="powderblue", shape=egg,
fontcolor="NavyBlue", fontname="Helvetica", fontsize=10 ];
"Andreas Tille\n8.15" -> "Gianfranco Costamagna\n3.90" [ label="216" ];
"Andreas Tille\n8.15" -> "Julian Andres Klode\n3.26" [ label="183" ];
"Andreas Tille\n8.15" -> "Sruthi Chandran\n2.01" [ label="212" ];
"Andreas Tille\n8.15" -> "None of the above" [ label="279" ];
"Sruthi Chandran\n2.01" [ style="filled" , fontname="Helvetica", fontsize=10
];
"Sruthi Chandran\n2.01" -> "None of the above" [ label="113" ];
"None of the above" [ style="filled" , shape=diamond, fontcolor="Red",
fontname="Helvetica", fontsize=10 ];
}
pgpTWupUmuiSR.pgp
Description: PGP signature
Re: Troubleshooting experimental build - how to replicate the sbuild?
Hi Steven, Looks like the distribution is being picked up correctly, but you may be missing the aspcud criteria used by the buildd's, see the `--aspcud-criteria` option in [1]. Cheers! [1] https://wiki.debian.org/sbuild#Enabling_experimental
Re: Dropping awk?
Michael Stone wrote:
> Debian is a general purpose OS that can form the foundation for a lot
> of variants. But, that flexibility has a cost, and the cost is size &
> complexity. /var/lib/apt and /var/lib/dpkg alone are the size of a
> minimal linux distribution, without even accounting for actual
> executables. You can shrink the minimal set by making some components
> replaceable, but for a general purpose OS that implies the 60k
> update-alternatives program plus /etc/alternatives plus
> /var/lib/dpkg/alternatives--all to support reconfiguration that won't
> ever happen in a container image.
Omitting whole directories like /var/lib/dpkg and /var/lib/apt (for
finalized containers that will never get more packages installed atop
them), or /usr/share/{doc,info,man,locale} (for most containers) is
straightforward and easy, and any container optimizing for size starts
there.
And the extra symlinks in `/etc/alternatives` don't take much size; I
agree you don't need update-alternatives, but then, you also don't
strictly need the entire dpkg and apt packages, if you're already
omitting their files under /var/lib.
Omitting other packages is harder, and more error-prone. And that's the
area where `Essential` makes it much harder. If there were explicit
dependencies, it'd be a matter of carefully pruning the DAG, rather than
a matter of carefully manually checking what has an unststated
dependency on what.
Re: Dropping awk?
* Michael Stone [250419 15:47]: On Fri, Apr 18, 2025 at 10:17:12PM +0100, Jonathan Dowland wrote: They likely lack perl, as well. Most/all awk usage in maintainer scripts could probably be replaced with perl. But, if you are in the minimizing game, perhaps you'd rather remove perl from the essential set? A substantially harder project. If the goal is a minimal container image, why use debian at all vs a distribution optimized for that purpose? Running alpine without perl is already a solved problem... This is true for a lot of things Debian is used for. As an example: GNOME desktop users could also use Fedora, and the work of maintaining GNOME in Debian would be saved. People like to use Debian for a lot of different reasons. Very large and very small installs are "just" usecases too. When there are enough people interested (and so on...) in it, it will happen. Chris
Re: POSIX sh compatibility (Re: Dropping awk?)
Sean Whitton writes: > Hello, > > On Fri 18 Apr 2025 at 08:18am -04, Michael Stone wrote: > >> On Fri, Apr 18, 2025 at 02:52:17PM +0800, Sean Whitton wrote: >>>On Thu 17 Apr 2025 at 08:02pm -05, Richard Laager wrote: So, personally, I think getting mktemp(1) added to POSIX would be better for portability in the long run anyway. >>> >>>Eventually. POSIX.1-2017 is going to be the thing to target for a long >>>time, I think. >> >> I think POSIX is mostly a relic, and not worth worrying about except as one >> of >> many inputs. Too many mistakes were made too early on, and it's just too late >> to get everyone to agree on a common standard because real world >> implementations diverged in too many ways. If someone wants to make a program >> that works reliably across platforms sh isn't the right tool in 2025. (And I >> say that as someone who quotes POSIX regularly: it has value for things like >> choosing amongst a set of possible implementations, but not for making >> assumptions about what will work in the real world.) > > I have interpreted scripts that I want to run on any FreeBSD and Debian > machine, because they are part of my OS bootstrapping. What else is > there than POSIX sh for this? Therefore, it's still relevant. I think some reasonable subset of POSIX sh is all you can/should assume these days, everything else needs to be documented and installed as dependencies. Even (what used to be) common tools like awk, cmp, diff, join have disappeared from various distributions. Guix proved that a /bin/sh-only approach is possible and usable. I have mixed feelings about this minimization pattern -- it is often combined with replacing copyleft software with non-copyleft implementations (GPL -> LGPL/MIT) -- but I can't deny that I find minimal containers really useful. /Simon signature.asc Description: PGP signature
Re: POSIX sh compatibility (Re: Dropping awk?)
On Sat, Apr 19, 2025 at 08:05:54PM +0800, Sean Whitton wrote: I have interpreted scripts that I want to run on any FreeBSD and Debian machine, because they are part of my OS bootstrapping. What else is there than POSIX sh for this? Therefore, it's still relevant. With that requirement, what you really want to know is how to write a script that works on FreeBSD and Debian--which POSIX can't tell you. (Neither of those is POSIX certified or fully compliant.) POSIX might be a starting point, but you'll have to read man pages and figure out the discrepencies. If you're stuck doing that anyway, I seriously question the value of artificially limiting yourself to what unix tools did 30 or 40 years ago--newer tools or options often let you accomplish tasks much more efficiently. Maybe it would be worth avoiding those if POSIX really did let you write once and run anywhere...but it doesn't.
Re: Dropping awk?
On Fri, Apr 18, 2025 at 10:17:12PM +0100, Jonathan Dowland wrote: They likely lack perl, as well. Most/all awk usage in maintainer scripts could probably be replaced with perl. But, if you are in the minimizing game, perhaps you'd rather remove perl from the essential set? A substantially harder project. If the goal is a minimal container image, why use debian at all vs a distribution optimized for that purpose? Running alpine without perl is already a solved problem...
Re: Dropping awk?
On Sat, Apr 19, 2025 at 04:09:53PM +0200, Chris Hofstaedtler wrote: * Michael Stone [250419 15:47]: If the goal is a minimal container image, why use debian at all vs a distribution optimized for that purpose? Running alpine without perl is already a solved problem... This is true for a lot of things Debian is used for. As an example: GNOME desktop users could also use Fedora, and the work of maintaining GNOME in Debian would be saved. No, that's not the same at all. Debian is a general purpose OS that can form the foundation for a lot of variants. But, that flexibility has a cost, and the cost is size & complexity. /var/lib/apt and /var/lib/dpkg alone are the size of a minimal linux distribution, without even accounting for actual executables. You can shrink the minimal set by making some components replaceable, but for a general purpose OS that implies the 60k update-alternatives program plus /etc/alternatives plus /var/lib/dpkg/alternatives--all to support reconfiguration that won't ever happen in a container image. If size alone is the driving requirement, a general purpose OS like Debian (or Fedora, etc.) isn't the right starting point. You *can* build a really small container based on debian by starting with udebs and ditching package management/interactive configuration/etc. (Or, many debian container guides advocate a generous use of rm -rf to get rid of a lot of that stuff after the fact.) But in that context I don't see the relevance in talking about trimming stuff from a normal debian base install because the target isn't a normal debian base install.
Re: POSIX sh compatibility (Re: Dropping awk?)
On Sat, Apr 19, 2025 at 10:55:20PM +0800, Sean Whitton wrote: This just hasn't been my experience. You don't need perfect compatibility (or certification). By restricting myself to the POSIX specifications of sh, awk, find, grep and sed, I've profitably written several non-trivial programs that work correctly on any FreeBSD install and any Debian install that wasn't specifically engineered to be minimal. You happened to pick two of the most compatible OSs--it's not hard to be portable between linux & freebsd *by accident* as there's a long history of cross-pollination between them. (E.g., coreutils routinely looks to see what parameters freebsd used when implementing a new feature.) Expand the problem set to include running on SunOS and AIX and OSX and QNX and ... and the problem becomes much harder. But if you don't care about all those oddballs, why limit yourself to POSIX--whose point was to try to enable that degree of cross-platform interoperability? Stick to the intersection between linux + freebsd and you instantly get access to all kinds of wonderful modern things like mktemp without having to wait for POSIX to tell you it's ok. Conversely, if you expect POSIX from debian you're going to be disappointed now and then. E.g., POSIX gave up on trying to unify all the incompatible versions of tar/cpio and created a new standard archive utility named pax. Which works fine on many non-certified but POSIX-curious OSs like FreeBSD, OSX, OpenIndiana, etc etc, but you won't find it on a standard debian install. It's just one of those things where regardless of what standard you are writing to, you still need to check to see how reality matches the standard.
Re: Dropping awk?
On Apr 19, Michael Stone wrote: If the goal is a minimal container image, why use debian at all vs a distribution optimized for that purpose? Running alpine without perl is already a solved problem... Because I want to use a real libc, for a start. -- ciao, Marco signature.asc Description: PGP signature
Re: POSIX sh compatibility (Re: Dropping awk?)
Hello, On Fri 18 Apr 2025 at 08:18am -04, Michael Stone wrote: > On Fri, Apr 18, 2025 at 02:52:17PM +0800, Sean Whitton wrote: >>On Thu 17 Apr 2025 at 08:02pm -05, Richard Laager wrote: >>> So, personally, I think getting mktemp(1) added to POSIX would be >>> better for portability in the long run anyway. >> >>Eventually. POSIX.1-2017 is going to be the thing to target for a long >>time, I think. > > I think POSIX is mostly a relic, and not worth worrying about except as one of > many inputs. Too many mistakes were made too early on, and it's just too late > to get everyone to agree on a common standard because real world > implementations diverged in too many ways. If someone wants to make a program > that works reliably across platforms sh isn't the right tool in 2025. (And I > say that as someone who quotes POSIX regularly: it has value for things like > choosing amongst a set of possible implementations, but not for making > assumptions about what will work in the real world.) I have interpreted scripts that I want to run on any FreeBSD and Debian machine, because they are part of my OS bootstrapping. What else is there than POSIX sh for this? Therefore, it's still relevant. > I'm curious what modern platform doesn't have mktemp; is this more than an > academic question? I don't know. There are other things that you want awk for if you are doing pure POSIX sh scripting; mkstemp is just an example. -- Sean Whitton
Bug#1103616: ITP: sphinx-data-viewer -- Presents json and Python data in a list-like view in Sphinx
Package: wnpp Severity: wishlist Owner: Christian Bayle X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: sphinx-data-viewer Version : 0.1.5 Upstream Contact: https://github.com/useblocks/sphinx-data- viewer/graphs/contributors * URL : https://github.com/useblocks/sphinx-data-viewer * License : (MIT) Programming Lang: (Python, javascript) Description : Presents json and Python data in a list-like view in Sphinx Adds an interactive data viewer for data objects to Sphinx. Use it to document: JSON data JSON files Python objects Dependency for sphinx-needs
Re: Debian Project Leader election 2025: Last call for votes
On Fri, 18 Apr 2025 14:37:34 +0200 Debian Project Secretary - Kurt Roeckx wrote: > - - -=-=-=-=-=- Don't Delete Anything Between These Lines > =-=-=-=-=-=-=-=- 7066677e-e899-4143-af5e-710364fc2673 > [ ] Choice 1: Gianfranco Costamagna > [ ] Choice 2: Julian Andres Klode > [1] Choice 3: Andreas Tille > [ ] Choice 4: Sruthi Chandran > [2] Choice 5: None Of The Above > - - -=-=-=-=-=- Don't Delete Anything Between These Lines > =-=-=-=-=-=-=-=-
Bug#1103576: ITP: sphinx-needs -- Brings Engineering-as-Code to the Sphinx framework
Package: wnpp Severity: wishlist Owner: Christian Bayle X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: sphinx-needs Version : 5.1.0 Upstream Contact: https://github.com/useblocks/sphinx- needs/graphs/contributors * URL : https://github.com/useblocks/sphinx- needs/graphs/contributors * License : (MIT) Programming Lang: (Python, javascript) Description : Brings Engineering-as-Code to the Sphinx framework Combine Docs-as-Code with Application Lifecycle Management, to track requirements, specifications, test cases, and other engineering objects in your document It is a doxysphinx dependency, also used in AMD ROCm documentation will be maintained a part of the python team packages, with other sphinx tooling.
Bug#1103619: ITP: python3-test2ref -- This tool allows users to record and replay tests against known scenarios
Package: wnpp Severity: wishlist Owner: Mitchell Augustin X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python3-test2ref Version : 0.8.2 Upstream Contact: iccode17 * URL : https://github.com/nbiotcloud/test2ref * License : MIT/X Programming Lang: Python Description : This tool allows users to record and replay tests against known scenarios Dependency for testing against learned reference data. This package is relevant since it is a new dependency of python3-anytree. I plan to maintain it as part of the python team, and I do need a sponsor.
Re: Debian Project Leader election 2025: Last call for votes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 18 Apr 2025 14:37:34 +0200 Debian Project Secretary - Kurt Roeckx wrote: > > - - -=-=-=-=-=- Don't Delete Anything Between These Lines > =-=-=-=-=-=-=-=- 7066677e-e899-4143-af5e-710364fc2673 > [ ] Choice 1: Gianfranco Costamagna > [ ] Choice 2: Julian Andres Klode > [1] Choice 3: Andreas Tille > [ ] Choice 4: Sruthi Chandran > [2] Choice 5: None Of The Above > - - -=-=-=-=-=- Don't Delete Anything Between These Lines > =-=-=-=-=-=-=-=- -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEgdlr0Zo67jlv29MMA1mVlHlGcBgFAmgD52UACgkQA1mVlHlG cBiWbw/+NoEchOzHDyJ26IL5BqoKqp+IIy6Nba+RsrBpF+5ouLrvqCSP6SDjuteY Xzv68i81NUx4VReJVOFcf0TeDMeV0y3chbgAFhmmLyjPuDZGkF7DssMrzxxXw+zL g78/yeQABM0os6F1Vly3+xsFTX7e4z2vhBDOJvzMISkLOFVAAUBJSpdOsbQ84Ax6 2gKpSZh8AxZY0VyYnvp4c2473Vps46SDZBEqS0Xo3gTPKBbA7UHCRN6D3pUXrUgx cYGgzFV5x7dzv15umGbHNwj+ZKNgBhzbOn5WZ1zOQzpDZD+29cw5mTT3lQKeNJJJ UJnO4xo9B7sRDFuZmse7n3X7IzAvsj40i9ldSGuP+hTa5B7lwh2rF6eeKvOHYw8V /Se/v6wsqL0WVD+/5MUZ+Vsyi4e33CSNkjDyvoXQLYToUXk0ZNQ6OeG/t9Pu6css Xq8+0c05MDckB3M4Rx3zZ7Mx7wA4f4aVS4q/35PNc8gMAaIeArU7cH5cE9QHeQFK G+dRtqmdZAxdSP9lkngZYhBr/YqlR1hERUetVLZZgYsKTUnWC7alyQf6rd4N2KNU gG2J23Lau81AN+4FAmSqgAy0dYmjTs0Gr/3bPDEe+EVkyu6nEDihJIcFIWSOnhuW OSnTFS8K5+Bm+Wo7wQ2G4dKBxZM8q6+ZmM0jKxWSfWxGZMnd1/Y= =s7Ho -END PGP SIGNATURE-
Re: Debian Project Leader election 2025: Last call for votes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 18 Apr 2025 14:37:34 +0200 Debian Project Secretary - Kurt Roeckx wrote: > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > 7066677e-e899-4143-af5e-710364fc2673 > [ ] Choice 1: Gianfranco Costamagna > [ ] Choice 2: Julian Andres Klode > [1] Choice 3: Andreas Tille > [ ] Choice 4: Sruthi Chandran > [2] Choice 5: None Of The Above > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEgdlr0Zo67jlv29MMA1mVlHlGcBgFAmgD6sUACgkQA1mVlHlG cBi8tw//WjlbAwpRHouDg7nqyeCjL5M5Bpm+jN4l31ts4tsX0a0bTn+5zFsgzvYo y6emMzIW7JrSfx2jh6WtKU7rxJi9oz3BWLIsKX6oojyNitjJPd5EI2Btcb6tXDTm 3zjbG0AqlBU0/BaRBry8q/J2qsQCNZgrj7lGbMxpW1kZ8jA0sFRswA8x+g516mEd aKgudCwm687eKj2iDFHExQwmVCmj5FS7Ppxu3ovQ5ljxCgGFVxSbqHgJ4qn6dTVt 5AAVAcvfcCqYRg3vff8b/cE84g/NRq/5JV2HJeJwUpOAknHCDtvjOd/CUoGsi/F5 Fcd8L8H8HrBLHtNuD5nXpkUF0UdA5sCgBaQQUb3ZyfA88zkT2YGFaE+W/UoSGM5D 44mApN8xJL/EY/5QpVwOaanmVl83j8l0rY0dzSW81wLXBcdFDfeSFAg8VA4RWXbq d3WIsyFvjSTXxKXxyOPHx06ncp9mqkNerikh6laUHcxc6+b4w9XU0UhzmoFWs8KP NEweF1qxp4Im0KbV7TwfRUeklBFe2qEfIES/iLusSssV/O0CBiccZXYL0kCRanms aGLd7iYGzg2b6C1PAQ2VaWjVOrCAwn1D/79Dsw+KQBvWUbFbjgwaw0T41FGmck5E jz8oIpJ2KHvEzTHuw/Qc4iAVAzaLsFcDRrvRUzp5RmvMmVUfKEY= =nqTk -END PGP SIGNATURE-
Re: How to remove 19 raku-* packages from all ARM architectures ?
Hi On 18-04-2025 15:46, Dominique Dumont wrote: Should I log one bug for all 19 packages, or one bug per package ? I'm pretty sure ftp-master has workflows that desire one bug per package as I've seen that request often enough. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: How to remove 19 raku-* packages from all ARM architectures ?
On Fri, Apr 18, 2025 at 03:46:03PM +0200, Dominique Dumont wrote: > But I forgot that all raku-modules are Architecture: any, which means that > all > these module must also be removed from unstable/arm*. > > There are 19 packages to be removed from arm*. > > Should I log one bug for all 19 packages, or one bug per package ? The process requires one bug per package, ftp-master don't handle it nicely otherwise. But I recommend you just leverage control commands while filing, since ftp-master tools just parse the subject: To: sub...@bugs.debian.org Subject: RM: raku-foobar -- ROM; ANAIS Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: rm Control: clone -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11 -12 -13 -14 -15 -16 -17 -18 -19 Control: retitle -2 RM: raku-barfoo -- ROM; ANAIS Control: retitle -3 RM: raku-balba -- ROM; ANAIS Control: retitle -4 RM: raku-fufu -- ROM; ANAIS etc etc. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: How to remove 19 raku-* packages from all ARM architectures ?
On Saturday, 19 April 2025 18:23:06 Central European Summer Time Mattia Rizzolo wrote: > But I recommend you just leverage control commands while filing, since > ftp-master tools just parse the subject: Good idea ! Thanks both for the help
Re: POSIX sh compatibility (Re: Dropping awk?)
Hello, On Sat 19 Apr 2025 at 09:40am -04, Michael Stone wrote: > On Sat, Apr 19, 2025 at 08:05:54PM +0800, Sean Whitton wrote: >>I have interpreted scripts that I want to run on any FreeBSD and Debian >>machine, because they are part of my OS bootstrapping. What else is >>there than POSIX sh for this? Therefore, it's still relevant. > > With that requirement, what you really want to know is how to write a script > that works on FreeBSD and Debian--which POSIX can't tell you. (Neither of > those is POSIX certified or fully compliant.) POSIX might be a starting point, > but you'll have to read man pages and figure out the discrepencies. If you're > stuck doing that anyway, I seriously question the value of artificially > limiting yourself to what unix tools did 30 or 40 years ago--newer tools or > options often let you accomplish tasks much more efficiently. Maybe it would > be worth avoiding those if POSIX really did let you write once and run > anywhere...but it doesn't. This just hasn't been my experience. You don't need perfect compatibility (or certification). By restricting myself to the POSIX specifications of sh, awk, find, grep and sed, I've profitably written several non-trivial programs that work correctly on any FreeBSD install and any Debian install that wasn't specifically engineered to be minimal. -- Sean Whitton signature.asc Description: PGP signature
