Re: Python versions, Zope and, Python modules
* Ingo Schwarze [2007-11-13]: > Consistent naming schemes are nice to have. Yes, but we don't have a consistent base to start with... > On the other hand, regarding FLAVORS, aren't they intended for > packages having common basic technology (which is not the case here as > we are using different platforms to start from) and different optional > functionality (which is also not the case here, py-foo will usually do > the same no matter which version of Python is involved). Besides, in > my understanding, choosing one and only one of several available > FLAVORS at install time is central to the whole concept of FLAVORS, > not only technically, but also logically. In my understanding, FLAVORS just differentiate packages built from the same source with different compile time options (i.e. you have to build them twice), just as is the case here: one module source compiled with different versions of python. That's the reason why I want this problem solved with FLAVORS. SUBPACKAGES on the other hand are just used to split files and simplify dependencies (i.e. one build to package them all ;). Nikolay -- "It's all part of my Can't-Do approach to life." Wally
Re: [NEW} GAMMApage-0.5
On Mon, 12 Nov 2007, Antoine Jacoutot wrote: pkg/DESCR GAMMApage is a gamma-adjusting utility for your monitor. It is able to adjust gamma on the fly and save settings to be used at each login (on a per-user basis, GAMMApage will only write to the user's home directory). Comments? OK? Works with quite light testing. I liked the "help" section of the tool. -- Antti Harri
Re: Python versions, Zope and, Python modules
> NetBSD apparently uses the latter, using py23-, py24- etc. This proposal reminds me of p5-* and php5-*. Consistent naming schemes are nice to have. On the other hand, regarding FLAVORS, aren't they intended for packages having common basic technology (which is not the case here as we are using different platforms to start from) and different optional functionality (which is also not the case here, py-foo will usually do the same no matter which version of Python is involved). Besides, in my understanding, choosing one and only one of several available FLAVORS at install time is central to the whole concept of FLAVORS, not only technically, but also logically. *IF* some Python port differs for various versions of Python, shouldn't we then regard it as two different ports, just like we regard two programs written in different programming languages as different ports, even if they happen to solve identical tasks?
Re: [NEW} GAMMApage-0.5
On Mon, Nov 12, 2007 at 04:34:36PM +0100, Antoine Jacoutot wrote: > pkg/DESCR > GAMMApage is a gamma-adjusting utility for your monitor. It is able to > adjust gamma on the fly and save settings to be used at each login (on > a per-user basis, GAMMApage will only write to the user's home > directory). > > > Comments? OK? Nice! Works fine under amd64. > > -- > Antoine
[NEW} GAMMApage-0.5
pkg/DESCR GAMMApage is a gamma-adjusting utility for your monitor. It is able to adjust gamma on the fly and save settings to be used at each login (on a per-user basis, GAMMApage will only write to the user's home directory). Comments? OK? -- Antoine gammapage.tar.gz Description: Binary data
Handelsvertreter......
Sehr geehrte Damen und Herren, für den Neuaufbau eines Vertriebes, suchen wir Führungskräfte für Deutschland, Österreich und Polen. NWSS - das Unternehmen Hinter NWSS stehen 25 Jahre Unternehmens-Erfahrung. NWSS startet den europaweiten Vertrieb von innovativen Telematik-Ortungssystemen. Damit können Personen und Fahrzeuge weltweit und punktgenau geortet werden. Die Technik bezieht NWSS direkt von einem der führenden Hersteller in Deutschland. Referenzen Die einzigartigen Ortungssysteme unseres Herstellers werden heute schon in die großen Limousinen von BMW, Audi, Mercedes, Jaguar eingebaut (Stand nur 2007: ca. 22.000 Einheiten). Die Abteilung für organisierte Kriminalität (OK) testet derzeit in Deutschland die Geräte. In der Türkei ist es mittlerweile Pflicht, das System in jedes Taxi einzubauen. NWSS liefert damit Hightech und Sicherheit mit Ihnen gemeinsam an jeden Kunden. Der Markt - Hightech und Sicherheit für jeden In Deutschland sind zur Zeit ca. 1650 Kinder vermisst. Mehr als 200 000 Kinder werden jedes Jahr sexuell missbraucht, schätzen Experten. NWSS-Technik schützt nicht nur Kinder. Auch Senioren, Sportlern, Motorrad- und Autofahrern bieten unsere Produkte ein Höchstmaß an Komfort, Ersparnisse und Sicherheit. Das System Der Clou ist die punktgenaue Ortung von Personen, die mit NWSS-Technik ausgerüstet sind. Alle Geräte verfügen über eine Alarm-Taste. Einmal gedrückt und innerhalb von Sekunden wird die Rettungskette punktgenau in Gang gesetzt. 365 Tage im Jahr, 24 Stunden am Tag. Karriere 2007 - Ihre Möglichkeiten wir bieten: * Vertriebsrechte der NWSS-Produkte europaweit * breite Zielgruppe im privaten und gewerblichen Bereich * professionelle Ausbildung und Unterstützungstools für das Produktangebot * eigene Homepage und personalisiertes Abrechnungssystem * lukrative, leistungsbezogene Vergütung von Anfang an (14-tägige Auszahlung) * Erfolgs- und Umsatzbeteiligung * Sondervereinbarungen für Teamleiter und Führungskräfte wir erwarten: * Erfahrung im Außendienst / Vertrieb * sicheres und kundenorientiertes Auftreten * hohe Leistungsbereitschaft, * selbständiges und unternehmerisches Denken * Mobilität, Lernbereitschaft und Kreativität Bitte rufen Sie uns an unter: 036969-54959 oder senden Sie uns eine Mail an: [EMAIL PROTECTED] Hans Peter Tkany www.hptconsulting.de http://www.xing.com/go/invite/7028732.f056b2
Re: Python versions, Zope and, Python modules
Joerg Zinke wrote: [...] Python can co-exist in different versions at the same time. Why should that not be possible for site-packages with our ports tree? ACK, would be nice to be able install ports for different python versions. Maybe this issue could be solved by improving python.port.mk with a additional variable which results in multiple install destinations for the different versions or something like that: PY_VERSIONS=2.3 2.4 2.5 in every python port. that still leaves a few questions: - how do we encode the version in the package name? - we must make sure that the packages do not conflict. some python packages have stuff in their PLIST that _will_ conflict, like documentation or examples. The ports need to be changed to put that in a subpackage. Maybe a suffix would be a solution, e.g. for package in version 1.2: somepkg-1.2-python23.tgz somepkg-1.2-python24.tgz somepkg-1.2-python25.tgz somepkg-1.2-common.tgz At would at least not conflict to much with how we name FLAVORS. regards, joerg - Marc
Re: Python versions, Zope and, Python modules
On Mon, 12 Nov 2007 12:38:28 +0100 Marc Winiger <[EMAIL PROTECTED]> wrote: > Marc Balmer wrote: > > Everyone interested in Zope (and Plone), please take a look at > > this. I am totally open for better solutions. > > IMO everyone using python should be interessted. Why is python > maintained in different versions, while site-packages can only be > used with one version? good question! :) > Python can co-exist in different versions at the same time. Why > should that not be possible for site-packages with our ports tree? ACK, would be nice to be able install ports for different python versions. Maybe this issue could be solved by improving python.port.mk with a additional variable which results in multiple install destinations for the different versions or something like that: PY_VERSIONS=2.3 2.4 2.5 in every python port. regards, joerg
Re: Python versions, Zope and, Python modules
Nikolay Sturm wrote: * Marc Winiger [2007-11-12]: Python can co-exist in different versions at the same time. Why should that not be possible for site-packages with our ports tree? Which is exactly the question Espie has to answer, but is currently too busy to do. So why don't we all just wait and maybe poke a little in his general direction. ;) Well, while we wait and poke we can look at the options we have. To have packages for the different Python versions, the must differ in the name. That could be a suffix (FLAVOR style) or a different prefix. NetBSD apparently uses the latter, using py23-, py24- etc. If the different packages are FLAVORS, the conflict management must at the moment be done in the PLIST "by hand". And at the moment, it does not work at all for FLAVORS. That would have to be changed somehow in the pkg_tools. Maybe something like '@option no-flavor-conflict ' in the PLIST could be used to tell the tools that the FLAVORs do not conflict. Using different prefixes (the NetBSD way), the default rules do apply and no changes are needed. - Marc
NEW: net/daemonlogger
COMMENT=packet logger and soft tap This is a libpcap-based program. It has two runtime modes: 1) It sniffs packets and spools them straight to the disk and can daemonize itself for background packet logging. By default the file rolls over when 1 GB of data is logged. 2) It sniffs packets and rewrites them to a second interface, essentially acting as a soft tap. It can also do this in daemon mode. These two runtime modes are mutually exclusive, if the program is placed in tap mode (using the -I switch) then logging to disk is disabled. http://secure.lv/~nikns/stuff/ports/daemonlogger-1.0.1.tar - # daemonlogger -i msk0 -s `expr 1024 \* 1024` -l /tmp/logs/ [-] Interface set to msk0 [-] Rollover size set to 1048576 bytes [-] Logpath set to /tmp/logs/ -*> DaemonLogger <*- Version 1.0.1 By Martin Roesch (C) Copyright 2006-2007 Sourcefire Inc., All rights reserved sniffing on interface msk0 Logging packets to /tmp/logs//daemonlogger.pcap.1194876457 Rolling over logfile... Logging packets to /tmp/logs//daemonlogger.pcap.1194876569 Rolling over logfile... Logging packets to /tmp/logs//daemonlogger.pcap.1194876674 daemonlogger-1.0.1.tar Description: Unix tar archive
Re: Python versions, Zope and, Python modules
* Marc Winiger [2007-11-12]: > Python can co-exist in different versions at the same time. Why should > that not be possible for site-packages with our ports tree? Which is exactly the question Espie has to answer, but is currently too busy to do. So why don't we all just wait and maybe poke a little in his general direction. ;) Nikolay
Re: NEW: devel/cln
On Mon, Nov 12, 2007 at 12:25:08PM +0100, Steven Mestdagh wrote:
> Paul Irofti [2007-11-11, 04:47:58]:
> > On Thu, Nov 08, 2007 at 08:53:21PM +0100, Steven Mestdagh wrote:
> > > > > This is a required lib in order to port GiNaC that will add symbolic
> > > > > algebra support to octave.
> > > > >
> > > > > There is a `gmake test' target and all tests have passed.
> > > > >
> > > > > Tested on amd64.
> > > > >
> > > > > pkg/DESCR:
> > > > > [--snip--]
> > > > > CLN is a C++ library providing the following features:
> > > > >
> > > > > * Rich set of number classes:
> > > > > Integer (unlimited precision), rational, short float, single
> > > > > float, double float, long float (unlimited precision), complex,
> > > > > modular integer, univariate polynomial.
> > > > > * Elementary, logical, transcendental functions.
> > > > > * C++ as implementation language brings
> > > > > o efficiency,
> > > > > o type safety,
> > > > > o algebraic syntax.
> > > > > * Memory efficiency:
> > > > > o Small integers and short floats are immediate, not heap
> > > > > allocated.
> > > > > o Automatic, non-interruptive garbage collection.
> > > > > * Speed efficiency:
> > > > > o Assembly language kernel for some CPUs,
> > > > > o Karatsuba and Sch?nhage-Strassen multiplication.
> > > > > * Interoperability:
> > > > > o Garbage collection with no burden on the main application,
> > > > > o hooks for memory allocation and exceptions.
> > > > > [--snip--]
> > > >
> > > > Fixed SHARED_LIBS, resubmitting...
> > >
> > > looks like this can make use of the gmp library.
> > > maybe you can look into that?
> >
> > Resubmit, thanks for the guidance.
>
> I get a compilation error on sparc64.
>
> /usr/local/bin/libtool --mode=compile c++ -O2 -pipe -Wformat -Wbounded
> -I/usr/local/include -I../include -I../include -I./base -I./base/digit
> -I./base/random -Ibase -c ./base/digitseq/cl_DS_mul.cc
> c++ -O2 -pipe -Wformat -Wbounded -I/usr/local/include -I../include
> -I../include -I./base -I./base/digit -I./base/random -Ibase -c
> ./base/digitseq/cl_DS_mul.cc -fPIC -DPIC -o .libs/cl_DS_mul.o
> base/digitseq/cl_DS_mul.cc: In function `cl_boolean
>cln::cl_fftm_suitable(unsigned int, unsigned int)':
> base/digitseq/cl_DS_mul.cc:364: error: invalid `asm': operand number missing
>after %-letter
> {standard input}: Assembler messages:
> {standard input}:3030: Error: Illegal operands: unrecognizable v9a or v9b
> ancillary state register
>
I had never dealt with SPARC and thus have very little knowledge in its
regards. But from your compile errors and through the bless of grep I
think I found your problem. It was a missing '%'.
I resubmitted the port with a patch for your issue. Please tell me how
it went.
cln-1.1.13.tgz
Description: application/tar-gz
Re: [update] x11vnc 0.9.3
On Sat, Nov 10, 2007 at 11:59:46AM +, jirib wrote: >Mike Erdely erdelynet.com> writes: > >> >> I've started working on an update to x11vnc. >> I've tested it on i386 and on two different systems, I've had it crash >> X11 on me when the client disconnects. I haven't had more time to look >> at it since. > >I think 'crashing X11' is normal, check --help :) > >-once Exit after the first successfully connected viewer > disconnects, opposite of -forever. This is the Default. > Tested on amd64, -forever prevents x11vnc to exit as stated in --help. >Bye > >jirib >
Re: Python versions, Zope and, Python modules
On 11/12/07, Marc Balmer <[EMAIL PROTECTED]> wrote: > If I can't get an OK for this or if there is no better proposal (just > saying this is not nice is not an alternative, imo ;) then I will have > to move Zope and friends to an internal CVS. That would leave Zope in > OpenBSD unmaintained (and unusable), so this is definitely _THE LAST > RESORT ONLY_ But since naddy already mentioned that Zope and Plone > should go down the curbe, I will eventually do it. > > Everyone interested in Zope (and Plone), please take a look at this. I > am totally open for better solutions. > Well, I am, but its at the moment not possible to me to test things at -current. I will try to make an effort to change this, hold on a litte bit, you will get some feedback within two weeks. --knitti
Re: Python versions, Zope and, Python modules
Marc Balmer wrote: Everyone interested in Zope (and Plone), please take a look at this. I am totally open for better solutions. IMO everyone using python should be interessted. Why is python maintained in different versions, while site-packages can only be used with one version? Python can co-exist in different versions at the same time. Why should that not be possible for site-packages with our ports tree? Marc
Re: NEW: devel/cln
Paul Irofti [2007-11-11, 04:47:58]:
> On Thu, Nov 08, 2007 at 08:53:21PM +0100, Steven Mestdagh wrote:
> > > > This is a required lib in order to port GiNaC that will add symbolic
> > > > algebra support to octave.
> > > >
> > > > There is a `gmake test' target and all tests have passed.
> > > >
> > > > Tested on amd64.
> > > >
> > > > pkg/DESCR:
> > > > [--snip--]
> > > > CLN is a C++ library providing the following features:
> > > >
> > > > * Rich set of number classes:
> > > > Integer (unlimited precision), rational, short float, single
> > > > float, double float, long float (unlimited precision), complex,
> > > > modular integer, univariate polynomial.
> > > > * Elementary, logical, transcendental functions.
> > > > * C++ as implementation language brings
> > > > o efficiency,
> > > > o type safety,
> > > > o algebraic syntax.
> > > > * Memory efficiency:
> > > > o Small integers and short floats are immediate, not heap
> > > > allocated.
> > > > o Automatic, non-interruptive garbage collection.
> > > > * Speed efficiency:
> > > > o Assembly language kernel for some CPUs,
> > > > o Karatsuba and Sch?nhage-Strassen multiplication.
> > > > * Interoperability:
> > > > o Garbage collection with no burden on the main application,
> > > > o hooks for memory allocation and exceptions.
> > > > [--snip--]
> > >
> > > Fixed SHARED_LIBS, resubmitting...
> >
> > looks like this can make use of the gmp library.
> > maybe you can look into that?
>
> Resubmit, thanks for the guidance.
I get a compilation error on sparc64.
/usr/local/bin/libtool --mode=compile c++ -O2 -pipe -Wformat -Wbounded
-I/usr/local/include -I../include -I../include -I./base -I./base/digit
-I./base/random -Ibase -c ./base/digitseq/cl_DS_mul.cc
c++ -O2 -pipe -Wformat -Wbounded -I/usr/local/include -I../include
-I../include -I./base -I./base/digit -I./base/random -Ibase -c
./base/digitseq/cl_DS_mul.cc -fPIC -DPIC -o .libs/cl_DS_mul.o
base/digitseq/cl_DS_mul.cc: In function `cl_boolean
cln::cl_fftm_suitable(unsigned int, unsigned int)':
base/digitseq/cl_DS_mul.cc:364: error: invalid `asm': operand number missing
after %-letter
{standard input}: Assembler messages:
{standard input}:3030: Error: Illegal operands: unrecognizable v9a or v9b
ancillary state register
Re: Cannot update "/usr/local/share/ghostscript/fonts" as message displays after xpdf install. It is a directory and not a file
On Nov 11, 2007 11:26 PM, Matthias Kilian <[EMAIL PROTECTED]> wrote: > On Sun, Nov 11, 2007 at 09:06:33PM +0530, Siju George wrote: > > Could somebody tell me where I should put the above mentioned FontPath > > lines? > > /etc/X11/xorg.conf > Thanks Kili :-) --Siju
Re: Python versions, Zope and, Python modules
Marc Balmer wrote:
Python and Python ports have been changed to use 2.5 as the default
version. This brings Zope users into trouble:
Maybe I must use a bit more drastic verbiage: Zope is not usable
anymore. For database adapters like py-psycopg or ldap adapters like
zope-ldapuserfolder, needed packages are no longer built.
About the only feedback I got was from Nikolay, who thinks my fix is not
nice. Marc Espie did not explain why @option no-default-conflict does
not work anymore for FLAVORS (and this is the reason why I had to change
the name stem). And I asked him several times.
I need to move forward with this in some or the other way quite soon,
because I run my servers on -current, to catch problems like this one
early on and not at release time.
If I can't get an OK for this or if there is no better proposal (just
saying this is not nice is not an alternative, imo ;) then I will have
to move Zope and friends to an internal CVS. That would leave Zope in
OpenBSD unmaintained (and unusable), so this is definitely _THE LAST
RESORT ONLY_ But since naddy already mentioned that Zope and Plone
should go down the curbe, I will eventually do it.
Everyone interested in Zope (and Plone), please take a look at this. I
am totally open for better solutions.
Zope still requires Python 2.4 to run. While it is no problem to
install Python 2.4 and Python 2.5 in parallel, some Python modules that
are needed by Zope only get built for Python 2.5.
For example, www/zope-ldapuserfolder set MODULES=www/zope and a
RUN_DEPENDS on databases/py-ldap. Of course the zope, py-ldap, and
zope-ldapuserfolder packages are build and the package tools will not
complain. _But_ py-ldap gets built using Python 2.5 and the other
two using Python 2.4 (as is needed by Zope). And then, when you
use the software you will notice that the py-ldap package installed
it's files into /usr/local/lib/python2.5/... whereas the other packages
installed the files under /usr/local/lib/python2.4.
The solution is surprisingly simple:
- Add a python2.4 PSEUDO_FLAVOR for databases/py-ldap. We choose to
alter the package name to py24-ldap so it does not conflict with
py-ldap (as flavors seem to conflict by default).
- Factor out Example code from py-ldap into a subpackage
py-ldap-examples.
- Have www/zope-ldapuserfolder depend on py24-ldap instead of py-ldap
We will have to use this scheme for some more packages, like database
adapters and such.
ok?
Index: databases/py-ldap/Makefile
===
RCS file: /cvs/ports/databases/py-ldap/Makefile,v
retrieving revision 1.15
diff -u -r1.15 Makefile
--- databases/py-ldap/Makefile 8 Oct 2007 08:22:39 - 1.15
+++ databases/py-ldap/Makefile 2 Nov 2007 15:26:53 -
@@ -1,12 +1,15 @@
# $OpenBSD: Makefile,v 1.15 2007/10/08 08:22:39 steven Exp $
-SHARED_ONLY= Yes
+SHARED_ONLY= Yes
-COMMENT= LDAP client API for Python
+COMMENT-main= LDAP client API for Python
+COMMENT-examples= example programs for the LDAP client API for Python
+
+V= 2.2.0
+DISTNAME= python-ldap-${V}
+PKGNAME-main= py-ldap-${V}p1
+FULLPKGNAME-examples= py-ldap-examples-${V}
-V= 2.2.0
-DISTNAME= python-ldap-${V}
-PKGNAME= py-ldap-${V}p0
CATEGORIES=databases
HOMEPAGE= http://python-ldap.sourceforge.net/
@@ -25,6 +28,16 @@
LIB_DEPENDS= ldap_r.>=7,lber.>=7::databases/openldap \
sasl2.>=2::security/cyrus-sasl2
+
+PSEUDO_FLAVORS=python2.4 # Needed for Zope, e.g.
+FLAVOR?=
+
+MULTI_PACKAGES=-main -examples
+
+.if ${FLAVOR:L:Mpython2.4}
+MODPY_VERSION= 2.4
+PKGNAME-main= py24-ldap-${V} # To avoid conflicts
+.endif
MODULES= lang/python
Index: databases/py-ldap/pkg/DESCR
===
RCS file: databases/py-ldap/pkg/DESCR
diff -N databases/py-ldap/pkg/DESCR
--- databases/py-ldap/pkg/DESCR 18 Dec 2004 14:28:35 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,14 +0,0 @@
-python-ldap provides an object-oriented API to access LDAP
-directory servers from Python programs. Mainly it wraps the
-OpenLDAP 2.x libs for that purpose.
-
-Additionally the package contains modules for other LDAP-related
-stuff (e.g. processing LDIF, LDAPURLs, LDAPv3 sub-schema, etc.).
-
-Not included: Direct BER support
-
-Quick usage example:
-import ldap
-l = ldap.open("my_ldap_server.my_domain")
-l.simple_bind_s("","")
-l.search_s("o=My Organisation, c=AU", ldap.SCOPE_SUBTREE, "objectclass=*")
Index: databases/py-ldap/pkg/DESCR-examples
===
RCS file: databases/py-ldap/pkg/DESCR-examples
diff -N databases/py-ldap/pkg/DESCR-examples
--- /dev/null 1 Jan 1970 00:00:00 -
+++ databases/py-ldap/pkg/DESCR-examples2 Nov 2007 15:26:53 -
@@ -0,0 +1,2 @@
+Example progra
Ndd vérification
Bonjour, Suite àla libéralisation de lâÂÂextension française, vous avez probablement réservé votre nom de domaine en .FR Vérifiez dès àprésent la disponibilité de votre extension en .COM ou .EU, et protégez efficacement votre adresse Internet. Dans lâÂÂattente dâÂÂun prochain contact, Veuillez accepter mes sincères salutations. Marie-thé Robin Responsable Développement www.nom-domaine.fr Ne plus recevoir d'information de notre part, suivez le lien.
