ently comparable,
since presumably you wouldn't have to spend money to keep the existing
32-bit machine in service). If Andrey does, I'd be interested to learn
it.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the wor
ifferences, then I may either return and report that (and apologize for
the noise, and probably drop the custom config file for the future), or
just remain silent to avoid adding further noise. If I cannot find such
a method, then I will probably remain silent - and continue using the
custom config
efault font (without
risking having the changes overwritten on a future package update) that
I could find.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable ma
=any-i386
FWIW: though I haven't touched it in quite some while, I recall from all
those years ago that the reason zsnes is i386-only is that part of its
code is hand-written assembly language for (some variant of) that
architecture, and that rewriting it for that not to be the case would be
potentially-relevant questions, in
making the analysis - both to do with the possibility of making changes
to the file, and both of which are likely to have the same answer:
* If upstream were going to change the configure process, what file
would they edit?
* If you wanted to make changes to the configu
ny of us there are, but I know there's at least me
(for the testing case), and I'd greatly prefer to be able to run an
upgrade and have things Just Work rather than need to make sure I catch
whatever notification comes along and make that change at the right
time to coordinate with when
what's the point
> of the "eventual removal" above? I'm not following you here...
I parsed that not as "removal from the archive" but as "removal from the
NEW queue", much as now happens (in some order and via some mechanism,
perhaps a manual one) when a
else (which isn't signed, and might be
malicious). Since the entire purpose of the shim - at least as I
understand it - is to chain to load something else, clearly either that
understanding is not correct, or they're making an exception for the
case of the shim.
--
The Wanderer
Th
anding is not correct, I'd be interested to learn what
the actual point of having the shim is.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.
ect to comply with license requirements? I may
> have missed it, but I don't see that on your list.
Isn't that the above paragraph?
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
t; and you may find that you suddenly have quite a few more volunteers.
I do, however, concur with these sentiments. Expanding the sphere of
those who can to provide reviews (if not necessarily grant approvals) to
packages in NEW might well be a good idea.
--
The Wanderer
The reasonable man adapts h
loads a bad change" problem for
already-accepted packages, but it would seem to avoid the "nobody ever
looked at this" situation.
It would also increase the number of automatically-filed bugs by quite a
lot, I suspect, which would itself be some degree of downside...
--
The W
the pile of the the reasons why copyright law is Why We Can't
Have Nice Things.
(I concur with your assessment and arguments overall, I just didn't see
this one angle being addressed anywhere, and I feel that it's important
enough - assuming it applies at all - to make sure it do
he move had not taken place to one where it has.
(Zack, if I've gotten any of those wrong, please don't hesitate to
correct me; I'll either apologize, or drop right back out of the
discussion to go hide in a metaphorical hole, if not both.)
Do you dispute any of those three points? I
king again, short of exiting and re-launching the shell.
(Though I also haven't tried *terribly* hard.)
This seems to demonstrate that you can't safely just use 'command -v'
wherever you would otherwise use 'which'.
--
The Wanderer
The reasonable man ada
this will resolve eventually in any case, as
long as there's ever another update to the affected package?
In that case, that entirely addresses my concern, and I apologize for
the noise.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in tryin
ifying the set of
affected packages isn't something I'm in a position to do without what
to me is a noticeable degree of effort.
Is there any reasonable way to get this spelling error corrected in the
changelogs across all these packages?
Or is this too minor to be worth bothering with,
o chide him for reordering lines in a way which
(presumably inadvertently) produced an initially-misleading result, that
would be one thing, but I don't think it's appropriate to accuse him of
snipping out context when he didn't do so.
--
The Wanderer
The reasonable man adapts hims
ring the servers, and they're blocking the downloading IP address
as an anti-DoS measure. I had a similar issue at one point for rather
different reasons, and if memory serves, I avoided the issue by just
adding a (possibly-semi-random) delay period - of only a few seconds -
after the download
apparently
doesn't make clear *where* and *how* to provide that firmware.
What I read Ted as suggesting is that there be available an installer
image which *has those files / packages already present*, but prompts
the user to decide whether or not the installer should make use of them.
--
new upstream version - has
agreed to handle the packaging again, but it's not at all clear whether
it'll be ready and make it through NEW again ahead of the release
freeze.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt
ralization? I'd suggest either "but all other
vendors should do so" or "as all others should do", but other variations
are possible and I don't have a strong preference.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable
od it, was something like "the branch which everything else
should be considered to be in some sense derived from"; experience seems
to show that that sense allows for considerable versatility. IMO we
should aim to retain that meaning in whatever name is chosen to replace
'master&#x
> consistent (because there is no character code name for experimental
> AFAIK).
I thought the same at one point, but in fact, there is: it's called
rc-buggy.
https://wiki.debian.org/DebianReleases#Codenames
http://ftp.debian.org/debian/dists/rc-buggy/
--
The Wanderer
The
quot;master" branch used in upstream git repositories,
> which doesn't really have a fixed meaning anyway.)
This would be the reason why I would have argued against choosing
'latest' for the name. If a replacement for 'master' is needed, the best
candidate I've enc
missions changed to 0750 (-rwxr-x---)
>
> You mean 0754?
I missed this detail of the proposal. Please ignore my previous mail.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progres
xr-x 1 root root 83K Aug 1 13:28 /bin/dmesg
Is there some Debian context in which this isn't the case?
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on
pa_supplicant.conf, and
I wouldn't want to have to re-enter them manually into a new system if I
could avoid it. Is there a migration procedure, other convenient way to
bring those settings across into iwd?
(I'm not at the computer involved at the moment, so I can't easily check
things to
g on what package names exist in the available
repositories, they are not being affected by the current change. Is that
(still) correct?
Are there any known plans for changes regarding this inline
install/remove syntax in the currently foreseeable future?
--
The Wanderer
The reasonable man ada
e root filesystem?
(Answers in the forms of pointers to Websites, or even to archives of
past discussion where this would be made clear, are entirely
acceptable.)
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
ving HTTPS be used everywhere and in all cases, even places and
cases which would not otherwise see any benefit from using it.
That argument does not necessarily generalize to other "higher security
by default" discussions, however, and at a glance I don't think I see
how it would
hat will the resulting behavior be like, and what syntax will we be
able to use to achieve similar "mix and match install and remove in the
same command line" results (preferably with similar levels of
convenience)?
--
The Wanderer
The reasonable man adapts himself to the world
On 2020-01-04 at 05:57, Simon McVittie wrote:
> On Fri, 03 Jan 2020 at 19:52:33 -0500, The Wanderer wrote:
>
>> On 2020-01-03 at 19:33, Simon McVittie wrote:
>>
>>> D-Bus activation is a D-Bus feature where instead of starting a
>>> D-Bus service (another
On 2020-01-03 at 19:33, Simon McVittie wrote:
> On Fri, 03 Jan 2020 at 18:07:36 -0500, The Wanderer wrote:
>
>> What I'm concerned about is dbus socket activation, or similar,
>> leading to e.g. logind getting activated by logging in at the text
>> console.
>&
On 2020-01-03 at 17:43, Russ Allbery wrote:
> The Wanderer writes:
>
>> If I recall and understand correctly, installing
>> systemd-the-package will result in at least some of the daemons
>> therein - including both systemd itself, and systemd-logind - being
>>
e
reasonable to bother supporting. I don't want to just drop the
conversation midstream at this point, however.)
On 2020-01-03 at 14:36, Russ Allbery wrote:
> The Wanderer writes:
>
>> On 2020-01-03 at 13:35, Russ Allbery wrote:
>>> Why would that be necessary?
&g
On 2020-01-03 at 13:35, Russ Allbery wrote:
> The Wanderer writes:
>
>> Unless my understanding of the architecture of
>> systemd-the-init-system is entirely incorrect, running these
>> .service'es is handled by /bin/systemd. If having these programs
>> run a
On 2020-01-03 at 09:13, Ansgar wrote:
> The Wanderer writes:
>
>> However, as it remains the case that they are shipped in the same
>> package as /bin/systemd, and as I gather (mostly from this thread,
>> I think) that some of the ways they are expected to be invoked
&g
On 2020-01-03 at 07:50, Ansgar wrote:
> The Wanderer writes:
>
>> On 2020-01-02 at 08:14, Thomas Goirand wrote:
>>
>>> As I wrote, no need to complain, but act.
>>>
>>> https://salsa.debian.org/debian/opentmpfiles
>>
>> For me (with n
On 2020-01-03 at 08:50, Andrej Shadura wrote:
> Hi,
>
> On Fri, 3 Jan 2020 at 14:02, The Wanderer
> wrote:
>
>> On 2020-01-02 at 09:03, Sam Hartman wrote:
>>
>>> My understanding is that systemd's implementation of tmpfiles
>>> and sysuser
son for me to finally give up on
Debian and try alternatives, whether Devuan or Gentoo or something
farther afield.
In that context, I find the entire premise of "why do we need multiple
implementations of this?" to be unfortunate; "need" is, IMO, the wrong
standard to use fo
in other distros), so that
doesn't fit.
Any idea what's going on here?
> https://salsa.debian.org/debian/opensysusers
This one shows the repository and its contents, however.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in tryi
; Issues preventing migration:
>> firefox-esr unsatisfiable Build-Depends(-Arch) on armel: nodejs (>= 8.11)
>> missing build on armel
That seems clear enough to me, although I haven't looked into the
reasons why that dependency can't currently be satisfied on that
architecture.
On 2019-08-07 at 16:59, Andrei POPESCU wrote:
> On Mi, 07 aug 19, 09:28:12, The Wanderer wrote:
>
>> I've begun to wonder whether it might be worth the overhead to set up
>> some type of mechanism to let packages which define such
>> machine-specific IDs A: d
ient
generality. If people think the idea is worth pursuing but that solution
is not ideal, I would be more than happy to defer to those with more
expertise.
--
The Wanderer (will, statistically, probably regret posting this)
The reasonable man adapts himself to the world; the unrea
st to include the
"release" version, i.e., mainline non-ESR.
My understanding is that that's a nonstarter for one reason and another,
but I don't recall all the specifics involved.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
pe
lutions but (for
discoverability's sake) as many of the client-specific error messages as
may be practical. (For those clients which don't present the solution
themselves, of course.)
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
D Graphics" series). Presumably that's what
> you meant when you said embedded?
I don't know of any which exist currently, but a naive Google search for
'discrete Intel GPU' turns up news articles from this past August
reporting that they've teased one coming out in ~
On 2018-10-26 at 00:51, Russ Allbery wrote:
> The Wanderer writes:
>
>> On 2018-10-25 at 20:00, Russ Allbery wrote:
>
>>> The Depends field should be used if the depended-on package is
>>> required for the depending package to provide a significant
>>>
efinitions would seem equally applicable.
If that's correct, then the definitions don't actually help indicate
which relationship should be declared in such a case. That strikes me as
a flaw in the definitions, quite possibly an unintended one, and (if so)
potentially a bug worth fixing.
--
included, but the basic functionality
should be present.
(And I say that as a near-diehard sysvinit user, who finds the idea of
sysvinit being dropped from Debian a source of considerable stress.)
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
at the odds of any change being made at
this point are exceedingly slim.
Basically, don't ever expect to receive via Gmail a copy of a message
sent from that same Gmail account.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to a
ith them.
Even leaving other Mozilla-based browsers aside, ISTR there being (or
having been?) some extensions which would work just fine in both Firefox
and Thunderbird, and since Thunderbird is retaining XUL support - at
least for now - there may be some value in retaining such "overlap
nd will not (as far as I can see) pull in anything named
python3*.
That is enough to qualify Python 2 as "the Python which will be present
in a default install of Python on Debian", and therefore as "Debian's
default version of Python".
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
On 2018-04-18 at 10:53, Ansgar Burchardt wrote:
> On Wed, 2018-04-18 at 10:45 -0400, The Wanderer wrote:
>
>> On 2018-04-18 at 05:55, Andrey Rahmatullin wrote:
>>> But that didn't happen, unless you put different meaning into
>>> Maintainer and Uploaders.
&
oved you as a maintainer.
>
> But that didn't happen, unless you put different meaning into
> Maintainer and Uploaders.
If you don't assign different meanings to "Maintainer:" and
"Uploaders:", what's the point in both fields existing?
--
The Wanderer
tually conceive of there being
such I so far haven't been able to think of any.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. --
leases.
> But what is "CIP"?
>
>
> My websearch did bring up "Clean In Place" and "Christelijk
> Intromatie Platform" ...
Referring back to Raphael's original mail, it would appear to stand for
"Civil Infrastructure Project".
--
ren't doing that for
> PostgreSQL.
Nit: the new Firefox ESR this year will apparently be version 60, not
59. They've postponed it by one release this time around, for reasons I
haven't bothered to retain.
--
The Wanderer
The reasonable man adapts himself to the world;
ve
never seen this "suspend in response to Shut Down" behavior there; the
first place I ever saw it was on a Windows 8 machine.
I'm not sure I've yet seen it in our current Windows 10 pilot, either,
but I also haven't looked especially closely there.
--
The Wanderer
and this.
I think I parse this as saying that the VM in question *is* a (virtual)
server, and as such needs to run server software (including time-server
software) for the benefit of other systems.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persi
imal solution? Although that would seem to imply a change in
what is considered "part of Debian", which might be controversial.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progr
tten* with
> an H at the start, but the H was not pronounced; I just wrote it
> down incorrectly.
At a guess, probably "herb", which is commonly pronounced without the
initial aspirant even in dialects (etc.) which ordinarily don't elide
such.
--
The Wanderer
The reasonab
of antimetapackages to be conflicted against seems like a recipe for
madness.
I hope I'm just missing something, because this looks like a very
interesting idea. With Recommends:, however, it looks like it would do
nothing more than potentially warn the user at install time that a
package w
On 2017-03-03 at 23:36, Ben Finney wrote:
> The Wanderer writes:
>
>> In this case, either it's faked up to look as if it's coming from
>> the person listed in the From: address but that person has actually
>> never seen the message before it reaches us, or
ing
sent _to_ that person (to appear as if it had come from the mailing
list) and we don't even have the headers of the actual original spam.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. There
message and has headers (etc.) as if it were a response
by J. Random Netizen to a message already posted in some random thread.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends
On 2017-01-30 at 07:38, Bernd Zeimetz wrote:
> On 01/30/2017 01:32 PM, The Wanderer wrote:
>
>> If someone isn't cloning the repository locally, how is that
>> someone creating the patch which is in the git repo which is
>> requested to be pulled?
>
> Choose a
ng your local changes into github is
with 'git push'; at least that's what I had to use the one time I tried
to work with github other than to clone a repo hosted there, although
admittedly my network situation is a bit unusual.)
--
The Wanderer
The reasonable man adapts himself to
em to be well received.
>
> Because I write the name of a project in the most reasonable
> capitalized form.
Without taking sides on the question at hand: do you, then, spell the
name of the distribution as DebIan?
--
The Wanderer
The reasonable man adapts himself to the world; the unre
es are valid, mind. That doesn't mean they aren't excuses.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
aving insufficient-data bugs
open is not a good idea for many kinds of projects, and I believe for
why Debian would be one of them; I'm not sure I necessarily accept that
rationale, but it is a solid one. That doesn't invalidate the above
logic, however, only explain why it may not
developers of Debian are developing software for themselves -
but I'm pretty sure the point of what you quoted is in the word "only",
which you omitted from your rephrasing, and I'm not at all sure even all
Debian contributors would agree that they are contributing to Debian
_only_
On 2016-09-15 at 22:03, Ben Finney wrote:
> The Wanderer writes:
>
>> On 2016-09-15 at 21:26, Wookey wrote:
>>
>>> I reckon a lot of us would be happier if you [Russ] (and Abou)
>>> used the term 'users', rather than 'customers'. I
rd - especially not
given that the entire discussion would be at best arguably on-topic.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
gt; the subscribers of debian-devel, and that we should try to find
> alternative ways for channeling such support requests.
Albeit (for reasons I can't seem to pin down into verbal form) somewhat
reluctantly, I have to agree with this.
--
The Wanderer
The reasonable man adapts himsel
"
than can the latter.)
Which is probably to say that eliminating, or at the least reworking,
the 'general' package as a target for bug reports would probably be an
improvement if done properly. I'm not terribly fond of it as an idea at
first glance, but the logic behind it d
building for upload isn't the only valid - or, AFAIK,
the only supported - reason to want to build in a given release.
Users of Debian - including both testing and stable - may want to
rebuild a given package themselves, perhaps with local modifications,
for use in the release which they are
ferences: headers manually every time they
look at the list of available messages.)
To arbitrarily drop that additional flag would require more
reason than "just because".
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt
On 2016-08-28 at 09:11, Jonathan de Boyne Pollard wrote:
> The Wanderer:
>
>> IMO this level of integration between things which are not mutually
>> interdependent is a minor bug in itself, but none of the
>> maintainers are going to agree with me on that.
>
> Actu
ntioned
elsewhere, which means I do need to wade through that changelog in case
anything relevant is mentioned.
IMO this level of integration between things which are not mutually
interdependent is a minor bug in itself, but none of the maintainers are
going to agree with me on that.)
--
The
On 2016-08-25 at 23:06, Paul Wise wrote:
> On Thu, Aug 25, 2016 at 9:29 PM, The Wanderer wrote:
>> If there exists a dependency solution which will achieve the
>> result requested on the command line (here, installing the lower
>> version of the depended-on package), th
On 2016-08-25 at 23:06, Paul Wise wrote:
> On Thu, Aug 25, 2016 at 9:29 PM, The Wanderer wrote:
>
>> In other words: the problem here is the fact that apt's priorities
>> in this regard are messed up.
>
> The same will happen with custom priorities set.
I a
package), that solution should be chosen over any which do
not achieve that result; if that solution involves removing or
downgrading packages, it should be presented for confirmation before
proceeding.
If - as is apparently the case - apt does not presently do that, that
should IMO be considered
are present - and IMO neither of those
is the correct default.
The presence of a comment such as this one informs me that I may want to
vary that practice in a given case. (I haven't done so in this case
since this mail is no longer on the topic which he raised, so I don't
have good
On 2016-05-08 at 09:09, Neil Williams wrote:
> On Sun, 08 May 2016 07:18:40 -0400 The Wanderer
> wrote:
>
>> On 2016-05-08 at 03:45, Neil Williams wrote:
>>
>>> On Sun, 8 May 2016 00:51:57 +0200 Pierre Ynard
>>> wrote:
>>
>> Even if runnin
On 2016-05-08 at 08:20, Marc Haber wrote:
> On Sun, 08 May 2016 07:18:40 -0400, The Wanderer
> wrote:
>
>> Even if running unstable, I would certainly expect that something
>> which is known to break certain types of systems this badly would
>> be announced at packag
g sid as
being a reasonable thing to do, although I myself decided years ago from
experience that it was a bad idea.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unrea
ld Provides:
firefox (or that both should Provides: a single virtual package), or
something along those lines, to avoid requiring packages to list both
alternatives explicitly. I'm not sure that wouldn't have too many
downsides to be a good approach, however.
--
The Wanderer
The reaso
reality is, code is only flowing
> _away_ from MySQL at this point. MariaDB's changes don't go back
> into MySQL. So the forks will just get further and further apart.
That's more or less what I'd expect. It still seems possible that the
"downstream" fork would retain
t the
two would be seamlessly compatible on the database level, and that
expectation seems to have been borne out.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unr
ess they're known to already be
broken badly enough that not having any would be an improvement
(although I don't think I've seen this specifically addressed in past
discussions). You wouldn't be obliged to continue to maintain and update
them, however, and IMO - in the absence
bly be "customize the user dictionary" instead
of "customize user dictionary".
The result of those changes isn't ideal, but it's adequate - and fixing
things up further would be me rewriting things on my own initiative,
rather than just pointing out corrections.
--
On 2015-12-06 at 18:23, Russ Allbery wrote:
> The Wanderer writes:
>
>> I'm not sure I'm happy about such an important change in the
>> behavior of the core binary of one package being (able to be) made
>> by an update to a completely different package, and
On 2015-12-06 at 15:30, Russ Allbery wrote:
> The Wanderer writes:
>
>> $ apt-cache policy apt-file
>> apt-file:
>> Installed: 2.5.4
>> Candidate: 2.5.4
>> Version table:
>> *** 2.5.4 0
>> 500 http://ftp.us.debian.org/debian
On 2015-12-06 at 11:46, Jakub Wilk wrote:
> * The Wanderer , 2015-12-06, 08:50:
>
>> Er... the entire reason I started running 'apt-file update' in the
>> first place is because running 'apt-get update' was not, or did
>> not appear to be, u
On 2015-12-06 at 07:01, David Kalnischkies wrote:
> On Sat, Dec 05, 2015 at 07:58:07AM -0500, The Wanderer wrote:
>> Will it still be possible to update just the apt-file index,
>> separately from updating the main package index? I see no
>> indication in the current apt(8)
stop updating the
apt-file index, or deal with redundant updates to the package index
(which might quality as "switch to apt" in practice).
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. T
t,
that would explain the observed behavior.
Unfortunately I don't have immediate access to a set of headers for the
3.18-era kernel, so I can't easily check that myself, but it shouldn't
be hard for you to check it on your build machine.
--
The Wanderer
The reasonable man a
cursive acronym "GNU" is a similar piece of wordplay.
I concur that this sort of wordplay in naming is a *nix tradition;
however, I withhold comment as to whether the name "bikeshed" is
appropriate in this case, as the first I remember hearing about them is
this thread and I don
1 - 100 of 227 matches
Mail list logo
