Re: PR problem -file handling.. long files
On Thu, Jun 28, 2007 at 06:38:24AM -0700, David Southwell wrote: > There is a difficulty when posting PR's when a large debug file is needed to > be posted to the PR as an attachment. Do you mean, via the web form or via send-pr(1)? The latter has a limit of 500k, via the FreeBSD.org email system. If something is larger than that, I would prefer that the debug file simply be posted to the web and a URL included. If you can't host the file yourself, email [EMAIL PROTECTED] and we'll host it somewhere. This way the size of the database won't grow as much. 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: ChartDirector
On Mon, Jul 02, 2007 at 12:34:20PM +0200, Tim Rijavec wrote: > can you add this package for ChartDirector for php to FreeBSD ports? > that can be found at http://www.freebsd.org/ports/master-index.html Please use send-pr to submit this so that it won't just get lost in the mailing list traffic. See: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/index.html http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/index.html mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make fetchindex failure
On Tue, Jul 03, 2007 at 11:19:04PM +0700, budsz wrote: > So the best way I should upgrade my system to FreeBSD 6.X series?, Yes, that is what we have been recommending for some time now. > BTW which one: > > "tag=RELEASE_4_EOL" or "tag=RELEASE_4" ?, I've already read in > handbook and didn't find exactly "tag=RELEASE_4_EOL" :-( There was a README posted to ports@ about how to do this. OTOH if you have already upgraded your ports past the RELEASE_4_EOL point, then your best choice is to just go ahead and upgrade to 6.2. Otherwise, you are going to have to revert your ports tree and then deal with the fallout of having any ports you have upgraded since the RELEASE_4_EOL tag was laid down, and that would be a complete waste of time. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade creates bogus messages
I went ahead and fixed it. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
recent updates to portsmon.freebsd.org
I have just updated portsmon to the most recent development code. Most of this code has to do with the ability to create dependency graphs of failed or broken ports, and is not yet totally automated; thus, it is not (yet) visible to users. Other code has to do with internal schema changes. The most user-visible change is the new ability to be able to show a page of "ports that fail on only one build environment". For example: http://portsmon.freebsd.org/portsconcordanceforbuildenv.py?buildenv=i386-7-full&buildenv2=i386-6-full will show you the list of ports that fail on i386 but only on -current, not on -stable. Please let me know if you experience any problems with the upgrade. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposal for another category in INDEX: common_deps
On Fri, Jul 20, 2007 at 05:11:27PM +0200, Michel Talon wrote: > The only relevant info for determining what to install or build > previously is RUN_DEPENDS and BUILD_DEPENDS. Everything else is garbage. The pointyhat error logs would tend to indicate that this isn't correct. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposal for another category in INDEX: common_deps
On Fri, Jul 20, 2007 at 12:40:02PM -0700, [EMAIL PROTECTED] wrote: > >> the INDEX files -- so many that I think that items common to both > >> build_deps and run_deps should be isolated and put into a new category > >> called 'common_deps': > > > >How will this benefit us? > > > >Doug > > Reduce amount of processed text. If you read the log I posted there are a > large number of what I refer to as 'excess characters'. These are the > duplicate characters in both BUILD_DEPENDS and RUN_DEPENDS. IMHO the change in file format (and resulting POLA problems) outweighs the benefits of the faster scan. I'd rather see us audit the ports and try to eliminate unneeded entries in each. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overly restrictive checks in the make process
On Fri, Jul 20, 2007 at 08:58:55AM -0400, Bill Moran wrote: > Why? Is there a legitimate reason why the fetch process refuses to > download this? The intention of the logic is to warn a user, as soon as possible, that they are spending time on something that will wind up being IGNOREd if it is installed. There is no logic there to try to figure out "later version of port"; it simply looks for "is IGNORE set?" Since some downloads take a long time, this does not seem too unreasonable to me. If we moved the check later, the process of trying to install a port that would be IGNOREd would be: spend time fetching and checksumming it, and only then tell the user that they had wasted their time. I think the best we could do is add something analagous to how DISABLE_VULNERABILITIES factors into it, and allow foot-shooting only if demanded, but turn it off by default. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overly restrictive checks in the make process
On Fri, Jul 20, 2007 at 04:07:49PM -0400, Bill Moran wrote: > Even better would be for make to realize that it's only doing the > fetching, and do it anyway. That still doesn't help with the problem of a user who starts a 10MB download that won't work on his architecture or OS release. The code is all the same. This is the aggravation we are trying to prevent. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What to do when the person who takes responsibility for a PR goes non-responsive?
I assume that you've already emailed the person? If so, sending email to portmgr@ is the right way to go. We'll attempt to find out if the person is busy/on vacation/overloaded/etc. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ports depending on FORBIDDEN ports
I'm actually doing a slight superset by looking at dependent ports of (ignore/broken/forbidden/failed) ports, now that I have updated the graph and can "see" it better. It sounds like people are already working on the misc/compat3x dependents. Most of these ports are antiques. IMHO sysutils/eject should be fixed; there is a PR for it already: 112754. We definitely need to find someone who will keep zope up to date. I have privately emailed both the maintainer and the submitter of the last N PRs. There are a few other Python ports marked NO_PACKAGE, and I have also emailed the maintainers. This affects about 80 packages. Fixing all of these would add over 100 packages to the pointyhat builds. Thanks for taking a look at all of these. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "make index" on 4.10-STABLE
On Mon, Jul 23, 2007 at 11:40:13AM -0400, Tuc at T-B-O-H.NET wrote: > I went back to the EOL branch, got the devel/make, installed it. > Went back to the current state, and still had the issue. I vaguely recall that right as we tagged the tree as EOL, one of the ports changed underneath us and broke INDEX. We _thought_ we slid the tag on the fixed port to fix the INDEX build, but from your experience it sounds like we didn't. The last INDEX build for 4.X in the uploaded package directory is ftp://ftp4.freebsd.org/pub/FreeBSD/ports/i386/packages-4-stable/INDEX. This dates from 02/06/07; the cvsdone file on pointyhat indicates that the last CVS checkout was Fri Feb 2 18:49:49 UTC 2007, so this would be believable. It looks like the tag was laid down sometime between 2007/01/28 21:55:55 and 2007/01/29 04:03:34, based on commits to devel/Makefile. (That's as much research as I want to do :-) ) We no longer have the ports tree that it was built from on pointyhat, so I can't tell you if the cvsdone reflects the tag date or the later date. I don't know if that INDEX file will be of use to you. > I'll probably just end up running into this more as I go down the line. Absolutely. At this point, unless the above INDEX file works for you, you are probably throwing good time after bad. > I guess I need to create a bunch of boot CDs, take my server down for > a while, and see if it'll run later versions of FreeBSD. That's your best choice. > I know on a few other computers I have I can't go past 5.3 without it > breaking. Please check them out with 6.2 or 6-STABLE and if they still don't work and there are not yet PRs filed against 6 for those machines, please do so. 4.X served us well for a long time, but it was taking more and more committer and maintainer time to keep it going; time that we (portmgr) wanted to redirect to fixing problems with 6.2 and releases going forwards, so that it could be a true superset of 4. We did spend a year telling people that we were closing the books on 4. I know this won't make you or anyone else happy, but I do still believe that if we had not shut the door at some point, we would still be supporting 4 years from now, and there's just simply not enough volunteer hours to supporting 4 (!) major source releases on the ports tree, which is where we were. With the upcoming 7.0 release, we're going to be back in that mode again, which is a shame (but at least the differences between 5, 6, and 7 are far less than the difference between 4 and 5, and 5 is rapidly approaching its own EOL.) If we had not dropped 4, we would have been supporting _5_ major source releases. We would not have succeeded. In any case, what's done is done, and we can't go backwards, only forwards, from this point. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: x11-themes/kde-icons-icosx - PLEASE DON'T DELETE
In general the way we want to assign maintainership is in conjunction with a port update/fix. Please submit anything that you come up with via GNATS. Even if in the meantime the port gets deleted, it can easily be brought back from the Attic. Thanks for volunteering to help. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Regarding upgrading nsc ports
On Fri, Jul 27, 2007 at 12:39:51PM +0530, Alagarsamy A wrote: > can you please update it to latest version 0.80 > (http://nsc-gothix.sourceforge.net/) ? ports@ is the "default" maintainer. No update will happen until someone (you?) submits a PR for it. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Keeping Ports and Packages Synchronized
On Thu, Jul 26, 2007 at 04:27:37PM -0700, Kurt Abahar wrote:
> However, I don't know how to get a hold of this "lag
> time." Is it a few days, a few weeks or ... ?
You can get an _idea_ of the degree of the lag via the following URL:
http://pointyhat.freebsd.org/errorlogs/packagestats.html
The "cvs date" column shows you the date of the CVS update for each
individual build environment (which is architecture * OS branch), _if_
the standard build scripts were invoked which automatically create this
file. However, if for some reason the CVS update had to be done manually
in the first place, or an update to certain ports was done after the
initial CVS build, then that file might not be correct. (Reasons for
having to do this might involve trying to update a single failing port
with many dependencies, or the CVS update having caught the tree in a
state where INDEX was not consistent, and so forth.)
Depending on the load on the port build cluster machines, amd64 and i386
builds can take a few days to longer. The sparc64 package builds take
weeks (we have far fewer sparc64 machines, and they are much slower). You
can safely treat the ia64 package builds as a mere sanity-test of the ia64
src tree; since they take over a month, they are useless for actual packages.
The other columns will give you pointers to the latest INDEX that was
created from each checked-out CVS tree; the number of ports marked IGNORE
for some reason ("skipped"); and other things. (See the text at the
bottom of that page for a fuller explanation).
But to answer your original question: the only way that we could keep
packages 100% in sync with the source would be to have two completely
separate versions of the source; one that was "internal" and one that
was released to the public. But which timeframe do you use? That for
amd64/i386, or the longer ones?
Also, note that these runs _overlap_. As one of the (e.g.) amd64 builds
winds down to the last few long-running packages, we start another one for
separate branch.
Between the fact of this, and the fact that the Ports Collection is an
infinitely moving target, there is _no_ time 'T' where the packages for
-stable and -current are up-to-date. The only case this is guaranteed
to happen is when we tag the ports tree for each release and then build
packages based upon it. Even with that, we do each package set and then
have to further manually update ports that have security updates, and
re-package them. We _hope_ to not make errors in that work.
To summarize: the problem is that there are too many moving parts that
all move simultaneously. The only way that we can guarantee that the
packages match your ports tree is at release time, and only then with
a great deal of QA.
(Note that I have skipped, in this discussion, packages that we can not
make available for license reasons, and the packages that depend upon
them; and packages that are currently not being made correctly*, and
the packages that depend on _them_.)
Now, in _general_ the amd64/i386 packages will be "fairly close", for
some value of "fairly close". This becomes untrue when, e.g., a commit
is done to the ports infrastructure, or a port that affects a large
number of packages (gettext, perl5.8, python, autotools, autoconf, and
so on.)
But the general-case problem is very, very, hard.
mcl
* either for temporary reasons, reasons that they don't yet build on that
architecture and/or OS release and/or gcc release, and other things
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: emacs 22 and info files
On Wed, Aug 01, 2007 at 03:17:24PM +0200, Mark Evenson wrote: > Which I would do but the [FreeBSD Bugs database][1] seems to not be > returning any matches to queries Seems to be working fine for me now. However, I've seen a 'no PRs found' page to be displayed sometimes, possibly due to some internal timeout. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Out of order line in /usr/ports/MOVED
On Sat, Aug 04, 2007 at 06:01:48PM -0700, Doug Barton wrote: > The following line was placed first in the file, instead of in > chronological order. Is there a reason that it needs to be first? This is a bug. Fixed. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Out of order line in /usr/ports/MOVED
On Sun, Aug 05, 2007 at 09:29:03AM -0700, Doug Barton wrote: > Thanks! I forgot to include in my original message that this is > important because some tools (like portmaster) and portsmon > rely on being able to parse the file in chronological order. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
new reports added to portsmon
These reports deal with package failures, adding together all packages that are intentionally not made, packages that fail, and all the packages that depend on them. Initially I generated these as graphs via GraphViz. However, the resulting images are so large that they take minutes to display on a browser such as firefox. This is useless. Now I have added a version of the reports in list form. Just see the "List of package failures (direct and indirect) by buildenv" on the charts and graphs page: http://portsmon.freebsd.org/chartsandgraphs/index.html . Each package that was not built is listed in the left column; the center column gives the explanation; and the third column lists the ports, if any, that depend on the non-built package. If you are interested in helping to get the packages in better shape, I think you will find these reports of help. (I am continuing to work on them, so the format may change.) Note: these reports show the state of the packages as of the last full runs. Some errors may have been fixed in the meantime; you will need to check the commit logs. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Popularity contest
On Sun, Sep 02, 2007 at 01:50:36AM +0200, Nils Vogels wrote: > Since a little while, Debian has been using a popularity contest, that > sends anonymous usage details of various packages that Debian users have > installed. See sysutils/bsdstats. It apparently has not yet been extended to ports/packages, although a category is shown for that on the homepage (http://www.bsdstats.org). mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[HEADSUP] bsd.perl.mk import coming soon
The refactoring that gabor has done to recreate bsd.perl.mk will be imported soon, along with the many ports that it simplifies. Due to the size of the patch, I expect there to be collisions that I will have to adjust as I go, so expect the tree to be broken briefly while I work through the checkin. The main feature of the change will be to allow USE_PERL5= 5.8.0+ (and similarly for USE_PERL5_RUN, USE_PERL5_BUILD, PERL_CONFIGURE and PERL_MODBUILD). As a side-effect, the remaining few stragglers that attempt to keep perl5.003 going will be dropped. (Other committers have also been removing that code). mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[headsup] latest changes to bsd.perl.mk, and regressions
This should fix the remaining perl-related problems that people were seeing, each related to ports that conditionally included perl. The only remaining regressions that I can't yet explain are the following: */fpc-* fail to compile due some kind of flag failure. (They work on my 6.2 machine here). lang/dylan does not seem to build reliably. */hs-* are refusing to install. Someone's going to need to help me out with these. Thanks. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
failure mode in build of devel/e4graph
Nothing has changed in the port, but this is showing up on both 5 and 5-exp now. Any ideas? The offending item is the extra space after '/usr/local/lib': mkdir -p /usr/local/lib /tcl8.4/tgraph1.0 cp ../../all/pkgIndex.tcl /usr/local/lib /tcl8.4/tgraph1.0 cp: /usr/local/lib is a directory (not copied). http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.5.2007092509/e4graph-1.0a11_2.log Is anyone else seeing an error like this? mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[HEADSUP] problems with the autoconf upgrade
Despite the fact that this was tested on the cluster, this upgrade has failed. Please hold off upgrading your ports tree until we can figure out what the problem is. 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: [HEADSUP] problems with the autoconf upgrade
On Sat, Oct 06, 2007 at 05:40:05PM +0200, Max Laier wrote: > On Sunday 30 September 2007, Mark Linimon wrote: > > Despite the fact that this was tested on the cluster, this upgrade has > > failed. Please hold off upgrading your ports tree until we can figure > > out what the problem is. Thanks. > > Did I miss the "all good now", or is this still the latest on the subject > matter? If the latter, what can we do to help? It was fixed 24 hours later. The actual problem turned out to be the m4 upgrade, which was quickly backed out. Anyone still having problems with autoconf should contact me directly. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[HEADSUP] portsmon default ports environment switched to i386-7
(For those who are not familiar with the FreeBSD Ports Monitoring System, or portsmon, that I wrote and maintain, you'll find more information at portsmon.freebsd.org.) To get ready for the 7.0 release, I've switched its model of the "default" ports build environment from i386-6 to i386-7. This mainly affects the status metavariables of each port. (It's a current limitation that portsmon only models one build environment.) E.g., its reports of ports that are marked "BROKEN" (i.e. fail to build for some reason) is now based on the evaluation of their state on -7 rather than on -6. This applies to both the interactive pages, and the email that is sent out every 2 weeks to maintainers and the mailing lists. Some of our maintainers will be seeing these messages for the first time. Don't panic; in many cases the newly-marked ports are failing to build because of the import of gcc4.2 into the base system. (All of the ports that are failing on i386 and/or amd64 have already been marked). We still have time before the 7.0 release to fix these problems -- most have already been fixed over the past few months. For some outdated software, it may not be feasible to provide patches; if this is the case, we can specify that the port can only be built with an older version of gcc. However, this should be used as a last resort. But the preferable solution is to provide patches and then send them to the upstream maintainers (if any) so that they can be incorporated there. In addition to the pages that most people are familiar with, I am in the alpha stage of generating reports that show the state of ports across all build environments. Unfortunately, the results are not yet dynamically generated. I had hoped to have that ready before release. In the meantime, the static reports will have to do. - http://portsmon.freebsd.org/chartsandgraphs/package_comparison.html compares the state of the packages for each build environment. The bars in the chart are divided up into: - unrestricted packages built; - restricted packages (built, but not available for download); - build errors; - not tried due to BROKEN, IGNORE, or FORBIDDEN; - not tried due to NO_PACKAGE; - not tried, other (these are due to drift in the ports tree between the time it was checked out, and the time it finished); - not tried, because it was a dependent port of one of the 3 lines above; - missing. These are due to bugs in the algorithm. - Clicking on each bar in the above will take you to a page for a particular build environment with a pie chart for the above values, and a tabular representation. (Bug: the links on those pages do not go anywhere useful). Examples: http://portsmon.freebsd.org/chartsandgraphs/package_status.amd64-7.html http://portsmon.freebsd.org/chartsandgraphs/package_status.i386-7.html - You can also (for the first time) see a tabular list of all ports that fail to package -- for the union of all the reasons above. Examples: http://portsmon.freebsd.org/chartsandgraphs/package_failures_list.amd64-7.html http://portsmon.freebsd.org/chartsandgraphs/package_failures_list.i386-7.html Here you can see, for a given build environment, the packages that were not built; the reasons that they were not built; and all the ports that depend on them. Clicking on each link in the left column will take you to the overview page for that port. Fair warning: these charts are pretty large; you may need to shrink them down to browse them effectively. Further note: some of the ones I have just uploaded show the results of a few very important packages that failed (x11/kdelibs3; devel/imake; and graphics/ImageMagick), so the statistics look bad. However, I believe these ports have already been fixed. Again, these reports are in an alpha state, but they offer a way for people interested in seeing e.g. what the state of the amd64 packages will be for 7.0, and hopefully give them a chance to fix some of them before the release. Finally, you don't need to let me know about the specific bugs in these reports -- I'm well aware of them :-) mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[HEADSUP] last run of GNATS weekly reports was broken
When we upgraded the machine that hosts these reports, we missed some files, and the reports came out null. I am currently working on testing the corrected script. While I'm working on it, I'm going to make a few tweaks. Let me know if you see anything odd in the results. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: broken ports freebsd 7.0 amd64
The best thing to do is to send individual PRs for these ports, so that they may be assigned to the maintainers. The mailing lists are so noisy that things like this tend to just get lost. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: the coming cold ... I mean freeze
On Tue, Oct 30, 2007 at 09:54:54AM +0100, [LoN]Kamikaze wrote: > I hope that when the freeze comes (wasn't that supposed to happen today?) the > maintainer updates from before the freeze will still get committed. No, the idea is that during the freeze period we turn our attention to fixing bugs and get as many packages building as possible. If an update is the only way to do that, fine. Otherwise, there's not much point in having a freeze. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: the coming cold ... I mean freeze
On Tue, Oct 30, 2007 at 11:35:48PM +0100, [LoN]Kamikaze wrote: > I put a lot of effort to get the release done (4 days) before the freeze. So > it's kind of frustrating that it doesn't get in. I sympathize, but if we let one update in, it is very difficult to not let them all in. We (portmgr) will have several hundred approval requests just for bugfixing during the freeze. At some point you simply have to say "today's the day" and draw a line, otherwise, the release process will never get done. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reviving a dead port
On Sun, Nov 04, 2007 at 12:45:34PM +0100, Michaël Grünewald wrote: > First, this is not really a new port, but a revival of a dead one. is > there specific issues with this? No, just label it [new port], but put in the Description that it's coming back from the Attic. > Second, the port version I wrote is anachronic, since some people may > have 1.46 installed (or prior 1.45.5 version, but PORT_REVISION can be > used here so this is not an issue). What's the correct way (or least > annoyance way) to handle this backtime travel? See the description of PORTEPOCH in the Porter's Handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-naming.html#MAKEFILE-NAMING-REVEPOCH mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fix build w/ gcc 4.2 - any priority?
On Sun, Nov 04, 2007 at 03:08:45PM +0100, Pietro Cerutti wrote: > Is there anything like bsdstats that I can use to see that? FreshPorts has http://www.freshports.org/graphs.php?id=7, but it's only the top 20, so not really. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cricket user
On Fri, Nov 09, 2007 at 03:05:47PM -0800, Mark D. Foster wrote: > Cricket is marked > IGNORE= uses a UID registered to another port > > What is the proper fix? Change it to use some UID that isn't yet listed in the Porter's Handbook and send-pr the diff. If you're not using whatever port yourself that reserves that UID, you can just force-install it, but the above is the preferred fix. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (no subject)
On Tue, Nov 20, 2007 at 09:37:47AM -0600, J. Porter Clark wrote: > How do you trace the dependencies? I have found this uncommonly > difficult. make all-depends-list make build-depends-list make package-depends-list make actual-package-depends make run-depends-list make pretty-print-build-depends-list make pretty-print-run-depends-list and ports/ports-mgmt/pkg_tree are pretty good places to start. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: octave-forge on FreeBSD 7.0
On Sunday 18 November 2007, Maho NAKATA wrote:
> > How about doing something more simple like:
> >
> > .if ${OSVERSION} >= 700042
> > USE_GCC=3.4
> > .endif
> >
> > which works great in my situation.
I'd rather see USE_GCC set unconditionally, so that INDEX will
be the same on 6 and 7.
Is there any hope of the software being updated? My concern is
that once we set this, we'll tend to forget about it later.
mcl
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: octave-forge on FreeBSD 7.0
> IMHO, octave-forge should be merged into octave itself, > and relese version of octave and corrsponding octave-forge is old. > I think this is a temporal situation. Once octave will be updated > octave-forge will also be updated, and I believe octave-forge > will be built with gcc42. OK, in that case, approved. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HEADSUP: some new port breakages on 5.x (but not 6.x and 7.x)
Sometime in late July or early August, something changed in the infrastructure that broke installation of these 4 ports -- but only on 5.x. The cause is still under investigation. If anyone has any ideas, please let me know. mcl -- Forwarded Message -- Subject: cvs commit: ports/databases/virtuoso Makefile ports/security/squidclam Makefile ports/www/havp Makefile ports/x11-drivers/xf86-video-openchrome Makefile Date: Saturday 24 November 2007 From: Mark Linimon <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] linimon 2007-11-25 01:24:13 UTC FreeBSD ports repository Modified files: databases/virtuoso Makefile security/squidclam Makefile www/havp Makefile x11-drivers/xf86-video-openchrome Makefile Log: Mark as broken on 5.x: fails to find pthread.h. Something in the infrastructure changed in the late July timeframe that actually caused this problem. The only major thing at that time was the autoconf/libtool change, but I can't see how that could have caused this failure mode. It only happens on 5.x; 6.x and 7.x are fine. Approved by:portmgr (self) Revision ChangesPath 1.9 +7 -2 ports/databases/virtuoso/Makefile 1.5 +5 -0 ports/security/squidclam/Makefile 1.8 +4 -0 ports/www/havp/Makefile 1.3 +1 -1 ports/x11-drivers/xf86-video-openchrome/Makefile --- linimon 2007-11-25 01:24:13 UTC FreeBSD ports repository Modified files: databases/virtuoso Makefile security/squidclam Makefile www/havp Makefile x11-drivers/xf86-video-openchrome Makefile Log: Mark as broken on 5.x: fails to find pthread.h. Something in the infrastructure changed in the late July timeframe that actually caused this problem. The only major thing at that time was the autoconf/libtool change, but I can't see how that could have caused this failure mode. It only happens on 5.x; 6.x and 7.x are fine. Approved by:portmgr (self) Revision ChangesPath 1.9 +7 -2 ports/databases/virtuoso/Makefile 1.5 +5 -0 ports/security/squidclam/Makefile 1.8 +4 -0 ports/www/havp/Makefile 1.3 +1 -1 ports/x11-drivers/xf86-video-openchrome/Makefile ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[HEADSUP] new package status/statistics uploaded to portsmon.freebsd.org
I've been generating these locally but not uploading them. Now, they are up-to-date. If you are interested in what the state of the packages is on the various architectures, these pages will be of interest. Of particular interest to ports committers is the new page http://portsmon.freebsd.org/checkpackages.html. This shows the status of the packages that go on disc1 and disc2 of the release CDs. When you click on the table header for each buildenv, it will take you to a page that shows the complete package status for that buildenv, including whether packages are marked IGNORE or BROKEN, or simply have errors. For each package in the checkpackages page, you'll need to search the most right-hand column of the status page to find out what package is blocking it, if it's a dependency of something else. The overall comparison amongst buildenvs is at the following: http://portsmon.freebsd.org/chartsandgraphs/package_comparison.html. That's a good "start here". Everything else is shown on http://portsmon.freebsd.org/chartsandgraphs/index.html. Note that all this data is as of the last port building run (not whichever one is currently in progress), so certain errors may already have been fixed. The information is all there -- but you may have to do a little bit of detective work with e.g. the individual port pages and the cvsweb links. For instance, amd64-7, i386-7, and sparc64-6 have been unblocked by the most recent commits. However, sparc64-7 is still blocked on x11/gnome2 via the build error in devel/pwlib, which appears to have happened when the threading libraries were switched. (Anyone willing to help track that down?) mcl ___ 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 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. Occam's Razor would suggest that portmgr is simply trying to get the combination of src + ports finalized enough to get a set of release package builds out the door. The Razor, and past experience, would suggest that sweeping changes would delay all that significantly. mcl ___ 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 03:08:43AM -0800, David Southwell wrote: > I must say I am having difficulty understanding the policies applicable > during ports freeze. I had hoped that http://www.freebsd.org/portmgr/qa.html and http://www.freebsd.org/portmgr/implementation.html would have been clear enough on what the policies are -- that was the motivation for writing these documents. > The freeze seems to be of longer duration than originally expected As are most of them. Welcome to the world of software engineering schedules :-) > I would however like to ask, on the basis of what is being learned now, > how could the length freezes be diminished on future occasions? After the 5.3 release, there was a lot of discussion between the ports management and release engineering teams on how to do exactly that. To some extent we're dependent on the state of the source tree; changes that affect the ABI cause us to have to go back and re-do package sets. The release engineers are now much more aware of this impact that they were in the past. However, .0 releases are particularly difficult on this front, since we have to live with any ABI mistakes for several years. Thus, it's worth a delay to avoid having to support a bad or questionable implemenation. Unfortunately, these are often not caught until the prelease starts to get widespread testing outside of the developer community. Another cause is that we're trying to get as many packages buildable and useful for release as we can. This is particularly important for the non-i386 architectures, which do not have as large a user base. Note: this time we waited to start the freeze until nearly the RC1 date -- in the past, we had done it earlier in the beta cycles. There's nothing to be done when RC1 slips, however; we want to have as good a package set entering RC1 as we can get. In the meantime, the number of working packages is probably close to an all-time high numerically (I don't have enough sense of historically to say percentage-wise, although I suspect it's a recent maximum). Folks can help out by trying to install systems just from the packages and letting us know what problems they find. mcl ___ 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 10:37:45AM -0800, David Southwell wrote: > But the chances are that freebsd-7 would be better becasue the extra 2 months > would give more feedback and urgent if not almost immediate needs for 7.1 > might be delayed. We've already _given_ 7.0 an extra 2 months; fortunately, not all of it was coupled into the ports freeze. mcl ___ 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:56:42AM -0600, Stephen Montgomery-Smith wrote: > These are all reasonably good suggestions for how to get around the ports > freeze. But they will come with a price, namely someone has to implement > these changes (which I guess one of you would do) fwiw, one of the pkgsrc committers estimates that it takes around 5 people to handle the work of having a branched tree. > Furthermore the FreeBSD project tends to be conservative and resistant to > big changes. We have such a large install base that we feel we have to be, in some respects. > So what I think you need to do is to really convince others that the port > freeze is not just an inconvenience/frustration (and personally I agree > with you here), but that it is a major shortcoming with the current > system. No one will argue that it's not an inconvenience and a frustration -- and, fwiw, a lot more work for the committers (and portmgr). I'm still not exactly clear on why not having the latest-and-greatest port is such a drawback. Yes, you're losing bugfixes on those in the meantime, but we're catching up on bugfixes on the other ones. Security updates go in in any case. mcl ___ 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 06:51:58AM -0800, David Southwell wrote: > Before I do so let me step outsiide the freebsd environment and ask what our > comments would be if MS$ were to announce that they were about to release an > upgrade to their operating system and until the new upgrade had been released > upgrades to existing applications would be barred. I am sure we would all > agree that that was ridiculous. I would certainly not agree that that's ridiculous; I'll call it an essential part of a QA process to hold changes to a minimum. > What proportion of freebsd users will immediately upgrade to the new > releases?? Maybe 5% or 10% at the most. I think a larger number than that will do so -- for the usual reason that they want the bugfixes that come with that release (especially if those bugs are ones affecting their installation). The answer to most problem reports for bugs fixed in later versions is "upgrade" -- not just FreeBSD, but any software product. Another factor to consider is that during the period between releases, most people will start with FreeBSD by installing the release CD. To the extent that the ports and packages on that CD don't work, we tend to lose new users right there. > How about maintaining the port tree as usual during the pre release period. > By > default all releases in the tree prior to a selected date should incorporate > a release dependency in their makefile that would NOT include the pending > future release. > > As each port is tested against the new release its release depency would be > changed and upgrades could continue to be added to the tree as normal. I think you seriously underestimate: the complexity of the dependency trees, the amount of horsepower it takes to build packages (even given that the build cluster "understands" to only build packages for which their port, or a dependent port, has changed in the meantime); how many person-hours it takes to analyze the results of package runs; and the subtle nature of how "innocent" dependency changes can break things. I'll freely admit to not fully understanding #1 and #4, and I think I understand more about them than all but a few people in the project. (I've spent a fair amount of time researching the package status over time to learn more about them.) I know all of this stuff happens in the background and isn't visible to most of the users, but the effort is large nonetheless. mcl ___ 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 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 ... mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: All those 'Ports System Re-engrg" posts
He lost me around the "these days, the horsepower to rebuild ports is easily available." He clearly has not idea, whatsoever, of what the current work is. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: All those 'Ports System Re-engrg" posts
On Tue, Dec 04, 2007 at 11:06:32PM -0800, Jason C. Wells wrote: > I seem to recall Jordan writing that the ports system was never > intended to last as long as it did. I think he said the same thing > about sysinstall. He was probably correct in both cases. However, we have this "userbase" thing to think about at the moment ... mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ion3 license violation
On Wed, Dec 12, 2007 at 07:22:50AM +, Tuomo Valkonen wrote: > The version of Ion3 in FreeBSD ports at [1,2] is obsolete (3rc-20070927 > is provided, but 3rc-20071109 is more than 28 days old), and must per > the license be upgraded, removed, or prominently marked as obsolete. I have marked it as DEPRECATED. Note: we've had a ports freeze and updates were not accepted during this time. The maintainer's activity or inactivity is thus not germane. I followed the discussion of your license on the pkgsrc mailing list, fwiw, and do not intend to rehash them here. To our users: if you are interested in seeing this software remain in the FreeBSD Ports Collection, please email me off-list. I have concerns about our ability to keep Mr. Valkonen happy with the way we distribute his code. pkgsrc has already made the decision that they are not able to do so, and have thus deleted it. Other BSDs and distributions may have done so as well. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ion3 license violation
On Wed, Dec 12, 2007 at 07:48:03AM +, Tuomo Valkonen wrote: > And this shows to a user trying to install it, how? ===> NOTICE: This port is deprecated; you may wish to reconsider installing it: is more than 28 days old, which the author states violates his license. Do not contact author. It is scheduled to be removed on or after 2008-01-12. This is normally as fast as we pull out the rug from under existing users' feet. If the above isn't satisfactory, I will immediately remove it from the Ports Collection. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ion3 license violation
Folks, don't reply any further to this thread. The packages are in the process of being removed, no further software from this author will be accepted, no more drama will be had. Nothing to see here, move along. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ion3 license violation
On Wed, Dec 12, 2007 at 08:25:17AM +, Tuomo Valkonen wrote: > On 2007-12-12, Mark Linimon <[EMAIL PROTECTED]> wrote: > > ===> NOTICE: > > And this would also stop binary package from being generated > for the releases? No, the release packages were already built. You see, part of the problem of software Quality Assurance is that it takes some period of time to get final packages made and tested -- a time that no one can guarantee will necessarily be less than 28 days. >From the discussion I followed on the pkgsrc mailing list, you obviously either don't understand, or don't care, about this asepct of trying to produce the best working packages for the users of a particular OS. But, I tell you what, as a special favor to you, I'll personally rip ion-3 out of the already-prepared package sets, check to make sure that the port is removed from the Ports Collection, and promulgate a new policy that NO software from you will in the future be accepted into the Ports Collection. Thus, your licenses will be honored, and as an inevitable result, your software will descend even further into complete irrelevance. Will that be acceptable, or is there something else that you would like from me this fine evening? mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ion3 license violation
On Wed, Dec 12, 2007 at 08:47:03AM +, Tuomo Valkonen wrote: > I could make it GPLv3 and nagware at the same time. Yes, and you could put on makeup, shave your armpits, put on a ballerina's dress, and declare yourself Queen of Saturn And All Its Moons for all it matters to FreeBSD now. We can make enough of our own drama here, thanks. Please take your own, and see what a wonderful reception it will get in the Windows world. (Free hint: they already have a windows manager built-in. Get it?) mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ion3 license violation
On Wed, Dec 12, 2007 at 12:08:46PM +0200, Tuomo Valkonen wrote: > "Do what the fuck you want as long as you don't piss me off." I personally consider this to be the null set. No one but you seems to be able to figure out what this is. It certainly doesn't seem to consist of "do whatever you want with this (theoretcially) GPLed software, but don't contact me" -- which, after all, would in and of itself be a reasonable position. (IMHO) Look, dude: we deleted your software -- all of it -- and two hours later you're still trying to find something to throw a fit about. It's gone, over, done, flushed, dead, buried, down the Sewey Hole, out with the used kitty litter, sent to /dev/null, pushing up the daisies, dwelling with Elvis on his UFO, gone Across The Ocean with Bilbo, on Amelia Earhart's last flight, in Judge Crater's suitcase, in Jimmy Hoffa's day-planner, gone to be with St. Francis, and singing in the Choir Invisible. The intersection of "ion-3" and "FreeBSD" is now congruent to the Vacuum Of Deep Space. Except with less free hydrogen atoms. So, please go away now. I am out of similes. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ion3 license violation
On Wed, Dec 12, 2007 at 10:36:23AM +, Tuomo Valkonen wrote: > Big and powerful distros can [piss me off], easily. Ah, that should let FreeBSD off the hook, then. mcl ___ 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 (Re: Ion3 license violation)
On Wed, Dec 12, 2007 at 08:12:17PM -0600, Mark Linimon wrote: > http://mail-index.netbsd.org/tech-pkg/2007/10/28/.html > > Anyone interested in this thread needs to go read that one first. As well as http://www.archlinux.org/pipermail/tur-users/2007-April/004634.html, which contains the history of the author's legal threat against ArchLinux. mcl ___ 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 (Re: Ion3 license violation)
On Wed, Dec 12, 2007 at 07:30:46PM -0500, Mikhail Teterin wrote: > I expect the port-removal to be initiated/done in an orderly fashion. Claims of license violations absolutely trump any "process requirements". portmgr has the explicit task of keeping the Ports Collection in as best a legal state as possible. Further, note that my initial commit tried to do this, and I asked the author if it was acceptable. It was clear from his reply that it was not -- especially considering the following history: http://mail-index.netbsd.org/tech-pkg/2007/10/28/.html Anyone interested in this thread needs to go read that one first. mcl ___ 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 (Re: Ion3 license violation)
It was pulled from Debian, as well: http://packages.qa.debian.org/i/ion3/news/20070310T233909Z.html As far as I'm concerned, the matter is closed. When 4 different* OS groups come to the same conclusion, I think there's not much else to say. mcl * pkgsrc, ArchLinux, Debian, and now FreeBSD ___ 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 (Re: Ion3 license violation)
On Thu, Dec 13, 2007 at 07:43:36AM +, Tuomo Valkonen wrote: > On 2007-12-13, Mark Linimon <[EMAIL PROTECTED]> wrote: > > Further, note that my initial commit tried to do this, and I asked the > > author if it was acceptable. It was clear from his reply that it was > > not -- especially considering the following history: > > It seemed acceptable wrt. the source package; I was querying the > effect on binary packages. It would have prevented binary packages. > Also read again what I have written about the Xinerama module. > Why is it not a separate package? What is it disguised as part > of Ion, when it is not? ion-3 is deleted -- both in source form, and in binary package form -- so the point is moot. Even without the Xinerama code, I don't see how we could have met your 'no modifications' clause and still have ion-3 be able to run on FreeBSD. In fact, I don't see how any packaging system can meet that standard. Perhaps you can tell me where I'm wrong here. My conclusions from your interactions with Debian + Gentoo + ArchLinux + pkgsrc + OpenBSD is that it is not possible for us to meet your objections in a timely fashion for this release. Apparently only Debian felt like they could meet your objections, even in absence of a deadline; the others either deleted it, or, in the case of OpenBSD, stayed with an older version that predates these licensing clauses. I haven't investigated the state of ion-3 with respect to any other major Linux distributions; the above seem to me to be a representative enough sample. Of course, I'm puzzled why the deletion of ion-3 wasn't enough to end this discussion. I myself have no further interest in discussing it. mcl ___ 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 (Re: Ion3 license violation)
On Thu, Dec 13, 2007 at 08:30:06AM +, Tuomo Valkonen wrote: > The copyright holder reserves the right to refine the definition of > significant changes on a per-case basis. In other words, a moving target -- which implies, to me, that to be legally in the clear, that we would first have to vet every possible change or modification, including patches. This would merely add to _your_ email/support burden, which theoretically is what you are trying to minimize by your license terms. This seems circular to me. You may think the quoted text represent reasonable criteria. But in the case of implied threat of legal action, in my opinion, it's not worth anyone's time to try to iterate over every possibility to find out to make sure they -- and others, on their behalf -- aren't somehow liable. The risk is simply too high. There are other window managers that don't have this restriction, and thus no associated legal risk. I suggest people investigate those instead. Disclaimer: I am not a lawyer, but two semester of US business and contract law taught me one thing: if there is any doubt as to whether something will create legal liability, it is absolutely incumbent on oneself to avoid it. mcl ___ 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 (Re: Ion3 license violation)
On Thu, Dec 13, 2007 at 10:17:16AM +, Tuomo Valkonen wrote: > Notice the "a priori": it means you're allowed to do that without legal > threat until further notice to the contrary. Minutiae like this are the reason I pursued engineering, not law. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ion3 license violation
On Thu, Dec 13, 2007 at 02:48:07AM -0800, Jeremy Chadwick wrote: > I believe Mark removed the source tarball from the "master" FreeBSD FTP > server, and very likely removed the binary packages as well. Correct. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ion3 license violation
On Thu, Dec 13, 2007 at 11:42:53AM +0100, Philip Paeps wrote: > Anyway. How does portmgr feel about this? Aye or nay? I do not yet believe that it is possible to meet Tuomo's interpretation of his license without his prior review of every possible patch, and I'm not willing to obligate the FreeBSD project, in perpetuity, to be able to do so. I have no faith whatsoever that the criteria won't change underneath us, based on the conversations with the pkgsrc, OpenBSD, and other package folks (as archived on public lists). Without written assurance from Tuomo that it won't, I cannot in good faith allow this code back in. I highly doubt that that will happen. The only situation I _might_ find acceptable is for us to follow OpenBSD's path and reintegrate the last release of ion-3 that was GPL only, without the extra clauses. Otherwise, I believe we are simply risking too much. Even that, however, I think is extremely risky, given his track record. >From everything I've seen, the goalposts keep moving. I do not trust that they will not continue to do so. Therefore, I don't want to find out, in a court of law, which parts of this license are legally enforceable. It's simply not worth the trouble for one single package out of nearly 18,000. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD: Ion3 removal (Re: Ion3 license violation)]
On Thu, Dec 13, 2007 at 09:23:24AM -0500, Mikhail Teterin wrote: > No, not impossible -- getting stuff out from the Attic is doable. But more > difficult (possibly involving contacting repo-meisters, etc.) Wrong. You do cvs add, cvs com. > Any claims of license violations -- which, according to Mark, lead to the > hasty removal -- should've been addressed by using FORBIDDEN/IGNORE instead. At least in the US, a court of law won't accept "we'll be deleting the infringing software Pretty Soon." Once notified of the infringement, you are obliged to take immediate action. Keeping us legal is an explicit part of the portmgr charter. If you think otherwise, please contact core@ and they can explain it to you. I doubt you'll take my word for it. mcl ___ 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 (Re: Ion3 license violation)
On Thu, Dec 13, 2007 at 02:43:07PM +, Tuomo Valkonen wrote: > And at least where I come from, contracts are legally enforceable, > even if they're only oral ones You clearly don't come from the US, where oral contracts are not germane in business law. What's written down in the license is the only thing that would be germane in court. Again, I'm not a lawyer, but this was my clear understanding from the courses I took. 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
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
> 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. You may want to take a look at some of the work OpenBSD has done recently; I believe they are working towards treating ports as first-class objects. mcl ___ 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 Mon, Dec 17, 2007 at 11:02:45AM +0900, Hiroki Sato wrote: > Do you think splitting it to small packages will be a big problem? That many ports would create a significant impact on the build systems, especially, sparc64, which is not keeping up at all as it is. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Request for Features: Ports Re-engineering
On Mon, Dec 17, 2007 at 12:59:54PM -0300, Alejandro Pulver wrote: > if not already done, AFAIK tinderbox has an option to run parallel > builds, but don't know about pointyhat) using multiple processors. pointyhat is actually the dispatch machine. It does not actually build packages. The current machine total: amd64:3 (2.2GHz) i386: 40 (400MHz - 1.8GHz, depending on machine) sparc64: 7 (440MHz) Several of these systems (in particular the amd64s) have multiple CPUs in them. In any case, each machine is given several packages to work on simultaneously, depending on its capacity, each in its own fully clean jail. Prerequisites are loaded via the previously built packages; if they are not available, they are first built, then cached. The way the current code works is documented in the following article: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/portbuild/index.html Although the documentation is terse, it is believed to be generally correct. In general, we use -incremental for the builds, unless there has been a large change in the src tree, or it's release. -incremental will only build packages for ports whose metadata (as determined by INDEX) has changed since the last run. This holds the build time for each package set down to a few days (amd64/i386) or a couple of weeks (sparc64), instead of around a week, or a couple of months, respectively. Remember that we have builds for 5.x, 6.x, 7.x, and 8.x all running at various times (some things can be overlapped without adding too much delay). The machines are almost never idle. I strongly suggest that before designing a new system, some careful attention be paid to how extensive and optimized the current system already is. I don't think the people following this thread are going to get the right perspective on the scope of this work, otherwise. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Request for Features: Ports Re-engineering
On Mon, Dec 17, 2007 at 11:54:45PM -0300, Alejandro Pulver wrote: > I remember some of my ports failed on ia64 (some time ago), what > happened to it/them? There are 2 ia64 build machines, each of which has been upgraded to 7.0. However, neither is able to build packages at this time, so until someone takes an interest in fixing that, there won't be any ia64 packages. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: who is the portsmgr? Re Linux hier
On Thu, Dec 20, 2007 at 08:36:32PM -0500, Chuck Robey wrote: > Back last time I was last active,Satoshi Asami was the "Portsmeister". I > dunno if that term is used anymore, but I need to find out if one person is in > charge of ports, or if it's a group of folks, and whichever it is, what their > name(s) are? Most of your questions are probably answered on http://www.freebsd.org/portmgr/. With the addition of another 10,000 or so ports, things have gotten more formalized over time :-) mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: long opened PR
On Fri, Dec 21, 2007 at 10:42:50PM +0300, Max Brazhnikov wrote: > I've submitted several pr (ports/117807, ports/118269, ports/118502) to > fix/update ports which are maintained by @freebsd.org people. Of these, the last 2 came in during the time that the ports tree was frozen in preparation for 6.3/7.0 release (it is now only semi-frozen). So I think it's fair to give folks time to catch up. As well, many people are now on vacation. As to the first one, I'll email the maintainer. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
new wiki page: State of Packages on Sparc64
Please see http://wiki.freebsd.org/Sparc64Packages for a writeup on where we are with respect to sparc64 packages, from portmgr's perspective. Quick summary: we're far behind where we are on i386. In particular, we can't build KDE anywhere at the moment, which affects the release package set. We really need more help from our sparc64 users to decide where we should be spending our efforts (e.g., try to fix various desktop issues? or, concentrate on server-only issues?) Recently several people have expressed an interest in loaning machines and fixing bugs, so consider this an effort at coordination. If you've got any questions, please email me directly. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: new wiki page: State of Packages on Sparc64
On Wed, Jan 02, 2008 at 05:10:56PM -0600, Mark Linimon wrote: > Please see http://wiki.freebsd.org/Sparc64Packages for a writeup on where > we are with respect to sparc64 packages, from portmgr's perspective. I have updated the charts and detailed-list pages on portsmon with the latest information from the partial runs on sparc64-6 and sparc64-7. The former is nearly complete, the latter has a few hundred packages to go. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suggested improvements for ports
On Fri, Jan 11, 2008 at 06:40:35PM +0100, Guido Falsi wrote: > I think that too much formalization in the porting rules would harm the > system. That seems to have been the community consensus in the past. Nevertheless, the PH could use some improvement. Most of what I've tried to put in there is "here's what we recommend as the preferred practice". There's not much "you can't do this" -- most of that deals with things that e.g. break INDEX or otherwise wreak havoc. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suggested improvements for ports
On Fri, Jan 11, 2008 at 11:10:45AM -0600, Paul Schmehl wrote: > The porters handbook seems written from the standpoint of a guide more > than a manual. That's something that I was going to work on, um, last year :-) We need both. Right now we have this hybrid which isn't a completely satisfactory solution for either one. This is historical; it kind of grew out of an initial short how-to document, then, as new things were stuffed into the ports infrastructure, there was no better place to document them. The "quick porting" text should turn into a "guide"; the "slow porting" text should become the reference. Of course, I say this, without the cycles to work on it. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suggested improvements for ports
On Fri, Jan 11, 2008 at 09:24:36PM -0800, Doug Barton wrote: > If you're not keen to learn the SGML there are people who can help > you with that, but coming up with good content that covers the needs > of people like you can (somewhat ironically) be done most easily by > people like you. I hope this is a good start. Excellent point. It's hard for me to see what's missing. I am willing to work with anyone on formatting up additional comment into SGML. (It turns out that if you already know HTML, it's not that difficult to cut-and-paste and experiment, but it's a pain to set up at first, too.) mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: packages with security vulnerabilities
On Mon, Jan 21, 2008 at 03:57:31PM -0800, Doug Barton wrote: > If I understood the question correctly, I think the OP is asking about > the frequency of rebuilding packages with security updates. In which > case your answer is still correct, but leads to a new question, which is > would it be possible to trigger an update for a port that has a security > update sooner? The package updates are triggered by changes to the INDEX file. If the port's metadata changes (which is a near 100% guarantee if it's a security fix), we would need to kill off the existing build, build a new INDEX, and then restart the build. And, of course, do this times 4 for FreeBSD-5/6/7/8, times 3 for the number of architectures we try to build. (Given that there are empty cells in that table, so we "only" try to build 10 package sets). Writing a package build cluster that keeps a rolling model of the INDEX metadata as every commit comes in, so it would know what dependencies need to be rebuilt, is left as an exercise for the reader. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: procedure for removing a port from the tree?
It's in there towards the end: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-deprecated.html You can just file a PR adding the DEPRECATED and EXPIRATION_DATE lines. The only reason we do this step is to provide warning for any existing users. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How long dose it take to approve a port?
On Tue, Jan 29, 2008 at 08:30:03PM +0100, GP wrote: > I'm just wondering how log it usually takes from you submits a new port, to > something happens? Everything is done by volunteers, so the answer is, "it depends". As I check there is a backlog of 980 port PRs. You can get an idea of the distribution via http://portsmon.freebsd.org/chartsandgraphs/prsexplanations.html. I'll note that we have several committers who like adding new ports, so they tend to get added within a few weeks. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Not sure why print/lyx15 is marked BROKEN
On Sun, Feb 03, 2008 at 02:31:48PM -0500, Bill Moran wrote: > $ uname -a > FreeBSD monster 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #2: Sun Dec 30 11:59:30 > EST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 > $ pkg_info | grep lyx > lyx-1.5.3 Document processor interfaced with LaTeX (nearly WYSIWYG) > > So, what information is useful to solving this? The pointyhat builds are done in a jail with the appropriate binaries for the buildenv (e.g. 7.0, in this case). However, the kernel that the jail runs on is running -current. I do not know if it makes any difference or not. >From looking at the logs on pointyhat (see below), as of revision 1.116, date: 2007/12/28 20:40:03; author: mi, the package failed to build everywhere on pointyhat. You might try building the port (by itself) on either a fresh system or in a fresh jail, to see if there is some kind of missing dependency that only affects the build in that environment. mcl for i386 (these are also in e.*): $ ls -al a.*.200[78]*/lyx-1.5.3* -rw-r--r-- 1 ports-i386 4201 312510 Jan 1 08:50 a.5.2007123019/lyx-1.5.3.log -rw-r--r-- 1 ports-i386 4201 312510 Jan 6 04:51 a.5.2008010321/lyx-1.5.3.log -rw-r--r-- 1 ports-i386 4201 312526 Jan 10 18:30 a.5.2008010816/lyx-1.5.3.log -rw-r--r-- 1 ports-i386 4201 312526 Jan 13 21:46 a.5.2008011211/lyx-1.5.3.log -rw-r--r-- 2 ports-i386 4201 324014 Jan 28 14:35 a.6.2008012319/lyx-1.5.3.log -rw-r--r-- 2 ports-i386 4201 324014 Jan 28 14:35 a.6.2008020213/lyx-1.5.3.log -rw-r--r-- 1 ports-i386 4201 324353 Jan 9 20:47 a.7-exp.2008010613/lyx-1.5.3.log -rw-r--r-- 1 ports-i386 4201 324369 Jan 27 11:43 a.7-exp.2008012223/lyx-1.5.3.log -rw-r--r-- 1 ports-i386 4201 324347 Jan 6 02:18 a.8.2008010316/lyx-1.5.3.log -rw-r--r-- 1 ports-i386 4201 324347 Jan 8 04:34 a.8.2008010617/lyx-1.5.3.log -rw-r--r-- 1 ports-i386 4201 333790 Jan 12 10:12 a.8.2008011108/lyx-1.5.3.log -rw-r--r-- 1 ports-i386 4201 324362 Jan 16 02:33 a.8.2008011318/lyx-1.5.3.log ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: X11/Xorg library dependencies
On Fri, Feb 08, 2008 at 11:02:57AM -0800, Gregory W. MacPherson wrote: > It would be nice if the owners of these various ports would update their > Makefiles and Configuration scripts to check for the existence of the > other ports and (gasp) actually build the missing dependencies). While > some ports fail with suggestive messages. I'm confused. When looking at status of libXmu on the build cluster, it seems that it is being built correctly on all of our buildenvs. Each package is built using the dependencies as defined in the INDEX file. So I wonder if this is a problem local to your own system? mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New Port - usual time for response/commit
On Sat, Feb 23, 2008 at 10:17:04PM -0800, comperr wrote: > What you package a port properly (with the shell archive and such) > what is the usual response time you get until a comitter sees it and > commits it? There isn't a "usual" response time. It can run from a few days to a number of months. We generally have around 100 pending new-port PRs out of around 1000 ports PRs. > Also - beyond the 'send-pr' what else has to be done on the > maintainers part? Nothing. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: interactive ports - the plague
On Mon, Mar 03, 2008 at 09:12:37AM -0800, pjd wrote: > With me the JDK ports stop and demand I manually download the files, which > is even more irritating Given Sun's licensing requirements, what is your suggestion? mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: why are older ports built on Sparc64?
> Both ports were updated on Jan 03 with patches that will (hopefully) > fix them on sparc64 with with PORTREVISIONs bumped, still portsmon > shows builds failed on Feb 25, and those are old versions of ports. Because sparc64-7 was (is) still, during that time, doing nothing but building the 7.0 release packages, and rebuilding the ones that had been tag-slipped for security updates. They only finally finished yesterday (!) I have restarted the sparc64-6 build I had started and then interrupted when the last security problems showed up. That's got a tree from Feb. 18: http://pointyhat.freebsd.org/errorlogs/packagestats.html mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: interactive ports - the plague
On Wed, Mar 05, 2008 at 04:22:28PM +0100, Nikola Lečić wrote: > (BTW, are/were there ideas of implementing something similar in Ports > Collection?) Yes, I think we are at the point of needing to implement this. I hope we can use what pkgsrc has (the concepts if not the code); it sounds as though you've put in a great deal of work on it. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysutils/aaccli to be deprecated
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-deprecated.html (I'll admit this page is not the easiest to find) mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vsftpd-2.0.6 failed to compile on FreeBSD-4.11-p26
On Tue, Apr 15, 2008 at 09:24:43AM +0800, John/SML wrote: > Then, I think the appropriate way to keep up with port updates is to > upgrade from FreeBSD 4.11 to FreeBSD 7. However, it is possible to use the > "build world" method to upgrade from 4.11 to 7, or I have to use the > binary upgrade method by using the FreeBSD 7 CD media. If you're using the source upgrade, you're probably going to have to do something like: update to 5.2; update to 5.3; update to 6.0; update to 7.0. You're facing an upgrade that takes you through literally years of technology. Although there are postings I've seen on the mailing lists where people have managed it, this is going to be a difficult task. In particular, you will need to pay attention to the various src/UPDATING files over this span of time. If at all possible, please consider doing a reinstall. You will probably save yourself considerable time in the end. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How often do pointyhat do a build?
On Mon, Apr 28, 2008 at 02:42:56PM -0700, Xin LI wrote: > To make it short - how often pointyhat would do a full build? A full (from scratch, with latest src changes) build is not done very often. We guarantee we do it before release time; there are other times, as well, (at least on i386/amd64). > long should I consider a change (API addition) made on -HEAD be "safe" > (does not cause compiling problems) for MFC into -STABLE branches? Please let portmgr know if we need to update the package machines to the latest -CURRENT to look for fallout. An incremental build on amd64 takes 2-3 days, i386 4-5 day, sparc64 a couple of weeks. A full build can take twice that. The following URL will give you an idea of what the current build state is: http://pointyhat.freebsd.org/errorlogs/packagestats.html mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How often do pointyhat do a build?
On Mon, Apr 28, 2008 at 06:41:30PM -0700, Xin LI wrote: > So does it imply that pointyhat's -CURRENT would (slightly) behind the > current development? Yes, it takes some amount of time to upgrade everything. > Is there any way to know which __FreeBSDversion the current build is > running against? Not without logging onto pointyhat and the nodes. (We do update all the nodes for a given architecture at the same time.) Here's the snapshot right now: pointyhat itself (amd64): FreeBSD 8.0-CURRENT #23: Mon Feb 11 21:22:10 UTC 2008 node gohan40 (i386):FreeBSD 8.0-CURRENT #21: Sun Feb 17 11:22:36 UTC 2008 node hammer1 (amd64): FreeBSD 8.0-CURRENT #0: Thu Apr 24 07:03:35 UTC 2008 node netra1 (sparc64): FreeBSD 7.0-CURRENT #2: Wed Aug 8 19:34:13 PDT 2007 mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Removal of OOo 1.0, 1.1, 1.1-devel ports
> I'd like to remove these ports with openoffice.org-1.0 in June... > Any comments? I see no reason not to, and good reasons (cluster build time) to proceed. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade to Perl 5.10.0 ??
On Sat, Jul 12, 2008 at 08:18:58AM +0200, Koen Martens wrote: > Silly suggestion: if your business is depending on it, either fix the port > yourself or pay someone to fix it for you. Seriously, making demands in a > free software project is silly (if not rude). Actually, Vivek does contribute to FreeBSD as a port maintainer, so he is due a a little respect. However, I have to admit that I find the tone of posts such as his very discouraging at this time. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: net/isc-dhcp40-server
See ports/126638. I don't know what the status is. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: i386-7-bindist.tar is inaccessible on pointyhat
The *bindist.tar files are no longer accessible under those names since the latest upgrade of pointyhat. I will look into it. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pointyhat sparc64
On Mon, Jun 23, 2008 at 01:44:49AM +0100, Daniel Austin MBCS wrote: > Is there anything I can do to assist getting more ports/packages tested > (or the pointyhat cluster running faster) ? I'm not sure I ever answered this email (I am going through the backlog today). I hope you did not get discouraged by the lack of response. We are always on the lookout for some more UltraSparc-II machines to add to the build cluster. The fastest things we have are e4500s right now. (There are 3 of those, 5 Netra 1s, and some other misc. stuff). > I had a quick look at your crash logs for the netras... It seems they > have some issues with the ATA controller (atapci0 interrupt storm) - you > only appear to use it for the cdrom drive - perhaps simply disabling via > the boot loader would prevent the kernel panic (and get the machines > into the build cluster)? No, the machines are set up to pxeboot. acd0: CDRW at ata2-master UDMA33 IOMMU fault virtual address 0xc3008000 panic: pcib: uncorrectable DMA error AFAR 0x1fc5c020 AFSR 0x27ff8000 cpuid = 0 KDB: enter: panic [thread pid 11 tid 13 ] Stopped at kdb_enter+0x80: ta %xcc, 1 db However, you are right to point out ata. The T1 200s use a different chipset than the T1 105s. (There are also other differences between them, so it may not necessarily be the cause.) However, you are right that this is a fairly low-cost thing to look at. I'll try it and let you know. (I've been short-cycled on time to look at this for a while, as you might be able to tell from the fact it took me this long to get around to looking at your email). Again, don't get discouraged, there is progress on the sparc64 front, albeit slow. I am running the 7.1R package builds right now. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: STILL OPEN: Fwd: ports/127015: [patch] Impossible to fetch devel/valgrind from the jail
On Thu, Sep 18, 2008 at 03:38:28AM +0400, Alexander Churanov wrote: > In the beginning of September, I've filed an issue about > devel/valgrind and also sent an e-mail to port maintainer. The issue > is still unresolved. For future reference, the address to contact with issues with maintainers is [EMAIL PROTECTED] I've already forwarded your email to [EMAIL PROTECTED] mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Request Tracker 3.8.1
On Fri, Oct 03, 2008 at 05:27:43PM -0400, Steven Kreuzer wrote: > Before I submit a PR and get it added into svn The ports tree is still on CVS; there are no immediate plans to move to SVN. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
reminder: please put category/portname in ports PRs
We have an auto-assigner that notifies maintainers of ports PRs. It looks for literal 'category/portname' in the Synopsis field to do its work. Please help us out by including this; otherwise, it has to be edited by hand. 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: ports missing their packages.
On Wed, Oct 29, 2008 at 04:42:18AM -0500, Scot Hetzel wrote: > So you are advocating that port maintainers have to create packages > for all the supported FreeBSD architecture's (amd64, arm, i386, ia64, > mips, pc98, powerpc, sparc64, sun4v). That would be 9 packages > needing to be created at the time the port maintainer submits the > upgrade PR. Nope, not 9 :-) You are forgetting FreeBSD 6, 7, and -current have builds enabled. OTOH, portmgr is only supporting amd64, i386, and sparc64 right now, and is not doing sparc64-8 due to lack of machines, so really the matrix is "only" 8. The ia64 package builds were stopped due to problems (and the fact that we only have 2 machines). There are no package building machines for the others yet -- and some of them ae really only going to be used for embedded systems, so only a very minimal subset of ports is going to be useful. So far, we've talked about addding machines for these, but there are no fixed plans so far. > It could be as simple as forgetting to add the ports subdirectory to > the category Makefile (i.e www/Makefile). Actually this is an uncommon problem; every time portmgr builds a package set, error messages are spit out if things are missing, and we are quick to email the maintainers :-) mcl ___ 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: > An alternate solution to this problem is to allow users to upload missing > packages one word for you: "security". What you suggest is never, ever, going to be implemented, due to the total lack of security. mcl ___ 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? A little research shows: ftp://ftp4.freebsd.org/pub/FreeBSD/ports/i386/packages-7-stable/All/php5-gd-5.2.6_2.tbz So, there is a current package for php5-gd. http://www.freebsd.org/cgi/cvsweb.cgi/ports/print/pdflib/Makefile?rev=1.54 So, there will never be a package for pdflib, because we are not allowed to distibute it. Now, apparently audio/jack is not being built at the moment, but without access to my home system I can't probe any further. See http://www.freebsd.org/cgi/cvsweb.cgi/ports/audio/jack/Makefile?rev=1.44 and http://portsmon.freebsd.org/portoverview.py?category=audio&portname=jack. mcl ___ 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 11:00:50PM +1100, andrew clarke wrote: > Presumably the 6.x series wlll be retired before 8.x is released... :) No, there will be an overlap. See http://www.freebsd.org/security/index.html#supported-branches. 8.0 had *better* be out before 2010 :-) > That brings up a question - what is the usual procedure for port > maintainers so they can test their ports on both 6.x & 7.x? I think most people these days run 7.x and create a ports tinderbox (ports-mgmt/tinderbox) to check on 6.x. A few people have tinderboxes available. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
