Re: SSL_ENABLE_FALLBACK_SCSV not defined error building firefox-esr-31.5.3 Re: differences between pk_add -u and building from source at stable
I'm sorry, but you've generated so many threads over the same build error
that i dont understand anymore what you're trying to achieve, what
situation you're coming from, and what you're doing to get this error.
Is this on 5.6/i386 ? with -stable patches applied ? Trying to build a port
from the stable branch ?
SSL_ENABLE_FALLBACK_SCSV is defined in nss (see
http://mxr.mozilla.org/mozilla-central/ident?i=SSL_ENABLE_FALLBACK_SCSV) ,
so you'll have to figure out if firefox build correctly detects the version
of nss installed on your system, and if that version has this define.
On current this is what i have with nss 3.18:
/usr/local/include/nss/ssl.h:#define SSL_ENABLE_FALLBACK_SCSV 28
On plain 5.6 with nss 3.16.2., i dont have that define, so maybe esr is
subtly messing up requirements here.
At some point, if you encounter too many build issues you're not able to
deal with, you should give some trust to the people who know what they're
doing, and just use the stable packages from mtier (which, of course,
managed to build that firefox esr version afaict)
Landry
On Mon, Apr 6, 2015 at 1:40 AM, Joel Rees joel.r...@gmail.com wrote:
On Apr 4, 2015 7:26 PM, Joel Rees joel.r...@gmail.com wrote:
After about six hours
More like eight hours.
Just finished a re-compile without the room fan and got to the same
error. (No overheating, either, with one less drive.)
with a room fan aimed at the computer to keep it from overheating, I get
this error about SSL_ENABLE_FALLBACK_SCSV undefined. Most of the error
scrolled off the screen and is not in the buffer because I had a different
virtual console up monitoring the CPU temperature. Was not using tee to
capture the output because I was trying to keep the burden on the drive
controller light.
(I'm pretty sure it was the drive controller overheating rather than the
CPU. I had to move it to a different slot to get it close enough to the
case fan.)
I have this much information still on the screen:
Kept the scrollback this time:
--
[...Need to find a place to post the screen shots. ...]
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/security/manager/ssl/src/nsNSSIOLayer.cpp:
In function 'bool {anonymous}::retryDueToTLSIntolerance(PRErrorCode,
nsSSSocketInfo*)':
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/security/manager/ssl/src/nsNSSIOLayer.cpp:959:10:
error: 'SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT' was not declared in
this scope
case SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT:
^
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/security/manager/ssl/src/nsNSSIOLayer.cpp:
In function 'nsresult nsSSLIOLayerSetOptions(PRFileDesc*, bool, const
char*, const char*, int32_t, nsNSSSocketInfo*)':
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/security/manager/ssl/src/nsNSSIOLayer.cpp:2328:41:
error: 'SSL_ENABLE_FALLBACK_SCSV' was not declared in this scope
if (SECSuccess != SSL_OptionSet(fd, SSL_ENABLE_FALLBACK_SCSV,
true)) {
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/rules.mk:1001:
recipe for target 'nsNSSIOLayer.o' failed
gmake[3]: *** [nsNSSIOLayer.o] Error 1
gmake[3]: Leaving directory
'/usr/ports/pobj/firefox-esr-31.5.3/build-i386/security/manager/ssl/src'
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/recurse.mk:95:
recipe for target 'security/manager/ssl/src/compile' failed
gmake[2]: *** [security/manager/ssl/src/compile] Error 2
gmake[2]: Leaving directory
'/usr/ports/pobj/firefox-esr-31.5.3/build-i386'
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/recurse.mk:95:
recipe for target 'compile' failed
gmake[1]: [compile] Error 2
gmake[1]: Leaving directory
'/usr/ports/pobj/firefox-esr-31.5.3/build-i386'
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/recurse.mk:592:
recipe for target 'all' failed
gmake: *** [all] Error 2
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2727
'/usr/ports/pobj/firefox-esr-31.5.3/build-i386/.build_done')
*** Error 1 in /usr/ports/www/firefox-esr (/usr/ports/infrastructure/mk/
bsd.port.mk:2455 'build')
if I didn't make a mistake typing that in. I did a pwd and lost the line
about SSL_ENABLE_FALLBACK_SCSV being undefined, sorry.
Any thoughts while I muck around in that directory and go looking for
the source, after I get back from a family errand? (Maybe I'll just give up
on firefox-esr v. 31.5.3.)
On Apr 3, 2015 4:22 PM, Joel Rees joel.r...@gmail.com wrote:
On Apr 3, 2015 6:35 AM, Joel Rees joel.r...@gmail.com wrote:
[...]
Probably should grab something to monitor the temperatures, etc.,
while I try building the compiler again. Maybe use job control to suspend
the build process every five minutes or so and let things cool down. (Since
I can't afford a new motherboard right now.)
Moving keyboards and books away from the case vents helps a lot.
Temperature was holding steady at 42 C or below
Re: SSL_ENABLE_FALLBACK_SCSV not defined error building firefox-esr-31.5.3 Re: differences between pk_add -u and building from source at stable
On Mon, Apr 6, 2015 at 7:02 PM, Landry Breuil landry.bre...@gmail.com wrote:
I'm sorry, but you've generated so many threads over the same build error
that i dont understand anymore what you're trying to achieve, what situation
you're coming from, and what you're doing to get this error.
And it doesn't help that I'm confused.
I've finally convinced myself that updates to stable in packages are
really serious issues and updates in ports are things that may not be
necessary for everyone. That's one thread that just happened to get
tangled up in this one.
Hardware issues are possibly the reason for this thread, and I've sort
of solved those. I need to get heat sink brackets for the hard drive
that I unplugged. That's another thread and maybe this
Is this on 5.6/i386 ? with -stable patches applied ? Trying to build a port
from the stable branch ?
SSL_ENABLE_FALLBACK_SCSV is defined in nss (see
http://mxr.mozilla.org/mozilla-central/ident?i=SSL_ENABLE_FALLBACK_SCSV) ,
so you'll have to figure out if firefox build correctly detects the version
of nss installed on your system, and if that version has this define.
On current this is what i have with nss 3.18:
/usr/local/include/nss/ssl.h:#define SSL_ENABLE_FALLBACK_SCSV 28
On plain 5.6 with nss 3.16.2., i dont have that define, so maybe esr is
subtly messing up requirements here.
At some point, if you encounter too many build issues you're not able to
deal with, you should give some trust to the people who know what they're
doing, and just use the stable packages from mtier (which, of course,
managed to build that firefox esr version afaict)
Landry
On Mon, Apr 6, 2015 at 1:40 AM, Joel Rees joel.r...@gmail.com wrote:
On Apr 4, 2015 7:26 PM, Joel Rees joel.r...@gmail.com wrote:
After about six hours
More like eight hours.
Just finished a re-compile without the room fan and got to the same
error. (No overheating, either, with one less drive.)
with a room fan aimed at the computer to keep it from overheating, I get
this error about SSL_ENABLE_FALLBACK_SCSV undefined. Most of the error
scrolled off the screen and is not in the buffer because I had a different
virtual console up monitoring the CPU temperature. Was not using tee to
capture the output because I was trying to keep the burden on the drive
controller light.
(I'm pretty sure it was the drive controller overheating rather than the
CPU. I had to move it to a different slot to get it close enough to the
case
fan.)
I have this much information still on the screen:
Kept the scrollback this time:
--
[...Need to find a place to post the screen shots. ...]
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/security/manager/ssl/src/nsNSSIOLayer.cpp:
In function 'bool {anonymous}::retryDueToTLSIntolerance(PRErrorCode,
nsSSSocketInfo*)':
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/security/manager/ssl/src/nsNSSIOLayer.cpp:959:10:
error: 'SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT' was not declared in
this scope
case SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT:
^
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/security/manager/ssl/src/nsNSSIOLayer.cpp:
In function 'nsresult nsSSLIOLayerSetOptions(PRFileDesc*, bool, const
char*, const char*, int32_t, nsNSSSocketInfo*)':
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/security/manager/ssl/src/nsNSSIOLayer.cpp:2328:41:
error: 'SSL_ENABLE_FALLBACK_SCSV' was not declared in this scope
if (SECSuccess != SSL_OptionSet(fd, SSL_ENABLE_FALLBACK_SCSV,
true)) {
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/rules.mk:1001:
recipe for target 'nsNSSIOLayer.o' failed
gmake[3]: *** [nsNSSIOLayer.o] Error 1
gmake[3]: Leaving directory
'/usr/ports/pobj/firefox-esr-31.5.3/build-i386/security/manager/ssl/src'
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/recurse.mk:95:
recipe for target 'security/manager/ssl/src/compile' failed
gmake[2]: *** [security/manager/ssl/src/compile] Error 2
gmake[2]: Leaving directory
'/usr/ports/pobj/firefox-esr-31.5.3/build-i386'
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/recurse.mk:95:
recipe for target 'compile' failed
gmake[1]: [compile] Error 2
gmake[1]: Leaving directory
'/usr/ports/pobj/firefox-esr-31.5.3/build-i386'
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/recurse.mk:592:
recipe for target 'all' failed
gmake: *** [all] Error 2
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2727
'/usr/ports/pobj/firefox-esr-31.5.3/build-i386/.build_done')
*** Error 1 in /usr/ports/www/firefox-esr
(/usr/ports/infrastructure/mk/bsd.port.mk:2455 'build')
if I didn't make a mistake typing that in. I did a pwd and lost the line
about SSL_ENABLE_FALLBACK_SCSV being undefined, sorry.
Any thoughts while I muck around in that directory and go looking for
the source, after I get back from a family errand? (Maybe I'll just
Re: differences between pk_add -u and building from source at stable
On 4/5/2015 3:45 PM, Theo de Raadt wrote: Indeed. Kind of amusing. Entirely possible a mtier person commits to the port John is worried about. Like all of us they are volunteers... So John, who will you trust? And why will you trust them, or not trust them? In fact, taken far enough... why trust me? Much of the trust imparted in us is probably for two reasons: 1. the software is cheap 2. perception of our software management practices relative to other's software management practices John, if you are paranoid, don't trust anyone... You know, these are ports. You trust all the upstreams? You're right. I don't like the amount of trust involved in modern computing. It made me uneasy before any of the recent revelations occurred. Now it's even worse. It's not something I obsess about but I just don't like it. Is it a bit silly? Yeah, probably, especially since I'm probably the most boring target ever with regards to being surveilled or whatever. But, at least in the country I'm in, you can't walk out your door without breaking at least a few laws. So I come back around to yeah, I probably should take some precautions and think about these things at least some. You're right, I have to trust someone to use modern computer hardware and operating systems. My strategy is to trust as few people as possible. I trust you and the other OpenBSD developers because of your stated principles and track record. Yeah, the price is right too. I trust payware less than free/open source software because I have to completely trust the software provider with payware whereas free/open source has at least some review by others. I haven't been able to contribute monetarily yet except buying a LibreSSL shirt. I hope to be able to change that soon and start contributing on a regular basis. So while the price is right more from a perspective of free/open vs payware it isn't so much about the money (which I truly do want to start gladly giving whenever I am able to which should be soon). With regards to mtier specifically, I didn't see a mention of it anywhere on openbsd.org. So my initial reaction was thanks but no thanks. If it really is considered trustworthy by core OpenBSD developers then maybe I'll take another look. -- John Merriam
Re: SSL_ENABLE_FALLBACK_SCSV not defined error building firefox-esr-31.5.3 Re: differences between pk_add -u and building from source at stable
On Apr 4, 2015 7:26 PM, Joel Rees joel.r...@gmail.com wrote:
After about six hours
More like eight hours.
Just finished a re-compile without the room fan and got to the same
error. (No overheating, either, with one less drive.)
with a room fan aimed at the computer to keep it from overheating, I get this
error about SSL_ENABLE_FALLBACK_SCSV undefined. Most of the error scrolled
off the screen and is not in the buffer because I had a different virtual
console up monitoring the CPU temperature. Was not using tee to capture the
output because I was trying to keep the burden on the drive controller light.
(I'm pretty sure it was the drive controller overheating rather than the CPU.
I had to move it to a different slot to get it close enough to the case fan.)
I have this much information still on the screen:
Kept the scrollback this time:
--
[...Need to find a place to post the screen shots. ...]
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/security/manager/ssl/src/nsNSSIOLayer.cpp:
In function 'bool {anonymous}::retryDueToTLSIntolerance(PRErrorCode,
nsSSSocketInfo*)':
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/security/manager/ssl/src/nsNSSIOLayer.cpp:959:10:
error: 'SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT' was not declared in
this scope
case SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT:
^
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/security/manager/ssl/src/nsNSSIOLayer.cpp:
In function 'nsresult nsSSLIOLayerSetOptions(PRFileDesc*, bool, const
char*, const char*, int32_t, nsNSSSocketInfo*)':
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/security/manager/ssl/src/nsNSSIOLayer.cpp:2328:41:
error: 'SSL_ENABLE_FALLBACK_SCSV' was not declared in this scope
if (SECSuccess != SSL_OptionSet(fd, SSL_ENABLE_FALLBACK_SCSV, true)) {
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/rules.mk:1001: recipe
for target 'nsNSSIOLayer.o' failed
gmake[3]: *** [nsNSSIOLayer.o] Error 1
gmake[3]: Leaving directory
'/usr/ports/pobj/firefox-esr-31.5.3/build-i386/security/manager/ssl/src'
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/recurse.mk:95: recipe
for target 'security/manager/ssl/src/compile' failed
gmake[2]: *** [security/manager/ssl/src/compile] Error 2
gmake[2]: Leaving directory '/usr/ports/pobj/firefox-esr-31.5.3/build-i386'
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/recurse.mk:95: recipe
for target 'compile' failed
gmake[1]: [compile] Error 2
gmake[1]: Leaving directory '/usr/ports/pobj/firefox-esr-31.5.3/build-i386'
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/recurse.mk:592:
recipe for target 'all' failed
gmake: *** [all] Error 2
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2727
'/usr/ports/pobj/firefox-esr-31.5.3/build-i386/.build_done')
*** Error 1 in /usr/ports/www/firefox-esr
(/usr/ports/infrastructure/mk/bsd.port.mk:2455 'build')
if I didn't make a mistake typing that in. I did a pwd and lost the line
about SSL_ENABLE_FALLBACK_SCSV being undefined, sorry.
Any thoughts while I muck around in that directory and go looking for the
source, after I get back from a family errand? (Maybe I'll just give up on
firefox-esr v. 31.5.3.)
On Apr 3, 2015 4:22 PM, Joel Rees joel.r...@gmail.com wrote:
On Apr 3, 2015 6:35 AM, Joel Rees joel.r...@gmail.com wrote:
[...]
Probably should grab something to monitor the temperatures, etc., while I
try building the compiler again. Maybe use job control to suspend the
build process every five minutes or so and let things cool down. (Since I
can't afford a new motherboard right now.)
Moving keyboards and books away from the case vents helps a lot.
Temperature was holding steady at 42 C or below with the vents clear until
about insn_emit or so. In the insn_* stuff, I'm getting 43 with the vents
uncovered.
With the vents uncovered, I made it through compiling gcc 4.8.3 in about
five hours without suddenly resetting. (12+ year old 32 bit sempron 2600+.
Did I set the temperature limit down in the BIOS?)
heh.
firefox 31.5.3 is now compiling. It recognizes gcc 4.8.3 built here, where
the same added with pkg_add -u was apparently not seen by the make process
for firefox.
Joel Rees
Computer memory is just fancy paper,
CPUs just fancy pens.
All is a stream of text
flowing from the past into the future.
Re: SSL_ENABLE_FALLBACK_SCSV not defined error building firefox-esr-31.5.3 Re: differences between pk_add -u and building from source at stable
dmesg below, since it occurs to me that my questions are heading that direction.
I'll note that the documentation for the ITExpress controller
recommends, when using only two drives, setting both to master on
separate channels. Openbsd doesn't boot that way, so I had both the
drives on the ITExpress on a single channel, master/slave.
I've unplugged the western digital drive, and the system is much more
stable. I haven't tried starting a new build of firefox that way yet.
Should I post a dmesg without the WDC drive?
On Sat, Apr 4, 2015 at 7:26 PM, Joel Rees joel.r...@gmail.com wrote:
After about six hours with a room fan aimed at the computer to keep it from
overheating, I get this error about SSL_ENABLE_FALLBACK_SCSV undefined. Most
of the error scrolled off the screen and is not in the buffer because I had
a different virtual console up monitoring the CPU temperature. Was not
using tee to capture the output because I was trying to keep the burden on
the drive controller light.
(I'm pretty sure it was the drive controller overheating rather than the
CPU. I had to move it to a different slot to get it close enough to the case
fan.)
I have this much information still on the screen:
--
if (SECSuccess != SSL_OptionSet(fd, SSL_ENABLE_FALLBACK_SCSV, true))
{
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/rules.mk:1001:
recipe for target 'nsNSSIOLayer.o' failed
gmake[3]: *** [nsNSSIOLayer.o] Error 1
gmake[3]: Leaving directory
'/usr/ports/pobj/firefox-esr-31.5.3/build-i386/security/manager/ssl/src'
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/recurse.mk:95:
recipe for target 'security/manager/ssl/src/compile' failed
gmake[2]: *** [security/manager/ssl/src/compile] Error 2
gmake[2]: Leaving directory '/usr/ports/pobj/firefox-esr-31.5.3/build-i386'
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/recurse.mk:95:
recipe for target 'compile' failed
gmake[1]: [compile] Error 2
gmake[1]: Leaving directory '/usr/ports/pobj/firefox-esr-31.5.3/build-i386'
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/recurse.mk:592:
recipe for target 'all' failed
gmake: *** [all] Error 2
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2727
'/usr/ports/pobj/firefox-esr-31.5.3/build-i386/.build_done')
*** Error 1 in /usr/ports/www/firefox-esr
(/usr/ports/infrastructure/mk/bsd.port.mk:2455 'build')
if I didn't make a mistake typing that in. I did a pwd and lost the line
about SSL_ENABLE_FALLBACK_SCSV being undefined, sorry.
Any thoughts while I muck around in that directory and go looking for the
source, after I get back from a family errand? (Maybe I'll just give up on
firefox-esr v. 31.5.3.)
On Apr 3, 2015 4:22 PM, Joel Rees joel.r...@gmail.com wrote:
On Apr 3, 2015 6:35 AM, Joel Rees joel.r...@gmail.com wrote:
[...]
Probably should grab something to monitor the temperatures, etc., while
I try building the compiler again. Maybe use job control to suspend the
build process every five minutes or so and let things cool down. (Since I
can't afford a new motherboard right now.)
Moving keyboards and books away from the case vents helps a lot.
Temperature was holding steady at 42 C or below with the vents clear until
about insn_emit or so. In the insn_* stuff, I'm getting 43 with the vents
uncovered.
With the vents uncovered, I made it through compiling gcc 4.8.3 in about
five hours without suddenly resetting. (12+ year old 32 bit sempron 2600+.
Did I set the temperature limit down in the BIOS?)
heh.
firefox 31.5.3 is now compiling. It recognizes gcc 4.8.3 built here, where
the same added with pkg_add -u was apparently not seen by the make process
for firefox.
Joel Rees
Computer memory is just fancy paper,
CPUs just fancy pens.
All is a stream of text
flowing from the past into the future.
OpenBSD 5.6-stable (GENERIC) #0: Wed Apr 1 22:30:31 JST 2015
r...@ob.reiisi.homedns.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Sempron(tm) 2600+ (AuthenticAMD 686-class, 256KB L2 cache) 1.84 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,MPC,MMXX,3DNOW2,3DNOW
real mem = 737636352 (703MB)
avail mem = 713138176 (680MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 07/28/04, BIOS32 rev. 0 @
0xfbaa0, SMBIOS rev. 2.3 @ 0xf0800 (33 entries)
bios0: vendor Phoenix Technologies, LTD version 6.00 PG date 07/28/2004
bios0: MICRO-STAR INTERNATIONAL CO., LTD KM266-8237
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC
acpi0: wakeup devices SLPB(S5) USB0(S1) USB1(S1) USB2(S1) USB3(S1)
USB4(S1) USB5(S1) USB6(S1) USB7(S1) LAN0(S5) UAR1(S5) LPT1(S5)
ECP1(S5) PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr:
Re: differences between pk_add -u and building from source at stable
On Thu, Apr 02, 2015 at 09:38:21AM -0400, John Merriam wrote: On Thu, 2 Apr 2015, Kevin Chadwick wrote: On Wed, 01 Apr 2015 22:34:06 -0400 John Merriam wrote: I don't mind using ports instead of packages myself. But, I haven't tried OpenBSD on the desktop yet (routers/firewalls and servers so far). Compiling huge stuff that updates often like Firefox could be kind of a pain I would guess. Have you checked out mtier.org's stable packages support? Yes, I have. It sounds nice. I'm a bit to paranoid though so I don't want to trust that additional layer/entity that I would have to in order to use their stuff. Considering some of mtier's employees, you're already trusting their work with official openbsd packages.
Re: differences between pk_add -u and building from source at stable
On Thu, Apr 02, 2015 at 09:38:21AM -0400, John Merriam wrote: On Thu, 2 Apr 2015, Kevin Chadwick wrote: On Wed, 01 Apr 2015 22:34:06 -0400 John Merriam wrote: I don't mind using ports instead of packages myself. But, I haven't tried OpenBSD on the desktop yet (routers/firewalls and servers so far). Compiling huge stuff that updates often like Firefox could be kind of a pain I would guess. Have you checked out mtier.org's stable packages support? Yes, I have. It sounds nice. I'm a bit to paranoid though so I don't want to trust that additional layer/entity that I would have to in order to use their stuff. Considering some of mtier's employees, you're already trusting their work with official openbsd packages. Indeed. Kind of amusing. Entirely possible a mtier person commits to the port John is worried about. Like all of us they are volunteers... So John, who will you trust? And why will you trust them, or not trust them? In fact, taken far enough... why trust me? Much of the trust imparted in us is probably for two reasons: 1. the software is cheap 2. perception of our software management practices relative to other's software management practices John, if you are paranoid, don't trust anyone... You know, these are ports. You trust all the upstreams?
SSL_ENABLE_FALLBACK_SCSV not defined error building firefox-esr-31.5.3 Re: differences between pk_add -u and building from source at stable
After about six hours with a room fan aimed at the computer to keep it from
overheating, I get this error about SSL_ENABLE_FALLBACK_SCSV undefined.
Most of the error scrolled off the screen and is not in the buffer because
I had a different virtual console up monitoring the CPU temperature. Was
not using tee to capture the output because I was trying to keep the burden
on the drive controller light.
(I'm pretty sure it was the drive controller overheating rather than the
CPU. I had to move it to a different slot to get it close enough to the
case fan.)
I have this much information still on the screen:
--
if (SECSuccess != SSL_OptionSet(fd, SSL_ENABLE_FALLBACK_SCSV,
true)) {
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/rules.mk:1001:
recipe for target 'nsNSSIOLayer.o' failed
gmake[3]: *** [nsNSSIOLayer.o] Error 1
gmake[3]: Leaving directory
'/usr/ports/pobj/firefox-esr-31.5.3/build-i386/security/manager/ssl/src'
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/recurse.mk:95:
recipe for target 'security/manager/ssl/src/compile' failed
gmake[2]: *** [security/manager/ssl/src/compile] Error 2
gmake[2]: Leaving directory '/usr/ports/pobj/firefox-esr-31.5.3/build-i386'
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/recurse.mk:95:
recipe for target 'compile' failed
gmake[1]: [compile] Error 2
gmake[1]: Leaving directory '/usr/ports/pobj/firefox-esr-31.5.3/build-i386'
/usr/ports/pobj/firefox-esr-31.5.3/mozilla-esr31/config/recurse.mk:592:
recipe for target 'all' failed
gmake: *** [all] Error 2
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2727
'/usr/ports/pobj/firefox-esr-31.5.3/build-i386/.build_done')
*** Error 1 in /usr/ports/www/firefox-esr (/usr/ports/infrastructure/mk/
bsd.port.mk:2455 'build')
if I didn't make a mistake typing that in. I did a pwd and lost the line
about SSL_ENABLE_FALLBACK_SCSV being undefined, sorry.
Any thoughts while I muck around in that directory and go looking for the
source, after I get back from a family errand? (Maybe I'll just give up on
firefox-esr v. 31.5.3.)
On Apr 3, 2015 4:22 PM, Joel Rees joel.r...@gmail.com wrote:
On Apr 3, 2015 6:35 AM, Joel Rees joel.r...@gmail.com wrote:
[...]
Probably should grab something to monitor the temperatures, etc., while
I try building the compiler again. Maybe use job control to suspend the
build process every five minutes or so and let things cool down. (Since I
can't afford a new motherboard right now.)
Moving keyboards and books away from the case vents helps a lot.
Temperature was holding steady at 42 C or below with the vents clear
until about insn_emit or so. In the insn_* stuff, I'm getting 43 with the
vents uncovered.
With the vents uncovered, I made it through compiling gcc 4.8.3 in about
five hours without suddenly resetting. (12+ year old 32 bit sempron 2600+.
Did I set the temperature limit down in the BIOS?)
heh.
firefox 31.5.3 is now compiling. It recognizes gcc 4.8.3 built here,
where the same added with pkg_add -u was apparently not seen by the make
process for firefox.
Joel Rees
Computer memory is just fancy paper,
CPUs just fancy pens.
All is a stream of text
flowing from the past into the future.
Re: differences between pk_add -u and building from source at stable
On Apr 3, 2015 6:35 AM, Joel Rees joel.r...@gmail.com wrote: [...] Probably should grab something to monitor the temperatures, etc., while I try building the compiler again. Maybe use job control to suspend the build process every five minutes or so and let things cool down. (Since I can't afford a new motherboard right now.) Moving keyboards and books away from the case vents helps a lot. Temperature was holding steady at 42 C or below with the vents clear until about insn_emit or so. In the insn_* stuff, I'm getting 43 with the vents uncovered. With the vents uncovered, I made it through compiling gcc 4.8.3 in about five hours without suddenly resetting. (12+ year old 32 bit sempron 2600+. Did I set the temperature limit down in the BIOS?) heh. firefox 31.5.3 is now compiling. It recognizes gcc 4.8.3 built here, where the same added with pkg_add -u was apparently not seen by the make process for firefox. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: differences between pk_add -u and building from source at stable
On Wed, Apr 01, 2015 at 11:48:16PM -0400, dan mclaughlin wrote: if you want the version that the port build will produce do: $ (cd /usr/ports/lang/gcc/4.8/ make _print-packagename) gcc-4.8.4p2 there are alot of options for make that are in bsd.port.mk(5) (although the one i used above is technically an internal make command). you also might have better luck asking these questions on ports@ in the future. Bad puppy. Technically what you're looking for is make show=PKGNAMES which will give you everything in a clean, unchanging way... (especially since ffx is likely to want C++ on top of C. You don't even have to change directory... nausicaa$ SUBDIR=lang/gcc/4.8 make show=PKGNAMES === lang/gcc/4.8 gcc-4.8.4p2 g95-4.8.4p1 gobjc-4.8.4p1 g++-4.8.4p1 libstdc++-4.8.4p1 gcj-4.8.4p1 gnat-4.8.4p1
Re: differences between pk_add -u and building from source at stable
Thanks for the comments. I've been re-reading faq 15 and related stuff, and realized that I thought I had figured this out before. My memory is not improving with age. This is how I re-understand it now: pkg_add -u is for getting packages with issues that are severe enough to motivate one of the developers to put a package together for. For less severe issues, we have to take the time and effort to rebuild the packages ourselves, according to our own priorities, setups, etc. Does that sound right? I had thought my ports tree was messed up, and it probably was, but something in the hardware seems to be breaking. Even with the ports tree on the other drive, rebuilding firefox results in a hardware reset with nothing in the logs to indicate why. Probably should grab something to monitor the temperatures, etc., while I try building the compiler again. Maybe use job control to suspend the build process every five minutes or so and let things cool down. (Since I can't afford a new motherboard right now.) Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: differences between pk_add -u and building from source at stable
On Thu, 2 Apr 2015 11:50:12 +0200 Marc Espie es...@nerim.net wrote: On Wed, Apr 01, 2015 at 11:48:16PM -0400, dan mclaughlin wrote: if you want the version that the port build will produce do: $ (cd /usr/ports/lang/gcc/4.8/ make _print-packagename) gcc-4.8.4p2 there are alot of options for make that are in bsd.port.mk(5) (although the one i used above is technically an internal make command). you also might have better luck asking these questions on ports@ in the future. Bad puppy. Technically what you're looking for is make show=PKGNAMES good to know. i stumbled across that when i was trying to figure that out before, and sometimes it's easier to read code than documentation. i was interestingly enough just now updating those scripts anyway (like literally opened it up right before i got this, for reasons unrelated to this thread...) which will give you everything in a clean, unchanging way... well i may not have been clear enough on that point, but i thought it was implied that since it was internal it was not documented, and thus ... (especially since ffx is likely to want C++ on top of C. this may have something to do with his original problem. You don't even have to change directory... nausicaa$ SUBDIR=lang/gcc/4.8 make show=PKGNAMES === lang/gcc/4.8 gcc-4.8.4p2 g95-4.8.4p1 gobjc-4.8.4p1 g++-4.8.4p1 libstdc++-4.8.4p1 gcj-4.8.4p1 gnat-4.8.4p1 but you still have to be in /usr/ports. personally i am used to the '(cd ...)' construct myself for other things so it is easier for me. but i understand your meaning, you're just expounding upon the subtleties of the system.
Re: differences between pk_add -u and building from source at stable
On Wed, 01 Apr 2015 22:34:06 -0400 John Merriam wrote: I don't mind using ports instead of packages myself. But, I haven't tried OpenBSD on the desktop yet (routers/firewalls and servers so far). Compiling huge stuff that updates often like Firefox could be kind of a pain I would guess. Have you checked out mtier.org's stable packages support?
Re: differences between pk_add -u and building from source at stable
On Thu, 2 Apr 2015, Kevin Chadwick wrote: On Wed, 01 Apr 2015 22:34:06 -0400 John Merriam wrote: I don't mind using ports instead of packages myself. But, I haven't tried OpenBSD on the desktop yet (routers/firewalls and servers so far). Compiling huge stuff that updates often like Firefox could be kind of a pain I would guess. Have you checked out mtier.org's stable packages support? Yes, I have. It sounds nice. I'm a bit to paranoid though so I don't want to trust that additional layer/entity that I would have to in order to use their stuff. -- John Merriam
Re: differences between pk_add -u and building from source at stable
On 4/1/2015 4:16 PM, Joel Rees wrote: Should there be a difference if I haven't botched the source tree for /usr/ports at some point? firefox --version tells me Mozilla Firefox 31.0 (It also gives a warning about size mismatch in a couple of c++ libraries and says I should relink the program, which is part of the message it sends to the console every time I run it. I'vd been ignoring that message.) And pkg_add -u firefox just talks to itself, then says quirks-2.9 signed on 2014-08-02T11:06:132 but cd /usr/ports/www/firefox-esr make -n tells me lock=firefox-esr-31.5.3 Hello. I had similar issues figuring this out when I started using OpenBSD again recently. If you are running -stable, the packages available from pkg_add are -release packages. From what others have said, the -release packages usually do not receive updates. To use -stable packages (which do receive updates via CVS), you must use ports and compile them from the ports tree. Obviously this is subject to change at any time but as far as I know that is still the situation. I don't mind using ports instead of packages myself. But, I haven't tried OpenBSD on the desktop yet (routers/firewalls and servers so far). Compiling huge stuff that updates often like Firefox could be kind of a pain I would guess. -- John Merriam
Re: differences between pk_add -u and building from source at stable
On Thu, 2 Apr 2015 05:16:25 +0900 Joel Rees joel.r...@gmail.com wrote: Should there be a difference if I haven't botched the source tree for /usr/ports at some point? firefox --version tells me Mozilla Firefox 31.0 (It also gives a warning about size mismatch in a couple of c++ libraries and says I should relink the program, which is part of the message it sends to the console every time I run it. I'vd been ignoring that message.) And pkg_add -u firefox just talks to itself, then says quirks-2.9 signed on 2014-08-02T11:06:132 but cd /usr/ports/www/firefox-esr make -n tells me lock=firefox-esr-31.5.3 Without the -n, it would try to install firefox 31.5.3, but break on lack of disk space for installing gcc 4.8.3. I installed gcc-4.8.3 from packages, but the make process didn't see that, and still tried to install it again. (gcc --version from the command line says 4.2.1.) for the package you need to check the patch version as well. whenever there is a change in the patches that the ports build system applies, it changes. if you want the version that the port build will produce do: $ (cd /usr/ports/lang/gcc/4.8/ make _print-packagename) gcc-4.8.4p2 if you have gcc-4.8.4p1 that is considered a different package version. to get the installed one: $ pkg_info -I gcc gcc-4.8.4p2 GNU compiler collection: core C compiler there are alot of options for make that are in bsd.port.mk(5) (although the one i used above is technically an internal make command). you also might have better luck asking these questions on ports@ in the future. I've grabbed some space on another disk, changed /etc/fstab to mount those partitions and rebuilt src and xenocara in nice roomy partitions there. (Man, putting the src tree on a separate disk sure speeds cvs updates and builds up like crazy!) /usr/ports is just sitting there after a cvs up to stable (-rOPENBSD_5_6). And I'm hesitating before building firefox from source again. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
