Re: [gentoo-user] Why is KDE so bad at multiple monitors?

[Mart Raudsepp]

On Sun, 2024-03-03 at 21:20 +, Michael wrote:
> Pipewire is the new sound server for KDE.  Take a look here in case
> yours 
> needs some tweaking:
> 
> https://wiki.gentoo.org/wiki/PipeWire
> 
> I run on my main desktop with USE="-pulseaudio", but if you have any 
> applications which need pulseaudio you'll need to enable it, if you
> haven't 
> done this already.

You are supposed to have USE="pulseaudio" enabled globally for when you
use PipeWire for audio as well. Using libpulse to talk to the PipeWire
provided compatible daemon is the main way to get audio over to
PipeWire (when ignoring JACK).
Only a few things talk to pipewire directly with it's own API and
PipeWire upstream generally doesn't recommend doing so unless needing
the extra deeply technical things it allows over libpulse API.
If you have it disabled, you are likely using ALSA API, which PipeWire
should also end up handling (like pulseaudio did), but it has much less
features.


Mart

Re: [gentoo-user] tmpfs filling up with nothing

[Mart Raudsepp]

On Wed, 2023-11-08 at 19:08 +, Neil Bothwick wrote:
> On Wed, 8 Nov 2023 16:17:19 +0200, Alan McKinnon wrote:
> 
> > On Wed, Nov 8, 2023 at 4:10 PM Neil Bothwick 
> > wrote:
> > 
> > > I have PORTAGE_TMPDIR on /tmp, which is a 24GB tmpfs. Last night,
> > > an
> > > update failed with an out of space error. df showed only 440MB
> > > free
> > > but du and ndcu both showed well under 1GB in use (including
> > > hidden
> > > files). this has happened on the odd occasion in the past and the
> > > only solution appears to be to reboot. Of course, that means I
> > > cannot
> > > provide any more information until it happens again.
> > > 
> > > Has anyone else experienced this or, hopefully, resolved it
> > > without
> > > rebooting?
> 
> > Hey Neil,
> > 
> > Yeah had this a few times. Always turns out to be deleted files
> > that
> > something still has a handle on
> 
> Hah! I never thought of that one. I'll try that next time it happens.


Another common case is that it runs out of inodes, not space,
especially if df actually says there is free spaces. Check
df -i /tmp
instead then - it might tell IFree is 0 and IUsed and Inodes are the
same non-0 value.
The option for this is:

nr_inodes: The maximum number of inodes for this instance. The default
   is half of the number of your physical RAM pages, or (on a
   machine with highmem) the number of lowmem RAM pages,
   whichever is the lower.

And for me with a 32GB tmpfs, it could have easily hit the default
limit when having e.g. firefox + webkit-gtk + chromium or some such
unpacked and built at once, or one of them failed without cleaning up,
etc.
A value of 0 would disable the limit altogether, but this comes with
the caveat of the possibility of a memory DoS when something malicious
could be writing 0 length files in there, because the size limit
doesn't get hit by it, but tracking the inodes does take some memory
itself and there's no inodes limit to deny that at some point then.
So it might be best to figure out some good value for that, perhaps
e.g. 8 times the default (what you see with your tmpfs size under
Inodes column with `df -i /tmp`).


HTH,
Mart

Re: [gentoo-user] X11 without udev/eudev

[Mart Raudsepp]

Ühel kenal päeval, L, 21.08.2021 kell 23:45, kirjutas Neil Bothwick:
> On Sun, 22 Aug 2021 00:34:32 +0200 (CEST), k...@aspodata.se wrote:
> 
> > > This should have some of the info you need 
> > > https://wiki.gentoo.org/wiki/Old_Fashioned_Gentoo_Install  
> > 
> > Well, I already have such a system, but developments since last
> > year somehow just claims I have to have a lot of (for me) useless
> > processes.
> > 
> > I have tried the overlay route, but since some time I get:
> > 
> >  * ERROR: x11-base/xorg-server-1.18.4::aspo failed (depend phase):
> >  *   xorg-2.eclass could not be found by inherit()
> >  * 
> 
> You need to grab xorg-2.eclass from the git history and put it in
> your
> overlay. Be prepared to repeat this process with other files.

Also be prepared for all the known security vulnerabilities you
reintroduce by installing a heavily outdated xorg-server with multiple
known vulnerabilities.


Mart

Re: [gentoo-user] How to emergency manual install of libffi-compat.

[Mart Raudsepp]

Ühel kenal päeval, L, 21.08.2021 kell 14:01, kirjutas Michael:
> I can't recall coming come across this problem myself, probably
> because I tend to leave emerge updates to finish, or resume from
> where I had stopped an update.  Is this a an error portage should be
> able to deal with itself when an update is interrupted, then
> restarted?

FEATURES="preserve-libs" (default enabled) should have preserved
/usr/lib/libffi.so.7 and it should have been fine enough. Not sure what
happened for him, maybe it has been disabled?


Mart

Re: [gentoo-user] gdm is running Xwayland, what about startx?

[Mart Raudsepp]

Ühel kenal päeval, T, 08.06.2021 kell 18:04, kirjutas Adam Carter:
> I've noticed that my gdm system is running /usr/bin/Xwayland instead of
> /usr/bin/Xorg, so I infer that Gentoo devs, or upstream, are preferring
> it now. 

It isn't really running in Xwayland really, it's running natively with
the Wayland protocol. Xwayland is a by-product of supporting
applications that still use X11 and settings for such applications. gdm
itself does not implement a GUI - it makes use of a login mode of
gnome-shell for that purpose. Future versions of GNOME will be able to
default to running Xwayland on-demand, so in the future you won't see
Xwayland running with just gdm, as no legacy applications are needed.
Right now I believe some accessibility things might need it still in
theory, so it isn't yet always skipped with GDM either.

GDM uses wayland when it can and all the support has been built for
that with USE=wayland on a bunch of packages, including GDM itself.

> Can i try Xwayland with startx?

No, Xwayland isn't something that can really run without a native
Wayland compositor, to my knowledge.
You can read up on what Xwayland is from
https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Compatibility_with_X
and elsewhere through your favorite Internet search engine.

> pstree shows the execution paths as below. Inscrutable to me and
> interesting that they're so different.
> 
> gdm: systemd -> gnome-shell -> Xwayland
> startx: startx -> xinit -> X (AND in parallel) gnome-session -> gnome-
> shell

startx is incapable of running Wayland sessions, so it forces the
legacy Xorg GNOME session, which you'd also get if you explicitly
choose "GNOME on Xorg" from gdm.

One big benefit of having GDM running with Wayland, even if you have to
pick Xorg for your GNOME due to some legacy app not supporting
screencasting portal or something along those lines, is that GDM when
using Wayland is capable of shutting down the gnome-shell it uses when
you aren't on GDM VT (i.e, have logged into a desktop session) and will
start it back up when you go back to GDM VT (i.e, you log out of your
desktop), which is not implemented for Xorg using GDM. This saves on
memory usage, as you don't have a background gnome-shell kept running.
Currently GDM also is incapable of starting Wayland session when it
itself isn't "using" Wayland.


Best,
Mart


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

Re: [gentoo-user] gtk+ package question

[Mart Raudsepp]

Ühel kenal päeval, L, 29.05.2021 kell 16:28, kirjutas Jack:
> I just noticed that the package x11-libs/gtk+ has slots 2 and 3  
> (nothing new there) however, it seems that version 4 has a totally
> new package gui-libs/gtk with only slot 0 (no explicit slot listed)
> with currently ~4.2.0 and 4.2.1 versions available.

They are in SLOT="4"

> I've done a quick  
> search through the announce and dev mailing lists, and not found  
> anything relevant.  Is this an intentional switch?  I don't think
> there  
> is much yet that uses version 4, but is there any planned migration  
> path?

Yes, this is an intentional plan from me, executed by others that had
the time available for it. There were IRC talks and probably some
comments on the relevant bugs.

* I consider it too disruptive to package move everything from x11-
libs/gtk+ to gui-libs/gtk, everyone would need to adapt to it in
overlays, etc
* SLOTs are really nothing more than keeping parallel-installable
packages under the same name, instead of having separate packages like
libgtk2, libgtk3, etc
* New parallel-installable version was a good time to make the switch,
with the old slots left behind in x11-libs until they naturally fall
out of use
* It is increasingly less used with X11, and is still in x11-libs due
to the disruption it would cause to move the existing SLOTs (however
gtk2 is really X11-only)
* Upstream renamed the project from GTK+ to GTK in the gtk4 development
phase
* Separate packages are just as well parallel-installable as separate
SLOTs

So given the above, it felt best to just have the new SLOT under new
package name and not force everyone to do busywork to rename things for
the old slots.

Maybe we can move them over in a couple years without extensive overlay
breakages, when most things are using GTK4, GTK2 has been last rited
and removed and GTK3 is in a similar state of usage like GTK2 is today,
or just leave it be and have it eventually disappear.


Mart


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

Re: [gentoo-user] 4 versions of binutils: requesting confirmation for eselect set

[Mart Raudsepp]

Ühel kenal päeval, E, 15.04.2019 kell 10:40, kirjutas allan gottlieb:
> On one of my machines I see
> 
> gottlieb@E6430 ~ $ eselect binutils list
>  [1] x86_64-pc-linux-gnu-2.28.1 *
>  [2] x86_64-pc-linux-gnu-2.29.1
>  [3] x86_64-pc-linux-gnu-2.30
>  [4] x86_64-pc-linux-gnu-2.31.1
> 
> But I also see
> 
> gottlieb@E6430 ~ $ eix -I -e binutils
> [?] sys-devel/binutils
>  ...
>  (2.28.1) [M]2.28.1
>  (2.29.1) [M]2.29.1-r1
>  (2.30) 2.30-r4
>  (2.31) 2.31.1-r4 ~2.31.1-r5
>  ...
> 
> So I am using a masked version of binutils, which seems bad.
> 
> I presume I should do
>eselect binutils set 4
> 
> I am asking for confirmation since I realize breaking binutils
> is not fun.

Yes, you should be using a newer version. I suggest reviewing your gcc-
config as well; changing that may involve some migration (especially if
very old version by now) or some specific rebuild needs. But binutils
is generally an easy fire and forget switchover.

After a bigger binutils or gcc upgrade (typically different
major.minor) you should usually actually switch to it as well, and if
everything worked out good, you can depclean the older versions (or
keep 1-2 around for safety; or more if you actually need to test older
GCC for some own programming work).


Best,
Mart



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

Re: [gentoo-user] What happened to glsa-check?

[Mart Raudsepp]

Ühel kenal päeval, E, 01.04.2019 kell 20:41, kirjutas Bill Kenworthy:
> > Are there more than one version in use? And why?
> 
> I would guess:
> 
> 1. that the portage version is meant for the internal use of portage
> (hence why its "in an odd spot") and is divorced from the user
> package.
> 
> 2. gentoolkit has the user version as "equery f gentoolkit" shows a
> /usr/bin/symlink.

The portage version is used for implementing the @security set, which I
believe is a dynamic set that pulls in packages that
"glsa-check -l affected" would report too.
It has a glsa-check too, as it was supposed to all be unified in there
eventually, but last I knew, that work has stalled and so there's
almost the same backend code for this both in portage and gentoolkit.

Use glsa-check from gentoolkit for manual calls and know that there is
a @security set available (but research how exactly it works before
relying on it for any security safety.


Mart

Re: [gentoo-user] Default USE flags for net-libs/webkit-gtk

[Mart Raudsepp]

Ühel kenal päeval, R, 09.11.2018 kell 10:59, kirjutas Yongming:
> Hi all,
> 
> I wonder if there is a place to read previous discussions for a
> package/ebuild. Specifically, I am interested in the rationale behind
> having the "geolocation" flag on by default for net-libs/webkit-gtk.
> 
> Currently on a desktop, having "geolocation" pulls in "geoclue"
> (which
> in turn pulls in "modemmanager" and so on), which is seemingly
> unnecessary in my case. I understand that these dependencies can be
> customised via /etc/portage/package.use/*, but I am also curious
> about
> the thinking behind net-libs/webkit-gtk having "geolocation" flag on
> by default.

We were asked this off-list. Now catching up, it seems that didn't
reach the list too, so here's belated information to others as well:

geolocation is a browser engine feature that is expected to be built by
default. Yes, it very likely also is default enabled by upstream, but
we also want to provide an out of the box good experience for browsers
built on top of webkit-gtk (such as epiphany and midori), which means
working geolocation support. Thus the default remains.

However, based on that query, we instead ended up removing the default
enabling of USE=modemmanager from geoclue itself. As a result, 
odemmanager is not pulled in anymore for webkit-gtk without user making
that choice via enabling USE=modemmanager due to actually having a
modem (think 4G mobile modems, not the dial-up kind).


Mart

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

Re: [gentoo-user] ACCESS DENIED

[Mart Raudsepp]

Ühel kenal päeval, K, 19.09.2018 kell 16:35, kirjutas Helmut Jarausch:
> Hi,
> I wonder what I am doing wrong.
> For several packages, e.g.   x11-terms/kitty-0.12.1
> I get access violations like
> 
>   * ACCESS DENIED:  mkdir:/root/.config/kitty
> 
> The cause of this is clear:  emerge is running as user/group
> 'portage'  
> but
> ls -ld  /root/.config
> gives
> drwx-- 15 root portage 4096 Sep 19 14:20 /root/.config
> 
> One could change the permission of this folder, but there are
> several applications which use this folder.
> 
> What am I missing?

kitty ebuild is missing a call to gnome_environment_reset, or at least
xdg_environment_reset. If that is not done (and the ebuild isn't EAPI7
and something in the build ends up using XDG standards), then you could
hit issues like this. Most often when you become root in a way that
keeps user settings.
To avoid this, you should consider using "su -" instead of "su" to
become root; or the equivalent in case of other methods (though sudo by
default does this and needs an extra argument to keep the env vars).

However this is also technicall a bug in the ebuild, as discussed
above, and such things should be tracked on bugzilla, if a particular
packages case already isn't.


Mart

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

Re: [gentoo-user] wxPython/wxWidgets release number mismatch

[Mart Raudsepp]

Ühel kenal päeval, K, 19.09.2018 kell 08:58, kirjutas David Haller:
> Hello,
> 
> On Wed, 19 Sep 2018, Andrew Udvare wrote:
> > Curiosity: what is the reason for wxGTK:3.0 and wxGTK:3.0-gtk3 ?
> 
> wxGTK:3.0 uses gtk+-2 and wxGTK:3.0-gtk3 uses gtk+-3.

That, and we couldn't do it with just flipping it to gtk3 in 3.0 SLOT,
because some wxWidgets apps could be doing conditional direct GTK+ code
as well, to go above the lowest common denominator toolkit support that
wxWidgets provides. Or some might just be wrongly linking directly to
gtk2 explicitly. Or had too much trouble with gtk3 in the less used
parts of wxGTK while wxGTK gtk3 support hadn't quite matured yet.
You can't have a program load in (link to) both gtk2 and gtk3 - it will
abort to not go completely runtime crazy and crash due to same function
names. Kind of like wxWidgets itself aborts if the library and app are
using different C++ ABI (however that's less of a problem with todays
relevant C++ ABI updates, unlike the gcc4 to 5 days).
Therefore it was just a separate parallel installable SLOT with which
we could move things over gradually and have the more maintained apps
benefit before everything is working with it.


Mart

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

Re: [gentoo-user] Re: wxPython/wxWidgets release number mismatch

[Mart Raudsepp]

Ühel kenal päeval, E, 17.09.2018 kell 19:02, kirjutas Andrew Udvare:
> On 9/17/18 5:02 PM, Grant Edwards wrote:
> > 
> > It wants to re-install wxpython-3.0.2.0, wxGTK-3.04 and
> > wxGTK-304-r300.  I've already done that a few times, but I answered
> > 'y' anyway and let it reinstall them again.  It didn't help:
> > 
> > $ python -c "import wx"
> > 
> > /usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py:16629:
> > UserWarning: wxPython/wxWidgets release number mismatch
> >   warnings.warn("wxPython/wxWidgets release number mismatch")
> > 
> 
> It needs to be version bumped. https://bugs.gentoo.org/632602

To my knowledge then that would also mean porting the program to it, as
it's a complete python bindings rewrite. Though the python API might be
quite the same compared to wxpython-3.0.2 with some exceptions and thus
maybe not a huge work.
For Gentoo it is of course quite a bit more "fun" when now all of a
sudden "import wx" could be either wxpython-3 or wxpython-4, even after
you get them installed in parallel in a separate SLOT without file
collisions. And that's why I still haven't even looked at this huge
bunch of needed work and testing. (more people want newer gnome right
now..)

> The current version of wxPython is actually 4.0.x and is not
> compatible
> with wxGTK 3.0.4.

I'm quite sure that is not true - wxPython 4.0.x README says it works
fine with wxWidgets 3.0, or more specifically wxGTK-3.0.4.

> wxGTK needs to be bumped as well
> https://bugs.gentoo.org/577030 but there are some breaking changes in
> 3.1 vs 3.0.

And 3.1 is ABI unstable development release, and we distributions
aren't fond of them.
Latest stable wxWidgets is 3.0.4, and we are up to date there with
wxGTK.

> wxPython 3.0.2.0 is considered 'classic' and was released in 2014.
> 
> I tried to use a virtualenv with system package access and tried `pip
> install wxpython` but the oldest sane version you can go back to
> 4.0.3
> which won't build with 3.0.4 version of wxGTK.
> 
> This discrepancy between the two does not look like it will be fixed
> any
> time soon.

It's just a warning from the times wxpython was released more or less
in tandem with wxWidgets. When their wxpython-4 worked progressed far,
they stopped doing that, and that old warning now apparently hits. But
all it is, is a warning. It'd be more of a problem if it ended up using
wxGTK-3.1 or a future 3.2. But wxGTK-3.0.4 is just bug fixes over
3.0.2, plus some new API and tiny careful backwards compatible ABI
changes (via ELF symbol versioning, etc). It should be fine as-is.
There might be value in relaxing that warning with a downstream patch,
but personally I'd rather save that time and work on wxpython-4
instead.

Yes, it'd be nice if we had wxpython-4. Help welcome. Also help welcome
in having wxpython-3 use wxGTK:3.0-gtk3 or have a separate SLOT for
that itself as well.

wxGTK-3.1 however is of debatable value due to development series and
ABI instability combined with a C++ ABI world. Most upstream developers
seem to ship their own wx things static linked into their stuff, so
don't seem to understand the needs of Linux distributions, or just
basic good release management. I am tired of trying to have that
improved by upstream - I've tried for ~14 years now, including while
being an upstream developer myself for wxGTK over a decade ago.

I realize that some programs want to use the new features already, but
we are in the business of building a stable distribution, not throw all
development releases and the caveats from that in front of everyone,
even when manpower is lacking for even the stable versions as-is.


Mart,
wxWidgets legacy Gentoo maintainer, hoping for a replacement..

Re: [gentoo-user] What's wrong with 4.16.X?

[Mart Raudsepp]

Ühel kenal päeval, L, 04.08.2018 kell 13:52, kirjutas Konstantinos
Agouros:
> Hi,
> 
> I have a Ryzen system running, so I used 4.16 as a few features are
> only
> available there. Using ~amd64 for newer versions. Why is non ~ stuck
> with 4.14 
> now?
> 
> As 4.16 is already removed from gentoo-sources I am kind of stuck
> with a 
> non existing package.

4.14 is the LTS (long term support) kernel, thus that will have stable
keywords only.
4.16 is EOL (end of life) and doesn't receive fixes anymore, so it was
removed from the main tree.
4.17 is the new non-LTS series that still receives updates, so you
probably want to upgrade to that, if you don't want to downgrade (or
can't due to suboptimal Ryzen support there). In that case you want to
upgrade to new series in a timely manner until at least a new LTS
appears - then you could stick to that one instead (stable versions).

See the nomenclature also on https://www.kernel.org/


Mart

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

Re: [gentoo-user] All Gentoo signing key expired and no way to fix it

[Mart Raudsepp]

Ühel kenal päeval, T, 03.07.2018 kell 14:00, kirjutas gevisz:
> Are you, by any chance, running this command through something like
> > lxc-attach or ssh?
> > I had the exact same problem two days ago and it turned out to be
> > something about the
> > environment being passed to the remote system. Sourcing
> > /etc/profile did the trick.
> 
> No, I do it on my desktop staying just in front of me.
> So, no need for ssh (and I do not know what lxc-attach is at all).
> 
> Still, sourcing /etc/profile somehow helped:

How do you obtain root privileges for the command?

If you use su, you should be using "su -" (or "su -l" or "su --login"), 
not "su".

If you use sudo, you might need to pass -i (--login) option to it.

And I mean that in general, not just for overcoming this error.


Mart

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

Re: [gentoo-user] Re: Hostile takeover of our github mirror. Don't use ebuild from there until new warning!

[Mart Raudsepp]

Ühel kenal päeval, L, 30.06.2018 kell 15:33, kirjutas Rich Freeman:
> On Sat, Jun 30, 2018 at 12:50 PM Nikos Chantziaras 
> wrote:
> > 
> > On 30/06/18 19:15, Rich Freeman wrote:
> > > 
> > > If you are using git syncing I believe that portage will verify
> > > that
> > > the top commit (which is the only one that really matters) is
> > > using a
> > > trusted key if you put the following line in repos.conf for the
> > > repository:
> > > sync-git-verify-commit-signature = true
> > > 
> > > Obviously this only works with repositories signed by one of the
> > > Gentoo keys.
> > 
> > When using git to sync portage, aren't you supposed to use:
> > 
> >git://anongit.gentoo.org/repo/sync/gentoo.git
> > 
> > anyway instead of GitHub?
> > 
> 
> A few comments there:
> 
> 1.  That particular repository isn't ideal since it lacks metadata.
> You'll benefit from the better performance of git vs rsync, but
> you'll
> lose out regenerating the cache.  It is of course the right place to
> pull for patches/etc.
> 2.  The gentoo-mirror stable branch that benefits from CI+metadata
> isn't available on Gentoo infra as far as I'm aware.

That repo/sync/gentoo.git is EXACTLY that. Same thing as gentoo-mirror
on GH. Has metadata cache and is pushed only to if CI passes.
I think the underlying setup just pushes to both gentoo-mirror and
there now.

Note the /sync/ in path, it's not the main tree devs push to.


Mart

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

Re: [gentoo-user] [SOLVED] webkit-gtk-2.18.6 failed (compile phase)

[Mart Raudsepp]

Sorry for some thread gravediggery, but thought to share my webkit-gtk
maintainer experience on this.

Ühel kenal päeval, N, 15.03.2018 kell 14:57, kirjutas thelma@sys-
concept.com:
> On 03/15/2018 12:29 PM, Neil Bothwick wrote:
> > On Thu, 15 Mar 2018 11:40:13 -0400, Walter Dnes wrote:
> > 
> > > > ninja: build stopped: subcommand failed.
> > > >  * ERROR: net-libs/webkit-gtk-2.18.6::gentoo failed (compile
> > > > phase):
> > > >  *   ninja -v -j5 -l8 failed  
> > > 
> > >   One option that sometimes cures mysterious failures is to do
> > > the build
> > > with...
> > > MAKEOPTS="-j1"
> > >Yes, the build takes longer, but it may actually
> > > build.  Remember to
> > > set the option back to normal value after experimenting.
> > 
> > You can set it on the command line for that build only
> > 
> > MAKEOPTS="-j1" emerge whatever
> > 
> > I too find that it can help builds that otherwise fail, even when
> > it
> > doesn't, the make output gives a better idea of the failure point
> > when
> > parallel builds are not cluttering it up.
> > 
> > If the build log is that big, either compress it or just post the
> > last
> > 100 lines. The error message you posted doesn't really say much
> > more than
> > "it broke".
> 
> Thanks Walter and Neil,  Yes, that was the case not enough RAM,
> MAKEOPTS="-j1" fixed the problem.
> 
> Though, it was slw.  On Intel Quad core CPU and 4MB of RAM it
> took
> over 7-hours to compile it.
> I guess I need more RAM.

-j1 is probably too low. I think -j3 or so (maybe even -j4 instead of
-j5) would have worked for you too.

I don't know what's up exactly, but it seems like some parts of the
memory used in the build process is marked as not swappable. If you
have a higher -j, then it doesn't fit it all (the individual file
compiles can be quite memory hungry with C++ and webkit) and the kernel
just OOM kills one of the parallel processes and the whole build will
fail.

The confusing part here is as I said - sometimes swap doesn't even help
at all. Of course if you have no swap or not enough swap, it's even
more likely to die with high -j MAKEOPTS.

webkit-gtk-2.20 will be using the rough equivalent of chromium jumbo-
build unconditionally. We shall see how that will effect it all; I
suspect even lower -j might be needed to fit it all in RAM in
constrained situations.


Mart

Re: [gentoo-user] Firefox 57.0.4 fails to build due to Rust 1.23

[Mart Raudsepp]

On Sat, 2018-01-27 at 18:17 +, Richard Bradfield wrote:
> Hi folks,
> 
> Forgive me if this has been spotted elsewhere, it's not in this list
> yet
> as far as I can see.
> 
> The excellent work to bring the version of Rust in ~amd64 up to date
> has
> had an unfortunate side effect, in that it now prevents Firefox from
> building. Firefox appears to only supports Rust 1.19 and no later.
> 
> I get a failure in one of the Rust components, as the build converts
> warnings to errors, and an import is now unused in 1.23 as it's now
> implicitly in scope, according to this thread [1]
> 
> I know this is only a minor point release, but I was hoping to update
> for the SPECTRE mitigations.
> 
> Has anyone patched this themselves, or do I need to think about
> rolling
> the system rust back to 1.19?
> 
> Emerge build log is attached, it's a bit noisy around the errors
> sadly.
> 
> 
> [1] https://www.reddit.com/r/rust/comments/7rjvfu/this_is_why_you_sho
> uld_not_treat_warnings_as/

This is https://bugs.gentoo.org/645718

Hopefully the problem just goes away with firefox 58, which is
available in mozilla overlay and should get to main tree soon (last I
heard some build tests were still running before introduction to main
tree).
Though if warnings are treated as errors still there too, then it'll
hit again at some point, I guess, unless that bit is solved for good.

Re: [gentoo-user] Using both Gnome and KDE Plasma?

[Mart Raudsepp]

On Thu, 2018-01-25 at 19:24 +, Neil Bothwick wrote:
> On Thu, 25 Jan 2018 18:52:34 +0200, Mart Raudsepp wrote:
> 
> > That said, the global USE flag manual copy to make.conf might get
> > outdated; e.g. we plan to add USE=wayland as global default to
> > gnome
> > profile at some point soon(tm). 
> 
> Could you source it from make.conf rather than copying the contents?
> That
> way you'll keep up with the profile changes.

Not sure, probably not a good idea, but the next sentence that you cut
from the reply gave an (untested) option right there in that e-mail...

Re: [gentoo-user] Using both Gnome and KDE Plasma?

[Mart Raudsepp]

On Thu, 2018-01-25 at 18:48 +0200, Mart Raudsepp wrote:
> On Thu, 2018-01-25 at 01:16 +0200, Nikos Chantziaras wrote:
> > One user wants Gnome, the other wants Plasma. Is this doable?
> > 
> > Currently, Plasma is installed, and the profile is:
> > 
> >    default/linux/amd64/17.0/desktop/plasma/systemd
> > 
> > The profiles seem to be either-or. There's one for plasma, one for 
> > gnome. But I need both now :-/
> 
> They just provide ease of installation by enabling some USE flags
> globally or per-package for you, to avoid having to add them manually
> on a fresh install or so.
> 
> You can create a local mix-in by having /etc/portage/make.profile as
> a
> directory with an eapi and parent file, but that has some caveats, so
> given that I leave the details to find out elsewhere when desired.
> Or you can just use one and add the stuff for the other manually,
> verbatim or as-needed.
> What they do can be seen in
> profiles/targets/desktop/gnome
> profiles/targets/desktop/plasma
> subdirectories of your PORTDIR (probably /usr/portage/)
> 
> The global USE flags each adds are in make.defaults file and the per-
> package USE flag tweaks are in package.use files.
> 
> So you could for example keep using the systemd plasma profile, add
> the
> global USE flags from
> /usr/portage/profiles/targets/desktop/gnome/make.defaults to your
> make.conf and symlink
> /usr/portage/profiles/targets/desktop/gnome/package.use to a
> gnome.use
> file under /etc/portage/package.use/ directory or so and voilà, you
> got
> effectively both.

That said, the global USE flag manual copy to make.conf might get
outdated; e.g. we plan to add USE=wayland as global default to gnome
profile at some point soon(tm). Though make.defaults could be symlinked
as well, I think to /etc/portage/profile/make.defaults
Though these changes are rare, and it's a convenience anyways, e.g. you
might have decided to globally enable wayland earlier already; or once
the change is made you might counter it with a global disable in
make.conf anyways.

Re: [gentoo-user] Using both Gnome and KDE Plasma?

[Mart Raudsepp]

On Thu, 2018-01-25 at 01:16 +0200, Nikos Chantziaras wrote:
> One user wants Gnome, the other wants Plasma. Is this doable?
> 
> Currently, Plasma is installed, and the profile is:
> 
>    default/linux/amd64/17.0/desktop/plasma/systemd
> 
> The profiles seem to be either-or. There's one for plasma, one for 
> gnome. But I need both now :-/

They just provide ease of installation by enabling some USE flags
globally or per-package for you, to avoid having to add them manually
on a fresh install or so.

You can create a local mix-in by having /etc/portage/make.profile as a
directory with an eapi and parent file, but that has some caveats, so
given that I leave the details to find out elsewhere when desired.
Or you can just use one and add the stuff for the other manually,
verbatim or as-needed.
What they do can be seen in
profiles/targets/desktop/gnome
profiles/targets/desktop/plasma
subdirectories of your PORTDIR (probably /usr/portage/)

The global USE flags each adds are in make.defaults file and the per-
package USE flag tweaks are in package.use files.

So you could for example keep using the systemd plasma profile, add the
global USE flags from
/usr/portage/profiles/targets/desktop/gnome/make.defaults to your
make.conf and symlink
/usr/portage/profiles/targets/desktop/gnome/package.use to a gnome.use
file under /etc/portage/package.use/ directory or so and voilà, you got
effectively both.

Re: [gentoo-user] Questions about Pale Moon

[Mart Raudsepp]

On Wed, 2018-01-24 at 16:30 +, Peter Humphrey wrote:
> On Tuesday, 23 January 2018 12:08:12 GMT Arve Barsnes wrote:
> 
> > Maybe check command line output?
> 
> I get eight of these: "undefined symbol: UCNV_TO_U_CALLBACK_STOP".
> The full 
> list is attached.

> (pale moon:2395): Gtk-WARNING **: Error loading theme icon 'go-
> previous' for stock: Unable to load image-loading module:
> /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so:
> /usr/lib64/libxml2.so.2: undefined symbol: UCNV_TO_U_CALLBACK_STOP

Your libxml2 appears broken after some ICU update and no automatic
rebuild of libxml2 or something (maybe something failed in the rebuilds
earlier in the queue from what portage figured has to get rebuilt after
icu upgrade). Rebuild libxml2 and that issue probably goes away.

Re: [gentoo-user] Re: emerge @preserved-rebuild failure

[Mart Raudsepp]

On Sat, 2018-01-06 at 23:42 +0200, zless wrote:
> În ziua de sâmbătă, 6 ianuarie 2018, la 23:25:32 EET, Hartmut Figge a
> scris:
> > zless:
> > > Could you also take a look at the file
> > > /var/lib/portage/preserved_libs_registry ?
> > 
> > hafi@i5-64 ~ $ cat /var/lib/portage/preserved_libs_registry
> > {
> > "sys-libs/readline:0": [
> > "sys-libs/readline-7.0_p3",
> > "10658",
> > [
> > "/lib64/libreadline.so.6.3",
> > "/lib64/libreadline.so.6"
> > ]
> > ]
> > 
> 
> To me this reads as readline-7.0_p3 depends on libs from readline-
> 6.3.
> 
> Smells a bit as some sort of bug. Try rebuilding readline?
> 
> This didn't happen here when readline was bumped.

This is no bug here. It's just storing the fact that it preserved these
/lib64/libreadline.so.6{,.3} under the replacing newer version package.
That is, readline-7.0_p3 now owns these files, but based on this
registry, they will be deleted and removed from its CONTENTS, once
there are no more consumers of it based on essentially NEEDED.ELF.2
contents in the VDB (/var/db/pkg/*/*/NEEDED.ELF.2).
That is, what is keeping them from being removed is not stored in this
registry.

> > > It's like this when there are no preserved libs:
> > > 
> > > # cat preserved_libs_registry
> > 
> > I'm currently running 'find . -name '*preserved*' on / in the hope
> > of
> > finding the set with the preserverd libs *g* Well, I will let it
> > continue.

Maybe there is just an old ruby:2.1 SLOT installed, that hasn't been
properly depcleaned?


Mart

Re: [gentoo-user] LINGUAS make.conf variable being ignored?

[Mart Raudsepp]

On Fri, 2018-01-05 at 18:53 +, Grant Edwards wrote:
> I haven't changed LINGUAS or L10N for ages, but I've noticed that
> suddely other packages are being rebuild without linguas_en and
> linguas_en_us.
> 
> Is make.conf's LINGUAS variable no longer being expanded?

Correct.
See https://bugs.gentoo.org/643598
and maybe https://bugs.gentoo.org/643682#c1 for a more technically
explained temporary workaround to not lose language during this
(hopefully rather short) final transition period.

> How do you show the complete set of use flags including expanded
> ones?

LINGUAS is not expanded anymore.

Re: [gentoo-user] Emerging media-sound/supercollider fails with"multilib-strict check failed!"

[Mart Raudsepp]

On Tue, 2018-01-02 at 09:18 -0800, Jigme Datse Yli-RAsku wrote:
> I'm not sure where best to address this, so for now I am starting
> here.
> I'd like to have this addressed, and be able to emerge it without
> disabling "multilib-strict" as it seems that this has been enabled
> because these packages are going to end up hard failing before too
> long.
> 
> Is there a good way to end up reporting these kinds of things?  I
> really
> wish this (and other packages which might have this problem)
> fixed.  If
> this isn't the right place to put this, could someone tell me where,
> and
> if I need other information?

File a bug on bugzilla, but in this case, there exists one already:

https://bugs.gentoo.org/628362

But I see supercollider does not currently have a Gentoo maintainer, so
you might want to consider proxy-maintaining it or something.

It has a fix suggestion on the bug already, no idea if that's the best
approach though.

Re: [gentoo-user] segfault in gedit / glib

[Mart Raudsepp]

On Sun, 2017-12-31 at 09:47 +1100, Adam Carter wrote:
> * Install gdb if it isn't already installed
> > * Make sure a core file is presend in coredumpd, coredumpctl should
> > show; if not, have it crash again so it's fresh and saved in there
> > 
> > * coredumpctl gdb gedit
> > 
> > * bt full
> > 
> > Post output of that "bt full"
> > 
> > 
> 
> (gdb) bt full
> #0  0x7f60cd333a74 in g_main_context_prepare () from
> /usr/lib64/libglib-2.0.so.0
> No symbol table info available.
> #1  0x7f60cd33449b in ?? () from /usr/lib64/libglib-2.0.so.0
> No symbol table info available.
> #2  0x7f60cd334693 in g_main_context_iteration () from
> /usr/lib64/libglib-2.0.so.0
> No symbol table info available.
> #3  0x7f60d047676a in g_application_run () from
> /usr/lib64/libgio-2.0.so.0
> No symbol table info available.
> #4  0x563890d41d59 in main ()
> No symbol table info available.
> 
> FWIW I have -fomit-frame-pointer set - should i rebuild glib & gedit
> with that or some other options changed?

-fomit-frame-pointer is the default on x86_64/amd64 in most situations.
-fno-omit-frame-pointer might help, but usually that's useful for
sample based profiling (like sysprof), which can't spend time unwinding
the traces with more complex ways during sample collection.
Here you already actually have the full backtrace available, even most
symbol names, so it could already unwind it. Best to have full debug
symbols then with CFLAGS including e.g -ggdb and FEATURES having
"splitdebug compressdebug". This can be done per-package, but if
there's disk space available for /usr/lib64/debug (could also be a
symlink to an always mounted data disk), it doesn't hurt to just always
have it enabled for all. Well, it does hurt compilation time a bit, and
a lot for big packages like chromium/webkit-gtk, for which this could
then be disabled instead. Anyhow, up to you how much you enable. For
this backtrace, dev-libs/glib is the one of interest.

That said, this looks really weird place to crash, and I doubt there's
threads going on with it unable to show the correct one.
t a a b f would make sure instead of bt full (the former is short for
thread apply all backtrace full, so the same as bt full, but will show
all threads, not current only).
I'm not sure debug information for the backtrace will help much, but
debug symbols + some more gdb usage than just getting the trace might
help.

Mart

Re: [gentoo-user] segfault in gedit / glib

[Mart Raudsepp]

On Sat, 2017-12-30 at 11:58 +1100, Adam Carter wrote:
> > The segfault message would exist in the dmesg/journalctl.  Please
> > open a user shell in Gnome and type "gedit ", substituting a
> > text file for .  Press enter.  Does this segfault and if so
> > is there anything else printed?
> >  
> > 
> 
> The journalctl message is;
> Dec 29 12:17:32 phat kernel: gedit[1177]: segfault at 7f7c0d36e880 ip
> 7f7c2550ba74 sp 7fff66834850 error 4 in libglib-
> 2.0.so.0.5200.3[7f7c254c+114000]
> 
> the gedit  message is;
> Segmentation fault (core dumped)

* Install gdb if it isn't already installed

* Make sure a core file is presend in coredumpd, coredumpctl should
show; if not, have it crash again so it's fresh and saved in there

* coredumpctl gdb gedit

* bt full

Post output of that "bt full"


Mart

Re: [gentoo-user] Re: How to resume 'emerge -e @world' after grub fails?

[Mart Raudsepp]

On K, 2017-12-20 at 17:28 -0600, Dale wrote:
> Grant Edwards wrote:
> > On 2017-12-18, Grant Edwards  wrote:
> > > On 2017-12-18, John Blinka  wrote:
> > > > On Mon, Dec 18, 2017 at 11:00 AM, Grant Edwards
> > > >  wrote:
> > > > 
> > > > > How do I skip grub and continue?
> > > > emerge --skipfirst --resume
> > [...]
> > 
> > > Oddly, the failing package (grub:0) wasn't the first one: it was
> > > about
> > > 5-6 packags down the list.  So I used --exclude instead.  We'll
> > > see
> > > how far that gets...
> > It took a couple days, but after "resuming" the emerge three times,
> > it
> > finished.  The three failures were grub:0, matplotlib, and crrcsim.
> > 
> > Each time the failed package was around 5th on the list when I did
> > a
> > resume.  And, each time emerge insisted on rebuilding gcc and glibc
> > first.  [I don't remember what else preceded the failed packages
> > when
> > I did the resumes.]
> > 
> > I think I'll postpone upgrading to profile 17 on my "real work"
> > computers where I have a lot more packages installed.
> > 
> 
> 
> I'm not sure why or what all this involves but there is a thread on
> -dev
> about a 17.1 profile coming at some point.  One may want to consider
> waiting to do to much for that.  Some of the messages make it seem to
> be
> a really large process to upgrade to it.  I'm hoping some or even
> most
> of it is just the devs testing things.  o_O
> 
> Just a thought. 

It's about making /usr/lib not be a symlink to lib64 anymore on amd64.

I wouldn't wait for it, could get complicated and messy to do both at
once. If 17.1 pans out (or well, maybe "18.0" when going out of
experimental testing phase next year..), it won't need a full rebuild,
at most only things that have /usr/lib/ entries (instead of /usr/lib64
or /usr/lib32) in portage CONTENTS file in VDB to fix those things up
after the migration tool.

And I don't see anything overeager in --depclean. Maybe a dependency
was removed later, so with still default "--dynamic-deps y" you get
them removed now. If this breaks something, then there's an automagic
dep involved (which should have a bug report and be fixed), or some
changes done to some ebuild without proper revbump.
I think --with-bdeps toggling might let it remove build-time only deps,
though. I didn't observe that being used in the thread here in a way
that lets these build-time only deps get removed, for that to be it.

Re: [gentoo-user] cross compiling arm with 17 profiles.

[Mart Raudsepp]

On P, 2017-12-17 at 16:50 +0800, Bill Kenworthy wrote:
> Something I cant figure out:
> 
> ARM is still on the 13 profiles - should an amd64 system used to
> cross
> compile for arm (Raspberry Pi's) be left on the 13 profiles or 17
> will
> work fine?

ARM profiles are delayed to potentially fix CHOSTs together with the
profile update. Though no-one is actively doing the work to my
knowledge right now.

I guess it could cause trouble from default PIE vs no PIE from native
compiler, but I don't know enough about that field to know for sure.

If you pay attention to any future CHOST changes and handle them
yourself at the right time, you could manually choose the appropriate
17.0 arm profile as your symlink (it doesn't show up in eselect profile
due to no profiles.desc entry, but should be there in profiles/). If
changes are done, you might be caught a bit off-guard though at the
time they are done though and I'm not sure what the effects of that
would be either (probably not too bad).

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

[Mart Raudsepp]

On P, 2017-12-10 at 08:56 +, Jorge Almeida wrote:
> On Sun, Dec 10, 2017 at 6:12 AM, R0b0t1  wrote:
> > On Sat, Dec 9, 2017 at 5:36 PM, Peter Humphrey  > uk> wrote:
> > > On Saturday, 9 December 2017 12:00:12 GMT Jorge Almeida wrote:
> > > > On Sat, Dec 9, 2017 at 10:45 AM, Mick  > > > m> wrote:
> > > > > Thank you all for detailed and clear replies.  You'd forgive
> > > > > me for
> > > > > being (a little) paranoid about Poettering's fingers getting
> > > > > anywhere
> > > > > near my systems.>
> > > > > :-p
> > > > 
> > > > Are you sure you need udisks? And policykit?
> > > 
> > > I'm pretty sure Mick runs KDE, which requires both of those.
> > > 
> > 
> > Eventually emerging @world will just pull in the entirety of the
> > Gentoo package repository, and we won't have to worry about what is
> > or
> > isn't necessary.
> > 
> Not that I would object much to have gnome-common if I needed it (I
> don't), but it is a bit
> shocking that installing kde stuff pulls gnome stuff. After all,
> they're supposed to be alternative worldviews, er, desktop
> environments. Maybe the relevant people should stop and think whether
> unbridled complexity is a good idea?

So you are suggesting that each desktop environment must NIH
everything?

Want an auto-mounter and disk monitor and more for a modern desktop
experience - reimplement udisks.
Want a secure permissions handling framework for the desktop -
reimplement polkit.
Want a user account service handler for desktop logins - reimplement
accountsservice.
Want color profiles handling for monitors and co, and other associated
stuff - reimplement colord.
And so on.

That's all "GNOME stuff" by your definition, with GNOME Foundation
members being the project leaders or starters.

Meanwhile gnome-common is just a package for m4 macros for the older
autotools using world, and is deprecated in favor of autoconf-archive,
which had the good things of gnome-common integrated into it. Please
remove that package too, if you want to NIH.


People, this is open source. Stop advocating NIH and make use of the
benefits of open source and let the people actually doing stuff
collaborate on things and re-use/share projects as they see fit, for
less time waste and more making GNU/Linux (desktops) great over the
proprietary others.

Re: [gentoo-user] net-wireless/blueman-2.1_alpha2 blocked by net-wireless/gnome-bluetooth - is it necessary?

[Mart Raudsepp]

On R, 2017-12-08 at 19:39 +0700, Vadim A. Misbakh-Soloviov wrote:
> > 
> > Is it really necessary to block one package when another installed?
> 
> Most of the time, the reason to make packages to block each other is 
> collisions (if they they contain files (like binaries or libraries)
> with same 
> install paths).
> 
> Although, I can't guarantee that it was the case here.

There was a blocker in blueman against gnome-bluetooth due to a file
collision with gnome-bluetooth. This was removed with 2.0-r1, back in
Oct 2015, as blueman upstream solved it.
To me it looks like the change didn't make it to the live ebuild and
then eventually sometime after 2.0.3 a bump was made via copying from
, not the latest version, thus reinstating the blocker, possibly by
accident. Or maybe on purpose, but I don't see an explanation for it in
logs.
Try to remove the blocker in blueman, see if files collide or not, and
if not file a bug against blueman, possibly with info that it might
have been accidental reintroduction due to..., etc.

> I've noticed that Gnome Team makes some decisions, that doesn't looks
> logical 
> for a few times already.

Something not looking logical for you doesn't mean there isn't sound
logic. In this case, it's not us who have a blocker possibly wrongly
reintroduced here.


Best,
Mart Raudsepp
Gentoo GNOME team lead

Re: [gentoo-user] Re: memset_s

[Mart Raudsepp]

On E, 2017-11-13 at 12:44 +0200, Nikos Chantziaras wrote:
> On 13/11/17 09:17, Jorge Almeida wrote:
> > 
> > On Sun, Nov 12, 2017 at 7:03 PM, Mart Raudsepp <l...@gentoo.org>
> > wrote:
> > > 
> > > On L, 2017-11-11 at 00:10 +, Jorge Almeida wrote:
> > > > 
> > > > Well, most programmers probably won't care about this stuff
> > > > anyway,
> > > > and people who deal with cryptography tend to be more cautious
> > > > than
> > > > average. But I'm not really making a case for safe versions of
> > > > known
> > > > functions. After all, the usual functions do fine for most
> > > > applications. memset() would be enough to clear RAM with
> > > > sensitive
> > > > data if we had a pragma (or equivalent) to convince the
> > > > compiler to
> > > > not ignore it (I mean a pragma to invoke on a particular
> > > > function
> > > > definition when the programmer  feels that a black box
> > > > behaviour is
> > > > undesirable). Of course, solving the problem of the compiler
> > > > copying
> > > > stuff around might be harder nut to crack.
> > > Sounds like you want explicit_bzero from libbsd?
> > > 
> > According to their man page, yes. I'll have to [try to] check the
> > source. I wonder how they do it? Even the volatile modifier doesn't
> > solve the problem, according to the link in previous post.
> explicit_bzero() is available in glibc. It's in .

Interesting. Some Xorg stuff is using libbsd explicitly, but probably
since before glibc gained this. This is new since glibc-2.25.

How they do it you can find out from the source code. In libbsd case, I
saw a weak linked (do-nothing) function call after memset, so the
compiler can't know if that weakly linked function isn't getting
replaced with something that might do something with the zeroed memory,
and thus can't optimize it out. Though I looked at an older libbsd.

Re: [gentoo-user] memset_s

[Mart Raudsepp]

On L, 2017-11-11 at 00:10 +, Jorge Almeida wrote:
> Well, most programmers probably won't care about this stuff anyway,
> and people who deal with cryptography tend to be more cautious than
> average. But I'm not really making a case for safe versions of known
> functions. After all, the usual functions do fine for most
> applications. memset() would be enough to clear RAM with sensitive
> data if we had a pragma (or equivalent) to convince the compiler to
> not ignore it (I mean a pragma to invoke on a particular function
> definition when the programmer  feels that a black box behaviour is
> undesirable). Of course, solving the problem of the compiler copying
> stuff around might be harder nut to crack.

Sounds like you want explicit_bzero from libbsd?

Re: [gentoo-user] Re: High resolution on a 13 inch screen

[Mart Raudsepp]

Ühel kenal päeval, R, 01.09.2017 kell 10:16, kirjutas Grant:
> > My laptop's 13" screen has a native resolution of 3200x1800 which
> > makes everything crazy small on-screen.  Is there a good method for
> > telling Xorg or xfce4 to compensate, or should I one-at-a-time my
> > applications?  I can adjust the resolution down but it makes the
> > colors look weird.
> 
> 
> After some more research, it turns out this is a pretty well-known
> problem on the Linux desktop (it's called HiDPI) without a good
> solution... except for this:
> 
> https://forums.linuxmint.com/viewtopic.php?t=159064
> https://bugs.freedesktop.org/show_bug.cgi?id=94816
> 
> The solution is to patch xrandr with the capability to do nearest
> neighbor filtering and run xrandr like this:
> 
> xrandr --output eDP1 --mode "3200x1800" --scale "0.5x0.5"
> 
> It works great.
> 

I don't see how it can be called great. This is pretty much losing most
of the benefits you have with a HiDPI screen, by just making it be
almost the same as a 1600x900 screen, except the scaling involves some
nearest neighbor filtering, which sometimes might be good, sometimes
bad, and never as good as rendering things in HiDPI.

For HiDPI you want the toolkit to support it properly and configure it
as such. GTK+3 is such a toolkit, but outside of GNOME (where it works
out of the box), I don't know what exactly it takes to set things up.
Plus you'll need a solution for your gtk2/whatever other things,
preferably one that doesn't make things worse for gtk3 things, like
that xrandr hack does.

Probably something like
gsettings set org.gnome.desktop.interface scaling-factor 2
combined with something for the other stuff that doesn't mess with the
former.
Outside GNOME, maybe exporting GDK_SCALE=2 works, if the dconf setting
isn't honored outside it.


Mart

Re: [gentoo-user] Re: chromium 60 build failure

[Mart Raudsepp]

Ühel kenal päeval, E, 31.07.2017 kell 21:00, kirjutas Grant Edwards:
> On 2017-07-31, Mateusz Lenik  wrote:
> > On Mon, Jul 31, 2017 at 08:02:34PM +, Grant Edwards wrote:
> > > ../../third_party/vulkan-validation-
> > > layers/src/loader/debug_report.c:50:5: 
> > > note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to 
> > > compile your code
> > > ../../third_party/vulkan-validation-
> > > layers/src/loader/debug_report.c: In function
> > > ‘util_CreateDebugReportCallbacks’:
> > > ../../third_party/vulkan-validation-
> > > layers/src/loader/debug_report.c:235:5: error: ‘for’ loop initial
> > > declarations are only allowed in C99 or C11 mode
> > 
> > Most likely gcc-4.9 defaults to older C standard (C89, I guess).
> > The easiest way to solve this would be to update your gcc to 5.4, 
> 
> One of these days when I have the time...
> 
> > otherwise you'd have to pass one of the suggested flags to the
> > compiler somehow.
> 
> Aren't required gcc versions and/or flags supposed to be specified
> in the ebuild?

Compilers are not specified in the ebuild, as the dependency doesn't
mean anything - you might have the old still as the selected one. Which
you do, which is your problem.
Most that could be done is doing a gcc version check early on, as to
not wait all this time until the failure before it exits with failure.

Everyone is expected to be on at least GCC 5 now.

There were some migration things for C++ ABI from GCC 4 to GCC 5
upgrade, but actually that wasn't so much a thing to do on gcc-config
switch of compiler, but immediately after GCC 5 install, as libstdc++
symlink isn't controlled by gcc-config afair.

Re: [gentoo-user] Clickless screenshot...how?

[Mart Raudsepp]

Ühel kenal päeval, L, 29.07.2017 kell 12:58, kirjutas R0b0t1:
> On Sat, Jul 29, 2017 at 11:17 AM, Mart Raudsepp <l...@gentoo.org>
> wrote:
> > Ühel kenal päeval, L, 29.07.2017 kell 13:20, kirjutas tuxic@posteo.
> > de:
> > > The task is already accomplished :) with a mixture of WM-based
> > > hotkey definitions and a delayed commandline utility (main,scrot,
> > > imagemagick).
> > > Addtionally I dont think that my X11 uses framebuffer (not shure
> > > about that, though)...
> > 
> > Those tools work by using an inherent X11 security hole by reading
> > out
> > the root window, it's not relevant to framebuffer in the kernel
> > sense.
> > 
> > Note that you can't use a global shortcut key in X11 while a
> > typical
> > right click context menu is open, because these take a X11 grab and
> > even screen lock can't activate.. Then only the delay approach will
> > work (if desired then together with a shortcut if the shortcut key
> > is
> > hit before opening the context menu). Fortunately in this case you
> > only
> > wanted a dropdown in firefox, which isn't implemented like that.
> > This popup menu problem is solved with Wayland (most importantly
> > the
> > not screenlocking aspect of it), but so is the root window security
> > hole, so the compositor/WM needs to take the screenshot and tools
> > like
> > import/scrot won't work.
> > 
> 
> I'm not really sure it is fair to call that a security problem. It's
> intentional, and that is because there are plenty of things that need
> access to the whole desktop at once. E.g. automating anything that
> doesn't expose a development API or have an accessibility API can
> pretty much only be done by scraping the contents of the screen -
> these programs simply don't work in Wayland? That seems like a
> misfeature.

I'm calling things as they are.
It is intentional only to the point of it not having been a concern
back in the 1980s during X11 protocol designing.

Any program running under the user can see the whole contents of their
screen - not just their own; that's how these screenshotters work too,
but it's easy to think of more nefarious use cases.

Any program running under the user can listen to all key events meant
for any other X application - that's how global shortcuts from random
daemons or whatnot work (instead of DE provided hooks). It is trivial
to write a key snooper.

Now yes, this is local issues, so hopefully you are good on remote
access issues, but if not, it might be game over for your terminal
entered ssh passwords or whatever. There exist some mitigation
techniques in the form of some non-standard X modules and other means,
but they are usually not used and also can break such non-nefarious
tools that make use of these aspects.
Due to it being local (unless you for some reason enable TCP for X.org
or something...) you can probably not worry about it too much, but it
doesn't change the fact that they are security issues to the core of
X.org, carried over from the 1980s.


To solve these things in Wayland, there are cross-desktop protocols
being specified to achieve these in a more arbitrated, correct and
secure manner. There is proper isolation between applications.

Re: [gentoo-user] Clickless screenshot...how?

[Mart Raudsepp]

Ühel kenal päeval, L, 29.07.2017 kell 13:20, kirjutas tu...@posteo.de:
> The task is already accomplished :) with a mixture of WM-based
> hotkey definitions and a delayed commandline utility (main,scrot,
> imagemagick).
> Addtionally I dont think that my X11 uses framebuffer (not shure
> about that, though)...

Those tools work by using an inherent X11 security hole by reading out
the root window, it's not relevant to framebuffer in the kernel sense.

Note that you can't use a global shortcut key in X11 while a typical
right click context menu is open, because these take a X11 grab and
even screen lock can't activate.. Then only the delay approach will
work (if desired then together with a shortcut if the shortcut key is
hit before opening the context menu). Fortunately in this case you only
wanted a dropdown in firefox, which isn't implemented like that.
This popup menu problem is solved with Wayland (most importantly the
not screenlocking aspect of it), but so is the root window security
hole, so the compositor/WM needs to take the screenshot and tools like
import/scrot won't work.

Re: [gentoo-user] USE_EXPAND

[Mart Raudsepp]

Ühel kenal päeval, R, 21.07.2017 kell 10:30, kirjutas Mick:
> Where is the best place to put USE_EXPAND flags?  In
> /etc/portage/make.conf, 
> or in some other file, e.g. /etc/portage/env//

/etc/portage/package.use (file or a file in that as a directory)

The syntax is like this:

dev-python/foo PYTHON_TARGETS: python3_6 # Add python3.6 support

It also supports wildcard, so you can do this for all with just
*/* USE_EXPAND_NAME: my choices
or if you want to force things, overriding profiles:
*/* USE_EXPAND_NAME: -* my choices

Re: [gentoo-user] Firefox - LINGUAS value en_GB is not enabled using L10N use flags

[Mart Raudsepp]

Ühel kenal päeval, R, 21.07.2017 kell 05:31, kirjutas wabe:
> Stroller  wrote:
> 
> > When emerging Firefox the warning "LINGUAS value en_GB is not
> > enabled
> > using L10N use flags" is twice shown.
> > 
> > Is there anything I can or should do about this?
> > 
> > The only uncommented lines in /etc/locale.gen are:
> > 
> >   en_GB.UTF-8
> > UTF-8 en_GB ISO-8859-1
> > 
> > And in /etc/portage/make.conf I have:
> > 
> >   LINGUAS="en_GB en"
> >   L10N="en_GB en"
> 
> Shouldn't it be en-GB and not en_GB?

Yes, it should be en-GB in L10N, but stay en_GB in LINGUAS.
That doesn't mean the warning will necessarily go away, but L10N is
purely a USE_EXPAND flag thing, and there exists no en_GB there (see
profiles/desc/l10n.desc).
Warning might be harmless after you fix that thing up.


Mart

Re: [gentoo-user] Bluetooth head phone

[Mart Raudsepp]

Ühel kenal päeval, T, 18.07.2017 kell 17:54, kirjutas Raphael MD:
> >On Tue, Jul 18, 2017 at 12:40 AM, Mart Raudsepp <l...@gentoo.org>
> wrote:
> >Ühel kenal päeval, E, 17.07.2017 kell 12:10, kirjutas Raphael MD:
> 
> >emerge --info pulseaudio please? Especially the "was built with the
> >following USE flags" part
> 
> Here is: https://pastebin.com/64Rbb9t0​

Ok, that's then:
USE="X alsa alsa-plugin asyncns bluetooth caps dbus gdbm glib gnome gtk
ipv6 orc qt4 ssl tcpd udev webrtc-aec -doc -equalizer -jack (-libressl) 
-libsamplerate -lirc -native-headset (-neon) -ofono-headset (-oss)
-realtime (-selinux) -sox (-system-wide) -systemd -test -zeroconf"
ABI_X86="32 64 -x32"

I've also found https://wiki.archlinux.org/index.php/Bluetooth_headset#
A2DP_profile_is_unavailable like another subthread, so that might be
one part to care about, to not hit that while testing other things to
get to work.
Please also give a try to USE=native-headset on pulseaudio, I think
that USE flag setup (packaging-wise) might be a bit suboptimal if that
makes it work - please try.


Mart

Re: [gentoo-user] Bluetooth head phone

[Mart Raudsepp]

Ühel kenal päeval, E, 17.07.2017 kell 12:10, kirjutas Raphael MD:
> Hi everyone,
> I'm suffering a lot to put sound on my Bluetooth's head phone.
> The Bluez5 recognize my bt device.
> The pulseaudio is working normally, but A2DP protocol do not appear
> in pavucontrol options.
> I've followed the gentoo wiki, and looked at arch wiki to.
> Anyone have a path to this be difficult task bt+headphone
> Thanks

emerge --info pulseaudio please? Especially the "was built with the
following USE flags" part

Re: [gentoo-user] Can't compile media-libs/mesa - do I need gallium?

[Mart Raudsepp]

Ühel kenal päeval, E, 17.07.2017 kell 12:00, kirjutas Mart Raudsepp:
> Ühel kenal päeval, E, 17.07.2017 kell 03:46, kirjutas Rasmus Thomsen:
> > Hello,
> > 
> > > undefined reference to
> > 
> > `llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::__cxx11:
> > :b
> > asic_string , std::allocator > const&)' 
> > 
> > Seems to be the error, maybe you have to recompile llvm with c++11
> 
> And without any VIDEO_CARDS set, you are only getting llvmpipe with
> USE=llvm. If you don't need that with Xpra, you don't need that (and
> USE=gallium). I'm not sure if Xpra can make use of it or not, but if
> GL
> is sent over the wire or something, then probably not at the server-
> side.
> What llvmpipe is is described here:
> https://www.mesa3d.org/llvmpipe.html

Actually to be fully correct, I believe USE=gallium might build more
stuff even without any VIDEO_CARDS, e.g some state trackers and
whatnot, but nothing useful to really make use of it if you don't have
any VIDEO_CARDS for mesa or any other packages.

Re: [gentoo-user] Can't compile media-libs/mesa - do I need gallium?

[Mart Raudsepp]

Ühel kenal päeval, E, 17.07.2017 kell 03:46, kirjutas Rasmus Thomsen:
> Hello,
> 
> > undefined reference to
> `llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::__cxx11::b
> asic_string , std::allocator > const&)' 
> 
> Seems to be the error, maybe you have to recompile llvm with c++11

And without any VIDEO_CARDS set, you are only getting llvmpipe with
USE=llvm. If you don't need that with Xpra, you don't need that (and
USE=gallium). I'm not sure if Xpra can make use of it or not, but if GL
is sent over the wire or something, then probably not at the server-
side.
What llvmpipe is is described here:
https://www.mesa3d.org/llvmpipe.html

Re: [gentoo-user] GPU closed source libraries

[Mart Raudsepp]

Ühel kenal päeval, N, 13.07.2017 kell 16:41, kirjutas Francisco Ares:
> Hi, All.
> 
> I'm trying to get Gentoo and xorg in an Odroid XU4 (hardkernel.com).
> 
> Most things are done, but there are a few glitches. I'm using the
> open source xf86-video-armsoc, which does not provide GPU
> acceleration.
> 
> So, for instance, dev-qt/qtgui with USE="gles2" (just an example), it
> will pull media-libs/mesa for 3d acceleration, although the
> proprietary library (Mali drivers) would do so.
> 
> How would I avoid emerging media-libs/mesa in this example?

It needs the standardish khronos GL headers from somewhere, which
proprietary drivers don't ship or mess with them too much for standard
stuff. Typically mesa is a good place to get them. That doesn't mean
it'd use it at runtime when your system is eselected to mali instead.
Have you tried not worry about the dep and just get things compiled
against mesa headers and see if it actually uses mali drivers then
still?

Re: [gentoo-user] Re: Wayland - too early to try?

[Mart Raudsepp]

Ühel kenal päeval, K, 12.07.2017 kell 09:33, kirjutas Mick:
> On Tuesday 11 Jul 2017 23:14:16 Mick wrote:
> > On Wednesday 12 Jul 2017 01:10:00 Mart Raudsepp wrote:
> > > > I copied /usr/share/xsessions/enlightenment.desktop to
> > > > /usr/share/wayland-
> > > > sessions/ and tried to select it in LightDM.  Unfortunately
> > > > LightDM
> > > > returns me
> > > > back to the login page.  I don't know if this is a result of
> > > > LightDM
> > > > not being
> > > > compatible with Wayland and friends, or if I need to install
> > > > some
> > > > other
> > > > package in addition to what has been emerged already.
> > > 
> > > The desktop manager needs to be using wayland to be able to
> > > launch
> > > wayland desktop sessions. LightDM is not such a desktop manager
> > > to my
> > > knowledge and you won't be able to launch any wayland sessions
> > > with it.
> > > 
> > > Mart
> > 
> > Thanks Mart, what other DM or means do I have to launch
> > enlightenment with
> > wayland?  I'm guessing the time honoured startx from a console
> > won't cut it.
> 
> Oh dear!  I noticed this:
> 
> https://git.enlightenment.org/core/enlightenment.git/tree/README.wayl
> and
> 
> which states that efl *must* be built with --enable-systemd
> option.  I am 
> running openrc ... so I don't know if the above just requires this as
> a build 
> time dependency, or is needs systemd to be running.  Anyway, from
> that write 
> up and the Known Issues at the bottom it seems Wayland is not ready
> for prime 
> time yet.

That README.wayland looks rather outdated. There are issues mentioned
in the end that have been fixed since mid-2016 with xorg-server
releases out since then with the fixes (Xwayland comes from xorg-
server[wayland]).

Regarding systemd, wayland sessions usually require logind seat
interfaces. If you want to stick with OpenRC, you might need to look
into elogind then, which is now in Gentoo and integrated for some
Plasma wayland usages, but EFL stuff might need some ebuild changes too
to use that instead of systemd provided logind.


Mart

Re: [gentoo-user] Re: Wayland - too early to try?

[Mart Raudsepp]

Ühel kenal päeval, T, 11.07.2017 kell 18:16, kirjutas R0b0t1:
> In any case if you are asking the question that OP did, I would
> suggest Wayland might not be for you. You may not receive any benefit
> from using it unless, for some reason, the differing underlying
> implementation fixes a bug - but I see this as being a bit of a
> stretch, because if you don't go out of your way to run Wayland only
> programs, you will still be running X11 on top of Wayland.

There are no grabs in Wayland, and thus the bug he had, related to
tooltips or context menus, might very well be related to the switch, as
tooltips and context menus are done completely differently.

> Most programs written for Wayland still seem to be at early
> experimental stages, and are things like tiling window managers.

Most programs don't need to be written for Wayland, they just use a
toolkit while avoiding to make their own libX11/XCB/etc calls.
This means most GTK3 programs and Qt programs run natively on wayland
out of the box without doing anything.
Running things needing X11, and thus going through Xwayland, can still
be smoother as well.


Mart

Re: [gentoo-user] Re: Wayland - too early to try?

[Mart Raudsepp]

Ühel kenal päeval, T, 11.07.2017 kell 23:14, kirjutas Mick:
> On Wednesday 12 Jul 2017 01:10:00 Mart Raudsepp wrote:
> > > I copied /usr/share/xsessions/enlightenment.desktop to
> > > /usr/share/wayland-
> > > sessions/ and tried to select it in LightDM.  Unfortunately
> > > LightDM
> > > returns me 
> > > back to the login page.  I don't know if this is a result of
> > > LightDM
> > > not being 
> > > compatible with Wayland and friends, or if I need to install some
> > > other 
> > > package in addition to what has been emerged already.  
> > 
> > The desktop manager needs to be using wayland to be able to launch
> > wayland desktop sessions. LightDM is not such a desktop manager to
> > my
> > knowledge and you won't be able to launch any wayland sessions with
> > it.
> > 
> > Mart
> 
> Thanks Mart, what other DM or means do I have to launch enlightenment
> with 
> wayland?  I'm guessing the time honoured startx from a console won't
> cut it.

Someone else was trying Sway with LightDM and got it to work. LightDM
wiki page also says it supports Wayland. But maybe our packaging
doesn't, I need to check back with him. Did you check with LightDM as-
is? It ought to show stuff from /usr/share/wayland-sessions/ as choices
(maybe enlightenment doesn't have an entry there?).

Command line launching should be possible, but I don't know the details
to get everything going correctly.


Mart

Re: [gentoo-user] Re: Wayland - too early to try?

[Mart Raudsepp]

> I copied /usr/share/xsessions/enlightenment.desktop to
> /usr/share/wayland-
> sessions/ and tried to select it in LightDM.  Unfortunately LightDM
> returns me 
> back to the login page.  I don't know if this is a result of LightDM
> not being 
> compatible with Wayland and friends, or if I need to install some
> other 
> package in addition to what has been emerged already.  

The desktop manager needs to be using wayland to be able to launch
wayland desktop sessions. LightDM is not such a desktop manager to my
knowledge and you won't be able to launch any wayland sessions with it.

Mart

Re: [gentoo-user] Re: Wayland - too early to try?

[Mart Raudsepp]

Random information dump on the subject.

Wayland is no program, it is a protocol, that's it. dev-libs/wayland is
essentially a helper library to speak that IPC protocol.

The window manager has to be the compositor and other things as well
and do the input handling, window drawing, screenshot support, screen
capture support, etc etc.
Random programs can not take screenshots, listen to keys (think global
keys, e.g outside desktop shortcuts/push2talk voip) without some
protocol between the WM and the program. The Xorg programs for that
essentially make use of Xorg design security issues to do stuff like
take screenshots (random program can see your whole desktop screen with
Xorg), listen to input (keyloggers are trivial with Xorg), etc.
There are some standardization efforts going on between the desktop in
various areas of this, to define wayland protocols to more securely
support these things for applications. In some areas things are still
lacking.

To detect native wayland vs Xwayland or Xorg I like to use xprop.
Running that command and clicking it on a window will give information
about that window IFF it's using Xwayland or your whole session is in
Xorg.
But if you are still using Xorg, then you'll have a /usr/bin/X running.
There is no X running with a wayland WM, just Xwayland at most for
programs that don't support wayland natively.
Xwayland is a rootless X server to run on top of a wayland supporting
compositor. It's conceptually the same like Xquartz or Xming to run X11
clients in some other environment.

Wayland strives towards the "every frame is perfect" mantra. It is very
hard for toolkits and other things to draw things halfway on monitor
scan-out, so things like tearing are rather hard to accomplish, albeit
possible still in certain situations.

With wayland your programs need to do all the drawing themselves, which
actually means often pure software rendering, but thanks to the
smoothness of "every frame is perfect", it'll feel faster on your
common system. You don't have RENDER extension to do some acceleration
like you do in Xorg with many toolkits knowing about X RENDER (cairo in
the gtk+ world). To get hardware acceleration, the toolkit itself needs
to be able to use OpenGL (full or GLES), Vulkan, or similar. GTK+ 4
will be able to do both. Games typically already use OpenGL or Vulkan
and if they run natively on Wayland, they are still accelerated, often
with some things out of the way compared to Xorg. Programs that don't
run natively and end up using Xwayland are also accelerated via RENDER,
as Xwayland makes use of GLAMOR, which implements RENDER in the
(Xwayland rootless) X server on top of OpenGL. But as said, in practice
things are fast and smooth already as-is, even if software rendering.

One caveat of Wayland is that if the WM/compositor crashes, your whole
graphical session dies, while with Xorg the WM typically just restarts
and for the session to die, Xorg itself would have to die (and that's
been ironed out over the decades to very rarely do).

GNOME is indeed one of the leaders in adoption and implementing various
extra features on top of it (even middle-click PRIMARY paste,
seriously). EFL is probably another, and I think plasma is getting
there. And then you have the dedicated wayland compositors like Sway (a
i3-compatible approach). I bet there are something similar openbox-like 
out there as well, but openbox itself definitely won't work, as it'd
have to be the compositor and not talk libX11..


HTH,
but probably you should have just googled ;)


Mart

Re: [gentoo-user] Anjuta - Segmentation Fault

[Mart Raudsepp]

Ühel kenal päeval, E, 10.07.2017 kell 08:44, kirjutas Peter Humphrey:
> On Monday 10 Jul 2017 05:22:04 Mart Raudsepp wrote:
> 
> > Glade, as in libglade, is deprecated for years and should
> > definitely
> > not be used. Glade the UI design tool[1] however is not deprecated,
> > it
> > just now outputs GtkBuilder XML [2] instead of Glade XML.
> > gnome-builder does intend to add glade UI design integration (for
> > GtkBuilder), but doesn't have that feature implemented yet [3].
> > You should very seriously consider moving over [4] to GtkBuilder,
> > libglade is dead.
> 
> prh@peak ~ $ equery d libglade
>  * These packages depend on libglade:
> dev-python/pygtk-2.24.0-r4 (>=gnome-base/libglade-2.5:2.0)
> prh@peak ~ $ equery d pygtk
>  * These packages depend on pygtk:
> media-gfx/gimp-2.8.22 (>=dev-
> python/pygtk-2.10.4:2[python_targets_python2_7(-)?,-
> python_single_target_jython2_7(-),-python_single_target_pypy(-),-
> python_single_target_pypy3(-),-python_single_target_python3_4(-),-
> python_single_target_python3_5(-),-
> python_single_target_python3_6(-),python_single_target_python2_7(+)])
> 
> Rumours of its death are being exaggerated, so to speak.

Yes, sorry. I've been busy with work, cold virus and getting gstreamer-
1.12 and GNOME 3.24 ready, so I haven't been able to deal with lower
priority things, like getting rid of completely upstream unmaintained
software, or security vulnerable webkit-gtk-2.4 and gstreamer:0.10.

The point was, no new application development should be done against
libglade, and any existing projects (that are apparently actively
worked on, as would be the case when an IDE is sought for) should work
on migrating to GtkBuilder, available in gtk+ core since 2.12 or so; so
not even a gtk3 thing to talk death exaggeration about.


Mart

Re: [gentoo-user] Anjuta - Segmentation Fault

[Mart Raudsepp]

Ühel kenal päeval, P, 09.07.2017 kell 07:15, kirjutas Hogren:
> How can it help ?

Seems like something with anjuta libgladeui integration is going wonky
and checking the type of some invalid pointer inside scale factor
query, wrong object or some such.
Might understand more when the backtrace had debugging symbols.
https://wiki.gentoo.org/wiki/Debugging#Install_debugging_information
(don't go with nostrip though, that's no good over splitdebug)

> For Gnome-Builder, Thanks for the advice. I will see more for a next
> project. Reading the website, I think it's really a Gnome IDE, in
> comparison with Anjuta which is more a GTK IDE. Am I in truth ?

More or less, though I use it for other stuff as well, especially with
the extra optional installs I added elog information into postinst of
gnome-builder.

> Therefore, there is no integrated Glade in Gnome-Builder.

Glade, as in libglade, is deprecated for years and should definitely
not be used. Glade the UI design tool[1] however is not deprecated, it
just now outputs GtkBuilder XML [2] instead of Glade XML.
gnome-builder does intend to add glade UI design integration (for
GtkBuilder), but doesn't have that feature implemented yet [3].
You should very seriously consider moving over [4] to GtkBuilder,
libglade is dead. After that you can use the standalone dev-util/glade. 
Actually I think it might still support libglade files as well.

1. https://glade.gnome.org/
2. https://developer.gnome.org/gtk3/stable/GtkBuilder.html
3. https://wiki.gnome.org/Apps/Builder/Planning/UIBuilder
4. https://developer.gnome.org/gtk2/stable/gtk-migrating-GtkBuilder.html

Re: [gentoo-user] Anjuta - Segmentation Fault

[Mart Raudsepp]

Ühel kenal päeval, R, 07.07.2017 kell 13:44, kirjutas Hogren:
> > Would be good to see the actual segfault message as well.
> > 
> 
> Just after errors messages, there is :
> Segmentation Error  (core dumped)

This involves actually looking at the core dump with gdb and such.
If you happen to use systemd, then this might just do it (provided gdb
is emerged):

coredumpctl gdb anjuta

it should load into gdb, takes a while, then if successful:

thread apply all bt full

---

However if you want an IDE or so, not anjuta in particular, I would
really suggest to try out gnome-builder instead.
Though it'd be nice to have anjuta working and debugged anyhow, even if
for others who suffer from it crashing but haven't bothered reporting.


Mart

Re: [gentoo-user] Gentoo vs Raspbian on Raspberry Pi 3?

[Mart Raudsepp]

Ühel kenal päeval, E, 26.06.2017 kell 10:32, kirjutas R0b0t1:
> If you want to use Gentoo on an embedded device you should be ready
> to set up crossdev and a crossroot for it.

That's for sure, except... RPi3 is NOT an embedded device in any
traditional sense of the word and I don't really like the term extended
to such machines. Embedded is what I'd call a Cortex-M maybe, not some
general purpose Cortex-A quad core 64bit "beast" with full USB/HDMI and
OpenGL support. It runs circles around the first desktop  machine I
installed Gentoo on. It is roughly equal to your low end cheap Atom
type laptops as far as CPU performance is concerned. It just has a slow
I/O and less RAM than we consider the norm these days.

I see no reason to crossroot for it unless that's ones desire in itself
(for example when it works, it might be worth the time save for mass
testing of stuff, e.g initial arch team work), or you really need it
for some working linker memory limitations when trying to do some
desktop stuff (browser engines, rust). For headless cases, not worth
the hassle whatsoever imho. Yes, gcc itself will take half a day or
whatnot, but hey, it's just taking you some 3-5W chugging along.

crossdev sure, if you think with the limited I/O a distcc host can help
out.

But sure, it can be educational, so have at it if you want; when it
works, it'll get your packages done faster if you have a beefy x86_64.


Mart

Re: [gentoo-user] bugzilla down?

[Mart Raudsepp]

Ühel kenal päeval, N, 15.06.2017 kell 16:28, kirjutas Ian Zimmerman:
> ~$ curl -L https://bugs.gentoo.org  2>/dev/null | lynx -dump -stdin
>  Internal Server Error


Please look at https://infra-status.gentoo.org/ of course.

Re: [gentoo-user] Why is PS1 (the console prompt) different for the root user?

[Mart Raudsepp]

Ühel kenal päeval, L, 10.06.2017 kell 09:12, kirjutas Nikos
Chantziaras:
> I noticed that the root prompt does not include the full path of the 
> current directory. Normal user:
> 
>    me@gentoopc ~ $ cd /usr/bin
>    me@gentoopc /usr/bin $
> 
> However, for root:
> 
>    gentoopc ~ # cd /usr/bin
>    gentoopc bin #

https://gitweb.gentoo.org/repo/gentoo.git/commit/app-shells/bash?id=15336782891de2b

Re: [gentoo-user] Imdb videos won't play in Chromium

[Mart Raudsepp]

It doesn't work for me either with chromium.
It seems to be some kind of supported video format negotiation error
with javascript or something; or CORS or who knows. For some reason a
suitable encoding can't be found and it fails with a log message in
debugging console as well.
However if going to the video URL manually (retrieved from a long long
javascript dictionary in the sources), it plays just fine.

Searching for it turns up various issues, from extensions causing
troubles (in my case it was a clean-ish profile with no extensions
enabled in private browsing where I tried this), to CORS (cross-origin
resource sharing) issues, to whatever else.

I can't spend more time debugging this right now, but hope this leads
to a better track than thinking it's some sort of flash or codecs
issue.


Mart

Re: [gentoo-user] gnome shell extensions installation without chrome/firefox

[Mart Raudsepp]

Ühel kenal päeval, T, 30.05.2017 kell 10:27, kirjutas Raffaele Belardi:
> I have Seamonkey and the default Gnome browser (epiphany) installed,
> none of which seems to be compatible with the Gnome shell extensions
> plugin system.

gnome-base/gnome-shell[nsplugin] ought to still work for those.

> Is there an alternative way to install shell extensions? Possibly by
> customizing the gnome-shell-extensions package?

There are various ways:

* https://extensions.gnome.org/ combined with either
  chrome-gnome-shell + browser plugin (it should auto-install with
chrome/chromium or pop up a notification on the website with a link to
the plugin); or gnome-shell[nsplugin]
** Note that chrome-gnome-shell, contrary to what the name makes one
possibly think, is also meant to be used with modern Firefox[1] and
various other browsers that support the new-ish WebExtensions
standard[2] (draft).
** With chrome-gnome-shell you'd also get notifications of outdated
extensions with newer versions available and to easily update them
(basically avoiding having to go check on extensions.gnome.org
Installed extensions tab if there are newer versions)

* Installing via a system package (gnome-shell-extensions is just one
such a package, there are others, mostly package name starts with
"gnome-shell-extensions"), which makes it managed by package manager
and be available for enabling for all users, or be default enabled for
all users

* Installing manually in the appropriate directory as discussed already
in other replies

* Installing via gnome-tweak-tool somehow, looks like via pointing it
at some compressed extension tarball

* Installing via gnome-software (yes, we have that packaged and the
extensions side of thing should work, albeit the package currently
doesn't really let it be installed without all the packagekit stuff,
but the extensions work even with packagekit portage integration being
rather broken in my tests - it's individual enough)

Mostly it all boils down to installing to the appropriate system or
user directory, rest is about monitoring for updates, having shortcuts
to opening the extensions settings panel, etc.


1. https://developer.mozilla.org/en-US/Add-ons/WebExtensions
2. https://browserext.github.io/browserext/

Re: [gentoo-user] Samba patching?

[Mart Raudsepp]

Ühel kenal päeval, E, 29.05.2017 kell 22:12, kirjutas Stefan G.
Weichinger:
> how do we gentoo-users handle CVE-2017-7494 ?

You upgrade to the version including the fix. 4.5.10, that is.
https://bugs.gentoo.org/show_bug.cgi?id=CVE-2017-7494

Re: [gentoo-user] Can I resize /dev/shm on the fly?

[Mart Raudsepp]

Ühel kenal päeval, E, 29.05.2017 kell 14:47, kirjutas Walter Dnes:
>   I was using a chroot, and I bind-mounted the chroot's /dev and
> /proc
> and /sys on top of the host machine's directories.  Bad idea... I now
> have a 10 megabyte /dev/shm on the host.  Is it possible to resize
> /dev/shm to approx 1 gigabyte without rebooting?

mount -oremount,size=1G /dev/shm

Provided it's a tmpfs like it is for me.

>   And how do I set up a working /dev and /proc and /sys on the chroot
> separately to avoid this in future?  I need /proc/cpuinfo because I
> have
> a build script in the chroot that checks the number of cores, and
> sets
> makeopts accordingly.  Also I need /dev/null.

Re: [gentoo-user] Gentoo livedvd

[Mart Raudsepp]

Ühel kenal päeval, P, 28.05.2017 kell 20:41, kirjutas Christos Kotsis:
> Hello everyone,
> 
> I noticed that the Gentoo livedvd is outdated. Is anyone assigned
> there
> to contact? I would like to updated it, since I use it very often.

The LiveDVD is a user contribution by Fernando Reyes, coordinated with
RelEng to some extent. Usually updated in time of some conference event
with bigger Gentoo presence to hand out pressed DVDs with some artwork.

You can catch him as "likewhoa" nickname in the #gentoo-ten IRC
channel.


Mart