From bwalton at opencsw.org  Sun Jan  1 04:30:27 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 31 Dec 2011 22:30:27 -0500
Subject: [csw-maintainers] away this week
Message-ID: <1325388581-sup-9682@pinkfloyd.chass.utoronto.ca>


Hi All,

I'll be away and pretty much offline this coming week (starting
tomorrow).  If you have buildfarm requests, please be patient as we
won't have full coverage of timezones.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From bonivart at opencsw.org  Mon Jan  2 10:14:34 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Mon, 2 Jan 2012 10:14:34 +0100
Subject: [csw-maintainers] pkgutil bugs in Mantis now listed as pkg-get
	bugs..?
Message-ID: <CABY0g1X2znKRHwS4EBfM1jbFLog2=cN+4LTDTajbZtL0u3zRog@mail.gmail.com>

I noticed on Dagos bug summary page that my pkgutil bugs were gone so
I dug up the latest e-mail notification and clicked on the links
there. The problem seems to be that they are now assigned to pkg-get.
Is this related to pkg-get being deprecated?

https://www.opencsw.org/mantis/view.php?id=3894
https://www.opencsw.org/mantis/view.php?id=4117

/peter

From dam at opencsw.org  Mon Jan  2 10:36:35 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 2 Jan 2012 10:36:35 +0100
Subject: [csw-maintainers] Catalog checks via REST
In-Reply-To: <CABY0g1VwS1p7Gm8Mz0yL7MD5SaSYYRohtvKwMt_JvNeS1vHgBw@mail.gmail.com>
References: <CALtRa-5zaZub2i=y33ik3uTkvvpyu+L6akkekcVsP1CoTUChOg@mail.gmail.com>
	<C5B7D102-40BD-49FD-9334-E472AF584682@opencsw.org>
	<CALtRa-6pmB96MzXJs_gseDJLEbgjvdcKX_EgZrPACUtRzjjiUw@mail.gmail.com>
	<033689A1-FD32-4DCB-9CE3-6C68D3AF6B4B@opencsw.org>
	<CALtRa-4xOkhzsWVDF0E0_vuvYyiBB5_nZwwav78XjYEtt+0kNg@mail.gmail.com>
	<CALtRa-6OSv+pBtRFAg6W4u4sjkodXrzCaHRZdxiZ7cjBOUBJ0g@mail.gmail.com>
	<CABY0g1VwS1p7Gm8Mz0yL7MD5SaSYYRohtvKwMt_JvNeS1vHgBw@mail.gmail.com>
Message-ID: <65B032CA-3C2D-4030-B1AA-5CF7C1086E42@opencsw.org>

Hi,

Am 30.12.2011 um 20:06 schrieb Peter Bonivart:
> 2011/12/30 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
>> I've pushed GCC to experimental, but haven't gotten a notification
>> email. I think we might have a bad catalog, and we don't know why.
> 
> Do you mean unstable?
> 
> In what stage has the process stopped and what stopped it? You could
> upload it into the database after passing checkpkg tests so it's when
> the cron job tries to produce a catalog from the database it breaks,
> probably due to chkcat complaining, right? Couldn't the output of the
> chkcat run always be put on a fixed path browseable? So anyone knowing
> the url for a catalog could check it themselves.
> 
> Also, Dago had some performance tips regarding chkcat so maybe it
> could be run when doing the uploading.

I have made an experimental branch "quickloop" for chkcat with improved
loop detection code where the actual loop detection does not take more
time then the other checks (making --nodeps obsolete) and which prints
the detected cycles:
  http://pkgutil.svn.sourceforge.net/viewvc/pkgutil/branches/quickloop/chkcat?revision=434&view=markup


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 bonivart at opencsw.org  Mon Jan  2 10:53:07 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Mon, 2 Jan 2012 10:53:07 +0100
Subject: [csw-maintainers] Catalog checks via REST
In-Reply-To: <65B032CA-3C2D-4030-B1AA-5CF7C1086E42@opencsw.org>
References: <CALtRa-5zaZub2i=y33ik3uTkvvpyu+L6akkekcVsP1CoTUChOg@mail.gmail.com>
	<C5B7D102-40BD-49FD-9334-E472AF584682@opencsw.org>
	<CALtRa-6pmB96MzXJs_gseDJLEbgjvdcKX_EgZrPACUtRzjjiUw@mail.gmail.com>
	<033689A1-FD32-4DCB-9CE3-6C68D3AF6B4B@opencsw.org>
	<CALtRa-4xOkhzsWVDF0E0_vuvYyiBB5_nZwwav78XjYEtt+0kNg@mail.gmail.com>
	<CALtRa-6OSv+pBtRFAg6W4u4sjkodXrzCaHRZdxiZ7cjBOUBJ0g@mail.gmail.com>
	<CABY0g1VwS1p7Gm8Mz0yL7MD5SaSYYRohtvKwMt_JvNeS1vHgBw@mail.gmail.com>
	<65B032CA-3C2D-4030-B1AA-5CF7C1086E42@opencsw.org>
Message-ID: <CABY0g1U0h8yhYwfsSk_EcO=zMjrUuzUVDpr9gdgHpzNFby__gg@mail.gmail.com>

On Mon, Jan 2, 2012 at 10:36 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
> I have made an experimental branch "quickloop" for chkcat with improved
> loop detection code where the actual loop detection does not take more
> time then the other checks (making --nodeps obsolete) and which prints
> the detected cycles:
> ?http://pkgutil.svn.sourceforge.net/viewvc/pkgutil/branches/quickloop/chkcat?revision=434&view=markup

Thanks Dago! So on the server side csw-upload-pkg could trigger a
catalog generation which would be checked by chkcat immediately so
csw-upload-pkg could respond to the user directly.

/peter

From rupert at opencsw.org  Thu Jan  5 21:33:22 2012
From: rupert at opencsw.org (rupert THURNER)
Date: Thu, 5 Jan 2012 21:33:22 +0100
Subject: [csw-maintainers] subversion-1.7.2 now with gnome-keyring,
 where to put command line keyring tool?
In-Reply-To: <1325270723-sup-2477@pinkfloyd.chass.utoronto.ca>
References: <CAJs9aZ_t13bdQ5mF3ZjqvDigLyZN2HnEM-jRLidiON2vgkb-mA@mail.gmail.com>
	<1325270723-sup-2477@pinkfloyd.chass.utoronto.ca>
Message-ID: <CAJs9aZ_QF5gu523tUd2+WLX50GpRcMrXQUXiobkqkq3M_PPqQQ@mail.gmail.com>

subversion_contrib, and subversion_tools do not make sense any more for
1.7+ as they are empty. is it sufficient to just remove them from the
makefile? and how the package then gets removed from the "new catalogue"?

On Fri, Dec 30, 2011 at 19:46, Ben Walton <bwalton at opencsw.org> wrote:

> Excerpts from rupert THURNER's message of Thu Dec 29 17:06:35 -0500 2011:
>
> Hi Rupert,
>
> > subversion-1.7.2 is now compiled with gnome-keyring included. for
>
> Nice!
>
> > headless installations, there is no possibility to maintain the
> > keys. mark phippard from collabnet wrote a tool to do this command
> > line based, which is now available as well:
> > https://ctf.open.collab.net/sf/projects/keyring/. this should go
> > into a dedicated package, or would it be good to just add it to
> > gnome keyring?
>
> I'd go separate package here since it doesn't seem to be included in
> the contrib/ directory of the subversion package itself.  You might
> reference it from README.CSW in CSWsvn though.
>
> Thanks
> -Ben
> --
> Ben Walton
> Systems Programmer - CHASS
> University of Toronto
> C:416.407.5610 | W:416.978.4302
>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120105/93af00cf/attachment.html>

From maciej at opencsw.org  Sun Jan  8 19:56:49 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 8 Jan 2012 18:56:49 +0000
Subject: [csw-maintainers] Patch management with Quilt
Message-ID: <CALtRa-4f+oCgypB0v7Ba-EjAbGf5662WW3iwiS4ePgdbookvzg@mail.gmail.com>

Hello maintainers,

Since we have automatic git integration in GAR builds, writing patches
has become easier. However, there are still some wrinkles, for example
there's no easy way to update a patch. We either need to create
layered patches, or manually remove the patch, apply it off-gar,
modify, and then re-create it.

There is a piece of software which can maintain a mapping between
patch files and upstream source files. It's called Quilt.

http://en.wikipedia.org/wiki/Quilt_(software)

There's Debian-specific documentation:

http://www.debian.org/doc/manuals/maint-guide/modify.en.html

Generally, the interaction with quilt goes like this:

1. Create me a new patch placeholder, called foo (quilt new foo)
2. Patch foo will modify file src/bar.c (quilt add src/bar.c)
3. Edit the file
4. Update the patch with my modifications (quilt refresh)
5. Record my comments on the patch (quilt header -e)

When you want to modify a patch, you go edit the sources again, and
call quilt refresh. Quilt stores its own state in a directory called
".pc".

Does anyone else have experience with quilt?

Maciej

From maciej at opencsw.org  Sun Jan  8 20:39:01 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 8 Jan 2012 19:39:01 +0000
Subject: [csw-maintainers] subversion-1.7.2 now with gnome-keyring,
 where to put command line keyring tool?
In-Reply-To: <CAJs9aZ_QF5gu523tUd2+WLX50GpRcMrXQUXiobkqkq3M_PPqQQ@mail.gmail.com>
References: <CAJs9aZ_t13bdQ5mF3ZjqvDigLyZN2HnEM-jRLidiON2vgkb-mA@mail.gmail.com>
	<1325270723-sup-2477@pinkfloyd.chass.utoronto.ca>
	<CAJs9aZ_QF5gu523tUd2+WLX50GpRcMrXQUXiobkqkq3M_PPqQQ@mail.gmail.com>
Message-ID: <CALtRa-4OeGS+Oe=WoT5ZotG6QPAf02DQfA+=OmzzB627MfRy6A@mail.gmail.com>

2012/1/5 rupert THURNER <rupert at opencsw.org>:
> subversion_contrib, and subversion_tools do not make sense any more for 1.7+
> as they are empty. is it sufficient to just remove them from the makefile?
> and how the package then gets removed from the "new catalogue"?

You need to think about it from the perspective of existing
installation. There are boxes out there with this package currently
installed. When you build and push a new version, people might upgrade
from any of the previously released versions. If someone upgrades from
1.6 with a contrib package with files, and you simply remove the
contrib package from the catalog, the installation will be left with
the old contrib files from the 1.6 series.

I suggest: for the dublin release, either ship an empty package or
declare an incompatibility in CSWsubversion on the contrib package.

When kiel comes along, only declare an incompatibility.

Removing packages from the catalog is currently done with
csw-upload-pkg --remove, but I've got feedback that the usage is
counter-intuitive (the same usage as adding packages to the catalog,
i.e. you refer to specific files by specifying paths to them). You can
either do it yourself (carefully) or ask someone else to do it for
you.

Maciej

From rupert at opencsw.org  Sun Jan  8 21:35:38 2012
From: rupert at opencsw.org (rupert THURNER)
Date: Sun, 8 Jan 2012 21:35:38 +0100
Subject: [csw-maintainers] Patch management with Quilt
In-Reply-To: <CALtRa-4f+oCgypB0v7Ba-EjAbGf5662WW3iwiS4ePgdbookvzg@mail.gmail.com>
References: <CALtRa-4f+oCgypB0v7Ba-EjAbGf5662WW3iwiS4ePgdbookvzg@mail.gmail.com>
Message-ID: <CAJs9aZ-GLK=DtuDRU6paRc-Zb1aJkPhXeYvODY2wbfy-Fp3tow@mail.gmail.com>

mercurial has mq for managing patches, and it is suggested that git
should not need a dedicated tool any more:
http://stackoverflow.com/questions/952651/git-equivalent-to-hg-mq

rupert.


2012/1/8 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
> Hello maintainers,
>
> Since we have automatic git integration in GAR builds, writing patches
> has become easier. However, there are still some wrinkles, for example
> there's no easy way to update a patch. We either need to create
> layered patches, or manually remove the patch, apply it off-gar,
> modify, and then re-create it.
>
> There is a piece of software which can maintain a mapping between
> patch files and upstream source files. It's called Quilt.
>
> http://en.wikipedia.org/wiki/Quilt_(software)
>
> There's Debian-specific documentation:
>
> http://www.debian.org/doc/manuals/maint-guide/modify.en.html
>
> Generally, the interaction with quilt goes like this:
>
> 1. Create me a new patch placeholder, called foo (quilt new foo)
> 2. Patch foo will modify file src/bar.c (quilt add src/bar.c)
> 3. Edit the file
> 4. Update the patch with my modifications (quilt refresh)
> 5. Record my comments on the patch (quilt header -e)
>
> When you want to modify a patch, you go edit the sources again, and
> call quilt refresh. Quilt stores its own state in a directory called
> ".pc".
>
> Does anyone else have experience with quilt?
>
> Maciej
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.

From maciej at opencsw.org  Mon Jan  9 01:18:01 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Mon, 9 Jan 2012 00:18:01 +0000
Subject: [csw-maintainers] Patch management with Quilt
In-Reply-To: <CAJs9aZ-GLK=DtuDRU6paRc-Zb1aJkPhXeYvODY2wbfy-Fp3tow@mail.gmail.com>
References: <CALtRa-4f+oCgypB0v7Ba-EjAbGf5662WW3iwiS4ePgdbookvzg@mail.gmail.com>
	<CAJs9aZ-GLK=DtuDRU6paRc-Zb1aJkPhXeYvODY2wbfy-Fp3tow@mail.gmail.com>
Message-ID: <CALtRa-6uF4fbWWX1_bog+Ck_i_1yYv5hsvLJfnL6GSFwNRtW1w@mail.gmail.com>

2012/1/8 rupert THURNER <rupert at opencsw.org>:
> mercurial has mq for managing patches, and it is suggested that git
> should not need a dedicated tool any more:
> http://stackoverflow.com/questions/952651/git-equivalent-to-hg-mq

What would the w full workflow look like? For example you write a
patch, and then you realize you need to modify it. How do you modify
the patch?

From bwalton at opencsw.org  Mon Jan  9 03:36:27 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 08 Jan 2012 21:36:27 -0500
Subject: [csw-maintainers] Patch management with Quilt
In-Reply-To: <CAJs9aZ-GLK=DtuDRU6paRc-Zb1aJkPhXeYvODY2wbfy-Fp3tow@mail.gmail.com>
References: <CALtRa-4f+oCgypB0v7Ba-EjAbGf5662WW3iwiS4ePgdbookvzg@mail.gmail.com>
	<CAJs9aZ-GLK=DtuDRU6paRc-Zb1aJkPhXeYvODY2wbfy-Fp3tow@mail.gmail.com>
Message-ID: <1326076133-sup-7015@pinkfloyd.chass.utoronto.ca>

Excerpts from rupert THURNER's message of Sun Jan 08 15:35:38 -0500 2012:

> mercurial has mq for managing patches, and it is suggested that git
> should not need a dedicated tool any more:
> http://stackoverflow.com/questions/952651/git-equivalent-to-hg-mq

There are two cases to content with here:

1. Updating a patch that still applies.
2. Updating a patch that no longer applies.

For patches that apply still, I think the stack overflow thread
provides sound advice in that git rebase -i is the way to go.  All
patches that get applied are done on a 'csw' branch, so an interactive
rebase against master (or the upstream tag) should be pretty sane.  A
new series of patches for GAR can then be generated with:

git format-patch upstream

Those files should then replace the list of files used in PATCHFILES.

This action could be rolled up in a GAR updatepatches command or
something although I'm not sure of a good way to handle botched
updates short of telling people to do an 'svn revert files/; mgar
spotless; mgar patch' and starting over.

The case where an old patch no longer applies can be handled by either
dropping it or manually recreating it.  In some cases, applying the
patch file with the actual patch command (and a higher fuzz level)
might be useful if the patch is valid but doesn't apply because the
new upstream file has significant changes.  I don't see a good way to
automate this in GAR though.
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From bwalton at opencsw.org  Tue Jan 10 04:04:32 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 09 Jan 2012 22:04:32 -0500
Subject: [csw-maintainers] pkgutil bugs in Mantis now listed as pkg-get
	bugs..?
In-Reply-To: <CABY0g1X2znKRHwS4EBfM1jbFLog2=cN+4LTDTajbZtL0u3zRog@mail.gmail.com>
References: <CABY0g1X2znKRHwS4EBfM1jbFLog2=cN+4LTDTajbZtL0u3zRog@mail.gmail.com>
Message-ID: <1326164430-sup-1649@pinkfloyd.chass.utoronto.ca>

Excerpts from Peter Bonivart's message of Mon Jan 02 04:14:34 -0500 2012:

Hi Peter,

> I noticed on Dagos bug summary page that my pkgutil bugs were gone
> so I dug up the latest e-mail notification and clicked on the links
> there. The problem seems to be that they are now assigned to
> pkg-get.  Is this related to pkg-get being deprecated?

I'm looking into why this happened.  It looks as though you already
moved them back to the correct project, so I'll simply work to prevent
it from occurring again.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From maciej at opencsw.org  Sun Jan 15 13:21:44 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 15 Jan 2012 12:21:44 +0000
Subject: [csw-maintainers] progress report
In-Reply-To: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca>
References: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca>
Message-ID: <CALtRa-52rNEh_thtc_f56zPfG-z+gdgaLp_qztO6k5HJSntKKg@mail.gmail.com>

2011/7/20 Ben Walton <bwalton at opencsw.org>:
> The code is in a git repository:
> gitosis at mirror.opencsw.org:cswsign.git
>
> We don't have gitweb enabled there, but if you want access, I'll add
> your public key so you can check it out. ?We could host this in the
> github/opencsw framework that Rupert has been working on if that's
> considered better (likely).

I would vote for hosting it in a way that is accessible from outside
the buildfarm. I often do coding locally to avoid network lag in an
interactive session, I also have faster cores available locally. We
can do onsite / internal backups, but as far as usability is
concerned, but this doesn't mean we can't use a solution which is easy
in a day-to-day use.

Maciej

From maciej at opencsw.org  Sun Jan 15 14:08:04 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 15 Jan 2012 13:08:04 +0000
Subject: [csw-maintainers] A systematic approach to package renames
Message-ID: <CALtRa-4Xn7=5_bJZ0vwybfAkO-99LjsquyfxO8w2HFRvjYC_Og@mail.gmail.com>

A package rename generally consists of two transitions; and there are
three states a package can be in:

1. Regular package foo/CSWfoo
2. A stub foo_stub/CSWfoo
3. Absent from catalog, with another package declared as incompatible
with CSWfoo, the idea is that pkgutil would remove CSWfoo

So far, each maintainer tracked in their heads the states of their
packages. It's easy when you maintain 5 packages, but quickly gets
confusing as the number of packages increases. I think we'd be better
off with a systematic approach. I already hacked some code to analyze
the transitions, but it's nothing really useful yet. I think that
Ben's integration scripts already have a lot of relevant logic, e.g.
detecting both catalogname and pkgname changes.

I would imagine a tool that would retrieve catalog metadata, analyze
the state and detect errors / make suggestions. For example:

- Opportunity: Package foo_stub present in dublin, so it could be
transitioned to the next stage in the next release
- Error: Package foo present in dublin, but there is no foo nor
foo_stub in unstable; premature package removal
- Unnecessary stub: package foo_stub present in unstable, but there is
no foo in dublin

Thoughts?

Maciej

From maciej at opencsw.org  Sun Jan 15 20:00:35 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 15 Jan 2012 19:00:35 +0000
Subject: [csw-maintainers] Patch management with Quilt
In-Reply-To: <1326076133-sup-7015@pinkfloyd.chass.utoronto.ca>
References: <CALtRa-4f+oCgypB0v7Ba-EjAbGf5662WW3iwiS4ePgdbookvzg@mail.gmail.com>
	<CAJs9aZ-GLK=DtuDRU6paRc-Zb1aJkPhXeYvODY2wbfy-Fp3tow@mail.gmail.com>
	<1326076133-sup-7015@pinkfloyd.chass.utoronto.ca>
Message-ID: <CALtRa-4DWvNofDF7MBzMRBGPaOdmAEZmg2ixzDsBcvGSXc6ttQ@mail.gmail.com>

2012/1/9 Ben Walton <bwalton at opencsw.org>:
> There are two cases to content with here:
>
> 1. Updating a patch that still applies.
> 2. Updating a patch that no longer applies.
>
> For patches that apply still, I think the stack overflow thread
> provides sound advice in that git rebase -i is the way to go. ?All
> patches that get applied are done on a 'csw' branch, so an interactive
> rebase against master (or the upstream tag) should be pretty sane. ?A
> new series of patches for GAR can then be generated with:
>
> git format-patch upstream

Did anyone had a chance to go over an example package and write out
every command that you have to type to do it?

Maciej

From bwalton at opencsw.org  Sun Jan 15 20:14:06 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 15 Jan 2012 14:14:06 -0500
Subject: [csw-maintainers] A systematic approach to package renames
In-Reply-To: <CALtRa-4Xn7=5_bJZ0vwybfAkO-99LjsquyfxO8w2HFRvjYC_Og@mail.gmail.com>
References: <CALtRa-4Xn7=5_bJZ0vwybfAkO-99LjsquyfxO8w2HFRvjYC_Og@mail.gmail.com>
Message-ID: <1326654445-sup-2754@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej (Matchek) Blizi?ski's message of Sun Jan 15 08:08:04 -0500 2012:

> So far, each maintainer tracked in their heads the states of their
> packages. It's easy when you maintain 5 packages, but quickly gets
> confusing as the number of packages increases. I think we'd be

Yes, this does get to be a lot of state to maintain.

> better off with a systematic approach. I already hacked some code to
> analyze the transitions, but it's nothing really useful yet. I think
> that Ben's integration scripts already have a lot of relevant logic,
> e.g.  detecting both catalogname and pkgname changes.

There is a lot of this logic encapsulated.  It would need to be
factored a bit to make it a generally useful standalone library, but
that shouldn't be too bad, I don't think.

> I would imagine a tool that would retrieve catalog metadata, analyze
> the state and detect errors / make suggestions. For example:
> 
> - Opportunity: Package foo_stub present in dublin, so it could be
> transitioned to the next stage in the next release

Yes, this would be good to catch.  (Skipping the generation of stub
packages automatically once they're released would be cool too but
that's a different topic.)

> - Error: Package foo present in dublin, but there is no foo nor
> foo_stub in unstable; premature package removal

This could also be a normal package drop.  Eg: apache1.  I would say
that this is a warning at most.  (But you're talking about generating
suggestions anyway, so that an equivalent.)

> - Unnecessary stub: package foo_stub present in unstable, but there
> is no foo in dublin

This _could_ happen legitimately if a package is reshaped while it's
in unstable.  The likelihood of this increases with the length of time
between cutting stable catalogs.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From maciej at opencsw.org  Sun Jan 15 20:16:14 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 15 Jan 2012 19:16:14 +0000
Subject: [csw-maintainers] Catalog checks via REST
In-Reply-To: <CABY0g1U0h8yhYwfsSk_EcO=zMjrUuzUVDpr9gdgHpzNFby__gg@mail.gmail.com>
References: <CALtRa-5zaZub2i=y33ik3uTkvvpyu+L6akkekcVsP1CoTUChOg@mail.gmail.com>
	<C5B7D102-40BD-49FD-9334-E472AF584682@opencsw.org>
	<CALtRa-6pmB96MzXJs_gseDJLEbgjvdcKX_EgZrPACUtRzjjiUw@mail.gmail.com>
	<033689A1-FD32-4DCB-9CE3-6C68D3AF6B4B@opencsw.org>
	<CALtRa-4xOkhzsWVDF0E0_vuvYyiBB5_nZwwav78XjYEtt+0kNg@mail.gmail.com>
	<CALtRa-6OSv+pBtRFAg6W4u4sjkodXrzCaHRZdxiZ7cjBOUBJ0g@mail.gmail.com>
	<CABY0g1VwS1p7Gm8Mz0yL7MD5SaSYYRohtvKwMt_JvNeS1vHgBw@mail.gmail.com>
	<65B032CA-3C2D-4030-B1AA-5CF7C1086E42@opencsw.org>
	<CABY0g1U0h8yhYwfsSk_EcO=zMjrUuzUVDpr9gdgHpzNFby__gg@mail.gmail.com>
Message-ID: <CALtRa-4902T_ETsdRoQCr1Yhen9+scqkgZfO+kVFjWkY+5fwTA@mail.gmail.com>

2012/1/2 Peter Bonivart <bonivart at opencsw.org>:
> Thanks Dago! So on the server side csw-upload-pkg could trigger a
> catalog generation which would be checked by chkcat immediately so
> csw-upload-pkg could respond to the user directly.

Can you rephrase? I'm not sure how you mean. There is no catalog
generation on the web backend (pkgdb_web.py), it's done from a cron
job.

From bwalton at opencsw.org  Sun Jan 15 20:24:26 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 15 Jan 2012 14:24:26 -0500
Subject: [csw-maintainers] progress report
In-Reply-To: <CALtRa-52rNEh_thtc_f56zPfG-z+gdgaLp_qztO6k5HJSntKKg@mail.gmail.com>
References: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca>
	<CALtRa-52rNEh_thtc_f56zPfG-z+gdgaLp_qztO6k5HJSntKKg@mail.gmail.com>
Message-ID: <1326655377-sup-8060@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej (Matchek) Blizi?ski's message of Sun Jan 15 07:21:44 -0500 2012:
> 2011/7/20 Ben Walton <bwalton at opencsw.org>:
> > The code is in a git repository:
> > gitosis at mirror.opencsw.org:cswsign.git
> >
> > We don't have gitweb enabled there, but if you want access, I'll add
> > your public key so you can check it out. ?We could host this in the
> > github/opencsw framework that Rupert has been working on if that's
> > considered better (likely).
> 
> I would vote for hosting it in a way that is accessible from outside
> the buildfarm. I often do coding locally to avoid network lag in an
> interactive session, I also have faster cores available locally. We
> can do onsite / internal backups, but as far as usability is
> concerned, but this doesn't mean we can't use a solution which is
> easy in a day-to-day use.

If we open the required ports from mirror.opencsw.org (ssh, maybe
git), this can be accessible off-buildfarm.  It could also be rolled
into the svn tree (Peter F's preference iirc).

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From dam at opencsw.org  Sun Jan 15 20:34:37 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 15 Jan 2012 20:34:37 +0100
Subject: [csw-maintainers] Catalog checks via REST
In-Reply-To: <CALtRa-4902T_ETsdRoQCr1Yhen9+scqkgZfO+kVFjWkY+5fwTA@mail.gmail.com>
References: <CALtRa-5zaZub2i=y33ik3uTkvvpyu+L6akkekcVsP1CoTUChOg@mail.gmail.com>
	<C5B7D102-40BD-49FD-9334-E472AF584682@opencsw.org>
	<CALtRa-6pmB96MzXJs_gseDJLEbgjvdcKX_EgZrPACUtRzjjiUw@mail.gmail.com>
	<033689A1-FD32-4DCB-9CE3-6C68D3AF6B4B@opencsw.org>
	<CALtRa-4xOkhzsWVDF0E0_vuvYyiBB5_nZwwav78XjYEtt+0kNg@mail.gmail.com>
	<CALtRa-6OSv+pBtRFAg6W4u4sjkodXrzCaHRZdxiZ7cjBOUBJ0g@mail.gmail.com>
	<CABY0g1VwS1p7Gm8Mz0yL7MD5SaSYYRohtvKwMt_JvNeS1vHgBw@mail.gmail.com>
	<65B032CA-3C2D-4030-B1AA-5CF7C1086E42@opencsw.org>
	<CABY0g1U0h8yhYwfsSk_EcO=zMjrUuzUVDpr9gdgHpzNFby__gg@mail.gmail.com>
	<CALtRa-4902T_ETsdRoQCr1Yhen9+scqkgZfO+kVFjWkY+5fwTA@mail.gmail.com>
Message-ID: <9B7B3237-29ED-45D1-9273-3977EDACECFB@opencsw.org>

Hi Maciej,

Am 15.01.2012 um 20:16 schrieb Maciej (Matchek) Blizi?ski:
> 2012/1/2 Peter Bonivart <bonivart at opencsw.org>:
>> Thanks Dago! So on the server side csw-upload-pkg could trigger a
>> catalog generation which would be checked by chkcat immediately so
>> csw-upload-pkg could respond to the user directly.
> 
> Can you rephrase? I'm not sure how you mean. There is no catalog
> generation on the web backend (pkgdb_web.py), it's done from a cron
> job.

I think Peters idea is to glue this together and not allow uploads to the
catalog which would break it. If it is not possible to do that easily with
Rest it may be worthwhile to reimplement the checks in python.


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 Jan 15 20:38:22 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 15 Jan 2012 19:38:22 +0000
Subject: [csw-maintainers] Catalog checks via REST
In-Reply-To: <9B7B3237-29ED-45D1-9273-3977EDACECFB@opencsw.org>
References: <CALtRa-5zaZub2i=y33ik3uTkvvpyu+L6akkekcVsP1CoTUChOg@mail.gmail.com>
	<C5B7D102-40BD-49FD-9334-E472AF584682@opencsw.org>
	<CALtRa-6pmB96MzXJs_gseDJLEbgjvdcKX_EgZrPACUtRzjjiUw@mail.gmail.com>
	<033689A1-FD32-4DCB-9CE3-6C68D3AF6B4B@opencsw.org>
	<CALtRa-4xOkhzsWVDF0E0_vuvYyiBB5_nZwwav78XjYEtt+0kNg@mail.gmail.com>
	<CALtRa-6OSv+pBtRFAg6W4u4sjkodXrzCaHRZdxiZ7cjBOUBJ0g@mail.gmail.com>
	<CABY0g1VwS1p7Gm8Mz0yL7MD5SaSYYRohtvKwMt_JvNeS1vHgBw@mail.gmail.com>
	<65B032CA-3C2D-4030-B1AA-5CF7C1086E42@opencsw.org>
	<CABY0g1U0h8yhYwfsSk_EcO=zMjrUuzUVDpr9gdgHpzNFby__gg@mail.gmail.com>
	<CALtRa-4902T_ETsdRoQCr1Yhen9+scqkgZfO+kVFjWkY+5fwTA@mail.gmail.com>
	<9B7B3237-29ED-45D1-9273-3977EDACECFB@opencsw.org>
Message-ID: <CALtRa-7QNVzEY0LiofRm9ixhp=5CcSWL1H9icKw_ex+qx9qweA@mail.gmail.com>

2012/1/15 Dagobert Michelsen <dam at opencsw.org>:
> I think Peters idea is to glue this together and not allow uploads to the
> catalog which would break it. If it is not possible to do that easily with
> Rest it may be worthwhile to reimplement the checks in python.

This is already the case; if chkcat reports a failure (non zero status
code), the script stops and does not push the catalogs.

We just don't get any information back.

From pfelecan at opencsw.org  Sun Jan 15 20:39:20 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sun, 15 Jan 2012 20:39:20 +0100
Subject: [csw-maintainers] progress report
In-Reply-To: <1326655377-sup-8060@pinkfloyd.chass.utoronto.ca> (Ben Walton's
	message of "Sun, 15 Jan 2012 14:24:26 -0500")
References: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca>
	<CALtRa-52rNEh_thtc_f56zPfG-z+gdgaLp_qztO6k5HJSntKKg@mail.gmail.com>
	<1326655377-sup-8060@pinkfloyd.chass.utoronto.ca>
Message-ID: <x6zkdo7o2f.fsf@opencsw.org>

Ben Walton <bwalton at opencsw.org> writes:

> Excerpts from Maciej (Matchek) Blizi?ski's message of Sun Jan 15 07:21:44 -0500 2012:
>> 2011/7/20 Ben Walton <bwalton at opencsw.org>:
>> > The code is in a git repository:
>> > gitosis at mirror.opencsw.org:cswsign.git
>> >
>> > We don't have gitweb enabled there, but if you want access, I'll add
>> > your public key so you can check it out. ?We could host this in the
>> > github/opencsw framework that Rupert has been working on if that's
>> > considered better (likely).
>> 
>> I would vote for hosting it in a way that is accessible from outside
>> the buildfarm. I often do coding locally to avoid network lag in an
>> interactive session, I also have faster cores available locally. We
>> can do onsite / internal backups, but as far as usability is
>> concerned, but this doesn't mean we can't use a solution which is
>> easy in a day-to-day use.
>
> If we open the required ports from mirror.opencsw.org (ssh, maybe
> git), this can be accessible off-buildfarm.  It could also be rolled
> into the svn tree (Peter F's preference iirc).

Yeah. Also, I thought that subversion is our SCM of choice but it seams
that there are as many as people.
-- 
Peter

From dam at opencsw.org  Sun Jan 15 20:47:33 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 15 Jan 2012 20:47:33 +0100
Subject: [csw-maintainers] progress report
In-Reply-To: <x6zkdo7o2f.fsf@opencsw.org>
References: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca>
	<CALtRa-52rNEh_thtc_f56zPfG-z+gdgaLp_qztO6k5HJSntKKg@mail.gmail.com>
	<1326655377-sup-8060@pinkfloyd.chass.utoronto.ca>
	<x6zkdo7o2f.fsf@opencsw.org>
Message-ID: <0AD17176-7B99-453F-A9F9-BC0F4EE421CE@opencsw.org>

Hi folks,

Am 15.01.2012 um 20:39 schrieb Peter FELECAN:
> Ben Walton <bwalton at opencsw.org> writes:
>> Excerpts from Maciej (Matchek) Blizi?ski's message of Sun Jan 15 07:21:44 -0500 2012:
>>> 2011/7/20 Ben Walton <bwalton at opencsw.org>:
>>>> The code is in a git repository:
>>>> gitosis at mirror.opencsw.org:cswsign.git
>>>> 
>>>> We don't have gitweb enabled there, but if you want access, I'll add
>>>> your public key so you can check it out.  We could host this in the
>>>> github/opencsw framework that Rupert has been working on if that's
>>>> considered better (likely).
>>> 
>>> I would vote for hosting it in a way that is accessible from outside
>>> the buildfarm. I often do coding locally to avoid network lag in an
>>> interactive session, I also have faster cores available locally. We
>>> can do onsite / internal backups, but as far as usability is
>>> concerned, but this doesn't mean we can't use a solution which is
>>> easy in a day-to-day use.
>> 
>> If we open the required ports from mirror.opencsw.org (ssh, maybe
>> git), this can be accessible off-buildfarm.  It could also be rolled
>> into the svn tree (Peter F's preference iirc).

Just wait: mirror.opencsw.org was the same host as buildfarm.opencsw.org
some time ago, but now mirror.* is the official mirror in Erlangen
while buildfarm is still the buildfarm. I suggest just using buildfarm*
for access and it should work immediately without any port changes.

> Yeah. Also, I thought that subversion is our SCM of choice but it seams
> that there are as many as people.

Subversion is our SCM of choice, however, if any one is feeling better
by using private gateways to any other repo he is free to do so.


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 Jan 15 21:12:33 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 15 Jan 2012 20:12:33 +0000
Subject: [csw-maintainers] progress report
In-Reply-To: <0AD17176-7B99-453F-A9F9-BC0F4EE421CE@opencsw.org>
References: <1311126906-sup-2591@pinkfloyd.chass.utoronto.ca>
	<CALtRa-52rNEh_thtc_f56zPfG-z+gdgaLp_qztO6k5HJSntKKg@mail.gmail.com>
	<1326655377-sup-8060@pinkfloyd.chass.utoronto.ca>
	<x6zkdo7o2f.fsf@opencsw.org>
	<0AD17176-7B99-453F-A9F9-BC0F4EE421CE@opencsw.org>
Message-ID: <CALtRa-6_nJTzs8ZwYWPrijfLJ13jg5nBfhMDz1+qEhVX687yCQ@mail.gmail.com>

2012/1/15 Dagobert Michelsen <dam at opencsw.org>:
> Subversion is our SCM of choice, however, if any one is feeling better
> by using private gateways to any other repo he is free to do so.

Subversion is our lowest common denominator. However, if anyone wishes
to use a different SCM locally, there bridges between subversion and
most of the other SCM systems. I personally use git-svn for code
development and raw subversion (although mgar wrapped) to submit
recipe updates.

I would suggest that others do the same thing - use our Subversion
repositories, while selecting their own frontends as they wish. This
way, it is reasonably easy to work with our shared code.

Maciej

From bonivart at opencsw.org  Sun Jan 15 21:20:23 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 15 Jan 2012 21:20:23 +0100
Subject: [csw-maintainers] Catalog checks via REST
In-Reply-To: <CALtRa-4902T_ETsdRoQCr1Yhen9+scqkgZfO+kVFjWkY+5fwTA@mail.gmail.com>
References: <CALtRa-5zaZub2i=y33ik3uTkvvpyu+L6akkekcVsP1CoTUChOg@mail.gmail.com>
	<C5B7D102-40BD-49FD-9334-E472AF584682@opencsw.org>
	<CALtRa-6pmB96MzXJs_gseDJLEbgjvdcKX_EgZrPACUtRzjjiUw@mail.gmail.com>
	<033689A1-FD32-4DCB-9CE3-6C68D3AF6B4B@opencsw.org>
	<CALtRa-4xOkhzsWVDF0E0_vuvYyiBB5_nZwwav78XjYEtt+0kNg@mail.gmail.com>
	<CALtRa-6OSv+pBtRFAg6W4u4sjkodXrzCaHRZdxiZ7cjBOUBJ0g@mail.gmail.com>
	<CABY0g1VwS1p7Gm8Mz0yL7MD5SaSYYRohtvKwMt_JvNeS1vHgBw@mail.gmail.com>
	<65B032CA-3C2D-4030-B1AA-5CF7C1086E42@opencsw.org>
	<CABY0g1U0h8yhYwfsSk_EcO=zMjrUuzUVDpr9gdgHpzNFby__gg@mail.gmail.com>
	<CALtRa-4902T_ETsdRoQCr1Yhen9+scqkgZfO+kVFjWkY+5fwTA@mail.gmail.com>
Message-ID: <CABY0g1X9DEhRfF2hEFJgJyGp0qLAhfNQYmLdmi-M9Xp6YRbLLQ@mail.gmail.com>

2012/1/15 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
> Can you rephrase? I'm not sure how you mean. There is no catalog
> generation on the web backend (pkgdb_web.py), it's done from a cron
> job.

Yes, but if the database was complete, as in having all needed info to
create a catalog, it would take no time to temporarily generate and
check one integrated in the upload procedure.

From maciej at opencsw.org  Sun Jan 15 22:19:47 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 15 Jan 2012 21:19:47 +0000
Subject: [csw-maintainers] Catalog checks via REST
In-Reply-To: <CABY0g1X9DEhRfF2hEFJgJyGp0qLAhfNQYmLdmi-M9Xp6YRbLLQ@mail.gmail.com>
References: <CALtRa-5zaZub2i=y33ik3uTkvvpyu+L6akkekcVsP1CoTUChOg@mail.gmail.com>
	<C5B7D102-40BD-49FD-9334-E472AF584682@opencsw.org>
	<CALtRa-6pmB96MzXJs_gseDJLEbgjvdcKX_EgZrPACUtRzjjiUw@mail.gmail.com>
	<033689A1-FD32-4DCB-9CE3-6C68D3AF6B4B@opencsw.org>
	<CALtRa-4xOkhzsWVDF0E0_vuvYyiBB5_nZwwav78XjYEtt+0kNg@mail.gmail.com>
	<CALtRa-6OSv+pBtRFAg6W4u4sjkodXrzCaHRZdxiZ7cjBOUBJ0g@mail.gmail.com>
	<CABY0g1VwS1p7Gm8Mz0yL7MD5SaSYYRohtvKwMt_JvNeS1vHgBw@mail.gmail.com>
	<65B032CA-3C2D-4030-B1AA-5CF7C1086E42@opencsw.org>
	<CABY0g1U0h8yhYwfsSk_EcO=zMjrUuzUVDpr9gdgHpzNFby__gg@mail.gmail.com>
	<CALtRa-4902T_ETsdRoQCr1Yhen9+scqkgZfO+kVFjWkY+5fwTA@mail.gmail.com>
	<CABY0g1X9DEhRfF2hEFJgJyGp0qLAhfNQYmLdmi-M9Xp6YRbLLQ@mail.gmail.com>
Message-ID: <CALtRa-4kGcXwW4hzmxxNv5_cHXy6mV_L92+SBis-m5L4RF5W0A@mail.gmail.com>

2012/1/15 Peter Bonivart <bonivart at opencsw.org>:
> 2012/1/15 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
>> Can you rephrase? I'm not sure how you mean. There is no catalog
>> generation on the web backend (pkgdb_web.py), it's done from a cron
>> job.
>
> Yes, but if the database was complete, as in having all needed info to
> create a catalog, it would take no time to temporarily generate and
> check one integrated in the upload procedure.

The main topic is how we know that something's broken. We're lacking a
piece of code which would let us know that something's broken. Whether
it's in a web backend or a cron job, is a secondary issue. The
important one is that we receive a meaningful information when things
break. I thought that this could be done by a separate piece of code,
following the KISS principle.

The bad catalogs aren't pushed, so parsing catalog files could not be
used for this purpose, only the REST interface allows access to that
data.

As Dago noted, the way the data are provided right now is quite slow
(although I didn't see any numbers), a speedup will require database
schema change. I can't give any time line right now, if anyone cares
about improving our database backend, I'll be happy to help them
familiarize with the code base.

Maciej

From maciej at opencsw.org  Sun Jan 15 22:25:07 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 15 Jan 2012 21:25:07 +0000
Subject: [csw-maintainers] A systematic approach to package renames
In-Reply-To: <1326654445-sup-2754@pinkfloyd.chass.utoronto.ca>
References: <CALtRa-4Xn7=5_bJZ0vwybfAkO-99LjsquyfxO8w2HFRvjYC_Og@mail.gmail.com>
	<1326654445-sup-2754@pinkfloyd.chass.utoronto.ca>
Message-ID: <CALtRa-5XL8KD+Arnfe-T6-kPGD6Axd+sCbSwQLq3-G5iyPRPjQ@mail.gmail.com>

2012/1/15 Ben Walton <bwalton at opencsw.org>:
>> better off with a systematic approach. I already hacked some code to
>> analyze the transitions, but it's nothing really useful yet. I think
>> that Ben's integration scripts already have a lot of relevant logic,
>> e.g. ?detecting both catalogname and pkgname changes.
>
> There is a lot of this logic encapsulated. ?It would need to be
> factored a bit to make it a generally useful standalone library, but
> that shouldn't be too bad, I don't think.

Can you give any pointers? For example, which classes / functions in
which files would they be?

>> I would imagine a tool that would retrieve catalog metadata, analyze
>> the state and detect errors / make suggestions. For example:
>>
>> - Opportunity: Package foo_stub present in dublin, so it could be
>> transitioned to the next stage in the next release
>
> Yes, this would be good to catch. ?(Skipping the generation of stub
> packages automatically once they're released would be cool too but
> that's a different topic.)
>
>> - Error: Package foo present in dublin, but there is no foo nor
>> foo_stub in unstable; premature package removal
>
> This could also be a normal package drop. ?Eg: apache1. ?I would say
> that this is a warning at most. ?(But you're talking about generating
> suggestions anyway, so that an equivalent.)

Yes, this would be only a suggestion.

>> - Unnecessary stub: package foo_stub present in unstable, but there
>> is no foo in dublin
>
> This _could_ happen legitimately if a package is reshaped while it's
> in unstable. ?The likelihood of this increases with the length of time
> between cutting stable catalogs.

It depends whether it's a package that you specifically care about,
with a specific program, or a package that was just pulled in as a
dependency.

One more thing to catch: foo_stub packages that do not have any
reverse dependencies, and therefore can be dropped. Same thing applies
to shared libraries, e.g. CSWlibfoo1 with no reverse dependencies when
all programs are relinked against CSWlibfoo2.

Maciej

From bonivart at opencsw.org  Sun Jan 15 23:20:14 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 15 Jan 2012 23:20:14 +0100
Subject: [csw-maintainers] Catalog checks via REST
In-Reply-To: <CALtRa-4kGcXwW4hzmxxNv5_cHXy6mV_L92+SBis-m5L4RF5W0A@mail.gmail.com>
References: <CALtRa-5zaZub2i=y33ik3uTkvvpyu+L6akkekcVsP1CoTUChOg@mail.gmail.com>
	<C5B7D102-40BD-49FD-9334-E472AF584682@opencsw.org>
	<CALtRa-6pmB96MzXJs_gseDJLEbgjvdcKX_EgZrPACUtRzjjiUw@mail.gmail.com>
	<033689A1-FD32-4DCB-9CE3-6C68D3AF6B4B@opencsw.org>
	<CALtRa-4xOkhzsWVDF0E0_vuvYyiBB5_nZwwav78XjYEtt+0kNg@mail.gmail.com>
	<CALtRa-6OSv+pBtRFAg6W4u4sjkodXrzCaHRZdxiZ7cjBOUBJ0g@mail.gmail.com>
	<CABY0g1VwS1p7Gm8Mz0yL7MD5SaSYYRohtvKwMt_JvNeS1vHgBw@mail.gmail.com>
	<65B032CA-3C2D-4030-B1AA-5CF7C1086E42@opencsw.org>
	<CABY0g1U0h8yhYwfsSk_EcO=zMjrUuzUVDpr9gdgHpzNFby__gg@mail.gmail.com>
	<CALtRa-4902T_ETsdRoQCr1Yhen9+scqkgZfO+kVFjWkY+5fwTA@mail.gmail.com>
	<CABY0g1X9DEhRfF2hEFJgJyGp0qLAhfNQYmLdmi-M9Xp6YRbLLQ@mail.gmail.com>
	<CALtRa-4kGcXwW4hzmxxNv5_cHXy6mV_L92+SBis-m5L4RF5W0A@mail.gmail.com>
Message-ID: <CABY0g1W3Vod557Fu_F22RcP7KdJHV37GMMUyd1-1Sacn3s1rsA@mail.gmail.com>

2012/1/15 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
> The bad catalogs aren't pushed, so parsing catalog files could not be
> used for this purpose, only the REST interface allows access to that
> data.

I'm not talking about pushing the catalogs, I'm talking about getting
info about a bad upload during the upload, the same thing you have
brought up earlier.

If the database contained everything needed for a catalog to be
generated directly from it one could be created temporarily, checked
by chkcat and the result could be returned to csw-upload-pkg. With the
new chkcat I think this could be done in 1-2 seconds per catalog max.

This has nothing to do with the actual creation of official catalogs,
they could still be generated from a cron job.

From maciej at opencsw.org  Mon Jan 16 10:33:40 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Mon, 16 Jan 2012 09:33:40 +0000
Subject: [csw-maintainers] Cyrus imapd update
Message-ID: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>

Looks like we need to rebuild Cyrus imapd together with sasl. I looked
at the current situation and found this:

- the unstable catalog contains version 2.3.16
  http://mirror.opencsw.org/opencsw/unstable/i386/5.10/catalog
- the website declares it's at 2.4.6
  http://www.opencsw.org/packages/cyrus_imapd/
- the build recipe is at 2.4.10
  https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/cyrus_imapd/trunk/Makefile
- the newest upstream version is 2.4.13
  ftp://ftp.cyrusimap.org/cyrus-imapd/

I don't know how we got into this state, but in a perfect world at
least the first three should match.

Yann, can you tell what's the current situation with this package?
What are the main challenges in getting a new version released?

Maciej

From bwalton at opencsw.org  Mon Jan 16 16:55:37 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 16 Jan 2012 10:55:37 -0500
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
Message-ID: <1326729201-sup-7253@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej (Matchek) Blizi?ski's message of Mon Jan 16 04:33:40 -0500 2012:

> - the unstable catalog contains version 2.3.16
>   http://mirror.opencsw.org/opencsw/unstable/i386/5.10/catalog

> - the website declares it's at 2.4.6
>   http://www.opencsw.org/packages/cyrus_imapd/

This is likely an artifact from the old processes.  If I recall
correctly, this package submission triggered a discussion about file
collisions (/opt/csw/bin/imapd) and the registration of the update was
never completed.

> I don't know how we got into this state, but in a perfect world at
> least the first three should match.

Registrations that failed with a file collision leave things in a half
baked-state.  In fact, I think the new code likely does this too.  I
should change the ordering such that files are registered for a new
package before we touch the other data.  That would let us fail early
on a package leaving only that table inconsistent.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From maciej at opencsw.org  Mon Jan 16 19:52:57 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Mon, 16 Jan 2012 18:52:57 +0000
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
Message-ID: <CALtRa-4WrAFkOcu+Cyh0Opd6XuH9JvDLhmRCeECH01Kos2KrQw@mail.gmail.com>

I've built Cyrus 2.4.10 against Berkeley 4.7 and put it into my
experimental catalog:

http://buildfarm.opencsw.org/experimental.html#maciej

I don't know how to test it.

Rafael, you could use the Cyrus build recipe to rebuild Cyrus; you can
now rebuild both Cyrus and SASL, and release them together.

Maciej

From maciej at opencsw.org  Tue Jan 17 00:18:40 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Mon, 16 Jan 2012 23:18:40 +0000
Subject: [csw-maintainers] Cross-distro track at FOSDEM 2012
Message-ID: <CALtRa-6NmSz-L+dthygTPE6Gpr=zjr7dUjw0ZoQ69JFg_iC1LQ@mail.gmail.com>

FOSDEM 2012 is getting closer and closer. Dagobert and I are going, is
anyone else going too?

Apart from the official grid, there's also a cross-distribution track.
I found the schedule:

https://penta.fosdem.org/xdistro/schedule.txt

There are some interesting talks, here's an appetizer:

11:30-12:00 Serafeim Zanikolas: Debian DEP9 // How to replace a legacy
tool with 100k installations and 50 reverse package dependencies in
Debian

Sounds a lot like what we do, just a bit bigger.

Maciej

From bwalton at opencsw.org  Tue Jan 17 02:56:07 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 16 Jan 2012 20:56:07 -0500
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <1326729201-sup-7253@pinkfloyd.chass.utoronto.ca>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
	<1326729201-sup-7253@pinkfloyd.chass.utoronto.ca>
Message-ID: <1326765227-sup-4876@pinkfloyd.chass.utoronto.ca>

Excerpts from Ben Walton's message of Mon Jan 16 10:55:37 -0500 2012:

> Registrations that failed with a file collision leave things in a
> half baked-state.  In fact, I think the new code likely does this
> too.  I should change the ordering such that files are registered
> for a new package before we touch the other data.  That would let us
> fail early on a package leaving only that table inconsistent.

Thinking more about this, I don't think the proposed change makes
sense...previously, the package didn't hit the catalog if the path
collision checks failed at registration time.  Now, the package is
already on the mirrors by the time the registration code sees it.
Thus, failing early doesn't buy anything and would actually make the
web information less consistent since old version info would be
presented while mirrors and catalogs contained the new version.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From raos at opencsw.org  Tue Jan 17 08:33:03 2012
From: raos at opencsw.org (Rafael Ostertag)
Date: Tue, 17 Jan 2012 08:33:03 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <CALtRa-4WrAFkOcu+Cyh0Opd6XuH9JvDLhmRCeECH01Kos2KrQw@mail.gmail.com>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
	<CALtRa-4WrAFkOcu+Cyh0Opd6XuH9JvDLhmRCeECH01Kos2KrQw@mail.gmail.com>
Message-ID: <20120117073303.GG19279@bender.opencsw.org>

Hi Maciej
On Mon, Jan 16, 2012 at 06:52:57PM +0000, Maciej (Matchek) Blizi??ski wrote:
> I've built Cyrus 2.4.10 against Berkeley 4.7 and put it into my
> experimental catalog:
> 
> http://buildfarm.opencsw.org/experimental.html#maciej
> 
> I don't know how to test it.
> 
> Rafael, you could use the Cyrus build recipe to rebuild Cyrus; you can
> now rebuild both Cyrus and SASL, and release them together.

I will take care of that tonight.

cheers
rafi

From maciej at opencsw.org  Tue Jan 17 10:01:44 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Tue, 17 Jan 2012 09:01:44 +0000
Subject: [csw-maintainers] Cross-distro track at FOSDEM 2012
In-Reply-To: <CALtRa-6NmSz-L+dthygTPE6Gpr=zjr7dUjw0ZoQ69JFg_iC1LQ@mail.gmail.com>
References: <CALtRa-6NmSz-L+dthygTPE6Gpr=zjr7dUjw0ZoQ69JFg_iC1LQ@mail.gmail.com>
Message-ID: <CALtRa-7HeM65CyjOR7Q09PX5UAKPZrJ=3mD4sPDDR=mANMaiEQ@mail.gmail.com>

One more thing about FOSDEM: the sposes / partners tour:

http://fosdem.org/2012/fosdem-spousespartners-tour-0

From maciej at opencsw.org  Wed Jan 18 10:44:10 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Wed, 18 Jan 2012 09:44:10 +0000
Subject: [csw-maintainers] The svn:externals references to GAR
Message-ID: <CALtRa-6f_prZrbHaLW54qCNoKXGWmsLK56u4yN8but5RuAPPMQ@mail.gmail.com>

Is anyone still using svn:externals to use GAR? Or, is anyone still
not using mgar? If there isn't anyone, I propose that we remove all
the svn:externals entries from the repository.

Maciej

From wilbury at opencsw.org  Wed Jan 18 10:47:41 2012
From: wilbury at opencsw.org (Juraj Lutter)
Date: Wed, 18 Jan 2012 10:47:41 +0100
Subject: [csw-maintainers] The svn:externals references to GAR
In-Reply-To: <CALtRa-6f_prZrbHaLW54qCNoKXGWmsLK56u4yN8but5RuAPPMQ@mail.gmail.com>
References: <CALtRa-6f_prZrbHaLW54qCNoKXGWmsLK56u4yN8but5RuAPPMQ@mail.gmail.com>
Message-ID: <4F16953D.1040100@opencsw.org>

On 01/18/2012 10:44 AM, Maciej (Matchek) Blizi?ski wrote:
> Is anyone still using svn:externals to use GAR? Or, is anyone still
> not using mgar? If there isn't anyone, I propose that we remove all
> the svn:externals entries from the repository.

Go ahead.



-- 
Juraj Lutter <wilbury at opencsw.org>

From maciej at opencsw.org  Wed Jan 18 10:53:36 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Wed, 18 Jan 2012 09:53:36 +0000
Subject: [csw-maintainers] Wintercamp 2011
Message-ID: <CALtRa-6zZV2X=pvUkok58X-djbaX2ezp7_boCu2hWrduEGODng@mail.gmail.com>

It's 2012! Which means it's time to organize Wintercamp 2011. We had a
plan of meeting in Bratislava. What kind of rough timeline can we aim
at? I'm thinking March or April. This way, Wintercamp 2011 will be not
in 2011 nor in winter! ;-)

Maciej

From wilbury at opencsw.org  Wed Jan 18 10:59:00 2012
From: wilbury at opencsw.org (Juraj Lutter)
Date: Wed, 18 Jan 2012 10:59:00 +0100
Subject: [csw-maintainers] Wintercamp 2011
In-Reply-To: <CALtRa-6zZV2X=pvUkok58X-djbaX2ezp7_boCu2hWrduEGODng@mail.gmail.com>
References: <CALtRa-6zZV2X=pvUkok58X-djbaX2ezp7_boCu2hWrduEGODng@mail.gmail.com>
Message-ID: <4F1697E4.6070403@opencsw.org>

On 01/18/2012 10:53 AM, Maciej (Matchek) Blizi?ski wrote:
> It's 2012! Which means it's time to organize Wintercamp 2011. We had a
> plan of meeting in Bratislava. What kind of rough timeline can we aim
> at? I'm thinking March or April. This way, Wintercamp 2011 will be not
> in 2011 nor in winter! ;-)

We will set up doodle poll. Just a rough estimation, which dates will
suite most of us?



-- 
Juraj Lutter <wilbury at opencsw.org>

From dam at opencsw.org  Wed Jan 18 10:59:46 2012
From: dam at opencsw.org (dam at opencsw.org)
Date: Wed, 18 Jan 2012 10:59:46 +0100 (CET)
Subject: [csw-maintainers] The svn:externals references to GAR
In-Reply-To: <CALtRa-6f_prZrbHaLW54qCNoKXGWmsLK56u4yN8but5RuAPPMQ@mail.gmail.com>
References: <CALtRa-6f_prZrbHaLW54qCNoKXGWmsLK56u4yN8but5RuAPPMQ@mail.gmail.com>
Message-ID: <af97e5539b9b3119d057c7089710845b.squirrel@mail.opencsw.org>

Hi Maciej,

> Is anyone still using svn:externals to use GAR? Or, is anyone still
> not using mgar? If there isn't anyone, I propose that we remove all
> the svn:externals entries from the repository.

Funny, I had the same thought this morning :-) My only concern would
be to provide the info in GARTYPE, but this is already properly set
as far as I can tell.

As I plan to change BUILD64 / BUILD64_LIBS_ONLY anyway in the near
future I already have a cleanly checkout out tree for large modification
and could do the change.


Best regards

  -- Dago

From maciej at opencsw.org  Wed Jan 18 11:03:28 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Wed, 18 Jan 2012 10:03:28 +0000
Subject: [csw-maintainers] The svn:externals references to GAR
In-Reply-To: <af97e5539b9b3119d057c7089710845b.squirrel@mail.opencsw.org>
References: <CALtRa-6f_prZrbHaLW54qCNoKXGWmsLK56u4yN8but5RuAPPMQ@mail.gmail.com>
	<af97e5539b9b3119d057c7089710845b.squirrel@mail.opencsw.org>
Message-ID: <CALtRa-4hdLXPVFyr501a=yAAEp1kfVWib8xYTR04hvVtKNg7=Q@mail.gmail.com>

2012/1/18  <dam at opencsw.org>:
> I already have a cleanly checkout out tree for large modification
> and could do the change.

Excellent. No more annoying accidental gar checkouts!

From pfelecan at opencsw.org  Wed Jan 18 11:14:01 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Wed, 18 Jan 2012 11:14:01 +0100
Subject: [csw-maintainers] Wintercamp 2011
In-Reply-To: <CALtRa-6zZV2X=pvUkok58X-djbaX2ezp7_boCu2hWrduEGODng@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed,
	18 Jan 2012 09:53:36 +0000")
References: <CALtRa-6zZV2X=pvUkok58X-djbaX2ezp7_boCu2hWrduEGODng@mail.gmail.com>
Message-ID: <x6boq1l3me.fsf@opencsw.org>

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

> It's 2012! Which means it's time to organize Wintercamp 2011. We had a
> plan of meeting in Bratislava. What kind of rough timeline can we aim
> at? I'm thinking March or April. This way, Wintercamp 2011 will be not
> in 2011 nor in winter! ;-)

Then call it Spring 2012.

Why Bratislava?
-- 
Peter

From wilbury at opencsw.org  Wed Jan 18 11:25:37 2012
From: wilbury at opencsw.org (Juraj Lutter)
Date: Wed, 18 Jan 2012 11:25:37 +0100
Subject: [csw-maintainers] Wintercamp 2011
In-Reply-To: <x6boq1l3me.fsf@opencsw.org>
References: <CALtRa-6zZV2X=pvUkok58X-djbaX2ezp7_boCu2hWrduEGODng@mail.gmail.com>
	<x6boq1l3me.fsf@opencsw.org>
Message-ID: <4F169E21.2050602@opencsw.org>

On 01/18/2012 11:14 AM, Peter FELECAN wrote:
> Then call it Spring 2012.
> 
> Why Bratislava?

Just because most of you haven't been here, just because Dago, Maciej
and some others have chosen my city at the time i was very new to
OpenCSW, and a bit of other reasons... Moreover, we have very good
transporation connections to Vienna, Prague, Warszaw, ...

j.


-- 
Juraj Lutter <wilbury at opencsw.org>

From bonivart at opencsw.org  Wed Jan 18 13:36:49 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Wed, 18 Jan 2012 13:36:49 +0100
Subject: [csw-maintainers] Fwd: [csw-users] bug in evince?
In-Reply-To: <4F169548.7030903@cmi.univ-mrs.fr>
References: <4F169548.7030903@cmi.univ-mrs.fr>
Message-ID: <CABY0g1Vjo6TPeQRtdEJyhQQu9SjY70aVCs+CNvMiK0Z-Bf_MdA@mail.gmail.com>

In case some maintainers don't read the users list.

/peter

---------- Forwarded message ----------
From: Gerard Henry <ghenry at cmi.univ-mrs.fr>
Date: Wed, Jan 18, 2012 at 10:47 AM
Subject: [csw-users] bug in evince?
To: Questions and discussions <users at lists.opencsw.org>


hello all,
i posted two bug reports about evince, anyone can help?
https://www.opencsw.org/mantis/view.php?id=4885
and
https://www.opencsw.org/mantis/view.php?id=4886

The first one seems to be a packaging problem on sparc only.


thanks in advance,

gerard
_______________________________________________
users mailing list
users at lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/users

From bwalton at opencsw.org  Wed Jan 18 15:28:54 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 18 Jan 2012 09:28:54 -0500
Subject: [csw-maintainers] The svn:externals references to GAR
In-Reply-To: <CALtRa-6f_prZrbHaLW54qCNoKXGWmsLK56u4yN8but5RuAPPMQ@mail.gmail.com>
References: <CALtRa-6f_prZrbHaLW54qCNoKXGWmsLK56u4yN8but5RuAPPMQ@mail.gmail.com>
Message-ID: <1326896912-sup-4624@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej (Matchek) Blizi?ski's message of Wed Jan 18 04:44:10 -0500 2012:

> Is anyone still using svn:externals to use GAR? Or, is anyone still
> not using mgar? If there isn't anyone, I propose that we remove all
> the svn:externals entries from the repository.

Yes, please!

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From dam at opencsw.org  Wed Jan 18 21:32:45 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 18 Jan 2012 21:32:45 +0100
Subject: [csw-maintainers] The svn:externals references to GAR
In-Reply-To: <1326896912-sup-4624@pinkfloyd.chass.utoronto.ca>
References: <CALtRa-6f_prZrbHaLW54qCNoKXGWmsLK56u4yN8but5RuAPPMQ@mail.gmail.com>
	<1326896912-sup-4624@pinkfloyd.chass.utoronto.ca>
Message-ID: <6168EA20-71B9-4530-A9D7-3431F241CB36@opencsw.org>

Hi folks!

Am 18.01.2012 um 15:28 schrieb Ben Walton:
> Excerpts from Maciej (Matchek) Blizi?ski's message of Wed Jan 18 04:44:10 -0500 2012:
>> Is anyone still using svn:externals to use GAR? Or, is anyone still
>> not using mgar? If there isn't anyone, I propose that we remove all
>> the svn:externals entries from the repository.
> 
> Yes, please!

Done, the externals are history since r16795!

Click only if you have patience:
  http://sourceforge.net/apps/trac/gar/changeset/16795

Now only the docs need adjustment. Any volunteers for the wiki here?
  http://gar.opencsw.org


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  Thu Jan 19 16:16:44 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 19 Jan 2012 10:16:44 -0500
Subject: [csw-maintainers] Fwd: Output from "cron" command
Message-ID: <1326986168-sup-3087@pinkfloyd.chass.utoronto.ca>

Hi Guys,

Override or fix the new package?  Ultimately, these packages would be
converted to use alternatives at which point the problem goes away.

Thanks
-Ben

--- Begin forwarded message from Ben Walton ---
From: Ben Walton <bwalton at www.opencsw.org>
To: bwalton <bwalton at www.opencsw.org>
Date: Thu, 19 Jan 2012 10:09:12 -0500
Subject: Output from "cron" command

Your "cron" job on ocswchbiesv01
/home/bwalton/bin/run_web_updates

produced the following output:

ERROR: /opt/csw/share/man/man8/imapd.8: Conflict between CSWcyrusimapd/cyrus_imapd and CSWcourierimap
--- End forwarded message ---
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From maciej at opencsw.org  Thu Jan 19 16:26:04 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Thu, 19 Jan 2012 15:26:04 +0000
Subject: [csw-maintainers] Fwd: Output from "cron" command
In-Reply-To: <1326986168-sup-3087@pinkfloyd.chass.utoronto.ca>
References: <1326986168-sup-3087@pinkfloyd.chass.utoronto.ca>
Message-ID: <CALtRa-5du4YKP2KVHaKrDZ_BC9pCvbrN_f79r_3tTDCUN8K6SQ@mail.gmail.com>

2012/1/19 Ben Walton <bwalton at opencsw.org>:
> Override or fix the new package? ?Ultimately, these packages would be
> converted to use alternatives at which point the problem goes away.

CSWcyrusimapd could rename the man page to something else, until
CSWcourierimap gets a working build recipe.

Maciej

From raos at opencsw.org  Thu Jan 19 19:41:28 2012
From: raos at opencsw.org (Rafael Ostertag)
Date: Thu, 19 Jan 2012 19:41:28 +0100
Subject: [csw-maintainers] Fwd: Output from "cron" command
In-Reply-To: <CALtRa-5du4YKP2KVHaKrDZ_BC9pCvbrN_f79r_3tTDCUN8K6SQ@mail.gmail.com>
References: <1326986168-sup-3087@pinkfloyd.chass.utoronto.ca>
	<CALtRa-5du4YKP2KVHaKrDZ_BC9pCvbrN_f79r_3tTDCUN8K6SQ@mail.gmail.com>
Message-ID: <20120119184128.GL19279@bender.opencsw.org>

Hi Guys
On Thu, Jan 19, 2012 at 03:26:04PM +0000, Maciej (Matchek) Blizi??ski wrote:
> 2012/1/19 Ben Walton <bwalton at opencsw.org>:
> > Override or fix the new package? ??Ultimately, these packages would be
> > converted to use alternatives at which point the problem goes away.
> 
> CSWcyrusimapd could rename the man page to something else, until
> CSWcourierimap gets a working build recipe.

If that's okay with everybody, I will move all the manpages in 8 to 1M for
cyrus.

Cheers
rafi

From bwalton at opencsw.org  Thu Jan 19 19:48:28 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 19 Jan 2012 13:48:28 -0500
Subject: [csw-maintainers] Fwd: Output from "cron" command
In-Reply-To: <20120119184128.GL19279@bender.opencsw.org>
References: <1326986168-sup-3087@pinkfloyd.chass.utoronto.ca>
	<CALtRa-5du4YKP2KVHaKrDZ_BC9pCvbrN_f79r_3tTDCUN8K6SQ@mail.gmail.com>
	<20120119184128.GL19279@bender.opencsw.org>
Message-ID: <1326998873-sup-2542@pinkfloyd.chass.utoronto.ca>

Excerpts from Rafael Ostertag's message of Thu Jan 19 13:41:28 -0500 2012:

> If that's okay with everybody, I will move all the manpages in 8 to
> 1M for cyrus.

That works. :)  I won't do anything to override the conflict then.
I'll just wait for the new package to land which will register
cleanly.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From raos at opencsw.org  Thu Jan 19 22:54:30 2012
From: raos at opencsw.org (Rafael Ostertag)
Date: Thu, 19 Jan 2012 22:54:30 +0100
Subject: [csw-maintainers] Fwd: Output from "cron" command
In-Reply-To: <1326998873-sup-2542@pinkfloyd.chass.utoronto.ca>
References: <1326986168-sup-3087@pinkfloyd.chass.utoronto.ca>
	<CALtRa-5du4YKP2KVHaKrDZ_BC9pCvbrN_f79r_3tTDCUN8K6SQ@mail.gmail.com>
	<20120119184128.GL19279@bender.opencsw.org>
	<1326998873-sup-2542@pinkfloyd.chass.utoronto.ca>
Message-ID: <20120119215430.GM19279@bender.opencsw.org>

On Thu, Jan 19, 2012 at 01:48:28PM -0500, Ben Walton wrote:
> Excerpts from Rafael Ostertag's message of Thu Jan 19 13:41:28 -0500 2012:
> 
> > If that's okay with everybody, I will move all the manpages in 8 to
> > 1M for cyrus.
> 
> That works. :)  I won't do anything to override the conflict then.
> I'll just wait for the new package to land which will register
> cleanly.
> 
Packages have been uploaded.

cheers
rafi

From maciej at opencsw.org  Fri Jan 20 11:37:33 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 20 Jan 2012 10:37:33 +0000
Subject: [csw-maintainers] OpenCSW manual
Message-ID: <CALtRa-6yJNddGhvZUFwF93efBzjAq0n_iVyCK20H80caYHmOhw@mail.gmail.com>

Hello maintainers,

Dago and I talked recently about the next generation of OpenCSW
documentation. Dago's take on the topic was that there are 3 key
audiences that our documentation needs to address:

1. System administrators
2. Developers
3. Package maintainers

The policy documents we've talked in the past would be part of the
manual for package maintainers.

I experimented with Sphinx, a tool which allows to compile
documentation written in reStructuredText into HTML, epub and other
formats. I've prepared a stub and put it into pkg/opencsw-manual.

https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/opencsw-manual/trunk/

There is also a version (a stub) compiled to HTML:

http://buildfarm.opencsw.org/~maciej/opencsw-manual/

Apart from my proof-of-concept port of the shared libraries document,
it's only a skeleton.

We could divide the work, for example one person could write the
section for administrators, another person for developers; other
people could review it as a whole.

Would anyone be interested in working on the document?

Maciej

From bonivart at opencsw.org  Fri Jan 20 13:09:15 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Fri, 20 Jan 2012 13:09:15 +0100
Subject: [csw-maintainers] OpenCSW manual
In-Reply-To: <CALtRa-6yJNddGhvZUFwF93efBzjAq0n_iVyCK20H80caYHmOhw@mail.gmail.com>
References: <CALtRa-6yJNddGhvZUFwF93efBzjAq0n_iVyCK20H80caYHmOhw@mail.gmail.com>
Message-ID: <CABY0g1VHnGcG3SN9CxdSLJWAUvHTM1TRKAEYDhywNXv8Xfa3xw@mail.gmail.com>

2012/1/20 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
> Hello maintainers,
>
> Dago and I talked recently about the next generation of OpenCSW
> documentation. Dago's take on the topic was that there are 3 key
> audiences that our documentation needs to address:
>
> 1. System administrators
> 2. Developers
> 3. Package maintainers

I think it's great to target the different audiences like that. Will
make it much more clear when reading.

> I experimented with Sphinx, a tool which allows to compile
> documentation written in reStructuredText into HTML, epub and other
> formats. I've prepared a stub and put it into pkg/opencsw-manual.
>
> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/opencsw-manual/trunk/

This looks horrible.

> There is also a version (a stub) compiled to HTML:
>
> http://buildfarm.opencsw.org/~maciej/opencsw-manual/

This looks great.

Why not document on a(ny) wiki which is made for ease of
documentation? Where I work every document system failed until we
implemented wikis, now people from all areas document new stuff and
keep it updated just because it's so easy to do so.

/peter

From pfelecan at opencsw.org  Fri Jan 20 14:23:39 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Fri, 20 Jan 2012 14:23:39 +0100
Subject: [csw-maintainers] OpenCSW manual
In-Reply-To: <CABY0g1VHnGcG3SN9CxdSLJWAUvHTM1TRKAEYDhywNXv8Xfa3xw@mail.gmail.com>
	(Peter Bonivart's message of "Fri, 20 Jan 2012 13:09:15 +0100")
References: <CALtRa-6yJNddGhvZUFwF93efBzjAq0n_iVyCK20H80caYHmOhw@mail.gmail.com>
	<CABY0g1VHnGcG3SN9CxdSLJWAUvHTM1TRKAEYDhywNXv8Xfa3xw@mail.gmail.com>
Message-ID: <x6lip2jyn8.fsf@opencsw.org>

Peter Bonivart <bonivart at opencsw.org> writes:

> 2012/1/20 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
>> Hello maintainers,
>>
>> Dago and I talked recently about the next generation of OpenCSW
>> documentation. Dago's take on the topic was that there are 3 key
>> audiences that our documentation needs to address:
>>
>> 1. System administrators
>> 2. Developers
>> 3. Package maintainers
>
> I think it's great to target the different audiences like that. Will
> make it much more clear when reading.
>
>> I experimented with Sphinx, a tool which allows to compile
>> documentation written in reStructuredText into HTML, epub and other
>> formats. I've prepared a stub and put it into pkg/opencsw-manual.
>>
>> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/opencsw-manual/trunk/
>
> This looks horrible.

This is the "production form". However Maciej changes quite often the
underlining tool. We had some discussion about this in the past.

>> There is also a version (a stub) compiled to HTML:
>>
>> http://buildfarm.opencsw.org/~maciej/opencsw-manual/
>
> This looks great.

This is the "consumable form".

> Why not document on a(ny) wiki which is made for ease of
> documentation? Where I work every document system failed until we
> implemented wikis, now people from all areas document new stuff and
> keep it updated just because it's so easy to do so.

Is a wiki "source" in the traditional sense? Can it be managed with a
SCM, extracted locally, edited with any text editors? Wikis are great
for some tasks. Maybe not for the one proposed in this thread.
-- 
Peter

From dam at opencsw.org  Fri Jan 20 20:43:10 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 20 Jan 2012 20:43:10 +0100
Subject: [csw-maintainers] RFC: Drop arch-specific packages of pkgutil and
	static from primary mirror
Message-ID: <BEBFA203-498E-463F-9547-730A4990A163@opencsw.org>

Hi,

I would like to clean up the primary mirror:

> -rw-r--r--   1 16801    103       305152 Aug 20  2010 pkgutil-i386.pkg
> -rw-r--r--   1 16801    103       365056 Aug 20  2010 pkgutil-sparc.pkg
> -rw-r--r--   1 16801    103       547328 Jul  1  2011 pkgutil.pkg
> 
> -rwxr-xr-x   2 16801    103       164576 Aug 20  2010 wget-i386
> -rwxr-xr-x   2 16801    103       164576 Aug 20  2010 wget-i386.bin
> -rwxr-xr-x   2 16801    103       224672 Aug 20  2010 wget-sparc
> -rwxr-xr-x   2 16801    103       224672 Aug 20  2010 wget-sparc.bin
> 
> primary# for f in pkgutil*; do pkginfo -d $f -x; done
> CSWpkgutil  pkgutil - Installs Solaris packages easily
>             (i386) 1.7,REV=2009.09.11
> CSWpkgutil  pkgutil - Installs Solaris packages easily
>             (sparc) 1.7,REV=2009.09.11
> CSWpkgutil  pkgutil - Installs Solaris packages easily
>             (all) 2.4,REV=2011.06.29

My suggestions:

1. Drop outdated, arch-specific pkgutil-i386.pkg and pkgutil-sparc.pkg
   Alternatively we could link that to pkgutil.pkg, but I would remove them
   to make a cleaner toplevel.

2. Remove static wget binaries completely as a static wget is now also shipped
   with pkgutil.pkg

3. The pkgutil build recipe currently just copies in the static binaries from
   the sourceforge zip. I suggest building a static wget during the pkgutil
   build phase. The wget recipe already contains a modulation for a static build.

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


From bwalton at opencsw.org  Fri Jan 20 21:11:43 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 20 Jan 2012 15:11:43 -0500
Subject: [csw-maintainers] RFC: Drop arch-specific packages of pkgutil
	and static from primary mirror
In-Reply-To: <BEBFA203-498E-463F-9547-730A4990A163@opencsw.org>
References: <BEBFA203-498E-463F-9547-730A4990A163@opencsw.org>
Message-ID: <1327090188-sup-621@pinkfloyd.chass.utoronto.ca>

Excerpts from Dagobert Michelsen's message of Fri Jan 20 14:43:10 -0500 2012:

Hi Dago,

> 1. Drop outdated, arch-specific pkgutil-i386.pkg and pkgutil-sparc.pkg
>    Alternatively we could link that to pkgutil.pkg, but I would remove them
>    to make a cleaner toplevel.

Ideally removal is best, but there are likely people with scripts
pulling down the arch specific packages.  I'd leave symlinks in place
to preserve that functionality.

> 2. Remove static wget binaries completely as a static wget is now
>    also shipped with pkgutil.pkg

Again, this might break scripts but I agree in principle.

> 3. The pkgutil build recipe currently just copies in the static
>    binaries from the sourceforge zip. I suggest building a static
>    wget during the pkgutil build phase. The wget recipe already
>    contains a modulation for a static build.

What's the advantage of this approach?

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From bonivart at opencsw.org  Fri Jan 20 21:12:25 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Fri, 20 Jan 2012 21:12:25 +0100
Subject: [csw-maintainers] RFC: Drop arch-specific packages of pkgutil
 and static from primary mirror
In-Reply-To: <BEBFA203-498E-463F-9547-730A4990A163@opencsw.org>
References: <BEBFA203-498E-463F-9547-730A4990A163@opencsw.org>
Message-ID: <CABY0g1XRUA6yj4DNs-6Xxh=pe1m-6Po3M70GMCPtC1q3KYOnsQ@mail.gmail.com>

On Fri, Jan 20, 2012 at 8:43 PM, Dagobert Michelsen <dam at opencsw.org> wrote:
> 1. Drop outdated, arch-specific pkgutil-i386.pkg and pkgutil-sparc.pkg
> ? Alternatively we could link that to pkgutil.pkg, but I would remove them
> ? to make a cleaner toplevel.

Yes.

> 2. Remove static wget binaries completely as a static wget is now also shipped
> ? with pkgutil.pkg

Yes.

> 3. The pkgutil build recipe currently just copies in the static binaries from
> ? the sourceforge zip. I suggest building a static wget during the pkgutil
> ? build phase. The wget recipe already contains a modulation for a static build.

Why? We know the current ones work and it's just a last resort anyway.
If you have wget in /opt/csw/bin, /usr/local/bin, /usr/sfw/bin or
/usr/bin it will be used before the included one.

Does the wget recipe build a static version? The above mentioned wget
binaries are not really static but they do not link to anything
outside Solaris.

/peter

From maciej at opencsw.org  Fri Jan 20 21:14:14 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 20 Jan 2012 20:14:14 +0000
Subject: [csw-maintainers] OpenCSW manual
In-Reply-To: <CABY0g1VHnGcG3SN9CxdSLJWAUvHTM1TRKAEYDhywNXv8Xfa3xw@mail.gmail.com>
References: <CALtRa-6yJNddGhvZUFwF93efBzjAq0n_iVyCK20H80caYHmOhw@mail.gmail.com>
	<CABY0g1VHnGcG3SN9CxdSLJWAUvHTM1TRKAEYDhywNXv8Xfa3xw@mail.gmail.com>
Message-ID: <CALtRa-4OZ0y9a-+RX0-hbda=HAtQWmhzVzfhGk9AQTPy7U58Ww@mail.gmail.com>

2012/1/20 Peter Bonivart <bonivart at opencsw.org>:
> 2012/1/20 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
>> Hello maintainers,
>>
>> Dago and I talked recently about the next generation of OpenCSW
>> documentation. Dago's take on the topic was that there are 3 key
>> audiences that our documentation needs to address:
>>
>> 1. System administrators
>> 2. Developers
>> 3. Package maintainers
>
> I think it's great to target the different audiences like that. Will
> make it much more clear when reading.
>
>> I experimented with Sphinx, a tool which allows to compile
>> documentation written in reStructuredText into HTML, epub and other
>> formats. I've prepared a stub and put it into pkg/opencsw-manual.
>>
>> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/opencsw-manual/trunk/
>
> This looks horrible.

Really that bad? The most realistic example is this one:

https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/opencsw-manual/trunk/files/for-maintainers/shared-libraries.rst

I challenge you to write this document in any other markup that will
look better than this! :-)

>> There is also a version (a stub) compiled to HTML:
>>
>> http://buildfarm.opencsw.org/~maciej/opencsw-manual/
>
> This looks great.
>
> Why not document on a(ny) wiki which is made for ease of
> documentation? Where I work every document system failed until we
> implemented wikis, now people from all areas document new stuff and
> keep it updated just because it's so easy to do so.

I agree that source code repository is harder to modify than a wiki.

I agree that wikis are better for general documentation, such as GAR
variable reference. The stuff that can change quickly and needs to be
very easy to update.

While wikis are good for vast knowledge bases, they don't allow for
reading top-to-bottom. The idea behind the manual is that it's an
introductory material for newcomers, which you read once,
top-to-bottom, and it gives a basic understanding of what you're
dealing with. The manual must not be large, each of the 3 sections has
to be possible to absorb in one evening.  If we have a newcomer, we
point them at the manual, and this should be enough to get anyone
started with the project (from each of the three perspectives).

Thoughts?

Maciej

From bwalton at opencsw.org  Fri Jan 20 21:19:40 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 20 Jan 2012 15:19:40 -0500
Subject: [csw-maintainers] OpenCSW manual
In-Reply-To: <CALtRa-4OZ0y9a-+RX0-hbda=HAtQWmhzVzfhGk9AQTPy7U58Ww@mail.gmail.com>
References: <CALtRa-6yJNddGhvZUFwF93efBzjAq0n_iVyCK20H80caYHmOhw@mail.gmail.com>
	<CABY0g1VHnGcG3SN9CxdSLJWAUvHTM1TRKAEYDhywNXv8Xfa3xw@mail.gmail.com>
	<CALtRa-4OZ0y9a-+RX0-hbda=HAtQWmhzVzfhGk9AQTPy7U58Ww@mail.gmail.com>
Message-ID: <1327090700-sup-6722@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej (Matchek) Blizi?ski's message of Fri Jan 20 15:14:14 -0500 2012:

> I agree that source code repository is harder to modify than a wiki.
> 
> I agree that wikis are better for general documentation, such as GAR
> variable reference. The stuff that can change quickly and needs to be
> very easy to update.

Ikiwiki is a wiki that is based on a git repository (other scm's
supported too, I think).  You can edit via the web (easy, low barrier)
or push new material to that git repo after using whatever tools you
want (harder, more flexible).

Might that be a useful too here?  I'm not familiar with the ikiwiki
markup though...it could be a deal breaker.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From maciej at opencsw.org  Fri Jan 20 21:20:09 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 20 Jan 2012 20:20:09 +0000
Subject: [csw-maintainers] Maciej out Sat-Wed
Message-ID: <CALtRa-5JhD1krgb4nDqkTY03+y3Xt5YpVbc5Vm2bSid4=KoRcw@mail.gmail.com>

Hello maintainers,

I'm going for a trip this Sat-Wed, with rather patchy access to the
network. I might be able to respond to emails, but no guarantees.

Maciej

From dam at opencsw.org  Fri Jan 20 21:20:54 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 20 Jan 2012 21:20:54 +0100
Subject: [csw-maintainers] RFC: Drop arch-specific packages of pkgutil
	and static from primary mirror
In-Reply-To: <CABY0g1XRUA6yj4DNs-6Xxh=pe1m-6Po3M70GMCPtC1q3KYOnsQ@mail.gmail.com>
References: <BEBFA203-498E-463F-9547-730A4990A163@opencsw.org>
	<CABY0g1XRUA6yj4DNs-6Xxh=pe1m-6Po3M70GMCPtC1q3KYOnsQ@mail.gmail.com>
Message-ID: <5412CBAB-2F06-4A22-8B52-8D58E38C1023@opencsw.org>

Hi Peter,

Am 20.01.2012 um 21:12 schrieb Peter Bonivart:
> On Fri, Jan 20, 2012 at 8:43 PM, Dagobert Michelsen <dam at opencsw.org> wrote:
>> 1. Drop outdated, arch-specific pkgutil-i386.pkg and pkgutil-sparc.pkg
>>   Alternatively we could link that to pkgutil.pkg, but I would remove them
>>   to make a cleaner toplevel.
> 
> Yes.
> 
>> 2. Remove static wget binaries completely as a static wget is now also shipped
>>   with pkgutil.pkg
> 
> Yes.
> 
>> 3. The pkgutil build recipe currently just copies in the static binaries from
>>   the sourceforge zip. I suggest building a static wget during the pkgutil
>>   build phase. The wget recipe already contains a modulation for a static build.
> 
> Why? We know the current ones work and it's just a last resort anyway.
> If you have wget in /opt/csw/bin, /usr/local/bin, /usr/sfw/bin or
> /usr/bin it will be used before the included one.

It is just an idea to make the build recipe easier to update.
If there is now a version bump of wget it needs to be shuffled
around manually. Anyway, that was a solution for a problem we don't
have :-)

> Does the wget recipe build a static version? The above mentioned wget
> binaries are not really static but they do not link to anything
> outside Solaris.

Right, thats what I meant.


Best regards

  -- Dago

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


From dam at opencsw.org  Fri Jan 20 21:22:19 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 20 Jan 2012 21:22:19 +0100
Subject: [csw-maintainers] RFC: Drop arch-specific packages of pkgutil
	and static from primary mirror
In-Reply-To: <1327090188-sup-621@pinkfloyd.chass.utoronto.ca>
References: <BEBFA203-498E-463F-9547-730A4990A163@opencsw.org>
	<1327090188-sup-621@pinkfloyd.chass.utoronto.ca>
Message-ID: <E026F021-F8B9-4455-9D1F-B628E827E096@opencsw.org>

Hi Ben,

Am 20.01.2012 um 21:11 schrieb Ben Walton:
> Excerpts from Dagobert Michelsen's message of Fri Jan 20 14:43:10 -0500 2012:
>> 1. Drop outdated, arch-specific pkgutil-i386.pkg and pkgutil-sparc.pkg
>>   Alternatively we could link that to pkgutil.pkg, but I would remove them
>>   to make a cleaner toplevel.
> 
> Ideally removal is best, but there are likely people with scripts
> pulling down the arch specific packages.  I'd leave symlinks in place
> to preserve that functionality.

Ok. But keep in mind we already removed pkg-get from there without
symlinking.

>> 2. Remove static wget binaries completely as a static wget is now
>>   also shipped with pkgutil.pkg
> 
> Again, this might break scripts but I agree in principle.

Why? Do you think they wget the wget?

>> 3. The pkgutil build recipe currently just copies in the static
>>   binaries from the sourceforge zip. I suggest building a static
>>   wget during the pkgutil build phase. The wget recipe already
>>   contains a modulation for a static build.
> 
> What's the advantage of this approach?

Please see my other mail to Peter.


Best regards

  -- Dago

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


From maciej at opencsw.org  Fri Jan 20 21:23:04 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 20 Jan 2012 20:23:04 +0000
Subject: [csw-maintainers] OpenCSW manual
In-Reply-To: <1327090700-sup-6722@pinkfloyd.chass.utoronto.ca>
References: <CALtRa-6yJNddGhvZUFwF93efBzjAq0n_iVyCK20H80caYHmOhw@mail.gmail.com>
	<CABY0g1VHnGcG3SN9CxdSLJWAUvHTM1TRKAEYDhywNXv8Xfa3xw@mail.gmail.com>
	<CALtRa-4OZ0y9a-+RX0-hbda=HAtQWmhzVzfhGk9AQTPy7U58Ww@mail.gmail.com>
	<1327090700-sup-6722@pinkfloyd.chass.utoronto.ca>
Message-ID: <CALtRa-6fSQu2Y=mfMxqMBNnu2d7qbpOHbKqLVED_ZKHQs3BPTw@mail.gmail.com>

2012/1/20 Ben Walton <bwalton at opencsw.org>:
> Ikiwiki is a wiki that is based on a git repository (other scm's
> supported too, I think). ?You can edit via the web (easy, low barrier)
> or push new material to that git repo after using whatever tools you
> want (harder, more flexible).
>
> Might that be a useful too here? ?I'm not familiar with the ikiwiki
> markup though...it could be a deal breaker.

If we want to do it in a wiki, we should pick one of the two existing
ones, that should be fine. The idea is to write something that you
read as a book, which has a first page and, most importantly, the last
page (which wikis don't have :-) (but potentially can emulate)).

Another topic is offline usage. I would imagine something like
downloading an epub/mobi to an ebook reader, and reading the OpenCSW
book on the plane.

From bwalton at opencsw.org  Fri Jan 20 21:23:59 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 20 Jan 2012 15:23:59 -0500
Subject: [csw-maintainers] RFC: Drop arch-specific packages of pkgutil
	and static from primary mirror
In-Reply-To: <E026F021-F8B9-4455-9D1F-B628E827E096@opencsw.org>
References: <BEBFA203-498E-463F-9547-730A4990A163@opencsw.org>
	<1327090188-sup-621@pinkfloyd.chass.utoronto.ca>
	<E026F021-F8B9-4455-9D1F-B628E827E096@opencsw.org>
Message-ID: <1327090979-sup-4827@pinkfloyd.chass.utoronto.ca>

Excerpts from Dagobert Michelsen's message of Fri Jan 20 15:22:19 -0500 2012:

> Ok. But keep in mind we already removed pkg-get from there without
> symlinking.

A fair point.

> >> 2. Remove static wget binaries completely as a static wget is now
> >>   also shipped with pkgutil.pkg
> > 
> > Again, this might break scripts but I agree in principle.
> 
> Why? Do you think they wget the wget?

Doh!  You're right. :)

> >> 3. The pkgutil build recipe currently just copies in the static
> >>   binaries from the sourceforge zip. I suggest building a static
> >>   wget during the pkgutil build phase. The wget recipe already
> >>   contains a modulation for a static build.
> > 
> > What's the advantage of this approach?
> 
> Please see my other mail to Peter.

Ok.  I'm good with the proposal and if Peter wants to change that wget
handling done by pkgutil, he knows best. :)

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From dam at opencsw.org  Fri Jan 20 21:24:50 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 20 Jan 2012 21:24:50 +0100
Subject: [csw-maintainers] OpenCSW manual
In-Reply-To: <CALtRa-4OZ0y9a-+RX0-hbda=HAtQWmhzVzfhGk9AQTPy7U58Ww@mail.gmail.com>
References: <CALtRa-6yJNddGhvZUFwF93efBzjAq0n_iVyCK20H80caYHmOhw@mail.gmail.com>
	<CABY0g1VHnGcG3SN9CxdSLJWAUvHTM1TRKAEYDhywNXv8Xfa3xw@mail.gmail.com>
	<CALtRa-4OZ0y9a-+RX0-hbda=HAtQWmhzVzfhGk9AQTPy7U58Ww@mail.gmail.com>
Message-ID: <F1DF531C-BD99-44FD-896A-D0D437B8AB2A@opencsw.org>

Hi,

Am 20.01.2012 um 21:14 schrieb Maciej (Matchek) Blizi?ski:
>>> There is also a version (a stub) compiled to HTML:
>>> 
>>> http://buildfarm.opencsw.org/~maciej/opencsw-manual/
>> 
>> This looks great.
>> 
>> Why not document on a(ny) wiki which is made for ease of
>> documentation? Where I work every document system failed until we
>> implemented wikis, now people from all areas document new stuff and
>> keep it updated just because it's so easy to do so.

...

> While wikis are good for vast knowledge bases, they don't allow for
> reading top-to-bottom. The idea behind the manual is that it's an
> introductory material for newcomers, which you read once,
> top-to-bottom, and it gives a basic understanding of what you're
> dealing with. The manual must not be large, each of the 3 sections has
> to be possible to absorb in one evening.  If we have a newcomer, we
> point them at the manual, and this should be enough to get anyone
> started with the project (from each of the three perspectives).

First lets please not discuss too long about the format. It needs
to be written. Convert it takes a fraction of the amount of writing it
if necessary.

Having a nice browsable thing and PDF is IMHO perfect for starters.


Best regards

  -- Dago

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


From yann at pleiades.fr.eu.org  Sat Jan 21 12:00:42 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Sat, 21 Jan 2012 12:00:42 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
Message-ID: <4F1A9ADA.3020900@pleiades.fr.eu.org>

Le 16/01/2012 10:33, Maciej (Matchek) Blizi?ski a ?crit :
> Looks like we need to rebuild Cyrus imapd together with sasl. I looked
> at the current situation and found this:
>
> - the unstable catalog contains version 2.3.16
>    http://mirror.opencsw.org/opencsw/unstable/i386/5.10/catalog
> - the website declares it's at 2.4.6
>    http://www.opencsw.org/packages/cyrus_imapd/
> - the build recipe is at 2.4.10
>    https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/cyrus_imapd/trunk/Makefile
> - the newest upstream version is 2.4.13
>    ftp://ftp.cyrusimap.org/cyrus-imapd/
>
> I don't know how we got into this state, but in a perfect world at
> least the first three should match.
>
> Yann, can you tell what's the current situation with this package?
> What are the main challenges in getting a new version release

Hi Maciej,

The blocker is the migration path, upgrade from 2.3 to 2.4 triggers a 
bug when berkeley is used.

I opened a bug upstream but the developper didn't have the time to work 
on it
https://bugzilla.cyrusimap.org/show_bug.cgi?id=3496

Any help is welcome.

Yann


From yann at pleiades.fr.eu.org  Sat Jan 21 12:17:16 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Sat, 21 Jan 2012 12:17:16 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <4F1A9ADA.3020900@pleiades.fr.eu.org>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
	<4F1A9ADA.3020900@pleiades.fr.eu.org>
Message-ID: <4F1A9EBC.50103@pleiades.fr.eu.org>

Oh, I just saw Rafael released Cyrus Imapd 2.4.

Did someone check that the upgrade from 2.3 went fine ?

You also upgraded berkeleydb, didn't you ?

It will probably break the setup of people who explicitely configured 
berkeleydb for cyrus database and the upgrade path should be documented.


Yann






Le 21/01/2012 12:00, Yann Rouillard a ?crit :
> Le 16/01/2012 10:33, Maciej (Matchek) Blizi?ski a ?crit :
>> Looks like we need to rebuild Cyrus imapd together with sasl. I looked
>> at the current situation and found this:
>>
>> - the unstable catalog contains version 2.3.16
>>    http://mirror.opencsw.org/opencsw/unstable/i386/5.10/catalog
>> - the website declares it's at 2.4.6
>>    http://www.opencsw.org/packages/cyrus_imapd/
>> - the build recipe is at 2.4.10
>>
>> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/cyrus_imapd/trunk/Makefile
>> - the newest upstream version is 2.4.13
>>    ftp://ftp.cyrusimap.org/cyrus-imapd/
>>
>> I don't know how we got into this state, but in a perfect world at
>> least the first three should match.
>>
>> Yann, can you tell what's the current situation with this package?
>> What are the main challenges in getting a new version release
>
> Hi Maciej,
>
> The blocker is the migration path, upgrade from 2.3 to 2.4 triggers a
> bug when berkeley is used.
>
> I opened a bug upstream but the developper didn't have the time to
> work on it
> https://bugzilla.cyrusimap.org/show_bug.cgi?id=3496
>
> Any help is welcome.
>
> Yann
>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.


From raos at opencsw.org  Sat Jan 21 12:47:09 2012
From: raos at opencsw.org (Rafael Ostertag)
Date: Sat, 21 Jan 2012 12:47:09 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <4F1A9ADA.3020900@pleiades.fr.eu.org>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
	<4F1A9ADA.3020900@pleiades.fr.eu.org>
Message-ID: <20120121114709.GP19279@bender.opencsw.org>

Hi Yann

On Sat, Jan 21, 2012 at 12:00:42PM +0100, Yann Rouillard wrote:
> Le 16/01/2012 10:33, Maciej (Matchek) Blizi??ski a ??crit :
> >Looks like we need to rebuild Cyrus imapd together with sasl. I looked
> >at the current situation and found this:
> >
> >- the unstable catalog contains version 2.3.16
> >   http://mirror.opencsw.org/opencsw/unstable/i386/5.10/catalog
> >- the website declares it's at 2.4.6
> >   http://www.opencsw.org/packages/cyrus_imapd/
> >- the build recipe is at 2.4.10
> >   https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/cyrus_imapd/trunk/Makefile
> >- the newest upstream version is 2.4.13
> >   ftp://ftp.cyrusimap.org/cyrus-imapd/
> >
> >I don't know how we got into this state, but in a perfect world at
> >least the first three should match.
> >
> >Yann, can you tell what's the current situation with this package?
> >What are the main challenges in getting a new version release
> 
> Hi Maciej,
> 
> The blocker is the migration path, upgrade from 2.3 to 2.4 triggers
> a bug when berkeley is used.
> 
> I opened a bug upstream but the developper didn't have the time to
> work on it
> https://bugzilla.cyrusimap.org/show_bug.cgi?id=3496
> 
> Any help is welcome.

What about, if we use a preinstall, and convert the deliver db to skiplist
before installing 2.4?

cheers
rafi

From raos at opencsw.org  Sat Jan 21 12:55:39 2012
From: raos at opencsw.org (Rafael Ostertag)
Date: Sat, 21 Jan 2012 12:55:39 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <4F1A9EBC.50103@pleiades.fr.eu.org>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
	<4F1A9ADA.3020900@pleiades.fr.eu.org>
	<4F1A9EBC.50103@pleiades.fr.eu.org>
Message-ID: <20120121115539.GQ19279@bender.opencsw.org>

Hi Yann
On Sat, Jan 21, 2012 at 12:17:16PM +0100, Yann Rouillard wrote:
> Oh, I just saw Rafael released Cyrus Imapd 2.4.
> 
> Did someone check that the upgrade from 2.3 went fine ?

I just checked it again:

 1. took 2.3 and created a trivial install with 3 users
 2. sent 2 mails to each user
 3. simply upgraded to 2.4 (pkgutil -u)

I did not see any errors so far. Let me know if I did something wrong in the
process.

> 
> You also upgraded berkeleydb, didn't you ?

Yep, because sendmail is using 4.8, and sendmail is using sasl, thus I
thought having the same bdb is a good idea.

> 
> It will probably break the setup of people who explicitely
> configured berkeleydb for cyrus database and the upgrade path should
> be documented.
Hmm, let me check this.

cheers
rafi

> 
> 
> Yann
> 
> 
> 
> 
> 
> 
> Le 21/01/2012 12:00, Yann Rouillard a ??crit :
> >Le 16/01/2012 10:33, Maciej (Matchek) Blizi??ski a ??crit :
> >>Looks like we need to rebuild Cyrus imapd together with sasl. I looked
> >>at the current situation and found this:
> >>
> >>- the unstable catalog contains version 2.3.16
> >>   http://mirror.opencsw.org/opencsw/unstable/i386/5.10/catalog
> >>- the website declares it's at 2.4.6
> >>   http://www.opencsw.org/packages/cyrus_imapd/
> >>- the build recipe is at 2.4.10
> >>
> >>https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/cyrus_imapd/trunk/Makefile
> >>- the newest upstream version is 2.4.13
> >>   ftp://ftp.cyrusimap.org/cyrus-imapd/
> >>
> >>I don't know how we got into this state, but in a perfect world at
> >>least the first three should match.
> >>
> >>Yann, can you tell what's the current situation with this package?
> >>What are the main challenges in getting a new version release
> >
> >Hi Maciej,
> >
> >The blocker is the migration path, upgrade from 2.3 to 2.4 triggers a
> >bug when berkeley is used.
> >
> >I opened a bug upstream but the developper didn't have the time to
> >work on it
> >https://bugzilla.cyrusimap.org/show_bug.cgi?id=3496
> >
> >Any help is welcome.
> >
> >Yann
> >
> >_______________________________________________
> >maintainers mailing list
> >maintainers at lists.opencsw.org
> >https://lists.opencsw.org/mailman/listinfo/maintainers
> >.:: This mailing list's archive is public. ::.
> 
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.

From raos at opencsw.org  Sat Jan 21 13:40:53 2012
From: raos at opencsw.org (Rafael Ostertag)
Date: Sat, 21 Jan 2012 13:40:53 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <20120121115539.GQ19279@bender.opencsw.org>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
	<4F1A9ADA.3020900@pleiades.fr.eu.org>
	<4F1A9EBC.50103@pleiades.fr.eu.org>
	<20120121115539.GQ19279@bender.opencsw.org>
Message-ID: <20120121124053.GR19279@bender.opencsw.org>

Hi Yann

On Sat, Jan 21, 2012 at 12:55:39PM +0100, Rafael Ostertag wrote:
> > 
> > It will probably break the setup of people who explicitely
> > configured berkeleydb for cyrus database and the upgrade path should
> > be documented.
> Hmm, let me check this.

I used the this imapd.conf: http://paste.pocoo.org/show/538215/

Same procedure:

 1. installed 2.3.16
 2. created 2 users
 3. sent some mails
 4. upgraded to 2.4

No errors so far. Would you say that is sufficient, or do we have to make a
more sophisticated test setup? 

cheers
rafi


From yann at pleiades.fr.eu.org  Sat Jan 21 14:25:06 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Sat, 21 Jan 2012 14:25:06 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <20120121114709.GP19279@bender.opencsw.org>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>	<4F1A9ADA.3020900@pleiades.fr.eu.org>
	<20120121114709.GP19279@bender.opencsw.org>
Message-ID: <4F1ABCB2.3030703@pleiades.fr.eu.org>

Hi Rafael,

It will not work it the administrator explicitly configured berkeleydb 
as a backend in its configuration file.

What we could do is:
     - convert every database to skiplist and remove the content of the 
db/ directory,
     - then reconvert every database in the format specified in the 
configuration file or skiplist (which is the default since 2.4) if 
nothing is specified.

But basically we would do the work that is already done by Cyrus Imap, 
so it would be better to fix this bug with upstream.

Yann


Le 21/01/2012 12:47, Rafael Ostertag a ?crit :
>
> What about, if we use a preinstall, and convert the deliver db to skiplist
> before installing 2.4?
>
> cheers
> rafi
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.


From raos at opencsw.org  Sat Jan 21 14:29:59 2012
From: raos at opencsw.org (Rafael Ostertag)
Date: Sat, 21 Jan 2012 14:29:59 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <4F1ABCB2.3030703@pleiades.fr.eu.org>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
	<4F1A9ADA.3020900@pleiades.fr.eu.org>
	<20120121114709.GP19279@bender.opencsw.org>
	<4F1ABCB2.3030703@pleiades.fr.eu.org>
Message-ID: <20120121132959.GS19279@bender.opencsw.org>

Hi Yann

On Sat, Jan 21, 2012 at 02:25:06PM +0100, Yann Rouillard wrote:
> Hi Rafael,
> 
> It will not work it the administrator explicitly configured
> berkeleydb as a backend in its configuration file.
> 
> What we could do is:
>     - convert every database to skiplist and remove the content of
> the db/ directory,
>     - then reconvert every database in the format specified in the
> configuration file or skiplist (which is the default since 2.4) if
> nothing is specified.
> 
> But basically we would do the work that is already done by Cyrus
> Imap, so it would be better to fix this bug with upstream.

Absolutely. Does the latest cyrus imapd (2.4.12) still have that bug?

And what if we set the db type explicitely in the config file, as it was in 2.3?

cheers
rafi

From yann at pleiades.fr.eu.org  Sat Jan 21 14:37:29 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Sat, 21 Jan 2012 14:37:29 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <20120121124053.GR19279@bender.opencsw.org>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>	<4F1A9ADA.3020900@pleiades.fr.eu.org>	<4F1A9EBC.50103@pleiades.fr.eu.org>	<20120121115539.GQ19279@bender.opencsw.org>
	<20120121124053.GR19279@bender.opencsw.org>
Message-ID: <4F1ABF99.8080301@pleiades.fr.eu.org>

The configuration file you used explicitly configured berkeleydb as the 
backend.

The bug is triggered if the administrator kept the default settings (and 
I suppose some admins do not change this setting).
The default backend for most cyrus database was berkeleydb before 2.4 
and is now skiplist since 2.4.

Cyrus tries to automagically upgrade from berkeleydb to skiplist and 
this is what didn't work as expected in my tests.

Have a look at the bug I opened upstream 
https://bugzilla.cyrusimap.org/show_bug.cgi?id=3496, I explained the bug 
and attached files which should allow you to reproduce the bug.
You will notice the bug happens the second time you launch cyrus.

(Although I am surprised you didn't run into some berkeleydb problem if 
you upgraded to berkeleydb 4.8).

Yann


Le 21/01/2012 13:40, Rafael Ostertag a ?crit :
> Hi Yann
>
> On Sat, Jan 21, 2012 at 12:55:39PM +0100, Rafael Ostertag wrote:
>>> It will probably break the setup of people who explicitely
>>> configured berkeleydb for cyrus database and the upgrade path should
>>> be documented.
>> Hmm, let me check this.
> I used the this imapd.conf: http://paste.pocoo.org/show/538215/
>
> Same procedure:
>
>   1. installed 2.3.16
>   2. created 2 users
>   3. sent some mails
>   4. upgraded to 2.4
>
> No errors so far. Would you say that is sufficient, or do we have to make a
> more sophisticated test setup?
>
> cheers
> rafi
>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.


From yann at pleiades.fr.eu.org  Sat Jan 21 14:39:46 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Sat, 21 Jan 2012 14:39:46 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <20120121132959.GS19279@bender.opencsw.org>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>	<4F1A9ADA.3020900@pleiades.fr.eu.org>	<20120121114709.GP19279@bender.opencsw.org>	<4F1ABCB2.3030703@pleiades.fr.eu.org>
	<20120121132959.GS19279@bender.opencsw.org>
Message-ID: <4F1AC022.7020805@pleiades.fr.eu.org>

Le 21/01/2012 14:29, Rafael Ostertag a ?crit :
>> But basically we would do the work that is already done by Cyrus
>> Imap, so it would be better to fix this bug with upstream.
> Absolutely. Does the latest cyrus imapd (2.4.12) still have that bug?
I didn't test.


> And what if we set the db type explicitely in the config file, as it was in 2.3?
It was not in the 2.3 default configuration file provided in the opencsw 
package.

Yann



From raos at opencsw.org  Sat Jan 21 14:59:33 2012
From: raos at opencsw.org (Rafael Ostertag)
Date: Sat, 21 Jan 2012 14:59:33 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <4F1ABF99.8080301@pleiades.fr.eu.org>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
	<4F1A9ADA.3020900@pleiades.fr.eu.org>
	<4F1A9EBC.50103@pleiades.fr.eu.org>
	<20120121115539.GQ19279@bender.opencsw.org>
	<20120121124053.GR19279@bender.opencsw.org>
	<4F1ABF99.8080301@pleiades.fr.eu.org>
Message-ID: <20120121135933.GT19279@bender.opencsw.org>

On Sat, Jan 21, 2012 at 02:37:29PM +0100, Yann Rouillard wrote:
> The configuration file you used explicitly configured berkeleydb as
> the backend.
> 
> The bug is triggered if the administrator kept the default settings
> (and I suppose some admins do not change this setting).
> The default backend for most cyrus database was berkeleydb before
> 2.4 and is now skiplist since 2.4.
Yes, I saw that, but I was referring to `what if somebody has explicitely set berkeleydb'.

> 
> Cyrus tries to automagically upgrade from berkeleydb to skiplist and
> this is what didn't work as expected in my tests.
> 
> Have a look at the bug I opened upstream
> https://bugzilla.cyrusimap.org/show_bug.cgi?id=3496, I explained the
> bug and attached files which should allow you to reproduce the bug.
> You will notice the bug happens the second time you launch cyrus.
> 
> (Although I am surprised you didn't run into some berkeleydb problem
> if you upgraded to berkeleydb 4.8).

Me too, taking into account what I heard so far about bdb. Did bdb 4.8 improve
that, perhaps?

It appears from your bug report, that only deliver.db is affected, and since it
is used `only' for duplicate delivery supression, why not taking a radical
approach and just kill it on upgrade?

--rafi
> 
> Yann
> 
> 
> Le 21/01/2012 13:40, Rafael Ostertag a ?crit :
> >Hi Yann
> >
> >On Sat, Jan 21, 2012 at 12:55:39PM +0100, Rafael Ostertag wrote:
> >>>It will probably break the setup of people who explicitely
> >>>configured berkeleydb for cyrus database and the upgrade path should
> >>>be documented.
> >>Hmm, let me check this.
> >I used the this imapd.conf: http://paste.pocoo.org/show/538215/
> >
> >Same procedure:
> >
> >  1. installed 2.3.16
> >  2. created 2 users
> >  3. sent some mails
> >  4. upgraded to 2.4
> >
> >No errors so far. Would you say that is sufficient, or do we have to make a
> >more sophisticated test setup?
> >
> >cheers
> >rafi
> >
> >_______________________________________________
> >maintainers mailing list
> >maintainers at lists.opencsw.org
> >https://lists.opencsw.org/mailman/listinfo/maintainers
> >.:: This mailing list's archive is public. ::.
> 
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
> 

From yann at pleiades.fr.eu.org  Sat Jan 21 15:10:34 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Sat, 21 Jan 2012 15:10:34 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <20120121135933.GT19279@bender.opencsw.org>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>	<4F1A9ADA.3020900@pleiades.fr.eu.org>	<4F1A9EBC.50103@pleiades.fr.eu.org>	<20120121115539.GQ19279@bender.opencsw.org>	<20120121124053.GR19279@bender.opencsw.org>	<4F1ABF99.8080301@pleiades.fr.eu.org>
	<20120121135933.GT19279@bender.opencsw.org>
Message-ID: <4F1AC75A.6040607@pleiades.fr.eu.org>

Le 21/01/2012 14:59, Rafael Ostertag a ?crit :
> On Sat, Jan 21, 2012 at 02:37:29PM +0100, Yann Rouillard wrote:
>> The configuration file you used explicitly configured berkeleydb as
>> the backend.
>>
>> The bug is triggered if the administrator kept the default settings
>> (and I suppose some admins do not change this setting).
>> The default backend for most cyrus database was berkeleydb before
>> 2.4 and is now skiplist since 2.4.
> Yes, I saw that, but I was referring to `what if somebody has explicitely set berkeleydb'.
>
In this casen it should not be a problem if berkeleydb handles 
gracefully the upgrade from 4.2 to 4.8.

>> Cyrus tries to automagically upgrade from berkeleydb to skiplist and
>> this is what didn't work as expected in my tests.
>>
>> Have a look at the bug I opened upstream
>> https://bugzilla.cyrusimap.org/show_bug.cgi?id=3496, I explained the
>> bug and attached files which should allow you to reproduce the bug.
>> You will notice the bug happens the second time you launch cyrus.
>>
>> (Although I am surprised you didn't run into some berkeleydb problem
>> if you upgraded to berkeleydb 4.8).
> Me too, taking into account what I heard so far about bdb. Did bdb 4.8 improve
> that, perhaps?
That's possible. We should check if the bug still happens with 
berkeleydb 4.8.

Because of the berkeleydb reputation, I think we should do more 
extensive test with berkeleydb.

> It appears from your bug report, that only deliver.db is affected, and since it
> is used `only' for duplicate delivery supression, why not taking a radical
> approach and just kill it on upgrade?
The problem isn't exactly deliver.db. deliver.db is correctly converted 
but somehow, a reference to deliver.db is kept in the db files and when 
the berkeleydb backend is initialized, it reads the db files and is not 
happy with that.
Removing the db/ directory before launching cyrus solves the problem, 
but it's not a solution if there is some database which should stay in 
berkeleydb format.

About deliver.db, it is also used to keep track of vacation message 
already sent. Not very important also but we should warn the users.
But the problem may also happen with annotations.db (I never used this 
one but some setup could).

Yann

> --rafi
>> Yann
>>
>>
>> Le 21/01/2012 13:40, Rafael Ostertag a ?crit :
>>> Hi Yann
>>>
>>> On Sat, Jan 21, 2012 at 12:55:39PM +0100, Rafael Ostertag wrote:
>>>>> It will probably break the setup of people who explicitely
>>>>> configured berkeleydb for cyrus database and the upgrade path should
>>>>> be documented.
>>>> Hmm, let me check this.
>>> I used the this imapd.conf: http://paste.pocoo.org/show/538215/
>>>
>>> Same procedure:
>>>
>>>   1. installed 2.3.16
>>>   2. created 2 users
>>>   3. sent some mails
>>>   4. upgraded to 2.4
>>>
>>> No errors so far. Would you say that is sufficient, or do we have to make a
>>> more sophisticated test setup?
>>>
>>> cheers
>>> rafi
>>>
>>> _______________________________________________
>>> maintainers mailing list
>>> maintainers at lists.opencsw.org
>>> https://lists.opencsw.org/mailman/listinfo/maintainers
>>> .:: This mailing list's archive is public. ::.
>> _______________________________________________
>> maintainers mailing list
>> maintainers at lists.opencsw.org
>> https://lists.opencsw.org/mailman/listinfo/maintainers
>> .:: This mailing list's archive is public. ::.
>>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.


From raos at opencsw.org  Sat Jan 21 15:56:55 2012
From: raos at opencsw.org (Rafael Ostertag)
Date: Sat, 21 Jan 2012 15:56:55 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <4F1AC75A.6040607@pleiades.fr.eu.org>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
	<4F1A9ADA.3020900@pleiades.fr.eu.org>
	<4F1A9EBC.50103@pleiades.fr.eu.org>
	<20120121115539.GQ19279@bender.opencsw.org>
	<20120121124053.GR19279@bender.opencsw.org>
	<4F1ABF99.8080301@pleiades.fr.eu.org>
	<20120121135933.GT19279@bender.opencsw.org>
	<4F1AC75A.6040607@pleiades.fr.eu.org>
Message-ID: <20120121145655.GU19279@bender.opencsw.org>

On Sat, Jan 21, 2012 at 03:10:34PM +0100, Yann Rouillard wrote:
> Le 21/01/2012 14:59, Rafael Ostertag a ?crit :
> >On Sat, Jan 21, 2012 at 02:37:29PM +0100, Yann Rouillard wrote:
> >>The configuration file you used explicitly configured berkeleydb as
> >>the backend.
> >>
> >>The bug is triggered if the administrator kept the default settings
> >>(and I suppose some admins do not change this setting).
> >>The default backend for most cyrus database was berkeleydb before
> >>2.4 and is now skiplist since 2.4.
> >Yes, I saw that, but I was referring to `what if somebody has explicitely set berkeleydb'.
> >
> In this casen it should not be a problem if berkeleydb handles
> gracefully the upgrade from 4.2 to 4.8.

I will test again, with bigger databases this time (few thousand mails
delievered)

> 
> >>Cyrus tries to automagically upgrade from berkeleydb to skiplist and
> >>this is what didn't work as expected in my tests.
> >>
> >>Have a look at the bug I opened upstream
> >>https://bugzilla.cyrusimap.org/show_bug.cgi?id=3496, I explained the
> >>bug and attached files which should allow you to reproduce the bug.
> >>You will notice the bug happens the second time you launch cyrus.
> >>
> >>(Although I am surprised you didn't run into some berkeleydb problem
> >>if you upgraded to berkeleydb 4.8).
> >Me too, taking into account what I heard so far about bdb. Did bdb 4.8 improve
> >that, perhaps?
> That's possible. We should check if the bug still happens with
> berkeleydb 4.8.
Yes, I can do that.

> 
> Because of the berkeleydb reputation, I think we should do more
> extensive test with berkeleydb.
> 
> >It appears from your bug report, that only deliver.db is affected, and since it
> >is used `only' for duplicate delivery supression, why not taking a radical
> >approach and just kill it on upgrade?
> The problem isn't exactly deliver.db. deliver.db is correctly
> converted but somehow, a reference to deliver.db is kept in the db
> files and when the berkeleydb backend is initialized, it reads the
> db files and is not happy with that.
> Removing the db/ directory before launching cyrus solves the
> problem, but it's not a solution if there is some database which
> should stay in berkeleydb format.

Well, there goes my radical approach. :)
> 
> About deliver.db, it is also used to keep track of vacation message
> already sent. Not very important also but we should warn the users.
> But the problem may also happen with annotations.db (I never used
> this one but some setup could).
I see.

> 
> Yann
> 
> >--rafi
> >>Yann
> >>
> >>
> >>Le 21/01/2012 13:40, Rafael Ostertag a ?crit :
> >>>Hi Yann
> >>>
> >>>On Sat, Jan 21, 2012 at 12:55:39PM +0100, Rafael Ostertag wrote:
> >>>>>It will probably break the setup of people who explicitely
> >>>>>configured berkeleydb for cyrus database and the upgrade path should
> >>>>>be documented.
> >>>>Hmm, let me check this.
> >>>I used the this imapd.conf: http://paste.pocoo.org/show/538215/
> >>>
> >>>Same procedure:
> >>>
> >>>  1. installed 2.3.16
> >>>  2. created 2 users
> >>>  3. sent some mails
> >>>  4. upgraded to 2.4
> >>>
> >>>No errors so far. Would you say that is sufficient, or do we have to make a
> >>>more sophisticated test setup?
> >>>
> >>>cheers
> >>>rafi
> >>>
> >>>_______________________________________________
> >>>maintainers mailing list
> >>>maintainers at lists.opencsw.org
> >>>https://lists.opencsw.org/mailman/listinfo/maintainers
> >>>.:: This mailing list's archive is public. ::.
> >>_______________________________________________
> >>maintainers mailing list
> >>maintainers at lists.opencsw.org
> >>https://lists.opencsw.org/mailman/listinfo/maintainers
> >>.:: This mailing list's archive is public. ::.
> >>
> >_______________________________________________
> >maintainers mailing list
> >maintainers at lists.opencsw.org
> >https://lists.opencsw.org/mailman/listinfo/maintainers
> >.:: This mailing list's archive is public. ::.
> 
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
> 

From maciej at opencsw.org  Sat Jan 21 16:17:13 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sat, 21 Jan 2012 15:17:13 +0000
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <20120121145655.GU19279@bender.opencsw.org>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
	<4F1A9ADA.3020900@pleiades.fr.eu.org>
	<4F1A9EBC.50103@pleiades.fr.eu.org>
	<20120121115539.GQ19279@bender.opencsw.org>
	<20120121124053.GR19279@bender.opencsw.org>
	<4F1ABF99.8080301@pleiades.fr.eu.org>
	<20120121135933.GT19279@bender.opencsw.org>
	<4F1AC75A.6040607@pleiades.fr.eu.org>
	<20120121145655.GU19279@bender.opencsw.org>
Message-ID: <CALtRa-5c_KD1fS1KtzWe=tQda72KXjvEx-BigFmx3TLUr0frqg@mail.gmail.com>

One note: we've built sasl and cyrus against bdb 4.7, not 4.8.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120121/779a5846/attachment.html>

From raos at opencsw.org  Sat Jan 21 16:22:42 2012
From: raos at opencsw.org (Rafael Ostertag)
Date: Sat, 21 Jan 2012 16:22:42 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <CALtRa-5c_KD1fS1KtzWe=tQda72KXjvEx-BigFmx3TLUr0frqg@mail.gmail.com>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
	<4F1A9ADA.3020900@pleiades.fr.eu.org>
	<4F1A9EBC.50103@pleiades.fr.eu.org>
	<20120121115539.GQ19279@bender.opencsw.org>
	<20120121124053.GR19279@bender.opencsw.org>
	<4F1ABF99.8080301@pleiades.fr.eu.org>
	<20120121135933.GT19279@bender.opencsw.org>
	<4F1AC75A.6040607@pleiades.fr.eu.org>
	<20120121145655.GU19279@bender.opencsw.org>
	<CALtRa-5c_KD1fS1KtzWe=tQda72KXjvEx-BigFmx3TLUr0frqg@mail.gmail.com>
Message-ID: <20120121152242.GV19279@bender.opencsw.org>

Hi Maciej

On Sat, Jan 21, 2012 at 03:17:13PM +0000, Maciej (Matchek) Blizi??ski wrote:
> One note: we've built sasl and cyrus against bdb 4.7, not 4.8.

Err, I hate to break that to you, but I changed that yesterday, since sendmail
is using sasl as well but is linked against 4.8. So I decided to bring sasl and
cyrus to 4.8.

--rafi

> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.


From raos at opencsw.org  Sat Jan 21 18:21:25 2012
From: raos at opencsw.org (Rafael Ostertag)
Date: Sat, 21 Jan 2012 18:21:25 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <4F1AC75A.6040607@pleiades.fr.eu.org>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
	<4F1A9ADA.3020900@pleiades.fr.eu.org>
	<4F1A9EBC.50103@pleiades.fr.eu.org>
	<20120121115539.GQ19279@bender.opencsw.org>
	<20120121124053.GR19279@bender.opencsw.org>
	<4F1ABF99.8080301@pleiades.fr.eu.org>
	<20120121135933.GT19279@bender.opencsw.org>
	<4F1AC75A.6040607@pleiades.fr.eu.org>
Message-ID: <20120121172125.GW19279@bender.opencsw.org>

On Sat, Jan 21, 2012 at 03:10:34PM +0100, Yann Rouillard wrote:
> Le 21/01/2012 14:59, Rafael Ostertag a ?crit :
> >On Sat, Jan 21, 2012 at 02:37:29PM +0100, Yann Rouillard wrote:
> >>The configuration file you used explicitly configured berkeleydb as
> >>the backend.
> >>
> >>The bug is triggered if the administrator kept the default settings
> >>(and I suppose some admins do not change this setting).
> >>The default backend for most cyrus database was berkeleydb before
> >>2.4 and is now skiplist since 2.4.
> >Yes, I saw that, but I was referring to `what if somebody has explicitely set berkeleydb'.
> >
> In this casen it should not be a problem if berkeleydb handles
> gracefully the upgrade from 4.2 to 4.8.

Well, as it turned out, it's not exactly graceful. But after some playing
arround, it appears running a /opt/csw/sbin/ctl_cyrdb -r -x prior upgrading to
2.4 smoothes things.  Without it, ctl_cyrdb might dump a core upon the first
start of 2.4 and the installation is hosed.

cheers
rafi

From dam at opencsw.org  Sun Jan 22 00:16:56 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 22 Jan 2012 00:16:56 +0100
Subject: [csw-maintainers] Add date to catalogs?
Message-ID: <C61D5E25-754D-43D2-B4BC-DDD097DFADA8@opencsw.org>

Hi,

I remember we talked about adding the creating date of a catalog as metadata
to the head. The current catalogs do not contain a date. As I am currently
working on checking downstream mirror status it would be very useful to do so.
I would favor a timely implementation.


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 bonivart at opencsw.org  Sun Jan 22 00:36:16 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 22 Jan 2012 00:36:16 +0100
Subject: [csw-maintainers] Add date to catalogs?
In-Reply-To: <C61D5E25-754D-43D2-B4BC-DDD097DFADA8@opencsw.org>
References: <C61D5E25-754D-43D2-B4BC-DDD097DFADA8@opencsw.org>
Message-ID: <CABY0g1X4xDOqVrCUpPaZNAfiR-KLSrkhDbGjWU2W9FM9NKBqGg@mail.gmail.com>

On Sun, Jan 22, 2012 at 12:16 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi,
>
> I remember we talked about adding the creating date of a catalog as metadata
> to the head. The current catalogs do not contain a date. As I am currently
> working on checking downstream mirror status it would be very useful to do so.
> I would favor a timely implementation.

I added that after the meeting in Kiel. Just add "--param=timestamp" to bldcat.

/peter

From dam at opencsw.org  Sun Jan 22 11:51:02 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 22 Jan 2012 11:51:02 +0100
Subject: [csw-maintainers] Add date to catalogs?
In-Reply-To: <CABY0g1X4xDOqVrCUpPaZNAfiR-KLSrkhDbGjWU2W9FM9NKBqGg@mail.gmail.com>
References: <C61D5E25-754D-43D2-B4BC-DDD097DFADA8@opencsw.org>
	<CABY0g1X4xDOqVrCUpPaZNAfiR-KLSrkhDbGjWU2W9FM9NKBqGg@mail.gmail.com>
Message-ID: <1317DCB7-B712-430B-AAF1-1853EAADBC51@opencsw.org>

Hi Peter,

Am 22.01.2012 um 00:36 schrieb Peter Bonivart:
> On Sun, Jan 22, 2012 at 12:16 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
>> I remember we talked about adding the creating date of a catalog as metadata
>> to the head. The current catalogs do not contain a date. As I am currently
>> working on checking downstream mirror status it would be very useful to do so.
>> I would favor a timely implementation.
> 
> I added that after the meeting in Kiel. Just add "--param=timestamp" to bldcat.

I am aware of that, but my main issue is to have it in the official catalogs
which are generate with gen-cat.


Best regards

  -- Dago

From dam at opencsw.org  Sun Jan 22 15:08:08 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 22 Jan 2012 15:08:08 +0100
Subject: [csw-maintainers] Location of pgp key
Message-ID: <8C6C4E70-986F-4F0C-875F-8CA9380F53E7@opencsw.org>

Hi,

I would like to reorganize the web page a bit: the mirror list should be moved to
mirror.opencsw.org and the gpg key should IMHO be located at
  www.opencsw.org/security
or such. I noticed the URL is already taken and is a forward to another page. Where is
that set? I looked in the
  .htaccess
  httpd-vhosts.conf
  httpd.conf
but can't find anything. Where is that set?


Best regards

  -- Dago


From bwalton at opencsw.org  Sun Jan 22 15:26:48 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 22 Jan 2012 09:26:48 -0500
Subject: [csw-maintainers] Location of pgp key
In-Reply-To: <8C6C4E70-986F-4F0C-875F-8CA9380F53E7@opencsw.org>
References: <8C6C4E70-986F-4F0C-875F-8CA9380F53E7@opencsw.org>
Message-ID: <1327242308-sup-5141@pinkfloyd.chass.utoronto.ca>

Excerpts from Dagobert Michelsen's message of Sun Jan 22 09:08:08 -0500 2012:

Hi Dago,

> Where is that set? I looked in the

I think this is configured inside wordpress somewhere given what I'm
seeing, but it's not in the url mapping that plugins/opencsw provides
and I don't see it anywhere else with the limited admin rights I have
to the site.  Can someone with full admin rights in wordpress take a
peek?

(I had thought it might be tied to a dynamic redirect to the most
recent 'Recent Updates' category but that's not the case.)

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From bwalton at opencsw.org  Sun Jan 22 15:39:10 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 22 Jan 2012 09:39:10 -0500
Subject: [csw-maintainers] Add date to catalogs?
In-Reply-To: <1317DCB7-B712-430B-AAF1-1853EAADBC51@opencsw.org>
References: <C61D5E25-754D-43D2-B4BC-DDD097DFADA8@opencsw.org>
	<CABY0g1X4xDOqVrCUpPaZNAfiR-KLSrkhDbGjWU2W9FM9NKBqGg@mail.gmail.com>
	<1317DCB7-B712-430B-AAF1-1853EAADBC51@opencsw.org>
Message-ID: <1327242786-sup-6849@pinkfloyd.chass.utoronto.ca>

Excerpts from Dagobert Michelsen's message of Sun Jan 22 05:51:02 -0500 2012:

Hi Dago,

> I am aware of that, but my main issue is to have it in the official
> catalogs which are generate with gen-cat.

The generate-catalog script (driven by generate-unstable) is calling:
bldcat --fast --param=timestamp

For some reason I don't yet understand, our catalogs aren't getting a
timestamp embedded though.  I have to run now but I'll try to identify
the problem later today.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From bonivart at opencsw.org  Sun Jan 22 15:46:08 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 22 Jan 2012 15:46:08 +0100
Subject: [csw-maintainers] Add date to catalogs?
In-Reply-To: <1327242786-sup-6849@pinkfloyd.chass.utoronto.ca>
References: <C61D5E25-754D-43D2-B4BC-DDD097DFADA8@opencsw.org>
	<CABY0g1X4xDOqVrCUpPaZNAfiR-KLSrkhDbGjWU2W9FM9NKBqGg@mail.gmail.com>
	<1317DCB7-B712-430B-AAF1-1853EAADBC51@opencsw.org>
	<1327242786-sup-6849@pinkfloyd.chass.utoronto.ca>
Message-ID: <CABY0g1WEXwLKUGcS-bvOZg0YkaAaHXRtcCzFBA_Ot8V24HKEeg@mail.gmail.com>

On Sun, Jan 22, 2012 at 3:39 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Dagobert Michelsen's message of Sun Jan 22 05:51:02 -0500 2012:
>
> Hi Dago,
>
>> I am aware of that, but my main issue is to have it in the official
>> catalogs which are generate with gen-cat.
>
> The generate-catalog script (driven by generate-unstable) is calling:
> bldcat --fast --param=timestamp
>
> For some reason I don't yet understand, our catalogs aren't getting a
> timestamp embedded though. ?I have to run now but I'll try to identify
> the problem later today.

Old version? Since pkgutil 2.6 (2012-12-31), bldcat has had this
feature. Make sure the CSWpkgutilplus package is up to date.

/peter

From skayser at opencsw.org  Sun Jan 22 16:17:46 2012
From: skayser at opencsw.org (Sebastian Kayser)
Date: Sun, 22 Jan 2012 16:17:46 +0100
Subject: [csw-maintainers] Location of pgp key
In-Reply-To: <1327242308-sup-5141@pinkfloyd.chass.utoronto.ca>
References: <8C6C4E70-986F-4F0C-875F-8CA9380F53E7@opencsw.org>
	<1327242308-sup-5141@pinkfloyd.chass.utoronto.ca>
Message-ID: <20120122151746.GD19520@sebastiankayser.de>

* Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Dagobert Michelsen's message of Sun Jan 22 09:08:08 -0500 2012:
> > Where is that set? I looked in the
> 
> I think this is configured inside wordpress somewhere given what I'm
> seeing, but it's not in the url mapping that plugins/opencsw provides
> and I don't see it anywhere else with the limited admin rights I have
> to the site.  Can someone with full admin rights in wordpress take a
> peek?
> 
> (I had thought it might be tied to a dynamic redirect to the most
> recent 'Recent Updates' category but that's not the case.)

The .htaccess for www.opencsw.org contains a generic wordpress redirect.

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/mantis
RewriteCond %{REQUEST_URI} !^/bugtrack
...
RewriteRule . /index.php [L]

This catches /security and Worpress then seems to do prefix based
matching on the news articles. I've now excluded /security via another
RewriteCond, so Dago, you should be good to go.

Sebastian

From dam at opencsw.org  Sun Jan 22 17:31:52 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 22 Jan 2012 17:31:52 +0100
Subject: [csw-maintainers] Add date to catalogs?
In-Reply-To: <1327242786-sup-6849@pinkfloyd.chass.utoronto.ca>
References: <C61D5E25-754D-43D2-B4BC-DDD097DFADA8@opencsw.org>
	<CABY0g1X4xDOqVrCUpPaZNAfiR-KLSrkhDbGjWU2W9FM9NKBqGg@mail.gmail.com>
	<1317DCB7-B712-430B-AAF1-1853EAADBC51@opencsw.org>
	<1327242786-sup-6849@pinkfloyd.chass.utoronto.ca>
Message-ID: <32D7C237-A2D2-4563-9368-DBF1E188149E@opencsw.org>

Hi Ben,

Am 22.01.2012 um 15:39 schrieb Ben Walton:
> Excerpts from Dagobert Michelsen's message of Sun Jan 22 05:51:02 -0500 2012:
>> I am aware of that, but my main issue is to have it in the official
>> catalogs which are generate with gen-cat.
> 
> The generate-catalog script (driven by generate-unstable) is calling:
> bldcat --fast --param=timestamp
> 
> For some reason I don't yet understand, our catalogs aren't getting a
> timestamp embedded though.  I have to run now but I'll try to identify
> the problem later today.

I just found the script and made the change an hour ago :-)
So just lets wait a day and see if it works.


Best regards

  -- Dago

From bwalton at opencsw.org  Sun Jan 22 20:07:04 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 22 Jan 2012 14:07:04 -0500
Subject: [csw-maintainers] Location of pgp key
In-Reply-To: <20120122151746.GD19520@sebastiankayser.de>
References: <8C6C4E70-986F-4F0C-875F-8CA9380F53E7@opencsw.org>
	<1327242308-sup-5141@pinkfloyd.chass.utoronto.ca>
	<20120122151746.GD19520@sebastiankayser.de>
Message-ID: <1327259181-sup-1355@pinkfloyd.chass.utoronto.ca>

Excerpts from Sebastian Kayser's message of Sun Jan 22 10:17:46 -0500 2012:

> This catches /security and Worpress then seems to do prefix based
> matching on the news articles. I've now excluded /security via
> another RewriteCond, so Dago, you should be good to go.

Ok, so if it is just some wordpress magic, presumably we could just
define a page with that url and not alter the rewrites at all?

Thanks for finding this!

-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From yann at pleiades.fr.eu.org  Sun Jan 22 20:14:19 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Sun, 22 Jan 2012 20:14:19 +0100
Subject: [csw-maintainers] New openssl packages
Message-ID: <4F1C600B.4090107@pleiades.fr.eu.org>


I updated the openssl packages set so it follows the library package 
naming and the /etc/opt/csw/ configuration directory standards.

I would welcome additionnal testing of the package before releasing them 
to the unstable repository.

They are available in my experimental repository:
http://buildfarm.opencsw.org/experimental.html#yann

Thanks in advance for any feedback,

Yann

From yann at pleiades.fr.eu.org  Sun Jan 22 20:31:00 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Sun, 22 Jan 2012 20:31:00 +0100
Subject: [csw-maintainers] New openssl packages
In-Reply-To: <4F1C600B.4090107@pleiades.fr.eu.org>
References: <4F1C600B.4090107@pleiades.fr.eu.org>
Message-ID: <4F1C63F4.50309@pleiades.fr.eu.org>

Hi again,

For those interested in some ssl speed up, there is an experimental 
openssl 0.9.8 build with pkcs11 support available in my build directory 
(/home/yann/build/ on the buildfarm).
It allows opencsw openssl to take advantage of crypto-hardware 
acceleration available on some sun servers, Ultrasparc T2 for example.

Here is an excerpt of openssl rsa speed test to see the difference:

Without pkcs11: 719 1024 bit private RSA's in 10.00s
With pkcs11: 10906 1024 bit private RSA's in 2.92s

I am also interested in some more testing of these packages.

Yann


Quick Openssl RSA benchmark:

# OPENCSW OPENSSL WITHOUT PKCS11 engine
# openssl speed rsa

Doing 512 bit private rsa's for 10s: 3154 512 bit private RSA's in 10.00s
Doing 512 bit public rsa's for 10s: 39315 512 bit public RSA's in 9.95s
Doing 1024 bit private rsa's for 10s: 719 1024 bit private RSA's in 10.00s
Doing 1024 bit public rsa's for 10s: 15178 1024 bit public RSA's in 10.00s
Doing 2048 bit private rsa's for 10s: 128 2048 bit private RSA's in 10.07s
Doing 2048 bit public rsa's for 10s: 4779 2048 bit public RSA's in 9.99s
Doing 4096 bit private rsa's for 10s: 21 4096 bit private RSA's in 10.39s
Doing 4096 bit public rsa's for 10s: 1356 4096 bit public RSA's in 9.98s
OpenSSL 0.9.8t 18 Jan 2012
built on: Sun Jan 22 12:41:16 CET 2012
options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) 
aes(partial) idea(int) blowfish(ptr)
compiler: cc -KPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -DPK11_LIB_LOCATION="/usr/lib/libpkcs11.so" 
-xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN 
-DBN_DIV2W
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
                   sign    verify    sign/s verify/s
rsa  512 bits 0.003171s 0.000253s    315.4   3951.3
rsa 1024 bits 0.013908s 0.000659s     71.9   1517.8
rsa 2048 bits 0.078672s 0.002090s     12.7    478.4
rsa 4096 bits 0.494762s 0.007360s      2.0    135.9


# OPENCSW OPENSSL WITH PKCS11 engine
# openssl speed -engine pkcs11 rsa

engine "pkcs11" set.
Doing 512 bit private rsa's for 10s: 31397 512 bit private RSA's in 1.19s
Doing 512 bit public rsa's for 10s: 30262 512 bit public RSA's in 5.28s
Doing 1024 bit private rsa's for 10s: 10906 1024 bit private RSA's in 2.92s
Doing 1024 bit public rsa's for 10s: 20980 1024 bit public RSA's in 3.80s
Doing 2048 bit private rsa's for 10s: 3900 2048 bit private RSA's in 1.13s
Doing 2048 bit public rsa's for 10s: 10639 2048 bit public RSA's in 1.97s
Doing 4096 bit private rsa's for 10s: 15 4096 bit private RSA's in 10.45s
Doing 4096 bit public rsa's for 10s: 537 4096 bit public RSA's in 10.00s
OpenSSL 0.9.8t 18 Jan 2012
built on: Sun Jan 22 12:41:16 CET 2012
options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) 
aes(partial) idea(int) blowfish(ptr)
compiler: cc -KPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -DPK11_LIB_LOCATION="/usr/lib/libpkcs11.so" 
-xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN 
-DBN_DIV2W
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
                   sign    verify    sign/s verify/s
rsa  512 bits 0.000038s 0.000174s  26384.0   5731.4
rsa 1024 bits 0.000268s 0.000181s   3734.9   5521.1
rsa 2048 bits 0.000290s 0.000185s   3451.3   5400.5
rsa 4096 bits 0.696667s 0.018622s      1.4     53.7


# SUN OPENSSL WITHOUT PKCS11 ENGINE
# openssl speed rsa

Doing 512 bit private rsa's for 10s: 2101 512 bit private RSA's in 9.99s
Doing 512 bit public rsa's for 10s: 20924 512 bit public RSA's in 10.00s
Doing 1024 bit private rsa's for 10s: 403 1024 bit private RSA's in 10.00s
Doing 1024 bit public rsa's for 10s: 6960 1024 bit public RSA's in 10.00s
Doing 2048 bit private rsa's for 10s: 64 2048 bit private RSA's in 10.03s
Doing 2048 bit public rsa's for 10s: 2056 2048 bit public RSA's in 9.99s
Doing 4096 bit private rsa's for 10s: 10 4096 bit private RSA's in 10.85s
Doing 4096 bit public rsa's for 10s: 569 4096 bit public RSA's in 10.01s
OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes for: CVE-2005-2969 
CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 CVE-2006-4343 
CVE-2007-5135 CVE-2007-3108 CVE-2008-5077 CVE-2009-0590 CVE-2009-3555)
built on: date not available
options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) 
aes(partial) blowfish(ptr)
compiler: information not available
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
                   sign    verify    sign/s verify/s
rsa  512 bits   0.0048s   0.0005s    210.3   2092.4
rsa 1024 bits   0.0248s   0.0014s     40.3    696.0
rsa 2048 bits   0.1567s   0.0049s      6.4    205.8
rsa 4096 bits   1.0850s   0.0176s      0.9     56.8


# SUN OPENSSL WITH PKCS11 ENGINE
# openssl speed -engine pkcs11 rsa

engine "pkcs11" set.
Doing 512 bit private rsa's for 10s: 30855 512 bit private RSA's in 1.17s
Doing 512 bit public rsa's for 10s: 53489 512 bit public RSA's in 1.75s
Doing 1024 bit private rsa's for 10s: 14632 1024 bit private RSA's in 0.59s
Doing 1024 bit public rsa's for 10s: 28838 1024 bit public RSA's in 0.97s
Doing 2048 bit private rsa's for 10s: 4153 2048 bit private RSA's in 0.19s
Doing 2048 bit public rsa's for 10s: 12484 2048 bit public RSA's in 0.44s
Doing 4096 bit private rsa's for 10s: 14 4096 bit private RSA's in 10.03s
Doing 4096 bit public rsa's for 10s: 542 4096 bit public RSA's in 9.99s
OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes for: CVE-2005-2969 
CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 CVE-2006-4343 
CVE-2007-5135 CVE-2007-3108 CVE-2008-5077 CVE-2009-0590 CVE-2009-3555)
built on: date not available
options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) 
aes(partial) blowfish(ptr)
compiler: information not available
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
                   sign    verify    sign/s verify/s
rsa  512 bits   0.0000s   0.0000s  26371.8  30565.1
rsa 1024 bits   0.0000s   0.0000s  24800.0  29729.9
rsa 2048 bits   0.0000s   0.0000s  21857.9  28372.7
rsa 4096 bits   0.7164s   0.0184s      1.4     54.3





Le 22/01/2012 20:14, Yann Rouillard a ?crit :
>
> I updated the openssl packages set so it follows the library package 
> naming and the /etc/opt/csw/ configuration directory standards.
>
> I would welcome additionnal testing of the package before releasing 
> them to the unstable repository.
>
> They are available in my experimental repository:
> http://buildfarm.opencsw.org/experimental.html#yann
>
> Thanks in advance for any feedback,
>
> Yann
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.


From rupert at opencsw.org  Sun Jan 22 20:38:59 2012
From: rupert at opencsw.org (rupert THURNER)
Date: Sun, 22 Jan 2012 20:38:59 +0100
Subject: [csw-maintainers] New openssl packages
In-Reply-To: <4F1C63F4.50309@pleiades.fr.eu.org>
References: <4F1C600B.4090107@pleiades.fr.eu.org>
	<4F1C63F4.50309@pleiades.fr.eu.org>
Message-ID: <CAJs9aZ_qTMOhtx5uGsVAZ_2nHZiMeRJm09iO5-Lp4CMRGVn8Zg@mail.gmail.com>

hi yann, this seems very interesting. how does this affect ones daily
life, or in other words, how often does this get used? is it only on
connection setup, or it somehow helps when encrypting the traffic?

On Sun, Jan 22, 2012 at 20:31, Yann Rouillard <yann at pleiades.fr.eu.org> wrote:
> Hi again,
>
> For those interested in some ssl speed up, there is an experimental openssl
> 0.9.8 build with pkcs11 support available in my build directory
> (/home/yann/build/ on the buildfarm).
> It allows opencsw openssl to take advantage of crypto-hardware acceleration
> available on some sun servers, Ultrasparc T2 for example.
>
> Here is an excerpt of openssl rsa speed test to see the difference:
>
> Without pkcs11: 719 1024 bit private RSA's in 10.00s
> With pkcs11: 10906 1024 bit private RSA's in 2.92s
>
> I am also interested in some more testing of these packages.
>
> Yann
>
>
> Quick Openssl RSA benchmark:
>
> # OPENCSW OPENSSL WITHOUT PKCS11 engine
> # openssl speed rsa
>
> Doing 512 bit private rsa's for 10s: 3154 512 bit private RSA's in 10.00s
> Doing 512 bit public rsa's for 10s: 39315 512 bit public RSA's in 9.95s
> Doing 1024 bit private rsa's for 10s: 719 1024 bit private RSA's in 10.00s
> Doing 1024 bit public rsa's for 10s: 15178 1024 bit public RSA's in 10.00s
> Doing 2048 bit private rsa's for 10s: 128 2048 bit private RSA's in 10.07s
> Doing 2048 bit public rsa's for 10s: 4779 2048 bit public RSA's in 9.99s
> Doing 4096 bit private rsa's for 10s: 21 4096 bit private RSA's in 10.39s
> Doing 4096 bit public rsa's for 10s: 1356 4096 bit public RSA's in 9.98s
> OpenSSL 0.9.8t 18 Jan 2012
> built on: Sun Jan 22 12:41:16 CET 2012
> options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) aes(partial)
> idea(int) blowfish(ptr)
> compiler: cc -KPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
> -DHAVE_DLFCN_H -DPK11_LIB_LOCATION="/usr/lib/libpkcs11.so" -xtarget=ultra
> -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W
> available timing options: TIMES TIMEB HZ=100 [sysconf value]
> timing function used: times
> ? ? ? ? ? ? ? ? ?sign ? ?verify ? ?sign/s verify/s
> rsa ?512 bits 0.003171s 0.000253s ? ?315.4 ? 3951.3
> rsa 1024 bits 0.013908s 0.000659s ? ? 71.9 ? 1517.8
> rsa 2048 bits 0.078672s 0.002090s ? ? 12.7 ? ?478.4
> rsa 4096 bits 0.494762s 0.007360s ? ? ?2.0 ? ?135.9
>
>
> # OPENCSW OPENSSL WITH PKCS11 engine
> # openssl speed -engine pkcs11 rsa
>
> engine "pkcs11" set.
> Doing 512 bit private rsa's for 10s: 31397 512 bit private RSA's in 1.19s
> Doing 512 bit public rsa's for 10s: 30262 512 bit public RSA's in 5.28s
> Doing 1024 bit private rsa's for 10s: 10906 1024 bit private RSA's in 2.92s
> Doing 1024 bit public rsa's for 10s: 20980 1024 bit public RSA's in 3.80s
> Doing 2048 bit private rsa's for 10s: 3900 2048 bit private RSA's in 1.13s
> Doing 2048 bit public rsa's for 10s: 10639 2048 bit public RSA's in 1.97s
> Doing 4096 bit private rsa's for 10s: 15 4096 bit private RSA's in 10.45s
> Doing 4096 bit public rsa's for 10s: 537 4096 bit public RSA's in 10.00s
> OpenSSL 0.9.8t 18 Jan 2012
> built on: Sun Jan 22 12:41:16 CET 2012
> options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) aes(partial)
> idea(int) blowfish(ptr)
> compiler: cc -KPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
> -DHAVE_DLFCN_H -DPK11_LIB_LOCATION="/usr/lib/libpkcs11.so" -xtarget=ultra
> -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W
> available timing options: TIMES TIMEB HZ=100 [sysconf value]
> timing function used: times
> ? ? ? ? ? ? ? ? ?sign ? ?verify ? ?sign/s verify/s
> rsa ?512 bits 0.000038s 0.000174s ?26384.0 ? 5731.4
> rsa 1024 bits 0.000268s 0.000181s ? 3734.9 ? 5521.1
> rsa 2048 bits 0.000290s 0.000185s ? 3451.3 ? 5400.5
> rsa 4096 bits 0.696667s 0.018622s ? ? ?1.4 ? ? 53.7
>
>
> # SUN OPENSSL WITHOUT PKCS11 ENGINE
> # openssl speed rsa
>
> Doing 512 bit private rsa's for 10s: 2101 512 bit private RSA's in 9.99s
> Doing 512 bit public rsa's for 10s: 20924 512 bit public RSA's in 10.00s
> Doing 1024 bit private rsa's for 10s: 403 1024 bit private RSA's in 10.00s
> Doing 1024 bit public rsa's for 10s: 6960 1024 bit public RSA's in 10.00s
> Doing 2048 bit private rsa's for 10s: 64 2048 bit private RSA's in 10.03s
> Doing 2048 bit public rsa's for 10s: 2056 2048 bit public RSA's in 9.99s
> Doing 4096 bit private rsa's for 10s: 10 4096 bit private RSA's in 10.85s
> Doing 4096 bit public rsa's for 10s: 569 4096 bit public RSA's in 10.01s
> OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes for: CVE-2005-2969
> CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 CVE-2006-4343
> CVE-2007-5135 CVE-2007-3108 CVE-2008-5077 CVE-2009-0590 CVE-2009-3555)
> built on: date not available
> options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) aes(partial)
> blowfish(ptr)
> compiler: information not available
> available timing options: TIMES TIMEB HZ=100 [sysconf value]
> timing function used: times
> ? ? ? ? ? ? ? ? ?sign ? ?verify ? ?sign/s verify/s
> rsa ?512 bits ? 0.0048s ? 0.0005s ? ?210.3 ? 2092.4
> rsa 1024 bits ? 0.0248s ? 0.0014s ? ? 40.3 ? ?696.0
> rsa 2048 bits ? 0.1567s ? 0.0049s ? ? ?6.4 ? ?205.8
> rsa 4096 bits ? 1.0850s ? 0.0176s ? ? ?0.9 ? ? 56.8
>
>
> # SUN OPENSSL WITH PKCS11 ENGINE
> # openssl speed -engine pkcs11 rsa
>
> engine "pkcs11" set.
> Doing 512 bit private rsa's for 10s: 30855 512 bit private RSA's in 1.17s
> Doing 512 bit public rsa's for 10s: 53489 512 bit public RSA's in 1.75s
> Doing 1024 bit private rsa's for 10s: 14632 1024 bit private RSA's in 0.59s
> Doing 1024 bit public rsa's for 10s: 28838 1024 bit public RSA's in 0.97s
> Doing 2048 bit private rsa's for 10s: 4153 2048 bit private RSA's in 0.19s
> Doing 2048 bit public rsa's for 10s: 12484 2048 bit public RSA's in 0.44s
> Doing 4096 bit private rsa's for 10s: 14 4096 bit private RSA's in 10.03s
> Doing 4096 bit public rsa's for 10s: 542 4096 bit public RSA's in 9.99s
> OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes for: CVE-2005-2969
> CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 CVE-2006-4343
> CVE-2007-5135 CVE-2007-3108 CVE-2008-5077 CVE-2009-0590 CVE-2009-3555)
> built on: date not available
> options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) aes(partial)
> blowfish(ptr)
> compiler: information not available
> available timing options: TIMES TIMEB HZ=100 [sysconf value]
> timing function used: times
> ? ? ? ? ? ? ? ? ?sign ? ?verify ? ?sign/s verify/s
> rsa ?512 bits ? 0.0000s ? 0.0000s ?26371.8 ?30565.1
> rsa 1024 bits ? 0.0000s ? 0.0000s ?24800.0 ?29729.9
> rsa 2048 bits ? 0.0000s ? 0.0000s ?21857.9 ?28372.7
> rsa 4096 bits ? 0.7164s ? 0.0184s ? ? ?1.4 ? ? 54.3
>
>
>
>
>
> Le 22/01/2012 20:14, Yann Rouillard a ?crit :
>>
>>
>> I updated the openssl packages set so it follows the library package
>> naming and the /etc/opt/csw/ configuration directory standards.
>>
>> I would welcome additionnal testing of the package before releasing them
>> to the unstable repository.
>>
>> They are available in my experimental repository:
>> http://buildfarm.opencsw.org/experimental.html#yann
>>
>> Thanks in advance for any feedback,
>>
>> Yann
>> _______________________________________________
>> maintainers mailing list
>> maintainers at lists.opencsw.org
>> https://lists.opencsw.org/mailman/listinfo/maintainers
>> .:: This mailing list's archive is public. ::.
>
>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.

From bonivart at opencsw.org  Sun Jan 22 20:52:55 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 22 Jan 2012 20:52:55 +0100
Subject: [csw-maintainers] New openssl packages
In-Reply-To: <4F1C600B.4090107@pleiades.fr.eu.org>
References: <4F1C600B.4090107@pleiades.fr.eu.org>
Message-ID: <CABY0g1XxNT-sVBdYPsKJKsKM8eo2P8BWN8=83JGpq4rKxxTyyw@mail.gmail.com>

On Sun, Jan 22, 2012 at 8:14 PM, Yann Rouillard <yann at pleiades.fr.eu.org> wrote:
>
> I updated the openssl packages set so it follows the library package naming
> and the /etc/opt/csw/ configuration directory standards.
>
> I would welcome additionnal testing of the package before releasing them to
> the unstable repository.
>
> They are available in my experimental repository:
> http://buildfarm.opencsw.org/experimental.html#yann

I did some simple tests and it seems to work fine for me.

/peter

From dam at opencsw.org  Sun Jan 22 22:01:28 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 22 Jan 2012 22:01:28 +0100
Subject: [csw-maintainers] Add date to catalogs?
In-Reply-To: <32D7C237-A2D2-4563-9368-DBF1E188149E@opencsw.org>
References: <C61D5E25-754D-43D2-B4BC-DDD097DFADA8@opencsw.org>
	<CABY0g1X4xDOqVrCUpPaZNAfiR-KLSrkhDbGjWU2W9FM9NKBqGg@mail.gmail.com>
	<1317DCB7-B712-430B-AAF1-1853EAADBC51@opencsw.org>
	<1327242786-sup-6849@pinkfloyd.chass.utoronto.ca>
	<32D7C237-A2D2-4563-9368-DBF1E188149E@opencsw.org>
Message-ID: <C6450920-C877-474D-9BE8-9A46C5B5D58E@opencsw.org>

Hi,

Am 22.01.2012 um 17:31 schrieb Dagobert Michelsen:
> Am 22.01.2012 um 15:39 schrieb Ben Walton:
>> Excerpts from Dagobert Michelsen's message of Sun Jan 22 05:51:02 -0500 2012:
>>> I am aware of that, but my main issue is to have it in the official
>>> catalogs which are generate with gen-cat.
>> 
>> The generate-catalog script (driven by generate-unstable) is calling:
>> bldcat --fast --param=timestamp
>> 
>> For some reason I don't yet understand, our catalogs aren't getting a
>> timestamp embedded though.  I have to run now but I'll try to identify
>> the problem later today.
> 
> I just found the script and made the change an hour ago :-)
> So just lets wait a day and see if it works.

Yeah! It is in:

> dam at login [login]:/home/dam > wget -q -O - http://mirror.opencsw.org/opencsw/unstable/sparc/5.10/catalog | grep CREATION
> # CREATIONDATE 2012-01-22T20:34:41Z

Thanks everyone!


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 Jan 22 22:22:15 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 22 Jan 2012 16:22:15 -0500
Subject: [csw-maintainers] New openssl packages
In-Reply-To: <4F1C600B.4090107@pleiades.fr.eu.org>
References: <4F1C600B.4090107@pleiades.fr.eu.org>
Message-ID: <1327267249-sup-6295@pinkfloyd.chass.utoronto.ca>

Excerpts from Yann Rouillard's message of Sun Jan 22 14:14:19 -0500 2012:

Hi Yann,

> I updated the openssl packages set so it follows the library package
> naming and the /etc/opt/csw/ configuration directory standards.

Did you intend to place sparc packages for testing too or i386 only?

Thanks for doing this library split!

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From yann at pleiades.fr.eu.org  Sun Jan 22 23:18:12 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Sun, 22 Jan 2012 23:18:12 +0100
Subject: [csw-maintainers] New openssl packages
In-Reply-To: <CAJs9aZ_qTMOhtx5uGsVAZ_2nHZiMeRJm09iO5-Lp4CMRGVn8Zg@mail.gmail.com>
References: <4F1C600B.4090107@pleiades.fr.eu.org>	<4F1C63F4.50309@pleiades.fr.eu.org>
	<CAJs9aZ_qTMOhtx5uGsVAZ_2nHZiMeRJm09iO5-Lp4CMRGVn8Zg@mail.gmail.com>
Message-ID: <4F1C8B24.50000@pleiades.fr.eu.org>

Hi Rupert,

I am not a cryptography expert, but you can have a look at this 
document: 
http://www.oracle.com/technetwork/server-storage/archive/a11-014-crypto-accelerators-439765.pdf
it contains a little performance chapter part at the end of the document 
which shows the impact of using hardware acceleration on the number of 
operations/seconds Apache can handle in HTTPS.

It would be nice if someone could confirm this numbers with Apache. I 
don't have administrator access on an Ultrasparc T1/T2 server (I made 
the openssl test on unstable10s|x).
I suppose it will also work with Ultrasparc T3.

Yann


Le 22/01/2012 20:38, rupert THURNER a ?crit :
> hi yann, this seems very interesting. how does this affect ones daily
> life, or in other words, how often does this get used? is it only on
> connection setup, or it somehow helps when encrypting the traffic?
>
> On Sun, Jan 22, 2012 at 20:31, Yann Rouillard<yann at pleiades.fr.eu.org>  wrote:
>> Hi again,
>>
>> For those interested in some ssl speed up, there is an experimental openssl
>> 0.9.8 build with pkcs11 support available in my build directory
>> (/home/yann/build/ on the buildfarm).
>> It allows opencsw openssl to take advantage of crypto-hardware acceleration
>> available on some sun servers, Ultrasparc T2 for example.
>>
>> Here is an excerpt of openssl rsa speed test to see the difference:
>>
>> Without pkcs11: 719 1024 bit private RSA's in 10.00s
>> With pkcs11: 10906 1024 bit private RSA's in 2.92s
>>
>> I am also interested in some more testing of these packages.
>>
>> Yann
>>
>>
>> Quick Openssl RSA benchmark:
>>
>> # OPENCSW OPENSSL WITHOUT PKCS11 engine
>> # openssl speed rsa
>>
>> Doing 512 bit private rsa's for 10s: 3154 512 bit private RSA's in 10.00s
>> Doing 512 bit public rsa's for 10s: 39315 512 bit public RSA's in 9.95s
>> Doing 1024 bit private rsa's for 10s: 719 1024 bit private RSA's in 10.00s
>> Doing 1024 bit public rsa's for 10s: 15178 1024 bit public RSA's in 10.00s
>> Doing 2048 bit private rsa's for 10s: 128 2048 bit private RSA's in 10.07s
>> Doing 2048 bit public rsa's for 10s: 4779 2048 bit public RSA's in 9.99s
>> Doing 4096 bit private rsa's for 10s: 21 4096 bit private RSA's in 10.39s
>> Doing 4096 bit public rsa's for 10s: 1356 4096 bit public RSA's in 9.98s
>> OpenSSL 0.9.8t 18 Jan 2012
>> built on: Sun Jan 22 12:41:16 CET 2012
>> options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) aes(partial)
>> idea(int) blowfish(ptr)
>> compiler: cc -KPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
>> -DHAVE_DLFCN_H -DPK11_LIB_LOCATION="/usr/lib/libpkcs11.so" -xtarget=ultra
>> -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W
>> available timing options: TIMES TIMEB HZ=100 [sysconf value]
>> timing function used: times
>>                   sign    verify    sign/s verify/s
>> rsa  512 bits 0.003171s 0.000253s    315.4   3951.3
>> rsa 1024 bits 0.013908s 0.000659s     71.9   1517.8
>> rsa 2048 bits 0.078672s 0.002090s     12.7    478.4
>> rsa 4096 bits 0.494762s 0.007360s      2.0    135.9
>>
>>
>> # OPENCSW OPENSSL WITH PKCS11 engine
>> # openssl speed -engine pkcs11 rsa
>>
>> engine "pkcs11" set.
>> Doing 512 bit private rsa's for 10s: 31397 512 bit private RSA's in 1.19s
>> Doing 512 bit public rsa's for 10s: 30262 512 bit public RSA's in 5.28s
>> Doing 1024 bit private rsa's for 10s: 10906 1024 bit private RSA's in 2.92s
>> Doing 1024 bit public rsa's for 10s: 20980 1024 bit public RSA's in 3.80s
>> Doing 2048 bit private rsa's for 10s: 3900 2048 bit private RSA's in 1.13s
>> Doing 2048 bit public rsa's for 10s: 10639 2048 bit public RSA's in 1.97s
>> Doing 4096 bit private rsa's for 10s: 15 4096 bit private RSA's in 10.45s
>> Doing 4096 bit public rsa's for 10s: 537 4096 bit public RSA's in 10.00s
>> OpenSSL 0.9.8t 18 Jan 2012
>> built on: Sun Jan 22 12:41:16 CET 2012
>> options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) aes(partial)
>> idea(int) blowfish(ptr)
>> compiler: cc -KPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
>> -DHAVE_DLFCN_H -DPK11_LIB_LOCATION="/usr/lib/libpkcs11.so" -xtarget=ultra
>> -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W
>> available timing options: TIMES TIMEB HZ=100 [sysconf value]
>> timing function used: times
>>                   sign    verify    sign/s verify/s
>> rsa  512 bits 0.000038s 0.000174s  26384.0   5731.4
>> rsa 1024 bits 0.000268s 0.000181s   3734.9   5521.1
>> rsa 2048 bits 0.000290s 0.000185s   3451.3   5400.5
>> rsa 4096 bits 0.696667s 0.018622s      1.4     53.7
>>
>>
>> # SUN OPENSSL WITHOUT PKCS11 ENGINE
>> # openssl speed rsa
>>
>> Doing 512 bit private rsa's for 10s: 2101 512 bit private RSA's in 9.99s
>> Doing 512 bit public rsa's for 10s: 20924 512 bit public RSA's in 10.00s
>> Doing 1024 bit private rsa's for 10s: 403 1024 bit private RSA's in 10.00s
>> Doing 1024 bit public rsa's for 10s: 6960 1024 bit public RSA's in 10.00s
>> Doing 2048 bit private rsa's for 10s: 64 2048 bit private RSA's in 10.03s
>> Doing 2048 bit public rsa's for 10s: 2056 2048 bit public RSA's in 9.99s
>> Doing 4096 bit private rsa's for 10s: 10 4096 bit private RSA's in 10.85s
>> Doing 4096 bit public rsa's for 10s: 569 4096 bit public RSA's in 10.01s
>> OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes for: CVE-2005-2969
>> CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 CVE-2006-4343
>> CVE-2007-5135 CVE-2007-3108 CVE-2008-5077 CVE-2009-0590 CVE-2009-3555)
>> built on: date not available
>> options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) aes(partial)
>> blowfish(ptr)
>> compiler: information not available
>> available timing options: TIMES TIMEB HZ=100 [sysconf value]
>> timing function used: times
>>                   sign    verify    sign/s verify/s
>> rsa  512 bits   0.0048s   0.0005s    210.3   2092.4
>> rsa 1024 bits   0.0248s   0.0014s     40.3    696.0
>> rsa 2048 bits   0.1567s   0.0049s      6.4    205.8
>> rsa 4096 bits   1.0850s   0.0176s      0.9     56.8
>>
>>
>> # SUN OPENSSL WITH PKCS11 ENGINE
>> # openssl speed -engine pkcs11 rsa
>>
>> engine "pkcs11" set.
>> Doing 512 bit private rsa's for 10s: 30855 512 bit private RSA's in 1.17s
>> Doing 512 bit public rsa's for 10s: 53489 512 bit public RSA's in 1.75s
>> Doing 1024 bit private rsa's for 10s: 14632 1024 bit private RSA's in 0.59s
>> Doing 1024 bit public rsa's for 10s: 28838 1024 bit public RSA's in 0.97s
>> Doing 2048 bit private rsa's for 10s: 4153 2048 bit private RSA's in 0.19s
>> Doing 2048 bit public rsa's for 10s: 12484 2048 bit public RSA's in 0.44s
>> Doing 4096 bit private rsa's for 10s: 14 4096 bit private RSA's in 10.03s
>> Doing 4096 bit public rsa's for 10s: 542 4096 bit public RSA's in 9.99s
>> OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes for: CVE-2005-2969
>> CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 CVE-2006-4343
>> CVE-2007-5135 CVE-2007-3108 CVE-2008-5077 CVE-2009-0590 CVE-2009-3555)
>> built on: date not available
>> options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) aes(partial)
>> blowfish(ptr)
>> compiler: information not available
>> available timing options: TIMES TIMEB HZ=100 [sysconf value]
>> timing function used: times
>>                   sign    verify    sign/s verify/s
>> rsa  512 bits   0.0000s   0.0000s  26371.8  30565.1
>> rsa 1024 bits   0.0000s   0.0000s  24800.0  29729.9
>> rsa 2048 bits   0.0000s   0.0000s  21857.9  28372.7
>> rsa 4096 bits   0.7164s   0.0184s      1.4     54.3
>>
>>
>>
>>
>>
>> Le 22/01/2012 20:14, Yann Rouillard a ?crit :
>>>
>>> I updated the openssl packages set so it follows the library package
>>> naming and the /etc/opt/csw/ configuration directory standards.
>>>
>>> I would welcome additionnal testing of the package before releasing them
>>> to the unstable repository.
>>>
>>> They are available in my experimental repository:
>>> http://buildfarm.opencsw.org/experimental.html#yann
>>>
>>> Thanks in advance for any feedback,
>>>
>>> Yann
>>> _______________________________________________
>>> maintainers mailing list
>>> maintainers at lists.opencsw.org
>>> https://lists.opencsw.org/mailman/listinfo/maintainers
>>> .:: This mailing list's archive is public. ::.
>>
>> _______________________________________________
>> maintainers mailing list
>> maintainers at lists.opencsw.org
>> https://lists.opencsw.org/mailman/listinfo/maintainers
>> .:: This mailing list's archive is public. ::.
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.


From yann at pleiades.fr.eu.org  Sun Jan 22 23:18:34 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Sun, 22 Jan 2012 23:18:34 +0100
Subject: [csw-maintainers] New openssl packages
In-Reply-To: <1327267249-sup-6295@pinkfloyd.chass.utoronto.ca>
References: <4F1C600B.4090107@pleiades.fr.eu.org>
	<1327267249-sup-6295@pinkfloyd.chass.utoronto.ca>
Message-ID: <4F1C8B3A.3000104@pleiades.fr.eu.org>

Hi Ben,

The sparc packages are now in the experimental repository.

Yann

Le 22/01/2012 22:22, Ben Walton a ?crit :
> Excerpts from Yann Rouillard's message of Sun Jan 22 14:14:19 -0500 2012:
>
> Hi Yann,
>
>> I updated the openssl packages set so it follows the library package
>> naming and the /etc/opt/csw/ configuration directory standards.
> Did you intend to place sparc packages for testing too or i386 only?
>
> Thanks for doing this library split!
>
> Thanks
> -Ben
> --
> Ben Walton
> Systems Programmer - CHASS
> University of Toronto
> C:416.407.5610 | W:416.978.4302
>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.


From bwalton at opencsw.org  Mon Jan 23 01:52:59 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 22 Jan 2012 19:52:59 -0500
Subject: [csw-maintainers] New openssl packages
In-Reply-To: <4F1C8B3A.3000104@pleiades.fr.eu.org>
References: <4F1C600B.4090107@pleiades.fr.eu.org>
	<1327267249-sup-6295@pinkfloyd.chass.utoronto.ca>
	<4F1C8B3A.3000104@pleiades.fr.eu.org>
Message-ID: <1327279871-sup-6623@pinkfloyd.chass.utoronto.ca>

Excerpts from Yann Rouillard's message of Sun Jan 22 17:18:34 -0500 2012:

Hi Yann,

> The sparc packages are now in the experimental repository.

Superficial testing here looks good!

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From skayser at opencsw.org  Mon Jan 23 05:41:13 2012
From: skayser at opencsw.org (Sebastian Kayser)
Date: Mon, 23 Jan 2012 05:41:13 +0100
Subject: [csw-maintainers] Location of pgp key
In-Reply-To: <1327259181-sup-1355@pinkfloyd.chass.utoronto.ca>
References: <8C6C4E70-986F-4F0C-875F-8CA9380F53E7@opencsw.org>
	<1327242308-sup-5141@pinkfloyd.chass.utoronto.ca>
	<20120122151746.GD19520@sebastiankayser.de>
	<1327259181-sup-1355@pinkfloyd.chass.utoronto.ca>
Message-ID: <20120123044113.GE19520@sebastiankayser.de>

* Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Sebastian Kayser's message of Sun Jan 22 10:17:46 -0500 2012:
> 
> > This catches /security and Worpress then seems to do prefix based
> > matching on the news articles. I've now excluded /security via
> > another RewriteCond, so Dago, you should be good to go.
> 
> Ok, so if it is just some wordpress magic, presumably we could just
> define a page with that url and not alter the rewrites at all?

Yup (as long as it's a URL that's handled by Wordpress).

Sebastian

From jesse at opencsw.org  Mon Jan 23 14:51:26 2012
From: jesse at opencsw.org (Jesse Reynolds)
Date: Tue, 24 Jan 2012 00:21:26 +1030
Subject: [csw-maintainers] package request page broken
Message-ID: <CAHiP+x9m2FiMQL23XCPbSoRNhsdekzUqDrSQ6kK_MrDyG6hFHA@mail.gmail.com>

I've just tried to use the /requestPackage/ page on the opencsw.org website
and unfortunately the Send button doesn't work, so you can't submit the
form.

Also, when you click into a field, I'm assuming that it's suppose to
automatically select-all, so you don't have to manually select-all and
delete the values that are in there by default?

Not sure who would look at this.

This is happening on Chrome and Firefox on my mac. It works on Safari.

Cheers
Jesse
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120124/c1c27128/attachment.html>

From dam at opencsw.org  Mon Jan 23 15:16:17 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 23 Jan 2012 15:16:17 +0100
Subject: [csw-maintainers] Important GAR change regarding BUILD64
Message-ID: <C8F69F94-A546-45AD-BF33-DDD461A84E77@opencsw.org>

Fellow maintainers,

to get a more consistent naming of variables I have adjusted the meaning of BUILD64
to be more intutitive (hopefully for the last time!):

Prior to r14023 it meant "also build 64 bit and put binaries in the package with
automatic isaexec, unless NOISAEXEC = 1 is given".

Starting from r14023 it meant "also build 64 bit, but do not use ISAEXEC and put
only libraries in the package. Add ISAEXEC = 1 if you want isaexec, and
EXTRA_MERGE_DIRS_isa-extra = $(bindir) if you want 64 bit binaries in your package".

With the current commit r16894 it means "build 64 bit binaries and libraries and
put them in the package. Put only 64 bit libraries in the package if
BUILD64_LIBS_ONLY = 1 is given. Use isaexec only if ISAEXEC = 1 is given.".

You can browse the whole commit here:
  http://sourceforge.net/apps/trac/gar/changeset/16894

In addition to the necessary GAR change I updated the Makefiles in pkg/*/trunk and
pkg/*/*/trunk to adjust for the new meaning with the following rules:

1. If BUILD64 = 1 was in the Makefile *without* ISAEXEC and MERGE_DIRS then replace it
   with BUILD64_LIBS_ONLY.

2. If BUILD64 = 1 was in the Makefile *with* MERGE_DIRS set to $(libdir) replace it
   with BUILD64_LIBS_ONLY and remove MERGE_DIRS.

3. If BUILD64 = 1 was in the Makefile *with* MERGE_DIRS adding $(bindir) or ISAEXEC = 1
   leave the Makefile as is. If there is just the default modulation MERGE_DIRS can
   be removed.

I have tested some recipes but due to the large number (> 300) I cannot verify every
single build. Please have an extra eye if you rebuild or update a package that has
64 bit enabled and drop a note if you see anything strange.


Best regards

  -- Dago


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


From dam at opencsw.org  Tue Jan 24 15:48:45 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 24 Jan 2012 15:48:45 +0100
Subject: [csw-maintainers] Fooling around with dependencies
Message-ID: <CB3A41FE-1A8E-4C1E-8C14-206F8B48BCC9@opencsw.org>

Hi folks,

I have been playing around with dependencies and hacked up a tiny cgi with
Sebastians deptree to dot converter. You can invoke it with
  http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=<pkg>

Here are some examples:
  http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=vim
  http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=xmlstarlet
  http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=libneon27
  http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=openldap

I would like to integrate this somewhere on the package information page.


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 bonivart at opencsw.org  Tue Jan 24 15:59:01 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Tue, 24 Jan 2012 15:59:01 +0100
Subject: [csw-maintainers] Fooling around with dependencies
In-Reply-To: <CB3A41FE-1A8E-4C1E-8C14-206F8B48BCC9@opencsw.org>
References: <CB3A41FE-1A8E-4C1E-8C14-206F8B48BCC9@opencsw.org>
Message-ID: <CABY0g1UYXNwjWcbfiQNPsWWXPxXgu_GE6mxiArh9EFdpA6KHqA@mail.gmail.com>

On Tue, Jan 24, 2012 at 3:48 PM, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi folks,
>
> I have been playing around with dependencies and hacked up a tiny cgi with
> Sebastians deptree to dot converter. You can invoke it with
> ?http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=<pkg>
>
> Here are some examples:
> ?http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=vim
> ?http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=xmlstarlet
> ?http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=libneon27
> ?http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=openldap
>
> I would like to integrate this somewhere on the package information page.

Very cool!?I agree that this should be made accessible to our users.

/peter

From ellson at opencsw.org  Tue Jan 24 16:10:36 2012
From: ellson at opencsw.org (John Ellson)
Date: Tue, 24 Jan 2012 10:10:36 -0500
Subject: [csw-maintainers] Fooling around with dependencies
In-Reply-To: <CB3A41FE-1A8E-4C1E-8C14-206F8B48BCC9@opencsw.org>
References: <CB3A41FE-1A8E-4C1E-8C14-206F8B48BCC9@opencsw.org>
Message-ID: <4F1EC9EC.2010003@opencsw.org>

On 01/24/2012 09:48 AM, Dagobert Michelsen wrote:
> Hi folks,
>
> I have been playing around with dependencies and hacked up a tiny cgi with
> Sebastians deptree to dot converter. You can invoke it with
>    http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=<pkg>
>
> Here are some examples:
>    http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=vim
>    http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=xmlstarlet
>    http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=libneon27
>    http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=openldap
>
> I would like to integrate this somewhere on the package information page.
>
>
> Best regards
>
>    -- Dago
>

Dago,

Ouch!

	http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=graphviz


You might want to produce -Tsvgz images instead of bitmaps, to reduce 
image size.

You could also consider running through "tred" to eliminate (or perhaps 
to highlight) the redundant transitive dependencies.

John



From pfelecan at opencsw.org  Tue Jan 24 17:09:18 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 24 Jan 2012 17:09:18 +0100
Subject: [csw-maintainers] more and more spam
Message-ID: <x6ipk1hykx.fsf@opencsw.org>

Since last week I receive a lot of spam originating from our web server
with a sender of the "form capital at ocswchbiesv01.opencsw.org" and a
subject such as "OpenCSW question about package opensp_doc".. Looking in
the envelope, the route starts from "webservd at localhost" to
"www.opencsw.org" to "bender.opencsw.org" &c. I can provide a sample to
whomever interested by finding a solution to this.
-- 
Peter

From dam at opencsw.org  Tue Jan 24 21:24:39 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 24 Jan 2012 21:24:39 +0100
Subject: [csw-maintainers] Fooling around with dependencies
In-Reply-To: <4F1EC9EC.2010003@opencsw.org>
References: <CB3A41FE-1A8E-4C1E-8C14-206F8B48BCC9@opencsw.org>
	<4F1EC9EC.2010003@opencsw.org>
Message-ID: <6F7BC8F4-F99B-40E1-8022-0F977F8E2B2E@opencsw.org>

Hi John,

Am 24.01.2012 um 16:10 schrieb John Ellson:
> On 01/24/2012 09:48 AM, Dagobert Michelsen wrote:
>> I have been playing around with dependencies and hacked up a tiny cgi with
>> Sebastians deptree to dot converter. You can invoke it with
>>   http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=<pkg>
>> 
>> Here are some examples:
>>   http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=vim
>>   http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=xmlstarlet
>>   http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=libneon27
>>   http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=openldap
>> 
>> I would like to integrate this somewhere on the package information page.
> 
> Ouch!
> 
> 	http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=graphviz

Some stripping possible in the hay :-)

> You might want to produce -Tsvgz images instead of bitmaps, to reduce image size.

I used svg for now as I need more fiddling with the compression encoding.

> You could also consider running through "tred" to eliminate (or perhaps to highlight) the redundant transitive dependencies.

For now I would like to leave the edges in as they are the real depencies in the package.
I see it as diagnostic tool for maintainers, later on for endusers this may be a good thing,
though.

PS: Want to give graphviz64 a try? We should have now all of the dependencies.


Best regards

  -- Dago

From bwalton at opencsw.org  Wed Jan 25 03:38:47 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 24 Jan 2012 21:38:47 -0500
Subject: [csw-maintainers] more and more spam
In-Reply-To: <x6ipk1hykx.fsf@opencsw.org>
References: <x6ipk1hykx.fsf@opencsw.org>
Message-ID: <1327459038-sup-7107@pinkfloyd.chass.utoronto.ca>

Excerpts from Peter FELECAN's message of Tue Jan 24 11:09:18 -0500 2012:

Hi Peter,

> Since last week I receive a lot of spam originating from our web
> server with a sender of the "form capital at ocswchbiesv01.opencsw.org"
> and a subject such as "OpenCSW question about package
> opensp_doc".. Looking in the envelope, the route starts from
> "webservd at localhost" to "www.opencsw.org" to "bender.opencsw.org"
> &c. I can provide a sample to whomever interested by finding a
> solution to this.

I get this junk too, although not often...it's quite sporadic for me,
really.  I think we should add a (re)captcha to the question
submission page as that would stop most of this bot-submitted junk in
its tracks.

We have that on another of our form pages already so integration
shouldn't be too bad.

Thoughts?

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From raos at opencsw.org  Wed Jan 25 07:39:19 2012
From: raos at opencsw.org (Rafael Ostertag)
Date: Wed, 25 Jan 2012 07:39:19 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <4F1A9ADA.3020900@pleiades.fr.eu.org>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
	<4F1A9ADA.3020900@pleiades.fr.eu.org>
Message-ID: <20120125063919.GY19279@bender.opencsw.org>

Hi Yann

On Sat, Jan 21, 2012 at 12:00:42PM +0100, Yann Rouillard wrote:
> Le 16/01/2012 10:33, Maciej (Matchek) Blizi??ski a ??crit :
> >Looks like we need to rebuild Cyrus imapd together with sasl. I looked
> >at the current situation and found this:
> >
> >- the unstable catalog contains version 2.3.16
> >   http://mirror.opencsw.org/opencsw/unstable/i386/5.10/catalog
> >- the website declares it's at 2.4.6
> >   http://www.opencsw.org/packages/cyrus_imapd/
> >- the build recipe is at 2.4.10
> >   https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/cyrus_imapd/trunk/Makefile
> >- the newest upstream version is 2.4.13
> >   ftp://ftp.cyrusimap.org/cyrus-imapd/
> >
> >I don't know how we got into this state, but in a perfect world at
> >least the first three should match.
> >
> >Yann, can you tell what's the current situation with this package?
> >What are the main challenges in getting a new version release
> 
> Hi Maciej,
> 
> The blocker is the migration path, upgrade from 2.3 to 2.4 triggers
> a bug when berkeley is used.
> 
> I opened a bug upstream but the developper didn't have the time to
> work on it
> https://bugzilla.cyrusimap.org/show_bug.cgi?id=3496
> 

I tested the new cyrus package with the config attached to the above mentioned
bug report, and it does not seem to exhibit the behavior described anymore.

However, I hit another bug/error during testing. After upgrading from 2.3 to
2.4 it might happen that ctl_cyrusdb dies:

Jan 22 10:42:41 cswtest master[7103]: [ID 965400 local6.notice] process started
Jan 22 10:42:41 cswtest master[7108]: [ID 392559 local6.debug] about to exec /opt/csw/sbin/ctl_cyrusdb
Jan 22 10:42:41 cswtest ctl_cyrusdb[7108]: [ID 866726 local6.warning] DBERROR db4: Program version 4.8 doesn't match environment version 4333.0
Jan 22 10:42:45 cswtest genunix: [ID 603404 kern.notice] NOTICE: core_log: ctl_cyrusdb[7108] core dumped: /var/cores/core.ctl_cyrusdb.7108

This error is reproducible (at least for me on Sol10x): first, send a few
hundred mails to cyrus 2.3, then upgrade to 2.4.

By using the db_recover utility, I was able to salvage the database and cyrus
started normally. 

Depending on the database configuration in imapd.conf, one has to either use
db_recover from bdb 4.2 or 4.8:

BDB -> Skiplist: db_recover 4.8
BDB -> BDB: db_recover 4.2

To use db_recover, issue:

 su - cyrus
 cd <imapconfigdir>
 /opt/csw/bdb(42|48)/bin/db_recover -h db


cheers
rafi

From maciej at opencsw.org  Wed Jan 25 08:49:01 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Wed, 25 Jan 2012 07:49:01 +0000
Subject: [csw-maintainers] Fooling around with dependencies
In-Reply-To: <6F7BC8F4-F99B-40E1-8022-0F977F8E2B2E@opencsw.org>
References: <CB3A41FE-1A8E-4C1E-8C14-206F8B48BCC9@opencsw.org>
	<4F1EC9EC.2010003@opencsw.org>
	<6F7BC8F4-F99B-40E1-8022-0F977F8E2B2E@opencsw.org>
Message-ID: <CALtRa-7kA1QTLSQQmU-ksRa42qsRXqAvErF75Y807pnDKauUSA@mail.gmail.com>

A feature suggestion: add node coloring when the catalog name ends with
_stub.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120125/c73bbfab/attachment.html>

From pfelecan at opencsw.org  Wed Jan 25 09:46:39 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Wed, 25 Jan 2012 09:46:39 +0100
Subject: [csw-maintainers] Fooling around with dependencies
In-Reply-To: <CALtRa-7kA1QTLSQQmU-ksRa42qsRXqAvErF75Y807pnDKauUSA@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed,
	25 Jan 2012 07:49:01 +0000")
References: <CB3A41FE-1A8E-4C1E-8C14-206F8B48BCC9@opencsw.org>
	<4F1EC9EC.2010003@opencsw.org>
	<6F7BC8F4-F99B-40E1-8022-0F977F8E2B2E@opencsw.org>
	<CALtRa-7kA1QTLSQQmU-ksRa42qsRXqAvErF75Y807pnDKauUSA@mail.gmail.com>
Message-ID: <x6ehuoi2z4.fsf@opencsw.org>

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

> A feature suggestion: add node coloring when the catalog name ends with
> _stub.

Yes, colors! Thank you Maciej, I knew that it was missing something but...
-- 
Peter

From dam at opencsw.org  Wed Jan 25 09:50:26 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 25 Jan 2012 09:50:26 +0100
Subject: [csw-maintainers] Fooling around with dependencies
In-Reply-To: <CALtRa-7kA1QTLSQQmU-ksRa42qsRXqAvErF75Y807pnDKauUSA@mail.gmail.com>
References: <CB3A41FE-1A8E-4C1E-8C14-206F8B48BCC9@opencsw.org>
	<4F1EC9EC.2010003@opencsw.org>
	<6F7BC8F4-F99B-40E1-8022-0F977F8E2B2E@opencsw.org>
	<CALtRa-7kA1QTLSQQmU-ksRa42qsRXqAvErF75Y807pnDKauUSA@mail.gmail.com>
Message-ID: <311E5A41-BBA6-4E93-9883-84AC98679E39@opencsw.org>

Hi Maciej,

Am 25.01.2012 um 08:49 schrieb Maciej (Matchek) Blizi?ski:
> A feature suggestion: add node coloring when the catalog name ends with _stub.

Already on my list :-)

- box nodes belonging to the same bundle
- add size in MB per package
- mark stubs red
- add hyperlinks to the package boxes
- add packageses depending on the one being requested
- limit dependency depth on excessive graphs so there won't be out-of-memory or XCPU


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 Jan 25 10:45:57 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Wed, 25 Jan 2012 10:45:57 +0100
Subject: [csw-maintainers] Fooling around with dependencies
In-Reply-To: <311E5A41-BBA6-4E93-9883-84AC98679E39@opencsw.org> (Dagobert
	Michelsen's message of "Wed, 25 Jan 2012 09:50:26 +0100")
References: <CB3A41FE-1A8E-4C1E-8C14-206F8B48BCC9@opencsw.org>
	<4F1EC9EC.2010003@opencsw.org>
	<6F7BC8F4-F99B-40E1-8022-0F977F8E2B2E@opencsw.org>
	<CALtRa-7kA1QTLSQQmU-ksRa42qsRXqAvErF75Y807pnDKauUSA@mail.gmail.com>
	<311E5A41-BBA6-4E93-9883-84AC98679E39@opencsw.org>
Message-ID: <x662g0i08a.fsf@opencsw.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> - limit dependency depth on excessive graphs so there won't be
> out-of-memory or XCPU

Offer a hierarchical view, i.e. when there is a "rich" node, such as for
Emacs using GTK, which has a lot of dependencies, use a specific node
shape on which the user can click to expand and/or navigate; this is
related to what you call "bundles" management.
-- 
Peter

From dam at opencsw.org  Wed Jan 25 15:32:21 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 25 Jan 2012 15:32:21 +0100
Subject: [csw-maintainers] Add bundle to catalog or get catalog via REST?
Message-ID: <2F1DFFA2-14CE-4B9D-A994-B8DE6307B30B@opencsw.org>

Hi folks,

I would like to add bundle information to the package graph. What do you think about
adding it to the catalog or alternatively to the database so I can retreive it via REST.


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 Jan 25 16:54:07 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Wed, 25 Jan 2012 16:54:07 +0100
Subject: [csw-maintainers] Add bundle to catalog or get catalog via REST?
In-Reply-To: <2F1DFFA2-14CE-4B9D-A994-B8DE6307B30B@opencsw.org> (Dagobert
	Michelsen's message of "Wed, 25 Jan 2012 15:32:21 +0100")
References: <2F1DFFA2-14CE-4B9D-A994-B8DE6307B30B@opencsw.org>
Message-ID: <x61uqnixr4.fsf@opencsw.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> I would like to add bundle information to the package graph. What do you think about
> adding it to the catalog or alternatively to the database so I can retreive it via REST.

IMHO, it should be added to the database and, as a consequence, when the
catalog is built is can be added to it. Thus, you can obtain it both
ways.

-- 
Peter

From dam at opencsw.org  Thu Jan 26 16:17:55 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 26 Jan 2012 16:17:55 +0100
Subject: [csw-maintainers] Making GARVERSION explicit
Message-ID: <189F47AE-522A-4D7E-B0A7-0A1F9C321D3B@opencsw.org>

Fellow maintainers,

I have updated all GAR Makefiles to make the used GAR version explicit with
  GARTYPE = v2
in r16916:
  http://sourceforge.net/apps/trac/gar/changeset/16916
I plan to make some things in GAR cleaner which will require adjustments in the Makefiles.
Fixating the GARTYPE ensures existing Makefiles stay with a clean build environment.


Sorry for the inconvenience and best regards

  -- Dago

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


From maciej at opencsw.org  Thu Jan 26 16:59:37 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Thu, 26 Jan 2012 15:59:37 +0000
Subject: [csw-maintainers] Rewiring dependencies
Message-ID: <CALtRa-4CPQvA6DA8+63cRkV1BGc=GmBpBF0-=7MGhBW+KZVc4w@mail.gmail.com>

When I look at our dependency graphs (thanks, Dago!), I see that we
have a lot of dependency rewiring to do.

http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=cups

But the process itself is quite tedious: you need to rebuild the
package, let checkpkg run, then see the list of surplus-dependency
errors (for old packages) and dependency-missing. Then you need to
read through that, hunt down all the relevant lines in the Makefile,
correct them, run mgar repackage, rinse, repeat.

We already have machinery capable of figuring out which binary will
link against which. What if we made GAR call out to a utility which
would detect dependencies caused by shared libraries, and
automatically add them?

Maciej

From dam at opencsw.org  Thu Jan 26 17:44:31 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 26 Jan 2012 17:44:31 +0100
Subject: [csw-maintainers] Rewiring dependencies
In-Reply-To: <CALtRa-4CPQvA6DA8+63cRkV1BGc=GmBpBF0-=7MGhBW+KZVc4w@mail.gmail.com>
References: <CALtRa-4CPQvA6DA8+63cRkV1BGc=GmBpBF0-=7MGhBW+KZVc4w@mail.gmail.com>
Message-ID: <8486BA22-0FB7-4B01-8662-7EC58A570B1B@opencsw.org>

Hi Maciej,

Am 26.01.2012 um 16:59 schrieb Maciej (Matchek) Blizi?ski:
> When I look at our dependency graphs (thanks, Dago!), I see that we
> have a lot of dependency rewiring to do.
> 
> http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=cups
> 
> But the process itself is quite tedious: you need to rebuild the
> package, let checkpkg run, then see the list of surplus-dependency
> errors (for old packages) and dependency-missing. Then you need to
> read through that, hunt down all the relevant lines in the Makefile,
> correct them, run mgar repackage, rinse, repeat.
> 
> We already have machinery capable of figuring out which binary will
> link against which. What if we made GAR call out to a utility which
> would detect dependencies caused by shared libraries, and
> automatically add them?

As we are facing massive rebuild times not only due to dependency updates
but also Solaris 11 I have some more radical ideas:

1. Isolated build environment

Now that Solaris 9 is gone we can clone fresh build zones and verify sufficient
setting of BUILD_DEPS.

2. Activate buildbot again

Compile in the background for dozens of auto-modified packages to see if it worked.

3. Enhanced package hierarchy

Add one more directory catalog/ in a package directory besides branches/, tags/ and trunk/
which contains a subdirectory for each catalog a package is in. This ensures easy
bugfixing in named catalogs and use auto-build packages for propagation in the catalog.

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


From pfelecan at opencsw.org  Thu Jan 26 17:57:33 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Thu, 26 Jan 2012 17:57:33 +0100
Subject: [csw-maintainers] Rewiring dependencies
In-Reply-To: <8486BA22-0FB7-4B01-8662-7EC58A570B1B@opencsw.org> (Dagobert
	Michelsen's message of "Thu, 26 Jan 2012 17:44:31 +0100")
References: <CALtRa-4CPQvA6DA8+63cRkV1BGc=GmBpBF0-=7MGhBW+KZVc4w@mail.gmail.com>
	<8486BA22-0FB7-4B01-8662-7EC58A570B1B@opencsw.org>
Message-ID: <x6obtqh05e.fsf@opencsw.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> As we are facing massive rebuild times not only due to dependency updates
> but also Solaris 11 I have some more radical ideas:

Solaris 11 ?

> 2. Activate buildbot again

Does it work ?

> 3. Enhanced package hierarchy
>
> Add one more directory catalog/ in a package directory besides branches/, tags/ and trunk/
> which contains a subdirectory for each catalog a package is in. This ensures easy
> bugfixing in named catalogs and use auto-build packages for propagation in the catalog.

Cannot be tag == catalog ?

-- 
Peter

From gadavis at opencsw.org  Thu Jan 26 19:27:36 2012
From: gadavis at opencsw.org (Geoff Davis)
Date: Thu, 26 Jan 2012 10:27:36 -0800
Subject: [csw-maintainers] New openssl packages
In-Reply-To: <4F1C63F4.50309@pleiades.fr.eu.org>
References: <4F1C600B.4090107@pleiades.fr.eu.org>
	<4F1C63F4.50309@pleiades.fr.eu.org>
Message-ID: <4F219B18.5090701@opencsw.org>

On 1/22/12 11:31 AM, Yann Rouillard wrote:
> Hi again,
>
> For those interested in some ssl speed up, there is an experimental 
> openssl 0.9.8 build with pkcs11 support available in my build 
> directory (/home/yann/build/ on the buildfarm).
> It allows opencsw openssl to take advantage of crypto-hardware 
> acceleration available on some sun servers, Ultrasparc T2 for example.
> --snip--
Awesome, I'm glad you figured out a way to take those old patches and 
put them into this newer build. I've got some T5220s that would be a 
heck of a lot more usable with this hardware-accelerated OpenSSL.

From dam at opencsw.org  Thu Jan 26 19:43:49 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 26 Jan 2012 19:43:49 +0100
Subject: [csw-maintainers] Rewiring dependencies
In-Reply-To: <x6obtqh05e.fsf@opencsw.org>
References: <CALtRa-4CPQvA6DA8+63cRkV1BGc=GmBpBF0-=7MGhBW+KZVc4w@mail.gmail.com>
	<8486BA22-0FB7-4B01-8662-7EC58A570B1B@opencsw.org>
	<x6obtqh05e.fsf@opencsw.org>
Message-ID: <9C0F3282-2D23-48A2-B518-5B5E66BE604D@opencsw.org>

Hi Peter,

Am 26.01.2012 um 17:57 schrieb Peter FELECAN:
> Dagobert Michelsen <dam at opencsw.org> writes:
>> As we are facing massive rebuild times not only due to dependency updates
>> but also Solaris 11 I have some more radical ideas:
> 
> Solaris 11 ?

Yes. An IPS backend is in the works. unstable11s and unstable11x are
already available and bootstrapped with OpenCSW SysV-packages.
It is possible to produce SysV-packages on Solaris 11 too with GAR.

>> 2. Activate buildbot again
> 
> Does it work ?

It did work in the past and asynchronously running lots of builds
with automatic bumping could save a lot of work.

>> 3. Enhanced package hierarchy
>> 
>> Add one more directory catalog/ in a package directory besides branches/, tags/ and trunk/
>> which contains a subdirectory for each catalog a package is in. This ensures easy
>> bugfixing in named catalogs and use auto-build packages for propagation in the catalog.
> 
> Cannot be tag == catalog ?

A tag is for me something immutable (at least logically), but we could also
add it to branches. Having a separate directory makes it IMHO more clear as it
is not "just a branch" and another dir on this level won't hurt.


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 Jan 26 19:47:21 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 26 Jan 2012 19:47:21 +0100
Subject: [csw-maintainers] Where does "category" come from?
In-Reply-To: <CALtRa-5UhfWbfNDZ91VmNLy9PcSMO49HXcsg_7ZO1eDivTu4GA@mail.gmail.com>
References: <ACC07856-A3CF-4815-A9C4-492A05E7E285@opencsw.org>
	<CALtRa-5UhfWbfNDZ91VmNLy9PcSMO49HXcsg_7ZO1eDivTu4GA@mail.gmail.com>
Message-ID: <2A513B36-F915-49CE-BA24-9F31989DE2B3@opencsw.org>

Hi Maciej,

Am 26.01.2012 um 18:35 schrieb Maciej (Matchek) Blizi?ski:
> 2012/1/26 Dagobert Michelsen <dam at opencsw.org>:
>> I noticed the catalog contains "category" as the last field like this:
>> 
>> xtideh 07.12.28,REV=2008.02.05 CSWxtideh xtideh-07.12.28,REV=2008.02.05-SunOS5.8-all-CSW.pkg.gz 0aa9756ab43d8219b8c0c54a21e5a7dc 741164 CSWcommon eng|fun|lib
>> xtidew 1.0,REV=2008.02.05 CSWxtidew xtidew-1.0,REV=2008.02.05-SunOS5.8-all-CSW.pkg.gz e37e60cbd79c8117a8a1e475f4cd5bb0 41699951 CSWcommon eng|fun|lib
>> 
>> I figure that it must be in CatalogDetail:
>> 
>> ./lib/web/pkgdb_web.py:  r'/catalogs/([\w-]+)-(sparc|i386)-(SunOS[^-]+)/', 'CatalogDetail',
>> ./lib/web/pkgdb_web.py:class CatalogDetail(object):
>> ./lib/web/pkgdb_web.py:    return render.CatalogDetail(cat_name, pkgs)
>> 
>> However, I can't find "render", just "render_response". So, where is that field stored in the database?
> 
> Catalogs files (indexes) are not generated from the database, they are
> generated straight from the packages, using bldcat, that's where the
> answer must be.

I see. It is generated from CSW_CATEGORY from pkginfo within the package:
  http://sourceforge.net/apps/trac/pkgutil/browser/trunk/bldcat#L238

However, I can't remember what is was used for. The discussions were from 2007 and
April 2008 before OpenCSW and are hence not in the mail archive. Maybe someone
can shed some light into this, probably Peter as he implemented it :-)

I have now tested a script which generates a full catalog (with the exception
of the category of course) completely from the database via REST and got the
following runtimes (with bundle :-)
  ./getcatalog  3868.28s user 5.09s system 76% cpu 1:24:26.68 total

The URLs used were
  http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/sparc/SunOS5.10/
  http://buildfarm.opencsw.org/pkgdb/rest/srv4/${md5}/pkg-stats/
It seems to me that the JSON encoding/decoding takes a lot of time.


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 bonivart at opencsw.org  Thu Jan 26 20:03:07 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Thu, 26 Jan 2012 20:03:07 +0100
Subject: [csw-maintainers] Where does "category" come from?
In-Reply-To: <2A513B36-F915-49CE-BA24-9F31989DE2B3@opencsw.org>
References: <ACC07856-A3CF-4815-A9C4-492A05E7E285@opencsw.org>
	<CALtRa-5UhfWbfNDZ91VmNLy9PcSMO49HXcsg_7ZO1eDivTu4GA@mail.gmail.com>
	<2A513B36-F915-49CE-BA24-9F31989DE2B3@opencsw.org>
Message-ID: <CABY0g1XqD6W1C=jecO7wRESgPheBSJy=3uQPWv6q0eUxr4x-Ag@mail.gmail.com>

On Thu, Jan 26, 2012 at 7:47 PM, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Maciej,
>
> Am 26.01.2012 um 18:35 schrieb Maciej (Matchek) Blizi?ski:
>> 2012/1/26 Dagobert Michelsen <dam at opencsw.org>:
>>> I noticed the catalog contains "category" as the last field like this:
>>>
>>> xtideh 07.12.28,REV=2008.02.05 CSWxtideh xtideh-07.12.28,REV=2008.02.05-SunOS5.8-all-CSW.pkg.gz 0aa9756ab43d8219b8c0c54a21e5a7dc 741164 CSWcommon eng|fun|lib

Note that the above is not a full catalog line, it should have I-deps
(or "none") as 9th field. I fought with Phil for two years to get that
included so don't you forget it! ;)

> I see. It is generated from CSW_CATEGORY from pkginfo within the package:
> ?http://sourceforge.net/apps/trac/pkgutil/browser/trunk/bldcat#L238
>
> However, I can't remember what is was used for. The discussions were from 2007 and
> April 2008 before OpenCSW and are hence not in the mail archive. Maybe someone
> can shed some light into this, probably Peter as he implemented it :-)

I think this has been in Phil's catalogs for a long time, it sure was
when I first made bldcat even though I think I just put in "none" at
first. I remember from Phil's old maintainer docs that these
categories were documented and I suppose the GAR categories are the
same.

Maybe Phil had some kind of group/bundle idea, that you should be able
to install all "fun" stuff with one command but it never got
implemented. It would be one way of implementing a simple install of
AMP for example even though it's much easier to make a package called
CSWamp just depending on what's needed. Phil didn't like empty
packages though. But Phil's gone now.

/peter

From dam at opencsw.org  Thu Jan 26 20:37:16 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 26 Jan 2012 20:37:16 +0100
Subject: [csw-maintainers] Where does "category" come from?
In-Reply-To: <CABY0g1XqD6W1C=jecO7wRESgPheBSJy=3uQPWv6q0eUxr4x-Ag@mail.gmail.com>
References: <ACC07856-A3CF-4815-A9C4-492A05E7E285@opencsw.org>
	<CALtRa-5UhfWbfNDZ91VmNLy9PcSMO49HXcsg_7ZO1eDivTu4GA@mail.gmail.com>
	<2A513B36-F915-49CE-BA24-9F31989DE2B3@opencsw.org>
	<CABY0g1XqD6W1C=jecO7wRESgPheBSJy=3uQPWv6q0eUxr4x-Ag@mail.gmail.com>
Message-ID: <EA7F08C3-15B4-4E10-9290-B232CF00B1D8@opencsw.org>

Hi Peter,

Am 26.01.2012 um 20:03 schrieb Peter Bonivart:
> On Thu, Jan 26, 2012 at 7:47 PM, Dagobert Michelsen <dam at opencsw.org> wrote:
>> Am 26.01.2012 um 18:35 schrieb Maciej (Matchek) Blizi?ski:
>>> 2012/1/26 Dagobert Michelsen <dam at opencsw.org>:
>>>> I noticed the catalog contains "category" as the last field like this:
>>>> 
>>>> xtideh 07.12.28,REV=2008.02.05 CSWxtideh xtideh-07.12.28,REV=2008.02.05-SunOS5.8-all-CSW.pkg.gz 0aa9756ab43d8219b8c0c54a21e5a7dc 741164 CSWcommon eng|fun|lib
> 
> Note that the above is not a full catalog line, it should have I-deps
> (or "none") as 9th field. I fought with Phil for two years to get that
> included so don't you forget it! ;)

Ahh, yes, of course not ;)

>> I see. It is generated from CSW_CATEGORY from pkginfo within the package:
>>  http://sourceforge.net/apps/trac/pkgutil/browser/trunk/bldcat#L238
>> 
>> However, I can't remember what is was used for. The discussions were from 2007 and
>> April 2008 before OpenCSW and are hence not in the mail archive. Maybe someone
>> can shed some light into this, probably Peter as he implemented it :-)
> 
> I think this has been in Phil's catalogs for a long time, it sure was
> when I first made bldcat even though I think I just put in "none" at
> first. I remember from Phil's old maintainer docs that these
> categories were documented and I suppose the GAR categories are the
> same.

The GAR categories are another area that needs reworking. It is more like a
build recipe type. Currently there are several categories which map to the
same recipe and I would to clean that up some time.

> Maybe Phil had some kind of group/bundle idea, that you should be able
> to install all "fun" stuff with one command but it never got
> implemented. It would be one way of implementing a simple install of
> AMP for example even though it's much easier to make a package called
> CSWamp just depending on what's needed. Phil didn't like empty
> packages though. But Phil's gone now.

I suggest using the field for something called "Facets" in IPS: It
specifies e.g. that it is a devel package or a locale-de package
which gets automatically installed if you enable that facet in pkgutil.conf
when anything from the bundle is installed. Ok, one more reason to have
the bundle in the catalog :-)


Best regards

  -- Dago

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


From maciej at opencsw.org  Sat Jan 28 12:08:44 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sat, 28 Jan 2012 11:08:44 +0000
Subject: [csw-maintainers] OpenCSW @ serverfault.com
Message-ID: <CALtRa-4R_nY+Z4EcYY8YCo0zt5OFEs-CLc0z9ci-NNLUXWR46g@mail.gmail.com>

This might be interesting for the Ruby folk around here. I found this
question on serverfault.com today:

"Curl development headers with SSL support for Phusion Passenger 3"

http://serverfault.com/questions/231641/curl-development-headers-with-ssl-support-for-phusion-passenger-3

It's good to see our packages mentioned in howtos on the web. I
remember Passenger mentioned here already, I'm wondering if anybody
was working on a package with it?

Maciej

From yann at pleiades.fr.eu.org  Sat Jan 28 13:12:00 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Sat, 28 Jan 2012 13:12:00 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <20120125063919.GY19279@bender.opencsw.org>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>	<4F1A9ADA.3020900@pleiades.fr.eu.org>
	<20120125063919.GY19279@bender.opencsw.org>
Message-ID: <4F23E610.5060707@pleiades.fr.eu.org>

Hi Rafael,



Le 25/01/2012 07:39, Rafael Ostertag a ?crit :
> I tested the new cyrus package with the config attached to the above 
> mentioned
> bug report, and it does not seem to exhibit the behavior described anymore.
That's good !
I tested again and was able to reproduce it again with cyrus linked with 
Berkeledy db 4.2 (in my repository).
So I suppose berkeleydb 4.8 is better at handling this case.

> However, I hit another bug/error during testing. After upgrading from 2.3 to
> 2.4 it might happen that ctl_cyrusdb dies:
>
> Jan 22 10:42:41 cswtest master[7103]: [ID 965400 local6.notice] process started
> Jan 22 10:42:41 cswtest master[7108]: [ID 392559 local6.debug] about to exec /opt/csw/sbin/ctl_cyrusdb
> Jan 22 10:42:41 cswtest ctl_cyrusdb[7108]: [ID 866726 local6.warning] DBERROR db4: Program version 4.8 doesn't match environment version 4333.0
> Jan 22 10:42:45 cswtest genunix: [ID 603404 kern.notice] NOTICE: core_log: ctl_cyrusdb[7108] core dumped: /var/cores/core.ctl_cyrusdb.7108
>
> This error is reproducible (at least for me on Sol10x): first, send a few
> hundred mails to cyrus 2.3, then upgrade to 2.4.
If it is rerpoducible, we might open a bug upstream.
Can you send the me a tar.gz of the config directory which triggers the 
bug ?

> By using the db_recover utility, I was able to salvage the database and cyrus
> started normally.
>
> Depending on the database configuration in imapd.conf, one has to either use
> db_recover from bdb 4.2 or 4.8:
>
> BDB ->  Skiplist: db_recover 4.8
> BDB ->  BDB: db_recover 4.2

Hmm, the problem is that you might have a user which has both BDB -> BDB 
and BDB -> Skiplist migration.
We might try to always launch db_recover 4.2 then db_recover 4.8, did 
you try to call them both in your tests ?

Yann

From dam at opencsw.org  Mon Jan 30 09:26:20 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 30 Jan 2012 09:26:20 +0100
Subject: [csw-maintainers] RFC: Drop arch-specific packages of pkgutil
	and static from primary mirror
In-Reply-To: <1327090979-sup-4827@pinkfloyd.chass.utoronto.ca>
References: <BEBFA203-498E-463F-9547-730A4990A163@opencsw.org>
	<1327090188-sup-621@pinkfloyd.chass.utoronto.ca>
	<E026F021-F8B9-4455-9D1F-B628E827E096@opencsw.org>
	<1327090979-sup-4827@pinkfloyd.chass.utoronto.ca>
Message-ID: <5A4B72C2-BC7C-4710-BF40-B9494B06DC77@opencsw.org>

Hi,

Am 20.01.2012 um 21:23 schrieb Ben Walton:
> Excerpts from Dagobert Michelsen's message of Fri Jan 20 15:22:19 -0500 2012:
>> Ok. But keep in mind we already removed pkg-get from there without
>> symlinking.
> 
> A fair point.
> 
>>>> 2. Remove static wget binaries completely as a static wget is now
>>>>  also shipped with pkgutil.pkg
>>> 
>>> Again, this might break scripts but I agree in principle.
>> 
>> Why? Do you think they wget the wget?
> 
> Doh!  You're right. :)
> 
>>>> 3. The pkgutil build recipe currently just copies in the static
>>>>  binaries from the sourceforge zip. I suggest building a static
>>>>  wget during the pkgutil build phase. The wget recipe already
>>>>  contains a modulation for a static build.
>>> 
>>> What's the advantage of this approach?
>> 
>> Please see my other mail to Peter.
> 
> Ok.  I'm good with the proposal and if Peter wants to change that wget
> handling done by pkgutil, he knows best. :)

I have now pushed the change by deleting the wgets and the arch-specific pkgutil
versions.


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 Jan 30 09:54:57 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Mon, 30 Jan 2012 08:54:57 +0000
Subject: [csw-maintainers] Wintercamp 2011
In-Reply-To: <4F169E21.2050602@opencsw.org>
References: <CALtRa-6zZV2X=pvUkok58X-djbaX2ezp7_boCu2hWrduEGODng@mail.gmail.com>
	<x6boq1l3me.fsf@opencsw.org> <4F169E21.2050602@opencsw.org>
Message-ID: <CALtRa-58NtXyykDkQK=T-k_k620PiQXzd5A=ML2oUM5KLVS3qQ@mail.gmail.com>

Hello everyone,

Here's the Doodle poll in which you can declare weekends you're
available for the Wintercamp.

http://www.doodle.com/scawm5zdt3x5tvgs

I entered Bratislava as the place; have we reached consensus on the
location? If not, please speak up.

Maciej

From ihsan at opencsw.org  Mon Jan 30 12:29:20 2012
From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=)
Date: Mon, 30 Jan 2012 12:29:20 +0100
Subject: [csw-maintainers] Open "System Engineer" Position at Swisscom
Message-ID: <4F267F10.104@opencsw.org>

Hi,

This is slightly off topic here, but maybe someone is looking for a job.

We, a major Telco in Switzerland, are looking for a system engineer
specialized in Solaris and Messaging (E-Mail).

Details (German only):
https://jobsp.swisscom.com/cui?publicationId=cGd1aWQ9MDQ0QTA1NEZBMUIyRDAwNEUxMDAwMDAwMEE1QzI5MkM%3d&configurationId=Z_VIEWER&sap-client=110

If you're interested, please drop me a mail.




Ihsan

-- 
ihsan at dogan.ch		http://blog.dogan.ch/

From ihsan at opencsw.org  Tue Jan 31 12:23:38 2012
From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=)
Date: Tue, 31 Jan 2012 12:23:38 +0100
Subject: [csw-maintainers] Wintercamp 2011
In-Reply-To: <CALtRa-58NtXyykDkQK=T-k_k620PiQXzd5A=ML2oUM5KLVS3qQ@mail.gmail.com>
References: <CALtRa-6zZV2X=pvUkok58X-djbaX2ezp7_boCu2hWrduEGODng@mail.gmail.com>
	<x6boq1l3me.fsf@opencsw.org> <4F169E21.2050602@opencsw.org>
	<CALtRa-58NtXyykDkQK=T-k_k620PiQXzd5A=ML2oUM5KLVS3qQ@mail.gmail.com>
Message-ID: <4F27CF3A.8090800@opencsw.org>

Hi,

On 01/30/12 09:54 AM, Maciej (Matchek) Blizi?ski wrote:

> Here's the Doodle poll in which you can declare weekends you're
> available for the Wintercamp.
> 
> http://www.doodle.com/scawm5zdt3x5tvgs
> 
> I entered Bratislava as the place; have we reached consensus on the
> location? If not, please speak up.

Hmm, so far not many people are joining.




Ihsan

-- 
ihsan at dogan.ch		http://blog.dogan.ch/

From maciej at opencsw.org  Tue Jan 31 12:57:35 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Tue, 31 Jan 2012 11:57:35 +0000
Subject: [csw-maintainers] The dublin release: remaining tasks
In-Reply-To: <DF613D56-2139-460C-B954-3B304F642562@opencsw.org>
References: <CALtRa-58r7RhZURNVb+ZpH-9O1nHEF4KY1koAO0wJCkMJDpFCQ@mail.gmail.com>
	<20111013090121.GA15669@bender.opencsw.org>
	<CALtRa-7wv53a25rv3+v_ijmzsV6efFk_mh-CJh1kEBPSANctkw@mail.gmail.com>
	<20111013101714.GB15669@bender.opencsw.org>
	<DF613D56-2139-460C-B954-3B304F642562@opencsw.org>
Message-ID: <CALtRa-6DRAyEX0r8S2gtxyiCz1usOmQqa7Dx_1AvoEwrpax=rQ@mail.gmail.com>

Status update:

libjpeg: Done
sasl + cyrus: Done (there are some upgrade issues, I understand that
Rafael and Yann are working on that)
openssl: Done (still using static prototypes, but the library split is done)

openldap: Not done

Is there anything else that people are aware of?

From maciej at opencsw.org  Tue Jan 31 16:26:38 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Tue, 31 Jan 2012 15:26:38 +0000
Subject: [csw-maintainers] Blogger says installation instructions are unclear
Message-ID: <CALtRa-7WJYUEt17Kv8GmB71Q5XwEZvJ3+J-fH=xmWWRcn5pECw@mail.gmail.com>

I found this post today:

http://computersimplified.wordpress.com/2012/01/20/addind-softwares-on-a-click-in-solaris-11/

The poster says:

"Unfortunately the instructions for setting up opencsw is not so clear
on the website."

...and then proceeds to explain how to install:

"Basically you add (...)"

It was posted 11 days ago, so it refers to the current layout of the
website. On the main page, we have the download link. On one hand I
can't see how it can be made simpler. On the other hand, I accept that
the user was looking for these instructions and couldn't find them.
Can we improve the installation instructions (or their
discoverability) in any way?

Maciej

From bonivart at opencsw.org  Tue Jan 31 17:15:18 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Tue, 31 Jan 2012 17:15:18 +0100
Subject: [csw-maintainers] Blogger says installation instructions are
	unclear
In-Reply-To: <CALtRa-7WJYUEt17Kv8GmB71Q5XwEZvJ3+J-fH=xmWWRcn5pECw@mail.gmail.com>
References: <CALtRa-7WJYUEt17Kv8GmB71Q5XwEZvJ3+J-fH=xmWWRcn5pECw@mail.gmail.com>
Message-ID: <CABY0g1X=6cvaBXLd3OXk5CHMEgevsNDhy8s44bcz2dTmT+tYww@mail.gmail.com>

2012/1/31 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
> I found this post today:
>
> http://computersimplified.wordpress.com/2012/01/20/addind-softwares-on-a-click-in-solaris-11/
>
> The poster says:
>
> "Unfortunately the instructions for setting up opencsw is not so clear
> on the website."
>
> ...and then proceeds to explain how to install:
>
> "Basically you add (...)"
>
> It was posted 11 days ago, so it refers to the current layout of the
> website. On the main page, we have the download link. On one hand I
> can't see how it can be made simpler. On the other hand, I accept that
> the user was looking for these instructions and couldn't find them.
> Can we improve the installation instructions (or their
> discoverability) in any way?

I've always thought it was overkill to have both announcements and
news, one should be enough. We could then move the text from "Get
started" right onto the first page in its own box. Most similar sites
have bootstrap info right in your face, we should as well.

/peter

From pfelecan at opencsw.org  Tue Jan 31 20:00:04 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 31 Jan 2012 20:00:04 +0100
Subject: [csw-maintainers] Blogger says installation instructions are
	unclear
In-Reply-To: <CABY0g1X=6cvaBXLd3OXk5CHMEgevsNDhy8s44bcz2dTmT+tYww@mail.gmail.com>
	(Peter Bonivart's message of "Tue, 31 Jan 2012 17:15:18 +0100")
References: <CALtRa-7WJYUEt17Kv8GmB71Q5XwEZvJ3+J-fH=xmWWRcn5pECw@mail.gmail.com>
	<CABY0g1X=6cvaBXLd3OXk5CHMEgevsNDhy8s44bcz2dTmT+tYww@mail.gmail.com>
Message-ID: <x6ehufg0jv.fsf@opencsw.org>

Peter Bonivart <bonivart at opencsw.org> writes:

> I've always thought it was overkill to have both announcements and
> news, one should be enough. We could then move the text from "Get
> started" right onto the first page in its own box. Most similar sites
> have bootstrap info right in your face, we should as well.

Overkill and quite stale. I fully agree with your proposal. BTW, if we
cannot feed correctly the "news" or "announcements" sections it's way
better to remove them altogether.
-- 
Peter

From grzemba at contac-dt.de  Thu Jan  5 14:24:45 2012
From: grzemba at contac-dt.de (Carsten Grzemba)
Date: Thu, 05 Jan 2012 13:24:45 -0000
Subject: [csw-maintainers] Review packages jss4 and ldapjdk
Message-ID: <7490bc19711c.4f05b2a6@contac-dt.de>

Please Review:

opencsw/lang-java/ldapjdk
opencsw/lang-java/jss

and perhaps an preview:

opencsw/lang-java/idm-console-base
opencsw/lang-java/389-console
opencsw/lang-java/389-admin-console

opencsw/lang-java/389-ds-console


--
Carsten Grzemba
Tel.:?? +49 3677 64740
Mobil: +49 171 9749479
Fax::?? +49 3677 6474111
Email: carsten.grzemba at contac-dt.de
contac Datentechnik GmbH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120105/e31c68fa/attachment-0001.html>

From juraj at lutter.sk  Wed Jan 18 11:24:33 2012
From: juraj at lutter.sk (Juraj Lutter)
Date: Wed, 18 Jan 2012 11:24:33 +0100
Subject: [csw-maintainers] Wintercamp 2011
In-Reply-To: <x6boq1l3me.fsf@opencsw.org>
References: <CALtRa-6zZV2X=pvUkok58X-djbaX2ezp7_boCu2hWrduEGODng@mail.gmail.com>
	<x6boq1l3me.fsf@opencsw.org>
Message-ID: <4F169DE1.10904@lutter.sk>

On 01/18/2012 11:14 AM, Peter FELECAN wrote:
> "Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> writes:
> 
>> It's 2012! Which means it's time to organize Wintercamp 2011. We had a
>> plan of meeting in Bratislava. What kind of rough timeline can we aim
>> at? I'm thinking March or April. This way, Wintercamp 2011 will be not
>> in 2011 nor in winter! ;-)
> 
> Then call it Spring 2012.
> 
> Why Bratislava?

Just because most of you haven't been here, just because Dago, Maciej
and some others have chosen my city at the time i was very new to
OpenCSW, and a bit of other reasons... Moreover, we have very good
transporation connections to Vienna, Prague, Warszaw, ...

j.


-- 
Juraj Lutter                            |  /\  ASCII Ribbon Campaign
otis (at) wilbury (dot) sk              |  \/  - NO HTML/RTF in e-mail
http://www.wilbury.sk/                  |  /\  - NO Word docs in e-mail
JID: otis (at) jabber (dot) vx (dot) sk
!07/11 PDP a ni deppart m'I  !pleH

From yann at opencsw.org  Sat Jan 21 12:14:39 2012
From: yann at opencsw.org (Yann Rouillard)
Date: Sat, 21 Jan 2012 12:14:39 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <4F1A9ADA.3020900@pleiades.fr.eu.org>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
	<4F1A9ADA.3020900@pleiades.fr.eu.org>
Message-ID: <4F1A9E1F.9020609@opencsw.org>

Oh, I just saw Rafael released Cyrus Imapd 2.4.

Did someone check that the upgrade from 2.3 went fine ?

You also upgraded berkeleydb, didn't you ?

It will probably break the setup of people who explicitely configured 
berkeleydb for cyrus database and the upgrade path should be documented.


Yann






Le 21/01/2012 12:00, Yann Rouillard a ?crit :
> Le 16/01/2012 10:33, Maciej (Matchek) Blizi?ski a ?crit :
>> Looks like we need to rebuild Cyrus imapd together with sasl. I looked
>> at the current situation and found this:
>>
>> - the unstable catalog contains version 2.3.16
>>    http://mirror.opencsw.org/opencsw/unstable/i386/5.10/catalog
>> - the website declares it's at 2.4.6
>>    http://www.opencsw.org/packages/cyrus_imapd/
>> - the build recipe is at 2.4.10
>>    
>> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/cyrus_imapd/trunk/Makefile
>> - the newest upstream version is 2.4.13
>>    ftp://ftp.cyrusimap.org/cyrus-imapd/
>>
>> I don't know how we got into this state, but in a perfect world at
>> least the first three should match.
>>
>> Yann, can you tell what's the current situation with this package?
>> What are the main challenges in getting a new version release
>
> Hi Maciej,
>
> The blocker is the migration path, upgrade from 2.3 to 2.4 triggers a 
> bug when berkeley is used.
>
> I opened a bug upstream but the developper didn't have the time to 
> work on it
> https://bugzilla.cyrusimap.org/show_bug.cgi?id=3496
>
> Any help is welcome.
>
> Yann
>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.


From yann at opencsw.org  Sat Jan 21 12:16:25 2012
From: yann at opencsw.org (Yann Rouillard)
Date: Sat, 21 Jan 2012 12:16:25 +0100
Subject: [csw-maintainers] Cyrus imapd update
In-Reply-To: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
References: <CALtRa-4pAC5Krc6sQVsQ4Ku5EV6_QkMb=3h1=+WRZ4NcYZ8_Xw@mail.gmail.com>
Message-ID: <4F1A9E89.5060801@opencsw.org>

Le 16/01/2012 10:33, Maciej (Matchek) Blizi?ski a ?crit :
> Looks like we need to rebuild Cyrus imapd together with sasl. I looked
> at the current situation and found this:
>
> - the unstable catalog contains version 2.3.16
>    http://mirror.opencsw.org/opencsw/unstable/i386/5.10/catalog
> - the website declares it's at 2.4.6
>    http://www.opencsw.org/packages/cyrus_imapd/
> - the build recipe is at 2.4.10
>    https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/cyrus_imapd/trunk/Makefile
> - the newest upstream version is 2.4.13
>    ftp://ftp.cyrusimap.org/cyrus-imapd/
>
> I don't know how we got into this state, but in a perfect world at
> least the first three should match.
>
> Yann, can you tell what's the current situation with this package?
> What are the main challenges in getting a new version release

Hi Maciej,

The blocker is the migration path, upgrade from 2.3 to 2.4 triggers a 
bug when berkeley is used.

I opened a bug upstream but the developper didn't have the time to work 
on it
https://bugzilla.cyrusimap.org/show_bug.cgi?id=3496

Any help is welcome.

Yann