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.13view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/ChangeLog?rev=1.13content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/ChangeLog?r1=1.12r2=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 idel...@gentoo.org
+sendpage-1.1.0-r2.ebuild, + -sendpage-1.1.0-r1.ebuild: +
revbump - EAPI 5, remove old
14 Jun 2012; Zac Medico zmed...@gentoo.org
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.1view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/sendpage-1.1.0-r2.ebuild?rev=1.1content-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
Re: [gentoo-dev] git-r3: initial draft for review
Dnia 2013-09-10, o godz. 07:04:49
Peter Stuge pe...@stuge.se napisał(a):
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?
Could you try your solutions before suggesting them on the list? It's
really something you could try at home in less than 5 minutes, and you
wouldn't have to make noise on the mailing list (not that anyone still
reads it). I think that you testing than would even take less time than
me answering it.
And in case you didn't want to do that: exiting ebuild process in middle
of inheritance chain is *not* a good idea. Portage will even give
an explanatory error for you.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] git-r3: initial draft for review
Michał Górny 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?
exiting ebuild process in middle of inheritance chain is *not* a good idea
I know, that's why I used quotes around the word exit. The question
is of course if there is a usable way to accomplish an early exit in
eclass context. Sad face if not.
//Peter
pgpU7QQybXnvE.pgp
Description: PGP signature
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
On 2013-09-09, at 7:31 PM, Alex Xu alex_y...@yahoo.ca wrote:
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.ebuild3 Sep 2013 21:59:11 -1.3[0;0m
[1;34m+++ gdk-pixbuf-2.28.2.ebuild9 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() {
shouldn't that be EROOT ?
[gentoo-dev] Re: bash-completion-2.1-r1
Duncan 1i5t5.dun...@cox.net wrote: 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 Then why is bash-completion still a global USE-flag? Those few cases where it has a different effect than installing a single file can still use a local flag - are there even such cases at all? How is it with USE=zsh-completion? This is a completely analogous situation. Should both USE-flags be deprecated as global flags?
[gentoo-dev] Re: [PATCH systemd.eclass] Introduce systemd_install_serviced().
Michał Górny wrote:
+systemd_install_serviced() {
+ debug-print-function ${FUNCNAME} ${@}
+
+ local src=${1}
+ local service=${2}
+
+ if [[ ! ${service} ]]; then
+ [[ ${src} == *.conf ]] || die Source file needs .conf suffix
I would hoist this check to before the if.
+ service=${src##*/}
+ service=${service%.conf}
+ fi
+ # avoid potentially common mistake
+ [[ ${service} != *.d ]] || die Service must not have .d suffix
Double-negative reads badly:
[[ $service = *.d ]] die $FUNCNAME: Service must not have .d suffix
Nope. 'insinto' sets INSDESTTREE. Due to lack of proper scoping
support in bash, we need to localize this variable to restore previous
'insinto' scope after leaving the function.
Actually the only reason you are able to do that, is *because* bash has proper
scoping support.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: bash-completion-2.1-r1
On Tue, Sep 10, 2013 at 10:43:53AM +, Martin Vaeth wrote: Duncan 1i5t5.dun...@cox.net wrote: 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 Then why is bash-completion still a global USE-flag? Those few cases where it has a different effect than installing a single file can still use a local flag - are there even such cases at all? How is it with USE=zsh-completion? This is a completely analogous situation. Should both USE-flags be deprecated as global flags? Yes, except for the cases you point out, which if they exist would be covered by a local flag, with a desc explaining how it affects the package. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: [PATCH systemd.eclass] Introduce systemd_install_serviced().
On Tue, Sep 10, 2013 at 12:36 PM, Michał Górny mgo...@gentoo.org wrote: Nope. 'insinto' sets INSDESTTREE. Due to lack of proper scoping support in bash, we need to localize this variable to restore previous 'insinto' scope after leaving the function. Actually the only reason you are able to do that, is *because* bash has proper scoping support. Proper scoping support would actually either disallow something like this or disallow something designed as 'insinto'. The 'local' in bash in the worst thing you could expect. From what I can remember from college, It seems like a pretty typical case of dynamic scope. Why do you find this to be bad?
Re: [gentoo-dev] Re: Improve the security of the default profile
On Sun, 8 Sep 2013 18:06:56 -0600 Ryan Hill dirtye...@gentoo.org wrote: So does anyone have any objections to making -fstack-protector the default? Now is the time to speak up. On PARISC you get plenty of warning of how well it's going to work out: (cc1|gcc|foo): warning: -fstack-protector not supported for this target [enabled by default] jer
[gentoo-dev] gnome2-utils.eclass: Add support new gtk-query-immodules handling introduced in gtk+-2.24.20
We need to handle this in a different way for gtk+-2.24.20 and newer as explained at: https://bugs.gentoo.org/show_bug.cgi?id=476100 The patch is here: https://476100.bugs.gentoo.org/attachment.cgi?id=358136 If you have any problems with it, please tell me so. Thanks
Re: [gentoo-dev] Re: [PATCH systemd.eclass] Introduce systemd_install_serviced().
Dnia 2013-09-10, o godz. 11:57:31
Steven J. Long sl...@rathaus.eclipse.co.uk napisał(a):
Michał Górny wrote:
+systemd_install_serviced() {
+ debug-print-function ${FUNCNAME} ${@}
+
+ local src=${1}
+ local service=${2}
+
+ if [[ ! ${service} ]]; then
+ [[ ${src} == *.conf ]] || die Source file needs .conf suffix
I would hoist this check to before the if.
Any suffix is allowed if ${service} is provided. Specific naming is
required only for service guessing.
+ service=${src##*/}
+ service=${service%.conf}
+ fi
+ # avoid potentially common mistake
+ [[ ${service} != *.d ]] || die Service must not have .d suffix
Double-negative reads badly:
[[ $service = *.d ]] die $FUNCNAME: Service must not have .d suffix
I agree.
Nope. 'insinto' sets INSDESTTREE. Due to lack of proper scoping
support in bash, we need to localize this variable to restore previous
'insinto' scope after leaving the function.
Actually the only reason you are able to do that, is *because* bash has proper
scoping support.
Proper scoping support would actually either disallow something like
this or disallow something designed as 'insinto'. The 'local' in bash
in the worst thing you could expect.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
On 10-09-2013 06:22:38 -0400, Ian Stakenvicius wrote:
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() {
shouldn't that be EROOT ?
and ED in that case too
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] Re: Improve the security of the default profile
On 09/08/2013 08:06 PM, Ryan Hill wrote: On Sat, 07 Sep 2013 19:08:57 -0400 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: Personally I think this would be a great stepping stone. If we add - -fstack-protector to 4.8.1 it will improve security (only a little I know) and give us an idea of what issues we may have. After a short enjoyment of fixing any issues which come up we could more to - -fstack-protector-strong in 4.9. Okay it won't be available for 4.8.1. It's going to require a couple minor glibc changes and a lot of testing. A bunch of packages stick workarounds behind a hardened USE flag or do things like `filter-flags -fstack-protector` which don't actually work (we have to patch the compiler, not just add it to the default flags in the profiles or something). I need to check the interactions with hardened's spec files. And I need to get 4.8.1 out the door two weeks ago. Once we fix the fallout from the unmasking I'll get back to this. I also want to make a comment on the implications of this change that people may not have considered. Bugs caused by -fstack-protector can no longer be just dismissed as unsupported, invalid, or assigned to the hardened team and forgotten about. 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. So does anyone have any objections to making -fstack-protector the default? Now is the time to speak up. (and for the record I've changed my mind and would like to see this go forward, so please stop emailing me) A few thoughts: 1. The kernel expects -fno-stack-protector to be the default. What will the effect be on kernel configuration once -fstack-protector is the default? 2. We should make sure that -fno-stack-protector is a supported CFLAG. This will make it easier to handle complaints from the vocal minority of our user base that want every last percentage point of performance. 3. I would like to point out that we are talking about deviating from upstream behavior and everyone is okay with it. Anyone who thinks we should stick to upstream when it is not good for us should speak now or risk being asked where were you when... whenever they try to use upstream as an excuse to hold back progress. ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Improve the security of the default profile
On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao r...@gentoo.org wrote: 1. The kernel expects -fno-stack-protector to be the default. What will the effect be on kernel configuration once -fstack-protector is the default? Nothing, since the kernel build system doesn't source make.conf. If somebody creates an ebuild that actually installs a kernel then it might be an issue, though it could be filtered if it is a problem. 2. We should make sure that -fno-stack-protector is a supported CFLAG. This will make it easier to handle complaints from the vocal minority of our user base that want every last percentage point of performance. No reason that it would be any less supported than -fstack-protector already is. 3. I would like to point out that we are talking about deviating from upstream behavior and everyone is okay with it. Anyone who thinks we should stick to upstream when it is not good for us should speak now or risk being asked where were you when... whenever they try to use upstream as an excuse to hold back progress. ;) I don't really see this as an issue - in general maintainers are expected to accommodate reasonable CFLAGS. This doesn't mean that arbitrary CFLAGS are supported so much as bugs should be taken seriously if they're really bugs. If -fstack-protector causes serious problems and this is inherent to the nature of the package/etc then just filter it. If it causes problems because upstream isn't doing things right, then this is no different than how things were 10 years ago when we were stomping out amd64 issues left and right (not working on amd64 wasn't a reason to mask a package for x86, but we didn't accept upstream doesn't care about amd64 as an excuse). Staying close to upstream is a good philosophy in general. I don't think that means that we can't have reasonable CFLAGS. Otherwise we wouldn't set CFLAGS at all and would just use whatever defaults the upstream build system applies. We're a distro - doing integration work is a value-add, not a sin. If we aren't doing integration, then users might as well just do Linux-from-scratch. Rich
[gentoo-dev] Re: Improve the security of the default profile
Rich Freeman posted on Tue, 10 Sep 2013 21:17:33 -0400 as excerpted: On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao r...@gentoo.org wrote: 1. The kernel expects -fno-stack-protector to be the default. What will the effect be on kernel configuration once -fstack-protector is the default? Nothing, since the kernel build system doesn't source make.conf. If somebody creates an ebuild that actually installs a kernel then it might be an issue, though it could be filtered if it is a problem. If I'm not mistaken, dirtyepic intends to patch gcc directly to enable -fstack-protector, changing the default at that level so it'll be used unless -fno-stack-protector is in CFLAGS. At least, that's how I interpret (dirtyepic): 'filter-flags -fstack-protector [won't] actually work (we have to patch the compiler, not just add it to the default flags in the profiles or something). Which means that yes, it WILL affect the kernel (and anything else separately compiled, unless -fno-stack-protector is given), since it'll then be the gentoo-patched gcc default, not in make.conf. (Tho jer points out that the parisc arch, among others, won't work with that flag at all, and warns to that effect. So I guess the patch will etiher be ifdeffed not to apply on such archs or will be conditionally applied in the first place. The former is I believe preferred as conditional patching is considered subpar.) I guess hardened should know what -fstack-protector does to the kernel, tho. But in any case it's certainly worth a news item when it happens, as people obviously build a lot of stuff with gcc independent of the tree, and I'm sure some of it will break if that becomes the default, so letting them know about it with a news item should help avoid at least /some/ of the resulting bugs from such a default-change. -- 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 Tue, 10 Sep 2013 18:41:34 -0400 Richard Yao r...@gentoo.org wrote: A few thoughts: 1. The kernel expects -fno-stack-protector to be the default. What will the effect be on kernel configuration once -fstack-protector is the default? The kernel has supported building with -fstack-protector since 2.6.19, (at least on x86/x86-64). It's controlled by CONFIG_CC_STACKPROTECTOR and if it's disabled then -fno-stack-protector is explicitly added to the command line. 2. We should make sure that -fno-stack-protector is a supported CFLAG. This will make it easier to handle complaints from the vocal minority of our user base that want every last percentage point of performance. If by supported you mean that they won't be removed by things like strip-flags, then yes, -fstack-protector -fstack-protector-all -fno-stack-protector and -fno-stack-protector-all are all on the whitelist. 3. I would like to point out that we are talking about deviating from upstream behavior and everyone is okay with it. Anyone who thinks we should stick to upstream when it is not good for us should speak now or risk being asked where were you when... whenever they try to use upstream as an excuse to hold back progress. ;) In this case it seems every other distro is already doing this, so we're in good company. -- 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
