[gentoo-dev] Re: Re: stable gcc 5.4.0 ??
Walter Dnes wrote: > On Thu, Apr 20, 2017 at 05:52:20PM -0500, Matthias Maier wrote > >> (A-C) gcc-5.4.0 and gcc-4.9.4 are slotted separately. What is going to >> be the default is entirely up to you. > > Good to hear. Like I said, on a fresh install I'd go with the current > version (5.4). But for now, I'll wait for other people to experience > problems. If nothing major, I might switch at a convenient time. > You just have to be careful with emerge -c This will remove the old "unused" gcc silently :-/ Cheers, Jörg
[gentoo-dev] Re: stable gcc 5.4.0 ??
Tomas Mozes wrote: > On Tue, Apr 18, 2017 at 10:15 AM, Jörg Schaible < > joerg.schai...@bpm-inspire.com> wrote: > >> Hi, >> >> according the logs, gcc 4.5.0-r3 is stable for amd64: >> https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc?showmsg=1 >> >> However, after synching the tree, this version is still unstable for me. >> Looking at the packages overview, it becomes even more weird, because >> there seem to be two 4.5.0-r3 versions, one stable for amd64 and one >> unstable: https://packages.gentoo.org/packages/sys-devel/gcc >> >> Can someone shed some light on this? >> >> Cheers, >> Jörg >> >> >> > You did mean 5.4.0-r3, right? Right. And James found the reason why was not in the stable branch. Cheers, Jörg
[gentoo-dev] Re: Re: Re: stable gcc 5.4.0 ??
James Le Cuirot wrote: > On Tue, 18 Apr 2017 15:12:13 +0200 > Jörg Schaible <joerg.schai...@bpm-inspire.com> wrote: > >> As said, I synced the tree twice this morning (4 hours ago) and the >> KEYWORDS in the ebuild do not declare amd64 as stable although it was >> committed to GIT already yesterday. And this is no wonder, because >> the stable branch of the GIT mirror is still not up-to-date: >> https://github.com/gentoo-mirror/gentoo/tree/stable/sys-devel/gcc > > It's been held up by this outstanding issue: > https://qa-reports.gentoo.org/output/gentoo-ci/58d678e2a/output.html#dev-db/psqlodbc > Thanks for the info. Always good to know, why something does not behave as expected. Cheers, Jörg
[gentoo-dev] Re: Re: stable gcc 5.4.0 ??
Tomas Mozes wrote: [snip] > As mentioned by others, bugs on packages.gentoo.org will not affect your > portage tree. I've just installed gcc 5.4.0-r3 on amd64, so try syncing > your portage tree. Don't you have it in your package.mask? As said, I synced the tree twice this morning (4 hours ago) and the KEYWORDS in the ebuild do not declare amd64 as stable although it was committed to GIT already yesterday. And this is no wonder, because the stable branch of the GIT mirror is still not up-to-date: https://github.com/gentoo-mirror/gentoo/tree/stable/sys-devel/gcc gcc-4.5.0-r3 is declared unstable and is not masked. Cheers, Jörg
[gentoo-dev] Re: stable gcc 5.4.0 ??
Hi Tomas, Tomas Mozes wrote: > On Tue, Apr 18, 2017 at 10:15 AM, Jörg Schaible < > joerg.schai...@bpm-inspire.com> wrote: > >> Hi, >> >> according the logs, gcc 4.5.0-r3 is stable for amd64: >> https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc?showmsg=1 >> >> However, after synching the tree, this version is still unstable for me. >> Looking at the packages overview, it becomes even more weird, because >> there seem to be two 4.5.0-r3 versions, one stable for amd64 and one >> unstable: https://packages.gentoo.org/packages/sys-devel/gcc >> >> Can someone shed some light on this? >> >> Cheers, >> Jörg >> >> >> > On which platform do you have it unstable? The packages problem is > probably related to: > https://bugs.gentoo.org/show_bug.cgi?id=612178 Amd64. Yes, it might be the same problem. The ebuild for gcc-4.5.0-r3 on my machine lists amd64 as unstable after synching the tree while the ebuild available over packages.gentoo.org has a stable version in KEYWORDS. Even if some GIT mirrors might be out of sync, it does not explain why https://packages.gentoo.org/packages/sys-devel/gcc lists the same version more than once. Cheers, Jörg
[gentoo-dev] stable gcc 5.4.0 ??
Hi, according the logs, gcc 4.5.0-r3 is stable for amd64: https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc?showmsg=1 However, after synching the tree, this version is still unstable for me. Looking at the packages overview, it becomes even more weird, because there seem to be two 4.5.0-r3 versions, one stable for amd64 and one unstable: https://packages.gentoo.org/packages/sys-devel/gcc Can someone shed some light on this? Cheers, Jörg
[gentoo-dev] Broken file protocol after KDE 5 upgrade
Hi, after upgrading to KDE 5, all remaining KDE 4 applications report a broken/unknown file protocol. This means: - cannot save attachments in KMail - cannot open HTML files FS in Konqueror - cannot assign covers to albums from local FS in Amarok Does anybody know how to fix this? Cheers, Jörg
[gentoo-dev] Re: rfc: the demise of grub:0
-1 I'd love to move to grub2 for all of my machines, but it does simply not work for one of my servers. I can install grub2 and it tells me that installation and anything else went fine, but when I try to boot with it, it stops and reports me that it found some conflicting area in my bios why it cannot work (sorry, I tell this from my memory, I've tried it quite some time ago). Mr. Google says that this may happen for some hardware, but has no solution to it. So, what are my options (or other people's options with such incompatible hardware) without grub 1? Lilo? - Jörg William Hubbs wrote: > All, > > I want to look into removing grub:0 from the tree; here are my thoughts > on why it should go. > > - the handbook doesn't document grub:0; we officially only support > grub:2. > > - There are multiple bugs open against grub:0 (15 at my last count). A > number of these as I understand it are because of custom patches we > apply. > > - grub:0 can't boot a nomultilib system, so we have to maintain a > separate package (grub-static) specifically for that setup. > > - Removing grub:0 from the tree doesn't stop you from using it. If people > really want it I will place it in the graveyard overlay. > > - We have custom patches for grub:0, which will never go upstream. > > - grub:0 is dead upstream. They have not done any work on it in years. > > - The only real problem with grub:2 has to do with pperception. Yes, > their documentation has a strong preference toward using their > configuration script (grub-mkconfig) to generate your grub.cfg, but > this is not required. > > So, I want to make a plan to lastrite grub:0 and grub-static. > > I'm thinking, in about a week, p.mask grub:0 along with grub-static and > send out a lastrites msg with a 30 day removal notice. > > If there any technical objections to this, let me know what they are. > > Thanks, > > William
[gentoo-dev] Re: Re: [RFC] Masterplan for solving LINGUAS problems
Michał Górny wrote: > Dnia 31 maja 2016 23:34:07 CEST, "Jörg Schaible" <joerg.schai...@gmx.de> > napisał(a): >>How can I select different linguas for individual packages with this >>approach? > > Using the currently available mechanisms you could use package.env to > alter INSTALL_MASK, e.g.: > > /etc/portage/env/german: > INSTALL_MASK="@l10n -@l10n-de" > > /etc/portage/package.env: > dev-foo/* german > > However, we will probably deploy a convenient package.install_mask file. OK, just to get this right. I always want English locale, for GUI apps also German and sometimes even French (office apps). Therefore I should set in future something along: /etc/portage/make.conf: LINGUAS="en de fr" INSTALL_MASK="@l10n -@l10n-en" /etc/portage/env/add-de: INSTALL_MASK="@l10n -@l10n-en -@l10n-de" /etc/portage/env/add-de-fr: INSTALL_MASK="@l10n -@l10n-en -@l10n-de -@l10n-fr" /etc/portage/package.env: dev-foo-gui/* add-de dev-bar-office/* add-fr Sounds reasonable to me. It's just no longer obvious(*) which packages actually support different languages. (*) Boldly assuming all packages provide the correct info currently ;-) Cheers, Jörg
[gentoo-dev] Re: Re: [RFC] Masterplan for solving LINGUAS problems
Mike Gilbert wrote: > On Tue, May 31, 2016 at 5:34 PM, Jörg Schaible <joerg.schai...@gmx.de> > wrote: >> How can I select different linguas for individual packages with this >> approach? > > Why would you want to? As programmer I am used to read English manuals and for most command line tools it is the only up-to-date documentation. Development tools or system configuration with translated manuals is simply awful for me. Therefore I've set LINGUAS to "en" in make.conf and run my shells with "LANG=en_US.UTF-8". Situation changes for GUI stuff like office applications where I feel more comfortable as "normal" user. KDE is configured for German language and for a lot of those apps I've explicitly set linguas_de in package.use. For libreoffice and calligra I've even added linguas_fr to get French spelling support. For me it is currently very convenient to look simply at the use flags of a package to see which languages will be supported. Gnucash is the only application I had to set environment variables for (using package.env) to get German language support (and it took me a while to find this and get it right). I may have missed other packages that do not use IUSE_EXPAND, simply because I am not aware of the support. Cheers, Jörg
[gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems
How can I select different linguas for individual packages with this approach? Michał Górny wrote: > Hello, everyone. > > Since the previous thread doesn't seem to have brought any good > solution to the problem other than stopping to (ab)use LINGUAS > as USE_EXPAND, I would like to start a RFC on a draft solution that > I'd like afterwards to propose to the Council. > > > Rationale > - > > The direct reason for this is that LINGUAS is treated as non-standard > special variable by multiple build systems. This includes the following > problems: > > 1. no localizations are installed if it is set to an empty value (which > happens in EAPI 5 when the ebuild does not use the flags), > > 2. there were historical cases where order of LINGUAS mattered. > > Those problems can't be reasonably solved within the scope of > USE_EXPAND. Furthermore, the use of flags to control localizations is > causing the following problems: > > a. maintaining correct flag list is a serious maintenance burden, > especially that differences in build systems make it hard to figure out > the 'most correct' set automatically, > > b. missing flags result in localizations being silently dropped, with > no clear way (i.e. for QA check) to detect that, > > c. large number of additional USE flags make it pretty much impossible > to limit localizations this way when using binary packages. > > > The plan > > > 1. Get approval on INSTALL_MASK GLEP [1] and finish implementing it > in Portage. > > 2. Introduce a new USE_EXPAND that can be used to control localizations > whenever this is really required (dependencies, large files, etc.). > Let's use L10N as a draft name for it. > > 3. Fix all packages using LINGUAS as USE_EXPAND, either by converting > to L10N or by removing the needless flags. > > 4. Remove LINGUAS from USE_EXPAND, therefore removing the special EAPI > rules from the variable. > > 5. Release a news item explaining the users the change, > and the necessary action. Request changing LINGUAS to L10N > in make.conf, and make LINGUAS considered an 'advanced variable' for > implicit localization control (i.e. passed through to build systems). > Recommend clean INSTALL_MASK solution instead. > > The example 'new' make.conf would probably look like: > > # controlling e.g. langpacks > L10N="en_US pl" > # stripping unneeded files > INSTALL_MASK="@linguas -@linguas_pl" > > > Your thoughts? > > > [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK >
[gentoo-dev] Re: code.google.com readonly starting on 25/Aug/15
Hi Tobias, Tobias Klausmann wrote: > Hi! > > Tomorrow, code.google.com will turn off write access to all > remaining projects[0]. As such, Gentoo ebuilds which still have > HOMEPAGE= pointing there should be updated. Hmm. Codehaus has also been shut down this year in May, but packages still refer it as their homepage: = %< $ eix -# -H codehaus dev-java/annogen dev-java/bytelist dev-java/groovy dev-java/jaxen dev-java/jcodings dev-java/jettison dev-java/joni dev-java/jruby dev-java/plexus-classworlds dev-java/qdox dev-java/spice-jndikit dev-java/stax dev-java/wstx dev-java/xstream = %< Some new homes I know of: - dev-java/bytelist: https://github.com/jruby/bytelist - dev-java/groovy: http://groovy.apache.org - dev-java/jaxen: https://github.com/jaxen-xpath/jaxen - dev-java/jcodings: https://github.com/jruby/jcodings - dev-java/jettison: https://github.com/jettison-json/jettison - dev-java/jodi: https://github.com/jruby/jodi - dev-java/jruby: http://jruby.org/ - dev-java/plexus-classworlds: http://sonatype.github.io/plexus-classworlds/ - dev-java/qdox: https://github.com/paul-hammant/qdox - dev-java/spice-jndikit: https://github.com/realityforge/jndikit - dev-java/xstx: http://fasterxml.github.io/woodstox/ - dev-java/xstream: http://x-stream.github.io/ The sources of some inactive projects have been simply moved to GitHub: - dev-java/annogen: https://github.com/codehaus/annogen - dev-java/stax: https://github.com/codehaus/stax However, most packages in the tree are outdated. BTW: Rubyforge was shut down a year earlier than Codehaus, some of those packages can be found now also in the jruby organization at GitHub (like bytelist, jodi and jcodings). Cheers, Jörg
[gentoo-dev] Re: Re: Re: Changes in installed ebuilds
Michał Górny wrote: Dnia 2014-06-26, o godz. 00:48:02 Jörg Schaible joerg.schai...@gmx.de napisał(a): hasufell wrote: Kristian Fiskerstrand: On 06/24/2014 09:25 PM, Jörg Schaible wrote: Alexandre Rostovtsev wrote: On Mon, 2014-06-23 at 22:15 +0200, Jörg Schaible wrote: So, why the heck, was the dependency to dev-libs/glib changed for an existing ebuild without increasing its version (e.g. dbus-glib-0.100.2-r2)? Please see http://article.gmane.org/gmane.linux.gentoo.devel/91615 These blocks had nothing to do with the multilibs ABI. It has been just the updated versions for the dependencies. For what it is worth, I completely agree significant changes to stable ebuilds (hereunder changes to dependencies) should get a revision bump and go through normal stabilization procedures. That would be a waste of time and would increase the overall workload on arch teams who already need 2-4 weeks to keep up with the queue. There is no reason to re-stabilize a package after a build-time bug has been fixed by adjusting the version of a dependency. Moreover, the fix that was applied was very important. And, since the official tree did not have an older version of those deps anyway, the upgrade in the stable dependent ebuilds was unnecessary. It just broke the tree for users with local or other overlays. But people could have older versions of those deps installed, and then their systems would slowly become broken on upgrades. Since the issues wouldn't be caught early properly, they would trigger incorrect installs of another packages and a few dep-tree branches further, an unexpected hard-to-debug failures. OK, you have a point. However, it is more dependent on the way people use emerge. This scenario could not have happen to me, I call emerge always with: emerge -uDvta --changed-use --with-bdeps=y Cheers, Jörg
[gentoo-dev] Re: Re: Changes in installed ebuilds
Jan Matejka wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 24 Jun 2014 21:25:40 +0200
Jörg Schaible joerg.schai...@gmx.de wrote:
Alexandre Rostovtsev wrote:
On Mon, 2014-06-23 at 22:15 +0200, Jörg Schaible wrote:
So, why the heck, was the dependency to dev-libs/glib changed for
an existing ebuild without increasing its version (e.g.
dbus-glib-0.100.2-r2)?
Please see http://article.gmane.org/gmane.linux.gentoo.devel/91615
These blocks had nothing to do with the multilibs ABI. It has been
just the updated versions for the dependencies.
I have to use an older Eclipse 3.8.x version for my daily work and
since it is broken with latest gtk versions (a lot of crashes), I
use still some old ebuilds and have masked new ones.
Please file a bug report about this. If nobody tells us that a new
gtk+ version broke something important, we will soon mark the new
version as stable and then remove the old version.
My understanding the problematic change is:
- -CDEPEND==dev-libs/expat-2[${MULTILIB_USEDEP}]
- - =dev-libs/glib-2.26:2[${MULTILIB_USEDEP}]
- - =sys-apps/dbus-1.6.2[${MULTILIB_USEDEP}]
+CDEPEND==dev-libs/expat-2.1.0-r3[${MULTILIB_USEDEP}]
+ =dev-libs/glib-2.38.2-r1:2[${MULTILIB_USEDEP}]
+ =sys-apps/dbus-1.6.18-r1[${MULTILIB_USEDEP}]
given that only micro version was bumped for dbus and while glib
changes minor version, it's the same slot. Therefore my understanding
is the resulting libraries should not break API/ABI and therefore there
shouldn't be an issue.
Except if they're locally hard masked ... ;-)
In that case I think revbump is not warranted since it should continue
to work for existing installation and new installations shouldn't be
any different beside the dependency and not revbumping eliminates some
needless rebuilts.
The point is: Why update silently the dependency versions for a stable
release? Especially in this case, because the now required versions are
the oldest stable ones in the official tree. Therefore anyone with the
official tree would have had those anyway. But such an action may affect
anyone with a local tree or overlays.
And that seems to be the case since you say it's actually problem in
eclipse …
I report anything, if it is worth it. However, in this case the
problem is on Eclipse's side and fixed in newer versions. Alas, it
does not help me, because I have to use that old version for my daily
work. So, there's no blame on Gentoo and nothing the devs should have
to waste their time.
Therefore I still use the once stable versions of GTK (~5 months old
now), where this old version of Eclipse runs, i.e. I already
preserved some older versions locally that are already vanished from
the portage tree. The newer ones are hard masked.
However, if some of my currently installed stable packages suddenly
require newer versions, my portage tree gets in serious trouble.
Nothing would have happen if the revision number of the affected
packages had been simply increased.
I guess you could fork the needed packages (you can always get older
versions from cvs) into your custom overlay for old eclipse and maintain
them there under some slot.
That's what I actually did for all bumped packages in the end. Effort for
nothing.
Caveat Emptor: I'm not particulary experienced with neither API/ABI
changes and slotting so I don't know how accurate this information is.
Cheers,
Jörg
[gentoo-dev] Re: Re: Changes in installed ebuilds
hasufell wrote: Kristian Fiskerstrand: On 06/24/2014 09:25 PM, Jörg Schaible wrote: Alexandre Rostovtsev wrote: On Mon, 2014-06-23 at 22:15 +0200, Jörg Schaible wrote: So, why the heck, was the dependency to dev-libs/glib changed for an existing ebuild without increasing its version (e.g. dbus-glib-0.100.2-r2)? Please see http://article.gmane.org/gmane.linux.gentoo.devel/91615 These blocks had nothing to do with the multilibs ABI. It has been just the updated versions for the dependencies. For what it is worth, I completely agree significant changes to stable ebuilds (hereunder changes to dependencies) should get a revision bump and go through normal stabilization procedures. That would be a waste of time and would increase the overall workload on arch teams who already need 2-4 weeks to keep up with the queue. There is no reason to re-stabilize a package after a build-time bug has been fixed by adjusting the version of a dependency. Moreover, the fix that was applied was very important. And, since the official tree did not have an older version of those deps anyway, the upgrade in the stable dependent ebuilds was unnecessary. It just broke the tree for users with local or other overlays. - Jörg
[gentoo-dev] Re: Re: Changes in installed ebuilds
hasufell wrote: Jörg Schaible: Alexandre Rostovtsev wrote: On Mon, 2014-06-23 at 22:15 +0200, Jörg Schaible wrote: So, why the heck, was the dependency to dev-libs/glib changed for an existing ebuild without increasing its version (e.g. dbus-glib-0.100.2-r2)? Please see http://article.gmane.org/gmane.linux.gentoo.devel/91615 These blocks had nothing to do with the multilibs ABI. It has been just the updated versions for the dependencies. I'm not sure if you understood the bug. It was breaking dependency calculation of portage, so the fallout you see is minor to what was going on. The dependency calculation worked perfectly, it just could not resolve them anymore, because those suddenly required newer packages are hard masked on my system to keep the software *I* need for my daily work running. Revbumping and restabilizing all of these packages (a LOT) would have been unrealistic. And the question was, why was the version for these deps upgraded in those ebuild at all. The official tree did not contain anything older anyway. Another possibility would have been to revbump the ebuild and make it instantly stable without arch teams involvement. That would actually be the cleaner way, but afair some people don't agree with that, so it isn't standard practice. However, you can still overwrite tree ebuilds in your local overlay and revert dependencies. I once did that with pypy, because it triggered too many rebuilds for me. That's what I did in the end for all bumped ebuilds, but the effort would not have been necessary at all. - Jörg
[gentoo-dev] Re: Changes in installed ebuilds
Alexandre Rostovtsev wrote: On Mon, 2014-06-23 at 22:15 +0200, Jörg Schaible wrote: So, why the heck, was the dependency to dev-libs/glib changed for an existing ebuild without increasing its version (e.g. dbus-glib-0.100.2-r2)? Please see http://article.gmane.org/gmane.linux.gentoo.devel/91615 These blocks had nothing to do with the multilibs ABI. It has been just the updated versions for the dependencies. I have to use an older Eclipse 3.8.x version for my daily work and since it is broken with latest gtk versions (a lot of crashes), I use still some old ebuilds and have masked new ones. Please file a bug report about this. If nobody tells us that a new gtk+ version broke something important, we will soon mark the new version as stable and then remove the old version. I report anything, if it is worth it. However, in this case the problem is on Eclipse's side and fixed in newer versions. Alas, it does not help me, because I have to use that old version for my daily work. So, there's no blame on Gentoo and nothing the devs should have to waste their time. Therefore I still use the once stable versions of GTK (~5 months old now), where this old version of Eclipse runs, i.e. I already preserved some older versions locally that are already vanished from the portage tree. The newer ones are hard masked. However, if some of my currently installed stable packages suddenly require newer versions, my portage tree gets in serious trouble. Nothing would have happen if the revision number of the affected packages had been simply increased. Cheers, Jörg
[gentoo-dev] Changes in installed ebuilds
Hi,
can somebody tell my, since when existing (and installed) ebuilds suddenly
change without at least increasing the version number?
Today's synchronization got me suddenly dependency conflicts for installed
packages:
% =
!!! All ebuilds that could satisfy =dev-libs/glib-2.38.2-
r1:2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
have been masked.
!!! One of the following masked packages is required to complete your
request:
- dev-libs/glib-2.40.0-r1::gentoo (masked by: ~amd64 keyword)
- dev-libs/glib-2.38.2-r1::gentoo (masked by: package.mask)
(dependency required by dev-libs/dbus-glib-0.100.2-r1 [installed])
(dependency required by sys-auth/consolekit-0.4.6 [installed])
(dependency required by sys-auth/polkit-0.112-r1[-systemd] [installed])
(dependency required by sys-fs/udisks-2.1.2 [installed])
(dependency required by kde-base/kdelibs-4.12.5-r1[udisks] [ebuild])
(dependency required by kde-base/nepomuk-widgets-4.12.5 [installed])
% =
Diffing the ebuilds for dbus-glib:
% =
~ $ locate dbus-glib-0.100.2-r1.ebuild
/var/db/pkg/dev-libs/dbus-glib-0.100.2-r1/dbus-glib-0.100.2-r1.ebuild
/var/db/portage/central/dev-libs/dbus-glib/dbus-glib-0.100.2-r1.ebuild
~ $ diff -u `locate dbus-glib-0.100.2-r1.ebuild`
--- /var/db/pkg/dev-libs/dbus-glib-0.100.2-r1/dbus-glib-0.100.2-r1.ebuild
2014-02-24 09:01:29.779074662 +0100
+++ /var/db/portage/central/dev-libs/dbus-glib/dbus-glib-0.100.2-r1.ebuild
2014-06-18 21:31:11.0 +0200
@@ -1,6 +1,6 @@
# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/dev-libs/dbus-glib/dbus-glib-0.100.2-
r1.ebuild,v 1.7 2014/02/23 16:17:58 pacho Exp $
+# $Header: /var/cvsroot/gentoo-x86/dev-libs/dbus-glib/dbus-glib-0.100.2-
r1.ebuild,v 1.11 2014/06/18 19:09:23 mgorny Exp $
EAPI=5
inherit bash-completion-r1 eutils multilib-minimal
@@ -11,18 +11,18 @@
LICENSE=|| ( GPL-2 AFL-2.1 )
SLOT=0
-KEYWORDS=~alpha amd64 arm hppa ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc x86
~amd64-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~arm-linux ~x86-linux ~ppc-
macos ~x86-macos ~m68k-mint ~sparc-solaris ~x86-solaris
+KEYWORDS=alpha amd64 arm hppa ia64 ~mips ppc ppc64 ~s390 ~sh sparc x86
~amd64-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~arm-linux ~x86-linux ~ppc-
macos ~x86-macos ~m68k-mint ~sparc-solaris ~x86-solaris
IUSE=debug doc static-libs test
-CDEPEND==dev-libs/expat-2[${MULTILIB_USEDEP}]
- =dev-libs/glib-2.26:2[${MULTILIB_USEDEP}]
- =sys-apps/dbus-1.6.2[${MULTILIB_USEDEP}]
+CDEPEND==dev-libs/expat-2.1.0-r3[${MULTILIB_USEDEP}]
+ =dev-libs/glib-2.38.2-r1:2[${MULTILIB_USEDEP}]
+ =sys-apps/dbus-1.6.18-r1[${MULTILIB_USEDEP}]
DEPEND=${CDEPEND}
virtual/pkgconfig
doc? ( =dev-util/gtk-doc-1.4 )
RDEPEND=${CDEPEND}
-abi_x86_32? (
- !app-emulation/emul-linux-x86-baselibs-20131008-r8
+ abi_x86_32? (
+ !app-emulation/emul-linux-x86-baselibs-20131008-r8
!app-emulation/emul-linux-x86-baselibs[-abi_x86_32(-)]
)
@@ -49,7 +49,7 @@
$(use_enable debug verbose-mode)
$(use_enable debug asserts)
$(use_enable static-libs static)
- $(multilib_build_binaries use_enable doc gtk-doc || echo
--disable-gtk-doc)
+ $(multilib_native_use_enable doc gtk-doc)
)
ECONF_SOURCE=${S} econf ${myconf[@]}
% =
So, why the heck, was the dependency to dev-libs/glib changed for an
existing ebuild without increasing its version (e.g. dbus-glib-0.100.2-r2)?
Who can really say, that dbus-glib still works properly without having been
compiled against those new versions of expat, glib and dbus? Sorry, but this
is simply bad practice.
I have to use an older Eclipse 3.8.x version for my daily work and since it
is broken with latest gtk versions (a lot of crashes), I use still some old
ebuilds and have masked new ones. However, if the dependencies of installed
ebuilds suddenly change, this simply breaks my portage tree.
- Jörg
[gentoo-dev] Re: RANT: Upgrade icu and KDE at once
Hi Zac,
Zac Medico wrote:
On Tue, Apr 30, 2013 at 9:51 AM, Jörg Schaible joerg.schai...@gmx.de
wrote:
The most annoying fact is, that none of this would have been necessary
with portage 2.2, but maybe we have to wait for 2.1.11.500 before 2.2
gets stable...
Since portage-2.1.11.20 [1], you can do this:
echo 'FEATURES=${FEATURES} preserve-libs' /etc/portage/make.conf
[1]
[http://blogs.gentoo.org/zmedico/2012/09/21/preserve-libs-available-in-portage-2-1/
That announcement slipped somehow my awareness. Indeed an upgrade of a
different machine with preserve-libs added to FEATURES went fine. Still, I
wonder what prevents portage-2.2 form going stable, I have one machine where
I use that one for years without any flaws and a lot of benefits.
- Jörg
[gentoo-dev] Re: New category for (libre)office extensions: app-officeext
Andreas K. Huettel wrote: Am Dienstag 08 Mai 2012, 12:30:04 schrieb Andreas K. Huettel: After some discussion with Ulrich on IRC, we settled on the name app-officeext, which we'll be able to fill with a couple of hundred (open|libre)office extensions then... :) I guess this is a compromise that we all can live with. So, I'll implement that tonight. And committed. There's already a first package in there, app-officeext/texmaths - a LaTeX replacement for the LO formula editor, generating embedded svg. Give it a try, it's really cool! There's also app-office/ooextras since a long time. - Jörg
[gentoo-dev] Re: [rfc] layman storage location (again)
dev-ran...@mail.ru wrote:
On Sat, Jan 16, 2010 at 01:57:38PM +0100, Ben de Groot wrote:
2010/1/16 Peter Volkov p...@gentoo.org:
layman cache is nfs distributable. Also it's good idea to have it close
to PORTDIR. Thus I'd like to keep it somewhere at /usr.
I'd like both to be under /var/
I _use_ both under /var/. In my config PORTDIR_OVERLAY=/var/repos/{many
directories} and PORTDIR=/var/repos/gentoo. /usr/ is too crazy place
for ebuilds. IMHO.
Same for me. I have PORTDIR also beneath /var ...
- Jörg
