[gentoo-dev] retirement
Hi folks, I've decided to retire as a Gentoo dev. I've been a dev for almost exactly 3 years as part of the Haskell team. I was team leader for a year or so. I managed to recruit kolmodin a couple years ago and handed team leadership over to him a few months ago. It's now his turn to recruit some more people to keep the Haskell team well staffed. My decision is based on real world time commitments. I'm in the late stages of writing up my PhD thesis and I've recently started a Haskell consultancy company . I don't intend to do much less work packaging but I intend to shift my focus from Gentoo packaging to the central Haskell packaging infrastructure http://hackage.haskell.org/. All QA improvements there benefit Gentoo. I'll still have commit access to the haskell overlay and to the hackport tool for automatically converting packages hackage->portage. I'll still be in #gentoo-haskell if you want to find me. I'd like to thank everyone for being welcoming and friendly and answering my stupid questions. Thanks especially to the arch teams for all the time they put in for us in testing and stabilising Haskell packages on such a wide range of platforms. I feel I should also apologise to jer for constantly breaking ghc on hppa ;-). Thanks also to jakub for his work filtering and redirecting bugs to us, along with the occasional helpful insight. Best of luck everyone. -- Duncan Coutts : (ex-)Gentoo Developer (Haskell team) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] The future of ebuild
On Sun, 2008-02-24 at 13:02 +0200, Felipe Contreras wrote: > > Take a look at Nix. It's a distribution-agnostic package manager that > > uses a purely functional DSL for package specifications. > > http://nix.cs.uu.nl/index.html > > That's exactly what I'm taking about :) I'll try it out. Thanks for > sharing the link. > > Is there any interest in the Gentoo community to migrate to Nix? It's quite a radical departure and requires more accurate information about packages. We'll see how the NixOS people get on. -- Duncan Coutts : Gentoo Developer (Haskell team) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] The future of ebuild
On Wed, 2008-02-20 at 22:40 +0200, Felipe Contreras wrote: > The core of a distribution is the "packaging" system, and the core of > the packaging system is the building system, which has no reason not > to be distribution agnostic, and actually, packaging system agnostic. > > Why not create a new build system with a state of the art programming > language, and an advanced DSL that actually other distributions could > use? > > I would like to hear your opinions on this matter. Take a look at Nix. It's a distribution-agnostic package manager that uses a purely functional DSL for package specifications. http://nix.cs.uu.nl/index.html -- Duncan Coutts : Gentoo Developer (Haskell team) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] I want to steal your tools
On Sat, 2008-02-02 at 22:54 -0800, Alec Warner wrote: > So it seems to me that we have tons of tools out there that people > have writtten and we need to aggregrate and document them. > > I don't care necessarily how shitty they are, how old they are, what > language they are in, or even who wrote them. I care that they are > open source or public domain; that they are useful etc... > > So reply with a URL pointing at your tool*. Please don't attach your > tool to the email as that would make our mail server sad. If you need > space; e-mail your tool to me (not the list) and I will host it > somewhere. The Haskell team wrote and use 'hackport', a tool for converting Haskell Cabal packages into ebuilds: emerge app-portage/hackport-darcs from the haskell overlay or darcs get --partial http://haskell.org/~gentoo/hackport/ Usage: # gets the package list from the hackage server hackport update # add a new ebuild into the local overlay hackport merge xmonad -- Duncan Coutts : Gentoo Developer (Haskell team) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New developer: Justin Bronder (jsbronder)
On Fri, 2007-11-16 at 14:40 +0200, Petteri Räty wrote: > It's my usual please to announce a new ebuild monkey. Justin hails from > Brighton, Massachusetts. His educational background should provide a > good theoretical approach to all the future flames on gentoo-dev: > "I'm pretty much self taught computer wise as I went to the University > of Maine in order to get my Master's in Mathematics where I focused on > abstract algebra and number theory, I liked the challenges of > discovering proofs, and pretty much ignored any real applications." > > Please give him the normal welcome. Welcome Justin! If you like beautiful code with firm mathematical underpinnings and a slight lack of real applications you'll love Haskell ;-) You're most welcome to come chat with us in #gentoo-haskell -- Duncan Coutts : Gentoo Developer (Haskell team) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] packages.gentoo.org lives!
On Tue, 2007-11-13 at 18:58 -0800, Robin H. Johnson wrote: > After a LOT of development, Gentoo Infra is pleased to announce the > return of the new packages.gentoo.org site. The new site is a complete > rewrite. Yay! It's soo useful for getting an overview and planning what work we need to do next in our team. It's really great to have it back. > Thanks to everybody that worked on this: > - jokey, starting this version > - cla, the visual template for this version > - robbat2, way too much coding and infra wrangling Thanks folks. -- Duncan Coutts : Gentoo Developer (Haskell team) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] New leader for Haskell team
I'm pleased to announce that Lennart Kolmodin (kolmodin) is taking over from me as the Haskell team lead. He will be continuing our plans towards world domination, starting with getting ghc-6.6.x and related libs into a sane state and into portage. All hail our new Haskell overlord. -- Duncan Coutts : Gentoo Developer ((no longer) Haskell team lead) email : dcoutts at gentoo dot org -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Scheme herd team needs some love
On Sat, 2006-11-04 at 06:47 -0300, [EMAIL PROTECTED] wrote: > On Fri, Oct 27, 2006 at 11:33:15PM -0500, Matthew Kennedy wrote: > > > If you have an interest in Scheme and the Gentoo project, I encourage > > you to go through the new developer process and start maintaining > > these Scheme ebuilds. > > I am interested in Scheme and the Gentoo project, but I am not a > developer. As was posted on the latest GWN, maybe it would be a good > idea to enter the recruiting process so that I would become a developer > and help the scheme herd. > > I am a professor at the Computer Science department of an university on > my country. As a professor I have interests on programming languages, in > particular, functional programming languages. Yay! :-) We can always do with more people with an interest in functional programming languages. We have fairly strong Haskell and Caml teams but seem to be quite short on people interested in the untyped lisp-like functional languages. > Currently I am at the end of a compiler construction course, and next > I will start teaching an Object Oriented Programming course to > Computer Science undergraduates. I also teach FP, compilers and OOP to undergraduates :-) > I hope I qualify to the "job". So you've clearly got great credentials. The process to qualify involves learning a lot about how Gentoo works, including management, ebuilds, portage, cvs and bug tracking. As others have said, the best way to start is to look at fixing some open bugs or contributing new ebuilds. You'll want to take a look at the Gentoo developer handbook: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml In particular here is the section on becoming a developer: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=2 -- Duncan Coutts : Gentoo Developer (Haskell team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] a new TLP to "unify" programming langiages?
On Wed, 2006-10-11 at 17:24 +0200, George Shapovalov wrote: > Hi gang. > > As I looked for a place where to put some documentation naturally falling in > a "project domain" for Ada, I realized that we have TLPs for many individual > (programming) languages. First I though to ping some people on irc, but, as I > went down the page the noticed number became nontrivial, so I decided to > throw an email here instead. > > Basically the idea is that a TLP for an individual language is way too much - > most of them do not have subprojects anyway. Therefore lets try to organize > it a bit better? At least documentation-wise. We will have to see whether > there will be any additional correllation further on (and indeed there might > be, for example for the different gcc-backends), but even if not I think it > is better to keep the main projects page more structured. > > What I propose is to create a TLP page for "Gentoo Programming Resources" (or > pick your name) and move all the individual languages into the subdirs of it. > Any opinions? If I get any "yay's" or no "nays" I'll create a bug about it > and then we can finalize the layout there.. > (I just like to keep the trace of what is being done and the related > discussions). I'd certainly say 'yay' for the Haskell team. We'd be quite happy to be a sub-project of some prog lang TLP. -- Duncan Coutts : Gentoo Developer (Haskell team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: Alexis Ballier (aballier)
On Mon, 2006-10-09 at 19:40 +0200, Christian Heim wrote: > Its my pleasure to introduce to you Alexis Ballier (also known as aballier), > our latest addition joining to help out with the media-sound and media-video > herd. Welcome Alexis. > His skillset only includes the basic linux languages (that being beneath > English, C and C++, but also BASH) and ocaml (wtf is ocaml? - thanks to Alec > I know that now). Well perhaps he'd be interested in joining the ml team (dev-lang/ocaml is in the ml herd). Obviously it's not quite as glorious as Haskell, but at least it's functional. ;-) > He's currently finishing his master degree in computer science (another > one :P) and will be a PhD student next year. Yay, another one. I wonder how many gentoo devs have a PhD or are in the process of trying to get one... -- Duncan Coutts : Gentoo Developer (Haskell team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Thu, 2006-10-05 at 09:52 +0300, Alin Nastac wrote: > Natanael Copa wrote: > > Nobody has ever showed interest and I'm not pushing my services on > > anyone. > > > Why exactly you don't want to become a Gentoo dev? The whole "proxy > maintainer" thing is a bunch of crap. The Gentoo developer will still be > expected to be responsible of his/her commits, which means 2 maintainers > will spend (approximately) same amount of time testing it. It does mean you can sometimes offload work onto other people, eg upstream maintainers - who are themselves not interested in becoming devs but are more than happy to maintain their single ebuild. And it does actually mean less work for us because although we still have to test it, we can rely to some extent on the testing done by that maintainer and by other users who regularly build from our overlay. Also it means we don't have to look out for upstream releases because they 'darcs send' in their updates and we just take responsibility for QA and getting things into portage cvs. -- Duncan Coutts : Gentoo Developer (Haskell team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 2006-10-04 at 17:13 -0400, Chris Gianelloni wrote: > With the increase in developer and project overlays, I see the > possibility for reducing work needed to maintain many packages. As > Natanael Copa, it would be nice for him to be able to maintain packages > without having CVS access. The idea of formalizing and promoting "proxy > developers" has come up a few times before, and I think it is a great > idea. Work is done in the overlays, tested, improved, then committed > into the main tree once the kinks have been worked out. We get a > stronger core tree with fewer "developers" and a better interaction with > the community. Some projects/herds already work this way with good results. We regularly get contributions from users that go into our overlay, get tested by us and other users and then get into the main portage tree some time later. We have a very low barrier to entry, it's just darcs record; darcs send. Then one of the devs reviews and applies/rejects the patch. Easy. For some of our ebuilds we already have de-facto "proxy developers". -- Duncan Coutts : Gentoo Developer (Haskell team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC about another *DEPEND variable
On Sat, 2006-09-23 at 06:13 -0400, Mike Frysinger wrote: > On Thursday 21 September 2006 11:41, Duncan Coutts wrote: > > On Thu, 2006-09-21 at 11:11 -0400, Mike Frysinger wrote: > > > On Thursday 21 September 2006 10:56, Duncan Coutts wrote: > > > > If we do go in this direction it'd be great to be able to slot on the > > > > ABI and still have dependencies resolved correctly. For example imagine > > > > having parallel python-2.3 and 2.4 installations with some libs > > > > installed for both. Crucially, deps need to be resolved to the version > > > > of a lib with the right ABI. > > > > > > ugh, no ... we are not a binary distribution so we should not have to > > > worry about ABI baggage > > > > So we can't ever install two versions of python or ghc at once? That > > seems a shame. > > that's an issue for the python or ghc maintainers to address Yes and as ghc maintainer for Gentoo I'd love to be able to do it. It is easy to install more than one version of ghc at once as it uses versioned directories etc. The problem is that we cannot correctly resolve dependencies with the current versions of portage. Hence we cannot effectively do it. I was worried from your ABI/API comments that you meant that we should never be allowed to do it. As I said before, if we were to SLOT ghc and the various dev-haskell/* libs on the ghc version then we would run into this problem: assume dev-haskell/foo needs dev-haskell/bar supposing dev-haskell/bar was installed and sloted for ghc-6.2 now I install ghc-6.4 too now I emerge dev-haskell/foo. portage will use the existing installation of dev-haskell/bar even though it was installed for another version of ghc. Therefore the build will break (think of haskell libs of having a SONAME that is the version of ghc they were built with). What needs to happen is to install dev-haskell/bar sloted for ghc-6.4 and use that. Currently there is no way to explain these dependencies to portage. I was hoping that with this talk of tracking reverse deps and such like that we could move in a direction where this kind of dependency could be supported. Even if we can't slot on the ghc version, automatically rebuilding for the latest ghc version would be a great improvement - like the suggestion to rebuild dependent libs when the SONAME changes. Duncan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC about another *DEPEND variable
On Thu, 2006-09-21 at 20:27 +0200, Luca Barbato wrote: > Duncan Coutts wrote: > > > > > So my point is, I don't think it can be simply dismissed as ABI nonsense > > that we don't have to deal with. Being able to SLOT on the compiler > > flavour (and possibly version) would allow us to do useful things that > > we cannot currently do. > > what about making them build what you want depending on useflags? Aye, for the implementation flavours that's probably the way to go once we have use-deps. We'll have to hold off on multiple versions of the same compiler though. It might get a bit hairy though :-) DEPEND="ghc? ( dev-haskell/foo @ ghc ) hugs? ( dev-haskell/foo @ hugs ) yhc? ( dev-haskell/foo @ yhc ) jhc? ( dev-haskell/foo @ jhc )" (I've not looked up what the use-dep syntax is, I'm just guessing) Duncan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC about another *DEPEND variable
On Thu, 2006-09-21 at 11:11 -0400, Mike Frysinger wrote: > On Thursday 21 September 2006 10:56, Duncan Coutts wrote: > > If we do go in this direction it'd be great to be able to slot on the > > ABI and still have dependencies resolved correctly. For example imagine > > having parallel python-2.3 and 2.4 installations with some libs > > installed for both. Crucially, deps need to be resolved to the version > > of a lib with the right ABI. > > ugh, no ... we are not a binary distribution so we should not have to worry > about ABI baggage So we can't ever install two versions of python or ghc at once? That seems a shame. > we SLOT based upon API, not ABI Here's another example; I'm not sure if it passes the ABI/API test: We would like to support 3 Haskell implementations: * GHC which compiles to native code (ELF binaries & static .a libs) * Hugs which is an interpreter so installation is .hs source files * YHC which compiles to portable bytecode A single Haskell library is likely to work with all three implementations. So that's API. Once installed however each implementation is very different. So that's incompatible ABI. This could be 'solved' by having dev-haskell/foo-ghc, dev-haskell/foo-hugs, dev-haskell/foo-yhc, but that's obviously not the Gentoo way (though it's pretty much what debian does). These multiple impls is pretty similar to multiple versions of the same compiler. So my point is, I don't think it can be simply dismissed as ABI nonsense that we don't have to deal with. Being able to SLOT on the compiler flavour (and possibly version) would allow us to do useful things that we cannot currently do. Duncan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC about another *DEPEND variable
On Thu, 2006-09-21 at 09:52 -0400, Mike Frysinger wrote:
> On Thursday 21 September 2006 07:59, Brian Harring wrote:
> > Why have the explicit var? Because 0.9.7a through 0.9.7c may all be
> > compatible, but 0.9.7d isn't. If you force an automatic algo that
> > tries to (effectively) guess, you get a lot of rebuilds through a,b,c,
> > end result being folks likely update less because it becomes a bigger
> > pain in the ass.
>
> if it isnt compatible then it shouldnt have the same SONAME, simple as
> that ... that is after all the point of encoding the ABI version number into
> the SONAME
>
> forcing devs to maintain a manual var which is basically duplicating the
> SONAME smells like maintenance nightmare
There are various kinds of ABI. Certainly for C libs the SONAME is
probably the most common. If we go for some kind of ABI reverse deps
feature I would beg for something a little more general - though
certainly with SONAME as a common case.
Other languages have similar problems. For example Python has
incompatible ABIs for each major release 2.2, 2.3 etc. They have a
similar solution to the revdep-rebuild: python-updater.
As lead of the Haskell team my interest in this is that our primary
Haskell compiler GHC has ABI incompatibility between versions too. We've
made a ghc-updater similar in style to the python one but this is
clearly an unsatisfactory situation. It's more acute for us as even
minor revisions are ABI-incompatible.
So for it's something like:
# for C:
ABI=${SONAME}
# for python
ABI=${PY_PV}
# for haskell:
ABI=${GHC_PV}
paludis has something going in this direction but I don't think it'd
quite solve the python/ghc abi issue. It was aimed more at cases like
mips with it's multiple abis.
If we do go in this direction it'd be great to be able to slot on the
ABI and still have dependencies resolved correctly. For example imagine
having parallel python-2.3 and 2.4 installations with some libs
installed for both. Crucially, deps need to be resolved to the version
of a lib with the right ABI.
debian solves this problem in an ad-hoc way by tacking extra components
into the package name:
pyfoo-py22.deb which deps on pybar-py22.deb
pyfoo-py23.deb which deps on pybar-py23.deb
so all can be installed at once and deps are resolved within the right
ABI. Now this is obviously not in the Gentoo tradition. We much prefer
cleaner solutions like SLOTing. I would love to see this extended to
allow us to SLOT on the abi and then correctly resolve based on that
abi.
If we just SLOTed at the moment we'd get the sitation where
dev-python/bar built for py 2.2 would be considered ok to satisfy a
dependency of dev-python/foo that is being built for py 2.3.
We want some kind of extra component to be able to resolve on:
dev-python/foo-1.0.ebuild:
SLOT="${PV}-${PY_PV}"
ABI="${PY_PV}"
DEPEND="dev-python/bar @ ${PY_PV}"
Actually for Haskell the situation is even more fun; we have multiple
haskell implementations, so we would like to install a lib and SLOT upon
and correctly resolve deps for multiple haskell compilers.
Fun stuff. :-)
If portage people are interested in moving in this direction we have an
experimental emerge-compatible mini dep-resolver which might be useful
to prototype an extended ABI/SLOTing system.
Duncan Coutts
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New darcs.eclass
Since there were no objections the darcs.eclass is now in the main tree. On Thu, 2006-05-18 at 22:58 +0100, Duncan Coutts wrote: > Just like we have eclasses for cvs, tla etc, kosmikus has written one > that does the same thing but for darcs. > > Darcs (dev-util/darcs) is one of the new breed of distributed source > control systems. Many projects are now maintaining their development > sources in darcs, hence the utility of this eclass: > > http://haskell.org/~gentoo/gentoo-haskell/portage/eclass/darcs.eclass > > kosmikus adapted it from the cvs and tla eclasses. We've been using it > for some time in the Haskell team's overlay and we've had a request to > include it in the main tree. > > http://bugs.gentoo.org/show_bug.cgi?id=128307 > That request includes an implementation but we're proposing our own > implementation that is a bit more sophisticated and has already been > tested with a few *-darcs ebuilds. > > So we'd like to have people's opinion/comments on this going into the > tree and of course we would appreciate code review etc. -- Duncan Coutts : Gentoo Developer (Haskell team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New darcs.eclass
In case anyone needs distracting from a current hot topic... Just like we have eclasses for cvs, tla etc, kosmikus has written one that does the same thing but for darcs. Darcs (dev-util/darcs) is one of the new breed of distributed source control systems. Many projects are now maintaining their development sources in darcs, hence the utility of this eclass: http://haskell.org/~gentoo/gentoo-haskell/portage/eclass/darcs.eclass kosmikus adapted it from the cvs and tla eclasses. We've been using it for some time in the Haskell team's overlay and we've had a request to include it in the main tree. http://bugs.gentoo.org/show_bug.cgi?id=128307 That request includes an implementation but we're proposing our own implementation that is a bit more sophisticated and has already been tested with a few *-darcs ebuilds. So we'd like to have people's opinion/comments on this going into the tree and of course we would appreciate code review etc. -- Duncan Coutts : Gentoo Developer (Haskell team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] overlay support current proposal?
On Fri, 2006-03-31 at 10:24 +0200, Fernando J. Pereda wrote: > On Fri, Mar 31, 2006 at 09:16:17AM +0100, Stuart Herbert wrote: > > Hi Aron, > > > > On 3/30/06, Aron Griffis <[EMAIL PROTECTED]> wrote: > > > I think we might be best to try three revision control systems to > > > start: darcs, git and subversion. Three seems like a lot, but each > > > has its reason, and we can anticipate darcs being used primarily by > > > the haskell team rather than for overlays in general. > > > > Many thanks for the summary. I'll find some time to look at how we > > can support darcs and git, and I'll post some news when I have some :) > > Feel free to contact me if you need help with Git. And likewise, free to contact me if you need help with Darcs. Current keyword status of darcs, git and mercurial: all are ok on alpha, amd64, ppc and x86. darcs and mercurial are ok on ia64 darcs and git are ok on ppc64 and sparc git is ok on hppa and mips hppa should be easy, ghc already works there. We're working on getting ghc working on mips (it works fine on Irix) but no promises. -- Duncan Coutts : Gentoo Developer (Haskell herd team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] overlay support current proposal?
On Fri, 2006-03-24 at 22:47 -0800, Ryan Phillips wrote: > We need to pick one VCS and only one. Having multiple systems > requires users to install multiple applications and learn each one. > Not all of them are easy to pick up. Plus, it would be nice to be > able to merge from the overlays to the Portage trunk. I'm not sure it is realistic at the moment to pick just one DVCS. Apart from getting one that works on all systems, it's likely to be hard to get everyone to agree. There's a slight danger that the discussion of which VCS could distract us from the important questions. If we're going with the idea that at least at first these overlay are going to be run by and for projects/teams/herds then perhaps the choice of VCS is not so important. So long as it's feasible with infra of course. Since we don't yet expect people to be using several of these overlays at once it's probably that each developer or outside contributer would not need to use more than one VCS (in addition to cvs for portage). As a plus side, this might give us some feedback on which (D)VCSs work well for overlay development and might help inform our future decisions on possible cvs replacements. BTW I hope that with all my recent emails on the issue of which arches/platforms can run darcs I've not been giving the impression that I'm pushing for darcs to be the "one true" choice. I am certainly interested in working with any arch team to get ghc and darcs ported but that's a separate issue. -- Duncan Coutts : Gentoo Developer (Haskell herd team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] overlay support current proposal?
On Sat, 2006-03-25 at 13:32 +0100, Kevin F. Quinn (Gentoo) wrote: > On Sat, 25 Mar 2006 11:46:58 + > Duncan Coutts <[EMAIL PROTECTED]> wrote: > > > On Sat, 2006-03-25 at 12:42 +0100, Kevin F. Quinn (Gentoo) wrote: > > > > > This is a valid issue, as ghc is only supplied upstream for linux > > > (some older versions available in mingw32). > > > > I don't think this is right. All the recent ghc versions have been > > supplied upstream on many OSs including installers for win32 and OSX. > > The OpenBSD, FreeBSD & Darwin ports systems include ghc. > > Sorry, yes - I looked at the snapshot download pages where it's linux > and mingw32) instead of the release download pages (where it's linux > x86, x86_64, ppc, ppc64 and windows, FreeBSD x86, OpenBSD x86, MacOS X > and AIX). > > However the issue still remains for non-x86/ppc platforms; sparc in > particular is likely to be used as a dev platform by some. I use ghc and darcs on my sparc box all the time. ghc-6.4.1-r2 is currently marked stable on sparc. darcs is currently marked ~sparc. I'm currently working on ghc for ia64 since Aron Griffis was interested in using darcs on ia64. It's looking good so far. As Flameeyes pointed out our main problem is with the various Gentoo/ALT systems where we don't have quite enough developer time to allow ghc to get near the top of the TODO list (though we do have it working with ppc osx). -- Duncan Coutts : Gentoo Developer (Haskell herd team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] overlay support current proposal?
On Sat, 2006-03-25 at 12:42 +0100, Kevin F. Quinn (Gentoo) wrote: > This is a valid issue, as ghc is only supplied upstream for linux (some > older versions available in mingw32). I don't think this is right. All the recent ghc versions have been supplied upstream on many OSs including installers for win32 and OSX. The OpenBSD, FreeBSD & Darwin ports systems include ghc. -- Duncan Coutts : Gentoo Developer (Haskell herd team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] overlay support current proposal?
On Sat, 2006-03-25 at 03:31 +0100, Diego 'Flameeyes' Pettenò wrote: > Darcs, instead, is written in Haskell, which means you need architectures > that > supports Haskell, and in which it's stable enough to work... considering we > have Gentoo/Alt, it's not that good to "cut" us off (yes I know I should be > able to make Gentoo/FreeBSD and maybe other arches to have ghc, We've got ghc working on ppc-osx and ghc of course works on FreeBSD (it's in FreeBSD ports) so all it needs is a helper for Gentoo/FreeBSD. I know you're busy of course but it doesn't need your time specifically, anyone using Gentoo/FreeBSD could do it. We can walk them through the process. We're working on ia64 support. s390 support would be possible if we had access to the hardware. The only arches we don't have much hope of supporting are arm, mips and sh. (It works on mips on irix but we have problems with GOT overflow on mips linux.) -- Duncan Coutts : Gentoo Developer (Haskell herd team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Official overlay support
On Thu, 2006-03-23 at 18:55 +, Chris Bainbridge wrote: > On 23/03/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote: > > On Thu, 2006-03-23 at 16:40 +, Chris Bainbridge wrote: > > > If the software a user wants is in an overlay, then the user will be > > > forced to install the overlay. > > > > It shouldn't be in the overlay, is I think the point many are trying to > > make. If the software is good enough for any of our users, it should be > > good enough for the tree. > > I agree. I would ask, what are the advantages of overlays that > developers find so compelling that they use them rather than the > portage tree? Would it not be a better idea to find a way to bring > those advantages to the tree, rather the proliferation of overlays we > are seeing? The advantages we see are: We use it as a staging area for our herd's ebuilds. We can start with an untested ebuild and between several team members and outside testers we can iteratively test and refine the ebuild. This relies on a low latency between committing changes and other devs and outside testers receiving those changes. We have a lag of several seconds rather than 30 minutes for the anoncvs. It means we get much higher QA before ebuilds actually end up in portage because by the time they get there they have been reviewed and tested by other team members and outside helpers (often including testing on several arches). If we did this in the cvs tree we'd need to keep the packages masked all the time we were improving them (overhead). We'd need changelog entries for every change (overhead). We wouldn't be able to share the development and testing with our outside helpers (due to anoncvs lag). And of course we wouldn't be able to grant out outside helpers write access. So the lower latency helps to run an AT-style system and the write access allows for a safe intermediate stage in the recruitment process between AT and dev status. -- Duncan Coutts : Gentoo Developer (Haskell herd team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Official overlay support
On Thu, 2006-03-23 at 13:55 -0500, Chris Gianelloni wrote: > I'm sorry, but I am not OK with just standing by and watching us give > complete access to do anything with no accountability. If you are, > perhaps you really need to rethink your commitment to our users and your > fellow developers. The way the Haskell team manages this is that we don't tell our end users about our testing overlay. So we don't get bug reports from them. We have three outside contributers with write access to the overlay repo. They make changes in consultation with the team. So we're not giving complete access without accountability. We have a couple other users who use the overlay but they know what they're doing. We don't make the overlay that easy to use on purpose because we don't want inexperienced users using it. So apart from not advertising it, we don't keep digests in the repo. I think the point is that these overlays should be a useful way of getting contributers more closely involved. However we should not encourage end users to use these overlays without thinking. For example using more than one at once seems like a really bad idea. Perhaps if we make them sufficiently hard to use then end users will not use them and we'll just get the contributers we want. -- Duncan Coutts : Gentoo Developer (Haskell herd team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Official overlay support
(re-sending as I sent from the wrong account) On Wed, 2006-03-22 at 19:42 +0100, Stefan Schweizer wrote: > On 3/22/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > > This definitely sounds like a fun idea. It would be even cooler if we > > were using a distributed SCM on both ends that allowed for easy merging. > > > I think it should be all in a central place possibly saved with > GPG-Keys that need to be signed by trusted persons so that someone can > get access. > Because security seems to be a big problem with a public overlay, but > I think with gpg-key-based-access it could work. Yes, we use gpg signed patches for our darcs overlay system. We add the gpg keys of our trusted contributers to a keychain (on the server where the darcs repo lives). Then they use "darcs send --sign" and their patches get applied automagically. Patches from contributers who don't sign their patches (or if the key check fails) get forwarded to the Haskell herd's email alias so any herd member can review and apply / reject the patches. -- Duncan Coutts : Gentoo Developer (Haskell herd team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Official overlay support
On Wed, 2006-03-22 at 09:03 -0800, Donnie Berkholz wrote: > Stuart Herbert wrote: > > I've been very happy with using svn+trac overlays to bridge this gap. > > They provide a sandbox for contributions to be shared and evaluated. > > They provide a place where I've been able to give commit access to > > non-devs, so that they can learn the ropes w/out threatening the > > Portage tree proper. They provide a place where people who just want > > to write docs for a single package can contribute. > > > > Overlays create a sense of participation that's lacking with Bugzilla > > patch submissions. Backed up with regular communication (I recommend > > not recruiting anyone who won't spend time in the IRC channels, but > > that's a personal preference), they help us get things done quicker. > > > > The downside with overlays at the moment is that they're scattered > > around the net, and if you don't know where to look they can be very > > hard to find. I've been talking with infra about providing > > overlays.g.o as a central hosting service for herd and individual > > developer overlays. Infra have been very supportive of the idea. I > > just need to free up some time to get the service launched. > > This definitely sounds like a fun idea. It would be even cooler if we > were using a distributed SCM on both ends that allowed for easy merging. We do this within the Haskell herd and with a small handful of outside contributers. We use darcs for our distributed SCM which makes the merging trivial. If works like so: We keep our testing ebuilds in a shared overlay managed with darcs. The Haskell herd members have write access. Trusted external contributers have write access to the overlay too (mostly people who are in the middle of the recruitment process). The existing devs are of course responsible for actually committing anything to portage cvs. Other contributers have read only access but they can "darcs send" us patches. These do not automatically get applied (as with our trusted contributers) but get emailed to us and any Haskell herd dev can review and apply patches sent in this manner quite easily. We have found that this system works rather well. It allows our testers and helpers to participate in writing ebuilds which has made the recruitment process smoother. It provides an intermediate phase in the recruitment process where they can participate in the herd's work without any danger of messing up portage cvs. Bugzilla is ok for submitting whole new ebuilds but it's got far too large an overhead for one line patches. Using darcs gives us a very low overhead. We also use the shared overlay as a testing zone for our herd's ebuilds. Our modus-operandi is to commit changes in ebuilds to the overlay, get peer review from other herd members and then commit to portage when we are satisfied. Of course this also makes it easy for our testers to keep up with the latest versions of ebuilds. With the combination of darcs and irc, we can get very quick turnaround on our testers finding bugs to fixing them and getting those changes back to our testers. -- Duncan Coutts : Gentoo Developer (Haskell herd team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] how to turn off hardened gcc flags reliably?
On Thu, 2006-03-02 at 00:41 +, Roy Marples wrote: > On Wednesday 01 March 2006 17:41, solar wrote: > > On Wed, 2006-03-01 at 17:17 +0000, Duncan Coutts wrote: > > > I presume it's a gentoo patch to gcc-4 to add back in > > > -fno-stack-protector? > > > > For the 4.0.x it should be just a dummy call. > > For 4.1 it is included. What does change and is really uncool with 4.1 > > is that -fno-stack-protector-all is missing and wont be added > > back without several somebodies making a case for it upstream. > > > > For the non technically minded folks whats the difference between > -fno-stack-protector and -fno-stack-protector-all? It was explained to me like this: -fno-stack-protector makes gcc use a heuristic to decide whether or not change a function to use stack-smashing protection. -fno-stack-protector-all makes gcc just do it for every function. there is also: -fno-stack-protector-to-all which if supplied makes -fno-stack-protector get promoted to -fno-stack-protector-all. Apparently -fno-stack-protector-to-all is on by default in all current gcc profiles so that means that at the moment if you specify -fno-stack-protector you really get -fno-stack-protector-all. Hope that's clear! :-) -- Duncan Coutts : Gentoo Developer (Haskell herd team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] how to turn off hardened gcc flags reliably?
On Wed, 2006-03-01 at 11:39 -0500, Mike Frysinger wrote: > On Wednesday 01 March 2006 10:35, Duncan Coutts wrote: > > gcc-3 supports both -nopie and -fno-stack-protector. So always using > > these would be ok if it were not for gcc-4 which doesn't grok > > -fno-stack-protector. > > yes it does Oh. I had reports from ppc devs who said that gcc-4 didn't recognise that flag. I also heard that gcc-4 contains a re-written stack protector implementation with different semantics and that was why it didn't recognise the flag anymore. > every gcc in portage by default supports -fno-stack-protector So that includes gcc 4 then. Well that makes life easier. :-) I presume it's a gentoo patch to gcc-4 to add back in -fno-stack-protector? -- Duncan Coutts : Gentoo Developer (Haskell herd team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] how to turn off hardened gcc flags reliably?
All, I'm hoping for some suggestions particularly from the toolchain and hardened profile folk. We have a compiler that goes via C and uses gcc as it's backend. This compiler does some pretty unpleasant things with the assembler output of gcc. For one thing it doesn't use the C stack. It strips off the prelude and epilogue of each function. Anyway, Suffice to say that it doesn't work with hardened gcc; that is both PIE and the stack protector. However turning these features off (by passing -nopie -fno-stack-protector to gcc) is not so easy when we consider that people can upgrade their gcc or change from a vanilla to a hardened profile *after* emerging ghc. gcc-3 supports both -nopie and -fno-stack-protector. So always using these would be ok if it were not for gcc-4 which doesn't grok -fno-stack-protector. If we don't use -fno-stack-protector then if someone changes from a vanilla gcc profile to a hardened one then the users will get breakage when they start using ghc again. We could have the ghc driver script work out dynamically which flags to pass to gcc to suppress the hardened stuff but I think we can all see the downside to that. We could say "don't switch to a hardened gcc profile - it doesn't work". We could say "don't use gcc 4 - it' not supported". However this will not last forever. We could ask the gcc-config people for some assistance. Perhaps by adding an extra env var GHC_CFLAGS that gives us the right flags. Or perhaps by hooking into gcc-config to have our flags updated whenever the user changes profile. Does anyone have any other suggestions? -- Duncan Coutts : Gentoo Developer (Haskell herd team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] check-reqs conditionals
On Sat, 2006-02-11 at 22:42 +, Ciaran McCreesh wrote: > For those of you who don't know, check-reqs is an eclass that is > occasionally used by a few packages that have ludicrously high build > requirements. Typical examples have included anything using Haskell (the > programming language with built-in memory leaks!) and certain C++ > template metaprogamming voodoo. > > Currently it just exports a single function that will warn (or die, > based upon user preference) if the build requirements aren't met. There > has been a request for a clean way of handling packages that can be > built in two different ways that give the same end result (typical > example is use of a really slow but low memory requiring algorithm vs a > fast but memory intensive algorithm when building data tables). > > How does something like the attached look? (Yes, it's using old-school > [ rather than [[, since the rest of the eclass is written that way. I > might switch the whole thing over at some point.) > Thanks Ciaran, this looks great. I've tested it with the dev-lang/ghc ebuild and it looks like it fits our needs. This will help us fix bug #74346. In the ghc ebuild I'll be using it like so: + # The SplitObjs feature doesn't work on several arches and it makes + # 'ar' take loads of RAM: + CHECKREQS_MEMORY="200" + if use alpha || use ppc || use ppc64 || use sparc; then + echo "SplitObjs=NO" >> mk/build.mk + elif ! check_reqs_conditional; then + einfo "Turning off ghc's 'Split Objs' feature because this machine" + einfo "does not have enough RAM for it. This will have the effect" + einfo "of making binaries produced by ghc considerably larger." + echo "SplitObjs=NO" >> mk/build.mk + fi -- Duncan Coutts : Gentoo Developer (Haskell herd team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites: dev-haskell/hugs98-graphics
This package provides a simple graphics library for use with the hugs98 Haskell interpreter. It doesn't work with the older versions of hugs98 that are in portage. While it does work with newer versions of hugs98 it is unnecessary there because they come bundled with an updated version of the same modules. I have package.mask'ed it and it will be removed in a week if there are no objections. It has been broken and unnecessary for quite some time with no bug reports so it does not appear to be used. Duncan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites: dev-lang/nhc98
nhc98 is a Haskell compiler. This package has been masked for several months because its memory management system makes assumptions that are no longer true on 2.6 kernels. This is not easily fixable and the upstream devs no not have the time or inclination to rewrite the runtime system. See also #46943. We do hope to get Yhc into portage when it is ready. Yhc is a fork of nhc98 with a totally rewritten runtime system and many other improvements. However it is not a direct drop-in replacement for nhc98 so there is no point in keeping nhc in the tree until yhc is ready. I there are no objections I will remove this package in a week. Duncan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Keywording, for the umpteenth time
On Fri, 2005-05-20 at 10:42 -0600, Jason Wever wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > OK, let's review this again. > > If you cannot test a given ebuild on a given arch, then don't touch that > arch's keyword (unless you need to remove it for broken dependencies). > > If you can test for a given arch and are not part of that arch team, > please please please let the arch teams know that before you go around > keywording things arbitrarily. It makes the baby Jesus cry when you don't > and really isn't the greatest from a QA perspective either. Sorry folks this was my fault. I've sent my grovelling apology to the sparc team. Hopefully they'll accept my apologies and put my digressions down to me being a new dev. :-) Actually I did do fairly thorough testing / QA but I didn't tell the arch team before keywording (bad me!). In case anyone is interested; this is about the Haskell packages which I hope to get up to scratch on sparc (with the consent and approval of the sparc team in future!) Duncan -- gentoo-dev@gentoo.org mailing list
