Re: [gentoo-user] upgrading 1-year old system

[thelma]

On 03/04/2017 10:51 PM, J. Roeleveld wrote:
> On March 4, 2017 11:01:38 PM GMT+01:00, the...@sys-concept.com wrote:
>>
>> I'm stuck upgrading to "dev-db/mysql-5.6.35" 
>>
>> make: *** [Makefile:150: all] Error 2
>> * ERROR: dev-db/mysql-5.6.35::gentoo failed (compile phase):
>> *   emake failed
>> * 
>> * If you need support, post the output of `emerge --info
>> '=dev-db/mysql-5.6.35::gentoo'`,
>> * the complete build log and the output of `emerge -pqv
>> '=dev-db/mysql-5.6.35::gentoo'`.
>> * The complete build log is located at
>> '/var/tmp/portage/dev-db/mysql-5.6.35/temp/build.log'.
>> * The ebuild environment file is located at
>> '/var/tmp/portage/dev-db/mysql-5.6.35/temp/environment'.
>> * Working directory:
>> '/var/tmp/portage/dev-db/mysql-5.6.35/work/mysql-abi_x86_32.x86'
>> * S: '/var/tmp/portage/dev-db/mysql-5.6.35/work/mysql'
>>
> Failed to emerge dev-db/mysql-5.6.35, Log file:
>>
>  '/var/tmp/portage/dev-db/mysql-5.6.35/temp/build.log'
>> *** Resuming merge...
>>
>> These are the packages that would be merged, in reverse order:
>>
>> Calculating dependencies... done!
>> * One or more packages are either masked or have missing dependencies:
>> * 
>> *   sys-libs/ncurses:0/5=[abi_x86_32(-),abi_x86_64(-)] pulled in by:
>> * (dev-db/mysql-5.6.27:0/18::gentoo, installed)
>> * 
>> *   >=sys-libs/ncurses-5.9-r3[abi_x86_32(-),abi_x86_64(-)] pulled in
>> by:
>> * (sys-libs/readline-6.3_p8-r2:0/0::gentoo, installed)
>> * 
>> *   >=sys-libs/ncurses-5.9-r3:0=[abi_x86_32(-),abi_x86_64(-)] pulled in
>> by:
>> * (sys-libs/gpm-1.20.7-r2:0/0::gentoo, installed)
>> * 
>> *   >=sys-libs/ncurses-5.2-r2:0/5=[unicode] pulled in by:
>> * (sys-apps/util-linux-2.26.2:0/0::gentoo, installed)
>> * 
>> *   >=sys-libs/ncurses-5.9-r3:5/5=[abi_x86_32(-),abi_x86_64(-)] pulled
>> in by:
>> * (sys-devel/llvm-3.5.0:0/3.5::gentoo, installed)
>> * 
>> *  
>>> =media-libs/harfbuzz-0.9.12:0/0.9.18=[glib(+),truetype(+),abi_x86_32(-),abi_x86_64(-)]
>> pulled in by:
>> * (x11-libs/pango-1.36.8-r1:0/0::gentoo, installed)
>> * 
>> *   > pulled in by:
>> * (net-print/cups-filters-1.0.71:0/0::gentoo, installed)
>>
>> Any ideas how to go around it?
>> I've installed: sys-libs/ncurses-6.0-r1
>>
>> Thanks
>>
>> --
>> Thelma
> 
> Few tips:
> 
> Check for the actual error in the build.log
> 
> Ensure you are not poluting your world file
> 
> Check previous threads for hints and tips on updating older Gentoo 
> installations. I think there might also be a wiki page on the gentoo website.
> 
> --
> Joost

It solved itself :-/
It is had to upgrade 1-year old systems; sometimes the errors are
totally related to something else.
I run "perl-cleaner --all" rebuild ~150-pacages and slowly everything
stared to fall into place. Some packages needed to be uninstall manually
(as they are no longer in portage and new one emerged).

--
Thelma

Re: [gentoo-user] upgrading 1-year old system

[J. Roeleveld]

On March 4, 2017 11:01:38 PM GMT+01:00, the...@sys-concept.com wrote:
>
>I'm stuck upgrading to "dev-db/mysql-5.6.35" 
>
>make: *** [Makefile:150: all] Error 2
> * ERROR: dev-db/mysql-5.6.35::gentoo failed (compile phase):
> *   emake failed
> * 
>* If you need support, post the output of `emerge --info
>'=dev-db/mysql-5.6.35::gentoo'`,
>* the complete build log and the output of `emerge -pqv
>'=dev-db/mysql-5.6.35::gentoo'`.
>* The complete build log is located at
>'/var/tmp/portage/dev-db/mysql-5.6.35/temp/build.log'.
>* The ebuild environment file is located at
>'/var/tmp/portage/dev-db/mysql-5.6.35/temp/environment'.
>* Working directory:
>'/var/tmp/portage/dev-db/mysql-5.6.35/work/mysql-abi_x86_32.x86'
> * S: '/var/tmp/portage/dev-db/mysql-5.6.35/work/mysql'
>
 Failed to emerge dev-db/mysql-5.6.35, Log file:
>
  '/var/tmp/portage/dev-db/mysql-5.6.35/temp/build.log'
>*** Resuming merge...
>
>These are the packages that would be merged, in reverse order:
>
>Calculating dependencies... done!
> * One or more packages are either masked or have missing dependencies:
> * 
> *   sys-libs/ncurses:0/5=[abi_x86_32(-),abi_x86_64(-)] pulled in by:
> * (dev-db/mysql-5.6.27:0/18::gentoo, installed)
> * 
>*   >=sys-libs/ncurses-5.9-r3[abi_x86_32(-),abi_x86_64(-)] pulled in
>by:
> * (sys-libs/readline-6.3_p8-r2:0/0::gentoo, installed)
> * 
>*   >=sys-libs/ncurses-5.9-r3:0=[abi_x86_32(-),abi_x86_64(-)] pulled in
>by:
> * (sys-libs/gpm-1.20.7-r2:0/0::gentoo, installed)
> * 
> *   >=sys-libs/ncurses-5.2-r2:0/5=[unicode] pulled in by:
> * (sys-apps/util-linux-2.26.2:0/0::gentoo, installed)
> * 
>*   >=sys-libs/ncurses-5.9-r3:5/5=[abi_x86_32(-),abi_x86_64(-)] pulled
>in by:
> * (sys-devel/llvm-3.5.0:0/3.5::gentoo, installed)
> * 
>*  
>>=media-libs/harfbuzz-0.9.12:0/0.9.18=[glib(+),truetype(+),abi_x86_32(-),abi_x86_64(-)]
>pulled in by:
> * (x11-libs/pango-1.36.8-r1:0/0::gentoo, installed)
> * 
>*   pulled in by:
> * (net-print/cups-filters-1.0.71:0/0::gentoo, installed)
>
>Any ideas how to go around it?
>I've installed: sys-libs/ncurses-6.0-r1
>
>Thanks
>
>--
>Thelma

Few tips:

Check for the actual error in the build.log

Ensure you are not poluting your world file

Check previous threads for hints and tips on updating older Gentoo 
installations. I think there might also be a wiki page on the gentoo website.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Gpgme oddity

[Alon Bar-Lev]

On 5 March 2017 at 00:59, Peter Humphrey  wrote:
>
> I just can't believe it. They're issuing a general-purpose tool, to work
> everywhere, and they don't test it on a representative sample of systems?

It was tested, otherwise how could the conflict with kde-apps/gpgmepp
and kde-apps/kdepimlibs:4 been known?

Upstream has merge some external libraries into its own code base and
provided an option to disable these exactly for this use case.
Adding USE="-cxx -qt5" or masking this package provides remedy for
those who still use kdepimlibs:4, both are standard gentoo procedures.
As apposed to what you present in previous messages, a "standard kde"
system may or may not include kdepimlibs:4. We delayed too much
stabilization of gpgme to allow proper resolution, however, no reason
to delay any more as no issue for these that do not use kdepimlibs:4
and for these who use a simple USE change or mask resolves the issue.

> I just can't believe it. They're issuing a general-purpose tool, to work 
> everywhere,
> and they don't test it on a representative sample of systems?

Indeed, we provide general-proposed tool that with correct setup can
work in most cases as supported as outlined by the designated
upstreams, while bridging the gaps and permutations as much as we can.

Regards,
Alon

Re: [gentoo-user] Gpgme oddity

[Peter Humphrey]

On Saturday 04 Mar 2017 11:48:23 Rich Freeman wrote:
> On Sat, Mar 4, 2017 at 11:30 AM, Peter Humphrey  
wrote:
> > On Saturday 04 Mar 2017 14:59:51 Alan McKinnon wrote:
> >> ... It's a ~arch package, so you get to be a field tester when you use
> >> it
> >> 
> >> :-)
> > 
> > As Marc said, it isn't. But I'm incredulous that gpgme wasn't tested on
> > a
> > standard KDE system. That just beggars belief.
> 
> In general, packages aren't tested on any particular desktop
> environment prior to stabilization.

Then for goodness' sake, where are they tested? In limbo?

> I'm sure the KDE packages get tested in KDE (probably on Plasma), but
> that's about as far as it is likely to go.  Now, packages might happen to
> be tested under KDE.
> 
> I'm not saying that is a good thing, or a bad thing, just that this is
> how it has worked for as long as I've been using Gentoo.

I just can't believe it. They're issuing a general-purpose tool, to work 
everywhere, and they don't test it on a representative sample of systems?

If my team had been tempted into that sort of myopia, I'd have been shown 
the door toute damn suite. And we had the nation's power grid to keep 
running. Sorry, but this is just amateur.

Not getting at you, Rich - just venting my frustration.

-- 
Regards
Peter

Re: [gentoo-user] upgrading 1-year old system

[thelma]

On 03/04/2017 03:01 PM, the...@sys-concept.com wrote:
> 
> I'm stuck upgrading to "dev-db/mysql-5.6.35" 
> 
> make: *** [Makefile:150: all] Error 2
>  * ERROR: dev-db/mysql-5.6.35::gentoo failed (compile phase):
>  *   emake failed
>  * 
[snip]

I advanced a bit, now I'm getting:  

make: *** [Makefile:150: all] Error 2
 * ERROR: dev-db/mysql-5.6.35::gentoo failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info 
'=dev-db/mysql-5.6.35::gentoo'`,
 * the complete build log and the output of `emerge -pqv 
'=dev-db/mysql-5.6.35::gentoo'`.
 * The complete build log is located at 
'/var/tmp/portage/dev-db/mysql-5.6.35/temp/build.log'.
 * The ebuild environment file is located at 
'/var/tmp/portage/dev-db/mysql-5.6.35/temp/environment'.
 * Working directory: 
'/var/tmp/portage/dev-db/mysql-5.6.35/work/mysql-abi_x86_32.x86'
 * S: '/var/tmp/portage/dev-db/mysql-5.6.35/work/mysql'
 


emerge --info '=dev-db/mysql-5.6.35::gentoo'

Portage 2.3.3 (python 3.4.3-final-0, default/linux/amd64/13.0/desktop, 
gcc-4.9.4, glibc-2.21-r1, 3.10.7-gentoo-r1 x86_64)
=
 System Settings
=
System uname: 
Linux-3.10.7-gentoo-r1-x86_64-AMD_FX-tm-8150_Eight-Core_Processor-with-gentoo-2.3
KiB Mem: 8092984 total,   4896500 free
KiB Swap:8757244 total,   8757244 free
Timestamp of repository gentoo: Sun, 26 Feb 2017 22:00:01 +
sh bash 4.3_p48-r1
ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
app-shells/bash:  4.3_p48-r1::gentoo
dev-java/java-config: 2.2.0::gentoo
dev-lang/perl:5.20.2::gentoo
dev-lang/python:  2.7.10-r1::gentoo, 3.4.3::gentoo
dev-util/cmake:   3.7.2::gentoo
dev-util/pkgconfig:   0.28-r2::gentoo
sys-apps/baselayout:  2.3::gentoo
sys-apps/openrc:  0.23.2::gentoo
sys-apps/sandbox: 2.6-r1::gentoo
sys-devel/autoconf:   2.13::gentoo, 2.69::gentoo
sys-devel/automake:   1.11.6-r1::gentoo, 1.13.4::gentoo, 1.14.1::gentoo, 
1.15::gentoo
sys-devel/binutils:   2.25.1-r1::gentoo
sys-devel/gcc:4.5.4::gentoo, 4.9.3::gentoo, 4.9.4::gentoo
sys-devel/gcc-config: 1.7.3::gentoo
sys-devel/libtool:2.4.6::gentoo
sys-devel/make:   4.2.1::gentoo
sys-kernel/linux-headers: 3.18::gentoo (virtual/os-headers)
sys-libs/glibc:   2.21-r1::gentoo
Repositories:

gentoo
location: /usr/portage
sync-type: rsync
sync-uri: rsync://10.0.0.103/gentoo-portage
priority: -1000

brother-overlay
location: /var/lib/layman/brother-overlay
sync-type: git
sync-uri: https://github.com/stefan-langenmaier/brother-overlay.git
masters: gentoo
priority: 0

Local
location: /usr/local/portage
masters: gentoo
priority: 

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA googleearth PUEL dlj-1.1 Oracle-BCLA-JavaSE"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib64/fax /usr/share/easy-rsa 
/usr/share/gnupg/qualified.txt /var/spool/fax/etc"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d 
/etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release 
/etc/php/apache2-php5.6/ext-active/ /etc/php/cgi-php5.6/ext-active/ 
/etc/php/cli-php5.6/ext-active/ /etc/revdep-rebuild /etc/sandbox.d 
/etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d 
/etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-march=native -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--autounmask-write=y --keep-going --with-bdeps=y"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks 
ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs 
protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs 
unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ 
http://gentoo.osuosl.org/ ftp://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ 
http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ 
ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ 
ftp://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/ 
http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/;
LANG="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j9 --load-average=8"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times 
--omit-dir-times --compress --force --whole-file --delete --stats 
--human-readable --timeout=180 --exclude=/distfiles --exclude=/local 
--exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="X a52 aac acpi alsa amd64 apache2 bluetooth branding bzip2 cairo cdda cdr 
cgi cleartype cli consolekit consolkit corefonts cracklib crypt cups cxx dbus 
dri dts dvd dvdr emboss encode exif fam firefox flac foomaticdb 

Re: [gentoo-user] upgrading 1-year old system

[thelma]

I'm stuck upgrading to "dev-db/mysql-5.6.35" 

make: *** [Makefile:150: all] Error 2
 * ERROR: dev-db/mysql-5.6.35::gentoo failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info 
'=dev-db/mysql-5.6.35::gentoo'`,
 * the complete build log and the output of `emerge -pqv 
'=dev-db/mysql-5.6.35::gentoo'`.
 * The complete build log is located at 
'/var/tmp/portage/dev-db/mysql-5.6.35/temp/build.log'.
 * The ebuild environment file is located at 
'/var/tmp/portage/dev-db/mysql-5.6.35/temp/environment'.
 * Working directory: 
'/var/tmp/portage/dev-db/mysql-5.6.35/work/mysql-abi_x86_32.x86'
 * S: '/var/tmp/portage/dev-db/mysql-5.6.35/work/mysql'

>>> Failed to emerge dev-db/mysql-5.6.35, Log file:

>>>  '/var/tmp/portage/dev-db/mysql-5.6.35/temp/build.log'
*** Resuming merge...

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
 * One or more packages are either masked or have missing dependencies:
 * 
 *   sys-libs/ncurses:0/5=[abi_x86_32(-),abi_x86_64(-)] pulled in by:
 * (dev-db/mysql-5.6.27:0/18::gentoo, installed)
 * 
 *   >=sys-libs/ncurses-5.9-r3[abi_x86_32(-),abi_x86_64(-)] pulled in by:
 * (sys-libs/readline-6.3_p8-r2:0/0::gentoo, installed)
 * 
 *   >=sys-libs/ncurses-5.9-r3:0=[abi_x86_32(-),abi_x86_64(-)] pulled in by:
 * (sys-libs/gpm-1.20.7-r2:0/0::gentoo, installed)
 * 
 *   >=sys-libs/ncurses-5.2-r2:0/5=[unicode] pulled in by:
 * (sys-apps/util-linux-2.26.2:0/0::gentoo, installed)
 * 
 *   >=sys-libs/ncurses-5.9-r3:5/5=[abi_x86_32(-),abi_x86_64(-)] pulled in by:
 * (sys-devel/llvm-3.5.0:0/3.5::gentoo, installed)
 * 
 *   
>=media-libs/harfbuzz-0.9.12:0/0.9.18=[glib(+),truetype(+),abi_x86_32(-),abi_x86_64(-)]
 pulled in by:
 * (x11-libs/pango-1.36.8-r1:0/0::gentoo, installed)
 * 
 *   

Re: [gentoo-user] Why portage demands to unmask an unstable version of the package?

[Neil Bothwick]

On Sat, 4 Mar 2017 09:52:38 -0800, Jorge Almeida wrote:

> >> [ebuild U  ] app-vim/gentoo-syntax-20170225 [20160530]
> >> [ebuild U ~] app-editors/gvim-8.0.0386 [8.0.0106]  
> >
> > Because vim-8.0.0386 is stable and, presumably, the vim and gvim
> > versions must match. I would suggest filing a stabilisation bug for
> > gvim, or  
> 
> Isn't it a bit bizarre that portage tries to force users to go
> unstable on such an exotic package as one of the two major text
> editors?

They're not trying to force anyone, it's simply an oversight.

> I couldn't find the name of the maintainer. Maybe different devs are
> in charge of vim and gvim?

Both are maintained by Gentoo's vim project, v...@gentoo.org. It's in the
metadata.xml file in the ebuild directory. There's probably a tool to
extract that information but eyeballs-1.0 works for me.

> > use emacs...  
> 
> What do[es] the maintainer[s] use?

I would expect the maintainers of any package to use that package...


-- 
Neil Bothwick

The people who are wrapped up in themselves are overdressed.


pgpQcUT_aTDgA.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Why portage demands to unmask an unstable version of the package?

[Marc Joliet]

On Saturday 04 March 2017 10:40:06 Jorge Almeida wrote:
> On Sat, Mar 4, 2017 at 10:09 AM, Marc Joliet  >
> 
> > Does nobody think of searching bugs.gentoo.org anymore?  It was an
> > oversight: https://bugs.gentoo.org/show_bug.cgi?id=611386#c6.
> 
> Actually, most plain users won't remember or know that there is such a
> thing. Your post may contribute to improve it. I know I'll remember.
> But that doesn't mean it makes it easy: searching "vim-core-8.0.0386"
> returns zero bugs. Searching "vim-core" returns several entries, one
> of which seems related (if one happens to know that the problem is
> related to gvim to start with, and assuming one is not daunted by a
> reference to "acl"). I'm sure this just means I'm keyword-challenged,
> but I bet I'm not the only one in the universe of plain Gentoo users.

Yeah, searching bugzilla can be a pain sometimes.  I make use of Gentoo's 
gitweb fairly regularly, and it provides a search function.  For example:

https://gitweb.gentoo.org/repo/gentoo.git/log/?qt=grep=vim

will show the commits with "vim" in their summary, and the commit messages 
reference the relevant bug.  Also, security bugs are often also stabilisation 
bugs, which can help in these specific cases.

But yeah, that's just the reality of searching bug databases, I guess :-/ .

> OK, everybody makes mistakes. But reading "use emacs" is bound to
> touch a few cords. Even if it was said with a grain of salt, the fact
> is that updating a stable system after sync'ing is not expected to be
> a surprising experience, at least regarding packages that are not part
> of a huge bundle like KDE.

I agree, for example the ongoing gpgme issue has annoyed quite a bit.  
However, issues like that happen pretty rarely in my personal experience, 
which makes it more tolerable when they do (and it *was* resolved in about 28 
hours, IME <48 hours is normal, often even <24 hours).  And regarding the 
Emacs remark: as somebody who uses both Vim *and* Emacs (though mostly Vim), I 
just don't *care* about the whole Emacs vs. Vi(m) "debate".

> Regards
> 
> Jorge Almeida

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


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

Re: [gentoo-user] Gpgme oddity

[Alan McKinnon]

On 04/03/2017 18:30, Peter Humphrey wrote:
> On Saturday 04 Mar 2017 14:59:51 Alan McKinnon wrote:
> 
>> ... It's a ~arch package, so you get to be a field tester when you use it
>> :-)
> 
> As Marc said, it isn't. But I'm incredulous that gpgme wasn't tested on a 
> standard KDE system. That just beggars belief.
> 

My portage tree was 2 days old when I typed that.
Now it's 0 days old, and I see things are different now :-)

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

Re: [gentoo-user] Why portage demands to unmask an unstable version of the package?

[Gevisz]

On Sat, 4 Mar 2017 16:37:13 + Neil Bothwick  wrote:

> On Sat, 4 Mar 2017 18:21:23 +0200, gevisz wrote:
> 
> > $ eix gvim
> > [I] app-editors/gvim
> >  Available versions:  8.0.0106 ~8.0.0386 ** {acl aqua cscope
> > debug gnome gtk gtk3 lua luajit motif neXt netbeans nls perl python
> > racket ruby selinux session tcl PYTHON_TARGETS="python2_7 python3_4
> > python3_5 python3_6"}
> >  Installed versions:  8.0.0106(05:36:17 PM 12/11/2016)(acl gtk
> > python session -aqua -cscope -debug -gnome -gtk3 -lua -luajit -motif
> > -neXt -netbeans -nls -perl -racket -ruby -selinux -tcl
> > PYTHON_TARGETS="python2_7 python3_4 -python3_5")
> >  Homepage:http://www.vim.org/ https://github.com/vim/vim
> >  Description: GUI version of the Vim text editor
> > 
> > So, in my portage tree currently there is one stable gvim package with
> > version  8.0.0106
> > and one unstable gvim package, with version 8.0.0386.
> > 
> > Why portage force me to unmask an unstable version of the package then?
> > 
> > # emerge --update --deep --with-bdeps=y --newuse --backtrack=90 --ask
> > world --exclude chromiumg
> > 
> > These are the packages that would be merged, in order:  
> 
> > [ebuild U  ] app-editors/vim-8.0.0386 [8.0.0106]
> > PYTHON_TARGETS="(-python3_6)"
> > [ebuild  NS] virtual/libusb-0-r2 [1-r2] ABI_X86="32 (64) (-x32)"
> > [ebuild U  ] app-vim/gentoo-syntax-20170225 [20160530]
> > [ebuild U ~] app-editors/gvim-8.0.0386 [8.0.0106]  
> 
> Because vim-8.0.0386 is stable and, presumably, the vim and gvim versions
> must match.

Probably, you are right.

But why to mark vim-8.0.0386 being stable, before gvim-8.0.0386?

> I would suggest filing a stabilisation bug for gvim,

As later replies suggest, it is already done.

My thanks to all who replied.

> or just use emacs...

:)

Re: [gentoo-user] Why portage demands to unmask an unstable version of the package?

[Jorge Almeida]

On Sat, Mar 4, 2017 at 10:09 AM, Marc Joliet  >
> Does nobody think of searching bugs.gentoo.org anymore?  It was an oversight:
> https://bugs.gentoo.org/show_bug.cgi?id=611386#c6.
>
Actually, most plain users won't remember or know that there is such a
thing. Your post may contribute to improve it. I know I'll remember.
But that doesn't mean it makes it easy: searching "vim-core-8.0.0386"
returns zero bugs. Searching "vim-core" returns several entries, one
of which seems related (if one happens to know that the problem is
related to gvim to start with, and assuming one is not daunted by a
reference to "acl"). I'm sure this just means I'm keyword-challenged,
but I bet I'm not the only one in the universe of plain Gentoo users.

OK, everybody makes mistakes. But reading "use emacs" is bound to
touch a few cords. Even if it was said with a grain of salt, the fact
is that updating a stable system after sync'ing is not expected to be
a surprising experience, at least regarding packages that are not part
of a huge bundle like KDE.

Regards

Jorge Almeida

Re: [gentoo-user] Why portage demands to unmask an unstable version of the package?

[Marc Joliet]

On Saturday 04 March 2017 09:52:38 Jorge Almeida wrote:
> On Sat, Mar 4, 2017 at 8:37 AM, Neil Bothwick  wrote:
> > On Sat, 4 Mar 2017 18:21:23 +0200, gevisz wrote:
> >> So, in my portage tree currently there is one stable gvim package with
> >> version  8.0.0106
> >> and one unstable gvim package, with version 8.0.0386.
> >> 
> >> Why portage force me to unmask an unstable version of the package then?
> >> 
> >> 
> >> [ebuild U  ] app-vim/gentoo-syntax-20170225 [20160530]
> >> [ebuild U ~] app-editors/gvim-8.0.0386 [8.0.0106]
> > 
> > Because vim-8.0.0386 is stable and, presumably, the vim and gvim versions
> > must match. I would suggest filing a stabilisation bug for gvim, or
> 
> Isn't it a bit bizarre that portage tries to force users to go
> unstable on such an exotic package as one of the two major text
> editors?
> 
> This can't be good publicity for Gentoo. Yes, I know nobody is after
> that, but still...
> 
> I couldn't find the name of the maintainer. Maybe different devs are
> in charge of vim and gvim?
> 
> just
> 
> > use emacs...
> 
> What do[es] the maintainer[s] use?
> 
> Regards
> 
> Jorge Almeida

Does nobody think of searching bugs.gentoo.org anymore?  It was an oversight:  
https://bugs.gentoo.org/show_bug.cgi?id=611386#c6.

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


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

Re: [gentoo-user] Why portage demands to unmask an unstable version of the package?

[Jorge Almeida]

On Sat, Mar 4, 2017 at 8:37 AM, Neil Bothwick  wrote:
> On Sat, 4 Mar 2017 18:21:23 +0200, gevisz wrote:
>

>> So, in my portage tree currently there is one stable gvim package with
>> version  8.0.0106
>> and one unstable gvim package, with version 8.0.0386.
>>
>> Why portage force me to unmask an unstable version of the package then?
>>

>> [ebuild U  ] app-vim/gentoo-syntax-20170225 [20160530]
>> [ebuild U ~] app-editors/gvim-8.0.0386 [8.0.0106]
>
> Because vim-8.0.0386 is stable and, presumably, the vim and gvim versions
> must match. I would suggest filing a stabilisation bug for gvim, or

Isn't it a bit bizarre that portage tries to force users to go
unstable on such an exotic package as one of the two major text
editors?

This can't be good publicity for Gentoo. Yes, I know nobody is after
that, but still...

I couldn't find the name of the maintainer. Maybe different devs are
in charge of vim and gvim?

just
> use emacs...

What do[es] the maintainer[s] use?

Regards

Jorge Almeida

Re: [gentoo-user] Gpgme oddity

[Rich Freeman]

On Sat, Mar 4, 2017 at 11:30 AM, Peter Humphrey  wrote:
> On Saturday 04 Mar 2017 14:59:51 Alan McKinnon wrote:
>
>> ... It's a ~arch package, so you get to be a field tester when you use it
>> :-)
>
> As Marc said, it isn't. But I'm incredulous that gpgme wasn't tested on a
> standard KDE system. That just beggars belief.
>

In general, packages aren't tested on any particular desktop
environment prior to stabilization.  I'm sure the KDE packages get
tested in KDE (probably on Plasma), but that's about as far as it is
likely to go.  Now, packages might happen to be tested under KDE.

I'm not saying that is a good thing, or a bad thing, just that this is
how it has worked for as long as I've been using Gentoo.

-- 
Rich

[gentoo-user] Re: CIFS mounts started misbehaving

[Grant Edwards]

On 2017-03-04, Kai Krakow  wrote:
> Am Sat, 04 Mar 2017 08:02:11 + schrieb "J. Roeleveld" 
> :
>
>>
>> >Normally, when things are working but idle, the TCP connection to 445
>> >shows an SMB echo request/rseponse transaction once per minute.  When
>> >it fails, the TCP connection evidently got dropped, and the Windows
>> >machine repeatedly shuts down new ones:
>> >
>> >The failure mode looks like this in wireshark:
>> >
>> >  GentooWindows
>> >  
>> >  -> SYN  ->  445  
>> > <-SYN/ACK   <-   445  
>> >  -> ACK  ->  445
>> >  -> SMB[echo req]->  445  
>> > <-  RST <-   445
>> >
>> >[that repeats 800 times per second for long periods of time]
>> >
>> >Then at some point, it starts to work:
>> >  
>> >  ->SYN  ->  445  
>> > <-   SYN/ACK   <-   445  
>> >  ->ACK  ->  445
>> >  -> SMB[proto neg req]  ->  445  
>> > <-  SMB[proto neg rsp] <-   445  
>> >  -> SMB[ses setup req]  ->  445  
>> > <-  SMB[ses setup rsp] <-   445
>> > ...
>>
>> >Sometimes the umount times out and "fails" because the "host is
>> >down", and when that happens, it seems like it immediately starts to
>> >work again. :/  
>> 
>> Are other hosts linux or windows?

Other Linux and Windows clients don't seem to be having this problem.

>> Maybe a dodgy switch forgetting the correct path?

I don't think so.  I can ping the host while the CIFS subsystem says
"host is down".  If the switch is forgetting the path, who's sending
back the SYN/ACK and the RST

> Or an MTU problem... Is there a router in the path?

Nope.

I'm going to try to set up a Wireshark capture in ring-buffer mode and
somehow detect the failure and stop the capture...

-- 
Grant

Re: [gentoo-user] Gpgme oddity

[Peter Humphrey]

On Saturday 04 Mar 2017 15:00:41 Marc Joliet wrote:
> On Saturday 04 March 2017 10:52:57 Mick wrote:
--->8
> > Apparently USE="-cxx -qt5" should allow gpgme to build.  kdepimlibs goes
> > away on KDE-5 and the packages affected are in flux at this point.  I
> > will rinse and repeat at a later date.
> 
> True, but then you'll probably hit bug #600510.  I did and ended up going
> the mask route for now.

It isn't the job of the admin of a stable system to go around patching code 
that should have been tested properly before release.

> (I may actually attempt to upgrade to KDE PIM 16.12.2, but that pulls in a
> long tail of other packages due to QT_MINIMAL="5.7.0".)

If you do that, you may find you lose all searching ability in KMail, 
according to a current discussion on kdepim-us...@kde.org.

-- 
Regards
Peter

Re: [gentoo-user] Why portage demands to unmask an unstable version of the package?

[Neil Bothwick]

On Sat, 4 Mar 2017 18:21:23 +0200, gevisz wrote:

> $ eix gvim
> [I] app-editors/gvim
>  Available versions:  8.0.0106 ~8.0.0386 ** {acl aqua cscope
> debug gnome gtk gtk3 lua luajit motif neXt netbeans nls perl python
> racket ruby selinux session tcl PYTHON_TARGETS="python2_7 python3_4
> python3_5 python3_6"}
>  Installed versions:  8.0.0106(05:36:17 PM 12/11/2016)(acl gtk
> python session -aqua -cscope -debug -gnome -gtk3 -lua -luajit -motif
> -neXt -netbeans -nls -perl -racket -ruby -selinux -tcl
> PYTHON_TARGETS="python2_7 python3_4 -python3_5")
>  Homepage:http://www.vim.org/ https://github.com/vim/vim
>  Description: GUI version of the Vim text editor
> 
> So, in my portage tree currently there is one stable gvim package with
> version  8.0.0106
> and one unstable gvim package, with version 8.0.0386.
> 
> Why portage force me to unmask an unstable version of the package then?
> 
> # emerge --update --deep --with-bdeps=y --newuse --backtrack=90 --ask
> world --exclude chromiumg
> 
> These are the packages that would be merged, in order:

> [ebuild U  ] app-editors/vim-8.0.0386 [8.0.0106]
> PYTHON_TARGETS="(-python3_6)"
> [ebuild  NS] virtual/libusb-0-r2 [1-r2] ABI_X86="32 (64) (-x32)"
> [ebuild U  ] app-vim/gentoo-syntax-20170225 [20160530]
> [ebuild U ~] app-editors/gvim-8.0.0386 [8.0.0106]

Because vim-8.0.0386 is stable and, presumably, the vim and gvim versions
must match. I would suggest filing a stabilisation bug for gvim, or just
use emacs...


-- 
Neil Bothwick

Windows Error #09: Game Over. Exiting Windows.


pgppq7EdxwlPO.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Gpgme oddity

[Peter Humphrey]

On Saturday 04 Mar 2017 14:59:51 Alan McKinnon wrote:

> ... It's a ~arch package, so you get to be a field tester when you use it
> :-)

As Marc said, it isn't. But I'm incredulous that gpgme wasn't tested on a 
standard KDE system. That just beggars belief.

-- 
Regards
Peter

[gentoo-user] Why portage demands to unmask an unstable version of the package?

[gevisz]

$ eix gvim
[I] app-editors/gvim
 Available versions:  8.0.0106 ~8.0.0386 ** {acl aqua cscope
debug gnome gtk gtk3 lua luajit motif neXt netbeans nls perl python
racket ruby selinux session tcl PYTHON_TARGETS="python2_7 python3_4
python3_5 python3_6"}
 Installed versions:  8.0.0106(05:36:17 PM 12/11/2016)(acl gtk
python session -aqua -cscope -debug -gnome -gtk3 -lua -luajit -motif
-neXt -netbeans -nls -perl -racket -ruby -selinux -tcl
PYTHON_TARGETS="python2_7 python3_4 -python3_5")
 Homepage:http://www.vim.org/ https://github.com/vim/vim
 Description: GUI version of the Vim text editor

So, in my portage tree currently there is one stable gvim package with
version  8.0.0106
and one unstable gvim package, with version 8.0.0386.

Why portage force me to unmask an unstable version of the package then?

# emerge --update --deep --with-bdeps=y --newuse --backtrack=90 --ask
world --exclude chromium

These are the packages that would be merged, in order:

Calculating dependencies... done!

The following packages are causing rebuilds:

  (dev-libs/kpathsea-6.2.2_p20160523:0/6.2.2::gentoo, ebuild scheduled
for merge) causes rebuilds for:
(dev-tex/bibtexu-3.71_p20150521:0/0::gentoo, ebuild scheduled for merge)
(app-text/evince-3.20.1:0/evd3.4-evv3.3::gentoo, ebuild scheduled for merge)
(app-text/dvipng-1.15:0/0::gentoo, ebuild scheduled for merge)
[ebuild  r  U  ] dev-libs/kpathsea-6.2.2_p20160523 [6.2.1_p20150521-r2]
[ebuild U  ] app-editors/vim-core-8.0.0386 [8.0.0106]
[ebuild   R] x11-base/xorg-drivers-1.18-r1  VIDEO_CARDS="(-omapfb%)"
[ebuild U  ] dev-libs/geoip-1.6.9-r1 [1.6.9]
[ebuild U ~] net-misc/youtube-dl-2017.03.02 [2017.02.22]
[ebuild U  ] dev-python/enum34-1.1.6 [1.0.4]
[ebuild  rR] dev-tex/bibtexu-3.71_p20150521
[ebuild U  ] net-libs/neon-0.30.2 [0.30.1] USE="(-libressl)"
[ebuild  N ] dev-libs/libusb-compat-0.1.5-r2  USE="-debug
-examples -static-libs" ABI_X86="32 (64) (-x32)"
[ebuild U  ] app-editors/vim-8.0.0386 [8.0.0106]
PYTHON_TARGETS="(-python3_6)"
[ebuild  NS] virtual/libusb-0-r2 [1-r2] ABI_X86="32 (64) (-x32)"
[ebuild U  ] app-vim/gentoo-syntax-20170225 [20160530]
[ebuild U ~] app-editors/gvim-8.0.0386 [8.0.0106]
PYTHON_TARGETS="-python3_6%"
[ebuild U  ] app-doc/doxygen-1.8.13-r1 [1.8.12]
[ebuild U  ] app-crypt/gnupg-2.1.18 [2.1.15] USE="smartcard* -wks-server%"
[ebuild U  ] app-crypt/gpgme-1.8.0-r2 [1.5.5] USE="cxx%* -python%
-qt5%" PYTHON_TARGETS="python2_7%* python3_4%* (-python3_5)"
[ebuild U  ] media-plugins/gst-plugins-libav-1.10.4 [1.10.3]
[ebuild  rR] app-text/dvipng-1.15
[ebuild  rR] app-text/evince-3.20.1

The following keyword changes are necessary to proceed:
 (see "package.accept_keywords" in the portage(5) man page for more details)
# required by @selected
# required by @world (argument)
=app-editors/gvim-8.0.0386 ~amd64

Would you like to add these changes to your config files? [Yes/No] n

!!! The following installed packages are masked:
- www-client/opera-12.16_p1860-r1::gentoo (masked by: OPERA-12 license(s))
A copy of the 'OPERA-12' license is located at '/usr/portage/licenses/OPERA-12'.

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

[gentoo-user] -dec-terminal- fonts

[Harry Putnam]

Some time back a standard part of an X install were fonts with names
like:
-dec-terminal-bold-r-normal--14-140-75-75-c-80-iso8859-1
-dec-terminal-medium-r-normal--0-0-75-75-c-0-dec-dectech

The list is about 10 lines longer.

I have them on a debian install but not sure where they came from.
I do believe they once part of gentoo installs too, but are not now.

asided: I have asked on debian list too, and searched their pkg repos.

I want them on my gentoo installs but can't google up a source

I see these fonts in /usr/share/fonts/

 find /usr/share/fonts -iname '*dec*'
/usr/share/fonts/encodings/dec-special.enc.gz
/usr/share/fonts/misc/decsess.pcf.gz
/usr/share/fonts/misc/deccurs.pcf.gz

I don't think those are the ones.  But that is all I turned up on
google too.

Re: [gentoo-user] llvm not updating with @world

[Dutch Ingraham]

On Sat, Mar 04, 2017 at 10:31:27AM -0500, Michael Orlitzky wrote:
> On 03/04/2017 10:18 AM, Dutch Ingraham wrote:
> > 
> > So, that will bring in the update, just like emerge -1a sys-devel/llvm
> > will.
> > 
> > But, why isn't --deep @world doing so?  Is it bug-reporting time?
> > 
> > (There is one other slight possible anomoly I could find:
> > 'equery depends sys-devel/llvm' returns llvm as a dependency of itself:
> 
> Yeah, I'm out of my depth. Just moments ago, there was a post to the
> portage list about LLVM and --with-bdeps:
> 
> https://archives.gentoo.org/gentoo-portage-dev/message/f1dfb5c37e6c3db1c2f22c137a4b15af
> 
> Some combination of the portage/llvm teams might know what's going on.

OK - thanks for looking at it and confirming I'm not missing something
obvious, which is my want, or that I was not misunderstanding what --deep was
supposed to do.  I'll file the bug.

Re: [gentoo-user] llvm not updating with @world

[Michael Orlitzky]

On 03/04/2017 10:18 AM, Dutch Ingraham wrote:
> 
> So, that will bring in the update, just like emerge -1a sys-devel/llvm
> will.
> 
> But, why isn't --deep @world doing so?  Is it bug-reporting time?
> 
> (There is one other slight possible anomoly I could find:
> 'equery depends sys-devel/llvm' returns llvm as a dependency of itself:

Yeah, I'm out of my depth. Just moments ago, there was a post to the
portage list about LLVM and --with-bdeps:

https://archives.gentoo.org/gentoo-portage-dev/message/f1dfb5c37e6c3db1c2f22c137a4b15af

Some combination of the portage/llvm teams might know what's going on.

Re: [gentoo-user] llvm not updating with @world

[Dutch Ingraham]

On Sat, Mar 04, 2017 at 09:55:30AM -0500, Michael Orlitzky wrote:
> On 03/04/2017 09:37 AM, Dutch Ingraham wrote:
> > 
> > Michael, thanks for your response.  No, I did not do a one-shot; llvm
> > was brought in by way of mesa -> gallium; this is llvm's only use on
> > this system as far as I know.
> > 
> > Also, 'emerge -ac' shows no packages to remove.
> > 
> 
> Well, there goes my one good idea =)
> 
> You can try doing "emerge -pe --tree @world" to see if llvm would get
> pulled in by anything in your system. If it is, then a --deep update
> --with-bdeps should be updating it.
> 
> One more desperate attempt: the --complete-graph option is weaker than
> --deep, I think. What happens if you remove it? (I'm wondering if
> --complete-graph overrides --deep).
> 
> If neither of those experiments are illuminating, you should file a bug.
> The portage team has a better understanding of why some things are skipped.

Removing --complete-graph doesn't change anything.  I don't usually use
that, but only added it to see if it would shake something out, but of course
it didn't.

The emerge -pe --tree @world returns, in relevant part:

[nomerge   ] mail-client/thunderbird-45.7.0 
[nomerge   ]  x11-libs/gtk+-2.24.31-r1 
[ebuild   R]   gnome-base/librsvg-2.40.16 
[ebuild   R]x11-libs/pango-1.40.3 
[ebuild   R] media-libs/harfbuzz-1.4.3 
[ebuild   R]  x11-libs/cairo-1.14.8 
[ebuild   R]   media-libs/mesa-17.0.0 
[ebuild U  ]sys-devel/llvm-3.9.1-r1 [3.7.1-r3] USE=[clip]

So, that will bring in the update, just like emerge -1a sys-devel/llvm
will.

But, why isn't --deep @world doing so?  Is it bug-reporting time?

(There is one other slight possible anomoly I could find:
'equery depends sys-devel/llvm' returns llvm as a dependency of itself:

gentoo3 ~ # equery depends sys-devel/llvm
 * These packages depend on sys-devel/llvm:
media-libs/mesa-17.0.0 [cut massive amnount of non-llvm-related options]

sys-devel/llvm-3.7.1-r3 (>=sys-devel/llvm-3.5)
gentoo3 ~ #

Is this relevant or expected?)

Thanks again.

Re: [gentoo-user] How do I install slotted guile

[karl]

Alen McKinnon:
> On 04/03/2017 15:56, k...@aspodata.se wrote:
> >  I need booth guile-2 (for geda) and guile-1.8 (for lilypond).
...
> > So, does anyone know how to install both of them ?
> You can't. At least, you can't emerge both with the current tree, you
...

Thanks, bad to know, I won't waste more time on that then.

> Your best bet is to install one version from source into /usr/local/,
> then find all the ways your system uses guile and take steps to always
> correctly identify the correct one.
...

I'll try to install 1.8.8 in /usr/local then.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57

Re: [gentoo-user] llvm not updating with @world

[Michael Orlitzky]

On 03/04/2017 09:37 AM, Dutch Ingraham wrote:
> 
> Michael, thanks for your response.  No, I did not do a one-shot; llvm
> was brought in by way of mesa -> gallium; this is llvm's only use on
> this system as far as I know.
> 
> Also, 'emerge -ac' shows no packages to remove.
> 

Well, there goes my one good idea =)

You can try doing "emerge -pe --tree @world" to see if llvm would get
pulled in by anything in your system. If it is, then a --deep update
--with-bdeps should be updating it.

One more desperate attempt: the --complete-graph option is weaker than
--deep, I think. What happens if you remove it? (I'm wondering if
--complete-graph overrides --deep).

If neither of those experiments are illuminating, you should file a bug.
The portage team has a better understanding of why some things are skipped.

Re: [gentoo-user] llvm not updating with @world

[Dutch Ingraham]

On Sat, Mar 04, 2017 at 09:30:42AM -0500, Michael Orlitzky wrote:
> On 03/04/2017 06:38 AM, Dutch Ingraham wrote:
> > Hi all - I'm running a systemd/hardened desktop with 
> > ACCEPT_KEYWORDS="~amd64". 
> > The result of an 'emerge -auDN --with-bdeps=y --complete-graph @world' is 
> > 'Nothing to merge; quitting.'
> > 
> > However, if I 'emerge -1a sys-devel/llvm', I get: 
> > '[ebuild  r  U  ] sys-devel/llvm-3.9.1-r1 [3.7.1-r3]' and
> > '[ebuild  rR] media-libs/mesa-17.0.0'
> > 
> > So, why is a reinstall of llvm triggering an upgrade but an @world is not?
> > 
> 
> Once upon a time, did you "emerge --oneshot llvm"? You can check by
> doing an "emerge --depclean" to see if llvm would be removed.

Michael, thanks for your response.  No, I did not do a one-shot; llvm
was brought in by way of mesa -> gallium; this is llvm's only use on
this system as far as I know.

Also, 'emerge -ac' shows no packages to remove.

Re: [gentoo-user] llvm not updating with @world

[Michael Orlitzky]

On 03/04/2017 06:38 AM, Dutch Ingraham wrote:
> Hi all - I'm running a systemd/hardened desktop with 
> ACCEPT_KEYWORDS="~amd64". 
> The result of an 'emerge -auDN --with-bdeps=y --complete-graph @world' is 
> 'Nothing to merge; quitting.'
> 
> However, if I 'emerge -1a sys-devel/llvm', I get: 
> '[ebuild  r  U  ] sys-devel/llvm-3.9.1-r1 [3.7.1-r3]' and
> '[ebuild  rR] media-libs/mesa-17.0.0'
> 
> So, why is a reinstall of llvm triggering an upgrade but an @world is not?
> 

Once upon a time, did you "emerge --oneshot llvm"? You can check by
doing an "emerge --depclean" to see if llvm would be removed.

Re: [gentoo-user] How do I install slotted guile

[Alan McKinnon]

On 04/03/2017 15:56, k...@aspodata.se wrote:
>  I need booth guile-2 (for geda) and guile-1.8 (for lilypond).
> 
>  I can install either of the two
> # emerge -aqv  dev-scheme/guile:12/8  # version 1.8.8
> # emerge -aqv  dev-scheme/guile:12/22 # version 2.0.14
> 
> but not both
> 
> # emerge -aqvuDN dev-scheme/guile:12/22 dev-scheme/guile:12/8 
> [ebuild UD] dev-scheme/guile-1.8.8-r3 [2.0.14] USE="deprecated emacs%* 
> networking nls readline%* regex threads -debug -debug-freelist% -debug-malloc 
> -discouraged%" 
> 
> !!! Multiple package instances within a single package slot have been pulled
> !!! into the dependency graph, resulting in a slot conflict:
> ...
> 
> So, does anyone know how to install both of them ?


You can't. At least, you can't emerge both with the current tree, you
can only have one version. SLOTting packages is trying is you don't know
how to do it, I'd advise not doing that.

Your best bet is to install one version from source into /usr/local/,
then find all the ways your system uses guile and take steps to always
correctly identify the correct one.

Another option is to find a way to go without geda and/or/lilypond


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

Re: [gentoo-user] Gpgme oddity

[Marc Joliet]

On Saturday 04 March 2017 10:52:57 Mick wrote:
> On Saturday 04 Mar 2017 09:45:28 Peter Humphrey wrote:
> > Greetings.
> > 
> > This is a KDE ~amd64 box, which still depends on kde-apps/kdepimlibs:4 for
> > many things. I've been running happily on =app-crypt/gpgme-1.5.5, but
> > today
> > portage wants to upgrade to =app-crypt/gpgme-1.8.0-r2. But that version
> > can't be installed while kdepimlibs:4 is still around, as I see from the
> > ebuild:
> > 
> > [...]
> > RDEPEND="${COMMON_DEPEND}
> > 
> > cxx? (
> > 
> > !kde-apps/gpgmepp
> > !kde-apps/kdepimlibs:4
> > 
> > )"
> > 
> > [...]
> > 
> > Is it even possible to satisfy that condition?
> 
> I saw Peter's post just as I hit sent on mine.  :-)
> 
> Apparently USE="-cxx -qt5" should allow gpgme to build.  kdepimlibs goes
> away on KDE-5 and the packages affected are in flux at this point.  I will
> rinse and repeat at a later date.

True, but then you'll probably hit bug #600510.  I did and ended up going the 
mask route for now. (I may actually attempt to upgrade to KDE PIM 16.12.2, but 
that pulls in a long tail of other packages due to QT_MINIMAL="5.7.0".)

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


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

[gentoo-user] How do I install slotted guile

[karl]

 I need booth guile-2 (for geda) and guile-1.8 (for lilypond).

 I can install either of the two
# emerge -aqv  dev-scheme/guile:12/8  # version 1.8.8
# emerge -aqv  dev-scheme/guile:12/22 # version 2.0.14

but not both

# emerge -aqvuDN dev-scheme/guile:12/22 dev-scheme/guile:12/8 
[ebuild UD] dev-scheme/guile-1.8.8-r3 [2.0.14] USE="deprecated emacs%* 
networking nls readline%* regex threads -debug -debug-freelist% -debug-malloc 
-discouraged%" 

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
...

So, does anyone know how to install both of them ?

///

Searching I find info. how to specify slotting in ebuild files, but
not how to actually install things in slots; man emerge wasn't to much
help either.

I could install it outside of emerge, in /usr/local. I did that for
some version of guile 2.0, but removed it so not to interfere with the
emerge work thing. But then, when I tried to emerge guile 2.0.14 I
got 

 make: error while loading shared libraries: libguile-2.0.so.22: cannot open 
shared object file: No such file or directory

I thougth it was strange that building guile would fail on missing
the libguile, and it happened whatever I did, until I realized that
make had a dependancy on libguile. Stupid thing, I couldn't rebuild
make with USE=-guile, since make didn't work any longer. So, I'd
prefer not go through that again (in the end I grabbed make from a
stage3 I had laying).

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57

Re: [gentoo-user] Gpgme oddity

[Marc Joliet]

On Saturday 04 March 2017 14:59:51 Alan McKinnon wrote:
> On 04/03/2017 14:33, Peter Humphrey wrote:
> > On Saturday 04 Mar 2017 12:42:38 Alan McKinnon wrote:
> >> On 04/03/2017 11:45, Peter Humphrey wrote:
> >>> Greetings.
> >>> 
> >>> This is a KDE ~amd64 box, which still depends on kde-apps/kdepimlibs:4
> >>> for many things. I've been running happily on =app-crypt/gpgme-1.5.5,
> >>> but today portage wants to upgrade to =app-crypt/gpgme-1.8.0-r2. But
> >>> that version can't be installed while kdepimlibs:4 is still around, as
> >>> I see from the ebuild:
> >>> 
> >>> [...]
> >>> RDEPEND="${COMMON_DEPEND}
> >>> 
> >>> cxx? (
> >>> 
> >>> !kde-apps/gpgmepp
> >>> !kde-apps/kdepimlibs:4
> >>> 
> >>> )"
> >>> 
> >>> [...]
> >>> 
> >>> Is it even possible to satisfy that condition?
> >> 
> >> No, but you can mask app-crypt/gpgme-1.8.0-r2 and stay on 1.5/1.6
> > 
> > Yes, I've done that, but why has such silliness been allowed out?
> 
> Maybe that combination never got tested? It's a ~arch package, so you
> get to be a field tester when you use it :-)

Not anymore it isn't, see https://packages.gentoo.org/packages/app-crypt/gpgme. 
 The bug referenced in the other gpgme thread [0] is the 
corresponding stabilisation bug.

I'm surprised the plasma profile wasn't modified to deal with this.  After 
all, it already takes care of various other blockers.

[0] https://bugs.gentoo.org/show_bug.cgi?id=611470

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


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

Re: [gentoo-user] Gpgme oddity

[Alan McKinnon]

On 04/03/2017 14:33, Peter Humphrey wrote:
> On Saturday 04 Mar 2017 12:42:38 Alan McKinnon wrote:
>> On 04/03/2017 11:45, Peter Humphrey wrote:
>>> Greetings.
>>>
>>> This is a KDE ~amd64 box, which still depends on kde-apps/kdepimlibs:4
>>> for many things. I've been running happily on =app-crypt/gpgme-1.5.5,
>>> but today portage wants to upgrade to =app-crypt/gpgme-1.8.0-r2. But
>>> that version can't be installed while kdepimlibs:4 is still around, as
>>> I see from the ebuild:
>>>
>>> [...]
>>> RDEPEND="${COMMON_DEPEND}
>>>
>>> cxx? (
>>> 
>>> !kde-apps/gpgmepp
>>> !kde-apps/kdepimlibs:4
>>> 
>>> )"
>>>
>>> [...]
>>>
>>> Is it even possible to satisfy that condition?
>>
>> No, but you can mask app-crypt/gpgme-1.8.0-r2 and stay on 1.5/1.6
> 
> Yes, I've done that, but why has such silliness been allowed out?

Maybe that combination never got tested? It's a ~arch package, so you
get to be a field tester when you use it :-)


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

Re: [gentoo-user] Gpgme oddity

[Peter Humphrey]

On Saturday 04 Mar 2017 12:42:38 Alan McKinnon wrote:
> On 04/03/2017 11:45, Peter Humphrey wrote:
> > Greetings.
> > 
> > This is a KDE ~amd64 box, which still depends on kde-apps/kdepimlibs:4
> > for many things. I've been running happily on =app-crypt/gpgme-1.5.5,
> > but today portage wants to upgrade to =app-crypt/gpgme-1.8.0-r2. But
> > that version can't be installed while kdepimlibs:4 is still around, as
> > I see from the ebuild:
> > 
> > [...]
> > RDEPEND="${COMMON_DEPEND}
> > 
> > cxx? (
> > 
> > !kde-apps/gpgmepp
> > !kde-apps/kdepimlibs:4
> > 
> > )"
> > 
> > [...]
> > 
> > Is it even possible to satisfy that condition?
> 
> No, but you can mask app-crypt/gpgme-1.8.0-r2 and stay on 1.5/1.6

Yes, I've done that, but why has such silliness been allowed out?

I may take the other route and add -cxx (and -qt5?) to USE for gpgme; needs 
a little thought.

In answer to Alan, 23 packages here depend on kdepimlibs:4. That's with the 
plasma profile, so I'm not being Luddite here. It's not nearly time yet to 
ditch :4.

-- 
Regards
Peter

Re: [gentoo-user] gpgme update and kdepimlibs-4.14.11_pre20160211 blocker

[Alan McKinnon]

On 04/03/2017 13:02, Mick wrote:
> On Saturday 04 Mar 2017 12:41:48 Alan McKinnon wrote:
>> On 04/03/2017 11:50, Mick wrote:
>>> Hi All,
>>>
>>> This morning's attempt to update a no-multilib PC brought up this
>>> conflict:
>>>
>>> # emerge -1aDv app-crypt/gpgme
>>>
>>> These are the packages that would be merged, in order:
>>>
>>> Calculating dependencies... done!
>>> [ebuild U  ] app-crypt/gpgme-1.8.0-r2:1/11::gentoo
>>> [1.5.5:1/11::gentoo]
>>> USE="cxx%* qt5%* -common-lisp -python% -static-libs"
>>> PYTHON_TARGETS="python2_7%* python3_4%* (-python3_5)" 1,268 KiB
>>> [blocks B  ] kde-apps/kdepimlibs:4 ("kde-apps/kdepimlibs:4" is
>>> blocking
>>> app-crypt/gpgme-1.8.0-r2)
>>>
>>> Total: 1 package (1 upgrade), Size of downloads: 1,268 KiB
>>> Conflict: 1 block (1 unsatisfied)
>>>
>>>  * Error: The above package list contains packages which cannot be
>>>  * installed at the same time on the same system.
>>
>> The blocker in gpgme-1.8.0-r2 is this:
>>
>> RDEPEND="${COMMON_DEPEND}
>> cxx? (
>> !kde-apps/gpgmepp
>> !kde-apps/kdepimlibs:4
>> )"
>>
>>> I can see that kde-apps/kdepimlibs-4.14.11_pre20160211-r2 is the latest
>>> version in the tree.  How am I supposed to move on from here?
>>
>> 2 options:
>>
>> - remove cxx from USE for gpgme
>> - mask gpgme-1.8.0-r2 and continue to use gpgme-1.6.0
>>
>> If you cannot use either of those options, then you cannot have
>> kdepimlibs:4. Unfortunately, gentoo never guaranteed that KDE-4 would
>> work endlessly, a day will come when it simply can't be done anymore.
>> kdepim-4 users need to know this, and there is a non-zero chance that
>> that day may be today
> 
> Thanks Alan, I posted a minute ago, there it is needed to also set USE="-qt" 
> for gpgme to build.
> 
> So what replaces kdepimlibs in KDE-5?  Is it being absorbed in some other 
> package?
> 


I haven't tracked pim in kde for years now, but looking in the ebuild
for kmail:5 I'd hazard a guess and say kdepim-apps-libs



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

[gentoo-user] llvm not updating with @world

[Dutch Ingraham]

Hi all - I'm running a systemd/hardened desktop with ACCEPT_KEYWORDS="~amd64". 
The result of an 'emerge -auDN --with-bdeps=y --complete-graph @world' is 
'Nothing to merge; quitting.'

However, if I 'emerge -1a sys-devel/llvm', I get: 
'[ebuild  r  U  ] sys-devel/llvm-3.9.1-r1 [3.7.1-r3]' and
'[ebuild  rR] media-libs/mesa-17.0.0'

So, why is a reinstall of llvm triggering an upgrade but an @world is not?

Thanks

Re: [gentoo-user] gpgme update and kdepimlibs-4.14.11_pre20160211 blocker

[Mick]

On Saturday 04 Mar 2017 12:41:48 Alan McKinnon wrote:
> On 04/03/2017 11:50, Mick wrote:
> > Hi All,
> > 
> > This morning's attempt to update a no-multilib PC brought up this
> > conflict:
> > 
> > # emerge -1aDv app-crypt/gpgme
> > 
> > These are the packages that would be merged, in order:
> > 
> > Calculating dependencies... done!
> > [ebuild U  ] app-crypt/gpgme-1.8.0-r2:1/11::gentoo
> > [1.5.5:1/11::gentoo]
> > USE="cxx%* qt5%* -common-lisp -python% -static-libs"
> > PYTHON_TARGETS="python2_7%* python3_4%* (-python3_5)" 1,268 KiB
> > [blocks B  ] kde-apps/kdepimlibs:4 ("kde-apps/kdepimlibs:4" is
> > blocking
> > app-crypt/gpgme-1.8.0-r2)
> > 
> > Total: 1 package (1 upgrade), Size of downloads: 1,268 KiB
> > Conflict: 1 block (1 unsatisfied)
> > 
> >  * Error: The above package list contains packages which cannot be
> >  * installed at the same time on the same system.
> 
> The blocker in gpgme-1.8.0-r2 is this:
> 
> RDEPEND="${COMMON_DEPEND}
> cxx? (
> !kde-apps/gpgmepp
> !kde-apps/kdepimlibs:4
> )"
> 
> > I can see that kde-apps/kdepimlibs-4.14.11_pre20160211-r2 is the latest
> > version in the tree.  How am I supposed to move on from here?
> 
> 2 options:
> 
> - remove cxx from USE for gpgme
> - mask gpgme-1.8.0-r2 and continue to use gpgme-1.6.0
> 
> If you cannot use either of those options, then you cannot have
> kdepimlibs:4. Unfortunately, gentoo never guaranteed that KDE-4 would
> work endlessly, a day will come when it simply can't be done anymore.
> kdepim-4 users need to know this, and there is a non-zero chance that
> that day may be today

Thanks Alan, I posted a minute ago, there it is needed to also set USE="-qt" 
for gpgme to build.

So what replaces kdepimlibs in KDE-5?  Is it being absorbed in some other 
package?
-- 
Regards,
Mick

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

[gentoo-user] Re: gpgme update and kdepimlibs-4.14.11_pre20160211 blocker

[Mick]

On Saturday 04 Mar 2017 09:50:21 Mick wrote:
> Hi All,
> 
> This morning's attempt to update a no-multilib PC brought up this conflict:
> 
> # emerge -1aDv app-crypt/gpgme
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild U  ] app-crypt/gpgme-1.8.0-r2:1/11::gentoo [1.5.5:1/11::gentoo]
> USE="cxx%* qt5%* -common-lisp -python% -static-libs"
> PYTHON_TARGETS="python2_7%* python3_4%* (-python3_5)" 1,268 KiB
> [blocks B  ] kde-apps/kdepimlibs:4 ("kde-apps/kdepimlibs:4" is blocking
> app-crypt/gpgme-1.8.0-r2)
> 
> Total: 1 package (1 upgrade), Size of downloads: 1,268 KiB
> Conflict: 1 block (1 unsatisfied)
> 
>  * Error: The above package list contains packages which cannot be
>  * installed at the same time on the same system.
> 
>   (kde-apps/kdepimlibs-4.14.11_pre20160211-r2:4/4.14::gentoo, installed)
> pulled in by
> 
> >=kde-apps/kdepimlibs-4.14:4[aqua=]
> >(>=kde-apps/kdepimlibs-4.14:4[-aqua])
> 
> required by (kde-apps/libkgapi-2.2.0:4/4::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
> 
> apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
> apps/kalarm-4.14.11_pre20160211:4/4.14::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
> 
> apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
> apps/kabcclient-4.14.11_pre20160211:4/4.14::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
> 
> apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
> apps/konsolekalendar-4.14.11_pre20160211:4/4.14::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
> 
> apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
> apps/kaddressbook-4.14.11_pre20160211:4/4.14::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
> 
> apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
> apps/blogilo-4.14.11_pre20160211:4/4.14::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
> 
> apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
> apps/ktnef-4.14.11_pre20160211:4/4.14::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
> 
> apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
> apps/akregator-4.14.11_pre20160211:4/4.14::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
> 
> apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
> apps/kmail-4.14.11_pre20160211:4/4.14::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
> 
> apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
> apps/kdepim-common-libs-4.14.11_pre20160211:4/4.14::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
> 
> apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
> apps/knode-4.14.11_pre20160211:4/4.14::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
> 
> apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
> apps/kdepim-runtime-4.14.11_pre20160211:4/4.14::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
> 
> apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
> apps/calendarjanitor-4.14.11_pre20160211:4/4.14::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.4:4[aqua=] (>=kde-apps/kdepimlibs-4.4:4[-aqua])
> 
> required by (app-office/kmymoney-4.7.2:4/4::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
> 
> apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
> apps/ktimetracker-4.14.11_pre20160211:4/4.14::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
> 
> apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
> apps/kjots-4.14.11_pre20160211:4/4.14::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
> 
> apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
> apps/knotes-4.14.11_pre20160211:4/4.14::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
> 
> apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
> apps/akonadiconsole-4.14.11_pre20160211:4/4.14::gentoo, installed)
> 
> >=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
> 
> apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
> apps/kleopatra-4.14.11_pre20160211:4/4.14::gentoo, 

Re: [gentoo-user] Gpgme oddity

[Mick]

On Saturday 04 Mar 2017 09:45:28 Peter Humphrey wrote:
> Greetings.
> 
> This is a KDE ~amd64 box, which still depends on kde-apps/kdepimlibs:4 for
> many things. I've been running happily on =app-crypt/gpgme-1.5.5, but today
> portage wants to upgrade to =app-crypt/gpgme-1.8.0-r2. But that version
> can't be installed while kdepimlibs:4 is still around, as I see from the
> ebuild:
> 
> [...]
> RDEPEND="${COMMON_DEPEND}
> cxx? (
> !kde-apps/gpgmepp
> !kde-apps/kdepimlibs:4
> )"
> [...]
> 
> Is it even possible to satisfy that condition?

I saw Peter's post just as I hit sent on mine.  :-)

Apparently USE="-cxx -qt5" should allow gpgme to build.  kdepimlibs goes away 
on KDE-5 and the packages affected are in flux at this point.  I will rinse 
and repeat at a later date.
-- 
Regards,
Mick

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

Re: [gentoo-user] Gpgme oddity

[Alan McKinnon]

On 04/03/2017 11:45, Peter Humphrey wrote:
> Greetings.
> 
> This is a KDE ~amd64 box, which still depends on kde-apps/kdepimlibs:4 for 
> many things. I've been running happily on =app-crypt/gpgme-1.5.5, but today 
> portage wants to upgrade to =app-crypt/gpgme-1.8.0-r2. But that version 
> can't be installed while kdepimlibs:4 is still around, as I see from the 
> ebuild:
> 
> [...]
> RDEPEND="${COMMON_DEPEND}
> cxx? (
> !kde-apps/gpgmepp
> !kde-apps/kdepimlibs:4
> )"
> [...]
> 
> Is it even possible to satisfy that condition?
> 

No, but you can mask app-crypt/gpgme-1.8.0-r2 and stay on 1.5/1.6

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

Re: [gentoo-user] gpgme update and kdepimlibs-4.14.11_pre20160211 blocker

[Alan McKinnon]

On 04/03/2017 11:50, Mick wrote:
> Hi All,
> 
> This morning's attempt to update a no-multilib PC brought up this conflict:
> 
> # emerge -1aDv app-crypt/gpgme
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild U  ] app-crypt/gpgme-1.8.0-r2:1/11::gentoo [1.5.5:1/11::gentoo] 
> USE="cxx%* qt5%* -common-lisp -python% -static-libs" 
> PYTHON_TARGETS="python2_7%* python3_4%* (-python3_5)" 1,268 KiB
> [blocks B  ] kde-apps/kdepimlibs:4 ("kde-apps/kdepimlibs:4" is blocking 
> app-crypt/gpgme-1.8.0-r2)
> 
> Total: 1 package (1 upgrade), Size of downloads: 1,268 KiB
> Conflict: 1 block (1 unsatisfied)
> 
>  * Error: The above package list contains packages which cannot be
>  * installed at the same time on the same system.

The blocker in gpgme-1.8.0-r2 is this:

RDEPEND="${COMMON_DEPEND}
cxx? (
!kde-apps/gpgmepp
!kde-apps/kdepimlibs:4
)"

> I can see that kde-apps/kdepimlibs-4.14.11_pre20160211-r2 is the latest 
> version in the tree.  How am I supposed to move on from here?

2 options:

- remove cxx from USE for gpgme
- mask gpgme-1.8.0-r2 and continue to use gpgme-1.6.0

If you cannot use either of those options, then you cannot have
kdepimlibs:4. Unfortunately, gentoo never guaranteed that KDE-4 would
work endlessly, a day will come when it simply can't be done anymore.
kdepim-4 users need to know this, and there is a non-zero chance that
that day may be today

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

[gentoo-user] 32 bit firefox on 64 bit system

[Jorge Almeida]

Is it possible?

Background: some time ago I converted my atom 330 system (ASUS ION) to
64 bits. RAM is about 3.3GB, but usage never approaches the limit. My
problem is that firefox went snail. chromium seems OK (I can't recall
whether it was faster on 32 bits, but anyway the difference is small).

Firefox runs OK on a faster computer (i3) in the same LAN (also 64
bits). I assume the problem is CPU or MO specific.

I thought of using a 32 bit firefox, while keeping a 64 bit system. I
use a 64 bit custom kernel with support for 32 bit binaries. The
question is, how to compile firefox? (It is OK if I have to recompile
basic libraries, as long as this is stable...)

TIA

Jorge Almeida

[gentoo-user] gpgme update and kdepimlibs-4.14.11_pre20160211 blocker

[Mick]

Hi All,

This morning's attempt to update a no-multilib PC brought up this conflict:

# emerge -1aDv app-crypt/gpgme

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild U  ] app-crypt/gpgme-1.8.0-r2:1/11::gentoo [1.5.5:1/11::gentoo] 
USE="cxx%* qt5%* -common-lisp -python% -static-libs" 
PYTHON_TARGETS="python2_7%* python3_4%* (-python3_5)" 1,268 KiB
[blocks B  ] kde-apps/kdepimlibs:4 ("kde-apps/kdepimlibs:4" is blocking 
app-crypt/gpgme-1.8.0-r2)

Total: 1 package (1 upgrade), Size of downloads: 1,268 KiB
Conflict: 1 block (1 unsatisfied)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (kde-apps/kdepimlibs-4.14.11_pre20160211-r2:4/4.14::gentoo, installed) 
pulled in by
>=kde-apps/kdepimlibs-4.14:4[aqua=] (>=kde-apps/kdepimlibs-4.14:4[-aqua]) 
required by (kde-apps/libkgapi-2.2.0:4/4::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/kalarm-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/kabcclient-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/konsolekalendar-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/kaddressbook-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/blogilo-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/ktnef-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/akregator-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/kmail-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/kdepim-common-libs-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/knode-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/kdepim-runtime-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/calendarjanitor-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.4:4[aqua=] (>=kde-apps/kdepimlibs-4.4:4[-aqua]) 
required by (app-office/kmymoney-4.7.2:4/4::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/ktimetracker-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/kjots-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/knotes-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/akonadiconsole-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/kleopatra-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.11_pre20160211:4[aqua=,akonadi(+)] (>=kde-
apps/kdepimlibs-4.14.11_pre20160211:4[-aqua,akonadi(+)]) required by (kde-
apps/kontact-4.14.11_pre20160211:4/4.14::gentoo, installed)
>=kde-apps/kdepimlibs-4.14.3:4[aqua=] (>=kde-apps/kdepimlibs-4.14.3:4[-
aqua]) required by 

[gentoo-user] Gpgme oddity

[Peter Humphrey]

Greetings.

This is a KDE ~amd64 box, which still depends on kde-apps/kdepimlibs:4 for 
many things. I've been running happily on =app-crypt/gpgme-1.5.5, but today 
portage wants to upgrade to =app-crypt/gpgme-1.8.0-r2. But that version 
can't be installed while kdepimlibs:4 is still around, as I see from the 
ebuild:

[...]
RDEPEND="${COMMON_DEPEND}
cxx? (
!kde-apps/gpgmepp
!kde-apps/kdepimlibs:4
)"
[...]

Is it even possible to satisfy that condition?

-- 
Regards
Peter

[gentoo-user] Re: CIFS mounts started misbehaving

[Kai Krakow]

Am Sat, 04 Mar 2017 08:02:11 +
schrieb "J. Roeleveld" :

> On March 4, 2017 12:41:05 AM GMT+01:00, Grant Edwards
>  wrote:
> >On 2017-03-03, J. Roeleveld  wrote:
> >  
> >> On March 3, 2017 7:49:27 PM GMT+01:00, Grant Edwards  
> > wrote:
> >  
>  [...]  
> >and  
>  [...]  
> >
> >[...]
> >  
> >> My guess would be some timeout setting on the server killing the
> >> login.  
> >
> >That doesn't seem to be the problem.  I've asked around, and others
> >aren't seeing this problem.
> >
> >I've also noticed that sometimes the mounts will start working again
> >without a umount/mount, but I can't figure out what causes it...
> >
> >Normally, when things are working but idle, the TCP connection to 445
> >shows an SMB echo request/rseponse transaction once per minute.  When
> >it fails, the TCP connection evidently got dropped, and the Windows
> >machine repeatedly shuts down new ones:
> >
> >The failure mode looks like this in wireshark:
> >
> >  GentooWindows
> >  
> >  -> SYN  ->  445  
> > <-SYN/ACK   <-   445  
> >  -> ACK  ->  445
> >  -> SMB[echo req]->  445  
> > <-  RST <-   445
> >
> >[that repeats 800 times per second for long periods of time]
> >
> >Then at some point, it starts to work:
> >  
> >  ->SYN  ->  445  
> > <-   SYN/ACK   <-   445  
> >  ->ACK  ->  445
> >  -> SMB[proto neg req]  ->  445  
> > <-  SMB[proto neg rsp] <-   445  
> >  -> SMB[ses setup req]  ->  445  
> > <-  SMB[ses setup rsp] <-   445
> > ...
> > 
> >Sometimes the umount times out and "fails" because the "host is
> >down", and when that happens, it seems like it immediately starts to
> >work again. :/  
> 
> Are other hosts linux or windows?
> 
> Maybe a dodgy switch forgetting the correct path?

Or an MTU problem... Is there a router in the path?

-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: CIFS mounts started misbehaving

[J. Roeleveld]

On March 4, 2017 12:41:05 AM GMT+01:00, Grant Edwards 
 wrote:
>On 2017-03-03, J. Roeleveld  wrote:
>
>> On March 3, 2017 7:49:27 PM GMT+01:00, Grant Edwards
> wrote:
>
>>>About a week ago, they started acting oddly.  They all mount fine,
>and
>>>work as usual as long as you keep using them.  AFAICT, if they sit
>>>idle for "a while" (tens of minutes, maybe an hour), they freeze up.
>
>[...]
>
>> My guess would be some timeout setting on the server killing the
>> login.
>
>That doesn't seem to be the problem.  I've asked around, and others
>aren't seeing this problem.
>
>I've also noticed that sometimes the mounts will start working again
>without a umount/mount, but I can't figure out what causes it...
>
>Normally, when things are working but idle, the TCP connection to 445
>shows an SMB echo request/rseponse transaction once per minute.  When
>it fails, the TCP connection evidently got dropped, and the Windows
>machine repeatedly shuts down new ones:
>
>The failure mode looks like this in wireshark:
>
>  GentooWindows
>
>  -> SYN  ->  445
> <-SYN/ACK   <-   445
>  -> ACK  ->  445
>  -> SMB[echo req]->  445
> <-  RST <-   445
>
>[that repeats 800 times per second for long periods of time]
>
>Then at some point, it starts to work:
>
>  ->SYN  ->  445
> <-   SYN/ACK   <-   445
>  ->ACK  ->  445
>  -> SMB[proto neg req]  ->  445
> <-  SMB[proto neg rsp] <-   445
>  -> SMB[ses setup req]  ->  445
> <-  SMB[ses setup rsp] <-   445
> ...
> 
>Sometimes the umount times out and "fails" because the "host is down",
>and when that happens, it seems like it immediately starts to work
>again. :/

Are other hosts linux or windows?

Maybe a dodgy switch forgetting the correct path?

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.