Re: Error when using 'portupgrade -ay' (and several others) [Second attempt]

2009-08-03 Thread David Southwell

 On Sat, Aug 1, 2009 at 5:29 PM, David Southwell da...@vizion2000.netwrote:
   Hi,
  
   I'm getting really weird problems when trying to upgrade my ports. I've
   already discussed this with Dan Naumov on the stable mailing list, and
   he is out of ideas on what I am to do. I've tried to fix the problem
   using many different methods (i.e. csup stable-ports-supfile;
   Portmaster
 
  -a/-af,
 
   portupgrade -ay, nuking the entire ports tree and then doing fetch
   ports; extract, and similar stuff), but everyone seems to get the same
   error,
 
  and
 
   not come any further. The ports my system is trying to update is not in
 
  the
 
   ports tree anymore either, so it is really strange that it is trying to
   update it self.
  
   Here is some outputs I've already posted on the stable mailinglist:
  
   Running 'portupgrade -ay'. Got this output:
  
   ---  Session started at: Fri, 10 Jul 2009 18:58:30 +0200
   ** Port directory not found: x11-drivers/xf86-video-vga
   ** Port marked as IGNORE: x11-drivers/xf86-video-via:
   requires pciVideoPtr typedef
   ** Port directory not found: x11/xorg-protos
   ** Port directory not found: x11/xphelloworld
   ---  Skipping 'x11-drivers/xorg-drivers' (xorg-drivers-7.3_3) because
   a requisite package 'xf86-video-vga-4.1.0_2'
   (x11-drivers/xf86-video-vga) failed (specify -k to force)
   ---  ** Upgrade tasks 3: 0 done, 4 ignored, 1 skipped and 0 failed
   ---  Skipping 'x11/xorg-apps' (xorg-apps-7.3) because a requisite
 
  package
 
   'xphelloworld-1.0.1_1' (x11/xphelloworld) failed (specify -k to force)
   ---  ** Upgrade tasks 3: 0 done, 4 ignored, 2 skipped and 0 failed
   ---  Skipping 'x11/xorg' (xorg-7.3_2) because a requisite package
   'xorg-drivers-7.3_3' (x11-drivers/xorg-drivers) failed (specify -k to
   force) ---  ** Upgrade tasks 3: 0 done, 4 ignored, 3 skipped and 0
 
  failed
 
   ---  Listing the results (+:done / -:ignored / *:skipped / !:failed) -
   x11-drivers/xf86-video-vga (port directory error)
   - x11-drivers/xf86-video-via (marked as IGNORE)
   - x11/xorg-protos (port directory error)
   - x11/xphelloworld (port directory error)
   * x11-drivers/xorg-drivers (xorg-drivers-7.3_3)
   * x11/xorg-apps (xorg-apps-7.3)
   * x11/xorg (xorg-7.3_2)
   ---  Packages processed: 0 done, 4 ignored, 3 skipped and 0 failed
   ---  Session ended at: Fri, 10 Jul 2009 18:58:46 +0200 (consumed
 
  00:00:15)
 
   [r...@machine ~]# portupgrade -ay
   ---  Session started at: Wed, 29 Jul 2009 18:30:36 +0200
  
   ** Port directory not found: x11-drivers/xf86-video-vga
   ** Port marked as IGNORE: x11-drivers/xf86-video-via:
   requires pciVideoPtr typedef
   ** Port directory not found: x11/xorg-protos
   ** Port directory not found: x11/xphelloworld
   [Updating the portsdb format:bdb_btree in /usr/ports ... - 20501 port
   entries found
 
  .1000.2000.3000.4000.5000
 .6
 
  000.7000.8000.9000.1.11000..
  
  
  ...12000.13000.14000.15000.16000
  .170 00.18000.19000.2. . done]
  
   ---  Skipping 'x11-drivers/xorg-drivers' (xorg-drivers-7.3_3) because
   a requisite package 'xf86-video-vga-4.1.0_2'
   (x11-drivers/xf86-video-vga) failed (specify -k to force)
   ---  ** Upgrade tasks 3: 0 done, 4 ignored, 1 skipped and 0 failed
   ---  Skipping 'x11/xorg-apps' (xorg-apps-7.3) because a requisite
 
  package
 
   'xphelloworld-1.0.1_1' (x11/xphelloworld) failed (specify -k to force)
   ---  ** Upgrade tasks 3: 0 done, 4 ignored, 2 skipped and 0 failed
   ---  Skipping 'x11/xorg' (xorg-7.3_2) because a requisite package
   'xorg-drivers-7.3_3' (x11-drivers/xorg-drivers) failed (specify -k to
   force) ---  ** Upgrade tasks 3: 0 done, 4 ignored, 3 skipped and 0
 
  failed
 
   ---  Listing the results (+:done / -:ignored / *:skipped / !:failed) -
   x11-drivers/xf86-video-vga (port directory error)
   - x11-drivers/xf86-video-via (marked as IGNORE)
   - x11/xorg-protos (port directory error)
   - x11/xphelloworld (port directory error)
   * x11-drivers/xorg-drivers (xorg-drivers-7.3_3)
   * x11/xorg-apps (xorg-apps-7.3)
   * x11/xorg (xorg-7.3_2)
   ---  Packages processed: 0 done, 4 ignored, 3 skipped and 0 failed
   ---  Session ended at: Wed, 29 Jul 2009 18:30:59 +0200 (consumed
 
  00:00:22)
 
   [r...@machine ~]#
  
   [r...@machine ~]# portsdb -Uu; portupgrade -ay
   Updating the ports index ... Generating INDEX.tmp - please
   wait..Warning: Duplicate INDEX entry: cvsup-without-gui-16.1h_4
Done.
   done
   [Updating the portsdb format:bdb_btree in /usr/ports ... - 20503 port
   entries found
 
  .1000.2000.3000.4000.5000
 .6
 
  000.7000.8000.9000.1.11000..
  
  
  ...12000.13000.14000.15000

Re: Error when using 'portupgrade -ay' (and several others) [Second attempt]

2009-08-01 Thread David Southwell
 Hi,

 I'm getting really weird problems when trying to upgrade my ports. I've
 already discussed this with Dan Naumov on the stable mailing list, and he
 is out of ideas on what I am to do. I've tried to fix the problem using
 many different methods (i.e. csup stable-ports-supfile; Portmaster -a/-af,
 portupgrade -ay, nuking the entire ports tree and then doing fetch ports;
 extract, and similar stuff), but everyone seems to get the same error, and
 not come any further. The ports my system is trying to update is not in the
 ports tree anymore either, so it is really strange that it is trying to
 update it self.

 Here is some outputs I've already posted on the stable mailinglist:

 Running 'portupgrade -ay'. Got this output:

 ---  Session started at: Fri, 10 Jul 2009 18:58:30 +0200
 ** Port directory not found: x11-drivers/xf86-video-vga
 ** Port marked as IGNORE: x11-drivers/xf86-video-via:
 requires pciVideoPtr typedef
 ** Port directory not found: x11/xorg-protos
 ** Port directory not found: x11/xphelloworld
 ---  Skipping 'x11-drivers/xorg-drivers' (xorg-drivers-7.3_3) because a
 requisite package 'xf86-video-vga-4.1.0_2' (x11-drivers/xf86-video-vga)
 failed (specify -k to force)
 ---  ** Upgrade tasks 3: 0 done, 4 ignored, 1 skipped and 0 failed
 ---  Skipping 'x11/xorg-apps' (xorg-apps-7.3) because a requisite package
 'xphelloworld-1.0.1_1' (x11/xphelloworld) failed (specify -k to force)
 ---  ** Upgrade tasks 3: 0 done, 4 ignored, 2 skipped and 0 failed
 ---  Skipping 'x11/xorg' (xorg-7.3_2) because a requisite package
 'xorg-drivers-7.3_3' (x11-drivers/xorg-drivers) failed (specify -k to
 force) ---  ** Upgrade tasks 3: 0 done, 4 ignored, 3 skipped and 0 failed
 ---  Listing the results (+:done / -:ignored / *:skipped / !:failed) -
 x11-drivers/xf86-video-vga (port directory error)
 - x11-drivers/xf86-video-via (marked as IGNORE)
 - x11/xorg-protos (port directory error)
 - x11/xphelloworld (port directory error)
 * x11-drivers/xorg-drivers (xorg-drivers-7.3_3)
 * x11/xorg-apps (xorg-apps-7.3)
 * x11/xorg (xorg-7.3_2)
 ---  Packages processed: 0 done, 4 ignored, 3 skipped and 0 failed
 ---  Session ended at: Fri, 10 Jul 2009 18:58:46 +0200 (consumed 00:00:15)

 [r...@machine ~]# portupgrade -ay
 ---  Session started at: Wed, 29 Jul 2009 18:30:36 +0200

 ** Port directory not found: x11-drivers/xf86-video-vga
 ** Port marked as IGNORE: x11-drivers/xf86-video-via:
 requires pciVideoPtr typedef
 ** Port directory not found: x11/xorg-protos
 ** Port directory not found: x11/xphelloworld
 [Updating the portsdb format:bdb_btree in /usr/ports ... - 20501 port
 entries found
 .1000.2000.3000.4000.5000.6
000.7000.8000.9000.1.11000..
...12000.13000.14000.15000.16000.170
00.18000.19000.2. . done]

 ---  Skipping 'x11-drivers/xorg-drivers' (xorg-drivers-7.3_3) because a
 requisite package 'xf86-video-vga-4.1.0_2' (x11-drivers/xf86-video-vga)
 failed (specify -k to force)
 ---  ** Upgrade tasks 3: 0 done, 4 ignored, 1 skipped and 0 failed
 ---  Skipping 'x11/xorg-apps' (xorg-apps-7.3) because a requisite package
 'xphelloworld-1.0.1_1' (x11/xphelloworld) failed (specify -k to force)
 ---  ** Upgrade tasks 3: 0 done, 4 ignored, 2 skipped and 0 failed
 ---  Skipping 'x11/xorg' (xorg-7.3_2) because a requisite package
 'xorg-drivers-7.3_3' (x11-drivers/xorg-drivers) failed (specify -k to
 force) ---  ** Upgrade tasks 3: 0 done, 4 ignored, 3 skipped and 0 failed
 ---  Listing the results (+:done / -:ignored / *:skipped / !:failed) -
 x11-drivers/xf86-video-vga (port directory error)
 - x11-drivers/xf86-video-via (marked as IGNORE)
 - x11/xorg-protos (port directory error)
 - x11/xphelloworld (port directory error)
 * x11-drivers/xorg-drivers (xorg-drivers-7.3_3)
 * x11/xorg-apps (xorg-apps-7.3)
 * x11/xorg (xorg-7.3_2)
 ---  Packages processed: 0 done, 4 ignored, 3 skipped and 0 failed
 ---  Session ended at: Wed, 29 Jul 2009 18:30:59 +0200 (consumed 00:00:22)
 [r...@machine ~]#

 [r...@machine ~]# portsdb -Uu; portupgrade -ay
 Updating the ports index ... Generating INDEX.tmp - please wait..Warning:
 Duplicate INDEX entry: cvsup-without-gui-16.1h_4
  Done.
 done
 [Updating the portsdb format:bdb_btree in /usr/ports ... - 20503 port
 entries found
 .1000.2000.3000.4000.5000.6
000.7000.8000.9000.1.11000..
...12000.13000.14000.15000.16000.170
00.18000.19000.2. . done]
 ---  Session started at: Thu, 30 Jul 2009 14:47:18 +0200

 ** Port directory not found: x11-drivers/xf86-video-vga
 ** Port marked as IGNORE: x11-drivers/xf86-video-via:
 requires pciVideoPtr typedef
 ** Port directory not found: x11/xorg-protos
 ** 

Re: Upcoming ABI Breakage in RELENG_7

2008-07-30 Thread David Southwell
On Tuesday 29 July 2008 08:45:45 Ken Smith wrote:
 Normally the FreeBSD Project tries very hard to avoid ABI breakage in
 Stable Branches.  However occasionally the fix for a bug can not be
 implemented without ABI breakage, and it is decided that the fix
 warrants the impact of the ABI breakage.  We have one of those
 situations coming along for RELENG_7 (what will become FreeBSD 7.1).
 The ABI breakage should only impact kernel modules that are not part of
 the baseline system (those will be patched by the MFC) which deal with
 advisory locks.  As such the impact should not cause many people
 problems.

 The work that will be MFCed fixes issues with filesystem advisory locks,
 and moves the advisory locks list from filesystem-private data
 structures into the vnode structure.

 The MFC will be done by Kostantin Belousov some time this coming Friday
 (August 1st, 2008) if you have concerns and want to watch for it.

 Thanks.
Sometimes information gets posted to this list on the assumption that everyone 
understand what the writer means.

This is one of those occasions!!

For those of us who are not as well informed and experienced  as others could 
someone please explain what is meant by an  ABI breakage, its implications 
and how to deal with them.

Thanks

David
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Upcoming ABI Breakage in RELENG_7

2008-07-30 Thread David Southwell
On Wednesday 30 July 2008 03:11:54 Heiko Wundram wrote:
 Am Mittwoch, 30. Juli 2008 11:47:34 schrieb David Southwell:
  For those of us who are not as well informed and experienced  as others
  could someone please explain what is meant by an  ABI breakage, its
  implications and how to deal with them.

 ABI (Application Binary Interface) is a term used to describe the
 characteristics of binary (i.e. object-) code when accessed from other
 binary code. Generally, this entails everything from method signatures over
 structure sizes to global data (exported symbols) sizes.

 One example of ABI-breakage, if you're somewhat proficient in C, could be
 the following:

 -- Old code (library header)

 /* Some structure which contains a long, and so has total size four bytes
 on i386. */
 struct x {
   long y;
 } __attribute__((packed))__;

 /* Get access to two x objects. This function is implemented in a shared
 library. It returns a pointer to eight bytes of memory (2*struct x). */
 extern const struct x* getSomeData();

 -- Old code (user)

 long test() {
   const struct x* ref = getSomeData();
   return ref[0].y + ref[1].y;
 }

 --

 Now, when compiling the user code, it will pick up the specification of the
 structure x through the library supplied header file, seeing that
 ref[...].y is a long value (four bytes on i386), and so that will be
 translated to some machine code which adds four bytes from offset zero
 (ref[0].y) of the pointer that getSomeData() returns to four bytes from
 offset four (ref[1].y), and returns the result as a long value.

 What happens if the following change to the library is made?

 -- New code (library header)

 /* Some structure which now contains a short. This reduces the size of the
 structure to two bytes on i386. */
 struct x {
   short y;
 } __attribute__((packed))__;

 /* Get access to two x objects. This function is implemented in a shared
 library. Due to the change in struct x, this now returns a pointer to
 (only!) four bytes of storage (2*struct x). */
 extern const struct x* getSomeData();

 --

 The size of the structure member y of structure x has now been reduced to
 two bytes (because the type was changed from long to short), but the user
 code doesn't know this, because it was compiled with the old headers. When
 installing the changed shared library, the old user code will load (!) as
 before, because the symbol getSomeData() is still exported from the shared
 library, but will now erraneously load in total eight bytes from a location
 (because that's hardcoded in the machine code produced for the user binary)
 where it should only load four bytes from after the incompatible change to
 the layout of the structure.

 If you were to recompile the user code after installing the updated shared
 library, everything would go back to functioning normally, because now the
 user code picks up the redefined structure x specification which now says
 that it should load only two bytes from offset zero (ref[0].y) and two
 bytes from offset two (ref[1].y) of the returned pointer.

 The API has not changed, because the user code would still compile
 properly, but the ABI has, and as such object code compiled before the
 change in the shared library breaks (most often in very mysterious ways).

 I don't know exactly what will be changed in the kernel to warrant the
 heads up for this specific case, but as was said, the vnode structure is
 changed (because data was added to it), and as such the structure
 specification has changed. If you now have a KLM which expects the old
 structure layout (because it was compiled before the change), you're bound
 for trouble, because it does not yet know that the offsets for members and
 the total size of the vnode structure has changed, and as such all offsets
 it uses in the vnode structure are broken.

 So, if you have a binary only kernel module which requires access/uses the
 vnode structure, you'll have a problem. If not, you don't.

 Does this help?

It sure helps the understanding bit but how about specific instructions about 
who is to what to do in this instance?

i.e. Circumstances and what commands to apply in those circumstances?

The general helps understanding.. the specifics provide solutions for the 
problems!!
Thanks again

David
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Upcoming ABI Breakage in RELENG_7

2008-07-30 Thread David Southwell
On Wednesday 30 July 2008 04:26:33 Heiko Wundram wrote:
 Am Mittwoch, 30. Juli 2008 13:03:34 schrieb Ronald Klop:
  I think in this case (the ABI breakage) it is more nice to say: If you
  don't know what to do, you wil probably not see any problem because of
  this.
  The edge case of what can go wrong is so small, that you must be doing
  quite specialized stuff to see breakage. In that case you would
  understand what is going on. (IMHO)

 Err, no.

 As someone else has already noted, a prominent KLM that's distributed
 separately from the kernel which uses the vnode structure extensively
 (which I didn't think of at all until I read the respective mail) is fuse.
 A pre-upgrade compiled fuse is most certainly going to break because of
 this change. Some people have dual installations of Windows/FreeBSD (at
 least I'd presume that's the case with the fiddlers like me that track
 -STABLE as a hobby, not as a developer, or those developers who program for
 Windows as a day-job, also like me) who use ntfs-3g to mount their
 NTFS-data;
 additionally, I also extensively use ssh-fs, which is also fuse-based, and
 I guess there are also others who use it, and so the reach of this
 ABI-change, at least IMHO, is much larger than the original message makes
 you believe.

 Now, after the update, a lot can go wrong, because the fuse KLM is loaded
 by an init-script, and your system is most probably going to Oops while
 booting if you didn't think of disabling the fuse init-script before you
 update your kernel, and will NOT fail gracefully. If the respective
 person doesn't know how he/she should boot to single-user-mode, update
 rc.conf to disable this, reboot, rebuild the module to get the system back
 up, the only thing I can possibly say is: don't track stable.

 It might've sounded a bit harsh what I wrote, but tracking -STABLE means
 knowing your system enough so that you know how to fix things if they come
 back to bite you (especially after getting a HEADS UP). And that doesn't
 seem to be the case here if the respective person asks for SPECIFIC
 instructions what to do.

 So, again: DON'T track -STABLE if you can't fix the system if it breaks,
 and AFAICT this change is most certainly going to break quite a few
 systems.

Hey

I want to thank those that have taken the trouble to explain stuff BUT

I also feel the need to object to If you cant then don't kind of mentality. 
Everyone has to start somewhere!!!

A contribution that sounds a bit like saying:

Well if you do not have the experience on tracking stable then do not bother 
to start
OR
If you do not understand my jargon why should it be explained

seems to me to invite a  gentle reproof

David
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Dragon_Saver Error 19 Freebsd 7.0 AMD64

2008-07-17 Thread David Southwell
Just upgraded from Freebsd 6.3 to 7.0

uname -a
FreeBSD dns1.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 16 
09:27:38 PDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  
amd64
Have the following entry in

/var/log/essages:

Jul 17 01:28:46 dns1 kernel: dragon_saver: the console does not support 
M_VGA_CG320
Jul 17 01:28:46 dns1 kernel: module_register_init: MOD_LOAD (dragon_saver, 
0xadf7a140, 0) error 19

Can anyone please point me in the right direction

Thanks
David

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Dragon_Saver Error 19 Freebsd 7.0 AMD64

2008-07-17 Thread David Southwell
On Thursday 17 July 2008 02:24:34 Jeremy Chadwick wrote:
 On Thu, Jul 17, 2008 at 02:17:12AM -0700, Jeremy Chadwick wrote:
  On Thu, Jul 17, 2008 at 02:08:58AM -0700, David Southwell wrote:
   Just upgraded from Freebsd 6.3 to 7.0
  
   uname -a
   FreeBSD dns1.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul
   16 09:27:38 PDT 2008
   [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64
   Have the following entry in
  
   /var/log/essages:
  
   Jul 17 01:28:46 dns1 kernel: dragon_saver: the console does not support
   M_VGA_CG320
   Jul 17 01:28:46 dns1 kernel: module_register_init: MOD_LOAD
   (dragon_saver, 0xadf7a140, 0) error 19
 
  That looks to be some kind of screen-saver for VGA consoles, similar to
  daemon_saver or green_saver.  Look at the splash(4) manpage.
 
  There is no 'dragon_saver' that comes with FreeBSD 7.0, however.  And I
  don't remember reading about it on FreeBSD 6.x either.
 
  Usually things like that are loaded via rc.conf or loader.conf.

 I stand corrected -- it appears to come with FreeBSD since the 4.x
 days: http://lists.freebsd.org/pipermail/cvs-all/2003-July/017624.html

 I've still never heard of it though, and it's not mentioned in the
 applicable manpages either.

 But there's an amusing part, too:

 You posted this exact question on freebsd-questions 1.5 years ago,
 where you were running FreeBSD 6.1.  So this problem has little to do
 with your 6.3 -- 7.0 upgrade.

 http://lists.freebsd.org/pipermail/freebsd-questions/2007-January/139096.ht
ml

CHUCKLES RTFM GRINZ
Well I cant remember -- It must have gone away on 6.3 -holding stomach as I 
roar with laughter

Well done...
Ah well as you will see from my next posting I have something alittle bit 
odder to report!!

David

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Portsclean doesnt like my upgrade from 6.3 7.0

2008-07-17 Thread David Southwell
It looks as though I have missed something!!
FreeBSD dns1.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 16 
09:27:38 PDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  
amd64

[EMAIL PROTECTED] ~]# portsclean
FFaattaall  eeoorr  ''Thread is not system scope.
Thread is not system scope.
''  aatt  lliinnee  331199  iinn  
ffiillee  
/usr/src/lib/libpthread/thread/thr_sig.c/usr/src/lib/libpthread/thread/thr_sig.c
  
((eennoo  ==  22))

Segmentation fault: 11 (core dumped)

Ok where do I go from here??

David
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Portsclean doesnt like my upgrade from 6.3 7.0

2008-07-17 Thread David Southwell
On Thursday 17 July 2008 06:39:26 Kris Kennaway wrote:
 David Southwell wrote:
  It looks as though I have missed something!!
  FreeBSD dns1.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 16
  09:27:38 PDT 2008
  [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64
 
  [EMAIL PROTECTED] ~]# portsclean
  FFaattaall  eeoorr  ''Thread is not system scope.
  Thread is not system scope.
  ''  aatt  lliinnee  331199  iinn
  ffiillee 
  /usr/src/lib/libpthread/thread/thr_sig.c/usr/src/lib/libpthread/thread/th
 r_sig.c ((eennoo  ==  22))
 
  Segmentation fault: 11 (core dumped)
 
  Ok where do I go from here??

 Find out which port(s) you didnt recompile as part of the upgrade (e.g.
 check mtime in /usr/local), and do that now.  You may need to also
 recompile the ports that depend on them to undo the damage.

 Kris
 ___
Thanks Kris
I have been unable to find instructions in the manual about  recompiling ports 
as part of a system upgrade process. There seems to be no reference to it. 
The upgrade from 6.1 to 6.3 seemed to work OK once I sorted out a problem 
with perl. However 6.3 to 7.0 seems to produce more difficulties than I 
bargained for!!!

How can I best reconfigure and recompile all th installed ports?

As you can see from below:
[EMAIL PROTECTED] ~]# portupgrade -a
Fatal error 'Thread is not system scope.
' at line 319 in file /usr/src/lib/libpthread/thread/thr_sig.c (errno = 2)
Segmentation fault: 11 (core dumped)

I have definitely omitted a vital step
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Portsclean doesnt like my upgrade from 6.3 7.0

2008-07-17 Thread David Southwell
On Thursday 17 July 2008 07:32:11 Andrew D wrote:
 David Southwell wrote:
  On Thursday 17 July 2008 06:39:26 Kris Kennaway wrote:
  David Southwell wrote:
  It looks as though I have missed something!!
  FreeBSD dns1.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul
  16 09:27:38 PDT 2008
  [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64
 
  [EMAIL PROTECTED] ~]# portsclean
  FFaattaall  eeoorr  ''Thread is not system scope.
  Thread is not system scope.
  ''  aatt  lliinnee  331199  iinn
  ffiillee
  /usr/src/lib/libpthread/thread/thr_sig.c/usr/src/lib/libpthread/thread/
 th r_sig.c ((eennoo  ==  22))
 
  Segmentation fault: 11 (core dumped)
 
  Ok where do I go from here??
 
  Find out which port(s) you didnt recompile as part of the upgrade (e.g.
  check mtime in /usr/local), and do that now.  You may need to also
  recompile the ports that depend on them to undo the damage.
 
  Kris
  ___
 
  Thanks Kris
  I have been unable to find instructions in the manual about  recompiling
  ports as part of a system upgrade process. There seems to be no reference
  to it. The upgrade from 6.1 to 6.3 seemed to work OK once I sorted out a
  problem with perl. However 6.3 to 7.0 seems to produce more difficulties
  than I bargained for!!!
 
  How can I best reconfigure and recompile all th installed ports?
 
  As you can see from below:
  [EMAIL PROTECTED] ~]# portupgrade -a
  Fatal error 'Thread is not system scope.
  ' at line 319 in file /usr/src/lib/libpthread/thread/thr_sig.c (errno =
  2) Segmentation fault: 11 (core dumped)

 I saw this not too long ago, The culprit was ruby.

 Go into each of these ports and
 'make clean  make  make deinstall reinstall' them

 lang/ruby18 (I assume)
 databases/ruby-bdb
 ports-mgmt/portupgrade

 you might have blow away /var/db/pkg/pkgdb.db a couple of times for it
 to work.

 Then portupgrade should work fine :)

Right on the nail
!!

I now have portupgrade -af fulfilling its magic

Thank you and everyone else.

David
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Following upgrade 6.3 7.0 /usr/libexec/save-entropy query

2008-07-17 Thread David Southwell
Receiving Automated message from cron

No such messages under 6.3

Is there anything I need to attend to here?

Subject: Cron ... /usr/libexec/save-entropy
Date: Thursday 17 July 2008
From: Cron Daemon 
To: [EMAIL PROTECTED]

unlink: /var/db/entropy/saved-entropy.8: No such file or directory
mv: /var/db/entropy/saved-entropy.7: No such file or directory
mv: /var/db/entropy/saved-entropy.5: No such file or directory
mv: /var/db/entropy/saved-entropy.1: No such file or directory

David
unlink: /var/db/entropy/saved-entropy.8: No such file or directory
mv: /var/db/entropy/saved-entropy.7: No such file or directory
mv: /var/db/entropy/saved-entropy.5: No such file or directory
mv: /var/db/entropy/saved-entropy.1: No such file or directory

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]