From skayser at opencsw.org Tue Nov 1 00:43:33 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 1 Nov 2011 00:43:33 +0100 Subject: [csw-maintainers] Release process graph // release branch info on opencsw.org In-Reply-To: <20111030191714.GE26160@sebastiankayser.de> References: <20111024231542.GP26160@sebastiankayser.de> <20111028083617.GW26160@sebastiankayser.de> <20111030191714.GE26160@sebastiankayser.de> Message-ID: <20111031234333.GF26160@sebastiankayser.de> * Sebastian Kayser wrote: > * Sebastian Kayser wrote: > > * Sebastian Kayser wrote: > > > The release branch information on opencsw.org however is still outdated. > > > Any volunteer to de-duplicate and update the relevant content [2,3]? > > > Then we could add a frontpage news items (with links to the updated > > > information) to bring our users up to speed and spare them hunting for > > > details. > > > > > > [2] http://www.opencsw.org/get-it/releases/ > > > [3] http://www.opencsw.org/use-it/#release > > > > Any volunteers? Doesn't have to be prose (IMHO) just a concise, current, > > and honest description of what people can currently expect. I'll go > > ahead and do it on Sunday if no one jumps in. Don't be surprised by the > > strange sentences then though, coz u noo, ai em noht a native spika. ;) > > Done on www-mockup. Barring veto, I'll push it to www tomorrow and we > can always refine it from there. That's done. Also published a news item regarding the changes. http://www.opencsw.org/2011/11/release-branches-adjusted/ Sebastian From bwalton at opencsw.org Tue Nov 1 18:07:57 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 01 Nov 2011 13:07:57 -0400 Subject: [csw-maintainers] website does not reflect real package versions ? In-Reply-To: References: Message-ID: <1320167237-sup-4774@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sat Oct 15 13:13:52 -0400 2011: Hi Rupert, > to put "solaris package ..." on the package description text makes > it finally easy to find opencsw packages on the web. unfortunately > it seems not easy to find the current versions. e.g mercurial is > still listet with a version 1.8.4 from june. there was one new > package every month since then. what is missing currently so the > versions are displayed correctly? who needs to do what? where could > one help out? I'm planning to run the web db integration tonight which should get things up to speed again. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Tue Nov 1 18:40:21 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 1 Nov 2011 17:40:21 +0000 Subject: [csw-maintainers] potentially useful script in gar In-Reply-To: <1320074480-sup-5963@pinkfloyd.chass.utoronto.ca> References: <1320029191-sup-2430@pinkfloyd.chass.utoronto.ca> <1320074480-sup-5963@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/10/31 Ben Walton : > Ok, I think my particular case is caused by having the catchall > package use a specific set of files and become a metapackage of sorts > (bacula). ?CSWbacula pulls in a few other packages that also have > specific PKGFILES definitions. ?Thus, I override the default gar > ability. It sounds like CSWbacula is not a catch-all package in your case. What I do in such case, is I create CSWdo-not-release, and I don't set PKGFILES for it. After gar finishes, I look inside to see if it contains any files. Maciej From bwalton at opencsw.org Wed Nov 2 00:49:21 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 01 Nov 2011 19:49:21 -0400 Subject: [csw-maintainers] web db integration in flight Message-ID: <1320191161-sup-5176@pinkfloyd.chass.utoronto.ca> Hi All, The maiden voyage of the web db integration run is now in progress. As this is a large update, there will be a long-ish window where packages that existed previously are not available. To handle the file path maintenance, all removal operations need to happen up front...It takes ~1hour to run to completion in my test environment and I found the mantis run to be slower. I'll send another mail when it's finished and ask that you take a peek at some of the things you know have been updated. Once the initial run is completed, I'll cron this at the same interval as the mantis updates. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Wed Nov 2 01:55:38 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 01 Nov 2011 20:55:38 -0400 Subject: [csw-maintainers] Fwd: Re: libsvn_subr/dirent_uri.c dumps core when url contains a space In-Reply-To: References: <20111031092923.GA14858@ted.stsp.name> Message-ID: <1320195297-sup-9937@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Mon Oct 31 13:40:18 -0400 2011: Hi Rupert, > fyi Thanks for this. I've identified a potential fix in for git-svn and am about to test it. Thanks for tracking this down. Sorry for the red herring. Thanks -Ben > ---------- Forwarded message ---------- > From: "Stefan Sperling" > Date: Oct 31, 2011 10:29 AM > Subject: Re: libsvn_subr/dirent_uri.c dumps core when url contains a space > To: "rupert.thurner" > Cc: > > On Sun, Oct 30, 2011 at 10:09:52PM -0700, rupert.thurner wrote: > > on solaris the perl bindings dump a core when an url contains a space, > > see https://www.opencsw.org/mantis/view.php?id=4854. an excerpt: > > > > The SVN::Ra bindings core dump with the following error: > > > > $ perl ./test.pl > > svn: E235000: In file 'subversion/libsvn_subr/dirent_uri.c' line 2291: > > assertion failed (svn_uri_is_canonical(url, pool)) > > Abort (core dumped) > > > > > > The content of test.pl: > > > > require SVN::Ra; > > > > $s = SVN::Ra->new('file:///home/bwalton/opencsw/git/trunk/work/ > > solaris9-sparc/build-isa-sparcv8/git-1.7.7.1/t/trash [^] > > directory.t9134-git-svn-ignore-paths/svnrepo'); > > Your code is wrong. You have to canonicalize URLs and paths > before passing them into the SVN API. > > Something like the following might work better (untested): > > require SVN::Core; > require SVN::Ra; > > my $url = > SVN::Core->svn_uri_canonicalize('file:///home/bwalton/opencsw/git/trunk/work/solaris9-sparc/build-isa-sparcv8/git-1.7.7.1/t/trash > [^] directory.t9134-git-svn-ignore-paths/svnrepo') > $s = SVN::Ra->new($url); > fyi > > ---------- Forwarded message ---------- > From: "Stefan Sperling" <[1]stsp at elego.de> > Date: Oct 31, 2011 10:29 AM > Subject: Re: libsvn_subr/dirent_uri.c dumps core when url contains a space > To: "rupert.thurner" <[2]rupert.thurner at gmail.com> > Cc: <[3]dev at subversion.apache.org> > > On Sun, Oct 30, 2011 at 10:09:52PM -0700, rupert.thurner wrote: > > on solaris the perl bindings dump a core when an url contains a space, > > see [4]https://www.opencsw.org/mantis/view.php?id=4854. an excerpt: > > > > The SVN::Ra bindings core dump with the following error: > > > > $ perl ./[5]test.pl > > svn: E235000: In file 'subversion/libsvn_subr/dirent_uri.c' line 2291: > > assertion failed (svn_uri_is_canonical(url, pool)) > > Abort (core dumped) > > > > > > The content of [6]test.pl: > > > > require SVN::Ra; > > > > $s = SVN::Ra->new('file:///home/bwalton/opencsw/git/trunk/work/ > > solaris9-sparc/build-isa-sparcv8/git-1.7.7.1/t/trash [^] > > directory.t9134-git-svn-ignore-paths/svnrepo'); > > Your code is wrong. You have to canonicalize URLs and paths > before passing them into the SVN API. > > Something like the following might work better (untested): > > require SVN::Core; > require SVN::Ra; > > my $url = > SVN::Core->svn_uri_canonicalize('file:///home/bwalton/opencsw/git/trunk/work/solaris9-sparc/build-isa-sparcv8/git-1.7.7.1/t/trash > [^] directory.t9134-git-svn-ignore-paths/svnrepo') > $s = SVN::Ra->new($url); > > References > > Visible links > 1. mailto:stsp at elego.de > 2. mailto:rupert.thurner at gmail.com > 3. mailto:dev at subversion.apache.org > 4. https://www.opencsw.org/mantis/view.php?id=4854 > 5. http://test.pl/ > 6. http://test.pl/ -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Wed Nov 2 02:10:35 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 2 Nov 2011 01:10:35 +0000 Subject: [csw-maintainers] web db integration in flight In-Reply-To: <1320191161-sup-5176@pinkfloyd.chass.utoronto.ca> References: <1320191161-sup-5176@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/11/1 Ben Walton : > The maiden voyage of the web db integration run is now in progress. > As this is a large update, there will be a long-ish window where > packages that existed previously are not available. ?To handle the > file path maintenance, all removal operations need to happen up > front...It takes ~1hour to run to completion in my test environment > and I found the mantis run to be slower. Excellent! In the meantime, I did some tweaking of pkgdb-web with the hope that I could make it runs faster. I might have made things slightly better. Maciej From bwalton at opencsw.org Wed Nov 2 03:04:58 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 01 Nov 2011 22:04:58 -0400 Subject: [csw-maintainers] web db integration in flight In-Reply-To: References: <1320191161-sup-5176@pinkfloyd.chass.utoronto.ca> Message-ID: <1320199464-sup-5807@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Tue Nov 01 21:10:35 -0400 2011: Hi Maciej, > In the meantime, I did some tweaking of pkgdb-web with the hope that > I could make it runs faster. I might have made things slightly > better. It felt quicker but I wasn't actually measuring the performance. It is presumably getting faster responses due to (hopefully!) not having to travel across the pond... The initial update has completed. Please inspect your list of pakcages and a few of the versions that you may have updated. Let me know if you find anything you're not happy with. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Wed Nov 2 03:23:51 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 01 Nov 2011 22:23:51 -0400 Subject: [csw-maintainers] lisa 2011 Message-ID: <1320200591-sup-695@pinkfloyd.chass.utoronto.ca> Hi All, Will anyone else be at LISA 2011 this year? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From gadavis at opencsw.org Wed Nov 2 22:40:47 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Wed, 02 Nov 2011 14:40:47 -0700 Subject: [csw-maintainers] lisa 2011 In-Reply-To: <1320200591-sup-695@pinkfloyd.chass.utoronto.ca> References: <1320200591-sup-695@pinkfloyd.chass.utoronto.ca> Message-ID: <4EB1B8DF.1010101@opencsw.org> I'm tentatively planning on it, haven't booked tix yet though. I'm doing a migration from Cfengine v2 to Puppet and could use a bit of indoctrination. Maybe Luke Kaines and Mark Burgess will get into fisticuffs this year since both of them will be there doing training for their competing platforms. On 11/1/11 7:23 PM, Ben Walton wrote: > Hi All, > > Will anyone else be at LISA 2011 this year? > > 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 bwalton at opencsw.org Thu Nov 3 00:26:21 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 02 Nov 2011 19:26:21 -0400 Subject: [csw-maintainers] lisa 2011 In-Reply-To: <4EB1B8DF.1010101@opencsw.org> References: <1320200591-sup-695@pinkfloyd.chass.utoronto.ca> <4EB1B8DF.1010101@opencsw.org> Message-ID: <1320276289-sup-1996@pinkfloyd.chass.utoronto.ca> Excerpts from Geoff Davis's message of Wed Nov 02 17:40:47 -0400 2011: > I'm tentatively planning on it, haven't booked tix yet though. I'm > doing a migration from Cfengine v2 to Puppet and could use a bit of > indoctrination. Maybe Luke Kaines and Mark Burgess will get into > fisticuffs this year since both of them will be there doing training > for their competing platforms. Cool. I'm going to be aiming for the chef stuff (which doesn't have a tutorial session unfortunately) but my goals are similar. If you come, would you have interest in doing a BoF session with me on OpenCSW? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From gadavis at opencsw.org Thu Nov 3 00:31:45 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Wed, 02 Nov 2011 16:31:45 -0700 Subject: [csw-maintainers] lisa 2011 In-Reply-To: <1320276289-sup-1996@pinkfloyd.chass.utoronto.ca> References: <1320200591-sup-695@pinkfloyd.chass.utoronto.ca> <4EB1B8DF.1010101@opencsw.org> <1320276289-sup-1996@pinkfloyd.chass.utoronto.ca> Message-ID: <4EB1D2E1.50901@opencsw.org> On 11/2/11 4:26 PM, Ben Walton wrote: > Excerpts from Geoff Davis's message of Wed Nov 02 17:40:47 -0400 2011: > >> I'm tentatively planning on it, haven't booked tix yet though. I'm >> doing a migration from Cfengine v2 to Puppet and could use a bit of >> indoctrination. Maybe Luke Kaines and Mark Burgess will get into >> fisticuffs this year since both of them will be there doing training >> for their competing platforms. > Cool. I'm going to be aiming for the chef stuff (which doesn't have a > tutorial session unfortunately) but my goals are similar. > > If you come, would you have interest in doing a BoF session with me on > OpenCSW? > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > Sure, I could do a BoF. Any idea what night so I can figure out what days to be there? From bwalton at opencsw.org Thu Nov 3 18:01:20 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 03 Nov 2011 13:01:20 -0400 Subject: [csw-maintainers] Solaris 9 deprecation/best effort Message-ID: <1320339658-sup-9268@pinkfloyd.chass.utoronto.ca> Hi All, Any objections to sending a short note to users@ and announce@ that Solaris 9 is now best effort support only? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From wilbury at opencsw.org Thu Nov 3 18:08:01 2011 From: wilbury at opencsw.org (Juraj Lutter) Date: Thu, 03 Nov 2011 18:08:01 +0100 Subject: [csw-maintainers] Solaris 9 deprecation/best effort In-Reply-To: <1320339658-sup-9268@pinkfloyd.chass.utoronto.ca> References: <1320339658-sup-9268@pinkfloyd.chass.utoronto.ca> Message-ID: <4EB2CA71.8080504@opencsw.org> On 11/03/2011 06:01 PM, Ben Walton wrote: > > Hi All, > > Any objections to sending a short note to users@ and announce@ that > Solaris 9 is now best effort support only? No. -- Juraj Lutter From maciej at opencsw.org Thu Nov 3 18:27:14 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 3 Nov 2011 17:27:14 +0000 Subject: [csw-maintainers] Solaris 9 deprecation/best effort In-Reply-To: <1320339658-sup-9268@pinkfloyd.chass.utoronto.ca> References: <1320339658-sup-9268@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/11/3 Ben Walton : > Any objections to sending a short note to users@ and announce@ that > Solaris 9 is now best effort support only? No objections. I was trying to find some kind of article on Oracle's website that would describe it, but I couldn't find the 2011 date anywhere, and the link to the description of the release life cycle threw a 404. Maciej From bwalton at opencsw.org Thu Nov 3 18:33:06 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 03 Nov 2011 13:33:06 -0400 Subject: [csw-maintainers] Solaris 9 deprecation/best effort In-Reply-To: References: <1320339658-sup-9268@pinkfloyd.chass.utoronto.ca> Message-ID: <1320341548-sup-5028@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Thu Nov 03 13:27:14 -0400 2011: > No objections. I was trying to find some kind of article on > Oracle's website that would describe it, but I couldn't find the > 2011 date anywhere, and the link to the description of the release > life cycle threw a 404. I think Jan (|woody|) shared a link when this was discussed before. I'll dig that out of my mailbox. It would be good to provide that reference. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Nov 4 01:14:04 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 03 Nov 2011 20:14:04 -0400 Subject: [csw-maintainers] small tweak to mantis and web updates Message-ID: <1320365559-sup-2029@pinkfloyd.chass.utoronto.ca> Hi All, I just updated the mantis and web db update code to use Solaris 10 catalogs as the default source. Specifically, changes are being detected from: http://mirror.opencsw.org/opencsw/unstable/sparc/5.10/catalog 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 6 19:39:46 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 06 Nov 2011 13:39:46 -0500 Subject: [csw-maintainers] Addition to the QA pages... Message-ID: <1320604713-sup-3393@pinkfloyd.chass.utoronto.ca> Hi All, I've made a test change to the QA pages on our site such that you can easily jump out to the pkgdb stats pages for a package. You can see the change on the mockup zone here: http://www-mockup.opencsw.org/qa/package/git/ Note the 'View build history and stats' link. (Alternate title welcomed.) If this is ok, I'll push to live. 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 6 22:37:47 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 6 Nov 2011 22:37:47 +0100 Subject: [csw-maintainers] Addition to the QA pages... In-Reply-To: <1320604713-sup-3393@pinkfloyd.chass.utoronto.ca> References: <1320604713-sup-3393@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Nov 6, 2011 at 7:39 PM, Ben Walton wrote: > If this is ok, I'll push to live. Looks good to me. :) From bwalton at opencsw.org Sun Nov 6 23:09:39 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 06 Nov 2011 17:09:39 -0500 Subject: [csw-maintainers] proposed change to feeds listing Message-ID: <1320617123-sup-5624@pinkfloyd.chass.utoronto.ca> Hi All, As we no longer generate the atom feed at release time through the script Phil used (it lived on bender and was served by an apache instance running there), I've made a few changes I think will be useful. The first is that the atom feeds I've been generating for a while have a new home at: http://www.opencsw.org/catalogfeeds/. These feeds have the two recently proposed changes: version in title history trimming to 31 days They also have the previously absent self link since they have a proper home now...I don't generate an html version of them (yet?) so they continue to lack that link. The second change is that I've altered the /feeds page in the mockup wordpress for preview: http://www-mockup.opencsw.org/feeds/ If this is good, I'll move the page update to the live wordpress instance. (I do still have intent to aggregate all catalog changes into a single feed but I never seem to get around to that.) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From gadavis at opencsw.org Mon Nov 7 06:45:05 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Sun, 06 Nov 2011 21:45:05 -0800 Subject: [csw-maintainers] RUNTIME_DEP_PKGS for x86 ISAs only? Message-ID: <4EB77061.5060705@opencsw.org> Hi all, I'm working on netcdf. One of the libraries pulls in CSWlibquadmath0 but only on the x86 ISAs, not on Sparc. I tried doing something like this: RUNTIME_DEP_PKGS_CSWlibnetcdff5_amd64 += CSWlibquadmath0 RUNTIME_DEP_PKGS_CSWlibnetcdff5_i386 += CSWlibquadmath0 But checkpkg doesn't like it. What am I missing? Here's a link to my makefile: http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/netcdf/trunk/Makefile?view=markup Thanks, Geoff From trygvis at opencsw.org Mon Nov 7 09:36:32 2011 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Mon, 07 Nov 2011 09:36:32 +0100 Subject: [csw-maintainers] proposed change to feeds listing In-Reply-To: <1320617123-sup-5624@pinkfloyd.chass.utoronto.ca> References: <1320617123-sup-5624@pinkfloyd.chass.utoronto.ca> Message-ID: <4EB79890.1060002@opencsw.org> On 11/06/2011 11:09 PM, Ben Walton wrote: > > Hi All, > > As we no longer generate the atom feed at release time through the > script Phil used (it lived on bender and was served by an apache > instance running there), I've made a few changes I think will be > useful. > > The first is that the atom feeds I've been generating for a while have > a new home at: http://www.opencsw.org/catalogfeeds/. These feeds have > the two recently proposed changes: > version in title > history trimming to 31 days > > They also have the previously absent self link since they have a > proper home now...I don't generate an html version of them (yet?) so > they continue to lack that link. > > The second change is that I've altered the /feeds page in the mockup > wordpress for preview: http://www-mockup.opencsw.org/feeds/ > > If this is good, I'll move the page update to the live wordpress > instance. > > (I do still have intent to aggregate all catalog changes into a single > feed but I never seem to get around to that.) A couple of notes: * The resource is served as "application/xml" but has to be "application/atom+xml". I think all that needs to be done is to either rename the files from "atom.xml" to "atom" as Apache seems to include a mapping for "atom" files, or add "atom.xml" to the mime.types file. * The self link seems wrong, it includes a reference to your home directory :) * The feed should include an tag to be valid. This is probably a decent author: OpenCSW Robot The feed doesn't contain any entries so I can't validate those yet :) -- Trygve From maciej at opencsw.org Mon Nov 7 10:06:56 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 7 Nov 2011 09:06:56 +0000 Subject: [csw-maintainers] RUNTIME_DEP_PKGS for x86 ISAs only? In-Reply-To: <4EB77061.5060705@opencsw.org> References: <4EB77061.5060705@opencsw.org> Message-ID: 2011/11/7 Geoff Davis : > I tried doing something like this: > RUNTIME_DEP_PKGS_CSWlibnetcdff5_amd64 += CSWlibquadmath0 > RUNTIME_DEP_PKGS_CSWlibnetcdff5_i386 += CSWlibquadmath0 > > But checkpkg doesn't like it. The connection between the Makefile and checkpkg is via the package itself, I generally suggest looking at the package itself to see if your Makefile changes took effect. > What am I missing? To debug, try using "mgar show-var FOO", for example: mgar show-var RUNTIME_DEP_PKGS_CSWlibnetcdff5 If you did that, you would see that your CSWlibquadmath0 did not make it into RUNTIME_DEP_PKGS_CSWlibnetcdff5. GAR doesn't pick up RUNTIME_DEP_PKGS_CSWlibnetcdff5_amd64 on its own. It only reads RUNTIME_DEP_PKGS_CSWlibnetcdff5, so you need to write something like this: RUNTIME_DEP_PKGS_CSWlibnetcdff5 += RUNTIME_DEP_PKGS_CSWlibnetcdff5_$(GARCH) Maciej From bondarenko.av at mmk.ru Mon Nov 7 10:19:31 2011 From: bondarenko.av at mmk.ru (=?koi8-r?B?4s/OxMHSxc7LzyDhzsTSxcog98nUwczYxdfJ3g==?=) Date: Mon, 7 Nov 2011 15:19:31 +0600 Subject: [csw-maintainers] Is there a reason not to fix uninitialized $REVISION warning Message-ID: <8F048E189BF2D84C8F2604829BFC4C8ABF6DEF5A2D@MSE-CCR-MB2.hq.corp.mmk.chel.su> Hi all, I'm new to OpenCSW and GAR. Can anybody tell me If there is a reason behind keeping "Use of uninitialized value $REVISION in sprint ..." warning in mkpackage? I've cloned GAR into a private mercurial repository to be able track changes not accepted in trunk. Mercurial does not expand keywords by default, so I get warning about uninitialized REVISION on each build. I find it quite annoying and fixed it in my branch (see attached patch), but I it looks like the warning is left intentionally. It is well known and mkpackage contains comment about the warning in the code. Can somebody explain me why? Thank you, Andrey -------------- next part -------------- A non-text attachment was scrubbed... Name: mkpackage-norev-warning.patch Type: application/octet-stream Size: 691 bytes Desc: mkpackage-norev-warning.patch URL: From dam at opencsw.org Mon Nov 7 10:33:45 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 7 Nov 2011 10:33:45 +0100 Subject: [csw-maintainers] RUNTIME_DEP_PKGS for x86 ISAs only? In-Reply-To: References: <4EB77061.5060705@opencsw.org> Message-ID: <9596E614-5941-492A-B33C-BDC17B9F713E@opencsw.org> Hi Geoff, Am 07.11.2011 um 10:06 schrieb Maciej (Matchek) Blizi?ski: > 2011/11/7 Geoff Davis : >> I tried doing something like this: >> RUNTIME_DEP_PKGS_CSWlibnetcdff5_amd64 += CSWlibquadmath0 >> RUNTIME_DEP_PKGS_CSWlibnetcdff5_i386 += CSWlibquadmath0 >> >> But checkpkg doesn't like it. > >> What am I missing? There is just RUNTIME_DEP_PKGS_, no isa suffix. If you want this you must also RUNTIME_DEP_PKGS_CSWlibnetcdff5 += $(RUNTIME_DEP_PKGS_CSWlibnetcdff5_$(GARCH)) Best regards -- Dago From maciej at opencsw.org Mon Nov 7 10:35:54 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 7 Nov 2011 09:35:54 +0000 Subject: [csw-maintainers] RUNTIME_DEP_PKGS for x86 ISAs only? In-Reply-To: <9596E614-5941-492A-B33C-BDC17B9F713E@opencsw.org> References: <4EB77061.5060705@opencsw.org> <9596E614-5941-492A-B33C-BDC17B9F713E@opencsw.org> Message-ID: 2011/11/7 Dagobert Michelsen : > ?RUNTIME_DEP_PKGS_CSWlibnetcdff5 += $(RUNTIME_DEP_PKGS_CSWlibnetcdff5_$(GARCH)) Right, I forgot about the $( ... ) when I replied. BTW, did you not see my reply? Maciej From maciej at opencsw.org Mon Nov 7 10:40:58 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 7 Nov 2011 09:40:58 +0000 Subject: [csw-maintainers] Is there a reason not to fix uninitialized $REVISION warning In-Reply-To: <8F048E189BF2D84C8F2604829BFC4C8ABF6DEF5A2D@MSE-CCR-MB2.hq.corp.mmk.chel.su> References: <8F048E189BF2D84C8F2604829BFC4C8ABF6DEF5A2D@MSE-CCR-MB2.hq.corp.mmk.chel.su> Message-ID: 2011/11/7 ?????????? ?????? ?????????? : > I'm new to OpenCSW and GAR. Can anybody tell me If there is a reason > behind keeping "Use of uninitialized value $REVISION in sprint ..." warning > in mkpackage? > > I've cloned GAR into a private mercurial repository to be able track changes > not accepted in trunk. Mercurial does not expand keywords by default, so > I get warning about uninitialized REVISION on each build. I find it quite > annoying and fixed it in my branch (see attached patch), but I it looks like > the warning is left intentionally. It is well known and mkpackage contains > comment about the warning in the code. Can somebody explain me why? I left the comment there in the hope that Dago who reads the commit log on the devel list would see it and fix it. But it did't happen, so the warning remained. I committed your patch, thanks! http://sourceforge.net/apps/trac/gar/changeset/16119 Maciej From maciej at opencsw.org Mon Nov 7 10:44:30 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 7 Nov 2011 09:44:30 +0000 Subject: [csw-maintainers] Is there a reason not to fix uninitialized $REVISION warning In-Reply-To: <8F048E189BF2D84C8F2604829BFC4C8ABF6DEF5A2D@MSE-CCR-MB2.hq.corp.mmk.chel.su> References: <8F048E189BF2D84C8F2604829BFC4C8ABF6DEF5A2D@MSE-CCR-MB2.hq.corp.mmk.chel.su> Message-ID: 2011/11/7 ?????????? ?????? ?????????? : > I get warning about uninitialized REVISION on each build. I find it quite > annoying (...) Me too. However, the warning, betraying the use of mkpackage, came in handy once: it once showed that GAR calls mkpackage where it doesn't really need to. When I'm building larger packages, I always need to wait for GAR just to print the list of built files. It turns out that GAR makes expensive calls to mkpackage just to print the file names. Maciej From dam at opencsw.org Mon Nov 7 11:16:35 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 7 Nov 2011 11:16:35 +0100 Subject: [csw-maintainers] RUNTIME_DEP_PKGS for x86 ISAs only? In-Reply-To: References: <4EB77061.5060705@opencsw.org> <9596E614-5941-492A-B33C-BDC17B9F713E@opencsw.org> Message-ID: <724AEEBB-8FF5-434E-BC04-48BD7D1F842D@opencsw.org> Hi Maciej, Am 07.11.2011 um 10:35 schrieb Maciej (Matchek) Blizi?ski: > 2011/11/7 Dagobert Michelsen : >> RUNTIME_DEP_PKGS_CSWlibnetcdff5 += $(RUNTIME_DEP_PKGS_CSWlibnetcdff5_$(GARCH)) > > Right, I forgot about the $( ... ) when I replied. BTW, did you not > see my reply? Ahhh, not the last line. I thought you were telling about debugging GAR variables and then replied to the original post as I didn't want to comment on the debugging thing :-) Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From gadavis at opencsw.org Mon Nov 7 16:15:14 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Mon, 07 Nov 2011 07:15:14 -0800 Subject: [csw-maintainers] RUNTIME_DEP_PKGS for x86 ISAs only? In-Reply-To: References: <4EB77061.5060705@opencsw.org> Message-ID: <4EB7F602.60001@opencsw.org> On 11/7/11 1:06 AM, Maciej (Matchek) Blizi?ski wrote: > mgar show-var RUNTIME_DEP_PKGS_CSWlibnetcdff5 Hmm, mgar popped up a warning stating that show-var doesn't evaluate for modulations, so I guess I won't know until I remerge/repackage. From skayser at opencsw.org Mon Nov 7 17:13:00 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 7 Nov 2011 17:13:00 +0100 Subject: [csw-maintainers] proposed change to feeds listing In-Reply-To: <4EB79890.1060002@opencsw.org> References: <1320617123-sup-5624@pinkfloyd.chass.utoronto.ca> <4EB79890.1060002@opencsw.org> Message-ID: <20111107161300.GI26160@sebastiankayser.de> * Trygve Laugst?l wrote: > * The feed should include an tag to be valid. This is probably > a decent author: > > > OpenCSW Robot > > > The feed doesn't contain any entries so I can't validate those yet :) The dublin feeds seem to be the only ones w/o entries (maybe no manual package integration in the last 31 days?). You can peek at the unstable feeds for entries. For validation purposes I also found the W3C validator quite useful: http://validator.w3.org/feed/ Sebastian From maciej at opencsw.org Mon Nov 7 17:13:48 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 7 Nov 2011 16:13:48 +0000 Subject: [csw-maintainers] RUNTIME_DEP_PKGS for x86 ISAs only? In-Reply-To: <4EB7F602.60001@opencsw.org> References: <4EB77061.5060705@opencsw.org> <4EB7F602.60001@opencsw.org> Message-ID: 2011/11/7 Geoff Davis : > On 11/7/11 1:06 AM, Maciej (Matchek) Blizi?ski wrote: >> >> mgar show-var RUNTIME_DEP_PKGS_CSWlibnetcdff5 > > Hmm, mgar popped up a warning stating that show-var doesn't evaluate for > modulations, so I guess I won't know until I remerge/repackage. GARCH doesn't change with modulations, so in this case it doesn't matter. One thing I noticed: you also set *_amd64. This has no effect, because GARCH is never set to "amd64". GARCH is the architecture, which is either "sparc" or "i386". It is confusing that the value "i386" can mean either generally the Intel architecture (32-bit and 64-bit), or can mean specifically the 80386 process / its instruction set. In this case, it means generally Intel. Maciej From maciej at opencsw.org Mon Nov 7 17:15:15 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 7 Nov 2011 16:15:15 +0000 Subject: [csw-maintainers] proposed change to feeds listing In-Reply-To: <20111107161300.GI26160@sebastiankayser.de> References: <1320617123-sup-5624@pinkfloyd.chass.utoronto.ca> <4EB79890.1060002@opencsw.org> <20111107161300.GI26160@sebastiankayser.de> Message-ID: 2011/11/7 Sebastian Kayser : > The dublin feeds seem to be the only ones w/o entries (maybe no manual > package integration in the last 31 days?). Correct, no updates there for some time now. From gadavis at opencsw.org Mon Nov 7 17:25:15 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Mon, 07 Nov 2011 08:25:15 -0800 Subject: [csw-maintainers] RUNTIME_DEP_PKGS for x86 ISAs only? In-Reply-To: References: <4EB77061.5060705@opencsw.org> <4EB7F602.60001@opencsw.org> Message-ID: <4EB8066B.1070109@opencsw.org> On 11/7/11 8:13 AM, Maciej (Matchek) Blizi?ski wrote: > 2011/11/7 Geoff Davis: >> On 11/7/11 1:06 AM, Maciej (Matchek) Blizi?ski wrote: >>> mgar show-var RUNTIME_DEP_PKGS_CSWlibnetcdff5 >> Hmm, mgar popped up a warning stating that show-var doesn't evaluate for >> modulations, so I guess I won't know until I remerge/repackage. > GARCH doesn't change with modulations, so in this case it doesn't matter. Well for whatever reason, it didn't show up on unstable10x initially. Now it is. > > One thing I noticed: you also set *_amd64. This has no effect, > because GARCH is never set to "amd64". GARCH is the architecture, > which is either "sparc" or "i386". It is confusing that the value > "i386" can mean either generally the Intel architecture (32-bit and > 64-bit), or can mean specifically the 80386 process / its instruction > set. In this case, it means generally Intel. > > Maciej Noted. I'll yank that one out. The 32-bit ISA value is pentium or pentium-pro then? From dam at opencsw.org Mon Nov 7 17:27:21 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 7 Nov 2011 17:27:21 +0100 Subject: [csw-maintainers] RUNTIME_DEP_PKGS for x86 ISAs only? In-Reply-To: <4EB8066B.1070109@opencsw.org> References: <4EB77061.5060705@opencsw.org> <4EB7F602.60001@opencsw.org> <4EB8066B.1070109@opencsw.org> Message-ID: <11B79DB6-5647-4C49-A0ED-6DBD5A85BF0C@opencsw.org> Hi Geoff, Am 07.11.2011 um 17:25 schrieb Geoff Davis: > On 11/7/11 8:13 AM, Maciej (Matchek) Blizi?ski wrote: >> 2011/11/7 Geoff Davis: >>> On 11/7/11 1:06 AM, Maciej (Matchek) Blizi?ski wrote: >>>> mgar show-var RUNTIME_DEP_PKGS_CSWlibnetcdff5 >>> Hmm, mgar popped up a warning stating that show-var doesn't evaluate for >>> modulations, so I guess I won't know until I remerge/repackage. >> GARCH doesn't change with modulations, so in this case it doesn't matter. > Well for whatever reason, it didn't show up on unstable10x initially. Now it is. >> >> One thing I noticed: you also set *_amd64. This has no effect, >> because GARCH is never set to "amd64". GARCH is the architecture, >> which is either "sparc" or "i386". It is confusing that the value >> "i386" can mean either generally the Intel architecture (32-bit and >> 64-bit), or can mean specifically the 80386 process / its instruction >> set. In this case, it means generally Intel. > > Noted. I'll yank that one out. The 32-bit ISA value is pentium or pentium-pro then? The 32 bit ISA is pentium-pro, but that is not relevant because this is about GARCH, the ARCH on which you are building. Valid values are only sparc and i386. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From skayser at opencsw.org Mon Nov 7 17:29:18 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 7 Nov 2011 17:29:18 +0100 Subject: [csw-maintainers] proposed change to feeds listing In-Reply-To: <1320617123-sup-5624@pinkfloyd.chass.utoronto.ca> References: <1320617123-sup-5624@pinkfloyd.chass.utoronto.ca> Message-ID: <20111107162918.GJ26160@sebastiankayser.de> * Ben Walton wrote: > The first is that the atom feeds I've been generating for a while have > a new home at: http://www.opencsw.org/catalogfeeds/. These feeds have > the two recently proposed changes: > version in title > history trimming to 31 days Thanks, Ben. With day-based trimming they are currently still quite big (~250K). I've hocked up the unstable/5.10/x86 feed to ceeswi on #opencsw nevertheless, (prefix "unstable"), let's how she likes it. > The second change is that I've altered the /feeds page in the mockup > wordpress for preview: http://www-mockup.opencsw.org/feeds/ > > If this is good, I'll move the page update to the live wordpress > instance. Sweet. Looks good! Sebastian From jgoerzen at opencsw.org Mon Nov 7 17:50:43 2011 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Mon, 07 Nov 2011 08:50:43 -0800 Subject: [csw-maintainers] INITSMF not generating scripts Message-ID: <4EB80C63.7060107@opencsw.org> Hello, I recently committed an updated recipe for CSWdovecot (http://sourceforge.net/apps/trac/gar/changeset/16069). For some reason the class action INITSMF is not generating any scripts. Could someone help me figure out why? It was working before this commit and I don't see why it shouldn't work. Thanks, Jake From dam at opencsw.org Mon Nov 7 18:07:35 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 7 Nov 2011 18:07:35 +0100 Subject: [csw-maintainers] INITSMF not generating scripts In-Reply-To: <4EB80C63.7060107@opencsw.org> References: <4EB80C63.7060107@opencsw.org> Message-ID: <122A58E8-C0E0-4635-A0D7-E1832DB8CD82@opencsw.org> Hi Jake, Am 07.11.2011 um 17:50 schrieb Jake Goerzen: > I recently committed an updated recipe for CSWdovecot (http://sourceforge.net/apps/trac/gar/changeset/16069). For some reason the class action INITSMF is not generating any scripts. Could someone help me figure out why? It was working before this commit and I don't see why it shouldn't work. Sure, some issues: - This rule does not exist (note the double-minus): pre-merge--modulated: Therefore the init-script is never installed in the right place - You inserted pre-merge-modulated which operates on $(PKGROOT), not $(DESTDIR) as post-install - use EXTRA_MERGE_EXCLUDE_FILES instead of the PROTOTYPE_FILTER makes it more readable Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From jgoerzen at opencsw.org Mon Nov 7 18:12:26 2011 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Mon, 07 Nov 2011 09:12:26 -0800 Subject: [csw-maintainers] INITSMF not generating scripts In-Reply-To: <122A58E8-C0E0-4635-A0D7-E1832DB8CD82@opencsw.org> References: <4EB80C63.7060107@opencsw.org> <122A58E8-C0E0-4635-A0D7-E1832DB8CD82@opencsw.org> Message-ID: <4EB8117A.1020209@opencsw.org> On 11/7/2011 9:07 AM, Dagobert Michelsen wrote: > Hi Jake, > > Am 07.11.2011 um 17:50 schrieb Jake Goerzen: >> I recently committed an updated recipe for CSWdovecot (http://sourceforge.net/apps/trac/gar/changeset/16069). For some reason the class action INITSMF is not generating any scripts. Could someone help me figure out why? It was working before this commit and I don't see why it shouldn't work. > Sure, some issues: > > - This rule does not exist (note the double-minus): > pre-merge--modulated: > Therefore the init-script is never installed in the right place > - You inserted pre-merge-modulated which operates on $(PKGROOT), not $(DESTDIR) as post-install > - use EXTRA_MERGE_EXCLUDE_FILES instead of the PROTOTYPE_FILTER makes it more readable > > > Best regards > > -- Dago > Thank you Sir, It should have caught that one. Thanks, Jake From bonivart at opencsw.org Mon Nov 7 18:32:13 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 7 Nov 2011 18:32:13 +0100 Subject: [csw-maintainers] INITSMF not generating scripts In-Reply-To: <4EB8117A.1020209@opencsw.org> References: <4EB80C63.7060107@opencsw.org> <122A58E8-C0E0-4635-A0D7-E1832DB8CD82@opencsw.org> <4EB8117A.1020209@opencsw.org> Message-ID: On Mon, Nov 7, 2011 at 6:12 PM, Jake Goerzen wrote: > On 11/7/2011 9:07 AM, Dagobert Michelsen wrote: >> >> Hi Jake, >> >> Am 07.11.2011 um 17:50 schrieb Jake Goerzen: >>> >>> ?I recently committed an updated recipe for CSWdovecot >>> (http://sourceforge.net/apps/trac/gar/changeset/16069). ?For some reason the >>> class action INITSMF is not generating any scripts. ?Could someone help me >>> figure out why? ?It was working before this commit and I don't see why it >>> shouldn't work. >> >> Sure, some issues: >> >> - This rule does not exist (note the double-minus): >> ? ? ?pre-merge--modulated: >> ? Therefore the init-script is never installed in the right place >> - You inserted pre-merge-modulated which operates on $(PKGROOT), not >> $(DESTDIR) as post-install >> - use EXTRA_MERGE_EXCLUDE_FILES instead of the PROTOTYPE_FILTER makes it >> more readable >> >> >> Best regards >> >> ? -- Dago >> > > Thank you Sir, ?It should have caught that one. In these cases I find it very helpful to actually look inside the generated package: (trimmed to the interesting parts) bonivart at login[clamav]$ gzcat clamav-0.97.3\,REV\=2011.10.27-SunOS5.10-i386-CSW.pkg.gz | strings | more ... CLASSES=none cswusergroup ugfiles cswmigrateconf cswcpsampleconf cswinitsmf ... 1 f cswcpsampleconf /etc/opt/csw/clamav-milter.conf.CSW 0644 root bin 8686 37116 1319724990 1 f cswcpsampleconf /etc/opt/csw/clamd.conf.CSW 0644 root bin 14957 60524 1319724990 1 f cswcpsampleconf /etc/opt/csw/freshclam.conf.CSW 0600 root bin 7774 38570 1319724990 1 d none /etc/opt/csw/init.d 0755 root bin 1 f cswinitsmf /etc/opt/csw/init.d/cswclamav-milter 0755 root bin 2882 25050 1319724990 1 f cswinitsmf /etc/opt/csw/init.d/cswclamd 0755 root bin 1109 18216 1319724990 1 d none /etc/opt/csw/pkg 0755 root bin 1 d none /etc/opt/csw/pkg/CSWclamav 0755 root bin 1 f cswmigrateconf /etc/opt/csw/pkg/CSWclamav/cswmigrateconf 0644 root bin 135 11755 1319724994 1 f cswusergroup /etc/opt/csw/pkg/CSWclamav/cswusergroup 0644 root bin 50 4535 1319724990 1 f none /opt/csw/bin/clambc 0755 root bin 70004 8658 1319724993 1 f none /opt/csw/bin/clamconf 0755 root bin 71320 25934 1319724993 ... 07070100104776000081a40000271300002710000000014ea968b5000002c40000012f000001cb00000000000000000000000f00000000install /depend P CSWcas-cpsampleconf cas_cpsampleconf - Class action script cpsampleconf P CSWcas-initsmf cas_initsmf - Class action script initsmf P CSWcas-migrateconf cas_migrateconf - Class action script migrateconf P CSWcas-usergroup cas_usergroup - Class action script usergroup P CSWcommon common - common files and dirs for CSW packages P CSWlibclam6 libclam6 - Clam AntiVirus Library P CSWlibz1 libz1 - Zlib data compression library, libz.so.1 P CSWlibltdl7 libltdl7 - Libtool libltdl.so.7 from libtool 2.x P CSWlibncurses5 libncurses5 - A free software emulation of curses, libncurses.so.5 P CSWlibbz2-1-0 libbz2_1_0 - Compression library, libbz2.so.1.0 P CSWlibiconv2 libiconv2 - GNU iconv library, libiconv.so.2 From jgoerzen at opencsw.org Mon Nov 7 18:57:24 2011 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Mon, 07 Nov 2011 09:57:24 -0800 Subject: [csw-maintainers] INITSMF not generating scripts In-Reply-To: References: <4EB80C63.7060107@opencsw.org> <122A58E8-C0E0-4635-A0D7-E1832DB8CD82@opencsw.org> <4EB8117A.1020209@opencsw.org> Message-ID: <4EB81C04.8030005@opencsw.org> On 11/7/2011 9:32 AM, Peter Bonivart wrote: > On Mon, Nov 7, 2011 at 6:12 PM, Jake Goerzen wrote: >> On 11/7/2011 9:07 AM, Dagobert Michelsen wrote: >>> Hi Jake, >>> >>> Am 07.11.2011 um 17:50 schrieb Jake Goerzen: >>>> I recently committed an updated recipe for CSWdovecot >>>> (http://sourceforge.net/apps/trac/gar/changeset/16069). For some reason the >>>> class action INITSMF is not generating any scripts. Could someone help me >>>> figure out why? It was working before this commit and I don't see why it >>>> shouldn't work. >>> Sure, some issues: >>> >>> - This rule does not exist (note the double-minus): >>> pre-merge--modulated: >>> Therefore the init-script is never installed in the right place >>> - You inserted pre-merge-modulated which operates on $(PKGROOT), not >>> $(DESTDIR) as post-install >>> - use EXTRA_MERGE_EXCLUDE_FILES instead of the PROTOTYPE_FILTER makes it >>> more readable >>> >>> >>> Best regards >>> >>> -- Dago >>> >> Thank you Sir, It should have caught that one. > In these cases I find it very helpful to actually look inside the > generated package: > > (trimmed to the interesting parts) > > bonivart at login[clamav]$ gzcat > clamav-0.97.3\,REV\=2011.10.27-SunOS5.10-i386-CSW.pkg.gz | strings | > more > ... I do normally look into the package contents like this but I missed it this time. Thanks for helping! Jake From gadavis at opencsw.org Mon Nov 7 19:02:39 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Mon, 07 Nov 2011 10:02:39 -0800 Subject: [csw-maintainers] RUNTIME_DEP_PKGS for x86 ISAs only? In-Reply-To: <11B79DB6-5647-4C49-A0ED-6DBD5A85BF0C@opencsw.org> References: <4EB77061.5060705@opencsw.org> <4EB7F602.60001@opencsw.org> <4EB8066B.1070109@opencsw.org> <11B79DB6-5647-4C49-A0ED-6DBD5A85BF0C@opencsw.org> Message-ID: <4EB81D3F.40101@opencsw.org> A summary write-up of this is now up on the Gar wiki: https://sourceforge.net/apps/trac/gar/wiki/Prototypes#Architecture-specificPackageDependencies From trygvis at opencsw.org Mon Nov 7 21:27:48 2011 From: trygvis at opencsw.org (=?ISO-8859-15?Q?Trygve_Laugst=F8l?=) Date: Mon, 07 Nov 2011 21:27:48 +0100 Subject: [csw-maintainers] proposed change to feeds listing In-Reply-To: <20111107161300.GI26160@sebastiankayser.de> References: <1320617123-sup-5624@pinkfloyd.chass.utoronto.ca> <4EB79890.1060002@opencsw.org> <20111107161300.GI26160@sebastiankayser.de> Message-ID: <4EB83F44.8060806@opencsw.org> On 11/07/2011 05:13 PM, Sebastian Kayser wrote: > * Trygve Laugst?l wrote: >> * The feed should include an tag to be valid. This is probably >> a decent author: >> >> >> OpenCSW Robot >> >> >> The feed doesn't contain any entries so I can't validate those yet :) > > The dublin feeds seem to be the only ones w/o entries (maybe no manual > package integration in the last 31 days?). You can peek at the unstable > feeds for entries. For validation purposes I also found the W3C > validator quite useful: http://validator.w3.org/feed/ Ah, I didn't check the other feeds. The w3.org validator was down earlier today, but I used [1]. I tend to run the feeds by both as they react to different things. [1]: www.validome.org/rss-atom/ -- Trygve From trygvis at opencsw.org Mon Nov 7 21:38:27 2011 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Mon, 07 Nov 2011 21:38:27 +0100 Subject: [csw-maintainers] proposed change to feeds listing In-Reply-To: <20111107162918.GJ26160@sebastiankayser.de> References: <1320617123-sup-5624@pinkfloyd.chass.utoronto.ca> <20111107162918.GJ26160@sebastiankayser.de> Message-ID: <4EB841C3.2070506@opencsw.org> On 11/07/2011 05:29 PM, Sebastian Kayser wrote: > * Ben Walton wrote: >> The first is that the atom feeds I've been generating for a while have >> a new home at: http://www.opencsw.org/catalogfeeds/. These feeds have >> the two recently proposed changes: >> version in title >> history trimming to 31 days > > Thanks, Ben. With day-based trimming they are currently still quite big > (~250K). I've hocked up the unstable/5.10/x86 feed to ceeswi on #opencsw > nevertheless, (prefix "unstable"), let's how she likes it. If you want you can split the feed into many different feeds, or perhaps a file with the 10 first entries and a file with the rest if you anticipate most people to just want the latest 10 entries. The full story is in [1], but long story short: In the first "page": On the other pages: [1]: http://tools.ietf.org/html/rfc5005 >> The second change is that I've altered the /feeds page in the mockup >> wordpress for preview: http://www-mockup.opencsw.org/feeds/ >> >> If this is good, I'll move the page update to the live wordpress >> instance. > > Sweet. Looks good! +1 -- Trygve From bwalton at opencsw.org Tue Nov 8 02:13:40 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 07 Nov 2011 20:13:40 -0500 Subject: [csw-maintainers] proposed change to feeds listing In-Reply-To: <4EB79890.1060002@opencsw.org> References: <1320617123-sup-5624@pinkfloyd.chass.utoronto.ca> <4EB79890.1060002@opencsw.org> Message-ID: <1320714782-sup-846@pinkfloyd.chass.utoronto.ca> Excerpts from Trygve Laugst?l's message of Mon Nov 07 03:36:32 -0500 2011: Hi Trygve, > * The resource is served as "application/xml" but has to be > "application/atom+xml". I think all that needs to be done is to > either rename the files from "atom.xml" to "atom" as Apache seems to > include a mapping for "atom" files, or add "atom.xml" to the > mime.types file. Corrected. I took the first approach of simply renaming the feed files. > * The self link seems wrong, it includes a reference to your home > directory :) Doh! Fixed. > * The feed should include an tag to be valid. This is > probably a decent author: > > > OpenCSW Robot > Added. The last time I ran these through a validator it didn't care about this, but it did want a valid author (which requires ) for each entry. I've run (one of) them through both validators and it passed them both now. I also updated the links in the /feeds wordpress page on mockup. 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 8 02:14:25 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 07 Nov 2011 20:14:25 -0500 Subject: [csw-maintainers] proposed change to feeds listing In-Reply-To: <20111107161300.GI26160@sebastiankayser.de> References: <1320617123-sup-5624@pinkfloyd.chass.utoronto.ca> <4EB79890.1060002@opencsw.org> <20111107161300.GI26160@sebastiankayser.de> Message-ID: <1320714834-sup-3056@pinkfloyd.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Mon Nov 07 11:13:00 -0500 2011: > The dublin feeds seem to be the only ones w/o entries (maybe no > manual package integration in the last 31 days?). You can peek at > the unstable feeds for entries. For validation purposes I also found > the W3C validator quite useful: http://validator.w3.org/feed/ These were actually brand new. They won't see entries until the next integration run so they're not much use right now. 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 8 02:18:34 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 07 Nov 2011 20:18:34 -0500 Subject: [csw-maintainers] proposed change to feeds listing In-Reply-To: <20111107162918.GJ26160@sebastiankayser.de> References: <1320617123-sup-5624@pinkfloyd.chass.utoronto.ca> <20111107162918.GJ26160@sebastiankayser.de> Message-ID: <1320714874-sup-6299@pinkfloyd.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Mon Nov 07 11:29:18 -0500 2011: > Thanks, Ben. With day-based trimming they are currently still quite > big (~250K). I've hocked up the unstable/5.10/x86 feed to ceeswi on > #opencsw nevertheless, (prefix "unstable"), let's how she likes it. I can trim it to two weeks with a minimum entry threshold for slow moving feeds like the dublin catalog? We could implement the 'paged' feeds that Trygve suggested but I'm not sure it would work nicely for a bursty source such as this. I'm more inclined to set a minimum number of entries to keep (so the feed never empties) and then trim stale entries that are older than X days. Trimming currently happens after new entries are added but that could happen first so that new entries are never weighted in the minimum entry calculation? Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Nov 8 02:41:40 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 07 Nov 2011 20:41:40 -0500 Subject: [csw-maintainers] Addition to the QA pages... In-Reply-To: References: <1320604713-sup-3393@pinkfloyd.chass.utoronto.ca> Message-ID: <1320716476-sup-3122@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Sun Nov 06 16:37:47 -0500 2011: > On Sun, Nov 6, 2011 at 7:39 PM, Ben Walton wrote: > > If this is ok, I'll push to live. > > Looks good to me. :) Made this live with r586. 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 8 09:35:15 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 8 Nov 2011 09:35:15 +0100 Subject: [csw-maintainers] INITSMF not generating scripts In-Reply-To: <4EB8117A.1020209@opencsw.org> References: <4EB80C63.7060107@opencsw.org> <122A58E8-C0E0-4635-A0D7-E1832DB8CD82@opencsw.org> <4EB8117A.1020209@opencsw.org> Message-ID: <7061E852-7CAB-4347-A827-43F9E8F03AD3@opencsw.org> Hi Jake, Am 07.11.2011 um 18:12 schrieb Jake Goerzen: > On 11/7/2011 9:07 AM, Dagobert Michelsen wrote: >> - This rule does not exist (note the double-minus): >> pre-merge--modulated: >> Therefore the init-script is never installed in the right place > > Thank you Sir, It should have caught that one. I can't count how often this happened to me when I stared on a piece of code for an hour and a colleague spotted the issue in 10 seconds ;-) Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Tue Nov 8 10:41:45 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 8 Nov 2011 09:41:45 +0000 Subject: [csw-maintainers] RUNTIME_DEP_PKGS for x86 ISAs only? In-Reply-To: <4EB81D3F.40101@opencsw.org> References: <4EB77061.5060705@opencsw.org> <4EB7F602.60001@opencsw.org> <4EB8066B.1070109@opencsw.org> <11B79DB6-5647-4C49-A0ED-6DBD5A85BF0C@opencsw.org> <4EB81D3F.40101@opencsw.org> Message-ID: 2011/11/7 Geoff Davis : > A summary write-up of this is now up on the Gar wiki: > https://sourceforge.net/apps/trac/gar/wiki/Prototypes#Architecture-specificPackageDependencies Cool, improving our documentation one section at a time! From bwalton at opencsw.org Wed Nov 9 03:45:25 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 08 Nov 2011 21:45:25 -0500 Subject: [csw-maintainers] minimum solaris 10 patche set / release Message-ID: <1320806459-sup-3336@pinkfloyd.chass.utoronto.ca> Hi All, I was helping a user in irc tonight and we determined that his base issue is that our libkrb5.so.3 requires libresolv.so.2 (SUNW_2.2.1). He was on a solaris 10 u1 system and didn't have the required symbol version available. We listed minimum patch levels and version requirements for 8 and 9. I think this means that we now have an identified minimum for 10. I'm not sure how to isolate the patch that delivers the required symbol versions. Can somebody help with this? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Wed Nov 9 10:44:01 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 9 Nov 2011 10:44:01 +0100 Subject: [csw-maintainers] minimum solaris 10 patche set / release In-Reply-To: <1320806459-sup-3336@pinkfloyd.chass.utoronto.ca> References: <1320806459-sup-3336@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Nov 9, 2011 at 3:45 AM, Ben Walton wrote: > > Hi All, > > I was helping a user in irc tonight and we determined that his base > issue is that our libkrb5.so.3 requires libresolv.so.2 (SUNW_2.2.1). > He was on a solaris 10 u1 system and didn't have the required symbol > version available. > > We listed minimum patch levels and version requirements for 8 and 9. > I think this means that we now have an identified minimum for 10. > > I'm not sure how to isolate the patch that delivers the required > symbol versions. ?Can somebody help with this? I don't remember us ever specifying a minimum patch level. Don't you mean the patches needed for pkgadd to install pkg-get/pkgutil? Blastwave just had a general recommendation that your system should be "fully patched" or something like that. I think that's reasonable to write on our get started pages as well since it's always the first question you get back from support anyway. For us to track a wider range of patch levels is not feasible. /peter From pfelecan at opencsw.org Wed Nov 9 11:35:38 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 09 Nov 2011 11:35:38 +0100 Subject: [csw-maintainers] minimum solaris 10 patche set / release In-Reply-To: (Peter Bonivart's message of "Wed, 9 Nov 2011 10:44:01 +0100") References: <1320806459-sup-3336@pinkfloyd.chass.utoronto.ca> Message-ID: Peter Bonivart writes: > On Wed, Nov 9, 2011 at 3:45 AM, Ben Walton wrote: >> >> Hi All, >> >> I was helping a user in irc tonight and we determined that his base >> issue is that our libkrb5.so.3 requires libresolv.so.2 (SUNW_2.2.1). >> He was on a solaris 10 u1 system and didn't have the required symbol >> version available. >> >> We listed minimum patch levels and version requirements for 8 and 9. >> I think this means that we now have an identified minimum for 10. >> >> I'm not sure how to isolate the patch that delivers the required >> symbol versions. ?Can somebody help with this? > > I don't remember us ever specifying a minimum patch level. Don't you > mean the patches needed for pkgadd to install pkg-get/pkgutil? > > Blastwave just had a general recommendation that your system should be > "fully patched" or something like that. I think that's reasonable to > write on our get started pages as well since it's always the first > question you get back from support anyway. For us to track a wider > range of patch levels is not feasible. So, we support Solaris 10 u10, isn't it? -- Peter From maciej at opencsw.org Wed Nov 9 12:23:19 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 9 Nov 2011 11:23:19 +0000 Subject: [csw-maintainers] minimum solaris 10 patche set / release In-Reply-To: References: <1320806459-sup-3336@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/11/9 Peter FELECAN : > So, we support Solaris 10 u10, isn't it? Barring the recent deprecation of Solaris 9, this is where we built all our binaries. Binaries built on Solaris 9 can't possibly know anything about Solaris 10 updates, so I guess that the U10 requirement is only for the 64-bit Intel binaries, which can't be built on Solaris 9. For Solaris 10, is it the update number, or certain patches that we support? Or is it patches, but we say we support U10, because it guarantees that certain patches are installed? Maciej From bwalton at opencsw.org Wed Nov 9 14:54:19 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Nov 2011 08:54:19 -0500 Subject: [csw-maintainers] minimum solaris 10 patche set / release In-Reply-To: References: <1320806459-sup-3336@pinkfloyd.chass.utoronto.ca> Message-ID: <1320846661-sup-3519@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Wed Nov 09 06:23:19 -0500 2011: > For Solaris 10, is it the update number, or certain patches that we > support? Or is it patches, but we say we support U10, because it > guarantees that certain patches are installed? The former is much easier but the latter is nicer for sites that don't live upgrade. I'm open to either, I think, but would prefer the patches option. For most purposes, this won't matter but in corner cases such as the one last night, it is clearly important. The oldest system I could lay hands on had the required symbol versions, so it is possible that the system last night, fully patched would work too... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Wed Nov 9 17:28:31 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Nov 2011 16:28:31 +0000 Subject: [csw-maintainers] Solaris 11 Message-ID: I've just watched the Solaris 11 broadcast. Should we start looking into IPS backend for GAR? Even if we can't use class action scripts, we can at least deliver the basic set of GNU userland. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonivart at opencsw.org Wed Nov 9 17:35:22 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 9 Nov 2011 17:35:22 +0100 Subject: [csw-maintainers] Solaris 11 In-Reply-To: References: Message-ID: On Wed, Nov 9, 2011 at 5:28 PM, Maciej (Matchek) Blizinski wrote: > I've just watched the Solaris 11 broadcast. ?Should we start looking into > IPS backend for GAR? ?Even if we can't use class action scripts, we can at > least deliver the basic set of GNU userland. Yes, I think we should support IPS in some form relatively soon. No, I don't think we should start another project since there's a million things in the air already. From maciej at opencsw.org Wed Nov 9 17:44:51 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 9 Nov 2011 16:44:51 +0000 Subject: [csw-maintainers] Solaris 11 In-Reply-To: References: Message-ID: 2011/11/9 Peter Bonivart : > Yes, I think we should support IPS in some form relatively soon. > No, I don't think we should start another project since there's a > million things in the air already. The trick will be to scale it appropriately, so we might have a small, but finite project that we can complete. For example: A proof-of-concept IPS building, and coreutils built with it (or whatever package people think is the most useful). Maciej From dam at opencsw.org Wed Nov 9 17:46:45 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 9 Nov 2011 17:46:45 +0100 Subject: [csw-maintainers] Solaris 11 In-Reply-To: References: Message-ID: <05DE4845-73C9-4A88-A338-73CAA3490055@opencsw.org> Hi, Am 09.11.2011 um 17:44 schrieb Maciej (Matchek) Blizi?ski: > 2011/11/9 Peter Bonivart : >> Yes, I think we should support IPS in some form relatively soon. >> No, I don't think we should start another project since there's a >> million things in the air already. > > The trick will be to scale it appropriately, so we might have a small, > but finite project that we can complete. For example: A > proof-of-concept IPS building, and coreutils built with it (or > whatever package people think is the most useful). True. In case anyone missed it: http://www.oracle.com/technetwork/server-storage/solaris11/downloads/index.html Bets regrads -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Wed Nov 9 17:49:07 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 9 Nov 2011 17:49:07 +0100 Subject: [csw-maintainers] Solaris 11 In-Reply-To: References: Message-ID: <33A3537C-3F8A-4891-ADF7-F180E3709432@opencsw.org> Hi Maciej, Am 09.11.2011 um 17:44 schrieb Maciej (Matchek) Blizi?ski: > 2011/11/9 Peter Bonivart : >> Yes, I think we should support IPS in some form relatively soon. >> No, I don't think we should start another project since there's a >> million things in the air already. > > The trick will be to scale it appropriately, so we might have a small, > but finite project that we can complete. For example: A > proof-of-concept IPS building, and coreutils built with it (or > whatever package people think is the most useful). Here is a brief list of things to do: # Set up IPS Provisioning server # Install new instances on T5220 and vSphere using the local probivioning server # Install compilers and stuff # Setup mounts and stuff from the farm # Bootstrap with System V packages from OpenCSW # Make IPS backend with just files # Transform CAS to SMF # Setup provisioning on primary mirror on pkg.opencsw.org in Erlangen # Push targets for GAR Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Wed Nov 9 18:14:28 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 9 Nov 2011 17:14:28 +0000 Subject: [csw-maintainers] Addition to the QA pages... In-Reply-To: <1320716476-sup-3122@pinkfloyd.chass.utoronto.ca> References: <1320604713-sup-3393@pinkfloyd.chass.utoronto.ca> <1320716476-sup-3122@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/11/8 Ben Walton : > Made this live with r586. Cool, thanks Ben. One thought I had is that the anchor text "View build history and stats" would better describe the target if it said "View '' in the buildfarm database", or "View all packages named ''". Maciej From bwalton at opencsw.org Wed Nov 9 18:18:29 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Nov 2011 12:18:29 -0500 Subject: [csw-maintainers] Addition to the QA pages... In-Reply-To: References: <1320604713-sup-3393@pinkfloyd.chass.utoronto.ca> <1320716476-sup-3122@pinkfloyd.chass.utoronto.ca> Message-ID: <1320858994-sup-8775@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Wed Nov 09 12:14:28 -0500 2011: > One thought I had is that the anchor text "View build history and > stats" would better describe the target if it said "View > '' in the buildfarm database", or "View all packages > named ''". How about: http://www-mockup.opencsw.org/qa/package/git/ Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Wed Nov 9 18:23:07 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 9 Nov 2011 17:23:07 +0000 Subject: [csw-maintainers] Addition to the QA pages... In-Reply-To: <1320858994-sup-8775@pinkfloyd.chass.utoronto.ca> References: <1320604713-sup-3393@pinkfloyd.chass.utoronto.ca> <1320716476-sup-3122@pinkfloyd.chass.utoronto.ca> <1320858994-sup-8775@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/11/9 Ben Walton : > How about: http://www-mockup.opencsw.org/qa/package/git/ Looks good! From bwalton at opencsw.org Thu Nov 10 01:56:04 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Nov 2011 19:56:04 -0500 Subject: [csw-maintainers] Addition to the QA pages... In-Reply-To: References: <1320604713-sup-3393@pinkfloyd.chass.utoronto.ca> <1320716476-sup-3122@pinkfloyd.chass.utoronto.ca> <1320858994-sup-8775@pinkfloyd.chass.utoronto.ca> Message-ID: <1320886555-sup-4786@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Wed Nov 09 12:23:07 -0500 2011: > 2011/11/9 Ben Walton : > > How about: http://www-mockup.opencsw.org/qa/package/git/ > > Looks good! Pushed to live. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Nov 10 19:04:34 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 10 Nov 2011 18:04:34 +0000 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: References: Message-ID: I built the intermediate gcc compilers on current9{s,x}, and I'm now running the target builds. I discovered that we never had the 64-bit Ada targets. This means that we are not and will not be able to compile Ada for amd64. If we want to have an amd64 Ada, we need to crosscompile. I'm not going to embark on that for the time being. There's one more problem, though. I can't build the intermediate Ada compiler on Solaris 10 amd64, because it tries to build the 64-bit target and fails: /opt/csw/gcc4/bin/gcc -c -g -fkeep-inline-functions -gnatpg -gnata -gnatwns -nostdinc -I- -I. -Iada -I/home/maciej/src/opencsw/pkg/gcc4/branches/ada/work/solaris10-i386/build-isa-pentium_pro/gcc-4.6.1/gcc/ada -I/home/maciej/src/opencsw/pkg/gcc4/branches/ada/work/solaris10-i386/build-isa-pentium_pro/gcc-4.6.1/gcc/ada/gcc-interface /home/maciej/src/opencsw/pkg/gcc4/branches/ada/work/solaris10-i386/build-isa-pentium_pro/gcc-4.6.1/gcc/ada/fmap.adb -o ada/fmap.o gnatmake: "xsnamest.ali" incompatible ALI file, please recompile gnatmake: "xsnamest.adb" compilation error /bin/bash: ./xsnamest: No such file or directory gmake[3]: *** [ada/stamp-snames] Error 127 gmake[3]: *** Waiting for unfinished jobs.... gnatmake: "xnmake.ali" incompatible ALI file, please recompile gnatmake: "xnmake.adb" compilation error /bin/bash: ./xnmake: No such file or directory gmake[3]: *** [ada/nmake.adb] Error 127 gmake[3]: Leaving directory `/home/maciej/src/opencsw/pkg/gcc4/branches/ada/work/solaris10-i386/build-isa-pentium_pro/objdir/gcc' Here are two choices I see and problems with them: - Build GCC on Solaris 9 only and use it for Solaris 10 - Problem: It will not have the 64-bit targets (unacceptable) - Build GCC on Solaris 9 and 10 separately - Problem: The Solaris 10 version will not have even the 32-bit Ada support If I could tell it to build Ada on Solaris 10, but skip the amd64 targets, it would solve the problem the best way, but I don't currently know how to do that. Thoughts? Maciej From bwalton at opencsw.org Thu Nov 10 20:09:29 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 10 Nov 2011 14:09:29 -0500 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: References: Message-ID: <1320952034-sup-6263@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Thu Nov 10 13:04:34 -0500 2011: Hi Maciej, > If I could tell it to build Ada on Solaris 10, but skip the amd64 > targets, it would solve the problem the best way, but I don't > currently know how to do that. Would a judicious (crafty?) use of modulations let you do this? Other than that, my thinking is that ada isn't likely seeing much action anyway so I'd be inclined to do the best you can and not worry about the rest... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Thu Nov 10 20:20:16 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 10 Nov 2011 20:20:16 +0100 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu, 10 Nov 2011 18:04:34 +0000") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > I discovered that we never had the 64-bit Ada targets. 64 bit support was not easy to build at the time, at least until 4.0.2 Can't we build 56 bit Ada with a 32 bit one? Well, having a 32 bit Ada is better than not having one at all. BTW, I don't agree with Ben on the low traction of Ada. There are a lot of aerospace industries using it, at least in Europe but I think that in the US is the same situation. -- Peter From bwalton at opencsw.org Thu Nov 10 20:27:01 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 10 Nov 2011 14:27:01 -0500 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: References: Message-ID: <1320953157-sup-6600@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Thu Nov 10 14:20:16 -0500 2011: Hi Peter, > Well, having a 32 bit Ada is better than not having one at all. BTW, > I don't agree with Ben on the low traction of Ada. There are a lot > of aerospace industries using it, at least in Europe but I think > that in the US is the same situation. Ok. I'm happy to defer to your wider exposure on this. I agree that some is better than none. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Nov 11 04:25:20 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 10 Nov 2011 22:25:20 -0500 Subject: [csw-maintainers] automated catalog promotion for packages Message-ID: <1320978197-sup-8724@pinkfloyd.chass.utoronto.ca> Hi All, At this point, we have automated all of the tasks required for automated package publishing to the point where our previous mechanisms stopped. It's now time to start looking at the last piece: Package promotion from unstable. This is by no means a trivial task, so lets hash out the rules that we expect from the system. For the sake of discussion, we'll assume that things must bake in unstable for X amount of time. We'd talked about a 2 week duration but that isn't set in stone. As it doesn't matter for this purpose, let's ignore it for now. I'm going to sketch out the basics of how I see this working. Then we can start picking it apart and finding the edge cases that will make it challenging to implement. Do we agree that all package removals should be done manually or does anyone think this should be done automatically too? For package adds and updates we'll need to determine the point in time that a package (add or update) enters the unstable catalog. The simplistic view would use the REV= date stamp for adds/updates but that can be misleading as a package might sit in experimental for an unknown amount of time before being pushed. Thus we need to watch the catalog(s) and detect package entry. This is easy enough to do as we have machinery for this task already. The initial spotting of a new package should trigger a clock for this package that upon expiry will see it moved forward. What criteria can be used to stop the clock? Some of the following are obvious and some are possibilities. I'm sure I'm missing items here too. 1. A bug against the package in question. 2. A bug against another package in the same 'bundle.' 3. A subsequent update of the same package. 4. A bug against a dependency if it has a ticking promotion clock too. All of the bug-based items are complicated by the fact that mantis carries no information about which catalog the particular bug is relevant too. A bug could be filed against the package in the named release, not the version in unstable but we have no way to ascertain that currently. To handle the mantis limitations, we could either add a facility to the promotion tool to ignore various bug id's (a manual action) or look at alternate bug tracking systems. The first item, barring the limitations, is a no brainer. A bug stops the clock. The question here is whether we remove this package from our (long lived) promotion object outright or mark it stalled? If we remove it outright then the third action would never occur...we'd just see another new package later on. If we do this, the 'override this bug' mechanism would need to repopulate this entry into the promotion object instead of just marking a bug as ignorable. Leaving the bug in the object but marking it stalled has impact on subsequent spottings of the same package. A subsequent update of the same package could simply overwrite the existing entry in the current promotion tracking object. That would be the equivalent of saying "we assume that a new update addresses open bugs. it would require a new bug to stop the clock again." Does that seem like a valid assumption to build in? I think the dependency issue will be the biggest trap here. I think we need to track bugs on dependencies as a broken dep could mean a broken app. We may want to only consider deps that also have ticking clocks. This would allow for the fact that the package under consideration was built against the dep (library, etc) that is already in the named release catalog. A dep that pre-exists in the promotion object would (assuming we keep the buildfarm very fresh) mean that the new package was built against the dep package that has a ticking clock itself. We could choose to ignore dependencies, but I'm not sure that's a good idea. If we decide that blocking a package based on its dependencies is the best action, then we have further complications. An update of the dependent package must also remove the block that it set on the original. I guess that's more of a bookkeeping issue in the data structure than a hard challenge but it's still something to consider. We should also offer a mechanism for a maintainer to signal that a package is not suitable for promotion. That could come in the form of a bug filed or through a command that is run. I think filing a bug is more consistent (and visible) in this case. Now, if we end up with several packages in the promotion object that have stopped clocks, we'll want to eventually garbage collect them. We should be able to set quite a long expiry time on this but at some point, things will fall out the bottom. Do we need a way for the maintainer to signal that the clock should start again? I think the simplest way to achieve that is to have the maintainer submit the package again and start a new clock. (This would require a different REV= stamp to ensure it is detected.) Now, what about different architectures and os releases? The bug system isn't granular enough to pick out this info so I think we need to stall the package in all catalogs until the normal criteria are met. This would have the benefit of keeping catalogs in lock step which I think is a good thing. I'm probably missing a bunch of important stuff here... Thoughts and comments? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Fri Nov 11 08:50:32 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 11 Nov 2011 07:50:32 +0000 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: References: Message-ID: 2011/11/10 Peter FELECAN : > "Maciej (Matchek) Blizi?ski" writes: > >> I discovered that we never had the 64-bit Ada targets. > > 64 bit support was not easy to build at the time, at least until 4.0.2 > > Can't we build 56 bit Ada with a 32 bit one? How would you go about this? It smells of cross-compiling to me. Maciej From maciej at opencsw.org Fri Nov 11 09:17:13 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 11 Nov 2011 08:17:13 +0000 Subject: [csw-maintainers] automated catalog promotion for packages In-Reply-To: <1320978197-sup-8724@pinkfloyd.chass.utoronto.ca> References: <1320978197-sup-8724@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/11/11 Ben Walton : > Do we agree that all package removals should be done manually or does > anyone think this should be done automatically too? If it were to be done automatically, there would need to be a mechanism detecting whether it's safe to do so. We could have a rule e.g. that we remove *_stub packages that nothing depends on. This way, to remove package foo from the catalog, you would replace it with an empty foo_stub, by uploading foo_stub to the catalog. Then the automation would scan the catalog, see that foo_stub exists and has no dependent packages - and harvest it. > For package adds and updates we'll need to determine the point in time > that a package (add or update) enters the unstable catalog. ?The > simplistic view would use the REV= date stamp for adds/updates but > that can be misleading as a package might sit in experimental for an > unknown amount of time before being pushed. ?Thus we need to watch the > catalog(s) and detect package entry. ?This is easy enough to do as we > have machinery for this task already. ?The initial spotting of a new > package should trigger a clock for this package that upon expiry will > see it moved forward. I agree, we can't use REV for this purpose. We need some kind of a datestamp denoting when certain package entered the catalog. I'm thinking that the srv4_file_in_catalog table could have an additional timestamp column for this purpose. > What criteria can be used to stop the clock? ?Some of the following > are obvious and some are possibilities. ?I'm sure I'm missing items > here too. > > 1. A bug against the package in question. Meaning, a new bug. In the general case, if you have two bugs open and you fix one, we would like to be able to push the improved (although not fixed completely) package to testing. > 2. A bug against another package in the same 'bundle.' Right, the clock would be set for the bundle rather than an individual package. Or it would be set for max(package.insertion_time). > 3. A subsequent update of the same package. > 4. A bug against a dependency if it has a ticking promotion clock too. I would achieve the same effect in a different way. I would not reset the clocks for dependent packages; I would handle that by always analyzing the package promotion as promotion of the package in question, plus all its dependencies. When you install a package with pkgutil, it always installs or updates all dependencies of that package. We would have the same requirement for promotion: if we want to promote "bar" that depends on "libfoo1", we can only promote bar together with libfoo1. > All of the bug-based items are complicated by the fact that mantis > carries no information about which catalog the particular bug is > relevant too. ?A bug could be filed against the package in the named > release, not the version in unstable but we have no way to ascertain > that currently. We would assume that the bug is relevant for unstable. In reality the bug might be present in testing, but even if so, the fix will first go into unstable. > To handle the mantis limitations, we could either add a facility to > the promotion tool to ignore various bug id's (a manual action) or > look at alternate bug tracking systems. > > The first item, barring the limitations, is a no brainer. ?A bug stops > the clock. ?The question here is whether we remove this package from > our (long lived) promotion object outright or mark it stalled? ?If we > remove it outright then the third action would never occur...we'd just > see another new package later on. ?If we do this, the 'override this > bug' mechanism would need to repopulate this entry into the promotion > object instead of just marking a bug as ignorable. ?Leaving the bug in > the object but marking it stalled has impact on subsequent spottings > of the same package. > > A subsequent update of the same package could simply overwrite the > existing entry in the current promotion tracking object. ?That would > be the equivalent of saying "we assume that a new update addresses > open bugs. ?it would require a new bug to stop the clock again." ?Does > that seem like a valid assumption to build in? My instinct says no. I'd rather say: "we assume that a new update addresses the bug if the bug gets closed, and: bug_open_timestamp < package_build_timestamp < bug_close_timestamp. > I think the dependency issue will be the biggest trap here. ?I think > we need to track bugs on dependencies as a broken dep could mean a > broken app. ?We may want to only consider deps that also have ticking > clocks. ?This would allow for the fact that the package under > consideration was built against the dep (library, etc) that is already > in the named release catalog. ?A dep that pre-exists in the promotion > object would (assuming we keep the buildfarm very fresh) mean that the > new package was built against the dep package that has a ticking clock > itself. > > We could choose to ignore dependencies, but I'm not sure that's a good > idea. Definitely not, it would cause a lot of breakage. We must take dependencies into account. > If we decide that blocking a package based on its dependencies is the > best action, then we have further complications. ?An update of the > dependent package must also remove the block that it set on the > original. ?I guess that's more of a bookkeeping issue in the data > structure than a hard challenge but it's still something to consider. > > We should also offer a mechanism for a maintainer to signal that a > package is not suitable for promotion. ?That could come in the form of > a bug filed or through a command that is run. ?I think filing a bug is > more consistent (and visible) in this case. I'm not sure I understand the bug filing idea here. I was imagining something like this: $ promote-package foo (...) Can't promote package foo, because: - package foo depends on libbar1 - package libbar1 can't be promoted, because: - mantis bug 4321 is open against libbar-utils - mantis bug 4123 is open against package foo > Now, if we end up with several packages in the promotion object that > have stopped clocks, we'll want to eventually garbage collect them. > We should be able to set quite a long expiry time on this but at some > point, things will fall out the bottom. ?Do we need a way for the > maintainer to signal that the clock should start again? That sounds like something that should happen automatically. > I think the > simplest way to achieve that is to have the maintainer submit the > package again and start a new clock. ?(This would require a different > REV= stamp to ensure it is detected.) In general, as a maintainer I'd like to know: if my package is not promoted, is it only because it needs to wait more (no action needed), or are there bugs that need to be fixed (action needed). > Now, what about different architectures and os releases? ?The bug > system isn't granular enough to pick out this info so I think we need > to stall the package in all catalogs until the normal criteria are > met. ?This would have the benefit of keeping catalogs in lock step > which I think is a good thing. I agree. It's better to keep the catalogs in sync. There are some cases though, where a package exists in the i386 catalog only (acrobat reader for instance), so the system would need to cope with these too. Maciej From dam at opencsw.org Fri Nov 11 10:54:59 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 11 Nov 2011 10:54:59 +0100 Subject: [csw-maintainers] automated catalog promotion for packages In-Reply-To: References: <1320978197-sup-8724@pinkfloyd.chass.utoronto.ca> Message-ID: <90CEEE1A-8234-4416-B4A2-500336769E39@opencsw.org> Am 11.11.2011 um 09:17 schrieb Maciej (Matchek) Blizi?ski: > 2011/11/11 Ben Walton : >> Do we agree that all package removals should be done manually or does >> anyone think this should be done automatically too? > > If it were to be done automatically, there would need to be a > mechanism detecting whether it's safe to do so. We could have a rule > e.g. that we remove *_stub packages that nothing depends on. This > way, to remove package foo from the catalog, you would replace it with > an empty foo_stub, by uploading foo_stub to the catalog. Then the > automation would scan the catalog, see that foo_stub exists and has no > dependent packages - and harvest it. The problem is that the stub must exist until the user has actually updated. That means the stub must stay inside a named release until the next named release or the packages obsoleted by the stub will not get removed. >> For package adds and updates we'll need to determine the point in time >> that a package (add or update) enters the unstable catalog. The >> simplistic view would use the REV= date stamp for adds/updates but >> that can be misleading as a package might sit in experimental for an >> unknown amount of time before being pushed. Thus we need to watch the >> catalog(s) and detect package entry. This is easy enough to do as we >> have machinery for this task already. The initial spotting of a new >> package should trigger a clock for this package that upon expiry will >> see it moved forward. > > I agree, we can't use REV for this purpose. We need some kind of a > datestamp denoting when certain package entered the catalog. I'm > thinking that the srv4_file_in_catalog table could have an additional > timestamp column for this purpose. > >> What criteria can be used to stop the clock? Some of the following >> are obvious and some are possibilities. I'm sure I'm missing items >> here too. >> >> 1. A bug against the package in question. > > Meaning, a new bug. In the general case, if you have two bugs open > and you fix one, we would like to be able to push the improved > (although not fixed completely) package to testing. Really? I would think that this is only allowed if you close both, probably one with "Resolution: Fix Later", but both closed. >> 2. A bug against another package in the same 'bundle.' > > Right, the clock would be set for the bundle rather than an individual > package. Or it would be set for max(package.insertion_time). Or even better bugs were reported against the bundle, which would require an updated bugtracker ;-) >> 3. A subsequent update of the same package. Which means that only the latest package version should be taken into account for propagation. >> 4. A bug against a dependency if it has a ticking promotion clock too. > > I would achieve the same effect in a different way. I would not reset > the clocks for dependent packages; I would handle that by always > analyzing the package promotion as promotion of the package in > question, plus all its dependencies. > > When you install a package with pkgutil, it always installs or updates > all dependencies of that package. We would have the same requirement > for promotion: if we want to promote "bar" that depends on "libfoo1", > we can only promote bar together with libfoo1. > >> All of the bug-based items are complicated by the fact that mantis >> carries no information about which catalog the particular bug is >> relevant too. A bug could be filed against the package in the named >> release, not the version in unstable but we have no way to ascertain >> that currently. > > We would assume that the bug is relevant for unstable. In reality the > bug might be present in testing, but even if so, the fix will first go > into unstable. Again an updated bugtracker would allow opening a bug against specific REV of a package and tracking that. Until now I think Maciejs assumption is viable. >> To handle the mantis limitations, we could either add a facility to >> the promotion tool to ignore various bug id's (a manual action) or >> look at alternate bug tracking systems. I suggest first implementing some very simple propagation where any bug stop propagation, no special cases, no elaborate coding. When that works we can start working on a new bugtracker and do the more advanced stuff with the new capabilities. >> A subsequent update of the same package could simply overwrite the >> existing entry in the current promotion tracking object. That would >> be the equivalent of saying "we assume that a new update addresses >> open bugs. it would require a new bug to stop the clock again." Does >> that seem like a valid assumption to build in? > > My instinct says no. I'd rather say: "we assume that a new update > addresses the bug if the bug gets closed, and: bug_open_timestamp < > package_build_timestamp < bug_close_timestamp. > >> I think the dependency issue will be the biggest trap here. I think >> we need to track bugs on dependencies as a broken dep could mean a >> broken app. We may want to only consider deps that also have ticking >> clocks. This would allow for the fact that the package under >> consideration was built against the dep (library, etc) that is already >> in the named release catalog. A dep that pre-exists in the promotion >> object would (assuming we keep the buildfarm very fresh) mean that the >> new package was built against the dep package that has a ticking clock >> itself. >> >> We could choose to ignore dependencies, but I'm not sure that's a good >> idea. > > Definitely not, it would cause a lot of breakage. We must take > dependencies into account. I am also for stopping propagation on any issue. If there is a block it needs fixing and the deps get work which they would otherwise not necessarily get. >> If we decide that blocking a package based on its dependencies is the >> best action, then we have further complications. An update of the >> dependent package must also remove the block that it set on the >> original. I guess that's more of a bookkeeping issue in the data >> structure than a hard challenge but it's still something to consider. >> >> We should also offer a mechanism for a maintainer to signal that a >> package is not suitable for promotion. That could come in the form of >> a bug filed or through a command that is run. I think filing a bug is >> more consistent (and visible) in this case. > > I'm not sure I understand the bug filing idea here. I was imagining > something like this: > > $ promote-package foo > (...) > Can't promote package foo, because: > - package foo depends on libbar1 > - package libbar1 can't be promoted, because: > - mantis bug 4321 is open against libbar-utils > - mantis bug 4123 is open against package foo But the promotion is done in background, so how will the maintainer get the output of the command? From my understanding a new bug on foo would opened as "Propagation Stopped"-bug. >> Now, if we end up with several packages in the promotion object that >> have stopped clocks, we'll want to eventually garbage collect them. >> We should be able to set quite a long expiry time on this but at some >> point, things will fall out the bottom. Do we need a way for the >> maintainer to signal that the clock should start again? > > That sounds like something that should happen automatically. And it should be visible to the maintainer. Maybe in a qa-page for the catalog with something like this: foo OLD=2011.04.02,1.23 NEW=2011.11.03,1.25 5 days until propagation bar OLD=2011.04.02,1.23 NEW=2011.11.03,1.25 would propagate, but 2 open bugs Maybe one page with all migrations per catalog, and one page per maintainer. >> I think the >> simplest way to achieve that is to have the maintainer submit the >> package again and start a new clock. (This would require a different >> REV= stamp to ensure it is detected.) > > In general, as a maintainer I'd like to know: if my package is not > promoted, is it only because it needs to wait more (no action needed), > or are there bugs that need to be fixed (action needed). > >> Now, what about different architectures and os releases? The bug >> system isn't granular enough to pick out this info so I think we need >> to stall the package in all catalogs until the normal criteria are >> met. This would have the benefit of keeping catalogs in lock step >> which I think is a good thing. > > I agree. It's better to keep the catalogs in sync. There are some > cases though, where a package exists in the i386 catalog only (acrobat > reader for instance), so the system would need to cope with these too. If in doubt halt propagation. After the first simple migration approach lets face a new bugtracker and do finer grained stuff later. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From pfelecan at opencsw.org Fri Nov 11 11:10:13 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 11 Nov 2011 11:10:13 +0100 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Fri, 11 Nov 2011 07:50:32 +0000") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2011/11/10 Peter FELECAN : >> "Maciej (Matchek) Blizi?ski" writes: >> >>> I discovered that we never had the 64-bit Ada targets. >> >> 64 bit support was not easy to build at the time, at least until 4.0.2 >> >> Can't we build 64 bit Ada with a 32 bit one? > > How would you go about this? It smells of cross-compiling to me. The solution resides in the answer to the question: can a 32 bit compiler generate 64 bit code? In my opinion, the answer is yes and it can be considered as cross-compilation in a very lazy definition. Note that I didn't researched how to do this in the Ada compiler context... -- Peter From Joerg.Schilling at fokus.fraunhofer.de Fri Nov 11 11:49:11 2011 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Fri, 11 Nov 2011 11:49:11 +0100 Subject: [csw-maintainers] Solaris 11 In-Reply-To: <33A3537C-3F8A-4891-ADF7-F180E3709432@opencsw.org> References: <33A3537C-3F8A-4891-ADF7-F180E3709432@opencsw.org> Message-ID: <4ebcfda7.hcHSL2F91qH3kXA6%Joerg.Schilling@fokus.fraunhofer.de> Dagobert Michelsen wrote: > Here is a brief list of things to do: > > # Set up IPS Provisioning server > # Install new instances on T5220 and vSphere using the local probivioning server > # Install compilers and stuff > # Setup mounts and stuff from the farm > # Bootstrap with System V packages from OpenCSW > # Make IPS backend with just files > # Transform CAS to SMF > # Setup provisioning on primary mirror on pkg.opencsw.org in Erlangen > # Push targets for GAR IPS looks like a subset (with a few exeptions) from Svr4 packaging. It should be possible to create IPS package definitions from SVr4 definitions. If someone likes to do this, I would be interested as this could be used on Schillix-ON. 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 skayser at opencsw.org Fri Nov 11 11:54:41 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 11 Nov 2011 11:54:41 +0100 Subject: [csw-maintainers] Solaris 11 In-Reply-To: <4ebcfda7.hcHSL2F91qH3kXA6%Joerg.Schilling@fokus.fraunhofer.de> References: <33A3537C-3F8A-4891-ADF7-F180E3709432@opencsw.org> <4ebcfda7.hcHSL2F91qH3kXA6%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <20111111105441.GL26160@sebastiankayser.de> * Joerg Schilling wrote: > Dagobert Michelsen wrote: > > > Here is a brief list of things to do: > > > > # Set up IPS Provisioning server > > # Install new instances on T5220 and vSphere using the local probivioning server > > # Install compilers and stuff > > # Setup mounts and stuff from the farm > > # Bootstrap with System V packages from OpenCSW > > # Make IPS backend with just files > > # Transform CAS to SMF > > # Setup provisioning on primary mirror on pkg.opencsw.org in Erlangen > > # Push targets for GAR > > IPS looks like a subset (with a few exeptions) from Svr4 packaging. > It should be possible to create IPS package definitions from SVr4 definitions. > If someone likes to do this, I would be interested as this could be used on > Schillix-ON. AFAIR, Trygve has been working on a SVR4 -> IPS package converter (if that's what you mean) several months ago. Not sure about the results. Sebastian From Joerg.Schilling at fokus.fraunhofer.de Fri Nov 11 11:56:53 2011 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Fri, 11 Nov 2011 11:56:53 +0100 Subject: [csw-maintainers] Solaris 11 In-Reply-To: <20111111105441.GL26160@sebastiankayser.de> References: <33A3537C-3F8A-4891-ADF7-F180E3709432@opencsw.org> <4ebcfda7.hcHSL2F91qH3kXA6%Joerg.Schilling@fokus.fraunhofer.de> <20111111105441.GL26160@sebastiankayser.de> Message-ID: <4ebcff75.8sWN3m/okDrEg5Wt%Joerg.Schilling@fokus.fraunhofer.de> Sebastian Kayser wrote: > AFAIR, Trygve has been working on a SVR4 -> IPS package converter (if > that's what you mean) several months ago. Not sure about the results. This would be very interesting! And yes, this is what I am looking for. 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 pfelecan at opencsw.org Fri Nov 11 14:25:44 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 11 Nov 2011 14:25:44 +0100 Subject: [csw-maintainers] automated catalog promotion for packages In-Reply-To: <1320978197-sup-8724@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Thu, 10 Nov 2011 22:25:20 -0500") References: <1320978197-sup-8724@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Do we agree that all package removals should be done manually or does > anyone think this should be done automatically too? Manual process but enabled for the maintainer, i.e., a maintainer can remove his package. There is an exception to that: see bellow where I'm discussing a subsequent update. > For package adds and updates we'll need to determine the point in time > that a package (add or update) enters the unstable catalog. The > simplistic view would use the REV= date stamp for adds/updates but > that can be misleading as a package might sit in experimental for an > unknown amount of time before being pushed. Thus we need to watch the > catalog(s) and detect package entry. This is easy enough to do as we > have machinery for this task already. The initial spotting of a new > package should trigger a clock for this package that upon expiry will > see it moved forward. Clocking must depend on the entry epoch of the package and not on the REV attribute. > What criteria can be used to stop the clock? Some of the following > are obvious and some are possibilities. I'm sure I'm missing items > here too. > > 1. A bug against the package in question. Yes, but only for bugs of a certain level, e.g., for major and critical ones; however, the maintainer must have the ability to change the level of a bug if he choose so. > 2. A bug against another package in the same 'bundle.' Yes. > 3. A subsequent update of the same package. >From my standpoint, when and update enters in the unstable catalog and there is still a previous version of that packaged, clocking or not, the previous package is removed automatically. > 4. A bug against a dependency if it has a ticking promotion clock too. I don't get that because a bug for the dependency would stop its clock, isn't it? > All of the bug-based items are complicated by the fact that mantis > carries no information about which catalog the particular bug is > relevant too. A bug could be filed against the package in the named > release, not the version in unstable but we have no way to ascertain > that currently. > To handle the mantis limitations, we could either add a facility to > the promotion tool to ignore various bug id's (a manual action) or > look at alternate bug tracking systems. The Mantis schemata and interface can be changed, it's a practice that I've seen in some places; this will help to keep the current bug tracker with minimal effort, versus changing toward an hypothetically one which is functionally complete. > The first item, barring the limitations, is a no brainer. A bug stops > the clock. The question here is whether we remove this package from > our (long lived) promotion object outright or mark it stalled? If we > remove it outright then the third action would never occur...we'd just > see another new package later on. If we do this, the 'override this > bug' mechanism would need to repopulate this entry into the promotion > object instead of just marking a bug as ignorable. Leaving the bug in > the object but marking it stalled has impact on subsequent spottings > of the same package. The ignore bug mechanism must be implemented in the bug tracker, i.e., it's a new attribute of the bug, and must be available only to the maintainer. > A subsequent update of the same package could simply overwrite the > existing entry in the current promotion tracking object. That would > be the equivalent of saying "we assume that a new update addresses > open bugs. it would require a new bug to stop the clock again." Does > that seem like a valid assumption to build in? Quite, but maybe we should add a package attribute explicating the bugs corrected if any; many packaging systems have this very useful information. > I think the dependency issue will be the biggest trap here. I think > we need to track bugs on dependencies as a broken dep could mean a > broken app. We may want to only consider deps that also have ticking > clocks. This would allow for the fact that the package under > consideration was built against the dep (library, etc) that is already > in the named release catalog. A dep that pre-exists in the promotion > object would (assuming we keep the buildfarm very fresh) mean that the > new package was built against the dep package that has a ticking clock > itself. I don't get this specific case. A dependency is a dependency and if it has a bug, its clock is stopped, isn't it? > We could choose to ignore dependencies, but I'm not sure that's a good > idea. Definitely a bad thing. > If we decide that blocking a package based on its dependencies is the > best action, then we have further complications. An update of the > dependent package must also remove the block that it set on the > original. I guess that's more of a bookkeeping issue in the data > structure than a hard challenge but it's still something to consider. It's just bookkeeping. > We should also offer a mechanism for a maintainer to signal that a > package is not suitable for promotion. That could come in the form of > a bug filed or through a command that is run. I think filing a bug is > more consistent (and visible) in this case. There should be a special bug level for a better visibility of the maintainer's intent. > Now, if we end up with several packages in the promotion object that > have stopped clocks, we'll want to eventually garbage collect them. > We should be able to set quite a long expiry time on this but at some > point, things will fall out the bottom. Do we need a way for the > maintainer to signal that the clock should start again? I think the > simplest way to achieve that is to have the maintainer submit the > package again and start a new clock. (This would require a different > REV= stamp to ensure it is detected.) No REV stamp difference needed as the clocking is not based on that but on the catalog entry or re-entry time. Consequently, there should be a re-entry procedure, manual, of course. > Now, what about different architectures and os releases? The bug > system isn't granular enough to pick out this info so I think we need > to stall the package in all catalogs until the normal criteria are > met. This would have the benefit of keeping catalogs in lock step > which I think is a good thing. No need for this if the bug tracking system give the possibility to signal a bug on a specific release, architecture and package revision (which implicates the catalog). -- Peter From gadavis at opencsw.org Fri Nov 11 18:10:10 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Fri, 11 Nov 2011 09:10:10 -0800 Subject: [csw-maintainers] automated catalog promotion for packages In-Reply-To: <1320978197-sup-8724@pinkfloyd.chass.utoronto.ca> References: <1320978197-sup-8724@pinkfloyd.chass.utoronto.ca> Message-ID: <4EBD56F2.1000805@opencsw.org> On 11/10/2011 7:25 PM, Ben Walton wrote: > Hi All, > > At this point, we have automated all of the tasks required for > automated package publishing to the point where our previous > mechanisms stopped. It's now time to start looking at the last piece: > Package promotion from unstable. > > This is by no means a trivial task, so lets hash out the rules that we > expect from the system. For the sake of discussion, we'll assume that > things must bake in unstable for X amount of time. We'd talked about > a 2 week duration but that isn't set in stone. As it doesn't matter > for this purpose, let's ignore it for now. > > I'm going to sketch out the basics of how I see this working. Then we > can start picking it apart and finding the edge cases that will make > it challenging to implement. > > Do we agree that all package removals should be done manually or does > anyone think this should be done automatically too? > > For package adds and updates we'll need to determine the point in time > that a package (add or update) enters the unstable catalog. The > simplistic view would use the REV= date stamp for adds/updates but > that can be misleading as a package might sit in experimental for an > unknown amount of time before being pushed. Thus we need to watch the > catalog(s) and detect package entry. This is easy enough to do as we > have machinery for this task already. The initial spotting of a new > package should trigger a clock for this package that upon expiry will > see it moved forward. > > What criteria can be used to stop the clock? Some of the following > are obvious and some are possibilities. I'm sure I'm missing items > here too. > > 1. A bug against the package in question. > 2. A bug against another package in the same 'bundle.' > 3. A subsequent update of the same package. > 4. A bug against a dependency if it has a ticking promotion clock too. > > All of the bug-based items are complicated by the fact that mantis > carries no information about which catalog the particular bug is > relevant too. A bug could be filed against the package in the named > release, not the version in unstable but we have no way to ascertain > that currently. > > To handle the mantis limitations, we could either add a facility to > the promotion tool to ignore various bug id's (a manual action) or > look at alternate bug tracking systems. > > The first item, barring the limitations, is a no brainer. A bug stops > the clock. The question here is whether we remove this package from > our (long lived) promotion object outright or mark it stalled? If we > remove it outright then the third action would never occur...we'd just > see another new package later on. If we do this, the 'override this > bug' mechanism would need to repopulate this entry into the promotion > object instead of just marking a bug as ignorable. Leaving the bug in > the object but marking it stalled has impact on subsequent spottings > of the same package. > > A subsequent update of the same package could simply overwrite the > existing entry in the current promotion tracking object. That would > be the equivalent of saying "we assume that a new update addresses > open bugs. it would require a new bug to stop the clock again." Does > that seem like a valid assumption to build in? > > I think the dependency issue will be the biggest trap here. I think > we need to track bugs on dependencies as a broken dep could mean a > broken app. We may want to only consider deps that also have ticking > clocks. This would allow for the fact that the package under > consideration was built against the dep (library, etc) that is already > in the named release catalog. A dep that pre-exists in the promotion > object would (assuming we keep the buildfarm very fresh) mean that the > new package was built against the dep package that has a ticking clock > itself. > > We could choose to ignore dependencies, but I'm not sure that's a good > idea. > > If we decide that blocking a package based on its dependencies is the > best action, then we have further complications. An update of the > dependent package must also remove the block that it set on the > original. I guess that's more of a bookkeeping issue in the data > structure than a hard challenge but it's still something to consider. > > We should also offer a mechanism for a maintainer to signal that a > package is not suitable for promotion. That could come in the form of > a bug filed or through a command that is run. I think filing a bug is > more consistent (and visible) in this case. > > Now, if we end up with several packages in the promotion object that > have stopped clocks, we'll want to eventually garbage collect them. > We should be able to set quite a long expiry time on this but at some > point, things will fall out the bottom. Do we need a way for the > maintainer to signal that the clock should start again? I think the > simplest way to achieve that is to have the maintainer submit the > package again and start a new clock. (This would require a different > REV= stamp to ensure it is detected.) > > Now, what about different architectures and os releases? The bug > system isn't granular enough to pick out this info so I think we need > to stall the package in all catalogs until the normal criteria are > met. This would have the benefit of keeping catalogs in lock step > which I think is a good thing. > > I'm probably missing a bunch of important stuff here... > > Thoughts and comments? > > 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. ::. While I can't speak for all of the arcanery behind our bug filing process, I'd like to point out the case where someone files a bug requesting an upgrade of a package. Those types of bugs should not normally block promotion of a previous version of a package. I guess it should block if it's a security consideration or something like that, but a request to go to Cfengine 3 should not block a Cfengine 2 package for example. From bwalton at opencsw.org Fri Nov 11 18:56:18 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 11 Nov 2011 12:56:18 -0500 Subject: [csw-maintainers] automated catalog promotion for packages In-Reply-To: <4EBD56F2.1000805@opencsw.org> References: <1320978197-sup-8724@pinkfloyd.chass.utoronto.ca> <4EBD56F2.1000805@opencsw.org> Message-ID: <1321033950-sup-3071@pinkfloyd.chass.utoronto.ca> Excerpts from Geoff Davis's message of Fri Nov 11 12:10:10 -0500 2011: Hi Guys, > While I can't speak for all of the arcanery behind our bug filing > process, I'd like to point out the case where someone files a bug > requesting an upgrade of a package. Those types of bugs should not > normally block promotion of a previous version of a package. I guess > it should block if it's a security consideration or something like > that, but a request to go to Cfengine 3 should not block a Cfengine > 2 package for example. Some very good points have been raised here so far. I'll try to reply to as many as possible right now. This has been noted a few times and it's something I didn't consider last night. I think it's a very good fit though. We just need to decide which type and severity combinations should stop the clock on a promotion. We can augment the classes with more categories as required to make the functionality what we want. A maintainer should have the ability to downgrade a bug such that the clock is reset. Should the countdown resume or be reset to two weeks? I'm inclined to think that unless new bugs are filed, it simply resumes from where it left off, but as the expiration approaches, that doesn't leave much wiggle room for any squabbling over the semantics of a downgrade. (That knife can cut both ways.) More to come as replies where appropriate. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Nov 11 22:16:05 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 11 Nov 2011 16:16:05 -0500 Subject: [csw-maintainers] automated catalog promotion for packages In-Reply-To: References: <1320978197-sup-8724@pinkfloyd.chass.utoronto.ca> Message-ID: <1321045800-sup-1152@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Fri Nov 11 08:25:44 -0500 2011: > > Do we agree that all package removals should be done manually or does > > anyone think this should be done automatically too? > > Manual process but enabled for the maintainer, i.e., a maintainer > can remove his package. There is an exception to that: see bellow > where I'm discussing a subsequent update. With the exception of stub packages that we may want to auto-expire somehow (the point Maciej and Dago discuss), I think this is a good way to handle removals. > Clocking must depend on the entry epoch of the package and not on > the REV attribute. Agreed. You point out below though that no REV= update would be required, but that's not easy to avoid if we're only looking at catalog data. We would stop the clock on a filed bug (meeting defined criteria) but in order to restart it for this package, we'd need to see it re-enter the catalog. As we'd never see it actually leave the unstable catalog, something detectable must change for it to be noticed again. The REV= stamp of a re-rolled package is the low hanging fruit here. The only other field likely to change is the md5sum, or possibly the version field if there is a subsequent update. > > What criteria can be used to stop the clock? Some of the following > > are obvious and some are possibilities. I'm sure I'm missing items > > here too. > > > > 1. A bug against the package in question. > > Yes, but only for bugs of a certain level, e.g., for major and > critical ones; however, the maintainer must have the ability to > change the level of a bug if he choose so. This is a good point. I hadn't considered it last night but I agree fully. > > 2. A bug against another package in the same 'bundle.' > > Yes. > > > 3. A subsequent update of the same package. > > From my standpoint, when and update enters in the unstable catalog > and there is still a previous version of that packaged, clocking or > not, the previous package is removed automatically. And the clock is reset as if the old one was never considered. I think this goes without saying, I'm just being explicit. > > 4. A bug against a dependency if it has a ticking promotion clock too. > > I don't get that because a bug for the dependency would stop its > clock, isn't it? If I build against libxml2 and my new program passes the tests, a new bug against libxml2 shouldn't hold me up. But if libxml2 is also new (defined by ticking clock here, but that may not be ideal?), and a bug is filed against it, packages built against it should (?) be stopped as well. The idea here is that we don't want a situation where I need a new SONAME to exist in the next catalog and that doesn't exist because the package providing that was held up. To truly prevent this, we may need to really leverage the pkgdb information. > The Mantis schemata and interface can be changed, it's a practice > that I've seen in some places; this will help to keep the current > bug tracker with minimal effort, versus changing toward an > hypothetically one which is functionally complete. Replacing the bug tracker is a big project so avoiding it (for now) is still a good approach, imo. If we can bend it to our needs, we should. Aside from augmenting categories/types of bugs, we could also consider merging all of the packages into a single item based on their bundle tag. The problem here is that this is relatively new so not all packages have it. > > The first item, barring the limitations, is a no brainer. A bug stops > > the clock. The question here is whether we remove this package from > > our (long lived) promotion object outright or mark it stalled? If we > > remove it outright then the third action would never occur...we'd just > > see another new package later on. If we do this, the 'override this > > bug' mechanism would need to repopulate this entry into the promotion > > object instead of just marking a bug as ignorable. Leaving the bug in > > the object but marking it stalled has impact on subsequent spottings > > of the same package. > > The ignore bug mechanism must be implemented in the bug tracker, i.e., > it's a new attribute of the bug, and must be available only to the > maintainer. This is a great idea. It's should fall out of the rest of the bug priority handling quite nicely. It's also makes the package control flow consistent. File a bug to halt, close/alter a bug to restart. Clean. > > A subsequent update of the same package could simply overwrite the > > existing entry in the current promotion tracking object. That would > > be the equivalent of saying "we assume that a new update addresses > > open bugs. it would require a new bug to stop the clock again." Does > > that seem like a valid assumption to build in? > > Quite, but maybe we should add a package attribute explicating the > bugs corrected if any; many packaging systems have this very useful > information. I think Debian does something like this. It's heading in the direction of proper change logs (a required Changelog.CSW in $docdir?). Do you see this as needing to be visible to the promotion system? > > We should also offer a mechanism for a maintainer to signal that a > > package is not suitable for promotion. That could come in the > > form of a bug filed or through a command that is run. I think > > filing a bug is more consistent (and visible) in this case. > > There should be a special bug level for a better visibility of the > maintainer's intent. A simple additional 'severity' status of "no promotion" would do the trick nicely. Again, this is a nice clean way to interface with the system. > > Now, if we end up with several packages in the promotion object > > that have stopped clocks, we'll want to eventually garbage collect > > them. We should be able to set quite a long expiry time on this > > but at some point, things will fall out the bottom. Do we need a > > way for the maintainer to signal that the clock should start > > again? I think the simplest way to achieve that is to have the > > maintainer submit the package again and start a new clock. (This > > would require a different REV= stamp to ensure it is detected.) > > No REV stamp difference needed as the clocking is not based on that > but on the catalog entry or re-entry time. Consequently, there > should be a re-entry procedure, manual, of course. As I mentioned above, we do need some mechanism to detect the difference. That can be either a drop (where we allow for the cron interval to ensure this is seen by the back end) or a re-add with a new version/md5sum. The former is more fragile, imo. > No need for this if the bug tracking system give the possibility to > signal a bug on a specific release, architecture and package > revision (which implicates the catalog). We don't have the currently. Can it be added easily Sebastian? I'm not overly familiar with the capabilities of mantis. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Sat Nov 12 07:07:15 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 12 Nov 2011 07:07:15 +0100 Subject: [csw-maintainers] automated catalog promotion for packages In-Reply-To: <1321045800-sup-1152@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Fri, 11 Nov 2011 16:16:05 -0500") References: <1320978197-sup-8724@pinkfloyd.chass.utoronto.ca> <1321045800-sup-1152@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Excerpts from Peter FELECAN's message of Fri Nov 11 08:25:44 -0500 2011: > >> Clocking must depend on the entry epoch of the package and not on >> the REV attribute. > > Agreed. You point out below though that no REV= update would be > required, but that's not easy to avoid if we're only looking at > catalog data. We would stop the clock on a filed bug (meeting defined > criteria) but in order to restart it for this package, we'd need to > see it re-enter the catalog. As we'd never see it actually leave the > unstable catalog, something detectable must change for it to be > noticed again. The REV= stamp of a re-rolled package is the low > hanging fruit here. The only other field likely to change is the > md5sum, or possibly the version field if there is a subsequent update. In my opinion, the entry epoch is by itself the the sufficient data and can be part of the package database and/or catalog. >> > 4. A bug against a dependency if it has a ticking promotion clock too. >> >> I don't get that because a bug for the dependency would stop its >> clock, isn't it? > > If I build against libxml2 and my new program passes the tests, a new > bug against libxml2 shouldn't hold me up. But if libxml2 is also new > (defined by ticking clock here, but that may not be ideal?), and a bug > is filed against it, packages built against it should (?) be stopped > as well. The idea here is that we don't want a situation where I need > a new SONAME to exist in the next catalog and that doesn't exist > because the package providing that was held up. > > To truly prevent this, we may need to really leverage the pkgdb > information. This is still not clear and should be reworked. Maybe a sequence and state diagram is required here. >> The Mantis schemata and interface can be changed, it's a practice >> that I've seen in some places; this will help to keep the current >> bug tracker with minimal effort, versus changing toward an >> hypothetically one which is functionally complete. > > Replacing the bug tracker is a big project so avoiding it (for now) is > still a good approach, imo. If we can bend it to our needs, we > should. I agree that changing the bug tracking system is not needed as we can coerce the current one to do what we wish. The same applies to the other systems, e.g., version control... > Aside from augmenting categories/types of bugs, we could also consider > merging all of the packages into a single item based on their bundle > tag. The problem here is that this is relatively new so not all > packages have it. Is the bundle concept supported today? >> > A subsequent update of the same package could simply overwrite the >> > existing entry in the current promotion tracking object. That would >> > be the equivalent of saying "we assume that a new update addresses >> > open bugs. it would require a new bug to stop the clock again." Does >> > that seem like a valid assumption to build in? >> >> Quite, but maybe we should add a package attribute explicating the >> bugs corrected if any; many packaging systems have this very useful >> information. > > I think Debian does something like this. It's heading in the > direction of proper change logs (a required Changelog.CSW in > $docdir?). Do you see this as needing to be visible to the promotion > system? As RedHat's RPMs Yes, the bugs addressed by the new release must be visible to the promotion system as it gives it the ability to decide if a blocking bug was corrected and restart the clock of dependent packages, &c. >> > Now, if we end up with several packages in the promotion object >> > that have stopped clocks, we'll want to eventually garbage collect >> > them. We should be able to set quite a long expiry time on this >> > but at some point, things will fall out the bottom. Do we need a >> > way for the maintainer to signal that the clock should start >> > again? I think the simplest way to achieve that is to have the >> > maintainer submit the package again and start a new clock. (This >> > would require a different REV= stamp to ensure it is detected.) >> >> No REV stamp difference needed as the clocking is not based on that >> but on the catalog entry or re-entry time. Consequently, there >> should be a re-entry procedure, manual, of course. > > As I mentioned above, we do need some mechanism to detect the > difference. That can be either a drop (where we allow for the cron > interval to ensure this is seen by the back end) or a re-add with a > new version/md5sum. The former is more fragile, imo. I prefer the the MD5 signature but, in my opinion, the entry epoch is sufficient. -- Peter From maciej at opencsw.org Sat Nov 12 15:06:19 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 12 Nov 2011 14:06:19 +0000 Subject: [csw-maintainers] automated catalog promotion for packages In-Reply-To: References: <1320978197-sup-8724@pinkfloyd.chass.utoronto.ca> <1321045800-sup-1152@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/11/12 Peter FELECAN : >> Aside from augmenting categories/types of bugs, we could also consider >> merging all of the packages into a single item based on their bundle >> tag. ?The problem here is that this is relatively new so not all >> packages have it. > > Is the bundle concept supported today? There is partial support. Supported: - look up the bundle given svr4 file md5 sum(*) Unsupported: - look up svr4 file list given bundle and catalog (*) You can look up the svr4 file given catalog and pkgname or catalog and catalogname, so you can get from pkgname to the md5. The definition of 'catalog' is the triplet of catalog release name, architecture, and OS release version. Maciej From bwalton at opencsw.org Sat Nov 12 16:26:12 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 12 Nov 2011 10:26:12 -0500 Subject: [csw-maintainers] automated catalog promotion for packages In-Reply-To: References: <1320978197-sup-8724@pinkfloyd.chass.utoronto.ca> <1321045800-sup-1152@pinkfloyd.chass.utoronto.ca> Message-ID: <1321111091-sup-5600@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Sat Nov 12 01:07:15 -0500 2011: > In my opinion, the entry epoch is by itself the the sufficient data and > can be part of the package database and/or catalog. Yes, this should be fine. I don't think it belongs in the catalog though so it should go in the pkgdb somewhere. Looking it up via the md5sum is the nicest method...it could be added to the pkginfo data or as a separately available item. Maciej is the best just of the cleanest/nicest way to place this information for retrieval. If we ever moved to an xml based catalog (I'm not proposing we do that now), then I think I'd be more amenable to including the info directly in the catalog as anything that didn't care about it could ignore it without parser modifications, etc. > > If I build against libxml2 and my new program passes the tests, a new > > bug against libxml2 shouldn't hold me up. But if libxml2 is also new > > (defined by ticking clock here, but that may not be ideal?), and a bug > > is filed against it, packages built against it should (?) be stopped > > as well. The idea here is that we don't want a situation where I need > > a new SONAME to exist in the next catalog and that doesn't exist > > because the package providing that was held up. > > > > To truly prevent this, we may need to really leverage the pkgdb > > information. > > This is still not clear and should be reworked. Maybe a sequence and > state diagram is required here. Sure. I'll work on putting something visual together to illustrate what I'm saying. > > Aside from augmenting categories/types of bugs, we could also consider > > merging all of the packages into a single item based on their bundle > > tag. The problem here is that this is relatively new so not all > > packages have it. > > Is the bundle concept supported today? It is included in all packages built with GAR. I don't know if checkpkg is enforcing the existence of the line in pkginfo though. It should if we're going to start leveraging it. Older packages won't have this info but they also won't be up for promotion in this sense so I think we can live with that. > > I think Debian does something like this. It's heading in the > > direction of proper change logs (a required Changelog.CSW in > > $docdir?). Do you see this as needing to be visible to the promotion > > system? > > As RedHat's RPMs True. > > As I mentioned above, we do need some mechanism to detect the > > difference. That can be either a drop (where we allow for the > > cron interval to ensure this is seen by the back end) or a re-add > > with a new version/md5sum. The former is more fragile, imo. > > I prefer the the MD5 signature but, in my opinion, the entry epoch > is sufficient. Ok. I too prefer the md5 signature. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From ai at opencsw.org Mon Nov 14 17:38:41 2011 From: ai at opencsw.org (Andy Igoshin) Date: Mon, 14 Nov 2011 20:38:41 +0400 Subject: [csw-maintainers] gar/gar.mk:199: warning: overriding recipe for target `extract-isa-pentium_pro' Message-ID: <2293846.x7lNU0Uc8s@netman> Hi! ? ------------------------------------------------------------------------------- ai at unstable10x [global]:~/mgar/pkg/nginx/trunk > gmake spotless gar/gar.mk:199: warning: overriding recipe for target `extract-isa- pentium_pro' gar/gar.mk:199: warning: ignoring old recipe for target `extract-isa- pentium_pro' gar/gar.mk:199: warning: overriding recipe for target `patch-isa-pentium_pro' gar/gar.mk:199: warning: ignoring old recipe for target `patch-isa- pentium_pro' gar/gar.mk:199: warning: overriding recipe for target `makepatch-isa- pentium_pro' gar/gar.mk:199: warning: ignoring old recipe for target `makepatch-isa- pentium_pro' gar/gar.mk:199: warning: overriding recipe for target `configure-isa- pentium_pro' gar/gar.mk:199: warning: ignoring old recipe for target `configure-isa- pentium_pro' gar/gar.mk:199: warning: overriding recipe for target `reset-configure-isa- pentium_pro' gar/gar.mk:199: warning: ignoring old recipe for target `reset-configure-isa- pentium_pro' gar/gar.mk:199: warning: overriding recipe for target `build-isa-pentium_pro' gar/gar.mk:199: warning: ignoring old recipe for target `build-isa- pentium_pro' gar/gar.mk:199: warning: overriding recipe for target `reset-build-isa- pentium_pro' gar/gar.mk:199: warning: ignoring old recipe for target `reset-build-isa- pentium_pro' gar/gar.mk:199: warning: overriding recipe for target `test-isa-pentium_pro' gar/gar.mk:199: warning: ignoring old recipe for target `test-isa-pentium_pro' gar/gar.mk:199: warning: overriding recipe for target `reset-test-isa- pentium_pro' gar/gar.mk:199: warning: ignoring old recipe for target `reset-test-isa- pentium_pro' gar/gar.mk:199: warning: overriding recipe for target `install-isa- pentium_pro' gar/gar.mk:199: warning: ignoring old recipe for target `install-isa- pentium_pro' gar/gar.mk:199: warning: overriding recipe for target `reset-install-isa- pentium_pro' gar/gar.mk:199: warning: ignoring old recipe for target `reset-install-isa- pentium_pro' gar/gar.mk:199: warning: overriding recipe for target `merge-isa-pentium_pro' gar/gar.mk:199: warning: ignoring old recipe for target `merge-isa- pentium_pro' gar/gar.mk:199: warning: overriding recipe for target `reset-merge-isa- pentium_pro' gar/gar.mk:199: warning: ignoring old recipe for target `reset-merge-isa- pentium_pro' gar/gar.mk:199: warning: overriding recipe for target `clean-isa-pentium_pro' gar/gar.mk:199: warning: ignoring old recipe for target `clean-isa- pentium_pro' gar/gar.mk:199: warning: overriding recipe for target `_modenv-isa- pentium_pro' gar/gar.mk:199: warning: ignoring old recipe for target `_modenv-isa- pentium_pro' ==> Removing work/solaris10-i386/cookies/global ==> Removing work/solaris10-i386/build-global ==> Removing /home/ai/mgar/pkg/nginx/trunk/work/solaris10-i386/install-global ------------------------------------------------------------------------------- Regards, -- Andy Igoshin Voronezh State University Phone: +7 473 2522406 Network Operation Center Fax: +7 473 2208820 Voronezh, Russia From jeff at cjsa.com Mon Nov 14 18:58:27 2011 From: jeff at cjsa.com (Jeffery Small) Date: Mon, 14 Nov 2011 17:58:27 GMT Subject: [csw-maintainers] What happened to ibiblio.org? Message-ID: I went to update my catalog and get the error: Connecting to ibiblio.org|152.19.134.40|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2011-11-14 09:52:46 ERROR 404: Not Found. Sure enough, everything under http://ibiblio.org/pub/packages/solaris/opencsw/ is missing. It is an empty directory. Has this mirror been removed from service? Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From jeff at cjsa.com Mon Nov 14 19:01:32 2011 From: jeff at cjsa.com (Jeffery Small) Date: Mon, 14 Nov 2011 18:01:32 GMT Subject: [csw-maintainers] Status of libidn Message-ID: I synced my catalog with http://mirrors.usc.edu/pub/csw/current and see no new packages have recently been released. However, I am finding that libidn seem to have regressed from version 1.21,REV=2011.04.25 which I have installed here, back to 1.20,REV=2011.03.04 which is listed in the catalog. Any thoughts on what is wright and wrong here? Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From dam at opencsw.org Mon Nov 14 23:57:26 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 14 Nov 2011 23:57:26 +0100 Subject: [csw-maintainers] What happened to ibiblio.org? In-Reply-To: References: Message-ID: <28B40025-5641-45BD-9F94-3464589E9595@opencsw.org> Hi Jeffery, Am 14.11.2011 um 18:58 schrieb Jeffery Small: > I went to update my catalog and get the error: > > Connecting to ibiblio.org|152.19.134.40|:80... connected. > HTTP request sent, awaiting response... 404 Not Found > 2011-11-14 09:52:46 ERROR 404: Not Found. > > Sure enough, everything under > > http://ibiblio.org/pub/packages/solaris/opencsw/ > > is missing. It is an empty directory. Has this mirror been removed from > service? OpenCSW has been moved to the high-traffic mirror section for some time now at http://mirrors.ibiblio.org/pub/mirrors/opencsw/ This is also listed at the mirror page: https://www.opencsw.org/get-it/mirrors/ You can also directly subscribe to our primary mirror http://mirror.opencsw.org/opencsw/ Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From jeff at cjsa.com Tue Nov 15 02:06:39 2011 From: jeff at cjsa.com (Jeffery Small) Date: Tue, 15 Nov 2011 01:06:39 GMT Subject: [csw-maintainers] What happened to ibiblio.org? References: <28B40025-5641-45BD-9F94-3464589E9595@opencsw.org> Message-ID: Dagobert Michelsen writes: >OpenCSW has been moved to the high-traffic mirror section for some time now at > http://mirrors.ibiblio.org/pub/mirrors/opencsw/ Dago: Thanks. I see that the change was made in the pkg-get.conf.csw but it never got migrated over to my local config file. I should have check there, or on the mirrors page, first! Back in business! Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From dam at opencsw.org Tue Nov 15 09:28:22 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 15 Nov 2011 09:28:22 +0100 Subject: [csw-maintainers] Status of libidn In-Reply-To: References: Message-ID: <5A9CB319-AD44-477B-A922-157B08BA5AED@opencsw.org> Hi Jeffery, Am 14.11.2011 um 19:01 schrieb Jeffery Small: > I synced my catalog with http://mirrors.usc.edu/pub/csw/current and > see no new packages have recently been released. Most updated nowadays go into "unstable" which are later on pushed to "testing" (the former "current"). This is explained at http://www.opencsw.org/2011/11/release-branches-adjusted/ https://www.opencsw.org/get-it/releases/ > However, I am finding > that libidn seem to have regressed from version 1.21,REV=2011.04.25 which > I have installed here, back to 1.20,REV=2011.03.04 which is listed in the > catalog. Any thoughts on what is wright and wrong here? This looks like an error in the package push: -rw-rw-r-- 5 web web 13269 Mar 10 2011 current/sparc/5.9/libidn-1.20,REV=2011.03.04-SunOS5.9-all-CSW.pkg.gz -rw-r--r-- 3 web web 194693 May 5 2011 current/sparc/5.9/libidn11-1.22,REV=2011.05.05-SunOS5.9-sparc-CSW.pkg.gz -rw-r--r-- 3 web web 105022 May 5 2011 current/sparc/5.9/libidn_dev-1.22,REV=2011.05.05-SunOS5.9-sparc-CSW.pkg.gz -rw-r--r-- 3 web web 31175 May 5 2011 current/sparc/5.9/libidn_utils-1.22,REV=2011.05.05-SunOS5.9-sparc-CSW.pkg.gz I have made a complete new set and just published it to unstable/, it should be visible in a couple of hours: -rw-r--r-- 1 dam csw 175979 Nov 15 08:33 libidn11-1.22,REV=2011.11.15-SunOS5.9-i386-CSW.pkg.gz -rw-r--r-- 1 dam csw 195203 Nov 15 08:19 libidn11-1.22,REV=2011.11.15-SunOS5.9-sparc-CSW.pkg.gz -rw-r--r-- 1 dam csw 104607 Nov 15 08:33 libidn_dev-1.22,REV=2011.11.15-SunOS5.9-i386-CSW.pkg.gz -rw-r--r-- 1 dam csw 105229 Nov 15 08:18 libidn_dev-1.22,REV=2011.11.15-SunOS5.9-sparc-CSW.pkg.gz -rw-r--r-- 1 dam csw 13280 Nov 15 08:33 libidn_stub-1.22,REV=2011.11.15-SunOS5.9-all-CSW.pkg.gz -rw-r--r-- 1 dam csw 29445 Nov 15 08:33 libidn_utils-1.22,REV=2011.11.15-SunOS5.9-i386-CSW.pkg.gz -rw-r--r-- 1 dam csw 31207 Nov 15 08:18 libidn_utils-1.22,REV=2011.11.15-SunOS5.9-sparc-CSW.pkg.gz BTW, the previous CSWlibidn is now an empty stub and the contents has been split into a library package, development files and utilities. Best regards -- Dago PS: I remember now, libidn already was a stub although the name does not match the conventional *stub, the version should be safe to ignore as it pulls in the real packages. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Tue Nov 15 11:32:57 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 15 Nov 2011 11:32:57 +0100 Subject: [csw-maintainers] gar/gar.mk:199: warning: overriding recipe for target `extract-isa-pentium_pro' In-Reply-To: <2293846.x7lNU0Uc8s@netman> References: <2293846.x7lNU0Uc8s@netman> Message-ID: Hi Andy, Am 14.11.2011 um 17:38 schrieb Andy Igoshin: > Hi! > > ? > > ------------------------------------------------------------------------------- > ai at unstable10x [global]:~/mgar/pkg/nginx/trunk > gmake spotless > gar/gar.mk:199: warning: overriding recipe for target `extract-isa- > pentium_pro' During the last technical camp we decided to raise the general build level on Solaris 10 to pentium_pro and sparcv8plus. As you also added pentium_pro this lead to double definition of rules. This has been fixed in r16195 (duplicate ISA requests are now only processed once). You can safely take out the extra definitions. Additionally, I noticed that after the change of definitions in r14023 as announced in http://lists.opencsw.org/pipermail/maintainers/2011-March/014351.html you may want to add ISAEXEC = 1. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From ai at opencsw.org Tue Nov 15 17:45:09 2011 From: ai at opencsw.org (Andy Igoshin) Date: Tue, 15 Nov 2011 20:45:09 +0400 Subject: [csw-maintainers] gar/gar.mk:199: warning: overriding recipe for target `extract-isa-pentium_pro' In-Reply-To: References: <2293846.x7lNU0Uc8s@netman> Message-ID: <10247139.0hsmRldhAx@netman> On Tuesday 15 November 2011 11:32:57 Dagobert Michelsen wrote: > Am 14.11.2011 um 17:38 schrieb Andy Igoshin: > > > > ------------------------------------------------------------------------ > > ------- ai at unstable10x [global]:~/mgar/pkg/nginx/trunk > gmake spotless > > gar/gar.mk:199: warning: overriding recipe for target `extract-isa- > > pentium_pro' > > During the last technical camp we decided to raise the general build level > on Solaris 10 to pentium_pro and sparcv8plus. As you also added pentium_pro > this lead to double definition of rules. This has been fixed in r16195 > (duplicate ISA requests are now only processed once). You can safely take > out the extra definitions. > > Additionally, I noticed that after the change of definitions in r14023 as > announced in > http://lists.opencsw.org/pipermail/maintainers/2011-March/014351.html > you may want to add ISAEXEC = 1. thanks! -- Andy Igoshin Voronezh State University Phone: +7 473 2522406 Network Operation Center Fax: +7 473 2208820 Voronezh, Russia From maciej at opencsw.org Wed Nov 16 15:16:29 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 16 Nov 2011 14:16:29 +0000 Subject: [csw-maintainers] The old documentation is now retired Message-ID: Hello maintainers, I've archived[1] and retired all the old website content (known as "build standards") by removing from the website and submitting a text file into our subversion repository, if we ever wanted to look something up. Maciej [1] http://sourceforge.net/apps/trac/gar/changeset/16200 From bwalton at opencsw.org Wed Nov 16 15:23:23 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 16 Nov 2011 09:23:23 -0500 Subject: [csw-maintainers] The old documentation is now retired In-Reply-To: References: Message-ID: <1321453372-sup-2989@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Wed Nov 16 09:16:29 -0500 2011: > I've archived[1] and retired all the old website content (known as > "build standards") by removing from the website and submitting a > text file into our subversion repository, if we ever wanted to look > something up. +1! :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From skayser at opencsw.org Wed Nov 16 23:27:41 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 16 Nov 2011 23:27:41 +0100 Subject: [csw-maintainers] bugs.opencsw.org now with URL shortcuts Message-ID: <20111116222741.GS26160@sebastiankayser.de> Hi, to facilitate looking up bug information, I've just added two URL redirects for the bugs.opencsw.org vhost: Lookup via ID: http://bugs.opencsw.org/id/1234 Lookup via login: http://bugs.opencsw.org/m(aintainer)?/skayser There's a third one in the pipeline Lookup via pkg: http://bugs.opencsw.org/p(ackage)?/xterm This one needs more work as it requires access to the Mantis DB from Apache to figure out the package id which used in the Mantis URLs. Let me know what you think and if you want more of them. Sebastian From pfelecan at opencsw.org Thu Nov 17 09:41:46 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 17 Nov 2011 09:41:46 +0100 Subject: [csw-maintainers] bugs.opencsw.org now with URL shortcuts In-Reply-To: <20111116222741.GS26160@sebastiankayser.de> (Sebastian Kayser's message of "Wed, 16 Nov 2011 23:27:41 +0100") References: <20111116222741.GS26160@sebastiankayser.de> Message-ID: Sebastian Kayser writes: > Lookup via ID: http://bugs.opencsw.org/id/1234 > Lookup via login: http://bugs.opencsw.org/m(aintainer)?/skayser > > There's a third one in the pipeline > > Lookup via pkg: http://bugs.opencsw.org/p(ackage)?/xterm Excellent. Thanks. Question: when you write 'm(aintainer)' do you mean 'm' or 'maintainer' (RE (m(aintainer)* ) ? -- Peter From dam at opencsw.org Thu Nov 17 10:35:00 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 17 Nov 2011 10:35:00 +0100 Subject: [csw-maintainers] bugs.opencsw.org now with URL shortcuts In-Reply-To: References: <20111116222741.GS26160@sebastiankayser.de> Message-ID: <879A4E58-E944-4BFB-8F2F-67F9C2C1BFE0@opencsw.org> Hi Peter, Am 17.11.2011 um 09:41 schrieb Peter FELECAN: > Sebastian Kayser writes: > >> Lookup via ID: http://bugs.opencsw.org/id/1234 >> Lookup via login: http://bugs.opencsw.org/m(aintainer)?/skayser >> >> There's a third one in the pipeline >> >> Lookup via pkg: http://bugs.opencsw.org/p(ackage)?/xterm > > Excellent. Thanks. > > Question: when you write 'm(aintainer)' do you mean 'm' or 'maintainer' > (RE (m(aintainer)* ) ? This works: http://bugs.opencsw.org/maintainer/dam which I especially like as it conforms http://www.opencsw.org/maintainer/dam Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From raos at opencsw.org Thu Nov 17 12:15:58 2011 From: raos at opencsw.org (Rafael Ostertag) Date: Thu, 17 Nov 2011 12:15:58 +0100 Subject: [csw-maintainers] glib2: finally some results In-Reply-To: <86C49AB2-92F0-4311-9488-09219E18BBAB@opencsw.org> References: <20111009172646.GA25605@bender.opencsw.org> <85555CAF-0F97-422A-88FA-D91663ED540C@opencsw.org> <20111014053800.GC15669@bender.opencsw.org> <86C49AB2-92F0-4311-9488-09219E18BBAB@opencsw.org> Message-ID: <20111117111558.GB10611@bender.opencsw.org> Hi Dago On Thu, Oct 27, 2011 at 02:45:24PM +0200, Dagobert Michelsen wrote: > Hi Rafi, > > Am 14.10.2011 um 07:38 schrieb Rafael Ostertag: > > On Thu, Oct 13, 2011 at 12:59:23PM +0200, Dagobert Michelsen wrote: > >> Hi Rafi, > >> > >> Am 09.10.2011 um 19:26 schrieb Rafael Ostertag: > >>> I just committed (r15901) the recipe for glib2 which I hope is deployment ready. > >>> > >>> However, I would appreciate if you could have a look at it and give it > >>> a go/no-go. > >> > >> The recipe looks ok, I am fwd'ing to maintainers for a broader test audience. > > > > Sounds good to me. Thanks! > > I have compiled pygobject against glib2 and it looks pretty good. > Did you have some progress on an updated gtk2 ? Sorry for the late response, I somehow managed to miss this mail completely. So far I have no progress on gtk2, but if you think glib2 looks good, I guess there is nothing refraining me from moving on to gtk2. Best regards rafi > > > Best regards > > -- Dago > > -- > "You don't become great by trying to be great, you become great by wanting to do something, > and then doing it so hard that you become great in the process." - xkcd #896 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From pfelecan at opencsw.org Thu Nov 17 14:00:10 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 17 Nov 2011 14:00:10 +0100 Subject: [csw-maintainers] bugs.opencsw.org now with URL shortcuts In-Reply-To: <879A4E58-E944-4BFB-8F2F-67F9C2C1BFE0@opencsw.org> (Dagobert Michelsen's message of "Thu, 17 Nov 2011 10:35:00 +0100") References: <20111116222741.GS26160@sebastiankayser.de> <879A4E58-E944-4BFB-8F2F-67F9C2C1BFE0@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 17.11.2011 um 09:41 schrieb Peter FELECAN: >> Sebastian Kayser writes: >> >>> Lookup via ID: http://bugs.opencsw.org/id/1234 >>> Lookup via login: http://bugs.opencsw.org/m(aintainer)?/skayser >>> >>> There's a third one in the pipeline >>> >>> Lookup via pkg: http://bugs.opencsw.org/p(ackage)?/xterm >> >> Excellent. Thanks. >> >> Question: when you write 'm(aintainer)' do you mean 'm' or 'maintainer' >> (RE (m(aintainer)* ) ? > > This works: > http://bugs.opencsw.org/maintainer/dam > which I especially like as it conforms > http://www.opencsw.org/maintainer/dam Tx. I didn't get that the ? in m(maintainer)? was the 0 or 1 occurrence in a regex... therefore http://bugs.opencsw.org/m/pfelecan works -- Peter From maciej at opencsw.org Thu Nov 17 14:37:40 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 17 Nov 2011 13:37:40 +0000 Subject: [csw-maintainers] bugs.opencsw.org now with URL shortcuts In-Reply-To: References: <20111116222741.GS26160@sebastiankayser.de> <879A4E58-E944-4BFB-8F2F-67F9C2C1BFE0@opencsw.org> Message-ID: 2011/11/17 Peter FELECAN : > Tx. I didn't get that the ? in m(maintainer)? was the 0 or 1 occurrence > in a regex... therefore http://bugs.opencsw.org/m/pfelecan works That's the idea, I think. It's nice to have the short version available. From bwalton at opencsw.org Fri Nov 18 02:31:43 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 17 Nov 2011 20:31:43 -0500 Subject: [csw-maintainers] automated catalog promotion for packages In-Reply-To: References: <1320978197-sup-8724@pinkfloyd.chass.utoronto.ca> Message-ID: <1321579275-sup-5791@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Fri Nov 11 08:25:44 -0500 2011: > > 4. A bug against a dependency if it has a ticking promotion clock too. > > I don't get that because a bug for the dependency would stop its > clock, isn't it? Sorry for the delay here...I've been thinking about this further and I no longer think that bugs on dependencies is a good metric. We should focus on bugs for anything in a bundle as previously discussed, but dependencies are a different matter. When it comes to dependencies, what we're concerned about is interface stability, not functionality. This makes the assumption that passing the test suite indicates that even a buggy version of a package is functional for the needs of the package under inspection. What we want to prevent is changes in SONAME or for other public interfaces that might break things depending on them. For example, the php (5.2.9) in dublin right now has breakage in the gd module as libjpeg was updated and the SONAME changed. If we were looking at bugs on packages, we'd still have made the promotion of gd. This now becomes a much larger puzzle... We need to ensure that a package moving from unstable to testing does not break packages already in test and we need to make sure that a package cannot be promoted if the testing catalog does not provide the required interfaces. The pkgdb can help with this, but the questions we need to ask it are more complex. I think Maciej indicated that we could run a set of packages that are up for promotion through checkpkg using the target catalog. This would be a good way to ensure that binary stuff continues to function...it won't help with other types of interfaces, but that's a smaller problem overall in my opinion. Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Nov 18 02:59:09 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 17 Nov 2011 20:59:09 -0500 Subject: [csw-maintainers] bugs.opencsw.org now with URL shortcuts In-Reply-To: <20111116222741.GS26160@sebastiankayser.de> References: <20111116222741.GS26160@sebastiankayser.de> Message-ID: <1321581517-sup-8586@pinkfloyd.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Wed Nov 16 17:27:41 -0500 2011: Hi Sebastian, > to facilitate looking up bug information, I've just added two URL redirects > for the bugs.opencsw.org vhost: > > Lookup via ID: http://bugs.opencsw.org/id/1234 > Lookup via login: http://bugs.opencsw.org/m(aintainer)?/skayser > > There's a third one in the pipeline > > Lookup via pkg: http://bugs.opencsw.org/p(ackage)?/xterm This is great! Thanks -Benk -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Nov 18 03:05:05 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 17 Nov 2011 21:05:05 -0500 Subject: [csw-maintainers] getting people onto dublin (from: stable) Message-ID: <1321581761-sup-1975@pinkfloyd.chass.utoronto.ca> Hi All, We should really look at entirely disabling access to the old stable release. I know that we're calling it legacy (stable is just a symlink), but there may still be sites running it... I think we should send notice to users@ and announce@ and then soon after drop it completely. This doesn't get sites upgraded, but it will prevent any new installs from legacy and will break any future update attempts from sites running it now which should prompt them to change their mirror settings. What do others think? 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 18 09:26:15 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 18 Nov 2011 09:26:15 +0100 Subject: [csw-maintainers] getting people onto dublin (from: stable) In-Reply-To: <1321581761-sup-1975@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Thu, 17 Nov 2011 21:05:05 -0500") References: <1321581761-sup-1975@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Hi All, > > We should really look at entirely disabling access to the old stable > release. I know that we're calling it legacy (stable is just a > symlink), but there may still be sites running it... > > I think we should send notice to users@ and announce@ and then soon > after drop it completely. This doesn't get sites upgraded, but it > will prevent any new installs from legacy and will break any future > update attempts from sites running it now which should prompt them to > change their mirror settings. > > What do others think? I'm tempted to say "go with it" but can you give the rationale? -- Peter From dam at opencsw.org Fri Nov 18 09:54:27 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 18 Nov 2011 09:54:27 +0100 Subject: [csw-maintainers] getting people onto dublin (from: stable) In-Reply-To: <1321581761-sup-1975@pinkfloyd.chass.utoronto.ca> References: <1321581761-sup-1975@pinkfloyd.chass.utoronto.ca> Message-ID: <8E344CFF-5214-41CD-BC5B-2F70DCC7552F@opencsw.org> Hi Ben, Am 18.11.2011 um 03:05 schrieb Ben Walton: > We should really look at entirely disabling access to the old stable > release. I know that we're calling it legacy (stable is just a > symlink), but there may still be sites running it... > > I think we should send notice to users@ and announce@ and then soon > after drop it completely. This doesn't get sites upgraded, but it > will prevent any new installs from legacy and will break any future > update attempts from sites running it now which should prompt them to > change their mirror settings. > > What do others think? We talked about adding something like README to a catalog, which would then be displayed by pkgutil on the next invocation. We discussed that in Kiel and it is noted in the Saturday notes under https://docs.google.com/document/d/1fIPdBHeNU0ZJ02zYdL8rPwNwPT5qnf_oYnXlpMrUDcE/edit?hl=en_US "How / when to introduce backward-incompatible changes" "The plan for the stable release" Additionally, I think we should never disable access to anything the hard way. Adding a note to be displayed would be IMHO best. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Fri Nov 18 09:59:57 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 18 Nov 2011 09:59:57 +0100 Subject: [csw-maintainers] automated catalog promotion for packages In-Reply-To: <1321579275-sup-5791@pinkfloyd.chass.utoronto.ca> References: <1320978197-sup-8724@pinkfloyd.chass.utoronto.ca> <1321579275-sup-5791@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Ben, Am 18.11.2011 um 02:31 schrieb Ben Walton: > We need to ensure that a package moving from unstable to testing does > not break packages already in test and we need to make sure that a > package cannot be promoted if the testing catalog does not provide the > required interfaces. > > The pkgdb can help with this, but the questions we need to ask it are > more complex. I think Maciej indicated that we could run a set of > packages that are up for promotion through checkpkg using the target > catalog. This would be a good way to ensure that binary stuff > continues to function...it won't help with other types of interfaces, > but that's a smaller problem overall in my opinion. I had talked about this with Maciej some time ago. IIRC there were two major concerns: - It is really slow as it involves testing the catalog as a whole. This may be simplified to only look for new packages and all of their dependencies. The initial discussion was about testing this on every push to unstable which probably really is too much, but I guess it may be ok for a daily propagation. - There are always lots of old errors from other packages disturbing the measurement. Last thing I remember was an idea to see if the number of reported errors lessened in total and that there were no new errors. That means errors(new catalog) subset of errors(old catalog) Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Fri Nov 18 14:11:51 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 18 Nov 2011 08:11:51 -0500 Subject: [csw-maintainers] getting people onto dublin (from: stable) In-Reply-To: References: <1321581761-sup-1975@pinkfloyd.chass.utoronto.ca> Message-ID: <1321621838-sup-9772@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Fri Nov 18 03:26:15 -0500 2011: > I'm tempted to say "go with it" but can you give the rationale? It was prompted by a bug in my open list. I currently have a bug on findutils for the version in stable. It's sporting a potential local root exploit. I'm not likely to setup a stack capable of fixing it as I don't think that's time well spent now. The generalization of this is that since nobody that I'm aware of (Peter B tried long ago) is looking at any updates for this set of packages, it harms us reputation-wise if people are still using it. We can't make them upgrade if they're already using it, but we can make it quite clear what the options are the next time they try and we can also prevent the problem from getting worse. I see Dago's reply though and that sounds like an ok solution to the problem as well. The end result is that we need to let anyone that is using the old stable know that it's not supported by us any longer. If they continue to run it, it's at their own risk. 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 18 15:48:14 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 18 Nov 2011 15:48:14 +0100 Subject: [csw-maintainers] getting people onto dublin (from: stable) In-Reply-To: <1321621838-sup-9772@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Fri, 18 Nov 2011 08:11:51 -0500") References: <1321581761-sup-1975@pinkfloyd.chass.utoronto.ca> <1321621838-sup-9772@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > I see Dago's reply though and that sounds like an ok solution to the > problem as well. The end result is that we need to let anyone that is > using the old stable know that it's not supported by us any longer. > If they continue to run it, it's at their own risk. Thank you. Agreed. -- Peter From maciej at opencsw.org Fri Nov 18 23:06:29 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 18 Nov 2011 22:06:29 +0000 Subject: [csw-maintainers] getting people onto dublin (from: stable) In-Reply-To: <8E344CFF-5214-41CD-BC5B-2F70DCC7552F@opencsw.org> References: <1321581761-sup-1975@pinkfloyd.chass.utoronto.ca> <8E344CFF-5214-41CD-BC5B-2F70DCC7552F@opencsw.org> Message-ID: 2011/11/18 Dagobert Michelsen : > Additionally, I think we should never disable access to anything the hard way. > Adding a note to be displayed would be IMHO best. I had this radical idea: mv stable stable-do-not-use Concerns and answers: 1. "sites that have subscribed to stable won't get updates" Answer: Stable doesn't get updates anyway 2. "sites that have subscribed to stable will see error during update attempts" Answer: Yes, that's the idea: they'll see errors and will realize they need to do something about it. 3. "sites that are desperate and must keep using stable will have to update their configuration" Answer: Tough luck. 4. "new sites will not be able to subscribe to stable in a straightforward way" Answer: Exactly! They shouldn't subscribe to stable. Maciej From bonivart at opencsw.org Fri Nov 18 23:19:01 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 18 Nov 2011 23:19:01 +0100 Subject: [csw-maintainers] getting people onto dublin (from: stable) In-Reply-To: References: <1321581761-sup-1975@pinkfloyd.chass.utoronto.ca> <8E344CFF-5214-41CD-BC5B-2F70DCC7552F@opencsw.org> Message-ID: 2011/11/18 Maciej (Matchek) Blizi?ski : > 2011/11/18 Dagobert Michelsen : >> Additionally, I think we should never disable access to anything the hard way. >> Adding a note to be displayed would be IMHO best. > > I had this radical idea: > > mv stable stable-do-not-use > > Concerns and answers: > > 1. "sites that have subscribed to stable won't get updates" > Answer: Stable doesn't get updates anyway > > 2. "sites that have subscribed to stable will see error during update attempts" > Answer: Yes, that's the idea: they'll see errors and will realize > they need to do something about it. > > 3. "sites that are desperate and must keep using stable will have to > update their configuration" > Answer: Tough luck. > > 4. "new sites will not be able to subscribe to stable in a straightforward way" > Answer: Exactly! They shouldn't subscribe to stable. This is more like the end result I would like to see as well. We should not remove stable completely, instead a rename does the needed job. However, I think we need to properly announce it in all channels available to us like users list, web site, irc title and twitter. They should be given something like a month of advance notice. /peter From maciej at opencsw.org Sat Nov 19 11:43:49 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 19 Nov 2011 10:43:49 +0000 Subject: [csw-maintainers] getting people onto dublin (from: stable) In-Reply-To: References: <1321581761-sup-1975@pinkfloyd.chass.utoronto.ca> <8E344CFF-5214-41CD-BC5B-2F70DCC7552F@opencsw.org> Message-ID: 2011/11/18 Peter Bonivart : > However, I think we need to properly announce it in all channels > available to us like users list, web site, irc title and twitter. They > should be given something like a month of advance notice. Yes, we definitely need to communicate this via all channels we have. Does this sound good to others? What timeline do you suggest? The announcement at the beginning of December and the deprecation some time in January 2012? Maciej From jgoerzen at opencsw.org Sat Nov 19 22:32:58 2011 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Sat, 19 Nov 2011 13:32:58 -0800 Subject: [csw-maintainers] dovecot 2.0 upgrade need help Message-ID: <4EC8208A.4090708@opencsw.org> Hello All, Can anyone help me with the upgrade of dovecot to version 2. I've run into a problem (bug # 0004866) where the configuration file is supposed to go. In previous versions of dovecot (1.2.17) the dovecot.conf file is located at /etc/opt/csw/dovecot.conf. Now with the newer version 2.0 the dovecot.conf file is supposed to go in /etc/opt/csw/dovecot/dovecot.conf. When I respun the recipe with an updated sysconfdir=/etc/opt/csw/dovecot, the resulting builds are now looking in /etc/opt/csw/dovecot/dovecot! This is not right. Suggestions? Thanks, Jake From bwalton at opencsw.org Sat Nov 19 22:41:03 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 19 Nov 2011 16:41:03 -0500 Subject: [csw-maintainers] dovecot 2.0 upgrade need help In-Reply-To: <4EC8208A.4090708@opencsw.org> References: <4EC8208A.4090708@opencsw.org> Message-ID: <1321738767-sup-9962@pinkfloyd.chass.utoronto.ca> Excerpts from Jake Goerzen's message of Sat Nov 19 16:32:58 -0500 2011: Hi Jake, > Now with the newer version 2.0 the dovecot.conf file is supposed to go > in /etc/opt/csw/dovecot/dovecot.conf. When I respun the recipe with an > updated sysconfdir=/etc/opt/csw/dovecot, the resulting builds are now > looking in /etc/opt/csw/dovecot/dovecot! This is not right. > > Suggestions? Just set sysconfdir to /etc/opt/csw (or leave the default from DIRPATHS in place). That should see you get the result you need. It looks as though it's appending dovecot/ to whatever is set for sysconfdir. Is the old config compatible with the new? If you, you'll want to look at a migrateconf for dovecot.conf too. HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Nov 21 02:01:55 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 20 Nov 2011 20:01:55 -0500 Subject: [csw-maintainers] automated catalog promotion for packages In-Reply-To: References: <1320978197-sup-8724@pinkfloyd.chass.utoronto.ca> <1321579275-sup-5791@pinkfloyd.chass.utoronto.ca> Message-ID: <1321836975-sup-4530@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Nov 18 03:59:57 -0500 2011: > - It is really slow as it involves testing the catalog as a whole. > This may be simplified to only look for new packages and all of > their dependencies. The initial discussion was about testing this > on every push to unstable which probably really is too much, but I > guess it may be ok for a daily propagation. Yes, it would be heavy, but it's really the only way to validate the binary interfaces. We'd need to ensure that the set going into the testing catalog passed a set of checks like when we use csw-upload-pkg. That's pretty straight forward. We then need to verify that anything depending on the new packages (if we're talking update) still passes checkpkg. This is where things start to get tricky. As you say, old errors are bound to be there and those shouldn't block anything. > - There are always lots of old errors from other packages disturbing > the measurement. Last thing I remember was an idea to see if the > number of reported errors lessened in total and that there were no > new errors. That means errors(new catalog) subset of errors(old > catalog) I'm not sure we should test the whole catalog. Rather, I'd narrow it to the affected packages. We can use a similar heuristic, but with fewer packages involved. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From daniel at opencsw.org Thu Nov 24 17:44:46 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Fri, 25 Nov 2011 00:44:46 +0800 Subject: [csw-maintainers] freshening up Ganglia packages/need rrdtool Message-ID: <4ECE747E.9060809@opencsw.org> Hi, I'm trying to build the Ganglia packages on unstable10s and unstable10x $ find /opt/csw -name rrd.h doesn't find anything on either machine. Can someone assist me: a) having the dev files for rrdtool installed b) installing the latest libconfuse packages I have built (v2.7) /home/daniel/pkgs/libconfuse-2.7,REV=2011.11.24-SunOS5.10-i386-CSW.pkg.gz /home/daniel/pkgs/libconfuse-2.7,REV=2011.11.24-SunOS5.10-sparc-CSW.pkg.gz It's a while since I've built any OpenCSW packages so any feedback is welcome Regards, Daniel From dam at opencsw.org Thu Nov 24 17:52:37 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 24 Nov 2011 17:52:37 +0100 Subject: [csw-maintainers] freshening up Ganglia packages/need rrdtool In-Reply-To: <4ECE747E.9060809@opencsw.org> References: <4ECE747E.9060809@opencsw.org> Message-ID: <72B0271D-2C12-47DA-A6AF-77A1B55A5ECB@opencsw.org> Hi Daniel, Am 24.11.2011 um 17:44 schrieb Daniel Pocock: > I'm trying to build the Ganglia packages on unstable10s and unstable10x > > $ find /opt/csw -name rrd.h > > doesn't find anything on either machine. > > Can someone assist me: > > a) having the dev files for rrdtool installed Done. Please add BUILD_DEP_PKGS += CSWrrdtool-dev > b) installing the latest libconfuse packages I have built (v2.7) > > /home/daniel/pkgs/libconfuse-2.7,REV=2011.11.24-SunOS5.10-i386-CSW.pkg.gz > /home/daniel/pkgs/libconfuse-2.7,REV=2011.11.24-SunOS5.10-sparc-CSW.pkg.gz > > It's a while since I've built any OpenCSW packages so any feedback is > welcome I suggest rebuilding this also to the latest naming standard which would be libconfuse0 and CSWlibconfuse0 together with CSWlibconfuse-dev and libconfuse_dev and obsolete the old name. You can look at http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/libssh2/trunk/Makefile for an example. Please let me know if I can assist you in this matter. After that I suggest you release libconfuse so I can install it and then proceed with ganglia. Is this possible? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From daniel at opencsw.org Thu Nov 24 18:44:07 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Fri, 25 Nov 2011 01:44:07 +0800 Subject: [csw-maintainers] freshening up Ganglia packages/need rrdtool In-Reply-To: <72B0271D-2C12-47DA-A6AF-77A1B55A5ECB@opencsw.org> References: <4ECE747E.9060809@opencsw.org> <72B0271D-2C12-47DA-A6AF-77A1B55A5ECB@opencsw.org> Message-ID: <4ECE8267.6040900@opencsw.org> >> a) having the dev files for rrdtool installed >> > Done. Please add > BUILD_DEP_PKGS += CSWrrdtool-dev > Done > >> b) installing the latest libconfuse packages I have built (v2.7) >> >> /home/daniel/pkgs/libconfuse-2.7,REV=2011.11.24-SunOS5.10-i386-CSW.pkg.gz >> /home/daniel/pkgs/libconfuse-2.7,REV=2011.11.24-SunOS5.10-sparc-CSW.pkg.gz >> >> It's a while since I've built any OpenCSW packages so any feedback is >> welcome >> > I suggest rebuilding this also to the latest naming standard which would be > libconfuse0 and CSWlibconfuse0 together with CSWlibconfuse-dev and libconfuse_dev > and obsolete the old name. You can look at > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/libssh2/trunk/Makefile > for an example. Please let me know if I can assist you in this matter. > The example is not so clear, because libssh2 is downloading libssh2-1.3.0.tar.gz, while there is no libconfuse0-2.7.0.tar.gz to download Therefore, where do I use the real name, and in which variables do I use libconfuse0 with the 0? > After that I suggest you release libconfuse so I can install it and then proceed with ganglia. > Is this possible? > Can you elaborate on `release'? I notice that /home/testing doesn't exist any more - what is the preferred way to release? From maciej at opencsw.org Thu Nov 24 19:04:08 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 24 Nov 2011 18:04:08 +0000 Subject: [csw-maintainers] freshening up Ganglia packages/need rrdtool In-Reply-To: <4ECE8267.6040900@opencsw.org> References: <4ECE747E.9060809@opencsw.org> <72B0271D-2C12-47DA-A6AF-77A1B55A5ECB@opencsw.org> <4ECE8267.6040900@opencsw.org> Message-ID: 2011/11/24 Daniel Pocock : >> After that I suggest you release libconfuse so I can install it and then proceed with ganglia. >> Is this possible? >> > Can you elaborate on `release'? ?I notice that /home/testing doesn't > exist any more - what is the preferred way to release? csw-upload-pkg ... More information: http://lists.opencsw.org/pipermail/maintainers/2011-May/014576.html And even more: http://lists.opencsw.org/pipermail/maintainers/2011-May/014545.html Remember that running csw-upload-pkg actually pushes the package to the official mirror. For trial-and-error kind of work, experimental (/home/experimental/) is a much better place. Maciej From daniel at opencsw.org Thu Nov 24 19:06:11 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Fri, 25 Nov 2011 02:06:11 +0800 Subject: [csw-maintainers] freshening up Ganglia packages/need rrdtool In-Reply-To: <4ECE8267.6040900@opencsw.org> References: <4ECE747E.9060809@opencsw.org> <72B0271D-2C12-47DA-A6AF-77A1B55A5ECB@opencsw.org> <4ECE8267.6040900@opencsw.org> Message-ID: <4ECE8793.10505@opencsw.org> >> I suggest rebuilding this also to the latest naming standard which would be >> libconfuse0 and CSWlibconfuse0 together with CSWlibconfuse-dev and libconfuse_dev >> and obsolete the old name. You can look at >> http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/libssh2/trunk/Makefile >> for an example. Please let me know if I can assist you in this matter. >> >> > The example is not so clear, because libssh2 is downloading > libssh2-1.3.0.tar.gz, while there is no libconfuse0-2.7.0.tar.gz to download > > Therefore, where do I use the real name, and in which variables do I use > libconfuse0 with the 0? > > I played around with it a bit and ended up with these: The following packages have been built: CSWlibconfuse0-1 /home/daniel/pkgs/libconfuse0_1-2.7,REV=2011.11.24-SunOS5.10-sparc-CSW.pkg.gz CSWlibconfuse0-dev /home/daniel/pkgs/libconfuse0_dev-2.7,REV=2011.11.24-SunOS5.10-sparc-CSW.pkg.gz Can you please check my Makefile and see if I'm doing it correctly? What is the next step to release? Would you be able to release them for me (I'm 7 hours ahead of you now) so I can test in the morning? >> After that I suggest you release libconfuse so I can install it and then proceed with ganglia. >> Is this possible? >> >> > Can you elaborate on `release'? I notice that /home/testing doesn't > exist any more - what is the preferred way to release? > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From daniel at opencsw.org Thu Nov 24 19:14:46 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Fri, 25 Nov 2011 02:14:46 +0800 Subject: [csw-maintainers] freshening up Ganglia packages/need rrdtool In-Reply-To: References: <4ECE747E.9060809@opencsw.org> <72B0271D-2C12-47DA-A6AF-77A1B55A5ECB@opencsw.org> <4ECE8267.6040900@opencsw.org> Message-ID: <4ECE8996.4060202@opencsw.org> On 25/11/11 02:04, Maciej (Matchek) Blizi?ski wrote: > 2011/11/24 Daniel Pocock : > >>> After that I suggest you release libconfuse so I can install it and then proceed with ganglia. >>> Is this possible? >>> >>> >> Can you elaborate on `release'? I notice that /home/testing doesn't >> exist any more - what is the preferred way to release? >> > csw-upload-pkg ... > > More information: > http://lists.opencsw.org/pipermail/maintainers/2011-May/014576.html > And even more: > http://lists.opencsw.org/pipermail/maintainers/2011-May/014545.html > > Remember that running csw-upload-pkg actually pushes the package to > the official mirror. For trial-and-error kind of work, experimental > (/home/experimental/) is a much better place. > > Thanks for pointing this out - I tried this, but various errors on both the build host and the login host - can you suggest what I'm doing wrong? -bash-3.00$ /home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg ~/pkgs/libconfuse0_* WARNING:root:This script is meant to be run on the login host. WARNING:root:Error reading /etc/opt/csw/releases/auth/daniel: [Errno 2] No such file or directory: '/etc/opt/csw/releases/auth/daniel' daniel's pkg release password> Processing 4 file(s). Please wait. Traceback (most recent call last): File "/home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg", line 608, in uploader.Upload() File "/home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg", line 134, in Upload self._ImportMetadata(filename) File "/home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg", line 101, in _ImportMetadata metadata = self._rest_client.GetPkgByMd5(md5_sum) File "/home/daniel/opencsw/.buildsys/v2/lib/python/rest.py", line 29, in GetPkgByMd5 data = urllib2.urlopen(url).read() File "/opt/csw/lib/python/urllib2.py", line 126, in urlopen return _opener.open(url, data, timeout) File "/opt/csw/lib/python/urllib2.py", line 391, in open response = self._open(req, data) File "/opt/csw/lib/python/urllib2.py", line 409, in _open '_open', req) File "/opt/csw/lib/python/urllib2.py", line 369, in _call_chain result = func(*args) File "/opt/csw/lib/python/urllib2.py", line 1170, in http_open return self.do_open(httplib.HTTPConnection, req) File "/opt/csw/lib/python/urllib2.py", line 1145, in do_open raise URLError(err) urllib2.URLError: -bash-3.00$ /home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg ~/pkgs/libconfuse0_* -bash-3.00$ logout Connection to unstable10s closed. daniel at login [login]:~ > /home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg ~/pkgs/libconfuse0_* /usr/bin/env: No such file or directory From maciej at opencsw.org Thu Nov 24 19:21:36 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 24 Nov 2011 18:21:36 +0000 Subject: [csw-maintainers] freshening up Ganglia packages/need rrdtool In-Reply-To: <4ECE8996.4060202@opencsw.org> References: <4ECE747E.9060809@opencsw.org> <72B0271D-2C12-47DA-A6AF-77A1B55A5ECB@opencsw.org> <4ECE8267.6040900@opencsw.org> <4ECE8996.4060202@opencsw.org> Message-ID: 2011/11/24 Daniel Pocock : > Thanks for pointing this out - I tried this, but various errors on both > the build host and the login host - can you suggest what I'm doing wrong? You need to be on the login host, that's one thing. But there's one more problem - there isn't a password set up for you to give you releasing permissions. > -bash-3.00$ /home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg > ~/pkgs/libconfuse0_* > WARNING:root:This script is meant to be run on the login host. > WARNING:root:Error reading /etc/opt/csw/releases/auth/daniel: [Errno 2] > No such file or directory: '/etc/opt/csw/releases/auth/daniel' This bit over here indicates the problem I described above. I've set up the access for you - please try again. > daniel's pkg release password> > Processing 4 file(s). Please wait. > Traceback (most recent call last): > ?File "/home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg", line 608, > in > ? ?uploader.Upload() > ?File "/home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg", line 134, > in Upload > ? ?self._ImportMetadata(filename) > ?File "/home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg", line 101, > in _ImportMetadata > ? ?metadata = self._rest_client.GetPkgByMd5(md5_sum) > ?File "/home/daniel/opencsw/.buildsys/v2/lib/python/rest.py", line 29, > in GetPkgByMd5 > ? ?data = urllib2.urlopen(url).read() > ?File "/opt/csw/lib/python/urllib2.py", line 126, in urlopen > ? ?return _opener.open(url, data, timeout) > ?File "/opt/csw/lib/python/urllib2.py", line 391, in open > ? ?response = self._open(req, data) > ?File "/opt/csw/lib/python/urllib2.py", line 409, in _open > ? ?'_open', req) > ?File "/opt/csw/lib/python/urllib2.py", line 369, in _call_chain > ? ?result = func(*args) > ?File "/opt/csw/lib/python/urllib2.py", line 1170, in http_open > ? ?return self.do_open(httplib.HTTPConnection, req) > ?File "/opt/csw/lib/python/urllib2.py", line 1145, in do_open > ? ?raise URLError(err) > urllib2.URLError: This particular error is because the build hosts don't have the necessary network access. > -bash-3.00$ /home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg > ~/pkgs/libconfuse0_* > -bash-3.00$ logout > Connection to unstable10s closed. > daniel at login [login]:~ > > /home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg ~/pkgs/libconfuse0_* > /usr/bin/env: No such file or directory This error is interesting. Could you look up the first line of /home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg and see if corresponding interpreter exists in your $PATH? Maciej From dam at opencsw.org Thu Nov 24 21:53:06 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 24 Nov 2011 21:53:06 +0100 Subject: [csw-maintainers] freshening up Ganglia packages/need rrdtool In-Reply-To: <4ECE8793.10505@opencsw.org> References: <4ECE747E.9060809@opencsw.org> <72B0271D-2C12-47DA-A6AF-77A1B55A5ECB@opencsw.org> <4ECE8267.6040900@opencsw.org> <4ECE8793.10505@opencsw.org> Message-ID: <2DBCD6AD-A227-4F35-BD32-B3AA7AB98BCD@opencsw.org> Hi Daniel, Am 24.11.2011 um 19:06 schrieb Daniel Pocock: >>> I suggest rebuilding this also to the latest naming standard which would be >>> libconfuse0 and CSWlibconfuse0 together with CSWlibconfuse-dev and libconfuse_dev >>> and obsolete the old name. You can look at >>> http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/libssh2/trunk/Makefile >>> for an example. Please let me know if I can assist you in this matter. >>> >>> >> The example is not so clear, because libssh2 is downloading >> libssh2-1.3.0.tar.gz, while there is no libconfuse0-2.7.0.tar.gz to download >> >> Therefore, where do I use the real name, and in which variables do I use >> libconfuse0 with the 0? > > I played around with it a bit and ended up with these: > > The following packages have been built: > > CSWlibconfuse0-1 > /home/daniel/pkgs/libconfuse0_1-2.7,REV=2011.11.24-SunOS5.10-sparc-CSW.pkg.gz > CSWlibconfuse0-dev > /home/daniel/pkgs/libconfuse0_dev-2.7,REV=2011.11.24-SunOS5.10-sparc-CSW.pkg.gz > > Can you please check my Makefile and see if I'm doing it correctly? Done on devel@ > What is the next step to release? Would you be able to release them for > me (I'm 7 hours ahead of you now) so I can test in the morning? You need to csw-upload-pkg and wait until they hit unstable/, then you mail to buildfarm@ to install these. >>> After that I suggest you release libconfuse so I can install it and then proceed with ganglia. >>> Is this possible? >> >> Can you elaborate on `release'? I notice that /home/testing doesn't >> exist any more - what is the preferred way to release? The packages which you drop in /home/experimental/ will appear in buildfarm.opencsw.org/experimental.html# for manual installation. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From daniel at opencsw.org Fri Nov 25 04:41:09 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Fri, 25 Nov 2011 11:41:09 +0800 Subject: [csw-maintainers] freshening up Ganglia packages/need rrdtool In-Reply-To: References: <4ECE747E.9060809@opencsw.org> <72B0271D-2C12-47DA-A6AF-77A1B55A5ECB@opencsw.org> <4ECE8267.6040900@opencsw.org> <4ECE8996.4060202@opencsw.org> Message-ID: <4ECF0E55.3000706@opencsw.org> >> -bash-3.00$ /home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg >> ~/pkgs/libconfuse0_* >> -bash-3.00$ logout >> Connection to unstable10s closed. >> daniel at login [login]:~ > >> /home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg ~/pkgs/libconfuse0_* >> /usr/bin/env: No such file or directory >> > This error is interesting. Could you look up the first line of > /home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg and see if > corresponding interpreter exists in your $PATH? > /opt/csw/bin wasn't in my path - I notice that on some hosts, it is in the path, but on others it is not I now get a little further.... it appears that the upgrade tool doesn't like my new package CSWlibconfuse0 because it has files that conflict with CSWlibconfuse (which I am replacing). Should CSWlibconfuse be removed from the archive to solve this? Or should I just use some command line switch to force the package upload to proceed regardless? Also, should checkpkg realise that I included an OBSOLETED statement in the Makefile? OBSOLETED_BY_CSWlibconfuse0 += CSWlibconfuse daniel at login [login]:~/pkgs > /home/daniel/opencsw/.buildsys/v2/bin/checkpkg --catalog-release unstable --os-release SunOS5.10 --architecture sparc ffdf7017df0dbcf5c42febd4122a5a3a c5815f8e91000b37411827943fa0d287 INFO:root:Unwrapping candies... 100% |#########################################################################| INFO:root:Tasting candies one by one... 100% |#########################################################################| INFO:root:Tasting them all at once... INFO:root:Stuffing the candies under the pillow... WARNING:root:Not saving an error for CSWlibconfuse. | WARNING:root:Not saving an error for CSWlibconfuse. WARNING:root:Not saving an error for CSWlibconfuse. WARNING:root:Not saving an error for CSWlibconfuse. WARNING:root:Not saving an error for CSWlibconfuse. 100% |#########################################################################| CSWlibconfuse-dev: CSWlibconfuse: CSWlibconfuse0: If any of the reported errors were false positives, you can override them pasting the lines below to the GAR recipe. CHECKPKG_OVERRIDES_CSWlibconfuse-dev += file-collision|/opt/csw/include/confuse.h|CSWlibconfuse|CSWlibconfuse-dev CHECKPKG_OVERRIDES_CSWlibconfuse-dev += file-collision|/opt/csw/lib/pkgconfig/libconfuse.pc|CSWlibconfuse|CSWlibconfuse-dev CHECKPKG_OVERRIDES_CSWlibconfuse-dev += file-collision|/opt/csw/lib/libconfuse.so|CSWlibconfuse|CSWlibconfuse-dev CHECKPKG_OVERRIDES_CSWlibconfuse0 += file-collision|/opt/csw/lib/libconfuse.so.0.0.0|CSWlibconfuse|CSWlibconfuse0 CHECKPKG_OVERRIDES_CSWlibconfuse0 += file-collision|/opt/csw/lib/libconfuse.so.0|CSWlibconfuse|CSWlibconfuse0 Please note that checkpkg isn't suggesting you should simply add these overrides do the Makefile. It only informs what the overrides could look like. You need to understand what are the reported issues about and use your best judgement to decide whether to fix the underlying problems or override them. For more information, scroll up and read the detailed messages. From daniel at opencsw.org Fri Nov 25 05:40:48 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Fri, 25 Nov 2011 12:40:48 +0800 Subject: [csw-maintainers] error from csw-upload-pkg Message-ID: <4ECF1C50.9060200@opencsw.org> I'm trying to upload from /home/daniel/pkgs/ganglia*.gz This is my PATH /usr/bin:/usr/sbin:/sbin:/usr/ccs/bin:/usr/dt/bin:/usr/openwin/bin:/opt/bop/bin:/usr/sfw/bin:/usr/sfw/sbin:/opt/csw/bin (I've added /opt/csw/bin at the end to overcome the previous error I had) Can anyone comment on the errors below? daniel at login [login]:~/pkgs > /home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg gang* Processing 12 file(s). Please wait. Uploading 'ganglia_agent-3.1.7,REV=2011.11.25-SunOS5.10-i386-CSW.pkg.gz' WARNING:root:http://buildfarm.opencsw.org/pkgdb/rest/srv4/720d12418be4d29b9cc702b71cb82903/ -- HTTP Error 404: Not Found WARNING:root:ganglia_agent-3.1.7,REV=2011.11.25-SunOS5.10-sparc-CSW.pkg.gz (720d12418be4d29b9cc702b71cb82903) is not known to the database. INFO:root:Juicing the srv4 package stream files... Traceback (most recent call last): | File "/home/daniel/opencsw/.buildsys/v2/bin/pkgdb", line 684, in main() File "/home/daniel/opencsw/.buildsys/v2/bin/pkgdb", line 442, in main force_unpack=options.force_unpack) File "/home/daniel/opencsw/.buildsys/v2/lib/python/package_stats.py", line 494, in CollectStatsFromFiles stats.CollectStats(force=force_unpack) File "/home/daniel/opencsw/.buildsys/v2/lib/python/package_stats.py", line 170, in CollectStats return self._CollectStats(register_files=register_files) File "/home/daniel/opencsw/.buildsys/v2/lib/python/package_stats.py", line 207, in _CollectStats self.SaveStats(pkg_stats) File "/home/daniel/opencsw/.buildsys/v2/lib/python/package_stats.py", line 280, in SaveStats db_pkg_stats.DeleteAllDependentObjects() File "/home/daniel/opencsw/.buildsys/v2/lib/python/models.py", line 161, in DeleteAllDependentObjects self.RemoveAllCswFiles() File "/home/daniel/opencsw/.buildsys/v2/lib/python/models.py", line 172, in RemoveAllCswFiles CswFile.q.srv4_file==self))) File "/opt/csw/lib/python/site-packages/sqlobject/dbconnection.py", line 349, in query return self._runWithConnection(self._query, s) File "/opt/csw/lib/python/site-packages/sqlobject/dbconnection.py", line 262, in _runWithConnection val = meth(conn, *args) File "/opt/csw/lib/python/site-packages/sqlobject/dbconnection.py", line 346, in _query self._executeRetry(conn, conn.cursor(), s) File "/opt/csw/lib/python/site-packages/sqlobject/mysql/mysqlconnection.py", line 122, in _executeRetry raise OperationalError(ErrorMessage(e)) sqlobject.dberrors.OperationalError: DELETE command denied to user 'pkg_maintainer'@'192.168.1.2' for table 'csw_file' Traceback (most recent call last): File "/home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg", line 608, in uploader.Upload() File "/home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg", line 134, in Upload self._ImportMetadata(filename) File "/home/daniel/opencsw/.buildsys/v2/bin/csw-upload-pkg", line 118, in _ImportMetadata raise OSError("An error occurred when running %s." % args) OSError: An error occurred when running ['/home/daniel/opencsw/.buildsys/v2/bin/pkgdb', 'importpkg', 'ganglia_agent-3.1.7,REV=2011.11.25-SunOS5.10-sparc-CSW.pkg.gz']. From maciej at opencsw.org Fri Nov 25 09:24:49 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 25 Nov 2011 08:24:49 +0000 Subject: [csw-maintainers] freshening up Ganglia packages/need rrdtool In-Reply-To: <4ECF0E55.3000706@opencsw.org> References: <4ECE747E.9060809@opencsw.org> <72B0271D-2C12-47DA-A6AF-77A1B55A5ECB@opencsw.org> <4ECE8267.6040900@opencsw.org> <4ECE8996.4060202@opencsw.org> <4ECF0E55.3000706@opencsw.org> Message-ID: 2011/11/25 Daniel Pocock > > Also, should checkpkg realise that I included an OBSOLETED statement in > the Makefile? > > OBSOLETED_BY_CSWlibconfuse0 += CSWlibconfuse Checkpkg only looks at the contents of the actual package. The debugging path would be to pkgtrans the package files produced and see if there is in fact a file conflict. What command (mgar ) did you run after adding the OBSOLETED_BY_* line? Was the CSWlibconfuse package actually produced? What's the contents of that package? Maciej From dam at opencsw.org Fri Nov 25 09:30:41 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 25 Nov 2011 09:30:41 +0100 Subject: [csw-maintainers] freshening up Ganglia packages/need rrdtool In-Reply-To: References: <4ECE747E.9060809@opencsw.org> <72B0271D-2C12-47DA-A6AF-77A1B55A5ECB@opencsw.org> <4ECE8267.6040900@opencsw.org> <4ECE8996.4060202@opencsw.org> <4ECF0E55.3000706@opencsw.org> Message-ID: Hi, Am 25.11.2011 um 09:24 schrieb Maciej (Matchek) Blizi?ski: > 2011/11/25 Daniel Pocock >> >> Also, should checkpkg realise that I included an OBSOLETED statement in >> the Makefile? >> >> OBSOLETED_BY_CSWlibconfuse0 += CSWlibconfuse > > Checkpkg only looks at the contents of the actual package. The > debugging path would be to pkgtrans the package files produced and see > if there is in fact a file conflict. That means you must feed the obsoleted package in one go together with the other packages to csw-upload-pkg so checkpkg can check all of them at once. You can just mgar spotless mgar platforms and the packages should be fine for uploading. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Fri Nov 25 10:08:15 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 25 Nov 2011 09:08:15 +0000 Subject: [csw-maintainers] error from csw-upload-pkg In-Reply-To: <4ECF1C50.9060200@opencsw.org> References: <4ECF1C50.9060200@opencsw.org> Message-ID: 2011/11/25 Daniel Pocock : > This is my PATH > > /usr/bin:/usr/sbin:/sbin:/usr/ccs/bin:/usr/dt/bin:/usr/openwin/bin:/opt/bop/bin:/usr/sfw/bin:/usr/sfw/sbin:/opt/csw/bin /opt/csw/bin should be in front, unless you have a specific reason to do otherwise. > Can anyone comment on the errors below? My guess is that the packages did not go through the usual build / check / upload cycle. For example, there's "ENABLE_CHECK = 0" in the Makefile, or the packages weren't built with GAR (which always run checkpkg after building packages), or checkpkg wasn't run first for some reason. I'll look into improving the workflow. The csw-upload-pkg application currently is not able to distinguish between certain states of the package (metadata uploaded y/n, data uploaded y/n). It tries to reimport the metadata, but doesn't have sufficient privileges to do so. I'll look into improving at least the error reporting, and possibly the workflow itself. For now, try building a new set of packages (e.g. mgar platforms-repackage) using the standard workflow. Releasing them should work fine then. Maciej From daniel at opencsw.org Fri Nov 25 12:05:08 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Fri, 25 Nov 2011 19:05:08 +0800 Subject: [csw-maintainers] error from csw-upload-pkg In-Reply-To: References: <4ECF1C50.9060200@opencsw.org> Message-ID: <4ECF7664.7080407@opencsw.org> On 25/11/11 17:08, Maciej (Matchek) Blizi?ski wrote: > 2011/11/25 Daniel Pocock : > >> This is my PATH >> >> /usr/bin:/usr/sbin:/sbin:/usr/ccs/bin:/usr/dt/bin:/usr/openwin/bin:/opt/bop/bin:/usr/sfw/bin:/usr/sfw/sbin:/opt/csw/bin >> > /opt/csw/bin should be in front, unless you have a specific reason to > do otherwise. > > Ok, I'll set that in my profile from now on >> Can anyone comment on the errors below? >> > My guess is that the packages did not go through the usual build / > check / upload cycle. For example, there's "ENABLE_CHECK = 0" in the > Makefile, or the packages weren't built with GAR (which always run > checkpkg after building packages), or checkpkg wasn't run first for > some reason. > > I did have ENABLE_CHECK = 0 in ~/.garrc I've now removed that and I'm doing mgar clean && mgar package and I get a whole bunch of errors from the check - I'll look over them and see if I can fix them before running it again From skayser at opencsw.org Fri Nov 25 12:54:20 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 25 Nov 2011 12:54:20 +0100 Subject: [csw-maintainers] freshening up Ganglia packages/need rrdtool In-Reply-To: References: <4ECE747E.9060809@opencsw.org> <72B0271D-2C12-47DA-A6AF-77A1B55A5ECB@opencsw.org> <4ECE8267.6040900@opencsw.org> <4ECE8996.4060202@opencsw.org> <4ECF0E55.3000706@opencsw.org> Message-ID: <20111125115420.GE5803@sebastiankayser.de> * Maciej (Matchek) Blizi??ski wrote: > 2011/11/25 Daniel Pocock > > > > Also, should checkpkg realise that I included an OBSOLETED statement in > > the Makefile? > > > > OBSOLETED_BY_CSWlibconfuse0 += CSWlibconfuse > > Checkpkg only looks at the contents of the actual package. The > debugging path would be to pkgtrans the package files produced and see > if there is in fact a file conflict. For quick skimming, http://buildfarm.opencsw.org/pkgdb/srv4/ might also be an option I guess. Sebastian From daniel at opencsw.org Fri Nov 25 14:11:31 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Fri, 25 Nov 2011 21:11:31 +0800 Subject: [csw-maintainers] library package names and unusual SONAME Message-ID: <4ECF9403.4080900@opencsw.org> I'm uncertain about this output from checkpkg - I want to call the package CSWlibganglia0, and mgar has successfully built CSWlibganglia0, but checkpkg wants me to call it CSWlibganglia3-1-7-0 I realise that the SONAME in the library should be fixed by the upstream maintainer - however, to make a package of this version a) should I implement some hack in my Makefile to work around this? b) or should my Makefile patch the package contents to build a library with a different SONAME? Notice I already use CHECKPKG_OVERRIDES_CSWlibganglia0 += shared-lib-pkgname-mismatch|file=opt/csw/li b/libganglia-3.1.7.so.0.0.0|soname=libganglia-3.1.7.so.0|pkgname=CSWlibganglia0| expected=CSWlibganglia3-1-7-0 and that doesn't seem to make the message go away http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/ganglia/trunk/Makefile This is the message from checkpkg: # Checkpkg suggests adding the following lines to the GAR recipe: # This is a summary; see above for details. # The following lines define a new package: CSWlibganglia3-1-7-0 PACKAGES += CSWlibganglia3-1-7-0 CATALOGNAME_CSWlibganglia3-1-7-0 = libganglia3_1_7_0 PKGFILES_CSWlibganglia3-1-7-0 += $(call baseisadirs,$(libdir),libganglia-3\.1\.7\.so\.0\.0\.0) PKGFILES_CSWlibganglia3-1-7-0 += $(call baseisadirs,$(libdir),libganglia-3\.1\.7\.so\.0(\.\d+)*) SPKG_DESC_CSWlibganglia3-1-7-0 += $(DESCRIPTION), libganglia-3.1.7.so.0 RUNTIME_DEP_PKGS_CSWlibganglia0 += CSWlibganglia3-1-7-0 # The end of CSWlibganglia3-1-7-0 definition From dam at opencsw.org Fri Nov 25 14:21:07 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 25 Nov 2011 14:21:07 +0100 Subject: [csw-maintainers] glib2: finally some results In-Reply-To: <20111117111558.GB10611@bender.opencsw.org> References: <20111009172646.GA25605@bender.opencsw.org> <85555CAF-0F97-422A-88FA-D91663ED540C@opencsw.org> <20111014053800.GC15669@bender.opencsw.org> <86C49AB2-92F0-4311-9488-09219E18BBAB@opencsw.org> <20111117111558.GB10611@bender.opencsw.org> Message-ID: Hi Rafi, Am 17.11.2011 um 12:15 schrieb Rafael Ostertag: > On Thu, Oct 27, 2011 at 02:45:24PM +0200, Dagobert Michelsen wrote: >> Am 14.10.2011 um 07:38 schrieb Rafael Ostertag: >> I have compiled pygobject against glib2 and it looks pretty good. >> Did you have some progress on an updated gtk2 ? > > Sorry for the late response, I somehow managed to miss this mail completely. So > far I have no progress on gtk2, but if you think glib2 looks good, I guess > there is nothing refraining me from moving on to gtk2. Cool! Any timeframe for gtk? I would need the updated glib/gtk for libgegl, a requirement for the current gimp 2.7.3. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Fri Nov 25 15:34:23 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 25 Nov 2011 14:34:23 +0000 Subject: [csw-maintainers] library package names and unusual SONAME In-Reply-To: <4ECF9403.4080900@opencsw.org> References: <4ECF9403.4080900@opencsw.org> Message-ID: 2011/11/25 Daniel Pocock : > I'm uncertain about this output from checkpkg - I want to call the > package CSWlibganglia0, and mgar has successfully built CSWlibganglia0, > but checkpkg wants me to call it CSWlibganglia3-1-7-0 > > I realise that the SONAME in the library should be fixed by the upstream > maintainer - however, to make a package of this version > > a) should I implement some hack in my Makefile to work around this? > > b) or should my Makefile patch the package contents to build a library > with a different SONAME? Looking through ganglia source code, it looks like the shared library might be something intended only for ganglia-internal use, meaning that no packages other than ganglia's own package can link against it. If this is true, then there is no benefit in splitting out the shared library. Line 93 of: http://ganglia.svn.sourceforge.net/viewvc/ganglia/trunk/monitor-core/configure.in?revision=2638&view=markup Line 34 of: http://ganglia.svn.sourceforge.net/viewvc/ganglia/trunk/monitor-core/lib/Makefile.am?revision=2638&view=markup > Notice I already use > > CHECKPKG_OVERRIDES_CSWlibganglia0 += > shared-lib-pkgname-mismatch|file=opt/csw/li > b/libganglia-3.1.7.so.0.0.0|soname=libganglia-3.1.7.so.0|pkgname=CSWlibganglia0| > expected=CSWlibganglia3-1-7-0 If the soname is libganglia-3.1.7.so.0, and you're creating a separate package, the package name should be exactly CSWlibganglia3-1-7-0. The way linking works, if you build a package named libganglia0, and you put the library "libganglia-3.1.7.so.0" inside, what happens next? A third party links against libganglia-3.1.7.so.0, now libganglia-3.1.8.so.0 comes out, and you want to remove libganglia-3.1.7.so.0, but you can't, because of the third party program. Now you have to put two libraries, libganglia-3.1.7.so.0 and libganglia-3.1.8.so.0 inside libganglia0, and you're in the situation we're trying hard to get out of. libganglia-3.1.7.so.0 might be a stupid soname, but if the package name should still match it. The other option is that libganglia-3.1.7.so.0 is a private (to ganglia) library, and there's no need to split it out, because no third party binary can link to it. > and that doesn't seem to make the message go away > > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/ganglia/trunk/Makefile > > This is the message from checkpkg: > > # Checkpkg suggests adding the following lines to the GAR recipe: > # This is a summary; see above for details. > # The following lines define a new package: CSWlibganglia3-1-7-0 > PACKAGES += CSWlibganglia3-1-7-0 > CATALOGNAME_CSWlibganglia3-1-7-0 = libganglia3_1_7_0 > PKGFILES_CSWlibganglia3-1-7-0 += $(call > baseisadirs,$(libdir),libganglia-3\.1\.7\.so\.0\.0\.0) > PKGFILES_CSWlibganglia3-1-7-0 += $(call > baseisadirs,$(libdir),libganglia-3\.1\.7\.so\.0(\.\d+)*) > SPKG_DESC_CSWlibganglia3-1-7-0 += $(DESCRIPTION), libganglia-3.1.7.so.0 > RUNTIME_DEP_PKGS_CSWlibganglia0 += CSWlibganglia3-1-7-0 > # The end of CSWlibganglia3-1-7-0 definition This is a non-error message; this gets only printed to screen. Maciej From daniel at opencsw.org Fri Nov 25 16:08:40 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Fri, 25 Nov 2011 23:08:40 +0800 Subject: [csw-maintainers] library package names and unusual SONAME In-Reply-To: References: <4ECF9403.4080900@opencsw.org> Message-ID: <4ECFAF78.2030909@opencsw.org> On 25/11/11 22:34, Maciej (Matchek) Blizi?ski wrote: > 2011/11/25 Daniel Pocock : > >> I'm uncertain about this output from checkpkg - I want to call the >> package CSWlibganglia0, and mgar has successfully built CSWlibganglia0, >> but checkpkg wants me to call it CSWlibganglia3-1-7-0 >> >> I realise that the SONAME in the library should be fixed by the upstream >> maintainer - however, to make a package of this version >> >> a) should I implement some hack in my Makefile to work around this? >> >> b) or should my Makefile patch the package contents to build a library >> with a different SONAME? >> > Looking through ganglia source code, it looks like the shared library > might be something intended only for ganglia-internal use, meaning > that no packages other than ganglia's own package can link against it. > If this is true, then there is no benefit in splitting out the shared > library. > > Line 93 of: > http://ganglia.svn.sourceforge.net/viewvc/ganglia/trunk/monitor-core/configure.in?revision=2638&view=markup > > Line 34 of: > http://ganglia.svn.sourceforge.net/viewvc/ganglia/trunk/monitor-core/lib/Makefile.am?revision=2638&view=markup > > Having made several Ganglia releases upstream, I'm quite familiar with that code, and I don't think it's ideal - but there are various things related to configure that I never finished sorting out. Some of it is sitting on this branch: http://ganglia.svn.sourceforge.net/viewvc/ganglia/branches/d_pocock-monitor-core-configure/ I've also seen numerous other packages where the libraries have some less than conventional approach to SONAME and ABI numbers. Wearing my OpenCSW maintainer hat, I look at it like this: - the library is used by either of the packages gangliaagent or gangliagmetad - the user is not obliged to install both packages - they can just install one or the other - therefore, there is a good case for splitting it - if SONAME is going to start following a different convention in future, I want to try and start numbering from 0, and then CSWlibganglia1 will be the first version that follows the new standard when it is adopted although I'm quite happy to consider other approaches. >> Notice I already use >> >> CHECKPKG_OVERRIDES_CSWlibganglia0 += >> shared-lib-pkgname-mismatch|file=opt/csw/li >> b/libganglia-3.1.7.so.0.0.0|soname=libganglia-3.1.7.so.0|pkgname=CSWlibganglia0| >> expected=CSWlibganglia3-1-7-0 >> > If the soname is libganglia-3.1.7.so.0, and you're creating a separate > package, the package name should be exactly CSWlibganglia3-1-7-0. The > way linking works, if you build a package named libganglia0, and you > put the library "libganglia-3.1.7.so.0" inside, what happens next? A > third party links against libganglia-3.1.7.so.0, now > libganglia-3.1.8.so.0 comes out, and you want to remove > libganglia-3.1.7.so.0, but you can't, because of the third party > program. Now you have to put two libraries, libganglia-3.1.7.so.0 and > libganglia-3.1.8.so.0 inside libganglia0, and you're in the situation > we're trying hard to get out of. > > libganglia-3.1.7.so.0 might be a stupid soname, but if the package > name should still match it. > > The other option is that libganglia-3.1.7.so.0 is a private (to > ganglia) library, and there's no need to split it out, because no > third party binary can link to it. > > I wouldn't completely rule that out - the long term strategy for the library was to enable people to link it with applications that would send out metrics into the Ganglia platform. The current solution involves spawning the gmetric binary every time a new metric value is available, or writing a custom module within gmond (the opposite of having the Ganglia library within an app). >> and that doesn't seem to make the message go away >> >> http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/ganglia/trunk/Makefile >> >> This is the message from checkpkg: >> >> # Checkpkg suggests adding the following lines to the GAR recipe: >> # This is a summary; see above for details. >> # The following lines define a new package: CSWlibganglia3-1-7-0 >> PACKAGES += CSWlibganglia3-1-7-0 >> CATALOGNAME_CSWlibganglia3-1-7-0 = libganglia3_1_7_0 >> PKGFILES_CSWlibganglia3-1-7-0 += $(call >> baseisadirs,$(libdir),libganglia-3\.1\.7\.so\.0\.0\.0) >> PKGFILES_CSWlibganglia3-1-7-0 += $(call >> baseisadirs,$(libdir),libganglia-3\.1\.7\.so\.0(\.\d+)*) >> SPKG_DESC_CSWlibganglia3-1-7-0 += $(DESCRIPTION), libganglia-3.1.7.so.0 >> RUNTIME_DEP_PKGS_CSWlibganglia0 += CSWlibganglia3-1-7-0 >> # The end of CSWlibganglia3-1-7-0 definition >> > This is a non-error message; this gets only printed to screen. > Ok, thanks for clarifying that From daniel at opencsw.org Sat Nov 26 04:22:41 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Sat, 26 Nov 2011 11:22:41 +0800 Subject: [csw-maintainers] Ganglia for Solaris packages now in OpenCSW unstable Message-ID: <4ED05B81.2090107@opencsw.org> I've freshened up the Ganglia packages and pushed them into the unstable catalog - this should make the packaging compliant with the latest OpenCSW standards I'd appreciate any feedback that people have about these packages http://www.opencsw.org/packages/CSWgangliaagent/ (put it on the machines you want to monitor) http://www.opencsw.org/packages/CSWgangliaweb/ (put it on a server with Apache, to see the graphs) The gmond agent sends the metrics over multicast by default - as long as the machine with gangliaweb and gangliagmetad can receive the multicast packets, there is no manual configuration required, the packages should just work out of the box. From maciej at opencsw.org Sun Nov 27 16:26:04 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 27 Nov 2011 15:26:04 +0000 Subject: [csw-maintainers] [GAR] The 'submitpkg' target has been removed Message-ID: Hello maintainers, I've removed the 'submitpkg' target from GAR in r16311. This target was slightly confusing, as there was both a GAR target and an executable, both called 'submitpkg' and both doing different things. The executable is now gone, and the the time has come to remove the target as well. What 'mgar submitpkg' did, was tagging the current version in subversion. This is not really necessary; all packages built with GAR set a pkginfo property OPENCSW_REPOSITORY, which holds the path to the Makefile and the revision used to build the package. This allows to retrieve the exact revision which was used to build the specific package in question. If you type "mgar submitpkg", deprecation information will be printed to screen, and nothing else will happen. If you wish to inspect a specific revision of a specific Makefile, you can do that from the package website. The sequence of steps is: 1. Visit www.opencsw.org/packages// 2. Note that "Package Build Repository" looks like it's what you're looking for, but it's not -- it doesn't hold the revision information. 3. Click on "Go to QA page" 4. Click on "View in the buildfarm database" 5. CTRL+F, search for OPENCSW_REPOSITORY This is as of today; I suspect it will be made easier in the future. Maciej http://sourceforge.net/apps/trac/gar/changeset/16311 From skayser at opencsw.org Sun Nov 27 18:02:10 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 27 Nov 2011 18:02:10 +0100 Subject: [csw-maintainers] [GAR] The 'submitpkg' target has been removed In-Reply-To: References: Message-ID: <20111127170210.GK5803@sebastiankayser.de> * Maciej (Matchek) Blizi??ski wrote: > If you type "mgar submitpkg", deprecation information will be printed > to screen, and nothing else will happen. If you wish to inspect a > specific revision of a specific Makefile, you can do that from the > package website. The sequence of steps is: > > 1. Visit www.opencsw.org/packages// > 2. Note that "Package Build Repository" looks like it's what you're > looking for, but it's not -- it doesn't hold the revision information. > 3. Click on "Go to QA page" > 4. Click on "View in the buildfarm database" > 5. CTRL+F, search for OPENCSW_REPOSITORY > > This is as of today; I suspect it will be made easier in the future. As of now - welcome to the future ;) - step 1 is a tiny bit shorter to type. Similar to the recently added URL redirect for bugs.opencsw.org: http://opencsw.org/p/ http://opencsw.org/m/ Sebastian From igalic at opencsw.org Mon Nov 28 11:42:55 2011 From: igalic at opencsw.org (Igor =?utf-8?Q?Gali=C4=87?=) Date: Mon, 28 Nov 2011 10:42:55 -0000 (UTC) Subject: [csw-maintainers] Ganglia for Solaris packages now in OpenCSW unstable In-Reply-To: <4ED05B81.2090107@opencsw.org> Message-ID: <90b67bda-f494-432b-bfa9-86ffdca04b1b@iris> ----- Original Message ----- > > > > I've freshened up the Ganglia packages and pushed them into the > unstable > catalog - this should make the packaging compliant with the latest > OpenCSW standards > > I'd appreciate any feedback that people have about these packages > > http://www.opencsw.org/packages/CSWgangliaagent/ (put it on the > machines you want to monitor) > > http://www.opencsw.org/packages/CSWgangliaweb/ (put it on a server > with Apache, to see the graphs) > > The gmond agent sends the metrics over multicast by default - as long > as > the machine with gangliaweb and gangliagmetad can receive the > multicast > packets, there is no manual configuration required, the packages > should > just work out of the box. > Maybe send this to users@ as well? i From dam at opencsw.org Mon Nov 28 12:00:50 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 28 Nov 2011 12:00:50 +0100 Subject: [csw-maintainers] [csw-buildfarm] Fwd: OpenCSW catalog update report (ganglia) In-Reply-To: <4ED251FF.8000107@opencsw.org> References: <4ED05794.9040605@opencsw.org> <742E888E-D268-4EAB-942E-CE014C48A297@opencsw.org> <4ED2515E.1010103@opencsw.org> <4ED251FF.8000107@opencsw.org> Message-ID: Hi Daniel, we used to have ganglia_rt which you need to obsolete for proper updating: Index: Makefile =================================================================== --- Makefile (revision 16318) +++ Makefile (working copy) @@ -65,6 +65,9 @@ CHECKPKG_OVERRIDES_CSWgangliaweb += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWgangliaweb += surplus-dependency|CSWrrdtool +OBSOLETED_BY_CSWlibganglia0 += CSWgangliart +CATALOGNAME_CSWgangliart = ganglia_rt_stub + # We define upstream file regex so we can be notifed of new upstream software release UPSTREAM_MASTER_SITES = $(SF_PROJECT_SHOWFILE)=43021 UPSTREAM_USE_SF = 1 Am 27.11.2011 um 16:06 schrieb Daniel Pocock: > Just adding to my comments below - http://buildfarm.opencsw.org/ganglia > appears to be Ganglia 3.1.3, while my packages are 3.1.7, so it seems > highly likely to be a legacy install > > If you delete the old gmetad.conf, gmond.conf and httpd-ganglia.conf, > pkgrm 3.1.3 and pkgadd the new packages, it should work instantly using > multicast mode. I updated the packages on web but it doesn't look too good... Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From daniel at opencsw.org Mon Nov 28 12:06:59 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Mon, 28 Nov 2011 19:06:59 +0800 Subject: [csw-maintainers] [csw-buildfarm] Fwd: OpenCSW catalog update report (ganglia) In-Reply-To: References: <4ED05794.9040605@opencsw.org> <742E888E-D268-4EAB-942E-CE014C48A297@opencsw.org> <4ED2515E.1010103@opencsw.org> <4ED251FF.8000107@opencsw.org> Message-ID: <4ED36B53.7070006@opencsw.org> On 28/11/11 19:00, Dagobert Michelsen wrote: > Hi Daniel, > > we used to have ganglia_rt which you need to obsolete for proper updating: > Ok, thanks for that feedback > > I updated the packages on web but it doesn't look too good... > I notice your gmetad and apache appear to be running OK, but no nodes are visible You can try some of the following tests: 1. telnet to a machine running the node on port 8649 2. svcs | grep cswgmond You must have cswgmond running on the machine where the apache is running, or you won't get metrics from any node (the default gmetad polls the local gmond by default, it can actually be configured in other ways too) 3. be aware the this gmond version doesn't run on a non-global zone http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=100 Regards, Daniel From dam at opencsw.org Mon Nov 28 13:01:41 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 28 Nov 2011 13:01:41 +0100 Subject: [csw-maintainers] [csw-buildfarm] Fwd: OpenCSW catalog update report (ganglia) In-Reply-To: <4ED36B53.7070006@opencsw.org> References: <4ED05794.9040605@opencsw.org> <742E888E-D268-4EAB-942E-CE014C48A297@opencsw.org> <4ED2515E.1010103@opencsw.org> <4ED251FF.8000107@opencsw.org> <4ED36B53.7070006@opencsw.org> Message-ID: <72A5C75A-AEFF-40CE-A46C-C30600992B56@opencsw.org> Hi Daniel, Am 28.11.2011 um 12:06 schrieb Daniel Pocock: > I notice your gmetad and apache appear to be running OK, but no nodes > are visible > > You can try some of the following tests: > > 1. telnet to a machine running the node on port 8649 > > 2. svcs | grep cswgmond > > You must have cswgmond running on the machine where the apache is > running, or you won't get metrics from any node (the default gmetad > polls the local gmond by default, it can actually be configured in other > ways too) > > 3. be aware the this gmond version doesn't run on a non-global zone > > http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=100 If course the webserver runs in a non-global zone :-P Could you please apply Brians patch as cited in the patch report? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From daniel at opencsw.org Mon Nov 28 14:14:15 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Mon, 28 Nov 2011 21:14:15 +0800 Subject: [csw-maintainers] [csw-buildfarm] Fwd: OpenCSW catalog update report (ganglia) In-Reply-To: <72A5C75A-AEFF-40CE-A46C-C30600992B56@opencsw.org> References: <4ED05794.9040605@opencsw.org> <742E888E-D268-4EAB-942E-CE014C48A297@opencsw.org> <4ED2515E.1010103@opencsw.org> <4ED251FF.8000107@opencsw.org> <4ED36B53.7070006@opencsw.org> <72A5C75A-AEFF-40CE-A46C-C30600992B56@opencsw.org> Message-ID: <4ED38927.8070201@opencsw.org> >> 3. be aware the this gmond version doesn't run on a non-global zone >> >> http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=100 > > If course the webserver runs in a non-global zone :-P > Could you please apply Brians patch as cited in the patch report? > There are comments in the bug report suggesting the patch may cause gmond not to work in a global zone, so I'm not sure if the patch is ideal I'll have to find a quick way to test if running in a zone or not From dam at opencsw.org Mon Nov 28 14:22:26 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 28 Nov 2011 14:22:26 +0100 Subject: [csw-maintainers] [csw-buildfarm] Fwd: OpenCSW catalog update report (ganglia) In-Reply-To: <4ED38927.8070201@opencsw.org> References: <4ED05794.9040605@opencsw.org> <742E888E-D268-4EAB-942E-CE014C48A297@opencsw.org> <4ED2515E.1010103@opencsw.org> <4ED251FF.8000107@opencsw.org> <4ED36B53.7070006@opencsw.org> <72A5C75A-AEFF-40CE-A46C-C30600992B56@opencsw.org> <4ED38927.8070201@opencsw.org> Message-ID: <40921A50-28D4-4A5B-9002-DD9FDA9BEB6F@opencsw.org> Hi Daniel, Am 28.11.2011 um 14:14 schrieb Daniel Pocock: >>> 3. be aware the this gmond version doesn't run on a non-global zone >>> >>> http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=100 >> >> If course the webserver runs in a non-global zone :-P >> Could you please apply Brians patch as cited in the patch report? >> > > There are comments in the bug report suggesting the patch may cause > gmond not to work in a global zone, so I'm not sure if the patch is ideal > > I'll have to find a quick way to test if running in a zone or not Comment #19 reads ok for me: "Just meet this issue in a Solaris zone. I compiled a small test with Brian's fix. And I found it works great, both in a non-global zone and global zone." Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From daniel at opencsw.org Mon Nov 28 15:14:04 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Mon, 28 Nov 2011 22:14:04 +0800 Subject: [csw-maintainers] Ganglia using rrdcached by default? Message-ID: <4ED3972C.9090300@opencsw.org> rrdcached makes the Ganglia graphs appear much more quickly, and reduces IO load on the reporting server. It is present in the rrdtool packages, but no init script is supplied. Various issues come to mind: a) should the ganglia packages use rrdcached by default? b) how to start rrdcached? Should rrdtool supply an init script? Or should it be done from the gangliagmetad init script? c) Can initsmf declare the dependency (gmetad depends on rrdcached if configured in this way)? Or would this over-complicate the relationship between the gangliagmetad and rrdtool packages? From daniel at opencsw.org Mon Nov 28 15:43:39 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Mon, 28 Nov 2011 22:43:39 +0800 Subject: [csw-maintainers] [csw-buildfarm] Fwd: OpenCSW catalog update report (ganglia) In-Reply-To: <40921A50-28D4-4A5B-9002-DD9FDA9BEB6F@opencsw.org> References: <4ED05794.9040605@opencsw.org> <742E888E-D268-4EAB-942E-CE014C48A297@opencsw.org> <4ED2515E.1010103@opencsw.org> <4ED251FF.8000107@opencsw.org> <4ED36B53.7070006@opencsw.org> <72A5C75A-AEFF-40CE-A46C-C30600992B56@opencsw.org> <4ED38927.8070201@opencsw.org> <40921A50-28D4-4A5B-9002-DD9FDA9BEB6F@opencsw.org> Message-ID: <4ED39E1B.7050808@opencsw.org> On 28/11/11 21:22, Dagobert Michelsen wrote: > Hi Daniel, > > Am 28.11.2011 um 14:14 schrieb Daniel Pocock: >>>> 3. be aware the this gmond version doesn't run on a non-global zone >>>> >>>> http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=100 >>> >>> If course the webserver runs in a non-global zone :-P >>> Could you please apply Brians patch as cited in the patch report? >>> >> >> There are comments in the bug report suggesting the patch may cause >> gmond not to work in a global zone, so I'm not sure if the patch is ideal >> >> I'll have to find a quick way to test if running in a zone or not > > Comment #19 reads ok for me: > > "Just meet this issue in a Solaris zone. I compiled a small test with Brian's > fix. And I found it works great, both in a non-global zone and global zone." http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=100#c3 'The problem with the "simple" solution is that it breaks normal (non-zone) setups. e.g. the following is from a Solaris-10 HA configuration:......' sounds a bit ominous to me. At the very least, Ganglia 3.1 series might be able to just refuse to run in a zone, display a more meaningful error than `ioctl failed' or just disable this code in a zone or some other `safe' hack, and then comprehensive zone support can be introduced through trunk I don't know enough about zones, HA setups and other permutations to say the ideal way to address the issue However, another issue that does come to mind: if someone runs gmond in a zone, is it meaningful to report all of the CPU stats for every zone? Or is the CPU inside a zone not really measurable in the same way as a physical CPU in the global zone? From bonivart at opencsw.org Mon Nov 28 16:00:08 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 28 Nov 2011 16:00:08 +0100 Subject: [csw-maintainers] Ganglia using rrdcached by default? In-Reply-To: <4ED3972C.9090300@opencsw.org> References: <4ED3972C.9090300@opencsw.org> Message-ID: On Mon, Nov 28, 2011 at 3:14 PM, Daniel Pocock wrote: > b) how to start rrdcached? ?Should rrdtool supply an init script? ?Or > should it be done from the gangliagmetad init script? If it's generic I think it should be in rrdtool. Only in ganglia if it's very specific to ganglia. I provide a Sendmail script in MailScanner because it totally changes how Sendmail is configured/started. > c) Can initsmf declare the dependency (gmetad depends on rrdcached if > configured in this way)? You can provide a custom manifest that cswinitsmf can use (instead of the autogenerated one). You declare it by using magic comments in the init script, see here: http://wiki.opencsw.org/cswclassutils-package#toc9 From gadavis at opencsw.org Tue Nov 29 01:15:04 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Mon, 28 Nov 2011 16:15:04 -0800 Subject: [csw-maintainers] dovecot, conf.d directories, and SAMPLECONF In-Reply-To: <4ED41D78.2040506@opencsw.org> References: <4ECA9515.4040503@opencsw.org> <4ECA96F9.4080307@opencsw.org> <4ED41D78.2040506@opencsw.org> Message-ID: <4ED42408.2080609@opencsw.org> On 11/28/11 3:47 PM, Jake Goerzen wrote: > (bits of original message snipped) > I wanted to ask, do you know anything about the "conf.d" directory in > example-config? In the dovecot 2.0 documentation "quick > configuration" it says to copy dovecot.conf and conf.d from the > example-config directory. Should I handle this conf.d directory as a > SAMPLECONF? or just the single dovecot.conf file as previously done? > If you understand Dovecot's configuration file format well enough, my advice would be to throw together a very minimal sample configuration file that is self-contained in a single file and that doesn't use conf.d. This is a tough call. I started to update the FreeRADIUS packages and ran into a similar decision point. The FreeRADIUS sample config is pretty ridiculous - something like 30 files in all, with some submodules using a conf.d structure, and others using a modules-enabled modules-available structure. I just threw up my hands and let the user figure it out and set the daemon to not auto-start because SAMPLECONF was falling down trying to manage the whole mess, and I didn't know enough about FreeRADIUS to put together a minimalist configuration file. (Then I got distracted by $DAYJOB obligations and gave up on it altogether.) I don't think SAMPLECONF is very well suited to conf.d structures because a user might want to just remove all of the sample configuration and have their own set of files in that directory. As far as I know, SAMPLECONF doesn't handle that case well at all during a package upgrade and puts whole new copies of the files in place, which is not what the user typically wants. Geoff CC: maintainers because there may be a MEGA_SAMPLECONF or something that I don't know about that handles conf.d setups better. From daniel at opencsw.org Tue Nov 29 06:08:47 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Tue, 29 Nov 2011 13:08:47 +0800 Subject: [csw-maintainers] [csw-buildfarm] Fwd: OpenCSW catalog update report (ganglia) In-Reply-To: <4ED39E1B.7050808@opencsw.org> References: <4ED05794.9040605@opencsw.org> <742E888E-D268-4EAB-942E-CE014C48A297@opencsw.org> <4ED2515E.1010103@opencsw.org> <4ED251FF.8000107@opencsw.org> <4ED36B53.7070006@opencsw.org> <72A5C75A-AEFF-40CE-A46C-C30600992B56@opencsw.org> <4ED38927.8070201@opencsw.org> <40921A50-28D4-4A5B-9002-DD9FDA9BEB6F@opencsw.org> <4ED39E1B.7050808@opencsw.org> Message-ID: <4ED468DF.6040701@opencsw.org> On 28/11/11 22:43, Daniel Pocock wrote: > On 28/11/11 21:22, Dagobert Michelsen wrote: >> Hi Daniel, >> >> Am 28.11.2011 um 14:14 schrieb Daniel Pocock: >>>>> 3. be aware the this gmond version doesn't run on a non-global zone >>>>> >>>>> http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=100 >>>> >>>> If course the webserver runs in a non-global zone :-P >>>> Could you please apply Brians patch as cited in the patch report? >>>> >>> >>> There are comments in the bug report suggesting the patch may cause >>> gmond not to work in a global zone, so I'm not sure if the patch is ideal >>> >>> I'll have to find a quick way to test if running in a zone or not >> >> Comment #19 reads ok for me: >> >> "Just meet this issue in a Solaris zone. I compiled a small test with Brian's >> fix. And I found it works great, both in a non-global zone and global zone." > > http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=100#c3 > > 'The problem with the "simple" solution is that it breaks normal > (non-zone) > setups. > > e.g. the following is from a Solaris-10 HA configuration:......' > > > sounds a bit ominous to me. > > At the very least, Ganglia 3.1 series might be able to just refuse to > run in a zone, display a more meaningful error than `ioctl failed' or > just disable this code in a zone or some other `safe' hack, and then > comprehensive zone support can be introduced through trunk > > I don't know enough about zones, HA setups and other permutations to say > the ideal way to address the issue > > However, another issue that does come to mind: if someone runs gmond in > a zone, is it meaningful to report all of the CPU stats for every zone? > Or is the CPU inside a zone not really measurable in the same way as a > physical CPU in the global zone? > Another thought: - has anyone tried the Host sFlow agent on Solaris (and in a zone)? http://host-sflow.sourceforge.net/ - if I update my package for Ganglia 3.2 and build a package of Host sFlow agent, then that may provide an alternative solution, as the Host sFlow agent may not face the zone problem, and users can still use Ganglia's web interface as the reporting tool: http://blog.sflow.com/2011/07/ganglia-32-released.html From dam at opencsw.org Tue Nov 29 09:27:24 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 29 Nov 2011 09:27:24 +0100 Subject: [csw-maintainers] [csw-buildfarm] Fwd: OpenCSW catalog update report (ganglia) In-Reply-To: <4ED468DF.6040701@opencsw.org> References: <4ED05794.9040605@opencsw.org> <742E888E-D268-4EAB-942E-CE014C48A297@opencsw.org> <4ED2515E.1010103@opencsw.org> <4ED251FF.8000107@opencsw.org> <4ED36B53.7070006@opencsw.org> <72A5C75A-AEFF-40CE-A46C-C30600992B56@opencsw.org> <4ED38927.8070201@opencsw.org> <40921A50-28D4-4A5B-9002-DD9FDA9BEB6F@opencsw.org> <4ED39E1B.7050808@opencsw.org> <4ED468DF.6040701@opencsw.org> Message-ID: Hi Daniel, Am 29.11.2011 um 06:08 schrieb Daniel Pocock: > On 28/11/11 22:43, Daniel Pocock wrote: >> On 28/11/11 21:22, Dagobert Michelsen wrote: >>> Am 28.11.2011 um 14:14 schrieb Daniel Pocock: >>>>>> 3. be aware the this gmond version doesn't run on a non-global zone >>>>>> >>>>>> http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=100 >>>>> >>>>> If course the webserver runs in a non-global zone :-P >>>>> Could you please apply Brians patch as cited in the patch report? >>>>> >>>> >>>> There are comments in the bug report suggesting the patch may cause >>>> gmond not to work in a global zone, so I'm not sure if the patch is ideal >>>> >>>> I'll have to find a quick way to test if running in a zone or not >>> >>> Comment #19 reads ok for me: >>> >>> "Just meet this issue in a Solaris zone. I compiled a small test with Brian's >>> fix. And I found it works great, both in a non-global zone and global zone." >> >> http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=100#c3 >> >> 'The problem with the "simple" solution is that it breaks normal >> (non-zone) >> setups. >> >> e.g. the following is from a Solaris-10 HA configuration:......' >> >> sounds a bit ominous to me. But http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=100#c19 sounds promising. Do you have upstream contacts who can aid in finally fixing this? >> At the very least, Ganglia 3.1 series might be able to just refuse to >> run in a zone, display a more meaningful error than `ioctl failed' or >> just disable this code in a zone or some other `safe' hack, and then >> comprehensive zone support can be introduced through trunk >> >> I don't know enough about zones, HA setups and other permutations to say >> the ideal way to address the issue >> >> However, another issue that does come to mind: if someone runs gmond in >> a zone, is it meaningful to report all of the CPU stats for every zone? >> Or is the CPU inside a zone not really measurable in the same way as a >> physical CPU in the global zone? It is measurable, but by default you would also get some of the performance data from the global zone (like system load). > Another thought: > > - has anyone tried the Host sFlow agent on Solaris (and in a zone)? > http://host-sflow.sourceforge.net/ Solaris doesn't seem to be on the list of supported operating systems. Have you tried compiling it? > - if I update my package for Ganglia 3.2 and build a package of Host > sFlow agent, then that may provide an alternative solution, as the Host > sFlow agent may not face the zone problem, and users can still use > Ganglia's web interface as the reporting tool: > http://blog.sflow.com/2011/07/ganglia-32-released.html sflow support in ganglia would certainly be a good thing. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Tue Nov 29 09:59:15 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 29 Nov 2011 09:59:15 +0100 Subject: [csw-maintainers] Ganglia using rrdcached by default? In-Reply-To: <4ED3972C.9090300@opencsw.org> References: <4ED3972C.9090300@opencsw.org> Message-ID: Hi Daniel, Am 28.11.2011 um 15:14 schrieb Daniel Pocock: > rrdcached makes the Ganglia graphs appear much more quickly, and reduces > IO load on the reporting server. It is present in the rrdtool packages, > but no init script is supplied. > > Various issues come to mind: > > a) should the ganglia packages use rrdcached by default? I would say no. > b) how to start rrdcached? Should rrdtool supply an init script? Or > should it be done from the gangliagmetad init script? If at all it should be in rrdtool. If you have one I would be glad to add this to rrdtool. > c) Can initsmf declare the dependency (gmetad depends on rrdcached if > configured in this way)? As Peter said you can do this with a custom manifest, but I don't think this is a good idea in general. An experienced user can easily set this up himself IMHO. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Tue Nov 29 10:04:03 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 29 Nov 2011 09:04:03 +0000 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: References: Message-ID: 2011/11/11 Peter FELECAN : > The solution resides in the answer to the question: can a 32 bit > compiler generate 64 bit code? In my opinion, the answer is yes and it > can be considered as cross-compilation in a very lazy definition. Note > that I didn't researched how to do this in the Ada compiler context... It seems to me that if not cross compilation, then something akin is necessary to build gcc with x86_64 targets for gnat. A note to everyone: In the meantime: I'm stuck at compiling gcc+gnat on Solaris 10 x86. Here's how it fails: http://buildfarm.opencsw.org/~maciej/gnat-i386-5.10-full.log.bz2 My calendar is full for the next few weeks, so don't hold your breath on gcc+gnat, and the unstable?dublin integration. If you are interested in getting it quicker, your direct help is necessary. Maciej From daniel at opencsw.org Tue Nov 29 13:05:48 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Tue, 29 Nov 2011 20:05:48 +0800 Subject: [csw-maintainers] Ganglia packages for 3.2.0 available Message-ID: <4ED4CA9C.1030803@opencsw.org> Unstable still has the latest 3.1.7 packages that I built recently Experimental now has the 3.2.0 packages I've verified the gmond, gmetad and web packages on a Solaris 10 x86 box. Once I've had some feedback, I'll consider moving them from experimental to unstable. (libconfuse 2.7 is also available in unstable) Details and installation instructions: http://buildfarm.opencsw.org/experimental.html#ganglia From dam at opencsw.org Tue Nov 29 13:53:50 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 29 Nov 2011 13:53:50 +0100 Subject: [csw-maintainers] Ganglia packages for 3.2.0 available In-Reply-To: <4ED4CA9C.1030803@opencsw.org> References: <4ED4CA9C.1030803@opencsw.org> Message-ID: <75C148D4-F8E0-4E2B-B91A-18201167B9F5@opencsw.org> Hi Daniel, Am 29.11.2011 um 13:05 schrieb Daniel Pocock: > Unstable still has the latest 3.1.7 packages that I built recently > > Experimental now has the 3.2.0 packages > > I've verified the gmond, gmetad and web packages on a Solaris 10 x86 > box. Once I've had some feedback, I'll consider moving them from > experimental to unstable. > > (libconfuse 2.7 is also available in unstable) > > Details and installation instructions: > > http://buildfarm.opencsw.org/experimental.html#ganglia I suggest adjusting the package name to latest standards, which is separating words with "-" and making catalog name identical to the package name (without CSW and s/-/_/), e.g. CSWgangliaweb -> CSWganglia-web. For the old packages you may need to obsolete the old ones and manually adjust the package names. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From daniel at opencsw.org Wed Nov 30 09:37:51 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 30 Nov 2011 16:37:51 +0800 Subject: [csw-maintainers] [csw-buildfarm] Fwd: OpenCSW catalog update report (ganglia) In-Reply-To: References: <4ED05794.9040605@opencsw.org> <742E888E-D268-4EAB-942E-CE014C48A297@opencsw.org> <4ED2515E.1010103@opencsw.org> <4ED251FF.8000107@opencsw.org> <4ED36B53.7070006@opencsw.org> <72A5C75A-AEFF-40CE-A46C-C30600992B56@opencsw.org> <4ED38927.8070201@opencsw.org> <40921A50-28D4-4A5B-9002-DD9FDA9BEB6F@opencsw.org> <4ED39E1B.7050808@opencsw.org> <4ED468DF.6040701@opencsw.org> Message-ID: <4ED5EB5F.5010803@opencsw.org> On 29/11/11 16:27, Dagobert Michelsen wrote: > Hi Daniel, > > Am 29.11.2011 um 06:08 schrieb Daniel Pocock: >> On 28/11/11 22:43, Daniel Pocock wrote: >>> On 28/11/11 21:22, Dagobert Michelsen wrote: >>>> Am 28.11.2011 um 14:14 schrieb Daniel Pocock: >>>>>>> 3. be aware the this gmond version doesn't run on a non-global zone >>>>>>> >>>>>>> http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=100 >>>>>> >>>>>> If course the webserver runs in a non-global zone :-P >>>>>> Could you please apply Brians patch as cited in the patch report? >>>>>> >>>>> >>>>> There are comments in the bug report suggesting the patch may cause >>>>> gmond not to work in a global zone, so I'm not sure if the patch is ideal >>>>> >>>>> I'll have to find a quick way to test if running in a zone or not >>>> >>>> Comment #19 reads ok for me: >>>> >>>> "Just meet this issue in a Solaris zone. I compiled a small test with Brian's >>>> fix. And I found it works great, both in a non-global zone and global zone." >>> >>> http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=100#c3 >>> >>> 'The problem with the "simple" solution is that it breaks normal >>> (non-zone) >>> setups. >>> >>> e.g. the following is from a Solaris-10 HA configuration:......' >>> >>> sounds a bit ominous to me. > > But http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=100#c19 sounds promising. > Do you have upstream contacts who can aid in finally fixing this? Most of the emphasis on the mailing list is on the various Linux distributions It is definitely something I can fix if necessary, but I would have to allocate some time to study the real requirements for both zone support and the way Ganglia deals with network interface metrics. > >>> At the very least, Ganglia 3.1 series might be able to just refuse to >>> run in a zone, display a more meaningful error than `ioctl failed' or >>> just disable this code in a zone or some other `safe' hack, and then >>> comprehensive zone support can be introduced through trunk >>> >>> I don't know enough about zones, HA setups and other permutations to say >>> the ideal way to address the issue >>> >>> However, another issue that does come to mind: if someone runs gmond in >>> a zone, is it meaningful to report all of the CPU stats for every zone? >>> Or is the CPU inside a zone not really measurable in the same way as a >>> physical CPU in the global zone? > > It is measurable, but by default you would also get some of the performance data > from the global zone (like system load). That's what I suspected, given that each metric RRD file takes up some disk space, a good implementation of Ganglia for zones should not send metrics that are not meaningful (e.g. those load/CPU related metrics that should be measured on the global zone) >> Another thought: >> >> - has anyone tried the Host sFlow agent on Solaris (and in a zone)? >> http://host-sflow.sourceforge.net/ > > Solaris doesn't seem to be on the list of supported operating systems. Have > you tried compiling it? > Just had a brief look at it today - the tarball contains a Linux directory and a Windows directory. Looking in SVN/trunk, it doesn't look like they have started on Solaris support yet. A Solaris port would probably involve working through the Linux files and adapting them to read kstat, e.g: http://host-sflow.svn.sourceforge.net/viewvc/host-sflow/trunk/src/Linux/readCpuCounters.c?revision=238&view=markup >> - if I update my package for Ganglia 3.2 and build a package of Host >> sFlow agent, then that may provide an alternative solution, as the Host >> sFlow agent may not face the zone problem, and users can still use >> Ganglia's web interface as the reporting tool: >> http://blog.sflow.com/2011/07/ganglia-32-released.html > > sflow support in ganglia would certainly be a good thing. > Ok, the package is there in experimental now - I'd be interested to know if anyone has some sFlow agent they can test with it? From rupert at opencsw.org Wed Nov 30 20:53:38 2011 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 30 Nov 2011 20:53:38 +0100 Subject: [csw-maintainers] subvertpy compile fails on unstable9x In-Reply-To: References: Message-ID: hi, while it goes through on unstable9s, subvertpy compile fails on unstable9x with: /opt/SUNWspro/bin/cc -DNDEBUG -O -xO3 -m32 -xarch=386 -I/opt/csw/include -Kpic -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include/subversion-1 -Isubvertpy -I/opt/csw/include/python2.6 -c subvertpy/client.c -o build/temp.solaris-2.9-i86pc-2.6/subvertpy/client.o ... "subvertpy/client.c", line 22: cannot find include file: "subvertpy/client.c", line 23: cannot find include file: "subvertpy/client.c", line 24: cannot find include file: "subvertpy/client.c", line 25: cannot find include file: "subvertpy/util.h", line 23: cannot find include file: "subvertpy/util.h", line 26: #error: "only svn 1.x is supported" what could be the difference between the two? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Wed Nov 30 20:57:43 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 30 Nov 2011 14:57:43 -0500 Subject: [csw-maintainers] subvertpy compile fails on unstable9x In-Reply-To: References: Message-ID: <1322682941-sup-6095@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Wed Nov 30 14:53:38 -0500 2011: Hi Rupert, > what could be the difference between the two? > I'm adding CSWsvn-devel to 9x now. It wasn't installed for whatever reason. (That should be -dev the next time you update if you get the chance. If you need a hand with the renaming, let me know.) Thanks -Benk -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302