Re: UPDATE net/tor: new bridge authority, patch for -current and -stable
On Mon, 16 Jul 2018 19:12:57 +0200, Juan Francisco Cantero Hurtado wrote: > The new versions add a new bridge authority. > https://github.com/torproject/tor/blob/master/ReleaseNotes > > Both pass the tests. OK? OK for the stable version. > > Current: > > Index: Makefile > === > --- Makefile (revision 130631) > +++ Makefile (working copy) > @@ -2,10 +2,9 @@ > > COMMENT= anonymity service using onion routing > > -DISTNAME=tor-0.3.3.8 > +DISTNAME=tor-0.3.3.9 > CATEGORIES= net > HOMEPAGE=https://www.torproject.org/ > -REVISION=1 > > MAINTAINER= Pascal Stumpf > > Index: distinfo > === > --- distinfo (revision 130631) > +++ distinfo (working copy) > @@ -1,2 +1,2 @@ > -SHA256 (tor-0.3.3.8.tar.gz) = PPW0/qJJHL/voQd78bKFXhaQUtOBvZIM1Xqpv6/2s6U= > -SIZE (tor-0.3.3.8.tar.gz) = 6564878 > +SHA256 (tor-0.3.3.9.tar.gz) = hTRrTQJuagQcjjJtLMZLX1NhsDIHXInFhU8W28Avzm8= > +SIZE (tor-0.3.3.9.tar.gz) = 6563091 > > Stable: > > > Index: Makefile > === > RCS file: /cvs/ports/net/tor/Makefile,v > retrieving revision 1.111 > diff -u -p -r1.111 Makefile > --- Makefile 4 Mar 2018 14:05:06 - 1.111 > +++ Makefile 16 Jul 2018 17:03:46 - > @@ -2,7 +2,7 @@ > > COMMENT= anonymity service using onion routing > > -DISTNAME=tor-0.3.2.10 > +DISTNAME=tor-0.3.2.11 > CATEGORIES= net > HOMEPAGE=https://www.torproject.org/ > > Index: distinfo > === > RCS file: /cvs/ports/net/tor/distinfo,v > retrieving revision 1.91 > diff -u -p -r1.91 distinfo > --- distinfo 4 Mar 2018 14:05:06 - 1.91 > +++ distinfo 16 Jul 2018 17:03:46 - > @@ -1,2 +1,2 @@ > -SHA256 (tor-0.3.2.10.tar.gz) = YN93wx3PlP3WhsjKjDTztwJDszpzROzAtxnVyiYXy+4= > -SIZE (tor-0.3.2.10.tar.gz) = 6421984 > +SHA256 (tor-0.3.2.11.tar.gz) = pq0hbX5dtjzNy4p6PobGnFcJ3c8I7ORMtVme7UL6IPA= > +SIZE (tor-0.3.2.11.tar.gz) = 6463761
UPDATE net/tor: new bridge authority, patch for -current and -stable
The new versions add a new bridge authority. https://github.com/torproject/tor/blob/master/ReleaseNotes Both pass the tests. OK? Current: Index: Makefile === --- Makefile(revision 130631) +++ Makefile(working copy) @@ -2,10 +2,9 @@ COMMENT= anonymity service using onion routing -DISTNAME= tor-0.3.3.8 +DISTNAME= tor-0.3.3.9 CATEGORIES=net HOMEPAGE= https://www.torproject.org/ -REVISION= 1 MAINTAINER=Pascal Stumpf Index: distinfo === --- distinfo(revision 130631) +++ distinfo(working copy) @@ -1,2 +1,2 @@ -SHA256 (tor-0.3.3.8.tar.gz) = PPW0/qJJHL/voQd78bKFXhaQUtOBvZIM1Xqpv6/2s6U= -SIZE (tor-0.3.3.8.tar.gz) = 6564878 +SHA256 (tor-0.3.3.9.tar.gz) = hTRrTQJuagQcjjJtLMZLX1NhsDIHXInFhU8W28Avzm8= +SIZE (tor-0.3.3.9.tar.gz) = 6563091 Stable: Index: Makefile === RCS file: /cvs/ports/net/tor/Makefile,v retrieving revision 1.111 diff -u -p -r1.111 Makefile --- Makefile4 Mar 2018 14:05:06 - 1.111 +++ Makefile16 Jul 2018 17:03:46 - @@ -2,7 +2,7 @@ COMMENT= anonymity service using onion routing -DISTNAME= tor-0.3.2.10 +DISTNAME= tor-0.3.2.11 CATEGORIES=net HOMEPAGE= https://www.torproject.org/ Index: distinfo === RCS file: /cvs/ports/net/tor/distinfo,v retrieving revision 1.91 diff -u -p -r1.91 distinfo --- distinfo4 Mar 2018 14:05:06 - 1.91 +++ distinfo16 Jul 2018 17:03:46 - @@ -1,2 +1,2 @@ -SHA256 (tor-0.3.2.10.tar.gz) = YN93wx3PlP3WhsjKjDTztwJDszpzROzAtxnVyiYXy+4= -SIZE (tor-0.3.2.10.tar.gz) = 6421984 +SHA256 (tor-0.3.2.11.tar.gz) = pq0hbX5dtjzNy4p6PobGnFcJ3c8I7ORMtVme7UL6IPA= +SIZE (tor-0.3.2.11.tar.gz) = 6463761
Re: [PostgreSQL] Updates for -current and -stable (5.5, 5.4 and 5.3)
On Thu, Mar 27, 2014 at 10:14:45PM +0100, LEVAI Daniel wrote: On sze, márc 26, 2014 at 16:57:41 +0100, Pierre-Emmanuel André wrote: On Fri, Mar 21, 2014 at 02:18:23PM +0100, Pierre-Emmanuel André wrote: Hi, There are new updates for PostgreSQL. The diffs for 5.4 and 5.3 are minor updates: http://www.postgresql.org/docs/9.2/static/release-9-2-8.html The diff for -current and 5.5 is more critical: The data corruption issue in PostgreSQL 9.3 affects binary replication standbys, servers being recovered from point-in-time-recovery backup, and standalone servers which recover from a system crash. The bug causes unrecoverable index corruption during recovery due to incorrect replay of row locking operations. This can then cause query results to be inconsistent depending on whether or not an index is used, and eventually lead to primary key violations and similar issues. More informations here: http://www.postgresql.org/about/news/1511/ I tested -current, 5.5 -stable and 5.4-stable on @amd64. Could someone do a test on a 5.3-stable ? Comments, OK ? ping ?? No 5.3, but it's been working well for me on 5.4 i386. Thanks for your report. It's committed. Regards, -- Pierre-Emmanuel André pea at raveland.org GPG key: 0xBB8D3F0E
Re: [PostgreSQL] Updates for -current and -stable (5.5, 5.4 and 5.3)
On sze, márc 26, 2014 at 16:57:41 +0100, Pierre-Emmanuel André wrote: On Fri, Mar 21, 2014 at 02:18:23PM +0100, Pierre-Emmanuel André wrote: Hi, There are new updates for PostgreSQL. The diffs for 5.4 and 5.3 are minor updates: http://www.postgresql.org/docs/9.2/static/release-9-2-8.html The diff for -current and 5.5 is more critical: The data corruption issue in PostgreSQL 9.3 affects binary replication standbys, servers being recovered from point-in-time-recovery backup, and standalone servers which recover from a system crash. The bug causes unrecoverable index corruption during recovery due to incorrect replay of row locking operations. This can then cause query results to be inconsistent depending on whether or not an index is used, and eventually lead to primary key violations and similar issues. More informations here: http://www.postgresql.org/about/news/1511/ I tested -current, 5.5 -stable and 5.4-stable on @amd64. Could someone do a test on a 5.3-stable ? Comments, OK ? ping ?? No 5.3, but it's been working well for me on 5.4 i386. Daniel -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: [PostgreSQL] Updates for -current and -stable (5.5, 5.4 and 5.3)
On Fri, Mar 21, 2014 at 02:18:23PM +0100, Pierre-Emmanuel André wrote: Hi, There are new updates for PostgreSQL. The diffs for 5.4 and 5.3 are minor updates: http://www.postgresql.org/docs/9.2/static/release-9-2-8.html The diff for -current and 5.5 is more critical: The data corruption issue in PostgreSQL 9.3 affects binary replication standbys, servers being recovered from point-in-time-recovery backup, and standalone servers which recover from a system crash. The bug causes unrecoverable index corruption during recovery due to incorrect replay of row locking operations. This can then cause query results to be inconsistent depending on whether or not an index is used, and eventually lead to primary key violations and similar issues. More informations here: http://www.postgresql.org/about/news/1511/ I tested -current, 5.5 -stable and 5.4-stable on @amd64. Could someone do a test on a 5.3-stable ? Comments, OK ? ping ?? -- Pierre-Emmanuel André pea at raveland.org GPG key: 0xBB8D3F0E
[PostgreSQL] Updates for -current and -stable (5.5, 5.4 and 5.3)
Hi,
There are new updates for PostgreSQL.
The diffs for 5.4 and 5.3 are minor updates:
http://www.postgresql.org/docs/9.2/static/release-9-2-8.html
The diff for -current and 5.5 is more critical:
The data corruption issue in PostgreSQL 9.3 affects binary replication
standbys, servers being recovered from point-in-time-recovery backup, and
standalone servers which recover from a system crash. The bug causes
unrecoverable index corruption during recovery due to incorrect replay of row
locking operations. This can then cause query results to be inconsistent
depending on whether or not an index is used, and eventually lead to
primary key violations and similar issues.
More informations here:
http://www.postgresql.org/about/news/1511/
I tested -current, 5.5 -stable and 5.4-stable on @amd64.
Could someone do a test on a 5.3-stable ?
Comments, OK ?
Regards,
--
Pierre-Emmanuel André pea at raveland.org
GPG key: 0xBB8D3F0E
Index: Makefile
===
RCS file: /cvs/ports/databases/postgresql/Makefile,v
retrieving revision 1.183
diff -u -p -u -p -r1.183 Makefile
--- Makefile 11 Mar 2014 10:42:34 - 1.183
+++ Makefile 21 Mar 2014 12:36:35 -
@@ -9,7 +9,7 @@ COMMENT-plpython=Python procedural langu
# DO NOT FORGET to also change the @ask-update entry in pkg/PLIST-server
# in case a dump before / restore after pkg_add -u is required!
-VERSION= 9.3.3
+VERSION= 9.3.4
DISTNAME= postgresql-${VERSION}
PKGNAME-main= postgresql-client-${VERSION}
PKGNAME-server= postgresql-server-${VERSION}
Index: distinfo
===
RCS file: /cvs/ports/databases/postgresql/distinfo,v
retrieving revision 1.51
diff -u -p -u -p -r1.51 distinfo
--- distinfo 11 Mar 2014 10:42:34 - 1.51
+++ distinfo 21 Mar 2014 12:36:35 -
@@ -1,2 +1,2 @@
-SHA256 (postgresql-9.3.3.tar.gz) = LbXruNTXwZ8G7Vhc2e/UH/Ygsi4whI+uOsLuqRhryHs=
-SIZE (postgresql-9.3.3.tar.gz) = 21851007
+SHA256 (postgresql-9.3.4.tar.gz) = cVW5TCq+x9BWOEY4Of9AP97oJ01yor0oCnvs3uSUFUA=
+SIZE (postgresql-9.3.4.tar.gz) = 21865589
Index: pkg/PLIST-docs
===
RCS file: /cvs/ports/databases/postgresql/pkg/PLIST-docs,v
retrieving revision 1.63
diff -u -p -u -p -r1.63 PLIST-docs
--- pkg/PLIST-docs 11 Mar 2014 10:42:34 - 1.63
+++ pkg/PLIST-docs 21 Mar 2014 12:36:35 -
@@ -783,6 +783,7 @@ share/doc/postgresql/html/release-8-4-18
share/doc/postgresql/html/release-8-4-19.html
share/doc/postgresql/html/release-8-4-2.html
share/doc/postgresql/html/release-8-4-20.html
+share/doc/postgresql/html/release-8-4-21.html
share/doc/postgresql/html/release-8-4-3.html
share/doc/postgresql/html/release-8-4-4.html
share/doc/postgresql/html/release-8-4-5.html
@@ -799,6 +800,7 @@ share/doc/postgresql/html/release-9-0-13
share/doc/postgresql/html/release-9-0-14.html
share/doc/postgresql/html/release-9-0-15.html
share/doc/postgresql/html/release-9-0-16.html
+share/doc/postgresql/html/release-9-0-17.html
share/doc/postgresql/html/release-9-0-2.html
share/doc/postgresql/html/release-9-0-3.html
share/doc/postgresql/html/release-9-0-4.html
@@ -812,6 +814,7 @@ share/doc/postgresql/html/release-9-1-1.
share/doc/postgresql/html/release-9-1-10.html
share/doc/postgresql/html/release-9-1-11.html
share/doc/postgresql/html/release-9-1-12.html
+share/doc/postgresql/html/release-9-1-13.html
share/doc/postgresql/html/release-9-1-2.html
share/doc/postgresql/html/release-9-1-3.html
share/doc/postgresql/html/release-9-1-4.html
@@ -828,10 +831,12 @@ share/doc/postgresql/html/release-9-2-4.
share/doc/postgresql/html/release-9-2-5.html
share/doc/postgresql/html/release-9-2-6.html
share/doc/postgresql/html/release-9-2-7.html
+share/doc/postgresql/html/release-9-2-8.html
share/doc/postgresql/html/release-9-2.html
share/doc/postgresql/html/release-9-3-1.html
share/doc/postgresql/html/release-9-3-2.html
share/doc/postgresql/html/release-9-3-3.html
+share/doc/postgresql/html/release-9-3-4.html
share/doc/postgresql/html/release-9-3.html
share/doc/postgresql/html/release.html
share/doc/postgresql/html/resources.html
Index: Makefile
===
RCS file: /cvs/ports/databases/postgresql/Makefile,v
retrieving revision 1.178.2.2
diff -u -p -u -p -r1.178.2.2 Makefile
--- Makefile 20 Mar 2014 09:12:50 - 1.178.2.2
+++ Makefile 21 Mar 2014 12:52:34 -
@@ -5,7 +5,7 @@ COMMENT-server= PostgreSQL RDBMS (server
COMMENT-docs= PostgreSQL RDBMS documentation
COMMENT-contrib=PostgreSQL RDBMS contributions
-VERSION= 9.2.7
+VERSION= 9.2.8
DISTNAME= postgresql-${VERSION}
PKGNAME-main= postgresql-client-${VERSION}
PKGNAME-server= postgresql-server-${VERSION}
Index: distinfo
===
RCS file: /cvs/ports/databases/postgresql/distinfo,v
retrieving revision 1.48.2.2
diff -u -p -u -p -r1.48.2.2 distinfo
Re: webkit-current on -stable
On Mon, Jan 04, 2010 at 09:19:40PM +0100, Landry Breuil wrote:
On Mon, Jan 04, 2010 at 10:55:06PM +0300, Andrej Elizarov wrote:
oh, my first thought was that ppl is some arch, like ppc =)
$ uname -rpmsv
OpenBSD 4.6 GENERIC#6 i386 Intel(R) Pentium(R) 4 CPU 1.80GHz
(GenuineIntel 686-class)
snip
$ pkg_info|grep g++|awk '{print $1}'
g++-4.2.4p5
That was enough info re/ compiler arch :)
u need some tweaks before, that i made.
- -lxcb -lpthread-stubs from xenocara-current
- glib2-2.22.3p1
but it's better change SHARED_LIBS suffix to previous (1802.0 -
1801.1) to not break all dependencies as i do at first time.
- new libsoup-2.28.2 (also with suffix hack)
- can't remember, may be some another
Ok, so a ports tree full of hacks. cool.
ok. now to errors.
i get some similiar to yours
https://bugs.webkit.org/show_bug.cgi?id=26099
but now with 4(four) asserts and different line numbers.
i'll be more accurate when reproduce it.
webkit-1.1.15.4/ $grep -r COMPILE_ASSERT . | wc -l
137
Yeah, you'll need to be more accurate.. if you reproduce it.
Here
http://trac.webkit.org/browser/releases/WebKitGTK/webkit-1.1.17/
appears some #def's and #ifdef's for OPENBSD,
may be it can be useful for breaking this bug(?) out.
Can you be _more_ precise on where this ifdefs 'appear' ? as i'm
probably the only one working on webkit/openbsd, and i didn't test
1.1.17 yet, i doubt that it targets this 'bug'.
^^ works great for me... (p.s. don't tell anyone ;)
comment out two blocks of code in my patch- may be valid only if :
#if COMPILER(GCC) PLATFORM(X86)
#elif COMPILER(GCC) PLATFORM(X86_64)
respectively
i'm surprised (see #uname output at top).
meanwhile your asserts works only on
#elif COMPILER(GCC) PLATFORM(X86_64)
and it's right imo.
I don't get what you mean.
i'm greping sources for layout of JITStackFrame, but no success for now.
may be there is things that i must to know about?
JavaScriptCore/jit/JITStubs.h
Landry
Re: webkit-current on -stable
On Mon, Jan 04, 2010 at 06:37:36AM +0300, Andrej Elizarov wrote: while compiling webkit-1.1.15.4v0 from current ports on 4.6-stable i still need patch-JavaScriptCore_jit_JITStubs_cpp . here it is. it just works for me. Which arch ? Iirc this patch was needed only on amd64, and not needed anymore since 1.1.15.2 and after which builds fine with -current, otherwise i suppose i would have get some complains since then... Providing an error message, a compiler version, etc... could be useful. (if we cared about ppl building current ports on stable) You can also comment on https://bugs.webkit.org/show_bug.cgi?id=26099 --- JavaScriptCore/jit/JITStubs.cpp.origMon Jan 4 06:03:57 2010 +++ JavaScriptCore/jit/JITStubs.cpp Mon Jan 4 06:17:10 2010 @@ -81,10 +81,10 @@ // These ASSERTs remind you that, if you change the layout of JITStackFrame, you // need to change the assembly trampolines below to match. -COMPILE_ASSERT(offsetof(struct JITStackFrame, code) % 16 == 0x0, JITStackFrame_maintains_16byte_stack_alignment); -COMPILE_ASSERT(offsetof(struct JITStackFrame, savedEBX) == 0x3c, JITStackFrame_stub_argument_space_matches_ctiTrampoline); -COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x58, JITStackFrame_callFrame_offset_matches_ctiTrampoline); -COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x50, JITStackFrame_code_offset_matches_ctiTrampoline); +//COMPILE_ASSERT(offsetof(struct JITStackFrame, code) % 16 == 0x0, JITStackFrame_maintains_16byte_stack_alignment); +//COMPILE_ASSERT(offsetof(struct JITStackFrame, savedEBX) == 0x3c, JITStackFrame_stub_argument_space_matches_ctiTrampoline); +//COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x58, JITStackFrame_callFrame_offset_matches_ctiTrampoline); +//COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x50, JITStackFrame_code_offset_matches_ctiTrampoline); asm volatile ( .globl SYMBOL_STRING(ctiTrampoline) \n @@ -140,10 +140,10 @@ // These ASSERTs remind you that, if you change the layout of JITStackFrame, you // need to change the assembly trampolines below to match. -COMPILE_ASSERT(offsetof(struct JITStackFrame, code) % 32 == 0x0, JITStackFrame_maintains_32byte_stack_alignment); -COMPILE_ASSERT(offsetof(struct JITStackFrame, savedRBX) == 0x48, JITStackFrame_stub_argument_space_matches_ctiTrampoline); -COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x90, JITStackFrame_callFrame_offset_matches_ctiTrampoline); -COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x80, JITStackFrame_code_offset_matches_ctiTrampoline); +//COMPILE_ASSERT(offsetof(struct JITStackFrame, code) % 32 == 0x0, JITStackFrame_maintains_32byte_stack_alignment); +//COMPILE_ASSERT(offsetof(struct JITStackFrame, savedRBX) == 0x48, JITStackFrame_stub_argument_space_matches_ctiTrampoline); +//COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x90, JITStackFrame_callFrame_offset_matches_ctiTrampoline); +//COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x80, JITStackFrame_code_offset_matches_ctiTrampoline); asm volatile ( .globl SYMBOL_STRING(ctiTrampoline) \n
Re: webkit-current on -stable
oh, my first thought was that ppl is some arch, like ppc =)
$ uname -rpmsv
OpenBSD 4.6 GENERIC#6 i386 Intel(R) Pentium(R) 4 CPU 1.80GHz
(GenuineIntel 686-class)
$ ec++ -v
Using built-in specs.
Target: i386-unknown-openbsd4.6
Configured with: /usr/obj/i386/gcc-4.2.4/gcc-4.2.4/configure
--with-gmp=/usr/local --enable-libgcj --verbose
--program-transform-name=s,^,e, --disable-nls --disable-checking
--with-system-zlib --disable-libmudflap --disable-libgomp
--disable-tls --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--with-gnu-ld --with-gnu-as --enable-threads=posix --enable-wchar_t
--enable-languages=c,c++,fortran,objc,java,ada --enable-cpp
--with-gnu-as --with-gnu-ld --enable-shared --prefix=/usr/local
--sysconfdir=/etc --mandir=/usr/local/man --infodir=/usr/local/info
Thread model: posix
gcc version 4.2.4
$ eg++ -v
Using built-in specs.
Target: i386-unknown-openbsd4.6
Configured with: /usr/obj/i386/gcc-4.2.4/gcc-4.2.4/configure
--with-gmp=/usr/local --enable-libgcj --verbose
--program-transform-name=s,^,e, --disable-nls --disable-checking
--with-system-zlib --disable-libmudflap --disable-libgomp
--disable-tls --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--with-gnu-ld --with-gnu-as --enable-threads=posix --enable-wchar_t
--enable-languages=c,c++,fortran,objc,java,ada --enable-cpp
--with-gnu-as --with-gnu-ld --enable-shared --prefix=/usr/local
--sysconfdir=/etc --mandir=/usr/local/man --infodir=/usr/local/info
Thread model: posix
gcc version 4.2.4
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd4.6/3.3.5/specs
Configured with:
Thread model: single
gcc version 3.3.5 (propolice)
$ g++ -v
Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd4.6/3.3.5/specs
Configured with:
Thread model: single
gcc version 3.3.5 (propolice)
$ pkg_info|grep g++|awk '{print $1}'
g++-4.2.4p5
u need some tweaks before, that i made.
- -lxcb -lpthread-stubs from xenocara-current
- glib2-2.22.3p1
but it's better change SHARED_LIBS suffix to previous (1802.0 -
1801.1) to not break all dependencies as i do at first time.
- new libsoup-2.28.2 (also with suffix hack)
- can't remember, may be some another
ok. now to errors.
i get some similiar to yours
https://bugs.webkit.org/show_bug.cgi?id=26099
but now with 4(four) asserts and different line numbers.
i'll be more accurate when reproduce it.
Here
http://trac.webkit.org/browser/releases/WebKitGTK/webkit-1.1.17/
appears some #def's and #ifdef's for OPENBSD,
may be it can be useful for breaking this bug(?) out.
comment out two blocks of code in my patch- may be valid only if :
#if COMPILER(GCC) PLATFORM(X86)
#elif COMPILER(GCC) PLATFORM(X86_64)
respectively
i'm surprised (see #uname output at top).
meanwhile your asserts works only on
#elif COMPILER(GCC) PLATFORM(X86_64)
and it's right imo.
i'm greping sources for layout of JITStackFrame, but no success for now.
may be there is things that i must to know about?
2010/1/4, Landry Breuil lan...@rhaalovely.net:
On Mon, Jan 04, 2010 at 06:37:36AM +0300, Andrej Elizarov wrote:
while compiling webkit-1.1.15.4v0 from current ports on 4.6-stable i
still
need
patch-JavaScriptCore_jit_JITStubs_cpp .
here it is. it just works for me.
Which arch ? Iirc this patch was needed only on amd64, and not needed
anymore since 1.1.15.2 and after which builds fine with -current,
otherwise i suppose i would have get some complains since then...
Providing an error message, a compiler version, etc... could be useful.
(if we cared about ppl building current ports on stable)
You can also comment on https://bugs.webkit.org/show_bug.cgi?id=26099
--- JavaScriptCore/jit/JITStubs.cpp.origMon Jan 4 06:03:57 2010
+++ JavaScriptCore/jit/JITStubs.cpp Mon Jan 4 06:17:10 2010
@@ -81,10 +81,10 @@
// These ASSERTs remind you that, if you change the layout of
JITStackFrame, you
// need to change the assembly trampolines below to match.
-COMPILE_ASSERT(offsetof(struct JITStackFrame, code) % 16 == 0x0,
JITStackFrame_maintains_16byte_stack_alignment);
-COMPILE_ASSERT(offsetof(struct JITStackFrame, savedEBX) == 0x3c,
JITStackFrame_stub_argument_space_matches_ctiTrampoline);
-COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x58,
JITStackFrame_callFrame_offset_matches_ctiTrampoline);
-COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x50,
JITStackFrame_code_offset_matches_ctiTrampoline);
+//COMPILE_ASSERT(offsetof(struct JITStackFrame, code) % 16 == 0x0,
JITStackFrame_maintains_16byte_stack_alignment);
+//COMPILE_ASSERT(offsetof(struct JITStackFrame, savedEBX) == 0x3c,
JITStackFrame_stub_argument_space_matches_ctiTrampoline);
+//COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x58,
JITStackFrame_callFrame_offset_matches_ctiTrampoline);
+//COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x50,
JITStackFrame_code_offset_matches_ctiTrampoline);
asm volatile (
.globl SYMBOL_STRING(ctiTrampoline) \n
@@ -140,10 +140,10 @@
// These ASSERTs
Re: webkit-current on -stable
On Mon, Jan 04, 2010 at 10:55:06PM +0300, Andrej Elizarov wrote:
oh, my first thought was that ppl is some arch, like ppc =)
$ uname -rpmsv
OpenBSD 4.6 GENERIC#6 i386 Intel(R) Pentium(R) 4 CPU 1.80GHz
(GenuineIntel 686-class)
snip
$ pkg_info|grep g++|awk '{print $1}'
g++-4.2.4p5
That was enough info re/ compiler arch :)
u need some tweaks before, that i made.
- -lxcb -lpthread-stubs from xenocara-current
- glib2-2.22.3p1
but it's better change SHARED_LIBS suffix to previous (1802.0 -
1801.1) to not break all dependencies as i do at first time.
- new libsoup-2.28.2 (also with suffix hack)
- can't remember, may be some another
Ok, so a ports tree full of hacks. cool.
ok. now to errors.
i get some similiar to yours
https://bugs.webkit.org/show_bug.cgi?id=26099
but now with 4(four) asserts and different line numbers.
i'll be more accurate when reproduce it.
webkit-1.1.15.4/ $grep -r COMPILE_ASSERT . | wc -l
137
Yeah, you'll need to be more accurate.. if you reproduce it.
Here
http://trac.webkit.org/browser/releases/WebKitGTK/webkit-1.1.17/
appears some #def's and #ifdef's for OPENBSD,
may be it can be useful for breaking this bug(?) out.
Can you be _more_ precise on where this ifdefs 'appear' ? as i'm
probably the only one working on webkit/openbsd, and i didn't test
1.1.17 yet, i doubt that it targets this 'bug'.
comment out two blocks of code in my patch- may be valid only if :
#if COMPILER(GCC) PLATFORM(X86)
#elif COMPILER(GCC) PLATFORM(X86_64)
respectively
i'm surprised (see #uname output at top).
meanwhile your asserts works only on
#elif COMPILER(GCC) PLATFORM(X86_64)
and it's right imo.
I don't get what you mean.
i'm greping sources for layout of JITStackFrame, but no success for now.
may be there is things that i must to know about?
JavaScriptCore/jit/JITStubs.h
Landry
Re: webkit-current on -stable
ok. now to errors. i get some similiar to yours https://bugs.webkit.org/show_bug.cgi?id=26099 but now with 4(four) asserts and different line numbers. i'll be more accurate when reproduce it. webkit-1.1.15.4/ $grep -r COMPILE_ASSERT . | wc -l 137 hey, this is exactly the same error in the same file, take a look at first message. only different lines. Yeah, you'll need to be more accurate.. if you reproduce it. sure. Here http://trac.webkit.org/browser/releases/WebKitGTK/webkit-1.1.17/ appears some #def's and #ifdef's for OPENBSD, may be it can be useful for breaking this bug(?) out. Can you be _more_ precise on where this ifdefs 'appear' ? as i'm probably the only one working on webkit/openbsd, and i didn't test 1.1.17 yet, i doubt that it targets this 'bug'. http://trac.webkit.org/browser/releases/WebKitGTK/webkit-1.1.17/JavaScriptCore/jit/JITStubs.cpp comment out two blocks of code in my patch- may be valid only if : #if COMPILER(GCC) PLATFORM(X86) #elif COMPILER(GCC) PLATFORM(X86_64) respectively i'm surprised (see #uname output at top). meanwhile your asserts works only on #elif COMPILER(GCC) PLATFORM(X86_64) and it's right imo. I don't get what you mean. ok. in my patch commented out two blocks of code. first contained in: #if COMPILER(GCC) PLATFORM(X86) //asserts #endif and second one in: #elif COMPILER(GCC) PLATFORM(X86_64) //asserts #endif i have (X86) machine, but still need to comment out second block to prevent errors, and it's weird. but in your case, as i see on https://bugs.webkit.org/show_bug.cgi?id=26099 there is only 125,126,127 lines in JavaScriptCore/jit/JITStubs.cpp this lines correspond to #elif COMPILER(GCC) PLATFORM(X86_64) //asserts #endif in http://trac.webkit.org/browser/releases/WebKitGTK/webkit-1.1.10/JavaScriptCore/jit/JITStubs.cpp and it's ok for you, as you use OpenBSD/amd64. i'm greping sources for layout of JITStackFrame, but no success for now. may be there is things that i must to know about? JavaScriptCore/jit/JITStubs.h oh, shame. tnx. so, think we just need correct offset-values for code,savedEBX, callFrame from struct JITStackFrame.
Re: webkit-current on -stable
On Tue, Jan 05, 2010 at 12:23:29AM +0300, Andrej Elizarov wrote: ok. now to errors. i get some similiar to yours https://bugs.webkit.org/show_bug.cgi?id=26099 but now with 4(four) asserts and different line numbers. i'll be more accurate when reproduce it. webkit-1.1.15.4/ $grep -r COMPILE_ASSERT . | wc -l 137 hey, this is exactly the same error in the same file, take a look at first message. only different lines. Hmpf, sorry. In fact, the fourth COMPILE_ASSERT appeared in r46589, which was a huge merge commit. yay for more comprehension. Yeah, you'll need to be more accurate.. if you reproduce it. sure. Here http://trac.webkit.org/browser/releases/WebKitGTK/webkit-1.1.17/ appears some #def's and #ifdef's for OPENBSD, may be it can be useful for breaking this bug(?) out. Can you be _more_ precise on where this ifdefs 'appear' ? as i'm probably the only one working on webkit/openbsd, and i didn't test 1.1.17 yet, i doubt that it targets this 'bug'. http://trac.webkit.org/browser/releases/WebKitGTK/webkit-1.1.17/JavaScriptCore/jit/JITStubs.cpp yeah well, maybe change in r51141 might be related. Good luck understanding this asm mess. comment out two blocks of code in my patch- may be valid only if : #if COMPILER(GCC) PLATFORM(X86) #elif COMPILER(GCC) PLATFORM(X86_64) respectively i'm surprised (see #uname output at top). meanwhile your asserts works only on #elif COMPILER(GCC) PLATFORM(X86_64) and it's right imo. I don't get what you mean. ok. in my patch commented out two blocks of code. first contained in: #if COMPILER(GCC) PLATFORM(X86) //asserts #endif and second one in: #elif COMPILER(GCC) PLATFORM(X86_64) //asserts #endif i have (X86) machine, but still need to comment out second block to prevent errors, and it's weird. Agreed, totally. but in your case, as i see on https://bugs.webkit.org/show_bug.cgi?id=26099 there is only 125,126,127 lines in JavaScriptCore/jit/JITStubs.cpp this lines correspond to #elif COMPILER(GCC) PLATFORM(X86_64) //asserts #endif in http://trac.webkit.org/browser/releases/WebKitGTK/webkit-1.1.10/JavaScriptCore/jit/JITStubs.cpp and it's ok for you, as you use OpenBSD/amd64. Wait.. i always compile and test webkit on amd64/i386/powerpc before commiting the update. At that time, the asserts for X86 where here too, and i didn't get any report of problems so far on i386 without the patch snippet. Be it with 1.1.10 or 1.1.15 or 1.1.15.4... i'm greping sources for layout of JITStackFrame, but no success for now. may be there is things that i must to know about? JavaScriptCore/jit/JITStubs.h oh, shame. tnx. so, think we just need correct offset-values for code,savedEBX, callFrame from struct JITStackFrame. Err... what makes you think that particular struct members need a 'better' offset ? Try to reproduce the same issue with i386/-current, and we'll see if it's a real bug. Given the monster webkit is, i already lost way too many hours in it maintaining/testing it for -current, i won't spend time on frankeinstein -stable/-current mixes. You can still push the issue further in webkit bz. Landry
Re: webkit-current on -stable
Wait.. i always compile and test webkit on amd64/i386/powerpc before commiting the update. At that time, the asserts for X86 where here too, and i didn't get any report of problems so far on i386 without the patch snippet. Be it with 1.1.10 or 1.1.15 or 1.1.15.4... i'll report about errors reproducing. so, think we just need correct offset-values for code,savedEBX, callFrame from struct JITStackFrame. Err... what makes you think that particular struct members need a 'better' offset ? well, may be it has other offsets. just.. thought y'know. Try to reproduce the same issue with i386/-current, and we'll see if it's a real bug. Given the monster webkit is, i already lost way too many hours in it maintaining/testing it for -current, i won't spend time on frankeinstein -stable/-current mixes. no problem, i was so verbose because you was interested in, i can deal my monster myself.) May be i'll learn some in proccess. And make real zombie, call it Marla, give her laser-sledgehammer and will rule the world! you all doomed! ))
Re: webkit-current on -stable
-o JavaScriptCore/jit/libJavaS criptCore_la-JITStubs.lo `test -f 'JavaSc riptCore/jit/JITStubs.cpp' || echo './' `JavaScriptCore/jit/JITStubs.cpp JavaScriptCore/jit/JITStubs.cpp:84: error: array bound is not an integer constan t JavaScriptCore/jit/JITStubs.cpp:85: error: array bound is not an integer constan t JavaScriptCore/jit/JITStubs.cpp:86: error: array bound is not an integer constan t JavaScriptCore/jit/JITStubs.cpp:87: error: array bound is not an integer constan t gmake[1]: *** [JavaScriptCore/jit/libJavaScriptCore_la-JITStubs.lo] Error 1 gmake[1]: Leaving directory `/usr/ports/obj/webkit-1.1.15.4v0/webkit-1.1.15.4' gmake: *** [all] Error 2 *** Error code 2 and i was wrong, only four first lines for X86 arch really needed. don't want take your time, it's just to note.
webkit-current on -stable
while compiling webkit-1.1.15.4v0 from current ports on 4.6-stable i still need patch-JavaScriptCore_jit_JITStubs_cpp . here it is. it just works for me. --- JavaScriptCore/jit/JITStubs.cpp.origMon Jan 4 06:03:57 2010 +++ JavaScriptCore/jit/JITStubs.cpp Mon Jan 4 06:17:10 2010 @@ -81,10 +81,10 @@ // These ASSERTs remind you that, if you change the layout of JITStackFrame, you // need to change the assembly trampolines below to match. -COMPILE_ASSERT(offsetof(struct JITStackFrame, code) % 16 == 0x0, JITStackFrame_maintains_16byte_stack_alignment); -COMPILE_ASSERT(offsetof(struct JITStackFrame, savedEBX) == 0x3c, JITStackFrame_stub_argument_space_matches_ctiTrampoline); -COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x58, JITStackFrame_callFrame_offset_matches_ctiTrampoline); -COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x50, JITStackFrame_code_offset_matches_ctiTrampoline); +//COMPILE_ASSERT(offsetof(struct JITStackFrame, code) % 16 == 0x0, JITStackFrame_maintains_16byte_stack_alignment); +//COMPILE_ASSERT(offsetof(struct JITStackFrame, savedEBX) == 0x3c, JITStackFrame_stub_argument_space_matches_ctiTrampoline); +//COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x58, JITStackFrame_callFrame_offset_matches_ctiTrampoline); +//COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x50, JITStackFrame_code_offset_matches_ctiTrampoline); asm volatile ( .globl SYMBOL_STRING(ctiTrampoline) \n @@ -140,10 +140,10 @@ // These ASSERTs remind you that, if you change the layout of JITStackFrame, you // need to change the assembly trampolines below to match. -COMPILE_ASSERT(offsetof(struct JITStackFrame, code) % 32 == 0x0, JITStackFrame_maintains_32byte_stack_alignment); -COMPILE_ASSERT(offsetof(struct JITStackFrame, savedRBX) == 0x48, JITStackFrame_stub_argument_space_matches_ctiTrampoline); -COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x90, JITStackFrame_callFrame_offset_matches_ctiTrampoline); -COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x80, JITStackFrame_code_offset_matches_ctiTrampoline); +//COMPILE_ASSERT(offsetof(struct JITStackFrame, code) % 32 == 0x0, JITStackFrame_maintains_32byte_stack_alignment); +//COMPILE_ASSERT(offsetof(struct JITStackFrame, savedRBX) == 0x48, JITStackFrame_stub_argument_space_matches_ctiTrampoline); +//COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x90, JITStackFrame_callFrame_offset_matches_ctiTrampoline); +//COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x80, JITStackFrame_code_offset_matches_ctiTrampoline); asm volatile ( .globl SYMBOL_STRING(ctiTrampoline) \n
Re: current or stable?
On Thu, May 01, 2008 at 05:52:02PM -0700, Daniel Thomas Nevistic wrote: I am working on learning how to port, c. and am trying to figure out which flavor of OpenBSD that I need to run. Does it need to be current if I want to help with porting? As many have already said, run -current for porting. But keep in mind that you don't have to run -current on your main machine if you're not comfortable with that. There's always the possibility of setting up a second machine (or a VM) that runs -current, and use that to do porting. That said, I've been running -current on my laptop for quite some time now (two years or so), and never had serious problems. It just needs more attention in case you have to keep your system up to date, i.e. especially whenever you're developing/testing your ports. I maintain only one port (net/pptp), and I usually use my laptop to update that cause I use pptp on my laptop anyway. But I also have another -current install on a spare box that I use occasionally for other testing and hacking. For servers and routers I use -stable though, with occasional cherry picking of security fixes from -current ports. Remember to always take a look at http://www.openbsd.org/faq/current.html before updating a -current box. Sorry if this is somewhere in the documentation. I did not see it clearly in any place that I have read so far. It's mentioned in http://www.openbsd.org/porttest.html#First Good luck, -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpSJwRTvUHva.pgp Description: PGP signature
current or stable?
I am working on learning how to port, c. and am trying to figure out which flavor of OpenBSD that I need to run. Does it need to be current if I want to help with porting? Sorry if this is somewhere in the documentation. I did not see it clearly in any place that I have read so far. -Dan Daniel Nevistic Electrical Engineering University of Washington 206.818.1127
Re: current or stable?
Daniel Thomas Nevistic wrote: I am working on learning how to port, c. and am trying to figure out which flavor of OpenBSD that I need to run. Does it need to be current if I want to help with porting? If you want a port to be committed, it needs to compile against -current.
Re: current or stable?
On Thu, May 01, 2008 at 05:52:02PM -0700, Daniel Thomas Nevistic wrote: I am working on learning how to port, c. and am trying to figure out which flavor of OpenBSD that I need to run. Does it need to be current if I want to help with porting? You should run -current for working on ports. -ME
Re: current or stable?
On Thu, May 01, 2008 at 05:52:02PM -0700, Daniel Thomas Nevistic wrote:
I am working on learning how to port, c. and am trying to figure
out which flavor of OpenBSD that I need to run. Does it need to
be current if I want to help with porting?
Changes to the ports tree occur in -current, so you should run that
(or snapshots) if you want to test or submit changes.
Sorry if this is somewhere in the documentation. I did not see it
clearly in any place that I have read so far.
The following two links are very useful for ports people:
http://www.openbsd.org/porttest.html
http://www.openbsd.org/checklist.html
The first includes the following in the 'First step' section:
The ports tree is developed against [10]OpenBSD-current; there
is no guarantee that new ports or updates will work correctly on
the other branches. This means you should upgrade your system
and ports tree to -current
--
o--{ Will Maier }--o
| web:...http://www.lfod.us/ | [EMAIL PROTECTED] |
*-[ BSD: Live Free or Die ]*
