Hi everybody, many of the CLC maintainers already know that at http://www.varlock.com/clcuild there's a summary of the automated build process for clc ports. First of all, congratulations to all maintainers, I got 356 ok / 47 failed, last time (crux 1.3) we had 306 / 240, I think this is a symptom the quality of ports is raising up. Even better, many of the failing ports are not related to the port itself (ie: sourceforge temporarily down, sendmail conflicting with exim, etc.) I tried to categorize the errors here: http://www.varlock.com/files/clcbuild-errors.tar.gz Some general analysis: - As written before, sourceforge hates me so some port simply failed to dowload - We should not worry too much about footprint mismatches (except for my port xpdf where xpdf itself is missing :)). Some adjustement in dep order could solve the issues (ie: kdeaddons) - A bunch of ports (notably apache and friends) failed bcause of hostname -f didn't return a valid full qualified hostname. Most of them are in the 'pre-post' dir since I see certificate generation for apache as an action outside of the package. - Gnome related ports are the great masters of missing deps, and this is obvious since the gnome platform is made up of a gazillion libs :) - Myfault dir contains local errors / stupid things (ie: cvstrac already installed, no linux link in /usr/src, etc). Hope this is useful, looking forward to further improve the script and run it every while (ie 15 days). As said before, the idea is to have a periodic full build, which maintainers can consult every while (without further noise on the mailing list, I promise). Suggestions on how to minimize the errors (ie: ignore / categorize footprint mismatches?) are welcome, the script is here: http://www.varlock.com/files/clcbuild-0.1.1.tar.gz Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
On 05/22/04 14:33 Simone Rota wrote:
Hi everybody,
many of the CLC maintainers already know that at http://www.varlock.com/clcuild there's a summary of the automated build process for clc ports.
Uhm, it's http://www.varlock.com/clcbuild/ -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
Hey Simone, On Sat, May 22, 2004 at 14:33:51 +0200, Simone Rota wrote:
Hi everybody,
many of the CLC maintainers already know that at http://www.varlock.com/clcbuild there's a summary of the automated build process for clc ports. Once more, thanks a lot for this, it's GREAT!
First of all, congratulations to all maintainers, I got 356 ok / 47 failed, last time (crux 1.3) we had 306 / 240, I think this is a symptom the quality of ports is raising up. Not too bad :-=
[...]
Hope this is useful, looking forward to further improve the script and run it every while (ie 15 days). Good idea; could you send an automated report as well?
As said before, the idea is to have a periodic full build, which maintainers can consult every while (without further noise on the mailing list, I promise). mmmh :-) This is not noise on clc-devel! See above.
Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On 05/22/04 16:47 Johannes Winkelmann wrote:
Hey Simone,
Hope this is useful, looking forward to further improve the script and run it every while (ie 15 days).
Good idea; could you send an automated report as well?
Good to hear it's somehow useful, but I really need help with code/ideas to improve the script, just to ensure the it really does what we want, ie: - Detect md5sums mismatches / unreachable urls and re-trying n-times before giving up - if some port fails, avoid to re-compiling it for future deps (ie: re-compiling kdebase for every kde*** port would be a great waste of time). - Auto-classification of errors (footprint/download...) - If 0 errors detected, placing online beer orders shipping to all maintainers' houses. :) I'll concentrate my efforts on the script during the next days, hope to address the presented issues asap. bye, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
On Sat, 22 May 2004, Johannes Winkelmann wrote:
Hey Simone,
On Sat, May 22, 2004 at 14:33:51 +0200, Simone Rota wrote:
Hi everybody,
many of the CLC maintainers already know that at http://www.varlock.com/clcbuild there's a summary of the automated build process for clc ports. Once more, thanks a lot for this, it's GREAT!
Indeed, great work Simone! Btw, the nvidia error is caused by a missing /lib/modules/<ver>/build/ directory. /Per
Simone Rota wrote:
Hi everybody,
many of the CLC maintainers already know that at http://www.varlock.com/clcuild/ there's a summary of the automated build process for clc ports.
First of all, congratulations to all maintainers, I got 356 ok / 47 failed, last time (crux 1.3) we had 306 / 240, I think this is a symptom the quality of ports is raising up.
See, that's cause mine weren't included. I take the curve down! ;) Well, problem is I will not be able to update my server to 2.0 for at least a week or two, since I got live mail, dns, web, etc. etc on it and just don't have downtime for it right now. So if anyone can go out of their way and test the following ports (after doing ports -u): gtk-engines-bluecurve gtk-engines-mist gtk-engines-thinice (Robert, I took over this one to complete the set) gtk-engines-xfce postfix stunnel syslog-ng xautolock icewm spamassassin mawk mrtg xblast xsoldier I still have to fix these two: gtk-engines-cleanice (wants gtk 2.4.x, I got 2.2.4) gtk-engines-smooth (something is wrong) I am thinking in a week or two, to start looking at ports that weren't tagged 2.0, to see if there are any I can adopt (if they matter). Problems: Since 1_3 is a branch, what do we do with gtk2-* ports? I really think the cvs tree is getting a little dirty with old names. Can we make a leap with 2.0 and make it its own branch too and clean out the crud? I am concerned that with every update, we lose ports that people no longer maintain. I really feel we got to create an automated list generation of abandoned ports so people can "adopt" them if they're interested. Here is current way to find untagged ports: #!/bin/bash CVSDIR=/home/$USER/PORTS/clc ### <<< UPDATE THIS LINE find $CVSDIR /usr/ports/{contrib,unmaintained} -type d \ -maxdepth 1 -printf "%f\n"| \ grep -v CVS | sort | uniq -u I think having 2.0 as a separate list can allow us to quickly find abandoned ports and have a clean start for the 2.x series. What do you guys think? Also, and I guess I'll get kicked for this, but I didn't ask before I did, so maybe I did wrong, but when I set up gtk-engines-* ports, I assumed, since 1.3 is a branch, that we didn't need gtk2-engines-* any more, and I removed them. Was that a bad thing? If it was, I guess I can recover them, but... I noticed gtk2 was still there... so... should I return gtk2-engines-* or not care? Victor
Victor <victord@jafa.homeip.net> [2004-05-23 09:39]:
So if anyone can go out of their way and test the following ports (after doing ports -u):
gtk-engines-bluecurve gtk-engines-mist gtk-engines-thinice (Robert, I took over this one to complete the set) gtk-engines-xfce
Slight footprint mismatches here, since you compiled the engines with GTK 2.2.0, but CRUX 2.0 ships with GTK 2.4.0. Replace 2.2.0 by 2.4.0 in the footprints and you should be set. If you want, I can fix that.
postfix
Just set it up last night, works like a charm. I did slightly tweak it to get SASL support compiled in, though.
I still have to fix these two: gtk-engines-cleanice (wants gtk 2.4.x, I got 2.2.4) gtk-engines-smooth (something is wrong)
I'd have a look at the problem, but it seems like you didn't put them in CVS yet :P -- Regards, Tilman
Tilman Sauerbeck wrote:
Victor <victord@jafa.homeip.net> [2004-05-23 09:39]:
So if anyone can go out of their way and test the following ports (after doing ports -u):
gtk-engines-bluecurve gtk-engines-mist gtk-engines-thinice (Robert, I took over this one to complete the set) gtk-engines-xfce
Slight footprint mismatches here, since you compiled the engines with GTK 2.2.0, but CRUX 2.0 ships with GTK 2.4.0. Replace 2.2.0 by 2.4.0 in the footprints and you should be set. If you want, I can fix that.
Oh, yeah 2.4... will alter... As far as the other two, I will fix them then commit them. Didn't want to commit crashy ports. We got standards to maintain here :)
Victor <victord@jafa.homeip.net> [2004-05-23 19:28]:
So if anyone can go out of their way and test the following ports (after doing ports -u):
gtk-engines-bluecurve gtk-engines-mist gtk-engines-thinice (Robert, I took over this one to complete the set) gtk-engines-xfce
Slight footprint mismatches here, since you compiled the engines with GTK 2.2.0, but CRUX 2.0 ships with GTK 2.4.0. Replace 2.2.0 by 2.4.0 in the footprints and you should be set. If you want, I can fix that.
Oh, yeah 2.4... will alter... As far as the other two, I will fix them then commit them. Didn't want to commit crashy ports. We got standards to maintain here :)
Well, you could commit them but not tag them, so they won't be fetched by CVSup :) -- Regards, Tilman
Tilman Sauerbeck wrote:
Victor <victord@jafa.homeip.net> [2004-05-23 19:28]:
So if anyone can go out of their way and test the following ports (after doing ports -u):
gtk-engines-bluecurve gtk-engines-mist gtk-engines-thinice (Robert, I took over this one to complete the set) gtk-engines-xfce
Slight footprint mismatches here, since you compiled the engines with GTK 2.2.0, but CRUX 2.0 ships with GTK 2.4.0. Replace 2.2.0 by 2.4.0 in the footprints and you should be set. If you want, I can fix that.
Oh, yeah 2.4... will alter... As far as the other two, I will fix them then commit them. Didn't want to commit crashy ports. We got standards to maintain here :)
Well, you could commit them but not tag them, so they won't be fetched by CVSup :)
Could have a one week 'testing' period directly after the next crux version is released. So all the ports are automatically tagged with CONTRIB-2_0 whilst the maintainers can test and fix their ports and have public feedback at the same time. Having to manually tag each individual port is a major pain in the arse for those with many ports (does not include me). Even just updating individual ports is a fair task with all the cvs commands, which although arn't hard, it can become time consuming. I think there needs to be an improved method of updating ports.
On Mon, May 24, 2004 at 06:02:42PM +1000, Daniel W. wrote: Hi Daniel, [...]
Could have a one week 'testing' period directly after the next crux version is released. So all the ports are automatically tagged with CONTRIB-2_0 whilst the maintainers can test and fix their ports and have public feedback at the same time.
The goal of CLC is to provide good and tested software. For this reason only tested ports should be labelled with the CONTRIB tag.
Having to manually tag each individual port is a major pain in the arse for those with many ports (does not include me).
The few required cvs tasks, are nothing compared to the time you must spend to test the port. With test I mean not only compiling the port, but, more important, to ensure that it is functional working. regards Jürgen -- juergen.daubert@t-online.de
participants (7)
-
Daniel W. -
Johannes Winkelmann -
Juergen.Daubert＠t-online.de -
Per Liden -
Simone Rota -
Tilman Sauerbeck -
Victor