[gentoo-dev] Thoughts about LUA_TARGETS
Hi! As you can be noticed, Lua packages, just like Python, PHP or Ruby ones, supports slotted behaviour (with some side notes). As far as we have nice *_TARGETS for languages above (without standardised naming syntax, although), we still do not have such for Lua. Rafael's main argument is about that fact, that Lua releases between themselves has incompatible bytecode, sometimes syntax (just as all interpreters above), and that LuaJIT has incompatible bytecode even with version it is built to be as (i.e. libluajit-5.1 bytecode is incompatible with liblua-5.1, and so on for 5.2 and 5.3). But as far as I know, it is same issues between CPython and PyPy, and between MRI and Rubinius. So, I'd like to escalate that problem, finally make some decision and finally introduce LUA_TARGETS on packages ;). -- Best regards, mva signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Review: Apache AddHandler news item
Sebastian Pipping posted on Thu, 26 Mar 2015 19:15:09 +0100 as excerpted: Changes: * Revision bump This ^^.. * Add section on .php.inc * Add thanks line Title: Apache AddHandler vulnerability protection Author: Sebastian Pipping sp...@gentoo.org Content-Type: text/plain Posted: 2015-03-26 Revision: 2 And this ^^.. News-Item-Format: 1.0 Display-If-Installed: www-servers/apache This is a common error. While not entirely intuitive, AFAIK revision is a post-publication value and should remain revision 1 unless a correction is needed once published. Perhaps it is time to formally change that. Reading software must be prepared to deal with first-seen values greater than 1 in any case, since a user might not have seen the original revision, and history has repeatedly demonstrated that people want to bump the revision number during initial discussion. So why not simply let it be bumped, and let the first published version be what it may? If necessary, further bumps can happen from there. Tho in practice, very likely as a result of the pre-publishing approval process including discussion here, AFAIK no such post-publishing correcting revision has ever been necessary. But that's not to say it won't /ever/ be necessary, so having the ability is certainly a good thing. =:^) Either that or start out with a pre-publishing version of 0.1 and bump that, changing it to 1 on initial publish. -- 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
[gentoo-dev] Last rites: app-admin/eselect-nxserver, net-misc/{neatx,nxcl,nxclient,nxnode,nxsadmin,nxserver-freeedition,nxserver-freenx,qtnx}
# Bernard Cafarelli voyag...@gentoo.org (26 Mar 2015)
# Dead upstreams, not working in some use cases,
# compatibility with current net-misc/nx not guaranteed,
# some bundle old binary Xorg code that may be vulnerable,
# modern alternative exist:
# net-misc/x2go{client,server} and proprietary NX 4 (bug #488334)
# These packages are now available in the NX overlay
# Removal in a month (bug #537774)
app-admin/eselect-nxserver
net-misc/neatx
net-misc/nxcl
net-misc/nxclient
net-misc/nxnode
net-misc/nxsadmin
net-misc/nxserver-freeedition
net-misc/nxserver-freenx
net-misc/qtnx
--
Bernard Cafarelli (Voyageur)
Gentoo developer (NX, GNUstep, net-misc, llvm/clang, ...)
Re: [gentoo-dev] Review: Apache AddHandler news item
On 03/26/2015 12:56 PM, Sebastian Pipping wrote: Why this news entry? The most important reason is missing =) If you are relying on the AddHandler behavior to execute secret_database_stuff.php.inc, then once the change is made, Apache will begin serving up your database credentials in plain text.
[gentoo-dev] rfc: zsh completions -- optional or mandatory?
All, I'm seeing at least two ways of handling zsh completion files in the tree. The first is in a package I maintain and several others in the tree -- using the zsh-completion use flag along with an rdepend on app-shells/zsh behind the use flag. The package I maintain that does this is www-client/pybugz, but you will find several other packages doing the same thing. 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. I think we should be consistent with how we handle this, and personally I would vote for the first way since zsh is not all that common. However, if the feeling is that we should nuke the zsh-completion use flag, I'll be the first to do it, and I'll start opening bugs against other packages. Comments/discussion are welcome. William signature.asc Description: Digital signature
[gentoo-dev] x11-libs/libXaw3dXft up for grabs
x11-libs/libXaw3dXft is up for grabs, as the x11 team is not interested in maintaining this package. The only reverse dependency of this package is media-gfx/xpaint.
Re: [gentoo-dev] rfc: zsh completions -- optional or mandatory?
On Thu, Mar 26, 2015 at 01:17:02PM -0400, Rich Freeman wrote: On Thu, Mar 26, 2015 at 12:51 PM, 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. I'd go with this, since this is how we handle bash. Second choice would be to make installing the files USE-conditional (since zsh is less common), but I wouldn't ever add an RDEPEND for zsh. I like your second choice. That means we are granting exceptions to our small files practice, which I would welcome. I feel much better about telling users to change use flags than telling them to use INSTALL_MASK for changes like this. William signature.asc Description: Digital signature
[gentoo-dev] Review: Apache AddHandler news item
Hi! In context of https://bugs.gentoo.org/show_bug.cgi?id=538822 mjo and agreed that a portage news item would be a good idea. Please review my proposal below. Thank you! Best, Sebastian === Title: Apache AddHandler vulnerability protection Author: Sebastian Pipping sp...@gentoo.org Content-Type: text/plain Posted: 2015-03-26 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: www-servers/apache Apache's directive AddHandler [1] can be used to map certain file name extensions (e.g. .php) to a handler (e.g. application/x-httpd-php). While a line like AddHandler application/x-httpd-php .php .php5 .phtml matches index.php, it also matches index.php.png. Apache's notes on multiple file extensions [2] document a multi-language website as a context where that behavior may be helpful. Unfortunately, it can be a security threat. Combined with (not just PHP) applications that support file upload, the AddHandler directive can get you into remote code execution situations. That is why app-admin/eselect-php now avoids AddHandler and is shipping FilesMatch \.(php|php5|phtml)$ SetHandler application/x-httpd-php /FilesMatch instead. Why this news entry? * Since Apache configuration lives below /etc, you need to run etc-update (or a substitute) to actually have related fixes applied. * You may be using AddHandler at other places, including off-package files. Please have a look. * app-admin/eselect-php is not the only package affected. There is a dedicated tracker bug at [3]. As of the momment, affected packages include: app-admin/eselect-php[apache2] dev-lang/php[apache2] net-nds/gosa-core www-apache/mod_fastcgi www-apache/mod_flvx www-apache/mod_python www-apache/mod_suphp www-apps/moinmoin www-apps/rt[-lighttpd] [1] https://httpd.apache.org/docs/current/mod/mod_mime.html#addhandler [2] https://httpd.apache.org/docs/current/mod/mod_mime.html#multipleext [3] https://bugs.gentoo.org/show_bug.cgi?id=544560
Re: [gentoo-dev] rfc: zsh completions -- optional or mandatory?
On Thu, Mar 26, 2015 at 12:51 PM, 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. I'd go with this, since this is how we handle bash. Second choice would be to make installing the files USE-conditional (since zsh is less common), but I wouldn't ever add an RDEPEND for zsh. -- Rich
Re: [gentoo-dev] Review: Apache AddHandler news item
* Sebastian Pipping schrieb am 26.03.15 um 19:15 Uhr: As of the momment, affected packages include: ^ Typo -- 0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 signature.asc Description: Digital signature
Re: [gentoo-dev] Review: Apache AddHandler news item
On 26.03.2015 18:02, Michael Orlitzky wrote: The most important reason is missing =) If you are relying on the AddHandler behavior to execute secret_database_stuff.php.inc, then once the change is made, Apache will begin serving up your database credentials in plain text. Good point. Changes: * Revision bump * Add section on .php.inc * Add thanks line Title: Apache AddHandler vulnerability protection Author: Sebastian Pipping sp...@gentoo.org Content-Type: text/plain Posted: 2015-03-26 Revision: 2 News-Item-Format: 1.0 Display-If-Installed: www-servers/apache Apache's directive AddHandler [1] can be used to map certain file name extensions (e.g. .php) to a handler (e.g. application/x-httpd-php). While a line like AddHandler application/x-httpd-php .php .php5 .phtml matches index.php, it also matches index.php.png. Apache's notes on multiple file extensions [2] document a multi-language website as a context where that behavior may be helpful. Unfortunately, it can be a security threat. Combined with (not just PHP) applications that support file upload, the AddHandler directive can get you into remote code execution situations. That is why app-admin/eselect-php now avoids AddHandler and is shipping FilesMatch \.(php|php5|phtml)$ SetHandler application/x-httpd-php /FilesMatch instead. Why this news entry? * Since Apache configuration lives below /etc, you need to run etc-update (or a substitute) to actually have related fixes applied. * If you are currently relying on AddHandler to execute secret_database_stuff.php.inc, moving away from AddHandler could result in serving your database credentials in plain text. A command like find /var/www/ -name '*.php.*' \ -o -name '*.php5.*' \ -o -name '*.phtml.*' may help discovering PHP files that would no longer be executed. * You may be using AddHandler at other places, including off-package files. Please have a look. * app-admin/eselect-php is not the only package affected. There is a dedicated tracker bug at [3]. As of the momment, affected packages include: app-admin/eselect-php[apache2] dev-lang/php[apache2] net-nds/gosa-core www-apache/mod_fastcgi www-apache/mod_flvx www-apache/mod_python www-apache/mod_suphp www-apps/moinmoin www-apps/rt[-lighttpd] Thanks to Nico Suhl and Michael Orlitzky. [1] https://httpd.apache.org/docs/current/mod/mod_mime.html#addhandler [2] https://httpd.apache.org/docs/current/mod/mod_mime.html#multipleext [3] https://bugs.gentoo.org/show_bug.cgi?id=544560
Re: [gentoo-dev] Review: Apache AddHandler news item
On 26.03.2015 20:50, Marc Schiffbauer wrote: * Sebastian Pipping schrieb am 26.03.15 um 19:15 Uhr: As of the momment, affected packages include: ^ Typo Thanks. Fixed in my local copy. No need to re-paste, I believe. Best, Sebastian
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
On 14.03.2015 23:25, Robin H. Johnson wrote:
Trying to explain to a new user that the Portage tree refers to the
collection of ebuilds used by a PMS-compliant package manager (eg
Portage) is problematic.
Full ack. Let's limit portage to the piece of software, please.
Questions: 0. What names for the tree/repository.
It's not a tree. Ideally, it would be a directed acyclic graph (DAG),
there maybe be some loops, even.
I would therefore object to any name that has tree in it.
Since there are other Gentoo-based distros, I would say the word
gentoo should be in there.
Plain gentoo may work. I would be happy with any of
gentoo-{core,main,master} as well, if plain gentoo causes trouble
for a name in some context.
1. We have some namespaces in Git: proj, dev, priv, data, sites,
exp; should the tree be in one of those namespaces, a new
namespace, or be without a namespace?
git://anongit.gentoo.org/NEW-NAME.git.
Not in any of those namespace, please.
If in any, make it repos or repositories, please.
Thanks for your consideration.
Best,
Sebastian
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
On 15.03.2015 10:48, Ulrich Mueller wrote:
If we want a separate repo/ namespace, we would probably need to
consider moving other repositories there -- at least the
official ones. Of course, it would be a nice result, having
everything hosted on git.g.o as git.g.o/repo/${repo_name}.git.
Isn't repo fairly redundant? Everything there is a repository.
There are Git repositories that do not contain ebuilds up there. So
repo is not redundant if it refers to its overlays kind of meaning.
Two examples:
http://gitweb.gentoo.org/proj/portage-utils.git/
http://gitweb.gentoo.org/proj/userinfo-scripts.git/
Best,
Sebastian
[gentoo-dev] [warning] the bug queue has 101 bugs
Our bug queue has 101 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Questions: 0. What names for the tree/repository. 1. We have some namespaces in Git: proj, dev, priv, data, sites, exp; should the tree be in one of those namespaces, a new namespace, or be without a namespace? git://anongit.gentoo.org/NEW-NAME.git. Here's an additional suggestion. It would be great to logically separate ebuild repositories (main tree and overlays) somehow logically from code, data, ... How about adding an additional level repo for everything that contains ebuild trees? repo/gentoo -- our main tree repo/proj/kde repo/proj/perl-overlay repo/dev/dilfridge Everything else stays where it is, eg., data/glsa proj/sandbox proj/portage ... - -- Andreas K. Huettel Gentoo Linux developer (council, perl, libreoffice) dilfri...@gentoo.org http://www.akhuettel.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVFHriAAoJEB9VdM6hupKVFbQQAK8xxy0TKMR9/a56ZTjgjZZE g/a2KqcwGuCRRkgGRHeRMiC5kkh8L1mS9WBJNIYA05todRv2eqG9fQCzO0xhF0YK iOMqBtO8A+KCgGcJ6ilaaCUn1Lp62d7bqdXvePE0i98qVrc1rXeXJGTAk4J/jGPQ 95iShF1/Pe8GGxJ/Qw+ekOwoDgqBCVJzjBEedfoOzI5yqxXDJZR1nCBqzZwl7DhW Fe/GQvNtTlGSlVq5i/1aOfVekabIGR82P+nqzSyKF88aYTdDVrmmeszvMx/pHOmk sdA8/k1JWNahK3RwL2n8xvil0sKFzPGiIqrV6VLJj5FnF+85ZSy4WYKuI4mJUQmx Nb3hELnZYs+J9COH7vGaHVGnVfZonkRm1AuTmzkDv2nBp92Z37DRA6m5vGlik9a7 rD02omjBaEJXZovxHOP30RlIxxqo5g0V2ytdqh8gD8sOsn21CGKJc/9QqzQ8SjrG tqQPwM+O0Kqk5Vl8CAuqm9J4cnJJSwoO7g1ERjv2y4zW4o7sQgMBdiNQ1w/It0q5 FjXK6x+8zB3jyKKkFQX70FQwjgDMlwYdEizbTKmRImeHDD7HUclOcC1NurrZNpS4 KwSFeNDiJ/4yslRCWXpgf5AJRszqQ7D0KOTlqiEOySsXuTc12ChPot143XILRCCB Uu7WG42KljBVR/zKIFrR =QmjZ -END PGP SIGNATURE-
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
On 27 March 2015 at 10:32, Andreas K. Huettel dilfri...@gentoo.org wrote: It would be great to logically separate ebuild repositories (main tree and overlays) somehow logically from code, data, ... How about adding an additional level repo for everything that contains ebuild trees? repo/gentoo -- our main tree repo/proj/kde repo/proj/perl-overlay repo/dev/dilfridge Everything else stays where it is, eg., data/glsa proj/sandbox proj/portage ... Agreed. It used to imply overlays by being called 'git.overlays.gentoo.org'. But but now its just going to be 'git.gentoo.org' And there's proj/ which is frankly dogs breakfast. Re-organising that to be sensible is a bit much to ask at this time. But maybe gentoo can at least start the ball rolling. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] rfc: zsh completions -- optional or mandatory?
On Thursday, March 26, 2015 13:17:02 Rich Freeman wrote: On Thu, Mar 26, 2015 at 12:51 PM, 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. I'd go with this, since this is how we handle bash. Second choice would be to make installing the files USE-conditional (since zsh is less common), but I wouldn't ever add an RDEPEND for zsh. Ditto and +1. Regards, -- Alex Brandt Cloud Evangelist for Rackspace and Developer for Gentoo http://blog.alunduil.com
Re: [gentoo-dev] rfc: zsh completions -- optional or mandatory?
On Thu, Mar 26, 2015 at 1:17 PM, Rich Freeman ri...@gentoo.org wrote: On Thu, Mar 26, 2015 at 12:51 PM, 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. I'd go with this, since this is how we handle bash. I think we should be consistent between bash and other shells here. Either make both bash completion and zsh completion conditional on use flags or make them both unconditional. It makes sense to make exceptions for certain classes of small files (init scripts versus shell completion), but not for specific implementations of small files (bash versus zsh, openrc versus systemd).
