Re: TeTeX and TeXLive
Le 14/12/2007 à 08:58:45+0100, Christian Walther a écrit > Hi, > > On 14/12/2007, Nikola Le?i? <[EMAIL PROTECTED]> wrote: > > On Fri, 14 Dec 2007 02:24:09 +0100 > > Albert Shih <[EMAIL PROTECTED]> wrote: > > > > > I'm just want known if there are any plan to replace teTeX ports (the > > > project as stop) by TeXLive ? > > > > > > I've send long time ago a mail to teTeX maintainer and I don't have > > > any answer. > > > > "Me too." > > > > I must add that I tried two times to contact two FreeBSD developers who > > (according to the public sources) seemed to be interested in this; > > never got a single word of reply. Having in mind that I offered a help, > > some experience and maintaining/testing availability, I can't > > understand this. It's very discouraging. > > Some time ago I asked which TeX-Port would be the best, LaTeX oder > teTeX. People here on this list recommended teTeX. I think there are some misunderstanding. teTeX is a distrubition, latex is a command. tex, latex, pdftex, pdflatex, etc is set of command and all of this command need many files (~15000 files). If you like it's like a Linux, gcc is part of Linux, but gcc is not Linux. And the are many linux distribution (Debian, Fedora etc..). But actually there only one distribution and it's TexLive. The teTeX project is ended by the author. And as like a Linux distribution you can use it event it's not up2date, but after sometime, depend the speed of the evolution, you need a new distribution. tex/latex don't evolve very fast, that's not mean it's never change. Actually I think it's not a problem to use teTeX. But IMHO it's the best interest of all FreeBSD user to have soon TexLive instead teTeX > TeXLive came up, too, and AFAIK there is work being done to include it > in the ports system. But TeXLive is a distribution that contains loads > of stuff that isn't needed with FreeBSD, and some parts don't fir into don't needed by youbut maybe needed by some others. > a FreeBSD system. So there's lots of work to be done and TeXLive can't > be expected anytime soon. Of course it's what I want to say. There's lots of work and teTeX is ended in may 2006. Regards. -- Albert SHIH Observatoire de Paris Meudon SIO batiment 15 Heure local/Local time: Ven 14 déc 2007 09:35:16 CET ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TeTeX and TeXLive
Albert Shih wrote: > I'm just want known if there are any plan to replace teTeX ports (the > project as stop) by TeXLive ? > > I've send long time ago a mail to teTeX maintainer and I don't have any > answer. > > I known that's nothing urgent, but without tex the live is hard ;-) Well, TeX itself is frozen since many years, so the differences between TeTeX and TeXLive are of the order of the infinitesimal. It is not like you could not do "happy texing" using TeTeX. Of course the migration to TeXLive will have to occur but i understand that it is not an ultra hot priority. Personnally i would be happier with a distribution much lighter than TeTeX, i think the only progress of any interest in all that stuff is pdftex. If only i could put Latex2e in the trash can ... -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Possibly unbuildable ports reminder
Dear porters, This is just a reminder to please periodically check the list of unbuildable ports at http://pointyhat.freebsd.org/errorlogs/ . A list by MAINTAINER is http://people.freebsd.org/~fenner/errorlogs/ so you can easily check the status of ports that you maintain. In addition, the list of ports with no MAINTAINER with build problems is http://people.freebsd.org/~fenner/errorlogs/[EMAIL PROTECTED] Since no one is responsible for these ports, the problem won't get fixed unless someone on this list takes the initiative. Thanks for your help! Bill "annoying port email" Fenner ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
On Friday 14 Dec 2007, [EMAIL PROTECTED] wrote: > I was not planning to skimp on the requirements at all but the test > case is xorg. A far better test case, IMHO, would be to run a similar build to the pointyhat cluster if you're serious about *replacing* the ports system. Unless a new system can do this, as well as being able to produce packages for a centralised port build system for multiple machines (yes, you can do this with NFS and a little thought), the metaphor "snowball in hell" springs to mind. The job you've given yourself is an elephant. I'll leave it up to others to decide if it's white or just too large to eat on your own all at once. Furthermore, if said elephant isn't consumed in its entirety, expect some resistance to your proof of concept code from some unexpected sources since the ports system isn't just the package management system some people seem to think it is. Looking at all this from a user's perspective is fine and dandy until you have a release to do. The ports are tied into bits of the base system in various ways, for example, make release or USE_OPENSSL=base. The current system, although appearing to drip with legacy methods and what look like arcane rituals to appease the make god (until you understand how it all fits together), is very powerful - perhaps more so than any other package managment system I've ever used - and is structured to work for end users, the release engineering and ports management teams. I suspect this is why so many @FreeBSD.org replies were negative. I don't wish to rock the boat and start another 8 kids 1 toy discourse and there is certainly no malice or insult intended, but the ports system is so much more than getting X installed on a desktop box. First and foremost, release engineering depends on it. Change can be good, but always remember the alternate definition of progress: Taking the best of what you have. And ruining it. -- Matt Dawson. [EMAIL PROTECTED] MTD15-RIPE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Dawson wrote: > On Friday 14 Dec 2007, [EMAIL PROTECTED] wrote: >> I was not planning to skimp on the requirements at all but the test >> case is xorg. > > A far better test case, IMHO, would be to run a similar build to the pointyhat > cluster if you're serious about *replacing* the ports system. Unless a new > system can do this, as well as being able to produce packages for a > centralised port build system for multiple machines (yes, you can do this > with NFS and a little thought), the metaphor "snowball in hell" springs to > mind. In the parlance of testing I consider xorg to be a large but basically a unit test. It has the following advantages: 1. Just enough external depends to not make it completely trivial (thus ideal for a unit style test) 2. Certain ports with in the system behave different depending on the order stuff is built in thus this serves as a good proof that DAG scanning is working on a non-trivial DAG 3. Unlike attempting to build the entire ports collection it is a relatively stable target (again an other key requirement for a unit test) Once xorg works correctly I will consider the new system to be alpha for the purposes of scaling it up to a static build of the whole ports system (alpha2) and finally the beta is doing it against a non-static ports system (i.e. having the two systems track each other). So when I said release I did not mean entery into production I just meant complete enough to allow non-core developer use. The idea is except for handling special cases as gracefully as possible the system is complete after xorg and special cases is where it becomes larger then what a small team of 1 or 2 people can handle. This does not preclude refactoring on behalf of the core team to make it so there as few special cases as possible. > > The job you've given yourself is an elephant. I'll leave it up to others to > decide if it's white or just too large to eat on your own all at once. > Furthermore, if said elephant isn't consumed in its entirety, expect some > resistance to your proof of concept code from some unexpected sources since > the ports system isn't just the package management system some people seem to > think it is. Proof of concept is a little stronger then how I would describe it. > > Looking at all this from a user's perspective is fine and dandy until you have > a release to do. The ports are tied into bits of the base system in various > ways, for example, make release or USE_OPENSSL=base. The current system, > although appearing to drip with legacy methods and what look like arcane > rituals to appease the make god (until you understand how it all fits > together), is very powerful - perhaps more so than any other package > managment system I've ever used - and is structured to work for end users, > the release engineering and ports management teams. I suspect this is why so > many @FreeBSD.org replies were negative. The general model I have in mind more then enough accounts for this interplay... but this entire discussion is getting ahead of the project we still don't have a clear idea of the project scope. > > I don't wish to rock the boat and start another 8 kids 1 toy discourse and > there is certainly no malice or insult intended, but the ports system is so > much more than getting X installed on a desktop box. First and foremost, > release engineering depends on it. Change can be good, but always remember > the alternate definition of progress: Taking the best of what you have. And > ruining it. I understand this completely (one reason I am doing this is I am working on a commerical OS that will need near equivelent functionality and this is the perfect way to prototype the concepts without creating a all or nothing risk [i.e. FreeBSD can always fall back on the current system where is the OS I am working for all intensive purposes will be stuck with what ever solution is implemented on it]). X is really nothing more then a large scale unit test. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYmbMzIOMjAek4JIRAtiwAJ9EsK2iBDmwqlr2DoZrJzedqwjeXACgpiGk LVPJXVFIZgwYWd0XBt7s0zo= =uqaP -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
make config-conditional recursive ?
Is make config-conditional recursive ? If not, shouldn't there be something like config-conditional-recursive ? My idea is to run something like the following to configure ports before upgrading a significant number of them: portupgrade -n -B 'make config-conditional' pkg1 pkg2 ... -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multimedia/mplayer doesn't build (default options)
I can confirm same error here. 6.2-STABLE FreeBSD 6.2-STABLE #76: Fri Sep 21 11:42:26 PDT 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PCBSD-SMP i386 On Dec 13, 2007 1:21 PM, Dominic Fandrey <[EMAIL PROTECTED]> wrote: > cc -O2 -pipe -march=pentium4 -O3 -ffast-math -fomit-frame-pointer > -I./libavcodec -I./libavformat -Wdisabled-optimization -Wno-pointer-sign > -Wdeclaration-after-statement -I. -I. -I./libavutil -O2 -pipe > -march=pentium4 > -O3 -ffast-math -fomit-frame-pointer -D_LARGEFILE_SOURCE > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H > -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/local/include > -I/usr/local/include/SDL -I/usr/local/include -D_REENTRANT > -I/usr/local/include/freetype2 -I/usr/local/include -D_THREAD_SAFE > -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include > -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo > -I/usr/local/include/pango-1.0 -I/usr/local/include > -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include > -I/usr/local/include/freetype2 -I../libavcodec -I../libavformat > -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement > -I. > -I.. -I../libavutil -O2 -pipe -march=pentium4 -O3 -ffast-math > -fomit-frame-pointer -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H -I/usr/local/include/freetype2 > -I/usr/local/include -I/usr/local/include -I/usr/local/include/SDL > -I/usr/local/include -D_REENTRANT -I/usr/local/include/freetype2 > -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include/gtk-2.0 > -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/atk-1.0 > -I/usr/local/include/cairo -I/usr/local/include/pango-1.0-I/usr/local/include > -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include > -I/usr/local/include/freetype2 -c -o ad_libvorbis.o ad_libvorbis.c > ad_libvorbis.c: In function 'decode_audio': > ad_libvorbis.c:232: warning: passing argument 2 of 'ds_get_packet_pts' > from > incompatible pointer type > ad_libvorbis.c:238: error: too few arguments to function > 'vorbis_synthesis' > gmake[1]: *** [ad_libvorbis.o] Error 1 > gmake[1]: Leaving directory > `/usr/obj/homeKamikaze.norad/usr/ports/multimedia/mplayer/work/MPlayer- > 1.0rc2/libmpcodecs' > gmake: *** [libmpcodecs/libmpcodecs.a] Error 2 > *** Error code 2 > > Stop in /usr/ports/multimedia/mplayer. > *** Error code 1 > > Stop in /usr/ports/multimedia/mplayer. > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- --I'm not 'renting' my OS-- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
--On Friday, December 14, 2007 12:19:06 + RW <[EMAIL PROTECTED]> wrote: On Thu, 13 Dec 2007 22:34:58 -0500 "Aryeh M. Friedman" <[EMAIL PROTECTED]> wrote: Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on "abc", but causes lock-ups on "def" SInce I've already killfiled Aryeh, I can only infer what you are responding to and respond to him. But let me state this emphatically in the hopes it will get through his thick skull. IT IS NOT THE JOB OF PORTS TO MAKE DECISIONS FOR USERS. Please repeat that one hundred times until it gets through. No port should *ever* make decisions on a users behalf. Suggestions, yes (e.g. OPTIONS that are enabled by default.) Decisions, no. If you depend on another port *and* on certain knobs in that dependency being enabled, then *tell* the user that during your port's install and let them decide how to handle it. DO NOT enable those knobs yourself, no matter how tempting it may be. It is beyond impossible for anyone to know what every user who is installing ports already has on their boxes or what they might want to add or ***what you might break***. Once you begin making decisions for them, you could well stomp all over something that was functioning perfectly normally and break a critical box. DON'T DO IT. That is so Microsoftian it's not funny. -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
On Thu, 13 Dec 2007 22:34:58 -0500 "Aryeh M. Friedman" <[EMAIL PROTECTED]> wrote: > Namely if I build abc with options 123 and 345 and > def with 345 and 678 then 345 will be cached for def since we already > set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on "abc", but causes lock-ups on "def" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Hosting for a FreeBSD port
Hello porters, I would like to find a hosting for small port. I thought, I can I place it to ftp.freebsd.org (the handbook mentions this possibility), I tried contacting mirror-admin@ and got no reponse. Regards, Igor. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make config-conditional recursive ?
On Fri, 14 Dec 2007 15:57:12 +0200 Andriy Gapon <[EMAIL PROTECTED]> wrote: > > Is make config-conditional recursive ? No, but config-recursive is conditional ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
On Friday 14 December 2007 08:08:54 Paul Schmehl wrote: > --On Friday, December 14, 2007 12:19:06 + RW > > <[EMAIL PROTECTED]> wrote: > > On Thu, 13 Dec 2007 22:34:58 -0500 > > > > "Aryeh M. Friedman" <[EMAIL PROTECTED]> wrote: > >> Namely if I build abc with options 123 and 345 and > >> def with 345 and 678 then 345 will be cached for def since we already > >> set it for abc. > > > > How do you know the user wants 345 set on both ports? > > > > It might be a useful stable feature on "abc", but causes lock-ups on > > "def" > > SInce I've already killfiled Aryeh, I can only infer what you are > responding to and respond to him. But let me state this emphatically in > the hopes it will get through his thick skull. I do wish you could acquire the maturity to distinguish between the advantages that could come arguing your case clearly and collegially and the disadvantages that acrue from being personally antagonistic towards someone with whose analysis you happen to disagree. For me when someone becomes abusive they destroy their own credibility and get to sound as though they believe their opinions antitle them to be hateful and that their own views are somehow godgiven. > IT IS NOT THE JOB OF PORTS > TO MAKE DECISIONS FOR USERS. IMHO Shouting make you less rather than more credible. > \Please repeat that one hundred times until it > gets through. > Endless repetition does not add strength to analysis!! > No port should *ever* make decisions on a users behalf. Suggestions, yes > (e.g. OPTIONS that are enabled by default.) Decisions, no. If you depend > on another port *and* on certain knobs in that dependency being enabled, > then *tell* the user that during your port's install and let them decide > how to handle it. DO NOT enable those knobs yourself, no matter how > tempting it may be. IMHO You would sound more credible if you used the IMHO a bit more!! You might also gain some respect if you followed your own advice. Make suggestions for others to consider - do not decide, in advance, they are thick skulled if they do not agree with you!! > > It is beyond impossible for anyone to know what every user who is > installing ports already has on their boxes or what they might want to add > or ***what you might break***. Once you begin making decisions for them, > you could well stomp all over something that was functioning perfectly > normally and break a critical box. > > DON'T DO IT. That is so Microsoftian it's not funny. IMHO Shouting, hectoring and lecturing does not add weight to anyones point of view. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD Port: dream-1.6.25_1
Hello, I've installed dream from the ports. Under windows I can chose the serial port and the receiver (in my case the elektor drm receiver) and change the frequency. Where can I find this dialog? Regards, Gilles ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TeTeX and TeXLive
On 20071214 09:49:24, Albert Shih wrote: > > I think there are some misunderstanding. teTeX is a distrubition, > latex is a command. > > tex, latex, pdftex, pdflatex, etc is set of command and all of this > command need many files (~15000 files). > > If you like it's like a Linux, gcc is part of Linux, but gcc is not Linux. > And the are many linux distribution (Debian, Fedora etc..). > > But actually there only one distribution and it's TexLive. The teTeX > project is ended by the author. > > tex/latex don't evolve very fast, that's not mean it's never change. > We have to remember, as well, that ConTeXt is also distributed as part of teTeX and the version included (TeXExec 5.2.4 - ConTeXt / PRAGMA ADE 1997-2005) is bordering on the neolithic. As such, it's not really eligble for support (the first thing you'll be told to do is upgrade to a recent version). MM ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 RW wrote: > On Thu, 13 Dec 2007 22:34:58 -0500 "Aryeh M. Friedman" > <[EMAIL PROTECTED]> wrote: > >> Namely if I build abc with options 123 and 345 and def with 345 >> and 678 then 345 will be cached for def since we already set it >> for abc. > > How do you know the user wants 345 set on both ports? > > It might be a useful stable feature on "abc", but causes lock-ups > on "def" There are multiple ways to handle the effects of 345 on def... only one of them is to automatically apply it the other two are def can ignore it by default or make it suer settable -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYucdzIOMjAek4JIRAgBQAJ9NZEM3EoOieFprT+f4LUe/g3GqiQCfT7N6 lW3o2lmL+g5FZk0oUsSZpxA= =nzu2 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Schmehl wrote: > --On Friday, December 14, 2007 12:19:06 + RW > <[EMAIL PROTECTED]> wrote: > >> On Thu, 13 Dec 2007 22:34:58 -0500 "Aryeh M. Friedman" >> <[EMAIL PROTECTED]> wrote: >> >>> Namely if I build abc with options 123 and 345 and def with 345 >>> and 678 then 345 will be cached for def since we already set it >>> for abc. >> >> How do you know the user wants 345 set on both ports? >> >> It might be a useful stable feature on "abc", but causes lock-ups >> on "def" > > SInce I've already killfiled Aryeh, I can only infer what you are > responding to and respond to him. But let me state this > emphatically in the hopes it will get through his thick skull. IT > IS NOT THE JOB OF PORTS TO MAKE DECISIONS FOR USERS. Please repeat > that one hundred times until it gets through. > > No port should *ever* make decisions on a users behalf. > Suggestions, yes (e.g. OPTIONS that are enabled by default.) > Decisions, no. If you depend on another port *and* on certain > knobs in that dependency being enabled, then *tell* the user that > during your port's install and let them decide how to handle it. > DO NOT enable those knobs yourself, no matter how tempting it may > be. > > It is beyond impossible for anyone to know what every user who is > installing ports already has on their boxes or what they might want > to add or ***what you might break***. Once you begin making > decisions for them, you could well stomp all over something that > was functioning perfectly normally and break a critical box. > > DON'T DO IT. That is so Microsoftian it's not funny. > I refuse to debate people with ear plugs on... if you want an honest debate please do so honestly -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYufyzIOMjAek4JIRAjWuAKCjBekW4+ysIJEBHZ5HShiIbzrRkwCcDo5H WVBI+0rgJDXcTG3Wpeu+90Y= =rsQy -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: miro "Loading Miro Guide" forever
Le Jeu 13 déc 07 à 20:16:49 +0100, Mario Sergio Fujikawa Ferreira <[EMAIL
PROTECTED]>
écrivait :
> Okay. Checking ${WRKSRC}/platform/gtk-x11/setup.py shows that
> xulrunner is always preferred over any other found GECKO options.
> Actually, the WITH_GECKO is only controlling the port dependency and it
> has no influence whatsoever on what setup.py will pick.
>
> That said. I removed xulrunner from the list of possible setup.py
> choices. Reinstalled and miro works with firefox. :)
>
> I have a patch attached that rectifies this situation.
Just committed, thanks!
--
Th. Thomas.
pgpmdHRBfzrI3.pgp
Description: PGP signature
Re: Limitations of Ports System
Aryeh M. Friedman wrote: > RW wrote: >> On Thu, 13 Dec 2007 22:34:58 -0500 "Aryeh M. Friedman" >> <[EMAIL PROTECTED]> wrote: >> >>> Namely if I build abc with options 123 and 345 and def with 345 >>> and 678 then 345 will be cached for def since we already set it >>> for abc. >> >> How do you know the user wants 345 set on both ports? >> >> It might be a useful stable feature on "abc", but causes lock-ups >> on "def" > > There are multiple ways to handle the effects of 345 on def... only > one of them is to automatically apply it the other two are def can > ignore it by default or make it suer settable Other than the automatic caching apsect, how would this be any different from what we already have with ports-mgmt/portconf? Currently, if you want a knob to apply to all ports, you wildcard the knob in your ports.conf file. If you want the same knob defined differently depending on port name, you define it per port. -- Skip ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Skip Ford wrote: > Aryeh M. Friedman wrote: >> RW wrote: >>> On Thu, 13 Dec 2007 22:34:58 -0500 "Aryeh M. Friedman" >>> <[EMAIL PROTECTED]> wrote: >>> Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. >>> How do you know the user wants 345 set on both ports? >>> >>> It might be a useful stable feature on "abc", but causes >>> lock-ups on "def" >> There are multiple ways to handle the effects of 345 on def... >> only one of them is to automatically apply it the other two are >> def can ignore it by default or make it suer settable > > Other than the automatic caching apsect, how would this be any > different from what we already have with ports-mgmt/portconf? > > Currently, if you want a knob to apply to all ports, you wildcard > the knob in your ports.conf file. If you want the same knob > defined differently depending on port name, you define it per port. > Often it is not possible to know if you want a knob until seeing it in context... see my reply to RW for more info -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYvT/zIOMjAek4JIRAul8AJ9dSWyYDGJTOh1d9ffBrPtBDsbKOwCgirF1 003NMaY15t0i3H2950Yt3Lw= =R/xP -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
devel/boost -- where is tools/build/v2?
Hello, I'm trying to walk through the tutorial of Boost.Python (the devel/boost-python port)... and unless I'm running out of coffe right now, it seems as if the boost port is not fully installed/specified! Isn't boost supposed to come with a tools/build/v2 directory? Where is it? Thanks for any insight, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hosting for a FreeBSD port
On 15/12/2007, at 2:10 AM, Igor Serikov wrote: Hello porters, I would like to find a hosting for small port. I thought, I can I place it to ftp.freebsd.org (the handbook mentions this possibility), I tried contacting mirror-admin@ and got no reponse. Hi Igor, When you submit the PR, just mention that you would like the committer to host it in their local-distfiles directory. They will upload it for you. Cheers Sam ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
Aryeh M. Friedman wrote: > Remko Lodder wrote: >> David Southwell wrote: >>> On Friday 14 December 2007 08:08:54 Paul Schmehl wrote: --On Friday, December 14, 2007 12:19:06 + RW <[EMAIL PROTECTED]> wrote: > On Thu, 13 Dec 2007 22:34:58 -0500 > > "Aryeh M. Friedman" <[EMAIL PROTECTED]> wrote: >> Namely if I build abc with options 123 and 345 and def with >> 345 and 678 then 345 will be cached for def since we >> already set it for abc. > How do you know the user wants 345 set on both ports? > > It might be a useful stable feature on "abc", but causes > lock-ups on "def" SInce I've already killfiled Aryeh, I can only infer what you are responding to and respond to him. But let me state this emphatically in the hopes it will get through his thick skull. >>> I do wish you could acquire the maturity to distinguish between >>> the advantages that could come arguing your case clearly and >>> collegially and the disadvantages that acrue from being >>> personally antagonistic towards someone with whose analysis you >>> happen to disagree. >>> >>> For me when someone becomes abusive they destroy their own >>> credibility and get to sound as though they believe their >>> opinions antitle them to be hateful and that their own views are >>> somehow godgiven. >>> >>> IT IS NOT THE JOB OF PORTS TO MAKE DECISIONS FOR USERS. >>> IMHO Shouting make you less rather than more credible. \Please repeat that one hundred times until it gets through. >>> Endless repetition does not add strength to analysis!! No port should *ever* make decisions on a users behalf. Suggestions, yes (e.g. OPTIONS that are enabled by default.) Decisions, no. If you depend on another port *and* on certain knobs in that dependency being enabled, then *tell* the user that during your port's install and let them decide how to handle it. DO NOT enable those knobs yourself, no matter how tempting it may be. >>> IMHO You would sound more credible if you used the IMHO a bit >>> more!! You might also gain some respect if you followed your own >>> advice. Make suggestions for others to consider - do not decide, >>> in advance, they are thick skulled if they do not agree with >>> you!! It is beyond impossible for anyone to know what every user who is installing ports already has on their boxes or what they might want to add or ***what you might break***. Once you begin making decisions for them, you could well stomp all over something that was functioning perfectly normally and break a critical box. DON'T DO IT. That is so Microsoftian it's not funny. >>> IMHO Shouting, hectoring and lecturing does not add weight to >>> anyones point of view. >>> >>> >> These threads have gone far enough, please consider taking this off >> the FreeBSD mailinglists and discuss this privately. The majority >> does not like the current ideas and want to see something usefull >> first. People like Aryeh and David are not really persons that one >> would see as the persons generating the ports-infrastructure-ng >> till they have code. > >> If you both keep pissing off people that have a fair share in the >> ports collection already, please do it by other means, dont crowd >> the mailinglists with it. Your ideas might be perfect in your world >> but they aint in ours (till you have shown working code). > >> So please stfu till you have some code and be done with it . > > Developing in a vacuum is a recipe for disaster we are making > fairly good progress believe it or not I only see an other 1 or 2 > threads being needed before actual coding starts, *BUT* producing a > system no one wants is pointless thus it is wise to gather as much > input as possible... why is it that everyone who sees the whole > concept as being negative has offered no input what so ever about what > should be done (even saying "the current system is fine" is useful to us) > simply because we have seen it failing a lot of times. Please take this offlist,discuss this and generate a nice PoC, then get back to us, till that time, DONT bother the ports list with it or any other list. You are the single reason for a HIGH S/N ration on MOST lists I am subscribed to that is a REALLY -BAD- thing. You Simply dont understand the way it works here and I can understand that till a certain point of view; take the advise; discuss it elsewhere, and get back with working code (yeah I repeat it twice because nobody seems to get through to you, and MANY people tried it already). -- /"\ Best regards, | [EMAIL PROTECTED] \ / Remko Lodder | [EMAIL PROTECTED] Xhttp://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-
Re: Limitations of Ports System
David Southwell wrote: > On Friday 14 December 2007 08:08:54 Paul Schmehl wrote: >> --On Friday, December 14, 2007 12:19:06 + RW >> >> <[EMAIL PROTECTED]> wrote: >>> On Thu, 13 Dec 2007 22:34:58 -0500 >>> >>> "Aryeh M. Friedman" <[EMAIL PROTECTED]> wrote: Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. >>> How do you know the user wants 345 set on both ports? >>> >>> It might be a useful stable feature on "abc", but causes lock-ups on >>> "def" >> SInce I've already killfiled Aryeh, I can only infer what you are >> responding to and respond to him. But let me state this emphatically in >> the hopes it will get through his thick skull. > I do wish you could acquire the maturity to distinguish between the > advantages > that could come arguing your case clearly and collegially and the > disadvantages that acrue from being personally antagonistic towards someone > with whose analysis you happen to disagree. > > For me when someone becomes abusive they destroy their own credibility and > get > to sound as though they believe their opinions antitle them to be hateful and > that their own views are somehow godgiven. > > >> IT IS NOT THE JOB OF PORTS >> TO MAKE DECISIONS FOR USERS. > > IMHO Shouting make you less rather than more credible. >> \Please repeat that one hundred times until it >> gets through. >> > Endless repetition does not add strength to analysis!! >> No port should *ever* make decisions on a users behalf. Suggestions, yes >> (e.g. OPTIONS that are enabled by default.) Decisions, no. If you depend >> on another port *and* on certain knobs in that dependency being enabled, >> then *tell* the user that during your port's install and let them decide >> how to handle it. DO NOT enable those knobs yourself, no matter how >> tempting it may be. > > IMHO You would sound more credible if you used the IMHO a bit more!! You > might > also gain some respect if you followed your own advice. Make suggestions for > others to consider - do not decide, in advance, they are thick skulled if > they do not agree with you!! >> It is beyond impossible for anyone to know what every user who is >> installing ports already has on their boxes or what they might want to add >> or ***what you might break***. Once you begin making decisions for them, >> you could well stomp all over something that was functioning perfectly >> normally and break a critical box. >> >> DON'T DO IT. That is so Microsoftian it's not funny. > > IMHO Shouting, hectoring and lecturing does not add weight to anyones point > of view. > > These threads have gone far enough, please consider taking this off the FreeBSD mailinglists and discuss this privately. The majority does not like the current ideas and want to see something usefull first. People like Aryeh and David are not really persons that one would see as the persons generating the ports-infrastructure-ng till they have code. If you both keep pissing off people that have a fair share in the ports collection already, please do it by other means, dont crowd the mailinglists with it. Your ideas might be perfect in your world but they aint in ours (till you have shown working code). So please stfu till you have some code and be done with it . -- /"\ Best regards, | [EMAIL PROTECTED] \ / Remko Lodder | [EMAIL PROTECTED] Xhttp://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Remko Lodder wrote: > David Southwell wrote: >> On Friday 14 December 2007 08:08:54 Paul Schmehl wrote: >>> --On Friday, December 14, 2007 12:19:06 + RW >>> >>> <[EMAIL PROTECTED]> wrote: On Thu, 13 Dec 2007 22:34:58 -0500 "Aryeh M. Friedman" <[EMAIL PROTECTED]> wrote: > Namely if I build abc with options 123 and 345 and def with > 345 and 678 then 345 will be cached for def since we > already set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on "abc", but causes lock-ups on "def" >>> SInce I've already killfiled Aryeh, I can only infer what you >>> are responding to and respond to him. But let me state this >>> emphatically in the hopes it will get through his thick skull. >>> >> I do wish you could acquire the maturity to distinguish between >> the advantages that could come arguing your case clearly and >> collegially and the disadvantages that acrue from being >> personally antagonistic towards someone with whose analysis you >> happen to disagree. >> >> For me when someone becomes abusive they destroy their own >> credibility and get to sound as though they believe their >> opinions antitle them to be hateful and that their own views are >> somehow godgiven. >> >> >>> IT IS NOT THE JOB OF PORTS TO MAKE DECISIONS FOR USERS. >> IMHO Shouting make you less rather than more credible. >>> \Please repeat that one hundred times until it gets through. >>> >> Endless repetition does not add strength to analysis!! >>> No port should *ever* make decisions on a users behalf. >>> Suggestions, yes (e.g. OPTIONS that are enabled by default.) >>> Decisions, no. If you depend on another port *and* on certain >>> knobs in that dependency being enabled, then *tell* the user >>> that during your port's install and let them decide how to >>> handle it. DO NOT enable those knobs yourself, no matter how >>> tempting it may be. >> IMHO You would sound more credible if you used the IMHO a bit >> more!! You might also gain some respect if you followed your own >> advice. Make suggestions for others to consider - do not decide, >> in advance, they are thick skulled if they do not agree with >> you!! >>> It is beyond impossible for anyone to know what every user who >>> is installing ports already has on their boxes or what they >>> might want to add or ***what you might break***. Once you >>> begin making decisions for them, you could well stomp all over >>> something that was functioning perfectly normally and break a >>> critical box. >>> >>> DON'T DO IT. That is so Microsoftian it's not funny. >> IMHO Shouting, hectoring and lecturing does not add weight to >> anyones point of view. >> >> > > These threads have gone far enough, please consider taking this off > the FreeBSD mailinglists and discuss this privately. The majority > does not like the current ideas and want to see something usefull > first. People like Aryeh and David are not really persons that one > would see as the persons generating the ports-infrastructure-ng > till they have code. > > If you both keep pissing off people that have a fair share in the > ports collection already, please do it by other means, dont crowd > the mailinglists with it. Your ideas might be perfect in your world > but they aint in ours (till you have shown working code). > > So please stfu till you have some code and be done with it . Developing in a vacuum is a recipe for disaster we are making fairly good progress believe it or not I only see an other 1 or 2 threads being needed before actual coding starts, *BUT* producing a system no one wants is pointless thus it is wise to gather as much input as possible... why is it that everyone who sees the whole concept as being negative has offered no input what so ever about what should be done (even saying "the current system is fine" is useful to us) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYwOjzIOMjAek4JIRAs8qAJ9Xa0loqoVr3dlKIT5AcOt5m6YKXACdE8QG 4ZPSX/xHgiiLW72pUPNW/W0= =KW47 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Remko Lodder wrote: > Aryeh M. Friedman wrote: >> Remko Lodder wrote: >>> David Southwell wrote: On Friday 14 December 2007 08:08:54 Paul Schmehl wrote: > --On Friday, December 14, 2007 12:19:06 + RW > > <[EMAIL PROTECTED]> wrote: >> On Thu, 13 Dec 2007 22:34:58 -0500 >> >> "Aryeh M. Friedman" <[EMAIL PROTECTED]> wrote: >>> Namely if I build abc with options 123 and 345 and def >>> with 345 and 678 then 345 will be cached for def since >>> we already set it for abc. >> How do you know the user wants 345 set on both ports? >> >> It might be a useful stable feature on "abc", but causes >> lock-ups on "def" > SInce I've already killfiled Aryeh, I can only infer what > you are responding to and respond to him. But let me state > this emphatically in the hopes it will get through his > thick skull. > I do wish you could acquire the maturity to distinguish between the advantages that could come arguing your case clearly and collegially and the disadvantages that acrue from being personally antagonistic towards someone with whose analysis you happen to disagree. For me when someone becomes abusive they destroy their own credibility and get to sound as though they believe their opinions antitle them to be hateful and that their own views are somehow godgiven. > IT IS NOT THE JOB OF PORTS TO MAKE DECISIONS FOR USERS. IMHO Shouting make you less rather than more credible. > \Please repeat that one hundred times until it gets > through. > Endless repetition does not add strength to analysis!! > No port should *ever* make decisions on a users behalf. > Suggestions, yes (e.g. OPTIONS that are enabled by > default.) Decisions, no. If you depend on another port > *and* on certain knobs in that dependency being enabled, > then *tell* the user that during your port's install and > let them decide how to handle it. DO NOT enable those > knobs yourself, no matter how tempting it may be. IMHO You would sound more credible if you used the IMHO a bit more!! You might also gain some respect if you followed your own advice. Make suggestions for others to consider - do not decide, in advance, they are thick skulled if they do not agree with you!! > It is beyond impossible for anyone to know what every user > who is installing ports already has on their boxes or what > they might want to add or ***what you might break***. Once > you begin making decisions for them, you could well stomp > all over something that was functioning perfectly normally > and break a critical box. > > DON'T DO IT. That is so Microsoftian it's not funny. IMHO Shouting, hectoring and lecturing does not add weight to anyones point of view. >>> These threads have gone far enough, please consider taking this >>> off the FreeBSD mailinglists and discuss this privately. The >>> majority does not like the current ideas and want to see >>> something usefull first. People like Aryeh and David are not >>> really persons that one would see as the persons generating the >>> ports-infrastructure-ng till they have code. If you both keep >>> pissing off people that have a fair share in the ports >>> collection already, please do it by other means, dont crowd the >>> mailinglists with it. Your ideas might be perfect in your world >>> but they aint in ours (till you have shown working code). So >>> please stfu till you have some code and be done with it . >> Developing in a vacuum is a recipe for disaster we are making >> fairly good progress believe it or not I only see an other 1 or >> 2 threads being needed before actual coding starts, *BUT* >> producing a system no one wants is pointless thus it is wise to >> gather as much input as possible... why is it that everyone who >> sees the whole concept as being negative has offered no input >> what so ever about what should be done (even saying "the current >> system is fine" is useful to us) >> > > simply because we have seen it failing a lot of times. Please take > this offlist,discuss this and generate a nice PoC, then get back to > us, till that time, DONT bother the ports list with it or any other > list. You are the single reason for a HIGH S/N ration on MOST lists > I am subscribed to that is a REALLY -BAD- thing. Perhaps one reason it has failed is because there was not a wide enough front end effort to decide what was really needed vs. what some individual thought was needed... as to the s/n thing there would be lot less if you actually debated on the technical merits of the proposal and not the meta discussion of does something belong here or list b or where ever... unless you think community input is completely pointless I invite you to suggest an other medium that allows for it without
misc/compat5x package installs with weird messages
Installing the 7.0-RELEASE package of graphics/xnview, I got some weird messages that seem to come from the misc/compat5x dependency: rm: /var/tmp/instmp.qdjoSl/lib/compat/libc.so.5: Operation not permitted rm: /var/tmp/instmp.qdjoSl/lib/compat/libc_r.so.5: Operation not permitted rm: /var/tmp/instmp.qdjoSl/lib/compat/libcrypt.so.2: Operation not permitted rm: /var/tmp/instmp.qdjoSl/lib/compat/libpthread.so.1: Operation not permitted rm: /var/tmp/instmp.qdjoSl/lib/compat/libthr.so.1: Operation not permitted rm: /var/tmp/instmp.qdjoSl/lib/compat: Directory not empty rm: /var/tmp/instmp.qdjoSl/lib: Directory not empty rm: /var/tmp/instmp.qdjoSl: Directory not empty pkg_add: couldn't remove temporary dir '/var/tmp/instmp.qdjoSl' What has happened? Regards, Jan Henrik ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
Aryeh M. Friedman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Remko Lodder wrote: Aryeh M. Friedman wrote: Remko Lodder wrote: David Southwell wrote: On Friday 14 December 2007 08:08:54 Paul Schmehl wrote: --On Friday, December 14, 2007 12:19:06 + RW <[EMAIL PROTECTED]> wrote: On Thu, 13 Dec 2007 22:34:58 -0500 "Aryeh M. Friedman" <[EMAIL PROTECTED]> wrote: Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on "abc", but causes lock-ups on "def" SInce I've already killfiled Aryeh, I can only infer what you are responding to and respond to him. But let me state this emphatically in the hopes it will get through his thick skull. I do wish you could acquire the maturity to distinguish between the advantages that could come arguing your case clearly and collegially and the disadvantages that acrue from being personally antagonistic towards someone with whose analysis you happen to disagree. For me when someone becomes abusive they destroy their own credibility and get to sound as though they believe their opinions antitle them to be hateful and that their own views are somehow godgiven. IT IS NOT THE JOB OF PORTS TO MAKE DECISIONS FOR USERS. IMHO Shouting make you less rather than more credible. \Please repeat that one hundred times until it gets through. Endless repetition does not add strength to analysis!! No port should *ever* make decisions on a users behalf. Suggestions, yes (e.g. OPTIONS that are enabled by default.) Decisions, no. If you depend on another port *and* on certain knobs in that dependency being enabled, then *tell* the user that during your port's install and let them decide how to handle it. DO NOT enable those knobs yourself, no matter how tempting it may be. IMHO You would sound more credible if you used the IMHO a bit more!! You might also gain some respect if you followed your own advice. Make suggestions for others to consider - do not decide, in advance, they are thick skulled if they do not agree with you!! It is beyond impossible for anyone to know what every user who is installing ports already has on their boxes or what they might want to add or ***what you might break***. Once you begin making decisions for them, you could well stomp all over something that was functioning perfectly normally and break a critical box. DON'T DO IT. That is so Microsoftian it's not funny. IMHO Shouting, hectoring and lecturing does not add weight to anyones point of view. These threads have gone far enough, please consider taking this off the FreeBSD mailinglists and discuss this privately. The majority does not like the current ideas and want to see something usefull first. People like Aryeh and David are not really persons that one would see as the persons generating the ports-infrastructure-ng till they have code. If you both keep pissing off people that have a fair share in the ports collection already, please do it by other means, dont crowd the mailinglists with it. Your ideas might be perfect in your world but they aint in ours (till you have shown working code). So please stfu till you have some code and be done with it . Developing in a vacuum is a recipe for disaster we are making fairly good progress believe it or not I only see an other 1 or 2 threads being needed before actual coding starts, *BUT* producing a system no one wants is pointless thus it is wise to gather as much input as possible... why is it that everyone who sees the whole concept as being negative has offered no input what so ever about what should be done (even saying "the current system is fine" is useful to us) simply because we have seen it failing a lot of times. Please take this offlist,discuss this and generate a nice PoC, then get back to us, till that time, DONT bother the ports list with it or any other list. You are the single reason for a HIGH S/N ration on MOST lists I am subscribed to that is a REALLY -BAD- thing. Perhaps one reason it has failed is because there was not a wide enough front end effort to decide what was really needed vs. what some individual thought was needed... as to the s/n thing there would be lot less if you actually debated on the technical merits of the proposal and not the meta discussion of does something belong here or list b or where ever... unless you think community input is completely pointless I invite you to suggest an other medium that allows for it without making is semi-obscure and hard to find. You Simply dont understand the way it works here and I can understand that till a certain point of view
Re: misc/compat5x package installs with weird messages
Garrett Cooper píše v pá 14. 12. 2007 v 15:39 -0800: > Jan Henrik Sylvester wrote: > > Installing the 7.0-RELEASE package of graphics/xnview, I got some > > weird messages that seem to come from the misc/compat5x dependency: > > > > rm: /var/tmp/instmp.qdjoSl/lib/compat/libc.so.5: Operation not permitted > > rm: /var/tmp/instmp.qdjoSl/lib/compat/libc_r.so.5: Operation not > > permitted > > rm: /var/tmp/instmp.qdjoSl/lib/compat/libcrypt.so.2: Operation not > > permitted > > rm: /var/tmp/instmp.qdjoSl/lib/compat/libpthread.so.1: Operation not > > permitted > > rm: /var/tmp/instmp.qdjoSl/lib/compat/libthr.so.1: Operation not > > permitted > > rm: /var/tmp/instmp.qdjoSl/lib/compat: Directory not empty > > rm: /var/tmp/instmp.qdjoSl/lib: Directory not empty > > rm: /var/tmp/instmp.qdjoSl: Directory not empty > > pkg_add: couldn't remove temporary dir '/var/tmp/instmp.qdjoSl' > > > > What has happened? > Files are still in use. Are you exec'ing a program that needs lib/compat5x? There is nothing like "executable in use is undeletable" phenomenon that's observed on Microsoft Windows. My bets are on noschg flag. -- Pav Lucistnik <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Angband in action! Constant escalation to new depths to find angrier, meaner letters and more punctuation! signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: misc/compat5x package installs with weird messages
Jan Henrik Sylvester wrote: Installing the 7.0-RELEASE package of graphics/xnview, I got some weird messages that seem to come from the misc/compat5x dependency: rm: /var/tmp/instmp.qdjoSl/lib/compat/libc.so.5: Operation not permitted rm: /var/tmp/instmp.qdjoSl/lib/compat/libc_r.so.5: Operation not permitted rm: /var/tmp/instmp.qdjoSl/lib/compat/libcrypt.so.2: Operation not permitted rm: /var/tmp/instmp.qdjoSl/lib/compat/libpthread.so.1: Operation not permitted rm: /var/tmp/instmp.qdjoSl/lib/compat/libthr.so.1: Operation not permitted rm: /var/tmp/instmp.qdjoSl/lib/compat: Directory not empty rm: /var/tmp/instmp.qdjoSl/lib: Directory not empty rm: /var/tmp/instmp.qdjoSl: Directory not empty pkg_add: couldn't remove temporary dir '/var/tmp/instmp.qdjoSl' What has happened? Regards, Jan Henrik ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]" Files are still in use. Are you exec'ing a program that needs lib/compat5x? -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > 1. Make plan. 2. Ask limited group for sanity check. 3. Code, code > code. Go back to 2. if necessary. Continue to 4. when "done". 4. > Ask larger group for sanity check and testing. Go back to 3. if > necessary. Continue to 5. when "done". 5. Release. > We're still at 1., and while I think that the problem to 1. can be > established and thought out via email, perhaps the stakeholders > need to brainstorm and research more about 1. on the lists, as this > topic has been brought up a few times already (see the ports@ and > hackers@ archives in particular). We (at least I) have done a good amount of background research but several key issues where not answered thus my public questions. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYxyKzIOMjAek4JIRAohzAJ93pnk01isO8YJ4wvXowkvG56DkdwCgmdgS gsx4EyT8gJka/10p1Zdjtlc= =rUS6 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
Aryeh M. Friedman wrote: > Developing in a vacuum is a recipe for disaster we are making > fairly good progress believe it or not I only see an other 1 or 2 > threads being needed before actual coding starts, *BUT* producing a > system no one wants is pointless thus it is wise to gather as much > input as possible... And that's fine if that's how you prefer to work, but everyone's point is that it has nothing to do with the current ports system at all so the talk doesn't belong on a mailing list dedicated to the current ports system. It's just noise here. Research for a new system from ports@ users belongs on a list dedicated to the new system. > why is it that everyone who sees the whole > concept as being negative has offered no input what so ever about what > should be done (even saying "the current system is fine" is useful to us) You've been told over and over what should be done. You need a ports-ng wiki (or whatever you want to call your new system) and/or your own mailing list. Posting a single message occasionally on ports@ to point others to a new system in the works is perfectly fine, but using a mailing list dedicated to one system to develop another competing system isn't. If you need research from ports@ readers, you post a message pointing them elsewhere, you don't do it in a way that floods this list with 100+ messages. You've been given lots of sound advice on how to proceed and you've listened to none of it. You haven't heard what anyone has said thus far. Just start a wiki already like you've been told to do by those who already know exactly what they're doing, and aren't still trying to figure out how to figure out what it is they might want to do someday. -- Skip ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
Aryeh M. Friedman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Remko Lodder wrote: You Simply dont understand the way it works here and I can understand that till a certain point of view; take the advise; discuss it elsewhere, and get back with working code (yeah I repeat it twice because nobody seems to get through to you, and MANY people tried it already). Oh I hear the message loud and clear and just happen to not agree with the thinking behind it. Namely ivory tower development has its place but not here. This is my thinking. I think what Aryeh is doing here is fine. But perhaps Aryeh and David need to stop rising to the bait when someone tells them they are wrong. I understand them replying up until now, because I can see that silence might be interpreted as their acquiescence. But I think to reply to naysayers now will only add much more noise. Both sides have made their points loud and clear, and the points don't need repetition. Remko: this thread has generated interesting discussions, clearly relevant to ports. If you don't like the discussions, simply press the delete key or don't reply. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Skip Ford wrote: > Aryeh M. Friedman wrote: >> Developing in a vacuum is a recipe for disaster we are making >> fairly good progress believe it or not I only see an other 1 or >> 2 threads being needed before actual coding starts, *BUT* >> producing a system no one wants is pointless thus it is wise to >> gather as much input as possible... > > And that's fine if that's how you prefer to work, but everyone's > point is that it has nothing to do with the current ports system at > all so the talk doesn't belong on a mailing list dedicated to the > current ports system. It's just noise here. Research for a new > system from ports@ users belongs on a list dedicated to the new > system. First of all not everyone has said a number of people (not including me) have said it is the proper place one thing is clear though there really is no proper mailing lists and wiki's have some problems covered below > >> why is it that everyone who sees the whole concept as being >> negative has offered no input what so ever about what should be >> done (even saying "the current system is fine" is useful to us) > > You've been told over and over what should be done. You need a > ports-ng wiki (or whatever you want to call your new system) and/or > your own mailing list. Posting a single message occasionally on > ports@ to point others to a new system in the works is perfectly > fine, but using a mailing list dedicated to one system to develop > another competing system isn't. If you need research from ports@ > readers, you post a message pointing them elsewhere, you don't do > it in a way that floods this list with 100+ messages. The simpler case is the seperate mailing list once there is a good idea of what is needed then moving to such a forum makes a great amount of sense and the 3 volunteers (including me) that have made firm commitments to work on the project do just this... but in the early design phases (deciding if the project is needed, the scope and gathering top level requirments/features) public input is critical and taking stuff out of a well established forum reduces the amount of useful input... btw we are basically somewhere between scope and top level requirement gathering (the internal mailing list is attempting to settle on a final scope statement so we can move to the final truly public phase which is systematic gathering of requirements) The wiki poses some issues due to the medium of wiki's vs. the medium of mail... the first of these issues is wiki's are terrible for discusssions and a very lively on topic discussion is the best way to iron out the 3 public phases... what wiki's are very good at is recording decisions and we defently plan to use a wiki for this... but besides for "the project should be done" not enough decisions have been made to justify a record of them currently, as soon as the scope is decided internally we will produce some docs that will justify a wiki (and since they are still in the public phases I will post them here for discussion purposes)... as soon the second set of docs (top level requirements) is produced all the work will occur privately except for one final post that details the conceptual model for public comment > > You've been given lots of sound advice on how to proceed and you've > listened to none of it. You haven't heard what anyone has said > thus far. Just start a wiki already like you've been told to do by > those who already know exactly what they're doing, and aren't still > trying to figure out how to figure out what it is they might want > to do someday. On techinical issues I have heard almost all of it and have substantially revised my mental conceptual model based on it. But as far as what should be public and what should be private good software engineering not only says the minority is wrong but I am using what is considered the industry standard method (as much as possible when it is not f2f). If the industry standard doesn't agree with FreeBSD's method then it does make sense to check if the FreeBSD model can not be improved in light of newer data. In sort the main metadebate is on cultural differences and that is sad because culture should have nothing to do with the tech aspects. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYxvQzIOMjAek4JIRAsRSAJ9YBTglveSohfNWAaKdvG3JrKUq7gCfUI3H v65HbjHbwZs+JryHeOqXOr4= =353C -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TeTeX and TeXLive
Am Fri, 14 Dec 2007 10:10:07 +0100 schrieb Michel Talon <[EMAIL PROTECTED]>: > Albert Shih wrote: > > > I'm just want known if there are any plan to replace teTeX ports > > (the project as stop) by TeXLive ? > > > > I've send long time ago a mail to teTeX maintainer and I don't have > > any answer. > > > > I known that's nothing urgent, but without tex the live is hard ;-) > > Well, TeX itself is frozen since many years, so the differences > between TeTeX and TeXLive are of the order of the infinitesimal. It > is not like you could not do "happy texing" using TeTeX. Of course > the migration to TeXLive will have to occur but i understand that it > is not an ultra hot priority. Personnally i would be happier with a > distribution much lighter than TeTeX, i think the only progress of > any interest in all that stuff is pdftex. If only i could put Latex2e > in the trash can ... > > Hi, I think there are some changes which are very interresting. One of this is unicode support through the xetex import to texlive. So the change to texlive will be important to some people. Chers, -- Uwe Grohnwaldt Max-Planck-Str 2A, 1.03.2 18059 Rostock Telefon: 0381 - 1 22 48 11 * Mobil : 0172 - 3 20 92 85 * Fax: 01212 - 5 - 131 - 79 - 310 * E-Mail : [EMAIL PROTECTED] ICQ: 149348486 * Skype : lando_calr * nur nach vorheriger Vereinbarung ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Kirkwood wrote: > Skip Ford wrote: >> Aryeh M. Friedman wrote: >> >>> Developing in a vacuum is a recipe for disaster we are >>> making fairly good progress believe it or not I only see an >>> other 1 or 2 threads being needed before actual coding starts, >>> *BUT* producing a system no one wants is pointless thus it is >>> wise to gather as much input as possible... >>> >> >> And that's fine if that's how you prefer to work, but everyone's >> point is that it has nothing to do with the current ports system >> at all so the talk doesn't belong on a mailing list dedicated to >> the current ports system. It's just noise here. Research for a >> new system from ports@ users belongs on a list dedicated to the >> new system. >> >> > > That is a little unfair IMHO - Aryeh has to gather information from > those who use the current system, and @ports is clearly the place > for that! Now he may listen to all, some or none of the points of > view he receives... and that may well determine the success or > otherwise of his ports-ng process - but I don't think he is doing > anything wrong. > > I agree that a new list (ports-ng or similar) for this would be a > good thing to start *soon*, so that those folks (probably from > *this* list) who are interested can see what is happening and maybe > help if they like! There is already an informal private one but until scope and some top level features are decided the vast majority of discussion will be on - -ports@ and as soon they are very little should be. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYyO+zIOMjAek4JIRAv4HAJ9pdPTWAYuEYsrfy4yNDL5+ZW3FeACeLfco JWBitNl/q0ntsb9bQhOm5L8= =Z2I6 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Diablo on 7.0-BETA
Just an update got jdk16 working on 7.0-BETA4 by building it from scratch never had any luck though using the binary diablo build's for 6.2 on 7.0-BETA4 even w compat6x. Prob a compat issue but I happy with 1.6 ... now only if it wasn't so slow :( ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
Skip Ford wrote: Aryeh M. Friedman wrote: Developing in a vacuum is a recipe for disaster we are making fairly good progress believe it or not I only see an other 1 or 2 threads being needed before actual coding starts, *BUT* producing a system no one wants is pointless thus it is wise to gather as much input as possible... And that's fine if that's how you prefer to work, but everyone's point is that it has nothing to do with the current ports system at all so the talk doesn't belong on a mailing list dedicated to the current ports system. It's just noise here. Research for a new system from ports@ users belongs on a list dedicated to the new system. That is a little unfair IMHO - Aryeh has to gather information from those who use the current system, and @ports is clearly the place for that! Now he may listen to all, some or none of the points of view he receives... and that may well determine the success or otherwise of his ports-ng process - but I don't think he is doing anything wrong. I agree that a new list (ports-ng or similar) for this would be a good thing to start *soon*, so that those folks (probably from *this* list) who are interested can see what is happening and maybe help if they like! Cheers Mark ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ion3 removal
Mikhail Teterin wrote: Bill Moran wrote: = > should've been addressed by using FORBIDDEN/IGNORE instead. = Perhaps you're right. However, I'd like to hear the opinion of a lawyer = as to whether this is acceptable or not. What happened is bad for porters and other users. It would be nice if there is at least an official stance or consensus regarding this issue. A port is a work separate from the software being ported, mostly not done by the authors of the software themselves, so do we want to allow unrelated software authors mess our system at all? We are thankful but there should also be some protection for our work. A port is also an unpaid advertisement with a hook. If software authors see it as such is not a legal matter, it is a matter of conduct. Cases like this illustrate that maybe it shouldn't be. I propose we at least clear the matters with authors of software with funny licenses before the port is approved. I'd also like to add that relying on a lawyer's opinion may not be such a good idea, because lawyers have to prove themselves too and that could be a lottery. We better focus on community, build consensus and try to outsmart casual pranksters with trivial legal tactics. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: misc/compat5x package installs with weird messages
Pav Lucistnik wrote: Garrett Cooper píše v pá 14. 12. 2007 v 15:39 -0800: Jan Henrik Sylvester wrote: Installing the 7.0-RELEASE package of graphics/xnview, I got some weird messages that seem to come from the misc/compat5x dependency: rm: /var/tmp/instmp.qdjoSl/lib/compat/libc.so.5: Operation not permitted rm: /var/tmp/instmp.qdjoSl/lib/compat/libc_r.so.5: Operation not permitted rm: /var/tmp/instmp.qdjoSl/lib/compat/libcrypt.so.2: Operation not permitted rm: /var/tmp/instmp.qdjoSl/lib/compat/libpthread.so.1: Operation not permitted rm: /var/tmp/instmp.qdjoSl/lib/compat/libthr.so.1: Operation not permitted rm: /var/tmp/instmp.qdjoSl/lib/compat: Directory not empty rm: /var/tmp/instmp.qdjoSl/lib: Directory not empty rm: /var/tmp/instmp.qdjoSl: Directory not empty pkg_add: couldn't remove temporary dir '/var/tmp/instmp.qdjoSl' What has happened? Files are still in use. Are you exec'ing a program that needs lib/compat5x? There is nothing like "executable in use is undeletable" phenomenon that's observed on Microsoft Windows. My bets are on noschg flag. Pav, you are exactly right. I have experienced this many times myself. After installing the compat5x package you need to do "chflags -R noschg /var/tmp/inst* && rm -rf /var/tmp/inst*" or something like that. I think it is a bug in pkg_install, that it doesn't check for the schg flag being set in its temporary file area. Or maybe it should set the flags in the first place. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TeTeX and TeXLive
Le 15/12/2007 à 01:13:18+0100, Uwe Grohnwaldt a écrit > > I think there are some changes which are very interresting. One of this > is unicode support through the xetex import to texlive. It's one reason I send the mail. Actually I already use ISO8859 becauseit's the default on FreeBSD. But many linux use UTF-8 by default. Maybe some day FreeBSD too. And on this day It's very good to have texlive. Unfortunaly I'm not TeX Guru and not developper at all. I can help I just want to say it's not urgent to have texlive in FreeBSD, but it's good idea. The OpenBSD texlive is release (http://students.dec.bmth.ac.uk/ebarrett/texlive/) Regards. -- Albert SHIH Observatoire de Paris Meudon SIO batiment 15 Heure local/Local time: Sam 15 déc 2007 02:10:07 CET ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
Mark Kirkwood wrote: That is a little unfair IMHO - Aryeh has to gather information from those who use the current system, and @ports is clearly the place for that! Now he may listen to all, some or none of the points of view he receives... and that may well determine the success or otherwise of his ports-ng process - but I don't think he is doing anything wrong. I agree that a new list (ports-ng or similar) for this would be a good thing to start *soon*, so that those folks (probably from *this* list) who are interested can see what is happening and maybe help if they like! Cheers Mark ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]" Information does indeed need to be gathered, and while even the ports list will only grab a small percentage of FreeBSD users, other options would likely grab a lot less. Plus, most of the users here are knowledgeable enough to give decent input. For those of you that don't like change may I suggest the book that led to http://www.whomovedmycheese.com/. It is really in all of our best interest to have the product evolve, the alternative is much worse. Brian ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TeTeX and TeXLive
On Fri, 14 Dec 2007 07:43:00 Doug Barton <[EMAIL PROTECTED]> wrote: > On Fri, 14 Dec 2007, Nikola Lečić wrote: [...] > > I must add that I tried two times to contact two FreeBSD developers > > who > > (according to the public sources) seemed to be interested in this; > > never got a single word of reply. Having in mind that I offered a > > help, some experience and maintaining/testing availability, I can't > > understand this. It's very discouraging. > > please feel free to take that as a sign that you should take the ball > and run with it. :) Well, according to http://lists.freebsd.org/pipermail/freebsd-ports/2007-May/040511.html porting of TeXLive has already been undertaken. :-) The problem is that it's not possible to get any further information on this work. But anyway, I don't think I can do it alone, of course. I could probably create port(s), but the biggest challenge is that so many other ports depend on teTeX, and re-configuring all dependencies obviously requires huge experience, computer horsepower and developers' hands. Therefore a help was offered and sharing future maintaining load as well: http://lists.freebsd.org/pipermail/freebsd-ports/2007-July/042729.html http://lists.freebsd.org/pipermail/freebsd-ports/2007-August/043453.html So, once again: * If any FreeBSD developer is currently working on TeXLive port, please, can we users know something about it? * If not, is any FreeBSD developer willing to lead that project, publicly discuss port's infrastructure/concept, and then give us (who are happy to help :-)) some tasks? * Or some user should start porting (and discuss infrastructure first?) and then developers will jump in? -- Nikola Lečić :: Никола Лечић ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
At 10:08 AM -0600 12/14/07, Paul Schmehl wrote: SInce I've already killfiled Aryeh, I guess we should all killfile you, too. -- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute; Troy, NY; USA ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
--On December 14, 2007 5:21:02 PM -0800 Brian <[EMAIL PROTECTED]> wrote: Information does indeed need to be gathered, and while even the ports list will only grab a small percentage of FreeBSD users, other options would likely grab a lot less. Plus, most of the users here are knowledgeable enough to give decent input. For those of you that don't like change may I suggest the book that led to http://www.whomovedmycheese.com/. It is really in all of our best interest to have the product evolve, the alternative is much worse. This really is getting quite irritating. Not one person on this list has *ever* said they don't want to entertain new ideas for ports. Not one person on this list has said they don't like change. *All* of the complaints have been along the lines of "go write some code and stop filling up this list with posts". And that is *precisely* the point. Yet the proponents of the Aryeh bandwagon keep throwing up this straw man that those of us who have tired of the useless back and forth are refusing to listen and uninterested in change, when *nothing* could be further from the truth. ports@ is *not* a development list. Its purpose is to provide news about ports, discuss problems with ports, get advice on porting and so forth. Or, to quote its charter, "Discussions concerning FreeBSD's “ports collection” (/usr/ports), ports infrastructure, and general ports coordination efforts. This is a technical mailing list for which strictly technical content is expected." Get that? "Strictly technical". "How do you feel about the present design" or "what don't you like about the present design" or "if you could change something about ports, what would it be" are *not* appropriate discussions for this list. It's time to move this "discussion" to some place where those that *care* about coding and/or redesigning the ports system can participate and discuss code and return this list to its original purpose. The only FreeBSD list that would be appropriate (if that - it's not really) would be arch, which is for architecture and design discussions. This thread is a design discussion and does not belong here. Please move it to a more appropriate place and leave this list alone. Ask the FreeBSD maintainers to create a new list "ports-design@" if you like, but please stop the discussions here. They are inappropriate for this list. And stop lying about the motivations of the many talented people who have asked, politely and otherwise, to stop. Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
On Fri, Dec 14, 2007 at 07:51:14PM -0500, Garance A Drosehn wrote: > At 10:08 AM -0600 12/14/07, Paul Schmehl wrote: > > > >SInce I've already killfiled Aryeh, > > I guess we should all killfile you, too. Can we please just stop the meta-thread now and go back to working on all the myriad things that need to be fixed? Thanks. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It is too bad I am in your killfile because you will not get this ;-)
>
> Yet the proponents of the Aryeh bandwagon keep throwing up this
> straw man that those of us who have tired of the useless back and
> forth are refusing to listen and uninterested in change, when
> *nothing* could be further from the truth. ports@ is *not* a
> development list. Its purpose is to provide news about ports,
> discuss problems with ports, get advice on porting and so forth.
> Or, to quote its charter, "Discussions concerning FreeBSD's “ports
> collection” (/usr/ports), ports infrastructure, and general ports
> coordination efforts. This is a technical mailing list for which
> strictly technical content is expected."
1. It specifically does not preclude such a discussion
2. If you where willing to have a rational debate vs. this chaos (some
of my "supporters" may have gone too far but it is only out of
reaction to the complete irrationality of some of those who don't like
the idea... btw I am not accusing anyone one of being against the
general concept of improving stuff just some people have really
"stupid" ideas {i.e. to me the seem like a recipe for disaster} of the
proper way to gather the information needed to do it right [not at all])
>
> Get that? "Strictly technical". "How do you feel about the
> present design" or "what don't you like about the present design"
> or "if you could change something about ports, what would it be"
> are *not* appropriate discussions for this list.
Name a specific aspect of an on topic reply (not debates about the
merits of the idea and/or the process of gathering info) that is not
specifically techinical. By definition I think it is impossible not
to have anything but a purely tech discussion unless your one of these
narrow minded people who thinks that "2+2=4" is techinical but "what
is the result of adding two and two" is not technical.
>
> It's time to move this "discussion" to some place where those that
> *care* about coding and/or redesigning the ports system can
> participate and discuss code and return this list to its original
> purpose. The only FreeBSD list that would be appropriate (if that
> - it's not really) would be arch, which is for architecture and
> design discussions. This thread is a design discussion and does
> not belong here. Please move it to a more appropriate place and
> leave this list alone. Ask the FreeBSD maintainers to create a new
> list "ports-design@" if you like, but please stop the discussions
> here. They are inappropriate for this list.
As soon the rough design is worked out (which if people would stop
debating pointless stuff and stay on topic would take a week or so)
almost nothing will be discussed on any existing -XXX@ list, the
working group will use it's own list [not sure if it will be public or
private yet], except for occasional progress reports.. just like any
other project (and just like any other project there is a hopefully
brief [compared to the total effort] peroid of public discussion
concerning the general aspects and that is what is happening now on
- [EMAIL PROTECTED])
>
> And stop lying about the motivations of the many talented people
> who have asked, politely and otherwise, to stop.
I don't see how anyone ascribed any motive to anyone except for some
opponents of my approach saying I have alternative motives
speaking of that I need to clarify one thing when I said my personal
reasons for doing this is to create a prototype for a commercial
system I am working on I didn't not mean the two projects will be
connected in any shape or form except for sharing some concepts
the commercial version will be in Java for a OS radically diff then
Unix thus almost no code portability is possible also the FreeBSD
stuff will be 100% under the BSD license (note the commercial version
will have "open" sources also see my company's web site
http://www.flosoft-systems.com for details) the reason for calling
the FreeBSD version a prototype is FreeBSD can always fall back on the
current system but for the commercial stuff due to it's nature there
is no fall back position.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHY0ShzIOMjAek4JIRApRXAJ9yLSVMCxgrogUvNaa0wr2tj8ceMgCeI78p
oI6J7k4VrK7622nSxxS7pmo=
=aCgZ
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: misc/compat5x package installs with weird messages
On Fri, 14 Dec 2007 18:32:22 -0600
Stephen Montgomery-Smith <[EMAIL PROTECTED]> wrote:
> > My bets are on noschg flag.
> Pav, you are exactly right. I have experienced this many times myself.
> After installing the compat5x package you need to do "chflags -R
> noschg /var/tmp/inst* && rm -rf /var/tmp/inst*" or something like that.
> I think it is a bug in pkg_install, that it doesn't check for the schg
> flag being set in its temporary file area. Or maybe it should set the
> flags in the first place.
I knew this issue. So I fixed it with rev#1.16 on make clean.
But my work was not enough:-(. How about following patch?
Index: Makefile
===
RCS file: /home/ncvs/ports/misc/compat5x/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- Makefile21 Apr 2007 03:24:32 - 1.16
+++ Makefile15 Dec 2007 02:59:30 -
@@ -11,7 +11,7 @@
PORTNAME= compat5x
PORTVERSION= 5.4.0.8
-PORTREVISION= 8
+PORTREVISION= 9
CATEGORIES=misc
MASTER_SITES= ${MASTER_SITE_LOCAL}
MASTER_SITE_SUBDIR=lesi/compat5x
@@ -68,6 +68,9 @@
PLIST_SUB+=SPARC64="@comment "
.endif
+post-extract:
+ @chflags -R noschg ${WRKSRC} || ${TRUE}
+
do-install:
@${MKDIR} ${TARGET_DIR}
(cd ${WRKSRC} && ${INSTALL_DATA} *.so.* ${TARGET_DIR})
@@ -85,7 +88,4 @@
.endif
@${CAT} ${PKGMESSAGE}
-pre-clean:
- @[ -w ${WRKSRC} ] && chflags -R noschg ${WRKSRC} || ${TRUE}
-
.include
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
--On December 14, 2007 7:51:14 PM -0500 Garance A Drosehn <[EMAIL PROTECTED]> wrote: At 10:08 AM -0600 12/14/07, Paul Schmehl wrote: SInce I've already killfiled Aryeh, I guess we should all killfile you, too. Be my guest. Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
Paul Schmehl wrote: --On December 14, 2007 5:21:02 PM -0800 Brian <[EMAIL PROTECTED]> wrote: Information does indeed need to be gathered, and while even the ports list will only grab a small percentage of FreeBSD users, other options would likely grab a lot less. Plus, most of the users here are knowledgeable enough to give decent input. For those of you that don't like change may I suggest the book that led to http://www.whomovedmycheese.com/. It is really in all of our best interest to have the product evolve, the alternative is much worse. This really is getting quite irritating. Not one person on this list has *ever* said they don't want to entertain new ideas for ports. Not one person on this list has said they don't like change. *All* of the complaints have been along the lines of "go write some code and stop filling up this list with posts". And that is *precisely* the point. Yet the proponents of the Aryeh bandwagon keep throwing up this straw man that those of us who have tired of the useless back and forth are refusing to listen and uninterested in change, when *nothing* could be further from the truth. ports@ is *not* a development list. Its purpose is to provide news about ports, discuss problems with ports, get advice on porting and so forth. Or, to quote its charter, "Discussions concerning FreeBSD's “ports collection” (/usr/ports), ports infrastructure, and general ports coordination efforts. This is a technical mailing list for which strictly technical content is expected." Get that? "Strictly technical". "How do you feel about the present design" or "what don't you like about the present design" or "if you could change something about ports, what would it be" are *not* appropriate discussions for this list. You are the first person who has raised any kind of coherent argument as to why perhaps Aryeh shouldn't be asking these questions on [EMAIL PROTECTED] Your argument is based on the interpretation of the phrase "strictly technical" that appears in the charter, because Aryeh's posts are clearly in line with every other phrase in the charter. Personally I would not agree with your interpretation that Aryeh's posts contradict "strictly technical," but then again I have never really thought long and hard about what "strictly technical" means in this context. Now to your point about "straw men", I have refrained from doing as others have done, and have not tried to ascribe motives as to why this particular discussion has so offended people. But the overreaction to Aryeh's posts is definitely a mystery, and I can understand why people are speculating. The idea of a new mailing list: if the discussion about ports design got to overwhelm ports@, then it would become time to create a new mailing list. But up until now, the ports design posts with genuine content (as opposed to the "get out of here" posts) have been sufficiently few and sufficiently non-disruptive to this mailing list, that I don't think it is worth while to do this. If people simply responded to Aryeh's posts with strictly technical answers, the whole discussion would have been a few posts. I do agree that Aryeh's discussions are not along the lines of "port XXX is not working", but I just don't see why both kinds of posting cannot coexist in peaceful harmony, with a split happening only if one set of discussions threatens to overwhelm the other. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
On Thu, 13 Dec 2007 21:58:57 +0100 Erik Trulsson <[EMAIL PROTECTED]> wrote: > One shortcoming is the lack of locking making parallell builds a bit unsafe. > If you try to build both port A and port B at the same time, and both A and > B depends (directly or indirectly) on port C which is not installed, then > you can esily end up having two processes both trying to build C at the same > time. This usually confuses both builds very badly making them fail. > > I also don't think there is any locking on /var/db/pkg making possibly > somewhat unsafe trying to register the installation of two ports/packages at > the same time. I have never noticed any actual problems with this though. > > > Some sort of locking, making parallel builds safe, should be possible to > add to the ports system without doing any sweeping changes. > (I did look briefly at the makefiles, but did not find any obvious place > to put the locking. I probably just did not look hard enough.) The ports system is to "install" a new port. It won't be easy to accomplish what you suggest. For example, dependencies are checked one at a time. So, even if you want to run multiple processes on LIB_DEPENDS, there is no easy way to control CPU load. It is a better idea for other "ports UPGRADE" utilities to take care of your suggestions. Indeed, I have been developing such utility myself. If you want to try, I can give out for testing. There are 2 known issues with my tool, yet: 1. no good way to run 'make config', yet, and 2. even if less LIB_DEPENDS are required due to less selected OPTIONS, my tool does not fully eliminate these dependencies. Hiro ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yoshihiro Ota wrote: > On Thu, 13 Dec 2007 21:58:57 +0100 Erik Trulsson > <[EMAIL PROTECTED]> wrote: > >> One shortcoming is the lack of locking making parallell builds a >> bit unsafe. If you try to build both port A and port B at the >> same time, and both A and B depends (directly or indirectly) on >> port C which is not installed, then you can esily end up having >> two processes both trying to build C at the same time. This >> usually confuses both builds very badly making them fail. >> >> I also don't think there is any locking on /var/db/pkg making >> possibly somewhat unsafe trying to register the installation of >> two ports/packages at the same time. I have never noticed any >> actual problems with this though. >> >> >> Some sort of locking, making parallel builds safe, should be >> possible to add to the ports system without doing any sweeping >> changes. (I did look briefly at the makefiles, but did not find >> any obvious place to put the locking. I probably just did not >> look hard enough.) > > The ports system is to "install" a new port. It won't be easy to > accomplish what you suggest. For example, dependencies are checked > one at a time. So, even if you want to run multiple processes on > LIB_DEPENDS, there is no easy way to control CPU load. > > It is a better idea for other "ports UPGRADE" utilities to take > care of your suggestions. Indeed, I have been developing such > utility myself. If you want to try, I can give out for testing. > There are 2 known issues with my tool, yet: 1. no good way to run > 'make config', yet, and 2. even if less LIB_DEPENDS are required > due to less selected OPTIONS, my tool does not fully eliminate > these dependencies. > Your correct that there are 2 seperate issues at play here but there is a common solution (and to be honest I have yet to see any feature/issue discussed in any of the re-engineering threads that doesn't at least become more manageable under this general design concept I am working under) I hate to keep referring to Miller97 but I think it highlights (directly or indirectly) every single issue that has been discussed while a little off topic (and slightly self serving) there is a good explanation of the general idea behind what I have in mind in the cook tutorial (I am the author thus it is self-serving) http://miller.emu.id.au/pmiller/software/cook/cook-2.30.tut.pdf.. In the the specific case of parallel builds once we pre-scan the DAG it is trivial to do a *FULL* DFS on it and just say for any time two ports are not in the same DFS generated subtree in respect to some root target (can be recursive) they can be build in parallel. Locking is also trivial now that the decision on ordering is made by the ports system and not indivual ports makefiles. (the indivual make files are still needed to build the port but should not and by definition can not contain knowledge about their depends). Side note the more we discuss this the more obvious it becomes to me it has to be in some OO lang and since C++ is the only one in the base system it kind of forces C++ to be the implementation lang. - -- Aryeh M. Friedman FloSoft Systems http://www.flosoft-systems.com Developer, not business, friendly -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHY1hWzIOMjAek4JIRArNwAJwMEsZVVMTnl3F4T96BfWGY/PHy2ACaA/RZ NGtCCzJp3z90MwP/UWGrp5o= =tTt4 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[ports/graphics/opencv] Add support V4L compat.
Hi Marc.
I'm tring to use opencv with USB camera. So I hope to support
Video for Linux compat to opencv. May I commit following patch?
Index: Makefile
===
RCS file: /home/ncvs/ports/graphics/opencv/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- Makefile7 Oct 2007 17:46:15 - 1.6
+++ Makefile15 Dec 2007 05:39:13 -
@@ -8,7 +8,7 @@
PORTNAME= opencv
PORTVERSION= 1.0.0
-PORTREVISION= 1
+PORTREVISION= 2
CATEGORIES=graphics
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE}
MASTER_SITE_SUBDIR=opencvlibrary
@@ -16,6 +16,8 @@
MAINTAINER=[EMAIL PROTECTED]
COMMENT= Open Source Computer Vision Library from Intel
+BUILD_DEPENDS=
${LOCALBASE}/include/linux/videodev.h:${PORTSDIR}/multimedia/v4l_compat
+
CFLAGS+= -I${LOCALBASE}/include/OpenEXR
CPPFLAGS+= -I${LOCALBASE}/include -I${LOCALBASE}/include/OpenEXR
LDFLAGS+= -L${LOCALBASE}/lib
@@ -24,7 +26,7 @@
USE_LDCONFIG= yes
GNU_CONFIGURE= yes
CONFIGURE_ENV= CPPFLAGS="${CPPFLAGS}" LDFLAGS="${LDFLAGS}"
-CONFIGURE_ARGS=--without-v4l --without-quicktime --without-carbon \
+CONFIGURE_ARGS=--with-v4l --without-quicktime --without-carbon \
--without-1394libs \
--without-swig # I don't know anything about
swig ...
CONFIGURE_TARGET=--build=${MACHINE_ARCH}-portbld-freebsd${OSREL}
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ports/graphics/opencv] Add support V4L compat.
On Sat, 15 Dec 2007 14:43:29 +0900
Norikatsu Shigemura <[EMAIL PROTECTED]> wrote:
> I'm tring to use opencv with USB camera. So I hope to support
> Video for Linux compat to opencv. May I commit following patch?
Oops! I forgot that there is a added patch. Please look at
following patch.
Index: Makefile
===
RCS file: /home/ncvs/ports/graphics/opencv/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- Makefile7 Oct 2007 17:46:15 - 1.6
+++ Makefile15 Dec 2007 05:39:13 -
@@ -8,7 +8,7 @@
PORTNAME= opencv
PORTVERSION= 1.0.0
-PORTREVISION= 1
+PORTREVISION= 2
CATEGORIES=graphics
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE}
MASTER_SITE_SUBDIR=opencvlibrary
@@ -16,6 +16,8 @@
MAINTAINER=[EMAIL PROTECTED]
COMMENT= Open Source Computer Vision Library from Intel
+BUILD_DEPENDS=
${LOCALBASE}/include/linux/videodev.h:${PORTSDIR}/multimedia/v4l_compat
+
CFLAGS+= -I${LOCALBASE}/include/OpenEXR
CPPFLAGS+= -I${LOCALBASE}/include -I${LOCALBASE}/include/OpenEXR
LDFLAGS+= -L${LOCALBASE}/lib
@@ -24,7 +26,7 @@
USE_LDCONFIG= yes
GNU_CONFIGURE= yes
CONFIGURE_ENV= CPPFLAGS="${CPPFLAGS}" LDFLAGS="${LDFLAGS}"
-CONFIGURE_ARGS=--without-v4l --without-quicktime --without-carbon \
+CONFIGURE_ARGS=--with-v4l --without-quicktime --without-carbon \
--without-1394libs \
--without-swig # I don't know anything about
swig ...
CONFIGURE_TARGET=--build=${MACHINE_ARCH}-portbld-freebsd${OSREL}
Index: files/patch-otherlibs-highgui-cvcap_v4l.cpp
===
RCS file: files/patch-otherlibs-highgui-cvcap_v4l.cpp
diff -N files/patch-otherlibs-highgui-cvcap_v4l.cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ files/patch-otherlibs-highgui-cvcap_v4l.cpp 15 Dec 2007 05:45:59 -
@@ -0,0 +1,10 @@
+--- otherlibs/highgui/cvcap_v4l.cpp.orig 2006-09-27 10:40:03.0
+0900
otherlibs/highgui/cvcap_v4l.cpp2007-12-15 14:44:37.0 +0900
+@@ -209,7 +209,6 @@
+
+ #include
+ #include
+-#include /* for videodev2.h */
+ #include
+ #include
+ #include
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
