sly overestimate how easy it is for
packages to be upgraded individually (compare: t64 testing migration).
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
them by generating work for many people and potentially
new upgrade problems for everyone – or if we declare them, existing or
not, a non-issue at least for the upgrade to trixie.
And on a sidenote: I would advise to reconsider interacting with dpkg
too casually – but luck is probably on your side in any case.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
exhibit the
required setup).
(I will write another mail in another subthread about the finer details
of what interacting with dpkg in an upgrade means and what might be
problematic if you aren't careful – in general, not just with aliasing)
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
On Mon, Dec 04, 2023 at 01:13:43PM +0100, Helmut Grohne wrote:
> David Kalnischkies made me aware […]
Oh, did he? I think he wanted to tell you something else…
As IRC seems to be really bad at transporting complicated things (who
had guessed?) and I need to sort my thoughts anyhow let
lly" also "Multi-Arch: foreign".
> provide clones of a single package list for every architecture explicitly,
> and having to do so whenever a new one appears.
So yeah, if you want you can ship only an -all/Packages file and add the
others if you ever ship some as long as you te
s the day after ~tomorrow groff will migrate as well – assuming
dgit was really your only problem.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
es
with every revision), but close enough. At least more realistic than
that this software wasn't changed since the start of the unix epoch…
So please drop this again if its no longer needed.
Best regards
David Kalnischkies
P.S.: d-devel@ isn't entirely wrong as this is sufficiently esoteric,
as-wanted basis)
Can you recommend a relatively safe & old version to use instead of
< 3.5 which doesn't need bumping next month but is also available in
most semi-current releases of all major distributions (as that is what
most upstreams will care about if they don't have special
ve some "random"
files not present on disk. So your system might not even boot or spawns
interdimensional portals. You better reinstall…' is not the type of
thing you wanna here from support.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
On Sun, Dec 18, 2022 at 06:08:57PM +0100, Johannes Schauer Marin Rodrigues
wrote:
> Quoting David Kalnischkies (2022-12-18 17:18:28)
> > On Fri, Dec 16, 2022 at 03:38:17PM +0100, Santiago Vila wrote:
> > > Then there is "e2fsprogs", which apt seems to treat as i
rst. But no problem, there usually is an option to
change anything in apt. If not, we can usually add it.
Just don't assume that the behaviour you prefer will be the default.
We have a strong tendency to make everyone unhappy.
(I should know, I never get what I want.)
Best regards
David Kalnischkies
P
help not installing broken packages (but that is another
topic).
So, who is gonna take the blame for deciding this for everyone?
Best regards
David Kalnischkies
[0]
https://salsa.debian.org/apt-team/apt/-/blob/main/apt-private/private-update.cc#L88-106
signature.asc
Description: PGP signature
On Mon, Oct 10, 2022 at 08:50:49AM +0800, Paul Wise wrote:
> On Sun, 2022-10-09 at 18:54 +0200, David Kalnischkies wrote:
> > I suppose we could use 'foo-dbgsym Enhances foo:arch (= version)'.
>
> That sounds interesting and would be nice generally, however...
>
>
ing all those nitty-gritty details to
policy would certainly be an interesting endeavour but if it would
really be a service to human kind^W^Wcontributors I am not so sure even
if its frequently used as an argument against MultiArch and related
projects.
Best regards
David Kalnischkies
[0]
http
cial), but that would lead us too far off-topic here…
So, could that be an acceptable Option c) ?
Best regards
David Kalnischkies
¹ this example was explicitly chosen as its possible that you
want to use them independently. I don't see a lot of reasons for
independent usage of e.g
the Release files,
which only stable does currently, stable-updates and stable-security
rely on apts built-in fallback which is sad)
Best regards
David Kalnischkies
P.S.: As I was quoted already, as a side note: I am not against nor in
favour of trimming; I am just pointing out potential probl
On Thu, May 26, 2022 at 08:50:21AM +0200, Marc Haber wrote:
> On Wed, 25 May 2022 20:21:03 +0200, David Kalnischkies
> wrote:
> >apt actually marks dependencies
> >of packages in section metapackages as manually installed if the
> >metapackage is removed due to t
::Never-MarkAuto-Sections
in apt or reconsider having tasks be in their own Section, personally
I would prefer the later.
There are many other packages which feel like metapackages, but aren't
for apt as they are in the 'wrong' section – which is what I meant later
on in the mail, but that was arguably very well hidden.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
(And yes, apt installs new recommends in upgrades since literal decades,
so that is absolutely not a reason to use depends…)
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
from the apt team, I don't think we
have the resources to help you with packaging through.)
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
regardless, but /usr-merge undoubtedly makes heavy use of it
so in an ideal world those interested in it would not only acknowledge
the problems but actually work together to resolve them.
Sadly, that isn't the world we seem to be stuck in at all.)
Best regards
David Kalnischkies
¹ You could o
On Wed, Nov 10, 2021 at 01:48:07AM +0200, Uoti Urpala wrote:
> David Kalnischkies wrote:
> > As the transition hasn't started everyone not already merged is currently
> > deferring it. That is true for those who upgrade daily as well as for
> > those people who seemingly o
On Tue, Nov 09, 2021 at 08:44:52PM +, Simon McVittie wrote:
> On Tue, 09 Nov 2021 at 19:01:18 +0100, David Kalnischkies wrote:
> > On Tue, Nov 09, 2021 at 03:21:25PM +, Simon McVittie wrote:
> > (Minus that for 12 it is technically still supported as long as it
ng an official opt-out of the
opt-out as long as it happens in time.
(Perhaps it comes with the job as apt maintainer, but I don't "discard
and redo" systems or even chroots… upgrades until hardware failure…
my current build chroots are from 2013. So I can totally see me opt-out
automatic
transition for whatever reason (lets say to test build packages on that
box) I also have a standard way of triggering the conversion by calling
dpkg-reconfigure on usrmerge at leisure before the 13 upgrade.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
ormats, but
I opted to change that as of course countless things poking into those
files broke left and right.
cups used to detect if it ran on a Debian-like system by checking the
sources.list file for deb entries… I doubt it does nowadays as there are
countless better options now, I just mention it
de nobody really uses for years (as is
common in apt land – backward compat be damned ).
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
ere were I before this 'emergency call' came in… mhhh)
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
On Sun, Sep 12, 2021 at 03:10:27AM +, Paul Wise wrote:
> On Fri, Sep 10, 2021 at 6:03 PM David Kalnischkies wrote:
> > Because this thread started with the idea to switch the default of d-i
> > and co to another URI. If you target only apt then you still need
> > a solut
On Fri, Sep 10, 2021 at 11:08:38AM -0400, Michael Stone wrote:
> On Fri, Sep 10, 2021 at 04:33:42PM +0200, David Kalnischkies wrote:
> > On Thu, Sep 09, 2021 at 08:53:21AM -0400, Michael Stone wrote:
> > > The only thing I could see that would be a net gain would be to
hing to do with sources. It is true that
apt-cacher-ng (and perhaps others) have a mode of operation in which you
prefix the URI of your (in that case caching) proxy to the URI of the
actual repo, but that isn't how a proxy usually operates and/or is
configured.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
rd apt is
stricter than a normal webbrowser (a mirror list acquired via https can
redirect to http mirrors though, but see the man pages for details).
Best regards
David Kalnischkies
¹ which deb.d.o sort of is just that it is nowadays done via SRV instead
of an explicit HTTP redirect – and tha
On Mon, Aug 30, 2021 at 11:53:59AM +0100, Colin Watson wrote:
> On Mon, Aug 30, 2021 at 12:30:49PM +0200, David Kalnischkies wrote:
> > So, while for some/most usecases something akin to DynamicUser would be
> > enough, for others a more stable user would be preferred and then the
ppy to be wrong through as it isn't exactly my dream to
make apt a decent service manager even through apt starts a lot
of processes, so a lot of management could and should be done here…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
orm of 'man
in the middle' "attack" https has no chance of preventing or detecting.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
ore reading Guillems replies which end on a similar
note even though he comes from the opposite end – dpkg worried about
the finer file-level details and apt about the general package-level
picture meeting halfway as usual… kinda funny)
Best regards
David Kalnischkies
P.S.: As someone will ask:
I can't remember of the top of
my hat. There are likely more problems as it is easier to just set the
clock approximately correct than to remember all the workarounds in
"the time of need"…
Best regards
David Kalnischkies
¹ okay, ~15 years of apt-secure are not exactly ever, but close enough.
signature.asc
Description: PGP signature
you
need some form of opt in at least. So far, that opt in was using http.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
hat many (so far).
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
On Mon, Aug 16, 2021 at 03:13:48PM +0200, Marco d'Itri wrote:
> On Aug 16, David Kalnischkies wrote:
> > Is perhaps pure existence not enough, do I need to provide an upgrade
> > path as simple as possible as well?
> If you have specific ideas about how the upgrade path
ve
to do it manually" so far. Surely you came up with something a lot
better after all those years.
Best regards
David Kalnischkies
P.S.: For the avoidance of doubt: apt-get is of course going nowhere,
but that cuts both ways: It isn't changing as your fingers hate change –
so e.g. no new interact
On Sun, Aug 15, 2021 at 05:52:06PM +0100, Simon McVittie wrote:
> On Sun, 15 Aug 2021 at 11:52:21 +0200, David Kalnischkies wrote:
> One way out of this would be to say that it is a RC bug for packages
> in bookworm to have different contents when built in equivalent
> merged-/usr
On Sun, Aug 15, 2021 at 12:16:39AM +0100, Simon McVittie wrote:
> On Sat, 14 Aug 2021 at 16:59:24 +0200, David Kalnischkies wrote:
> > Wouldn't it be kinda strange to have the chroots building the packages
> > for the first bookworm release using a layout which isn't supported
On Sat, Aug 14, 2021 at 02:26:29PM +0100, Simon McVittie wrote:
> On Sat, 14 Aug 2021 at 14:33:44 +0200, David Kalnischkies wrote:
> > the current 'transition' plan is to have the
> > release notes nudge all people who upgrade instead of reinstall their
> > systems, chroots a
pen question for them
still as nobody is running the upgrader in there of course.
See also https://bugs.debian.org/985957.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Best regards
David Kalnischkies
P.S.: I picked out only this line as I think most of the rest is more
or less discussed to death already in other sub-threads and at times
actually objectively wrong – like the amount of packages shipping
something in /bin and co – so I don't feel like rehashing those
n with).
So, before I am rushing off to do whatever I like, could we perhaps
agree on a "sensible-restricted-pager" (I dare not to name it secure…)
sort-of implementation first?
Oh and, btw, there is no point¹ in running 'apt changelog' with root
permissions – it is beside the point here
ges=1 to disable this check.
Or, simply don't try to reinstall packages for (probably) no reason…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
e are unwilling to postpone,
and one we intend to win".
Lets see how that will go.
Cavendish surprised most experts, too.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
On Fri, May 28, 2021 at 05:12:01PM +0100, Simon McVittie wrote:
> On Thu, 27 May 2021 at 16:53:45 +0200, David Kalnischkies wrote:
> > dpkg has the notion of "disappearing packages" (packages which have no
> > files left on a system) which could solv
themselves too much with upgrades, but are
mostly used in build-chroot constructions, so you might get away without
it (see also optimisation criteria "less removals" from above).
As the number increases we would also need an "upgrade" command which
allows those removes but not the others as our current "upgrade" becomes
less and less useful.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
-default by
installing qtbase5-gles-dev (just to then figure out that gles-dev
breaks qt5-default, so it has to remove the later anyhow).
Thanks for looking into this: That seems like a simpler and less
controversial example than the one I used for the last big round of
resolver changes … and sorry
es your users to experience the worst of both worlds:
The packages can not be co-installed forcing them through the change in
one sitting and they are an upgrade nightmare as there will always be
one more situation in which apt (or another resolver, or even a human)
decides that (part of) an upgra
han 16y later…).
So don't worry that you haven't heard about it yet: You are not the last
one to know, you are in fact well ahead of the curve.
As said, if you have questions (or ideas), feel free to praise the cow
^Ŵ^W^W join #debian-apt on IRC, mail us at deity@d.l.o or even report
a bug a
ullseye though as such
a change would likely not get a freeze exception.
Best regards
David Kalnischkies
¹ ; char const * const name = "World"
; printf("Hello %s!", name)
(that style reminds me of some other language I have seen but can't
quite remember at the moment; I jus
on one side actually gives
the one having it a scoring advantage in apts conflict resolution, so
for apt it reads in fact like -gles is the preferred package of the
two making it less likely that apt holds back libqt5gui5. In practice
other score points should level the playing field for libqt5gui5 th
isn't what you meant to say of course, but you would be surprised how often
that style is used rather than the intended "I have no idea why APT does that
here, could someone please explain it?".
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
d hence ask you to explain a bit better why you think APT is wrong
and provide an example which actually shows these characteristics.
Otherwise I will apparently be a tiny bit annoyed by this thread.
Best regards
David Kalnischkies
P.S.: For these cases -o Debug::pkgDepCache::AutoInstall=1 sh
be applied so that this happens only to
packages which end up in Debians repositories… which could complicate
reproducibility as its clear for a buildd, but my local sbuild…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
)
Now, suggesting that apt is not an integral part of a Debian system and
could henceforth be removed is of course heresy! The only thing saving
you vile heretics is apts heavy involvement in the creation of these
chroots.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 29 Dec 2019 16:40:19 +0100
Source: vim-youcompleteme
Architecture: source
Version: 0+20191218+git9e2ab00+ds-1
Distribution: unstable
Urgency: medium
Maintainer: David Kalnischkies
Changed-By: David Kalnischkies
Changes:
vim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 29 Dec 2019 15:13:44 +0100
Source: ycmd
Architecture: source
Version: 0+20191222+git2771f6f+ds-1
Distribution: unstable
Urgency: medium
Maintainer: David Kalnischkies
Changed-By: David Kalnischkies
Closes: 912690 929987
eature via the config option APT::Sources::With, the commandline
flag is just syntactic sugar.
So, as aptitude has I think -o you could e.g. say
-o APT::Sources::With::=/path/to/file.deb
or if all else fails a config file of course.
Best regards
David Kalnischkies
signature.asc
Descriptio
a Sources file? Also, --with-source actually
allows to add Packages/Sources files as well, I use them for
simulations only, but in theory they should work "for real", too.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
t plan is to make the switch over for Suite
changes automatic – if some preconditions are satisfied. The discussion
about that isn't hard to find, but here you go: #931566. You are welcome
to add any good ideas not already present (that hopefully shows also
that this is a tiny bit more complex than
ractive question) or
"apt-get update --allow-releaseinfo-change" (see apt-get manpage) or
[least preferred option] set the config option
Acquire::AllowReleaseInfoChange for basically any apt-based client.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
stion as that seems wrong (and why I put "bug" in quotes).
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 14 Feb 2019 11:38:37 +0100
Source: vim-youcompleteme
Architecture: source
Version: 0+20190211+gitcbaf813-0.1
Distribution: unstable
Urgency: medium
Maintainer: Onur Aslan
Changed-By: David Kalnischkies
Changes:
vim
Kalnischkies
Description:
python-hamcrest - Hamcrest framework for matcher objects (Python 2)
python3-hamcrest - Hamcrest framework for matcher objects (Python 3)
Closes: 917660
Changes:
pyhamcrest (1.8.0-1.1) unstable; urgency=medium
.
[ David Kalnischkies ]
* No-change non-maintainer upload
field
* d/control: Set Vcs-* to salsa.debian.org
.
[ Sylvestre Ledru ]
* New upstream release
- Refresh path-to-server-script.patch
.
[ David Kalnischkies ]
* New upstream version 0+20181101+gitfaa019a
- Use uscan to generate tarball from upstream git HEAD
- Refresh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 02 Nov 2018 19:57:14 +0100
Source: ycmd
Binary: ycmd
Architecture: source
Version: 0+20181101+git600f54d-0.1
Distribution: unstable
Urgency: medium
Maintainer: Onur Aslan
Changed-By: David Kalnischkies
Description:
ycmd
ng an
archive and most of these tools have a focused upstream… the apt client
needed a server to start rolling, but nowadays this server side hustle
is more a brake than an accelerator.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
hing by it. We
just (literally) moved the problem.
(The other aspects I will hopefully answer with another mail in the
gsoc/outreach subthread)
Best regards
David Kalnischkies
[0] https://wiki.debian.org/Teams/Dpkg/RoadMap
signature.asc
Description: PGP signature
ting task of actually switching code,
documentation and existing databases over on the other hand… I at least
don't see me enthusiastically raising my arm crying "let me, let me, …".
Best regards
David Kalnischkies
¹ The Census has a field for "Archive tool", but
hanged-By: David Kalnischkies <donk...@debian.org>
Description:
apt-transport-tor - APT transport for anonymous package downloads via Tor
Changes:
apt-transport-tor (0.4) unstable; urgency=medium
.
* fix typo in Vcs-{Git,Browser} URI
* document that a-t-tor is not a The Tor Project prod
fensive takes off. SCNR)
> I second this patch. I suggest we add it as section 3.1.1, i.e., as a
> subsection to 3.1 "The package name".
[As this is the first subsection I wonder if there will soon be many
more "rip-off" naming conventions added like python-*, *-perl, … a
e
release notes helps preventing "decades-old" as that includes the
suggestion to run 'clean' before the upgrade and Debian releases a
few times within a decade… (heck, apt hasn't reached the "decades"
milestone yet… so technically… but just a few more months).
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
regards
David Kalnischkies
[0] https://wiki.ubuntu.com/AptElfDebugSymbols
signature.asc
Description: PGP signature
nstall-recommends.
I would recommend not to recommend it because apt follows the general
recommendation of not recommending the installation of recommendations
of build-dependencies by default for all recommended Debian releases.
Recommended summary: Already the default since 2011.
Recommending eve
On Wed, Feb 22, 2017 at 09:04:16PM +0100, Luca Capello wrote:
> On Wed, 22 Feb 2017 13:16:27 +0100, David Kalnischkies wrote:
> > On Wed, Feb 22, 2017 at 01:06:24PM +1300, martin f krafft wrote:
> > > What am I not understanding right here? Shouldn't "apt-get upgrade"
-picture test!)
Oh, and of course the standard reply: You know, apt does print
a proposal not an EULA – so you don't have to press 'yes' without
reading.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
e fellowship of the cow!
Best regards
David Kalnischkies
[0] https://qa.debian.org/cgi-bin/bugs-by-source
signature.asc
Description: PGP signature
would still like to have some for a-t-tor, too. The package is
even way smaller than even the smallest node packages [SCNR] nowadays
and someone with an eye for detail, integration and documentation could
do wonders… but I start to digress.
Best regards
David Kalnischkies
[0] https://xkcd.com/1172/
signature.asc
Description: PGP signature
s long as you haven't
got a bugreport telling you it would be nice from some cross-folks (be
it grader, builder, bootstrapper, …). Reason is that M-A:same/foreign is
instantly useable/ful, but M-A:allowed is useless if nothing ends up
depending on it with :any.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
that smells wrong… What are you trying to express here?
(and have you heard that automatic debug packages are a thing nowadays?)
Best regards
David Kalnischkies
[0] https://wiki.ubuntu.com/MultiarchSpec
[1] There are ways around it. See the "If it helps" remark for a hint.
signature.asc
Description: PGP signature
On Thu, Oct 27, 2016 at 10:05:56PM +0200, Tollef Fog Heen wrote:
> ]] David Kalnischkies
> > I would kinda like to avoid encoding the entire answer and sending that
> > in for display because it would be a lot of noise (and bugreporters will
> > truncate it if it is too long
I would kinda like to avoid encoding the entire answer and sending that
in for display because it would be a lot of noise (and bugreporters will
truncate it if it is too long trying to be helpful), so if people who
actually know what they would need to deal with issues (I don't) would
decide upon a set and
nt an opportunistic use
of https if a-t-https is installed and "_https._tcp." srv-lookups get
a favorable response by letting http ask for that first and internally
redirect in that case.
So, you see, as usually, there isn't a shortage on ideas. If someone
wants to work on any feel free to joi
for because it isn't. Various people have said for various teams
already which technical challenges need to be solved before we can
seriously think about rolling out https on a broad scale and as usual
the problems aren't fixing themselves if only we talk long enough about
them…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
ing to do security) have I bet the security team would
be overjoyed if all clients talking to a mirror would embed such code…
Best regards
David Kalnischkies
¹ overloaded term, here it means: "Debian Signature Algorithm" – SCNR
signature.asc
Description: PGP signature
left as an
exercise to the reader.
Best regards
David Kalnischkies
P.S.: There are various arguments why -https is in terms of mirrors – as
their content is static and public knowledge – more an obfuscation
rather than 'real' security/privacy enhancement. If you want more/better
have a l
hanged-By: David Kalnischkies <donk...@debian.org>
Description:
apt-transport-tor - APT transport for anonymous package downloads via Tor
Closes: 755675 812490 835128
Changes:
apt-transport-tor (0.3) unstable; urgency=medium
.
[ David Kalnischkies ]
* use apt 1.3 directly instead of an e
Not sure what tool you are using to generate an apt repository, but it
seems rather non-standard given that it includes the deb file also in
the Release file… using one of the many already existent solutions might
be better…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
oes OR exist as | then?, is
it a versioned relation, keeping API and/or ABI, what if v2 of a package
adds/modifies/removes the field, interaction with autoremove………
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
ng with packages.
For Multi-Arch itself I managed to hide away most of it behind implicit
dependency relations, versioned provides and 'strange' virtual packages
for the libapt-based ones which made that transition quite "easy" all
things considered, but we can't pretend it will always be that "easy"…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
;too weak hash" – but error is error either way, so you may want to talk
to the repository maintainers (there are more than just this repository
with such an issue) and I should write a patch to produce a better
message as we were talking in the APT team about it for a while now…
Best regards
Dav
is of a proud heart stirreth up strife: but …".
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
On Thu, Dec 24, 2015 at 01:50:45AM +0100, Alberto Salvia Novella wrote:
> Luis Felipe Tabera Alonso:
> David Kalnischkies:
> > It is not a good idea to perform autoremoves unattended for situations
> > in which you have installed A (gui) depends B (console) depends
> > C
ood that
others put a stop to such ideas before those ideas have a chance to hurt
me (and I can assure you, I implemented ideas which never should have
been and now taunt me by their mere existence).
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
On Sun, Dec 06, 2015 at 08:50:55AM -0500, The Wanderer wrote:
> On 2015-12-06 at 07:01, David Kalnischkies wrote:
> > On Sat, Dec 05, 2015 at 07:58:07AM -0500, The Wanderer wrote:
> > (as I am sightly lying, it is actually possible – just not very
> > accessible for a user and
1 - 100 of 254 matches
Mail list logo
