Re: OpenVPN + OpenBSD6.0 (i386 and Mip64) latency and jitter in Openvpn TCP Bridged mode
> > On Sun, 2017-02-19 at 14:15 +, Tom Smyth wrote: > > > I have tried tcp_nodelay, etc but i get a warning about it not > > > being > > > supported > > > by the kernel at run time ... I recently patched OpenVPN in -current to add a missing header that prevented OpenVPN from setting tcp_nodelay. It is likely that this will help your situation. -Kurt
Following Current / Flag Day
We narrowed the definition of what a static pie binary is in the kernel. This change is a flag day where newer kernels will not recognize older pie binaries making upgrading via source hard. If you are running an older version of -current, upgrade via snapshots prior to building a new kernel from source to get over this flag day. -Kurt
Need HPPA Machine Donation
I need a decent HPPA for hacking on OpenBSD. It would be great if someone from the community could donate or buy me a J6700 or J6750 (J6750 is better). I live in the greater New York City area. Contact me off-list for details. Thanks, -Kurt
Re: BSD Port from OpenJDK
On Wednesday 08 October 2008 2:21:23 pm Benjamin Adams wrote: Just wondering if this will effect OpenBSD with java: Eventually it will make things easier for BSD Java porting. -Kurt
Re: BSD Port from OpenJDK
On Tuesday 14 October 2008 11:13:41 am new_guy wrote: Ben Adams-3 wrote: Just wondering if this will effect OpenBSD with java: Per the interim governance guidelines for Projects [1] I'm pleased to announce the creation of the BSD Port Project Java is nasty. There... I said it and it is true. The goopy OOP of Java will tarnish anything it touches. Personally, I hope Java (in all of its virtual glory) never makes it into OpenBSD at all. Real men will cry man tears when OpenBSD ships with Java. Uninformed. We've had Java for years and now we have packages: ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/i386/jdk-1.7.0.00b24p2.tgz 4.4 will have packages also. Your negativity sucks. Porting Java to OpenBSD was and is not a trivial effort. It also serves as an excellent test bed for threads, the runtime linker and large memory applications. Porting Java to OpenBSD enabled the LOCKSS project to use it for its noble goals. It uncovered deadlocks in our pthread lib that resulted in large improvements to libpthread. Its use of dlopen() and friends resulted in significant improvements in our runtime linker. Oh and who made those improvements??? The same person who took the time to port Java to OpenBSD!! Me and other OpenBSD developers who saw the need to improve things. BTW, all those system level improvements have made significant stability gains for applications like firefox, KDE, OpenOffice, Asterisk, etc, etc which all use threads and dlopen() alot. Quite frankly I'm pretty upset at all the 'Java sucks' banter on misc. If you and the other naysayers don't realize that porting Java to OpenBSD was a 'Good-Thing' then you are just UNINFORMED! -Kurt
Re: Problems with socket created before fork() in multi-threaded application
On Friday 21 March 2008 6:25:59 am Philip Guenther wrote: On Fri, Mar 21, 2008 at 1:44 AM, Tvrvk Edwin [EMAIL PROTECTED] wrote: Philip Guenther wrote: On Thu, Mar 20, 2008 at 3:01 PM, Tvrvk Edwin [EMAIL PROTECTED] wrote: ClamAV has changed to call fork() after creating its local socket. This causes weird behaviours when communicating on the socket [1] If fork() is called before creating the socket() it works. Is it safe to create a socket, fork(), and then call pthread_create() and read from the socket? ... fork() is used to daemonize the process. Okay, it's a bug in libpthread. The user-space thread implementation of libpthread sets all the file descriptors to be non-blocking (O_NONBLOCK) so that it can catch blocking I/O and perform a context switch to another thread when that happens. This is hidden from the application itself: if a threaded app calls fcntl(fd, F_GETFL), the library will hide the O_NONBLOCK flag unless the app actually called fcntl() to set it. When a process exits, the library resets the fds back to blocking if they were only non-blocking for the library; this is so that other, non-threaded apps don't get confused when /dev/tty is left non-blocking, and things like that. That last bit is the catch: when the parent exits after calling fork, the socket is reset to blocking and the child never sets it back to non-blocking again. Your analysis is correct. It's not clear to me how the child can reliably detect that this has occurred. It could use a kqueue/kevent to detect when its parent has exited, but the reset could just as well be done by the child's grandparent (consider a double-fork daemonize). Indeed this is a nasty limitation of userland threads that doesn't have an easy solution. As a gross kludge, I think things would work if you added the following to the code called by the child after the fork. sleep(1); /* make sure the parent has a chance to exit */ fcntl(sockfd, F_SETFL, fcntl(sockfd, F_GETFL) ~O_NONBLOCK); (With the correct 'sockfd' variable, of course). That'll bring the kernel's O_NONBLOCK flag on the socket in sync with what libpthread thinks it should be. To avoid the race in the child (and the sleep() call), the parrent can set the fd's to non-blocking *before* the fork() and the child can set them back to blocking directly after the fork. Obviously not ideal but it will work-around the problem effectively. I'll note that I see a *bunch* of other fork() calls in the clamav source (0.92.1), some of which look very dubious in terms of safety. For example, dirscan() in clamd/scanner.c has a threadpool_t argument, so I presume it's called after threads have been spawned, yet it calls virusaction() which calls fork() and the child calls strdup(), malloc(), putenv(), system(), and exit(), none of which are async-signal safe. shrug Yuck -Kurt
Re: Problems with socket created before fork() in multi-threaded application
On Friday 21 March 2008 10:47:27 am Kurt Miller wrote: On Friday 21 March 2008 6:25:59 am Philip Guenther wrote: On Fri, Mar 21, 2008 at 1:44 AM, Tvrvk Edwin [EMAIL PROTECTED] wrote: Philip Guenther wrote: On Thu, Mar 20, 2008 at 3:01 PM, Tvrvk Edwin [EMAIL PROTECTED] wrote: ClamAV has changed to call fork() after creating its local socket. This causes weird behaviours when communicating on the socket [1] If fork() is called before creating the socket() it works. Is it safe to create a socket, fork(), and then call pthread_create() and read from the socket? ... fork() is used to daemonize the process. Okay, it's a bug in libpthread. The user-space thread implementation of libpthread sets all the file descriptors to be non-blocking (O_NONBLOCK) so that it can catch blocking I/O and perform a context switch to another thread when that happens. This is hidden from the application itself: if a threaded app calls fcntl(fd, F_GETFL), the library will hide the O_NONBLOCK flag unless the app actually called fcntl() to set it. When a process exits, the library resets the fds back to blocking if they were only non-blocking for the library; this is so that other, non-threaded apps don't get confused when /dev/tty is left non-blocking, and things like that. That last bit is the catch: when the parent exits after calling fork, the socket is reset to blocking and the child never sets it back to non-blocking again. Your analysis is correct. It's not clear to me how the child can reliably detect that this has occurred. It could use a kqueue/kevent to detect when its parent has exited, but the reset could just as well be done by the child's grandparent (consider a double-fork daemonize). Indeed this is a nasty limitation of userland threads that doesn't have an easy solution. As a gross kludge, I think things would work if you added the following to the code called by the child after the fork. sleep(1); /* make sure the parent has a chance to exit */ fcntl(sockfd, F_SETFL, fcntl(sockfd, F_GETFL) ~O_NONBLOCK); (With the correct 'sockfd' variable, of course). That'll bring the kernel's O_NONBLOCK flag on the socket in sync with what libpthread thinks it should be. To avoid the race in the child (and the sleep() call), the parrent can set the fd's to non-blocking *before* the fork() and the child can set them back to blocking directly after the fork. Obviously not ideal but it will work-around the problem effectively. After some more thought, a simpler solution would be to just have the parrent set the fd's to non-blocking directly before the exit() call. -Kurt
Re: Compile jdk 1.5 on amd64 run out of memory
Dongsheng Song wrote: For idle: $ swapctl -s total: 4200966k bytes allocated = 4776k used, 4196190k available When I not set HOTSPOT_BUILD_JOBS, it trap to ddb. Could you restrict the HOTSPOT_BUILD_JOBS not by cores, but also by memory ? Thanks. Yes I am planning on implementing that when the ports tree unlocks. Just for interested: What's the default vaalue for HOTSPOT_BUILD_JOBS and PARALLEL_BUILD_JOBS ? I will leave that question as an an exercise for the reader. However, I should point out the second env var is not called PARALLEL_BUILD_JOBS. It is called PARALLEL_COMPILE_JOBS. -Kurt
Re: Compile jdk 1.5 on amd64 run out of memory
Dongsheng Song wrote: When I not set HOTSPOT_BUILD_JOBS, it trap to ddb. Please submit a full bug report for this using sendbug(1). See http://www.openbsd.org/faq/faq2.html#Bugs and http://www.openbsd.org/report.html for what information you need to collect for it to be useful. Thanks, -Kurt
Re: Compile jdk 1.5 on amd64 run out of memory
On Saturday 08 March 2008 6:53:08 am Dongsheng Song wrote: Thanks, when I set HOTSPOT_BUILD_JOBS=2, it builds smoothly. Great. BTW, how much swap space did you configure on this system (swapctl -s)? What's PARALLEL_BUILD_JOBS, and their relationship? HOTSPOT_BUILD_JOBS controls how many parallel build jobs occur during the hotspot portion of the build (mostly c++ compiles). PARALLEL_BUILD_JOBS controls how many parallel build jobs occur during the rest of the build which I've left at the default. -Kurt
Re: Compile jdk 1.5 on amd64 run out of memory
On Thursday 06 March 2008 11:00:22 pm Dongsheng Song wrote: When I compile jdk 1.5 on amd64 as root, dmesg report: warning: resource shortage: 1 pages of swap lost extent_alloc_subregion: can't allocate region descriptor extent_alloc_subregion: can't allocate region descriptor extent_alloc_subregion: can't allocate region descriptor extent_alloc_subregion: can't allocate region descriptor extent_alloc_subregion: can't allocate region descriptor top report: load averages: 14.06, 11.01, 7.06 11:52:56 79 processes: 1 running, 72 idle, 2 stopped, 1 zombie, 3 on processor CPU0 states: 6.6% user, 0.0% nice, 6.9% system, 9.6% interrupt, 76.9% idle CPU1 states: 2.1% user, 0.0% nice, 8.2% system, 0.0% interrupt, 89.7% idle CPU2 states: 1.0% user, 0.0% nice, 5.8% system, 0.0% interrupt, 93.2% idle CPU3 states: 1.4% user, 0.0% nice, 6.3% system, 0.0% interrupt, 92.2% idle CPU4 states: 0.7% user, 0.0% nice, 5.4% system, 0.0% interrupt, 93.9% idle CPU5 states: 1.4% user, 0.0% nice, 5.3% system, 0.0% interrupt, 93.3% idle CPU6 states: 0.9% user, 0.0% nice, 5.2% system, 0.0% interrupt, 93.8% idle CPU7 states: 1.0% user, 0.0% nice, 5.4% system, 0.0% interrupt, 93.6% idle Memory: Real: 1248M/1742M act/tot Free: 243M Swap: 716M/4103M used/tot PID USERNAME PRI NICE SIZE RES STATEWAIT TIMECPU COMMAND 4022 root 640 189M 191M onproc/7 - 0:20 62.89% cc1plus 4909 root 640 135M 137M onproc/5 - 0:19 61.23% cc1plus 9915 root -50 274M 217M sleep/7 biowait 2:41 0.59% cc1plus 2750 root -50 274M 170M sleep/1 biowait 2:36 0.54% cc1plus 22384 root -50 274M 212M sleep/6 biowait 2:44 0.49% cc1plus 27878 root -50 274M 157M sleep/7 biowait 2:28 0.29% cc1plus 20622 root -50 274M 161M sleep/6 biowait 2:28 0.15% cc1plus 32565 _syslogd 20 472K 616K sleep/4 poll 0:00 0.00% syslogd 6005 root 20 3288K 620K idle select0:19 0.00% sshd 3110 root -60 16M 8880K sleep/6 piperd0:07 0.00% gmake 2414 root -50 428K 612K run/6- 0:00 0.00% g++ 19420 root -50 1232K 684K sleep/5 biowait 0:00 0.00% as 16834 root 280 920K 1612K stop/0 - 0:03 0.00% top 10131 root 20 1184K 1244K sleep/0 select0:03 0.00% sendmail 26246 root 30 632K 276K idle ttyin 0:03 0.00% ksh 24483 root 20 3352K 1304K idle select0:00 0.00% sshd $ ulimit -a time(cpu-seconds)unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 1048576 stack(kbytes)8192 lockedmem(kbytes)674606 memory(kbytes) 2019284 nofiles(descriptors) 128 processes660 The dmesg after boot is: http://marc.info/?l=openbsd-miscm=120479733117326w=2 What can I do ? Try editing the port Makefile and set HOTSPOT_BUILD_JOBS=4 or less. -Kurt
Re: vmware tools
On Tuesday 05 February 2008 9:21:51 am Marco Peereboom wrote: I recall seeing a post on a port for native vmware tools on openbsd. I can't find that email to save my life. Does anyone recall it that can send it to me? It's a bit old and crusty but here's one I did for 3.8: http://www.intricatesoftware.com/OpenBSD/ports/3.8/vmware_tools.tgz I no longer use vmware so I never committed it. -Kurt
Re: Compile jdk-1_5_0_12 on OpenBSD 4.2
On Friday 07 December 2007 5:15:13 am Dongsheng Song wrote: When I compile jdk from port, after few hours, errors occured: [...] ../../../src/share/native/sun/awt/image/BufImgSurfaceData.c:17: ../../../src/solaris/native/sun/awt/awt.h:20:27: X11/Intrinsic.h: No such file or directory [...] Thanks for some help. The Xorg sets need to be installed to build ports. -Kurt
Re: Java problems on 4.1
On Thursday 25 October 2007 2:33:58 am Pawel Veselov wrote: Since some time ago it became impossible to run JVMs on my 4.1 box. I can't seem to figure out what's wrong, probably something easy and stupid... ... 1.5.0-p1 Patchset one (-p1) was circa 3.8. it appears you have not rebuilt the jdk since 3.8. That would be my first guess. -Kurt
Re: gdb - firefox debugging
On Tuesday 07 August 2007 1:43:21 am J.C. Roberts wrote: I'm looking for all the needed steps to get firefox debug running in gdb. It's my first attempt at this and I've failed to the correct find the mozilla docs (assuming they exist) or details in the misc@, ports@ or tech@ archives. From what I've learned, you're supposed to use the following switches with the /usr/bin/firefox shell script. $ firefox -g You can be more explicit by naming the binary and the debugger. $ firefox -g /usr/local/mozilla-firefox/firefox-bin -d gdb The two are equivalent. Once inside gdb, I know you need to handle some signals. I've tried all combinations of the following signals and handling (nostop etc) without any luck: (gdb) handle SIG32 nostop noprint pass (gdb) handle SIG33 nostop noprint pass (gdb) handle SIGPIPE nostop noprint pass The problem I'm having is the gdb session just stops, without error, and firefox never actually loads. It never stops in the same place twice but it always stops. Hi, use 'set auto-solib-add off' to stop gdb from loading symbols from all shared libs. then selectively load shared lib symbols with 'shared libname' for placing breakpoints or to get line numbers from 'bt'. this technique is also needed to debug OOo issues. -Kurt
Re: tomcat-4.1 kaffe; IllegalArgumentException: Attribute must be readable or writable
Try http://www.kaffe.org/ first please. On Tuesday 24 July 2007 6:02:42 am Craig Skinner wrote: I have a bog standard tomcat-4.1 kaffe install on OpenBSD 4.0 i386. dmesg head shows that the box has little memory, JAVA_OPTS tuned to suit. Getting this exception (no search engine hits) as below, then tomcat bails out, any pointers? (I fiddled about in catalina.policy with attributes, but no joy): $ more catalina.out 2007 7 21 12:56:20 org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 ServerLifecycleListener: createMBeans: Throwable javax.management.RuntimeOperationsException: nested exception is java.lang.IllegalArgumentException: Attribute must be readable or writable java.lang.IllegalArgumentException: Attribute must be readable or writable at javax.management.MBeanAttributeInfo.init (MBeanAttributeInfo.java:60) at javax.management.modelmbean.ModelMBeanAttributeInfo.init (ModelMBeanAttributeInfo.java:50) at javax.management.modelmbean.ModelMBeanAttributeInfo.init (ModelMBeanAttributeInfo.java:45) at org.apache.commons.modeler.AttributeInfo.createAttributeInfo (AttributeInfo.java:283) at org.apache.commons.modeler.ManagedBean.createMBeanInfo (ManagedBean.java:464) at org.apache.commons.modeler.ManagedBean.createMBean (ManagedBean.java:424) at org.apache.catalina.mbeans.MBeanUtils.createMBean (MBeanUtils.java:657) at org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans (ServerLifecycleListener.java:759) at org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans (ServerLifecycleListener.java:325) at org.apache.catalina.mbeans.ServerLifecycleListener.lifecycleEvent (ServerLifecycleListener.java:179) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent (LifecycleSupport.java:119) at org.apache.catalina.core.StandardServer.start (StandardServer.java:2136) at org.apache.catalina.startup.Catalina.start (Catalina.java:463) at org.apache.catalina.startup.Catalina.execute (Catalina.java:350) at org.apache.catalina.startup.Catalina.process (Catalina.java:129) at java.lang.reflect.Method.invoke0 (Method.java) at java.lang.reflect.Method.invoke (Method.java:255) at org.apache.catalina.startup.Bootstrap.main (Bootstrap.java:156) GlobalResourcesLifecycleListener: Exception creating UserDatabase MBeans for UserDatabase javax.management.RuntimeOperationsException: nested exception is java.lang.IllegalArgumentException: Attribute must be readable or writable java.lang.IllegalArgumentException: Attribute must be readable or writable at javax.management.MBeanAttributeInfo.init (MBeanAttributeInfo.java:60) at javax.management.modelmbean.ModelMBeanAttributeInfo.init (ModelMBeanAttributeInfo.java:50) at javax.management.modelmbean.ModelMBeanAttributeInfo.init (ModelMBeanAttributeInfo.java:45) at org.apache.commons.modeler.AttributeInfo.createAttributeInfo (AttributeInfo.java:283) at org.apache.commons.modeler.ManagedBean.createMBeanInfo (ManagedBean.java:464) at org.apache.commons.modeler.ManagedBean.createMBean (ManagedBean.java:424) at org.apache.catalina.mbeans.MBeanUtils.createMBean (MBeanUtils.java:741) at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans (GlobalResourcesLifecycleListener.java:214) at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans (GlobalResourcesLifecycleListener.java:176) at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans (GlobalResourcesLifecycleListener.java:134) at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.lifecycleEvent (GlobalResourcesLifecycleListener.java:102) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent (LifecycleSupport.java:119) at org.apache.catalina.core.StandardServer.start (StandardServer.java:2136) at org.apache.catalina.startup.Catalina.start (Catalina.java:463) at org.apache.catalina.startup.Catalina.execute (Catalina.java:350) at org.apache.catalina.startup.Catalina.process (Catalina.java:129) at java.lang.reflect.Method.invoke0 (Method.java) at java.lang.reflect.Method.invoke (Method.java:255) at org.apache.catalina.startup.Bootstrap.main (Bootstrap.java:156) Starting service Tomcat-Standalone Apache Tomcat/4.1.31 Catalina.start: LifecycleException: Context startup failed due to previous errors LifecycleException: Context startup failed due to previous errors at org.apache.catalina.core.StandardContext.start (StandardContext.java:3578) at org.apache.catalina.core.ContainerBase.start (ContainerBase.java:1141) at org.apache.catalina.core.StandardHost.start (StandardHost.java:707) at org.apache.catalina.core.ContainerBase.start (ContainerBase.java:1141) at org.apache.catalina.core.StandardEngine.start (StandardEngine.java:316) at
Re: The tree is broken -- /sbin/ifconfig
On Tuesday 05 June 2007 4:04:50 pm Stephan Andre' wrote: I think today's changes to libc broke ifconfig, which still knows about ipx stuff... fixed now. thx.
Re: whats wrong with my iwi still ieee80211: nwid -50dBm
On Monday 19 March 2007 6:51:37 am Jay Jesus Amorin wrote: iwi0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 lladdr 00:12:f0:c7:30:a9 media: IEEE802.11 autoselect status: no network ieee80211: nwid my_net nwkey 0x1deadbeef1 -50dBm inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::212:f0ff:fec7:30a9%iwi0 prefixlen 64 scopeid 0x2 It not 'UP' but I doubt that's the problem. I've noticed iwi has trouble after changing nwid and/or nwkey. Rebooting works. This weekend I noticed an access point scan also seems to kick the card into recognizing the changed values. Try: ifconfig iwi0 up ifconfig -M iwi0 -Kurt
Re: java on openbsd 4.0?
On Monday 08 January 2007 8:38 pm, bofh wrote: What am I doing wrong? This is openbsd 4.0 on a DL145, dual opteron. Thanx for any pointers! I've replied to your build problem on the ports@ list, but just to clarify some things said in this thread: Beginning with OpenBSD 4.0 devel/jdk/1.5 no longer requires users to src build 1.3-linux and 1.4. It uses an open-source jdk to bootstrap the build now. -Kurt
Re: Trouble compiling JDK 1.5 on recent snapshot
On Monday 23 October 2006 1:55 pm, Greg Thomas wrote: Ok, it was successful this time but Firefox (1.5.0.7) crashes: # cat plugin_stack.trace java.io.IOException: Broken pipe at java.io.FileOutputStream.writeBytes(Native Method) at java.io.FileOutputStream.write(FileOutputStream.java:260) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65 ) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123) at java.io.DataOutputStream.flush(DataOutputStream.java:106) at sun.plugin.navig.motif.Plugin.replyOK(Plugin.java:530) at sun.plugin.navig.motif.Plugin.doit(Plugin.java:212) at sun.plugin.navig.motif.Plugin.start(Plugin.java:104) I did: sudo ln -s /usr/local/jdk-1.5.0/jre/plugin/i386/ns7/ libjavaplugin_oji.so /usr/local/lib/mozilla-plugins/libjavaplugin_oji.so Most likely you have hit the ulimits issue again. I would suggest changing settings in /etc/login.conf for your login class. I run with the following staff settings, YMMV: staff:\ :datasize-cur=infinity:\ :datasize-max=infinity:\ :stacksize-cur=8M:\ :openfiles-cur=1024:\ :maxproc-max=infinity:\ :maxproc-cur=1024:\ :ignorenologin:\ :requirehome@:\ :tc=default: I also bumped my kern.maxfiles=3000 so that when I login to kde and have many konqueror sessions with lots of tabs in them I don't hit the system limit. -Kurt
Re: Firefox/Iceweasel in OpenBSD
On Thursday 12 October 2006 4:57 am, Tobias Ulmer wrote: On Wed, Oct 11, 2006 at 10:19:45PM -0700, Ted Unangst wrote: On 10/11/06, David Sampson [EMAIL PROTECTED] wrote: AFAIK, no, but I was hoping to glean that information from the list... On Wed, 2006-10-11 at 23:31 -0500, Sam Fourman Jr. wrote: is someone planning on making a OpenBSD port for IceWeasel? and the point would be? what makes iceweasel a better browser than firefox? It's a legal issue. I've asked Mike Connor recently about the trademark problems and his answers were quite clear to me (applies to unofficial builds): - Currently mozilla takes no actions against the firefox executable or package name (because applications depend on the name), however it's not legal. - 'Firefox(r)' Community Edition is a trademark of mozilla. Its use is tolerated as long as we don't modify firefox too much (as outlined in [1] under Community Releases). Afaik our packages are not legal unless we have a secret partnership with mozilla. [2] links to all releveant documents. Did you intentionally leave out the document that describes Community Editions? Porting the software to different operating systems is specifically allowed in the Community Edition Policy: http://www.mozilla.org/foundation/trademarks/community-edition-policy.html Declaring our port is not legal without details is irresponsible and informatory. Please state specifically what part of their policy we are violating. Personally i would like to see the same strict policy we use against vendors like Intel, Mavell etc applied to Mozilla, but thats just me (yes i know, base != ports). Tobias [1] http://www.mozilla.org/foundation/trademarks/l10n-policy.html [2] http://www.mozilla.org/foundation/trademarks/index.html
Re: Firefox/Iceweasel in OpenBSD
On Wednesday 11 October 2006 10:31 pm, David Sampson wrote: Due to the recent flair over the use of the Firefox logo, the GNU camp has decided to fork the entire project, into IceWeasel. The idea here is that they can't use the FF logo freely, so of course they must fork it. I just want to know how this is going to affect the OpenBSD camp, if at all. We currently distribute Firefox under their Community Edition policy: http://www.mozilla.org/foundation/trademarks/community-edition-policy.html At this point in time I don't see a reason to change over to use IceWeasel or make up our own name. Perhaps others will have different opinions on this. -Kurt
Re: Firefox/Iceweasel in OpenBSD
On Thursday 12 October 2006 10:13 am, Tobias Ulmer wrote: We are modifying the source code, which is ok with the porting software paragraph in the document above, but contradicts with a private mail from Mike Connor where he writes about patching of app source violates their trademark. Oh well... Yes they are trying to exert a ridiculous level of control with their trademark but only when using the official branding. If they have given a project permission to use the official branding then any patch to firefox must first be approved by them. That's what all the fus is about. I'm not happy about it but it doesn't affect our ability to distribute it under the community edition rules. -Kurt
Re: Firefox/Iceweasel in OpenBSD
Henrik Enberg wrote: Date: Thu, 12 Oct 2006 11:11:52 -0400 From: Kurt Miller [EMAIL PROTECTED] On Thursday 12 October 2006 10:13 am, Tobias Ulmer wrote: We are modifying the source code, which is ok with the porting software paragraph in the document above, but contradicts with a private mail from Mike Connor where he writes about patching of app source violates their trademark. Oh well... Yes they are trying to exert a ridiculous level of control with their trademark but only when using the official branding. If they have given a project permission to use the official branding then any patch to firefox must first be approved by them. That's what all the fus is about. I'm not happy about it but it doesn't affect our ability to distribute it under the community edition rules. Actually, what the Mozilla people objected to in the whole Debian debacle seems to be that the package was called ;firefox+. I don't agree with your interpretation of the bug report. Debian already used the community edition version just like OpenBSD does. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354622 Again this is not the way I understand it. What happened there is not our concern or a topic for this list. They did things differently then we have. OpenBSD is complying with the published guidelines for the community edition. That is the only point that matters. If the Mozilla Foundation thinks differently, I'm sure they will contact us. -Kurt
Re: ld relocation error R_X86_64_32 from libc.a on amd64 building eclipse
Frederick C. Druseikis wrote: Greetings, In the build sequence below, ld issues a relocation error for libc.a(malloc.o), indicating it [libc.a, as I read it] should be recompiled with -fPIC Googling the key words in the message reveals a few of hits, all with similar advice; but the advice is directed to an application specific library, not libc Is this a generic issue for amd64? In a cosmic sense, probably not, we have a lot of shared libs building on the amd64. And FWIW I know that the same build sequence works on i386. A possibility is that there is a contradictory use of flags on the cc line, at least for the amd64. Does anybody have insight on this? Alternatively, should I take the advice and look for a work-around -- such as building my own libc with -fPIC ? This doesn't seem right for a port. I'm concerned about what else might break. The application in question is OpenBSD ports devel/eclipse-3.1p6, which is not currently qualified for the amd64, but hey, we're giving it a shot; there are only a about five cc compiles in the entire build, we're about 2/3 of the way through, and most of the job is ant and ecj, which are running quite happily on the amd64 jamvm/classpath. There's a lot more to do then adjust the 5 cc complies to get eclipse to run on amd64. I have an update to eclipse 3.2 with support for amd64. The current version of the diff is here: http://lists.codemonkey.net/pipermail/openbsd-java/2006-June/000784.html I'm literally walking out the door and be off the net for a week or so. Catch you later. I'm running OpenBSD 3.9-current (GENERIC) #556: Sat May 27 18:32:05 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC Regards, Fred Druseikis build.jars: [echo] Building libcore_3_1_0.so.2.0 [echo] cc -o libcore_3_1_0.so.2.0 -shared -fPIC -I/home/hubert/openbsd/ports/devel/eclipse/sdk/w-eclipse-sdk-3.1p6/plugins/org.eclipse.core.resources.openbsd/../org.eclipse.core.resources.openbsd/src/ -I/usr/local/exodus/include -I/usr/local/exodus/include/openbsd libcore_3_1_0.so.2.0 -static -lc [apply] /usr/bin/ld: /usr/lib/libc.a(malloc.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC [apply] /usr/lib/libc.a: could not read symbols: Bad value [apply] collect2: ld returned 1 exit status [apply] Result: 1
Re: ipv6 in openbsd 3.9
On Wednesday 07 June 2006 11:11 am, sonjaya wrote: dear all i try using ipv6 in my openbsd 3.9 box, here the step : i using ipv6 from : http://www.hexago.com/index.php?pgID=step1 and download client tunnel http://www.hexago.com/files/tspc-2.1.1-src.tgz and doing $ tar zxfv tspc-2.1.1-src.tgz $ cd tspc2 $ sudo make install target=openbsd installdir=/usr/local/tsp $ cd /usr/local/tsp/bin $ sudo vi tspc.conf -- edit as need $ /usr/local/tsp/bin/tsp -f /usr/local/tsp/bin/tscp.conf and try browsing and ping6 , traceroute6 to ipv6 server is working , also try browsing to webserver use ipv6 is detect from ipv6 Then i try install squid in that machine .. when my lan using that proxy still detect ipv4 my question how to set my openbsd 3.9 tunnel ipv6 can using NAT/ Proxy for my LAN so , when my comp in LAN browsing to website who using IPV6 can detect using ipv6 . I tried hexago and switched to SixXS which has been better for me. No tunnel broker needed. Get yourself a v6 subnet and forget NATing v6. Works nice for me. https://noc.sixxs.net/main/ http://www.sixxs.net/faq/connectivity/?faq=ossetupos=openbsd -Kurt
Re: Using OpenBSD article in 'The Jem Report'
On Sunday 30 April 2006 10:56 pm, Dave Feustel wrote: This is a very well written article for new users of OpenBSD: http://www.softwareinreview.com/cms/content/view/34/1/ One question I have: Is the description in the article of what's required to install Java on OpenBSD correct? The only thing that looked incorrect to me was the lack of a jre package. The port builds two packages; one for the jdk and one for the jre. You can install the jre using pkg_add or SUBPACKAGE=-jre make install. -Kurt
Re: How to find memory leak in library/OS?
On Thursday 30 March 2006 1:25 pm, Claus Assmann wrote: On Thu, Mar 30, 2006, Ted Unangst wrote: particular to pthreads, if you are using mutexes or somesuch on the stack, you will leak memory. (the lock on the stack is just a pointer, it gets allocated on first use). All mutexes are part of structures that are allocated via malloc(). Would those leak memory too (even if pthread_mutex_destroy() is called)? The application (it's the sendmail X address resolver) uses a new mutex/condition variable for every request in the test that triggers the leaks. Thanks for your answer! I recently went through a similar exercise looking for leaks in the jvm thread creation and destruction code. The process is simple but tedious. Build a debug version of libc, libpthread and your application. Put a break point on malloc, realloc free. When malloc and realloc are hit, do the finish gdb command and note the returned address on a pad and where it was called from. When free is called cross off the matching address from the list. Whatever is left is the source of your leak. There are things you could do help the process along, like using gdb's 'commands' feature. If you suspect the pthreads library is leaking you could place break points at the malloc / realloc / free calls that your application hits in pthreads (ie break at the calls to malloc in the pthread code, not at malloc itself). -Kurt
Re: Netbeans on jdk-5 OpenBSD
Edd Barrett wrote: Hello all, Soon I am required to write some java GUI's using netbeans for my university degree, so I have jumped ahead of the game and downloaded it and got it running on OpenBSD using kurt's port of jdk-5 (many thanks ;) ). However unfortunatley there appears to be some kind of display error / character encoding issue in the compile window. http://arameus.net/users/edd/dump/nb.jpg I have tried all sorts of combinations of LC_ALL and LANG, but no cigar. Also I tried the --locale switch of netbeans itself and changing fonts in options settings. Any Ideas? There's not much to go by. :( Can you make a minimal test program to reproduce the problem? Also, patchset 3 for 1.5 is close to being released. It contains one fix that might effect this. I'll update our port when it becomes available. -Kurt
isakmpd can't tear down phase 1 SA (3.8-beta/i386)
I'm not sure if my problem is user/configuration related or if there is a problem with isakmpd... I'd like to only initiate connections using the isakmpd.fifo as needed. When finished with the connection I was planning on tearing it down using the fifo too. When I tear down the phase 2 connection, phase 1 remains. Nothing I do seems to be able to tear down the phase 1 connection. The remote side tears down its phase 1 connection when the phase 2 one is gone (remote is a SonicWall in this case). When I attempt to reconnect to the remote site, isakmpd uses the old phase 1 and can't connect. I think this is a problem with isakmpd. Below are the commands I'm issuing and the isakmpd.result info after each step. Also the -DA=90 output for this sequence is available here: http://intricatesoftware.com:81/OpenBSD/misc/isakmpd.log $ sudo ksh -c echo c IPsec-Site1 /var/run/isakmpd.fifo $ sudo ksh -c echo S /var/run/isakmpd.fifo $ more /var/run/isakmpd.result SA name: ISAKMP-Site1 (Phase 1/Initiator) src: 172.16.1.24 dst: x.x.x.x Lifetime: 28800 seconds Soft timeout in 26429 seconds Hard timeout in 28791 seconds icookie af2b308c6583a724 rcookie 32ea88cc20420661 SA name: IPsec-Site1 (Phase 2) src: 172.16.1.24 dst: x.x.x.x Lifetime: 1200 seconds Soft timeout in 1056 seconds Hard timeout in 1191 seconds SPI 0: f3d26409 SPI 1: bda5bb6e Transform: IPsec ESP Encryption key length: 8 Authentication key length: 16 Encryption algorithm: DES Authentication algorithm: HMAC-MD5 Everything is working ok at this point. Now tear down IPsec-Site1 and check if phase 1 is still there. $ sudo ksh -c echo t IPsec-Site1 /var/run/isakmpd.fifo $ sudo ksh -c echo S /var/run/isakmpd.fifo $ more /var/run/isakmpd.result SA name: ISAKMP-Site1 (Phase 1/Initiator) src: 172.16.1.24 dst: x.x.x.x Lifetime: 28800 seconds Soft timeout in 26385 seconds Hard timeout in 28747 seconds icookie af2b308c6583a724 rcookie 32ea88cc20420661 I can't get rid of this entry using 't ISAKMP-Site1' or 'd af2b308c6583a724 -' or 'd 32ea88cc20420661 -' or even 'T'. Attempting to reconnect fails and looks like this: $ sudo ksh -c echo c IPsec-Site1 /var/run/isakmpd.fifo $ sudo ksh -c echo S /var/run/isakmpd.fifo $ more /var/run/isakmpd.result SA name: ISAKMP-Site1 (Phase 1/Initiator) src: 172.16.1.24 dst: x.x.x.x Lifetime: 28800 seconds Soft timeout in 26282 seconds Hard timeout in 28644 seconds icookie af2b308c6583a724 rcookie 32ea88cc20420661 SA name: unnamed (Phase 2) src: 172.16.1.24 dst: x.x.x.x SPI 0 not defined. SPI 1: bd55249b Transform: IPsec ESP Encryption key length: 0 Authentication key length: 0 Encryption algorithm: unknown (0) Authentication algorithm: none Note the Phase 2 garbage. I have to shutdown isakmpd to clean this up. Here's my isakmpd.conf: [General] Default-phase-1-lifetime= 28800,60:86400 [Phase 1] x.x.x.x=ISAKMP-Site1 [Phase 2] Passive-connections=IPsec-Site1 # Phase 1 ### [ISAKMP-Site1] Phase= 1 Address=x.x.x.x Configuration= SonicWall-main-mode Default=IPsec-Site1 Authentication= not ID= SonicWall-Phase1-ID # Phase 2 sections ## [IPsec-Site1] Phase= 2 ISAKMP-peer=ISAKMP-Site1 Configuration= SonicWall-quick-mode Local-ID= Default-Phase2-Local-ID Remote-ID= Site1-Phase2-Remote-ID # Client ID sections [SonicWall-Phase1-ID] ID-type=USER_FQDN Name= GroupVPN [Default-Phase2-Local-ID] ID-type=IPV4_ADDR Address=default [Site1-Phase2-Remote-ID] ID-type=IPV4_ADDR_SUBNET Network=172.31.5.0 Netmask=255.255.255.0 # Transform descriptions [SonicWall-main-mode] DOI=IPSEC EXCHANGE_TYPE= ID_PROT Transforms= 3DES-MD5 [SonicWall-quick-mode] DOI=IPSEC EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-DES-MD5-SUITE
Re: Negotiating a license for Sun Java on OpenBSD?
From: Michael W. Lucas [EMAIL PROTECTED] On Sat, Aug 06, 2005 at 01:12:24PM -0700, J.C. Roberts wrote: The FreeBSD guys sold their soul to Sun in a license agreement of some sort in order to use Sun's code as a base for their native implementation. Sorry, not quite. The FreeBSD-native Java implementation did not require changing any licenses in the base OS. Mind you, those poor bastards who donated their work and code to get Java running natively on FreeBSD may have sold their souls (or, at least, got badly taken), but that's a separate issue. I have spent considerable time getting Java working on OpenBSD. How I choose to spend my time is my choice. I've nethier sold my soul or have been badly taken. Piss off! The last time I tried it, the FreeBSD native Java ran fine on OpenBSD under emulation. At least it's a step closer than the Linux version. And, if you feel like donating your limited free time to Sun, the FreeBSD version is a better starting point than the Linux version. Stop spreading FUD. At least take a sec and look in /usr/ports/devel/jdk before posting this crap. -Kurt.
Re: Negotiating a license for Sun Java on OpenBSD?
From: Anon Y. Mous [EMAIL PROTECTED] Hi: Has anyone involved with OpenBSD development attempted to negotiate a license with Sun for a Java binaries usage agreement, (e.g., FreeBSD/Sun agreement)? As stated several times in this thread, the type of license that FreeBSD has with Sun goes against the projects goals. We will not be distributing jdk binary packages without a policy change from Sun. We do however have ports of Sun's jdk's that work and people can build their own packages rather easily. look in /usr/ports/devel/jdk. URL: http://www.freebsd.org/java/ The FreeBSD Foundation has negotiated a license with Sun Microsystems to distribute FreeBSD binaries for the Java Runtime Environment (JRE) and Java Development Kit (JDK). -minsai Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Negotiating a license for Sun Java on OpenBSD?
From: Michael W. Lucas [EMAIL PROTECTED] On Mon, Aug 08, 2005 at 10:05:38AM -0400, Kurt Miller wrote: From: Michael W. Lucas [EMAIL PROTECTED] On Sat, Aug 06, 2005 at 01:12:24PM -0700, J.C. Roberts wrote: The FreeBSD guys sold their soul to Sun in a license agreement of some sort in order to use Sun's code as a base for their native implementation. Sorry, not quite. The FreeBSD-native Java implementation did not require changing any licenses in the base OS. Mind you, those poor bastards who donated their work and code to get Java running natively on FreeBSD may have sold their souls (or, at least, got badly taken), but that's a separate issue. I have spent considerable time getting Java working on OpenBSD. How I choose to spend my time is my choice. I've nethier sold my soul or have been badly taken. Piss off! The last time I tried it, the FreeBSD native Java ran fine on OpenBSD under emulation. At least it's a step closer than the Linux version. And, if you feel like donating your limited free time to Sun, the FreeBSD version is a better starting point than the Linux version. Stop spreading FUD. At least take a sec and look in /usr/ports/devel/jdk before posting this crap. Kurt, Really, no disparagement was meant of your efforts. My apologies for any offense. I can't see spending my time working on Sun's code, but that's your choice, and if it works for you more power to you. Thanks for the apology. Your post struck a nerve and my frustration with the amount of misinformation in this thread came out. Few people really understand the Java - *BSD licensing issues. For what seems like ideological licensing preferences, people like to make noise and otherwise spout off. I choose to work on Java on OpenBSD because it was challenging and it represented the convergence of two of my interests. Do I like the licensing situation? No, but that didn't stop me from having fun, learning a lot and getting it work. So let us all move on and let this thread die already. :-) -Kurt
Re: Please help: DHCP over IPSec
From: Bruno S. Delbono [EMAIL PROTECTED] IKE-mode is good but can be buggy with some clients. The best Windows clients for a pure IPSec connection are: a) Safenet (OEM) SoftRemote version 10.x (versions 9.x do not support AES). * Danke Harondel! *. Safenet supports PSK and X509 certs. It has very good support and stability and I believe is the best of the bunch. SoftRemote can be purchased rather cheaply (~$40 US) under the name NetGear ProSafe VPN Client. -Kurt
Re: Eclipse + 3.7
From: Kurt Miller [EMAIL PROTECTED] The error you are having looks like you may have borked a src upgrade to some older -current. In any case, I would do the following to clean up the mess you have now. rm -rf /usr/include/g++ Download and install a snapshot including x*.tgz Upgrade all your packages from snapshots. Update your src and ports trees and then try rebuiding the jdk. BTW, the above procedure can not be used to get your system back to 3.7 release. You will still have cruft around like the somewhat current libstdc++ and who knows what else. If your intent is to run 3.7 then you will need to reinstall from scratch. -Kurt
