bluetooth problem
Hello all, I'm having trouble locating stuff like rfcomm, etc. in the ports tree. I would be very happy if someone can help me find a howto for bluetooth on openbsd. All I find is about freebsd, and that doesn't tell me where the actual software is. I get the following from dmesg: ubt0 at uhub3 port 2 configuration 1 interface 0 ubt0: vendor 0x1131 product 0x1001, rev 1.10/3.73, addr 3 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 So, I have a bluetooth device , right? But there's nothing in /dev that implies that. I'm very confused, any help will be much appreciated. Thanks -- Cengiz Bayazit
Re: bluetooth problem
On 12/13/06, Cengiz Bayazit [EMAIL PROTECTED] wrote: Hello all, I'm having trouble locating stuff like rfcomm, etc. in the ports tree. I would be very happy if someone can help me find a howto for bluetooth on openbsd. All I find is about freebsd, and that doesn't tell me where the actual software is. glycosine:ttyp1# cd /usr/ports/ glycosine:ttyp1# make search key=bluetooth Port: bluetooth-libs-20050716 Path: devel/bluetooth-libs Info: bluetooth network libraries Maint: Alexander Yurchenko [EMAIL PROTECTED] Index: devel net L-deps: B-deps: R-deps: Archs: any Port: bluetooth-tools-20050725 Path: net/bluetooth-tools Info: bluetooth network tools Maint: Alexander Yurchenko [EMAIL PROTECTED] Index: net L-deps: bluetooth.=1.0::devel/bluetooth-libs B-deps: R-deps: Archs: any -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: bluetooth problem
You will not be able to do anything useful with it anyway. OpenBSD bluetooth support is *unfinished*. On Wed, Dec 13, 2006 at 10:24:50AM -0700, Chris Kuethe wrote: On 12/13/06, Cengiz Bayazit [EMAIL PROTECTED] wrote: Hello all, I'm having trouble locating stuff like rfcomm, etc. in the ports tree. I would be very happy if someone can help me find a howto for bluetooth on openbsd. All I find is about freebsd, and that doesn't tell me where the actual software is. glycosine:ttyp1# cd /usr/ports/ glycosine:ttyp1# make search key=bluetooth Port: bluetooth-libs-20050716 Path: devel/bluetooth-libs Info: bluetooth network libraries Maint: Alexander Yurchenko [EMAIL PROTECTED] Index: devel net L-deps: B-deps: R-deps: Archs: any Port: bluetooth-tools-20050725 Path: net/bluetooth-tools Info: bluetooth network tools Maint: Alexander Yurchenko [EMAIL PROTECTED] Index: net L-deps: bluetooth.=1.0::devel/bluetooth-libs B-deps: R-deps: Archs: any -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: [Bacula-users] Building bacula on OpenBSD
Stop in /usr/local/src/bacula-1.38.11/src/stored. It looks to me like the OS' header file is badly broken -- at least in the sense that if it is a Unix system, both mt_fileno and mt_blkno should be defined in the struct mtget. Someone should fix the OS, barring that we will need a patch. Kern, Rus, et al: We have to be really careful with regard how we word things here. The way you assert that could be easily misinterpreted or misconstrued to have a vendor-bashing tone. Moreover, conceding the unavailability of compatibility with the OpenBSD platform doesn't gain us any additional users; a very large group of talented individuals with tremendous experience writing highly secure, reliable, and _portable_ code who could contribute greatly to the project. -- To set the record straight, and encourage mutual cooperation -- The reality here is that OpenBSD is very selective about where it focuses its development efforts, and the st(4) driver is not one of those places. Therefore, the assertion that The OS is broken is not correct, it simply hasn't been implemented or maintained as it should. Before I go on and make my own silly assertions, I should note: ' Things are always subject to change, and this is F/OSS and you're always welcome to do the work yourself or have corporate sponsorship. OpenBSD is not the platform for a Bacula director. You wont see it (at present) driving a 5-LTO3-drive, 2000 tape, 1000+ Terabyte StorageTek Powderhorn Tape Silo connected via Brocade FC switches.(1) However you will see it at the perimeter and on the wire keeping the packet kiddies from stealing all of your customers data. It could be the ideal system for the job with features like enhanced crypto acceleration via crypto(9) and the existing improvements on scsi(4) and recent HBA support. Anyway, not a director, not now at least, and probably not a SD Storage Daemon either. But most definitely a management console and file daemon. Russel: You'll probably notice that Bacula builds perfectly fine up until it gets to the director, then you get into OS-specific kernel knits and hooks where either OpenBSD lacks the framework/API (pthreads, st(4), etc.) or kernel-specific code needs to be added to Bacula. In the mean time, we should endeavor to create a bacula-clientonly Port in OpenBSD ports, or bacula port with a clientonly flavor. This has been done before, but the work was never commited (CC:) 1. http://www.arsc.edu/resources/silo.html I will take the lead on this if I have to. ~BAS I checked the man page for st, where all other Unix systems define the packet. They include no definition, so you will need to consult the header file directly sys/mtio.h. Sorry, but you are pretty much on your own on this. == Error in /usr/local/src/bacula-1.38.11/src/stored == ==Entering directory /usr/local/src/bacula-1.38.11/src/tools Make of tools is good
Re: [Bacula-users] Building bacula on OpenBSD
Here is a functional FD on OpenBSD 4.0/i386: bash-3.2# uname -a OpenBSD vmware-sandbox.pgh.priv.collaborativefusion.com 4.0 GENERIC.MP+RAIDFRAME#1 bash-3.2# /usr/local/sbin/bacula-fd -u root -g wheel -d128 -v -c /usr/local/etc/bacula-fd.conf -f vmware-sandbox-fd: jcr.c:129 read_last_jobs seek to 188 vmware-sandbox-fd: jcr.c:136 Read num_items=0 vmware-sandbox-fd: filed.c:223 filed: listening on port 9102 vmware-sandbox-fd: bnet_server.c:98 Addresses host[ipv4:0.0.0.0:9102] vmware-sandbox-fd: bnet.c:1154 who=client host=192.168.4.55 port=36387 vmware-sandbox-fd: find.c:81 init_find_files ff=-7e0f0be8 vmware-sandbox-fd: job.c:216 dird: Hello Director mindwipe-dir calling vmware-sandbox-fd: job.c:232 Executing Hello command. vmware-sandbox-fd: job.c:337 Calling Authenticate vmware-sandbox-fd: cram-md5.c:71 send: auth cram-md5 [EMAIL PROTECTED] ssl=0 vmware-sandbox-fd: cram-md5.c:131 cram-get: auth cram-md5 [EMAIL PROTECTED] ssl=0 vmware-sandbox-fd: cram-md5.c:150 sending resp to challenge: TS/yz8d8e9BM/gxwO9++iC vmware-sandbox-fd: job.c:341 OK Authenticate vmware-sandbox-fd: job.c:216 dird: JobId=0 Job=*Console*.2006-12-13_13.09.33 SDid=0 SDtime=0 Authorization=dummy vmware-sandbox-fd: job.c:232 Executing JobId= command. vmware-sandbox-fd: job.c:435 JobId=0 Auth=dummy vmware-sandbox-fd: job.c:216 dird: statusvmware-sandbox-fd: job.c:232 Executing status command. vmware-sandbox-fd: job.c:322 Calling term_find_files vmware-sandbox-fd: job.c:325 Done with term_find_files vmware-sandbox-fd: job.c:327 Done with free_jcr The code for this may be found at: http://people.collaborativefusion.com/~seklecki/obsd_bacula.html This illustrates basic support. I've submited sendbug(1) to OpenBSD GNATS, but it does not appear to have made it through: bash-3.2$ Nov 12 09:08:11 vmware-sandbox sm-mta[10302]: kACE7scF013066: to=[EMAIL PROTECTED], ctladdr=[EMAIL PROTECTED] (1016/10), delay=00:00:16, xdelay=00:00:16, mailer=esmtp, pri=31100, relay=cvs.openbsd.org. [199.185.137.3], dsn=4.3.0, stat=Deferred: 451 Temporary failure, please try again later. Possibly greylisting~ ~BAS On Wed, 13 Dec 2006, Brian A. Seklecki wrote: Stop in /usr/local/src/bacula-1.38.11/src/stored. It looks to me like the OS' header file is badly broken -- at least in the sense that if it is a Unix system, both mt_fileno and mt_blkno should be defined in the struct mtget. Someone should fix the OS, barring that we will need a patch. Kern, Rus, et al: We have to be really careful with regard how we word things here. The way you assert that could be easily misinterpreted or misconstrued to have a vendor-bashing tone. Moreover, conceding the unavailability of compatibility with the OpenBSD platform doesn't gain us any additional users; a very large group of talented individuals with tremendous experience writing highly secure, reliable, and _portable_ code who could contribute greatly to the project. -- To set the record straight, and encourage mutual cooperation -- The reality here is that OpenBSD is very selective about where it focuses its development efforts, and the st(4) driver is not one of those places. Therefore, the assertion that The OS is broken is not correct, it simply hasn't been implemented or maintained as it should. Before I go on and make my own silly assertions, I should note: ' Things are always subject to change, and this is F/OSS and you're always welcome to do the work yourself or have corporate sponsorship. OpenBSD is not the platform for a Bacula director. You wont see it (at present) driving a 5-LTO3-drive, 2000 tape, 1000+ Terabyte StorageTek Powderhorn Tape Silo connected via Brocade FC switches.(1) However you will see it at the perimeter and on the wire keeping the packet kiddies from stealing all of your customers data. It could be the ideal system for the job with features like enhanced crypto acceleration via crypto(9) and the existing improvements on scsi(4) and recent HBA support. Anyway, not a director, not now at least, and probably not a SD Storage Daemon either. But most definitely a management console and file daemon. Russel: You'll probably notice that Bacula builds perfectly fine up until it gets to the director, then you get into OS-specific kernel knits and hooks where either OpenBSD lacks the framework/API (pthreads, st(4), etc.) or kernel-specific code needs to be added to Bacula. In the mean time, we should endeavor to create a bacula-clientonly Port in OpenBSD ports, or bacula port with a clientonly flavor. This has been done before, but the work was never commited (CC:) 1. http://www.arsc.edu/resources/silo.html I will take the lead on this if I have to. ~BAS I checked the man page for st, where all other Unix systems define the packet. They include no definition, so you will need to consult the header file directly sys/mtio.h. Sorry, but you are pretty much on your own on this. == Error in
Re: [Bacula-users] Building bacula on OpenBSD
Just adding readline and OpenSSL support. Good to go now. ...OpenBSD doesn't have a portlint equiv, does it? ~BAS On Wed, 13 Dec 2006, GUILLON Gabriel wrote: This link: http://people.collaborativefusion.com/~seklecki/bacula_openbsd_port.tar seems to be broken Brian A. Seklecki a écrit : Here is a functional FD on OpenBSD 4.0/i386: bash-3.2# uname -a OpenBSD vmware-sandbox.pgh.priv.collaborativefusion.com 4.0 GENERIC.MP+RAIDFRAME#1 bash-3.2# /usr/local/sbin/bacula-fd -u root -g wheel -d128 -v -c /usr/local/etc/bacula-fd.conf -f vmware-sandbox-fd: jcr.c:129 read_last_jobs seek to 188 vmware-sandbox-fd: jcr.c:136 Read num_items=0 vmware-sandbox-fd: filed.c:223 filed: listening on port 9102 vmware-sandbox-fd: bnet_server.c:98 Addresses host[ipv4:0.0.0.0:9102] vmware-sandbox-fd: bnet.c:1154 who=client host=192.168.4.55 port=36387 vmware-sandbox-fd: find.c:81 init_find_files ff=-7e0f0be8 vmware-sandbox-fd: job.c:216 dird: Hello Director mindwipe-dir calling vmware-sandbox-fd: job.c:232 Executing Hello command. vmware-sandbox-fd: job.c:337 Calling Authenticate vmware-sandbox-fd: cram-md5.c:71 send: auth cram-md5 [EMAIL PROTECTED] ssl=0 vmware-sandbox-fd: cram-md5.c:131 cram-get: auth cram-md5 [EMAIL PROTECTED] ssl=0 vmware-sandbox-fd: cram-md5.c:150 sending resp to challenge: TS/yz8d8e9BM/gxwO9++iC vmware-sandbox-fd: job.c:341 OK Authenticate vmware-sandbox-fd: job.c:216 dird: JobId=0 Job=*Console*.2006-12-13_13.09.33 SDid=0 SDtime=0 Authorization=dummy vmware-sandbox-fd: job.c:232 Executing JobId= command. vmware-sandbox-fd: job.c:435 JobId=0 Auth=dummy vmware-sandbox-fd: job.c:216 dird: statusvmware-sandbox-fd: job.c:232 Executing status command. vmware-sandbox-fd: job.c:322 Calling term_find_files vmware-sandbox-fd: job.c:325 Done with term_find_files vmware-sandbox-fd: job.c:327 Done with free_jcr The code for this may be found at: http://people.collaborativefusion.com/~seklecki/obsd_bacula.html This illustrates basic support. I've submited sendbug(1) to OpenBSD GNATS, but it does not appear to have made it through: bash-3.2$ Nov 12 09:08:11 vmware-sandbox sm-mta[10302]: kACE7scF013066: to=[EMAIL PROTECTED], ctladdr=[EMAIL PROTECTED] (1016/10), delay=00:00:16, xdelay=00:00:16, mailer=esmtp, pri=31100, relay=cvs.openbsd.org. [199.185.137.3], dsn=4.3.0, stat=Deferred: 451 Temporary failure, please try again later. Possibly greylisting~ ~BAS On Wed, 13 Dec 2006, Brian A. Seklecki wrote: Stop in /usr/local/src/bacula-1.38.11/src/stored. It looks to me like the OS' header file is badly broken -- at least in the sense that if it is a Unix system, both mt_fileno and mt_blkno should be defined in the struct mtget. Someone should fix the OS, barring that we will need a patch. Kern, Rus, et al: We have to be really careful with regard how we word things here. The way you assert that could be easily misinterpreted or misconstrued to have a vendor-bashing tone. Moreover, conceding the unavailability of compatibility with the OpenBSD platform doesn't gain us any additional users; a very large group of talented individuals with tremendous experience writing highly secure, reliable, and _portable_ code who could contribute greatly to the project. -- To set the record straight, and encourage mutual cooperation -- The reality here is that OpenBSD is very selective about where it focuses its development efforts, and the st(4) driver is not one of those places. Therefore, the assertion that The OS is broken is not correct, it simply hasn't been implemented or maintained as it should. Before I go on and make my own silly assertions, I should note: ' Things are always subject to change, and this is F/OSS and you're always welcome to do the work yourself or have corporate sponsorship. OpenBSD is not the platform for a Bacula director. You wont see it (at present) driving a 5-LTO3-drive, 2000 tape, 1000+ Terabyte StorageTek Powderhorn Tape Silo connected via Brocade FC switches.(1) However you will see it at the perimeter and on the wire keeping the packet kiddies from stealing all of your customers data. It could be the ideal system for the job with features like enhanced crypto acceleration via crypto(9) and the existing improvements on scsi(4) and recent HBA support. Anyway, not a director, not now at least, and probably not a SD Storage Daemon either. But most definitely a management console and file daemon. Russel: You'll probably notice that Bacula builds perfectly fine up until it gets to the director, then you get into OS-specific kernel knits and hooks where either OpenBSD lacks the framework/API (pthreads, st(4), etc.) or kernel-specific code needs to be added to Bacula. In the mean time, we should endeavor to create a bacula-clientonly Port in OpenBSD ports, or bacula port with a clientonly flavor. This has been done before, but the work was never commited (CC:) 1. http://www.arsc.edu/resources/silo.html I will take the lead on this if I have to. ~BAS I
Re: [Bacula-users] Building bacula on OpenBSD
Hello,
Since this is directed to me, and assuming I wrote the double 'ed sections
below (which sound a lot like me but so much is snipped that I cannot be
sure), I can assure you that, my intention, if I am the guity party was not
to insult any person or any particular OS, but just to point out that it
appears to me to be an OS compatibility problem (actually a system header
file to be more correct).
See notes below, where I assume that I wrote the offending statements:
On Wednesday 13 December 2006 18:28, Brian A. Seklecki wrote:
Stop in /usr/local/src/bacula-1.38.11/src/stored.
It looks to me like the OS' header file is badly broken -- at least in the
sense that if it is a Unix system, both mt_fileno and mt_blkno should be
defined in the struct mtget.
Someone should fix the OS, barring that we will need a patch.
Kern, Rus, et al:
We have to be really careful with regard how we word things here. The
way you assert that could be easily misinterpreted or misconstrued to
have a vendor-bashing tone.
I'm sorry, I did not intend to be vendor bashing. I stand by what is written.
If it is a Unix system and there are not mt_fileno and mt_blkno in the struct
mtget, there are serious compatibility problems, since I don't have an
OpenBSD system, assuming the OS is not going to change, we would need a patch
to Bacula to fix it.
Moreover, conceding the unavailability of compatibility with the OpenBSD
platform doesn't gain us any additional users; a very large group of
talented individuals with tremendous experience writing highly secure,
reliable, and _portable_ code who could contribute greatly to the
project.
-- To set the record straight, and encourage mutual cooperation --
The reality here is that OpenBSD is very selective about where it
focuses its development efforts, and the st(4) driver is not one of
those places.
Therefore, the assertion that The OS is broken is not correct, it
simply hasn't been implemented or maintained as it should.
Yes, broken was a poor choice of words. I would rephrase it to say it is not
Unix compatible.
Before I go on and make my own silly assertions, I should note: '
Things are always subject to change, and this is F/OSS and you're
always welcome to do the work yourself or have corporate sponsorship.
OpenBSD is not the platform for a Bacula director. You wont see it (at
present) driving a 5-LTO3-drive, 2000 tape, 1000+ Terabyte StorageTek
Powderhorn Tape Silo connected via Brocade FC switches.(1)
However you will see it at the perimeter and on the wire keeping the
packet kiddies from stealing all of your customers data. It could be
the ideal system for the job with features like enhanced crypto
acceleration via crypto(9) and the existing improvements on scsi(4) and
recent HBA support.
Anyway, not a director, not now at least, and probably not a SD Storage
Daemon either.
Yes, since the problem above arises when compiling the SD.
But most definitely a management console and file daemon.
I think these already exist. Bacula does have some code to support OpenBSD.
Russel: You'll probably notice that Bacula builds perfectly fine up
until it gets to the director, then you get into OS-specific kernel
knits and hooks where either OpenBSD lacks the framework/API (pthreads,
st(4), etc.) or kernel-specific code needs to be added to Bacula.
Without a decent implementation of pthreads, even the client (file daemon)
will not build.
In the mean time, we should endeavor to create a bacula-clientonly
Port in OpenBSD ports, or bacula port with a clientonly flavor.
This has been done before, but the work was never commited (CC:)
1. http://www.arsc.edu/resources/silo.html
I will take the lead on this if I have to.
~BAS
I checked the man page for st, where all other Unix systems define the
packet.
They include no definition, so you will need to consult the header file
directly sys/mtio.h. Sorry, but you are pretty much on your own on this.
== Error in /usr/local/src/bacula-1.38.11/src/stored ==
==Entering directory /usr/local/src/bacula-1.38.11/src/tools
Make of tools is good
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Building bacula on OpenBSD
This link: http://people.collaborativefusion.com/~seklecki/bacula_openbsd_port.tar seems to be broken Brian A. Seklecki a écrit : Here is a functional FD on OpenBSD 4.0/i386: bash-3.2# uname -a OpenBSD vmware-sandbox.pgh.priv.collaborativefusion.com 4.0 GENERIC.MP+RAIDFRAME#1 bash-3.2# /usr/local/sbin/bacula-fd -u root -g wheel -d128 -v -c /usr/local/etc/bacula-fd.conf -f vmware-sandbox-fd: jcr.c:129 read_last_jobs seek to 188 vmware-sandbox-fd: jcr.c:136 Read num_items=0 vmware-sandbox-fd: filed.c:223 filed: listening on port 9102 vmware-sandbox-fd: bnet_server.c:98 Addresses host[ipv4:0.0.0.0:9102] vmware-sandbox-fd: bnet.c:1154 who=client host=192.168.4.55 port=36387 vmware-sandbox-fd: find.c:81 init_find_files ff=-7e0f0be8 vmware-sandbox-fd: job.c:216 dird: Hello Director mindwipe-dir calling vmware-sandbox-fd: job.c:232 Executing Hello command. vmware-sandbox-fd: job.c:337 Calling Authenticate vmware-sandbox-fd: cram-md5.c:71 send: auth cram-md5 [EMAIL PROTECTED] ssl=0 vmware-sandbox-fd: cram-md5.c:131 cram-get: auth cram-md5 [EMAIL PROTECTED] ssl=0 vmware-sandbox-fd: cram-md5.c:150 sending resp to challenge: TS/yz8d8e9BM/gxwO9++iC vmware-sandbox-fd: job.c:341 OK Authenticate vmware-sandbox-fd: job.c:216 dird: JobId=0 Job=*Console*.2006-12-13_13.09.33 SDid=0 SDtime=0 Authorization=dummy vmware-sandbox-fd: job.c:232 Executing JobId= command. vmware-sandbox-fd: job.c:435 JobId=0 Auth=dummy vmware-sandbox-fd: job.c:216 dird: statusvmware-sandbox-fd: job.c:232 Executing status command. vmware-sandbox-fd: job.c:322 Calling term_find_files vmware-sandbox-fd: job.c:325 Done with term_find_files vmware-sandbox-fd: job.c:327 Done with free_jcr The code for this may be found at: http://people.collaborativefusion.com/~seklecki/obsd_bacula.html This illustrates basic support. I've submited sendbug(1) to OpenBSD GNATS, but it does not appear to have made it through: bash-3.2$ Nov 12 09:08:11 vmware-sandbox sm-mta[10302]: kACE7scF013066: to=[EMAIL PROTECTED], ctladdr=[EMAIL PROTECTED] (1016/10), delay=00:00:16, xdelay=00:00:16, mailer=esmtp, pri=31100, relay=cvs.openbsd.org. [199.185.137.3], dsn=4.3.0, stat=Deferred: 451 Temporary failure, please try again later. Possibly greylisting~ ~BAS On Wed, 13 Dec 2006, Brian A. Seklecki wrote: Stop in /usr/local/src/bacula-1.38.11/src/stored. It looks to me like the OS' header file is badly broken -- at least in the sense that if it is a Unix system, both mt_fileno and mt_blkno should be defined in the struct mtget. Someone should fix the OS, barring that we will need a patch. Kern, Rus, et al: We have to be really careful with regard how we word things here. The way you assert that could be easily misinterpreted or misconstrued to have a vendor-bashing tone. Moreover, conceding the unavailability of compatibility with the OpenBSD platform doesn't gain us any additional users; a very large group of talented individuals with tremendous experience writing highly secure, reliable, and _portable_ code who could contribute greatly to the project. -- To set the record straight, and encourage mutual cooperation -- The reality here is that OpenBSD is very selective about where it focuses its development efforts, and the st(4) driver is not one of those places. Therefore, the assertion that The OS is broken is not correct, it simply hasn't been implemented or maintained as it should. Before I go on and make my own silly assertions, I should note: ' Things are always subject to change, and this is F/OSS and you're always welcome to do the work yourself or have corporate sponsorship. OpenBSD is not the platform for a Bacula director. You wont see it (at present) driving a 5-LTO3-drive, 2000 tape, 1000+ Terabyte StorageTek Powderhorn Tape Silo connected via Brocade FC switches.(1) However you will see it at the perimeter and on the wire keeping the packet kiddies from stealing all of your customers data. It could be the ideal system for the job with features like enhanced crypto acceleration via crypto(9) and the existing improvements on scsi(4) and recent HBA support. Anyway, not a director, not now at least, and probably not a SD Storage Daemon either. But most definitely a management console and file daemon. Russel: You'll probably notice that Bacula builds perfectly fine up until it gets to the director, then you get into OS-specific kernel knits and hooks where either OpenBSD lacks the framework/API (pthreads, st(4), etc.) or kernel-specific code needs to be added to Bacula. In the mean time, we should endeavor to create a bacula-clientonly Port in OpenBSD ports, or bacula port with a clientonly flavor. This has been done before, but the work was never commited (CC:) 1. http://www.arsc.edu/resources/silo.html I will take the lead on this if I have to. ~BAS I checked the man page for st, where all other Unix systems define the
x11/openmotif building package problem
Hi, Can anyone reproduce that? # cd /usr/ports/x11/openmotif cvs -q up -PAd # make show=USE_SYSTRACE Yes # make show=FLAVOR # make show=PKGNAMES openmotif-demos-2.1.30.5p0 openmotif-debuglibs-2.1.30.5p0 openmotif-2.1.30.5p2 # make build [...] # make fake [...] rm -f mwm cc -o mwm -O2 -fno-strict-aliasing -Wall -Wpointer-arith -Wundef -L../../exports/lib -L/usr/X11R6/lib -L/usr/local/lib -L../../imports/x11/lib WmCDInfo.o WmCDecor.o WmCEvent.o WmCPlace.o WmCmd.o WmColormap.oWmError.o WmEvent.o WmFeedback.oWmFunction.oWmGraphics.oWmIDecor.o WmIPlace.o WmIconBox.o WmImage.o WmInitWs.o WmKeyFocus.o WmMain.oWmManage.o WmMenu.oWmProperty.oWmProtocol.o WmResCvt.o WmResParse.oWmResource.oWmSignal.o WmWinConf.o WmWinInfo.o WmWinList.o WmWinState.oWmWsm.o WmXSMP.oversion.o ./WmWsmLib/libWsm.a -lXm -lXt -lSM -lICE -lXp -lXext -lX11 -L/usr/X11R6/lib -lm -Wl,-rpath-link,../../exports/lib cc: ./WmWsmLib/libWsm.a: No such file or directory *** Error code 1 Stop in /usr/ports/x11/openmotif/w-motif/motif/clients/mwm (line 1236 of Makefile). *** Error code 1 Stop in /usr/ports/x11/openmotif/w-motif/motif/clients (line 1267 of Makefile). *** Error code 1 Stop in /usr/ports/x11/openmotif/w-motif/motif (line 1391 of xmakefile). *** Error code 1 Stop in /usr/ports/x11/openmotif/w-motif/motif (line 201 of Makefile). *** Error code 1 Stop in /usr/ports/x11/openmotif (line 2111 of /usr/ports/infrastructure/mk/bsd.port.mk). -- best regards q#
New: telephony/chan_unistim
Unistim is the proprietary protocol used by Nortel i2004 and similar phones. chan_unistim is a revenged implementation of unistim for the Asterisk open source PBX; as such this port depends on Asterisk. Comments welcome on anything that needs improving before it goes in (e.g, it doesn't yet honor CC/CFLAGS). Tested with * running on amd64; also built on i386. Port is at http://www.darwinsys.com/openbsd/myports/chan_unistim.tar.gz Thx
Re: x11/openmotif building package problem
On Wed, Dec 13, 2006 at 11:59:47PM +, Mikolaj Kucharski wrote: Hi, Can anyone reproduce that? # cd /usr/ports/x11/openmotif cvs -q up -PAd # make show=USE_SYSTRACE Yes # make show=FLAVOR # make show=PKGNAMES openmotif-demos-2.1.30.5p0 openmotif-debuglibs-2.1.30.5p0 openmotif-2.1.30.5p2 # make build [...] # make fake [...] I've have just entered into same problem with x11/qt3. Maybe some will ask about limits, so here they are: # ulimit -a time(cpu-seconds)unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 1048576 stack(kbytes)8192 lockedmem(kbytes)315993 memory(kbytes) 946340 nofiles(descriptors) 128 processes1024 -- best regards q#
Re: x11/openmotif building package problem
* Mikolaj Kucharski [2006-12-14]: Can anyone reproduce that? If you have problems building a port and expect anyone to help you, it is mandatory to provide a build log. Nikolay
Re: x11/openmotif building package problem
* Mikolaj Kucharski [2006-12-14]: Can anyone reproduce that? not me Nikolay
Re: x11/openmotif building package problem
On Thu, Dec 14, 2006 at 06:44:49AM +0100, Nikolay Sturm wrote: * Mikolaj Kucharski [2006-12-14]: Can anyone reproduce that? If you have problems building a port and expect anyone to help you, it is mandatory to provide a build log. Currently I have similar problem with openmotif and qt3, logs are pleced in url below for both of them. I have build both of ports in this month without any problems. http://ports-wip.sourceforge.net/logs/x11/ -- best regards q#
