December 2006 - crux-devel

Re: [crux-devel] Proposal: Guidelines for CVS/SVN/etc Pkgfile's
by Brett Goulder 03 Dec '06

03 Dec '06

On Sat, 2 Dec 2006 17:27:44 +0100 simone@ wrote: > On Sat, Dec 02, 2006 at 08:21:10PM +0300, Anton Vorontsov wrote: > > > > fetching from repository by revision or tag should produce > > predictable results, just the same as tarballs (as opposite to > > fetching from trunk or branches). > > True, but some extra work for the packager (as in publishing > a snapshot) will discourage too much frequent updates ;-) > > Packages in core/opt could be bumped every X amount of time, like say bump once every week. Contrib ones should be whenever the maintainer pleases, say a new feature is added one day and the next another, he should be able to bump and test as he wishes in contrib. In my opinion, snapshots of cvs/svn are just a bad idea, some of the time snapshots might not even work (I've used upstream snapshots that have been busted before). -- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc

1 0

Re: [crux-devel] Proposal: Guidelines for CVS/SVN/etc Pkgfile's
by Anton Vorontsov 02 Dec '06

02 Dec '06

On Sat, Dec 02, 2006 at 05:08:06PM +0100, simone@ wrote: > On Fri, Dec 01, 2006 at 09:08:16PM -0500, Brett Goulder wrote: > > I'm just going to paste my proposal below, please comment on it. > > > > 1. What is this proposal about? > > It's about laying down basic guidelines for writing Pkgfile's which > > deal with CVS/SVN checkouts, in order to standardise this. The reason I > > want to standardise this is because Pkgfile's that handle > > CVS/SVN/whatever tend to use their own way of doing things, for example > > Han's Pkgfile's checkout stuff live and others use snapshots. > > I think live checkouts should be generally avoided. Better providing > a snapshot (when not available upstream) and update it from time > to time. > This would make the ports more 'predictable', and this is especially > needed since we're already using a bleeding edge package :-) fetching from repository by revision or tag should produce predictable results, just the same as tarballs (as opposite to fetching from trunk or branches). > Regards, > Simone -- Anton (irc: bd2)

1 0

prtverify daily results
by crux＠crux.nu 02 Dec '06

02 Dec '06

Differences since last check: (no differences) Full report: http://crux.nu/files/prtverify.log

1 0

Potentially broken source downloads
by crux＠crux.nu 02 Dec '06

02 Dec '06

Port: /home/crux/git-to-rsync-working-copy/crux-2.2/core/dhcpcd Url: ftp://ftp.phystech.com/pub/dhcpcd-1.3.22-pl4.tar.gz Reason: curl: (6) Couldn't resolve host 'ftp.phystech.com' State: New Port: /home/crux/git-to-rsync-working-copy/crux-2.2/core/ppp Url: ftp://ftp.samba.org/pub/ppp/ppp-2.4.4.tar.gz Reason: curl: (7) couldn't connect to host State: Changed reason Full report: http://crux.nu/files/check_urls.html

1 0

Proposal: Guidelines for CVS/SVN/etc Pkgfile's
by Brett Goulder 02 Dec '06

02 Dec '06

I'm just going to paste my proposal below, please comment on it. Proposal: Handling CVS/SVN Pkgfile's in a standardised manner. Written by: Brett 'predatorfreak' Goulder 1. What is this proposal about? It's about laying down basic guidelines for writing Pkgfile's which deal with CVS/SVN checkouts, in order to standardise this. The reason I want to standardise this is because Pkgfile's that handle CVS/SVN/whatever tend to use their own way of doing things, for example Han's Pkgfile's checkout stuff live and others use snapshots. 2. Well, what should we change? I think we should change the Pkgfile's so we checkout revisions and change the version variable to the revision or date to checkout, as this allows us to stop rolling a snapshot or using someone elses and doesn't force us to use a live checkout, which presents a problem for people to help with problems during the build or operation of the package. We should also add a variable, svntrunk/cvsroot/etc that would allow a script to grab the latest revision to aid in bumping. Here's an example of how a CVS/SVN/etc Pkgfile would look: # Description: Foobar # URL: Foobar # Maintainer: XYZ <XYZ(a)XYZ.XYS> # Packager: XYZ <XYZ(a)XYZ.XYS> # Depends on: foo name=bar version=4543 release=1 source=() svntrunk="svn://svn.foobar.com/$name/trunk" build() { cd $PKGMK_SOURCE_DIR svn co $svntrunk $name-svn --config-dir ./ -r $version cp -r $name-svn $SRC/$name-build cd $SRC/$name-build ./autogen.sh ./configure --prefix=/usr make make DESTDIR=$PKG install } We also checkout the source into the $PKGMK_SOURCE_DIR in order to allow us to use it as a later point, that way the source can be used between builds without downloading it again. -- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc

3 3

Potentially broken source downloads
by crux＠crux.nu 01 Dec '06

01 Dec '06

Port: /home/crux/git-to-rsync-working-copy/crux-2.2/core/ppp Url: ftp://ftp.samba.org/pub/ppp/ppp-2.4.4.tar.gz Reason: curl: (67) Access denied: 421 State: New Port: /home/crux/git-to-rsync-working-copy/crux-2.2/opt/samba Url: http://us1.samba.org/samba/ftp/stable/samba-3.0.23d.tar.gz Reason: curl: (52) Empty reply from server State: New Full report: http://crux.nu/files/check_urls.html

1 0

prtverify daily results
by crux＠crux.nu 01 Dec '06

01 Dec '06

Differences since last check: (no differences) Full report: http://crux.nu/files/prtverify.log

1 0