From igalic at opencsw.org  Sat Dec  1 11:22:21 2012
From: igalic at opencsw.org (Igor =?utf-8?Q?Gali=C4=87?=)
Date: Sat, 1 Dec 2012 10:22:21 +0000 (UTC)
Subject: [csw-maintainers] Garbage collecting the package database
In-Reply-To: <CALtRa-5kmJ8=imEXxYiwkKvgjPOZca8k=QVSzWPHtCks41qjug@mail.gmail.com>
References: <CALtRa-5kmJ8=imEXxYiwkKvgjPOZca8k=QVSzWPHtCks41qjug@mail.gmail.com>
Message-ID: <1201497339.432794.1354357341932.JavaMail.root@brainsware.org>

\o/

----- Original Message -----
> The package database stores metadata about every package ever
> analyzed
> with checkpkg. Only a small fraction of built and checked packages
> make it into catalogs, which means that there is a boatload of
> packages which are in the database, but aren't used.
> 
> I wrote a script to find and delete unused packages:
> http://sourceforge.net/apps/trac/gar/changeset/19788
> 
> There were about 80k packages (defined as SVR4 .pkg files), of which
> only 16.5k are actually used in catalogs (since the stable and
> current
> catalogs are now dropped from the database). Before garbage
> collection, the compressed database dump had 815MB, and now it has
> 150MB. I'm guessing that the size reduction will also have
> performance
> benefits.
> 
> Maciej
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
> 

From dam at opencsw.org  Sat Dec  1 22:10:18 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sat, 1 Dec 2012 22:10:18 +0100
Subject: [csw-maintainers] TeXLive packaging take almost 3 days
In-Reply-To: <x6k3t42j1y.fsf@opencsw.org>
References: <45c2f3ff0a268dff9e15d23967f71026.squirrel@mail.opencsw.org>
	<D8DD1B8F-78E8-4785-8211-F0521C572EDF@opencsw.org>
	<x6a9ud4h7f.fsf@opencsw.org>
	<DA4F0B5F-D78F-4FFE-8C4B-EEF153004E77@opencsw.org>
	<x6k3t42j1y.fsf@opencsw.org>
Message-ID: <4575CBFC-93C8-4759-B12A-BF96A63E2378@opencsw.org>

Hi Peter,

Am 29.11.2012 um 22:30 schrieb Peter FELECAN <pfelecan at opencsw.org>:
> I confirm a 50 times optimization for pathfilter.
> 
> As for cswproto, still a hog, here is some additional profiling data:
> 
> Total Elapsed Time = 1184.726 Seconds
>  User+System Time = 1060.576 Seconds
> Exclusive Times
> %Time ExclSec CumulS #Calls sec/call Csec/c  Name
> 98.1   1040. 1040.6 112180   0.0093 0.0093  main::is_common
> 0.09   0.980  0.980 112164   0.0000 0.0000  main::exclude
> 0.01   0.069  0.236      7   0.0099 0.0337  main::BEGIN
> 
> As you can see the time is spent is determining if the components are
> part of the common package. I understood that in the future we get rid
> of that but in the mean time we need to find a quicker way to determine
> that relation. With the current optimization we probably can package
> TeXLive in 1.5 days which is still too much...


Indeed? That was not what I had expected by looking at the code as I would have guessed
it takes most of the time for during mkproto. I did some optimization on the regex-part,
it should now be a lot faster:
  http://sourceforge.net/apps/trac/gar/changeset/19800

Please let me know if you encounter any other performance issues.


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  Sat Dec  1 22:28:10 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sat, 1 Dec 2012 22:28:10 +0100
Subject: [csw-maintainers] Document package naming
Message-ID: <C09E288D-E6EA-4E39-91E5-20F799A802D2@opencsw.org>

Hi folks,

I was just talking with jatan on IRC about package naming policies and noted that
it is not documented. It should be IMHO in the manual. If anybody has time to add
the respective standards to the manual be invited to do so:
  mgar/pkg/opencsw-manual/trunk/files/for-maintainers/
I also put it on my todo list, but I am a bit overworked lately?


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  Sun Dec  2 14:44:06 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 2 Dec 2012 13:44:06 +0000
Subject: [csw-maintainers] Document package naming
In-Reply-To: <C09E288D-E6EA-4E39-91E5-20F799A802D2@opencsw.org>
References: <C09E288D-E6EA-4E39-91E5-20F799A802D2@opencsw.org>
Message-ID: <CALtRa-62AA+NdetyQCzAm-H=ZOH8L2iR0buyKwwmQ13iaExfNA@mail.gmail.com>

I quickly added a couple of paragraphs.

http://sourceforge.net/apps/trac/gar/changeset/19801

Does it cover what you intended?

From dam at opencsw.org  Sun Dec  2 18:57:56 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 2 Dec 2012 18:57:56 +0100
Subject: [csw-maintainers] Document package naming
In-Reply-To: <CALtRa-62AA+NdetyQCzAm-H=ZOH8L2iR0buyKwwmQ13iaExfNA@mail.gmail.com>
References: <C09E288D-E6EA-4E39-91E5-20F799A802D2@opencsw.org>
	<CALtRa-62AA+NdetyQCzAm-H=ZOH8L2iR0buyKwwmQ13iaExfNA@mail.gmail.com>
Message-ID: <83E032CE-4F8B-4C0A-84DA-E4C440C09A3A@opencsw.org>

Hi Maciej,

Am 02.12.2012 um 14:44 schrieb Maciej (Matchek) Blizi?ski:
> I quickly added a couple of paragraphs.
> 
> http://sourceforge.net/apps/trac/gar/changeset/19801
> 
> Does it cover what you intended?

Exactly. Thanks!!


Best regards

  -- Dago


From maciej at opencsw.org  Mon Dec  3 15:03:41 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Mon, 3 Dec 2012 14:03:41 +0000
Subject: [csw-maintainers] GCC 4.7 release
Message-ID: <CALtRa-5+71kKoXN5FeCHmMQVWkcs4oK8mhjBh03643Uxe679-w@mail.gmail.com>

I've got the new GCC built (some moons ago), but I can't release it,
because people complain they can't run it on older Solaris 10
releases. Yet they can't use the 4.6 version in dublin, they need the
4.7 version from unstable.

I want to find a way out.

There's a larger issue, what do we do with the kiel release. Do we
keep it compatible with pre-U10 (or pre-U9?) releases? If we do, how
do we do it? Yann spent a lot of time preparing maps, and I think
there are still problems. Some ways to proceed I can think of:

1. Set U10 (or U9?) as a requirement to run kiel, force users to bite
the bullet and upgrade.
2. Freeze kiel (but how do we release security fixes? Dago told me
it's hard to simultaneously have different Solaris 10 releases on the
buildfarm)
3. Fix whatever problems there are with function version maps.

We could also ask users what they think about it.

Your thoughts?

Maciej

From jh at opencsw.org  Mon Dec  3 15:37:59 2012
From: jh at opencsw.org (Jan Holzhueter)
Date: Mon, 03 Dec 2012 15:37:59 +0100
Subject: [csw-maintainers] GCC 4.7 release
In-Reply-To: <CALtRa-5+71kKoXN5FeCHmMQVWkcs4oK8mhjBh03643Uxe679-w@mail.gmail.com>
References: <CALtRa-5+71kKoXN5FeCHmMQVWkcs4oK8mhjBh03643Uxe679-w@mail.gmail.com>
Message-ID: <50BCB947.60806@opencsw.org>

Hi,

Am 03.12.12 15:03, schrieb Maciej (Matchek) Blizi?ski:
> I've got the new GCC built (some moons ago), but I can't release it,
> because people complain they can't run it on older Solaris 10
> releases. Yet they can't use the 4.6 version in dublin, they need the
> 4.7 version from unstable.
> 
> I want to find a way out.
> 
> There's a larger issue, what do we do with the kiel release. Do we
> keep it compatible with pre-U10 (or pre-U9?) releases? If we do, how
> do we do it? Yann spent a lot of time preparing maps, and I think
> there are still problems. Some ways to proceed I can think of:
> 
> 1. Set U10 (or U9?) as a requirement to run kiel, force users to bite
> the bullet and upgrade.

Using U10 might be a little to hard. But update8 or 9 sounds good to me.
We should not go lower then update 8 though since it introduced
getpagesizes2 which in the new header files rewrites getpagesizes to
getpagesizes2. So even if you use getpagesizes you end up with
getpagesizes2 call.

> 2. Freeze kiel (but how do we release security fixes? Dago told me
> it's hard to simultaneously have different Solaris 10 releases on the
> buildfarm)
We can't do that for sparc as it would require an ldom for every
Solaris10 release. (Don't have enough RAM and CPU for that) In other
words we don't have the hardware for that.

> 3. Fix whatever problems there are with function version maps.

The map stuff is fixed now. The Problems I had was trying to drive it
down below update5. This does not work. But in my opinion update 5 is
old enough :) Production systems should be updated anyway.
As mentioned above we should move to update8 for Kiel.

(We should mention it on the homepage though. I wanted to write
something for that but did not have the time to do so.)

We should add some checks though.Because autofoo could check for wrong
stuff :) I think Yann did even start to write some test to check for
newer libc bindings. (could be wrong though )

In short. Move to Update 8 (Kernel 141444-09/141445-09 and higher) for Kiel

Greetings
Jan








From jh at opencsw.org  Tue Dec  4 09:42:18 2012
From: jh at opencsw.org (Jan Holzhueter)
Date: Tue, 04 Dec 2012 09:42:18 +0100
Subject: [csw-maintainers] File collision CSWbinutils and CSWgdb
Message-ID: <50BDB76A.3030507@opencsw.org>

Hi,
building a new binutils gave me a file collision with gdb:

/opt/csw/share/locale/it/LC_MESSAGES/opcodes.mo
and
/opt/csw/share/locale/uk/LC_MESSAGES/bfd.mo

looking at the gdb package those are the only to .mo files in the
package. Sound like a wrong pickup in the gdb package.

Greetings
Jan


From pfelecan at opencsw.org  Tue Dec  4 16:37:59 2012
From: pfelecan at opencsw.org (pfelecan at opencsw.org)
Date: Tue, 4 Dec 2012 16:37:59 +0100 (CET)
Subject: [csw-maintainers] pathfilter issue and more
Message-ID: <f239895c7b0edd2da9c8c7f4cc64c579.squirrel@mail.opencsw.org>

Still trying to build the new release of gdb... I'm getting the following:

Use of uninitialized value $type in string eq at
/home/pfelecan/opencsw/.buildsys/v2/gar/bin/pathfilter line 91, <STDIN>
line 1.
Use of uninitialized value $type in string eq at
/home/pfelecan/opencsw/.buildsys/v2/gar/bin/pathfilter line 93, <STDIN>
line 1.
Use of uninitialized value $type in concatenation (.) or string at
/home/pfelecan/opencsw/.buildsys/v2/gar/bin/pathfilter line 96, <STDIN>
line 1.
Undefined subroutine &main::croak called at
/home/pfelecan/opencsw/.buildsys/v2/gar/bin/pathfilter line 96, <STDIN>
line 1.

You can see all the glorious detail in ~pfelecan/logs/gdb

BTW, the pkgcheck messages are more or less incoherent, especially on the
state of commitment:

CHECKPKG_OVERRIDES_CSWgdb += pkginfo-opencsw-repository-uncommitted

which is true for ~pfelecan/opencsw directory but not for 
~pfelecan/opencsw/gdb/trunk itself...

I'm thanking in advance the kind souls willing to address these issues



From dam at opencsw.org  Tue Dec  4 17:01:55 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 4 Dec 2012 17:01:55 +0100
Subject: [csw-maintainers] pathfilter issue and more
In-Reply-To: <f239895c7b0edd2da9c8c7f4cc64c579.squirrel@mail.opencsw.org>
References: <f239895c7b0edd2da9c8c7f4cc64c579.squirrel@mail.opencsw.org>
Message-ID: <7640D312-DF1E-4D94-BB05-B9095FBC0A7A@opencsw.org>

Hi Peter,

Am 04.12.2012 um 16:37 schrieb pfelecan at opencsw.org:
> Still trying to build the new release of gdb... I'm getting the following:
> 
> Use of uninitialized value $type in string eq at
> /home/pfelecan/opencsw/.buildsys/v2/gar/bin/pathfilter line 91, <STDIN>
> line 1.
> Use of uninitialized value $type in string eq at
> /home/pfelecan/opencsw/.buildsys/v2/gar/bin/pathfilter line 93, <STDIN>
> line 1.
> Use of uninitialized value $type in concatenation (.) or string at
> /home/pfelecan/opencsw/.buildsys/v2/gar/bin/pathfilter line 96, <STDIN>
> line 1.
> Undefined subroutine &main::croak called at
> /home/pfelecan/opencsw/.buildsys/v2/gar/bin/pathfilter line 96, <STDIN>
> line 1.
> 
> You can see all the glorious detail in ~pfelecan/logs/gdb

I think there was a logical error which is hopefully fixed in r19811:
  http://sourceforge.net/apps/trac/gar/changeset/19811

If you still get errors please commit what you have so I can reproduce it.

> BTW, the pkgcheck messages are more or less incoherent, especially on the
> state of commitment:
> 
> CHECKPKG_OVERRIDES_CSWgdb += pkginfo-opencsw-repository-uncommitted
> 
> which is true for ~pfelecan/opencsw directory but not for 
> ~pfelecan/opencsw/gdb/trunk itself...
> 
> I'm thanking in advance the kind souls willing to address these issues


I suggest putting the nohup somewhere else:

> dam at unstable10s [unstable10s]:/home/dam/mgar/pkg/nginx/trunk > svn status ~pfelecan/opencsw/gdb/trunk
> ?       /home/pfelecan/opencsw/gdb/trunk/nohup.out


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  Tue Dec  4 19:58:22 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 04 Dec 2012 19:58:22 +0100
Subject: [csw-maintainers] pathfilter issue and more
In-Reply-To: <7640D312-DF1E-4D94-BB05-B9095FBC0A7A@opencsw.org> (Dagobert
	Michelsen's message of "Tue, 4 Dec 2012 17:01:55 +0100")
References: <f239895c7b0edd2da9c8c7f4cc64c579.squirrel@mail.opencsw.org>
	<7640D312-DF1E-4D94-BB05-B9095FBC0A7A@opencsw.org>
Message-ID: <x6sj7l1w6p.fsf@opencsw.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> Hi Peter,
>
> Am 04.12.2012 um 16:37 schrieb pfelecan at opencsw.org:
>> Still trying to build the new release of gdb... I'm getting the following:
>> 
>> Use of uninitialized value $type in string eq at
>> /home/pfelecan/opencsw/.buildsys/v2/gar/bin/pathfilter line 91, <STDIN>
>> line 1.
>> Use of uninitialized value $type in string eq at
>> /home/pfelecan/opencsw/.buildsys/v2/gar/bin/pathfilter line 93, <STDIN>
>> line 1.
>> Use of uninitialized value $type in concatenation (.) or string at
>> /home/pfelecan/opencsw/.buildsys/v2/gar/bin/pathfilter line 96, <STDIN>
>> line 1.
>> Undefined subroutine &main::croak called at
>> /home/pfelecan/opencsw/.buildsys/v2/gar/bin/pathfilter line 96, <STDIN>
>> line 1.
>> 
>> You can see all the glorious detail in ~pfelecan/logs/gdb
>
> I think there was a logical error which is hopefully fixed in r19811:
>   http://sourceforge.net/apps/trac/gar/changeset/19811
>
> If you still get errors please commit what you have so I can reproduce it.

Thank you for the fix. I'll try it tomorrow.

>> BTW, the pkgcheck messages are more or less incoherent, especially on the
>> state of commitment:
>> 
>> CHECKPKG_OVERRIDES_CSWgdb += pkginfo-opencsw-repository-uncommitted
>> 
>> which is true for ~pfelecan/opencsw directory but not for 
>> ~pfelecan/opencsw/gdb/trunk itself...
>> 
>> I'm thanking in advance the kind souls willing to address these issues
>
>
> I suggest putting the nohup somewhere else:
>
>> dam at unstable10s [unstable10s]:/home/dam/mgar/pkg/nginx/trunk > svn status ~pfelecan/opencsw/gdb/trunk
>> ?       /home/pfelecan/opencsw/gdb/trunk/nohup.out

Well, this never had this kind of effect...
-- 
Peter

From pfelecan at opencsw.org  Tue Dec  4 20:00:01 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 04 Dec 2012 20:00:01 +0100
Subject: [csw-maintainers] TeXLive packaging take almost 3 days
In-Reply-To: <4575CBFC-93C8-4759-B12A-BF96A63E2378@opencsw.org> (Dagobert
	Michelsen's message of "Sat, 1 Dec 2012 22:10:18 +0100")
References: <45c2f3ff0a268dff9e15d23967f71026.squirrel@mail.opencsw.org>
	<D8DD1B8F-78E8-4785-8211-F0521C572EDF@opencsw.org>
	<x6a9ud4h7f.fsf@opencsw.org>
	<DA4F0B5F-D78F-4FFE-8C4B-EEF153004E77@opencsw.org>
	<x6k3t42j1y.fsf@opencsw.org>
	<4575CBFC-93C8-4759-B12A-BF96A63E2378@opencsw.org>
Message-ID: <x6obi91w3y.fsf@opencsw.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> Hi Peter,
>
> Am 29.11.2012 um 22:30 schrieb Peter FELECAN <pfelecan at opencsw.org>:
>> I confirm a 50 times optimization for pathfilter.
>> 
>> As for cswproto, still a hog, here is some additional profiling data:
>> 
>> Total Elapsed Time = 1184.726 Seconds
>>  User+System Time = 1060.576 Seconds
>> Exclusive Times
>> %Time ExclSec CumulS #Calls sec/call Csec/c  Name
>> 98.1   1040. 1040.6 112180   0.0093 0.0093  main::is_common
>> 0.09   0.980  0.980 112164   0.0000 0.0000  main::exclude
>> 0.01   0.069  0.236      7   0.0099 0.0337  main::BEGIN
>> 
>> As you can see the time is spent is determining if the components are
>> part of the common package. I understood that in the future we get rid
>> of that but in the mean time we need to find a quicker way to determine
>> that relation. With the current optimization we probably can package
>> TeXLive in 1.5 days which is still too much...
>
>
> Indeed? That was not what I had expected by looking at the code as I would have guessed
> it takes most of the time for during mkproto. I did some optimization on the regex-part,
> it should now be a lot faster:
>   http://sourceforge.net/apps/trac/gar/changeset/19800
>
> Please let me know if you encounter any other performance issues.

I can confirm that this fix reduces the step by one order of magnitude,
i.e., from 30 minutes for this specific prototype to 3 minutes!

Thank you again for your work
-- 
Peter

From pfelecan at opencsw.org  Tue Dec  4 20:00:47 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 04 Dec 2012 20:00:47 +0100
Subject: [csw-maintainers] File collision CSWbinutils and CSWgdb
In-Reply-To: <50BDB76A.3030507@opencsw.org> (Jan Holzhueter's message of "Tue, 
	04 Dec 2012 09:42:18 +0100")
References: <50BDB76A.3030507@opencsw.org>
Message-ID: <x6k3sx1w2o.fsf@opencsw.org>

Jan Holzhueter <jh at opencsw.org> writes:

> Hi,
> building a new binutils gave me a file collision with gdb:
>
> /opt/csw/share/locale/it/LC_MESSAGES/opcodes.mo
> and
> /opt/csw/share/locale/uk/LC_MESSAGES/bfd.mo
>
> looking at the gdb package those are the only to .mo files in the
> package. Sound like a wrong pickup in the gdb package.

I fixed this but have some delay in releasing a new package. Hopefully
tomorrow.

-- 
Peter

From dam at opencsw.org  Tue Dec  4 21:37:37 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 4 Dec 2012 21:37:37 +0100
Subject: [csw-maintainers] Fwd: OpenCSW,
	it's time to upgrade your classic SourceForge project
References: <mailman.593.1354653396.25301.maintainers@lists.opencsw.org>
Message-ID: <28282788-CF41-4146-B5D7-FA3999CA2B04@opencsw.org>

Hi folks,

I guess we need to get going with the transfer. As far as I understood it we could
also continue to run Trac on the SourceForge webspace now which has been enhanced
to be able to run Trac.


Best regards

 -- Dago

Anfang der weitergeleiteten Nachricht:

> Von: "Rich Bowen" <rbowen at sourceforge.net>
> Betreff: OpenCSW, it's time to upgrade your classic SourceForge project
> Datum: 4. Dezember 2012 18:24:07 MEZ
> An: "Dagobert Michelsen" <dmichelsen at users.sf.net>, "Sebastian Kayser" <skayser at users.sf.net>
> 
> Dear OpenCSW project admin,
> 
> Since your project has shown some activity in the last few months, we
> want to be sure that you're aware that some changes are happening at
> SourceForge, and we want to be sure you're not caught by surprise.
> 
> As you may already be aware, SourceForge is upgrading to a new platform
> (code-named Allura), and as a result, we'll be retiring the Classic
> SourceForge platform, which your project is still using. Our goal is to
> have everybody off of the old platform in the first quarter of next
> year, so that we can retire that code and focus our attention on the new
> platform. It would, of course, be preferable if you migrate your own
> project in your own time.
> 
> You can read more about the new platform at
> https://sourceforge.net/p/upgrade/ and then, when you're ready, press
> the Upgrade button next to your project name.
> 
> If you have any concerns about the process, or if your project has an
> unusually large number of forums, source code repositories, or trackers,
> please don't hesitate to contact us to discuss your upgrade. It's
> important to us that it go smoothly.
> 
> As always, thanks for being part of the SourceForge community.
> 
> Rich Bowen
> SourceForge Community Manager
> rbowen at sourceforge.net


-- 
"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 jh at opencsw.org  Wed Dec  5 07:28:02 2012
From: jh at opencsw.org (Jan Holzhueter)
Date: Wed, 05 Dec 2012 07:28:02 +0100
Subject: [csw-maintainers] File collision CSWbinutils and CSWgdb
In-Reply-To: <x6k3sx1w2o.fsf@opencsw.org>
References: <50BDB76A.3030507@opencsw.org> <x6k3sx1w2o.fsf@opencsw.org>
Message-ID: <50BEE972.9020508@opencsw.org>

Am 04.12.12 20:00, schrieb Peter FELECAN:
> Jan Holzhueter <jh at opencsw.org> writes:
> 
>> Hi,
>> building a new binutils gave me a file collision with gdb:
>>
>> /opt/csw/share/locale/it/LC_MESSAGES/opcodes.mo
>> and
>> /opt/csw/share/locale/uk/LC_MESSAGES/bfd.mo
>>
>> looking at the gdb package those are the only to .mo files in the
>> package. Sound like a wrong pickup in the gdb package.
> 
> I fixed this but have some delay in releasing a new package. Hopefully
> tomorrow.
> 

I saw that. No Problem.

Greetings
Jan


From pfelecan at opencsw.org  Wed Dec  5 08:53:52 2012
From: pfelecan at opencsw.org (pfelecan at opencsw.org)
Date: Wed, 5 Dec 2012 08:53:52 +0100 (CET)
Subject: [csw-maintainers] checkpkg for builds spanning on 2 or more days
	(again)
Message-ID: <22b55696851a23aa58cd871290df04bc.squirrel@mail.opencsw.org>

Still getting this error when the packaging process spans more than 2 days!

A lot of energy spent to fail for this kind of reason.

Please don't tell me to do it manually as I have 96 packages...

INFO:root:Juicing the svr4 package stream files...
Traceback (most recent call last):                                        
   |
  File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", line 197,
in <module>
    main()
  File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", line 120,
in main
    stats_list = collector.CollectStatsFromFiles(file_list, None)
  File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py",
line 499, in CollectStatsFromFiles
    stats.CollectStats(force=force_unpack)
  File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py",
line 174, in CollectStats
    if force or not self.StatsExist():
  File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py",
line 102, in StatsExist
    pkg_stats = self.GetDbObject()
  File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py",
line 85, in GetDbObject
    md5_sum = self.GetMd5sum()
  File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py",
line 80, in GetMd5sum
    self.md5sum = self.srv4_pkg.GetMd5sum()
  File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package.py", line
193, in GetMd5sum
    fp = open(self.pkg_path)
IOError: [Errno 2] No such file or directory:
'/home/pfelecan/staging/build-05.Dec.2012/libkpathsea6-20120701,REV=2012.12.04-SunOS5.10-sparc-UNCOMMITTED.pkg.gz'
gmake[1]: *** [pkgcheck] Error 2
gmake[1]: Leaving directory `/home/pfelecan/opencsw/texlive/trunk'
gmake: *** [platforms] Error 2


From dam at opencsw.org  Wed Dec  5 08:55:32 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 5 Dec 2012 08:55:32 +0100
Subject: [csw-maintainers] checkpkg for builds spanning on 2 or more
	days (again)
In-Reply-To: <22b55696851a23aa58cd871290df04bc.squirrel@mail.opencsw.org>
References: <22b55696851a23aa58cd871290df04bc.squirrel@mail.opencsw.org>
Message-ID: <B4F68184-B733-40E6-B4F0-4B216B5B369D@opencsw.org>

Hi Peter,

Am 05.12.2012 um 08:53 schrieb pfelecan at opencsw.org:
> Still getting this error when the packaging process spans more than 2 days!
> 
> A lot of energy spent to fail for this kind of reason.
> 
> Please don't tell me to do it manually as I have 96 packages?

The repackage should now be considerable faster. I'll also have a look
on how this could be fixed.


Best regards

  -- Dago

> 
> INFO:root:Juicing the svr4 package stream files...
> Traceback (most recent call last):                                        
>   |
>  File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", line 197,
> in <module>
>    main()
>  File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", line 120,
> in main
>    stats_list = collector.CollectStatsFromFiles(file_list, None)
>  File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py",
> line 499, in CollectStatsFromFiles
>    stats.CollectStats(force=force_unpack)
>  File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py",
> line 174, in CollectStats
>    if force or not self.StatsExist():
>  File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py",
> line 102, in StatsExist
>    pkg_stats = self.GetDbObject()
>  File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py",
> line 85, in GetDbObject
>    md5_sum = self.GetMd5sum()
>  File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py",
> line 80, in GetMd5sum
>    self.md5sum = self.srv4_pkg.GetMd5sum()
>  File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package.py", line
> 193, in GetMd5sum
>    fp = open(self.pkg_path)
> IOError: [Errno 2] No such file or directory:
> '/home/pfelecan/staging/build-05.Dec.2012/libkpathsea6-20120701,REV=2012.12.04-SunOS5.10-sparc-UNCOMMITTED.pkg.gz'
> gmake[1]: *** [pkgcheck] Error 2
> gmake[1]: Leaving directory `/home/pfelecan/opencsw/texlive/trunk'
> gmake: *** [platforms] Error 2
> 
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.

-- 
"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 Dec  5 09:40:47 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Wed, 5 Dec 2012 08:40:47 +0000
Subject: [csw-maintainers] checkpkg for builds spanning on 2 or more
	days (again)
In-Reply-To: <B4F68184-B733-40E6-B4F0-4B216B5B369D@opencsw.org>
References: <22b55696851a23aa58cd871290df04bc.squirrel@mail.opencsw.org>
	<B4F68184-B733-40E6-B4F0-4B216B5B369D@opencsw.org>
Message-ID: <CALtRa-6zMaFn37hYS7Cygy_XfOZRpOLYoLPErjGB4kJ28Y_2TA@mail.gmail.com>

2012/12/5 Dagobert Michelsen <dam at opencsw.org>:
> The repackage should now be considerable faster. I'll also have a look
> on how this could be fixed.

I think the problem is that the date tag is calculated multiple times
independently, instead of being calculated once and then fixed; it
could be either near the packaging start date or packaging stop date.

Is this some kind of a fundamental problem? (I don't think we
shouldn't try to speed up package builds spanning days, but it's
common to do some packaging around midnight, and the same problem
occurs.)

From dam at opencsw.org  Wed Dec  5 09:58:49 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 5 Dec 2012 09:58:49 +0100
Subject: [csw-maintainers] checkpkg for builds spanning on 2 or more
	days (again)
In-Reply-To: <CALtRa-6zMaFn37hYS7Cygy_XfOZRpOLYoLPErjGB4kJ28Y_2TA@mail.gmail.com>
References: <22b55696851a23aa58cd871290df04bc.squirrel@mail.opencsw.org>
	<B4F68184-B733-40E6-B4F0-4B216B5B369D@opencsw.org>
	<CALtRa-6zMaFn37hYS7Cygy_XfOZRpOLYoLPErjGB4kJ28Y_2TA@mail.gmail.com>
Message-ID: <8EF9A732-FF73-4884-BB03-FFE16FE0FA54@opencsw.org>

Hi Maciej,

Am 05.12.2012 um 09:40 schrieb Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
> 2012/12/5 Dagobert Michelsen <dam at opencsw.org>:
>> The repackage should now be considerable faster. I'll also have a look
>> on how this could be fixed.
> 
> I think the problem is that the date tag is calculated multiple times
> independently, instead of being calculated once and then fixed; it
> could be either near the packaging start date or packaging stop date.
> 
> Is this some kind of a fundamental problem? (I don't think we
> shouldn't try to speed up package builds spanning days, but it's
> common to do some packaging around midnight, and the same problem
> occurs.)

It is a fundamental problem and the name is calculated multiple times. The problem
is the multiple subinvocations, the package names must be calculated only on the first
invocation and passed to deeper levels. However, the filenames need to be associated
with the generated packages. In general the problem is rather easy, but fiddling it into
the existing make-system is a bit hairy.


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896


From dam at opencsw.org  Wed Dec  5 16:09:02 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 5 Dec 2012 16:09:02 +0100
Subject: [csw-maintainers] checkpkg for builds spanning on 2 or more
	days (again)
In-Reply-To: <22b55696851a23aa58cd871290df04bc.squirrel@mail.opencsw.org>
References: <22b55696851a23aa58cd871290df04bc.squirrel@mail.opencsw.org>
Message-ID: <B7DD0DFC-1D0E-440A-B898-8AE191C68E48@opencsw.org>

Hi Peter,

Am 05.12.2012 um 08:53 schrieb pfelecan at opencsw.org:
> Still getting this error when the packaging process spans more than 2 days!
> 
> A lot of energy spent to fail for this kind of reason.
> 
> Please don't tell me to do it manually as I have 96 packages?

This is finally fixed in r19819:
  https://sourceforge.net/apps/trac/gar/changeset/19819

After all the solution was quite easy, but I didn't see it before: just put
the filename statically in the gspec describing the build to mkpackage.
The filename from there is also taken for checkpkg, so it should work
without problems now.

I always pumped up my head on how to pass environment variables between
subinvocations, which is indeed not trivial.

Just let me know how it goes.


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  Wed Dec  5 20:03:14 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Wed, 05 Dec 2012 20:03:14 +0100
Subject: [csw-maintainers] File collision CSWbinutils and CSWgdb
In-Reply-To: <50BEE972.9020508@opencsw.org> (Jan Holzhueter's message of "Wed, 
	05 Dec 2012 07:28:02 +0100")
References: <50BDB76A.3030507@opencsw.org> <x6k3sx1w2o.fsf@opencsw.org>
	<50BEE972.9020508@opencsw.org>
Message-ID: <x6fw3k1fv1.fsf@opencsw.org>

Jan Holzhueter <jh at opencsw.org> writes:

> Am 04.12.12 20:00, schrieb Peter FELECAN:
>> Jan Holzhueter <jh at opencsw.org> writes:
>> 
>>> Hi,
>>> building a new binutils gave me a file collision with gdb:
>>>
>>> /opt/csw/share/locale/it/LC_MESSAGES/opcodes.mo
>>> and
>>> /opt/csw/share/locale/uk/LC_MESSAGES/bfd.mo
>>>
>>> looking at the gdb package those are the only to .mo files in the
>>> package. Sound like a wrong pickup in the gdb package.
>> 
>> I fixed this but have some delay in releasing a new package. Hopefully
>> tomorrow.
>> 
>
> I saw that. No Problem.

FYI: released gdb 7.5.1 which doesn't conflict anymore. Happy binutils...
-- 
Peter

From pfelecan at opencsw.org  Wed Dec  5 20:07:15 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Wed, 05 Dec 2012 20:07:15 +0100
Subject: [csw-maintainers] checkpkg for builds spanning on 2 or more
	days (again)
In-Reply-To: <B7DD0DFC-1D0E-440A-B898-8AE191C68E48@opencsw.org> (Dagobert
	Michelsen's message of "Wed, 5 Dec 2012 16:09:02 +0100")
References: <22b55696851a23aa58cd871290df04bc.squirrel@mail.opencsw.org>
	<B7DD0DFC-1D0E-440A-B898-8AE191C68E48@opencsw.org>
Message-ID: <x6boe81foc.fsf@opencsw.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> Hi Peter,
>
> Am 05.12.2012 um 08:53 schrieb pfelecan at opencsw.org:
>> Still getting this error when the packaging process spans more than 2 days!
>> 
>> A lot of energy spent to fail for this kind of reason.
>> 
>> Please don't tell me to do it manually as I have 96 packages?
>
> This is finally fixed in r19819:
>   https://sourceforge.net/apps/trac/gar/changeset/19819
>
> After all the solution was quite easy, but I didn't see it before: just put
> the filename statically in the gspec describing the build to mkpackage.
> The filename from there is also taken for checkpkg, so it should work
> without problems now.
>
> I always pumped up my head on how to pass environment variables between
> subinvocations, which is indeed not trivial.
>
> Just let me know how it goes.

Thank you for your always quick intervention! I started a new build of
TeXLive and I'm quite optimistic that it will continue after midnight
which is an optimal venue to test your enhancement.
-- 
Peter

From claudio at opencsw.org  Wed Dec  5 22:37:19 2012
From: claudio at opencsw.org (Claudio)
Date: Wed, 05 Dec 2012 22:37:19 +0100
Subject: [csw-maintainers] mgar experts: help me out with mgar-Perl
Message-ID: <50BFBE8F.4030109@opencsw.org>

Hi,

[ Warning: long mail ]

As some of you may know I am looking on how to get an up-to-date Perl
(5.16.1/2) on OpenCSW. There were some bugs on Solaris that were fixed
along the way by the Perl core hackers with our aid (mainly supplying
failing cases). Sorry for my intermittent presence, but I have been very
busy lately.

Now, we have a perfectly compiling, unit-tested and working Perl on
Solaris (including 64-bit builds, sparc, d-trace and threaded builds).
The patch to fix one failing test didn't make it to the latest release
(5.16.2), but we do have the patch on the farm as provided by p5p and
it's in blead. So far so good... on *non-mgar* builds on the farm.

So while we know that we can easily build Perl on the farm by hand,
there were some problems when integrating into mgar. Luckily, Peter's
work on the previous mgar Makefile is solid, so besides some small
adaptations there was not much work there to get Perl compiled.

Perl has thousands of tests to make sure the latest release don't make
stuff. When running the test suit on the mgar-build, we ended with 4
failing tests (so we passed 99.9-something%). The first one, as pointed
out above, was a Solaris-specific bug in the test itself.

The next two failing tests were a false positive caused by an
incompatibility on how mgar works and assumptions by the core Perl
developers. In short, when an '.git' directory is found in the source,
the testing suit assumes you're upstream running a dev-release and
additional tests are performed for releases, like author information and
the like. And because mgar create a '.git' directory in the source
directory we have a conflict. The workaround for now is a move/rename of
the directory while testing and restore the situation afterwards (mv &&
test && mv).

The last failing test also looks like a mgar problem to me, but we need
to be careful because it affects the Perl debugger. I strongly suspect,
that's it's related to the mgar environment at test time (but it could
be earlier).

See the mentioning of /opt/csw/lib/perl/csw/Term/ReadLine/Gnu.pm in the
failing test below. The line number resulting in the crash is the line
number of the *installed* 5.10 perl on the system and not the new 5.16.1
lib with a very different layout. So the test is definitely mixing old
and new when testing. Also, when doing the test differently (second test
link) we get the explicit error of the mixing of version. Furthermore,
comparing the compile information on the successful non-mgar build and
the successful-with-failing-test mgar-build I don't see any relevant
difference. Maybe you guys and gals can recognise something and have
some pointers. if we find out at what stage the mixing happens, we'll
have an up-to-date perl.

Here is the verbose output of the failing test of perldb.pl:
http://buildfarm.opencsw.org/~claudio/failing-test-perldb
http://buildfarm.opencsw.org/~claudio/perl-test-mix

Here is the compile information of the non-mgar build:
http://buildfarm.opencsw.org/~claudio/perl-V-nomgar

Here is the compile information of the mgar build:
http://buildfarm.opencsw.org/~claudio/perl-V-mgar


Claudio





From pfelecan at opencsw.org  Thu Dec  6 09:05:03 2012
From: pfelecan at opencsw.org (pfelecan at opencsw.org)
Date: Thu, 6 Dec 2012 09:05:03 +0100 (CET)
Subject: [csw-maintainers] checkpkg for builds spanning on 2 or more days
	(continued)
Message-ID: <d364b3f12c45a08475372c3c00f8a8cc.squirrel@mail.opencsw.org>

After upgrading ~/opencsw/.buildsys/v2, I tested the packaging of TeXLive
and failed again in the same situation. You can dinf everything in
~pfelecan/opencsw/texlive/trunk, ~pfelecan/staging/build-06.Dec.2012 and
the log file is in ~pfelecan/logs/texlive


From dam at opencsw.org  Thu Dec  6 09:30:46 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 6 Dec 2012 09:30:46 +0100
Subject: [csw-maintainers] checkpkg for builds spanning on 2 or more
	days (continued)
In-Reply-To: <d364b3f12c45a08475372c3c00f8a8cc.squirrel@mail.opencsw.org>
References: <d364b3f12c45a08475372c3c00f8a8cc.squirrel@mail.opencsw.org>
Message-ID: <7D3B0146-4929-46C1-AF6B-CBA3DF5642B7@opencsw.org>

Hi Peter,

Am 06.12.2012 um 09:05 schrieb pfelecan at opencsw.org:
> After upgrading ~/opencsw/.buildsys/v2, I tested the packaging of TeXLive
> and failed again in the same situation. You can dinf everything in
> ~pfelecan/opencsw/texlive/trunk, ~pfelecan/staging/build-06.Dec.2012 and
> the log file is in ~pfelecan/logs/texlive

This is (yet another) continuity error, the package names are correct now and
mkpackage extracts consistently the right names, but the name of the staging
directory also includes the date, so resulting packages are mixed within output
dirs:

> dam at login [login]:/home/pfelecan/opencsw/texlive/trunk > ls -l /home/pfelecan/staging/build-06.Dec.2012 | wc -l
>       81
> dam at login [login]:/home/pfelecan/opencsw/texlive/trunk > ls -l /home/pfelecan/staging/build-05.Dec.2012 | wc -l
>       22

I'll see that I can get this fixed ASAP.


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896


From dam at opencsw.org  Thu Dec  6 11:35:23 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 6 Dec 2012 11:35:23 +0100
Subject: [csw-maintainers] checkpkg for builds spanning on 2 or more
	days (continued)
In-Reply-To: <7D3B0146-4929-46C1-AF6B-CBA3DF5642B7@opencsw.org>
References: <d364b3f12c45a08475372c3c00f8a8cc.squirrel@mail.opencsw.org>
	<7D3B0146-4929-46C1-AF6B-CBA3DF5642B7@opencsw.org>
Message-ID: <E54F53B4-78D6-4405-B48B-4D874C4F21E8@opencsw.org>

Hi Peter,

Am 06.12.2012 um 09:30 schrieb Dagobert Michelsen <dam at opencsw.org>:
> Am 06.12.2012 um 09:05 schrieb pfelecan at opencsw.org:
>> After upgrading ~/opencsw/.buildsys/v2, I tested the packaging of TeXLive
>> and failed again in the same situation. You can dinf everything in
>> ~pfelecan/opencsw/texlive/trunk, ~pfelecan/staging/build-06.Dec.2012 and
>> the log file is in ~pfelecan/logs/texlive
> 
> This is (yet another) continuity error, the package names are correct now and
> mkpackage extracts consistently the right names, but the name of the staging
> directory also includes the date, so resulting packages are mixed within output
> dirs:
> 
>> dam at login [login]:/home/pfelecan/opencsw/texlive/trunk > ls -l /home/pfelecan/staging/build-06.Dec.2012 | wc -l
>>      81
>> dam at login [login]:/home/pfelecan/opencsw/texlive/trunk > ls -l /home/pfelecan/staging/build-05.Dec.2012 | wc -l
>>      22
> 
> I'll see that I can get this fixed ASAP.


This is now fixed in r19829:
  http://sourceforge.net/apps/trac/gar/changeset/19829

I really like these demanding build recipes as they push GAR to the limit revealing problems
which would go unnoticed otherwise :-)


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 claudio at opencsw.org  Thu Dec  6 12:04:06 2012
From: claudio at opencsw.org (Claudio)
Date: Thu, 06 Dec 2012 12:04:06 +0100
Subject: [csw-maintainers] mgar experts: help me out with mgar-Perl
In-Reply-To: <50BFBE8F.4030109@opencsw.org>
References: <50BFBE8F.4030109@opencsw.org>
Message-ID: <50C07BA6.1030809@opencsw.org>

On 05-12-12 22:37, Claudio wrote:
> Hi,
> 
> [ Warning: long mail ]

This one is shorter. I found the cultpit on the Makefile:

CONFIGURE_ARGS += -Dvendorarch=$(libdir)/perl/csw

Commenting that one out, results in all test passing:

All tests successful.
u=36.26  s=27.75  cu=3890.22  cs=615.88  scripts=2250  tests=537030
gmake[2]: Leaving directory
`/home/claudio/opencsw/perl/trunk/work/solaris10-sparc/build-isa-sparcv8plus/perl-5.16.1'
        [test-modulated] complete for perl.
gmake[1]: Leaving directory `/home/claudio/opencsw/perl/trunk'
        [test] complete for perl.

C.

From dam at opencsw.org  Thu Dec  6 12:29:56 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 6 Dec 2012 12:29:56 +0100
Subject: [csw-maintainers] mgar experts: help me out with mgar-Perl
In-Reply-To: <50C07BA6.1030809@opencsw.org>
References: <50BFBE8F.4030109@opencsw.org> <50C07BA6.1030809@opencsw.org>
Message-ID: <9B65264F-74E5-4104-8DB2-8D4E1F4A2C62@opencsw.org>

Hi Claudio,

Am 06.12.2012 um 12:04 schrieb Claudio <claudio at opencsw.org>:
> On 05-12-12 22:37, Claudio wrote:
>> [ Warning: long mail ]
> 
> This one is shorter. I found the cultpit on the Makefile:
> 
> CONFIGURE_ARGS += -Dvendorarch=$(libdir)/perl/csw
> 
> Commenting that one out, results in all test passing:
> 
> All tests successful.
> u=36.26  s=27.75  cu=3890.22  cs=615.88  scripts=2250  tests=537030
> gmake[2]: Leaving directory
> `/home/claudio/opencsw/perl/trunk/work/solaris10-sparc/build-isa-sparcv8plus/perl-5.16.1'
>        [test-modulated] complete for perl.
> gmake[1]: Leaving directory `/home/claudio/opencsw/perl/trunk'
>        [test] complete for perl.


\o/ How do we proceed? As I understand it this is necessary to put our stuff in that
subdirectory. Should we omit it anyway or does the test need adjustment?


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 claudio at opencsw.org  Thu Dec  6 12:46:30 2012
From: claudio at opencsw.org (Claudio)
Date: Thu, 06 Dec 2012 12:46:30 +0100
Subject: [csw-maintainers] mgar experts: help me out with mgar-Perl
In-Reply-To: <9B65264F-74E5-4104-8DB2-8D4E1F4A2C62@opencsw.org>
References: <50BFBE8F.4030109@opencsw.org> <50C07BA6.1030809@opencsw.org>
	<9B65264F-74E5-4104-8DB2-8D4E1F4A2C62@opencsw.org>
Message-ID: <50C08596.5020207@opencsw.org>

On 06-12-12 12:29, Dagobert Michelsen wrote:

> \o/ How do we proceed? As I understand it this is necessary to put our stuff in that
> subdirectory. Should we omit it anyway or does the test need adjustment?

Define "our stuff". What do we put in there? As far as I can see, all
the files are put in the correct /opt/csw dir as specified by the
configure stage. There is even a site_vendor dir for vendor modules.

C


From bwalton at opencsw.org  Sat Dec  8 14:06:30 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 8 Dec 2012 13:06:30 +0000
Subject: [csw-maintainers] multi-catalog package browser vs mantis
Message-ID: <CAP30j17s1TNy+fOaNSXMxBTAA4zKzeWunv32xWKU6d9V9U09Qw@mail.gmail.com>

Hi All,

I've implemented many of the modifications required to move our
package browsing interface from a mysql backed setup to a combination
of a small mysql database (serving as a cache) and an ajax interface
using Maciej's pkgdb REST interface.  (I haven't made these publicly
available yet but will over the weekend, I hope.)

There are some hurdles to overcome if this is the direction that we're
going to move but most of those can be handled by extending the REST
interface to allow more and different calls.

The real problem, as I see it, will be the mantis integration.  We're
able to provide links to the bugs for a package right now because the
php code accesses both the mantis and package databases.  It is able
to extract and ID for a package given the catalog name.  (Mantis has
no sense of package names at all.)  Our mantis integration (and indeed
our whole mantis approach) is centred on a single catalog of package
information.  It lacks any sort of decent api, as far as I can tell,
to even jump directly to a bug list by anything other than a project
id which requires a db lookup to extract.

I can hack around the ID lookup issue to facilitate providing a link
from the package info to the mantis page but it will be a leaky
workaround.  Does anyone have thoughts on the best way to address
this?  We've talked before about mantis' shortcomings and a desire to
move away from it...volunteers?

The alternate approach is pull all catalog info to a local mysql
database but that still leaves the mantis problem, so this isn't just
a methodology issue but a fundamental disconnect between how we're
using mantis and how we'd like our users to be able to see our catalog
information.

Thoughts?

Thanks
-Ben

From pfelecan at opencsw.org  Sat Dec  8 19:44:59 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sat, 08 Dec 2012 19:44:59 +0100
Subject: [csw-maintainers] checkpkg for builds spanning on 2 or more
	days (continued)
In-Reply-To: <E54F53B4-78D6-4405-B48B-4D874C4F21E8@opencsw.org> (Dagobert
	Michelsen's message of "Thu, 6 Dec 2012 11:35:23 +0100")
References: <d364b3f12c45a08475372c3c00f8a8cc.squirrel@mail.opencsw.org>
	<7D3B0146-4929-46C1-AF6B-CBA3DF5642B7@opencsw.org>
	<E54F53B4-78D6-4405-B48B-4D874C4F21E8@opencsw.org>
Message-ID: <x6y5h8z8lw.fsf@opencsw.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> Hi Peter,
>
> Am 06.12.2012 um 09:30 schrieb Dagobert Michelsen <dam at opencsw.org>:
>> Am 06.12.2012 um 09:05 schrieb pfelecan at opencsw.org:
>>> After upgrading ~/opencsw/.buildsys/v2, I tested the packaging of TeXLive
>>> and failed again in the same situation. You can dinf everything in
>>> ~pfelecan/opencsw/texlive/trunk, ~pfelecan/staging/build-06.Dec.2012 and
>>> the log file is in ~pfelecan/logs/texlive
>> 
>> This is (yet another) continuity error, the package names are correct now and
>> mkpackage extracts consistently the right names, but the name of the staging
>> directory also includes the date, so resulting packages are mixed within output
>> dirs:
>> 
>>> dam at login [login]:/home/pfelecan/opencsw/texlive/trunk > ls -l /home/pfelecan/staging/build-06.Dec.2012 | wc -l
>>>      81
>>> dam at login [login]:/home/pfelecan/opencsw/texlive/trunk > ls -l /home/pfelecan/staging/build-05.Dec.2012 | wc -l
>>>      22
>> 
>> I'll see that I can get this fixed ASAP.
>
>
> This is now fixed in r19829:
>   http://sourceforge.net/apps/trac/gar/changeset/19829
>
> I really like these demanding build recipes as they push GAR to the limit revealing problems
> which would go unnoticed otherwise :-)

I rebuilt TexLive in the same conditions and now it works correctly. Now
it's my turn to act upon the checkpkg suggestions.

Thank you for your work.
-- 
Peter

From pfelecan at opencsw.org  Sat Dec  8 19:52:07 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sat, 08 Dec 2012 19:52:07 +0100
Subject: [csw-maintainers] multi-catalog package browser vs mantis
In-Reply-To: <CAP30j17s1TNy+fOaNSXMxBTAA4zKzeWunv32xWKU6d9V9U09Qw@mail.gmail.com>
	(Ben Walton's message of "Sat, 8 Dec 2012 13:06:30 +0000")
References: <CAP30j17s1TNy+fOaNSXMxBTAA4zKzeWunv32xWKU6d9V9U09Qw@mail.gmail.com>
Message-ID: <x6txrwz8a0.fsf@opencsw.org>

Ben Walton <bwalton at opencsw.org> writes:

> I can hack around the ID lookup issue to facilitate providing a link
> from the package info to the mantis page but it will be a leaky
> workaround.  Does anyone have thoughts on the best way to address
> this?  We've talked before about mantis' shortcomings and a desire to
> move away from it...volunteers?
>
> The alternate approach is pull all catalog info to a local mysql
> database but that still leaves the mantis problem, so this isn't just
> a methodology issue but a fundamental disconnect between how we're
> using mantis and how we'd like our users to be able to see our catalog
> information.

Can you write a short but complete specification of what we want and use
it as a guide to moving forward? It will help to fix the requirements
and choose and/or create the adequate tools.
-- 
Peter

From dam at opencsw.org  Sat Dec  8 20:43:39 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sat, 8 Dec 2012 20:43:39 +0100
Subject: [csw-maintainers] multi-catalog package browser vs mantis
In-Reply-To: <x6txrwz8a0.fsf@opencsw.org>
References: <CAP30j17s1TNy+fOaNSXMxBTAA4zKzeWunv32xWKU6d9V9U09Qw@mail.gmail.com>
	<x6txrwz8a0.fsf@opencsw.org>
Message-ID: <74C03AAF-9360-4F6A-BB66-5F572161DF1F@opencsw.org>

Hi Peter,

Am 08.12.2012 um 19:52 schrieb Peter FELECAN <pfelecan at opencsw.org>:
> Ben Walton <bwalton at opencsw.org> writes:
>> I can hack around the ID lookup issue to facilitate providing a link
>> from the package info to the mantis page but it will be a leaky
>> workaround.  Does anyone have thoughts on the best way to address
>> this?  We've talked before about mantis' shortcomings and a desire to
>> move away from it...volunteers?
>> 
>> The alternate approach is pull all catalog info to a local mysql
>> database but that still leaves the mantis problem, so this isn't just
>> a methodology issue but a fundamental disconnect between how we're
>> using mantis and how we'd like our users to be able to see our catalog
>> information.
> 
> Can you write a short but complete specification of what we want and use
> it as a guide to moving forward? It will help to fix the requirements
> and choose and/or create the adequate tools.

There is a webpage where some of the issues about the bug tracker are
collected:
  http://wiki.opencsw.org/project-bugtracker


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  Sun Dec  9 10:32:37 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 9 Dec 2012 09:32:37 +0000
Subject: [csw-maintainers] www-mockup
Message-ID: <CAP30j17-qEbziONnS+_ChBk7MTxhP=68e7ARQPHazYxK8WFxNA@mail.gmail.com>

Hi All,

Are there any objections to me wiping out www-mockup and placing my
work in progress on the new package browser there for public scrutiny?

I don't have better facilities for such a display at the moment...

I could preserve the current content/experiments if they're of any value.

Thanks
-Ben

From maciej at opencsw.org  Sun Dec  9 11:12:32 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 9 Dec 2012 10:12:32 +0000
Subject: [csw-maintainers] www-mockup
In-Reply-To: <CAP30j17-qEbziONnS+_ChBk7MTxhP=68e7ARQPHazYxK8WFxNA@mail.gmail.com>
References: <CAP30j17-qEbziONnS+_ChBk7MTxhP=68e7ARQPHazYxK8WFxNA@mail.gmail.com>
Message-ID: <CALtRa-6PK-vzkoT7=T9SaPcMmk0SjGoJuP8Lw1qOUC7=bzCNDg@mail.gmail.com>

2012/12/9 Ben Walton <bwalton at opencsw.org>:
> Are there any objections to me wiping out www-mockup and placing my
> work in progress on the new package browser there for public scrutiny

No objections; I have played around with the layout there, so you
might save a backup in case we want to use my modifications to the
main page.

Maciej

From wilbury at opencsw.org  Sun Dec  9 11:29:57 2012
From: wilbury at opencsw.org (Juraj Lutter)
Date: Sun, 09 Dec 2012 11:29:57 +0100
Subject: [csw-maintainers] www-mockup
In-Reply-To: <CALtRa-6PK-vzkoT7=T9SaPcMmk0SjGoJuP8Lw1qOUC7=bzCNDg@mail.gmail.com>
References: <CAP30j17-qEbziONnS+_ChBk7MTxhP=68e7ARQPHazYxK8WFxNA@mail.gmail.com>
	<CALtRa-6PK-vzkoT7=T9SaPcMmk0SjGoJuP8Lw1qOUC7=bzCNDg@mail.gmail.com>
Message-ID: <50C46825.6000706@opencsw.org>

On 12/09/2012 11:12 AM, Maciej (Matchek) Blizi?ski wrote:
> 2012/12/9 Ben Walton <bwalton at opencsw.org>:
>> Are there any objections to me wiping out www-mockup and placing my
>> work in progress on the new package browser there for public scrutiny
> 
> No objections; I have played around with the layout there, so you
> might save a backup in case we want to use my modifications to the
> main page.

While we are at it, what is the current status of moving web to a zone
that i've set up?

IIRC, Yann has made some progress with it.



-- 
Juraj Lutter <wilbury at opencsw.org>

From bwalton at opencsw.org  Sun Dec  9 21:53:39 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 9 Dec 2012 20:53:39 +0000
Subject: [csw-maintainers] www-mockup
In-Reply-To: <CALtRa-6PK-vzkoT7=T9SaPcMmk0SjGoJuP8Lw1qOUC7=bzCNDg@mail.gmail.com>
References: <CAP30j17-qEbziONnS+_ChBk7MTxhP=68e7ARQPHazYxK8WFxNA@mail.gmail.com>
	<CALtRa-6PK-vzkoT7=T9SaPcMmk0SjGoJuP8Lw1qOUC7=bzCNDg@mail.gmail.com>
Message-ID: <CAP30j17CyN2aSRsGuwV_8QjBLnkdciAZ-vu2V+MQr2TQRkY_9g@mail.gmail.com>

Ok, done.  I've moved the original htdocs to htdocs.orig.  I had to
quickly stub out a bit of code that sorted SunOS5.x strings by the x
as I guess I used some newer php convention that www-mockup didn't
like.  I'll fix that later so that 5.8 sorts before 5.11. You can poke
at what I've done for now though.

Larger items remaining:

1. Pull a list of maintainers over REST and implement /maintainers/
functionality.
2. Add dependency info.
3. Add shared library info.

The approach I've taken so far is to remain as close as possible to
the old browser while adding multi-catalog viewing.  We'll need to
extend the REST interface if we'd like to add things like a drill-down
from a full catalog list, etc.  (...or cache more info in the local
db.)  I think we'll need to extend the REST interface regardless so
this shouldn't be seen as a large hurdle.  The key as far as extending
the REST interface is that there are things that are currently quite
slow to do and those would be noticed by the user...that's why we
cache the list of packages across all catalogs in the DB, for example.

Comments?

Thanks
-Ben

On Sun, Dec 9, 2012 at 10:12 AM, Maciej (Matchek) Blizi?ski
<maciej at opencsw.org> wrote:
> 2012/12/9 Ben Walton <bwalton at opencsw.org>:
>> Are there any objections to me wiping out www-mockup and placing my
>> work in progress on the new package browser there for public scrutiny
>
> No objections; I have played around with the layout there, so you
> might save a backup in case we want to use my modifications to the
> main page.
>
> Maciej
> _______________________________________________
> 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  Sun Dec  9 21:54:01 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 9 Dec 2012 20:54:01 +0000
Subject: [csw-maintainers] www-mockup
In-Reply-To: <50C46825.6000706@opencsw.org>
References: <CAP30j17-qEbziONnS+_ChBk7MTxhP=68e7ARQPHazYxK8WFxNA@mail.gmail.com>
	<CALtRa-6PK-vzkoT7=T9SaPcMmk0SjGoJuP8Lw1qOUC7=bzCNDg@mail.gmail.com>
	<50C46825.6000706@opencsw.org>
Message-ID: <CAP30j15+T8vS+N4ee3iGmPwKTC2MAuhAF_ihQ1fdtSSzsic6hw@mail.gmail.com>

I'm not sure where this is at.  I haven't heard anything about it for
a while now.

Thanks
-Ben

On Sun, Dec 9, 2012 at 10:29 AM, Juraj Lutter <wilbury at opencsw.org> wrote:
> On 12/09/2012 11:12 AM, Maciej (Matchek) Blizi?ski wrote:
>> 2012/12/9 Ben Walton <bwalton at opencsw.org>:
>>> Are there any objections to me wiping out www-mockup and placing my
>>> work in progress on the new package browser there for public scrutiny
>>
>> No objections; I have played around with the layout there, so you
>> might save a backup in case we want to use my modifications to the
>> main page.
>
> While we are at it, what is the current status of moving web to a zone
> that i've set up?
>
> IIRC, Yann has made some progress with it.
>
>
>
> --
> Juraj Lutter <wilbury at opencsw.org>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.

From guillomovitch at opencsw.org  Thu Dec 13 13:56:41 2012
From: guillomovitch at opencsw.org (Guillaume Rousse)
Date: Thu, 13 Dec 2012 13:56:41 +0100
Subject: [csw-maintainers] Cherry-picking unstable packages
In-Reply-To: <CALtRa-70H53OR3pOBnB8F_LFXSGsxhqSxzd26c9DV-uLB1usVA@mail.gmail.com>
References: <50B74E3B.9010503@opencsw.org>
	<CALtRa-70H53OR3pOBnB8F_LFXSGsxhqSxzd26c9DV-uLB1usVA@mail.gmail.com>
Message-ID: <50C9D089.5060802@opencsw.org>

Le 29/11/2012 15:02, Maciej (Matchek) Blizi?ski a ?crit :
> 4) switch to the kiel catalog
>
> The kiel catalog is now what dublin used to be - it gets periodic
> updates from the unstable catalog, so you're likely to avoid temporary
> problems when a package is uploaded, then detected as problematic, and
> fixed or rolled back. The kiel catalog will eventually become the
> testing catalog, but it's not at the moment, and will not until dublin
> becomes the stable catalog.
Thanks, we used this option.

Now, we just have to balance the interest of globally updating every 
already installed package from testing to kiel catalog, or just the ones 
required to install new additional packages. The second option is more 
conservative, but seems to be quite difficult to achieve with rsyslog, 
as it is a native package with more versionned dependencies on core 
libraries (libgcc and liblz1).

-- 
BOFH excuse #189:

SCSI's too wide.

From maciej at opencsw.org  Fri Dec 14 10:03:28 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 14 Dec 2012 09:03:28 +0000
Subject: [csw-maintainers] Cherry-picking unstable packages
In-Reply-To: <50C9D089.5060802@opencsw.org>
References: <50B74E3B.9010503@opencsw.org>
	<CALtRa-70H53OR3pOBnB8F_LFXSGsxhqSxzd26c9DV-uLB1usVA@mail.gmail.com>
	<50C9D089.5060802@opencsw.org>
Message-ID: <CALtRa-4vT2izL1DypDn3Z18Qayj=Grro0rsRUwu6w5gTikdPWg@mail.gmail.com>

2012/12/13 Guillaume Rousse <guillomovitch at opencsw.org>:
> Now, we just have to balance the interest of globally updating every already
> installed package from testing to kiel catalog,

The plan is that kiel will become the testing catalog some time in
2013. If your alternative plan is to stick with the testing catalog,
it will only make a temporal difference.

I wish we had killed the old stable half a year ago. If we did that,
we could have already promoted dublin to be the new stable and kiel
the new testing.

> or just the ones required to
> install new additional packages. The second option is more conservative, but
> seems to be quite difficult to achieve with rsyslog, as it is a native
> package with more versionned dependencies on core libraries (libgcc and
> liblz1).

We expect users to stick to one catalog and not mix packages. Of
course you're free to do what you want, but make sure you know what
you're doing and test your solution. Overall, I'd expect that sticking
to one catalog should be less overall hassle.

If you support many hosts, do you use any configuration management?

For instance, something along these lines:
http://www.andybotting.com/wordpress/using-pkgutil-on-solaris-with-puppet-for-easy-package-management

Maciej

From maciej at opencsw.org  Fri Dec 14 16:51:40 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 14 Dec 2012 15:51:40 +0000
Subject: [csw-maintainers] Let's delete the 'current' symlink
Message-ID: <CALtRa-4mtb4iHnn9BfrKwdodr2T_WeURFh3GgCwGbt44SiDmsg@mail.gmail.com>

We maintained it for backward compatibility. But I think in practice
it confuses people, they think there's a release (or a branch) called
'current', or that whatever is in there, is up to date. All of that is
not so, and maybe our users are better of without the symlink? I
propose that we delete it, or replace it with a stub like we did with
the 'stable' branch.

Maciej

From pfelecan at opencsw.org  Fri Dec 14 19:59:45 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Fri, 14 Dec 2012 19:59:45 +0100
Subject: [csw-maintainers] Let's delete the 'current' symlink
In-Reply-To: <CALtRa-4mtb4iHnn9BfrKwdodr2T_WeURFh3GgCwGbt44SiDmsg@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Fri,
	14 Dec 2012 15:51:40 +0000")
References: <CALtRa-4mtb4iHnn9BfrKwdodr2T_WeURFh3GgCwGbt44SiDmsg@mail.gmail.com>
Message-ID: <x6fw38zcgu.fsf@opencsw.org>

"Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> writes:

> We maintained it for backward compatibility. But I think in practice
> it confuses people, they think there's a release (or a branch) called
> 'current', or that whatever is in there, is up to date. All of that is
> not so, and maybe our users are better of without the symlink? I
> propose that we delete it, or replace it with a stub like we did with
> the 'stable' branch.

agreement++
-- 
Peter

From bwalton at opencsw.org  Fri Dec 14 20:01:49 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 14 Dec 2012 19:01:49 +0000
Subject: [csw-maintainers] Let's delete the 'current' symlink
In-Reply-To: <CALtRa-4mtb4iHnn9BfrKwdodr2T_WeURFh3GgCwGbt44SiDmsg@mail.gmail.com>
References: <CALtRa-4mtb4iHnn9BfrKwdodr2T_WeURFh3GgCwGbt44SiDmsg@mail.gmail.com>
Message-ID: <CAP30j16Z3=vgLJU_Mybk5XWDKyWhAf-KV+6O91HLkJx9Px=AaQ@mail.gmail.com>

Anything that makes it easier for the users to find the right catalog is
good. Like stable, I think a removal is the way to go here too.

Thanks
-Ben
On Dec 14, 2012 3:52 PM, "Maciej (Matchek) Blizi?ski" <maciej at opencsw.org>
wrote:

> We maintained it for backward compatibility. But I think in practice
> it confuses people, they think there's a release (or a branch) called
> 'current', or that whatever is in there, is up to date. All of that is
> not so, and maybe our users are better of without the symlink? I
> propose that we delete it, or replace it with a stub like we did with
> the 'stable' branch.
>
> Maciej
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20121214/d3ec7df2/attachment-0001.html>

From claudio at opencsw.org  Fri Dec 14 20:05:36 2012
From: claudio at opencsw.org (Claudio)
Date: Fri, 14 Dec 2012 20:05:36 +0100
Subject: [csw-maintainers] Let's delete the 'current' symlink
In-Reply-To: <CALtRa-4mtb4iHnn9BfrKwdodr2T_WeURFh3GgCwGbt44SiDmsg@mail.gmail.com>
References: <CALtRa-4mtb4iHnn9BfrKwdodr2T_WeURFh3GgCwGbt44SiDmsg@mail.gmail.com>
Message-ID: <50CB7880.4060103@opencsw.org>

On 14-12-12 16:51, Maciej (Matchek) Blizi?ski wrote:
> We maintained it for backward compatibility. But I think in practice
> it confuses people, they think there's a release (or a branch) called
> 'current', or that whatever is in there, is up to date. All of that is
> not so, and maybe our users are better of without the symlink? I
> propose that we delete it, or replace it with a stub like we did with
> the 'stable' branch.

"stable" being a mantra for servers and the way to go for releases (e.g.
Debian Stable: older, but stable, maintained and secured), the name is
really confusing. Similarly, UNIX admins and engineers are not too fond
on running things named testing, unstable or experimental on anything
besides a personal laptop or a "toy" server. I agree with Maciej.

C.

From claudio at opencsw.org  Fri Dec 14 23:10:10 2012
From: claudio at opencsw.org (Claudio)
Date: Fri, 14 Dec 2012 23:10:10 +0100
Subject: [csw-maintainers] mgar stripbin conflict
Message-ID: <50CBA3C2.7030104@opencsw.org>



When running mgar package after a successful build and test run, I get
an error at the end (gmake install went fine). I think it's a
meta-problem of the package in question (64-bit) setting up environment
values and the perl expected by the stripbin script. Hardcoding the
stripbin shebang to /opt/csw/bin/perl fixes the problem.


Original error:
gmake[1]: Leaving directory
`/home/claudio/opencsw/perl/trunk/work/solaris10-sparc/build-isa-sparcv9/perl-5.16.2'
gmake: Leaving directory
`/home/claudio/opencsw/perl/trunk/work/solaris10-sparc/build-isa-sparcv9/perl-5.16.2'
  ==> fixconfig:
/home/claudio/opencsw/perl/trunk/work/solaris10-sparc/install-isa-sparcv9/opt/csw/lib/64
  ==> fixconfig:
/home/claudio/opencsw/perl/trunk/work/solaris10-sparc/install-isa-sparcv9/opt/csw/bin/sparcv9
Can't locate strict.pm in @INC (@INC contains:
/opt/csw/lib/64/perl/site_perl /opt/csw/share/perl/site_perl
/opt/csw/lib/perl5/5.16.2/sun4-solaris-thread-multi-64
/opt/csw/lib/perl5/5.16.2 .) at
/home/claudio/opencsw/.buildsys/v2/gar/bin/stripbin line 16.
BEGIN failed--compilation aborted at
/home/claudio/opencsw/.buildsys/v2/gar/bin/stripbin line 16.
Can't locate strict.pm in @INC (@INC contains:
/opt/csw/lib/64/perl/site_perl /opt/csw/share/perl/site_perl
/opt/csw/lib/perl5/5.16.2/sun4-solaris-thread-multi-64
/opt/csw/lib/perl5/5.16.2 .) at
/home/claudio/opencsw/.buildsys/v2/gar/bin/stripbin line 16.
BEGIN failed--compilation aborted at
/home/claudio/opencsw/.buildsys/v2/gar/bin/stripbin line 16.
gmake[1]: *** [strip] Error 2
gmake[1]: Leaving directory `/home/claudio/opencsw/perl/trunk'
gmake: *** [merge-isa-sparcv9] Error 2


From maciej at opencsw.org  Mon Dec 17 14:30:40 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Mon, 17 Dec 2012 13:30:40 +0000
Subject: [csw-maintainers] OpenCSW packaging screencast
Message-ID: <CALtRa-6-hKc_dd4M0gkseeVgC5E9SM0iXSDak2a-r0EQOh0cwA@mail.gmail.com>

Hello maintainers,

I made a GAR setup tutorial / introductory packaging tutorial.

http://youtu.be/JWKCbPJSaxw

In about 35 minutes, I'm showing how to set up a freshly installed
Solaris 10 for building packages with GAR, and I build one small
package which requires a small modification to the recipe (because of
/bin/sh limitations).

I'm curious to hear your opinions, what you like about the video and
what you think could be improved. I plan to make a few more videos, so
I want to get all feedback I can.

If you like this screencast as is, we can start publishing it.

Maciej

From bwalton at opencsw.org  Mon Dec 17 21:49:54 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 17 Dec 2012 20:49:54 +0000
Subject: [csw-maintainers] OpenCSW packaging screencast
In-Reply-To: <CALtRa-6-hKc_dd4M0gkseeVgC5E9SM0iXSDak2a-r0EQOh0cwA@mail.gmail.com>
References: <CALtRa-6-hKc_dd4M0gkseeVgC5E9SM0iXSDak2a-r0EQOh0cwA@mail.gmail.com>
Message-ID: <CAP30j16_ToXYPoa2DCVy1X6pgwFVFEbM0_eJ9iaQv=nTU0nqHQ@mail.gmail.com>

This is very well done! It should be on the homepage (and in a relevant
stub page for posterity) if you haven't done that already.

Thanks
-Ben
On Dec 17, 2012 1:31 PM, "Maciej (Matchek) Blizi?ski" <maciej at opencsw.org>
wrote:

> Hello maintainers,
>
> I made a GAR setup tutorial / introductory packaging tutorial.
>
> http://youtu.be/JWKCbPJSaxw
>
> In about 35 minutes, I'm showing how to set up a freshly installed
> Solaris 10 for building packages with GAR, and I build one small
> package which requires a small modification to the recipe (because of
> /bin/sh limitations).
>
> I'm curious to hear your opinions, what you like about the video and
> what you think could be improved. I plan to make a few more videos, so
> I want to get all feedback I can.
>
> If you like this screencast as is, we can start publishing it.
>
> Maciej
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20121217/63f4dc81/attachment.html>

From maciej at opencsw.org  Tue Dec 18 10:16:57 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Tue, 18 Dec 2012 09:16:57 +0000
Subject: [csw-maintainers] OpenCSW packaging screencast
In-Reply-To: <CAP30j16_ToXYPoa2DCVy1X6pgwFVFEbM0_eJ9iaQv=nTU0nqHQ@mail.gmail.com>
References: <CALtRa-6-hKc_dd4M0gkseeVgC5E9SM0iXSDak2a-r0EQOh0cwA@mail.gmail.com>
	<CAP30j16_ToXYPoa2DCVy1X6pgwFVFEbM0_eJ9iaQv=nTU0nqHQ@mail.gmail.com>
Message-ID: <CALtRa-4SGTmG3m9AVgZA0GdpO+fhY_s58Zfchv-wMJh1hQ17Uw@mail.gmail.com>

2012/12/17 Ben Walton <bwalton at opencsw.org>:
> This is very well done! It should be on the homepage (and in a relevant stub
> page for posterity) if you haven't done that already.

I wanted to check with you guys first. If you think it's good to be
posted there, I'll be glad to do it!

From pfelecan at opencsw.org  Tue Dec 18 20:42:57 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 18 Dec 2012 20:42:57 +0100
Subject: [csw-maintainers] OpenCSW packaging screencast
In-Reply-To: <CALtRa-4SGTmG3m9AVgZA0GdpO+fhY_s58Zfchv-wMJh1hQ17Uw@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Tue,
	18 Dec 2012 09:16:57 +0000")
References: <CALtRa-6-hKc_dd4M0gkseeVgC5E9SM0iXSDak2a-r0EQOh0cwA@mail.gmail.com>
	<CAP30j16_ToXYPoa2DCVy1X6pgwFVFEbM0_eJ9iaQv=nTU0nqHQ@mail.gmail.com>
	<CALtRa-4SGTmG3m9AVgZA0GdpO+fhY_s58Zfchv-wMJh1hQ17Uw@mail.gmail.com>
Message-ID: <x638z3ywn2.fsf@opencsw.org>

"Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> writes:

> 2012/12/17 Ben Walton <bwalton at opencsw.org>:
>> This is very well done! It should be on the homepage (and in a relevant stub
>> page for posterity) if you haven't done that already.

goodness++
-- 
Peter

From claudio at opencsw.org  Wed Dec 19 10:39:18 2012
From: claudio at opencsw.org (Claudio)
Date: Wed, 19 Dec 2012 10:39:18 +0100
Subject: [csw-maintainers] User writable tree for local CSW-based software
Message-ID: <50D18B46.1000700@opencsw.org>

Hi,

There are cases when we will not supply the software and the user will
want to compile it himself using the CSW stack. This is a common case
for Perl modules (we can not supply all the 116002 of them, and you can
have modules out of CPAN). For that reason, Perl looks for this extra
user-supplied modules in a pre-difined originally empty directory.
Besides the new libs, man-pages and binaries are also placed there.

The Perl default (also used e.g. by Debian) is to use /usr/local for
this: /usr/local/bin, lib, share/man, etc. This is how I compiled the
Perl package. I had a talk with Dago, and we're unsure what to do in
this situation.

Do we mirror Debian and keep /usr/local? Advantage: known to UNIX users,
first place to look. Do we create a /opt/csw/local for a parallel tree
(lib, bin, share/man) to keep non-csw but related stuff ( (which won't
work without CSW libs/binaries) in our tree? /opt/local (I don't see
advantages to this one).

What do you think? Where do non-csw python eggs or ruby gems install?

C.

From Joerg.Schilling at fokus.fraunhofer.de  Wed Dec 19 12:00:36 2012
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Wed, 19 Dec 2012 12:00:36 +0100
Subject: [csw-maintainers] User writable tree for local CSW-based
	software
In-Reply-To: <50D18B46.1000700@opencsw.org>
References: <50D18B46.1000700@opencsw.org>
Message-ID: <50d19e54.sbFgCQtymbGegQ8n%Joerg.Schilling@fokus.fraunhofer.de>

Claudio <claudio at opencsw.org> wrote:

> The Perl default (also used e.g. by Debian) is to use /usr/local for
> this: /usr/local/bin, lib, share/man, etc. This is how I compiled the
> Perl package. I had a talk with Dago, and we're unsure what to do in
> this situation.

The UNIX vendors decided in 1988 already to abandon /usr/local 

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 maciej at opencsw.org  Wed Dec 19 13:07:29 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Wed, 19 Dec 2012 12:07:29 +0000
Subject: [csw-maintainers] OpenCSW packaging screencast
In-Reply-To: <x638z3ywn2.fsf@opencsw.org>
References: <CALtRa-6-hKc_dd4M0gkseeVgC5E9SM0iXSDak2a-r0EQOh0cwA@mail.gmail.com>
	<CAP30j16_ToXYPoa2DCVy1X6pgwFVFEbM0_eJ9iaQv=nTU0nqHQ@mail.gmail.com>
	<CALtRa-4SGTmG3m9AVgZA0GdpO+fhY_s58Zfchv-wMJh1hQ17Uw@mail.gmail.com>
	<x638z3ywn2.fsf@opencsw.org>
Message-ID: <CALtRa-4-LOEZE7hYBp3JFhzzWxxYc5NX6uDBxn4HpPVhyKNjGw@mail.gmail.com>

I made a new screencast, this time showing how to package a piece of
software which requires patching: http://youtu.be/Eq8S-futDho

From maciej at opencsw.org  Wed Dec 19 13:17:42 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Wed, 19 Dec 2012 12:17:42 +0000
Subject: [csw-maintainers] Screencast ideas
Message-ID: <CALtRa-4rfgz7qXBrJJfZYSR9jbN3thbtd03+7cYaR+1UYU=VAA@mail.gmail.com>

Hello maintainers,

I'm looking for new screencast ideas. So far, I've covered setting up
GAR on a build machine, and building a package that requires patching
the source code. I can make a couple more screencasts, but I need good
ideas. So far I've collected:

- splitting a package into libs, utils and header files
- modulations
- checkpkg database setup

What would be your picks and ideas? Are there things that you wish you
had learned earlier? Are there things you currently want to learn?

Maciej

From claudio at opencsw.org  Wed Dec 19 13:25:17 2012
From: claudio at opencsw.org (Claudio)
Date: Wed, 19 Dec 2012 13:25:17 +0100
Subject: [csw-maintainers] User writable tree for local CSW-based
	software
In-Reply-To: <50d19e54.sbFgCQtymbGegQ8n%Joerg.Schilling@fokus.fraunhofer.de>
References: <50D18B46.1000700@opencsw.org>
	<50d19e54.sbFgCQtymbGegQ8n%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <CAJ2-jQnhw1NXk-GwO1hvAZ99d5YC55fbJ3xNkh-baY2v88ZWsA@mail.gmail.com>

J?rg,

Is a parallel tree in /opt/csw/local a valid alternative for you?

C.


On Wed, Dec 19, 2012 at 12:00 PM, Joerg Schilling <
Joerg.Schilling at fokus.fraunhofer.de> wrote:

> Claudio <claudio at opencsw.org> wrote:
>
> > The Perl default (also used e.g. by Debian) is to use /usr/local for
> > this: /usr/local/bin, lib, share/man, etc. This is how I compiled the
> > Perl package. I had a talk with Dago, and we're unsure what to do in
> > this situation.
>
> The UNIX vendors decided in 1988 already to abandon /usr/local
>
> 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
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20121219/2f5c1a9e/attachment.html>

From maciej at opencsw.org  Sat Dec 22 23:01:18 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sat, 22 Dec 2012 22:01:18 +0000
Subject: [csw-maintainers] Solaris 8 packages in named releases
Message-ID: <CALtRa-6HqZ95fCAnMLZZHoARCutM_OEiZMECW8h8+wgtYsLU+g@mail.gmail.com>

Hello maintainers,

We are no longer building for Solaris 8, but we're still dragging along the
last Solaris 8 snapshot. It's present in the dublin release as well as in
kiel. I propose that we keep the Solaris 8 packages in dublin, but we drop
them from kiel.

The reason is that if we tell the world ?hello world, we made a new
release!?, and there is a whole bunch of Solaris 8 packages, it will look
like as if we have done something in the Solaris 8 area, while we wouldn't
actually have. If, on the other hand, there is no "5.8" directory, it will
be obvious to users that they have to use an older release to get the
Solaris 8 packages. This should help people set the right expectations.

Thoughts?

Maciej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20121222/640ec105/attachment.html>

From claudio at opencsw.org  Sat Dec 22 23:05:37 2012
From: claudio at opencsw.org (Claudio)
Date: Sat, 22 Dec 2012 23:05:37 +0100
Subject: [csw-maintainers] Solaris 8 packages in named releases
In-Reply-To: <CALtRa-6HqZ95fCAnMLZZHoARCutM_OEiZMECW8h8+wgtYsLU+g@mail.gmail.com>
References: <CALtRa-6HqZ95fCAnMLZZHoARCutM_OEiZMECW8h8+wgtYsLU+g@mail.gmail.com>
Message-ID: <50D62EB1.8030106@opencsw.org>

On 22-12-12 23:01, Maciej (Matchek) Blizi?ski wrote:
-cut--
> The reason is that if we tell the world ?hello world, we made a new
> release!?, and there is a whole bunch of Solaris 8 packages, it will
> look like as if we have done something in the Solaris 8 area, while we
> wouldn't actually have.
--cut--

Also, security-wise I wouldn't be too fond to offer packages with
probably known (upstream) security problems.

C.


From pfelecan at opencsw.org  Sun Dec 23 10:47:29 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sun, 23 Dec 2012 10:47:29 +0100
Subject: [csw-maintainers] User writable tree for local CSW-based
	software
In-Reply-To: <50D18B46.1000700@opencsw.org> (claudio@opencsw.org's message of
	"Wed, 19 Dec 2012 10:39:18 +0100")
References: <50D18B46.1000700@opencsw.org>
Message-ID: <x6y5gpxfpq.fsf@opencsw.org>

Claudio <claudio at opencsw.org> writes:

> Do we mirror Debian and keep /usr/local? Advantage: known to UNIX users,
> first place to look. Do we create a /opt/csw/local for a parallel tree
> (lib, bin, share/man) to keep non-csw but related stuff ( (which won't
> work without CSW libs/binaries) in our tree? /opt/local (I don't see
> advantages to this one).
>
> What do you think? [...]

/opt/csw/local seems an orthogonal choice (viz. /usr/bin is /opt/csw/bin)

-- 
Peter

From pfelecan at opencsw.org  Sun Dec 23 10:48:36 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sun, 23 Dec 2012 10:48:36 +0100
Subject: [csw-maintainers] Screencast ideas
In-Reply-To: <CALtRa-4rfgz7qXBrJJfZYSR9jbN3thbtd03+7cYaR+1UYU=VAA@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed,
	19 Dec 2012 12:17:42 +0000")
References: <CALtRa-4rfgz7qXBrJJfZYSR9jbN3thbtd03+7cYaR+1UYU=VAA@mail.gmail.com>
Message-ID: <x6txrdxfnv.fsf@opencsw.org>

"Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> writes:

> Hello maintainers,
>
> I'm looking for new screencast ideas. So far, I've covered setting up
> GAR on a build machine, and building a package that requires patching
> the source code. I can make a couple more screencasts, but I need good
> ideas. So far I've collected:
>
> - splitting a package into libs, utils and header files
> - modulations
> - checkpkg database setup
>
> What would be your picks and ideas? Are there things that you wish you
> had learned earlier? Are there things you currently want to learn?

How to set up a build farm ?
-- 
Peter

From pfelecan at opencsw.org  Sun Dec 23 10:50:18 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sun, 23 Dec 2012 10:50:18 +0100
Subject: [csw-maintainers] Solaris 8 packages in named releases
In-Reply-To: <CALtRa-6HqZ95fCAnMLZZHoARCutM_OEiZMECW8h8+wgtYsLU+g@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat,
	22 Dec 2012 22:01:18 +0000")
References: <CALtRa-6HqZ95fCAnMLZZHoARCutM_OEiZMECW8h8+wgtYsLU+g@mail.gmail.com>
Message-ID: <x6pq21xfl1.fsf@opencsw.org>

"Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> writes:

> Hello maintainers,
>
> We are no longer building for Solaris 8, but we're still dragging along the
> last Solaris 8 snapshot. It's present in the dublin release as well as in
> kiel. I propose that we keep the Solaris 8 packages in dublin, but we drop
> them from kiel.
>
> The reason is that if we tell the world ?hello world, we made a new
> release!?, and there is a whole bunch of Solaris 8 packages, it will look
> like as if we have done something in the Solaris 8 area, while we wouldn't
> actually have. If, on the other hand, there is no "5.8" directory, it will
> be obvious to users that they have to use an older release to get the
> Solaris 8 packages. This should help people set the right expectations.
>
> Thoughts?

Drop 5.8 from Kiel and plan for removal of 5.9 in Bratislava.
-- 
Peter

From bonivart at opencsw.org  Sun Dec 23 12:04:27 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 23 Dec 2012 12:04:27 +0100
Subject: [csw-maintainers] Solaris 8 packages in named releases
In-Reply-To: <x6pq21xfl1.fsf@opencsw.org>
References: <CALtRa-6HqZ95fCAnMLZZHoARCutM_OEiZMECW8h8+wgtYsLU+g@mail.gmail.com>
	<x6pq21xfl1.fsf@opencsw.org>
Message-ID: <CABY0g1WtreL0e_MxmW0s+2qb8BnznZ7Ttqtqy-9CPNYirUJLhg@mail.gmail.com>

On Sunday, December 23, 2012, Peter FELECAN wrote:
>
>
> Drop 5.8 from Kiel and plan for removal of 5.9 in Bratislava.
>

+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20121223/1c625e70/attachment.html>

From maciej at opencsw.org  Sun Dec 23 12:22:17 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 23 Dec 2012 11:22:17 +0000
Subject: [csw-maintainers] Screencast ideas
In-Reply-To: <x6txrdxfnv.fsf@opencsw.org>
References: <CALtRa-4rfgz7qXBrJJfZYSR9jbN3thbtd03+7cYaR+1UYU=VAA@mail.gmail.com>
	<x6txrdxfnv.fsf@opencsw.org>
Message-ID: <CALtRa-6VU-t1ckhOM1qK-t2PHfbn2xMKcke3sFUZSo_NrVJZMg@mail.gmail.com>

2012/12/23 Peter FELECAN <pfelecan at opencsw.org>
>
> How to set up a build farm ?

There is a couple of aspects to a build farm. I can cover the checkpkg
database. There are aspects of the OS setup that Dago and others might
know about. Some examples would be running different OS releases in
different zones, sharing the file system, and writing system-wide
garrc.

From claudio at opencsw.org  Sun Dec 23 12:26:24 2012
From: claudio at opencsw.org (Claudio)
Date: Sun, 23 Dec 2012 12:26:24 +0100
Subject: [csw-maintainers] Screencast ideas
In-Reply-To: <CALtRa-6VU-t1ckhOM1qK-t2PHfbn2xMKcke3sFUZSo_NrVJZMg@mail.gmail.com>
References: <CALtRa-4rfgz7qXBrJJfZYSR9jbN3thbtd03+7cYaR+1UYU=VAA@mail.gmail.com>
	<x6txrdxfnv.fsf@opencsw.org>
	<CALtRa-6VU-t1ckhOM1qK-t2PHfbn2xMKcke3sFUZSo_NrVJZMg@mail.gmail.com>
Message-ID: <50D6EA60.2080404@opencsw.org>

On 23-12-12 12:22, Maciej (Matchek) Blizi?ski wrote:
> 2012/12/23 Peter FELECAN <pfelecan at opencsw.org>
>>
>> How to set up a build farm ?
> 
> There is a couple of aspects to a build farm. I can cover the checkpkg
> database. There are aspects of the OS setup that Dago and others might
> know about. Some examples would be running different OS releases in
> different zones, sharing the file system, and writing system-wide
> garrc.

What about a *minimalist* build farm? The minimum needed to created one?

C



From maciej at opencsw.org  Sun Dec 23 13:00:46 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 23 Dec 2012 12:00:46 +0000
Subject: [csw-maintainers] Screencast ideas
In-Reply-To: <50D6EA60.2080404@opencsw.org>
References: <CALtRa-4rfgz7qXBrJJfZYSR9jbN3thbtd03+7cYaR+1UYU=VAA@mail.gmail.com>
	<x6txrdxfnv.fsf@opencsw.org>
	<CALtRa-6VU-t1ckhOM1qK-t2PHfbn2xMKcke3sFUZSo_NrVJZMg@mail.gmail.com>
	<50D6EA60.2080404@opencsw.org>
Message-ID: <CALtRa-6UdV9Qu8jjXhErGptKdnbSa4kK9+Dhj3sNiAKBWmPFPg@mail.gmail.com>

2012/12/23 Claudio <claudio at opencsw.org>:
> What about a *minimalist* build farm? The minimum needed to created one?

You would need to define what do you need to call it a build farm.

- want to build a package? You need to set up GAR.
- want to contribute to the OpenCSW repository? You need to check out
the recipes.
- want to check your packages for errors? You need to create a shared database.
- want to be able to run 'mgar platforms'? You need do additional
setup that Dago knows about.
- want to automatically sign catalogs? You need to set up Ben's
catalog signing daemon.

There's probably more.

From pfelecan at opencsw.org  Sun Dec 23 13:43:20 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sun, 23 Dec 2012 13:43:20 +0100
Subject: [csw-maintainers] Screencast ideas
In-Reply-To: <CALtRa-6UdV9Qu8jjXhErGptKdnbSa4kK9+Dhj3sNiAKBWmPFPg@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun,
	23 Dec 2012 12:00:46 +0000")
References: <CALtRa-4rfgz7qXBrJJfZYSR9jbN3thbtd03+7cYaR+1UYU=VAA@mail.gmail.com>
	<x6txrdxfnv.fsf@opencsw.org>
	<CALtRa-6VU-t1ckhOM1qK-t2PHfbn2xMKcke3sFUZSo_NrVJZMg@mail.gmail.com>
	<50D6EA60.2080404@opencsw.org>
	<CALtRa-6UdV9Qu8jjXhErGptKdnbSa4kK9+Dhj3sNiAKBWmPFPg@mail.gmail.com>
Message-ID: <x6licpx7kn.fsf@opencsw.org>

"Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> writes:

> 2012/12/23 Claudio <claudio at opencsw.org>:
>> What about a *minimalist* build farm? The minimum needed to created one?
>
> You would need to define what do you need to call it a build farm.
>
> - want to build a package? You need to set up GAR.
> - want to contribute to the OpenCSW repository? You need to check out
> the recipes.
> - want to check your packages for errors? You need to create a shared database.
> - want to be able to run 'mgar platforms'? You need do additional
> setup that Dago knows about.
> - want to automatically sign catalogs? You need to set up Ben's
> catalog signing daemon.

Beside the last one I think that you have the complete definition for
the season. The previous 2, counting from the end, are the most
interesting from my point of view.
-- 
Peter

From wilbury at opencsw.org  Sun Dec 23 13:45:35 2012
From: wilbury at opencsw.org (Juraj Lutter)
Date: Sun, 23 Dec 2012 13:45:35 +0100
Subject: [csw-maintainers] Solaris 8 packages in named releases
In-Reply-To: <CABY0g1WtreL0e_MxmW0s+2qb8BnznZ7Ttqtqy-9CPNYirUJLhg@mail.gmail.com>
References: <CALtRa-6HqZ95fCAnMLZZHoARCutM_OEiZMECW8h8+wgtYsLU+g@mail.gmail.com>
	<x6pq21xfl1.fsf@opencsw.org>
	<CABY0g1WtreL0e_MxmW0s+2qb8BnznZ7Ttqtqy-9CPNYirUJLhg@mail.gmail.com>
Message-ID: <50D6FCEF.70508@opencsw.org>

On 12/23/2012 12:04 PM, Peter Bonivart wrote:
> On Sunday, December 23, 2012, Peter FELECAN wrote:
> 
> 
>     Drop 5.8 from Kiel and plan for removal of 5.9 in Bratislava.
> 
> 
> +1 

Same here.



-- 
Juraj Lutter <wilbury at opencsw.org>

From maciej at opencsw.org  Wed Dec 26 10:26:55 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Wed, 26 Dec 2012 09:26:55 +0000
Subject: [csw-maintainers] Solaris 8 packages in named releases
In-Reply-To: <50D6FCEF.70508@opencsw.org>
References: <CALtRa-6HqZ95fCAnMLZZHoARCutM_OEiZMECW8h8+wgtYsLU+g@mail.gmail.com>
	<x6pq21xfl1.fsf@opencsw.org>
	<CABY0g1WtreL0e_MxmW0s+2qb8BnznZ7Ttqtqy-9CPNYirUJLhg@mail.gmail.com>
	<50D6FCEF.70508@opencsw.org>
Message-ID: <CALtRa-4V2RSMMaMZZR-tjeO8OaVV8x1G9bSpRzqQ2r0gtJftmA@mail.gmail.com>

This is now done. I dropped all Solaris 8 packages from the unstable
catalog, and integrated the change into kiel, so both keil and
unstable are now free from Solaris 8 packages.

http://buildfarm.opencsw.org/pkgdb/catalogs/unstable-sparc-SunOS5.8/
http://buildfarm.opencsw.org/pkgdb/catalogs/unstable-i386-SunOS5.8/

I also updated the README file on the mirror site, removing a
reference to the 'current' catalog. In the 'current' directory is now
empty, except for information that this now a dead catalog.

http://mirror.opencsw.org/opencsw/current/

I also updated the 'Release branches' page, shortening it and adding
the current recommendations.
http://www.opencsw.org/get-it/releases/

One complicating factor is that 'dublin' should currently be the
'stable' catalog, but it isn't. So for productions systems, we need to
recommend subscribing to it as to a named release.

The 'releases' directory has not been updated for a long time now.

http://mirror.opencsw.org/opencsw/releases/stable/

Maintainers, how do you feel about it, is it helping, or is it adding
to confusion?

Maciej

From bonivart at opencsw.org  Fri Dec 28 16:33:26 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Fri, 28 Dec 2012 16:33:26 +0100
Subject: [csw-maintainers] Catalog generation broken?
Message-ID: <CABY0g1UKs2Ee5sYev_EipizqwsuyLAm4LJOfZqeYZq66YM0EdQ@mail.gmail.com>

Yesterday I uploaded some packages (Bind and Sendmail) to unstable but
I haven't received the normal e-mail notification about it and sure
enough there's nothing new on the mirrors either. But they are gone
from their respective experimental folders which usually means they
have been pushed.

Can someone take a look?

bonivart at login[bind]$ csw-upload-pkg *
Processing 9 file(s). Please wait.
Uploading 'bind-9.9.2P1,REV=2012.12.27-SunOS5.10-i386-CSW.pkg.gz'
Uploading 'bind-9.9.2P1,REV=2012.12.27-SunOS5.10-sparc-CSW.pkg.gz'
Uploading 'bind_chroot-9.9.2P1,REV=2012.12.27-SunOS5.10-all-CSW.pkg.gz'
Uploading 'bind_dev-9.9.2P1,REV=2012.12.27-SunOS5.10-i386-CSW.pkg.gz'
Uploading 'bind_dev-9.9.2P1,REV=2012.12.27-SunOS5.10-sparc-CSW.pkg.gz'
Uploading 'bind_utils-9.9.2P1,REV=2012.12.27-SunOS5.10-i386-CSW.pkg.gz'
Uploading 'bind_utils-9.9.2P1,REV=2012.12.27-SunOS5.10-sparc-CSW.pkg.gz'
Uploading 'libbind-9.9.2P1,REV=2012.12.27-SunOS5.10-i386-CSW.pkg.gz'
Uploading 'libbind-9.9.2P1,REV=2012.12.27-SunOS5.10-sparc-CSW.pkg.gz'
Checking 5 package(s) against catalog unstable i386 SunOS5.10
Checking 5 package(s) against catalog unstable sparc SunOS5.10
Checking 5 package(s) against catalog unstable i386 SunOS5.11
Checking 5 package(s) against catalog unstable sparc SunOS5.11
All checks successful. Proceeding.
Inserting bind (i386 SunOS5.10) into catalog unstable i386 SunOS5.10
Inserting bind_chroot (all SunOS5.10) into catalog unstable i386 SunOS5.10
Inserting bind_dev (i386 SunOS5.10) into catalog unstable i386 SunOS5.10
Inserting bind_utils (i386 SunOS5.10) into catalog unstable i386 SunOS5.10
Inserting libbind (i386 SunOS5.10) into catalog unstable i386 SunOS5.10
Inserting bind (i386 SunOS5.10) into catalog unstable i386 SunOS5.11
Inserting bind_chroot (all SunOS5.10) into catalog unstable i386 SunOS5.11
Inserting bind_dev (i386 SunOS5.10) into catalog unstable i386 SunOS5.11
Inserting bind_utils (i386 SunOS5.10) into catalog unstable i386 SunOS5.11
Inserting libbind (i386 SunOS5.10) into catalog unstable i386 SunOS5.11
Inserting bind (sparc SunOS5.10) into catalog unstable sparc SunOS5.10
Inserting bind_chroot (all SunOS5.10) into catalog unstable sparc SunOS5.10
Inserting bind_dev (sparc SunOS5.10) into catalog unstable sparc SunOS5.10
Inserting bind_utils (sparc SunOS5.10) into catalog unstable sparc SunOS5.10
Inserting libbind (sparc SunOS5.10) into catalog unstable sparc SunOS5.10
Inserting bind (sparc SunOS5.10) into catalog unstable sparc SunOS5.11
Inserting bind_chroot (all SunOS5.10) into catalog unstable sparc SunOS5.11
Inserting bind_dev (sparc SunOS5.10) into catalog unstable sparc SunOS5.11
Inserting bind_utils (sparc SunOS5.10) into catalog unstable sparc SunOS5.11
Inserting libbind (sparc SunOS5.10) into catalog unstable sparc SunOS5.11
bonivart at login[bind]$ cd ../sendmail/
bonivart at login[sendmail]$ csw-upload-pkg *
Processing 5 file(s). Please wait.
Uploading 'libmilter-8.14.6,REV=2012.12.27-SunOS5.10-i386-CSW.pkg.gz'
Uploading 'libmilter-8.14.6,REV=2012.12.27-SunOS5.10-sparc-CSW.pkg.gz'
Uploading 'sendmail-8.14.6,REV=2012.12.27-SunOS5.10-i386-CSW.pkg.gz'
Uploading 'sendmail-8.14.6,REV=2012.12.27-SunOS5.10-sparc-CSW.pkg.gz'
Uploading 'sendmail_contrib-8.14.6,REV=2012.12.27-SunOS5.10-all-CSW.pkg.gz'
Checking 3 package(s) against catalog unstable i386 SunOS5.10
Checking 3 package(s) against catalog unstable sparc SunOS5.10
Checking 3 package(s) against catalog unstable i386 SunOS5.11
Checking 3 package(s) against catalog unstable sparc SunOS5.11
All checks successful. Proceeding.
Inserting libmilter (i386 SunOS5.10) into catalog unstable i386 SunOS5.10
Inserting sendmail (i386 SunOS5.10) into catalog unstable i386 SunOS5.10
Inserting sendmail_contrib (all SunOS5.10) into catalog unstable i386 SunOS5.10
Inserting libmilter (i386 SunOS5.10) into catalog unstable i386 SunOS5.11
Inserting sendmail (i386 SunOS5.10) into catalog unstable i386 SunOS5.11
Inserting sendmail_contrib (all SunOS5.10) into catalog unstable i386 SunOS5.11
Inserting libmilter (sparc SunOS5.10) into catalog unstable sparc SunOS5.10
Inserting sendmail (sparc SunOS5.10) into catalog unstable sparc SunOS5.10
Inserting sendmail_contrib (all SunOS5.10) into catalog unstable sparc SunOS5.10
Inserting libmilter (sparc SunOS5.10) into catalog unstable sparc SunOS5.11
Inserting sendmail (sparc SunOS5.10) into catalog unstable sparc SunOS5.11
Inserting sendmail_contrib (all SunOS5.10) into catalog unstable sparc SunOS5.11
bonivart at login[sendmail]$

/peter

From maciej at opencsw.org  Fri Dec 28 16:41:39 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 28 Dec 2012 15:41:39 +0000
Subject: [csw-maintainers] Catalog generation broken?
In-Reply-To: <CABY0g1UKs2Ee5sYev_EipizqwsuyLAm4LJOfZqeYZq66YM0EdQ@mail.gmail.com>
References: <CABY0g1UKs2Ee5sYev_EipizqwsuyLAm4LJOfZqeYZq66YM0EdQ@mail.gmail.com>
Message-ID: <CALtRa-6xdSsS4b6aKRNxYfp4oRfMJ=nxEhkZ8fFmJ-swChDKgQ@mail.gmail.com>

2012/12/28 Peter Bonivart <bonivart at opencsw.org>:
> Can someone take a look?

There was a stale lock. I'm running generation in foreground to see if
it's all right.

From maciej at opencsw.org  Fri Dec 28 17:35:16 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 28 Dec 2012 16:35:16 +0000
Subject: [csw-maintainers] Catalog generation broken?
In-Reply-To: <CALtRa-6xdSsS4b6aKRNxYfp4oRfMJ=nxEhkZ8fFmJ-swChDKgQ@mail.gmail.com>
References: <CABY0g1UKs2Ee5sYev_EipizqwsuyLAm4LJOfZqeYZq66YM0EdQ@mail.gmail.com>
	<CALtRa-6xdSsS4b6aKRNxYfp4oRfMJ=nxEhkZ8fFmJ-swChDKgQ@mail.gmail.com>
Message-ID: <CALtRa-5rAbKg72OpWDLzgARmOw5uorQ+EzLCWqkgMG1w_ikW1Q@mail.gmail.com>

2012/12/28 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
> There was a stale lock. I'm running generation in foreground to see if
> it's all right.

It's broken, and it's me who broke it. I'm fixing it now.

From bwalton at opencsw.org  Sat Dec 29 10:51:39 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 29 Dec 2012 09:51:39 +0000
Subject: [csw-maintainers] Solaris 8 packages in named releases
In-Reply-To: <CALtRa-4V2RSMMaMZZR-tjeO8OaVV8x1G9bSpRzqQ2r0gtJftmA@mail.gmail.com>
References: <CALtRa-6HqZ95fCAnMLZZHoARCutM_OEiZMECW8h8+wgtYsLU+g@mail.gmail.com>
	<x6pq21xfl1.fsf@opencsw.org>
	<CABY0g1WtreL0e_MxmW0s+2qb8BnznZ7Ttqtqy-9CPNYirUJLhg@mail.gmail.com>
	<50D6FCEF.70508@opencsw.org>
	<CALtRa-4V2RSMMaMZZR-tjeO8OaVV8x1G9bSpRzqQ2r0gtJftmA@mail.gmail.com>
Message-ID: <CAP30j15g+QmiWxYD2bwq6cSe_p=KE4AnVki9-C39DwiZRJnSdQ@mail.gmail.com>

On Wed, Dec 26, 2012 at 9:26 AM, Maciej (Matchek) Blizi?ski
<maciej at opencsw.org> wrote:
> Maintainers, how do you feel about it, is it helping, or is it adding
> to confusion?

No, I think it is now clearer.  Also, subscribing to named releases
instead of an alias is likely a good thing in the long run.  We are
free to introduce fairly radical changes between, say, Dublin and
Kiel, so having one suddenly replace the other because of subscription
to an aliased catalog isn't what we want.

A very simple addition to pkgutil will make moving to a new release
more obvious:

1. Look for $catalog_url/UPGRADE_AVAILABLE (name is for discussion
purposes, not a real proposal).
2. If found, display with pause before doing new package actions.

So, when we're ready to have people move from Dublin to the next
release, we place this file and pkgutil will now tell people that
there is a newer catalog they should subscribe to.  We can use this
file to point of some of the major differences between releases or
other things that have the potential to cause aggravation at the local
site.

I'll code the pkgutil bits if this is deemed a worthwhile approach.

Thanks
-Ben

From bonivart at opencsw.org  Sat Dec 29 11:24:28 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sat, 29 Dec 2012 11:24:28 +0100
Subject: [csw-maintainers] Catalog generation broken?
In-Reply-To: <CALtRa-5rAbKg72OpWDLzgARmOw5uorQ+EzLCWqkgMG1w_ikW1Q@mail.gmail.com>
References: <CABY0g1UKs2Ee5sYev_EipizqwsuyLAm4LJOfZqeYZq66YM0EdQ@mail.gmail.com>
	<CALtRa-6xdSsS4b6aKRNxYfp4oRfMJ=nxEhkZ8fFmJ-swChDKgQ@mail.gmail.com>
	<CALtRa-5rAbKg72OpWDLzgARmOw5uorQ+EzLCWqkgMG1w_ikW1Q@mail.gmail.com>
Message-ID: <CABY0g1VtubDFneZ92NwK5SOKugLWjVtjnJ3xY+WrwVx+eqhGRw@mail.gmail.com>

On Fri, Dec 28, 2012 at 5:35 PM, Maciej (Matchek) Blizi?ski
<maciej at opencsw.org> wrote:
> 2012/12/28 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
>> There was a stale lock. I'm running generation in foreground to see if
>> it's all right.
>
> It's broken, and it's me who broke it. I'm fixing it now.

I now got the notification but there's a minor problem on the mirrors,
the old packages were not removed, e.g.:

sendmail-8.14.5,REV=2012.06.07-SunOS5.9-i386-CSW.pkg.gz 2012-Jun-07
14:46:01 982.0K application/x-gzip
sendmail-8.14.6,REV=2012.12.27-SunOS5.10-i386-CSW.pkg.gz 2012-Dec-27
22:04:38 991.8K application/x-gzip
sendmail_contrib-8.14.5,REV=2012.06.07-SunOS5.9-all-CSW.pkg.gz
2012-Jun-07 14:46:08 72.3K application/x-gzip
sendmail_contrib-8.14.6,REV=2012.12.27-SunOS5.10-all-CSW.pkg.gz
2012-Dec-27 22:04:41 72.7K application/x-gzip

/peter

From maciej at opencsw.org  Sat Dec 29 11:35:46 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sat, 29 Dec 2012 10:35:46 +0000
Subject: [csw-maintainers] Catalog generation broken?
In-Reply-To: <CABY0g1VtubDFneZ92NwK5SOKugLWjVtjnJ3xY+WrwVx+eqhGRw@mail.gmail.com>
References: <CABY0g1UKs2Ee5sYev_EipizqwsuyLAm4LJOfZqeYZq66YM0EdQ@mail.gmail.com>
	<CALtRa-6xdSsS4b6aKRNxYfp4oRfMJ=nxEhkZ8fFmJ-swChDKgQ@mail.gmail.com>
	<CALtRa-5rAbKg72OpWDLzgARmOw5uorQ+EzLCWqkgMG1w_ikW1Q@mail.gmail.com>
	<CABY0g1VtubDFneZ92NwK5SOKugLWjVtjnJ3xY+WrwVx+eqhGRw@mail.gmail.com>
Message-ID: <CALtRa-79FYiytYfNEyiNetoeuKY-RpeMsnaGG-f61aWgbUopOg@mail.gmail.com>

2012/12/29 Peter Bonivart <bonivart at opencsw.org>:
> I now got the notification but there's a minor problem on the mirrors,
> the old packages were not removed, e.g.:
>
> sendmail-8.14.5,REV=2012.06.07-SunOS5.9-i386-CSW.pkg.gz 2012-Jun-07
> 14:46:01 982.0K application/x-gzip

I'm still working on it, but ? they were not removed from where? I'm
not sure where you pasted this from, could you give the URL?

From bonivart at opencsw.org  Sat Dec 29 11:38:29 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sat, 29 Dec 2012 11:38:29 +0100
Subject: [csw-maintainers] Catalog generation broken?
In-Reply-To: <CALtRa-79FYiytYfNEyiNetoeuKY-RpeMsnaGG-f61aWgbUopOg@mail.gmail.com>
References: <CABY0g1UKs2Ee5sYev_EipizqwsuyLAm4LJOfZqeYZq66YM0EdQ@mail.gmail.com>
	<CALtRa-6xdSsS4b6aKRNxYfp4oRfMJ=nxEhkZ8fFmJ-swChDKgQ@mail.gmail.com>
	<CALtRa-5rAbKg72OpWDLzgARmOw5uorQ+EzLCWqkgMG1w_ikW1Q@mail.gmail.com>
	<CABY0g1VtubDFneZ92NwK5SOKugLWjVtjnJ3xY+WrwVx+eqhGRw@mail.gmail.com>
	<CALtRa-79FYiytYfNEyiNetoeuKY-RpeMsnaGG-f61aWgbUopOg@mail.gmail.com>
Message-ID: <CABY0g1Un67f80RdGqEGiWrfEAUmQKiWLMOHkmXFHk6LSPJ99qg@mail.gmail.com>

On Sat, Dec 29, 2012 at 11:35 AM, Maciej (Matchek) Blizi?ski
<maciej at opencsw.org> wrote:
> 2012/12/29 Peter Bonivart <bonivart at opencsw.org>:
>> I now got the notification but there's a minor problem on the mirrors,
>> the old packages were not removed, e.g.:
>>
>> sendmail-8.14.5,REV=2012.06.07-SunOS5.9-i386-CSW.pkg.gz 2012-Jun-07
>> 14:46:01 982.0K application/x-gzip
>
> I'm still working on it, but ? they were not removed from where? I'm
> not sure where you pasted this from, could you give the URL?

This was from http://mirror.opencsw.org/opencsw/unstable/i386/5.10/.

/peter

From maciej at opencsw.org  Sat Dec 29 11:45:19 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sat, 29 Dec 2012 10:45:19 +0000
Subject: [csw-maintainers] Catalog generation broken?
In-Reply-To: <CABY0g1Un67f80RdGqEGiWrfEAUmQKiWLMOHkmXFHk6LSPJ99qg@mail.gmail.com>
References: <CABY0g1UKs2Ee5sYev_EipizqwsuyLAm4LJOfZqeYZq66YM0EdQ@mail.gmail.com>
	<CALtRa-6xdSsS4b6aKRNxYfp4oRfMJ=nxEhkZ8fFmJ-swChDKgQ@mail.gmail.com>
	<CALtRa-5rAbKg72OpWDLzgARmOw5uorQ+EzLCWqkgMG1w_ikW1Q@mail.gmail.com>
	<CABY0g1VtubDFneZ92NwK5SOKugLWjVtjnJ3xY+WrwVx+eqhGRw@mail.gmail.com>
	<CALtRa-79FYiytYfNEyiNetoeuKY-RpeMsnaGG-f61aWgbUopOg@mail.gmail.com>
	<CABY0g1Un67f80RdGqEGiWrfEAUmQKiWLMOHkmXFHk6LSPJ99qg@mail.gmail.com>
Message-ID: <CALtRa-7WkwdbviEgumrBYJ7KCxqzE2CiLvi-W9N=T_r1-ycsNA@mail.gmail.com>

2012/12/29 Peter Bonivart <bonivart at opencsw.org>:
> On Sat, Dec 29, 2012 at 11:35 AM, Maciej (Matchek) Blizi?ski
> <maciej at opencsw.org> wrote:
>> 2012/12/29 Peter Bonivart <bonivart at opencsw.org>:
>>> I now got the notification but there's a minor problem on the mirrors,
>>> the old packages were not removed, e.g.:
>>>
>>> sendmail-8.14.5,REV=2012.06.07-SunOS5.9-i386-CSW.pkg.gz 2012-Jun-07
>>> 14:46:01 982.0K application/x-gzip
>>
>> I'm still working on it, but ? they were not removed from where? I'm
>> not sure where you pasted this from, could you give the URL?
>
> This was from http://mirror.opencsw.org/opencsw/unstable/i386/5.10/.

My guess is that rsync was run with the --delete-after option. It was
uploading new files first, and only then deleting the old ones; you
looked while it was still working.

From maciej at opencsw.org  Sat Dec 29 14:38:13 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sat, 29 Dec 2012 13:38:13 +0000
Subject: [csw-maintainers] Solaris 8 packages in named releases
In-Reply-To: <CAP30j15g+QmiWxYD2bwq6cSe_p=KE4AnVki9-C39DwiZRJnSdQ@mail.gmail.com>
References: <CALtRa-6HqZ95fCAnMLZZHoARCutM_OEiZMECW8h8+wgtYsLU+g@mail.gmail.com>
	<x6pq21xfl1.fsf@opencsw.org>
	<CABY0g1WtreL0e_MxmW0s+2qb8BnznZ7Ttqtqy-9CPNYirUJLhg@mail.gmail.com>
	<50D6FCEF.70508@opencsw.org>
	<CALtRa-4V2RSMMaMZZR-tjeO8OaVV8x1G9bSpRzqQ2r0gtJftmA@mail.gmail.com>
	<CAP30j15g+QmiWxYD2bwq6cSe_p=KE4AnVki9-C39DwiZRJnSdQ@mail.gmail.com>
Message-ID: <CALtRa-4_d=Pt=CrUbVfxSB_=tGH3PS0toJZmX7hNhg=ZHX960Q@mail.gmail.com>

12/12/29 Ben Walton <bwalton at opencsw.org>:
> A very simple addition to pkgutil will make moving to a new release
> more obvious:
>
> 1. Look for $catalog_url/UPGRADE_AVAILABLE (name is for discussion
> purposes, not a real proposal).
> 2. If found, display with pause before doing new package actions.
>
> So, when we're ready to have people move from Dublin to the next
> release, we place this file and pkgutil will now tell people that

I like the idea. It would make the catalogs a linked list. It could be
also a field in the catalog file, similar to the one with the creation
date.

From maciej at opencsw.org  Sat Dec 29 14:54:24 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sat, 29 Dec 2012 13:54:24 +0000
Subject: [csw-maintainers] Garbage collection in allpkgs
Message-ID: <CALtRa-6fRGP5VSb0fWj7t+e0Z2rV16zHoptLmYFbV+BEYLqOpw@mail.gmail.com>

I ran garbage collection in our official catalog. This means that I
removed files that were in allpkgs, but were not used/referenced by
any of our catalogs. I managed to remove about 24GB worth of unused
packages. The package files are not deleted, they are only moved out
of allpkgs.

Does anyone think we should keep old files forever, that is, keep more
than just what's in our history of releases?

Maciej

From rupert at opencsw.org  Sat Dec 29 15:01:45 2012
From: rupert at opencsw.org (rupert THURNER)
Date: Sat, 29 Dec 2012 15:01:45 +0100
Subject: [csw-maintainers] mgar with other svn clients, like git-svn, hg?
Message-ID: <CAJs9aZ-9zH=+Qabw0v0S1jgdNK7=kG_it4HNM0zZ6-vV_8WqBg@mail.gmail.com>

hi,

is there any (easy) possibility to use mgar with other subversion
clients, like git-svn, or hg?

rupert

From maciej at opencsw.org  Sat Dec 29 15:05:35 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sat, 29 Dec 2012 14:05:35 +0000
Subject: [csw-maintainers] mgar with other svn clients, like git-svn, hg?
In-Reply-To: <CAJs9aZ-9zH=+Qabw0v0S1jgdNK7=kG_it4HNM0zZ6-vV_8WqBg@mail.gmail.com>
References: <CAJs9aZ-9zH=+Qabw0v0S1jgdNK7=kG_it4HNM0zZ6-vV_8WqBg@mail.gmail.com>
Message-ID: <CALtRa-4KL_xuBL-nY9=Dj2=4YbJA8m++Fdm75-8mdVv3YrBT9g@mail.gmail.com>

2012/12/29 rupert THURNER <rupert at opencsw.org>:
> hi,
>
> is there any (easy) possibility to use mgar with other subversion
> clients, like git-svn, or hg?

The mgar code ? yes.
The build descriptions ? no.

From bonivart at opencsw.org  Sat Dec 29 15:08:03 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sat, 29 Dec 2012 15:08:03 +0100
Subject: [csw-maintainers] Solaris 8 packages in named releases
In-Reply-To: <CALtRa-4_d=Pt=CrUbVfxSB_=tGH3PS0toJZmX7hNhg=ZHX960Q@mail.gmail.com>
References: <CALtRa-6HqZ95fCAnMLZZHoARCutM_OEiZMECW8h8+wgtYsLU+g@mail.gmail.com>
	<x6pq21xfl1.fsf@opencsw.org>
	<CABY0g1WtreL0e_MxmW0s+2qb8BnznZ7Ttqtqy-9CPNYirUJLhg@mail.gmail.com>
	<50D6FCEF.70508@opencsw.org>
	<CALtRa-4V2RSMMaMZZR-tjeO8OaVV8x1G9bSpRzqQ2r0gtJftmA@mail.gmail.com>
	<CAP30j15g+QmiWxYD2bwq6cSe_p=KE4AnVki9-C39DwiZRJnSdQ@mail.gmail.com>
	<CALtRa-4_d=Pt=CrUbVfxSB_=tGH3PS0toJZmX7hNhg=ZHX960Q@mail.gmail.com>
Message-ID: <CABY0g1VHqnkmb-yEriyp+u43tP9DysbXCSfeb27Fww3zDggpwQ@mail.gmail.com>

On Sat, Dec 29, 2012 at 2:38 PM, Maciej (Matchek) Blizi?ski
<maciej at opencsw.org> wrote:
> 12/12/29 Ben Walton <bwalton at opencsw.org>:
>> A very simple addition to pkgutil will make moving to a new release
>> more obvious:
>>
>> 1. Look for $catalog_url/UPGRADE_AVAILABLE (name is for discussion
>> purposes, not a real proposal).
>> 2. If found, display with pause before doing new package actions.
>>
>> So, when we're ready to have people move from Dublin to the next
>> release, we place this file and pkgutil will now tell people that
>
> I like the idea. It would make the catalogs a linked list. It could be
> also a field in the catalog file, similar to the one with the creation
> date.

Dago suggested a long time ago support for a message-of-the-day
feature if files like ANNOUNCE/MOTD/CHANGES were present. We also have
talked about the RELEASE feature inside the catalogs, I think that was
in Kiel. The last one is already implemented in pkgutil but I don't
see that we publish the RELEASE line in our catalogs.

I just wanted to bring those older ideas up again.

/peter

From bonivart at opencsw.org  Sat Dec 29 15:19:30 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sat, 29 Dec 2012 15:19:30 +0100
Subject: [csw-maintainers] Garbage collection in allpkgs
In-Reply-To: <CALtRa-6fRGP5VSb0fWj7t+e0Z2rV16zHoptLmYFbV+BEYLqOpw@mail.gmail.com>
References: <CALtRa-6fRGP5VSb0fWj7t+e0Z2rV16zHoptLmYFbV+BEYLqOpw@mail.gmail.com>
Message-ID: <CABY0g1UQDWp+UOQNmD7eXUk-aMSTbAPhsn=cp026Ym3YWv5WBQ@mail.gmail.com>

On Sat, Dec 29, 2012 at 2:54 PM, Maciej (Matchek) Blizi?ski
<maciej at opencsw.org> wrote:
> I ran garbage collection in our official catalog. This means that I
> removed files that were in allpkgs, but were not used/referenced by
> any of our catalogs. I managed to remove about 24GB worth of unused
> packages. The package files are not deleted, they are only moved out
> of allpkgs.
>
> Does anyone think we should keep old files forever, that is, keep more
> than just what's in our history of releases?

What catalogs did you match against, current ones or also archived ones?

I think many users have looked for that lost package from back in the
day, we had one single mirror in Germany that didn't rsync with
--delete so they basically archived everything but I don't think it
was official and they could stop doing that anytime. Could we do the
same somewhere on the buildfarm but not on the master mirror? Then we
would have an official archive for those that need it but since it
wouldn't be used that much it would be unnecessary to mirror it, we
would just link to it from our mirror page.

/peter

From dam at opencsw.org  Sat Dec 29 15:34:58 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sat, 29 Dec 2012 15:34:58 +0100
Subject: [csw-maintainers] Garbage collection in allpkgs
In-Reply-To: <CABY0g1UQDWp+UOQNmD7eXUk-aMSTbAPhsn=cp026Ym3YWv5WBQ@mail.gmail.com>
References: <CALtRa-6fRGP5VSb0fWj7t+e0Z2rV16zHoptLmYFbV+BEYLqOpw@mail.gmail.com>
	<CABY0g1UQDWp+UOQNmD7eXUk-aMSTbAPhsn=cp026Ym3YWv5WBQ@mail.gmail.com>
Message-ID: <FDC1421F-EBD6-4B55-8741-82133B4B3DAB@opencsw.org>

Hi,

Am 29.12.2012 um 15:19 schrieb Peter Bonivart <bonivart at opencsw.org>:

> On Sat, Dec 29, 2012 at 2:54 PM, Maciej (Matchek) Blizi?ski
> <maciej at opencsw.org> wrote:
>> I ran garbage collection in our official catalog. This means that I
>> removed files that were in allpkgs, but were not used/referenced by
>> any of our catalogs. I managed to remove about 24GB worth of unused
>> packages. The package files are not deleted, they are only moved out
>> of allpkgs.
>> 
>> Does anyone think we should keep old files forever, that is, keep more
>> than just what's in our history of releases?

We should keep packages forever in allpkgs. I suggest putting them back.

> What catalogs did you match against, current ones or also archived ones?
> 
> I think many users have looked for that lost package from back in the
> day, we had one single mirror in Germany that didn't rsync with
> --delete so they basically archived everything but I don't think it
> was official and they could stop doing that anytime.

Correct. If archived packages are offered and users consider it useful
it should be us to offer that.

> Could we do the
> same somewhere on the buildfarm but not on the master mirror? Then we
> would have an official archive for those that need it but since it
> wouldn't be used that much it would be unnecessary to mirror it, we
> would just link to it from our mirror page.

This is already the case: allpkgs/ is not included in the main rsync
offering, just in opencsw-full:

> dam at login [login]:/home/dam > rsync rsync://mirror.opencsw.org
> csw             Legacy name, please switch to the identical 'opencsw'
> opencsw         CSW Primary Mirror, use this if you are mirroring OpenCSW (the archive "allpkgs" is now in 'opencsw-full')
> opencsw-full    CSW Primary Mirror, contains full archive of old packages
> opencsw-future  The proposed future layout of the OpenCSW Primary, layout may change without notice at any time


This is done by using the exclude-directive in rsync.conf for "csw" and "opencsw":
        exclude = allpkgs HEADER.txt

Having all packages on the primary mirror is also good IMHO. This way
each downstream-site can easily select what to offer.


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  Sun Dec 30 19:53:45 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 30 Dec 2012 18:53:45 +0000
Subject: [csw-maintainers] Garbage collection in allpkgs
In-Reply-To: <FDC1421F-EBD6-4B55-8741-82133B4B3DAB@opencsw.org>
References: <CALtRa-6fRGP5VSb0fWj7t+e0Z2rV16zHoptLmYFbV+BEYLqOpw@mail.gmail.com>
	<CABY0g1UQDWp+UOQNmD7eXUk-aMSTbAPhsn=cp026Ym3YWv5WBQ@mail.gmail.com>
	<FDC1421F-EBD6-4B55-8741-82133B4B3DAB@opencsw.org>
Message-ID: <CALtRa-7XAEQtdqt0r=7NN1zyZc=YAL_2j7JG0Z1-iCBd0ey=JQ@mail.gmail.com>

2012/12/29 Dagobert Michelsen <dam at opencsw.org>:
> Hi,
>
> Am 29.12.2012 um 15:19 schrieb Peter Bonivart <bonivart at opencsw.org>:
>
>> On Sat, Dec 29, 2012 at 2:54 PM, Maciej (Matchek) Blizi?ski
>> <maciej at opencsw.org> wrote:
>>> I ran garbage collection in our official catalog. This means that I
>>> removed files that were in allpkgs, but were not used/referenced by
>>> any of our catalogs. I managed to remove about 24GB worth of unused
>>> packages. The package files are not deleted, they are only moved out
>>> of allpkgs.
>>>
>>> Does anyone think we should keep old files forever, that is, keep more
>>> than just what's in our history of releases?
>
> We should keep packages forever in allpkgs. I suggest putting them back.

OK, will do.

>> What catalogs did you match against, current ones or also archived ones?

Current ones.

>> I think many users have looked for that lost package from back in the
>> day, we had one single mirror in Germany that didn't rsync with
>> --delete so they basically archived everything but I don't think it
>> was official and they could stop doing that anytime.
>
> Correct. If archived packages are offered and users consider it useful
> it should be us to offer that.

Agreed.

>> Could we do the
>> same somewhere on the buildfarm but not on the master mirror? Then we
>> would have an official archive for those that need it but since it
>> wouldn't be used that much it would be unnecessary to mirror it, we
>> would just link to it from our mirror page.
>
> This is already the case: allpkgs/ is not included in the main rsync
> offering, just in opencsw-full:
>
>> dam at login [login]:/home/dam > rsync rsync://mirror.opencsw.org
>> csw             Legacy name, please switch to the identical 'opencsw'
>> opencsw         CSW Primary Mirror, use this if you are mirroring OpenCSW (the archive "allpkgs" is now in 'opencsw-full')
>> opencsw-full    CSW Primary Mirror, contains full archive of old packages
>> opencsw-future  The proposed future layout of the OpenCSW Primary, layout may change without notice at any time
>
>
> This is done by using the exclude-directive in rsync.conf for "csw" and "opencsw":
>         exclude = allpkgs HEADER.txt
>
> Having all packages on the primary mirror is also good IMHO. This way
> each downstream-site can easily select what to offer.

I'm not sure what you mean by downstream-sites selecting what to
offer. The primary mirror has a set of files, and that's it. People
can make snapshots from different points in time, is that what you
mean?

Generally, the oldpkgs archive that people often wanted were there
because of the rolling release of the 'current' catalog. At the time,
the thinking was that first we scrutinize the hell of the package, and
once we prove to ourselves it's a good package, we push it forward
with no good way of rolling it back. If we pushed something bad, we
had nothing to say to people other than ?scavenge oldpkgs?. These
days, we have the testing release; we know that we will every now and
then push something bad to unstable, and that people can still using
the testing release, and we don't have to panic when there's something
broken in unstable. The assumption there is of course, that majority
of problems will be caught when in unstable.

We also keep the old named releases, for instance the dublin release,
which is a consistent set of packages and their dependencies.

The 'allpkgs' directory does contain a history of packages, but it
doesn't contain all transient (and often broken) 19 different versions
of MySQL that happened to be in unstable for 2 days, but only the 3 or
4 versions that are actually used somewhere in our catalogs. I thought
that was good enough. If you disagree, I will put the 24GB of junk
back in allpkgs; but I remain unconvinced that they are actually
useful.

Maciej

From pfelecan at opencsw.org  Sun Dec 30 20:21:49 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sun, 30 Dec 2012 20:21:49 +0100
Subject: [csw-maintainers] Garbage collection in allpkgs
In-Reply-To: <CALtRa-7XAEQtdqt0r=7NN1zyZc=YAL_2j7JG0Z1-iCBd0ey=JQ@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun,
	30 Dec 2012 18:53:45 +0000")
References: <CALtRa-6fRGP5VSb0fWj7t+e0Z2rV16zHoptLmYFbV+BEYLqOpw@mail.gmail.com>
	<CABY0g1UQDWp+UOQNmD7eXUk-aMSTbAPhsn=cp026Ym3YWv5WBQ@mail.gmail.com>
	<FDC1421F-EBD6-4B55-8741-82133B4B3DAB@opencsw.org>
	<CALtRa-7XAEQtdqt0r=7NN1zyZc=YAL_2j7JG0Z1-iCBd0ey=JQ@mail.gmail.com>
Message-ID: <x6r4m7tkfm.fsf@opencsw.org>

"Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> writes:

> The 'allpkgs' directory does contain a history of packages, but it
> doesn't contain all transient (and often broken) 19 different versions
> of MySQL that happened to be in unstable for 2 days, but only the 3 or
> 4 versions that are actually used somewhere in our catalogs. I thought
> that was good enough. If you disagree, I will put the 24GB of junk
> back in allpkgs; but I remain unconvinced that they are actually
> useful.

Isn't the set allpkgs the union of all the named releases, e.g. dublin,
kiel, &c. ? If that is true we must offer only that. To offer all the
instances of our packages that were produced over the time can be a
waste of resources, material and spiritual, i.e. is very difficult for
someone to create a coherent set of that even if he's perusing the
source control system's history of the recipes. Consequently, I support
Maciej proposition.
-- 
Peter

From dam at opencsw.org  Mon Dec 31 13:23:14 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 31 Dec 2012 13:23:14 +0100
Subject: [csw-maintainers] Garbage collection in allpkgs
In-Reply-To: <CALtRa-7XAEQtdqt0r=7NN1zyZc=YAL_2j7JG0Z1-iCBd0ey=JQ@mail.gmail.com>
References: <CALtRa-6fRGP5VSb0fWj7t+e0Z2rV16zHoptLmYFbV+BEYLqOpw@mail.gmail.com>
	<CABY0g1UQDWp+UOQNmD7eXUk-aMSTbAPhsn=cp026Ym3YWv5WBQ@mail.gmail.com>
	<FDC1421F-EBD6-4B55-8741-82133B4B3DAB@opencsw.org>
	<CALtRa-7XAEQtdqt0r=7NN1zyZc=YAL_2j7JG0Z1-iCBd0ey=JQ@mail.gmail.com>
Message-ID: <9A41C992-9D7E-481C-BBFB-2C14E8080B47@opencsw.org>

Hi Maciej,

Am 30.12.2012 um 19:53 schrieb Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
> 2012/12/29 Dagobert Michelsen <dam at opencsw.org>:
>>> Could we do the
>>> same somewhere on the buildfarm but not on the master mirror? Then we
>>> would have an official archive for those that need it but since it
>>> wouldn't be used that much it would be unnecessary to mirror it, we
>>> would just link to it from our mirror page.
>> 
>> This is already the case: allpkgs/ is not included in the main rsync
>> offering, just in opencsw-full:
>> 
>>> dam at login [login]:/home/dam > rsync rsync://mirror.opencsw.org
>>> csw             Legacy name, please switch to the identical 'opencsw'
>>> opencsw         CSW Primary Mirror, use this if you are mirroring OpenCSW (the archive "allpkgs" is now in 'opencsw-full')
>>> opencsw-full    CSW Primary Mirror, contains full archive of old packages
>>> opencsw-future  The proposed future layout of the OpenCSW Primary, layout may change without notice at any time
>> 
>> 
>> This is done by using the exclude-directive in rsync.conf for "csw" and "opencsw":
>>        exclude = allpkgs HEADER.txt
>> 
>> Having all packages on the primary mirror is also good IMHO. This way
>> each downstream-site can easily select what to offer.
> 
> I'm not sure what you mean by downstream-sites selecting what to
> offer.

Official sites mirroring our packages.

> The primary mirror has a set of files, and that's it.

Not quite. There are all files in the filesystem avaialable for download.
However, if you rsync "opencsw" you won't get allpkgs/, so almost all
of the official mirror sites don't mirror allpkgs/.

> People
> can make snapshots from different points in time, is that what you
> mean?

No, that is different. We don't do this ATM, but archive catalog-files,
so if someone has a specific problem we can regenerate everything
from that catalog and allpkgs/ and this is another reason why I think
having allpkgs is a Good Thing?.

> Generally, the oldpkgs archive that people often wanted were there
> because of the rolling release of the 'current' catalog. At the time,
> the thinking was that first we scrutinize the hell of the package, and
> once we prove to ourselves it's a good package, we push it forward
> with no good way of rolling it back. If we pushed something bad, we
> had nothing to say to people other than ?scavenge oldpkgs?. These
> days, we have the testing release; we know that we will every now and
> then push something bad to unstable, and that people can still using
> the testing release, and we don't have to panic when there's something
> broken in unstable. The assumption there is of course, that majority
> of problems will be caught when in unstable.

Right.

> We also keep the old named releases, for instance the dublin release,
> which is a consistent set of packages and their dependencies.

Yes.

> The 'allpkgs' directory does contain a history of packages, but it
> doesn't contain all transient (and often broken) 19 different versions
> of MySQL that happened to be in unstable for 2 days, but only the 3 or
> 4 versions that are actually used somewhere in our catalogs.

If it would be only for this we wouldn't need allpkgs at all.

> I thought
> that was good enough. If you disagree, I will put the 24GB of junk
> back in allpkgs; but I remain unconvinced that they are actually
> useful.


Hopefully I convinced you with the above arguments.


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896


From dam at opencsw.org  Mon Dec 31 13:25:03 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 31 Dec 2012 13:25:03 +0100
Subject: [csw-maintainers] Garbage collection in allpkgs
In-Reply-To: <x6r4m7tkfm.fsf@opencsw.org>
References: <CALtRa-6fRGP5VSb0fWj7t+e0Z2rV16zHoptLmYFbV+BEYLqOpw@mail.gmail.com>
	<CABY0g1UQDWp+UOQNmD7eXUk-aMSTbAPhsn=cp026Ym3YWv5WBQ@mail.gmail.com>
	<FDC1421F-EBD6-4B55-8741-82133B4B3DAB@opencsw.org>
	<CALtRa-7XAEQtdqt0r=7NN1zyZc=YAL_2j7JG0Z1-iCBd0ey=JQ@mail.gmail.com>
	<x6r4m7tkfm.fsf@opencsw.org>
Message-ID: <6227C4FC-0779-43BB-8BD9-7E9D4BFA7958@opencsw.org>

Hi Peter,

Am 30.12.2012 um 20:21 schrieb Peter FELECAN <pfelecan at opencsw.org>:
> "Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> writes:
>> The 'allpkgs' directory does contain a history of packages, but it
>> doesn't contain all transient (and often broken) 19 different versions
>> of MySQL that happened to be in unstable for 2 days, but only the 3 or
>> 4 versions that are actually used somewhere in our catalogs. I thought
>> that was good enough. If you disagree, I will put the 24GB of junk
>> back in allpkgs; but I remain unconvinced that they are actually
>> useful.
> 
> Isn't the set allpkgs the union of all the named releases, e.g. dublin,
> kiel, &c. ?

No, allpkgs is the collection of all packages ever released to any
of the catalogs (with the exception of experimental).

> If that is true we must offer only that. To offer all the
> instances of our packages that were produced over the time can be a
> waste of resources, material and spiritual, i.e. is very difficult for
> someone to create a coherent set of that even if he's perusing the
> source control system's history of the recipes. Consequently, I support
> Maciej proposition.

It is meant as a reference for reproducing issues. Also I compare
old versions of a package with a recent one from time to time if
I think we have a regression.


Best regards

  -- Dago


-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896


From maciej at opencsw.org  Mon Dec 31 14:04:25 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Mon, 31 Dec 2012 13:04:25 +0000
Subject: [csw-maintainers] Garbage collection in allpkgs
In-Reply-To: <9A41C992-9D7E-481C-BBFB-2C14E8080B47@opencsw.org>
References: <CALtRa-6fRGP5VSb0fWj7t+e0Z2rV16zHoptLmYFbV+BEYLqOpw@mail.gmail.com>
	<CABY0g1UQDWp+UOQNmD7eXUk-aMSTbAPhsn=cp026Ym3YWv5WBQ@mail.gmail.com>
	<FDC1421F-EBD6-4B55-8741-82133B4B3DAB@opencsw.org>
	<CALtRa-7XAEQtdqt0r=7NN1zyZc=YAL_2j7JG0Z1-iCBd0ey=JQ@mail.gmail.com>
	<9A41C992-9D7E-481C-BBFB-2C14E8080B47@opencsw.org>
Message-ID: <CALtRa-6Q1--hs7BDLeKy97rMs67mMpczHrf5=aukswokRRvXvA@mail.gmail.com>

2012/12/31 Dagobert Michelsen <dam at opencsw.org>:
> Hi Maciej,
>
> Am 30.12.2012 um 19:53 schrieb Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
>> 2012/12/29 Dagobert Michelsen <dam at opencsw.org>:
>>>> Could we do the
>>>> same somewhere on the buildfarm but not on the master mirror? Then we
>>>> would have an official archive for those that need it but since it
>>>> wouldn't be used that much it would be unnecessary to mirror it, we
>>>> would just link to it from our mirror page.
>>>
>>> This is already the case: allpkgs/ is not included in the main rsync
>>> offering, just in opencsw-full:
>>>
>>>> dam at login [login]:/home/dam > rsync rsync://mirror.opencsw.org
>>>> csw             Legacy name, please switch to the identical 'opencsw'
>>>> opencsw         CSW Primary Mirror, use this if you are mirroring OpenCSW (the archive "allpkgs" is now in 'opencsw-full')
>>>> opencsw-full    CSW Primary Mirror, contains full archive of old packages
>>>> opencsw-future  The proposed future layout of the OpenCSW Primary, layout may change without notice at any time
>>>
>>>
>>> This is done by using the exclude-directive in rsync.conf for "csw" and "opencsw":
>>>        exclude = allpkgs HEADER.txt
>>>
>>> Having all packages on the primary mirror is also good IMHO. This way
>>> each downstream-site can easily select what to offer.
>>
>> I'm not sure what you mean by downstream-sites selecting what to
>> offer.
>
> Official sites mirroring our packages.

I was asking what do you mean by selecting what to offer. Downstream
sites I understand.

>> The primary mirror has a set of files, and that's it.
>
> Not quite. There are all files in the filesystem avaialable for download.
> However, if you rsync "opencsw" you won't get allpkgs/, so almost all
> of the official mirror sites don't mirror allpkgs/.

So there's a set of file that you get when you rsync and that's it. If
you rsync, you don't get to choose, you get what you it's given to
you. If you don't, then you're not a full mirror.

>> People
>> can make snapshots from different points in time, is that what you
>> mean?
>
> No, that is different. We don't do this ATM, but archive catalog-files,
> so if someone has a specific problem we can regenerate everything
> from that catalog and allpkgs/ and this is another reason why I think
> having allpkgs is a Good Thing?.

Did we ever do that? Did we even exercise doing this? I think that in
a real situation we would do something else rather than recreating a
past catalog. Do you have a specific scenario in mind? For example, we
have a bad, I don't know, MySQL. What would make us recreate an old
catalog from archives, rather than selectively solving the problem at
hand?

>> Generally, the oldpkgs archive that people often wanted were there
>> because of the rolling release of the 'current' catalog. At the time,
>> the thinking was that first we scrutinize the hell of the package, and
>> once we prove to ourselves it's a good package, we push it forward
>> with no good way of rolling it back. If we pushed something bad, we
>> had nothing to say to people other than ?scavenge oldpkgs?. These
>> days, we have the testing release; we know that we will every now and
>> then push something bad to unstable, and that people can still using
>> the testing release, and we don't have to panic when there's something
>> broken in unstable. The assumption there is of course, that majority
>> of problems will be caught when in unstable.
>
> Right.
>
>> We also keep the old named releases, for instance the dublin release,
>> which is a consistent set of packages and their dependencies.
>
> Yes.
>
>> The 'allpkgs' directory does contain a history of packages, but it
>> doesn't contain all transient (and often broken) 19 different versions
>> of MySQL that happened to be in unstable for 2 days, but only the 3 or
>> 4 versions that are actually used somewhere in our catalogs.
>
> If it would be only for this we wouldn't need allpkgs at all.
>
>> I thought
>> that was good enough. If you disagree, I will put the 24GB of junk
>> back in allpkgs; but I remain unconvinced that they are actually
>> useful.
>
>
> Hopefully I convinced you with the above arguments.

I see some point in keeping old packages for some time. We had one
case in which we needed to restore a version of gcc from allpkgs,
because the version from dublin was too old and the version from
unstable was still problematic. But I still don't see a point in
keeping them forever.

We should focus on realistic scenarios, either ones that we actually
performed (like the gcc restore) or ones that we anticipate and are
able to exercise.

Maciej

From maciej at opencsw.org  Mon Dec 31 14:06:50 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Mon, 31 Dec 2012 13:06:50 +0000
Subject: [csw-maintainers] Garbage collection in allpkgs
In-Reply-To: <6227C4FC-0779-43BB-8BD9-7E9D4BFA7958@opencsw.org>
References: <CALtRa-6fRGP5VSb0fWj7t+e0Z2rV16zHoptLmYFbV+BEYLqOpw@mail.gmail.com>
	<CABY0g1UQDWp+UOQNmD7eXUk-aMSTbAPhsn=cp026Ym3YWv5WBQ@mail.gmail.com>
	<FDC1421F-EBD6-4B55-8741-82133B4B3DAB@opencsw.org>
	<CALtRa-7XAEQtdqt0r=7NN1zyZc=YAL_2j7JG0Z1-iCBd0ey=JQ@mail.gmail.com>
	<x6r4m7tkfm.fsf@opencsw.org>
	<6227C4FC-0779-43BB-8BD9-7E9D4BFA7958@opencsw.org>
Message-ID: <CALtRa-7OofNNwaG4e+FKue4xd+XwvtoDJxQXbbR=oPHfbarFEg@mail.gmail.com>

2012/12/31 Dagobert Michelsen <dam at opencsw.org>:
> Hi Peter,
>
> Am 30.12.2012 um 20:21 schrieb Peter FELECAN <pfelecan at opencsw.org>:
>> "Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> writes:
>>> The 'allpkgs' directory does contain a history of packages, but it
>>> doesn't contain all transient (and often broken) 19 different versions
>>> of MySQL that happened to be in unstable for 2 days, but only the 3 or
>>> 4 versions that are actually used somewhere in our catalogs. I thought
>>> that was good enough. If you disagree, I will put the 24GB of junk
>>> back in allpkgs; but I remain unconvinced that they are actually
>>> useful.
>>
>> Isn't the set allpkgs the union of all the named releases, e.g. dublin,
>> kiel, &c. ?
>
> No, allpkgs is the collection of all packages ever released to any
> of the catalogs (with the exception of experimental).

'unstable' is also one of the named catalogs. I think we could change
that at some point for clarity, but for now 'unstable' is a named
release, which gets never promoted.

>> If that is true we must offer only that. To offer all the
>> instances of our packages that were produced over the time can be a
>> waste of resources, material and spiritual, i.e. is very difficult for
>> someone to create a coherent set of that even if he's perusing the
>> source control system's history of the recipes. Consequently, I support
>> Maciej proposition.
>
> It is meant as a reference for reproducing issues. Also I compare
> old versions of a package with a recent one from time to time if
> I think we have a regression.

This is an argument for keeping package files around for some time,
where the time could be for instance half a year.

Maciej

From guillomovitch at opencsw.org  Mon Dec 31 15:19:39 2012
From: guillomovitch at opencsw.org (Guillaume Rousse)
Date: Mon, 31 Dec 2012 15:19:39 +0100
Subject: [csw-maintainers] 404 error on fusioninventory-agent QA page
Message-ID: <50E19EFB.1020202@opencsw.org>

Hello list.

In the 'uWatch information' section of QA page for fusioninventory-agent 
package, there is an explicit error:
http://www.opencsw.org/qa/package/fusioninventory_agent/

I guess this is about automatically checking for newer version 
availability, but the URL used 
(http://search.cpan.org/~fusinv/fusioninventory-agent) is wrong. How do 
I change this to use 
http://forge.fusioninventory.org/projects/fusioninventory-agent/files 
instead ?
-- 
BOFH excuse #38:

secretary plugged hairdryer into UPS

From dam at opencsw.org  Mon Dec 31 22:09:46 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 31 Dec 2012 22:09:46 +0100
Subject: [csw-maintainers] Garbage collection in allpkgs
In-Reply-To: <CALtRa-6Q1--hs7BDLeKy97rMs67mMpczHrf5=aukswokRRvXvA@mail.gmail.com>
References: <CALtRa-6fRGP5VSb0fWj7t+e0Z2rV16zHoptLmYFbV+BEYLqOpw@mail.gmail.com>
	<CABY0g1UQDWp+UOQNmD7eXUk-aMSTbAPhsn=cp026Ym3YWv5WBQ@mail.gmail.com>
	<FDC1421F-EBD6-4B55-8741-82133B4B3DAB@opencsw.org>
	<CALtRa-7XAEQtdqt0r=7NN1zyZc=YAL_2j7JG0Z1-iCBd0ey=JQ@mail.gmail.com>
	<9A41C992-9D7E-481C-BBFB-2C14E8080B47@opencsw.org>
	<CALtRa-6Q1--hs7BDLeKy97rMs67mMpczHrf5=aukswokRRvXvA@mail.gmail.com>
Message-ID: <1A4196A0-120D-4217-B0A4-646E30F34BAA@opencsw.org>

Hi Maciej,

Am 31.12.2012 um 14:04 schrieb Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
> 2012/12/31 Dagobert Michelsen <dam at opencsw.org>:
>> Am 30.12.2012 um 19:53 schrieb Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
>>> 2012/12/29 Dagobert Michelsen <dam at opencsw.org>:
>>>>> Could we do the
>>>>> same somewhere on the buildfarm but not on the master mirror? Then we
>>>>> would have an official archive for those that need it but since it
>>>>> wouldn't be used that much it would be unnecessary to mirror it, we
>>>>> would just link to it from our mirror page.
>>>> 
>>>> This is already the case: allpkgs/ is not included in the main rsync
>>>> offering, just in opencsw-full:
>>>> 
>>>>> dam at login [login]:/home/dam > rsync rsync://mirror.opencsw.org
>>>>> csw             Legacy name, please switch to the identical 'opencsw'
>>>>> opencsw         CSW Primary Mirror, use this if you are mirroring OpenCSW (the archive "allpkgs" is now in 'opencsw-full')
>>>>> opencsw-full    CSW Primary Mirror, contains full archive of old packages
>>>>> opencsw-future  The proposed future layout of the OpenCSW Primary, layout may change without notice at any time
>>>> 
>>>> This is done by using the exclude-directive in rsync.conf for "csw" and "opencsw":
>>>>       exclude = allpkgs HEADER.txt
>>>> 
>>>> Having all packages on the primary mirror is also good IMHO. This way
>>>> each downstream-site can easily select what to offer.
>>> 
>>> I'm not sure what you mean by downstream-sites selecting what to
>>> offer.
>> 
>> Official sites mirroring our packages.
> 
> I was asking what do you mean by selecting what to offer. Downstream
> sites I understand.
> 
>>> The primary mirror has a set of files, and that's it.
>> 
>> Not quite. There are all files in the filesystem avaialable for download.
>> However, if you rsync "opencsw" you won't get allpkgs/, so almost all
>> of the official mirror sites don't mirror allpkgs/.
> 
> So there's a set of file that you get when you rsync and that's it. If
> you rsync, you don't get to choose, you get what you it's given to
> you. If you don't, then you're not a full mirror.

You are completely missing the point here. Please try
  rsync rsync://mirror.opencsw.org/opencsw/
and compare this to
  rsync rsync://mirror.opencsw.org/opencsw-full/

The former does not include allpkgs/, the latter does. By choosing the rsync URL
you as downstream mirror decide if you want to include allpkgs or not although
it is on the filesystem of the primary. This is rsync-magic. Trust me! :-)

>>> People
>>> can make snapshots from different points in time, is that what you
>>> mean?
>> 
>> No, that is different. We don't do this ATM, but archive catalog-files,
>> so if someone has a specific problem we can regenerate everything
>> from that catalog and allpkgs/ and this is another reason why I think
>> having allpkgs is a Good Thing?.
> 
> Did we ever do that? Did we even exercise doing this? I think that in
> a real situation we would do something else rather than recreating a
> past catalog. Do you have a specific scenario in mind? For example, we
> have a bad, I don't know, MySQL. What would make us recreate an old
> catalog from archives, rather than selectively solving the problem at
> hand?

I did a couple of times. 

>>> Generally, the oldpkgs archive that people often wanted were there
>>> because of the rolling release of the 'current' catalog. At the time,
>>> the thinking was that first we scrutinize the hell of the package, and
>>> once we prove to ourselves it's a good package, we push it forward
>>> with no good way of rolling it back. If we pushed something bad, we
>>> had nothing to say to people other than ?scavenge oldpkgs?. These
>>> days, we have the testing release; we know that we will every now and
>>> then push something bad to unstable, and that people can still using
>>> the testing release, and we don't have to panic when there's something
>>> broken in unstable. The assumption there is of course, that majority
>>> of problems will be caught when in unstable.
>> 
>> Right.
>> 
>>> We also keep the old named releases, for instance the dublin release,
>>> which is a consistent set of packages and their dependencies.
>> 
>> Yes.
>> 
>>> The 'allpkgs' directory does contain a history of packages, but it
>>> doesn't contain all transient (and often broken) 19 different versions
>>> of MySQL that happened to be in unstable for 2 days, but only the 3 or
>>> 4 versions that are actually used somewhere in our catalogs.
>> 
>> If it would be only for this we wouldn't need allpkgs at all.
>> 
>>> I thought
>>> that was good enough. If you disagree, I will put the 24GB of junk
>>> back in allpkgs; but I remain unconvinced that they are actually
>>> useful.
>> 
>> 
>> Hopefully I convinced you with the above arguments.
> 
> I see some point in keeping old packages for some time. We had one
> case in which we needed to restore a version of gcc from allpkgs,
> because the version from dublin was too old and the version from
> unstable was still problematic. But I still don't see a point in
> keeping them forever.
> 
> We should focus on realistic scenarios, either ones that we actually
> performed (like the gcc restore) or ones that we anticipate and are
> able to exercise.

Keeping them is almost free and has IMHO no drawbacks. Having a complete
archive is professional behaviour. Why keep all patchdiag.xref ever
released? Because you can never know.


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896


From dam at opencsw.org  Mon Dec 31 22:15:06 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 31 Dec 2012 22:15:06 +0100
Subject: [csw-maintainers] 404 error on fusioninventory-agent QA page
In-Reply-To: <50E19EFB.1020202@opencsw.org>
References: <50E19EFB.1020202@opencsw.org>
Message-ID: <4D129037-5E39-4D37-9113-CAE9B58A4A71@opencsw.org>

Hi Guillaume,

Am 31.12.2012 um 15:19 schrieb Guillaume Rousse <guillomovitch at opencsw.org>:
> In the 'uWatch information' section of QA page for fusioninventory-agent package, there is an explicit error:
> http://www.opencsw.org/qa/package/fusioninventory_agent/
> 
> I guess this is about automatically checking for newer version availability, but the URL used (http://search.cpan.org/~fusinv/fusioninventory-agent) is wrong. How do I change this to use http://forge.fusioninventory.org/projects/fusioninventory-agent/files instead ?

I think you just change the UFILES_REGEX and UPSTREAM_MASTER_SITES variable
in the Makefile and commit the Makefile.

There are a couple of wiki-pages describing the interaction of uwatch:
  http://wiki.opencsw.org/uwatch
or
  http://wiki.opencsw.org/search:site/q/uwatch

William used to maintain uwatch, but he has been dormant for some time now,
so if you have further problems we may need to initiate a joint debug
session.



Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896


From dam at opencsw.org  Mon Dec 31 22:26:53 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 31 Dec 2012 22:26:53 +0100
Subject: [csw-maintainers] Some ideas about forthcoming camps
Message-ID: <D9FF4659-A013-4508-A89B-CB3C6395B829@opencsw.org>

Hi folks,

in the past we had a lot of cool camps at maintainer locations. To attract more
maintainers to come to the camps I just got the idea of combining the camp with
some other larger-scale event like FOSDEM in Brussel or CCCC in Hamburg and
either pre- or postpend some extra days exclusively for OpenCSW. We could also
do this from time to time as events see fit.

Thoughts?


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