Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On Fri, Nov 17, 2023 at 11:00:07AM +0100, Olivier Certner wrote: > Hi Glen, > > > I also agree we cannot prevent people from downloading the images, > > installers, whatever before the announcement. That is the lovely race > > condition with which we have to live at the moment. > > Yes, and given that, I don't think you did anything wrong. > > It seems that the race is the same for freebsd-update(8), according to "The > Doctor". But maybe in this case it is easier to fix, perhaps if installing > the metadata signaling the new release to it can be delayed, by contrast with > big files containing the actual data (I don't know how freebsd-update(8) > works, so this is just a guess). > > > The alternative would be to say nothing at all. > > I really hope you and re@ will never choose this way. > > > Either way, it is a productivity, communication drain. It is > > a lose-lose situation no matter how one looks at it given the above > > context. We either get chastised for being "too open" into insights > > delaying an official announcement, or for being "not open enough" when > > there is silence from RE when a release does not meet its scheduled > > announcement date. > > IMHO, a delay should always be announced (perhaps unless it's only a few > days). If it is too hard to decide on the right level of details, then only > mention that some (potential or verified) problem is being looked upon, but > don't let that prevent you from communicating. > > As for people saying that they have already installed the "release", I'd > suggest to have some text on the website (https://www.freebsd.org/releng/ > perhaps) explaining that images on mirrors can appear in advance of release > announcements and that they should not be considered as official until the > official mail is sent, and just kindly point them to it. I hope this can > contribute to at least attenuating the drain you're experiencing. > > Regards. > > -- > Olivier Certner > > just a suggestion for the future is that to have some sort of gpg/gpg check in freebsd-update . -- Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism ; unsubscribe from Google Groups to be seen Lest we forget 11 Nov 2023 Beware https://mindspring.com
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On Thu, Nov 16, 2023 at 12:07:36AM -0500, Glen Barber wrote: > And if there is a reason to reissue a release, the update will reflect such. > > So to answer your latter question, yes. Unless it needs to be replaced. > > Glen > Sent from my phone. > Please excuse my brevity and/or typos. > > > On Nov 15, 2023, at 11:38 PM, The Doctor wrote: > > > > ???On Thu, Nov 16, 2023 at 12:30:30AM +, Glen Barber wrote: > >>> On Wed, Nov 15, 2023 at 08:39:39AM -0800, John Baldwin wrote: > >>> On 11/14/23 8:52 PM, Glen Barber wrote: > >>>> On Tue, Nov 14, 2023 at 08:10:23PM -0700, The Doctor wrote: > >>>>> On Wed, Nov 15, 2023 at 02:27:01AM +, Glen Barber wrote: > >>>>>> On Tue, Nov 14, 2023 at 05:15:48PM -0700, The Doctor wrote: > >>>>>>> On Tue, Nov 14, 2023 at 08:36:54PM +, Glen Barber wrote: > >>>>>>>> We are still waiting for a few (non-critical) things to complete > >>>>>>>> before > >>>>>>>> the announcement of 14.0-RELEASE will be ready. > >>>>>>>> > >>>>>>>> It should only be another day or so before these things complete. > >>>>>>>> > >>>>>>>> Thank you for your understanding. > >>>>>>>> > >>>>>>> > >>>>>>> I always just installed my copy. > >>>>>>> > >>>>>> > >>>>>> Ok. I do not know what exactly is your point, but releases are never > >>>>>> official until there is a PGP-signed email sent. The email is intended > >>>>>> for the general public of consumers of official releases, not "yeah, > >>>>>> but"s. > >>>>>> > >>>>> > >>>>> Howver if you do a freebsd-update upgrade, you can upgrade. > >>>>> > >>>>> Is that suppose to happen? > >>>>> > >>>> > >>>> That does not say that the freebsd-update bits will not change *until* > >>>> the official release announcement has been sent. > >>>> > >>>> In my past 15 years involved in the Project, I think we have been very > >>>> clear on that. > >>>> > >>>> A RELEASE IS NOT FINAL UNTIL THE PGP-SIGNED ANNOUNCEMENT IS SENT. > >>>> > >>>> I mean, c'mon, dude. > >>>> > >>>> We really, seriously, for all intents and purposes, cannot be any more > >>>> clear than that. > >>>> > >>>> So, yes, *IF* an update necessitates a new freebsd-update build, what > >>>> you are running is *NOT* official. > >>>> > >>>> For at least 15 years, we have all said the same entire thing. > >>> > >>> Yes, but, if at this point we had to rebuild, it would have to be 14.0.1 > >>> or something (which we have done a few times in the past). It would be > >>> too confusing otherwise once the bits are built and published (where > >>> published means "uploaded to our CDN"). It is the 14.0 release bits, > >>> the only question is if for some reason we had a dire emergency that > >>> meant we had to pull it at the last minute and publish different bits > >>> (under a different release name). > >>> > >>> Realistically, once the bits are available, we can't prevent people from > >>> using them, it's just at their own risk to do so until the project says > >>> "yes, we believe these are good". Granted, they are under the same risk > >>> if they are still running the last RC. The best way to minimize that > >>> risk going forward is to add more automation of testing/CI to go along > >>> with the process of building release bits so that the build artifacts > >>> from the release build run through CI and are only published if the CI > >>> is green as that would give us greater confidence of "we believe these > >>> are good" before they are uploaded for publishing. > >>> > >> > >> You are correct on all points. If there were a need to re-roll 14.0, it > >> would indeed necessitate a release/14.0.1 tag. Note, release/14.0.0 has > >> not yet been tagged, and I find it extremely unlikely that it will be > >> necessary to rebuild from a release/14.0.1 tag.
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On Thu, Nov 16, 2023 at 12:30:30AM +, Glen Barber wrote: > On Wed, Nov 15, 2023 at 08:39:39AM -0800, John Baldwin wrote: > > On 11/14/23 8:52 PM, Glen Barber wrote: > > > On Tue, Nov 14, 2023 at 08:10:23PM -0700, The Doctor wrote: > > > > On Wed, Nov 15, 2023 at 02:27:01AM +, Glen Barber wrote: > > > > > On Tue, Nov 14, 2023 at 05:15:48PM -0700, The Doctor wrote: > > > > > > On Tue, Nov 14, 2023 at 08:36:54PM +, Glen Barber wrote: > > > > > > > We are still waiting for a few (non-critical) things to complete > > > > > > > before > > > > > > > the announcement of 14.0-RELEASE will be ready. > > > > > > > > > > > > > > It should only be another day or so before these things complete. > > > > > > > > > > > > > > Thank you for your understanding. > > > > > > > > > > > > > > > > > > > I always just installed my copy. > > > > > > > > > > > > > > > > Ok. I do not know what exactly is your point, but releases are never > > > > > official until there is a PGP-signed email sent. The email is > > > > > intended > > > > > for the general public of consumers of official releases, not "yeah, > > > > > but"s. > > > > > > > > > > > > > Howver if you do a freebsd-update upgrade, you can upgrade. > > > > > > > > Is that suppose to happen? > > > > > > > > > > That does not say that the freebsd-update bits will not change *until* > > > the official release announcement has been sent. > > > > > > In my past 15 years involved in the Project, I think we have been very > > > clear on that. > > > > > > A RELEASE IS NOT FINAL UNTIL THE PGP-SIGNED ANNOUNCEMENT IS SENT. > > > > > > I mean, c'mon, dude. > > > > > > We really, seriously, for all intents and purposes, cannot be any more > > > clear than that. > > > > > > So, yes, *IF* an update necessitates a new freebsd-update build, what > > > you are running is *NOT* official. > > > > > > For at least 15 years, we have all said the same entire thing. > > > > Yes, but, if at this point we had to rebuild, it would have to be 14.0.1 > > or something (which we have done a few times in the past). It would be > > too confusing otherwise once the bits are built and published (where > > published means "uploaded to our CDN"). It is the 14.0 release bits, > > the only question is if for some reason we had a dire emergency that > > meant we had to pull it at the last minute and publish different bits > > (under a different release name). > > > > Realistically, once the bits are available, we can't prevent people from > > using them, it's just at their own risk to do so until the project says > > "yes, we believe these are good". Granted, they are under the same risk > > if they are still running the last RC. The best way to minimize that > > risk going forward is to add more automation of testing/CI to go along > > with the process of building release bits so that the build artifacts > > from the release build run through CI and are only published if the CI > > is green as that would give us greater confidence of "we believe these > > are good" before they are uploaded for publishing. > > > > You are correct on all points. If there were a need to re-roll 14.0, it > would indeed necessitate a release/14.0.1 tag. Note, release/14.0.0 has > not yet been tagged, and I find it extremely unlikely that it will be > necessary to rebuild from a release/14.0.1 tag. > > I also agree we cannot prevent people from downloading the images, > installers, whatever before the announcement. That is the lovely race > condition with which we have to live at the moment. > > My email was intended to be informative. Period. > > There were no suggestions that 14.0-RELEASE was not yet final. And to > be fair, I had to personally deal with the fallout of a release "too > soon", notably 11.0-RELEASE, where I thought a critical issue had been > addressed, but I was wrong. > > My only point, in being overly open to the public on the delay, is that > we (the Release Engineering Team) are not yet ready to rubber-stamp this > as complete, as there are some outstanding items that are pending that > have not yet completed. > > The alternative would be to say nothing at all. > > Either way, it is a productivity, communication drain. It is > a lose-lose situation no matter how one looks at it given the above > context. We either get chastised for being "too open" into insights > delaying an official announcement, or for being "not open enough" when > there is silence from RE when a release does not meet its scheduled > announcement date. > > Glen > > What ahappened was that I inititated the freebsd-upgrade RELEASE upgrade command. question should that RELEASe been released? -- Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism ; unsubscribe from Google Groups to be seen Lest we forget 11 Nov 2023 Beware https://mindspring.com
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On Wed, Nov 15, 2023 at 02:27:01AM +, Glen Barber wrote: > On Tue, Nov 14, 2023 at 05:15:48PM -0700, The Doctor wrote: > > On Tue, Nov 14, 2023 at 08:36:54PM +, Glen Barber wrote: > > > We are still waiting for a few (non-critical) things to complete before > > > the announcement of 14.0-RELEASE will be ready. > > > > > > It should only be another day or so before these things complete. > > > > > > Thank you for your understanding. > > > > > > > I always just installed my copy. > > > > Ok. I do not know what exactly is your point, but releases are never > official until there is a PGP-signed email sent. The email is intended > for the general public of consumers of official releases, not "yeah, > but"s. > Howver if you do a freebsd-update upgrade, you can upgrade. Is that suppose to happen? > Glen > -- Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism ; unsubscribe from Google Groups to be seen Lest we forget 11 Nov 2023 Beware https://mindspring.com
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On Tue, Nov 14, 2023 at 08:36:54PM +, Glen Barber wrote: > We are still waiting for a few (non-critical) things to complete before > the announcement of 14.0-RELEASE will be ready. > > It should only be another day or so before these things complete. > > Thank you for your understanding. > I always just installed my copy. > Glen > On behalf of: re@ > -- Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism ; unsubscribe from Google Groups to be seen Lest we forget 11 Nov 2023 Beware https://mindspring.com
Re: Radius challenges in FreeBSD 14.0 Re: FreeBSD 14.0-RC4 Now Available
On Mon, Nov 06, 2023 at 04:31:04PM +0100, Baptiste Daroussin wrote: > On Mon, Nov 06, 2023 at 08:27:34AM -0700, The Doctor wrote: > > On Mon, Nov 06, 2023 at 09:50:18AM +0100, Baptiste Daroussin wrote: > > > On Mon, Nov 06, 2023 at 09:04:15AM +0100, Baptiste Daroussin wrote: > > > > On Mon, Nov 06, 2023 at 12:50:43AM -0700, The Doctor wrote: > > > > > On Mon, Nov 06, 2023 at 08:43:05AM +0100, Baptiste Daroussin wrote: > > > > > > On Sun, Nov 05, 2023 at 12:11:06PM -0700, The Doctor wrote: > > > > > > > On Sun, Nov 05, 2023 at 10:32:44AM -0700, The Doctor wrote: > > > > > > > > On Fri, Nov 03, 2023 at 11:42:32PM +, Glen Barber wrote: > > > > > > > > > The fourth RC build of the 14.0-RELEASE release cycle is now > > > > > > > > > available. > > > > > > > > > > > > > > > > > > Installation images are available for: > > > > > > > > > > > > > > > > > > o 14.0-RC4 amd64 GENERIC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am having a problem witb Freeradius and GNU radius. > > > > > > > > > > > > > > > > Anyone else? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I found the problem. Replace /usr/lib/libncursesw.so as a > > > > > > > symbolic > > > > > > > link to /lib/libncursesw.so.9 > > > > > > > > > > > > can you provide more inputs here, please where do you get your > > > > > > freeradious or > > > > > > gnu radius implementation from, what is failing an so on? > > > > > > > > > > > > Best regards, > > > > > > Bapt > > > > > > > > > > freeradius looks like a TLS issue with openssl 3 > > > > > > > > > > . > > > > > > > > > > gnu Radius was biuld by me and not a port. > > > > > > > > > > Trying to recode is a challenge. > > > > > > > > > > What is happening is that > > > > > > > > > > the so file is not being recognised so > > > > > I have to symlink in order to get GNU radius 1.6.X to work . > > > > > > > > > > It will work with /lib/libncursesw.so.9 if the so file is found in > > > > > /usr/lib . > > > > > > > > OK I will dig into gnu-radius, and fix the port if needed! thank you > > > > > > > > Best regards, > > > > Bapt > > > > > > I just checked here, and I built gnu-radius on a vanilla freebsd 14.0 rc4 > > > and a > > > vanilla 15 current, and in both case it perfectly links to > > > libncursesw.so.9 and > > > does not require any change of the .so, at least from all the binary > > > analysis > > > that I have done, do you have a specific command that will expose the > > > issue? > > > > > > Can you provide me you gnu-radius package as created by pkg create > > > gnu-radius ? > > > > > > Best regards, > > > Bapt > > > > Try to build from ports, here is what I get > > > > cc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../include > > -I../include/radius -I../include/radius -I../lib -I../gnu -I../gnu > > -I/usr/local/include/guile/1.8 -I/usr/local/include -isystem > > /usr/local/include -D_THREAD_SAFE -DSYSCONFDIR=\"/usr/local/etc\" > > -DRADPID_DIR=\"/var/run\" -DRADLOG_DIR=\"/var/log\" > > -DRADIUS_DATADIR=\"/usr/local/share/radius/1.6.1\" > > -DRADIUS_LIBDIR=\"/usr/local/lib/radius/1.6.1\" -I/usr/local/include/ > > -I/usr/local/include -fno-strict-aliasing -O2 -pipe > > -fstack-protector-strong -fno-strict-aliasing -MT builddbm.o -MD -MP -MF > > .deps/builddbm.Tpo -c -o builddbm.o builddbm.c > > builddbm.c:101:13: warning: call to undeclared function 'grad_dbm_insert'; > > ISO C99 and later do not support implicit function declarations > > [-Wimplicit-function-declaration] > > if (g
Re: Radius challenges in FreeBSD 14.0 Re: FreeBSD 14.0-RC4 Now Available
On Mon, Nov 06, 2023 at 09:50:18AM +0100, Baptiste Daroussin wrote:
> On Mon, Nov 06, 2023 at 09:04:15AM +0100, Baptiste Daroussin wrote:
> > On Mon, Nov 06, 2023 at 12:50:43AM -0700, The Doctor wrote:
> > > On Mon, Nov 06, 2023 at 08:43:05AM +0100, Baptiste Daroussin wrote:
> > > > On Sun, Nov 05, 2023 at 12:11:06PM -0700, The Doctor wrote:
> > > > > On Sun, Nov 05, 2023 at 10:32:44AM -0700, The Doctor wrote:
> > > > > > On Fri, Nov 03, 2023 at 11:42:32PM +, Glen Barber wrote:
> > > > > > > The fourth RC build of the 14.0-RELEASE release cycle is now
> > > > > > > available.
> > > > > > >
> > > > > > > Installation images are available for:
> > > > > > >
> > > > > > > o 14.0-RC4 amd64 GENERIC
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > I am having a problem witb Freeradius and GNU radius.
> > > > > >
> > > > > > Anyone else?
> > > > > >
> > > > > >
> > > > >
> > > > > I found the problem. Replace /usr/lib/libncursesw.so as a symbolic
> > > > > link to /lib/libncursesw.so.9
> > > >
> > > > can you provide more inputs here, please where do you get your
> > > > freeradious or
> > > > gnu radius implementation from, what is failing an so on?
> > > >
> > > > Best regards,
> > > > Bapt
> > >
> > > freeradius looks like a TLS issue with openssl 3
> > >
> > > .
> > >
> > > gnu Radius was biuld by me and not a port.
> > >
> > > Trying to recode is a challenge.
> > >
> > > What is happening is that
> > >
> > > the so file is not being recognised so
> > > I have to symlink in order to get GNU radius 1.6.X to work .
> > >
> > > It will work with /lib/libncursesw.so.9 if the so file is found in
> > > /usr/lib .
> >
> > OK I will dig into gnu-radius, and fix the port if needed! thank you
> >
> > Best regards,
> > Bapt
>
> I just checked here, and I built gnu-radius on a vanilla freebsd 14.0 rc4 and
> a
> vanilla 15 current, and in both case it perfectly links to libncursesw.so.9
> and
> does not require any change of the .so, at least from all the binary analysis
> that I have done, do you have a specific command that will expose the issue?
>
> Can you provide me you gnu-radius package as created by pkg create gnu-radius
> ?
>
> Best regards,
> Bapt
Try to build from ports, here is what I get
cc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../include -I../include/radius
-I../include/radius -I../lib -I../gnu -I../gnu -I/usr/local/include/guile/1.8
-I/usr/local/include -isystem /usr/local/include -D_THREAD_SAFE
-DSYSCONFDIR=\"/usr/local/etc\" -DRADPID_DIR=\"/var/run\"
-DRADLOG_DIR=\"/var/log\" -DRADIUS_DATADIR=\"/usr/local/share/radius/1.6.1\"
-DRADIUS_LIBDIR=\"/usr/local/lib/radius/1.6.1\" -I/usr/local/include/
-I/usr/local/include -fno-strict-aliasing -O2 -pipe -fstack-protector-strong
-fno-strict-aliasing -MT builddbm.o -MD -MP -MF .deps/builddbm.Tpo -c -o
builddbm.o builddbm.c
builddbm.c:101:13: warning: call to undeclared function 'grad_dbm_insert'; ISO
C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
if (grad_dbm_insert(closure->dbmfile, named, contentd)) {
^
builddbm.c:141:13: warning: call to undeclared function
'grad_dbm_create'; ISO C99 and later do not support implicit function
declarations [-Wimplicit-function-declaration]
if (grad_dbm_create(db_file, )) {
^
builddbm.c:147:39: error: incompatible
function pointer types passing 'int (DBM_closure *, User_symbol *)' (aka 'int
(DBM_closure *, struct user_symbol *)') to parameter of type 'int (*)(void *,
grad_symbol_t *)' (aka 'int (*)(void *, struct symbol *)')
[-Wincompatible-function-pointer-types]
grad_symtab_iterate(user_tab,
append_symbol, );
^
../include/radius/symtab.h:48:11: note: passing argument to parameter
'fn' here
Re: Radius challenges in FreeBSD 14.0 Re: FreeBSD 14.0-RC4 Now Available
On Mon, Nov 06, 2023 at 09:04:14AM +0100, Baptiste Daroussin wrote: > On Mon, Nov 06, 2023 at 12:50:43AM -0700, The Doctor wrote: > > On Mon, Nov 06, 2023 at 08:43:05AM +0100, Baptiste Daroussin wrote: > > > On Sun, Nov 05, 2023 at 12:11:06PM -0700, The Doctor wrote: > > > > On Sun, Nov 05, 2023 at 10:32:44AM -0700, The Doctor wrote: > > > > > On Fri, Nov 03, 2023 at 11:42:32PM +, Glen Barber wrote: > > > > > > The fourth RC build of the 14.0-RELEASE release cycle is now > > > > > > available. > > > > > > > > > > > > Installation images are available for: > > > > > > > > > > > > o 14.0-RC4 amd64 GENERIC > > > > > > > > > > > > > > > > > > > > > > I am having a problem witb Freeradius and GNU radius. > > > > > > > > > > Anyone else? > > > > > > > > > > > > > > > > > > I found the problem. Replace /usr/lib/libncursesw.so as a symbolic > > > > link to /lib/libncursesw.so.9 > > > > > > can you provide more inputs here, please where do you get your > > > freeradious or > > > gnu radius implementation from, what is failing an so on? > > > > > > Best regards, > > > Bapt > > > > freeradius looks like a TLS issue with openssl 3 > > > > . > > > > gnu Radius was biuld by me and not a port. > > > > Trying to recode is a challenge. > > > > What is happening is that > > > > the so file is not being recognised so > > I have to symlink in order to get GNU radius 1.6.X to work . > > > > It will work with /lib/libncursesw.so.9 if the so file is found in > > /usr/lib . > > OK I will dig into gnu-radius, and fix the port if needed! thank you > > Best regards, > Bapt Looks like we will a challenge to update. Let me know if you need help. -- Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism ; unsubscribe from Google Groups to be seen Suffering will continue until we stop believing lies. -unknown Beware https://mindspring.com
Radius challenges in FreeBSD 14.0 Re: FreeBSD 14.0-RC4 Now Available
On Mon, Nov 06, 2023 at 08:43:05AM +0100, Baptiste Daroussin wrote: > On Sun, Nov 05, 2023 at 12:11:06PM -0700, The Doctor wrote: > > On Sun, Nov 05, 2023 at 10:32:44AM -0700, The Doctor wrote: > > > On Fri, Nov 03, 2023 at 11:42:32PM +, Glen Barber wrote: > > > > The fourth RC build of the 14.0-RELEASE release cycle is now available. > > > > > > > > Installation images are available for: > > > > > > > > o 14.0-RC4 amd64 GENERIC > > > > > > > > > > > > > > I am having a problem witb Freeradius and GNU radius. > > > > > > Anyone else? > > > > > > > > > > I found the problem. Replace /usr/lib/libncursesw.so as a symbolic > > link to /lib/libncursesw.so.9 > > can you provide more inputs here, please where do you get your freeradious or > gnu radius implementation from, what is failing an so on? > > Best regards, > Bapt freeradius looks like a TLS issue with openssl 3 . gnu Radius was biuld by me and not a port. Trying to recode is a challenge. What is happening is that the so file is not being recognised so I have to symlink in order to get GNU radius 1.6.X to work . It will work with /lib/libncursesw.so.9 if the so file is found in /usr/lib . -- Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism ; unsubscribe from Google Groups to be seen Suffering will continue until we stop believing lies. -unknown Beware https://mindspring.com
Re: FreeBSD 14.0-RC4 Now Available
On Sun, Nov 05, 2023 at 10:32:44AM -0700, The Doctor wrote: > On Fri, Nov 03, 2023 at 11:42:32PM +, Glen Barber wrote: > > The fourth RC build of the 14.0-RELEASE release cycle is now available. > > > > Installation images are available for: > > > > o 14.0-RC4 amd64 GENERIC > > o 14.0-RC4 i386 GENERIC > > o 14.0-RC4 powerpc GENERIC > > o 14.0-RC4 powerpc64 GENERIC64 > > o 14.0-RC4 powerpc64le GENERIC64LE > > o 14.0-RC4 powerpcspe MPC85XXSPE > > o 14.0-RC4 armv7 GENERICSD > > o 14.0-RC4 aarch64 GENERIC > > o 14.0-RC4 aarch64 RPI > > o 14.0-RC4 aarch64 PINE64 > > o 14.0-RC4 aarch64 PINE64-LTS > > o 14.0-RC4 aarch64 PINEBOOK > > o 14.0-RC4 aarch64 ROCK64 > > o 14.0-RC4 aarch64 ROCKPRO64 > > o 14.0-RC4 riscv64 GENERIC > > o 14.0-RC4 riscv64 GENERICSD > > > > Note regarding arm SD card images: For convenience for those without > > console access to the system, a freebsd user with a password of > > freebsd is available by default for ssh(1) access. Additionally, > > the root user password is set to root. It is strongly recommended > > to change the password for both users after gaining access to the > > system. > > > > Installer images and memory stick images are available here: > > > > https://download.freebsd.org/releases/ISO-IMAGES/14.0/ > > > > The image checksums follow at the end of this e-mail. > > > > If you notice problems you can report them through the Bugzilla PR > > system or on the -stable mailing list. > > > > If you would like to use Git to do a source based update of an existing > > system, use the "releng/14.0" branch. > > > > A summary of changes since 14.0-RC3 includes: > > > > o ISA and GIANT-locked driver removal has been delayed to FreeBSD 15, > > and system messages have been updated to reflect such. > > > > o An update to OpenZFS correcting block cloning between encrypted and > > unencrypted datasets has been included. > > > > o A fix for Hyper-V emulation within QEMU resulting in system crashes > > has been addressed. > > > > A list of changes since 13.2-RELEASE is available in the releng/14.0 > > release notes: > > > > https://www.freebsd.org/releases/14.0R/relnotes/ > > > > Please note, the release notes page is not yet complete, and will be > > updated on an ongoing basis as the 14.0-RELEASE cycle progresses. > > > > === Virtual Machine Disk Images === > > > > VM disk images are available for the amd64, i386, and aarch64 > > architectures. Disk images may be downloaded from the following URL > > (or any of the FreeBSD download mirrors): > > > > https://download.freebsd.org/releases/VM-IMAGES/14.0-RC4/ > > > > BASIC-CI images can be found at: > > > > https://download.freebsd.org/releases/CI-IMAGES/14.0-RC4/ > > > > The partition layout is: > > > > ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) > > ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) > > ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) > > > > The disk images are available in QCOW2, VHD, VMDK, and raw disk image > > formats. The image download size is approximately 135 MB and 165 MB > > respectively (amd64/i386), decompressing to a 21 GB sparse image. > > > > Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI > > loader file is needed for qemu-system-aarch64 to be able to boot the > > virtual machine images. See this page for more information: > > > > https://wiki.freebsd.org/arm64/QEMU > > > > To boot the VM image, run: > > > > % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ > > -bios QEMU_EFI.fd -serial telnet::,server -nographic \ > > -drive if=none,file=VMDISK,id=hd0 \ > > -device virtio-blk-device,drive=hd0 \ > > -device virtio-net-device,netdev=net0 \ > > -netdev user,id=net0 > > > > Be sure to replace "VMDISK" with the path to the virtual machine image. > > > > === Amazon EC2 AMI Images === > > > > FreeBSD/amd64 EC2 AMI IDs can be retrieved from the Systems Manager > > Parameter Store in each region using the keys: > > > > /aws/service/freebsd/amd64/base/ufs/14.0/RC4 > > /aws/service/freebsd/amd64/base/zfs/14.0/RC4 > > /aws/service/freebsd/amd64/cloud-init/ufs/14.0/RC4 > > /aws/service/freebsd/amd64/cloud-init/zfs/14.0/RC4 > > > > FreeBSD/aarch64 EC2 AMI IDs
Re: FreeBSD 14.0-RC4 Now Available
On Fri, Nov 03, 2023 at 11:42:32PM +, Glen Barber wrote: > The fourth RC build of the 14.0-RELEASE release cycle is now available. > > Installation images are available for: > > o 14.0-RC4 amd64 GENERIC > o 14.0-RC4 i386 GENERIC > o 14.0-RC4 powerpc GENERIC > o 14.0-RC4 powerpc64 GENERIC64 > o 14.0-RC4 powerpc64le GENERIC64LE > o 14.0-RC4 powerpcspe MPC85XXSPE > o 14.0-RC4 armv7 GENERICSD > o 14.0-RC4 aarch64 GENERIC > o 14.0-RC4 aarch64 RPI > o 14.0-RC4 aarch64 PINE64 > o 14.0-RC4 aarch64 PINE64-LTS > o 14.0-RC4 aarch64 PINEBOOK > o 14.0-RC4 aarch64 ROCK64 > o 14.0-RC4 aarch64 ROCKPRO64 > o 14.0-RC4 riscv64 GENERIC > o 14.0-RC4 riscv64 GENERICSD > > Note regarding arm SD card images: For convenience for those without > console access to the system, a freebsd user with a password of > freebsd is available by default for ssh(1) access. Additionally, > the root user password is set to root. It is strongly recommended > to change the password for both users after gaining access to the > system. > > Installer images and memory stick images are available here: > > https://download.freebsd.org/releases/ISO-IMAGES/14.0/ > > The image checksums follow at the end of this e-mail. > > If you notice problems you can report them through the Bugzilla PR > system or on the -stable mailing list. > > If you would like to use Git to do a source based update of an existing > system, use the "releng/14.0" branch. > > A summary of changes since 14.0-RC3 includes: > > o ISA and GIANT-locked driver removal has been delayed to FreeBSD 15, > and system messages have been updated to reflect such. > > o An update to OpenZFS correcting block cloning between encrypted and > unencrypted datasets has been included. > > o A fix for Hyper-V emulation within QEMU resulting in system crashes > has been addressed. > > A list of changes since 13.2-RELEASE is available in the releng/14.0 > release notes: > > https://www.freebsd.org/releases/14.0R/relnotes/ > > Please note, the release notes page is not yet complete, and will be > updated on an ongoing basis as the 14.0-RELEASE cycle progresses. > > === Virtual Machine Disk Images === > > VM disk images are available for the amd64, i386, and aarch64 > architectures. Disk images may be downloaded from the following URL > (or any of the FreeBSD download mirrors): > > https://download.freebsd.org/releases/VM-IMAGES/14.0-RC4/ > > BASIC-CI images can be found at: > > https://download.freebsd.org/releases/CI-IMAGES/14.0-RC4/ > > The partition layout is: > > ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) > ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) > ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) > > The disk images are available in QCOW2, VHD, VMDK, and raw disk image > formats. The image download size is approximately 135 MB and 165 MB > respectively (amd64/i386), decompressing to a 21 GB sparse image. > > Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI > loader file is needed for qemu-system-aarch64 to be able to boot the > virtual machine images. See this page for more information: > > https://wiki.freebsd.org/arm64/QEMU > > To boot the VM image, run: > > % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ > -bios QEMU_EFI.fd -serial telnet::,server -nographic \ > -drive if=none,file=VMDISK,id=hd0 \ > -device virtio-blk-device,drive=hd0 \ > -device virtio-net-device,netdev=net0 \ > -netdev user,id=net0 > > Be sure to replace "VMDISK" with the path to the virtual machine image. > > === Amazon EC2 AMI Images === > > FreeBSD/amd64 EC2 AMI IDs can be retrieved from the Systems Manager > Parameter Store in each region using the keys: > > /aws/service/freebsd/amd64/base/ufs/14.0/RC4 > /aws/service/freebsd/amd64/base/zfs/14.0/RC4 > /aws/service/freebsd/amd64/cloud-init/ufs/14.0/RC4 > /aws/service/freebsd/amd64/cloud-init/zfs/14.0/RC4 > > FreeBSD/aarch64 EC2 AMI IDs can be retrieved from the Systems Manager > Parameter Store in each region using the keys: > > /aws/service/freebsd/aarch64/base/ufs/14.0/RC4 > /aws/service/freebsd/aarch64/base/zfs/14.0/RC4 > /aws/service/freebsd/aarch64/cloud-init/ufs/14.0/RC4 > /aws/service/freebsd/aarch64/cloud-init/zfs/14.0/RC4 > > === Vagrant Images === > > FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can > be installed by running: > > % vagrant init freebsd/FreeBSD-14.0-RC4 > % vagrant up > > === Upgrading === > > The freebsd-update(8) utility supports binary upgrades of amd64, i386, > and aarch64 systems running earlier FreeBSD releases. Systems running > earlier FreeBSD releases can upgrade as follows: > > # freebsd-update upgrade -r 14.0-RC4 > > During this process, freebsd-update(8) may ask the user to help by > merging some configuration files or by confirming that the automatically
Re: unsubscribe
On Sun, Aug 06, 2023 at 09:01:42AM +0200, Damon Unric wrote: > unsubscribe > please do this via the mailman web interface. -- Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b An extremist would label a moderate an extremist: know who is lying to you, or suffer. -unknown Beware https://mindspring.com
Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"
On Mon, Jul 10, 2023 at 08:56:22AM -0700, Mark Millard wrote: > The subject line's question was prompted by > . . ./hazmat/bindings/_openssl.abi3.so related notices > in a kyua report: > > # kyua report --verbose > --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785 > 2>&1 | grep "Undefined symbol" | sort -u > +ImportError: > /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so: > Undefined symbol "ERR_GET_FUNC" > ImportError: > /usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so: > Undefined symbol "ERR_GET_FUNC" > ImportError: > /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so: > Undefined symbol "ERR_GET_FUNC" > > It is possible that this is related to some oddities of my > context for this. But I figured I'd ask the general question > anyway. > No! The problem is that Python is calling an openssl 1.X function which is dropped in Opensss 3.X Python nedds to fix that issue. > === > Mark Millard > marklmi at yahoo.com > > -- Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b "We should do good unless it inconveniences us," is not righteous thinking. -unknown Beware https://mindspring.com
Re: Version of OpenSSL included in upcoming 14.0-RELEASE
On Sat, Jan 28, 2023 at 04:34:14PM +0900, Yasuhiro Kimura wrote: > Dear developers of base system, > > Though release process of 13.2-RELEASE has just started, please let me > talk about one more next one. > > According to the initial schedule of 14.0-RELEASE, release process > will start on April 25 and 14.0-RELEASE will be released on July > 17. > > https://www.freebsd.org/releases/14.0R/schedule/ > > So it means release process will start about 3 months later and > 14.0-RELEASE will be released about 5.5 months later. And I would like > to ask a question. > > Is it planned (or considered, scheduled, etc.) to upgrade version of > OpenSSL included in 14-CURRENT from 1.1.1 to 3.0? > > According to the "Release Strategy" page of upstream > (https://www.openssl.org/policies/releasestrat.html), OpenSSL 1.1.1 > will reach its EoL on September 11, 2023 and OpenSSL 3.0 will be > supported until September 7, 2026. Since EoL of OpenSSL 1.1.1 is only > after 2 months of the release of 14.0-RELEASE, it doesn't seems > realistic to include OpenSSL 1.1.1 in 14.0-RELEASE and upgrading to > OpenSSL 3.0 is inevitable. > > Though I'm not familiar with the incompatibility between OpenSSL 1.1.1 > and 3.0, I believe it is too optimistic to regard that build of > 14-CURRENT succeeds without any error just by updating > /usr/src/crypto/openssl from 1.1.1 to 3.0. So it will take for a while > (a few weeks?) to finish it. > > And it also affects build of ports. To be honest, it is rather my main > concern as ports committer. I checked Bugzilla and found following PR. > > Bug 258413 [exp-run] OpenSSL 3.0 upgrade > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258413 > > Though it intends to check how many ports fails to be built if > security/openssl is updated to 3.0 and 'DEFAULT_VERSIONS+= openssl' is > set in /etc/make.conf, it is also applicable to after OpenSSL in > 14-CURRENT is updated to 3.0. And according to the result of exp-run, > it doesn't seem to be easy job to adapt ports tree to OpenSSL 3.0. So > it probably will take longer than updating base system. > > And considering these points, 3 months are not necessarily so long. So > I asked a question as above. > > Please let me know current status about it. > I also beleive that FreeBSD should now adopt Openssl 3.0 OPenssl 1.1.1 is about to be defunct. > Best Regards. > > --- > Yasuhiro Kimura > -- Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b Birthdate: 29 Jan 1969 Redhill, Surrey, England Beware https://mindspring.com
Re: Update to the 13.0-RELEASE schedule
On Wed, Mar 31, 2021 at 03:58:51PM +, Glen Barber wrote: > A small set of updates that we consider blocking the 13.0 release have > been brought to our attention. As such, the 13.0-RELEASE schedule has > been updated to include a fifth release candidate (RC5). > > The updated schedule is available on the FreeBSD Project website: > > https://www.freebsd.org/releases/13.0R/schedule/ > > As usual, we will continue to consider critical bug fixes only for the > duration of this release cycle. > > Thank you for your cooperation, and for your patience. > > Glen > On behalf of: re@ > I rather that than a buggy realease. Good show. I will continue to test on my workstation running a Supermicro X10sL7-f -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b We cannot change human failings by ridding ourselves of machines. -unknown ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Firefox most recent version
-87.0/caps/BasePrincipal.cpp:1349 [Child 54719, Main Thread] WARNING: 'NS_FAILED(rv)', file /usr/ports/www/firefox/work/firefox-87.0/dom/storage/LocalStorageManager.cpp:165 [Child 54719, Main Thread] WARNING: Fallback to BasicLayerManager: file /usr/ports/www/firefox/work/firefox-87.0/dom/ipc/BrowserChild.cpp:2697 [Child 54719, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80040111 (NS_ERROR_NOT_AVAILABLE): file /usr/ports/www/firefox/work/firefox-87.0/caps/BasePrincipal.cpp:1349 [Child 54719, Main Thread] WARNING: 'NS_FAILED(rv)', file /usr/ports/www/firefox/work/firefox-87.0/dom/storage/LocalStorageManager.cpp:165 [Child 54719, Main Thread] WARNING: Fallback to BasicLayerManager: file /usr/ports/www/firefox/work/firefox-87.0/dom/ipc/BrowserChild.cpp:2697 [Child 54719, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80040111 (NS_ERROR_NOT_AVAILABLE): file /usr/ports/www/firefox/work/firefox-87.0/caps/BasePrincipal.cpp:1349 [Child 54719, Main Thread] WARNING: 'NS_FAILED(rv)', file /usr/ports/www/firefox/work/firefox-87.0/dom/storage/LocalStorageManager.cpp:165 [Child 54719, Main Thread] WARNING: Fallback to BasicLayerManager: file /usr/ports/www/firefox/work/firefox-87.0/dom/ipc/BrowserChild.cpp:2697 [Child 54719, IPC I/O Child] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /usr/ports/www/firefox/work/firefox-87.0/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc:19 Exiting due to channel error. [Child 54719, IPC I/O Child] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /usr/ports/www/firefox/work/firefox-87.0/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc:19 [Child 54719, IPC I/O Child] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /usr/ports/www/firefox/work/firefox-87.0/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc:19 Exiting due to channel error. Segmentation fault (core dumped) How do I debug this crash? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b They boast of how smart they are, yet cannot even tell salt from sugar.-unknown ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 13.0 RC4 might be delayed
On Thu, Mar 25, 2021 at 09:29:27PM -0600, Scott Long wrote: > Hi everyone, > > Speaking on behalf of Core, i wanted to let you know that 13.0 RC4 might be > delayed. Glen has an emergency to attend to, and might be unavailable or > slow to respond for a few more days. You???re still encouraged to email re@ > with requests and questions. Anything urgent can be directed to core@ if > necessary. > HJust wondering if people are having issues with ports like VLC or Web Browsers? > Thanks, > Scott > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b Without discipline, there's no life at all. -Katharine Hepburn ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mouse is broken
On Mon, Mar 09, 2020 at 09:12:49PM -0400, AN wrote: > > After an update today to world, kernel, and ports my mouse no longer works. > Mouse works on console. I use startx, mouse seems to break after startx is > issued. > > Is any one else seeing anything similar? Any help is appreciated, thanks > in advance. I have the same issue. > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism An enlightened soul would not demand of another to believe lies. -unknown ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
POSIX Threads
Any known issues with Posix threads in FreeBSD 11? While I am at it, What about python and pip? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Time for the USA to hold a referendum on its republic and vote to dissolve!! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -Current + X 4.0.1 = mouse problems
Out of da blue Doug Barton aka ([EMAIL PROTECTED]) said:
David Siebörger wrote:
I've experienced the (apparently common) problem of switching from X
to console and back to X and getting an unresponsive mouse pointer in
X. This occurs when I use protocol "Auto", or don't specify a
protocol.
Someone was kind enough to send me the attached patch. With
Option "Protocol""Auto"
Option "Device" "/dev/sysmouse"
it works with moused. I tried protocol sysmouse, but it didn't work.
Neither did Christian's advice about the mousesystems protocol. I also
have a wheeled mouse, logitech specifically.
I too am experiencing problem. I have a logitech serial wheel mouse. However
X will only fire up if I tell it to ignore the "cannot open input device"
for my Mouse1 identifier :(. I'll try this patch and see what happens.
It would be nice to include this patch in our X4 port.
Doug
--
"The dead cannot be seduced."
- Kai, "Lexx"
Do YOU Yahoo!?
--- programs/Xserver/hw/xfree86/input/mouse/mouse.c.orig Sun Jul 23 17:50:10
2000
+++ programs/Xserver/hw/xfree86/input/mouse/mouse.c Sun Jul 23 17:54:22 2000
@@ -692,10 +692,15 @@
pMse-protocolID = protocolID;
}
}
+#ifndef __FreeBSD__
memcpy(pMse-protoPara, proto[pMse-protocolID], sizeof(pMse-protoPara));
+#endif
if (automatic) {
if (name) {
+#ifdef __FreeBSD__
+ memcpy(pMse-protoPara, proto[pMse-protocolID], sizeof(pMse-protoPara));
+#endif
/* Possible protoPara overrides from SetupAuto. */
for (i = 0; i sizeof(pMse-protoPara); i++)
if (protoPara[i] != -1)
--- programs/Xserver/hw/xfree86/os-support/bsd/bsd_mouse.c.orig Sat Feb 12
22:45:41 2000
+++ programs/Xserver/hw/xfree86/os-support/bsd/bsd_mouse.cSun Jul 23 17:50:10
2000
@@ -165,7 +165,11 @@
mode.rate = rate 0 ? rate : -1;
mode.resolution = res 0 ? res : -1;
mode.accelfactor = -1;
+#ifdef __FreeBSD__
+mode.level = 1;
+#else
mode.level = -1;
+#endif
ioctl(pInfo-fd, MOUSE_SETMODE, mode);
}
#endif
#:^)
--
f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.
bush doctor
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Starange behaviour ...
I need some hints in finding the answer to the following. When compiling xscreensaver-3.24 from the ports on my home box I get the following diagnostics (P200 128Mb ram) ikhala.tcimet.net:dervish uname -a FreeBSD ikhala.tcimet.net 5.0-CURRENT FreeBSD 5.0-CURRENT #28: Sat Jun 3 07:10:29 EDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/GANJA i386 cc -Wall -Wstrict-prototypes -Wnested-externs -Wno-format -Wp,-lang-c89 -L/usr/X11R6/lib -o cage cage.o screenhack-gl.o xlock-gl.o ../xlockm ore.o ../../utils/resources.o ../../utils/visual.o ../../utils/visual-gl.o ../../utils/usleep.o ../../utils/yarandom.o ../../utils/hsv.o ../../utils/colors.o -L/usr/X11R6/lib -lMesaGL -lMesaGLU -lXmu -lSM -lICE -lXmu -lXt -lXt -lX11 -lXext -lm /usr/lib/libc_r.so.4: WARNING! setkey(3) not present in the system! /usr/lib/libc_r.so.4: warning: this program uses gets(), which is unsafe. /usr/lib/libc_r.so.4: warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/lib/libc_r.so.4: WARNING! des_setkey(3) not present in the system! /usr/lib/libc_r.so.4: WARNING! encrypt(3) not present in the system! /usr/lib/libc_r.so.4: warning: tmpnam() possibly used unsafely; consider using mkstemp() /usr/lib/libc_r.so.4: warning: this program uses f_prealloc(), which is stupid. /usr/lib/libc_r.so.4: WARNING! des_cipher(3) not present in the system! /usr/lib/libc_r.so.4: warning: tempnam() possibly used unsafely; consider using mkstemp() cc -Wall -Wstrict-prototypes -Wnested-externs -Wno-format -Wp,-lang-c89 -c -I. -I./../../utils -I./.. -I../.. -I/usr/X11R6/include -DSTANDA LONE -DUSE_GL -DHAVE_CONFIG_H -O -pipe -I/usr/X11R6/include gears.c Alone this would indicate that the port needs to be linked with the -pthreads option. However on my box at work (PIII 550 128Mb ram) goku.cl.msu.edu:dervish uname -a FreeBSD goku.cl.msu.edu 5.0-CURRENT FreeBSD 5.0-CURRENT #40: Thu May 25 21:56:27 EDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/GOKU i386 the same port reports none of the warnings :(. Any clues? #;^) -- So ya want ta hear da roots? bush doctor [EMAIL PROTECTED] Of course I run FreeBSD!! http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Starange behaviour ...
Out of da blue Will Andrews aka ([EMAIL PROTECTED]) said: On Sun, Jun 04, 2000 at 12:58:28PM -0400, bush doctor wrote: the same port reports none of the warnings :(. Any clues? Different libc linking in one of the libs. Thanxs, I found the culprit. I needed to rebuild libgii. Looks like I hadn't rebuilt since the -pthread option was implemented. -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? #;-) -- So ya want ta hear da roots? bush doctor [EMAIL PROTECTED] Of course I run FreeBSD!! http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
Out of da blue David Scheidt aka ([EMAIL PROTECTED]) said: On Fri, 28 Apr 2000, David O'Brien wrote: On Fri, Apr 28, 2000 at 01:17:56PM -0400, Brian Dean wrote: I've often traced files back to the begining of FreeBSD time (and then continued in the CSRG SCCS tree). I've wanted to do this on occasion. Where are these pre-FreeBSD history records available? Glad you asked. http://www.mckusick.com/csrg/index.html Not incidently, SCO have waived the $100 license application fee, which means that you can get your own official Ancient UNIX(TM) Source Code License for free. This roughly cuts in half the cost of the disks for someone not covered under a orginizaitonal souce code license. Is there a new license form to sign or do we just fill out the current form without sending the applicateion fee? David Scheidt #;^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
Out of da blue David Scheidt aka ([EMAIL PROTECTED]) said: On Fri, 28 Apr 2000, Bush Doctor wrote: Out of da blue David Scheidt aka ([EMAIL PROTECTED]) said: Not incidently, SCO have waived the $100 license application fee, which means that you can get your own official Ancient UNIX(TM) Source Code License for free. This roughly cuts in half the cost of the disks for someone not covered under a orginizaitonal souce code license. Is there a new license form to sign or do we just fill out the current form without sending the applicateion fee? I don't know. SCO just made the announcement a week or two ago -- the same time they BSD licensed cscope -- and don't appear to have made changes to their web site yet. The press release is at http://www.sco.com/press/releases/2000/6927.html It might be worthwhile to attempt to contact the contact name on the release. Thanxs, I'll do that. David #;^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Warnings when linking against libc_r
I'm seeing the following diagnostics with applications linked against libc_r cc -O -pipe -I/usr/local/include -D_REENTRANT -D_THREAD_SAFE -g -Wall -o .libs/structs structs.o -L/usr/local/lib ../../ggi/.libs/libggi.so -lc_r /usr/local/lib/libgg.so /usr/local/lib/libgii.so -Wl,--rpath -Wl,/usr/local/lib /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc.so: WARNING! setkey(3) not present in the system! /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid. Can these be ignored? From what I gathered from the mailing list archives this issue has reared its head before. goku.cl.msu.edu:dervish uname -a FreeBSD goku.cl.msu.edu 5.0-CURRENT FreeBSD 5.0-CURRENT #33: Tue Mar 14 11:25:48 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/GOKU i386 #;^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Warnings when linking against libc_r
Out of da blue Chris Costello aka ([EMAIL PROTECTED]) said: On Tuesday, March 28, 2000, Bush Doctor wrote: I'm seeing the following diagnostics with applications linked against libc_r ... Do not directly link with libc_r. Instead, use the -pthread gcc flag. It will properly compile and link your program with the correct thread bits. Thanxs Chris. If this was discussed on -current, I apologise for missing the discussion. :( A question why can we not link directly with libc_r? If this was discussed on -current I can look it up in the archives. Looks like gnats will be seeing some send-pr's about this. Thanxs again! -- |Chris Costello [EMAIL PROTECTED] |I/O, I/O, it's off to work we go... ` #;^) -- So ya want ta hear da roots? bush doctor [EMAIL PROTECTED] Of course I run FreeBSD!! http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure in cvs ...
Out of da blue Kris Kennaway aka ([EMAIL PROTECTED]) said: On Thu, 9 Mar 2000, Bush Doctor wrote: Again my libRSAglue libraries before the above were: bantu.cl.msu.edu:dervish ls -l /usr/lib/libR* -r--r--r-- 1 root wheel 810 Feb 28 22:28 /usr/lib/libRSAglue.a lrwxr-xr-x 1 root wheel 15 Jan 29 07:29 /usr/lib/libRSAglue.so - libRSAglue.so.1 -r--r--r-- 1 root wheel5872 Jan 29 07:29 /usr/lib/libRSAglue.so.1 -r--r--r-- 1 root wheel 868 Feb 28 22:28 /usr/lib/libRSAglue_p.a This was very helpful - I've been able to replicate the problem by install an old libRSAglue of this vintage. It still doesn't answer why on earth make world is trying to link with it, but at least now I have something to look at. Thanks! You're welcome. I'm interested in what you find out. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] #;^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure in cvs ...
Out of da blue Jim Bloom aka ([EMAIL PROTECTED]) said: Kris Kennaway wrote: On Thu, 9 Mar 2000, Bush Doctor wrote: Again my libRSAglue libraries before the above were: bantu.cl.msu.edu:dervish ls -l /usr/lib/libR* -r--r--r-- 1 root wheel 810 Feb 28 22:28 /usr/lib/libRSAglue.a lrwxr-xr-x 1 root wheel 15 Jan 29 07:29 /usr/lib/libRSAglue.so - libRSAglue.so.1 -r--r--r-- 1 root wheel5872 Jan 29 07:29 /usr/lib/libRSAglue.so.1 -r--r--r-- 1 root wheel 868 Feb 28 22:28 /usr/lib/libRSAglue_p.a This was very helpful - I've been able to replicate the problem by install an old libRSAglue of this vintage. It still doesn't answer why on earth make world is trying to link with it, but at least now I have something to look at. Thanks! I looked into this problem a bit as well. I believe it is a build order and dependency problem that shouldn't exist. libkrb is built before libRSAglue and then the shared library is built with -LRSAglue which is only found in /usr/lib. kerberosIV/Makefile.inc has a line "LDADD+= -LRSAglue". This whole issue should not exist simply because libRSAglue is a dummy stub and there is no reson to link anything against it. The quick fix is to remove libRSAglue from the makefiles where it is used. The following makefiles need to have the references to RSAglue removed: Hmmm ..., I just helped a co-worker upgrade from -release to -current and he ran into a problem where 'make buildworld' failed in building Kerberos IV. I seem to recall a similiar problem a few weeks back on my -current box. I wound up commenting out the kerberos IV build in make.conf, performed a 'make buildworld' and 'make installworld' without kerberos IV, and rebuilt world afterwards with kerberos IV enabled. I really must be more proactive in reporting -current hiccups I come across :( Unfortunately, my co-worker has already overwritten the buildworld log :( usr.sbin/ppp/Makefile usr.sbin/pppd/Makefile secure/libexec/sshd/Makefile kerberosIV/Makefile.inc I don't know how to change ld (compile time?) so that it doesn't look in the standard locations for files during buildworld. That is what is required to guarantee this problem doesn't happen again. Kris, would you like patches or will you edit these yourself? Jim Bloom [EMAIL PROTECTED] #;^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld failure in cvs ...
Is anyone else seeing this. cvsupped from 12:00 noon EST ... cc -O -pipe -I/usr/src/gnu/usr.bin/cvs/cvs -I/usr/src/gnu/usr.bin/cvs/cvs/../lib -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/cvs/cvs/../../../.. /contrib/cvs/src -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/lib -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/diff -DHA VE_KERBEROS -DHAVE_KRB_GET_ERR_TEXT -DENCRYPTION -I/usr/obj/usr/src/i386/usr/include -o cvs add.o admin.o buffer.o checkin.o checkout.o c lassify.o client.o commit.o create_adm.o cvsrc.o diff.o edit.o entries.o error.o expand_path.o fileattr.o filesubr.o find_names.o hardlink.o hash.o history.o ignore.o import.o lock.o log.o login.o logmsg.o main.o mkmodules.o modules.o myndbm.o no_diff.o parseinfo.o patch.o prepen d_args.o rcs.o rcscmds.o recurse.o release.o remove.o repos.o root.o rtag.o run.o scramble.o server.o status.o subr.o tag.o update.o vers_ts .o version.o watch.o wrapper.o zlib.o /usr/obj/usr/src/gnu/usr.bin/cvs/cvs/../lib/libcvs.a /usr/obj/usr/src/gnu/usr.bin/cvs/cvs/../libdiff/ libdiff.a -lgnuregex -lmd -lcrypt -lz -lkrb -lcrypto -lcom_err /usr/lib/libRSAglue.so.1: undefined reference to `R_RandomUpdate' /usr/lib/libRSAglue.so.1: undefined reference to `R_GetRandomBytesNeeded' /usr/lib/libRSAglue.so.1: undefined reference to `RSAPrivateDecrypt' /usr/lib/libRSAglue.so.1: undefined reference to `RSAPublicEncrypt' /usr/lib/libRSAglue.so.1: undefined reference to `R_RandomFinal' /usr/lib/libRSAglue.so.1: undefined reference to `RSAPrivateEncrypt' /usr/lib/libRSAglue.so.1: undefined reference to `R_RandomInit' /usr/lib/libRSAglue.so.1: undefined reference to `RSAPublicDecrypt' *** Error code 1 Stop in /usr/src/gnu/usr.bin/cvs/cvs. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cvs. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. #;^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure in cvs ...
Out of da blue Kris Kennaway aka ([EMAIL PROTECTED]) said: On Thu, 9 Mar 2000, Bush Doctor wrote: Is anyone else seeing this. cvsupped from 12:00 noon EST ... cc -O -pipe -I/usr/src/gnu/usr.bin/cvs/cvs -I/usr/src/gnu/usr.bin/cvs/cvs/../lib -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/cvs/cvs/../../../.. /contrib/cvs/src -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/lib -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/diff -DHA VE_KERBEROS -DHAVE_KRB_GET_ERR_TEXT -DENCRYPTION -I/usr/obj/usr/src/i386/usr/include -o cvs add.o admin.o buffer.o checkin.o checkout.o c lassify.o client.o commit.o create_adm.o cvsrc.o diff.o edit.o entries.o error.o expand_path.o fileattr.o filesubr.o find_names.o hardlink.o hash.o history.o ignore.o import.o lock.o log.o login.o logmsg.o main.o mkmodules.o modules.o myndbm.o no_diff.o parseinfo.o patch.o prepen d_args.o rcs.o rcscmds.o recurse.o release.o remove.o repos.o root.o rtag.o run.o scramble.o server.o status.o subr.o tag.o update.o vers_ts .o version.o watch.o wrapper.o zlib.o /usr/obj/usr/src/gnu/usr.bin/cvs/cvs/../lib/libcvs.a /usr/obj/usr/src/gnu/usr.bin/cvs/cvs/../libdiff/ libdiff.a -lgnuregex -lmd -lcrypt -lz -lkrb -lcrypto -lcom_err /usr/lib/libRSAglue.so.1: undefined reference to `R_RandomUpdate' Did this come up as part of make world? It looks like you have a stale library. It's occurring during a buildworld. If you're referring to libRSAglue being stale it looks like that may be it. bantu.cl.msu.edu:dervish ls -l /usr/lib/libR* -r--r--r-- 1 root wheel 810 Feb 28 22:28 /usr/lib/libRSAglue.a lrwxr-xr-x 1 root wheel 15 Jan 29 07:29 /usr/lib/libRSAglue.so - libRSAglue.so.1 -r--r--r-- 1 root wheel5872 Jan 29 07:29 /usr/lib/libRSAglue.so.1 -r--r--r-- 1 root wheel 868 Feb 28 22:28 /usr/lib/libRSAglue_p.a Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] #;^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure in cvs ...
Out of da blue Kris Kennaway aka ([EMAIL PROTECTED]) said: On Thu, 9 Mar 2000, Benjamin Greenwald wrote: I did try blowing away /obj. Didn't help. Hmm. I'll try running a buildworld at home tonight with stale libRSAglue libs in /usr/lib and see if I can reproduce this. I don't think it's anything in the source tree which is causing the breakage directly - although if it's picking up things outside /usr/obj during the course of the buildworld that needs to be fixed. Not that it directly relates to the problem, I wound up doing the following to get 'make buildworld' to work: 1. rm -rf ../obj/* make clean make cleandepend make cleandir make clean make update 2. cd secure;make obj;make depend make all install 3. rm -rf ../obj/* make clean make cleandepend make cleandir make cleandir make clean Again my libRSAglue libraries before the above were: bantu.cl.msu.edu:dervish ls -l /usr/lib/libR* -r--r--r-- 1 root wheel 810 Feb 28 22:28 /usr/lib/libRSAglue.a lrwxr-xr-x 1 root wheel 15 Jan 29 07:29 /usr/lib/libRSAglue.so - libRSAglue.so.1 -r--r--r-- 1 root wheel5872 Jan 29 07:29 /usr/lib/libRSAglue.so.1 -r--r--r-- 1 root wheel 868 Feb 28 22:28 /usr/lib/libRSAglue_p.a and after: bantu.cl.msu.edu:dervish ls -l /usr/lib/libR* -r--r--r-- 1 root wheel 810 Mar 9 18:02 /usr/lib/libRSAglue.a lrwxr-xr-x 1 root wheel 15 Mar 9 18:02 /usr/lib/libRSAglue.so - libRSAglue.so.1 -r--r--r-- 1 root wheel1616 Mar 9 18:02 /usr/lib/libRSAglue.so.1 -r--r--r-- 1 root wheel 868 Mar 9 18:02 /usr/lib/libRSAglue_p.a Unfortunately I blew away the old libraries, but would like to know what happens with your test ... Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] #;^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mod_ssl current
Out of da blue Sean-Paul Rees aka ([EMAIL PROTECTED]) said: I'm having a problem getting Apache setup to work with modssl; I'm running apache1.3.12+php4+mod_ssl2.6.0 [root@valiant]-~# apachectl startssl /usr/local/sbin/apachectl startssl: httpd could not be started No other info whatsoever. (helpful, huh? :-) I've run into the same problem. You'll probably see this in /var/log/apache_error_log /usr/libexec/ld-elf.so.1: /usr/lib/librsaUSA.so: Undefined symbol "ERR_load_strings" /usr/libexec/ld-elf.so.1: /usr/lib/librsaUSA.so: Undefined symbol "ERR_load_strings" /usr/libexec/ld-elf.so.1: /usr/lib/librsaUSA.so: Undefined symbol "ERR_load_strings" /usr/libexec/ld-elf.so.1: /usr/lib/librsaUSA.so: Undefined symbol "ERR_load_strings" This symbol is in /usr/lib/libssl.a and in /usr/lib/librsaUSA.a. I had a similar problem before and was helped by someone on the list, but I've seem to have lost the solution he gave :( I wound up haveing to add some linking info in the Makefile in /usr/ports/www/apache13-php3/work/apache_1.3.12/src/modules/ssl. Just can't remember. I'm using the stock configuration file with just hostname changes throughout. I'm getting this with apache+php+mod_ssl-1.3.12+3.0.15+2.6.1 (php3) Any ideas? I'm running current from 2/26/2000. Not at the moment, but still checking. -- Cheers, Sean #;^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: international RSA code
Out of da blue Peter Wemm aka ([EMAIL PROTECTED]) said: I've added a port, ports/security/librsaintl, that should build and install the librsaINTL.* files in /usr/lib, in case you did a binary install or are stuck with the USA source. The port is quite a hack, but I'd be interested to know how it works for folks. Note that there have been several versions, so make sure you've got the current version before trying to use it. :-) This builds the optimized RSA code designed for use by the ssl code. It also is used by openssh. RSAREF requires big number format conversion, this code does not. RSAREF is also limited to 1024 bit keys, this code has no such limitation. I'm still not clear on the issue of RSAREF :( In the US do we need to have the rsaref port installed in order to use openssl/openssh in the source tree? If not then in /etc/make.conf we can set "RSAREF=NO" and buildworld will DTRT with respect to openssl/openssh? thanxs ... Cheers, -Peter #;^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Will the real libcrypto please stand up?
I'm a bit confused about the libcrypto situation and need some clarification :) I'm running -current and rebuilt the apache13-php3 port recently. The port depends on /usr/local/lib/libcrypto.so.1, however when starting the ssl version I get the following: ikhala.tcimet.net:root apachectl startssl Syntax error on line 240 of /usr/local/etc/apache/apache.conf: Cannot load /usr/local/libexec/apache/libssl.so into server: /usr/lib/libcrypto.so.1: Undefined symbol "ERR_load_RSAREF_strings" /usr/local/sbin/apachectl startssl: httpd could not be started My question is simply what is the "correct" fix so all apps needing libcrypto will find the one it needs? Should there be only one? I know I'm missing something simple. Thanxs #;^) -- So ya want ta hear da roots? bush doctor [EMAIL PROTECTED] Of course I run FreeBSD!! http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Will the real libcrypto please stand up?
Out of da blue Manfred Antar aka ([EMAIL PROTECTED]) said: At 02:20 PM 2/3/00 -0500, bush doctor wrote: I'm a bit confused about the libcrypto situation and need some clarification :) I'm running -current and rebuilt the apache13-php3 port recently. The port depends on /usr/local/lib/libcrypto.so.1, however when starting the ssl version I get the following: ikhala.tcimet.net:root apachectl startssl Syntax error on line 240 of /usr/local/etc/apache/apache.conf: Cannot load /usr/local/libexec/apache/libssl.so into server: /usr/lib/libcrypto.so.1: Undefined symbol "ERR_load_RSAREF_strings" /usr/local/sbin/apachectl startssl: httpd could not be started My question is simply what is the "correct" fix so all apps needing libcrypto will find the one it needs? Should there be only one? I know I'm missing something simple. Thanxs I had to add -L/usr/local/lib -lrsaref -lRSAglue to the SSL_LIBS= line of /usr/ports/www/apache13-php3/work/apache_1.3.11/src/modules/ssl/Makefile then it works fine. Thanxs Manfred. That did the trick. I removed the crypto port. ( I remembered seeing the posts about that, but looks like I got caught napping :) Have you sent a send-pr for this? If not I can wrap one around your fix. Thanxs again ... Manfred = ||[EMAIL PROTECTED] || ||Ph. (415) 681-6235|| = #;^) -- So ya want ta hear da roots? bush doctor [EMAIL PROTECTED] Of course I run FreeBSD!! http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make installworld broken???
I'm seeing the following failure on my -current box with sources cvsupped last night about 11:30 est. === bin/ps install -C -c -s -o root -g wheel -m 555 ps /bin install -C -c -o root -g wheel -m 444 ps.1.gz /usr/share/man/man1 === bin/pwd install -C -c -s -o root -g wheel -m 555 pwd /bin install -C -c -o root -g wheel -m 444 pwd.1.gz /usr/share/man/man1 === bin/rcp install -C -c -s -o root -g wheel -m 4555 -fschg rcp /bin /usr/libexec/ld-elf.so.1: install: Undefined symbol "string_to_flags" *** Error code 1 Stop in /usr/src/bin/rcp. *** Error code 1 Stop in /usr/src/bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. #;^) -- So ya want ta hear da roots? bush doctor [EMAIL PROTECTED] Of course I run FreeBSD!! http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make installworld broken???
Out of da blue Poul-Henning Kamp aka ([EMAIL PROTECTED]) said: You need to manually recompile and install your "install" command. Thanxs. I had looked at this, but wasn't sure. It's source-dir is called "xinstall" btw. Why is the source called "xinstall"? Poul-Henning In message [EMAIL PROTECTED], bush doctor writes: I'm seeing the following failure on my -current box with sources cvsupped last night about 11:30 est. [snippage ...] -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! #;^) -- So ya want ta hear da roots? bush doctor [EMAIL PROTECTED] Of course I run FreeBSD!! http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken using /usr/local/lib?
Out of da blue Alfred Perlstein aka ([EMAIL PROTECTED]) said: broken here for the last 12 hours or so: cc -pipe -O2 -DMONOLITH -DNO_IDEA -I/home/src/secure/usr.bin/openssl -DRSAref -I/usr/obj/home/src/i386/usr/include -c /home/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/speed.c cc -pipe -O2 -DMONOLITH -DNO_IDEA -I/home/src/secure/usr.bin/openssl -DRSAref -I/usr/obj/home/src/i386/usr/include -c /home/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/verify.c cc -pipe -O2 -DMONOLITH -DNO_IDEA -I/home/src/secure/usr.bin/openssl -DRSAref -I/usr/obj/home/src/i386/usr/include -c /home/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/version.c cc -pipe -O2 -DMONOLITH -DNO_IDEA -I/home/src/secure/usr.bin/openssl -DRSAref -I/usr/obj/home/src/i386/usr/include -c /home/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/x509.c cc -pipe -O2 -DMONOLITH -DNO_IDEA -I/home/src/secure/usr.bin/openssl -DRSAref -I/usr/obj/home/src/i386/usr/include -o openssl apps.o asn1pars.o ca.o ciphers.o crl.o crl2p7.o dgst.o dh.o dsa.o dsaparam.o enc.o errstr.o gendh.o gendsa.o genrsa.o nseq.o openssl.o pkcs12.o pkcs7.o pkcs8.o req.o rsa.o s_cb.o s_client.o s_server.o s_socket.o s_time.o sess_id.o speed.o verify.o version.o x509.o -lssl -lcrypto -L/usr/local/lib -lrsaref speed.o: In function `speed_main': speed.o(.text+0x66a): undefined reference to `RSA_PKCS1_RSAref' /usr/local/lib/libcrypto.so: undefined reference to `ERR_load_RSAREF_strings' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error ? do i need to rebuild a port, and why? Did a quick look and found the following: ikhala.tcimet.net:dervish nm /usr/local/lib/libRSAglue.a | grep ERR_load_RSAREF_strings T ERR_load_RSAREF_strings ikhala.tcimet.net:dervish Do we also need a -lRSAglue? thanks, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] -- So ya want ta hear da roots? bush doctor [EMAIL PROTECTED] Of course I run FreeBSD!! http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld failure in === makeinfo
le\" -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo -I/usr/sr c/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib -I/usr/obj/usr/src/i386/usr/include -c /usr/src/gnu/usr.bin/texinfo/makeinf o/../../../../contrib/texinfo/makeinfo/sectioning.c cc -O -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo -I/usr/sr c/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib -I/usr/obj/usr/src/i386/usr/include -c /usr/src/gnu/usr.bin/texinfo/makeinf o/../../../../contrib/texinfo/makeinfo/toc.c cc -O -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo -I/usr/sr c/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib -I/usr/obj/usr/src/i386/usr/include -o makeinfo cmds.o defun.o files.o foo tnote.o html.o index.o insertion.o lang.o macro.o makeinfo.o multi.o node.o sectioning.o toc.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/te xinfo/makeinfo/../libtxi/libtxi.a /usr/obj/usr/src/i386/usr/libexec/elf/ld: cannot open crt1.o: No such file or directory *** Error code 1 Stop in /usr/src/gnu/usr.bin/texinfo/makeinfo. *** Error code 1 Stop in /usr/src/gnu/usr.bin/texinfo. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 #:^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Buildworld failing in === secure/usr.bin/openssl
From sources cvsup around 14:00 EST ... cc -O -pipe -DMONOLITH -DNO_IDEA -I/usr/src/secure/usr.bin/openssl -DNO_RSA -DNO_SSL2 -I/usr/obj/usr/src/i386/usr/include -o openssl apps.o asn1pars.o ca.o ciphers.o crl.o crl2p7.o dgst.o dh.o dsa.o dsaparam.o enc.o errstr.o gendh.o gendsa.o genrsa.o nseq.o openssl.o pkcs12.o pkcs7.o pkcs8.o req.o rsa.o s_cb.o s_client.o s_server.o s_socket.o s_time.o sess_id.o speed.o verify.o version.o x509.o -lssl -lcrypto /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `R_RandomUpdate' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `R_GetRandomBytesNeeded' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `RSAPrivateDecrypt' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `RSAPublicEncrypt' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `R_RandomFinal' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `RSAPrivateEncrypt' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `R_RandomInit' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `RSAPublicDecrypt' *** Error code 1 Stop in /usr/src/secure/usr.bin/openssl. *** Error code 1 Stop in /usr/src/secure/usr.bin. *** Error code 1 Stop in /usr/src/secure. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. #:^) -- So ya want ta hear da roots? bush doctor [EMAIL PROTECTED] Of course I run FreeBSD!! http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Buildworld failing in === secure/usr.bin/openssl
Out of da blue Matthew Jacob aka ([EMAIL PROTECTED]) said: Has been fixed, approx 1700 EST. Thanxs. I knew I should have re-supped before sending to list. On Mon, 17 Jan 2000, bush doctor wrote: From sources cvsup around 14:00 EST ... cc -O -pipe -DMONOLITH -DNO_IDEA -I/usr/src/secure/usr.bin/openssl -DNO_RSA -DNO_SSL2 -I/usr/obj/usr/src/i386/usr/include -o openssl apps.o asn1pars.o ca.o ciphers.o crl.o crl2p7.o dgst.o dh.o dsa.o dsaparam.o enc.o errstr.o gendh.o gendsa.o genrsa.o nseq.o openssl.o pkcs12.o pkcs7.o pkcs8.o req.o rsa.o s_cb.o s_client.o s_server.o s_socket.o s_time.o sess_id.o speed.o verify.o version.o x509.o -lssl -lcrypto /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `R_RandomUpdate' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `R_GetRandomBytesNeeded' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `RSAPrivateDecrypt' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `RSAPublicEncrypt' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `R_RandomFinal' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `RSAPrivateEncrypt' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `R_RandomInit' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `RSAPublicDecrypt' *** Error code 1 Stop in /usr/src/secure/usr.bin/openssl. *** Error code 1 Stop in /usr/src/secure/usr.bin. *** Error code 1 Stop in /usr/src/secure. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. #:^) -- So ya want ta hear da roots? bush doctor [EMAIL PROTECTED] Of course I run FreeBSD!! http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld fails (yet another failure)
/kerberosIV/lib/libkadm/../../lib/libkadm/kadm_err.h:13: warning: `ERROR_TABLE_BASE_' redefined /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkrb/krb_err.h:13: warning: this is the location of the previous definition /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkadm/kadm_err.h:17: invalid macro name In file included from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_locl.h:74, from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/check_password.c:34: /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkrb/krb_err.h:17: invalid macro name In file included from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_locl.h:77, from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/check_password.c:34: /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkadm/kadm_err.h:13: warning: `ERROR_TABLE_BASE_' redefined /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkrb/krb_err.h:13: warning: this is the location of the previous definition /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkadm/kadm_err.h:17: invalid macro name mkdep: compile failed *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. root@wintermute# #:^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: config tool breaks
Out of da blue Forrest Aldrich aka ([EMAIL PROTECTED]) said: Is this a bug, or did I miss something on the list that changed this procedure: cd /usr/src/sys/i386/conf) bash-2.03# config MYMACHINE config: files.i386: No such file or directory bash-2.03# exit The files.* is missing, etc. No changes after a cvsup. Did you build a new config first? _F #:^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Status on building modula-3 and cvsup on -current ...
Out of da blue John Polstra aka ([EMAIL PROTECTED]) said: In article [EMAIL PROTECTED], Bush Doctor I [EMAIL PROTECTED] wrote: What's the latest on building modula 3 and cvsup on -current systems? It probably doesn't work right yet -- I'm not sure. I've been too busy and there have been too many code freezes to get the patches for the sigset_t expansion in so far. It's on my to-do list. Meanwhile, the binaries (cvsup-bin and cvsupd-bin ports) work fine under -current. Yes the modula-3 libraries aren't building. I've gone ahead and installed cvsup-bin and everthing is working fine. Thanxs. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron #:^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Status on building modula-3 and cvsup on -current ...
What's the latest on building modula 3 and cvsup on -current systems? thanxs ... #:^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pnp and AWE64
Out of da blue Jim King aka ([EMAIL PROTECTED]) said: I just picked up an AWE64 to use until the Vortex2 driver is working. Is someone actively working on the Vortex2 driver for FreeBSD or are you referring to the work that's being done by the opensound group? The card is detected in Win98, but unfortunately the new PnP code in -current (cvsup'ed this evening) doesn't seem to find this card at all. Nothing shows up about it in dmesg; pnpinfo shows my ISA PnP modem, but nothing at all about the AWE64. #:^) -- bush doctor harder than the rest ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata driver and mounting CDROMs, missing tape drives
Quoting Bryan Liesner ([EMAIL PROTECTED]): I've been having trouble mounting my ATAPI CDROM using the new ATA drivers When I do a: %mount /cdrom, the system complains: %mount_cd9660 /cdrom or %mount -t cd9660 /cdrom #:^) -- bush doctor harder than the rest ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
A question about kld filesystems and xFS_ROOT options
Now that file systems options such as CD9660, MFS and NFS can be loaded dynamically do lines like options CD9660_ROOT #CD-ROM usable as root device still need to occur in our kernel config files if we want them usable as root devices? #;^) -- So ya want ta here da roots? Dem that feels it knows it ... bush doctor derv...@bantu.cl.msu.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: What is MTRR all about???
Quoting Daniel J. O'Connor (dar...@dons.net.au): On 05-Jun-99 bush doctor wrote: No man page yet. No horrors tho'. Man pages and info files are great, but there's nothing like reading through the sources ... #;^) Well given that the source contains help information its not a bad problem.. I think the author is a tad busy at the moment :) Agreed ... #;^) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum #;^) -- So ya want ta here da roots? Dem that feels it knows it ... bush doctor derv...@bantu.cl.msu.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Extra text modes via vidcontrol...
Quoting Kazutaka YOKOTA (yok...@zodiac.mech.utsunomiya-u.ac.jp): Are you sure you enabled options VM86 in the kernel configuration file and loaded the vesa module by the boot loader? Hmmm ... When I added options VM86 to my kernel config file I get: su-2.02# config BANTU BANTU:135: unknown option VM86 Unknown option used - it is VERY important that you do make clean make depend before recompiling Kernel build directory is ../../compile/BANTU Umm, this means that your source tree is not as current as it should be, in order to be called 4.0-CURRENT. The VM86 option was added to the -CURRENT branch long before 3.0-RELEASE! How are you updating your source tree in /usr/src? I update everyday with cvsup. bantu.cl.msu.edu:dervish uname -a FreeBSD bantu.cl.msu.edu 4.0-CURRENT FreeBSD 4.0-CURRENT #19: Thu Jun 3 13:54 :15 EDT 1999 r...@bantu.cl.msu.edu:/usr/src/sys/compile/BANTU i386 I did get splash screen to work with the default 320x200 bmp files ... The files I'm working with are from http://advocacy.freebsd.org/ammunition/splash.html Good! Thanxs for the you've done with the syscons stuff ... Kazu #;^) -- So ya want ta here da roots? Dem that feels it knows it ... bush doctor derv...@bantu.cl.msu.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: What is MTRR all about???
Quoting Daniel J. O'Connor (dar...@dons.net.au): On 04-Jun-99 bush doctor wrote: Pentium Pro MTRR support enabled, default memory type is uncacheable What is MTRR? Using the web based cross referencing tool I came up with MTRR's are a way to tell the processor how to cache regions of memory. Its commonly used to speed up video card access by disabling caching on the linear frame buffer, this makes writes to the card faster (around 0-30%). The penalty is that reading is slower, but since that doesn't happen very often the speed increase is good. Try man memcontrol - It doesn't yet work on SMP boxes though. Hmmm ... bantu.cl.msu.edu:dervish more /usr/src/usr.sbin/memcontrol/Makefile PROG= memcontrol NOMAN= yes .include bsd.prog.mk No man page yet. No horrors tho'. Man pages and info files are great, but there's nothing like reading through the sources ... #;^) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum #;^) -- So ya want ta here da roots? Dem that feels it knows it ... bush doctor derv...@bantu.cl.msu.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
What is MTRR all about???
After reading /sys/boot/README, I decided to sync up my -current boxes. I began playing around with loader, kld's and the splash screens. Now I have a few queries ... #;^)
