Re: call for testing: firefox 4.0beta9
> http://rhaalovely.net/stuff/amd64/mozilla-firefox-4.0b9.tgz > > or try those packages (built against somewhat -current, don't > > come crying if it doesn't install on your box due to dependencies > > not matching) Boo hoo. > http://rhaalovely.net/stuff/amd64/mozilla-firefox-4.0beta10.tgz > http://rhaalovely.net/stuff/amd64/mozilla-firefox-4.0beta11.tgz > http://rhaalovely.net/stuff/amd64/mozilla-firefox-4.0beta12.tgz This seems to basically work on my current/amd64, except that the Firefox Sync add-on refuses to install. "This add-on has not been updated to work with your version of Firefox"
Re: call for testing: firefox 4.0beta9
On Feb 27 11:30:37, Jan Stary wrote: > > http://rhaalovely.net/stuff/amd64/mozilla-firefox-4.0b9.tgz > > > or try those packages (built against somewhat -current, don't > > > come crying if it doesn't install on your box due to dependencies > > > not matching) > > Boo hoo. > > > http://rhaalovely.net/stuff/amd64/mozilla-firefox-4.0beta10.tgz > > http://rhaalovely.net/stuff/amd64/mozilla-firefox-4.0beta11.tgz > > http://rhaalovely.net/stuff/amd64/mozilla-firefox-4.0beta12.tgz > > This seems to basically work on my current/amd64, > except that the Firefox Sync add-on refuses to install. > > "This add-on has not been updated > to work with your version of Firefox" In fact, Firefox Sync comes bundled with the 4.* version. Sorry.
Re: Firefox sync extension
On Jan 30 01:42:02, Rafael Sadowski wrote: > firefox sync 1.6.2 extension don't work with OpenBSD Firefox. I get > "Error unknown" as error massage. Does anyone have a suggestion how I > can debug this? > System : -current (4.9-beta), amd64 and mozilla-firefox-3.6.13p2 On Jan 30 05:26:39, Hugo Osvaldo Barrera wrote: > I asked this on their list tome time ago, but never did manage to get it > running. > On firefox 3.X, it depends on a binary component not shipped for OpenBSD > (great portability, mozilla!). > > See here for more info: > https://groups.google.com/group/mozilla-labs-weave/browse_thread/thread/1645b57e8c8c9e6d On Jan 30 10:42:18, Landry Breuil wrote: > Try the firefox 4 betas, as it's supposedly bundled in... Yes it is. Trying to configure it on my 4.0beta12 (amd64): It longer says "Unknown error"; it accepts the login, the password, and the sync key, and does nothing, leaving me with the option of either clicking Next again a hundred times with no effect, or clicking Cancel, leaving my Sync unset.
NEW: productivity/douf00
Hey, This is a port for dou00, a light-weight presentation tool. Attached is also a port for print/py-poppler which provides python bindings for poppler and is a dependency of douf00. Comments? Ok? I don't have CVS commit rights. It would be nice if someone could import these ports into the tree. This is my first attempt of porting software to openbsd, so I would love to get some critique. regards, natano py-poppler.tar.gz Description: application/compressed-tar douf00.tar.gz Description: application/compressed-tar
Re: NEW: productivity/douf00
On 2011/02/27 12:53, Martin Natano wrote: > Hey, > > This is a port for dou00, a light-weight presentation tool. > Attached is also a port for print/py-poppler which provides python > bindings for poppler and is a dependency of douf00. > > Comments? Ok? > > I don't have CVS commit rights. It would be nice if someone could > import these ports into the tree. > > This is my first attempt of porting software to openbsd, so I would > love to get some critique. > > regards, > natano > This is a good first attempt at writing a port for OpenBSD, but it will need updating for -current, so if you'd like to get this in after the ports tree unlocks I'd suggest updating base and packages to a recent snapshot and getting things working there. So these need updating for -current, - *_DEPENDS style has changed (remove ::) - USE_X11 is no more - WANTLIB will probably need updating for newer cairo/X - douf00 needs USE_GROFF=yes, mandoc doesn't handle this manpage and these are the things that need changing anyway, - the python dependencies in py-poppler (py-gtk2, py-cairo) should be RUN_DEPENDS rather than LIB_DEPENDS - the COMMENT should be a bit more self-explanatory, at least mention that it's for PDFs
openldap-server-2.4.23p1 does not starts up via /etc/rc.d/slapd
Hello, ports@ readers. I have problem with starting openldap-server-2.4.23p1. I've setup /etc/openldap/slapd.conf and I can run slapd via command line by doing: $ sudo /usr/local/libexec/slapd -4d 2 @(#) $OpenLDAP: slapd 2.4.23 (Feb 16 2011 15:45:39) $ @i386.ports.openbsd.org:/usr/obj/i386/openldap-2.4.23/build-i386/servers/slapd bdb_monitor_db_open: monitoring disabled; configure monitor database to enable slapd starting But if I run $ sudo /etc/rc.d/slapd start I do not see running slapd instance among my processes. Are there someone who also faced this problem? I'm running OpenBSD-current i386.
Re: openldap-server-2.4.23p1 does not starts up via /etc/rc.d/slapd
On Sun, 27 Feb 2011, Igor Zinovik wrote: > Hello, ports@ readers. > > I have problem with starting openldap-server-2.4.23p1. > > I've setup /etc/openldap/slapd.conf and I can run slapd via command line > by doing: > > $ sudo /usr/local/libexec/slapd -4d 2 > @(#) $OpenLDAP: slapd 2.4.23 (Feb 16 2011 15:45:39) $ > > @i386.ports.openbsd.org:/usr/obj/i386/openldap-2.4.23/build-i386/servers/slapd > bdb_monitor_db_open: monitoring disabled; configure monitor database to enable > slapd starting > > But if I run > $ sudo /etc/rc.d/slapd start > > I do not see running slapd instance among my processes. Are there > someone who also faced this problem? > > I'm running OpenBSD-current i386. How are you running current? Is that a new installation or an upgrade? If you upgraded, did you use sysmerge(8)? root's dot.profile needs to be up to date. -- Antoine
Re: [UPDATE] iodine 0.5.2 -> 0.6.0-rc1
Hi Will,
William Orr wrote on Wed, Feb 23, 2011 at 10:34:14AM -0500:
> On Wed, Feb 23, 2011 at 10:23 AM, Ingo Schwarze wrote:
>> William Orr wrote:
>>> Index: net/iodine/pkg/iodined.rc
>>> ===
>>> RCS file: net/iodine/pkg/iodined.rc
>>> diff -N net/iodine/pkg/iodined.rc
>>> --- /dev/null 1 Jan 1970 00:00:00 -
>>> +++ net/iodine/pkg/iodined.rc 23 Feb 2011 14:32:46 -
>>> @@ -0,0 +1,8 @@
>>> +#!/bin/sh
>>> +
>>> +daemon=/usr/local/sbin/iodined
>>> +pexp=${daemon}
>>> +
>>> +. /etc/rc.d/rc.subr
>>> +
>>> +rc_cmd $1
>> pexp must be defined *after* sourcing rc.subr, or it will be overwritten.
That part is correct.
>> However, "${daemon} ${daemon_flags}" is the default, or just "${daemon}"
>> when ${daemon_flags} is unset, so you should not set it at all.
Sorry, that part was bad advice. As dcoppa@ and ajacoutot@ observed
as well, in this particular case, putting "pexp=${daemon}" makes
sense because the user might set iodine_flags in rc.conf.local(8).
> In rc.subr (or at least the one in -current), it checks for the
> existence of $pexp before setting it.
It does not, see
http://www.openbsd.org/cgi-bin/cvsweb/src/etc/rc.d/rc.subr?rev=1.20
The second line from the bottom is an unconditional
pexp="${daemon}${daemon_flags:+ ${daemon_flags}}"
That will override whatever you set before.
Yours,
Ingo
Re: NEW: productivity/douf00
Hey, thank you for the fast response. > So these need updating for -current, > > - *_DEPENDS style has changed (remove ::) > - USE_X11 is no more > - WANTLIB will probably need updating for newer cairo/X > - douf00 needs USE_GROFF=yes, mandoc doesn't handle > this manpage > > and these are the things that need changing anyway, > > - the python dependencies in py-poppler (py-gtk2, py-cairo) > should be RUN_DEPENDS rather than LIB_DEPENDS > - the COMMENT should be a bit more self-explanatory, > at least mention that it's for PDFs Attached are the updated ports. regards, natano douf00.tar.gz Description: application/compressed-tar py-poppler.tar.gz Description: application/compressed-tar
Re: Firefox sync extension
On Sun, Feb 27, 2011 at 11:50:18AM +0100, Jan Stary wrote: > On Jan 30 01:42:02, Rafael Sadowski wrote: > > firefox sync 1.6.2 extension don't work with OpenBSD Firefox. I get > > "Error unknown" as error massage. Does anyone have a suggestion how I > > can debug this? > > System : -current (4.9-beta), amd64 and mozilla-firefox-3.6.13p2 > > On Jan 30 05:26:39, Hugo Osvaldo Barrera wrote: > > I asked this on their list tome time ago, but never did manage to get it > > running. > > On firefox 3.X, it depends on a binary component not shipped for OpenBSD > > (great portability, mozilla!). > > > > See here for more info: > > https://groups.google.com/group/mozilla-labs-weave/browse_thread/thread/1645b57e8c8c9e6d > > On Jan 30 10:42:18, Landry Breuil wrote: > > Try the firefox 4 betas, as it's supposedly bundled in... > > Yes it is. Trying to configure it on my 4.0beta12 (amd64): > It longer says "Unknown error"; it accepts the login, > the password, and the sync key, and does nothing, > leaving me with the option of either clicking Next > again a hundred times with no effect, or clicking > Cancel, leaving my Sync unset. 2011-02-27 17:38:39 Service.Main WARN Failed to fetch symmetric keys. Failing remote setup. 2011-02-27 17:38:39 Service.Main WARN Remote setup failed. Here's what i get on the error console when trying to set an account. Grepping the source, it comes from services/sync/modules/service.js. I have to admit i never tried setting it. Apparently, some work is needed to manually build WeaveCrypto, according to https://wiki.mozilla.org/Services/Sync/FxSync/Developer/Building#Building_Crypto Landry
Re: Firefox sync extension
On Sun, Feb 27, 2011 at 05:50:42PM +0100, Landry Breuil wrote: > On Sun, Feb 27, 2011 at 11:50:18AM +0100, Jan Stary wrote: > > On Jan 30 01:42:02, Rafael Sadowski wrote: > > > firefox sync 1.6.2 extension don't work with OpenBSD Firefox. I get > > > "Error unknown" as error massage. Does anyone have a suggestion how I > > > can debug this? > > > System : -current (4.9-beta), amd64 and mozilla-firefox-3.6.13p2 > > > > On Jan 30 05:26:39, Hugo Osvaldo Barrera wrote: > > > I asked this on their list tome time ago, but never did manage to get it > > > running. > > > On firefox 3.X, it depends on a binary component not shipped for OpenBSD > > > (great portability, mozilla!). > > > > > > See here for more info: > > > https://groups.google.com/group/mozilla-labs-weave/browse_thread/thread/1645b57e8c8c9e6d > > > > On Jan 30 10:42:18, Landry Breuil wrote: > > > Try the firefox 4 betas, as it's supposedly bundled in... > > > > Yes it is. Trying to configure it on my 4.0beta12 (amd64): > > It longer says "Unknown error"; it accepts the login, > > the password, and the sync key, and does nothing, > > leaving me with the option of either clicking Next > > again a hundred times with no effect, or clicking > > Cancel, leaving my Sync unset. > > 2011-02-27 17:38:39 Service.Main WARN Failed to fetch > symmetric keys. Failing remote setup. > > 2011-02-27 17:38:39 Service.Main WARN Remote setup failed. > > Here's what i get on the error console when trying to set an account. > Grepping the source, it comes from services/sync/modules/service.js. > > I have to admit i never tried setting it. Apparently, some work is > needed to manually build WeaveCrypto, according to > https://wiki.mozilla.org/Services/Sync/FxSync/Developer/Building#Building_Crypto oh, fun. set services.sync.log.cryptoDebug to true, retry, here's what happens: WeaveCrypto: Trying NSS library without path WeaveCrypto: Trying again with path /usr/local/lib/firefox-4.0b12/libnss3.so.22.0 WeaveCrypto: init failed: Error: couldn't open library of course it fails, as we use systemwide nss in /usr/local/lib/libnss3.so.27.0 Landry
Re: openldap-server-2.4.23p1 does not starts up via /etc/rc.d/slapd
On Feb 27, Antoine Jacoutot wrote: > How are you running current? Is that a new installation or an upgrade? > If you upgraded, did you use sysmerge(8)? root's dot.profile needs to be > up to date. I updated sources, compiled new kernel, installed it, compiled new userland and installed it. After that I launched sysmerge -b. Thats all.
Re: openldap-server-2.4.23p1 does not starts up via /etc/rc.d/slapd
On 2011/02/27 22:27, Igor Zinovik wrote: > On Feb 27, Antoine Jacoutot wrote: > > How are you running current? Is that a new installation or an upgrade? > > If you upgraded, did you use sysmerge(8)? root's dot.profile needs to be > > up to date. > > I updated sources, compiled new kernel, installed it, compiled new > userland and installed it. After that I launched sysmerge -b. Thats > all. > With sysmerge -b you have to merge the files manually, did you do that (and, if you did that, did you miss merging any files?) In the first few months of /etc/rc.d, things evolved as new requirements were identified. If you still have an older rc.subr file, you are likely to have some problems.
Re: [UPDATE] iodine 0.5.2 -> 0.6.0-rc1
On Sun, Feb 27, 2011 at 9:06 AM, Ingo Schwarze wrote:
> Hi Will,
>
> William Orr wrote on Wed, Feb 23, 2011 at 10:34:14AM -0500:
>> On Wed, Feb 23, 2011 at 10:23 AM, Ingo Schwarze wrote:
>>> William Orr wrote:
>
Index: net/iodine/pkg/iodined.rc
===
RCS file: net/iodine/pkg/iodined.rc
diff -N net/iodine/pkg/iodined.rc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ net/iodine/pkg/iodined.rc 23 Feb 2011 14:32:46 -
@@ -0,0 +1,8 @@
+#!/bin/sh
+
+daemon=/usr/local/sbin/iodined
+pexp=${daemon}
+
+. /etc/rc.d/rc.subr
+
+rc_cmd $1
>
>>> pexp must be defined *after* sourcing rc.subr, or it will be overwritten.
>
> That part is correct.
>
>>> However, "${daemon} ${daemon_flags}" is the default, or just "${daemon}"
>>> when ${daemon_flags} is unset, so you should not set it at all.
>
> Sorry, that part was bad advice. As dcoppa@ and ajacoutot@ observed
> as well, in this particular case, putting "pexp=${daemon}" makes
> sense because the user might set iodine_flags in rc.conf.local(8).
>
>> In rc.subr (or at least the one in -current), it checks for the
>> existence of $pexp before setting it.
>
> It does not, see
>
> http://www.openbsd.org/cgi-bin/cvsweb/src/etc/rc.d/rc.subr?rev=1.20
>
> The second line from the bottom is an unconditional
>
> pexp="${daemon}${daemon_flags:+ ${daemon_flags}}"
>
> That will override whatever you set before.
>
> Yours,
> Ingo
>
Thanks so much for your help, guys. Here's the latest patch, with the
change to the rc script. I also bumped the revision number.
Let me know if there are any more problems with it.
Thanks!
Index: net/iodine/Makefile
===
RCS file: /cvs/ports/net/iodine/Makefile,v
retrieving revision 1.11
diff -u -r1.11 Makefile
--- net/iodine/Makefile 3 Dec 2010 07:47:44 - 1.11
+++ net/iodine/Makefile 28 Feb 2011 01:43:21 -
@@ -3,7 +3,7 @@
COMMENT= tunnel IPv4 data through DNS
DISTNAME= iodine-0.5.2
-REVISION= 0
+REVISION= 1
CATEGORIES=net
HOMEPAGE= http://code.kryo.se/iodine/
Index: net/iodine/patches/patch-man_iodine_8
===
RCS file: net/iodine/patches/patch-man_iodine_8
diff -N net/iodine/patches/patch-man_iodine_8
--- /dev/null 1 Jan 1970 00:00:00 -
+++ net/iodine/patches/patch-man_iodine_8 22 Feb 2011 04:43:52 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+--- man/iodine.8.orig Tue Jan 4 21:00:27 2011
man/iodine.8 Tue Jan 4 21:01:53 2011
+@@ -103,10 +103,10 @@ Print usage info and exit.
+ Keep running in foreground.
+ .TP
+ .B -u user
+-Drop privileges and run as user 'user' after setting up tunnel.
++Drop privileges and run as user 'user' after setting up tunnel.
Default is _iodine.
+ .TP
+ .B -t chrootdir
+-Chroot to 'chrootdir' after setting up tunnel.
++Chroot to 'chrootdir' after setting up tunnel. Default is /var/empty.
+ .TP
+ .B -d device
+ Use the TUN device 'device' instead of the normal one, which is dnsX on Linux
Index: net/iodine/pkg/PLIST
===
RCS file: /cvs/ports/net/iodine/pkg/PLIST,v
retrieving revision 1.3
diff -u -r1.3 PLIST
--- net/iodine/pkg/PLIST30 Mar 2009 09:17:45 - 1.3
+++ net/iodine/pkg/PLIST22 Feb 2011 04:45:28 -
@@ -4,3 +4,4 @@
@man man/man8/iodine.8
@bin sbin/iodine
@bin sbin/iodined
+@rcscript ${RCDIR}/iodined
Index: net/iodine/pkg/iodined.rc
===
RCS file: net/iodine/pkg/iodined.rc
diff -N net/iodine/pkg/iodined.rc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ net/iodine/pkg/iodined.rc 28 Feb 2011 01:49:58 -
@@ -0,0 +1,9 @@
+#!/bin/sh
+
+daemon=/usr/local/sbin/iodined
+
+. /etc/rc.d/rc.subr
+
+pexp=${daemon}
+
+rc_cmd $1
--
-Will Orr
Re: [UPDATE] iodine 0.5.2 -> 0.6.0-rc1
On Sun, 27 Feb 2011, William Orr wrote: > Index: net/iodine/pkg/iodined.rc > === > RCS file: net/iodine/pkg/iodined.rc > diff -N net/iodine/pkg/iodined.rc > --- /dev/null 1 Jan 1970 00:00:00 - > +++ net/iodine/pkg/iodined.rc 28 Feb 2011 01:49:58 - > @@ -0,0 +1,9 @@ > +#!/bin/sh > + > +daemon=/usr/local/sbin/iodined Please don't hardcode /usr/local here. -- Antoine
