[gentoo-dev] bash-completion-2.1-r1
Hello, all. I'd like to ask finally: who feels himself responsible for deploying bashcomp-2.1-r1? Does he have any kind of plan? Does anyone care at all? Do I have to say it's pretty far from professional to commit it half-working, with no clear information how to proceed, neither for users nor for developers? As far as I can see, there were mostly either random patches or random bugs, with no clear generic guidelines. I have enough projects on my back but I guess I'll end up carrying this mess if nobody bothers to do so. For future reference, I so far know the following: 1. bash supports two directories for completions: completionsdir (/usr/.../completions) and compatdir (/etc). gentoo added a third directory that i will call gentoodir (/usr/.../bash-completion). 2. bash sources all files in compatdir (at start?). 3. eselect used to symlink stuff from $gentoodir to $compatdir to enable completions. therefore, all enabled stuff polluted the environment all the time. 4. files in completionsdir are sourced when command matching filename is typed in. that is 'foo ' -> "$completionsdir/foo" is sourced. 5. in order for completionsdir to work, /usr/share/bash-completion/bash_completion must be sourced first. (is this just me? is this something to be done in global bashrc?) Aside to the above, what needs to be answered: 1. how to properly disable completions the 'new way'? 2. do we want to support adding stuff to $compatdir? what do we do with completions that don't fit $completionsdir? 3. how do we handle completion 'dependencies'? the 'old way' just relied on them being sourced from $compatdir early. do we source them explicitly now? do we put them in $compatdir unconditionally? 4. do we want to maintain eselect for bash completions? do we want it to handle disabling and 'enabling' completions the 'new way'? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] bash-completion-2.1-r1
On 09/09/13 12:24, Michał Górny wrote: Hello, all. I'd like to ask finally: who feels himself responsible for deploying bashcomp-2.1-r1? Does he have any kind of plan? Does anyone care at all? 2.1-r1 works great here and I don't see any other work left than maybe a wiki page for instructing people howto use `complete` like `complete -r` to remove unwanted completions that cause grief in the way people want to use the command and you don't need to disable completions to get the filename instead, bash-completion supports... (from README, first entry in FAQ) Q. The bash completion code inhibits some commands from completing on files with extensions that are legitimate in my environment. Do I have to disable completion for that command in order to complete on the files that I need to? A. No. Use M-/ to (in the words of the man page) attempt file name completion on the text to the left of the cursor. This will circumvent any file type restrictions put in place by the bash completion code. Do I have to say it's pretty far from professional to commit it half-working, with no clear information how to proceed, neither for users nor for developers? As far as I can see, there were mostly either random patches or random bugs, with no clear generic guidelines. I have enough projects on my back but I guess I'll end up carrying this mess if nobody bothers to do so. For future reference, I so far know the following: 1. bash supports two directories for completions: completionsdir (/usr/.../completions) and compatdir (/etc). gentoo added a third directory that i will call gentoodir (/usr/.../bash-completion). 2. bash sources all files in compatdir (at start?). 3. eselect used to symlink stuff from $gentoodir to $compatdir to enable completions. therefore, all enabled stuff polluted the environment all the time. 4. files in completionsdir are sourced when command matching filename is typed in. that is 'foo ' -> "$completionsdir/foo" is sourced. 5. in order for completionsdir to work, /usr/share/bash-completion/bash_completion must be sourced first. (is this just me? is this something to be done in global bashrc?) yes, that's the way to enable bash completion support per user just like documented in top of README Aside to the above, what needs to be answered: 1. how to properly disable completions the 'new way'? something like http://blog.onetechnical.com/2012/06/19/disable-bash-autocompletion-on-ubunt/ should be replicated at wiki.gentoo.org 2. do we want to support adding stuff to $compatdir? why not, does something need this? what do we do with completions that don't fit $completionsdir? like? some old format of bash completion files that don't work if not sourced directly? should be treated like other bugs, ie. treat it as a bug, report upstream of the file, patch the file if not possible, put them in the compatdir? didn't tackle the compatdir issue yet because nothing obvious needed it, surely adding extra eclass code is on need-basis... :/ 3. how do we handle completion 'dependencies'? the 'old way' just relied on them being sourced from $compatdir early. do we source them explicitly now? do we put them in $compatdir unconditionally? 4. do we want to maintain eselect for bash completions? do we want it to handle disabling and 'enabling' completions the 'new way'? eselect module seems unnecessary, when you can disable them using `complete` and the list of completions you get by `ls` :P but like I said before, it's still doable if someone wants to add another layer, I just don't see any value in that... so seems like people who claim 2.1-r1 is somehow broken or half-working didn't read README, and insist on ready wiki page also for ~arch users?
Re: [gentoo-dev] bash-completion-2.1-r1
Dnia 2013-09-09, o godz. 12:50:03 Samuli Suominen napisał(a): > On 09/09/13 12:24, Michał Górny wrote: > > Do I have to say it's pretty far from professional to commit it > > half-working, with no clear information how to proceed, neither for > > users nor for developers? As far as I can see, there were mostly either > > random patches or random bugs, with no clear generic guidelines. > > > > I have enough projects on my back but I guess I'll end up carrying this > > mess if nobody bothers to do so. > > > > > > For future reference, I so far know the following: > > > > 1. bash supports two directories for completions: completionsdir > > (/usr/.../completions) and compatdir (/etc). gentoo added a third > > directory that i will call gentoodir (/usr/.../bash-completion). > > > > 2. bash sources all files in compatdir (at start?). > > > > 3. eselect used to symlink stuff from $gentoodir to $compatdir to > > enable completions. therefore, all enabled stuff polluted > > the environment all the time. > > > > 4. files in completionsdir are sourced when command matching filename > > is typed in. that is 'foo ' -> "$completionsdir/foo" is sourced. > > > > 5. in order for completionsdir to work, > > /usr/share/bash-completion/bash_completion must be sourced first. > > (is this just me? is this something to be done in global bashrc?) > > yes, that's the way to enable bash completion support per user just like > documented in top of README > > > Aside to the above, what needs to be answered: > > > > 1. how to properly disable completions the 'new way'? > > something like > http://blog.onetechnical.com/2012/06/19/disable-bash-autocompletion-on-ubunt/ > should be replicated at wiki.gentoo.org Did you actually try that? Trying plain: complete -r git it removes git completion indeed. But when I type 'git ', it is loaded back :). > > 2. do we want to support adding stuff to $compatdir? > > why not, does something need this? I don't know. Maybe. Like git-prompt, though I'd rather move that out of topic of bash-completion, maybe instead some kind of bashrc.d. > > what do we do with completions that don't fit $completionsdir? > > like? some old format of bash completion files that don't work if not > sourced directly? > should be treated like other bugs, ie. treat it as a bug, report > upstream of the file, patch the file > if not possible, put them in the compatdir? > > didn't tackle the compatdir issue yet because nothing obvious needed it, > surely adding extra eclass code is on need-basis... :/ Ok then, will report bugs. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: Improve the security of the default profile
Ryan Hill wrote: > > You will be expected to fix them, and `append-flags > -fno-stack-protector` is not an acceptable fix. I guess there might be some projects with special assembler code where this is the only possiblity. For your information, I attach my list of packages (of about 1400 installed ones) for which I had seen a reason to exclude them from -fstack-protector The reasons why they are in the list, I forgot long ago; might be failure of some version with ARCH=x86 or ARCH=amd64 or just carefulness like for grub: app-emulation/wine dev-libs/klibc media-gfx/splashutils sys-apps/texinfo sys-apps/v86d sys-boot/grub sys-devel/llvm In addition also: sys-libs/glibc sys-devel/gcc (for the latter, I found an old note that www-plugins/nspluginwrapper failed on amd64 if gcc itself was compiled with -fstack-protector; I guessed some multilib issue but never examined).
Re: [gentoo-dev] Re: Improve the security of the default profile
On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill wrote: > You will be expected to fix them, and `append-flags > -fno-stack-protector` is not an acceptable fix. You can't champion for more > secure defaults and then just disable them when they get in your way. Why not? Surely a system where 99.9% of the packages installed are hardened is more secure than a system where 0% of the packages installed are hardened. > So does anyone have any objections to making -fstack-protector the default? > Now is the time to speak up. So, in this world of all-or-nothing we want people who realize that 100% protection might not be possible to raise an objection so that we end up with 0% protection instead? Why not just do the sensible thing (IMHO) and make it a default, and then if it doesn't work for an individual package deal with it on an individual basis? We already encourage maintainers to try to get custom CFLAGS to work when practical, but when not practical we filter them. I don't see stack protection as any different. If there is a fix, then fix it, and if not, then disable it. I don't see a lack of stack-protection as a reason to keep something out of the tree. Rich
[gentoo-dev] Re: bash-completion-2.1-r1
On 09/09/13 13:05, Michał Górny wrote: Dnia 2013-09-09, o godz. 12:50:03 Samuli Suominen napisał(a): On 09/09/13 12:24, Michał Górny wrote: 1. how to properly disable completions the 'new way'? something like http://blog.onetechnical.com/2012/06/19/disable-bash-autocompletion-on-ubunt/ should be replicated at wiki.gentoo.org Did you actually try that? Trying plain: complete -r git it removes git completion indeed. But when I type 'git ', it is loaded back :). You can disable the "bash-completion" USE flag of dev-vcs/git. This isn't a real solution, of course, since you need to recompile the whole package every time you want to disable or enable bash completion. But if you don't intend to actually ever use Git's completion, then this should work.
Re: [gentoo-dev] Re: bash-completion-2.1-r1
Dnia 2013-09-09, o godz. 18:12:08 Nikos Chantziaras napisał(a): > On 09/09/13 13:05, Michał Górny wrote: > > Dnia 2013-09-09, o godz. 12:50:03 > > Samuli Suominen napisał(a): > > > >> On 09/09/13 12:24, Michał Górny wrote: > >>> 1. how to properly disable completions the 'new way'? > >> > >> something like > >> http://blog.onetechnical.com/2012/06/19/disable-bash-autocompletion-on-ubunt/ > >> should be replicated at wiki.gentoo.org > > > > Did you actually try that? > > > > Trying plain: > > > >complete -r git > > > > it removes git completion indeed. But when I type 'git ', it is > > loaded back :). > > You can disable the "bash-completion" USE flag of dev-vcs/git. This > isn't a real solution, of course, since you need to recompile the whole > package every time you want to disable or enable bash completion. But > if you don't intend to actually ever use Git's completion, then this > should work. And it is a bug since completions are supposed to be installed indep of USE flags. But above all, I'm pointing out that we're pointing users towards a solution that simply does not work. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] RFC: directory-based wrapping of Python scripts
Hello, all.
I've been working on solving the issues we had with Python script
wrapping. I'd like to present the best solution I could think of, along
with a technical demo, and ask for your opinion.
Wrapping Python scripts currently involves renaming them through
appending ${EPYTHON} suffix. This change in filename sometimes results
in unexpected results, especially with packages that use sys.argv[0].
This breaks mis-designed packages such as gentoolkit or pkgcore,
and often results in unexpected help output.
It should be noted that kernel has special behavior wrt shebangs,
and modifies argv[0] when they are involved. Therefore 'simple' setting
of argv[0] for exec*() calls in the wrapper doesn't help here.
In the past, python.eclass used Gentoo-specific patches to Python to
work around those issues, and overriding sys.argv[0] on Python-side.
python-r1 no longer uses those patches, and we will hopefully drop them
after getting rid of python.eclass.
The new way would involve moving them into dedicated directory instead.
That is:
old way: /usr/bin/foo-pythonX.Y
new way: /usr/lib/python-bin/pythonX.Y/foo
While this still involves changing argv[0], it has a few advantages
over the current solution:
1. basename(sys.argv[0]) stays unchanged. this fixes gentoolkit,
pkgcore and makes 'foo --help' output 'foo'.
2. PATH is no longer polluted by a dozen of foo-* variants. While some
people may consider this a disadvantage, it makes bash completion
a little less irritating at least. It also avoids having sub-commands
like 'git bz-python2.7' :).
3. variant choice can be implemented purely using PATH adjustments.
That is, in a very optimistic case the wrapper scripts wouldn't need to
be called.
If you'd like to test it, I'm attaching a complete patch that should
work on top of current tree. It modifies the python eclasses and adds
a new slot to python-exec. The same changesets can be found on
python-script-location-r1 branch of my gx86-working-tree repo [1].
It should be noted that while the eclass changes on that branch can be
considered testing-ready, the C wrapper code is a quick, dirty hack
and will be rewritten in the future if we decide to go this way.
Currently known issues with the demo:
1. the few ebuilds that try to play with wrappers directly do not work
because they rely on old paths (dev-python/wxpython),
2. parallel 'doins' is broken in portage [2] which can break a few
more ebuilds (dev-python/docutils),
3. baselayout doesn't provide a way to prepend paths before
the standard set [3], so the wrapper are always used indep of PATH.
[1]:https://bitbucket.org/mgorny/gx86-working-tree/commits/branch/python-script-location-r1
[2]:https://bugs.gentoo.org/show_bug.cgi?id=484332
[3]:https://bugs.gentoo.org/show_bug.cgi?id=484268
Please let me know what you think of this solution. It could be
implemented mostly safely since the 'old' and 'new' wrappers can
co-exist on the system.
--
Best regards,
Michał Górny
diff --git a/gx86/dev-python/python-exec/Manifest b/gx86/dev-python/python-exec/Manifest
index 8cf6142..daa6d72 100644
--- a/gx86/dev-python/python-exec/Manifest
+++ b/gx86/dev-python/python-exec/Manifest
@@ -1,29 +1,11 @@
--BEGIN PGP SIGNED MESSAGE-
-Hash: SHA512
-
DIST python-exec-0.2.tar.bz2 65466 SHA256 df61ec2968930016dd14d5d1c5f12b5e501bc572bfe07f07e294906070e144fc SHA512 5f66eadedc9acfb915f830d8d8d16c2645d5f22f65fa0bfc9eb0ae77061c51484e07b98edcceb0b0cf6143c246cd3fa8f95b03c89b14e1fb1f0a6951a301d806 WHIRLPOOL 33e797f0bd3a259e8850a054c94c6cb68a32836e02a7a142de11bf8c838e6dab230f368d53fb4928dd62869794ec4ee84ba6c4bbdd0c8a60dce9c83759d23cd0
DIST python-exec-0.3.1.tar.bz2 74441 SHA256 460837775167108419b9497353a6f832fc8a249c341469dd235c70633ac37557 SHA512 764d1aaf3b4f9679be6ab1105b4b4d9222b245502114ee3d451b4507f86679ae05136eeae3337351c80b52ee03b9461a2f89c87e63cc4cbb76a1023fb243f84e WHIRLPOOL 6b34c2f44976a33a67269c766bd13401b6b1b39fad3d5df6bbef2bd06e15e09bd2ac13123718b8fa0bdb67f812c7407192b9c16860ab442d3c35259afeb3da82
DIST python-exec-0.3.tar.bz2 73698 SHA256 3d593d3d06d2a05b90be014577c7d096e30dbe093176cc69c9c7a8deb00c0d7a SHA512 d52497dc81a72550da1c461d8e26fe9640ea02c2b8a8f2437ef4a714a007717d4eaf3508e22569b6693b38caea41934cfc057a398b9d5f5a3cff35c7ad52629a WHIRLPOOL 5b0aaeb20915b9190f648bf552f72842a329c10f1eafcdde3e118ef442a94d309b26462447f1ff42e561a86fb798e5de3478a7c06298f86ca66f5e4699dc1fde
EBUILD python-exec-0.2.ebuild 1089 SHA256 ee151de72bc789ea1c4e74418fbdb0150b4ae02ed4f96118116fc8f530f4e82c SHA512 2c7c518fb34c0cfc131917571219ddd6f5c6c1b3efd3e78332eaa08f3a57770954f7090d66655c7c02d5a0edfefe90e4debbd615ed05d151aae0ca9d0cbe4143 WHIRLPOOL 70163f1fc2364db548dd7878ff13311911dc7ada81b1e705bcee7b808d963a8371870cb7f29f5cbc133756e4e0fe3a0b6673fa8428643dffa2c9ca7f9cdcd759
EBUILD python-exec-0.3.1.ebuild 1088 SHA256 f76f577167aa049d36d99dfb8975938753c5d9b33c221768757359ebe95a0024 SHA512 97c8077874c8be68cdc619a55c707c69b686c2543cb3761023acfeea4968e38ee193b3634e04742fbb08e336208
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
As a follow up to this discussion, I came with the attached patch. It
appears to work ok for regular merges and binpkg merges with
FEATURES="collision-protect".
Per my reading of PMS it does not appear to violate anything so I guess
it is ok.
--
Gilles Dartiguelongue
Gentoo
[1;32mIndex: gdk-pixbuf-2.28.2.ebuild[0;0m
[1;32m===[0;0m
[1;32mRCS file: /var/cvsroot/gentoo-x86/x11-libs/gdk-pixbuf/gdk-pixbuf-2.28.2.ebuild,v[0;0m
[1;32mretrieving revision 1.3[0;0m
[1;32mdiff -u -B -r1.3 gdk-pixbuf-2.28.2.ebuild[0;0m
[1;31m--- gdk-pixbuf-2.28.2.ebuild 3 Sep 2013 21:59:11 - 1.3[0;0m
[1;34m+++ gdk-pixbuf-2.28.2.ebuild 9 Sep 2013 22:28:20 -[0;0m
[1;35m@@ -67,6 +67,15 @@[0;0m
[0;0m [0;0m
[0;0m pkg_preinst() {[0;0m
[0;0m gnome2_gdk_pixbuf_savelist[0;0m
[1;34m+[0;0m
[1;34m+ # Make sure loaders.cache belongs to gdk-pixbuf alone[0;0m
[1;34m+ local cache="usr/$(get_libdir)/${PN}-2.0/2.10.0/loaders.cache"[0;0m
[1;34m+[0;0m
[1;34m+ if [[ -e ${ROOT}${cache} ]]; then[0;0m
[1;34m+ cp "${ROOT}"${cache} "${D}"/${cache} || die[0;0m
[1;34m+ else[0;0m
[1;34m+ touch "${D}"/${cache} || die[0;0m
[1;34m+ fi[0;0m
[0;0m }[0;0m
[0;0m [0;0m
[0;0m pkg_postinst() {[0;0m
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/10/2013 02:29 AM, Gilles Dartiguelongue wrote: > As a follow up to this discussion, I came with the attached patch. > It appears to work ok for regular merges and binpkg merges with > FEATURES="collision-protect". > > Per my reading of PMS it does not appear to violate anything so I > guess it is ok. > unreadable diff -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSLldDAAoJEFpvPKfnPDWzAlEIAKieKaMfao/xpimPOWShEZZW AedAHki/r5b4IsZBYeE3m971SBWXMYvL4W7KAGPiLHeUzKXzN6wYLLx5Bru/uWnP Gh7WYYnCq93Z9VnPXeeUd6Cau7cNSdcMEfjE4BRA06aNu2KSdXV3rC5PTTVM5KX0 VJ9BgjzvCs9YDzv2pmsBthoVAZv4zqrpDXLJJD6yzCyFQN/rHntnzij3aYUEAGVu 99axU7nWUrbBFOQ4C+J0ANSS1gkd+rmFudWnQ9pBpzPpPD4aQUwLTFc6+bf3Beho jeD8TVAkUqr5OcuF278E0Rg0nqN/rvi8wglbO6855NTYi1SdNRJncujzOmc2gNI= =DDxq -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
On 09/09/13 08:29 PM, Gilles Dartiguelongue wrote:
>
> [1;32mIndex: gdk-pixbuf-2.28.2.ebuild[0;0m
> [1;32m===[0;0m
> [1;32mRCS file:
> /var/cvsroot/gentoo-x86/x11-libs/gdk-pixbuf/gdk-pixbuf-2.28.2.ebuild,v[0;0m
> [1;32mretrieving revision 1.3[0;0m
> [1;32mdiff -u -B -r1.3 gdk-pixbuf-2.28.2.ebuild[0;0m
> [1;31m--- gdk-pixbuf-2.28.2.ebuild 3 Sep 2013 21:59:11 -
> 1.3[0;0m
> [1;34m+++ gdk-pixbuf-2.28.2.ebuild 9 Sep 2013 22:28:20 -[0;0m
> [1;35m@@ -67,6 +67,15 @@[0;0m
> [0;0m [0;0m
> [0;0m pkg_preinst() {[0;0m
> [0;0mgnome2_gdk_pixbuf_savelist[0;0m
> [1;34m+[0;0m
> [1;34m+ # Make sure loaders.cache belongs to gdk-pixbuf alone[0;0m
> [1;34m+ local
> cache="usr/$(get_libdir)/${PN}-2.0/2.10.0/loaders.cache"[0;0m
> [1;34m+[0;0m
> [1;34m+ if [[ -e ${ROOT}${cache} ]]; then[0;0m
> [1;34m+ cp "${ROOT}"${cache} "${D}"/${cache} || die[0;0m
> [1;34m+ else[0;0m
> [1;34m+ touch "${D}"/${cache} || die[0;0m
> [1;34m+ fi[0;0m
> [0;0m }[0;0m
> [0;0m [0;0m
> [0;0m pkg_postinst() {[0;0m
Index: gdk-pixbuf-2.28.2.ebuild
===
RCS file:
/var/cvsroot/gentoo-x86/x11-libs/gdk-pixbuf/gdk-pixbuf-2.28.2.ebuild,v
retrieving revision 1.3
diff -u -B -r1.3 gdk-pixbuf-2.28.2.ebuild
--- gdk-pixbuf-2.28.2.ebuild3 Sep 2013 21:59:11 - 1.3
+++ gdk-pixbuf-2.28.2.ebuild9 Sep 2013 22:28:20 -
@@ -67,6 +67,15 @@
pkg_preinst() {
gnome2_gdk_pixbuf_savelist
+
+ # Make sure loaders.cache belongs to gdk-pixbuf alone
+ local cache="usr/$(get_libdir)/${PN}-2.0/2.10.0/loaders.cache"
+
+ if [[ -e ${ROOT}${cache} ]]; then
+ cp "${ROOT}"${cache} "${D}"/${cache} || die
+ else
+ touch "${D}"/${cache} || die
+ fi
}
pkg_postinst() {
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: bash-completion-2.1-r1
Michał Górny posted on Mon, 09 Sep 2013 17:18:50 +0200 as excerpted: > Dnia 2013-09-09, o godz. 18:12:08 Nikos Chantziaras > napisał(a): > >> On 09/09/13 13:05, Michał Górny wrote: >> > >> > Trying plain: >> > >> >complete -r git >> > >> > it removes git completion indeed. But when I type 'git ', it is >> > loaded back :). >> >> You can disable the "bash-completion" USE flag of dev-vcs/git. This >> isn't a real solution, of course, since you need to recompile the whole >> package every time you want to disable or enable bash completion. But >> if you don't intend to actually ever use Git's completion, then this >> should work. > > And it is a bug since completions are supposed to be installed indep of > USE flags. Indeed. The general gentoo policy is that "trivial" files such as bash- completions, systemd unit files, etc, aren't to be install-controlled via USE flags, for exactly the reason given -- the cost of rebuilding the entire package just to change one's mind is considered too high to pay for the "trivial" amount of space taken by such files, particularly so when people who /really/ care about it already have the install-mask solution available. However, that totally skirts another problem as well. If one user on a system wants completion and another doesn't, installation-control isn't going to cut it. That's a problem that per-user eselect bash-completion USED to address, but doesn't with the new bash-completion. -- 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] Re: Improve the security of the default profile
On Mon, 9 Sep 2013 08:21:35 -0400 Rich Freeman wrote: > On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill wrote: > > So does anyone have any objections to making -fstack-protector the default? > > Now is the time to speak up. > > So, in this world of all-or-nothing we want people who realize that > 100% protection might not be possible to raise an objection so that we > end up with 0% protection instead? No, all I've heard so far is support and wanted to give anyone with an opposing viewpoint a chance to speak up. I support it, but if there are any problems we might run into it's best we know about them beforehand, no? I wasn't looking for a reason to veto it. > Why not just do the sensible thing (IMHO) and make it a default, and > then if it doesn't work for an individual package deal with it on an > individual basis? We already encourage maintainers to try to get > custom CFLAGS to work when practical, but when not practical we filter > them. I don't see stack protection as any different. If there is a > fix, then fix it, and if not, then disable it. I don't see a lack of > stack-protection as a reason to keep something out of the tree. Rich, that's exactly what I'm saying. We have to make an effort to fix things properly, like we do with any supported feature. That's something I see as one of the key strengths of this group we have. Obviously there are cases where a fix isn't possible (glibc and gcc itself are prime examples) and we need to disable it. That's fine. But we need to discourage people sweeping problems under the rug because they're inconvenient, especially when those problems may indicate security issues. I'm just trying to set proper expectations - that this change may break people's packages, and they may have to do some work to find out why and how to fix it. I don't like creating more work for people, so I want to be sure there is consensus on this first. So far it sounds like there is. -- 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: Improve the security of the default profile
Ryan Hill wrote: > I don't like creating more work for people, so I want to be sure > there is consensus on this first. So far it sounds like there is. I think there will come enough objections, but only down the road, and only from people who don't want to care about quality. Don't let that stop the improvements from happening. Thanks //Peter pgpVL39G_2RCE.pgp Description: PGP signature
Re: [gentoo-dev] git-r3: initial draft for review
Markos Chandras wrote:
> the whole eclass is inside the " if [[ ! ${_GIT_R3} ]] " block.
Rather than putting the whole eclass inside a block like that maybe
it's possible to test for that condition and "exit" early?
//Peter
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-dialup/sendpage: sendpage-1.1.0-r2.ebuild ChangeLog sendpage-1.1.0-r1.ebuild
04.09.2013 18:01, Ian Stakenvicius пишет:
> On 04/09/13 01:28 AM, Sergey Popov wrote:
>> 02.09.2013 19:29, Ian Delaney (idella4) пишет:
>>> idella4 13/09/02 15:29:57
>>>
>>> Modified: ChangeLog Added:
>>> sendpage-1.1.0-r2.ebuild Removed:
>>> sendpage-1.1.0-r1.ebuild Log: revbump -> EAPI 5, remove old
>>>
>>> (Portage version: 2.2.0/cvs/Linux x86_64, signed Manifest commit
>>> with key 0xB8072B0D)
>>>
>>> Revision ChangesPath 1.13
>>> net-dialup/sendpage/ChangeLog
>>>
>>> file :
>>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/ChangeLog?rev=1.13&view=markup
>>>
>>>
> plain:
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/ChangeLog?rev=1.13&content-type=text/plain
>>> diff :
>>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/ChangeLog?r1=1.12&r2=1.13
>>>
>>>
>>>
> Index: ChangeLog
>>> ===
>>>
>>>
> RCS file: /var/cvsroot/gentoo-x86/net-dialup/sendpage/ChangeLog,v
>>> retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12
>>> -r1.13 --- ChangeLog14 Jun 2012 01:50:05 - 1.12 +++
>>> ChangeLog 2 Sep 2013 15:29:57 - 1.13 @@ -1,6 +1,12 @@ #
>>> ChangeLog for net-dialup/sendpage -# Copyright 2000-2012 Gentoo
>>> Foundation; Distributed under the GPL v2 -# $Header:
>>> /var/cvsroot/gentoo-x86/net-dialup/sendpage/ChangeLog,v 1.12
>>> 2012/06/14 01:50:05 zmedico Exp $ +# Copyright 2000-2013 Gentoo
>>> Foundation; Distributed under the GPL v2 +# $Header:
>>> /var/cvsroot/gentoo-x86/net-dialup/sendpage/ChangeLog,v 1.13
>>> 2013/09/02 15:29:57 idella4 Exp $ + +*sendpage-1.1.0-r2 (02 Sep
>>> 2013) + + 02 Sep 2013; Ian Delaney
>>> +sendpage-1.1.0-r2.ebuild, + -sendpage-1.1.0-r1.ebuild: +
>>> revbump -> EAPI 5, remove old
>>>
>>> 14 Jun 2012; Zac Medico
>>> sendpage-1.1.0-r1.ebuild: inherit user for enewgroup and
>>> enewuser
>>>
>>>
>>>
>>> 1.1
>>> net-dialup/sendpage/sendpage-1.1.0-r2.ebuild
>>>
>>> file :
>>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/sendpage-1.1.0-r2.ebuild?rev=1.1&view=markup
>>>
>>>
> plain:
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/sendpage-1.1.0-r2.ebuild?rev=1.1&content-type=text/plain
>>>
>>> Index: sendpage-1.1.0-r2.ebuild
>>> ===
>>>
>>>
> # Copyright 1999-2013 Gentoo Foundation
>>> # Distributed under the terms of the GNU General Public License
>>> v2 # $Header:
>>> /var/cvsroot/gentoo-x86/net-dialup/sendpage/sendpage-1.1.0-r2.ebuild,v
>>> 1.1 2013/09/02 15:29:57 idella4 Exp $
>>>
>>> EAPI=5
>>>
>>> inherit perl-module eutils user
>>>
>>> MY_P=${PN}-1.001 DESCRIPTION="Dialup alphapaging software."
>>> HOMEPAGE="http://www.sendpage.org/";
>>> SRC_URI="http://www.sendpage.org/download/${MY_P}.tar.gz";
>>> S="${WORKDIR}/${MY_P}"
>>>
>>> LICENSE="GPL-2" SLOT="0" KEYWORDS="~amd64 ~ppc ~x86" # This
>>> package warrants IUSE doc IUSE=""
>>>
>>> DEPEND="!net-misc/hylafax >=dev-perl/Device-SerialPort-0.13
=dev-perl/MailTools-1.44 >=virtual/perl-libnet-1.11
=dev-perl/Net-SNPP-1.13 dev-perl/DBI"
>>>
>>> mydoc="FEATURES email2page.conf sendpage.cf snpp.conf"
>>>
>>> pkg_setup() { enewgroup sms enewuser sendpage -1 -1
>>> /var/spool/sendpage sms }
>>>
>>> PATCHES=( "${FILESDIR}"/${PV}-makefile.patch )
>>>
>>> src_install() { perl-module_src_install insinto /etc doins
>>> sendpage.cf newinitd "${FILESDIR}"/sendpage.initd sendpage
>>> diropts -o sendpage -g sms -m0770 keepdir /var/spool/sendpage #
>>> Separate docs/ content from ${mydoc[@]} docompress -x
>>> /usr/share/doc/${PF}/text/ docinto text/ dodoc docs/* }
>>>
>>>
>>>
>>>
>
>> EAPI=5 has no implicit RDEPEND="${DEPEND}". Does this package
>> really has no run-time dependendies?
>
>
>
> Well, perl-module.eclass adds an RDEPEND of dev-lang/perl , so there's
> that. If it's just perl scripts, though (and I haven't checked if it
> is or not), then that probably would be the only hard RDEPEND...
>
Package contents are EXACTLY the perl scripts that needs specified
modules in runtime. Fixed that now.
--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead
signature.asc
Description: OpenPGP digital signature
