On 06/29/04 20:37:59, Daniel Mueller wrote:

...

do you think is possible to work on this issue in the next months? what kind of solution would you suggest? we are ready to contribute in anyway could be useful.

Hmm, since we're using a CVS repository it shouldn't be a problem to mix both architectures, x86 & ppc.

[...]

Variant two: ============

CRUX PPC always gets the latest (main) version of a particular port and modifies it for their ppc edition. The branch tag would be moved from version to version (cvs -b -B -F <TAGNAME>).

myport/Pkgfile: [CVS version tree]

+---------+ +---------+ Branch 1.2.2 -> _! 1.2.2.1 !-X Branch 1.5.2 -> _! 1.5.2.1 ! (PPC-2_0 ppc) / +---------+ (PPC-2_0 ppc) / +---------+ / / / / +-----+ +-----+ +-----+ +-----+ +-----+ ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk +-----+ +-----+ +-----+ +-----+ +-----+ (CONTRIB-2_0 x86)

------------snap--------------

As long as the main branch remains untouched by PPC stuff, I'd be happy to see some CRUX PPC guys at CLC.

Hi Dan, tnx for the reply! For us it's ok. We think that the variant that would best suit our needs is the second one. If it's ok also the others, let us know when we could start to work on the cvs. Best regards. -- Giulivo Navigante CRUX for PowerPC http://cruxppc.sunsite.dk

On 07/01/04 20:11:03, Robert McMeekin wrote:

On Thu, 2004-07-01 at 19:16 +0200, Giulivo Navigante wrote:

...

On 06/29/04 20:37:59, Daniel Mueller wrote:

...

Variant two: ============

CRUX PPC always gets the latest (main) version of a particular port and modifies it for their ppc edition. The branch tag would be moved from version to version (cvs -b -B -F <TAGNAME>).

For us it's ok. We think that the variant that would best suit our needs is the second one. If it's ok also the others, let us know when we could start to work on the cvs.

I think that sounds like a good idea. Perhaps there should be some guidelines on who from CRUX PPC gets CVS access? Maybe something like the CLC MaintainerGuidelines[1]? I'm not sure exactly how that sort of thing is working with CRUX PPC right now. What do you guys think?

can we have a "per user" account solution as it is for x86 maintainers? greetings :) -- Giulivo Navigante GnuPG KeyID: E468396A

Another (completely different) solution would be the following: ls -la ./myport -rw-r--r-- 1 danm danm 40412 May 31 11:46 .footprint -rw-r--r-- 1 danm danm 40311 May 31 11:41 .footprint.ppc -rw-r--r-- 1 danm danm 123 Jul 2 21:31 .md5sum -rw-r--r-- 1 danm danm 686 Jul 2 21:45 Pkgfile -rw-r--r-- 1 danm danm 689 Jul 2 21:41 Pkgfile.ppc -rw-r--r-- 1 danm danm 653 Jul 2 21:42 Pkgfile.i686 pkgmk(8) first looks for a machine specific file (Pkgfile.`uname -m`). Advantages/Disadvantages 1. it's simple 2. we don't need to take care about CVS branches :) 1. too many files for each port.. 2. looks scary 3. needs to be implemented in various tools (pkgmk, prt-get, ..) bye, danm -- Daniel Mueller Berlin, Germany (OpenPGP: 1024D/126EC290)

* ncrfgs <ncrfgs@tin.it> [2004-07-07 23:18]:

On 07/02/04 2i1:27:14, Daniel Mueller wrote: [...]

...

Aside from this, I (personally) would like to know WHO actually plays with the CVS. I mean I know you, because I heard you in IRC & mailing lists and I saw some of your Pkgfiles etc. But who else is 'we' ?

The two users account would be for giulivo and me. Maybe rrm3, jaeger and you already know me.

Just to keep this thread alive until something happens, I confirm knowing them. (-; // Rob

On Wed, Jul 21, 2004 at 09:26:59AM +0200, Johannes Winkelmann wrote:

I know them as well, and judging from their past presence in the mailing list and IRC, it seems to me that they have yet to integrate better. There were some discussions about improvements they'd like to see, but I have never seen them actually implementing one of them (to have a technical instead of a political discussion) or accepting one of Per's or CLC's decisions.

Just because we sometimes disagree with Per's point of view this doesn't mean we don't like it at all. If we are Crux users and spend our time porting it to another architecture there is "some kind" of reason, don't you think? =) And this reason is that we like it and we agree on most Per's opinions, although we disagree on few other ones. Furthermore it doesn't seem to me that having different points of view is a disadvantage. If there wasn't different points of view there would be no GNU, there would be no Linux, there would be no Free Software and maybe you would still be using a proprietary OS from Redmond. =)

but I have never seen them actually implementing one of them

This is because we feel a part of the Crux community and we think that decisions should be taken all together when possible. Implementing some kind of changes to important parts of a distribution such as the package management system on our own would just result in getting more and more away. It was intended as Crux port after all.

The more - as I already tried to point out in [1] - the tone of communication is on a level which hardly helps to raise my interest in their problems [not sure if this this can be said this way].

I'm sure that sometimes you did find yourself flying off the handle, too. Didn't you? =) Everyone can get angry, it happens. BTW I'm afraid that often we get misunderstood also because english is not our first language and what we says sometimes might look rude without intention. It isn't yours, too, we know this. But what can I say? Maybe you're better than us at speaking it. =)

Sometimes it almost seems to me that they are not interested in CLC (as a project) itself, but just having our ports.

If it was so we would simply add the clc.cvsup to /etc/ports/ and we wouldn't have asked to join and we wouldn't, for example, have reported any bug to the tracker. If we'd like to become part of CLC it's because we think it's a great project and we would be glad to contribute to it.

I'm obviously not speaking for the CLC project; personally, I'm more than happy to have non-x86 ports at CLC (even though I don't believe in a CVS based solution ;-)), but at the current point in time I don't think giulivo or "ncrfgs" are good matches for our team.

I hope other members don't think the same way. =) Fergus "NeCRoFaGuS" Incoronato -- Value your freedom, or you will lose it, teaches history. ``Don't bother us with politics,'' respond those who don't want to learn. -- Richard M. Stallman http://www.gnu.org/philosophy/linux-gnu-freedom.html

On 07/23/04 20:01:47, Daniel Mueller wrote:

I've seen that your default crux-ppc cd image comes with 'httpup' and 'curl'. http://cvs.sunsite.dk/viewcvs.cgi/cruxppc/ports/ppc_added_ports.txt

yep but they will not be included in the upcoming 2.0 release thank you for your interest greetings -- Giulivo Navigante GnuPG KeyID: E468396A

Hi, On Sat, Jul 24, 2004 at 13:43:40 +0200, Giulivo Navigante wrote:

On 07/21/04 09:26:59, Johannes Winkelmann wrote:

...

I'm obviously not speaking for the CLC project; personally, I'm more than happy to have non-x86 ports at CLC (even though I don't believe in a CVS based solution ;-)), but at the current point in time I don't think giulivo or "ncrfgs" are good matches for our team.

anyway, as i've wrote in the first email, our intent is to improve crux ppc and have a better integration between clc's ports and crux ppc

in that message i can read this:

do you think is possible to work on this issue in the next months? Well, depends on your definition of integration. If your idea is to develop it in a common Revision Control Repository, the answer is 'no', CVS isn't suitable for this, and we're not planning to move away from CVS (or to put it differently: I'm not aware of a revision control which offers all the advantages of the current CVS & CVSUp setup in terms of network traffic efficiency, support for our "moving tags" and simple usage as a ports backend). Of course, a lot can change in the next few month, but we're at least not planning to switch at the moment.

what kind of solution would you suggest? we are ready to contribute in anyway could be useful. We (the maintainers I've discussed this with so far, not CLC as an entity) would suggest that you maintain PPC specific ports (yaboot etc) and ports from CLC which require changes to work on PPC (mplayer, openoffice-bin etc) in your own repository, so CRUX PPC users can get your tree and the one from CLC and have all ports in a working state;

This doesn't mean that we want to stick with CVS by any means possible, but I'm not aware of a solution which is as good as the CVS/CVSUp based one (Subversion isn't, SVK isn't, monotone isn't, gnuarch isn't). But of course if you find something which would allow this, we would definitely consider making the switch. And obviously we're looking at those revision control systems anyway (some of us at least), so if there's going to be a good alternative to CVS, we might switch just for the additional features. We're not actively looking for a solution to integrate your ports tough, but of course, you're invited to do so. they just have to look in your ports directory first. I personally would probably have a complete tree synced and adapted from the one from CLC, since you have to check every single port anyway to be sure that it works on PPC; you might have a different point of view on this though. Of course, using this solution, your users would get only those ports which are known to work, and you don't have to worry about any change in our tree breaking any of your PPC user's build. The more, they only have to fetch one tree. If there are ports which don't work on PPC because the they are x86 specific without good reasons (like hardcoded CFLAGS and the like), please report this as a bug and we'll try to fix it.

so, about the problem, which are the results? we have to work on the CVS? we have to use mppm? we have to write new code (and make johannes happy)? Basically, you don't have to do anything. It's about what you want to do.

CVS is not suitable for this task, so you don't have to use it. What ever tool you use to maintain, sync and merge your tree (see above) with the tree from CLC is really up to you. mppm can do it [1]; I'm not aware of any other tool that does exactly this, but you might be lucky finding one. To keep your copy up to date, we offer cvsup access and httpup; at least the later should work fine one most platforms, so this shouldn't be a problem. And you won't make me happy by writing code (neither with statements like the one above), but by solving problems. If course, the former can lead to the later... Kind regards, Johannes Notes: 1. mppm will need further work to become faster and more mature; I'm more than happy about feedback, problem reports and suggestions, though -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net