On Monday 01 December 2008 03:27:00 pm Dag Wieers wrote: > On Fri, 21 Nov 2008, Dries Verachtert wrote: > > On Thursday 20 November 2008 12:50:34 pm Fabian Arrotin wrote: > >> On Thu, 20 Nov 2008, Stefan Radman wrote: > >>> Sounds like a sensible proposal with all the information needed > >>> present. It would probably be useful to see who initiated the build > >>> process (for the feedback). > >>> > >>> The publicly accessible buildlogs have always been very useful for me > >>> as rpmforge user to give a focused feedback when a package was'nt > >>> available in the repo the main point being that they were publicly > >>> accessible for analysis. > >>> With the current state (buildlogs not publicly available) I can't be of > >>> any help in getting packages like GraphViz upgraded because I don't see > >>> where the build process fails and blindly bugging the packers every now > >>> and then is no fun. > >>> > >>> My 2 cents. > >>> Stefan > >> > >> Yep, that's a discussion we need to have .. > >> All the PPC package buildlogs are located @ > >> http://rpms.arrfab.net/rpmforge/_buildlogs/ PS : some older ppc logs are > >> still located on the build machine but available on request ;-) > > > > I've put some info about the current build log formats on the wiki: > > https://rpmrepo.org/RPMforge/BuildlogFormat > > Fabian already added some info about his log format. > > > > The current log formats are quite different, so probably it isn't easy to > > switch each buildsystem to 1 fixed common format. Possible solution: > > > > * define a format for sections, for example with the '---' as used in > > Dag's logformat. > > * define a set of required sections, at least: > > o a general header with info about the build > > o the output of rpmbuild > > o the result of the rpmbuild command > > * allow additional sections, just like you can add additional X- > > headers in a mail > > * a standard name for the log file > > > > What do you think? > > Thanks Dries. > > For me the content of the logfile does not (per se) have to be exactly the > same. It would be nice, but I don't see a good validation for spending a > lot of resource on it if at some point we would move to a central > buildsystem anyway. > > What is most important is a naming convention, so that the repository > scripts can handle it and so that the files listed in the same directory > are properly ordered and can be easily identified. > > If we can agree on a filename (and we do some conversions) we'd have the > buildlogs up of all three in a day. > > So here's my proposal: > > name-version-release.arch.extra.log > > where in my case the extra includes 'ok' and 'ko', but for someone else it > could hold the buildid or may even be empty.
That's ok for me. I'm currently using a different convention but i don't see any advantages/disadvantages between them. I'll rename those files. Fabian: looks ok for you too? > - No longer compressed (easier access from the browser) Currently i've got +/- 500 megabytes of log files. Uncompressed this will be probably +/- 5 gigabytes according to some small tests... > - Extension .log so it is obvious what it is (works inside browsers like > .txt) - I think it is important to have the build status (ok/.ko) in the > filename too, simply because that makes if very resource-light to scan or > compare results without the need for accessing the files > > There was a time when .log.gz and .txt.gz were opened directly from the > browser too, but I don't know when that stopped working as I find it very > inconvenient. Having the logfiles compressed however makes a real > difference on disk and for bandwidth, so while I prefer compression I do > accept that making them more accessible (and indexable by Google) are very > valuable to a lot of people. > > Only the build-logs of packages that you are authority of, are being > displayed in the packages-listing (much like how it already is for the > RPMs themselves). Dries _______________________________________________ users mailing list [email protected] http://lists.rpmforge.net/mailman/listinfo/users
