Re: Problems using portupgrade to recompile all ports
On Thu, 15 Jan 2004 17:38:41 +, Matthew Seaman wrote: > portupgrade -rfx '>=2004-01-15' foo > > will force re-install 'foo' and everything that depends on package > 'foo', except those packages installed on or after the given date. Well, actually I want -R and not -r, but anyways.. almost, but not quite: su-2.05b# portupgrade -Rfx '>=2004-01-14' docbook-xsl ** All the packages matching 'docbook-xsl' were excluded. ** No such package 'docbook-xsl' is installed. So -x is picking up the package name too. Don't want that. So I try: portupgrade -Rf docbook-xsl -x '>=2004-01-14' And that seems to work. I've used it with a bunch of my originally-failed ports and making progress. A lot of them are failing with "local modification time does not match remote" but I delete the file from /usr/ports/distfiles and all is well. Thanks! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems using portupgrade to recompile all ports
On Thu, Jan 15, 2004 at 12:25:17PM -0500, Scott I. Remick wrote: > One question: it's not clear from man pkg_glob whether I can combine the > date format '<2004-01-15' with a package name, so that I only update the > dependencies of a SPECIFIC package that are older than that date (using -f > instead of -af of course). Is there a syntax to do that? portupgrade -rfx '>=2004-01-15' foo will force re-install 'foo' and everything that depends on package 'foo', except those packages installed on or after the given date. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
Re: Problems using portupgrade to recompile all ports
On Thu, 15 Jan 2004 17:12:27 +, Matthew Seaman wrote: > Work out what went wrong, fix it and then just run: > > # portupgrade -af '<2004-01-15' > > which does a forced update of all packages installed before the given > date. (Note: -R and -r are unnecessary with -a). Rinse, > repeat. Until all your ports are up to date. Excellent! That should do EXACTLY what I needed. Thank you so much. > Usually ports problems are either inability to download the required > distfiles or a temporary SNAFU by the port maintainer/committer. In > most cases it suffices to wait a few hours or days, re-cvsup the ports > tree and start the portupgrade job again. Yeah that was my plan... I'm well-familiar with ports-tree hiccups. I have plenty of other things to do to pass the time while I sort this out (like install 4.9 on a separate drive to try and fix a UFS1 volume I cannot access due to a bad superblock. Or play with my new Palm Tungsten T3 once it arrives) One question: it's not clear from man pkg_glob whether I can combine the date format '<2004-01-15' with a package name, so that I only update the dependencies of a SPECIFIC package that are older than that date (using -f instead of -af of course). Is there a syntax to do that? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems using portupgrade to recompile all ports
On Thu, Jan 15, 2004 at 10:03:31AM -0500, Scott I. Remick wrote: > So... my ultimate question is: how do you pros handle situations like this? > Is there a trick I'm missing? Work out what went wrong, fix it and then just run: # portupgrade -af '<2004-01-15' which does a forced update of all packages installed before the given date. (Note: -R and -r are unnecessary with -a). Rinse, repeat. Until all your ports are up to date. Usually ports problems are either inability to download the required distfiles or a temporary SNAFU by the port maintainer/committer. In most cases it suffices to wait a few hours or days, re-cvsup the ports tree and start the portupgrade job again. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
Re: Problems using portupgrade to recompile all ports
On Thu, 15 Jan 2004 16:02:44 + (GMT), Jan Grant wrote: > On Thu, 15 Jan 2004, Scott I. Remick wrote: > >> So I'm upgrading my 5.1R desktop to 5.2R. Used cvsup, followed the >> instructions in UPGRADING, did a custom kernel, etc etc. That part went >> fine, no probs. >> >> I noticed some of my daemons (from ports) seemed a bit annoyed though upon >> booting up 5.2. I tried using portupgrade -Rf on them individually, and >> then all was well. I decided then that it'd be best to do everything (-Raf) >> to play it safe. I've done this before. >> >> So it finally finished last night, but not really... about 132 ports were >> failed/skipped. My problem is figuring out the most efficient way to deal >> with it from here. LAST time I did a portupgrade -Raf I had a much smaller >> number failed/skipped, and what I did was work out the dependency tree for >> the remaining ones by hand using pkg_info -R and -r, figure out the order, >> and do a portupgrade -f on each in the proper order. This was to avoid >> rebuilding stuff already built on the first -Raf pass, and multiple times >> over (since I was taking care of each remaining one individually). Seems to >> me that if 50 of those 132 are X apps and I do a portupgrade -Rf on each, >> I'll be rebuilding XFree86 50 times. Hence the need to work out the install >> order by-hand based upon dependencies and only use -f. But I don't see that >> as practical this time around with so many left to do. >> >> So... my ultimate question is: how do you pros handle situations like this? >> Is there a trick I'm missing? > > Do you know why the failure happened? The most frequent cause of this > when I've encountered the problem is that a distfile could not be > fetched. I tend to try to avoid that these days by prefetching the > distfiles prior to a build (ie, while I'm around to sort out problems > manually rather than overnight). Various reasons. I could post the full list at the end if you'd like (I saved it). Most are skipped (*) due to dependencies on the ones that failed (!). For the failed ones, I got assorted errors: "unknown build error", "install error", "checksum mismatch", "linker error", "new compiler error", "missing header". The ones marked ! failed isn't so large I couldn't investigate/fix each individually, but I'm trying to figure out the best way to deal with the full list of failed/skipped so that once I fix the reason for the failures, I can JUST rebuild those in the failed/skipped list and in the proper order, instead of having to rebuild my entire (400+) ports list again w/ -Raf, most of which compiled fine under 5.2. Hopefully I'm making sense... :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems using portupgrade to recompile all ports
On Thu, 15 Jan 2004, Scott I. Remick wrote: > So I'm upgrading my 5.1R desktop to 5.2R. Used cvsup, followed the > instructions in UPGRADING, did a custom kernel, etc etc. That part went > fine, no probs. > > I noticed some of my daemons (from ports) seemed a bit annoyed though upon > booting up 5.2. I tried using portupgrade -Rf on them individually, and > then all was well. I decided then that it'd be best to do everything (-Raf) > to play it safe. I've done this before. > > So it finally finished last night, but not really... about 132 ports were > failed/skipped. My problem is figuring out the most efficient way to deal > with it from here. LAST time I did a portupgrade -Raf I had a much smaller > number failed/skipped, and what I did was work out the dependency tree for > the remaining ones by hand using pkg_info -R and -r, figure out the order, > and do a portupgrade -f on each in the proper order. This was to avoid > rebuilding stuff already built on the first -Raf pass, and multiple times > over (since I was taking care of each remaining one individually). Seems to > me that if 50 of those 132 are X apps and I do a portupgrade -Rf on each, > I'll be rebuilding XFree86 50 times. Hence the need to work out the install > order by-hand based upon dependencies and only use -f. But I don't see that > as practical this time around with so many left to do. > > So... my ultimate question is: how do you pros handle situations like this? > Is there a trick I'm missing? Do you know why the failure happened? The most frequent cause of this when I've encountered the problem is that a distfile could not be fetched. I tend to try to avoid that these days by prefetching the distfiles prior to a build (ie, while I'm around to sort out problems manually rather than overnight). -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/ If it's broken really badly - don't fix it either. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Problems using portupgrade to recompile all ports
So I'm upgrading my 5.1R desktop to 5.2R. Used cvsup, followed the instructions in UPGRADING, did a custom kernel, etc etc. That part went fine, no probs. I noticed some of my daemons (from ports) seemed a bit annoyed though upon booting up 5.2. I tried using portupgrade -Rf on them individually, and then all was well. I decided then that it'd be best to do everything (-Raf) to play it safe. I've done this before. So it finally finished last night, but not really... about 132 ports were failed/skipped. My problem is figuring out the most efficient way to deal with it from here. LAST time I did a portupgrade -Raf I had a much smaller number failed/skipped, and what I did was work out the dependency tree for the remaining ones by hand using pkg_info -R and -r, figure out the order, and do a portupgrade -f on each in the proper order. This was to avoid rebuilding stuff already built on the first -Raf pass, and multiple times over (since I was taking care of each remaining one individually). Seems to me that if 50 of those 132 are X apps and I do a portupgrade -Rf on each, I'll be rebuilding XFree86 50 times. Hence the need to work out the install order by-hand based upon dependencies and only use -f. But I don't see that as practical this time around with so many left to do. So... my ultimate question is: how do you pros handle situations like this? Is there a trick I'm missing? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
