Re: DRM in xpdf
* Martin Schr?der <[EMAIL PROTECTED]> [2008-04-25 23:33:05]: > 2008/4/25 Deanna Phillips <[EMAIL PROTECTED]>: > > You mean this part? > > > > "For those who would argue that important content might get > > irretrievably locked away in PDF format, I'll remind you that > > Xpdf is open source, and can be modified by end users (the GPL > > even allows this)." > > While an XPDF port with these patches is technically not distributed > but compiled by the user installing the port, any package of this > patched XPDF will be a modified version of XPDF and as such has to > follow the restrictions on distributing modified programs as specified > in section 2 of the GPL. Or you stop distributing XPDF packages. > > Best >Martin > > You're out of touch with reality. The GPL is not being violated, or even streched for that matter! And whether or not the ports guys remove this drm crap, well, that's not your decision. The DRM is going away. It's absurd to have it. If you can view a document or whatnot, you can copy it. This is some kludge to try and make it harder to do that. Well, honestly, its not that hard. I could type out something by hand in the document or screenshot the images. This is _NOT_ security. It's stupidity. This no-copy crap makes no sense. I can't think of one reason why someone would want this. It's not going to protect the pdf author's work. Which is absurd in its own right. Protecting your work from the very people you are sharing it with. I thought the point of a "portable document format" was to disseminate information! You keep blabbering on about section 2 of the GPL. Well, we're not changing the license, and the program does not print a license clause on startup, so that only leaves part A: "You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change." I don't see what's more conducive to this than the nice unified diffs existing in the ports tree. The GPL is being followed. DRM is stupid. Oh wait, as a matter of fact, the two are ideologically opposed to each other! Get a grip. -- Travers Buda
Re: DRM in xpdf
* Martin Schr?der <[EMAIL PROTECTED]> [2008-04-25 23:23:17]: > 2008/4/25 Travers Buda <[EMAIL PROTECTED]>: > > This part? > > Troll. > > Wow. -- Travers Buda
Re: DRM in xpdf
* Martin Schr?der <[EMAIL PROTECTED]> [2008-04-25 17:32:26]: > 2008/4/25 Travers Buda <[EMAIL PROTECTED]>: > > There is plenty of precedent for this sort of thing. Plus, xpdf > > is GPL 2, so we're not dealing with some sort of Iceweasel or Apache > > type malarkey. It's not an issue. > > Read section 2 of the GPL2 please. > > Best >Martin > > This part? "You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications..." Apache, in my example, added some sort of clause that you can't modify / distribute their software and call it apache. That's not the GPL, that's their own clause. It's the rebranding issue. It does not exist with xpdf. But really, the rebranding issue is not germane to this discussion; there's no need to fork the software. That would be the only time I would consider such action. -- Travers Buda
Re: DRM in xpdf
* Martin Schr?der <[EMAIL PROTECTED]> [2008-04-25 10:00:22]: > 2008/4/25 Theo de Raadt <[EMAIL PROTECTED]>: > > Thank you very much for your opinion, but it is clear you come > > with an agenda. > > > > The OpenBSD project people do not follow the "bend to Adobe" agenda > > that some xpdf people follow. > > While it's always nice to blame Adobe, please first discuss those patches > upstream (i.e. with Derek and/or the poppler guys). And then consider > forking an OpenXPDF. At least make sure the original author never gets > bug reports from your Frankenstein-XPDF. > > Best >Martin > Oh, puh-lease. It's common practice for a distibution of whatever, be it BSD, linux, etc., to add patches to 3rd party programs--not just to make them compile and work on a platform, but also to change functionality. This is no secret; upstream would be foolish to not consider the platform and patches their software is running on and with if they get a bug report. There is plenty of precedent for this sort of thing. Plus, xpdf is GPL 2, so we're not dealing with some sort of Iceweasel or Apache type malarkey. It's not an issue. -- Travers Buda
Re: Remove x11/ion
* Darrin Chandler <[EMAIL PROTECTED]> [2007-04-30 09:49:19]: > On Mon, Apr 30, 2007 at 11:24:07AM -0500, Marco Peereboom wrote: > > Sure we can keep ion3 ad is but I'd like to pick up the new changes in a > > forked project called bananawm :-) > > bananawm? I don't get it. How about FreeIon for a fork: > > "FreeIon: if you're not part of the solution, you're part of the > precipitate" > Naw, I like bananawm better =). Such features could include: . Changing the mouse cursor to a banana. . A theme song is absolutely necessary... http://en.wikipedia.org/wiki/Bananaphone . Banana background! . Floating bananas like xsnow! . A banana clock... hrm, analog sounds good, but binary or digital would suffice. . A Pulp Fiction themed FPS with the only weapons being bannanas... hey, a wm has to have it all, after all! See http://www.flickr.com/photos/i-capture/16136112/ for an artistic example we can base it off of. Banana, mofo, do you speak it? But in all seriousness, FreeIon sounds good. Little bit easier to figure out just what the hell it is. Anyone serious about sed'ing this port to hell? -- Travers Buda
Re: Remove x11/ion
* Pedro Martelletto <[EMAIL PROTECTED]> [2007-04-30 15:58:02]: > As can be seen in http://tinyurl.com/2pelmo [1], the author of x11/ion > recently changed the software's license to something obscure, completely > open to misinterpretation, and in my opinion incompatible with our ports > tree. > > Therefore, I'd like to propose the complete removal of the port. > How about no. We can easily keep around a compatible version; I find ion3 to be quite stable anyhow. Besides, OpenBSD has been known to keep 6 year old WM code around. Point is, the unencumbered port works, no point in removing it over spite. -- Travers Buda
Re: NEW: geo/proj
Eric's port of proj fails regress tests for me on amd64 =(. cd /usr/ports/mystuff/geo/proj/w-proj-4.5.0/proj-4.5.0/nad && ./testntv2 ../src/cs2cs Running ./testntv2 using ../src/cs2cs: doing tests into file ntv2_out, please wait diff ntv2_out with ntv2_out.dist 3,6c3,6 < 82d00'00.000"W 42d00'00.000"N 0.0 82dW42d0'0.03"N 0.000 < 82d00'01.000"W 42d00'00.000"N 0.0 82d0'1"W42d0'0.03"N 0.000 < 82d00'02.000"W 42d00'00.000"N 0.0 82d0'2"W42d0'0.03"N 0.000 < 84d00'00.000"W 42d00'00.000"N 0.0 84dW42d0'0.03"N 0.000 --- > 82d00'00.000"W 42d00'00.000"N 0.0 81d59'59.61037"W42d0'0.1602"N > 0.000 > 82d00'01.000"W 42d00'00.000"N 0.0 82d0'0.610403"W 42d0'0.160204"N 0.000 > 82d00'02.000"W 42d00'00.000"N 0.0 82d0'1.610436"W 42d0'0.160209"N 0.000 > 84d00'00.000"W 42d00'00.000"N 0.0 83d59'59.85928"W42d0'0.18003"N > 0.000 9,11c9,11 < 99d00'00.000"W 65d00'00.000"N 0.0 99dW65d0'0.03"N 0.000 < 111d00'00.000"W 46d00'00.000"N 0.0111dW 46d0'0.03"N 0.000 < 111d00'00.000"W 47d30'00.000"N 0.0111dW 47d30'0.03"N 0.000 --- > 99d00'00.000"W 65d00'00.000"N 0.0 99d0'1.58847"W 65d0'1.34815"N 0.000 > 111d00'00.000"W 46d00'00.000"N 0.0111d0'3.15487"W 45d59'59.75279"N 0.000 > 111d00'00.000"W 47d30'00.000"N 0.0111d0'2.7989"W 47d29'59.9896"N 0.000 PROBLEMS HAVE OCCURED test file ntv2_out saved # cd w-proj-4.5.0/proj-4.5.0/nad/ # ./testvarious ../src/cs2cs Running ./testvarious using ../src/cs2cs: doing tests into file td_out, please wait diff td_out with td_out.dist 3,4c3,4 < 111d00'00.000"W 44d00'00.000"N 0.0111dW 44dN 0.000 < 111d00'00.000"W 39d00'00.000"N 0.0111dW 39dN 0.000 --- > 111d00'00.000"W 44d00'00.000"N 0.0111d0'3.085"W 43d59'59.756"N 0.000 > 111d00'00.000"W 39d00'00.000"N 0.0111d0'2.604"W 38d59'59.912"N 0.000 7,8c7,8 < 111d00'00.000"W 44d00'00.000"N 0.0111dW 44dN 0.000 < 111d00'00.000"W 39d00'00.000"N 0.0111dW 39dN 0.000 --- > 111d00'00.000"W 44d00'00.000"N 0.0111d0'2.788"W 43d59'59.725"N 0.000 > 111d00'00.000"W 39d00'00.000"N 0.0111d0'2.604"W 38d59'59.912"N 0.000 11,14c11,14 < 79d58'00.000"W 37d02'00.000"N 0.0 79d58'W 37d2'N 0.000 < 79d58'00.000"W 36d58'00.000"N 0.0 79d58'W 36d58'N 0.000 < 79d58'00.000"W 37d02'00.000"N 0.0 79d58'W 37d2'N 0.000 < 79d58'00.000"W 36d58'00.000"N 0.0 79d58'W 36d58'N 0.000 --- > 79d58'00.000"W 37d02'00.000"N 0.0 79d58'0.005"W 37d1'59.998"N 0.000 > 79d58'00.000"W 36d58'00.000"N 0.0 79d57'59.128"W 36d58'0.501"N 0.000 > 79d58'00.000"W 37d02'00.000"N 0.0 79d57'59.126"W 37d2'0.501"N 0.000 > 79d58'00.000"W 36d58'00.000"N 0.0 79d57'59.128"W 36d58'0.501"N 0.000 21c21 < 79d00'00.000"W 35d00'00.000"N 0.0 79dW34d59'57.975"N 718.018 --- > 79d00'00.000"W 35d00'00.000"N 0.0 78d59'59.107"W 34d59'58.563"N 718.018 39,40c39,40 < 0d00'00.000"W 0d00'00.000"N 0.0 6378137.00 0.00 0.00 < 0d00'00.000"W 0d00'00.000"N 10.0 6378147.00 0.00 0.00 --- > 0d00'00.000"W 0d00'00.000"N 0.0 6378137.00 -0.00 0.00 > 0d00'00.000"W 0d00'00.000"N 10.0 6378147.00 -0.00 0.00 42c42 < 0d00'00.000"W 90d00'00.000"N 0.0 0.000.00 6356752.31 --- > 0d00'00.000"W 90d00'00.000"N 0.0 0.00-0.00 6356752.31 PROBLEMS HAVE OCCURED test file td_out saved -- Travers Buda
Re: NEW: geo/proj
* Benoit Myard <[EMAIL PROTECTED]> [2007-04-20 23:02:26]: > Hi, > > proj is both a library and a set of tools for cartographic > projections. It's the base of many cartographic applications (GRASS, > MapServer, GDAL/OGR, Quantum GIS) whose I plan to port (at least for > MapServer and GDAL/OGR) as well. > > I thought creating a 'geo' category was a good idea since it will > later contain other specific ports too, correct me if I was wrong. > > Although proj surely builds on several platforms [1], I've only tested > the port on i386. > > Please send any comments and advises. > > NB: this is my very first port, and my first OpenBSD installation > (one-day old); don't hesitate! > > [1] I've got it build under Linux x86 and Sun Solaris 10. > Hi Benoit, It compiles for me here on amd64... I don't have any data lying around to test it with (perhaps you could provide?) I cleaned up the Makefile a little bit, but looks good... a good job especially since you've been running Open a day now. =) I'd like to see some GIS software in OpenBSD so I welcome your efforts. -- Travers Buda proj.tar.gz Description: application/tar-gz
Re: important: people following -current
* walt <[EMAIL PROTECTED]> [2007-04-10 17:05:48]: > Ingo Schwarze wrote: > > Hi Jesse, hi Walt, > > > > Jesse Scott schrieb am Tue, Apr 10, 2007 at 05:18:11AM +0100: > >> walt wrote: > > >>> So far I've figured out that I need to switch to xenocara also, > >>> but how? Are the binary snapshots the only way at the moment? > >>> Any way to build from source? > > >> This should help you build xenocara from source: > >> http://mersenne.homeunix.net/zaurusforums/viewtopic.php?t=220 > > For some reason that website won't load for me, so I used > Matthieu's instructions which worked on the first try. > Thanks to Jesse and Matthieu both. > ... See release(8) and the README in the xenocara tree. That should be all you need to build xenocara. I've been fetching the sources via cvs off rt.fm -- Travers Buda
Re: patch for graphics/GraphicsMagick
> Charles Longeau [2007-03-30, 19:24:50]: > Hi, > > While trying to build graphics/GraphicsMagick port, I faced this error : > > cc -DHAVE_CONFIG_H -I. -I. -I../magick -I../magick -I.. -I.. > -I/usr/X11R6/include/freetype2 -I/usr/local/include/libpng > -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/X11R6/include > -I/usr/local/include/libxml2 -O2 -pipe -Wall -MT png.lo -MD -MP -MF > .deps/png.Tpo -c png.c -fPIC -DPIC -o .libs/png.o > png.c: In function `ReadOnePNGImage': > png.c:1712: warning: implicit declaration of function `png_access_version' > png.c:1721: error: `png_ptr' undeclared (first use in this function) > png.c:1721: error: (Each undeclared identifier is reported only once > png.c:1721: error: for each function it appears in.) > *** Error code 1 I've seen this one too, on amd64; it fails every time. -- Travers Buda
Re: on current, Xvnc core dumps on amd64 (with an intel dual core
On Mon, 1 Jan 2007 23:38:47 +0200 Nikns Siankin <[EMAIL PROTECTED]> wrote: > > No. I have amd64 box without any duals cores... > Port is broken for amd64. There are a lot of *bugreports* > on misc@ about this port. > It works great for me on -current with an _athlon 64 clawhammer_. What hardware are you running, Nikns? Intel, AMD...? Travers Buda
Re: on current, Xvnc core dumps on amd64 (with an intel dual core
On Mon, 1 Jan 2007 17:39:00 +0100 (CET) Otto Moerbeek <[EMAIL PROTECTED]> wrote: > > On Mon, 1 Jan 2007, Travers Buda wrote: > > > On Mon, 01 Jan 2007 13:34:16 +0100 > > Didier Wiroth <[EMAIL PROTECTED]> wrote: > > > > > Hello, > > > I'm trying to use tightvnc-1.2.9p0 on current amd64 (with intel dual core > > > cpu). > > > > Perhaps one of these is at fault: > > http://geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif > > > > Travers Buda > > Core 2 CPU != Core CPU. > > The errata quoted is about the Core Duo/Solo CPU, the OP has a Core 2 > Duo CPU. > > A difference between the two is that the Core CPU's ae 32bit, > while the Core 2 CPU is 64 bit. > > -Otto > Whell, of course, =); it's a place to start. Another place to start would be trying to reproduce this on i386 -current... Didier?
Re: on current, Xvnc core dumps on amd64 (with an intel dual core
On Mon, 01 Jan 2007 13:34:16 +0100 Didier Wiroth <[EMAIL PROTECTED]> wrote: > Hello, > I'm trying to use tightvnc-1.2.9p0 on current amd64 (with intel dual core > cpu). Perhaps one of these is at fault: http://geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif Travers Buda
New VLC out.
Version 0.8.6 VLC is out. It does not compile right out of the box. A patch or two should be required. no_dvd is still mentioned in DESCR. Travers Buda
Re: Bind 9 port?
On Wed, 16 Aug 2006 13:32:09 -0600 "W S" <[EMAIL PROTECTED]> wrote: > Greetings, > > I'm wondering if there is anyone working on a port of Bind 9.x? > > Thanks, > Will http://openbsd.org/faq/faq1.html#Included And improvements, too. Travers Buda
Re: strange behavior of gecko-based browsers, AMD64, 3.9
Ok, thanks for the testing and replies all, it must be isolated to me. Good! Travers
Re: strange behavior of gecko-based browsers, AMD64, 3.9
I know this sounds a bit nuts, but I've only gotten the crashing with fvwm, 2.2.5; the version that OpenBSD ships with and has not been updated in 5 years. (I'm not blaming anyone, I realize the scale and resources of this project.) I noticed a more current verion is in ports, I'm going to look at that and their changelogs. Meanwhile, could you please test with 2.2.5 fvwm? If someone can duplicate what I'm getting, then I'll see what I can do about tracking down atleast this bug. On 5/8/06, Jim Capozzoli <[EMAIL PROTECTED]> wrote: Travers Buda wrote: > I've been experiencing slow rendering (mostly with large images) and random > crashing with the gecko-based browsers on 3.9 on AMD64. Same browsers on 64 > bit linux behave properly and are snappy. The network is not at fault for > the slow rendering. I've been unable to stick my finger on what is causing > the slow rendering (common) as compared to the crashing (about once > every 25 > minutes or so.) A page will load correctly in one instance, and then loaded > again can crash the browser. No errors are dumped in the term. > > I suspect this is some conflict with Gecko-20060303 and mmap'ed malloc > (only > grounds for this is a vanilla linux which is a whole different ball > park.) I > don't have a 3.8 box handy to see what verion of Gecko those era browsers > were using. But its a fair guess to say it was not Gecko-20060303 =). > > The offending browsers which I have used are mozilla-1.7.12p11, > galeon-1.3.21p3 (galeon only renders slowly, no crashes,) > mozilla-firefox-1.5.0.3, and mozilla-firefox-1.5.0.2, all of which are > using > Gecko-20060303. > > Has anyone else seen this or am I just crazy? > > As always, lynx works like a charm, sans the fact there are no pretty > pictures. =( > > Travers > I use openbsd/amd64 3.9 as a "desktop" box, and I don't experience any of your problems with mozilla-firefox-1.5.0.1. -Jim
strange behavior of gecko-based browsers, AMD64, 3.9
I've been experiencing slow rendering (mostly with large images) and random crashing with the gecko-based browsers on 3.9 on AMD64. Same browsers on 64 bit linux behave properly and are snappy. The network is not at fault for the slow rendering. I've been unable to stick my finger on what is causing the slow rendering (common) as compared to the crashing (about once every 25 minutes or so.) A page will load correctly in one instance, and then loaded again can crash the browser. No errors are dumped in the term. I suspect this is some conflict with Gecko-20060303 and mmap'ed malloc (only grounds for this is a vanilla linux which is a whole different ball park.) I don't have a 3.8 box handy to see what verion of Gecko those era browsers were using. But its a fair guess to say it was not Gecko-20060303 =). The offending browsers which I have used are mozilla-1.7.12p11, galeon-1.3.21p3 (galeon only renders slowly, no crashes,) mozilla-firefox-1.5.0.3, and mozilla-firefox-1.5.0.2, all of which are using Gecko-20060303. Has anyone else seen this or am I just crazy? As always, lynx works like a charm, sans the fact there are no pretty pictures. =( Travers
new: naim-0.11.8.1
naim is a ncurses client for AOL Instant Messenger (AIM), AOL I Seek You (ICQ), Internet Relay Chat (IRC), and The lily CMC. Tested and works fine on i386. Buggy on sparc64, added to NOT_FOR_ARCHS. Please test, especially amd64. Travers Buda naim-0.11.8.1.tgz Description: application/tgz
Re: dsniff segfaults
On Sunday 29 January 2006 08:25, Nikolay Sturm wrote: > * Frank Denis (Jedi/Sector One) [2006-01-24]: > > ports/dsniff always seems to always crash with SEGV after a few > > seconds on 3.9-beta x86. I've seen this behavior on 3.8-release but I no longer have the box with me that did it.
