Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Most of the time, when people are moaning about 'slacker' archs, they don't have any kind of decent technical reason for doing so... In cases where such a reason exists, the arch teams are usually quite happy to prioritise if asked. And the point of me asking for the council to talk about this is to set some kind of guidelines for what happens after you've asked X number of times and let Y number of days go by, where X and Y are amounts open for discussion. Caleb -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Improving use.desc
On Jan 4, 2008 6:31 AM, Donnie Berkholz [EMAIL PROTECTED] wrote: Are there any programs (make.conf / USE editors) that manage to read and set that stuff? Paludis read and show them. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Last rites: some sci-mathematics packages
On Jan 4, 2008 1:30 PM, Sébastien Fabbro [EMAIL PROTECTED] wrote:
sci-mathematics/ksimus-{boolean,datarecorder,floatingpoint}:
unmaintained upstream since 2003, see bug #157577
Replacements: unknown
Scilab's Scicos ? Not a direct replacement, but there are some similarities.
Denis.
Re: [gentoo-dev] Last rites: some sci-mathematics packages
Sébastien == Sébastien Fabbro [EMAIL PROTECTED] writes: Sébastien sci-mathematics/pariguide: unmaintained since 2002 Is there anything actually wrong with this one? I don't see any bugs open on it, and it works fine here. Dropping packages just because they are stable is rather questionable. -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Fri, 4 Jan 2008 06:23:11 -0500 (EST) Caleb Tennis [EMAIL PROTECTED] wrote: Most of the time, when people are moaning about 'slacker' archs, they don't have any kind of decent technical reason for doing so... In cases where such a reason exists, the arch teams are usually quite happy to prioritise if asked. And the point of me asking for the council to talk about this is to set some kind of guidelines for what happens after you've asked X number of times and let Y number of days go by, where X and Y are amounts open for discussion. X and Y are pretty much irrelevant. The important factor is Z, the impact of leaving things the way they are. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Bug Day Saturday January 5th, 2008
Roy Bamford schrieb: It's that time of the month again, time for another Bug Day on Saturday 5th January. Yep, that's the first bug day of 2008. Join us in #gentoo-bugs on irc.freenode.net to help squash some bugs and meet up with fellow users and developers. Read all about it http://bugday.gentoo.org/ Friendly reminder, bugday is tomorrow :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Fri, 4 Jan 2008 17:26:39 -0500 (EST) Caleb Tennis [EMAIL PROTECTED] wrote: X and Y are pretty much irrelevant. The important factor is Z, the impact of leaving things the way they are. Well, I'm asking the council to discuss when pretty much irrelevant no longer applies. Compared to the cost of causing yet more arch breakage, which takes huge amounts of time to fix and leads to far more problems, I'd say X and Y should be something like one billion and three billion respectively, except in those rare cases where Z is genuinely significant. Really, I'd like to see some genuine examples of cases where people think they have a legitimate value of Z... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
X and Y are pretty much irrelevant. The important factor is Z, the impact of leaving things the way they are. Well, I'm asking the council to discuss when pretty much irrelevant no longer applies. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: wxGTK 2.8
Ryan Hill wrote: PS. wxpython-2.8 will also be added shortly, after I finish cleaning up a few more packages that break when the two versions are both installed. wxpython-2.8 has now been unmasked. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwindows @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] has_version etc parallelisability
On Mon, Dec 31, 2007 at 02:28:44PM +, Ciaran McCreesh wrote: On Sun, 30 Dec 2007 20:11:16 -0800 Alec Warner [EMAIL PROTECTED] wrote: On 12/30/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: Is it legal for ebuilds to call has_version and friends in parallel? Is it legal for ebuilds to call has_version and friends after the ebuild process has terminated? Discuss. If the pm implements read/write locking on the underlying datastore (which it should probably have regardless of this request) then I don't see a problem in parallel has_version calls. Actually, it's the communication channel that's the issue... If, for example, has_version is implemented in terms of a request on a pipe rather than execing a new package manager, we get into messy bash locking territory... I don't get your second example..do you mean the ebuild is running has_version in the background and then terminating? Yeah. Again, consider the pipe example. If the package manager closes off the pipe when it thinks the ebuild's done, calling has_version will get the backgrounded process SIGPIPEd. Depends on the implementation; for pkgcore, if that comm pipe is dead, the ebuild env *should* be dead, or dieing. Background'ing processes from that env isn't valid imo, either. If you're refering to an ebuild that parallelizes itself while executing, iow, parallelization w/in the ebuild env/phase execution, I'd look more at being able to batch commands instead of trying to run them in parallel. Reasoning follows- 1) if doing an exec approach to service the request, this means reparsing of involved files for each request- inefficient, potentially horribly so on crappy hardware/setups. 2) screws up the pipe approach, should folks take it for control/env introspection gains. Summarizing, executing has_version (and friends) concurrently has it's own issues performance wise, and implementation wise; growing batch functionality into portageq however avoids those issues, and would be faster- thus the route I'd advocate. ~harring pgpQjljDYcTPp.pgp Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Fri, 2008-01-04 at 21:02 +, Ciaran McCreesh wrote: X and Y are pretty much irrelevant. The important factor is Z, the impact of leaving things the way they are. ...and the idea is to let the Council decide what level of Z is acceptable. Currently, it appears as if the issue is maintainers being forced to keep abhorrently old versions of packages, including security-vulnerable packages, simply because a security-unsupported architecture hasn't had time to test/update/whatever. This has been an issue for quite some time. Of course, the impact is debatable, but it seems that we cannot agree ourselves on what is agreeable, so I see this as a point to bring to the Council simply so it can be resolved once and for all and things can resume normal operation. I know that I, as an ebuild developer, would be much more comfortable/accepting of having to keep around old versions of packages, if the Council had deemed it to be something important enough. No offence to any alternative architectures or their hard-working team members, but there are some times when we have to look at the common good, and forcing maintainers to spend time keeping older ebuilds that are possibly using older ebuild code and other idiosyncrasies versus the current versions for the more mainstream architectures simply might not be worth it for architectures with a very minimal number of users. I've heard some suggestions for removing stable KEYWORDS on arches that aren't security supported. I see this as a possible solution to such issues, since ~arch packages aren't security-supported in the sense of GLSA and such, so why not keep arches which aren't security-supported from having stable KEYWORDS? Of course, this is a global change which affects multiple architectures, so it should be deferred to the Council. I don't really think it requires a large amount of discussion simply because it is simple to see how it would come to a swift stand-still. The arch teams affected will want nothing to change, the package maintainers will want to make things easier on themselves. This is to be expected. We elect the Council for a reason. Making decisions like this is one of them. Let's let them do their job and follow their leadership. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Fri, 2008-01-04 at 22:37 +, Ciaran McCreesh wrote: Really, I'd like to see some genuine examples of cases where people think they have a legitimate value of Z... How about we base X Y and Z on the number of verifiable users of said arch? That's just as arbitrary and fits with the normal pink ponies philosophy of pulling complete bullshit out of the air and using it as a justification or argument. Maybe we'll base it on how many months they've been security-supported? No offense to anyone, but holding back hundreds of developers and thousands of users for a handful of developers, who could do their jobs just as well without stable KEYWORDS, and an nearly as small number of users, just isn't worth it to us all. How many users do you really think breaking some of these arches affects? If the architecture (or its team) is incapable of maintaining stable KEYWORDS in a timely manner, why should we care about them, again? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Fri, 04 Jan 2008 20:20:18 -0800 Chris Gianelloni [EMAIL PROTECTED] wrote: No offense to anyone, but holding back hundreds of developers and thousands of users for a handful of developers ...and how exactly are hundreds of developers and thousands of users being held back? So far as I can see, in cases where anyone really is being held back, the arch teams are quite happy to prioritise -- the people who go around moaning about 'slacker archs' rarely if ever actually have anything holding them back. If anyone has any examples of where they really are being held back and where they really have given the arch teams plenty of time to do something, I'd like to see them... Somehow I doubt it happens very often, if at all. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] has_version etc parallelisability
On Fri, 4 Jan 2008 18:50:56 -0800
Brian Harring [EMAIL PROTECTED] wrote:
Depends on the implementation; for pkgcore, if that comm pipe is
dead, the ebuild env *should* be dead, or dieing. Background'ing
processes from that env isn't valid imo, either.
Right. Paludis will give a weird die message but not actually fail if
you do:
src_compile() {
{ sleep 10 ; has_version '=app-misc/foo-1.23' ; }
}
If you're refering to an ebuild that parallelizes itself while
executing, iow, parallelization w/in the ebuild env/phase execution,
I'd look more at being able to batch commands instead of trying to
run them in parallel.
That's its own slippery slope. Because of limited size pipes, the
following causes all sorts of trouble:
pkg_setup()
{
portageq match ${ROOT} cat/some-pkg | while read a ; do
if has_version =${a} ; then
echo yes to ${a}
else
echo no to ${a}
fi
done
}
The problem is thus: the has_version and portageq match here can be run
in parallel by bash. The portageq match output can be longer than the
maximum size of a pipe. Thus, if the above is legal, no lock that is
visible to the has_version can be held by portageq match once it starts
producing output.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
