Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On 26 Apr 2008, at 9:30 PM, Marc Espie wrote: We're talking about stupid, evil, legal DRM here. The pdf document basically says `oh, you're not supposed to do things with this document, because I say so'. There's nothing that prevents anyone from doing anything with the document. If anything, our xpdf should probably display a notice that says `the author of the document thought you should not be able to print it... or whatever'. Finally, some sense, thanks. The real issue for me at least is the fact that one is prepared to modify (in this case xpdf) away for what ever standard it is written against, modified away from the original software distribution without documenting the change, informing the end user who installs the modified software so they can make an informed decision as to whether they still want to use the modified version or go off and install the unmodified version. In the case of xpdf, everyone just wanted to shout we can modify the software because we can. If the modification is some where documented, then I and others don't sit scratching our heads as to why this no longer works the way it should according to the standard or whatever. But there is no actual protection in the document. It's all stupid shackles in software. This is a case where I strongly believe in freedom: the end user should be able to decide what they can do with the document. And equality: knowledgeable technical users shouldn't have an edge. It's completely hypocritical to say `oh, you can recompile the software to remove the restriction', because it shuts down some users. As far as I'm concerned, you've got two levels of protection: legal and technical. This `drm' part of pdf is purely legal: you get a document, you are informed you're not supposed to do such and such, and THAT'S IT. There's no technical protection to speak of. For me, the legal barrier is quite enough. As adult, you can make an ethical choice whether or not to obey the spirit of the document author. Ian McWilliam
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On 26 Apr 2008, at 1:34 PM, Iruata Souza wrote: On Fri, Apr 25, 2008 at 11:25 PM, Ian McWilliam [EMAIL PROTECTED] wrote: Stephan Andre' wrote: On Friday 25 April 2008 20:49:00 Ian McWilliam wrote: Ok, Not really wanting to comment on this call me a troll, call me want you want but The following rant in NOT about GPL licensing. I am neither supporting or denying the the said change to xdpf. This is a discussion about modifying standards.. What is hypocrytical here is the not one person has said the have looked at the standard for PDF to determine the correct behaviour. Whether it is for or against peoples wishes, there is a standard somewhere and even the author of xpdf hints that there is one and what you are removing is against the standard. http://www.foolabs.com/xpdf/cracking.html ... I distribute source code (for Xpdf) under a particular license (the GPL) which depends entirely on users' goodwill for its effectiveness. If any of my users ever decided to violate the license, I would probably never even know about it, much less be able to do anything about it. The only thing I can do is trust the users. In light of this, it would be very hypocritical of me to, on one hand, ask people to honor my licensing restrictions, and, on the other hand, bypass (or assist others in bypassing) another author's requested restrictions. In addition to all of this, Adobe requires that implementors of the PDF spec adhere to the document permissions. ... I haven't read the Adobe PDF sepc or standard and have no intention to. It looks like no body here wants to either. I find that puzzling seeing. According to a recent thread on tech@ recently, http://marc.info/?l=openbsd-techm=120890031123301w=2 This patch is a joke. It will never go into OpenSSH since it is completely incorrect. The standard is clear -- The version string for an SSH client or server is supposed to be disclosed. It is the standard behaviour, and is done for very good reasons. Can anybody explain why is it acceptable to modify a standard for ports but not not for base? flame away Ian McWilliam P.S I hate DRM as much as the next person. Because the two are completely different concepts. The SSH patch was clueless, both in terms of how OpenSSH works, and the protection it would(n't) give. Sorry STeve but we are not talking directly about the SSH patch in question. It's the concept of modifying software away from it's documented behaviour / standard. The removal of the DRM code is has actual benefit, the GPL permits this, and Adobe *knows* this. This is useless laywer gobble. PDF's are now an ISO standard. So if PDF is now an ISO standrard then what does the standard say about what being modified? This still dosn't answer why it is acceptable to modify a piece of software away from it's standards definition maybe you are a little confuse about design versus implementation? iru Not really, I have no issue with design vs implementation as long as it is documented somehow. The issue is that we want to modify software away from the original implementation but not document that fact. Ian McWilliam
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On 26 Apr 2008, at 2:30 PM, Nick Holland wrote: Ian McWilliam wrote: ... Can anybody explain why is it acceptable to modify a standard for ports but not not for base? I think Standards is a bogus argument here. That's not what this is about. Try this way of looking at it: The author of xpdf wants DRM in the source code. That is his right. Many users find it more useful without it. That is their right. We distribute patches to build a version that disables the DRM that will never be incorporated into the main package. That is our right. The author distributes it the way they wish to, and OpenBSD distributes a patch. Everyone's rights are respected. Author has freedom, users have freedom, OpenBSD has freedom. The authors of OpenSSH don't want to hide the version. That is their right. A few users think there is benefit in hiding the version. That is their right (you have the right to remain wrong...) Someone distributes a patch that will never go into the OpenSSH code. That is their right. The authors distribute the code they wish to and users can distribute a patch. Everyone's rights are respected. Authors have freedom, users have freedom, patchers have freedom. You see a difference. I see remarkable parallels. This is real freedom in action. What you seem to think is that you get a vote or claim on someone else's work. No, you don't. Not here, at least. OpenBSD decides what is in OpenBSD, The xpdf authors get to decide what is in xpdf, The OpenSSH authors get to decide what is in OpenSSH. And that is how it should be, and that is how it is. YOU get to decide what you wish to use, too. Not if you modify that software away from it's original intention and not tell me about it. Then I don't get to decide. You may use OpenBSD or not. You may use xpdf in patched or unpatched form. Only if I know it's changed. No body seems prepared to tell me you modified it at point of installation. You may or may not respect the wishes of the author of documents you look at with xpdf. wow, you got freedom too. Amazing how this works. :) Think about this: I suspect most developers and users of OpenBSD think the DRM features of xpdf are stupid and annoying..but I bet virtually all of them would fight for the RIGHT of the author to decide to be stupid and annoying, and put whatever they darned well please into their own code. There is a difference between wishing and attempting to persuade someone to do something differently, and demanding or expecting them to do something differently. A very large difference, which is often missed by many. I WISH xpdf didn't have silly DRM stuff in it. I WISH people didn't distribute silly patches for OpenSSH I am glad they can. Nick. -- By reading this note, you agree to not think of a big red bird with fuzzy pink feet. Ian McWilliam
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
Ian McWilliam [EMAIL PROTECTED] writes: The real issue for me at least is the fact that one is prepared to modify (in this case xpdf) away for what ever standard it is written against, modified away from the original software distribution without documenting the change, informing the end user who installs the modified software so they can make an informed decision as to whether they still want to use the modified version or go off and install the unmodified version. I'd call it a sane default. If we made an xpdf-drm FLAVOR of this port, how many people do you think would choose it? Would you?
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On Thu, May 01, 2008 at 08:43:36PM +1000, Ian McWilliam wrote: Finally, some sense, thanks. The real issue for me at least is the fact that one is prepared to modify (in this case xpdf) away for what ever standard it is written against, modified away from the original software distribution without documenting the change, informing the end user who installs the modified software so they can make an informed decision as to whether they still want to use the modified version or go off and install the unmodified version. I don't see any actual reason to have flavors for xpdf. As far as I'm concerned, the drm part is just some bits in the document. This is information, we should display it, let's say add a menu that tells you what protection the document has, possibly add a notice requester that tells you the author didn't intend for you to print the document, asking you for confirmation and... that's it. I only see reasons to tell people they're about to do something that the original author of the document didn't intend them to, and to let them choose what they will do, based on technical possibilities.
Update: security/integrit (3.02.00 - 4.1)
Hi,
here's an update for security/integrit. Apart from switching to RMD-160
for checksums it includes a couple of bug fixes.
In addition to the update I tweaked the port a bit:
- build with SEPARATE_BUILD=simple
- include the (small) test-suite as regression test
- include original install message as pkg/MESSAGE
- install with correct file permissions
- don't install examples to ${SYSCONFDIR}/integrit
Tested with the latest snapshot on i386 and amd64 (both inside qemu) so far.
Regards,
Oliver Klima
Index: Makefile
===
RCS file: /data/cvs/ports/security/integrit/Makefile,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- Makefile1 May 2008 13:39:29 - 1.1.1.1
+++ Makefile1 May 2008 13:47:50 - 1.2
@@ -1,16 +1,14 @@
# $OpenBSD: Makefile,v 1.7 2007/09/15 23:29:58 merdely Exp $
COMMENT= file integrity checker
+CATEGORIES=security
-VERSION= 3.02.00
+VERSION= 4.1
DISTNAME= integrit-${VERSION}
-PKGNAME= ${DISTNAME}p0
-CATEGORIES=security
HOMEPAGE= http://integrit.sourceforge.net/
-MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=integrit/} \
- http://www.noserose.net/e/integrit/download/
+MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=integrit/}
# GPL
PERMIT_PACKAGE_CDROM= Yes
@@ -18,14 +16,11 @@
PERMIT_DISTFILES_CDROM=Yes
PERMIT_DISTFILES_FTP= Yes
-WRKDIST= ${WRKDIR}/${DISTNAME:R}
-
CONFIGURE_STYLE= gnu
+SEPARATE_BUILD=simple
ALL_TARGET=integrit utils
-NO_REGRESS=Yes
-
post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/integrit
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/integrit
@@ -33,5 +28,8 @@
integrit_check viewreport ${PREFIX}/share/doc/integrit
cd ${WRKSRC}/examples ${INSTALL_DATA} *.conf \
${PREFIX}/share/examples/integrit
+
+do-regress:
+ cd ${WRKBUILD} /bin/sh ${WRKSRC}/test/test
.include bsd.port.mk
Index: distinfo
===
RCS file: /data/cvs/ports/security/integrit/distinfo,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- distinfo1 May 2008 13:39:29 - 1.1.1.1
+++ distinfo1 May 2008 13:47:50 - 1.2
@@ -1,5 +1,5 @@
-MD5 (integrit-3.02.00.tar.gz) = Bi2wEWEYcYT3yF91Srb3pQ==
-RMD160 (integrit-3.02.00.tar.gz) = rcB2bbkaPpwz36sNSzmivdtU8uc=
-SHA1 (integrit-3.02.00.tar.gz) = eF07BS7WKsrrXEoWKjDbUOidazE=
-SHA256 (integrit-3.02.00.tar.gz) = xZ4XLpDhcaF13WgLREPNHRXkc9eBsfFQu0d9gpNWm6U=
-SIZE (integrit-3.02.00.tar.gz) = 251649
+MD5 (integrit-4.1.tar.gz) = 9RpbVYmBpdkOfW9OfiaaRg==
+RMD160 (integrit-4.1.tar.gz) = 1WWFycOMLlPxDQrWrvXqkGfd2FI=
+SHA1 (integrit-4.1.tar.gz) = i31sp80UXO/F8XkK8v0zLA8UkX0=
+SHA256 (integrit-4.1.tar.gz) = Kgm2cO4CXW+udW4ET3gMysqQaIqXGDo1CSfjiFF0Ij4=
+SIZE (integrit-4.1.tar.gz) = 271626
Index: patches/patch-Makefile_in
===
RCS file: /data/cvs/ports/security/integrit/patches/patch-Makefile_in,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- patches/patch-Makefile_in 1 May 2008 13:39:29 - 1.1.1.1
+++ patches/patch-Makefile_in 1 May 2008 13:47:52 - 1.2
@@ -1,27 +1,24 @@
$OpenBSD: patch-Makefile_in,v 1.1.1.1 2002/11/17 00:15:19 brad Exp $
Makefile.in.orig Sun Sep 22 04:36:21 2002
-+++ Makefile.inSun Sep 22 04:39:40 2002
+--- Makefile.in.orig Sat Jun 2 23:41:37 2007
Makefile.inThu May 1 13:22:06 2008
@@ -26,7 +26,7 @@ srcdir= @srcdir@
# VPATH= @srcdir@
CC = @CC@
PROG = integrit
-SBINDIR= @sbindir@
-+SBINDIR= ${PREFIX}/sbin
++SBINDIR= $(PREFIX)/sbin
INSTALL= @INSTALL@
OBJ= @OBJ@
ILIBOBJ= @ILIBOBJ@
-@@ -84,9 +84,12 @@ $(srcdir)/dep.mak ::
- fi; \
- done; \
- obj=`echo $$f | sed -e 's/^gnupg\///' -e 's/\.c\$$/.o/'`; \
--printf %s\n\t%s\n \
-+if [ $obj = sha1.o ]; then \
-+ extra_flags=-O0; \
-+fi; \
-+ printf %s\n\t%s\n \
- $$obj : \$${srcdir}/$$f $$hdeps Makefile \
-- ${COMPILE} \$${srcdir}/$$f; \
-+ ${COMPILE} \$${srcdir}/$$f $extra_flags; \
- done dep.mak
-
- include $(srcdir)/dep.mak
+@@ -143,9 +143,9 @@ install : $(PROG)
+ fi
+ @if test ! -d $(SBINDIR); then \
+ echo creating directory $(SBINDIR); \
+-$(INSTALL) -d -m 755 $(SBINDIR); \
++$(INSTALL) -d -m $(DIRMODE) $(SBINDIR); \
+ fi
+- $(INSTALL) $(STRIP) -m 755 $(PROG) $(SBINDIR)/$(PROG)
++ $(INSTALL) $(STRIP) -m $(BINMODE) $(PROG) $(SBINDIR)/$(PROG)
+ @echo
+ @echo 'It is recommended that the
Re: NEW: math/wxMaxima
On Thu, May 1, 2008 at 4:15 PM, Iruata Souza [EMAIL PROTECTED] wrote: wxWidgets GUI for math/maxima. tested on i386. http://iru.oitobits.net/src/openbsd/ports/wxmaxima.tgz needs maxima which needs common lisp. iru
Re: clisp: clx flavor
From: Michael Small [EMAIL PROTECTED] Subject: Re: clisp: clx flavor Date: Wed, 30 Apr 2008 23:11:55 -0400 On Wed, Apr 30, 2008 at 11:12:58PM +0200, fulvio ciriaco wrote: Hallo, I added a clx flavor to clisp, clx is a foreign interface to Xlib allowing for use of X programs in clisp. Stumpwm for example (http://www.nongnu.org/stumpwm/) is a wm running under clisp/sbcl dependent on clx. By the way clisp 2.44.1 is out. Instructions recommend libffcall but I could not find it anywhere. It compiles and runs fine nonetheless. I think that's the package called ffcall under devel. At least I can get fairly far compiling clisp on macppc using that (I'm hitting a stack overflow with a 32M stack). -- Mike Small [EMAIL PROTECTED] You are right in fact, ffcall is what instructions mean. However, though recommended, clisp 2.44.1 does not compile --with-ffcall on openbsd current i386. Undefined references to __va_(all kind of vars) Otherwise it compiles fine --with-gmalloc Fulvio
Re: vlc bug
Hello, I just updated to 4.3 and noticed this odd VLC volume bar visual bug, it's rather distracting... :( -Nix Fan.
current or stable?
I am working on learning how to port, c. and am trying to figure out which flavor of OpenBSD that I need to run. Does it need to be current if I want to help with porting? Sorry if this is somewhere in the documentation. I did not see it clearly in any place that I have read so far. -Dan Daniel Nevistic Electrical Engineering University of Washington 206.818.1127
Re: current or stable?
Daniel Thomas Nevistic wrote: I am working on learning how to port, c. and am trying to figure out which flavor of OpenBSD that I need to run. Does it need to be current if I want to help with porting? If you want a port to be committed, it needs to compile against -current.
Re: current or stable?
On Thu, May 01, 2008 at 05:52:02PM -0700, Daniel Thomas Nevistic wrote: I am working on learning how to port, c. and am trying to figure out which flavor of OpenBSD that I need to run. Does it need to be current if I want to help with porting? You should run -current for working on ports. -ME
Re: current or stable?
On Thu, May 01, 2008 at 05:52:02PM -0700, Daniel Thomas Nevistic wrote:
I am working on learning how to port, c. and am trying to figure
out which flavor of OpenBSD that I need to run. Does it need to
be current if I want to help with porting?
Changes to the ports tree occur in -current, so you should run that
(or snapshots) if you want to test or submit changes.
Sorry if this is somewhere in the documentation. I did not see it
clearly in any place that I have read so far.
The following two links are very useful for ports people:
http://www.openbsd.org/porttest.html
http://www.openbsd.org/checklist.html
The first includes the following in the 'First step' section:
The ports tree is developed against [10]OpenBSD-current; there
is no guarantee that new ports or updates will work correctly on
the other branches. This means you should upgrade your system
and ports tree to -current
--
o--{ Will Maier }--o
| web:...http://www.lfod.us/ | [EMAIL PROTECTED] |
*-[ BSD: Live Free or Die ]*
Re: NEW (again): x11/tcltutor
A happy porting story: When I was working on this port I asked the author about the license. He informed me that not only was he going to release a new version of TclTutor, he was also changing the license to a BSD-style license. I looked at the license ... it was OK, not great ... there was some government clause at the end that bothered me. I suggested, since he was already switching licenses, to switch to the ISC license. He agreed. So now a new port! Tcltutor 3b1 Obvious improvements over version 2b4: - Nicer GUI - Lessons also available in Portuguese - ISC license One more reason to stop putting off learning Tcl! ;) Stu tcltutor-3b1-port.tar.gz Description: application/gzip
NEW: devel/sparse
Here's a port of sparse which I've tested on i386. From pkg/DESCR: Sparse, the semantic parser, provides a compiler frontend capable of parsing most of ANSI C as well as many GCC extensions, and a collection of sample compiler backends, including a static analyzer also called sparse. Sparse provides a set of annotations designed to convey semantic information about types, such as what address space pointers point to, or what locks a function acquires or releases. patch has been uploaded here: http://www.dickman.org/openbsd/ports/ports_devel_sparse_0.4.1.patch
