Walter Dnes wrote:
> I seem to remember that Google Chrome used to build with all L10N
> locales disabled. But I just ran a pretend emerge and I got...
>
> www-client/google-chrome [...] L10N="af am ..."
It seems that the use flags default to "on".
> how can I turn it off?
/etc/pportage/pac
Martin Vaeth wrote:
>
> /etc/portage/patches can patch practically everything
> in ebuilds *except metadata*. That's exactly what
> bug 209653 is about.
Typo: I meant /etc/portage/env/*/*
stefan1 wrote:
> On 2023-12-28 15:21, Martin Vaeth wrote:
>> stefan1 wrote:
>>> This got me wondering though, is there no way to fix this globally
>>> via make.conf instead of adding patched ebuilds to my overlay?
>>
>> No. Until https://bugs.ge
Arve Barsnes wrote:
> On Thu, 28 Dec 2023 at 16:21, Martin Vaeth wrote:
>>
>> stefan1 wrote:
>> > This got me wondering though, is there no way to fix this globally
>> > via make.conf instead of adding patched ebuilds to my overlay?
>>
>> No.
stefan1 wrote:
> This got me wondering though, is there no way to fix this globally
> via make.conf instead of adding patched ebuilds to my overlay?
No. Until https://bugs.gentoo.org/209653 is fixed (which did not
happen since 16 years and presumably never will), there is no
other way to fix
stefan1@shitposting.expert wrote:
> I have done the migration to python 3.12.
> The problem is that portage is pulling in python 3.11.
A python version jump in gentoo is always a horrible work:
Many ebuilds have not been updated and pull in unnecessarily
python 3.11. If you use any of these p
Wols Lists wrote:
> So why am I glad my USE= includes "-gnome" :-)
>
> Although I don't use Chrome, so I wouldn't notice anyways :-)
You are wrong: The dependency is unconditional, so USE=-gnome won't help.
What helps is to put a version of virtual/secret-service in your local
repository which d
Dale wrote:
>
> root@fireball / # equery d sys-apps/systemd-utils
> * These packages depend on sys-apps/systemd-utils:
> sys-apps/systemd-tmpfiles-250 (sys-apps/systemd-utils[tmpfiles])
> sys-fs/udev-250 (sys-apps/systemd-utils[udev,...])
> virtual/libudev-232-r7 (!systemd ? sys-apps/systemd-util
Rich Freeman wrote:
> On Sun, Apr 17, 2022 at 3:00 PM Martin Vaeth wrote:
>>
>> Yes, without a manually written grub.cfg you get none of these features -
>> the default grub.cfg is just horrible.
>> Well, the most powerful feature is probably still available:
>
Michael wrote:
> On Sunday, 17 April 2022 17:48:04 BST Martin Vaeth wrote:
>> Michael wrote:
>> > From: Michael
>> >
>> > On Sunday, 17 April 2022 16:52:34 BST Peter Humphrey wrote:
>> >> > Why not try rEFInd? It handles UEFI booting simply,
Peter Humphrey wrote:
> On Sunday, 17 April 2022 16:42:35 -00 Martin Vaeth wrote:
>> Peter Humphrey wrote:
>> > On Sunday, 17 April 2022 14:54:50 -00 Rich Freeman wrote:
>> >> Can't you just fix your USE flags with systemd-utils? Why revert?
>> >
Michael wrote:
> From: Michael
> On Sunday, 17 April 2022 16:52:34 BST Peter Humphrey wrote:
>> > Why not try rEFInd? It handles UEFI booting simply, without the
>> > no-longer-needed bloat of GRUB.
>>
>> Hm. If I'm reading the wiki right, it can't handle choice of run levels with
>> a selected
Peter Humphrey wrote:
> On Sunday, 17 April 2022 14:54:50 -00 Rich Freeman wrote:
>>
>> Can't you just fix your USE flags with systemd-utils? Why revert?
>
> No, because the flag I'd need is 'boot', and that triggers switching from
> elogind to systemd.
No, USE=boot for systemd-util does not tri
Matthias Hanft wrote:
>
> Meanwhile I have found out that the culprit is "virtual/jdk".
No, the “culprit” is that you do not use the binary package openjdk
and you did apparently in the case of icedtea.
Icedtea and openjdk both have cups as a USE-flag, but this influences
only the runtime depend
Neil Bothwick wrote:
>
> In a normal situation, with only one init system installed, there is no
> need to do anything, because the virtual takes care of making sure it is
> not deleted.
It is not only about non-deletion. It is also about updating.
Suppose that you have installed openrc and syste
Grant Edwards wrote:
> On 2021-07-29, Martin Vaeth wrote:
>
>> The handbook contains the instruction how to do this: Put the packages
>> you need into the @world file.
> [...]
>
> Is this documented somewhere in the handbook?
I always supposed that it is document
Rich Freeman wrote:
>
> First, it doesn't sound like qmail actually requires daemontools, but
> simply happens to include a daemontools service config.
My understanding is that qmali contains a "daemon" which does not
daemonize itself. To my knowledge, you can start such a thing
only with daemont
Alan Mackenzie wrote:
>
>> > Less clever people like me follow the handbook, and assume that
>> > packages in @system are protected.
>
>> And they are right to do so. And openrc is not in @system (at least not
>> in the profile which you have chosen), and certainly the handbook does
>> not claim t
Rich Freeman wrote:
> The more I heard on this the more I tend to think that maybe it
> should either not be in that virtual or that it should itself depend
> on openrc/etc, or that qmail shouldn't depend on it.
I strongly disagree. You have the same problem if you have any other
init system inst
Alan Mackenzie wrote:
>
> On Sun, Jul 25, 2021 at 16:18:25 -, Martin Vaeth wrote:
>
>> Portage *cannot* know unless you tell it. The way to tell portage that
>> a package is crucial for *you* is to put it into the world file (or
>> into some set which is in your wor
Neil Bothwick wrote:
>
> It seems that Rich's suggestion has the most merit, add a USE flag to
> daemontools to indicate that it is intended to be your service manager,
> and have the virtual require that flag.
If you want to solve it by a USE-flag, add this flag to
virtual/service-manager. One c
Alan Mackenzie wrote:
> On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote:
>
>> Well, it's not installed on my new system. I doubt it's installed on any
>> new-ish gentoo-gnome systems. So openrc itself can't be critical.
>
> Must you be so objectionably pedantic? It is surely clear that I
Steven Lembark wrote:
> (dev-python/idna-3.1:0/0::gentoo, ebuild scheduled for merge)
> (no parents that aren't satisfied by other packages in this slot)
>
> (dev-python/idna-2.10-r1:0/0::gentoo, ebuild scheduled for merge)
>
Steven Lembark wrote:
: sys-apps/sg3_utils:0
:
: (sys-apps/sg3_utils-1.44:0/0::gentoo, ebuild scheduled for merge) [...]
:
: (sys-apps/sg3_utils-1.42:0/0::gentoo, installed) [...]
: =sys-apps/sg3_utils-1.44 or (permanently)
unmerge sys-apps/rescan-scsi-bus and whatever pulls it in as a
dependenc
Steven Lembark wrote:
>
> # emerge --oneshot sys-apps/portage 2>&1 | tee a;
>
The output of this information is not very useful:
Unsurprisingly, it only shows that update of only the portage
dependencies collides with the dependencies of packages which
are not updated. You should instead try t
Michael Orlitzky wrote:
> On 12/6/20 11:57 AM, Martin Vaeth wrote:
>> Michael Orlitzky wrote:
>>>
>>> Why are you focusing on /tmp and /var/tmp?
>> Because only world-writable directories are the ones which
>> can be exploited unless the tmpfiles.conf
antlists wrote:
> On 06/12/2020 07:55, Martin Vaeth wrote:
>> Dale wrote:
>>> It sounds like a rather rare problem. Maybe even only during boot up.
>
>> It is a non-existent problem on openrc if you clean /tmp and /var/tmp
>> on boot (which you should do if you
Michael Orlitzky wrote:
>
> Why are you focusing on /tmp and /var/tmp?
Because only world-writable directories are the ones which
can be exploited unless the tmpfiles.conf author does
something malevolent or extremely stupid.
> To pick a relevant example
relevant?
> If that was a 'Z' entry, or
Michael wrote:
>
> Given M.Orlitzky's comments and discussions with systemd devs he shared,
> what's the optimal solution for OpenRC users, who want to avoid systemd?
Simply stay with opentmpfiles.
> Rely on ebuild creators and maintainer checks to guard against these inherent
> vulnerabilities?
Dale wrote:
>
> It sounds like a rather rare problem. Maybe even only during boot up.
It is a non-existent problem on openrc if you clean /tmp and /var/tmp
on boot (which you should do if you use opentmp):
The purpose of opentmpfiles is to fill these directories with
certain data during boot, an
Dr Rainer Woitok wrote:
>> ...
>> > I STRONGLY beg to disagree! The "~amd64" notation is used to ACCEPT a
>> > package even though it is (still) classified as UNSTABLE.
>>
>> This is package-manager terminology [...]
>
> No it's USER terminology. It's what users are confronted with when they
Dr Rainer Woitok wrote:
> I STRONGLY beg to disagree! The "~amd64" notation is used to ACCEPT a
> package even though it is (still) classified as UNSTABLE.
This is package-manager terminology which has much less states since
a package manager needs no fine distinctions about the reasons of
ac
Dr Rainer Woitok wrote:
>
> Yes. To satisfy the requirements of package "sys-apps/fwupd" I long ago
> added the line
>
>>=app-crypt/tpm2-tss-2.2.3-r1 ~amd64
Ah! That explains it.
> But this only means that I accept an unstable package here, not that
> these versions are regarded stable
Dr Rainer Woitok wrote:
>
>> ...
>> I exported ARCH="x86_64" and did eix-update, but still:
>>
>> % F=':\n' eix --format '' -e tpm2-tss
>> 2.2.3-r2:
>> 2.3.3:
>
> Did you check with "eix --print ARCH"?
Sure.
> but rather what the command "arch" is returning.
No. It's what it gets from the profi
Dr Rainer Woitok wrote:
>> >app-crypt/tpm2-tss 2.2.3-r21 1
>> >app-crypt/tpm2-tss 2.3.3 1 1
>>
>> This is strange: Both versions are only ~amd64, and in your previous
>> posting the output for {isstable} was indeed 0.
>
> No. It was only 0 in the output of the "instal
Dr Rainer Woitok wrote:
> Martin,
>
> On Monday, 2020-04-20 18:21:00 -, you wrote:
>
>> ...
>> >app-crypt/tpm2-tss 2.3.3 0 1
>> ...
>> The second value depends on your ARCH;
>> Since {isunstable} fails, I suppose that your ARCH is not amd64.
>
>$ eix --dump | grep DE
Dr Rainer Woitok wrote:
> 1. Why do the package properties "isstable" and "!isunstable" differ
>from each other in four out of five output lines?
isstable means that a package is ARCH,
isunstable means that it is ~ARCH (for your ARCH).
For other arches there is isalienstable.
Your partic
Petric Frank wrote:
> I looked inside the perl source archives. Language.pm is missing from
> 5.30.1 whereas it is available in 5.28.2.
This looks like a bug in the perl distribution to me:
man perl5300delta
claims "Locale::Codes has been upgraded from version 3.56 to 3.57." and
man perl5301de
Neil Bothwick wrote:
>
> eix reports USE flags for all versions in the tree
Try eix -l
Neil Bothwick wrote:
> --Sig_/199FZt974m.Ua./7+MHQOSx
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: quoted-printable
>
> On Sat, 06 Oct 2018 18:51:11 -0400, John Covici wrote:
>
>> > With USE=3D"atk-bridge adwaita-icon-theme" this "breakage" will not
>> > happen. =20
>
John Covici wrote:
> [ebuild U #] x11-libs/gtk+-3.24.1:3::mv [3.22.30:3::gentoo]
> prevent the install of the newer gtk+ which breaks some accessibility
> features?
With USE="atk-bridge adwaita-icon-theme" this "breakage" will not happen.
Akater wrote:
>
>> configure:3753: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe
>> -Wl,-O1 -Wl,--as-needed conftest.c >&5
This should succeed. So the problem is probably this:
>> cc1: fatal error: /usr/local/include/stdc-predef.h: Permission denied
It seems that you have this file but that
Peter Humphrey wrote:
> On Friday, 6 July 2018 06:34:01 BST Davyd McColl wrote:
>
>> 1) `sync-depth` has been deprecated (should now use `clone-depth`)
>
> [...] And why is the recent news item referring to instructions
> to use sync-depth?
Things have changed with portage-2.3.42:
sync-depth is a
Rich Freeman wrote:
> emerge --sync works just fine if
> there are uncommitted changes in your repository, whether they are
> indexed or otherwise.
You are right. It seems to be somewhat "random" when git pull
refuses to work and when not. I could not detect a common scheme.
Maybe this has mainly
Rich Freeman wrote:
>> I was speaking about gentoo's git repository, of course
>> (the one which was attacked on github), not about a Frankensteined one
>> with metadata history filling megabytes of disk space unnecessarily.
>> Who has that much disk space to waste?
>
> Doesn't portage create that
Rich Freeman wrote:
> On Sat, Jul 7, 2018 at 1:51 AM Martin Vaeth wrote:
>> Davyd McColl wrote:
>>
>> > I ask because prior to the GitHub incident, I didn't have signature
>> > verification enabled
>>
>> Currently, it is not practical to change
Rich Freeman wrote:
> On Sat, Jul 7, 2018 at 1:34 AM Martin Vaeth wrote:
>>
>> Biggest issue is that git signature happens by the developer who
>> last commited which means that in practice you need dozens/hundreds
>> of keys.
>
> This is untrue. [...]
>
Davyd McColl wrote:
> @Rich: if I understand the process correctly, the same commits are
> pushed to infra and GitHub by the CI bot?
Yes, the repositories are always identical (up to a few seconds delay).
> I ask because prior to the GitHub incident, I didn't have signature
> verification enable
Rich Freeman wrote:
>
> git has the advantage that it can just read the current HEAD and from
> that know exactly what commits are missing, so there is way less
> effort spent figuring out what changed.
I don't know the exact protocol, but I would assume that git is
even more efficient: I would a
Rich Freeman wrote:
>
> Biggest issue with git signature verification is that right now it
> will still do a full pull/checkout before verifying
Biggest issue is that git signature happens by the developer who
last commited which means that in practice you need dozens/hundreds
of keys. No package
Davyd McColl wrote:
>
> 1) `sync-depth` has been deprecated (should now use `clone-depth`)
The reason is that sync-depth was meant to be effective for
every sync, i.e. that with sync-depth=1 the clone should stay shallow.
However, it turned out that this caused frequent/occassional errors
with gi
Klaus Ethgen wrote:
> - - What does that -oss in brackets mean?
It means that it is masked in use.mask or package.use.mask
In your case the file /usr/portage/profiles/default/linux/package.use.mask
explains the reason.
> - - How can I force usage of oss
In your case: Put into /etc/portage/profi
Rich Freeman wrote:
> On Thu, May 10, 2018 at 1:34 AM Martin Vaeth wrote:
>
>> As a simple example, assume that you have read a password file
>> into a string of your language and now access a single password.
>> No matter, how you mark the end of the passwo
Rich Freeman wrote:
> On Wed, May 9, 2018 at 2:18 PM Martin Vaeth wrote:
>
>> Which would be the horribly slow case I mentioned above.
>
> I'm saying that high-level languages can be made safe.
>
> You're saying that making high-level languages safe comes at a
Rich Freeman wrote:
> On Tue, May 8, 2018 at 4:19 AM Martin Vaeth wrote:
>
>> Rich Freeman wrote:
>> >
>> > Higher-level languages will probably become nearly immune to Spectre
> just
>> > as most are nearly immune to buffer overflows.
>
>> Qui
Rich Freeman wrote:
>
> Higher-level languages will probably become nearly immune to Spectre just
> as most are nearly immune to buffer overflows.
Quite the opposite: Higher-level languages *always* do some checks
for array-length etc, and it is the _checks_ which are vulnerable.
You can only mak
James Cloos wrote:
> For eix, I have this in a file in /etc/eixrc/:
>
> BG0=none
> BG1=none
> BG2=none
> BG3=none
If you only use colorscheme 3 you need only BG3=none
> COLORSCHEME0=3
> COLORSCHEME1=3
The former (...0=3) should have no effect at all if your TERM
is recognized by eix as 256-colo
Peter Humphrey wrote:
> On Monday, 2 April 2018 21:50:30 BST Philip Webb wrote:
>> 180402 Dale wrote:
>> > After each period at the end of a sentence, I put in two spaces, not one.
>> > Something I was taught years ago somewhere and still do.
>> > I only put one after a comma tho.
>>
>> That is co
Daniel Frey wrote:
> On 04/02/18 08:21, Ian Zimmerman wrote:
>>
>> BTW, your mails are full of strange space characters
>
> I don't see any extra spaces in Dale's message
After every "." there is a non-breakable space inserted.
I guess this is an attempt of some editor to non-french-space
ASCII t
Bill Kenworthy wrote:
> On 02/04/18 13:41, Martin Vaeth wrote:
>> Bill Kenworthy wrote:
>>> I use the palemoon overlay.
>> There is also the octopus overlay.
>> Anyway, both can only react to upstream.
>>
>>> builds fine with gcc-6.4
>> Yes, bu
Walter Dnes wrote:
> Mind you, the Pale Moon team may not
> have the staffing level required to write a new compiler, maintain a
> politically correct "community", integrate real-time-chat into the
> browser, integrate "Pocket" into the browser, rewrite the GUI every so
> often, yada, yada, yada.
tu...@posteo.de wrote:
> On 04/02 05:41, Martin Vaeth wrote:
>> It seems currently that mozilla, google, and apple are the only
>> oranganizations with enough resources to maintain full browsers,
>> and any forks of their browsers which diverge more than a patchset
>>
Bill Kenworthy wrote:
> I use the palemoon overlay.
There is also the octopus overlay.
Anyway, both can only react to upstream.
> builds fine with gcc-6.4
Yes, but it has random crashes which do not occur with gcc-5,
and as somebody familiar with the code posted somewhere,
the reasons are quite
Ian Zimmerman wrote:
> On 2018-04-01 09:15, Martin Vaeth wrote:
>
>> noscript, ublock-origin, and https-everywhere (maybe for privacy also
>> coupled with decentraleyes, duckduckgo{-privacy-esesntials},
>> canvasblocker, skip-redirect)
I had forgottten to mention: These
Ian Zimmerman wrote:
> On 2018-03-31 08:18, Martin Vaeth wrote:
>
>> As usual, there is the balance
>> "convenience" (old plugins) <-> "security".
>> In the beginning (say, until firefox-52 is no longer supported
>> upstream),
tu...@posteo.de wrote:
>
> There two reasons for which I have switched to waterfox: Privacy and
> memory.
>
> About:config and search for "telemetry"
Telemetry can be switched off.
> Or check how many URLS are configured under about:config.
It is in "about:config", so they can be switched off.
Dale wrote:
>
> I been holding off on upgrading Firefox. Basically, it breaks addons
> that I just can't go without. Tab groups and some other tab utilities
> are among them.
Basically the situation is the following:
>=firefox-57 support so-called WebExtensions which intentionally
are less power
Akater wrote:
> I just tried
>
>> emerge --ask --verbose --update --oneshot x11-base/xorg-proto x11-proto/s=
> crnsaverproto
>
> > (x11-proto/scrnsaverproto-1.2.2-r1:0/0::gentoo, installed) pulled in by
> >x11-proto/scrnsaverproto
It should be scrnsaverproto-1.2.2-r2 which is pulled in.
Mayb
Nikos Chantziaras wrote:
>
> For example, if you don't trust Firefox, don't install Firefox. But you
> *do* trust Firefox. What you don't trust is the JS code Firefox is
> executing.
That's an artificial distinction, because it is actually firefox
which is executing the code during the interpreta
Nikos Chantziaras wrote:
> Yeah, that's the kind of software that benefits from the Spectre
> mitigation patches. Like browsers, virtualization or emulation software,
> the kernel, etc.
No. It's software like gnupg, encfs, openssl and all the library they
use (glibc, glib, X etc) which need these
Nikos Chantziaras wrote:
>
> Well, if you're running a local process that is trying to attack you,
> you've been compromised already, imo.
By your definition, you are compromised if you surf to the
wrong webpage with enabled javascript.
While this is arguably true, I would distinguish between va
Walter Dnes wrote:
> Question: does PIE imply pic/PIC?
The code is somewhat different, but in principle yes.
> I.e does a PIE build also require USE="pic"
Assembler code which breaks pic will also break pie,
so better do not use that code.
> and CFLAGS/CXXFLAGS="-fpic -fPIC"?
These are usua
Adam Carter wrote:
> so why have it if you force it off?
One thing is the ebuild and the other is the profile:
It might be different in a different profile.
David Haller wrote:
>
> Mow is that meson_options.txt
> maintained? Automatically or by hand? If the former: yay!
No, the former would be bad since it would require an
analogue of an "autoreconf" run which is what meson avoids.
> If the latter, treat it as non-existant...
I think you misunderst
David Haller wrote:
> autotools is _by far_the best both from a users and a packagers view.
I do not agree. Its main advantage is that it is compatible with
most existing unix systems (but I am already not so sure whether
this also holds if you also want to compile for windows, powerpc,
etc.)
>
Wolfram Schlich wrote:
> So, you (also) are effectively the maintainer
There was some dispute. It seems that now my requests are ignored:
https://bugs.gentoo.org/628512
Wolfram Schlich wrote:
>
> Use this for a quick fix until it's sorted out upstream:
It is not an upstream issue. You can use the ebuild from the
mv overlay which does not patch the upstream build system.
R0b0t1 wrote:
>
> https://wiki.gentoo.org/wiki/Hardened_Gentoo
>
> The hardened profile still sets PaX and a slew of toolchain options.
Yes. But marking binaries for pax if you don't use a kernel with pax
is pointless. And whether you use the hardened toolchain or a current
gcc with USE="ssp pie"
james wrote:
>
> Hmmm. OK, so I avoid systemd and nepomuk (actually all of KDE) but
> polkit? I try and run a minimized DE environment, but on a workstation,
> I'm constantly evaluating various codes, so how do I avoid polkit?
USE=-policykit obviously helps a lot
> dev-util/sysprof-3.22.2 (gtk
Peter Humphrey wrote:
> On Friday 07 Jul 2017 07:53:01 Martin Vaeth wrote:
>
>> ... my original text was arguing against the claim that the primary
>> purpose of hardened kernels was to protect against untrusted users
>> sitting in front of the keyboard.
>
> It wasn
R0b0t1 wrote:
> On Thu, Jul 6, 2017 at 1:33 AM, Martin Vaeth wrote:
>> Peter Humphrey wrote:
>>> On Tuesday 04 Jul 2017 10:14:23 Martin Vaeth wrote:
>>>>
>>>> With modern browsers and their complexity, you can expect that any
>>>> website (o
Peter Humphrey wrote:
> On Tuesday 04 Jul 2017 10:14:23 Martin Vaeth wrote:
>>
>> With modern browsers and their complexity, you can expect that any
>> website (or the one who has hacked it) can do anything which the
>> user of that browser can do if he is sitting on y
Peter Humphrey wrote:
> hardening is intended
> more for protection against local threats, like someone else
> ssitting in your seat, than anything coming in over the wires.
With modern browsers and their complexity, you can expect that any
website (or the one who has hacked it) can do anything w
Ian Zimmerman wrote:
>
> 1. How does it know which swap device to use as backing store, if any?
My understanding is that zswap is lower level: only in the moment when a
page _would_ be stored, the zswap code is called. That's why activating
zsawp has absolutely no effect if there is no swap devi
Mick wrote:
> Do either of these reduce the effect of (spinning) drive thrashing and
> desktop latency increasing when swapping takes place?
I never made any benchmarks. I just heard that some people are using
the combination of both to avoid swap altogether (or only have an
fallback swap which i
Andrew Savchenko wrote:
> For similar needs I found zswap the most suitable, it's so much
> better than zram:
This sounds like one is an alternative to the other.
This is not the case. It can even make sense to use them together.
For instance, the swap device necessarily required for zswap
can be
Miroslav Rovis wrote:
> Received SIGSEGV - you probably found a bug in eix.
If you are using eix-0.32.7* or eix-0.32.8.alpha* then this is
perhaps this bug:
https://github.com/vaeth/eix/issues/39
> Alan McKinnon | [ebuild N ] dev-cpp/cairomm-1.12.0-r1 USE="svg -X (-aqua) -doc"
>[???]
>| # required by dev-cpp/cairomm-1.12.0-r1::gentoo
>| >=x11-libs/cairo- -X
eix -vle cairomm
???RDEPEND: >=x11-libs/cairo-1.12.10[aqua=,svg=,X=,???
So your selected cairomm[-X] requires cairo[-
Dan Douglas wrote:
>
> However most of these are only metadata/md5-cache files
By default, eix reads its information for the main portage tree
from this directory. Check whether e.g. the portage versions
displayed by eix match which the versions in that directory.
If this is the case (as I suppo
You appear to have experimental CFLAGS. Try without these.
meino.cra...@gmx.de wrote:
>
> Q: How can I direct the emerged NoScript to be
> inserted into PaleMoon Profiles
With correct USE-flags (BROWSER=palemoon) the ebuild
installs noscript into the _system_ directory where palemoon
looks for plugins. No user profiles are touched.
I am not sure how use
meino.cra...@gmx.de wrote:
> Martin Vaeth [17-01-16 18:22]:
>> meino.cra...@gmx.de wrote:
>> > I still cant use NoScript with PaleMoon.
>>
>> Check out the mv overlay: There is a slot working with palemoon.
>
> Did that but cannot determine, what has changed
meino.cra...@gmx.de wrote:
> I still cant use NoScript with PaleMoon.
Check out the mv overlay: There is a slot working with palemoon.
lee wrote:
>
> So the names will not change when rebooting and are to be expected to
> possibly change at any time.
/at any time/when you open the computer and mess around with the hardware/
Your whining in many postings becomes meanwhile unbearable.
Just face the facts:
Unless somebody comes up
meino.cra...@gmx.de wrote:
> sys-apps/systemd required by (virtual/tmpfiles [...]
Probably this is your problem:
You have apparently stabilized the testing virtual/tmpfiles
(or some other package which requires it).
virtual/tmpfiles depends (unless you use systemd) on the unstable
sys-apps/op
Miroslav Rovis wrote:
> Martin Vaeth, I think he works with the ebuilds of Pale moon
No, I don't. I had just reported a few bugs (and suggested
some workarounds).
Helmut Jarausch wrote:
>
> Since the hard drives within theses enclosures have different
> capacities, there is a different ATTR{size} value in the
> block-subsystem.
>
> How can I write to different udev rules to distinguish these two
> external hard disks?
KERNEL=="sd[a-z]*", ATTR{size}=="31...
Jorge Almeida wrote:
> I want to do emerge --sync on computer A and then update computer B by
> copying /usr/portage. Is this safe?
Yes, although ...
> does emerge --sync just updates the contents of /usr/portage
portage also changes the content of /var/cache/edb, and in some
cases even of /var
Jorge Almeida wrote:
> Is there a technical reason for forcing the use of PAM on gentoo?
No. You can use alpine from the mv overlay which has a pam useflag.
Peter Humphrey wrote:
>
> Would it be sensible to use the 44 packages in that @system as a new
> set @sysbase on the main system, or would I miss something important?
Actually, this set is even _larger_ than the @system set which
I got from combining both profiles
default/linux/amd64/13.0/desk
1 - 100 of 207 matches
Mail list logo