Re: [gentoo-dev] Please review fortran-2.eclass next round
Thanks again Mike for an extended review. Some replies on your comments
everything else is directly excepted.
On 17/06/11 05:03, Mike Frysinger wrote:
# @ECLASS: fortran-2.eclass
i dont see fortran.eclass. what's with the -2 ?
There was a fortran eclass, which did completely different things. In
order to not break an ancient package (outside the tree) I decided to
go to the new name, which also underlines the new functionality.
DEPEND=virtual/fortran
RDEPEND=${DEPEND}
i'm not sure that RDEPEND is correct. do all fortran compilers additionally
require the fortran compiler to be available at runtime ?
I will evaluate this and fix it accordingly. But I see difficulties, if
it is mixed. Best would be to fix that in virtual/fortran
# internal function
use the @INTERNAL tag and proper eclass documentation
I wasn't aware of that. We are lacking any documentation about the
proper documentation for manpages in all eclass writing guides.
(( ${ret} )) || break
a little odd syntax, but i guess it works ...
I don't know any other way how I can jump out of the loop. The complete
things simulates the autoconf behavior.
although i wonder why you're not using tc-getF77 ...
Because tc-getF77 is only different to tc-getFC if F77 is set. And this
is tested for before.
ewarn The support for EAPI=${EAPI} by the fortran-2.eclass
why ? it's causing you no real trouble to do so
The suggestion was to only support EAPI=4. I don't like this completely
as all fortran packages should directly use the eclass in order to make
it smooth for users. The delay should give some time to come up with
stable versions for all fortran packages at EAPI=4, but allow the use in
every ebuild right away.
-mike
Thank you very much,
justin
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Please review fortran-2.eclass next round
On Friday, June 17, 2011 02:05:59 justin wrote:
On 17/06/11 05:03, Mike Frysinger wrote:
# @ECLASS: fortran-2.eclass
i dont see fortran.eclass. what's with the -2 ?
There was a fortran eclass, which did completely different things. In
order to not break an ancient package (outside the tree) I decided to
go to the new name, which also underlines the new functionality.
thanks; makes sense
# internal function
use the @INTERNAL tag and proper eclass documentation
I wasn't aware of that. We are lacking any documentation about the
proper documentation for manpages in all eclass writing guides.
the syntax is fully documented in the utility that generates it. see the awk
in the eclass-manpages filesdir.
(( ${ret} )) || break
a little odd syntax, but i guess it works ...
I don't know any other way how I can jump out of the loop. The complete
things simulates the autoconf behavior.
i just meant using (( ${ret} )) rather than [[ ${ret} -eq 0 ]]
ewarn The support for EAPI=${EAPI} by the fortran-2.eclass
why ? it's causing you no real trouble to do so
The suggestion was to only support EAPI=4. I don't like this completely
as all fortran packages should directly use the eclass in order to make
it smooth for users. The delay should give some time to come up with
stable versions for all fortran packages at EAPI=4, but allow the use in
every ebuild right away.
if you want to keep older EAPI support, and/or it's trivial to do so, then
you're free to disagree with the suggestion and keep support. you are the
maintainer of this after all.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review fortran-2.eclass next round
I wasn't aware of that. We are lacking any documentation about the proper documentation for manpages in all eclass writing guides. the syntax is fully documented in the utility that generates it. see the awk in the eclass-manpages filesdir. This is not a proper way of documentation. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Please review fortran-2.eclass next round
On Friday, June 17, 2011 02:40:27 justin wrote: I wasn't aware of that. We are lacking any documentation about the proper documentation for manpages in all eclass writing guides. the syntax is fully documented in the utility that generates it. see the awk in the eclass-manpages filesdir. This is not a proper way of documentation. in your opinion of course. makes perfect sense to me though to have the documentation in the exact same file as the code that implements said documentation. more likely that the two are kept in sync. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 17/06/2011 03:30 πμ, Mike Frysinger wrote: On Monday, June 13, 2011 19:09:06 Jorge Manuel B. S. Vicetto wrote: On 11-06-2011 20:48, Mike Frysinger wrote: On Saturday, June 11, 2011 16:24:00 Ciaran McCreesh wrote: On Sat, 11 Jun 2011 15:58:43 -0400 Mike Frysinger wrote: So, effectively the QA team lead can appoint the people who elect him. I'm not at all implying that Diego would abuse his position, but still I think that this is not a sane situation. it does seem trivial to remove people who disagree with you and thus cement an echo chamber Are you talking in a hypothetical future situation, or has this already happened? If so, can you point to an example of where Diego's been removing people for disagreeing with him, rather than for disagreeing with the Council? how is disagreeing with a Council decision valid grounds either ? punting people because they disagree with any group isn't really valid. It was not about disagreeing with Council but actively going against an approved policy when the team is responsible for enforcing policies in the tree. This is why in my proposal for the review of GLEP 48 I added a point stating that acting against established policies would constitute ground to be removed from the team. that isnt what Ciaran said, and what you describe no one has shown me doing. thus the only logical conclusions that one can draw from this: - Diego mistakenly removed me without knowing all the facts or - i was removed for purely voicing disagreement -mike This is exactly what I've trying to explain in many many e-mails. You and Samuli agreed to follow the policy. Not removing old packages does *NOT* violate the policy. I am not sure why this is so hard for someone to understand the difference. This is reason why I left as well. Because you were removed with no proof of policy violation. - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJN+xbjAAoJEPqDWhW0r/LCDBcQAJNSH6E4eiB4GFt7nSWkT1Ou u9XbcaANAOBHNgt0Ydg/QJF2w0ON8vo/hk8y2gvxOOKXlukT21teDAQ4A7BTiRHa zz7m51TXyTXAjBUavam6x9KKgdTTnlHkRpVMCxh6HHG1K8n7qHFrswMxr41V8cD6 oZ4sP0UZPXKA7qslDv44MGF7gPQyUcCCKAYVOBOCWtNOr9LABxfSQnX/s6ZtSEHy uvQ8FD4cL/BYN83NnoB+fUUqzFwiyz1xlZDD3QrvhlsYNi3QSM+Zp6t2X08eWci5 ScSLUqB5kAZVZH9SzxNjpGeZu95A5hr0w6goCd6dxUqdUne/2k99HwPp876PRiq1 jvcRMEHvvKQdVN8Tdqs8fiSxVZBcBlG4N9ief6FyAKrNgcJ8aaLAPb9CeuqWcGnE mmWrtql5QJR3n5AENNOWUzG41RfBRf6QqoF9WYLDuIEwXOfcE2mpWmtL473fXtUK 8PsLSZ9ZXYVDhGxAAai1ZFCgTjbzCv635V0nXpZm2w6PBsDpuKRXtjUJCRbhoXVP lFBrDLDOyI/qFf7PfYQfi3nwUucmZIJTm3g+hSt1nuE9nvx2qjdx9FzN79DqattC RfiZQJFxXc9baa1qz0yt1TZHmmbFmUuX/moIxSSk0XbzYhEl5uJUuJeh/b8MGjeT 18nIZ+fNSEaHwyc/IHSk =0nlz -END PGP SIGNATURE-
Re: [gentoo-dev] Please review fortran-2.eclass next round
W dniu 17.06.2011 05:03, Mike Frysinger pisze:
DEPEND=virtual/fortran
RDEPEND=${DEPEND}
i'm not sure that RDEPEND is correct. do all fortran compilers additionally
require the fortran compiler to be available at runtime ?
They require fortran runtime library if they don't link it statically.
Cheers,
Kacper
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Please review fortran-2.eclass next round
On 17/06/11 11:01, Kacper Kowalik wrote:
W dniu 17.06.2011 05:03, Mike Frysinger pisze:
DEPEND=virtual/fortran
RDEPEND=${DEPEND}
i'm not sure that RDEPEND is correct. do all fortran compilers additionally
require the fortran compiler to be available at runtime ?
They require fortran runtime library if they don't link it statically.
Cheers,
Kacper
Thanks for clarification. We leave them as RDEPEND as well and handle
any (future) exeption in the virtual.
Here the updated eclass:
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# Author Justin Lecher j...@gentoo.org
# Test functions provided by Sebastien Fabbro and Kacper Kowalik
# @ECLASS: fortran-2.eclass
# @MAINTAINER:
# j...@gentoo.org
# s...@gentoo.org
# @BLURB: Simplify fortran compiler management
# @DESCRIPTION:
# If you need a fortran compiler, then you should be inheriting this eclass.
# The eclass tests for working fortran compilers
# and exports the variables FC and F77.
# Optionally, it checks for extended capabilities based on
# the variable options selected in the ebuild
# The only phase functions exported are pkg_pretend and pkg_setup.
# @ECLASS-VARIABLE: FORTRAN_NEED_OPENMP
# @DESCRIPTION:
# Set to 1 in order to automatically have the eclass abort if the fortran
# compiler lacks openmp support.
: ${FORTRAN_NEED_OPENMP:=0}
# @ECLASS-VARIABLE: FORTRAN_STANDARD
# @DESCRIPTION:
# Set this, if a special dialect needs to be supported.
# Generally not needed as default is sufficient.
#
# Valid settings are any combination of: 77 90 95 2003
: ${FORTRAN_STANDARD:=77}
inherit toolchain-funcs
DEPEND=virtual/fortran
RDEPEND=${DEPEND}
# @FUNCTION: _write_testsuite
# @DESCRIPTION: writes fortran test code
# @INTERNAL
_write_testsuite() {
local filebase=${T}/test-fortran
# f77 code
cat - EOF ${filebase}.f
end
EOF
# f90/95 code
cat - EOF ${filebase}.f90
end
EOF
# f2003 code
cat - EOF ${filebase}.f03
procedure(), pointer :: p
end
EOF
}
# @FUNCTION: _compile_test
# @DESCRIPTION:
# Takes fortran compiler as first argument and dialect as second.
# Checks whether the passed fortran compiler speaks the fortran dialect
# @INTERNAL
_compile_test() {
local filebase=${T}/test-fortran
local fcomp=${1}
local fdia=${2}
local fcode=${filebase}.f${fdia}
local ret
[[ $# -eq 0 ]] die _compile_test() needs at least one argument
[[ -f ${fcode} ]] || _write_testsuite
${fcomp} ${fcode} -o ${fcode}.x /dev/null
ret=$?
rm -f ${fcode}.x
return ${ret}
}
# @FUNCTION: _fortran-has-openmp
# @DESCRIPTION:
# See if the fortran supports OpenMP.
# @INTERNAL
_fortran-has-openmp() {
local flag
local filebase=${T}/test-fc-openmp
local fcode=${filebase}.f
local ret
local _fc=$(tc-getFC)
cat - EOF ${fcode}
call omp_get_num_threads
end
EOF
for flag in -fopenmp -xopenmp -openmp -mp -omp -qsmp=omp; do
${_fc} ${flag} ${fcode} -o ${fcode}.x /dev/null
ret=$?
(( ${ret} )) || break
done
rm -f ${fcode}.x
return ${ret}
}
# @FUNCTION: _die_msg
# @DESCRIPTION: Detailed description how to handle fortran support
# @INTERNAL
_die_msg() {
echo
eerror Please install currently selected gcc version with USE=fortran.
eerror If you intend to use a different compiler then gfortran, please
eerror set FC variable accordingly and take care that the neccessary
eerror fortran dialects are support.
echo
die Currently no working fortran compiler is available
}
# @FUNCTION: fortran-2_pkg_pretend
# @DESCRIPTION:
# Setup functionallity, checks for a valid fortran compiler and optionally for
its openmp support.
fortran-2_pkg_pretend() {
local dialect
: ${F77:=$(tc-getFC)}
: ${FORTRAN_STANDARD:=77}
for dialect in ${FORTRAN_STANDARD}; do
case ${dialect} in
77) _compile_test $(tc-getF77) || _die_msg ;;
90|95) _compile_test $(tc-getFC) 90 || _die_msg ;;
2003) _compile_test $(tc-getFC) 03 || _die_msg ;;
2008) die Future ;;
*) die ${dialect} is not a Fortran dialect. ;;
esac
done
if [[ ${FORTRAN_NEED_OPENMP} == 1 ]]; then
_fortran-has-openmp || \
die Please install current gcc with USE=openmp or set
the FC variable to a compiler that supports OpenMP
fi
}
# @FUNCTION: fortran-2_pkg_setup
# @DESCRIPTION:
# In EAPI 4 it calls the compiler check. This behavior is deprecated
# and will be removed at 01-Okt-2011. Please migrate to EAPI=4.
#
#
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: package.mask
On 06/17/2011 04:10 PM, Stuart Longland (redhatter) wrote: redhatter11/06/17 13:10:02 Modified: package.mask Log: Masking of media-radio/svxlink-090426 and media-radio/gmfsk. The former will need a major overhaul, and I intend to replace the ebuild with a newer one. The latter, no point in keeping it around as media-radio/fldigi does the same and more. That, and gmfsk is no longer maintained... so out it goes. Revision ChangesPath 1.12844 profiles/package.mask file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?rev=1.12844view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?rev=1.12844content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?r1=1.12843r2=1.12844 Index: package.mask === RCS file: /var/cvsroot/gentoo-x86/profiles/package.mask,v retrieving revision 1.12843 retrieving revision 1.12844 diff -u -r1.12843 -r1.12844 --- package.mask 17 Jun 2011 09:55:07 - 1.12843 +++ package.mask 17 Jun 2011 13:10:02 - 1.12844 @@ -1,5 +1,5 @@ -# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.12843 2011/06/17 09:55:07 olemarkus Exp $ +# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.12844 2011/06/17 13:10:02 redhatter Exp $ # # When you add an entry to the top of this file, add your name, the date, and # an explanation of why something is getting masked. Please be extremely @@ -31,6 +31,18 @@ #--- END OF EXAMPLES --- +# Stuart Longland redhat...@gentoo.org (17 Jun 2011) +# Masked for removal within 30 days. Will be replacing it with updated +# ebuilds to address numerous issues. See bugs #336993, #336199, #369881 +# and #335307. +=media-radio/svxlink-090426 + +# Stuart Longland redhat...@gentoo.org (17 Jun 2011) +# Masked for removal within 30 days. There is a newer version upstream but it +# doesn't compile for me, and upstream is now dead. As an alternative, have a +# look at media-radio/fldigi instead. (See bug #259451) +media-radio/fldigi That doesn't make much sense... Mask fldigi and suggest it at the same time?
Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
On Fri, Jun 17, 2011 at 1:57 AM, Markos Chandras hwoar...@gentoo.org wrote: Not removing old packages does *NOT* violate the policy. And this is why nobody likes lawyers. :) Leaving around old packages because of a desire to avoid a policy doesn't really strike me as an example of exemplary QA either. There are lots of good reasons to keep a few versions of a package in-tree. None of them should be used merely as excuses to avoid running the echangelog command. I could see foot-dragging over a policy that requires refactoring many ebuilds or something, but the Council tends to avoid things like this precisely because they are onerous. Personally I tend to just run echangelog for everything anyway - it is easier to changelog a trivial change than to spend half a week on -dev debating anybody who questions whether it is trivial. Besides, I spend much of my career working on systems that won't commit anything without a documented reason for change - the changelogs on these systems typically grow to fill 75% of the entire databases. Gentoo is like a breath of fresh air... The one thing I hope doesn't come out of this is a Council that is even more reluctant to act out of fear of being slapped around by the community anytime a developer threatens to quit. Sure, we can't really afford to lose people, but we can even less afford a system where any one person can just hold the entire endeavor hostage. If we think that tweaking the changelog policy causes pain, just wait to see how the git migration goes. Sometimes individual devs just need to see which way the wind is blowing and do their part to make sure we at least end up anywhere other than going in circles... Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 17/06/2011 05:25 ??, Rich Freeman wrote: On Fri, Jun 17, 2011 at 1:57 AM, Markos Chandras hwoar...@gentoo.org wrote: Not removing old packages does *NOT* violate the policy. And this is why nobody likes lawyers. :) Rich, That's a bit controversial. Do not expect developers to use common sense when you frame them with policies that you (not you in particular) established just because you think that they don't have common sense. See the irony? :) - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJN+2n6AAoJEPqDWhW0r/LCdigP/2lUqGrTRsMKSnVzXfrgPVP0 fq+n3iTlHkYo6dPHHE8qCp0XeALTwelM/aBV3EHmtfMhxLDrcL1TZXpLPZ1CcAtY /1p5mkkC6BIbpxwhBkKmTVeqPY8sTTkFMWJItrcwL48U47inBEK9+Lk1rZ6ZWJgh km5b9R8NpB9zY5a28HGl+zrIX+W5LFcQZ9DlIZ8+b/wBn6IbTLSN25mmL7HeaDvL GrSv++1PJGAAp0wBo9RwhrgxfGIi+emDZFxMsLoxDmpZLLpZ3FOK/7q1jYXmUJ+O F3mwMa1U71SG5IKYUVPP9lNgWqdM7bneuGcCtvEva3mx7js5GoAdznjm2CQrA5PS RgV3ZgpV6q8IdmOO7/RfA/i5WNQNdK+0gk09o6uElKn1hCV2cW8lcC2yQe8sHyka 02x5JSaTijl39cjhqCysNZfuuzM6RzYsNOxwg56OCyl2ZDS3WgyoPInWlrLr1bpF LMNMeD486o/uD4pvkYp40vkbdy2VInasV7+Tpfj5AmNrXqnUNFumHP6t41QsIB90 vtRY7G3nSM1nQxfaw8CPrFDiWaKkZ/adScQg6G3W9P3Bi45ddTWtaEh2YseJZm0w C8V+86j0t+LyFkjiHpORkusZgVoNrWW8Z2gSBAvB4IQDJZmyWA/vGPbVvX+CDc5L bo3sP9fYm2YLwGhj7BOL =6aj1 -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
Rich Freeman posted on Fri, 17 Jun 2011 07:25:42 -0700 as excerpted: On Fri, Jun 17, 2011 at 1:57 AM, Markos Chandras hwoar...@gentoo.org wrote: Not removing old packages does *NOT* violate the policy. And this is why nobody likes lawyers. :) Leaving around old packages because of a desire to avoid a policy doesn't really strike me as an example of exemplary QA either. There are lots of good reasons to keep a few versions of a package in-tree. None of them should be used merely as excuses to avoid running the echangelog command. Reading a changelog (yes, READING A CHANGELOG!! people actually DO use them, and occasionally depend on entries when versions are removed, but that's covered territory) at my last update yesterday, something occurred to me... The particular entry in question listed some trivial change in maintained ebuilds, then said Remove old. There was accordingly a list of a bunch of removed versions, along with the versions modified by the update. What occurred to me in the context of this whole controversy, was that not only can devs simply leave old versions for someone else to remove, but they can, and routinely do, remove old versions as part of a commit changing something in (some of) the remaining ones, as well. It's worth pointing out that if Mike and others' workflow already involves a lot of this, they'd be modifying it very little if they simply avoided separate removals. In fact, in borderline cases where a trivial change may not have made it on its own, as it waited for a bigger change to come along to be worth doing, the removals combined with the trivial change may now trigger the trivial change commit earlier than it would have occurred otherwise. So depending on the individual package and how often minor changes as opposed to version removals are necessary, it's entirely possible that deliberately abstaining from removal-only commits won't visibly change the workflow AT ALL, or that if it does, it's in favor of getting those minor changes in faster than they'd otherwise appear. [Deleted a bunch I 100% agree with.] The one thing I hope doesn't come out of this is a Council that is even more reluctant to act out of fear of being slapped around by the community anytime a developer threatens to quit. That was worth repeating. ++ If we think that tweaking the changelog policy causes pain, just wait to see how the git migration goes. True but scary. -- 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
Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
El 17/06/11 16:25, Rich Freeman escribió: If we think that tweaking the changelog policy causes pain, just wait to see how the git migration goes. Just a few words regarding this, in my company we moved to git (from darcs) recently. I have ended up taking some non working days because the pressure made by the devs was very high. So Council guys expect the same from Gentoo devs when you move (and I'm in no way not supporting the move, in fact I'd like to see it done). signature.asc Description: OpenPGP digital signature
[gentoo-dev] write to filesystem in pkg_pretend
* justin j...@gentoo.org: Now using the new pkg_pretend for EAPI=4 While T is defined in all phases, PMS also says that pkg_pretend must not write to the filesystem. Is it allowed to write to T or not? Can the specs be clearer if it's allowed? -- Thanks
Re: [gentoo-dev] write to filesystem in pkg_pretend
On Fri, 17 Jun 2011 18:25:21 +0200 Torsten Veller ml...@veller.net wrote: * justin j...@gentoo.org: Now using the new pkg_pretend for EAPI=4 While T is defined in all phases, PMS also says that pkg_pretend must not write to the filesystem. Is it allowed to write to T or not? Can the specs be clearer if it's allowed? No, it's not allowed. pkg_pretend() should work without creating the ebuild temporary dirs. But that's only my PoV. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] write to filesystem in pkg_pretend
On Fri, 17 Jun 2011, Torsten Veller wrote: While T is defined in all phases, PMS also says that pkg_pretend must not write to the filesystem. Is it allowed to write to T or not? Can the specs be clearer if it's allowed? Must not write to the filesystem seems to be very clear to me. Ulrich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
On Friday, June 17, 2011 11:31:43 Duncan wrote: What occurred to me in the context of this whole controversy, was that not only can devs simply leave old versions for someone else to remove, but they can, and routinely do, remove old versions as part of a commit changing something in (some of) the remaining ones, as well. yes, which is why i find it a bit ironic when people claim that this information is useful while at the same basically generating garbage themselves. It's worth pointing out that if Mike and others' workflow already involves a lot of this, they'd be modifying it very little if they simply avoided separate removals. In fact, in borderline cases where a trivial change may not have made it on its own, as it waited for a bigger change to come along to be worth doing, the removals combined with the trivial change may now trigger the trivial change commit earlier than it would have occurred otherwise. if you look at my commit behavior, this is exactly the sort of thing i avoid. my cvs commits are pretty logically clean to the point where importing into git would result in nice behavior. which means i make one commit to remove, one commit to fix a specific bug, one commit to version bump, etc... -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
On Friday, June 17, 2011 12:08:43 Francisco Blas Izquierdo Riera wrote: El 17/06/11 16:25, Rich Freeman escribió: If we think that tweaking the changelog policy causes pain, just wait to see how the git migration goes. Just a few words regarding this, in my company we moved to git (from darcs) recently. I have ended up taking some non working days because the pressure made by the devs was very high. So Council guys expect the same from Gentoo devs when you move (and I'm in no way not supporting the move, in fact I'd like to see it done). when i made the conversion at my job, i made myself available for random/trivial questions and explaining of concepts. it seemed to make things much smoother for them. certainly dont have a problem doing the same for Gentoo. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review fortran-2.eclass next round
On Friday, June 17, 2011 05:01:10 Kacper Kowalik wrote:
W dniu 17.06.2011 05:03, Mike Frysinger pisze:
DEPEND=virtual/fortran
RDEPEND=${DEPEND}
i'm not sure that RDEPEND is correct. do all fortran compilers
additionally require the fortran compiler to be available at runtime ?
They require fortran runtime library if they don't link it statically.
*if* there is a fortran runtime library in the first place. gcc provides one,
but does that mean all fortran compilers do ?
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] write to filesystem in pkg_pretend
On Friday, June 17, 2011 12:25:21 Torsten Veller wrote: * justin j...@gentoo.org: Now using the new pkg_pretend for EAPI=4 While T is defined in all phases, PMS also says that pkg_pretend must not write to the filesystem. Is it allowed to write to T or not? Can the specs be clearer if it's allowed? sounds like a good reason to use emktemp as that'll utilize /tmp for files when $T is unavailable or just drop EAPI=4 support ;) -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
Mike Frysinger posted on Fri, 17 Jun 2011 12:44:52 -0400 as excerpted: On Friday, June 17, 2011 11:31:43 Duncan wrote: It's worth pointing out that if Mike and others' workflow already involves a lot of this, they'd be modifying it very little if they simply avoided separate removals. In fact, in borderline cases where a trivial change may not have made it on its own, as it waited for a bigger change to come along to be worth doing, the removals combined with the trivial change may now trigger the trivial change commit earlier than it would have occurred otherwise. if you look at my commit behavior, this is exactly the sort of thing i avoid. my cvs commits are pretty logically clean to the point where importing into git would result in nice behavior. which means i make one commit to remove, one commit to fix a specific bug, one commit to version bump, etc... Good point and exactly the behavior best on git as it makes for far easier and more effective git bisects when necessary. Unfortunately (for oh so many reasons!!), Gentoo's main tree and workflow isn't git-ified yet. But I can certainly commend someone whose personal standards demand that same one-thing-and-one-thing-only commit separation, modern dVCS or not. Meanwhile, case-in-point of why changelogging removals matters. My last post was to a kde list, helping someone trying to build kdelibs on RHEL. He was missing the libdbusmenu-qt dependency, which I was able to point out, and I went on to describe the version info. Gentoo's kdelibs-4.6.4 dependency for that library is = libdbusmenu-qt-0.3.2, but I have 0.8.2 installed. Because the information was in the changelog, I was able to tell him that my current 0.8.2 was introduced in April, the other available version on gentoo, 0.6.2, was introduced in Sept. 2010, there was a version jump (at least on gentoo) between 0.3.5 (from June, 2010) and 0.6.2, and the 0.3.2 that's gentoo's minimum requirement was introduced on Gentoo in April 2010 and removed in Sept, 2010. So even 0.3.2 isn't much more than a year old (on RHEL 5 it's likely an upgrade!), but was already considered old enough to remove ~6 months later. That information on 0.3.2 removal wouldn't have been available to me (at least not without making a huge project of it, checking Gentoo's viewCVS logs on the web) had someone not put it in the changelog. Users DO find that information useful and there have been quite a number of times I personally have found it useful in helping people not necessarily on gentoo (tho I believe I've spotted hugely outdated based on changelogs versions of packages on gentoo-users systems, too), but in other parts of the FLOSS community. Having that information not available locally on my system, either by changelog as now, or by git whatchanged, if users finally get access to direct git-pull once the main tree is git-upgraded, would be a serious regression. -- 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
Re: [gentoo-dev] Please review fortran-2.eclass next round
On Friday, June 17, 2011 14:39:22 Kacper Kowalik wrote:
W dniu 17.06.2011 18:41, Mike Frysinger pisze:
On Friday, June 17, 2011 05:01:10 Kacper Kowalik wrote:
W dniu 17.06.2011 05:03, Mike Frysinger pisze:
DEPEND=virtual/fortran
RDEPEND=${DEPEND}
i'm not sure that RDEPEND is correct. do all fortran compilers
additionally require the fortran compiler to be available at runtime ?
They require fortran runtime library if they don't link it statically.
*if* there is a fortran runtime library in the first place. gcc provides
one, but does that mean all fortran compilers do ?
It *really* makes things easier if virtual/fortran is in RDEPEND. Is it
serious obstacle?
i didnt say it was an obstacle. i asked if it's actually correct. atm, it
would seem it is required.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
On 06/17/2011 09:18 PM, Duncan wrote: Mike Frysinger posted on Fri, 17 Jun 2011 12:44:52 -0400 as excerpted: On Friday, June 17, 2011 11:31:43 Duncan wrote: It's worth pointing out that if Mike and others' workflow already involves a lot of this, they'd be modifying it very little if they simply avoided separate removals. In fact, in borderline cases where a trivial change may not have made it on its own, as it waited for a bigger change to come along to be worth doing, the removals combined with the trivial change may now trigger the trivial change commit earlier than it would have occurred otherwise. if you look at my commit behavior, this is exactly the sort of thing i avoid. my cvs commits are pretty logically clean to the point where importing into git would result in nice behavior. which means i make one commit to remove, one commit to fix a specific bug, one commit to version bump, etc... Good point and exactly the behavior best on git as it makes for far easier and more effective git bisects when necessary. Unfortunately (for oh so many reasons!!), Gentoo's main tree and workflow isn't git-ified yet. But I can certainly commend someone whose personal standards demand that same one-thing-and-one-thing-only commit separation, modern dVCS or not. Meanwhile, case-in-point of why changelogging removals matters. My last post was to a kde list, helping someone trying to build kdelibs on RHEL. He was missing the libdbusmenu-qt dependency, which I was able to point out, and I went on to describe the version info. Gentoo's kdelibs-4.6.4 dependency for that library is = libdbusmenu-qt-0.3.2, but I have 0.8.2 installed. Because the information was in the changelog, I was able to tell him that my current 0.8.2 was introduced in April, the other available version on gentoo, 0.6.2, was introduced in Sept. 2010, there was a version jump (at least on gentoo) between 0.3.5 (from June, 2010) and 0.6.2, and the 0.3.2 that's gentoo's minimum requirement was introduced on Gentoo in April 2010 and removed in Sept, 2010. So even 0.3.2 isn't much more than a year old (on RHEL 5 it's likely an upgrade!), but was already considered old enough to remove ~6 months later. That information on 0.3.2 removal wouldn't have been available to me (at least not without making a huge project of it, checking Gentoo's viewCVS logs on the web) had someone not put it in the changelog. Users DO find that information useful and there have been quite a number of times I personally have found it useful in helping people not necessarily on gentoo (tho I believe I've spotted hugely outdated based on changelogs versions of packages on gentoo-users systems, too), but in other parts of the FLOSS community. Having that information not available locally on my system, either by changelog as now, or by git whatchanged, if users finally get access to direct git-pull once the main tree is git-upgraded, would be a serious regression. I'm sorry, but honestly, did you have a point in there somewhere?
Re: [gentoo-dev] Packages that explicitly DEPEND on sys-apps/sed
more thoughts as to why this is a bad idea ... how do you deal with runtime library requirements which only the compiler knows about ? sys-devel/gcc provides many runtime libraries such as libgcc_s.so. but whether the package actually needs that at runtime may depend purely on the arch/abi, or what code *just happens* to be generated. embedded cpus tend to need it more often than desktop cpus because libgcc_s.so provides fun things like 64bit multiplication and division routines when the hardware lacks support. so if your target happens to do 64bit multiplication, you now have RDEPEND on sys-devel/gcc. glibc itself will load up libgcc_s.so via dlopen when unwinding in threaded situations. but this only necessary when the package uses threads, and needs unwind support (iirc), and glibc is using NPTL. you could say ah just have glibc itself always require gcc, but if we're not being explicit in our deps, i dont see any difference from the implicit system set (except in the worse direction). these dependencies cannot be expressed via ebuilds/eclasses. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
On Friday, June 17, 2011 14:34:35 Samuli Suominen wrote: I'm sorry, but honestly, did you have a point in there somewhere? i gathered that he had a specific case where he found a removal entry in the ChangeLog kept people from chasing their own tail for a while -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
Samuli Suominen posted on Fri, 17 Jun 2011 21:34:35 +0300 as excerpted: On 06/17/2011 09:18 PM, Duncan wrote: Meanwhile, case-in-point of why changelogging removals matters. My last post was to a kde list, helping someone trying to build kdelibs on RHEL. He was missing the libdbusmenu-qt dependency Because the information was in the changelog 0.3.2 isn't much more than a year old (on RHEL 5 it's likely an upgrade!), but was already considered old enough to remove ~6 months later. That information on 0.3.2 removal wouldn't have been available to me had someone not put it in the changelog. Having that information not available locally on my system, either by changelog as now, or by git whatchanged, if users finally get access to direct git-pull once the main tree is git-upgraded, would be a serious regression. I'm sorry, but honestly, did you have a point in there somewhere? Mike's correct. Not having package removal information in the changelog would be a serious regression, as the last paragraph states in summary of the previous, which is excerpted above. -- 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
Re: [gentoo-dev] Packages that explicitly DEPEND on sys-apps/sed
On Tue, 14 June 2011 Brian Harring ferri...@gmail.com wrote: On Tue, Jun 14, 2011 at 10:08:54AM -0400, Rich Freeman wrote: On Tue, Jun 14, 2011 at 8:54 AM, Brian Harring ferri...@gmail.com wrote: The implicit system set dependency thing really, really needs to die; at the time of the rule, portage couldn't handle resolving graphs of that sort. ?PM resolvers for gentoo are generally a fair bit saner now thus doing what you're suggesting isn't really beneficial (frankly it causes some issues for stages, as zac noted). ++ It seems to me that the best policy would be for every package to just list all its dependencies, and then users are free to run the default experience that includes everything in @system, or a more trimmed-down experience. An annoying, but valid complaint agains this is that the deps start getting heavy to maintain for developers, and aren't always viable to represent. Unpackers for example, are a pain in the ass for current EAPIs- that could be reduced in pain via addition of basic implicit deps to EAPI5 (if a src_uri ends in .bz2, then dep on virtual/bzip2). Or devs could just be nudged into adding the appropriate DEPEND. repoman checking for it either way wouldn't be hard. IMHO a big distinction between DEPEND and RDEPEND should be done. For RDEPEND all dependencies should be listed (including those packages provided by @system) This would allow easy installing into chroots with package manager's help, especially in combination with binary packages. For DEPEND it could be sufficient to assume @system is present or at least limit to those dependencies needed by the package/ebuild itself, but not those coming implicitly with features of package manager used (e.g. default unpacking, emake, einstall, do*) Eclasses extending package manager features should include their extra DEPEND needs. On the other hand, it would be nice if package manager could auto-detect at least part of the runtime dependencies (library linking should be easy as package manager already looks for them -- what's completely missing is shebang/interpreter dependencies). This way only version constraints would need to get added to RDEPEND inside ebuilds as needed (and the few cases where dlopen makes it impossible for package manager to see the linking). A nice benefit of this would be that it can adapt to changes caused by INSTALL_MASK, e.g. reduces dependencies that are not needed anymore because some files were not installed. Bruno
Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
El 17/06/11 18:46, Mike Frysinger escribió: On Friday, June 17, 2011 12:08:43 Francisco Blas Izquierdo Riera wrote: El 17/06/11 16:25, Rich Freeman escribió: If we think that tweaking the changelog policy causes pain, just wait to see how the git migration goes. Just a few words regarding this, in my company we moved to git (from darcs) recently. I have ended up taking some non working days because the pressure made by the devs was very high. So Council guys expect the same from Gentoo devs when you move (and I'm in no way not supporting the move, in fact I'd like to see it done). when i made the conversion at my job, i made myself available for random/trivial questions and explaining of concepts. it seemed to make things much smoother for them. Neither am I in fact I'm working in this ATM: http://dev.gentoo.org/~klondike/git.xml Yet when people doesn't want to change your availability serves little. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
On Friday, June 17, 2011 16:37:02 Francisco Blas Izquierdo Riera wrote: El 17/06/11 18:46, Mike Frysinger escribió: On Friday, June 17, 2011 12:08:43 Francisco Blas Izquierdo Riera wrote: El 17/06/11 16:25, Rich Freeman escribió: If we think that tweaking the changelog policy causes pain, just wait to see how the git migration goes. Just a few words regarding this, in my company we moved to git (from darcs) recently. I have ended up taking some non working days because the pressure made by the devs was very high. So Council guys expect the same from Gentoo devs when you move (and I'm in no way not supporting the move, in fact I'd like to see it done). when i made the conversion at my job, i made myself available for random/trivial questions and explaining of concepts. it seemed to make things much smoother for them. Neither am I in fact I'm working in this ATM: http://dev.gentoo.org/~klondike/git.xml thanks. this is what i wrote: http://docs.blackfin.uclinux.org/doku.php?id=version_control_systems#quick_references people found the cvs-svn-git rosetta stone useful -mike signature.asc Description: This is a digitally signed message part.
