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
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
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.
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
-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
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
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
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
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
-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
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
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
* 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
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
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
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)
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
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 ?
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
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
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
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
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,
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
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
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
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
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,
28 matches
Mail list logo
