Re: [gentoo-user] Dolphin, CPU usage and process ID to which window.

[Franz Fellner]

On Tue Sep  8 13:40:03 2020, Neil Bothwick  wrote:
> On Tue, 8 Sep 2020 04:55:50 -0500, Dale wrote:
> 
> > I have a lot of desktops here.  If I run that command in a Konsole, can
> > I still click to switch to the desktop that Dolphin is running on?  I
> > have to click to switch since the usual offender is on desktop 12, 13 or
> > 14.  I can't switch there with the F keys.  It seems something else uses
> > those shortcuts. 
> 
> Open a separate console on the desktop running Dolphin, or install
> kde-apps/yakuake to have a console wherever and whenever you want it.

Or scroll the mouse wheel on the pager/desktop switcher to switch
between desktops.
But Yakuake is probably the easiest solution.
You can also toggle "view on all desktops" for the console via the
context menu.

Re: [gentoo-user] Dolphin, CPU usage and process ID to which window.

[Franz Fellner]

On Mon Sep  7 22:05:36 2020, Dale  wrote:
> Another question.  I use top to see what is using the CPU so much.  When
> it is Dolphin, I can't tell which window it is.  I sometimes have a few
> instances of Dolphin open at the same time.  Sometimes I have my spot
> marked by highlighting a file or files.  If I kill it, I don't get to
> write down where I was.  Thing is, I can't tell from top which window it
> is that is using the CPU more than it should.  Is there a way to figure
> out which process goes with which window or running instance of
> Dolphin?  In top, it shows a ID number like this.

In a console run:

xprop _NET_WM_PID

Your cursor will turn into a crosshair.
now click on the first dolphin window.
In the console you now get something like

_NET_WM_PID(CARDINAL) = 576073

Compare the number with the PID in top from the dolphin instance
with high CPU usage.
If it is the same you have your instance.
If not repeat with the next dolphin window.

Re: [gentoo-user] meson build woes

[Franz Fellner]

On Mo 24 Aug 2020 11:21:10 +0200, Hogren  wrote:
> Maybe try to :
> 
> - Unmerge all python and python-setuptools versions

No, don't do that!!!
Unmerging all python version will leave you with a non-working portage.
portage is written in python.
You can fix that but it requires some manual intervention...

> - Verify your package.use files. Run "grep -Ri 'python' 
> /etc/portage/package.use/" and delete old files.
> 
> - Run a "emerge --newuse --update --autounmask-write --deep 
> --with-bdeps=y @world".

This should be the first thing to check.
package.use and probably also make.conf should be looked for PYTHON settings.
Uncomment affected lines first (put the character # at the beginning) before 
deleting.
The "--deep --newuse" emerge options should take care for the rest.

Re: [gentoo-user] [OT] Persistent empty window

[Franz Fellner]

On So 23 Aug 2020 12:20:10 +0100, Neil Bothwick  wrote:
> On Sun, 23 Aug 2020 09:54:25 +0100, Peter Humphrey wrote:
> 
> > > > What an obscure "feature."  
> > > 
> > > Not that obscure, click anywhere but where you meant to and it's
> > > staring you in the face :)  
> > 
> > :)
> > 
> > Yes, but how did you discover the right-edge-click feature?
> 
> After clicking everywhere else. Then doing the same again the next time.
> Eventually, it sunk in.

You can have the actual control to resize and delete by long-pressing.
Just press the left mouse button on the note widget until the controls come up.
Works for every plasma widget you put on your desktop (like system monitors, 
launchers, ...)

Re: [gentoo-user] repoint virtual/rust to rust instead of rust-bin

[Franz Fellner]

When you sorted out the mentioned keywording issues:
To tell portage to ignore rust-bin as a valid dependency
for virtual/rust simply put "dev-lang/rust-bin" in your
"/etc/portage/pckage.mask"

Franz

On Tue Jul 21 17:49:12 2020, Adam Carter  wrote:
> I've unmerged rust-bin, emerged rust (v1,45), then re-emerged virtual/rust
> but if i run a world update it still wants to pull rust-bin back in;
> 
> # emerge -avuD --tree world
> 
> These are the packages that would be merged, in reverse order:
> Calculating dependencies... done!
> [ebuild UD ] virtual/rust-1.44.1::gentoo [1.45.0::gentoo] ABI_X86="(64)
> -32 (-x32)" 0 KiB
> [ebuild  N ]  dev-lang/rust-bin-1.44.1:stable::gentoo  USE="-clippy
> -doc -rustfmt" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse2" 0 KiB
> 
> How do I clear this?
> 
> 

Re: [gentoo-user] Memory cards and deleting files.

[Franz Fellner]

On Sun Jun 21 09:21:36 2020, Dale  wrote:
> The cards I use are class 10, slow but pretty fast for the type of
> card.  Generally, I can download several hundred MBs in a minute or
> two.  Deleting sometimes over a 1,000 pics one at a time just isn't
> feasible.  That could take a long time.

That wasn't my intention!
I thought you should just select one file (remember its name), delete it,
unmount, remount and see if the file is still there.
So you can be sure that you really have a different issue than just performance.
Trying to delete a folder takes ages and you don't see the file names.

Re: [gentoo-user] Memory cards and deleting files.

[Franz Fellner]

On Sat Jun 20 12:09:02 2020, Dale  wrote:
> I then right clicked on the
> directory and chose move to trash.

Never tried deleting just single files?
Probably you need to wait longer, those cards are slow.
I personally do not like to use "move to trash" as the copy takes ages.
In dolphin you also have "Delete" now (probably you need to press shift
to turn the "trash" menu item into a "delete")

Formatting usually is the fastest way to get rid of everything on the cards.

Re: [gentoo-user] eselect not showing python3.7 or 3.8

[Franz Fellner]

Probably you still have set PYTHON_TARGETS in your make.conf?
I currently have no Gentoo system running so I can't check.


On Fri Jun 19 15:19:50 2020, William Kenworthy  wrote:
> I have been slowly fixing the mess that the python upgrade has made of
> my systems and have come across this:
> 
> san0 ~ # eselect python list
> Available Python interpreters, in order of preference:
>   [1]   python3.6
>   [2]   python2.7
> san0 ~ # equery l python
>  * Searching for python ...
> [IP-] [  ] dev-lang/python-2.7.18:2.7
> [IP-] [  ] dev-lang/python-3.6.10-r2:3.6/3.6m
> [IP-] [  ] dev-lang/python-3.7.7-r2:3.7/3.7m
> [IP-] [  ] dev-lang/python-3.8.2-r2:3.8
> san0 ~ #
> 
> eselect python cleanup does not change anything. The system is refusing
> me from removing python3.6 and re-emerging 3.7 doesn't change anything. 
> 4 other almost identical hosts are fine.
> 
> I was looking at why ansible was failing on hosts that had python3.6
> removed and came across this one ...
> 
> BillK
> 
> 
> 
> 
> 

Re: [gentoo-user] Daily update fails

[Franz Fellner]

On Thu May  7 10:04:37 2020, Dan Johansson  wrote:
> Today when I tried to do my daily "emerge --update ... @world", portage 
> spitted out a lot of "Multiple package instances within a single package 
> slot have been pulled" messages.

So THIS would have been the issue you should have given us to solve.
Instead you borked your package.use by globally deactivating py2.7
and asked us to point you to that.

So please: Revert the python changes you did in your package.use,
rerun your update command and post the error you get with that.
Please post the whole output, including the exact command you used.
And also add "--tree --verbose" to the emerge options, this usually
requires less guessing.

Thx
Franz

Re: [gentoo-user] Re: Troubles setting USE flag for inkscape

[Franz Fellner]

On Sat Apr 25 20:33:36 2020, tu...@posteo.de wrote:
> 
> Hi Remy,
> 
> that helped !
> 
> To be honest ... I never had deduced this from the error message.
> Is this pure experience...somehing one had to learn after uears
> of trying to cope with The Portage Oracle...or is it one has
> and the other one has not...? ;)
> 
> ...or what manual do I need to read to up with this line?

For the "Oracle" output of portage:
  ##The following REQUIRED_USE flag constraints are unsatisfied:
  ##exactly-one-of ( python_single_target_python3_6 
python_single_target_python3_7 python_single_target_python3_8 )
^^

So "exactly one of the listed use flags".

For the documentation on syntax:
"man portage" and go to the "package.use" section
or visit
https://wiki.gentoo.org/wiki//etc/portage/package.use

Re: [gentoo-user] Emergian oracle spoke again...

[Franz Fellner]

Yes, confusing. portage bug IMO.
Filed one for you:
https://bugs.gentoo.org/711474

But still this should have been possible for you to figure out.
Confusing suggestion? Just have a look at the mentioned file.
/usr/portage/profiles/package.mask
Search for tintwizard and find this block:
# Andreas Sturmlechner  (2020-02-26)
# Unmaintained revdeps on dev-python/pygtk blocking its removal, py2-only
# All masked for removal in 30 days.
# Last release in 2011, bug #708106
app-cdr/gtkcdlabel
# No plans upstream to port away from pygtk, suggested alternative dupeguru
# not packaged in Gentoo, bug #708112
app-misc/fslint
# Last release in 2012, bug #708124
app-text/keepnote
# Last release in 2012, bug #708142
x11-misc/revelation
# Last release in 2011, bug #708150
x11-misc/tintwizard
# Last activity in 2013, bug #710162
sci-misc/pythoncad
# Last release in 2013, bug #710164
sci-electronics/gresistor

Another hint are those linked bug numbers.
Just copy one, type "bugs.gentoo.org/" and paste the number.
e.g. "bugs.gentoo.org/708112" which is the bug mentioned in the "dupeguru"
line.
And you see this issue is about fslint. "scratch you head".

Am Mi., 4. März 2020 um 04:22 Uhr schrieb :

> Hi,
>
> I got this oupt while updateing:
>
> !!! The following installed packages are masked:
> - x11-misc/tintwizard-0.3.4-r3::gentoo (masked by: package.mask)
> /usr/portage/profiles/package.mask:
> # Andreas Sturmlechner  (2020-02-26)
> # Unmaintained revdeps on dev-python/pygtk blocking its removal, py2-only
> # All masked for removal in 30 days.
> # Last release in 2011, bug #708106
> # No plans upstream to port away from pygtk, suggested alternative dupeguru
> # not packaged in Gentoo, bug #708112
> # Last release in 2012, bug #708124
> # Last release in 2012, bug #708142
> # Last release in 2011, bug #708150
>
> I interpret this as:
>
> tintwizard will be removed because of being Unmaintained and python-2
> base.
>
> As an alternative, "dupeguru" is suggestet.
>
> The description of tintwizard is:
> "GUI wizard which generates config files for tint2 panels"
>
> dupeguru isn't in the repository so I searched for it and found:
> "dupeGuru is a cross-platform (Linux, OS X, Windows) GUI tool to find
> duplicate files in a system."
>
> Both application seem to have silightly different use cases.
>
> Or what dupeguru is meant here?
>
> Cheers!
> mcc
>
>
>
>
>

Re: [gentoo-user] mkvtoolnix: To use qt5 or not to use qt5 - that is the question (USE flag in-/valid?)

[Franz Fellner]

And another great one!
Just have a look at package.use/mkvtoolnix and you will see your problem.

# echo "qt5" >> /etc/portage/package.use/testuse
# emerge @preserved-rebuild
--- Invalid atom in /etc/portage/package.use/testuse: qt5

If it isn't obvious:
# man portage
-> GLOSSARY -> DEPEND atom

Am Do., 27. Feb. 2020 um 06:13 Uhr schrieb :

> Hi
>
> this command:
> emerge --selective=n  @preserved-rebuild
>
> gives me this message when started:
> --- Invalid atom in /etc/portage/package.use/mkvtoolnix: qt5
>
> and eix said this:
> [I] media-video/mkvtoolnix
>  Available versions:  37.0.0^t (~)42.0.0^t (~)43.0.0^t ***l^t
> {debug nls pch qt5 test}
>  Installed versions:  43.0.0^t(06:02:33 PM 02/23/2020)(nls -debug -pch
> -qt5 -test)
>  Homepage:https://mkvtoolnix.download/
> https://gitlab.com/mbunkus/mkvtoolnix
>  Description: Tools to create, alter, and inspect Matroska
> files
>
> From this I cannot decide, how to handle the 'qt5'-flag:
> Is it valid or is it invalid (and how do I get the gui version of that
> tool...) ?
>
> Cheers!
> mcc
>
>
>
>

Re: [gentoo-user] ERROR: media-video/mplayer-9999::bircoph failed (depend phase)

[Franz Fellner]

There's already a bug report open:
https://bugs.gentoo.org/709050
Is there a reason you use mplayer- from that repository?
There's also an mplayer- in the main portage tree.

Am Di., 25. Feb. 2020 um 06:01 Uhr schrieb Dale :

> Howdy,
>
> I get this when I try to emerge anything.  This is part of a string of
> commands so the emerge command itself is missing but its my usual emerge
> -auDN world.  Here's the error.
>
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies - * ERROR: media-video/mplayer-::bircoph
> failed (depend phase):
>  *   git-2.eclass could not be found by inherit()
>  *
>  * Call stack:
>  | * ebuild.sh, line 609:  Called source
> '/var/lib/layman/bircoph/media-video/mplayer/mplayer-.ebuild'
>  *   mplayer-.ebuild, line   8:  Called inherit 'flag-o-matic'
> 'git-2' 'multilib' 'subversion' 'toolchain-funcs'
>  * ebuild.sh, line 290:  Called die
>  * The specific snippet of code:
>  *  [[ -z ${location} ]] && die "${1}.eclass could not be
> found by inherit()"
>  *
>  * If you need support, post the output of `emerge --info
> '=media-video/mplayer-::bircoph'`,
>  * the complete build log and the output of `emerge -pqv
> '=media-video/mplayer-::bircoph'`.
>  * Working directory: '/usr/lib64/python2.7/site-packages'
>  * S: '/var/tmp/portage/media-video/mplayer-/work/mplayer-'
> ... done!
>
>
>
> It started when I synced about a week ago.  I thought it was a ebuild
> with a typo and would be fixed by the time I synced again.  I synced a
> few minutes ago and this is still there.  Either something is wrong with
> the tree or I have something off on my end.  Since I've never put a 
> ebuild in a overlay, I don't think it is me but one never knows about
> these things.  ;-)  Despite the error, emerge does continue on.  It
> spits that out very early on.
>
> Ideas? Bug that needs reporting?  Something wrong on my end somewhere?
>
> Dale
>
> :-)  :-)
>
>

Re: [gentoo-user] KDE Panel Mouse Problem

[Franz Fellner]

Autohide seems to work fine here.
Do you have the feature activated, that lets you change desktop when the
mouse hits the borders? If I activate that and have configured the Virtual
Desktop applet to show 4 desktops in two rows I get the described effect:
Hitting any of the four edges won't show the panel but change the desktop,
the mouse jumps to the opposite side.

Am Sa., 22. Feb. 2020 um 13:10 Uhr schrieb jdm :

> Hi,
>
> For the last three versions of plasma including latest 5.18 I am having
> a problem with panels. If I put autohide on and place the mouse on edge
> of the screen to get the panel to show my mouse (pointer) jumps to
> another part of the screen. It jumps out of the panel which hides again.
>
> This has been happening for the last 3 versions, I have created a new
> user and still have the problem and cleaned up configs.
>
> I have tried 3 different type of panels (app, default and empty) and in
> 4 places. It's even worse when placed on left or bottom as mouse
> jumps to centre.
>
>
> ---
> |   X  |
> |  |
> |  |
> |  |
> |X   X |
> |X   X |
> |X   X |
> |X   X |
> |X   X |
> |X |
> |  |
> |  |
> |XX|
> 
> Figure 1. Screenshot of panel placements.
>
> When the panel is not on autohide there is no mouse jump
>
> Any ideas.
>
> John
>
>

Re: [gentoo-user] OT> Python 2x deprecated: Alternative to bleachbit ?

[Franz Fellner]


Why look for an alternative? Just because the current version - that went
stable just in dezember, btw - depends on py2.7?
Upstream seems to be active - if you would had looked a little bit when
visiting the homepage -> they just released a v3.2!
And clicking that you can read - py3 update is in the workings!




Am So., 9. Feb. 2020 um 08:42 Uhr schrieb :

> Hi,
>
> I intensively use bleachbit to cleanup the filesystem and
> to get rid of tracking bits, which are left on my disk while
> browsing the internet.
>
> Bleachbit depends on python 2x.
>
> I searched the internet for an alternative to bleachbit especially
> for cleaning and wipeing www-debris (trackers, cookies, etc) from
> my disk...and found nothing.
>
> Additionally I search addons for firefox to do this job, but either
> it does not install (I am using waterfox) or was of questionable
> -hhhr- "quality"...
>
> Does anyone know of some tool to clean and wipe such "informations
> to increase my user experience"  from my disk?
>
> Thanks a lot for any help in advance!
> Cheers!
> mcc
>
>
>
>

Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions

[Franz Fellner]

That doesn't apply to the kernel.
4.19.97 got tagged on January 17.
January 18. it was stable on amd64 and x86 - one day instead of 30.
Here is the stabilization request: https://bugs.gentoo.org/705006
There were some issues and changes to the targeted versions.


Am Fr., 7. Feb. 2020 um 19:18 Uhr schrieb Mike Gilbert :

> On Thu, Feb 6, 2020 at 10:23 PM Matt Connell 
> wrote:
> >
> > On 2020-02-06 11:40, Ian Zimmerman wrote:
> > > 5.4 has just become the newest LTS.
> >
> > I see that now.  But my original question still stands as to why the
> > stable version of gentoo-sources is consistently a few versions behind
> > the latest LTS release.
>
> Typically, Gentoo maintainers leave new versions in ~arch for some
> time so they can be tested by a broad set of people. Stabilization
> bugs are normally not filed until a given version has spent at least
> 30 days in ~arch.
>
> See GLEP 40 for details on this process.
>
> https://www.gentoo.org/glep/glep-0040.html
>
>

Re: [gentoo-user] Question about gentoo-sources kernel release versions

[Franz Fellner]

That article you linked to is about a variant of linux, "rt". And as it
looks they didn't update their branch since the release of 4.19.100-r41.
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/log/?h=v4.19-rt
linux is at 4.19.102 now...

AFAIR the Gentoo kernel team knows what's going on regarding upcoming linux
patches.
They know about the fixes in each minor release. And they kinda sort out
what's important enough and what not.
Because longterm gets releases every few DAYS (!) and forcing the user to
update the kernel after every single sync is hardcore.

IMO it's good the way it is.

Am Do., 6. Feb. 2020 um 06:14 Uhr schrieb Matt Connell <
matthewdconn...@gmail.com>:

> I see posts on LWN (or other sources) for kernel minor version releases,
> such as this one: https://lwn.net/Articles/811334/  The notes will
> typically say that users should upgrade to that minor version due to bug
> fixes or security patches.
>
> I know that gentoo-sources tracks on the most current LTS kernel
> release, currently 4.19.97.  However, these versions seem to usually be
> slightly behind the 'recommended' minor version number.
>
> Why is this?  Is it because the Gentoo patchset precludes the issues
> that are being resolved by the LTS releases?  Are the issues considered
> significantly minor enough that they don't warrant a version bump for
> gentoo-sources?
>
> No complaint or dissatisfaction being expressed here, just curious why
> this seems to be, and if I should consider accepting ~amd64 for a newer
> version.
>
>
>

Re: [gentoo-user] python 2 deprecation

[Franz Fellner]

Quoting james (2020-01-27 06:57:24)
> It runs on 64/145 packages just fine, then, as always, fails on 
> "Emerging (65 of 145)dev-perl/Authen-SASL-2.160.0-r1::argent-main"
> 
> Any other ideas?  Maybe I need to download that package again, as it 
> somehow got corrupted?

I assume "argent-main" repo is the main tree of argentlinux, correct?
So no Gentoo but a fork?
It is likely that they messed up some things, so normal Gentoo users 
have no issues with that package.

Re: [gentoo-user] any experience with wayland?

[Franz Fellner]

Look here for some hints:
https://github.com/elogind/elogind/issues/61
Not everything should apply as you are using Gentoo, but I think there
might be a solution for you (pam configuration might be a first step).
Unfortunately I can't help with elogind as I'm using systemd and there I
have no issues with starting a wayland desktop.

Wayland won't work ON TOP OF X11. You can start X applications within
Wayland using XWayland (will be done automatically).
But trying to start wayland through startx will fail.

Am Do., 9. Jan. 2020 um 19:31 Uhr schrieb Mick :

> On Thursday, 9 January 2020 17:19:18 GMT Jack wrote:
> > On 2020.01.09 11:38, Franz Fellner wrote:
> > > Am Do., 9. Jan. 2020 um 18:35 Uhr schrieb Jack <
> > >
> > > ostrof...@users.sourceforge.net>:
> > > > Based on various wiki and forum posts,
> > > > I'm using  "dbus-run-session startplasma-wayland" as the last line
> > >
> > > in
> > >
> > > > .xinitrc, and launching with startx.
> > >
> > > I stopped reading here.
> > > Please think about that again, especially what wayland was meant to
> > > REPLACE!
> >
> > So if you think that's wrong/outdated/inappropriate - please suggest an
> > alternative.
> >
> > I know the ultimate goal is for Wayland to replace xorg-server, but
> > everything I have read so far indicates that currently it is really
> > just the compositor, and in the case of KDE, that compositing is
> > incorporated into kwin (launched as kwin_wayland instead of kwin_x11.)
> > I have seen no instructions anywhere on how  to launch wayland totally
> > independent of xorg.  As I said - I'll be happy to be pointed to any
> > docs I seem to have missed.  I do agree that most of the instructions
> > out there seem to be somewhat outdated, but I would expect to find
> > SOMETHING up to date.
>
> Perhaps as far back as 6 months ago I was able to run Plasma and
> Enlightenment
> desktops in Wayland, starting them from sddm DM.  A couple of months ago
> Wayland broke for me.  It tries to start, then drops me back into the
> login
> screen.  I haven't bothered to troubleshoot it, because the mechanism of
> providing me with a GUIfied desktop is less of an interest to me than
> being
> able to get a desktop in the first place.
> --
> Regards,
>
> Mick

Re: [gentoo-user] any experience with wayland?

[Franz Fellner]

P.S.: If you are on systemd just run 'dbus-launch startplasma-wayland'
directly after login on the terminal.
I don't know if there is an equivalent to .xinitrc that can launch other
important commands before the DE.

Am Do., 9. Jan. 2020 um 18:38 Uhr schrieb Franz Fellner <
alpine.art...@gmail.com>:

>
>
> Am Do., 9. Jan. 2020 um 18:35 Uhr schrieb Jack <
> ostrof...@users.sourceforge.net>:
>
>> Based on various wiki and forum posts,
>> I'm using  "dbus-run-session startplasma-wayland" as the last line in
>> .xinitrc, and launching with startx.
>>
>
> I stopped reading here.
> Please think about that again, especially what wayland was meant to
> REPLACE!
>

Re: [gentoo-user] any experience with wayland?

[Franz Fellner]

Am Do., 9. Jan. 2020 um 18:35 Uhr schrieb Jack <
ostrof...@users.sourceforge.net>:

> Based on various wiki and forum posts,
> I'm using  "dbus-run-session startplasma-wayland" as the last line in
> .xinitrc, and launching with startx.
>

I stopped reading here.
Please think about that again, especially what wayland was meant to REPLACE!

Re: [gentoo-user] Stable Python package changes USE flags with ~amd64

[Franz Fellner]

OK, seems I can reproduce (had an issue with my config in a previous
attempt).
Probably related:
https://bugs.gentoo.org/491166
But your view on the matter isn't correct.
Portage is strict when it comes to dependencies. Just because py3_7 is
installed it won't enable the PYTHON_TARGET because you might uninstall
python-3.7 and end up with a broken olefile.
What actually seems to happen: python3_7 (together with other)
PYTHON_TARGETS is disabled in the profile via use.stable.mask.
That config file disables certain USE-Flags for stable packages. That way
py3_7 is available for testing versions but not for stable ones.
olefile-0.46 is only available as stable version. But now adding it to
package.accept_keywords automagically seems to enable those
use.stable.mask'ed USE-Flags.
IMO this is a bug as it introduces totally unpredictable (and AFAICS
undocumented) behaviour.

Let's see what the DEVs say about this!

Regards
Franz

Am Di., 7. Jan. 2020 um 18:27 Uhr schrieb Mickaël Bucas :

> I get the following result:
> # emerge -pv1 olefile
>
>
> These are the packages that would be merged, in order:
> Calculating dependencies... done!
> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
> PYTHON_TARGETS="python2_7 python3_6 (-pypy3) (-python3_7*) (-python3_8)" 0
> KiB
> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>
> It seems to be in line with the interpretation I've come up with.
>
> Best regards
> Mickaël Bucas
>
> Le mar. 7 janv. 2020 à 16:18, Franz Fellner  a
> écrit :
>
>> And what if you change the line to "dev-python/olefile amd64"?
>>
>> Am Di., 7. Jan. 2020 um 17:10 Uhr schrieb Mickaël Bucas > >:
>>
>>> Hi Franz
>>>
>>> Thanks for your reply.
>>>
>>> However your assumption is incorrect: these two commands are run on the
>>> same machine, with only the keyword on "olefile" changed.
>>> Thinking a bit more about it, Python 3.7 isn't stable yet, so I also
>>> have "=dev-lang/python-3.7* ~amd64" in package.accept_keyword.
>>>
>>> I've been able to reproduce this behavior in a chroot based on stage 3
>>> with the minimum packages installed.
>>> I have in make.conf
>>> PYTHON_TARGETS="python2_7 python3_6 python3_7"
>>> In /var/lib/portage/world
>>> dev-lang/python:3.7
>>> dev-python/olefile
>>> In /etc/portage/package.accept_keywords
>>> dev-python/olefile ~amd64
>>> =dev-lang/python-3.7* ~amd64
>>> dev-python/setuptools ~amd64
>>> dev-python/certifi ~amd64
>>>
>>> And emerge says :
>>> # emerge -pv1 olefile
>>> These are the packages that would be merged, in order:
>>> Calculating dependencies... done!
>>> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
>>> PYTHON_TARGETS="python2_7 python3_6 python3_7 -pypy3 -python3_8" 0 KiB
>>> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>>>
>>> When I remove " dev-python/olefile ~amd64", Python 3.7 would be disabled
>>> :
>>> # emerge -pv1 olefile
>>> These are the packages that would be merged, in order:
>>> Calculating dependencies... done!
>>> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
>>> PYTHON_TARGETS="python2_7 python3_6 (-pypy3) (-python3_7*) (-python3_8)" 0
>>> KiB
>>> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>>>
>>> This is still puzzling me, but one interpretation may be :
>>> I you enable the unstable ~amd64 keyword on a package, the stable
>>> version of said package is allowed to run on the unstable version of the
>>> Python interpreter.
>>>
>>> This seems to be the intended behavior, as I found that at least 40
>>> Python packages on each of my 2 systems are stable and have Python 3.7
>>> enabled (I keyworded all of them sometime in the past...)
>>>
>>> Thanks
>>> Best regards
>>> Mickaël Bucas
>>>
>>> Le mar. 7 janv. 2020 à 08:08, Franz Fellner  a
>>> écrit :
>>>
>>>> I assume those emerge commands weren't done on one machine but come
>>>> from those two different machines.
>>>> This change in USE Flags can't come from that line in
>>>> package.accept_keywords.
>>>> This is a change in PYTHON_TARGETS in make.conf, package.use or
>>>> package.env.
>>>> Carefully go through those config files/directories, I am sure you will
>>>> find the offending line.
>>>>
>>>

Re: [gentoo-user] Stable Python package changes USE flags with ~amd64

[Franz Fellner]

And what if you change the line to "dev-python/olefile amd64"?

Am Di., 7. Jan. 2020 um 17:10 Uhr schrieb Mickaël Bucas :

> Hi Franz
>
> Thanks for your reply.
>
> However your assumption is incorrect: these two commands are run on the
> same machine, with only the keyword on "olefile" changed.
> Thinking a bit more about it, Python 3.7 isn't stable yet, so I also have
> "=dev-lang/python-3.7* ~amd64" in package.accept_keyword.
>
> I've been able to reproduce this behavior in a chroot based on stage 3
> with the minimum packages installed.
> I have in make.conf
> PYTHON_TARGETS="python2_7 python3_6 python3_7"
> In /var/lib/portage/world
> dev-lang/python:3.7
> dev-python/olefile
> In /etc/portage/package.accept_keywords
> dev-python/olefile ~amd64
> =dev-lang/python-3.7* ~amd64
> dev-python/setuptools ~amd64
> dev-python/certifi ~amd64
>
> And emerge says :
> # emerge -pv1 olefile
> These are the packages that would be merged, in order:
> Calculating dependencies... done!
> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
> PYTHON_TARGETS="python2_7 python3_6 python3_7 -pypy3 -python3_8" 0 KiB
> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>
> When I remove " dev-python/olefile ~amd64", Python 3.7 would be disabled :
> # emerge -pv1 olefile
> These are the packages that would be merged, in order:
> Calculating dependencies... done!
> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
> PYTHON_TARGETS="python2_7 python3_6 (-pypy3) (-python3_7*) (-python3_8)" 0
> KiB
> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>
> This is still puzzling me, but one interpretation may be :
> I you enable the unstable ~amd64 keyword on a package, the stable version
> of said package is allowed to run on the unstable version of the Python
> interpreter.
>
> This seems to be the intended behavior, as I found that at least 40 Python
> packages on each of my 2 systems are stable and have Python 3.7 enabled (I
> keyworded all of them sometime in the past...)
>
> Thanks
> Best regards
> Mickaël Bucas
>
> Le mar. 7 janv. 2020 à 08:08, Franz Fellner  a
> écrit :
>
>> I assume those emerge commands weren't done on one machine but come from
>> those two different machines.
>> This change in USE Flags can't come from that line in
>> package.accept_keywords.
>> This is a change in PYTHON_TARGETS in make.conf, package.use or
>> package.env.
>> Carefully go through those config files/directories, I am sure you will
>> find the offending line.
>>
>> Regards
>> Franz
>>
>> Am Fr., 3. Jan. 2020 um 11:44 Uhr schrieb Mickaël Bucas > >:
>>
>>> Hello
>>>
>>> For some time I've been wondering why I had a difference on
>>> dev-python/olefile-0.46 between 2 machines : one was installed with
>>> python_targets_python3_7, the other wasn't.
>>> And I finally pinpointed it to package.accept_keywords containing
>>> "dev-python/olefile ~amd64" on one of the machines only
>>>
>>> At the time of writing, dev-python/olefile-0.46 is the stable version,
>>> and KEYWORDS contains "amd64" (no tilde) among others.
>>>
>>> When package.accept_keywords doesn't contain "dev-python/olefile
>>> ~amd64", I get :
>>> emerge -pv1 --verbose-conflicts olefile
>>> These are the packages that would be merged, in order:
>>> Calculating dependencies... done!
>>> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
>>> PYTHON_TARGETS="python2_7 python3_6 (-pypy3) (-python3_7) (-python3_8)" 0
>>> KiB
>>> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>>>
>>> => Python 3.7 is disabled
>>>
>>> When package.accept_keywords contains "dev-python/olefile ~amd64", I get
>>> :
>>> emerge -pv1 olefile
>>> These are the packages that would be merged, in order:
>>> Calculating dependencies... done!
>>> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
>>> PYTHON_TARGETS="python2_7 python3_6 python3_7* -pypy3 -python3_8" 0 KiB
>>> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>>>
>>> => Python 3.7 is enabled
>>>
>>> It seems really really strange to me for the same version of a stable
>>> package to be "influenced" by keywording.
>>> Is it a bug or a feature ?
>>> Did I do something wrong ?
>>>
>>> Thanks
>>> Best regards
>>> Mickaël Bucas
>>>
>>

Re: [gentoo-user] Stable Python package changes USE flags with ~amd64

[Franz Fellner]

I assume those emerge commands weren't done on one machine but come from
those two different machines.
This change in USE Flags can't come from that line in
package.accept_keywords.
This is a change in PYTHON_TARGETS in make.conf, package.use or package.env.
Carefully go through those config files/directories, I am sure you will
find the offending line.

Regards
Franz

Am Fr., 3. Jan. 2020 um 11:44 Uhr schrieb Mickaël Bucas :

> Hello
>
> For some time I've been wondering why I had a difference on
> dev-python/olefile-0.46 between 2 machines : one was installed with
> python_targets_python3_7, the other wasn't.
> And I finally pinpointed it to package.accept_keywords containing
> "dev-python/olefile ~amd64" on one of the machines only
>
> At the time of writing, dev-python/olefile-0.46 is the stable version, and
> KEYWORDS contains "amd64" (no tilde) among others.
>
> When package.accept_keywords doesn't contain "dev-python/olefile ~amd64",
> I get :
> emerge -pv1 --verbose-conflicts olefile
> These are the packages that would be merged, in order:
> Calculating dependencies... done!
> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
> PYTHON_TARGETS="python2_7 python3_6 (-pypy3) (-python3_7) (-python3_8)" 0
> KiB
> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>
> => Python 3.7 is disabled
>
> When package.accept_keywords contains "dev-python/olefile ~amd64", I get :
> emerge -pv1 olefile
> These are the packages that would be merged, in order:
> Calculating dependencies... done!
> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
> PYTHON_TARGETS="python2_7 python3_6 python3_7* -pypy3 -python3_8" 0 KiB
> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>
> => Python 3.7 is enabled
>
> It seems really really strange to me for the same version of a stable
> package to be "influenced" by keywording.
> Is it a bug or a feature ?
> Did I do something wrong ?
>
> Thanks
> Best regards
> Mickaël Bucas
>

Re: [gentoo-user] I am trying to install app-editors/atom...and portage talks to me in tongues...or so...

[Franz Fellner]

Am So., 5. Jan. 2020 um 19:52 Uhr schrieb :

> On 01/05 07:22, Franz Fellner wrote:
> > Am So., 5. Jan. 2020 um 19:11 Uhr schrieb :
> >
> > >
> > > As far as my knowledge of portagese goes it means: Man, decide what
> > > you want: This software or that software...you cannot get both.
> > >
> > > So I have to decide, whether I want atpm or nodejs...
> > >
> >
> > Portagese is funny, but sometimes Ebuildian is more usefull.
> > Get the basics and dive into the tree of tears.
> > Look at the opposing crumbs of knowledge and - find a third solution!
> >
> > Have fun
> > Franz
>
> Ok, I skip atom.
>

Huh?!? That's not the solution I envisioned.
Just look at the ebuilds, especially the electron. Search for openssl.
Adjust. Profit.


>
> Cheers
> Meino
>
>
>
>

Re: [gentoo-user] I am trying to install app-editors/atom...and portage talks to me in tongues...or so...

[Franz Fellner]

Am So., 5. Jan. 2020 um 19:11 Uhr schrieb :

>
> As far as my knowledge of portagese goes it means: Man, decide what
> you want: This software or that software...you cannot get both.
>
> So I have to decide, whether I want atpm or nodejs...
>

Portagese is funny, but sometimes Ebuildian is more usefull.
Get the basics and dive into the tree of tears.
Look at the opposing crumbs of knowledge and - find a third solution!

Have fun
Franz

Re: [gentoo-user] "Application Menu" missing on Desktop after Plasma update to 5.17.4 : bug reported

[Franz Fellner]

Here is a patch that brings back LMB actions when the applets are locked.
With unlocked applets LMB is needed for editing, and I didn't want to spend
too much time on it.
Read here for some discussion:
https://phabricator.kde.org/D24748
But better than nothing, isn't it? ;)

Place it into /etc/portage/patches/kde-plasma/plasma-workspace/ and
reemerge plasma-workspace.
--- plasma-workspace-5.17.4/components/containmentlayoutmanager/appletslayout.cpp.org	2020-01-04 08:43:18.958318856 +0200
+++ plasma-workspace-5.17.4/components/containmentlayoutmanager/appletslayout.cpp	2020-01-04 08:51:56.229879126 +0200
@@ -530,6 +530,11 @@
 
 void AppletsLayout::mousePressEvent(QMouseEvent *event)
 {
+if (!m_editMode && m_editModeCondition == AppletsLayout::Locked) {
+event->setAccepted(false);
+return;
+}
+
 forceActiveFocus(Qt::MouseFocusReason);
 
 if (!m_editMode && m_editModeCondition == AppletsLayout::Manual) {

Re: [gentoo-user] KDE panel shows wrong time

[Franz Fellner]

The top entry in the "time zone" config page is "local" "system time zone"
(or something like that, I don't run the desktop in English.)
What does it say there in the leftmost column?

To force the clock to "Toronto" you can simply uncheck the box for every
other than "Toronto".


Am So., 29. Dez. 2019 um 05:12 Uhr schrieb Philip Webb :

> 191228 Philip Webb wrote:
> >> I've also had another KDE desktop problem for a long time.
> >> The clock on the panel claims it's showing EST (N America),
> >> but in fact deducts another  5 hr , so 06:32 EST shows as 01:32 EST.
> > The 'date' command give : 'Sat 28 Dec 2019 09:44:07 PM EST' correctly.
> > the digital clock in the panel continues to show '16:44:07 EST' ;
> > When I look at the 'Date + Time' display itself,
> > the analog clock shows the correct time, as does the legend below.
>
> I just checked Fluxbox : its panel clock showed '22:06' correctly.
>
> --
> ,,
> SUPPORT ___//___,   Philip Webb
> ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
> TRANSIT`-O--O---'   purslowatchassdotutorontodotca
>
>
>

Re: [gentoo-user] "Application Menu" missing on Desktop after Plasma update to 5.17.4 : solved

[Franz Fellner]

This sounds like a bug to me.
Could you please report it on bugs.gentoo.org.
This is a regression and should prevent stabilization of 5.17.
There is still one more bug fix release until we hit a stable candidate
5.17.5.

Thx
Franz

Am So., 29. Dez. 2019 um 08:54 Uhr schrieb Philip Webb :

> I've solved the missing L-click problem quite simply for my own use.
>
> Use R-click to open the desktop context menu -> Configure Desktop
> -> Mouse Actions -> Right Button : make it Application Launcher ;
> that brings back the desktop menu of applications.
>
> There was  1  problem : I could no longer access the context menu !
> So I changed the line in  plasma-whatsit  in  ~/.config
> to make the middle button bring up 'contextmenu' & everything was usable.
> I had lost the possibility of dumping text into a sticky note,
> but as I never want to do that in real life, it's an advantage.
>
> L-click still does nothing on the desktop, but I can live with that.
>
> HTH
>
> --
> ,,
> SUPPORT ___//___,   Philip Webb
> ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
> TRANSIT`-O--O---'   purslowatchassdotutorontodotca
>
>
>

Re: [gentoo-user] Kernel option missing - very frustrating...

[Franz Fellner]

I can't see CONFIG_VIDEO_DEV in your list.

Am So., 15. Dez. 2019 um 19:26 Uhr schrieb Daniel Frey :

> Well, I bought a new TV tuner card for MythTV, a Hauppauge QuadHD.
>
> It uses the cx23885 driver, but I can't find it anywhere.
>
> According to menuconfig:
>
> Symbol: VIDEO_CX23885 [=n]
>
>
>
> Type  : tristate
>
>
>
> Prompt: Conexant cx23885 (2388x successor) support
>
>
>Location:
>  -> Device Drivers
>
>
>  -> Multimedia support (MEDIA_SUPPORT [=y])
>
>
> (1) -> Media PCI Adapters (MEDIA_PCI_SUPPORT [=y])
>
> But it isn't there.
>
> I checked its dependencies:
>
> Depends on: MEDIA_SUPPORT [=y] &&
>MEDIA_PCI_SUPPORT [=y] &&
>(MEDIA_ANALOG_TV_SUPPORT [=n] || MEDIA_DIGITAL_TV_SUPPORT [=y]) &&
>DVB_CORE [=y] &&
>VIDEO_DEV [=n] &&
>PCI [=y] &&
>I2C [=y] &&
>INPUT [=y] &&
>SND [=y] &&
>RC_CORE [=y]
>
> ..and... :
>
> # grep
> 'CONFIG_MEDIA_SUPPORT=\|CONFIG_MEDIA_PCI_SUPPORT=\|CONFIG_MEDIA_ANALOG_TV_SUPPORT=\|CONFIG_MEDIA_DIGITAL_TV_SUPPORT=\|CONFIG_DVB_CORE=\|CONFIG_VIDEO_DEV=\|CONFIG_PCI=\|CONFIG_I2C=\|CONFIG_INPUT=\|CONFIG_SND=\|CONFIG_RC_CORE='
>
> .config
> CONFIG_PCI=y
> CONFIG_INPUT=y
> CONFIG_I2C=y
> CONFIG_RC_CORE=y
> CONFIG_MEDIA_SUPPORT=y
> CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y
> CONFIG_DVB_CORE=y
> CONFIG_MEDIA_PCI_SUPPORT=y
> CONFIG_SND=y
>
> So why on earth isn't it showing? The dependencies should be satisfied.
> I hope someone has some insight... I've had this problem before with
> tuner cards not showing and I can't remember how I fixed it.
>
> Kernel version is 5.4.2, but I also tried 4.14.143 with no difference...
>
>
> Dan
>
>

Re: [gentoo-user] Changing git upstream server

[Franz Fellner]

You manage remote repositories with git remote.
git remote set-url origin 
should do it.

Am So., 15. Dez. 2019 um 12:07 Uhr schrieb J. Roeleveld :

> On 15 December 2019 11:02:16 CET, Peter Humphrey 
> wrote:
> >Hello list,
> >
> >Would someone remind me, please, of the git command I need to issue to
> >change
> >its upstream sync source? I'm debugging a local repo and I'd prefer not
> >to
> >keep removing the whole tree just to sync it again from a different
> >upstream
> >server.
>
> I don't know the command, but it is stored in ".git/config" inside the
> tree.
>
> --
> Joost
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>

Re: [gentoo-user] Problems with numpy and python 3x

[Franz Fellner]

It can't have been "just an update" because python-3.7 is your default
python, so you have selected it after the update.
Alternatively: Your numpy doesn't work for a longer time and you just
didn't realize until now.

numpy was built for python-3.6 and not for python3.7. Which is perfectly
fine as it is gentoos default -
base/make.defaults:PYTHON_TARGETS="python2_7 python3_6".
So why did you install python-3.7 and set it as default although your
system isn't prepared for it?

Am So., 15. Dez. 2019 um 08:07 Uhr schrieb :

> Hi,
>
> after the update this morning, "numpy" wasn't found anumore by python.
>
> Asking python, it gave me:
> Python 3.7.5 (default, Dec 15 2019, 05:23:14)
> [GCC 9.2.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import numpy
> Traceback (most recent call last):
>   File "", line 1, in 
> ModuleNotFoundError: No module named 'numpy'
> >>>
>
> eix numpy gave me:
>
>
> [U] dev-python/numpy
>  Available versions:  1.14.5^t (~)1.15.4^t (~)1.16.1^t (~)1.16.5^t
> (~)1.17.4^t {doc lapack test PYTHON_TARGETS="python2_7 python3_5 python3_6
> python3_7 python3_8"}
>  Installed versions:  1.16.5^t(06:31:45 AM 12/15/2019)(lapack -doc
> -test PYTHON_TARGETS="python2_7 python3_6 -python3_5 -python3_7")
>  Homepage:https://www.numpy.org
>  Description: Fast array and numerical python library
>
>
> emergeing it with
>
> emerge --selective=n dev-python/numpy
>
> results in the same output of eix.
>
> Interestingly a post on stackexchange related to the problem of "numpy
> not found" states (source:
> https://stackoverflow.com/questions/7818811/import-error-no-module-named-numpy_
> )
>
> "Support for Python 3 was added in NumPy version 1.5.0, so to begin with,
> you must download/install a newer version of NumPy."
>
> and links to this address:
> https://sourceforge.net/projects/numpy/files//NumPy/1.5.0/NOTES.txt/view
> which states the same.
>
> A version of numpy >= 1.5 is not offered by portage repo it seems, but
> python 3.x is.
>
> pip3 says, everything is fine, numpy is installed:
>
> pip3 install --user numpy
> Requirement already satisfied: numpy in /usr/lib64/python3.6/site-packages
> (1.16.5)
>
> But this does not fit the installed python version according to the
> linked sources above.
>
> How can I solve this problem?
>
> (I am on "unstable"...)
>
> Cheers!
> mcc
>
>
>
>

Re: [gentoo-user] Conflicting version...but the version scheme is confusing...

[Franz Fellner]

Am Sa., 30. Nov. 2019 um 11:34 Uhr schrieb Mick :

> On Saturday, 30 November 2019 07:17:01 GMT Franz Fellner wrote:
> > inkscape-0.92.4 has the same issue.
> > The problem is that the API (Programming interface, not Binary interface)
> > between imagemagick-6 and imagemagick-7 isn't compatible.
> > And inkscape never was updated to use the API from imagemagick-7.
>
> Yes, that's exactly the problem.
>
> media-gfx/inkscape-0.92.4 which is presently the stable version is quite
> happy
> with media-gfx/imagemagick-7.0.9.5.
>

Ah. It's 7.0.8.5, not 7.0.9.5:
https://bugs.gentoo.org/663468#c5
Some deprecated features of the API were removed. Unfortunately also the
pkgconfig file was renamed to Magick++ which made inkscape silently disable
imagemagick support and the compilation failure/incompatibility wasn't
noticed for a long time.


> However, the unstable version of inkscape-1.0_beta1 requires imagemagick
> versions prior to 7.0.9.5, with the currently available version of
> imagemagick-6.9.10.74 fulfilling the requirement.
>

imakemagick-7.0.8.5, again. Not that nobody will stay confused.


> > 1) entirely disable imagemagick for inkscape, e.g. with
> "media-gfx/inkscape
> > -imagemagick" in package.use
>
> If you do this, you'll find that conversions and imports/exports from one
> graphics file format to another would be somewhat limited.  Imagemagick
> relies
> on inkscape for this functionality.
>

The other way around, inkscape needs imagemagick for such conversions.

I don't know how limiting it will be. If all you want to do is create pure
vector graphics you are good to go.

> 2) Use inkscape-1.0.0_beta1 and enable both USE-Flags "imagemagick
> > graphicsmagick".
> > That way you will get the imagemagick features through
> graphicsmagick,
> > which means imagemagick is not a dependency of inkscape anymore.
>
> Right, but graphicsmagick is more limited in its functionality than
> imagemagick.  For a poweruser of imagemagick this may present a problem -
> but
> I don't know how big a problem it might be.


You aren't forced to build graphicsmagick as a complete replacement for
imagemagick.
You only need the C++-API for inkscape and not the commandline tools.
Put "media-gfx/graphicsmagick cxx -imagemagick" in your package.use and
imagemagick and graphicsmagick can be installed at the same time.

Re: [gentoo-user] Conflicting version...but the version scheme is confusing...

[Franz Fellner]

inkscape-0.92.4 has the same issue.
The problem is that the API (Programming interface, not Binary interface)
between imagemagick-6 and imagemagick-7 isn't compatible.
And inkscape never was updated to use the API from imagemagick-7.
That's why you are forced to downgrade imagemagick to a version lower than
7 when you want to use imagemagick in inkscape.
If you want to stay with imagemagick >=7 you have two options:
1) entirely disable imagemagick for inkscape, e.g. with "media-gfx/inkscape
-imagemagick" in package.use
2) Use inkscape-1.0.0_beta1 and enable both USE-Flags "imagemagick
graphicsmagick".
That way you will get the imagemagick features through graphicsmagick,
which means imagemagick is not a dependency of inkscape anymore.

Regards
Franz

Re: [gentoo-user] libffi-3.3.0-rc0

[Franz Fellner]

No mistake:
https://bugs.gentoo.org/694978

Am Sa., 28. Sept. 2019 um 19:54 Uhr schrieb Ian Zimmerman <
i...@very.loosely.org>:

> After my weekly webrsync this morning, emerge -p showed me a whale of an
> upgrade, including rebuilding both pythons, llvm and firefox, on top of
> the legitimate and long overdue texlive update.  It would have taken
> half a day even on a reasonably capable desktop.
>
> Inspecting the -p output I blame libffi, and indeed using the
> package.mask file to block its new version I got a more manageable
> upgrade.  My question is, how come a -rc0 version got unkeyworded?  Does
> this normally happen or was it a mistake?
>
> --
> Please don't Cc: me privately on mailing lists and Usenet,
> if you also post the followup to the list or newsgroup.
> To reply privately _only_ on Usenet and on broken lists
> which rewrite From, fetch the TXT record for no-use.mooo.com.
>
>

Re: [gentoo-user] Dolphin only allowing a single instance after update

[Franz Fellner]

You might want to have a play with kbuildsycoca5 after editing .desktop
files.
Look at the options (--help I think, or --help-all), I can't help with that
ATM.
It should rebuild the system config cache - reparse the .desktop files.

Good luck
Franz

Am Fr., 23. Aug. 2019 um 12:49 Uhr schrieb Dale :

> Mick wrote:
> > On Friday, 23 August 2019 05:56:07 BST Dale wrote:
> >>   It seems it is hardcoded to do this at the moment.
> >> This seriously makes me want to start using another file manager.  I
> >> don't mind someone testing new features but at the very least, have it
> >> where it can be disabled for those who do not want it or are set up not
> >> to need it.
> > You're missing the point!  As soon as something works as most users
> want, or
> > becoming used to at any rate, the KDE devs will  /improve/ their
> > software by breaking its most desired functionality - sometimes
> irrepairably.
> > LOL!
> >
> > Konqueror was the best file manager ever, with multiple vertical and
> > horizontal window split, with kio-slaves which would process or play
> anything
> > and everything you threw at it, with browser integration, ftp/s and
> sftp/fish,
> > etc.  Nope, evidently konqueror wasn't good enough, so here comes
> dolphin
> > which can't do half of what konqueror was able to offer us.  I better
> not
> > mention kmail2, because I don't want anyone to think this message was
> written
> > by Edgar Allan Poe.  :-(
> >
>
>
> I hear you very clearly.  I had my desktop set up just like I needed it
> so that I didn't have to spend time navigating to things.  Bad thing is,
> by the time I figured out it was clobbering already running instances, I
> had closed some tabs/windows and lost my place.  On a couple of them,
> there is no way for me to know where I left off.  When I stop editing
> pictures or videos for example, I always highlight or select the last
> one I did.  If I'm going to logout or something, I write all that info
> down so I know where I left off.  When a tab gets closed and I don't
> write it down, no clue where I was at.  It's one reason I had to wait a
> bit to logout and back in to test that patch.  I had to get to a
> stopping place and not be downloading anything either.  It takes time to
> get to that spot.  This new feature really messed me up.  If they going
> to release some change like this, they should warn people about it.
> Sort of like Gentoo's news item or something and already have a way to
> do it the old way.
>
> I remember Konqueror. It's still around I think but a lot of things are
> broken or removed last I looked.  Thing is, you could do a LOT of things
> with that one tool.  Need to copy from another system, no problem.  Need
> it done securely, still not a problem.  Need a plain file manager, no
> problem.  That thing was powerful to say the least.  Honestly, I still
> miss the thing.  I really liked running it as root as a file manager.  I
> never used it to access the internet as root but as a file manager, it
> was awesome.  Dolphin started to stink so much, I switched to Krusader.
>
> Yea, those were the days.  lol
>
> Dale
>
> :-)  :-)
>
>

Re: [gentoo-user] Re: Linux: "make menuconf" creates a hardly useable interface

[Franz Fellner]

I am sure nconfig does the same thing as menuconfig and xconfig.
Concerning your issue with menuconfig: Is this with a new kernel? Do older
kernel versions still play well with menuconfig?

Am Sa., 12. Jan. 2019 um 19:49 Uhr schrieb :

> On 01/12 07:47, Franz Fellner wrote:
> > No issues here with "make nconfig", like that more than menuconfig.
> >
> > Am Sa., 12. Jan. 2019 um 19:23 Uhr schrieb :
> >
> > > On 01/12 06:53, Nikos Chantziaras wrote:
> > > > On 12/01/2019 18:52, Nikos Chantziaras wrote:
> > > > > On 12/01/2019 18:10, tu...@posteo.de wrote:
> > > > > > On 01/12 04:59, tu...@posteo.de wrote:
> > > > > > > On 01/12 05:15, Nikos Chantziaras wrote:
> > > > > > > > On 12/01/2019 16:09, tu...@posteo.de wrote:
> > > > > > > > > when calling "make menuconf" on a linux kernel source after
> > > > > > > > > a short period of time a ncurses-like interface pop up. But
> > > > > > > > > since some interations of the linux kernel this interface
> > > > > > > > > has become a mess: Line contents is offsetted all over the
> > > place.
> > > > > > > >
> > > > > > > > What terminal are you using? Try a different one.
> > > > > > >
> > > > > > > At worked for years, with terminal.
> > > > > >
> > > > > > ooops...typo should be:
> > > > > >
> > > > > >   At worked for years, with this terminal.
> > > > >
> > > > > Well, I just mentioned it because a while ago I had exactly the
> same
> > > > > problem with Konsole 18.04. It's fixed now, but back then I had to
> use
> > > > > another terminal application as a workaround.
> > > >
> > > > And this was the bug report, which includes screenshots of the
> problem:
> > > >
> > > > https://bugs.gentoo.org/648338
> > > >
> > > >
> > >
> > > I am using x11-terms/rxvt-unicode-9.22-r1
> > >
> > >
> > >
> > >
>
> ...only to get sure:
> The functionality of 'make nconfig'is identically to 'make menuconfig'
> ?
>
>
>
>
>

Re: [gentoo-user] Re: Linux: "make menuconf" creates a hardly useable interface

[Franz Fellner]

No issues here with "make nconfig", like that more than menuconfig.

Am Sa., 12. Jan. 2019 um 19:23 Uhr schrieb :

> On 01/12 06:53, Nikos Chantziaras wrote:
> > On 12/01/2019 18:52, Nikos Chantziaras wrote:
> > > On 12/01/2019 18:10, tu...@posteo.de wrote:
> > > > On 01/12 04:59, tu...@posteo.de wrote:
> > > > > On 01/12 05:15, Nikos Chantziaras wrote:
> > > > > > On 12/01/2019 16:09, tu...@posteo.de wrote:
> > > > > > > when calling "make menuconf" on a linux kernel source after
> > > > > > > a short period of time a ncurses-like interface pop up. But
> > > > > > > since some interations of the linux kernel this interface
> > > > > > > has become a mess: Line contents is offsetted all over the
> place.
> > > > > >
> > > > > > What terminal are you using? Try a different one.
> > > > >
> > > > > At worked for years, with terminal.
> > > >
> > > > ooops...typo should be:
> > > >
> > > >   At worked for years, with this terminal.
> > >
> > > Well, I just mentioned it because a while ago I had exactly the same
> > > problem with Konsole 18.04. It's fixed now, but back then I had to use
> > > another terminal application as a workaround.
> >
> > And this was the bug report, which includes screenshots of the problem:
> >
> > https://bugs.gentoo.org/648338
> >
> >
>
> I am using x11-terms/rxvt-unicode-9.22-r1
>
>
>
>

Re: [gentoo-user] Re: Where is ustat.h?

[Franz Fellner]

❯ qfile /usr/include/sys/ustat.h
sys-libs/glibc (/usr/include/sys/ustat.h)

~ 36s
❯ eix -e glibc
[I] sys-libs/glibc
 Available versions:  (2.2) [M]**2.19-r2^s [M]2.21-r2^s [M]2.22-r4^s
[M]2.23-r4^s [M]~2.24-r4^s [M]2.25-r11^s [M]2.26-r7^s 2.27-r6^s ~2.28-r4^s
**^s
   {audit caps cet compile-locales debug doc gd hardened headers-only
+multiarch multilib nscd profile +rpc selinux suid systemtap test vanilla}
 Installed versions:  2.27-r6(2.2)^s(09:53:17 25.10.2018)(multiarch
multilib -audit -caps -compile-locales -doc -gd -hardened -headers-only
-nscd -profile -selinux -suid -systemtap -vanilla)
 Homepage:https://www.gnu.org/software/libc/
 Description: GNU libc C library

Am Mi., 2. Jan. 2019 um 12:46 Uhr schrieb Nikos Chantziaras <
rea...@gmail.com>:

> On 02/01/2019 12:27, Peter Humphrey wrote:
> > I'm trying to compile gcc-7.3.0-r3 to test a hypothesis, but I get this
> > failure:
> >
> >
> /var/tmp/portage/sys-devel/gcc-7.3.0-r3/work/gcc-7.3.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:157:10:
> fatal error: sys/ustat.h: No such file or directory
> >   #include 
> >
> > I thought it might be in sys-kernel/linux-headers, but installing a
> > contemporaneous version didn't help. Google doesn't, either.
> >
> > Can anyone point me in the right direction?
>
> It seems it was provided by old glibc versions. It doesn't exist anymore.
>
>
>

Re: [gentoo-user] ...I not allowed to make pdfs from images??????

[Franz Fellner]

Check your /etc/ImageMagick-7/policy.xml
But be aware of the riscs, see the comment in the very same policy.xml file

Am Sa., 8. Dez. 2018 um 15:22 Uhr schrieb :

> Hi,
>
> from some images I want to create a pdf.
> I found this commandline to do so (imagemagick):
> convert 1.png 2.ong 3.png result.pdf
>
> If I do so I got this message:
> convert: attempt to perform an operation not allowed by the security
> policy `PDF' @ error/constitute.c/IsCoderAuthorized/408.
>
> What the heck...
>
> How can I allow myself to work on my compyter ? ;)
>
> Cheers!
> Meino
>
>
>
>
>

Re: [gentoo-user] problem updating KDE breeze : solved

[Franz Fellner]

Nice that you could solve it!

There is already a report on bugs.gentoo.org which unfortunately can't be
found with a search for "breeze" as it's state is "RESOLVED TEST-REQUEST".
https://bugs.gentoo.org/660896
The reporter never came back to confirm that reemerging kdeclarative solved
the issue.

Am Mo., 22. Okt. 2018 um 07:53 Uhr schrieb Philip Webb :

> 181022 Philip Webb wrote:
> > /usr/lib64/libKF5Declarative.so.5: undefined reference to
> `QQmlPropertyMap::init(QMetaObject const*)@Qt_5'
> > /usr/lib64/libKF5Declarative.so.5: undefined reference to
> `QQmlPropertyMap::allocatePrivate()@Qt_5'
> > collect2: error: ld returned 1 exit status
> > make[2]: ***
> [kstyle/config/CMakeFiles/breeze-settings5.dir/build.make:121:
> kstyle/config/breeze-settings5] Error 1
>
> The file causing the problem belongs to  kde-frameworks/kdeclarative :
>
>   root:586 ~> equery belongs /usr/lib64/libKF5Declarative.so.5
> kde-frameworks/kdeclarative-5.50.0
> (/usr/lib64/libKF5Declarative.so.5.50.0)
> kde-frameworks/kdeclarative-5.50.0 (/usr/lib64/libKF5Declarative.so.5
> -> libKF5Declarative.so.5.50.0)
>
> I updated it the previous weekend :
>
>   root:587 ~> eix kdeclar
> [I] kde-frameworks/kdeclarative
>   Available versions:  (5) 5.50.0(5/5.50) ~5.51.0(5/5.51) {debug doc}
>   Installed versions:  5.50.0(5/5.50)([2018-10-13 11:50:09])(-debug
> -doc)
>
> So I just tried the obvious & re-merged Kdeclarative.
> After I did that, Breeze + the other  5  pkgs merged successfully.
> Somewhere in the toils of the ebuilds, there's a missing requirement,
> but if anyone else runs into this, it's now on record here.
>
> I would have worked this out for myself,
> if I had known there cb  > 1  'Error' in emerge output.
> Thanks to you both for educating me : I'll add a note to my help files.
>
> (Big smile)
>
> --
> ,,
> SUPPORT ___//___,   Philip Webb
> ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
> TRANSIT`-O--O---'   purslowatchassdotutorontodotca
>
>
>

Re: [gentoo-user] problem updating KDE breeze

[Franz Fellner]

Hi Philipp,
the actual error really is missing.
Can you use pastebin or something similar to upload the whole build.log?

The number of cores may help to estimate the unmber of compilation units
that still get built.
Unfortunately not with cmake. It usually continues building targets that do
not depend on the failed target.
You may have to scroll up hundreds of lines.

So, again: Please give us the complete buld.log!

Thx
Franz


Am So., 21. Okt. 2018 um 10:30 Uhr schrieb Philip Webb :

> 181021 Dale wrote:
> > You need to go back further on your copy n paste.
> > The first error I see error 2.  Somewhere further back is error 1.
>
> I don't think so : isn't that the type of error taken from a list ?
> I don't see another error higher up.
>
> > That is the first trigger and may point to a problem.
> > I usually go back 20 or 30 lines before error 1
> > just to be sure I went back far enough.
> > I have a 4 core CPU here.
>
> Whatever does that have to do with the problem ?
>
> > My only other suggestion is to make sure you have not run out of space,
> > either hard drive mount point or memory if using tmpfs.
> > That can cause a strange error
> > because it fails wherever it runs out of space.
> > Sometimes it fails at different spots too.
>
> There's no reason to expect that here.
>
> Thanks for trying, but I believe the problem is somewhere else.
>
> --
> ,,
> SUPPORT ___//___,   Philip Webb
> ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
> TRANSIT`-O--O---'   purslowatchassdotutorontodotca
>
>
>

Re: [gentoo-user] Rust problem when upgrading Firefox

[Franz Fellner]

My "other advice" would be to simply use rust-bin.

Am Di., 16. Okt. 2018 um 11:25 Uhr schrieb Mick :

> On Monday, 15 October 2018 19:49:59 BST Philip Webb wrote:
> > 181015 Dale wrote:
> > > Just curious, did you notice this little part?
> > > "LLVM ERROR: IO failure on output stream: No space left on device"
> > > You may want to make sure you are not out of disk space
> > > wherever your tmp directory is or out of ram if you use tmpfs.
> >
> > Yes, I did, as I said, & added  2  lines to 'package.env'.
> > That solved that problem, which was surprising :
> > my explanation is that FF itself is too big to use 'tmpfs'
> > & this then squeezes out any other pkgs to be compiled along with it,
> > even a tiny virtual.  Otherwise, the 1st problem was USE flags.
> >
> > The new FF requires some very big items, which took a long time to
> emerge :
> > Rust (59), Clang (11), Llvm (15), FF (33) : total  118 min .
> > The total download was  c 500 MB .  LO is modest in comparison.
> >
> > Now to get some groceries, then I'll try it out.
> > The big question is whether I can still group tabs,
> > whether directly with FF or via some add-on (whatever they're now
> called).
> >
> > Thanks for offering a bit of help.
>
> I've noticed the same both in terms of the dependencies now being drawn in
> and
> in terms of how much RAM the compile consumes.  On systems with low RAM I
> set
> lower MAKEOPTS jobs and average values and add plenty of swap.  This keeps
> emerge in check and stops it from swapping in and out continuously
> thrashing
> the disk.
>
> More than a year ago I'd noticed similar uncontrolled consumption of
> resources
> by emerge on Chromium.  Interestingly a few versions later something must
> have
> changed (some hardware limit checks added by devs?) and Chromium became
> much
> less hungry for resources.
> --
> Regards,
> Mick

Re: [gentoo-user] python-3.6.5 rebuild fails on new install

[Franz Fellner]

Seems to be a known issue and probably fixed in gcc-7.4.0:
https://bugs.gentoo.org/662208
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83317

This error is also used in the Gentoo gcc internal compiler error reporting
wiki page:
https://wiki.gentoo.org/wiki/Gcc-ICE-reporting-guide

Am Mo., 20. Aug. 2018 um 08:23 Uhr schrieb Adam Carter <
adamcart...@gmail.com>:

>   I just tried with MAKEOPTS="-j1" and got the same failure output at
>> the same place.  I normally run with the number equal to the number of
>> cores.  On this notebook MAKEOPTS="-j2".  Are there any other
>> memory-conserving tweaks available?
>>
>
> I guess you've stopped all the non-essential services and programs.
>
> Does top or free -m confirm that you're running out of space? If so, you
> could create a temporary swap file on an existing filesystem (
> https://www.cyberciti.biz/faq/linux-add-a-swap-file-howto/) or make a USB
> drive into some temporary swap get you through the build
>
>

Re: [gentoo-user] python-3.6.5 rebuild fails on new install

[Franz Fellner]

I think the memory is only used in the context of OpenGL (or when it's used
for computing like with OpenCL).
I am sure you won't run out of memory when compiling on a pure text console
because of the grahics driver.


Am So., 19. Aug. 2018 um 05:27 Uhr schrieb Walter Dnes <
waltd...@waltdnes.org>:

>   One interesting item early on in dmesg...
>
> [0.173494] [drm] Memory usable by graphics device = 2048M
> [0.173591] [drm] Replacing VGA console driver
>
>   Would the "graphics driver" be capable of using up 2 gigs of ram in
> a pure text console?  On a 3-gig machine, that would be very bad.
>
> --
> Walter Dnes 
> I don't run "desktop environments"; I run useful applications
>
>

Re: [gentoo-user] Is this a portage bug?

[Franz Fellner]

I think that's the way "equery w" works:
>> Display the path to the ebuild that would be used by Portage with the
current configuration. <<
With your current configuration there is no package matching your query.

Alternatives for future use in such cases:
❯ epkginfo -k kyocera-1x2x-mfp-driver
 * net-print/kyocera-1x2x-mfp-driver [gentoo]
1.1203-r1:0: ~amd64 -*

❯ equery y kyocera-1x2x-mfp-driver
Keywords for net-print/kyocera-1x2x-mfp-driver:
  |   a |   |
  |   m |   |
  |   d   x |   |
  |   6   8 |   |
  |   4   6 |   u   |
  | a a   a p   s |   | |   n   |
  | l m   r i   p   h m s   p f m f | e u s | r
  | p d a m a p c x p 6 3   a b i b | a s l | e
  | h 6 r 6 6 p 6 8 p 8 9 s r s p s | p e o | p
  | a 4 m 4 4 c 4 6 a k 0 h c d s d | i d t | o
--+-+---+---

1.1203-r1 | * ~ * * * * * * * * * * * * * * | 6 o 0 | gentoo

Am Mi., 15. Aug. 2018 um 12:23 Uhr schrieb Peter Humphrey <
pe...@prh.myzen.co.uk>:

> On Wednesday, 15 August 2018 09:50:09 BST Franz Fellner wrote:
> >
> > Am Mi., 15. Aug. 2018 um 11:29 Uhr schrieb Peter Humphrey <
> >
> > pe...@prh.myzen.co.uk>:
> > > Hello list,
> > >
> > > While trying to get a USB printer recognised on an Atom box, I found
> > > this, immediately after emerge --sync && eix-update:
> > >
> > > (atom) peak / # eix -c kyocera
> > > [N] net-print/kyocera-1x2x-mfp-driver (--): Printer descriptions (PPDs)
> > > and filters for Kyocera 1x2x MFP
> > > [N] net-print/kyocera-mita-ppds ((~)8.4-r1{tbz2}): PPD description
> files
> > > for (some) Kyocera Mita Printers
> > > Found 2 matches
> > >
> > > (atom) peak / # emerge -pv net-print/kyocera-1x2x-mfp-driver
> > > net-print/kyocera-mita-ppds
> > >
> > > These are the packages that would be merged, in order:
> > >
> > > Calculating dependencies  ... done!
> > >
> > > !!! All ebuilds that could satisfy "net-print/kyocera-1x2x-mfp-driver"
> > > have been masked.
> > > !!! One of the following masked packages is required to complete your
> > > request:
> > > - net-print/kyocera-1x2x-mfp-driver-1.1203-r1::gentoo (masked by:
> > > missing keyword)
> > >
> > > (atom) peak / # grep kyocera /etc/portage/package.keywords
> > > net-print/kyocera-1x2x-mfp-driver
> > > net-print/kyocera-mita-ppds
> > >
> > > I wonder whether the "1x2x" is confusing portage.
>
> > It's ~amd64 only. So if you get missing keyword, could it be you are on
> > x86?
>
> This is an X86 box (Atom N270), but it's more complex than that:
>
> (atom) peak / # equery w net-print/kyocera-1x2x-mfp-driver
> !!! No packages matching 'net-print/kyocera-1x2x-mfp-driver'
> (atom) peak / # ls -l /usr/portage/net-print/kyocera-1x2x-mfp-driver
> total 7.0K
> drwxr-xr-x 2 portage portage 1.0K Sep  6  2017 files
> -rw-r--r-- 1 portage portage 3.4K Jan 15  2018
> kyocera-1x2x-mfp-driver-1.1203-r1.ebuild
> -rw-r--r-- 1 portage portage  317 Dec 12  2017 Manifest
> -rw-r--r-- 1 portage portage  529 Sep  6  2017 metadata.xml
>
> Thus my usual use of portage tools failed, so I didn't get as far as seeing
> this:
>
> (atom) peak / # grep KEYWORDS
> /usr/portage/net-print/kyocera-1x2x-mfp-driver/*ebuild
> KEYWORDS="-* ~amd64"
>
> Something does seem to be, if not broken, somewhat bent.
>
> --
> Regards,
> Peter.
>
>
>
>
>

Re: [gentoo-user] Is this a portage bug?

[Franz Fellner]

It's ~amd64 only. So if you get missing keyword, could it be you are on x86?

Am Mi., 15. Aug. 2018 um 11:29 Uhr schrieb Peter Humphrey <
pe...@prh.myzen.co.uk>:

> Hello list,
>
> While trying to get a USB printer recognised on an Atom box, I found this,
> immediately after emerge --sync && eix-update:
>
> (atom) peak / # eix -c kyocera
> [N] net-print/kyocera-1x2x-mfp-driver (--): Printer descriptions (PPDs)
> and filters for Kyocera 1x2x MFP
> [N] net-print/kyocera-mita-ppds ((~)8.4-r1{tbz2}): PPD description files
> for (some) Kyocera Mita Printers
> Found 2 matches
>
> (atom) peak / # emerge -pv net-print/kyocera-1x2x-mfp-driver
> net-print/kyocera-mita-ppds
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies  ... done!
>
> !!! All ebuilds that could satisfy "net-print/kyocera-1x2x-mfp-driver"
> have been masked.
> !!! One of the following masked packages is required to complete your
> request:
> - net-print/kyocera-1x2x-mfp-driver-1.1203-r1::gentoo (masked by: missing
> keyword)
>
> (atom) peak / # grep kyocera /etc/portage/package.keywords
> net-print/kyocera-1x2x-mfp-driver
> net-print/kyocera-mita-ppds
>
> I wonder whether the "1x2x" is confusing portage.
>
> --
> Regards,
> Peter.
>
>
>
>
>

Re: [gentoo-user] KDE: wtf

[Franz Fellner]

I wanted to add that there is a similar bug report:
https://bugs.gentoo.org/592140
Closed as INVALID. Go through the comments and see if the reason is similar.

2018-07-28 9:14 GMT+03:00 Franz Fellner :

> Please tame your tongue.
>
> The correct package would have been qtx11extras.
> But it is already in the dependencies when you build kwindowsystem with
> USE="X".
>
> Post the output of
> emerge -pv kwindowsystem
> And also have a look into /etc/portage/package.provided if it contains
> qtx11extras.
>
> Of course it could be that there is some issue with how Gentoo sets up the
> build for kwindowsystem.
> In that case you might want to create an issue on bugs.gentoo.org.
>
>
> 2018-07-28 8:02 GMT+03:00 Alan Grimes :
>
>> Kde is still broken here, I want to reboot before declaring Steam still
>> dead...
>>
>> I read some vomit just now and it's like:
>>
>> ###
>> -- Found PkgConfig: x86_64-pc-linux-gnu-pkg-config (found version
>> "0.29.2")
>> -- Found XCB_XCB: /usr/lib/libxcb.so (found version "1.13")
>> -- Found XCB_KEYSYMS: /usr/lib/libxcb-keysyms.so (found version "0.4.0")
>> -- Found XCB: /usr/lib/libxcb.so;/usr/lib/libxcb-keysyms.so (found
>> version "1.13") found components:  XCB KEYSYMS
>> CMake Error at /usr/lib64/cmake/Qt5/Qt5Config.cmake:28 (find_package):
>>   Could not find a package configuration file provided by "Qt5X11Extras"
>> with
>>   any of the following names:
>>
>> Qt5X11ExtrasConfig.cmake
>> qt5x11extras-config.cmake
>>
>>   Add the installation prefix of "Qt5X11Extras" to CMAKE_PREFIX_PATH or
>> set
>>   "Qt5X11Extras_DIR" to a directory containing one of the above files.  If
>>   "Qt5X11Extras" provides a separate development package or SDK, be sure
>> it
>>   has been installed.
>> Call Stack (most recent call first):
>>   CMakeLists.txt:58 (find_package)
>>
>>
>> -- Configuring incomplete, errors occurred!
>> See also
>> "/var/tmp/portage/kde-frameworks/kwindowsystem-5.48.0/work/
>> kwindowsystem-5.48.0_build/CMakeFiles/CMakeOutput.log".
>>  * ERROR: kde-frameworks/kwindowsystem-5.48.0::gentoo failed (configure
>> phase):
>>  *   cmake failed
>>  *
>>  * Call stack:
>>  * ebuild.sh, line  124:  Called src_configure
>>  *   environment, line 3762:  Called kde5_src_configure
>> ###
>>
>>
>> Okay I'm a bit dumbfounded right now. =(
>>
>> I tried
>> emerge --oneshot kde-frameworks/extra-cmake-modules
>>
>> and that didn't help
>>
>> --
>> Please report bounces from this address to a...@numentics.com
>>
>> Powers are not rights.
>>
>>
>>
>

Re: [gentoo-user] KDE: wtf

[Franz Fellner]

Please tame your tongue.

The correct package would have been qtx11extras.
But it is already in the dependencies when you build kwindowsystem with
USE="X".

Post the output of
emerge -pv kwindowsystem
And also have a look into /etc/portage/package.provided if it contains
qtx11extras.

Of course it could be that there is some issue with how Gentoo sets up the
build for kwindowsystem.
In that case you might want to create an issue on bugs.gentoo.org.


2018-07-28 8:02 GMT+03:00 Alan Grimes :

> Kde is still broken here, I want to reboot before declaring Steam still
> dead...
>
> I read some vomit just now and it's like:
>
> ###
> -- Found PkgConfig: x86_64-pc-linux-gnu-pkg-config (found version "0.29.2")
> -- Found XCB_XCB: /usr/lib/libxcb.so (found version "1.13")
> -- Found XCB_KEYSYMS: /usr/lib/libxcb-keysyms.so (found version "0.4.0")
> -- Found XCB: /usr/lib/libxcb.so;/usr/lib/libxcb-keysyms.so (found
> version "1.13") found components:  XCB KEYSYMS
> CMake Error at /usr/lib64/cmake/Qt5/Qt5Config.cmake:28 (find_package):
>   Could not find a package configuration file provided by "Qt5X11Extras"
> with
>   any of the following names:
>
> Qt5X11ExtrasConfig.cmake
> qt5x11extras-config.cmake
>
>   Add the installation prefix of "Qt5X11Extras" to CMAKE_PREFIX_PATH or set
>   "Qt5X11Extras_DIR" to a directory containing one of the above files.  If
>   "Qt5X11Extras" provides a separate development package or SDK, be sure it
>   has been installed.
> Call Stack (most recent call first):
>   CMakeLists.txt:58 (find_package)
>
>
> -- Configuring incomplete, errors occurred!
> See also
> "/var/tmp/portage/kde-frameworks/kwindowsystem-5.48.
> 0/work/kwindowsystem-5.48.0_build/CMakeFiles/CMakeOutput.log".
>  * ERROR: kde-frameworks/kwindowsystem-5.48.0::gentoo failed (configure
> phase):
>  *   cmake failed
>  *
>  * Call stack:
>  * ebuild.sh, line  124:  Called src_configure
>  *   environment, line 3762:  Called kde5_src_configure
> ###
>
>
> Okay I'm a bit dumbfounded right now. =(
>
> I tried
> emerge --oneshot kde-frameworks/extra-cmake-modules
>
> and that didn't help
>
> --
> Please report bounces from this address to a...@numentics.com
>
> Powers are not rights.
>
>
>

Re: [gentoo-user] Something's messed up my mimetypes

[Franz Fellner]

2018-07-23 18:58 GMT+03:00 Wols Lists :

> How do I find out what mimetypes are associated with an application?
>
> I would just inspect the .desktop files
We use Gentoo here so you know which package installed your application.
for kate it's... kate ;)

$ qlist kate | grep desktop
/usr/share/plasma/plasmoids/org.kde.plasma.katesessions/metadata.desktop
/usr/share/kservices5/plasma-dataengine-katesessions.desktop
/usr/share/kservices5/plasma-applet-org.kde.plasma.katesessions.desktop
/usr/share/applications/org.kde.kate.desktop

$ grep Mime /usr/share/applications/org.kde.kate.desktop
MimeType=text/plain;
Not a big help...

But... kate uses ktexteditor to show text. Do the same there (katepart) and
you should get the mimetypes associated with it.
Which is too long to post here ;)

Re: [gentoo-user] /usr/bin/qtconfig is missing components

[Franz Fellner]

Just for fun:
Open /usr/bin/emerge in a text editor and read the first 10 lines.
Then run
grep python-exec /usr/bin/*

It basically is the same what qtchooser does: Forward a python script to
the appropriate python version.

2018-07-23 13:20 GMT+03:00 Franz Fellner :

> IMO the problem is that qtchooser acts as one point to select ALL
> components for the default Qt, be it qt4 or qt5 (and possibly qt6 in 2020),
> without checking if the tool really exists.
> It just forwards the call to an execuatble with the same name inside the
> qt-installation's bin dir. (/usr/lib/qt...)
> qtconfig got removed and people (with DEs lacking qt integration) couldn't
> configure their fonts/colors/widget style/... anymore. So someone just
> started to develop a third-party config tool to fill the gap.
> qtchooser on the other hand is an official qt tool (at least it is hosted
> on qt's servers). I think that's why they don't just call qt5ct ;) And it
> would introduce a speacial case for just this one tool.
>
>
> 2018-07-23 13:05 GMT+03:00 Mick :
>
>> On Monday, 23 July 2018 10:09:38 BST Franz Fellner wrote:
>> > Yeah, stupid qtchooser ;)
>> >
>> > qtconfig got dropped, use x11-misc/qt5ct instead.
>>
>> Thanks Franz, qtconfig used to be installed by default with Qt.  I wonder
>> why
>> x11-misc/qt5ct isn't treated the same, especially as qtconfig is left on
>> the
>> box and is symlinked to qtchooser now.  :-/
>>
>> --
>> Regards,
>> Mick
>
>
>

Re: [gentoo-user] /usr/bin/qtconfig is missing components

[Franz Fellner]

IMO the problem is that qtchooser acts as one point to select ALL
components for the default Qt, be it qt4 or qt5 (and possibly qt6 in 2020),
without checking if the tool really exists.
It just forwards the call to an execuatble with the same name inside the
qt-installation's bin dir. (/usr/lib/qt...)
qtconfig got removed and people (with DEs lacking qt integration) couldn't
configure their fonts/colors/widget style/... anymore. So someone just
started to develop a third-party config tool to fill the gap.
qtchooser on the other hand is an official qt tool (at least it is hosted
on qt's servers). I think that's why they don't just call qt5ct ;) And it
would introduce a speacial case for just this one tool.


2018-07-23 13:05 GMT+03:00 Mick :

> On Monday, 23 July 2018 10:09:38 BST Franz Fellner wrote:
> > Yeah, stupid qtchooser ;)
> >
> > qtconfig got dropped, use x11-misc/qt5ct instead.
>
> Thanks Franz, qtconfig used to be installed by default with Qt.  I wonder
> why
> x11-misc/qt5ct isn't treated the same, especially as qtconfig is left on
> the
> box and is symlinked to qtchooser now.  :-/
>
> --
> Regards,
> Mick

Re: [gentoo-user] /usr/bin/qtconfig is missing components

[Franz Fellner]

Yeah, stupid qtchooser ;)

qtconfig got dropped, use x11-misc/qt5ct instead.

2018-07-23 12:02 GMT+03:00 Dale :

> Mick wrote:
> > When I run /usr/bin/qtconfig it complains about a missing
> '/usr/lib64/qt5/bin/
> > qtconfig':
> >
> > $ /usr/bin/qtconfig
> > qtconfig: could not exec '/usr/lib64/qt5/bin/qtconfig': No such file or
> > directory
> >
> > $ locate qtconfig
> > /usr/bin/qtconfig
> >
> >
> > Which package is responsible for it and how can I get it back?
> >
>
>
> Does this help?
>
> root@fireball / # equery b /usr/bin/qtconfig
>  * Searching for /usr/bin/qtconfig ...
> dev-qt/qtchooser-0_p20170803 (/usr/bin/qtconfig -> qtchooser)
> dev-qt/qtchooser-0_p20170803 (/usr/bin/qtchooser)
> root@fireball / #
>
> Dale
>
> :-)  :-)
>
>

Re: [gentoo-user] PYTHON_SINGLE_TARGET inconsistent?

[Franz Fellner]

It's not automatically doing magic but using things specified in the
profile. In this case look at ${PORTDIR}/profile/base/package.use
Setting PYTHON_SINGLE_TARGET (which is expanded to those USEFlags) in your
make.conf will shadow those from the profile and spit out an error.

2018-07-07 21:45 GMT+03:00 Vadim A. Misbakh-Soloviov :

> The package you're referring to have only support of python2 interpreters
> (python2_7 (CPython) and pypy (not the pypy3)).
>
> It seems, by default (if neither of PYTHON_SINGLE_TARGET is set), portage
> tries to do the "magic" (well, in my opinion, it opposes to the Gentoo
> Philosophy, and it should throw the same error even with "defaults") and
> automatically chooses the 2_7 single target for it.
>
> But when you explicitly specify the targets in make.conf, it obeys and
> don't
> do that magic anymore, so condition of "exactly one of supported
> single_targets (pypy, pyhton2.7)" is not meeting anymore".
>
> That's why you getting the error.
>
> В письме от суббота, 7 июля 2018 г. 21:31:48 MSK пользователь Andreas Fink
> написал:
> > Hello,
> > I have a question considering PYTHON_SINGLE_TARGET because it seems to
> > behave inconsistently on my system and I cannot find any documentation
> > about it, that would guide me in the right direction how to fix it.
> > Running emerge --info I see the following (I'm on ~amd64):
> > ... PYTHON_SINGLE_TARGET="python3_5" PYTHON_TARGETS="python2_7
> python3_5"
> > ...
> >
> > This output is the default for ~amd64, neither PYTHON_SINGLE_TARGET nor
> > PYTHON_TARGETS has been set explicitly.
> > If I do an emerge -av asciidoc, I see the following output:
> > ebuild   R] app-text/asciidoc-8.6.10::gentoo  USE="-examples
> -graphviz
> > -highlight {-test}" PYTHON_SINGLE_TARGET="python2_7 -pypy"
> > PYTHON_TARGETS="python2_7 -pypy"
> >
> > Setting PYTHON_SINGLE_TARGET and PYTHON_TARGETS in /etc/portage/make.conf
> > explicitly to: PYTHON_SINGLE_TARGET="python3_5"
> > PYTHON_TARGETS="python2_7 python3_5"
> >
> > Now emerge --info doesn't show any difference. It's still the same
> output.
> > Doing an emerge -av asciidoc I get now this output:
> > !!! The ebuild selected to satisfy "asciidoc" has unmet requirements.
> > - app-text/asciidoc-8.6.10::gentoo USE="-examples -graphviz -highlight
> > -test" ABI_X86="(64)" PYTHON_SINGLE_TARGET="-pypy -python2_7"
> > PYTHON_TARGETS="python2_7 -pypy"
> >
> >   The following REQUIRED_USE flag constraints are unsatisfied:
> > exactly-one-of ( python_single_target_pypy
> > python_single_target_python2_7 )
> >
> >
> > This seems for me to be really inconsistent, considering the fact that we
> > usually request users to provide an emerge --info, which wouldn't show
> any
> > difference.
> > Why am I able to merge in the first case the package, but in the second
> case
> > I get an error? I really cannot understand where the
> > python_single_target_python2_7 is set in the first case.
> > Anyone who has more insight into that case?
> >
> > Cheers
> > Andreas
>
>
>
>
>
>

Re: [gentoo-user] New xorg-proto package blocks everything else.

[Franz Fellner]

Just a stupid question: Did you add =scrnsaverproto-1.2.2-r1 to
package.mask? Because the -r2 is stable and nothing should prevent it from
being merged...
I am running partly testing and the time xorg-proto was added I had to deal
with hard blocks which I circumvented by un-keywording (remove from
package.accept-keywords) and selectively masking.

2018-03-25 20:58 GMT+03:00 gevisz :

> 2018-03-25 20:38 GMT+03:00 gevisz :
> > 2018-03-25 15:50 GMT+03:00 Neil Bothwick :
> >> On Sun, 25 Mar 2018 15:19:33 +0300, gevisz wrote:
> >>
> >>> It seems that newly introduced x11-base/xorg-proto-2018.4 package
> >>> blocks everything else. What to do?
> >>> Is there better option in this case than unmerging xorg-server?
> >>> Thank you.
> >>>
> >>> # emerge --update --deep --with-bdeps=y --newuse --backtrack=90 --ask
> world
> >>>
> >>> These are the packages that would be merged, in order:
> >>>
> >>> Calculating dependencies... done!
> >>> [ebuild U  ] sys-apps/rename-1.3-r2 [1.3]
> >>> [ebuild U  ] sys-devel/autoconf-archive-2017.09.28 [2017.03.21]
> >>> [ebuild U  ] app-misc/pax-utils-1.2.3 [1.2.2-r2]
> >>> [ebuild U  ] sys-apps/sandbox-2.13 [2.12]
> >>> [ebuild  N ] x11-base/xorg-proto-2018.4
> > ...
> >>> [blocks B  ]  >>> (" >>> x11-base/xorg-proto-2018.4)
> >>>
> >>>  * Error: The above package list contains packages which cannot be
> >>>  * installed at the same time on the same system.
> >>
> >> The only hard block here appears to be xscrnsaverproto, unmerge that and
> >> the rest should take care of themselves. I had all the soft blocks today
> >> but not that one, and everything worked fine.
> >
> > Unmerging the scrnsaverproto package did not changed the message from
> > portage. However, adding --exclude scrnsaverproto --exclude chromium
> > to the command above helped a bit. So, now, I have the following:
> >
> > # emerge --update --deep --with-bdeps=y --newuse --backtrack=100 --ask
> > world --exclude chromium
> >
> > These are the packages that would be merged, in order:
> >
> > Calculating dependencies... done!
> > [ebuild  N ] x11-proto/scrnsaverproto-1.2.2-r1  USE="-doc"
> > ABI_X86="(64) -32 (-x32)"
> > [blocks B  ]  > (" > x11-base/xorg-proto-2018.4)
> >
> >  * Error: The above package list contains packages which cannot be
> >  * installed at the same time on the same system.
> >
> >   (x11-base/xorg-proto-2018.4:0/0::gentoo, installed) pulled in by
> > x11-base/xorg-proto required by
> > (x11-proto/renderproto-0.11.1-r2:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/xf86bigfontproto-1.2.0-r2:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/glproto-1.4.17-r2:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/fixesproto-5.0-r2:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/xproto-7.0.31-r1:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/dri2proto-2.8-r2:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/compositeproto-0.4.2-r2:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/randrproto-1.5.0-r1:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/inputproto-2.3.2-r1:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/resourceproto-1.2.0-r1:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/videoproto-2.3.3-r1:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/kbproto-1.0.7-r1:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/fontsproto-2.1.3-r1:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/xf86vidmodeproto-2.3.1-r2:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/trapproto-3.4.3-r1:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/xf86driproto-2.1.1-r2:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/damageproto-1.2.1-r2:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/recordproto-1.14.2-r2:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/xineramaproto-1.2.1-r2:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/presentproto-1.1-r1:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/xcmiscproto-1.2.2-r1:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/xf86dgaproto-2.1-r3:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/xextproto-7.3.0-r1:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/bigreqsproto-1.1.2-r1:0/0::gentoo, installed)
> > x11-base/xorg-proto required by
> > (x11-proto/dri3proto-1.0-r1:0/0::gentoo, installed)
> >
> >   

Re: [gentoo-user] Downgrading glibc prevented by emerge/portage...but why initiated?

[Franz Fellner]

My guess: You have glibc-2.24-r4 and one of the 2.25 with revision <-r4
listed WITH EXACT VERSION AND REVISiON in your package.accept_keywords. The
recent glibc-cleanp remove those 2.25 revisions and only left 2.25-r4 and
2.24-r4 Leaving you with the downgrade as only option to get the most
recent available version.

2017-09-12 9:17 GMT+02:00 Alan McKinnon :

> On 12/09/2017 05:43, tu...@posteo.de wrote:
> > Hi,
> >
> > got a problem this morning:
> >
>  Verifying ebuild manifests
>  Running pre-merge checks for sys-libs/glibc-2.24-r4
> >  * Sanity check to keep you from breaking your system:
> >  *  Downgrading glibc is not supported and a sure way to destruction
> >  * ERROR: sys-libs/glibc-2.24-r4::gentoo failed (pretend phase):
> >  *   aborting to save your system
> >  *
> >  * Call stack:
> >  *ebuild.sh, line 115:  Called pkg_pretend
> >  *ebuild.sh, line 348:  Called
> toolchain-glibc_pkg_pretend
> >  *   toolchain-glibc.eclass, line 507:  Called die
> >  * The specific snippet of code:
> >  *die "aborting to save your system"
> >  *
> >  * If you need support, post the output of `emerge --info
> '=sys-libs/glibc-2.24-r4::gentoo'`,
> >  * the complete build log and the output of `emerge -pqv
> '=sys-libs/glibc-2.24-r4::gentoo'`.
> >  * The complete build log is located at '/var/tmp/portage/sys-libs/
> glibc-2.24-r4/temp/build.log'.
> >  * The ebuild environment file is located at '/var/tmp/portage/sys-libs/
> glibc-2.24-r4/temp/die.env'.
> >  * Working directory: '/var/tmp/portage/sys-libs/glibc-2.24-r4/homedir'
> >  * S: '/var/tmp/portage/sys-libs/glibc-2.24-r4/work/glibc-2.24'
>  Running pre-merge checks for media-sound/pulseaudio-11.0
> >  * Determining the location of the kernel source code
> >  * Found kernel source directory:
> >  * /usr/src/linux
> >  * Found sources for kernel version:
> >  * 4.13.1-RT
> >  * Checking for suitable kernel configuration options...
> >  [ ok ]
> >  * A preallocated buffer-size of 2048 (kB) or higher is recommended for
> the HD-audio driver!
> >  * CONFIG_SND_HDA_PREALLOC_SIZE=64
> >
> > I would interpret this as:
>
> Looks to me like you are assuming the glibc maintainer has more
> knowledge of the future that he/she actually has.
>
> >
> > In the past emerge had updated glibc to a higher version as it want it
> > to install now and prevented the latter becayse it would be downgrade,
> > which in turn would render my box useless.
>
> No, not useless. It's a safety check for just in case. And now you must
> bypass the checks
>
> >
> > But why updateing to higher version in the first step
>
> Because you had a valid ebuild in the tree that said to do it ?
> >
> or attempting
> > to downgrade now?
>
> Because now you don't have that valid ebuild anymore?
>
>
> >
> > And finally...ANy update is blocked for now it seems...how can I get
> > out of this?
>
> Why is glibc wanting to downgrade? What is your current version?
>
> both of these versions are in the tree: (~)2.24-r4^s (~)2.25-r4^s
> so there is at least 1 glibc higher than what portage wants to downgrade
> to.
>
> You need to find out why 2.25-r4 is not being used. Usual tools, e.g.:
>
> grep -r glibc /etc/portage
> and any other methods you prefer
>
> As a last resort if the ebuld maintainer screwed up, you can bypass the
> safety check. Edit ${PORTDIR}/eclass/toolchain-glibc.eclass and comment
> out the check in
> toolchain-glibc_pkg_pretend()
>
> This is unlikely to destroy the system. Cause a problem - maybe. Destroy
> it? No. The wording of the safety check is hugely over-dramatic to
> discourage people from downgrading willy-nilly without thinking
>
> --
> Alan McKinnon
> alan.mckin...@gmail.com
>
>
>

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

[Franz Fellner]

>
> Additional question:  will keyboard selection keybindings for different
> languages be read off /etc/X11/xorg.conf.d/10-evdev.conf?  In particular,
>
>  Option "XkbLayout"
>  Option "XkbOptions"
>
> which help me toggle the keyboard between different languages.  Or is a
> different mechanism required for (X)Wayland?
>

You have to go a different route: Either it is directly configurable via WM
(AFAIK enlightenment has a keybord module) or you have to set
XKB_DEFAULT_LAYOUT envvar.

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

[Franz Fellner]

Just porting to a toolkit that "supports" Wayland won't be much help to
window managers. A WM has to implement the wayland server side (compositor)
while applications are clients. The toolkits abstract away the X/wayland
client API calls (E.G. Qt platform plugins) so you simply create your
widgets, setup your (toolkit native) callbacks and are done. But as soon as
you call X-specific functions in your applications things will get harder.
Qt now also implements a wayland-compostior which HELPS creating a wayland
server. But still you need to do quite some work. Porting to gtk3 (xfce...
) will have a similar impact: It won't allow XFCE to automatically run on X
and Wayland. Probably it makes some things easier but in the end there is
not so much the toolkit can abstract away in terms of creating a
compositor/server/WM.

Personally I tried to get running Plasma on wayland several times and while
I finally got it started there were so many crashes (e.g. some applications
esp. those having to run on XWayland, but also systemsettings) and issues
with managing windows that I gave up on it for the moment. Gnome might be a
different thing as they go wayland exclusively and have a working
implementation for a longer time than kde. I also tried enlightenment with
wayland which didn't run more stable than with X :(

2017-07-11 17:25 GMT+02:00 Rich Freeman :

> On Tue, Jul 11, 2017 at 10:51 AM, Ian Zimmerman 
> wrote:
> > On 2017-07-11 09:02, Rich Freeman wrote:
> >
> >> > I use GNOME with Wayland for some time and I actually didn't notice
> >> > that I switched until I tried to get synergy working ( mouse sharing
> >> > software, which only works on X ), seems like GDM automatically
> >> > chose Wayland since some upgrade. XWayland works pretty seamlessly
> >> > as well, so I'll just stay with Wayland for now, but it might be
> >> > more annoying to use it with other DEs/WMs.
> >
> >> > However, I have less screen tearing with fullscreen applications
> >> > with Wayland than I had with X ( with radeon + mesa ).
> >
> >> My sense is that this is probably what people would see.  It will
> >> probably work fine for any of the major DEs, but you'll find these
> >> little cases of tools that aren't ported.  One BIG area that will be
> >> affected is X11 forwarding.  I'm not sure if that works over ssh or
> >> not with wayland, but wayland in general doesn't support network
> >> sockets.
> >
> > What about "3rd party" window managers like openbox?  From my limited
> > understanding of wayland, that functionality just goes out of the window
> > (OOPS, sorry); window management becomes a responsibility of the toolkit
> > and there is no way to plug in a different one.
>
> I'm going out on a limb a bit here, but my understanding is not so
> much that it is impossible for arbitrary applications to talk to
> wayland (that seems silly - it is just an API).  Rather, the major
> toolkits simply have already done all the hard work so that if you use
> one of those toolkits then your application will work.
>
> I'm sure there is no reason an application that doesn't use qt/gtk/etc
> couldn't just make direct calls to wayland.  However, it will require
> a lot more porting work on the part of upstream, and so it probably
> won't happen quickly.
>
> In the same way an application written to use QT probably can be made
> to work on OSX or Windows with very little additional work, because
> the toolkits provide a single API across all the platforms.  You could
> write an application that works on all these platforms without using a
> toolkit, but then the developer needs to maintain all the API
> abstraction.
>
> Getting back to openbox/etc, I suspect that you have a couple of extremes
> here:
>
> * Full-fledged DEs like Gnome/KDE.  They have a ton of functionality
> that would be impacted by Wayland, but they also use toolkits that
> have probably already taken care of this.
> * Very minimal window managers (think fvwm/twm/etc).  They may not use
> a toolkit that was ported, but on the other hand their functionality
> is minimal and porting might not be so hard.  Also, there seems to be
> some effort to port more minimal toolkits like motif to wayland.
> * In-between environments (think xfce, openstep, etc).  They don't
> benefit from the toolkit but still have a lot of functionality to
> port.  I heard that xfce is being ported to gtk for just this reason.
>
> I suspect that Wayland is going to drive adoption of gtk/qt much more
> widely.  For the effort of directly porting to Wayland you could just
> port to gtk and then get coverage on other platforms as well.
>
> >
> > Or does xwayland help with that?  I'll be grateful for an explanation of
> > this area, as I'm worried about the future of the X server but I'm also
> > married to openbox.
> >
>
> I suspect that xwayland would cover some of this, but I haven't messed
> with either.
>
> --
> Rich
>
>

Re: [gentoo-user] Vim puts command in when starting up

[Franz Fellner]

Could you try
vim -u NONE
to see if there is an issue with your config or one of your plugins?

On Thu, 22 Sep 2016 11:28:34 -0700, Daniel Frey  wrote:
> On 09/22/2016 09:17 AM, Matthias Gerstner wrote:
> > Hi,
> > 
> >> For some reason, on one box, whenever I start vim it puts
> >> "://" on the command line. I've looked in vimrc and can't
> >> see any reference to this. Hitting Enter yields "E486: Pattern not found
> >> :"
> > 
> > I've had a similar issues for the past months with my vim. It was
> > related to my using the "urxvt" terminal and its TERM variable being set
> > to "rxvt-unicode".
> > 
> > In my case the effect didn't always show up but only under certain
> > conditions. I remember having seen a bug report for vim back then but
> > can't seem to find it right now. There are similar, older bug reports,
> > however, like this one:
> > 
> > https://bbs.archlinux.org/viewtopic.php?id=199362
> > 
> > I also remember there was a bugfix to vim back then to fix the issue.
> > But the version containing the bugfix was not yet stable in portage and
> > so I've lived with the occasional bug until now. I'm currently using
> > vim-7.4.769 and I think the bugfix was contained just a few micro
> > versions later if I'm not mistaken.
> 
> Hmm, I've just upgraded to vim v8 and it is still doing it. I'm quite
> confused.
> 
> Dan
> 
> 
> 
> 
-- 

Re: [gentoo-user] emerge wants to upgrade gtk+ but it's masked

[Franz Fellner]

> Good suggestion, thanks. notification-deamon wants the upgrade, I'll try 
> with some more masking or USE change.

--verbose --tree (short: -vt) should really be used by default ;) It doesn't 
hurt
but it is a great help.

> Do you have a reference regarding the meld issue so I can track it?

Nothing really to track, but a commit that references CSS issues with gtk+-3.20:
https://git.gnome.org/browse/meld/commit/?id=df83035b6531adb8153fbdb00141fb4e3cd1bbcc

Re: [gentoo-user] emerge wants to upgrade gtk+ but it's masked

[Franz Fellner]

Adding "--verbose --tree" to your emerge options probably reveals the offending 
package.
It is likely this is caused by a dependency you have not yet masked.

Meld master already contains fixes for those issues, so hopefully they release 
a fixed
version soon...

On Wed, 21 Sep 2016 10:30:21 +0200, Raffaele BELARDI  
wrote:
> I have masked >gtk+-3.18.9 due to issues with meld on my system [1],[2].
> Today's update wants me to unmask it [3]. Checking the ebuilds, none of 
> the packages emerge lists should need a gtk+ higher than gtk+-3.18.9; 
> for example the most probable candidate, gcr-3.20.,0 depends only on:
> COMMON_DEPEND="
> >=app-crypt/p11-kit-0.19
> >=dev-libs/glib-2.38:2
> >=dev-libs/libgcrypt-1.2.2:0=
> >=dev-libs/libtasn1-1:=
> >=sys-apps/dbus-1
> gtk? ( >=x11-libs/gtk+-3.12:3[X,introspection?] )
> introspection? ( >=dev-libs/gobject-introspection-1.34:= )
> 
> Also none of the installed packages needs it [4].
> 
> Any way I can convince emerge to proceed with the update without 
> unmasking gtk+-3.20.x?
> 
> thanks,
> 
> raffaele
> 
> -
> 
> [1] # cat /etc/portage/package.mask
> # the last good meld version was linked against x11-libs/gtk+-3.18.6, 
> .7, .8, .9
> # try masking higher library version
>  >x11-libs/gtk+-3.18.9
> # higher than this one pulls in x11-libs/gtk+-3.20.x
>  >x11-libs/gtksourceview-3.18.3
> 
> # eix -I gtk+
> [U] x11-libs/gtk+
>   Available versions:
>   (1)1.2.10-r13
>   (2)*2.24.28-r1 2.24.30^t (~)2.24.31^t
>   (3)*3.16.7 3.18.9{tbz2} [m](~)3.20.8^t{tbz2} [m](~)3.20.9^t
> {X aqua broadway cloudprint colord cups debug examples 
> +introspection nls test vim-syntax wayland xinerama ABI_MIPS="n32 n64 
> o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32" LINGUAS="az ca 
> cs da de el es et eu fi fr ga gl hr hu it ja ko lt nl nn no pl pt pt_BR 
> ro ru sk sl sr sv tr uk vi"}
>   Installed versions:  2.24.30(2)^t(08:43:17 AM 
> 08/18/2016)(introspection -aqua -cups -debug -examples -test -vim-syntax 
> -xinerama ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" 
> ABI_X86="32 -64 -x32") 3.18.9(3){tbz2}(10:20:59 AM 08/10/2016)(X 
> introspection -aqua -broadway -cloudprint -colord -cups -debug -examples 
> -test -vim-syntax -wayland -xinerama ABI_MIPS="-n32 -n64 -o32" 
> ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="32 -64 -x32")
> 
> 
> [2] with gtk+-3.20.x the tabs and buttons in meld are drawn without the 
> surrounding border line thus it's unusable. I opened a bug on gnome but 
> it was rightly dismissed as a packaging system issue 
> (https://bugzilla.gnome.org/show_bug.cgi?id=769699).
> 
> 
> [3] The following mask changes are necessary to proceed:
>   (see "package.unmask" in the portage(5) man page for more details)
> # required by app-crypt/gcr-3.20.0::gentoo[gtk]
> # required by gnome-base/gvfs-1.28.3-r1::gentoo
> # required by x11-libs/libfm-1.2.4::gentoo[automount,udisks]
> # required by lxde-base/lxpanel-0.8.2::gentoo
> # required by lxde-base/lxde-meta-0.5.5-r5::gentoo
> # required by @selected
> # required by @world (argument)
> # /etc/portage/package.mask:
> # the last good meld version was linked against x11-libs/gtk+-3.18.6, 
> .7, .8, .9
> # try masking higher library version
> =x11-libs/gtk+-3.20.9
> 
> 
> [4] # equery d x11-libs/gtk+
>   * These packages depend on x11-libs/gtk+:
> app-crypt/gcr-3.20.0 (gtk ? >=x11-libs/gtk+-3.12:3[X,introspection?])
> app-crypt/pinentry-0.9.7-r1 (gtk ? x11-libs/gtk+:2)
> app-editors/leafpad-0.8.18.1 (x11-libs/gtk+:2)
> app-text/ghostscript-gpl-9.19 (gtk ? x11-libs/gtk+:3)
>(gtk ? x11-libs/gtk+:2)
> app-text/gtkspell-2.0.16 (x11-libs/gtk+:2)
> dev-java/oracle-jre-bin-1.8.0.102 (javafx ? x11-libs/gtk+:2)
> dev-libs/keybinder-0.3.1-r200 (>=x11-libs/gtk+-2.20:2)
> dev-libs/libunique-1.1.6-r1 (>=x11-libs/gtk+-2.11:2[introspection?])
> dev-python/pygobject-3.20.1 (test ? x11-libs/gtk+:3[introspection])
> dev-util/meld-3.16.2 (>=x11-libs/gtk+-3.14:3[introspection])
> games-misc/xcowsay-1.3 (x11-libs/gtk+:2)
> gnome-base/gvfs-1.28.3-r1 (gtk ? >=x11-libs/gtk+-3.0:3)
> gnome-base/libglade-2.6.4-r2 
> (>=x11-libs/gtk+-2.24.23:2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
> gnome-base/librsvg-2.40.16 (tools ? >=x11-libs/gtk+-3.10.0:3)
> gnome-extra/polkit-gnome-0.105-r1 (x11-libs/gtk+:3)
> lxde-base/lxappearance-0.5.5 (x11-libs/gtk+:2)
> lxde-base/lxde-common-0.5.5-r3 (x11-libs/gtk+:2)
> lxde-base/lxde-icon-theme-0.5.0-r1 (x11-libs/gtk+:2)
> lxde-base/lxinput-0.3.2 (x11-libs/gtk+:2)
> lxde-base/lxpanel-0.8.1 (x11-libs/gtk+:2)
> lxde-base/lxrandr-0.1.2 (x11-libs/gtk+:2)
> lxde-base/lxsession-0.5.2 (x11-libs/gtk+:2)
> lxde-base/lxtask-0.1.6 (x11-libs/gtk+:2)
> 

Re: [gentoo-user] Choice of MUA

[Franz Fellner]

On Thu, 11 Aug 2016 06:51:29 +0100, Peter Humphrey  
wrote:
> On Wednesday 10 Aug 2016 19:26:56 Mick wrote:
> 
> > Peter, I recall you being a long term sufferer of Kmail2 problems, which I
> > do not experience here.
> 
> Yes, I have some old archives preserved as tar.bz2 files, but I can't import 
> them into KMail because of some internal damage to many of the messages. I 
> think the damage was caused by a gradually developing hardware problem 
> (which has eventually forced me into replacing the whole box), and KMail, 
> akonadi and friends can't handle the mess. They aren't what I would call 
> defensively programmed. They either throw wobblers or refuse to co-operate 
> at all.
> 
> So I have the basic data and can use standard tools to examine them if 
> necessary; that will have to do for now. Meanwhile, KMail is working happily 
> with stuff originating on the new box - apart from the apparently inevitable 
> duplicate messages of course.

You could just try notmuch. Extract your tarball and run "notmuch new" on that -
of course you want to configure notmuch before that, "man notmuch" may help.
If it doesn't throw any errors you can try some basic queries like
"notmuch search subject:MUA" to see if indexing went fine.
You could try https://github.com/astroidmail/astroid as a frontend. It supports
HTML-Mails, is highly configurable and completely keyboard-driven but still
requires webkit-gtk:3...

Happy testing ;)

Re: [gentoo-user] Re: Portage getting slicker?

[Franz Fellner]

On Thu, 14 Jul 2016 14:43:54 +0300, Gevisz  wrote:
> On Thu, 14 Jul 2016 09:52:41 +0200 Marc Joliet  wrote:
> 
> > On Thursday 14 July 2016 08:17:19 Alan McKinnon wrote:
> > > -N is newuse, portage also considers packages whose USE has changed.
> > > -t is emptytree, portage also considers the entire tree and -u tells it
> > > to not remerge things that don't need updating.  
> > 
> > Um, -e is --emptytree, no? -t is just --tree.  But yeah, according to his 
> > first email, James did leave out -N the second time around ("emerge -uvDNp 
> > world" vs. "emerge -uDtv @world").
> 
> Sorry for the interrupting a big gurus, but in my humble opinion
> the reason why there was no compilation while running emerge for
> the first time is the -p option (pretend). 

No, even without -p the first command wouldn't have done anything, because 
"Total: 0 packages".
There simple was nothing to do! The second command showed "3 Packages".

> 
> 
> 
> 
-- 

Re: [gentoo-user] Re: How safe is it to change vanilla-USE-Flag in glibc?

[Franz Fellner]

On Wed, 06 Jul 2016 15:06:20 +, James <wirel...@tampabay.rr.com> wrote:
> Franz Fellner  gmail.com> writes:
> 
> 
> > I have issues with some prgrams eating too much memory. This seems to be
> > related to glibc not trimming as
> > necessary which results in way too much memory still occupied by the
> > program after free()ing memory.
> 
> Perhaps you should file a bug, providing some evidence if other distros are
> affected (this suggests it might be a gcc issue) or other distros are not
> affected (this suggests it might be a gentoo pathch issue)?

I mentioned my issues several times with the answer "can't be, the issue is on 
your side".
When I filed a bug against tmux regarding its memory consumption I got told 
"glibc is known to do bad things" and I was given this patch for tmux which 
instantenously solved my issue:

diff --git a/grid.c b/grid.c
index ef7c374..96385f4 100644
--- a/grid.c
+++ b/grid.c
@@ -113,6 +113,8 @@ grid_destroy(struct grid *gd)
free(gd->linedata);
 
free(gd);
+
+   malloc_trim(0);
 }
 
 /* Compare grids. */
@@ -326,6 +328,8 @@ grid_clear_lines(struct grid *gd, u_int py, u_int ny)
free(gl->celldata);
memset(gl, 0, sizeof *gl);
}
+
+   malloc_trim(0);
 }
 
 /* Move a group of lines. */

I have some other applications that are unusable to a certain degree. Having to 
patch every single application isn't possible, I want to get to the root of the 
issue :) And USE=vanilla is my first attempt.

Thx
Franz

Re: [gentoo-user] How safe is it to change vanilla-USE-Flag in glibc?

[Franz Fellner]

On Wed, 06 Jul 2016 11:19:44 -0400, Michael Orlitzky <m...@gentoo.org> wrote:
> On 07/06/2016 03:17 AM, Franz Fellner wrote:
> > Hey all,
> > 
> > I have issues with some prgrams eating too much memory. This seems to be 
> > related to glibc not trimming as necessary which results in way too much 
> > memory still occupied by the program after free()ing memory.
> > I can't use gcc (specifically g++) with quite some apps now because it 
> > starts collecting memory (+swap) until everything falls apart, and I 
> > finally came to the conclusion also gcc might suffer from bad trimming 
> > behaviour.
> > As glibc is the package that implements free I want to have a closer look 
> > at it. The first idea is to get rid of Gentoo patches which are controlled 
> > by USE="vanilla". Playing around with glibc might destroy my system. 
> > Downgrades are already unsupported. So my question:
> > 
> > Can I safely switch from -vanilla to +vanilla in glibc?
> > 
> 
> It looks to me like USE=vanilla controls only whether or not bundled
> timezone data is used. If that's the case (double-check!), it's probably
> safe to unmerge timezone-data and re-emerge glibc with USE=vanilla.

There is a huge glibc-2.23-patches-4.tar.bz2 in my DISTDIR and the patches get 
applied.

> To be safe, you can bundle up your existing glibc with quickpkg. Then if
> something goes wrong, you can always boot to a liveCD and unpack the old
> version.

Yes, I know that works ;) But I don't have any livecd around (and most likely 
not even an empty disc, at least it's not therewhere it should be) so it is 
extra work I could avoid if a DEV gives me the OK regarding USE=vanilla.

Thx
Franz

[gentoo-user] How safe is it to change vanilla-USE-Flag in glibc?

[Franz Fellner]

Hey all,

I have issues with some prgrams eating too much memory. This seems to be 
related to glibc not trimming as necessary which results in way too much memory 
still occupied by the program after free()ing memory.
I can't use gcc (specifically g++) with quite some apps now because it starts 
collecting memory (+swap) until everything falls apart, and I finally came to 
the conclusion also gcc might suffer from bad trimming behaviour.
As glibc is the package that implements free I want to have a closer look at 
it. The first idea is to get rid of Gentoo patches which are controlled by 
USE="vanilla". Playing around with glibc might destroy my system. Downgrades 
are already unsupported. So my question:

Can I safely switch from -vanilla to +vanilla in glibc?

This is how glibc currently is installed:
sys-libs/glibc-2.23-r2(multilib rpc -audit -caps -debug -gd -hardened -nscd 
-profile -selinux -suid -systemtap -vanilla CROSSCOMPILE_OPTS="-headers-only")

Thx for your help
Franz

Re: [gentoo-user] Libreoffice

[Franz Fellner]

On Sat, 02 Jul 2016 09:51:17 +0200, Roger Cahn  wrote:
> hey all,
> 
> 4.4.6-gentoo, amd64, libreoffice-5.1.2.2
> 
> Since I have done what was said,
> I have in make.conf   LINGUAS="fr fr_FR"   L1ON="fr"

It's "L ten N" Instead of "L one o N" (Zero instead of upper letter o).

> 
> Libreoffice is in English. I would like to have it again in French.
> I updated a short time agoapp-office/libreoffice-l10n-5.1.2.2
> with  L10N having -fr instead of +fr
> I think it is the reason of this.
> 
> How could I solve the problem ?
> Thank you for your help
> Roger
> 
> 
-- 

Re: [gentoo-user] Emerge is teh FAIL ! ! ! ! !

[Franz Fellner]

man emerge
search for "skipfirst" and "keep-going"
It also seems you did not post the actual error or log. At least the
snipped you posted does not make any sense.

2016-03-14 16:12 GMT+01:00 Alan Grimes :

> In order to press ahead, I had to drop ktorrent and digikam, both
> packages that I consider high priority. =\
>
>
> I thought that would finally get me going...
>
>
> Oh what a fool I was...
>
> #
>
> >>> Running pre-merge checks for kde-plasma/plasma-workspace-5.5.5-r2
> >>> Running pre-merge checks for kde-plasma/kdeplasma-addons-5.5.5
> >>> Running pre-merge checks for kde-plasma/khotkeys-5.5.5
> >>> Running pre-merge checks for kde-plasma/powerdevil-5.5.5
> >>> Running pre-merge checks for kde-plasma/kmenuedit-5.5.5
> >>> Running pre-merge checks for kde-plasma/plasma-desktop-5.5.5
> >>> Running pre-merge checks for dev-lang/mono-4.2.2.30
>  * Determining the location of the kernel source code
>  * Found kernel source directory:
>  * /usr/src/linux
>  * Found kernel object directory:
>  * /lib/modules/4.4.0/build
>  * Found sources for kernel version:
>  * 4.4.0
>  * Checking for suitable kernel configuration
> options...
> [ ok ]
>
>  * Messages for package app-emulation/wine-1.9.5:
>
>  * ERROR: app-emulation/wine-1.9.5::gentoo failed (pretend phase):
>  *   (no error message)
>  *
>  * Call stack:
>  *   ebuild.sh, line 133:  Called pkg_pretend
>  *   wine-1.9.5.ebuild, line 206:  Called wine_build_environment_check
>  *   wine-1.9.5.ebuild, line 179:  Called die
>  * The specific snippet of code:
>  *  $(tc-getCC) -O2 "${FILESDIR}"/pr69140.c -o
> "${T}"/pr69140 || die
>  *
>  * If you need support, post the output of `emerge --info
> '=app-emulation/wine-1.9.5::gentoo'`,
>  * the complete build log and the output of `emerge -pqv
> '=app-emulation/wine-1.9.5::gentoo'`.
>  * The complete build log is located at
> '/var/tmp/portage/app-emulation/wine-1.9.5/temp/build.log'.
>  * The ebuild environment file is located at
> '/var/tmp/portage/app-emulation/wine-1.9.5/temp/die.env'.
>  * Working directory: '/usr/lib64/python3.4/site-packages'
>  * S: '/var/tmp/portage/app-emulation/wine-1.9.5/work/wine-1.9.5'
> tortoise ~ #
>
> 
>
> So this one stupid leaf package is killing my ENTIRE update???
>
> I guess I'd better pray to Bill Gates that he won't fuck up my Windows 7
> HTPC by shoving win x down my throat or otherwise I won't be able to
> even try to play the several games I have that are windows only. =\
>
> --
> IQ is a measure of how stupid you feel.
>
> Powers are not rights.
>
>
>

Re: [gentoo-user] Is Calligra / KRITA currently compilable

[Franz Fellner]

Could both of you please be more precise about what actually goes wrong with 
your calligra builds?
I had issues with krita, too: gmic.cpp never finished and the CXX-process 
accumulated memory until
it crashed with an std::bad_alloc exception. (with calligra-2.9.11)
Appending "-DWITH_GMIC=OFF" to the cmake options fixes the issue. But as I 
don't know the exact
errors of your builds I can't say this is the fix you should go for...

Franz

On Sun, 06 Mar 2016 18:21:14 +0100, Paul Klos  wrote:
> Could you share your use flags? Calligra stopped compiling here a few weeks 
> ago. I'd be interested to see if there any differences.
> 
> Thanks,
> 
> Paul
> 
-- 

Re: [gentoo-user] weird (?) dependency is blocking freeze

[Franz Fellner]

> > Calculating dependencies... done!
> >   media-libs/mlt-0.9.0 pulled in by:
> > media-video/openshot-1.4.3 requires 
> > >=media-libs/mlt-0.8.2[ffmpeg,frei0r,gtk,melt,python,sdl,xml]
> > 
> > Checking the kind of packages:
> > 
> > * app-arch/freeze
> >  Available versions:  2.5.0-r1
> >  Homepage:http://www.ibiblio.org/pub/Linux/utils/compress/
> >  Description: Freeze/unfreeze compression program
> > 
> > [I] media-libs/mlt
> >  Available versions:  0.9.0 ~0.9.8 ~0.9.8-r2 {compressed-lumas debug dv 
> > ffmpeg fftw frei0r gtk jack kde kdenlive libav libsamplerate lua melt 
> > opengl python qt4 qt5 quicktime rtaudio ruby sdl vdpau vorbis xine xml 
> > CPU_FLAGS_X86="mmx sse sse2" KERNEL="linux" PYTHON_TARGETS="python2_7"}
> >  Installed versions:  0.9.0(18:22:19 06/06/15)(ffmpeg frei0r gtk jack 
> > kdenlive lua melt python qt4 sdl vdpau vorbis xml -compressed-lumas -debug 
> > -dv -kde -libav -libsamplerate -quicktime -rtaudio -ruby -xine 
> > CPU_FLAGS_X86="mmx sse sse2" KERNEL="linux")
> >  Homepage:http://www.mltframework.org/
> >  Description: Open source multimedia framework for television 
> > broadcasting
> > 
> > [I] media-video/openshot
> >  Available versions:  (~)1.4.3 {+ffmpeg libav +python 
> > PYTHON_TARGETS="python2_7"}
> >  Installed versions:  1.4.3(18:33:24 06/06/15)(ffmpeg python -libav 
> > PYTHON_TARGETS="python2_7")
> >  Homepage:http://www.openshotvideo.com
> >  Description: Free, open-source, non-linear video editor to 
> > create and edit videos and movies
> > 
> > 
> > ...what is the common dominator which creates this blocking effect? ;)
> 
> As always with such things, look in the ebuild.
> 
> In /var/portage/app-arch/freeze/freeze-2.5.0-r1.ebuild:
> 
> RDEPEND="
> !<=media-libs/mlt-0.4.2
> !media-libs/mlt[melt]
> 
> The solution is to set USE="-melt" for mlt if you want to use freeze.

Which won't work because openshot obviously depends on media-libs/mlt[melt].
So it really looks like openshot can't be installed together with freeze -- If
the dependencies in both the ebuilds are really correct...

Re: [gentoo-user] What package provides gstreamer-app?

[Franz Fellner]

❯ qlist gst-plugins-base:0.10 | grep app
/usr/share/gtk-doc/html/gst-plugins-base-libs-0.10/gstreamer-app.html
/usr/share/gtk-doc/html/gst-plugins-base-libs-0.10/gst-plugins-base-libs-appsrc.html
/usr/share/gtk-doc/html/gst-plugins-base-libs-0.10/gst-plugins-base-libs-appsink.html
/usr/share/gtk-doc/html/gst-plugins-base-plugins-0.10/gst-plugins-base-plugins-appsrc.html
/usr/share/gtk-doc/html/gst-plugins-base-plugins-0.10/gst-plugins-base-plugins-plugin-app.html
/usr/share/gtk-doc/html/gst-plugins-base-plugins-0.10/gst-plugins-base-plugins-appsink.html
/usr/lib64/gstreamer-0.10/libgstapp.so
/usr/lib64/libgstapp-0.10.so.0.25.0
/usr/lib64/libgstapp-0.10.so.0
/usr/lib64/pkgconfig/gstreamer-app-0.10.pc
/usr/lib64/libgstapp-0.10.so
/usr/include/gstreamer-0.10/gst/app/gstappsink.h
/usr/include/gstreamer-0.10/gst/app/gstappbuffer.h
/usr/include/gstreamer-0.10/gst/app/gstappsrc.h

Probably you need to start a completely fresh build?
Also you might want to build against gstreamer:1.0 (AFAIK it is not the
default but there should be a configure switch)

2015-12-11 8:43 GMT+01:00 Dale :

> waltd...@waltdnes.org wrote:
> >   I've successfully manually compiled Pale Moon (a Firefox fork), but it
> > doesn't play h264 files.  Apparently, I have to enable gstreamer for
> > that.  OK, I did it.  This time the build fails with...
> >
> > configure:20206: checking for gstreamer-0.10 >= 0.10.25
> >   gstreamer-app-0.10
> >   gstreamer-plugins-base-0.10
> > *** Fix above errors and then restart with "make -f client.mk
> build"
> >
> >   I built libgstreamer and the base plugins package.  It still fails.
> > I can't find which package provides gstreamer-app.  Searching Google
> > reveals that a lot of other people have the same problem.
> > http://www.portagefilelist.de/ doesn't have any results.  Any ideas?
> >
>
>
> I have some gstreamer stuff installed here and I didn't find any matches
> either.  If that filelist site doesn't list it either, makes me wonder
> what does install that file.  :/
>
> Dale
>
> :-)  :-)
>
>

Re: [gentoo-user] 69.99 != 69.99

[Franz Fellner]

On Sat, 22 Aug 2015 16:57:41 +0200, hw h...@gartencenter-vaehning.de wrote:
 
 
 Am 22.08.2015 um 15:43 schrieb Alan McKinnon:
  On 22/08/2015 15:26, hw wrote:
 
  Hi,
 
  I have the following in a perl script:
 
 
 if ($a != $b) {
   print e: '$a', t: '$b'\n;
 }
 
 
  That will print:
 
  e: '69.99', t: '69.99'
 
 
  When I replace != with ne (if ($a ne $a) {), it doesn't print.
 
 
  Is that a bug or a feature?  And if it's a feature, what's the explanation?
 
  And how do you deal with comparisions of variables when you get randomly
  either correct results or wrong ones?  It's randomly because this
  statement checks multiple values in the script, and 69.99 is the only
  number showing up yet which isn't numerically equal to itself (but equal
  to itself when compared as strings).
 
 
 
  Computer languages have a much more exact idea of what equality means
  than you do. In your head (because you are human, not silicon) you are
  completely comfortable with taking 69.99 and treat8ing it as a string,
  or a number, or a mostly-rounded-off floating point number.
 
  The computer does not do it like that. To a computer, the same must be
  exactly the same. Two things a little bit different are completely
  different (or not equal). And perl has two different operators for
  (in)equality:
 
  != does a numerical comparison. More on this below
  ne does a string comparison. When viewed as a bunch of characters, 69.99
  and 69.99 are identical.
 
 When the value is numerically not 69.99 but something like 69.99001, 
 then printing the value should print 69.99001 rather than 69.99.

To take your perl statement:
perl -e 'printf(%34.32f\n, 23.33*3)'
69.98488409230252727866

It doesnt print that strange value because it rounds it to something
more readable, as the value is known to be not as precise.

 
 perl -e 'print 1/3 . \n;' prints 0.333
 
 perl -e 'printf(%34.32f\n, 1/3);' prints 
 0.1482961625624739
 
 perl -e 'print (((1/3 == 0.333) ? equal : not equal) . 
 \n);' prints not equal
 
 perl -e 'print (((1/3 == 0.0.1482961625624739) ? equal 
 : not equal) . \n);' prints Integer overflow in decimal number at 
 -e line 1. a couple times

typo ;)
1/3 == 0.0.333[...]
Here it prints equal.

 
 This is random, may it be predictable or not, and what's the integer here?
 
  Now, your comparisons are NOT random. They are entirely predictable, as
  long as you know what is going on; you are running into floating point
  numbers. And as it turns out, computers never represent these things
  exactly (they are NOT integers). Even though they look identical
  on-screen, in RAM they will not be (this must be so for perl to do the
  print). Maybe they actually resolve to 69.99001 and 69.9900. You
  see them as close-as-dammit equal, perl sees them as entirely different.
 
 Why can't it print the number as it is, or at least as it is compared, 
 like it should?  If it would, one could see at once what the problem is.
 
  This is such as huge IT problem that many solutions have been proposed.
  You get classes like BigFloat that represent a floating point as an
  integer so that equality works, you can round the floats off before
  comparing them, or just make the things integers.
 
  The last one is nice: don't represent money as dollars and cents,
  represent it as cents or decicents and only divide by 100 (or 1000) when
  you finally get to display it.
 
 That would add quite a lot of complexity, and the problem should either 
 be handled transparently, or the value should be printed as the 
 software/computer sees it.  It is a recipe for disaster when you tell 
 your computer to print something but it prints something else instead.
 
  So how to fix your problem: you are doing what you shouldn't do - trying
  equality on floats. Turn them into integers, or round them off, or use
  =/= instead of !=
 
 '=/=' is not an operator in perl?
 

Re: [gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

[Franz Fellner]

Fernando Rodriguez wrote:
 On Monday, August 03, 2015 6:41:22 PM walt wrote:
  That line declares *hostname as a constant and then the statement below
  proceeds to assign a value to the 'constant'.  I wonder how many hours
  of frustration have been suffered by student programmers while trying to
  understand the logic behind that.
 
 Because it's not a constant, it's a pointer-to-constant :)
Both of you are right, you can read the declaration in both ways:
hostname is of type pointer to const char.
*hostname is of type const char.

But in this case it is not *hostname, that get's a value assigned, it's 
simply hostname. If you do not set hostname to NULL it stays uninitialised, 
which means its value is what the actual memory is set to - quite undefined.
Correct initialization is really important and should be done consequently so 
it gets an automatism ;) (would avoid issues like this)

 
 const char *hostname; /* pointer to constant char */
 char *const hostname; /* constant pointer to char */
 const char *const hostname; /* constant pointer to constant char */
 
 Is that confusing enough?
 
 -- 
 Fernando Rodriguez
 

RE: [gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

[Franz Fellner]

walt wrote:
 On Tue, 04 Aug 2015 08:19:37 +0200
 Franz Fellner alpine.art...@gmail.com wrote:
 
  Fernando Rodriguez wrote:
   On Monday, August 03, 2015 6:41:22 PM walt wrote:
That line declares *hostname as a constant and then the statement
below proceeds to assign a value to the 'constant'.  I wonder how
many hours of frustration have been suffered by student
programmers while trying to understand the logic behind that.
   
   Because it's not a constant, it's a pointer-to-constant :)
  Both of you are right, you can read the declaration in both ways:
  hostname is of type pointer to const char.
  *hostname is of type const char.
  
  But in this case it is not *hostname, that get's a value assigned,
  it's simply hostname. If you do not set hostname to NULL it stays
  uninitialised, which means its value is what the actual memory is set
  to - quite undefined. Correct initialization is really important and
  should be done consequently so it gets an automatism ;) (would avoid
  issues like this)
  
   
   const char *hostname; /* pointer to constant char */
   char *const hostname; /* constant pointer to char */
   const char *const hostname; /* constant pointer to constant char */
   
   Is that confusing enough?
 
 confusing++
 
 Thank you both for being patient enough to teach the ineducable :)
 
 Let me give you one more example of syntax that I find unreasonable,
 and then I'll ask my *real* question, about which I hope you will have
 opinions.
 
 Okay, the statement I referred to above uses this notation:
 
  if (!link-network-hostname)  this notation makes sense to me
  r = sd_dhcp_lease_get_hostname(lease, hostname); this doesn't

The -operator returns the address of the object, in this case of hostname.
If you would just pass hostname the function would receive a _copy_ of the 
object.
hostname is an out-argument, the function writes to it. That is needed 
sometimes
as C only can return one value, if you need to return more things you need to 
pass
them as out-args. But for that to work you need to operate on the actual object 
and
not a copy of it, so you need to pass the address to the actual object.
The declaration of the function of course needs to specify the arg as pointer 
to
the actual type, here pointer to a pointer to char.

 
 In this context does 'hostname' mean a-pointer-to-a-pointer-to-the-
 charstring we actually need?
 
 Doesn't this code seem needlessly complicated?
 
 okay, screed over, thanks for listening
 
 Somewhere I read that there was really only *one* java program ever
 written, and every subsequent java program was written by cut-and-paste
 from the first one.
 
 Is that how professional developers learn the art of programming?
 
 I really would like to hear your opinions on that question because I
 feel it's an important topic.
 
 Thanks guys.
 
 
 

RE: [gentoo-user] Re: Anyone else having a problem with bash?

[Franz Fellner]

Nikos Chantziaras wrote:
 On 10/07/15 02:34, Nikos Chantziaras wrote:
  I tried it [zsh], for exactly 10 seconds. My home/end keys didn't work. This
  gave me the impression of an unfinished project. Why on earth would
  anyone release a program after 1990 that doesn't know the home/end keys?
  :-/
 
 PS:
 
 The Del key doesn't work either.

Have a look at the zshwiki [1] on how to bind keys. You might want to give the 
zkbd module a try.
For a good out-of-the-box-experience you can try one of the many zsh 
configuration frameworks. I used oh-my-zsh for quite a while until I found 
prezto [2], which started as a fork of oh-my-zsh but ended up as a complete 
rewrite. It feels and looks quite nice. Add history-substring-search and 
syntax-highlighting to the list of modules to load (~/.zpreztorc) to get an 
even nicer prompt.
With prezto I could completely skip key-bindings as it seems to manage all the 
cases itself pretty well.

[1] http://zshwiki.org/home/zle/bindkeys
[2] https://github.com/sorin-ionescu/prezto

RE: [gentoo-user] necessary use flgas

[Franz Fellner]

behrouz khosravi wrote:
 Hello everyone.
 
 I really like to have control over my machine as much as possible. In this
 way I will learn a lot, so I am trying to remove all the default use flags
 and control them manually.
 
 I just don't know which global use flags are absolutely necessary to the
 system to make it snappier or secure.
 What do you recommend ?
 
 Thanks

Oh, USE-Flags are so boing :( They are documented well (quse -D $FLAG), you can 
even look into specific ebuilds what they actually do.

If you want to learn Gentoo the hard way I suggest to emerge -C python. or 
emerge -C glibc (yeah, glibc is gnome, and I hate gnome! Whoops, it was glib, 
not glibc... errr)
Or install certain packages by hand (make install) into /usr/local and forget 
about it.

(Before someone asks: Those are issues people actually had in the forums and 
it's really hard to track them down or fix them, you will learn quite a bit 
about your system ;)...)

To be more serious:
* Set a minimal basic profile (as already suggested)
* Tune your USE-Flags in make.conf. media-related flags (mp3, flac) should be 
harmless, if you touch flags that get used in core packages (e.g. in the 
toolchain) double (or triple) check if you don't do evil things.
* fine tune USE-Flags on a per-package-base via /etc/portage/package.use

RE: [gentoo-user] Mysterious library access...

[Franz Fellner]

Meino.Cramer@ wrote:
 Hi,
 
 After trying to play a flac-file with mpv I got this error message:
 Playing: Track_01.flac
 (+) Audio --aid=1 (flac)
 File tags:
 Artist: Unknown
 Album: Unknown Disc
 Genre: Alternative
 Title: Track 01
 Track: 1
 ALSA lib 
 /var/tmp/portage/media-libs/alsa-lib-1.0.29/work/alsa-lib-1.0.29/src/pcm/pcm_dmix.c:1024:(snd_pcm_dmix_open)
  unable to open slave

That's just debug output. In order to make dev's live easier alsa-lib uses 
__FILE__ and __LINE__ macros to point to the exact place where the debug output 
happened. As portage compiles in /var/tmp/portage/... the debug output mentions 
that file (note the .c suffix - not .so so it's not a library ;))

To fix your actual problem (no audio) we need to know how you configured audio 
(pure alsa/pulseaudio/...) and which USE-Flags you have enabled for mpv and 
ffmpeg.

 [ao/alsa] Playback open error: Device or resource busy
 connect(2) call to /dev/shm/jack-0/default/jack_0 failed (err=No such 
 file or directory)
 attempt to connect to server failed
 [ao/jack] cannot open server
 ALSA lib 
 /var/tmp/portage/media-libs/alsa-lib-1.0.29/work/alsa-lib-1.0.29/src/pcm/pcm_dmix.c:1024:(snd_pcm_dmix_open)
  unable to open slave
 Could not open/initialize audio device - no sound.
 Audio: no audio
 : 00:00:00 / 00:05:56 (0%)
 
 I reinstalled alsa-lib and mpv but the problem remains:
 Why does alsa tries to load a library which is meant to be found under 
 /var/tmp/portage?
 
 Best regards,
 Meino
 
 
 
 
 

RE: [gentoo-user] Portage.provided

[Franz Fellner]

Matti Nykyri wrote:
 How to get portage off my back? I have the following in 
 /etc/portage/package.provided:

For me package.provided didn't work wither. Until I noticed that I missed 
profile in te path.

mv /etc/portage/package.provided /etc/portage/profile/package.provided

and it should do what you expect.

 
 sys-kernel/gentoo-sources-4.0.5
 sys-kernel/gentoo-sources-4
 sys-kernel/gentoo-sources
 
 
 However when I run emerge -DuvaN world:
 
 
 
 These are the packages that would be merged, in order:
 
 Calculating dependencies... done!
 [ebuild  N ] sys-kernel/gentoo-sources-4.0.5:4.0.5::gentoo  USE=-build 
 -deblob -experimental -symlink 0 KiB
 
 Total: 1 package (1 new), Size of downloads: 0 KiB
 
 Would you like to merge these packages? [Yes/No] 
 
 
 
 What should I do?
 
 -- 
 -Matti
 

RE: [gentoo-user] Re: OT: Southbridge chip on laptop overheating

[Franz Fellner]

James wrote:
 Daniel Frey djqfrey at gmail.com writes:
  
  Hi all,
 
  I am curious though, what causes this chip to overheat, and can I do
  something about it?
 
 There may be a generic processor fan you can mount/glue onto the chip
 for cooling. Make sure all other fans are running. Blow out the laptop
 with an air compressor.

If you really blow out your laptop make sure the fans are fixed. If they
start turning while you blow into them they really can destroy your hardware.
Induction can be really bad ;)

 Sometime to add more cooling, I'd get a couple of
 pieces of 1/2 x 1/2 wood and place under the laptop to increase the air
 space under the laptop for increase air circulation.
 
 HAVIT® HV-F2056 15.6-17 Laptop Cooler - Three Quiet 110mm Fans at 1,000RPM, 
 
 Last, I think some folks make a cooling pad for laptops. If you have
 agressive compile options (like mine MAKEOPTS=-j9 -l9) in your 
 make.conf, slow them way down (-j1) etc.
 
 
  I'm using lm_sensors, which doesn't provide a temperature for this
  particular chip. I've monitored processes and nothing really stands out.
  I've even tried disabling plasma, no luck.
 
 
 hth,
 James

Re: [gentoo-user] Re: plugin-containers missing libraries

[Franz Fellner]

Adam Carter wrote:
 On Wed, May 27, 2015 at 3:24 PM, Franz Fellner alpine.art...@gmail.com
 wrote:
 
  Look at usually means Read the file - look at the content ;)
 
 
 Lets pretend for one minute that i'm a dumbass. In what way would I read a
 binary executable, and how is that relevant to plugin-container?

Just have a look and don't pretend it's a binary file ;)

$ cat /usr/bin/firefox-bin
#!/bin/sh
unset LD_PRELOAD
LD_LIBRARY_PATH=/opt/firefox/
GTK_PATH=/usr/lib/gtk-2.0/
exec /opt/firefox/firefox $@

Re: [gentoo-user] Re: plugin-containers missing libraries

[Franz Fellner]

Look at usually means Read the file - look at the content ;)

Adam Carter wrote:
 On Wed, May 27, 2015 at 10:37 AM, Holger Hoffstätte 
 holger.hoffstae...@googlemail.com wrote:
 
  On Wed, 27 May 2015 09:54:33 +1000, Adam Carter wrote:
 
   Is this working looking into? The programs generally work ok, so this is
   more for interests sake.
  
   # ldd /usr/lib64/firefox/plugin-container | grep not
   libmozalloc.so = not found
   libxul.so = not found
 
  This is normal, look at e.g. /usr/bin/firefox-bin to see why it works
  as expected.
 
 
 $ ls -l /usr/bin/firefox*
 lrwxrwxrwx 1 root root 26 May  9 19:13 /usr/bin/firefox -
 /usr/lib64/firefox/firefox*
 
 $ ls -l /usr/lib64/firefox/firefox*
 -rwxr-xr-x 1 root root 441096 May  9 19:13 /usr/lib64/firefox/firefox*
 -rwxr-xr-x 1 root root 441096 May  9 19:13 /usr/lib64/firefox/firefox-bin*
 
 $ md5sum /usr/lib64/firefox/firefox*
 61f2c178ef765770824c45c6ea9fa5e1  /usr/lib64/firefox/firefox
 61f2c178ef765770824c45c6ea9fa5e1  /usr/lib64/firefox/firefox-bin
 
 Is that what you expect me to see? I dont think I understand what you're
 saying.

RE: [gentoo-user] recommended applications

[Franz Fellner]

I use: 

* ranger for file management (if I need a file manager); tried MC which I 
didn't like.
  Tried to use krusader (which also is a commander-like FM for kde), but it 
also never worked for me...
  I just have no need for a split view in 99% of the cases, and ranger IMHO 
uses the space uch better.: 
* notmuch + offlineimap (with an eye on isync) + msmtp for mail - there is also 
a notmuch extension for mutt: 
* feh as image viewer: 
* llpp for pdfs (occasionally qpdfview and evince, if I feel like it): 
* urxvt as terminal: 
* vim as an editor (with more than one eye on neovim ;)): 
* everything inside awesome wm: 

behrouz khosravi wrote:
 Hello everyone. After spending about a year in the world of linux (and
 mostly beloved gentoo!) I have realized that the key to a stable and fast
 machine is to keep the system as small as possible.
 So I am going to use console based tools mostly. I will also replace KDE
 with i3wm.
 
 What do you recommend as a replacement for kmail? (is mutt a good choise?)
 
 What about IRC client?
 
 Torrent client?
 
 I know that I can use google! but I would like to know your opinion.
 Thanks for your time.

RE: [gentoo-user] Question for users of the Firefox browser

[Franz Fellner]

Andrew Lowe wrote:
 Hi all,
   I've been using Firefox for ages and something struck me recently as a
 bit odd. In the Windows version, if I click up into the address or
 search boxes, the existing contents are highlighted and if I begin
 typing, the existing text is deleted and what I'm typing becomes the
 contents. On the Linux version, under KDE, it doesn't. I have to click
 into the appropriate edit box, highlight the contents and start typing
 or hit either home/end and then start deleting before typing my new URL.
 If, for example, the existing text happens to be a google search string,
 this can be quite a bit of text to delete.
 
   So my question, I suppose, is multipart:
 
 1) Is this by design? Is this the normal behaviour?
 
 2) Have I set a USE flag wrong somewhere that causes this behaviour?
 
 3) How do people get around the problem I mentioned above regarding long
 URL's, such as a Google search results?
 
   Any thoughts, greatly appreciated,
 
   Andrew
 

You can try to double/triple click the text.
Or use Ctrl+L or F6.
I am using vimperator with gui=None, so I don't see the url/search bar.
I simply hit o or t and start typing ;)

Concerning the other points: I can't tell you if it's intentional. I never 
cared ;)
You can argue that canging the URL gets mor difficult with the way it works on 
WIN
An I don't think this depends on USE-Flags.

Re: [gentoo-user] Re: configure.ac and Makefile.am easy_view ?

[Franz Fellner]

Michael Orlitzky wrote:
 On 03/28/2015 01:40 PM, Todd Goodman wrote:
 
  Some ebuilds may patch configure.ac or Makefile.am -- in that case it's
  a little harder. I'm sure there's an elegant way to do it, but what I
  usually do is begin to emerge the package and Ctrl-C it when it starts
  compiling. Then you can find the sources under /var/tmp/portage.
 
  
  Wouldn't 'ebuild ebuild_file_name prepare' do what you want without
  trying to time a Ctrl-C?
  
 
 Yeah, but I have to be in the directory where the ebuild lives for that
 to work. `emerge foo` works anywhere. It's also more flexible -- if I
 want the *unpatched* files, I just Ctrl-C earlier =)

The ebuild-command works from every directory (at least for me ;)), you don't 
need to be inside
the directory where the ebuild lives.
And to get the unpatched src tree simply use ebuild EBUILD unpack. After 
that you
can run ebuild EBUILD prepare to prepare (e.g. patch) the sources. That's 
way easier to get
a well defined result than hitting C-c :)

RE: [gentoo-user] [OT] Purchase and setup of monitor calibration device

[Franz Fellner]

Hi Frank,

You maybe want to have a look at ColorHug:
http://www.hughski.com/
I don't own one, but it should work just fine.

Franz

Frank Steinmetzger wrote:
 Hey gurus
 
 I may soon get me a shiny (not in the sense of glossy, mind you) new
 monitor. Along with it, I’m planning on purchasing a colorimeter to properly
 calibrate it. Can anyone give me a recommendation for a device that runs
 well with Linux?
 
 It doesn’t have to be a super-pro device, but no el-cheapo either. I’ll need
 it mostly for photo editing and the warm feeling of having an above-average
 setup. *g* Oh and I want to improve my laptop experience, because those
 things usually come with crappy screens in the first place. So I’m looking
 at a price range of no more than 150€.
 
 Also, I’m looking for info on how to set up KDE (or the entire system?) to
 use the thusly generated colour profiles. So any food for thought?
 
 Thanks
 -- 
 Gruß | Greetings | Qapla’
 Please do not share anything from, with or about me with any social network.
 
 Bees aren’t at all hard working, they just can’t fly any slower.

Re: [gentoo-user] [OT] Purchase and setup of monitor calibration device

[Franz Fellner]

You forgot one important point:
It's a completely open product!
ColorHug is OpenHardware. The software is OpenSource (hosted at github).

Concerning setting up your computer with the generated profile:
I think that should be possible with colord.

Rich Freeman wrote:
 On Sat, Mar 28, 2015 at 7:48 AM, Franz Fellner alpine.art...@gmail.com 
 wrote:
 
  You maybe want to have a look at ColorHug:
  http://www.hughski.com/
  I don't own one, but it should work just fine.
 
 
 I'm still not sure if I feel the need greatly enough to invest in one,
 but this looks like a very nice solution.  They offer a LiveCD which
 you can use to just create an icc file which you can save to media or
 they have a free pastebin-like site that you can post them to for a
 week to retrieve after you reboot into your main OS.  That means you
 can trivially use this solution on numerous computers without
 installing drivers/etc or worrying about compatibility.  I'm sure
 getting it working natively on Gentoo wouldn't be a big deal either.
 
 For $100 it doesn't seem like a bad deal.  It does look like you have
 to take care of the import side yourself (I've never actually done
 that which is ironic since I've spent the last two years working on a
 system for automating corporate import declarations - I imagine the
 courier will handle it for a fee - I doubt the duties are much).  I
 guess they don't just do what all the cheap Amazon vendors do and
 stamp gift on the outside of the package.
 
 -- 
 Rich