From dam at opencsw.org  Thu Sep  1 18:06:29 2016
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 1 Sep 2016 18:06:29 +0200
Subject: New Subversion 1.9.4 and general update on unstable hosts
Message-ID: <50C77E68-365B-4E4C-B4CF-C46C48C38D32@opencsw.org>

Hi folks,

I just pushed Subversion 1.9.4 after a long period of adjustments and the
unstable* build hosts have been udpated to the most recent unstable including
this update. Please keep an open eye and let me know if you encounter anything
suspicous.


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20160901/b0872c11/attachment.asc>

From dam at opencsw.org  Wed Sep  7 21:18:00 2016
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 7 Sep 2016 21:18:00 +0200
Subject: cannot link -lmysqlclient on unstable10x/s
In-Reply-To: <f53972e3-dff7-4539-2119-58b1aef1da4c@opencsw.org>
References: <f53972e3-dff7-4539-2119-58b1aef1da4c@opencsw.org>
Message-ID: <9EF63E55-5BCA-4CEE-BE3A-126B11060D90@opencsw.org>

Hi Jake,

Am 07.09.2016 um 17:22 schrieb Jake Goerzen via buildfarm <buildfarm at lists.opencsw.org>:
>  All of a sudden I cannot link -lmysqlclient on the buildfarm unstable10x/s hosts.
> 
> jgoerzen at unstable10x [global]:/home/jgoerzen/opencsw/dovecot/trunk > ld -L/opt/csw/lib -lmysqlclient
> ld: fatal: library -lmysqlclient: not found
> ld: fatal: file processing errors. No output written to a.out

Looks like CSWmysql56-dev was missing, don?t know why. It is installed now.


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20160907/c0b7b0ee/attachment.asc>

From jgoerzen at opencsw.org  Wed Sep  7 22:36:56 2016
From: jgoerzen at opencsw.org (Jake Goerzen)
Date: Wed, 7 Sep 2016 13:36:56 -0700
Subject: cannot link -lmysqlclient on unstable10x/s
In-Reply-To: <9EF63E55-5BCA-4CEE-BE3A-126B11060D90@opencsw.org>
References: <f53972e3-dff7-4539-2119-58b1aef1da4c@opencsw.org>
	<9EF63E55-5BCA-4CEE-BE3A-126B11060D90@opencsw.org>
Message-ID: <0bcc345f-8e69-2301-693a-8a61732f7824@opencsw.org>

Hi Dago,



On 09/07/2016 12:18 PM, Dagobert Michelsen wrote:
> Hi Jake,
>
> Am 07.09.2016 um 17:22 schrieb Jake Goerzen via buildfarm <buildfarm at lists.opencsw.org>:
>>   All of a sudden I cannot link -lmysqlclient on the buildfarm unstable10x/s hosts.
>>
>> jgoerzen at unstable10x [global]:/home/jgoerzen/opencsw/dovecot/trunk > ld -L/opt/csw/lib -lmysqlclient
>> ld: fatal: library -lmysqlclient: not found
>> ld: fatal: file processing errors. No output written to a.out
> Looks like CSWmysql56-dev was missing, don?t know why. It is installed now.
>
>
> 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
>

Thanks for fixing!


Best regards,

Jake



From dam at opencsw.org  Thu Sep  8 09:47:55 2016
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 8 Sep 2016 09:47:55 +0200
Subject: New GNU Gettext 0.19.8
Message-ID: <2A212731-95F9-4EB9-B168-0EE91788DD7A@opencsw.org>

Hi folks,

I just pushed a new GNU Gettext 0.19.8 to unstable. It took quite some effort to rebuild
and as it is used by a wide range of packages please keep an extra eye on it. If you are
wondering: as we are running continuous integration [1] for more and more projects including
automatic integration in GitHub for Pull Requests the necessity for a newer gettext arose.

Just let me know if you encounter something suspicious.


Best regards

  ? Dago

[1] https://buildfarm.opencsw.org/buildbot/waterfall

--
"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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20160908/aa819709/attachment.asc>

From cgrzemba at opencsw.org  Thu Sep  8 11:10:18 2016
From: cgrzemba at opencsw.org (cgrzemba at opencsw.org)
Date: Thu, 08 Sep 2016 11:10:18 +0200
Subject: GARCHIVEDIR for git and hg
Message-ID: <be1d99d4e7d.57d1471a@contac-dt.de>

I fiddle a little around the use of mercurial repos. 

For GIT the steps are:

fetch - clone the remote repo to DOWNLOADDIR, but if there already a cloned repo in GARCHIVEDIR (/home/src) it will take this and don't connect to the remote repository (target gitrepo:). 
If no repo in GARCHIVEDIR, mgar will clone the remote repository to DOWNLOADDIR.

makesums - don't create checksums, but copies the git repo from DONWLOADDIR to GARCHIVEDIR, if it not exists already (target $(GARCHIVEDIR)/%:)

extract - creates an archive from repo in DONWLOADDIR and extracts the archive in WORKDIR.

This leads to some unexpected behavior if the repo in GARCHIVEDIR gets old. So if you get some mysterious errors with fetch a GIT_REPOS it is a good idea to delete the repo in GARCHIVEDIR.

Related to the trouble with old repositories in GARCHIVEDIR I am wondering if it better not to use GARCHIVEDIR for GIT and Mercurial repositories? 
Or create an archive of the remote repo with name DISTNAME.tar.gz in GARCHIVEDIR instead of copy of the repo? So you can see the version of the source, sure only if the tag is not HEAD or tip.

Any thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20160908/c88bae9f/attachment.html>

From dam at opencsw.org  Thu Sep  8 12:12:06 2016
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 8 Sep 2016 12:12:06 +0200
Subject: GARCHIVEDIR for git and hg
In-Reply-To: <be1d99d4e7d.57d1471a@contac-dt.de>
References: <be1d99d4e7d.57d1471a@contac-dt.de>
Message-ID: <369DDAAD-8A40-49C1-AE04-B5D2FCAF04A3@opencsw.org>

Hi Carsten,

Am 08.09.2016 um 11:10 schrieb cgrzemba at opencsw.org:
> I fiddle a little around the use of mercurial repos.
> 
> For GIT the steps are:
> 
> fetch - clone the remote repo to DOWNLOADDIR,

The reason for GARCHIVEDIR is that stuff doesn?t get downloaded all over again every time
a spotless/package is done.

> but if there already a cloned repo in GARCHIVEDIR (/home/src) it will take this and don't connect to the remote repository (target gitrepo:).

This seems wrong. It can clone from GARCHIVEDIR, but should then also pull from origin
and push back to GARCHIVEDIR.

> If no repo in GARCHIVEDIR, mgar will clone the remote repository to DOWNLOADDIR.
> 
> makesums - don't create checksums, but copies the git repo from DONWLOADDIR to GARCHIVEDIR, if it not exists already (target $(GARCHIVEDIR)/%:)

Hmm? maybe checksums should contain the GIT Revision.

> extract - creates an archive from repo in DONWLOADDIR and extracts the archive in WORKDIR.

The Repo should be cloned and a new branch for patches in GAR should be created instead of
creating a new GIT Repository, this would make it easier to track patches. Also the cloned
repo in workdir/ could probably include a remote for garchive to permanently push patches
locally.

> This leads to some unexpected behavior if the repo in GARCHIVEDIR gets old. So if you get some mysterious errors with fetch a GIT_REPOS it is a good idea to delete the repo in GARCHIVEDIR.
> 
> Related to the trouble with old repositories in GARCHIVEDIR I am wondering if it better not to use GARCHIVEDIR for GIT and Mercurial repositories?
> Or create an archive of the remote repo with name DISTNAME.tar.gz in GARCHIVEDIR instead of copy of the repo? So you can see the version of the source, sure only if the tag is not HEAD or tip.
> 
> Any thoughts?

Yes :-)


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20160908/412c032b/attachment-0001.asc>