PHP 5.{4,5} and Suhosin
Hi list,
I was wondering if there were any plans to incorporate suhosin into PHP
5.{4,5}, or should I just forget about it and move along anyway? Lack
of suhosin is the only reason I haven't moved on from 5.3.
--
Scott McEachern
https://www.blackstaff.ca
Beware the Four Horsemen of the Information Apocalypse: terrorists, drug dealers,
kidnappers, and child pornographers. Seems like you can scare any public into allowing
the government to do anything with those four. -- Bruce Schneier
Re: PHP 5.{4,5} and Suhosin
On 10/24/13 18:43, Stuart Henderson wrote:
On 2013/10/24 18:26, Scott McEachern wrote:
I was wondering if there were any plans to incorporate suhosin into PHP
5.{4,5}, or should I just forget about it and move along anyway? Lack of
suhosin is the only reason I haven't moved on from 5.3.
If Suhosin upstream release a version for 5.4/5.5 I'd be interested in
adding it to the port but, as it is, my opinion is that you're better off
running a version that still gets security fixes..
Which, according to php.net, makes 5.3 still ok until Jul/2014:
11-Jul-2013
The PHP development team announces the immediate availability of PHP
5.3.27. About 10 bugs were fixed, including a security fix in the XML
parser (Bug #65236).
*Please Note:* This will be the last regular release of the PHP 5.3
series. All users of PHP are encouraged to upgrade to PHP 5.4 or PHP
5.5. The PHP 5.3 series will receive only security fixes for
the next year.
But general bugfixes would be nice, too, so are you suggesting moving
to, say, 5.5?
--
Scott McEachern
https://www.blackstaff.ca
Beware the Four Horsemen of the Information Apocalypse: terrorists, drug dealers,
kidnappers, and child pornographers. Seems like you can scare any public into allowing
the government to do anything with those four. -- Bruce Schneier
Re: [arc4random] devel/libevent2, mail/exim, print/cups
On 10/22/13 04:37, Jérémie Courrèges-Anglas wrote: Hi, here are patches to fix build after yesterday's arc4random_(addrandom|stir) removal. ok? Patches applied cleanly, all three ports packaged and installed (manually) just fine, allowing my dpb build to continue. -- Scott McEachern https://www.blackstaff.ca Beware the Four Horsemen of the Information Apocalypse: terrorists, drug dealers, kidnappers, and child pornographers. Seems like you can scare any public into allowing the government to do anything with those four. -- Bruce Schneier
Re: [arc4random] devel/libevent2, mail/exim, print/cups
On 10/22/13 05:47, Scott McEachern wrote: Patches applied cleanly, all three ports packaged and installed (manually) just fine, allowing my dpb build to continue. Sorry, forgot to mention: OpenBSD 5.4-current (GENERIC.MP) #0: Tue Oct 22 02:30:48 EDT 2013 sc...@elminster.blackstaff.ca:/usr/src/sys/arch/amd64/compile/GENERIC.MP -- Scott McEachern https://www.blackstaff.ca Beware the Four Horsemen of the Information Apocalypse: terrorists, drug dealers, kidnappers, and child pornographers. Seems like you can scare any public into allowing the government to do anything with those four. -- Bruce Schneier
webkit,-gtk build failure with dpb
-lwebp -lXt -licui18n -lstdc++ -ldbus-glib-1 -lgstvideo-1.0 -lgstaudio-1.0 -lgsttag-1.0 -lgstbase-1.0 -lorc-0.4 -lgstreamer-1.0 -lgcrypt -lgpg-error -lharfbuzz-icu -licuuc -licudata -lgtk-3 -latk-bridge-2.0 -latspi -lSM -ldbus-1 -lICE -lgdk-3 -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lXfixes -lpangocairo-1.0 -lpangoft2-1.0 -lharfbuzz -lgraphite2 -lpango-1.0 -latk-1.0 -lcairo-gobject -lpthread -lpixman-1 -lfontconfig -lxcb-shm -lxcb-render -lXext -lfreetype -lexpat -lpthread-stubs -lcairo -lgdk_pixbuf-2.0 -lpng -lgthread-2.0 -lsoup-2.4 -lxml2 -lsqlite3 -lgmodule-2.0 -lffi -lpcre -lz -liconv -lm -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl -lXrender -lxcb -lX11 -Wl,-rpath-link,/usr/local/lib,-rpath-link,/usr/X11R6/lib gmake[1]: *** [Programs/unittests/testapplicationcache] Error 2 gmake[1]: *** Waiting for unfinished jobs mv -f Source/WebKit2/WebProcess/WebPage/.deps/libwebkit2gtk_3_0_la-WebPage.Tpo Source/WebKit2/WebProcess/WebPage/.deps/libwebkit2gtk_3_0_la-WebPage.Plo mv -f Source/WebKit2/WebProcess/.deps/libwebkit2gtk_3_0_la-WebProcess.Tpo Source/WebKit2/WebProcess/.deps/libwebkit2gtk_3_0_la-WebProcess.Plo mv -f Source/WebKit2/WebProcess/WebPage/gtk/.deps/libwebkit2gtk_3_0_la-LayerTreeHostGtk.Tpo Source/WebKit2/WebProcess/WebPage/gtk/.deps/libwebkit2gtk_3_0_la-LayerTreeHostGtk.Plo gmake[1]: Leaving directory `/usr/ports/pobj/webkit-2.2.1-gtk3/webkitgtk-2.2.1' gmake: *** [all] Error 2 *** Error 2 in www/webkit (/usr/ports/infrastructure/mk/bsd.port.mk:2654 '/usr/ports/pobj/webkit-2.2.1-gtk3/.build_done') *** Error 1 in www/webkit (/usr/ports/infrastructure/mk/bsd.port.mk:2383 'build') === Exiting www/webkit,gtk3 with an error /bin/sh: exit 1: not found *** Error 127 in /usr/ports (infrastructure/mk/bsd.port.subdir.mk:147 'build') Error: job failed 256 Both libc.so.70.0 and 71.0 are installed: $ find /usr/lib -name libc.so.* /usr/lib/libc.so.70.0 /usr/lib/libc.so.71.0 Right now I'm doing a manual make package clean, but I suspect in a couple of hours it will crap out too. The most recent precompiled packages use webkit 2.2.0p1, not 2.2.1. Is there anything I can do to fix this? Is anyone else running into this problem? Thanks, -- Scott McEachern https://www.blackstaff.ca Beware the Four Horsemen of the Information Apocalypse: terrorists, drug dealers, kidnappers, and child pornographers. Seems like you can scare any public into allowing the government to do anything with those four. -- Bruce Schneier
Re: CVS: cvs.openbsd.org: ports
On 10/21/13 18:02, Stuart Henderson wrote: On 2013/10/21 15:26, Stuart Henderson wrote: CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2013/10/21 15:26:42 Modified files: mail/roundcubemail: Tag: OPENBSD_5_4 Makefile distinfo mail/roundcubemail/patches: Tag: OPENBSD_5_4 patch-config_main_inc_php_dist Log message: MFC Security update to Roundcube 0.9.5 We just published new releases which fix a recently reported vulnerability that allows an attacker to overwrite configuration settings using user preferences. This can result in random file access, manipulated SQL queries and even code execution. The latter one only affects versions 0.8.6 and older. 5.3 update for anyone who can test: Patches applied cleanly, port packaged and installed properly on i386 5.3-stable. -- Scott McEachern https://www.blackstaff.ca Beware the Four Horsemen of the Information Apocalypse: terrorists, drug dealers, kidnappers, and child pornographers. Seems like you can scare any public into allowing the government to do anything with those four. -- Bruce Schneier
dpb with -P ${filename} and FLAVORs
Quick question about dpb: I use dpb with secondary file using the -P switch that looks much like this: snip sysutils/firmware/radeondrm textproc/xpdf #www/chromium # PROPRIETARY www/mozilla-firefox www/xombrero /snip Is there any way to have Chromium build with the proprietary flavour from within a -P referenced file? -- Scott McEachern https://www.blackstaff.ca Beware the Four Horsemen of the Information Apocalypse: terrorists, drug dealers, kidnappers, and child pornographers. Seems like you can scare any public into allowing the government to do anything with those four. -- Bruce Schneier
Re: dpb with -P ${filename} and FLAVORs
On 10/11/13 16:46, Nigel Taylor wrote: On 10/11/13 21:08, Scott McEachern wrote: Quick question about dpb: I use dpb with secondary file using the -P switch that looks much like this: snip sysutils/firmware/radeondrm textproc/xpdf #www/chromium # PROPRIETARY www/mozilla-firefox www/xombrero /snip Is there any way to have Chromium build with the proprietary flavour from within a -P referenced file? Try www/chromium,proprietary as described in pkgpath(7) some/directory[,-sub][,flavor...] Ah, thanks. Will do on my next build. -- Scott McEachern https://www.blackstaff.ca Beware the Four Horsemen of the Information Apocalypse: terrorists, drug dealers, kidnappers, and child pornographers. Seems like you can scare any public into allowing the government to do anything with those four. -- Bruce Schneier
Re: firefox-22: missing print-to-file option?
On 08/15/13 10:11, patrick keshishian wrote: Hi, I don't have a printer configured, and I hardly ever have a need to print. However, the few times I do end up printing things, especially web content, I use ff's print-to-file option (pdf/ps output). Tonight, I had a need to take a hardcopy of an email (gmail) to a meeting, and noticed that the option to print to file is now missing in ff-22, which I built from ports after my last snapshot[1] install. Anyone know if this is/was broken in ff-22 or if the issue is entirely on my end? If the former, is there a remedy in works for future ff release and/or port? Thanks, --patrick [1] $ sysctl kern.version kern.version=OpenBSD 5.3-current (GENERIC.MP) #18: Sat Jul 6 16:54:29 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Odd, because I'm using ffx 22 as well, also built from ports, on $ sysctl kern.version kern.version=OpenBSD 5.4-beta (GENERIC.MP) #26: Thu Jul 11 15:38:31 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP and I can print to file just fine. Just tested now by viewing a page in PDF form (epdfview) without a problem. -- Scott McEachern https://www.blackstaff.ca Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin
Re: firefox-22: missing print-to-file option?
On 08/15/13 23:04, patrick keshishian wrote: I have spent some time searching on-line without success. I have seen suggestions of resetting print.print_printer and print.printer setting in about:config and restarting ff. I have tried these without success. I'm curious, for those who have success selecting print to file from ff-22 (e.g., Scott McEachern if kind enough) can you tell me what your about:config says for following setting items? print.print_printer print.printer_list Anyone else have any ideas I can/should try? Short of trying a new snapshot (I think I'll wait after the storm to clear before attempting a snapshot upgrade). Incidentally, I am not running any modern desktop environment, if that is potentially the problem of gtk2 not configuring the/any printer settings, or whatever modern desktop utility ff is depending on to select printers. Previously, with ff-18, this worked just fine. print_printer (not print.print_printer) is user set, string, and Print to File print.printer_list is default and string. No value is set. FWIW, ffx 22 was compiled using dpb on a bog-standard install with no special compile options. I have a ton of addons (noscript, adblockplus, ghostery, etc.) but none of them involve printing. I do not have a physical printer attached. I'm not running any fancy desktop either, just spectrwm, but a lot of crap is still installed because I used this box to build the packages (that I use) from the July 11th snapshot. $ pkg_info|grep gtk atk-2.8.0 accessibility toolkit used by gtk+ gdk-pixbuf-2.28.2p1 graphic library for gtk+2 gtk+2-2.24.20p1 multi-platform graphical toolkit gtk+3-3.8.2p3 multi-platform graphical toolkit gtk-update-icon-cache-2.24.20 gtk+ icon theme caching utility py-gtk2-2.24.0p1GTK+2 Python bindings Also, a new snapshot appeared today, presumably with the 64-bit time stuff. There's a t32 directory under the amd64 snaps which I've never seen before, and presumably that's a snap from before the time switch. I'm downloading the new snap (64-bit) now and will give it a whirl, but it won't be finished for at least 8h. -- Scott McEachern https://www.blackstaff.ca Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin
Re: Bug-report: Firefox crashing in recent snapshots
On 07/24/13 05:48, James Griffin wrote: The crashes i've experiebced have been only since i installed some extensions/plugins from Mozilla. I've removed them and the browser is much better again. I don't know if anyone else has noticed this. my ulimit -d is: 524288 I will increase it to to test and see if it helps. I have to say, though, i've been using FF on -current since last December and it's been pretty good. Crashes have been few and only rencently. I used to have firefox crash on a daily basis, usually when I opened too many tabs in sites like IMDb, or especially, gmail. Without fail, opening a gmail tab would crash ffx and after that it wouldn't crash right away, but became painful to use. I also run about 14 addons, including adblockplus, noscript, ghostery, requestpolicy, etc. That was with a stock data size of 512M. Then one day, a long time ago, someone else complained of ffx crashes and landry@, again, asked what happens with a data size of 2G? I tried it, and miracle of miracles, no more ffx crashes. Gmail works just fine, I could open IMDb tabs to my heart's content, plus a bunch of others. I currently have about 20 tabs open in ffx to various sites (including gmail and IMDb), plus all my addons running, and I don't remember the last time ffx crashed on me. For me, the real question is whether the default user data size shouldn't be increased in this day and age of modern (bloated, if you will) browsers. PS: Running a relatively-recent -current (Jul 11) on amd64 w/ ffx v22.0. -- Scott McEachern https://www.blackstaff.ca Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin
Re: Bug-report: Firefox crashing in recent snapshots
On 07/24/13 09:04, Landry Breuil wrote: On Wed, Jul 24, 2013 at 08:47:11AM -0400, Scott McEachern wrote: On 07/24/13 05:48, James Griffin wrote: The crashes i've experiebced have been only since i installed some extensions/plugins from Mozilla. I've removed them and the browser is much better again. I don't know if anyone else has noticed this. my ulimit -d is: 524288 I will increase it to to test and see if it helps. I have to say, though, i've been using FF on -current since last December and it's been pretty good. Crashes have been few and only rencently. I used to have firefox crash on a daily basis, usually when I opened too many tabs in sites like IMDb, or especially, gmail. Without fail, opening a gmail tab would crash ffx and after that it wouldn't crash right away, but became painful to use. I also run about 14 addons, including adblockplus, noscript, ghostery, requestpolicy, etc. That was with a stock data size of 512M. Then one day, a long time ago, someone else complained of ffx crashes and landry@, again, asked what happens with a data size of 2G? I tried it, and miracle of miracles, no more ffx crashes. Gmail works just fine, I could open IMDb tabs to my heart's content, plus a bunch of others. I currently have about 20 tabs open in ffx to various sites (including gmail and IMDb), plus all my addons running, and I don't remember the last time ffx crashed on me. For me, the real question is whether the default user data size shouldn't be increased in this day and age of modern (bloated, if you will) browsers. That point has been a long-standing discussion among developers, and a consensus hasn't been reached yet. Note that iirc, chromium wrapper automatically bumps ulimit -d at startup to workaround such issues.. Still, firefox should properly backoff in situations of constrained memory instead of exploding in flight. Landry -- Scott McEachern https://www.blackstaff.ca Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin
Re: Bug-report: Firefox crashing in recent snapshots
Sorry about the previous blank post, my mouse is dying and often double-clicks instead of single, so Send got hit instead of Edit - Undo. On 07/24/13 09:04, Landry Breuil wrote: That point has been a long-standing discussion among developers, and a consensus hasn't been reached yet. Note that iirc, chromium wrapper automatically bumps ulimit -d at startup to workaround such issues.. Still, firefox should properly backoff in situations of constrained memory instead of exploding in flight. Landry The list of things firefox should do is long. I suggest that you'll be waiting for a good long time before that situation is fixed. :) Mind you, such a wrapper (or a note as Lars suggested) sounds interesting. -- Scott McEachern https://www.blackstaff.ca Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin
Re: FHASLOCK - FIF_HASLOCK (Was: CVS: cvs.openbsd.org: src)
On 06/07/13 12:17, Philip Guenther wrote:
On Fri, 7 Jun 2013, David Coppa wrote:
This change broke sysutils/lsof.
cc -DOPENBSDV=5000 -DN_UNIXV=/bsd -DHASNFSPROTO -DHASIPv6 -DHAS9660FS=1 -DHASMSDOSFS=1
-DHASI_E2FS_PTR -DHASEXT2FS=2 -DHASEFFNLINK=i_effnlink -DHAS_DINODE_U -DHASI_FFS1
-DHAS_UM_UFS -DHASNCVPID -DUVM -DHAS_UVM_INCL -DHAS_SYS_PIPEH -DHASKVMGETPROC2
-DHASKVMGETPROCS -DHAS_STRFTIME -DLSOF_VSTR=\5.3\ -I/usr/include -I/sys -O2
-pipe -c dstore.c
dstore.c:112: error: 'FHASLOCK' undeclared here (not in a function)
*** Error 1 in /usr/ports/pobj/lsof-4.87/lsof_4.87/lsof_4.87_src (sys.mk:87
'dstore.o')
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2643
'/usr/ports/pobj/lsof-4.87/.build_done')
*** Error 1 in /usr/ports/sysutils/lsof
(/usr/ports/infrastructure/mk/bsd.port.mk:2372 'build')
Just delete the
{ (long)FHASLOCK, FF_HASLOCK },
line from dstore.c, or maybe wrap it in #if defined(FHASHLOCK) like
FMARK and FDEFER are.
Philip
I just deleted it and lsof built. Something in kde4 (qt4, I believe)
wants it, so now my make package of kde4 can continue.
BTW, excellent timing with your fix... you sent it within *minutes* of
my running into that problem.
--
Scott McEachern
https://www.blackstaff.ca
Those who would give up essential liberty to purchase a little temporary safety
deserve neither liberty nor safety. -- Benjamin Franklin
Re: CVS: cvs.openbsd.org: ports
On 06/06/13 05:44, Vadim Zhukov wrote: 06.06.2013 12:38 пользователь David Coppa dco...@gmail.com напи�ал: 2013/6/6 Vadim Zhukov z...@cvs.openbsd.org: Log message: Bugfix update to KDE 4.10.4. Tested with upcoming CMake 2.8.11. Yeah!!! Not yeah - I've run in a hurry and missed l10n bits. :( Will fix ASAP, but probably this will take a few hours due to bad connectivity here. :( Or someone with fast connection could just run make DANGEROUS=Yes makesum update-plist in x11/kde4/l10n, all tricky parts are handled by framework. Sorry. :((( Don't we have to wait for upcoming CMake 2.8.11 anyway? -- Scott McEachern https://www.blackstaff.ca Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin
Re: kdelibs-4.10.3 packaging error
On 05/17/13 01:00, David Coppa wrote: On Fri, May 17, 2013 at 12:57 AM, Scott McEachern sc...@blackstaff.ca wrote: Error: /usr/ports/pobj/kdelibs-4.10.3/fake-amd64/usr/local/lib/kde4/plugins/script/libkrossqtsplugin.so does not exist Fatal error: can't continue Monday I've fixed a problem with cmake shared lib support and some packages need to be fixed too as a consequence ciao, David Ok, thanks for the response. I'll give it a few days and watch for commits. BTW, I've since found a similar problem with devel/libgtop2. -- Scott McEachern https://www.blackstaff.ca
kdelibs-4.10.3 packaging error
Is anyone else seeing this? 1) With either the May13 snapshot or a system built from source today, (I)install a new system 2) Install the latest ports tree, updated from cvs. 3) cd /usr/ports/x11/kde4 4) make package 5) Quite a while later, observe: -- Installing: /usr/ports/pobj/kdelibs-4.10.3/fake-amd64/usr/local/man/man1/kconfig_compiler.1 -- Installing: /usr/ports/pobj/kdelibs-4.10.3/fake-amd64/usr/local/man/man1/preparetips.1 === Building package for kdelibs-4.10.3 Create /usr/ports/packages/amd64/all/kdelibs-4.10.3.tgz Error: /usr/ports/pobj/kdelibs-4.10.3/fake-amd64/usr/local/lib/kde4/plugins/script/libkrossqtsplugin.so does not exist Fatal error: can't continue at /usr/libdata/perl5/OpenBSD/PkgCreate.pm line 1386. *** Error 1 in libs (/usr/ports/infrastructure/mk/bsd.port.mk:1838 '/usr/ports/packages/amd64/all/kdelibs-4.10.3.tgz') *** Error 1 in libs (/usr/ports/infrastructure/mk/bsd.port.mk:2380 '_internal-package') *** Error 1 in libs (/usr/ports/infrastructure/mk/bsd.port.mk:2360 'package') === Exiting x11/kde4/libs with an error *** Error 1 in /usr/ports/x11/kde4 (/usr/ports/infrastructure/mk/bsd.port.subdir.mk:147 'package') Am I missing something? I've repeated this a few times today, including on 100% virgin fresh installs. -- Scott McEachern https://www.blackstaff.ca
Re: amd64 build failures 2012-11-04
On 11/05/12 11:53, Christian Weisgerber wrote: These ports failed in the latest amd64 bulk build: multimedia/mediatomb ../src/transcoding/transcoding.h:128: error: 'Dictionary' was not declared in this scope x11/py-qt3 sip/qt/qimage.sip:535: error: 'ANY' was not declared in this scope I can of course provide full logs for anybody interested in looking into this. FYI, using yesterday's snapshot (Nov. 4) on amd64, I had failures using dpb for games/wesnoth and sysutils/coreutils. Interestingly, wesnoth seems to both package and pkg_add properly when done by hand, however coreutils coughs this up: snip config output checking whether mbswidth is declared in wchar.h... no checking for mbstate_t... (cached) yes checking for mempcpy... (cached) no checking for memrchr... yes checking whether mkdir handles trailing slash... yes checking whether mkdir handles trailing dot... yes checking whether mkfifo rejects trailing slashes... yes checking whether mknod can create fifo without root privileges... configure: error: in `/usr/ports/pobj/coreutils-8.20/coreutils-8.20': configure: error: you should not run configure as root (set FORCE_UNSAFE_CONFIGURE=1 in environment to bypass this check) See `config.log' for more details *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2529 '/usr/ports/pobj/coreutils-8.20/.configure_done': @for d in /usr/ports/pobj/...) *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1764 '/usr/ports/packages/amd64/all/coreutils-8.20.tgz') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2307 '_internal-package') *** Error 1 in /usr/ports/sysutils/coreutils (/usr/ports/infrastructure/mk/bsd.port.mk:2287 'package') and setting the environment variable as suggested does not help. Any suggestions or should I wait for such things as cmake to get settled? Thanks, -- Scott McEachern https://www.blackstaff.ca
Re: libc.so.66.0 (system): bad major
On 08/27/12 16:03, Stuart Henderson wrote:
On 2012/08/27 10:31, Matthew Dempsky wrote:
On Sun, Aug 26, 2012 at 10:25 PM, Scott McEachern sc...@blackstaff.ca wrote:
=== Installing groff-1.21p8 from /usr/ports/packages/amd64/all/
Can't install groff-1.21p8 because of libraries
|library c.65.0 not found
| /usr/lib/libc.so.66.0 (system): bad major
*** Error code 1
I suspect you compiled the groff package against an older snapshot
which had libc.so.65.0. The new snapshots have libc.so.66.0 now, and
if you did a clean reinstall of base then you no longer have
libc.so.65.0.
I thought the ports tools are supposed to gracefully handle this, but
maybe not. Try deleting the groff package and rebuilding it from
source to see if that helps.
If I were guessing, I'd say there are probably either old packages lying
around in /usr/ports/packages, old build directories in WRKOBJDIR (I
forget where this points by default as I always reset it), or FETCH_PACKAGES
is set and PKG_PATH is pointed at a mirror with old packages built against
libc.so.65.0.
Yes, it was a clean install on a temp SSD drive I have. This box is
my fastest, so I use it as a build machine.
However, the mistake I made was mounting a local file server holding all
amd64 packages, including old ones, on /usr/ports/packages/amd64/all. I
guess the fresh install tried using (older) existing packages and barfed
on it, so no, it isn't handled gracefully. :)
This time, I only mounted /usr/ports/distfiles and starting building
from scratch, and it seems to be doing just fine. (It'll be just a
few hours before it finishes everything...)
FYI, dpb displays the following below the normal output during
processing. It doesn't seem to change or affect anything; as I write
this over 120 packages have been successfully built. I've seen it on a
few recent snapshots but since they weren't clean installs, I figured it
was something I broke.
print() on closed filehandle $fh at
/usr/ports/infrastructure/lib/DPB/PortBuilder.pm line 171
DPB::PortBuilder::report('DPB::PortBuilder=HASH(0x20b74ea78)',
'DPB::PkgPath=HASH(0x20b1b0100)', 'DPB::Job::Port=HASH(0x20b12c760)',
'DPB::Core::Local=HASH(0x206ae0388)') called at
/usr/ports/infrastructure/lib/DPB/PortBuilder.pm line 209
DPB::PortBuilder::__ANON__('DPB::Core::Local=HASH(0x206ae0388)') called
at /usr/ports/infrastructure/lib/DPB/Job.pm line 149
DPB::Job::Normal::finalize('DPB::Job::Port=HASH(0x20b12c760)',
'DPB::Core::Local=HASH(0x206ae0388)') called at
/usr/ports/infrastructure/lib/DPB/Job/Port.pm line 568
DPB::Job::Port::finalize('DPB::Job::Port=HASH(0x20b12c760)',
'DPB::Core::Local=HASH(0x206ae0388)') called at
/usr/ports/infrastructure/lib/DPB/Core.pm line 325
(There may be more, but my screen ends there.)
Thanks everyone,
--
Scott McEachern
https://www.blackstaff.ca
libc.so.66.0 (system): bad major
Hi, I performed a clean install of the latest snapshot (Aug 26) with the matching ports file and tried building a handful of ports via DPB. After a bunch of failures (eg. net/libproxy; x11/gnome/librsvg; lang/gcc/4.6,-c++; devel/orc; devel/libusb1) I tried building those and a few others by hand (eg. firefox; thunderbird) and got errors such as this: === Checking files for firefox-14.0.1p0 `/usr/ports/distfiles/mozilla/firefox-14.0.1.source.tar.bz2' is up to date. (SHA256) mozilla/firefox-14.0.1.source.tar.bz2: OK === firefox-14.0.1p0 depends on: unzip-* - not found === Verifying install for unzip-* in archivers/unzip Link to /usr/ports/packages/amd64/ftp/unzip-6.0p0.tgz Link to /usr/ports/packages/amd64/cdrom/unzip-6.0p0.tgz === unzip-6.0p0 depends on: groff-=1.21 - not found === Verifying install for groff-=1.21 in textproc/groff Link to /usr/ports/packages/amd64/ftp/groff-1.21p8.tgz Link to /usr/ports/packages/amd64/cdrom/groff-1.21p8.tgz === Verifying specs: c m stdc++ === found c.66.0 m.7.1 stdc++.55.0 === Installing groff-1.21p8 from /usr/ports/packages/amd64/all/ Can't install groff-1.21p8 because of libraries |library c.65.0 not found | /usr/lib/libc.so.66.0 (system): bad major *** Error code 1 Stop in /usr/ports/textproc/groff (line 1737 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 That same error regarding bad major can be found for every package I've mentioned. Am I missing something, or is something out of sync? Thanks, -- Scott McEachern https://www.blackstaff.ca
Re: torrent gui
On 11/17/11 01:50, Sha'ul wrote: I tried Transmission but that doesn't seem to have the GUI. Are you sure about that? I'll even bet their website (http://www.transmissionbt.com/) has screenshots of Mac, GTK+, Qt, web client, etc. GUI's on the front page... As for disabling files before the torrent even begins, I've never seen that. I just do it by hand after they start.
