Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 24/05/2012 03:19, Mark Wright wrote: > Michael Weber writes: >> "Clean cut" turns of cvs access on a given and announced timestamp, >> rsync-generation/updates is suspended (no input -> no changes), some >> magic scripts prepare the git repo (according to [3], some hours >> duration) and we all checkout the tree (might be some funny massive load). > > +1 for clean cut to git > clean cut +1
Re: [gentoo-dev] net-misc/rabbitmq-server up for grabs
I'll take it tho I don't use it. If someone else want it feel free to ping me, I share my toys. Cheers Ultra On 18/07/2012 18:37, Benedikt Böhm wrote: > All, > > i'm not using rabbitmq-server except as a dependency for > app-admin/chef and i've no interest or time to fix it. Feel free to > take it. > > Regards, > Bene >
Re: [gentoo-dev] Moving our/portage stuff to var
On 17/12/2012 13:15, Dirkjan Ochtman wrote: On Mon, Dec 17, 2012 at 11:23 AM, Diego Elio Pettenò wrote: I would say let's work on that so that portage can keep them there. Although I'm more for /var/cache/portage myself, as both distfiles and tree can be re-generated. +1. Cheers, Dirkjan +1 Ultra
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
Thanks for your work mate !
On 14/01/2013 21:24, Andreas K. Huettel wrote:
[CC'ing this to core so noone can complain afterwards.]
Since 48h did not lead to any responses positive or negative, I'll start
implementing the procedure as given in the original e-mail (quoted below).
As also said below, each arch will get a mail before I touch their profile
tree and after I've finished.
Cheers, Andreas
Am Samstag, 12. Januar 2013, 21:47:18 schrieb Andreas K. Huettel:
Hi everyone,
since Council has approved the creation of a fresh set of EAPI=5 "13.0"
profiles, I would like to volunteer for creating them. The proposed
procedure is outlined below in detail, and I'd be happy for comments.
[If anything below deviates from Council decision, please tell me- not my
intention.]
One general question comes first, though: Right now, the releases/10.0
profile directory does the following things:
* mask too-old portage
* set eapi
* add USE=bzip2
Is there anything unrelated to EAPI=5 that absolutely must be added to the
new releases/13.0 directory in addition in your opinion? (Whether this is
the right place and was the right place in the beginning for USE=bzip2 is
another question.)
###
The procedure (all paths relative to profiles):
1) create directory eapi-5-files, with eapi (containing 5), skeletons for
package.stable.mask etc and a readme
2) copy releases/10.0 to releases/13.0, in releases/13.0:
* increase required portage version
* additionally inherit ../../eapi-5-files
* other changes as per question above?
3) for each arch in default/linux,
* announce on arch alias (to prevent overlapping commits)
* copy default/linux/${arch}/10.0 to default/linux/${arch}/13.0 and
* change inheritance in the new copy to inherit ../../../../releases/13.0
instead of ../../../../releases/10.0
* announce on arch alias (so future changes go into 13.0 tree)
[This describes the simple case. I realize that there are differences in
the directory structure, e.g. powerpc/ppc64/10.0, which is why this step
needs extra care.]
4) edit profiles.desc and copy all "10.0 lines" to "13.0 lines", with an
initial setting "dev" (if dev or stable before) or "exp" (if exp before)
This makes repoman check against the new profiles when using developer
profiles.
5) announce the state on the dev list, urging devs to update their symlink
manually and !test!
6) wait one / two weeks
7) in profiles.desc, mark all 13.0 profiles stable that were stable in
10.0, and remove the lines for the 10.0 profiles. This makes eselect
profile now only offer the new ones, and repoman test by default against
13.0 profiles.
8) mark all 10.0 profiles as deprecated by creating a "deprecated" file
(containing the replacement suggestion) in the directory. This makes
portage warn users to upgrade (suggesting a new profile for them), and
repoman ignore the 10.0 profiles.
9) long waiting time as decided by Council
###
Everything that does NOT use/inherit 10.0 will remain unaffected, and
whoever responsible may have to take care of that some time before (in
step 10) the main profile directory becomes EAPI=5. This means e.g.
hardened, ulibc, prefix or bsd.
Cheers,
Andreas
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
On 10/06/2013 17:15, Alex Legler wrote: On 10.06.2013 14:36, Sergey Popov wrote: 09.06.2013 18:22, Alex Legler пишет: I'd appreciate some input on below plan to move project pages to the Wiki: Motivation -- The main motivation is to reduce the contents on the main website, allowing for an easier makeover. Also, the Wiki exposes the contents and an editing capability to more people, allowing for better collaboration. Finally, this is an opportunity for projects to go through the contents in their project spaces and update/remove outdated contents as well Gentoo as a whole to remove orphaned projects. Err, i do not want to say that wiki is not suite for this purpose, but what's wrong with current situation? Is there something wrong with gorg? The software is unmaintained, and the website template is next to unmaintainable. I could go on a bit more about this, but I think these two points *alone* justify moving away from it. Well, it is not always clear how to use some of it's features, but apart of that, why we should migrate to wiki? Just to clear orphaned project pages? No, I described multiple points. Again: - Less contents on www.g.o -> we can much more easily relaunch it - Users can more easily contribute to project documentation - Update/purge project documentation - Remove orphaned projects Why we can not just have official project pages, maintained as usual through gorg and additional info in wiki(if it is needed, for example, like we do on Gentoo Qt project page? In case it wasn't clear enough yet: This is step 1 of n to get rid of gorg and GuideXML for the website (read: not main docs) aspects of Gentoo. Running two project page venues increases maintenance instead of lowering it. I intend to have less work after this change, not more. Do you have any concerns beyond 'never change a running system'? +1, totally agree.. It's 2013 duh.. -- Ultrabug Gentoo / cluster
Re: [gentoo-dev] Moving more arches to dev profiles
On 08/21/2013 01:04 PM, Markos Chandras wrote: Hi, It's time of year again to consider moving a few arches to dev-only status. I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc The manpower on these arches is below acceptable levels and they often block stabilizations for many months. This also causes troubles to developers trying to get rid of old versions of packages. I am CC'ing Mike and on this to draw his attention since he seems to be doing stabilizations and keywording on a few of them. Moreover, Agostino is also doing a lot of work on these arches. Consider what will happen if he ever goes MIA or decides to retire ;) We will probably end up with a pile of stabilization bugs like the good old days. In my opinion, having these arches be ~arch only, will improve the overall user experience since the arch teams will only have to test a single tree. It will also help developers get rid of old ebuilds and keep the portage tree healthy and reasonably updated. If I get enough positive feedback on this, I will propose this in the next Council's agenda. +1 Even if I'm not directly concerned by those arches, I agree with your point and can see its benefits for both devs and users. Cheers
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On 12/10/2013 09:55 PM, Pacho Ramos wrote: https://bugs.gentoo.org/show_bug.cgi?id=197625#c14 This has reminded me that maybe we should switch to cronie from vixie-cron as default and recommended cron provider in Handbook. Last time I checked, vixie-cron upstream was died while cronie forked it fixing some bugs :/ What do you think? +1 here, thx
Re: [gentoo-dev] Maintainer-needed on many of my packages
On 12/29/2013 01:19 AM, Robin H. Johnson wrote: dev-db/redis I'll try my best on this one. sys-cluster/corosync Obviously I'll keep on working on this one along with the cluster team. Cheers Ultrabug
Re: [gentoo-dev] Thank you
On 02/06/2014 07:30 AM, Canek Peláez Valdés wrote: Hi. TL;DR, this is basically just a THANK YOU to the Gentoo devs, so you can go on your daily business if you don't want to read the rest of it. No biggie. Thank you for all the work you guys do and have done. Thank you for not penalize progress. Thank you for not being so rigid. Thank you for keeping the distribution moving and evolving. And finally, just thank you. Thank you for your email mate, it's great to read such a positive one :) From a proud Gentoo+systemd+GNOME 3 user, thank you. Regards. Kindly
Re: [gentoo-dev] New portage-9999 plugin-sync system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/12/2014 07:11, Brian Dolbec wrote: > > For those people running portage-. I've now merged the new > plugin-sync system into the master branch. I've just added the > following einfo block to the .ebuild. I will be preparing a > news item for review soon. We will be extending some of the > modules options, adding more capabilities such as git branch and > depth options. Thank you guys, I'm eager to see it live :) -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlSIJhAACgkQKiQSS7ZY+hM1FwD+J9l+qaOunmbpOjOA/c7vac+7 +Yh0GKHWXybXHcUHYTIA/2vQ1AzQMm5Yhy0uZA+iO34aI2LkOEjEbg2qQc6O8Xvh =TpZx -END PGP SIGNATURE-
Re: [gentoo-dev] CGA Web™ graphics standards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/04/2015 20:29, Joshua Kinard wrote: > Arguably the best 04/01 gag I've seen today. Can we keep this? > It'll make browsing the site on old SGI machines so much easier... > +1, very good job guys it made my day. Thank you ! -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlUc/BwACgkQKiQSS7ZY+hPvFgEAuOa1EZlahkb+9ebtgcBhJHm0 /lEf2jiALipYN0xapE4BAJazaOX0qvzzUwBPyVO7aLUzkMkcfXaiaq+dKCthXf/E =FDq5 -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/06/2015 05:25, Zac Medico wrote: > On 06/29/2015 07:24 PM, Michael Orlitzky wrote: >> On 06/29/2015 07:44 PM, Zac Medico wrote: >>> Having faced the exact same problem I have to say I agree 100% with Zac. I'd like to say that Gentoo needs this kind of packages to stay actual and that our NOGO (yes that's an actual joke) on Go packages is not good for us nowdays. >>> While it would certainly be possible to split out a number of >>> separate ebuilds for Go libraries that are used *exclusively* >>> by consul, what advantages would it have? >> >> Even in this limiting case, >> >> 1. You avoid pointless rebuilds. You rebuild the library (and >> probably the binary, for Go packages) when the library is >> upgraded rather than rebuilding everything whenever anything is >> updated. > > From my experience, Go packages don't take very long to build. > +1, Go is not C, I have the same feeling >> 2. Security. If upstream treats the packages as separate, a user >> might hear that there's a security issue in libfoo but then run >> eix and see that he doesn't have libfoo installed (because it's >> bundled). > > That's a reasonable motivation. However, many of these libraries > don't have any tags. So, you'll have to use the commit hashes if > you want to test for vulnerabilities. In the case of the consul > ebuild, the commit hashes of the libraries are available in the > SRC_URI. I suppose that we could standardize a way to expose > these. > +1, there is no strong tagging on every upstream. Maybe that's another topic but handling git sub modules et al could be made easier while satisfying our QA (or maybe make some exceptions) >> 3. Chicken and egg problem. If the library only has one consumer >> and you keep it bundled with that consumer forever, then it will >> probably only ever have one consumer. If somebody wants to use it >> in an overlay or something he'd have to pull in the whole >> program. > > If a Go developer wants to use the libraries in question, then > he'll probably use 'go get' to install them. I doubt the existence > of an ebuild will have much relevance in people's decision to adopt > a given Go library. > >> 4. Ebuild complexity. Now you have to compile e.g. three packages >> in src_compile, install three packages in src_install, etc. The >> result is more complicated than building once, three times. > > In the case of the consul ebuild, all of the libraries are > automatically built when the ebuild calls the emake. Even without a > Makefile, Go makes it trivial to build the dependencies. > Non live GIT ebuilds already make ebuilds more complex, this should indeed be enough. >> 5. One maintainer has to commit to maintaining all of the >> dependencies in addition to the program that he cares about. > > I guess that's a reasonable argument, depending on how much > maintenance the dependencies require. > Since there is no real Go support as such, this would be a pain ... >> Someone actually has to do the work to split out the libraries, >> so it may not be a clear-cut win in some cases. But it's nicer to >> have them split out should that happen by magic. > > Considering that Go binaries are statically linked, you'll end up > with a bunch of Go libraries installed that you don't need during > run-time. > +1, this defeats Go's main advantage imho (not that I think it's smart, but it's the actual fact) Cheers
Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/08/2015 16:32, Michał Górny wrote: > Hello, everyone. > > Now that we're officially on git and can officially use pull > requests to provide rapid community interaction, it'd be convenient > to have a little better framework for pinging package maintainers. > > With the unofficial mirror/pull request project, I was either > looking for project member GitHub accounts and pinging found > project members by name, or talking to them directly on IRC. > However, with the growth in number of pull requests this will > become more and more inconvenient. Therefore, I think it's time to > be able to mirror teams willing to work with GitHub community there > for easier 'pings'. > I like the idea, sounds very handy > I have two ideas right now: > > 1. creating GitHub Gentoo project teams corresponding to willing > Gentoo teams, > > 2. preparing lists of GitHub usernames on project wiki pages. > > Solution 1. is cleaner. In this case, we create GitHub teams under > the Gentoo projects, and add appropriate Gentoo developers having > GitHub accounts to the teams. Then, in PRs we can just ping the > whole team like @Gentoo/Qt or like. > +1 imho, clean & simple, only team and ppl willing to participate can get there > Solution 2. avoids adding any GitHub teams. In this case, in team > wiki page we collect team member usernames like "@Pesa, > @kensington, ..." so we could copy-paste it to pull requests. We > still require extra effort when 'assigning' PRs but at least I > don't have to lookup the same people over and over again. > > With some Wiki people help, we could even implement updating > GitHub teams automatically following Wiki member changes. > > Your thoughts? > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXKCqsACgkQKiQSS7ZY+hNd9AD9FBXc16nF9sp2Xk1gBpXsduGt a2+f1tHSMN9ChSrCBM4A/Ao1nCfMNBEaI9WYBUOQ0Cti5hkjM9X66sMlnszsBahP =GS6Q -END PGP SIGNATURE-
Re: [gentoo-dev] EAPI Cheat Sheet for review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17/10/2015 21:52, Ulrich Mueller wrote: > In addition to the EAPI 6 specification, a draft of the "EAPI > Cheat Sheet" is ready. > Great idea, I love it! Thanks for your time on this > http://dev.gentoo.org/~ulm/pms/6-draft/eapi-cheatsheet.pdf > http://dev.gentoo.org/~ulm/pms/6-draft/eapi-cheatsheet-nocombine.pdf > > The second version doesn't combine the leaflet pages and may be > better suited for online viewing. EAPI 6 is on pages 5 and 6. I > also include the patch for the LaTeX source below. > > Please review. > > Ulrich > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlYkoOsACgkQKiQSS7ZY+hNzHwD/UMKVsaD9KqICyvZyAroyW4tm AD4baO3cElSbhTGdCQsA/3AMYLTorx4XwOsI2B+Q6IwzcEKeM7SPTTkEBp0UzsCW =XzX5 -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-admin/rsyslog: ChangeLog rsyslog-5.6.5.ebuild rsyslog-5.6.4.ebuild
On 30/03/2011 16:12, Tomas Chvatal (scarabeus) wrote:
> scarabeus11/03/30 14:12:55
>
> Modified: ChangeLog rsyslog-5.6.5.ebuild rsyslog-5.6.4.ebuild
> Log:
> Drop logrotate useflag. Fixes bug #344175.
>
> (Portage version: 2.2.0_alpha29/cvs/Linux x86_64)
>
> Revision ChangesPath
> 1.39 app-admin/rsyslog/ChangeLog
>
> file :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-admin/rsyslog/ChangeLog?rev=1.39&view=markup
> plain:
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-admin/rsyslog/ChangeLog?rev=1.39&content-type=text/plain
> diff :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-admin/rsyslog/ChangeLog?r1=1.38&r2=1.39
>
> Index: ChangeLog
> ===
> RCS file: /var/cvsroot/gentoo-x86/app-admin/rsyslog/ChangeLog,v
> retrieving revision 1.38
> retrieving revision 1.39
> diff -u -r1.38 -r1.39
> --- ChangeLog 25 Mar 2011 09:27:20 - 1.38
> +++ ChangeLog 30 Mar 2011 14:12:55 - 1.39
> @@ -1,6 +1,10 @@
> # ChangeLog for app-admin/rsyslog
> # Copyright 1999-2011 Gentoo Foundation; Distributed under the GPL v2
> -# $Header: /var/cvsroot/gentoo-x86/app-admin/rsyslog/ChangeLog,v 1.38
> 2011/03/25 09:27:20 ultrabug Exp $
> +# $Header: /var/cvsroot/gentoo-x86/app-admin/rsyslog/ChangeLog,v 1.39
> 2011/03/30 14:12:55 scarabeus Exp $
> +
> + 30 Mar 2011; Tomáš Chvátal rsyslog-5.6.4.ebuild,
> + rsyslog-5.6.5.ebuild:
> + Drop logrotate useflag. Fixes bug #344175.
>
>25 Mar 2011; Ultrabug rsyslog-5.6.5.ebuild:
>add back virtual/logger provider waiting for migration (#358881)
>
>
>
> 1.3 app-admin/rsyslog/rsyslog-5.6.5.ebuild
>
> file :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-admin/rsyslog/rsyslog-5.6.5.ebuild?rev=1.3&view=markup
> plain:
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-admin/rsyslog/rsyslog-5.6.5.ebuild?rev=1.3&content-type=text/plain
> diff :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-admin/rsyslog/rsyslog-5.6.5.ebuild?r1=1.2&r2=1.3
>
> Index: rsyslog-5.6.5.ebuild
> ===
> RCS file: /var/cvsroot/gentoo-x86/app-admin/rsyslog/rsyslog-5.6.5.ebuild,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- rsyslog-5.6.5.ebuild 25 Mar 2011 09:27:20 - 1.2
> +++ rsyslog-5.6.5.ebuild 30 Mar 2011 14:12:55 - 1.3
> @@ -1,6 +1,6 @@
> # Copyright 1999-2011 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> -# $Header: /var/cvsroot/gentoo-x86/app-admin/rsyslog/rsyslog-5.6.5.ebuild,v
> 1.2 2011/03/25 09:27:20 ultrabug Exp $
> +# $Header: /var/cvsroot/gentoo-x86/app-admin/rsyslog/rsyslog-5.6.5.ebuild,v
> 1.3 2011/03/30 14:12:55 scarabeus Exp $
>
> EAPI=3
>
> @@ -11,13 +11,12 @@
> LICENSE="GPL-3 LGPL-3"
> KEYWORDS="~amd64 ~arm ~hppa ~sparc ~x86"
> SLOT="0"
> -IUSE="dbi debug doc extras gnutls kerberos logrotate mysql oracle postgres
> relp snmp static-libs zlib"
> +IUSE="dbi debug doc extras gnutls kerberos mysql oracle postgres relp snmp
> static-libs zlib"
>
> DEPEND="dbi? ( dev-db/libdbi )
> extras? ( net-libs/libnet )
> gnutls? ( net-libs/gnutls )
> kerberos? ( virtual/krb5 )
> - logrotate? ( app-admin/logrotate )
> mysql? ( virtual/mysql )
> postgres? ( dev-db/postgresql-base )
> oracle? ( dev-db/oracle-instantclient-basic )
> @@ -98,10 +97,8 @@
> doins plugins/ompgsql/createDB.sql || die
> fi
>
> - if use logrotate; then
> - insinto /etc/logrotate.d/
> - newins "${FILESDIR}/${BRANCH}/rsyslog.logrotate" rsyslog || die
> - fi
> + insinto /etc/logrotate.d/
> + newins "${FILESDIR}/${BRANCH}/rsyslog.logrotate" rsyslog || die
> }
>
> pkg_postinst() {
>
>
>
> 1.2 app-admin/rsyslog/rsyslog-5.6.4.ebuild
>
> file :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-admin/rsyslog/rsyslog-5.6.4.ebuild?rev=1.2&view=markup
> plain:
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-admin/rsyslog/rsyslog-5.6.4.ebuild?rev=1.2&content-type=text/plain
> diff :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-admin/rsyslog/rsyslog-5.6.4.ebuild?r1=1.1&r2=1.2
>
> Index: rsyslog-5.6.4.ebuild
> ===
> RCS file: /var/cvsroot/gentoo-x86/app-admin/rsyslog/rsyslog-5.6.4.ebuild,v
> retrieving revision 1.1
> retri
[gentoo-dev] Re: [gentoo-commits] proj/betagarden:master commit in: dev-db/mongodb/files/, dev-db/mongodb/
f --git a/dev-db/mongodb/mongodb-1.7.5.ebuild
> b/dev-db/mongodb/mongodb-1.7.5.ebuild
> deleted file mode 100644
> index c25a8a4..000
> --- a/dev-db/mongodb/mongodb-1.7.5.ebuild
> +++ /dev/null
> @@ -1,65 +0,0 @@
> -# Copyright 1999-2010 Gentoo Foundation
> -# Distributed under the terms of the GNU General Public License v2
> -# $Header: $
> -
> -EAPI="2"
> -
> -SCONS_MIN_VERSION="1.2.0-r1"
> -MY_P="${PN}-src-r${PV}"
> -
> -inherit eutils scons-utils versionator
> -
> -DESCRIPTION="A high-performance, open source, schema-free document-oriented
> database"
> -HOMEPAGE="http://www.mongodb.org";
> -SRC_URI="http://downloads.mongodb.org/src/${MY_P}.tar.gz";
> -
> -LICENSE="AGPL-3 Apache-2.0"
> -SLOT="0"
> -KEYWORDS="~amd64 ~x86"
> -IUSE=""
> -
> -RDEPEND="
> - dev-lang/spidermonkey[unicode]
> - dev-libs/boost
> - dev-libs/libpcre
> - net-libs/libpcap
> -"
> -
> -DEPEND="${RDEPEND}
> - sys-libs/readline
> - sys-libs/ncurses
> -"
> -
> -S="${WORKDIR}/${MY_P}"
> -
> -pkg_setup() {
> - enewgroup mongodb
> - enewuser mongodb -1 -1 /var/lib/${PN} mongodb
> -}
> -
> -#src_prepare() {
> -#epatch "${FILESDIR}/${PN}-1.6.3-fix-scons.patch"
> -#}
> -
> -src_compile() {
> - escons all || die "Compile failed"
> -}
> -
> -src_install() {
> - escons --full --nostrip install --prefix="${D}"/usr || die "Install
> failed"
> -
> - for x in /var/{lib,log,run}/${PN}; do
> - dodir "${x}" || die "Install failed"
> - fowners mongodb:mongodb "${x}"
> - done
> -
> - doman debian/mongo*.1 || die "Install failed"
> - dodoc README docs/building.md
> -
> - newinitd "${FILESDIR}/${PN}.initd" ${PN} || die "Install failed"
> - newconfd "${FILESDIR}/${PN}.confd" ${PN} || die "Install failed"
> -}
> -
> -src_test() {
> - escons smoke --smokedbprefix='testdir' test || die "Tests failed"
> -}
>
> diff --git a/dev-db/mongodb/mongodb-1.8.0_rc1.ebuild
> b/dev-db/mongodb/mongodb-1.8.0_rc1.ebuild
> deleted file mode 100644
> index 25f1299..000
> --- a/dev-db/mongodb/mongodb-1.8.0_rc1.ebuild
> +++ /dev/null
> @@ -1,65 +0,0 @@
> -# Copyright 1999-2010 Gentoo Foundation
> -# Distributed under the terms of the GNU General Public License v2
> -# $Header: $
> -
> -EAPI="2"
> -
> -SCONS_MIN_VERSION="1.2.0-r1"
> -MY_P="${PN}-src-r${PV/_rc/-rc}"
> -
> -inherit eutils scons-utils versionator
> -
> -DESCRIPTION="A high-performance, open source, schema-free document-oriented
> database"
> -HOMEPAGE="http://www.mongodb.org";
> -SRC_URI="http://downloads.mongodb.org/src/${MY_P}.tar.gz";
> -
> -LICENSE="AGPL-3 Apache-2.0"
> -SLOT="0"
> -KEYWORDS="~amd64 ~x86"
> -IUSE=""
> -
> -RDEPEND="
> - dev-lang/spidermonkey[unicode]
> - dev-libs/boost
> - dev-libs/libpcre
> - net-libs/libpcap
> -"
> -
> -DEPEND="${RDEPEND}
> - sys-libs/readline
> - sys-libs/ncurses
> -"
> -
> -S="${WORKDIR}/${MY_P}"
> -
> -pkg_setup() {
> - enewgroup mongodb
> - enewuser mongodb -1 -1 /var/lib/${PN} mongodb
> -}
> -
> -#src_prepare() {
> -#epatch "${FILESDIR}/${PN}-1.6.3-fix-scons.patch"
> -#}
> -
> -src_compile() {
> - escons all || die "Compile failed"
> -}
> -
> -src_install() {
> - escons --full --nostrip install --prefix="${D}"/usr || die "Install
> failed"
> -
> - for x in /var/{lib,log,run}/${PN}; do
> - dodir "${x}" || die "Install failed"
> - fowners mongodb:mongodb "${x}"
> - done
> -
> - doman debian/mongo*.1 || die "Install failed"
> - dodoc README docs/building.md
> -
> - newinitd "${FILESDIR}/${PN}.initd" ${PN} || die "Install failed"
> - newconfd "${FILESDIR}/${PN}.confd" ${PN} || die "Install failed"
> -}
> -
> -src_test() {
> - escons smoke --smokedbprefix='testdir' test || die "Tests failed"
> -}
>
> diff --git a/dev-db/mongodb/mongodb-1.8.0.ebuild
> b/dev-db/mongodb/mongodb-1.8.1.ebuild
> similarity index 58%
> rename from dev-db/mongodb/mongodb-1.8.0.ebuild
> rename to dev-db/mongodb/mongodb-1.8.1.ebuild
> index 3849f20..74b7af6 100644
> --- a/dev-db/mongodb/mongodb-1.8.0.ebuild
> +++ b/dev-db/mongodb/mongodb-1.8.1.ebuild
> @@ -16,36 +16,50 @@ SRC_URI="http://downloads.mongodb.org/src/${MY_P}.tar.gz";
> LICENSE="AGPL-3 Apache-2.0"
> SLOT="0"
> KEYWORDS="~amd64 ~x86"
> -IUSE=""
> +IUSE="v8"
>
> -RDEPEND="
> - dev-lang/spidermonkey[unicode]
> +RDEPEND="!v8? ( >=dev-lang/spidermonkey-1.9.2.15 )
> + v8? ( dev-lang/v8 )
> dev-libs/boost
> - dev-libs/libpcre
> - net-libs/libpcap
> -"
> + dev-libs/libpcre[cxx]
> + net-libs/libpcap"
>
> DEPEND="${RDEPEND}
> sys-libs/readline
> - sys-libs/ncurses
> -"
> + sys-libs/ncurses"
>
> S="${WORKDIR}/${MY_P}"
>
> pkg_setup() {
> enewgroup mongodb
> enewuser mongodb -1 -1 /var/lib/${PN} mongodb
> +
> + if use v8; then
> + scons_opts="--usev8"
> + else
> + scons_opts="--usesm"
> + fi
> +}
> +
> +src_prepare() {
> + epatch "${FILESDIR}/${PN}-1.8.1-fix-scons.patch"
> +
> + if use v8; then
> + # Suppress known test failure with v8:
> + # http://jira.mongodb.org/browse/SERVER-1147
> + sed -e '/add< NumberLong >/d' -i dbtests/jstests.cpp || die
> + fi
> }
>
> src_compile() {
> - escons all || die "Compile failed"
> + escons ${scons_opts} all || die "Compile failed"
> }
>
> src_install() {
> - escons --full --nostrip install --prefix="${D}"/usr || die "Install
> failed"
> + scons ${scons_opts} --full --nostrip install --prefix="${D}"/usr || die
> "Install failed"
>
> for x in /var/{lib,log,run}/${PN}; do
> - dodir "${x}" || die "Install failed"
> + dodir "${x}"
> fowners mongodb:mongodb "${x}"
> done
>
> @@ -57,5 +71,5 @@ src_install() {
> }
>
> src_test() {
> - escons smoke --smokedbprefix='testdir' test || die "Tests failed"
> + scons ${scons_opts} smoke --smokedbprefix='testdir' test || die "Tests
> failed"
> }
>
Hi mate, thanks for working on mongodb fix/bump !
Just so you know, I'm working with @jbergstroem on this aswell, maybe
you could have a look at my overlay (ultrabug) and give your feedback
please ?
Regards
--
Ultrabug
Gentoo / cluster
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] www-servers herd is empty
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/03/2012 10:47, Pacho Ramos wrote: > El mar, 20-03-2012 a las 11:40 +0200, Samuli Suominen escribió: >> On 03/20/2012 11:36 AM, Pacho Ramos wrote: >>> El lun, 19-03-2012 a las 20:48 +, Markos Chandras >>> escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/19/2012 08:32 AM, Pacho Ramos wrote: > El dom, 18-03-2012 a las 20:29 -0400, Chris Reffett > escribió: >> Hi, I'd be interested in helping with www-servers, but I >> would have to help by proxy because I am not a dev yet. >> Chris Reffett >> >> On 03/18/12 15:27, Pacho Ramos wrote: >>> With bass retirement (#391429) lcd has become empty, is >>> anybody willing to join or should their packages be >>> moved to maintainer-needed (CCing that empty herd to >>> allow somebody joining in the future to easily >>> resurrect the herd)? >>> >>> Thanks >>> > > Thanks for offering your help, will CC gentoo-dev mailing > list and proxy-maint to see how we could handle this case > It is very unlikely for proxy-maintainers to proxy an entire herd. Sorry - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 >>> >>> We need to try to find a way to let him contribute, the problem >>> is that I don't know much about Chris to know if he is ready to >>> try to become a gentoo-dev in the near future :S >> >> I find the whole concept of www-servers herd flawed. It's not >> very likely one person would be running many different servers, >> and thus be able to contribute to them. >> That's my case tbh, I co-maintain a www-servers package but don't feel like being able to maintain the whole of them as I just don't use them all. >> Propably why the team has no members in the first place... >> >> > > Then, the way to go would be to move them to maintainer-needed and > let people pick whatever they want. I agree and can do it myself > just now if you let me do I think that's a good idea and reasonable way to go. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk9pje8ACgkQKiQSS7ZY+hP2cAD/Wix5cEM6YuFMu4V/l3sTZTci eBHwWjKVBHTb1+G/HmsA/3HPgxNSesEedPWLxgQ0f7Rk1W2QZTq2S99WVdIPNeyq =lrz9 -END PGP SIGNATURE-
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/05/2017 15:49, Michał Górny wrote: > Dnia 8 maja 2017 15:27:18 CEST, Dirkjan Ochtman > napisał(a): >> On Mon, May 8, 2017 at 12:49 PM, Mikle Kolyada >> wrote: >>> Against. Do not touch things you are not working on, council >>> has >> already >>> dropped m68k s390 and sh to exp few years ago. Now we have a >>> big mess there and only, while ia64 sparc and co have slow but >>> progress and mature enough stable profiles. >> >> Obviously we should prevent big messes from happening. But it's >> a mistake that things I don't work on don't affect me -- work >> left over by lagging arch teams can affect me in many ways, in >> terms of having to keep older versions of my packages working and >> in the tree, and having to keep track of many more KEYWORDREQs >> and STABLEREQs. >> >> To me it's likely that the pace of stabilization for everyone is >> affected by the slower arches, in the sense that maintainers are >> less likely to stabilize newer versions if they see that arches >> can't keep up with previous requests. This means that even stable >> amd64 users are affected to some extent by ppc being slow to >> stabilize. > > Plus the usual mess of having to keep up with multiple large > stablereqs for stuff where we need to stabilize newer while some > arches are still two stabilizations behind. > > Not to mention when we want to stabilize a new version but the > arches still haven't even keyworded it... That ! We can all face that our latency is not good for our traction on a wider user base. Freeing ourselves from this kind of latency is energy saving and thus a positive move imho. > >> >> Cheers, >> >> Dirkjan > > -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQSqwxDKv5211qJQBiIqJBJLtlj6EwUCWRHIfQAKCRAqJBJLtlj6 EwmzAPwP2a6MgG3aE6EdSuPLjsabytT+qRskanNMJtiVsQqWpwD+NsGzWk9ff1RS 2mZYazWC5U9HBD3MzPG65jhX8Dl43jA= =h+5a -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-dev-announce] Developer commit timeline updates
On 24/06/2018 00:36, Michał Górny wrote: > Hi, everyone. > > I'd like to just make a short announcement that I've updated > the developer commit timeline [1]. Besides the usual periodic update, > there are two major changes: > > a. I've added commit counts to the bars (in the popups shown upon > hovering the bar), > > b. I've created an additional timeline for determining activity of > active Gentoo developers, as a partial replacement for the semi-broken > 'slacker' script used by Undertakers [2]. Thank you for updating and sharing this! I remember a sort of animated / timelapse version that was shared someday, it was good too.
Re: [gentoo-dev] [RFC] Dropping PyPy(3) back to ~arch
On 02/03/2021 16:05, Michał Górny wrote: Hi, Hi I don't really want to remove it entirely or revert all the work we've put into testing packages with it -- but I think we should move it to ~arch at the very least. WDYT? I agree with you, I'd drop it back to ~arch too. Thanks for your work on keeping pypy up.
Re: [gentoo-dev] Packages up for grabs
On 04/08/2021 11:08, Sergei Trofimovich wrote: Last batch of packages in search of a dedicated maintainer: x11-misc/i3status I've taken it, thanks Sergei None of them should have any immediate problems.
Re: [gentoo-dev] Packages up for grabs
On 30/08/2021 13:37, Jakov Smolić wrote: On 8/30/21 10:39 AM, Lars Wendler wrote: Hi, the following packages are up for grabs: app-emulation/sen (3 open bugs) dev-python/flexmock sys-process/nmon (2 open bugs) x11-wm/i3 I can take i3. If anybody else is interested feel free to join in. I'll join you mate, cheers Cheers
