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.
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
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.)
>
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
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.
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
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
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:
>
> 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
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
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
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.
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),
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
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
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
>>
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.
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
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
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
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
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
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:
> 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 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
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
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
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
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
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:
> 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. [...]
>
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:
>> 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:
> 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
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
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
Thanasis wrote:
>
> So in /etc/eixrc/00-eixrc I have set
> KEEP_VIRTUALS=true
> REMOTE_DEFAULT=1
With the current default setting of separate databases for the
local eix cache (normally /var/cache/eix/portage.eix) and
for the remote eix cache (/var/cache/eix/remote.eix),
KEEP_VIRTUALS=true makes
Thanasis wrote:
>
> So, if I understand correctly, I _don't_ need any settings, and I should
> remove both KEEP_VIRTUALS and REMOTE_DEFAULT, and just use the -R option
You don't need KEEP_VIRTUALS.
Whether you prefer REMOTE_DEFAULT or not is up to you.
This has nothing to do with the necessity t
Thanasis wrote:
> on 07/10/2013 09:38 AM Martin Vaeth wrote the following:
>>
>> This has nothing to do with the necessity to call "eix-remote add"
>> after eix-sync
With eix-0.29.0 which just entered the tree, eix-sync will
by default do this for you, so you us
pk wrote:
>
> Seriously, boot-critical would be something that the system cannot *boot
> without*, which belongs in /. Everything else should be in /usr, i.e.
> non-boot-critical. How hard is it to start *non-boot* (system) critical
> *after* boot (things like sshd)? I do that today...
For somebo
Michael Orlitzky wrote:
>
> And my counterarguments:
>
> 1. The iptables-restore syntax is uglier and harder to read.
>
> 2. You get better error reporting calling iptables repeatedly.
>
> 3. The published interface will never change; iptables-restore reads an
> input language whose specification
>> 5. You can't script iptables-restore!
>
> Well, actually you can script iptables-restore.
For those who are interested:
net-firewall/firewall-mv from the mv overlay
(available over layman) now provides a separate
firewall-scripted.sh
which can be conveniently used for such scripting.
shawn wilson wrote:
> On Fri, Oct 4, 2013 at 5:58 PM, Michael Orlitzky wrote:
>
>>
>> 1. The iptables-restore syntax is uglier and harder to read.
>
> I don't get this - the syntax is [...]
> What am I missing or how is this uglier?
Argument separation (e.g. if you have arguments with spaces);
i
Michael Orlitzky wrote:
> On 10/13/2013 06:08 AM, Martin Vaeth wrote:
>>>> 5. You can't script iptables-restore!
>>>
>>> Well, actually you can script iptables-restore.
>>
>> For those who are interested:
>> net-firewall/firewall-mv from
Michael Orlitzky wrote:
>>> [...]
>>> If you have a million rules and you need to wipe/reload them all
>>> frequently you're probably doing something wrong to begin with.
>>
>> I don't know how this is related with the discussion.
>> The main advantage of using iptables-restore is avoidance of
>>
Michael Orlitzky wrote:
> Port knocking is cute, but imparts no extra security.
It does, for instance if you use it to protect sshd and
sshd turns out to be vulnerable; remember e.g. the
security disaster with Debian.
> A better, secure way to achieve the same goal is with OpenVPN.
Using yet an
Pandu Poluan wrote:
>
> Thanks, Martin! I was about to create my own preprocessor, but I'll check
> out yours first. If it's what I had planned, may I contribute, too?
Sure, patches are welcome.
William Kenworthy wrote:
>
> If you are going to go to this bother ... why not use shorewall, create
When I checked for scripts creating rules, none fulfilled my needs.
(I do not know whether I checked shorewall at this time).
For instance, instead of dropping most packets, I want to reject them
Michael Orlitzky wrote:
> On 10/14/2013 07:49 AM, Martin Vaeth wrote:
>>
>> Using yet another service with possible holes to protect a sshd?
>> In this case, I would like port knocking at least for this OpenVPN.
>
> The sensitive parts of OpenVPN are audited
Tanstaafl wrote:
>> Like passwords, these sequences should better not stay the same for
>> too long...
>
> Forced changing of passwords
I agreee: To do this to protect *other* users will not work.
It's a different thing if you use it for protection of your own data...
Andreas K. Huettel wrote:
>
> Minor updates (5.x.y -> 5.x.y+1) do not need any rebuilds
> or reinstallations of modules.
This is at most partially correct:
At least, after the update, the install directories change;
here from
/usr/lib/perl5/{vendor_perl,}/5.20.1
to
/usr/lib/perl5/{vendor_perl,}/
Andreas K. Huettel wrote:
>
>> Moreover, I didn't check before the rebuild, but after
>> the rebuild there is no 5.20.1 in @INC.
>
> Sure about this?
I checked this, of course.
But now I realize that the path is *added* to @INC
(even to the perl -V output!) when I re-create it...
walt wrote:
>
> it tries to read from the floppy and prints an error message to the console
No. The kernel does not do this. It is either udev or some other
part of your init system which does this.
> "mount" at a bash prompt, and then spams the screen
> with errors about /dev/fd0.
And again it
meino.cra...@gmx.de wrote:
> A novice asks the master Emerge:
> "Is there Zen also in every upgrade, which will serve to Gentoo?"
Did the novice ask the correct question about the life, the world,
and everything? Your mantra should be
emerge -NaDu @world
(--with-bdeps=y in EMERGE_DEFAULT_OPTS in
Nikos Chantziaras wrote:
>
> Now that 5.1 is in Portage (masked), you should keep in mind that
> emerging it will result in the 5.1 libraries being used, even if you
> keep 4.9 (or 4.8) as the default compiler.
If you should really get problems with this, you can manually
remove the corresponding
Neil Bothwick wrote:
> On Sun, 26 Apr 2015 06:49:09 + (UTC), Martin Vaeth wrote:
>
>> nvidia legacy drivers?
>> In the latter case you are doomed...
>> I also had to throw out recently an nvidia card because of this.
>
> Was nouveau not an option.
No. It seems,
meino.cra...@gmx.de wrote:
> But the same script states:
>
> [I] x11-base/xorg-server
> Available versions: 1.12.4-r4(0/1.12.4) [m]1.15.2-r2(0/1.15.2)
The [m] means that you masked newer versions of xorg-server locally.
If you remove that local mask, the blockers should be gone.
Do you have
Philip Webb wrote:
>
>> If you're willing to wait an hour, it might be able to come up
>> with a list of ways you could resolve a conflict, but basically
>> all of them will be wrong, eg suggestion #1, uninstall everything.
>
> Really, this is a flippant response to a serious issue,
No. It is how
Andrew Savchenko wrote:
>
> That's why kernel makes sure that no floating point instructions
> sneaks in using CFLAGS, you may see a lot of -mno-${intrucion_set}
> flags when running make -V.
So it should be sufficient that the kernel does not use "float"
or "double", shouldn't it?
I can hardly i
James wrote:
>
> So instead of my spew of ascii information files, I'm now composing
> 'man pages' mostly using txt2man.
If you want to avoid learning *roff, there is also e.g. pod from perl
which gives you simple basic markup functionality and can output in
man page format (and other format).
Fo
James wrote:
>
> Pod leaves me with too many choices. Can you narrow it down?
pod (and pod2*) is part of perl. Very likely it is already installed.
man perlpod (or "perldoc pod::perlpod" if the former does not work
on your system).
> eix latex returns too many choices. What is the best one(s) to
hw wrote:
>
> there are quite a few TeX/LaTeX packages available.
emerge texlive with USE=latexextra
> print labels on label printers
texdoc labels
hw wrote:
>> texdoc labels
>
> This seems to be for pre-defined labels like you get them in A4 size?
I have no experience with it; for my purposes a simple manual setting
was always enough. There are of course more (La)TeX packages for labels,
probably most already installed with USE=latexextra.
James wrote:
> This is why I was looking for a 'tool' or script that would allow me
> to easily browse the default package listings for the different
> arch types with a default profile.
If you only want to see the @system set of $PROFILE, use
PORTAGE_PROFILE=/usr/portage/profiles/$PROFILE4 eix
Neil Bothwick wrote:
>
> PORTAGE_PROFILE=/usr/portage/profiles/$PROFILE eix -c --system
>
> The 4 is an interloper.
Yep, a typo: Next key to the E when one finger presses "shift"...
Although once PORTAGE_PROFILE was supposed to become a
variable in make.conf, it seems to not have made it.
eix st
James wrote:
> # PORTAGE_PROFILE=/usr/portage/profiles/arch/arm/armv7a/eapi
This is not a directory. If PORTAGE_PROFILE is not a readable
directory, eix falls back to the symlink
James wrote:
> Martin Vaeth mvath.de> writes:
>
>
>> James tampabay.rr.com> wrote:
>> > # PORTAGE_PROFILE=/usr/portage/profiles/arch/arm/armv7a/eapi
>
>> This is not a directory. [...]
>
> How do I determine [...]
Choose the directory to which you
James wrote:
>
> # PORTAGE_PROFILE=/usr/portage/profiles/arch/arm/armv7a eix -c --system
> No matches found.
Obviously, this profile contains no @system packages.
Which appears natural for an embedded profile...
James wrote:
> There is no dir '/var/portage' on my system. Yet this command works fine:
>
> "PORTAGE_PROFILE=/var/portage/profiles/default/linux/arm/13.0/armv7a eix -c
> --system "
>
> Strange, to say the least.
Not at all strange: Again, PORTAGE_PROFILE points to a non-directory,
so it is ignor
James wrote:
>
> use to match the string against all three:
> (1) gentoo tree /usr/portage
> (2) the /var/lib/layman/ overlays I had installed and manage with layman
> (3) my /usr/local/portage local ebuild placed in /usr/local/portage/
>
> Now, only option (1) shows the embuilds
Very likely yo
Nikos Chantziaras wrote:
>
> I tried it, for exactly 10 seconds. My home/end keys didn't work.
The default configuration is horrible, and they won't change it
since compatibility with stone age and all zsh features switched
off is a design goal of the defaults. I already wrote on their
list that
Neil Bothwick wrote:
> As a
> scripting language, Bash is probably better
This is not true, either: Although finally bash took some of the
features of zsh (arrays, regular expression matching, etc.) there
are still many features missing in bash (extended globbing, many
variable and array operatio
Neil Bothwick wrote:
>
> In one sub-thread we've so far managed to cover:
>
> Bash vs Zsh
> Vim vs Emacs
> Perl vs Python
not to forget: POSIX vs Bash
> What are your thoughts on KDE, kernel modules or USE=3D"-*"? ;-)
Substitute "kernel modules" by Gnome (incl. systemd, policykit) and add
topic
Nikos Chantziaras wrote:
> On 10/07/15 18:00, Gevisz wrote:
>> bindkey '^[[7~' beginning-of-line # Home (xterm)
>> bindkey '^[[8~' end-of-line# End (xterm)
>
> lol... are these guys serious?
>
> It's 2015...
... and yet the way of handling special keys i
cov...@ccs.covici.com wrote:
>
> I cannot see, so I use speakup or orca to read the screen
I have no experience whether zsh is appropriate for this.
Certainly zshrc-mv is not written with this case in mind,
and probably you should refrain from using
zsh-syntax-highlighting or auto-fu-zsh
(The dup
Nikos Chantziaras wrote:
>
> I really don't have time to learn arcane settings anymore.
That's why it is good that you can adapt the shell completely
to your needs: My opinion is that the computer must adapt to
*my* habits and not vice versa.
> If it doesn't work out of the box
I don't see the
Neil Bothwick wrote:
>
> I agree. Being able to customise is good, but the defaults should be
> sensible and appealing to new users.
Yes, but not only new users but also not breaking expectations
of old users are important - it is a subtle balance,
and shells tend to be conservative here (bash is
Andrew Tselischev wrote:
> On Sun, Jul 12, 2015 at 06:52:35PM -0700, walt wrote:
[...]
>> http://wiki.redbrick.dcu.ie/mw/Account_Customisation_(zsh)
Note that this does not activate all features e.g. concerning
completion: You can have files displayed in your custom "ls"
colors in the "selection"
Joerg Schilling wrote:
> Martin Vaeth wrote:
>>
>> This is not true, either: Although finally bash took some of the
>> features of zsh (arrays, regular expression matching, etc.) there
>> are still many features missing in bash (extended globbing, many
>>
Joerg Schilling wrote:
>
> bash vs. POSIX, as bash tried to ignore long existing
> rules just because the bash maintainer did not understand them.
Are there really several? I know only one such example:
bash insists on compound commands ("{ ... }" or "( ... )")
for the function body while accordi
Alon Bar-Lev wrote:
>
> Only issue I could not find a solution to is tab completion after '=',
> for example:
>
> xxx --file=
>
> This will not complete files, while it will be nice if it does.
For standard commands, it works as it should. For instance,
tar --file=
chmod --reference=
dd if=
all
Alon Bar-Lev wrote:
>
> I do not want to write completion for every command out there.
For most commands there already do exist completion functions.
Essentially, it is only your own scripts for which you have
to do it, and this does not take a lot of time when you write
the scripts anyway...
In
meino.cra...@gmx.de wrote:
>
> I took a look at parted and the resize command
Use a
walt wrote:
>
> Oops, journalctl tells me that systemd-networkd is segfaulting
> repeatedly during boot.
systemd has become very picky on cflags; e.g. -DNDEBUG
and friends cause strange behaviour and segfaults.
Helmut Jarausch wrote:
>
> It turned out that something has installed /lib/udev
> while removing the symlink /lib -> /lib64 on my machine.
> Therefore /lib did contains nothing but udev
This sounds like a very serious bug of portage or
of the ebuild; but it did not happen here.
It is probably cor
jfmxl wrote:
> I wrote a coupla days ago, using the guest interface at the website ...
I do not know what you mean by "guest interface".
One right place for your support question would be the
gentoo forum "Installing Gentoo":
https://forums.gentoo.org/viewforum-f-14.html
> but the kernel failed
Michael Orlitzky wrote:
>
> With dynamic deps, portage will scan (that is, execute) all of the
> ebuilds for installed packages that could affect the dependency graph.
This is not correct. This data is already stored in metadata/
(or in /var/cache/edb, depending on the backend),
and just has to b
Rich Freeman wrote:
> There really wasn't much loud objection when the proposal came up
> again last week
This does not mean that everybody agreed.
However, all arguments had been exchanged before,
so repeating them would just have been pointless:
Eventually a decision had to be made, and I am co
James wrote:
>
> Basically from my point of view, something like TUP [1] is needed so
> that at dependency check time you only list files that need
> attention (linking, loading, compiling etc) thus speeding up the
> update processes for the Package Manager (portage).
This is a misunderstanding (
Rich Freeman wrote:
>
> Sure, but the portage team can really only dictate the upstream
> defaults of portage, not tree policy.
As I understand, they intend to remove non-dynamic deps
(if they agreed to not implement it properly for sub-slots,
this makes sense).
So we are not speaking about defa
James wrote:
>[cr
> DAG's
All this can work only if you reflect the complete history
in the DAG. Such approaches had been discussed and eliminated
as unrealistic: You do not want to keep the history forever;
the data will always grow and eventually be too much.
Moreover, there can be overlays whi
wrote:
> Alan Grimes wrote:
>
>> You know that famous Van Gough painting? That kinda haunts you because
>> it's absolutely silent...
>
> "The Scream" is painted by Edvard Munch. Van Gogh (not Gough!) is well
> known for his paintings of sunflowers and cypresses
Doesn't matter in this context:
B
Alan McKinnon wrote:
> On 07/10/2015 18:27, Grant wrote:
>> I have to chown munin:nginx and chmod g+x on directory /run/munin/
>> after every reboot. The munin list suggests altering the initscript
>> but is there a better way?
>
> There are ways, but I wouldn't call them better.
The way to do i
Grant wrote:
>>
>> The way to do it nowadays would be by placing a file with the content
>> d /run/munin 0775 munin nginx
>> into /usr/lib/tmpfiles.d (if done by the distribution) or into
>> /etc/tmpfiles.d (if this is only needed for your special setup).
>
> Will do. Is that leading "d " suppose
Alan Mackenzie wrote:
>!!! /usr/portage/sys-apps/busybox/busybox-.ebuild
>!!! Got: 8493
>!!! Expected: 8580
Do you use the default (rsync) for syncing, or have you changed
the method?
I have the above claimed filesize (8493), but the Manifest
I obtained from rsync is correct.
Th
Neil Bothwick wrote:
>
> I deleted the busybox directory from the tree then ran emerge --sync.
> The error is still there
You have the same files that I have.
Unfortunately, only now I actually did:
$ grep busybox- Manifest
EBUILD busybox-.ebuild 8580 [...]
???
I have the same wrong siz
Simon Thelen wrote:
> I sync from git and none of my Manifests track the ebuilds, so this
> could be a thing.
No. git has (probably, I didn't check)
thin-manifests = true
in its metadata/layout.conf, but for rsync this should
not be the case for security reasons. I double-checked,
and I have inde
cov...@ccs.covici.com wrote:
>
> I have thinmanifests=true as specified in some news item or post, I
> think this was a mandatory change some time ago using rsync.
If you really use rsync/webrsync and not git, this is unlikely:
The file containing this line (metadata/layout.conf) should be
overri
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).
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
1 - 100 of 207 matches
Mail list logo
