Re: Should /usr/bin/perl be a link to /usr/local/bin/perl ?
Quoting Yuri : I found that many ports specify /usr/bin/perl as an interpreter. This comes from Linux. Examples: valgrind-snapshot, windowmaker, enscript-a4, a2ps, svgalib Just for the record, it does not come from Linux. Specifying /usr/bin/perl as the interpreter is a Perl convention which was established before Linux (or FreeBSD for that matter) even existed. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Why delete KDE3 ports?
Quoting "Mikhail T." : On 07.01.2013 09:54, Kimmo Paasiala wrote: Are you willing to step up as the maintainer of the KDE3 ports? Or anyone else reading this? The situation with ports like KDE3 is that they are lots of work to keep up in shape and if no one wants to maintain them they succumb to what is called "bitrot" very quickly when something changes in dependent ports or in the base system. When/if that happens, we can renew the conversation. For the time being there are no build errors. Indeed. That a port is old is not a good reason to remove it. That a port is unmaintained is also not a good reason to remove it. If a port stops working and nobody steps up to fix it, *then* removal becomes a reasonable action, but not before that. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Perl symlinks question
On Tue, Jan 10, 2012 at 12:46:51AM +0100, Oliver Heesakkers wrote:
> Op ma 09 jan 2012 22:49:33 schreef Ruslan Mahmatkhanov:
> > Hi.
> >
> > There is PR: http://bugs.freebsd.org/163687
> > It tries to fix port building when user built it's perl installation
> > with USE_PERL option (creating symlinks in /usr/bin) set to off (not the
> > default). Patch in PR just replaces static shebang with ${PERL} variable
> > from Mk/bsd.perl.mk. But it doesn't actually fix the build, because
> > consequent call of aclocal-1.11 will fail since it's shebang set to
> > '/usr/bin/perl' too.
> >
> > The question is how to properly handle this PR:
> > 1. Fix devel/automake too (by replacing /usr/bin/perl with ${PERL})
> > 2. Create symlinks unconditionally in perl port and drop USE_PERL option
> > 3. Close PR as invalid since the build fails because of user
> > intervention (changing the value of default option)
>
> 4. Teach upstream (and maybe maintainers) to use /usr/bin/env as they should
> do:
>
> http://perldoc.perl.org/perlintro.html#Running-Perl-programs
That may be the modern way of doing it, but older versions of the Perl
documentation used to recommend using /usr/bin/perl, so there are most
likely a ton of perl scripts out there (only a small fraction of which
appears in the FreeBSD ports tree) which use that convention.
It is also worth noting that even the current version of the Perl
documentation refers to /usr/bin/perl in numerous places and recommends
that it exists as a symlink to the perl binary.
--
Erik Trulsson
ertr1...@student.uu.se
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: HEADS UP: ports/ and 10.0-CURRENT
On Tue, Sep 27, 2011 at 08:22:54AM -0400, Robert Huff wrote: > > krad writes: > > we can leave that to our grand children to figure out though 8) > > Wasn't that what people said about two-digit years? Not quite. There they mostly said "No way that this program will still be in use when two-digit years becomes a problem!" -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: LDFLAGS support for bsd.port.mk and CPPFLAGS/LDFLAGS cleanup
On Sun, Sep 25, 2011 at 02:41:36PM +0400, Lev Serebryakov wrote: > Hello, Dmitry. > You wrote 24 2011 ??., 3:36:14: > > > The patch was committed, LDFLAGS and CPPFLAGS and now handled > > similarily, shouldn't be passed to CONFIGURE_ENV and should be > > altered by += like C/CXXFLAGS. > Add devel/dbus-glib to the list... > Should I make formal PR for all these ports? I could build all those ports just fine ysterday (after the referenced commit went in) and there has not yet been a wide outcry of people having trouble building ports, so I suspect the problem is local to your machine. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports-system priorities rant (Re: sysutils/cfs)
On Thu, Sep 08, 2011 at 06:36:46PM +0200, Matthias Andree wrote: > Am 08.09.2011 16:15, schrieb Mikhail T.: > > > Having a poor port of an obscure > > piece of software is better, than no port at all. > > A poor port is undesirable (and shouldn't be in the tree in the first > place). Highly debatable. It is clear that a poor port is undesirable compared to a good port, but very often a poor port is more desirable than no port at all. > > An obscure piece of software is undesirable (and shouldn't be ported in > the first place). Bullshit! Keep in mind that FreeBSD itself is a fairly obscure piece of software in that most people in the world have never heard of it. For any given individual something like 90+% percent of the ports in the ports-tree could count as obscure since that person has never heard of that particular piece of software before. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: sysutils/cfs
On Thu, Sep 08, 2011 at 06:54:36PM +0200, Matthias Andree wrote: > Am 08.09.2011 13:52, schrieb Matt Burke: > > > Changing to a hypothetical example, why would an Apache vulnerability in > > mod_rewrite in the least bit bother a person who doesn't have the module > > enabled, which I believe is the standard configuration? Would you prefer > > Apache be deleted from ports if it took longer than expected to fix it? > > That wouldn't happen anyways because the package is actively maintained, > unlike many of the ports the discussion is about. You (and others) place *far* too much emphasis on a piece of software being "maintained" > > > What the current FreeBSD policy of actively deleting perfectly usable ports > > instead of putting a mild hurdle in the way is saying, is that FreeBSD will > > stop me doing what I may want to do because FreeBSD knows best. > > The port isn't perfectly usable (because that would mean it's usable in > all circumstances for all advertised purposes, which is explicitly not > the case in the light of known vulnerabilities). In which case just about no port is 'perfectly usable' since almost all non-trivial software contains bugs - at least some of which are not documented, meaning that it isn't usable in *all* circumstances for *all* advertised purposes. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: sysutils/cfs
On Wed, Sep 07, 2011 at 09:25:15AM -0600, Chad Perrin wrote: > On Wed, Sep 07, 2011 at 09:37:07PM +1000, Peter Jeremy wrote: > > On 2011-Sep-07 01:35:54 -0600, Chad Perrin wrote: > > > > > > One thing I've seen come up that I definitely think would be a good > > > idea, though, is more accessible documentation of the CVS "attic", > > > though. I had no idea such a thing existed for old FreeBSD ports > > > until fairly recently, and still don't know much about it. > > > > Any VCS worthy of the name will retain history for objects that no > > longer exist because you might want to look at the state as it was at > > some point in the past when that object still existed. CVS stores the > > RCS masters for these deleted files is a subdirectory 'Attic' under > > the original directory. The data is only accessible via CVS - either > > using a local repository or via CVSweb. As an example, look at: > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/audio/xmms/?hideattic=0 > > My understanding is that you are saying "attic" is just the standard term > for CVS history. Is that the case, or do I misunderstand your point? Almost correct. "Attic" is the standard term for where CVS stores files that have been deleted. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: sysutils/cfs
On Wed, Sep 07, 2011 at 09:37:07PM +1000, Peter Jeremy wrote: > On 2011-Sep-06 23:30:04 -0700, Stanislav Sedov wrote: > >What about requiring that the ports deprecated should be either broken > >or have known published vulnerabilties for a long period of > >time (say 6 months) for the start? > > This might be reasonable for broken ports but ports with known > vulnerabilities should either be fixed or removed promptly. That depends somewhat on the exact nature of the vulnerability. Depending on how the port is used a given vulnerability might not be a problem. (E.g. if a port has a vulnerability which allows a local user to become root, then it is a problem for multi-user systems with untrusted users, but for a system which only has a single user or only trusted users it would not be a significant problem.) If a port can be used safely despite existing vulnerabilities it is not at all clear it need to be removed quickly even if it is not fixed. (Marking it FORBIDDEN so potential users are warned about known problems is another thing.) -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Thu, Apr 28, 2011 at 12:39:52AM +0200, John Marino wrote: > On 4/28/2011 12:18 AM, Erik Trulsson wrote: > > And if the committers can't choose what they are going to work on, you > > are likely going find yourself with a lot fewer committers fairly soon. > > > As you notice, I never said they are limited what they work on. The > order of the work is the focus. But if they are forced to do certain tasks first, there might well not be time over to do other things later. I.e. they are limited in what they work on. > > > > And who is going to do all that extra work? You volunteering? > > If finding a volunteer is the only thing holding a reform back, then we > have nothing to worry about. Hardly the only thing, merely one of the things. > > There is also the question of what to do if a committer doesn't like > > all the proposed extra rules and bureacracy and simply ignores a PR he > > has been assigned. There isn't really any way force a given committer > > to work on something he doesn't want to work on. The only sanction > > available is to remove the commit bit at which point you have one > > committer less, and that work still isn't done. > I was working the assumption that he agrees to the port up front or > voluntarily picks up the next task. However, if someone has a repeated > history of refusals or only wants to do a very narrow set of tasks, then > maybe commit bit removal isn't that dramatic. I didn't say anything about dramatic. My point is that removing that persons commit bit would not serve any useful purpose, and is not enough punishment that the threat of it is likely to convince any committer to do anything he doesn't fell like doing. > > Worth it for who? Hardly to the guy who is going to do the extra work. > > As for "fair" you haven't convinced me why it should be a requirement. > > I don't consider it extra work. I consider it doing the job correctly. > And if I need to convince you that "fair" is correct, then basically I > just wasted 5 minutes answering this post. Jerry pretty much outlined > why it's correct to process these things in order, or at some semblance > of order. Only under certain assumptions that are far from obviously correct. > > Look, your mind is made up. You like the status quo. Everything is > fine and no effort should be made to improve. I'm not interested in a > long, drawn out discussion. I just wanted to give my opinion which I > did, so I'm done. Oh, I am not saying that the current situation is ideal. It isn't. Far from it. What I am saying is that your proposed solution is a bad idea that is more likely to cause problems than to solve them. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Wed, Apr 27, 2011 at 10:12:57AM -0400, Jerry wrote: > On Wed, 27 Apr 2011 15:48:36 +0200 > Erik Trulsson articulated: > > > On Wed, Apr 27, 2011 at 09:32:58AM -0400, Jerry wrote: > > > On Wed, 27 Apr 2011 08:50:52 -0400 > > > > > > However, I do find troubling you statement regarding a large update > > > to an older port or even a new port submission for that matter. I > > > see no logical reason for a committer to bypass an item simple > > > based on its size or the amount of work involved in getting it > > > committed. After all, consider that the original submitter invested > > > a large amount of his/her time in that same item. > > > > Very simple. A particular committer during one particular period of > > time maybe only 45 minutes of free time to spend on handling PRs. > > If the committer estimates that one large submitted PR would take at > > least two hours to review, test, and commit, while another, smaller, > > PR would only take 30 minutes to handle. > > > > Then the committer in question would have two choices: Don't handle > > either submission, or handling the smaller submission, while skipping > > the large one and hoping that some other committer with more free time > > will pick up that one. > > I see no reason to prefer the first of these choices. > > If the committer cannot finish the project in their allotted time > frame they simply stop and pick up from that point in their next > session. Or they can take a look at that project, decide that they are not interested in doing that particular project, and say "Screw this, I have better things do with my free time" and go off and read a book instead. > I have literally hundreds of projects that I cannot complete > in one day; however, I don't simply shrug them off. If I did nothing > would ever get accomplished, or at best only the easiest assignments. Hundreds? Sounds a bit excessive if you were to ask me. If you have that many things to do then FIFO is a downright stupid way to approach them unless you know you have enough time to do *all* of them. (And it is rare that there is that much time available.) With that many things to do one needs to prioritize. First one should do the important stuff, and if there is any time left after having done that one might as well pick the fun projects, because there just isn't much point in doing boring, unimportant stuff. > > One of the basic fallacies in your analysis is that someone else will > pick up the slack. Unfortunately, our society has become over run by > those who are always ready to blame others or expect others to do our > job for us. Quite honestly, I find that pathetic. And yet you are so quick at blaming committers for not doing things the way you think they should be done. Pot. Kettle. Black. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Wed, Apr 27, 2011 at 08:54:05PM +0200, John Marino wrote: > On 4/27/2011 4:12 PM, Jerry wrote: > > On Wed, 27 Apr 2011 15:48:36 +0200 > > Erik Trulsson articulated: > > > >> On Wed, Apr 27, 2011 at 09:32:58AM -0400, Jerry wrote: > >> Very simple. A particular committer during one particular period of > >> time maybe only 45 minutes of free time to spend on handling PRs. > >> If the committer estimates that one large submitted PR would take at > >> least two hours to review, test, and commit, while another, smaller, > >> PR would only take 30 minutes to handle. > >> > >> Then the committer in question would have two choices: Don't handle > >> either submission, or handling the smaller submission, while skipping > >> the large one and hoping that some other committer with more free time > >> will pick up that one. > >> I see no reason to prefer the first of these choices. > > If the committer cannot finish the project in their allotted time > > frame they simply stop and pick up from that point in their next > > session. I have literally hundreds of projects that I cannot complete > > in one day; however, I don't simply shrug them off. If I did nothing > > would ever get accomplished, or at best only the easiest assignments. > > > > One of the basic fallacies in your analysis is that someone else will > > pick up the slack. Unfortunately, our society has become over run by > > those who are always ready to blame others or expect others to do our > > job for us. Quite honestly, I find that pathetic. > > > > I seemed to have kicked off quite a dialog! First of all, I want to > thank Frederic Culot for committing my patch today. > > Basically, I'm in complete agreement with Jerry with regards to FIFO. > The proposal was made that given a short amount a time, a committer > should choose the simpler project and bypass the first one simply based > on time/complexity. I couldn't disagree more. As soon as it's possible > to skip valid ports, then that's what is going to happen. If people can > physically cherry-pick, then they'll exercise their ability to do that > and immediately you sink into the current situation. And if the committers can't choose what they are going to work on, you are likely going find yourself with a lot fewer committers fairly soon. > > Unfortunately, a FIFO setup requires that all the requests go through a > single entity who then assigns them. And who is going to do all that extra work? You volunteering? > I don't really buy the > joe-the-font-guy with mary-the-network-gal mismatch. Nobody said the > PRs have to be assigned as round-robin. And then that changes the > dynamic since the PR is assigned rather than chosen. This entity can't > just assign a PR without knowing the committer's timeline, availability, > etc, so there are clearly implementation details to work out. Details indeed, and the devil is in the details as the saying goes. First of all there is no entity that knows about the timeline, availability, etc. of the various committers. The only way to get that information would be if committers were to report it at regular intervals which they don't have any reason to do. There is also the question of what to do if a committer doesn't like all the proposed extra rules and bureacracy and simply ignores a PR he has been assigned. There isn't really any way force a given committer to work on something he doesn't want to work on. The only sanction available is to remove the commit bit at which point you have one committer less, and that work still isn't done. > > Maybe a compromise would be to keep the current system in place with the > addition of having somebody do these assignments if the new PRs are > unclaimed for more than 3-7 days. Yes, it means a new job for someone, > but if one believes that FIFO is the fair and respectful approach, the > extra effort should be worth it. Worth it for who? Hardly to the guy who is going to do the extra work. As for "fair" you haven't convinced me why it should be a requirement. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On Wed, Apr 27, 2011 at 05:05:57PM -0400, Eitan Adler wrote: > >> apache13 is EOL upstream. We should not have ports for EOL software. > > > > Why not, exactly?.. > > What happens if a security hole or a bug is found? Are we the ones to > fix it? If yes are we to host the patches? Where should the bug > reports go to - our bug tracker? What if our implementation ceases to > match established documentation? Should we host the docs too? "We"? Who is this "we" you keep talking about here? If a port has a security hole then it is up to the maintainer to find a fix for it - if this fix is a patch he/she comes up with or a switch to a newer upstream version is irrelevant. If there is no maintainer and nobody else provides a fix either, it is time to mark the port as FORBIDDEN and DEPRECATED and remove it after the deprecation period expires, just like how other broken ports are handled. > > The ports collection is one of *third party* software (with a couple > of small exceptions). If the third party says "this program is done, > has bugs which won't be fixed, etc" we should no longer support it. Depends on what you mean by "support", but removing a port just because upstream development has ceased is just plain silly. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Wed, Apr 27, 2011 at 09:32:58AM -0400, Jerry wrote: > On Wed, 27 Apr 2011 08:50:52 -0400 > > However, I do find troubling you statement regarding a large update to > an older port or even a new port submission for that matter. I see no > logical reason for a committer to bypass an item simple based on its > size or the amount of work involved in getting it committed. After all, > consider that the original submitter invested a large amount of his/her > time in that same item. Very simple. A particular committer during one particular period of time maybe only 45 minutes of free time to spend on handling PRs. If the committer estimates that one large submitted PR would take at least two hours to review, test, and commit, while another, smaller, PR would only take 30 minutes to handle. Then the committer in question would have two choices: Don't handle either submission, or handling the smaller submission, while skipping the large one and hoping that some other committer with more free time will pick up that one. I see no reason to prefer the first of these choices. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Wed, Apr 27, 2011 at 08:05:43AM +0200, John Marino wrote: > Since we're already in the mood to discuss FreeBSD ports issues, maybe > somebody can clear something up for me. > > Several days ago, I submitted a patch for a port I maintain: > ports/156541 "[MAINTAINER] Upgrade lang/gnat-aux to release version > and add C++" > > Nobody has touched it, but many other PRs after that submission have > been assigned, etc. So I have two questions: > > 1) What's involved with processing a patch from a maintainer? Is it > simply a committer commits it on behalf of the maintainer (iow very > easy?). Or is it the other end of the spectrum where it has to go > through Tinderbox? I would assume the maintainer is trusted and the > patch is applied without testing. A committer is always responsible for his/her commits and so should do at least minimal testing of any patches even if it is from a maintainer. > > 2) I have very well aware that people dedicate their own time, etc, and > I think that explains why the PRs are getting cherry picked. But > seriously, shouldn't there be a policy to process these PRs in order? Not really, since some PRs might require a *lot* of work (and/or might be controversial) and thus could block other, far simpler, PRs if they were taken strictly in order. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Dropping maintainership of my ports
On Wed, Apr 27, 2011 at 12:15:43AM -0700, Charlie Kester wrote: > On Tue 26 Apr 2011 at 23:27:40 PDT John Marino wrote: > > > >You're just sulking because your idea of identifying popular ports > >wasn't met with enthusiasm. > > > > No, it's more than that. I got the distinct impression that many of the > committers would be unhappy if I took maintainership of some of the > ports I might identify as "popular", because it would interfere with > their plans to trim the portstree. Then you have misunderstood things. I don't think anybody would be unhappy if you (or anybody else) took maintainership of one or more of the currently unmaintained ports. What plans there are, are not so much about trimming the portstree in general but trimming the number of unmaintained ports. What is met with uninterest is your plans to identify "popular" ports. > Re-read the thread. At every point I'm talking about looking for ports > I (and others) might want to maintain, as a service to their users. Now > ask yourself why I've been getting so much resistance to that, when we > keep hearing how deprecated ports can be easily resurrected if someone > steps up to maintain them? Actually you spend much time speaking about/looking for "popular" ports and that is what is met with uninterest. If you want to take maintainership of a port because you personally use that port and want to have it working, that is great. If you want to take maintainership of a port because you believe that it is a "popular" port, then go ahead, just don't expect much help with identifying such ports. > > Every response from the committers ignored what I said I was trying to > do, and instead repeated the same old arguments about stale, > unfetchable, broken or superceded ports. That "talking points" response > tells me that they didn't want me doing what I was doing to buck an > already-established policy of letting unmaintained ports die unless and > until someone complains. (Actually the policy is that unmaintained and non-working ports should be let to die, unless somebody steps up to fix the port and take maintainership.) Nobody is stopping you from assuming maintainership of one or more of those unmaintained ports, and thus preventing them from being removed. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Best way to uninstall X
On Thu, Apr 07, 2011 at 11:31:27PM +0400, Konstantin Tokarev wrote: > > > 07.04.2011, 23:15, "David Demelier" : > > On 07/04/2011 19:29, Konstantin Tokarev wrote: > > > >> 07.04.2011, 20:59, "Attos";: > >>> Hello all, > >>> > >>> What is the best way to uninstall X and all the applications that run > >>> under > >>> X? > >>> > >>> Thanks in advance. > >> rm -rf /* > > > > This kind of answers can be avoided. > > WIll you argue it doesn't uninstall "X and all the applications that run > under X?" :) Plus a lot of other stuff...Yes, it will do that, but the question was specifically for "the best way" of doing it which I don't think that particular solution qualifies as. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: opera
On Tue, Oct 26, 2010 at 07:43:55AM -0400, Robert Huff wrote: > > ajtiM writes: > > > My question is: does FreeBSD doesn't "like" Opera to much? In > > this case is better to live choice to Opera users that installed > > the browser when and where they wanted and quit porting it. > > The port is maintained by: > > freebsd-maintai...@opera.com > > If it's behind the curve, complain to Opera. But first check if there is any pending PR with uncommitted patches: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/151471 -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Double versions installed
On Sun, Sep 19, 2010 at 06:07:02PM +0200, Jos Chrispijn wrote: > I have now installed two versions of autoconf: That is perfectly normal. Some programs require one specific version of autoconf, while others require another version, so one easily ends up with more than one version installed. They can live side-by-side so having more than one version installed is not a problem. > > autoconf-2.13.000227_6 Automatically configure source code on many > Un*x platforms > autoconf-2.67Automatically configure source code > on many Un*x platforms > > Can someone tell me how I can get rid of the first one? Thank you. Just use pkg_delete to remove it. If anything has it as a run-time dependency (most unlikely) pkg_delete will complain and refuse to remove it so you donät need to worry about breaking anything by removing it. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: UPDATING entry for X.org changes
On Fri, May 07, 2010 at 08:25:56AM -0400, Robert Huff wrote: > > =?ISO-8859-1?Q?Ren=E9_Ladan?= writes: > > > > Is there one? I've been checking daily, and ... nothing. > > > (Various sited, including just now "cvsup.freebsd.org:.) > > > > No, there is indeed none for now. > > Obvious question: why not? Even if all it says is "use > 'portmaster -af' or portupgrade equivalent", isn't having such a > huge event go unremarked in front-line documentation a Bad Idea(tm)? No, not really. The entries in UPDATING are really only intended for the cases where the Usual Procedures(tm) for updating are not sufficient and the user needs to take some kind of special action. For the recent X.org change users are not supposed to need to do anything special when upgrading, and thus there is no need for an entry in UPDATING. The size of the upgrade is not really relevant for if it gets an entry in UPDATING or not, only if some kind of special action is needed. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: graphics/png
On Sun, Mar 28, 2010 at 07:47:36AM -0500, ajtiM wrote: > In the /usr/ports/UPDATING is: > > "20090328: > AFFECTS: users of graphics/png > AUTHOR: din...@freebsd.org > > The png library has been updated to version 1.4.1. Please rebuild all > ports that depend on it. > > If you use portmaster: > > portmaster -r jpeg- > > If you use portupgrade: > > portupgrade -fr graphics/jpeg" > > Is this mistake or I don't understand, please? A mistake. It should obviously say 'png' rather than 'jpeg'. I believe a fix for this has already been commited. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: editors/joe + textproc/aspell: dependency problem?
On Mon, Mar 08, 2010 at 12:50:05PM +0100, Oliver Fromme wrote: > Hi, > > I just csupped fresh ports on a new stable/8 box, installed > textproc/aspell-without-dicten (i.e. with WITHOUT_DICTEN=YES) > and then proceeded to install editors/joe. Both installed > successfully, as far as I can tell. There were no error > messages, and joe seems to work fine. But ... > > joe has a dependency on aspell (both build dependency _and_ > run dependency), so I expected it to be recorded in the > package database. But it isn't. pkg_info -r joe\* and > pkg_info -R aspell\* don't report this dependency. > > While building joe, it _does_ display that it depends on > aspell, and it correctly reports it as "found". It also > depends in libiconv, which _is_ correctly recorded in the > package database. > > Am I doing something wrong, or is there a bug somewhere? If there is a bug it is in the ports system in general when a given dependency can be fulfilled by more than one port. If a port declares that it depends on file/library/whatever "foo" from the port "bar", but you have "foo" installed from the port "baz" then the dependency check will be fine (since it finds "foo") but when the dependency should be registered in the package database it will try to register a dependency on the package "bar", which is not installed, and then no dependency is registered. (In your case "foo" = "/usr/local/bin/aspell", "bar" = "textproc/aspell", and "baz" = "textproc/aspell-without-dicten".) It might be better if a dependency was registered on the package that the depended-on file actually was installed from, but this is currently not done. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Recent massive port update.
On Fri, Feb 05, 2010 at 06:25:42PM +0300, cvs-...@yandex.ru wrote: > Hi there. > I see some massive port update in past hours, but not see what the > reason of it (nor on freebsd-ports@, nor on freshports.org). Can > anybody shed the light what was changed? The graphics/jpeg port was updated such that the version number of libjpeg.so was increased. This necessitated a revision bump in all the ports that depend on graphics/jpeg. There are *many* such ports. > > Thanks. > > [r...@smeshariki2 ~]# portsnap fetch > Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found. > Fetching snapshot tag from portsnap1.FreeBSD.org... done. > Fetching snapshot metadata... done. > Updating from Fri Feb 5 06:44:34 MSK 2010 to Fri Feb 5 15:57:40 MSK 2010. > Fetching 4 metadata patches... done. > Applying metadata patches... done. > Fetching 0 metadata files... done. > Fetching 4282 patches. > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: can't update system.
On Tue, Jan 12, 2010 at 09:45:35PM +0600, keneasson wrote: > Hello, > > Forgive cross posting, i have an unusable system and an not sure where to > post. > This follows up a more lengthy post, but i've got some new info so again. > > libxul requiers libiconv > libiconv requires libxul libiconv does not require libxul AFAICT. > > i have WITH_GECKO=libxul in make.conf That is likely what is causing your problems. Remove that line and see if things work better. > > i'm using FreeBSD 8.0-stable. > > thanks. > ken > ___ > freebsd-questi...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: remove BUILD_DEPENDS automatically after install
On Sun, Nov 15, 2009 at 11:44:04PM +0100, Sandra Kachelmann wrote: > Is there a reason why BUILD_DEPENDS aren't being removed after a port > has been installed and if no other installed port depends on it? How do you know that the user does not want that port installed? And what if the user will install 20 other ports afterwards - all of which is that same port as a BUILD_DEPENDS - should that port be installed/deinstalled each and every time? (Personally I would be *very* annoyed if, for example, libtool or automake/autoconf would be reinstalled every time I installed a port which had one of them as a build-time dependency. There are *lots* of ports which have one of them in BUILD_DEPENDS, but few if any that has them as RUN_DEPENDS.) -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: lsof build failed under FreeBSD 7.2-STABLE AMD64
[lsof maintainer added to Cc:] On Sun, Nov 01, 2009 at 12:10:07PM -0600, Larry Rosenman wrote: > Are your system sources current? and do they match the running system? > > it compiles file for me on: But if you update your FreeBSD system to the very latest (or at least after Oct 29) it will not compile fine for you either. The following commit to 7-stable broke lsof compilation: Author: jhb Date: Thu Oct 29 15:10:38 2009 New Revision: 198595 URL: http://svn.freebsd.org/changeset/base/198595 Log: MFC 196615: Extend the device pager to support different memory attributes on different pages in an object. - Add a new variant of d_mmap() currently called d_mmap2() which accepts an additional in/out parameter that is the memory attribute to use for the requested page. - A driver either uses d_mmap() or d_mmap2() for all requests but not - both. The current implementation uses a flag in the cdevsw (D_MMAP2) to indicate that the driver provides a d_mmap2() handler instead of d_mmap(). This is done to make the change ABI compatible with existing drivers and MFC'able to 7 and 8. The lsof source code contains code to handle the problem for -CURRENT. The following part from dialects/freebsd/dlsof.h is the relevant part which describes the problem and contains a solution for 9-CURRENT. # if FREEBSDV>=9000 /* * The FreeBSD 9 and above d_mmap2_t function typedef in needs * the definition of vm_memattr_t for a pointer, but that definition is only * available under _KERNEL in . Defining _KERNEL before * including causes many compilation problems, so this * expedient (hack) is used. */ #define vm_memattr_tvoid # endif/* FREEBSDV>=9000 */ #include # if FREEBSDV>=9000 #undef vm_memattr_t # endif/* FREEBSDV>=9000 */ The 'if FREEBSDV>=9000' parts need to be mofified to make it work for older releases too now that the d_mmap2_t function has been MFC'd. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: lsof won't build
On Sun, Sep 20, 2009 at 03:15:32PM -0400, Robert Huff wrote:
> Lowell Gilbert writes:
>
> > It seems to me (fairly short investigation) that it uses kernel
> > structures that aren't in /usr/include. That means it must be
> > looking in /usr/src/sys. If those sources don't match the
> > installed kernel exactly, that typically won't be a problem,
> > because kernel interfaces are intended to not change within a
> > major-number release.
>
> If you say so. My recent experience started with lsof compiled
> under stock 8.0 beta 4, which was was incompatible with some change
> that happened around the branch of 9.0 CURRENT. And there's nothing
> in {src, ports}/UPDATING which would suggest the need for a change.
But that is not within a major-number release. 8.0 is still not released
and from a compatibility view should still be considered as -CURRENT, and
9.0-CURRENT is, well, -CURRENT. In -CURRENT non-compatible changes do
happen from time to time, and is often not mentioned in UPDATING, because
people running -CURRENT are not supposed to need such reminders.
--
Erik Trulsson
ertr1...@student.uu.se
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/*/jpeg "Thanks a lot guys"
On Fri, Jul 31, 2009 at 12:12:49PM -0400, Jason J. Hellenthal wrote: > > Now that I have finally upgraded my system in full from the last mix-up > with jpeg, You guys have bumped up every PORTREVISION that depends on jpeg > "Great real great" Now I get to spend another three days fixing up some > more packages and rebuilding about 800+ ports. > > Thanks a whole lot. Nobody is forcing you to rebuild your ports just because the PORTREVISION was bumped. If everything works fine for you there is actually no good reason at all to do so. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: make.conf no x option
On Wed, May 27, 2009 at 03:52:53AM +0900, Randy Bush wrote: > > Something like the following would work as a safety net. > > > > --- /usr/ports/Mk/bsd.xorg.mk.orig 2009-05-26 13:42:52.0 +0100 > > +++ /usr/ports/Mk/bsd.xorg.mk 2009-05-26 13:42:58.0 +0100 > > @@ -28,6 +28,11 @@ > > # xserver - there's only one atm, I guess everything can fit into the > > port itself > > > > .if defined(XORG_CAT) > > + > > +. if defined(WITHOUT_X11) > > +IGNORE=me not want x11 > > +. endif > > + > > # Default variables, common to all new modular xorg ports. > > .if !defined(USE_TGZ) > > USE_BZIP2= yes > > looks useful. Perhaps, but it would change the meaning of 'WITHOUT_X11=yes' quite a bit, so I do not think it would be suitable to commit to the ports tree as-is (and I hope nobody had planned on doing that.) (At the moment 'WITHOUT_X11=yes' means that those ports which have optional support for X11 should be built without it. With the patch above it would change to mean that the ports system will refuse to build *any* port which depends on X11.) > > i think this whole thing is worth a few days to settle in our heads. > essentially, if we believe that freebsd is used extensively in headless > server deployments, we should make that easy and smooth. But even a headless server can run X clients with the display being on some other (presumably non-headless) machine. That is on of the beauties of the X Windowing System. The only part that would make no sense to install on a headless machine is the X server itself, which almost no ports depend on anyway (and those which do are mainly other components of X.) -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: make.conf no x option
On Tue, May 26, 2009 at 08:44:43PM +0900, Randy Bush wrote: > >> as so many folk build server-only, there must e a make.conf or whatever > >> option to tell ports that you just do not want an x server or any of > >> it's 500kg friends. but i can not seem to find it. > > I think you're looking for WITHOUT_X11=yes :) > > i have that. i still get a lot of x with some ports. i will try to > keep a watch for which ones. Well, there are many ports which depend unconditionally upon X. If you install one of them (or some other port which depends on one of them) you will get X, no questions asked. WITHOUT_X11 is useful for those ports which have an optional dependency upon X, but that is all it does. There does not exist any flag which tells the ports-system to refuse to build any ports which depend on X, which seems to be what you want. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: always-interactive ports
On Mon, Nov 24, 2008 at 01:55:55PM +0200, Andriy Gapon wrote:
>
> I wonder if we have any flag for always-interactive ports i.e. ports
> that prompt user for something regardless of all batch/interactivity
> options. One example is java/jdk* ports that prompt user for license
> acceptance.
>
> If we don't have such a flag, maybe we should add one.
>
> One use, for instance, is to skip such ports for portupgrade --batch.
>From /usr/ports/Mk/bsd.ports.mk :
# IS_INTERACTIVE
# - Set this if your port needs to interact with the user
# during any step in a package build. User can then decide
# to skip this port by setting ${BATCH}, or compiling only
# the interactive ports by setting ${INTERACTIVE}.
# Default: not set.
--
Erik Trulsson
[EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports missing their packages.
On Wed, Oct 29, 2008 at 05:02:14PM +0800, joeb wrote: > How does kdenetwork-kopete-0.12.8 or php5-gd or pdflib fit into those > reasons you gave? > These all have ports but no package for many releases of Freebsd. > For print/pdflib it is legal restrictions. (The Makefile says "RESTRICTED= many odd restrictions on usage and distribution") As for graphics/php5-gd and net-im/kopete ports, they both seem to be available as pre-built packages so I am not sure what problem you are having with them. > > > -Original Message- > From: Erik Trulsson [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 29, 2008 4:47 PM > To: FBSD1 > Cc: [EMAIL PROTECTED] ORG; [EMAIL PROTECTED] > Subject: Re: ports missing their packages. > > On Wed, Oct 29, 2008 at 04:09:23PM +0800, FBSD1 wrote: > > It's my understanding that a port maintainer has to install the port for > > real any time a change is made to the port make files or a update to the > > source of the software to test and verify the changes work as wanted. > > Creating the package after this is just one command and a ftp upload to > the > > package server. Why are maintainers being given approval to apply their > > changes without creating the required package? This is just lax management > > on the part of the people who do the authorizing of the changes. Missing > > packages increases user frustration level and makes FreeBSD look like its > > being mis-managed. > > It is not port managers who create or upload packages. Most of them do not > even have access to the package server. > The downloadable packages are built and uploaded automatically by a cluster > of servers that do little else. > > If a particular port does not have a corresponding package it is generally > not due to laxness on anybodys part. > > The main reasons why a port might not have corresponding package are: > > 1) The port has just been created and the package hasn't had time to built >yet. Normally a very temporary situation. > > 2) Legal restrictions. There are several ports where it is simply not legal >for the FreeBSD project to distribute the corresponding binary packages. > > 3) The port is currently broken and cannot be built. (This is of course a >bug which should be fixed as soon as possible. For ports without a >maintainer that might take a while.) > > 4) One or more of the dependencies of the package is not available as a >package. (If port A depends on port B, and there does not exist a >package for B (for any of the reasons listed here) there will not be >a package of A either. > > > > > > > An alternate solution to this problem is to allow users to upload missing > > packages to the package server direct or to a staging ftp server so > port/pkg > > management staff can review first and them populate the production package > > server. > > All the packages that can be built and distributed are already being built > and uploaded. Allowing users to upload packages would not help. > -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports missing their packages.
On Wed, Oct 29, 2008 at 04:09:23PM +0800, FBSD1 wrote: > It's my understanding that a port maintainer has to install the port for > real any time a change is made to the port make files or a update to the > source of the software to test and verify the changes work as wanted. > Creating the package after this is just one command and a ftp upload to the > package server. Why are maintainers being given approval to apply their > changes without creating the required package? This is just lax management > on the part of the people who do the authorizing of the changes. Missing > packages increases user frustration level and makes FreeBSD look like its > being mis-managed. It is not port managers who create or upload packages. Most of them do not even have access to the package server. The downloadable packages are built and uploaded automatically by a cluster of servers that do little else. If a particular port does not have a corresponding package it is generally not due to laxness on anybodys part. The main reasons why a port might not have corresponding package are: 1) The port has just been created and the package hasn't had time to built yet. Normally a very temporary situation. 2) Legal restrictions. There are several ports where it is simply not legal for the FreeBSD project to distribute the corresponding binary packages. 3) The port is currently broken and cannot be built. (This is of course a bug which should be fixed as soon as possible. For ports without a maintainer that might take a while.) 4) One or more of the dependencies of the package is not available as a package. (If port A depends on port B, and there does not exist a package for B (for any of the reasons listed here) there will not be a package of A either. > > An alternate solution to this problem is to allow users to upload missing > packages to the package server direct or to a staging ftp server so port/pkg > management staff can review first and them populate the production package > server. All the packages that can be built and distributed are already being built and uploaded. Allowing users to upload packages would not help. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc versions following upgrade 6.3 >7.0
On Tue, Jul 22, 2008 at 01:07:53AM -0700, David Southwell wrote:
> On Monday 21 July 2008 23:27:49 Garrett Cooper wrote:
> > On Mon, Jul 21, 2008 at 4:09 AM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
> > > On Mon, Jul 21, 2008 at 03:11:25AM -0700, [EMAIL PROTECTED] wrote:
> > >> FreeBSD **.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 16
> > >> 09:27:38 PDT 2008 @**.vizion2000.net:/usr/obj/usr/src/sys/GENERIC
> > >> amd64 # pkg_info |grep gcc
> > >> gcc-4.1.3_20080630 GNU Compiler Collection 4.1
> > >> gcc-4.2.5_20080702 GNU Compiler Collection 4.2
> > >> gccmakedep-1.0.2Create dependencies in makefiles using 'gcc -M'
> > >>
> > >> Should both versions be installed?
> > >
> > > That depends. Are you using any ports which depend on specific versions
> > > of GCC? The base system version comes with gcc 4.2.1. There may be
> > > ports which require older or newer GCC, however.
> > >
> > > "pkg_info -R" should help you determine what ports are dependant upon
> > > those two GCC ports.
> >
> > There isn't anything wrong with having multiple compilers installed on
> > a given system, insomuch as they install within separate directories
> > or are prefixed differently. The sym-/hard-links for the compiler last
> > installed may be the one that gets used though (not sure because I
> > don't have any experience installing gcc from ports on FreeBSD)...
> >
> > >> Do they not place files in same place?
> > >
> > > No.
> >
> > This ties into the reply above, but if you have a compiler provided by
> > the base system and a compiler provided by ports, they won't install
> > in the same location, as ${PREFIX} dictates in ports.
> >
> > -Garrett
> What happens, as in this instance, the system was originally on 6.1 then 6.3
> &
> subsequently upgraded to 7.0?
The version of gcc shipped with 6.3 is 3.4.6.
What probably happened was that you installed some port that required
gcc 4.1 or newer to build, and thus gcc-4.1 was installed automatically as
part of the dependencies for that port.
Later you installed some port that needed gcc 4.2 or later, at which point
gcc-4.2 was installed for you.
If you had been running 7.0 from start, then the gcc ports would not have
been needed, since (as has been noted) FreeBSD 7.0 includes gcc 4.2.
>
> How can I tell whether the versions were installed by the base system or via
> ports?
If they show up with pkg_info, then they were installed via the ports
system.
>
> I am not clear about how the system distinguishes between gcc installed via
> ports and via base system.
Installed in different places: Just about everything installed from ports
(or packages) will end up under /usr/local/ (or on older systems under
/usr/X11R6/) Files that are part of the base system will not be installed
there.
> Indcidentally when did gcc become part of the base
> system?
gcc has always been part of the base system. (Otherwise it would have been
difficult to recompile the base system, or to compile any ports.)
--
Erik Trulsson
[EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: koffice-kde3 compile failure on amd64
On Wed, Jul 09, 2008 at 06:52:54AM -0700, David Southwell wrote: > Here it is.. > > Does anyone know how to fix this one? > Thanks in advance > ___ > then mv -f ".deps/karbon.la.Tpo" ".deps/karbon.la.Po"; else > rm -f ".deps/karbon.la.Tpo"; exit 1; fi > /bin/sh /usr/local/bin/libtool --silent --tag=CXX --mode=link > c++ -Wno-long-long -Wundef -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 > -O2 -fno-strict-aliasing -pipe -Wno-non-virtual-dtor -fno-exceptions > -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST > -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DHAVE_KNEWSTUFF > -L/usr/local/lib -o > karbon -R /usr/local/lib -R /usr/local/lib -R /usr/local/lib -R > /usr/local/lib -R /usr/local/lib -no-undefined -L/usr/local/lib > -D_THREAD_SAFE -pthread -L/usr/local/lib > karbon.la.o > libkdeinit_karbon.la -Wl,-export-dynamic -L/usr/local/lib -ljpeg > -L/usr/local/lib > /usr/local/lib/libMagickCore.so: undefined reference to `DrawSetViewbox' > /usr/local/lib/libMagickCore.so: undefined reference to `DrawScale' > /usr/local/lib/libMagickCore.so: undefined reference to > `DrawSetTextUnderColor' Yes, I have seen a similar problem before. If you have the graphics/ImageMagick port installed, then the koffice-kde3 build will somehow try to link against that instead of the libraries installed by the graphics/GraphicsMagick port (which it should use.) (Note that the file /usr/local/lib/libMagickCore.so is installed by graphics/ImageMagick, not by graphics/GraphicsMagick.) If you deinstall ImageMagick, and then try to reinstall koffice-kde3 it should work. Afterwards you can reinstall ImageMagick again if you wish. (As far as I can tell it is only when building and installing koffice-kde3 that the presence of ImageMagick is a problem, not when running it.) -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports/124985: [patch] devel/dmucs unbreak on 64bits archs
On Mon, Jul 07, 2008 at 07:20:17PM +0200, Pietro Cerutti wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Kostik Belousov wrote: > | On Mon, Jul 07, 2008 at 06:34:54PM +0200, Pietro Cerutti wrote: > |> I definitely do not agree. Please note that a pointer is not required to > |> fit into a long, while it is required to fit into a size_t. > | I do not think that C99 requires the size_t to be capable of holding > | the pointer. size_t is only required to hold result of sizeof. > > size_t is required to be of rank equal to or greater than any other > object you can create from within the C language. This implies that it > can (i.e., it is required to be able to) hold a pointer type. Wrong. There is no requirement in C that there exists *any* integer type large enough to hold a pointer - and certainly not that size_t is such a type. size_t must be large enough to hold the size of any object that the C implementation allows you to create, but there is no requirement that you can create an object that occupies the whole memory space. (E.g. if you had an implementation that did not allow to create any arrays larger than 4GB or to malloc() more than 4GB at a time, then it would suffice to have a 32-bit size_t even if pointers were 64-bit. (For older machines make that: 64KB objects, 16-bit size_t and 32-bit pointers.)) > > | > | It is intptr_t type that shall do it. > > Unfortunately intptr_t is not defined prior to C99, and I still haven't > got used to use it. Yes, that would be the preferred solution. > -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: devel/gettext notification in /usr/ports/UPDATING
On Fri, Jun 06, 2008 at 06:38:51PM +0200, Dominic Fandrey wrote: > Dominic Fandrey wrote: > > I don't really understand why it's there and why it's recommending to > > rebuild > > all ports. > > > > I have 761 ports installed, but only 173 of them depend on gettext, so > > why should > > I reinstall more than 530 ports that don't need to be rebuild. > > > > What's even worse according to my shell-script pkg_libchk not a single > > one of > > the 173 ports depending on gettext needs to be rebuild because of libintl. > > Great, all ports depending on devel/gettext got bumped. > > My Shell script checks every single library and executable on the system > with ldd and it says _nothing is amiss_ after upgrading devel/gettext. And how does it know that all the existing libraries and executables are completely compatible with the new devel/gettext? > > Now I am condemned to rebuild ~100 ports, even though it is completely > unnecessary. Nobody forces you to rebuild them if you do not think it is necessary. > I do not have to tell you that downloading all the distfiles > over a GSM connection will take days. If you already have built the ports once, you will probably have most of the distfiles already. > And all this for no reason at all! > > What's going on here? > > Ldd says it's not necessary. Can anyone really argue with that? How can ldd determine that it is not necessary? -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: About closed-source ports...
On Sun, Jun 01, 2008 at 02:23:15AM -0700, ck74 wrote: > > > Hello! > > Couls someone please tell me how a user can restrict freebsd to install > open-source ports only? Well, for example if you want to install www/opera, > 'make install' does not warn user that this port uses closed-source (binary > distribution) only. There is no general mechanism in place for that. Installing software that is partly or completely closed-source is not really something that it is considered that users need to be warned about. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: where to find old ports.tar.gz files
On Sun, Feb 03, 2008 at 10:46:20AM -0800, Jin Guojun [VFFS] wrote: > I need to get wine 0.9.37 to 0.9.39 ports build structure, mainly the > ports/emulatoes/wine/Makefile > to build these wine releases on FreeBSD 6.3-R, but I cannot find older > ports.tar.gz files. > > Does anyone know where I can find older ports.tar.gz files that contain > wine 0.9.37 to 0.9.39 releases? > > Thanks, > -Jin > You can always pull any version of source files (including the ports tree) directly from the CVS repository. See http://www.freebsd.org/developers/cvs.html for information on how to do that. You will however not find any version of the ports tree that include Wine 0.9.37 or 0.9.38 because support for those versions were never added to the ports tree as far as I can tell. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Migrating to AMD64
On Mon, Jan 07, 2008 at 11:14:49AM -0800, Brian wrote: > Pav Lucistnik wrote: >> Cy Schubert pí?e v po 07. 01. 2008 v 09:15 -0800: >> >> >>> Is there a documented or preferred approach to migrate ports from i386 to >>> AMD64? Portupgrade has issues. Deleting and reinstalling 1954 ports by >>> hand would be a monumental project. Any suggestions? >>> >> >> Reinstall from scratch. >> >> > Something like this can be used to uninstall all ports. > > cd /var/db/pkg; find . -type d | xargs pkg_delete Yes, but it is even easier to just do a pkg_delete '*' to delete all installed ports/packages. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is skype only usable on intel and not on AMD64?
On Mon, Dec 31, 2007 at 07:43:09AM -0600, eculp wrote: > When trying to install skype on an acer amd turrion64x2 model 5520-5679 > using the latest Current snapshot for AMD64, I see the following: > > /usr/ports/net/skype # make install > ===> Installing for skype-1.2.0.18,1 > ===> skype-1.2.0.18,1 depends on file: > /compat/linux/usr/lib/libfontconfig.so.1 - found > ===> skype-1.2.0.18,1 depends on file: > /compat/linux/usr/lib/libexpat.so.0 - found > ===> skype-1.2.0.18,1 depends on file: > /compat/linux/usr/X11R6/lib/libGL.so.1 - not found > ===>Verifying install for /compat/linux/usr/X11R6/lib/libGL.so.1 in > /usr/ports/graphics/linux_dri > ===> linux_dri-7.0 is only for i386, while you are running amd64. > *** Error code 1 > > Stop in /usr/ports/graphics/linux_dri. > *** Error code 1 > > Maybe I am missing something in my linux emulation. I have installed > > linux_base-f7-7 > > and in sysctl.conf > > compat.linux.osrelease=2.6.16 > You are not missing anything. Skype depends on graphics/linux_dri and graphics/linux_dri currently only works on i386. I do not know what would be needed to make it work on other architectures as well. -- Erik Trulsson [EMAIL PROTECTED] ___ 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 10:34:06PM -0500, 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. What I suggested should not present any major difficulties. I did not propose automatic parallelization, or anything that needs to control CPU load in way. What I wanted is just support for manual execution of two parallel port builds. E.g. I want to be able to write 'cd /usr/ports/x11/gnome2 ; make install' in one virtual terminal and then, while the first command is running and installing all kinds of dependent ports, to able to switch to another terminal and write 'cd /usr/ports/x11/kde3 ; make install' without having to worry about the fact that some ports (like x11/xorg-libraries) will be needed by both builds. (Assume that I have already done a 'make config-recursive' for both gnome2 and kde3.) Currently doing the above will not work reliably. All that should be needed to make it work reliably is to add some kind of locking so that the ports system will not try to build a port if a build of that particular port is already in progress. (I suspect that using lockf(1) at appropriate places in /usr/ports/Mk/bsd.port.mk would be sufficient, but there are almost certainly a bunch of details and corner-cases that need to be considered.) > > 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 -- Erik Trulsson [EMAIL PROTECTED] ___ 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, Dec 13, 2007 at 10:42:43AM -0500, Steven Kreuzer wrote: > This thread was called "results of ports re-engineering survey" but I > figured I would start a new thread. > > On Dec 12, 2007, at 6:45 AM, Ade Lovett wrote: >> >> >> We *know* it can be done better. We *know* the scaling limits of the >> current system, and most of us are completely amazed it even still works. >> >> If y'all want to make a difference, concepts and ideas we have plenty of. >> Code talks. > > Out of curiosity, are any of these shortcomings documented anywhere? I have > been using ports on my home machine for a long time and I've never > had any problems with it. I assume the issues come into play when you work > with multiple systems you are trying to keep in sync, etc. > > I would be interested in reading about some of the limitations people have > run into when using ports. 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.) -- Erik Trulsson [EMAIL PROTECTED] ___ 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, Dec 13, 2007 at 11:17:34AM -0700, Warren Block wrote: > On Thu, 13 Dec 2007, Steven Kreuzer wrote: > >> This thread was called "results of ports re-engineering survey" but I >> figured I would start a new thread. > > Rightly so. > >> On Dec 12, 2007, at 6:45 AM, Ade Lovett wrote: >>> We *know* it can be done better. We *know* the scaling limits of the >>> current system, and most of us are completely amazed it even still works. >>> If y'all want to make a difference, concepts and ideas we have plenty of. >>> Code talks. >> >> Out of curiosity, are any of these shortcomings documented anywhere? I >> have been using ports on my home machine for a long time and I've never >> had any problems with it. I assume the issues come into play when you work >> with multiple systems you are trying to keep in sync, etc. >> >> I would be interested in reading about some of the limitations people have >> run into when using ports. > > Notable with the new modular Xorg is the speed of changes > (install/deinstall/clean) when there are a lot of ports installed. Before > modular xorg, 400 ports installed was a lot. 700 now is not surprising. > > Some profiling looking for areas which could benefit from speed > optimization would be useful. That may have already been done but not > publicized. There were some modifications added to the ports tree earlier this year (I think it was) that resulted in some quite significant speedups when installing/deinstalling ports. There were quite a bit of discussions about it at the time at this list (or possibly one of the other freebsd- lists.) -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (Very) bogus package dependencies
On Thu, Dec 06, 2007 at 06:22:58PM -0500, Alex Goncharov wrote: > There has been a point recently made on a `freebsd-' list about > unnecessary dependencies of the `xorg-server' package, it being > dependent on `gnome' and `hal', for example. That's a valid point and > I am with those who don't want this dependency to exist -- but at > least this dependency can be somehow justified. > > But I cannot find any justification for this: > > > $ pkg_info -R cdrtools* > Information for cdrtools-2.01_6: > > Required by: > hal-0.5.8.20070909 > xf86-input-keyboard-1.2.2_1 > xf86-input-mouse-1.2.3 > xf86-video-i810-1.6.5_3 > xf86-video-radeonhd-1.0.0 > xorg-server-1.4_3,1 > > > `xf86-video-radeonhd-1.0.0' requires `cdrtools'?... > > How can this happen? Am I missing something? It looks like an ordinary indirect dependency. The drivers as well as the xorg-server all require 'hal'. 'hal' depends on 'cdrtools'. (It may be that the drivers only depend on xorg-server, which does depend on hal.) As for why 'hal' requires 'cdrtools' I have no idea, but there is probably some reason for it. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [RFC/P] Port System Re-Engineering
On Mon, Dec 03, 2007 at 05:33:09PM -0500, Aryeh M. Friedman wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Carl Johan Gustavsson wrote: > > Aryeh M. Friedman wrote: > >> perl (what is the difference between the 5.8.8 in the base system > >> and the one in ports?!?!?!?) > >> > > The base system does not contain Perl. > > Then why is it compiled by buildworld? It isn't - not unless you are running FreeBSD 4.x or older (and then it would have been Perl version 5.005_03.) Perl was removed from the base system (in what was then 5-CURRENT) back in 2002 and has certainly not been added back again. Perl 5.8.8 has never been part of the base system, nor compiled by buildworld. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Are there any maintainer for mplayer?
On Sun, Dec 02, 2007 at 04:26:45AM +0100, Andreas Davour wrote: > On Sat, 1 Dec 2007, Mark Linimon wrote: > >> On Sun, Dec 02, 2007 at 03:54:28AM +0100, Andreas Davour wrote: >>> I looked in the Makefile for mplayer but couldn't find any MAINTAINER. >> >> $ cd multimedia/mplayer >> $ make maintainer >> [EMAIL PROTECTED] >> >> Looks like it's maintained to me ... > > The make target "maintainer" was news to me. I've always grep'ed for > "Maintainer" in the makefile. This time I did like this: > cat Makefile* | grep aintainer > and thought I should have found it. Thanks for setting me straight. Try doing a cat Makefile* | grep -i aintainer instead. Then you will also find "MAINTAINER", which I believe is how it is normally spelled. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: duration of the ports freeze
On Sat, Dec 01, 2007 at 11:49:11AM -0800, David Southwell wrote: > On Saturday 01 December 2007 10:28:40 Erik Trulsson wrote: > > > > Personally, as a user, I have never really been even slightly inconvienced > > by any of the ports tree freezes. > > All I can say is bully for you! The question is how do we get rid of a > p[roblem even if it is not a disadvantage for you personally. It is > disappointing when one hears arguments not to change simply because one > particular individual is not disadvantaged by a currently illogical and > antiquated solution to a problem that will inevitably grow as the number of > ports increase. I am quite certain that I am not alone or even unusual in not having a problem with the current situation. I believe that for the majority of FreeBSD users the port freezes do not constitue a major problem - or even a problem at all. The current situation apparently constitute a problem for you, which is too bad, but you have failed to convince me that you are representative for more than a very small minority of FreeBSD users - and it is of course not possible to satisfy everybody. (And it is anyway not me you need to convince, since I have no official standing at all in the FreeBSD project.) As for your earlier claims that the process is developer-centric rather than user-centric, I would say that claim is just plain wrong. If anything I would say the code-freezes of both the base system and the ports tree is more inconvenient for the FreeBSD committers and port mainttainers than for the average user. The intent is to make sure each release is in good shape, in the belief that this is what is most important for the average user (from which follows that the state of the ports tree between releases is of somewhat lesser importance.) This belief might of course be wrong, but so far little evidence has been given to contradict it. It is disappointing to hear arguments to change simply because one particular individual is disadvantaged by the current situation, without any regard given to the fact that such a change might actually inconvenience a larger number of people. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: duration of the ports freeze
On Sat, Dec 01, 2007 at 09:48:34AM -0800, David Southwell wrote: > On Saturday 01 December 2007 08:48:41 Erik Trulsson wrote: > > On Sat, Dec 01, 2007 at 07:49:00AM -0800, David Southwell wrote: > > > On Saturday 01 December 2007 05:58:21 Thierry Thomas wrote: > > > > On Sat 1 dec 07 at 14:25:08 +0100, Erik Trulsson > > > > <[EMAIL PROTECTED]> > > > > > > > > wrote: > > > > > The ports freeze is intended to make sure the ports tree is in a > > > > > stable and well tested state for the release. Updating major ports > > > > > always carry a great risk of breaking things thus defeating the point > > > > > of the freeze. > > > > > > > > Anyway, if the freeze is too long, and if the new version is released > > > > several weeks after the thaw, very few will install these packages: > > > > a lot of updates will be committed, and many users will update their > > > > ports tree to install the new versions. This is very difficult to find > > > > a good compromise! > > > > > > I do not think we need a compromise we need a different system. We need > > > one that preserves continuity of support for existing systems while the > > > new releases are testedin a way that does not adversely impact them. The > > > priority needs to be the current user base not a desire to rush a new > > > release out the door at all costs. > > > > > Considering that FreeBSD releases almost always get delayed by several > > weeks compared to the original schedule I think it is safe to say that "a > > desire to rush a new release out the door at all costs" is something that > > the FreeBSD project certainly does not suffer from. > > I believe this to be head in the sand logic.IMHO It is rushing it out the > door > at all costs if the cost is a port freeze!!! I do not follow your logic at all. I do not see the rushing part occuring. The ports freeze is a consequence of *not* rushing out the release, but instead pausing and making sure everything is right before making the release. > A port freeze is the most user > unfriendly act that one could think of! Not even close. Having lots of broken ports would be much more user unfriendly. To most users a ports freeze is probably no more than a minor inconvenience, if they even notice it. > > > > Now it may be that due to the ports freeze, there will be some ports whose > > upgrade will be delayed for a couple of weeks (not to be confused with > > those ports whose upgrade gets delayed for other reasons.) > > I do not consider this to be a major problem. > > > > I think you vastly overestimate the need for the ports tree to always have > > the latest versions of all softwares contained therein. > > The ports system and new release development systems need to move seemlessly > not interfere with one another. This means a rethink of the fundamental > assumptions that drive current policies and practice. What "fundamental assumptions" are you thinking of? > > > > In those very rare cases where a user just cannot wait 2-3 weeks extra for > > an upgrade, they can always try to build the software themselves outside > > the ports system. > > I regard this view as developer centric rather than user centric. As I have > said elsewhere the ports system is freebsd msp and users are not naturally > comnfortable with building outside the ports system. If they were we would > not need the system!!! I believe there is only a quite small minority of users who actually *need* to have all the ports updated as quickly as possible. Most of those users are probably sufficiently technically proficient to be able to handle building things outside the ports system. All those users who want to be able to install a new release with accompanying packages and just want it to work 'out of the box' without *having* to upgrade anything are probably better off with the current policies. I don't know, but I suspect those are the majority of ordinary users. Personally, as a user, I have never really been even slightly inconvienced by any of the ports tree freezes. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: duration of the ports freeze
On Sat, Dec 01, 2007 at 07:49:00AM -0800, David Southwell wrote: > On Saturday 01 December 2007 05:58:21 Thierry Thomas wrote: > > On Sat 1 dec 07 at 14:25:08 +0100, Erik Trulsson <[EMAIL PROTECTED]> > > > > wrote: > > > The ports freeze is intended to make sure the ports tree is in a stable > > > and well tested state for the release. Updating major ports always carry > > > a great risk of breaking things thus defeating the point of the freeze. > > > > Anyway, if the freeze is too long, and if the new version is released > > several weeks after the thaw, very few will install these packages: > > a lot of updates will be committed, and many users will update their > > ports tree to install the new versions. This is very difficult to find a > > good compromise! > > I do not think we need a compromise we need a different system. We need one > that preserves continuity of support for existing systems while the new > releases are testedin a way that does not adversely impact them. The priority > needs to be the current user base not a desire to rush a new release out the > door at all costs. Considering that FreeBSD releases almost always get delayed by several weeks compared to the original schedule I think it is safe to say that "a desire to rush a new release out the door at all costs" is something that the FreeBSD project certainly does not suffer from. Now it may be that due to the ports freeze, there will be some ports whose upgrade will be delayed for a couple of weeks (not to be confused with those ports whose upgrade gets delayed for other reasons.) I do not consider this to be a major problem. I think you vastly overestimate the need for the ports tree to always have the latest versions of all softwares contained therein. In those very rare cases where a user just cannot wait 2-3 weeks extra for an upgrade, they can always try to build the software themselves outside the ports system. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: duration of the ports freeze
On Sat, Dec 01, 2007 at 05:14:55AM -0800, David Southwell wrote: > On Saturday 01 December 2007 Pav Lucistnik <[EMAIL PROTECTED]> answered part > of > the question: > > On Friday 30 November 2007 21:47:07 Jason C. Wells wrote: > > > Peter Jeremy wrote: > > > > On Fri, Nov 30, 2007 at 03:04:14PM -0600, Mark Linimon wrote: > > > >> On Fri, Nov 30, 2007 at 07:50:02AM -0800, Jason C. Wells wrote: > > > >>> It wouldn't surprise me if portmanager is hoping that KDE 4.0 will go > > > >>> prime time real soon. That's my big conspiracy theory. > >> > >> > >> > >> package builds out the door. The Razor, and past experience, would > >> > >> suggest that sweeping changes would delay all that significantly. > >> > > > >> > > As a corollary, KDE4 will not hit the ports tree until after 7.0 and > >> > > 6.3 are released. > .> > > >> > We lucked out last time and got current updates of both gnome and kde. > >> > > >> > "It would be a pleasant surprise if portmgr were able to take KDE 4.0 to > >> > prime time real soon." > >> > > >> > Later, > >>>Jason > >> > ___ > >> > >> I must say I am having difficulty understanding the policies applicable > >> during ports freeze. > >> > > What criteria are used to determine whether an update is allowed or barred > > during the freeze? > > Pav Lucistnik <[EMAIL PROTECTED]> answered part of the question with this > interjection: > > >David Southwell pí??e v so 01. 12. 2007 v 03:08 -0800: > > >> What criteria are used to determine whether an update is allowed or barred > >> during the freeze? > > >1) Security update > >2) Build fix on one of the release platforms > >3) Major runtime fix > > > > This seems sensible unless: > a) The freeze is unduly long (I would suggest more than two weeks) > AND > b) There is a major upgrade of a port which is used by a large proportion of > users. AND c) The upgrade is very unlikely to break things. An upgrade to KDE or Gnome or X.org or similarily gargantuan ports (or many smaller ports too for that matter) fail point c). > > In which case I believe such major upgrades should be favourably considered. > Such a policy would reflect the fact that there are many users who need to > keep their systems up to date (especially when they workin communities where > multiple operating systems are in use). Allowing port freezes to extend for > long periods should not IMHO be allowed to conflict with the need to keep > major ports updated. The ports freeze is intended to make sure the ports tree is in a stable and well tested state for the release. Updating major ports always carry a great risk of breaking things thus defeating the point of the freeze. > > This puts added weight to my second question to which I am hoping for some > response: > >> The freeze seems to be of longer duration than originally expected while > >> the current inconvenience seems to growing exponentially. I appreciate the > >> long term benefits so please do not think I am in any way critical of those > >> who are working on this. > >> > >> I would hgowever like to ask, on the basis of what is being learned now, > >> how could the length freezes be diminished on future occasions? > >> -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can the following license be used for ported programs?
On Sun, Sep 23, 2007 at 05:10:53PM +, Aryeh Friedman wrote: > My company develops software under a commercial "open source" (see > links for details) and I want to know if my license is close enough to > open source (see links for why it is not 100% OSD compliant [it is 95% > compliant]). Specifically does the business model as outlined in my > blog (the third installment should be out later today), my business > model page, the third party certifier and license allow for inclusion > in the ports collection. Keep in mind that the source is available > to anyone but execution is conditioned on attachment A of the license > and after the trial period (30 days) is paid for software. > > License: http://www.flosoft-systems.com/license.php > Official statement of my business model: > http://www.flosoft-systems.com/bmodel.php > Blog entries: > http://www.flosoft-systems.com/blogs/aryeh/FOSS.php > http://www.flosoft-systems.com/blogs/aryeh/SIW_Background.php > Third party group (due to DNS issues is currently hosted on my domain > but is not officially associated with my company): > http://www.flosoft-systems.com/miai/ For inclusion in the ports tree it really does not matter much what license you use for your software - it could even be a commercial closed-source program. The reason for this is that the ports tree is just a framework for installing and managing software packages, and none of your code will actually live in the ports tree. If you have various restrictions in the license then it may not be possible for the FreeBSD project to distribute binary packages or source files. If that is the case the port creator should set RESTRICTED or other appropriate variable in the port Makefile to enforce this (see http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-restrictions.html for what variations are possible.) -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to get a list of all kernel modules
On Sun, Jun 17, 2007 at 12:15:16AM -0600, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> "[LoN]Kamikaze" <[EMAIL PROTECTED]> writes:
> : [LoN]Kamikaze wrote:
> : > M. Warner Losh wrote:
> : >> Greetings,
> : >>
> : >> is there an easy way to get a list of all the ports that compile
> : >> kernel modules? I'd like to add them to my kernel build. I did this
> : >> once before, but I lost all information on how to do it when I lost my
> : >> laptop's hard disk after the last bsdcan...
> : >>
> : >> Warner
> : >
> : > # find /boot/ -type f -exec pkg_info -W \{} \;
> :
> : Sorry about that, it takes very long. Better is:
> :
> : # sh -c 'for mod in `pkg_info -qaL|grep -E "^/+boot"`; { pkg_info -W
> "$mod"; }
>
> This sounds great, except for one problem. This will tell me all the
> modules that I've installed that are from ports. Since I've never
> installed any from ports, this will not work for what I want. I want
> a list of all the ports in /usr/ports that install kernel modules.
> I'd even settle for a list of all the ports in /usr/ports that only
> install modules.
>
> Something like
> egrep -l '\.ko$' /usr/ports/*/*/pkg-plist | sed -e s=/pkg-plist//
> might do the trick, but that blows the command line limits out of the
> water. Replacing egrep with 'find' would need to be carefully
> constructed to avoid false positives in any work directories I have
> laying around. I was hoping for something a little easier to do...
Keep in mind that not all ports have a 'pkg-plist' file. Some ports list
that info directly in the Makefile.
I don't think there is any way of doing what you want without searching
through every single Makefile/pkg-plist file in the entire ports tree.
--
Erik Trulsson
[EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to get a list of all kernel modules
On Sun, Jun 17, 2007 at 01:22:57AM -0500, Mark Linimon wrote: > On Sun, Jun 17, 2007 at 12:15:16AM -0600, M. Warner Losh wrote: > > I want a list of all the ports in /usr/ports that install kernel modules. > > IIRC they're all in misc/. Let me see if I can come up with a quick list. Not all of them are in misc/. One counter-example is emulators/kqemu-kmod, another is x11/nvidia-driver. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rsync as a daemon doesn't play nice with rcng
On Thu, Nov 30, 2006 at 05:09:43PM -0500, Bill Moran wrote: > > Noticed that the rsync port has an rcng compliant script for starting > rsync in daemon mode. Nice. > > Unfortunately, rsync doesn't seem to write its pidfile to /var/run, > and doesn't seem to even _support_ doing so. The documentation suggests that it *does* support doing so. The rsyncd.conf(5) manpage (referenced by the rsync(1) manpage) mentions a "pid file" option that seems to be exactly what you want. (The rsync port also installs an example rsyncd.conf into /usr/local/etc/ that sets that option.) I have never actually tried running rsync in daemon mode so I don't know if the above actually works, but it certainly seems like it should. > As a result, the rc > system is unable to determine when it's running, thus stop and > restart work poorly. > > Is there a mechanism within the rc system that can work around this > so the rc script can be improved? > > -- > Bill Moran > Collaborative Fusion Inc. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Merging X11BASE to LOCALBASE
On Wed, Jul 19, 2006 at 01:32:06AM -0500, Mark Linimon wrote: > On Tue, Jul 18, 2006 at 09:43:54PM +0200, Dag-Erling Smørgrav wrote: > > This makes no sense at all, since X.org is (by definition) X11R7. > > They changed the protocol? I thought that was what the suffix was > originally for. No, not really. The suffix is mainly just a revision number for the code base. The (major) version number for the protocol is the '11' part, which has not been changed for nearly 20 years now. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
