From rupert at opencsw.org Mon Nov 1 07:32:17 2010 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 1 Nov 2010 07:32:17 +0100 Subject: [csw-maintainers] dago's helper script into some base package? In-Reply-To: References: Message-ID: hi, would it make sense to include dago's helper script: http://www.opencsw.org/2010/09/which-csw-packages-have-been-installed/ into some basic package, like pkg-get or pkg-util? rupert. From rupert at opencsw.org Mon Nov 1 07:53:47 2010 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 1 Nov 2010 07:53:47 +0100 Subject: [csw-maintainers] apache2, 2.2.17, checkpkg error Message-ID: hi, i tried to build apache2, 2.2.17 with "gmake clean plaforms", but it refuses to build with an error: CHECKPKG_OVERRIDES_CSWap2suexec += dependency-listed-more-than-once|CSWapache2 i included it into the makefile, but it anyway gets this error. can this be the "platforms" target of gar as well, as it failed on build9x, but executed with $ gmake remerge repackage it went through? kr, rupert. From bonivart at opencsw.org Mon Nov 1 09:18:22 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 1 Nov 2010 09:18:22 +0100 Subject: [csw-maintainers] dago's helper script into some base package? In-Reply-To: References: Message-ID: On Mon, Nov 1, 2010 at 7:32 AM, rupert THURNER wrote: > hi, would it make sense to include dago's helper script: > http://www.opencsw.org/2010/09/which-csw-packages-have-been-installed/ > into some basic package, like pkg-get or pkg-util? I have talked to Dago about it and it will be in the next version of pkgutilplus as a separate script or directly in pkgutil as an option. /peter From bwalton at opencsw.org Mon Nov 1 14:04:19 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 01 Nov 2010 09:04:19 -0400 Subject: [csw-maintainers] apache2, 2.2.17, checkpkg error In-Reply-To: References: Message-ID: <1288616613-sup-1036@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Mon Nov 01 02:53:47 -0400 2010: Hi Rupert, > CHECKPKG_OVERRIDES_CSWap2suexec += > dependency-listed-more-than-once|CSWapache2 I suspect this is due to use of AP2MOD = 1 in gar. I'll look into it...the ap2mod stuff is likely to change though. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Mon Nov 1 15:55:12 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 1 Nov 2010 15:55:12 +0100 Subject: [csw-maintainers] Amarok still runnable? Message-ID: Hi, I updated taglib to have taglib_gcc contain the gcc3-build in /opt/csw/kde-gcc and taglib to contain a nice newstyle library: http://buildfarm.opencsw.org/experimental.html#taglib Could please someone verify that Amarok is still runnable? It does not work for me, but I don't have a full Solaris desktop, so that may be my issue... Best regards -- Dago From bwalton at opencsw.org Mon Nov 1 15:55:42 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 01 Nov 2010 10:55:42 -0400 Subject: [csw-maintainers] package naming conventions for addons to other packages In-Reply-To: References: <20101027084904.GA155@bender.opencsw.org> <1288179019-sup-4933@pinkfloyd.chass.utoronto.ca> Message-ID: <1288623283-sup-3439@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Sat Oct 30 10:55:16 -0400 2010: > Do you, as an active foundation maintainer, agree to relive the > current limit of packages name from the current 20 characters to the > 32 characters defined by the current packaging system? Yes, this has my support. We should 'take' as much space as we possibly can for our use instead of imposing _any_ artificial restrictions. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Mon Nov 1 16:43:42 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 1 Nov 2010 08:43:42 -0700 Subject: [csw-maintainers] package naming conventions for addons to other packages In-Reply-To: References: <20101027084904.GA155@bender.opencsw.org> <1288179019-sup-4933@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Oct 30, 2010 at 7:55 AM, Peter FELECAN wrote: >... > Thus, here is the reformulated call for vote: > > Do you, as an active foundation maintainer, agree to relive the current > limit of packages name from the current 20 characters to the 32 > characters defined by the current packaging system? > That is more reasonable. And something I can actually support, myself. That being said, I dont think it appropriate to change it, without some notice and call for discussion from the full user base. I'll post something to announce, and users. I think a minimum wait of 2 weeks for any feedback is appropriate. From phil at bolthole.com Mon Nov 1 16:52:54 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 1 Nov 2010 08:52:54 -0700 Subject: [csw-maintainers] dago's helper script into some base package? In-Reply-To: References: Message-ID: On Sun, Oct 31, 2010 at 11:32 PM, rupert THURNER wrote: > hi, would it make sense to include dago's helper script: > http://www.opencsw.org/2010/09/which-csw-packages-have-been-installed/ > into some basic package, like pkg-get or pkg-util? > I dont know about "minimal set", as the writeup for that says. but pkg-get has had "pkg-get -l" for a long time. Which allows machine1$ pkg-get -l >savefile machine2# pkg-get -i `cat savefile` From pfelecan at opencsw.org Mon Nov 1 19:11:45 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 01 Nov 2010 19:11:45 +0100 Subject: [csw-maintainers] package naming conventions for addons to other packages In-Reply-To: (Philip Brown's message of "Mon, 1 Nov 2010 08:43:42 -0700") References: <20101027084904.GA155@bender.opencsw.org> <1288179019-sup-4933@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > On Sat, Oct 30, 2010 at 7:55 AM, Peter FELECAN wrote: >>... >> Thus, here is the reformulated call for vote: >> >> Do you, as an active foundation maintainer, agree to relive the current >> limit of packages name from the current 20 characters to the 32 >> characters defined by the current packaging system? >> > > That is more reasonable. And something I can actually support, myself. > That being said, I dont think it appropriate to change it, without > some notice and call for discussion from the full user base. > > I'll post something to announce, and users. > I think a minimum wait of 2 weeks for any feedback is appropriate. As usual, you do just like you wish and didn't take into account a proposal. This manifest again your disdain for us. Alright, I'll ask in a separate message a vote on the original wording. -- Peter From pfelecan at opencsw.org Mon Nov 1 19:15:33 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 01 Nov 2010 19:15:33 +0100 Subject: [csw-maintainers] Call for vote for increasing the limit of packages name Message-ID: Do you, as an active foundation maintainer, agree to relive the current limit of packages name from the current 20 characters to the 32 characters defined by the current packaging system? Please vote on this issue not later than November 8th, 2010. Thank you in advance -- Peter From phil at bolthole.com Mon Nov 1 19:23:32 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 1 Nov 2010 11:23:32 -0700 Subject: [csw-maintainers] Call for vote for increasing the limit of packages name In-Reply-To: References: Message-ID: On Mon, Nov 1, 2010 at 11:15 AM, Peter FELECAN wrote: > Do you, as an active foundation maintainer, agree to relive the current > limit of packages name from the current 20 characters to the 32 > characters defined by the current packaging system? > > Please vote on this issue not later than November 8th, 2010. > the mailing list is not a voting mechanism. Please set up your call for a vote in a more appropriate place, and give a url reference, at the proper time. (you might use one of the free voting thingies we've used in the past, but I dont recall the name right now) (or, request that "the board", or anyone else you wish, set one up. I'll remind you that the official OpenCSW "secretary" is Dagobert) Also, it is not appropriate to have the vote, until the timeperiod for request for comments to our users has happened. As I emailed the list today, an abbreviated timeperiod of 2 weeks seems appropriate. Normally, for something globally affecting every single thing we do, I'd suggest 4 weeks, but since I'm actually in favor of the change and think it will pass without opposition, I'm okay with the shorter period of 2 weeks. So the timeperiod involved, would be better stated as "No SOONER than november 14th, but not later than (november 21st?)" From phil at bolthole.com Mon Nov 1 19:28:47 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 1 Nov 2010 11:28:47 -0700 Subject: [csw-maintainers] package naming conventions for addons to other packages In-Reply-To: References: <20101027084904.GA155@bender.opencsw.org> <1288179019-sup-4933@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Nov 1, 2010 at 11:11 AM, Peter FELECAN wrote: > Philip Brown writes: > >> That is more reasonable. And something I can actually support, myself. >> That being said, I dont think it appropriate to change it, without >> some notice and call for discussion from the full user base. >> >> I'll post something to announce, and users. >> I think a minimum wait of 2 weeks for any feedback is appropriate. > > As usual, you do just like you wish and didn't take into account a > proposal. This manifest again your disdain for us. Alright, I'll ask in > a separate message a vote on the original wording. You are being needlessly hostile here Peter. I am more than "taking it into account". I am actually directly helping it, by taking the time to write up the query to the userbase myself, rather than asking you to jump through more hoops. It's rather ill-deserved for you to accuse me of "disdain", when all I'm doing is ensuring some kind of open, formal process for the change to happen. From pfelecan at opencsw.org Mon Nov 1 19:35:55 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 01 Nov 2010 19:35:55 +0100 Subject: [csw-maintainers] Call for vote for increasing the limit of packages name In-Reply-To: (Philip Brown's message of "Mon, 1 Nov 2010 11:23:32 -0700") References: Message-ID: Philip Brown writes: > On Mon, Nov 1, 2010 at 11:15 AM, Peter FELECAN wrote: >> Do you, as an active foundation maintainer, agree to relive the current >> limit of packages name from the current 20 characters to the 32 >> characters defined by the current packaging system? >> >> Please vote on this issue not later than November 8th, 2010. >> Alright, here starts the noise again. > the mailing list is not a voting mechanism. Why? > Please set up your call for a vote in a more appropriate place, and > give a url reference, at the proper time. > (you might use one of the free voting thingies we've used in the past, > but I dont recall the name right now) > (or, request that "the board", or anyone else you wish, set one up. > I'll remind you that the official OpenCSW "secretary" is Dagobert) No need to set up something else. > Also, it is not appropriate to have the vote, until the timeperiod for > request for comments to our users has happened. As I emailed the list > today, an abbreviated timeperiod of 2 weeks seems appropriate. > Normally, for something globally affecting every single thing we do, > I'd suggest 4 weeks, but since I'm actually in favor of the change and > think it will pass without opposition, I'm okay with the shorter > period of 2 weeks. > > > So the timeperiod involved, would be better stated as > "No SOONER than november 14th, but not later than (november 21st?)" Consulting the users on an internal issue is ridiculous as it was said before. Please don't pollute this thread. Let the foundation maintainers vote. -- Peter From skayser at opencsw.org Mon Nov 1 19:38:53 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 1 Nov 2010 19:38:53 +0100 (CET) Subject: [csw-maintainers] Call for vote for increasing the limit of packages name In-Reply-To: References: Message-ID: <2020.92.74.25.190.1288636733.squirrel@ssl.skayser.de> Peter FELECAN schrieb: > Do you, as an active foundation maintainer, agree to relive the current > limit of packages name from the current 20 characters to the 32 > characters defined by the current packaging system? > > Please vote on this issue not later than November 8th, 2010. +1 Sebastian From gadavis at opencsw.org Tue Nov 2 00:25:19 2010 From: gadavis at opencsw.org (Geoff Davis) Date: Mon, 1 Nov 2010 16:25:19 -0700 Subject: [csw-maintainers] Call for vote for increasing the limit of packages name In-Reply-To: References: Message-ID: <6EC7D320-3ABF-4AAB-9113-DFA007EA658B@opencsw.org> +1 On Nov 1, 2010, at 11:15 AM, Peter FELECAN wrote: > Do you, as an active foundation maintainer, agree to relive the current > limit of packages name from the current 20 characters to the 32 > characters defined by the current packaging system? > > Please vote on this issue not later than November 8th, 2010. > > Thank you in advance > -- > Peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From bwalton at opencsw.org Tue Nov 2 02:02:25 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 01 Nov 2010 21:02:25 -0400 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs pm_calendarsimp, pm_calendarsimple In-Reply-To: References: <201011020003.oA203Tlg017693@login.bo.opencsw.org> Message-ID: <1288659664-sup-5413@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Nov 01 20:46:30 -0400 2010: > erm.. it also depends on CSWperl. > please remove that, and the CSWcommon dependency. I thought that everything was supposed to depend on CSWcommon? That's been standard practice since I've been around...It's a dummy package, but still a package. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Nov 2 02:02:49 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 01 Nov 2010 21:02:49 -0400 Subject: [csw-maintainers] Call for vote for increasing the limit of packages name In-Reply-To: References: Message-ID: <1288659758-sup-6979@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Mon Nov 01 14:15:33 -0400 2010: > Do you, as an active foundation maintainer, agree to relive the current > limit of packages name from the current 20 characters to the 32 > characters defined by the current packaging system? +1 -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From jcraig at opencsw.org Tue Nov 2 02:48:47 2010 From: jcraig at opencsw.org (Jonathan Craig) Date: Mon, 1 Nov 2010 21:48:47 -0400 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs pm_calendarsimp, pm_calendarsimple In-Reply-To: <1288659664-sup-5413@pinkfloyd.chass.utoronto.ca> References: <201011020003.oA203Tlg017693@login.bo.opencsw.org> <1288659664-sup-5413@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Nov 1, 2010 at 9:02 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Mon Nov 01 20:46:30 -0400 2010: > >> erm.. it also depends on CSWperl. >> please remove that, and the CSWcommon dependency. > > I thought that everything was supposed to depend on CSWcommon? That's > been standard practice since I've been around...It's a dummy package, > but still a package. > The CSWperl and CSWcommon dependencies are being driven from within GAR and not my Makefile. I tried setting explicit dependies with: RUNTIME_DEP_PKGS_CSWpmcalendarsimple = CSWcommon CSWperl RUNTIME_DEP_PKGS_CSWpmcalendarsimp = CSWpmcalendarsimple But I end up with the same / additional errors (CSWcommon CSWperl multiply defined). I suppose I could add CHECKPKG overrides to eliminate the checkpkg failures but I dont know if this is the proper thing to do. Regardless, having extra dependencies to CSWcommon CSWperl isn't really a problem as the dependencies will simply be added by the CSWpmcalendarsimple package anyways. Please advise on the best way to proceed. Thanks, Jon. From phil at bolthole.com Tue Nov 2 03:11:59 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 1 Nov 2010 19:11:59 -0700 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs pm_calendarsimp, pm_calendarsimple In-Reply-To: References: <201011020003.oA203Tlg017693@login.bo.opencsw.org> <1288659664-sup-5413@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Nov 1, 2010 at 6:48 PM, Jonathan Craig wrote: > > Please advise on the best way to proceed. ?Thanks, Jon. > Gar afficionados will hate me for this but: you could always create it "by hand". Gar is way overkill for this. if you feel adventurous... create a pkginfo file. create a depend file. create a prototype file, containing nothing but i pkginfo i depend i copyright (make some dummy copyright file also i guess) run pkgmk.. hmm. except that wont make nice filenames for you based on the stuff in pkginfo. So run "createpkg" instead and you should be done. From dam at opencsw.org Tue Nov 2 08:53:49 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 2 Nov 2010 08:53:49 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs pm_calendarsimp, pm_calendarsimple In-Reply-To: References: <201011020003.oA203Tlg017693@login.bo.opencsw.org> <1288659664-sup-5413@pinkfloyd.chass.utoronto.ca> Message-ID: <8DDCFEFB-5E5C-4D28-A33B-78E6DECAFAAB@opencsw.org> Hi, Am 02.11.2010 um 03:11 schrieb Philip Brown: > On Mon, Nov 1, 2010 at 6:48 PM, Jonathan Craig > wrote: >> >> Please advise on the best way to proceed. Thanks, Jon. > > Gar afficionados will hate me for this but: Yes. Please do NOT make that package manually as doing both packages in one recipe is a lot cleaner than manually fiddling stuff together. Why is this dependency a problem now? All of my stubs I referenced in my last email had both dependencies to CSWcommon and CSWperl and as the dependend package has also both dependencies there I can't imagine why that should be a problem. Best regards -- Dago From dam at opencsw.org Tue Nov 2 09:16:42 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 2 Nov 2010 09:16:42 +0100 Subject: [csw-maintainers] package naming conventions for addons to other packages In-Reply-To: References: <20101027084904.GA155@bender.opencsw.org> <1288179019-sup-4933@pinkfloyd.chass.utoronto.ca> Message-ID: <1BB6BF50-866A-4B09-8A2D-544E81E8688F@opencsw.org> Hi, Am 01.11.2010 um 19:28 schrieb Philip Brown: > On Mon, Nov 1, 2010 at 11:11 AM, Peter FELECAN > wrote: >> This manifest again your disdain for us. > > You are being needlessly hostile here Peter. Please, a little more civility, gentlemen! We now have two nice polls and in the end both of you want the package names to be extended. So, please, let's focus on the result and not start calling names each other next... Best regards -- Dago From bonivart at opencsw.org Tue Nov 2 09:49:09 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 2 Nov 2010 09:49:09 +0100 Subject: [csw-maintainers] Call for vote for increasing the limit of packages name In-Reply-To: References: Message-ID: On Mon, Nov 1, 2010 at 7:15 PM, Peter FELECAN wrote: > Do you, as an active foundation maintainer, agree to relive the current > limit of packages name from the current 20 characters to the 32 > characters defined by the current packaging system? +1 /Peter Bonivart From hson at opencsw.org Tue Nov 2 10:52:16 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Tue, 02 Nov 2010 10:52:16 +0100 Subject: [csw-maintainers] Call for vote for increasing the limit of packages name In-Reply-To: References: Message-ID: <4CCFDF50.2030703@opencsw.org> On 2010-11-01 19:15, Peter FELECAN wrote: > Do you, as an active foundation maintainer, agree to relive the current > limit of packages name from the current 20 characters to the 32 > characters defined by the current packaging system? > Yes From maciej at opencsw.org Tue Nov 2 14:10:36 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 2 Nov 2010 13:10:36 +0000 Subject: [csw-maintainers] Call for vote for increasing the limit of packages name In-Reply-To: References: Message-ID: No dia 1 de Novembro de 2010 18:15, Peter FELECAN escreveu: > Do you, as an active foundation maintainer, agree to relive the current > limit of packages name from the current 20 characters to the 32 > characters defined by the current packaging system? +1 From maciej at opencsw.org Tue Nov 2 16:33:49 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 2 Nov 2010 15:33:49 +0000 Subject: [csw-maintainers] samba: file sparcv8: open failed: No such file or directory In-Reply-To: References: Message-ID: No dia 31 de Outubro de 2010 10:11, rupert THURNER escreveu: > hi, > > somebody of you did already see this error message? > > creating /home/rupert/mgar/pkg/samba/trunk/work/solaris9-sparc/build-isa-sparcv8/samba-3.4.9/source3/exports/libtalloc.syms > Linking shared library bin/libtalloc.so.1 > ld: fatal: file sparcv8: open failed: No such file or directory > ld: fatal: file sparcv8: open failed: No such file or directory > ld: fatal: File processing errors. No output written to bin/libtalloc.so.1 > gmake[3]: *** [bin/libtalloc.so.1] Error 1 Looks like something specific to samba's build system, unlikely to have been seen before. Have you tried working out the exact linker invocation? Maciej From dam at opencsw.org Tue Nov 2 16:46:14 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 2 Nov 2010 16:46:14 +0100 Subject: [csw-maintainers] samba: file sparcv8: open failed: No such file or directory In-Reply-To: References: Message-ID: <28EBF08A-E280-44CD-B60E-7928C208D51C@opencsw.org> Hi Maciej, Am 02.11.2010 um 16:33 schrieb Maciej (Matchek) Blizinski: > No dia 31 de Outubro de 2010 10:11, rupert THURNER > escreveu: >> somebody of you did already see this error message? >> >> creating /home/rupert/mgar/pkg/samba/trunk/work/solaris9-sparc/ >> build-isa-sparcv8/samba-3.4.9/source3/exports/libtalloc.syms >> Linking shared library bin/libtalloc.so.1 >> ld: fatal: file sparcv8: open failed: No such file or directory >> ld: fatal: file sparcv8: open failed: No such file or directory >> ld: fatal: File processing errors. No output written to bin/ >> libtalloc.so.1 >> gmake[3]: *** [bin/libtalloc.so.1] Error 1 > > Looks like something specific to samba's build system, unlikely to > have been seen before. Have you tried working out the exact linker > invocation? Phil did have the problem before and obviously solved it as there is the lib sitting in testing/ for a very long time now: /home/testing/archive/libtalloc.so.1.sparc Am 30.10.2009 um 18:50 schrieb Philip Brown: > btw there's apparently a missing step in my directions somewhere.. > it's missing "libtalloc.so.1" from the package I made at least. > > so maby the "make install" is broken or something > libtalloc is from samba itself, and does get built. Phil: Maybe you can remember how you built it? Best regards -- Dago From bwalton at opencsw.org Tue Nov 2 16:48:54 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 02 Nov 2010 11:48:54 -0400 Subject: [csw-maintainers] samba: file sparcv8: open failed: No such file or directory In-Reply-To: <28EBF08A-E280-44CD-B60E-7928C208D51C@opencsw.org> References: <28EBF08A-E280-44CD-B60E-7928C208D51C@opencsw.org> Message-ID: <1288712855-sup-7402@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Nov 02 11:46:14 -0400 2010: > Phil: Maybe you can remember how you built it? I wonder if this is related to upstream changes...the latest fedora packages split out libtalloc and libtdb to separate packages. There is also a ctdb project that would use libtdb. Maybe those libraries are now external entities in their own projects? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Nov 2 16:49:37 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 2 Nov 2010 08:49:37 -0700 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs pm_calendarsimp, pm_calendarsimple In-Reply-To: <8DDCFEFB-5E5C-4D28-A33B-78E6DECAFAAB@opencsw.org> References: <201011020003.oA203Tlg017693@login.bo.opencsw.org> <1288659664-sup-5413@pinkfloyd.chass.utoronto.ca> <8DDCFEFB-5E5C-4D28-A33B-78E6DECAFAAB@opencsw.org> Message-ID: On Tue, Nov 2, 2010 at 12:53 AM, Dagobert Michelsen wrote: > > > Why is this dependency a problem now? All of my stubs > I referenced in my last email had both dependencies to > CSWcommon and CSWperl and as the dependend package has > also both dependencies there I can't imagine why that > should be a problem. Because the package itself does not actually depend on CSWperl. That at least should be a clear "wrong" to you. We are sometimes interested in "how many packages need perl", and stubs like this throw off the count. Additionally, this has been a standard since day one of CSW: If package A depends on package B which depends on package C: it is an ERROR to say that A -> C, unless it directly uses things in C. Perhaps not so clear, is that depending on CSWcommon is also wrong. The stub(s) uses nothing of the contents of CSWcommon. Dago, I did not closely examine your stub packages prior to this, because I presumed as a long-time maintainer such as yourself, would "do the right thing" without me checking. :) But since Jonathan is relatively new, i took a closer look at his stub package From bwalton at opencsw.org Tue Nov 2 16:51:49 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 02 Nov 2010 11:51:49 -0400 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs pm_calendarsimp, pm_calendarsimple In-Reply-To: References: <201011020003.oA203Tlg017693@login.bo.opencsw.org> <1288659664-sup-5413@pinkfloyd.chass.utoronto.ca> <8DDCFEFB-5E5C-4D28-A33B-78E6DECAFAAB@opencsw.org> Message-ID: <1288713053-sup-4000@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Nov 02 11:49:37 -0400 2010: > Perhaps not so clear, is that depending on CSWcommon is also wrong. > The stub(s) uses nothing of the contents of CSWcommon. I for 'two' was unaware of this. My understanding was that _all_ packages depend on CSWcommon, regardless or 'need' and in fact, this is what GAR does by default. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Tue Nov 2 17:08:00 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 2 Nov 2010 17:08:00 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs pm_calendarsimp, pm_calendarsimple In-Reply-To: References: <201011020003.oA203Tlg017693@login.bo.opencsw.org> <1288659664-sup-5413@pinkfloyd.chass.utoronto.ca> <8DDCFEFB-5E5C-4D28-A33B-78E6DECAFAAB@opencsw.org> Message-ID: <79556B6D-F417-4611-85ED-B195FEC17AB6@opencsw.org> Hi, Am 02.11.2010 um 16:49 schrieb Philip Brown: > On Tue, Nov 2, 2010 at 12:53 AM, Dagobert Michelsen > wrote: >> Why is this dependency a problem now? All of my stubs >> I referenced in my last email had both dependencies to >> CSWcommon and CSWperl and as the dependend package has >> also both dependencies there I can't imagine why that >> should be a problem. > > Because the package itself does not actually depend on CSWperl. > That at least should be a clear "wrong" to you. We are sometimes > interested in "how many packages need perl", and stubs like this throw > off the count. > > Additionally, this has been a standard since day one of CSW: If > package A depends on package B which depends on package C: it is an > ERROR to say that A -> C, unless it directly uses things in C. > > Perhaps not so clear, is that depending on CSWcommon is also wrong. > The stub(s) uses nothing of the contents of CSWcommon. > > Dago, I did not closely examine your stub packages prior to this, > because I presumed as a long-time maintainer such as yourself, would > "do the right thing" without me checking. :) This first requires that I know what is the right thing :) > But since Jonathan is relatively new, i took a closer look at his > stub package Removing the dependency to CSWperl is not that hard - a possibility to override dependencies should just do it. OTOH I could also add something that if the package has been registered as stub it will have no implicit dependencies. I'll have a look on how to best implement it. Best regards -- Dago From phil at bolthole.com Tue Nov 2 17:25:51 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 2 Nov 2010 09:25:51 -0700 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs pm_calendarsimp, pm_calendarsimple In-Reply-To: <1288713053-sup-4000@pinkfloyd.chass.utoronto.ca> References: <201011020003.oA203Tlg017693@login.bo.opencsw.org> <1288659664-sup-5413@pinkfloyd.chass.utoronto.ca> <8DDCFEFB-5E5C-4D28-A33B-78E6DECAFAAB@opencsw.org> <1288713053-sup-4000@pinkfloyd.chass.utoronto.ca> Message-ID: On 11/2/10, Ben Walton wrote: > Excerpts from Philip Brown's message of Tue Nov 02 11:49:37 -0400 2010: > >> Perhaps not so clear, is that depending on CSWcommon is also wrong. >> The stub(s) uses nothing of the contents of CSWcommon. > > I for 'two' was unaware of this. My understanding was that _all_ > packages depend on CSWcommon, regardless or 'need' and in fact, this > is what GAR does by default. ah. well, I'm all for better knowledge sharing :) *most* packages, do actually get use out of it. It's "use", is to define common shared permissions and modes, for the top level directories such as /opt/csw/lib, /opt/csw/share, and so on. Since *most* packages actually deliver files under /opt/csw, this is useful. Almost all packages, but not quite. Stub packages are an exception. In theory, cswclassutils could also be an exception, since it primarily delivers things into /usr/sadm. However, since it also delivers things into /opt/csw/share (docs), it also "uses" cswcommon. Another exception type, would be pure relocatable packages. (potentially, some web stuff) Since they can be deployed outside of /opt/csw, they should, strictly speaking, NOT depend on CSWcommon. That would needlessly clutter up a user's filesystem, if they deploy elsewhere. From phil at bolthole.com Tue Nov 2 17:34:40 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 2 Nov 2010 09:34:40 -0700 Subject: [csw-maintainers] samba: file sparcv8: open failed: No such file or directory In-Reply-To: <28EBF08A-E280-44CD-B60E-7928C208D51C@opencsw.org> References: <28EBF08A-E280-44CD-B60E-7928C208D51C@opencsw.org> Message-ID: On 11/2/10, Dagobert Michelsen wrote: > > Phil: Maybe you can remember how you built it? > Hm. well, my old 3.4.5 builds are sitting in /home/phil/build-`uname -p`/samba-3.4.5 and there's /home/phil/pkgs/samba/BUILD.NOTES (and old.build.notes) From jcraig at opencsw.org Tue Nov 2 18:05:21 2010 From: jcraig at opencsw.org (Jonathan Craig) Date: Tue, 2 Nov 2010 13:05:21 -0400 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs pm_calendarsimp, pm_calendarsimple In-Reply-To: <79556B6D-F417-4611-85ED-B195FEC17AB6@opencsw.org> References: <201011020003.oA203Tlg017693@login.bo.opencsw.org> <1288659664-sup-5413@pinkfloyd.chass.utoronto.ca> <8DDCFEFB-5E5C-4D28-A33B-78E6DECAFAAB@opencsw.org> <79556B6D-F417-4611-85ED-B195FEC17AB6@opencsw.org> Message-ID: On Tue, Nov 2, 2010 at 12:08 PM, Dagobert Michelsen wrote: >> Perhaps not so clear, is that depending on CSWcommon is also wrong. >> The stub(s) uses nothing of the contents of CSWcommon. >> Getting rid of the CSWcommon dependency only required a: COMMON_PKG_DEPENDS = to keep it from being added by gar. > Removing the dependency to CSWperl is not that hard - a possibility > to override dependencies should just do it. OTOH I could also > add something that if the package has been registered as stub > it will have no implicit dependencies. I'll have a look on how > to best implement it. Getting rid of CSWperl looks to be more involved. I believe its pulled in from the depend.perl file inside of gar but couldnt immediately discern how. As the stub package has a: PKGFILES_CSWpmcalendarsimp = NOFILES line this could be a good trigger to forgo added dependencies. Jon From phil at bolthole.com Wed Nov 3 18:40:36 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 3 Nov 2010 10:40:36 -0700 Subject: [csw-maintainers] How to make notes on why a package is "special" Message-ID: FYI to folks, After a quick conversation with Maciej in the pkgsubmissions mailing list, I just updated our docs, at the end of http://www.opencsw.org/extend-it/contribute-packages/build-standards/ It now mentions the name of a new, optional file, called "cswreleasemgr". If you are unlucky enough to be maintaining a package that is... shall we say, 'special'... you now have a place to document it in the package itself. Toss an "i cswreleasemgr" as the first line in your prototype file, and it will be bundled away inside the package, yet easily readable by me come release time. From maciej at opencsw.org Thu Nov 4 10:34:25 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 4 Nov 2010 09:34:25 +0000 Subject: [csw-maintainers] checkpkg now allows *-devel packages to depend on any packages Message-ID: The surplus-dependency error tag used to be one of the most common false positives in checkpg. I've just committed a code change, which allows *-devel packages to depend on any packages. The detection is based on pkgname (not the catalogname), and the regex used is: CSW[a-z\-]+dev(el)? This matches CSWfoo-devel, CSWfoo-dev, CSWfoodevel and CSWfoodev. After you update your svn clients, you'll see messages about unused overrides. You will also no longer see the surplus-dependency errors in new *-devel packages. Maciej From skayser at opencsw.org Thu Nov 4 23:12:45 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 04 Nov 2010 23:12:45 +0100 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? Message-ID: <4CD32FDD.3020606@opencsw.org> Hi, I just found that I wanted to quickly know how a released package was built, that's when the following (old) thought crossed my mind. When a package is built with GAR, the repository URL for its current build description gets embedded into the pkginfo file as OPENCSW_REPOSITORY. What do you guys think about integrating this URL on the package display page so that the build description is easily accessibly by anyone (say as field "Build Recipe")? Someone proficient enough with our database and the wordpress setup to do so? Phil? Does the package database already hold this information or could you add this? Sebastian From bwalton at opencsw.org Fri Nov 5 00:44:09 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 04 Nov 2010 19:44:09 -0400 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: <4CD32FDD.3020606@opencsw.org> References: <4CD32FDD.3020606@opencsw.org> Message-ID: <1288914224-sup-4820@pinkfloyd.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Thu Nov 04 18:12:45 -0400 2010: > OPENCSW_REPOSITORY. What do you guys think about integrating this > URL on the package display page so that the build description is > easily accessibly by anyone (say as field "Build Recipe")? +1. I don't know much about how any of this is currently setup though. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Fri Nov 5 00:46:24 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 4 Nov 2010 16:46:24 -0700 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: <4CD32FDD.3020606@opencsw.org> References: <4CD32FDD.3020606@opencsw.org> Message-ID: On 11/4/10, Sebastian Kayser wrote: > > When a package is built with GAR, the repository URL for its current > build description gets embedded into the pkginfo file as > OPENCSW_REPOSITORY. What do you guys think about integrating this URL on > the package display page so that the build description is easily > accessibly by anyone (say as field "Build Recipe")? Possibly a good idea. Not too enthused about the name. I'd prefer "Source Repository" or something like that. > Someone proficient enough with our database and the wordpress setup to > do so? Phil? Does the package database already hold this information or > could you add this? it wouldnt be too difficult to add the information into our package database. I'm not sure who coded our current web interface to the package display page, but it wasnt me. From bwalton at opencsw.org Fri Nov 5 00:57:30 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 04 Nov 2010 19:57:30 -0400 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <4CD32FDD.3020606@opencsw.org> Message-ID: <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Nov 04 19:46:24 -0400 2010: > Possibly a good idea. Not too enthused about the name. I'd prefer > "Source Repository" or something like that. Build Recipe is internal lingo, so it may not be the best choice of naming. Source Repository is misleading though. I'd expect that to take me to the upstream vcs repository, not to the CSW GAR build description. I don't have a better suggestion though. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From jcraig at opencsw.org Fri Nov 5 01:03:52 2010 From: jcraig at opencsw.org (Jonathan Craig) Date: Thu, 4 Nov 2010 20:03:52 -0400 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Nov 4, 2010 at 7:57 PM, Ben Walton wrote: >> Possibly a good idea. Not too enthused about the name. I'd prefer >> "Source Repository" or something like that. May I suggest "Package Build Repository"? From phil at bolthole.com Fri Nov 5 01:33:39 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 4 Nov 2010 17:33:39 -0700 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> Message-ID: On 11/4/10, Jonathan Craig wrote: > On Thu, Nov 4, 2010 at 7:57 PM, Ben Walton wrote: > >>> Possibly a good idea. Not too enthused about the name. I'd prefer >>> "Source Repository" or something like that. > > May I suggest "Package Build Repository"? > sure. no reason for us to limit ourselves to two words only :) From ihsan at opencsw.org Fri Nov 5 12:21:04 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Fri, 05 Nov 2010 12:21:04 +0100 Subject: [csw-maintainers] maintenance on the mail server Message-ID: <4CD3E8A0.3090902@opencsw.org> Hello, On Sunday I will update all the packages on bender.opencsw.org aka mail.opencsw.org to the most recent version. I expect this will cause an outage of approximately 2 hours. I will also upgrade to the most recent Solaris version. This will cause an outage of 5-10 minutes on all the zones (mail, web, dev). Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Fri Nov 5 14:10:52 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 5 Nov 2010 13:10:52 +0000 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> Message-ID: A side note, this idea is already implemented in the package details browser, for instance: http://pkg.opencsw.org/pkgbrowser/reports/pkgbrowse-maciej.html#8ad9ee0d1b215b301eb748d08713af48 Contains: ==Build source code== https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/nspr/trunk at 11305 Makefile (in Subversion, may link to a later revision) Makefile (in Trac view, always links to the correct file revision) The links are: - https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/nspr/trunk/Makefile - http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/nspr/trunk/Makefile?rev=11305 From maciej at opencsw.org Fri Nov 5 14:11:14 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 5 Nov 2010 13:11:14 +0000 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> Message-ID: How about: "build description" or "package build description"? The word "repository" does not contain any interesting information in this context. From phil at bolthole.com Fri Nov 5 16:44:04 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 5 Nov 2010 08:44:04 -0700 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> Message-ID: On 11/5/10, Maciej (Matchek) Blizinski wrote: > A side note, this idea is already implemented in the package details > browser, for instance: >[....] > Contains: > > ==Build source code== > > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/nspr/trunk at 11305 > That brings up a side issue. the url may be svn-friendly. but its not really WEB friendly. (it is an INVALID url, if you just drop it into your browser!) Any user-friendly web display, in my opinion, should first give a web-browsable url. and then if appropriate, mention something like, "oh and if you want to use svn to check out the specific revision, use svn co [url-here]" From phil at bolthole.com Fri Nov 5 16:45:21 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 5 Nov 2010 08:45:21 -0700 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> Message-ID: On 11/5/10, Maciej (Matchek) Blizinski wrote: > How about: "build description" or "package build description"? The > word "repository" does not contain any interesting information in this > context. i disagree. It's not a "description". It's a reference to a specific svn-tag, in a specific part of a source code tree. The english meaning of "repository" fits far better than the english meaning of "description". From maciej at opencsw.org Fri Nov 5 17:15:10 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 5 Nov 2010 16:15:10 +0000 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 5 de Novembro de 2010 15:45, Philip Brown escreveu: > On 11/5/10, Maciej (Matchek) Blizinski wrote: >> How about: "build description" or "package build description"? The >> word "repository" does not contain any interesting information in this >> context. > > > i disagree. > It's not a "description". It's a reference to a specific svn-tag, in a > specific part of a source code tree. No, it's not a reference to a subversion tag. It's a reference to a specific revision of a file in a subversion repository. > The english meaning of "repository" fits far better than the english > meaning of "description". Repository is a place, while the link needs to tell you what kind of thing you're referring to (rather than where it is). In this case, it is a bit of information describing how was a particular package built, and "Build description" seems like a good match, but I guess you can find other expressions too. From phil at bolthole.com Fri Nov 5 17:27:02 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 5 Nov 2010 09:27:02 -0700 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> Message-ID: On 11/5/10, Maciej (Matchek) Blizinski wrote: > No dia 5 de Novembro de 2010 15:45, Philip Brown > escreveu: >> On 11/5/10, Maciej (Matchek) Blizinski wrote: >>> How about: "build description" or "package build description"? The >>> word "repository" does not contain any interesting information in this >>> context. >> >> >> i disagree. >> It's not a "description". It's a reference to a specific svn-tag, in a >> specific part of a source code tree. > > No, it's not a reference to a subversion tag. It's a reference to a > specific revision of a file in a subversion repository. > err, what? Existing OPENCSW_REPOSITORY lines in packages, do not refer to a specific directory. They tend to have the form OPENCSW_REPOSITORY=https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/software/trunk at 12345 That does not refer to a specific file. If we are planning to make OPENCSW_REPOSITORY visible in our package information webpage, then "description" does not fit that information. From skayser at opencsw.org Fri Nov 5 17:27:42 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 5 Nov 2010 17:27:42 +0100 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> Message-ID: <20101105162742.GA15588@sebastiankayser.de> * Philip Brown wrote: > On 11/5/10, Maciej (Matchek) Blizinski wrote: > > No dia 5 de Novembro de 2010 15:45, Philip Brown > > escreveu: > >> On 11/5/10, Maciej (Matchek) Blizinski wrote: > >>> How about: "build description" or "package build description"? The > >>> word "repository" does not contain any interesting information in this > >>> context. > >> > >> > >> i disagree. > >> It's not a "description". It's a reference to a specific svn-tag, in a > >> specific part of a source code tree. > > > > No, it's not a reference to a subversion tag. It's a reference to a > > specific revision of a file in a subversion repository. > > > > err, what? > > Existing OPENCSW_REPOSITORY lines in packages, do not refer to a > specific directory. > They tend to have the form > > OPENCSW_REPOSITORY=https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/software/trunk at 12345 > > That does not refer to a specific file. > > If we are planning to make OPENCSW_REPOSITORY visible in our package > information webpage, then "description" does not fit that information. Isn't what the user sees once he clicks this sort of link (adjusted to be browser-usable of course) a build description? I tend to agree with Maciej that the location is an implementation detail and the field name should describe what content the link is pointing to. Anyway, the field name can easily be changed once it is in place and is secondary in nature to the link being in place at all. So how about we/you spend our time implementing this thing rather than going in circles about the name? Sebastian From phil at bolthole.com Fri Nov 5 17:56:51 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 5 Nov 2010 09:56:51 -0700 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: <20101105162742.GA15588@sebastiankayser.de> References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> <20101105162742.GA15588@sebastiankayser.de> Message-ID: On 11/5/10, Sebastian Kayser wrote: > * Philip Brown wrote: >> >> OPENCSW_REPOSITORY=https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/software/trunk at 12345 >> >> That does not refer to a specific file. >> >> If we are planning to make OPENCSW_REPOSITORY visible in our package >> information webpage, then "description" does not fit that information. > > Isn't what the user sees once he clicks this sort of link (adjusted to > be browser-usable of course) a build description? I tend to agree with > Maciej that the location is an implementation detail and the field name > should describe what content the link is pointing to. That would only be true, if you CHANGE the link. Clearly, the link as it currently stands, points to a directory that it was built from, not a file. Which, I suggest, is more useful to the user than linking directly to the Makefile. The user will most likely be interested in this information for either two reasons: 1. browsing the source code with a browser. 2. rebulding the package himself from source. In neither case will he be interested in only "the GAR recipe". Besides which, not everything in our source tree is GAR. I've been playing nice by including OPENCSW_REPOSITORY information in certain packages of mine in the svn tree, and filling it out with information which follows the literal meaning of the name: referencing "where in the OPENCSW REPOSITORY this package was built". If you want information in the package that declares "Which GAR recipe file this was built from", then seems to me you should be doing that under a more appropriately named pkginfo line. From maciej at opencsw.org Fri Nov 5 18:39:25 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 5 Nov 2010 17:39:25 +0000 Subject: [csw-maintainers] License / copyright files in packages Message-ID: I've just learned that our release manager is not aware of a policy requiring to put license files into /opt/csw/share/doc/foo/license. Currently, checkpkg requires that and if the file is not present, prints: # See http://sourceforge.net/apps/trac/gar/wiki/CopyRight # -> CheckpkgTag('CSWfoo', 'license-missing', '/opt/csw/share/doc/foo/license') On the other hand, I learned about the "i copyright" file that is meant to contain the license file. Should we reconcile that and settle on one policy? Maciej From phil at bolthole.com Fri Nov 5 18:42:34 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 5 Nov 2010 10:42:34 -0700 Subject: [csw-maintainers] License / copyright files in packages In-Reply-To: References: Message-ID: On 11/5/10, Maciej (Matchek) Blizinski wrote: > > On the other hand, I learned about the "i copyright" file that is > meant to contain the license file. that is a misstatement. It was previously our (loooong time) policy, that the "i copyright" file, contain the actual license file. However, some time in the not-too-distant-past it was agreed that it was acceptible for the "i copyright" file to only reference the full copyright file, as delivered in the package. (the reason for this, is that the "i copyright" file gets displayed in its entirety, at pkgadd time) From maciej at opencsw.org Fri Nov 5 18:48:49 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 5 Nov 2010 17:48:49 +0000 Subject: [csw-maintainers] License / copyright files in packages In-Reply-To: References: Message-ID: No dia 5 de Novembro de 2010 17:42, Philip Brown escreveu: > On 11/5/10, Maciej (Matchek) Blizinski wrote: >> >> On the other hand, I learned about the "i copyright" file that is >> meant to contain the license file. > > that is a misstatement. > > It was previously our (loooong time) policy, that the "i copyright" > file, contain the actual license file. > > However, some time in the not-too-distant-past it was agreed that it > was acceptible for the "i copyright" file to only reference the full > copyright file, as delivered in the package. Does the reference have a defined syntax? Checkpkg could de-refer it and check if the referred license file is present in the package. From phil at bolthole.com Fri Nov 5 18:53:18 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 5 Nov 2010 10:53:18 -0700 Subject: [csw-maintainers] License / copyright files in packages In-Reply-To: References: Message-ID: On 11/5/10, Maciej (Matchek) Blizinski wrote: > >> However, some time in the not-too-distant-past it was agreed that it >> was acceptible for the "i copyright" file to only reference the full >> copyright file, as delivered in the package. > > Does the reference have a defined syntax? Checkpkg could de-refer it > and check if the referred license file is present in the package. > None have been defined that I recall. Which is in some ways appropriate, because SOMETIMES, for very short licenses, it is just fine to contain the license itself in "i copyright", with no separate license file. But it's pretty trivial to just "grep /opt/csw/share/doc copyright", after all. From dam at opencsw.org Fri Nov 5 21:58:26 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 5 Nov 2010 21:58:26 +0100 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> Message-ID: <2277D105-CCEE-4712-ACCE-AD3B3184ACB0@opencsw.org> Hi Phil, Am 05.11.2010 um 16:44 schrieb Philip Brown: > On 11/5/10, Maciej (Matchek) Blizinski wrote: >> A side note, this idea is already implemented in the package details >> browser, for instance: >> [....] >> Contains: >> >> ==Build source code== >> >> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/nspr/trunk at 11305 >> > > That brings up a side issue. > > the url may be svn-friendly. but its not really WEB friendly. > (it is an INVALID url, if you just drop it into your browser!) > > Any user-friendly web display, in my opinion, should first give a > web-browsable url. and then if appropriate, mention something like, > "oh and if you want to use svn to check out the specific revision, use > svn co [url-here]" Definitely. That's why there are two URLs given. This is human-readable one: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/nspr/trunk/Makefile?rev=11305 Best regards -- Dago From phil at bolthole.com Fri Nov 5 22:50:18 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 5 Nov 2010 14:50:18 -0700 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: <2277D105-CCEE-4712-ACCE-AD3B3184ACB0@opencsw.org> References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> <2277D105-CCEE-4712-ACCE-AD3B3184ACB0@opencsw.org> Message-ID: On 11/5/10, Dagobert Michelsen wrote: > Hi Phil, *wave* > Am 05.11.2010 um 16:44 schrieb Philip Brown: > >> Any user-friendly web display, in my opinion, should first give a >> web-browsable url. and then if appropriate, mention something like, >> "oh and if you want to use svn to check out the specific revision, use >> svn co [url-here]" > > Definitely. That's why there are two URLs given. This is human-readable one: > > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/nspr/trunk/Makefile?rev=11305 Where are you referring to? somewhere waay back in this thread? I'm just looking at "what we put in pkginfo right now". which only has one: the directory based one. Personally, I think this is adequate, and to put anything more in the package itself would be rather redundant. Comments from anyone we havent heard from yet? From ihsan at opencsw.org Sun Nov 7 23:34:51 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 07 Nov 2010 23:34:51 +0100 Subject: [csw-maintainers] maintenance on the mail server In-Reply-To: <4CD3E8A0.3090902@opencsw.org> References: <4CD3E8A0.3090902@opencsw.org> Message-ID: <4CD7298B.3050405@opencsw.org> Am 05.11.10 12:21, schrieb Ihsan Dogan: > On Sunday I will update all the packages on bender.opencsw.org aka > mail.opencsw.org to the most recent version. I expect this will cause an > outage of approximately 2 hours. > > I will also upgrade to the most recent Solaris version. This will cause > an outage of 5-10 minutes on all the zones (mail, web, dev). All updates are done. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From james at opencsw.org Mon Nov 8 12:19:58 2010 From: james at opencsw.org (James Lee) Date: Mon, 08 Nov 2010 11:19:58 GMT Subject: [csw-maintainers] License / copyright files in packages In-Reply-To: References: Message-ID: <20101108.11195800.2647946344@gyor.oxdrove.co.uk> On 05/11/10, 17:39:25, Maciej "(Matchek)" Blizinski wrote regarding [csw-maintainers] License / copyright files in packages: > I've just learned that our release manager is not aware of a policy > requiring to put license files into /opt/csw/share/doc/foo/license. > Currently, checkpkg requires that and if the file is not present, > prints: I'm also not aware it's a requirement. > On the other hand, I learned about the "i copyright" file that is > meant to contain the license file. Can you clarify? I too learned about the "i copyright" but it was when I built my first package. > Should we reconcile that and settle on one policy? i copyright is the correct place. The advantage of placing in the information section of the package is the file is in a standard place and it gets put in the first part of the package file so allowing it to be pullout more easily (without reading/downloading the whole file) eg to present to the user before installation which is important should the user not agree. See example here: http://www.canoedissent.org.uk/packages/unstable/sparc/5.10/CSWfetchma il/copyright/ I only download the head of each package to extract i files. Excepting local file system differences, eg sharing /opt, there is no advantage in storing the copyright in: /opt/csw/share/doc/foo/license over: /var/sadm/pkg/CSWfoo/copyright The advantage of storing in the standard location is it's standard, not just CSW and should already be known to admins. James. From bwalton at opencsw.org Tue Nov 9 03:49:14 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 08 Nov 2010 21:49:14 -0500 Subject: [csw-maintainers] License / copyright files in packages In-Reply-To: <20101108.11195800.2647946344@gyor.oxdrove.co.uk> References: <20101108.11195800.2647946344@gyor.oxdrove.co.uk> Message-ID: <1289270794-sup-4040@pinkfloyd.chass.utoronto.ca> Excerpts from James Lee's message of Mon Nov 08 06:19:58 -0500 2010: Hi James, > The advantage of storing in the standard location is it's standard, > not just CSW and should already be known to admins. I really like the much quieter package install. Having the entire copyright spit out at installation time adds insult to injury to an already noisy process. I think that was the impetus for the change originally. If this could be toggled via the admin file then I wouldn't care, but I _really_ don't want to go back to having this displayed at install time. Your points about ease of extraction are well taken though. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From james at opencsw.org Tue Nov 9 10:32:33 2010 From: james at opencsw.org (James Lee) Date: Tue, 09 Nov 2010 09:32:33 GMT Subject: [csw-maintainers] License / copyright files in packages In-Reply-To: <1289270794-sup-4040@pinkfloyd.chass.utoronto.ca> References: <20101108.11195800.2647946344@gyor.oxdrove.co.uk> <1289270794-sup-4040@pinkfloyd.chass.utoronto.ca> Message-ID: <20101109.9323300.1424021773@gyor.oxdrove.co.uk> On 09/11/10, 02:49:14, Ben Walton wrote regarding Re: [csw-maintainers] License / copyright files in packages: > I really like the much quieter package install. Having the entire > copyright spit out at installation time adds insult to injury to an > already noisy process. I think that was the impetus for the change > originally. If this could be toggled via the admin file then I > wouldn't care This can be done with the -S flag of pkgadd. ("S" is for secret option.) eg, in: /opt/csw/etc/pkg-get.conf set: PKGADDFLAGS="-S" James. From pfelecan at opencsw.org Tue Nov 9 10:58:16 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 09 Nov 2010 10:58:16 +0100 Subject: [csw-maintainers] License / copyright files in packages In-Reply-To: <20101109.9323300.1424021773@gyor.oxdrove.co.uk> (James Lee's message of "Tue, 09 Nov 2010 09:32:33 GMT") References: <20101108.11195800.2647946344@gyor.oxdrove.co.uk> <1289270794-sup-4040@pinkfloyd.chass.utoronto.ca> <20101109.9323300.1424021773@gyor.oxdrove.co.uk> Message-ID: James Lee writes: > This can be done with the -S flag of pkgadd. ("S" is for secret > option.) what about a -O flag as Opacity/Obscurity? -- Peter From maciej at opencsw.org Tue Nov 9 11:04:38 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 9 Nov 2010 10:04:38 +0000 Subject: [csw-maintainers] License / copyright files in packages In-Reply-To: References: Message-ID: No dia 5 de Novembro de 2010 17:53, Philip Brown escreveu: > On 11/5/10, Maciej (Matchek) Blizinski wrote: >> >>> However, some time in the not-too-distant-past it was agreed that it >>> was acceptible for the "i copyright" file to only reference the full >>> copyright file, as delivered in the package. >> >> Does the reference have a defined syntax? ?Checkpkg could de-refer it >> and check if the referred license file is present in the package. >> > > None have been defined that I recall. > Which is in some ways appropriate, because SOMETIMES, for very short > licenses, it is just fine to contain the license itself in "i > copyright", with no separate license file. > > But it's pretty trivial to just "grep /opt/csw/share/doc copyright", after all. You mean, in pkgmp? If we don't have a naming standard, we can't grep like this without having lots of false positives. When you start analyzing the copyright file, you could do something like this: if copyright_file_exists: if is_reference: if cannot_derefer: return an error tag else: return an error tag The problem is in determining whether it's a reference or not. If there is no format, you cannot parse the file and answer the question "is it a reference or not?", and in effect, you cannot check whether the package actually contains a copyright or not. The "i copyright" file could contain a reference to a file that isn't included in the package, and you would be unable to detect that. Phil, would you like to suggest a syntax for copyright file references? From bwalton at opencsw.org Tue Nov 9 15:02:57 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 09 Nov 2010 09:02:57 -0500 Subject: [csw-maintainers] License / copyright files in packages In-Reply-To: <20101109.9323300.1424021773@gyor.oxdrove.co.uk> References: <20101108.11195800.2647946344@gyor.oxdrove.co.uk> <1289270794-sup-4040@pinkfloyd.chass.utoronto.ca> <20101109.9323300.1424021773@gyor.oxdrove.co.uk> Message-ID: <1289311337-sup-3860@pinkfloyd.chass.utoronto.ca> Excerpts from James Lee's message of Tue Nov 09 04:32:33 -0500 2010: Hi James, > This can be done with the -S flag of pkgadd. ("S" is for secret > option.) Ok, this would work. Where do you learn of all these undocumented things? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Tue Nov 9 15:39:41 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 09 Nov 2010 15:39:41 +0100 Subject: [csw-maintainers] License / copyright files in packages In-Reply-To: <1289311337-sup-3860@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Tue, 09 Nov 2010 09:02:57 -0500") References: <20101108.11195800.2647946344@gyor.oxdrove.co.uk> <1289270794-sup-4040@pinkfloyd.chass.utoronto.ca> <20101109.9323300.1424021773@gyor.oxdrove.co.uk> <1289311337-sup-3860@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: >> This can be done with the -S flag of pkgadd. ("S" is for secret >> option.) > > Ok, this would work. Where do you learn of all these undocumented > things? You can read the relevant information in http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/svr4pkg/pkgadd/main.c 758 /* 759 * Not a public interface: suppress copyright notice being 760 * output during installation. 761 */ 762 case 'S': 763 suppressCopyright++; 764 break; -- Peter From james at opencsw.org Tue Nov 9 15:42:35 2010 From: james at opencsw.org (James Lee) Date: Tue, 09 Nov 2010 14:42:35 GMT Subject: [csw-maintainers] License / copyright files in packages In-Reply-To: <1289311337-sup-3860@pinkfloyd.chass.utoronto.ca> References: <20101108.11195800.2647946344@gyor.oxdrove.co.uk> <1289270794-sup-4040@pinkfloyd.chass.utoronto.ca> <20101109.9323300.1424021773@gyor.oxdrove.co.uk> <1289311337-sup-3860@pinkfloyd.chass.utoronto.ca> Message-ID: <20101109.14423500.3203749745@gyor.oxdrove.co.uk> On 09/11/10, 14:02:57, Ben Walton wrote regarding Re: [csw-maintainers] License / copyright files in packages: > > This can be done with the -S flag of pkgadd. ("S" is for secret > > option.) > Ok, this would work. Where do you learn of all these undocumented > things? I learnt of pkgadd -S from this list. James. From phil at bolthole.com Tue Nov 9 17:59:45 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 9 Nov 2010 08:59:45 -0800 Subject: [csw-maintainers] License / copyright files in packages In-Reply-To: References: Message-ID: On 11/9/10, Maciej (Matchek) Blizinski wrote: > > > Phil, would you like to suggest a syntax for copyright file references? > I thought I just did. grep for /opt/csw/share/doc, in the "i copyright" file. there are exactly two expected cases for the copyright file. a) it contains the copyright in its entirety. Stop. Nothing to see here :) b) it contains a reference to the full copyright file. That file should live under /opt/csw/share/doc somewhere. Note that it may NOT always be /opt/csw/share/doc/[softwarename], since some packages, for valid reasons, keep their docs under /opt/csw/share/doc/[somethingelse] It makes the most sense to me, to keep the copyright notice in the same place as (the rest of the docs for the package) From maciej at opencsw.org Wed Nov 10 11:45:37 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 10 Nov 2010 10:45:37 +0000 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs cups In-Reply-To: References: <201011081957.oA8JvUVW025660@login.bo.opencsw.org> Message-ID: [+maintainers, bcc:pkgsubmissions] Link back to the start of the thread on pkgsubmissions: http://lists.opencsw.org/pipermail/pkgsubmissions/2010-November/001528.html No dia 9 de Novembro de 2010 16:47, Philip Brown escreveu: > On 11/9/10, Maciej (Matchek) Blizinski wrote: >> No dia 8 de Novembro de 2010 20:10, Philip Brown >> escreveu: >>> >>> bug #2: erm... so how come something named "libcups **2**", has >>> version=1.4.4 ?? >>> that's very confusing. >> >> It's the same naming scheme as with every other shared library. ?If >> you look at the soname, it's libcups.so.2, which gives us CSWlibcups2. >> ?It has been built from cups sources version 1.4.4, and hence the >> version. >> > > I dont think "the same as every other shared library" quite fits, > here. There are many libxxx packages that do not fit that naming > scheme. > I'm thinking this is the "new" library naming scheme you proposed, yes? Yes, that's it. > Do we have the specifics of the proposal up somewhere, either ?on main > site, or on wiki? There is a best practices writeup on the wiki, on the checkpkg error tags page, about the shared-lib-pkgname-mismatch tag. It links to the original discussion on the mailing list; the rationale is written up in the first post. There's also a link to a file with unit tests and examples of 12 different sonames and resulting package names. http://wiki.opencsw.org/checkpkg-error-tags#toc5 > Although your libpython seems relatively fine. > your libcups2 package does not match that. oh wait, it sort of does... > this is a single-digit-rev shared lib. > Which fits my original addendum to the proposal, if I recall: > "[libraries with single-digit (version numbers in the file) do not > usually need to be split out" > > This would seem to be the case for cups, where the SONAME has not > changed in over 3 years. I don't think your proposed addendum got accepted, did it? I have discussed this and explained why the number of elements in the soname version does not affect the shared library life cycle. Here's the reference: http://lists.opencsw.org/pipermail/maintainers/2010-October/012850.html > using our existing defacto standards of naming, having > > softname > ?and > softname2 > > usually means two separate, different-by-major-number versions of the software. > So libcups2 is confusing. What do you mean by confusing - what else do you think it could be? Let's consider a hypothetical release of cups version 2, which could be installed together with cups 1.x (regardless of how much sense it could have). I think this is the scenario you had in mind. Cups version two would probably increment the soname version of libcups, or change the soname altogether. Distributed files would be libcups.so.3, or libcups2.so.1 (or similar). Here's a rundown of hypothetical sonames of cups2 and resulting package names: example 1: libcups.so.3 - CSWlibcups3 example 2: libcups2.so.1 - CSWlibcups2-1 example 3: libcups2.so.2 - CSWlibcups2-2 example 4: libcups2.so - CSWlibcups2 Only the example 4 could be ambiguous; but changing the soname from libcups.so.2 to libcups2.so would be an evil thing to do, and I don't think cups developers would ever change the soname that way. I doubt that it was the scenario you had in mind. Barring the hypothetical libcups2.so example, the CSWlibcups2 package name is unique and explicit. Here's an important note on package names: The package names (pkgname and catalogname) depend solely (!) on sonames. They explicitly do not depend on project names, or sources versions. CSWlibcups2 is named the way it is because it contains libcups.so.2. The "cups" word is there just by coincidence - it so happens that the project name is embedded in the soname. Does this explanation make it more clear to you? > softname2_x_y ?is a bit more indicative of the sharedlib scheme you've proposed. > Perhaps the proposal needs something a bit more explicit to denote > "this is a split-off shared lib", since we've found a case where > having a leading "lib" is not sufficient to denote that any more. Do you mean some kind of naming prefix unambiguously identifying packages with shared libraries? What would be its purpose? The core of the package naming policy is that every soname has its own pkgname and catalogname. It's not about a perfect mapping from pkgnames to shared library names, or about identifying packages with shared libraries just by package names. The purpose of the soname-driven naming is to facilitate a healthy shared library life cycle. From dam at opencsw.org Wed Nov 10 16:14:27 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 10 Nov 2010 16:14:27 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs pm_calendarsimp, pm_calendarsimple In-Reply-To: References: <201011020003.oA203Tlg017693@login.bo.opencsw.org> <1288659664-sup-5413@pinkfloyd.chass.utoronto.ca> <8DDCFEFB-5E5C-4D28-A33B-78E6DECAFAAB@opencsw.org> <79556B6D-F417-4611-85ED-B195FEC17AB6@opencsw.org> Message-ID: <1758C7DB-B700-45F3-9371-36E347D72302@opencsw.org> Hi, Am 02.11.2010 um 18:05 schrieb Jonathan Craig: > On Tue, Nov 2, 2010 at 12:08 PM, Dagobert Michelsen > wrote: >>> Perhaps not so clear, is that depending on CSWcommon is also wrong. >>> The stub(s) uses nothing of the contents of CSWcommon. > > Getting rid of the CSWcommon dependency only required a: > > COMMON_PKG_DEPENDS = > > to keep it from being added by gar. > >> Removing the dependency to CSWperl is not that hard - a possibility >> to override dependencies should just do it. OTOH I could also >> add something that if the package has been registered as stub >> it will have no implicit dependencies. I'll have a look on how >> to best implement it. > > Getting rid of CSWperl looks to be more involved. I believe its > pulled in from the depend.perl file inside of gar but couldnt > immediately discern how. As the stub package has a: > > PKGFILES_CSWpmcalendarsimp = NOFILES > > line this could be a good trigger to forgo added dependencies. I have added a new directive to finer control dependencies in GAR by using RUNTIME_DEP_PKGS_ONLY_* the automatic dependencies are not included at all. Please be advised to closely look at dependencies on new packages: http://sourceforge.net/apps/trac/gar/changeset/11547 This module can be used as a reference: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/cpan/Time-modules/trunk/Makefile?rev=11549 Feedback as always welcome! Best regards -- Dago From maciej at opencsw.org Wed Nov 10 16:49:27 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 10 Nov 2010 15:49:27 +0000 Subject: [csw-maintainers] License / copyright files in packages In-Reply-To: References: Message-ID: No dia 9 de Novembro de 2010 16:59, Philip Brown escreveu: > On 11/9/10, Maciej (Matchek) Blizinski wrote: >> >> >> Phil, would you like to suggest a syntax for copyright file references? >> > > I thought I just did. > grep for /opt/csw/share/doc, in the "i copyright" file. OK, so it's /opt/csw/share/doc/\S+ anywhere in the file. I have some further questions. > there are exactly two expected cases for the copyright file. > > a) it contains the copyright in its entirety. Stop. Nothing to see here :) What if the file is, let's say, 1 line long and does not contain a reference? > b) it contains a reference to the full copyright file. That file > should live under /opt/csw/share/doc somewhere. What if the file contains more than one reference to a file in /otp/csw/share/doc? Is it allowed? Is the file allowed to contain text other than the reference? How much of it is allowed? > Note that it may NOT always be /opt/csw/share/doc/[softwarename], > since some packages, for valid reasons, keep their docs under > /opt/csw/share/doc/[somethingelse] > It makes the most sense to me, to keep the copyright notice in the > same place as (the rest of the docs for the package) Does every package contain the actual copyright file, or can one package reference a license file contained in another package? From dam at opencsw.org Wed Nov 10 16:53:31 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 10 Nov 2010 16:53:31 +0100 Subject: [csw-maintainers] License / copyright files in packages In-Reply-To: References: Message-ID: <719018BF-5FCC-48A9-8D1F-2F299B3FF3EE@opencsw.org> Hi, Am 10.11.2010 um 16:49 schrieb Maciej (Matchek) Blizinski: >> b) it contains a reference to the full copyright file. That file >> should live under /opt/csw/share/doc somewhere. > > What if the file contains more than one reference to a file in > /otp/csw/share/doc? Is it allowed? Is the file allowed to contain > text other than the reference? How much of it is allowed? > >> Note that it may NOT always be /opt/csw/share/doc/[softwarename], >> since some packages, for valid reasons, keep their docs under >> /opt/csw/share/doc/[somethingelse] >> It makes the most sense to me, to keep the copyright notice in the >> same place as (the rest of the docs for the package) > > Does every package contain the actual copyright file, or can one > package reference a license file contained in another package? IMHO there is exactly one reason why a package does not contain the license at /opt/csw/share/doc//license and that is because the license is unknown. In all other cases I would consider it an error. Best regards -- Dago From blizinski at google.com Fri Nov 5 08:52:12 2010 From: blizinski at google.com (Maciej (Matchek) Blizinski) Date: Fri, 5 Nov 2010 07:52:12 +0000 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> Message-ID: How about: "build description" or "package build description"? The word "repository" is not necessary here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Wed Nov 10 19:18:16 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 10 Nov 2010 19:18:16 +0100 Subject: [csw-maintainers] Packaging DBD::Sybase: need Sybase 12.5 x86 32 bit Message-ID: <716DB9DD-63AC-4DF5-8D9E-F5A33629EEBE@opencsw.org> Hi, 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... Anyway, if you have one at just drop me a note. Best regards -- Dago From phil at bolthole.com Wed Nov 10 20:29:32 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 10 Nov 2010 11:29:32 -0800 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> Message-ID: which "here" are you talking about? perjaps you need ti give a full example of what you are talking about. for what I'm talking about, "description" is inappropriate. On Friday, November 5, 2010, Maciej (Matchek) Blizinski wrote: > How about: "build description" or "package build description"? The word "repository" is not necessary here. > From skayser at opencsw.org Thu Nov 11 00:22:21 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 11 Nov 2010 00:22:21 +0100 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> <20101105162742.GA15588@sebastiankayser.de> Message-ID: <4CDB292D.3090108@opencsw.org> Philip Brown wrote on 05.11.2010 17:56: > On 11/5/10, Sebastian Kayser wrote: >> * Philip Brown wrote: >>> >>> OPENCSW_REPOSITORY=https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/software/trunk at 12345 >>> >>> That does not refer to a specific file. >>> >>> If we are planning to make OPENCSW_REPOSITORY visible in our package >>> information webpage, then "description" does not fit that information. >> >> Isn't what the user sees once he clicks this sort of link (adjusted to >> be browser-usable of course) a build description? I tend to agree with >> Maciej that the location is an implementation detail and the field name >> should describe what content the link is pointing to. > > That would only be true, if you CHANGE the link. > Clearly, the link as it currently stands, points to a directory that > it was built from, not a file. True, somehow I was mistaken that it would point to the Makefile instead of the directory. Which is fine with me. Sorry for the confusion. Regarding the naming, the URL points to a certain point-in-time-copy of the build directory that as a whole represents or "describes" how the currently published package version was built. So if it stays as is (i.e. with revision information) "package build description" IMHO fits the bill, but I'll also be happy with Jonathan's suggestion of "package build repository" (although this somehow implies a moving target). Anyway, it's a matter of two different words. I'd rather care about the actual implementation. Phil, any chance you got round to add the OPENCSW_REPOSITORY field to the database yet? Please yell once that's done so that someone (if need be, me) can go ahead and adjust the wordpress stuff. Sebastian From phil at bolthole.com Thu Nov 11 06:44:29 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 10 Nov 2010 21:44:29 -0800 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs cups In-Reply-To: References: <201011081957.oA8JvUVW025660@login.bo.opencsw.org> Message-ID: >>Do we have the specifics of the proposal up somewhere, either ?on main >> site, or on wiki? > > There is a best practices writeup on the wiki, on the checkpkg error > tags page, about the shared-lib-pkgname-mismatch tag. ?It links to the > original discussion on the mailing list; the rationale is written up > in the first post. it's late. I intend to reply in more depth tomorrow. however I wanted to give you a chance to use the crosstimezone delay to address this issue; pointing to a mailing list thread, and references in gar, do not make for a policy writeup. or even a good proposal writeup, after the initial "what do you guys think?" email if people are going to be able to follow either a proposal or policy, it needs to be written up as an explicit document unto itself. someone needs to properly write up a web page for it, and then we can iron out the rough points. I'm hoping you might do that in the next 12 hrs or so. if you dont, then I will take it on. I'd rather not have the extra work for myself though From phil at bolthole.com Thu Nov 11 07:03:35 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 10 Nov 2010 22:03:35 -0800 Subject: [csw-maintainers] ntop ... Message-ID: the nice folks at w.l. gore. are requesting a newer version of ntop. (they give us a fallback build machine to use) anyone willing to take this on? From dam at opencsw.org Thu Nov 11 09:18:15 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 11 Nov 2010 09:18:15 +0100 Subject: [csw-maintainers] ntop ... In-Reply-To: References: Message-ID: <3ACA07E9-DE64-4147-BF13-E4A686BA8958@opencsw.org> Hi, Am 11.11.2010 um 07:03 schrieb Philip Brown: > the nice folks at w.l. gore. are requesting a newer version of ntop. > (they give us a fallback build machine to use) > > anyone willing to take this on? Roger took a good shot at 3.3.10 some time ago. Roger: was it releasable? Have you submitted the autoconf-changes back upstream? I'll try to bump to 4.0.1 in the meantime. As I vaguely remember ntop was pretty hard to build I would really love some help. Of course I'll commit often and early. Best regards -- Dago From maciej at opencsw.org Thu Nov 11 11:27:26 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 11 Nov 2010 10:27:26 +0000 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 10 de Novembro de 2010 19:29, Philip Brown escreveu: > which "here" are you talking about? perjaps you need ti give a full > example of what you are talking about. > for what I'm talking about, "description" is inappropriate. I meant the anchor text for a link to package's build description, such as a Makefile describing how CSWfoo was built. Here's another example: http://pkg.opencsw.org/pkgbrowser/reports/pkgbrowse-maciej.html#c91b5add71df022951999ca87fdfab78 (The expression used in this example is "Build source code".) From dam at opencsw.org Thu Nov 11 15:11:11 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 11 Nov 2010 15:11:11 +0100 Subject: [csw-maintainers] Website registration for CSWoldapdevel is wrong Message-ID: Hi, this http://www.opencsw.org/packages/CSWoldapdevel/ show still the old package version and Alex Moore as maintainer. Phil: Would you mind having a look? Best regards -- Dago From maciej at opencsw.org Thu Nov 11 16:35:45 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 11 Nov 2010 15:35:45 +0000 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs cups In-Reply-To: References: <201011081957.oA8JvUVW025660@login.bo.opencsw.org> Message-ID: No dia 11 de Novembro de 2010 05:44, Philip Brown escreveu: >>>Do we have the specifics of the proposal up somewhere, either ?on main >>> site, or on wiki? >> >> There is a best practices writeup on the wiki, on the checkpkg error >> tags page, about the shared-lib-pkgname-mismatch tag. ?It links to the >> original discussion on the mailing list; the rationale is written up >> in the first post. > > > it's late. I intend to reply in more depth tomorrow. however I wanted > to give you a chance to use the crosstimezone delay to address this > issue; > > pointing to a mailing list thread, and references in gar, do not make > for a policy writeup. or even a good proposal writeup, after the > initial "what do you guys think?" email > > if people are going to be able to follow either a proposal or policy, > it needs to be written up as an explicit document ?unto itself. Fair enough. I wrote it up, here's the link: http://wiki.opencsw.org/packaging-shared-libraries Maciej From phil at bolthole.com Thu Nov 11 17:53:06 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 11 Nov 2010 08:53:06 -0800 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: <4CDB292D.3090108@opencsw.org> References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> <20101105162742.GA15588@sebastiankayser.de> <4CDB292D.3090108@opencsw.org> Message-ID: On 11/10/10, Sebastian Kayser wrote: > ... > Anyway, it's a matter of two different words. I'd rather care about the > actual implementation. Phil, any chance you got round to add the > OPENCSW_REPOSITORY field to the database yet? Please yell once that's > done so that someone (if need be, me) can go ahead and adjust the > wordpress stuff. Hmmm... Do we get to use a fixed length for the field? if so, which length? If not.. varchars suck for performance. Maybe we should put in a side table indexed by software name? From phil at bolthole.com Thu Nov 11 17:54:55 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 11 Nov 2010 08:54:55 -0800 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> Message-ID: On 11/11/10, Maciej (Matchek) Blizinski wrote: > No dia 10 de Novembro de 2010 19:29, Philip Brown > escreveu: >> which "here" are you talking about? perjaps you need ti give a full >> example of what you are talking about. >> for what I'm talking about, "description" is inappropriate. > > I meant the anchor text for a link to package's build description, > such as a Makefile describing how CSWfoo was built. > aha. Okay, I (and I think most others) have been mostly referring to the *existing* pkginfo field, OPENCSW_REPOSITORY. You seem to be referring to a whole new thing you'd like to propose adding to the format. Personally, I think it makes the most sense to just go with the existing information. Adding an additional line specifically to the Makefile, seems rather redundant. From dam at opencsw.org Thu Nov 11 17:57:32 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 11 Nov 2010 17:57:32 +0100 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> <20101105162742.GA15588@sebastiankayser.de> <4CDB292D.3090108@opencsw.org> Message-ID: Hi Phil, Am 11.11.2010 um 17:53 schrieb Philip Brown: > On 11/10/10, Sebastian Kayser wrote: >> ... >> Anyway, it's a matter of two different words. I'd rather care about >> the >> actual implementation. Phil, any chance you got round to add the >> OPENCSW_REPOSITORY field to the database yet? Please yell once that's >> done so that someone (if need be, me) can go ahead and adjust the >> wordpress stuff. > > Hmmm... > Do we get to use a fixed length for the field? No. And I won't accept one for technical reasons. > If not.. varchars suck for performance. How much traffic do we have? One hit per minute or less? Best regards -- Dago From phil at bolthole.com Thu Nov 11 18:02:26 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 11 Nov 2010 09:02:26 -0800 Subject: [csw-maintainers] License / copyright files in packages In-Reply-To: References: Message-ID: On 11/10/10, Maciej (Matchek) Blizinski wrote: > >> there are exactly two expected cases for the copyright file. >> >> a) it contains the copyright in its entirety. Stop. Nothing to see here :) > > What if the file is, let's say, 1 line long and does not contain a > reference? In theory, it could be "This software is in the public domain". I see that as perfectly valid. I also dont see why you are attempting to be so strict about this. I think it would be acceptable error checking to have the following flow: 1. does "i copyright" exist? if no, then error 2. does it reference specific files under /opt/csw/share/doc? 2.1 Do those files exist? if no, then error Done. The one loophole in this I can think of, is that in the case where a package is completely useless without another package being present, I could see it possibly being acceptable to reference the license file installed from another package. You could, only in that case, consider the combination of packages to be "the distribution of the software", and license conditions such as GPL, will be satisfied. Otherwise, the license needs to be in the same package as the software. From phil at bolthole.com Thu Nov 11 18:04:10 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 11 Nov 2010 09:04:10 -0800 Subject: [csw-maintainers] Website registration for CSWoldapdevel is wrong In-Reply-To: References: Message-ID: Okay, done. Note that we still have "newer" ldap packages sitting pending in newpkgs. I dont remmeber what they are pending ON, but I dont think it was me. On 11/11/10, Dagobert Michelsen wrote: > Hi, > > this > http://www.opencsw.org/packages/CSWoldapdevel/ > show still the old package version and Alex Moore as maintainer. > > Phil: Would you mind having a look? > > > Best regards > > -- Dago > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From dam at opencsw.org Thu Nov 11 18:06:57 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 11 Nov 2010 18:06:57 +0100 Subject: [csw-maintainers] Website registration for CSWoldapdevel is wrong In-Reply-To: References: Message-ID: <2D28BCB5-A080-456F-84C8-D4D060578DF5@opencsw.org> Hi Phil, Am 11.11.2010 um 18:04 schrieb Philip Brown: > Okay, done. Thanks! > Note that we still have "newer" ldap packages sitting pending in > newpkgs. > I dont remmeber what they are pending ON, but I dont think it was me. Right, AFAIR Geoff has made some changes. Geoff, Rupert: Would you mind coordinating what you have done and maybe repackage if necessary? Best regards -- Dago From bwalton at opencsw.org Thu Nov 11 18:08:16 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 11 Nov 2010 12:08:16 -0500 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <4CD32FDD.3020606@opencsw.org> <1288914849-sup-5134@pinkfloyd.chass.utoronto.ca> <20101105162742.GA15588@sebastiankayser.de> <4CDB292D.3090108@opencsw.org> Message-ID: <1289495253-sup-1575@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Thu Nov 11 11:57:32 -0500 2010: > > If not.. varchars suck for performance. > > How much traffic do we have? One hit per minute or less? ...and as with php file includes, if the varchars are slowing things down enough to be noticable, please retire the server. :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From skayser at opencsw.org Thu Nov 11 18:10:50 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 11 Nov 2010 18:10:50 +0100 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: References: <20101105162742.GA15588@sebastiankayser.de> <4CDB292D.3090108@opencsw.org> Message-ID: <20101111171050.GP28050@sebastiankayser.de> * Dagobert Michelsen wrote: > Am 11.11.2010 um 17:53 schrieb Philip Brown: > >On 11/10/10, Sebastian Kayser wrote: > >>... > >>Anyway, it's a matter of two different words. I'd rather care about > >>the > >>actual implementation. Phil, any chance you got round to add the > >>OPENCSW_REPOSITORY field to the database yet? Please yell once that's > >>done so that someone (if need be, me) can go ahead and adjust the > >>wordpress stuff. > > > >Hmmm... > >Do we get to use a fixed length for the field? > > No. And I won't accept one for technical reasons. > > >If not.. varchars suck for performance. > > How much traffic do we have? One hit per minute or less? Side note (out of curiosity): Besides the marginal hits, does it even matter? We are not going to search this column, just grab it's value for a known package. Sebastian From phil at bolthole.com Thu Nov 11 18:45:39 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 11 Nov 2010 09:45:39 -0800 Subject: [csw-maintainers] http://www.opencsw.org/packages/: Add GAR build recipe URL to package page? In-Reply-To: <20101111171050.GP28050@sebastiankayser.de> References: <20101105162742.GA15588@sebastiankayser.de> <4CDB292D.3090108@opencsw.org> <20101111171050.GP28050@sebastiankayser.de> Message-ID: On 11/11/10, Sebastian Kayser wrote: > * Dagobert Michelsen wrote: >> Am 11.11.2010 um 17:53 schrieb Philip Brown: >> >> >If not.. varchars suck for performance. > > Side note (out of curiosity): Besides the marginal hits, does it even > matter? We are not going to search this column, just grab it's value for > a known package. > having a varchar in a table, torpedoes performance of the ENTIRE TABLE to some degree. It's irrelevant whether or not you search on it or not. Good databases tend to do interesting optimizations based on "I can guarantee that the start of record 'X' is exactly 'Y' bytes into the file/memory space". Granted, performance on this table isnt exactly critical now. But as a matter of good principle, I like to keep things clean and fairly optimal from the start, rather than have to figure out a year or two later, "Oh.. gee, I have to go back and straighten this stuff up now..." From dam at opencsw.org Thu Nov 11 19:09:46 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 11 Nov 2010 19:09:46 +0100 Subject: [csw-maintainers] ntop ... In-Reply-To: <3ACA07E9-DE64-4147-BF13-E4A686BA8958@opencsw.org> References: <3ACA07E9-DE64-4147-BF13-E4A686BA8958@opencsw.org> Message-ID: Hi, Am 11.11.2010 um 09:18 schrieb Dagobert Michelsen: > Am 11.11.2010 um 07:03 schrieb Philip Brown: >> the nice folks at w.l. gore. are requesting a newer version of ntop. >> (they give us a fallback build machine to use) >> >> anyone willing to take this on? > > Roger took a good shot at 3.3.10 some time ago. Roger: was it > releasable? Have you submitted the autoconf-changes back > upstream? > > I'll try to bump to 4.0.1 in the meantime. As I vaguely remember > ntop was pretty hard to build I would really love some help. > Of course I'll commit often and early. I have made the first 90% so it compiles cleanly and made a package, everything is committed. What is missing now are the second 90% finetuning the start scripts etc. I won't have much time to work on this for the next two weeks, so maybe someone wants to jump in and earn the merits of release? Best regards -- Dago From gadavis at opencsw.org Thu Nov 11 19:44:14 2010 From: gadavis at opencsw.org (Geoff Davis) Date: Thu, 11 Nov 2010 10:44:14 -0800 Subject: [csw-maintainers] Website registration for CSWoldapdevel is wrong In-Reply-To: <2D28BCB5-A080-456F-84C8-D4D060578DF5@opencsw.org> References: <2D28BCB5-A080-456F-84C8-D4D060578DF5@opencsw.org> Message-ID: <8F19397C-8254-437B-A685-FE670986D59A@opencsw.org> Hi all, My changes are to a couple of ancillary files and shouldn't affect the whole packaging effort. They are all checked in to Gar so a rebuild should get them included. On Nov 11, 2010, at 9:06, Dagobert Michelsen wrote: > Hi Phil, > > Am 11.11.2010 um 18:04 schrieb Philip Brown: >> Okay, done. > > Thanks! > >> Note that we still have "newer" ldap packages sitting pending in newpkgs. >> I dont remmeber what they are pending ON, but I dont think it was me. > > Right, AFAIR Geoff has made some changes. > > Geoff, Rupert: Would you mind coordinating what you have done and maybe > repackage if necessary? > > > Best regards > > -- Dago > From rupert at opencsw.org Sat Nov 13 13:23:59 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 13 Nov 2010 13:23:59 +0100 Subject: [csw-maintainers] maven3 - java package for all architectures Message-ID: hi, i tried to copy maven2 to build maven3, and checked it also in for reference. the package is java and does not build as such. which java package would be the best one to look at to get some ideas how to make it build? rupert. From maciej at opencsw.org Sat Nov 13 16:01:38 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 13 Nov 2010 15:01:38 +0000 Subject: [csw-maintainers] Positioning our website Message-ID: I just made a search for "solaris packages" on Google and I saw that out of the first 10 results: 3 are actual Solaris package projects (we aren't any of the 3) 3 are packaging howtos 2 are pages that just point to other pages and provide little actual materials 1 belongs to a specific open source project which offers Solaris packages 1 is a blog entry on Wordpress.com I wrote some time ago Not seeing opencsw.org within first 10 results is depressing. Our website was the result number 20, the last one on the second page. This is of course better than nothing, but I believe we deserve a better position. I see two things we can do to improve the situation. The first one is our domain registration. Here's a snippet from whois: Domain ID:D153552903-LROR Domain Name:OPENCSW.ORG Created On:08-Aug-2008 08:29:30 UTC Last Updated On:14-Sep-2010 20:19:19 UTC Expiration Date:08-Aug-2011 08:29:30 UTC I'm not sure what the "Last updated" field means here, whether it was the renewal date or an unrelated metadata update. In either case, I believe that extending our registration to 2 or 3 years into the future would give us a huge boost. Google considers domains that are registered for a short duration less trustworthy and demotes them in search results. Extending the registration can be a really quick fix for our positioning. Dago, can you take care of that? The other suggestion requires more people to work together. There are essentially two things we can try doing: - work on moving opencsw.org up until it gets into the first 10 - create pages that can get into the first 10 If my blog post can get into the first 10, many other pages can too. For instance, I know that some of us write blogs. If you keep on writing blog posts with the "solaris packages" phrase in the tag, and linking to opencsw.org, it'll help both sites. The page rank of opencsw.org will go up - good! If it's your blog post and not opencsw.org that makes it into the first 10, that's great too. If your blog post has a link to opencsw.org, people will click on it and learn about our project, and potentially start using our packages. I'm going to start by writing yet another Solaris packaging howto, focused on using GAR and being short. It's something I meant to do anyway, but after looking the positioning issue, I'll make sure my howto's title contains "solaris packages" and features prominent links to opencsw.org. Do other people have topics they can write about? Maciej From dam at opencsw.org Sat Nov 13 16:13:00 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 13 Nov 2010 16:13:00 +0100 Subject: [csw-maintainers] Positioning our website In-Reply-To: <AANLkTi=-E89BOEdLv0WhWxbBT4zMzLPFDh3POUpWqvjc@mail.gmail.com> References: <AANLkTi=-E89BOEdLv0WhWxbBT4zMzLPFDh3POUpWqvjc@mail.gmail.com> Message-ID: <9A606DB6-E838-4552-B08B-A278AE3B1D49@opencsw.org> Hi Maciej, Am 13.11.2010 um 16:01 schrieb Maciej (Matchek) Blizinski: > The first one is our domain registration. Here's a snippet from > whois: > > Domain ID:D153552903-LROR > Domain Name:OPENCSW.ORG > Created On:08-Aug-2008 08:29:30 UTC > Last Updated On:14-Sep-2010 20:19:19 UTC > Expiration Date:08-Aug-2011 08:29:30 UTC > > I'm not sure what the "Last updated" field means here, whether it was > the renewal date or an unrelated metadata update. In either case, I > believe that extending our registration to 2 or 3 years into the > future would give us a huge boost. Google considers domains that are > registered for a short duration less trustworthy and demotes them in > search results. Extending the registration can be a really quick fix > for our positioning. Dago, can you take care of that? Sure, request to my registrar sent. > The other suggestion requires more people to work together. There are > essentially two things we can try doing: > > - work on moving opencsw.org up until it gets into the first 10 I proposed a change to the front page, but somehow William is busy right now so it has not been done yet: Anfang der weitergeleiteten E-Mail: > Von: Dagobert Michelsen <dam at baltic-online.de> > Datum: 25. August 2010 14:47:42 MESZ > An: List for OpenCSW maintainers <maintainers at lists.opencsw.org> > Kopie: William Bonnet <wbonnet at opencsw.org> > Betreff: Reorganiation of webpage > > Hi, > > I gave the website some more thought. Personally I find the "Latest > News" section > not really useful as I have to click on it. The news should be > relocated/merged > with "Latest Announcements". > > The "Download" box occupies a lot of valuable space not used often. > I recommend > removing the box and renaming "Get it" to the more catchy "Download". > > Further I would think "Feeds" as second item in the top-bar should > be moved to the > right as it will be used only sporadically. > > One more thing: On http://www.opencsw.org/support/ the link in > "If you want to immediately use our software, you can go through the > quickstart > documentation page" to quickstart is broken. > > Feedback welcome! > > > Best regards > > -- Dago Maybe someone has the permissions to make the necessary change? Best regards -- Dago From bwalton at opencsw.org Sat Nov 13 19:35:44 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 13 Nov 2010 13:35:44 -0500 Subject: [csw-maintainers] http://www.opencsw.org/packages/<pkg>: Add GAR build recipe URL to package page? In-Reply-To: <AANLkTimW2xVb=nwQuqKi7G1Qgb21GRttoZ7JOJGPboGT@mail.gmail.com> References: <AANLkTinDZMHfx3gf=unSnYWPhpPGzcM4ppmg3pfeYntu@mail.gmail.com> <AANLkTi=oCjs+VqVvr8iAkApYAcXpDurhSmE+heEv79e=@mail.gmail.com> <AANLkTim1d82p_u9+YpT877jQRpb0dz4HqzFTVs+zHi1M@mail.gmail.com> <AANLkTi=CfQpjWCn4R72QzX=6nKZkf3OKDrc_tjBAvYFe@mail.gmail.com> <AANLkTikFLm7HBncpo4tqCB0aD+0NKC8f07wZ3jopA7ys@mail.gmail.com> <20101105162742.GA15588@sebastiankayser.de> <AANLkTi=qiP57EoqARAaCK=nPgxw+U2B=-fWvx3KKs7V=@mail.gmail.com> <4CDB292D.3090108@opencsw.org> <AANLkTikYhpD4mZ0-Xx9jMRYZzzOBaY65S0jqHY0OwoYi@mail.gmail.com> <EDB0F459-82F6-42E8-9E39-44141E84EE57@opencsw.org> <20101111171050.GP28050@sebastiankayser.de> <AANLkTimW2xVb=nwQuqKi7G1Qgb21GRttoZ7JOJGPboGT@mail.gmail.com> Message-ID: <1289672497-sup-4152@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Nov 11 12:45:39 -0500 2010: > Granted, performance on this table isnt exactly critical now. But as > a matter of good principle, I like to keep things clean and fairly > optimal from the start, rather than have to figure out a year or two > later, "Oh.. gee, I have to go back and straighten this stuff up > now..." http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize ...Anyway, with either CHAR or VARCHAR, we still need to choose a maximum length. With CHAR the MySQL limit is 255. Without going outside of portable POSIX ranges for file paths, that should be enough even in the extreme cases. If we wanted to allow the svn path to grow to what Solaris would allow, then a VARCHAR(1023) is required. I don't think our svn reference paths will approach this (or at least they shouldn't). I also think that the common portion of the SourceForge.net URL should be stripped out of the storage here and appended by php as a statically defined string in the code. Thoughts? -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From jeff at cjsa.com Sun Nov 14 00:54:59 2010 From: jeff at cjsa.com (Jeffery Small) Date: Sat, 13 Nov 2010 23:54:59 GMT Subject: [csw-maintainers] New release of vim editor? Message-ID: <LBuL3n.LG8@cjsa.com> The last release of vim was April 9, 2009. There has been a newer 7.3 version for quite some time. Is the current maintainer, Chad Harp, still working on the project? I sent him an email regarding this long ago but never received a reply. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From rupert at opencsw.org Sun Nov 14 00:59:30 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 14 Nov 2010 00:59:30 +0100 Subject: [csw-maintainers] Positioning our website In-Reply-To: <9A606DB6-E838-4552-B08B-A278AE3B1D49@opencsw.org> References: <AANLkTi=-E89BOEdLv0WhWxbBT4zMzLPFDh3POUpWqvjc@mail.gmail.com> <9A606DB6-E838-4552-B08B-A278AE3B1D49@opencsw.org> Message-ID: <AANLkTimnAH1hG+oY9ntVRGcT7qOxMmchxJAKbZdm2=YJ@mail.gmail.com> On Sat, Nov 13, 2010 at 16:13, Dagobert Michelsen <dam at opencsw.org> wrote: > Hi Maciej, > > Am 13.11.2010 um 16:01 schrieb Maciej (Matchek) Blizinski: >> >> The first one is our domain registration. ?Here's a snippet from whois: >> >> Domain ID:D153552903-LROR >> Domain Name:OPENCSW.ORG >> Created On:08-Aug-2008 08:29:30 UTC >> Last Updated On:14-Sep-2010 20:19:19 UTC >> Expiration Date:08-Aug-2011 08:29:30 UTC >> >> I'm not sure what the "Last updated" field means here, whether it was >> the renewal date or an unrelated metadata update. ?In either case, I >> believe that extending our registration to 2 or 3 years into the >> future would give us a huge boost. ?Google considers domains that are >> registered for a short duration less trustworthy and demotes them in >> search results. ?Extending the registration can be a really quick fix >> for our positioning. ?Dago, can you take care of that? > > Sure, request to my registrar sent. > >> The other suggestion requires more people to work together. ?There are >> essentially two things we can try doing: >> >> - work on moving opencsw.org up until it gets into the first 10 > > I proposed a change to the front page, but somehow William is > busy right now so it has not been done yet: > > Anfang der weitergeleiteten E-Mail: > >> Von: Dagobert Michelsen <dam at baltic-online.de> >> Datum: 25. August 2010 14:47:42 MESZ >> An: List for OpenCSW maintainers <maintainers at lists.opencsw.org> >> Kopie: William Bonnet <wbonnet at opencsw.org> >> Betreff: Reorganiation of webpage >> >> Hi, >> >> I gave the website some more thought. Personally I find the "Latest News" >> section >> not really useful as I have to click on it. The news should be >> relocated/merged >> with "Latest Announcements". >> >> The "Download" box occupies a lot of valuable space not used often. I >> recommend >> removing the box and renaming "Get it" to the more catchy "Download". >> >> Further I would think "Feeds" as second item in the top-bar should be >> moved to the >> right as it will be used only sporadically. >> >> One more thing: On http://www.opencsw.org/support/ the link in >> "If you want to immediately use our software, you can go through the >> quickstart >> documentation page" to quickstart is broken. >> >> Feedback welcome! yes, streamlining is a good idea :) when linking to opencsw.org from outside i noticed that it is not that easy to directly link the correct page. a couple of suggestions: 1. about should not contain "install". 2. about - history what about a direct link instead "the OpenCSW Wiki under the ?Association? section." 3. get it (or: download) should offer a start without clicking again, either with pkg-get or pkgutil for solaris 10. and below, the current sofware list should be displayed. options are: pkg-get, pkgutil, manual download (linked to "mirror sites"). 4. get it - release branches move the contents, shortened, to "get it - stable", "get it - current (was: software list)", "get it - experimental". 5. get it - software list remove experimental, mirror, manual download sections. 6. use it remove the top titel and merge into support 7. use it remove the blastwave hint, should be enough to have it in the dedicated page. move "release program" (a shortened version?) to "about". 8. use it, the tools, how to upgrade remove, both are empty 9. use it, migration from blastwave move to faq rupert. From bwalton at opencsw.org Sun Nov 14 01:51:24 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 13 Nov 2010 19:51:24 -0500 Subject: [csw-maintainers] New release of vim editor? In-Reply-To: <LBuL3n.LG8@cjsa.com> References: <LBuL3n.LG8@cjsa.com> Message-ID: <1289695755-sup-8520@pinkfloyd.chass.utoronto.ca> Excerpts from jeff's message of Sat Nov 13 18:54:59 -0500 2010: Hi Jeff, > The last release of vim was April 9, 2009. There has been a newer > 7.3 version for quite some time. Is the current maintainer, Chad > Harp, still working on the project? I sent him an email regarding > this long ago but never received a reply. Although Chad is listed as active, I've not seen activity in quite a while. I don't think anybody would dispute a take over of the package if it's something you're interested in. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Sun Nov 14 14:54:45 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 14 Nov 2010 14:54:45 +0100 Subject: [csw-maintainers] New release of vim editor? In-Reply-To: <1289695755-sup-8520@pinkfloyd.chass.utoronto.ca> References: <LBuL3n.LG8@cjsa.com> <1289695755-sup-8520@pinkfloyd.chass.utoronto.ca> Message-ID: <A70F2185-87F7-4B87-A527-86CB06B06E9E@opencsw.org> Hi, Am 14.11.2010 um 01:51 schrieb Ben Walton: > Excerpts from jeff's message of Sat Nov 13 18:54:59 -0500 2010: >> The last release of vim was April 9, 2009. There has been a newer >> 7.3 version for quite some time. Is the current maintainer, Chad >> Harp, still working on the project? I sent him an email regarding >> this long ago but never received a reply. > > Although Chad is listed as active, I've not seen activity in quite a > while. I don't think anybody would dispute a take over of the package > if it's something you're interested in. He is on sabbatical to be presise. I bumped vim tpo 7.3p011, but: Ben, the patches are not recognized by the new GIT mechanism, would you mind having a look? https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/vim/trunk Best regards -- Dago From bwalton at opencsw.org Sun Nov 14 17:00:18 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 14 Nov 2010 11:00:18 -0500 Subject: [csw-maintainers] New release of vim editor? In-Reply-To: <A70F2185-87F7-4B87-A527-86CB06B06E9E@opencsw.org> References: <LBuL3n.LG8@cjsa.com> <1289695755-sup-8520@pinkfloyd.chass.utoronto.ca> <A70F2185-87F7-4B87-A527-86CB06B06E9E@opencsw.org> Message-ID: <1289750307-sup-2698@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sun Nov 14 08:54:45 -0500 2010: Hi Dago, > Ben, the patches are not recognized by the new GIT mechanism, would > you mind having a look? > https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/vim/trunk The patches it's trying to apply don't exist...? It's building the PATCHFILES dynamically using the current PATCHREV and trying to reference 001 - $(PATCHREV). It ends up creating symlinks to non-existent files in /home/src. The patch mechanism them bails trying apply a non-existent file. I think you should just comment out PATCHFILES or possibly use the two .patch files in files/ as they do exist. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Sun Nov 14 21:28:45 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 14 Nov 2010 21:28:45 +0100 Subject: [csw-maintainers] New release of vim editor? In-Reply-To: <1289750307-sup-2698@pinkfloyd.chass.utoronto.ca> References: <LBuL3n.LG8@cjsa.com> <1289695755-sup-8520@pinkfloyd.chass.utoronto.ca> <A70F2185-87F7-4B87-A527-86CB06B06E9E@opencsw.org> <1289750307-sup-2698@pinkfloyd.chass.utoronto.ca> Message-ID: <A5A27E07-518A-46AE-A533-F87F729EAF53@opencsw.org> Hi Ben, Am 14.11.2010 um 17:00 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Sun Nov 14 08:54:45 -0500 2010: >> Ben, the patches are not recognized by the new GIT mechanism, would >> you mind having a look? >> https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/vim/trunk > > The patches it's trying to apply don't exist...? It's building the > PATCHFILES dynamically using the current PATCHREV and trying to > reference 001 - $(PATCHREV). It ends up creating symlinks to > non-existent files in /home/src. > > The patch mechanism them bails trying apply a non-existent file. Umh... no: > ==> Applying patch work/solaris9-sparc/download/7.3.001 > Patch format detection failed. > gmake[1]: *** [normal-patch-7.3.001] Error 1 > gmake[1]: Leaving directory `/home/dam/mgar/pkg/vim/trunk' > gmake: *** [merge-isa-sparcv8] Error 2 > current9s% ls -l work/solaris9-sparc/download/7.3.001 > lrwxrwxrwx 1 dam csw 17 Nov 14 21:23 work/solaris9-sparc/download/7.3.001 -> /home/src/7.3.001 > current9s% ls -lL work/solaris9-sparc/download/7.3.001 > -rw-r--r-- 1 dam csw 1720 Sep 29 09:36 work/solaris9-sparc/download/7.3.001 > current9s% more work/solaris9-sparc/download/7.3.001 > To: vim-dev at vim.org > Subject: Patch 7.3.001 > Fcc: outbox > From: Bram Moolenaar <Bram at moolenaar.net> > Mime-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > ------------ > > Patch 7.3.001 > Problem: When editing "src/main.c" and 'path' set to "./proto", > ":find e<C-D" shows ./proto/eval.pro instead of eval.pro. > Solution: Check for path separator when comparing names. (Nazri Ramliy) > Files: src/misc1.c > > > *** ../vim-7.3.000/src/misc1.c 2010-08-15 21:57:27.000000000 +0200 > --- src/misc1.c 2010-08-16 20:43:25.000000000 +0200 > *************** > *** 9317,9323 **** > continue; /* it's different when it's shorter */ > > rival = other_paths[j] + other_path_len - candidate_len; > ! if (fnamecmp(maybe_unique, rival) == 0) > return FALSE; /* match */ > } > > --- 9317,9324 ---- > continue; /* it's different when it's shorter */ > > rival = other_paths[j] + other_path_len - candidate_len; > ! if (fnamecmp(maybe_unique, rival) == 0 > ! && (rival == other_paths[j] || vim_ispathsep(*(rival - 1)))) > return FALSE; /* match */ > } > > *** ../vim-7.3.000/src/version.c 2010-08-15 21:57:25.000000000 +0200 > --- src/version.c 2010-08-16 20:53:09.000000000 +0200 > *************** > *** 716,717 **** > --- 716,719 ---- > { /* Add new patch number below this line */ > + /**/ > + 1, > /**/ > > > -- > From "know your smileys": > (:-# Said something he shouldn't have > > /// Bram Moolenaar -- Bram at Moolenaar.net -- http://www.Moolenaar.net \\\ > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ download, build and distribute -- http://www.A-A-P.org /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// > current9s% Do you have another idea? Best regards -- Dago From bwalton at opencsw.org Sun Nov 14 21:51:00 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 14 Nov 2010 15:51:00 -0500 Subject: [csw-maintainers] New release of vim editor? In-Reply-To: <A5A27E07-518A-46AE-A533-F87F729EAF53@opencsw.org> References: <LBuL3n.LG8@cjsa.com> <1289695755-sup-8520@pinkfloyd.chass.utoronto.ca> <A70F2185-87F7-4B87-A527-86CB06B06E9E@opencsw.org> <1289750307-sup-2698@pinkfloyd.chass.utoronto.ca> <A5A27E07-518A-46AE-A533-F87F729EAF53@opencsw.org> Message-ID: <1289767342-sup-4311@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sun Nov 14 15:28:45 -0500 2010: Hi Dago, > Umh... no: Not sure what I was looking at this morning, but I didn't see real files backing those patches. Anyway... The problem is the detection of git crafted patches from non-git ones. I look for Subject: in the body of the patch thinking that the only patch files with that string would be git-format-patch output. This looks to be a partial mbox-style patch and has the Subject: header as well. I just tuned the heuristic to look for 'diff --git' in the patch file instead. Try again, please. The patch step looks good to me now... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Mon Nov 15 09:30:42 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 15 Nov 2010 08:30:42 +0000 Subject: [csw-maintainers] CSWgtar - Segmentation Fault (core dumped) Message-ID: <AANLkTi=0x6zyQ6ZK+LOwr+5d_go0L_uqsg=X1O6Ur3Us@mail.gmail.com> Has anyone else seen the following symptom? maciej at unknown ~/src/examplepkg $ gtar xfvz hello-0.1.0.tar.gz hello-0.1.0/hello.texinfo Segmentation Fault (core dumped) maciej at unknown ~/src/examplepkg $ which gtar /opt/csw/bin/gtar maciej at unknown ~/src/examplepkg $ gmd5sum /opt/csw/bin/gtar e015e4bcfb1f4094bbe854d49f534640 /opt/csw/bin/gtar maciej at unknown ~/src/examplepkg $ pkgparam CSWgtar VERSION 1.24,REV=2010.11.05 Maciej From maciej at opencsw.org Mon Nov 15 09:43:49 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 15 Nov 2010 08:43:49 +0000 Subject: [csw-maintainers] CSWgtar - Segmentation Fault (core dumped) In-Reply-To: <AANLkTi=0x6zyQ6ZK+LOwr+5d_go0L_uqsg=X1O6Ur3Us@mail.gmail.com> References: <AANLkTi=0x6zyQ6ZK+LOwr+5d_go0L_uqsg=X1O6Ur3Us@mail.gmail.com> Message-ID: <AANLkTi=8_c6yqv0XrOTpAsUzqdCR_+t-hZgdx6JPV3F+@mail.gmail.com> No dia 15 de Novembro de 2010 08:30, Maciej (Matchek) Blizinski <maciej at opencsw.org> escreveu: > maciej at unknown ~/src/examplepkg $ gtar xfvz hello-0.1.0.tar.gz > hello-0.1.0/hello.texinfo > Segmentation Fault (core dumped) This is on x86. On sparc, the file was unpacked successfully. I only have one x86 host to test right now, and gtar segfaults there every time (therefore, probably not a bad memory problem). From skayser at opencsw.org Mon Nov 15 10:08:16 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 15 Nov 2010 10:08:16 +0100 Subject: [csw-maintainers] CSWgtar - Segmentation Fault (core dumped) In-Reply-To: <AANLkTi=8_c6yqv0XrOTpAsUzqdCR_+t-hZgdx6JPV3F+@mail.gmail.com> References: <AANLkTi=0x6zyQ6ZK+LOwr+5d_go0L_uqsg=X1O6Ur3Us@mail.gmail.com> <AANLkTi=8_c6yqv0XrOTpAsUzqdCR_+t-hZgdx6JPV3F+@mail.gmail.com> Message-ID: <4CE0F880.4000302@opencsw.org> Maciej (Matchek) Blizinski wrote on 15.11.2010 09:43: > No dia 15 de Novembro de 2010 08:30, Maciej (Matchek) Blizinski > <maciej at opencsw.org> escreveu: >> maciej at unknown ~/src/examplepkg $ gtar xfvz hello-0.1.0.tar.gz >> hello-0.1.0/hello.texinfo >> Segmentation Fault (core dumped) > > This is on x86. On sparc, the file was unpacked successfully. I only > have one x86 host to test right now, and gtar segfaults there every > time (therefore, probably not a bad memory problem). Just tried this with tarballs from mbuffer [1] and drbd [2]. Both extracted fine. Where did you get your tarball from? Sebastian [1] http://www.maier-komor.de/software/mbuffer/mbuffer-20100526.tgz [2] http://oss.linbit.com/drbd/8.3/drbd-8.3.8.1.tar.gz From maciej at opencsw.org Mon Nov 15 10:09:55 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 15 Nov 2010 09:09:55 +0000 Subject: [csw-maintainers] CSWgtar - Segmentation Fault (core dumped) In-Reply-To: <4CE0F880.4000302@opencsw.org> References: <AANLkTi=0x6zyQ6ZK+LOwr+5d_go0L_uqsg=X1O6Ur3Us@mail.gmail.com> <AANLkTi=8_c6yqv0XrOTpAsUzqdCR_+t-hZgdx6JPV3F+@mail.gmail.com> <4CE0F880.4000302@opencsw.org> Message-ID: <AANLkTimtnhs1SdrPXskjn+uSpMnkNXdK37vA1+LXJOdj@mail.gmail.com> No dia 15 de Novembro de 2010 09:08, Sebastian Kayser <skayser at opencsw.org> escreveu: > Maciej (Matchek) Blizinski wrote on 15.11.2010 09:43: >> No dia 15 de Novembro de 2010 08:30, Maciej (Matchek) Blizinski >> <maciej at opencsw.org> escreveu: >>> maciej at unknown ~/src/examplepkg $ gtar xfvz hello-0.1.0.tar.gz >>> hello-0.1.0/hello.texinfo >>> Segmentation Fault (core dumped) >> >> This is on x86. ?On sparc, the file was unpacked successfully. ?I only >> have one x86 host to test right now, and gtar segfaults there every >> time (therefore, probably not a bad memory problem). > > Just tried this with tarballs from mbuffer [1] and drbd [2]. Both > extracted fine. Where did you get your tarball from? https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/examples/multiple-versions/trunk/files/hello-0.1.0.tar.gz (I'm working on a packaging tutorial.) Just found a bug about the gtar issue: https://www.opencsw.org/mantis/view.php?id=4601 But the bug is closed, and my issue is still occurring. My instructions to reproduce work on bender. It might be a problem which occurs on Solaris 10 U9 but not other Solaris versions. Does anyone here run Solaris 10 U9 and can test our gtar there? From james at opencsw.org Mon Nov 15 10:43:44 2010 From: james at opencsw.org (James Lee) Date: Mon, 15 Nov 2010 09:43:44 GMT Subject: [csw-maintainers] CSWgtar - Segmentation Fault (core dumped) In-Reply-To: <AANLkTimtnhs1SdrPXskjn+uSpMnkNXdK37vA1+LXJOdj@mail.gmail.com> References: <AANLkTi=0x6zyQ6ZK+LOwr+5d_go0L_uqsg=X1O6Ur3Us@mail.gmail.com> <AANLkTi=8_c6yqv0XrOTpAsUzqdCR_+t-hZgdx6JPV3F+@mail.gmail.com> <4CE0F880.4000302@opencsw.org> <AANLkTimtnhs1SdrPXskjn+uSpMnkNXdK37vA1+LXJOdj@mail.gmail.com> Message-ID: <20101115.9434400.792641895@gyor.oxdrove.co.uk> On 15/11/10, 09:09:55, Maciej "(Matchek)" Blizinski <maciej at opencsw.org> wrote regarding Re: [csw-maintainers] CSWgtar - Segmentation Fault (core dumped): > Does anyone here run Solaris 10 U9 and can test our gtar there? $ cat /etc/release Oracle Solaris 10 9/10 s10x_u9wos_14a X86 Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. Assembled 11 August 2010 $ wget --no-check-certificate https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/examples/multiple-versions/trunk/files/hello-0.1.0.tar.gz --2010-11-15 09:34:30-- https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/examples/multiple-versions/trunk/files/hello-0.1.0.tar.gz Resolving gar.svn.sourceforge.net... 216.34.181.65, 216.34.181.177 Connecting to gar.svn.sourceforge.net|216.34.181.65|:443... connected. WARNING: cannot verify gar.svn.sourceforge.net's certificate, issued by `/C=US/O=Equifax/OU=Equifax Secure Certificate Authority': Unable to locally verify the issuer's authority. HTTP request sent, awaiting response... 200 OK Length: 233426 (228K) [application/octet-stream] Saving to: `hello-0.1.0.tar.gz' 100%[====================================================>] 233,426 218K/s in 1.0s 2010-11-15 09:34:32 (218 KB/s) - `hello-0.1.0.tar.gz' saved [233426/233426] $ cksum hello-0.1.0.tar.gz 222854634 233426 hello-0.1.0.tar.gz $ gtar xfvz hello-0.1.0.tar.gz hello-0.1.0/hello.texinfo zsh: segmentation fault (core dumped) gtar xfvz hello-0.1.0.tar.gz $ rm -r hello-0.1.0 $ gzcat hello-0.1.0.tar.gz | star xf - star: 81 blocks + 4608 bytes (total of 834048 bytes = 814.50k). James. From dam at opencsw.org Mon Nov 15 10:50:55 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 15 Nov 2010 10:50:55 +0100 Subject: [csw-maintainers] CSWgtar - Segmentation Fault (core dumped) In-Reply-To: <20101115.9434400.792641895@gyor.oxdrove.co.uk> References: <AANLkTi=0x6zyQ6ZK+LOwr+5d_go0L_uqsg=X1O6Ur3Us@mail.gmail.com> <AANLkTi=8_c6yqv0XrOTpAsUzqdCR_+t-hZgdx6JPV3F+@mail.gmail.com> <4CE0F880.4000302@opencsw.org> <AANLkTimtnhs1SdrPXskjn+uSpMnkNXdK37vA1+LXJOdj@mail.gmail.com> <20101115.9434400.792641895@gyor.oxdrove.co.uk> Message-ID: <77C422FF-1D71-4F8D-A223-D71EBD63261F@opencsw.org> Hi James, Am 15.11.2010 um 10:43 schrieb James Lee: > On 15/11/10, 09:09:55, Maciej "(Matchek)" Blizinski <maciej at opencsw.org > > > wrote regarding Re: [csw-maintainers] CSWgtar - Segmentation Fault > (core > dumped): > >> Does anyone here run Solaris 10 U9 and can test our gtar there? > > > $ cat /etc/release > Oracle Solaris 10 9/10 s10x_u9wos_14a X86 > Copyright (c) 2010, Oracle and/or its affiliates. All rights > reserved. > Assembled 11 August 2010 > > > $ wget --no-check-certificate > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/examples/multiple-versions/trunk/files/hello-0.1.0.tar.gz > --2010-11-15 09:34:30-- > > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/examples/multiple-versions/trunk/files/hello-0.1.0.tar.gz > Resolving gar.svn.sourceforge.net... 216.34.181.65, 216.34.181.177 > Connecting to gar.svn.sourceforge.net|216.34.181.65|:443... connected. > WARNING: cannot verify gar.svn.sourceforge.net's certificate, issued > by > `/C=US/O=Equifax/OU=Equifax Secure Certificate Authority': > Unable to locally verify the issuer's authority. > HTTP request sent, awaiting response... 200 OK > Length: 233426 (228K) [application/octet-stream] > Saving to: `hello-0.1.0.tar.gz' > > 100%[====================================================>] 233,426 > 218K/s in 1.0s > > 2010-11-15 09:34:32 (218 KB/s) - `hello-0.1.0.tar.gz' saved > [233426/233426] > > > $ cksum hello-0.1.0.tar.gz > 222854634 233426 hello-0.1.0.tar.gz > > > $ gtar xfvz hello-0.1.0.tar.gz > hello-0.1.0/hello.texinfo > zsh: segmentation fault (core dumped) gtar xfvz hello-0.1.0.tar.gz > > > > > $ rm -r hello-0.1.0 > $ gzcat hello-0.1.0.tar.gz | star xf - > star: 81 blocks + 4608 bytes (total of 834048 bytes = 814.50k). Would you mind trying http://buildfarm.opencsw.org/experimental/dam/gtar-1.25,REV=2010.11.15-SunOS5.9-i386-CSW.pkg.gz Best regards -- Dago From james at opencsw.org Mon Nov 15 10:57:12 2010 From: james at opencsw.org (James Lee) Date: Mon, 15 Nov 2010 09:57:12 GMT Subject: [csw-maintainers] CSWgtar - Segmentation Fault (core dumped) In-Reply-To: <77C422FF-1D71-4F8D-A223-D71EBD63261F@opencsw.org> References: <AANLkTi=0x6zyQ6ZK+LOwr+5d_go0L_uqsg=X1O6Ur3Us@mail.gmail.com> <AANLkTi=8_c6yqv0XrOTpAsUzqdCR_+t-hZgdx6JPV3F+@mail.gmail.com> <4CE0F880.4000302@opencsw.org> <AANLkTimtnhs1SdrPXskjn+uSpMnkNXdK37vA1+LXJOdj@mail.gmail.com> <20101115.9434400.792641895@gyor.oxdrove.co.uk> <77C422FF-1D71-4F8D-A223-D71EBD63261F@opencsw.org> Message-ID: <20101115.9571200.3438457856@gyor.oxdrove.co.uk> On 15/11/10, 09:50:55, Dagobert Michelsen <dam at opencsw.org> wrote regarding Re: [csw-maintainers] CSWgtar - Segmentation Fault (core dumped): > Would you mind trying > http://buildfarm.opencsw.org/experimental/dam/gtar-1.25,REV=2010.11.15-Sun OS5.9-i386-CSW.pkg.gz $ pkginfo -l CSWgtar PKGINST: CSWgtar NAME: gtar - GNU tape archiver CATEGORY: application ARCH: i386 VERSION: 1.25,REV=2010.11.15 BASEDIR: / VENDOR: http://www.gnu.org/software/tar/ packaged for CSW by Dagobert Michelsen PSTAMP: dam at current9x-20101115103936 INSTDATE: Nov 15 2010 09:54 HOTLINE: http://www.opencsw.org/bugtrack/ EMAIL: dam at opencsw.org STATUS: completely installed FILES: 54 installed pathnames 9 shared pathnames 12 directories 1 executables 5543 blocks used (approx) $ /opt/csw/bin/gtar xfvz hello-0.1.0.tar.gz hello-0.1.0/hello.texinfo zsh: segmentation fault (core dumped) /opt/csw/bin/gtar xfvz hello-0.1.0.tar.gz From maciej at opencsw.org Mon Nov 15 12:20:46 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 15 Nov 2010 11:20:46 +0000 Subject: [csw-maintainers] CSWgtar - Segmentation Fault (core dumped) In-Reply-To: <77C422FF-1D71-4F8D-A223-D71EBD63261F@opencsw.org> References: <AANLkTi=0x6zyQ6ZK+LOwr+5d_go0L_uqsg=X1O6Ur3Us@mail.gmail.com> <AANLkTi=8_c6yqv0XrOTpAsUzqdCR_+t-hZgdx6JPV3F+@mail.gmail.com> <4CE0F880.4000302@opencsw.org> <AANLkTimtnhs1SdrPXskjn+uSpMnkNXdK37vA1+LXJOdj@mail.gmail.com> <20101115.9434400.792641895@gyor.oxdrove.co.uk> <77C422FF-1D71-4F8D-A223-D71EBD63261F@opencsw.org> Message-ID: <AANLkTikNH_Oz=DzKKJhXWM_RdZsAr7m8Y4Y8MB1c0hbN@mail.gmail.com> No dia 15 de Novembro de 2010 09:50, Dagobert Michelsen <dam at opencsw.org> escreveu: > Would you mind trying > ?http://buildfarm.opencsw.org/experimental/dam/gtar-1.25,REV=2010.11.15-SunOS5.9-i386-CSW.pkg.gz maciej at unknown ~/src $ gtar xfvz hello-0.1.0.tar.gz hello-0.1.0/hello.texinfo Segmentation Fault (core dumped) maciej at unknown ~/src $ gtar --version tar (GNU tar) 1.25 From dam at opencsw.org Mon Nov 15 16:26:01 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 15 Nov 2010 16:26:01 +0100 Subject: [csw-maintainers] New release of vim editor? In-Reply-To: <LBuL3n.LG8@cjsa.com> References: <LBuL3n.LG8@cjsa.com> Message-ID: <6116EC77-1F40-43E2-83F1-B83BB14C6DB1@opencsw.org> Hi Jeffery, Am 14.11.2010 um 00:54 schrieb Jeffery Small: > The last release of vim was April 9, 2009. There has been a newer 7.3 > version for quite some time. Is the current maintainer, Chad Harp, > still > working on the project? I sent him an email regarding this long ago > but > never received a reply. Please try 7.3p055 from http://buildfarm.opencsw.org/experimental.html#vim Feedback welcome! Best regards -- Dago From skayser at opencsw.org Mon Nov 15 16:25:02 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 15 Nov 2010 16:25:02 +0100 Subject: [csw-maintainers] CSWgtar - Segmentation Fault (core dumped) In-Reply-To: <AANLkTikNH_Oz=DzKKJhXWM_RdZsAr7m8Y4Y8MB1c0hbN@mail.gmail.com> References: <AANLkTi=0x6zyQ6ZK+LOwr+5d_go0L_uqsg=X1O6Ur3Us@mail.gmail.com> <AANLkTi=8_c6yqv0XrOTpAsUzqdCR_+t-hZgdx6JPV3F+@mail.gmail.com> <4CE0F880.4000302@opencsw.org> <AANLkTimtnhs1SdrPXskjn+uSpMnkNXdK37vA1+LXJOdj@mail.gmail.com> <20101115.9434400.792641895@gyor.oxdrove.co.uk> <77C422FF-1D71-4F8D-A223-D71EBD63261F@opencsw.org> <AANLkTikNH_Oz=DzKKJhXWM_RdZsAr7m8Y4Y8MB1c0hbN@mail.gmail.com> Message-ID: <20101115152502.GW28050@sebastiankayser.de> * Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: > No dia 15 de Novembro de 2010 09:50, Dagobert Michelsen > <dam at opencsw.org> escreveu: > > Would you mind trying > > ?http://buildfarm.opencsw.org/experimental/dam/gtar-1.25,REV=2010.11.15-SunOS5.9-i386-CSW.pkg.gz > > maciej at unknown ~/src $ gtar xfvz hello-0.1.0.tar.gz > hello-0.1.0/hello.texinfo > Segmentation Fault (core dumped) > maciej at unknown ~/src $ gtar --version > tar (GNU tar) 1.25 Before anyone else wanders off to do the same. I just sent an email regarding this issue to the GNU tar bug mailing list. Thanks for the stacktrace Maciej! Will add findings to the bug on our side [1]. Sebastian [1] http://www.opencsw.org/mantis/view.php?id=4601 From Joerg.Schilling at fokus.fraunhofer.de Mon Nov 15 16:42:19 2010 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Mon, 15 Nov 2010 16:42:19 +0100 Subject: [csw-maintainers] CSWgtar - Segmentation Fault (core dumped) In-Reply-To: <4CE0F880.4000302@opencsw.org> References: <AANLkTi=0x6zyQ6ZK+LOwr+5d_go0L_uqsg=X1O6Ur3Us@mail.gmail.com> <AANLkTi=8_c6yqv0XrOTpAsUzqdCR_+t-hZgdx6JPV3F+@mail.gmail.com> <4CE0F880.4000302@opencsw.org> Message-ID: <4ce154db.iS2gyyL9GJPLpJB2%Joerg.Schilling@fokus.fraunhofer.de> Sebastian Kayser <skayser at opencsw.org> wrote: > Maciej (Matchek) Blizinski wrote on 15.11.2010 09:43: > > No dia 15 de Novembro de 2010 08:30, Maciej (Matchek) Blizinski > > <maciej at opencsw.org> escreveu: > >> maciej at unknown ~/src/examplepkg $ gtar xfvz hello-0.1.0.tar.gz > >> hello-0.1.0/hello.texinfo > >> Segmentation Fault (core dumped) > > > > This is on x86. On sparc, the file was unpacked successfully. I only > > have one x86 host to test right now, and gtar segfaults there every > > time (therefore, probably not a bad memory problem). > > Just tried this with tarballs from mbuffer [1] and drbd [2]. Both > extracted fine. Where did you get your tarball from? GNU tar seems to have known bugs since at least two weeks. Even 1.25 has been reported to be buggy. 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 phil at bolthole.com Mon Nov 15 18:13:52 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 15 Nov 2010 09:13:52 -0800 Subject: [csw-maintainers] CSWgtar - Segmentation Fault (core dumped) In-Reply-To: <4ce154db.iS2gyyL9GJPLpJB2%Joerg.Schilling@fokus.fraunhofer.de> References: <AANLkTi=0x6zyQ6ZK+LOwr+5d_go0L_uqsg=X1O6Ur3Us@mail.gmail.com> <AANLkTi=8_c6yqv0XrOTpAsUzqdCR_+t-hZgdx6JPV3F+@mail.gmail.com> <4CE0F880.4000302@opencsw.org> <4ce154db.iS2gyyL9GJPLpJB2%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <AANLkTinncM-0BQ1+TufchDwC0e1tv6FQSWLtvQpxHLST@mail.gmail.com> On Mon, Nov 15, 2010 at 7:42 AM, Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de> wrote: > > GNU tar seems to have known bugs since at least two weeks. Even 1.25 has been > reported to be buggy. > drat. So, seems like the GNU tar folks have recently become incompetant, and we need to not trust new releases for a few months. I'll backrev to 1.23 I think. From bwalton at opencsw.org Mon Nov 15 18:22:29 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 15 Nov 2010 12:22:29 -0500 Subject: [csw-maintainers] CSWgtar - Segmentation Fault (core dumped) In-Reply-To: <AANLkTinncM-0BQ1+TufchDwC0e1tv6FQSWLtvQpxHLST@mail.gmail.com> References: <AANLkTi=0x6zyQ6ZK+LOwr+5d_go0L_uqsg=X1O6Ur3Us@mail.gmail.com> <AANLkTi=8_c6yqv0XrOTpAsUzqdCR_+t-hZgdx6JPV3F+@mail.gmail.com> <4CE0F880.4000302@opencsw.org> <4ce154db.iS2gyyL9GJPLpJB2%Joerg.Schilling@fokus.fraunhofer.de> <AANLkTinncM-0BQ1+TufchDwC0e1tv6FQSWLtvQpxHLST@mail.gmail.com> Message-ID: <1289841655-sup-5015@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Nov 15 12:13:52 -0500 2010: > So, seems like the GNU tar folks have recently become incompetant, > and we need to not trust new releases for a few months. I'll > backrev to 1.23 I think. This could be centred on the same bug that showed up in coreutils after U9 came out. There is an issue with setting time stamps in gnulib that was exposed by a change in U9. Given that gtar uses gnulib and will be setting timestamps as it extracts files, I wouldn't be surprised if it's the same issue. 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 Mon Nov 15 18:26:48 2010 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Mon, 15 Nov 2010 18:26:48 +0100 Subject: [csw-maintainers] CSWgtar - Segmentation Fault (core dumped) In-Reply-To: <1289841655-sup-5015@pinkfloyd.chass.utoronto.ca> References: <AANLkTi=0x6zyQ6ZK+LOwr+5d_go0L_uqsg=X1O6Ur3Us@mail.gmail.com> <AANLkTi=8_c6yqv0XrOTpAsUzqdCR_+t-hZgdx6JPV3F+@mail.gmail.com> <4CE0F880.4000302@opencsw.org> <4ce154db.iS2gyyL9GJPLpJB2%Joerg.Schilling@fokus.fraunhofer.de> <AANLkTinncM-0BQ1+TufchDwC0e1tv6FQSWLtvQpxHLST@mail.gmail.com> <1289841655-sup-5015@pinkfloyd.chass.utoronto.ca> Message-ID: <4ce16d58.2CHiIR5O0A7aVnZr%Joerg.Schilling@fokus.fraunhofer.de> Ben Walton <bwalton at opencsw.org> wrote: > Excerpts from Philip Brown's message of Mon Nov 15 12:13:52 -0500 2010: > > > So, seems like the GNU tar folks have recently become incompetant, > > and we need to not trust new releases for a few months. I'll > > backrev to 1.23 I think. > > This could be centred on the same bug that showed up in coreutils > after U9 came out. There is an issue with setting time stamps in > gnulib that was exposed by a change in U9. Given that gtar uses > gnulib and will be setting timestamps as it extracts files, I wouldn't > be surprised if it's the same issue. The GNUtar people seem to be working on a change from open() and similar towards openat() and similar. For many OS, there is a need for a emulation and it seems that the wrapper code does not always work currectly. It would be of interest whether the problems occur on Solaris 9 or newer or on Solaris 8. I am planning a similar move for stare in the near future and I hope that I will be able to do this with less visible effects. 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 phil at bolthole.com Mon Nov 15 18:32:28 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 15 Nov 2010 09:32:28 -0800 Subject: [csw-maintainers] http://www.opencsw.org/packages/<pkg>: Add GAR build recipe URL to package page? In-Reply-To: <1289672497-sup-4152@pinkfloyd.chass.utoronto.ca> References: <AANLkTinDZMHfx3gf=unSnYWPhpPGzcM4ppmg3pfeYntu@mail.gmail.com> <AANLkTi=oCjs+VqVvr8iAkApYAcXpDurhSmE+heEv79e=@mail.gmail.com> <AANLkTim1d82p_u9+YpT877jQRpb0dz4HqzFTVs+zHi1M@mail.gmail.com> <AANLkTi=CfQpjWCn4R72QzX=6nKZkf3OKDrc_tjBAvYFe@mail.gmail.com> <AANLkTikFLm7HBncpo4tqCB0aD+0NKC8f07wZ3jopA7ys@mail.gmail.com> <20101105162742.GA15588@sebastiankayser.de> <AANLkTi=qiP57EoqARAaCK=nPgxw+U2B=-fWvx3KKs7V=@mail.gmail.com> <4CDB292D.3090108@opencsw.org> <AANLkTikYhpD4mZ0-Xx9jMRYZzzOBaY65S0jqHY0OwoYi@mail.gmail.com> <EDB0F459-82F6-42E8-9E39-44141E84EE57@opencsw.org> <20101111171050.GP28050@sebastiankayser.de> <AANLkTimW2xVb=nwQuqKi7G1Qgb21GRttoZ7JOJGPboGT@mail.gmail.com> <1289672497-sup-4152@pinkfloyd.chass.utoronto.ca> Message-ID: <AANLkTik0iWrkpeu+N3_V8jeHZfActj9K3Pha2PqxbP7T@mail.gmail.com> On Sat, Nov 13, 2010 at 10:35 AM, Ben Walton <bwalton at opencsw.org> wrote: > > > ...Anyway, with either CHAR or VARCHAR, we still need to choose a > maximum length. ?With CHAR the MySQL limit is 255. ?Without going > outside of portable POSIX ranges for file paths, that should be enough > even in the extreme cases. > > If we wanted to allow the svn path to grow to what Solaris would > allow, then a VARCHAR(1023) is required. ?I don't think our svn > reference paths will approach this (or at least they shouldn't). Preamble: unfortunately, the current subject line doesnt quite fit what I'm talking about: I'm talking more about just adding in the OPENCSW_REPOSITORY bit. Shall we change the subject line? within the context for that only -- For that, the actual database space could be somewhat fixed. After all, we are now agreed that package names should be 31 chars or less. And that the location for a package in our repository is usually [top]/softwarename Or in some rare cases (which I'd personally like to do away with) [top]/(maybe-ONE subdir)/softwarename So we could actually pick some reasonable fixed size for it. The exact length, would depend on the answer to your followup question: > I also think that the common portion of the SourceForge.net URL should > be stripped out of the storage here and appended by php as a > statically defined string in the code. Are you suggesting that the existing string in pkginfo be left as is, but when inserted into the database, we auto-strip out {top of repository} ? sounds potentially reasonable. If so, then the database size for storing the OPENCSW_REPOSITORY info could be limited to 31 + fileseparator + 31 = 63. Make it 64 just to be 'rounded' hmmm? From phil at bolthole.com Mon Nov 15 18:36:02 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 15 Nov 2010 09:36:02 -0800 Subject: [csw-maintainers] CSWgtar - Segmentation Fault (core dumped) In-Reply-To: <4ce16d58.2CHiIR5O0A7aVnZr%Joerg.Schilling@fokus.fraunhofer.de> References: <AANLkTi=0x6zyQ6ZK+LOwr+5d_go0L_uqsg=X1O6Ur3Us@mail.gmail.com> <AANLkTi=8_c6yqv0XrOTpAsUzqdCR_+t-hZgdx6JPV3F+@mail.gmail.com> <4CE0F880.4000302@opencsw.org> <4ce154db.iS2gyyL9GJPLpJB2%Joerg.Schilling@fokus.fraunhofer.de> <AANLkTinncM-0BQ1+TufchDwC0e1tv6FQSWLtvQpxHLST@mail.gmail.com> <1289841655-sup-5015@pinkfloyd.chass.utoronto.ca> <4ce16d58.2CHiIR5O0A7aVnZr%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <AANLkTik=n_ag=bgQSFMCag4ZAnZ0VbYoSvK5yW7K4ykM@mail.gmail.com> Well, I have test packages of 1.23 rerolled, in my 'experimental' dir. erm.. http://buildfarm.opencsw.org/experimental/phil ? From dam at opencsw.org Mon Nov 15 19:20:58 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 15 Nov 2010 19:20:58 +0100 Subject: [csw-maintainers] http://www.opencsw.org/packages/<pkg>: Add GAR build recipe URL to package page? In-Reply-To: <AANLkTik0iWrkpeu+N3_V8jeHZfActj9K3Pha2PqxbP7T@mail.gmail.com> References: <AANLkTinDZMHfx3gf=unSnYWPhpPGzcM4ppmg3pfeYntu@mail.gmail.com> <AANLkTi=oCjs+VqVvr8iAkApYAcXpDurhSmE+heEv79e=@mail.gmail.com> <AANLkTim1d82p_u9+YpT877jQRpb0dz4HqzFTVs+zHi1M@mail.gmail.com> <AANLkTi=CfQpjWCn4R72QzX=6nKZkf3OKDrc_tjBAvYFe@mail.gmail.com> <AANLkTikFLm7HBncpo4tqCB0aD+0NKC8f07wZ3jopA7ys@mail.gmail.com> <20101105162742.GA15588@sebastiankayser.de> <AANLkTi=qiP57EoqARAaCK=nPgxw+U2B=-fWvx3KKs7V=@mail.gmail.com> <4CDB292D.3090108@opencsw.org> <AANLkTikYhpD4mZ0-Xx9jMRYZzzOBaY65S0jqHY0OwoYi@mail.gmail.com> <EDB0F459-82F6-42E8-9E39-44141E84EE57@opencsw.org> <20101111171050.GP28050@sebastiankayser.de> <AANLkTimW2xVb=nwQuqKi7G1Qgb21GRttoZ7JOJGPboGT@mail.gmail.com> <1289672497-sup-4152@pinkfloyd.chass.utoronto.ca> <AANLkTik0iWrkpeu+N3_V8jeHZfActj9K3Pha2PqxbP7T@mail.gmail.com> Message-ID: <1F550B4F-E5CA-405C-A6ED-52AB09EA3023@opencsw.org> Hi Phil, Am 15.11.2010 um 18:32 schrieb Philip Brown: > within the context for that only -- > For that, the actual database space could be somewhat fixed. > After all, we are now agreed that package names should be 31 chars or less. Does that mean all my waiting packages get released now including the Perl modules with longer names than previously allowed but <31? > And that the location for a package in our repository is usually > [top]/softwarename > Or in some rare cases (which I'd personally like to do away with) > [top]/(maybe-ONE subdir)/softwarename > > So we could actually pick some reasonable fixed size for it. The exact > length, would depend on the answer to your followup question: > >> I also think that the common portion of the SourceForge.net URL should >> be stripped out of the storage here and appended by php as a >> statically defined string in the code. > > Are you suggesting that the existing string in pkginfo be left as is, > but when inserted into the database, we auto-strip out {top of > repository} ? > > sounds potentially reasonable. > > If so, then the database size for storing the OPENCSW_REPOSITORY info > could be limited to > 31 + fileseparator + 31 = 63. Make it 64 just to be 'rounded' > > hmmm? Nope. The server name prefix to the repository should be stripped up to the repository root, which is Repository Root: https://gar.svn.sf.net/svnroot/gar The path length is not directly connected to the catalog-, nor the package name, but the upstream name which may or may not be similar in length. Short answer: Just user 255 and we never will have this discussion again :-) If you have doubts about the database size: an extra GB of RAM shouldn't matter which will suffice for about 1.000.000.000 / (255 - 63) ~ 5 million extra package. Some room available :-) Best regards -- Dago From dam at opencsw.org Mon Nov 15 19:23:10 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 15 Nov 2010 19:23:10 +0100 Subject: [csw-maintainers] [csw-users] important change: length of software names In-Reply-To: <AANLkTi=+HqXBP_4Jxe8u-ze_-J7XFzU-34qPt1+LMFfD@mail.gmail.com> References: <AANLkTi=+HqXBP_4Jxe8u-ze_-J7XFzU-34qPt1+LMFfD@mail.gmail.com> Message-ID: <9EAC9604-37ED-471E-A602-97380AAADD6C@opencsw.org> Hi, Am 01.11.2010 um 16:48 schrieb Philip Brown: > Greetings, OpenCSW users, > > We are considering making a change to a long-time standard for CSW > packages. It has been proposed that we raise the maximum length limit > on our software names, to be the full length supported by Solaris 9 > and 10. > > This means that PKG names would be allowed to be 32 chars long. which > means catalog names, aka "software names", could be up to 29 chars > long > (To match the PKG name, minus the leading "CSW") > > While we believe our internal software, and also utilities such as > pkg-get and pkgutil, can be easily modified, we wanted to give the > user community notice in advance, so that there is opportunity for > feedback, if this somehow adversely affects anyone. > > If this is the case for you, please let us know. The simplest method > is probably to email this list. However, if you wish, you may > alternatively email me, or the OpenCSW board list. (board @ ....) > > Thank you for your interest, and involvement, in OpenCSW Ok, two weeks from the inital post, only positive feedback from maintainers, none from users. Is this settled to 32 characters, than? Best regards -- Dago From phil at bolthole.com Mon Nov 15 19:53:56 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 15 Nov 2010 10:53:56 -0800 Subject: [csw-maintainers] important change: length of software names In-Reply-To: <9EAC9604-37ED-471E-A602-97380AAADD6C@opencsw.org> References: <AANLkTi=+HqXBP_4Jxe8u-ze_-J7XFzU-34qPt1+LMFfD@mail.gmail.com> <9EAC9604-37ED-471E-A602-97380AAADD6C@opencsw.org> Message-ID: <AANLkTikkAu_29zcVatVdSXvpY7X=9SfFAxmcvF9QJKQb@mail.gmail.com> On Monday, November 15, 2010, Dagobert Michelsen <dam at opencsw.org> wrote: > Hi, > > Am 01.11.2010 um 16:48 schrieb Philip Brown: >>... >> This means that PKG names would be allowed to be 32 chars long. which >> means catalog names, aka "software names", could be up to 29 chars >> long >> (To match the PKG name, minus the leading "CSW") >> >> > > Ok, two weeks from the inital post, only positive feedback from maintainers, > none from users. Is this settled to 32 characters, than? > (29) yes. I'll be working on adjusting my validation and database scripts shortly From phil at bolthole.com Mon Nov 15 20:24:20 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 15 Nov 2010 11:24:20 -0800 Subject: [csw-maintainers] maven3 - java package for all architectures In-Reply-To: <AANLkTimJc3Jq5V21SO2vvRsCfPdfr9k-hzcAYsZdY+U4@mail.gmail.com> References: <AANLkTimJc3Jq5V21SO2vvRsCfPdfr9k-hzcAYsZdY+U4@mail.gmail.com> Message-ID: <AANLkTinUYok7_FqWzHANqtzMfbpjf3MkAXJmLB1Zmw_e@mail.gmail.com> On Sat, Nov 13, 2010 at 4:23 AM, rupert THURNER <rupert at opencsw.org> wrote: > hi, i tried to copy maven2 to build maven3, and checked it also in for > reference. the package is java and does not build as such. what do you mean by this? Does the maven3 project distribute precompiled but standalone .class files? or does it give you .java files and expects you t compile to .class/jar files? or does it just provide a jar? The answer to this decides which package you need to compare to. From dam at opencsw.org Mon Nov 15 22:24:58 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 15 Nov 2010 22:24:58 +0100 Subject: [csw-maintainers] maven3 - java package for all architectures In-Reply-To: <AANLkTinUYok7_FqWzHANqtzMfbpjf3MkAXJmLB1Zmw_e@mail.gmail.com> References: <AANLkTimJc3Jq5V21SO2vvRsCfPdfr9k-hzcAYsZdY+U4@mail.gmail.com> <AANLkTinUYok7_FqWzHANqtzMfbpjf3MkAXJmLB1Zmw_e@mail.gmail.com> Message-ID: <E8178D96-07D7-465B-B767-8585049A1E0F@opencsw.org> Hi, Am 15.11.2010 um 20:24 schrieb Philip Brown: > On Sat, Nov 13, 2010 at 4:23 AM, rupert THURNER <rupert at opencsw.org> wrote: >> hi, i tried to copy maven2 to build maven3, and checked it also in for >> reference. the package is java and does not build as such. > > what do you mean by this? > > Does the maven3 project distribute precompiled but standalone .class files? > or does it give you .java files and expects you t compile to .class/jar files? > or does it just provide a jar? > > The answer to this decides which package you need to compare to. I just looked, it is a GAR issue: Hardcoding GARCH on the top breaks the modulation. The build is independent from Java, good examples are e.g. phpldapadmin and jdk6 which just put files in place. Rupert: I updated the GAR Makefile that it install but as I don't know Maven at all I'll leave the difficult things like symlinking 'mvn' and moving the config-file to /etc/opt/csw to you :-) Best regards -- Dago From phil at bolthole.com Tue Nov 16 00:35:28 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 15 Nov 2010 15:35:28 -0800 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs cups In-Reply-To: <AANLkTimceaYGvavJGp7gwrkXMhrdCreuhU7OgDmE=ZK_@mail.gmail.com> References: <201011081957.oA8JvUVW025660@login.bo.opencsw.org> <AANLkTikVgBzacEx2U22XRQAn==admXRUdF7GeW1MEN-h@mail.gmail.com> <AANLkTimTBCV0cVt1z5e70BjSc68s+x7ueposFHLd0hcc@mail.gmail.com> <AANLkTinJt_a5Uainip1ekZjCTViCwZvg8B5bmVQwQPqW@mail.gmail.com> <AANLkTi=3_5FSnaYQEiqmWRJxu9toUQnSYeZDtsUc=HpN@mail.gmail.com> <AANLkTi=2z1LmA-rcRnZUgnS_QbyVp6dNu8vfxGmpC0hc@mail.gmail.com> <AANLkTimceaYGvavJGp7gwrkXMhrdCreuhU7OgDmE=ZK_@mail.gmail.com> Message-ID: <AANLkTikp5Y52G=cPPzOvaigEXZTV9tFgN_LHMb=aLjx=@mail.gmail.com> On 11/11/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: > >> if people are going to be able to follow either a proposal or policy, >> it needs to be written up as an explicit document unto itself. > > Fair enough. I wrote it up, here's the link: > > http://wiki.opencsw.org/packaging-shared-libraries > Thank you for doing so. I now finally have the time to properly review, and write up a reply. I'll make a comment here, so that it doesnt gum up the other thread: I think your italicized pre-amble was .. well, i was going to call it something else, but I'll instead call it "counter-productive". If you were saying "Please dont pick needlessly at grammar", that's sensible. But it seems like you are almost saying "dont point out any flaws in the proposal at all". From phil at bolthole.com Tue Nov 16 01:20:48 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 15 Nov 2010 16:20:48 -0800 Subject: [csw-maintainers] commentary on shared library naming proposal Message-ID: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> This is starting off a fresh thread, on the proposal being suggested around naming of packages, that have shared libraries in them. Maciej was kind enough to write up a web page for it, here: http://wiki.opencsw.org/packaging-shared-libraries I have made some very minor updates to it, and corrected the naming length "32" to "29" . I then added some areas of concern that I have, to the bottom of the page. I was originally going to quote them here, but they have become rather long :-/ So perhaps they are better read in the full context of the wiki page, above. I will also mention, given that Maciej gave the debian sharedlibs policy (section 8.1) as a reference, if we abided by the WHOLE text of that section. Again, my further notes on that, are at the bottom of the wiki page. General comment I did not add into the wiki: I do not see having "more packages" as a good in and of itself (and neither does Debian, as I reference in the page). If upgrading "libcups" -- what was previously a single package -- now takes downloading and cycling through (pkgrm, pkgadd) **6** times... I dont think this looks good to our users. From bwalton at opencsw.org Tue Nov 16 04:01:22 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 15 Nov 2010 22:01:22 -0500 Subject: [csw-maintainers] apache 1.3 retirement? Message-ID: <1289876125-sup-6296@pinkfloyd.chass.utoronto.ca> Hi All, Is anyone going to maintain apache 1.3 any longer? It's had bugs open for (literally) years and is vulnerable to several security issues. Can we put this one to rest? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Nov 16 05:57:30 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 15 Nov 2010 20:57:30 -0800 Subject: [csw-maintainers] apache 1.3 retirement? In-Reply-To: <1289876125-sup-6296@pinkfloyd.chass.utoronto.ca> References: <1289876125-sup-6296@pinkfloyd.chass.utoronto.ca> Message-ID: <AANLkTi=Mz-J=sQWgtfhW6tL_X+y31ynHrpSYRfKTt9Uz@mail.gmail.com> it has multiple pkgs depending on it On Monday, November 15, 2010, Ben Walton <bwalton at opencsw.org> wrote: > > Hi All, > > Is anyone going to maintain apache 1.3 any longer? ?It's had bugs open > for (literally) years and is vulnerable to several security issues. > Can we put this one to rest? > > Thanks > -Ben > -- > 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. ::. > From maciej at opencsw.org Tue Nov 16 11:54:57 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 16 Nov 2010 10:54:57 +0000 Subject: [csw-maintainers] apache 1.3 retirement? In-Reply-To: <AANLkTi=Mz-J=sQWgtfhW6tL_X+y31ynHrpSYRfKTt9Uz@mail.gmail.com> References: <1289876125-sup-6296@pinkfloyd.chass.utoronto.ca> <AANLkTi=Mz-J=sQWgtfhW6tL_X+y31ynHrpSYRfKTt9Uz@mail.gmail.com> Message-ID: <AANLkTi=_=ptUqU=RZq3UtsfG0-eZZQzWH2TR+xDfTUPw@mail.gmail.com> No dia 16 de Novembro de 2010 04:57, Philip Brown <phil at bolthole.com> escreveu: > it has multiple pkgs depending on it We could remove these as well. From bwalton at opencsw.org Tue Nov 16 15:11:46 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 16 Nov 2010 09:11:46 -0500 Subject: [csw-maintainers] apache 1.3 retirement? In-Reply-To: <AANLkTi=_=ptUqU=RZq3UtsfG0-eZZQzWH2TR+xDfTUPw@mail.gmail.com> References: <1289876125-sup-6296@pinkfloyd.chass.utoronto.ca> <AANLkTi=Mz-J=sQWgtfhW6tL_X+y31ynHrpSYRfKTt9Uz@mail.gmail.com> <AANLkTi=_=ptUqU=RZq3UtsfG0-eZZQzWH2TR+xDfTUPw@mail.gmail.com> Message-ID: <1289916578-sup-7589@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Tue Nov 16 05:54:57 -0500 2010: > No dia 16 de Novembro de 2010 04:57, Philip Brown <phil at bolthole.com> escreveu: > > it has multiple pkgs depending on it > > We could remove these as well. Yes, other than RT, sqwebmail and possibly htdig[1] everything else is a module for apache that would be retired along side of it. The sqwebmail could be updated (or simply unrolled, modified and re-rolled) to have the deps updated to apache....it may or may not require other tweaks. Thanks -Ben [1] Are people still using this? The site has a 2004 copyright on it... -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From skayser at opencsw.org Tue Nov 16 15:19:11 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 16 Nov 2010 15:19:11 +0100 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> Message-ID: <20101116141911.GZ28050@sebastiankayser.de> * Philip Brown <phil at bolthole.com> wrote: > I will also mention, given that Maciej gave the debian sharedlibs > policy (section 8.1) as a reference, if we abided by the WHOLE text of > that section. Again, my further notes on that, are at the bottom of > the wiki page. When it comes to policy vs "when seen beneficial" in this case, I regard it as helpful to have as few exceptions and as much of a standard as possible. If the naming scheme is considered CAN and the release manager is to decide on a case by case basis whether the naming seems "beneficial" this somehow defeats the purpose of the (standardizing) naming policy in the first place and is prone to cause confusion (well, we have this guideline in place, but ...). No need to make it extra complicated. Maciej's checkpkg which is integrated into GAR even suggests the GAR directives for the lib package splitoff so the maintainer doesn't have to come up with them. > General comment I did not add into the wiki: I do not see having "more > packages" as a good in and of itself (and neither does Debian, as I > reference in the page). > If upgrading "libcups" -- what was previously a single package -- now > takes downloading and cycling through (pkgrm, pkgadd) **6** times... I > dont think this looks good to our users. To be honest, I have been using Debian for several years and only now (that we are talking about the library naming scheme) realized how the names of their libraries are constructed. To me - as a user - this has been and still is totally secondary as long as the application or service I want to use is working fine. The only time I wanted to explicitly pull in something library related is when I needed it for compilation purposes (the -dev package variants and these don't depend on SONAMES). Sebastian From phil at bolthole.com Tue Nov 16 17:21:31 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 16 Nov 2010 08:21:31 -0800 Subject: [csw-maintainers] apache 1.3 retirement? In-Reply-To: <1289916578-sup-7589@pinkfloyd.chass.utoronto.ca> References: <1289876125-sup-6296@pinkfloyd.chass.utoronto.ca> <AANLkTi=Mz-J=sQWgtfhW6tL_X+y31ynHrpSYRfKTt9Uz@mail.gmail.com> <AANLkTi=_=ptUqU=RZq3UtsfG0-eZZQzWH2TR+xDfTUPw@mail.gmail.com> <1289916578-sup-7589@pinkfloyd.chass.utoronto.ca> Message-ID: <AANLkTiks2UDc1U0WYVe3o0Gxf8MyFUyzD2Ydio+E8N6=@mail.gmail.com> On 11/16/10, Ben Walton <bwalton at opencsw.org> wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Tue Nov 16 05:54:57 > -0500 2010: >> No dia 16 de Novembro de 2010 04:57, Philip Brown <phil at bolthole.com> >> escreveu: >> > it has multiple pkgs depending on it >... > > Yes, other than RT, sqwebmail and possibly htdig[1] everything else is > a module for apache that would be retired along side of it. yes i did notice that the majority of dependants are just apache modules. But, even if there was only ONE useful package depending on it, it would be reason to still keep it in. and there are at least two. For the record, I kept "meaning to update apache1, but wanted to do it "nicely". but nicely takes more time than a quickie, so it never happened :-/ Probably its about time I do a quickie instead. would be nice if someone did it "properly" though. There are some useful apache modules that *only* work with apache1, I think, But last time i verified that was a year or two ago. From maciej at opencsw.org Tue Nov 16 17:28:51 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 16 Nov 2010 16:28:51 +0000 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <20101116141911.GZ28050@sebastiankayser.de> References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> <20101116141911.GZ28050@sebastiankayser.de> Message-ID: <AANLkTikJcqhmxdKMd5CoiMsUxE+dmGTfT6nsgpqqVHq4@mail.gmail.com> No dia 16 de Novembro de 2010 14:19, Sebastian Kayser <skayser at opencsw.org> escreveu: > * Philip Brown <phil at bolthole.com> wrote: >> I will also mention, given that Maciej gave the debian sharedlibs >> policy (section 8.1) as a reference, if we abided by the WHOLE text of >> that section. Again, my further notes on that, are at the bottom of >> the wiki page. > > When it comes to policy vs "when seen beneficial" in this case, I regard > it as helpful to have as few exceptions and as much of a standard as > possible. There's also the question of who is the subject to see the benefit. Is it the maintainer or the release manager? What if the two disagree? Is it reasonable for the release manager to reject a split-off package even though the maintainer sees it as beneficial and the package follows the naming scheme? From bwalton at opencsw.org Tue Nov 16 17:31:41 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 16 Nov 2010 11:31:41 -0500 Subject: [csw-maintainers] apache 1.3 retirement? In-Reply-To: <AANLkTiks2UDc1U0WYVe3o0Gxf8MyFUyzD2Ydio+E8N6=@mail.gmail.com> References: <1289876125-sup-6296@pinkfloyd.chass.utoronto.ca> <AANLkTi=Mz-J=sQWgtfhW6tL_X+y31ynHrpSYRfKTt9Uz@mail.gmail.com> <AANLkTi=_=ptUqU=RZq3UtsfG0-eZZQzWH2TR+xDfTUPw@mail.gmail.com> <1289916578-sup-7589@pinkfloyd.chass.utoronto.ca> <AANLkTiks2UDc1U0WYVe3o0Gxf8MyFUyzD2Ydio+E8N6=@mail.gmail.com> Message-ID: <1289924999-sup-7646@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Nov 16 11:21:31 -0500 2010: > Probably its about time I do a quickie instead. would be nice if > someone did it "properly" though. There are some useful apache > modules that *only* work with apache1, I think, But last time i > verified that was a year or two ago. ...or spend the time updating the packages that depend on it. Removing it from our catalogs doesn't remove it from the mirrors that don't use --delete with rsync and it doesn't remove it from servers where it's installed. Just a thought. I sure wouldn't invest my time in 1.3 these days. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Nov 16 18:00:41 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 16 Nov 2010 09:00:41 -0800 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <AANLkTikJcqhmxdKMd5CoiMsUxE+dmGTfT6nsgpqqVHq4@mail.gmail.com> References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> <20101116141911.GZ28050@sebastiankayser.de> <AANLkTikJcqhmxdKMd5CoiMsUxE+dmGTfT6nsgpqqVHq4@mail.gmail.com> Message-ID: <AANLkTinxgZzYhByjzya7oKOZ8BWm3Kjowq=c1eTmhnH+@mail.gmail.com> On 11/16/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: > No dia 16 de Novembro de 2010 14:19, Sebastian Kayser > <skayser at opencsw.org> escreveu: >> * Philip Brown <phil at bolthole.com> wrote: >>> I will also mention, given that Maciej gave the debian sharedlibs >>> policy (section 8.1) as a reference, if we abided by the WHOLE text of >>> that section. Again, my further notes on that, are at the bottom of >>> the wiki page. >> >> When it comes to policy vs "when seen beneficial" in this case, I regard >> it as helpful to have as few exceptions and as much of a standard as >> possible. > > There's also the question of who is the subject to see the benefit. "The benefit " is supposed to be for the user, not the maintainer OR the release manager. :) As far as who determines it before the package is released: by definition, the person with the most authority to make that decision, is the release manager. > Is it the maintainer or the release manager? What if the two > disagree? Ideally, "the maintainer" should respect the release manager's experience in the matter. But there's always recourse to the board. From pfelecan at opencsw.org Tue Nov 16 18:02:19 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 16 Nov 2010 18:02:19 +0100 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <AANLkTikJcqhmxdKMd5CoiMsUxE+dmGTfT6nsgpqqVHq4@mail.gmail.com> (Maciej Blizinski's message of "Tue, 16 Nov 2010 16:28:51 +0000") References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> <20101116141911.GZ28050@sebastiankayser.de> <AANLkTikJcqhmxdKMd5CoiMsUxE+dmGTfT6nsgpqqVHq4@mail.gmail.com> Message-ID: <x6hbfhjj6s.fsf@opencsw.org> "Maciej (Matchek) Blizinski" <maciej at opencsw.org> writes: > No dia 16 de Novembro de 2010 14:19, Sebastian Kayser > <skayser at opencsw.org> escreveu: >> * Philip Brown <phil at bolthole.com> wrote: >>> I will also mention, given that Maciej gave the debian sharedlibs >>> policy (section 8.1) as a reference, if we abided by the WHOLE text of >>> that section. Again, my further notes on that, are at the bottom of >>> the wiki page. >> >> When it comes to policy vs "when seen beneficial" in this case, I regard >> it as helpful to have as few exceptions and as much of a standard as >> possible. > > There's also the question of who is the subject to see the benefit. > Is it the maintainer or the release manager? What if the two > disagree? Is it reasonable for the release manager to reject a > split-off package even though the maintainer sees it as beneficial and > the package follows the naming scheme? This reminds me that we strongly agreed, at the summer summit (sorry to raise again a subject discussed at that time), that we don't need a "release manager" per see; the transition from experimental to testing to unstable to stable can be done almost automatically, based on standards, tools that enforce those standards and *maintainers* community agreement. -- Peter From bwalton at opencsw.org Tue Nov 16 18:06:55 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 16 Nov 2010 12:06:55 -0500 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <AANLkTinxgZzYhByjzya7oKOZ8BWm3Kjowq=c1eTmhnH+@mail.gmail.com> References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> <20101116141911.GZ28050@sebastiankayser.de> <AANLkTikJcqhmxdKMd5CoiMsUxE+dmGTfT6nsgpqqVHq4@mail.gmail.com> <AANLkTinxgZzYhByjzya7oKOZ8BWm3Kjowq=c1eTmhnH+@mail.gmail.com> Message-ID: <1289927015-sup-9843@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Nov 16 12:00:41 -0500 2010: > "The benefit " is supposed to be for the user, not the maintainer OR > the release manager. :) Sebastian made a valid point in this regard. Other than a few extra http fetches, they typically won't notice (in any meaningful sense) whether they grab a few extra packages or not. What they _will_ notices is nicer transitions of packages as _maintainers_ have a lot more freedom to upgrade packages gradually instead of as a big lump. This should result in a better user experience overall. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Tue Nov 16 18:10:36 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 16 Nov 2010 18:10:36 +0100 Subject: [csw-maintainers] apache 1.3 retirement? In-Reply-To: <1289924999-sup-7646@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Tue, 16 Nov 2010 11:31:41 -0500") References: <1289876125-sup-6296@pinkfloyd.chass.utoronto.ca> <AANLkTi=Mz-J=sQWgtfhW6tL_X+y31ynHrpSYRfKTt9Uz@mail.gmail.com> <AANLkTi=_=ptUqU=RZq3UtsfG0-eZZQzWH2TR+xDfTUPw@mail.gmail.com> <1289916578-sup-7589@pinkfloyd.chass.utoronto.ca> <AANLkTiks2UDc1U0WYVe3o0Gxf8MyFUyzD2Ydio+E8N6=@mail.gmail.com> <1289924999-sup-7646@pinkfloyd.chass.utoronto.ca> Message-ID: <x6d3q5jisz.fsf@opencsw.org> Ben Walton <bwalton at opencsw.org> writes: > Excerpts from Philip Brown's message of Tue Nov 16 11:21:31 -0500 2010: > >> Probably its about time I do a quickie instead. would be nice if >> someone did it "properly" though. There are some useful apache >> modules that *only* work with apache1, I think, But last time i >> verified that was a year or two ago. > > ...or spend the time updating the packages that depend on it. > Removing it from our catalogs doesn't remove it from the mirrors that > don't use --delete with rsync and it doesn't remove it from servers > where it's installed. > > Just a thought. I sure wouldn't invest my time in 1.3 these days. Well, keeping old clunkers as Apache 1.x doesn't work toward keeping the number of the packages under control as was suggested in the libraries naming thread. However, it's very coherent with the state of mind that opposed dropping Solaris 8, and will oppose the dropping of Solaris 9 for who knows how many years. Seriously, who distributes today Apache 1.x; who uses it? A reality check is good from time to time. -- Peter From phil at bolthole.com Tue Nov 16 18:24:56 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 16 Nov 2010 09:24:56 -0800 Subject: [csw-maintainers] apache 1.3 retirement? In-Reply-To: <x6d3q5jisz.fsf@opencsw.org> References: <1289876125-sup-6296@pinkfloyd.chass.utoronto.ca> <AANLkTi=Mz-J=sQWgtfhW6tL_X+y31ynHrpSYRfKTt9Uz@mail.gmail.com> <AANLkTi=_=ptUqU=RZq3UtsfG0-eZZQzWH2TR+xDfTUPw@mail.gmail.com> <1289916578-sup-7589@pinkfloyd.chass.utoronto.ca> <AANLkTiks2UDc1U0WYVe3o0Gxf8MyFUyzD2Ydio+E8N6=@mail.gmail.com> <1289924999-sup-7646@pinkfloyd.chass.utoronto.ca> <x6d3q5jisz.fsf@opencsw.org> Message-ID: <AANLkTiksToNrnXr1QM5Ln-AfQzUR3WenyqZghgHp-7Yo@mail.gmail.com> On 11/16/10, Peter FELECAN <pfelecan at opencsw.org> wrote: > > Seriously, who distributes today Apache 1.x; who uses it? A reality > check is good from time to time. reality check: this isnt really about apache1, its about the packages that USE apache 1. When those packages dont use it any more, I would be very happy to remove apache1 from our catalog. Perhaps you would like to DO something to help clean up the current state of things? From pfelecan at opencsw.org Tue Nov 16 18:31:50 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 16 Nov 2010 18:31:50 +0100 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <AANLkTinxgZzYhByjzya7oKOZ8BWm3Kjowq=c1eTmhnH+@mail.gmail.com> (Philip Brown's message of "Tue, 16 Nov 2010 09:00:41 -0800") References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> <20101116141911.GZ28050@sebastiankayser.de> <AANLkTikJcqhmxdKMd5CoiMsUxE+dmGTfT6nsgpqqVHq4@mail.gmail.com> <AANLkTinxgZzYhByjzya7oKOZ8BWm3Kjowq=c1eTmhnH+@mail.gmail.com> Message-ID: <x64obhjhtl.fsf@opencsw.org> Philip Brown <phil at bolthole.com> writes: > On 11/16/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: >> No dia 16 de Novembro de 2010 14:19, Sebastian Kayser >> <skayser at opencsw.org> escreveu: >>> * Philip Brown <phil at bolthole.com> wrote: >>>> I will also mention, given that Maciej gave the debian sharedlibs >>>> policy (section 8.1) as a reference, if we abided by the WHOLE text of >>>> that section. Again, my further notes on that, are at the bottom of >>>> the wiki page. >>> >>> When it comes to policy vs "when seen beneficial" in this case, I regard >>> it as helpful to have as few exceptions and as much of a standard as >>> possible. >> >> There's also the question of who is the subject to see the benefit. > > "The benefit " is supposed to be for the user, not the maintainer OR > the release manager. :) > As far as who determines it before the package is released: > by definition, the person with the most authority to make that > decision, is the release manager. I completely disagree with this: the maintainers provides the work, respects the domain standards and agreed by the *maintainers* community. The users benefit form this as upgrades have a better granularity. The "release manager" is a facilitator for maintainers. What he is doing in our case is discretionary under the cover of user community advocacy. >> Is it the maintainer or the release manager? What if the two >> disagree? > > Ideally, "the maintainer" should respect the release manager's > experience in the matter. > But there's always recourse to the board. Theoretically. In practice I beg to disagree again... This bring up another issue: our foundation needs a long due election for renewing the board, but this is probably better brought up in another thread, that I agree. -- Peter From bwalton at opencsw.org Tue Nov 16 18:37:34 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 16 Nov 2010 12:37:34 -0500 Subject: [csw-maintainers] apache2 call for testing again Message-ID: <1289928905-sup-8519@pinkfloyd.chass.utoronto.ca> Hi All, I've placed updated apache2 packages in an experimental repo here: http://buildfarm.opencsw.org/experimental.html#apache2 These are using the build CAS instead of the custom cswap2mod to handle module add/remove. Additionally, they leverage the build CAS for the default SSL (dummy) cert generation, and default config file creation. I'm working on a branch toward moving etc/ and var/ to the proper locations, but that's a bigger project that will take a bit more time. In the meantime, if people wouldn't mind testing what I've done now, that would be great. I can release them in a week or so if there is no negative feedback on these. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Nov 16 18:56:55 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 16 Nov 2010 09:56:55 -0800 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <1289927015-sup-9843@pinkfloyd.chass.utoronto.ca> References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> <20101116141911.GZ28050@sebastiankayser.de> <AANLkTikJcqhmxdKMd5CoiMsUxE+dmGTfT6nsgpqqVHq4@mail.gmail.com> <AANLkTinxgZzYhByjzya7oKOZ8BWm3Kjowq=c1eTmhnH+@mail.gmail.com> <1289927015-sup-9843@pinkfloyd.chass.utoronto.ca> Message-ID: <AANLkTi=bfKw0MRkskwZNvcXZsMQabRQ_V_raH=5eRsv4@mail.gmail.com> On 11/16/10, Ben Walton <bwalton at opencsw.org> wrote: > Excerpts from Philip Brown's message of Tue Nov 16 12:00:41 -0500 2010: > >> "The benefit " is supposed to be for the user, not the maintainer OR >> the release manager. :) > > Sebastian made a valid point in this regard. Other than a few extra > http fetches, they typically won't notice (in any meaningful sense) > whether they grab a few extra packages or not. > > What they _will_ notices is nicer transitions of packages as > _maintainers_ have a lot more freedom to upgrade packages gradually > instead of as a big lump. > This should result in a better user experience overall. There isnt a single "ALWAYS TRUE" method for this. Certainly, there's a "usually true". but not always. That's why the debian policy is the way it is. They've had years more experience dealing with this issue than than us, right? And they explicitly call out that it is just fine to have a single package, that itself contains multiple shared libs, rather than splitting out the shared libs into individual packages. (if the libs are always going to be upgraded together) The "libcups" stuff pending in newpkgs, is actually a perfect example of this. When will a user EVER want to upgrade them separately? Or even a maintainer? Come on now.. you cant honestly say either a user Or a maintainer will deliberately want to ever upgrade them separately. A maintainer will just grab the latest release of cups, run a make, and release the full set of packages that are generated. These days, even when I suggest to a maintainer, "hey, there's a problem with this one package in your (set of 4, 6,8), but the rest are fine"... no-one ever gives me back the one package. They dump a full set on me again. Seems like it's this sort of reason why debian, and pretty much any other distro on the planet, only has a single "libcups" package, rather than 6 separate ones for each of the shared libs in there. From phil at bolthole.com Tue Nov 16 19:11:32 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 16 Nov 2010 10:11:32 -0800 Subject: [csw-maintainers] [csw-users] important change: length of software names In-Reply-To: <9EAC9604-37ED-471E-A602-97380AAADD6C@opencsw.org> References: <AANLkTi=+HqXBP_4Jxe8u-ze_-J7XFzU-34qPt1+LMFfD@mail.gmail.com> <9EAC9604-37ED-471E-A602-97380AAADD6C@opencsw.org> Message-ID: <AANLkTimAkbapPb8kmZVj8tzMXmcY8U45HjcksjEV9G5W@mail.gmail.com> On 11/15/10, Dagobert Michelsen <dam at opencsw.org> wrote: > Hi, > > Ok, two weeks from the inital post, only positive feedback from maintainers, > none from users. Is this settled to 32 characters, than? >... FYI, this is now done. Database tables are modified, and my registration checks updated. Reminder: PKG length = 32, softwarename=29 Packages within those lengths can now be accepted. I also updated svn for CSWcswutils, for the next time Ben feels like updating the package. From maciej at opencsw.org Tue Nov 16 19:15:29 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 16 Nov 2010 18:15:29 +0000 Subject: [csw-maintainers] apache 1.3 retirement? In-Reply-To: <AANLkTiksToNrnXr1QM5Ln-AfQzUR3WenyqZghgHp-7Yo@mail.gmail.com> References: <1289876125-sup-6296@pinkfloyd.chass.utoronto.ca> <AANLkTi=Mz-J=sQWgtfhW6tL_X+y31ynHrpSYRfKTt9Uz@mail.gmail.com> <AANLkTi=_=ptUqU=RZq3UtsfG0-eZZQzWH2TR+xDfTUPw@mail.gmail.com> <1289916578-sup-7589@pinkfloyd.chass.utoronto.ca> <AANLkTiks2UDc1U0WYVe3o0Gxf8MyFUyzD2Ydio+E8N6=@mail.gmail.com> <1289924999-sup-7646@pinkfloyd.chass.utoronto.ca> <x6d3q5jisz.fsf@opencsw.org> <AANLkTiksToNrnXr1QM5Ln-AfQzUR3WenyqZghgHp-7Yo@mail.gmail.com> Message-ID: <AANLkTi=2kntLWT8=dsXuLe8wHSN4iDTEm3LT-DSb=6Nx@mail.gmail.com> No dia 16 de Novembro de 2010 17:24, Philip Brown <phil at bolthole.com> escreveu: > On 11/16/10, Peter FELECAN <pfelecan at opencsw.org> wrote: >> >> Seriously, who distributes today Apache 1.x; who uses it? A reality >> check is good from time to time. > > > reality check: this isnt really about apache1, its about the packages > that USE apache 1. > When those packages dont use it any more, I would be very happy to > remove apache1 from our catalog. The packages that depend on apache 1.x, why do they depend on it? It it a strong dependency, or is it just that they need a web server to run? Does anyone know? From phil at bolthole.com Tue Nov 16 19:19:04 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 16 Nov 2010 10:19:04 -0800 Subject: [csw-maintainers] http://www.opencsw.org/packages/<pkg>: Add GAR build recipe URL to package page? In-Reply-To: <1F550B4F-E5CA-405C-A6ED-52AB09EA3023@opencsw.org> References: <AANLkTinDZMHfx3gf=unSnYWPhpPGzcM4ppmg3pfeYntu@mail.gmail.com> <AANLkTi=oCjs+VqVvr8iAkApYAcXpDurhSmE+heEv79e=@mail.gmail.com> <AANLkTim1d82p_u9+YpT877jQRpb0dz4HqzFTVs+zHi1M@mail.gmail.com> <AANLkTi=CfQpjWCn4R72QzX=6nKZkf3OKDrc_tjBAvYFe@mail.gmail.com> <AANLkTikFLm7HBncpo4tqCB0aD+0NKC8f07wZ3jopA7ys@mail.gmail.com> <20101105162742.GA15588@sebastiankayser.de> <AANLkTi=qiP57EoqARAaCK=nPgxw+U2B=-fWvx3KKs7V=@mail.gmail.com> <4CDB292D.3090108@opencsw.org> <AANLkTikYhpD4mZ0-Xx9jMRYZzzOBaY65S0jqHY0OwoYi@mail.gmail.com> <EDB0F459-82F6-42E8-9E39-44141E84EE57@opencsw.org> <20101111171050.GP28050@sebastiankayser.de> <AANLkTimW2xVb=nwQuqKi7G1Qgb21GRttoZ7JOJGPboGT@mail.gmail.com> <1289672497-sup-4152@pinkfloyd.chass.utoronto.ca> <AANLkTik0iWrkpeu+N3_V8jeHZfActj9K3Pha2PqxbP7T@mail.gmail.com> <1F550B4F-E5CA-405C-A6ED-52AB09EA3023@opencsw.org> Message-ID: <AANLkTi=k8PeoCr_v28FPiVnruxu2hWoVPU0ZYw2hXO5K@mail.gmail.com> On 11/15/10, Dagobert Michelsen <dam at opencsw.org> wrote: > >> If so, then the database size for storing the OPENCSW_REPOSITORY info >> could be limited to >> 31 + fileseparator + 31 = 63. Make it 64 just to be 'rounded' >> >> hmmm? > > Nope. The server name prefix to the repository should be stripped > up to the repository root, which is > Repository Root: https://gar.svn.sf.net/svnroot/gar > The path length is not directly connected to the catalog-, nor > the package name, but the upstream name which may or may not > be similar in length. Short answer: Just user 255 and we never > will have this discussion again :-) 64 vs 255, I can live with 255 :) Table modified. Now we have to decide if we're going to attempt to retroactively register old packages, or just go for a "from here on in" stance. Hmm. I was thinking of suggesting a longer "root" to strip. if you strip out what you are suggesting, you still get a somewhat ugly csw/mgar/pkg/apache2/trunk at 11200 "csw/mgar/pkg" is also pretty much redundant. Shouldnt we strip that out also, and just save stuff under "pkg" ? From bonivart at opencsw.org Tue Nov 16 19:22:57 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 16 Nov 2010 19:22:57 +0100 Subject: [csw-maintainers] apache 1.3 retirement? In-Reply-To: <AANLkTi=2kntLWT8=dsXuLe8wHSN4iDTEm3LT-DSb=6Nx@mail.gmail.com> References: <1289876125-sup-6296@pinkfloyd.chass.utoronto.ca> <AANLkTi=Mz-J=sQWgtfhW6tL_X+y31ynHrpSYRfKTt9Uz@mail.gmail.com> <AANLkTi=_=ptUqU=RZq3UtsfG0-eZZQzWH2TR+xDfTUPw@mail.gmail.com> <1289916578-sup-7589@pinkfloyd.chass.utoronto.ca> <AANLkTiks2UDc1U0WYVe3o0Gxf8MyFUyzD2Ydio+E8N6=@mail.gmail.com> <1289924999-sup-7646@pinkfloyd.chass.utoronto.ca> <x6d3q5jisz.fsf@opencsw.org> <AANLkTiksToNrnXr1QM5Ln-AfQzUR3WenyqZghgHp-7Yo@mail.gmail.com> <AANLkTi=2kntLWT8=dsXuLe8wHSN4iDTEm3LT-DSb=6Nx@mail.gmail.com> Message-ID: <AANLkTim_fPSeCcObkNdNrBWHxiJ1qYQ-+_GaRgh6vWNx@mail.gmail.com> On Tue, Nov 16, 2010 at 7:15 PM, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: > The packages that depend on apache 1.x, why do they depend on it? ?It > it a strong dependency, or is it just that they need a web server to > run? ?Does anyone know? RT is the biggest one and it certainly doesn't require Apache 1.x (which is EOL btw). Does anyone know if our RT works at all? With all the changes to Perl and all the modules needed by RT, who can tell? I think we could just unpack RT, modify the dependencies and release it again with an updated REV-stamp. It wouldn't be worse than what we have today and we would have gotten rid of the largest dependency to Apache 1.x. /peter From bonivart at opencsw.org Tue Nov 16 19:26:43 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 16 Nov 2010 19:26:43 +0100 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <AANLkTi=bfKw0MRkskwZNvcXZsMQabRQ_V_raH=5eRsv4@mail.gmail.com> References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> <20101116141911.GZ28050@sebastiankayser.de> <AANLkTikJcqhmxdKMd5CoiMsUxE+dmGTfT6nsgpqqVHq4@mail.gmail.com> <AANLkTinxgZzYhByjzya7oKOZ8BWm3Kjowq=c1eTmhnH+@mail.gmail.com> <1289927015-sup-9843@pinkfloyd.chass.utoronto.ca> <AANLkTi=bfKw0MRkskwZNvcXZsMQabRQ_V_raH=5eRsv4@mail.gmail.com> Message-ID: <AANLkTikHY2uWbj_DkL9PM7XOa5V1zqcU_1JTh7_Ps=4u@mail.gmail.com> On Tue, Nov 16, 2010 at 6:56 PM, Philip Brown <phil at bolthole.com> wrote: > Seems like it's this sort of reason why debian, and pretty much any > other distro on the planet, only has a single "libcups" package, > rather than 6 separate ones for each of the shared libs in there. But how can it hurt if the maintainer chose to split up the libs? I understand that, the opposite, keeping multiple libs in one package can sometimes be a problem and cause for rejection but how is this a real problem? /peter From phil at bolthole.com Tue Nov 16 19:33:30 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 16 Nov 2010 10:33:30 -0800 Subject: [csw-maintainers] apache 1.3 retirement? In-Reply-To: <AANLkTi=2kntLWT8=dsXuLe8wHSN4iDTEm3LT-DSb=6Nx@mail.gmail.com> References: <1289876125-sup-6296@pinkfloyd.chass.utoronto.ca> <AANLkTi=Mz-J=sQWgtfhW6tL_X+y31ynHrpSYRfKTt9Uz@mail.gmail.com> <AANLkTi=_=ptUqU=RZq3UtsfG0-eZZQzWH2TR+xDfTUPw@mail.gmail.com> <1289916578-sup-7589@pinkfloyd.chass.utoronto.ca> <AANLkTiks2UDc1U0WYVe3o0Gxf8MyFUyzD2Ydio+E8N6=@mail.gmail.com> <1289924999-sup-7646@pinkfloyd.chass.utoronto.ca> <x6d3q5jisz.fsf@opencsw.org> <AANLkTiksToNrnXr1QM5Ln-AfQzUR3WenyqZghgHp-7Yo@mail.gmail.com> <AANLkTi=2kntLWT8=dsXuLe8wHSN4iDTEm3LT-DSb=6Nx@mail.gmail.com> Message-ID: <AANLkTim0RoeTbxBkhPPxTLbZ0fTYR72g51RWnrzqbTJb@mail.gmail.com> On 11/16/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: > No dia 16 de Novembro de 2010 17:24, Philip Brown <phil at bolthole.com> > escreveu: > >> reality check: this isnt really about apache1, its about the packages >> that USE apache 1. >> When those packages dont use it any more, I would be very happy to >> remove apache1 from our catalog. > > The packages that depend on apache 1.x, why do they depend on it? It > it a strong dependency, or is it just that they need a web server to > run? Does anyone know? I dont think sqwebmail cares. not sure about htdig. rt v3 originally had a problem, in that it was *only* compatible with the mod_perl for apache1 GOOD NEWS, though: newer versions of rt, can use mod_perl2, for apache2. From maciej at opencsw.org Tue Nov 16 19:41:32 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 16 Nov 2010 18:41:32 +0000 Subject: [csw-maintainers] [csw-users] important change: length of software names In-Reply-To: <AANLkTimAkbapPb8kmZVj8tzMXmcY8U45HjcksjEV9G5W@mail.gmail.com> References: <AANLkTi=+HqXBP_4Jxe8u-ze_-J7XFzU-34qPt1+LMFfD@mail.gmail.com> <9EAC9604-37ED-471E-A602-97380AAADD6C@opencsw.org> <AANLkTimAkbapPb8kmZVj8tzMXmcY8U45HjcksjEV9G5W@mail.gmail.com> Message-ID: <AANLkTimQ3YXSdNr1Ka1Tg3KQQ-OxyrEHCHtva7nAXXcp@mail.gmail.com> No dia 16 de Novembro de 2010 18:11, Philip Brown <phil at bolthole.com> escreveu: > On 11/15/10, Dagobert Michelsen <dam at opencsw.org> wrote: >> Hi, >> >> Ok, two weeks from the inital post, only positive feedback from maintainers, >> none from users. Is this settled to 32 characters, than? >>... > > FYI, this is now done. Not quite done yet; checkpkg hasn't been updated[1]. Why didn't you talk to me to coordinate this? [1] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/package_checks.py#L59 From phil at bolthole.com Tue Nov 16 19:52:49 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 16 Nov 2010 10:52:49 -0800 Subject: [csw-maintainers] [csw-users] important change: length of software names In-Reply-To: <AANLkTimQ3YXSdNr1Ka1Tg3KQQ-OxyrEHCHtva7nAXXcp@mail.gmail.com> References: <AANLkTi=+HqXBP_4Jxe8u-ze_-J7XFzU-34qPt1+LMFfD@mail.gmail.com> <9EAC9604-37ED-471E-A602-97380AAADD6C@opencsw.org> <AANLkTimAkbapPb8kmZVj8tzMXmcY8U45HjcksjEV9G5W@mail.gmail.com> <AANLkTimQ3YXSdNr1Ka1Tg3KQQ-OxyrEHCHtva7nAXXcp@mail.gmail.com> Message-ID: <AANLkTinJMjjGDvc_DOcHzTansh=qkE_0Z5bms1SLrh5T@mail.gmail.com> On 11/16/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: > No dia 16 de Novembro de 2010 18:11, Philip Brown <phil at bolthole.com> > escreveu: >> On 11/15/10, Dagobert Michelsen <dam at opencsw.org> wrote: >>> Hi, >>> >>> Ok, two weeks from the inital post, only positive feedback from >>> maintainers, >>> none from users. Is this settled to 32 characters, than? >>>... >> >> FYI, this is now done. > > Not quite done yet; checkpkg hasn't been updated[1]. Why didn't you > talk to me to coordinate this? > Since people had recently already submitted packages longer than 20 chars, I thought there was no need for further coordination :-} no worries. and no need to rush on my account :-D From phil at bolthole.com Tue Nov 16 20:10:47 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 16 Nov 2010 11:10:47 -0800 Subject: [csw-maintainers] apache 1.3 retirement? In-Reply-To: <AANLkTim0RoeTbxBkhPPxTLbZ0fTYR72g51RWnrzqbTJb@mail.gmail.com> References: <1289876125-sup-6296@pinkfloyd.chass.utoronto.ca> <AANLkTi=Mz-J=sQWgtfhW6tL_X+y31ynHrpSYRfKTt9Uz@mail.gmail.com> <AANLkTi=_=ptUqU=RZq3UtsfG0-eZZQzWH2TR+xDfTUPw@mail.gmail.com> <1289916578-sup-7589@pinkfloyd.chass.utoronto.ca> <AANLkTiks2UDc1U0WYVe3o0Gxf8MyFUyzD2Ydio+E8N6=@mail.gmail.com> <1289924999-sup-7646@pinkfloyd.chass.utoronto.ca> <x6d3q5jisz.fsf@opencsw.org> <AANLkTiksToNrnXr1QM5Ln-AfQzUR3WenyqZghgHp-7Yo@mail.gmail.com> <AANLkTi=2kntLWT8=dsXuLe8wHSN4iDTEm3LT-DSb=6Nx@mail.gmail.com> <AANLkTim0RoeTbxBkhPPxTLbZ0fTYR72g51RWnrzqbTJb@mail.gmail.com> Message-ID: <AANLkTikeTz-z_iMCgW28TjLX1ikXfcU4A1ZQugX1g1g_@mail.gmail.com> On 11/16/10, Philip Brown <phil at bolthole.com> wrote: > On 11/16/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: >> >> The packages that depend on apache 1.x, why do they depend on it? It >> it a strong dependency, or is it just that they need a web server to >> run? Does anyone know? > ... > > rt v3 originally had a problem, in that it was *only* compatible with > the mod_perl for apache1 > PS: I know this sort of thing, specifically because I've been the release manager for 7 years, and I bug people by asking questions such as "Why are you doing it this way? Why dont use use apache2 instead?" :-) From pfelecan at opencsw.org Tue Nov 16 20:16:51 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 16 Nov 2010 20:16:51 +0100 Subject: [csw-maintainers] apache 1.3 retirement? In-Reply-To: <AANLkTiksToNrnXr1QM5Ln-AfQzUR3WenyqZghgHp-7Yo@mail.gmail.com> (Philip Brown's message of "Tue, 16 Nov 2010 09:24:56 -0800") References: <1289876125-sup-6296@pinkfloyd.chass.utoronto.ca> <AANLkTi=Mz-J=sQWgtfhW6tL_X+y31ynHrpSYRfKTt9Uz@mail.gmail.com> <AANLkTi=_=ptUqU=RZq3UtsfG0-eZZQzWH2TR+xDfTUPw@mail.gmail.com> <1289916578-sup-7589@pinkfloyd.chass.utoronto.ca> <AANLkTiks2UDc1U0WYVe3o0Gxf8MyFUyzD2Ydio+E8N6=@mail.gmail.com> <1289924999-sup-7646@pinkfloyd.chass.utoronto.ca> <x6d3q5jisz.fsf@opencsw.org> <AANLkTiksToNrnXr1QM5Ln-AfQzUR3WenyqZghgHp-7Yo@mail.gmail.com> Message-ID: <x6zkt9hye4.fsf@opencsw.org> Philip Brown <phil at bolthole.com> writes: > On 11/16/10, Peter FELECAN <pfelecan at opencsw.org> wrote: >> >> Seriously, who distributes today Apache 1.x; who uses it? A reality >> check is good from time to time. > > > reality check: this isnt really about apache1, its about the packages > that USE apache 1. That I understood. > When those packages dont use it any more, I would be very happy to > remove apache1 from our catalog. More the one maintainer proposed work on that. > Perhaps you would like to DO something to help clean up the current > state of things? Yup. But only after discussing the other issues that I raised. -- Peter From maciej at opencsw.org Tue Nov 16 21:10:36 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 16 Nov 2010 20:10:36 +0000 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <AANLkTinxgZzYhByjzya7oKOZ8BWm3Kjowq=c1eTmhnH+@mail.gmail.com> References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> <20101116141911.GZ28050@sebastiankayser.de> <AANLkTikJcqhmxdKMd5CoiMsUxE+dmGTfT6nsgpqqVHq4@mail.gmail.com> <AANLkTinxgZzYhByjzya7oKOZ8BWm3Kjowq=c1eTmhnH+@mail.gmail.com> Message-ID: <AANLkTimbVdh3ukL2hksovy7p7YKXyO_Jn=hbvxUybGi+@mail.gmail.com> No dia 16 de Novembro de 2010 17:00, Philip Brown <phil at bolthole.com> escreveu: > On 11/16/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: >> No dia 16 de Novembro de 2010 14:19, Sebastian Kayser >> <skayser at opencsw.org> escreveu: >>> * Philip Brown <phil at bolthole.com> wrote: >>>> I will also mention, given that Maciej gave the debian sharedlibs >>>> policy (section 8.1) as a reference, if we abided by the WHOLE text of >>>> that section. Again, my further notes on that, are at the bottom of >>>> the wiki page. >>> >>> When it comes to policy vs "when seen beneficial" in this case, I regard >>> it as helpful to have as few exceptions and as much of a standard as >>> possible. >> >> There's also the question of who is the subject to see the benefit. > > "The benefit " is supposed to be for the user, not the maintainer OR > the release manager. :) How does the release manager know what's the best for the user? It's not a rhetorical question. I'm interested to know in the process. > As far as who determines it before the package is released: > by definition, the person with the most authority to make that > decision, is the release manager. > >> Is it the maintainer or the release manager? ?What if the two >> disagree? > > Ideally, "the maintainer" should respect the release manager's > experience in the matter. > But there's always recourse to the board. I guess there's also the question of the reasons for rejecting a package. The release manager, despite having more power, can't reject a package because, let's say, he doesn't like the maintainer. There has to be a valid reason. I hope you agree. From gadavis at opencsw.org Tue Nov 16 21:57:26 2010 From: gadavis at opencsw.org (Geoff Davis) Date: Tue, 16 Nov 2010 12:57:26 -0800 Subject: [csw-maintainers] apache 1.3 retirement? In-Reply-To: <AANLkTim_fPSeCcObkNdNrBWHxiJ1qYQ-+_GaRgh6vWNx@mail.gmail.com> References: <1289876125-sup-6296@pinkfloyd.chass.utoronto.ca> <AANLkTi=Mz-J=sQWgtfhW6tL_X+y31ynHrpSYRfKTt9Uz@mail.gmail.com> <AANLkTi=_=ptUqU=RZq3UtsfG0-eZZQzWH2TR+xDfTUPw@mail.gmail.com> <1289916578-sup-7589@pinkfloyd.chass.utoronto.ca> <AANLkTiks2UDc1U0WYVe3o0Gxf8MyFUyzD2Ydio+E8N6=@mail.gmail.com> <1289924999-sup-7646@pinkfloyd.chass.utoronto.ca> <x6d3q5jisz.fsf@opencsw.org> <AANLkTiksToNrnXr1QM5Ln-AfQzUR3WenyqZghgHp-7Yo@mail.gmail.com> <AANLkTi=2kntLWT8=dsXuLe8wHSN4iDTEm3LT-DSb=6Nx@mail.gmail.com> <AANLkTim_fPSeCcObkNdNrBWHxiJ1qYQ-+_GaRgh6vWNx@mail.gmail.com> Message-ID: <64C0EACE-16AA-4A38-ADC7-32FE1777911D@opencsw.org> On Nov 16, 2010, at 10:22 AM, Peter Bonivart wrote: > Does anyone know if our RT works at all? With all the changes to Perl > and all the modules needed by RT, who can tell? I'm not sure. The Blastwave (pre-fork) version was hopelessly out of date and required Apache 1 when we were evaluating it in September 2008, so we went with a hand-rolled version of 3.8.1 using the Blastwave mod_perl 2.x under Perl 5.8. We stopped using RT at my site about a year ago (we replaced it with Jira) but kept an instance around in read-only mode for reference. When we went to migrate our old read-only RT server to a new Zone instance this past August, it didn't work. As I didn't attempt the migration myself, I don't know exactly which perl module(s) were the problem. From my experiences with trying to keep multiple versions of RT 2.x and 3.x alive over the past 8 years, I can say with some authority that RT (and it's tight dependency HTML::Mason) is incredibly finicky about the explicit Perl module versions that it uses. This makes it a nightmare for the end-user sysadmin and I would imagine for the CSW maintainers who want to keep things current. For this reason, the servers on which RT ran eventually NEVER got CSW package updates because the module upgrades would break RT on a regular basis if given a chance. From bonivart at opencsw.org Tue Nov 16 22:03:50 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 16 Nov 2010 22:03:50 +0100 Subject: [csw-maintainers] apache 1.3 retirement? In-Reply-To: <64C0EACE-16AA-4A38-ADC7-32FE1777911D@opencsw.org> References: <1289876125-sup-6296@pinkfloyd.chass.utoronto.ca> <AANLkTi=Mz-J=sQWgtfhW6tL_X+y31ynHrpSYRfKTt9Uz@mail.gmail.com> <AANLkTi=_=ptUqU=RZq3UtsfG0-eZZQzWH2TR+xDfTUPw@mail.gmail.com> <1289916578-sup-7589@pinkfloyd.chass.utoronto.ca> <AANLkTiks2UDc1U0WYVe3o0Gxf8MyFUyzD2Ydio+E8N6=@mail.gmail.com> <1289924999-sup-7646@pinkfloyd.chass.utoronto.ca> <x6d3q5jisz.fsf@opencsw.org> <AANLkTiksToNrnXr1QM5Ln-AfQzUR3WenyqZghgHp-7Yo@mail.gmail.com> <AANLkTi=2kntLWT8=dsXuLe8wHSN4iDTEm3LT-DSb=6Nx@mail.gmail.com> <AANLkTim_fPSeCcObkNdNrBWHxiJ1qYQ-+_GaRgh6vWNx@mail.gmail.com> <64C0EACE-16AA-4A38-ADC7-32FE1777911D@opencsw.org> Message-ID: <AANLkTimRy0fjwWfXmpzPZtVSGVahjkyKG9_5gkctu5B+@mail.gmail.com> On Tue, Nov 16, 2010 at 9:57 PM, Geoff Davis <gadavis at opencsw.org> wrote: > From my experiences with trying to keep multiple versions of RT 2.x and 3.x alive over the past 8 years, I can say with some authority that RT (and it's tight dependency HTML::Mason) is incredibly finicky about the explicit Perl module versions that it uses. This makes it a nightmare for the end-user sysadmin and I would imagine for the CSW maintainers who want to keep things current. For this reason, the servers on which RT ran eventually NEVER got CSW package updates because the module upgrades would break RT on a regular basis if given a chance. This is exactly what I've heard as well. I think my "fix" for RT would do no harm to RT (which probably doesn't work anyway) and it's one less dep to Apache 1. Long term we should provide a complete collection of deps for RT or maybe a VM image? We need a new RT maintainer though. /peter From phil at bolthole.com Tue Nov 16 22:18:52 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 16 Nov 2010 13:18:52 -0800 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <AANLkTimbVdh3ukL2hksovy7p7YKXyO_Jn=hbvxUybGi+@mail.gmail.com> References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> <20101116141911.GZ28050@sebastiankayser.de> <AANLkTikJcqhmxdKMd5CoiMsUxE+dmGTfT6nsgpqqVHq4@mail.gmail.com> <AANLkTinxgZzYhByjzya7oKOZ8BWm3Kjowq=c1eTmhnH+@mail.gmail.com> <AANLkTimbVdh3ukL2hksovy7p7YKXyO_Jn=hbvxUybGi+@mail.gmail.com> Message-ID: <AANLkTin1aQqh_LezTgPd0A3wYmT8fc_XCrEPnuW532_D@mail.gmail.com> On 11/16/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: > No dia 16 de Novembro de 2010 17:00, Philip Brown <phil at bolthole.com> > escreveu: > > How does the release manager know what's the best for the user? It's > not a rhetorical question. I'm interested to know in the process. Maciej, we've been round this particular discussion at least 3 times before :-/ Previously, you have been asking with an eye to "well, tell me the process, and then we'll automate it". To which the reply has been, is, and always will be, "you cant automate EVERYTHING. Certainly, the things that can be, we should. But there are things that cannot be". If you are NOT asking in that "Give me machine readable procedure" context, but truly out of inquiry, then I will attempt to give you a good faith answer. (It's a pain in the butt. I WISH it could be more automated :) Your extra gar-checkpkg stuff has helped, which is nice) My registration script gives me a quick overview of what files are in the package, what dependancies it has, and what shared libs it uses. (maybe one or two other things i forget). For trivial packages, I usually just "wave them through". ** For new maintainers, I try to spend a bit more time digging. For new packages, I try to spend a bit more time digging. For packages that have changed (names, etc) I try to spend a bit more time digging. If I notice some odd pathnames, I query the maintainer. If I notice some odd/obsolete/non-optimal dependancies, I query the maintainer For packages that have not been updated in a very long time, I try to spend a bit more time digging. Some types of package I tend to wave through, UNLESS they have obnoxious names or other blatant oddities. eg: perl, ruby, and python packages. If someone wanted to actually spend TIME being a (perl/ruby/python) release manager, I would welcome the extra scrutiny. I myself am not qualified to deeply examine them, so I usually just pass them through, with the exception of the libpython, and "where do the scripts live" issues, which I attempt to keep consistent for the good of all. Some things that will be viewed as inconsistent: I have limited time. I'm not paid for this. So, sometimes, things get delayed, when I think, "this one should probably be looked at more, but I dont have time right now". And sometimes, I wave them through because they've waited long enough, and I just hope to look at them more 'next time around'. Or, "the maintainer has already done 10 of this type, I'm sure this one is the same" And sometimes, I was simply not aware of a problem the first time(or 2nd or 3rd) a package goes through. But after seeing similar issues with other packages, I will then hold up something to bug a maintainer, for an issue which they previously thought was okay. Sometimes, a particular thing does not seem like an issue to me at first. but then when I notice 3 or 4 packages going through the same way, my mind may notice something and say "Hey wait a minute!" and bug that maintainer. Nothing against that maintainer personally... its just at that point that my eyes happen to notice something in the file listings scrolling by, or whatever. > I guess there's also the question of the reasons for rejecting a > package. The release manager, despite having more power, can't reject > a package because, let's say, he doesn't like the maintainer. There > has to be a valid reason. I hope you agree. Of course. I can say with all honesty that I have *never* rejected a package because I "dont like" someone. Some people may claim that I have... but its important to note that they usually make this claim, instead of doing work to alter what I'm complaining about. If they had just done the work, they would have seen the package go through. Bad feeling may build up, when a maintainer goes through multiple times of rebuilding a package, but it's nothing about the maintainer personally. Its just that when I reach a problem, I say "fix this please", without looking further. Once they fix the problem, then I continue looking through it. What is unfortunate for positive feeling, is that I do usually look harder at a package that has had a problem already. NOT because I "dislike the maintainer", but because it is very often the case, that when a package has one problem, it usually has more. So when I hit a problem with a package, I do look even harder once I get a repackage of it. Not because I dislike the maintainer, but because I want our packages to be as clean for our users as possible. So where there are likely more problems, I look for more problems. I havent kept records, but it does seem like packages more often have 2+ problems, than just 1. and if you're wondering how I judge "problem", I go by our "core value": 'to provide a straightforward, easy-to-use experience for the user' The tricky bit is in balancing the needs from all of our different types of user: home, corporate, smallscale, and large scale. It requires a lot of human judgement. For which, I use my 7 years experience as a release manager, and 20 years experience as a sysadmin. From bwalton at opencsw.org Wed Nov 17 16:06:47 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 17 Nov 2010 10:06:47 -0500 Subject: [csw-maintainers] http://www.opencsw.org/packages/<pkg>: Add GAR build recipe URL to package page? In-Reply-To: <AANLkTi=k8PeoCr_v28FPiVnruxu2hWoVPU0ZYw2hXO5K@mail.gmail.com> References: <AANLkTinDZMHfx3gf=unSnYWPhpPGzcM4ppmg3pfeYntu@mail.gmail.com> <AANLkTi=oCjs+VqVvr8iAkApYAcXpDurhSmE+heEv79e=@mail.gmail.com> <AANLkTim1d82p_u9+YpT877jQRpb0dz4HqzFTVs+zHi1M@mail.gmail.com> <AANLkTi=CfQpjWCn4R72QzX=6nKZkf3OKDrc_tjBAvYFe@mail.gmail.com> <AANLkTikFLm7HBncpo4tqCB0aD+0NKC8f07wZ3jopA7ys@mail.gmail.com> <20101105162742.GA15588@sebastiankayser.de> <AANLkTi=qiP57EoqARAaCK=nPgxw+U2B=-fWvx3KKs7V=@mail.gmail.com> <4CDB292D.3090108@opencsw.org> <AANLkTikYhpD4mZ0-Xx9jMRYZzzOBaY65S0jqHY0OwoYi@mail.gmail.com> <EDB0F459-82F6-42E8-9E39-44141E84EE57@opencsw.org> <20101111171050.GP28050@sebastiankayser.de> <AANLkTimW2xVb=nwQuqKi7G1Qgb21GRttoZ7JOJGPboGT@mail.gmail.com> <1289672497-sup-4152@pinkfloyd.chass.utoronto.ca> <AANLkTik0iWrkpeu+N3_V8jeHZfActj9K3Pha2PqxbP7T@mail.gmail.com> <1F550B4F-E5CA-405C-A6ED-52AB09EA3023@opencsw.org> <AANLkTi=k8PeoCr_v28FPiVnruxu2hWoVPU0ZYw2hXO5K@mail.gmail.com> Message-ID: <1290006319-sup-2226@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Nov 16 13:19:04 -0500 2010: > csw/mgar/pkg/apache2/trunk at 11200 > > "csw/mgar/pkg" is also pretty much redundant. Shouldnt we strip that > out also, and just save stuff under "pkg" ? I agree with this. Nothing that gets registered in the package database should live above this portion of the svn URL. Even though we could conceivably build a package from source that lives higher, the build recipe/makefile that built it (and hence gets registered) would be nested under pkg/. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Wed Nov 17 16:19:00 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 17 Nov 2010 16:19:00 +0100 Subject: [csw-maintainers] http://www.opencsw.org/packages/<pkg>: Add GAR build recipe URL to package page? In-Reply-To: <1290006319-sup-2226@pinkfloyd.chass.utoronto.ca> References: <AANLkTinDZMHfx3gf=unSnYWPhpPGzcM4ppmg3pfeYntu@mail.gmail.com> <AANLkTi=oCjs+VqVvr8iAkApYAcXpDurhSmE+heEv79e=@mail.gmail.com> <AANLkTim1d82p_u9+YpT877jQRpb0dz4HqzFTVs+zHi1M@mail.gmail.com> <AANLkTi=CfQpjWCn4R72QzX=6nKZkf3OKDrc_tjBAvYFe@mail.gmail.com> <AANLkTikFLm7HBncpo4tqCB0aD+0NKC8f07wZ3jopA7ys@mail.gmail.com> <20101105162742.GA15588@sebastiankayser.de> <AANLkTi=qiP57EoqARAaCK=nPgxw+U2B=-fWvx3KKs7V=@mail.gmail.com> <4CDB292D.3090108@opencsw.org> <AANLkTikYhpD4mZ0-Xx9jMRYZzzOBaY65S0jqHY0OwoYi@mail.gmail.com> <EDB0F459-82F6-42E8-9E39-44141E84EE57@opencsw.org> <20101111171050.GP28050@sebastiankayser.de> <AANLkTimW2xVb=nwQuqKi7G1Qgb21GRttoZ7JOJGPboGT@mail.gmail.com> <1289672497-sup-4152@pinkfloyd.chass.utoronto.ca> <AANLkTik0iWrkpeu+N3_V8jeHZfActj9K3Pha2PqxbP7T@mail.gmail.com> <1F550B4F-E5CA-405C-A6ED-52AB09EA3023@opencsw.org> <AANLkTi=k8PeoCr_v28FPiVnruxu2hWoVPU0ZYw2hXO5K@mail.gmail.com> <1290006319-sup-2226@pinkfloyd.chass.utoronto.ca> Message-ID: <27547BE1-D407-4F76-B2DA-B97E5C225F89@opencsw.org> Hi, Am 17.11.2010 um 16:06 schrieb Ben Walton: > Excerpts from Philip Brown's message of Tue Nov 16 13:19:04 -0500 > 2010: >> csw/mgar/pkg/apache2/trunk at 11200 >> >> "csw/mgar/pkg" is also pretty much redundant. Shouldnt we strip that >> out also, and just save stuff under "pkg" ? > > I agree with this. Nothing that gets registered in the package > database should live above this portion of the svn URL. Even though > we could conceivably build a package from source that lives higher, > the build recipe/makefile that built it (and hence gets registered) > would be nested under pkg/. I disagree. The path within the repository (with SVNROOT stripped) describes exactly the location of the build description. Why introduce artificial special cases? If the repository is reorganized in some distant future all existing links will be invalid are would need special treatment while retaining the full path with revision will always link directly to the build recipe. Best regards -- Dago From bwalton at opencsw.org Wed Nov 17 16:23:08 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 17 Nov 2010 10:23:08 -0500 Subject: [csw-maintainers] http://www.opencsw.org/packages/<pkg>: Add GAR build recipe URL to package page? In-Reply-To: <27547BE1-D407-4F76-B2DA-B97E5C225F89@opencsw.org> References: <AANLkTinDZMHfx3gf=unSnYWPhpPGzcM4ppmg3pfeYntu@mail.gmail.com> <AANLkTi=oCjs+VqVvr8iAkApYAcXpDurhSmE+heEv79e=@mail.gmail.com> <AANLkTim1d82p_u9+YpT877jQRpb0dz4HqzFTVs+zHi1M@mail.gmail.com> <AANLkTi=CfQpjWCn4R72QzX=6nKZkf3OKDrc_tjBAvYFe@mail.gmail.com> <AANLkTikFLm7HBncpo4tqCB0aD+0NKC8f07wZ3jopA7ys@mail.gmail.com> <20101105162742.GA15588@sebastiankayser.de> <AANLkTi=qiP57EoqARAaCK=nPgxw+U2B=-fWvx3KKs7V=@mail.gmail.com> <4CDB292D.3090108@opencsw.org> <AANLkTikYhpD4mZ0-Xx9jMRYZzzOBaY65S0jqHY0OwoYi@mail.gmail.com> <EDB0F459-82F6-42E8-9E39-44141E84EE57@opencsw.org> <20101111171050.GP28050@sebastiankayser.de> <AANLkTimW2xVb=nwQuqKi7G1Qgb21GRttoZ7JOJGPboGT@mail.gmail.com> <1289672497-sup-4152@pinkfloyd.chass.utoronto.ca> <AANLkTik0iWrkpeu+N3_V8jeHZfActj9K3Pha2PqxbP7T@mail.gmail.com> <1F550B4F-E5CA-405C-A6ED-52AB09EA3023@opencsw.org> <AANLkTi=k8PeoCr_v28FPiVnruxu2hWoVPU0ZYw2hXO5K@mail.gmail.com> <1290006319-sup-2226@pinkfloyd.chass.utoronto.ca> <27547BE1-D407-4F76-B2DA-B9 7E5C225F89@opencsw.org> Message-ID: <1290007298-sup-9644@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Nov 17 10:19:00 -0500 2010: > I disagree. The path within the repository (with SVNROOT stripped) > describes exactly the location of the build description. Why > introduce artificial special cases? If the repository is reorganized > in some distant future all existing links will be invalid are would > need special treatment while retaining the full path with revision > will always link directly to the build recipe. Ok, taking future reorganization into account then yes it does make sense to include the full path. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Wed Nov 17 18:49:08 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 17 Nov 2010 09:49:08 -0800 Subject: [csw-maintainers] http://www.opencsw.org/packages/<pkg>: Add GAR build recipe URL to package page? In-Reply-To: <27547BE1-D407-4F76-B2DA-B97E5C225F89@opencsw.org> References: <AANLkTinDZMHfx3gf=unSnYWPhpPGzcM4ppmg3pfeYntu@mail.gmail.com> <AANLkTi=oCjs+VqVvr8iAkApYAcXpDurhSmE+heEv79e=@mail.gmail.com> <AANLkTim1d82p_u9+YpT877jQRpb0dz4HqzFTVs+zHi1M@mail.gmail.com> <AANLkTi=CfQpjWCn4R72QzX=6nKZkf3OKDrc_tjBAvYFe@mail.gmail.com> <AANLkTikFLm7HBncpo4tqCB0aD+0NKC8f07wZ3jopA7ys@mail.gmail.com> <20101105162742.GA15588@sebastiankayser.de> <AANLkTi=qiP57EoqARAaCK=nPgxw+U2B=-fWvx3KKs7V=@mail.gmail.com> <4CDB292D.3090108@opencsw.org> <AANLkTikYhpD4mZ0-Xx9jMRYZzzOBaY65S0jqHY0OwoYi@mail.gmail.com> <EDB0F459-82F6-42E8-9E39-44141E84EE57@opencsw.org> <20101111171050.GP28050@sebastiankayser.de> <AANLkTimW2xVb=nwQuqKi7G1Qgb21GRttoZ7JOJGPboGT@mail.gmail.com> <1289672497-sup-4152@pinkfloyd.chass.utoronto.ca> <AANLkTik0iWrkpeu+N3_V8jeHZfActj9K3Pha2PqxbP7T@mail.gmail.com> <1F550B4F-E5CA-405C-A6ED-52AB09EA3023@opencsw.org> <AANLkTi=k8PeoCr_v28FPiVnruxu2hWoVPU0ZYw2hXO5K@mail.gmail.com> <1290006319-sup-2226@pinkfloyd.chass.utoronto.ca> <27547BE1-D407-4F76-B2DA-B97E5C225F89@opencsw.org> Message-ID: <AANLkTin8v3M2TTk+nSktqCSSc5T4sO6bEch5ZHvjHA3z@mail.gmail.com> On 11/17/10, Dagobert Michelsen <dam at opencsw.org> wrote: > Hi, > > Am 17.11.2010 um 16:06 schrieb Ben Walton: >> Excerpts from Philip Brown's message of Tue Nov 16 13:19:04 -0500 >> 2010: >>> csw/mgar/pkg/apache2/trunk at 11200 >>> >>> "csw/mgar/pkg" is also pretty much redundant. Shouldnt we strip that >>> out also, and just save stuff under "pkg" ? >> ... > I disagree. The path within the repository (with SVNROOT stripped) > describes exactly the location of the build description. Why > introduce artificial special cases? If the repository is > reorganized in some distant future all existing links will be > invalid are would need special treatment while retaining the full > path with revision will always link directly to the build recipe. I was thinking that stripping things out, should actually make things MORE portable, in the event of a reorganization. Take a starting point of $SVNROOT/csw/mgar/pkg/softname Then lets say it gets reorganized. There are two ways it might get reorganized, that I can see: a) some way that is completely incompatible, ie: $SVNROOT/csw/mgar/pkg/random/stuff/here/softname b) some way that is auto-correctible. Example $SVNROOT/something/else/pkg/softname. I was thinking that we are most likely to keep "pkg/softname". In which case, the web page would need only one consistent change to redirect people from the "old location", to the "new, up to date location". I guess it depends what your goals are. There would seem to be two, mutually conflicting goals: 1. Make it so packages already registered, do not have to be REregistered with new src locations, if we reorganize SVN (assumption: if we reorganize, we will do a clean, transparent migration of EVERYTHING, rather than onsey-twosy migrate) 2. Make it so packages keep the old legacy pathnames. So even if we reorganize, old packages keep pointing to old locations. I THINK Dago is aiming for #2. Whereas it seems to me that #1 is better. From rupert at opencsw.org Wed Nov 17 20:29:21 2010 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 17 Nov 2010 20:29:21 +0100 Subject: [csw-maintainers] Positioning our website In-Reply-To: <AANLkTi=-E89BOEdLv0WhWxbBT4zMzLPFDh3POUpWqvjc@mail.gmail.com> References: <AANLkTi=-E89BOEdLv0WhWxbBT4zMzLPFDh3POUpWqvjc@mail.gmail.com> Message-ID: <AANLkTikHGHWLFjdtfh9ChT1j9ozfpU3nxiZkzhz8Ozx5@mail.gmail.com> when typing "solaris package apache2" our package page is not found. if one goes to to our packages page, we talk about "software packages", but not "solaris packages" or "solaris package". ben, what about changing the wording? i changed the links on http://sourceforge.net/apps/trac/gar from http://opencsw.org to http://www.opencsw.org. On Sat, Nov 13, 2010 at 16:01, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: > I just made a search for "solaris packages" on Google and I saw that > out of the first 10 results: > > 3 are actual Solaris package projects (we aren't any of the 3) > 3 are packaging howtos > 2 are pages that just point to other pages and provide little actual materials > 1 belongs to a specific open source project which offers Solaris packages > 1 is a blog entry on Wordpress.com I wrote some time ago > > Not seeing opencsw.org within first 10 results is depressing. ?Our > website was the result number 20, the last one on the second page. > This is of course better than nothing, but I believe we deserve a > better position. > > I see two things we can do to improve the situation. > > The first one is our domain registration. ?Here's a snippet from whois: > > Domain ID:D153552903-LROR > Domain Name:OPENCSW.ORG > Created On:08-Aug-2008 08:29:30 UTC > Last Updated On:14-Sep-2010 20:19:19 UTC > Expiration Date:08-Aug-2011 08:29:30 UTC > > I'm not sure what the "Last updated" field means here, whether it was > the renewal date or an unrelated metadata update. ?In either case, I > believe that extending our registration to 2 or 3 years into the > future would give us a huge boost. ?Google considers domains that are > registered for a short duration less trustworthy and demotes them in > search results. ?Extending the registration can be a really quick fix > for our positioning. ?Dago, can you take care of that? > > The other suggestion requires more people to work together. ?There are > essentially two things we can try doing: > > - work on moving opencsw.org up until it gets into the first 10 > - create pages that can get into the first 10 > > If my blog post can get into the first 10, many other pages can too. > For instance, I know that some of us write blogs. ?If you keep on > writing blog posts with the "solaris packages" phrase in the <title> > tag, and linking to opencsw.org, it'll help both sites. ?The page rank > of opencsw.org will go up - good! ?If it's your blog post and not > opencsw.org that makes it into the first 10, that's great too. ?If > your blog post has a link to opencsw.org, people will click on it and > learn about our project, and potentially start using our packages. > > I'm going to start by writing yet another Solaris packaging howto, > focused on using GAR and being short. ?It's something I meant to do > anyway, but after looking the positioning issue, I'll make sure my > howto's title contains "solaris packages" and features prominent links > to opencsw.org. > > Do other people have topics they can write about? > > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From phil at bolthole.com Wed Nov 17 20:48:36 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 17 Nov 2010 11:48:36 -0800 Subject: [csw-maintainers] Positioning our website In-Reply-To: <AANLkTikHGHWLFjdtfh9ChT1j9ozfpU3nxiZkzhz8Ozx5@mail.gmail.com> References: <AANLkTi=-E89BOEdLv0WhWxbBT4zMzLPFDh3POUpWqvjc@mail.gmail.com> <AANLkTikHGHWLFjdtfh9ChT1j9ozfpU3nxiZkzhz8Ozx5@mail.gmail.com> Message-ID: <AANLkTi=2zFr2_Vp86Yoek6nYzYc6za95G3HiTDjX9d_W@mail.gmail.com> On 11/17/10, rupert THURNER <rupert at opencsw.org> wrote: > when typing "solaris package apache2" [into google] our package page is not found. > if one goes to to our packages page, we talk about "software > packages", but not "solaris packages" or "solaris package". ben, what > about changing the wording? I should point out that this is something in favor of what I was saying regarding naming: it's better to keep the "software name" of our packages to strongly match up with what the software is normally known as; otherwise, it wont generate search engine hits properly. From maciej at opencsw.org Thu Nov 18 00:10:41 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 17 Nov 2010 23:10:41 +0000 Subject: [csw-maintainers] [csw-users] important change: length of software names In-Reply-To: <AANLkTinJMjjGDvc_DOcHzTansh=qkE_0Z5bms1SLrh5T@mail.gmail.com> References: <AANLkTi=+HqXBP_4Jxe8u-ze_-J7XFzU-34qPt1+LMFfD@mail.gmail.com> <9EAC9604-37ED-471E-A602-97380AAADD6C@opencsw.org> <AANLkTimAkbapPb8kmZVj8tzMXmcY8U45HjcksjEV9G5W@mail.gmail.com> <AANLkTimQ3YXSdNr1Ka1Tg3KQQ-OxyrEHCHtva7nAXXcp@mail.gmail.com> <AANLkTinJMjjGDvc_DOcHzTansh=qkE_0Z5bms1SLrh5T@mail.gmail.com> Message-ID: <AANLkTimpYY_GgbmpB9RrJtS_k3u2non8xb_mqeBQ1x8b@mail.gmail.com> No dia 16 de Novembro de 2010 18:52, Philip Brown <phil at bolthole.com> escreveu: > On 11/16/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: >> No dia 16 de Novembro de 2010 18:11, Philip Brown <phil at bolthole.com> >> escreveu: >>> On 11/15/10, Dagobert Michelsen <dam at opencsw.org> wrote: >>>> Hi, >>>> >>>> Ok, two weeks from the inital post, only positive feedback from >>>> maintainers, >>>> none from users. Is this settled to 32 characters, than? >>>>... >>> >>> FYI, this is now done. >> >> Not quite done yet; checkpkg hasn't been updated[1]. ?Why didn't you >> talk to me to coordinate this? >> > > Since people had recently already submitted packages longer than 20 > chars, I thought there was no need for further coordination :-} I think the package length errors were overriden. By the way, do you usually look inside the override files in packages? From maciej at opencsw.org Thu Nov 18 00:12:33 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 17 Nov 2010 23:12:33 +0000 Subject: [csw-maintainers] [csw-users] important change: length of software names In-Reply-To: <AANLkTimAkbapPb8kmZVj8tzMXmcY8U45HjcksjEV9G5W@mail.gmail.com> References: <AANLkTi=+HqXBP_4Jxe8u-ze_-J7XFzU-34qPt1+LMFfD@mail.gmail.com> <9EAC9604-37ED-471E-A602-97380AAADD6C@opencsw.org> <AANLkTimAkbapPb8kmZVj8tzMXmcY8U45HjcksjEV9G5W@mail.gmail.com> Message-ID: <AANLkTinfbJ1oHRP6ApC2=cFQh2Lq280R_QDhkmUMvWY5@mail.gmail.com> No dia 16 de Novembro de 2010 18:11, Philip Brown <phil at bolthole.com> escreveu: > On 11/15/10, Dagobert Michelsen <dam at opencsw.org> wrote: >> Hi, >> >> Ok, two weeks from the inital post, only positive feedback from maintainers, >> none from users. Is this settled to 32 characters, than? >>... > > FYI, this is now done. Database tables are modified, and my > registration checks updated. > > Reminder: PKG length = 32, softwarename=29 > Packages within those lengths can now be accepted. > > I also updated svn for CSWcswutils, for the next time Ben feels like > updating the package. I've committed r11645, which bumps up package name lengths up in checkpkg. http://sourceforge.net/apps/trac/gar/changeset/11645 From maciej at opencsw.org Thu Nov 18 00:17:57 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 17 Nov 2010 23:17:57 +0000 Subject: [csw-maintainers] [csw-users] important change: length of software names In-Reply-To: <AANLkTinJMjjGDvc_DOcHzTansh=qkE_0Z5bms1SLrh5T@mail.gmail.com> References: <AANLkTi=+HqXBP_4Jxe8u-ze_-J7XFzU-34qPt1+LMFfD@mail.gmail.com> <9EAC9604-37ED-471E-A602-97380AAADD6C@opencsw.org> <AANLkTimAkbapPb8kmZVj8tzMXmcY8U45HjcksjEV9G5W@mail.gmail.com> <AANLkTimQ3YXSdNr1Ka1Tg3KQQ-OxyrEHCHtva7nAXXcp@mail.gmail.com> <AANLkTinJMjjGDvc_DOcHzTansh=qkE_0Z5bms1SLrh5T@mail.gmail.com> Message-ID: <AANLkTikskGTCmJWsC=QWZ6Do5T_CddqH2MRzAxRzaimU@mail.gmail.com> No dia 16 de Novembro de 2010 18:52, Philip Brown <phil at bolthole.com> escreveu: > Since people had recently already submitted packages longer than 20 > chars, I thought there was no need for further coordination :-} Can we coordinate these kinds of changes in the future? From maciej at opencsw.org Thu Nov 18 12:01:35 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 18 Nov 2010 11:01:35 +0000 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user Message-ID: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> No dia 16 de Novembro de 2010 21:18, Philip Brown <phil at bolthole.com> escreveu: > On 11/16/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: >> No dia 16 de Novembro de 2010 17:00, Philip Brown <phil at bolthole.com> >> escreveu: >> >> How does the release manager know what's the best for the user? ?It's >> not a rhetorical question. ?I'm interested to know in the process. > > Maciej, we've been round this particular discussion at least 3 times > before :-/ Previously, you have been asking with an eye to "well, tell > me the process, and then we'll automate it". > To which the reply has been, is, and always will be, "you cant > automate EVERYTHING. Certainly, the things that can be, we should. But > there are things that cannot be". > > If you are NOT asking in that "Give me machine readable procedure" > context, but truly out of inquiry, then I will attempt to give you a > good faith answer. > (It's a pain in the butt. I WISH it could be more automated :) Your > extra gar-checkpkg stuff has helped, which is nice) Yes, this question it's not about automation. > My registration script gives me a quick overview of what files are in > the package, what dependancies it has, and what shared libs it uses. > (maybe one or two other things i forget). > For trivial packages, I usually just "wave them through". > ?** > For new maintainers, I try to spend a bit more time digging. > For new packages, I try to spend a bit more time digging. > For packages that have changed (names, etc) I try to spend a bit more > time digging. > If I notice some odd pathnames, I query the maintainer. > If I notice some odd/obsolete/non-optimal dependancies, I query the maintainer > For packages that have not been updated in a very long time, I try to > spend a bit more time digging. > > Some types of package I tend to wave through, UNLESS they have > obnoxious names or other blatant oddities. > eg: perl, ruby, and python packages. > If someone wanted to actually spend TIME being a (perl/ruby/python) > release manager, I would welcome the extra scrutiny. I myself am not > qualified to deeply examine them, so I usually just pass them through, > with the exception of the libpython, and "where do the scripts live" > issues, which I attempt to keep consistent for the good of all. > > Some things that will be viewed as inconsistent: > I have limited time. I'm not paid for this. So, sometimes, things get > delayed, when I think, "this one should probably be looked at more, > but I dont have time right now". > And sometimes, I wave them through because they've waited long enough, > and I just hope to look at them more 'next time around'. > Or, "the maintainer has already done 10 of this type, I'm sure this > one is the same" > > And sometimes, I was simply not aware of a problem the first time(or > 2nd or 3rd) a package > goes through. But after seeing similar issues with other packages, I > will then hold up something to bug a maintainer, for an issue which > they previously thought was okay. > Sometimes, a particular thing does not seem like an issue to me at > first. but then when I notice 3 or 4 packages going through the same > way, my mind may notice something and say "Hey wait a minute!" and bug > that maintainer. > Nothing against that maintainer personally... its just at that point > that my eyes happen to notice something in the file listings scrolling > by, or whatever. Thanks for the writeup, I've added a summary of that to our wiki: http://wiki.opencsw.org/release-process For the sake of next generations! (Someone will see it and say "this is wrong/bad/incomplete!" and improve it.) >> I guess there's also the question of the reasons for rejecting a >> package. ?The release manager, despite having more power, can't reject >> a package because, let's say, he doesn't like the maintainer. ?There >> has to be a valid reason. ?I hope you agree. > > Of course. > ?I can say with all honesty that I have *never* rejected a package > because I "dont like" someone. ?Some people may claim that I have... > but its important to note that they usually make this claim, instead > of doing work to alter what I'm complaining about. If they had just > done the work, they would have seen the package go through. > > Bad feeling may build up, when a maintainer goes through multiple > times of rebuilding a package, but it's nothing about the maintainer > personally. Its just that when I reach a problem, I say "fix this > please", without looking further. > Once they fix the problem, then I continue looking through it. > > > What is unfortunate for positive feeling, is that I do usually look > harder at a package that has had a problem already. NOT because I > "dislike the maintainer", but because it is very often the case, that > when a package has one problem, it usually has more. So when I hit a > problem with a package, I do look even harder once I get a repackage > of it. > Not because I dislike the maintainer, but because I want our packages > to be as clean for our users as possible. So where there are likely > more problems, I look for more problems. > I havent kept records, but it does seem like packages more often have > 2+ problems, than just 1. > > and if you're wondering how I judge "problem", I go by our "core value": > 'to provide a straightforward, easy-to-use experience for the user' > The tricky bit is in balancing the needs from all of our different > types of user: home, corporate, smallscale, and large scale. It > requires a lot of human judgement. For which, I use my 7 years > experience as a release manager, and 20 years experience as a > sysadmin. I think your contributions to the project in terms of examining packages and discovering issues, are really valuable. I admire your patience and insight. However, the 20 years experience argument leaves me unimpressed. I've seen people with 15 or 20 years experience, who, when asked to write a shell script, write something that doesn't work, and asked about the big-O notation of the complexity of the script, can't work out the answer. At the same time, the 20-years experience people are those who learned to put up with crap around them, and would rather continue to do that, instead of introducing change. It's the fresh people who notice crap and have the energy to improve. So, if you want to reason from experience, it works against you as well, experience makes you also ill-equipped for making decisions. What I asked in the original question, was _how_ do you know what's best for the user. You've described the fact gathering part (package examination). I'm interested in the process that happens afterwards. I guess have some sort of a mental model of the OpenCSW-related part of the world. Then you have our core principle of providing straightforward experience to our users, and you somehow match the two. I'm interested in what does the model consist of, and what the evaluation process looks like. You need to operate using incomplete and imperfect information, so you need to use heuristics, or skip evaluating some parts of the model. I'm interested in what does this model comprise of, and what does the process of evaluation look like. -- Maciej 95e7d4ae28961661d8b34c6399e4b6c4 From maciej at opencsw.org Thu Nov 18 12:11:56 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 18 Nov 2010 11:11:56 +0000 Subject: [csw-maintainers] Friction induced by our package release model Message-ID: <AANLkTikGhTHz6TuueLAo-+PMEUEPaBK_mUQAbMLfYxr9@mail.gmail.com> I've seen that it quite often happens that a package or a set of packages is being worked for quite a long time with no review from the release manager. If there is a number of maintainers involved, they usually discuss, and achieve consensus about each issue. When it's all done, packages are submitted for release, and - like a lightning out of a clear sky - the release manager says "no", and nobody understands why. It's a rare case that the raised objections are clear problems with a package, such as a missing dependency. They are usually matters subject to opinion, aesthetic or otherwise. Consensus driven communities work these things out, and once consensus is achieved, they don't come back to the same discussion right away. If there's a person who picks up a topic again and tries to undermine the consensus without a good reason, the person is likely viewed as poisonous. As it happens, our workflow leads to exactly this. Release manager doesn't look at packages until they are submitted, and they are submitted after a consensus between maintainers is reached. If the release manager objects, he's up against an already established consensus. It's not that the objections raised are unreasonable - they might be well reasonable. The problem is that they are raised at a wrong time. Have other people noticed this? Do you think it could at least partly explain the excessive amount of friction in our community? From ihsan at opencsw.org Thu Nov 18 13:01:36 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Thu, 18 Nov 2010 13:01:36 +0100 Subject: [csw-maintainers] Positioning our website In-Reply-To: <AANLkTi=-E89BOEdLv0WhWxbBT4zMzLPFDh3POUpWqvjc@mail.gmail.com> References: <AANLkTi=-E89BOEdLv0WhWxbBT4zMzLPFDh3POUpWqvjc@mail.gmail.com> Message-ID: <4CE515A0.5010100@opencsw.org> On 11/13/10 04:01 PM, Maciej (Matchek) Blizinski wrote: > Domain ID:D153552903-LROR > Domain Name:OPENCSW.ORG > Created On:08-Aug-2008 08:29:30 UTC > Last Updated On:14-Sep-2010 20:19:19 UTC > Expiration Date:08-Aug-2011 08:29:30 UTC > > I'm not sure what the "Last updated" field means here, whether it was > the renewal date or an unrelated metadata update. In either case, I > believe that extending our registration to 2 or 3 years into the > future would give us a huge boost. Google considers domains that are > registered for a short duration less trustworthy and demotes them in > search results. Extending the registration can be a really quick fix > for our positioning. Dago, can you take care of that? Last Updated shows the date, when the last change on this domain was done. On 14th September we have added ns3.opencsw.org as a third DNS server. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Thu Nov 18 13:37:05 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 18 Nov 2010 13:37:05 +0100 Subject: [csw-maintainers] http://www.opencsw.org/packages/<pkg>: Add GAR build recipe URL to package page? In-Reply-To: <AANLkTin8v3M2TTk+nSktqCSSc5T4sO6bEch5ZHvjHA3z@mail.gmail.com> References: <AANLkTinDZMHfx3gf=unSnYWPhpPGzcM4ppmg3pfeYntu@mail.gmail.com> <AANLkTi=oCjs+VqVvr8iAkApYAcXpDurhSmE+heEv79e=@mail.gmail.com> <AANLkTim1d82p_u9+YpT877jQRpb0dz4HqzFTVs+zHi1M@mail.gmail.com> <AANLkTi=CfQpjWCn4R72QzX=6nKZkf3OKDrc_tjBAvYFe@mail.gmail.com> <AANLkTikFLm7HBncpo4tqCB0aD+0NKC8f07wZ3jopA7ys@mail.gmail.com> <20101105162742.GA15588@sebastiankayser.de> <AANLkTi=qiP57EoqARAaCK=nPgxw+U2B=-fWvx3KKs7V=@mail.gmail.com> <4CDB292D.3090108@opencsw.org> <AANLkTikYhpD4mZ0-Xx9jMRYZzzOBaY65S0jqHY0OwoYi@mail.gmail.com> <EDB0F459-82F6-42E8-9E39-44141E84EE57@opencsw.org> <20101111171050.GP28050@sebastiankayser.de> <AANLkTimW2xVb=nwQuqKi7G1Qgb21GRttoZ7JOJGPboGT@mail.gmail.com> <1289672497-sup-4152@pinkfloyd.chass.utoronto.ca> <AANLkTik0iWrkpeu+N3_V8jeHZfActj9K3Pha2PqxbP7T@mail.gmail.com> <1F550B4F-E5CA-405C-A6ED-52AB09EA3023@opencsw.org> <AANLkTi=k8PeoCr_v28FPiVnruxu2hWoVPU0ZYw2hXO5K@mail.gmail.com> <1290006319-sup-2226@pinkfloyd.chass.utoronto.ca> <27547BE1-D407-4F76-B2DA-B97E5C225F89@opencsw.org> <AANLkTin8v3M2TTk+nSktqCSSc5T4sO6bEch5ZHvjHA3z@mail.gmail.com> Message-ID: <9728F38B-0325-480E-A849-80A0C2C077F0@opencsw.org> Hi Phil, Am 17.11.2010 um 18:49 schrieb Philip Brown: > On 11/17/10, Dagobert Michelsen <dam at opencsw.org> wrote: >> Hi, >> >> Am 17.11.2010 um 16:06 schrieb Ben Walton: >>> Excerpts from Philip Brown's message of Tue Nov 16 13:19:04 -0500 >>> 2010: >>>> csw/mgar/pkg/apache2/trunk at 11200 >>>> >>>> "csw/mgar/pkg" is also pretty much redundant. Shouldnt we strip >>>> that >>>> out also, and just save stuff under "pkg" ? >>> > ... >> I disagree. The path within the repository (with SVNROOT stripped) >> describes exactly the location of the build description. Why >> introduce artificial special cases? If the repository is >> reorganized in some distant future all existing links will be >> invalid are would need special treatment while retaining the full >> path with revision will always link directly to the build recipe. > > I was thinking that stripping things out, should actually make things > MORE portable, in the event of a reorganization. > > Take a starting point of $SVNROOT/csw/mgar/pkg/softname > > Then lets say it gets reorganized. > There are two ways it might get reorganized, that I can see: > a) some way that is completely incompatible, ie: > $SVNROOT/csw/mgar/pkg/random/stuff/here/softname > b) some way that is auto-correctible. Example > > $SVNROOT/something/else/pkg/softname. > > I was thinking that we are most likely to keep "pkg/softname". > > > In which case, the web page would need only one consistent change to > redirect people from > the "old location", to the "new, up to date location". > > I guess it depends what your goals are. There would seem to be two, > mutually conflicting goals: > > 1. Make it so packages already registered, do not have to be > REregistered with new src locations, if we reorganize SVN > (assumption: if we reorganize, we will do a clean, transparent > migration of EVERYTHING, rather than onsey-twosy migrate) > > 2. Make it so packages keep the old legacy pathnames. So even if we > reorganize, old packages keep pointing to old locations. > > I THINK Dago is aiming for #2. Whereas it seems to me that #1 is > better. Correct. The link should go to the specific revision in the repository the package was built from. The reasoning is that releasable packages should be build by an automatic build system in the future triggered by copying trunk to a specific directory for releasable packages which path will then go into the package. The path will be different than the one leading to the most current build recipep For the most up to date link the field can just be freely editable, inference from a package field may or may not be correct. It should be set manually by the package maintainer and may be preset to trunk. Best regards -- Dago From maciej at opencsw.org Thu Nov 18 13:42:19 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 18 Nov 2010 12:42:19 +0000 Subject: [csw-maintainers] Policies and special cases Message-ID: <AANLkTin0WvoFBLyiSirtjXuyid2goezSqnbvF4VVu-KW@mail.gmail.com> No dia 16 de Novembro de 2010 21:18, Philip Brown <phil at bolthole.com> escreveu: > On 11/16/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: >> No dia 16 de Novembro de 2010 17:00, Philip Brown <phil at bolthole.com> >> escreveu: >> >> How does the release manager know what's the best for the user? ?It's >> not a rhetorical question. ?I'm interested to know in the process. > > Maciej, we've been round this particular discussion at least 3 times > before :-/ Previously, you have been asking with an eye to "well, tell > me the process, and then we'll automate it". > To which the reply has been, is, and always will be, "you cant > automate EVERYTHING. Certainly, the things that can be, we should. But > there are things that cannot be". I've never said that everything can, or should be automated. There are even things that should not be automated, even though they can, I can grant you that. I think this particular discussion that we had 3 times before, was not about automation. It's about policies. You seem to be resisting policies and policy enforcement. When rejecting packages, you quite often say something that resembles a policy, but when I look at a catalog, it turns out that other packages don't follow what you said. And that's fine - policies are changing, what was fine a week ago might not be fine now. At this point I'd expect you to say: "Yes, there are packages that don't follow that policy, they would best be fixed." But you don't say that. Instead, you say "It's not a policy really, it's a case by case thing". This way, you basically reserve the right to say whatever you please on any package you please and always claim it's a case by case basis. When submitting a package, a maintainer can never tell whether a package will or will not be accepted. I would expect that if there's a well understood aspect of packaging, the policy should be clear and the same for all packages. If the aspect is complex, the policy can be complex too, this is fine. But complex does not mean case by case. I'm not saying that you can put rules on absolutely everything. But I'm saying that if there is some kind of reasoning that suggests a particular solution, the same reasoning applies to other packages too, and is worth documenting. If it's not worth documenting and applying across the catalog (to the packages it applies to), perhaps it just doesn't matter that much, and therefore my package can be safely included in the catalog. Each well understood aspect of packaging should have related policy. I expect that if I submit a package that conforms to the policy, it gets accepted. In the unlikely event that my package gets rejected, I expect a change to the policy, or a new policy put in place -- and from now on all packages have to follow that policy too. I don't want my packages to be at the mercy of a single person who can make stuff up as they go along. Is that reasonable? From maciej at opencsw.org Thu Nov 18 16:31:16 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 18 Nov 2010 15:31:16 +0000 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> Message-ID: <AANLkTinumvsFih1yERKyFJytLOc2zJBb4QL4vRdz7K27@mail.gmail.com> No dia 16 de Novembro de 2010 00:20, Philip Brown <phil at bolthole.com> escreveu: > This is starting off a fresh thread, on the proposal being suggested > around naming of packages, that have shared libraries in them. > > Maciej was kind enough to write up a web page for it, here: > > http://wiki.opencsw.org/packaging-shared-libraries > > I have made some very minor updates to it, and corrected the naming > length "32" to "29" . > > I then added some areas of concern that I have, to the bottom of the page. > > I was originally going to quote them here, but they have become rather long :-/ > So perhaps they are better read in the full context of the wiki page, above. > > > I will also mention, given that Maciej gave the debian sharedlibs > policy (section 8.1) as a reference, if we abided by the WHOLE text of > that section. Again, my further notes on that, are at the bottom of > the wiki page. > > > General comment I did not add into the wiki: I do not see having "more > packages" as a good in and of itself (and neither does Debian, as I > reference in the page). It can be viewed as both good and bad, depending on the context. We can remove this point if you wish. > If upgrading "libcups" -- what was previously a single package -- now > takes downloading and cycling through (pkgrm, pkgadd) **6** times... I > dont think this looks good to our users. Granted that 6 packages will take slightly longer to install, I don't see why is that a problem. > What to do when a software package has its common name as "libxyz", and then also contains a "libxyz.so.#" ? You'd follow the recommendation and have CSWlibxyz# with the library, CSWlibxyz-devel with headers and the .so file, and if there's anything left, CSWlibxyz-doc, etc. > People will usually expect to find the package by simple name. Do we provide a ghost "libxyz" package that depends on the longer named one? Or expect that our users will educate themselves (usually a losing proposition) They will probably do something like "pkgutil -a libxyz" and find out the package names. > What to do when a software package is primarily a library, but is more commonly known by a shorter name? EG: "ldns", which technically is short for "libdns", and mostly just provides a "libdns", but its software name is specifically "ldns" NOT "libldns". :: http://www.nlnetlabs.nl/projects/ldns/ Follow the recommendation: CSWldns-devel with the header files CSWlibldns1 with /opt/csw/lib/libldns.so.1 CSWldns(-.*)? if there's anything left (docs, tools, etc) > Is it really neccessary to add a "1" to well-known libraries, that have a very small likelyhood of changing, and so do not present an issue to the stated goals? ie: "libldns" -> "libldns1" :: is that really neccessary or even useful? Everything will end some day, and so will libldns.so.1. When that happens, future maintainers will be grateful that we've made it easier for them to phase it out. While it's not strictly necessary to add the "1", I see no reason to object to that if a maintainer thinks it's a good idea. > What about when the software is actually known as "libFoo", and is at version X, but the shared lib of the same name, is at version Y? This would lead to grossness such as "libcups2-1.4.4". It is version2, but it is version 1.4.4? This is confusing to a user, who at first glance (being used to our release of things like "mysql4" vs "mysql5" packages, may think, "oh, there's a version 2 of libcups" when there is not. Perhaps the foo.so.N+1 is an unfortunate case when the major software version is N. If you saw, say, libcups3, you wouldn't think it's the version 3 of cups as there's no version 2 of cups yet. While this could in fact be somewhat confusing to a user, I think it's very unlikely that it would. The libcups2 package is only a shared library, and will probably never be installed by itself. The typical two cases are installing cups itself, or installing cupsdevel to compile other software with cups support. As Sebastian has said before, it's unlikely any user would care about lib packages. To answer the main question about libFoo at version X with library at version Y -- the answer is that you follow the recommendation. Assuming you care about capitalization: CSWlibFoo contains everything minus devel, minus shared libs, etc, potentially unnecessary CSWlibFoo-devel with headers CSWlibfooY with the shared library (library package names are normalized with lowercase) > In these cases, perhaps it is better to encode the SONAME version information somewhere other than immediately after the softwarename. Perhaps libcups-1.4.4_so2,REV=2010.xx.xx? similarly, libcupsimage-1.4.4_so2,REV=2010.xx.xx? libcupsimage-1.4.4,so=2,REV=2010.xx.xx > Hmm. except that would not allow for specific version-based dependencies. So libcupsimage_so2-1.4.4, libcups_so2-1.4.4 ? We try to keep package names short, and the "_so" bit would be repetitive and not very helpful in most cases, but it's a possibility. WRT grouping libraries - yes, you are right that what matters here is whether libraries change together. Matching library versions is only a heuristic. We can emphasize this in the document if you want to. We can also replace this heuristic with something else, but we need a way to decide, given a set of sonames, whether they belong together or not. As Debian policy points out, it's always safe to split libraries to separate packages, and I think it's reasonable to nudge the maintainer about non-version-matching sonames in one package. I'm not pushing towards this being a policy; it can remain a best practices recommendation. I wouldn't mind it becoming the policy, but I understand that there is already a large number of packages, and not everybody will be happy to rework all their packages. What I would like to achieve is that if a maintainer submits a package following this recommendation, the package is not rejected on the grounds of doing so. What do you intend to do with your comments in on the wiki page? I guess we want to arrive at a clean version of the document that can eventually become our recommendation. From phil at bolthole.com Thu Nov 18 18:09:48 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 18 Nov 2010 09:09:48 -0800 Subject: [csw-maintainers] [csw-users] important change: length of software names In-Reply-To: <AANLkTikskGTCmJWsC=QWZ6Do5T_CddqH2MRzAxRzaimU@mail.gmail.com> References: <AANLkTi=+HqXBP_4Jxe8u-ze_-J7XFzU-34qPt1+LMFfD@mail.gmail.com> <9EAC9604-37ED-471E-A602-97380AAADD6C@opencsw.org> <AANLkTimAkbapPb8kmZVj8tzMXmcY8U45HjcksjEV9G5W@mail.gmail.com> <AANLkTimQ3YXSdNr1Ka1Tg3KQQ-OxyrEHCHtva7nAXXcp@mail.gmail.com> <AANLkTinJMjjGDvc_DOcHzTansh=qkE_0Z5bms1SLrh5T@mail.gmail.com> <AANLkTikskGTCmJWsC=QWZ6Do5T_CddqH2MRzAxRzaimU@mail.gmail.com> Message-ID: <AANLkTikON6shusp8OcCcqPy16=5MXju_fChhnQNkyj+U@mail.gmail.com> On 11/17/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: > No dia 16 de Novembro de 2010 18:52, Philip Brown <phil at bolthole.com> > escreveu: >> Since people had recently already submitted packages longer than 20 >> chars, I thought there was no need for further coordination :-} > > Can we coordinate these kinds of changes in the future? > I'm usually all about coordination :) So sure thing. I'm just not sure what you think we missed out on, with this particular case. You couldnt make the change on 'your end', until the database and my registration scripts were changed. But i'm not sure what the problem is in the other direction. I dont see what we "lost", if the gar-side changes were made a week after the database change, as compared to the same day. From phil at bolthole.com Thu Nov 18 18:20:12 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 18 Nov 2010 09:20:12 -0800 Subject: [csw-maintainers] Policies and special cases In-Reply-To: <AANLkTin0WvoFBLyiSirtjXuyid2goezSqnbvF4VVu-KW@mail.gmail.com> References: <AANLkTin0WvoFBLyiSirtjXuyid2goezSqnbvF4VVu-KW@mail.gmail.com> Message-ID: <AANLkTin+2ysY9+xgCfw7mhWz2bsnAGCgaeQis1Y-51HQ@mail.gmail.com> On 11/18/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: > No dia 16 de Novembro de 2010 21:18, Philip Brown <phil at bolthole.com> > escreveu: >> .. >.... When > rejecting packages, you quite often say something that resembles a > policy, but when I look at a catalog, it turns out that other packages > don't follow what you said. And that's fine - policies are changing, > what was fine a week ago might not be fine now. At this point I'd > expect you to say: "Yes, there are packages that don't follow that > policy, they would best be fixed." But you don't say that. Instead, > you say "It's not a policy really, it's a case by case thing". Hey now, be fair: sometimes I say the first thing :) But yes, other times I say "case by case" > This way, you basically reserve the right to say whatever you please > on any package you please and always claim it's a case by case basis. > When submitting a package, a maintainer can never tell whether a > package will or will not be accepted. I would expect that if there's > a well understood aspect of packaging, the policy should be clear and > the same for all packages. If the aspect is complex, the policy can > be complex too, this is fine. But complex does not mean case by case. I *have* attempted to improve the 'detail' of these descriptions of policy this year. I think the other problem we run into, is that our 'policy-related' documents are getting larger, and more spread out, so no-one really reads all of them. Or forgets them. OR, heck, I forget sometimes that what I'm describing, has already been written up on some page last updated 3 years ago :) > I'm not saying that you can put rules on absolutely everything. But > I'm saying that if there is some kind of reasoning that suggests a > particular solution, the same reasoning applies to other packages too, > and is worth documenting. If it's not worth documenting and applying > across the catalog (to the packages it applies to), perhaps it just > doesn't matter that much, and therefore my package can be safely > included in the catalog. There really are things that are "specific to the package/software". The big, obvious example, is "where to put config files.", and the case-by-case factor of, "does this software most often get deployed with a global config, or with a machine-local config?" This is a completely non-automatable, case-by-case scenario. Usually, the maintainer is the best source for this, and I try to respect. Sometimes, though, there is a conflict between the maintainer saying, "well, *I* usually deploy it this way", vs what the community at large most commonly expects. The release manager needs to be mindful of that potential conflict. > Each well understood aspect of packaging should have related policy. > I expect that if I submit a package that conforms to the policy, it > gets accepted. In the unlikely event that my package gets rejected, I > expect a change to the policy, or a new policy put in place -- and > from now on all packages have to follow that policy too. I completely understand a maintainer's desire to understand where a package is going to fall, before they put the work into it. This touches on another email you already posted, where there's a "problem" with the release manager getting notified only at the very end of the package creation process, vs the beginning. It's always nice to see someone ask me, or the maintainers list in general, packaging design questions up front, vs arguing after the fact. > I don't want > my packages to be at the mercy of a single person who can make stuff > up as they go along. Is that reasonable? There's a difference between "making stuff up as they go along", vs "judgement call". I'll respond more about the basis for my judgement, in another email, since you already raised that topic elsewhere. From pfelecan at opencsw.org Thu Nov 18 18:26:00 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 18 Nov 2010 18:26:00 +0100 Subject: [csw-maintainers] Friction induced by our package release model In-Reply-To: <AANLkTikGhTHz6TuueLAo-+PMEUEPaBK_mUQAbMLfYxr9@mail.gmail.com> (Maciej Blizinski's message of "Thu, 18 Nov 2010 11:11:56 +0000") References: <AANLkTikGhTHz6TuueLAo-+PMEUEPaBK_mUQAbMLfYxr9@mail.gmail.com> Message-ID: <x6pqu27dcn.fsf@opencsw.org> "Maciej (Matchek) Blizinski" <maciej at opencsw.org> writes: > Have other people noticed this? Do you think it could at least partly > explain the excessive amount of friction in our community? yes & yes. I raised this issue some days ago but there was no answer. Given that the release model is sometimes discretionary I proposed to remove the release manager per see and replace-it with verification and validation tools. The maintainer is the release manager for his packages he's the release manager! -- Peter From pfelecan at opencsw.org Thu Nov 18 18:37:43 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 18 Nov 2010 18:37:43 +0100 Subject: [csw-maintainers] Policies and special cases In-Reply-To: <AANLkTin0WvoFBLyiSirtjXuyid2goezSqnbvF4VVu-KW@mail.gmail.com> (Maciej Blizinski's message of "Thu, 18 Nov 2010 12:42:19 +0000") References: <AANLkTin0WvoFBLyiSirtjXuyid2goezSqnbvF4VVu-KW@mail.gmail.com> Message-ID: <x6lj4q7ct4.fsf@opencsw.org> "Maciej (Matchek) Blizinski" <maciej at opencsw.org> writes: > No dia 16 de Novembro de 2010 21:18, Philip Brown <phil at bolthole.com> escreveu: >> On 11/16/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: >>> No dia 16 de Novembro de 2010 17:00, Philip Brown <phil at bolthole.com> >>> escreveu: >>> >>> How does the release manager know what's the best for the user? ?It's >>> not a rhetorical question. ?I'm interested to know in the process. >> >> Maciej, we've been round this particular discussion at least 3 times >> before :-/ Previously, you have been asking with an eye to "well, tell >> me the process, and then we'll automate it". >> To which the reply has been, is, and always will be, "you cant >> automate EVERYTHING. Certainly, the things that can be, we should. But >> there are things that cannot be". > [...] > This way, you basically reserve the right to say whatever you please > on any package you please and always claim it's a case by case basis. This is the exact definition of the term "discretionary" > [...] I don't want > my packages to be at the mercy of a single person who can make stuff > up as they go along. Is that reasonable? Again: the maintainer is the release manager and tools verify and validate predefined policies. Dominique Laigle made up a nice process diagram about what we agreed at the summer summit (sorry again). -- Peter From phil at bolthole.com Thu Nov 18 19:07:04 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 18 Nov 2010 10:07:04 -0800 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> Message-ID: <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> On 11/18/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: > No dia 16 de Novembro de 2010 21:18, Philip Brown <phil at bolthole.com> > escreveu: > > I think your contributions to the project in terms of examining > packages and discovering issues, are really valuable. I admire your > patience and insight. > > However, the 20 years experience argument leaves me unimpressed. I've > seen people with 15 or 20 years experience, who, when asked to write a > shell script, write something that doesn't work, and asked about the > big-O notation of the complexity of the script, can't work out the > answer. I know what you mean. i've seen people like that. :-} usually been at the same low-level job for those 20 years. So let me share more detail of my experience, and how that benefits my position of release manager. In my 20 years sysadmin experience, I have worked in almost every segment of the IT industry. I have worked for 2 fortune-500 companies. I have worked for 3 'higher education' institutions. I have also worked for a silicon valley startup company. I have worked at places where the release process was "Go for it!". I have also worked at places where you were expected to file a full change management document, a week in advance, for any changes. I have worked in places where there were only 10 machines to deal with. I have worked in places where there are hundreds of machines to deal with. I have worked to support machines where the attitude was "eh, its okay to be down for a while". I have worked to support machines where the importance was, "If you screw things up, you'd better clear out your desk, because the company just lost $1million or more". I have also supported a wide variety of users. From the highly knowlegeable set, to the "Where's the 'any' key?" set And on a general computing competency note: I have a degree in computer science, and have had assorted chunks of code accepted into solaris... BEFORE the whole opensolaris source tree type access was started. So, there's where my judgement for package quality comes from :) > At the same time, the 20-years experience people are those who learned > to put up with crap around them, and would rather continue to do that, > instead of introducing change. It's the fresh people who notice crap > and have the energy to improve. So, if you want to reason from > experience, it works against you as well, experience makes you also > ill-equipped for making decisions. Erm... I think that a fair evaluation of my track record, shows that I am highly in favor of change: just so long as it is positive, well planed, and well managed change. *cough* I did bring network-enabled automated package installation to solaris, after all. Plus suggested the CAS framework. and worked on *some* of them,but then mostly stood back and encouraged other people to implement their own. And other things I'm probably forgetting. Summary: "change for change's sake=bad. researched and planned change = good" Most recent example: the pkg namelength change. I didnt block it just to block change. I wanted to make sure it was fully researched and thought out. And good thing I did, otherwise we'd have a 'new standard' that violated solaris capabilities, hmmm? > What I asked in the original question, was _how_ do you know what's > best for the user. I take my experience I mentioned above, and try to figure out how the package would best meet the needs of ALL the different types of environment and users if possible. If there's a fundamental conflict between "please these folks, or that folks", things get complicated. On the one hand, it may make no sense to deploy an application in one setting, so I ignore that segment if need be. But usually, I keep an eye more tuned to the "large, corporate style" usage cases. The reasons being: - Most people who work with "open source", have no idea of (nor do they even care to think about) impact to large scale deployments. Someone needs to plan it. - (From the user's perspective) It is easier to take clean methodology brought on by corporate deployment styles, and then deploy for a single user... then it is to take a lazy "it works good enough for me" single user oriented package, and then attempt to shoe-horn it into a large scale deployment. Most corporate folks who hit the latter style, will just say to themselves, "okay these guys are clueless/have no idea what they are doing... we cant trust them to provide packages for our needs", and give up on opencsw for any purpose whatsoever (whereas an individual user may not like one particular package, but use the rest of them) That is why I push particularly hard for large-scale-friendly packages. We cant grow OpenCSW to full potential, if we dont meet the needs of the large scale deployments well. Not only is this important as a general customer principle, but it also affects your interest in web search placement. "corporate worthy" sites, tend to get higher ranking. No corporate buy-in, means we lose writeups, and references. Which means we will be lower in search engine ranking than otherwise. From phil at bolthole.com Thu Nov 18 20:45:29 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 18 Nov 2010 11:45:29 -0800 Subject: [csw-maintainers] Final feedback for putting in GAR/repository info into our mysql db Message-ID: <AANLkTimHa35+QjJx0FFmLDjcvfz=pGFdc2h=uSWG-GiB@mail.gmail.com> Sorry for loong quote: wanted to preserve context for others. This was from subject line previously of: "http://www.opencsw.org/packages/<pkg>: Add GAR build recipe URL to package page?" On 11/18/10, Dagobert Michelsen <dam at opencsw.org> wrote: > Hi Phil, *wave* > Am 17.11.2010 um 18:49 schrieb Philip Brown: > >> >> I guess it depends what your goals are. There would seem to be two, >> mutually conflicting goals: [for db registration of OPENCSW_REPOSITORY] >> >> 1. Make it so packages already registered, do not have to be >> REregistered with new src locations, if we reorganize SVN >> (assumption: if we reorganize, we will do a clean, transparent >> migration of EVERYTHING, rather than onsey-twosy migrate) [ http://blahblah/svnroot/gar/csw/mgar/pkg/ruby/trunk at 11004 becomes pkg/ruby/trunk at 11004, or even just ruby/trunk at 11004, in db ] >> >> 2. Make it so packages keep the old legacy pathnames. So even if we >> reorganize, old packages keep pointing to old locations. [ http://blahblah/svnroot/gar/csw/mgar/pkg/ruby/trunk at 11004 becomes gar/csw/mgar/pkg/ruby/trunk at 11004 in db] >> >> I THINK Dago is aiming for #2. Whereas it seems to me that #1 is >> better. > > Correct. The link should go to the specific revision in the repository > the > package was built from. The reasoning is that releasable packages > should be build by an automatic build system in the future triggered > by copying trunk to a specific directory for releasable packages > which path will then go into the package. The path will be > different than the one leading to the most current build recipep > > For the most up to date link the field can just > be freely editable, inference from a package field may or may not be > correct. It should be set manually by the package maintainer and may > be preset to trunk. Okay. Well, I dont feel strongly that there is one particular "right" answer; I think its mostly just "what do people want". Putting this out there, with a clean subject line so people previously ignoring it, might pay attention now :) If there's no other feedback in support of the shorter method, then I guess I'll start working on implementing the longer method come monday (nov 22nd) From phil at bolthole.com Thu Nov 18 20:45:29 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 18 Nov 2010 11:45:29 -0800 Subject: [csw-maintainers] Final feedback for putting in GAR/repository info into our mysql db Message-ID: <AANLkTimHa35+QjJx0FFmLDjcvfz=pGFdc2h=uSWG-GiB@mail.gmail.com> Sorry for loong quote: wanted to preserve context for others. This was from subject line previously of: "http://www.opencsw.org/packages/<pkg>: Add GAR build recipe URL to package page?" On 11/18/10, Dagobert Michelsen <dam at opencsw.org> wrote: > Hi Phil, *wave* > Am 17.11.2010 um 18:49 schrieb Philip Brown: > >> >> I guess it depends what your goals are. There would seem to be two, >> mutually conflicting goals: [for db registration of OPENCSW_REPOSITORY] >> >> 1. Make it so packages already registered, do not have to be >> REregistered with new src locations, if we reorganize SVN >> (assumption: if we reorganize, we will do a clean, transparent >> migration of EVERYTHING, rather than onsey-twosy migrate) [ http://blahblah/svnroot/gar/csw/mgar/pkg/ruby/trunk at 11004 becomes pkg/ruby/trunk at 11004, or even just ruby/trunk at 11004, in db ] >> >> 2. Make it so packages keep the old legacy pathnames. So even if we >> reorganize, old packages keep pointing to old locations. [ http://blahblah/svnroot/gar/csw/mgar/pkg/ruby/trunk at 11004 becomes gar/csw/mgar/pkg/ruby/trunk at 11004 in db] >> >> I THINK Dago is aiming for #2. Whereas it seems to me that #1 is >> better. > > Correct. The link should go to the specific revision in the repository > the > package was built from. The reasoning is that releasable packages > should be build by an automatic build system in the future triggered > by copying trunk to a specific directory for releasable packages > which path will then go into the package. The path will be > different than the one leading to the most current build recipep > > For the most up to date link the field can just > be freely editable, inference from a package field may or may not be > correct. It should be set manually by the package maintainer and may > be preset to trunk. Okay. Well, I dont feel strongly that there is one particular "right" answer; I think its mostly just "what do people want". Putting this out there, with a clean subject line so people previously ignoring it, might pay attention now :) If there's no other feedback in support of the shorter method, then I guess I'll start working on implementing the longer method come monday (nov 22nd) From rupert at opencsw.org Fri Nov 19 07:30:52 2010 From: rupert at opencsw.org (rupert THURNER) Date: Fri, 19 Nov 2010 07:30:52 +0100 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> Message-ID: <AANLkTika1M3eiadMRx1mz6h4T7kcx5EnNBMQQoa+Megz@mail.gmail.com> there lies a lot of truth in all these mails. for us the incentive was: 1. simple way to get a 2. stable solaris package which comes from a 3. long time sustaining (most important!) project which has a 4. simple way to create a package which allows an 5. effortless update to a new upstream version because it is early in the morning, allow me to be a little provocative: as so many emails are written, somebody must have some spare time, which is a very good sign for an active voluntary project :) who helps me updating php to a new version, maybe make the package less complex ? rupert. On Thu, Nov 18, 2010 at 19:07, Philip Brown <phil at bolthole.com> wrote: > On 11/18/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: >> No dia 16 de Novembro de 2010 21:18, Philip Brown <phil at bolthole.com> >> escreveu: >> >> I think your contributions to the project in terms of examining >> packages and discovering issues, are really valuable. ?I admire your >> patience and insight. >> >> However, the 20 years experience argument leaves me unimpressed. ?I've >> seen people with 15 or 20 years experience, who, when asked to write a >> shell script, write something that doesn't work, and asked about the >> big-O notation of the complexity of the script, can't work out the >> answer. > > I know what you mean. i've seen people like that. :-} usually been at > the same low-level job for those 20 years. > So let me share more detail of my experience, and how that benefits my > position of release manager. > > In my 20 years sysadmin experience, I have worked in almost every > segment of the IT industry. > I have worked for 2 fortune-500 companies. I have worked for 3 'higher > education' institutions. I have also worked for a silicon valley > startup company. > > I have worked at places where the release process was "Go for it!". I > have also worked at places where you were expected to file a full > change management document, a week in advance, for any changes. > I have worked in places where there were only 10 machines to deal > with. I have worked in places where there are hundreds of machines to > deal with. > I have worked to support machines where the attitude was "eh, its okay > to be down for a while". ?I have worked to support machines where the > importance was, "If you screw things up, you'd better clear out your > desk, because the company just lost $1million or more". > > I have also supported a wide variety of users. From the highly > knowlegeable set, to the "Where's the 'any' key?" set > > And on a general computing competency note: I have a degree in > computer science, and have had assorted chunks of code accepted into > solaris... BEFORE the whole opensolaris source tree type access was > started. > > So, there's where my judgement for package quality comes from :) > > >> At the same time, the 20-years experience people are those who learned >> to put up with crap around them, and would rather continue to do that, >> instead of introducing change. ?It's the fresh people who notice crap >> and have the energy to improve. ?So, if you want to reason from >> experience, it works against you as well, experience makes you also >> ill-equipped for making decisions. > > Erm... I think that a fair evaluation of my track record, shows that I > am highly in favor of change: just so long as it is positive, well > planed, and well managed change. > *cough* I did bring network-enabled automated package installation to > solaris, after all. > Plus suggested the CAS framework. and worked on *some* of them,but > then mostly stood back and encouraged other people to implement their > own. > And other things I'm probably forgetting. > > Summary: "change for change's sake=bad. researched and planned change = good" > Most recent example: the pkg namelength change. I didnt block it just > to block change. I wanted to make sure it was fully researched and > thought out. > And good thing I did, otherwise we'd have a 'new standard' that > violated solaris capabilities, hmmm? > > >> What I asked in the original question, was _how_ do you know what's >> best for the user. > > I take my experience I mentioned above, and try to figure out how the > package would best meet the needs of ALL the different types of > environment and users if possible. > If there's a fundamental conflict between "please these folks, or that > folks", things get complicated. > On the one hand, it may make no sense to deploy an application in one > setting, so I ignore that segment if need be. But usually, I keep an > eye more tuned to the "large, corporate style" usage cases. ?The > reasons being: > > - Most people who work with "open source", have no idea of (nor do > they even care to think about) impact to large scale deployments. > Someone needs to plan it. > - (From the user's perspective) It is easier to take clean methodology > brought on by corporate deployment styles, and then deploy for a > single user... then it is to take a lazy "it works good enough for me" > single user oriented package, and then attempt to shoe-horn it into a > large scale deployment. > Most corporate folks who hit the latter style, will just say to > themselves, "okay these guys are clueless/have no idea what they are > doing... we cant trust them to provide packages for our needs", and > give up on opencsw for any purpose whatsoever > (whereas an individual user may not like one particular package, but > use the rest of them) > That is why I push particularly hard for large-scale-friendly > packages. We cant grow OpenCSW to full potential, if we dont meet the > needs of the large scale deployments well. > > Not only is this important as a general customer principle, but it > also affects your interest in web search placement. ?"corporate > worthy" sites, tend to get higher ranking. > No corporate buy-in, means we lose writeups, and references. Which > means we will be lower in search engine ranking than otherwise. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From dam at opencsw.org Fri Nov 19 10:02:00 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 19 Nov 2010 10:02:00 +0100 Subject: [csw-maintainers] Final feedback for putting in GAR/repository info into our mysql db In-Reply-To: <AANLkTimHa35+QjJx0FFmLDjcvfz=pGFdc2h=uSWG-GiB@mail.gmail.com> References: <AANLkTimHa35+QjJx0FFmLDjcvfz=pGFdc2h=uSWG-GiB@mail.gmail.com> Message-ID: <5CA5AA66-A74A-4FF9-A6CE-F7E7C707027A@opencsw.org> Hi Phil, Am 18.11.2010 um 20:45 schrieb Philip Brown: >> Am 17.11.2010 um 18:49 schrieb Philip Brown: >>> I guess it depends what your goals are. There would seem to be two, >>> mutually conflicting goals: [for db registration of >>> OPENCSW_REPOSITORY] >>> >>> 1. Make it so packages already registered, do not have to be >>> REregistered with new src locations, if we reorganize SVN >>> (assumption: if we reorganize, we will do a clean, transparent >>> migration of EVERYTHING, rather than onsey-twosy migrate) > > [ http://blahblah/svnroot/gar/csw/mgar/pkg/ruby/trunk at 11004 > becomes pkg/ruby/trunk at 11004, or even just ruby/trunk at 11004, in db ] > >>> >>> 2. Make it so packages keep the old legacy pathnames. So even if we >>> reorganize, old packages keep pointing to old locations. > > [ http://blahblah/svnroot/gar/csw/mgar/pkg/ruby/trunk at 11004 > becomes gar/csw/mgar/pkg/ruby/trunk at 11004 in db] Almost... It becomes csw/mgar/pkg/ruby/trunk at 11004 as the repository root is https://gar.svn.sf.net/svnroot/gar. This allows relocation of the repository as a whole if necessary while keeping the complete information to find the package in the repository tree. >>> I THINK Dago is aiming for #2. Whereas it seems to me that #1 is >>> better. >> >> Correct. The link should go to the specific revision in the >> repository >> the >> package was built from. The reasoning is that releasable packages >> should be build by an automatic build system in the future triggered >> by copying trunk to a specific directory for releasable packages >> which path will then go into the package. The path will be >> different than the one leading to the most current build recipep >> >> For the most up to date link the field can just >> be freely editable, inference from a package field may or may not be >> correct. It should be set manually by the package maintainer and may >> be preset to trunk. > > Okay. Well, I dont feel strongly that there is one particular "right" > answer; I think its mostly just "what do people want". Or maybe both. > Putting this out there, with a clean subject line so people previously > ignoring it, might pay attention now :) > If there's no other feedback in support of the shorter method, then I > guess I'll start working on implementing the longer method come monday > (nov 22nd) Great! Best regards -- Dago From pfelecan at opencsw.org Fri Nov 19 10:45:53 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 19 Nov 2010 10:45:53 +0100 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> (Philip Brown's message of "Thu, 18 Nov 2010 10:07:04 -0800") References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> Message-ID: <x67hg97ijy.fsf@opencsw.org> Philip Brown <phil at bolthole.com> writes: > On 11/18/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: >> No dia 16 de Novembro de 2010 21:18, Philip Brown <phil at bolthole.com> >> escreveu: >> >> I think your contributions to the project in terms of examining >> packages and discovering issues, are really valuable. I admire your >> patience and insight. >> >> However, the 20 years experience argument leaves me unimpressed. I've >> seen people with 15 or 20 years experience, who, when asked to write a >> shell script, write something that doesn't work, and asked about the >> big-O notation of the complexity of the script, can't work out the >> answer. > > I know what you mean. i've seen people like that. :-} usually been at > the same low-level job for those 20 years. > So let me share more detail of my experience, and how that benefits my > position of release manager. Well, nobody said that your contribution to the community is not valuable. However, what was said is that your vision is not the only one possibly correct. Without wanting to start a "who's hard disk's bigger" game, there are other experienced people in this community and their vision should matter also. Hence the community concept vs. a sort of autocratic organization. Let that last one for Fortune 500 entities. -- Peter From dam at opencsw.org Fri Nov 19 10:48:13 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 19 Nov 2010 10:48:13 +0100 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTika1M3eiadMRx1mz6h4T7kcx5EnNBMQQoa+Megz@mail.gmail.com> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <AANLkTika1M3eiadMRx1mz6h4T7kcx5EnNBMQQoa+Megz@mail.gmail.com> Message-ID: <0FCAB3BF-E0DE-40EF-B8AA-593FEE050B95@opencsw.org> Hi Rupert, Am 19.11.2010 um 07:30 schrieb rupert THURNER: > there lies a lot of truth in all these mails. for us the incentive > was: > > 1. simple way to get a > 2. stable solaris package which comes from a > 3. long time sustaining (most important!) project which has a > 4. simple way to create a package which allows an > 5. effortless update to a new upstream version > > because it is early in the morning, allow me to be a little > provocative: > as so many emails are written, somebody must have some spare time, > which is a very good sign for an active voluntary project :) who > helps me updating php to a new version, maybe make the package less > complex ? Sure. How about we do it similar to OpenLDAP? Go for some restructuring, hand over on problems and I'll hand back again when I'm exhausted... Best regards -- Dago From bwalton at opencsw.org Fri Nov 19 13:26:42 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 19 Nov 2010 07:26:42 -0500 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <x67hg97ijy.fsf@opencsw.org> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> Message-ID: <1290169392-sup-7850@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Fri Nov 19 04:45:53 -0500 2010: > vision should matter also. Hence the community concept vs. a sort of > autocratic organization. Let that last one for Fortune 500 entities. I know this wasargued against the time someone put it forward , but I think the release manager should be a) an elected position and b) a position that is mutually exclusive from any board position. It may make sense to have the election for the release manager straddle/overlap the board election so that each release manager would see two boards and vice versa. As long as the elected person enforces the policies as laid out, and works to improve or clarify them where necessary, there is no reason this wouldn't work. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Fri Nov 19 14:20:59 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 19 Nov 2010 14:20:59 +0100 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <1290169392-sup-7850@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Fri, 19 Nov 2010 07:26:42 -0500") References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <1290169392-sup-7850@pinkfloyd.chass.utoronto.ca> Message-ID: <x6y68p5u10.fsf@opencsw.org> Ben Walton <bwalton at opencsw.org> writes: > Excerpts from Peter FELECAN's message of Fri Nov 19 04:45:53 -0500 2010: > >> vision should matter also. Hence the community concept vs. a sort of >> autocratic organization. Let that last one for Fortune 500 entities. > > I know this wasargued against the time someone put it forward , but I > think the release manager should be a) an elected position and b) a > position that is mutually exclusive from any board position. It may > make sense to have the election for the release manager > straddle/overlap the board election so that each release manager would > see two boards and vice versa. > > As long as the elected person enforces the policies as laid out, and > works to improve or clarify them where necessary, there is no reason > this wouldn't work. The policies should be defined and agreed upon by the maintainers community. When that is done, the policies must be enforced by tools which verify their application and validates a package for release. Hence, no need for a human release manager. This was discussed and agreed upon by 8 active members of the foundation. Maybe a call for vote on this issue is due but not before the new board election. -- Peter From dam at opencsw.org Fri Nov 19 17:27:43 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 19 Nov 2010 17:27:43 +0100 Subject: [csw-maintainers] Package length again References: <E1PIPuQ-0007gq-17@sfp-svn-4.v30.ch3.sourceforge.com> Message-ID: <0AF9DBAC-A930-43C7-A10E-AA05294FFA5E@opencsw.org> Hi Phil, Anfang der weitergeleiteten E-Mail: > -if [[ ${#software} -gt 20 ]] ; then errmsg $f: software name greater than 20 chars ; fi > -if [[ ${#pkgname} -gt 20 ]] ; then errmsg $f: pkg name greater than 20 chars; fi > +if [[ ${#software} -gt 29 ]] ; then errmsg $f: software name greater than 29 chars ; fi > +if [[ ${#pkgname} -gt 32 ]] ; then errmsg $f: pkg name greater than 32 chars; fi Waitaminute... When the package is called CSWpm(max 27 character) then the package name will be pm_(max 27 characters) leading to a 30 characters long catalog name. I guess the fixing on 29 catalog name was a it too fast... Best regards -- Dago From phil at bolthole.com Fri Nov 19 18:19:28 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 19 Nov 2010 09:19:28 -0800 Subject: [csw-maintainers] Package length again In-Reply-To: <0AF9DBAC-A930-43C7-A10E-AA05294FFA5E@opencsw.org> References: <E1PIPuQ-0007gq-17@sfp-svn-4.v30.ch3.sourceforge.com> <0AF9DBAC-A930-43C7-A10E-AA05294FFA5E@opencsw.org> Message-ID: <AANLkTinJ1zUcPHQZZfkszCOo3A7LznZ2zMYCsmKcgSZw@mail.gmail.com> On 11/19/10, Dagobert Michelsen <dam at opencsw.org> wrote: > Hi Phil, > > Anfang der weitergeleiteten E-Mail: >> -if [[ ${#software} -gt 20 ]] ; then errmsg $f: software name greater than >> 20 chars ; fi >> -if [[ ${#pkgname} -gt 20 ]] ; then errmsg $f: pkg name greater than 20 >> chars; fi >> +if [[ ${#software} -gt 29 ]] ; then errmsg $f: software name greater than >> 29 chars ; fi >> +if [[ ${#pkgname} -gt 32 ]] ; then errmsg $f: pkg name greater than 32 >> chars; fi > > Waitaminute... When the package is called > CSWpm(max 27 character) > then the package name will be > pm_(max 27 characters) > leading to a 30 characters long catalog name. I guess the fixing on 29 > catalog name was a it too fast... What.. you are suggesting that we now LOWER it, because perl package maintainers cant figure out that they need to shorten their software name by one char? :-} We certainly cannot raise it further in any way I think that the max allowable limits, simply state "max allowable",and that is fine. If there are collections of packages (such as perl modules) that have naming conventions beyond our global standard ones, that is something to be worked out for that area. It does not need to affect our global limits. From phil at bolthole.com Fri Nov 19 18:34:32 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 19 Nov 2010 09:34:32 -0800 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <x67hg97ijy.fsf@opencsw.org> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> Message-ID: <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> On 11/19/10, Peter FELECAN <pfelecan at opencsw.org> wrote: > Philip Brown <phil at bolthole.com> writes: >... >> So let me share more detail of my experience, and how that benefits my >> position of release manager. > > Well, nobody said that your contribution [as release manager] to the community is not > valuable. Choosing the option of "no human release manager", is saying exactly that. (if one presumes that people are choosing that option, with the assumption that quality of packages will not suffer as a result) It would in some ways bother me more, if a majority of maintainers voted for "no human release manager", and believed in their hearts, "yes, quality of packages WILL suffer, but I dont care, i just want life easier for myself" If the majority of voting members no longer care about package quality as paramount importance, that would be a sign that opencsw has become an organization I would no longer wish to be a part of, or even use products from. From phil at bolthole.com Fri Nov 19 18:50:38 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 19 Nov 2010 09:50:38 -0800 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <AANLkTinumvsFih1yERKyFJytLOc2zJBb4QL4vRdz7K27@mail.gmail.com> References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> <AANLkTinumvsFih1yERKyFJytLOc2zJBb4QL4vRdz7K27@mail.gmail.com> Message-ID: <AANLkTin1Y9Y2GPWVWh5YzqdPPUyY_k8T9Cgq=n4A9721@mail.gmail.com> On 11/18/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: > No dia 16 de Novembro de 2010 00:20, Philip Brown <phil at bolthole.com> > escreveu: > >> People will usually expect to find the package by simple name. Do we >> provide a ghost "libxyz" package that depends on the longer named one? Or >> expect that our users will educate themselves (usually a losing >> proposition) > > They will probably do something like "pkgutil -a libxyz" and find out > the package names. I guess I wasnt strong enough with my indirect comment about "losing proposition" :-) I am going to suggest a related fact, and then a choice to make. If you disagree that the 'fact' is not true, I will change it. But if we both agree it is true, then please treat it as 'fact' :) Fact: there will be users that run the command "pkgxxx install libxyz", and if it fails, will then presume "oh. opencsw does not have libxyz". Or similarly, attempt to visit "www.opencsw.org/packages/libxyz", etc. (Going to the full list of packages, and searching, is something I personally avoid too) I think we can both agree there exist this sort of people. the only difference between us would be how many there are, and how important they are. Choice: * we can be elitist about this, and take the attitude of, "Well, they need to learn how to use opencsw better" * or, we can have policies that are more accommodating to 'newbie' users. I tend to prefer policies that favour "I've never read a manpage, and dont want to," users. Comments? (We might also take the time to query our user list?) > What do you intend to do with your comments in on the wiki page? I > guess we want to arrive at a clean version of the document that can > eventually become our recommendation. At some point I will try to clean up points from me that have been resolved or fully answered. But may as well leave the mess for now, since if we dont come to a mutually agreed recommendation, we'll need to keep it for voting writeup. From dam at opencsw.org Fri Nov 19 19:10:47 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 19 Nov 2010 19:10:47 +0100 Subject: [csw-maintainers] Package length again In-Reply-To: <AANLkTinJ1zUcPHQZZfkszCOo3A7LznZ2zMYCsmKcgSZw@mail.gmail.com> References: <E1PIPuQ-0007gq-17@sfp-svn-4.v30.ch3.sourceforge.com> <0AF9DBAC-A930-43C7-A10E-AA05294FFA5E@opencsw.org> <AANLkTinJ1zUcPHQZZfkszCOo3A7LznZ2zMYCsmKcgSZw@mail.gmail.com> Message-ID: <4C50B93E-362B-4BE3-A088-0A7E1207D704@opencsw.org> Hi Phil, Am 19.11.2010 um 18:19 schrieb Philip Brown <phil at bolthole.com>: > On 11/19/10, Dagobert Michelsen <dam at opencsw.org> wrote: >> Hi Phil, >> >> Anfang der weitergeleiteten E-Mail: >>> -if [[ ${#software} -gt 20 ]] ; then errmsg $f: software name greater than >>> 20 chars ; fi >>> -if [[ ${#pkgname} -gt 20 ]] ; then errmsg $f: pkg name greater than 20 >>> chars; fi >>> +if [[ ${#software} -gt 29 ]] ; then errmsg $f: software name greater than >>> 29 chars ; fi >>> +if [[ ${#pkgname} -gt 32 ]] ; then errmsg $f: pkg name greater than 32 >>> chars; fi >> >> Waitaminute... When the package is called >> CSWpm(max 27 character) >> then the package name will be >> pm_(max 27 characters) >> leading to a 30 characters long catalog name. I guess the fixing on 29 >> catalog name was a it too fast... > > What.. you are suggesting that we now LOWER it, because perl package > maintainers cant figure out that they need to shorten their software > name by one char? :-} > We certainly cannot raise it further in any way > > I think that the max allowable limits, simply state "max > allowable",and that is fine. If there are collections of packages > (such as perl modules) that have naming conventions beyond our global > standard ones, that is something to be worked out for that area. It > does not need to affect our global limits. I am suggesting to raise the catalogname length limit to 30 characters. Best regards -- Dago From phil at bolthole.com Fri Nov 19 20:07:57 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 19 Nov 2010 11:07:57 -0800 Subject: [csw-maintainers] Package length again In-Reply-To: <4C50B93E-362B-4BE3-A088-0A7E1207D704@opencsw.org> References: <E1PIPuQ-0007gq-17@sfp-svn-4.v30.ch3.sourceforge.com> <0AF9DBAC-A930-43C7-A10E-AA05294FFA5E@opencsw.org> <AANLkTinJ1zUcPHQZZfkszCOo3A7LznZ2zMYCsmKcgSZw@mail.gmail.com> <4C50B93E-362B-4BE3-A088-0A7E1207D704@opencsw.org> Message-ID: <AANLkTimg=VZHCA7V-gYoUSmPauQo0wm--XTPOTh37EBV@mail.gmail.com> On 11/19/10, Dagobert Michelsen <dam at opencsw.org> wrote: > > Am 19.11.2010 um 18:19 schrieb Philip Brown <phil at bolthole.com>: >> I think that the max allowable limits, simply state "max >> allowable",and that is fine. If there are collections of packages >> (such as perl modules) that have naming conventions beyond our global >> standard ones, that is something to be worked out for that area. It >> does not need to affect our global limits. > > I am suggesting to raise the catalogname length limit to 30 characters. > but that would allow people to create non-perl packages, that had catalog names that would not, and could not, match the PKG names exactly. One of the big things about adjusting the name lengths, was that we were finally going to have exact parity between PKG name, and 'catalog name', from now on. If you feel so strongly about the 1 char inequality for perl packages, then perhaps instead you should adjust the perl naming spec so that instead of pm_xxxx CSWpmxxxx it now becomes pm_xxx CSWpm-xxx Then you once again have full parity between catalog and PKG name. Plus it looks cleaner anyway. *and* matches what we are doing in other areas, such as python module naming. From dam at opencsw.org Fri Nov 19 20:30:11 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 19 Nov 2010 20:30:11 +0100 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> Message-ID: <C893A98F-BC78-491A-AC12-341A450A0CE3@opencsw.org> Hi, Am 19.11.2010 um 18:34 schrieb Philip Brown: > On 11/19/10, Peter FELECAN <pfelecan at opencsw.org> wrote: >> Philip Brown <phil at bolthole.com> writes: >> ... >>> So let me share more detail of my experience, and how that benefits my >>> position of release manager. >> >> Well, nobody said that your contribution [as release manager] to the community is not >> valuable. > > Choosing the option of "no human release manager", is saying exactly that. > (if one presumes that people are choosing that option, with the > assumption that quality of packages will not suffer as a result) > > It would in some ways bother me more, if a majority of maintainers > voted for "no human release manager", and believed in their hearts, > "yes, quality of packages WILL suffer, but I dont care, i just want > life easier for myself" > If the majority of voting members no longer care about package quality > as paramount importance, that would be a sign that opencsw has become > an organization I would no longer wish to be a part of, or even use > products from. Peter, IIRC we agreed on moving to something similar like http://wiki.opencsw.org/automated-release-process This indeed has no release manager for the first step when the maintainer can deliver directly to experimental/ (as in the document, not as we use it ATM), which automatically generates new catalogs and brave users can install from that. But the migration to the following repositories unstable/testing/stable (again as in the document) are done asynchronously by the release manager. So I think you are suggesting to shift the role of the release manager slightly, right? Best regards -- Dago From dam at opencsw.org Fri Nov 19 20:34:40 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 19 Nov 2010 20:34:40 +0100 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <AANLkTin1Y9Y2GPWVWh5YzqdPPUyY_k8T9Cgq=n4A9721@mail.gmail.com> References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> <AANLkTinumvsFih1yERKyFJytLOc2zJBb4QL4vRdz7K27@mail.gmail.com> <AANLkTin1Y9Y2GPWVWh5YzqdPPUyY_k8T9Cgq=n4A9721@mail.gmail.com> Message-ID: <38930B84-F102-4DA7-9C80-98303342C1B1@opencsw.org> Hi Phil, Am 19.11.2010 um 18:50 schrieb Philip Brown: > On 11/18/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: >> No dia 16 de Novembro de 2010 00:20, Philip Brown <phil at bolthole.com> >> escreveu: >> >>> People will usually expect to find the package by simple name. Do we >>> provide a ghost "libxyz" package that depends on the longer named one? Or >>> expect that our users will educate themselves (usually a losing >>> proposition) >> >> They will probably do something like "pkgutil -a libxyz" and find out >> the package names. > > I guess I wasnt strong enough with my indirect comment about "losing > proposition" :-) > I am going to suggest a related fact, and then a choice to make. > If you disagree that the 'fact' is not true, I will change it. But if > we both agree it is true, then please treat it as 'fact' :) > > Fact: there will be users that run the command "pkgxxx install > libxyz", and if it fails, will then presume "oh. opencsw does not have > libxyz". > Or similarly, attempt to visit "www.opencsw.org/packages/libxyz", etc. > (Going to the full list of packages, and searching, is something I > personally avoid too) > > I think we can both agree there exist this sort of people. the only > difference between us would be how many there are, and how important > they are. > Choice: > * we can be elitist about this, and take the attitude of, "Well, they > need to learn how to use opencsw better" > * or, we can have policies that are more accommodating to 'newbie' users. > > I tend to prefer policies that favour "I've never read a manpage, and > dont want to," users. > > Comments? Having libxyz in the catalog does sound useful, but I am unsure what to expect in this case: - is it the latest libxyzN? - is it the latest libxyzN together with _devel? - is it all versions libxyzM, libxyzN, ... together with _devel? - ...or does it directly contain legacy .so.L and depends on _devel? The longer I think about it the more I think libxyz as a "bundle" containing everything related to the package, whereas legacy stuff would be directly in it as long as necessary and other things like libxyzM and _devel would be factored out and be depend on. This would be consistent with that we have planned for the bugtracker and it would also be useful as web-entry-point for a software. Best regards -- Dago From dam at opencsw.org Fri Nov 19 20:41:45 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 19 Nov 2010 20:41:45 +0100 Subject: [csw-maintainers] Package length again In-Reply-To: <AANLkTimg=VZHCA7V-gYoUSmPauQo0wm--XTPOTh37EBV@mail.gmail.com> References: <E1PIPuQ-0007gq-17@sfp-svn-4.v30.ch3.sourceforge.com> <0AF9DBAC-A930-43C7-A10E-AA05294FFA5E@opencsw.org> <AANLkTinJ1zUcPHQZZfkszCOo3A7LznZ2zMYCsmKcgSZw@mail.gmail.com> <4C50B93E-362B-4BE3-A088-0A7E1207D704@opencsw.org> <AANLkTimg=VZHCA7V-gYoUSmPauQo0wm--XTPOTh37EBV@mail.gmail.com> Message-ID: <01CF7488-69CA-4863-A3DB-49CF56756B98@opencsw.org> Hi Phil, Am 19.11.2010 um 20:07 schrieb Philip Brown: > On 11/19/10, Dagobert Michelsen <dam at opencsw.org> wrote: >> >> Am 19.11.2010 um 18:19 schrieb Philip Brown <phil at bolthole.com>: > >>> I think that the max allowable limits, simply state "max >>> allowable",and that is fine. If there are collections of packages >>> (such as perl modules) that have naming conventions beyond our global >>> standard ones, that is something to be worked out for that area. It >>> does not need to affect our global limits. >> >> I am suggesting to raise the catalogname length limit to 30 characters. >> > > but that would allow people to create non-perl packages, that had > catalog names that would not, and could not, match the PKG names > exactly. > One of the big things about adjusting the name lengths, was that we > were finally going to have exact parity between PKG name, and 'catalog > name', from now on. > > If you feel so strongly about the 1 char inequality for perl packages, > then perhaps instead you should adjust the perl naming spec so that > instead of > > pm_xxxx > CSWpmxxxx > > it now becomes > > pm_xxx > CSWpm-xxx > > Then you once again have full parity between catalog and PKG name. > Plus it looks cleaner anyway. *and* matches what we are doing in other > areas, such as python module naming. Generally I agree. But would you agree renaming all packages? Having 80% old CSWpmabc packages and 20% new CSWpm-xyz packages seems to be the worst solution to me, although I really favor using more hyphens as it reduces ambiguity and eases reading. But unless this is true I would favor raising the catalogname to match the leading package name by existing naming conventions, and that would require a raise or not using the full package name length for Perl modules without violating the current convention. Best regards -- Dago From phil at bolthole.com Fri Nov 19 20:46:37 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 19 Nov 2010 11:46:37 -0800 Subject: [csw-maintainers] Package length again In-Reply-To: <01CF7488-69CA-4863-A3DB-49CF56756B98@opencsw.org> References: <E1PIPuQ-0007gq-17@sfp-svn-4.v30.ch3.sourceforge.com> <0AF9DBAC-A930-43C7-A10E-AA05294FFA5E@opencsw.org> <AANLkTinJ1zUcPHQZZfkszCOo3A7LznZ2zMYCsmKcgSZw@mail.gmail.com> <4C50B93E-362B-4BE3-A088-0A7E1207D704@opencsw.org> <AANLkTimg=VZHCA7V-gYoUSmPauQo0wm--XTPOTh37EBV@mail.gmail.com> <01CF7488-69CA-4863-A3DB-49CF56756B98@opencsw.org> Message-ID: <AANLkTim3rQ=XiL0-8apsPxNjJiXLQyipmGv+JW45_1f-@mail.gmail.com> On 11/19/10, Dagobert Michelsen <dam at opencsw.org> wrote: > Hi Phil, > > Am 19.11.2010 um 20:07 schrieb Philip Brown: >>... >> If you feel so strongly about the 1 char inequality for perl packages, >> then perhaps instead you should adjust the perl naming spec ... >>.... >> Then you once again have full parity between catalog and PKG name. >> Plus it looks cleaner anyway. *and* matches what we are doing in other >> areas, such as python module naming. > > Generally I agree. But would you agree renaming all packages? Having > 80% old CSWpmabc packages and 20% new CSWpm-xyz packages seems to > be the worst solution to me, although I really favor using more > hyphens as it reduces ambiguity and eases reading. perl modules seem to have a high rate of "churn". So I dont think this is a bad thing: they will probably get mostly refreshed over the course of the next 12 months anyway, I would guess, to approach 100% I think the added benefit of consistency with py_ modules, makes this the best choice. The renaming IS going to be horrible, and yes I will probably get sulky about it at times, because of the extra work that *I* will have to do as well. :-} But it is the right thing to do I think. From dam at opencsw.org Fri Nov 19 21:25:32 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 19 Nov 2010 21:25:32 +0100 Subject: [csw-maintainers] Package length again In-Reply-To: <AANLkTim3rQ=XiL0-8apsPxNjJiXLQyipmGv+JW45_1f-@mail.gmail.com> References: <E1PIPuQ-0007gq-17@sfp-svn-4.v30.ch3.sourceforge.com> <0AF9DBAC-A930-43C7-A10E-AA05294FFA5E@opencsw.org> <AANLkTinJ1zUcPHQZZfkszCOo3A7LznZ2zMYCsmKcgSZw@mail.gmail.com> <4C50B93E-362B-4BE3-A088-0A7E1207D704@opencsw.org> <AANLkTimg=VZHCA7V-gYoUSmPauQo0wm--XTPOTh37EBV@mail.gmail.com> <01CF7488-69CA-4863-A3DB-49CF56756B98@opencsw.org> <AANLkTim3rQ=XiL0-8apsPxNjJiXLQyipmGv+JW45_1f-@mail.gmail.com> Message-ID: <13120DA0-2742-4C68-9850-CBFED6B82846@opencsw.org> Hi Phil, Am 19.11.2010 um 20:46 schrieb Philip Brown: > On 11/19/10, Dagobert Michelsen <dam at opencsw.org> wrote: >> Am 19.11.2010 um 20:07 schrieb Philip Brown: >>> ... >>> If you feel so strongly about the 1 char inequality for perl packages, >>> then perhaps instead you should adjust the perl naming spec ... >>> .... >>> Then you once again have full parity between catalog and PKG name. >>> Plus it looks cleaner anyway. *and* matches what we are doing in other >>> areas, such as python module naming. >> >> Generally I agree. But would you agree renaming all packages? Having >> 80% old CSWpmabc packages and 20% new CSWpm-xyz packages seems to >> be the worst solution to me, although I really favor using more >> hyphens as it reduces ambiguity and eases reading. > > perl modules seem to have a high rate of "churn". So I dont think this > is a bad thing: they will probably get mostly refreshed over the > course of the next 12 months anyway, I would guess, to approach 100% > > I think the added benefit of consistency with py_ modules, makes this > the best choice. > > The renaming IS going to be horrible, and yes I will probably get > sulky about it at times, because of the extra work that *I* will have > to do as well. :-} > But it is the right thing to do I think. Just my 0.02 ? ... We have a lot of invasive changes pending. Maybe it is time for a "rebuild-all-stable" effort to really get rid of old stuff and completely start over and rethink how a modern Solaris packaging really should look like including IPS interop, fully consistent package naming, the new release process... Don't get me too serious, this may very well be late-night dream (or nightmare :-) from me... Best regards -- Dago From phil at bolthole.com Fri Nov 19 21:48:12 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 19 Nov 2010 12:48:12 -0800 Subject: [csw-maintainers] Package length again In-Reply-To: <13120DA0-2742-4C68-9850-CBFED6B82846@opencsw.org> References: <E1PIPuQ-0007gq-17@sfp-svn-4.v30.ch3.sourceforge.com> <0AF9DBAC-A930-43C7-A10E-AA05294FFA5E@opencsw.org> <AANLkTinJ1zUcPHQZZfkszCOo3A7LznZ2zMYCsmKcgSZw@mail.gmail.com> <4C50B93E-362B-4BE3-A088-0A7E1207D704@opencsw.org> <AANLkTimg=VZHCA7V-gYoUSmPauQo0wm--XTPOTh37EBV@mail.gmail.com> <01CF7488-69CA-4863-A3DB-49CF56756B98@opencsw.org> <AANLkTim3rQ=XiL0-8apsPxNjJiXLQyipmGv+JW45_1f-@mail.gmail.com> <13120DA0-2742-4C68-9850-CBFED6B82846@opencsw.org> Message-ID: <AANLkTimhgvNwQfCy733hmzmYGZx3vZq--mSO8b9H0unt@mail.gmail.com> On 11/19/10, Dagobert Michelsen <dam at opencsw.org> wrote: > Hi Phil, > > Just my 0.02 ? ... > > We have a lot of invasive changes pending. Maybe it is time for a > "rebuild-all-stable" effort to really get rid of old stuff and > completely start over and rethink how a modern Solaris packaging > really should look like including IPS interop, fully consistent > package naming, the new release process... > > Don't get me too serious, this may very well be late-night dream > (or nightmare :-) from me... > hey, I'm all for it, as long as you get enough reliable people to commit to, "I will spend X hours of work every week on this" up front :) But nature of open source type projects, says that sort of huge change set only works for paid time. With volunteer time, you have to do things incrementally. From pfelecan at opencsw.org Sat Nov 20 10:06:24 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 20 Nov 2010 10:06:24 +0100 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <C893A98F-BC78-491A-AC12-341A450A0CE3@opencsw.org> (Dagobert Michelsen's message of "Fri, 19 Nov 2010 20:30:11 +0100") References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <C893A98F-BC78-491A-AC12-341A450A0CE3@opencsw.org> Message-ID: <x6pqu05ppr.fsf@opencsw.org> Dagobert Michelsen <dam at opencsw.org> writes: > Hi, > > Am 19.11.2010 um 18:34 schrieb Philip Brown: >> On 11/19/10, Peter FELECAN <pfelecan at opencsw.org> wrote: >>> Philip Brown <phil at bolthole.com> writes: >>> ... >>>> So let me share more detail of my experience, and how that benefits my >>>> position of release manager. >>> >>> Well, nobody said that your contribution [as release manager] to the community is not >>> valuable. >> >> Choosing the option of "no human release manager", is saying exactly that. >> (if one presumes that people are choosing that option, with the >> assumption that quality of packages will not suffer as a result) >> >> It would in some ways bother me more, if a majority of maintainers >> voted for "no human release manager", and believed in their hearts, >> "yes, quality of packages WILL suffer, but I dont care, i just want >> life easier for myself" >> If the majority of voting members no longer care about package quality >> as paramount importance, that would be a sign that opencsw has become >> an organization I would no longer wish to be a part of, or even use >> products from. > > Peter, IIRC we agreed on moving to something similar like > http://wiki.opencsw.org/automated-release-process No. What you refer is "last_edited: 30 Jan 2010" so it predates the summer summit. The agreed on process is that referred in the wave of August 14th under the title "Release process (alternative approaches to a new stable/)" To access the wave, here's the link: https://wave.google.com/wave/waveref/googlewave.com/w+0tu9vv7tA > This indeed has no release manager for the first step when the > maintainer can deliver directly to experimental/ (as in the document, > not as we use it ATM), which automatically generates new catalogs > and brave users can install from that. But the migration to > the following repositories unstable/testing/stable (again as in > the document) are done asynchronously by the release manager. > So I think you are suggesting to shift the role of the release > manager slightly, right? If that was not clear until now: I'm suggesting the whole elimination of a human release manager. -- Peter From maciej at opencsw.org Sat Nov 20 13:26:51 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 20 Nov 2010 12:26:51 +0000 Subject: [csw-maintainers] Removing old packages from the OS Message-ID: <AANLkTi=0jDkdDii4m0M61E304R=ipgGRN1bu-JOoYP_=@mail.gmail.com> The issue of removing packages from the OS is important in 2 main cases: - package renames (pkgname changes) - phasing out of old packages In the rename case, our method is to declare the old package incompatible with the renamed package. For example: CSWbar (old package, removed from the catalog) CSWfoo (new package) incompatible with CSWbar I'm not sure what's the plan for the user actions. I think that the assumption is that users will read messages from pkgadd, and realize that CSWbar should not be installed. Having realized that, they will use their own tools to remove the old packages. I might be wrong though. I remember a discussion on irc where Peter Bonivart mentioned that pkgutil automatically removed the incompatible packages. Is that true? in general, what is the typical package removal scenario for an OpenCSW user? Maciej From maciej at opencsw.org Sat Nov 20 15:21:37 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 20 Nov 2010 14:21:37 +0000 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> Message-ID: <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> No dia 19 de Novembro de 2010 17:34, Philip Brown <phil at bolthole.com> escreveu: > On 11/19/10, Peter FELECAN <pfelecan at opencsw.org> wrote: >> Philip Brown <phil at bolthole.com> writes: >>... >>> So let me share more detail of my experience, and how that benefits my >>> position of release manager. >> >> Well, nobody said that your contribution [as release manager] to the community is not >> valuable. That's not what Peter said. It's a good thing you've inserted the bit in brackets, I can see now how you understood it. I don't think this is how Peter meant it. I think that he meant that your valuable contributions to the community might not be about stopping packages from entering the catalog - something that you seem to believe is the primary function of the release manager. For example, package consulting is hugely important. Dissecting a package, analyzing the contents, looking direct problems and potential problems, and providing feedback, is an immensely valuable activity. > Choosing the option of "no human release manager", is saying exactly that. > (if one presumes that people are choosing that option, with the > assumption that quality of packages will not suffer as a result) No human release manager means that there is no single person in power. It does not mean that packages aren't examined by a human. The difference is that in the consensus model, the person who takes the time to examine packages, is a voice in discussion rather than an authority. If the issue raised is, for example, of an aesthetic nature, it will be resolved by consensus. > It would in some ways bother me more, if a majority of maintainers > voted for "no human release manager", and believed in their hearts, > "yes, quality of packages WILL suffer, but I dont care, i just want > life easier for myself" > If the majority of voting members no longer care about package quality > as paramount importance, I don't believe that package quality alone should be the gating factor. It's not part of our core value is providing straightforward experience for the user, and having packages in the first place can be more important. Presented with a dilemma of a slightly flawed package versus no package at all, I would go for the imperfect package option. It could at least work for some users. > that would be a sign that opencsw has become > an organization I would no longer wish to be a part of, or even use > products from. What do you want to achieve by saying this? From maciej at opencsw.org Sat Nov 20 15:26:11 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 20 Nov 2010 14:26:11 +0000 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> Message-ID: <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> (Apologies, I hit "send" too early. Here's a proofread version.) No dia 19 de Novembro de 2010 17:34, Philip Brown <phil at bolthole.com> escreveu: > On 11/19/10, Peter FELECAN <pfelecan at opencsw.org> wrote: >> Philip Brown <phil at bolthole.com> writes: >>... >>> So let me share more detail of my experience, and how that benefits my >>> position of release manager. >> >> Well, nobody said that your contribution [as release manager] to the community is not >> valuable. That's not what Peter said. It's a good thing you've inserted the bit in brackets, I can see now how you understood it. I don't think this is how Peter meant it. I think that he meant that your valuable contributions to the community might not be about stopping packages from entering the catalog - something that you seem to believe is the primary function of the release manager. For example, package consulting is hugely important. Dissecting a package, analyzing the contents, looking for direct and potential problems, and providing feedback, is an immensely valuable activity. > Choosing the option of "no human release manager", is saying exactly that. > (if one presumes that people are choosing that option, with the > assumption that quality of packages will not suffer as a result) No human release manager means that there is no single person in power. It does not mean that packages aren't examined by a human. The difference is that in the consensus model, the person who takes the time to examine packages, is a voice in discussion rather than an authority. If the issue raised is, for example, of an aesthetic nature, it will be resolved by consensus. > It would in some ways bother me more, if a majority of maintainers > voted for "no human release manager", and believed in their hearts, > "yes, quality of packages WILL suffer, but I dont care, i just want > life easier for myself" > If the majority of voting members no longer care about package quality > as paramount importance, I don't believe that package quality alone should be the gating factor. It's not part of our core values. Our core value is providing straightforward experience for the user, and having packages in the first place can be more important. Presented with a dilemma of a slightly flawed package versus no package at all, I would go for the imperfect package option. It could work for at least some users. > that would be a sign that opencsw has become > an organization I would no longer wish to be a part of, or even use > products from. What do you want to achieve by saying this? From phil at bolthole.com Sat Nov 20 20:46:54 2010 From: phil at bolthole.com (Philip Brown) Date: Sat, 20 Nov 2010 11:46:54 -0800 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> Message-ID: <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> On Sat, Nov 20, 2010 at 6:26 AM, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: > (Apologies, I hit "send" too early. Here's a proofread version.) >... > > For example, package consulting is hugely important. ?Dissecting a > package, analyzing the contents, looking for direct and potential > problems, and providing feedback, is an immensely valuable activity. > >> Choosing the option of "no human release manager", is saying exactly that. >> (if one presumes that people are choosing that option, with the >> assumption that quality of packages will not suffer as a result) > > No human release manager means that there is no single person in > power. ?It does not mean that packages aren't examined by a human. (I will point out that this is EXACTLY what Peter proposed: no-one other than the maintainer would directly examine them before release, is his stated goal. But now to address what you wrote:) How will they ever get examined by someone other than the maintainer, then? Please propose something that is actually practical, rather than just ideal. In the Real World, how will you ensure that packages are examined "by a human[that is not just the maintainer themselves]" before release to 'current'? What you wrote, seems to be contradictory. if there is no human release manager, then there is no human looking at packages before release. perhaps you meant "no SINGLE release manager", but that's not what you wrote :-) From pfelecan at opencsw.org Sun Nov 21 12:48:37 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 21 Nov 2010 12:48:37 +0100 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> (Philip Brown's message of "Sat, 20 Nov 2010 11:46:54 -0800") References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> Message-ID: <x61v6e6goa.fsf@opencsw.org> Philip Brown <phil at bolthole.com> writes: > On Sat, Nov 20, 2010 at 6:26 AM, Maciej (Matchek) Blizinski > <maciej at opencsw.org> wrote: >> (Apologies, I hit "send" too early. Here's a proofread version.) >>... >> >> For example, package consulting is hugely important. ?Dissecting a >> package, analyzing the contents, looking for direct and potential >> problems, and providing feedback, is an immensely valuable activity. >> >>> Choosing the option of "no human release manager", is saying exactly that. >>> (if one presumes that people are choosing that option, with the >>> assumption that quality of packages will not suffer as a result) >> >> No human release manager means that there is no single person in >> power. ?It does not mean that packages aren't examined by a human. > > (I will point out that this is EXACTLY what Peter proposed: no-one > other than the maintainer would directly examine them before release, > is his stated goal. But now to address what you wrote:) The maintainer is a human, isn't it? The maintainers community is formed by humans. If you read the referred proposal you'll see that the release is done to experimental and it transits, depending on well defined rules, such as reported issues, policies &c, to unstable, testing and then to current. > How will they ever get examined by someone other than the maintainer, then? > Please propose something that is actually practical, rather than just ideal. > In the Real World, how will you ensure that packages are examined "by > a human[that is not just the maintainer themselves]" before release to > 'current'? What's "Real World"? The world according to you? There are other options such as automated processes supported by non discretionary release managers. Look at the other distributions models and you'll see that there is not a serious one having an *unique* person doing discretionary release management. Anyhow, in my opinion, you assumed this role for a too long time and that is the reason for which you cannot consider a situation where you don't have that role. Not having the role of release manager seems for you the end of your participation to the community. Aut caesar aut nihil. This is a strange attachment. -- Peter From phil at bolthole.com Sun Nov 21 16:55:47 2010 From: phil at bolthole.com (Philip Brown) Date: Sun, 21 Nov 2010 07:55:47 -0800 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <x61v6e6goa.fsf@opencsw.org> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> <x61v6e6goa.fsf@opencsw.org> Message-ID: <AANLkTinmdKxNe85kKk=n14fowopEE3UOZVMqOt3WS=7b@mail.gmail.com> On Sun, Nov 21, 2010 at 3:48 AM, Peter FELECAN <pfelecan at opencsw.org> wrote: >... > . Anyhow, in my opinion, you assumed this role for a > too long time and that is the reason for which you cannot consider a > situation where you don't have that role. Not having the role of release > manager seems for you the end of your participation to the > community. Aut caesar aut nihil. This is a strange attachment. If you were proposing simply removing ME as release manager, and having the position be elected, your opinion might have some justification for it. But since instead you are trying to eliminate the position entirely, your ad hominen attack is completely misdirected. From pfelecan at opencsw.org Sun Nov 21 17:12:01 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 21 Nov 2010 17:12:01 +0100 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTinmdKxNe85kKk=n14fowopEE3UOZVMqOt3WS=7b@mail.gmail.com> (Philip Brown's message of "Sun, 21 Nov 2010 07:55:47 -0800") References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> <x61v6e6goa.fsf@opencsw.org> <AANLkTinmdKxNe85kKk=n14fowopEE3UOZVMqOt3WS=7b@mail.gmail.com> Message-ID: <x6sjyu4pwu.fsf@opencsw.org> Philip Brown <phil at bolthole.com> writes: > On Sun, Nov 21, 2010 at 3:48 AM, Peter FELECAN <pfelecan at opencsw.org> wrote: >>... >> . Anyhow, in my opinion, you assumed this role for a >> too long time and that is the reason for which you cannot consider a >> situation where you don't have that role. Not having the role of release >> manager seems for you the end of your participation to the >> community. Aut caesar aut nihil. This is a strange attachment. > > > If you were proposing simply removing ME as release manager, and > having the position be elected, your opinion might have some > justification for it. > But since instead you are trying to eliminate the position entirely, > your ad hominen attack is completely misdirected. I tried to convey in my messages that this is not an ad hominem attack. That being said, I'm against a kind of paternalistic and absolutist posture that you take and I'm afraid any release manager having discretionary power would take. Consequently, I'm not against you as Philip Brown per se, and that being said, lets move on the main issue which is the release process as proposed in the referred document which mandates the usage of automatic verification and validation tools based on well defined and known policies issued by the maintainers community consensus. -- Peter From phil at bolthole.com Tue Nov 23 00:00:00 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 22 Nov 2010 15:00:00 -0800 Subject: [csw-maintainers] Final feedback for putting in GAR/repository info into our mysql db In-Reply-To: <5CA5AA66-A74A-4FF9-A6CE-F7E7C707027A@opencsw.org> References: <AANLkTimHa35+QjJx0FFmLDjcvfz=pGFdc2h=uSWG-GiB@mail.gmail.com> <5CA5AA66-A74A-4FF9-A6CE-F7E7C707027A@opencsw.org> Message-ID: <AANLkTim0asmfs1qzeRWsiknQgWsLxE66d_Vat-ngaA3O@mail.gmail.com> On 11/19/10, Dagobert Michelsen <dam at opencsw.org> wrote: > Hi Phil, > > Am 18.11.2010 um 20:45 schrieb Philip Brown: >> If there's no other feedback in support of the shorter method, then I >> guess I'll start working on implementing the longer method come monday >> (nov 22nd) > > Great! > fyi, this is done. and I also took the liberty of back-registering packages released in the last 100 days. Good thing I like copious output from my registration script... or I would have missed that it isnt always "sf.net", but sometimes "sourceforge.net" :-/ From maciej at opencsw.org Tue Nov 23 08:41:19 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 23 Nov 2010 07:41:19 +0000 Subject: [csw-maintainers] OpenSolaris on FLOSS Weekly (ep. 75) Message-ID: <AANLkTi=RX9NONUozpur7eTp=VyJGi73ToVJte84MWTTw@mail.gmail.com> It's an old episode of a tech podcast, from June 2009. An interview with Glynn Foster http://twit.tv/floss75 from (at the time) Sun Microsystems. I thought folks here might find it interesting. Some topics would need updates though, especially the relation between Oracle and OpenSolaris. Maciej From dam at opencsw.org Tue Nov 23 10:34:04 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 23 Nov 2010 10:34:04 +0100 Subject: [csw-maintainers] Final feedback for putting in GAR/repository info into our mysql db In-Reply-To: <AANLkTim0asmfs1qzeRWsiknQgWsLxE66d_Vat-ngaA3O@mail.gmail.com> References: <AANLkTimHa35+QjJx0FFmLDjcvfz=pGFdc2h=uSWG-GiB@mail.gmail.com> <5CA5AA66-A74A-4FF9-A6CE-F7E7C707027A@opencsw.org> <AANLkTim0asmfs1qzeRWsiknQgWsLxE66d_Vat-ngaA3O@mail.gmail.com> Message-ID: <9AA59E51-9948-43D7-9571-E38B87BCB6F2@opencsw.org> Hi, Am 23.11.2010 um 00:00 schrieb Philip Brown: > On 11/19/10, Dagobert Michelsen <dam at opencsw.org> wrote: >> Am 18.11.2010 um 20:45 schrieb Philip Brown: > >>> If there's no other feedback in support of the shorter method, then I >>> guess I'll start working on implementing the longer method come monday >>> (nov 22nd) >> >> Great! > > fyi, this is done. Um, where is it? There is no link at http://www.opencsw.org/packages/libtool/ or is the webpage done by someone else? > and I also took the liberty of back-registering packages released in > the last 100 days. Cool. > Good thing I like copious output from my registration script... or I > would have missed that it isnt always "sf.net", but sometimes > "sourceforge.net" :-/ The plain SVN URL is registered in the package. The problem is that Sourceforge has multiple domains with the same contents, but I guess these are the only ones. Best regards -- Dago From skayser at opencsw.org Tue Nov 23 11:28:06 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 23 Nov 2010 11:28:06 +0100 Subject: [csw-maintainers] Final feedback for putting in GAR/repository info into our mysql db In-Reply-To: <9AA59E51-9948-43D7-9571-E38B87BCB6F2@opencsw.org> References: <AANLkTimHa35+QjJx0FFmLDjcvfz=pGFdc2h=uSWG-GiB@mail.gmail.com> <5CA5AA66-A74A-4FF9-A6CE-F7E7C707027A@opencsw.org> <AANLkTim0asmfs1qzeRWsiknQgWsLxE66d_Vat-ngaA3O@mail.gmail.com> <9AA59E51-9948-43D7-9571-E38B87BCB6F2@opencsw.org> Message-ID: <20101123102806.GF28050@sebastiankayser.de> * Dagobert Michelsen <dam at opencsw.org> wrote: > Am 23.11.2010 um 00:00 schrieb Philip Brown: > > On 11/19/10, Dagobert Michelsen <dam at opencsw.org> wrote: > >> Am 18.11.2010 um 20:45 schrieb Philip Brown: > > > >>> If there's no other feedback in support of the shorter method, then I > >>> guess I'll start working on implementing the longer method come monday > >>> (nov 22nd) > >> > >> Great! > > > > fyi, this is done. > > Um, where is it? There is no link at > http://www.opencsw.org/packages/libtool/ > or is the webpage done by someone else? It's done by someone else. Anyone aware about the packages/ setup on our www box? Anyone with Wordpress know how? Will look into it unless someone else jumps in. @Ihsan: Just had a look, the web files on the www box are still all owned by William. Could we get a wwwadmin user to which certain people can sudo to? > > and I also took the liberty of back-registering packages released in > > the last 100 days. Thanks. Any problem with simply processing all packages? > > Good thing I like copious output from my registration script... or I > > would have missed that it isnt always "sf.net", but sometimes > > "sourceforge.net" :-/ > > The plain SVN URL is registered in the package. The problem is that > Sourceforge has multiple domains with the same contents, but I guess > these are the only ones. In our repository links we should use SF's canonical domain name (sourceforge.net) as that's what their certificates are issued for, e.g. *.svn.sourceforge.net. Sebastian From skayser at opencsw.org Tue Nov 23 12:45:56 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 23 Nov 2010 12:45:56 +0100 Subject: [csw-maintainers] Final feedback for putting in GAR/repository info into our mysql db In-Reply-To: <20101123102806.GF28050@sebastiankayser.de> References: <AANLkTimHa35+QjJx0FFmLDjcvfz=pGFdc2h=uSWG-GiB@mail.gmail.com> <5CA5AA66-A74A-4FF9-A6CE-F7E7C707027A@opencsw.org> <AANLkTim0asmfs1qzeRWsiknQgWsLxE66d_Vat-ngaA3O@mail.gmail.com> <9AA59E51-9948-43D7-9571-E38B87BCB6F2@opencsw.org> <20101123102806.GF28050@sebastiankayser.de> Message-ID: <20101123114556.GG28050@sebastiankayser.de> * Sebastian Kayser <skayser at opencsw.org> wrote: > * Dagobert Michelsen <dam at opencsw.org> wrote: > > Am 23.11.2010 um 00:00 schrieb Philip Brown: > > > On 11/19/10, Dagobert Michelsen <dam at opencsw.org> wrote: > > >> Am 18.11.2010 um 20:45 schrieb Philip Brown: > > > > > >>> If there's no other feedback in support of the shorter method, then I > > >>> guess I'll start working on implementing the longer method come monday > > >>> (nov 22nd) > > >> > > >> Great! > > > > > > fyi, this is done. > > > > Um, where is it? There is no link at > > http://www.opencsw.org/packages/libtool/ > > or is the webpage done by someone else? > > It's done by someone else. Anyone aware about the packages/ setup on our > www box? Anyone with Wordpress know how? Will look into it unless > someone else jumps in. Figured out the setup. Do we have a place to document such internal things? I keep a Mantis related README on the www server itself. A restricted wiki or such would be nice though. > @Ihsan: Just had a look, the web files on the www box are still all > owned by William. Could we get a wwwadmin user to which certain people > can sudo to? ^^ Now this needs to be figured out :) Sebastian From maciej at opencsw.org Tue Nov 23 13:08:26 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 23 Nov 2010 12:08:26 +0000 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> Message-ID: <AANLkTik=_qycu1fanHTLbwD8SSrCDcKe+5mbpHoRY851@mail.gmail.com> No dia 20 de Novembro de 2010 19:46, Philip Brown <phil at bolthole.com> escreveu: > On Sat, Nov 20, 2010 at 6:26 AM, Maciej (Matchek) Blizinski > <maciej at opencsw.org> wrote: >> (Apologies, I hit "send" too early. Here's a proofread version.) >>... >> >> For example, package consulting is hugely important. ?Dissecting a >> package, analyzing the contents, looking for direct and potential >> problems, and providing feedback, is an immensely valuable activity. >> >>> Choosing the option of "no human release manager", is saying exactly that. >>> (if one presumes that people are choosing that option, with the >>> assumption that quality of packages will not suffer as a result) >> >> No human release manager means that there is no single person in >> power. ?It does not mean that packages aren't examined by a human. > > (I will point out that this is EXACTLY what Peter proposed: no-one > other than the maintainer would directly examine them before release, Yes and no. No one other than the maintainer would _have_ to directly examine packages before putting the package into unstable. However, the maintainer could ask another maintainer for a review of his package. Once the package gets into experimental and/or unstable, anybody who uses the package and notices a problem with it, can file a bug against the package, saying: "this package does not follow the policy in this place." If we then use the bug statistics to gate packages between, say, unstable and testing, or testing and stable, everyone can be a release manager. > How will they ever get examined by someone other than the maintainer, then? > Please propose something that is actually practical, rather than just ideal. > In the Real World, how will you ensure that packages are examined "by > a human[that is not just the maintainer themselves]" before release to > 'current'? I think it was about a release to unstable, rather than current. You're probably still thinking in the old model, while many people already think in terms of staged package catalogs. I don't think that the goal of providing high quality packages is contradictory with the idea of human-free release process. > What you wrote, seems to be contradictory. > if there is no human release manager, then there is no human looking > at packages before release. The term "release" needs to be slightly redefined. Instead of a quantum leap from "does not exist in the outer world" to "released to everyone", we would have stages that each package undergoes, at each stage reaching a slightly wider audience. > perhaps you meant "no SINGLE release manager", but that's not what you wrote :-) Yes, it's about many people participating in staged releases. I believe that there being a single person with discretionary control over releases is not a good thing. From maciej at opencsw.org Tue Nov 23 13:14:45 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 23 Nov 2010 12:14:45 +0000 Subject: [csw-maintainers] Maintainer tools Message-ID: <AANLkTinR+Q0aCZY8mDmo5XZkc_VoiRo1gCgYsLW7O0NK@mail.gmail.com> I've started a wiki page a while ago, with the list of our maintainer tools. It currently lists GAR, checkpkg, and a couple of scripts I wrote. The page is meant for maintainers to learn about our toolset -- what tools exist, and what they can be used for. http://wiki.opencsw.org/maintainer-tools If anyone has any other tools that they think other maintainers could find useful, please include them on the wiki! If you don't have the wiki account, please send the info to me, and I'll update the wiki (although no timely wiki editing service is guaranteed from me!). Maciej From pfelecan at opencsw.org Tue Nov 23 14:09:38 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 23 Nov 2010 14:09:38 +0100 Subject: [csw-maintainers] Maintainer tools In-Reply-To: <AANLkTinR+Q0aCZY8mDmo5XZkc_VoiRo1gCgYsLW7O0NK@mail.gmail.com> (Maciej Blizinski's message of "Tue, 23 Nov 2010 12:14:45 +0000") References: <AANLkTinR+Q0aCZY8mDmo5XZkc_VoiRo1gCgYsLW7O0NK@mail.gmail.com> Message-ID: <x639qs425p.fsf@opencsw.org> "Maciej (Matchek) Blizinski" <maciej at opencsw.org> writes: > I've started a wiki page a while ago, with the list of our maintainer > tools. It currently lists GAR, checkpkg, and a couple of scripts I > wrote. The page is meant for maintainers to learn about our toolset > -- what tools exist, and what they can be used for. > > http://wiki.opencsw.org/maintainer-tools > > If anyone has any other tools that they think other maintainers could > find useful, please include them on the wiki! If you don't have the > wiki account, please send the info to me, and I'll update the wiki > (although no timely wiki editing service is guaranteed from me!). I remember that the topic of unifying the different sources of information about our community was discussed already. However, nothing changed with the exception of the web server content which, being WordPress, can be easily enriched and point toward a external wiki, currently at wikidot, or, even better, to an internal one. How about using the WordPress core features to have all this disseminated article articles on our main server? -- Peter From dam at opencsw.org Tue Nov 23 14:24:23 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 23 Nov 2010 14:24:23 +0100 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <B5DC69A7-2B81-4442-8E6B-32EF4A8EE23F@opencsw.org> References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> <AANLkTinumvsFih1yERKyFJytLOc2zJBb4QL4vRdz7K27@mail.gmail.com> <AANLkTin1Y9Y2GPWVWh5YzqdPPUyY_k8T9Cgq=n4A9721@mail.gmail.com> <38930B84-F102-4DA7-9C80-98303342C1B1@opencsw.org> <AANLkTi=mhu50Q_EAmQ090WiQN3Bs-kZf=cPUbyPAvPXu@mail.gmail.com> <8E6B140A-2F7A-42ED-BDFE-D378E558EE6A@opencsw.org> <AANLkTi=xfF6FHE2bSiHXGnrkyTxUqT8mWdw9i7K7tH1o@mail.gmail.com> <AANLkTi=ek4qmdTURMmCdE35+7W=1Jm3ENLfZNvorjHTP@mail.gmail.com> <B5DC69A7-2B81-4442-8E6B-32EF4A8EE23F@opencsw.org> Message-ID: <16D1F716-2E4F-4C99-A0A2-C2F50F770C53@opencsw.org> Hi Phil, I just got an interesting example so I do post this myself now :-) On Friday, November 19, 2010, Philip Brown <phil at bolthole.com> wrote: > On 11/19/10, Dagobert Michelsen <dam at opencsw.org> wrote: >> Hi Phil, >> >> Am 19.11.2010 um 20:43 schrieb Philip Brown: >>> Note, this is off-list, because I didnt want to needlessly extend an >>> already huge thread, further, if not neccessary :) >>> >>> >>> On 11/19/10, Dagobert Michelsen <dam at opencsw.org> wrote: >>>> ..... >>> >> >> That means: >> - CSWlibxyz may depend on CSWlibxyz-legacy containing legacy libs >> as needed by existing packages >> - CSWlibxyz may depend on CSWlibxyzM and CSWlibxyzN etc. >> - CSWlibxyz must depend on the latest CSWlibxyzZ as it matches -devel >> - CSWlibxyz must depend on CSWlibxyz-devel >> >> In short: CSWlibxyz gets you everything. The name will also be used to >> track bugs for every CSWlibxyz* package and libxyz/ should be the GAR >> directory name. >> > > sounds like we mostly agree. The only difference left is that I dont > like the idea of literally HUNDREDS of empty "CSWlibxyz" packages. I'd > like for them to be actually have some useful content. > > seems to me like having them take on the role of "devel" for "current > version of lib" is a useful thing for them to be doing. I just finished libemf which has an interesting issue which I suggest to split like this: CSWlibemf-devel contains the header files and *.so CSWlibemf1 contains libemf.so.1.0.0 CSWlibemf contains /opt/csw/bin/printemf as part of the lib package Also CSWlibemf depends on both CSWlibemf-devel and CSWlibemf1. Would this be satisfactory? Or better leave the (unnecessary) dependency to CSWlibemf-devel and just depend on the latest runtime lib? Best regards -- Dago From dam at opencsw.org Tue Nov 23 16:24:04 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 23 Nov 2010 16:24:04 +0100 Subject: [csw-maintainers] Naming and layout of libnet packages In-Reply-To: <ED2945A9-DEE0-46B2-8E6A-9E5969F6F434@opencsw.org> References: <201011171610.oAHGAUls000290@login.bo.opencsw.org> <AANLkTi=Rr4EBAEtwdbnKtM0Vp54ZtG6-BmOj7w-b6oW5@mail.gmail.com> <008C0724-E797-4FBF-A85D-25EF610C9AE1@opencsw.org> <AANLkTimTuzD_W7FT53rkgcLcMG0hSRJHSjkEZt+Suw8x@mail.gmail.com> <ED2945A9-DEE0-46B2-8E6A-9E5969F6F434@opencsw.org> Message-ID: <CFB04E46-CD36-4B89-86B2-32F77431A103@opencsw.org> Hi, (reposting to maintainers@ for general package naming discussion) Best regards -- Dago Am 19.11.2010 um 10:54 schrieb Dagobert Michelsen: > Hi Phil, > > Am 18.11.2010 um 22:51 schrieb Philip Brown: >> On 11/18/10, Dagobert Michelsen <dam at opencsw.org> wrote: >>> Am 17.11.2010 um 18:57 schrieb Philip Brown: >>>> Two comments: >>>> >>>> 1. the SONAME is libnet.so.1 >>> >>> Partly correct. The SONAME of libnet.so.1.0.2 is libnet.so which is >>> the one all existing packages link to: >>> http://www.opencsw.org/packages/libnet >> >> For other peoples' benefit, here is full information: >> >> 1. OLD "libnet" package contained a libnet.so* file, which other >> programs required >> as only "libnet.so" >> >> 2. The "real filename" of the old package was libnet.so.1.0.2. >> However, that is kinda irrelevant since nothing referenced it directly >> as such >> >> 3. NEW "libnet", contains a symlink "libnet.so.1.0.2". > > Umh, no. /opt/csw/lib/libnet.so.1.0.2 is a file as always and libnet.so > is a symlink pointing to it as always. > >> This is, as I >> mentioned, completely irrelevent, since no "old" stuff uses it,and >> "new" stuff has libnet.so.1.6.0 > > I think it is good to have libnet.so pointing to libnet.so.1.0.2 to > make it explicit what version libnet.so is pointing to instead of > having just a file libnet.so with the contents of libnet.so.1.0.2 > in it. > >> 4. NEW "libnet" has an actual SONAME of "libnet.so.1" > > Right. > >>>> Why do you then provide a symlink >>>> /opt/csw/lib/libnet.so=libnet.so.1.0.2 >>>> It would seem to be completely unneccessary. >>> >>> Just for clarity. I could put the libnet.so.1.0.2 directly in >>> libnet.so without loss of functionality, but personally I prefer to >>> make the version explicit as there is no other place where you >>> can see the library version. >> >> clarity of what? I Dont Get It. >> And speaking of "I Dont Get It"... I also dont get what provides the >> backwards capability for older stuff needing libnet.so. >> >> oh wait, I didnt notice that you provide the actual binary compat lib >> in "libnet", in addition to the symlink. > > Yes. > >> Justaminute... Even though I'm suggesting not following the proposed >> standards.. doesnt your implementation, break the proposed standards >> too? :) > > Probably, because it is a legacy library and does not have a SONAME anyway. > >> Seems like CSWlibnet, should depend on a new "CSWlibnet0" for now: >> Then that, and only that, should have the older compat >> libnet.so.1.0.2, and libnet.so symlink to it. > > ...which would break the standards too as .so should be in _devel. > But again, libnet is not a standard library. It is a legacy piece > of crap where the library broke even existing SONAME standards. > >>>> 2. Given that this is a "lib" package... having "lib_devel" would seem >>>> to be redundant. >>>> What do you think of my addendum to the wiki proposal, where for >>>> 'lib*' packages specifically, we just put the "devel" stuff in the >>>> straight "lib" package? >>> >>> I don't like it because the devel part of some libraries are excessively >>> large where you would like to keep the devel package. >> >> I may be missing something here. >> >> What I'm seeing, is that if we stuck to the proposal,it would mean: >> >> applications that need the lib, would depend on CSWlibfoo#-#-#. >> They would not pull in CSWlibfoo-devel, or anything else. To compile >> stuff, people have to add in CSWlibfoo-devel > > Correct. > >> What I an suggesting is almost identical: >> applications that need the lib, would depend on CSWlibfoo#-#-#. >> They would not pull in CSWlibfoo, or anything else. To compile stuff, >> people have to add in CSWlibfoo > > This would be good if all libraries would play well. A ton of packages > depends on CSWlibnet, so that one must contain the old libnet.so. If you > want to add the devel stuff to CSWlibnet that is doable, but it would be > the devel-files **from the new** libnet library. Personally I would find > this very confusing. > >> To me, this makes contextual sense, because if a user explicitly wants >> to use "libfoo" directly, they can say "I want libfoo installed", aka >> "pkg-get install libfoo", and be ready to go. The "_devel" part is >> redundant to a library package, if you've already split out the actual >> shared library itself to a different package. >> >> I dont see how a user ever ends up with 'devel' type stuff that they >> dont need, in either case shown above. > > As I said: existing packages depend on CSWlibnet which would then > contain devel-stuff from another version. Additionally, having > a clean _devel-policy like "if you want to compile x you must install > x_devel" is very simple and could be even be made an automated > check, but only if done consistently. > >>> One more argument for having a separate devel: When we split out >>> real libraries like CSWlibnet1 containing libnet.so.1.1.5 the >>> merging of devel in there makes some of the advantages useless. >>> When some libnet.so.2.x comes out CSWlibnet1 would need to be respun >>> to rip out the devel stuff as this would now be shipped in CSWlibnet2. >> >> well yes. IF (andonly if) we thought it advantageous to be able to >> develop on both versions of the library, we would want to maintain >> "libnet1", and "libnet2" > > We don't want this. And I don't see how this related to my statement. > Putting devel together with a library will lead to repackaging > of the library package if another SONAME comes out as the devel > part needs to be relocated to the new package, so both need to > be rebuilt. *Not* to rebuild all packages is one of the goals > of the library suffixing with the so-number. > >> However, in most sane cases, we only care about development with "the >> latest" version of something. So do most people. >> Again, if they want to pull in "libfoo" to compile with, they probably >> are just using some kind of general requirement, and dont really want >> to think about "well, I need to get 'libfoo-vx-y. IF it's available. >> oh wait, opencsw doesnt have that yet. Hmm.. I wonder what version >> they have.. .checking... okay I'll specifically select libfoo-x-y to >> install now'". >> >> Kinda annoying. I'm thinking most users are just ripping through >> compile requirements, and they just want to "get the latest". >> So having "CSWlibfoo" track to "development for 'the latest' libfoo", >> I see as a feature for the users, rather than a negative overall. > > I don't see how this is more difficult than to say "If I want to > develop with libfoo I need to install CSWlibfoo-devel". > >> So to be more explicit, I'm suggesting that, *specifically for library >> packages only", >> "libfoo" contains >> - a dependancy on the latest shared library version we support >> - the dev files to compile against it. >> >> Does that sound more appealing? > > In general this sounds not too bad, but > - it is really bad for legacy libraries like libnet > - it is not consistent to have _devel for some packages but not for others. > > Having a consistent _devel would allow something like "List all CSW > packages and install <pkg>-devel" and everything will work. > > > Best regards > > -- Dago > > _______________________________________________ > pkgsubmissions mailing list > pkgsubmissions at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/pkgsubmissions From maciej at opencsw.org Wed Nov 24 00:44:39 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 23 Nov 2010 23:44:39 +0000 Subject: [csw-maintainers] Documentation consolidation - wiki, trac, wordpress Message-ID: <AANLkTinjYfACUEf-DOt3450GRSyEGn9UixqqzJzQuU+X@mail.gmail.com> No dia 23 de Novembro de 2010 13:09, Peter FELECAN <pfelecan at opencsw.org> escreveu: > I remember that the topic of unifying the different sources of > information about our community was discussed already. However, nothing > changed with the exception of the web server content which, being > WordPress, can be easily enriched and point toward a external wiki, > currently at wikidot, or, even better, to an internal one. How about > using the WordPress core features to have all this disseminated > article articles on our main server? We could start driving everything to wordpress, although I have to say that I generally like wikidot more than the wordpress editor, especially for things like documentation. I find myself more effective writing wikidot markup, as opposed to the wysiwyg/html editor in wordpress. I thought that we could keep our project external documents and news on wordpress, while keeping the working maintainer documentation on the wiki. The wiki also provides an API that Dago already uses. We have integrations between wiki and irc - ceeswi sends notifications about changes on the wiki. These are the arguments for wiki. I'm not saying we should definitely keep on using it. I think that just the fact that there is more than one place / domain we keep our material, is not that much of a problem. Back in the day when I talked about this, I mentioned that links were assymetric: trac and wikidot linked to each other and to opencsw.org, but opencsw.org linked to no others. Which was a shame, becase opencsw.org was the main landing page for the project. But this has changed, and we now have links between all these sites. I think that the two important issues are: - interlinking - documentation updates Whether we use wikidot or wordpress is secondary. What do others think? From jgoerzen at opencsw.org Wed Nov 24 00:56:21 2010 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Tue, 23 Nov 2010 15:56:21 -0800 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTik=_qycu1fanHTLbwD8SSrCDcKe+5mbpHoRY851@mail.gmail.com> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> <AANLkTik=_qycu1fanHTLbwD8SSrCDcKe+5mbpHoRY851@mail.gmail.com> Message-ID: <4CEC54A5.5060709@opencsw.org> On 11/23/2010 4:08 AM, Maciej (Matchek) Blizinski wrote: > No dia 20 de Novembro de 2010 19:46, Philip Brown<phil at bolthole.com> escreveu: >> On Sat, Nov 20, 2010 at 6:26 AM, Maciej (Matchek) Blizinski >> <maciej at opencsw.org> wrote: >>> (Apologies, I hit "send" too early. Here's a proofread version.) >>> ... >>> >>> For example, package consulting is hugely important. Dissecting a >>> package, analyzing the contents, looking for direct and potential >>> problems, and providing feedback, is an immensely valuable activity. >>> >>>> Choosing the option of "no human release manager", is saying exactly that. >>>> (if one presumes that people are choosing that option, with the >>>> assumption that quality of packages will not suffer as a result) >>> No human release manager means that there is no single person in >>> power. It does not mean that packages aren't examined by a human. >> (I will point out that this is EXACTLY what Peter proposed: no-one >> other than the maintainer would directly examine them before release, > Yes and no. No one other than the maintainer would _have_ to directly > examine packages before putting the package into unstable. However, > the maintainer could ask another maintainer for a review of his package. > > Once the package gets into experimental and/or unstable, anybody who > uses the package and notices a problem with it, can file a bug against > the package, saying: "this package does not follow the policy in this > place." If we then use the bug statistics to gate packages between, > say, unstable and testing, or testing and stable, everyone can be a > release manager. > >> How will they ever get examined by someone other than the maintainer, then? >> Please propose something that is actually practical, rather than just ideal. >> In the Real World, how will you ensure that packages are examined "by >> a human[that is not just the maintainer themselves]" before release to >> 'current'? > I think it was about a release to unstable, rather than current. > You're probably still thinking in the old model, while many people > already think in terms of staged package catalogs. > > I don't think that the goal of providing high quality packages is > contradictory with the idea of human-free release process. > >> What you wrote, seems to be contradictory. >> if there is no human release manager, then there is no human looking >> at packages before release. > The term "release" needs to be slightly redefined. Instead of a > quantum leap from "does not exist in the outer world" to "released to > everyone", we would have stages that each package undergoes, at each > stage reaching a slightly wider audience. > >> perhaps you meant "no SINGLE release manager", but that's not what you wrote :-) > Yes, it's about many people participating in staged releases. I > believe that there being a single person with discretionary control > over releases is not a good thing. > What about the experimental branch? Isn't the experimental branch exactly what you are getting at? The package maintainer can "release" here directly themselves and the package is available world wide through the automatically generated experimental catalog every 5 minutes. In my opinion having release manager with lots of experience and dedication is a good thing. Kind regards, Jake From phil at bolthole.com Wed Nov 24 04:11:40 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 23 Nov 2010 19:11:40 -0800 Subject: [csw-maintainers] Final feedback for putting in GAR/repository info into our mysql db In-Reply-To: <20101123102806.GF28050@sebastiankayser.de> References: <AANLkTimHa35+QjJx0FFmLDjcvfz=pGFdc2h=uSWG-GiB@mail.gmail.com> <5CA5AA66-A74A-4FF9-A6CE-F7E7C707027A@opencsw.org> <AANLkTim0asmfs1qzeRWsiknQgWsLxE66d_Vat-ngaA3O@mail.gmail.com> <9AA59E51-9948-43D7-9571-E38B87BCB6F2@opencsw.org> <20101123102806.GF28050@sebastiankayser.de> Message-ID: <AANLkTinPb_SNaSxTP4nP9erYnRVv0jnpniS5+oRmDvTk@mail.gmail.com> >> > and I also took the liberty of back-registering packages released in >> > the last 100 days. > > Thanks. Any problem with simply processing all packages? unfortunately yes. the reg routine is embedded in the official script which has various checks in it. not all packages actually pass all current checks From maciej at opencsw.org Wed Nov 24 08:01:47 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 24 Nov 2010 07:01:47 +0000 Subject: [csw-maintainers] Removing old packages from the OS In-Reply-To: <AANLkTi=0jDkdDii4m0M61E304R=ipgGRN1bu-JOoYP_=@mail.gmail.com> References: <AANLkTi=0jDkdDii4m0M61E304R=ipgGRN1bu-JOoYP_=@mail.gmail.com> Message-ID: <AANLkTinXEhtaMAq1M5Mh4ia__u+QnPuSOYFOfYn+7KM4@mail.gmail.com> No dia 20 de Novembro de 2010 12:26, Maciej (Matchek) Blizinski <maciej at opencsw.org> escreveu: > in general, what is the typical package removal scenario for an OpenCSW user? ping? From maciej at opencsw.org Wed Nov 24 08:25:39 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 24 Nov 2010 07:25:39 +0000 Subject: [csw-maintainers] [csw-users] important change: length of software names In-Reply-To: <AANLkTikON6shusp8OcCcqPy16=5MXju_fChhnQNkyj+U@mail.gmail.com> References: <AANLkTi=+HqXBP_4Jxe8u-ze_-J7XFzU-34qPt1+LMFfD@mail.gmail.com> <9EAC9604-37ED-471E-A602-97380AAADD6C@opencsw.org> <AANLkTimAkbapPb8kmZVj8tzMXmcY8U45HjcksjEV9G5W@mail.gmail.com> <AANLkTimQ3YXSdNr1Ka1Tg3KQQ-OxyrEHCHtva7nAXXcp@mail.gmail.com> <AANLkTinJMjjGDvc_DOcHzTansh=qkE_0Z5bms1SLrh5T@mail.gmail.com> <AANLkTikskGTCmJWsC=QWZ6Do5T_CddqH2MRzAxRzaimU@mail.gmail.com> <AANLkTikON6shusp8OcCcqPy16=5MXju_fChhnQNkyj+U@mail.gmail.com> Message-ID: <AANLkTikF=Md0nNFKkgGNg7wx9xk=xQQW5YdjJoBwHAtJ@mail.gmail.com> No dia 18 de Novembro de 2010 17:09, Philip Brown <phil at bolthole.com> escreveu: > On 11/17/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: >> No dia 16 de Novembro de 2010 18:52, Philip Brown <phil at bolthole.com> >> escreveu: >>> Since people had recently already submitted packages longer than 20 >>> chars, I thought there was no need for further coordination :-} >> >> Can we coordinate these kinds of changes in the future? >> > > I'm usually all about coordination :) So sure thing. > I'm just not sure what you think we missed out on, with this particular case. > > You couldnt make the change on 'your end', until the database and my > registration scripts were changed. ?But i'm not sure what the problem > is in the other direction. I dont see what we "lost", if the gar-side > changes were made a week after the database change, as compared to the > same day. You could imagine a maintainer who reads the announcement, updates his local copy of the repository, attempts to build a package, and gets an error message that his 21 character long package name exceeds the allowed length. Confusion: if he can't create such package, why the announcement? If the announcement is real, why can't he? I don't know if this scenario actually happened, but chances are it did. From dam at opencsw.org Wed Nov 24 09:13:03 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 24 Nov 2010 09:13:03 +0100 Subject: [csw-maintainers] Removing old packages from the OS In-Reply-To: <AANLkTinXEhtaMAq1M5Mh4ia__u+QnPuSOYFOfYn+7KM4@mail.gmail.com> References: <AANLkTi=0jDkdDii4m0M61E304R=ipgGRN1bu-JOoYP_=@mail.gmail.com> <AANLkTinXEhtaMAq1M5Mh4ia__u+QnPuSOYFOfYn+7KM4@mail.gmail.com> Message-ID: <E366FFCD-8BE5-4583-8AB0-ED9C070ABCE3@opencsw.org> Hi Maciej, Am 24.11.2010 um 08:01 schrieb Maciej (Matchek) Blizinski: > No dia 20 de Novembro de 2010 12:26, Maciej (Matchek) Blizinski > <maciej at opencsw.org> escreveu: >> in general, what is the typical package removal scenario for an OpenCSW user? > > ping? pkgrm <package>? Kidding aside, I rarely remove a CSW package, mostly because it probably has pulled in large dependencies which I am not aware of and removing just a single package doesn't gain much and finding the unnecessary dependencies later is hard. Best regards -- Dago From pfelecan at opencsw.org Wed Nov 24 09:40:26 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 24 Nov 2010 09:40:26 +0100 Subject: [csw-maintainers] Documentation consolidation - wiki, trac, wordpress In-Reply-To: <AANLkTinjYfACUEf-DOt3450GRSyEGn9UixqqzJzQuU+X@mail.gmail.com> (Maciej Blizinski's message of "Tue, 23 Nov 2010 23:44:39 +0000") References: <AANLkTinjYfACUEf-DOt3450GRSyEGn9UixqqzJzQuU+X@mail.gmail.com> Message-ID: <x6hbf72jyd.fsf@opencsw.org> "Maciej (Matchek) Blizinski" <maciej at opencsw.org> writes: > No dia 23 de Novembro de 2010 13:09, Peter FELECAN > <pfelecan at opencsw.org> escreveu: >> I remember that the topic of unifying the different sources of >> information about our community was discussed already. However, nothing >> changed with the exception of the web server content which, being >> WordPress, can be easily enriched and point toward a external wiki, >> currently at wikidot, or, even better, to an internal one. How about >> using the WordPress core features to have all this disseminated >> article articles on our main server? >[...] > I think that just the fact that there is more than one place / domain > we keep our material, is not that much of a problem. Back in the day > when I talked about this, I mentioned that links were assymetric: trac > and wikidot linked to each other and to opencsw.org, but opencsw.org > linked to no others. Which was a shame, becase opencsw.org was the > main landing page for the project. But this has changed, and we now > have links between all these sites. This is true now. But having advertisements just after "Welcome to the OpenCSW wiki" is polluting, as is every other advertisements on all the pages. > I think that the two important issues are: > - interlinking > - documentation updates > Whether we use wikidot or wordpress is secondary. I agree. However, having everything under one domain, being WordPress or Wiki, makes things easier and cleaner. -- Peter From bonivart at opencsw.org Wed Nov 24 10:20:44 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 24 Nov 2010 10:20:44 +0100 Subject: [csw-maintainers] Documentation consolidation - wiki, trac, wordpress In-Reply-To: <x6hbf72jyd.fsf@opencsw.org> References: <AANLkTinjYfACUEf-DOt3450GRSyEGn9UixqqzJzQuU+X@mail.gmail.com> <x6hbf72jyd.fsf@opencsw.org> Message-ID: <AANLkTik9dNGHDnpLFRyROL5kkuhJ2tT+XxidsB-odNaa@mail.gmail.com> On Wed, Nov 24, 2010 at 9:40 AM, Peter FELECAN <pfelecan at opencsw.org> wrote: > This is true now. But having advertisements just after "Welcome to the > OpenCSW wiki" is polluting, as is every other advertisements on all the > pages. It didn't use to be like that. When I registered the wiki it was optional to show ads but that has changed, now they require a paid alternative to be ad free. /peter From pfelecan at opencsw.org Wed Nov 24 11:05:31 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 24 Nov 2010 11:05:31 +0100 Subject: [csw-maintainers] Documentation consolidation - wiki, trac, wordpress In-Reply-To: <AANLkTik9dNGHDnpLFRyROL5kkuhJ2tT+XxidsB-odNaa@mail.gmail.com> (Peter Bonivart's message of "Wed, 24 Nov 2010 10:20:44 +0100") References: <AANLkTinjYfACUEf-DOt3450GRSyEGn9UixqqzJzQuU+X@mail.gmail.com> <x6hbf72jyd.fsf@opencsw.org> <AANLkTik9dNGHDnpLFRyROL5kkuhJ2tT+XxidsB-odNaa@mail.gmail.com> Message-ID: <x6d3pv2g0k.fsf@opencsw.org> Peter Bonivart <bonivart at opencsw.org> writes: > On Wed, Nov 24, 2010 at 9:40 AM, Peter FELECAN <pfelecan at opencsw.org> wrote: >> This is true now. But having advertisements just after "Welcome to the >> OpenCSW wiki" is polluting, as is every other advertisements on all the >> pages. > > It didn't use to be like that. When I registered the wiki it was > optional to show ads but that has changed, now they require a paid > alternative to be ad free. I remarked that. Unfortunately this is a current trend. An additional reason to move everything in one place. Maybe it will enhance our visibility through Google. -- Peter From bonivart at opencsw.org Wed Nov 24 11:14:52 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 24 Nov 2010 11:14:52 +0100 Subject: [csw-maintainers] Documentation consolidation - wiki, trac, wordpress In-Reply-To: <x6d3pv2g0k.fsf@opencsw.org> References: <AANLkTinjYfACUEf-DOt3450GRSyEGn9UixqqzJzQuU+X@mail.gmail.com> <x6hbf72jyd.fsf@opencsw.org> <AANLkTik9dNGHDnpLFRyROL5kkuhJ2tT+XxidsB-odNaa@mail.gmail.com> <x6d3pv2g0k.fsf@opencsw.org> Message-ID: <AANLkTimc8Ye=N6eaEei7e=Vx7VsLN7WTFa-ZgZfyMkR+@mail.gmail.com> On Wed, Nov 24, 2010 at 11:05 AM, Peter FELECAN <pfelecan at opencsw.org> wrote: > I remarked that. Unfortunately this is a current trend. An additional > reason to move everything in one place. Maybe it will enhance our > visibility through Google. If we want to we can embed this wiki into our own site. The wiki engine is open source and we should be able to host it ourselves. That would save us conversion to some other wiki format. /peter From pfelecan at opencsw.org Wed Nov 24 13:09:30 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 24 Nov 2010 13:09:30 +0100 Subject: [csw-maintainers] Documentation consolidation - wiki, trac, wordpress In-Reply-To: <AANLkTimc8Ye=N6eaEei7e=Vx7VsLN7WTFa-ZgZfyMkR+@mail.gmail.com> (Peter Bonivart's message of "Wed, 24 Nov 2010 11:14:52 +0100") References: <AANLkTinjYfACUEf-DOt3450GRSyEGn9UixqqzJzQuU+X@mail.gmail.com> <x6hbf72jyd.fsf@opencsw.org> <AANLkTik9dNGHDnpLFRyROL5kkuhJ2tT+XxidsB-odNaa@mail.gmail.com> <x6d3pv2g0k.fsf@opencsw.org> <AANLkTimc8Ye=N6eaEei7e=Vx7VsLN7WTFa-ZgZfyMkR+@mail.gmail.com> Message-ID: <x68w0i3oud.fsf@opencsw.org> Peter Bonivart <bonivart at opencsw.org> writes: > On Wed, Nov 24, 2010 at 11:05 AM, Peter FELECAN <pfelecan at opencsw.org> wrote: >> I remarked that. Unfortunately this is a current trend. An additional >> reason to move everything in one place. Maybe it will enhance our >> visibility through Google. > > If we want to we can embed this wiki into our own site. The wiki > engine is open source and we should be able to host it ourselves. That > would save us conversion to some other wiki format. Great. Do we have a package for that? (I think that all the tool that we use should be packaged for our target environment). I'm all in favor of hosting the wiki on our machines. -- Peter From bwalton at opencsw.org Wed Nov 24 15:05:22 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 24 Nov 2010 09:05:22 -0500 Subject: [csw-maintainers] Removing old packages from the OS In-Reply-To: <E366FFCD-8BE5-4583-8AB0-ED9C070ABCE3@opencsw.org> References: <AANLkTi=0jDkdDii4m0M61E304R=ipgGRN1bu-JOoYP_=@mail.gmail.com> <AANLkTinXEhtaMAq1M5Mh4ia__u+QnPuSOYFOfYn+7KM4@mail.gmail.com> <E366FFCD-8BE5-4583-8AB0-ED9C070ABCE3@opencsw.org> Message-ID: <1290607481-sup-4769@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Nov 24 03:13:03 -0500 2010: > Kidding aside, I rarely remove a CSW package, mostly because it > probably has pulled in large dependencies which I am not aware of > and removing just a single package doesn't gain much and finding the > unnecessary dependencies later is hard. I'm generally the same. Every now and then I may remove something via pkgrm if I know that it's a leaf node in the dep chain and I was just testing it out... -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Wed Nov 24 15:43:09 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 24 Nov 2010 14:43:09 +0000 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <16D1F716-2E4F-4C99-A0A2-C2F50F770C53@opencsw.org> References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> <AANLkTinumvsFih1yERKyFJytLOc2zJBb4QL4vRdz7K27@mail.gmail.com> <AANLkTin1Y9Y2GPWVWh5YzqdPPUyY_k8T9Cgq=n4A9721@mail.gmail.com> <38930B84-F102-4DA7-9C80-98303342C1B1@opencsw.org> <AANLkTi=mhu50Q_EAmQ090WiQN3Bs-kZf=cPUbyPAvPXu@mail.gmail.com> <8E6B140A-2F7A-42ED-BDFE-D378E558EE6A@opencsw.org> <AANLkTi=xfF6FHE2bSiHXGnrkyTxUqT8mWdw9i7K7tH1o@mail.gmail.com> <AANLkTi=ek4qmdTURMmCdE35+7W=1Jm3ENLfZNvorjHTP@mail.gmail.com> <B5DC69A7-2B81-4442-8E6B-32EF4A8EE23F@opencsw.org> <16D1F716-2E4F-4C99-A0A2-C2F50F770C53@opencsw.org> Message-ID: <AANLkTik+qxsDUEzLDtUtA0RbnifpVgT2EMergPu_kimh@mail.gmail.com> There's an issue that the proposal hasn't addressed so far: Package names for two packages with the same soname. One example could be a Sun compiler and GCC versions of a C++ library. Both compilations will result in the same soname. Should we try to achieve a standard naming technique for these? For example: CSWlibfoo1 for the Sun one CSWlibfoo1-gcc for the GCC one Or, more generally, how should the new package differentiate from the previous one - by adding a prefix, or a postfix? Should the pre/postfix have a certain format, such as: "only [a-z], up to 3 chars", etc? Thoughts? From maciej at opencsw.org Wed Nov 24 15:32:01 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 24 Nov 2010 14:32:01 +0000 Subject: [csw-maintainers] Removing old packages from the OS In-Reply-To: <1290607481-sup-4769@pinkfloyd.chass.utoronto.ca> References: <AANLkTi=0jDkdDii4m0M61E304R=ipgGRN1bu-JOoYP_=@mail.gmail.com> <AANLkTinXEhtaMAq1M5Mh4ia__u+QnPuSOYFOfYn+7KM4@mail.gmail.com> <E366FFCD-8BE5-4583-8AB0-ED9C070ABCE3@opencsw.org> <1290607481-sup-4769@pinkfloyd.chass.utoronto.ca> Message-ID: <AANLkTimSSQucNLcvMPfbS8+BqoLzgO59CKahdfX6jAiu@mail.gmail.com> No dia 24 de Novembro de 2010 14:05, Ben Walton <bwalton at opencsw.org> escreveu: > Excerpts from Dagobert Michelsen's message of Wed Nov 24 03:13:03 -0500 2010: > >> Kidding aside, I rarely remove a CSW package, mostly because it >> probably has pulled in large dependencies which I am not aware of >> and removing just a single package doesn't gain much and finding the >> unnecessary dependencies later is hard. > > I'm generally the same. ?Every now and then I may remove something via > pkgrm if I know that it's a leaf node in the dep chain and I was just > testing it out... I see. In a package rename scenario, we don't have a package removal procedure then. If we had: OpenCSW: New packages, CSWfoo depending on CSWlibbar User: pkgutil -y -i CSWfoo CSWlibbar gets installed automatically. OpenCSW: We changed our mind, CSWlibbar is deprecated, CSWlibbaz has some of these files now User: pkgutil -u CSWfoo CSWlibbaz gets installed automatically Now the user has both CSWlibbar and CSWlibbaz. You can imagine scenario, where the presence of CSWlibbar could lead to problems, especially if we produce more packages under the assumption that CSWlibbar is gone. Do you guys think we should have a mechanism that make sure that CSWlibbar gets removed? From pfelecan at opencsw.org Wed Nov 24 16:33:57 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 24 Nov 2010 16:33:57 +0100 Subject: [csw-maintainers] Removing old packages from the OS In-Reply-To: <AANLkTimSSQucNLcvMPfbS8+BqoLzgO59CKahdfX6jAiu@mail.gmail.com> (Maciej Blizinski's message of "Wed, 24 Nov 2010 14:32:01 +0000") References: <AANLkTi=0jDkdDii4m0M61E304R=ipgGRN1bu-JOoYP_=@mail.gmail.com> <AANLkTinXEhtaMAq1M5Mh4ia__u+QnPuSOYFOfYn+7KM4@mail.gmail.com> <E366FFCD-8BE5-4583-8AB0-ED9C070ABCE3@opencsw.org> <1290607481-sup-4769@pinkfloyd.chass.utoronto.ca> <AANLkTimSSQucNLcvMPfbS8+BqoLzgO59CKahdfX6jAiu@mail.gmail.com> Message-ID: <x64ob63fdm.fsf@opencsw.org> "Maciej (Matchek) Blizinski" <maciej at opencsw.org> writes: > Do you guys think we should have a mechanism that make sure that > CSWlibbar gets removed? Absolutely; viz apt-get autoremove. -- Peter From pfelecan at opencsw.org Wed Nov 24 16:40:36 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 24 Nov 2010 16:40:36 +0100 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <AANLkTik+qxsDUEzLDtUtA0RbnifpVgT2EMergPu_kimh@mail.gmail.com> (Maciej Blizinski's message of "Wed, 24 Nov 2010 14:43:09 +0000") References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> <AANLkTinumvsFih1yERKyFJytLOc2zJBb4QL4vRdz7K27@mail.gmail.com> <AANLkTin1Y9Y2GPWVWh5YzqdPPUyY_k8T9Cgq=n4A9721@mail.gmail.com> <38930B84-F102-4DA7-9C80-98303342C1B1@opencsw.org> <AANLkTi=mhu50Q_EAmQ090WiQN3Bs-kZf=cPUbyPAvPXu@mail.gmail.com> <8E6B140A-2F7A-42ED-BDFE-D378E558EE6A@opencsw.org> <AANLkTi=xfF6FHE2bSiHXGnrkyTxUqT8mWdw9i7K7tH1o@mail.gmail.com> <AANLkTi=ek4qmdTURMmCdE35+7W=1Jm3ENLfZNvorjHTP@mail.gmail.com> <B5DC69A7-2B81-4442-8E6B-32EF4A8EE23F@opencsw.org> <16D1F716-2E4F-4C99-A0A2-C2F50F770C53@opencsw.org> <AANLkTik+qxsDUEzLDtUtA0RbnifpVgT2EMergPu_kimh@mail.gmail.com> Message-ID: <x6zksy20i3.fsf@opencsw.org> "Maciej (Matchek) Blizinski" <maciej at opencsw.org> writes: > There's an issue that the proposal hasn't addressed so far: > > Package names for two packages with the same soname. > > One example could be a Sun compiler and GCC versions of a C++ library. > Both compilations will result in the same soname. Should we try to > achieve a standard naming technique for these? For example: > > CSWlibfoo1 for the Sun one > CSWlibfoo1-gcc for the GCC one Isn't there a case when we need: CSWlibfoo1 for the Sun one CSWlibfoo1-gcc3 for the GCC 3 one CSWlibfoo1-gcc4 for the GCC 4 one > Or, more generally, how should the new package differentiate from the > previous one - by adding a prefix, or a postfix? Should the > pre/postfix have a certain format, such as: "only [a-z], up to 3 > chars", etc? Use only suffixes from a limited and well defined set, such as {gcc}. But, is there other use case for this? If this is the only use case, we can use a "-g" suffix, e.g., CSWlibfoo1-g -- Peter From bwalton at opencsw.org Wed Nov 24 17:32:47 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 24 Nov 2010 11:32:47 -0500 Subject: [csw-maintainers] Removing old packages from the OS In-Reply-To: <x64ob63fdm.fsf@opencsw.org> References: <AANLkTi=0jDkdDii4m0M61E304R=ipgGRN1bu-JOoYP_=@mail.gmail.com> <AANLkTinXEhtaMAq1M5Mh4ia__u+QnPuSOYFOfYn+7KM4@mail.gmail.com> <E366FFCD-8BE5-4583-8AB0-ED9C070ABCE3@opencsw.org> <1290607481-sup-4769@pinkfloyd.chass.utoronto.ca> <AANLkTimSSQucNLcvMPfbS8+BqoLzgO59CKahdfX6jAiu@mail.gmail.com> <x64ob63fdm.fsf@opencsw.org> Message-ID: <1290616327-sup-6760@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Wed Nov 24 10:33:57 -0500 2010: > Absolutely; viz apt-get autoremove. While this would be nice, it would require the storage of data above and beyond what the underlying pkg* tools currently do. Not impossible, but definitely a lot of extra work. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Wed Nov 24 17:47:26 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 24 Nov 2010 08:47:26 -0800 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <x6zksy20i3.fsf@opencsw.org> References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> <AANLkTinumvsFih1yERKyFJytLOc2zJBb4QL4vRdz7K27@mail.gmail.com> <AANLkTin1Y9Y2GPWVWh5YzqdPPUyY_k8T9Cgq=n4A9721@mail.gmail.com> <38930B84-F102-4DA7-9C80-98303342C1B1@opencsw.org> <AANLkTi=mhu50Q_EAmQ090WiQN3Bs-kZf=cPUbyPAvPXu@mail.gmail.com> <8E6B140A-2F7A-42ED-BDFE-D378E558EE6A@opencsw.org> <AANLkTi=xfF6FHE2bSiHXGnrkyTxUqT8mWdw9i7K7tH1o@mail.gmail.com> <AANLkTi=ek4qmdTURMmCdE35+7W=1Jm3ENLfZNvorjHTP@mail.gmail.com> <B5DC69A7-2B81-4442-8E6B-32EF4A8EE23F@opencsw.org> <16D1F716-2E4F-4C99-A0A2-C2F50F770C53@opencsw.org> <AANLkTik+qxsDUEzLDtUtA0RbnifpVgT2EMergPu_kimh@mail.gmail.com> <x6zksy20i3.fsf@opencsw.org> Message-ID: <AANLkTi=f86dSWkH_p6K3+uFe9PG_+BGi7HfgujH8Vw-G@mail.gmail.com> On 11/24/10, Peter FELECAN <pfelecan at opencsw.org> wrote: > > Use only suffixes from a limited and well defined set, such as {gcc}. > But, is there other use case for this? If this is the only use case, > we can use a "-g" suffix, e.g., CSWlibfoo1-g > we have an existing de-facto standard to add (*gcc) to package names, in multiple use cases. I think for clarity, we should continue our standard behaviour there rather than attempting to "save" 3 chars. From dam at opencsw.org Wed Nov 24 17:49:12 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 24 Nov 2010 17:49:12 +0100 Subject: [csw-maintainers] commentary on shared library naming proposal In-Reply-To: <AANLkTi=f86dSWkH_p6K3+uFe9PG_+BGi7HfgujH8Vw-G@mail.gmail.com> References: <AANLkTi=NkNFM7VAfGSqOd9WJNP8vVtjK8Ww0t2_-3G4O@mail.gmail.com> <AANLkTinumvsFih1yERKyFJytLOc2zJBb4QL4vRdz7K27@mail.gmail.com> <AANLkTin1Y9Y2GPWVWh5YzqdPPUyY_k8T9Cgq=n4A9721@mail.gmail.com> <38930B84-F102-4DA7-9C80-98303342C1B1@opencsw.org> <AANLkTi=mhu50Q_EAmQ090WiQN3Bs-kZf=cPUbyPAvPXu@mail.gmail.com> <8E6B140A-2F7A-42ED-BDFE-D378E558EE6A@opencsw.org> <AANLkTi=xfF6FHE2bSiHXGnrkyTxUqT8mWdw9i7K7tH1o@mail.gmail.com> <AANLkTi=ek4qmdTURMmCdE35+7W=1Jm3ENLfZNvorjHTP@mail.gmail.com> <B5DC69A7-2B81-4442-8E6B-32EF4A8EE23F@opencsw.org> <16D1F716-2E4F-4C99-A0A2-C2F50F770C53@opencsw.org> <AANLkTik+qxsDUEzLDtUtA0RbnifpVgT2EMergPu_kimh@mail.gmail.com> <x6zksy20i3.fsf@opencsw.org> <AANLkTi=f86dSWkH_p6K3+uFe9PG_+BGi7HfgujH8Vw-G@mail.gmail.com> Message-ID: <30CD6A84-9BF7-42E7-A0CA-BCC2A819D42A@opencsw.org> Hi, Am 24.11.2010 um 17:47 schrieb Philip Brown: > On 11/24/10, Peter FELECAN <pfelecan at opencsw.org> wrote: >> >> Use only suffixes from a limited and well defined set, such as {gcc}. >> But, is there other use case for this? If this is the only use case, >> we can use a "-g" suffix, e.g., CSWlibfoo1-g > > we have an existing de-facto standard to add (*gcc) to package names, > in multiple use cases. I think for clarity, we should continue our > standard behaviour there rather than attempting to "save" 3 chars. To enhance clarity I suggest adding -gcc and _gcc instead just concatenation which is also more homogenous to the new module naming (like CSWpm-* for modules). Best regards -- Dago From phil at bolthole.com Wed Nov 24 17:51:29 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 24 Nov 2010 08:51:29 -0800 Subject: [csw-maintainers] Removing old packages from the OS In-Reply-To: <AANLkTi=0jDkdDii4m0M61E304R=ipgGRN1bu-JOoYP_=@mail.gmail.com> References: <AANLkTi=0jDkdDii4m0M61E304R=ipgGRN1bu-JOoYP_=@mail.gmail.com> Message-ID: <AANLkTinter0N5tuk_7+RuQ-jfUL2GbBmnYSF4u3ENkVo@mail.gmail.com> On 11/20/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: > The issue of removing packages from the OS is important in 2 main cases: > > - package renames (pkgname changes) > - phasing out of old packages > > In the rename case, our method is to declare the old package > incompatible with the renamed package. For example: > > CSWbar (old package, removed from the catalog) > CSWfoo (new package) incompatible with CSWbar > > I'm not sure what's the plan for the user actions. I think that the > assumption is that users will read messages from pkgadd, and realize > that CSWbar should not be installed. Having realized that, they will > use their own tools to remove the old packages. I might be wrong > though. > > I remember a discussion on irc where Peter Bonivart mentioned that > pkgutil automatically removed the incompatible packages. Is that > true? I was staying out of this to let Peter B reply, but since he hasnt yet: >From almost day 1 of CSW, this was the normal behaviour of pkg-get. pkg-get removes packages that are declared conflicting with the current package being installed. pkgutil was, I am told, also updated to match this behaviour. So, doing these renames by declaring conflicts with obsolete packages, has the advantages of: 1. cleanup is automatic, when using pkg-get or pkgutil 2. it lets a user know beforehand, even if they are MANUALLY doing "pkgadd newpkg", (note: pkgadd, not pkg-get) that there is a conflict with older names, and they need to clean up first. From phil at bolthole.com Wed Nov 24 18:12:59 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 24 Nov 2010 09:12:59 -0800 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTik=_qycu1fanHTLbwD8SSrCDcKe+5mbpHoRY851@mail.gmail.com> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> <AANLkTik=_qycu1fanHTLbwD8SSrCDcKe+5mbpHoRY851@mail.gmail.com> Message-ID: <AANLkTin+2wi=e+WpGZ1sTxuQOM2dqnhm5zTTFq5TD8us@mail.gmail.com> On 11/23/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: > No dia 20 de Novembro de 2010 19:46, Philip Brown <phil at bolthole.com> > escreveu: >> (I will point out that this is EXACTLY what Peter proposed: no-one >> other than the maintainer would directly examine them before release, > > Yes and no. No one other than the maintainer would _have_ to directly > examine packages before putting the package into unstable. However, > the maintainer could ask another maintainer for a review of his package. > This is what I mean by "[something that works in the real world]". In the "Real World", almost no maintainer asks someone else for a review before releasing their package. So your, and Peter's proposal, will effectively result in packages getting directly released without any 3rd party review, for pretty much all future packages. > I think it was about a release to unstable, rather than current. Err.. unstable IS current. Maybe you mean experimental. But what is your proposal of migrating packages from experimental to current? > You're probably still thinking in the old model, while many people > already think in terms of staged package catalogs. > > I don't think that the goal of providing high quality packages is > contradictory with the idea of human-free release process. People have only to check through the now public pkgsubmissions archives, to see proof that this is false. Many problems with packages have been caught by the existing release process, that would not have been caught by a method of "only maintainer looks at it". You will probably reply by, "well users can always file a bug", to which my reply is, "users very rarely file bugs. it is more common for users to simply stop using the package and look elsewhere". I dont know about your definition of "high quality packages", but "maintainer releases what is 'good enough for them', and no-one else looks at it", definately does not fit my definition of it. From rupert at opencsw.org Wed Nov 24 18:50:14 2010 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 24 Nov 2010 18:50:14 +0100 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <4CEC54A5.5060709@opencsw.org> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> <AANLkTik=_qycu1fanHTLbwD8SSrCDcKe+5mbpHoRY851@mail.gmail.com> <4CEC54A5.5060709@opencsw.org> Message-ID: <AANLkTim5rkLtkoVz5ySkue2KhXU_ALTz0F52Y1MiiE3x@mail.gmail.com> On Wed, Nov 24, 2010 at 00:56, Jake Goerzen <jgoerzen at opencsw.org> wrote: > On 11/23/2010 4:08 AM, Maciej (Matchek) Blizinski wrote: > >> No dia 20 de Novembro de 2010 19:46, Philip Brown<phil at bolthole.com> >> escreveu: >> >>> On Sat, Nov 20, 2010 at 6:26 AM, Maciej (Matchek) Blizinski >>> <maciej at opencsw.org> wrote: >>> >>>> (Apologies, I hit "send" too early. Here's a proofread version.) >>>> ... >>>> >>>> For example, package consulting is hugely important. Dissecting a >>>> package, analyzing the contents, looking for direct and potential >>>> problems, and providing feedback, is an immensely valuable activity. >>>> >>>> Choosing the option of "no human release manager", is saying exactly >>>>> that. >>>>> (if one presumes that people are choosing that option, with the >>>>> assumption that quality of packages will not suffer as a result) >>>>> >>>> No human release manager means that there is no single person in >>>> power. It does not mean that packages aren't examined by a human. >>>> >>> (I will point out that this is EXACTLY what Peter proposed: no-one >>> other than the maintainer would directly examine them before release, >>> >> Yes and no. No one other than the maintainer would _have_ to directly >> examine packages before putting the package into unstable. However, >> the maintainer could ask another maintainer for a review of his package. >> >> Once the package gets into experimental and/or unstable, anybody who >> uses the package and notices a problem with it, can file a bug against >> the package, saying: "this package does not follow the policy in this >> place." If we then use the bug statistics to gate packages between, >> say, unstable and testing, or testing and stable, everyone can be a >> release manager. >> >> How will they ever get examined by someone other than the maintainer, >>> then? >>> Please propose something that is actually practical, rather than just >>> ideal. >>> In the Real World, how will you ensure that packages are examined "by >>> a human[that is not just the maintainer themselves]" before release to >>> 'current'? >>> >> I think it was about a release to unstable, rather than current. >> You're probably still thinking in the old model, while many people >> already think in terms of staged package catalogs. >> >> I don't think that the goal of providing high quality packages is >> contradictory with the idea of human-free release process. >> >> What you wrote, seems to be contradictory. >>> if there is no human release manager, then there is no human looking >>> at packages before release. >>> >> The term "release" needs to be slightly redefined. Instead of a >> quantum leap from "does not exist in the outer world" to "released to >> everyone", we would have stages that each package undergoes, at each >> stage reaching a slightly wider audience. >> >> perhaps you meant "no SINGLE release manager", but that's not what you >>> wrote :-) >>> >> Yes, it's about many people participating in staged releases. I >> believe that there being a single person with discretionary control >> over releases is not a good thing. >> >> What about the experimental branch? Isn't the experimental branch > exactly what you are getting at? The package maintainer can "release" here > directly themselves and the package is available world wide through the > automatically generated experimental catalog every 5 minutes. In my opinion > having release manager with lots of experience and dedication is a good > thing. > > i'd support this as well. then we have two stages, experimental and current/unstable. broken packages make users look for alternatives - many of them do not like to file bugs. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20101124/cfac0953/attachment.html> From phil at bolthole.com Wed Nov 24 19:07:01 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 24 Nov 2010 10:07:01 -0800 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTin+2wi=e+WpGZ1sTxuQOM2dqnhm5zTTFq5TD8us@mail.gmail.com> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> <AANLkTik=_qycu1fanHTLbwD8SSrCDcKe+5mbpHoRY851@mail.gmail.com> <AANLkTin+2wi=e+WpGZ1sTxuQOM2dqnhm5zTTFq5TD8us@mail.gmail.com> Message-ID: <AANLkTikSz6hAcEY8iowWq8TzjUV=TVDXKAMhuR=Zk3D9@mail.gmail.com> On 11/24/10, Philip Brown <phil at bolthole.com> wrote: > > I dont know about your definition of "high quality packages", but > "maintainer releases what is 'good enough for them', and no-one else > looks at it", definately does not fit my definition of it. To be clearer: I want the target that we aim at, to be, "high quality packages, EVERY TIME we release a package to current". Not, "we release packages often. The quality of packages cycles between low and high, based on how many people decide to file bugs against already released packages" From dam at opencsw.org Wed Nov 24 21:46:00 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 24 Nov 2010 21:46:00 +0100 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTin+2wi=e+WpGZ1sTxuQOM2dqnhm5zTTFq5TD8us@mail.gmail.com> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> <AANLkTik=_qycu1fanHTLbwD8SSrCDcKe+5mbpHoRY851@mail.gmail.com> <AANLkTin+2wi=e+WpGZ1sTxuQOM2dqnhm5zTTFq5TD8us@mail.gmail.com> Message-ID: <37BABF51-9E97-43E1-895F-AD071DDD9136@opencsw.org> Hi, Am 24.11.2010 um 18:12 schrieb Philip Brown: > On 11/23/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: >> No dia 20 de Novembro de 2010 19:46, Philip Brown <phil at bolthole.com> >> escreveu: >>> (I will point out that this is EXACTLY what Peter proposed: no-one >>> other than the maintainer would directly examine them before release, >> >> Yes and no. No one other than the maintainer would _have_ to directly >> examine packages before putting the package into unstable. However, >> the maintainer could ask another maintainer for a review of his package. > > This is what I mean by "[something that works in the real world]". > In the "Real World", almost no maintainer asks someone else for a > review before releasing their package. > > So your, and Peter's proposal, will effectively result in packages > getting directly released without any 3rd party review, for pretty > much all future packages. > > >> I think it was about a release to unstable, rather than current. > > Err.. unstable IS current. > Maybe you mean experimental. But what is your proposal of migrating > packages from experimental to current? There are two different things producing "quality": manual inspection and realworld usage. I could imagine a first-step trial for brave users with feedback and a second-step inspection to go to the next more stable release level. >> You're probably still thinking in the old model, while many people >> already think in terms of staged package catalogs. >> >> I don't think that the goal of providing high quality packages is >> contradictory with the idea of human-free release process. > > People have only to check through the now public pkgsubmissions > archives, to see proof that this is false. > Many problems with packages have been caught by the existing release > process, that would not have been caught by a method of "only > maintainer looks at it". > You will probably reply by, "well users can always file a bug", to > which my reply is, > "users very rarely file bugs. it is more common for users to simply > stop using the package and look elsewhere". > > I dont know about your definition of "high quality packages", but > "maintainer releases what is 'good enough for them', and no-one else > looks at it", definately does not fit my definition of it. Right, no maintainer however experienced is proof of making stupid mistakes (like me...) Best regards -- Dago From dam at opencsw.org Wed Nov 24 21:53:10 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 24 Nov 2010 21:53:10 +0100 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTikSz6hAcEY8iowWq8TzjUV=TVDXKAMhuR=Zk3D9@mail.gmail.com> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> <AANLkTik=_qycu1fanHTLbwD8SSrCDcKe+5mbpHoRY851@mail.gmail.com> <AANLkTin+2wi=e+WpGZ1sTxuQOM2dqnhm5zTTFq5TD8us@mail.gmail.com> <AANLkTikSz6hAcEY8iowWq8TzjUV=TVDXKAMhuR=Zk3D9@mail.gmail.com> Message-ID: <A78D5203-031E-473A-B03A-9F7E0E80D056@opencsw.org> Hi, Am 24.11.2010 um 19:07 schrieb Philip Brown: > On 11/24/10, Philip Brown <phil at bolthole.com> wrote: >> >> I dont know about your definition of "high quality packages", but >> "maintainer releases what is 'good enough for them', and no-one else >> looks at it", definately does not fit my definition of it. > > To be clearer: > I want the target that we aim at, to be, > "high quality packages, EVERY TIME we release a package to current". > > Not, "we release packages often. The quality of packages cycles > between low and high, based on how many people decide to file bugs > against already released packages" You statement is true for unstable (=current), but not experimental as outlined in http://wiki.opencsw.org/automated-release-process Best regards -- Dago From maciej at opencsw.org Wed Nov 24 22:34:17 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 24 Nov 2010 21:34:17 +0000 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTikSz6hAcEY8iowWq8TzjUV=TVDXKAMhuR=Zk3D9@mail.gmail.com> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> <AANLkTik=_qycu1fanHTLbwD8SSrCDcKe+5mbpHoRY851@mail.gmail.com> <AANLkTin+2wi=e+WpGZ1sTxuQOM2dqnhm5zTTFq5TD8us@mail.gmail.com> <AANLkTikSz6hAcEY8iowWq8TzjUV=TVDXKAMhuR=Zk3D9@mail.gmail.com> Message-ID: <AANLkTi=95_k8dM1oDbqt=9W88e5=sNkf+MQY8mXcz_Lt@mail.gmail.com> No dia 24 de Novembro de 2010 18:07, Philip Brown <phil at bolthole.com> escreveu: > On 11/24/10, Philip Brown <phil at bolthole.com> wrote: >> >> I dont know about your definition of "high quality packages", but >> "maintainer releases what is 'good enough for them', and no-one else >> looks at it", definately does not fit my definition of it. > > > To be clearer: > I want the target that we aim at, to be, > "high quality packages, EVERY TIME we release a package to current". You use the term "quality of packages" as if it was obvious what it means. When you think about it, it may be not obvious at all. Of course, there are things that are uncontroversial. If a binary segfaults, or there's a missing dependency, there's no doubt about whether this constitutes a high or a low quality. The problem can arise with issues which depend on personal taste. What is high quality for Phil Brown, may be low quality for Maciej Blizi?ski. If maintainers are forced to release packages which are, in their opinion, low quality packages, it demoralizes them. A single person in power can also hurt package quality. Imagine a scenario in which there is a package, which has two issues, let's call them A and B. The package is unmaintained, and one maintainer takes on the issue A, fixes it and submits the fix for release. The updated package is better than the previous one, but the release manager, using his discretionary powers, rejects the package, saying that the maintainer should fix issue B as well. The maintainer feels he's being controlled, the release manager believes he's right and insists, and both end up in a deadlock. This kind of an issue would not happen in a consensus driven community. The updated package would be released, and the issue B would get eventually fixed too. > Not, "we release packages often. The quality of packages cycles > between low and high, based on how many people decide to file bugs > against already released packages" Phil, I understand you mean well and you want packages to work well, and I want the same thing. But I believe that package quality should not be based on what Phil Brown (or any single person, for that matter) happens to think is right. It should be based on what the OpenCSW community agrees on. From bwalton at opencsw.org Thu Nov 25 02:22:37 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 24 Nov 2010 20:22:37 -0500 Subject: [csw-maintainers] svn help? Message-ID: <1290647989-sup-6671@pinkfloyd.chass.utoronto.ca> Hi All, I'm hoping someone can tell me why subversion is lying to me. I've seen it lie before, but this is the most blatant case I've seen: http://pastie.org/1324528 In two different svn:externals checkous of gar (git, mediawiki), I get different results from grepping the same file. You'll note that 'svn up' claims no changes from current upstream and indicates the same revision id. The 'svn st' indicates a clean working directory. Yikes! -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Nov 25 02:25:28 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 24 Nov 2010 20:25:28 -0500 Subject: [csw-maintainers] svn help? In-Reply-To: <1290647989-sup-6671@pinkfloyd.chass.utoronto.ca> References: <1290647989-sup-6671@pinkfloyd.chass.utoronto.ca> Message-ID: <1290648258-sup-9173@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Wed Nov 24 20:22:37 -0500 2010: > In two different svn:externals checkous of gar (git, mediawiki), I > get different results from grepping the same file. You'll note that > 'svn up' claims no changes from current upstream and indicates the > same revision id. The 'svn st' indicates a clean working directory. Oh, and in the stale mediawiki checkout of gar, I did: rm *mk; svn st; svn revert $(all *mk files listed in last command) It restored the incorrect version. Seriously...what is this thing doing? -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Nov 25 02:51:04 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 24 Nov 2010 20:51:04 -0500 Subject: [csw-maintainers] svn help? In-Reply-To: <1290648258-sup-9173@pinkfloyd.chass.utoronto.ca> References: <1290647989-sup-6671@pinkfloyd.chass.utoronto.ca> <1290648258-sup-9173@pinkfloyd.chass.utoronto.ca> Message-ID: <1290649818-sup-2412@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Wed Nov 24 20:25:28 -0500 2010: > It restored the incorrect version. Seriously...what is this thing > doing? Figured it out: bwalton @ current9x : ~/pkg/mediawiki/trunk $ svn propget svn:externals . gar https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2-relocate walton @ current9x : ~/pkg/git/trunk $ svn propget svn:externals . gar https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2 Different externals. :( -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Nov 25 08:33:00 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 25 Nov 2010 07:33:00 +0000 Subject: [csw-maintainers] Support for multiple Python versions In-Reply-To: <AANLkTim-f1wLdtn4zHHLCfYTkV4WNEQiL+OWS5P82jxw@mail.gmail.com> References: <AANLkTim-f1wLdtn4zHHLCfYTkV4WNEQiL+OWS5P82jxw@mail.gmail.com> Message-ID: <AANLkTi=R7QmFjNyzkqQ_pXiTO-6LuQKbBP9W4FBu5CDA@mail.gmail.com> No dia 15 de Outubro de 2010 01:00, Maciej (Matchek) Blizinski <maciej at opencsw.org> escreveu: > In the meantime, I've built Python 3.1 to try it out. ?It passed the > smoke test: can be installed alongside Python 2.6, with both 2.6 and > 3.1 versions working fine. > > If anyone is interested in testing and/or reviewing, here are the packages: > http://buildfarm.opencsw.org/experimental.html#python-3.1 I'd like to go forward with this. What are your thoughts on the Python 3.1 packages? Can I go ahead and submit them for release, or would you like to discuss the multiple Python versions some more? From pfelecan at opencsw.org Thu Nov 25 09:52:41 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 25 Nov 2010 09:52:41 +0100 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTin+2wi=e+WpGZ1sTxuQOM2dqnhm5zTTFq5TD8us@mail.gmail.com> (Philip Brown's message of "Wed, 24 Nov 2010 09:12:59 -0800") References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> <AANLkTik=_qycu1fanHTLbwD8SSrCDcKe+5mbpHoRY851@mail.gmail.com> <AANLkTin+2wi=e+WpGZ1sTxuQOM2dqnhm5zTTFq5TD8us@mail.gmail.com> Message-ID: <x6sjyp23ae.fsf@opencsw.org> Philip Brown <phil at bolthole.com> writes: > This is what I mean by "[something that works in the real world]". > In the "Real World", almost no maintainer asks someone else for a > review before releasing their package. > > So your, and Peter's proposal, will effectively result in packages > getting directly released without any 3rd party review, for pretty > much all future packages. you still didn't take into account the other distribution models, as I suggested: "[...]Look at the other distributions models and you'll see that there is not a serious one having an *unique* person doing discretionary release management.[...]" this thread is not only about human release management but also about how that role is accomplished: discretionarily. -- Peter From dam at opencsw.org Thu Nov 25 09:54:23 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 25 Nov 2010 09:54:23 +0100 Subject: [csw-maintainers] svn help? In-Reply-To: <1290649818-sup-2412@pinkfloyd.chass.utoronto.ca> References: <1290647989-sup-6671@pinkfloyd.chass.utoronto.ca> <1290648258-sup-9173@pinkfloyd.chass.utoronto.ca> <1290649818-sup-2412@pinkfloyd.chass.utoronto.ca> Message-ID: <BDA0D961-73A7-480B-8C71-E51CB0FA8FDD@opencsw.org> Hi Ben, Am 25.11.2010 um 02:51 schrieb Ben Walton: > Excerpts from Ben Walton's message of Wed Nov 24 20:25:28 -0500 2010: > >> It restored the incorrect version. Seriously...what is this thing >> doing? > > Figured it out: > > bwalton @ current9x : ~/pkg/mediawiki/trunk > $ svn propget svn:externals . > gar > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2-relocate > > walton @ current9x : ~/pkg/git/trunk > $ svn propget svn:externals . > gar https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2 > > > Different externals. :( Would you mind merging this branch into the main branch? Best regards -- Dago From bwalton at opencsw.org Thu Nov 25 14:41:06 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 25 Nov 2010 08:41:06 -0500 Subject: [csw-maintainers] svn help? In-Reply-To: <BDA0D961-73A7-480B-8C71-E51CB0FA8FDD@opencsw.org> References: <1290647989-sup-6671@pinkfloyd.chass.utoronto.ca> <1290648258-sup-9173@pinkfloyd.chass.utoronto.ca> <1290649818-sup-2412@pinkfloyd.chass.utoronto.ca> <BDA0D961-73A7-480B-8C71-E51CB0FA8FDD@opencsw.org> Message-ID: <1290692448-sup-3645@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Thu Nov 25 03:54:23 -0500 2010: > Would you mind merging this branch into the main branch? I can, but I don't even know what it is...? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Thu Nov 25 14:48:07 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 25 Nov 2010 14:48:07 +0100 Subject: [csw-maintainers] svn help? In-Reply-To: <1290692448-sup-3645@pinkfloyd.chass.utoronto.ca> References: <1290647989-sup-6671@pinkfloyd.chass.utoronto.ca> <1290648258-sup-9173@pinkfloyd.chass.utoronto.ca> <1290649818-sup-2412@pinkfloyd.chass.utoronto.ca> <BDA0D961-73A7-480B-8C71-E51CB0FA8FDD@opencsw.org> <1290692448-sup-3645@pinkfloyd.chass.utoronto.ca> Message-ID: <30486602-7D41-420E-995C-7CD525154731@opencsw.org> Hi Ben, Am 25.11.2010 um 14:41 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Thu Nov 25 03:54:23 -0500 2010: >> Would you mind merging this branch into the main branch? > > I can, but I don't even know what it is...? I can also take care of it. The idea was to generate relocatable packages not fixated to / as install base. Now I also saw why I couldn't remember: Because Mike did it :-) The changes look pretty straight-forward: https://sourceforge.net/apps/trac/gar/changeset?new=5214%40csw%2Fmgar%2Fgar%2Fv2-relocate&old=5027%40csw%2Fmgar%2Fgar%2Fv2-relocate Best regards -- Dago From bwalton at opencsw.org Fri Nov 26 02:27:46 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 25 Nov 2010 20:27:46 -0500 Subject: [csw-maintainers] Disabling git patching framework in gar Message-ID: <1290734807-sup-7079@pinkfloyd.chass.utoronto.ca> Hi All, I just added a toggle to the git patching framework for GAR. If you set the variable NOGITPATCH to a non-null value, you can turn off the git stuff that brackets the extract and patch steps. Let me know if you have any trouble with it. I'm about to go document it... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Fri Nov 26 09:12:16 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 26 Nov 2010 09:12:16 +0100 Subject: [csw-maintainers] Alternatives without automatic selection Message-ID: <8F38B2DD-5DCF-4674-9BFF-C0162C6D9E9A@opencsw.org> Hi, a question arose whetere it is allowed to have two alternatives with the same priority. The idea is this: If the priorities are the same the package which gets installed first is kept, irregardless if other alternatives are installed later. One usecase would be e.g. an MTA (like sendmail) which you deliberately install and configure. Than, later, some other program needs some other mailer which can act as MTA or MUA which should not override what you have already configured. You can of course always select alternatives manually. This has the consequence that programs must be installed in the same order they were removed as automatic same-prios are not persistently saved on alternative-selection. This may be necessary, though. Ideas? Best regards -- Dago From pfelecan at opencsw.org Fri Nov 26 09:36:03 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 26 Nov 2010 09:36:03 +0100 Subject: [csw-maintainers] Alternatives without automatic selection In-Reply-To: <8F38B2DD-5DCF-4674-9BFF-C0162C6D9E9A@opencsw.org> (Dagobert Michelsen's message of "Fri, 26 Nov 2010 09:12:16 +0100") References: <8F38B2DD-5DCF-4674-9BFF-C0162C6D9E9A@opencsw.org> Message-ID: <x6bp5c1nyk.fsf@opencsw.org> Dagobert Michelsen <dam at opencsw.org> writes: > Hi, > > a question arose whetere it is allowed to have two alternatives > with the same priority. The idea is this: If the priorities are > the same the package which gets installed first is kept, > irregardless if other alternatives are installed later. > One usecase would be e.g. an MTA (like sendmail) which you > deliberately install and configure. Than, later, some other > program needs some other mailer which can act as MTA or MUA > which should not override what you have already configured. > You can of course always select alternatives manually. > > This has the consequence that programs must be installed > in the same order they were removed as automatic same-prios > are not persistently saved on alternative-selection. > This may be necessary, though. > > Ideas? I'm not sure on what you're asking ideas... however, for the order of installation you have the installation date of the packages which gives you the order until an unsynchronized update is made; otherwise, the alternatives system can be enhanced to make persistent the alternative selection and priorities, if I'm understanding correctly, we now have a specific alternative system, isn't it? or is still based on the Linux one? -- Peter From dam at opencsw.org Fri Nov 26 09:41:06 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 26 Nov 2010 09:41:06 +0100 Subject: [csw-maintainers] Alternatives without automatic selection In-Reply-To: <x6bp5c1nyk.fsf@opencsw.org> References: <8F38B2DD-5DCF-4674-9BFF-C0162C6D9E9A@opencsw.org> <x6bp5c1nyk.fsf@opencsw.org> Message-ID: <41FC60D9-8F03-4C68-B539-17A282B28245@opencsw.org> Hi Peter, Am 26.11.2010 um 09:36 schrieb Peter FELECAN: > Dagobert Michelsen <dam at opencsw.org> writes: >> a question arose whetere it is allowed to have two alternatives >> with the same priority. The idea is this: If the priorities are >> the same the package which gets installed first is kept, >> irregardless if other alternatives are installed later. >> One usecase would be e.g. an MTA (like sendmail) which you >> deliberately install and configure. Than, later, some other >> program needs some other mailer which can act as MTA or MUA >> which should not override what you have already configured. >> You can of course always select alternatives manually. >> >> This has the consequence that programs must be installed >> in the same order they were removed as automatic same-prios >> are not persistently saved on alternative-selection. >> This may be necessary, though. >> >> Ideas? > > I'm not sure on what you're asking ideas... Would you consider same priorities a bug or a feature? > however, for the order of > installation you have the installation date of the packages which gives > you the order until an unsynchronized update is made; otherwise, the > alternatives system can be enhanced to make persistent the alternative > selection and priorities, ATM it is persistent *only* if the selection was done manually. If you have two packages pkg1 and pkg2 which are installed in order and provide "soft" with the same priority then pkg1.soft is selected and kept after installation of pkg2. If you update, pkg1 is removed and pkg2.soft is selected. On reinstallation of the newer pkg1 there is no switch-back until pkg2 is also removed. So even automatic selection should be noted and rolled back. > if I'm understanding correctly, we now have a > specific alternative system, isn't it? or is still based on the Linux > one? Yes, specific. CSW-custom-implemented. Best regards -- Dago From pfelecan at opencsw.org Fri Nov 26 10:06:28 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 26 Nov 2010 10:06:28 +0100 Subject: [csw-maintainers] Alternatives without automatic selection In-Reply-To: <41FC60D9-8F03-4C68-B539-17A282B28245@opencsw.org> (Dagobert Michelsen's message of "Fri, 26 Nov 2010 09:41:06 +0100") References: <8F38B2DD-5DCF-4674-9BFF-C0162C6D9E9A@opencsw.org> <x6bp5c1nyk.fsf@opencsw.org> <41FC60D9-8F03-4C68-B539-17A282B28245@opencsw.org> Message-ID: <x67hg01mjv.fsf@opencsw.org> Dagobert Michelsen <dam at opencsw.org> writes: > Hi Peter, > > Am 26.11.2010 um 09:36 schrieb Peter FELECAN: >> Dagobert Michelsen <dam at opencsw.org> writes: >>> a question arose whetere it is allowed to have two alternatives >>> with the same priority. The idea is this: If the priorities are >>> the same the package which gets installed first is kept, >>> irregardless if other alternatives are installed later. >>> One usecase would be e.g. an MTA (like sendmail) which you >>> deliberately install and configure. Than, later, some other >>> program needs some other mailer which can act as MTA or MUA >>> which should not override what you have already configured. >>> You can of course always select alternatives manually. >>> >>> This has the consequence that programs must be installed >>> in the same order they were removed as automatic same-prios >>> are not persistently saved on alternative-selection. >>> This may be necessary, though. >>> >>> Ideas? >> >> I'm not sure on what you're asking ideas... > > Would you consider same priorities a bug or a feature? Definitely a feature! You example shows it clearly. >> however, for the order of >> installation you have the installation date of the packages which gives >> you the order until an unsynchronized update is made; otherwise, the >> alternatives system can be enhanced to make persistent the alternative >> selection and priorities, > > ATM it is persistent *only* if the selection was done manually. > If you have two packages pkg1 and pkg2 which are installed in > order and provide "soft" with the same priority then > pkg1.soft is selected and kept after installation of pkg2. > If you update, pkg1 is removed and pkg2.soft is selected. > On reinstallation of the newer pkg1 there is no switch-back > until pkg2 is also removed. So even automatic selection should > be noted and rolled back. If we implement same priority alternatives and the order of installation is rendered persistent I think that the described use case is satisfied. >> if I'm understanding correctly, we now have a >> specific alternative system, isn't it? or is still based on the Linux >> one? > > Yes, specific. CSW-custom-implemented. At least we have the advantage to enhance it (although I was opposed to such a specific implementation now I see the advantage...) What are the solutions for this issue in the Linux alternatives implementation? -- Peter From skayser at opencsw.org Fri Nov 26 10:41:04 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 26 Nov 2010 10:41:04 +0100 Subject: [csw-maintainers] Disabling git patching framework in gar In-Reply-To: <1290734807-sup-7079@pinkfloyd.chass.utoronto.ca> References: <1290734807-sup-7079@pinkfloyd.chass.utoronto.ca> Message-ID: <4CEF80B0.50306@opencsw.org> Ben Walton wrote on 26.11.2010 02:27: > I just added a toggle to the git patching framework for GAR. If you > set the variable NOGITPATCH to a non-null value, you can turn off the > git stuff that brackets the extract and patch steps. > > Let me know if you have any trouble with it. I'm about to go document > it... The patch went into the -noexternals branch (thanks for testing Ben!) and isn't yet available on the regular GAR branch. Dago, would you mind checking the diff of the -noexternals branch. It should be fully compatible for regular (non-mgar-wrapper) usage and thus a candidate for merging. Sebastian From bwalton at opencsw.org Fri Nov 26 14:07:34 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 26 Nov 2010 08:07:34 -0500 Subject: [csw-maintainers] Disabling git patching framework in gar In-Reply-To: <4CEF80B0.50306@opencsw.org> References: <1290734807-sup-7079@pinkfloyd.chass.utoronto.ca> <4CEF80B0.50306@opencsw.org> Message-ID: <1290776689-sup-2630@pinkfloyd.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Fri Nov 26 04:41:04 -0500 2010: Hi Sebastian, > The patch went into the -noexternals branch (thanks for testing > Ben!) and isn't yet available on the regular GAR branch. Thanks for letting me know. I didn't realize there was such a branch, but I guess that's part of your mgar work. :) Ok, so if people want this for now, give Sebastian's new mgar wrapper a try! Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From skayser at opencsw.org Fri Nov 26 14:27:57 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 26 Nov 2010 14:27:57 +0100 Subject: [csw-maintainers] GAR wrapper (was: Re: Disabling git patching framework in gar) In-Reply-To: <1290776689-sup-2630@pinkfloyd.chass.utoronto.ca> References: <1290734807-sup-7079@pinkfloyd.chass.utoronto.ca> <4CEF80B0.50306@opencsw.org> <1290776689-sup-2630@pinkfloyd.chass.utoronto.ca> Message-ID: <4CEFB5DD.5020103@opencsw.org> Ben Walton wrote on 26.11.2010 14:07: > Excerpts from Sebastian Kayser's message of Fri Nov 26 04:41:04 -0500 2010: >> The patch went into the -noexternals branch (thanks for testing >> Ben!) and isn't yet available on the regular GAR branch. > > Thanks for letting me know. I didn't realize there was such a branch, > but I guess that's part of your mgar work. :) > > Ok, so if people want this for now, give Sebastian's new mgar wrapper > a try! As the mgar wrapper hasn't been announced here yet, I am gonna make up for it now: I've built a small command line wrapper prototype for GAR (currently called mgar). It aims to be a central interface to all things GAR and its main three goals are: 1) allow to drop the svn:externals definitions and gar/ symlinks 2) easen everyday work with GAR 3) provide a brief command line usage help Rationale and setup instructions for the wrapper are documented on the Wiki [1]. And yes, this required some small tweaks to GAR, thus the branch. Sorry for the confusion Ben :) The wrapper is in its early stages, but should already demonstrate its purpose. Feedback welcome. Sebastian [1] http://wiki.opencsw.org/gar-wrapper From phil at bolthole.com Sat Nov 27 00:38:11 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 26 Nov 2010 15:38:11 -0800 Subject: [csw-maintainers] Alternatives without automatic selection In-Reply-To: <x67hg01mjv.fsf@opencsw.org> References: <8F38B2DD-5DCF-4674-9BFF-C0162C6D9E9A@opencsw.org> <x6bp5c1nyk.fsf@opencsw.org> <41FC60D9-8F03-4C68-B539-17A282B28245@opencsw.org> <x67hg01mjv.fsf@opencsw.org> Message-ID: <AANLkTinZPMG0JngQWz3LgOgaAXKhKJsomXZuTAjxH=2k@mail.gmail.com> On Fri, Nov 26, 2010 at 1:06 AM, Peter FELECAN <pfelecan at opencsw.org> wrote: > >> Would you consider same priorities a bug or a feature? > > Definitely a feature! You example shows it clearly. > How is it a feature? what if the install order is effectively random? how is that a benefit to the user? >If we implement same priority alternatives and the order of installation >is rendered persistent how can we possibly guarantee order of installation? That would seem to be up to the user. This sort of thing will lead to the link given by 'alternatives' to start randomly changing, from a users perspective. This is a huge anti-feature! Any time a package is being upgraded: - it gets removed. alternatives gets called. 'oh, current alternative is no longer here. use next available for link'. - newer version gets added. alternatives gets called. ' oh. there's already an alternative in place of same priority. that one gets to keep the link'. the only way to implement any kind of "first installed, keeps priority", would be to effectively lock in "first installed", in basically the same way as a manual preference. IE; equivalent to alternatives -set xxx yyyy This sort of lock-in is supposed to be reserved to the user. To have the system do this pseudo-randomly based on "which got installed first", hidden in the background, is rather against the whole principle of the 'alternatives' mechanisms. From phil at bolthole.com Sat Nov 27 07:18:25 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 26 Nov 2010 22:18:25 -0800 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTi=95_k8dM1oDbqt=9W88e5=sNkf+MQY8mXcz_Lt@mail.gmail.com> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> <AANLkTik=_qycu1fanHTLbwD8SSrCDcKe+5mbpHoRY851@mail.gmail.com> <AANLkTin+2wi=e+WpGZ1sTxuQOM2dqnhm5zTTFq5TD8us@mail.gmail.com> <AANLkTikSz6hAcEY8iowWq8TzjUV=TVDXKAMhuR=Zk3D9@mail.gmail.com> <AANLkTi=95_k8dM1oDbqt=9W88e5=sNkf+MQY8mXcz_Lt@mail.gmail.com> Message-ID: <AANLkTi=AKrvxb34-zGLmJT3oQZsQ=S1E8A+BHdCaUSao@mail.gmail.com> A bit of a delayed reply on this one... I wanted to let it sit for a bit. This is mostly in reply to Maciej's email, but the very last bit addresses Peter's concerns about 'discretionary' release management. Maciej, you made claims that resistance to package manager concerns is because the maintainer wants to "avoid low quality" however, the examples you give, seem to mostly be in the flavor of "maintainer wants to avoid doing more work". On 11/24/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: >... > A single person in power can also hurt package quality. Imagine a > scenario in which there is a package, which has two issues, let's call > them A and B. The package is unmaintained, and one maintainer takes > on the issue A, fixes it and submits the fix for release. The updated > package is better than the previous one, but the release manager, > using his discretionary powers, rejects the package, saying that the > maintainer should fix issue B as well. The maintainer feels he's > being controlled, the release manager believes he's right and insists, > and both end up in a deadlock. point #1: notice this is nothing about the maintainer avoiding "low quality"; this is simply about "maintainer does not wish to do extra work". The "feeling controlled" complaint is just a passive-aggressive way of rephrasing "feeling pressured to do more work against his will". Almost every argument that comes up on the pkgsubmissions list, has nothing to do with the maintainer pushing back because it would somehow make the package "lower quality". Nor do they even claim that. It is almost always because the maintainer simply does not wish to do more work on the package, and tries to argue the work is "unneccessary". Other types of disagreement usually get resolved relatively easily with our existing methods. > This kind of an issue would not happen in a consensus driven > community. The updated package would be released, and the issue B > would get eventually fixed too. (its interesting that you assume that "consensus" means "siding with the maintainer, against the release manager". but apart from that...) Point #2: In contradiction to what you claim your interest is ("promoting high quality") your example explicitly *promotes* low quality, rather than somehow avoiding it. Your example says B eventually gets fixed. Which means B *is* a problem. Which means the package is better with it("higher quality") than without it. Yet your 'consensus' example gets the lesser quality package released, instead of waiting for the higher quality one to be ready. > Phil, I understand you mean well and you want packages to work well, > and I want the same thing. But I believe that package quality should > not be based on what Phil Brown (or any single person, for that > matter) happens to think is right. It should be based on what the > OpenCSW community agrees on. I'll mention that in most major free software distribution projects, the exact opposite is true. They do not handle every package release issue through "consensus of the members". To take debian, as usual: (and do note that it is arguably The Most Democratic of all distributions) The "ftp master" team, has virtually exclusive power over what gets released, and what does not. Note also, that the ftp masters are not purely bound by debian policy either! While debian policy is the usual benchmark, "The ftpmasters also have room for discretion in applying the rules and may reject packages for other reasons" While complex issues may end up getting discussed on debian devel (as complex issues with us, already get discussed on the maintainers list!), it is in the end, up to the debian ftp masters what gets released as a package, and what does not. From bonivart at opencsw.org Sat Nov 27 12:21:13 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 27 Nov 2010 12:21:13 +0100 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTi=AKrvxb34-zGLmJT3oQZsQ=S1E8A+BHdCaUSao@mail.gmail.com> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> <AANLkTik=_qycu1fanHTLbwD8SSrCDcKe+5mbpHoRY851@mail.gmail.com> <AANLkTin+2wi=e+WpGZ1sTxuQOM2dqnhm5zTTFq5TD8us@mail.gmail.com> <AANLkTikSz6hAcEY8iowWq8TzjUV=TVDXKAMhuR=Zk3D9@mail.gmail.com> <AANLkTi=95_k8dM1oDbqt=9W88e5=sNkf+MQY8mXcz_Lt@mail.gmail.com> <AANLkTi=AKrvxb34-zGLmJT3oQZsQ=S1E8A+BHdCaUSao@mail.gmail.com> Message-ID: <AANLkTinBYb4N-PTXQsJwic21mre1WexPvJVMUH_pywJQ@mail.gmail.com> On Sat, Nov 27, 2010 at 7:18 AM, Philip Brown <phil at bolthole.com> wrote: > To take debian, as usual: (and do note that it is arguably The Most > Democratic of all distributions) > The "ftp master" team, has virtually exclusive power over what gets > released, and what does not. > > Note also, that the ftp masters are not purely bound by debian policy either! > While debian policy is the usual benchmark, > "The ftpmasters also have room for discretion in applying the rules > and may reject packages for other reasons" > > While complex issues may end up getting discussed on debian devel (as > complex issues with us, already get discussed on the maintainers > list!), it is in the end, up to the debian ftp masters what gets > released as a package, and what does not. Your use of "debian ftp masters" imply plural which already there is an improvement of what we have. How did they become masters of the debian universe? You call them the most democratic of all distributions so maybe we could learn something here since ours is not democratic at all or has your position ever been up for a vote? /peter From yann at pleiades.fr.eu.org Sat Nov 27 22:33:03 2010 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 27 Nov 2010 22:33:03 +0100 Subject: [csw-maintainers] Sun Studio 12 outputs v8plus code instead of v8 code under Solaris 10 Message-ID: <4CF1790F.3000109@pleiades.fr.eu.org> Hi, I am currently building openssl under Solaris 10 to test the pkcs11 patch [1] and I've discovered a strange bug: Sun Studio 12 seems to generate v8plus code instead of v8 code when compiling assembly code. You can easily reproduce the bug using the attached file (sparcv8.S) under current10s: $ /opt/SUNWspro/bin/cc -I.. -I../.. -I../../include -KPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xarch=v8 -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -c sparcv8.S && elfdump sparcv8.o | grep machine e_machine: EM_SPARC32PLUS e_version: EV_CURRENT The machine identifier is EM_SPARC32PLUS, it should be EM_SPARC. $ /opt/studio/SOS11/SUNWspro/bin/cc -I.. -I../.. -I../../include -KPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xarch=v8 -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -c sparcv8.S && elfdump sparcv8.o | grep machine e_machine: EM_SPARC e_version: EV_CURRENT The bug doesn't happen with Sun Studio 12.1 et Sun Studio 12.2: $ /opt/SUNWspro/bin/cc -I.. -I../.. -I../../include -KPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xarch=v8 -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -c sparcv8.S && elfdump sparcv8.o | grep machine e_machine: EM_SPARC e_version: EV_CURRENT $ /opt/solstudio12.2/bin/cc -I.. -I../.. -I../../include -KPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xarch=v8 -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -c sparcv8.S && elfdump sparcv8.o | grep machine e_machine: EM_SPARC e_version: EV_CURRENT The bug doesn't happen on current9s using the same command lines. I will switch to Sun Studio 12.1 for now (BTW it seems it's not installed on current9s) but if someone has a clue on this issue, I would be interested. BTW I've noticed this bug thanks to Maciej's package checking code. Thanks in advance for your answers. Yann [1] http://blogs.sun.com/janp/entry/pkcs_11_engine_patch_including -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sparcv8.S URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20101127/c320894b/attachment-0001.ksh> From bwalton at opencsw.org Sun Nov 28 03:23:21 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 27 Nov 2010 21:23:21 -0500 Subject: [csw-maintainers] Disabling git patching framework in gar In-Reply-To: <4CEF80B0.50306@opencsw.org> References: <1290734807-sup-7079@pinkfloyd.chass.utoronto.ca> <4CEF80B0.50306@opencsw.org> Message-ID: <1290910840-sup-9244@pinkfloyd.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Fri Nov 26 04:41:04 -0500 2010: Hi Sebastian, > Dago, would you mind checking the diff of the -noexternals > branch. It should be fully compatible for regular (non-mgar-wrapper) > usage and thus a candidate for merging. I just looked at the change and I'd say it's ready to merge. It's pretty straight forward and not a large change overall. I say go for it! Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Nov 28 04:07:56 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 27 Nov 2010 22:07:56 -0500 Subject: [csw-maintainers] svn help? In-Reply-To: <30486602-7D41-420E-995C-7CD525154731@opencsw.org> References: <1290647989-sup-6671@pinkfloyd.chass.utoronto.ca> <1290648258-sup-9173@pinkfloyd.chass.utoronto.ca> <1290649818-sup-2412@pinkfloyd.chass.utoronto.ca> <BDA0D961-73A7-480B-8C71-E51CB0FA8FDD@opencsw.org> <1290692448-sup-3645@pinkfloyd.chass.utoronto.ca> <30486602-7D41-420E-995C-7CD525154731@opencsw.org> Message-ID: <1290913646-sup-2276@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Thu Nov 25 08:48:07 -0500 2010: Hi Dago, > I can also take care of it. The idea was to generate relocatable > packages not fixated to / as install base. Now I also saw why I > couldn't remember: Because Mike did it :-) Merged in r11739. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Nov 28 04:53:03 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 27 Nov 2010 22:53:03 -0500 Subject: [csw-maintainers] move bugs to another package? Message-ID: <1290916315-sup-2802@pinkfloyd.chass.utoronto.ca> Hi All, Does anyone know how to move a bug from one package to another? Now that each CAS is a separate package, the bugs can be moved to the scripts they pertain to. I don't see a method to do this via the web interface...is there a cli tool or does the database need to be updated manually? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Sun Nov 28 09:52:47 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 28 Nov 2010 09:52:47 +0100 Subject: [csw-maintainers] move bugs to another package? In-Reply-To: <1290916315-sup-2802@pinkfloyd.chass.utoronto.ca> References: <1290916315-sup-2802@pinkfloyd.chass.utoronto.ca> Message-ID: <AANLkTi=0DVcr+WZW_PVqzEHSrUR2fnCRtjF9rELFb3Zg@mail.gmail.com> On Sun, Nov 28, 2010 at 4:53 AM, Ben Walton <bwalton at opencsw.org> wrote: > Does anyone know how to move a bug from one package to another? ?Now > that each CAS is a separate package, the bugs can be moved to the > scripts they pertain to. ?I don't see a method to do this via the web > interface...is there a cli tool or does the database need to be > updated manually? How about "Move issue"? Doesn't that do exactly that? /peter From bwalton at opencsw.org Sun Nov 28 14:06:02 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 28 Nov 2010 08:06:02 -0500 Subject: [csw-maintainers] move bugs to another package? In-Reply-To: <AANLkTi=0DVcr+WZW_PVqzEHSrUR2fnCRtjF9rELFb3Zg@mail.gmail.com> References: <1290916315-sup-2802@pinkfloyd.chass.utoronto.ca> <AANLkTi=0DVcr+WZW_PVqzEHSrUR2fnCRtjF9rELFb3Zg@mail.gmail.com> Message-ID: <1290949543-sup-1181@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Sun Nov 28 03:52:47 -0500 2010: > How about "Move issue"? Doesn't that do exactly that? Yes. I completely missed that button. Thanks! -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Sun Nov 28 14:22:30 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 28 Nov 2010 14:22:30 +0100 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTi=AKrvxb34-zGLmJT3oQZsQ=S1E8A+BHdCaUSao@mail.gmail.com> (Philip Brown's message of "Fri, 26 Nov 2010 22:18:25 -0800") References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> <AANLkTik=_qycu1fanHTLbwD8SSrCDcKe+5mbpHoRY851@mail.gmail.com> <AANLkTin+2wi=e+WpGZ1sTxuQOM2dqnhm5zTTFq5TD8us@mail.gmail.com> <AANLkTikSz6hAcEY8iowWq8TzjUV=TVDXKAMhuR=Zk3D9@mail.gmail.com> <AANLkTi=95_k8dM1oDbqt=9W88e5=sNkf+MQY8mXcz_Lt@mail.gmail.com> <AANLkTi=AKrvxb34-zGLmJT3oQZsQ=S1E8A+BHdCaUSao@mail.gmail.com> Message-ID: <x6y68dzip5.fsf@opencsw.org> Philip Brown <phil at bolthole.com> writes: > however, the examples you give, seem to mostly be in the flavor of > "maintainer wants to avoid doing more work". I don't think that this is very accurate. It's subjectiveness is insulting to the *voluntary* work of the maintainers. It's not about laziness but about pragmatic compromises chosen by the maintainer. > On 11/24/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote: >>... >> A single person in power can also hurt package quality. Imagine a >> scenario in which there is a package, which has two issues, let's call >> them A and B. The package is unmaintained, and one maintainer takes >> on the issue A, fixes it and submits the fix for release. The updated >> package is better than the previous one, but the release manager, >> using his discretionary powers, rejects the package, saying that the >> maintainer should fix issue B as well. The maintainer feels he's >> being controlled, the release manager believes he's right and insists, >> and both end up in a deadlock. > > > point #1: notice this is nothing about the maintainer avoiding "low > quality"; this is simply about "maintainer does not wish to do extra > work". In your reality we are a bunch of lazy people isn't it? > The "feeling controlled" complaint is just a passive-aggressive way of > rephrasing "feeling pressured to do more work against his will". This is cheap psychology. >> Phil, I understand you mean well and you want packages to work well, >> and I want the same thing. But I believe that package quality should >> not be based on what Phil Brown (or any single person, for that >> matter) happens to think is right. It should be based on what the >> OpenCSW community agrees on. > > I'll mention that in most major free software distribution projects, > the exact opposite is true. They do not handle every package release > issue through "consensus of the members". > To take debian, as usual: (and do note that it is arguably The Most > Democratic of all distributions) > The "ftp master" team, has virtually exclusive power over what gets > released, and what does not. That is a team. In our case we can consider that there is a team and it's constituted only by one person. In North Korea they call it popular democracy but that is not enough reason to qualify. > Note also, that the ftp masters are not purely bound by debian policy either! > While debian policy is the usual benchmark, > "The ftpmasters also have room for discretion in applying the rules > and may reject packages for other reasons" This is cherry picking and I'm not surprised that you like this part. However, their community have well defined policies when our has very fluctuating and arbitrary policies where rules spring out of blue sky, on the whims of the "release management team"; putting the release management above the policies is like in the feodal regimes. I'm not proposing a multi-person release management team but an automatic release management based on agreed upon policies. Instead of reinventing policies we can very easily adapt the Debian policies to our community. -- Peter From pfelecan at opencsw.org Sun Nov 28 16:38:02 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 28 Nov 2010 16:38:02 +0100 Subject: [csw-maintainers] Alternatives without automatic selection In-Reply-To: <AANLkTinZPMG0JngQWz3LgOgaAXKhKJsomXZuTAjxH=2k@mail.gmail.com> (Philip Brown's message of "Fri, 26 Nov 2010 15:38:11 -0800") References: <8F38B2DD-5DCF-4674-9BFF-C0162C6D9E9A@opencsw.org> <x6bp5c1nyk.fsf@opencsw.org> <41FC60D9-8F03-4C68-B539-17A282B28245@opencsw.org> <x67hg01mjv.fsf@opencsw.org> <AANLkTinZPMG0JngQWz3LgOgaAXKhKJsomXZuTAjxH=2k@mail.gmail.com> Message-ID: <x6tyj1zcf9.fsf@opencsw.org> Philip Brown <phil at bolthole.com> writes: > On Fri, Nov 26, 2010 at 1:06 AM, Peter FELECAN <pfelecan at opencsw.org> wrote: >> >>> Would you consider same priorities a bug or a feature? >> >> Definitely a feature! You example shows it clearly. >> > > How is it a feature? > what if the install order is effectively random? how is that a benefit > to the user? You should remember the context, as described by Dag. In my reading, it's about packages having declared alternatives with the same priority and the issue of keeping the first installed alternative when installing, later, other alternatives, with the same priority. >>If we implement same priority alternatives and the order of installation >>is rendered persistent > > how can we possibly guarantee order of installation? > That would seem to be up to the user. Still thinking that this can be a feature, I'll let Dag arguing with you about what and how. -- Peter From maciej at opencsw.org Sun Nov 28 19:30:46 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 28 Nov 2010 18:30:46 +0000 Subject: [csw-maintainers] File type of '?' in /var/sadm/install/contents Message-ID: <AANLkTimjpquUxTRw+wAV9eEJ0hUecNzvL+8JDRYk=7J2@mail.gmail.com> While working on file collision detection in checkpkg, I found the following line in /var/sadm/install/contents on current9s: '/opt/csw/gcc3/lib/gcc/sparc-sun-solaris2.8/3.4.6/include ? none CSWgcc3g77 CSWgcc3core\n' Looking at the filesystem, it's a directory. Therefore, the file type should be 'd'. But in install/contents, it's '?'. According to Sun docs[1], the syntax is: path d class mode owner group package(s) So, the line in /var/sadm/install/contents does not follow the spec. I looked at both packages (CSWgcc3g77 and CSWgcc3core), and their pkgmap looks sane, the corresponding lines are identical in both packages, and looking sane: 1 d none /opt/csw/gcc3/lib/gcc/sparc-sun-solaris2.8/3.4.6/include 0755 root bin 1 d none /opt/csw/gcc3/lib/gcc/sparc-sun-solaris2.8/3.4.6/include 0755 root bin Does anyone know how is it possible that /var/sadm/install/contents contains a line that does not follow the spec? Maciej http://docs.sun.com/app/docs/doc/816-5174/contents-4?l=en&a=view From dam at opencsw.org Mon Nov 29 10:59:59 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 29 Nov 2010 10:59:59 +0100 Subject: [csw-maintainers] Alternatives without automatic selection In-Reply-To: <AANLkTinZPMG0JngQWz3LgOgaAXKhKJsomXZuTAjxH=2k@mail.gmail.com> References: <8F38B2DD-5DCF-4674-9BFF-C0162C6D9E9A@opencsw.org> <x6bp5c1nyk.fsf@opencsw.org> <41FC60D9-8F03-4C68-B539-17A282B28245@opencsw.org> <x67hg01mjv.fsf@opencsw.org> <AANLkTinZPMG0JngQWz3LgOgaAXKhKJsomXZuTAjxH=2k@mail.gmail.com> Message-ID: <1F1B4430-FEA0-4FB9-BAA8-BE438CF3C3B1@opencsw.org> Hi Phil, Am 27.11.2010 um 00:38 schrieb Philip Brown: > On Fri, Nov 26, 2010 at 1:06 AM, Peter FELECAN <pfelecan at opencsw.org> wrote: >> >>> Would you consider same priorities a bug or a feature? >> >> Definitely a feature! You example shows it clearly. > > How is it a feature? > what if the install order is effectively random? how is that a benefit > to the user? It may not be random if a user installs one MTA and configures it. No MTA is better than another, if the prios were different another MTA may supersede which is bad. The automatic selection of same priorities should be persistent and saved similar to manual selection. >> If we implement same priority alternatives and the order of installation >> is rendered persistent > > how can we possibly guarantee order of installation? > That would seem to be up to the user. > > This sort of thing will lead to the link given by 'alternatives' to > start randomly changing, from a users perspective. This is a huge > anti-feature! > Any time a package is being upgraded: > - it gets removed. alternatives gets called. 'oh, current alternative > is no longer here. use next available for link'. Right. Store "Previous automatic was 100 sendmail" > - newer version gets added. alternatives gets called. ' oh. there's > already an alternative in place of same priority. that one gets to > keep the link'. Nope. Sendmail gets added, current automatic selection is "postfix 100", previous stored automatic was sendmail, restore previous automatic setting if possible. > the only way to implement any kind of "first installed, keeps > priority", would be to effectively lock in "first installed", in > basically the same way as a manual preference. > IE; equivalent to alternatives -set xxx yyyy Similar. > This sort of lock-in is supposed to be reserved to the user. > To have the system do this pseudo-randomly based on "which got > installed first", hidden in the background, is rather against the > whole principle of the 'alternatives' mechanisms. Ok then, so you say identical prios are an error. That means sendmail would get 100 and postfix 200 (or vice versay, doesn't matter for the moment). User installs sendmail and configures it. Than much later postfix is installed and everything breaks. Does this sound better to you than my proposal? Best regards -- Dago From dam at opencsw.org Mon Nov 29 11:36:14 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 29 Nov 2010 11:36:14 +0100 Subject: [csw-maintainers] Sun Studio 12 outputs v8plus code instead of v8 code under Solaris 10 In-Reply-To: <4CF1790F.3000109@pleiades.fr.eu.org> References: <4CF1790F.3000109@pleiades.fr.eu.org> Message-ID: <F6A97B5A-0581-414C-B209-EA808C015358@opencsw.org> Hi Yann, Am 27.11.2010 um 22:33 schrieb Yann Rouillard: > I am currently building openssl under Solaris 10 to test the pkcs11 > patch [1] and I've discovered a strange bug: Sun Studio 12 seems to > generate v8plus code instead of v8 code when compiling assembly code. I guess this is because Solaris 10 requires sparcv8+, but the inconsistent handling between the compilers more look like a bug. > I will switch to Sun Studio 12.1 for now (BTW it seems it's not > installed on current9s) but if someone has a clue on this issue, I would > be interested. Yep, 12.1 starts to run on Solaris 10: http://docs.sun.com/source/821-0080/index.html Best regards -- Dago From phil at bolthole.com Tue Nov 30 02:56:45 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 29 Nov 2010 17:56:45 -0800 Subject: [csw-maintainers] Alternatives without automatic selection In-Reply-To: <1F1B4430-FEA0-4FB9-BAA8-BE438CF3C3B1@opencsw.org> References: <8F38B2DD-5DCF-4674-9BFF-C0162C6D9E9A@opencsw.org> <x6bp5c1nyk.fsf@opencsw.org> <41FC60D9-8F03-4C68-B539-17A282B28245@opencsw.org> <x67hg01mjv.fsf@opencsw.org> <AANLkTinZPMG0JngQWz3LgOgaAXKhKJsomXZuTAjxH=2k@mail.gmail.com> <1F1B4430-FEA0-4FB9-BAA8-BE438CF3C3B1@opencsw.org> Message-ID: <AANLkTinKj4YhiAd72YjbguNtr7ZVc=GQJOx=Jy7d6PJB@mail.gmail.com> On Mon, Nov 29, 2010 at 1:59 AM, Dagobert Michelsen <dam at opencsw.org> wrote: > ... > Ok then, so you say identical prios are an error. That means > sendmail would get 100 and postfix 200 (or vice versay, doesn't > matter for the moment). User installs sendmail and configures it. > Than much later postfix is installed and everything breaks. > Does this sound better to you than my proposal? Thank you for bringing up that example. We should definitely augment our documentation to cover it. I have two comments. #1: What you describe is, unfortunately, an example of another way to incorrectly implement 'alternatives' in a package. A package should not trigger 'alternatives', until what is referenced, is actually functional. We should document use of 'alternatives' to be clear about this. #2: here's the biggest thing: . If you dont like the fact that the user will automatically get a different implementation inserted underneath things, when they install a higher priority implementation, I can understand that. But ***this is exactly how they (LINUX alternatives) were designed to work***! So if you dont like the way that feels as a user, then please make a formal proposal suggesting we stop trying to emulate "linux alternatives", and start using "Dagobert's Special Program Switcher(tm)" instead :-D From phil at bolthole.com Tue Nov 30 17:44:51 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 30 Nov 2010 08:44:51 -0800 Subject: [csw-maintainers] Our core values: providing straightforward experience to the user In-Reply-To: <AANLkTinBYb4N-PTXQsJwic21mre1WexPvJVMUH_pywJQ@mail.gmail.com> References: <AANLkTik_VYxQwDG0xpB5ehDnf=URm+OLyEqMzTGAQdn_@mail.gmail.com> <AANLkTi=Jb+eQnijf6yG7hBg9wV8-9o4G0iXUfev4FWaa@mail.gmail.com> <x67hg97ijy.fsf@opencsw.org> <AANLkTim+rmNGjUhve1GSVzhVFDeKd7-h3vEriPCpvS9N@mail.gmail.com> <AANLkTinHa+VfwLm+HDyrsU-OtcOhtqDZyQ=KQeie-WS9@mail.gmail.com> <AANLkTi=gBk0v-GK0pVaWFrgrPUD8U2RGhPsXw5heThFY@mail.gmail.com> <AANLkTim0ftNs_B0mCcc0dVDEsz-fFkqEFijBVC7TRP1r@mail.gmail.com> <AANLkTik=_qycu1fanHTLbwD8SSrCDcKe+5mbpHoRY851@mail.gmail.com> <AANLkTin+2wi=e+WpGZ1sTxuQOM2dqnhm5zTTFq5TD8us@mail.gmail.com> <AANLkTikSz6hAcEY8iowWq8TzjUV=TVDXKAMhuR=Zk3D9@mail.gmail.com> <AANLkTi=95_k8dM1oDbqt=9W88e5=sNkf+MQY8mXcz_Lt@mail.gmail.com> <AANLkTi=AKrvxb34-zGLmJT3oQZsQ=S1E8A+BHdCaUSao@mail.gmail.com> <AANLkTinBYb4N-PTXQsJwic21mre1WexPvJVMUH_pywJQ@mail.gmail.com> Message-ID: <AANLkTikFj11Wi_2m0XyRoBQ8E8p=+X1EQ-04jHhxC0zr@mail.gmail.com> On 11/27/10, Peter Bonivart <bonivart at opencsw.org> wrote: > On Sat, Nov 27, 2010 at 7:18 AM, Philip Brown <phil at bolthole.com> wrote: >> >> While complex issues may end up getting discussed on debian devel (as >> complex issues with us, already get discussed on the maintainers >> list!), it is in the end, up to the debian ftp masters what gets >> released as a package, and what does not. > > Your use of "debian ftp masters" imply plural which already there is > an improvement of what we have. Its important to note that they have multiple, to share the extreme workload, not so that maintainers get to run to one of them, because they dont like how strict the other one is. > How did they become masters of the debian universe? You call them the > most democratic of all distributions so maybe we could learn something > here since ours is not democratic at all or has your position ever > been up for a vote? I believe the debian ftp-master position, is a "delegated" position. It is assigned by the Debian Project Leader. It is not directly elected. I do not have an objection to our release master being delegated by the board. I would be interested to see who else wants to make an actual commitment on the level that I have, both in time, and in commitment to quality. As far as I know, no-one else is interested in doing so. From gadavis at opencsw.org Tue Nov 30 21:31:14 2010 From: gadavis at opencsw.org (Geoff Davis) Date: Tue, 30 Nov 2010 12:31:14 -0800 Subject: [csw-maintainers] Alternatives without automatic selection In-Reply-To: <AANLkTinKj4YhiAd72YjbguNtr7ZVc=GQJOx=Jy7d6PJB@mail.gmail.com> References: <8F38B2DD-5DCF-4674-9BFF-C0162C6D9E9A@opencsw.org> <x6bp5c1nyk.fsf@opencsw.org> <41FC60D9-8F03-4C68-B539-17A282B28245@opencsw.org> <x67hg01mjv.fsf@opencsw.org> <AANLkTinZPMG0JngQWz3LgOgaAXKhKJsomXZuTAjxH=2k@mail.gmail.com> <1F1B4430-FEA0-4FB9-BAA8-BE438CF3C3B1@opencsw.org> <AANLkTinKj4YhiAd72YjbguNtr7ZVc=GQJOx=Jy7d6PJB@mail.gmail.com> Message-ID: <96A70775-4B30-466E-A538-5CDB69F3E7A0@opencsw.org> On Nov 29, 2010, at 5:56 PM, Philip Brown wrote: > On Mon, Nov 29, 2010 at 1:59 AM, Dagobert Michelsen <dam at opencsw.org> wrote: >> ... >> Ok then, so you say identical prios are an error. That means >> sendmail would get 100 and postfix 200 (or vice versay, doesn't >> matter for the moment). User installs sendmail and configures it. >> Than much later postfix is installed and everything breaks. >> Does this sound better to you than my proposal? > > Thank you for bringing up that example. We should definitely augment > our documentation to cover it. > > I have two comments. > > #1: What you describe is, unfortunately, an example of another way to > incorrectly implement 'alternatives' in a package. A package should > not trigger 'alternatives', until what is referenced, is actually > functional. We should document use of 'alternatives' to be clear about > this. > > > #2: here's the biggest thing: . > If you dont like the fact that the user will automatically get a > different implementation inserted underneath things, when they install > a higher priority implementation, I can understand that. > But ***this is exactly how they (LINUX alternatives) were designed to work***! > > So if you dont like the way that feels as a user, then please make a > formal proposal suggesting we stop trying to emulate "linux > alternatives", and start using "Dagobert's Special Program > Switcher(tm)" instead :-D How does the alternatives mechanism handle package upgrades of an existing package in the Linux world? If I recall, the RPM and Debian package managers have the concept of "upgrade" rather than "Uninstall" followed by "Install". I would assume therefore that the initial package installation order determines in perpetuity what package is preferred. This would certainly be the behavior that I would expect from the OpenCSW tools. From phil at bolthole.com Tue Nov 30 22:04:42 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 30 Nov 2010 13:04:42 -0800 Subject: [csw-maintainers] Alternatives without automatic selection In-Reply-To: <96A70775-4B30-466E-A538-5CDB69F3E7A0@opencsw.org> References: <8F38B2DD-5DCF-4674-9BFF-C0162C6D9E9A@opencsw.org> <x6bp5c1nyk.fsf@opencsw.org> <41FC60D9-8F03-4C68-B539-17A282B28245@opencsw.org> <x67hg01mjv.fsf@opencsw.org> <AANLkTinZPMG0JngQWz3LgOgaAXKhKJsomXZuTAjxH=2k@mail.gmail.com> <1F1B4430-FEA0-4FB9-BAA8-BE438CF3C3B1@opencsw.org> <AANLkTinKj4YhiAd72YjbguNtr7ZVc=GQJOx=Jy7d6PJB@mail.gmail.com> <96A70775-4B30-466E-A538-5CDB69F3E7A0@opencsw.org> Message-ID: <AANLkTi=ohN56qaMzLqqj1M69gYP8p1JCLvcJ_HUXjg18@mail.gmail.com> On 11/30/10, Geoff Davis <gadavis at opencsw.org> wrote: > ... > How does the alternatives mechanism handle package upgrades of an existing > package in the Linux world? If I recall, the RPM and Debian package managers > have the concept of "upgrade" rather than "Uninstall" followed by "Install". I think that is a side issue; if we just focus on pure "install", the central issue here becomes clearer. Please see below > I would assume therefore that the initial package installation order > determines in perpetuity what package is preferred. This would certainly be > the behavior that I would expect from the OpenCSW tools. well, it's exactly the opposite, from what you will get from a linux install. Try the following, with names adjusted as appropriate, in your linux distribution of choice that supports "alternatives": * install [vim-tiny] * use "vim". you'll be using "vim-tiny". * install [full-vim] * use "vim". Would you expect to still be using "vim-tiny", at that point, or full "vim"? either way, you'll GET full vim, unless you explicitly run "alternatives --set vim vim-tiny" or whatever is the equivalent on that linux distro. Why would you expect any differently? If I, as a user, install a "better" implementation of something I was previously using, I would expect that any intelligent packaging system automatically use the "better" one, without me having to tell it to. For what it's worth.. seeing as how it's "OUR" tool, so we can customize how we like :), I could potentially see adding in some kind of configuration option in our tool, that behaves in a "first come first served" manner. However, given the common expectation out there of hundreds of thousands of linux systems working in the exact opposite way... there's no way that should be default behaviour. From dam at opencsw.org Tue Nov 30 23:20:13 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 30 Nov 2010 23:20:13 +0100 Subject: [csw-maintainers] Alternatives without automatic selection In-Reply-To: <AANLkTi=ohN56qaMzLqqj1M69gYP8p1JCLvcJ_HUXjg18@mail.gmail.com> References: <8F38B2DD-5DCF-4674-9BFF-C0162C6D9E9A@opencsw.org> <x6bp5c1nyk.fsf@opencsw.org> <41FC60D9-8F03-4C68-B539-17A282B28245@opencsw.org> <x67hg01mjv.fsf@opencsw.org> <AANLkTinZPMG0JngQWz3LgOgaAXKhKJsomXZuTAjxH=2k@mail.gmail.com> <1F1B4430-FEA0-4FB9-BAA8-BE438CF3C3B1@opencsw.org> <AANLkTinKj4YhiAd72YjbguNtr7ZVc=GQJOx=Jy7d6PJB@mail.gmail.com> <96A70775-4B30-466E-A538-5CDB69F3E7A0@opencsw.org> <AANLkTi=ohN56qaMzLqqj1M69gYP8p1JCLvcJ_HUXjg18@mail.gmail.com> Message-ID: <5CC7B35F-6C99-4783-A454-D37F0A8DB4E5@opencsw.org> Hi Phil, Am 30.11.2010 um 22:04 schrieb Philip Brown: > On 11/30/10, Geoff Davis <gadavis at opencsw.org> wrote: >> ... >> How does the alternatives mechanism handle package upgrades of an existing >> package in the Linux world? If I recall, the RPM and Debian package managers >> have the concept of "upgrade" rather than "Uninstall" followed by "Install". > > I think that is a side issue; if we just focus on pure "install", the > central issue here becomes clearer. Please see below > >> I would assume therefore that the initial package installation order >> determines in perpetuity what package is preferred. This would certainly be >> the behavior that I would expect from the OpenCSW tools. > > well, it's exactly the opposite, from what you will get from a linux install. > Try the following, with names adjusted as appropriate, in your linux > distribution of choice that supports "alternatives": Your example is for alternatives with different priorities. My example (and all the discussion) is about same priorities. > For what it's worth.. seeing as how it's "OUR" tool, so we can > customize how we like :), I could potentially see adding in some kind > of configuration option in our tool, that behaves in a "first come > first served" manner. However, given the common expectation out there > of hundreds of thousands of linux systems working in the exact > opposite way. They do not. Having an update-hook in pkg* would be the best solution for persistence, but feel free to work around that in the script. Best regards -- Dago From phil at bolthole.com Tue Nov 30 23:56:06 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 30 Nov 2010 14:56:06 -0800 Subject: [csw-maintainers] Alternatives without automatic selection In-Reply-To: <5CC7B35F-6C99-4783-A454-D37F0A8DB4E5@opencsw.org> References: <8F38B2DD-5DCF-4674-9BFF-C0162C6D9E9A@opencsw.org> <x6bp5c1nyk.fsf@opencsw.org> <41FC60D9-8F03-4C68-B539-17A282B28245@opencsw.org> <x67hg01mjv.fsf@opencsw.org> <AANLkTinZPMG0JngQWz3LgOgaAXKhKJsomXZuTAjxH=2k@mail.gmail.com> <1F1B4430-FEA0-4FB9-BAA8-BE438CF3C3B1@opencsw.org> <AANLkTinKj4YhiAd72YjbguNtr7ZVc=GQJOx=Jy7d6PJB@mail.gmail.com> <96A70775-4B30-466E-A538-5CDB69F3E7A0@opencsw.org> <AANLkTi=ohN56qaMzLqqj1M69gYP8p1JCLvcJ_HUXjg18@mail.gmail.com> <5CC7B35F-6C99-4783-A454-D37F0A8DB4E5@opencsw.org> Message-ID: <AANLkTik6etWc-7SHMyQSf_EPnJ1UQn=24VD3-2LUUdcS@mail.gmail.com> On 11/30/10, Dagobert Michelsen <dam at opencsw.org> wrote: > Hi Phil, > > Am 30.11.2010 um 22:04 schrieb Philip Brown: >> >> well, it's exactly the opposite, from what you will get from a linux >> install. >> Try the following, with names adjusted as appropriate, in your linux >> distribution of choice that supports "alternatives": > > Your example is for alternatives with different priorities. My example > (and all the discussion) is about same priorities. And why are you attempting to set same priorities in the first place, rather than make a priority decision about what deserves to be a higher priority? In what you wrote, you seem to imply that you want same priorities for everything, to avoid the user ever having the implementation switched out from what they installed the first time, because that behaviour is "bad" to you. From phil at bolthole.com Tue Nov 30 23:58:57 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 30 Nov 2010 14:58:57 -0800 Subject: [csw-maintainers] Alternatives without automatic selection In-Reply-To: <5CC7B35F-6C99-4783-A454-D37F0A8DB4E5@opencsw.org> References: <8F38B2DD-5DCF-4674-9BFF-C0162C6D9E9A@opencsw.org> <x6bp5c1nyk.fsf@opencsw.org> <41FC60D9-8F03-4C68-B539-17A282B28245@opencsw.org> <x67hg01mjv.fsf@opencsw.org> <AANLkTinZPMG0JngQWz3LgOgaAXKhKJsomXZuTAjxH=2k@mail.gmail.com> <1F1B4430-FEA0-4FB9-BAA8-BE438CF3C3B1@opencsw.org> <AANLkTinKj4YhiAd72YjbguNtr7ZVc=GQJOx=Jy7d6PJB@mail.gmail.com> <96A70775-4B30-466E-A538-5CDB69F3E7A0@opencsw.org> <AANLkTi=ohN56qaMzLqqj1M69gYP8p1JCLvcJ_HUXjg18@mail.gmail.com> <5CC7B35F-6C99-4783-A454-D37F0A8DB4E5@opencsw.org> Message-ID: <AANLkTikiL=gv4V5PLotHrkvHjptmtgSs7ZQLYiWDdfOh@mail.gmail.com> PS: On 11/30/10, Dagobert Michelsen <dam at opencsw.org> wrote: > > Your example is for alternatives with different priorities. My example > (and all the discussion) is about same priorities. > I also gave an example with the same priorities, a few messages back. I saw a reply from Peter(I think) about it, but he only replied to the first half, and ignored the part where I point out glaring problems with having the same priorties. No-one has directly addressed those problems.