Re: [gentoo-dev] Re: The state and future of the OpenRC project
Michael Palimaka kensing...@gentoo.org writes: Perhaps we could consider GitLab? +1 on that. I have deployed it recently at work and it seems to perform well. *Really* easy to use. Easy to deploy as well. It's written in Ruby, *not Java*. It's possible to have a basic integartion with external issue trackers. It also has an LDAP auth. +1 on docs. We should focus on forcing people who were involved into OpenRC to document what they know. I could do some contributions to OpenRC, but I don't have time for reverse engineering. I have developed some experimental Plytmouth plugin to OpenRC, but it was really time consuming to guess what does what... We cannot let OpenRC die. It cannot happen that systemd and upstart are the only init systems. -- Amadeusz Żołnowski pgpQ46M0fXYSk.pgp Description: PGP signature
Re: [gentoo-dev] Re: The state and future of the OpenRC project
On Mon, Jun 9, 2014 at 4:57 AM, Amadeusz Żołnowski aide...@gentoo.org wrote: We should focus on forcing people who were involved into OpenRC to document what they know. Uh, you can't force anybody to do anything, and most of them are no longer around. You can always encourage or ask nicely. You can also set a policy of no further commits accepted without accompanying documentation, but that could just as easily result in fewer commits and not more documentation. And this is why half of FOSS isn't well-documented. Often the docs aren't written by the same people who wrote the code. Rich
Re: [gentoo-dev] Re: The state and future of the OpenRC project
Rich Freeman ri...@gentoo.org writes: Uh, you can't force anybody to do anything, and most of them are no longer around. You can always encourage or ask nicely. Yes, I meant that: forcing by asking nicely. :-) You can also set a policy of no further commits accepted without accompanying documentation, but that could just as easily result in fewer commits and not more documentation. Yup, that's right, unfortunately. -- Amadeusz Żołnowski pgpkHcxq9buzj.pgp Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
08.06.2014 16:25, Fabio Erculiani пишет: Due to permanent lack of time, I'm unable to properly maintain the packages below. Feel free to take them over. I'll remove myself from metadata.xml in 14 days. app-admin/389-admin-console app-admin/389-console app-admin/389-ds-console app-admin/aws-as-tools app-admin/aws-elb-tools app-admin/aws-iam-tools app-admin/aws-rds-tools app-emulation/edumips64 dev-java/idm-console-framework dev-libs/389-adminutil dev-libs/mozldap dev-libs/svrcore dev-perl/perl-mozldap net-nds/389-admin net-nds/389-ds-base net-libs/libgrss www-apache/mod_nss www-apps/389-dsgw x11-apps/ardesia x11-apps/spotlighter x11-apps/python-whiteboard x11-apps/whyteboard x11-drivers/cwiid dev-perl/perl-mozldap perl herd will take care.
Re: [gentoo-dev] Packages up for grabs
On Mon, 09 Jun 2014 21:34:06 +0400 Mikle Kolyada zlog...@gentoo.org wrote: app-admin/389-admin-console app-admin/389-console app-admin/389-ds-console app-admin/aws-as-tools app-admin/aws-elb-tools app-admin/aws-iam-tools app-admin/aws-rds-tools app-emulation/edumips64 dev-java/idm-console-framework dev-libs/389-adminutil dev-libs/mozldap dev-libs/svrcore dev-perl/perl-mozldap net-nds/389-admin net-nds/389-ds-base net-libs/libgrss www-apache/mod_nss www-apps/389-dsgw x11-apps/ardesia x11-apps/spotlighter x11-apps/python-whiteboard x11-apps/whyteboard x11-drivers/cwiid dev-perl/perl-mozldap perl herd will take care. It looks like you mean perl@ will take care of all of them. jer
Re: [gentoo-dev] Packages up for grabs
09.06.2014 21:47, Jeroen Roovers пишет: On Mon, 09 Jun 2014 21:34:06 +0400 Mikle Kolyada zlog...@gentoo.org wrote: app-admin/389-admin-console app-admin/389-console app-admin/389-ds-console app-admin/aws-as-tools app-admin/aws-elb-tools app-admin/aws-iam-tools app-admin/aws-rds-tools app-emulation/edumips64 dev-java/idm-console-framework dev-libs/389-adminutil dev-libs/mozldap dev-libs/svrcore dev-perl/perl-mozldap net-nds/389-admin net-nds/389-ds-base net-libs/libgrss www-apache/mod_nss www-apps/389-dsgw x11-apps/ardesia x11-apps/spotlighter x11-apps/python-whiteboard x11-apps/whyteboard x11-drivers/cwiid dev-perl/perl-mozldap perl herd will take care. It looks like you mean perl@ will take care of all of them. jer no, only dev-perl/perl-mozldap. I just use wrong quotes:/
Re: [gentoo-dev] The state and future of the OpenRC project
On 08/06/14 18:06, hasufell wrote: I am not sure if that is a joke. You can pretty much ask most major gentoo projects. The ones where I was involved more deeply definitely suffer from that problem, including sunrise and games team. Science team gave up importing major ebuilds to the tree and just let users manage them on github, because that workflow sucks less. I disagree with that point. If you are referring to sage (or other larger science projects), then they stay in the overlay because people feel it is not worth the effort to fix the QA issues which in turn would be necessary before moving them to the main tree. From what I can tell it has nothing to do with bugzilla vs. github. For me personally bugzilla + a git tree (which is the situation we have for overlays anyway) is fine. Cheers, Thomas -- Thomas Kahle http://dev.gentoo.org/~tomka/ signature.asc Description: OpenPGP digital signature
[gentoo-dev] New eclass: gstreamer.eclass (replacement for gst-plugins*.eclass)
Hello,
For some time I've been working on bringing multilib gstreamer
into the tree. Following recent review by gstreamer team, I would like
to submit the new eclass for a wider opinion.
The gstreamer.eclass intends to replace all of gst-plugins* eclasses.
It provides routines suitable for building 'base' packages of
gst-plugins-{base,good,bad,ugly} sets and plugins split out of them. It
is built on top of multilib-minimal to provide complete multilib
support, and provides reusable multilib sub-phases
(gstreamer_multilib_src_configure etc.).
I've also tried to fix some of the uglyness, and removed some
deprecated/unused functions from gst-plugins10.eclass. And replaced
the four split eclasses that set GST_ORG_MODULE and inherited
gst-plugins10 with explicit GST_ORG_MODULE assignments.
In case anyone would like to see some ebuilds using the eclass, they
are available in gst-multilib-r2 branch of my working tree:
https://bitbucket.org/mgorny/gx86-working-tree/src/gst-multilib-r2/media-plugins/?at=gst-multilib-r2
--
Best regards,
Michał Górny
# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/gst-plugins10.eclass,v 1.12
2014/04/05 09:19:19 tetromino Exp $
# @ECLASS: gstreamer.eclass
# @MAINTAINER:
# gstrea...@gentoo.org
# @AUTHOR:
# MichaŠGórny mgo...@gentoo.org
# Gilles Dartiguelongue e...@gentoo.org
# Saleem Abdulrasool compn...@gentoo.org
# foser fo...@gentoo.org
# zaheerm zahe...@gentoo.org
# @BLURB: Helps building core split gstreamer plugins.
# @DESCRIPTION:
# Eclass to make external gst-plugins emergable on a per-plugin basis
# and to solve the problem with gst-plugins generating far too much
# unneeded dependencies.
#
# GStreamer consuming applications should depend on the specific plugins
# they need as defined in their source code. Usually you can find that
# out by grepping the source tree for 'factory_make'. If it uses playbin
# plugin, consider adding media-plugins/gst-plugins-meta dependency, but
# also list any packages that provide explicitly requested plugins.
inherit eutils multilib multilib-minimal toolchain-funcs versionator
case ${EAPI:-0} in
5)
;;
0|1|2|3|4)
die EAPI=\${EAPI:-0}\ is not supported anymore
;;
*)
die EAPI=\${EAPI}\ is not supported yet
;;
esac
# @ECLASS-VARIABLE: GST_PLUGINS_BUILD
# @DESCRIPTION:
# Defines the plugins to be built.
# May be set by an ebuild and contain more than one indentifier, space
# seperated (only src_configure can handle mutiple plugins at this time).
: ${GST_PLUGINS_BUILD:=${PN/gst-plugins-/}}
# @ECLASS-VARIABLE: GST_PLUGINS_BUILD_DIR
# @DESCRIPTION:
# Actual build directory of the plugin.
# Most often the same as the configure switch name.
: ${GST_PLUGINS_BUILD_DIR:=${PN/gst-plugins-/}}
# @ECLASS-VARIABLE: GST_TARBALL_SUFFIX
# @DESCRIPTION:
# Most projects hosted on gstreamer.freedesktop.org mirrors provide
# tarballs as tar.bz2 or tar.xz. This eclass defaults to xz. This is
# because the gstreamer mirrors are moving to only have xz tarballs for
# new releases.
: ${GST_TARBALL_SUFFIX:=xz}
# Even though xz-utils are in @system, they must still be added to DEPEND; see
# http://archives.gentoo.org/gentoo-dev/msg_a0d4833eb314d1be5d5802a3b710e0a4.xml
if [[ ${GST_TARBALL_SUFFIX} == xz ]]; then
DEPEND=${DEPEND} app-arch/xz-utils
fi
# @ECLASS-VARIABLE: GST_ORG_MODULE
# @DESCRIPTION:
# Name of the module as hosted on gstreamer.freedesktop.org mirrors.
# Leave unset if package name matches module name.
: ${GST_ORG_MODULE:=$PN}
# @ECLASS-VARIABLE: GST_ORG_PVP
# @INTERNAL
# @DESCRIPTION:
# Major and minor numbers of the version number.
: ${GST_ORG_PVP:=$(get_version_component_range 1-2)}
DESCRIPTION=${BUILD_GST_PLUGINS} plugin for gstreamer
HOMEPAGE=http://gstreamer.freedesktop.org/;
SRC_URI=http://gstreamer.freedesktop.org/src/${GST_ORG_MODULE}/${GST_ORG_MODULE}-${PV}.tar.${GST_TARBALL_SUFFIX};
LICENSE=GPL-2
case ${GST_ORG_PVP} in
0.10) SLOT=0.10 ;;
1.*) SLOT=1.0 ;;
*) die Unkown gstreamer release.
esac
S=${WORKDIR}/${GST_ORG_MODULE}-${PV}
RDEPEND=
dev-libs/glib:2[${MULTILIB_USEDEP}]
media-libs/gstreamer:${SLOT}[${MULTILIB_USEDEP}]
DEPEND=
=sys-apps/sed-4
virtual/pkgconfig[${MULTILIB_USEDEP}]
# Export common multilib phases.
multilib_src_configure() { gstreamer_multilib_src_configure; }
if [[ ${PN} != ${GST_ORG_MODULE} ]]; then
# Do not run test phase for invididual plugin ebuilds.
RESTRICT=test
RDEPEND=${RDEPEND}
=media-libs/${GST_ORG_MODULE}-${PV}:${SLOT}[${MULTILIB_USEDEP}]
# Export multilib phases used for split builds.
multilib_src_compile() { gstreamer_multilib_src_compile; }
multilib_src_install() { gstreamer_multilib_src_install; }
multilib_src_install_all() {
Re: [gentoo-dev] The state and future of the OpenRC project
Thomas Kahle: then they stay in the overlay because people feel it is not worth the effort to fix the QA issues which in turn would be necessary before moving them to the main tree. Probably because no one mentored them on how to fix these QA issues. Otherwise... if that's attitude, then that's just sad and has to be fixed by those who run that overlay (review, contribution guidelines). And I still think that the top 1 reason people run an overlay is because it's easier than contributing directly. A lot of overlay maintainers I tried to convince on getting more involved even said that. Even sunrise workflow has proven too slow and cumbersome... look at the commit history, it's constantly decreasing. Sure, reasons may vary, but there is not much positive to say about current gentoo workflow.
Re: [gentoo-dev] The state and future of the OpenRC project
On Mon, 09 Jun 2014 21:45:26 + hasufell hasuf...@gentoo.org wrote: Probably because no one mentored them on how to fix these QA issues. Otherwise... if that's attitude, then that's just sad and has to be fixed by those who run that overlay (review, contribution guidelines). And I still think that the top 1 reason people run an overlay is because it's easier than contributing directly. A lot of overlay maintainers I tried to convince on getting more involved even said that. Even sunrise workflow has proven too slow and cumbersome... look at the commit history, it's constantly decreasing. Sure, reasons may vary, but there is not much positive to say about current gentoo workflow. We are setting up https://github.com/gentoo/proxy-maintainers to deal with some of these problems; if sunrise continues to decrease activity, I suspect this repository has a chance to become its successor. Travis integration is used to cover QA issues, see https://travis-ci.org/gentoo/proxy-maintainers which runs repoman on the overlay for each commit; therefore, QA issues don't go unnoticed. To improve the workflow further; we use app-portage/overlint to catch differences between that repository and the Portage tree, after which there is room for even much more automation; thus more time reviewing. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] [RFC] News item: GCC 4.8.3 defaults to -fstack-protector
Title: GCC 4.8.3 defaults to -fstack-protector Author: Ryan Hill rh...@gentoo.org Content-Type: text/plain Posted: 2014-06-10 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: =sys-devel/gcc-4.8.3 Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be enabled by default. The 4.8 series will enable -fstack-protector while 4.9 and later enable -fstack-protector-strong. SSP is a security feature that attempts to mitigate stack-based buffer overflows by placing a canary value on the stack after the function return pointer and checking for that value before the function returns. If a buffer overflow occurs and the canary value is overwritten, the program aborts. There is a small performance cost to these features. They can be disabled with -fno-stack-protector. For more information these options, refer to the GCC Manual, or the following articles. http://en.wikipedia.org/wiki/Buffer_overflow_protection http://en.wikipedia.org/wiki/Stack_buffer_overflow https://securityblog.redhat.com/tag/stack-protector http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] The state and future of the OpenRC project
Alexander Berntsen berna...@gentoo.org writes: It would be cool if some of the OpenRC hackers had the time to set up a developer's wiki or similar, where they share their workflow and similar. Nice idea, on my list. pgp5kJikw7nfi.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] News item: GCC 4.8.3 defaults to -fstack-protector
On Mon, 9 Jun 2014 18:16:02 -0600 Ryan Hill rh...@gentoo.org wrote: Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be enabled by default.[..] .. on supported architectures. Right? jer
Re: [gentoo-dev] Re: The state and future of the OpenRC project
Alexey Shvetsov ale...@gentoo.org writes: However this will depend on migration of gentoo-x86 to git Well, we can start evaluating gitlab for git overlays and gentoo hosted projects, such as (back to topic :) OpenRC. Is the infra team interested in this option? pgpqPDX0LzcUz.pgp Description: PGP signature
Re: [gentoo-dev] The state and future of the OpenRC project
All, just a quick update. I now have a box set up for installing gentoo on it so I will be able to take the lead on OpenRC again. I will have that up and running, probably tomorrow, then I also have a medical situation I have to take care of in a couple of weeks. I will continue to be intermittently around for a few weeks, but that should all be taken care of soon. If you want to help out, the #openrc irc channel is the place to go; that is where most things are done. You do not have to be a gentoo developer to contribute to OpenRC. Daniel Robbins assisted me today with tweaking the bios of the box I plan to put Gentoo on so that I can boot it from a cdrom. Also he alerted me to this thread, so that is why I wanted to post this update. He will also be becoming a co-maintainer of OpenRC, so you will see commits from him in the tree soon. Once I am fully up and running again, I plan to open a ml for OpenRC development. Thanks for your patience, William On 6/7/2014 4:08 PM, Jeroen Roovers wrote: On Sat, 07 Jun 2014 15:35:04 -0500 Daniel Campbell cont...@sporkbox.us wrote: [2]: Overview of bugs that involve OpenRC, most for the package itself. https://bugs.gentoo.org/buglist.cgi?quicksearch=openrc I think working on OpenRC would be a great learning experience for me and would be a great opportunity to contribute to Gentoo. You can start fixing bugs immediately. You can check out the sources, write patches and attach the patches to the bug reports. Then all it takes is someone else to review/commit the patches. jer
[gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector
On Tue, 10 Jun 2014 04:31:27 +0200 Jeroen Roovers j...@gentoo.org wrote: On Mon, 9 Jun 2014 18:16:02 -0600 Ryan Hill rh...@gentoo.org wrote: Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be enabled by default.[..] .. on supported architectures. Right? Yes. But now you've got me worried. We have to build gcc itself with -fno-stack-protector. Does compiling something with that flag give an error on hppa? Maybe give 4.8.2-r1 a whirl. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: The state and future of the OpenRC project
All, I attempted to post an update a bit earlier, but I haven't seen it yet, so I thought I would try again. Thanks to Daniel Robbins of funtoo, I am about to getGentoo installed on another box, so I will be able to take the lead on OpenRC again. He assisted me on Skype today with getting into setup on the box and setting the boot order so I can boot from a cd rom. Also, he volunteered to work with me as a co-maintainer of OpenRC. I should have the new box installed sometime tomorrow or Wednesday, then I will be around for a few days, then sometime on or after 18 June, I have a medical issue that I need to take care of. Once that is done, I should be back in the saddle so to speak. You don't need to be a gentoo developer to work on OpenRC, that work is happening on the #openrc irc channel. Also, the primary OpenRC repository is http://github.com/openrc/openrc, feel free to fork that and submit pull requests. Once I am fully back up and running, I am planning on opening a mailing list for OpenRC. Thanks for your patience, William
[gentoo-dev] Re: The state and future of the OpenRC project
William Hubbs posted on Mon, 09 Jun 2014 22:14:34 -0500 as excerpted: Daniel Robbins assisted me today with tweaking the bios of the box I plan to put Gentoo on so that I can boot it from a cdrom. Also he alerted me to this thread, so that is why I wanted to post this update. He will also be becoming a co-maintainer of OpenRC, so you will see commits from him in the tree soon. Very positive development. =:^) A bus-factor of one isn't a good thing, particularly for something as critical as an init-manager. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
