Re: new: shells/perlsh 1.8
On Wed, 28 Sep 2005 17:46:36 +0200 Jasper Lievisse Adriaanse [EMAIL PROTECTED] wrote: snip i get this error upon installing the package Couldn't find subject in old manpage /usr/local/man/man3p/Psh::StrategyBunch.3p Unknown manpage type /usr/local/man/man3p/Psh::StrategyBunch.3p I noticed, that too. But I just can't seem to find the source of that error. Does anybody have a clue? Well, it's finally fixed. Thanks to the help of alek@, jmc@ and [EMAIL PROTECTED] The updated tarball containing the port, which is working on i386, alpha and sparc64, is at http://nedbsd.nl/~jasper/obsd/ports/perlsh.tar.gz Jasper snip -- Security is decided by quality -- Theo de Raadt
Re: installing gmake
* Chuck Robey [2005-10-07]: OpenBSD complained vociferously about pre-existing files for those two (they did pre-exist) and I didn't know how to tell the system to accept what I gifted it. I sure wish there was some way to tell the system that it doesn't need to be the sole and only source of all software. The ports tree is the only source of all software, that exists as a port *and* is needed by another port. This will never change (for some sensible value of 'never' ;). If you have software that is not ported *or* which no other port depends on, there is no problem installing that on your own, of course. I really think you ought to consider allowing folks to be able to loosen up on the so strict ports control of files. It's (if this continues like this) going to force me away from all use of ports, if it's won;t let me do anything of my own. You clearly don't understand the issues involved. What is the problem with installing ports/packages? Nikolay
ImageMagick/PerlMagick issues with large files?
Greetings,
I am finally getting around to putting up some of my vacation
images up on a web-site and wanted to use {Image,Perl}Magick
to process them (Scale, Rotate, etc) before putting them up.
I noticed that after calling $img-Rotate(degrees=-90.0) (for
example) the process would seem to hang and system load would
jump up.
I thought maybe something is wrong with PerlMagick and so I
attempted using:
% convert image.jpg -rotate -90.0 rotated_image.jpg
But that does the same thing. Seems to hang and system load
goes up (~2.23 right now).
A resized version of the source image works fine. So I'm
wondering if I am running into some memory limitations?
I used ktrace -p PID and after the ktrace.out file grew to
about 7+MB I stopped it and used kdump to see what I can
gather. Not much besides a whole lot of:
...
PID convert RET pwrite 8
PID convert CALL pwrite(0x3,0x3c3d1520,0x8,0,0x2ec528,0)
PID convert GIO fd 3 wrote 8 bytes
$$55,,\0\0
...
So, is there any known performance issues with pwrite and
large files? or is there something else wrong?
The source image (jpg) file size is about 3.5MB (it is
from an 8.3MP camera).
I should point out that opening up the same image using
xv and rotating it, or scaling it, works as desired.
Should I post this to misc@ or is it in the proper mailing
list?
Thanks for any info,
--patrick
dmesg:
OpenBSD 3.7-stable (GENERIC) #0: Mon Aug 1 19:32:49 PDT 2005
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Sempron(tm) Processor 2600+ (AuthenticAMD 686-class) 1.61 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2
real mem = 536387584 (523816K)
avail mem = 482521088 (471212K)
using 4278 buffers containing 26923008 bytes (26292K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(6b) BIOS, date 04/08/05, BIOS32 rev. 0 @ 0xfa120
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
pcibios0 at bios0: rev 2.1 @ 0xf/0xc4b4
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfc380/288 (16 entries)
pcibios0: bad IRQ table checksum
pcibios0: PCI BIOS has 17 Interrupt Routing table entries
pcibios0: PCI Exclusive IRQs: 3 5 10 11 12
pcibios0: no compatible PCI ICU found
pcibios0: Warning, unable to fix up PCI interrupt routing
pcibios0: PCI bus #2 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x800
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 Nvidia nForce3 250 PCI Host rev 0xa1
pcib0 at pci0 dev 1 function 0 Nvidia nForce3 250 ISA rev 0xa2
Nvidia nForce3 250 SMBus rev 0xa1 at pci0 dev 1 function 1 not configured
ohci0 at pci0 dev 2 function 0 Nvidia nForce3 250 USB rev 0xa1: irq 12,
version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: Nvidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 4 ports with 4 removable, self powered
ohci1 at pci0 dev 2 function 1 Nvidia nForce3 250 USB rev 0xa1: irq 10,
version 1.0, legacy support
usb1 at ohci1: USB revision 1.0
uhub1 at usb1
uhub1: Nvidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 4 ports with 4 removable, self powered
ehci0 at pci0 dev 2 function 2 Nvidia nForce3 250 USB2 rev 0xa2: irq 11
ehci0: EHCI version 1.0
ehci0: companion controllers, 4 ports each: ohci0 ohci1
usb2 at ehci0: USB revision 2.0
uhub2 at usb2
uhub2: Nvidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub2: single transaction translator
uhub2: 8 ports with 8 removable, self powered
Nvidia nForce3 LAN rev 0xa2 at pci0 dev 5 function 0 not configured
auich0 at pci0 dev 6 function 0 Nvidia nForce3 250 AC-97 Audio rev 0xa1: irq
3, nForce3 AC97
ac97: codec id 0x414c4780 (Avance Logic ALC658)
ac97: codec features 20 bit DAC, 18 bit ADC, No 3D Stereo
audio0 at auich0
pciide0 at pci0 dev 8 function 0 Nvidia nForce3 250 IDE rev 0xa2: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: Maxtor 6Y080P0
wd0: 16-sector PIO, LBA, 78167MB, 160086528 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: _NEC, DVD_RW ND-3540A, 1.01 SCSI0 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
pciide1 at pci0 dev 10 function 0 Nvidia nForce3 250 SATA rev 0xa2: DMA
(unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI
pciide1: using irq 11 for native-PCI interrupt
pciide1: channel 0 ignored (not responding; disabled or no drives?)
pciide1: channel 1 ignored (not responding; disabled or no drives?)
ppb0 at pci0 dev 11 function 0 Nvidia nForce3 250 AGP rev 0xa2
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 ATI Rage 128 Pro TF rev 0x00
wsdisplay0 at vga1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb1 at pci0 dev 14 function 0 Nvidia nForce3 250 PCI-PCI rev 0xa2
pci2 at ppb1 bus 2
xl0 at pci2 dev 7
securiry: mail/imap-uw update to 2004g
hi
mail/imap-uw has a security problem described in
http://www.idefense.com/application/poi/display?id=313type=vulnerabilities;
attached diff takes the port to version 2004g
ok?
- Marc Balmer
diff -urN -x CVS mail/imap-uw.orig/Makefile mail/imap-uw/Makefile
--- mail/imap-uw.orig/Makefile Mon Aug 8 10:26:28 2005
+++ mail/imap-uw/Makefile Fri Oct 7 13:39:10 2005
@@ -3,8 +3,8 @@
COMMENT= University of Washington IMAP4rev1/POP2/POP3 mail
servers
COMMENT-mailutil= University of Washington IMAP4rev1/POP2/POP3 mail
utility
-VERSION= 2004.357p1
-DISTNAME= imap-2004e
+VERSION= 2004g
+DISTNAME= imap-2004g
PKGNAME= imap-uw-${VERSION}
PKGNAME-mailutil= mailutil-uw-${VERSION}
diff -urN -x CVS mail/imap-uw.orig/distinfo mail/imap-uw/distinfo
--- mail/imap-uw.orig/distinfo Mon Aug 8 10:26:28 2005
+++ mail/imap-uw/distinfo Fri Oct 7 13:36:38 2005
@@ -1,4 +1,4 @@
-MD5 (imap-2004e.tar.Z) = deee044b2dcaf6fe12dc545673906ac5
-RMD160 (imap-2004e.tar.Z) = 76c8596fe1a9a830bbd60fdafafb13f9bac42cd9
-SHA1 (imap-2004e.tar.Z) = 3c5cf83489dd8ac4c2cfd43370fcec85db7bc372
-SIZE (imap-2004e.tar.Z) = 2219840
+MD5 (imap-2004g.tar.Z) = 9a80f58d8d6a0979c13714ae69050020
+RMD160 (imap-2004g.tar.Z) = a016a06ba073e879d2574a6395ce1074ea74c687
+SHA1 (imap-2004g.tar.Z) = 791a8bb247ca51ce0a4c32e814a2f736c2bcf066
+SIZE (imap-2004g.tar.Z) = 2246713
new: net/pear-Net-URL
find attached net/pear-Net-URL, used by Horde/IMP. ok? pear-Net-URL.tgz Description: Binary data
Re: UPDATE: fluxbox-0.9.14
David Krause wrote... please test Works fine on i386-current. Some warning during compile time, nothing horrendous, seems to work just fine. Josh
NEW: graphics/py-cairo
Hi all, I have written a port of pycairo-1.0.0. It relies on my cairo ports (which I have updated to 1.0.2). It also depends on libsvg-cairo and py-gtk2, since that is what is useful (too me at least). Note that I completely bypass the provided configure-based build mechanism, doing it all with python. Everything is available at http://ekyo.nerim.net/ports/ Eric.
ports philosophy
I just got a nicely worded letter from someone, who's prodded me into
trying once more to ask a ports-philosphy question. It's a question of
how much control to allow a user, for ports. The person I was chatting
with seemed to be of the opinion that the system ought to hage sole
control of all common area software, areas such as /usr/local, or opt,
or areas like that. This means allowing, by means of archtecture (not
just root control, but iron architectural control) whether or not a user
may have his own system.
I'm arguing here that such a system is very hostile to programmers, and
that there should be some method allowed, for a person to be able to
tell the system, for particular file, that the user is to be allowed
control of that file, and not the system. I want to be able to say, for
example, I have installed libtcl.so.84.1, and not you, but please use it
to satisfy calls for (give a sed pattern that finds libtcl.so.84 well
enough).
[Let me emphasize that above a little more: un my mind, you're making a
system that's hostile to progammers, unless they are willing to program
for OpenBSD itself. Actually using OpenBSD as a base for their own
projects, it's such a hostile environment! The ports system legislates
against all incursions against it's iron control.]
I suppose it's possible that such a overrideregistration method might
exist, but if so, I can't find it. The system, as I see it, has been
crafted so that no programmer can have any control at all, and the only
person who wins is the sysadmin, who no longer has to worry that anyone
might possibly make any changes in his system, the control is not just
via root password (which in itself is a system that is strong enough for
this task. Root password isn't the strongest method in the world, but
it's strong enough for this purpose.
If you are making a system that allows no users to have any control even
if they're the root user, then you are making a system that is highly
hostile to programmers. What you ought to expect, then, is for folks to
install your system, learn what kind of control they're giving up, and
then those people will be leaving the system, just as soon as an
alternative shows up, because THEY LIKE TO PROGRAM.
I just can't see why adding in a program, something akin to GNU's
pkgconfig idea, is such a bad idea.
The way I see it working is, for every dir in the list of dirs in
LD_LIBRARY_PATH, there should be dir ${dir}/opkgconfig (gnu already uses
pkgconfig, so I added a o prefix, I might even agree to
openbsd-pkgconfig subdir to every dir that shared libs are in. Then,
for every shared lib that the programmer wishees to have control over,
the person must have a file of the form (pkgname.pc) , example,
libtcl.pc. Inside this file would be information that you would want to
pass along to the system, if it's going to surrender all control, such
as a sed pattern that you'd want to have the file protect against
incursion on, all the CFLAGS to use, if you want to compile in the
program, any LDFLAGS likewise, installation dir, include dir, (and yo
can probabluy figure in anything I;'ve forgotten). Making a small shell
utility to query the .pc files wouldn't be all that hard, would it?
Re: ports philosophy
On Fri, Oct 07, 2005 at 01:51:22PM -0400, Chuck Robey wrote: [ a rant ] You're completely wrong. Programmers can very well use our system (and they do). The pkgconfig approach is flawed, it doesn't allow for some things we would do. The gnu configure approach is worse. It has a lot of assumptions that are quite wrong, in some times disturbingly so. If you prefer that approach, go back to using gnu linux. Auto-detecting piles of shit without any user control, or with very poor user control, like GNU configure allows, is a receipe for disaster. It does NOT help the user, contrarily to what you might think.
Re: ports philosophy
On Fri, Oct 07, 2005 at 01:51:22PM -0400, Chuck Robey wrote: I just got a nicely worded letter from someone, who's prodded me into trying once more to ask a ports-philosphy question. It's a question of This isn't our philosophy list. You must have this confused with misc@ misc@ is the appropriate list for flamebait. HTH! -- Mathieu Sauve-Frankel
Re: ports philosophy
Mathieu Sauve-Frankel wrote: On Fri, Oct 07, 2005 at 01:51:22PM -0400, Chuck Robey wrote: I just got a nicely worded letter from someone, who's prodded me into trying once more to ask a ports-philosphy question. It's a question of This isn't our philosophy list. You must have this confused with misc@ misc@ is the appropriate list for flamebait. HTH! Why? It's just a matter of porting the flamebait.
Re: ports philosophy
[EMAIL PROTECTED] wrote: Chuck Robey wrote: [Let me emphasize that above a little more: un my mind, you're making a system that's hostile to progammers, unless they are willing to program for OpenBSD itself. I assume you never used OpenBSD for serious development of software that has to be run on different target platforms, because...: you are just plain wrong. OpenBSD is indeed one of the best platforms to do development and testing on, even if writing code that is targeted at a different platform. OK, I stated that I'm talking about getting the ports not to allow development ... I'm talking about getting ports to allow you to specify that it is to use some parts that you provide, and not stubbornly require that it supply all the pieces. I had put in my own gettext, which installed libintl.so.7.3. The ports installed, on it's own (and I cou;d see how to override this) a libintl.so.2.0, but when gmake linked, it added in the 7.3, and gmake did 2 rotten things: it found the files that my gettext had installed, and refused to ovewrite them, and then added a @wantlib in the +CONTENTS file of the gmake package, but (why?) couldn't find the libintl.so.7.3 that the ldconfig found ok. In other words, the ports really kicked up hell that I'd had the gaul to put my own files in, and I couldn't get it to lose the idea. I m not completely finished trying to find a way around this, but are your comments above predicated on the idea of mixing ports and non-ports development?
Re: ports philosophy
Marc Espie wrote: On Fri, Oct 07, 2005 at 01:51:22PM -0400, Chuck Robey wrote: [ a rant ] You're completely wrong. Programmers can very well use our system (and they do). The pkgconfig approach is flawed, it doesn't allow for some things we would do. The gnu configure approach is worse. It has a lot of assumptions that are quite wrong, in some times disturbingly so. If you prefer that approach, go back to using gnu linux. Auto-detecting piles of shit without any user control, or with very poor user control, like GNU configure allows, is a receipe for disaster. It does NOT help the user, contrarily to what you might think. I'm going to drop this, if you folks will be kind enough to let me. I just wish that folks would leave off the kind of response you're wrong and instead try this is why you're wrong, and this is the right way. It's a lot more useful. I am sorry if I've started some mini-war.
NEW: xcompmgr
xcompmgr is a sample composite manager for X. Together with the X composite extension (which needs to be enabled explicitely in xorg.conf) it helps adding eye-candy (shadows, transparencies, etc) to X applications. Try for instance fluxbox transparencies with 'xcompmgr -c'. -- Matthieu Herrb xcompmgr.tgz Description: Binary data
Re: ports philosophy
Chuck Robey wrote: I'm going to drop this, if you folks will be kind enough to let me. I just wish that folks would leave off the kind of response you're wrong and instead try this is why you're wrong, and this is the right way. It's a lot more useful. I am sorry if I've started some mini-war. You did not start a mini-war. You are just wrong. One day you will realize.
Re: ports philosophy
On Fri, Oct 07, 2005 at 04:15:59PM -0400, Chuck Robey wrote: I had put in my own gettext, which installed libintl.so.7.3. The ports installed, on it's own (and I cou;d see how to override this) a libintl.so.2.0, but when gmake linked, it added in the 7.3, and gmake did 2 rotten things: it found the files that my gettext had installed, and refused to ovewrite them, and then added a @wantlib in the +CONTENTS file of the gmake package, but (why?) couldn't find the libintl.so.7.3 that the ldconfig found ok. In other words, the ports really kicked up hell that I'd had the gaul to put my own files in, and I couldn't get it to lose the idea. You're not a serious developer, you just tinker with stuff... - Installing your own gettext is rather dangerous, unless you really know what you are doing. Especially these days, because we are adding i18n to the base system. - Installing stuff into the same directories the basic ports install stuff in is a nice recipe for disaster. - If you install basic software like gettext on a variant version, there will be issues all over the ports tree. what you're describing here is the *least* of your worries stuff that should work won't. - @wantlib records actual hard set libraries, but they need to be parts of packages, together with dependencies. It's trivial to cobble together a package that will record the stuff you install. It's about as difficult as pkgconfig specs. It's easy to automate. No-one with skill enough has shown enough interest. Oh yes, and the way it works is documented in pkg_add(1)/pkg_create(1). - personally, when I install new software, I simply use the ports framework. It's trivial to write a skeleton port that builds, packages and installs stuff. Polishing it to commit quality is a bit harder. The only point you may have is that, one day, we might move the whole package stuff from /usr/local to elsewhere, maybe even /usr/pkg. It's a big change, we're not even really sure it's worth it. Also, you seem to operate under a strange delusion, that software components work flawlessly. Having played a lot with various versions of software, I can tell you it's a myth. Installing a new version of a common dependency very often results in breakage, some of it quite subtle. The skills of the people who write those basic components is not that good. Well, there's another rather negative point about your whole idea: people who do actually tinker with software don't try to reinvent the wheel all the time. Unless you're learning the basic ropes, it pays a lot to start from existing stuff like, if you want to use a newer version of gettext, it's ways simpler to modify the existing port to use the new version. That way, you get the OpenBSD specific patches, instead of having to re-roll your own. You seem to have missed one big advantage to the ports tree: it's there, and it's way more transparent than some other package systems... It just insists on doing things correctly, and thus it catches lots of mistakes.
Re: new: shells/perlsh 1.8
Jasper Lievisse Adriaanse [EMAIL PROTECTED] wrote: On Wed, 28 Sep 2005 17:46:36 +0200 Jasper Lievisse Adriaanse [EMAIL PROTECTED] wrote: snip i get this error upon installing the package Couldn't find subject in old manpage /usr/local/man/man3p/Psh::StrategyBunch.3p Unknown manpage type /usr/local/man/man3p/Psh::StrategyBunch.3p I noticed, that too. But I just can't seem to find the source of that error. Does anybody have a clue? Well, it's finally fixed. Thanks to the help of alek@, jmc@ and [EMAIL PROTECTED] The updated tarball containing the port, which is working on i386, alpha and sparc64, is at http://nedbsd.nl/~jasper/obsd/ports/perlsh.tar.gz What about this (it's make install output): [...] Installing /mnt/wd0i/obj/ports/perlsh-1.8/fake-i386/usr/local/bin/psh Writing /mnt/wd0i/obj/ports/perlsh-1.8/fake-i386/usr/local/libdata/perl5/site_perl/i386-openbsd/auto/psh/.packlist Appending installation info to /mnt/wd0i/obj/ports/perlsh-1.8/fake-i386/usr/./libdata/perl5/i386-openbsd/perllocal.pod /usr/bin/perl postinstall.pl /usr/local /usr/local Installing share files to /usr/local/share/psh systrace: deny user: root, prog: /bin/mkdir, pid: 28858(0)[10776], policy: /usr/bin/env, filters: 144, syscall: native-fswrite(136), filename: /usr/local/share/psh mkdir: /usr/local/share/psh: Operation not permitted systrace: deny user: root, prog: /bin/cp, pid: 25329(0)[10776], policy: /usr/bin/env, filters: 144, syscall: native-fswrite(136), filename: /usr/local/share/psh cp: /usr/local/share/psh/: Operation not permitted systrace: deny user: root, prog: /bin/cp, pid: 26483(0)[10776], policy: /usr/bin/env, filters: 144, syscall: native-fswrite(136), filename: /usr/local/share/psh cp: /usr/local/share/psh/: Operation not permitted Cheers, Alek -- Maybe were victims of fate / Remember when we'd celebrate We'd drink and get high until late / And now were all alone Wedding bells ain't gonna chime / With both of us guilty of crime And both of us sentenced to time / And now were all alone -- Placebo, Protect me from what i want
Re: ports philosophy
Matthias Kilian wrote: On Fri, Oct 07, 2005 at 08:13:25PM +0200, Marc Espie wrote: Auto-detecting piles of shit without any user control, or with very poor user control, like GNU configure allows, is a receipe for disaster. It does NOT help the user, contrarily to what you might think. See also: http://www.onlamp.com/pub/a/onlamp/2005/03/31/packaging.html http://www.onlamp.com/pub/a/onlamp/2005/04/28/packaging2.html Not perfect, but it mentions a lot of common (avoidable) problems. Please, I NEVER said I like configure, I don't like configure, and I dont like being represented as liking configure, not most of gnu. My sole thesis was that the ports system should allow a user to be able to make certain overrides in some of the software (like install one of their own libraries), and allow that user to take maintenance responsibility for those decisions. I never said I like any of the gnu stuff. As a matter of fact, I'm one of those few folks who like Makefiles. Ciao, Kili
Re: ports philosophy
Marc Balmer wrote: Chuck Robey wrote: Marc, I began to reply, because you've begun insulting me here, but if you'll let it go, I will let it go here. Can you do that? Just stop reading here. You are not being insulted. We just try to direct you in the right direction. Maybe the time has come to end this thread if you feel insulted by good advice. would you be wiling ot meet me on a irc channel, say, on freenode? I will be on channel chuckr for the next new minutes, ok? Let's get this off the mailing lists, and get it over.
Re: ports philosophy
On Fri, Oct 07, 2005 at 05:14:59PM -0400, Chuck Robey wrote: Marc Espie wrote: You're not a serious developer, you just tinker with stuff... You know, I'be been as careful as I could be, never to insult any of you. You know me very little, but you need to support your argument, and I guess you need to insult. - Installing your own gettext is rather dangerous, unless you really know what you are doing. Especially these days, because we are adding i18n to the base system. It's not so terribly dangerous as all that, moreover, nothing i do to my own system affects your at all. If I take responsibiliity for my own system, then (as long as it removes none of your control, and I've already demonstated at least one method to do that, I'm certain that I didn't pick either the only way or the best way) then this wouldn't bother your system goals at all. I spent years doing FreeBSD ports. about 10. Yes, you need to stay awake, but as long as you don't mind talking care of things, it's not so bad, not nearly as bad as you are playing it. Well, I've spent enough time working on i18n to tell you that, yes, it is more dangerous than that. Other people working on this stuff, naddy for instance, could tell you the same thing. It's not only staying awake, it's figuring out weeks later that the stuff that almost works that you see is coming from THAT specific change and not from anything else. I don't care that it's your machine or not, I'm just saying it's dangerous. You are doing some non-serious, dangerous tinkering there. If you don't see the link now that it's explicit, and you still think I'm insulting you, your loss... OK, then how about a have local-1? I would like, if I install some shared lib in /usr/local-1/lib, to have it not only found, but have it override (in terms of DEPENDS) any lib in /usr/local, or any ports-controlled lib. If I agree that I must take all blame for any problems in such a system, folks in FreeBSD, which runs like that (and has for years) don't seem to be all that worried. Knobs are an issue, for various reasons. We do provide some. Not that many. Because each of them takes a lot of time to support. You might think it's just a convenient knob for you, but it has a big cost. Each option we add is carefully weighted. I'll make you a deal: once we've finished making sure all ports are clean if you tinker with LOCALBASE, X11BASE or SYSCONFDIR, I'll have a look at something that would allow you to install some stuff elsewhere. One final point: the apparent complexity of the dependencies in the OpenBSD ports system is real. It's what allows pkg_add -u to work, and YES, there are rather difficult issues to solve...
Re: ports philosophy
On Fri, Oct 07, 2005 at 05:14:59PM -0400, Chuck Robey wrote: Marc Espie wrote: - Installing stuff into the same directories the basic ports install stuff in is a nice recipe for disaster. OK, then how about a have local-1? I would like, if I install some shared lib in /usr/local-1/lib, to have it not only found, but have it override (in terms of DEPENDS) any lib in /usr/local, or any ports-controlled lib. If I agree that I must take all blame for any problems in such a system, folks in FreeBSD, which runs like that (and has for years) don't seem to be all that worried. Why move the ports to local-1? Why don't you install your own stuff in local-1? Why does the rest of the world have to bend over for your sake? -Ray-
Re: ports philosophy
Chuck Robey wrote: You are not being insulted. We just try to direct you in the right direction. Maybe the time has come to end this thread if you feel insulted by good advice. would you be wiling ot meet me on a irc channel, say, on freenode? I will be on channel chuckr for the next new minutes, ok? Let's get this off the mailing lists, and get it over. I see no benefit in not discussing this publicly. And, it's not about getting over it. You stated, among other things, that OpenBSD is somewhat programmer unfriendly. Which is wrong. So stay with us and explain exactly why OpenBSD is not suited for serious software development (which I and my colleagues do, btw).
Re: ports philosophy
Ray Lai wrote: On Fri, Oct 07, 2005 at 05:14:59PM -0400, Chuck Robey wrote: Marc Espie wrote: - Installing stuff into the same directories the basic ports install stuff in is a nice recipe for disaster. OK, then how about a have local-1? I would like, if I install some shared lib in /usr/local-1/lib, to have it not only found, but have it override (in terms of DEPENDS) any lib in /usr/local, or any ports-controlled lib. If I agree that I must take all blame for any problems in such a system, folks in FreeBSD, which runs like that (and has for years) don't seem to be all that worried. Why move the ports to local-1? Why don't you install your own stuff in local-1? Why does the rest of the world have to bend over for your sake? -Ray- Ray, you didn't read well enough, I merely want to install my own nominations for some pieces of software, anywhere you choose, I don't care too much, I just don't want the system to come to a crashing halt if it finds something of mine. I am perfectly willing to jump thru any hoop whatever, to tell the system what I've done, but it needs to be possible to accomplish. I give again as example, if I install libintl.so.7.3 in /usr/local-1/lib/, I wish it to be found and used, and not have it overwritten by a libintl.so.2.0 in /usr/local/lib. What I *think* I was asking for really boils down to some method to tell the system, officially, what I've gone and done. Something akin to (but not exactly!) the GNU pkgconfig system. My main problem with that system, by the way, is those silly little *.la files. They aren't needed! As far as that goes, I did find one nice theng even about Linux: I don't expec to ever get folks to agree, but I think the Gentoo's etc setup is pretty slick. They rely on python, and that in itself is a very nice thing. It's a grownup piece of software, if you'll call perl the teenager. There's good everywhere, if you're not too stubborn. Did I just call someone else stubborn? OK , I'm losing it.
Re: ports philosophy
Chuck Robey wrote: I want to be able to put in my own items, and have them be able to: 1) be found by the pkg tools, the *DEPENDS stuff 2) not have files that I've installed be overwritten by installed files from ports. If I installed a modified gmake, not to have you overwrite it. I don't see why you couldn't do that. Keep your own ports tree and set PORTSDIR_PATH in /etc/mk.conf accordingly for a first step. Then you can have your own version of any ports. The ports tools don't overwrite existing files, they issue a warning.
Re: ports philosophy
Marc Balmer wrote: Chuck Robey wrote: You are not being insulted. We just try to direct you in the right direction. Maybe the time has come to end this thread if you feel insulted by good advice. would you be wiling ot meet me on a irc channel, say, on freenode? I will be on channel chuckr for the next new minutes, ok? Let's get this off the mailing lists, and get it over. I see no benefit in not discussing this publicly. And, it's not about getting over it. You stated, among other things, that OpenBSD is somewhat programmer unfriendly. Which is wrong. So stay with us and explain exactly why OpenBSD is not suited for serious software development (which I and my colleagues do, btw). BTW, your comment about me, I have a full archive of my comments, and I did never say OpenBSD is not suited for serious software development, what I said was that a system that would not allow a programmer to put in their own software was very hostile, and that some method should exist to allow a programmer to insert their own work amongst the ports software. Especially for an item that's so inflammatory, can we please not make things worse? I did allow the possibility that I might be wrong, also, and I have been repeatedly asking what method might exist to allow what I want to do, so if I;'m wrong, TELL ME. And don't tell me something like you're wrong, tell me how the right way is, how to I tell the system that I have in the acme widget, and that it's not supposed to install it's own version of the acme widget.
Re: ports philosophy
Marc Balmer wrote: Chuck Robey wrote: I want to be able to put in my own items, and have them be able to: 1) be found by the pkg tools, the *DEPENDS stuff 2) not have files that I've installed be overwritten by installed files from ports. If I installed a modified gmake, not to have you overwrite it. I don't see why you couldn't do that. Keep your own ports tree and set PORTSDIR_PATH in /etc/mk.conf accordingly for a first step. Then you can have your own version of any ports. The ports tools don't overwrite existing files, they issue a warning. All this time, if I were factually wrong (and folks had been so tied up in saying you;'re wrong instead of what's right) I would really find that funny. Look, I will try this again, I will re-install from scratch and see, I never tried messing with PORTSDIR_PATH before.
Re: ports philosophy
On Fri, Oct 07, 2005 at 06:19:25PM -0400, Chuck Robey wrote: what I said was that a system that would not allow a programmer to put in their own software was very hostile, and that some method should exist to allow a programmer to insert their own work amongst the ports software. there is a way to add your own software. you make your own port. that was the first (and repeated many times) answer. I did allow the possibility that I might be wrong, also, and I have been repeatedly asking what method might exist to allow what I want to do, so if I;'m wrong, TELL ME. you have been told repeatedly. make/modify an existing port. the ports system is very well documented. And don't tell me something like you're wrong, tell me how the right way is, how to I tell the system that I have in the acme widget, and that it's not supposed to install it's own version of the acme widget. you do it by making a proper port/package. start by reading ports(7). one more time: make your own port. it's really not that hard, especially if your just modifying an existing port, which is exactly what you want to do. for future reference, if you had asked your question like so: how do I install a version of gmake that is different than the port, but have it work with the ports system?, then you would not have been labeled, and you probably would have gotten help doing exactly what you wanted to do. insulting peoples' work is not far from insulting the people. you really shouldn't be surprised by the replys you've gotten. -- [EMAIL PROTECTED]
Dsniff coredump OpenBSD-Current, AMD64 (SMP)
Tkae ya prefered 40MB wordlist, a neat TelnetD somewhere and use Hydra to bruteforce any account. Then switch to another console and run dsniff ($ dsniff). Dsniff will coredump after some seconds. Example (dsniff ran 90-110 seconds): - 10/08/05 07:07:29 tcp some.where.int.19574 - beloved.telnet.daemon.23 (telnet) anyaccount Abi-Farah anyaccount - 10/08/05 07:07:29 tcp some.where.int.9193 - beloved.telnet.daemon.23 (telnet) anyaccount Abi-Ghanem anyaccount Segmentation fault (core dumped) $ Some neat but useless GDB output (just because I know somebody will ask me for it): $ sudo gdb --core dsniff.core /usr/local/sbin/dsniff 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 amd64-unknown-openbsd3.8...(no debugging symbols found) Core was generated by `dsniff'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libdb.so.3.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdb.so.3.1 Reading symbols from /usr/local/lib/libnet.so.0.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libnet.so.0.0 Reading symbols from /usr/lib/libpcap.so.3.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libpcap.so.3.0 Reading symbols from /usr/lib/libssl.so.10.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libssl.so.10.0 Reading symbols from /usr/lib/libcrypto.so.12.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libcrypto.so.12.0 Reading symbols from /usr/lib/libdes.so.9.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libdes.so.9.0 Reading symbols from /usr/lib/libc.so.38.2... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libc.so.38.2 Reading symbols from /usr/libexec/ld.so...(no debugging symbols found)...done. Loaded symbols for /usr/libexec/ld.so #0 0x0040c790 in ?? () (gdb) OS: OpenBSD current (snapshot downloaded yesterday) ARCH: AMD64, SMP dmesg: OpenBSD 3.8-current (GENERIC.MP) #0: Fri Oct 7 00:57:26 CEST 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2147020800 (2096700K) avail mem = 1836093440 (1793060K) using 22937 buffers containing 214908928 bytes (209872K) of memory mainbus0 (root) mainbus0: Intel MP Specification (Version 1.1) (TYAN S2882 ) cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Opteron(tm) Processor 242, 1595.07 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,MMXX,LONG,3DNOW2,3DNOW cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: apic clock running at 199358268Hz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Opteron(tm) Processor 242, 1594.87 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,MMXX,LONG,3DNOW2,3DNOW cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative mpbios: bus 0 is type PCI mpbios: bus 1 is type PCI mpbios: bus 2 is type PCI mpbios: bus 3 is type PCI mpbios: bus 4 is type ISA ioapic0 at mainbus0 apid 2: pa 0x83740e24, version 11, 24 pins ioapic1 at mainbus0 apid 3: pa 0x83740d24, version 11, 4 pins ioapic2 at mainbus0 apid 4: pa 0x83740c24, version 11, 4 pins pci0 at mainbus0 bus 0: configuration mode 1 ppb0 at pci0 dev 6 function 0 AMD 8111 PCI-PCI rev 0x07 pci1 at ppb0 bus 3 ohci0 at pci1 dev 0 function 0 AMD 8111 USB rev 0x0b: apic 2 int 19 (irq 10), version 1.0, legacy support usb0 at ohci0: USB revision 1.0 uhub0 at usb0 uhub0: AMD OHCI root hub, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1 at pci1 dev 0 function 1 AMD 8111 USB rev 0x0b: apic 2 int 19 (irq 10), version 1.0, legacy support usb1 at ohci1: USB revision 1.0 uhub1 at usb1 uhub1: AMD OHCI root hub, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered emu0 at pci1 dev 4 function 0 Creative Labs SoundBlaster Live rev 0x08: apic 2 int 16 (irq 9) ac97: codec id 0x43525914 (Cirrus Logic CS4297A rev 4) ac97: codec features headphone, 20 bit DAC, 18 bit ADC, Crystal Semi 3D audio0 at emu0 Creative Labs PCI Gameport Joystick rev 0x08 at pci1 dev 4 function 1 not configured pciide0 at pci1 dev 5 function 0 CMD Technology SiI3114 SATA rev 0x02: DMA
