Re: LibreOffice trouble
On Wed, 29 Jul 2015 04:58:42 +0300 Vadim Zhukov wrote: > 2015-07-29 2:48 GMT+03:00 Ed Ahlsen-Girard : > > Starting LibreOffice (from snapshots) with no arguments fails with > > this error: > > > > LibreOffice 4.4 - Fatal Error > > > > The application cannot be started. > > User installation could not be completed. > > > > dmesg below. > > > > -- > > > > Edward Ahlsen-Girard > > Ft Walton Beach, FL > > > > OpenBSD 5.8 (GENERIC.MP) #1193: Fri Jul 24 12:17:54 MDT 2015 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 2094530560 (1997MB) > > avail mem = 2027216896 (1933MB) > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf06d0 (43 entries) > > bios0: vendor American Megatrends Inc. version "0504" date > > 10/05/2009 bios0: ASUSTeK Computer INC. P-P5G41 > > acpi0 at bios0: rev 2 > > acpi0: sleep states S0 S1 S3 S4 S5 > > acpi0: tables DSDT FACP APIC MCFG OEMB HPET GSCI SSDT > > acpi0: wakeup devices P0P2(S4) P0P3(S4) P0P1(S4) UAR1(S4) PS2K(S4) > > PS2M(S4) USB0(S4) USB1(S4) USB2(S4) USB3(S4) EUSB(S4) MC97(S4) > > P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) [...] acpitimer0 at acpi0: > > 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT > > compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) > > Core(TM)2 Duo CPU E7500 @ 2.93GHz, 2933.67 MHz cpu0: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR > > cpu0: 3MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 > > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > > cpu0: apic clock running at 271MHz > > cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE > > cpu1 at mainbus0: apid 1 (application processor) > > cpu1: Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz, 2991.97 MHz > > cpu1: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR > > cpu1: 3MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 > > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins > > acpimcfg0 at acpi0 addr 0xf000, bus 0-63 > > acpihpet0 at acpi0: 14318179 Hz > > acpiprt0 at acpi0: bus 0 (PCI0) > > acpiprt1 at acpi0: bus -1 (P0P2) > > acpiprt2 at acpi0: bus -1 (P0P3) > > acpiprt3 at acpi0: bus 3 (P0P4) > > acpiprt4 at acpi0: bus -1 (P0P5) > > acpiprt5 at acpi0: bus 2 (P0P6) > > acpiprt6 at acpi0: bus 1 (P0P7) > > acpicpu0 at acpi0: !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS > > acpicpu1 at acpi0: !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS > > aibs0 at acpi0 RTMP RVLT RFAN GGRP GITM SITM > > aibs0: FSIF: invalid package > > acpibtn0 at acpi0: PWRB > > cpu0: Enhanced SpeedStep 2933 MHz: speeds: 2936, 2670, 2403, 2136, > > 1870, 1603 MHz pci0 at mainbus0 bus 0 > > pchb0 at pci0 dev 0 function 0 "Intel G41 Host" rev 0x03 > > vga1 at pci0 dev 2 function 0 "Intel G41 Video" rev 0x03 > > intagp0 at vga1 > > agp0 at intagp0: aperture at 0xe000, size 0x1000 > > inteldrm0 at vga1 > > drm0 at inteldrm0 > > inteldrm0: 1920x1080 > > wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) > > wsdisplay0: screen 1-5 added (std, vt100 emulation) > > "Intel G41 Video" rev 0x03 at pci0 dev 2 function 1 not configured > > azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev > > 0x01: msi azalia0: codecs: Realtek ALC888 > > audio0 at azalia0 > > ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: msi > > pci1 at ppb0 bus 3 > > xhci0 at pci1 dev 0 function 0 vendor "Fresco Logic", unknown > > product 0x1100 rev 0x01: msi usb0 at xhci0: USB revision 3.0 > > uhub0 at usb0 "Fresco Logic xHCI root hub" rev 3.00/1.00 addr 1 > > ppb1 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x01: msi > > pci2 at ppb1 bus 2 > > re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x02: > > RTL8168C/8111C (0x3c00), msi, address 48:5b:39:c5:63:95 rgephy0 at > > re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 2 ppb2 at pci0 dev 28 > > function 3 "Intel 82801GB PCIE" rev 0x01: msi pci3 at ppb2 bus 1 > > vendor "VIA", unknown product 0x3401 (class serial bus subclass > > Firewire, rev 0x00) at pci3 dev 0 function 0 not configured vendor > > "VIA", unknown product 0x401a (class mass storage subclass > > miscellaneous, rev 0x00) at pci3 dev 0 function 1 not configured > > sdhc0 at pci3 dev 0 function 2 vendor "VIA", unknown product 0x401b > > rev 0x00: apic 2 int 19 sdhc0 at 0x10: can't map registers uhci0 at > > pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 2 int 23 > > uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic > > 2 int 19 uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev > > 0x01: apic 2 int 18 uhci3 at pci0 dev 29 function 3 "Intel 82801GB > > USB" rev 0x01: a
Re: [tobi...@tmux.org: mark net/rtorrent as broken on powerpc]
Il 31/lug/2015 21:17, "Landry Breuil" ha scritto: > > On Fri, Jul 31, 2015 at 06:51:19PM +0200, Martin Pieuchot wrote: > > On 31/07/15(Fri) 15:31, Stuart Henderson wrote: > > > On 2015/07/31 15:53, Tobias Ulmer wrote: > > > > Is David around? Any objections should be voiced in the next few hours, > > > > before I commit this. > > > > > > It's actually libtorrent not rtorrent that should be marked broken. > > > > > > Would it be worth building on i386 with compiler flags to fix that, > > > at the expense of not running on crappy old machines that you probably > > > wouldn't want to run this on anyway? > > > > There's only one atomic operation on a 64bit value and it is just for > > instrumentation. So by adding "--disable-instrumentation" to the > > configure arguments libtorrent builds just fine on macppc. I did not > > try i386 but it should be the same. > > latest rtorrent builds and runs here on macppc with this diff, ok for me. Ok with me too. Martin, please go ahead Thanks! David
Re: Fix: games/sudoku-solver
On 2015-07-31, Tobias Ulmer wrote: > But... why not delete the whole thing? It's from mbalmer@, he's not > using it any more (at the very least not on OpenBSD) and he even pulled I checked NetBSD pkgsrc hoping I might find a new master site, but he hasn't imported any of his old OpenBSD ports there. > his own website and any traces of the source. Why keep it? It's a nice > programming exercise, but I doubt anyone uses it. Well, that's the problem. We don't know who uses which ports. I suspect all the old mbalmer ports are cruft that we could remove (after the release), although that might be mistaken as vindicative. > Oh, and the compiler warning messages don't exactly inspire strict > alignment readyness. I only looked briefly. The 64-bit warnings are harmless. That's the common practice of using a pointer to pass data to callbacks and if the data is just an int, people directly cast it into the pointer. It's widely used with Motif and some other X11 stuff. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [tobi...@tmux.org: mark net/rtorrent as broken on powerpc]
On Fri, Jul 31, 2015 at 06:51:19PM +0200, Martin Pieuchot wrote: > On 31/07/15(Fri) 15:31, Stuart Henderson wrote: > > On 2015/07/31 15:53, Tobias Ulmer wrote: > > > Is David around? Any objections should be voiced in the next few hours, > > > before I commit this. > > > > It's actually libtorrent not rtorrent that should be marked broken. > > > > Would it be worth building on i386 with compiler flags to fix that, > > at the expense of not running on crappy old machines that you probably > > wouldn't want to run this on anyway? > > There's only one atomic operation on a 64bit value and it is just for > instrumentation. So by adding "--disable-instrumentation" to the > configure arguments libtorrent builds just fine on macppc. I did not > try i386 but it should be the same. latest rtorrent builds and runs here on macppc with this diff, ok for me.
Re: [tobi...@tmux.org: mark net/rtorrent as broken on powerpc]
Hello Martin, > There's only one atomic operation on a 64bit value and it is just for > instrumentation. So by adding "--disable-instrumentation" to the > configure arguments libtorrent builds just fine on macppc. I did not > try i386 but it should be the same. Works fine on i386 for me. Thank you, Jan
Re: duplicity backup to hubic - bunch of new deps
Penned by viq on 20150726 14:50.55, we have: | ping | -- | viq My thoughts are... duplicity works great with hubic (kindof slow on this side of the pond, but it works!) the py-pyrax bits are ginormous as discussed elsewhere, just make the user add it to gain that functionality, since there is no compile or package time requirements for them to be installed looking around, there is a fuse fs for hubic that with a few tweaks works... see: https://github.com/toddfries/hubicfuse todd@i5/pU ~/tmp/hosts/hubic|60$ ls HubiC-Backup_2015-07-23T07:36:59Z_eb7e6547-8e59-4d46-b862-446bf7eab32f_HUAWEI+H868C/ HubiC-Backup_2015-07-27T03:05:53Z_eb7e6547-8e59-4d46-b862-446bf7eab32f_HUAWEI+H868C/ backups/ backups.kv.root/ backups.kv.todd/ backups.kv.venti/ default/ todd@i5/pU ~/tmp/hosts/hubic|61$ df -h . Filesystem SizeUsed Avail Capacity Mounted on fusefs10.0T 30.7G 10.0T 0%/home/todd/tmp/hosts/hubic todd@i5/pU ~/tmp/hosts/hubic|62$ Thanks, -- Todd T. Fries . http://todd.fries.net/pgp.txt . @unix2mars . github:toddfries
Re: [tobi...@tmux.org: mark net/rtorrent as broken on powerpc]
On Fri, Jul 31, 2015 at 06:51:19PM +0200, Martin Pieuchot wrote: > On 31/07/15(Fri) 15:31, Stuart Henderson wrote: > > On 2015/07/31 15:53, Tobias Ulmer wrote: > > > Is David around? Any objections should be voiced in the next few hours, > > > before I commit this. > > > > It's actually libtorrent not rtorrent that should be marked broken. > > > > Would it be worth building on i386 with compiler flags to fix that, > > at the expense of not running on crappy old machines that you probably > > wouldn't want to run this on anyway? > > There's only one atomic operation on a 64bit value and it is just for > instrumentation. So by adding "--disable-instrumentation" to the > configure arguments libtorrent builds just fine on macppc. I did not > try i386 but it should be the same. Thanks martin for bringing some common sense into this atomic creep :)
Re: [tobi...@tmux.org: mark net/rtorrent as broken on powerpc]
On 31/07/15(Fri) 15:31, Stuart Henderson wrote:
> On 2015/07/31 15:53, Tobias Ulmer wrote:
> > Is David around? Any objections should be voiced in the next few hours,
> > before I commit this.
>
> It's actually libtorrent not rtorrent that should be marked broken.
>
> Would it be worth building on i386 with compiler flags to fix that,
> at the expense of not running on crappy old machines that you probably
> wouldn't want to run this on anyway?
There's only one atomic operation on a 64bit value and it is just for
instrumentation. So by adding "--disable-instrumentation" to the
configure arguments libtorrent builds just fine on macppc. I did not
try i386 but it should be the same.
Index: Makefile
===
RCS file: /cvs/ports/net/libtorrent/Makefile,v
retrieving revision 1.41
diff -u -p -r1.41 Makefile
--- Makefile31 Jul 2015 16:08:44 - 1.41
+++ Makefile31 Jul 2015 16:45:13 -
@@ -11,7 +11,7 @@ NOT_FOR_ARCHS=${GCC3_ARCHS}
DISTNAME= libtorrent-0.13.4
EPOCH= 0
-REVISION= 0
+REVISION= 1
SHARED_LIBS += torrent 21.0# .18.0
CATEGORIES=net devel
@@ -32,14 +32,7 @@ CONFIGURE_ARGS= ${CONFIGURE_SHARED} \
--enable-static \
--with-kqueue \
--without-epoll \
+ --disable-instrumentation \
--disable-debug
-
-.include
-
-# for 64-bit atomic ops
-.if ${ARCH:Mi386}
-CFLAGS+= -march=i586 -fomit-frame-pointer
-CXXFLAGS+= -march=i586 -fomit-frame-pointer
-.endif
.include
Re: [tobi...@tmux.org: mark net/rtorrent as broken on powerpc]
Il 31/lug/2015 17:11, "Tobias Ulmer" ha scritto:
>
> Thought about that, but was too lazy to check that libtorrent is only
> used by rtorrent. It is.
>
> ok
Also ok dcoppa@
> On Fri, Jul 31, 2015 at 03:31:41PM +0100, Stuart Henderson wrote:
> > On 2015/07/31 15:53, Tobias Ulmer wrote:
> > > Is David around? Any objections should be voiced in the next few
hours,
> > > before I commit this.
> >
> > It's actually libtorrent not rtorrent that should be marked broken.
> >
> > Would it be worth building on i386 with compiler flags to fix that,
> > at the expense of not running on crappy old machines that you probably
> > wouldn't want to run this on anyway?
> >
> > Index: libtorrent/Makefile
> > ===
> > RCS file: /cvs/ports/net/libtorrent/Makefile,v
> > retrieving revision 1.40
> > diff -u -p -r1.40 Makefile
> > --- libtorrent/Makefile 24 Mar 2015 13:35:09 - 1.40
> > +++ libtorrent/Makefile 31 Jul 2015 14:31:14 -
> > @@ -2,6 +2,10 @@
> >
> > COMMENT= BitTorrent library written in C++
> >
> > +BROKEN-hppa =undefined references to __sync atomic ops
> > +BROKEN-mips64 = undefined references to __sync atomic ops
> > +BROKEN-sh = undefined references to __sync atomic ops
> > +
> > # requires C++ tr1 headers
> > NOT_FOR_ARCHS= ${GCC3_ARCHS}
> >
> > @@ -28,5 +32,13 @@ CONFIGURE_ARGS=${CONFIGURE_SHARED} \
> > --with-kqueue \
> > --without-epoll \
> > --disable-debug
> > +
> > +.include
> > +
> > +# for 64-bit atomic ops
> > +.if ${ARCH:Mi386}
> > +CFLAGS+= -march=i586 -fomit-frame-pointer
> > +CXXFLAGS+= -march=i586 -fomit-frame-pointer
> > +.endif
> >
> > .include
> > Index: rtorrent/Makefile
> > ===
> > RCS file: /cvs/ports/net/rtorrent/Makefile,v
> > retrieving revision 1.48
> > diff -u -p -r1.48 Makefile
> > --- rtorrent/Makefile 28 May 2015 10:17:24 - 1.48
> > +++ rtorrent/Makefile 31 Jul 2015 14:31:25 -
> > @@ -1,10 +1,5 @@
> > # $OpenBSD: Makefile,v 1.48 2015/05/28 10:17:24 pascal Exp $
> >
> > -BROKEN-hppa =undefined references to __sync atomic ops
> > -BROKEN-mips64 = undefined references to __sync atomic ops
> > -BROKEN-sh = undefined references to __sync atomic ops
> > -BROKEN-i386 =64-bit atomics (fetch_and_and,
add_and_fetch)
> > -
> > COMMENT= ncurses BitTorrent client based on libTorrent
> >
> > DISTNAME=rtorrent-0.9.4
> >
Re: [tobi...@tmux.org: mark net/rtorrent as broken on powerpc]
Thought about that, but was too lazy to check that libtorrent is only
used by rtorrent. It is.
ok
On Fri, Jul 31, 2015 at 03:31:41PM +0100, Stuart Henderson wrote:
> On 2015/07/31 15:53, Tobias Ulmer wrote:
> > Is David around? Any objections should be voiced in the next few hours,
> > before I commit this.
>
> It's actually libtorrent not rtorrent that should be marked broken.
>
> Would it be worth building on i386 with compiler flags to fix that,
> at the expense of not running on crappy old machines that you probably
> wouldn't want to run this on anyway?
>
> Index: libtorrent/Makefile
> ===
> RCS file: /cvs/ports/net/libtorrent/Makefile,v
> retrieving revision 1.40
> diff -u -p -r1.40 Makefile
> --- libtorrent/Makefile 24 Mar 2015 13:35:09 - 1.40
> +++ libtorrent/Makefile 31 Jul 2015 14:31:14 -
> @@ -2,6 +2,10 @@
>
> COMMENT= BitTorrent library written in C++
>
> +BROKEN-hppa =undefined references to __sync atomic ops
> +BROKEN-mips64 = undefined references to __sync atomic ops
> +BROKEN-sh = undefined references to __sync atomic ops
> +
> # requires C++ tr1 headers
> NOT_FOR_ARCHS= ${GCC3_ARCHS}
>
> @@ -28,5 +32,13 @@ CONFIGURE_ARGS=${CONFIGURE_SHARED} \
> --with-kqueue \
> --without-epoll \
> --disable-debug
> +
> +.include
> +
> +# for 64-bit atomic ops
> +.if ${ARCH:Mi386}
> +CFLAGS+= -march=i586 -fomit-frame-pointer
> +CXXFLAGS+= -march=i586 -fomit-frame-pointer
> +.endif
>
> .include
> Index: rtorrent/Makefile
> ===
> RCS file: /cvs/ports/net/rtorrent/Makefile,v
> retrieving revision 1.48
> diff -u -p -r1.48 Makefile
> --- rtorrent/Makefile 28 May 2015 10:17:24 - 1.48
> +++ rtorrent/Makefile 31 Jul 2015 14:31:25 -
> @@ -1,10 +1,5 @@
> # $OpenBSD: Makefile,v 1.48 2015/05/28 10:17:24 pascal Exp $
>
> -BROKEN-hppa =undefined references to __sync atomic ops
> -BROKEN-mips64 = undefined references to __sync atomic ops
> -BROKEN-sh = undefined references to __sync atomic ops
> -BROKEN-i386 =64-bit atomics (fetch_and_and, add_and_fetch)
> -
> COMMENT= ncurses BitTorrent client based on libTorrent
>
> DISTNAME=rtorrent-0.9.4
>
Re: Fix: games/sudoku-solver
ok tobiasu@
But... why not delete the whole thing? It's from mbalmer@, he's not
using it any more (at the very least not on OpenBSD) and he even pulled
his own website and any traces of the source. Why keep it? It's a nice
programming exercise, but I doubt anyone uses it.
Oh, and the compiler warning messages don't exactly inspire strict
alignment readyness.
so.. rm -rf?
On Thu, Jul 30, 2015 at 07:29:58PM +0200, Christian Weisgerber wrote:
> This removes a spurious -fpic which broke the build on sparc64.
>
> I _think_ the intention of the Makefile is to build the webui
> component statically (for copying into chroot?), so I've fixed it
> that way. Not sure though if we need or want this.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/sudoku-solver/Makefile,v
> retrieving revision 1.19
> diff -u -p -r1.19 Makefile
> --- Makefile 30 Jul 2015 16:05:51 - 1.19
> +++ Makefile 30 Jul 2015 17:27:51 -
> @@ -3,7 +3,7 @@
> COMMENT= sudoku puzzle solver with cli, gui, and web ui
>
> DISTNAME=sudoku-solver-1.0.1
> -REVISION=7
> +REVISION=8
>
> CATEGORIES= games www x11
>
> Index: patches/patch-webui_Makefile
> ===
> RCS file: /cvs/ports/games/sudoku-solver/patches/patch-webui_Makefile,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-webui_Makefile
> --- patches/patch-webui_Makefile 23 Jun 2011 22:50:27 - 1.1
> +++ patches/patch-webui_Makefile 30 Jul 2015 17:27:51 -
> @@ -1,9 +1,18 @@
> $OpenBSD: patch-webui_Makefile,v 1.1 2011/06/23 22:50:27 naddy Exp $
> webui/Makefile.orig Tue Jun 21 07:13:47 2011
> -+++ webui/Makefile Tue Jun 21 07:14:07 2011
> -@@ -13,7 +13,7 @@ CFLAGS+= -pthread -Wall -fpic -static -I/usr/local/inc
> +--- webui/Makefile.orig Sat May 26 02:38:57 2007
> webui/Makefile Thu Jul 30 19:26:16 2015
> +@@ -6,14 +6,15 @@ SRCS= sudoku-handler.c solver.c
> + SUBDIR+=templates
> +
> + VPATH+= ..
> +-CFLAGS+=-pthread -Wall -fpic -static -I/usr/local/include \
> ++CFLAGS+=-pthread -Wall -I/usr/local/include \
> + -I/usr/local/include/ClearSilver -I.. -DDEBUG \
> + -DNO_FCGI_DEFINES
> +
> LDADD+= -L/usr/local/lib -lneo_cgi -lneo_utl -lneo_cs -lpthread
> \
> -lintl -liconv -lcrypto -lz -lc -lfcgi
> ++LDSTATIC= ${STATIC}
>
> -BINDIR= /usr/local/libexec
> +BINDIR= ${TRUEPREFIX}/libexec
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
Re: gnome-shell crashes while running desktop-update-database
On 2015/07/31 15:48, Fabian Raetz wrote: > Does the ports framework provide a way to reinstall glib2 with debugging > symbols without > deleting all reverse dependencies first? I compiled devel/glib2 with > 'DEBUG="-g -O0" make package' and want to 'make reinstall' it. Yes. First build your package, then it's something like 'env PKG_PATH=/usr/ports/packages/amd64/all pkg_add -r -D installed glib2'.
Re: [tobi...@tmux.org: mark net/rtorrent as broken on powerpc]
On 2015/07/31 15:53, Tobias Ulmer wrote:
> Is David around? Any objections should be voiced in the next few hours,
> before I commit this.
It's actually libtorrent not rtorrent that should be marked broken.
Would it be worth building on i386 with compiler flags to fix that,
at the expense of not running on crappy old machines that you probably
wouldn't want to run this on anyway?
Index: libtorrent/Makefile
===
RCS file: /cvs/ports/net/libtorrent/Makefile,v
retrieving revision 1.40
diff -u -p -r1.40 Makefile
--- libtorrent/Makefile 24 Mar 2015 13:35:09 - 1.40
+++ libtorrent/Makefile 31 Jul 2015 14:31:14 -
@@ -2,6 +2,10 @@
COMMENT= BitTorrent library written in C++
+BROKEN-hppa = undefined references to __sync atomic ops
+BROKEN-mips64 =undefined references to __sync atomic ops
+BROKEN-sh =undefined references to __sync atomic ops
+
# requires C++ tr1 headers
NOT_FOR_ARCHS= ${GCC3_ARCHS}
@@ -28,5 +32,13 @@ CONFIGURE_ARGS= ${CONFIGURE_SHARED} \
--with-kqueue \
--without-epoll \
--disable-debug
+
+.include
+
+# for 64-bit atomic ops
+.if ${ARCH:Mi386}
+CFLAGS+= -march=i586 -fomit-frame-pointer
+CXXFLAGS+= -march=i586 -fomit-frame-pointer
+.endif
.include
Index: rtorrent/Makefile
===
RCS file: /cvs/ports/net/rtorrent/Makefile,v
retrieving revision 1.48
diff -u -p -r1.48 Makefile
--- rtorrent/Makefile 28 May 2015 10:17:24 - 1.48
+++ rtorrent/Makefile 31 Jul 2015 14:31:25 -
@@ -1,10 +1,5 @@
# $OpenBSD: Makefile,v 1.48 2015/05/28 10:17:24 pascal Exp $
-BROKEN-hppa = undefined references to __sync atomic ops
-BROKEN-mips64 =undefined references to __sync atomic ops
-BROKEN-sh =undefined references to __sync atomic ops
-BROKEN-i386 = 64-bit atomics (fetch_and_and, add_and_fetch)
-
COMMENT= ncurses BitTorrent client based on libTorrent
DISTNAME= rtorrent-0.9.4
Re: [tobi...@tmux.org: mark net/rtorrent as broken on powerpc]
On Fri, Jul 31, 2015 at 04:02:10PM +0200, David Coppa wrote: > Il 31/lug/2015 15:53, "Tobias Ulmer" ha scritto: > > > > Is David around? Any objections should be voiced in the next few hours, > > before I commit this. > > Go ahead! Ah, so that explains why rtorrent on my macppc hasnt been updated in ages guess it's time to find another client.
Re: [tobi...@tmux.org: mark net/rtorrent as broken on powerpc]
Il 31/lug/2015 15:53, "Tobias Ulmer" ha scritto: > > Is David around? Any objections should be voiced in the next few hours, > before I commit this. Go ahead! Thanks, David > - Forwarded message from Tobias Ulmer - > > Date: Thu, 30 Jul 2015 18:30:23 +0200 > From: Tobias Ulmer > To: dco...@openbsd.org > Subject: mark net/rtorrent as broken on powerpc > > Mark broken and sort the list, no point in wasting cpu time > > ok? > > Index: Makefile > === > RCS file: /home/vcs/cvs/openbsd/ports/net/rtorrent/Makefile,v > retrieving revision 1.48 > diff -u -p -r1.48 Makefile > --- Makefile28 May 2015 10:17:24 - 1.48 > +++ Makefile30 Jul 2015 16:13:24 - > @@ -1,9 +1,10 @@ > # $OpenBSD: Makefile,v 1.48 2015/05/28 10:17:24 pascal Exp $ > > BROKEN-hppa = undefined references to __sync atomic ops > +BROKEN-i386 = 64-bit atomics (fetch_and_and, add_and_fetch) > BROKEN-mips64 =undefined references to __sync atomic ops > +BROKEN-powerpc = undefined references to __sync atomic ops > BROKEN-sh =undefined references to __sync atomic ops > -BROKEN-i386 = 64-bit atomics (fetch_and_and, add_and_fetch) > > COMMENT= ncurses BitTorrent client based on libTorrent > > > - End forwarded message - >
Re: gnome-shell crashes while running desktop-update-database
On Fri, Jul 31, 2015 at 03:48:33PM +0200, Fabian Raetz wrote: > Hi ports@, > > i'm runnning -current/amd64 + GNOME environment. > > gnome-shell crashes multiple times while running "pkg_add -u" (since a > few month?) but i didn't knew what / which package(s) exactly triggered the > crash until > today. The crash can be triggered by executing "udpate-desktop-database". > > Does the ports framework provide a way to reinstall glib2 with debugging > symbols without > deleting all reverse dependencies first? I compiled devel/glib2 with > 'DEBUG="-g -O0" make package' and want to 'make reinstall' it. > > Sorry for reporting that late in the release cycle! That's a known issue: https://bugzilla.gnome.org/show_bug.cgi?id=739424 -- Antoine
[tobi...@tmux.org: mark net/rtorrent as broken on powerpc]
Is David around? Any objections should be voiced in the next few hours, before I commit this. - Forwarded message from Tobias Ulmer - Date: Thu, 30 Jul 2015 18:30:23 +0200 From: Tobias Ulmer To: dco...@openbsd.org Subject: mark net/rtorrent as broken on powerpc Mark broken and sort the list, no point in wasting cpu time ok? Index: Makefile === RCS file: /home/vcs/cvs/openbsd/ports/net/rtorrent/Makefile,v retrieving revision 1.48 diff -u -p -r1.48 Makefile --- Makefile28 May 2015 10:17:24 - 1.48 +++ Makefile30 Jul 2015 16:13:24 - @@ -1,9 +1,10 @@ # $OpenBSD: Makefile,v 1.48 2015/05/28 10:17:24 pascal Exp $ BROKEN-hppa = undefined references to __sync atomic ops +BROKEN-i386 = 64-bit atomics (fetch_and_and, add_and_fetch) BROKEN-mips64 =undefined references to __sync atomic ops +BROKEN-powerpc = undefined references to __sync atomic ops BROKEN-sh =undefined references to __sync atomic ops -BROKEN-i386 = 64-bit atomics (fetch_and_and, add_and_fetch) COMMENT= ncurses BitTorrent client based on libTorrent - End forwarded message -
gnome-shell crashes while running desktop-update-database
Hi ports@, i'm runnning -current/amd64 + GNOME environment. gnome-shell crashes multiple times while running "pkg_add -u" (since a few month?) but i didn't knew what / which package(s) exactly triggered the crash until today. The crash can be triggered by executing "udpate-desktop-database". Does the ports framework provide a way to reinstall glib2 with debugging symbols without deleting all reverse dependencies first? I compiled devel/glib2 with 'DEBUG="-g -O0" make package' and want to 'make reinstall' it. Sorry for reporting that late in the release cycle! Regards, Fabian No malloc.conf. $ gdb /usr/local/bin/gnome-shell gnome-shell.core (no debugging symbols found) Core was generated by `gnome-shell'. Program terminated with signal 10, Bus error. Reading symbols from /usr/lib/libpthread.so.19.0...done. Loaded symbols for /usr/lib/libpthread.so.19.0 Loaded symbols for /usr/local/bin/gnome-shell Reading symbols from /usr/local/lib/gnome-shell/libgnome-shell.so...done. Loaded symbols for /usr/local/lib/gnome-shell/libgnome-shell.so Reading symbols from /usr/local/lib/libxml2.so.15.1...done. Loaded symbols for /usr/local/lib/libxml2.so.15.1 Reading symbols from /usr/lib/libz.so.5.0...done. Loaded symbols for /usr/lib/libz.so.5.0 Reading symbols from /usr/local/lib/liblzma.so.2.1...done. Loaded symbols for /usr/local/lib/liblzma.so.2.1 Reading symbols from /usr/local/lib/libiconv.so.6.0...done. Loaded symbols for /usr/local/lib/libiconv.so.6.0 Reading symbols from /usr/lib/libm.so.9.0...done. Loaded symbols for /usr/lib/libm.so.9.0 Reading symbols from /usr/local/lib/libatk-bridge-2.0.so.0.0...done. Loaded symbols for /usr/local/lib/libatk-bridge-2.0.so.0.0 Reading symbols from /usr/local/lib/libdbus-1.so.11.0...done. Loaded symbols for /usr/local/lib/libdbus-1.so.11.0 Symbols already loaded for /usr/lib/libpthread.so.19.0 Reading symbols from /usr/local/lib/libgmodule-2.0.so.4200.1...done. Loaded symbols for /usr/local/lib/libgmodule-2.0.so.4200.1 Reading symbols from /usr/local/lib/libglib-2.0.so.4200.1...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.4200.1 Reading symbols from /usr/local/lib/libpcre.so.3.0...done. Loaded symbols for /usr/local/lib/libpcre.so.3.0 Reading symbols from /usr/local/lib/libintl.so.6.0...done. Loaded symbols for /usr/local/lib/libintl.so.6.0 Reading symbols from /usr/local/lib/libatk-1.0.so.21609.1...done. Loaded symbols for /usr/local/lib/libatk-1.0.so.21609.1 Reading symbols from /usr/local/lib/libgobject-2.0.so.4200.1...done. Loaded symbols for /usr/local/lib/libgobject-2.0.so.4200.1 Reading symbols from /usr/local/lib/libffi.so.1.1...done. Loaded symbols for /usr/local/lib/libffi.so.1.1 Reading symbols from /usr/local/lib/libatspi.so.0.1...done. Loaded symbols for /usr/local/lib/libatspi.so.0.1 Reading symbols from /usr/X11R6/lib/libSM.so.9.0...done. Loaded symbols for /usr/X11R6/lib/libSM.so.9.0 Reading symbols from /usr/X11R6/lib/libICE.so.10.0...done. Loaded symbols for /usr/X11R6/lib/libICE.so.10.0 Reading symbols from /usr/X11R6/lib/libX11.so.16.1...done. Loaded symbols for /usr/X11R6/lib/libX11.so.16.1 Reading symbols from /usr/X11R6/lib/libxcb.so.3.1...done. Loaded symbols for /usr/X11R6/lib/libxcb.so.3.1 Reading symbols from /usr/local/lib/libgjs.so.4.2...done. Loaded symbols for /usr/local/lib/libgjs.so.4.2 Reading symbols from /usr/local/lib/libgirepository-1.0.so.3.0...done. Loaded symbols for /usr/local/lib/libgirepository-1.0.so.3.0 Reading symbols from /usr/local/lib/libgio-2.0.so.4200.1...done. Loaded symbols for /usr/local/lib/libgio-2.0.so.4200.1 Reading symbols from /usr/local/lib/libgthread-2.0.so.4200.1...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.4200.1 Reading symbols from /usr/local/lib/libmozjs-24.so.0.0...done. Loaded symbols for /usr/local/lib/libmozjs-24.so.0.0 Reading symbols from /usr/local/lib/libgtk-3.so.1600.0...done. Loaded symbols for /usr/local/lib/libgtk-3.so.1600.0 Reading symbols from /usr/local/lib/libgdk-3.so.1600.0...done. Loaded symbols for /usr/local/lib/libgdk-3.so.1600.0 Reading symbols from /usr/local/lib/libpangocairo-1.0.so.3600.0...done. Loaded symbols for /usr/local/lib/libpangocairo-1.0.so.3600.0 Reading symbols from /usr/local/lib/libpango-1.0.so.3600.0...done. Loaded symbols for /usr/local/lib/libpango-1.0.so.3600.0 Reading symbols from /usr/local/lib/libcairo.so.12.3...done. Loaded symbols for /usr/local/lib/libcairo.so.12.3 Reading symbols from /usr/X11R6/lib/libpixman-1.so.32.6...done. Loaded symbols for /usr/X11R6/lib/libpixman-1.so.32.6 Reading symbols from /usr/X11R6/lib/libpthread-stubs.so.2.0...done. Loaded symbols for /usr/X11R6/lib/libpthread-stubs.so.2.0 Reading symbols from /usr/X11R6/lib/libfontconfig.so.9.1...done. Loaded symbols for /usr/X11R6/lib/libfontconfig.so.9.1 Reading symbols from /usr/X11R6/lib/libfreetype.so.24.0...done. Loaded symbols for /usr/X11R6/lib/libfreetype.so.24.0 Reading symbols from /usr/lib/libexpat.so.11.0...done. Loaded symbols for /usr/lib/libexpa
