Re: devel/icu4 update -- chase LIB_DEPENDS
On Fri, Jul 9, 2010 at 5:27 PM, Matthew Seaman
wrote:
> However naively incrementing the shlib version in the
> databases/postgresql84-server Makefile doesn't work:
>
> ===> Configuring for postgresql-server-8.4.4_2
> checking build system type... amd64-portbld-freebsd8.1
> checking host system type... amd64-portbld-freebsd8.1
> checking which template to use... freebsd
> checking whether to build with 64-bit integer date/time support... yes
> checking whether NLS is wanted... yes
> [...]
> checking for CRYPTO_new_ex_data in -lcrypto... yes
> checking for SSL_library_init in -lssl... yes
> checking for ucol_open_43 in -licui18n... no
> checking for ucol_open_3_8 in -licui18n... no
> checking for ucol_open_3_6 in -licui18n... no
> checking for ucol_open_3_4 in -licui18n... no
> configure: error: library 'icui18n' is required for ICU
> ===> Script "configure" failed unexpectedly.
> Please report the problem to gir...@freebsd.org [maintainer] and attach the
> "/usr/ports/databases/postgresql84-server/work/postgresql-8.4.4/config.log"
> including the output of the failure of your make command. Also, it might be
> a good idea to provide an overview of all packages installed on your system
> (e.g. an `ls /var/db/pkg`).
> *** Error code 1
>
Looks like it needs a change to the ${WRKSRC}/configure script to
detect ucol_open_44 and ucnv_fromUChars_44:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/databases/postgresql84-server/files/extra-patch-icu4
The simplest way to fix this would be to change ucol_open_43 and
ucnv_fromUChars_43 in the extra-patch-icu4 to ucol_open_44 and
ucnv_fromUChars_44.
Scot
___
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: Solutions for the PR load problem
On Fri, 9 Jul 2010, Shaun Amott wrote: Indeed, part of the problem is burn-out. We recruit committers, and then their activity tapers off (I'm guilty of this myself). Part of this, I believe, is down to the effort involved in maintaining a useful (up-to-date) testing environment -- hence my advocacy of a centralised tinderbox resource. The machines I used to use are out-of-date and probably inadequate now. Isn't that the type of project the Foundation is set up to fund? ___ 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"
devel/icu4 update -- chase LIB_DEPENDS
devel/icu4 was recently updated and now installs shlibs with ABI version
44. Unfortunately this hasn't been propagated to those ports with a
LIB_DEPENDS on devel/icu4 (all three of them):
worm:/usr/ports:% grep -r 'icu.*\.43:' .
./databases/postgresql90-server/Makefile:LIB_DEPENDS+=
icudata.43:${PORTSDIR}/devel/icu4
./databases/postgresql84-server/Makefile:LIB_DEPENDS+=
icudata.43:${PORTSDIR}/devel/icu4
./www/webkit-gtk2/Makefile:LIB_DEPENDS+=icutu.43:${PORTSDIR}/devel/icu4
pkg_info -L icu-4.4 | grep '\.so'
/usr/local/lib/libicudata.so
/usr/local/lib/libicudata.so.44
/usr/local/lib/libicudata.so.44.0
/usr/local/lib/libicui18n.so
/usr/local/lib/libicui18n.so.44
/usr/local/lib/libicui18n.so.44.0
/usr/local/lib/libicuio.so
/usr/local/lib/libicuio.so.44
/usr/local/lib/libicuio.so.44.0
/usr/local/lib/libicule.so
/usr/local/lib/libicule.so.44
/usr/local/lib/libicule.so.44.0
/usr/local/lib/libiculx.so
/usr/local/lib/libiculx.so.44
/usr/local/lib/libiculx.so.44.0
/usr/local/lib/libicutu.so
/usr/local/lib/libicutu.so.44
/usr/local/lib/libicutu.so.44.0
/usr/local/lib/libicuuc.so
/usr/local/lib/libicuuc.so.44
/usr/local/lib/libicuuc.so.44.0
However naively incrementing the shlib version in the
databases/postgresql84-server Makefile doesn't work:
===> Configuring for postgresql-server-8.4.4_2
checking build system type... amd64-portbld-freebsd8.1
checking host system type... amd64-portbld-freebsd8.1
checking which template to use... freebsd
checking whether to build with 64-bit integer date/time support... yes
checking whether NLS is wanted... yes
[...]
checking for CRYPTO_new_ex_data in -lcrypto... yes
checking for SSL_library_init in -lssl... yes
checking for ucol_open_43 in -licui18n... no
checking for ucol_open_3_8 in -licui18n... no
checking for ucol_open_3_6 in -licui18n... no
checking for ucol_open_3_4 in -licui18n... no
configure: error: library 'icui18n' is required for ICU
===> Script "configure" failed unexpectedly.
Please report the problem to gir...@freebsd.org [maintainer] and attach the
"/usr/ports/databases/postgresql84-server/work/postgresql-8.4.4/config.log"
including the output of the failure of your make command. Also, it might be
a good idea to provide an overview of all packages installed on your system
(e.g. an `ls /var/db/pkg`).
*** Error code 1
No idea about www/webkit-gtk2 I'm afraid.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
Re: Solutions for the PR load problem
On Fri, Jul 09, 2010 at 10:51:01PM +0200, Dominic Fandrey wrote: > > Ok - but how do we define "experienced"? Someone who has submitted 100 > > PORTVERSION++ PRs? I'm not convinced we have enough contributors who are > > experienced enough to be given commit rights, but not contributing > > enough to be offered full access. > > Well, I don't see a mass recruiting plan in action and the typical > response time for a ports PR has dropped from a couple of hours to > something around a month following a singular event everyone > here probably already knows about. > > Though there are a lot of committers, there aren't many active > committers. The need seems obvious to me and I figured it would > be obvious to create some middle ground where the demands from > both sides are less. Indeed, part of the problem is burn-out. We recruit committers, and then their activity tapers off (I'm guilty of this myself). Part of this, I believe, is down to the effort involved in maintaining a useful (up-to-date) testing environment -- hence my advocacy of a centralised tinderbox resource. The machines I used to use are out-of-date and probably inadequate now. I don't disagree in principle with the idea of having a middle ground, just not sure (how) it would work in practice. > > Cases where other ports need touching (e.g., library bumps), or an > > update depends on another port/PR elsewhere could prove to be > > problematic. > > Those are the kind of maintainers that have the commit bit anyway. > People who do the major stuff like Xorg, KDE, gnome, autobreak ... > I think those are also the people who carry the main burden of > Maintainer PRs. They really shouldn't have to, they've got more > than enough work. > > >>> One thing that is sorely missed -- by me, at least -- is the ports > >>> tinderbox mini-cluster we had previously (graciously provided by simon > >>> and erwin). The major bottleneck in the review/commit process is the > >>> testing part (again, I speak for myself). A set of tinderbox machines > >>> representing the tier-1 architectures, to which we could grant > >>> contributors access, would reduce the burden on committers (if a > >>> patch/PR arrives with an accompanying log file). > >> > >> What needs to be done? (I.e. money, work hours) > > > > Machine(s), rack-space, someone to maintain said machines to a decent > > standard. Possibly money could solve these issues. :-) > > > > I'm not sure how many non-committers were aware of / given access to tb3 > > and tb4 when they were around, but if tinderbox were used as a matter of > > course, it would, I believe go some way to speeding things up. > > > > So if I set up a private tinderbox and provide amd64 and i386 > 6-/7-/8-stable logs with every PR I submit it would hasten the > processing of my PRs? > > If that is so, I'll get me a small quad-core with ~16GB RAM > and a huge hard disk just for this purpose (my largest hard disk > is the one in my notebook, not sufficient for all the distfiles > and packages). Sure, I would be more likely to look at / commit your patches in a timely fashion if you've done part of the work for me. I'm pretty sure it helped back when I was submitting lots of ports PRs. -- Shaun Amott // PGP: 0x6B387A9A "A foolish consistency is the hobgoblin of little minds." - Ralph Waldo Emerson ___ 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: Solutions for the PR load problem
On 09/07/2010 22:00, Shaun Amott wrote: > On Fri, Jul 09, 2010 at 07:37:11PM +0200, Dominic Fandrey wrote: >> >> On 09/07/2010 19:25, Shaun Amott wrote: >>> On Fri, Jul 09, 2010 at 06:15:58PM +0200, Dominic Fandrey wrote: To solve this problem with the current organization, my guess is that between 15 and 30 new active committers are required. Because I don't think this is easily achieved I want to suggest a different approach. And I expect many others also have their own ideas how this can be solved. Proposal: My idea is that experienced Maintainers get commit permission for their own ports. I don't even think such a thing needs to be enforced technically, after all who'd want to risk his experienced maintainer bit, however this is possible (and people would probably sleep better). > > (apologies for my dodgy quoting...) > >>> >>> The whole VCS debate has been had over and over; I think that for the >>> time being it is more constructive to look at changes we can make to our >>> existing processes. Anything that requires switching from CVS isn't >>> going to happen any time soon. >> >> You can also do this with CVS. > > Ok - but how do we define "experienced"? Someone who has submitted 100 > PORTVERSION++ PRs? I'm not convinced we have enough contributors who are > experienced enough to be given commit rights, but not contributing > enough to be offered full access. Well, I don't see a mass recruiting plan in action and the typical response time for a ports PR has dropped from a couple of hours to something around a month following a singular event everyone here probably already knows about. Though there are a lot of committers, there aren't many active committers. The need seems obvious to me and I figured it would be obvious to create some middle ground where the demands from both sides are less. > Cases where other ports need touching (e.g., library bumps), or an > update depends on another port/PR elsewhere could prove to be > problematic. Those are the kind of maintainers that have the commit bit anyway. People who do the major stuff like Xorg, KDE, gnome, autobreak ... I think those are also the people who carry the main burden of Maintainer PRs. They really shouldn't have to, they've got more than enough work. >>> One thing that is sorely missed -- by me, at least -- is the ports >>> tinderbox mini-cluster we had previously (graciously provided by simon >>> and erwin). The major bottleneck in the review/commit process is the >>> testing part (again, I speak for myself). A set of tinderbox machines >>> representing the tier-1 architectures, to which we could grant >>> contributors access, would reduce the burden on committers (if a >>> patch/PR arrives with an accompanying log file). >> >> What needs to be done? (I.e. money, work hours) > > Machine(s), rack-space, someone to maintain said machines to a decent > standard. Possibly money could solve these issues. :-) > > I'm not sure how many non-committers were aware of / given access to tb3 > and tb4 when they were around, but if tinderbox were used as a matter of > course, it would, I believe go some way to speeding things up. > So if I set up a private tinderbox and provide amd64 and i386 6-/7-/8-stable logs with every PR I submit it would hasten the processing of my PRs? If that is so, I'll get me a small quad-core with ~16GB RAM and a huge hard disk just for this purpose (my largest hard disk is the one in my notebook, not sufficient for all the distfiles and packages). Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: [kde-freebsd] Soprano Update eeded to 2.4.4 ? Current version not finding libiodbc
> I went to http://soprano.sourceforge.net and founf the following: > > Soprano 2.4.4 released > Wed, 06/30/2010 - 20:20 - trueg > Soprano 2.4.4 is a bugfix release - probably the last one before the release > of Soprano 2.5. It features the following changes: > > Fix to FindIODBC.cmake which ensures that the correct locations are searched > first. This allows the usage of a locally installed libiodbc. > > Any chance of 2.4.4 being made available to see if this fixed the problem? > I've sent in a PR to update to Soprano 2.4.4. I've attached the diff as well. Sincerely, Rusty Nejdl soprano-2.4.4.diff Description: Binary data ___ 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: Solutions for the PR load problem
On Fri, Jul 09, 2010 at 07:37:11PM +0200, Dominic Fandrey wrote: > > On 09/07/2010 19:25, Shaun Amott wrote: > > On Fri, Jul 09, 2010 at 06:15:58PM +0200, Dominic Fandrey wrote: > >> > >> To solve this problem with the current organization, my guess is > >> that between 15 and 30 new active committers are required. > >> Because I don't think this is easily achieved I want to suggest > >> a different approach. And I expect many others also have their > >> own ideas how this can be solved. > >> > >> Proposal: > >> My idea is that experienced Maintainers get commit permission > >> for their own ports. I don't even think such a thing needs to > >> be enforced technically, after all who'd want to risk his > >> experienced maintainer bit, however this is possible (and people > >> would probably sleep better). > >> (apologies for my dodgy quoting...) > > > > The whole VCS debate has been had over and over; I think that for the > > time being it is more constructive to look at changes we can make to our > > existing processes. Anything that requires switching from CVS isn't > > going to happen any time soon. > > You can also do this with CVS. Ok - but how do we define "experienced"? Someone who has submitted 100 PORTVERSION++ PRs? I'm not convinced we have enough contributors who are experienced enough to be given commit rights, but not contributing enough to be offered full access. Cases where other ports need touching (e.g., library bumps), or an update depends on another port/PR elsewhere could prove to be problematic. > > One thing that is sorely missed -- by me, at least -- is the ports > > tinderbox mini-cluster we had previously (graciously provided by simon > > and erwin). The major bottleneck in the review/commit process is the > > testing part (again, I speak for myself). A set of tinderbox machines > > representing the tier-1 architectures, to which we could grant > > contributors access, would reduce the burden on committers (if a > > patch/PR arrives with an accompanying log file). > > What needs to be done? (I.e. money, work hours) Machine(s), rack-space, someone to maintain said machines to a decent standard. Possibly money could solve these issues. :-) I'm not sure how many non-committers were aware of / given access to tb3 and tb4 when they were around, but if tinderbox were used as a matter of course, it would, I believe go some way to speeding things up. -- Shaun Amott // PGP: 0x6B387A9A "A foolish consistency is the hobgoblin of little minds." - Ralph Waldo Emerson ___ 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"
can somebody attend this PR???
hello .. i can't build kde4 on my tinderbox because 'graphics/djvulibre-nox11' port .. here is my PR .. hope some FBSDD can solve this .. thanks http://www.freebsd.org/cgi/query-pr.cgi?pr=147650 ___ 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"
can somebody attend this PR???
hello .. i can't build kde4 on my tinderbox because 'graphics/djvulibre-nox11' port .. here is my PR .. hope some FBSDD can solve this .. thanks http://www.freebsd.org/cgi/query-pr.cgi?pr=147650 ___ 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: Review request for new port: sysutils/etcupdate
On 07/09/10 05:27, John Baldwin wrote: > (I used etcmerge as a template.) BTW, I forgot to take this opportunity to insert my traditional rant about "this is why I'm so pedantic when it comes to removing bad code from existing ports." :) They get used as examples, and in this case John made a perfectly reasonable choice, and should have been able to rely on existing code to give him a clean path to developing his new port. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ 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: Review request for new port: sysutils/etcupdate
On 07/09/10 05:27, John Baldwin wrote: > On Thursday, July 08, 2010 6:12:39 pm Doug Barton wrote: >> On Thu, 8 Jul 2010, John Baldwin wrote: >> >>> This is a port for yet-another-/etc-merging tool that I wrote recently. > It >>> passes portlint -N with one bogus warning because /etc is in the comment. >> >> I didn't try installing/deinstalling but you seem to have the right >> stuff in the Makefile for that. Overall it looks good, just a couple >> comments: >> 1. I don't think textproc is right for CATEGORIES, although sysutils is >> of course. >> 2. I don't think the do-fetch target is necessary, but if it is needed >> when you test it that's fine. >> 3. You have a pkg-descr~ file in the shar that should be deleted before >> you commit it. >> >> Assuming it passes all the tests in the porter's handbook for install, >> deinstall, package, etc. I'd say go ahead. :) > > Ok. Should I fix 1) and 2) for the sysutils/etcmerge port as well? (I used > etcmerge as a template.) I think removing textproc is a no-brainer, unless someone has a different opinion. :) I don't have a do-fetch target in portmaster's port (which also has the src in the tree), and given the fact that DISTFILES is explicitly set empty I don't see why one would be necessary at all. So, short answer, yes, if you don't mind. Otherwise I'll be glad to do it, just let me know. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ 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: Solutions for the PR load problem
On 09/07/2010 19:25, Shaun Amott wrote: > On Fri, Jul 09, 2010 at 06:15:58PM +0200, Dominic Fandrey wrote: >> >> To solve this problem with the current organization, my guess is >> that between 15 and 30 new active committers are required. >> Because I don't think this is easily achieved I want to suggest >> a different approach. And I expect many others also have their >> own ideas how this can be solved. >> >> Proposal: >> My idea is that experienced Maintainers get commit permission >> for their own ports. I don't even think such a thing needs to >> be enforced technically, after all who'd want to risk his >> experienced maintainer bit, however this is possible (and people >> would probably sleep better). >> > > The whole VCS debate has been had over and over; I think that for the > time being it is more constructive to look at changes we can make to our > existing processes. Anything that requires switching from CVS isn't > going to happen any time soon. You can also do this with CVS. > One thing that is sorely missed -- by me, at least -- is the ports > tinderbox mini-cluster we had previously (graciously provided by simon > and erwin). The major bottleneck in the review/commit process is the > testing part (again, I speak for myself). A set of tinderbox machines > representing the tier-1 architectures, to which we could grant > contributors access, would reduce the burden on committers (if a > patch/PR arrives with an accompanying log file). What needs to be done? (I.e. money, work hours) -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: Solutions for the PR load problem
On Fri, Jul 09, 2010 at 06:15:58PM +0200, Dominic Fandrey wrote: > > To solve this problem with the current organization, my guess is > that between 15 and 30 new active committers are required. > Because I don't think this is easily achieved I want to suggest > a different approach. And I expect many others also have their > own ideas how this can be solved. > > Proposal: > My idea is that experienced Maintainers get commit permission > for their own ports. I don't even think such a thing needs to > be enforced technically, after all who'd want to risk his > experienced maintainer bit, however this is possible (and people > would probably sleep better). > The whole VCS debate has been had over and over; I think that for the time being it is more constructive to look at changes we can make to our existing processes. Anything that requires switching from CVS isn't going to happen any time soon. One thing that is sorely missed -- by me, at least -- is the ports tinderbox mini-cluster we had previously (graciously provided by simon and erwin). The major bottleneck in the review/commit process is the testing part (again, I speak for myself). A set of tinderbox machines representing the tier-1 architectures, to which we could grant contributors access, would reduce the burden on committers (if a patch/PR arrives with an accompanying log file). Shaun -- Shaun Amott // PGP: 0x6B387A9A "A foolish consistency is the hobgoblin of little minds." - Ralph Waldo Emerson ___ 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: Solutions for the PR load problem
On 09/07/2010 18:26, Chris Rees wrote: > I think the people you describe as 'experienced' maintainers tend to be made > committers anyway, or that's as far as I know. What gives you that impression? ~180 committers that have been active within the last 12 months (as in at least one commit), are currently pitted against 915 open PRs. ~80 committers perform more than 1 commit per week. Of 440 committers the top 20 do more than 60% of the work. The ports tree currently has more than 1700 maintainers. A small number considering that they maintain almost 22000 ports, but still there ought to be some potential to lift some of that burden from the committers. Sources: http://people.freebsd.org/~peter/ports.window.txt /usr/ports FreeBSD bugtracking system Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: Solutions for the PR load problem
On 09/07/2010 18:50, Gary Jennejohn wrote: > On Fri, 09 Jul 2010 18:15:58 +0200 > Dominic Fandrey wrote: > >> Currently the PR load is obviously too high for the committer team >> to deal with. From a maintainer perspective this is rather painful, >> I have currently stopped updating all my ports, because I want >> pending updates committed first and also want to avoid running into >> PR dependencies (ioquake3, openarena and iourbanterror are >> examples in my case). >> > > Are you aware that the ports tree was in freeze/slush for the 8.1 > release? This was just lifted. > > Not much happens when that's the case. I'm not sweeping talking about sweeping commits and the problem has become apparent months ago. And while the number of ports is steadily increasing, the number of commits appears to be declining slightly. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: Solutions for the PR load problem
On Fri, 09 Jul 2010 18:15:58 +0200 Dominic Fandrey wrote: > Currently the PR load is obviously too high for the committer team > to deal with. From a maintainer perspective this is rather painful, > I have currently stopped updating all my ports, because I want > pending updates committed first and also want to avoid running into > PR dependencies (ioquake3, openarena and iourbanterror are > examples in my case). > Are you aware that the ports tree was in freeze/slush for the 8.1 release? This was just lifted. Not much happens when that's the case. -- Gary Jennejohn ___ 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: Solutions for the PR load problem
I think the people you describe as 'experienced' maintainers tend to be made committers anyway, or that's as far as I know. There's little to be gained by putting another rank of responsibility in, especially when a commit to any port can cause huge wreckage; INDEX building, circular dependencies etc. This is why only committers have commit access, as I see it. Sorry for top-posting, Android won't let me quote. There's a bug report on it! On 9 Jul 2010 17:16, "Dominic Fandrey" wrote: Currently the PR load is obviously too high for the committer team to deal with. From a maintainer perspective this is rather painful, I have currently stopped updating all my ports, because I want pending updates committed first and also want to avoid running into PR dependencies (ioquake3, openarena and iourbanterror are examples in my case). Also it adds the burden of adjusting your patches every time the PORTREVISION is bumped, because of a library update, thus producing additional workload without benefit to anyone. To solve this problem with the current organization, my guess is that between 15 and 30 new active committers are required. Because I don't think this is easily achieved I want to suggest a different approach. And I expect many others also have their own ideas how this can be solved. Proposal: My idea is that experienced Maintainers get commit permission for their own ports. I don't even think such a thing needs to be enforced technically, after all who'd want to risk his experienced maintainer bit, however this is possible (and people would probably sleep better). Technical Approach: One, though not the only, technical approach is to switch to SVN and use path based access control. A pretty primitive shell script, probably less than 10 lines could generate the SVN path configuration, from just a list of users. It need not even be run on the server and wouldn't have to be run often. There also exist solutions that add similar features to CVS, but I do prefer SVN. Pros: - Less Maintainer-Update PRs - Maintainers can deal with third party patches directly instead of just providing feedback, so the actual ports committers would only have to close the PRs - Path based access control can be turned off during ports freezes Cons: - Higher server load - Additional user management - Testing guidlines in the Porters' Handbook need to be extended - Experienced Maintainers have to be defined Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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" ___ 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: Solutions for the PR load problem
I think the people you describe as 'experienced' maintainers tend to be made committers anyway, or that's as far as I know. There's little to be gained by putting another rank of responsibility in, especially when a commit to any port can cause huge wreckage; INDEX building, circular dependencies etc. This is why only committers have commit access, as I see it. Sorry for top-posting, Android won't let me quote. There's a bug report on it! On 9 Jul 2010 17:16, "Dominic Fandrey" wrote: Currently the PR load is obviously too high for the committer team to deal with. From a maintainer perspective this is rather painful, I have currently stopped updating all my ports, because I want pending updates committed first and also want to avoid running into PR dependencies (ioquake3, openarena and iourbanterror are examples in my case). Also it adds the burden of adjusting your patches every time the PORTREVISION is bumped, because of a library update, thus producing additional workload without benefit to anyone. To solve this problem with the current organization, my guess is that between 15 and 30 new active committers are required. Because I don't think this is easily achieved I want to suggest a different approach. And I expect many others also have their own ideas how this can be solved. Proposal: My idea is that experienced Maintainers get commit permission for their own ports. I don't even think such a thing needs to be enforced technically, after all who'd want to risk his experienced maintainer bit, however this is possible (and people would probably sleep better). Technical Approach: One, though not the only, technical approach is to switch to SVN and use path based access control. A pretty primitive shell script, probably less than 10 lines could generate the SVN path configuration, from just a list of users. It need not even be run on the server and wouldn't have to be run often. There also exist solutions that add similar features to CVS, but I do prefer SVN. Pros: - Less Maintainer-Update PRs - Maintainers can deal with third party patches directly instead of just providing feedback, so the actual ports committers would only have to close the PRs - Path based access control can be turned off during ports freezes Cons: - Higher server load - Additional user management - Testing guidlines in the Porters' Handbook need to be extended - Experienced Maintainers have to be defined Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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" ___ 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"
Solutions for the PR load problem
Currently the PR load is obviously too high for the committer team to deal with. From a maintainer perspective this is rather painful, I have currently stopped updating all my ports, because I want pending updates committed first and also want to avoid running into PR dependencies (ioquake3, openarena and iourbanterror are examples in my case). Also it adds the burden of adjusting your patches every time the PORTREVISION is bumped, because of a library update, thus producing additional workload without benefit to anyone. To solve this problem with the current organization, my guess is that between 15 and 30 new active committers are required. Because I don't think this is easily achieved I want to suggest a different approach. And I expect many others also have their own ideas how this can be solved. Proposal: My idea is that experienced Maintainers get commit permission for their own ports. I don't even think such a thing needs to be enforced technically, after all who'd want to risk his experienced maintainer bit, however this is possible (and people would probably sleep better). Technical Approach: One, though not the only, technical approach is to switch to SVN and use path based access control. A pretty primitive shell script, probably less than 10 lines could generate the SVN path configuration, from just a list of users. It need not even be run on the server and wouldn't have to be run often. There also exist solutions that add similar features to CVS, but I do prefer SVN. Pros: - Less Maintainer-Update PRs - Maintainers can deal with third party patches directly instead of just providing feedback, so the actual ports committers would only have to close the PRs - Path based access control can be turned off during ports freezes Cons: - Higher server load - Additional user management - Testing guidlines in the Porters' Handbook need to be extended - Experienced Maintainers have to be defined Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: kdepim4-runtime fails to build
--On Thursday, July 08, 2010 15:39:09 -0500 Paul Schmehl wrote: Building CXX object agents/ontologies/CMakeFiles/niefast.dir/nmo.o Linking CXX static library ../../lib/libniefast.a [ 40%] Built target niefast gmake: *** [all] Error 2 *** Error code 1 Stop in /usr/ports/deskutils/kdepim4-runtime. I've read UPDATING and made the change to libassuan-1, but this port will not build. Anyone have an idea where to go to fix the problem? I fixed the problem by deselecting kde pim. I don't use it anyway. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: Review request for new port: sysutils/etcupdate
On Thursday, July 08, 2010 6:12:39 pm Doug Barton wrote: > On Thu, 8 Jul 2010, John Baldwin wrote: > > > This is a port for yet-another-/etc-merging tool that I wrote recently. It > > passes portlint -N with one bogus warning because /etc is in the comment. > > I didn't try installing/deinstalling but you seem to have the right > stuff in the Makefile for that. Overall it looks good, just a couple > comments: > 1. I don't think textproc is right for CATEGORIES, although sysutils is > of course. > 2. I don't think the do-fetch target is necessary, but if it is needed > when you test it that's fine. > 3. You have a pkg-descr~ file in the shar that should be deleted before > you commit it. > > Assuming it passes all the tests in the porter's handbook for install, > deinstall, package, etc. I'd say go ahead. :) Ok. Should I fix 1) and 2) for the sysutils/etcmerge port as well? (I used etcmerge as a template.) -- John Baldwin ___ 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"
FreeBSD Port: devel/mercurial
Hello Ollivier, Could you update devel/mercurial to version 1.6 (released 2010-07-01)? Thanks! ___ 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"
page fault on writing on fusefs mount through samba
Hello everyone. I'm getting kernel panics everytime I try to write a file to samba share which is a fuse mount. I tried samba 3.0.37, 3.3.13, 3.4.8, no difference. Tried on 8.0-RELEASE, on today's 8.1-PRERELEASE. How to reproduce: 1. Install /usr/ports/net/samba34, /usr/ports/sysutils/fusefs-unionfs 2. Add to default samba config: security = user [test] path = /test public = yes writeable = yes 3. unionfs -o allow_other /tmp /test 4. smbclient //IP/test put There we get a panic: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xe67bbc44 frame pointer = 0x28:0xe67bbc68 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1237 (smbd) trap number = 12 panic: page fault cpuid = 1 Uptime: 14m23s Physical memory: 1011 MB Dumping 73 MB: 58panic: bufwrite: buffer is not busy??? cpuid = 1 42 26 10 Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc08a1d47 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc08a1fa9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xc0bd72bc in trap_fatal (frame=0xe67bbc04, eva=0) at /usr/src/sys/i386/i386/trap.c:938 #4 0xc0bd7540 in trap_pfault (frame=0xe67bbc04, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:851 #5 0xc0bd7e85 in trap (frame=0xe67bbc04) at /usr/src/sys/i386/i386/trap.c:533 #6 0xc0bb9e7c in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0x in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) ___ 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"
updating py-wxPython28* to support cairo ?
Hi, are there any plans to update x11-toolkits/py-wxPython28* to a version which support cairo (2.8.9.0 or higher?) I could send in a patch myself... Regards, Rene -- http://www.rene-ladan.nl/ GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) ___ 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: Happy Release Time, Freeze is over
Note that we still ask our committers to avoid sweepting commits until after the release is officially out the door ... just in case. mcl ___ 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"
