Re: There is no release manager! There is no release manager!
On Wed, Oct 8, 2008 at 4:58 PM, Ryan Schmidt [EMAIL PROTECTED] wrote: Yes, but Julio Biason did volunteer, but I haven't seen his name on the lists before and I can't find any ports he maintains, hence I don't know his qualifications. Though he did volunteer, which is an important qualification in itself. :) Hi there! ;) Well, I was quiet for a while, 'cause I was reading jmpp (John?) document about releases. To be completely honest, it's not that different from the releases I did for my personal projects and the projects at work [wonderful world were everyone uses SVN ;)]. But, as anyone working in a big project, I'm scared of doing something stupid and botching the whole thing. I'm also listening to the worries of users and developers about this, so I can keep that in mind when doing it. And, as pointed before, I don't have an impressive number of ports under my belt (I just did send a small patch to ircstats, IIRC) but it's in my plans to get more in touch with MacPorts code before going further. I know people *want* a release, I just want to be sure it will not be the worst release ever. -- Julio Biason [EMAIL PROTECTED] Twitter: http://twitter.com/juliobiason ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
[Ticket #16549] gcc43: patch to add Ada support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, The Trac Ticket #16549 [1] now open for 3 weeks and it seem to be stalled. And it seems that the ticket is stalled over the fundamental problem on how to handle self hosted systems [2]. Now I still would like to go ahead so I would like to put the problem up for discussion. Both on user as well as development list, as both parties are affected on the possible outcome of discussion. Now I hope there is an outcome, otherwise I'll be forces to Plan-C: a complete fork into the GNU Ada Project [1]. Which at least for the potential users would be the worse outcome. To understand the problem I suggest to read up the wikipedia page [2]. As you see in a normal binary based distribution the normal users would never notice as the developers and packagers would take care of the difficult part. And they should have the experience as well to deal with it. However MacPorts is source based so one need a user friendly which is a little trickier. My current solution is a variant in gcc43 which can only be used when certain pre-condition are meed. However it was suggested that the Portfile should download and install everything needed on its own. That would result in a rather complex Portfile. At compl.lang.ada it was suggested that a separate gnat Portfile so the gcc* maintainer is not burdened by this approach. So what is everybody thinking. Regards Martin [1] http://trac.macports.org/ticket/16549 [2] http://en.wikipedia.org/wiki/Self-hosting [3] http://gnuada.sourceforge.net - -- Martin Krischik [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iD8DBQFI7FOPijwKaHyem9cRAqrhAKDZ6I1YzhCUxNBwcVEsxT/tQEXmkQCfYXCG E8mrybxOROepqAVRK8lIAk0= =06w9 -END PGP SIGNATURE- ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Important: MacPorts PortMgr Changes
In short, if we agree to the plan Markus, Juan and James proposed and open up the floor for nominations for PortMgr membership, I would be honored to accept your nomination. :-) Ok, then I hereby officially nominate you :) I wanted to do that anyway. Also I would like to nominate the following members (alphabetically ordered): - Bryan Blackburn - Rainer Mueller - Joshua Root Do the nominees accept the nomination? :) All this provided that the suggested plan is accepted. I don't know how we can officially establish acceptance for such a plan, but I think there was largely consent, so we should assume it is accepted. Am I wrong? By the way, who was meant to be able to vote eventually? All users or mailing list participants, or just maintainers/ members? Florian -- Florian Ebeling [EMAIL PROTECTED] [EMAIL PROTECTED] ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Important: MacPorts PortMgr Changes
On Oct 8, 2008, at 02:40, C. Florian Ebeling wrote: In short, if we agree to the plan Markus, Juan and James proposed and open up the floor for nominations for PortMgr membership, I would be honored to accept your nomination. :-) Ok, then I hereby officially nominate you :) I wanted to do that anyway. Thank you! :) Also I would like to nominate the following members (alphabetically ordered): - Bryan Blackburn - Rainer Mueller - Joshua Root Do the nominees accept the nomination? :) I second all three of these nominations! ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Important: MacPorts PortMgr Changes
C. Florian Ebeling wrote: In short, if we agree to the plan Markus, Juan and James proposed and open up the floor for nominations for PortMgr membership, I would be honored to accept your nomination. :-) Ok, then I hereby officially nominate you :) I wanted to do that anyway. Also I would like to nominate the following members (alphabetically ordered): - Bryan Blackburn - Rainer Mueller - Joshua Root Do the nominees accept the nomination? :) Yes, of course. Thank you, I am proud to be nominated. I realize that I am now with MacPorts for more than 1.5 years and I still enjoy working on it. I hope I have gathered enough experience with this project in this time to become a PortMgr :-) All this provided that the suggested plan is accepted. I don't know how we can officially establish acceptance for such a plan, but I think there was largely consent, so we should assume it is accepted. Am I wrong? Once we get an election plan it should be written down somewhere in the wiki (or even in the guide?) for reference. At least nobody had objections yet, so this is kind of accepted. By the way, who was meant to be able to vote eventually? All users or mailing list participants, or just maintainers/ members? We could restrict it to people listed on MacPortsDevelopers [1], although some of them seem to be inactive. And we have other people caring about MacPorts who are not developers. Rainer [1] http://trac.macports.org/wiki/MacPortsDevelopers ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: There is no release manager! There is no release manager!
On Oct 7, 2008, at 9:35 PM, Ryan Schmidt wrote: For the next release, I think we need version 1.7.0, not 1.6.1, because there are countless new features and a year's worth of bug fixes. That much work deserves more than just a bugfix version number increase. That means we release from trunk, not the 1.6 branch. A concern of mine is that the 1.6 branch contains some work that was done only there and not on trunk. I believe some of it was done on trunk in a different way, but I don't know if all changes from the 1.6 branch got put in trunk. Someone needs to figure out whether it was, and if not, identify what needs to be ported from 1.6 to trunk. Ideally that would happen before a 1.7.0 release. I agree entirely. I know that some kind folks have also been tentatively tossing their hat in the ring for this job, and for that I think we should all be thankful and also willing to both encourage and help them do so in any way necessary, but I also agree that we haven't had a release in some time and the accumulated backlog of work is likely to be a little daunting to anyone who isn't already intimately familiar with MacPorts. Ryan. I hate to do this to you, I really do, but given the degree to which you've been active in this project and the fact that you clearly know your way around, I don't suppose YOU would be willing to do this for at least one release, just to get the ball rolling again, as it were? The quoted paragraph clearly demonstrates an agenda of sorts, without which any RE cannot truly be effective, and I think the other volunteers would find you a more than credible candidate for the job and be willing to follow/help you as necessary. Again, I am not suggesting that you volunteer (or be volunteered :-) for anything more than this 1.7.0 release, we just need to break the log jam and there are very few people I can think of who have demonstrated your level of commitment to this project (the svn logs speak for themselves!). - Jordan ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Hey, I would like to propose that we cut the gordian knot.
(http://en.wikipedia.org/wiki/Gordian_knot) Having just read jmpp's request for a bit more time to sort out a voting process, I must confess to feeling more trepidation than assurance. To be completely fair, he does note several times that he and the rest of the moribund portmgr team would like to move quickly, but given the degree to which that group has also demonstrated itself to be overworked and less than involved in the day to day affairs of MacPorts, anything which delays a solution also runs the risk of blunting some of the current enthusiasm should said process end up dragging out longer than anticipated (which, as experience amply suggests, it invariably does) and I honestly don't think we can afford that at this late stage. I would therefore like to suggest that we simply ratify the following list rather than dragging out a lengthy voting process for a set of positions which, from a certain angle, might even be viewed as largely ceremonial since there is no real power afforded by membership in the portmgr team. Volunteers will always choose to follow (or not) such a group on the basis of the credibility of its individual members rather than any fancy paper hats they may be wearing, and the sooner we simply slam those hats on some credible heads and say Thank you! Get started!, the sooner we can all get back to discussing the real question of how to get to where we need to go next. As a courtesy to the outgoing portmgr team, I would also be perfectly happy to see them be the official ratifiers of this new team, assuming it passes their sniff test and they're also willing to do so in the next day or two, otherwise I would be just as happy with a statement along the lines of if there are no significant, well-argued objections in the next 72 hours, they're it! Quick, before they change their minds! :-) Portmgr (subject to individual acceptance, of course - we still haven't heard from two of the four): Ryan Schmidt Bryan Blackburn Rainer Mueller Joshua Root [Note: Any subset of the above would also be acceptable - 4 is not some magic minimum number, for all the reasons I've already outlined] Release engineering team: Ryan Schmidt (interim or longer, if he wants it) Julio Biason I'm really not trying to undercut anyone here, least of all jmpp, but seriously folks - we've been suffering from a leadership/directional vacuum for quite some time now and I don't think we need to bog down the only solution to be offered in quite some time by getting all constitutional about it or saying hey, wait, let's all think about this for awhile and engage in lengthy discussion!That might have been a good plan of action about a year ago, and I would be also more than happy to see the new portmgr establish a framework for elections and term limits and all the other checks and balances that they might wish to create for future generations, but what we need right now is an immediate interim government and some long overdue action on the release engineering front. Any objections? - Jordan ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: There is no release manager! There is no release manager!
On Oct 7, 2008, at 7:36 PM, paul beard wrote: FAIL. There has been a release manager and portmgr@ team for quite some time and this bug lingers, festers even. I don't know which reality you have been living in, but I think the weight of evidence points to exactly the opposite conclusion: There has not been a release manager or portmgr team for quite some time, which is why this and other bugs have been stuck in release limbo. Ryan has done an excellent job of summing that up and pointing to both the portmgr announcement and jmpp's rather excellent what it takes to make a release checklist (and I say rather excellent because, frankly, most release engineers do not bother to document their process anywhere near as well), so I will not belabor the point. Back when I was release engineer for FreeBSD, a job I held for some 9 years (which is one of the many reasons you don't see me exactly leaping at this opportunity myself - I've done my time in the box and then some), I also went out of my way to automate the process as much as possible, laziness being the mother of invention and all that. The end result was that just about anyone could (and still can) type make release at the top of the FreeBSD source tree and, assuming everything compiled and the internal consistency checks passed, see a full and complete set of bootable ISO images pop out the other end. This is still used on a daily basis to create the snapshot releases of FreeBSD-current, as well as by the current FreeBSD release engineering team, and I would therefore encourage whomever steps into these shoes to follow the same path since it's clearly paid off. It's a little more work up-front to make things turn-key like this, but it more than pays for itself in labor savings over the long term, in addition to also making it much easier to appoint interim release engineers during periods where the primary release engineer is burnt out or on vacation. So, consider that my two cents added to jmpp's already fine release engineer checklist. Well, OK, maybe three cents since I'd also like to take the opportunity to beat the drum (again) for the notion of simply tagging trunk and releasing from the tag rather than going to all the overhead of branching and trying to keep track of what should be merged and what should not. Were macports a much larger project, or perhaps one simply better staffed with infrastructure folk, I would actually argue in favor of branches since it's certainly the more controlled way to go, but I don't think the project can really afford the overhead right now and the model of declaring an impending release, converging things in trunk, tagging, and then declaring the trunk open again is one that can certainly work with a little overall project discipline. Given that Subversion also allows one to easily promote a tag to a branch (since they're really the same thing), you also always have the option of creating a temporary branch for any late-breaking issues that require just a couple more fixes without requiring that trunk be re-frozen. I think it's the best of both worlds, and certainly a lot less work than requiring the release engineer(s) to branch and do n weeks worth of merges until the release is ready, which is one of the reasons I think our releases became so laborious and infrequent. If this is part of a strategy of annoying users to the point where they sign up to be release manager just so it gets done, I'm not sure it will work. Civilians like me have no idea what the actual steps are to get a release cut, even one so trivial as the bug fix for 1.6. If the guys who were doing it had a hard time with it, what would make someone who isn't an active port maintainer think they could do it? Because release engineering is not rocket science, it's simply time and communications intensive. Anyone can do it, to some degree, assuming a basic engineering background and the ability to build and test bits. The part that suck up all the time is herding all the cats and managing the usual debate around what absolutely must, or must not, go into the next release (ultimately a judgement call, which is why good release engineers are also possessed of almost infinite amounts of patience and Solomon-like skills). Absent a release manager or team, what would it take to get a release schedule (quarterly? monthly?) and/or a roadmap? Not sure it makes a lot of sense to fret about a release manager if we don't really know what a release is or why we need one. A roadmap/set of benchmarks/goals would help and from there a release calendar could be derived. Roadmaps are great. I am a big believer in Roadmaps. The only problem with them in all-volunteer projects like this one is getting everyone to (a) agree on the roadmap and (b) actually execute it with any accuracy. Sometimes it's a
Re: Important: MacPorts PortMgr Changes
James Berry wrote: So we want to propose some ideas to get new leadership blood into MacPorts, while retaining the systemic knowledge and continuity that our continued presence can allow. We therefore want to put the following plan forward for community comment (and hopefully, thereafter, implementation): (1) That the MacPorts community elect a new slate of PortMgr individuals, probably three people, to continue to guide day-to-day MacPorts operations and direction. I think it would be good to add a time limitation to the PortMgr status. I propose to elect PortMgrs for the period of a year and hold a new election every year. This would allow existing PortMgrs to easily step back if they no longer have much time for the project. (2) That the three of us move into an Elder-council (advisory board, trustees, steering committee, etc), which will continue to help out and give guidance as needed, and watch over the long-term health of MacPorts assets such as domains and finances. I like this idea. Your experience and advice is still valuable! Rainer PS: It took some time to write this mail as I was a bit busy last week, but finally I managed to do so. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Important: MacPorts PortMgr Changes
On Oct 8, 2008, at 3:10 AM, C. Florian Ebeling wrote: In short, if we agree to the plan Markus, Juan and James proposed and open up the floor for nominations for PortMgr membership, I would be honored to accept your nomination. :-) Ok, then I hereby officially nominate you :) I wanted to do that anyway. Also I would like to nominate the following members (alphabetically ordered): - Bryan Blackburn - Rainer Mueller - Joshua Root Do the nominees accept the nomination? :) All this provided that the suggested plan is accepted. I don't know how we can officially establish acceptance for such a plan, but I think there was largely consent, so we should assume it is accepted. Am I wrong? By the way, who was meant to be able to vote eventually? All users or mailing list participants, or just maintainers/ members? Florian I would like to thank everyone who has participated in this very important thread for the comments they put forth and for, at least up until now, accepting and endorsing our proposed plan. Unless we experience any roadblocks from this point onward, I guess it's safe to say that Markus, James and I can now sit down to sort out the implementation details ASAP for sooner than later implementation. In any case, and as a personal draft note based on previous experience, I think the likelihood is that only active committers will be allowed to vote, for some definition of active that we'll certainly have to sort out; but in conclusion, no general public open voting. But in any case that's just me talking, so please don't take it as an official stance, not just yet. And with respect to nominations: it's very exciting to see people already warming up for the race, but if I may suggest anything it'd be to hold your horses a bit. For instance, PortMgr may come up with some sort of loose template through which we'd ask you to state to the public a couple of facts about yourself as the foundations for your ticket, or who knows what else, so until we have that sorted out it may not be too productive to have a potentially disordered influx of messages saying I'm in! in various different ways. I promise we'll get the plan fully ironed out pretty quick now, just hold your horses a bit longer! ;-) And, again, thanks to everyone for their participation and for continuously breathing life into the project! -- Florian Ebeling [EMAIL PROTECTED] [EMAIL PROTECTED] Regards,... -jmpp PS: Need I not say, we're open as always to suggestions on these implementation details we now need to iron out, like for instance on the couple of maybe cues I used as examples here. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: There is no release manager! There is no release manager!
On Wed, Oct 8, 2008 at 5:10 AM, Jordan K. Hubbard [EMAIL PROTECTED] wrote: On Oct 7, 2008, at 9:35 PM, Ryan Schmidt wrote: For the next release, I think we need version 1.7.0, not 1.6.1, because there are countless new features and a year's worth of bug fixes. That much work deserves more than just a bugfix version number increase. That means we release from trunk, not the 1.6 branch. A concern of mine is that the 1.6 branch contains some work that was done only there and not on trunk. I believe some of it was done on trunk in a different way, but I don't know if all changes from the 1.6 branch got put in trunk. Someone needs to figure out whether it was, and if not, identify what needs to be ported from 1.6 to trunk. Ideally that would happen before a 1.7.0 release. I agree entirely. I know that some kind folks have also been tentatively tossing their hat in the ring for this job, and for that I think we should all be thankful and also willing to both encourage and help them do so in any way necessary, but I also agree that we haven't had a release in some time and the accumulated backlog of work is likely to be a little daunting to anyone who isn't already intimately familiar with MacPorts. Ryan. I hate to do this to you, I really do, but given the degree to which you've been active in this project and the fact that you clearly know your way around, I don't suppose YOU would be willing to do this for at least one release, just to get the ball rolling again, as it were? The quoted paragraph clearly demonstrates an agenda of sorts, without which any RE cannot truly be effective, and I think the other volunteers would find you a more than credible candidate for the job and be willing to follow/help you as necessary. Again, I am not suggesting that you volunteer (or be volunteered :-) for anything more than this 1.7.0 release, we just need to break the log jam and there are very few people I can think of who have demonstrated your level of commitment to this project (the svn logs speak for themselves!). Sounds like an excellent solution. Breaking the log jam is an excellent summation of what's needed here and I think once people can see the accumulated body of work that comes with the 1.7 release, the energy level and enthusiasm will go up a bit. Seconded, in other words. -- Paul Beard / www.paulbeard.org/ paulbeard.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: There is no release manager! There is no release manager!
On Wed, Oct 8, 2008 at 7:01 AM, [EMAIL PROTECTED] wrote: I don't know which reality you have been living in, but I think the weight of evidence points to exactly the opposite conclusion: There has not been a release manager or portmgr team for quite some time, which is why this and other bugs have been stuck in release limbo. Just the daily reality of an end-user. I didn't realize those positions were completely vacant. Maybe in future those responsibilities, if they are important to the ongoing success of the project, can be taken up by someone else, even on an interim or one shot basis. -- Paul Beard / www.paulbeard.org/ paulbeard.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: [macports-mgr] Hey, I would like to propose that we cut the gordian knot.
Hi Jordan, As usual, you work well to cut through the bureaucracy ;) I'm not so opposed to going along with your suggestion to just get this thing done, or that an official vote may be superflous. But I also think it's premature to assume that the list of nominees so far, is complete, given that we haven't called for nominees (or interested parties) yet. So I'd like to request that anybody interested in PortMgr announce their intent (via nomination, or not) by the close of this Friday. James On Oct 8, 2008, at 5:55 AM, Jordan K. Hubbard wrote: (http://en.wikipedia.org/wiki/Gordian_knot) Having just read jmpp's request for a bit more time to sort out a voting process, I must confess to feeling more trepidation than assurance. To be completely fair, he does note several times that he and the rest of the moribund portmgr team would like to move quickly, but given the degree to which that group has also demonstrated itself to be overworked and less than involved in the day to day affairs of MacPorts, anything which delays a solution also runs the risk of blunting some of the current enthusiasm should said process end up dragging out longer than anticipated (which, as experience amply suggests, it invariably does) and I honestly don't think we can afford that at this late stage. I would therefore like to suggest that we simply ratify the following list rather than dragging out a lengthy voting process for a set of positions which, from a certain angle, might even be viewed as largely ceremonial since there is no real power afforded by membership in the portmgr team. Volunteers will always choose to follow (or not) such a group on the basis of the credibility of its individual members rather than any fancy paper hats they may be wearing, and the sooner we simply slam those hats on some credible heads and say Thank you! Get started!, the sooner we can all get back to discussing the real question of how to get to where we need to go next. As a courtesy to the outgoing portmgr team, I would also be perfectly happy to see them be the official ratifiers of this new team, assuming it passes their sniff test and they're also willing to do so in the next day or two, otherwise I would be just as happy with a statement along the lines of if there are no significant, well-argued objections in the next 72 hours, they're it! Quick, before they change their minds! :-) Portmgr (subject to individual acceptance, of course - we still haven't heard from two of the four): Ryan Schmidt Bryan Blackburn Rainer Mueller Joshua Root [Note: Any subset of the above would also be acceptable - 4 is not some magic minimum number, for all the reasons I've already outlined] Release engineering team: Ryan Schmidt (interim or longer, if he wants it) Julio Biason I'm really not trying to undercut anyone here, least of all jmpp, but seriously folks - we've been suffering from a leadership/ directional vacuum for quite some time now and I don't think we need to bog down the only solution to be offered in quite some time by getting all constitutional about it or saying hey, wait, let's all think about this for awhile and engage in lengthy discussion! That might have been a good plan of action about a year ago, and I would be also more than happy to see the new portmgr establish a framework for elections and term limits and all the other checks and balances that they might wish to create for future generations, but what we need right now is an immediate interim government and some long overdue action on the release engineering front. Any objections? - Jordan ___ macports-mgr mailing list [EMAIL PROTECTED] http://lists.macosforge.org/mailman/listinfo.cgi/macports-mgr smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Call for PortMgr interest/nominations
Per my previous note to Jordan, I'd like to set a deadline of this coming Friday, Oct 10, for those wishing to be part of the new PortMgr slate. If you are interested in these posts, please express your interest, or ask somebody to nominate you, by that time. In throwing in your hat, or accepting a nomination, I think it would be appropriate to include a paragraph or so about what makes you want to be involved, and why we should care ;) Such notices should be given in email to the MacPorts development list. If you have already written such a note, you don't need to do so again. Based on the amount of interest, we'll decide on an appropriate way to select the new slate. James smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Hey, I would like to propose that we cut the gordian knot.
Well spoken, Jordan! On Wed, Oct 8, 2008 at 2:55 PM, Jordan K. Hubbard [EMAIL PROTECTED] wrote: (http://en.wikipedia.org/wiki/Gordian_knot) Having just read jmpp's request for a bit more time to sort out a voting process, I must confess to feeling more trepidation than assurance. To be completely fair, he does note several times that he and the rest of the moribund portmgr team would like to move quickly, but given the degree to which that group has also demonstrated itself to be overworked and less than involved in the day to day affairs of MacPorts, anything which delays a solution also runs the risk of blunting some of the current enthusiasm should said process end up dragging out longer than anticipated (which, as experience amply suggests, it invariably does) and I honestly don't think we can afford that at this late stage. I would therefore like to suggest that we simply ratify the following list rather than dragging out a lengthy voting process for a set of positions which, from a certain angle, might even be viewed as largely ceremonial since there is no real power afforded by membership in the portmgr team. Volunteers will always choose to follow (or not) such a group on the basis of the credibility of its individual members rather than any fancy paper hats they may be wearing, and the sooner we simply slam those hats on some credible heads and say Thank you! Get started!, the sooner we can all get back to discussing the real question of how to get to where we need to go next. As a courtesy to the outgoing portmgr team, I would also be perfectly happy to see them be the official ratifiers of this new team, assuming it passes their sniff test and they're also willing to do so in the next day or two, otherwise I would be just as happy with a statement along the lines of if there are no significant, well-argued objections in the next 72 hours, they're it! Quick, before they change their minds! :-) Portmgr (subject to individual acceptance, of course - we still haven't heard from two of the four): Ryan Schmidt Bryan Blackburn Rainer Mueller Joshua Root [Note: Any subset of the above would also be acceptable - 4 is not some magic minimum number, for all the reasons I've already outlined] Release engineering team: Ryan Schmidt (interim or longer, if he wants it) Julio Biason I'm really not trying to undercut anyone here, least of all jmpp, but seriously folks - we've been suffering from a leadership/directional vacuum for quite some time now and I don't think we need to bog down the only solution to be offered in quite some time by getting all constitutional about it or saying hey, wait, let's all think about this for awhile and engage in lengthy discussion!That might have been a good plan of action about a year ago, and I would be also more than happy to see the new portmgr establish a framework for elections and term limits and all the other checks and balances that they might wish to create for future generations, but what we need right now is an immediate interim government and some long overdue action on the release engineering front. Any objections? - Jordan ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users -- Florian Ebeling [EMAIL PROTECTED] ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: There is no release manager! There is no release manager!
Jordan K. Hubbard wrote: Ryan. I hate to do this to you, I really do, but given the degree to which you've been active in this project and the fact that you clearly know your way around, I don't suppose YOU would be willing to do this for at least one release, just to get the ball rolling again, as it were? The quoted paragraph clearly demonstrates an agenda of sorts, without which any RE cannot truly be effective, and I think the other volunteers would find you a more than credible candidate for the job and be willing to follow/help you as necessary. Again, I am not suggesting that you volunteer (or be volunteered :-) for anything more than this 1.7.0 release, we just need to break the log jam and there are very few people I can think of who have demonstrated your level of commitment to this project (the svn logs speak for themselves!). I second the nomination of Ryan as executive release manager. He has been incredibly helpful, consistently skilful, and invariably polite, and it can only help the project to give him more responsibilities. As he knows the ropes and has been active with port updates, he is already at lift-off speed for the task. He will also be a great resource for the rest of the release manager team; it's important we avoid the situation where too much rests for too long on one pair of shoulders. For the immediate next release, we will all be very relieved and grateful to have an experienced hand. David ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: [macports-mgr] Hey, I would like to propose that we cut the gordian knot.
Greetings all, I am a relatively silent observer of this list, and well felt it worth chiming in. Since I am on the exec board of the BSD Cert Group, which has experienced more than their share of staled elections I happen to have a little experience with this sort of thing. I would like to offer the following suggestions. 1. for the sake of the project install these members now, with a deadline to make an official release and a 1 year term limit. 2. setup an executive board to deal with the whole mess of by laws and elections ( say the 3 grandfathers and perhaps two others). 3. keep it all simple as everyone is a volunteer and this sort of thing can become a bike shed big enough to park an aircraft carrier. 4. by this time next year the by laws and all that governance mess should be completed, thus opening up for the appropriate elections as needed. Cheers, Mikel King CEO, Olivent Technologies Senior Editor, Daemon News Columnist, BSD Magazine 6 Alpine Court Medford, NY 11763 http://www.olivent.com http://www.daemonnews.org http://www.bsdmag.org skype: mikel.king t: 631.627.3055 m: 646.554.3660 +--+ How do you spell cooperation? Pessimists use each other, but optimists help each other. Collaboration feeds your spirit, while competition only stokes your ego. You'll find the best way to get along. +--+ On Oct 8, 2008, at 10:42 AM, James Berry wrote: Hi Jordan, As usual, you work well to cut through the bureaucracy ;) I'm not so opposed to going along with your suggestion to just get this thing done, or that an official vote may be superflous. But I also think it's premature to assume that the list of nominees so far, is complete, given that we haven't called for nominees (or interested parties) yet. So I'd like to request that anybody interested in PortMgr announce their intent (via nomination, or not) by the close of this Friday. James On Oct 8, 2008, at 5:55 AM, Jordan K. Hubbard wrote: (http://en.wikipedia.org/wiki/Gordian_knot) Having just read jmpp's request for a bit more time to sort out a voting process, I must confess to feeling more trepidation than assurance. To be completely fair, he does note several times that he and the rest of the moribund portmgr team would like to move quickly, but given the degree to which that group has also demonstrated itself to be overworked and less than involved in the day to day affairs of MacPorts, anything which delays a solution also runs the risk of blunting some of the current enthusiasm should said process end up dragging out longer than anticipated (which, as experience amply suggests, it invariably does) and I honestly don't think we can afford that at this late stage. I would therefore like to suggest that we simply ratify the following list rather than dragging out a lengthy voting process for a set of positions which, from a certain angle, might even be viewed as largely ceremonial since there is no real power afforded by membership in the portmgr team. Volunteers will always choose to follow (or not) such a group on the basis of the credibility of its individual members rather than any fancy paper hats they may be wearing, and the sooner we simply slam those hats on some credible heads and say Thank you! Get started!, the sooner we can all get back to discussing the real question of how to get to where we need to go next. As a courtesy to the outgoing portmgr team, I would also be perfectly happy to see them be the official ratifiers of this new team, assuming it passes their sniff test and they're also willing to do so in the next day or two, otherwise I would be just as happy with a statement along the lines of if there are no significant, well-argued objections in the next 72 hours, they're it! Quick, before they change their minds! :-) Portmgr (subject to individual acceptance, of course - we still haven't heard from two of the four): Ryan Schmidt Bryan Blackburn Rainer Mueller Joshua Root [Note: Any subset of the above would also be acceptable - 4 is not some magic minimum number, for all the reasons I've already outlined] Release engineering team: Ryan Schmidt (interim or longer, if he wants it) Julio Biason I'm really not trying to undercut anyone here, least of all jmpp, but seriously folks - we've been suffering from a leadership/ directional vacuum for quite some time now and I don't think we need to bog down the only solution to be offered in quite some time by getting all constitutional about it or saying hey, wait, let's all think about this for awhile and engage in lengthy discussion!That might have been a good plan of action about a year ago, and I would be also more than happy to see the new portmgr establish a framework for
linking to libssl and libcrypt
I'm attempting to build a static library that links to both libssl.a and libcrypto.a. When I build it I get these has no symbols messages. Any advice on resolving this? Thanks. # Building liballkeyrtv.a libtool -static -o liballkeyrtv.a allkeyrtv.o parseini.o tksc.o TkscTls.o TkscSockets.o skeys.o writelogs.o tThreads.o /opt/local/lib/ libssl.a /opt/local/lib/libcrypto.a libtool: file: /opt/local/lib/libssl.a(kssl.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(ebcdic.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(rand_win.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(rand_os2.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(rand_nw.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(e_camellia.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(e_seed.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(e_rc5.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(m_mdc2.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(v3_asid.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(v3_addr.o) has no symbols Finished building target: liballkeyrtv.a ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
upgrading gimp2
I am trying to upgrade gimp2 with python scripting enabled. However, during the install ports is trying to install python24. Why is that? Shouldn't port know that I have python25 already installed? I already have python25 installed and don't want to install python24. Is there a way to keep gimp2 from trying to install python24. I was looking at the dependencies of gimp2 and saw that only py25-gtk is the only python dependency. Are there any other dependencies of gimp2 that have python24 as a dependent? Any help or clarification is much appreciated. Thank you, Duc ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: linking to libssl and libcrypt
On Wed, Oct 08, 2008 at 01:44:19PM -0700, Shawn Protsman said: I'm attempting to build a static library that links to both libssl.a and libcrypto.a. When I build it I get these has no symbols messages. Any advice on resolving this? Thanks. Ignore them? Some source files end up, based on #defines, to have nothing in them, so when compiled, they have no symbols. Eg, rand_os2.c: http://cvs.openssl.org/fileview?f=openssl/crypto/rand/rand_os2.c when built on anything other than OS/2 will have nothing, hence the message you see from libtool below. Note also at the end that it finished building the library, so does it work as expected? Bryan # Building liballkeyrtv.a libtool -static -o liballkeyrtv.a allkeyrtv.o parseini.o tksc.o TkscTls.o TkscSockets.o skeys.o writelogs.o tThreads.o /opt/local/lib/ libssl.a /opt/local/lib/libcrypto.a libtool: file: /opt/local/lib/libssl.a(kssl.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(ebcdic.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(rand_win.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(rand_os2.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(rand_nw.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(e_camellia.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(e_seed.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(e_rc5.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(m_mdc2.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(v3_asid.o) has no symbols libtool: file: /opt/local/lib/libcrypto.a(v3_addr.o) has no symbols Finished building target: liballkeyrtv.a ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: upgrading gimp2
Duc N Nguyen wrote: I am trying to upgrade gimp2 with python scripting enabled. However, during the install ports is trying to install python24. Why is that? Shouldn't port know that I have python25 already installed? I already have python25 installed and don't want to install python24. Is there a way to keep gimp2 from trying to install python24. I was looking at the dependencies of gimp2 and saw that only py25-gtk is the only python dependency. Are there any other dependencies of gimp2 that have python24 as a dependent? Any help or clarification is much appreciated. Thank you, Duc ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users Yes, it looks like asciidoc depends on python24. Perhaps the asciidoc maintainer can comment on this. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
macports and Xcode
Hello all, Probably a ridiculous question. (never stopped me before) Is macports always and forever dependent upon Xcode? Can it be de-coupled? ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: linking to libssl and libcrypt
Shawn Protsman wrote: Undefined symbols: _inflateEnd, referenced from: _zlib_stateful_free_ex_data in liballkeyrtv.a(c_zlib.o) _bio_zlib_free in liballkeyrtv.a(c_zlib.o) _inflateInit_, referenced from: Need -lz. Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: macports and Xcode
On Wed, Oct 08, 2008 at 02:16:08PM -0700, rhubbell said: Hello all, Probably a ridiculous question. (never stopped me before) Is macports always and forever dependent upon Xcode? Can it be de-coupled? As long as MacPorts builds ports from source, then Xcode is an absolute requirement (for gcc etc). If the day comes that MacPorts distributes binary packages, then Xcode may only be needed by some ports and not MacPorts as a whole. Bryan ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: linking to libssl and libcrypt
On Wed, Oct 08, 2008 at 02:27:07PM -0700, Shawn Protsman said: [...] Thanks for the quick reply. I copied the static lib to /usr/local/lib and then tried to compile my binary which links to liballkeyrtv.a: Building target: keyreq ##gcc -lallkeyrtv -o keyreq keyreq.o gcc -o keyreq keyreq.o /usr/local/lib/liballkeyrtv.a Undefined symbols: _inflateEnd, referenced from: _zlib_stateful_free_ex_data in liballkeyrtv.a(c_zlib.o) _bio_zlib_free in liballkeyrtv.a(c_zlib.o) [...] Looks like you need to link libz as well. Bryan ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: upgrading gimp2
David Evans wrote: Duc N Nguyen wrote: I am trying to upgrade gimp2 with python scripting enabled. However, during the install ports is trying to install python24. Why is that? Shouldn't port know that I have python25 already installed? I already have python25 installed and don't want to install python24. Is there a way to keep gimp2 from trying to install python24. I was looking at the dependencies of gimp2 and saw that only py25-gtk is the only python dependency. Are there any other dependencies of gimp2 that have python24 as a dependent? Any help or clarification is much appreciated. Thank you, Duc ___ Yes, it looks like asciidoc depends on python24. Perhaps the asciidoc maintainer can comment on this. To be a bit clearer, gimp2 depends on gegl which depends on asciidoc to generate documentation. I have just submitted a patch for gegl which disables docs unless you explicitly ask for them via the +html_doc variant. When this is committed, it should avoid the dependency you mention. Also upgrades gegl to 0.0.20. See https://trac.macports.org/ticket/16796 Let me know if this helps Dave ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: upgrading gimp2
On Oct 8, 2008, at 3:48 PM, David Evans wrote: David Evans wrote: Duc N Nguyen wrote: I am trying to upgrade gimp2 with python scripting enabled. However, during the install ports is trying to install python24. Why is that? Shouldn't port know that I have python25 already installed? I already have python25 installed and don't want to install python24. Is there a way to keep gimp2 from trying to install python24. I was looking at the dependencies of gimp2 and saw that only py25-gtk is the only python dependency. Are there any other dependencies of gimp2 that have python24 as a dependent? Any help or clarification is much appreciated. Thank you, Duc ___ Yes, it looks like asciidoc depends on python24. Perhaps the asciidoc maintainer can comment on this. To be a bit clearer, gimp2 depends on gegl which depends on asciidoc to generate documentation. I have just submitted a patch for gegl which disables docs unless you explicitly ask for them via the +html_doc variant. When this is committed, it should avoid the dependency you mention. Also upgrades gegl to 0.0.20. See https://trac.macports.org/ticket/16796 Let me know if this helps Dave ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users I just upgraded to gimp 2.6. The irony is that whenever I select help in gimp2 it crashes. So, I have the docs installed, I would guess, but trying to use them causes a crash. --Adam ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Call for PortMgr interest/nominations
On Thu, Oct 9, 2008 at 1:49 AM, James Berry [EMAIL PROTECTED] wrote: Per my previous note to Jordan, I'd like to set a deadline of this coming Friday, Oct 10, for those wishing to be part of the new PortMgr slate. If you are interested in these posts, please express your interest, or ask somebody to nominate you, by that time. In throwing in your hat, or accepting a nomination, I think it would be appropriate to include a paragraph or so about what makes you want to be involved, and why we should care ;) Such notices should be given in email to the MacPorts development list. If you have already written such a note, you don't need to do so again. Well, as James put it, I'm interested in be the Release Engineer. Why I want to do this? 'Cause I really enjoy MacPorts and that's one of the things that keep me sane when using a Mac (and it's always the first thing I install when I need to reinstall OS X after breaking it.) Why you should care? Well, I'm a maintainer of a small project (Mitter, a Twitter client) and I'm doing releases almost in the same way MacPorts is released. It's also very similar to the way we release code (internally) at work. [I think there is one reason for not being nominated: I don't have much experience with the base code and, so far, I've just contributed with one Portfile. But, in my defense, I could say that a release is not affected by the code -- or so I hope ;)] -- Julio Biason [EMAIL PROTECTED] Twitter: http://twitter.com/juliobiason ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
