Re: obsd 3.4 port of mysql may have error9 issue again...
On Mon, Mar 17, 2008 at 02:50:01PM +, Paul Pruett wrote: just a heads up, for mysql on new openbsd 3.4 just did the make build for src with OPENBSD_3_4 Tag and mysql port from anoncvs today because I was starting to see the infamous errorcode 9 with the beta port of mysql ??? OpenBSD 4.3, you mean. If I run mysqlcheck -A against a lot of databases... about the last database it comes back errors... Error: File './*_drupal/vocabulary_node_types.MYD' not found (Errcode: 9) Error: Got error9 from storage engine error: Corrupt No such issues there with OpenBSD 4.3.
Re: Problems building bison on OpenBSD 4.3
On Tue, Mar 25, 2008 at 02:51:27PM -0600, Gerardo Santana Gsmez Garrido wrote: On 3/25/08, Matthias Kilian [EMAIL PROTECTED] wrote: On Tue, Mar 25, 2008 at 02:28:07PM -0600, Gerardo Santana Gsmez Garrido wrote: I'm running OpenBSD 4.3-stable on i386. Ports are 4.3-stable too. How? It's not even released. Building it from source. You managed to fuck up the build order, somehow. Your c++ compiler can't find its headers. You probably want to move /usr/include out of the way and regenerate it correctly.
Re: GTK2 - what's wrong?
On Mon, Apr 07, 2008 at 11:54:16AM +0200, Zbigniew Baniewski wrote:
Trying to compile a simple example taken from:
http://library.gnome.org/devel/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD
...code below...
#v+
#include gtk/gtk.h
int main( int argc,
char *argv[] )
{
GtkWidget *window;
gtk_init (argc, argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_show (window);
gtk_main ();
return 0;
}
#v-
...I've got in return a lot of errors (below). Of course, it's not possible,
that GTK2 in OpenBSD 4.2 is in totally broken state ;) - so I'm just
missing something. But what exactly? pkg-config seems to see all the
needed included files and libraries. So, why so much error messages?
Why don't you give us the most important piece ? that is, pkg-config output,
and instead a huge amount of meaningless error message.
#v+
[EMAIL PROTECTED] cc base.c -o base `pkg-config --cflags --libs gtk+-2.0`
In file included from /usr/local/include/gtk-2.0/gdk/gdktypes.h:32,
from /usr/local/include/gtk-2.0/gdk/gdkcolor.h:31,
from /usr/local/include/gtk-2.0/gdk/gdkcairo.h:23,
from /usr/local/include/gtk-2.0/gdk/gdk.h:30,
from /usr/local/include/gtk-2.0/gtk/gtk.h:31,
from base.c:1:
/usr/local/include/glib-1.2/glib.h:510: error: conflicting types for `gssize'
/usr/local/lib/glib-2.0/include/glibconfig.h:58: error: previous declaration
of `gssize'
So you picked up some glib 1.2 stuff. I really don't see how.
Re: suggested change to fgetln manpage example code
On Tue, Apr 08, 2008 at 05:49:09AM +0200, Tobias Ulmer wrote: Costs 250$/EUR or something last time i've checked. The electronic version should be available for *ways* cheaper, like $18 or so. There's also a paper book by Wiley Sons, with the rationale and standard, costing ~50 EUR. ISBN 0 470 84573 2.
Re: Optimising OpenBSD
On Wed, Apr 09, 2008 at 08:49:38AM +0930, Matthew Smith wrote: Quoth Ted Unangst at 2008-04-09 08:38... Nothing beats an 8 year old article for the latest info. OpenBSD now comes fully optimized out of the box. Yes, I did notice the age, but that was about all that Google had for me. Optimised out of the box sounds good to me - not having to do anything is the way I like to work ;-) You do realise that this means that the installation time of the base system is now going to be down to about 15 minutes (from over a day) - what am I going to do with all that spare time? I've never before had so much of my hardware recognised without extra effort; it's even recognising my Stallion PCI serial cards - now I just need to figure what I have to do to get them configured. Write new code, instead of fiddling up with old one ?
Re: Chatting with developers? Is it soo 1996?
On Tue, Apr 15, 2008 at 10:12:08AM -0700, Unix Fan wrote: I found an old email on the mailing lists, dating back to 1996, when Theo announced users could connect and chat with the developers on their ICB server. I'm wondering, when did it go private? Why can't users join and chat.. or idle.. and watch OpenBSD development as it takes place, are there any other places to go besides -cvs? Went private at some point in the past, in fact before I became a developer. As a result, there's a lot of stuff on that channel, and not all of it is technical. You've got to realize, there are not that many people with commit rights to the tree. After years working together, we know one another, so things about family matters appear on the channel, or lots of private jokes. This stuff is definitely written with the expectation that no outsiders are listening. And it's good that way. Some public stuff goes on in [EMAIL PROTECTED] or inside the tree proper. Sorry, we don't even have time to do everything we would like, development-wise and documentation-wise, so sanitizing private communication stuff to extract only the public parts is out of the question.
Re: poll(2) vs kqueue(2) performance
On Sat, Apr 19, 2008 at 11:43:20AM +0200, Jonathan Schleifer wrote: Edwin Eyan Moragas [EMAIL PROTECTED] wrote: the question is, which one is more useful when writing new servers? kqueue or poll? poll is more portable, while kqueue should be more performant (at least, that's why it was invented). If your app only needs to run on OpenBSD, NetBSD and FreeBSD, you're just fine with kqueue, otherwise use poll. Generally, I think it's better to use poll and sacrifice that unnoticable performance gain. As usual, depends what you want to do. poll() and select() give you control over file descriptors. kqueue encompasses more events. It's not especially faster, it just leads to simpler code in case you need the supplementary events. If all you need to do is watch over a set of file descriptors, poll and select are the simplest ones to use... and the most portable. In many, many cases, poll() is better. The only case where select comes close is when you want to watch over most of your file descriptors (because you access less memory in such a case). And then, you should profile. I'm not even sure it makes a difference. Most of the places in the system where we have select() are legacies: it it's not broken, don't fix it.
Re: collect2: ld returned 1 exit status....during linking...
On Tue, Apr 22, 2008 at 03:04:23PM -0700, vatocleti wrote: vatocleti wrote: Hey all, I installed 'gmake' to build a Linux based Makefile that uses 'gcc' and when I issue 'gmake' I get the following error: /usr/bin/ld: my_app.o: relocation R_X86_64_32 can not be used when making a shared object: recompile with -fPIC my_app.o: could not read symbols: Bad value collect2: ld returned 1 exit status gmake: *** [libAPP.so] Error 1 any ideas/suggestions are greatly appreciated. Thanks in advance. I added -fPIC to CLFAGS and this got me past this error...is that the proper fix? More or less.
Re: E17
On Wed, Apr 23, 2008 at 04:22:51PM +1000, Rich Healey wrote: Where can i find the E17 port maintainer? This info doesn't seem to be in mine, perhaps my tree is borked? make show=MAINTAINER gives you The OpenBSD ports mailing-list [EMAIL PROTECTED] so there you have it.
Re: Rolling release?
On Wed, Apr 23, 2008 at 03:04:35AM +0200, Zbigniew Baniewski wrote: On Tue, Apr 22, 2008 at 08:48:47PM -0400, Jason Beaudoin wrote: the devs have been hard at work for many years, and I'd be willing to bet that they like the system they've come up with. If they didn't, they'd change it. But it's pretty valid to ask? I thought, that's the mailing lists are for. Maybe I'm wrong. No, it's a valid question. There are hints of answers and even answers if you read the mailing-list archives, but it's possible to overlook them. Let me explain things to you another way. OpenBSD tries to have quality releases, with several goals. Those goals include keeping support for a variety of non mainstream architectures alive. There are various reasons for that, one of which being that it is useful for i386/amd64, because some other arches are good at finding some classes of bugs that affect all arches, but are more apparent on strict alignment architectures (for instance). It's also good because it attracts kernel and driver developers. With that in mind, OpenBSD-current is always high quality, in theory. In practice, comes release time, building and testing the release on each and every arch weeds out hundreds of bugs... and takes a big chunk of time and nerves out of Theo, and some other people involved. Thus the very quick reaction. We're trying hard to go up, up, up and have better and better releases. If you read the archives, you'll see lots of calls to test things, in a real community spirit, instead of the current `gimme, gimme, gimme' frame of mind a lot of our users have... so there have been some hard choices with respect to support, especially wrt backporting stuff to -stable, or actually making these releases. There will be hard choices in the future, undoubtedly. Hence the harsh reactions from the people involved in the release process. Just read the ml around `release build time' (which was a few months back, actually, that's how slow the release process is), and you'll figure out for yourself why `a release a month' is a bad idea, and also why the people involved reacted so violently to your apparently innocuous email... it kind-of implies the release process is something trivial you can change as you want, which it obviously is not... and it also dismisses the ten years of experience that our fearless leader has. Kind of insulting, don't you think ? ;-) Contrarily to what you might think, this email is NOT an exhaustive description of things as they are. It's a very quick, oversimplified summary, of a taxing process and decisions. There are glaring mistakes, for the sake of simplification. In a nutshell, release is ways harder to do than you think.
Re: Nvidia Quadro NVS 140M
On Sun, Apr 27, 2008 at 01:13:40PM +1000, mufurcz wrote: Hi, We've got a few Lenovo T61 with Nvidia Quadro NVS 140M video cards. As far as I know, these cards are based on the GeForce 8400M G or GS chip set (not an expert), and provides some entry level 3D performance, more than enough to run X. Will this cards supported in the upcoming 4.3? My R61 has got the same card, it's supported in 4.3, to the extent that I have the full panel resolution correctly detected. However, X is slow, really slow. And there's no acceleration for anything, including no xvideo mode. xvidtune doesn't allow any other mode but the native mode. So, depends what you intend. Basic desk work with `normal apps' like xterm: no issue. Fast stuff with accelerated graphics, video - stay away Maybe nouveau will be better. It's so fucking hard to find a correct laptop where most everything will work correctly these days...
Re: web development on OpenBSD
On Mon, Apr 28, 2008 at 09:56:19AM -0300, Vinicius Vianna wrote: Maybe the best languages for start web development would be PHP and Perl, i don't know about ruby since i've never used it, but a lot of people talks nicely about it ;) The current situation sucks a bit. You've got a choice of classical web dev environments, like perl's Mason, which are fast, but a bit difficult to code for, and so-called `modern' web environments, like ruby-on-rails, or perl's catalyst (or php symphony, if I'm right), which would be nice, except that they're REAL SLOW, and so you need a killer machine to run any kind of web server. Google's approach of compiling java into javascript has not yet made it to the world of php/perl/python, as far as I'm aware, though it might be the real solution for maintainable ajax...
Re: web development on OpenBSD
I am currently running a web site which says http://joomla.* Strangely enough, it's a drupal site, with no joomla at all. (after spending a week of hair pulling trying to coerce joomla to do whatever I wanted, as the `best-of-breed' solution of choice to brain-dead newbies, I settled on a sensible CMS that actually works)
Re: web development on OpenBSD
On Wed, Apr 30, 2008 at 01:42:05AM +1000, Joel Sing wrote: AFAIK Amazon.com is primarily developed using Mason, an excellent Perl-based web site development and delivery engine - I highly recommend it: http://www.masonhq.com/ Yeah, historically, that's been the case. I have absolutely no clue whether the current incarnation of amazon is still HTML::Mason, though. while mason is very nice for pure web template code, it does absolutely nothing to help you organize your DB access, or even give you sane urls for interactive sites. You really need something like Class::DBI / DBIx::Class or Rose::DB for that. The current trend is Catalyst, which is very nice, but really slow compared to mason... it uses a lot of new-fangled perl features, which are not exactly fast (especially multiple inheritance).
Re: : web development on OpenBSD
On Tue, Apr 29, 2008 at 06:10:41PM +0200, Raimo Niskanen wrote: On Tue, Apr 29, 2008 at 05:15:43PM +0200, Marc Espie wrote: I am currently running a web site which says http://joomla.* Strangely enough, it's a drupal site, with no joomla at all. (after spending a week of hair pulling trying to coerce joomla to do whatever I wanted, as the `best-of-breed' solution of choice to brain-dead newbies, I settled on a sensible CMS that actually works) I am curious to know which one? Sorry, don't want 100s of people to bang on it, as the server isn't all THAT fast. I have been banging my head into joomla for a while, and maybe it can do what I want, but I want user names and passwords encrypted among other things and that does not seem to be among their design choices... If you have any amount of logic, you'll find drupal to be quite refreshing for a change. And yeah, drupal has various secure modules that help. The OpenBSD ports include more or less the plugins I use, there are hundreds more where that comes from.
Re: : : web development on OpenBSD
On Wed, Apr 30, 2008 at 09:36:59AM +0200, Raimo Niskanen wrote: From which release is Drupal in ports? I can not find it in OpenBSD 4.1. I know it is time to upgrade but my installation runs sooo nicely now. 4.3, excellent time to update.
Re: : : web development on OpenBSD (Drupal)
On Thu, May 01, 2008 at 07:46:06PM +1200, Richard Toohey wrote: On 30/04/2008, at 7:36 PM, Raimo Niskanen wrote: Oops my bad english. I thought drupal was a for me unknown common english word, not a CMS name. It was which CMS system you had chosen I was curious to know... Which brings us back to the OP's question on web development software on OpenBSD ... Technically, drupal is just an extensible cms. web development still encompasses way more than that. ;-)
Re: make fails on @pkgpath net/libnet
On Fri, Feb 17, 2006 at 08:48:44AM -0600, [EMAIL PROTECTED] wrote: Novice Alert! I keep hitting this error output when trying pkg_add or use ports method to install nmap The instant cases were pkg_add nmap-3.95p0-no_x11.tgz Error is: Unknown element: @pkgpath net/libdnet,no_python So what is the root problem? Does nmap really need all that? Anyone know what this error is trying to tell me? You're mixing up -stable with -current, which does not work on OpenBSD.
Re: xchm port
On Sun, Feb 26, 2006 at 10:26:02PM -0300, Joco Salvatti wrote: I have installed xchm from a non-offical OpenBSD port. The installation process ran fine, however the program is not running completely fine. When I try to open a .chm document it doesn't open. In the status bar the message connecting... appears and nothing else happens... Has anyone here faced that before? What should I do to solve it? -- install the official package ?
Re: OBSD 3.8: bash, libiconv, libintl in rc.securelevel
Chris 'Xenon' Hanson wrote: While poking around, I see that there is a package for a static version of bash: ftp://ftp.openbsd.org//pub/OpenBSD/3.8/packages/i386/bash-3.0.16p1-static.tgz 2. For an automated installer, how would the installer know where to get the proper package? The URL above works for 3.8, but will be wrong for 3.9. Is there an environment variable or string that the installer can expand to get the 3.8 or 3.9 portion of the URL? And then, how does it figure out the exact package filename for the static version of bash for a OS release it's never seen before? Without a heavy-duty web search,how would it know that the 3.8 static release of bash was named bash-3.0.16p1-static.tgz? It'd be nice if the script doesn't immediately break and need updating when 3.9 comes out. We have the mechanisms in place for updates to figure this out. One can also currently install a package without knowing the exact version, through pkg stems. More thorough search mechanisms will be present in the next release. And it's likely automatic determinations of correct default location to grab a package will work. For the case at hand, something like PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/3.9/packages/i386/ sudo pkg_add -i bash ought to more or less work. It's currently not possible to specify a specific flavor without a version number, but interactive mode copes nicely. Your example is a bit unfortunate, since we decided it was not worth it to have a separate -static bash version. All in due time... there are no mechanisms yet to deal with this kind of meta issue, at least providing a `reasonable' update path for people who used to have a static bash version (okay, we do have some, it will replace the static version with the normal version).
Re: OpenBSD 3.8 ports quality?
On Tue, Mar 14, 2006 at 12:10:53AM +0100, Ramiro Aceves wrote: Why do you insult to the GNU people? aren't you using their compiler?. I do not understand why you say such things. Peace, please. *I* can insult the GNU people. I've spent enough time working around their over-engineered code that somehow, breaks all over the place (latest issue being GCC's libmudflap being WAYS too chummy with linux headers), or can't possibly work without hordes of lemmings fixing it all the time (libtool, for instance). I guess that's the reason I spent most of my time debugging KDE bits instead of gnome... at least THAT code is sane.
Re: old libs removal
On Fri, Apr 28, 2006 at 09:51:57AM -0600, Bob Beck wrote: If you do this - any apps which are linked against the older versions will likely stop working. the reason upgrade leaves them lying around is so that your applications which were built using an older version of the OS will continue to get the correct share library. My suggestion is don't do this - if what you really want is a clean system, consider doing install instead of upgrade and reinstalling your applications from versions compiled on the version of OpenBSD you are installing -Bob These days, if you only have packages installed, and they're recent, they should register every shared library they need. We could have a fairly simple tool which would remove those old libs, after validating no other package leaves them...
Re: exploit for openbsd 3.9 php 4.4.1p0/5.0.5p0
On Tue, May 02, 2006 at 10:05:28PM -0700, paul dansing wrote: Is there some reason this issue is being ignored? What, you people need to see an exploit before you will even LOOK at it and answer whether it is vuln? I'm not the maintainer of php itself, but still I have an opinion. I don't like php, from a security point of view. It has an AWFUL track record. Some people will tell you it has seen lots of vulnerabilities because it's in heavy use. Well, I've had a look at the code, it has seen lots of vulnerabilities because it was never designed with security in mind. That said, we provide php because some people may want it. I personally would NOT want to run that on any kind of web server (in fact, I use perl's HTML::Mason as the same kind of framework). I can give you a simple answer though. Yes, php* is vulnerable. Doesn't matter whether you're talking about this vulnerability, or another. There will be another one lurking around the corner. Fixing vulnerabilities in the php code is like sticking a finger in a dike. Great legendary stuff, doesn't really work in reality.
Re: exploit for openbsd 3.9 php 4.4.1p0/5.0.5p0
On Wed, May 03, 2006 at 01:08:50AM -0700, paul dansing wrote: also, i wish openbsd would release updated packages instead of just the patches. i would do it myself but who would trust a binary some random guy posts? openbsd maintainers have to step up and do this. why aren't you guys releasing package updates anyway? when you post a source patch on your errata page, take the few extra minutes to make a updated package and post that as well please! :) You don't know what you're talking about. Releasing updated packages means having an extra machine that would run only stable, and building stuff on that as well. This is not a few minutes more, more like three or four hours of definitely not fun work.
Re: Mic recording
On Mon, May 08, 2006 at 12:40:30AM +0200, Rico wrote: Hi Anyone who can recommend a good and easy to use tool for recording audio (mic) from the packages? It doesn't need to have any gui but build in compression like MP3 is preferable. I know there are a couple of different tools but what are the best ones? I haven't tried it for recording (no mike around), but audacity seems to be a very good tool for handling audio samples... its record button seems to work as well (even though I'm getting nothing without a mike), and it can compress stuff out as mp3 or ogg vorbis.
Re: Qt Error compiling
On Mon, May 08, 2006 at 10:06:35PM -0500, uv negativa wrote: Hi i compile # env MOC=moc3 env UIC=uic1 ./configure [...] checking for uic... not found configure: WARNING: No Qt ui compiler (uic) found! any ideas obvious typo on your part !
Re: PHP vs Mason vs Ruby vs JSP/Tomcat
To refocus the current discussion somewhat, I'm going with HTML::Mason myself, for various reasons. The first one is that I trust the perl people to do something sensible. They've got a lot of advanced frameworks that do work, and they understand something about security. The downside is the documentation: HTML::Mason does not have the greatest documentation in the world, you have to read the full manpage to make sense of some of it. And there are not that many advanced examples around that are actually usable. I tend to not like sites where everything lives in a database (and this is the case for a lot of mason examples). The second point is the DBI framework. There are some genuine gems in there. Including Proxy/ProxyServer, which can be a life saver in some situations. And sqlite, which is really nice for medium sized applications (and requires no extra password ! a big plus in my opinion). Compared to 'ruby on rails', I imported p5-HTML-Prototype this week-end. Yes, this is the same ajax framework, adapted to perl. The documentation says it's designed for Catalyst, but it does work correctly with Mason as well... I haven't yet really started doing useful stuff with it, but proof-of-concept pages do work. Catalyst itself might be another solution (a big large one). Not too fond of its design myself. I do not need true MVC designs for my web, and I don't care all that much about completely well-formed XHTML. There is some fledgeling Catalyst port somewhere on the list, it will probably go somewhere soon. The main issue with perl modules is that there are so many of them. Most of CPAN is trivial to port over to OpenBSD, but is it worth it ? Most of it probably isn't... Some further notes: the apache2 framework is still `less' interesting than what we have in apache1, IMO. They keep building and building, but some basic functionality appears not to be there. e.g., our apache + Mason performs internal redirects. The apache2 installation I've seen does not. I'm also not really happy about existing DBIx frameworks for Mason... there does not seem to be any. True maps of databases to OO seem to exist, but I'd like a simple MVC schema for databases rendering and modifications, and so far it seems like I need to write my own. In the end, with correctly designed applications, Mason + sqlite + prototype + DateTime goes real fast, and does more or less what I need it to do. I'll have to do some real benches of Apache::DBI. In my setup, it does not seem to speed anything up, plus it adds some interesting bugs. It's probably a bit more raw than I would like, but I don't mind all that much. I'd appreciate some pointers to some other HTML::Mason apps with source code, or `frameworks'. So far, I've seen RT and Bricolage, and that's about it.
Re: package dependencies
On Thu, Jun 15, 2006 at 10:47:40PM +0100, poncenby wrote: p.s. this question comes from the need to know the exact packages to download and burn to CD in order to get a reasonably usable desktop system running gnome, when said system has no connection to the interweb Just use pkg_add ! pkg_add -n will download whatever packages you need without installing them, and if you set PKG_CACHE, then stuff will be kept there. Note that this CAN be done on a non-OpenBSD system, since pkg_add is perl.
Re: package dependencies
On Sat, Jun 17, 2006 at 12:34:47PM +0200, Bihlmaier Andreas wrote: On Sat, Jun 17, 2006 at 11:20:44AM +0100, Stuart Henderson wrote: On 2006/06/17 11:38, Bihlmaier Andreas wrote: Could you elaborate on this, since that was my first thought how to do it, but it didn't work (and doesn't), do I need a special -F flag? setenv PKG_PATH $OBSD_FTP/snapshots/packages/i386/ setenv PKG_CACHE $HOME Results in: /usr/sbin/pkg_add should be run as root parsing kdebase-3.5.3 Can't install kdebase-3.5.3 because of conflicts (kdebase-3.5.1p4) /usr/sbin/pkg_add: kdebase-3.5.3:Fatal error This doesn't work because: 1. you already have an older version installed. Add -r (replace) to the command line. 2. you mix -current packages and -stable OS. I know this quite well (using OpenBSD since quite a while), but you have to read the previous mail I was responding to. Marc Espie said that I could use pkg_add -n ... (-n = Do not install) to fetch a package together with it's dependencies, but that doesn't work because pkg_add does checks ... Just tell it to install stuff elsewhere instead, or tell it to use -r anyways. It will still work. Why shouldn't it ? exercise some logic...
Re: pkg_add -u not working
On Sun, Jun 18, 2006 at 12:03:34AM +0200, [EMAIL PROTECTED] wrote: In my oppinion the tool does NOT WORK like descriped... Why? If you update from 3.8 to 3.9 it MAY work. But if a depency was updated or so it totaly fails... godfather $ sudo pkg_add -ui Looking for updates: complete Are you pointing it at a valid package repository ? doesn't look like it. Btw: The other problem of that tool is that the Packages at the FTP must be up2date too... Of course they must ! that's a prerequisite. And guess what ? they often are. I would prefere a Ports-Solution for pkg_add -ui but there`s none. *my oppinion but I think this examples proofs me right* You'd better really start explaining what you are doing, and what you expect the tools to do... so far, you are not making any kind of point. pkg_add -ui does exactly what it is supposed to at this point in time. If it doesn't work for you, it's probably because there's something you have completely not understood...
Re: Dynamically Increase IPC on OpenBSD ?
On Mon, Jun 19, 2006 at 09:43:59AM +0200, Vincent Blondel wrote: Hello all, I would like to increase some IPC values on my OpenBSD 3.9 box. These parameters need to be changed for Squid. When I look at the current values I receive next result [EMAIL PROTECTED] [/etc/squid] # ipcs -Q msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) and would like to set these new ones. options MSGMNB=8192 options MSGMNI=40 options MSGSEG=512 options MSGSSZ=64 options MSGTQL=2048 but I still haven't found how I could increase dynamically these settings and I don't find them in sysctl proposals. That's kern.seminfo and kern.shminfo
Re: pkg_add -ui - Using Ports except or real Packages?
On Mon, Jun 19, 2006 at 05:10:21PM +0200, [EMAIL PROTECTED] wrote: Or, the other solution, would be enable pkg_add -ui (maybe with another argument to use Ports) using the Port-system to update. The interface will use PKG_PATH. After all, using ports is just another kind of url, similar to ftp/scp. Unfortunately, this needs an almost complete rewrite/redesign of the way package lookups and package repositories are handled in the current tools. If you want, you can look at what's going on yourself, look in the package tools, around the PackageLocator.pm file and the PackageRepository stuff. You'll notice finding packages is not as generic as it should be (there should be a generic `search object', so that you can locate packages by stem, or by package path, or some other combinations), and the current way to look up packages does things the wrong way (looks in every repository instead of stopping at the first one that holds reasonable candidates)... and there's even some completely non-functional scaffolding to go build packages from the ports tree. Hey, if it was 4 hours of work, it would already be in the ports tree. The other way around (FETCH_PACKAGES) has been functional since the last ports hackathon thanks to nikolay, and there were already quite a few minor issues to solve to make it work correctly (partial downloads did tend to stick around in the package cache). As far as building and replacing in source goes, we do know we actually need to replace libtool with something that works, and doesn't go looking in /usr/local all the time (obnoxious twit), but again, this is not a 4 hours endeavor...
Re: Recompiling Perl 5.8.6
On Sat, Jul 15, 2006 at 12:42:25PM +0200, Karel Kulhavy wrote: Is it OK to download perl 5.8.6 (the same that is in OpenBSD 3.9) then compile it using supplied hints/openbsd.sh and install over the existing perl? I want GDBM_File and GDBM_File is in perl 5.8.6. No, you don't know that it is the same. You'd better start off running a diff to make sure... Anyways, I can build a GDBM port, it's no hardship, and probably trivial to do...
Re: Recompiling Perl 5.8.6
On Tue, Jul 18, 2006 at 12:40:10AM +0200, Marc Espie wrote: Anyways, I can build a GDBM port, it's no hardship, and probably trivial to do... Committed. Quite simple, seems to work. Much better than recompiling the whole of perl.
Re: pkg_add
On Thu, Jul 20, 2006 at 10:58:15AM +0300, Claudiu Pruna wrote: Hi there, Can anybody enlighten me, why in OpenBSD 3.9/i386 with GENERIC #617, happens the followings: ftp get bash-3.1.1p0.tgz |pkg_add -v - local: |pkg_add -v - remote: bash-3.1.1p0.tgz 227 Entering Passive Mode (129,128,5,191,166,108) 150 Opening BINARY mode data connection for bash-3.1.1p0.tgz (514696 bytes). Error from ftp://ftp.openbsd.org/pub/OpenBSD/3.9/packages/i386/: Unknown command. Can't resolve - ftp: |pkg_add -v -: short write 426 Network seems to have barfed - Let's all phone our ISP and go postal! 15928 bytes received in 7.75 seconds (2.01 KB/s) and PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/3.9/packages/i386/; Because it's broken in 3.9, it was fixed since then.
Re: stopping robots
I've got a robots.txt, and a script that loops to infinity. Actually, it's a useful page on the server, there's a list that can be ordered two ways, and switching from one to the other increments a parameter at the end of the invocation. A robot has no business reading that specific page in the first place (in fact, they're disallowed to), and after a small number of loops (10 or 15), the webserver becomes very unresponsive, thus ensuring the robot writer will lose a lot of time on that page. Assuming reasonable technologies (e.g., mason), the url does not even have to look like a script...
Re: infinite tree in qt libraries
On Wed, Aug 09, 2006 at 11:01:40AM +0200, Karel Kulhavy wrote: Is this infinite directory tree intentional? Yes. It's a symlink, so tools don't see it. You have to explicitly walk it down yourself. It's needed to simplify some builds which expect the whole of qt to live in a single directory.
Re: mirroring packages without much bandwidth overhead
On Tue, Aug 15, 2006 at 11:40:18AM -0400, Arnaud Bergeron wrote: On 8/14/06, Stuart Henderson [EMAIL PROTECTED] wrote: On 2006/08/14 17:59, Arnaud Bergeron wrote: In which case, the patchlevel needs to be bumped (eg. foo-1.0.tgz - foo-1.0p0.tgz). No boom here, unless the maintaner was lazy. No, /usr/lib changes don't bump patchlevels of every package. You are right, but I was thinking about a dependancy in terms of other packages. You're still wrong, we would bump package names all the time otherwise. And we don't. There's a concept of package signature, built from the package name itself, and a freeze-dried version of every dependency used to build the package. That's what pkg_add uses to decide to update packages. As far as pkg names bumps go, we change pkgnames every time something *in the package directory itself* changes. Say, if we have to adjust WANTLIB, or DESCR, or something like that, then the package changes. That's the kind of thing the PLIST_DB database catches, since it will refuse to record distinct plists with the same package name (carefully dropping some information, like package signatures, for instance). This is done so that pkg_add can decide when to update: the pkg names, plus the pkg names of dependencies, are just enough to decide whether something is up-to-date or not. In fact, I need to write a patch so that messages like: Updating gimp-2.2.10 - gimp-2.2.10 appear less confusing.
Re: The future of NetBSD
On Fri, Sep 01, 2006 at 01:15:09PM -0700, Jon R H wrote: There is no way anybody can win from any of this! That's the worst part of it all! all BSD's will are suffering! Nope. I don't see OpenBSD suffering from this, not for real. The BSDs have always been about the code, not the organization. As long as there are people writing good code with a reasonable licence, who cares where they live ? Certainly not I.
Re: OT: Amarok Sound Device
On Sun, Sep 03, 2006 at 12:57:52AM +0100, Edd Barrett wrote: Hiya, I decided to bite the bullet and test a 4.0 snapshot. Seems great so far. Seems the guys over at amarok have replaced gstreamer with xine to decode compressed formats. In the old gstreamer config section you could specify a new sound device, which I did because I use a USB audio device. However it seems this option does not exist for the new xine engine. Does anyone know how to change the device, I have two sound cards as well. I generally change things directly at the system level. Namely, all this code is using /dev/audio, /dev/mixer and /dev/sound. But these three devices are just links. They normally pointer to /dev/foo0 you can just make them point to /dev/foo1, and be done with it. The good thing is that this fixes all audio apps, not just amarok, without having to tweak anything else.
Re: figures with magicpoint
On Mon, Sep 11, 2006 at 02:18:31PM +0530, Girish Venkatachalam wrote: What do I use? I need a spartan simple tool like magicpoint itself. Is xfig the right choice? What about inkscape? I am somewhat excited with SVG. Are ther other image manipulation tools out there? I guess gimp would be an overkill. And openoffice is not meant for UNIX geeks.:-) metapost is great if you need figures with tex captions (though it's a programmer's tool). I'm also partial to kig, in kde-edu, which is great for geometric stuff. Gimp is a fine pixel drawing program. Depends a lot if you can live with pixel-art, or if you really need vectorial stuff. We don't have a working port of inkscape yet. This is a big issue with boehm-gc based software: this library tends to work rather badly on OpenBSD for now. There are also a few drawing programs in koffice, and they tend to get better from release to release...
Re: Low priority or real coders
What do I care about the size of vim ? My development box has got 1G of real memory, and vim is the most single important tool on that box ! All I care about is that it starts up fast enough, and it does what I need it to do (visual highlights with v, and multiple windows). Heck, it's pretty small compared to what it does. If you want to look at people's development tools these days, have a look at eclipse.
Re: qt 3.3 or later
On Mon, Sep 25, 2006 at 07:36:14PM +0200, Karel Kulhavy wrote: Hello I am trying to compile qcad 2.x from sources which says Qt 3.3 or later - which packages should I install? Just qt4-4.1.0p0.tgz? Or some more? qt3-mt-3.5p4.tgz That's the one, this is qt 3.3.5, in fact. qt 4 is an entirely different beast, probably better than qt3, but most programs will need some adaptations to work with it. The qcad port should maybe get updated at some point ?
Re: glib2 fails to build on ppc-current: pthreads issue?
On Fri, Sep 29, 2006 at 09:15:49AM +0200, Antoine Jacoutot wrote: On Fri, 29 Sep 2006, Douglas F. Calvert wrote: checking for pthread_create/pthread_join... no checking for pthread_create/pthread_join in -lpthread... no checking for pthread_create/pthread_join in -lpthread32... no checking for pthread_create/pthread_join in -lpthreads... no checking for pthread_create/pthread_join in -lthread... no checking for pthread_create/pthread_join in -ldce... no configure: error: I can't find the libraries for the thread implementation posix. Please choose another thread implementation or provide information on your thread implementation. You can also run 'configure --disable-threads' to compile without thread support. *** Error code 1 Guys, come on, you know there's a config.log generated by configure. Why don't you give us the relevant excerpts ? e.g, what it's actually trying to compile and not finding ?
Re: 24kHz plays slower on 3.9
On Wed, Oct 18, 2006 at 10:29:37AM +0200, Karel Kulhavy wrote: 48kHz, 44.1kHz and 8kHz sampling rate wavs play the right speed on my system. 24kHz play annoyingly slower. I took a 44.1kHz song, resampled to 24kHz using sox rate -ql and checked with audacity, if the sox resampling is not wrong. It isn't, the resulting files have both exactly the same length (measured from the beginning to a prominent audio feature at the end). Have you checked that your soundcard supports 24KHz ? some don't, and you will end up with an approximation. 24Khz is not a `natural' speed, 8kHz, 44.1kHz, 48kHz is. 16kHz often is, as is 22kHz. Depending on your soundcard, you're probably hearing the sound at 22kHz (a bit slower) or 16kHz (very much slower).
Re: update automaticly
On Thu, Oct 19, 2006 at 09:28:23PM +0700, sonjaya wrote: i have script for update automaticly here: # cat /root/update_part1.sh #!/bin/csh cd /usr/src setenv CVS_CLIENT_PORT -1 setenv CVSROOT [EMAIL PROTECTED]:/cvs cvs -d $CVSROOT -q up -rOPENBSD_3_9 -Pd date /root/update_part1.log when i try run that script get error such like this : # sh /root/update_part1.sh ^^ /root/update_part1.sh[3]: setenv: not found /root/update_part1.sh[4]: setenv: not found cvs update: CVSROOT -q must be an absolute pathname cvs [update aborted]: Bad CVSROOT. please tell me to fix it . You have to choose one shell and stick to it
Re: Package update candidates
On Sun, Oct 22, 2006 at 02:18:09PM +0400, Bruno Carnazzi wrote: Hi misc, When upgrading some packages with 'pkg_add -u', I sometimes see : No need to update uptodate_package and Candidates for updating package - the_same_package_the_same_version What's the difference ? Please notice that in first case, the package seems ignored, and in the second case, the package seems uninstalled and reinstalled in the same version... Dependencies it was built again have changed. For instance, newer shared libraries. You have to update these to a newer build so that eventually, you'll be able to get rid of the old shared libraries...
Re: OpenBSD AJAX
On Tue, Oct 24, 2006 at 12:55:09AM -0500, Sam Fourman Jr. wrote: Just a Quick Question, I have been searching for a direct answer to: is it possible to have a AJAX enabled Website hosted on OpenBSD? Yes. I have one. the reason why I am asking is because Apache is version 1.3.x (due to licencing issues). if not Maybe there is another http server that would support it? Not related. Most of the AJAX technology is *client-side*. All it does is callbacks to the server, which serves normal requests. There are some AJAX frameworks already in OpenBSD. There are two perl frameworks, for instance. And ruby-on-rail is known to rely on java. As far as responsiveness goes, Apache 1.3 has enough server-side module supports for the application to (more or less) live within the server.
Re: your mail
On Tue, Oct 31, 2006 at 01:19:09PM -0500, John Kintzele wrote: Hello, OpenBSD 4.0 installed from official CD (i386). No problems. In trying to install various Gnome apps (e.g., gedit), I'm running into a missing lib problem, and while I've people who've had the same problem on Google, I haven't found a clear response that seems to have fixed the problem. (I am performing this pkg_add via FTP). In a nutshell, here is what I'm seeing from pkg_add: Can't install gnome-vfs2-2.10.1p0: lib not found crypto.12.0 Even by looking in dependency tree... etc. Maybe it's in a dependent... etc. Can't install gnome-vfs2-2.10.1p0: lib not found ssl.10.0 etc. On my system, libcrypto.so.12.0 dates back from september 2005... Where are you getting those packages from ? the 3.8 directory ?
Re: i18n/l10n
On Mon, Nov 06, 2006 at 12:56:29PM -0700, Jack J. Woehr wrote: Looked in the FAQ and don't find any path to start understanding internationalization and localization in OpenBSD ... if there is such a path? Nope, there isn't. For one good reason: it's still work in progress. The integration of i18n mechanisms is not finished, we do not have the widechars to multibyte code yet (just stubs for it). As it is, it is enough to have partial support in places that matter, and thus a lot of `new ports' compile... most of the i18n stuff comes from 3rd party apps for now (perl, gtk, qt come to mind). There is very little sense in documenting it until it is more usable. Hopefully, the situation will improve.
Re: layout of filesystems on OpenBSD
On Fri, Nov 10, 2006 at 07:32:38PM +0100, Robert Urban wrote: For example, how could /usr/X11R6 possibly represent a threat to eat all the space is /usr? X11R6 content is static. (yes, I know, software packages put stuff there, but for the purposes of this discussion it's static). Actually, no, on OpenBSD, software packages do not put stuff there.
Re: How to force reinstall package
On Sat, Nov 11, 2006 at 04:44:25PM +0100, Piotr Jedryczek wrote: On 11/11/06, Antoine Jacoutot [EMAIL PROTECTED] wrote: pkg_add -F installed /usr/ports/packages/amd64/all/libiconv-1.9.2p3.tgz doesn't work? No. But can I remove entry in /var/db/pkg, remove files from package manually and then install the package? No, it's a thoroughly bad idea. Reading the man page is not enough, you should try to actually understand what is going on. Specifically, you should be able to force it using the right options: pkg_add -F installed -r In any cases, if you changed the configure options, you should also change the package name. This is not hard at all. Just define your own flavor. And you should also check that your package is complete. At least check that update-plist and lib-depends-check are happy with the new package. If you tinker with the installation manually, you will regret it. Having reliable packages and dependencies come at a price. If you tinker with the way packages are built, you should still follow the rules. Otherwise, you're going to break your installation. Now, this is just some piece of advice. Do what you want with it, but don't come whining later if you break everything. ;-)
Re: Perl distribution incomplete in 4.0?
On Mon, Nov 27, 2006 at 01:42:02PM -0700, Kevin Konowalec wrote: So does the default perl distribution in 4.0 have problems with dynamic linking of modules? Should I rebuild perl? Try to statically load the module? No, it has no problems with dynamic linking of modules. It must be something wrong you did.
Re: Perl distribution incomplete in 4.0?
On Mon, Nov 27, 2006 at 05:32:14PM -0700, Kevin Konowalec wrote: On Nov 27, 2006, at 4:58 PM, Kevin Konowalec wrote: Well all I've done so far was: - install OS - install packages. which step was wrong? As you wrote in your earlier message, someone told you you need the X11 libraries. It might actually be true after all. You might try 'ldd' on GD.so and see if that sheds any light. Well I did grab what I was told were the required few X libraries but I'm beginning to wonder if I'll have to install the whole shebang If you really want to fix this, you might start by giving us consistent information. Reading between the lines, in one message you tell us you informed the system `normally' and packages on top of that. But you're obviously lying, since you tell us you grabbed the X libraries manually. I don't know what you did to get pkg_add to not complain about missing libraries. Frankly, I don't care too much. I have more interesting things to do than trying to figure out stuff from half-formed bug-reports. There are about two ways you can do stuff: - use the tools of the system, install it as it's meant to be used. You need gd and it says it needs the X libraries ? then install the X libraries. - you want to be smart and do it yourself, and get rid of the X libraries dependency ? then be smart, and do it. Be aware that it is not that simple, and wishful thinking won't work. Just installing stuff without parts of the system won't work very well. OpenBSD is not a good system for guesswork. As far as developers go, we spend enough time making sure the supported configurations work...
some more ports hackathon thanks
I can't stress enough the importance of the ports hackathon. The current ports infrastructure changes come directly from some discussions we had during that week. The idea of streamlining MULTI_PACKAGES was completely non existent before Budapest. Maybe I would have thought about it at some point, maybe not. The offsprings from that idea are nothing short of amazing (at least for me). The current framework is much, much clearer and faster and powerful than it was two months ago. And this wouldn't have happened without Budapest. So thank you again to anyone who donated, directly or indirectly, so that we could meet and hack during the week.
Re: Links sources and GPL
On Mon, Dec 04, 2006 at 04:56:46PM +0100, Karel Kulhavy wrote: From this I have a feeling that the Links distribution of OpenBSD doesn't accord to the terms of GPL. Do you have an argument to convince me that I am wrong? ftp ftp.openbsd.org cd pub/OpenBSD/distfiles ls links* you can't have looked very far, have you ?
Re: Compiling netpbm
On Tue, Dec 05, 2006 at 11:50:48AM +0100, Karel Kulhavy wrote: Hello I want to use xpm2ppm, but it doesn't work because it says [EMAIL PROTECTED]:~$ xpmtoppm vnc/img_0.xpm xpmtoppm: Input file has line that is too long (longer than 2048 bytes). Obviously, someone programmed with fixed-size buffers. I would like to increase the compiled-in buffer size from 2048 to 4096 and try again. I would like to get the source for netpbm somewhere, change it and compile. However it turns out to be an impenetrable obstacle: - The OpenBSD website describes only some CVS method which seems to involve getting sources for all programs in the operating system and I don't have space for Nope, again, you read wrong. For netpbm, you just have to grab the ports tree. Maybe you should have followed the obvious link `Application packages' and read the fine document there. that: Filesystem 512-blocks Used Avail Capacity Mounted on /dev/wd0a 74935160 70114912 107349298%/ - Getting sources - web - ports - graphics - netpbm there are no sources, only some auxilliary files Of course there are no sources ! but there is a plain indication of where sources are in the Makefile. - when I download the official netpbm 10.26.34 source and say y enter openbsd enter enter enter enter library filename or 'none' [libjpeg.so] libjpeg.so.62.0 JPEG header directory [default] == /usr/local/include libtiff.so.37.3 /usr/local/include libpng.so.4.2 /usr/local/include libz.so.4.1 /usr/local/include (the filenames were determined using locate), the compilation of netpbm crashes with libopt results: ' -L/home/clock/netpbm-10.26.34/lib -lnetpbm -ljpeg.so.62' /usr/bin/ld: cannot find -ljpeg.so.62 collect2: ld returned 1 exit status gmake[3]: *** [ppmtompeg] Error 1 gmake[3]: Leaving directory `/home/clock/netpbm-10.26.34/converter/ppm/ppmtompeg Is it possible to compile netpbm on openbsd from the sources without extensive OpenBSD maintainer expertise? Yes, people routinely manage to do it. But they read the documentation, and don't try to reinvent stuff from scratch. Read the ports documentation. man ports for starters. Basically, all you have to do is untar the ports tarball under /usr/ports (which is reasonably SMALL for your needs, under 30M), then cd graphics/netpbm, and type `make'. You are insisting on doing things your own way. Wishful thinking does not replace reading the documentation. Why don't you try slowing down and reading through stuff ? Are you deficient ? I've got the impression you read one word out of five and skip through most documents like you already know what they contain... By now, it should be painfully obvious that you don't have a clue.
Re: Doubt about license
On Sun, May 04, 2008 at 03:38:13AM +0530, debian developer wrote: 1. BSD license is completely free. No one needs to give back changes forcibly(the GPL way), hence this is completely free. If what i hear is correct, there are companies(Microsoft) which take BSD code (network stack i hear) and made it proprietary by not giving back anything. What i don't understand is are we not loosing anything in this case?? I can understand that there are many more companies which have used the code(Apple) and given back but there are also opposite ends... No, nothing is lost. A way to look at this which I like more and more: people can still do `bad' things with code under the BSD licence, like extend it and not give back their changes. They are free to do so. The BSD licence does not steal your freedom to make ethical choices about code. On the other hand, the GPL makes half of the ethical choice for you: you want to use the code, you have to give back. The only way not to give back is to not use the code (or, well, you can make a bigger ethical choice of using the code and lying about it).
Re: Is NV supposed to be SLOW?
On Sun, May 04, 2008 at 10:16:54AM -0500, Marco Peereboom wrote: My previous laptop was radeonhd and I might go back to it until noveau is in enough shape. Only after coming from radeonhd to go nvidia made me realize how much better the driver is. Almost the same, except that my old laptop video card died. I'm still hoping for nouveau to happen, hopefully, just so that we can fuck the nvidia morons (like, even if they don't open their specs, someone can reverse engineer a driver), and also because that laptop is very nice outside of that gfx card issue.
Re: Apache suexec problem
I've looked a bit at suexec, trying to make it go saner. I still cringe. The model is intrinsically broken, for a lot of reasons. I don't think it's feasible to fix suexec for real. You've got to realize that suexec basically *elevates* a process to root, making its decision on its name and various fishy tests. I don't see how this can be made safe.
Re: Screen,colorls,xterms issue. 4.2
On Sun, May 11, 2008 at 07:45:06AM +0200, Jesus Sanchez wrote: Girish Venkatachalam escribis: On 22:20:18 May 10, Jesus Sanchez wrote: Hi, I'm using OpenBSD 4.2, a clean install. I have experienced some problems using screen and X with colorsls. The issue is that when I launch 'screen' on virtual terminals (C0,C1...) I don't have any problem but when launch X, on the xterm/rxvt I have open I can't launch a screen because the colors goes mad and shows white on black combinations I have not set on my rxvt (I use some grey tones combinations). I have set an alias for ls='colorls -GF' (color output) and this causes the problems on a screen session. I have set the TERM=xterm-color on my /etc/profile. As Stuart pointed out you should not do this. I used to experience hell since I used to make the same mistake. ;) Later life got simple after doing a code walk through of screen's source and figured that the problem is fixed by setting $ export TERM=rxvt ;) Funny we arrive at simple solutions through circuitous routes. ;) -Girish I tried to set the TERM variable to rxvt value export TERM=rxvt on the /etc/profile and I have problems with the virtual terminals now. (the ones invoked by Ctrl+Alt+F1 to F4). I get weird color when doing colorls -G in screen session, so your solution it's not valid to me, but thanks for the info. Don't do that. You really need to learn a bit more of Unix before you start making changes in system-wide files. Unix administration is relatively easy, but this is still stuff you need to learn. Putting personal choices in system-wide files is a really bad habit, even if you are on your personal machine. Especially when your personal choices are bogus in the first place. Sooner or later, you'll manage to break the machine config, and then you'll figure out you can no longer login normally, and end up needing to take down the machine violently. With luck, fsck and single-user will get you out. With no luck, fsck will fail and you will have to reinstall partly. Stuart explained this specific case in a sibling message. TERM only reflects your current terminal. There is no way you can put settings that work for everything, you have to use some kind of judo. Specifically, don't change TERM yourself, convince your subsystems to set it correctly for you, either through the use of /etc/ttys for the console, or through the use of resources for X windows emulators. Do this carefully: first test manually on a specific session, then do the changes in *your* config files, and then decide whether you really want to do this on a system basis. In the end, you'll end up with a sane configuration at the system level, and your personal config files set up carefully. A big advantage of doing this on your config files is that, over the years, you'll end up with a configuration you can transport from machine to machine as you gain user accounts on other people's machines, where you usually cannot change system-wide files...
Re: Debian libssl security (OpenSSH safe?)
On Tue, May 13, 2008 at 11:14:59AM -0500, Sean Malloy wrote: On Tue, May 13, 2008 at 11:37:38AM -0400, Juan Miscaro wrote: I guess everyone by now has heard about the very serious libssl vulnerability on Debian/Ubuntu? Just making sure that the source is safe, thanks. /juan Here is a quote from the official Debian Security announcement, DSA-1571 http://www.debian.org/security/2008/dsa-1571. This is a Debian-specific vulnerability which does not affect other operating systems which are not based on Debian. However, other systems can be indirectly affected if weak keys are imported into them. More details show that someone seriously fucked up in debian. Trusting automated reporting tools like valgrind is fairly dangerous. I'm saddened that people still don't learn. `but this is a serious security warning. This MUST be fixed, valgrind canNOT be wrong.' duh... well, it can, like every tool out there that understands the source only so far... better than some humans, granted, but hopefully not better (yet) than the people who write serious software...
Re: Debian libssl security (OpenSSH safe?)
On Tue, May 13, 2008 at 09:41:00PM +0400, B A wrote: Can't find relation between bug in openssl deb package and valgring. There is no such info in the original link as I see (DSA-1571-1). Cold you be more specific and informative? Thank you. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516
Re: updating ports after OS update
On Fri, May 16, 2008 at 04:19:12AM +0200, Robert Urban wrote: # pkg_add -ui -F update -F updatedepends What do I need to do about the numerous ports I built and installed? Do they need to be updated manually? The packages you built manually, assuming you used a virgin ports tree, are no different from the distributed packages. You can update safely from our tree. Things may fail if you run into a package that's not distributed (java comes to mind), but it will fail decently, and you can update the required packages manually, then proceed with update. You can also set FETCH_PACKAGES to Yes and update using the ports tree. Or even add a SRC: element to your PKG_PATH as a fallback. Also, I'm currently running 4.1, and would like to get to 4.3. I guess I will need to do this in two hops. Can I postpone package updating until I've finished updating the OS to 4.3? You can skip one release, the ports tree tools can deal with old stuff without any issue.
Re: SRC in PKG_PATH ( was Re: updating ports after OS update )
On Fri, May 16, 2008 at 11:47:09AM -0700, Ben Calvert wrote: On May 16, 2008, at 12:34 AM, Marc Espie wrote: Or even add a SRC: element to your PKG_PATH as a fallback. Marc - where is this documented? i can't find it in pkg_add, package, or friends. It was finished fairly recently, and it's not 100% tested yet: - it requires some cooperation between the ports tree and pkg_add: if you run the ports tree from pkg_add, it means you already have a lock on /var/db/pkg, so it requires -F nolock. - it's also one of the reasons for stopping at the first PKG_PATH entry that satisfies your request. SRC urls are a `last resort', when you can't find the package and need to build it. If you want to play with it, you can try adding an entry like: src:/usr/ports/ at the end of your PKG_PATH (for instance: PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/i386/:src:/usr/ports/ and it will build locally whatever it doesn't find on the ftp site... Note that this needs to disable FETCH_PACKAGES, so in some cases, it will build more stuff than is available (if it needs to build something, and it discovers some dependencies are missing, it will build them as well). In many cases, setting FETCH_PACKAGES=Yes is a simpler way to achieve similar results. src: urls will mostly be useful for pkg_add -u.
Re: Why Perl for pkg_* tools ?
On Thu, May 22, 2008 at 03:23:17PM +, hyjial wrote: Hi list ! Reading through OpenBSD's codebase, I have noticed that the code living under src/usr.sbin/pkg_add is written in Perl. Perl is distributed under the Artistic license, though. The latter is not as permissive as the BSD license under which monst of OpenBSD is released. No doubt that is the reason why Perl lives in src/gnu. Well, perl lives in src/gnu by mistake, since it has little to do with gnu, but moving it would not help anything, since it would add lots of noise to the CVS repository. Actually, we don't frown all that much on the Artistic licence. It is very much free compared to the obnoxious GPL. If you read it carefully, the only thing the Artistic licence requires you to do is not to misrepresent the software, by changing it without renaming it. As far as perl goes, it's about the only language that fit the bill. The older pkg_* were totally impossible to maintain and extend, and I needed a sensible script language that was in base.
Re: Why Perl for pkg_* tools ?
On Fri, May 23, 2008 at 01:42:05PM +0200, Almir Karic wrote: On Fri, May 23, 2008 at 9:37 AM, Marc Espie [EMAIL PROTECTED] wrote: As far as perl goes, it's about the only language that fit the bill. The older pkg_* were totally impossible to maintain and extend, and I needed a sensible script language that was in base. at the risk of starting a flame war, considered python? beside not being in the base, any other downsides for this particular task? There's no real fundamental difference between python and perl, especially for this kind of job. Some people prefer python, say it's cleaner. Frankly, I don't care. I haven't yet met a task that python could tackle and python could not. Perl is in base, and I'm used to working with it. Those are pretty big advantages. The only potential drawback to perl was speed... since the rewritten pkg_* turned out to be *faster* than their older C counterpart, that was not a viable argument. The only other viable choice would have been C++. But needing to compile that stuff, having a somewhat less stable toolchain, plus the frank dislike of some OpenBSD people wrt C++ made that a non-issue. I've spent quite some time thinking about the language before I embarked on the perl pkg_* adventures. I've never regretted that choice, the tools turned out to do even more than I hoped for, and I've never run into any perl-related issue.
Re: Why Perl for pkg_* tools ?
On Fri, May 23, 2008 at 07:16:03AM -0600, Diana Eichert wrote: On Fri, 23 May 2008, Marc Balmer wrote: or maybe I should write my next radio clock driver in forth, I heard it is fast and small, so I am sure it is the right tool for drivers...) YES! Marc if you put forth in base and started writing all your drivers in forth I'd buy you some fondue. Or at least integrate forth in the boot loader. ;-) diana forth, it does the body good. Tsk, tsk, tsk. Kids. Stop trolling. Or at least make it less obvious.
Re: Why Perl for pkg_* tools ?
On Fri, May 23, 2008 at 08:20:50PM -0400, Hugo Villeneuve wrote: perl offers faster software development. perl is not fast. Just saying. Althought, I think that's what you meant too. # sysctl hw.model hw.physmem hw.model=SUNW,SPARCclassic, TMS390S10 @ 50 MHz, on-chip FPU hw.physmem=24801280 # time pkg_info gettext-0.16.1 GNU gettext libiconv-1.9.2p5character set conversion library lrzsz-0.12.20p0 receive/send files via X/Y/ZMODEM protocol mutt-1.4.2.3tty-based e-mail client stunnel-4.20SSL encryption wrapper for standard network daemons uucp-1.07p2 UUCP suite 0m22.57s real 0m13.05s user 0m6.44s system 22 seconds to list one folder and open 6 files :) I doubt it took 1 seconds before the move to perl on that computer. You're partly confusing start-up time and speed. In less trivial tasks than pkg_info, for instance actual use of pkg_add, the new tools are faster. Most run-times are dominated by IO. The old tools were using external tar(1) to a temporary area, then copying over to the final destination. That makes for double IO, and thus very slow. Replacing that in the old tools would not have been feasible. Likewise, the new tools do not spend all their time re-discovering the world. If you pkg_add *.tgz, you run one instance of pkg_add which keeps every info it needs in memory (and I spent some time specifically improving that so that, even with all the checks being done, pkg_add can handle 1000s of packages before overflowing 64M). pkg_info time was similarly improved when we finally merged +COMMENT into +CONTENT, so that less files got opened and read. pkg_info on an installation with few packages installed is the odd case where it is noticeably slower. Seriously, the advantages far outweigh the problem. It's been my experience that a language such as perl allows you to deploy much faster algorithms in the same amount of time it will take to code the same problem in C. The rapid application development facilities by themselves are tremendous. It's ways simpler to tune things so that they run circle around their C counterparts. Happened with pkg_add, happened with makewhatis. And I ran the benches to check it. Of course you won't be able to run old pkg_* with our new pkg tools, the new ones do so much more. But on sheer pkg extraction, the new tools win by a factor or 2.
Re: [OT] Python License [WAS: Re: Why Perl for pkg_* tools ?]
On Sat, May 24, 2008 at 06:23:23PM +0200, Martin Marcher wrote: Hello, How about the python license? Not that I'm really capable of rewriting and/or patching the pkg_* tools but from a license point of view I think that the license under which python is distributed is quite similiar to a BSD license. Especiall this: So is Perl's artistic licence. gnu/ is a historic accident. It's actually a shorthand for `not bsd' in our tree. Read the Artistic licence, there's nothing that conflicts with the overall goals of OpenBSD. Technically, the Artistic Licence gives you the same rights as a BSD licence. The only thing it prevents you to do is to misrepresent the original software: if you change it, you have to display it prominently, and you can't use the exact same name. Wooo, big infringement on your liberty. Now, compare to the obnoxious GPLv2, or the even more stinky GPLv3. Not the same ballpark. It's a bit like comparing Jimmy Carter to Adolf Hitler. So, let's invoke Godwin's law and close that useless discussion.
Re: Why Perl for pkg_* tools ?
A final word. For all you backseat drivers: this is OpenBSD. Those who do the work get to call the shots. I did get permission from my fellow developers to switch our pkg_* to perl once I made a strong enough argument. A huge part of the argument was the actual code. I did write tools that work. I did write an infrastructure that still grows, stays coherent, and is still fairly easy to manage. These pkg_* are the first in the BSD world to actually support safe updates, without needing to back up most of your system first. Everything-in-perl was a deliberate design decision. What do you think ? that we grow code in a vat with eyes closed ? I've looked very closely at the neighbors, and at our distant cousins. The neighbors manage to live on a weird mix of awk/ruby/perl/python/sh/C. From a distance, it looks like everyone in NetBSD/FreeBSD has their own favorite language, and is happy to reinvent a square wheel to handle packages in their own language. Well, my tools were written specifically to squash that, to give people a cool enough interface that they would not need to reinvent the world. You prefer python ? tough cookies. Perl and python are more or less equivalent. If you know one, you can write code in the other. Or you're less elite than you think (as a sidenote, I loathe php, yet I run a drupal site, and I have written numerous patches for drupal). The only important difference, for me, was that perl comes with the base install in OpenBSD. And we made a conscious decision to keep it so. That gives us *one* decent high-level script language. OS and distributions are all about editorial choices. Some have given up, and let the user wadle through hundreds of inane choice and a bazaar of half-finished toys. OpenBSD takes some strong stances. We wanted pkg_* that work, we got them. You don't like that they're in perl ? you can always go elsewhere, or, if you have some real balls, write something better in whatever language you want. Have fun, good luck.
Re: small, random essay on performance tuning, was: remove....
On Fri, Jun 06, 2008 at 07:59:31PM -0700, Peter Hessler wrote: Removing device drivers may speed the boot process on your system, but can complicate recovery should you have a hardware problem, and is very often done wrong. Removing device drivers iwill not/i make your system run faster by any noticeable amount, though can produce a smaller kernel. Removing debugging and error checking can result in a measurable performance gain, but will make it impossible to troubleshoot a system if something goes wrong. You almost never need to remove device drivers from the kernel, since you can use boot -c and config -c to temporarily disable them, without needing to recompile anything.
Re: pkg_add errors
On Wed, Jun 11, 2008 at 10:22:17AM -0500, c l wrote: Anyone else get this message when doing pkg_add's from ftp sites? 421 There are too many connections from your internet address I get this on all my openbsd boxes, 4.3 and -current from June 10, 2008. All of them are behind either a cisco pix or 4.3 -release firewall. It seems to happen with just about any package that has a few dependencies. Looks like you have some proxying mechanism which fucks up. It definitely appears that your ftp client is not terminating client properly, something eats the connection termination. As said, if you are behind a nat, you should definitely make sure you have ftp proxying running, so that the connections are tracked correctly. Otherwise, use an http mirror, it doesn't have this shortcoming.
Re: pkg_add errors
On Thu, Jun 12, 2008 at 03:23:29AM +, Stuart Henderson wrote: On 2008-06-11, Marc Espie [EMAIL PROTECTED] wrote: On Wed, Jun 11, 2008 at 10:22:17AM -0500, c l wrote: Anyone else get this message when doing pkg_add's from ftp sites? 421 There are too many connections from your internet address I get this on all my openbsd boxes, 4.3 and -current from June 10, 2008. All of them are behind either a cisco pix or 4.3 -release firewall. It seems to happen with just about any package that has a few dependencies. Looks like you have some proxying mechanism which fucks up. It definitely appears that your ftp client is not terminating client properly, something eats the connection termination. This happens with some mirrors from time to time.. definitely seen it on belnet befrore, maybe some others. As I said before, but it's worth repeating. pkg_add *relies* on being able to interrupt ftp transfers in the middle. That's a part of the telnet layer of ftp. Namely, there's some sequence you can send on the connection that will abort the connection cleanly, on both sides. From pkg_add's point of view, there will be only one active ftp connection to a given ftp server, there's some code that's very careful doing that. Of course, if there's some lousy network equipment in the middle, there can be *stuck* ftp connections. The other part of the problem is the data/control nature of ftp. Stupide aggressive nats will tend to drop the control connection after a while, because it's inactive, even though there is data going through the data connection. We fixed this one for real when we started sending NOP over inactive control connections to prevent that (ftp-level `keep-alive' kind-of). Ftp is a fine protocol, modern network equipment is dumb. There's not much you can do, except switch to a more stupid protocol, like http, which is perfectly adapted to a world of dumb networks and dumb users.
Re: Typo in pkg_delete output message?
On Thu, Jun 12, 2008 at 08:09:56AM -0500, Aaron Poffenberger wrote: I tried to delete a partial package by typing `pkg_delete partial-xulrunner-1.8.1.13`. Apparently it wasn't fully installed and I received the following output message: /bin/sh: xulrunner: not foundading plist I'm guessing that should be not founding plist or perhaps plist not found or something similar. Nope, it's xulrunner's message overriding the current progress display, namely: partial-xulrunner-1.8.1.3: reading plist
Re: Get rid of windows limit in 'window'?
On Sat, Jun 14, 2008 at 06:18:31PM -0700, F. Caulier wrote: I just discovered 'window' in base, a very usefull tool! I was used to install 'screen' to get a terminal multiplexer but as I found 'window' which gives me multiplexing without 'screen's' bloat and restrictive license. I still don't understand the current craze about window, since it doesn't have the one killer feature of screen, namely the ability to attach/detach sessions at will... I mean, probably like a lot of people, my main use of screen is to have interactive sessions I can keep around from login to login, or around a flaky network connection. Nothing as unpleasant as having a build fail just because your network timed out and make got SIGHUP'ed.
Re: OT: Dissertation ideas for my degree
On Thu, Jun 19, 2008 at 12:48:08PM +0100, Edd Barrett wrote: Lars NoodC)n wrote: Edd Barrett wrote: I would love a decent network filesystem, but its probably too much work for an undergrad project. Its more like a PHD. What's missing from OpenAFS? Or do you mean hammering out lumps in NFS 3/NFS 4 ? I use NFSv3 because its simple, but I hate it because of the security issues. If AFS were simpler perhaps. I think solaris has secure rpc, thus crypted NFS but it's a nasty can of worms.
Re: Failing to install packages with $PKG_PATH
On Mon, Jun 23, 2008 at 10:34:33PM +, Jacob Meuser wrote: On Mon, Jun 23, 2008 at 06:56:00PM -0300, Daniel B. wrote: Hi, I've updated to the today -current and I can't install packages as I usually do. # export PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/i386 man pkg_add ... Since a few URL schemes contain colons, pkg_add relies on each directory ending in a / ... Paradoxically, that's me trying to relax that limitation. I've changed the code that reads PKG_PATH from separating things on /:, then parsing each path independently, to having the url parser interpret the whole string, and figure out by itself where to cut things. Along the process, the version in snapshots is the one where the url parser does insist on the terminating /. The further change I committed yesterday does much finer url parsing, so that in many cases, the / requirement at end should be dropped: new pkg_add will parse PKG_PATH like a human would, and figure out which : are parts of urls, and which : are separators between urls...
Re: getpwnam_r() missing on OpenBSD 4.3
On Fri, Jun 27, 2008 at 05:23:54PM -0400, (private) HKS wrote: Not sure if this is the right list for this question, so let me know if it needs to go somewhere else. My OpenBSD box is missing the getpwnam_r() function described in the getpwent(3) man page. At least, it's described at this URL: http://www.openbsd.org/cgi-bin/man.cgi?query=getpwnamapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html ^^^ Have a closer look at that url. ;-)
Re: getpwnam_r() missing on OpenBSD 4.3
On Tue, Jul 01, 2008 at 11:04:21AM -0400, (private) HKS wrote: Let's hear it for my attention to detail. Does anybody happen to have a creative workaround for threaded applications requesting this call? I'm experimenting with changing the call to getpwnam(), but that's out of morbid curiosity rather than a real fix. Use current, that will also help the project, since we're happy to have more people testing stuff.
Re: getpwnam_r() missing on OpenBSD 4.3
On Wed, Jul 02, 2008 at 02:42:35PM -0400, (private) HKS wrote: Backporting this is beyond my meager C abilities (and time to learn, at the moment). Considering where the getpwnam_r comes from, backporting it would be more or less equivalent to running -current anyways, since getpwnam_r comes as a *minor* side-effect of a HUGE revamp of the related lookup code.
Re: pkg_add not terminating
On Sat, Jul 12, 2008 at 07:32:07PM +1200, Richard Toohey wrote: On 12/07/2008, at 12:31 PM, Daniel Ouellet wrote: Ivo van der Sangen wrote: When trying to install texlive_texmf-minimal-2007p2.tgz I run into problems. The pkg_add script does not terminate. The progress bar stops at 100% and there are still 3 processes running: perl, ftp and gzip. It happen sometime when dependency are install. The FTP hang as it doesn't close the connection properly. Just look the process and kill ONLY the ftp one when it's at 100% and do not close by itself. This will allow the rest of the regular pkg_add to continue as usual. Then the install process will continue as normal and get the next dependency if any as nothing unusual happened. Not a big deal when you know. Hope this help you. Best, Daniel If it is FTP (and these are the symptoms I've seen when it has been an FTP issue) then ... My experience is that your FTP *control* channel is timed out, because the FTP takes over a certain time (e.g. 10 minutes.) Your FTP *data* channel is busy, but dumb firewalls (usually M$ in my experience) see nothing happening on the control channel, and kill it. The data channel finishes the transfer, but your control channel has gone ... so hang ... It's OpenBSD, so use the excellent docs ... http://www.openbsd.org/cgi-bin/man.cgi?query=pkg_addapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html Near the bottom ... FTP_KEEPALIVE Have ftp(1) send a byte after every FTP_KEEPALIVE seconds, so that incorrectly configured network equipment won't ag- gressively drop it. See ``ftp -k'' for more information. This will keep the control channel alive, so when the data channel is finished, the control channel is still alive bad things don't happen. Thanks. In fact, this has been turned on by default after 4.3, so in current this should no longer be an issue at all. I'm going to remove the button from pkg_add soon, this does remind me to do it...
Re: scripting port install driving me mad
On Sat, Jul 12, 2008 at 03:11:18PM -0400, Juan Miscaro wrote: Hi, I have a script that I use to automate server installations. Every time I come to the point of installing a port with a certain flavor: postfix with sasl2/mysql I can never get it to work. I thought I had it working before by putting in the Makefile: FLAVORS= sasl2 mysql but this is ignored. Putting the following in the script also barfs: env FLAVOR=sasl2 mysql What am I missing? /juan No idea, since you're not giving your actual script. cd /usr/ports SUBDIR=mail/postfix/stable,sasl2,mysql SUDO=sudo make install BULK=Yes should more or less work.
Re: scripting port install driving me mad
On Sat, Jul 12, 2008 at 08:38:18PM +, Jacob Meuser wrote: On Sat, Jul 12, 2008 at 03:11:18PM -0400, Juan Miscaro wrote: Hi, I have a script that I use to automate server installations. Every time I come to the point of installing a port with a certain flavor: postfix with sasl2/mysql I can never get it to work. I thought I had it working before by putting in the Makefile: FLAVORS= sasl2 mysql but this is ignored. Putting the following in the script also barfs: env FLAVOR=sasl2 mysql What am I missing? instead of manually setting FLAVOR in your script (btw, FLAVORS is just a list of available FLAVORs, not what FLAVORs will be built) or mucking about in the ports Makefiles, you probably want to use SUBDIRLIST from the top of the ports directory. for example: $ echo 'mail/postfix/stable,sasl2,mysql' /tmp/build-list $ echo 'another/port' /tmp/build-list $ echo 'one/more,flavored' /tmp/build-list $ echo 'still/another,-subpackage' /tmp/build-list $ cd /usr/ports $ BULK=Yes FETCH_PACKAGES=Yes SUBDIRLIST=/tmp/build-list make install see bsd.port.mk(5) and packages-specs(7) for more info. btw, you can generate a SUBDIRLIST from all installed packages: $ pkg_info -fa | sed -ne 's/[EMAIL PROTECTED] subdir=\([^ ]*\) .*/\1/p' build-list although, there is probably a better way to do this with perl. Duh moment. Jacob, you should rtfm from time to time, you'd discover that pkg_info has a -P option, that yields precisely the pkgpath info... ;-) This is going to be *ways* faster than building the full list of all packing-lists (and no, pkg_info doesn't just display the file, it reads the file, parses it, builds internal structures and pretty-prints the result, which is interesting for several reasons, chief among them that it will tell you if a packing-list is bogus).
Re: 'Nother broken package - git-1.5.4.2
On Tue, Jul 15, 2008 at 04:52:16PM -0400, Nick Guenther wrote: On Tue, Jul 15, 2008 at 4:28 PM, Will Maier [EMAIL PROTECTED] wrote: On Tue, Jul 15, 2008 at 02:30:36PM -0500, L. V. Lammert wrote: Depends on tcl-8.4.7p6, .. maybe, .. but what does X have to do with git?? http://en.wikipedia.org/wiki/Tk_%28framework%29 Can't install tk-8.4.7p1: lib not found X11.11.1 Is this a broken dependency No. It's because of gitk which is a repository browser (or so http://git.or.cz/course/svn.html tells me). Annoying that there's no git-no_x11 but them's the breaks. Makes no sense. It's clearly a multi-package situation, not flavor.
Re: 'Nother broken package - git-1.5.4.2
On Wed, Jul 16, 2008 at 09:30:02AM -0500, L. V. Lammert wrote: If a command line tool like git has a 'GUI Helper', then that package is broken (which, I believe, is the case in this situation). You don't get it, so I'll explain it. There are a lot of packages in OpenBSD. We can spend time providing stupid options like manually removing X, and then spend more time testing, and testing again. Each flavor you add has a cost: more tests. Either they're not done, and then stuff breaks (because untested packages don't work, murphy's law), or it detracts from more useful stuff. Moving some X11 stuff to subpackages makes sense. Creating some no_x11 stuff, *very* occasionally, makes sense. Most of the time, it's a wast of time. It makes for more complicated dependency trees, build errors, packaging errors, runtime errors. We'd rather spend time doing valuable things. You can very well install X on a production server. You don't have to run it. If you're afraid it's going to hole your precious machine, just remove the setuid binaries, it's darn simple, and it won't affect package dependencies. If you don't like the current situation, go run something else. We have enough stuff to do already, we're not into adding knobs just because it's neater. There are huge amounts of useful modifications to do that are ways more important than creating no_x11 flavors (and testing them).
Re: This is what Linus Torvalds calls openBSD crowd
On Wed, Jul 16, 2008 at 07:47:54PM +0100, Nuno Magalhces wrote: Eheh he's right :-) If you guys get your heads out of your asses and actually read his words with the use of some common sense you might get what he means. It's a balanced opinion. It's a totally misinformed opinion. Quoting In fact, all the boring normal bugs are _way_ more important, just because there's a lot more of them. I don't think some spectacular security hole should be glorified or cared about as being any more special than a random spectacular crash due to bad locking. which is exactly what people in the OpenBSD project do, all the time (fix normal bugs). That's the proactive approach to security: don't wait until you have an exploit, just fix the darn bug. So, when he tries to say that the OpenBSD crowd has a different attitude, I don't know who he's referring to, but certainly not me. I don't think you have any idea how hard we're laughing right now. It's just so out of touch with how we see things, it's beyond pathetic. As you can see, my fellow developpers took it about the same way, but with even more sarcasm... we don't give a fuck about security for security's sake: free, FUNCTIONAL, secure. choose all three. Says so on the T-shirt.
Re: Trying to compile cwm on Linux
On Thu, Jul 24, 2008 at 10:01:50PM +0200, Martin Toft wrote: +#define strlcpy(dst, src, size) (strncpy((dst), (src), (size) - 1)) +#define strlcat(dst, src, size) (strncat((dst), (src), (size) - 1)) To be a bit more specific than Theo, don't believe idiots like Ulrich Drepper. There's a *reason* for strlcpy and strlcat. strncpy and strncat are bogus. They're almost never the solution. Accept no substitute. On any lesser system (and that's mostly linux these days), you must ship a copy of strlcat and strlcpy. Fortunately the source code for these is small! And it's free! nice licence! no obnoxious GPL!
Re: make ls not show dot-files as root
On Tue, Jul 29, 2008 at 12:33:54AM +0200, Jesus Sanchez wrote: Hi, using 4.2. Just for curiosity... Can I make ls to NOT show the hidden files (.xinitrc , .vimrc, etc) when using as Root?? Thanks 4 all. Why is this a problem ? When you're root, you really want to see all the files. If you see this as inconvenient, this is because you're misusing the root account, most likely doing your normal work as root. THIS IS A HUGE MISTAKE. Create a user account, use it. You have nice tools like sudo to become root when you need it. If you do everything as root, sooner or later, you will fuck up. We have this old saying. There are two kinds of sysadmins: those who have already done one big mistake (and learnt from it) and those who haven't YET.
Re: Not updating .libs1-gettext-0.16.1, remember to clean it
You know, if you go on like that, you're going to end up in my killfile, and a lot of other people as well.
Re: Is there a non-X11 version of Prolog available?
On Fri, Aug 29, 2008 at 03:48:54PM +0100, Simon Connah wrote: I've just been trying to install the SWI-Prolog port and it seems like it needs X11 installed to run. Is there a command line version of Prolog floating around at all? Or do I need to compile and install my own copy? swi-prolog works as a command-line version. You need to have X11 libraries around, but it's perfectly happy running from the command-line, without any X server around. Thanks for the tip. I'm just a bit concerned about the broken part on that site apparently caused by randomised mmap(). Any idea if this is a major concern or just something that can be safely ignored? This is a major concern. This means it won't work reliably... sometimes, your binary will get loaded at an address which interferes with your static mmap'ed image, and it will just fail, and you will have to restart the prolog interpreter for it to work, eventually... with a big enough image, it's likely it will get really hard to make things work...
Re: Stop in line 73 of Makefile
On Sun, Sep 07, 2008 at 08:52:54PM -0700, Doug Milam wrote: Thanks; I had never set or changed any flags until a few days ago, in trying to 'fix' this issue. Perhaps someone compromised the system via FTP (ftpd was running only anonymously), or via HTTP. * * Sorry to be harsh, but it's most likely to be your own fuck-up. Most people with strangely behaving systems usually have done something wrong, like running a too old kernel with old binaries, or having something out of synch. Jumping to conclusions and blaming unknown pirates is ways simpler than looking for the fault in yourself...
Re: Stop in line 73 of Makefile
On Mon, Sep 08, 2008 at 07:58:54AM -0700, Doug Milam wrote: Anything I can do short of re-installing from a CD? I was able to rebuild the kernel successfully... Make sure you strip any special parameter from each directory and file you have... Depending how much work you did, it may be simpler to just reinstall...
Re: autoconf error message suggestion
Okay, guys, kill it. The main issue I have with Karel is that he lacks basic tact. But saying metaauto lacks some documentation is not necessarily wrong. However, since he's already written opensource software, maybe he could contribute ? I wouldn't object to a set of manpages for metaauto. I won't necessarily have time to write it myself, obviously.
Re: OT: TinyMCE security and track records
On Thu, Dec 21, 2006 at 03:02:11PM -0500, Daniel Ouellet wrote: Sorry for this off topic question, but I get more and more requests to have WYSIWYG editing on web management servers. I have been resisting this for many years so far as I hate this, but look likes more and more demands may force me to do it anyway. Any valid feedback on the security and stability of this one on OpenBSD, or any other prefer. I am looking more for security and stability oppose to bell and whistle and features. The archive point me only this one post of TinyMCE: http://marc.theaimsgroup.com/?l=openbsd-miscm=113468845728612w=2 Any feedback and/or suggestions would be greatly appreciated if any. Don't know if konqueror or TinyMCE is deficient, but they don't play together... As far as WYSIWYG editing goes, the main problem with TinyMCE is a design issue: what you see is all that you get. When was the last time you had a website that was actual static html ? you're going to get lots of banner material, and a big part of the site is going to be generated with template stuff... or if you want a nice look, you're pretty much going to want your own classes and stuff like that. TinyMCE is cute, but it's pretty much designed to handle `old-style' HTML. If you use it to create big chunks of web sites, you're soon going to end up with some hand-coded mess. As far as grabbing and sanitizing the resulting html, there are tools out there that can do that. My perl background prompts you to recommend HTML::Tree, which creates a proper parsed tree from an HTML document, and allows you to clean it up. So my assessment is that this kind of tool is pretty much limited if you actually want good-looking sites... no actual security problem per se (not more than usual form-based editors, at least on the server side). I think that, to go further, you need actual development tools that you can customize to the level of your website code. I assume eclipse will have this kind of plugin. The kde webdev suite is definitely a nice candidate there, though I haven't tried to customize it to get WYSIWYG editing of my Mason/Catalyst code...
Re: dylan language
On Fri, Dec 22, 2006 at 11:42:44AM -0800, Joe wrote: Is this for real? I figured if anyone could shed some light on this, an OpenBSD developer might be able to comment on this dylan language. I'm not looking to learn dylan, but am just wondering if this is legit. I wouldn't mind running one of these tools if they are indeed safer to run than wireshark. (yes i use tcpdump regularly) I have the beginning of a port of gwydiondylan, there are still a lot of issues to fix. The byte-code compiler (mindy) is slow as hell, d2c doesn't quite work for me yet. Outside of that, dylan-binary does not work on a range of architectures. Dylan reminds me of haskell. Both are high-level languages, better than sliced bread, and *everything* you want to build with them involves compilation speeds that make g++ look like it's the fastest thing out there...
Re: Spamassassin segfaults
On Thu, Dec 28, 2006 at 11:30:27AM +0100, Karel Kulhavy wrote: When I clear the stale lock and re-run it, then it segfaults again. Are you familiar with this problem? I will try yet erasing the .spamassassin directory (no idea how to erase the db without corrupting the contents of .spamassassin) and then retrain. What I also don't like is that SA is very slow. I don't believe Bayesian statistics are so computationally expensive. Can you recommend a different tool than spamassassin? I wonder what CRM114 is http://crm114.sourceforge.net/ I don't use spamassassin for its bayesian filters. I have a combo spamassassin + bogofilter, where spamassassin only sees the stuff when bogofilter cannot classify it.
Re: OT Was: Wanted: OpenBSD Systems Administrator
For once, I'm going to say this from my position as an OpenBSD developer who has sunk countless hours into writing code for this OS. It's obvious a lot of wankers around here have nothing better to do than start threads based on that job offer. I am perfectly happy with someone posting a job offer directly related to OpenBSD on [EMAIL PROTECTED] If we ever become mainstream and this list gets swamped with thousands of job offers each week, this will become a problem. But for now ? Shesh! This is legitimate email. People who don't think so are totally disconnected from reality. Let me remind the wankers that *a lot* of people who work on developping OpenBSD are no longer students, and are taking the development time from their copious free time, or making use of understanding bosses... So, thanks for the offer, sorry for the incredible reaction from the jerks' section, and please come again...
Re: Is Theo still hiking ????
On Sun, Jan 28, 2007 at 03:17:14PM +, Jeroen Massar wrote: Also note that FT serves the whole country of France, you might not like them, but they also have a right to use the Internet ;) Most ISP's get only a /32 and there are millions of those. Getting a /19 is really something that only a few ISP's will be able to claim that they will actually be able to get customers for. Bullshit. We've had deregulation for a while now, and FT is just the historical operator. There's no reason to treat them differently than other ISPs. Them getting a whole hefty chunk of address space looks like some political game on their part to try and keep their position, for which they have no actual right these days. Wouldn't be the first time they try to rig the game.
Re: perl webapp and threads
Basically, you're out of luck for now. Tough problem.
