Re: [gentoo-user] what gives with -O[x] in cflags?

[Michael Orlitzky]

On 12/15/2017 09:11 PM, R0b0t1 wrote:
> 2) Firefox is the only application I run that crashes, and I don't
> know how to disable -O3 to potentially make it more stable.

Try USE=custom-optimization.

Re: [gentoo-user] what gives with -O[x] in cflags?

[R0b0t1]

On Fri, Dec 15, 2017 at 2:12 PM, Alan Grimes  wrote:
> I did not have -O3 in my cflags because
>
> A> most packages have an appropriate -O level set
> B> Some packages are sensitive to the optimization flag and will
> missbehave if set,
> C> letting the optimization level default to whatever should always be
> safe.
>
> -> therefore I did not have any optimization set...
>
> So therefore webkit-gtk decides to be a prissy little cunt and throws an
> error because it didn't have an optimization flag set, who the hell do
> those developers think they are? If you think you should have an
> optimization flag  SET IT!!! Just provide an override, throwing an error
> just because the user was lazy in compiling it is not acceptable. =|
>

I noticed something similar in Firefox, which from skimming the build
log sets -O3 internally regardless of what the user has set. This is
troubling for two reasons:

1) Gentoo (apparently) has a policy of not allowing packages to mangle
CFLAGS and CXXFLAGS, even with user permission (a useflag of eix was
removed because it set -O3 when enabled).
2) Firefox is the only application I run that crashes, and I don't
know how to disable -O3 to potentially make it more stable.

Cheers,
 R0b0t1

Re: [gentoo-user] list of miscellaneous FAIL

[Neil Bothwick]

On Sat, 16 Dec 2017 00:32:11 +0200, Alan McKinnon wrote:

> Is he the fellow with the weird update script? The one that entertained
> us so much for so long? Plus a total inability to listen to anyone else?

It's not an update script, it's a package manager stress tester, designed
to abuse portage until something starts smoking. Yes, this is that guy,
although I don't recall him being so foul-mouthed in the past.

> On 16 Dec 2017 12:28 AM, "Dale"  wrote:
> > Alan McKinnon wrote:  
> > > Oh ye gods, not this fellow again.
> > >
> > > Fellow gentoo-listers, please I beg you, with all my heart and all
> > > my soul, I beg you:
> > >
> > > Do not feed this troll. Please.
> > >
> > > Alan
> > >
> > >  
> >
> >
> > I mentioned my blacklist the other day in another thread and how it
> > has only one person in it.  It's about to be two.  My grass is
> > growing and I find it more interesting.  lol
> >
> > I wonder how long he will last this time?
> >
> > Dale
> >
> > :-)  :-)
> >
> >  




-- 
Neil Bothwick

Biology is the only science in which multiplication means the same thing
as division.


pgph3VpLu8B1h.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] list of miscellaneous FAIL

[Alan McKinnon]

Is he the fellow with the weird update script? The one that entertained us
so much for so long? Plus a total inability to listen to anyone else?

On 16 Dec 2017 12:28 AM, "Dale"  wrote:

> Alan McKinnon wrote:
> > Oh ye gods, not this fellow again.
> >
> > Fellow gentoo-listers, please I beg you, with all my heart and all my
> > soul, I beg you:
> >
> > Do not feed this troll. Please.
> >
> > Alan
> >
> >
>
>
> I mentioned my blacklist the other day in another thread and how it has
> only one person in it.  It's about to be two.  My grass is growing and I
> find it more interesting.  lol
>
> I wonder how long he will last this time?
>
> Dale
>
> :-)  :-)
>
>

Re: [gentoo-user] list of miscellaneous FAIL

[Dale]

Alan McKinnon wrote:
> Oh ye gods, not this fellow again.
>
> Fellow gentoo-listers, please I beg you, with all my heart and all my
> soul, I beg you:
>
> Do not feed this troll. Please.
>
> Alan
>
>


I mentioned my blacklist the other day in another thread and how it has
only one person in it.  It's about to be two.  My grass is growing and I
find it more interesting.  lol 

I wonder how long he will last this time? 

Dale

:-)  :-) 

[gentoo-user] what gives with -O[x] in cflags?

[Alan Grimes]

I did not have -O3 in my cflags because

A> most packages have an appropriate -O level set
B> Some packages are sensitive to the optimization flag and will
missbehave if set,
C> letting the optimization level default to whatever should always be
safe.

-> therefore I did not have any optimization set...

So therefore webkit-gtk decides to be a prissy little cunt and throws an
error because it didn't have an optimization flag set, who the hell do
those developers think they are? If you think you should have an
optimization flag  SET IT!!! Just provide an override, throwing an error
just because the user was lazy in compiling it is not acceptable. =|


-- 
Please report bounces from this address to a...@numentics.com

Powers are not rights.

Re: [gentoo-user] list of miscellaneous FAIL

[Mick]

On Friday, 15 December 2017 15:10:07 GMT Alan McKinnon wrote:
> Oh ye gods, not this fellow again.
> 
> Fellow gentoo-listers, please I beg you, with all my heart and all my
> soul, I beg you:
> 
> Do not feed this troll. Please.
> 
> Alan

LOL!

Well, he didn't exactly ask a question to expect an answer.  Perhaps he is 
suffering from ADD, ADHD, Asperger's Syndrome and the like, causing him bouts 
of anxiety; for which the mere act of running emerge is unlikely to provide a 
cure.  TBH with the things portage spews back at me at times, I can feel his 
pain!  LOL!

@OP: Do us all a favour and go get yourself a binary distro.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] list of miscellaneous FAIL

[Alan McKinnon]

Oh ye gods, not this fellow again.

Fellow gentoo-listers, please I beg you, with all my heart and all my
soul, I beg you:

Do not feed this troll. Please.

Alan



On 15/12/2017 16:44, Alan Grimes wrote:
> kdeinit:
> 
> over-tight constraint to cmake version:
> 
> ##
> -- Found XCB_XCB: /usr/lib/libxcb.so (found version "1.12")
> -- Found XCB: /usr/lib/libxcb.so (found version "1.12") found
> components:  XCB
> CMake Error at CMakeLists.txt:51 (find_package):
>   Could not find a configuration file for package "KF5KIO" that is
> compatible
>   with requested version "5.41.0".
> 
>   The following configuration files were considered but not accepted:
> 
>     /usr/lib64/cmake/KF5KIO/KF5KIOConfig.cmake, version: 5.40.0
>     /usr/lib/cmake/KF5KIO/KF5KIOConfig.cmake, version: 5.40.0
> 
> 
> 
> -- Configuring incomplete, errors occurred!
> See also
> "/var/tmp/portage/kde-frameworks/kinit-5.41.0/work/kinit-5.41.0_build/CMakeFiles/CMakeOutput.log".
> See also "/var/tmp/portage/kde-frameworks/kinit-5
> #
> 
> also the files symlink in the build path was a reference to itself!!! =P
> 
> 
> Also, the perennial fail, libcdio was giving a more helpful error
> message this time, seems it was looking for a specific libiconv even
> though that library seems to have been folded into glibc
> 
> 
> 
> There is also a new perennial fail, that's very suspicious and worrying,
> ffmpeg... I think it might have to do with relocatable code or
> something, I thought I had disabled that feature and had gotten it to
> work, apparently some pinhead decided to turn it back on thinking 'ooh
> security'.  I'm like look: the only thing I care about is that I can log
> in. =|
> 
> In file included from src/libpostproc/postprocess.c:538:0:
> src/libpostproc/postprocess_template.c: In function ‘dering_MMX2’:
> src/libpostproc/postprocess_template.c:1097:5: error: ‘asm’ operand has
> impossible constraints
>  __asm__ volatile(
>  ^~~
> 
> 


-- 
Alan McKinnon
alan.mckin...@gmail.com

[gentoo-user] list of miscellaneous FAIL

[Alan Grimes]

kdeinit:

over-tight constraint to cmake version:

##
-- Found XCB_XCB: /usr/lib/libxcb.so (found version "1.12")
-- Found XCB: /usr/lib/libxcb.so (found version "1.12") found
components:  XCB
CMake Error at CMakeLists.txt:51 (find_package):
  Could not find a configuration file for package "KF5KIO" that is
compatible
  with requested version "5.41.0".

  The following configuration files were considered but not accepted:

    /usr/lib64/cmake/KF5KIO/KF5KIOConfig.cmake, version: 5.40.0
    /usr/lib/cmake/KF5KIO/KF5KIOConfig.cmake, version: 5.40.0



-- Configuring incomplete, errors occurred!
See also
"/var/tmp/portage/kde-frameworks/kinit-5.41.0/work/kinit-5.41.0_build/CMakeFiles/CMakeOutput.log".
See also "/var/tmp/portage/kde-frameworks/kinit-5
#

also the files symlink in the build path was a reference to itself!!! =P


Also, the perennial fail, libcdio was giving a more helpful error
message this time, seems it was looking for a specific libiconv even
though that library seems to have been folded into glibc



There is also a new perennial fail, that's very suspicious and worrying,
ffmpeg... I think it might have to do with relocatable code or
something, I thought I had disabled that feature and had gotten it to
work, apparently some pinhead decided to turn it back on thinking 'ooh
security'.  I'm like look: the only thing I care about is that I can log
in. =|

In file included from src/libpostproc/postprocess.c:538:0:
src/libpostproc/postprocess_template.c: In function ‘dering_MMX2’:
src/libpostproc/postprocess_template.c:1097:5: error: ‘asm’ operand has
impossible constraints
 __asm__ volatile(
 ^~~


-- 
Please report bounces from this address to a...@numentics.com

Powers are not rights.

Re: [gentoo-user] Can't emerge --sync

[Marc Joliet]

(I've got a bad habit of saving unfinished emails in the drafts folder and then 
forgetting 
about them.  I found this one while cleaning it up and thought it might still 
be informative.)

Am Samstag, 15. Juli 2017, 17:47:18 CEST schrieb Peter Humphrey:
> On Saturday 15 Jul 2017 16:07:26 Marc Joliet wrote:
> > Am Samstag, 15. Juli 2017, 15:11:03 CEST schrieb Peter Humphrey:
> > > On Saturday 15 Jul 2017 12:14:52 Daniel Wagener wrote:
> > > > On Sat, 15 Jul 2017 11:00:01 +0100
> > 
> > > > Peter Humphrey  wrote:
> > [...]
> > 
> > > > Why not just go there and do a "git diff"?
> > > > It will show you what changed – maybe that gives an Idea what happened
> > > 
> > > It showed me that I'd changed "masters =" to "masters = gentoo" in
> > > layout.conf, which I knew because I'd been told to at some time.
> > 
> > That's ridiculous.  You're configuring the main portage tree to be a
> > master of itself.  Search for "masters" in portage(5) for an explanation
> > of what that option is for (it's mainly interesting for overlays).
> 
> Nevertheless, I did only follow an instruction in a Gentoo wiki page. It
> said the change was "for future compatibility" or some such. I wouldn't just
> have made it up for myself.

Hmm, now that you mention it, I vaguely remember something like that.  (Also, 
for a 
better explanation of masters, see [0].)

Searching for it now (longer than I should have), I see it's a warning from 
portage that you 
get when you leave it out completely.

> --->8
> 
> > What probably happened is that this is the first time something changed in
> > layout.conf since you added the "masters" line, thus why git never
> > complained.
> 
> --->8
> 
> > Since git is a version control system, it won't blindly overwrite local
> > changes, so it's best not to make any :) (so don't add that change back
> > in, since it's pointless anyway).  Always use your own overlay if you
> > want to make changes.
> > 
> > HTH
> 
> Yes. Thanks.

[0] https://wiki.gentoo.org/wiki/Repository_format/metadata/layout.conf#masters
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup



signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] SOLVED: NVMe drive and grub

[Marc Joliet]

(I've got a bad habit of saving unfinished emails in the drafts folder and 
then forgetting about them.  I found this one while cleaning it up and thought 
it might still be informative.)

On Tuesday 12 April 2016 10:56:56 Adam Carter wrote:
>> The problem was sys-boot/grub-2.02_beta2-r9, which UEFI never ran.
>> 
>> The fix was to get rid of grub altogether and instead use
>> sys-boot/gummiboot.
>> Not only was it fully functional, it was a welcome relief not to have to
>> grapple with grub's baroque complexity and to be able to return to the
>> simple
>> booting I remember from years ago.
>> 
>> I'd spent five long days wrestling with grub, going round in circles and
>> getting nowhere, before I was pointed to gummiboot.
>
>I also failed to get grub2 + UEFI working. So either;
>1. We're both dummies
>2. The handbook instructions are incorrect and/or inadequate
>
>Can anyone else that is familiar comment on the grub2 + UEFI doc quality?

Poison already gave a more informative reply than I could have , but just to 
give a data point: I have successfully installed GRUB on an old Mac Mini from 
2007 (obtained from a friend).  The main hiccup was that I couldn't get any 
live CDs to boot in EFI mode, so I resorted to grub2-mkimage in order to 
"bootstrap" booting in EFI mode.  Once that was resolved, grub2-install worked 
just fine, as long as I passed --efi-directory=/boot/efi.  I have yet to test 
whether I can boot directly with GRUB or still need refind.

(I was being stubborn and wanted to run what I found out after the fact is 
referred to as mixed mode, which allows a 64 bit kernel to access a 32 bit 
EFI, in which case you *need* a boot loader like GRUB.  BTW, another thing I 
found out afterwards is that Debian apparently has mixed-mode live media 
starting with the Jessie release.)

HTH
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Is gnome becoming obligatory?

[Wols Lists]

On 15/12/17 01:16, Marc Joliet wrote:
> [ Just to be clear: autofs is a Linux kernel feature, systemd just exposes it 
> in an easy to use way.  That is, BTW, a theme with systemd. ]

Likewise, cgroups. I believe Lennart is regularly "blamed" for this, but
it's been in the kernel a looonngg time, long before systemd. Just not
with any easy way of using it.

Cheers,
Wol

Re: [gentoo-user] Re: Is gnome becoming obligatory?

[Neil Bothwick]

On Fri, 15 Dec 2017 07:38:01 +0100, J. Roeleveld wrote:

> > If you "rc-update del" a service, you wouldn't
> > prevent it from being started neither, just because OpenRC is still
> > able to pull it in as a dependency.  
> 
> True, except with OpenRC, all the config is located together. Not
> mostly in / usr/ somewhere with overrides in /etc/...
> I dislike all tools that split their config in this way.

Conversely, I prefer it. The package defaults should be set in /usr, /etc
is for customisation. xorg works the same way with settings
in /etc/overriding those it /usr. It saves cluttering up /etc with tons
of default settings.

However, with both openrc and systemd you don't need to trawl the
filesystems to find the settings, using the provided tools, rc-update and
systemctl in this case, is both preferred and simpler.

One of the benefits, IMO, of systemd, is that it brings a consistency to
operations. In many cases the systemd tools do the same as their
non-systemd equivalents, but they follow a consistent style guide. Of
course, this means that they may work differently to the way you are used
to and there is definitely a learning curve in switching to systemd. I
also didn't discover mask/unmask for a while, only finding it when I was
looking for something else in a man page. Running a mixture of systemd and
openrc boxes, I more often find myself doing thing wrong on the openrc
boxes these days and missing systemd features.


-- 
Neil Bothwick

Puritanism: The haunting fear that someone, somewhere may be happy.


pgpMtTBc5Amwl.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: Is gnome becoming obligatory?

[Kai Krakow]

Am Fri, 15 Dec 2017 07:38:01 +0100 schrieb J. Roeleveld:

> On Friday, December 15, 2017 4:05:41 AM CET Kai Krakow wrote:
>> Am Thu, 14 Dec 2017 08:54:59 +0100 schrieb J. Roeleveld:
>> >> Some historical correctnesses about Canek:
>> >> 
>> >> - He has been here for years - He has contributed here for years -
>> >> He supports systemd and has offered more help and explanation about
>> >> systemd to it's users on this list than any other single person, bar
>> >> none - He has never, not once, slagged off SysV Init, OpenRC or any
>> >> other init system, ot the creators or the users - He has never
>> >> posted rude or inflamatory comments about anyone arguing against him
>> >> - He has never resorted to ad-hominem and never posted any knee jerk
>> >> opinions about any other poster wrt their stance on init systems
>> > 
>> > +1 I may not agree with Canek on all things:
>> > - I do dislike systemd, especially on Centos where disabling services
>> > doesn't always work past a reboot
>> 
>> Well, I think you're falling the pitfall expecting "disable" makes a
>> unit unstartable. That is not the case. Disabling a unit only removes
>> it from the list of units starting on your own intent. It can still be
>> pulled it as a (required) dependency.
> 
> Makes sense
> 
>> If you really want it never being started, you need to mask the unit.
>> It's then no longer visible to the dependency resolver as if it were
>> not installed at all.
> 
> This is not listed anywhere easy to find in google.
> 
>> The verbs disable and enable are arguably a bit misleading, while the
>> verbs mask and unmask are not really obvious. But if you think of it,
>> it actually makes sense.
> 
> Actually, it doesn't. But lets not discuss naming conventions. A lot of
> tools have ones where I fail to see the logic.
> It's a shame that option is not easily findable. And not knowing it
> exists, means checking man-pages and googling for them doesn't happen
> either.
> 
>> If you "rc-update del" a service, you wouldn't prevent it from being
>> started neither, just because OpenRC is still able to pull it in as a
>> dependency.
> 
> True, except with OpenRC, all the config is located together. Not mostly
> in / usr/ somewhere with overrides in /etc/...
> I dislike all tools that split their config in this way.
> 
>> So it's actually not an argument for why you'd dislike systemd. ;-)
> 
> The lack of easily findable documentation on how to stop a service from
> starting, even as a dependency, is a reason. (not singularly against
> systemd).
> Systemd, however, has an alternative.

Maybe it's a point of how you view and understand the underlying 
workings. For me, it was quite obvious that "disable" wouldn't stop a 
unit from starting at all. There's also socket activation, and if a 
socket can still pull in the unit, systemd actually tells you that it can 
be pulled in and you need to disable the socket unit, too.

After all, systemd is meant to automate most of the stuff, thus units are 
pulled in by udev or statically enabled units as needed. If you want to 
disable (and possibly break) some part of functionality, you have to 
pretend it's not there, thus "mask" it from visibility of the dependency 
system. That's also well documented in the man pages and blog articles by 
Lennart - which btw I've read _before_ deploying systemd.

I guess the bigger problem here is transitioning from the old, static, 
non plug-and-play init systems to some new style as systemd provides it. 
Old thinking no longer applies, you have to relearn from scratch. It's 
like driving a car from the 70s and then a modern one: The modern one may 
have extras like breaking assistant, traction control, etc... And when 
this first kicks in, it may come at a surprise. But hey, it's not that 
bad and maybe there are even buttons to disable such functionality - at 
your own risk.

But I agree with you that at first glance it is missing some overview: 
You cannot just look at /etc/systemd to see the full picture. There may 
be vendor enabled units which you don't see there. But "systemd status 
unit-file" will tell you. Actually, I like the fact that installing a 
piece of software also enabled the service I expect to be installed and 
working then. The problem here is more on the distribution side where 
dependencies of packages may pull in packages with services you'd never 
need - just for a small runtime dependency. And I can agree with you that 
it breaks the principle of least surprise then. But it really should be 
fixed by the packagers, not by systemd. Systemd is just the messenger 
here which provides the function of vendor presets.

But, yes, if systemd was installed as part of a distribution upgrade, 
without giving you the chance to read the docs, many things will come at 
a surprise, and there's an overwhelming lot of changes and different and 
unexpected behavior. But is that really systemd's fault?


-- 
Regards,
Kai

Replies to list-only preferred.