e time.
> But, I haven't looked too closely into that since without an MUA it
> isn't terribly useful.
Sylpheed supports filters which allow you to have e-mails in
multiple directories based on arbitrary user-defined filtering.
It supports IMAP also, though I never use it as I prefer POP3 and
SMTP.
Best regards,
Andrew Savchenko
pgpjAxsQFeuMk.pgp
Description: PGP signature
imal page width is
about 67 characters, see Knuth's work on that. Barring spaces and
tabs that 67 will give approximately 80.
Best regards,
Andrew Savchenko
pgp1SP1bYVXjs.pgp
Description: PGP signature
ce to finally fix that, but let's be realistic: it looks
> like
> it wouldn't be finished in the near 10 years :-/
It will never be finished, because console-based workflow is the
most efficient way to work for many people, especially for advanced
users/devs.
Best regards,
Andre
On Sun, 7 Jun 2015 04:40:47 + (UTC) Duncan wrote:
> Andrew Savchenko posted on Sat, 06 Jun 2015 20:36:13 +0300 as excerpted:
>
> > On Sat, 06 Jun 2015 18:35:41 +0600 Vadim A. Misbakh-Soloviov wrote:
> >> > * linewidth >> 80 (why do we have this short limit stil
ng another generator, and to
> get deps right.
Sounds great. IMO default value should be determined per-package:
if upstream recommends Ninja (or there is a good testing with
Ninja), then set it, otherwise emake.
Any progress here? The only package in tree which allows user to
select cmake backend is llvm-.
Best regards,
Andrew Savchenko
pgp6h_a0gQ8pI.pgp
Description: PGP signature
lue, since the way the git DAG-chain of SHA1's work,
you only ever need _one_ signature to make all the commits
reachable from that one be effectively covered by that one. So
signing each commit is simply missing the point.
''
Best regards,
Andrew Savchenko
pgp3IuIWwuwJv.pgp
Description: PGP signature
On Fri, 3 Jul 2015 21:40:50 + Robin H. Johnson wrote:
> On Sat, Jul 04, 2015 at 12:19:41AM +0300, Andrew Savchenko wrote:
> > As I see from git docs only commits and tags may be signed. There
> > is no way to sign a push. Moreover there is no need to sign each
> > commit
in this thread, the best is the enemy of
the good. In no way we should delay git migration due to possible
git review.
Best regards,
Andrew Savchenko
pgpaeQblTgCEP.pgp
Description: PGP signature
boxes can go "Ok, a full build of this will block testing
> everything else for XUNIT time, is this worth it?".
there is no need to increase overhead for developers for a stuff
that can be easily generated: just fill a raw build time (without
ccache/distcc) during test runs the
On Mon, 06 Jul 2015 19:20:14 +0200 hasufell wrote:
> On 07/05/2015 08:05 AM, Andrew Savchenko wrote:
> > On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote:
> >> It's important that the review flow is well-understood and efficient.
> >
> > This is imposs
s://bugs.gentoo.org/show_bug.cgi?id=552388
[3] https://bugs.gentoo.org/show_bug.cgi?id=546260
Best regards,
Andrew Savchenko
pgpC9sdzKQcPH.pgp
Description: PGP signature
gpg-agent should be used; alternatively it may be
allowed to sign already installed packages on a trusted system.
3. Of course backward compatibility with old CONTENTS format should
be kept.
This proposal is not my own whim: I have requests from users for
such functionality which is quite
Hi,
On Fri, 17 Jul 2015 14:22:23 +0400 Jason Zaman wrote:
> On Fri, Jul 17, 2015 at 01:15:53PM +0300, Andrew Savchenko wrote:
> > Hello,
> >
> > TL;DR Is there any tool to build dependency tree for all packages
> > needed to be stabilized (or keyworded) in order stab
, but they require too much maintenance effort: each
update is a pain and quite time consuming and I need such images
only once or twice per year, but still I need them!
In the ideal world it would be nice to have such stage4 ebuilds
available to speed-up initial installation and configuration
process.
Best regards,
Andrew Savchenko
pgpNN4IylEdq1.pgp
Description: PGP signature
ions as it will
suit needs most of the users out-of-the-box. And python3 should be
set as default so that will stick to present, not to the past.
As for people interested in single python version installed only,
they are always free to switch to selected version and drop all
others. It may require rebuild of python-dependent packages of
course, but this is a normal procedure.
Best regards,
Andrew Savchenko
pgpdlKJysWrP_.pgp
Description: PGP signature
and consistency checks.
We already have g-sorcery and other g-* projects. I'm not sure if
haskell uses one. Anyway having mass-updater and consistency
checker as a complementary to these tools will be great.
Best regards,
Andrew Savchenko
pgpTX3gI8uuCf.pgp
Description: PGP signature
On Tue, 21 Jul 2015 08:34:00 + (UTC) Duncan wrote:
> Andrew Savchenko posted on Tue, 21 Jul 2015 03:05:04 +0300 as excerpted:
>
> > occasionally I need a tool to "fast install Gentoo and fine-tune it
> > later". This happens quite often on a new job box,
> >
Hi,
On Tue, 21 Jul 2015 13:52:07 +0400 Jason Zaman wrote:
> On Tue, Jul 21, 2015 at 03:05:04AM +0300, Andrew Savchenko wrote:
> > Maybe a bit off-topic, but occasionally I need a tool to "fast
> > install Gentoo and fine-tune it later". This happens quite often on
>
derivative than any other random distro, right?
Anyway there are many Gentoo derivatives, not only Sabayon.
Probably I should check Calculate too.
Best regards,
Andrew Savchenko
pgpu1Ewl_DazC.pgp
Description: PGP signature
On Tue, 21 Jul 2015 12:14:47 -0400 Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 21/07/15 12:08 PM, Andrew Savchenko wrote:
> > On Tue, 21 Jul 2015 09:10:52 -0500 J.Rutkowski wrote:
> >> The problem I have with using Sabayon to ult
ers are allowed to change
this article, but you can always open a discussion page with
proposed changes[2].
[1] https://wiki.gentoo.org/wiki/Handbook:Main_Page
[2]https://wiki.gentoo.org/index.php?title=Special%3AWhatLinksHere&target=Template%3AInfoBox+talk+open&namespace=561
Best regards,
Andrew Savchenko
pgpKImzQD3Np9.pgp
Description: PGP signature
functionality to the eclass, thus ebuilds can
be simplified. See attached patch.
Comments?
Best regards,
Andrew Savchenko
--- cmake-utils.eclass.orig 2015-02-18 09:31:10.0 +0300
+++ cmake-utils.eclass 2015-07-26 02:14:38.335700364 +0300
@@ -562,6 +562,7 @@
-DCMAKE_INSTALL_DO_STRIP=OFF
rtage instance calling eclass is in PREFIX and
> depends on that — keep it or disable.
This is exactly what proposed patch is doing: it checks if EPREFIX
is empty, and only in such case disables RPATH, otherwise it is
enabled.
Best regards,
Andrew Savchenko
pgpxWsTSTMmsD.pgp
Description: PGP signature
that.
So I propose to add somewhere to devmanual/policies the following
recommendation: "If package supports several versions of the same
technology (e.g. qt4 and qt5) and more than one is enabled by USE
flags, ebuild should prefer the later one (in terms of technology
generation).".
Best regards,
Andrew Savchenko
pgpPTFN6MFtrx.pgp
Description: PGP signature
sers — they will confused by "qt qt4 qt5": "what is
'qt', how is it different from 'qt4' and 'qt5'. What you are really
doing is implementing second-level USE flags, while they were
supposed to be linear.
> However, as you can see QA has previously outvoted the clean policy for
> USE=gtk. I don't see why it would decide otherwise for USE=qt*.
>
> --
> Best regards,
> Michał Górny
Best regards,
Andrew Savchenko
pgpsxPI4QzhzE.pgp
Description: PGP signature
On Sun, 2 Aug 2015 20:35:27 +0200 Michał Górny wrote:
> Dnia 2015-08-02, o godz. 21:21:03
> Andrew Savchenko napisał(a):
>
> > On Sun, 2 Aug 2015 19:27:02 +0200 Michał Górny wrote:
> > > Long story short, this is USE=gtk once again. GNOME team had a
> > > policy
e in there though. need to run
> > a sed on the files to clear it out.
> >
> > it also will include noise where your local checkout was behind the latest
> > tree, so it'll only really work if you ran `cvs up` in the whole tree just
> > before it was shutdown.
>
mit message:
> =
> Stable for amd64, wrt bug #556974
> =
And what is wrong with this? Git allows easily and undoubtedly
show relations between each commit and files affected. This is
_trivial_.
I know, there is a "rule" about '^$cat/$pn:' syntax at present
g browser on URL click.
5. Clicking is less convenient than typing "bugs search $number" —
user have to move hands from a keyboard to a mouse — a terrible
waste of time, at least in my case with my typing speed.
Best regards,
Andrew Savchenko
pgp9XJzgDvj9P.pgp
Description: PGP signature
On Sun, 9 Aug 2015 21:04:35 + Robin H. Johnson wrote:
> On Sun, Aug 09, 2015 at 01:16:19PM +0300, Andrew Savchenko wrote:
> > > Out of curiosity, is it impossible to have a read only CVS server with
> > > the state at the time of the freeze?
> > Seconded here. Read-
bugs search $number" —
> > user have to move hands from a keyboard to a mouse — a terrible
> > waste of time, at least in my case with my typing speed.
>
> You can type the number you see at the end of the URL. If you really
> want to go l33t, that shouldn't
oo. There are tons of ways
> to get to a bug; the important part is the bug number. I think putting
> the URL in there adds extra work for us later down the road should we
> migrate away from Bugzilla.
Same here, but "gentoo $number" in the URL field.
Best regards,
Andrew Savchenko
pgpR_HPHe1iEN.pgp
Description: PGP signature
y much useless data all the same through
> > almost all commit messages.
>
> Which reminds me of the metadata.xml discussion. These days we have
> transparent compression which handles redundant data much better than
> explicit obfuscation, and with much less harm.
I'm not talking about bits on disk (though they matter too), but
more about human being reading them.
Best regards,
Andrew Savchenko
pgp16i0YCp7ll.pgp
Description: PGP signature
gt; >
>
> In fact, this should be the recommended way of running gentoo for
> everyone. Our rsync methods are still inherently insecure (unless I
> missed something), because:
> 1. machine key
> 2. profiles, eclasses and so on are not covered with a
> signature/Manifest an
On Mon, 10 Aug 2015 23:47:21 +0300 Andrew Savchenko wrote:
> On Mon, 10 Aug 2015 22:13:23 +0200 hasufell wrote:
> > On 08/10/2015 05:09 PM, Rich Freeman wrote:
> > > On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert wrote:
> > >>
> > >> Expanding on th
rd, but a draft;
2. not all issues are clear right now (e.g. how to reference bugs);
3. it is not approved by the Council;
4. not everyone agrees with these rules anyway.
Best regards,
Andrew Savchenko
pgpX1D8IcKPzO.pgp
Description: PGP signature
location = metadata/news
> sync-type = git
> sync-uri = https://anongit.gentoo.org/proj/gentoo-news.git
>
> [herds]
> location = metadata/herds.xml
> # or do we want to use git here?
> sync-type = http
> sync-uri = https://api.gentoo.or
efore, it is not
really needed now.
Best regards,
Andrew Savchenko
pgp0tGaNtp_On.pgp
Description: PGP signature
n't like the idea of post-modifying content of
signed commits: files developers committed to the tree should be
the same users get. As a side effect this will simplify tree
consistency checks and forensics.
Best regards,
Andrew Savchenko
pgp6Wh2tmBHb9.pgp
Description: PGP signature
On Fri, 14 Aug 2015 13:16:47 +0200 hasufell wrote:
> On 08/14/2015 01:10 PM, Andrew Savchenko wrote:
> > On Fri, 14 Aug 2015 02:11:09 -0700 Daniel Campbell (zlg) wrote:
> >> I honestly don't see the point of this when `git log` or even `git
> >> diff` or standard `
On Thu, 13 Aug 2015 19:19:10 +0800 Ben de Groot wrote:
> I vote for a simple
>
> Bug: 333531
+1
Of course, for external bugs (e.g. in other projects) full URI
should be used.
Best regards,
Andrew Savchenko
pgpwvJxv7YOQ_.pgp
Description: PGP signature
EAPI 4 deprecation (except
concerns mentioned above), I see no strong need for this also.
Just declare EAPI 5 as recommended. Having legacy support for
EAPI 4 will not hurt possible contributions.
Best regards,
Andrew Savchenko
pgph90LrJq9yy.pgp
Description: PGP signature
On Sat, 15 Aug 2015 08:12:42 +0200 Paweł Hajdan, Jr. wrote:
> On 8/15/15 3:16 AM, Ian Stakenvicius wrote:
> > Secondly, though, conversion to EAPI5 is not actually trivial, there
> > are a couple of things, 'usex' related for instance, that also need
> > to be taken care of. If it was just a matte
gn developer-signed manifest + ChangeLog with releng key. Thus
we'll have double signature for most important files.
Best regards,
Andrew Savchenko
pgpOetqsNBozT.pgp
Description: PGP signature
On Sat, 15 Aug 2015 09:53:37 +0200 Michał Górny wrote:
> Dnia 2015-08-15, o godz. 10:50:02
> Andrew Savchenko napisał(a):
>
> > Hi,
> >
> > On Fri, 14 Aug 2015 10:54:57 -0400 Rich Freeman wrote:
> > > On Fri, Aug 14, 2015 at 8:45 AM, Kristian Fiskerstrand
oking for
> > gpg-signed manifests or other solutions.
>
> I see you talking about introducing whole new bucket of merge
> conflicts.
Where? The only case where such conflict may occur is when several
developers are working on the same package at the same time. This
is quite rare occasion. And even with current thin-manifest
workflow there may be conflict if they touch the same files.
Best regards,
Andrew Savchenko
pgpCgqBC6QLMu.pgp
Description: PGP signature
t repo with historical commits will be
available? Or am I missing something and it is already online?
Having rsync mirrors with up-to-date ChangeLogs will be great too :)
Best regards,
Andrew Savchenko
pgpb83cXTjfMb.pgp
Description: PGP signature
or supporting both GTK2
> and 3, I'll read it. But for now, defaulting IUSE to gtk3 and allowing
> the user to set gtk2 is the best of both worlds imo.
The chromium upstream recommends gtk2, so it should be the default,
even if the GNOME team recommends gtk3.
Best regards,
Andrew Savchenko
pgpQkR30y3SMr.pgp
Description: PGP signature
uoted code
> snippet),
>
> - handling comment edits and removals,
>
> - some people will get double mail for each comment,
>
> - extra bugs for existing issues (we shouldn't really try to reuse
> existing bugs for this).
>
>
>
> What are your thoughts? Any other proposals?
Gentoo workflow should not depend on a proprietary tools like
github issue tracker and github pull requests.
Best regards,
Andrew Savchenko
pgpuRGI1XO4is.pgp
Description: PGP signature
On Sun, 13 Sep 2015 20:21:02 +0200 hasufell wrote:
> On 09/13/2015 07:56 PM, Andrew Savchenko wrote:
> >
> > Gentoo workflow should not depend on a proprietary tools like
> > github issue tracker and github pull requests.
> >
>
> It doesn't. That'
On Sun, 13 Sep 2015 22:13:30 +0100 Ciaran McCreesh wrote:
> On Mon, 14 Sep 2015 00:07:26 +0300
> Andrew Savchenko wrote:
> > On Sun, 13 Sep 2015 20:21:02 +0200 hasufell wrote:
> > > On 09/13/2015 07:56 PM, Andrew Savchenko wrote:
> > > > Gentoo workflow should
On Sun, 13 Sep 2015 20:27:32 +0200 Michał Górny wrote:
> Dnia 2015-09-13, o godz. 20:56:07
> Andrew Savchenko napisał(a):
>
> > On Sat, 12 Sep 2015 21:12:25 +0200 Michał Górny wrote:
> > > Hello, everyone.
> > >
> > > The current workflow for
en facing large-scale blockers. Otherwise one day we
will face nasty bug like mutual heimdal/mit-krb5 blocker[1], where
foo will work only openssl, bar only with libressl and users will
need both.
[1] https://bugs.gentoo.org/show_bug.cgi?id=542462
Best regards,
Andrew Savchenko
pgpmO3NF6ibCV.pgp
Description: PGP signature
will help here: have both qt4 and qt5
versions. Other distributions are being able to handle mit-krb5 and
heidmal on the same system simultaneously, so should we. Situation
with openssl/libressl, ffmpeg/libav and so on is effectively the
same: when we have couples of libraries deliberately incompatible
with each other why sharing pretty much common namespace.
Best regards,
Andrew Savchenko
pgptGoyvixpNt.pgp
Description: PGP signature
hould be stabilized as well and I have a
package which needs this (dev-util/oprofile).
Best regards,
Andrew Savchenko
pgp8B7l3gKCsv.pgp
Description: PGP signature
n't be installed at
the same time. While for now we tend to postpone solution of such
problem, it is only matter of time when we'll face it. Perhaps
static linking for one of the libraries will do the job, despite
it sounds crasy.
Still, we can go ahead and introduce some mechanis
hile they are
indeed not secure, some apps are likely still depend on them.
So it is only matter of time
Best regards,
Andrew Savchenko
pgpam1qYnLi8Y.pgp
Description: PGP signature
On Thu, 1 Oct 2015 09:25:42 -0400 Brian Evans wrote:
> On 9/30/2015 5:40 PM, Andrew Savchenko wrote:
>
> > 2. Some old features are removed:
> > https://en.wikipedia.org/wiki/LibreSSL#Added_features Most notably
> > SSLv3 and MD5 support cancelled, while they are inde
esn't depend on the audit package).
3) sys-apps/policycoreutils implies more than dependency on the
audit package:
Enable support for sys-process/audit and use the audit_*
functions (like audit_getuid instead of getuid())
> "Enable support for sys-process/audit"
>
> which is similar to what most packages use?
Best regards,
Andrew Savchenko
pgpdOUCft25sw.pgp
Description: PGP signature
On Tue, 6 Oct 2015 19:39:42 +0100 Markos Chandras wrote:
> On 10/06/2015 06:58 PM, Andrew Savchenko wrote:
> > Hi,
> >
> > On Tue, 6 Oct 2015 17:32:07 +0100 Markos Chandras wrote:
> >> Hi,
> >>
> >> The following packages currently use the
>
> Yes it is.
No, it is not. The whole git tree is insecure and no better than
rsync or CVS in terms of data security because SHA1 is vulnerable.
What we really need for security is GnuPG-signed tree. Right now we
have only signed commits and pushes. This is work in progress if
und
port stable packages as well, but these
versions are mostly a burden and I can't really understand stable
users.
Best regards,
Andrew Savchenko
pgpVC4orUTzSl.pgp
Description: PGP signature
tl.
>
> Any ideas?
+1. Just do it.
I add /sbin and /usr/sbin in PATH on all Gentoo setups for ages.
Too many useful tools are there. Though, add them after /bin
and /usr/sbin for non-priviledged users and before for root.
Best regards,
Andrew Savchenko
pgpClAaQ6AwxP.pgp
Description: PGP signature
On Fri, 11 Dec 2015 20:18:46 +0100 Gilles Dartiguelongue wrote:
> Le vendredi 11 décembre 2015 à 12:17 +0000, Andrew Savchenko a écrit :
> > commit: fcc5f0fe910ec73b41adf3120255571baf896d4c
> > Author: Andrew Savchenko gentoo org>
> > AuthorDate: Fri Dec 11 12:17:
> ... and why is that not default then.
Best regards,
Andrew Savchenko
pgpaR8EFsY5mi.pgp
Description: PGP signature
nc.
> So, what can we do to make this whole story of 'commit (and push) to
> repo/gentoo.git' make sense? And why do I appear to be the only one to
> notice this chain of breakage?!
We need to complete gkeys project, right? That's not all of the
story, but a start.
On Sun, 13 Dec 2015 16:30:06 -0500 Mike Gilbert wrote:
> On Sun, Dec 13, 2015 at 2:20 PM, Andrew Savchenko wrote:
> >> Since signing is mandatory since the git migration, ahem, this means
> >> that no one in the last 5 months(!) actually followed the documentation
> >&g
ss
> an empty string as the argument to the -d option of the read builtin
> (what actually happens is that in all cases, bash uses the first
> character of the C string that the option gets translated to, which is
> '\0' for the empty string; the documentation just refers to "the first
> character of the string passed").
And the first and the last character of an empty string is '\0'.
So this behaviour is perfectly defined.
Best regards,
Andrew Savchenko
pgpVvedGCgiN8.pgp
Description: PGP signature
g/wiki/Project:Crypto
> >
> >
> > Sounds good to me. I have a passing interest in crypto, so where do
> > I sign? :)
+1
> I'm trying to reclaim the #gentoo-crypto channel for now, would be
> nice to have a place for coordination corresponding to the project
Any progress here?
Best regards,
Andrew Savchenko
pgp9WTbtxbjGA.pgp
Description: PGP signature
e for memory
estimation. Sometimes this is the only way to build package without
cross-compiling. So I propose something like:
CHECKREQS_MEMORY_USE_SWAP="yes|no"
which can be set on command line, in make.conf or in per-package env
setup.
This option should be disabled by default, of course.
Hi,
On Mon, 28 Dec 2015 10:40:26 +0100 Justin Lecher (jlec) wrote:
> On 28/12/15 10:35, Andrew Savchenko wrote:
> > On Mon, 28 Dec 2015 09:43:46 +0100 Justin Lecher wrote:
> >> please review my suggestion to the check-reqs.eclass according to
> >> cleanups and EAPI=6
'FNR == 2 {print $4}')
> + space_megs=$(df -P -B 1048576 "${1}" 2>/dev/null | awk 'FNR == 2 {print
> $4}')
Why not "-BM"? IMHO, this will be more readable, though, of course,
both arguments are semantically correct.
Best regards,
Andrew Savchenko
pgpoKY8IH4uNu.pgp
Description: PGP signature
So phones/tablets are not suitable
for cryptography anyway.
P.S. We had a good discussion of this on core, but still have no
summary on dev ML.
Best regards,
Andrew Savchenko
pgp2cyjAVTb6R.pgp
Description: PGP signature
ugs.gentoo.org/show_bug.cgi?id=398633
> >
> > Can we reconsider implementing this idea perhaps?
> >
>
> Given the thrust of this whole discussion this is a good idea. It
> naturally advertises packages of this unmaintained status to users as
> they emerge.
Please make this optional. Elog already contains too much
information and it is already hard to read logs after world update
or other massive change. It literally takes hours sometimes.
Best regards,
Andrew Savchenko
pgp4AnWCoIzR_.pgp
Description: PGP signature
es.
> > +patches because git does not play well with binary files.
> >
> >
> >
> > --
> > 2.4.10
> >
> >
>
> "Again you should not compress these patches because git does not play well
> binary files".
>
> I'm not sure this statement still holds true with git. Does it?
What about repoman checks? Will it still yell at >20 kB patches?
Best regards,
Andrew Savchenko
pgpmSRbRfXzcf.pgp
Description: PGP signature
s,
this makes sysusers.d stuff an infinite times larger than a
whole typical acct-* package (it will still be much larger if one
will consider size of new passw/group records).
2) acct-* packages are very fast to rebuild, so such price will
be small compared to other changes necessary when USE="systemd" is
being flipped.
So it will be reasonable to add USE="systemd" to acct-* eclasses
to control the changes proposed above.
Best regards,
Andrew Savchenko
pgps8XkbFsi5J.pgp
Description: PGP signature
# Andrew Savchenko (2020-10-11)
# Mask old openafs version and corresponding openafs-kernel with
# multiple CVEs.
# All kernel module functionality is merged back in the single
# net-fs/openafs package using USE="modules" starting from 1.8 branch.
# No reverse dependencies, bug #71913
-trap) and they all explicitly depend on a slotted
> older version of the engine.
1. pygame_sdl2 is ported to python3, so there is no need to remove
it even if renpy will be temporarily gone.
2. It should be possible to keep renpy and games as masked in the
tree, but this will require user
On Sat, 05 Dec 2020 15:47:40 + Marek Szuba wrote:
>
>
> On December 5, 2020 12:31:33 PM UTC, Andrew Savchenko
> wrote:
>
> >Looks like you misunderstood what "Python 3 compatibility mode"
> >means. See official explanation:
> >https://www.ren
# Andrew Savchenko (2020-12-26)
# All docs and socket library functionality are merged back into single
# app-admin/clsync package using USE="apidoc doc socket-library" starting
# from clsync-0.4.5.
# No reverse dependencies. Removal in 30 days.
pgpJZDAZGWp60.pgp
Description: PGP signature
file net-dns/unbound may be a better
replacement. For me a killer feature of pdnsd was the persistent
dns cache, which is very useful on mobile devices. Dnsmasq doesn't
have one, but unbound now has.
Best regards,
Andrew Savchenko
pgp3INGYXBpaV.pgp
Description: PGP signature
On Mon, 13 Dec 2021 09:34:46 +0100 Lars Wendler wrote:
> On Sun, 12 Dec 2021 13:35:20 +0300 Andrew Savchenko wrote:
>
> >On Tue, 7 Dec 2021 15:33:34 +0100 Lars Wendler wrote:
> >> Fails to build with recent kernel headers (bug #801688).
> >> Upstream is gone for a lo
t; + xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-getCC)
> AR=$(tc-getAR)"
OBJDUMP should be exported as well
(e.g. used by scripts/Makefile.build)
> export xmakeopts
> }
>
Best regards,
Andrew Savchenko
pgpodFBDDef4_.pgp
Description: PGP signature
On Thu, 16 Dec 2021 03:32:10 +0300 Andrew Savchenko wrote:
> On Wed, 15 Dec 2021 16:58:26 +0200 Adrian Ratiu wrote:
> > Starting with kernel>=v5.7 the build system can override the
> > tools vars by setting LLVM=1 [1], but older kernels still use
> > the default GNU tools
is to be packaged, see also [1], from the point
> before discussion went off on an X-Y categories tangent.
>
> Here's a list of suggestions made for a new category so far, ordered from
> (seemingly) best- to least-liked:
>
> media-print
> sys-print
> app-print(ing)
IMHO sys-print is the best variant, since printing often requires
system privileges to set it up or change lots of settings.
Best regards,
Andrew Savchenko
pgpCQ1b4x5Cci.pgp
Description: PGP signature
301 - 385 of 385 matches
Mail list logo
