)
MariaDB [(none)]> SELECT Host,User FROM mysql.user where password_expired='N';
+---+---+
| Host | User |
+---+---+
| localhost | root |
| localhost | mysql |
+---+---+
MariaDB [(none)]> SHOW WARNINGS;
Empty set (0.001 sec)
I followed
Hi!
We still have
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/61
open to potentially change the defaults, but I am hesitant to diverge
from upstream on this.
Seems
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/02f6ba571e930493c51b92b8c23e2e7fadcedbe0
on
I debugged
https://salsa.debian.org/debian/devscripts/-/commit/e6b8179080ee087b2a2f3c349b19c6f541335b3b
and in particular
https://salsa.debian.org/debian/devscripts/-/blob/main/scripts/debchange.pl#L317-359
today.
I can confirm that this works as intended:
dch --no-multimaint-merge --append
I am happy to review MRs if somebody has a suggested fix to this issue.
Status update:
There are some discussions in upstream mailing list / bug tracker
about potential performance regression. I will not rush to upload
MariaDB 10.11.12 this weekend, but wait for clarity on upstream issues
first.
Note related
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/90
that was done in an attempt to fix
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063738
Latest x32 build in
https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=x32&ver=1%3A11.8.1-2&stamp=1742533258&
> >* My tentative conclusion is that the mariadb-plugin-provider
> > compression packages have a very tight version dependency on the
> > server packages and that they should only be upgraded in concert
> > with the server packages, with matching versions.
>
> We could make plugi
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: mari...@packages.debian.org
Control: affects -1 + src:mariadb
I propose that the latest minor maintenance version of MariaDB be included in
the stable release update
Hoping to see a contribution stem out of
https://www.reddit.com/r/debian/comments/1kd6r3w/what_do_users_of_mariadb_in_debian_want_to_see_in/
where removing old conffiles was requested
See also related:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931314
gbp: Doesn't check if the vcs is current before importing
https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/439
Check for upstream tarball checksum mismatch
https://salsa.debian.org/debian/debcraft/-/issues/19
Can
Hi,
Thanks for reporting, I will check it.
Control: title -1 mariadbd: Server GSSAPI error, gss_acquire_cred failed
Thanks for reporting!
I would like to know if other people are experiencing this?
Can anyone provide a reproducible test case?
The error log shows MariaDB 11.8.1 starting and doing crash recovery.
This is an indication tha
Maybe the USR1 signal is from the test runner that kills the process after
it has been stuck for a long time.
I observed the first tests run quickly but then it grinds to a halt. But it
could just be because of hitting the bug that traps stops/crashes server
without returning control.
I didn't in
Hi,
Quick update to this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070845
The Godot 4 package was in the Debian NEW queue
(https://ftp-master.debian.org/new.html) since January and finally got
reviewed by FTP Masters for the first time yesterday.
Unfortunately they had some feedback ab
The test main.func_json_notembedded was re-enabled in
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/24719a9066bf7468550737bd0933d3cb9512c737
However, for sparc64 and hppa the build is now failing on other
reasons, so I am not closing this bug report just yet.
Also the main.func_js
Hi!
Yes, I tried the build on the porterbox and it is crashing, and
repeated runs seem to crash on the same tests, but not exactly every
time.
Completed: Failed 14/1131 tests, 98.76% were successful.
Failing test(s): main.bind_address_resolution
main.bind_multiple_addresses_resolution
main.log_sl
who wants to
contribute that change and do the required testing.
The optimal fix is probably to contribute to
https://salsa.debian.org/debian/libedit (maintainer Sylvestre CC'd)
- Otto
Thanks for the tips, I relayed suggestion about GCC Compile Farm to upstream.
Also I noticed that the sparc64 crashes are pretty random, happening
in different tests. Maybe the runner is unstable?
For example in
https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=sparc64&ver=1%3A11.8.1-4
Package: mariadb
Version: 1:11.8.1-1
Tags: ftbfs
X-Debbugs-CC: debian-sp...@lists.debian.org
User: debian-sp...@lists.debian.org
Usertags: sparc64
Forwarded: https://jira.mariadb.org/browse/MDEV-36670
**REQUESTING HELP FROM SPARC64 PORTERS IN DEBIAN**
In a build of MariaDB 11.8.1 on official Debi
This https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959159 seems as
a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850167
In both cases a `origin/pristine-tar` already exists but
git-buildpackage does not automatically use it, because a local
`pristine-tar` branch didn't exist
Thanks Sebastien for reporting!
For anyone else reading this, contributions are welcome!
https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/Contributing-to-MariaDB-packaging-in-Debian
Package: python-upstream-ontologist
Version: 0.2.2-2
I installed the latest version in sid in a clean container and tried
to run it, but it fails to load itself:
# apt install -y python3-upstream-ontologist
# guess-upstream-metadata --help
Traceback (most recent call last):
File "/usr/bin/guess
Forward: https://jira.mariadb.org/browse/MDEV-36652
Still visible as failing in
https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=sparc64&ver=1%3A11.4.5-2%7Eexp1&stamp=1740288400&raw=0
Forwarded: https://jira.mariadb.org/browse/MDEV-36652
Forwarded: https://jira.mariadb.org/browse/MDEV-34788
Control: retitle -1 mariadb: FTBFS multiple archs: Post-build tests
fail on reserved port
In
https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=amd64&ver=1%3A11.4.5-2%7Eexp1&stamp=1740281411&raw=0
these were passing:
main.bind_addres
This https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037327 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057708 are
partially duplicate.
We could potentially re-apply
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/5545bb341808cef8a4227b55b0c75e331cc48c96
that was revert
Hi!
Thanks for the patches!
If you think they are correct and universally should be in the
packaging, please submit a Merge Request:
https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/Contributing-to-MariaDB-packaging-in-Debian
Steps to reproduce the original issue would also be nice
Forwarded: https://github.com/MariaDB/server/pull/3873
This does not affect MariaDB 11.8.1 in unstable/Trixie, but it does
affect mariadb/1:10.11.11-0+deb12u1 in Bookworm, and will
automatically be fixed with next upstream release as upstream fixed
this.
Hi!
It is still unclear to me what the bug here was originally, and how to
reproduce it.
We could potentially re-apply
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/5545bb341808cef8a4227b55b0c75e331cc48c96
that was reverted in
https://salsa.debian.org/mariadb-team/mariadb-server/-
Hi!
I drafted now the MR for this myself at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/114
I won't merge it unless at least on other person contributes with
testing and review.
On Wed, 28 Jun 2023 at 05:17, Otto Kekäläinen wrote:
>
> Hi Marc!
>
b.com/aristocratos/btop/pull/715.
- Otto
On Thu, 2 Jan 2025 at 17:10, Marius gripsgard:
>
> Hi,
>
> I'm so sorry I have completely missed your other mails, I'm really sorry.
>
> Yes, to share the workload would be awesome :) I'll move it over to the
> debian project o
Hi!
This is already fixed at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/112
but upload pending another person to review/approve.
Thanks for the reply.
This means that in Salsa CI the Lintian job for Bookworm should run Lintian
from Bookworm, rather than the unstable version.
This is not the case now but with this clarification we will change it to
follow your stated maintenance principle.
Hi,
On a tanget to this bug: this package is maintained in Salsa, and the
original build failure is visible when CI runs in
https://salsa.debian.org/otto/mat2/-/pipelines/850962, and the fact
that the new change fixed the first issue but revealed another is
visible in https://salsa.debian.org
Hi Louis-Philippe!
Did you have a chance to think about what the maintenance policy is?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100539
Thanks for the clarification.
Indeed https://en.m.wikipedia.org/wiki/MIT_License#Ambiguity_and_variants
explains that FSF didn't like the name MIT and recommends Expat instead.
However, MIT is currently the most popular open source license in the world
and everyone else uses it by that name, inclu
Package: licenserecon
Version: 4.2
When running lrc on new package usql
(https://salsa.debian.org/go-team/packages/usql/-/merge_requests/1) I
got:
# lrc
: Versions: licenserecon '4.2' licensecheck '3.3.9-1'
Parsing Source Tree
Reading d/copyright
Running licensecheck
d/copyrig
Roger, so steps to reproduce:
apt update
apt install -y libcap2-bin
apt install -y mariadb-server
...
Setting up mariadb-server-core (1:10.11.11-0+deb12u1) ...
Invalid file '/usr/sbin/mysqld' for capability operation
Setcap failed on /usr/sbin/mysqld, required with --memlock if
insufficent RLIMIT_
Control: tags -1 +help
Hi!
I never saw a patch or MR about this, but I am happy to have one, even
if it is only 90% done and failing, if you still want to help optimize
the binary sizes.
Currently the examples you referenced are 10M+:
± ll ./builddir/storage/maria/aria_*
-rwxr-xr-x 1 otto otto
lready merged last month, if that's not already migrated into
> Debian:
> https://github.com/MariaDB/server/pull/3611
>
> On Fri, 2025-04-11 at 19:40 +0300, Otto Kekäläinen wrote:
> > If you report this upstream (or better, send them a Pull Request
> > with the change) an
Hi Sam!
If you report this upstream (or better, send them a Pull Request
with the change) and they accept it, we could backport that to Debian.
https://github.com/MariaDB/server/blob/main/support-files/mariadb.service.in#L109C1-L112C14:
```
# Restart crashed server only, on-failure would also re
Hi!
This was potentially fixed via
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/63
a year ago, but I'd like to see a confirmation on the bug report from
users that the fix was complete and confirmed to work well.
On Mon, 22 Jan 2024 at 09:33, Otto Kekäläinen
Hi!
Can you confirm if this issue is fixed with latest MariaDB versions in Debian?
If not, can you provide exact steps on how to reproduce the issue so I
can test it myself easily or add it into CI?
I don't see any progress in upstream https://jira.mariadb.org/browse/MDEV-35424
You might consider contributing directly upstream additional debugging
information, volunteer to do testing etc to advance this.
Hi,
Related: Bug#1084293
We need to figure out if something changed in tzdata(-legacy) transition
again. Seems MariaDB is working "correctly", environment just changed to
force new tz or something.
Hi Martin-Eric!
> I just tried performing the DEP14 migration as a DM and got:
>
> ---
> salsa protect_branch debian/xserver-xorg-video-geode master no
> Error DELETEing
> https://salsa.debian.org/api/v4/projects/91605/protected_branches/master
> (HTTP 403): Forbidden {"error":"insufficient_
Thanks for the details.
Seems regression was introduced in
https://github.com/mariadb-corporation/mariadb-connector-c/commit/1a2ed3f67af698b394b2faed069b49d4f409a155
and fixed in mainline, but not published by upstream yet.
Hi!
Thanks for reporting this. Can you please give more information? What
are these UDF_* args? Have you check in MariaDB documentation or code
base if they exist there, or ever did?
What are the steps to reproduce the issue you are experiencing in a
clean Debian unstable container?
Is this a re
Control: forwarded -1 https://jira.mariadb.org/browse/MDEV-35424
Thanks for reporting! This will hopefully be fixed in next upstream release.
Hi!
I don't know why, but for some reason this started affecting MariaDB
recently. Perhaps something related to the new MariaDB 11.8.1 itself,
or a some build tool updated in Debian unstable recently.
Details and workaround described in
https://salsa.debian.org/otto/mariadb-server/-/c
Based on
https://github.com/MariaDB/server/commit/2d971709a8b96ebd71c4a5d2ca74ee6f72ad0355
this was already in 11.8.1, and thus already fixed in Debian unstable.
Fixes for Bookworm and Bullseye are pending next upload.
Package: wnpp
Severity: wishlist
Owner: Otto Kekäläinen
* Package name: usql
Version : 0.19.19-1
Upstream Author : xo
* URL : https://github.com/xo/usql
* License : Expat
Programming Lang: Go
Description : Universal command-line interface for SQL
Control: tags -1 moreinfo
Hi!
We have extensive install/upgrade testing for MariaDB, see e.g.
https://salsa.debian.org/mariadb-team/mariadb-server/-/pipelines/824990
Can you reproduce the issue you saw in a clean environment, e.g. a
container or virtual machine?
If not, then you probably had so
Hi!
Thanks for reporting. This is a regression from
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/db57c0d8f20ebfe9f54f98941eabb1c774e696a3
The warning is just a warning and the installation/upgrade still
completes, right?
Seems upstream is aware of this issue and reworking this f
Package: lintian
Severity: wishlist
I am asking this question from Lintian maintainers in a bug to
formally record what the maintenance policy is.
Is Lintian maintained maintained in a backwards incompatible way?
Is the intent that the same Lintian version in unstable can at any
time be used to c
Thanks for the heads-up. None of these are visible on
https://mariadb.com/kb/en/security/ yet.
Hi!
> * Package name: bacon
>Version : 3.11.0
>Upstream Contact: dystroy
> * URL : https://dystroy.org/bacon/
> * License : AGPL-3.0
>Programming Lang: Rust
>Description : background code checker
>
> bacon is a code checker designed to run in th
Control: affects -1 mariadb-10.5, mariadb
Hi Patrick!
Thanks for reporting this!
According to https://jira.mariadb.org/browse/MDEV-36026 it applies to
all versions of MariaDB in Debian.
The regression does not seem serious enough for upstream to make an
emergency release. It is probably safest
Hi,
> Please go ahead, bearing in mind that the window for 12.10 closes next
> weekend.
Thanks! Upload is done
(https://tracker.debian.org/news/1623097/accepted-mariadb-110-0deb12u1-source-into-proposed-updates/)
but I don't see builds happening at
https://buildd.debian.org/status/package.php
Hi release team,
The MR https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/98
has been reviewed (thanks Sylvain) and I think it is ready to be
uploaded to stable-proposed-updates.
I've attached the output `git diff debian/1%10.11.9-0+deb12u1 --
debian > debian-1%10.11.9-0+deb12
Control: tags -1 -moreinfo
New version currently in review at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/98
mariadb (1:10.11.11-0+deb12u1) bookworm; urgency=medium
[ Otto Kekäläinen ]
* New upstream version 10.11.11. Includes fixes for several defects
as noted
Source: mariadb
Version: 1:11.4.5-1
Tags: upstream, confirmed, help, ftbfs
X-Debbugs-CC: debian-sp...@lists.debian.org
User: debian-sp...@lists.debian.org
Usertags: sparc64
Forwarded: https://jira.mariadb.org/browse/MDEV-36145
After latest upload to Debian unstable I noticed the post-build test
fa
Hi,
Thanks all for investigating this. Seems it is affecting a large
amount packages as use of 'adduser' is very common. This also breaks a
lot of Debian CI and Salsa CI. If it is not easy to figure out a fix,
please consider reverting to previous behavior as an alternative.
Pasting example of er
Control: retitle -1 bookworm-pu: package mariadb 1:10.11.11-0+deb12u1
Upstream 10.11.11 version is now out, so I will repurpose this for the
preparation of 1:10.11.11-0+deb12u1, currently in progress at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/98
Package: libcap2
While reviewing libcap2 I noticed that the upstream signatures are missing from
Also imports fail:
± gbp import-orig --uscan --upstream-version=2.73
gbp:info: Launching uscan...
gpgv: Signature made su 1. joulukuuta 2024 20.24.50 PST
gpgv:using RSA key 38A644698
Thanks Christian for fixing this quickly!
This may help to prevent similar issues in the future:
https://salsa.debian.org/debian/libcap2/-/merge_requests/2
Hi,
This broke the installation of numerous packages in Debian, hopefully
you can prioritize fixing it today.
Thanks,
Otto
Forwarded: https://jira.mariadb.org/browse/MDEV-36078
Thanks Matthew for discovering this. I submitted this now upstream as
we need to coordinate with upstream how to avoid behavior change in
MariaDB 11.4 series.
Package: adequate
Version: 0.17.5
Severity: wishlist
To allow Adequate errors to be QA blockers in the future, it would be
good if there was a mechanism to override some checks, similar to
Lintian overrides. Otherwise people might be tempted to turn off
Adequate completely.
A scheme that mimics L
Package: debmutate
Version: 0.71
Severity: important
Tags: python3.13
The python3-debmutate package fails to handle UTF-8 encoded files when
running under Python 3.13. This affects multiple Debian packaging
tools including lintian-brush, making it impossible to process
packages containing non-ASCI
Hi!
I am currently reviewing
https://salsa.debian.org/go-team/packages/ntfy and the dependency
https://salsa.debian.org/go-team/packages/golang-github-olebedev-when
that is being packaged for nfty.
My first request is to have the package build and pass Lintian in CI
so we get into a good habit of
Actually, the 'when' library was already uploaded to NEW:
https://ftp-master.debian.org/new/golang-github-olebedev-when_1.1.0-1.html
I think there are indeed two things to consider here:
The first is the choice of compiler, and whether or not any recent
clang will do. It would be easier if CMake can just find the installed
clang - then we don't need any custom config scripts for it to work.
The second is the location of the co
Santiago RR is actually working on running sbuild inside containers in
Salsa CI, so the build envs will be cleaner soon.
I've tested building the 11.3.1-1 sources on a clean container with
tzdata 2024b-5, and then immediately with 2025a-1, and both passed
without errors with default timezone 'Etc/UTC'. Changing timezone to
Berlin like the reproducible builds has didn't change the outcome.
$ dpkg -l | grep tzdata
ii
Package: libamdhip64-dev
Version: 5.7.1-5
Severity: normal
Dear Maintainer,
I'm trying to use HIP from CMake, using the packages available in
Trixie. I'm running into an issue where CMake is unable to find
hip-lang-config.cmake.
The code I'm trying to build does an enable_language(HIP), which fa
On a second thought, Ubuntu Plucky differences are probably due to
their tzdata having a lot of modifications and maybe not yet the
tzdata-legacy split:
https://patches.ubuntu.com/t/tzdata/tzdata_2024b-6ubuntu1.patch
> > You might want to ensure (as maintainer of Salsa CI) that such thing
> > does not happen (or, at the very minimum, document the differences
> > between a completely clean chroot and the one used by Salsa CI).
>
> Simple question: Does it help if I open an issue in Salsa CI for that?
Thanks San
Nobuhiro, would you like to approve
https://salsa.debian.org/go-team/packages/golang-github-caarlos0-env/-/merge_requests/1?
Tracker https://tracker.debian.org/pkg/golang-github-caarlos0-env
currently says package is marked for autoremoval on Feb 13th.
Thanks for report! I can fix this later today
Nice, glad to see you are taking on more packages!
Just out of curiosity, what are you using it for?
A large part of the FOSS community has moved to Podman instead of
Oracle affiliated Docker. Have you checked if a Podman BuildKit plugin
could do the same?
Hi!
Sorry for the long delay, I didn't have time to import new RocksDB
until yesterday and today. I have now a MR pending at
https://salsa.debian.org/debian/rocksdb/-/merge_requests/9 for
co-maintainer review and will upload to unstable hopefully soon, with
high likelihood that this fixes #1088523
Hi!
This https://salsa.debian.org/penguin359/pwru/-/commits/debian/latest
looks good!
Your repo has logo and everything :)
Do you want to push that all to
https://salsa.debian.org/go-team/packages/pwru so I can finalize and
upload?
I see you have now version number '1.0.5+ds2-1'. Since it has never
been uploaded, we should probably use '1.0.5+ds1-1', right?
I think this looks overall pretty good, you could rebase git history
and remove your temporary experiment commits etc what you want and put
this debian/latest branch on t
Not mandatory, but here are some Lintian nags currently reported in
package at https://salsa.debian.org/penguin359/pwru/-/commits/debian/latest
W: pwru: no-manual-page [usr/bin/pwru]
N:
N: Each binary in /usr/bin, /usr/sbin, /bin, /sbin or /usr/games should have
N: a manual page
N:
N: Note t
Package: dino-im
Version: 0.4.4-1~bpo12+1
Severity: normal
Dear Maintainer,
when the pcspkr module is loaded (was the default on my machine), dino
uses it
to beep when I press backspace on an empty input line.
To reproduce:
- execute `modprobe pcspkr` if it is not loaded
- open a chat in din
I can try importing latest upstream and run reverse builds for all
dependants.
One challenge I have at the moment is that upstream is not responding on
GitHub PRs and ignoring fixes and also not publishing any policy of which
RocksDB version is likely good for long-term maintenance. Thus there is
Currently in NEW queue since Dec 27th, 2024:
https://ftp-master.debian.org/new/glow_2.0.0-1.html
> > Hi folks!
> >
> > Can we now in 2025 agree that `wrap-and-sort -vast` is what we should
> > recommend new people joining Debian to use?
>
> I feel this question has become moot now that we have X-Style.
The X-Style is used by 'deputy reformat' only. This bug report is
about updating defaults i
Hi folks!
Can we now in 2025 agree that `wrap-and-sort -vast` is what we should
recommend new people joining Debian to use?
This proposal (--wrap-always, --short-indent, --trailing-comma) has
been open since 2018. If we can at least in principle agree that this
is best practice, the next discussi
For additional context, the build log
https://people.debian.org/~sanvila/build-logs/202412/golang-golang-x-net_0.27.0-1_amd64-20241206T201010.312Z
contains the error (which was missing from this bug report):
...
--- PASS: TestNodeLabel (0.00s)
=== RUN TestFind
--- PASS: TestFind (0.00s)
=== RUN
Package: debmake
Version debmake/4.5.1-1
Hi!
While using latest debmake I noticed that the debian/upstream/metadata
it produces seems to only consist of a citation block and nothing
else. All the "normal" fields are missing. In particular the
"Repository:" field is missing, which is important for
Hi!
I am happy to sponsor the upload of any package that has prior to
upload been proven to not have any easily testable regressions by
running Salsa CI on it. Would you be willing to put a bit of extra
work in and adopt Salsa CI as it is in the latest pkg-go-tools?
See https://salsa.debian.org/g
Forwarded: https://github.com/cli/cli/pull/10151
Hi!
I submitted fix upstream in https://github.com/cli/cli/pull/10151 and will
backport into Debian and coming days.
This could be a bit faster if the existing package maintainer replies to
email this week. I don't feel confident doing changes in
Package has now landed in NEW queue:
https://ftp-master.debian.org/new/prometheus-phpfpm-exporter_0.6.0-1.html
Yay!
Thanks Nicolas for your work to help Debian!
Forwarded: https://jira.mariadb.org/browse/MDEV-34788?
This seems to be flaky tests and not inherently a blocker for the i386 rebuild.
These issues seem like a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052838 "mariadb:
FTBFS multiple archs: Post-build tests randomly fail on
Fix pending review at https://github.com/Debian/dh-make-golang/pull/235
, feel free to check out the
package status and file Merge Requests with whatever improvements you
wish to see in Godot.
- Otto
Hi,
> Before we move on, please allow me to ask what problem the nproc tool is
> supposed to solve. Of course it tells you the number of processors, but
> that is not a use case on its own. If you search for uses, "make
> -j$(nproc)" (with varying build systems) is the immediate hit. This use
> i
1 - 100 of 1176 matches
Mail list logo
