Re: [gentoo-dev] News item: m68k, s390, and sh are dropping stable keywords
And committed. --- Title: m68k, s390, sh are dropping stable keywords Author: Andreas K. Huettel dilfri...@gentoo.org Content-Type: text/plain Posted: 2013-09-22 Revision: 1 News-Item-Format: 1.0 Display-If-Keyword: m68k Display-If-Keyword: s390 Display-If-Keyword: sh Following discussion [1] and a vote by the Gentoo Council [2,3], m68k, s390, and sh will drop all stable keywords and become unstable/testing only arches. The main reason for this is that these arch teams visibly lack manpower, resulting in undesirable delays. In a week, the ACCEPT_KEYWORDS variable in the respective profiles will be switched to automatically include ~arch packages. Systems running stable before will update to current unstable/testing then. Afterwards m68k, s390, and sh keywords on all ebuilds will be changed to ~m68k, ~s390, and ~sh. No steps are required from users, however you should be aware of the upcoming changes. [1] http://thread.gmane.org/gmane.linux.gentoo.project/2975/focus=2984 [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917.txt [3] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt Am Donnerstag, 19. September 2013, 21:29:35 schrieb Andreas K. Huettel: For general review and improvement, to be committed 2013-09-25... [The summary link [3] will work soon... :) ] -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/emelfm2: emelfm2-0.9.0.ebuild metadata.xml ChangeLog
On 22/09/13 17:42, Jeroen Roovers (jer) wrote:
jer 13/09/22 14:42:31
Modified: metadata.xml ChangeLog
Added:emelfm2-0.9.0.ebuild
Log:
Version bump (bug #485616 by teidakankan).
(Portage version: 2.2.6/cvs/Linux x86_64, signed Manifest commit with key
A792A613)
Revision ChangesPath
1.11 app-misc/emelfm2/metadata.xml
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-misc/emelfm2/metadata.xml?rev=1.11view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-misc/emelfm2/metadata.xml?rev=1.11content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-misc/emelfm2/metadata.xml?r1=1.10r2=1.11
Index: metadata.xml
===
RCS file: /var/cvsroot/gentoo-x86/app-misc/emelfm2/metadata.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- metadata.xml22 Jan 2013 17:07:51 - 1.10
+++ metadata.xml22 Sep 2013 14:42:31 - 1.11
@@ -3,4 +3,5 @@
pkgmetadata
herddesktop-misc/herd
useflag name='ansi'Add support for ANSI escape sequences/flag/use
+ useflag name='gtk3'Use pkgx11-libs/gtk:3/pkg instead of
pkgx11-libs/gtk:2/pkg/flag/use
/pkgmetadata
1.55 app-misc/emelfm2/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-misc/emelfm2/ChangeLog?rev=1.55view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-misc/emelfm2/ChangeLog?rev=1.55content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-misc/emelfm2/ChangeLog?r1=1.54r2=1.55
Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/app-misc/emelfm2/ChangeLog,v
retrieving revision 1.54
retrieving revision 1.55
diff -u -r1.54 -r1.55
--- ChangeLog 25 Jan 2013 15:25:30 - 1.54
+++ ChangeLog 22 Sep 2013 14:42:31 - 1.55
@@ -1,6 +1,12 @@
# ChangeLog for app-misc/emelfm2
# Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/app-misc/emelfm2/ChangeLog,v 1.54
2013/01/25 15:25:30 jer Exp $
+# $Header: /var/cvsroot/gentoo-x86/app-misc/emelfm2/ChangeLog,v 1.55
2013/09/22 14:42:31 jer Exp $
+
+*emelfm2-0.9.0 (22 Sep 2013)
+
+ 22 Sep 2013; Jeroen Roovers j...@gentoo.org +emelfm2-0.9.0.ebuild,
+ metadata.xml:
+ Version bump (bug #485616 by teidakankan).
25 Jan 2013; Jeroen Roovers j...@gentoo.org -emelfm2-0.7.5.ebuild,
-emelfm2-0.8.0.ebuild:
1.1 app-misc/emelfm2/emelfm2-0.9.0.ebuild
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-misc/emelfm2/emelfm2-0.9.0.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-misc/emelfm2/emelfm2-0.9.0.ebuild?rev=1.1content-type=text/plain
Index: emelfm2-0.9.0.ebuild
===
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/app-misc/emelfm2/emelfm2-0.9.0.ebuild,v 1.1
2013/09/22 14:42:31 jer Exp $
EAPI=5
inherit eutils multilib toolchain-funcs
DESCRIPTION=A file manager that implements the popular two-pane design
HOMEPAGE=http://emelfm2.net/;
SRC_URI=http://emelfm2.net/rel/${P}.tar.bz2;
LICENSE=GPL-3 LGPL-3
SLOT=0
KEYWORDS=~amd64 ~ppc ~ppc64 ~sparc ~x86
IUSE=acl ansi fam gimp gtk3 kernel_linux nls policykit spell udev
IUSE has 'fam' but it's not used anywhere in the ebuild.
Re: [gentoo-dev] Re: sys-kernel/tuxonice-sources up for grabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/09/13 08:21 PM, Rick Zero_Chaos Farina wrote: On 09/21/2013 08:44 AM, Pacho Ramos wrote: El sáb, 21-09-2013 a las 14:42 +0200, Pacho Ramos escribió: I don't have time for it for a long time (since I switched to official suspend time ago and moved back to gentoo-sources then), updated patches are periodically generated and put at: http://tuxonice.nigelcunningham.com.au/downloads/all/?C=MO=D Feel free to get it if you want It goes with tuxonice-userui Is any of this really needed anymore? I suspend/hibernate/resume with gentoo-sources and hardened-sources Does it really make sense to hold on to tuxonice still? -Zero Admittedly I haven't looked into this, but I believe tuxonice-sources is still required if you wish to use a hibernation file rather than a swap partition. There are numerous other features to, iirc, that users may want that the kernel just doesn't offer. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlI/h98ACgkQ2ugaI38ACPC1nAEAgxS6SfDNmXU3NGa1LDDaMWFy rDIfmwyddZZa7sv2KsAA/2AYzvEBZMAuzlNCvxw33PKMLfN5V/GMivmNuHcnC49i =dya3 -END PGP SIGNATURE-
[gentoo-dev] does v8 shared library make sense with current upstream approach?
I'd like to get your feedback and opinion about removing shared v8 library package from Gentoo. It's currently used by www-client/chromium, dev-db/drizzle, dev-db/mongodb, dev-lang/v8cgi and sci-geosciences/osgearth. net-libs/nodejs switched back to bundled v8 a long time ago: 25 Feb 2013; Patrick Lauer +nodejs-0.6.21-r2.ebuild, +nodejs-0.8.20.ebuild: Version bump for 0.6 and 0.8 that also disables shared v8 as our v8 maintainers remove all compatible versions Some bugs for reference: https://bugs.gentoo.org/show_bug.cgi?id=417879 https://bugs.gentoo.org/show_bug.cgi?id=420995 https://bugs.gentoo.org/show_bug.cgi?id=471582 https://bugs.gentoo.org/show_bug.cgi?id=477300 https://bugs.gentoo.org/show_bug.cgi?id=484786 From mongodb upstream https://jira.mongodb.org/browse/SERVER-10282 : compiling with versions of v8 other than what is included is not currently supported. I'd like maintainers of all packages depending on dev-lang/v8 to make their packages use bundled v8 copy instead (I can file bugs for that, let's discuss here whether it should be done). For now V8 upstream gives no guarantees about API/ABI stability and actually breaks it very often (http://upstream-tracker.org/versions/v8.html). Having a shared library so closely tied to packages (which results in frustrating blockers, since v8 is updated often and chromium is synchronized with that) is not really much different from everyone bundling the library. I'd like that to improve, but for now it's time for a pragmatic solution to this IMHO. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/09/13 08:17 PM, Paweł Hajdan, Jr. wrote: I'd like to get your feedback and opinion about removing shared v8 library package from Gentoo. It's currently used by www-client/chromium, dev-db/drizzle, dev-db/mongodb, dev-lang/v8cgi and sci-geosciences/osgearth. net-libs/nodejs switched back to bundled v8 a long time ago: 25 Feb 2013; Patrick Lauer +nodejs-0.6.21-r2.ebuild, +nodejs-0.8.20.ebuild: Version bump for 0.6 and 0.8 that also disables shared v8 as our v8 maintainers remove all compatible versions Some bugs for reference: https://bugs.gentoo.org/show_bug.cgi?id=417879 https://bugs.gentoo.org/show_bug.cgi?id=420995 https://bugs.gentoo.org/show_bug.cgi?id=471582 https://bugs.gentoo.org/show_bug.cgi?id=477300 https://bugs.gentoo.org/show_bug.cgi?id=484786 From mongodb upstream https://jira.mongodb.org/browse/SERVER-10282 : compiling with versions of v8 other than what is included is not currently supported. I'd like maintainers of all packages depending on dev-lang/v8 to make their packages use bundled v8 copy instead (I can file bugs for that, let's discuss here whether it should be done). For now V8 upstream gives no guarantees about API/ABI stability and actually breaks it very often (http://upstream-tracker.org/versions/v8.html). Having a shared library so closely tied to packages (which results in frustrating blockers, since v8 is updated often and chromium is synchronized with that) is not really much different from everyone bundling the library. I'd like that to improve, but for now it's time for a pragmatic solution to this IMHO. Paweł FYI - Spidermonkey is in the exact same situation -- upstream develops with the expectation that projects will embed the code or at best bundle the lib. They also completely break API with every major version bump (ie, every 6 weeks). Fortunately they accepted patches that support installing multiple versions concurrently, and so I've started slotting it in the tree. IMO, just like spidermonkey, yes we should still try and keep libs as system-installed rather than bundling. Just because upstream doesn't think it's the right idea and doesn't support it, doesn't mean we shouldn't continue to push for this paradigm. That said, I don't know anything about v8 and if it would be feasible to slot it, and ultimately, it's going to be up to the dev's maintaining both v8 and its rdeps, since they're the ones that need to do the work... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlI/iikACgkQ2ugaI38ACPAQcQD+PicDLQX4e2TsZv5wuAKlVKGW rjNhGjeE4Eet/So9xqQBAJzDUp5AeiZqmRpzCxzQoi5OOorYfRnTZMDU9elgcDVP =CfAi -END PGP SIGNATURE-
Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?
Paweł Hajdan, Jr. wrote: compiling with versions of v8 other than what is included is not currently supported. .. For now V8 upstream gives no guarantees about API/ABI stability and actually breaks it very often I agree that it isn't worth the effort to try to offer V8 as a library then. As soon as upstream stabilizes one API/ABI I think it would be wise to make a package providing that as a library. Not everybody understands it but actually it isn't a library if there isn't a stable API/ABI. //Peter pgpWQp9tOUeo4.pgp Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-09-22 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-09-22 23h59 UTC. Removals: dev-ruby/programming-ruby 2013-09-20 00:38:52 mrueg net-im/kf 2013-09-20 00:41:18 mrueg Additions: app-emacs/scim-bridge-el2013-09-16 11:55:41 heroxbd dev-java/piccolo2013-09-17 15:19:54 tomwij dev-java/annogen2013-09-17 16:13:20 tomwij dev-haskell/hslua 2013-09-17 16:58:08 qnikst dev-haskell/stringable 2013-09-17 17:11:49 qnikst dev-python/testresources2013-09-17 17:16:44 prometheanfire dev-python/testscenarios2013-09-17 17:44:54 prometheanfire dev-python/testrepository 2013-09-17 19:06:54 prometheanfire dev-perl/IO-Pipely 2013-09-18 05:52:28 patrick app-arch/zopfli 2013-09-18 20:43:23 tomwij sys-block/arcconf 2013-09-19 13:35:20 dev-zero net-analyzer/zmap 2013-09-20 16:02:31 jlec dev-php/pecl-event 2013-09-22 09:40:17 hwoarang dev-php/pecl-eio2013-09-22 10:13:13 hwoarang app-emulation/cloud-init2013-09-22 19:11:45 prometheanfire -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-ruby/programming-ruby,removed,mrueg,2013-09-20 00:38:52 net-im/kf,removed,mrueg,2013-09-20 00:41:18 Added Packages: app-emacs/scim-bridge-el,added,heroxbd,2013-09-16 11:55:41 dev-java/piccolo,added,tomwij,2013-09-17 15:19:54 dev-java/annogen,added,tomwij,2013-09-17 16:13:20 dev-haskell/hslua,added,qnikst,2013-09-17 16:58:08 dev-haskell/stringable,added,qnikst,2013-09-17 17:11:49 dev-python/testresources,added,prometheanfire,2013-09-17 17:16:44 dev-python/testscenarios,added,prometheanfire,2013-09-17 17:44:54 dev-python/testrepository,added,prometheanfire,2013-09-17 19:06:54 dev-perl/IO-Pipely,added,patrick,2013-09-18 05:52:28 app-arch/zopfli,added,tomwij,2013-09-18 20:43:23 sys-block/arcconf,added,dev-zero,2013-09-19 13:35:20 net-analyzer/zmap,added,jlec,2013-09-20 16:02:31 dev-php/pecl-event,added,hwoarang,2013-09-22 09:40:17 dev-php/pecl-eio,added,hwoarang,2013-09-22 10:13:13 app-emulation/cloud-init,added,prometheanfire,2013-09-22 19:11:45 Done.
Re: [gentoo-dev] News item: m68k, s390, and sh are dropping stable keywords
On Sun, Sep 22, 2013 at 10:38:57AM +0200, Andreas K. Huettel wrote: And committed. --- Title: m68k, s390, sh are dropping stable keywords Author: Andreas K. Huettel dilfri...@gentoo.org Content-Type: text/plain Posted: 2013-09-22 Revision: 1 News-Item-Format: 1.0 Display-If-Keyword: m68k Display-If-Keyword: s390 Display-If-Keyword: sh Following discussion [1] and a vote by the Gentoo Council [2,3], m68k, s390, and sh will drop all stable keywords and become unstable/testing only arches. The main reason for this is that these arch teams visibly lack manpower, resulting in undesirable delays. Please remove the word unstable as there are no unstable keywords in Gentoo Linux, just stable and testing. In a week, the ACCEPT_KEYWORDS variable in the respective profiles will be switched to automatically include ~arch packages. Systems running stable before will update to current unstable/testing then. Afterwards m68k, s390, and sh keywords on all ebuilds will be changed to ~m68k, ~s390, and ~sh. No steps are required from users, however you should be aware of the upcoming changes. [1] http://thread.gmane.org/gmane.linux.gentoo.project/2975/focus=2984 [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917.txt [3] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt Am Donnerstag, 19. September 2013, 21:29:35 schrieb Andreas K. Huettel: For general review and improvement, to be committed 2013-09-25... [The summary link [3] will work soon... :) ] Thanks, -- Jack Morgan Pub 4096R/761D8E0A 2010-09-13 Jack Morgan jmor...@gentoo.org Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A signature.asc Description: Digital signature
[gentoo-dev] unstable/testing keywords
I find this confusing and hope to clear it up. According to emerge/portage man pages we have stable keywords (ARCH) and unstable packages (~ARCH) while the handbook[1] says we have stable keywords (ARCH) and testing keywords (~ARCH). I think the handbook is more accurate: The testing branch is exactly what it says - Testing. If a package is in testing, it means that the developers feel that it is functional but has not been thoroughly tested. You could very well be the first to discover a bug in the package in which case you could file a bugreport to let the developers know about it. [1] http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3chap=3 Thanks, -- Jack Morgan Pub 4096R/761D8E0A 2010-09-13 Jack Morgan jmor...@gentoo.org Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A signature.asc Description: Digital signature
Re: [gentoo-dev] News item: GRUB2 migration
On 9/21/13 1:19 PM, Mike Gilbert wrote: I wasn't able to reproduce this in qemu. It is possible that GRUB's graphical terminal driver has some issues with VMWare. However, have a Gentoo box at work that runs GRUB2 on VMWare ESX, and I don't recall having any display issues on the console. But I'm also not chainloading it there. Thanks for testing this. I've tried without chainloading and it was also broken. However, I got it to work later, and there are at least two solutions: 1. In /etc/default/grub, uncomment GRUB_TERMINAL=console line and re-run grub2-mkconfig. 2. In /etc/default/grub, add GRUB_GFXPAYLOAD_LINUX=text line and re-run grub2-mkconfig. Actually Arch wiki article mentions something very similar: https://wiki.archlinux.org/index.php/GRUB2#Disable_framebuffer Also, it seems worth it to add to the guide info about how to roll back just in case. Running grub-install /dev/sda works just fine (it invokes grub legacy as opposed to grub2). Then, looking at Arch wiki article, it's probably a good idea to make backup: https://wiki.archlinux.org/index.php/GRUB2#Backup_important_data . I recommend adding this to our guide. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: sys-kernel/tuxonice-sources up for grabs
On 23 September 2013 08:14, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/09/13 08:21 PM, Rick Zero_Chaos Farina wrote: On 09/21/2013 08:44 AM, Pacho Ramos wrote: El sáb, 21-09-2013 a las 14:42 +0200, Pacho Ramos escribió: I don't have time for it for a long time (since I switched to official suspend time ago and moved back to gentoo-sources then), updated patches are periodically generated and put at: http://tuxonice.nigelcunningham.com.au/downloads/all/?C=MO=D Feel free to get it if you want It goes with tuxonice-userui Is any of this really needed anymore? I suspend/hibernate/resume with gentoo-sources and hardened-sources Does it really make sense to hold on to tuxonice still? -Zero Admittedly I haven't looked into this, but I believe tuxonice-sources is still required if you wish to use a hibernation file rather than a swap partition. There are numerous other features to, iirc, that users may want that the kernel just doesn't offer. Tux-on-ice patches are also included in pf-sources, so those who want it can get it that way. Then we may not need to maintain separate tuxonice-sources. -- Cheers, Ben | yngwin Gentoo developer
