Re: [gentoo-dev] RFC: app-eselect category
Yes, +1 On Mar 29, 2015 12:59 AM, Ben de Groot yng...@gentoo.org wrote: On 29 March 2015 at 04:47, Ulrich Mueller u...@gentoo.org wrote: Now the number of eselect-* packages in the app-admin category has grown to 52. Should we create a new app-eselect category for them? I think this is a good idea. So +1 from me. -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] Last-rite x11-themes/gtk-engines-qtcurve
# Ben de Groot yng...@gentoo.org (29 Mar 2015) # Merged with qtcurve-qt4 into x11-themes/qtcurve (with gtk useflag) # Removal in 30 days. See also bug #544406. x11-themes/gtk-engines-qtcurve -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Should Gentoo do https by default?
On 27.03.2015 15:33, Hanno Böck wrote: I think defaulting the net to HTTPS is a big step for more security and I think Gentoo should join the trend here. Yes please! Sebastian
[gentoo-dev] Last rites: app-emulation/emul-linux-x86*
# Michał Górny mgo...@gentoo.org (14 Sep 2014) # on behalf of gx86-multilib project multi...@gentoo.org # Mask emul-linux-x86 packages along with unported old versions # of reverse dependencies for removal in 60 days, bug #544876. # Please use multilib ebuilds with abi_x86_32 instead. app-emulation/emul-linux-x86-baselibs app-emulation/emul-linux-x86-cpplibs app-emulation/emul-linux-x86-db app-emulation/emul-linux-x86-gstplugins app-emulation/emul-linux-x86-gtklibs app-emulation/emul-linux-x86-gtkmmlibs app-emulation/emul-linux-x86-medialibs app-emulation/emul-linux-x86-motif app-emulation/emul-linux-x86-opengl app-emulation/emul-linux-x86-qtlibs app-emulation/emul-linux-x86-sdl app-emulation/emul-linux-x86-soundlibs app-emulation/emul-linux-x86-xlibs app-emulation/emul-linux-x86-jna-20140508-r1 app-emulation/wine-1.6.1 x11-drivers/ati-drivers-14 -- Best regards, Michał Górny pgpao1B5UKQh0.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: app-eselect category
On Sat, 28 Mar 2015 21:47:04 +0100 Ulrich Mueller u...@gentoo.org wrote: I had already brought this up a long time ago [1] but it wasn't done then, mainly because the thread drifted into a discussion of the category's name. (Does anyone remember the Universal Select Tool which was a GSoC project in 2009? :) Now the number of eselect-* packages in the app-admin category has grown to 52. Should we create a new app-eselect category for them? eselect itself would stay in app-admin. app-admin itself contains 244 packages which is well above the median (58) and the mean value (113) of packages in a category. Ulrich [1] https://archives.gentoo.org/gentoo-dev/message/4cfd11c209754be96ffa417cb4d40b9f yes, +1 -- Brian Dolbec dolsen pgpJhxXd2_SPR.pgp Description: OpenPGP digital signature
[gentoo-dev] RFC: app-eselect category
I had already brought this up a long time ago [1] but it wasn't done then, mainly because the thread drifted into a discussion of the category's name. (Does anyone remember the Universal Select Tool which was a GSoC project in 2009? :) Now the number of eselect-* packages in the app-admin category has grown to 52. Should we create a new app-eselect category for them? eselect itself would stay in app-admin. app-admin itself contains 244 packages which is well above the median (58) and the mean value (113) of packages in a category. Ulrich [1] https://archives.gentoo.org/gentoo-dev/message/4cfd11c209754be96ffa417cb4d40b9f pgpsFqvMGQElj.pgp Description: PGP signature
Re: [gentoo-dev] rfc: zsh completions -- optional or mandatory?
On Sat, Mar 28, 2015 at 08:51:52AM +0800, Ben de Groot wrote: On 27 March 2015 at 00:51, William Hubbs willi...@gentoo.org wrote: The other method is shown by dev-vcs/hub at least, and maybe several other packages -- e.g. unconditionally installing the completions according to our small files installation practice and not reflecting the rdepend on app-shells/zsh. This is standard practice already (e.g. for systemd unit files and bash completion files), so this should be followed for zsh completion files as well. I'm going to go with what Rich and a couple of others said earlier in the thread. Especially with small files that we do not provide (e.g. that are not in $FILESDIR). I'm thinking that, tomorrow or Monday, I will open up a new thread to discuss what we are doing with small files and ask folks to consider changing at least part of the practice. William signature.asc Description: Digital signature
[gentoo-dev] Last rites: dev-java/jna-posix
# James Le Cuirot ch...@gentoo.org (28 Mar 2015) # Formerly required by NetBeans. Upstream has been dead for # years. Removal in 30 days. dev-java/jna-posix -- James Le Cuirot (chewi) Gentoo Linux Developer pgpIJ0tOffEY6.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: app-eselect category
On 29 March 2015 at 04:47, Ulrich Mueller u...@gentoo.org wrote: Now the number of eselect-* packages in the app-admin category has grown to 52. Should we create a new app-eselect category for them? I think this is a good idea. So +1 from me. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] RFC: app-eselect category
Dnia 2015-03-28, o godz. 21:47:04 Ulrich Mueller u...@gentoo.org napisał(a): I had already brought this up a long time ago [1] but it wasn't done then, mainly because the thread drifted into a discussion of the category's name. (Does anyone remember the Universal Select Tool which was a GSoC project in 2009? :) Now the number of eselect-* packages in the app-admin category has grown to 52. Should we create a new app-eselect category for them? eselect itself would stay in app-admin. app-admin itself contains 244 packages which is well above the median (58) and the mean value (113) of packages in a category. Yes, please do that before I finish the next package for that category ;). -- Best regards, Michał Górny pgp3ZHV4iZz48.pgp Description: OpenPGP digital signature
[gentoo-dev] Version Bumps
Dear fellow devs, The following behavior is not an appropriate procedure for a version bump! Seems like a trivial version bump, simply renaming the xxx ebuild works. Please check packages more carefully e.g. comparing configure.ac, Makefile.am, README, INSTALL, setup.py, requirements.txt and what all those names are. Thank you, Jusitn
[gentoo-dev] Cluster tinderbox poc
Hi As some of you may know, I have been working on code for a tinderbox with frontend support. I think its time to move it to a offcial project. The Proof-Of-Concept (poc) is almost ready, but it still have alot of the frontend left to do. You can see the logs and summit bugsreports and chose what to build. The poc is runing on a 64core box with help of ganeti to manges the virtual machines (vm). I have 4 vm's runing for now but I will add 4 more later. I'm building the vm's with help of ganeti-instance-gentoobootstrap. The vm's query the db for what to build. Db is update with tree info and list to builds for the vm's. The vm's are runing python code that call portage api to build the packages in the list. The frontend is just django. Featuers -Support multiplay repos -Support any arch there the python code can run. -Attach the build logs. -Use the db to store the repex for log search. /Magnus G.
Re: [gentoo-dev] Re: Review: Apache AddHandler news item
Hi! I was wondering about the same thing, too. I can commit it as revision 1 for a workaround. If you have some time, please take this question/issue further with the related software and people. Thanks in advance, Sebastian
Re: [gentoo-dev] Should Gentoo do https by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 +1 for everything. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlUWwDgACgkQRtClrXBQc7XyRQEAh2fJrr9aW9kLLa+a4hmwOT80 2ucx01RUq2IGmm9P7kMA/2o/rh46QX8xrAn5lbHtjqcy3y8NjW2gKsrg9QYATrHy =Uddl -END PGP SIGNATURE-
Re: [gentoo-dev] Should Gentoo do https by default?
Just my 5c: On Fri, 27 Mar 2015 19:18:24 + Robin H. Johnson robb...@gentoo.org wrote: * Make sure all use modern HTTPS features, including: * OCSP Stapling SSLUseStapling is Apache 2.3+ only, and that isn't stable yet. You can always set up Nginx, if not instead, but at least in front of the Apache and hand over SSL handling to it.
