NEW: mail/rcub-carddav 1.0.0
Hi all, Here is a CardDAV plugin for Roundcube. It works well against ownCloud's Contacts. The port should be reasonably clean, but I get two messages from portcheck that I don't know how to address: extra PERMIT_DISTFILES_FTP line(-s) extra PERMIT_PACKAGE_FTP lines (There is only one of each line). Any comment is welcome, though please keep my address CC'd, as I only check the list sporadically through GMane. Cheers. -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted. rcub-carddav-1.0.0.tgz Description: application/tar-gz signature.asc Description: PGP signature
Re: NEW: mail/rcub-carddav 1.0.0
Hey Stu, all On Fri, May 13, 2016 at 11:10:55AM +0100, Stuart Henderson wrote: > from a quick read-through: Thanks! > | PERMIT_PACKAGE_FTP =Yes > | PERMIT_DISTFILES_FTP = Yes > remove these Right, I deleted comments in the template too quickly, PERMIT_PACKAGE_CDROM is sufficient if both are Yes too. > | @owner www > | @group www > The program code should never be writable by www. *IF* it needs > to write any files at runtime, then just make the relevant files > or directories writable by www, but that's not needed for most > roundcube plugins. Yup, this seems to work without this. > | roundcubemail/plugins/carddav/composer.json > | @sample roundcubemail/plugins/carddav/config.inc.php > the way you have it, this copies composer.json to config.inc.php > at install time. along with getting rid of mv in do-install, > change those lines in PLIST to these: > > roundcubemail/plugins/carddav/composer.json > roundcubemail/plugins/carddav/config.inc.php.dist > @sample roundcubemail/plugins/carddav/config.inc.php Right. This would explain a lot of my confusing in porting things and seeing files disappearing... Thanks a lot for that! The rest of your comments were also addressed. See new archive attached. Thanks again! -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted. rcube-carddav-1.0.0.tgz Description: application/tar-gz signature.asc Description: PGP signature
NEW: www/php-simplepie-1.3.1
Hi all, Attached is a first attempt at packaging the SimplePie RSS-parsing library for PHP [0]. I doubt I did the packaging entirely properly, but it works as is on my 5.4 machine. Where I might have not done it properly: * Getting the code from GitHub: there is a lot of messing around with DISTNAME, PKGNAME, V and DIST_SUBDIR; I couldn't find a clearly standard way other ports (or GitHub...) do it. It might be worth adding a recipe in network.conf.template for that. * Installing the library (only) in /var/www/pear/lib. This is not a PEAR library that I know of, but this allows not to have to fiddle with the conf for PHP to find it. Other ports do it this way, e.g., www/php-markdown or www/php-openid. * Not installing any support file. I tried (they are commented out), but couldn't determine where they should go (all in /var/www?, /usr/share?, /usr/share/php-5.3?) The port also installs a compiled version of the library and symlinks it as simplepie.inc for backward compatibility. At the moment, SimplePie tries to create a cache in "./cache" for the PWD of the calling PHP script. I'm not sure whether we should pull it back to, e.g., [/var/www]/cache, as the current situation requires multiple directories to be writable by www, or at least for a writable cache directory to be created manually. All thoughts and comments are welcome. Thanks. [0] http://simplepie.org/ -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted. php-simplepie-1.3.1.tar.gz Description: application/tar-gz pgp7UbGMYoyz4.pgp Description: PGP signature
NEW: www/wallabag-1.6.0
Hi all, Attached is an OpenBSD port for Wallabag [0]. This is a self-hosted read-it-later application offering similar functionality as Readability or Poche. The port is pretty trivial, apart from some playing around with dependencies: Wallabag provides an archive (vendor.zip) containing a few PHP libraries from various vendors on which the webapp depends. While the port works well at the moment, I suspect there might be an issue when this vendor.zip archive needs be updated, as checksums might fail then. It would probably be better to have a vendor-1.6.0.zip archive, so we're sure what version we're getting (Wallabag devs are Cc'd to this email so they are aware of this potential issue). Apart from that, the port and webapp work nicely on 5.4-stable with httpd and php-5.3. [0] https://www.wallabag.org/ -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted. pgpYMEoq_XnPY.pgp Description: PGP signature
Re: NEW: www/wallabag-1.6.0
On Thu, Apr 10, 2014 at 11:51:06AM +1000, Olivier Mehani wrote: > Attached is an OpenBSD port for Wallabag [0]. This is a self-hosted > read-it-later application offering similar functionality as Readability > or Poche. As is often the case, this type of email is better with the attachment (thanks, Nicolas). -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted. wallabag-1.6.0.tar.gz Description: application/tar-gz pgpBcO8xD1WRB.pgp Description: PGP signature
[patch] Add static FLAVOR to www/cgit-8.3.5p1 (OPENBSD_5_1)
Hi all, Cgit in ports seems to be a ligtweight web interface to Git. However, to run its binary from ports in a chroot requires to copy a bunch of libraries in the chroot (or ???Premature end of script headers: /cgi-bin/cgit.cgi??? will ensue; `ldd /var/www/cgi-bin/cgit.cgi` is your friend), which I'd rather not. The attached patch to the Makefile fixes this by adding a static flavour to the port. I have it running on my 5.1 server at the moment, without shared libs, and it seems to behave fine, but I haven't tested it thoroughly yet. There might be a mistake in the way I handled the MODULES variable (it's unconditionally set), which might result in the -static package to have a spurious dependency. I'm happy to be corrected on that (: Hope this helps! -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Index: Makefile === @@ -23,8 +23,17 @@ USE_GMAKE =yes +FLAVORS= static +FLAVOR?= + MODULES = converters/libiconv +.if ${FLAVOR:L} == "static" +CFLAGS += -static +LDFLAGS += -static +MAKEFLAGS += CFLAGS+=-static LDFLAGS+=-static +.else WANTLIB += c crypto pthread z +.endif PREFIX = /var/www MAKE_FLAGS += V=1 NEEDS_LIBICONV=1 LDFLAGS+=-L${LOCALBASE}/lib
NEW: www/owncloud
Hi all, OwnCloud is a self-webhosting application providing file, music, calendar and other services through DAVisnh interfaces, from the comfort of your own server. It's a PHP application with a few dependencies. I packaged the latest version (4.5.0) for OpenBSD, and tested it summarily on 5.1/amd64, where it works nicely. The portfiles are attached. It's one of my first ports, and I'm a bit unuser about some details; let me know what you think. -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 www_owncloud.tar.gz Description: application/tar-gz
UPDATE: www/wallabag-1.8.0
Hi all, Here is an update to my previous OpenBSD port of the Wallabag read-it-later application [0]. From my initial post: The port is pretty trivial, apart from some playing around with dependencies: Wallabag provides an archive (vendor.zip) containing a few PHP libraries from various vendors on which the webapp depends. While the port works well at the moment, I suspect there might be an issue when this vendor.zip archive needs be updated, as checksums might fail then. It would probably be better to have a vendor-1.6.0.zip archive, so we're sure what version we're getting (Wallabag devs are Cc'd to this email so they are aware of this potential issue). Apart from that, the port and webapp work nicely on 5.4-stable with httpd and php-5.3. All comments are most welcome. [0] https://www.wallabag.org/ -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted. wallabag-1.8.0.tar.gz Description: application/tar-gz pgpdoicArYnfN.pgp Description: PGP signature
Re: UPDATE: www/wallabag-1.8.0
Hey Jiri, On Wed, Nov 12, 2014 at 03:11:48AM -0500, Jiri B wrote: > > The port is pretty trivial, apart from some playing around with > > dependencies: Wallabag provides an archive (vendor.zip) containing a > > few PHP libraries from various vendors on which the webapp depends. > Well recent OpenBSD policy about web apps is that it should need > some specific patching for OpenBSD to be as a port (or to be very > very popular so it's needed as a port > If a web app port just unpacks an archive then it doesn't need to > be a port. Fair enough. I'll keep maintaining it for myself, as I find it easier to have a single database of installed software. > Anyway, you can modify Makefile to use GITHUB* variables (see bsd.port.mk), > also change MESSAGE to readme file. Cheers for that, I'll adjust it. > I didn't test the port, when I tried wallabag i decided that it > does not fit 100% to my needs; if it would behave more like Zotero > then I would use it :) I see what you mean. The main advantage of Wallabag, or other read-it-later apps is that this let me postpone procrastination to a later time, and potentially another device. This is not a general purpose bookmarking system. -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted. pgpD9IrpJWA_K.pgp Description: PGP signature
NEW: security/fail2ban-0.9.1
Hi all, Here is a port for Fail2Ban [0]. I made it some time ago, but just realised that I never posted it here. I have culled the example files to what is relevant to OpenBSD, and altered the default configuration so it does the right thing out of the box (looking in the right paths, and using PF). It seems to work reasonably well on my machine, but please let me know of anything that needs to be adjusted in the port. Any feedback is welcome. [0] http://www.fail2ban.org/ -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted. fail2ban-0.9.1.tar.gz Description: application/tar-gz pgpHs_L6NbXPN.pgp Description: PGP signature
cgit-0.8.3.5p1 segfault on 5.0 GENERIC#53 amd64
Hi, I'm trying to run cgit on 5.0 GENERIC#53 amd64 on a VIA Nano U2250 (Dell XS11-VX8). But I get segfaults right at the start. I've tried both the binary package (cgit-0.8.3.5p1 from ftp.fr.openbsd.org) and one built from ports (same from OPENBSD_5_0 on anoncvs.fr.openbsd.org). In both cases, it segfaults in trim_end() (line 114 [0]: t[len] = '\0';) called from main() (line 686 [1]; both according to gdb*). This bit of code tries to trim the path after the last '/' in argv[0], whitc never seems to have one even when manually called from a different directory (e.g. ./cgi-bin/cgit.cgi). What is odd is that in trim_end(), at the previous line also references t[len] (c = t[len];), but doesn't fail there. c then changes to '\0' (and gdb says it's "not available"), supposedly at line 113, then the segfault occurs. len is 8, which is the length of str ("cgit.cgi"). However, there is some possibly dirty things happening as *t is a pointer equals to trim_end's argument const char *str. Could this be some protection forbidding functions to modifiy anything in the memory passed as const? Did anybody notice anything similar? Any idea on how to fix it or investigate it further? [0] http://hjemli.net/git/cgit/tree/shared.c?id=9e849950dc7c1f2fb6ffa62ab65bd30f35717d13#n114 [1] http://hjemli.net/git/cgit/tree/cgit.c?id=9e849950dc7c1f2fb6ffa62ab65bd30f35717d13#n686 * Starting program: /srv/www/cgi-bin/cgit.cgi Program received signal SIGSEGV, Segmentation fault. [Switching to process 28106, thread 0x203488800] trim_end (str=0x56bc08 "cgit.cgi", c=0 '\0') at shared.c:114 114 t[len] = '\0'; (gdb) bt #0 trim_end (str=0x56bc08 "cgit.cgi", c=0 '\0') at shared.c:114 #1 0x00404f76 in main (argc=1, argv=0x7f7c5800) at cgit.c:686 -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655
Re: cgit-0.8.3.5p1 segfault on 5.0 GENERIC#53 amd64
In gmane.os.openbsd.ports, you wrote: > On Mon, Mar 12, 2012 at 12:56:36PM +0000, Olivier Mehani wrote: >> However, there is some possibly dirty things happening as *t is a >> pointer equals to trim_end's argument const char *str. Could this be >> some protection forbidding functions to modifiy anything in the memory >> passed as const? > /etc/malloc.conf ? Right. I wasn't aware of that. Thanks for the pointer. However, nothing special is set there (neither the symlink nor the environment variable). I confirmed that the problem seems to be due to the const manipulation addness, as the following test program segfaults in the same way. int test (const char* a) { char *t=a; t[0]='a'; return 0; } int main() { test("bbba"); return 0; } GCC also complains when this get compiled but, oddly enough, not the port when compiling shared.c... >> Did anybody notice anything similar? Any idea on how to fix it or >> investigate it further? > Never had any issue on amd64 since i've imported it. You may discuss it > with upstream... or try the new versions (0.9.0.2 is in current) Yeah, the code for that function actually changed to something cleaner [0,1]. I'm not too keen on upgrading this server to current, but backporting the patch [0] with the following as patches/patch-shared_c seems to fix the problem. $OpenBSD$ --- shared.c.orig Sat Mar 5 13:52:39 2011 +++ shared.cWed Mar 14 05:12:25 2012 @@ -98,23 +98,17 @@ void *cgit_free_commitinfo(struct commitinfo *info) char *trim_end(const char *str, char c) { int len; - char *s, *t; if (str == NULL) return NULL; - t = (char *)str; - len = strlen(t); - while(len > 0 && t[len - 1] == c) len--; - + len = strlen(str); + while(len > 0 && str[len - 1] == c) + len--; if (len == 0) return NULL; - c = t[len]; - t[len] = '\0'; - s = xstrdup(t); - t[len] = c; - return s; + return strndup(str, len); } char *strlpart(char *txt, int maxlen) Thanks for your help! [0] http://hjemli.net/git/cgit/diff/shared.c?id=v0.8.3.5&id2=master [1] http://hjemli.net/git/cgit/tree/shared.c?id=master#n102 -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655
Re: teTeX
On Fri, May 09, 2008 at 12:36:53AM -0700, Daniel Thomas Nevistic wrote: > I've been trying to find TeX for 4.3 but can not find it in ports. > I believe that teTeX is the UNIX TeX program which has TeX and the LaTeX2e > macros package for it. Same here. I updated from 4.2 to 4.3, then did the same for the packages to discover that (at the time I did that i.e., two or three days ago), teTeX was cruelly missing. -- Olivier Mehani <[EMAIL PROTECTED]> PGP fingerprint: 3720 A1F7 1367 9FA3 C654 6DFB 6845 4071 E346 2FD1
Re: teTeX
On Fri, May 09, 2008 at 10:23:46AM +0200, Paul de Weerd wrote: > > I've been trying to find TeX for 4.3 but can not find it in ports. > Edd Barrett has done a lot of work on porting TeXLive, the actively > maintained TeX distribution. This ought to provide you with what > you're looking for. Are you aware of any no_x11 version? -- Olivier Mehani <[EMAIL PROTECTED]> PGP fingerprint: 3720 A1F7 1367 9FA3 C654 6DFB 6845 4071 E346 2FD1
Re: gnu ghostscript port bug
On Tue, Jun 17, 2008 at 12:36:52PM +0800, Dongsheng Song wrote: > # cd /usr/ports/print/ghostscript/gnu > # make install > ... > checking for C compiler default output file name... > configure: error: C compiler cannot create executables > See `config.log' for more details. What does the config.log say? -- Olivier Mehani <[EMAIL PROTECTED]> PGP fingerprint: 3720 A1F7 1367 9FA3 C654 6DFB 6845 4071 E346 2FD1 pgpWysn0kvYJt.pgp Description: PGP signature
Building a port tries to install an older libtool version
Hi list, (Hope this is the right ML Considering it's port-related, I reckoned ports@ was the one.) I'm trying to build a port (jabberd14-1.6.0b8 from [0], to be precise) on a system on which libtool has already been installed as a binary package: $ pkg_info | grep libtool libltdl-1.5.22p3GNU libtool system independent dlopen wrapper libtool-1.5.22p14 generic shared library support script When making the port, though, the system tries to install an older version: $ make ===> jabberd14-1.6.0-mysql depends on: libtool-1.5.8 - not found ===> Verifying install for libtool-1.5.8 in devel/libtool ===> Checking files for libtool-1.5.8 `/usr/ports/distfiles/libtool-1.5.8.tar.gz' is up to date. >> Checksum OK for libtool-1.5.8.tar.gz. (sha1) ... I have checked in the port files, and apart from a (rather expected) mention of the need for libtool (USE_LIBTOOL=Yes) in the main Makefile, nothing is found. Specifically no mention is made about the libtool version to be used. I do not understand where the port system decides it needs the older version of libtool, nor why it cannot use the more recent already installed. Do anyone of you have an idea/explanation or advice about this problem and how to solve it? Thanks (: [0] http://www.studis.de/Software/jabberd14-1.6.0b8.tgz -- Olivier Mehani <[EMAIL PROTECTED]> PGP fingerprint: 3720 A1F7 1367 9FA3 C654 6DFB 6845 4071 E346 2FD1 pgpNcNtElfD38.pgp Description: PGP signature
Re: Building a port tries to install an older libtool version
On Tue, Aug 12, 2008 at 02:38:52AM -0400, Brad wrote: > > I'm trying to build a port (jabberd14-1.6.0b8 from [0], to be precise) > > on a system on which libtool has already been installed as a binary > > package: > > When making the port, though, the system tries to install an older > > version: > > Do anyone of you have an idea/explanation or advice about this problem > > and how to solve it? > First off.. you did not specify which version of OpenBSD you are using. Based > on the libtool version you have installed I would guess a snapshot just past > the 4.0 release. OpenBSD 4.3, but updated from older version (that used to be a 4.0 fresh install). > >From the version of libtool trying to be installed it looks as if the ports > >tree > on this system is from 3.6. The ports tree should be updated to match the > release > of the base system that you are currently using. Damnation, you're right. I dug out a port-tree upgrading script and used it without checking. It actually contains a "cvs -z9 get -rOPENBSD_3_6 -P ports"... Stupid me. Anyway, for the sake of curiosity, where are these version number defined? Thanks for your insight. -- Olivier Mehani <[EMAIL PROTECTED]> PGP fingerprint: 3720 A1F7 1367 9FA3 C654 6DFB 6845 4071 E346 2FD1 pgpluSDmV8Gb8.pgp Description: PGP signature
Re: [New] gnupg2
On Tue, Jun 01, 2010 at 01:52:40PM +0200, Pierre-Emmanuel André wrote: > This is a port for gnupg2 It builds and works on 4.7 GENERIC#112 amd64 after manually installing CURRENT ports for libassuan and libgpg-error. > The following diff for gnupg1 is needed to permit the installation > of both 1 & 2 at the same time. I didn't try this part. > It could be fun if someone could test this port with a gnupg smartcard. Hum, I actually have a card reader that I just set up under Linux [0]. My 4.7 is on a remote machine, but I'll try to track down a spare machine and put a fresh 4.8 on it to try it all. [0] http://www.narf.ssji.net/~shtrom/wiki/tips/openpgpsmartcard -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 pgpzyx4m0UYAp.pgp Description: Cryptographic signature
SCM SCR335 SmartCard reader works OK with GnuPG 2 (was Re: [New] gnupg2)
Ahoy, On Wed, Nov 03, 2010 at 07:31:38AM +0100, David Coppa wrote: > >> It could be fun if someone could test this port with a gnupg smartcard. > > Hum, I actually have a card reader that I just set up under Linux [0]. > > My 4.7 is on a remote machine, but I'll try to track down a spare > > machine and put a fresh 4.8 on it to try it all. > It doesn't work. At least the OpenPGP SmartCard V2 I have. > This card requires pcsc-lite and ccid. I've ported both and they worked. > My work stopped trying to make scdaemon working: threading issues made > me give up. I just found time, over the week end, to install 4.8 on said spare machine. My SCM SCR335 USB reader works nicely out of the box with just gnupg-2-0-15. No need for pcsc-lite nor ccid. After starting the GPG agent, I could list and use the keys, both for signing, decryption AND remote SSH login. I jotted down some doc here [0]. Next step is trying to see how to do system auth as well! (; [0] https://www.narf.ssji.net/~shtrom/wiki/tips/openpgpsmartcard#doing_the_same_with_openbsd_48 -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 pgp2TYsj342gf.pgp Description: PGP signature