linkage problem with libgcc from gcc-4.9
' '/tmp/tmpj3yLhWexe' '-nostdinc++' '-std=c++11' '-D' 'LIBCXXABI_NO_TIMER' '-I' '/usr/ports/pobj/llvmorg-3.6.1/llvm-3.6.1.src/projects/libcxxabi/include' '-I' '/usr/ports/pobj/llvmorg-3.6.1/llvm-3.6.1.src/projects/libcxx/include' '-nodefaultlibs' '-L/usr/ports/pobj/llvmorg-3.6.1/build-amd64/lib' '-v' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-unknown-openbsd5.7/4.9.2/collect2 --eh-frame-hdr -e __start -Bdynamic -dynamic-linker /usr/libexec/ld.so -o /tmp/tmpj3yLhWexe /usr/lib/crt0.o /usr/lib/crtbegin.o -L/usr/ports/pobj/llvmorg-3.6.1/build-amd64/lib -L/usr/local/lib/gcc/x86_64-unknown-openbsd5.7/4.9.2 -L/usr/local/lib/gcc/x86_64-unknown-openbsd5.7/4.9.2/../../.. /tmp//cc6yfQpy.o -lc++ -lc++abi -lc -lm -lgcc -lpthread /usr/lib/crtend.o The failing run: $ LD_LIBRARY_PATH=/usr/ports/pobj/llvmorg-3.6.1/build-amd64/lib /tmp/tmpj3yLhWexe /tmp/tmpj3yLhWexe:/usr/ports/pobj/llvmorg-3.6.1/build-amd64/lib/libc++abi.so.0.0: undefined symbol '_Unwind_RaiseException' lazy binding failed! Segmentation fault (core dumped) If I ask ld.so to bind all symbols at startup: $ LD_LIBRARY_PATH=/usr/ports/pobj/llvmorg-3.6.1/build-amd64/lib LD_BIND_NOW=yes /tmp/tmpj3yLhWexe /tmp/tmpj3yLhWexe:/usr/ports/pobj/llvmorg-3.6.1/build-amd64/lib/libc++abi.so.0.0: undefined symbol '_Unwind_GetIP' /tmp/tmpj3yLhWexe:/usr/ports/pobj/llvmorg-3.6.1/build-amd64/lib/libc++abi.so.0.0: undefined symbol '_Unwind_GetRegionStart' /tmp/tmpj3yLhWexe:/usr/ports/pobj/llvmorg-3.6.1/build-amd64/lib/libc++abi.so.0.0: undefined symbol '_Unwind_Resume' /tmp/tmpj3yLhWexe:/usr/ports/pobj/llvmorg-3.6.1/build-amd64/lib/libc++abi.so.0.0: undefined symbol '_Unwind_DeleteException' /tmp/tmpj3yLhWexe:/usr/ports/pobj/llvmorg-3.6.1/build-amd64/lib/libc++abi.so.0.0: undefined symbol '_Unwind_RaiseException' /tmp/tmpj3yLhWexe:/usr/ports/pobj/llvmorg-3.6.1/build-amd64/lib/libc++abi.so.0.0: undefined symbol '_Unwind_SetIP' /tmp/tmpj3yLhWexe:/usr/ports/pobj/llvmorg-3.6.1/build-amd64/lib/libc++abi.so.0.0: undefined symbol '_Unwind_GetLanguageSpecificData' /tmp/tmpj3yLhWexe:/usr/ports/pobj/llvmorg-3.6.1/build-amd64/lib/libc++abi.so.0.0: undefined symbol '_Unwind_SetGR' /tmp/tmpj3yLhWexe:/usr/ports/pobj/llvmorg-3.6.1/build-amd64/lib/libc++.so.0.0: undefined symbol '_Unwind_Resume' Segmentation fault (core dumped) These symbols normally comes with libgcc.a. The compile command-line use -lgcc, and with eg++ the file is: $ eg++ -print-libgcc-file-name /usr/local/lib/gcc/x86_64-unknown-openbsd5.7/4.9.2/libgcc.a Replacing '-lgcc' with complete path have the same result. The final program don't include the symbol. $ nm -g /tmp/tmpj3yLhWexe | grep _Unwind_RaiseException $ whereas it exists in 4.9.2/libgcc.a: $ nm -g /usr/local/lib/gcc/x86_64-unknown-openbsd5.7/4.9.2/libgcc.a | grep _Unwind_RaiseException 25b0 T _Unwind_RaiseException But, if I use libgcc.a from base (/usr/lib/gcc-lib/amd64-unknown-openbsd5.7/4.2.1/libgcc.a) the program haven't problem, the symbols are correctly binded, and the test program works well. $ eg++ ... -lc -lm /usr/lib/gcc-lib/amd64-unknown-openbsd5.7/4.2.1/libgcc.a -lpthread $ LD_LIBRARY_PATH=/usr/ports/pobj/llvmorg-3.6.1/build-amd64/lib LD_BIND_NOW=yes /tmp/tmpj3yLhWexe echo ok ok $ nm -g /tmp/tmpj3yLhWexe | grep _Unwind_RaiseException 3bc0 T _Unwind_RaiseException Any clues would be welcome. Thanks. -- Sébastien Marie
latexmk / texlive_base-2014 conflict
Hi, I started to see warnings when I upgrade packages using pkg_add -u texlive_base-2014:zziplib-0.13.62-0.13.62p0: ok Bogus symlink: /usr/local/bin/latexmk Renaming old file /usr/local/bin/latexmk to /usr/local/bin/latexmk.dVFMswT8Fw texlive_base-2014-2014: ok From pkg_locate database, it seems that texlive_base-2014 and latexmk should conflicts: $ pkg_locate */latexmk latexmk-443ap0:textproc/latexmk:/usr/local/bin/latexmk texlive_base-2014:print/texlive/base:/usr/local/bin/latexmk From latexmk package, the /usr/local/bin/latexmk file is a perl script. From texlive_base-2014 package, the file is a symlink to ../share/texmf-dist/scripts/latexmk/latexmk.pl, and the pointed file don't exist. I think texlive_base-2014 package shouldn't provide /usr/local/bin/latexmk. Thanks. -- Sébastien Marie
rust/llvm status. was: Re: [maintainer update] rust 1.0.0
On Sat, May 16, 2015 at 10:24:46PM +, Brandon Mercer wrote:
[...]
What is the plan for llvm? We should be able to use the llvm in
ports in the long term,
I will try to explain the current status of rust with LLVM.
I am agreed that I would be very good thing that rust could be able to
using llvm in ports, and not rebuild an embedded llvm version.
but it's my understanding that they have some patches applied to llvm
to satisfy their needs?
I don't have followed exactly what is the *current* status of LLVM
version embedded with rust. So I have asked on #rust-internals channel (on
irc.mozilla.org).
semarie: where can I found information about minimal LLVM version for
building rust ?
cmr: I think 3.5 right now
doener: 3.5 in theory, in practice we lack some version check to actually
make
it work I think (e.g. the assume intrinsic is used unconditionally)
So a LLVM 3.5 should be suffisent to build rust (but dev aren't sure).
So I have redo some tests to build with devel/llvm.
I have first tried to build it with clang (from devel/llvm), by adding
--llvm-root=/usr/local --enable-clang to configure stage.
After that, testing just the compilation of rustllvm part is:
$ env VERBOSE=1 gmake x86_64-unknown-openbsd/rt/librustllvm.a
First, some paths for includes are wrong. But it could be just be done
by patching. devel/llvm announce it self as 3.5, but the version is
something between 3.4 and 3.5.
After that, I have several errors that seems due to c++11.
I am not sure to understand exactly the errors, but:
- building without specific options: error because use of specific c++11
extensions in rust (src/rustllvm/).
- building with CFLAGS=-std=c++11: errors in llvm includes, because
use of c++11 without c++11 std library (from my interpretation).
- building with CFLAGS=-std=c++11 -stdlib=libc++: error in llvm
includes, because lake of headers.
It seems building with clang would need libc++.
Second try, by building with gcc 4.8. The problems seems to be
differences between what rust expects to find in llvm headers, and what
gcc found in it:
- error: no matching function for call to 'llvm::MemoryBuffer::getFile(cons t
char*, int, bool)'
- error: 'class llvm::AttrBuilder' has no member named 'addDereferenceableAttr'
- ...
Here the problems seems to be that devel/llvm version isn't a true 3.5.
I have checked the lib/Support/MemoryBuffer.cpp in devel/llvm and
llvm.org (3.5 and 3.6). In devel/llvm the return is error_code, and in
llvm.org, the return is ErrorOrstd::unique_ptrMemoryBuffer.
So I am not sure that using devel/llvm with rust would be possible, without
rewriting rustllvm part (and it is a moving target), or backport several
others parts of llvm 3.5 in devel/llvm.
Another possibility would be to have another version of llvm in ports,
installed under a subdirectory of ${LOCALBASE} in order to not conflict
with devel/llvm. (/usr/local/llvm3.6, or /usr/local/llvmorg for
examples). The building of this new port would require lang/gcc/4.8 (as
gcc in base lake of c++11 support).
In the rust perspective, it would just permit to not rebuild the llvm
part each time a new version of rust come (every six weeks), and it
wouldn't be more ressource consuming than now (as we build llvm when
we build rust).
I am not sure which direction should be taken. Please comment.
Thanks.
--
Sébastien Marie
Re: [maintainer update] rust 1.0.0
On Sun, May 17, 2015 at 12:26:48PM +0100, Stuart Henderson wrote: (gdb) bt #0 0x17cf21e32181 in je_tsd_cleanup () from /usr/obj/ports/rust-1.0.0/rust-stage0/bin/rustc #1 0x17d21b150056 in _rthread_tls_destructors (thread=0x17d17efaaa00) at /usr/src/lib/librthread/rthread_tls.c:172 #2 0x17d21b14e872 in pthread_exit (retval=Variable retval is not available. ) at /usr/src/lib/librthread/rthread.c:329 #3 0x17d21b14e996 in _rthread_start (v=Variable v is not available. ) at /usr/src/lib/librthread/rthread.c:146 #4 0x17d1b702268b in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75 #5 0x in ?? () It looks like the bootstrapper (rust-stage0/bin/rustc) may have a problem. je_tsd_cleanup come from jemalloc, and I am not sure if it is correctly build (forced to be build without thread-local-storage). another possibility is libraries vs kernel. the bootstrapper was build with: - libc.so.78.1 - libestdc++.so.16.0 - libm.so.9.0 - libpthread.so.18.1 (there are in rust-stage0/lib). In the two cases a rebuild of the bootstrapper would be required. I will take a look in this direction. I see that 'make update-plist' have removed '@bin' annotation on binaries (see pkg/PLIST-main). Is it normal ? This may be due to the change to the (very nice) file(1) rewrite, or it may be some change in the produced binaries. Due to the above problem I can't check further. After updating /usr/ports, annotations comes back. Thanks. -- Sébastien Marie
[maintainer update] rust 1.0.0
Hi,
Here a patch in order to update rust to 1.0.0 (stable version).
Tested using make test.
Thanks.
--
Sébastien Marie
Index: Makefile
===
RCS file: /cvs/ports/lang/rust/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile18 Apr 2015 12:19:09 - 1.3
+++ Makefile16 May 2015 07:03:34 -
@@ -7,8 +7,8 @@ PKG_ARCH-doc = *
COMMENT-main = compiler for Rust Language
COMMENT-doc = html documentation for rustc
-V =1.0.0beta2
-DISTNAME = rustc-1.0.0-beta.2-src
+V =1.0.0
+DISTNAME = rustc-1.0.0-src
PKGNAME = rust-${V}
PKGNAME-main = rust-${V}
@@ -81,7 +81,7 @@ USE_GMAKE = Yes
CONFIGURE_STYLE = simple
CONFIGURE_ARGS += --disable-valgrind-rpass \
- --release-channel=beta \
+ --release-channel=stable \
--prefix=${LOCALBASE} \
--mandir=${LOCALBASE}/man
Index: distinfo
===
RCS file: /cvs/ports/lang/rust/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo18 Apr 2015 12:19:09 - 1.2
+++ distinfo16 May 2015 07:03:34 -
@@ -1,4 +1,4 @@
SHA256
(rust/rust-stage0-2015-03-27-5520801-openbsd-x86_64-afab969e747a3fc72c357155ca82891d2b485b36.tar.bz2)
= R00kMjGzuiNJRuckAKOtH51KtwrYle2npQkV12GGYi4=
-SHA256 (rust/rustc-1.0.0-beta.2-src.tar.gz) =
lp8gv+xYhFavirgcmwDvRt8HW/msmVXkKoex85y5l3E=
+SHA256 (rust/rustc-1.0.0-src.tar.gz) =
wwTL1PeyXRFrc8JJ9mvbXJ2oZFhVzhlaQb2lB3uZXro=
SIZE
(rust/rust-stage0-2015-03-27-5520801-openbsd-x86_64-afab969e747a3fc72c357155ca82891d2b485b36.tar.bz2)
= 23974052
-SIZE (rust/rustc-1.0.0-beta.2-src.tar.gz) = 22115249
+SIZE (rust/rustc-1.0.0-src.tar.gz) = 22121878
Re: [maintainer update] rust 1.0.0
On Sat, May 16, 2015 at 10:24:46PM +, Brandon Mercer wrote: I have a very similar diff that I did yesterday and it worked well. The beta that is in ports now is not really usable as is so I'm OK with it going in. What are the problem you have with beta ? A rust problem that the update should solve, or a specific problem with openbsd ? What is the plan for llvm? We should be able to use the llvm in ports in the long term, but it's my understanding that they have some patches applied to llvm to satisfy their needs? I would really like to avoid another scenario like what has happened with webkit. Rust basically depends of LLVM version 3.5 or 3.6. The version of devel/llvm is based on llvm 3.4/3.5 + lot of patches. For some pointer on devel/llvm perspective, please refer to http://marc.info/?l=openbsd-portsm=142756878131426w=2 Thanks. -- Sébastien Marie
Re: [maintener update] lang/rust: ping + beta1
Hi, This patch include: - the previous patch to disambiguate linkage (not yet commited) - update to rust-1.0.0beta1 On Wed, Apr 15, 2015 at 04:10:42PM +0200, Sébastien Marie wrote: It provide a correction to permit to build lang/rust whereas gcc-libs-4.9.* is installed (+ some cleanup in comments). The problem with gcc-libs-4.9.* is the package include a libestdc++.so.17.0 file. The lang/rust is normally linked with libestdc++.so.16.0, but without this patch, it could be linked with libestdc++.so.17.0 if present. The patch disambiguate the linkage. Please commit or feedback. Thanks. -- Sébastien Marie
Re: New port - MLton
On Mon, Mar 02, 2015 at 05:21:00PM +1300, m...@extensibl.com wrote: On Sun, Mar 01, 2015 at 01:55:49PM +, Stuart Henderson wrote: Build fails with: gmake[3]: mlton: Command not found ..so presumably it needs some work to fetch (via SUPDISTFILES?) and use a bootstrap? The port's Makefile should really have a way to generate a bootstrap file, or at least some clear instructions about how to do so. See the lang/gcc ports for some ideas about this. We need to have a way to re-generate bootstraps in the event of a flag day update to the OS - sorry it isn't going to be particularly simple for a first port but that's the way it is.. MLton requires mlton compiler to be present to compile. it isn't a problem, but a port need to be self-contained. The question is whether it is acceptable to provide pre-generated C/assembly code along with required instructions to assist with package build (from scratch)? if the required instructions are code in Makefile, yes it is acceptable :) The port will known how to build itself. The port will rebuild mlton compiler twice in that case: get pre-generated C/assembly - compile bootstrapped mlton from C/assembly - compile mlton compiler from source using the bootstrapped mlton compiler Are there any better options? It is a simple and good way to procede. You could take a look at others compilers in ports. It is very common for a compiler of language X to be written in the language X. :) A possible simple example is lang/chicken (a scheme compiler): upstream provide C code (generated by chicken) in the archive for initial bootstrapping when no chicken compiler is available on host. The build is in two steps (there are two ports exactly: chicken-bootstrap and chicken-core): - lang/chicken/bootstrap : it is a C version of the compiler - lang/chicken/core depend of lang/chicken/bootstrap : it compile scheme code with the bootstrapper Depending of mlton, it could be possible to have only one port to build all the stuff... Several others ports are possible examples (lang/ghc, lang/ocaml, ...). Just look at ports in lang categories. There are also so others compilers in openbsd-wip at https://github.com/jasperla/openbsd-wip Good luck. -- Sébastien Marie
Re: about rustc / successfully build
Hi ! I just finish a full compilation cycle of rustc under openbsd ! We have a fonctionnal rustc ! The previous Thread problem was due to following dragonfly for stack managment, whereas dragonfly have segmented-stacks, and openbsd not. And after that, just some linking problem (rustc search LLVM in /usr/local instead of the one it has compiled...) The github have been updated: https://github.com/semarie/rust/ I use two additionnals patchs: - mk/main.mk: for adding --sysroot $$(HROOT$(1)_H_$(3)) to rustc - etc/mklldeps.py: for linking with estdc+++ instead of stdc++ But severals tasks remains: - some cleanup - run the unit tests of rustc - propose a pull request to rust dev Thanks. -- Sébastien Marie
about rustc
Hi,
I am currently working to port rustc to openbsd (amd64).
I have wrote a compatibility layer for openbsd (using some part of
http://www.ntecs.de/blog/2014/07/29/rust-ported-to-dragonflybsd/ and
https://github.com/qbit/rust-cross-openbsd), and I am able to
cross-compile a rustc openbsd-binary from linux.
I have done lot of rewrite for have a more valid openbsd support in
rustc. For explain to not-rustc-dev-aware persons: rustc don't used
header files (.h). It needs to rewriting them in rustc-language, and use
that for FFI calls. It is methods definition, types definition (size,
struct members...).
And as openbsd isn't same as freebsd or dragonfly, just adding
conditional-compilation at same places of freebsd/dragonfly isn't
enought.
The rustc code is here: https://github.com/semarie/rust/tree/openbsd,
and for compilation I mainly take inspiration from
http://github.jfet.org/Rust_cross_bootstrapping.html.
My build framework is somehow fragile: it use shared filesystem between
a linux (debian wheezy) and an openbsd (openbsd-current, somewhere at
starting 5.7-BETA). For openbsd target, the objects files are build on
linux, and linking (using remote-command) on openbsd (modulo some parts
based on C code, whole compiled under openbsd, like LLVM, compiler-rt,
libbacktrace...).
As result, the rustc openbsd-binary is mainly fonctionnal: I am able to
build simples rustc programs (like hello-world.hs, or guess.rs [from
rustc guide]).
So I started to build rustc it-self, fully under openbsd. The current
status is the build isn't complete because of random panic or coredump
(more details below).
The current goal is to have a working rustc binary compiled from
openbsd, and next check it with the rustc testing framework.
Some workarounds/problems:
- I compile without jemalloc (the jemalloc make check crash
systematically. The issue wasn't investigated as jemalloc seems to be
optional)
- I don't implement 'load_self' function which live under
'libstd/sys/unix/os.rs'. The function should return the filepath of
the current running program (and it isn't trivial as there are
possibles races).
As result, rustc *must* have a --sysroot argument to work, else it
would panic (and so I hack the build process to pass the argument).
Note this build hack isn't in my github repository.
mk/main.mk
-EXTRAFLAGS_STAGE$(1) = $$(RUSTFLAGS_STAGE$(1))
+EXTRAFLAGS_STAGE$(1) = --sysroot $$(HROOT$(1)_H_$(3)) $$(RUSTFLAGS_STAGE$(1))
- under openbsd, it seems rustc couldn't use ports/llvm.
ports/llvm annonce it-self as 3.5, but directory structure is
something between 3.4.2 et 3.5. and even if I hack the #include in
src/rustllvm, I have compilation errors...
As result, I currently use the llvm version provided with rustc, and
so need to compile the embeded llvm version before compile rustc.
It is ok for now, but when rustc would work enought to be packaged,
it should be investigated...
- for coredump, there are double-free and coredump that occurs
generally in thread code. I think the openbsd-layer of rustc isn't
fully correct.
- sometimes, panic randomly occurs (rustc detect itself a problem and
abort). Generally it is in checking of args for FFI ('\0' char in
middle of CString for example). So could be related to
openbsd-specific code in rustc.
- sometimes, rustc enter in infinite-loop (but it stuck in a wait, not
a busy loop). It is generally in spawing... so it may be a race in
waiting the process to ending ? Seems related to spawning too...
In conclusion, I am able to build rustc until processing
librustc_llvm.rlib (librustc_llvm.so is ok).
And I am currently blocking by thread-related coredump (or
infinite-waiting).
For how I understand the build system of rustc, building
src/librustc_llvm need to heavy use of spawning, for construct the rlib
file (an object archive, if I understand well), as it take objects files
from LLVM libraries (so a lot of libraries). So I hit theses bugs each
time (but never at same place...) I try to build it.
So I am in a linuxBuild-openbsdBuild-correctOpenbsdRustcSupport loop...
(and a full linuxBuild is something like 90min compile time).
Review of the rustc openbsd specific code are welcome... or any others
ideas :)
Thanks reading.
--
Sébastien Marie
Re: about rustc
On Fri, Jan 16, 2015 at 08:00:16AM -0700, Aaron Bieber wrote: Sébastien Marie semarie-open...@latrappe.fr writes: My fork was a pretty sad attempt at getting it ported.. I stopped with the lack of segmented stacks. That said Dave Huseby made it much further: https://github.com/dhuseby/rust-cross-openbsd ! segmented stacks are optional: iOS lake it for example. My current implementation don't use it. IIRC he ran into another issue with linking.. and is currently working on https://github.com/dhuseby/rust-cross-bitrig . He would probably be the person to talk to about furthering the OpenBSD port! I don't known about the bitrig porting effort... but as bitrig and openbsd are close, it will take a look at rustc patchs for bitrig. Thanks ! -- Sébastien Marie
segfault in librthread with glib+gio (2.0)
Hi,
Initially, this problem was discover with www/vimb. But I have isolated
it, and it seems related to glib+gio with/or librthread. The mail is
cross-posted to ports@ (if glib+gio is the problem) and bugs@ (if the
problem is with librthread).
I run openbsd -current (GENERIC.MP) under amd64.
For vimb, calling:
$ vimb -C sh xterm
will generate a vimb.core in cwd.
The segfault occurs at fork() (in librthead) in the child process (the
window of vimb stay here: it is the child that segfault).
Here a minimal c-file that reproduce the problem:
BEGIN test.c
/*
* cc test.c -o test `pkg-config -cflags -libs glib-2.0 gio-2.0`
*/
#include stdio.h
#include stdlib.h
#include glib.h
#include gio/gio.h
int main(int argc, char *argv) {
char *stdOut = NULL, *stdErr = NULL;
int status;
GError *error = NULL;
g_tls_file_database_new(/etc/ssl/cert.pem, error);
if (error) {
printf(could not load ssl database: %s\n, error-message);
g_error_free(error);
return(EXIT_FAILURE);
}
if (FALSE == g_spawn_command_line_sync(xterm, stdOut, stdErr,
status, error)) {
printf(can't run cmd: %s\n, error ? error-message :
(null));
g_clear_error(error);
return(EXIT_FAILURE);
}
return(EXIT_SUCCESS);
}
END test.c
Here a commented gdb session (and an explaination below):
$ gdb ./test
## the segfault occurs in child, so follow the child
(gdb) set follow-fork-mode child
## track when the bad data is setted
(gdb) br pthread_atfork
Function pthread_atfork not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (pthread_atfork) pending.
## run the program
(gdb) r
Starting program: /home/semarie/tmp/src/test-gio/test
Breakpoint 2 at 0x10e3aaf73840: file /usr/src/lib/librthread/rthread_fork.c,
line 179.
Pending breakpoint pthread_atfork resolved
## the bad data will be 0x10e356d3ae40 (child argument)
## the backtrace don't saw useful information... be we are somewhere in
## g_tls_file_database_new() call (when loading giomodule for tls).
Breakpoint 2, pthread_atfork (prepare=0, parent=0, child=0x10e356d3ae40) at
/usr/src/lib/librthread/rthread_fork.c:179
179 {
(gdb) bt
#0 pthread_atfork (prepare=0, parent=0, child=0x10e356d3ae40) at
/usr/src/lib/librthread/rthread_fork.c:179
#1 0x10e3aaf7128e in pthread_once (once_control=0x10e356f55f40,
init_routine=0x10e356d3aef0)
at /usr/src/lib/librthread/rthread_once.c:26
#2 0x10e356d08eae in ?? ()
#3 0x in ?? ()
## the bad data is not bad here: we could access it.
(gdb) print *0x10e356d3ae40
$1 = 1761971016
## there is some others call to pthread_atfork, skip them
(gdb) disable
(gdb) continue
Continuing.
[New process 21972]
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 1028857]
0x10e356d3ae40 in ?? ()
## ok, we try to access the bad data
## we are *after* the fork occurs (see New process)
(gdb) bt
#0 0x10e356d3ae40 in ?? ()
#1 0x10e3aaf73afb in fork () at /usr/src/lib/librthread/rthread_fork.c:160
#2 0x10e368f2b72c in fork_exec_with_pipes () from
/usr/local/lib/libglib-2.0.so.4200.0
#3 0x10e368f2c55c in g_spawn_sync () from
/usr/local/lib/libglib-2.0.so.4200.0
#4 0x10e368f2ca6a in g_spawn_command_line_sync () from
/usr/local/lib/libglib-2.0.so.4200.0
#5 0x10e0b9200fbb in main () from /home/semarie/tmp/src/test-gio/test
## the bad data is not accessible
(gdb) print *0x10e356d3ae40
Cannot access memory at address 0x10e356d3ae40
Somewhere in loading some giomodule in g_tls_file_database_new call,
pthread_atfork is called with child=0x10e356d3ae40. At this time, the
memory address is accessible (gdb print command works).
When g_spawn_command_line_sync is called, after the fork (we are in the
child process), the memory address 0x10e356d3ae40 is not accessible
anymore.
I don't known where to search now... the problem could be related to
librthread, or the use of glib+gio. Any help is welcome.
Thanks.
--
Sébastien Marie
Re: segfault in librthread with glib+gio (2.0)
Hi Dmitrij,
Apparently I have similar problem with surf:
You could try to workaround by launching surf with:
$ LD_PRELOAD=/usr/local/lib/gio/modules/libgiognutls.so surf
For vimb, it works.
About the problem, my last minimal c-file looks like:
/*
* cc test.c -o test `pkg-config -cflags -libs glib-2.0 gio-2.0`
*/
#include stdio.h
#include stdlib.h
#include glib.h
#include gio/gio.h
int main(int argc, char *argv) {
//g_module_open(/usr/local/lib/gio/modules/libgiognutls.so,
G_MODULE_BIND_MASK);
g_tls_backend_get_default ();
fork();
return(EXIT_SUCCESS);
}
The g_module_open function is called near the pthread_atfork in
g_tls_backend_get_default.
But:
- only with it (g_module_open + fork): no problem
- with g_module_open+g_tls_backend_get_default+fork: no problem
So there is something between the two...
the g_module_open (in g_tls_backend_get_default) will call:
_g_module_open (file_name=0x15887c4669c0
/usr/local/lib/gio/modules/libgiognutls.so, bind_lazy=1, bind_local=1) at
gmodule-dl.c:97
which call dlopen().
the pthread_atfork seems (but not sure) to be part of dlopen in the
pthread case.
--
Sébastien Marie
wpa_supplicant may be vulnerable to RCE (CVE-2014-3686)
Hi David, You may have already be advertised, but in case... the current version of wpa_supplicant in openbsd-ports may be vulnerable to a remote command execution. The vulnerability description is here: http://w1.fi/security/2014-1/wpacli-action-scripts.txt The vulnerability on v2.2 is triggeable if some configuration options are enable (CONFIG_P2P or CONFIG_WNM or CONFIG_HS20 or CONFIG_WPS), but I don't see any of them in current build (files/config). So I don't sure if the version in ports is vulnerable or not. Thanks. -- Sébastien Marie
Re: [UPDATE] math/pari to 2.1.7 (keep Math::Pari compatibility)
ping ?
This latest patch keep full compatibility, and have been tested with
math/p5-Math-Pari (all tests are ok).
Thanks.
--
Sébastien Marie
On Thu, Sep 11, 2014 at 09:27:34AM +0200, Sébastien Marie wrote:
Hi,
There were several problems with math/pari.
Short version:
- upgrade to the latest 2.1.x version (2.1.7) to keep Math::Pari
compatibility, and correct all problems
- test target ok for math/pari (on amd64)
- test target ok for math/p5-Math-Pari (on amd64)
Long version:
1. readline support was broken
With 2.1.6, the readline support is broken. 2.1.7 correct that.
gcc-3.4 breaks PARI compatibility code for old readline (from
Changelog).
2. test target was broken
I also patch the test script to 'exit 1' on error, instead of 'exit 0',
so new breakage should be noticed.
As side problem corrected by 2.1.7, pari on amd64 pass the test (was not
the case before)
3. emacs is automatically picked if present
I disable to search of emacs in configure script.
4. update the MASTER_SITES to found the old versions
Thanks.
--
Sébastien Marie
Index: Makefile
===
RCS file: /cvs/ports/math/pari/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile 11 Mar 2013 11:23:56 - 1.12
+++ Makefile 11 Sep 2014 07:18:58 -
@@ -2,18 +2,17 @@
COMMENT= number theory-oriented computer algebra system
-DISTNAME=pari-2.1.6
-REVISION=2
+DISTNAME=pari-2.1.7
EXTRACT_SUFX=.tgz
CATEGORIES= math
HOMEPAGE=http://pari.math.u-bordeaux.fr/
-# GPL
+# GPLv2
PERMIT_PACKAGE_CDROM=Yes
WANTLIB= X11 c m ncurses readline
-MASTER_SITES=${HOMEPAGE}/pub/pari/unix/
+MASTER_SITES=
http://pari.math.u-bordeaux.fr/pub/pari/unix/OLD/2.1/
BUILD_DEPENDS= print/texlive/base
Index: distinfo
===
RCS file: /cvs/ports/math/pari/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo 5 Apr 2007 16:20:06 - 1.2
+++ distinfo 11 Sep 2014 07:18:58 -
@@ -1,5 +1,2 @@
-MD5 (pari-2.1.6.tgz) = UGoGHI3N7DPRiHbzxVHpUQ==
-RMD160 (pari-2.1.6.tgz) = a3noS2OdGGLfFIslMTberNc79PA=
-SHA1 (pari-2.1.6.tgz) = VL1A+nCgLnbXjQ6hnA9W99pi3o4=
-SHA256 (pari-2.1.6.tgz) = YVBwBDLiy9CFZ66qYrL3+S81C4PyysjnR7HVgYg6Qic=
-SIZE (pari-2.1.6.tgz) = 1541464
+SHA256 (pari-2.1.7.tgz) = kULyza8wg8iWLxpcK7Dp/okV99lJDAMxKsI2HH6hVfo=
+SIZE (pari-2.1.7.tgz) = 1542137
Index: patches/patch-Configure
===
RCS file: /cvs/ports/math/pari/patches/patch-Configure,v
retrieving revision 1.2
diff -u -p -r1.2 patch-Configure
--- patches/patch-Configure 30 Apr 2008 19:42:07 - 1.2
+++ patches/patch-Configure 11 Sep 2014 07:18:58 -
@@ -1,6 +1,15 @@
$OpenBSD: patch-Configure,v 1.2 2008/04/30 19:42:07 naddy Exp $
Configure.orig Thu Nov 25 16:58:25 2004
-+++ ConfigureMon Apr 28 20:14:36 2008
+--- Configure.orig Wed Sep 14 13:26:40 2005
ConfigureThu Sep 11 09:10:43 2014
+@@ -246,7 +246,7 @@ fi
+ # We might need the following :
+ #
+ echo Looking for some tools first ...
+-list='ld zcat gzip ranlib perl emacs'
++list='ld zcat gzip ranlib perl'
+ pathspace=`echo $PATH | sed -e s/$dir_sep/ /g | sed -e 's,,/,g'`
+
+ for file in $list; do
@@ -844,7 +844,7 @@ if test -n $__gnuc__; then
esac
;;
@@ -10,7 +19,7 @@ $OpenBSD: patch-Configure,v 1.2 2008/04/
DBGFLAGS=-g $warn
# Some architectures need -fPIC for building dynamic lib
case $osname-$arch in hpux-*) DLCFLAGS=-fPIC;; esac
-@@ -1006,7 +1006,7 @@ if test $optimization = profiling; then DLLD=; else
+@@ -1009,7 +1009,7 @@ if test $optimization = profiling; then DLLD=; else
#aix-*) DLSUFFIX=a ;; dynamic linking does not work!
sunos-*) sodest=$VersionMajor$VersionMinor.$patch
soname=$sodest;;
@@ -19,7 +28,7 @@ $OpenBSD: patch-Configure,v 1.2 2008/04/
case $libpari_base in
pari) sodest=$version.$patch;; # released versions
*) sodest=$patch.0.0;; # unstable versions
-@@ -1044,10 +1044,6 @@ if test -n $DLLD; then
+@@ -1047,10 +1047,6 @@ if test -n $DLLD; then
freebsd-*) DLLDFLAGS=-Bshareable -x ;;
gnu-*|linux-*)DLLDFLAGS=-shared -soname \$(LIBPARI_SONAME) ;;
irix-*) DLLDFLAGS=-shared -elf -no_unresolved -all ;;
@@ -30,7 +39,7 @@ $OpenBSD: patch-Configure,v 1.2 2008/04/
sunos-*)DLLDFLAGS=-assert nodefinitions ;;
solaris-*) DLLDFLAGS=-G -h \$(LIBPARI_SONAME) ;;
*) DLLD=;;
-@@ -1159,7 +1155,6 @@ extra_flags=
+@@ -1162,7 +1158,6 @@ extra_flags=
list=exp2; . ./look
list=strftime; . ./look
case $arch in
Index: patches/patch-src_test_dotest
Re: [UPDATE] math/pari to 2.1.7 (keep Math::Pari compatibility)
Hi,
There were several problems with math/pari.
Short version:
- upgrade to the latest 2.1.x version (2.1.7) to keep Math::Pari
compatibility, and correct all problems
- test target ok for math/pari (on amd64)
- test target ok for math/p5-Math-Pari (on amd64)
Long version:
1. readline support was broken
With 2.1.6, the readline support is broken. 2.1.7 correct that.
gcc-3.4 breaks PARI compatibility code for old readline (from
Changelog).
2. test target was broken
I also patch the test script to 'exit 1' on error, instead of 'exit 0',
so new breakage should be noticed.
As side problem corrected by 2.1.7, pari on amd64 pass the test (was not
the case before)
3. emacs is automatically picked if present
I disable to search of emacs in configure script.
4. update the MASTER_SITES to found the old versions
Thanks.
--
Sébastien Marie
Index: Makefile
===
RCS file: /cvs/ports/math/pari/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile11 Mar 2013 11:23:56 - 1.12
+++ Makefile11 Sep 2014 07:18:58 -
@@ -2,18 +2,17 @@
COMMENT= number theory-oriented computer algebra system
-DISTNAME= pari-2.1.6
-REVISION= 2
+DISTNAME= pari-2.1.7
EXTRACT_SUFX= .tgz
CATEGORIES=math
HOMEPAGE= http://pari.math.u-bordeaux.fr/
-# GPL
+# GPLv2
PERMIT_PACKAGE_CDROM= Yes
WANTLIB= X11 c m ncurses readline
-MASTER_SITES= ${HOMEPAGE}/pub/pari/unix/
+MASTER_SITES= http://pari.math.u-bordeaux.fr/pub/pari/unix/OLD/2.1/
BUILD_DEPENDS= print/texlive/base
Index: distinfo
===
RCS file: /cvs/ports/math/pari/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo5 Apr 2007 16:20:06 - 1.2
+++ distinfo11 Sep 2014 07:18:58 -
@@ -1,5 +1,2 @@
-MD5 (pari-2.1.6.tgz) = UGoGHI3N7DPRiHbzxVHpUQ==
-RMD160 (pari-2.1.6.tgz) = a3noS2OdGGLfFIslMTberNc79PA=
-SHA1 (pari-2.1.6.tgz) = VL1A+nCgLnbXjQ6hnA9W99pi3o4=
-SHA256 (pari-2.1.6.tgz) = YVBwBDLiy9CFZ66qYrL3+S81C4PyysjnR7HVgYg6Qic=
-SIZE (pari-2.1.6.tgz) = 1541464
+SHA256 (pari-2.1.7.tgz) = kULyza8wg8iWLxpcK7Dp/okV99lJDAMxKsI2HH6hVfo=
+SIZE (pari-2.1.7.tgz) = 1542137
Index: patches/patch-Configure
===
RCS file: /cvs/ports/math/pari/patches/patch-Configure,v
retrieving revision 1.2
diff -u -p -r1.2 patch-Configure
--- patches/patch-Configure 30 Apr 2008 19:42:07 - 1.2
+++ patches/patch-Configure 11 Sep 2014 07:18:58 -
@@ -1,6 +1,15 @@
$OpenBSD: patch-Configure,v 1.2 2008/04/30 19:42:07 naddy Exp $
Configure.orig Thu Nov 25 16:58:25 2004
-+++ Configure Mon Apr 28 20:14:36 2008
+--- Configure.orig Wed Sep 14 13:26:40 2005
Configure Thu Sep 11 09:10:43 2014
+@@ -246,7 +246,7 @@ fi
+ # We might need the following :
+ #
+ echo Looking for some tools first ...
+-list='ld zcat gzip ranlib perl emacs'
++list='ld zcat gzip ranlib perl'
+ pathspace=`echo $PATH | sed -e s/$dir_sep/ /g | sed -e 's,,/,g'`
+
+ for file in $list; do
@@ -844,7 +844,7 @@ if test -n $__gnuc__; then
esac
;;
@@ -10,7 +19,7 @@ $OpenBSD: patch-Configure,v 1.2 2008/04/
DBGFLAGS=-g $warn
# Some architectures need -fPIC for building dynamic lib
case $osname-$arch in hpux-*) DLCFLAGS=-fPIC;; esac
-@@ -1006,7 +1006,7 @@ if test $optimization = profiling; then DLLD=; else
+@@ -1009,7 +1009,7 @@ if test $optimization = profiling; then DLLD=; else
#aix-*) DLSUFFIX=a ;; dynamic linking does not work!
sunos-*) sodest=$VersionMajor$VersionMinor.$patch
soname=$sodest;;
@@ -19,7 +28,7 @@ $OpenBSD: patch-Configure,v 1.2 2008/04/
case $libpari_base in
pari) sodest=$version.$patch;; # released versions
*) sodest=$patch.0.0;; # unstable versions
-@@ -1044,10 +1044,6 @@ if test -n $DLLD; then
+@@ -1047,10 +1047,6 @@ if test -n $DLLD; then
freebsd-*) DLLDFLAGS=-Bshareable -x ;;
gnu-*|linux-*)DLLDFLAGS=-shared -soname \$(LIBPARI_SONAME) ;;
irix-*) DLLDFLAGS=-shared -elf -no_unresolved -all ;;
@@ -30,7 +39,7 @@ $OpenBSD: patch-Configure,v 1.2 2008/04/
sunos-*)DLLDFLAGS=-assert nodefinitions ;;
solaris-*) DLLDFLAGS=-G -h \$(LIBPARI_SONAME) ;;
*) DLLD=;;
-@@ -1159,7 +1155,6 @@ extra_flags=
+@@ -1162,7 +1158,6 @@ extra_flags=
list=exp2; . ./look
list=strftime; . ./look
case $arch in
Index: patches/patch-src_test_dotest
===
RCS file: patches/patch-src_test_dotest
diff -N patches/patch-src_test_dotest
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_test_dotest 11 Sep 2014 07:18:58 -
@@ -0,0 +1,8 @@
+$OpenBSD$
+--- src/test/dotest.orig Thu Sep 11 06:39:25 2014
src/test/dotestThu Sep
Re: [UPDATE] math/pari 2.7.1
On Wed, Sep 10, 2014 at 07:24:15AM +0200, Landry Breuil wrote:
On Wed, Sep 10, 2014 at 06:52:33AM +0200, Sébastien Marie wrote:
Hi,
Here a patch to upgrade math/pari from 2.1.6 to 2.7.1. It is a big
upgrade as 2.1.6 is something like 10 years old version.
- pari use a shared lib
You dont need to use PFRAG.shared anymore if you use SHARED_ONLY, you
can move the file to PLIST and remove %shared% from it..
In order to be exact, math/pari *should* be able to build without shared
libs (so on vax too). But as I haven't necessary resource to test it, I
would prefer to keep SHARED_ONLY=Yes.
If support is need for static build, it should be doable later.
Next, the patch with requested modification.
--
Sébastien Marie
Index: Makefile
===
RCS file: /cvs/ports/math/pari/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile11 Mar 2013 11:23:56 - 1.12
+++ Makefile10 Sep 2014 07:03:33 -
@@ -1,37 +1,44 @@
# $OpenBSD: Makefile,v 1.12 2013/03/11 11:23:56 espie Exp $
+SHARED_ONLY= Yes
+
COMMENT= number theory-oriented computer algebra system
-DISTNAME= pari-2.1.6
-REVISION= 2
-EXTRACT_SUFX= .tgz
+DISTNAME= pari-2.7.1
CATEGORIES=math
HOMEPAGE= http://pari.math.u-bordeaux.fr/
-# GPL
+# GPLv2+
PERMIT_PACKAGE_CDROM= Yes
-WANTLIB= X11 c m ncurses readline
+WANTLIB= X11 c m ncurses readline gmp
-MASTER_SITES= ${HOMEPAGE}/pub/pari/unix/
+MASTER_SITES= http://pari.math.u-bordeaux.fr/pub/pari/unix/
+LIB_DEPENDS= devel/gmp
BUILD_DEPENDS= print/texlive/base
-USE_GROFF =Yes
+USE_GMAKE= Yes
+
+SHARED_LIBS += pari-gmp0.0 # 4.0
CONFIGURE_SCRIPT= Configure
CONFIGURE_STYLE= simple
-CONFIGURE_ENV= CFLAGS=${CFLAGS}
+CONFIGURE_ENV= CC=${CC} \
+ CFLAGS=${CFLAGS} \
+ LDFLAGS=${LDFLAGS}
CONFIGURE_ARGS+= --datadir=${PREFIX}/share/pari \
- --miscdir=${PREFIX}/share/pari \
+ --mandir=${PREFIX}/man/man1 \
--prefix=${PREFIX} \
- --host=${ARCH}
+ --with-gmp
TEST_TARGET= dobench
+pre-configure:
+ ${SUBST_CMD} ${WRKSRC}/config/get_dlld
+
post-install:
mv ${PREFIX}/share/pari/doc ${PREFIX}/share/doc/pari
- mv ${PREFIX}/share/pari/[A-Z]* ${PREFIX}/share/doc/pari
mv ${PREFIX}/share/pari/examples ${PREFIX}/share/examples/pari
.include bsd.port.mk
Index: distinfo
===
RCS file: /cvs/ports/math/pari/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo5 Apr 2007 16:20:06 - 1.2
+++ distinfo10 Sep 2014 07:03:33 -
@@ -1,5 +1,2 @@
-MD5 (pari-2.1.6.tgz) = UGoGHI3N7DPRiHbzxVHpUQ==
-RMD160 (pari-2.1.6.tgz) = a3noS2OdGGLfFIslMTberNc79PA=
-SHA1 (pari-2.1.6.tgz) = VL1A+nCgLnbXjQ6hnA9W99pi3o4=
-SHA256 (pari-2.1.6.tgz) = YVBwBDLiy9CFZ66qYrL3+S81C4PyysjnR7HVgYg6Qic=
-SIZE (pari-2.1.6.tgz) = 1541464
+SHA256 (pari-2.7.1.tar.gz) = zGN5GPPAsg3Ju+qZ5jnnooi4nqTQ5OP5txEKEVvLQb4=
+SIZE (pari-2.7.1.tar.gz) = 3140893
Index: patches/patch-Configure
===
RCS file: patches/patch-Configure
diff -N patches/patch-Configure
--- patches/patch-Configure 30 Apr 2008 19:42:07 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,40 +0,0 @@
-$OpenBSD: patch-Configure,v 1.2 2008/04/30 19:42:07 naddy Exp $
Configure.orig Thu Nov 25 16:58:25 2004
-+++ Configure Mon Apr 28 20:14:36 2008
-@@ -844,7 +844,7 @@ if test -n $__gnuc__; then
- esac
- ;;
- esac
-- OPTFLAGS=$OPTFLAGS -DGCC_INLINE $warn
-+ OPTFLAGS=$CFLAGS -DGCC_INLINE $warn
- DBGFLAGS=-g $warn
- # Some architectures need -fPIC for building dynamic lib
- case $osname-$arch in hpux-*) DLCFLAGS=-fPIC;; esac
-@@ -1006,7 +1006,7 @@ if test $optimization = profiling; then DLLD=; else
- #aix-*) DLSUFFIX=a ;; dynamic linking does not work!
- sunos-*) sodest=$VersionMajor$VersionMinor.$patch
- soname=$sodest;;
--gnu-*|*-alpha|solaris-*|linux-*|freebsd-*)
-+gnu-*|solaris-*|linux-*|freebsd-*)
- case $libpari_base in
- pari) sodest=$version.$patch;; # released versions
- *) sodest=$patch.0.0;; # unstable versions
-@@ -1044,10 +1044,6 @@ if test -n $DLLD; then
- freebsd-*) DLLDFLAGS=-Bshareable -x ;;
- gnu-*|linux-*)DLLDFLAGS=-shared -soname \$(LIBPARI_SONAME) ;;
- irix-*) DLLDFLAGS=-shared -elf -no_unresolved -all ;;
-- *-alpha)DLLDFLAGS=-shared; EXTRADLLDFLAGS='${LIBS}'
-- case $optimization in
-- full) DLLDFLAGS=$DLLDFLAGS -O3 ;;
-- esac;;
- sunos-*)DLLDFLAGS=-assert nodefinitions
Re: [UPDATE] math/pari 2.7.1
On Wed, Sep 10, 2014 at 09:43:22AM +0100, Stuart Henderson wrote: math/p5-Math-Pari needs fixing with this; it fails to build (with a knock-on to 9 dependent ports). Oops, I haven't check for reverse-dependencies. Thanks for note that. But math/p5-Math-Pari is not fixable (even a more recent version, the last one is Math-Pari-2.010808). From README: 2.01080* still fully supports only 2.1.7, but mostly works with 2.3.* too. math/pari 2.1.7 was released Sep 20 2005, and 2.3.* last released Feb 05 2010. Which path follow ? - math/p5-Math-Pari seems maintained (last update 01-Jun-2014) - math/pari 2.1.6 is upgradable to 2.1.7 (will full compatibility with math/p5-Math-Pari) I first go to upgrade the port instead of search for debug the outdated version, as it is not usable on my machine (amd64). $ gp Illegal instruction (core dumped) Does someone have same problem ? It should be possible to have math/pari and math/pari27. I would take a look why it crash. -- Sébastien Marie
[UPDATE] math/pari 2.7.1
Hi,
Here a patch to upgrade math/pari from 2.1.6 to 2.7.1. It is a big
upgrade as 2.1.6 is something like 10 years old version.
- pari use a shared lib
- it (optionnally) depends of devel/gmp. I choose to explicitely depends
of it, as configure pick it by default, and pari's devel said it have
better performances. Could be reverted if need (or configure a flavor
?)
- build configuration at changed from one monolitic ./Configure script
to multiple snipset of file in ./config . I ported previous patch from
./Configure to new code in ./config when applicable.
- build optimization are removed by patch (as before)
- I have removed alpha specific patch from ./Configure in the previous
version, as I couldn't find any revelant code in new ./Configure.
- gphelp is patched in order to find good directory for documentation (a
RUN_DEPENDS should be added for full functionnality: it need xdvi from
print/texlive/base, but it may be a big dependency).
Tested on amd64.
--
Sébastien Marie
Index: Makefile
===
RCS file: /cvs/ports/math/pari/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile11 Mar 2013 11:23:56 - 1.12
+++ Makefile10 Sep 2014 04:40:26 -
@@ -1,37 +1,44 @@
# $OpenBSD: Makefile,v 1.12 2013/03/11 11:23:56 espie Exp $
+SHARED_ONLY= Yes
+
COMMENT= number theory-oriented computer algebra system
-DISTNAME= pari-2.1.6
-REVISION= 2
-EXTRACT_SUFX= .tgz
+DISTNAME= pari-2.7.1
CATEGORIES=math
HOMEPAGE= http://pari.math.u-bordeaux.fr/
-# GPL
+# GPLv2+
PERMIT_PACKAGE_CDROM= Yes
-WANTLIB= X11 c m ncurses readline
+WANTLIB= X11 c m ncurses readline gmp
-MASTER_SITES= ${HOMEPAGE}/pub/pari/unix/
+MASTER_SITES= http://pari.math.u-bordeaux.fr/pub/pari/unix/
+LIB_DEPENDS= devel/gmp
BUILD_DEPENDS= print/texlive/base
-USE_GROFF =Yes
+USE_GMAKE= Yes
+
+SHARED_LIBS += pari-gmp0.0 # 4.0
CONFIGURE_SCRIPT= Configure
CONFIGURE_STYLE= simple
-CONFIGURE_ENV= CFLAGS=${CFLAGS}
+CONFIGURE_ENV= CC=${CC} \
+ CFLAGS=${CFLAGS} \
+ LDFLAGS=${LDFLAGS}
CONFIGURE_ARGS+= --datadir=${PREFIX}/share/pari \
- --miscdir=${PREFIX}/share/pari \
+ --mandir=${PREFIX}/man/man1 \
--prefix=${PREFIX} \
- --host=${ARCH}
+ --with-gmp
TEST_TARGET= dobench
+pre-configure:
+ ${SUBST_CMD} ${WRKSRC}/config/get_dlld
+
post-install:
mv ${PREFIX}/share/pari/doc ${PREFIX}/share/doc/pari
- mv ${PREFIX}/share/pari/[A-Z]* ${PREFIX}/share/doc/pari
mv ${PREFIX}/share/pari/examples ${PREFIX}/share/examples/pari
.include bsd.port.mk
Index: distinfo
===
RCS file: /cvs/ports/math/pari/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo5 Apr 2007 16:20:06 - 1.2
+++ distinfo10 Sep 2014 04:40:26 -
@@ -1,5 +1,2 @@
-MD5 (pari-2.1.6.tgz) = UGoGHI3N7DPRiHbzxVHpUQ==
-RMD160 (pari-2.1.6.tgz) = a3noS2OdGGLfFIslMTberNc79PA=
-SHA1 (pari-2.1.6.tgz) = VL1A+nCgLnbXjQ6hnA9W99pi3o4=
-SHA256 (pari-2.1.6.tgz) = YVBwBDLiy9CFZ66qYrL3+S81C4PyysjnR7HVgYg6Qic=
-SIZE (pari-2.1.6.tgz) = 1541464
+SHA256 (pari-2.7.1.tar.gz) = zGN5GPPAsg3Ju+qZ5jnnooi4nqTQ5OP5txEKEVvLQb4=
+SIZE (pari-2.7.1.tar.gz) = 3140893
Index: patches/patch-Configure
===
RCS file: patches/patch-Configure
diff -N patches/patch-Configure
--- patches/patch-Configure 30 Apr 2008 19:42:07 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,40 +0,0 @@
-$OpenBSD: patch-Configure,v 1.2 2008/04/30 19:42:07 naddy Exp $
Configure.orig Thu Nov 25 16:58:25 2004
-+++ Configure Mon Apr 28 20:14:36 2008
-@@ -844,7 +844,7 @@ if test -n $__gnuc__; then
- esac
- ;;
- esac
-- OPTFLAGS=$OPTFLAGS -DGCC_INLINE $warn
-+ OPTFLAGS=$CFLAGS -DGCC_INLINE $warn
- DBGFLAGS=-g $warn
- # Some architectures need -fPIC for building dynamic lib
- case $osname-$arch in hpux-*) DLCFLAGS=-fPIC;; esac
-@@ -1006,7 +1006,7 @@ if test $optimization = profiling; then DLLD=; else
- #aix-*) DLSUFFIX=a ;; dynamic linking does not work!
- sunos-*) sodest=$VersionMajor$VersionMinor.$patch
- soname=$sodest;;
--gnu-*|*-alpha|solaris-*|linux-*|freebsd-*)
-+gnu-*|solaris-*|linux-*|freebsd-*)
- case $libpari_base in
- pari) sodest=$version.$patch;; # released versions
- *) sodest=$patch.0.0;; # unstable versions
-@@ -1044,10 +1044,6 @@ if test -n $DLLD; then
- freebsd-*) DLLDFLAGS=-Bshareable -x ;;
- gnu-*|linux-*)DLLDFLAGS=-shared -soname \$(LIBPARI_SONAME) ;;
- irix
Re: NEW: lang/pure
On Thu, Jun 12, 2014 at 09:04:20PM +1000, Anders Jensen-Waud wrote: On 12 Jun 2014, at 4:30 pm, Sebastien Marie semarie-open...@latrappe.fr wrote: On Thu, Jun 12, 2014 at 03:25:37PM +1000, Anders Jensen-Waud wrote: portcheck(1) complains: LIB_DEPENDS devel/llvm not needed for lang/pure ? Sure it is LIB_DEPENDS ? and not a BUILD_ and/or RUN_DEPENDS ? OK, so I have fixed the port now based on your recommendations. The Makefile now has: SHARED_LIBS += pure 0.0 # 8.0 ... which should theoretically do the job. However, when I run the ``make port-lib-depends-check'', I get the following error: # make port-lib-depends-check Asking ports for dependency llvm-3.3p3(devel/llvm) pure-0.60(lang/pure): Missing lib: libpure.so.8 (/usr/local/bin/pure) (NOT REACHABLE) *** Error 1 in target 'port-lib-depends-check' (ignored) Is there any reason for that error message when I have explicitly specified version 0.0? Also specifying version 8.0 generates a similar check error. Changing the version in the Makefile don't always change the version in the ports itself. Patching may be needed, depending how the ports was made by upstream. Please note another problem with your ports tree: your version of llvm is llvm-3.3p3, which is not the latest ports tree (llvm-3.5p3). Next, under which arch do you work ? amd64 ? My first post mention build error under i386. And as I couldn't build the port, I couldn't look for problem with files generated by the build :-) Thanks. -- Sébastien Marie
packages snapshots signed with wrong key
Hi, Short story: the latest package snapshost (i386) is signed with 55pkg.pub, but the @signer in +CONTENTS is 54pkg. Long story: I upgraded to (near) latest base system (OpenBSD bert.local 5.5 GENERIC.MP#217 i386). And I tried to update my ports too, via packages. My mirror is ftp://mirror.esc7.net/pub/OpenBSD/snapshots/packages/i386/ It should be same state as ftp.openbsd.org (having same SHA256 in directory). # pkg_add -aui pub fp: UQW0HmnVm5k= sig fp: qMGXBLsGJhI= signify: verification failed: checked against wrong key system(/usr/bin/signify, -p, /etc/signify/54pkg.pub, -V, -m, /tmp/pkgcontent.8ERtOK64G) failed: exit(1) --- +quirks-1.106 --- Bad signature Fatal error: quirks-1.106 is corrupted at /usr/libdata/perl5/OpenBSD/PkgAdd.pm line 659. To be sure about the error, I test the following: # /usr/bin/signify -p /etc/signify/54pkg.pub -V -m /tmp/pkgcontent.8ERtOK64G pub fp: UQW0HmnVm5k= sig fp: qMGXBLsGJhI= signify: verification failed: checked against wrong key OK, the key 54pkg is not the signer. # /usr/bin/signify -p /etc/signify/55pkg.pub -V -m /tmp/pkgcontent.8ERtOK64G # So no error with 55pkg.pub, so the 55pkg is the signer. But in the package, the registered signer is 54pkg. # head /tmp/pkgcontent.8ERtOK64G @comment $OpenBSD: PLIST,v 1.2 2011/07/14 09:53:58 espie Exp $ @name quirks-1.106 @signer 54pkg @digital-signature signify:2014-01-14T21:43:38Z @option always-update @comment pkgpath=devel/quirks cdrom=yes ftp=yes @arch * +DESC @sha ZcShuBxD9cPsWmJce9rnoKKlC4qYQve7PwElfX/uk8Q= @size 348 Thanks. -- Sébastien Marie
[patch] ports using @{,un}exec with LOCALBASE supposed in PATH
Hi,
During snapshot update, I encounter this problem:
guile-1.8.8p3:slib-3b1-3b4p0: ok
/bin/sh: guile: not found
system(/bin/sh, -c, guile -c (use-modules (ice-9 slib)) (require 'printf))
failed: exit(127)
guile-1.8.8p1-1.8.8p3: ok
It is due to @exec in pkg/PLIST:
@comment force the creation of slibcat
@exec guile -c (use-modules (ice-9 slib)) (require 'printf)
and because my script for pkg_add -u don't include /usr/local in PATH.
Should be better to don't use search path for @exec ? Specially when
LOCALBASE is supposed to be included ?
If it is ok, here a patch for several others ports that relied on
LOCALBASE in PATH for @exec/@unexec:
- devel/doc++
- graphics/asymptote
- lang/guile
- print/texlive
Please note, that there are others ports that relied on system base (for
chmod, ln, rm, install-info, cp...), but I suppose it is safe to suppose
/bin or /usr/bin are in PATH.
Below a patch for the 4 ports listed before. For all except guile,
there used mktexlsr, so assure that TEXMFMAIN is setted to good
directory (like others ports using mktexlsr does).
--
Sébastien Marie
Index: Makefile
===
RCS file: /cvs/ports/devel/doc++/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- Makefile11 Mar 2013 10:50:03 - 1.20
+++ Makefile11 Dec 2013 05:50:26 -
@@ -3,7 +3,7 @@
COMMENT= documentation system for C, C++, IDL and Java
DISTNAME= doc++-3.4.10
-REVISION = 2
+REVISION = 3
CATEGORIES=devel
HOMEPAGE= http://docpp.sourceforge.net/
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/doc++/pkg/PLIST,v
retrieving revision 1.8
diff -u -p -r1.8 PLIST
--- pkg/PLIST 11 Aug 2007 10:44:24 - 1.8
+++ pkg/PLIST 11 Dec 2013 05:50:26 -
@@ -48,5 +48,5 @@ share/texmf/tex/latex/doc++/docxx-fr.sty
share/texmf/tex/latex/doc++/docxx-ja.sty
share/texmf/tex/latex/doc++/docxx-ro.sty
share/texmf/tex/latex/doc++/docxx.sty
-@exec mktexlsr /dev/null 21
-@unexec mktexlsr /dev/null 21
+@exec TEXMFMAIN=%D/share/texmf %D/bin/mktexlsr /dev/null 21
+@unexec TEXMFMAIN=%D/share/texmf %D/bin/mktexlsr /dev/null 21
Index: Makefile
===
RCS file: /cvs/ports/graphics/asymptote/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile25 Nov 2013 14:16:22 - 1.14
+++ Makefile11 Dec 2013 05:50:26 -
@@ -4,7 +4,7 @@ COMMENT=powerful descriptive vector gr
DISTNAME= asymptote-2.10.src
PKGNAME= ${DISTNAME:S/.src//g}
-REVISION = 5
+REVISION = 6
CATEGORIES=graphics
HOMEPAGE= http://asymptote.sourceforge.net/
Index: pkg/PLIST
===
RCS file: /cvs/ports/graphics/asymptote/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -r1.3 PLIST
--- pkg/PLIST 1 Aug 2011 11:35:34 - 1.3
+++ pkg/PLIST 11 Dec 2013 05:50:26 -
@@ -444,5 +444,5 @@ share/texmf/tex/latex/asymptote/asycolor
share/texmf/tex/latex/asymptote/asymptote.sty
share/texmf/tex/latex/asymptote/latexmkrc
share/texmf/tex/latex/asymptote/ocg.sty
-@exec mktexlsr /dev/null 21
-@unexec-delete mktexlsr /dev/null 21
+@exec TEXMFMAIN=%D/share/texmf %D/bin/mktexlsr /dev/null 21
+@unexec-delete TEXMFMAIN=%D/share/texmf %D/bin/mktexlsr /dev/null 21
Index: Makefile
===
RCS file: /cvs/ports/lang/guile/Makefile,v
retrieving revision 1.43
diff -u -p -r1.43 Makefile
--- Makefile8 Dec 2013 12:21:09 - 1.43
+++ Makefile11 Dec 2013 05:50:26 -
@@ -4,7 +4,7 @@ COMMENT=GNU's Ubiquitous Intelligent La
VERSION= 1.8.8
DISTNAME= guile-${VERSION}
-REVISION= 3
+REVISION= 4
SHARED_LIBS= guile 20.0 \
guile-srfi-srfi-1-v-3 3.2 \
guile-srfi-srfi-13-14-v-3 3.1 \
Index: pkg/PLIST
===
RCS file: /cvs/ports/lang/guile/pkg/PLIST,v
retrieving revision 1.14
diff -u -p -r1.14 PLIST
--- pkg/PLIST 8 Dec 2013 12:21:09 - 1.14
+++ pkg/PLIST 11 Dec 2013 05:50:26 -
@@ -306,5 +306,5 @@ share/guile/${V}/srfi/srfi-88.scm
share/guile/${V}/srfi/srfi-9.scm
share/guile/slib
@comment force the creation of slibcat
-@exec guile -c (use-modules (ice-9 slib)) (require 'printf)
+@exec %D/bin/guile -c (use-modules (ice-9 slib)) (require 'printf)
@unexec rm %D/share/guile/${V}/slibcat
Index: base/Makefile
===
RCS file: /cvs/ports/print/texlive/base/Makefile,v
retrieving revision 1.69
diff -u -p -r1.69 Makefile
--- base/Makefile 9 Nov 2013 18:22:02 - 1.69
+++ base/Makefile 11 Dec 2013 05:50:27 -
@@ -4,7 +4,7 @@ COMMENT
qt4 apps broken
Hi, I just upgrade my ports to -current (dmesg below), but I have problems with qt4 applications. For example, starting qtconfig4 (which is packaged in qt4-4.8.5) result of X11 error: $ qtconfig4 X Error: BadAccess (attempt to access private resource denied) 10 Extension:130 (MIT-SHM) Minor opcode: 1 (X_ShmAttach) Resource id: 0x180 X Error: BadShmSeg (invalid shared segment parameter) 128 Extension:130 (MIT-SHM) Minor opcode: 5 (X_ShmCreatePixmap) Resource id: 0x81 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x1800010 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x1800010 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x1800010 ... and the window is just a plain rectangle... Same problem occurs for others qt4 applications (as vlc or keepassx). Is it a known problem ? or it is just me ? I don't think about dependency problem as qtconfig4 is affected too, and my system seems clean (pkg_check ok, no .libs-qt4-*). Thanks for your help. -- Sébastien Marie OpenBSD 5.4-current (GENERIC.MP) #70: Tue Oct 1 12:57:28 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Genuine Intel(R) CPU T2400 @ 1.83GHz (GenuineIntel 686-class) 1.83 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF real mem = 2137399296 (2038MB) avail mem = 2090733568 (1993MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 06/13/07, BIOS32 rev. 0 @ 0xffa10, SMBIOS rev. 2.4 @ 0xf7980 (44 entries) bios0: vendor Dell Inc. version A17 date 06/13/2007 bios0: Dell Inc. MM061 acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC MCFG SLIC BOOT SSDT acpi0: wakeup devices LID_(S3) PBTN(S4) MBTN(S5) PCI0(S3) USB0(S0) USB1(S0) USB2(S0) USB3(S0) EHCI(S0) AZAL(S3) PCIE(S4) RP01(S4) RP02(S3) RP03(S3) RP04(S3) RP05(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 166MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Genuine Intel(R) CPU T2400 @ 1.83GHz (GenuineIntel 686-class) 1.83 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2 acpimcfg0 at acpi0 addr 0xf000, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 3 (PCIE) acpiprt3 at acpi0: bus 11 (RP01) acpiprt4 at acpi0: bus -1 (RP02) acpiprt5 at acpi0: bus -1 (RP03) acpiprt6 at acpi0: bus 12 (RP04) acpiprt7 at acpi0: bus -1 (RP05) acpiprt8 at acpi0: bus -1 (RP06) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpitz0 at acpi0: critical temperature is 126 degC acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT0 model DELLUD2649 serial 878 type LION oem Sanyo acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: PBTN acpibtn2 at acpi0: SBTN acpivideo0 at acpi0: VID_ acpivideo1 at acpi0: VID_ acpivout0 at acpivideo1: LCD_ acpivideo2 at acpi0: VID2 bios0: ROM list: 0xc/0xe800! 0xce800/0x1800 cpu0: Enhanced SpeedStep 1829 MHz: speeds: 1833, 1333, 1000 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03 vga1 at pci0 dev 2 function 0 Intel 82945GM Video rev 0x03 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1280x800 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 82945GM 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: Sigmatel STAC9200, Conexant/0x2bfa, using Sigmatel STAC9200 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x01: apic 2 int 16 pci1 at ppb0 bus 11 wpi0 at pci1 dev 0 function 0 Intel PRO/Wireless 3945ABG rev 0x02: msi, MoW2, address 00:13:02:2e:8b:46 ppb1 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x01: apic 2 int 19 pci2 at ppb1 bus 12 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x01: apic 2 int 20 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x01: apic 2 int 21 uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x01: apic 2 int 22 uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x01: apic 2 int 23 ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x01: apic 2 int 20 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb2 at pci0 dev 30 function 0
Re: qt4 apps broken
On Wed, Oct 09, 2013 at 04:43:09PM +0200, Marc Espie wrote: On Wed, Oct 09, 2013 at 04:03:01PM +0200, Sébastien Marie wrote: Same problem occurs for others qt4 applications (as vlc or keepassx). vlc and keepassx are NOT qt4 apps. not agreed. keepassx is linked to qt4 $ ldd /usr/local/bin/keepassx /usr/local/bin/keepassx: StartEnd Type Open Ref GrpRef Name 1c00 3c03c000 exe 10 0 /usr/local/bin/keepassx 0cd28000 2cf6 rlib 01 0 /usr/local/lib/qt4/libQtGui.so.10.1 068cd000 268dd000 rlib 01 0 /usr/local/lib/qt4/libQtXml.so.8.0 019d2000 21ac6000 rlib 03 0 /usr/local/lib/qt4/libQtCore.so.9.0 074e5000 27563000 rlib 07 0 /usr/X11R6/lib/libX11.so.16.0 038a1000 238a5000 rlib 01 0 /usr/X11R6/lib/libXtst.so.11.0 0b27a000 2b2a8000 rlib 04 0 /usr/lib/libstdc++.so.56.0 0ee6b000 2ee74000 rlib 06 0 /usr/lib/libm.so.9.0 00dcc000 20dfc000 rlib 01 0 /usr/lib/libc.so.70.0 04eb2000 24eca000 rlib 02 0 /usr/X11R6/lib/libfreetype.so.21.0 0bbec000 2bbf rlib 01 0 /usr/X11R6/lib/libSM.so.9.0 094a3000 294aa000 rlib 02 0 /usr/X11R6/lib/libICE.so.10.0 07197000 2719b000 rlib 02 0 /usr/X11R6/lib/libXi.so.12.0 0d73f000 2d743000 rlib 01 0 /usr/X11R6/lib/libXrender.so.6.0 0edf3000 2edf7000 rlib 01 0 /usr/X11R6/lib/libXinerama.so.6.0 0d75 2d761000 rlib 01 0 /usr/X11R6/lib/libfontconfig.so.9.0 0be4d000 2be51000 rlib 04 0 /usr/X11R6/lib/libXext.so.13.0 0b0f4000 2b0f8000 rlib 02 0 /usr/local/lib/libgthread-2.0.so.3800.0 07012000 27067000 rlib 04 0 /usr/local/lib/libglib-2.0.so.3800.0 01ed9000 21edd000 rlib 05 0 /usr/local/lib/libintl.so.6.0 0a359000 2a361000 rlib 01 0 /usr/local/lib/libpng.so.17.1 05972000 25979000 rlib 04 0 /usr/lib/libz.so.5.0 0e639000 2e646000 rlib 01 0 /usr/local/lib/libgobject-2.0.so.3800.0 0d746000 2d74b000 rlib 07 0 /usr/lib/libpthread.so.18.0 0f45b000 2f53b000 rlib 05 0 /usr/local/lib/libiconv.so.6.0 0696e000 26973000 rlib 06 0 /usr/X11R6/lib/libxcb.so.3.0 09b4b000 29b5 rlib 01 0 /usr/lib/libexpat.so.11.0 002ef000 202f3000 rlib 02 0 /usr/X11R6/lib/libpthread-stubs.so.2.0 04d1c000 24d32000 rlib 03 0 /usr/local/lib/libpcre.so.3.0 0b3ef000 2b3f3000 rlib 01 0 /usr/local/lib/libffi.so.0.0 0067c000 2068 rlib 01 0 /usr/X11R6/lib/libXau.so.10.0 07e17000 27e1c000 rlib 01 0 /usr/X11R6/lib/libXdmcp.so.11.0 044a7000 044a7000 rtld 01 0 /usr/libexec/ld.so GUI interface of vlc is qt4 $ vlc [0x7e075230] main xml reader error: XML reader not found Blocked: call to unsetenv(DBUS_ACTIVATION_ADDRESS) Blocked: call to unsetenv(DBUS_ACTIVATION_BUS_TYPE) [0x86e5b530] main libvlc: Lancement de vlc avec l'interface par défaut. Utilisez « cvlc » pour démarrer VLC sans interface. Blocked: call to setlocale(0, ) [0x7e0732b0] qt4 interface error: Unable to load extensions module X Error: BadAccess (attempt to access private resource denied) 10 Extension:130 (MIT-SHM) Minor opcode: 1 (X_ShmAttach) Resource id: 0x180 X Error: BadShmSeg (invalid shared segment parameter) 128 Extension:130 (MIT-SHM) Minor opcode: 5 (X_ShmCreatePixmap) Resource id: 0x81 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x1c00016 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x1c00016 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x1c00016 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x1c00016 X Error: BadPixmap (invalid Pixmap parameter) 4 Major opcode: 54 (X_FreePixmap) Resource id: 0x1c00016 X Error: BadShmSeg (invalid shared segment parameter) 128 Extension:130 (MIT-SHM) Minor opcode: 2 (X_ShmDetach) Resource id: 0x1c00016 first thing to debug that would be to tell us what your xserver says. Like, does it have all extensions it's supposed to ? ok, sorry to have omit X log dmesg + X log may help. The dmesg was already include in first mail, so I don't re-include it here. No error in X log. --- /var/log/Xorg.0.log --- [25.480] (--) checkDevMem: using aperture driver /dev/xf86 [25.495] (--) Using wscons driver on /dev/ttyC4 in pcvt compatibility mode (version 3.32) [25.632] X.Org X Server 1.14.2 Release Date: 2013-06-25 [25.632] X Protocol Version 11, Revision 0 [25.632] Build
Re: qt4 apps broken
On Wed, Oct 09, 2013 at 05:57:13PM +0200, Giovanni Bechis wrote:
On 10/09/13 17:54, Matthieu Herrb wrote:
On Wed, Oct 09, 2013 at 04:47:41PM +0200, Giovanni Bechis wrote:
On 10/09/13 16:32, Stuart Henderson wrote:
On 2013/10/09 16:03, Sébastien Marie wrote:
Hi,
I just upgrade my ports to -current (dmesg below), but I have problems
with qt4 applications.
For example, starting qtconfig4 (which is packaged in qt4-4.8.5) result
of X11 error:
Confirmed (and on amd64 here, so it's not just a problem with a particular
pkg snap).
With this snapshot and inteldrm is working fine:
OpenBSD 5.4-current (GENERIC.MP) #65: Thu Oct 3 18:48:14 MDT 2013
How are you starting X (xdm, gdm, startx, ... ? )
I am using xdm(1).
me too.
My .xsession is basically like that:
xset dpms 120 120 120
#some toolbar with dzen2
setxkbmap -model pc105 -layout fr -variant latin9
#dbus
if [ -z ${DBUS_SESSION_BUS_ADDRESS} ]; then
eval `dbus-launch --sh-syntax --exit-with-session`
fi
exec /usr/X11R6/bin/cwm
--
Sébastien Marie
Re: qt4 apps broken
On Wed, Oct 09, 2013 at 06:25:32PM +0200, Giovanni Bechis wrote: On 10/09/13 18:16, Stuart Henderson wrote: I'm using xdm, wm is cwm, new mesa, packages built against new mesa, inteldrm My qt4 version is qt4-4.8.2p7, maybe the problem is related to the qt4 packages update. Cheers Giovanni This qt4 version is what I have before update... and it works well. But the latest in snapshots is qt4-4.8.5, and the problem occurs starting with this version (4.8.5). -- Sébastien Marie
Re: qt4 apps broken
On Wed, Oct 09, 2013 at 07:15:10PM +0200, Matthieu Herrb wrote: On Wed, Oct 09, 2013 at 07:01:46PM +0200, Sébastien Marie wrote: On Wed, Oct 09, 2013 at 06:25:32PM +0200, Giovanni Bechis wrote: On 10/09/13 18:16, Stuart Henderson wrote: I'm using xdm, wm is cwm, new mesa, packages built against new mesa, inteldrm My qt4 version is qt4-4.8.2p7, maybe the problem is related to the qt4 packages update. Cheers Giovanni This qt4 version is what I have before update... and it works well. But the latest in snapshots is qt4-4.8.5, and the problem occurs starting with this version (4.8.5). So this means that the previous version used less strict permissions on shared memory segments. You can check them with ipcs(8). in a term: $ qtconfig4 [... errors ...] in another: $ ipcs Message Queues: T ID KEYMODE OWNERGROUP Shared Memory: T ID KEYMODE OWNERGROUP m 262151 0 --rwa-- semarie semarie Semaphores: T ID KEYMODE OWNERGROUP It means a new patch for qt4... From changes-4.8.5 (in qt-everywhere-opensource-src-4.8.5): General Improvements - Change all shmget calls to user-only memory (security) So yes, the problem is due to qt4, which use more strict permissions for shmget. Thanks. -- Sébastien Marie
Re: lang/chicken: need some advices
On Mon, Apr 22, 2013 at 12:32:12PM +0300, Timo Myyrä wrote: I've had WIP port of chicken in the openbsd-wip tree for a while: https://github.com/jasperla/openbsd-wip/tree/master/lang/chicken I will take a look. Thanks. I haven't yet found a way to properly address the shared library version. The installed version number is correct in the port but the deployment doesn't work. It still uses the old binary version. If I modify csc.scm copy-libraries function to use .6.0 then the build fails. I think, it is because of csc.c need to be regenerated from csc.scm. (Makefile rules try to rebuild it atomatically). But for that it need chicken to be installed (or just chicken-boot). I didn't notice anything else wrong in my port. As your BINARYVERSION is upstream, this reduce worng things to append now: I think only deploy should be impacted: the library isn't found as the name that chicken expects is not used. In my case, I try to redefine BINARYVERSION to LIBchicken_VERSION, in order to keep extensions in correct directory. This expose more problems now, but link more efficiently extensions with library: what would append if you need to bump LIBchicken_VERSION whereas BINARYVERSION remains the same ? Extensions still leave here, whereas they may be incompatibles. -- Sébastien Marie
lang/chicken: need some advices
Hi,
I start to look at lang/chicken in ports. Currently it is near 6 years
old.
But I encourter the following problem: chicken generate and use a shared
lib with only a major number for the version (lib/libchicken.so.6 from
upstream). It is the BINARYVERSION=6 in defaults.make file. It is
also used in directory name for extensions (some are provided by
default): lib/chicken/6 .
According to the ports guide, porters should rewrites the library
version to correctly keep track of ABI changes.
My problem is chicken expects BINARYVERSION to be an integer, and use it
as integer for:
- found the library when deploying application (copy the file in a
target directory)
- use it in extensions-directory-name (lib/chicken/6/...) when managing
extensions (install an extension as unprivilegied user).
But 2.0 casted to integer is 2... so I couldn't satisfy OpenBSD
requirement (major+minor) without patching chicken to do the program use
a string instead of an integer. Am I right, here ?
*But*, patching chicken is patching scheme source. And need
first bootstrapping chicken... The upstream tarball contains scheme
source + compiled-c-files, and offer the possibility to bootstrap the
compiler first.
But if I patch scheme files before building chicken-boot (the
bootstrapping compiler), the makefile wants to regenerate C file
(whereas the bootstrapping compiler is not yet here).
So how to achieve this ?
- have another port lang/chicken-boot (only used in BUILD_DEPENDS of
lang/chiken) ? (or hierarchy like lang/chicken/boot for bootstrap and
lang/chiken/stable for stable release ?)
- does exist a possibility in ports to first build something before
patching ?
- does it possible to keep BINARYVERSION as integer ? According to the
chicken wiki, they take care to do the right thing with version
number: Changes that break C-level compatibility (for example by
modifying the signature of an exported C routine) will require
bumping up the binary compatibility version (BINARYVERSION in
defaults.make).)
But SHARED_LIBS doesn't seems support major only version
(make update-plist isn't agreed) .
- another solution ?
I join my current diff of the ports.
And a other question: the chicken Makefile contains a check for OpenBSD
to remove a gcc option: OpenBSD base still uses GCC 3.3.5 which does
not support -fwrapv. Does OpenBSD still have somes archs with GCC
3.3.5 (or that don't support -fwrapv option) ?
Thanks.
--
Sébastien Marie
Index: Makefile
==
--- Makefile
+++ Makefile
@@ -1,41 +1,60 @@
# $OpenBSD: Makefile,v 1.21 2013/03/21 08:46:32 ajacoutot Exp $
COMMENT= practical and portable Scheme system
-DISTNAME= chicken-2.6
+BASE_VERSION= 4.8.0
+VERSION= 3
+
+DISTNAME= chicken-${BASE_VERSION}.${VERSION}
EPOCH= 0
-SHARED_LIBS += chicken 1.0 # .0.0
-SHARED_LIBS += uchicken 1.0 # .0.0
+SHARED_LIBS += chicken 2.0 # 6
CATEGORIES=lang
-HOMEPAGE= http://www.call-with-current-continuation.org/
+HOMEPAGE= http://www.call-cc.org/
-MASTER_SITES= ${HOMEPAGE}
+MASTER_SITES= http://code.call-cc.org/releases/${BASE_VERSION}/
# BSD
PERMIT_PACKAGE_CDROM= Yes
WANTLIB += c m pthread
USE_GMAKE= Yes
-USE_GROFF =Yes
+
+# test works only after installation
+TEST_DEPENDS= ${FULLPKGNAME}:${BUILD_PKGPATH}
+TEST_TARGET= check
+
+MAKE_FILE =GNUmakefile
+
+MAKE_ENV +=PLATFORM=bsd
+
+# if in MAKE_ENV, the build system override variables
+MAKE_FLAGS += PREFIX=${TRUEPREFIX} \
+ ${DESTDIRNAME}=${WRKINST} \
+ TOPMANDIR=${PREFIX}/man \
+ DOCDIR=${PREFIX}/share/doc/chicken \
+ BINARYVERSION=${LIBchicken_VERSION}
+
+.include bsd.port.arch.mk
+
+.if defined(NO_SHARED_LIBS) ${NO_SHARED_LIBS:L} == yes
+
+# TODO:
+# - need more testing
+# - remove man page of not compiled program
(chicken-{install,uninstall,status})
+#
+MAKE_FLAGS += STATICBUILD=1
-LIB_DEPENDS += devel/libffi
-WANTLIB += ffi
+.else
-CONFIGURE_STYLE= gnu
-CONFIGURE_ARGS=${CONFIGURE_SHARED}
-CONFIGURE_ENV= CPPFLAGS=-I${LOCALBASE}/include -pthread \
- LDFLAGS=-L${LOCALBASE}/lib -pthread
+# chicken expect BINARYVERSION is an integer, and it uses it for found the
library
+post-install:
+ ln -s libchicken.so.${LIBchicken_VERSION} \
+ ${PREFIX}/lib/libchicken.so.${LIBchicken_VERSION:C/\.[^.]*$//}
-TEST_TARGET= bench
-TEST_DEPENDS= ${FULLPKGNAME}:lang/chicken
-
-CFLAGS+= -I${LOCALBASE}/include
-
-pre-configure:
- ${SUBST_CMD} ${WRKSRC}/cscbench.scm
+.endif
.include bsd.port.mk
Index: distinfo
==
--- distinfo
+++ distinfo
@@ -1,5 +1,2 @@
-MD5 (chicken-2.6.tar.gz
Re: [bug] chromium problem since 26.0.1410.43 (and 26.0.1410.63 too)
On Thu, Apr 11, 2013 at 05:11:15AM +, Ted Unangst wrote:
On Mon, Apr 08, 2013 at 07:23, Robert Nagy wrote:
It seems to be a different issue which is not related to chromium itself.
It is being investigated. I assume you have been trying on i386?
Robert, could you tell to me some hints about you point of vue on this ?
Why it seems to you that it is not related to chromium itself ?
I suspect you don't need this, but to fill out a few details in case anybody
else is seeing crashes, they can confirm this is the same problem.
I see this on i386 with chromium-26.0.1410.43-proprietary.
I upgrade chromium to chromium-26.0.1410.63-proprietary, and I always
have problems (but it seems to occurs less often ? not sure). I am on
i386.
Opening a new tab displays the sad tab and this on console:
[6692:-2104363520:0411/005739:ERROR:user_style_sheet_watcher.cc(174)] Failed
to setup watch for /home/tedu/.config/chromium/Default/User
StyleSheets/Custom.css
I have this error only at start time (Sad tab or not).
Visiting www.openbsd.org works as expected.
Visiting www.apple.com displays the sad tab and this (repeating):
[5303:600661216:0411/005904:ERROR:omnibox_view_gtk.cc(431)] Not implemented
reached in virtual void OmniboxViewGtk::ApplyCaretVisibility()
I have this error on console when focus enter the URL bar.
The sad tab seems to occurs (randomly: not every time):
- on some static big page
(http://ftp.fr.openbsd.org/pub/OpenBSD/snapshots/packages/i386/)
- simple page with javascript (http://www.openbsdfoundation.org/)
But very less often (I only saw one crash during testing) on simples pages
without js
like http://www.openbsd.org/.
I reliably obtain a crash (a chrome.core, but without sad tab) when I open
the javascript
console (Ctrl+Maj+J): the panel of console is all white.
Runing as env G_SLICE=always-malloc chrome helps a little, but not really.
It's still pretty useless.
I don't remark very less crash with it.
For testing, I always start a fresh chrome session (rm -rf
${HOME}/{.cache,.config}/chromium). So none personal extensions or
settings are in use.
--
Sébastien Marie
OpenBSD 5.3-current (GENERIC.MP) #117: Mon Apr 8 07:32:44 MDT 2013
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Genuine Intel(R) CPU T2400 @ 1.83GHz (GenuineIntel 686-class) 1.83 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF
real mem = 2137399296 (2038MB)
avail mem = 2091044864 (1994MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 03/09/06, BIOS32 rev. 0 @ 0xffa10, SMBIOS
rev. 2.4 @ 0xf7b70 (44 entries)
bios0: vendor Dell Inc. version A03 date 03/09/2006
bios0: Dell Inc. MM061
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG BOOT SSDT
acpi0: wakeup devices LID_(S3) PBTN(S4) PCI0(S3) USB0(S0) USB1(S0) USB2(S0)
USB3(S0) EHCI(S0) CH31(S0) AZAL(S3) PCIE(S4) RP01(S4) RP02(S3) RP03(S3)
RP04(S3) RP05(S3) RP06(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 166MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU T2400 @ 1.83GHz (GenuineIntel 686-class) 1.83 GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 3 (PCIE)
acpiprt3 at acpi0: bus 11 (RP01)
acpiprt4 at acpi0: bus -1 (RP02)
acpiprt5 at acpi0: bus -1 (RP03)
acpiprt6 at acpi0: bus 12 (RP04)
acpiprt7 at acpi0: bus -1 (RP05)
acpiprt8 at acpi0: bus -1 (RP06)
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpitz0 at acpi0: critical temperature is 126 degC
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model DELLUD2649 serial 878 type LION oem Sanyo
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PBTN
acpibtn2 at acpi0: SBTN
acpivideo0 at acpi0: VID_
acpivideo1 at acpi0: VID_
acpivideo2 at acpi0: VID2
bios0: ROM list: 0xc/0xe800! 0xce800/0x1800
cpu0: Enhanced SpeedStep 1829 MHz: speeds: 1833, 1333, 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03
vga1 at pci0 dev 2 function 0 Intel 82945GM Video rev 0x03
intagp0 at vga1
agp0 at intagp0: aperture at 0xc000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: apic 2 int 16
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
Intel 82945GM Video rev 0x03 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0
Re: [bug] chromium problem since 26.0.1410.43
On Mon, Apr 08, 2013 at 07:23:23AM +0200, Robert Nagy wrote: It seems to be a different issue which is not related to chromium itself. It is being investigated. I assume you have been trying on i386? Yes, I am on i386. If it help, my full dmesg was attached in a previous mail. If I could help, please to let me known. Thanks. -- Sébastien Marie
[bug] chromium problem since 26.0.1410.43
Hi, After switching chrome from chromium-25.0.1364.173p1-proprietary to 26.0.1410.43-proprietary , I start having problems in chromium: tabs crash randomly (near every time, but not all the time)... The chrome.core is seems very useless: (gdb) bt #0 0x4460a37e in ?? () #1 0x in ?? () I have same result with clean settings (cd ~/.config ; mv chromium my_chromium) On console, I have these errors message: [8187:-1993597184:0407/132937:ERROR:user_style_sheet_watcher.cc(174)] Failed to setup watch for /home/semarie/.config/chromium/Default/User StyleSheets/Custom.css [8187:687373536:0407/132938:ERROR:omnibox_view_gtk.cc(431)] Not implemented reached in virtual void OmniboxViewGtk::ApplyCaretVisibility() (with multiple omnibox_view_gtk) But it is not seems linked with the crash: for example, omnibox_view_gtk error also occurs with new tab (and when no crash). The crash could occurs: - at load time (the page start rendering, and Aw, snap message) - after some time (page loaded, tab in background, and after some time it dead) - tab could be unusable: all white without Aw, snap - and all of that not only on website, but also on chrome://settings for example. The cvs log mentions: - use clang/llvm instead of gcc - switch back to the internal libvpx - re-enable SSE2 support So I am rebuilding without SSE2, as first try. But it should take some time before I could testing :-), any ideas ? Thanks. -- Sébastien Marie OpenBSD 5.3-current (GENERIC.MP) #110: Thu Apr 4 10:08:08 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Genuine Intel(R) CPU T2400 @ 1.83GHz (GenuineIntel 686-class) 1.83 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF real mem = 2137399296 (2038MB) avail mem = 2091040768 (1994MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 03/09/06, BIOS32 rev. 0 @ 0xffa10, SMBIOS rev. 2.4 @ 0xf7b70 (44 entries) bios0: vendor Dell Inc. version A03 date 03/09/2006 bios0: Dell Inc. MM061 acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG BOOT SSDT acpi0: wakeup devices LID_(S3) PBTN(S4) PCI0(S3) USB0(S0) USB1(S0) USB2(S0) USB3(S0) EHCI(S0) CH31(S0) AZAL(S3) PCIE(S4) RP01(S4) RP02(S3) RP03(S3) RP04(S3) RP05(S3) RP06(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 166MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Genuine Intel(R) CPU T2400 @ 1.83GHz (GenuineIntel 686-class) 1.83 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2 acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 3 (PCIE) acpiprt3 at acpi0: bus 11 (RP01) acpiprt4 at acpi0: bus -1 (RP02) acpiprt5 at acpi0: bus -1 (RP03) acpiprt6 at acpi0: bus 12 (RP04) acpiprt7 at acpi0: bus -1 (RP05) acpiprt8 at acpi0: bus -1 (RP06) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpitz0 at acpi0: critical temperature is 126 degC acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT0 model DELLUD2649 serial 878 type LION oem Sanyo acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: PBTN acpibtn2 at acpi0: SBTN acpivideo0 at acpi0: VID_ acpivideo1 at acpi0: VID_ acpivideo2 at acpi0: VID2 bios0: ROM list: 0xc/0xe800! 0xce800/0x1800 cpu0: Enhanced SpeedStep 1829 MHz: speeds: 1833, 1333, 1000 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03 vga1 at pci0 dev 2 function 0 Intel 82945GM Video rev 0x03 intagp0 at vga1 agp0 at intagp0: aperture at 0xc000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: apic 2 int 16 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 82945GM 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: Sigmatel STAC9200, Conexant/0x2bfa, using Sigmatel STAC9200 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x01: apic 2 int 16 pci1 at ppb0 bus 11 wpi0 at pci1 dev 0 function 0 Intel PRO/Wireless 3945ABG rev 0x02: msi, MoW2, address 00:13:02:2e:8b:46 ppb1 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x01: apic 2 int 19 pci2 at ppb1 bus 12 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x01: apic 2 int 20 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x01: apic 2 int 21 uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x01: apic 2 int 22 uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev
Re: [bug] chromium problem since 26.0.1410.43
On Sun, Apr 07, 2013 at 01:55:49PM +0200, Sébastien Marie wrote: Hi, After switching chrome from chromium-25.0.1364.173p1-proprietary to 26.0.1410.43-proprietary , I start having problems in chromium: tabs crash randomly (near every time, but not all the time)... [...] The cvs log mentions: - use clang/llvm instead of gcc - switch back to the internal libvpx - re-enable SSE2 support So I am rebuilding without SSE2, as first try. But it should take some time before I could testing :-), any ideas ? Rebuilding without SSE2 support (-Ddisable_sse2=1) results to same problems. I rebuild using gcc4 instead of clang, but if someone have any clue to help target the problem, advices are welcome! Thanks. -- Sébastien Marie
problem with bsd.port.mk and readonly /usr/ports
Hi,
I start having a problem with recent bsd.port.mk in ports, that seems
related to readonly /usr/ports partition.
My bsd.port.mk is 1.1208.
The base is (on i386):
OpenBSD 5.3-beta (GENERIC.MP) #25: Fri Feb 1 16:35:30 MST 2013
bert:/usr/ports/textproc/groff# make clean
=== Cleaning for groff-1.21p8
rm: /usr/ports/textproc/groff/w-groff-1.21: Read-only file system
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2859
'_internal-clean': @rm -rf /usr/ports/textproc/groff/w-groff-1.21)
*** Error 1 in /usr/ports/textproc/groff
(/usr/ports/infrastructure/mk/bsd.port.mk:2342 'clean')
bert:/usr/ports/textproc/groff# ls
CVS Makefile distinfo patches pkg
My is /etc/mk.conf is:
--- BEGIN ---
FORCE_UPDATE=yes
SUDO=/usr/bin/sudo
USE_SYSTRACE=yes
# use /usr/obj for xenocara and ports obj
XOBJDIR=/usr/obj/xobj
WRKOBJDIR=/usr/obj/pobj
# define directories for PORTSDIR read-only
VARPORTSDIR=/var/ports
BULK_COOKIES_DIR=${VARPORTSDIR}/bulk/${MACHINE_ARCH}
DISTDIR=${VARPORTSDIR}/distfiles
PACKAGE_REPOSITORY=${VARPORTSDIR}/packages
PLIST_DB=${VARPORTSDIR}/plist/${MACHINE_ARCH}
UPDATE_COOKIES_DIR=${VARPORTSDIR}/update/${MACHINE_ARCH}
--- END ---
Thanks for any help.
--
Sébastien Marie
Re: problem with bsd.port.mk and readonly /usr/ports
On Tue, Feb 05, 2013 at 11:28:05AM +0100, Landry Breuil wrote:
On Tue, Feb 05, 2013 at 10:52:14AM +0100, Sébastien Marie wrote:
Hi,
I start having a problem with recent bsd.port.mk in ports, that seems
related to readonly /usr/ports partition.
My bsd.port.mk is 1.1208.
The base is (on i386):
OpenBSD 5.3-beta (GENERIC.MP) #25: Fri Feb 1 16:35:30 MST 2013
bert:/usr/ports/textproc/groff# make clean
=== Cleaning for groff-1.21p8
rm: /usr/ports/textproc/groff/w-groff-1.21: Read-only file system
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2859
'_internal-clean': @rm -rf /usr/ports/textproc/groff/w-groff-1.21)
*** Error 1 in /usr/ports/textproc/groff
(/usr/ports/infrastructure/mk/bsd.port.mk:2342 'clean')
w- (OLD_WRKDIR_NAME) calculation changed in
http://www.openbsd.org/cgi-bin/cvsweb/ports/infrastructure/mk/bsd.port.mk.diff?r1=1.1205;r2=1.1206
pretty sure that's related. The wrong codepath is used because
WRKOBJDIR_${PKGPATH} is empty.
It seems not:
_WRKDIRS=/usr/ports/textproc/groff/w-groff-1.21 /usr/obj/pobj/groff-1.21
/usr/obj/pobj/groff-1.21 /tmp/pobj/groff-1.21
PKGPATH=textproc/groff
WRKOBJDIR_textproc/groff=/usr/obj/pobj
(I patch bsd.port.mk to echo vars just before line 2859).
It seems that _WRKDIRS is inconditionnally populated with ${OLD_WRKDIR_NAME}.
And rm(1) doesn't like read-only filesystem: with a user without write perm on
/usr/ports, and /usr/ports mount rw, there is no error...
For example: (/ is rw)
$ rm -rf /really-not-existent-file echo $?
0
But if rm on read-only (/usr/ports is ro):
$ rm -rf /usr/ports/really-not-existent-file echo $?
rm: /usr/ports/really-not-existent-file: Read-only file system
Should be considered as a bug in rm ?
--
Sébastien Marie
PATCH: update mail/bogofilter to 1.2.3
Hi,
This is the diff to update mail/bogofilter to 1.2.3
This version correct (from 1.1.6) several security issues:
- bogofilter-SA-2012-01/CVE-2012-5468: bogofilter/bogolexer heap buffer
overrun with base64 input that decodes to invalid multi-byte
characters (versions up to and including 1.2.2).
- bogofilter-SA-2010-01/CVE-2010-2494: bogofilter/bogolexer heap buffer
underrun (1 byte) with invalid base64 input (versions up to and
including 1.2.1).
The diff pass regress for all flavors (on i386).
[db3] : 55 passed (2 were not run)
db4: 55 passed (2 were not run)
sqlite3: 54 passed (3 were not run)
qdbm : 54 passed (3 were not run)
Are you ok ?
Thanks.
--
Sébastien Marie
Index: Makefile
===
RCS file: /cvs/ports/mail/bogofilter/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- Makefile23 Apr 2012 17:15:18 - 1.22
+++ Makefile22 Dec 2012 11:24:15 -
@@ -2,8 +2,7 @@
COMMENT = bayesian spam filter
-DISTNAME = bogofilter-1.1.6
-REVISION = 5
+DISTNAME = bogofilter-1.2.3
CATEGORIES = mail
MAINTAINER = Marc Espie es...@openbsd.org
Index: distinfo
===
RCS file: /cvs/ports/mail/bogofilter/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo19 Dec 2007 21:44:08 - 1.7
+++ distinfo22 Dec 2012 11:24:15 -
@@ -1,5 +1,2 @@
-MD5 (bogofilter-1.1.6.tar.gz) = NexS5dLFjeBKHgLdzI0CUg==
-RMD160 (bogofilter-1.1.6.tar.gz) = dNnLd8oRhFlB7rrhAs8PjDXoZVI=
-SHA1 (bogofilter-1.1.6.tar.gz) = GwEcZ9UY/v/5q20SD1tRP84Pj8I=
-SHA256 (bogofilter-1.1.6.tar.gz) = gtsImUBd4VJXkZ7wV+rQkW3rhzFnr1m+z/FfsFjwv40=
-SIZE (bogofilter-1.1.6.tar.gz) = 1044042
+SHA256 (bogofilter-1.2.3.tar.gz) = JvuAejZDciNi7QLtnO6kknyhP6N78gVlxCh52V2EB60=
+SIZE (bogofilter-1.2.3.tar.gz) = 1056248
Index: patches/patch-configure
===
RCS file: /cvs/ports/mail/bogofilter/patches/patch-configure,v
retrieving revision 1.2
diff -u -p -r1.2 patch-configure
--- patches/patch-configure 19 Dec 2007 21:44:08 - 1.2
+++ patches/patch-configure 22 Dec 2012 11:24:15 -
@@ -1,17 +1,7 @@
$OpenBSD: patch-configure,v 1.2 2007/12/19 21:44:08 bernd Exp $
configure.orig Sat Nov 24 05:37:19 2007
-+++ configure Fri Dec 14 18:01:09 2007
-@@ -12520,7 +12520,8 @@ echo ${ECHO_T}$ac_cv_libsqlite3_libs 6; }
-
-
-
-- LIBDB=$LIBSQLITE3
-+ LIBDB=$LTLIBSQLITE3
-+ LTLIBDB=$LTLIBSQLITE3
- WITH_DB_ENGINE=sqlite3
- ;;
- xtokyocabinet)
-@@ -13455,7 +13456,8 @@ echo ${ECHO_T}$ac_cv_libqdbm_libs 6; }
+--- configure.orig Sat Dec 22 11:41:09 2012
configure Sat Dec 22 11:50:16 2012
+@@ -9849,7 +9849,8 @@ $as_echo $ac_cv_libqdbm_libs 6; }
@@ -20,44 +10,4 @@ $OpenBSD: patch-configure,v 1.2 2007/12/
+ LTLIBDB=$LTLIBQDBM
saveLIBS=$LIBS
LIBS=$LIBS $LIBDB
- cat conftest.$ac_ext _ACEOF
-@@ -16427,7 +16429,7 @@ DISABLE_UNICODE_TRUE!$DISABLE_UNICODE_TRUE$ac_delim
- DISABLE_UNICODE_FALSE!$DISABLE_UNICODE_FALSE$ac_delim
- ENABLE_UNICODE_TRUE!$ENABLE_UNICODE_TRUE$ac_delim
- ENABLE_UNICODE_FALSE!$ENABLE_UNICODE_FALSE$ac_delim
--LIBICONV!$LIBICONV$ac_delim
-+LIBICONV!$LTLIBICONV$ac_delim
- LTLIBICONV!$LTLIBICONV$ac_delim
- ENCODING!$ENCODING$ac_delim
- DEFAULT_CHARSET!$DEFAULT_CHARSET$ac_delim
-@@ -16442,13 +16444,13 @@
DISABLE_TRANSACTIONS_TRUE!$DISABLE_TRANSACTIONS_TRUE$a
- DISABLE_TRANSACTIONS_FALSE!$DISABLE_TRANSACTIONS_FALSE$ac_delim
- ENABLE_TRANSACTIONS_TRUE!$ENABLE_TRANSACTIONS_TRUE$ac_delim
- ENABLE_TRANSACTIONS_FALSE!$ENABLE_TRANSACTIONS_FALSE$ac_delim
--LIBSQLITE3!$LIBSQLITE3$ac_delim
-+LIBSQLITE3!$LTLIBSQLITE3$ac_delim
- LTLIBSQLITE3!$LTLIBSQLITE3$ac_delim
- LIBTOKYOCABINET!$LIBTOKYOCABINET$ac_delim
- LTLIBTOKYOCABINET!$LTLIBTOKYOCABINET$ac_delim
--LIBQDBM!$LIBQDBM$ac_delim
-+LIBQDBM!$LTLIBQDBM$ac_delim
- LTLIBQDBM!$LTLIBQDBM$ac_delim
--LIBDB!$LIBDB$ac_delim
-+LIBDB!$LTLIBDB$ac_delim
- LTLIBDB!$LTLIBDB$ac_delim
- DB_EXT!$DB_EXT$ac_delim
- DB_TYPE!$DB_TYPE$ac_delim
-@@ -17086,9 +17088,9 @@ echo $as_me: CFLAGS=$CFLAGS 6;}
- echo $as_me: LDFLAGS=$LDFLAGS 6;}
- { echo $as_me:$LINENO: LIBS=$LIBS 5
- echo $as_me: LIBS=$LIBS 6;}
--{ echo $as_me:$LINENO:LIBDB=$LIBDB 5
--echo $as_me:LIBDB=$LIBDB 6;}
-+{ echo $as_me:$LINENO:LIBDB=$LTLIBDB 5
-+echo $as_me:LIBDB=$LTLIBDB 6;}
- { echo $as_me:$LINENO: GSL_LIBS=$GSL_LIBS 5
- echo $as_me: GSL_LIBS=$GSL_LIBS 6;}
--{ echo $as_me:$LINENO: LIBICONV=$LIBICONV 5
--echo $as_me: LIBICONV=$LIBICONV 6;}
-+{ echo $as_me:$LINENO: LIBICONV=$LTLIBICONV 5
-+echo $as_me: LIBICONV=$LTLIBICONV 6;}
+ cat confdefs.h - _ACEOF conftest.$ac_ext
Index: pkg/PFRAG.qdbm
===
RCS file: /cvs/ports/mail/bogofilter/pkg/PFRAG.qdbm,v
retrieving revision 1.1
diff -u -p -r1.1
Re: [PATCH] out-of-date: PORTSDIR_PATH support
On Tue, Dec 18, 2012 at 12:18:29PM +, Nigel Taylor wrote: out-of-date is not really used any more, don't know why your using it. mainly because it is a valuable tool to check is the installed packages are in sync with /usr/ports. but maybe I don't manage my updates in a accurate manner... pkg_add -ui should update any out of date installed packages from PKG_PATH. for officials and distributed packages, I'm agreed (except some normal delays in official build). but I use some packages that are not packaged (audio/timidity or cad/qcad for example) or personnals packages (the dependencies are better managed by pkg_add than by me... :-)) The packages in PKG_PATH should be built on a clean system with no packages installed, or present in PKG_PATH. Because nothing is installed or present out-of-date can't be used. If your build and running systems are combined then look at dpb with the -R, -u, -U options. See comment some packages only build on a clean system. dpb -R works by looking at out of date packages in PKG_PATH not those installed, out-of-date will not find out of date packages in PKG_PATH which haven't been installed, leaving broken packages in PKG_PATH if out-of-date is used as a rebuilding tool. I keep /usr/ports in sync daily, as it is more accurate than rely on pkg_add for be informed about update: packages are not rebuild daily for all archs. It is not a critic, I understand that all archs couldn't be rebuild every time (build time + limited ressources). out-of-date is only use to remind me about unsync between ports installed packages, and so known potential flaw in running system. So as I only want the installed packages to be monitored, I think use out-of-date for that is ok. and after, if I really need a package that is not already packaged, I ran: # dpb -R -u -q pathlist # pkg_add -aui package Thanks. -- Sébastien Marie
[PATCH] out-of-date: PORTSDIR_PATH support
Hi,
As my previous message seems to get very small audience, I rewrite it... please
excuse my previous mail, which was bad written.
The purpose is to permit the use of out-of-date(1) with customized mk.conf(5),
in particular the usage of PORTSDIR_PATH (search path for package
specifications).
The patch replace the search of path of installed packages, from a directory
existence check, to something that let make search the patch for us, and parse
the errors (in order to set not-found packages).
My use case is the mystuff directory (with is included by default in
PORTSDIR_PATH). With the patch, packages build from mystuff are found by
out-of-date (and so, reported as not up-to-date if there are), else there are
reported as not found.
If this proposal is not good, please let me know.
Thanks.
--
Sebastien Marie
Index: out-of-date
===
RCS file: /cvs/ports/infrastructure/bin/out-of-date,v
retrieving revision 1.5
diff -u -p -r1.5 out-of-date
--- out-of-date 7 May 2012 15:57:51 - 1.5
+++ out-of-date 16 Dec 2012 13:10:55 -
@@ -77,24 +77,14 @@ sub collect_port_versions
{
my ($pkg, $portsdir, $notfound) = @_;
- my @subdirs = ();
- for my $subdir (keys %$pkg) {
- my ($dir) = split(/,/, $subdir);
- if (-d $portsdir/$dir) {
- push(@subdirs, $subdir);
- } else {
- push(@$notfound, $subdir);
- }
- }
-
- my $cmd = cd $portsdir SUBDIR=\.join(' ', @subdirs)
+ my $cmd = cd $portsdir SUBDIR=\.join(' ', keys %$pkg)
.\ FULLPATH=Yes REPORT_PROBLEM=true make
.'show=FULLPKGNAME\${SUBPACKAGE} '
.21;
my $port = {};
my $error = {};
my $count = 0;
- my $total = scalar @subdirs;
+ my $total = scalar keys %$pkg;
$state-progress-set_header(Collecting port versions);
my $fh = open_cmd($cmd);
@@ -105,6 +95,12 @@ sub collect_port_versions
$subdir = $1;
$count++;
$state-progress-show($count, $total);
+ next;
+ }
+ if (/^\\ Broken dependency:\s+(\S+)\s+non existent/) {
+ $count++;
+ $state-progress-show($count, $total);
+ push(@$notfound, $1);
next;
}
next unless $_ or $subdir;
out-of-date: mystuff support
Hi,
Currently, when out-of-date(1) is used, with packages installed from mystuff
directory, these packages are reported as not found in the official ports
tree.
I don't know if I miss-used out-of-date or not... In doubt I ask. Feel free to
correct me if need.
Here, a naive proposal to include support of mystuff directory in
out-of-date(1).
Index: out-of-date
===
RCS file: /cvs/ports/infrastructure/bin/out-of-date,v
retrieving revision 1.5
diff -u -p -r1.5 out-of-date
--- out-of-date 7 May 2012 15:57:51 - 1.5
+++ out-of-date 16 Dec 2012 10:56:36 -
@@ -82,6 +82,8 @@ sub collect_port_versions
my ($dir) = split(/,/, $subdir);
if (-d $portsdir/$dir) {
push(@subdirs, $subdir);
+ } elsif (-d $portsdir/mystuff/$dir) {
+ push(@subdirs, $subdir);
} else {
push(@$notfound, $subdir);
}
An other proposal is to skip any directory existence test, and push $subdir in
@$notfound, during the parsing of make output. It would allow to used
out-of-date(1) in conjonction with some customized mk.conf (usage of
PORTSDIR_PATH for example, and mystuff directory in particular).
Index: out-of-date
===
RCS file: /cvs/ports/infrastructure/bin/out-of-date,v
retrieving revision 1.5
diff -u -p -r1.5 out-of-date
--- out-of-date 7 May 2012 15:57:51 - 1.5
+++ out-of-date 16 Dec 2012 13:10:55 -
@@ -77,24 +77,14 @@ sub collect_port_versions
{
my ($pkg, $portsdir, $notfound) = @_;
- my @subdirs = ();
- for my $subdir (keys %$pkg) {
- my ($dir) = split(/,/, $subdir);
- if (-d $portsdir/$dir) {
- push(@subdirs, $subdir);
- } else {
- push(@$notfound, $subdir);
- }
- }
-
- my $cmd = cd $portsdir SUBDIR=\.join(' ', @subdirs)
+ my $cmd = cd $portsdir SUBDIR=\.join(' ', keys %$pkg)
.\ FULLPATH=Yes REPORT_PROBLEM=true make
.'show=FULLPKGNAME\${SUBPACKAGE} '
.21;
my $port = {};
my $error = {};
my $count = 0;
- my $total = scalar @subdirs;
+ my $total = scalar keys %$pkg;
$state-progress-set_header(Collecting port versions);
my $fh = open_cmd($cmd);
@@ -105,6 +95,12 @@ sub collect_port_versions
$subdir = $1;
$count++;
$state-progress-show($count, $total);
+ next;
+ }
+ if (/^\\ Broken dependency:\s+(\S+)\s+non existent/) {
+ $count++;
+ $state-progress-show($count, $total);
+ push(@$notfound, $1);
next;
}
next unless $_ or $subdir;
--
Sébastien Marie
Re: lang/ghc: missing dep
On Wed, Oct 10, 2012 at 11:10:18PM +0200, Matthias Kilian wrote: On Wed, Oct 10, 2012 at 04:38:55PM +0200, Matthias Kilian wrote: On Wed, Oct 10, 2012 at 04:05:34PM +0200, David Coppa wrote: Here's the diff, comments are highly appreciated. Please commit, but without patches/patch-libraries_integer-gmp_configure Hi, Before commit, is it possible to fix a missing BUILD_DEPENDS for documentation ? textproc/docbook is missing. when build without (and systrace enable): checking for DocBook DTD... I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd and after, there are parser error for resolving entity (like ldquo;) thanks. -- Sébastien Marie
Re: lang/ghc: missing dep
On Thu, Oct 11, 2012 at 09:24:00AM +0200, Matthias Kilian wrote:
On Thu, Oct 11, 2012 at 08:37:01AM +0200, Sébastien Marie wrote:
Please commit, but without patches/patch-libraries_integer-gmp_configure
Before commit, is it possible to fix a missing BUILD_DEPENDS for
documentation ?
textproc/docbook is missing.
lang/ghc BUILD_DEPENDS on textproc/docbook-xsl which in turn
RUN_DEPENDS on textproc/docbook and textproc/libxslt.
The docbook{,-xsl} dependencies had been changed about two weeks
ago. Are your ports tree and packages up to date?
my system (base ports) is near one month old...
ok, sorry for the noise. I will re-read the faq where it is written that before
reporting problem upgrade :-)
--
Sébastien Marie
update: graphics/tiff: CVE-2012-1173 libtiff: Heap-buffer overflow
Hi, The current version of graphics/tiff (3.9.5) in ports seems to be vulnerable to CVE-2012-1173, a heap-buffer overflow. Upstream information and patch: http://bugzilla.maptools.org/show_bug.cgi?id=2369 Others informations: http://seclists.org/oss-sec/2012/q2/31 https://bugzilla.redhat.com/show_bug.cgi?id=803078 Thanks. -- Sebastien Marie
