From phil at bolthole.com Fri Jul 1 00:16:35 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 30 Jun 2011 15:16:35 -0700 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> Message-ID: It has been pointed out to me that I made an error in reading. I misread that Maciej wanted to protect "the proposal", but he in fact wrote of protecting "the procedure" I apologise for my mischaracterization in that regard. That being said, I fail to see how the Secretary has "a duty" to protect a procedure that was never officially made a procedure of the organization in the first place. From bwalton at opencsw.org Fri Jul 1 02:29:28 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 30 Jun 2011 20:29:28 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> Message-ID: <1309480086-sup-922@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Jun 30 16:46:46 -0400 2011: Hi Phil, > I request that there be an option for those people who see a value > in required 2nd party review, to be able to register that opinion > with their vote, separate from whether they support the new > mechanisms for package release flow. This option is not relevant to the proposal at hand. People can accept, reject or abstain. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Jul 1 02:31:18 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 30 Jun 2011 20:31:18 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> Message-ID: <1309480213-sup-8769@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Jun 30 17:54:32 -0400 2011: > also, I am fully encouraging that this "vote reaches completion". I'm > only requesting that the ballot have an additional choice box on it. An irrelevant choice, given the proposal at hand. If you had any real interest in automating things before this came up, you had plenty of time and unique opportunity to do so. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Fri Jul 1 02:48:20 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 30 Jun 2011 17:48:20 -0700 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: <1309480213-sup-8769@pinkfloyd.chass.utoronto.ca> References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> <1309480213-sup-8769@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Jun 30, 2011 at 5:31 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Thu Jun 30 17:54:32 -0400 2011: > >> also, I am fully encouraging that this "vote reaches completion". I'm >> only requesting that the ballot have an additional choice box on it. > > An irrelevant choice, given the proposal at hand. ?If you had any real > interest in automating things before this came up, you had plenty of > time and unique opportunity to do so. ah, no, I did not have "plenty of time". I just barely have enough free time to deal with the burden of being release manager. (and unfortunately not even that, at times). I have 2 hour a day commute, and 3 children under 10 years old. I barely have a handful of extra free hours to myself, let alone the many hours of time it takes to plan, code, and test a structure such as Maciej et. al have been working on. From bwalton at opencsw.org Fri Jul 1 02:50:15 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 30 Jun 2011 20:50:15 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> <1309480213-sup-8769@pinkfloyd.chass.utoronto.ca> Message-ID: <1309481398-sup-7593@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Jun 30 20:48:20 -0400 2011: > ah, no, I did not have "plenty of time". I just barely have enough > free time to deal with the burden of being release manager. (and > unfortunately not even that, at times). > I have 2 hour a day commute, and 3 children under 10 years old. I > barely have a handful of extra free hours to myself, let alone the > many hours of time it takes to plan, code, and test a structure such > as Maciej et. al have been working on. So the desire but no expression of such? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Fri Jul 1 02:59:21 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 30 Jun 2011 17:59:21 -0700 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: <1309481398-sup-7593@pinkfloyd.chass.utoronto.ca> References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> <1309480213-sup-8769@pinkfloyd.chass.utoronto.ca> <1309481398-sup-7593@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Jun 30, 2011 at 5:50 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Thu Jun 30 20:48:20 -0400 2011: > >> ah, no, I did not have "plenty of time". I just barely have enough >> free time to deal with the burden of being release manager. (and >> unfortunately not even that, at times). >> I have 2 hour a day commute, and 3 children under 10 years old. ?I >> barely have a handful of extra free hours to myself, let alone the >> many hours of time it takes to plan, code, and test a structure such >> as Maciej et. al have been working on. > > So the desire but no expression of such? You could say that. I'm not in the habit of saying, "this really sucks, and I have no time to make it better. Could someone else please spend days of work coding something to make my life easier?" :-} From jcraig at opencsw.org Fri Jul 1 04:03:27 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Thu, 30 Jun 2011 22:03:27 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Jun 30, 2011 at 6:16 PM, Philip Brown wrote: > That being said, I fail to see how the Secretary has "a duty" to > protect a procedure that was never officially made a procedure of the > organization in the first place. Regardless of duties I feel it is important that the current proposal stand on its own. We need to make some progress and that requires a clear and unambiguous vote. Allowing a myriad of choices would simply split the vote. If one cannot vote for the proposal as written then choose to deny or abstain. Further, the review process is not critical to the success of failure of determining our goals of implementing an automated release process. This proposal neither support or denies the possibility of creating a review process in the future. Phil, I would suggest you write up a proposal to cover the review process as you see fit. Please remember it will be voted upon by a broad audience and therefore must meet that audiences needs and desires. From maciej at opencsw.org Fri Jul 1 11:44:59 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 1 Jul 2011 10:44:59 +0100 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> <1309480213-sup-8769@pinkfloyd.chass.utoronto.ca> <1309481398-sup-7593@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/7/1 Philip Brown : > On Thu, Jun 30, 2011 at 5:50 PM, Ben Walton wrote: >> Excerpts from Philip Brown's message of Thu Jun 30 20:48:20 -0400 2011: >> >>> ah, no, I did not have "plenty of time". I just barely have enough >>> free time to deal with the burden of being release manager. (and >>> unfortunately not even that, at times). >>> I have 2 hour a day commute, and 3 children under 10 years old. ?I >>> barely have a handful of extra free hours to myself, let alone the >>> many hours of time it takes to plan, code, and test a structure such >>> as Maciej et. al have been working on. >> >> So the desire but no expression of such? > > You could say that. > I'm not in the habit of saying, "this really sucks, and I have no time > to make it better. Could someone else please spend days of work coding > something to make my life easier?" > :-} Why not say that? You could still communicate what are the biggest issues and where to look to solve them. Here's an example of a problem description: http://lists.opencsw.org/pipermail/devel/2011-March/018341.html (currently alleviated by memoizing GetPkgByPath in r14920) Maciej From maciej at opencsw.org Fri Jul 1 12:16:20 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 1 Jul 2011 11:16:20 +0100 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/6/30 Philip Brown : > I fail to see how the Secretary has "a duty" to > protect a procedure that was never officially made a procedure of the > organization in the first place. When I was appointed the position, there was no existing voting procedure. Therefore, I am following the simplest possible procedure that makes sense and guarantees resolution. There may be differences between what you and I think what should be the details of the procedure - it should not surprise you. If we haven't talked about it, what would be the reason to have exactly the same idea of the voting procedure? Let's suppose that you wish is to have a more complex procedure (e.g. [1]). A way to adopt one, would be to write a proposal and have a vote. In such scenario, you, as a potential proponent, should be happy about protecting the procedure. If the secretary allowed anyone to modify the way voting is handled, it would be easier to interfere, delay, or block the vote entirely. Such problems have happened[2] in the recent past. When using a simple but effective procedure, there is a much bigger chance that a proposal to adopt a more complex voting procedure, is resolved. Otherwise, you could have never be able to introduce a new voting procedure. What are other people's opinions on this? Am I doing the wrong thing? Or the right thing? Maciej [1] http://www.debian.org/vote/howto_follow.en.html [2] http://lists.opencsw.org/pipermail/maintainers/2011-March/014348.html From maciej at opencsw.org Fri Jul 1 12:49:13 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 1 Jul 2011 11:49:13 +0100 Subject: [csw-maintainers] where is graphviz-2.28 ? In-Reply-To: References: <4E03C388.2070207@opencsw.org> <4E03CB1B.9020408@opencsw.org> <4E0495DC.2070508@opencsw.org> <4E04A8E2.1060602@opencsw.org> <4E04DD8D.7050109@opencsw.org> Message-ID: 2011/6/24 Philip Brown : > On Fri, Jun 24, 2011 at 11:55 AM, John Ellson wrote: >> >> I'm assuming that the ImageMagic fix is small and that we should have a new >> set of packages in a few days, but Dago didn't say when he was going to be >> back. >> >> I'm not even so worried about the web pages on this occasion. ? It just >> seems to me that some scripts need to be fixed so that web updates are >> atomic and only happen if batching is successful. > > > Would be useful. > However, at my utility script level, there is unfortunately no concept > of a maintainer-grouped-batch at the moment. > There is only individual-package visibility. > > As I said, this isnt a problem with smaller grouped packages, so there > isnt much incentive to write something fancier. > I could in theory write something that would be more package-group > aware. However, it would probably involve a lot of saved state, and a > high (relative) degree of inner complexity. Which would mean high > likelyhood of bugs. > My gut level risk/reward analyzer suggests it would probably end up > causing more problems than it would solve. Trygve had an idea to create long-lived catalog update objects. I didn't attempt to implement them yet. It looks a bit like implementing version control for catalog, so I'm still looking if there's a way of achieving the same objective (controlling complex updates) in some other, simpler way. Maciej [1] http://buildfarm.opencsw.org/~trygvis/upload-application/opencsw-upload-process-application.html From bonivart at opencsw.org Fri Jul 1 14:13:56 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 1 Jul 2011 14:13:56 +0200 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/7/1 Maciej Blizi?ski : > What are other people's opinions on this? ?Am I doing the wrong thing? > Or the right thing? You're doing the right thing. Keep it simple, get it done. /peter From phil at bolthole.com Fri Jul 1 15:59:16 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 1 Jul 2011 06:59:16 -0700 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Jun 30, 2011 at 7:03 PM, Jonathan Craig wrote: > On Thu, Jun 30, 2011 at 6:16 PM, Philip Brown wrote: >> That being said, I fail to see how the Secretary has "a duty" to >> protect a procedure that was never officially made a procedure of the >> organization in the first place. > > Regardless of duties I feel it is important that the current proposal > stand on its own. ?We need to make some progress and that requires a > clear and unambiguous vote. ?Allowing a myriad ?of choices would > simply split the vote. ?If one cannot vote for the proposal as written > then choose to deny or abstain. How does the adjusted vote, as I proposed, impeed "progress"? It seems as though the mechanisms, while nearly completely, still have a week or two worth of tweaks to make it fully live(?) During that time, we could discuss, in parallel, what kind of reviews other people may want. Or, if no-one else voted for the reviews. just have peace and quiet :) > Phil, I would suggest you write up a proposal to cover the review > process as you see fit. ?Please remember it will be voted upon by a > broad audience and therefore must meet that audiences needs and > desires. I am not entirely sure what the audience's "needs and desires" are at this point. I'm hoping that if a vote shows interest in the reviews, that others among the "more active" folks, would then be motivated to chime in and help shape what it would look like. Without the vote of interest *first*, though, I dont think the discussion would be nearly as productive. From jcraig at opencsw.org Fri Jul 1 16:50:50 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Fri, 1 Jul 2011 10:50:50 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> Message-ID: On Fri, Jul 1, 2011 at 9:59 AM, Philip Brown wrote: > On Thu, Jun 30, 2011 at 7:03 PM, Jonathan Craig wrote: >> On Thu, Jun 30, 2011 at 6:16 PM, Philip Brown wrote: > > How does the adjusted vote, as I proposed, impeed "progress"? > It seems as though the mechanisms, while nearly completely, still have > a week or two worth of tweaks to make it fully live(?) > During that time, we could discuss, in parallel, what kind of reviews > other people may want. > Or, if no-one else voted for the reviews. just have peace and quiet :) If you split the vote across a number of choices then we will end up with no clear direction. Your trying to ride the coattails of the automated release proposal and unfairly disrupting that decision. You need to get out of the way of the first proposal and begin work on your own proposal. If you had done this to begin with you wouldn't have lost the last week to arguments with the automated release process. > > >> Phil, I would suggest you write up a proposal to cover the review >> process as you see fit. ?Please remember it will be voted upon by a >> broad audience and therefore must meet that audiences needs and >> desires. > > I am not entirely sure what the audience's "needs and desires" are at this > point. I'm hoping that if a vote shows interest in the reviews, that others > among the "more active" folks, would then be motivated to chime in > and help shape what it would look like. > Without the vote of interest *first*, though, I dont think the discussion > would be nearly as productive. No reason to turn a formal vote on the release process into a straw vote into the interest others may share with you in a review process. If your looking to determine interest in a review process then I suggest your start a new thread and pose that question to the maintainers. The sooner you do this the sooner you will have your answer. At this time nobody, beyond you, has voiced interest in inserting a peer review step into the release proposal, especially if the review process is largely undefined. The only definition I have seen from you is that a "group" will "take a look at" packages and "discuss" whether to "allow" the package to release. How's the group formed, what specifically will they do as part of a review, how are the results of the review going to be used. The process needs to be deterministic and as free from subjective standards as possible. Look less to controlling unruly/uninformed maintainers and more towards using the results of review to inform the standards process, improve maintainer documentation and the future development of automated checks. From rupert at opencsw.org Fri Jul 1 17:12:03 2011 From: rupert at opencsw.org (rupert THURNER) Date: Fri, 1 Jul 2011 17:12:03 +0200 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> Message-ID: On Fri, Jul 1, 2011 at 16:50, Jonathan Craig wrote: > On Fri, Jul 1, 2011 at 9:59 AM, Philip Brown wrote: > > On Thu, Jun 30, 2011 at 7:03 PM, Jonathan Craig > wrote: > >> On Thu, Jun 30, 2011 at 6:16 PM, Philip Brown > wrote: > > > > How does the adjusted vote, as I proposed, impeed "progress"? > > It seems as though the mechanisms, while nearly completely, still have > > a week or two worth of tweaks to make it fully live(?) > > During that time, we could discuss, in parallel, what kind of reviews > > other people may want. > > Or, if no-one else voted for the reviews. just have peace and quiet :) > > If you split the vote across a number of choices then we will end up > with no clear direction. Your trying to ride the coattails of the > automated release proposal and unfairly disrupting that decision. You > need to get out of the way of the first proposal and begin work on > your own proposal. If you had done this to begin with you wouldn't > have lost the last week to arguments with the automated release > process. > if you want to have a fair result even if you have similar possibilities in the selection, one might consider the debian method of voting, http://en.wikipedia.org/wiki/Cloneproof_Schwartz_Sequential_Dropping. otherwise opencsw will be called thunderbay, not lakehead :) rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcraig at opencsw.org Fri Jul 1 17:38:02 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Fri, 1 Jul 2011 11:38:02 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> Message-ID: On Fri, Jul 1, 2011 at 11:12 AM, rupert THURNER wrote: > > if you want to have a fair result even if you have similar possibilities in > the selection, one might consider the debian method of > voting,?http://en.wikipedia.org/wiki/Cloneproof_Schwartz_Sequential_Dropping. > otherwise opencsw will be called thunderbay, not lakehead :) > rupert. That is an elegant solution when choosing amongst a group of like items. If we were determining the color of our logo I would be all for it. The major issue would be timely implementation. We use Ballotbin to hold our elections as its controlled by a third party and is therefore subject to less concern of rigging. A quick look at the software list referenced in the wikipedia site didn't immediately turn up a third party with the same capability. Instead its offered as software one may implement, and this could raise concerns on some peoples part. Additionally, if you accept that a choice to automate the release process and the use of peer reviews as being two different subjects, then there is no need to tie the choices together. Each choice stands on its own and can be determined separately without interference. Further, the peer review process is wholly defined by a collection of complaints and what-ifs and is not at the stage of being voted upon. The release process on the other hand has been posted for everyone to review, amendments / suggestions have been requested and considered. Is there some reason I'm not understanding that the two items must be determined together? At this point I can see no reason the release proposal would impede the development of a review proposal. However, the release process will suffer last minute delays if it waits for the review process to be defined. From bwalton at opencsw.org Fri Jul 1 18:17:17 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 01 Jul 2011 12:17:17 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> Message-ID: <1309536645-sup-4842@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Fri Jul 01 11:12:03 -0400 2011: Hi Rupert, > if you want to have a fair result even if you have similar > possibilities in the selection, one might consider the debian method > of voting, > http://en.wikipedia.org/wiki/Cloneproof_Schwartz_Sequential_Dropping. I agree that this would be useful if there were multiple similarly valid choices, but I don't see that as the case here. > otherwise opencsw will be called thunderbay, not lakehead :) Until I read the link, I thought you'd been doing some background research on me. I went to Lakehead University in Thunder Bay. It's a beautiful part of the country, if a bit cold. :) The drive across the top of Lake Superior in the fall rivals even the lovely scenery pics I saw from the technical camp in Norway. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Fri Jul 1 23:13:15 2011 From: rupert at opencsw.org (rupert THURNER) Date: Fri, 1 Jul 2011 23:13:15 +0200 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> Message-ID: On Fri, Jul 1, 2011 at 17:38, Jonathan Craig wrote: > On Fri, Jul 1, 2011 at 11:12 AM, rupert THURNER > wrote: > > > > > if you want to have a fair result even if you have similar possibilities > in > > the selection, one might consider the debian method of > > voting, > http://en.wikipedia.org/wiki/Cloneproof_Schwartz_Sequential_Dropping. > > otherwise opencsw will be called thunderbay, not lakehead :) > > rupert. > > That is an elegant solution when choosing amongst a group of like > items. If we were determining the color of our logo I would be all > for it. The major issue would be timely implementation. We use > Ballotbin to hold our elections as its controlled by a third party and > is therefore subject to less concern of rigging. A quick look at the > software list referenced in the wikipedia site didn't immediately turn > up a third party with the same capability. maybe http://modernballots.com/ would be an option ... i tried to create a test vote http://modernballots.com/_l3FJ7qj rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sat Jul 2 04:29:05 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 2 Jul 2011 03:29:05 +0100 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> Message-ID: I have received a suggestion for the following ballot wording: --snip-- * For the proposal as written * Against the proposal as written (may prefer amendments, see bio) * Abstain --snip-- I'm posting it here for reference, and to address the request. I would like to keep the ballot items as simple as possible: I accept, I do not accept, I abstain. I understand that the intent behind the suggestion is making sure that voters realize what are some of the implications (or non-implications) of certain options. I do not believe that such wording increases clarity. Putting parentheses, and the phrase referring to preferring amendments next to one option and not next to other options gives the impression that other options may imply no amendments. There is certain division of purpose between the writeup[1] and the ballot. The purpose of the writeup is to describe the higher level goal of the vote, and potential implications of accepting or rejecting the proposal. The purpose of the ballot is to only to present options and collect votes. Items on the ballot need to very clearly refer to options from the writeup. As far as writing up potential implications of proposal acceptance or rejection is concerned, there was enough time to work on the writeup. Both sides had time to write and revise their summaries, and I believe both received fair treatment. Therefore, ballot will be written as shown in version 3 on the wiki[1]. Maciej [1] http://wiki.opencsw.org/vote-release-process From maciej at opencsw.org Sat Jul 2 05:00:50 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 2 Jul 2011 04:00:50 +0100 Subject: [csw-maintainers] The automated release process vote has started Message-ID: All association members should have received their ballots. The vote timeline is: Opens: 2011-07-02 00:00:00 GMT Closes: 2011-07-08 23:59:00 GMT The vote is now open. References: - http://wiki.opencsw.org/automated-release-proposal - http://wiki.opencsw.org/vote-release-process Maciej From rupert at opencsw.org Sat Jul 2 14:19:31 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 2 Jul 2011 14:19:31 +0200 Subject: [csw-maintainers] [csw-pkgsubmissions] patching made simpler? In-Reply-To: <1294276587-sup-9714@pinkfloyd.chass.utoronto.ca> References: <1294276587-sup-9714@pinkfloyd.chass.utoronto.ca> Message-ID: hi, what is the best procedure to produce patches for subversion-1.7.0-alpha2. some of the old ones are not applying cleanly? i saw http://wiki.opencsw.org/using-git-to-produce-patches. rupert. On Thu, Jan 6, 2011 at 02:30, Ben Walton wrote: > Excerpts from rupert THURNER's message of Wed Jan 05 14:12:46 -0500 2011: > > Hi Rupert, > > I'm sorry this wasn't easier for you. > > > * try to build, not all patches applied > > * throw away the old patches, check in > > First, a recommendation: Never throw away patch/script/foo files from > an existing build until you've got a working replacement. I've kicked > myself a few times for doing this. :) > > In a situation like this, I'd see if I could get the patches to apply > manually using patch or other methods. > > > * "gmake extract" to get the source back > > * edit the files again like it should be > > Although it may not complain, makepatch would prefer to be called > after `gmake patch` to ensure all existing patches are applied. I > forget whether I enforced this with a constraint or not...If not, I > don't recall a the reason why I didn't. > > > * "gmake makepatch" > > * "gmake package", failed as there is a new file which would need > > patching as well. > > > * "gmake clean", "gmake extract" again > > * edit the file > > * "gmake makepatch" again > > Did you see your first patch applied in this process at all? If not, > you're working on a pre-patched set of files. > > > then i forgot to delete a line in a file which is already patched, and > > i thought about repeating above procedure again: > > 1. gmake extract > > applied patch 001 > > 2. gmake makepatch > > tried to apply patch 001 again > > which failed. > > This is likely due to creating a patch against the unpatched tree > above. If so, I should look at making sure makepatch cannot run > unless the patch target has already been called. You could, > potentially still have problems though... > > > then i gave up for the moment ... but this cannot be it, isn't it? > > should we switch to the whole source from subversion to git and it > > would be neater? then patches could be rebased instead of applied > > newly. > > I wouldn't object[1], but others may disagree. It's also a huge > undertaking. I know that many others are also using git quite a bit > lately too. > > The first major portion of this transition would require separating > GAR (the tool) from the build recipes. Git simply doesn't handle > (nicely) the idea of an external like subversion does. This would be > the final impetus to separate the two, most likely using Sebastian's > excellent mgar! > > I know that Maciej has been having both success and frustration using > the git-svn bridge as of late... > > Thanks > -Ben > > [1] It would actually make my day! > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonivart at opencsw.org Sat Jul 2 14:24:27 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 2 Jul 2011 14:24:27 +0200 Subject: [csw-maintainers] [csw-pkgsubmissions] patching made simpler? In-Reply-To: References: <1294276587-sup-9714@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Jul 2, 2011 at 2:19 PM, rupert THURNER wrote: > hi, > what is the best procedure to produce patches for subversion-1.7.0-alpha2. > some of the old ones are not applying cleanly? i > saw?http://wiki.opencsw.org/using-git-to-produce-patches. Take a look here: http://sourceforge.net/apps/trac/gar/wiki/GitMakepatch /peter From bwalton at opencsw.org Sat Jul 2 14:27:19 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 02 Jul 2011 08:27:19 -0400 Subject: [csw-maintainers] [csw-pkgsubmissions] patching made simpler? In-Reply-To: References: <1294276587-sup-9714@pinkfloyd.chass.utoronto.ca> Message-ID: <1309609306-sup-9568@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sat Jul 02 08:19:31 -0400 2011: Hi Rupert, > what is the best procedure to produce patches for > subversion-1.7.0-alpha2. some of the old ones are not applying > cleanly? i saw http://wiki.opencsw.org/using-git-to-produce-patches. There are a few options here, and the best choice depends on whether the existing patches are still valid but the source has changed enough that they don't apply or if you need entirely new patches. In the case where you need to modify/update existing patches and the patch step in GAR isn't doing it, I use: 1. Comment out patches that don't work from GAR recipe. 2. mgar spotless; mgar patch # this gets any working patches setup 3. cd work/solaris.../build-isa.../foo-1.2.3/; 4a. patch -p1 < ../../../../files/oldpatch.diff # maybe try different # fuzz levels here 4b. If patch still doesn't apply it, recreate the patch by making the required file edits. 5. cd - 6. mgar makepatch The last step should get you an updated patch. I think that wiki pages needs some updates to reflect that generating patches, using git, is now integrated into GAR (and isn't POC any more). Does this help? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Sat Jul 2 14:54:54 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 2 Jul 2011 14:54:54 +0200 Subject: [csw-maintainers] mercurial-1.9, where did it go? Message-ID: yesterday i built hg-1.9 and used csw-upload-package, but now i am wondering where it went? there was no mail, and i do not see a link on the opencsw website? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonivart at opencsw.org Sat Jul 2 15:01:06 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 2 Jul 2011 15:01:06 +0200 Subject: [csw-maintainers] mercurial-1.9, where did it go? In-Reply-To: References: Message-ID: On Sat, Jul 2, 2011 at 2:54 PM, rupert THURNER wrote: > yesterday i built hg-1.9 and used csw-upload-package, but now i am wondering > where it went? there was no mail, and i do not see a link on the opencsw > website? Something probably went wrong since it's not reached the mirrors yet. Do you have any output from the csw-upload-package session? Or try it again and post here. /peter From rupert at opencsw.org Sat Jul 2 15:05:11 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 2 Jul 2011 15:05:11 +0200 Subject: [csw-maintainers] mercurial-1.9, where did it go? In-Reply-To: References: Message-ID: oh, i see, this time my session did not break, and it says: $ csw-upload-pkg pkgs/01.Jul.2011/mercurial-1.9\,REV\=2011.07.01-SunOS5.9-*Processing 2 file(s). Please wait. Checking 1 package(s) against catalog unstable sparc SunOS5.9 Traceback (most recent call last): File "/opt/csw/bin/checkpkg", line 179, in main() File "/opt/csw/bin/checkpkg", line 140, in main exit_code, screen_report, tags_report = check_manager.Run() File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 803, in Run return super(CheckpkgManager2, self).Run() File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 232, in Run errors, messages, gar_lines = self.GetAllTags(self.sqo_pkgs_list) File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 760, in GetAllTags function(pkg_data, check_interface, logger=logger, messenger=messenger) File "/opt/csw/lib/python/csw/package_checks.py", line 648, in CheckDisallowedPaths for common_path in error_mgr.GetCommonPaths(arch): File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 396, in GetCommonPaths lines.extend(self._GetPathsForArch(arch)) File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 379, in _GetPathsForArch f = open(file_name, "r") IOError: [Errno 2] No such file or directory: '/opt/csw/lib/python/csw/../../etc/commondirs-sparc' Checking 1 package(s) against catalog unstable i386 SunOS5.9 Traceback (most recent call last): File "/opt/csw/bin/checkpkg", line 179, in main() File "/opt/csw/bin/checkpkg", line 140, in main exit_code, screen_report, tags_report = check_manager.Run() File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 803, in Run return super(CheckpkgManager2, self).Run() File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 232, in Run errors, messages, gar_lines = self.GetAllTags(self.sqo_pkgs_list) File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 760, in GetAllTags function(pkg_data, check_interface, logger=logger, messenger=messenger) File "/opt/csw/lib/python/csw/package_checks.py", line 648, in CheckDisallowedPaths for common_path in error_mgr.GetCommonPaths(arch): File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 396, in GetCommonPaths lines.extend(self._GetPathsForArch(arch)) File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 379, in _GetPathsForArch f = open(file_name, "r") IOError: [Errno 2] No such file or directory: '/opt/csw/lib/python/csw/../../etc/commondirs-i386' Checking 1 package(s) against catalog unstable sparc SunOS5.10 Traceback (most recent call last): File "/opt/csw/bin/checkpkg", line 179, in main() File "/opt/csw/bin/checkpkg", line 140, in main exit_code, screen_report, tags_report = check_manager.Run() File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 803, in Run return super(CheckpkgManager2, self).Run() File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 232, in Run errors, messages, gar_lines = self.GetAllTags(self.sqo_pkgs_list) File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 760, in GetAllTags function(pkg_data, check_interface, logger=logger, messenger=messenger) File "/opt/csw/lib/python/csw/package_checks.py", line 648, in CheckDisallowedPaths for common_path in error_mgr.GetCommonPaths(arch): File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 396, in GetCommonPaths lines.extend(self._GetPathsForArch(arch)) File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 379, in _GetPathsForArch f = open(file_name, "r") IOError: [Errno 2] No such file or directory: '/opt/csw/lib/python/csw/../../etc/commondirs-sparc' Checking 1 package(s) against catalog unstable i386 SunOS5.10 Traceback (most recent call last): File "/opt/csw/bin/checkpkg", line 179, in main() File "/opt/csw/bin/checkpkg", line 140, in main exit_code, screen_report, tags_report = check_manager.Run() File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 803, in Run return super(CheckpkgManager2, self).Run() File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 232, in Run errors, messages, gar_lines = self.GetAllTags(self.sqo_pkgs_list) File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 760, in GetAllTags function(pkg_data, check_interface, logger=logger, messenger=messenger) File "/opt/csw/lib/python/csw/package_checks.py", line 648, in CheckDisallowedPaths for common_path in error_mgr.GetCommonPaths(arch): File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 396, in GetCommonPaths lines.extend(self._GetPathsForArch(arch)) File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 379, in _GetPathsForArch f = open(file_name, "r") IOError: [Errno 2] No such file or directory: '/opt/csw/lib/python/csw/../../etc/commondirs-i386' Checks failed for catalogs: - sparc SunOS5.9 mercurial-1.9,REV=2011.07.01-SunOS5.9-sparc-CSW.pkg.gz To see errors, run: /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.9 --architecture sparc 1c96617426eb1c0035268a83f23195f8 - i386 SunOS5.9 mercurial-1.9,REV=2011.07.01-SunOS5.9-i386-CSW.pkg.gz To see errors, run: /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.9 --architecture i386 200831e0eef62b27bcd836bfd08b61af - sparc SunOS5.10 mercurial-1.9,REV=2011.07.01-SunOS5.9-sparc-CSW.pkg.gz To see errors, run: /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.10 --architecture sparc 1c96617426eb1c0035268a83f23195f8 - i386 SunOS5.10 mercurial-1.9,REV=2011.07.01-SunOS5.9-i386-CSW.pkg.gz To see errors, run: /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.10 --architecture i386 200831e0eef62b27bcd836bfd08b61af Packages have not been submitted to the unstable catalog. On Sat, Jul 2, 2011 at 15:01, Peter Bonivart wrote: > On Sat, Jul 2, 2011 at 2:54 PM, rupert THURNER wrote: > > yesterday i built hg-1.9 and used csw-upload-package, but now i am > wondering > > where it went? there was no mail, and i do not see a link on the opencsw > > website? > > Something probably went wrong since it's not reached the mirrors yet. > Do you have any output from the csw-upload-package session? Or try it > again and post here. > > /peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonivart at opencsw.org Sat Jul 2 15:09:25 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 2 Jul 2011 15:09:25 +0200 Subject: [csw-maintainers] mercurial-1.9, where did it go? In-Reply-To: References: Message-ID: On Sat, Jul 2, 2011 at 3:05 PM, rupert THURNER wrote: > oh, i see, this time my session did not break, and it says: > $ csw-upload-pkg > pkgs/01.Jul.2011/mercurial-1.9\,REV\=2011.07.01-SunOS5.9-*Processing 2 > file(s). I assume you're running csw-upload-pkg from /opt/csw/bin, it's been mentioned multiple times on the list that it's an older buggy version. Run it instead from the gar sources. I have this set up: alias csw-upload-pkg='~/opencsw/.buildsys/v2/bin/csw-upload-pkg' /peter From maciej at opencsw.org Sat Jul 2 15:09:12 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 2 Jul 2011 14:09:12 +0100 Subject: [csw-maintainers] mercurial-1.9, where did it go? In-Reply-To: References: Message-ID: 2011/7/2 rupert THURNER : > oh, i see, this time my session did not break, and it says: > $ csw-upload-pkg > pkgs/01.Jul.2011/mercurial-1.9\,REV\=2011.07.01-SunOS5.9-*Processing 2 > file(s). Please wait. > Checking 1 package(s) against catalog unstable sparc SunOS5.9 > Traceback (most recent call last): > ? File "/opt/csw/bin/checkpkg", line 179, in > ? ? main() > ? File "/opt/csw/bin/checkpkg", line 140, in main > ? ? exit_code, screen_report, tags_report = check_manager.Run() > ? File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 803, in Run > ? ? return super(CheckpkgManager2, self).Run() > ? File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 232, in Run > ? ? errors, messages, gar_lines = self.GetAllTags(self.sqo_pkgs_list) > ? File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 760, in GetAllTags > ? ? function(pkg_data, check_interface, logger=logger, messenger=messenger) > ? File "/opt/csw/lib/python/csw/package_checks.py", line 648, in > CheckDisallowedPaths > ? ? for common_path in error_mgr.GetCommonPaths(arch): > ? File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 396, in > GetCommonPaths > ? ? lines.extend(self._GetPathsForArch(arch)) > ? File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 379, in > _GetPathsForArch > ? ? f = open(file_name, "r") > IOError: [Errno 2] No such file or directory: > '/opt/csw/lib/python/csw/../../etc/commondirs-sparc' It's a known problem - /opt/csw/bin/csw-upload-pkg does not work currently; the one from gar sources does. The way to call it is to specify the path: /v2/bin/csw-upload-pkg ... Maciej From maciej at opencsw.org Sat Jul 2 15:25:57 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 2 Jul 2011 14:25:57 +0100 Subject: [csw-maintainers] mercurial-1.9, where did it go? In-Reply-To: References: Message-ID: Hi Ben, Could you make a new release of cswutils, including two commondirs- files from gar sources, putting them into /opt/csw/share/opencsw/gar? Here is the reference sources change: http://gar.svn.sourceforge.net/viewvc/gar?view=revision&revision=14964 Maciej From bwalton at opencsw.org Sat Jul 2 19:14:51 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 02 Jul 2011 13:14:51 -0400 Subject: [csw-maintainers] /etc/shells CAS for testing... Message-ID: <1309626700-sup-320@pinkfloyd.chass.utoronto.ca> Hi All, I put together a working but only lightly tested CAS to handle registration and de-registration of a shell from /etc/shells this morning. It'll be available[1] for testing shortly. This is in request to an RFE[2] on cswclassutils. I'll add the GAR integration after it's released. Feedback welcome. Thanks -Ben [1] http://buildfarm.opencsw.org/experimental.html#cswclassutils [2] https://www.opencsw.org/mantis/view.php?id=4063 -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Jul 2 19:41:01 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 02 Jul 2011 13:41:01 -0400 Subject: [csw-maintainers] mercurial-1.9, where did it go? In-Reply-To: References: Message-ID: <1309628423-sup-6893@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Sat Jul 02 09:25:57 -0400 2011: > Could you make a new release of cswutils, including two > commondirs- files from gar sources, putting them into > /opt/csw/share/opencsw/gar? Done. Just waiting for 'batched.' Unless anyone objects, we could push it onto login before that happens... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sat Jul 2 19:52:30 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 2 Jul 2011 18:52:30 +0100 Subject: [csw-maintainers] mercurial-1.9, where did it go? In-Reply-To: <1309628423-sup-6893@pinkfloyd.chass.utoronto.ca> References: <1309628423-sup-6893@pinkfloyd.chass.utoronto.ca> Message-ID: Since it's an internal (to the project) operation, we are OK to install this package without a public release. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Mon Jul 4 07:16:33 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 3 Jul 2011 22:16:33 -0700 Subject: [csw-maintainers] Why I'm retiring Message-ID: This message is both an explanation, and a warning, to maintainers past and present. Firstly, the current board has subverted fair democratic process. The way the latest voting process and ballot was manipulated, should be considered an outrage. At every step they have steered it on a narrow course, putting blinders up to obscure any way but their chosen course. Now they won't even allow wording on the ballot to indicate in even a minor way, "hey, there's something worth reading on the detailed write-up"?? There have been claims of "well we can vote on amendments to the proposal, after we pass the proposal". Given the way this vote has been run... and for that matter, the two preceeding ones as well!... it seems pretty clear that it would be anything but a fair vote. It's sad enough that they are doing this; but what is far sadder, is that no-one else seems to CARE. Whether or not you agree with the direction they are taking things technically, this abuse of power should greatly concern all maintainers. It *should*. Yet it does not seem to worry anyone but me. On top of the abuses of power, there are bad software development practices, such as "just grab from the svn tree, we dont want to be hassled with making proper releases of core utilities". As exemplified by the handling of gar in general, and re-emphasised recently with the mercurial/csw-upload-package issues. These attitudes seem to be entrenched, without hope of fixing. It used to be that CSW was a place that cared about technical quality, and user experience, above all other considerations. The priorities seem to now be "is it convenient to the maintainer, and is it easy to code in gar?" All else is secondary to those considerations. It seems the integrity of the organization has passed the point of being savable. Therefore, I hereby tender my resignation from opencsw. Philip Brown July 3, 2011 From dam at opencsw.org Mon Jul 4 11:54:56 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 4 Jul 2011 11:54:56 +0200 Subject: [csw-maintainers] New link for OpenCSW bootstrapping Message-ID: <406292C0-0A07-45DD-A884-F8FCE10645F9@opencsw.org> Hi William, I and Ihsan have set up some aliasing which allows for more easy-to-remember bootstrapping of Solaris: pkgadd -d http://get.opencsw.org/now The /now is necessary until bug 7061591 is resolved. William: How about adding this more prominently on the webpage? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Mon Jul 4 20:23:09 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 04 Jul 2011 14:23:09 -0400 Subject: [csw-maintainers] Why I'm retiring In-Reply-To: References: Message-ID: <1309803762-sup-4608@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Jul 04 01:16:33 -0400 2011: Hi Phil, > Therefore, I hereby tender my resignation from opencsw. Thanks for all the work you've done over the years. All the best in your future endeavours. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Jul 5 03:03:06 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 04 Jul 2011 21:03:06 -0400 Subject: [csw-maintainers] moving forward Message-ID: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> Hi All, With Phil gone, we're left without immediate mirror pushing until we sort out an interim solution. Ihsan, Maciej and I are tossing around a few ideas for how best to proceed, but if you have suggestions, please share them. This will be a big shift for us, but I'd like to make it as smooth as possible... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Jul 5 03:22:10 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 04 Jul 2011 21:22:10 -0400 Subject: [csw-maintainers] Code and package reviews In-Reply-To: References: Message-ID: <1309827865-sup-9084@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Mon Jun 13 06:05:41 -0400 2011: > Our aim is to build a culture in which peer review is one of the key > elements. There needs to be an environment which encourages peer > reviews and makes them easy. A thought I had on the train tonight is that review could begin with the maintainer detailing the following changes for a package release: 1. Version info. 2. Changed configure options (if any). 3. Overrides used and why. 4. New or removed patches and their function. 5. Filesystem layout changes and how they're gracefully handled. Having the maintainer lay this info out clearly to kickstart the discussion does a few things: 1. Makes the maintainer think about the changes in a package at a level higher than the build recipe. 2. Gives other maintainers insight into hot spots to review if they want to look in more depth. As an example, for the pending php5 release, I'd float a message like: --snip-- * This package changed from 5.2.9 to 5.3.6. * The GAR recipe was overhauled entirely to make it a single make file again. (Builds in a few hours instead of a day.) * Several build system patches were removed as they're no longer needed. * I created new patches to strip some ucb/lib references, fix non-portable grep use in the build system and ensure the 32-bit build for postgresql modules worked properly on sparc boxes. * I dropped the mbregex configure argument to fix a mis-fire in the build system, but this option, aside from breaking functionality instead of being a no-op is deprecated anyway. * I've updated several dependencies to match split out libraries. * I introduced a special module helper in GAR to enable easy, automatic module install/uninstall without a special CAS or postinstall script. * I santized the naming convention to be CSWphp5-foo instead of the older CSWphp5foo. * I use modulations in GAR to provide the cgi and ap2 modules. * I migrated configuration to /etc/opt/csw/php5. --snip-- This should provide a pretty good platform for comments, questions and critiques, I think. Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Jul 5 03:41:58 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 04 Jul 2011 21:41:58 -0400 Subject: [csw-maintainers] Assessing catalog quality In-Reply-To: <4E070436.7080407@opencsw.org> References: <4E070436.7080407@opencsw.org> Message-ID: <1309829862-sup-6372@pinkfloyd.chass.utoronto.ca> Excerpts from Trygve Laugst?l's message of Sun Jun 26 06:04:38 -0400 2011: > Number of overrides is one thing that comes to mind. While I agree that this is something to keep an eye on, there would need to be some sort of weighting factor used as judicious use of overrides can improve quality. Things to consider (possibly fictional error tags): CHECKPKG_OVERRIDE_CSWfoo += bad-path|/var/mypkg vs CHECKPKG_OVERRIDE_CSWfoo += bad-path The first overrides a single bad path but the second overrides every bad path...same number of overrides, but (possibly) very different package quality. Also, overriding /usr/local references in share/doc/foo/ isn't as bad as putting sparc binaries in an i386 package, etc... Weighting the tags would help, but that's a big job in and of itself...is it worthwhile for this? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From ihsan at opencsw.org Wed Jul 6 10:27:09 2011 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Wed, 06 Jul 2011 10:27:09 +0200 Subject: [csw-maintainers] HEADS UP: SMTP AUTH on mail.opencsw.org Message-ID: <4E141C5D.6090607@opencsw.org> Hi, If you are using SMTP AUTH on mail.opencsw.org, please make sure that your client is using the submission port 587 and not port 25. I will implement the new Postfix postscreen daemon soon and therefore I have to disable SMTP authentication on port 25. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Wed Jul 6 11:16:06 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 6 Jul 2011 11:16:06 +0200 Subject: [csw-maintainers] Technical Summercamp in Kiel 2011 Message-ID: <958B6EC9-5CE1-4B2E-BE39-2C85617D3EDD@opencsw.org> Hi folks, time is passing and I would like to invite everybody to add their available time slots to the doodle poll: http://doodle.com/ewfzuze75afweueq I removed the early dates within holidays as there were anyway nobody interested and added September. Please update soon as about 4 weeks in advance is needed for hotel booking etc. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Wed Jul 6 17:25:09 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 6 Jul 2011 17:25:09 +0200 Subject: [csw-maintainers] Use of testing* In-Reply-To: <1309892637-sup-4928@pinkfloyd.chass.utoronto.ca> References: <201106292024.p5TKOi1P008545@login.bo.opencsw.org> <1309892637-sup-4928@pinkfloyd.chass.utoronto.ca> Message-ID: <1219AD39-B607-4ACB-B6F6-70A762F31F72@opencsw.org> Hi, Am 05.07.2011 um 21:05 schrieb Ben Walton: > Excerpts from Peter Bonivart's message of Tue Jul 05 14:13:08 -0400 2011: >>> Darn... I looked in i386. This raises the question of the 2 testing >>> platforms: are they identical? Me think that no. >> >> You're right: > > These boxes aren't really "maintained" as much as the current and > unstable hosts. They're basically: > > I need this, so I install it. That doesn't get applied evenly. The > nature of their use doesn't lend itself to applying updates across the > board either, although we could definitely improve that. I suggest leave it that way for testing* and set up a new set of machines for project specific work, like project* similar to what we have. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Wed Jul 6 19:58:30 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 6 Jul 2011 18:58:30 +0100 Subject: [csw-maintainers] Use of testing* In-Reply-To: <1219AD39-B607-4ACB-B6F6-70A762F31F72@opencsw.org> References: <201106292024.p5TKOi1P008545@login.bo.opencsw.org> <1309892637-sup-4928@pinkfloyd.chass.utoronto.ca> <1219AD39-B607-4ACB-B6F6-70A762F31F72@opencsw.org> Message-ID: Em 06/07/2011 16:25, "Dagobert Michelsen" escreveu: > > Hi, > > Am 05.07.2011 um 21:05 schrieb Ben Walton: > > Excerpts from Peter Bonivart's message of Tue Jul 05 14:13:08 -0400 2011: > >>> Darn... I looked in i386. This raises the question of the 2 testing > >>> platforms: are they identical? Me think that no. > >> > >> You're right: > > > > These boxes aren't really "maintained" as much as the current and > > unstable hosts. They're basically: > > > > I need this, so I install it. That doesn't get applied evenly. The > > nature of their use doesn't lend itself to applying updates across the > > board either, although we could definitely improve that. > > I suggest leave it that way for testing* and set up a new set of machines > for project specific work, like project* similar to what we have. Checkpkg derives the catalog name (e.g.current or unstable) from the host name. It will be necessary to set CATALOG_NAME in system wide garrc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Fri Jul 8 18:09:10 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 08 Jul 2011 12:09:10 -0400 Subject: [csw-maintainers] vote reminder Message-ID: <1310141309-sup-2900@pinkfloyd.chass.utoronto.ca> Hi All, Just a reminder that if you haven't voted on the whether or not to adopt the new release process yet, it's ~4pm GMT, so there are only 8 hours remaining. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Jul 9 03:16:11 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 08 Jul 2011 21:16:11 -0400 Subject: [csw-maintainers] ideas In-Reply-To: References: <1309827347-sup-4348@pinkfloyd.chass.utoronto.ca> <1310062947-sup-1843@pinkfloyd.chass.utoronto.ca> <1310082708-sup-260@pinkfloyd.chass.utoronto.ca> Message-ID: <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Fri Jul 08 13:06:39 -0400 2011: Hi Maciej, > Another thought: perhaps it would not be that hard to implement a > POC of automatic catalog signing. For example: a machine in a > private network, controlled by a trusted person runs gpg agent with > a timeout in the order of 3 days to a week. A cron job running on > that machine pulls the catalog file, signs it and pushes it back for > the rest of the automation to pick it up. This is a good idea. I've been contemplating the design of such a system for a few days now. > At this point, there is a problem, that there is no verification > that the catalog pulled can be trusted. To fix that, we can I think something more 'on demand' is better suited here as that lends itself to better atomicity which will be important. I'm thinking something along the lines of: Just before a mirror push is about to happen, something opens a socket to a daemon and says "please sign catalog current/i386/5.9 having sha1 $sha1." The daemon would then grab the catalog from a preset location, ensure the sha1 matches and sign it. The signature is then returned over the socket and the caller is responsible for placing it appropriately with the files. Having things designed like this removes some possible security issues. 1. If the client can only request catalog signatures based on the tuple (catalog, arch, os release) and the daemon then goes and reads the file from a run-time specified or hard coded directory, the client cannot get 'just anything' signed. 2. Making the client responsible for placing the signature data means that, given 1, we don't need to protect the daemon with encryption, authentication, etc, as getting a catalog signature for a valid catalog is public data that will be available on the mirrors anyway. It also removes privilege from the daemon so that it needs read-only access to the data it will sign. If the client has enough access to manipulate the directory structure that the daemon will read, it can make the daemon sign a manipulated catalog. This level of compromise means things are already in bad shape though, so it shouldn't be worse than the risks we have today. The daemon would, as you suggest, need a timeout so that a human needs to re-initialize the agent storing the pass phrase periodically and it could tell the caller if it was unable to perform signatures. I'm willing to code the daemon. With such a signing daemon in place, we can have a cron job running as a dedicated catalog/mirror maintenance uid that has the access needed to place catalogs and signatures and push to the live mirror area...It will update catalogs, get them signed, etc. If the release proposal is accepted, this job could also be the one that moves things from unstable to current. As a side note, I'd like to mention to a wider audience than irc: I think our signatures should be detached instead of clear signed. These are nicer to work with all around. It would require coordinating a pkgutil update though. > introduce signing of individual .pkg and .pkg.gz files. The script > pulls not only the catalog file, but also the data files. It > verifies that all files referenced in the index (the catalog file) > are properly signed. If not, it complaints loudly. If yes, it > proceeds with signing. This can be a separate topic, but I think it is something to look at. The biggest hurdle here is ensuring that everyone gets a gpg key created for this purpose and that we distribute the public portions of the keys to client systems for verification. This could be tied into CSWcswpki that I've already laid groundwork for. > The signatures could be uploaded with csw-upload-pkg. Detached signatures for this would be best too. > I do not have a good idea where to store the signatures. I can > imagine an appendix to the catalog that lives in a parallel > directory, or a subdirectory of e.g. unstable/sparc/5.9 CSWcswpki should pull them down and install them in a private keyring. > There also is the (independent) problem of key revocation, presented > in detail by William in Dublin. Revoking a catalog signing key is different from revoking a maintainer signing key. If we revoke a catalog key, we can regenerate a new catalog with the new key. We may not be able to easily regenerate signatures for all packages if the need arises. If we sign packages individually, we may want to use a generic (but different than the catalog signer) key for this purpose too. > The two stage implementation outlined above gives us the advantage > that we can be back quickly and we can we have a plan how to improve > the security chain between an individual maintainer and the user. Agreed. Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sat Jul 9 12:47:42 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 9 Jul 2011 11:47:42 +0100 Subject: [csw-maintainers] ideas In-Reply-To: <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> References: <1309827347-sup-4348@pinkfloyd.chass.utoronto.ca> <1310062947-sup-1843@pinkfloyd.chass.utoronto.ca> <1310082708-sup-260@pinkfloyd.chass.utoronto.ca> <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> Message-ID: Em 09/07/2011 02:16, "Ben Walton" escreveu: > > Excerpts from Maciej Blizi?ski's message of Fri Jul 08 13:06:39 -0400 2011: > > Hi Maciej, > > > Another thought: perhaps it would not be that hard to implement a > > POC of automatic catalog signing. For example: a machine in a > > private network, controlled by a trusted person runs gpg agent with > > a timeout in the order of 3 days to a week. A cron job running on > > that machine pulls the catalog file, signs it and pushes it back for > > the rest of the automation to pick it up. > > This is a good idea. I've been contemplating the design of such a > system for a few days now. > > > At this point, there is a problem, that there is no verification > > that the catalog pulled can be trusted. To fix that, we can > > I think something more 'on demand' is better suited here as that lends > itself to better atomicity which will be important. I'm thinking > something along the lines of: > > Just before a mirror push is about to happen, something opens a socket > to a daemon and says "please sign catalog current/i386/5.9 having sha1 > $sha1." The daemon would then grab the catalog from a preset > location, ensure the sha1 matches and sign it. > > The signature is then returned over the socket and the caller is > responsible for placing it appropriately with the files. > > Having things designed like this removes some possible security > issues. > > 1. If the client can only request catalog signatures based on the > tuple (catalog, arch, os release) and the daemon then goes and > reads the file from a run-time specified or hard coded directory, > the client cannot get 'just anything' signed. > 2. Making the client responsible for placing the signature data means > that, given 1, we don't need to protect the daemon with encryption, > authentication, etc, as getting a catalog signature for a valid > catalog is public data that will be available on the mirrors > anyway. It also removes privilege from the daemon so that it needs > read-only access to the data it will sign. > > If the client has enough access to manipulate the directory structure > that the daemon will read, it can make the daemon sign a manipulated > catalog. This level of compromise means things are already in bad > shape though, so it shouldn't be worse than the risks we have today. > > The daemon would, as you suggest, need a timeout so that a human needs > to re-initialize the agent storing the pass phrase periodically and it > could tell the caller if it was unable to perform signatures. > > I'm willing to code the daemon. > > With such a signing daemon in place, we can have a cron job running as > a dedicated catalog/mirror maintenance uid that has the access needed > to place catalogs and signatures and push to the live mirror area...It > will update catalogs, get them signed, etc. If the release proposal > is accepted, this job could also be the one that moves things from > unstable to current. > > As a side note, I'd like to mention to a wider audience than irc: I > think our signatures should be detached instead of clear signed. > These are nicer to work with all around. It would require > coordinating a pkgutil update though. > > > introduce signing of individual .pkg and .pkg.gz files. The script > > pulls not only the catalog file, but also the data files. It > > verifies that all files referenced in the index (the catalog file) > > are properly signed. If not, it complaints loudly. If yes, it > > proceeds with signing. > > This can be a separate topic, but I think it is something to look at. > The biggest hurdle here is ensuring that everyone gets a gpg key > created for this purpose and that we distribute the public portions of > the keys to client systems for verification. This could be tied into > CSWcswpki that I've already laid groundwork for. > > > The signatures could be uploaded with csw-upload-pkg. > > Detached signatures for this would be best too. > > > I do not have a good idea where to store the signatures. I can > > imagine an appendix to the catalog that lives in a parallel > > directory, or a subdirectory of e.g. unstable/sparc/5.9 > > CSWcswpki should pull them down and install them in a private keyring. > > > There also is the (independent) problem of key revocation, presented > > in detail by William in Dublin. > > Revoking a catalog signing key is different from revoking a maintainer > signing key. If we revoke a catalog key, we can regenerate a new > catalog with the new key. We may not be able to easily regenerate > signatures for all packages if the need arises. If we sign packages > individually, we may want to use a generic (but different than the > catalog signer) key for this purpose too. > > > The two stage implementation outlined above gives us the advantage > > that we can be back quickly and we can we have a plan how to improve > > the security chain between an individual maintainer and the user. > > Agreed. > > Thoughts? Yes, here are some more. I like both ideas: the signing system initiating the connection (easier to secure it), and the buildfarm deciding when to sign. I have two alternative ideas. 1. The signing system listens, but the handling code is super simple, only sets a flag. Then the cron job notices it, and signing occurs. 2. The flag is set on buildfarm side, there is no listener on the signing side. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sat Jul 9 14:26:51 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 09 Jul 2011 08:26:51 -0400 Subject: [csw-maintainers] ideas In-Reply-To: References: <1309827347-sup-4348@pinkfloyd.chass.utoronto.ca> <1310062947-sup-1843@pinkfloyd.chass.utoronto.ca> <1310082708-sup-260@pinkfloyd.chass.utoronto.ca> <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> Message-ID: <1310213974-sup-5381@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Sat Jul 09 06:47:42 -0400 2011: Hi Maciej, > Yes, here are some more. I like both ideas: the signing system > initiating the connection (easier to secure it), and the buildfarm > deciding when to sign. I have two alternative ideas. > > 1. The signing system listens, but the handling code is super > simple, only sets a flag. Then the cron job notices it, and signing > occurs. > > 2. The flag is set on buildfarm side, there is no listener on the > signing side. If I'm reading this correctly, the signature would need to be deposited by the signing side, which means it needs +w on the catalog storage area and thus more lockdown. Did I miss your intent? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sat Jul 9 14:34:05 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 9 Jul 2011 13:34:05 +0100 Subject: [csw-maintainers] ideas In-Reply-To: <1310213974-sup-5381@pinkfloyd.chass.utoronto.ca> References: <1309827347-sup-4348@pinkfloyd.chass.utoronto.ca> <1310062947-sup-1843@pinkfloyd.chass.utoronto.ca> <1310082708-sup-260@pinkfloyd.chass.utoronto.ca> <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> <1310213974-sup-5381@pinkfloyd.chass.utoronto.ca> Message-ID: Em 09/07/2011 13:26, "Ben Walton" escreveu: > > Excerpts from Maciej Blizi?ski's message of Sat Jul 09 06:47:42 -0400 2011: > > Hi Maciej, > > > Yes, here are some more. I like both ideas: the signing system > > initiating the connection (easier to secure it), and the buildfarm > > deciding when to sign. I have two alternative ideas. > > > > 1. The signing system listens, but the handling code is super > > simple, only sets a flag. Then the cron job notices it, and signing > > occurs. > > > > 2. The flag is set on buildfarm side, there is no listener on the > > signing side. > > If I'm reading this correctly, the signature would need to be > deposited by the signing side, which means it needs +w on the catalog > storage area and thus more lockdown. Did I miss your intent? The signature could be pushed from the signing side to the buildfarm, e.g. using a RESTful interface. The +w would be on the buildfarm side. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sat Jul 9 14:59:01 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 09 Jul 2011 08:59:01 -0400 Subject: [csw-maintainers] vote results Message-ID: <1310216264-sup-8597@pinkfloyd.chass.utoronto.ca> Hi All, We'll get the vote writeup page updated later, but the vote is closed and the results are as follows: Accept: 14 Reject: 2 Abstain: 1 The proposal is therefore accepted and we can proceed with discussing the implementation details. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Jul 9 20:46:20 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 09 Jul 2011 14:46:20 -0400 Subject: [csw-maintainers] ideas In-Reply-To: References: <1309827347-sup-4348@pinkfloyd.chass.utoronto.ca> <1310062947-sup-1843@pinkfloyd.chass.utoronto.ca> <1310082708-sup-260@pinkfloyd.chass.utoronto.ca> <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> <1310213974-sup-5381@pinkfloyd.chass.utoronto.ca> Message-ID: <1310236678-sup-2941@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Sat Jul 09 08:34:05 -0400 2011: Hi Maciej, > The signature could be pushed from the signing side to the > buildfarm, e.g. using a RESTful interface. The +w would be on the > buildfarm side. Initially, I didn't think this was a good idea and I'm still not completely convinced, but my initial misgivings have given way to some further thinking about it. I think what I don't like is that the flow would be like: p1 -> touch trigger file -> d1 signs catalog -> sent to p2 via post The design I'd had in mind was: p1 -> signal daemon -> d1 signs catalog -> p1 via some protocol In the first mechanism, p1 and p2 could be the same thing, but it doesn't feel right to me. In the layout I was considering, it feels like a more closed loop. Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Jul 10 00:54:28 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 09 Jul 2011 18:54:28 -0400 Subject: [csw-maintainers] ideas In-Reply-To: <1310236678-sup-2941@pinkfloyd.chass.utoronto.ca> References: <1309827347-sup-4348@pinkfloyd.chass.utoronto.ca> <1310062947-sup-1843@pinkfloyd.chass.utoronto.ca> <1310082708-sup-260@pinkfloyd.chass.utoronto.ca> <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> <1310213974-sup-5381@pinkfloyd.chass.utoronto.ca> <1310236678-sup-2941@pinkfloyd.chass.utoronto.ca> Message-ID: <1310251904-sup-1461@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Sat Jul 09 14:46:20 -0400 2011: > p1 -> signal daemon -> d1 signs catalog -> p1 via some protocol Thinking further about this the request to sign the catalog should be http to a restful server. This would lend itself especially well to p1 doing the handling. Something like: GET /sign/unstable/i386/SUnOS5.9/ And the result is either a 200 response with the appropriate signature or some 4xx code, etc. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Jul 10 03:21:52 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 09 Jul 2011 21:21:52 -0400 Subject: [csw-maintainers] ideas In-Reply-To: <1310251904-sup-1461@pinkfloyd.chass.utoronto.ca> References: <1309827347-sup-4348@pinkfloyd.chass.utoronto.ca> <1310062947-sup-1843@pinkfloyd.chass.utoronto.ca> <1310082708-sup-260@pinkfloyd.chass.utoronto.ca> <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> <1310213974-sup-5381@pinkfloyd.chass.utoronto.ca> <1310236678-sup-2941@pinkfloyd.chass.utoronto.ca> <1310251904-sup-1461@pinkfloyd.chass.utoronto.ca> Message-ID: <1310260838-sup-5731@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Sat Jul 09 18:54:28 -0400 2011: > Excerpts from Ben Walton's message of Sat Jul 09 14:46:20 -0400 2011: > > > p1 -> signal daemon -> d1 signs catalog -> p1 via some protocol > > Thinking further about this the request to sign the catalog should be > http to a restful server. This would lend itself especially well to > p1 doing the handling. > > Something like: GET /sign/unstable/i386/SUnOS5.9/ > > And the result is either a 200 response with the appropriate signature > or some 4xx code, etc. I've implemented a basic proof of concept that can return both a clearsigned file and a detached signature for the same file based on the requested url... It would need lots of work on the gpg agent front still, but the basics are in place if this turns out to be worthwhile. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sun Jul 10 03:27:18 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 10 Jul 2011 02:27:18 +0100 Subject: [csw-maintainers] ideas In-Reply-To: <1310260838-sup-5731@pinkfloyd.chass.utoronto.ca> References: <1309827347-sup-4348@pinkfloyd.chass.utoronto.ca> <1310062947-sup-1843@pinkfloyd.chass.utoronto.ca> <1310082708-sup-260@pinkfloyd.chass.utoronto.ca> <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> <1310213974-sup-5381@pinkfloyd.chass.utoronto.ca> <1310236678-sup-2941@pinkfloyd.chass.utoronto.ca> <1310251904-sup-1461@pinkfloyd.chass.utoronto.ca> <1310260838-sup-5731@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/7/10 Ben Walton : > I've implemented a basic proof of concept that can return both a > clearsigned file and a detached signature for the same file based on > the requested url... Cool! > It would need lots of work on the gpg agent front still, but the > basics are in place if this turns out to be worthwhile. We have the keychain package which wraps gpg agent interaction. Maciej From bwalton at opencsw.org Sun Jul 10 03:33:42 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 09 Jul 2011 21:33:42 -0400 Subject: [csw-maintainers] ideas In-Reply-To: References: <1309827347-sup-4348@pinkfloyd.chass.utoronto.ca> <1310062947-sup-1843@pinkfloyd.chass.utoronto.ca> <1310082708-sup-260@pinkfloyd.chass.utoronto.ca> <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> <1310213974-sup-5381@pinkfloyd.chass.utoronto.ca> <1310236678-sup-2941@pinkfloyd.chass.utoronto.ca> <1310251904-sup-1461@pinkfloyd.chass.utoronto.ca> <1310260838-sup-5731@pinkfloyd.chass.utoronto.ca> Message-ID: <1310261500-sup-635@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Sat Jul 09 21:27:18 -0400 2011: > We have the keychain package which wraps gpg agent interaction. This might be useful for the daemon init, but the real fun will be setting the timeout on the keyphrase and then detecting a timeout and responding to the caller appropriately and alerting the admin to this fact. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sun Jul 10 04:18:55 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 10 Jul 2011 03:18:55 +0100 Subject: [csw-maintainers] ideas In-Reply-To: <1310261500-sup-635@pinkfloyd.chass.utoronto.ca> References: <1309827347-sup-4348@pinkfloyd.chass.utoronto.ca> <1310062947-sup-1843@pinkfloyd.chass.utoronto.ca> <1310082708-sup-260@pinkfloyd.chass.utoronto.ca> <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> <1310213974-sup-5381@pinkfloyd.chass.utoronto.ca> <1310236678-sup-2941@pinkfloyd.chass.utoronto.ca> <1310251904-sup-1461@pinkfloyd.chass.utoronto.ca> <1310260838-sup-5731@pinkfloyd.chass.utoronto.ca> <1310261500-sup-635@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/7/10 Ben Walton : > Excerpts from Maciej Blizi?ski's message of Sat Jul 09 21:27:18 -0400 2011: > >> We have the keychain package which wraps gpg agent interaction. > > This might be useful for the daemon init, but the real fun will be > setting the timeout on the keyphrase and then detecting a timeout and > responding to the caller appropriately and alerting the admin to this > fact. Detecting should be easy: a cron job tries to sign and verify a random string. If it fails, it sends an alert. How and to whom send the alert - any ideas? Maciej From bwalton at opencsw.org Sun Jul 10 14:34:12 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 10 Jul 2011 08:34:12 -0400 Subject: [csw-maintainers] ideas In-Reply-To: References: <1309827347-sup-4348@pinkfloyd.chass.utoronto.ca> <1310062947-sup-1843@pinkfloyd.chass.utoronto.ca> <1310082708-sup-260@pinkfloyd.chass.utoronto.ca> <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> <1310213974-sup-5381@pinkfloyd.chass.utoronto.ca> <1310236678-sup-2941@pinkfloyd.chass.utoronto.ca> <1310251904-sup-1461@pinkfloyd.chass.utoronto.ca> <1310260838-sup-5731@pinkfloyd.chass.utoronto.ca> <1310261500-sup-635@pinkfloyd.chass.utoronto.ca> Message-ID: <1310301014-sup-3902@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Sat Jul 09 22:18:55 -0400 2011: > Detecting should be easy: a cron job tries to sign and verify a > random string. If it fails, it sends an alert. But we shouldn't allow signing random data. The set of allowed inputs via the URL should specify the path (either the containing directory or fully qualified to the catalog file) using a $mirror_base setup to limit abuses. This means that the daemon itself must do the test prior to returning signed data. I was thinking of querying the agent to see what keys are unlocked. > How and to whom send the alert - any ideas? Email alerts and a useful error code via the restful interface. I think the mail alerts should go to Ihsan and $someone_else for redundancy. The daemon will be running on a zone in the www area, so Ihsan is the logical choice here, imo. (I'm working on the assumption that this is ok with Ihsan. If not, we need to come up with something else.) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jul 11 04:30:24 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 10 Jul 2011 22:30:24 -0400 Subject: [csw-maintainers] ideas In-Reply-To: <1310301014-sup-3902@pinkfloyd.chass.utoronto.ca> References: <1309827347-sup-4348@pinkfloyd.chass.utoronto.ca> <1310062947-sup-1843@pinkfloyd.chass.utoronto.ca> <1310082708-sup-260@pinkfloyd.chass.utoronto.ca> <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> <1310213974-sup-5381@pinkfloyd.chass.utoronto.ca> <1310236678-sup-2941@pinkfloyd.chass.utoronto.ca> <1310251904-sup-1461@pinkfloyd.chass.utoronto.ca> <1310260838-sup-5731@pinkfloyd.chass.utoronto.ca> <1310261500-sup-635@pinkfloyd.chass.utoronto.ca> <1310301014-sup-3902@pinkfloyd.chass.utoronto.c a> Message-ID: <1310351325-sup-3520@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Sun Jul 10 08:34:12 -0400 2011: > Excerpts from Maciej Blizi?ski's message of Sat Jul 09 22:18:55 -0400 2011: > > > Detecting should be easy: a cron job tries to sign and verify a > > random string. If it fails, it sends an alert. > > But we shouldn't allow signing random data. The set of allowed inputs > via the URL should specify the path (either the containing directory > or fully qualified to the catalog file) using a $mirror_base setup to > limit abuses. I misinterpreted what you meant here. Yes, a cron job on the private host running as the same uid as the daemon could sign some file and verify it. If this fails, mail would be sent. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Mon Jul 11 08:45:49 2011 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 11 Jul 2011 08:45:49 +0200 Subject: [csw-maintainers] mercurial 1.9, how long does it take? In-Reply-To: References: Message-ID: how long does it take that the new mercurial hg-1.9 package shows up on our website, e.g. http://www.opencsw.org/packages/mercurial ? rupert. From dam at opencsw.org Mon Jul 11 08:49:08 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 11 Jul 2011 08:49:08 +0200 Subject: [csw-maintainers] mercurial 1.9, how long does it take? In-Reply-To: References: Message-ID: Hi Rupert, Am 11.07.2011 um 08:45 schrieb rupert THURNER: > how long does it take that the new mercurial hg-1.9 package shows up > on our website, e.g. http://www.opencsw.org/packages/mercurial ? The process to sync up is currently reworked. It may very well take a week or so until the new process is in place. Don't wait on it. The pushing to unstable/ is not affected by the presentation on the webpage. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Mon Jul 11 09:05:38 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 11 Jul 2011 08:05:38 +0100 Subject: [csw-maintainers] mercurial 1.9, how long does it take? In-Reply-To: References: Message-ID: 2011/7/11 Dagobert Michelsen : > Hi Rupert, > > Am 11.07.2011 um 08:45 schrieb rupert THURNER: >> how long does it take that the new mercurial hg-1.9 package shows up >> on our website, e.g. http://www.opencsw.org/packages/mercurial ? > > The process to sync up is currently reworked. It may very well take a week > or so until the new process is in place. Don't wait on it. The pushing > to unstable/ is not affected by the presentation on the webpage. Yes, the website presents data from a separate database. It is possible to receive notifications about packages becoming available in two ways. One is the email sent to the maintainer, and the other is the RSS feed. You can look at the following address and subscribe to an RSS feed with updates to specific catalogs. http://buildfarm.opencsw.org/~bwalton/ It is a temporary location - I think it's a good time to find a permanent home for these feeds. Maciej From maciej at opencsw.org Mon Jul 11 11:55:36 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 11 Jul 2011 10:55:36 +0100 Subject: [csw-maintainers] ideas In-Reply-To: <1310351325-sup-3520@pinkfloyd.chass.utoronto.ca> References: <1309827347-sup-4348@pinkfloyd.chass.utoronto.ca> <1310062947-sup-1843@pinkfloyd.chass.utoronto.ca> <1310082708-sup-260@pinkfloyd.chass.utoronto.ca> <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> <1310213974-sup-5381@pinkfloyd.chass.utoronto.ca> <1310236678-sup-2941@pinkfloyd.chass.utoronto.ca> <1310251904-sup-1461@pinkfloyd.chass.utoronto.ca> <1310260838-sup-5731@pinkfloyd.chass.utoronto.ca> <1310261500-sup-635@pinkfloyd.chass.utoronto.ca> <1310301014-sup-3902@pinkfloyd.chass.utoronto.ca> <1310351325-sup-3520@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/7/11 Ben Walton : > I misinterpreted what you meant here. ?Yes, a cron job on the private > host running as the same uid as the daemon could sign some file and > verify it. ?If this fails, mail would be sent. Yup, that's the idea I had. Maciej From maciej at opencsw.org Mon Jul 11 17:20:18 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 11 Jul 2011 16:20:18 +0100 Subject: [csw-maintainers] pkg-get is now deprecated Message-ID: Hello maintainers, pkg-get[1], the original package installation tool, is now deprecated. The development is now focused on pkgutil[2]. The bootstrap area of the website[3] no longer shows the choice between pkg-get and pkgutil; the old URL is now a HTTP redirection to the pkgutil page. > curl -s -I http://www.opencsw.org/get-it/pkg-get/ | gegrep '(HTTP|Location)' HTTP/1.0 301 Moved Permanently Location: http://www.opencsw.org/get-it/pkgutil/ The old tool is still available from the package catalog, but it isn't supported and there are no guarantees that it will receive any updates in the future. Those who care about pkg-get are encouraged to look for a new maintainer for the package. Maciej [1] http://www.opencsw.org/packages/CSWpkgget/ [2] http://www.opencsw.org/packages/CSWpkgutil/ [3] http://www.opencsw.org/get-it/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Wed Jul 13 04:03:55 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 12 Jul 2011 22:03:55 -0400 Subject: [csw-maintainers] ideas In-Reply-To: References: <1309827347-sup-4348@pinkfloyd.chass.utoronto.ca> <1310062947-sup-1843@pinkfloyd.chass.utoronto.ca> <1310082708-sup-260@pinkfloyd.chass.utoronto.ca> <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> <1310213974-sup-5381@pinkfloyd.chass.utoronto.ca> <1310236678-sup-2941@pinkfloyd.chass.utoronto.ca> <1310251904-sup-1461@pinkfloyd.chass.utoronto.ca> <1310260838-sup-5731@pinkfloyd.chass.utoronto.ca> <1310261500-sup-635@pinkfloyd.chass.utoronto.ca> <1310301014-sup-3902@pinkfloyd.chass.utoronto.c a> <1310351325-sup-3520@pinkfloyd.chass.utoronto.ca> Message-ID: <1310522079-sup-5718@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Mon Jul 11 05:55:36 -0400 2011: > 2011/7/11 Ben Walton : > > I misinterpreted what you meant here. ?Yes, a cron job on the private > > host running as the same uid as the daemon could sign some file and > > verify it. ?If this fails, mail would be sent. > > Yup, that's the idea I had. Ok, here's what I've got: 1. A screen session gets started with two screens. One screen runs the signing daemon and the other a verification script. 2. The signing daemon creates a gpg-agent process and saves the info for use by other programs. It then runs the restful web agent. 3. The verification script tries to encrypt the signing daemon script every minute. If it fails, it will generate an alert and wait for operator intervention. 4. Operator intervention will take the form of a script that connects to the verification screen to accept the passphrase again. Until the passphrase times out, you can test the restful interface by hitting: http://unstable9x:9981/clearsign/current/i386/5.10 detachsign is also an option as is unstable in place of current. If this is run on a private host where all gpg files reside on host-local storage and the mirror tree is shared to this host so it can see the catalog files to sign, we should be in reasonable shape as long as we trust the nfs share... We'd need to make the signing agent sign catalog.update or catalog.new or something instead of catalog as presumably catalog would be the previously clear signed file. (I'm still happy to see clear signed catalogs go away in favour of a detached signature.) I still have some error handling and logging to take care of, but I think the proof of concept is in good shape now. Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Wed Jul 13 09:55:28 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 13 Jul 2011 08:55:28 +0100 Subject: [csw-maintainers] ideas In-Reply-To: <1310522079-sup-5718@pinkfloyd.chass.utoronto.ca> References: <1309827347-sup-4348@pinkfloyd.chass.utoronto.ca> <1310062947-sup-1843@pinkfloyd.chass.utoronto.ca> <1310082708-sup-260@pinkfloyd.chass.utoronto.ca> <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> <1310213974-sup-5381@pinkfloyd.chass.utoronto.ca> <1310236678-sup-2941@pinkfloyd.chass.utoronto.ca> <1310251904-sup-1461@pinkfloyd.chass.utoronto.ca> <1310260838-sup-5731@pinkfloyd.chass.utoronto.ca> <1310261500-sup-635@pinkfloyd.chass.utoronto.ca> <1310351325-sup-3520@pinkfloyd.chass.utoronto.ca> <1310522079-sup-5718@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/7/13 Ben Walton : > Excerpts from Maciej Blizi?ski's message of Mon Jul 11 05:55:36 -0400 2011: >> 2011/7/11 Ben Walton : >> > I misinterpreted what you meant here. ?Yes, a cron job on the private >> > host running as the same uid as the daemon could sign some file and >> > verify it. ?If this fails, mail would be sent. >> >> Yup, that's the idea I had. > > Ok, here's what I've got: > > 1. A screen session gets started with two screens. ?One screen runs > ? the signing daemon and the other a verification script. > 2. The signing daemon creates a gpg-agent process and saves the info > ? for use by other programs. ?It then runs the restful web agent. Sharing of the gpg-agent is on the user level, so being able to run as the same user on the same host lets you access the key, is that correct? > 3. The verification script tries to encrypt the signing daemon script > ? every minute. ?If it fails, it will generate an alert and wait for > ? operator intervention. How does the verification script reach the signing daemon? > 4. Operator intervention will take the form of a script that connects > ? to the verification screen to accept the passphrase again. > > Until the passphrase times out, you can test the restful interface by > hitting: > > http://unstable9x:9981/clearsign/current/i386/5.10 > > detachsign is also an option as is unstable in place of current. I need more instructions (URLs?). The best I could do so far, was: maciej at login [login]:~/src/opencsw-git/gar/v2 > curl -s http://unstable9x.bo.opencsw.org:9981/clearsign/current/i386/5.10 500 There was a problem processing the request. > If this is run on a private host where all gpg files reside on > host-local storage and the mirror tree is shared to this host so it > can see the catalog files to sign, we should be in reasonable shape as > long as we trust the nfs share... Looks good enough for now. In the target setup, the verification daemon will also verify signatures of individual packages, so trusting the NFS share will not be necessary. > We'd need to make the signing agent sign catalog.update or catalog.new > or something instead of catalog as presumably catalog would be the > previously clear signed file. ?(I'm still happy to see clear signed > catalogs go away in favour of a detached signature.) +1 > I still have some error handling and logging to take care of, but I > think the proof of concept is in good shape now. > > Thoughts? Sounds great! Can you show an example of the signing daemon usage? Maciej From maciej at opencsw.org Wed Jul 13 11:32:47 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 13 Jul 2011 10:32:47 +0100 Subject: [csw-maintainers] moving forward In-Reply-To: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/7/5 Ben Walton : > With Phil gone, we're left without immediate mirror pushing until we > sort out an interim solution. ?Ihsan, Maciej and I are tossing around > a few ideas for how best to proceed, but if you have suggestions, > please share them. > > This will be a big shift for us, but I'd like to make it as smooth as > possible... Here is a sketch of a plan: We will move the unstable as it is to unstable-poc and create a new empty unstable. We will then synchronize the new unstable from current. Packages uploaded from csw-upload-pkg will be for now periodically moved to current by a designated person until automation arrives. We will investigate the old scripts that used to drive the website updates. We will work on an automatic website and mantis integration solution. If using the old scripts is too hard, we will allow mantis to desynchronize, but we will keep on releasing packages to unstable and current. It would be good to avoid re-uploading all the packages to unstable. I can use the existing catalog integration tool to do that. To recap: Before: current unstable ? current stable After: current ? testing testing (a snapshot of current, will receive manual updates for now) unstable (generated from the db, driven by csw-upload-pkg) stable An alternative after: current ? unstable unstable (generated from the db, driven by csw-upload-pkg) stable Thoughts? Maciej From maciej at opencsw.org Wed Jul 13 23:22:59 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 13 Jul 2011 22:22:59 +0100 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> References: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/6/20 Ben Walton : > Excerpts from rupert THURNER's message of Sun Jun 19 09:00:55 -0400 2011: > > Hi Rupert, > >> as an experiment, i tried to convert the subversion gar repository to git >> and mercurial: >> ?* http://code.google.com/p/gar/ (hg) >> ?* https://github.com/opencsw/gar (git) > > I like this! :) ?I'm not keen on mercurial given my exposure to it, > but anything distributed would be a step up. I agree. I did check out gar from github today and I would love to work on git-controlled gar sources. Does anyone have a good idea how will we push the code updates back to subversion? Or can we migrate off of subversion to github (or git in general) and stop relying on gar being checked into subversion together with the build descriptions? Maciej From bwalton at opencsw.org Thu Jul 14 03:15:38 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 13 Jul 2011 21:15:38 -0400 Subject: [csw-maintainers] moving forward In-Reply-To: References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> Message-ID: <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Wed Jul 13 05:32:47 -0400 2011: > We will move the unstable as it is to unstable-poc and create a new > empty unstable. We will then synchronize the new unstable from > current. Packages uploaded from csw-upload-pkg will be for now > periodically moved to current by a designated person until > automation arrives. We will investigate the old scripts that used to > drive the website updates. We will work on an automatic website and > mantis integration solution. If using the old scripts is too hard, > we will allow mantis to desynchronize, but we will keep on releasing > packages to unstable and current. This works for me. There is still some work to do to automate the flow and we can't sit on packages until everything is ready. Would anyone like the job of moving packages from unstable to current for the time being? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Jul 14 03:28:19 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 13 Jul 2011 21:28:19 -0400 Subject: [csw-maintainers] ideas In-Reply-To: References: <1309827347-sup-4348@pinkfloyd.chass.utoronto.ca> <1310062947-sup-1843@pinkfloyd.chass.utoronto.ca> <1310082708-sup-260@pinkfloyd.chass.utoronto.ca> <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> <1310213974-sup-5381@pinkfloyd.chass.utoronto.ca> <1310236678-sup-2941@pinkfloyd.chass.utoronto.ca> <1310251904-sup-1461@pinkfloyd.chass.utoronto.ca> <1310260838-sup-5731@pinkfloyd.chass.utoronto.ca> <1310261500-sup-635@pinkfloyd.chass.utoronto.ca> <1310351325-sup-3520@pinkfloyd.chass.utoronto.c a> <1310522079-sup-5718@pinkfloyd.chass.utoronto.ca> Message-ID: <1310606416-sup-3040@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Wed Jul 13 03:55:28 -0400 2011: > Sharing of the gpg-agent is on the user level, so being able to run as > the same user on the same host lets you access the key, is that > correct? Yes. And root, of course. > How does the verification script reach the signing daemon? The initialization uses --write-env-file and the verification daemon sources this. It's not keychain driven, but it's the same principle. > I need more instructions (URLs?). The best I could do so far, was: > > maciej at login [login]:~/src/opencsw-git/gar/v2 > curl -s > http://unstable9x.bo.opencsw.org:9981/clearsign/current/i386/5.10 > 500 There was a problem processing the request. This means the agent had timed out. > Looks good enough for now. In the target setup, the verification > daemon will also verify signatures of individual packages, so > trusting the NFS share will not be necessary. Adding individual package signatures will be a lot more work. Each maintainer will need a key for which we'd need to collect the public half, etc. I think this is definitely worthwhile, but lets leave that until we have basic package flow in place. > > We'd need to make the signing agent sign catalog.update or > > catalog.new or something instead of catalog as presumably catalog > > would be the previously clear signed file. ?(I'm still happy to > > see clear signed catalogs go away in favour of a detached > > signature.) > > +1 After discussing this with Peter in irc a bit today, I think we should stick with clear signing for now. Changing this would break pkg-get and although we're not tied to that any more, there's no need break it right out of the gate. Peter is thinking of some json-based catalog stuff anyway, so maybe when he's ready to tackle that problem, we can choose a new name for the file, continue generating legacy catalogs and then do the new catalog file plus a detached signature for it. > Sounds great! Can you show an example of the signing daemon usage? This should be as simple as a curl call from the script that is going to push a mirror update. for catalog in unstable current; do for arch in i386 sparc; do for rel in 5.9 5.10 5.11; do curl -s http://cswsign:9981/clearsign/$catalog/$arch/$rel \ > catalog.updated && mv catalog.updated catalog done done done Dago has set up a private zone on the farm to run the signing agent. It's called cswsign as per the example above. I'm continuing development on there as soon as I hit send on this. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Jul 14 09:53:41 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 14 Jul 2011 08:53:41 +0100 Subject: [csw-maintainers] moving forward In-Reply-To: <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/7/14 Ben Walton : > This works for me. ?There is still some work to do to automate the > flow and we can't sit on packages until everything is ready. ?Would > anyone like the job of moving packages from unstable to current for > the time being? Moving packages from unstable to current in the database can be automatic. How about the following idea: - maintainers push packages to unstable - at time t, a script looks at the diff between unstable and current; it prepares a change set to be applied to current; it sends the change set to a mailing list with information: "At time t + 12h the following changes will be applied: ..." - people in the project have 12h to react if the change set reads "destroy the world" - if no action is taken until t + 12h, the change set is applied and new current is pushed Maciej From maciej at opencsw.org Thu Jul 14 10:10:25 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 14 Jul 2011 09:10:25 +0100 Subject: [csw-maintainers] moving forward In-Reply-To: References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> Message-ID: Heads up, I'm working on opencsw-future. From maciej at opencsw.org Thu Jul 14 10:44:55 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 14 Jul 2011 09:44:55 +0100 Subject: [csw-maintainers] moving forward In-Reply-To: References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> Message-ID: Here is the changeset to be applied to dublin (my idea is to have 'current' become a symlink to dublin). http://buildfarm.opencsw.org/~maciej/to_dublin.sh Changes I know about or I noticed: - updated libffi - Python 2.6 with ctypes support on i386 - Python 2.7 - Python 3.1 - MySQL libraries are split to a separate package and placed in /opt/csw/lib - added libslp - added opencsw_policy - removed squirrelmail - removed drupal - removed mediawiki - removed zope - lots and lots of library splits - lots and lots of updated packages - probably other significant updates I did not notice Overall, I do not see anything drastic here. I think we could do the unstable?{dublin,current} integration. Did anyone make a test, e.g. install a box from current, then switch to unstable and upgrade all packages? If not, could anyone do that? Maciej From maciej at opencsw.org Thu Jul 14 12:36:21 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 14 Jul 2011 11:36:21 +0100 Subject: [csw-maintainers] moving forward In-Reply-To: References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/7/14 Maciej Blizi?ski : > Heads up, I'm working on opencsw-future. I made changes to the way opencsw-future is handled. Dago, can you look at the logs from the 12:00 cron job? If there are any errors encounters, I'd like to see them. Thanks! Maciej From dam at opencsw.org Thu Jul 14 13:44:16 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jul 2011 13:44:16 +0200 Subject: [csw-maintainers] moving forward In-Reply-To: References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> Message-ID: Hi, Am 14.07.2011 um 10:44 schrieb Maciej Blizi?ski: > Here is the changeset to be applied to dublin (my idea is to have > 'current' become a symlink to dublin). > > http://buildfarm.opencsw.org/~maciej/to_dublin.sh > > Changes I know about or I noticed: > > - updated libffi > - Python 2.6 with ctypes support on i386 > - Python 2.7 > - Python 3.1 > - MySQL libraries are split to a separate package and placed in /opt/csw/lib > - added libslp > - added opencsw_policy > - removed squirrelmail > - removed drupal > - removed mediawiki > - removed zope Why are these removed? Shouldn't for "Dublin" much more packages be moved to "unmaintained"? > - lots and lots of library splits > - lots and lots of updated packages > - probably other significant updates I did not notice > > Overall, I do not see anything drastic here. I think we could do the > unstable?{dublin,current} integration. > > Did anyone make a test, e.g. install a box from current, then switch > to unstable and upgrade all packages? If not, could anyone do that? Is this from here? http://buildfarm.opencsw.org/opencsw-future/ Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Thu Jul 14 13:45:44 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jul 2011 13:45:44 +0200 Subject: [csw-maintainers] moving forward In-Reply-To: References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> Message-ID: <055C3DE3-40C4-43EF-AEF9-966A192DA083@opencsw.org> Hi Maciej, Am 14.07.2011 um 09:53 schrieb Maciej Blizi?ski: > 2011/7/14 Ben Walton : >> This works for me. There is still some work to do to automate the >> flow and we can't sit on packages until everything is ready. Would >> anyone like the job of moving packages from unstable to current for >> the time being? > > Moving packages from unstable to current in the database can be > automatic. How about the following idea: > > - maintainers push packages to unstable > - at time t, a script looks at the diff between unstable and current; > it prepares a change set to be applied to current; it sends the change > set to a mailing list with information: "At time t + 12h the following > changes will be applied: ..." > - people in the project have 12h to react if the change set reads > "destroy the world" > - if no action is taken until t + 12h, the change set is applied and > new current is pushed Ok. And later on packages with open bugs will be blocked from propagation, right? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Thu Jul 14 14:47:57 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 14 Jul 2011 13:47:57 +0100 Subject: [csw-maintainers] moving forward In-Reply-To: References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/7/14 Dagobert Michelsen : > Hi, > > Am 14.07.2011 um 10:44 schrieb Maciej Blizi?ski: >> Here is the changeset to be applied to dublin (my idea is to have >> 'current' become a symlink to dublin). >> >> http://buildfarm.opencsw.org/~maciej/to_dublin.sh >> >> Changes I know about or I noticed: >> >> - updated libffi >> - Python 2.6 with ctypes support on i386 >> - Python 2.7 >> - Python 3.1 >> - MySQL libraries are split to a separate package and placed in /opt/csw/lib >> - added libslp >> - added opencsw_policy >> - removed squirrelmail >> - removed drupal >> - removed mediawiki >> - removed zope > > Why are these removed? I am guilty of removing them. Reasons: - they depend on apache2c - they have no maintainers - they are useless - we want apache2c gone > Shouldn't for "Dublin" much more packages be > moved to "unmaintained"? Yes, but we haven't implemented tiers yet. I only removed packages that were getting in our way. >> - lots and lots of library splits >> - lots and lots of updated packages >> - probably other significant updates I did not notice >> >> Overall, I do not see anything drastic here. ?I think we could do the >> unstable?{dublin,current} integration. >> >> Did anyone make a test, e.g. install a box from current, then switch >> to unstable and upgrade all packages? ?If not, could anyone do that? > > Is this from here? > ?http://buildfarm.opencsw.org/opencsw-future/ Yes, from here. It will also be synced with the master mirror soon, when we stamp out cron job failures. Maciej From maciej at opencsw.org Thu Jul 14 14:51:59 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 14 Jul 2011 13:51:59 +0100 Subject: [csw-maintainers] moving forward In-Reply-To: <055C3DE3-40C4-43EF-AEF9-966A192DA083@opencsw.org> References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> <055C3DE3-40C4-43EF-AEF9-966A192DA083@opencsw.org> Message-ID: 2011/7/14 Dagobert Michelsen : > Hi Maciej, > > Am 14.07.2011 um 09:53 schrieb Maciej Blizi?ski: >> 2011/7/14 Ben Walton : >>> This works for me. ?There is still some work to do to automate the >>> flow and we can't sit on packages until everything is ready. ?Would >>> anyone like the job of moving packages from unstable to current for >>> the time being? >> >> Moving packages from unstable to current in the database can be >> automatic. ?How about the following idea: >> >> - maintainers push packages to unstable >> - at time t, a script looks at the diff between unstable and current; >> it prepares a change set to be applied to current; it sends the change >> set to a mailing list with information: "At time t + 12h the following >> changes will be applied: ..." >> - people in the project have 12h to react if the change set reads >> "destroy the world" >> - if no action is taken until t + 12h, the change set is applied and >> new current is pushed > > Ok. And later on packages with open bugs will be blocked from propagation, right? Yes, but there are some issues. This hasn't been implemented yet, and there's a bit of yak shaving to be done: - write the integration using mantis XML RPC - mantis XML RPC requires upgrading mantis - upgrading mantis requires porting our patches - porting our patches requires profiling of mantis So for now, I thought of unconditional migration with monitoring and optional human intervention. Maciej From maciej at opencsw.org Thu Jul 14 17:01:39 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 14 Jul 2011 16:01:39 +0100 Subject: [csw-maintainers] moving forward In-Reply-To: References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/7/14 Maciej Blizi?ski : >> Is this from here? >> ?http://buildfarm.opencsw.org/opencsw-future/ > > Yes, from here. It will also be synced with the master mirror soon, > when we stamp out cron job failures. Updates: There was a number of stuck cron jobs on the web zone. Dago cleaned some of them, I cleaned out the rest. There were 3 kinds of stuck cron jobs: - experimental update - uwatch - update-package-version-database I did not attempt to debug why the jobs were stuck. Generation of dublin now works; rsync to opencsw-future on the master mirror is now underway. I talked to Ben on IRC. He'll update his catalog signing program to support also opencsw-future. I'll then integrate it into the catalog generation, and we'll have signed, autogenerated catalogs in opencsw-future. After a period testing (length to be discussed), we'll flip the switch and go live. Maciej From maciej at opencsw.org Thu Jul 14 17:34:38 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 14 Jul 2011 16:34:38 +0100 Subject: [csw-maintainers] moving forward In-Reply-To: References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> Message-ID: Should we make an announcement on the users list about the current state of affairs? E.g. information that there's a pause in package releases until we put the new release mechanism in place. Maciej From pfelecan at opencsw.org Thu Jul 14 18:17:50 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 14 Jul 2011 18:17:50 +0200 Subject: [csw-maintainers] moving forward In-Reply-To: ("Maciej =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu, 14 Jul 2011 16:34:38 +0100") References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> Message-ID: Maciej Blizi?ski writes: > Should we make an announcement on the users list about the current > state of affairs? E.g. information that there's a pause in package > releases until we put the new release mechanism in place. That would be nice toward the user base. We lost enough traction in the last year and maybe a better communication is welcome. -- Peter From ihsan at opencsw.org Fri Jul 15 08:11:24 2011 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Fri, 15 Jul 2011 08:11:24 +0200 Subject: [csw-maintainers] moving forward In-Reply-To: References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> Message-ID: <4E1FDA0C.5060305@opencsw.org> Am 14.07.2011 18:17, schrieb Peter FELECAN: >> Should we make an announcement on the users list about the current >> state of affairs? E.g. information that there's a pause in package >> releases until we put the new release mechanism in place. > > That would be nice toward the user base. We lost enough traction in the > last year and maybe a better communication is welcome. I fully agree. We have our website and the announce/users mailing list, which we could more often to communicate with our user base. Being more open and communicative attracts definitely more people. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Fri Jul 15 09:29:19 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 15 Jul 2011 08:29:19 +0100 Subject: [csw-maintainers] moving forward In-Reply-To: References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/7/14 Maciej Blizi?ski : > Generation of dublin now works; rsync to opencsw-future on the master > mirror is now underway. Updates: I did more testing of the catalog generation, and fixed a bug which was causing the 5.11 catalog to be not generated. The bug caused the big catalog update emails everyone got last night and this morning. I'm currently running the integration from unstable to dublin. You will probably get the email notification later today, about the updated packages. Maciej From bwalton at opencsw.org Fri Jul 15 14:52:15 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 15 Jul 2011 08:52:15 -0400 Subject: [csw-maintainers] moving forward In-Reply-To: References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> Message-ID: <1310734278-sup-9274@pinkfloyd.chass.utoronto.ca> Update: The passphrase handling of the key via pinentry is my sticking point right now. I'm looking at an alternative gpg-agent passphrase handling tool which should make this easier. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Fri Jul 15 16:08:04 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 15 Jul 2011 15:08:04 +0100 Subject: [csw-maintainers] moving forward In-Reply-To: <1310734278-sup-9274@pinkfloyd.chass.utoronto.ca> References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> <1310734278-sup-9274@pinkfloyd.chass.utoronto.ca> Message-ID: I'm going for 2 weeks vacation this Sunday. I will have no access to shell, so if something breaks, you're on your own until the 2nd of August. I will try to peek at email and might offer advice. Before I go, we could meet online for a walkthrough over the codebase, to make potential debugging easier. A couple of notes: - if the catalog generation fails, Dago receives an email with the error message - to implement signing, you need to modify the opencsw-future-update script[1] which runs on the web zone (see crontab -l) Off the top of my head, here are things to do in the near future: - implement better error reporting for the catalog generation script; it could be as simple as capturing stdout and sending it somewhere if the return code != 0 - remove the snapshots and snapshot generating scripts; we once thought of snapshots, but will have named releases instead - implement migration from unstable to dublin, however lame I will not be online this evening. I'll pop up on Saturday (tomorrow) morning (IST) to see if there any loose ends to tie. I'll be out Saturday evening, and gone on Sunday. You can expect me back on the 2nd of August in the evening IST. Maciej [1] http://opencsw.svn.sourceforge.net/viewvc/opencsw/buildfarm/bin/opencsw-future-update?view=markup From maciej at opencsw.org Sun Jul 17 02:20:10 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 17 Jul 2011 01:20:10 +0100 Subject: [csw-maintainers] Forum Software In-Reply-To: <20110525164348.GG11519@sebastiankayser.de> References: <4DDD0E24.6010907@opencsw.org> <20110525164348.GG11519@sebastiankayser.de> Message-ID: 2011/5/25 Sebastian Kayser : > During winter camp Maciej mentioned Vanilla which seems loosely modelled > after Stackoverflow [1,2]. From looking at it briefly, it feels more > like the 21th century than traditional forums. That's only the user side > though, not the admin perspective. I do like Vanilla, but I also recognize that phpBB is the leading, and the most familiar forum engine. If we wanted ensure a low entry bar on the user forum, phpBB would be the best choice. Vanilla does feel more modern though. Overall, I personally think that both are acceptable, and that it's better to have one installed relatively soon than have long debates over which one is better. Ihsan, can you pick the one that you believe is best and make a test deployment? If you don't have the time to do it yourself, could you pass credentials and access instructions to someone else? Maciej From rupert at opencsw.org Sun Jul 17 07:48:24 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 17 Jul 2011 07:48:24 +0200 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: References: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/7/13 Maciej Blizi?ski : > 2011/6/20 Ben Walton : >> Excerpts from rupert THURNER's message of Sun Jun 19 09:00:55 -0400 2011: >> >> Hi Rupert, >> >>> as an experiment, i tried to convert the subversion gar repository to git >>> and mercurial: >>> ?* http://code.google.com/p/gar/ (hg) >>> ?* https://github.com/opencsw/gar (git) >> >> I like this! :) ?I'm not keen on mercurial given my exposure to it, >> but anything distributed would be a step up. > > I agree. ?I did check out gar from github today and I would love to > work on git-controlled gar sources. ?Does anyone have a good idea how > will we push the code updates back to subversion? ?Or can we migrate > off of subversion to github (or git in general) and stop relying on > gar being checked into subversion together with the build > descriptions? if one clones the svn repository, attach it to the git repo, then synchronization would be possible i gess. checkout (once): git svn clone https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2 gar cd gar git remote add origin git at github.com:opencsw/gar.git do changes and commit (regular) : git push git svn dcommit rupert. From maciej at opencsw.org Sun Jul 17 10:51:35 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 17 Jul 2011 09:51:35 +0100 Subject: [csw-maintainers] moving forward In-Reply-To: References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> <1310734278-sup-9274@pinkfloyd.chass.utoronto.ca> Message-ID: [+buildfarm] Since from now on we're no longer releasing to current, but to unstable instead, we should no longer build on the current{9,10}{s,x} hosts. I think it's best to put some signpost in place along the lines of "this isn't the build host you're looking for". Maciej From rupert at opencsw.org Sun Jul 17 10:59:56 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 17 Jul 2011 10:59:56 +0200 Subject: [csw-maintainers] moving forward In-Reply-To: References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> <1310734278-sup-9274@pinkfloyd.chass.utoronto.ca> Message-ID: $ gmake platforms ssh -t current9s .... 2011/7/17 Maciej Blizi?ski > [+buildfarm] > > Since from now on we're no longer releasing to current, but to > unstable instead, we should no longer build on the current{9,10}{s,x} > hosts. I think it's best to put some signpost in place along the > lines of "this isn't the build host you're looking for". > > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Sun Jul 17 11:12:15 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 17 Jul 2011 11:12:15 +0200 Subject: [csw-maintainers] moving forward In-Reply-To: References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> <1310734278-sup-9274@pinkfloyd.chass.utoronto.ca> Message-ID: haha ... unstable seems to well deserve its name :) == Testing test/testcases/simple.response == scotch.ics.uci.edu

More to come!

Apache httpd 2.0 manual

Trust our CA!

Powered by Apache!

== Testing test/testcases/chunked-empty.response == == Testing test/testcases/chunked.response == this is 1 test. i am a test.this is a test. == Testing test/testcases/chunked-trailers.response == this is 1 test. i am a test.this is a test. Trailer-Test: f == Testing test/testcases/deflate.response == Test of gzip Content-Encoding

This is a test

This file was created with mod_deflate on the server side.

curl -i --output gzip.response -H "Accept-Encoding: gzip"
http://localhost:8080/1.html
Apache
== Running test_all == FFFFFFF.......... There were 7 failures: 1) test_serf_connection_request_create: test/test_context.c:166: expected <0> but was <124> 2) test_serf_connection_priority_request_create: test/test_context.c:265: expected <0> but was <124> 3) test_serf_closed_connection: test/test_context.c:404: expected <0> but was <124> 4) test_serf_setup_proxy: test/test_context.c:505: expected <0> but was <124> 5) test_keepalive_limit_one_by_one: test/test_context.c:656: expected <0> but was <124> 6) test_keepalive_limit_one_by_one_and_burst: test/test_context.c:810: expected <0> but was <124> 7) test_serf_progress_callback: test/test_context.c:932: expected <0> but was <124> !!!FAILURES!!! Runs: 17 Passes: 10 Fails: 7 gmake[2]: *** [check] Error 1 gmake[2]: Leaving directory `/home/rupert/mgar/pkg/libserf/trunk/work/solaris9-sparc/build-isa-sparcv8/serf-1.0.0' gmake[1]: *** [test-work/solaris9-sparc/build-isa-sparcv8/serf-1.0.0/Makefile] Error 2 gmake[1]: Leaving directory `/home/rupert/mgar/pkg/libserf/trunk' gmake: *** [merge-isa-sparcv8] Error 2 On Sun, Jul 17, 2011 at 10:59, rupert THURNER wrote: > $ gmake platforms > ssh -t current9s .... > > > 2011/7/17 Maciej Blizi?ski > >> [+buildfarm] >> >> Since from now on we're no longer releasing to current, but to >> unstable instead, we should no longer build on the current{9,10}{s,x} >> hosts. I think it's best to put some signpost in place along the >> lines of "this isn't the build host you're looking for". >> >> Maciej >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Sun Jul 17 13:15:53 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 17 Jul 2011 13:15:53 +0200 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: References: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Jul 17, 2011 at 07:48, rupert THURNER wrote: > 2011/7/13 Maciej Blizi?ski : > > 2011/6/20 Ben Walton : > >> Excerpts from rupert THURNER's message of Sun Jun 19 09:00:55 -0400 > 2011: > >> > >> Hi Rupert, > >> > >>> as an experiment, i tried to convert the subversion gar repository to > git > >>> and mercurial: > >>> * http://code.google.com/p/gar/ (hg) > >>> * https://github.com/opencsw/gar (git) > >> > >> I like this! :) I'm not keen on mercurial given my exposure to it, > >> but anything distributed would be a step up. > > > > I agree. I did check out gar from github today and I would love to > > work on git-controlled gar sources. Does anyone have a good idea how > > will we push the code updates back to subversion? Or can we migrate > > off of subversion to github (or git in general) and stop relying on > > gar being checked into subversion together with the build > > descriptions? > > if one clones the svn repository, attach it to the git repo, then > synchronization would be possible i gess. checkout (once): > git svn clone https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2gar > cd gar > git remote add origin git at github.com:opencsw/gar.git > > do changes and commit (regular) : > > git push > git svn dcommit > > when building libserf, not using a standard svn working copy but a git checkout, it gives: * Platform solaris9-i386 (built on host 'current9x') Use of uninitialized value $REVISION in sprintf at gar//bin/mkpackage line 31. Use of uninitialized value $REVISION in sprintf at gar//bin/mkpackage line 31. CSWlibserf0-0 /home/rupert/pkgs/17.Jul.2011/libserf0_0_stub-1.0.0,REV=2011.07.17-SunOS5.9-all-NOTVERSIONED.pkg.gz CSWlibserf1-0 /home/rupert/pkgs/17.Jul.2011/libserf1_0-1.0.0,REV=2011.07.17-SunOS5.9-i386-NOTVERSIONED.pkg.gz -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sun Jul 17 13:20:03 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 17 Jul 2011 07:20:03 -0400 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: References: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> Message-ID: <1310901477-sup-2595@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sun Jul 17 07:15:53 -0400 2011: > when building libserf, not using a standard svn working copy but a git > checkout, it gives: > * Platform solaris9-i386 (built on host 'current9x') > Use of uninitialized value $REVISION in sprintf at gar//bin/mkpackage line > 31. > Use of uninitialized value $REVISION in sprintf at gar//bin/mkpackage line > 31. > CSWlibserf0-0 > /home/rupert/pkgs/17.Jul.2011/libserf0_0_stub-1.0.0,REV=2011.07.17-SunOS5.9-all-NOTVERSIONED.pkg.gz > CSWlibserf1-0 > /home/rupert/pkgs/17.Jul.2011/libserf1_0-1.0.0,REV=2011.07.17-SunOS5.9-i386-NOTVERSIONED.pkg.gz This is something we'd need to work out if switching to git. Most like, we'd want to substitue the first 7/8 chars of the sha1 representing the HEAD commit that you build from. We'd also need to ensure that the sha1 was containined in the set of commit referenced by the origin/master remote references. This is because in git, a committed set of files does not mean a publicly available set of files/commits. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From skayser at opencsw.org Sun Jul 17 15:14:25 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 17 Jul 2011 15:14:25 +0200 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: <1310901477-sup-2595@pinkfloyd.chass.utoronto.ca> References: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> <1310901477-sup-2595@pinkfloyd.chass.utoronto.ca> Message-ID: <20110717131424.GN21790@sebastiankayser.de> * Ben Walton wrote: > Excerpts from rupert THURNER's message of Sun Jul 17 07:15:53 -0400 2011: > > > when building libserf, not using a standard svn working copy but a git > > checkout, it gives: > > * Platform solaris9-i386 (built on host 'current9x') > > Use of uninitialized value $REVISION in sprintf at gar//bin/mkpackage line > > 31. > > Use of uninitialized value $REVISION in sprintf at gar//bin/mkpackage line > > 31. > > CSWlibserf0-0 > > /home/rupert/pkgs/17.Jul.2011/libserf0_0_stub-1.0.0,REV=2011.07.17-SunOS5.9-all-NOTVERSIONED.pkg.gz > > CSWlibserf1-0 > > /home/rupert/pkgs/17.Jul.2011/libserf1_0-1.0.0,REV=2011.07.17-SunOS5.9-i386-NOTVERSIONED.pkg.gz > > This is something we'd need to work out if switching to git. Most > like, we'd want to substitue the first 7/8 chars of the sha1 > representing the HEAD commit that you build from. We'd also need to > ensure that the sha1 was containined in the set of commit referenced > by the origin/master remote references. This is because in git, a > committed set of files does not mean a publicly available set of > files/commits. Ben, what do you think about adding this to the wiki page that Rupert created? http://wiki.opencsw.org/dvcs That way we can prepare a checklist of TODOs leading up to a migration. Sebastian From dam at opencsw.org Sun Jul 17 16:00:48 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 17 Jul 2011 16:00:48 +0200 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[15079] csw/mgar/pkg/libserf/trunk/Makefile In-Reply-To: References: <1310901647-sup-5939@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Rupert, Am 17.07.2011 um 15:56 schrieb rupert THURNER: > could you please have a look what might be wrong: > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/libserf/trunk/Makefile There are quite a lot of things: 1. Why have you removed the package split in r15079? http://sourceforge.net/apps/trac/gar/changeset/15079/csw/mgar/pkg/libserf/trunk/Makefile This alone causes a ton of errors like conflicts, warnings and other errors. 2. It is not good to remove released packages. The right way is to do an obsoletion which you aleady did. 3. An obsoletion must fully take over the functionality of the obsoleted package with the exception of development packages. The dependency from .so.1 to so.0 is invalid as bound programs bound to so.0 will not just work on so.1 I'll take a further look at the recipe. Best regards -- Dago From rupert at opencsw.org Sun Jul 17 16:13:57 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 17 Jul 2011 16:13:57 +0200 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[15079] csw/mgar/pkg/libserf/trunk/Makefile In-Reply-To: References: <1310901647-sup-5939@pinkfloyd.chass.utoronto.ca> Message-ID: for three reasons: 1. it did not build with the package split 2. it is a very small package and it adds complexity 3. something broke serf support in subversion a couple of months ago and with my restricted knowledge i was not able to upgrade subversion and serf. i removed the libserf0-0 obsolete, and now it complains about libserf-devel: $ csw-upload-pkg pkgs/17.Jul.2011/libserf* Processing 3 file(s). Please wait. Checking 2 package(s) against catalog unstable sparc SunOS5.9 Checking 2 package(s) against catalog unstable i386 SunOS5.9 Checking 2 package(s) against catalog unstable sparc SunOS5.10 Checking 2 package(s) against catalog unstable i386 SunOS5.10 All checks successful. Proceeding. Inserting libserf1_0 (i386 SunOS5.9) into catalog unstable i386 SunOS5.10 Inserting libserf_devel_stub (all SunOS5.9) into catalog unstable i386 SunOS5.10 CRITICAL:root:Response: 406 {"error_message": "There already is a package with that pkgname: CSWlibserf-devel"} Traceback (most recent call last): File "/opt/csw/bin/csw-upload-pkg", line 596, in uploader.Upload() File "/opt/csw/bin/csw-upload-pkg", line 172, in Upload self._InsertIntoCatalog(filename, arch, osrel, file_metadata) File "/opt/csw/bin/csw-upload-pkg", line 375, in _InsertIntoCatalog raise RestCommunicationError("%s - HTTP code: %s" % (url, http_code)) __main__.RestCommunicationError: http://buildfarm.opencsw.org/releases/catalogs/unstable/i386/SunOS5.10/f227ae44170d9dd97d60e1c1c6c934e4/- HTTP code: 406 in general i'd prefer less complex recipies, which are easy upgradable even by non-experts ... like me :) rupert. On Sun, Jul 17, 2011 at 16:00, Dagobert Michelsen wrote: > Hi Rupert, > > Am 17.07.2011 um 15:56 schrieb rupert THURNER: > > could you please have a look what might be wrong: > > > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/libserf/trunk/Makefile > > There are quite a lot of things: > > 1. Why have you removed the package split in r15079? > > http://sourceforge.net/apps/trac/gar/changeset/15079/csw/mgar/pkg/libserf/trunk/Makefile > This alone causes a ton of errors like conflicts, warnings and other > errors. > > 2. It is not good to remove released packages. The right way is to do an > obsoletion which > you aleady did. > > 3. An obsoletion must fully take over the functionality of the obsoleted > package with > the exception of development packages. The dependency from .so.1 to so.0 > is invalid > as bound programs bound to so.0 will not just work on so.1 > > I'll take a further look at the recipe. > > > Best regards > > -- Dago -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Sun Jul 17 16:18:44 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 17 Jul 2011 16:18:44 +0200 Subject: [csw-maintainers] Test errors on current* In-Reply-To: References: <1309827668-sup-918@pinkfloyd.chass.utoronto.ca> <1310605910-sup-2081@pinkfloyd.chass.utoronto.ca> <1310734278-sup-9274@pinkfloyd.chass.utoronto.ca> Message-ID: <12ADF45A-4776-4928-BBF8-A09D76F32A21@opencsw.org> Hi Rupert, Am 17.07.2011 um 11:12 schrieb rupert THURNER: > haha ... unstable seems to well deserve its name :) > > There were 7 failures: > 1) test_serf_connection_request_create: test/test_context.c:166: expected <0> but was <124> > 2) test_serf_connection_priority_request_create: test/test_context.c:265: expected <0> but was <124> > 3) test_serf_closed_connection: test/test_context.c:404: expected <0> but was <124> > 4) test_serf_setup_proxy: test/test_context.c:505: expected <0> but was <124> > 5) test_keepalive_limit_one_by_one: test/test_context.c:656: expected <0> but was <124> > 6) test_keepalive_limit_one_by_one_and_burst: test/test_context.c:810: expected <0> but was <124> > 7) test_serf_progress_callback: test/test_context.c:932: expected <0> but was <124> This was due to missing ipv6 on loopback interfaces: 9120: so_socket(PF_INET6, SOCK_STREAM, IPPROTO_IP, "", 1) = 10 9120: fcntl(10, F_GETFD, 0x00000002) = 0 9120: fcntl(10, F_SETFD, 0x00000001) = 0 9120: fcntl(10, F_GETFL, 0x00000000) = 2 9120: fcntl(10, F_SETFL, 0x00000082) = 0 9120: setsockopt(10, SOL_SOCKET, SO_REUSEADDR, 0xFFBFF864, 4, 1) = 0 9120: bind(10, 0x00059EA0, 16, 3) Err#124 EAFNOSUPPORT Fixed now. Investigating further. Best regards -- Dago From dam at opencsw.org Sun Jul 17 16:33:28 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 17 Jul 2011 16:33:28 +0200 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[15079] csw/mgar/pkg/libserf/trunk/Makefile In-Reply-To: References: <1310901647-sup-5939@pinkfloyd.chass.utoronto.ca> Message-ID: <71F517CB-9496-498F-9BFD-393E8611536D@opencsw.org> Hi Rupert, Am 17.07.2011 um 16:13 schrieb rupert THURNER: > for three reasons: > 1. it did not build with the package split > 2. it is a very small package and it adds complexity Splitting off devel is a real good idea, and taking back an already splitted package is a real bad idea. > 3. something broke serf support in subversion a couple of months ago > and with my restricted knowledge i was not able to upgrade subversion and serf. > > i removed the libserf0-0 obsolete, and now it complains about libserf-devel: > $ csw-upload-pkg pkgs/17.Jul.2011/libserf* > Processing 3 file(s). Please wait. > Checking 2 package(s) against catalog unstable sparc SunOS5.9 > Checking 2 package(s) against catalog unstable i386 SunOS5.9 > Checking 2 package(s) against catalog unstable sparc SunOS5.10 > Checking 2 package(s) against catalog unstable i386 SunOS5.10 > All checks successful. Proceeding. > Inserting libserf1_0 (i386 SunOS5.9) into catalog unstable i386 SunOS5.10 > Inserting libserf_devel_stub (all SunOS5.9) into catalog unstable i386 SunOS5.10 > CRITICAL:root:Response: 406 {"error_message": "There already is a package with that pkgname: CSWlibserf-devel"} > Traceback (most recent call last): > File "/opt/csw/bin/csw-upload-pkg", line 596, in > uploader.Upload() > File "/opt/csw/bin/csw-upload-pkg", line 172, in Upload > self._InsertIntoCatalog(filename, arch, osrel, file_metadata) > File "/opt/csw/bin/csw-upload-pkg", line 375, in _InsertIntoCatalog > raise RestCommunicationError("%s - HTTP code: %s" % (url, http_code)) > __main__.RestCommunicationError: http://buildfarm.opencsw.org/releases/catalogs/unstable/i386/SunOS5.10/f227ae44170d9dd97d60e1c1c6c934e4/ - HTTP code: 406 For obsoletiong the prio package to the stub must be removed manually for now. > in general i'd prefer less complex recipies, which are easy upgradable even by non-experts ... like me :) True. But please keep in mind that I just recently updated libserf and usually not introduce complexity for fun: http://sourceforge.net/apps/trac/gar/log/csw/mgar/pkg/libserf/trunk/Makefile The interesting thing is that you can really take out much of the real complexity like handling post-configure-libtool and fiddling with pathes in 1.0: http://sourceforge.net/apps/trac/gar/changeset/15086 I'll happily renew my offer from last time: If you are working on a package I recently updated please ask me on any issues and I explain them so you can take over the package cleanly and you can maintain it in the future. I am unhappy if you just rip out stuff and try to release the resulting packages without review. I rebuild and released the package resulting from the latest revision to unstable for your convenience: -rw-r--r-- 1 dam csw 45074 Jul 17 16:30 libserf1_0-1.0.0,REV=2011.07.17-SunOS5.9-i386-CSW.pkg.gz -rw-r--r-- 1 dam csw 48050 Jul 17 16:28 libserf1_0-1.0.0,REV=2011.07.17-SunOS5.9-sparc-CSW.pkg.gz -rw-r--r-- 1 dam csw 23700 Jul 17 16:30 libserf_dev-1.0.0,REV=2011.07.17-SunOS5.9-i386-CSW.pkg.gz -rw-r--r-- 1 dam csw 23469 Jul 17 16:27 libserf_dev-1.0.0,REV=2011.07.17-SunOS5.9-sparc-CSW.pkg.gz -rw-r--r-- 1 dam csw 5077 Jul 17 16:30 libserf_devel_stub-1.0.0,REV=2011.07.17-SunOS5.9-all-CSW.pkg.gz Best regards -- Dago From rupert at opencsw.org Sun Jul 17 18:20:28 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 17 Jul 2011 18:20:28 +0200 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[15079] csw/mgar/pkg/libserf/trunk/Makefile In-Reply-To: <71F517CB-9496-498F-9BFD-393E8611536D@opencsw.org> References: <1310901647-sup-5939@pinkfloyd.chass.utoronto.ca> <71F517CB-9496-498F-9BFD-393E8611536D@opencsw.org> Message-ID: On Sun, Jul 17, 2011 at 16:33, Dagobert Michelsen wrote: > Hi Rupert, > > Am 17.07.2011 um 16:13 schrieb rupert THURNER: > > for three reasons: > > 1. it did not build with the package split > > 2. it is a very small package and it adds complexity > > Splitting off devel is a real good idea, and taking back an already > splitted package > is a real bad idea. > > > 3. something broke serf support in subversion a couple of months ago > > and with my restricted knowledge i was not able to upgrade subversion > and serf. > > > > i removed the libserf0-0 obsolete, and now it complains about > libserf-devel: > > $ csw-upload-pkg pkgs/17.Jul.2011/libserf* > > Processing 3 file(s). Please wait. > > Checking 2 package(s) against catalog unstable sparc SunOS5.9 > > Checking 2 package(s) against catalog unstable i386 SunOS5.9 > > Checking 2 package(s) against catalog unstable sparc SunOS5.10 > > Checking 2 package(s) against catalog unstable i386 SunOS5.10 > > All checks successful. Proceeding. > > Inserting libserf1_0 (i386 SunOS5.9) into catalog unstable i386 SunOS5.10 > > Inserting libserf_devel_stub (all SunOS5.9) into catalog unstable i386 > SunOS5.10 > > CRITICAL:root:Response: 406 {"error_message": "There already is a package > with that pkgname: CSWlibserf-devel"} > > Traceback (most recent call last): > > File "/opt/csw/bin/csw-upload-pkg", line 596, in > > uploader.Upload() > > File "/opt/csw/bin/csw-upload-pkg", line 172, in Upload > > self._InsertIntoCatalog(filename, arch, osrel, file_metadata) > > File "/opt/csw/bin/csw-upload-pkg", line 375, in _InsertIntoCatalog > > raise RestCommunicationError("%s - HTTP code: %s" % (url, http_code)) > > __main__.RestCommunicationError: > http://buildfarm.opencsw.org/releases/catalogs/unstable/i386/SunOS5.10/f227ae44170d9dd97d60e1c1c6c934e4/- HTTP code: 406 > > For obsoletiong the prio package to the stub must be removed manually for > now. > > > in general i'd prefer less complex recipies, which are easy upgradable > even by non-experts ... like me :) > > True. But please keep in mind that I just recently updated libserf and > usually not > introduce complexity for fun: > > http://sourceforge.net/apps/trac/gar/log/csw/mgar/pkg/libserf/trunk/Makefile > > The interesting thing is that you can really take out much of the real > complexity > like handling post-configure-libtool and fiddling with pathes in 1.0: > http://sourceforge.net/apps/trac/gar/changeset/15086 > > I'll happily renew my offer from last time: If you are working on a package > I recently updated please ask me on any issues and I explain them so you > can > take over the package cleanly and you can maintain it in the future. I am > unhappy > if you just rip out stuff and try to release the resulting packages without > review. > > I rebuild and released the package resulting from the latest revision to > unstable > for your convenience: > > -rw-r--r-- 1 dam csw 45074 Jul 17 16:30 > libserf1_0-1.0.0,REV=2011.07.17-SunOS5.9-i386-CSW.pkg.gz > -rw-r--r-- 1 dam csw 48050 Jul 17 16:28 > libserf1_0-1.0.0,REV=2011.07.17-SunOS5.9-sparc-CSW.pkg.gz > -rw-r--r-- 1 dam csw 23700 Jul 17 16:30 > libserf_dev-1.0.0,REV=2011.07.17-SunOS5.9-i386-CSW.pkg.gz > -rw-r--r-- 1 dam csw 23469 Jul 17 16:27 > libserf_dev-1.0.0,REV=2011.07.17-SunOS5.9-sparc-CSW.pkg.gz > -rw-r--r-- 1 dam csw 5077 Jul 17 16:30 > libserf_devel_stub-1.0.0,REV=2011.07.17-SunOS5.9-all-CSW.pkg.gz > > many thanks, dago! one cannot say no to such a nice offer, could you please help me get subversion-1.7 and serf running on unstable, or testing? currently serf does not work, giving: $ svn up --ignore-externals svn: Error running context: Internal error you can change the svn client to use serf by inserting in ~/.subversion/servers: [global] http-library = serf rupert -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Sun Jul 17 22:40:20 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 17 Jul 2011 22:40:20 +0200 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[15079] csw/mgar/pkg/libserf/trunk/Makefile In-Reply-To: References: <1310901647-sup-5939@pinkfloyd.chass.utoronto.ca> <71F517CB-9496-498F-9BFD-393E8611536D@opencsw.org> Message-ID: <0F71E7DE-0872-4215-8C23-F0E1002E1720@opencsw.org> Hi Rupert, Am 17.07.2011 um 18:20 schrieb rupert THURNER: > many thanks, dago! one cannot say no to such a nice offer, could you please help me get subversion-1.7 and serf running on unstable, or testing? currently serf does not work, giving: > > $ svn up --ignore-externals > svn: Error running context: Internal error > > you can change the svn client to use serf by inserting in ~/.subversion/servers: > [global] > http-library = serf An update of libserf won't work as svn is bound to libserf0-0 and the new one is libserf1-0 which needs a recompile of subversion. New build of 1.7.0alpha3 is under way, contrib/ seems to be missing in 1.7.0. I'll try the above test against libserf1-0 when I have a package. The build now fails with > /opt/csw/bin/ginstall -c -d /home/dam/mgar/pkg/subversion/trunk/work/solaris9-i386/install-isa-i386/opt/csw/lib/python2.3/libsvn > cd subversion/bindings/swig/python ; /bin/bash /home/dam/mgar/pkg/subversion/trunk/work/solaris9-i386/build-isa-i386/subversion-1.7.0-alpha3/libtool --mode=install /opt/csw/bin/ginstall -c _core.la /home/dam/mgar/pkg/subversion/trunk/work/solaris9-i386/install-isa-i386/opt/csw/lib/python2.3/libsvn/_core.la > libtool: install: error: cannot install `_core.la' to a directory not ending in /opt/csw/lib/svn/python/site-packages/libsvn I'll investigate further during next week. Feel free to give it a spin, everything is committed. Best regards -- Dago From rupert at opencsw.org Sun Jul 17 22:48:35 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 17 Jul 2011 22:48:35 +0200 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[15079] csw/mgar/pkg/libserf/trunk/Makefile In-Reply-To: <0F71E7DE-0872-4215-8C23-F0E1002E1720@opencsw.org> References: <1310901647-sup-5939@pinkfloyd.chass.utoronto.ca> <71F517CB-9496-498F-9BFD-393E8611536D@opencsw.org> <0F71E7DE-0872-4215-8C23-F0E1002E1720@opencsw.org> Message-ID: On Sun, Jul 17, 2011 at 22:40, Dagobert Michelsen wrote: > Hi Rupert, > > Am 17.07.2011 um 18:20 schrieb rupert THURNER: > > many thanks, dago! one cannot say no to such a nice offer, could you > please help me get subversion-1.7 and serf running on unstable, or testing? > currently serf does not work, giving: > > > > $ svn up --ignore-externals > > svn: Error running context: Internal error > > > > you can change the svn client to use serf by inserting in > ~/.subversion/servers: > > [global] > > http-library = serf > > An update of libserf won't work as svn is bound to libserf0-0 and the new > one is libserf1-0 which > needs a recompile of subversion. > > New build of 1.7.0alpha3 is under way, contrib/ seems to be missing in > 1.7.0. > I'll try the above test against libserf1-0 when I have a package. > > The build now fails with > > > /opt/csw/bin/ginstall -c -d > /home/dam/mgar/pkg/subversion/trunk/work/solaris9-i386/install-isa-i386/opt/csw/lib/python2.3/libsvn > > cd subversion/bindings/swig/python ; /bin/bash > /home/dam/mgar/pkg/subversion/trunk/work/solaris9-i386/build-isa-i386/subversion-1.7.0-alpha3/libtool > --mode=install /opt/csw/bin/ginstall -c _core.la/home/dam/mgar/pkg/subversion/trunk/work/solaris9-i386/install-isa-i386/opt/csw/lib/python2.3/libsvn/_ > core.la > > libtool: install: error: cannot install `_core.la' to a directory not > ending in /opt/csw/lib/svn/python/site-packages/libsvn > > I'll investigate further during next week. Feel free to give it a spin, > everything is > committed. > > exactly this error prevented a subversion build in the last couple of months - and nobody (that i know of) was able to fix it. i also asked on the subversion mailing list. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Sun Jul 17 23:08:24 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 17 Jul 2011 23:08:24 +0200 Subject: [csw-maintainers] gar download from launchpad? In-Reply-To: References: Message-ID: what is the reason that this download link does not work, i.e. it does not try http: MASTER_SITES = http://launchpad.net/subvertpy/trunk/$(VERSION)/+download DISTFILES = $(DISTNAME).tar.gz rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Jul 17 23:15:03 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 17 Jul 2011 22:15:03 +0100 Subject: [csw-maintainers] gar download from launchpad? In-Reply-To: References: Message-ID: Em 17/07/2011 22:08, "rupert THURNER" escreveu: > > what is the reason that this download link does not work, i.e. it does not try http: > > MASTER_SITES = http://launchpad.net/subvertpy/trunk/$(VERSION)/+download > DISTFILES = $(DISTNAME).tar.gz Try comparing with pyopenssl. It also downloads from launchpad. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Jul 17 23:24:21 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 17 Jul 2011 22:24:21 +0100 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[15079] csw/mgar/pkg/libserf/trunk/Makefile In-Reply-To: References: <1310901647-sup-5939@pinkfloyd.chass.utoronto.ca> <71F517CB-9496-498F-9BFD-393E8611536D@opencsw.org> <0F71E7DE-0872-4215-8C23-F0E1002E1720@opencsw.org> Message-ID: Em 17/07/2011 21:49, "rupert THURNER" escreveu: > > On Sun, Jul 17, 2011 at 22:40, Dagobert Michelsen wrote: >> >> Hi Rupert, >> >> Am 17.07.2011 um 18:20 schrieb rupert THURNER: >> > many thanks, dago! one cannot say no to such a nice offer, could you please help me get subversion-1.7 and serf running on unstable, or testing? currently serf does not work, giving: >> > >> > $ svn up --ignore-externals >> > svn: Error running context: Internal error >> > >> > you can change the svn client to use serf by inserting in ~/.subversion/servers: >> > [global] >> > http-library = serf >> >> An update of libserf won't work as svn is bound to libserf0-0 and the new one is libserf1-0 which >> needs a recompile of subversion. >> >> New build of 1.7.0alpha3 is under way, contrib/ seems to be missing in 1.7.0. >> I'll try the above test against libserf1-0 when I have a package. >> >> The build now fails with >> >> > /opt/csw/bin/ginstall -c -d /home/dam/mgar/pkg/subversion/trunk/work/solaris9-i386/install-isa-i386/opt/csw/lib/python2.3/libsvn >> > cd subversion/bindings/swig/python ; /bin/bash /home/dam/mgar/pkg/subversion/trunk/work/solaris9-i386/build-isa-i386/subversion-1.7.0-alpha3/libtool --mode=install /opt/csw/bin/ginstall -c _core.la/home/dam/mgar/pkg/subversion/trunk/work/solaris9-i386/install-isa-i386/opt/csw/lib/python2.3/libsvn/_ core.la Why python2.3 while we have 2.4... that's one odd thing here. >> > libtool: install: error: cannot install `_core.la' to a directory not ending in /opt/csw/lib/svn/python/site-packages/libsvn This is our python libraries directory. Our Python is different from most distributions in that we have a patch which removes the python version from the python lib subdirectory. Don't ask me why as the decision predates my involvement in the project. Some upstream projects (libxml comes to mind) assume that there is or there needs to be a version number in the python lib path. It could be an instance of this problem. I would like to reintroduce the version specific python lib dir, but it requires time, and hasn't yet bubbled up to the top of my priority list. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Mon Jul 18 00:47:58 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 17 Jul 2011 18:47:58 -0400 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: <20110717131424.GN21790@sebastiankayser.de> References: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> <1310901477-sup-2595@pinkfloyd.chass.utoronto.ca> <20110717131424.GN21790@sebastiankayser.de> Message-ID: <1310910757-sup-4510@pinkfloyd.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Sun Jul 17 09:14:25 -0400 2011: > Ben, what do you think about adding this to the wiki page that Rupert > created? > > http://wiki.opencsw.org/dvcs Done. I added a 'Choosing GIT' todo as presumably there could be a different list for mercurial if anyone is inclined in that direction. (I see that Rupert has made good improvements to this already.) A very rough method to check this that would definitely need some polish would be: git branch -a --contains $(git rev-parse HEAD) | grep "^remotes/origin" Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Mon Jul 18 05:23:24 2011 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 18 Jul 2011 05:23:24 +0200 Subject: [csw-maintainers] gar download from launchpad? In-Reply-To: References: Message-ID: 2011/7/17 Maciej Blizi?ski > > Em 17/07/2011 22:08, "rupert THURNER" escreveu: > > > > > what is the reason that this download link does not work, i.e. it does > not try http: > > > > MASTER_SITES = http://launchpad.net/subvertpy/trunk/$(VERSION)/+download > > DISTFILES = $(DISTNAME).tar.gz > > Try comparing with pyopenssl. It also downloads from launchpad. > > oh ... it did not like the missing / at the end. i tried to switch off the tests, but TEST_TARGET = did not do the trick. [===== NOW BUILDING: subvertpy-0.8.2 MODULATION isa-sparcv8: ISA=sparcv8 =====] [extract-modulated] complete for subvertpy. [patch-modulated] complete for subvertpy. [configure-modulated] complete for subvertpy. ==> Running setup.py test in work/solaris9-sparc/build-isa-sparcv8/subvertpy-0.8.2 usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: invalid command 'test' gmake[1]: Entering directory `/home/rupert/mgar-sav/pkg/subvertpy/trunk' [===== NOW BUILDING: subvertpy-0.8.2 MODULATION isa-sparcv8: ISA=sparcv8 =====] [extract-modulated] complete for subvertpy. [patch-modulated] complete for subvertpy. [configure-modulated] complete for subvertpy. ==> Running setup.py in work/solaris9-sparc/build-isa-sparcv8/subvertpy-0.8.2 Traceback (most recent call last): File "./setup.py", line 254, in (svn_includedirs, svn_libdirs, svn_link_flags, extra_libs) = svn_build_data() File "./setup.py", line 125, in svn_build_data raise Exception("Subversion development files not found. " Exception: Subversion development files not found. Please set SVN_PREFIX or (SVN_LIBRARY_PATH and SVN_HEADER_PATH) environment variable. gmake[1]: *** [build-work/solaris9-sparc/build-isa-sparcv8/subvertpy-0.8.2/setup.py] Error 1 gmake[1]: Leaving directory `/home/rupert/mgar-sav/pkg/subvertpy/trunk' gmake: *** [merge-isa-sparcv8] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Mon Jul 18 06:50:29 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 18 Jul 2011 06:50:29 +0200 Subject: [csw-maintainers] gar download from launchpad? In-Reply-To: References: Message-ID: Hi Rupert, Am 18.07.2011 um 05:23 schrieb rupert THURNER: > 2011/7/17 Maciej Blizi?ski > > Em 17/07/2011 22:08, "rupert THURNER" escreveu: > > > > > > what is the reason that this download link does not work, i.e. it does not try http: > > > > MASTER_SITES = http://launchpad.net/subvertpy/trunk/$(VERSION)/+download > > DISTFILES = $(DISTNAME).tar.gz > > Try comparing with pyopenssl. It also downloads from launchpad. > > > oh ... it did not like the missing / at the end. i tried to switch off the tests, but > TEST_TARGET = > did not do the trick. With TEST_TARGET you specifiy the make target, to completely disable the testsuite permanently use TEST_SCRIPTS = or for a temporary deisable use SKIPTEST ?= 1 Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From rupert at opencsw.org Mon Jul 18 10:34:00 2011 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 18 Jul 2011 10:34:00 +0200 Subject: [csw-maintainers] gar download from launchpad? In-Reply-To: References: Message-ID: On Mon, Jul 18, 2011 at 06:50, Dagobert Michelsen wrote: > Hi Rupert, > > Am 18.07.2011 um 05:23 schrieb rupert THURNER: > > 2011/7/17 Maciej Blizi?ski > > > > Em 17/07/2011 22:08, "rupert THURNER" escreveu: > > > > > > > > > > what is the reason that this download link does not work, i.e. it does > not try http: > > > > > > MASTER_SITES = > http://launchpad.net/subvertpy/trunk/$(VERSION)/+download > > > DISTFILES = $(DISTNAME).tar.gz > > > > Try comparing with pyopenssl. It also downloads from launchpad. > > > > > > oh ... it did not like the missing / at the end. i tried to switch off > the tests, but > > TEST_TARGET = > > did not do the trick. > > With TEST_TARGET you specifiy the make target, to completely disable the > testsuite permanently use > TEST_SCRIPTS = > or for a temporary deisable use > SKIPTEST ?= 1 thanks, this worked, at least on unstable9s! on current9x, unstable9x i have another problem: ==> Running setup.py in work/solaris9-i386/build-isa-i386/subvertpy-0.8.2 Traceback (most recent call last): File "./setup.py", line 254, in (svn_includedirs, svn_libdirs, svn_link_flags, extra_libs) = svn_build_data() File "./setup.py", line 125, in svn_build_data raise Exception("Subversion development files not found. " Exception: Subversion development files not found. Please set SVN_PREFIX or (SVN_LIBRARY_PATH and SVN_HEADER_PATH) environment variable. gmake[1]: *** [build-work/solaris9-i386/build-isa-i386/subvertpy-0.8.2/setup.py] Error 1 gmake[1]: Leaving directory `/home/rupert/mgar-sav/pkg/subvertpy/trunk' gmake: *** [merge-isa-i386] Error 2 it seems to be installed: $ pkginfo | grep subv application CSWsvn-devel subversion_devel - Subversion Development Support rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Mon Jul 18 13:03:02 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 18 Jul 2011 12:03:02 +0100 Subject: [csw-maintainers] Shared library placement, take 3 In-Reply-To: References: Message-ID: Hello maintainers, I would like to revisit a topic that was discussed earlier[1][2] this year. In short, it is the idea of keeping all shared libraries under /opt/csw/lib. Everything is explained in the proposal[3] that I wrote in February. The questions discussed were e.g. how to compile against an older version of the library. One idea was to keep header and .so files in separate directories; another idea was to have incompatible dev packages and that the choice of the version would be made by installing or uninstalling specific dev packages. What are your thoughts about it? Would you like to see the proposal integrated into our shared libraries packaging policy? Maciej [1] http://lists.opencsw.org/pipermail/maintainers/2011-January/013624.html [2] http://lists.opencsw.org/pipermail/maintainers/2011-February/013917.html [3] http://wiki.opencsw.org/proposal:shared-library-placement -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Mon Jul 18 13:03:03 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 18 Jul 2011 12:03:03 +0100 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses Message-ID: 2011/2/13 Peter FELECAN : > If we volunteered on the policy review is that we want to discuss. What > we don't wish is to run in circles. Yes, that was exactly the motivation behind policy-team: Have a small, agile team which can move quickly and get things done, while preserving the consensus-driven culture and allowing open discussion. I would like to revisit this topic in the near future. Peter, would you like to resume your participation in the policy team? Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Mon Jul 18 13:03:04 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 18 Jul 2011 12:03:04 +0100 Subject: [csw-maintainers] Introducting uWatch 2 Message-ID: Hi Willliam, Maybe we could also announce the automation of regex generation, so people know they can remove the regexes in most cases? Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Mon Jul 18 15:01:28 2011 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Mon, 18 Jul 2011 15:01:28 +0200 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: ("Maciej =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Mon, 18 Jul 2011 12:03:03 +0100") References: Message-ID: Maciej Blizi?ski writes: > 2011/2/13 Peter FELECAN : >> If we volunteered on the policy review is that we want to discuss. What >> we don't wish is to run in circles. > > Yes, that was exactly the motivation behind policy-team: Have a small, agile > team which can move quickly and get things done, while preserving the > consensus-driven culture and allowing open discussion. > > I would like to revisit this topic in the near future. > > Peter, would you like to resume your participation in the policy team? Of course I wish to. I think that we should start from where we left the discussion before it was polluted, i.e., the copyright and the abstract. Taking on the Debian policy document and adapting it to our specifics but not more. -- Peter FELECAN mailto:pfelecan at acm.org From maciej at opencsw.org Tue Jul 19 13:03:09 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 19 Jul 2011 12:03:09 +0100 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: References: Message-ID: Em 18/07/2011 14:02, escreveu: > > Maciej Blizi?ski writes: > > > 2011/2/13 Peter FELECAN : > >> If we volunteered on the policy review is that we want to discuss. What > >> we don't wish is to run in circles. > > > > Yes, that was exactly the motivation behind policy-team: Have a small, agile > > team which can move quickly and get things done, while preserving the > > consensus-driven culture and allowing open discussion. > > > > I would like to revisit this topic in the near future. > > > > Peter, would you like to resume your participation in the policy team? > > Of course I wish to. I think that we should start from where we left the > discussion before it was polluted, i.e., the copyright and the > abstract. Taking on the Debian policy document and adapting it to our > specifics but not more. Excellent! I have since looked at sphinx, a higher level tool which helps with structured documentation. It uses reStructured Text as the lightweight markup language. I will send the patch and a link to an example when I'm back home at the beginning of August. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Tue Jul 19 19:50:07 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 19 Jul 2011 19:50:07 +0200 Subject: [csw-maintainers] Packaging DBD::Sybase: need Sybase 12.5 x86 32 bit In-Reply-To: <20110530114003.GF29708@sebastiankayser.de> References: <716DB9DD-63AC-4DF5-8D9E-F5A33629EEBE@opencsw.org> <20110530114003.GF29708@sebastiankayser.de> Message-ID: <129AB912-3344-44A1-B98C-3AD4022ACBAB@opencsw.org> Hi Sebastian, Am 30.05.2011 um 13:40 schrieb Sebastian Kayser: > * Dagobert Michelsen wrote: >> I have packaged up the Perl module DBD::Sybase bound against >> Sybase OCS 12.5 and FreeTDS as alternative. However, as the >> customer uses Sparc I only have Sybase Sparc at hand. To build >> the x86 Perl module I would need a Sybase OCS 12.5 Client >> for x86 with 32 bit. I happen to have a 64 bit x64 which >> is unfortunately useless for a 32 bit Perl... > > was there further progress on DBD::Sybase? Got a Nagios plugin here > which could use it. In case the Sybase x86 client is still missing, > would it be feasible to release a build with / against FreeTDS only? Both are build and released: http://www.opencsw.org/packages/CSWpm-dbd-sybase-freetds/ http://www.opencsw.org/packages/CSWpm-dbd-sybase-ocs/ Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Wed Jul 20 04:10:05 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 19 Jul 2011 22:10:05 -0400 Subject: [csw-maintainers] progress report Message-ID: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca> Hi All, At this point, I'm fairly happy with the gpg signing daemon. You should be able to request a signed (with a dummy key) catalog on the buildfarm by doing: curl -s http://192.168.1.40:9981/clearsign/opencsw-future/unstable/i386/5.9 Valid urls for the daemon are: /(clearsign|detachsign)/(opencsw|opencsw-future)/(unstable|current)/... Give it a kick and see for yourself. The code is in a git repository: gitosis at mirror.opencsw.org:cswsign.git We don't have gitweb enabled there, but if you want access, I'll add your public key so you can check it out. We could host this in the github/opencsw framework that Rupert has been working on if that's considered better (likely). Additionally, I've written a basic script to integrate this feature with the script that is currently generating the catalogs for opencsw-future/unstable. I still need to plug it in, but the basics are in place now. The remaining pieces for automated signing are: 1. Enable outbound mail notification from cswsign on the buildfarm. 2. Integrate the generate-catalog script into generate-unstable. 3. Activate. This will leave two major automation tasks remaining: 1. Mantis integration. 2. Promotion from unstable to current. (depends on 1) If I understand correctly, Maciej re-integrated current and unstable before leaving for vacation. That means that packages newly pushed to unstable can (when #2 is ready) be promoted as appropriate to current. This should put us well on the path to automating our release process. If you've got questions or suggestions about how to proceed with the automation, please shoot them out here... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Wed Jul 20 04:16:16 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 19 Jul 2011 22:16:16 -0400 Subject: [csw-maintainers] Shared library placement, take 3 In-Reply-To: References: Message-ID: <1311127984-sup-3921@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Mon Jul 18 07:03:02 -0400 2011: Hi Maciej, > The questions discussed were e.g. how to compile against an older > version of the library. One idea was to keep header and .so files in > separate directories; another idea was to have incompatible dev > packages and that the choice of the version would be made by > installing or uninstalling specific dev packages. I don't recall (and haven't googled the archive) whether we discussed using alternatives as a mechanism that could default to newest .so but be toggled to older versions as required...This would allow side-by-side installation of the -dev packages. For buildfarm use, it could be a little unpleasant if it's switched for building one package and then affects other users. That might be reason enough to discard the idea. > What are your thoughts about it? Would you like to see the proposal > integrated into our shared libraries packaging policy? The less we have in special-prefix areas the better, as far as I'm concerned. If we do this, we'll need to tackle (as a separate item) the header files, etc too. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Wed Jul 20 04:51:14 2011 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 20 Jul 2011 04:51:14 +0200 Subject: [csw-maintainers] 32bit vs 64bit Message-ID: hi, is there a special reason that the recipies deal with 32bit and 64bit versions of our builds? could not gar just hardcode: if run on x86/current9x, build 32 bit, if run on sparc or unstable9x, build 64bit? reason why i dare asking: * tools like git and mercurial are sensitive to the available memory address space * build recipes dealing with 32 and 64 bit tend to be tricky. e.g. apr, apr-util, which then contain special hints why something worked or did not work rupert. From bwalton at opencsw.org Wed Jul 20 06:09:13 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 20 Jul 2011 00:09:13 -0400 Subject: [csw-maintainers] 32bit vs 64bit In-Reply-To: References: Message-ID: <1311134694-sup-5568@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Tue Jul 19 22:51:14 -0400 2011: Hi Rupert, > is there a special reason that the recipies deal with 32bit and > 64bit versions of our builds? could not gar just hardcode: if run on > x86/current9x, build 32 bit, if run on sparc or unstable9x, build > 64bit? The recipes only do a few things (typically) with 32 vs 64. The first is turning on the 64-bit support and the second is telling GAR whether or not to use isaexec. Are you suggesting that we enable 64-bit for everything by default? There has been some discussion about this in irc. More and more major things (perl, python, php, ruby for example) are beginning to require 64-bit builds. This requires more and more libraries to ahve 64-bit support. Once that is in place, building 64-bit binaries can be done too. Is it time to flip this default to on? Some apps would benefit, as you noted. Others wouldn't, but if those don't use isaexec, the 32-bit would still be the default. I think I'd support this change although it would take a long time to get everything updated. Maybe a post-dublin target? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From Joerg.Schilling at fokus.fraunhofer.de Wed Jul 20 10:33:51 2011 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Wed, 20 Jul 2011 10:33:51 +0200 Subject: [csw-maintainers] 32bit vs 64bit In-Reply-To: <1311134694-sup-5568@pinkfloyd.chass.utoronto.ca> References: <1311134694-sup-5568@pinkfloyd.chass.utoronto.ca> Message-ID: <4e2692ef.4JIN4rAuEWtj3p/t%Joerg.Schilling@fokus.fraunhofer.de> Ben Walton wrote: > Is it time to flip this default to on? Some apps would benefit, as > you noted. Others wouldn't, but if those don't use isaexec, the > 32-bit would still be the default. Most applications on sparc do not get a benefit from 64 bit as sparc is an orthogonal CPU and you have to pay for 64 bit with bigger code. Many applications in x86 benefit from 64 bit as they get twice as many registers with 64 bits and as missing registers is one of the major design faults from Intel. There is another more interesting thing to discuss. The large file summit in 1995 did bring us 32 bit support for files > 2147483646 bytes but the standard commitee did forget about adding support for the time past 2038 Jan 19 03:14:07. Sooner or later all applications that have to deal with times will have to be converted to 64 bit only and many of them are still not well written for the future. I had to work a lot on e.g. SCCS in order to remove any time related limitations. In order to support the time range for SCCS mentioned in POSIX with a 32 bit application, I added code that folds the time between 2038 Jan 19 03:14:08 GMT and Y2068 to times between 1902 and 1932. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From dam at opencsw.org Wed Jul 20 12:49:39 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 20 Jul 2011 12:49:39 +0200 Subject: [csw-maintainers] apr, apr-util In-Reply-To: References: Message-ID: Hi Rupert, Am 19.07.2011 um 23:28 schrieb rupert THURNER: > i tried to change apr, and apr-util as well ... but i seem to have the > same problem with obsoleting again. what did i do wrong, here the > apr-util example: > > http://sourceforge.net/apps/trac/gar/changeset/15126/csw/mgar/pkg/apr-util/trunk/Makefile You are trying to obsolete CSWlibaprutil which does not exist. Additionally, the private shared libraries in lib/apr-util-1 are needed for libaprutil-1.so.0. For the devel package I would recommend naming it after the library package as there is no longer a base apr-util where it would be devel for. This has all been fixed in http://sourceforge.net/apps/trac/gar/changeset/15147 and the packages have been released to unstable/: apr_util_stub-1.3.12,REV=2011.07.20-SunOS5.9-all-CSW.pkg.gz libaprutil1_0-1.3.12,REV=2011.07.20-SunOS5.9-i386-CSW.pkg.gz libaprutil1_0-1.3.12,REV=2011.07.20-SunOS5.9-sparc-CSW.pkg.gz libaprutil_dev-1.3.12,REV=2011.07.20-SunOS5.9-i386-CSW.pkg.gz libaprutil_dev-1.3.12,REV=2011.07.20-SunOS5.9-sparc-CSW.pkg.gz Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Wed Jul 20 13:22:14 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 20 Jul 2011 13:22:14 +0200 Subject: [csw-maintainers] apr, apr-util In-Reply-To: References: Message-ID: Hi Rupert, Am 20.07.2011 um 13:17 schrieb rupert THURNER: > On Wed, Jul 20, 2011 at 12:49, Dagobert Michelsen wrote: >> Hi Rupert, >> >> Am 19.07.2011 um 23:28 schrieb rupert THURNER: >>> i tried to change apr, and apr-util as well ... but i seem to have the >>> same problem with obsoleting again. what did i do wrong, here the >>> apr-util example: >>> >>> http://sourceforge.net/apps/trac/gar/changeset/15126/csw/mgar/pkg/apr-util/trunk/Makefile >> >> You are trying to obsolete CSWlibaprutil which does not exist. Additionally, the >> private shared libraries in lib/apr-util-1 are needed for libaprutil-1.so.0. For the >> devel package I would recommend naming it after the library package as there is no >> longer a base apr-util where it would be devel for. This has all been fixed in >> http://sourceforge.net/apps/trac/gar/changeset/15147 >> and the packages have been released to unstable/: >> >> apr_util_stub-1.3.12,REV=2011.07.20-SunOS5.9-all-CSW.pkg.gz >> libaprutil1_0-1.3.12,REV=2011.07.20-SunOS5.9-i386-CSW.pkg.gz >> libaprutil1_0-1.3.12,REV=2011.07.20-SunOS5.9-sparc-CSW.pkg.gz >> libaprutil_dev-1.3.12,REV=2011.07.20-SunOS5.9-i386-CSW.pkg.gz >> libaprutil_dev-1.3.12,REV=2011.07.20-SunOS5.9-sparc-CSW.pkg.gz > > thanks a lot dago! as apr was always fine and no need to change > anything which was fine, i thought it might be appropriate to just > ignore the error messages of checkpkg ... but it does not let. despite > CHECKPKG_OVERRIDES_CSWapr += > shared-lib-pkgname-mismatch|sonames=libapr-1.so.0|pkgname=CSWapr|expected=CSWlibapr10,CSWlibapr1-0| > in the recipe checkpkg wants it again, resp complains. This is in fact a bug in checkpkg. As you notice '|' is the last character indicating there is somewhere a trailing space. Maciej is aware of the issue but was unable to find the cause yet. As a workaround you could do CHECKPKG_OVERRIDES_CSWapr += shared-lib-pkgname-mismatch Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Wed Jul 20 16:11:11 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 20 Jul 2011 15:11:11 +0100 Subject: [csw-maintainers] progress report In-Reply-To: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca> References: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca> Message-ID: Em 20/07/2011 03:10, "Ben Walton" escreveu: > > > Hi All, > > At this point, I'm fairly happy with the gpg signing daemon. You > should be able to request a signed (with a dummy key) catalog on the > buildfarm by doing: > > curl -s > http://192.168.1.40:9981/clearsign/opencsw-future/unstable/i386/5.9 > > Valid urls for the daemon are: > > /(clearsign|detachsign)/(opencsw|opencsw-future)/(unstable|current)/... > > Give it a kick and see for yourself. > > The code is in a git repository: > gitosis at mirror.opencsw.org:cswsign.git > > We don't have gitweb enabled there, but if you want access, I'll add > your public key so you can check it out. We could host this in the > github/opencsw framework that Rupert has been working on if that's > considered better (likely). > > Additionally, I've written a basic script to integrate this feature > with the script that is currently generating the catalogs for > opencsw-future/unstable. I still need to plug it in, but the basics > are in place now. > > The remaining pieces for automated signing are: > > 1. Enable outbound mail notification from cswsign on the buildfarm. > 2. Integrate the generate-catalog script into generate-unstable. > 3. Activate. > > This will leave two major automation tasks remaining: > > 1. Mantis integration. > 2. Promotion from unstable to current. (depends on 1) > > If I understand correctly, Maciej re-integrated current and unstable > before leaving for vacation. That means that packages newly pushed to > unstable can (when #2 is ready) be promoted as appropriate to current. Yes, I have integrated unstable into dublin. I'll explain a bit about how I organized catalogs, so that we all use the same terminology. If anyone objects to the way I did it, please say. Here go the details. There are 2 places that hold catalog information: files on disk, visible at mirror.opencsw.org, and the buildfarm database, visible through buildfarm.opencsw.org. Information migration is possible in both directions. On the disk, there are two places, 'opencsw' and 'opencsw-future'. They also differ. 'opencsw' represents the old state as of the last time the former release manager touched it. 'opencsw-future' holds the proposed new structure. Some catalogs are the same in both places, for example unstable and dublin. However, some aren't, notably current is not the same in opencsw-future and in the DB. In opencsw-future, we integrate from unstable into a named release. Currently, the named release is "dublin". We also talked about "testing". In opencsw-future, testing is (can be) an alias for the named release we're currently working on. There is no concept of an alias in the database. That's why there is no "testing" there. We provide the URL ending in "current" for backward compatibility. There is also a catalog named "current" in the database, but it contains a snapshot of current on the official mirror. Perhaps we should rename it (in the DB) to "current-legacy" to make it explicit that it is not what we serve from .../opencsw-future/current/. Back to catalog signing, I suggest that we say "we sign unstable and dublin" or "we sign unstable and testing". Let "current" become a term denoting a legacy URL. I hope it makes sense to you. If it doesn't, or you need more information, please say. I am excited about the upcoming signing automation. I feel we are close to completing the new workflow which will make it easy to move forward. We have a number of new ideas in the pipeline, from me it will be new Python versions, reworked PostgreSQL and new MySQL version. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Wed Jul 20 16:37:30 2011 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 20 Jul 2011 16:37:30 +0200 Subject: [csw-maintainers] Fwd: incorrect time stamps after commit?! In-Reply-To: <5892b7b6-7dba-4050-a902-db5814aacb84@h4g2000vbw.googlegroups.com> References: <4E26001B.90500@maier-komor.de> <5892b7b6-7dba-4050-a902-db5814aacb84@h4g2000vbw.googlegroups.com> Message-ID: corrposting from the mercurial mailing list, as this is on solaris. did anybody of you see such a phenomen that a file timestamp is correct, and the mercurial commit timestamp is one day early? pls cc thomas as he is not on our list. rupert. ---------- Forwarded message ---------- From: Thomas Maier-Komor Date: Jul 20, 12:07?am Subject: incorrect time stamps after commit?! To: mercurial Hi, I'm a little bit confused about the timestamps in the commit log, after I just commit a changeset to a local repository (commit no push). The commit was at about Jul 19 23:57. Last change to one of the committed files was (as can be seen below) at 23:54. thomas at azalin:~/src/mbuffer% ls -l mbuffer.c -rw-r--r-- ? 1 thomas ? thomas ? ? 65235 Jul 19 23:53 mbuffer.c thomas at azalin:~/src/mbuffer% hg tip changeset: ? 221:5970604006e6 tag: ? ? ? ? tip user: ? ? ? ?Thomas Maier-Komor date: ? ? ? ?Mon Jul 18 23:25:12 2011 +0200 summary: ? ? added interactive prompting mode thomas at azalin:~/src/mbuffer% hg diff -c 221 mbuffer.c | diffstat ? mbuffer.c | ?120 ++++++++++++++++++++++++++++++++++++++++++++------------------ ? 1 file changed, 87 insertions(+), 33 deletions(-) thomas at azalin:~/src/mbuffer% hg version Mercurial Distributed SCM (version 1.8.4) (seehttp://mercurial.selenic.comfor more information) Copyright (C) 2005-2011 Matt Mackall and others This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. thomas at azalin:~/src/mbuffer% uname -a SunOS azalin 5.10 Generic_144488-05 sun4u sparc SUNW,Sun-Blade-2500 But still the message log say I did the commit was done yesterday, ~24.5 hours ago! This is a local filesystem! No NFS, no CIFS or the like. Just Solaris with native ZFS if it matters at all. The filesystem time stamps look correct, but the commit entry looks broken. The same for the one before. I cannot comment on older commits. This is with Mercurial 1.8.4. The Locale was set to de_DE.ISO8859-1 and I reset it to generate the output above. The time on the machine is correct and synced via NTP... Any ideas? - Thomas _______________________________________________ Mercurial mailing list Mercur... at selenic.comhttp://selenic.com/mailman/listinfo/mercurial From rupert at opencsw.org Wed Jul 20 18:03:15 2011 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 20 Jul 2011 18:03:15 +0200 Subject: [csw-maintainers] progress report In-Reply-To: References: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca> Message-ID: What is the plan for the packages maintained by phil? > Am 20.07.2011 16:12 schrieb "Maciej Blizi?ski" : > > > Em 20/07/2011 03:10, "Ben Walton" escreveu: > >> > >> > >> Hi All, > >> > >> At this point, I'm fairly happy with the gpg signing daemon. You > >> should be able to request a signed (with a dummy key) catalog on the > >> buildfarm by doing: > >> > >> curl -s > >> http://192.168.1.40:9981/clearsign/opencsw-future/unstable/i386/5.9 > >> > >> Valid urls for the daemon are: > >> > >> /(clearsign|detachsign)/(opencsw|opencsw-future)/(unstable|current)/... > >> > >> Give it a kick and see for yourself. > >> > >> The code is in a git repository: > >> gitosis at mirror.opencsw.org:cswsign.git > >> > >> We don't have gitweb enabled there, but if you want access, I'll add > >> your public key so you can check it out. We could host this in the > >> github/opencsw framework that Rupert has been working on if that's > >> considered better (likely). > >> > >> Additionally, I've written a basic script to integrate this feature > >> with the script that is currently generating the catalogs for > >> opencsw-future/unstable. I still need to plug it in, but the basics > >> are in place now. > >> > >> The remaining pieces for automated signing are: > >> > >> 1. Enable outbound mail notification from cswsign on the buildfarm. > >> 2. Integrate the generate-catalog script into generate-unstable. > >> 3. Activate. > >> > >> This will leave two major automation tasks remaining: > >> > >> 1. Mantis integration. > >> 2. Promotion from unstable to current. (depends on 1) > >> > >> If I understand correctly, Maciej re-integrated current and unstable > >> before leaving for vacation. That means that packages newly pushed to > >> unstable can (when #2 is ready) be promoted as appropriate to current. > > > > Yes, I have integrated unstable into dublin. I'll explain a bit about how I > > organized catalogs, so that we all use the same terminology. If anyone > > objects to the way I did it, please say. Here go the details. > > > > There are 2 places that hold catalog information: files on disk, visible at > > mirror.opencsw.org, and the buildfarm database, visible through > > buildfarm.opencsw.org. Information migration is possible in both > > directions. On the disk, there are two places, 'opencsw' and > > 'opencsw-future'. They also differ. 'opencsw' represents the old state as of > > the last time the former release manager touched it. 'opencsw-future' holds > > the proposed new structure. > > > > Some catalogs are the same in both places, for example unstable and dublin. > > However, some aren't, notably current is not the same in opencsw-future and > > in the DB. > > > > In opencsw-future, we integrate from unstable into a named release. > > Currently, the named release is "dublin". We also talked about "testing". In > > opencsw-future, testing is (can be) an alias for the named release we're > > currently working on. > > > > There is no concept of an alias in the database. That's why there is no > > "testing" there. > > > > We provide the URL ending in "current" for backward compatibility. There is > > also a catalog named "current" in the database, but it contains a snapshot > > of current on the official mirror. Perhaps we should rename it (in the DB) > > to "current-legacy" to make it explicit that it is not what we serve from > > .../opencsw-future/current/. > > > > Back to catalog signing, I suggest that we say "we sign unstable and dublin" > > or "we sign unstable and testing". Let "current" become a term denoting a > > legacy URL. > > > > I hope it makes sense to you. If it doesn't, or you need more information, > > please say. > > > > I am excited about the upcoming signing automation. I feel we are close to > > completing the new workflow which will make it easy to move forward. We have > > a number of new ideas in the pipeline, from me it will be new Python > > versions, reworked PostgreSQL and new MySQL version. > > > > Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Wed Jul 20 18:29:31 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 20 Jul 2011 12:29:31 -0400 Subject: [csw-maintainers] progress report In-Reply-To: References: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca> Message-ID: <1311179300-sup-3323@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Wed Jul 20 12:03:15 -0400 2011: Hi Rupert, > What is the plan for the packages maintained by phil? These will be handled like any other orphaned packages. If somebody wants an uprev or bug fix, they're open to takeover. Some of them have build descriptions (non-GAR) in the svn repo that can be GAR-ified but others will need a whole new recipe. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Wed Jul 20 20:06:11 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 20 Jul 2011 20:06:11 +0200 Subject: [csw-maintainers] Shared library placement, take 3 In-Reply-To: <1311127984-sup-3921@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Tue, 19 Jul 2011 22:16:16 -0400") References: <1311127984-sup-3921@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Excerpts from Maciej Blizi?ski's message of Mon Jul 18 07:03:02 -0400 2011: > > Hi Maciej, > >> The questions discussed were e.g. how to compile against an older >> version of the library. One idea was to keep header and .so files in >> separate directories; another idea was to have incompatible dev >> packages and that the choice of the version would be made by >> installing or uninstalling specific dev packages. > > I don't recall (and haven't googled the archive) whether we discussed > using alternatives as a mechanism that could default to newest .so but > be toggled to older versions as required...This would allow > side-by-side installation of the -dev packages. For buildfarm use, it > could be a little unpleasant if it's switched for building one package > and then affects other users. That might be reason enough to discard > the idea. I think that I proposed the alternatives solution and I still think that it's a good solution although painful on a build-farm but where the last version should be considered the right alternative. Using zones or other virtual system can be an easier solution but which requires a lot of metal. I think that we must not ignore the population of developers who need to use different versions on their own systems. As always, look how Debian solved the issue. -- Peter From pfelecan at opencsw.org Wed Jul 20 20:09:21 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 20 Jul 2011 20:09:21 +0200 Subject: [csw-maintainers] progress report In-Reply-To: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Tue, 19 Jul 2011 22:10:05 -0400") References: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Give it a kick and see for yourself. Congrats for all this good work. > The code is in a git repository: > gitosis at mirror.opencsw.org:cswsign.git However, can we use one and only one source control system? It starts to be a little bit of a bazaar (and I'm not proposing bzr) -- Peter From bwalton at opencsw.org Wed Jul 20 20:12:45 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 20 Jul 2011 14:12:45 -0400 Subject: [csw-maintainers] progress report In-Reply-To: References: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca> Message-ID: <1311185511-sup-2549@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Wed Jul 20 14:09:21 -0400 2011: Hi Peter, > > The code is in a git repository: > > gitosis at mirror.opencsw.org:cswsign.git > > However, can we use one and only one source control system? It starts to > be a little bit of a bazaar (and I'm not proposing bzr) I will place it in the opencsw sourceforge repository beside the buildfarm code, etc then. I agree that until we switch, mixing isn't ideal. I'll still develop with git but will push to svn for public consumption. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From jcraig at opencsw.org Wed Jul 20 21:07:48 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Wed, 20 Jul 2011 15:07:48 -0400 Subject: [csw-maintainers] Shared library placement, take 3 In-Reply-To: References: <1311127984-sup-3921@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Jul 20, 2011 at 2:06 PM, Peter FELECAN wrote: > need to use different versions on their own systems. As always, look how > Debian solved the issue. There are two use cases for this problem: Unique SONAMEs ) This is the better behaved use case. In this situation multiple versions of the shared libraries can co-exist in the same directory. So lets assume we have the app "foo" that provides "libfoo" and has a version 1 & 2. package contents dependency foo1 bin depends on libfoo1 foo2 bin depends on libfoo2 libfoo1 so libfoo2 so libfoo1-dev header depends on libfoo1, conflicts libfoo2-dev libfoo2-dev header depends on libfoo2, conflicts libfoo1-dev If debug versions of so's then: libfoo1-dbg debug-so conficts with libfoo1 (and libfoo1 conflicts with it) This allows multiple bin/so versions to be installed and one version of the headers. We could extend this with CSWalternatives to allow switching between header versions but could be confusing if you assume the version you want is the current version. Non-Unique SONAMEs) Bad developer, bad. Oh well, the packager must still deal with it. I'm not sure of an example package like this to check against my ubuntu catalog. This situation calls for either making the versions exclusive (using conflicts with) or configuring them for there own tree. Using alternatives is a risky undertaking because it will almost always eventually cause grief. If alternatives puts the .so in a common lib directory and a user builds against it then changes the alternative choice, whatever they've built will break. Ultimately, if the library is well behaved then I do think its best to place it in a common directory (/opt/csw/lib). Jon From bwalton at opencsw.org Thu Jul 21 02:15:16 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 20 Jul 2011 20:15:16 -0400 Subject: [csw-maintainers] 32bit vs 64bit In-Reply-To: <4e2692ef.4JIN4rAuEWtj3p/t%Joerg.Schilling@fokus.fraunhofer.de> References: <1311134694-sup-5568@pinkfloyd.chass.utoronto.ca> <4e2692ef.4JIN4rAuEWtj3p/t%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <1311207061-sup-5613@pinkfloyd.chass.utoronto.ca> Excerpts from Joerg.Schilling's message of Wed Jul 20 04:33:51 -0400 2011: > Most applications on sparc do not get a benefit from 64 bit as sparc > is an orthogonal CPU and you have to pay for 64 bit with bigger > code. True, but providing the option (especially for libraries) makes sense, I think. > Sooner or later all applications that have to deal with times will > have to be converted to 64 bit only and many of them are still not > well written for the future. So by building them 64-bit now and getting some field testing , bugs can be found and fixed. That seems like a good thing to me. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Jul 21 09:39:15 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 21 Jul 2011 08:39:15 +0100 Subject: [csw-maintainers] progress report In-Reply-To: <1311185511-sup-2549@pinkfloyd.chass.utoronto.ca> References: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca> <1311185511-sup-2549@pinkfloyd.chass.utoronto.ca> Message-ID: Em 20/07/2011 19:12, "Ben Walton" escreveu: > > Excerpts from Peter FELECAN's message of Wed Jul 20 14:09:21 -0400 2011: > > Hi Peter, > > > > The code is in a git repository: > > > gitosis at mirror.opencsw.org:cswsign.git > > > > However, can we use one and only one source control system? It starts to > > be a little bit of a bazaar (and I'm not proposing bzr) > > I will place it in the opencsw sourceforge repository beside the > buildfarm code, etc then. I agree that until we switch, mixing isn't > ideal. I'll still develop with git but will push to svn for public > consumption. Can we use github (or code.google.com) for development in git and periodically sync the code with subversion? Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Thu Jul 21 09:39:15 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 21 Jul 2011 08:39:15 +0100 Subject: [csw-maintainers] Shared library placement, take 3 In-Reply-To: References: <1311127984-sup-3921@pinkfloyd.chass.utoronto.ca> Message-ID: Em 20/07/2011 20:08, "Jonathan Craig" escreveu: > > On Wed, Jul 20, 2011 at 2:06 PM, Peter FELECAN wrote: > > need to use different versions on their own systems. As always, look how > > Debian solved the issue. > > There are two use cases for this problem: > > Unique SONAMEs ) This is the better behaved use case. In this > situation multiple versions of the shared libraries can co-exist in > the same directory. So lets assume we have the app "foo" that > provides "libfoo" and has a version 1 & 2. > > package contents dependency > foo1 bin depends on libfoo1 > foo2 bin depends on libfoo2 > libfoo1 so > libfoo2 so > libfoo1-dev header depends on libfoo1, conflicts libfoo2-dev > libfoo2-dev header depends on libfoo2, conflicts libfoo1-dev > > If debug versions of so's then: > libfoo1-dbg debug-so conficts with libfoo1 (and libfoo1 conflicts with it) > > This allows multiple bin/so versions to be installed and one version > of the headers. What if two maintainers are building packages at the same time and each one needs a different version of a library? > We could extend this with CSWalternatives to allow > switching between header versions but could be confusing if you assume > the version you want is the current version. > > Non-Unique SONAMEs) Bad developer, bad. Oh well, the packager must > still deal with it. In the general case, it is possible to inject an additional soname number to make the sonames unique. > I'm not sure of an example package like this to > check against my ubuntu catalog. This situation calls for either > making the versions exclusive (using conflicts with) or configuring > them for there own tree. Using alternatives is a risky undertaking > because it will almost always eventually cause grief. If alternatives > puts the .so in a common lib directory and a user builds against it > then changes the alternative choice, whatever they've built will > break. Yes, alternatives do not look like a good choice, neither for .so symlinks, nor for libraries. > Ultimately, if the library is well behaved then I do think its best to > place it in a common directory (/opt/csw/lib). Cool. There is one case which needs consideration: gcc C++ libs vs Solaris Studio C++ libs. If we compile the same sources with both compilers, we will get a soname conflict. What should we do: put gcc libs into e.g. /opt/csw/lib/gcc/ or append "gcc" to the soname and keep the lib in /opt/csw/lib? (Or is there another solution?) Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Jul 21 09:41:40 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 21 Jul 2011 09:41:40 +0200 Subject: [csw-maintainers] Shared library placement, take 3 In-Reply-To: References: <1311127984-sup-3921@pinkfloyd.chass.utoronto.ca> Message-ID: <42F03AD6-DB11-4C77-9513-6CA6C10D3A9E@opencsw.org> Hi Jon, Am 20.07.2011 um 21:07 schrieb Jonathan Craig: > Non-Unique SONAMEs) Bad developer, bad. Oh well, the packager must > still deal with it. I'm not sure of an example package like this to > check against my ubuntu catalog. The old libnet.so > This situation calls for either > making the versions exclusive (using conflicts with) or configuring > them for there own tree. Using alternatives is a risky undertaking > because it will almost always eventually cause grief. If alternatives > puts the .so in a common lib directory and a user builds against it > then changes the alternative choice, whatever they've built will > break. The only viable solution is to fix that and to force a unique soname. This is what we have done on libnet1. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Thu Jul 21 10:31:14 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 21 Jul 2011 10:31:14 +0200 Subject: [csw-maintainers] apr, apr-util In-Reply-To: References: Message-ID: <41D4D716-370C-4689-9FBA-644FB59DAFDF@opencsw.org> Hi Rupert, Am 20.07.2011 um 13:17 schrieb rupert THURNER: > thanks a lot dago! as apr was always fine and no need to change > anything which was fine, i thought it might be appropriate to just > ignore the error messages of checkpkg ... but it does not let. despite > CHECKPKG_OVERRIDES_CSWapr += > shared-lib-pkgname-mismatch|sonames=libapr-1.so.0|pkgname=CSWapr|expected=CSWlibapr10,CSWlibapr1-0| > in the recipe checkpkg wants it again, resp complains. While I am at it I reviewed the patches and environment and ripped out most of it as it seems to have been inserted earlier and is no longer necessary. The recipe is now also at 64 bit and with consistent package naming: http://sourceforge.net/apps/trac/gar/changeset/15165 The packages have been released to unstable/. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From rupert at opencsw.org Thu Jul 21 12:51:00 2011 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 21 Jul 2011 12:51:00 +0200 Subject: [csw-maintainers] Fwd: git svn push, git dcommit leads to commit duplication? In-Reply-To: <201107211225.42860.trast@student.ethz.ch> References: <201107211225.42860.trast@student.ethz.ch> Message-ID: for the interest of the ones using git as client and want to update both, git, and svn: first dcommit to svn to enrich with svn information, then push everything to the git server. a little bit background info how i got in this situation: i did it the other way round, i.e. push first to github, then dcommit to svn. i ended up having duplicate commits, one with svn info, and one without, locally. the effect was that i could not push any more to github (without forcing it though). i removed the surplus commits from github via git reset --hard hoping nobody of you pulled them beforehand. rupert. ---------- Forwarded message ---------- From: Thomas Rast Date: Thu, Jul 21, 2011 at 12:25 Subject: Re: git svn push, git dcommit leads to commit duplication? To: rupert THURNER Cc: git at vger.kernel.org rupert THURNER wrote: > we keep a svn clone of > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg on > https://github.com/opencsw/pkg-all . usually i synchronize it with > "git svn rebase" and "git push" from a local clone created with "git > svn clone https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg". > > last time i changed something in this local clone and pushed it to > github, and commited it to sourceforge via git svn dcommit. now the > commits are there two times, different. my guess was that dcommit > would add the svn related stuff to the existing git commits. what is > the correct usage to keep svn and git in sync? Your guess is mostly correct. To best understand what is going on, keep in mind that "you can never modify, you can only rewrite and forget"[1]. Suppose you say 'git svn dcommit' on history that looks like 1---2---3--(4)--(5) SVN o---o---o (svn/trunk) \ a---b---c (master) where 4 and 5 are commits not yet fetched from SVN (if any). 1. git-svn will first fetch the new SVN history, let's call them N: 1---2---3---4---5 SVN o---o---o---N---N (svn/trunk) \ a---b---c (master) 2. Then it will rebase your own work on top of the new SVN stuff: 1---2---3---4---5 SVN o---o---o---N---N (svn/trunk) \ a---b---c (master) 3. Then it will rebase your own work on top of the new SVN stuff: 1---2---3---4---5 SVN o---o---o---N---N (svn/trunk) \ a'--b'--c' (master) 4. Then it will commit all of that to SVN: 1---2---3---4---5---6---7---8 SVN o---o---o---N---N (svn/trunk) \ a'--b'--c' (master) 5. Then it will annotate your commits o' with the info coming back from SVN (such as author, etc.) and "replace" your master with it: 1---2---3---4---5---6---7---8 SVN o---o---o---N---N---A---B---C (svn/trunk, master) From the point of view of 'master', this is also much like a rebase, except that authors and timestamps change too and (unless disabled) git-svn-id: lines appear in your commit messages. Does that clarify what happens? [For the sake of completeness, I should point out that this is a simplification. Steps 3--5 are actually all done in one go *per commit*, and step 3 does not use 'git-rebase' but a variant on the theme that preserves merges of side branches.] As for > what is the correct usage to keep svn and git in sync? the only way I know of that avoids constantly rebasing branches is to never push anything before it has been dcommitted. [1] Quoting Tv; he said it much better than I can. -- Thomas Rast trast@{inf,student}.ethz.ch -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Thu Jul 21 19:32:49 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 21 Jul 2011 19:32:49 +0200 Subject: [csw-maintainers] progress report In-Reply-To: ("Maciej =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu, 21 Jul 2011 08:39:15 +0100") References: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca> <1311185511-sup-2549@pinkfloyd.chass.utoronto.ca> Message-ID: Maciej Blizi?ski writes: > Em 20/07/2011 19:12, "Ben Walton" escreveu: >> >> Excerpts from Peter FELECAN's message of Wed Jul 20 14:09:21 -0400 2011: >> >> Hi Peter, >> >> > > The code is in a git repository: >> > > gitosis at mirror.opencsw.org:cswsign.git >> > >> > However, can we use one and only one source control system? It starts to >> > be a little bit of a bazaar (and I'm not proposing bzr) >> >> I will place it in the opencsw sourceforge repository beside the >> buildfarm code, etc then. I agree that until we switch, mixing isn't >> ideal. I'll still develop with git but will push to svn for public >> consumption. > > Can we use github (or code.google.com) for development in git and > periodically sync the code with subversion? Please use *one* official SCM and, if you wish, make a bridge toward others. In what you describe, github is the principal one and subversion a bridged one. What I propose is the contrary until we decide on changing the official SCM. A final point is to use the same SCM for all the public OpenCSW projects. -- Peter FELECAN mailto:pfelecan at acm.org From pfelecan at opencsw.org Thu Jul 21 19:38:14 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 21 Jul 2011 19:38:14 +0200 Subject: [csw-maintainers] Fwd: git svn push, git dcommit leads to commit duplication? In-Reply-To: (rupert THURNER's message of "Thu, 21 Jul 2011 12:51:00 +0200") References: <201107211225.42860.trast@student.ethz.ch> Message-ID: rupert THURNER writes: > for the interest of the ones using git as client and want to update both, > git, and svn: first dcommit to svn to enrich with svn information, then push > everything to the git server. this is a good example of what happens when mixing SCMs and why we need an official one -- Peter From bonivart at opencsw.org Thu Jul 21 19:45:24 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 21 Jul 2011 19:45:24 +0200 Subject: [csw-maintainers] Fwd: git svn push, git dcommit leads to commit duplication? In-Reply-To: References: <201107211225.42860.trast@student.ethz.ch> Message-ID: On Thu, Jul 21, 2011 at 7:38 PM, Peter FELECAN wrote: > rupert THURNER writes: > >> for the interest of the ones using git as client and want to update both, >> git, and svn: first dcommit to svn to enrich with svn information, then push >> everything to the git server. > > > this is a good example of what happens when mixing SCMs and > why we need an official one > I also fail to see why this is important, it's not just Rupert who shows a lot of interest in this but in my opinion we have far more important things to do at the moment and the more complicated the situation is the less people can cooperate. Can we push all these SCM/repo discussion and experiments until we have a working release process at least. And to me it's obvious we should only have one system and host, if it's not good enough for all of our needs it's not worth the effort to migrate. Personally I've had zero issues with SVN at SF. /peter From bwalton at opencsw.org Fri Jul 22 02:43:01 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 21 Jul 2011 20:43:01 -0400 Subject: [csw-maintainers] Fwd: git svn push, git dcommit leads to commit duplication? In-Reply-To: References: <201107211225.42860.trast@student.ethz.ch> Message-ID: <1311295292-sup-8087@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Thu Jul 21 13:45:24 -0400 2011: > Can we push all these SCM/repo discussion and experiments until we > have a working release process at least. And to me it's obvious we > should only have one system and host, if it's not good enough for > all of our needs it's not worth the effort to migrate. Personally > I've had zero issues with SVN at SF. I think this is wise. It doesn't mean we can't think about it or tinker with it, but we really should focus on getting release machinery operational. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Jul 22 02:47:03 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 21 Jul 2011 20:47:03 -0400 Subject: [csw-maintainers] progress report In-Reply-To: References: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca> <1311185511-sup-2549@pinkfloyd.chass.utoronto.ca> Message-ID: <1311295574-sup-410@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Thu Jul 21 13:32:49 -0400 2011: > Please use *one* official SCM and, if you wish, make a bridge toward > others. In what you describe, github is the principal one and > subversion a bridged one. What I propose is the contrary until we > decide on changing the official SCM. A final point is to use the > same SCM for all the public OpenCSW projects. I agree with this. Lets fry the big fish (releases) for now and when things settle a bit, we can bike shed on scm for a while. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From jcraig at opencsw.org Fri Jul 22 13:38:14 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Fri, 22 Jul 2011 07:38:14 -0400 Subject: [csw-maintainers] Shared library placement, take 3 In-Reply-To: <42F03AD6-DB11-4C77-9513-6CA6C10D3A9E@opencsw.org> References: <1311127984-sup-3921@pinkfloyd.chass.utoronto.ca> <42F03AD6-DB11-4C77-9513-6CA6C10D3A9E@opencsw.org> Message-ID: On Thu, Jul 21, 2011 at 3:41 AM, Dagobert Michelsen wrote: > > The only viable solution is to fix that and to force a unique soname. > This is what we have done on libnet1. > Are there side effects to this solution. Obviously anything we built against our modified library would fail to find its shared library if someone removed ours and compiled their own. How about end users compiling against ours? Any issues with their ability to choose library version or anything like that? Jon From jcraig at opencsw.org Fri Jul 22 13:56:34 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Fri, 22 Jul 2011 07:56:34 -0400 Subject: [csw-maintainers] Shared library placement, take 3 In-Reply-To: References: <1311127984-sup-3921@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/7/21 Maciej Blizi?ski : > > Cool. There is one case which needs consideration: gcc C++ libs vs Solaris > Studio C++ libs. If we compile the same sources with both compilers, we will > get a soname conflict. What should we do: put gcc libs into e.g. > /opt/csw/lib/gcc/ or append "gcc" to the soname and keep the lib in > /opt/csw/lib? (Or is there another solution?) > This problem is one we will have to solve on our own as debian doesn't face this issue AFAIK. Well I see three approaches, but there may be more: 1) Place the the style of the library used by our binaries into the common directory and the other into its own tree (/op/csw/lib/[gcc|sunstudio]). PROS: Our binaries always find shared library in a single place. Could help with customers who are forced to use LD_LIBRARY_PATH settings. CONS: Confusing, how is one to know which style a given library uses beyond looking for a README. 2) Always place sunstudio into the common and gcc into its own tree (or vise-versa) PROS: Not confusing as to which directory holds which files. Our developers have resources to determine their RPATH needs at build time. CONS: LD_LIBRARY_PATH, while not recommended, should have a note about default including all of the shared library trees. 3) Use the approach for poorly behaved libraries and insert a minor release version to indicate sunstudio/gcc style library. If we always use a most minor version component of ".999" for the gcc style then we can force the link against the correct style. PROS: One shared library tree, so only one path for LD_LIBRARY_PATH users. CONS: Package construction is trickier. Possibly still confusing for end users who are trying to build against our libraries. I'm not wedded to any given approach at this time as my packages have all been pretty straight forward. I would lean towards #2 as its the simplest in terms of construction and should be easily understood by our customers. Option 3 is intriguing but I worry that it would be overly complicated for little gain. Thoughts? Jon From dam at opencsw.org Fri Jul 22 14:17:33 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 22 Jul 2011 14:17:33 +0200 Subject: [csw-maintainers] Shared library placement, take 3 In-Reply-To: References: <1311127984-sup-3921@pinkfloyd.chass.utoronto.ca> <42F03AD6-DB11-4C77-9513-6CA6C10D3A9E@opencsw.org> Message-ID: Hi Jon, Am 22.07.2011 um 13:38 schrieb Jonathan Craig: > On Thu, Jul 21, 2011 at 3:41 AM, Dagobert Michelsen wrote: >> The only viable solution is to fix that and to force a unique soname. >> This is what we have done on libnet1. > > Are there side effects to this solution. Obviously anything we built > against our modified library would fail to find its shared library if > someone removed ours and compiled their own. Probably yet, but I would say if someone replaces one of our libs they should better know what they are doing. > How about end users > compiling against ours? Any issues with their ability to choose > library version or anything like that? They should always use the new one. The layout is described here: http://wiki.opencsw.org/project-libnet Best regards -- Dago From bwalton at opencsw.org Sat Jul 23 05:54:56 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 22 Jul 2011 23:54:56 -0400 Subject: [csw-maintainers] unstable is now signed... Message-ID: <1311389987-sup-6408@pinkfloyd.chass.utoronto.ca> Hi All, The catalogs in unstable are now signed with the key inlined below. Once this has been working for a few days, we can go live with automatically signed catalogs. Thanks -Ben -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.9 (SunOS) mQGiBE4bnlARBAC205/zm2dhS9umxGYoBQqWC9B4z5LPU6AQiRYaabUVSvYToSZ9 kVHrkMbZXmhyGzT7jEpwc6/3de61poe8TqxPlJfP3pEqKbjSr2dVVuJVVyjXJtEC dbaNBgmYFDoSeCM+hDaXW6jZEUIOnqCIhwIWAm8SadhIdSZFy9c8Ukjx3wCgt4Fo ExK/sj7xMSKSmIT6wLvwNaMEALamp2oaL6Z7Gs2HoPeMXM8gcNVlbOVYbxfrE22l nagLoua/5zyoidgxv2MahjCINaFSQB0gjtMW6ZRZedlqNej3OMeDJycIbyJ/t+A8 dS9ygT8qgz4KQxmZhT4CDwrVAHaDIYxos+hi6UezxSKUZqTGSj4ZJFC/uZ0qjcqP abLgBACMcl3C7j6dgx/cgckvpgiHSK9vl1EgD3Err6v3mfOycJ3KH+xxV/5SXX6Z mu+vl7Ulf81IQwdTZttLWpzQ1JveMx1H7nXzU74/WAvOJoztvWIT/cKrmVGO/fZv 87IqpHvNTDOL0tx3mTgIPkirrxc8SrdLXO0lBQA3dsBq/MvRpLQnT3BlbkNTVyBD YXRhbG9ncyA8Y2F0YWxvZ3NAb3BlbmNzdy5vcmc+iGAEExECACAFAk4bnlACGwMG CwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRBglSj68CAzWdUmAJ0Qeydrn+zSKZhu O3MS9Xh/RP3ZRQCeMx6qgKraDpFcwie4zOdV/6WeroG5Ag0EThueUBAIAIZTBIx1 BE2IcIgyGDUz5BOJBFCKP5N7MTrmYfEeNIaY0NjGl0AKzatl26MB+GU9D18Z0o2m Y4sZiTPeNcZpDOaYCvpaB5KGSn48dhvu9n8S2Cqsckv0D4NaM6Vo3b+BJo+yKCgn nBQ4gLwwstNwoqN5UmiBAKY3YwSCloSlS+eWvXFfuwQy74fTK5OVVPNS2IijSWch 6aZqnRcevBajaea83AE6YgIgtVzMclSA7aZzVL/6Z3lC/T7mBrNhckj6v6/ITd1f FHq+xnizwZPTRxDqd5SKLqVTv1kg6yE/lIoCa2LDrx8xx5I6aTJYjYLLceuWqG5B bYtEdEtcHLICvBcABAsH/ArTGFLNIGihnoet4r90F355coL1v0DIGc9TEa7qfjyh vNq1AKUQrT65rngde1G+d6AI3mmzCF3IpAej9q6JAji38QHzXNGS68awqbGrknS/ CJp2QOvHYRgxdbUgpgv82uwIh+Qm1NZV035uU9lB4HVFiM2YFu5NAiVW7H3b9v2d 2Oc0Jcqa4F5GD/m+bMtSQA2SY4sZD5F9QZT9SkhW65w+5kyfwBgcYQe2awv67dGa 8VyETwuhQxIqUXF0I8gnks83jver08u4lEuPLYv2DkVBjrkMi/n4hMHUJ9LdAXva jP7jYpoeeDOJp9LYqNf21WdeE+NG0fqOJlIiyfmKK6GISQQYEQIACQUCThueUAIb DAAKCRBglSj68CAzWV75AKCb+ElaBqbCTPutfJoUj8RMIB7KnQCgr/gGGy9BVKlZ kWTM/wIojO/alMA= =gc0+ -----END PGP PUBLIC KEY BLOCK----- -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Jul 23 19:27:23 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 23 Jul 2011 13:27:23 -0400 Subject: [csw-maintainers] how the catalog signing works Message-ID: <1311439323-sup-2576@pinkfloyd.chass.utoronto.ca> Hi All, I'm going to be on vacation this week and I'll have little to no connectivity. As such, I'm sharing a sketch (proper documentation is still in progress) of how the catalog signing works so that if it breaks others can troubleshoot it. On the designated zone (named cswsign) there is an account named catalogsign. Anyone needing access to this account should have their ssh key seeded there. The code for the daemon is at /opt/catalog_signatures. In the directory is a README file with more details than I'll include here. The basics are that if the pass phrase expires, you should run: /opt/catalog_signatures/bin/reset_passphrase. This should connect you to the screen session where you should see a prompt from the monitoring agent. Hit Enter and then type in the passphrase. If for some reason you need to restart the whole machinery, kill the screen session entirely and then the gpg-agent process. Next, run: /opt/catalog_signatures/bin/signing_daemon. This starts up a screen session where the web daemon lives. You'll be prompted for the passphrase. Once that has been properly entered, the web daemon will be ready and then the monitoring agent will be started in a second screen terminal. Once everything is running use the 'd' (detach) command in screen to fully background everything. When you're connected to the screen session, screen 0 is the verification monitor and screen 1 is the stdout from the web daemon. These have labels on them if you use the " (quote) command in screen. Access logs for the web daemon are in /opt/catalog_signatures/log. I'll eventually move the stdout to this directory as well. The monitor cannot currently emit email so the sign of breakage at the 3 day interval will be that the generate-unstable script will die when the signature fails. Dago (at least) should get an email in this situation. The passphrase for the test key is 'secret' (which is no secret at all *g*). If you'd like more details, please let me know. I'll document this in the wiki at some point (maybe tonight if I have time). Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sun Jul 24 17:57:35 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 24 Jul 2011 16:57:35 +0100 Subject: [csw-maintainers] Shared library placement, take 3 In-Reply-To: References: <1311127984-sup-3921@pinkfloyd.chass.utoronto.ca> Message-ID: Em 22/07/2011 12:56, "Jonathan Craig" escreveu: > > 2011/7/21 Maciej Blizi?ski : > > > > Cool. There is one case which needs consideration: gcc C++ libs vs Solaris > > Studio C++ libs. If we compile the same sources with both compilers, we will > > get a soname conflict. What should we do: put gcc libs into e.g. > > /opt/csw/lib/gcc/ or append "gcc" to the soname and keep the lib in > > /opt/csw/lib? (Or is there another solution?) > > > This problem is one we will have to solve on our own as debian doesn't > face this issue AFAIK. Well I see three approaches, but there may be > more: > > 1) Place the the style of the library used by our binaries into the > common directory and the other into its own tree > (/op/csw/lib/[gcc|sunstudio]). > > PROS: Our binaries always find shared library in a single place. > Could help with customers who are forced to use LD_LIBRARY_PATH > settings. > CONS: Confusing, how is one to know which style a given library uses > beyond looking for a README. > > 2) Always place sunstudio into the common and gcc into its own tree > (or vise-versa) > > PROS: Not confusing as to which directory holds which files. Our > developers have resources to determine their RPATH needs at build > time. > CONS: LD_LIBRARY_PATH, while not recommended, should have a note about > default including all of the shared library trees. > > 3) Use the approach for poorly behaved libraries and insert a minor > release version to indicate sunstudio/gcc style library. If we always > use a most minor version component of ".999" for the gcc style then we > can force the link against the correct style. We can append anything, soname is a string. > > PROS: One shared library tree, so only one path for LD_LIBRARY_PATH users. Also, an easy to understand runtime failure mode: "Error: libfoo.so.gcc1 not found." It is obvious what file is needed. > CONS: Package construction is trickier. Possibly still confusing for > end users who are trying to build against our libraries. The .so files still need to be in a different directory, like in the libnet example. > I'm not wedded to any given approach at this time as my packages have > all been pretty straight forward. I would lean towards #2 as its the > simplest in terms of construction and should be easily understood by > our customers. The main disadvantage would be confusing failure modes. Whether the binaries would work or not, would be determined by the RPATH order, and in the case of failure, the given error message would in no way indicate what's wrong or what to do. It would be something like a missing symbol, snd not something that points to the sunstudio vs gcc issue. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Jul 24 23:14:24 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 24 Jul 2011 22:14:24 +0100 Subject: [csw-maintainers] how the catalog signing works In-Reply-To: <1311439323-sup-2576@pinkfloyd.chass.utoronto.ca> References: <1311439323-sup-2576@pinkfloyd.chass.utoronto.ca> Message-ID: Em 23/07/2011 18:27, "Ben Walton" escreveu: > The monitor cannot currently emit email (...) If it could send email, where would you plan to send it to? Perhaps a mail alias with a bunch of interested people? Something like a mailing list, but with no archives (not necessary). Thanks Ben for implementing the catalog signing! This is a tremendous contribution to the project! Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Mon Jul 25 11:09:25 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 25 Jul 2011 11:09:25 +0200 Subject: [csw-maintainers] Problem with update of latest openssh Message-ID: Hi Yann, hi have some issues with the latest update of OpenSSH in unstable: 1. Some of the files are not migrated This is true for the host keys ssh_host_* and sshd_config originally located in /etc/ssh/: > unstable9s# ls -l /etc/ssh /etc/opt/csw/ssh/ > /etc/opt/csw/ssh/: > total 547 > -rw-r--r-- 1 root other 125811 Jul 25 10:38 moduli > -rw-r--r-- 1 root bin 125811 Jul 24 04:12 moduli.CSW > -rw-r--r-- 1 root bin 1529 Mar 28 2009 ssh_config > -rw-r--r-- 1 root bin 1602 Jul 24 04:12 ssh_config.CSW > -rw------- 1 root other 672 Jul 25 10:38 ssh_host_dsa_key > -rw-r--r-- 1 root other 602 Jul 25 10:38 ssh_host_dsa_key.pub > -rw------- 1 root other 887 Jul 25 10:38 ssh_host_rsa_key > -rw-r--r-- 1 root other 222 Jul 25 10:38 ssh_host_rsa_key.pub > -rw-r--r-- 1 root other 8427 Jul 25 10:38 ssh_known_hosts > -rwxr--r-- 1 root other 2906 Jan 24 2009 sshd_config > -rw-r--r-- 1 root bin 3320 Jul 24 04:12 sshd_config.CSW > > /etc/ssh: > total 218 > -rw-r--r-- 1 root sys 88308 Jul 15 2010 moduli > -rw-r--r-- 1 root sys 861 Oct 18 2007 ssh_config > -rw------- 1 root root 672 Jan 23 2009 ssh_host_dsa_key > -rw-r--r-- 1 root root 602 Jan 23 2009 ssh_host_dsa_key.pub > -rw------- 1 root root 887 Jan 23 2009 ssh_host_rsa_key > -rw-r--r-- 1 root root 222 Jan 23 2009 ssh_host_rsa_key.pub > -rw-r--r-- 1 root root 8427 Mar 26 2010 ssh_known_hosts > -rw-r--r-- 1 root sys 5208 Jul 15 2010 sshd_config 2. Error on startup: > unstable9s# /etc/init.d/cswopenssh start > unstable9s# Could not load host key: /etc/opt/csw/ssh/ssh_host_ecdsa_key This is probably also due to using the wrong configuration file. 3. cswopenssh is down after upgrade on Solaris 9 even if it was running before I remember we talked about daemon autostart (which is false here), but AFAIR the run-status of a daemon should be kept after update. Disabling sshd on a machine can be nasty if you don't have another of accessing it. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From yann at pleiades.fr.eu.org Mon Jul 25 11:47:24 2011 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Mon, 25 Jul 2011 11:47:24 +0200 Subject: [csw-maintainers] Problem with update of latest openssh In-Reply-To: References: Message-ID: <4E2D3BAC.7010808@pleiades.fr.eu.org> Hi Dago, Le 25/07/2011 11:09, Dagobert Michelsen a ?crit : > Hi Yann, > > hi have some issues with the latest update of OpenSSH in unstable: > > 1. Some of the files are not migrated > > This is true for the host keys ssh_host_* and sshd_config originally > located in /etc/ssh/: No they are migrated from /opt/csw/etc/ssh not /etc/ssh. Do you also have the migration problem with files from /opt/csw/etc/ssh/ ? > 2. Error on startup: > >> unstable9s# /etc/init.d/cswopenssh start >> unstable9s# Could not load host key: /etc/opt/csw/ssh/ssh_host_ecdsa_key This is more a warning, the new elliptic curve algorithm needs a new host key. This will not prevent openssh from working with dsa/rsa, but will add the generation of this new host key in the init script. > 3. cswopenssh is down after upgrade on Solaris 9 even if it was running before > > I remember we talked about daemon autostart (which is false here), but AFAIR > the run-status of a daemon should be kept after update. Disabling sshd on > a machine can be nasty if you don't have another of accessing it. Concerning Solaris 9, we had a discussion and I think the problem was at this time not in openssh but in some autoenable settings but I will look into this. If there is a problem, I suspect it would probably be in the class action script but I will test this. Concerning autostart, csw openssh is configured to start at boot. You would prefer it to be autostarted by default at first install because of SUN ssh ? Thanks for having tested the package. Yann From dam at opencsw.org Mon Jul 25 12:51:51 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 25 Jul 2011 12:51:51 +0200 Subject: [csw-maintainers] Problem with update of latest openssh In-Reply-To: <4E2D3BAC.7010808@pleiades.fr.eu.org> References: <4E2D3BAC.7010808@pleiades.fr.eu.org> Message-ID: Hi Yann, Am 25.07.2011 um 11:47 schrieb Yann Rouillard: > Le 25/07/2011 11:09, Dagobert Michelsen a ?crit : >> hi have some issues with the latest update of OpenSSH in unstable: >> >> 1. Some of the files are not migrated >> >> This is true for the host keys ssh_host_* and sshd_config originally >> located in /etc/ssh/: > > No they are migrated from /opt/csw/etc/ssh not /etc/ssh. > Do you also have the migration problem with files from /opt/csw/etc/ssh/ ? Nope, everything fine. >> 3. cswopenssh is down after upgrade on Solaris 9 even if it was running before >> >> I remember we talked about daemon autostart (which is false here), but AFAIR >> the run-status of a daemon should be kept after update. Disabling sshd on >> a machine can be nasty if you don't have another of accessing it. > > Concerning Solaris 9, we had a discussion and I think the problem was at this time not in openssh but in some autoenable settings but I will look into this. > If there is a problem, I suspect it would probably be in the class action script but I will test this. > > Concerning autostart, csw openssh is configured to start at boot. You would prefer it to be autostarted by default at first install because of SUN ssh ? Sorry, I looked wrong. The existing SUNW-ssh was hidden by a start of the new ssh and I didn't have daemon autoenable=0. Sorry for the noise. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Mon Jul 25 16:54:31 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 25 Jul 2011 16:54:31 +0200 Subject: [csw-maintainers] Shared library placement, take 3 In-Reply-To: References: <1311127984-sup-3921@pinkfloyd.chass.utoronto.ca> Message-ID: <4A2F33C4-ED6E-481F-A6AD-EF5532401343@opencsw.org> Hi, Am 24.07.2011 um 17:57 schrieb Maciej Blizi?ski: > Em 22/07/2011 12:56, "Jonathan Craig" escreveu: > > > > 2011/7/21 Maciej Blizi?ski : > > > > > > Cool. There is one case which needs consideration: gcc C++ libs vs Solaris > > > Studio C++ libs. If we compile the same sources with both compilers, we will > > > get a soname conflict. What should we do: put gcc libs into e.g. > > > /opt/csw/lib/gcc/ or append "gcc" to the soname and keep the lib in > > > /opt/csw/lib? (Or is there another solution?) > > > > > This problem is one we will have to solve on our own as debian doesn't > > face this issue AFAIK. Well I see three approaches, but there may be > > more: > > > > 1) Place the the style of the library used by our binaries into the > > common directory and the other into its own tree > > (/op/csw/lib/[gcc|sunstudio]). > > > > PROS: Our binaries always find shared library in a single place. > > Could help with customers who are forced to use LD_LIBRARY_PATH > > settings. > > CONS: Confusing, how is one to know which style a given library uses > > beyond looking for a README. > > > > 2) Always place sunstudio into the common and gcc into its own tree > > (or vise-versa) > > > > PROS: Not confusing as to which directory holds which files. Our > > developers have resources to determine their RPATH needs at build > > time. > > CONS: LD_LIBRARY_PATH, while not recommended, should have a note about > > default including all of the shared library trees. > > > > 3) Use the approach for poorly behaved libraries and insert a minor > > release version to indicate sunstudio/gcc style library. If we always > > use a most minor version component of ".999" for the gcc style then we > > can force the link against the correct style. > > We can append anything, soname is a string. > > > PROS: One shared library tree, so only one path for LD_LIBRARY_PATH users. > > Also, an easy to understand runtime failure mode: > "Error: libfoo.so.gcc1 not found." It is obvious what file is needed. > > > CONS: Package construction is trickier. Possibly still confusing for > > end users who are trying to build against our libraries. > > The .so files still need to be in a different directory, like in the libnet example. > > > I'm not wedded to any given approach at this time as my packages have > > all been pretty straight forward. I would lean towards #2 as its the > > simplest in terms of construction and should be easily understood by > > our customers. > > The main disadvantage would be confusing failure modes. Whether the binaries would work or not, would be determined by the RPATH order, and in the case of failure, the given error message would in no way indicate what's wrong or what to do. It would be something like a missing symbol, snd not something that points to the sunstudio vs gcc issue. Rewriting the soname or other linker information is really hard to build into the process. For adding AUX linkage to GAR I make a build, then remove libraries one by one, set for each one a linker adjustment variable and restart the build. This is obivously pretty ugly. Before going this path we must find a simpler approach or this path is dead. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Mon Jul 25 22:11:21 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 25 Jul 2011 21:11:21 +0100 Subject: [csw-maintainers] Shared library placement, take 3 In-Reply-To: <4A2F33C4-ED6E-481F-A6AD-EF5532401343@opencsw.org> References: <1311127984-sup-3921@pinkfloyd.chass.utoronto.ca> <4A2F33C4-ED6E-481F-A6AD-EF5532401343@opencsw.org> Message-ID: Em 25/07/2011 15:54, "Dagobert Michelsen" escreveu: > > Hi, > > Am 24.07.2011 um 17:57 schrieb Maciej Blizi?ski: > > Em 22/07/2011 12:56, "Jonathan Craig" escreveu: > > > > > > 2011/7/21 Maciej Blizi?ski : > > > > > > > > Cool. There is one case which needs consideration: gcc C++ libs vs Solaris > > > > Studio C++ libs. If we compile the same sources with both compilers, we will > > > > get a soname conflict. What should we do: put gcc libs into e.g. > > > > /opt/csw/lib/gcc/ or append "gcc" to the soname and keep the lib in > > > > /opt/csw/lib? (Or is there another solution?) > > > > > > > This problem is one we will have to solve on our own as debian doesn't > > > face this issue AFAIK. Well I see three approaches, but there may be > > > more: > > > > > > 1) Place the the style of the library used by our binaries into the > > > common directory and the other into its own tree > > > (/op/csw/lib/[gcc|sunstudio]). > > > > > > PROS: Our binaries always find shared library in a single place. > > > Could help with customers who are forced to use LD_LIBRARY_PATH > > > settings. > > > CONS: Confusing, how is one to know which style a given library uses > > > beyond looking for a README. > > > > > > 2) Always place sunstudio into the common and gcc into its own tree > > > (or vise-versa) > > > > > > PROS: Not confusing as to which directory holds which files. Our > > > developers have resources to determine their RPATH needs at build > > > time. > > > CONS: LD_LIBRARY_PATH, while not recommended, should have a note about > > > default including all of the shared library trees. > > > > > > 3) Use the approach for poorly behaved libraries and insert a minor > > > release version to indicate sunstudio/gcc style library. If we always > > > use a most minor version component of ".999" for the gcc style then we > > > can force the link against the correct style. > > > > We can append anything, soname is a string. > > > > > PROS: One shared library tree, so only one path for LD_LIBRARY_PATH users. > > > > Also, an easy to understand runtime failure mode: > > "Error: libfoo.so.gcc1 not found." It is obvious what file is needed. > > > > > CONS: Package construction is trickier. Possibly still confusing for > > > end users who are trying to build against our libraries. > > > > The .so files still need to be in a different directory, like in the libnet example. > > > > > I'm not wedded to any given approach at this time as my packages have > > > all been pretty straight forward. I would lean towards #2 as its the > > > simplest in terms of construction and should be easily understood by > > > our customers. > > > > The main disadvantage would be confusing failure modes. Whether the binaries would work or not, would be determined by the RPATH order, and in the case of failure, the given error message would in no way indicate what's wrong or what to do. It would be something like a missing symbol, snd not something that points to the sunstudio vs gcc issue. > > Rewriting the soname or other linker information is really hard to build into the > process. For adding AUX linkage to GAR I make a build, then remove libraries one by one, > set for each one a linker adjustment variable and restart the build. This is > obivously pretty ugly. Before going this path we must find a simpler approach or > this path is dead. Why rewriting? It would probably be my last choice. It is cleaner to patch the sources to modify the soname right from the beginning. Patching sources might be trivial or hard depending on the build system, but I expect that it is possible to teach checkpkg to detect whether built sonames have the right format. This way, it would be clear for the maintainer, whether they got it right or not. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Wed Jul 27 23:15:44 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 27 Jul 2011 23:15:44 +0200 Subject: [csw-maintainers] Vacation Message-ID: <653BCD4E-AB32-46CD-9973-0ADC4B635A9E@opencsw.org> Hi folks, I'll be away for the next 10 days and try to go to "deep-relexation mode" without internet. If you encounter any issues with the farm please mail to buildfarm@, my colleague Jan (|woody| on irc) is on the list too to take care of things. Best regards and cu then -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From ihsan at opencsw.org Thu Jul 28 10:18:30 2011 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Thu, 28 Jul 2011 10:18:30 +0200 Subject: [csw-maintainers] Vacation In-Reply-To: <653BCD4E-AB32-46CD-9973-0ADC4B635A9E@opencsw.org> References: <653BCD4E-AB32-46CD-9973-0ADC4B635A9E@opencsw.org> Message-ID: <4E311B56.8060907@opencsw.org> Hello Dago, On 07/27/11 11:15 PM, Dagobert Michelsen wrote: > I'll be away for the next 10 days and try to go to "deep-relexation mode" without > internet. If you encounter any issues with the farm please mail to buildfarm@, > my colleague Jan (|woody| on irc) is on the list too to take care of things. 10 days without Internet? Are you sure that you are going to survive this? ;-) Enjoy your holidays! Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bonivart at opencsw.org Thu Jul 28 17:30:09 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 28 Jul 2011 17:30:09 +0200 Subject: [csw-maintainers] What's up with ceeswi? Message-ID: Not sure for how long but ceeswi seems to aggregate twitter posts about OpenCSW multiple times which is annoying enough but especially bad right now since some masochistic dude is leaving OpenCSW to use Gentoo on Solaris instead. 02:09| opencsw at twitter: @taxi1729 I'm migrating from #OpenCSW to Gentoo Prefix || @kstailey_caci What are you planning to migrate to instead of #opencsw ? || Abandoning OpenCSW has begun. 11:30| opencsw at twitter: @taxi1729 I'm migrating from #OpenCSW to Gentoo Prefix || @kstailey_caci What are you planning to migrate to instead of #opencsw ? || Abandoning OpenCSW has begun. 16:02| opencsw at twitter: @taxi1729 I'm migrating from #OpenCSW to Gentoo Prefix || @kstailey_caci What are you planning to migrate to instead of #opencsw ? || Abandoning OpenCSW has begun. 17:23| opencsw at twitter: @taxi1729 I'm migrating from #OpenCSW to Gentoo Prefix || @kstailey_caci What are you planning to migrate to instead of #opencsw ? || Abandoning OpenCSW has begun. As you can see no updates and it still echoes it every other hour. If it's not fixed I prefer we have that feature off. /peter From maciej at opencsw.org Thu Jul 28 23:26:09 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 28 Jul 2011 22:26:09 +0100 Subject: [csw-maintainers] What's up with ceeswi? In-Reply-To: References: Message-ID: Em 28/07/2011 16:30, "Peter Bonivart" escreveu: > > Not sure for how long but ceeswi seems to aggregate twitter posts > about OpenCSW multiple times which is annoying enough but especially > bad right now since some masochistic dude is leaving OpenCSW to use > Gentoo on Solaris instead. It must be an interesting exercise. I'm curious what is he building, and whether the results will be published. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From skayser at opencsw.org Sat Jul 30 13:00:41 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Sat, 30 Jul 2011 13:00:41 +0200 (CEST) Subject: [csw-maintainers] What's up with ceeswi? In-Reply-To: References: Message-ID: <3388.83.113.70.59.1312023641.squirrel@ssl.skayser.de> Hi guys, Peter Bonivart wrote: > Not sure for how long but ceeswi seems to aggregate twitter posts > about OpenCSW multiple times which is annoying enough but especially > bad right now since some masochistic dude is leaving OpenCSW to use > Gentoo on Solaris instead. sorry for the late reply, similar to Dago I've gone on vacations w/o internet. If ceeswi is still an issue, just ban her from the channel. I'll be back on the 8th of August. We can see what went wrong and migrate her to OpenCSW infrastructure then. Sebastian From maciej.blizinski at gmail.com Wed Jul 6 10:06:23 2011 From: maciej.blizinski at gmail.com (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 06 Jul 2011 08:06:23 -0000 Subject: [csw-maintainers] Code and package reviews In-Reply-To: <1309827865-sup-9084@pinkfloyd.chass.utoronto.ca> References: <1309827865-sup-9084@pinkfloyd.chass.utoronto.ca> Message-ID: Em 05/07/2011 02:22, "Ben Walton" escreveu: > > Excerpts from Maciej Blizi?ski's message of Mon Jun 13 06:05:41 -0400 2011: > > > Our aim is to build a culture in which peer review is one of the key > > elements. There needs to be an environment which encourages peer > > reviews and makes them easy. > > A thought I had on the train tonight is that review could begin with > the maintainer detailing the following changes for a package release: > > 1. Version info. > 2. Changed configure options (if any). > 3. Overrides used and why. > 4. New or removed patches and their function. > 5. Filesystem layout changes and how they're gracefully handled. > > Having the maintainer lay this info out clearly to kickstart the > discussion does a few things: > > 1. Makes the maintainer think about the changes in a package at a > level higher than the build recipe. > 2. Gives other maintainers insight into hot spots to review if they > want to look in more depth. Sounds good. Would that be on the devel or the maintainers list? I once had a bit of code that was creating a list of code commits that fall between releases. A tool like this could be used to start a review email. I also had an idea for a better package diff tool, which was basically a different of two formatted python data structures. One of the issues was to sort all the output so that the diff is meaningful. I am on vacations this week; will provide more feedback when I get back. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej.blizinski at gmail.com Wed Jul 6 10:06:26 2011 From: maciej.blizinski at gmail.com (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 06 Jul 2011 08:06:26 -0000 Subject: [csw-maintainers] Assessing catalog quality In-Reply-To: <1309829862-sup-6372@pinkfloyd.chass.utoronto.ca> References: <4E070436.7080407@opencsw.org> <1309829862-sup-6372@pinkfloyd.chass.utoronto.ca> Message-ID: Em 05/07/2011 02:42, "Ben Walton" escreveu: > > Excerpts from Trygve Laugst?l's message of Sun Jun 26 06:04:38 -0400 2011: > > > Number of overrides is one thing that comes to mind. > > While I agree that this is something to keep an eye on, there would > need to be some sort of weighting factor used as judicious use of > overrides can improve quality. > > Things to consider (possibly fictional error tags): > > CHECKPKG_OVERRIDE_CSWfoo += bad-path|/var/mypkg > vs > CHECKPKG_OVERRIDE_CSWfoo += bad-path > > The first overrides a single bad path but the second overrides every > bad path...same number of overrides, but (possibly) very different > package quality. > > Also, overriding /usr/local references in share/doc/foo/ isn't as bad > as putting sparc binaries in an i386 package, etc... > > Weighting the tags would help, but that's a big job in and of > itself...is it worthwhile for this? Different overrides mean different things. We could monitor selected overrides. As far as specific / nonspecific overrides, it would be a good enough approximation to tag on a per package basis: X packages with the foo-bar override, specific or not, with multiple instances or not. To get started, we could monitor and plot some metrics without assigning any specific meaning or a interpretation to them just yet. When more data come in, the interpretation will be easier. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej.blizinski at gmail.com Wed Jul 6 18:07:28 2011 From: maciej.blizinski at gmail.com (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 06 Jul 2011 16:07:28 -0000 Subject: [csw-maintainers] Use of testing* In-Reply-To: <1219AD39-B607-4ACB-B6F6-70A762F31F72@opencsw.org> References: <201106292024.p5TKOi1P008545@login.bo.opencsw.org> <1309892637-sup-4928@pinkfloyd.chass.utoronto.ca> <1219AD39-B607-4ACB-B6F6-70A762F31F72@opencsw.org> Message-ID: Em 06/07/2011 16:25, "Dagobert Michelsen" escreveu: > > Hi, > > Am 05.07.2011 um 21:05 schrieb Ben Walton: > > Excerpts from Peter Bonivart's message of Tue Jul 05 14:13:08 -0400 2011: > >>> Darn... I looked in i386. This raises the question of the 2 testing > >>> platforms: are they identical? Me think that no. > >> > >> You're right: > > > > These boxes aren't really "maintained" as much as the current and > > unstable hosts. They're basically: > > > > I need this, so I install it. That doesn't get applied evenly. The > > nature of their use doesn't lend itself to applying updates across the > > board either, although we could definitely improve that. > > I suggest leave it that way for testing* and set up a new set of machines > for project specific work, like project* similar to what we have. Checkpkg derives the catalog name (e.g.current or unstable) from the host name. It will be necessary to set CATALOG_NAME in system wide garrc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadud3 at gmail.com Fri Jul 8 22:58:05 2011 From: vadud3 at gmail.com (Asif Iqbal) Date: Fri, 08 Jul 2011 20:58:05 -0000 Subject: [csw-maintainers] [board] [Mantis] Account registration In-Reply-To: <1309979186-sup-9810@pinkfloyd.chass.utoronto.ca> References: <1309884703-sup-1267@pinkfloyd.chass.utoronto.ca> <1309913219-sup-4680@pinkfloyd.chass.utoronto.ca> <1309977657-sup-28@pinkfloyd.chass.utoronto.ca> <1309979186-sup-9810@pinkfloyd.chass.utoronto.ca> Message-ID: Hi All, I like to introduce myself to the mailing list. I have been using Solaris since 2000 and using hobbit monitoring tool, now called xymon (xymon.com) since 2004. I noticed opencsw.org has the hobbit pkg 4.2 which is from 2006. Since I heavily depend on csw (started with blastwave) I was looking for a new hobbit pkg. So I volunteered to try to make xymon pkg and maintain. I have built hobbit pkg for our company but that is not easy to maintain. I used the sun doc to build the pkg and it works fine. However I rather join a mature community like this one and maintain it in csw repo using the method designed to follow. It will definitely benefit us. Thanks for the opportunity. Lets hope I don't screw it up :-) Sorry about the top posting. I thought it is a new email and I like to keep the thread below to show how I entered into this community. On Wed, Jul 6, 2011 at 3:07 PM, Ben Walton wrote: > Excerpts from Asif Iqbal's message of Wed Jul 06 14:53:10 -0400 2011: > >> I was trying to click the sign in. But it is not necessary anymore. > > Ah. ?Ok. > >> I added a .forward file in mail.opencsw.org to send all my mails to >> vadud3+csw at gmail.com > > Cool. ?Feel free to say hi on the maintainers@ mailing list. ?Maybe > introduce yourself and indicate which package(s) you're planning to > build. ?(This is optional of course, but there are lots of folks that > read the lists but don't hang out in irc.) > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? From maciej.blizinski at gmail.com Sat Jul 9 12:43:55 2011 From: maciej.blizinski at gmail.com (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 09 Jul 2011 10:43:55 -0000 Subject: [csw-maintainers] ideas In-Reply-To: <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> References: <1309827347-sup-4348@pinkfloyd.chass.utoronto.ca> <1310062947-sup-1843@pinkfloyd.chass.utoronto.ca> <1310082708-sup-260@pinkfloyd.chass.utoronto.ca> <1310170504-sup-3326@pinkfloyd.chass.utoronto.ca> Message-ID: Em 09/07/2011 02:16, "Ben Walton" escreveu: > > Excerpts from Maciej Blizi?ski's message of Fri Jul 08 13:06:39 -0400 2011: > > Hi Maciej, > > > Another thought: perhaps it would not be that hard to implement a > > POC of automatic catalog signing. For example: a machine in a > > private network, controlled by a trusted person runs gpg agent with > > a timeout in the order of 3 days to a week. A cron job running on > > that machine pulls the catalog file, signs it and pushes it back for > > the rest of the automation to pick it up. > > This is a good idea. I've been contemplating the design of such a > system for a few days now. > > > At this point, there is a problem, that there is no verification > > that the catalog pulled can be trusted. To fix that, we can > > I think something more 'on demand' is better suited here as that lends > itself to better atomicity which will be important. I'm thinking > something along the lines of: > > Just before a mirror push is about to happen, something opens a socket > to a daemon and says "please sign catalog current/i386/5.9 having sha1 > $sha1." The daemon would then grab the catalog from a preset > location, ensure the sha1 matches and sign it. > > The signature is then returned over the socket and the caller is > responsible for placing it appropriately with the files. > > Having things designed like this removes some possible security > issues. > > 1. If the client can only request catalog signatures based on the > tuple (catalog, arch, os release) and the daemon then goes and > reads the file from a run-time specified or hard coded directory, > the client cannot get 'just anything' signed. > 2. Making the client responsible for placing the signature data means > that, given 1, we don't need to protect the daemon with encryption, > authentication, etc, as getting a catalog signature for a valid > catalog is public data that will be available on the mirrors > anyway. It also removes privilege from the daemon so that it needs > read-only access to the data it will sign. > > If the client has enough access to manipulate the directory structure > that the daemon will read, it can make the daemon sign a manipulated > catalog. This level of compromise means things are already in bad > shape though, so it shouldn't be worse than the risks we have today. > > The daemon would, as you suggest, need a timeout so that a human needs > to re-initialize the agent storing the pass phrase periodically and it > could tell the caller if it was unable to perform signatures. > > I'm willing to code the daemon. > > With such a signing daemon in place, we can have a cron job running as > a dedicated catalog/mirror maintenance uid that has the access needed > to place catalogs and signatures and push to the live mirror area...It > will update catalogs, get them signed, etc. If the release proposal > is accepted, this job could also be the one that moves things from > unstable to current. > > As a side note, I'd like to mention to a wider audience than irc: I > think our signatures should be detached instead of clear signed. > These are nicer to work with all around. It would require > coordinating a pkgutil update though. > > > introduce signing of individual .pkg and .pkg.gz files. The script > > pulls not only the catalog file, but also the data files. It > > verifies that all files referenced in the index (the catalog file) > > are properly signed. If not, it complaints loudly. If yes, it > > proceeds with signing. > > This can be a separate topic, but I think it is something to look at. > The biggest hurdle here is ensuring that everyone gets a gpg key > created for this purpose and that we distribute the public portions of > the keys to client systems for verification. This could be tied into > CSWcswpki that I've already laid groundwork for. > > > The signatures could be uploaded with csw-upload-pkg. > > Detached signatures for this would be best too. > > > I do not have a good idea where to store the signatures. I can > > imagine an appendix to the catalog that lives in a parallel > > directory, or a subdirectory of e.g. unstable/sparc/5.9 > > CSWcswpki should pull them down and install them in a private keyring. > > > There also is the (independent) problem of key revocation, presented > > in detail by William in Dublin. > > Revoking a catalog signing key is different from revoking a maintainer > signing key. If we revoke a catalog key, we can regenerate a new > catalog with the new key. We may not be able to easily regenerate > signatures for all packages if the need arises. If we sign packages > individually, we may want to use a generic (but different than the > catalog signer) key for this purpose too. > > > The two stage implementation outlined above gives us the advantage > > that we can be back quickly and we can we have a plan how to improve > > the security chain between an individual maintainer and the user. > > Agreed. > > Thoughts? Yes, here are some more. I like both ideas: the signing system initiating the connection (easier to secure it), and the buildfarm deciding when to sign. I have two alternative ideas. 1. The signing system listens, but the handling code is super simple, only sets a flag. Then the cron job notices it, and signing occurs. 2. The flag is set on buildfarm side, there is no listener on the signing side. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert.thurner at gmail.com Sun Jul 10 16:06:59 2011 From: rupert.thurner at gmail.com (rupert THURNER) Date: Sun, 10 Jul 2011 14:06:59 -0000 Subject: [csw-maintainers] subversion python bindings not working? Message-ID: on login.opencsw.org i tried to do: hg clone https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/subversion/trunk and got: Please install either Subvertpy or the Subversion Python SWIG bindings! is this a fault in the subversion package, or the installation on login? rupert From rupert.thurner at gmail.com Mon Jul 11 08:43:11 2011 From: rupert.thurner at gmail.com (rupert THURNER) Date: Mon, 11 Jul 2011 06:43:11 -0000 Subject: [csw-maintainers] mercurial 1.9, how long does it take? Message-ID: how long does it take that the new mercurial hg-1.9 package shows up on our website, e.g. http://www.opencsw.org/packages/mercurial ? rupert. From rupert.thurner at gmail.com Sun Jul 17 23:04:17 2011 From: rupert.thurner at gmail.com (rupert THURNER) Date: Sun, 17 Jul 2011 21:04:17 -0000 Subject: [csw-maintainers] gar download from launchpad? Message-ID: what is the reason that this download link does not work, i.e. it does not try http: MASTER_SITES = http://launchpad.net/subvertpy/trunk/$(VERSION)/+download DISTFILES = $(DISTNAME).tar.gz rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej.blizinski at gmail.com Tue Jul 19 12:54:28 2011 From: maciej.blizinski at gmail.com (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 19 Jul 2011 10:54:28 -0000 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: References: Message-ID: Em 18/07/2011 14:02, escreveu: > > Maciej Blizi?ski writes: > > Peter, would you like to resume your participation in the policy team? > > Of course I wish to. I think that we should start from where we left the > discussion before it was polluted, i.e., the copyright and the > abstract. Taking on the Debian policy document and adapting it to our > specifics but not more. Excellent! I have since looked at sphinx, a higher level tool which helps with structured documentation. It uses reStructured Text as the lightweight markup language. I will send the patch and a link to an example when I'm back home at the beginning of August. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert.thurner at gmail.com Wed Jul 20 13:17:38 2011 From: rupert.thurner at gmail.com (rupert THURNER) Date: Wed, 20 Jul 2011 11:17:38 -0000 Subject: [csw-maintainers] apr, apr-util In-Reply-To: References: Message-ID: On Wed, Jul 20, 2011 at 12:49, Dagobert Michelsen wrote: > Hi Rupert, > > Am 19.07.2011 um 23:28 schrieb rupert THURNER: >> i tried to change apr, and apr-util as well ... but i seem to have the >> same problem with obsoleting again. what did i do wrong, here the >> apr-util example: >> >> http://sourceforge.net/apps/trac/gar/changeset/15126/csw/mgar/pkg/apr-util/trunk/Makefile > > You are trying to obsolete CSWlibaprutil which does not exist. Additionally, the > private shared libraries in lib/apr-util-1 are needed for libaprutil-1.so.0. For the > devel package I would recommend naming it after the library package as there is no > longer a base apr-util where it would be devel for. This has all been fixed in > ?http://sourceforge.net/apps/trac/gar/changeset/15147 > and the packages have been released to unstable/: > > apr_util_stub-1.3.12,REV=2011.07.20-SunOS5.9-all-CSW.pkg.gz > libaprutil1_0-1.3.12,REV=2011.07.20-SunOS5.9-i386-CSW.pkg.gz > libaprutil1_0-1.3.12,REV=2011.07.20-SunOS5.9-sparc-CSW.pkg.gz > libaprutil_dev-1.3.12,REV=2011.07.20-SunOS5.9-i386-CSW.pkg.gz > libaprutil_dev-1.3.12,REV=2011.07.20-SunOS5.9-sparc-CSW.pkg.gz thanks a lot dago! as apr was always fine and no need to change anything which was fine, i thought it might be appropriate to just ignore the error messages of checkpkg ... but it does not let. despite CHECKPKG_OVERRIDES_CSWapr += shared-lib-pkgname-mismatch|sonames=libapr-1.so.0|pkgname=CSWapr|expected=CSWlibapr10,CSWlibapr1-0| in the recipe checkpkg wants it again, resp complains. # Checkpkg suggests adding the following lines to the GAR recipe: # This is a summary; see above for details. # (If CSWapr-dev doesn't exist yet) PACKAGES += CSWapr-dev PKGFILES_CSWapr-dev += /opt/csw/lib/libapr-1.so CATALOGNAME_CSWapr-dev = apr_dev # (If CSWapr-dev doesn't exist yet) PACKAGES += CSWapr-dev PKGFILES_CSWapr-dev += /opt/csw/lib/sparcv9/libapr-1.so CATALOGNAME_CSWapr-dev = apr_dev If any of the reported errors were false positives, you can override them pasting the lines below to the GAR recipe. CHECKPKG_OVERRIDES_CSWapr += shared-lib-pkgname-mismatch|sonames=libapr-1.so.0|pkgname=CSWapr|expected=CSWlibapr10,CSWlibapr1-0| Please note that checkpkg isn't suggesting you should simply add these overrides do the Makefile. It only informs what the overrides could look like. You need to understand what are the reported issues about and use your best judgement to decide whether to fix the underlying problems or override them. For more information, scroll up and read the detailed messages. WARNING: Some overrides did not match any errors. They can be removed, as they don't take any effect anyway. If you're getting errors at the same time, maybe you didn't specify the overrides correctly. * Unused Override: CSWapr: shared-lib-pkgname-mismatch sonames=libapr-1.so.0 pkgname=CSWapr expected=CSWlibapr10,CSWlibapr1-0 gmake: *** [pkgcheck] Error 2 From rupert.thurner at gmail.com Wed Jul 20 18:00:01 2011 From: rupert.thurner at gmail.com (rupert THURNER) Date: Wed, 20 Jul 2011 16:00:01 -0000 Subject: [csw-maintainers] progress report In-Reply-To: References: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca> Message-ID: What is the plan for the packages maintained by phil? Am 20.07.2011 16:12 schrieb "Maciej Blizi?ski" : > Em 20/07/2011 03:10, "Ben Walton" escreveu: >> >> >> Hi All, >> >> At this point, I'm fairly happy with the gpg signing daemon. You >> should be able to request a signed (with a dummy key) catalog on the >> buildfarm by doing: >> >> curl -s >> http://192.168.1.40:9981/clearsign/opencsw-future/unstable/i386/5.9 >> >> Valid urls for the daemon are: >> >> /(clearsign|detachsign)/(opencsw|opencsw-future)/(unstable|current)/... >> >> Give it a kick and see for yourself. >> >> The code is in a git repository: >> gitosis at mirror.opencsw.org:cswsign.git >> >> We don't have gitweb enabled there, but if you want access, I'll add >> your public key so you can check it out. We could host this in the >> github/opencsw framework that Rupert has been working on if that's >> considered better (likely). >> >> Additionally, I've written a basic script to integrate this feature >> with the script that is currently generating the catalogs for >> opencsw-future/unstable. I still need to plug it in, but the basics >> are in place now. >> >> The remaining pieces for automated signing are: >> >> 1. Enable outbound mail notification from cswsign on the buildfarm. >> 2. Integrate the generate-catalog script into generate-unstable. >> 3. Activate. >> >> This will leave two major automation tasks remaining: >> >> 1. Mantis integration. >> 2. Promotion from unstable to current. (depends on 1) >> >> If I understand correctly, Maciej re-integrated current and unstable >> before leaving for vacation. That means that packages newly pushed to >> unstable can (when #2 is ready) be promoted as appropriate to current. > > Yes, I have integrated unstable into dublin. I'll explain a bit about how I > organized catalogs, so that we all use the same terminology. If anyone > objects to the way I did it, please say. Here go the details. > > There are 2 places that hold catalog information: files on disk, visible at > mirror.opencsw.org, and the buildfarm database, visible through > buildfarm.opencsw.org. Information migration is possible in both > directions. On the disk, there are two places, 'opencsw' and > 'opencsw-future'. They also differ. 'opencsw' represents the old state as of > the last time the former release manager touched it. 'opencsw-future' holds > the proposed new structure. > > Some catalogs are the same in both places, for example unstable and dublin. > However, some aren't, notably current is not the same in opencsw-future and > in the DB. > > In opencsw-future, we integrate from unstable into a named release. > Currently, the named release is "dublin". We also talked about "testing". In > opencsw-future, testing is (can be) an alias for the named release we're > currently working on. > > There is no concept of an alias in the database. That's why there is no > "testing" there. > > We provide the URL ending in "current" for backward compatibility. There is > also a catalog named "current" in the database, but it contains a snapshot > of current on the official mirror. Perhaps we should rename it (in the DB) > to "current-legacy" to make it explicit that it is not what we serve from > .../opencsw-future/current/. > > Back to catalog signing, I suggest that we say "we sign unstable and dublin" > or "we sign unstable and testing". Let "current" become a term denoting a > legacy URL. > > I hope it makes sense to you. If it doesn't, or you need more information, > please say. > > I am excited about the upcoming signing automation. I feel we are close to > completing the new workflow which will make it easy to move forward. We have > a number of new ideas in the pipeline, from me it will be new Python > versions, reworked PostgreSQL and new MySQL version. > > Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej.blizinski at gmail.com Mon Jul 25 22:07:46 2011 From: maciej.blizinski at gmail.com (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 25 Jul 2011 20:07:46 -0000 Subject: [csw-maintainers] Shared library placement, take 3 In-Reply-To: <4A2F33C4-ED6E-481F-A6AD-EF5532401343@opencsw.org> References: <1311127984-sup-3921@pinkfloyd.chass.utoronto.ca> <4A2F33C4-ED6E-481F-A6AD-EF5532401343@opencsw.org> Message-ID: Em 25/07/2011 15:54, "Dagobert Michelsen" escreveu: > > Hi, > > Am 24.07.2011 um 17:57 schrieb Maciej Blizi?ski: > > Em 22/07/2011 12:56, "Jonathan Craig" escreveu: > > > > > > 2011/7/21 Maciej Blizi?ski : > > > > > > > > Cool. There is one case which needs consideration: gcc C++ libs vs Solaris > > > > Studio C++ libs. If we compile the same sources with both compilers, we will > > > > get a soname conflict. What should we do: put gcc libs into e.g. > > > > /opt/csw/lib/gcc/ or append "gcc" to the soname and keep the lib in > > > > /opt/csw/lib? (Or is there another solution?) > > > > > > > This problem is one we will have to solve on our own as debian doesn't > > > face this issue AFAIK. Well I see three approaches, but there may be > > > more: > > > > > > 1) Place the the style of the library used by our binaries into the > > > common directory and the other into its own tree > > > (/op/csw/lib/[gcc|sunstudio]). > > > > > > PROS: Our binaries always find shared library in a single place. > > > Could help with customers who are forced to use LD_LIBRARY_PATH > > > settings. > > > CONS: Confusing, how is one to know which style a given library uses > > > beyond looking for a README. > > > > > > 2) Always place sunstudio into the common and gcc into its own tree > > > (or vise-versa) > > > > > > PROS: Not confusing as to which directory holds which files. Our > > > developers have resources to determine their RPATH needs at build > > > time. > > > CONS: LD_LIBRARY_PATH, while not recommended, should have a note about > > > default including all of the shared library trees. > > > > > > 3) Use the approach for poorly behaved libraries and insert a minor > > > release version to indicate sunstudio/gcc style library. If we always > > > use a most minor version component of ".999" for the gcc style then we > > > can force the link against the correct style. > > > > We can append anything, soname is a string. > > > > > PROS: One shared library tree, so only one path for LD_LIBRARY_PATH users. > > > > Also, an easy to understand runtime failure mode: > > "Error: libfoo.so.gcc1 not found." It is obvious what file is needed. > > > > > CONS: Package construction is trickier. Possibly still confusing for > > > end users who are trying to build against our libraries. > > > > The .so files still need to be in a different directory, like in the libnet example. > > > > > I'm not wedded to any given approach at this time as my packages have > > > all been pretty straight forward. I would lean towards #2 as its the > > > simplest in terms of construction and should be easily understood by > > > our customers. > > > > The main disadvantage would be confusing failure modes. Whether the binaries would work or not, would be determined by the RPATH order, and in the case of failure, the given error message would in no way indicate what's wrong or what to do. It would be something like a missing symbol, snd not something that points to the sunstudio vs gcc issue. > > Rewriting the soname or other linker information is really hard to build into the > process. For adding AUX linkage to GAR I make a build, then remove libraries one by one, > set for each one a linker adjustment variable and restart the build. This is > obivously pretty ugly. Before going this path we must find a simpler approach or > this path is dead. Why rewriting? It would be my last choice. It is cleaner to patch the sources to modify the soname right from the beginning. Patching sources might be trivial or hard depending on the build system, but I expect that it is possible to teach checkpkg to detect whether built sonames have the right format. This way, it would be clear for the maintainer, whether they got it right or not. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: