Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On Wed, Feb 11, 2015 at 2:15 PM, hasufell wrote: > A team is clearly violating GLEP39 and you don't care: When did I claim to not care? >> It may have one or many leads, and the leads are selected by the members of >> the project. This selection must occur at least once every 12 months, and >> may occur at any time. > > Instead we are getting tree inconsistency, because people start to > ignore the team. > > That is the worst that could happen. You clearly lack imagination. There are many things that could happen that are far worse than this. Gentoo not having anybody maintaining any games would be a worse outcome, for starters. What "punishment" would you deem appropriate for a team not following GLEP39? We could disband it, but we're not in any hurry to do so, because we're not convinced that doing this will make things any better. > I wonder why you were not so picky about the QA team back then. QA has authority over the entire tree. The games team does not. It is important that teams that have authority over the entire distro be selected in a way that makes them accountable. I don't think QA was doing anything horribly wrong, but having the Council confirm the QA lead helps to provide this accountability, since ultimately we are accountable. > > Maybe the solution is point 3 of GLEP39 under the rationale section: >> If the council does a lousy job handling global issues (or has no global >> vision), vote out the bums > Which would be why I've encouraged you to run for Council a few times now if you think you'll do better. I'm not going to apologize for being elected. If you really think that games.eclass is the hill we should all be dying on, you can put that in your manifesto. I think the urgent part of the crisis was dealt with (a conflict between individual maintainers and the games team, and a concern that people couldn't join the games team even if they wanted to). We can afford to take our time to deal with the rest, and it is best left to those who actually care about the issue. -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
A team is clearly violating GLEP39 and you don't care: > It may have one or many leads, and the leads are selected by the members of > the project. This selection must occur at least once every 12 months, and may > occur at any time. Instead we are getting tree inconsistency, because people start to ignore the team. That is the worst that could happen. I wonder why you were not so picky about the QA team back then. Maybe the solution is point 3 of GLEP39 under the rationale section: > If the council does a lousy job handling global issues (or has no global > vision), vote out the bums
Re: [gentoo-dev] [PATCH] cmake-utils.eclass: add Fortran to Gentoo override rules (set valid compiler, append FCFLAGS)
2015-02-11 11:14 GMT-07:00 Andrew Savchenko : > Hello, > > attached patch adds Fortran compiler to Gentoo override rules in > cmake-utils.eclass the same way C/C++ compilers are added. > > This change is needed because packages which force their own > precedence of Fortran compilers or flags also exists. We hit this > issue on bug 486626 [1] for sci-libs/lapacke-reference (science > overlay): if multiple Fortran compilers are installed, e.g. pathf95 > and gfortran, package prefers pathf95 — this may even broke build, > because most FCFLAGS are not compatible between this compilers > > In order to fix this FC should be set from $(tc-getFC), which is > implemented in proposed patch as well as ensuring proper flags are > set. > > This change was already discussed with KDE team [1] and I'm going to > commit this patch after feedback or in a week if there are no > objections. +1 > > [1] https://bugs.gentoo.org/show_bug.cgi?id=486626 > > Best regards, > Andrew Savchenko -- Christoph Junghans http://dev.gentoo.org/~ottxor/
[gentoo-dev] [PATCH] cmake-utils.eclass: add Fortran to Gentoo override rules (set valid compiler, append FCFLAGS)
Hello,
attached patch adds Fortran compiler to Gentoo override rules in
cmake-utils.eclass the same way C/C++ compilers are added.
This change is needed because packages which force their own
precedence of Fortran compilers or flags also exists. We hit this
issue on bug 486626 [1] for sci-libs/lapacke-reference (science
overlay): if multiple Fortran compilers are installed, e.g. pathf95
and gfortran, package prefers pathf95 — this may even broke build,
because most FCFLAGS are not compatible between this compilers
In order to fix this FC should be set from $(tc-getFC), which is
implemented in proposed patch as well as ensuring proper flags are
set.
This change was already discussed with KDE team [1] and I'm going to
commit this patch after feedback or in a week if there are no
objections.
[1] https://bugs.gentoo.org/show_bug.cgi?id=486626
Best regards,
Andrew Savchenko
--- cmake-utils.eclass.orig 2014-12-18 20:01:09.0 +0300
+++ cmake-utils.eclass 2015-02-11 20:54:43.307183771 +0300
@@ -462,6 +462,7 @@
SET (CMAKE_ASM_COMPILE_OBJECT " ${CFLAGS} -o -c " CACHE STRING "ASM compile command" FORCE)
SET (CMAKE_C_COMPILE_OBJECT " ${CPPFLAGS} -o -c " CACHE STRING "C compile command" FORCE)
SET (CMAKE_CXX_COMPILE_OBJECT " ${CPPFLAGS} -o -c " CACHE STRING "C++ compile command" FORCE)
+ SET (CMAKE_Fortran_COMPILE_OBJECT " ${FCFLAGS} -o -c " CACHE STRING "Fortran compile command" FORCE)
SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE FILEPATH "Archive index generator" FORCE)
SET (PKG_CONFIG_EXECUTABLE $(type -P $(tc-getPKG_CONFIG)) CACHE FILEPATH "pkg-config executable" FORCE)
_EOF_
@@ -470,6 +471,7 @@
cat > ${toolchain_file} <<- _EOF_
SET (CMAKE_C_COMPILER $(tc-getCC))
SET (CMAKE_CXX_COMPILER $(tc-getCXX))
+ SET (CMAKE_Fortran_COMPILER $(tc-getFC))
_EOF_
if tc-is-cross-compiler; then
pgpHPv48kuxSP.pgp
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On Wed, Feb 11, 2015 at 11:08 AM, hasufell wrote: > > So let's summarize: > * the council said it will deal with it Cite? I just posted what the council ACTUALLY said, and this wasn't on it. I'd re-post it, but I think it was only two posts ago for my part. > > What we have now is: > * the council says there is no problem Cite? A random council member posting that they don't think that we should take drastic action isn't the "council" saying something. Even all seven council members posting random posts on lists isn't the "council" saying something. Believe it or not, the council is composed of mortal human beings who tend to discuss ideas openly and some turn out to be good and some turn out to be bad, and they tend to not vote on things until it is pretty clear that it is the right thing to do. If a council member posts an idea on the list and a non-council member replies pointing out the issues and offering a better proposal in response, that is a good thing. > * the council didn't deal with it > * there have been no votes There have been no candidates to vote for, and voting for candidates to lead the games team is the responsibility of the games team, not the Council. The Council DID vote to place an interim lead in charge of the games team for the purpose of facilitating an election. However, there was no response to repeated calls to join the team. This whole issue seems to be a tempest in a teapot, honestly. I don't really consider it ideal, but there is little in Gentoo I would consider ideal. Ultimately we all tend to step up and work on things we think are important to us, and this item is no different. If somebody really cares about this issue, they'll join the games team. Pointing out issues on lists that people aren't aware of is helpful. Harping on them repeatedly isn't. If you want to offer solutions, do it. If you just want to boss people around, try running for Council and see how well it works out even if you do get elected. -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
Andreas K. Huettel: >> Tim Harder: > >>> Also, I would advise caution on considering it dysfunctional and >>> disbanding it due to this. >> I cannot follow that argumentation. Because no one wants to join, the >> team is functional? > > I'm seeing a lot of commits by mr_bones and tupone recently. Doesn't look > defunct to me. > So let's summarize: * the council agreed that there are problems with the project * the council said it will deal with it * the council said there will be votes for a new lead What we have now is: * the council says there is no problem * the council didn't deal with it * there have been no votes errr... wat? Seriously?
Re: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
> Tim Harder: > > Also, I would advise caution on considering it dysfunctional and > > disbanding it due to this. > I cannot follow that argumentation. Because no one wants to join, the > team is functional? I'm seeing a lot of commits by mr_bones and tupone recently. Doesn't look defunct to me. -- Andreas K. Huettel Gentoo Linux developer perl, office, comrel, council
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
hasufell wrote: > > from what comments I got back no one really wanted to join (at least > > under the current system). I wasn't going to force the games team to > > elect a new lead when it appears none cared much at that point who > > the lead was. Also, I would advise caution on considering it > > dysfunctional and disbanding it due to this. > > I cannot follow that argumentation. Because no one wants to join, the > team is functional? You're verging on trolling. :\ Noone wanting to join does not automatically mean that the team is not functional. //Peter
Re: [gentoo-dev] Suggestion about how to tell ATs that a package can be stabilized on all arches at the same time
Pacho Ramos napisał: >El mié, 11-02-2015 a las 09:22 +0100, Jeroen Roovers escribió: >> On Sun, 08 Feb 2015 11:17:19 +0100 >> Pacho Ramos wrote: >> >> > Many times has raised the question about how we could handle those >> > packages (like icon packs, wallpapers...) that are not arch >dependent >> > and, then, could be stabilized all at the same time by the first >arch >> > team that is going to stabilize it. >> >> If you do that, then what is the point of having a stable request in >> the first place? The many-eyeballs argument is gone then, so what are >we >> left with? > >The point is to test if it breaks depending on the arch, not to get it >tested by maintainers + a random of arch teams depending on each >package > >For example, for ubuntu-wallpapers package there is no need to overload >three different arch-teams (or even more if it was keyworded on more >arches) But what if the wallpapers contain exploits that work only on specific arches? ;) > >> >> It isn't a team that is doing the stabilisation, it's a single person >> who may or may not have looked at what the new version does and how >> well it installs, and may or may not feel some pressure to rush it. >> >> As I said before many times, having more people on more architecture >> teams look at the same problem actually helps catch bug at a late >> stage but arguably still in time. Removing or weakening that last >line >> of defence (either by having a single person do stabilisations for >> multiple architectures, or by removing most architecture teams from >each >> single task) will increase the bug rate for stable ebuilds (even >more). >> >> >> jer >> > >Current situation only leads to stabilizations hanging for months with >some arch teams having really big pending lists (taking care of their >rate of stabling). Of course, if you want to have an exception for HPPA >(as it has for other stuff like the profiles), there is no problem. We >can keep leaving hppa there if you want to double check them (HPPA is >not a problem as it has a stable tree that is small enough to be >maintainable) Of course there's always the option of dropping stable keywords. -- Michał Górny
Re: [gentoo-dev] Suggestion about how to tell ATs that a package can be stabilized on all arches at the same time
On Sun, 08 Feb 2015 11:53:39 -0500 Brian Evans wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 02/08/2015 05:17 AM, Pacho Ramos wrote: > > Hello > > > > Many times has raised the question about how we could handle those > > packages (like icon packs, wallpapers...) that are not arch > > dependent and, then, could be stabilized all at the same time by > > the first arch team that is going to stabilize it. > > > > Some months ago it was suggested that this packages could have a > > KEYWORD with a value like "~arch" for example that could indicate > > this situation: > > http://www.gossamer-threads.com/lists/gentoo/dev/283020 > > > > But it was shown that it would be difficult to make it work > > properly at PM level. > > > > Then, I was wondering if we could handle this simply by having: - A > > new keyword for bugzilla like "STABLEREQALL" to easily allow arch > > teams to filter this kind of packages and handle them in this > > "special way" - A new key for metadata.xml files to specify there > > that the package can be handled in that way. > > > > What do you think about this? It wouldn't need any change at PM > > level and, then, it should be easy to do. > > > > > > I would like to see packages with PHP scripts (only) be included with > such a proposal. i.e. dev-php/PEAR-* . They are only text files which > may only rely on dev-lang/php USE which are simple to detect with > repoman failures. This is way too dangerous. Perl packages are also text files, but there was a case in history, when perl package was working only on specific architecture. Best regards, Andrew Savchenko pgpDXI3JuR17b.pgp Description: PGP signature
Re: [gentoo-dev] Suggestion about how to tell ATs that a package can be stabilized on all arches at the same time
El mié, 11-02-2015 a las 09:22 +0100, Jeroen Roovers escribió: > On Sun, 08 Feb 2015 11:17:19 +0100 > Pacho Ramos wrote: > > > Many times has raised the question about how we could handle those > > packages (like icon packs, wallpapers...) that are not arch dependent > > and, then, could be stabilized all at the same time by the first arch > > team that is going to stabilize it. > > If you do that, then what is the point of having a stable request in > the first place? The many-eyeballs argument is gone then, so what are we > left with? The point is to test if it breaks depending on the arch, not to get it tested by maintainers + a random of arch teams depending on each package For example, for ubuntu-wallpapers package there is no need to overload three different arch-teams (or even more if it was keyworded on more arches) > > It isn't a team that is doing the stabilisation, it's a single person > who may or may not have looked at what the new version does and how > well it installs, and may or may not feel some pressure to rush it. > > As I said before many times, having more people on more architecture > teams look at the same problem actually helps catch bug at a late > stage but arguably still in time. Removing or weakening that last line > of defence (either by having a single person do stabilisations for > multiple architectures, or by removing most architecture teams from each > single task) will increase the bug rate for stable ebuilds (even more). > > > jer > Current situation only leads to stabilizations hanging for months with some arch teams having really big pending lists (taking care of their rate of stabling). Of course, if you want to have an exception for HPPA (as it has for other stuff like the profiles), there is no problem. We can keep leaving hppa there if you want to double check them (HPPA is not a problem as it has a stable tree that is small enough to be maintainable)
Re: [gentoo-dev] Suggestion about how to tell ATs that a package can be stabilized on all arches at the same time
On Sun, 08 Feb 2015 11:17:19 +0100 Pacho Ramos wrote: > Many times has raised the question about how we could handle those > packages (like icon packs, wallpapers...) that are not arch dependent > and, then, could be stabilized all at the same time by the first arch > team that is going to stabilize it. If you do that, then what is the point of having a stable request in the first place? The many-eyeballs argument is gone then, so what are we left with? It isn't a team that is doing the stabilisation, it's a single person who may or may not have looked at what the new version does and how well it installs, and may or may not feel some pressure to rush it. As I said before many times, having more people on more architecture teams look at the same problem actually helps catch bug at a late stage but arguably still in time. Removing or weakening that last line of defence (either by having a single person do stabilisations for multiple architectures, or by removing most architecture teams from each single task) will increase the bug rate for stable ebuilds (even more). jer
