Hi there,
As recently pointed out by Fredrik [1] the demand for 64-bit OSes is
only getting bigger, and as more and more of us have access to 64-bit
hardware it would be nice to work towards an official crux 64-bit port.
To prepare for this, we've discussed about the possible ways to manage
ports, and came up with the following suggestion:
- we'll keep separate core-x86_64.git and opt-x86_64.git
- we'll add post commit hooks to all repositories, allowing to track
changes to a port easily
- ports will appear in opt-x86_64.git because they have a maintainer on
this platform, not because they're in opt.git
In other words, there won't be an automatic way to merge changes,
however in most situations updates should be straight forward anyway,
and for the rest I'd suggest to write a script which fetches the primary
port, and runs some merge tool.
I also suggest that we use the term "primary maintainer" (tracks
upstream & makes the call whether a release should be used in CRUX,
equivalent to the current maintainer) and "arch maintainer" (tracks the
primary port). Being an arch maintainer should be a lot less work, and
might in the future also be a good way to get into CRUX.
In order to get things going, it would be nice to hear how many of you
would be willing to help on this project.
We can probably start with one of the existing 64-bit versions, so the
initial release should be ready fairly quickly. More interesting would
be to get a feeling what the costs of maintaining ports on two platforms
are.
Looking forward to hearing from you.
Thanks, Johannes
[1] http://crux.nu/bugs/index.php?do=details&task_id=280
--
Johannes Winkelmann mailto:jw@smts.ch
Zurich, Switzerland http://jw.smts.ch
Hi there,
I'd like to suggest casual IRC meeting of us developers, with no fixed
agenda and no need to give notice whether you can attend or not.
The main goal would be to get things done quickly which would normally
take a lot of time to coordinate in mail, for example the
"Public Wiki" -> "Wiki" transformation, or discussion on bug reports and
taking necessary actions.
It's by no means a replacement for the existing meetings, but could help
to make us more efficient at getting things done, and could hopefully
allow those that aren't frequently on IRC join for the important bits.
We'd probably hold it at 20:00 CEST as the regular meetings.
I've created a poll where you can write down days that you generally
could participate on, plus a "Bad idea" option if you dislike it. Please
only vote if you're a dev, those will get remove anyway. If you want to
comment (no matter whether you're a dev or not :-)) please feel free to
follow up to the mail.
Poll here:
http://doodle.ch/participation.html?pollId=rturdcmvq86s5s6w
Thanks for reading.
Johannes
--
Johannes Winkelmann mailto:jw@smts.ch
Zurich, Switzerland http://jw.smts.ch
Hi there,
My qt4 port triggered an error [1] when using distcc to build it. After
some investigation, I realized that Qt4 by default uses precompiled
headers [2], which break when the compilation is done on a different
machine since the precompiled headers are not transfered automatically.
Currently, this means that any package using PCH will break when
trying to compile it with distcc.
There are a couple of ways to address that:
1. let it break on distcc machines, since we expect users of distcc to
understand the problem
2. force the packages to not use PCH at all (= longer compile times for
non distributed builds)
3. make the Pkgfiles aware that they're build with distcc, so they can
react (might need a more generic solution than just distcc, since other
tools doing the same would suffer from the same problem)
4. make the port aware (i.e. using a ".pch" file) that it will break,
and make the distcc code in pkgmk.conf smart enough to not select distcc
if it's there
I think #4 would be the cleanest solution, however #3 would be faster if
a user has a compile farm, at the cost of some detection code build()
function
At this point in time, distcc is not maintained in core/opt, so I'm not
sure if there's a general interest to fix that problem; I used to
maintain distcc before my "sabbatical leave" so I have a personal
interest in it and believe that distcc is quite interesting for a source
based distribution, YMMV though :-).
If you have other ideas or any preferences, please tell the world :-).
Best wishes, Johannes
References:
1. http://crux.nu/bugs/index.php?do=details&task_id=275
2. http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
--
Johannes Winkelmann mailto:jw@smts.ch
Zurich, Switzerland http://jw.smts.ch
