Re: squid reorg.
Hi, On Sun, Nov 03, 2013 at 09:23:01PM +, Stuart Henderson wrote: > The diff at http://junkpile.org/squid.reorg.diff (not inline as it's 360kB) > reorganises the squid ports; it removes squid27 now that the main squid port > works on more arches, and splits www/squid into stable (with the latest > 3.3 release) and snapshot (adding a 3.4 release). > > It also enables the rock storage backend (particularly useful for people > playing with the SMP support) and builds a few more helper applications > (mostly switched from "build a fixed list of helpers" to "build everything > we can and then remove what we don't want"). > > Any comments, OKs? I just swapped out Squid 3.3.8 from a 5.4 machine because of severe problems: The proxy crashed frequently with this line in cache.log: FATAL: Too few filedescriptors available in the system (97 usable of 8192). But I had this in /etc/squid/squid.conf: max_filedescriptors 1024 I also had this in my /etc/login.conf: proxy:\ :ignorenologin:\ :datasize=infinity:\ :maxproc=128:\ :openfiles=1024:\ :stacksize-cur=64M:\ :localcipher=blowfish,8:\ :tc=default: And I had the login class set to 'proxy' using vipw. Now I have renamed the login class to 'squid' and the 2.7 squid at least starts with this message: With 1024 file descriptors available Don't know whether the 3.4 line works better... I never had problems with squid on that machine since 3.x or 4.x, when I originally installed it, so I guess that it's squid 3.3.8 which was causing the problems. IOW, I'd probably rather kick out 3.3 instead of 2.7. Kind regards, --Toni++
Re: squid reorg.
Hi Stuart, On Thu, Jan 09, 2014 at 06:20:26PM +, Stuart Henderson wrote: > On 2014/01/09 17:48, Toni Mueller wrote: > > > > proxy:\ > > :ignorenologin:\ > > :datasize=infinity:\ > > :maxproc=128:\ > > :openfiles=1024:\ > > :stacksize-cur=64M:\ > > :localcipher=blowfish,8:\ > > :tc=default: > > > > > > And I had the login class set to 'proxy' using vipw. > > > Now I have renamed the login class to 'squid' and the 2.7 squid at least > > starts with this message: > > > > With 1024 file descriptors available > > > > Don't know whether the 3.4 line works better... > > > You don't mention how you start squid, but if you use the rc.d script, > the class *must* be named after the daemon, i.e. "squid". yes, I use the rc.d script, but was not aware of this requirement. But squid did not respect the config file setting either, which motivated me to downgrade the package. > As a proxy is > necessarily FD-hungry I made sure the pkg-readme specifically covers this.. Of course - but I have kern.maxfiles = 16000, and still saw the problem. The kernel is 5.4 stable, now with an additional patch to silence bge(4) buffer overrun errors (based on a tip that Mike gave on misc@). > 2.7 hasn't been developed upstream for years, Ok... :/ > do you have enough information that you could file a bug or at least > write a mail to their list about the handling when out of FDs? Last > time I brought this up there, I got the impression squid is meant to > handle this more cleanly.. Hmmm? I'm not sure what exactly you or they night want or need. I have these "fatal" notices in the log file and complaints of the users that Internet does not work. Is there a way that I can inspect the limits in effect for a given running process? Kind regards, --Toni++
Re: squid reorg.
On Thu, Jan 09, 2014 at 08:08:04PM +, Stuart Henderson wrote: > On 2014/01/09 20:39, Toni Mueller wrote: > > Of course - but I have kern.maxfiles = 16000, and still saw the problem. > > squid can't itself do anything to raise the limit above what you > have set in login.conf, kern.maxfiles is irrelevant if the login.conf > limit for the class is lower. Yes - I only wanted to say that squid should imho not run into limits imposed elsewhere. > > I'm not sure what exactly you or they night want or need. I have these > > "fatal" notices in the log file and complaints of the users that > > Internet does not work. > > If squid runs out of FDs, the idea is that it should clamp the > connection limit to below what it finds it can use (though some people > have occasionally run into high-cpu loops in that situation). The cpu on that box is basically idle. > If you don't have a "squid" class and use rc.d/squid, it will use > limits from "daemon", default 128 iirc. This might be beyond what it > can cope with so perhaps it just exits, I'm not sure what is the > intended behaviour then. Strange - it logged that it started with 8192 file descriptors, which is way beyond what I specified in two locations (also in the config file!), and what is in the 'daemon' login class. I have no idea where it gets this value from, or the minimum value I can configure there. Imho, problem #1 is that it ignores the config file setting, and problem #2 is that it does not gracefully cope with the "out of FD" situation. http://www.squid-cache.org/Doc/config/max_filedescriptors/ > sudo -c squid sh -c "ulimit -n" > sudo -c daemon sh -c "ulimit -n" Thank you! That gets me the expected values... Kind regards, --Toni++
New Maintainers Wanted
Hi, @David: thanks for putting in some work and reminding me to do this... On Sun, May 13, 2012 at 05:30:21PM -0400, David Hill wrote: > Date: Sun, 13 May 2012 17:30:21 -0400 > From: David Hill > To: ports@openbsd.org @all: Please take over all my ports and remove me from maintainership, as I am currently, and in the forseeable future, unable to properly maintain them. TIA! Kind regards, --Toni++
Re: UPDATE: bzr 1.8
Hi, On Sat, 25.10.2008 at 15:06:00 +0200, Bernd Ahlers wrote: > Brad [Sat, Oct 25, 2008 at 05:50:50AM -0400] wrote: > >Here is an update to bzr 1.8. > Regress tests crash on amd64 and i386. Did you run them? I've just reproduced the problem with bzr 1.10, and am going to ship the test results to upstream. -- Kind regards, --Toni++
Re: UPDATE: bzr 1.8
Hi, On Fri, 02.01.2009 at 22:31:42 +0100, Toni Mueller wrote: > On Sat, 25.10.2008 at 15:06:00 +0200, Bernd Ahlers wrote: > > Brad [Sat, Oct 25, 2008 at 05:50:50AM -0400] wrote: > > >Here is an update to bzr 1.8. > > Regress tests crash on amd64 and i386. Did you run them? > > I've just reproduced the problem with bzr 1.10, and am going to ship > the test results to upstream. please see https://bugs.edge.launchpad.net/bzr/+bug/314247 -- Kind regards, --Toni++
Semi-OT: Re: update & gc all three maintained python ports
Hi, On Sat, 27.12.2008 at 10:39:10 +1100, Damien Miller wrote: > This (large) diff updates and garbage collects all three Python > ports: > 2.4.4 => 2.4.8 > 2.5.2 => 2.5.4 > 2.6 => 2.6.1 stupid question, perhaps, but would it be a good idea to hack at P3.0? Or do you think it's too early? http://www.python.org/download/releases/3.0/ Kind regards, --Toni++
Re: RESUBMIT: sysutils/apcupsd
Hi, On Sat, 03.01.2009 at 20:51:40 +0300, Kirill S. Bychkov wrote: > This is a resubmit of apcupsd port. > Any comments/oks? I have no comment on the port, just a question: What would be the advantage of using apcupsd in favour of nut? Kind regards, --Toni++
Re: [new] www/varnish
Hi, On Mon, 10.11.2008 at 11:59:50 -0500, Jim Razmus wrote: > This really needs testing on different archs before commit. My sun > servers are toast. Only tested on i386. > > Port available here: http://www.bonetruck.org/tmp/varnish.tgz I can't find this tarball, and neither a commit. Also, there's varnish 2.0.2... Can you please make it available again? TIA! -- Kind regards, --Toni++
Re: [TESTING] www/varnish-beta1
Hi,
On Tue, 09.09.2008 at 15:18:46 +0200, Landry Breuil wrote:
> I had a quick look to your port only ports-wise, but why not adding
> something like LDFLAGS=-pthread instead of patching Makefile.am and re-running
> it built fine here without patches and with
> CONFIGURE_ENV+="LDFLAGS=-pthread" in port Makefile..
I tried this in a port for 2.0.2 I started to work on before I became
aware of Jim's work, but the threads library wasn't properly detected
anyway (amd64). Instead, I got an error message like "have found
threading, but can't compile it, notify upstream".
For reference, the gist of the Makefile is currently:
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=varnish/}
BUILD_DEPENDS= :automake->=1.9:devel/automake/1.9 \
:libtool->=1.5:devel/libtool
CONFIGURE_STYLE=gnu
CONFIGURE_ENV+="LDFLAGS=-pthread"
CONFIGURE_ARGS= --prefix=${SYSCONFDIR}/varnish \
--localstatedir=/var/varnish \
--enable-stack-protector
Kind regards,
--Toni++
Re: www/varnish
Hi Jim, thanks for posting. On Sat, 17.01.2009 at 23:06:38 -0500, Jim Razmus wrote: > I dropped the maintainer line from the Makefile. I've gone with Movable > Type and don't need or want an HTTP accelerator anymore. This caught my curiosity. What were you using Varnish for, before? I'm also in the situation to host Movable Type, but as of late, got rather disenchanted with it. -- Kind regards, --Toni++
NEW: p5-Danga-Socket
Hi, I've packaged Danga::Socket, which is helps creating high-performance servers. This module is needed for perlbal, which I'm about to create a port for, too. Please test and send feedback. Kind regards, --Toni++ p5-Danga-Socket.tgz Description: GNU Unix tar archive
Re: www/varnish
Hi Jim, thanks for answering. On Sun, 18.01.2009 at 12:30:41 -0500, Jim Razmus wrote: > Varnish is a reverse caching HTTP proxy more or less. It allocates a > chunk memory and then caches the output from backend web servers to > serve future requests itself. It's like squid, but arguably more > efficient and scalable. This is all known - I'm in the Plone crowd, and want to enhance our Plone hosting with varnish. > Varnish could be advantageous when used in conjunction with truly dynamic > web applications. Word Press and Plone I believe create everything > dynamically for all requests. They have caching plug-ins available > though... I can only speak about Plone. Yes, Plone has caching modules built in, but they do different things than those that varnish can do. But Plone can talk to varnish and tell it which pages (or other items) are out of date, so it is generally said that varnish can provide great relief to Plone servers, and I also subscribe to the idea that varnish is better than squid, pound or Apache for reverse-proxying. > Movable Type creates static html files for subsequent delivery by your > web server. Known... This page generation can take quite a while, too. [ we should probably move off ports@ ] Did you look at Reed Cartwright's addons? > The "dynamic" nature of Movable Type only comes about when > creating a new entry/page and/or adding a comment to a page/entry at > which time it just creates an updated html file. Any decent web server > should be able to choke your Internet connection serving static content > from the file system. So Varnish is mostly redundant redundant in this > case. This may be true, although I see quite an unhealthy tendency in Movable Type to "retrofit" true dynamic posting via PHP (**YUCK**) plugins. Combined with some other problems in MTOS4 (I have MTOS4.21 atm), I'm almost ready to ditch it, although I'd still like to discuss MT4 hosting with you, probably offline. -- Kind regards, --Toni++
Re: NEW: p5-Danga-Socket
Hi, On Sun, 18.01.2009 at 18:59:19 +0100, Toni Mueller wrote: > Please test and send feedback. I was a bit rash. There are probably some patches missing. =8-| -- Kind regards, --Toni++
Re: NEW: p5-Danga-Socket (fixed)
Hi, sorry about the blunder, but initially, I forgot a dependency. The new port is attached... -- Kind regards, --Toni++ p5-Danga-Socket.tgz Description: GNU Unix tar archive
NEW: p5-Sys-Syscall
Hi, I've packaged Sys::Syscall which exposes some more system calls to Perl programs than are available through stock Perl. This port is required by Danga::Socket. Please test and send feedback. Kind regards, --Toni++ p5-Sys-Syscall.tgz Description: GNU Unix tar archive
HELP WANTED: sysutils/p5-IO-AIO
Hi, I'm in the process of creating a port for perlbal from Danga, and noticed that the self-tests don't all run to completion. This is partially due to not having IO::AIO. So I thought, why not create a port for IO::AIO, too, but while creating the port's mechanics was quite easy, it looks like this module is not yet compatible with *BSDs, due to threading issues. Anyway, when I run the selftest suite on IO::AIO, the test run simply locks up on the second test. I'm not enough of a C guru, or at least not enough at leisure atm, to dig into this problem, and would greatly appreciate help! Attached you find the preliminary port. TIA! Kind regards, --Toni++ p5-IO-AIO.tgz Description: GNU Unix tar archive
CPAN fetcher broken?
Hi, while still wrestling with the perlbal port, I've found that there is no way to download this package from CPAN with 'make fetch' because this results in attempts to fetch .../by-module/... . After nagging quite a lot of people, Andreas J. Koenig from mind.de finally answered an email of mine to modu...@perl.org and said that the symlink trees have been abandoned long ago, that they are about to be deprecated, and that I should use CPAN or CPANPLUS or similar modules to fetch from CPAN, using their index files. At the same time, I noticed the following (small?) issues with the current scheme: * Fetches are done via FTP, thus most likely bypassing CPAN's load-balancing and redirection scheme. * The hard-coded list of CPAN sites in templates/nework.conf.template is imho geared towards users in the Americas, and Asia. At least, I was chased around the world, and most servers "in my neighbourhood" were bypassed. Maybe this can somehow be improved to automatically select local servers, too. In any case, it might be a good idea to not rely on the symlink trees to fetch the code from CPAN for the upcoming OpenBSD release, as their availability appears to be rather doubtful. Kind regards, --Toni++
Re: HELP WANTED: sysutils/p5-IO-AIO
Hi, On Fri, 23.01.2009 at 09:15:46 +0100, Giovanni Bechis wrote: > Toni Mueller wrote: >> I'm not enough of a C guru, or at least not enough at leisure atm, to >> dig into this problem, and would greatly appreciate help! >> > I think that our perl() is not thread-safe, > (see /usr/src/gnu/usr.bin/perl/Makefile.bsd-wrapper) and this could > cause a problem with a perl module linked against pthread. thanks for the heads-up. I'll then probably proceeed to ignore these tests that require threading. Do you perchance have an estimate if/when/how/why-not OpenBSD will support a threaded Perl? -- Kind regards, --Toni++
perlbal, p5-Net-Netmask
Hi, I've now created a preliminary port for perlbal, and one for p5-Net-Netmask, which is so far required to provide some features for perlbal, like access control based on IP addresses. After doing this, it looks like only one set of tests (the admin interface) fails, because I can't reasonably make use of IO::AIO, due to threading. Please review the attached ports and provide some feedback. TIA! Kind regards, --Toni++ perlbal.tgz Description: GNU Unix tar archive p5-Net-Netmask.tgz Description: GNU Unix tar archive
Re: CPAN fetcher broken?
Hi, On Sat, 24.01.2009 at 19:53:07 +0100, Simon Bertrang wrote: > Just set CPAN_AUTHOR to the authors id. Look at cpan.port.mk or grep > through other Perl ports also using this variable. ok, thank you. This is mentioned nowhere, however, and it's a lot less automatic than a CPAN-based download could be. > P.S.: the license of p5-Net-Netmask doesn't seems to be Artistic. Yes. The joys of cut&paste... In any case, I'm a bit undecided about what that license actually is. The terms are somehwere between BSD and beerware, from my perspective, but he ask something much larger than a beer. Any thoughts? Kind regards, --Toni++
NEW: perlbal
Hi, On Fri, 23.01.2009 at 11:19:28 +0100, Toni Mueller wrote: > I've now created a preliminary port for perlbal, and one for I've attached a revised version of the port of perlbal, a fast reverse proxy and web server, written in Perl. You need the non-official p5-Net-Netmask port which I posted a few days ago to run it. Please send me feedback. -- Kind regards, --Toni++ perlbal.tgz Description: GNU Unix tar archive
Re: CPAN fetcher broken?
Hi, On Mon, 26.01.2009 at 12:37:14 +, Stuart Henderson wrote: > On 2009/01/26 12:10, Toni Mueller wrote: > > On Sat, 24.01.2009 at 19:53:07 +0100, Simon Bertrang > > wrote: > > > Just set CPAN_AUTHOR to the authors id. Look at cpan.port.mk or grep > > > through other Perl ports also using this variable. > > > > ok, thank you. This is mentioned nowhere, however, > > port-modules(5) this is only documented in -current, although it works in -release, too. > > Any thoughts? > "custom, see " Thanks! I'll probably first talk to the guy about it, as others suggested, though. -- Kind regards, --Toni++
Re: CPAN fetcher broken?
Hi, On Mon, 26.01.2009 at 22:58:41 +0100, Marc Espie wrote: > On Mon, Jan 26, 2009 at 12:10:49PM +0100, Toni Mueller wrote: > > ok, thank you. This is mentioned nowhere, however, and it's a lot less > > automatic than a CPAN-based download could be. > > But it does have other advantages that a CPAN-based download doesn't have, > like being a standard url scheme... I'm sorry, but I don't understand. I was thinking along the lines of having to say only (something like) PERL_MODULE=DBI and the ports infrastructure would automatically figure out that this should be downloaded via http://search.cpan.org/CPAN/authors/id/T/TI/TIMB/DBI-1.607.tar.gz which, in turn, would use their load balancing features to get the file from the nearest responding server. Or so I thought. I briefly looked into writing such a downloader module. If you say you don't like the whole idea and wouldn't accept it, I think I won't bother to look any further, though. -- Kind regards, --Toni++
Re: CPAN fetcher broken?
Hi, On Mon, 26.01.2009 at 15:10:56 +0100, Toni Mueller wrote: > Thanks! I'll probably first talk to the guy about it, as others > suggested, though. I've got this response: "There is nothing to uphold. It is a request with no force. It's also no longer relevant." So I'll probably change the license clause to "BSD". Ok? -- Kind regards, --Toni++
Re: NEW: perlbal
Hi Simon, On Sun, 01.02.2009 at 18:08:37 +0100, Simon Bertrang wrote: > Attached is an updated version. Specifically i changed: thanks, I hope to look into it RSN. > The only thing that i still see and i'm not very tempted to fix is a > failing test. Upstream also doesn't seem very active... but anyway, > at least i'd like to know if the test itself is broken or something else. I ran the test suite before posting the port, and I had exactly one test failing which pertains to IO::AIO, which does not work on OpenBSD due to threading issues. It also requires a threaded Perl to begin with, but OpenBSD's Perl is unthreaded. I asked about this a few days/weeks before. If you see additional breakage, please tell me. Kind regards, --Toni++
Re: NEW: perlbal
Hi Simon, On Sun, 01.02.2009 at 18:08:37 +0100, Simon Bertrang wrote: > Attached is an updated version. Specifically i changed: so much that I have to question my qualification for maintaining the port. What do you think? Kind regards, --Toni++
openldap-server-2.3.43: hang
Hi, I have openldap-server-2.3.43, as shipped with OpenBSD 4.4/i386, under 'runit' in a slave configuration for replication via syncrepl from a master server, which is openldap-server-2.3.33p1-bdb. The servers are mostly idle, processing between 0 and perhaps 2 requests per second, but mostly 0 requests per second. I have configured TLS, although it gives me some problem that I still need to figure out (complaining about a self-signed certificate, when there's only the CA certificate actually self-signed), but the most annoying thing is that it does not stop. To wit: # sv stop openldap # tail /var/log/openldap/current ... @4000498c1a0437c1d39c daemon: shutdown requested and initiated. @4000498c1a0437ccd01c slapd shutdown: waiting for 2 threads to terminate # It stays this way for more than 10 minutes (forever?). I can only use force to kill the server, but then I get a message about possibly inconsistent data at the next restart (and no good idea about how to repair it, with ldbm). In that case, I have no better idea than to delete the database, and to start over. Any ideas about how to fix this problem are most welcome! Kind regards, --Toni++
Re: md5?
Hi, On Thu, 12.02.2009 at 21:25:34 +, Christian Weisgerber wrote: > Should be trivial, but that's not my decision. And really, what's > the point? Unless the MD5 file has a different distribution path, > it offers no security benefit. It's handy to check for inadvertent > transfer corruption, that's all. yes, but this one could be easily fixed, imho (sort of, that is). It would require someone signing a file with such hashes with - preferably - a well connected OpenPGP key. Any one of the OpenBSD developers should be able to create and/or use such a key of suitable size (4096 bits, imho) with ease. Only that some keys need to be published and widely advertized as being used for that purpose. Please see eg. "debian-keyring" or "debian-archive-keyring" for inspiration. Kind regards, --Toni++
Re: openldap-server-2.3.43: hang
Hi, On Fri, 06.02.2009 at 12:21:06 +0100, Toni Mueller wrote: > I have openldap-server-2.3.43, as shipped with OpenBSD 4.4/i386, under I have this package also running on 4.4/amd64, and it hung on an attempt to add an entry. I needed to use kill -9 in order to restart it. I've then run it under ktrace, and found a large number of "bad file descriptor (errno 9)" and "resource unavailable (errno 35)" entries, but couldn't so far find the root of these problems. Adding a new class to /etc/login.conf with much increased limits (esp. file descriptors) along the lines suggested for mysql-server seems to help, currently. I could send a modified ktrace.out file (ie, sans passwords etc) to interested parties. -- Kind regards, --Toni++
Re: openldap-server-2.3.43: hang
Hi, On Sun, 15.02.2009 at 15:28:00 +0100, Toni Mueller wrote: > On Fri, 06.02.2009 at 12:21:06 +0100, Toni Mueller > wrote: > > I have openldap-server-2.3.43, as shipped with OpenBSD 4.4/i386, under > I have this package also running on 4.4/amd64, and it hung on an > attempt to add an entry. I needed to use kill -9 in order to restart > it. I adjusted the configuration of openldap on an i386 machine to the one on an amd64 machine that I used to compare with, and found the following, using ktrace/kdump (exerpt): daemon: select: listen=8 active_threads=0 tvp=zero PSIG SIGTERM caught handler=0x2eb7fc4 mask=0x0 RET poll -1 errno 4 Interrupted system call CALL read(0x3,0x8a03d4d0,0x80) RET read -1 errno 35 Resource temporarily unavailable --> The last thing I saw about 'fd 3' was some library opened. daemon: shutdown requested and initiated. daemon: closing 8 CALL fstat(0x8,0x8a03d5e0) RET fstat -1 errno 22 Invalid argument --> I was unable to find anything like an open(2) call resulting in fd 8 slapd shutdown: waiting for 1 threads to terminate --> The latest other message mentioning threads was the one at the beginning, stating something about 'active_threads=0'. When I remove the syncrepl slave clause, the problem goes away. Nuking the db and starting over didn't help in any way. I'm stumped... -- Kind regards, --Toni++
Re: NEW: perlbal
Hi, On Sun, 01.02.2009 at 18:08:37 +0100, Simon Bertrang wrote: > - add missing RUN_DEPENDS to p5-BSD-Resource and p5-libwww > The only thing that i still see and i'm not very tempted to fix is a > failing test. Upstream also doesn't seem very active... but anyway, > at least i'd like to know if the test itself is broken or something else. the port, as is, has one entry too much in its PLIST (so it doesn't build). I've been running the software for testing purposes, and saw no immediate problem. OTOH, I'm not so sure that I still need it, after the progress that varnish has made. The ability to add and remove backend servers while operating, and w/o any need to HUP or otherwise signal the proxy, is nice. :) Other than that, there remains the problem that Perlbal emits a warning "I'll be slow" because it can't find IO:AIO. But that one looks like being impossible to run on OpenBSD unless OpenBSD is going to ship a threaded Perl. Other than that, I'll be happy to support this port if people like Simon keep pushing me into the right direction. If someone wants it in OpenBSD 4.5, please say so. TIA! -- Kind regards, --Toni++
Re: NEW: perlbal
Hi, On Thu, 19.02.2009 at 18:18:43 +0100, Toni Mueller wrote: > [ a lot of mostly useless stuff because I overlooked naddy's >"tree locked" message ] I'd roll the port nonetheless, if desired. -- Kind regards, --Toni++
ldconfig -m something? ("user experience")
Hi, I've discovered that, if I start out installing systems "small" (eg. w/o packages, and w/o xbase), ld doesn't know where to find a lot of the required libraries. When I install a package, I usually want to run the associated software without further tweaking, but before I can do so, I have to first go around and manually run something like # ldconfig -m /usr/X11R6/lib and/or # ldconfig -m /usr/local/lib to get things going. I thought that this could be automated somehow. Eg, while parsing the PLIST files, if there are directories not already known to ld, merge appropriate directories on the fly. Just a thought... -- Kind regards, --Toni++
Re: [new] www/varnish
Hi,
On Tue, 10.02.2009 at 20:55:08 -0500, b...@openbsd.rutgers.edu
wrote:
> > Yeah. We can try sending a diff upstream to get them to use safe string
> > functions, but otherwise... they will probably stay as is.
doing that seems to be a good idea.
> > I think it should also do @newuser/@newgroup instead of using 'nobody'.
Yes. I suggest using either one of _www, _proxy, or _varnish as a
username.
> > Jim also noted that kqueue doesn't work, and he's right. I'm looking
> > into that, as well...
That sounds nice, too!
> Don't let the above be misconstrued... it works as is, it's just not as
> efficient as it could be.
I can't confirm this. Running varnish 2.0.3 on a 4.4/amd64 system like this:
# /usr/local/sbin/varnishd -d -f /etc/varnish/test.vcl -g www -n proxy_1 -P
/var/run/varnish/proxy_1.pid -u www -s file,/var/varnish/proxy_1_data,100m
with this config file /etc/varnish/test.vcl:
--
backend c1 {
.host = "127.0.0.1";
.port = "8080";
}
sub vcl_recv {
set req.backend = c1;
}
--
yields an endless stream of error messages after giving the 'start'
command on the management console:
child (3620) Started
Child (3620) said Closed fds: 6 7 12 13 15 16
Child (3620) said Child starts
Child (3620) said managed to mmap 104857600 bytes of 104857600
Child (3620) said Ready
Child (3620) died signal=6
Child (3620) Panic message: Assert error in vca_acct(),
cache_acceptor.c line 191: Condition((setsockopt(ls->sock, 0x, 0x1005,
&tv_sndtimeo, sizeof tv_sndtimeo)) == 0) not true. errno = 33 (Numerical
argument out of domain) thread = (cache-acceptor)
Child cleanup complete
This is on 4.4/amd64 with an MP kernel, on a QC CPU.
I didn't yet have enough time to dig into the C code yet, though it
could well be a user error at this point. I am also very unhappy about
their statement in http://varnish.projects.linpro.no/ticket/272, and
consider ways to solve this issue.
Kind regards,
--Toni++
Re: [new] www/varnish version 2.0.3
Hi Jim, On Mon, 02.03.2009 at 08:24:52 -0500, Jim Razmus wrote: > Again I throw varnish maintainer up in the air. My employer has decided > to go with Apache2 mod_cache. I don't have a personal need for varnish > either. > > Anyone want it? yes, me, but I'd need some help. -- Kind regards, --Toni++
Re: [new] www/varnish
Hi Jim, On Mon, 02.03.2009 at 08:20:34 -0500, Jim Razmus wrote: > * Toni Mueller [090302 06:51]: > > # /usr/local/sbin/varnishd -d -f /etc/varnish/test.vcl -g www -n proxy_1 -P > > /var/run/varnish/proxy_1.pid -u www -s file,/var/varnish/proxy_1_data,100m > > add this: -p send_timeout=327 thanks a bunch! This at least stops the crashes. I can test the functionality only later today. I hope to find some time to glance at the C code, too. -- Kind regards, --Toni++
PHP5 on 4.4/i386: Crash
Hi, I don't know how relevant this still is, but I just discovered a core file from one of my Apaches which runs with mod_php. Just FYI. I didn't notice immediately because I have the actual server running under 'runit'. $ gdb /usr/sbin/httpd /httpd.core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-openbsd4.4"... (no debugging symbols found) Core was generated by `httpd'. Program terminated with signal 6, Aborted. Reading symbols from /usr/lib/libm.so.3.0...done. Loaded symbols for /usr/lib/libm.so.3.0 Reading symbols from /usr/lib/libssl.so.11.0...done. Loaded symbols for /usr/lib/libssl.so.11.0 Reading symbols from /usr/lib/libcrypto.so.14.0...done. Loaded symbols for /usr/lib/libcrypto.so.14.0 Reading symbols from /usr/lib/libc.so.48.0...done. Loaded symbols for /usr/lib/libc.so.48.0 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so Reading symbols from /usr/lib/apache/modules/mod_info.so...done. Loaded symbols for /usr/lib/apache/modules/mod_info.so Reading symbols from /usr/lib/apache/modules/mod_rewrite.so...done. Loaded symbols for /usr/lib/apache/modules/mod_rewrite.so Reading symbols from /usr/local/lib/php/libphp5.so...done. Loaded symbols for /usr/local/lib/php/libphp5.so Reading symbols from /usr/lib/libstdc++.so.45.0...done. Loaded symbols for /usr/lib/libstdc++.so.45.0 Reading symbols from /usr/local/lib/libintl.so.4.0...done. Loaded symbols for /usr/local/lib/libintl.so.4.0 Reading symbols from /usr/lib/libz.so.4.1...done. Loaded symbols for /usr/lib/libz.so.4.1 Reading symbols from /usr/local/lib/libxml2.so.10.0...done. Loaded symbols for /usr/local/lib/libxml2.so.10.0 Reading symbols from /usr/local/lib/libiconv.so.5.0...done. Loaded symbols for /usr/local/lib/libiconv.so.5.0 #0 0x0d1dfaed in kill () from /usr/lib/libc.so.48.0 (gdb) bt #0 0x0d1dfaed in kill () from /usr/lib/libc.so.48.0 #1 0x0d217da3 in abort () at /usr/src/lib/libc/stdlib/abort.c:68 #2 0x0d1ff541 in wrterror (p=0x2d1ad2f8 "bogus pointer (double free?)") at /usr/src/lib/libc/stdlib/malloc.c:347 #3 0x0d1ff603 in wrtwarning (p=0x2d1ad2f8 "bogus pointer (double free?)") at /usr/src/lib/libc/stdlib/malloc.c:357 #4 0x0d200d19 in free (ptr=0x815a7400) at /usr/src/lib/libc/stdlib/malloc.c:1216 #5 0x01c049e7 in zend_hash_destroy () from /usr/local/lib/php/libphp5.so #6 0x01bf45bf in destroy_zend_class () from /usr/local/lib/php/libphp5.so #7 0x01c04a24 in zend_hash_destroy () from /usr/local/lib/php/libphp5.so #8 0x01bfbe23 in zend_shutdown () from /usr/local/lib/php/libphp5.so #9 0x01bc1d6f in php_module_shutdown () from /usr/local/lib/php/libphp5.so #10 0x01bc1d2a in php_module_shutdown_wrapper () from /usr/local/lib/php/libphp5.so #11 0x01c71cb3 in apache_php_module_shutdown_wrapper () from /usr/local/lib/php/libphp5.so #12 0x1c0340e0 in ap_run_cleanup () #13 0x1c0330fb in ap_clear_pool () #14 0x1c040b00 in ap_child_terminate () #15 0x1c04175c in main () (gdb) -- Kind regards, --Toni++
Re: Fix some more fallout from the python update
Hi, On Sun, 04.01.2009 at 02:14:52 +0100, Matthias Kilian wrote: > Thanks. I already got some explanations from jasper@ about this > strange MODPY_EGG_VERSION thing ;-) any chance to make it public? I'd like to package virtualenv, which I need, but currently get stuck in some .pth problems. I need to build-depend on py-setuptools, too. TIA! -- Kind regards, --Toni++
[new] www/varnish version 2.0.4
Hi, after Jim and others did the bulk of the work, I'll try to take over. In any case, a port of 2.0.4 is attached. This is what the changelog has to say: snip Varnish 2.0.4 has just been released. This release contains multiple changes, amongst them: * Serve graced objects if the backend is unhealthy. * Portability fixes for Solaris, MacOS X/Darwin and NetBSD * Documentation updates * Added server.hostname and server.identity to VCL. * Fixed a problem where we would sleep for far too long when we * would run out of file descriptors. * Add support for processing binary objects with ESI. snip Please test and report any breakage. Thank you! -- Kind regards, --Toni++ varnish-2.0.4.tar.gz Description: Binary data
Re: [new] www/varnish version 2.0.4
Hi, On Tue, 05.05.2009 at 19:57:22 +0100, Federico G. Schwindt wrote: > On Sun, Apr 12, 2009 at 01:08:22AM +0100, Federico G. Schwindt wrote: > > > - Create /var/varnish by default > > > - Use _varnish. Nothing should use nobody, not even by default > > > - Use kqueue > > > - Use -pthread > > > - Do not hardcode -O2 > > > - Install getting-started.html > > > > And hopefully last tarball, including all the above and the manpage > > fixes. > > as i haven't seen anything else on this, i'm planning to commit this > today/tomorrow. > it's a good time to talk now if you have any comments. sorry for having been _VERY_ busy (and being late). I missed your work, but so far ran from a self-baked version on amd64. I noticed the following breakage that I suspect to be related to using kqueue or pthread: Backend health checking is completely broken for me. If I enable it, my backends are all marked "sick", and I get no results. I'll look into your port and probably make more comments after that. Kind regards, --Toni++
Re: [new] www/varnish version 2.0.4
Hi, On Fri, 15.05.2009 at 17:38:10 +0100, Federico G. Schwindt wrote: > no worries. can you try disabling kqueue to see if that's the issue? > i have been busy as well, so i haven't commited it yet. i will do during > the weekend. I'm not sure that I'll manage to do this that fast - the machine in question currently undergoes an upgrade, and, unfortunately, 4.5 shipped with very few pre-built packages. Plus, I have to adapt/re-build software on top of that that is not part of OpenBSD in any sense of the word. Stay tuned, though - I have your code already on the build machine... Kind regards, --Toni++
how to determine obsolete ports?
Hi, I've just discovered that I had some old packages from 4.4 installed on a 4.5 system. While investigating the resulting breakage, it occurred to me that I don't seem to have an easy way to properly determine which ports are being made obsolete by new functionality in the base system. In such cases, I usually wish to remove the package and use the corresponding functionality from the base system. TIA! -- Kind regards, --Toni++
Re: how to determine obsolete ports?
Hi, On Tue, 26.05.2009 at 10:20:20 +0200, Robert wrote: > http://www.openbsd.org/faq/upgrade45.html#Pkgup AAARRGG Thanks! Kind regards, --Toni++
Re: how to determine obsolete ports?
Hi, On Tue, 26.05.2009 at 11:20:35 +0200, Marc Espie wrote: > This is a known defect. It will be dealt with eventually, hopefully soon... thanks to Stuart and you for the background information. I aimed at both targets when I posed the question. -- Kind regards, --Toni++
pure-ftpd-ldap: unusable on amd64
Hi, I'm having a problem with pure-ftpd-ldap on amd64. Short story: When trying to authenticate, the child crashes. Slightly longer story: I've had the same setup running for years on 32bit machines. The setup comprises OpenLDAP + TLS and pure-ftpd-ldap + TLS, authenticating against an OpenLDAP server on the same machine. I've now copied the same setup to four different machines: 4.4/i386 -> works 4.5/i386 -> works (so it's not a 4.4/4.5 issue) 2x 4.5/amd64 (different hardware) -> breaks (so it's not a hardware issue) All machines in question have ECC memory, and the amd64 machines have different quad-core Xeon CPUs, one L5420, and one X3230. One of the i386 machines has older dual-core Xeon CPUs, the other has a P3. The last (only) thing I can see in the logs is this: Jun 14 17:19:11 bgp2a pure-ftpd[7398]: (?...@1.2.3.4) [INFO] New connection from 193.221.127.48 Jun 14 17:19:11 bgp2a pure-ftpd[7398]: (?...@1.2.3.4) [INFO] SSL/TLS: Enabled TLSv1/SSLv3 with AES128-SHA, 128 secret bits cipher The crash happens immediately after the ftp client tries to actually log in to the server. I've tried to disable SSL/TLS on the FTP server, but to no avail, so I'm inclined to suspect some 64bit issue. A little help to debug this would be most welcome! TIA! -- Kind regards, --Toni++
Re: pure-ftpd-ldap: unusable on amd64
Hi Claudio, On Sun, 14.06.2009 at 18:21:21 +0200, Claudio Jeker wrote: > Update the port to -current or define LDAP_DEPRECATED in src/log_ldap_p.h > You can send your regards including all rants to the openldap mailing list > and their braindead model of deprecating the most used functions. > Took me a full afternoon to figure that out. oh, sorry then, and thanks for the heads-up. In the meantime, I've updated the port to pure-ftpd-1.0.22 as per your suggestions, but with not much success. Now I get "Login failed" in the client, and in the OpenLDAP log, I get tons of "requesting something... granted". The last log entries look like this: @40004a3526e330582ebc => access_allowed: read access granted by read(=rscxd) @40004a3526e3305928bc conn=6 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= @40004a3526e330599a04 conn=6 op=2 UNBIND @40004a3526e33059bd2c conn=6 fd=13 closed IOW, with nentries=1, there should be a success, but there isn't. I'll now try the 1.0.21+your patch, too. -- Kind regards, --Toni++
Re: pure-ftpd-ldap: unusable on amd64
Hi, On Sun, 14.06.2009 at 18:43:50 +0200, Toni Mueller wrote: > In the meantime, I've updated the port to pure-ftpd-1.0.22 as per your > suggestions, but with not much success. Now I get "Login failed" in the > client, and in the OpenLDAP log, I get tons of > "requesting something... granted". The last log entries look like this: > > @40004a3526e330582ebc => access_allowed: read access granted by > read(=rscxd) > @40004a3526e3305928bc conn=6 op=1 SEARCH RESULT tag=101 err=0 nentries=1 > text= > @40004a3526e330599a04 conn=6 op=2 UNBIND > @40004a3526e33059bd2c conn=6 fd=13 closed > > IOW, with nentries=1, there should be a success, but there isn't. I'll > now try the 1.0.21+your patch, too. trying the patched 1.0.21 works. Thanks a bunch! -- Kind regards, --Toni++
PHP5: --enable-zend-multibyte?
Hi, I've seen that this option isn't part of the port, but, not being a PHP guru, don't know why. I also don't know how to test for this option in a given PHP binary. :( If anyone has some light to share on this, I'd be glad to hear your story. Thank you! -- Kind regards, --Toni++
Re: PHP5: --enable-zend-multibyte?
Hi, On Tue, 30.06.2009 at 14:17:51 +0200, Toni Mueller wrote: > I've seen that this option isn't part of the port, but, not being a PHP > guru, don't know why. I also don't know how to test for this option in > a given PHP binary. :( I don't know whether this option has adverse effects, but I'm forced to recompile with this option enabled. Please see this bug: > http://bugs.php.net/bug.php?id=22108 Maybe this option should be the default on OpenBSD, too. -- Kind regards, --Toni++
[new] www/p5-FCGI
Hi, I had to create a port for Perl's FCGI module. I need the module to run MovableType together with MT-Dispatch. Please review the attached port to see whether it is ok for you, and send me your feedback. TIA! -- Kind regards, --Toni++ p5-FCGI.tar.gz Description: Binary data
Re: openldap-server-2.3.43: hang
Hi, I'm aware of the tree-lock, but still don't know how this can be handled, and when/how the project can transition to 2.4.x. FWIW, I plead guilty of not testing a preliminary 2.4 port, but will do ASAP if I get my hands on one. The problem described below is still biting me hard. =8-( On Mon, 16.02.2009 at 11:16:13 +0100, Toni Mueller wrote: > On Sun, 15.02.2009 at 15:28:00 +0100, Toni Mueller > wrote: > > On Fri, 06.02.2009 at 12:21:06 +0100, Toni Mueller > > wrote: > > > I have openldap-server-2.3.43, as shipped with OpenBSD 4.4/i386, under > > I have this package also running on 4.4/amd64, and it hung on an > > attempt to add an entry. I needed to use kill -9 in order to restart > > it. > > I adjusted the configuration of openldap on an i386 machine to the one > on an amd64 machine that I used to compare with, and found the > following, using ktrace/kdump (exerpt): > > > daemon: select: listen=8 active_threads=0 tvp=zero > PSIG SIGTERM caught handler=0x2eb7fc4 mask=0x0 > RET poll -1 errno 4 Interrupted system call > > CALL read(0x3,0x8a03d4d0,0x80) > RET read -1 errno 35 Resource temporarily unavailable > > --> The last thing I saw about 'fd 3' was some library opened. > > > daemon: shutdown requested and initiated. > daemon: closing 8 > > CALL fstat(0x8,0x8a03d5e0) > RET fstat -1 errno 22 Invalid argument > > --> I was unable to find anything like an open(2) call resulting in fd 8 > > slapd shutdown: waiting for 1 threads to terminate > > > --> The latest other message mentioning threads was the one at the > beginning, stating something about 'active_threads=0'. > > > When I remove the syncrepl slave clause, the problem goes away. Nuking > the db and starting over didn't help in any way. > > > I'm stumped... > > > -- > Kind regards, > --Toni++ > -- Kind regards, --Toni++
Re: UPDATE: databases/openldap 2.3.39 -> 2.4.9
Hi,
On Wed, 14.05.2008 at 04:05:28 +0200, Henning Brauer
wrote:
> and makes a regular update a no-no in my eyes. I have been using
> ldbm everywhere all the time, because that was the only stable backend
> for years. I suspect I amnot quite alone (read:many many many more
> affected users). just updating this packe removing ldbm fucks them all.
my experience is quite the opposite: bdb (and hdb) were the only
halfway-stable flavours for me, ever. With bdb, I occasionally have to
repair the database ('db_recover'), but with ldbm, I have to completely
reload it after a server hang. I also have non-working syncrepl
synchronization (works with bdb) on top of servers locking up, too
(using the binary packages as provided by OpenBSD, all versions).
--
Kind regards,
--Toni++
Re: UPDATE: databases/openldap 2.3.39 -> 2.4.9
Hi, On Thu, 09.07.2009 at 11:25:07 +0100, Stuart Henderson wrote: > so; some developers need 2.3. other people need 2.4. others don't nice distinction. ;-} I have to correct myself, however, in that syncrepl synchronization does appear to (partially) work. With bdb, I was unable to edit data on the slave, but with ldbm, I can edit that data, and my client shows me exactly the data that I edited. Only that this data that I manually put in, is completely ignored, and the non-visible values from the master are used... > mind which they have. so it seems there needs to be a way for the > versions to coexist in the ports tree. I don't know offhand if this is feasible, or in which ways this will cause problems to other ports and packages, but I'd be happy to decide to only ever have *one* of these packages installed on any given machine. I mean, having two differently versioned LDAP servers to service different applications that link against one or the other only, would be a little counter-intuitive, imho, because it defeats the purpose of having LDAP in the first place. I don't know what ypldap (in the main tree?) does. Maybe this has to influence the decision. > 1. add a -libs package, where 2.3 and 2.4 can coexist, keep the > original binary names in -main and -server and make them conflict. > so packages pulling in libraries from one or other version still work. > (I'm sure some third-party things will start to require 2.4 sometime..) This sounds good to me, but it also sounds like a lot of work. > 2. keep libs in -main (openldap-client) and rename the binaries, > e.g. slapd23, ldapsearch24, and tell people to symlink if they want > the "normal" names (like done with python). This would most likely be sufficient for me, at least as long as I can simply recompile a depending package to link against the other version of LDAP. -- Kind regards, --Toni++
Re: UPDATE: databases/openldap 2.3.39 -> 2.4.9
Hi, On Thu, 09.07.2009 at 22:16:58 +0200, Henning Brauer wrote: > * Stuart Henderson [2009-07-09 21:14]: > > Me too, but if something pulls in 2.3 as a BUILD or LIB depend, and > > something else pulls in 2.4 > > is this really going to happen? I don't know either, but bad memories about the qmail-ldap and pure-ftpd problems, caused by OpenLDAP's API changes, creep back into my mind. It's not entirely out of the question that they did it again, maybe on a bigger scale, when they went from 2.3 to 2.4. Therefore, I don't expect an upgrade to 2.4 being a drop-in replacement, even if the database was already in [bh]db format. -- Kind regards, --Toni++
Re: php 5.2.10 segfault on amd 4.5 -stable
Hi, On Mon, 20.07.2009 at 17:11:31 +0100, Stuart Henderson wrote: > On 2009/07/20 17:38, Jonathan Armani wrote: > > Just a note for php users, php segfault on my server since I update > > it to 2.5.10 : > > > > [Mon Jul 20 17:28:03 2009] [notice] child pid 31165 exit signal > > Segmentation fault (11) > > [Mon Jul 20 17:28:04 2009] [notice] child pid 31388 exit signal > > Segmentation fault (11) > > [Mon Jul 20 17:28:04 2009] [notice] child pid 19135 exit signal > > Segmentation fault (11) > > [Mon Jul 20 17:28:04 2009] [notice] child pid 4215 exit signal Segmentation > > fault (11) > > [Mon Jul 20 17:28:04 2009] [notice] child pid 31812 exit signal > > Segmentation fault (11) > > > > As a workaround I have add *suhosin.session.encrypt= Off* to php.ini > > which seems to stop the error, seems to concern linux too, > > see > > http://www.dotdeb.org/2009/06/25/php-5-2-10-packages-for-lennyetch-are-now-available/#comment-1053. > > > > Anybody see this on -current ? > > > > I don't see this with amd64 -current and FastCGI. I see a similar thing on 4.5-stable, but not exactly a segfault, but PHP closing it's inet socket after a while when running under FastCGI. Requires a restart of the FastCGI server, and does not seem to happen on 4.4 with its earlier PHP version, and Unix domain sockets. I have to check whether it works with Unix domain sockets on 4.5, and if not, then I'm in deep trouble. The error symptom is that the web server in front says "Bad gateway" while the problem exists. It takes only a few hours to reach that stage... -- Kind regards, --Toni++
broken: nut
Hello, since there is no maintainer listed in the nut Makefile, I'd like to ask the list: - I assume that nut currently has no maintainer? - Building the port breaks when using systrace at archive extraction phase: ===> Extracting for nut-2.0.0 systrace: deny user: root, prog: /bin/tar, pid: 6784(0)[3290], policy: /usr/bin/make, filters: 142, syscall: native-fswrite(136), filename: /usr/S/ports/sysutils/nut/w-nut-2.0.0/nut-2.0.0 My /etc/mk.conf looks like this: PORTSDIR=/usr/S/ports DISTDIR=/usr/S/ports/distfiles PKGREPOSITORYBASE=/usr/S/ports/packages/i386 USE_SYSTRACE=Yes Of course, some other ports build with these settings - I didn't try all, however. This is 3.7. Looks like I should try to correct the port myself? Best, --Toni++
ports & systrace
Hi,
On Sat, 18.06.2005 at 17:36:30 +0200, Toni Mueller <[EMAIL PROTECTED]> wrote:
> ===> Extracting for nut-2.0.0
> systrace: deny user: root, prog: /bin/tar, pid: 6784(0)[3290], policy:
> /usr/bin/make, filters: 142, syscall: native-fswrite(136), filename:
> /usr/S/ports/sysutils/nut/w-nut-2.0.0/nut-2.0.0
playing around with other ports, I found out that the systrace file is
often wrongly generated, having a hard wired path of '/usr/ports'
instead of the possible value of ${POPRTSDIR}. Ie, in the
systrace.policy file, the path would read:
/usr/ports/sysutils/nut/w-nut-2.0.0/nut-2.0.0
instead of the real path given above. Somehow, this systrace thing
doesn't seem to work with my symlink in place:
/usr/ports -> /usr/S/ports
Best,
--Toni++
Re: broken: nut
Hi, On Sat, 18.06.2005 at 22:34:11 +0200, Nikolay Sturm <[EMAIL PROTECTED]> wrote: > * Toni Mueller [2005-06-18]: > > - Building the port breaks when using systrace at archive extraction > > phase: > Show me the port's systrace.policy file, please. I cannot reproduce your > problem. no problem: Policy: /bin/sh, Emulation: native native-__sysctl: permit native-accept: true then permit log native-bind: sockaddr match "/tmp" then permit native-bind: sockaddr match "/tmp" then permit native-break: permit native-chdir: permit native-chflags: permit native-chmod: permit native-chown: permit native-chroot: permit native-clock_gettime: permit native-close: permit native-closefrom: permit native-compat_43_ogetdtablesize: permit native-compat_43_ogetpagesize: permit native-compat_43_olseek: permit native-connect: sockaddr eq "family(0)" then permit native-connect: sockaddr match "/dev/log" then permit native-connect: sockaddr match "/tmp" then permit native-connect: sockaddr match "/tmp" then permit native-dup2: permit native-dup: permit native-execve: true then permit native-exit: permit native-fchdir: permit native-fchflags: permit native-fchmod: permit native-fchown: permit native-fcntl: permit native-flock: permit native-fork: permit native-fsread: true then permit native-fstat: permit native-fstatfs: permit native-fswrite: filename eq "" then deny[enoent] native-fswrite: filename eq "/dev/crypto" then permit native-fswrite: filename eq "/dev/null" then permit native-fswrite: filename eq "/dev/stdout" then permit native-fswrite: filename eq "/dev/tty" then permit native-fswrite: filename eq "/dev/zero" then permit native-fswrite: filename match "/tmp" then permit native-fswrite: filename match "/tmp" then permit native-fswrite: filename match "/usr/S/ports/distfiles" then permit native-fswrite: filename match "/usr/ports/sysutils/nut/w-nut-2.0.0" then permit native-fswrite: filename match "/usr/S/ports/bulk" then permit native-fswrite: filename match "/usr/S/ports/packages" then permit native-fswrite: filename match "/var/tmp" then permit native-fswrite: filename match "/: *" then deny[enoent] native-fsync: permit native-ftruncate: permit native-futimes: permit native-getdirentries: permit native-getegid: permit native-geteuid: permit native-getfsstat: permit native-getgid: permit native-getgroups: permit native-getlogin: permit native-getpeername: permit native-getpgid: permit native-getpgrp: permit native-getpid: permit native-getppid: permit native-getpriority: permit native-getrlimit: permit native-getrusage: permit native-getsid: permit native-getsockname: permit native-getsockopt: permit native-gettimeofday: permit native-getuid: permit native-ioctl: permit native-issetugid: permit native-kill: permit native-lchown: permit native-link: filename match "/tmp" and filename[1] match "/tmp" then permit native-link: filename match "/usr/ports/sysutils/nut/w-nut-2.0.0" and filename[1] match "/usr/ports/sysutils/nut/w-nut-2.0.0" then permit native-link: filename[1] match "/: *" then deny[enoent] native-listen: true then permit log native-lseek: permit native-madvise: permit native-mkfifo: permit native-mlock: permit native-mlockall: permit native-mmap: permit native-mprotect: permit native-mquery: permit native-msync: permit native-munmap: permit native-nanosleep: permit native-osigaltstack: permit native-pathconf: permit native-pipe: permit native-poll: permit native-pread: permit native-pwrite: permit native-read: permit native-readv: permit native-recvfrom: permit native-recvmsg: permit native-rename: permit native-select: permit native-sendmsg: permit native-sendto: permit native-setegid: permit native-setgid: permit native-setgroups: permit native-setitimer: permit native-setpgid: permit native-setpriority: permit native-setregid: permit
Re: broken: nut
Hi, On Tue, 21.06.2005 at 14:06:12 -0700, Michael Coulter <[EMAIL PROTECTED]> wrote: > > Btw, while I'm at it, this machine, despite being amd64, creates > > ...ports/packages/i386/... instead of ...porets/packages/amd64/... > > This is because you told it to :) ok, stupid me :-| Best, --Toni++
Re: broken: nut
Hi,
On Tue, 21.06.2005 at 14:06:12 -0700, Michael Coulter <[EMAIL PROTECTED]> wrote:
> Lines like this one are the culprit. It looks like you ran make extract
> from /usr/ports as opposed to /usr/S/ports. In the case where WRKOBJDIR
> is not set, WRKDIR uses ${.CURDIR} as it's base path. I'm not sure if
> there is a way to build this path using PORTSDIR as a base, but with
> the current infrastructure, it looks like you need to either try setting
> WRKOBJDIR (to something like /usr/obj/ports) or run make extract from
> ${PORTSDIR}/sysutils/nut.
I'm not sure about what you mean here, but in all these cases, I 'cd'
to the directory of the port, then run "make package". It fails on the
first run, but then I hand-edit w- and run 'make package'
again. Some ports build without problems. However, I didn't find a
pattern yet.
Best,
--Toni++
Re: broken: nut
Hi Nicolay, On Wed, 22.06.2005 at 08:03:25 +0200, Nikolay Sturm <[EMAIL PROTECTED]> wrote: > * Toni Mueller [2005-06-21]: > > native-fswrite: filename match "/usr/S/ports/distfiles" then permit > > native-fswrite: filename match "/usr/ports/sysutils/nut/w-nut-2.0.0" > > then permit > > This indeed is a very strange entry. Is /usr/ports a hardlink to > /usr/S/ports? of course not - it's a symlink. I'm a bit confused about the question since directories can't be hardlinked to. # ls -l ports lrwxr-xr-x 1 root wheel 7 Jun 18 16:43 ports -> S/ports > Otherwise I don't see how WRKDIR could ever point to /usr/ports in > your case, as path normalisation is, afaik, always taken into > account. I looked at the systrace skeleton in infrastructure, but couldn't find a problem there. Best, --Toni++
systrace on ports, was: Re: broken: nut
Hi,
On Thu, 23.06.2005 at 12:23:42 -0700, Michael Coulter <[EMAIL PROTECTED]> wrote:
> # PORTSDIR=/symlink_to_usr_ports cd /usr/ports/sysutils/nut && make
> show=WRKDIR
> /usr/ports/sysutils/nut/w-nut-2.0.0
>
> i.e. WRKDIR gets set by the directory you're in, not ${PORTSDIR}
yes, but WRKDIR should not be PORTSDIR in any case - it's two levels
down for most ports, and three on some.
Eg, WRKDIR=${PORTSDIR} + "/" + "sysutils/nut"
I've looked into infrastructure, and there are three occurrences of
'pwd', two with '-P' and one plain...
> "directory of the port" could mean either /usr/ports/sysutils/nut or
> /usr/S/ports/sysutils/nut. The former is probably the one breaking,
> the latter should work properly though.
Yes, the symlink is for convenience *ONLY*. I'd like to keep it if
possible, esp since the system can figure out the required settings
anyway (mostly).
Best,
--Toni++
Re: systrace on ports
Hi, On Sat, 25.06.2005 at 21:27:16 -0700, Michael Coulter <[EMAIL PROTECTED]> wrote: > The symlink isn't the problem, it's all about what directory you're > changing to. as far as I understand you, the problem is that sometimes the current directory is found via /bin/pwd or "pwd -P" which gives the physical path, and in one case it's found with pwd only, giving the logical path. Best, --Toni++
Re: Lost connections with mysql-server-4.0.23p1
Hi, On Wed, 14.09.2005 at 13:26:00 -0400, Jason Dixon <[EMAIL PROTECTED]> wrote: > I've got an OpenBSD 3.7 server with mysql-server-4.0.23p1.tgz I'm running the same software, and encounter "bad file descriptor" errors more often than not. Can somebody please take care to set higher limits for MySQL on installing the server part of the port, please? > installed from packages. Once a week or so, the mysql server will > stop taking queries, commands, etc. This happens at least once a day over here. In that case, MySQL needs to be restarted by force to get going again. I've made a band-aid for this, but a solution is very much preferred. > There are no error messages in /var/mysql/`hostname`.err that would > suggest anything is wrong. > Has anyone else run into problems with this version? Any success > stories with the newest 4.1.14 port running on 3.7? I'm trying to move to 3.8 to see if anything gets better, but am generally not overly happy with MySQL on OpenBSD 8-( Kind Regards, --Toni++
Re: Courier-Authlib, Courier-MTA
Hello Steve,
On Sat, 23.07.2005 at 20:24:08 -0400, Steve Shockley <[EMAIL PROTECTED]> wrote:
> I've updated my Courier-MTA and Courier-Authlib ports, linked below.
> Please take a look and consider committing them, or let me know what I
> should change to make them commit-worthy.
unfortunately, your port didn't get commited for 3.8.
> It currently creates user/group _courier, ID 601, but I'd be happy to
> change that to an "official" one.
I hereby request assigning an official user and groupid of "_courier".
> http://shockley.net/OpenBSD/courier-authlib-0.57-port.tgz
> http://shockley.net/OpenBSD/courier-0.50.1-port.tgz
I'm underway mangling that into a similar structure as eg. have the
Python or PHP ports:
mail/courier
/authlib
/imap
/sqwebmail
(would do for me, and have a unified structure for the whole beast, but
you probably also want)
/mta
/pop3
/... ?
My goal would be to update to the latest of these packages instead of
keep lingering at pre-authlib versions...
So far, I replaced your patch-configure with a patch-configure_in,
taking in your patch:
--- configure.in.orig Fri Dec 9 00:15:55 2005
+++ configure.inMon Dec 26 12:44:50 2005
@@ -912,8 +912,8 @@
then
$COURIERCONFIG >conftest.out || exit 1
sed -n '/^mail/p' conftest2.out || exit 1
- . conftest2.out
- rm -f conftest.out conftest2.out
+ . ./conftest2.out
+ rm -f ./conftest.out ./conftest2.out
cmailuser="$mailuser"
cmailgroup="$mailgroup"
@@ -924,8 +924,8 @@
then
$bindir/courierauthconfig --configfiles >conftest.out || exit 1
sed -n '/^mail/p' conftest2.out || exit 1
- . conftest2.out
- rm -f conftest.out conftest2.out
+ . ./conftest2.out
+ rm -f ./conftest.out ./conftest2.out
cmailuser="$mailuser"
cmailgroup="$mailgroup"
@@ -952,7 +952,7 @@
#include
#include
-static const char *ids $LB $RB={"courier","daemon","adm","bin","root", 0};
+static const char *ids $LB $RB={"_courier", 0};
int main()
{
@@ -998,7 +998,7 @@
#include
#include
-static const char *ids $LB $RB={"courier", "daemon","sys","adm", "root", 0};
+static const char *ids $LB $RB={"_courier", "daemon", 0};
int main()
{
@@ -1032,7 +1032,7 @@
AC_MSG_RESULT([$mailgroup $result])
AC_SUBST(mailuser)
AC_SUBST(mailgroup)
-rm -f conftest.out
+rm -f ./conftest.out
AC_ARG_WITH(stdheaderdir,
[ --without-stdheaderdir Header files will be installed into a directory
The uid mentioned above must exist at build time (ie, on both the build
system _and_ the target system), but I'm unsure about how to express
that - unless there'd be a fake package that contains only adding this
uid and gid, but do nothing else, and mention that as BUILD_DEPENDS and
RUN_DEPENDS.
Comments are most welcome.
Best,
--Toni++
Re: Courier-Authlib, Courier-MTA
Hello Steve, On Tue, 27.12.2005 at 00:18:07 -0500, Steve Shockley <[EMAIL PROTECTED]> wrote: > That's a tossup for me, although there's the argument that I'm not quite sure about what you want to say, but the last thing I'd like to do is to even give the impression of taking your effort and attempt to re-label it as mine. Also, I'm not too keen on working on a (competing) port when yours is already there, but only want to see/use an official port in good shape, whoever makes it happen. > They're subpackages, so they really don't need their own directory. Since I probably misunderstood the courier docs and what you've done, I didn't check out your courier package yet which I'm underway doing now, which may very well show that I'm working in the wrong direction (your http://shockley.net/OpenBSD/ page lists only a much older version). > I haven't tried patching configure_in and rebuilding configure, but > building courier-authlib works fine if you give it a numeric uid and the > user doesn't exist yet. Yes, that's what I understood from reading your port, but I wanted to make that UID stuff automatic and official, too. Requirements for creating ports seem to have tightened up quite a bit since the last time I looked, and eg. there's now an official list of UIDs and GIDs for OpenBSD ports which I'd like to comply with. > You don't have to worry about the user existing when you > build/install courier-mta, since courier-authlib is a dependency and > will create the user if needed. I'll look into this as well, but the extra package would hand that task to the ports system instead requiring the maintainer of the courier port(s) to hand-wire such things into the port. It should also be fairly easy to do. Best, --Toni++
Re: Courier-Authlib, Courier-MTA
Hello Steve, On Tue, 27.12.2005 at 00:18:07 -0500, Steve Shockley <[EMAIL PROTECTED]> wrote: > That's a tossup for me, although there's the argument that > courier-authlib should go under security instead of mail, since it's not > really a mail program. this sounds perfectly reasonable as well. I looked into your port of courier-authlib and find that it lists "CATEGORY=mail", though. > They're subpackages, so they really don't need their own directory. In the meantime, I've taken a short look at your real courier package and think that most of our discussion is already over because you seem to have solved most if not all of it already. So, what remains from my point of view is to get the UID problem resolved, and to get the packages into the tree. I'm not too sure why it happened already, and why I didn't see any discussion on why it has *not* been included. Also, the packages imho pose the question why Marc says he is now maintaining these, and what he does (differently)? Marc? Best, --Toni++
Re: Courier-Authlib
Hello,
my package isn't going too well. As per pkg_create(1), I've done
this PLIST:
@newgroup _courier:601
@newuser _courier:601:601:daemon:Courier Auth
Daemon:/var/courier:/bin/sh
@group _courier
@owner _courier
@mode 0755
var/courier/
@unexec /usr/sbin/userdel _courier
@unexec /usr/sbin/groupdel _courier
Formerly, I had "@dir var/courier" instead of just "var/courier/" (as
per
http://marc.theaimsgroup.com/?l=openbsd-ports&m=109040813323276&w=2),
but that directory doesn't get created despite the man page saying so.
I also had
do-install:
mkdir ${WRKDIR}/var/courier
in the Makefile at some point, yielding the very same effect.
What am I doing wrong this time?
Best,
--Toni++
NEW: courier-uidgid (was: Courier-Authlib)
Hello, I've probably unbungled my effort to create that package, and now it works as I think it should. Since it's very small, I attach the port directory. I don't quite know where to place it, however. Best, --Toni++ courier-uidgid.tgz Description: GNU Unix tar archive
Problem w/ Python 2.3.5
Hi, finally, I broke down and installed some X11 stuff on a server in the hope to gain PIL there... but first, I need to rebuild Python (re-run after the same breakage): hostname 11:42:23 /home/obsd/ports/lang/python/2.3 # /usr/bin/make package ===> Building for python-2.3.5p2 case $MAKEFLAGS in *-s*) CC='cc -pthread' LDSHARED='cc -pthread -shared -fPIC -L/home/obsd/ports/lang/python/2.3/w-python-2.3.5p2/Python-2.3.5' OPT='-DNDEBUG -O2 -pipe -DTHREAD_STACK_SIZE=0x18 -fPIC' ./python -E /home/obsd/ports/lang/python/2.3/w-python-2.3.5p2/Python-2.3.5/setup.py -q build;; *) CC='cc -pthread' LDSHARED='cc -pthread -shared -fPIC -L/home/obsd/ports/lang/python/2.3/w-python-2.3.5p2/Python-2.3.5' OPT='-DNDEBUG -O2 -pipe -DTHREAD_STACK_SIZE=0x18 -fPIC' ./python -E /home/obsd/ports/lang/python/2.3/w-python-2.3.5p2/Python-2.3.5/setup.py build;; esac running build running build_ext *** Error code 4 Stop in /home/obsd/ports/lang/python/2.3/w-python-2.3.5p2/Python-2.3.5 (line 340 of Makefile). *** Error code 1 Stop in /home/obsd/ports/lang/python/2.3 (line 1807 of /home/obsd/ports/infrastructure/mk/bsd.port.mk). I've made sure to have only OPENBSD_3_8 tagged stuff on that box. Any ideas? Best, --Toni++
Re: Problem w/ Python 2.3.5
Hi Joachim, On Tue, 17.01.2006 at 17:00:24 +0100, Joachim Schipper <[EMAIL PROTECTED]> wrote: > On Tue, Jan 17, 2006 at 11:56:38AM +0100, Toni Mueller wrote: > > case $MAKEFLAGS in *-s*) CC='cc -pthread' LDSHARED='cc -pthread -shared > > -fPIC -L/home/obsd/ports/lang/python/2.3/w-python-2.3.5p2/Python-2.3.5' > > OPT='-DNDEBUG -O2 -pipe -DTHREAD_STACK_SIZE=0x18 -fPIC' ./python -E > > /home/obsd/ports/lang/python/2.3/w-python-2.3.5p2/Python-2.3.5/setup.py -q > > build;; *) CC='cc -pthread' LDSHARED='cc -pthread -shared -fPIC > > -L/home/obsd/ports/lang/python/2.3/w-python-2.3.5p2/Python-2.3.5' > > OPT='-DNDEBUG -O2 -pipe -DTHREAD_STACK_SIZE=0x18 -fPIC' ./python -E > > /home/obsd/ports/lang/python/2.3/w-python-2.3.5p2/Python-2.3.5/setup.py > > build;; esac > > running build > > running build_ext > > *** Error code 4 > Not reproducible on my system (3.8-stable/i386) - python-2.3.5p2 builds > fine. (Do note that this is under /usr/ports, and as root.) thanks for your message. In the meantime, I think I found out that this means "interrupted system call", and no, I don't have any better error messages. > Try to find a more detailed error log. Are you certain your hardware > works as expected? Well... that's what I'm not sure about right now, too. The box is otherwise mostly idle, and has been reliable except for this problem now. Any ideas on how to check it? Best, --Toni++
Re: Problem w/ Python 2.3.5
Hello Steve, On Wed, 18.01.2006 at 06:38:25 +0100, steven mestdagh <[EMAIL PROTECTED]> wrote: > with PIL you are referring to the python imaging library, right? > this is available as a package (py-Imaging). > is there a reason why you cannot use packages? yes, the reason is that I need Plone 2.1.1 which in turn requires PIL 1.1.5, not 1.1.4 which is in ports. In most cases, when the updated package is mostly reflected in new version numbers in the Makefile, and a new distinfo, this is not a problem. > "broke down and installed some X11 stuff" sounds pretty vague. By this I meant that I installed the xbase38.tgz, xetc38.tgz and xshare38.tgz which I normally don't install. Unfortunately, the PIL port can't easily be built w/o tk which in turn requires X11. Best, --Toni++
NEW: courier-uidgid
Hello, this is sort of a repost, since nobody cared to comment the last time, and since I find this matter increasingly urgent (seeing 3.9 approaching fast), and feel a bit stuck. Attached you find a small "port" which creates a package that adds a directory, a uid and a gid which can then be used by the courier suite. Please assign an official uid so I can change the package to use that. There's a set of (imho) two good packages by Steve Shockley which represent the bulk of the work and create packages for the whole of the courier suite instead of only scattered parts of it, and are compatible with courier releases using courier-authlib which exists since at least 10/2004. Will we see any progress before freeze, please? Best, --Toni++ courier-uidgid.tgz Description: GNU Unix tar archive
Re: NEW: courier-uidgid
Hello Marc, On Sun, 29.01.2006 at 10:17:48 +0100, Marc Balmer <[EMAIL PROTECTED]> wrote: > * Toni Mueller wrote: > > Will we see any progress before freeze, please? > > We have reworked all of the courier stuff, I will mail out a diff on > monday. you mean yesterday? Best, --Toni++
Re: PHP4 packages
Hello, On Wed, 01.02.2006 at 16:52:24 +0100, Marc Balmer <[EMAIL PROTECTED]> wrote: > * Andreas Vögele wrote: > > third-party PHP ports, like for example Horde, depend on the php5 > > port. You can't built packages that depend on php4. > An you can't use modern software like recent horde based stuff with > PHP4. why not depend on PHP5 for packages that need it, on PHP4 OR PHP5 for packages that are ok with any of them, and have both PHP4 and PHP5 around? > > If I were the OP I would install the relevant third-party PHP packages > > manually without using the ports system. Alternatively, he could copy > > those ports to /usr/ports/mystuff and alter the dependencies. > > Why not consider using PHP5? While neither PHP4 nor PHP5 give me great feelings of trust, PHP5 is still too new for my taste, and also generally claimed to require _much_ more machine resources. I'm not really thrilled at throwing more hardware at PHP if there is no *compelling* reason. Also, we need Typo3 (blech) which in turn requires PHP4, not PHP5. Compatibility with PHP5 is planned for 4.0, so turned around, 3.8.x isn't compatible with PHP5, and 4.0 beta isn't, either. Best, --Toni++
Re: NEW: courier-uidgid
Hello Marc, On Tue, 31.01.2006 at 16:34:46 +0100, Marc Balmer <[EMAIL PROTECTED]> wrote: > * Toni Mueller wrote: > > On Sun, 29.01.2006 at 10:17:48 +0100, Marc Balmer <[EMAIL PROTECTED]> wrote: > > > We have reworked all of the courier stuff, I will mail out a diff on > > > monday. > > you mean yesterday? > Sure, but a lot of work here, ok, I look at this tomorrow... ;) did you see anything? We're all thrilled to learn the new secret ways for packaging courier, too! Best, --Toni++
Re: PHP4 packages
Hello Marc, On Sat, 04.02.2006 at 16:42:57 +0100, Marc Balmer <[EMAIL PROTECTED]> wrote: > * Toni Mueller wrote: > > Also, we need Typo3 (blech) which in turn requires PHP4, not PHP5. > > Compatibility with PHP5 is planned for 4.0, so turned around, 3.8.x > > isn't compatible with PHP5, and 4.0 beta isn't, either. > > iirc there is no typo3 port, indeed, there isn't. It was also a bit of work getting it to run properly w/o resortung to -u. > so what are you trying to tell us? I'm trying to say that PHP4 still is required, which you seemed to dispute, and that ports should not be viewed as a closed shop but eg. are useful to lay ground for other apps which maybe didn't make it into ports yet, and that your argument that there is lang+1 for popular languages - that's what I understand from you wrt. PHP4 vs. PHP5, for instance, is invalid as long as important applications are not certified for that language version. > On the other hand we have software _in the tree_ that requires the > PHP5 stuff. it has been decided long time ago to go with PHP5 > wherever possible. Don't get me wrong - I'm in no way advocating throwing out PHP5, but I wish that different language versions could be installed in parallel, and then eg. be differentiated by search paths, instead of having to choose either one and discarding all others. This is impractical from my perspective. > php4 remains in the ports collection, though. Ok... While we are at it, what about PHP 4.4.2 which again claims to fix some security problems over 4.4.1? Best, --Toni++
Re: @newuser question
Hello, On Wed, 08.02.2006 at 16:51:12 +1100, Ian McWilliam <[EMAIL PROTECTED]> wrote: > On 8 Feb 2006, at 12:00 PM, Arnaud Bergeron wrote: > >On 2/7/06, Nikolay Sturm <[EMAIL PROTECTED]> wrote: > >>* Keith Richardson [2006-02-07]: > >>>for the same UID. Are there any reasons *not* to provide the > >>>next-availble UID if the '!' prefix wasn't specified? > >> > >>In a network, having different UIDs for the same accounts is just > >>calling for trouble. You really want a deterministic solution there. > > > >Also some apps have their uids compiled-in. What would happen if > >another port "stole" the uid because the one just before was taken (or > >whatever the reason). > > This is poor software design. They should be looking up the uid or > gid and not relying on a hard coded number. that may well be, but must be catered for in the real world (imho). I came across that same problem with the courier mail suite, and decided to make a package as a build-depends for just this purpose, which does nothing except creating that user id and her home. This is sort of ugly, but the cleanest way I can think of atm. I'm very interested in other ideas on this matter! Best, --Toni++
Re: Python versions and dependencies
Hello, On Wed, 08.02.2006 at 19:55:19 +0100, Nikolay Sturm <[EMAIL PROTECTED]> wrote: > Intentional, by default our ports depend on python 2.3, they use python > 2.4 if there is a reason for it. ok, then I'd like to log an error with Zope < 3.0 because this depends on 2.4 as per port, but is only verified for 2.3 as per the Zope release managers, and there is even a claim that breakage is likely when you run Zope 2.x on Python 2.4. See mails by Andreas Jung who produces the Zope 2.x releases. Best, --Toni++
bsd.port.subdir.mk and makesum?
Hello, trying to tackle the PHP 4.4.2 stuff myself, I ran into the following problem: make fetch: ok... file was correctly downloaded But make makesum: # /usr/bin/make makesum make: don't know how to make makesum. Stop in /home/obsd/ports/www/php4. (PORTSDIR set correctly) Looking into ports/infrastructure/mk/bsd.port.subdir.mk, I can't find any good reference to 'makesum', and only a reference to 'checksum'. Trying to copy the makesum part from bsd.port.mk yields: # /usr/bin/make makesum make: don't know how to make fetch-all. Stop in /home/obsd/ports/www/php4. But looking into that Makefile again yields that the 'addsum' target also depends on 'fetch-all'. Trying this from the 'core' subdirectory produces a correct distinfo one level above. Is this intentional behaviour? Best, --Toni++
Re: bsd.port.subdir.mk and makesum?
Hi, On Thu, 09.02.2006 at 16:22:06 +0100, steven mestdagh <[EMAIL PROTECTED]> wrote: > On Thu, Feb 09, 2006 at 03:36:49PM +0100, Toni Mueller wrote: > > Trying this from the 'core' subdirectory produces a correct distinfo > > one level above. Is this intentional behaviour? > > I think so, since Makefile.inc sets CHECKSUM_FILE. ok, thanks for the heads-up. I am more interested if it's intentional behaviour that I _can't_ make makesum from the top directory when Makefile includes instead of . Best, --Toni++
Re: NEW: courier-uidgid
Hello Marc, On Thu, 09.02.2006 at 20:09:40 +0100, Marc Balmer <[EMAIL PROTECTED]> wrote: > * Toni Mueller wrote: > > We're all thrilled to learn the new secret ways for packaging courier, > > too! > It has been decided not to import new stuff or do major upgrades now, as > we are approaching tree lock for the 3.9 release. I have learnt so in the meantime, but several people inquired before the tree was locked. > I am withholding this stuff until after the tree lock. Obviously. > If you're curious, you can probably get it from www.etc.msys.ch. Yes, I am curious. Best, --Toni++
Re: Python versions and dependencies
Hello Marc, On Thu, 09.02.2006 at 20:24:26 +0100, Marc Balmer <[EMAIL PROTECTED]> wrote: > me: > > ok, then I'd like to log an error with Zope < 3.0 because this depends > > on 2.4 as per port, but is only verified for 2.3 as per the Zope > > release managers, and there is even a claim that breakage is likely > > when you run Zope 2.x on Python 2.4. See mails by Andreas Jung who > > produces the Zope 2.x releases. > > That is _bullshit_. Sorry would you care to elaborate? I have a quote from him, and I have also learned that it's usually _not_ wise to try to override such dependencies, esp. not with Zope. We discussed that before and also didn't reach any consensus. Ok, maybe I should have writen < 2.9 instead of < 3.0, but that's about it, isn't it? Like eg. this (seeing that 2.8.4 is still head in CVS): http://www.zope.org/Products/Zope/2.8.5/Zope-2_8_5-released Quote: " At this time the only supported and recommended Python versions are 2.3.4 and 2.3.5. Using Python 2.4.X is not supported and not recommended at this time. Python 2.4.X will be supported when a security audit took place. This means that you are using Python 2.4 + Zope 2.8 at your own risk." You also get slapped heavily when asking for help and saying that you run Zope 2.8 on Python 2.4 on the dzug.org mailing list (I didn't...). Best, --Toni++
MySQL 5.0.18 on 3.8 breaks with libmysqlclient SO number
Hi, I'd like to build MySQL 5.0.18 on a 3.8 machine. It doesn't work since there are discrepancies between the assumed and real numbers of shared libs (I have BSDPORTSDIR set appropriately): ===> Building package for mysql-client-5.0.18p0 Switching to /home/obsd/ports/databases/mysql/pkg/PFRAG.shared Error in package: "/home/obsd/ports/databases/mysql/w-mysql-5.0.18/fake-i386//usr/local/lib/mysql/libmysqlclient.so.16.0" does not exist Error in package: "/home/obsd/ports/databases/mysql/w-mysql-5.0.18/fake-i386//usr/local/lib/mysql/libmysqlclient_r.so.16.0" does not exist ===> Cleaning for mysql-client-5.0.18p0 rm -f /home/obsd/ports/packages/i386/all/mysql-client-5.0.18p0.tgz *** Error code 1 Stop in /home/obsd/ports/databases/mysql (line 2075 of /home/obsd/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /home/obsd/ports/databases/mysql (line 1308 of /home/obsd/ports/infrastructure/mk/bsd.port.mk). # /usr/bin/find w-mysql-5.0.18 -name 'libmysqlclient.so.16*' w-mysql-5.0.18/fake-i386/usr/local/lib/libmysqlclient.so.16.0 # /bin/ls -al w-mysql-5.0.18/fake-i386/usr/local/lib/ total 8 drwxr-xr-x 4 root wheel 512 Feb 28 23:10 . drwxr-xr-x 11 root wheel 512 Feb 28 23:10 .. drwxr-xr-x 3 root wheel 512 Feb 28 23:10 X11 lrwxr-xr-x 1 root wheel 28 Feb 28 23:10 libmysqlclient.so.16.0 -> mysql/libmysqlclient.so.16.0 lrwxr-xr-x 1 root wheel 30 Feb 28 23:10 libmysqlclient_r.so.16.0 -> mysql/libmysqlclient_r.so.16.0 drwxr-xr-x 2 root wheel 512 Feb 28 23:10 mysql # /bin/ls -al w-mysql-5.0.18/fake-i386/usr/local/lib/mysql/ total 5544 drwxr-xr-x 2 root wheel 512 Feb 28 23:10 . drwxr-xr-x 4 root wheel 512 Feb 28 23:10 .. -r--r--r-- 1 root bin 10482 Feb 28 23:10 libdbug.a -r--r--r-- 1 root bin 38920 Feb 28 23:10 libheap.a -r--r--r-- 1 root bin319328 Feb 28 23:10 libmyisam.a -r--r--r-- 1 root bin 22754 Feb 28 23:10 libmyisammrg.a -rw-r--r-- 1 root bin472346 Feb 28 23:10 libmysqlclient.a -rwxr-xr-x 1 root bin 869 Feb 28 23:10 libmysqlclient.la -rwxr-xr-x 1 root bin440948 Feb 28 23:10 libmysqlclient.so.15.0 -rw-r--r-- 1 root bin478354 Feb 28 23:10 libmysqlclient_r.a -rwxr-xr-x 1 root bin 891 Feb 28 23:10 libmysqlclient_r.la -rwxr-xr-x 1 root bin446556 Feb 28 23:10 libmysqlclient_r.so.15.0 -r--r--r-- 1 root bin246470 Feb 28 23:10 libmystrings.a -r--r--r-- 1 root bin255884 Feb 28 23:10 libmysys.a -r--r--r-- 1 root bin 14750 Feb 28 23:10 libvio.a I don't understand what the change of Makefile (rev. 1.114 -> 1.115) was good for - the log message is too cryptic for me, but this seems to break the build. At least (as can be seen) the change doesn't seem to be propagated through the tree. Why is it a good idea to have .so numbers different from upstream? Where should I look? TIA! Best, --Toni++
Re: MySQL 5.0.18 on 3.8 breaks with libmysqlclient SO number
Hello, On Tue, 28.02.2006 at 23:05:26 +, Stuart Henderson <[EMAIL PROTECTED]> wrote: > On 2006/02/28 23:31, Toni Mueller wrote: > > I don't understand what the change of Makefile (rev. 1.114 -> 1.115) > Neither of those are for 3.8. yes, I know, and yes, sometimes you have to have newer versions of something in your non-current system, for reasons outside of OpenBSD (of course). I'd rather attempt a backport than throwing away all that porting knowledge and compile straight from source. That's what I did, and that's what broke. Best, --Toni++
Re: MySQL 5.0.18 on 3.8 breaks with libmysqlclient SO number
Hi, On Wed, 01.03.2006 at 00:15:07 +0100, Bernd Ahlers <[EMAIL PROTECTED]> wrote: > Toni Mueller [Tue, Feb 28, 2006 at 11:31:53PM +0100] wrote: > >I'd like to build MySQL 5.0.18 on a 3.8 machine. It doesn't work since > >there are discrepancies between the assumed and real numbers of shared > >libs (I have BSDPORTSDIR set appropriately): > > > There's no mysql-5.0.x port in 3.8. Mixing -current and > -stable/-release isn't supported. You'll end up with broken stuff. yes, that's a mantra well known to me, but sometimes the choices are, umm, limited (see other post). > >I don't understand what the change of Makefile (rev. 1.114 -> 1.115) > >was good for - the log message is too cryptic for me, but this seems > >to break the build. > > > No, it doesn't break the build in -current. Ok, so this broke the build only on 3.8. > We had to bump all versions of c++ shared libs in the ports tree, > because of a change in the base system. > > A new framework to control shared libs got introduced in the -current > ports tree. Therefore your -current mysql doesn't work on > -stable/-release. Thanks for the explanation! That helps me understand. FWIW, changing the '16' in the Makefile back to '15' made the port compile, but I'll have to see if it also works. Best, --Toni++
Interchange or Request Tracker underway?
Hi, before re-inventing the wheel, I'd like to know if anyone is already working on porting Interchange (http://www.icdevgroup.org/) or Request Tracker (http://www.bestpractical.com/rt/) to OpenBSD? I know it's too late for 3.9 already, but since I need to make at least one of them run on OpenBSD (again), I consider working on a port. So, nothing tangible right now... Best, --Toni++
Re: Radius question
Hello, On Mon, 06.03.2006 at 12:17:03 -0500, Jason Dixon <[EMAIL PROTECTED]> wrote: > question, but it seems close enough. I need to setup a new RADIUS > server on OpenBSD, but I'm looking for one that will allow me to run > an external command for authentication. Is this possible? Do either > of the RADIUS ports on OpenBSD (cistron, lucent) support this? both of these should be woefully out of date, with the Cistron having stopped a few years ago, and the lucent one probably earlier still. If you need RADIUS on OpenBSD, please take a good look at FreeRADIUS and/or OpenRADIUS which are, to the best of my knowledge, the most reasonable free packages out there. Personally, I suspect that FreeRADIUS is the best server currently available. Best, --Toni++
Re: Interchange or Request Tracker underway?
Hello, On Sat, 18.03.2006 at 14:43:22 +0100, Toni Mueller <[EMAIL PROTECTED]> wrote: > before re-inventing the wheel, I'd like to know if anyone is already please scratch RT - I've just found the other stuff from Deanna & Co. The IC question remains. Maybe I should just focus on that. Best, --Toni++
Re: Interchange or Request Tracker underway?
Hello Marc, On Sat, 18.03.2006 at 18:04:14 +0100, Marc Balmer <[EMAIL PROTECTED]> wrote: > We have a working port of OTRS, www.otrs.org, if that helps. thanks for the offer, but I don't see why I should (would) switch. Best, --Toni++
wget <= 1.10.2 in 3.[89] -> sign error?
Hello, I just tried to download a file of some 3 gigs from a foreign server using wget. On both a 3.9+ (snapshot shortly after tagging) and 3.8 machine, wget crashes. On the 3.9+ machine, it worked like this: Loaded symbols for /usr/libexec/ld.so #0 0x063c39b9 in kill () from /usr/lib/libc.so.39.0 (gdb) bt #0 0x063c39b9 in kill () from /usr/lib/libc.so.39.0 #1 0x06400093 in abort () at /usr/src/lib/libc/stdlib/abort.c:65 #2 0x1c014bb5 in http_loop () #3 0x1c01cd8c in retrieve_url () #4 0x1c018dd5 in main () and looking into the protocol for the 3.8 machine yields this: Length: -1,585,934,797 [application/x-tar] Refering to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354989 I went to look into config.log to find ac_cv_sys_large_files=no ac_cv_sys_largefile_CC=no ac_cv_sys_largefile_source=no despite this being version 1.10... what gives? Best, --Toni++
Re: wget <= 1.10.2 in 3.[89] -> sign error?
Hello, On Mon, 27.03.2006 at 21:50:14 +, Thorsten Glaser <[EMAIL PROTECTED]> wrote: > Toni Mueller dixit: > >I just tried to download a file of some 3 gigs > wget is not designed to do it. If it works, sheer luck. > The internal code uses 32-bit variables all over the place. so you say: Despite its claim of being able to download large files, it really does so only on occasion? Besides that, large file support isn't detected by the OpenBSD port. And fwiw, shortly after posting the question, I started over with curl anyway, just wanted to ask, and take note. Best, --Toni++
distfiles gone?
Hello,
I wanted to fix a problem I have, but stumbled over this:
MASTER_SITE_OVERRIDE="ftp://ftp.openbsd.org/pub/OpenBSD/distfiles/${cipher}/${value}/";
(in bsd.port.mk)
The problem is that this directory
ftp://ftp.openbsd.org/pub/OpenBSD/distfiles/ does not exist. Since
upstream managed to put up a tarball that is different from what's
required in the OpenBSD ports mechanism, but under the same name, I am
now unsure as to how to proceed.
In theory, as far as I understood, the directory named above should be
there and hold all upstream distfiles as a last resort, for all
supported releases (ie, 3.8 and 3.9).
The culprit is db-4.2 which I need for 3.8/i386, but can't easily get
at atm. So far, I hope to get at the file to avoid re-constructing the
port...
Best,
--Toni++
Re: Hylafax
Hello, On Sun, 12.03.2006 at 17:57:44 +1100, Steve <[EMAIL PROTECTED]> wrote: > A diff was posted for Hylafax 4.25 a few weeks back. > > Can I get some guidance as how to apply this so I can test it. that patch is probably applied on top of the hylafax tree. $ man patch Apart from that, there's 4.3.0rc3 out the door, probably meaning that 4.3.0 will be out well before 3.10/4.0 to get in, apparently fixing some 50+ bugs on top of 4.2.5 already. Best, --Toni++
Re: -current: Conflict between efax and mgetty+sendfax
Hello, On Fri, 13.01.2006 at 14:33:23 +, Antoine Jacoutot <[EMAIL PROTECTED]> wrote: > Actually, I need some port guru advice here. I would like to be able to make > mgetty install alongside with hylafax or efax since they could complete each > other. me too. I would assume that the port rather should rename such files to remove as many conflicts as possible. Eg. rename fax.1 to efax-fax.1 and hylafax-fax.1 in their respective ports. Best, --Toni++
Re: A way to verify installed packages?
Hello, On Sun, 14.05.2006 at 07:11:56 +0200, viq <[EMAIL PROTECTED]> wrote: > binary files in /usr/lost+found. Is there a way to verify whether all > packages have their files where they should? Or maybe even a way to figure > out where did those files belong? there's +PLIST which you could be able to peruse, but of course, that doesn't catch your individual modifications (configs etc). Best, --Toni++
NEW: p5-Safe-Hole
Hello, attached you find my attempt at porting Safe::Hole. This module allows you to call subroutines defined outside of a Safe compartment within the context of where they were defined (ie, bypassing the rules for the Safe compartment for these subroutines). Best, --Toni++ p5-Safe-Hole.tar.gz Description: Binary data
Re: NEW: p5-Safe-Hole
Hello Steven, On Thu, 18.05.2006 at 11:20:21 +0200, steven mestdagh <[EMAIL PROTECTED]> wrote: > in DESCR you say this is required for Interchange. it is. > does this mean you are preparing a port for Interchange and necessary > dependencies? Not neccessarily... Interchange is a huge beast. First and foremost, I need to get it up on a 3.9 box, and in the process, I manufactured that port. Best, --Toni++
Re: Hylafax
Hi, On Fri, 12.05.2006 at 16:06:34 +0200, Toni Mueller <[EMAIL PROTECTED]> wrote: > Apart from that, there's 4.3.0rc3 out the door, probably meaning that > 4.3.0 will be out well before 3.10/4.0 to get in, apparently fixing > some 50+ bugs on top of 4.2.5 already. FYI: http://www.hylafax.org/content/HylaFAX_4.3.0_release Best, --Toni++
