pkgbuild-sfe-devel — SFE contributor mailing list

[SFE-devel] Testing github for source repository

[Thomas W. <to...@us...>]

Hi SFE Maintainers,

right now I was able to claim the name https://github.com/spec-files-extra

I'm planning for a move:

 * Moving spec-files-extra SVN over to github, including history 

 * setting up an automatic sync back from github to sourceforge

 * make sourceforge SVN read-only (except the sync user)


What would you like to see on the github side? 

How would you like to see changes to the repo pulled in?

Who should have write access to "master"?

Who should be approving integration requests?

Is it important to you to have your own commits mapped to your
github account? If yes, then don't wait to tell me your
github email address that I should use for mapping you as author.
You'll get your commits counted on your activity display
on github.

Other work to do: 
 * Recreate a few pages from the old wiki 
   (old: Mediawiki, I have the database and file on disk)

 * some notes on handling if you are new on git. 
   E.g. replacing "svn commit" with "git ...",
   how to fetch new changes from the github repo.
   General tips how to do the first git steps.
   (who can help with writing up? should be a short text!)

With git I very much hope to make contribution easy.
Especially having people fork the repo into their own
and issuing pull requests once the spec files work.

What I don't want to see is a high load on the few people
approving integration into master... how could that be
solved?

Best Regards,
Thomas
@tomww

-- 

Re: [SFE-devel] Proposal - Re: Thoughts on gcc runtime in conflict with OpenIndiana Hipster

[Alex V. <vis...@im...>]

Hi Tom,

On 08/ 2/16 09:25 AM, Thomas Wagner wrote:

> In the meantime Solaris 12 came in the way. And as my
> collegues expressed interest in LibreOffice4 on that
> upcoming Solaris 12, again the SFE-runtime and the OSdistro
> compiler signaled file conflicts..
> As developers they are naturally in the need of having
> the native GCC coming with S12 and not the SFEgcc imple-
> mentation.
>
> So I built an experimental repository for S12 with all
> the package dependencies on SFE-gccruntime dropped.
> Fingers crossed, the important LAZY_LOAD stayed mostly
> in place even when running the OSdistro gcc runtime
> instead of the SFE gccruntime.

Good. So building SFE packages on Solaris with the native gcc works for 
you. It works for me too, although I had to build gcc 4.9.3 myself using 
Solaris userland since Solaris 11.3 does not come with a pre-built gcc 
4.9.3.

> But, in either case, I do not want to go for the OSdistro
> delivered GCC, as it lacks the LAZY_LOAD fixes which need
> to be present at compile time of the target softare to
> avoid for the C++ runtime exceptions.

Yes, but my understanding is that this is not an issue on illumos-based 
distributions.You have written about this in the following blog post:

http://tom.blog.in-ulm.de/gcc-zinterpose

> The unfortunate combination is this: The ON libc.so library provides
 > C++ interfaces compiled by Studio compilers, and this library is
 > loaded *very* early at program start.
 >
> Even if gcc runtime libaries are recorded in the binary, they get
 > loaded much later in the startup of a program then the libc.so
 > library. That way the C++ code which my be in the need of C++
 > exception handling, runs into the incompatible functions bound to
 > libc.so.

Unless I'm mistaken, illumos doesn't use Studio anymore. Thus, libc.so 
gets built with gcc on OpenIndiana. This means that the C++ runtime 
exception problem is not an issue on OI Hipster.

In the same way that I use the native gcc to build SFE packages on 
Solaris 11.3, I use the native gcc on OI hipster, as I describe here:

https://wiki.openindiana.org/oi/SFE+with+enhanced+pkgbuild

Therefore, my view is the following. No response by SFE is required to 
Hipster starting to use paths like /usr/gcc/4.9/lib, because there is no 
reason for SFE to use such paths on Hipster. There is no real conflict.

There are three basic reasons for SFE to use its own gcc instead of a 
native system gcc on a given distribution:

(1) The C++ runtime exception problem
(2) The preferability of using the same gcc _version_ on all 
platforms/distributions
(3) The complication of using different gcc _packages_ on different 
platforms

As I've already said, (1) does not exist on Hipster because it uses gcc 
to build libc.so. (2) does not exist because Hipster, unlike OpenSolaris 
(and OmniOS) is always at a recent version of gcc, a version that it is 
reasonable for SFE to use itself. The complication raised by (3) is 
solved by these lines from the file mapping.yaml used by the enanced 
pkgbuild described by the Wiki page I linked to above:

SFEgcc:
- developer/gcc-49
- developer/gcc-49
- SFEgcc
SFEgccruntime:
- system/library/gcc-c-runtime-49
- system/library/gcc-4-runtime
- SFEgccruntime

While no reason exists to use SFEgcc on Hipster instead of the native 
gcc, there are reasons to use SFEgcc on other platforms. The C++ runtime 
exception problem exists on Solaris, since it uses Studio to build 
libc.so. And OmniOS does not provide a recent version of gcc, which 
raises reason (2).

Therefore, SFEgcc _must_ be used on OmniOS. However, in my view, using 
SFEgcc on Solaris 11.3-12 is optional, and should be left up to the 
user. My main computing platform is Solaris 11.3, and I have only just 
today learned about the C++ runtime exception problem, even though I 
have never used SFEgcc for anything other than testing inside a local 
zone since I started working on http://pkg.openindiana.org/sfe/. I do 
get coredumps occasionally on Solaris, and the C++ runtime exception 
could be the reason why. So I will consider switching to SFEgcc on 
Solaris. But this would in effect be a workaround. Really, I should not 
have to do this. As your blog post makes clear, the native Solaris gcc 
runtime itself should be built with -zinterpose.

I believe the approach I suggested here strikes the right balance 
between the realities of building and using SFE packages on Solaris and 
doing the same on OI Hipster. Since OpenIndiana is a free software 
project in the same way that SFE is, SFE and OI developers should be 
able to accommodate each other, so that we can all use the same gcc on 
that platform.

Regards,
Alex

[SFE-devel] Proposal - Re: Thoughts on gcc runtime in conflict with OpenIndiana Hipster

[Thomas W. <to...@us...>]

Hi Bob,

I was thinking and watching and thinking for quite a while now.
Probably I have an idea now, what to do on the SFE side to
avoid problems every now and then with OSdistro provided GCC / runtime.

I see at least 230 downloads for LibreOffcie4 for Solaris 11.
So, in practise getting file conflicts happens only very infrequently.
Nevertheless, better have no conflicts.

In the meantime Solaris 12 came in the way. And as my
collegues expressed interest in LibreOffice4 on that
upcoming Solaris 12, again the SFE-runtime and the OSdistro
compiler signaled file conflicts..
As developers they are naturally in the need of having
the native GCC coming with S12 and not the SFEgcc imple-
mentation.

So I built an experimental repository for S12 with all
the package dependencies on SFE-gccruntime dropped.
Fingers crossed, the important LAZY_LOAD stayed mostly 
in place even when running the OSdistro gcc runtime 
instead of the SFE gccruntime.

But, in either case, I do not want to go for the OSdistro
delivered GCC, as it lacks the LAZY_LOAD fixes which need
to be present at compile time of the target softare to
avoid for the C++ runtime exceptions. 
At the minimum this makes me stay with the SFE gcc imple-
mentation which gives more stable binaries in the field.
(And the SFE gcj in SFEgcc can successfully produce working
java binaries for e.g. pdftk...)


Okay, the Solaris 12 experience made me favour this solution:

In the beginning SFE was alone in /usr/gcc, that changed.
OSdistro started to copy the path and they turn out being
the steam roller ironging the SFEgcc concept.

Today I can't see that OSdistro goes out of /usr/gcc anytime
in the future. So even different GCC version numbers will
continue to claim that path for themselves.

Lucky enough, we today have no name clush in the package
names being used.

Proposal:
SFE gcc stores runtime in /usr/gcc-sfe/<major.minor>  (old: /usr/gcc-sfe/<major.minor>)
SFE gcc stores compiler in /usr/gcc-sfe/<major.minor>          ""

Package names will stay at gcc, gcc-49, gccruntime, gccruntime-49

Once the need arises, they will be accompanied by extra
packages for the transition time. Those extra packages
will only deliver symlinks in /usr/gcc/<major.minor>
pointing to the new files in /usr/gcc-sfe/<major.minor>

Situation A:
============
Upwards compatibility seen from an old SFE binary:
SFEgccruntime with *new* layout /usr/gcc-sfe/lib is installed.
symlink /usr/gcc/lib     points to /usr/gcc-sfe/<major.minor>/lib (interim)
symlink /usr/gcc-sfe/lib points to /usr/gcc-sfe/<major.minor>/lib (for ever)

If compiled with old SFEgcc, the binary/library has a runpath like this:
PATH     /usr/gcc/4.9/lib:/usr/gcc/lib

A1)
given that user has not installed OSdistro gcc compiler package,
then the SFE gcc runtime is found in /usr/gcc/lib by symlink
Same files loaded as ever.

A2)
given the user has installed OSdistro gcc compiler package,
what only a few people might have,
then the OSdistro gcc runtime is found in /usr/gcc/4.9/lib
In that case, the calling binary still has LAZY_LOAD switched off.
This is key.

In case an old SFEgcc binary/library has a problem with the
rarely installed OSdistro gccruntime, then we need to recompile
that SFE binary/library with the *new* SFEgcc to get into the
case "B" described next.

Situation B:
============
Case seen from a SFE binary compiled with the *new* SFEgcc.

If compiled with *new* SFEgcc, the binary/library has a runpath like this:
PATH     /usr/gcc-sfe/4.9/lib:/usr/gcc-sfe/lib
                 ^^^^^                ^^^^^

B1)
New binaries use on the new runpath, so libgcc_s.so and
libstdc++.so.6 are read from /usr/gcc-sfe/4.9/lib or /usr/gcc-sfe/lib.
That way, reading OSdistro gccruntime is avoided as much as possible.


I would program the changes into SFEgcc.spec but keep that new
symlinks / RUNPATH  as before. A compiletime switch to pkgbuild
would enable this behavoir so people can test this.

After a while I would make the new layout default.

Special cases:
If a spec file explicitly says "CC=/usr/gcc/4.8/bin/gcc", 
then one can decide to make a pnm macro which is smart enough
to use the right path /usr/gcc or /usr/gcc-sfe or we invent
any other way to specify a specific gcc compiler version and
does not interfere with the possibly present OSdistro gcc.


I believe we should take the proposed change for the path
and give way to the OSdisto (/usr/gcc/).


BTW: We really need to talk about SFE in public, it is powerfull
and of very good quality. Hey, we have the exciting LibreOffice 4
and soon version 5. Which other package project can say, we
span OmnniOS, OpenIndiana, Solaris 11 and Solaris 12. We can
be ported to Tribblix, OpenSXCE and even SmartOS (once we
can get /usr/ a writable Filesystem!).

Im really mean you when I say talking in public. That can be
blogging, a talk at a conference, twitter, facebook, reddit,
linkedin .... you have other ideas too? Please let me know.

The blog on sfe.opencsw.org is *open* for guest articles of
any topic related to packages. From use cases to how the
community works. Even configuration tips in any language.

Please help!

Regards,
Thomas




On Sat, May 21, 2016 at 12:02:30PM -0500, Bob Friesenhahn wrote:
>  On Sat, 21 May 2016, Thomas Wagner wrote:
> > Only OmniOS is an exception, they managed to store gcc runtime libs into 
> > one
> > directory and deliver all every published gcc runtime versions in one 
> > package.
> > The runtime linker tries to catch the right version runtime library.
> 
>  I assume that this works.
> 
> > What would SFE need to do:
> > Decide for a move of SFE gcc runtime into a new location, so new
> > packages would load SFE gcc runtime e.g. from /usr/gccruntime/4.9
> > Old packages would find a symlink in the old location for comaptibilty.
> > Once all old packages are recompiled, the symlink could vanish.
> 
>  Didn't old OI SFE already build packages using its own compiler and the 
>  package binaries dependend on its own compiler run-times?  It was not 
>  originally this way, but then packages were re-built and migrated to the new 
>  strategy.
> 
>  While there is waste of resources, it seems like OI SFE needs to be as 
>  defensive as possible and depend only on stable Illumos-provided bits, 
>  OI-provided libraries which are assured to be stable, and its own compiler 
>  and compiler run-times.  Without this, OI SFE components could break at any 
>  time due to an OI package update.
> 
>  Bob
>  -- 
>  Bob Friesenhahn
>  bfr...@si..., http://www.simplesystems.org/users/bfriesen/
>  GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
> 

-- 
-- 
Thomas Wagner

------------------------------------------------------------------------
Service rund um UNIX(TM),     Wagner Network Services, Thomas Wagner
Solaris(TM), Linux(TM)        Eschenweg 21, 89174 Altheim, Germany
Novell(TM), Windows(TM)       TEL: +49-731-9807799, FAX: +49-731-9807711
Telekommunikation, LAN,       MOBILE/CELL: +49-171-6135989
Internet-Service, Elektronik  EMAIL: wa...@wa...

Re: [SFE-devel] Thougs on gcc runtime in conflict with OpenIndiana Hipster

[Thomas W. <to...@us...>]

Bob,

now answers directly to your notes.

On Sat, May 21, 2016 at 12:02:30PM -0500, Bob Friesenhahn wrote:
>  On Sat, 21 May 2016, Thomas Wagner wrote:
> > Only OmniOS is an exception, they managed to store gcc runtime libs into 
> > one
> > directory and deliver all every published gcc runtime versions in one 
> > package.
> > The runtime linker tries to catch the right version runtime library.
> 
>  I assume that this works.
> 
> > What would SFE need to do:
> > Decide for a move of SFE gcc runtime into a new location, so new
> > packages would load SFE gcc runtime e.g. from /usr/gccruntime/4.9
> > Old packages would find a symlink in the old location for comaptibilty.
> > Once all old packages are recompiled, the symlink could vanish.
> 
>  Didn't old OI SFE already build packages using its own compiler and the 
>  package binaries dependend on its own compiler run-times?  It was not 
>  originally this way, but then packages were re-built and migrated to the new 
>  strategy.

we rarely used SFEgcc in the beginning, but as gcc 3 from Solaris got too
old, there was need for a new gcc. I remember gcc 4.4, then 4.5 and so on.
Initially OSdistro support was very short for gcc-new-version, so it has
been mostly ignored in the beginning. These days, even Solaris uses gcc 4.x
and soon 5.x to build parts of userland.
But they don't implement LAZY_LOAD off for the gccruntime, that is calling
for troubles with C++ exception handling (simple description: libc with
incomplete calls can't handle all exception calls).
 
>  While there is waste of resources, it seems like OI SFE needs to be as 
>  defensive as possible and depend only on stable Illumos-provided bits, 
>  OI-provided libraries which are assured to be stable, and its own compiler 
>  and compiler run-times.  Without this, OI SFE components could break at any 
>  time due to an OI package update.
Yes, SFE should depend on only a few of the OI provided libs. As you write,
those who can be considered stable. The idea is, the OS should really provide
a stable, non-fancy basement.

Maybe I personally have a special case with the automated builds. Once I
detect that an OS upgrade breaks a SFE binary, I can trigger a rebuild
of that compoment and get automatically a rebuild of everything ontop of
that. That mechanism is unfortunaly not implemented to the regular
SFE use who compiles by pure pkgtool. I would be happy to share the
rules/scripts I use to resolve the dependency chain and see which
spec files need uninstall/rebuild cycle. Anyone want to work on such a
script for the small SFE user? It is not too diffcult, promised.


Thanks much + Regards,
Thomas

> 
>  Bob
>  -- 
>  Bob Friesenhahn
>  bfr...@si..., http://www.simplesystems.org/users/bfriesen/
>  GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
> 

-- 
-- 
Thomas Wagner

------------------------------------------------------------------------
Service rund um UNIX(TM),     Wagner Network Services, Thomas Wagner
Solaris(TM), Linux(TM)        Eschenweg 21, 89174 Altheim, Germany
Novell(TM), Windows(TM)       TEL: +49-731-9807799, FAX: +49-731-9807711
Telekommunikation, LAN,       MOBILE/CELL: +49-171-6135989
Internet-Service, Elektronik  EMAIL: wa...@wa...

Re: [SFE-devel] Thougs on gcc runtime in conflict with OpenIndiana Hipster

[Bob F. <bfr...@si...>]

On Sat, 21 May 2016, Thomas Wagner wrote:
> Only OmniOS is an exception, they managed to store gcc runtime libs into one
> directory and deliver all every published gcc runtime versions in one package.
> The runtime linker tries to catch the right version runtime library.

I assume that this works.

> What would SFE need to do:
> Decide for a move of SFE gcc runtime into a new location, so new
> packages would load SFE gcc runtime e.g. from /usr/gccruntime/4.9
> Old packages would find a symlink in the old location for comaptibilty.
> Once all old packages are recompiled, the symlink could vanish.

Didn't old OI SFE already build packages using its own compiler and 
the package binaries dependend on its own compiler run-times?  It was 
not originally this way, but then packages were re-built and migrated 
to the new strategy.

While there is waste of resources, it seems like OI SFE needs to be as 
defensive as possible and depend only on stable Illumos-provided bits, 
OI-provided libraries which are assured to be stable, and its own 
compiler and compiler run-times.  Without this, OI SFE components 
could break at any time due to an OI package update.

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

[SFE-devel] Thougs on gcc runtime in conflict with OpenIndiana Hipster

[Thomas W. <to...@us...>]

Hi maintainers,

it is possible that SFE needs to move the GCC runtime to a new location
anytime soon for OpenIndiana Hipster.

Background: (just a glimpse)
These days OpenIndiana discovered the incompatibility of GCC 4.x and GCC 5.x
runtime and as well incompatibility on the Source side.
That means:
You can't have GCC 5.x runtime libs which are stored in a publicly searchable
location /usr/lib and run a C++ program on that library which has been
compiled with a GCC 4.x compiler. You might get the wrong version of the
runtime loaded.

Since a few years, in SFE I've build SFEgcc.spec in a way, so that a binary
searches for the GCC runtime libs in a *private* directory *first*.
That private directoy is in a versioned path like /usr/gcc/4.9/lib.
If a package IPS-requires gcc-runtime-majorversion.miniorversion (e.g. 4.9),
then you always end up with the *compatible* gcc-runtime the package has been
compiled with.
This works almost perfect in my view.

Neither Solaris 11, OpenIndiana Hipster nor OmniOS follow exactly this path.
Solaris 11, OI-Hipster deliver only one gcc runtime version into /usr/lib.
I believe OpenCSW (possibly others) copied the SFE method. This Method can
be searchd by googling for "LINK_LIBGCC_SPEC" "cookbook".

The downside of what the OSdistros do by default: Delivering the gcc
runtime into directory /usr/lib disables the possiblitly to have more then
one version of the gcc runtime at the same time.
Only OmniOS is an exception, they managed to store gcc runtime libs into one
directory and deliver all every published gcc runtime versions in one package.
The runtime linker tries to catch the right version runtime library.


I'm writing this email, because I'm expecting that the SFE project might be
forced to move the own gcc runtime into a *new* directory, at least for 
OI-Hipster "SFE"-builds. This might be needed *if* OpenIndiana Hipster
continues to deliver the GCC runtime files in /usr/gcc/4.9/lib/<libgcc_s.so|libstdc++.so.6>

In practise, only for OpenIndiana Hipster, we have a file conflict so you can
these days only install LibreOffices, if you don't install the OpenIndiana
Hipster package gcc compiler in version 4.9 or 4.8.
The odd thing is, the files /usr/gcc/4.9/lib/<libgcc_s.so|libstdc++.so.6>
delivered by OpenIndiana Hipster aren't used by OI binaries at all! 
They already deliver a gcc runtime package which delivers gcc runtime into
/usr/lib - and only these files are used in practise as far as I could see.


So, if OpenIndiana Hipster decides to implement the full method or parts of 
if as it does SFE (search gcc runtime by LINK_LIBGCC_SPEC in the /usr/gcc/4.9/lib/<libgcc_s.so|libstdc++.so.6>
location), then we loose the currently used workaround to install SFE libreoffice and
other packages:
The workaround is: Do not install OpenIndiana Hipster GCC compiler (only OI gcc runtime),
then you can install SFE gcc runtime, that is, "SFE"-files /usr/gcc/4.9/lib/<libgcc_s.so|libstdc++.so.6>.
We deliver thise files in sfe/system/library/gcc-49-runtime or sfe/system/library/gcc-48-runtime
and these sfe gcc runtime files are really *used* by all sfe-gcc compiled binaries!
The "normal" end-user doesn't detect this, as he doesn't install the
OI-Hipster compiler, only the runtime. But Developers micght be annoyed,
as hey only have the SFE gcc compiler installable if the want to install
at least one SFE package.

I would be happy if OI Hipster would implement GCC absolutely identical (I mean it by word)
then SFE does. This is: LINK_LIBGCC_SPEC *and* -zinterpose in the compiler
runtime defaults to disable LAZY_LOAD.
This is why I think we would need to move our runtime into a new location,
if OI-Hipster starts to really use the paths  /usr/gcc/4.9/lib/<libgcc_s.so|libstdc++.so.6>.
But the Quality on the OI-Hipster side would increase in my view. They
could copy the SFE way which has bneen successful since quite a while.
If the price for this to move a little on the SFE side, then okay.
You know, I would personally prefer as well Solaris 11 would use the
same approach. It would certainly help letting gcc-old and gcc-new
coexist trouble free.

What would SFE need to do:
Decide for a move of SFE gcc runtime into a new location, so new
packages would load SFE gcc runtime e.g. from /usr/gccruntime/4.9
Old packages would find a symlink in the old location for comaptibilty.
Once all old packages are recompiled, the symlink could vanish.

The dates blog articles here describe the story behind the SFE method
used for finding the runtime in a non-public location and the meaning
of -zinterpose against LAZY_LOAD of the gcc runtime:

http://tom.blog.in-ulm.de/gcc_cookbook_for_a_distribution
http://tom.blog.in-ulm.de/gcc-zinterpose

What do you think?

Regards,
Thomas
-- 
Thomas Wagner
+49-171-6135989 (no SMS/Text) http://www.wagner-net.net

Re: [SFE-devel] Fixes to pkgbuild-1.3.105 to configure on OmniOS r151016

[Bob F. <bfr...@si...>]

On Tue, 8 Dec 2015, Thomas Wagner wrote:

> Hi Bob,
>
> yes, that 1.3.105 version on SF is the latest which is published
> on that SF channel.

Does the project still have the ability to create new pkgbuild 
releases?  Is Peter Laszlo (Laca) still actively associated with the 
project and still allowed to post updates for pkgbuild?

> One could compare what is in Solaris 11.3 and for those getting hold
> of Solaris 12 can compare it from there. I just don't know if that
> pkgbuild is in sync with the oracle internal pkgbuild used to make
> Gnome.

I don't have Solaris 11.3 here.  Can you look?

> In my bootstrap script I had to patch pkgbuild with the same
> effekts then you had to. The Japan OpenSolaris Usergroup maintains
> "contrib-spec-files" and they have as well patched the pkgbuild for
> OmniOS.

This is good to hear.  For my immediate requirements, I am building 
some server applications packages (e.g. bind and apache) from a 
omnios-build derivative as found on github.  This works but does not 
seem as finely tuned as pkgbuild/SFE files.

SFE needs to fill the gap between the standard server applications 
offered with Solaris 10/11 and the much more spartan OmniOS baseline.

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Re: [SFE-devel] Fixes to pkgbuild-1.3.105 to configure on OmniOS r151016

[Thomas W. <to...@us...>]

Hi Bob,

yes, that 1.3.105 version on SF is the latest which is published
on that SF channel.

One could compare what is in Solaris 11.3 and for those getting hold
of Solaris 12 can compare it from there. I just don't know if that
pkgbuild is in sync with the oracle internal pkgbuild used to make
Gnome.

In my bootstrap script I had to patch pkgbuild with the same 
effekts then you had to. The Japan OpenSolaris Usergroup maintains
"contrib-spec-files" and they have as well patched the pkgbuild for 
OmniOS.

Regards,
Thomas


On Sun, Nov 29, 2015 at 02:54:49PM -0600, Bob Friesenhahn wrote:
>  The attached two patches were found necessary in order to be able to 
>  complete pkgbuild-1.3.105 on OmniOS r151016.  The configure.in should really 
>  be renamed to configure.ac as well.
> 
>  After applying patches, I did
> 
>    autoreconf --force --install
> 
>  Is the pkgbuild offered at SourceForge really the current release or is 
>  there a more current offering from elsewhere?  Where is the source code for 
>  it managed?
> 
>  Bob
>  -- 
>  Bob Friesenhahn
>  bfr...@si..., http://www.simplesystems.org/users/bfriesen/
>  GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

> --- pkgbuild-1.3.105-dist/configure.in	2013-04-03 23:43:19.000000000 -0500
> +++ pkgbuild-1.3.105/configure.in	2015-11-29 14:35:05.914960090 -0600
> @@ -23,7 +23,7 @@
>  PATCH_IS_GNU=no
>  $PATCH --version 2>/dev/null | grep 'Free Software Foundation' > /dev/null \
>         && PATCH_IS_GNU=yes
> -$PATCH --version 2>/dev/null | head -1 | grep '^patch ' > /dev/null \
> +$PATCH --version 2>/dev/null | head -1 | grep '^.*patch ' > /dev/null \
>         || PATCH_IS_GNU=no
>  AC_MSG_RESULT([$PATCH_IS_GNU])
>  if test $PATCH_IS_GNU = no; then
> @@ -36,7 +36,7 @@
>  SED_IS_GNU=no
>  $GNU_SED --version 2>/dev/null | grep 'Free Software Foundation' > /dev/null \
>         && SED_IS_GNU=yes
> -$GNU_SED --version 2>/dev/null | head -1 | grep 'GNU sed ' > /dev/null \
> +$GNU_SED --version 2>/dev/null | head -1 | grep 'GNU sed' > /dev/null \
>         || SED_IS_GNU=no
>  AC_MSG_RESULT([$SED_IS_GNU])
>  if test $SED_IS_GNU = no; then

> --- pkgbuild-1.3.105-dist/Makefile.am	2010-10-18 09:33:42.000000000 -0500
> +++ pkgbuild-1.3.105/Makefile.am	2015-11-29 14:31:25.133449611 -0600
> @@ -1,4 +1,5 @@
>  AUTOMAKE_OPTIONS = dist-bzip2
> +ACLOCAL_AMFLAGS = -I m4
>  
>  topdir = @TOPDIR@
>  

> ------------------------------------------------------------------------------

> _________________________________________________________________
> SFE-devel mailing list - Pkg...@li...
> http://pkgbuild.wiki.sourceforge.net/SFE
> https://lists.sourceforge.net/lists/listinfo/pkgbuild-sfe-devel


-- 
-- 
Thomas Wagner

------------------------------------------------------------------------
Service rund um UNIX(TM),     Wagner Network Services, Thomas Wagner
Solaris(TM), Linux(TM)        Eschenweg 21, 89174 Altheim, Germany
Novell(TM), Windows(TM)       TEL: +49-731-9807799, FAX: +49-731-9807711
Telekommunikation, LAN,       MOBILE/CELL: +49-171-6135989
Internet-Service, Elektronik  EMAIL: wa...@wa...

Re: [SFE-devel] Fixes to pkgbuild-1.3.105 to configure on OmniOS r151016

[Alex V. <vis...@im...>]

Yes, the official repository for pkgbuild is the CVS repository at 
SourceForge. As an experiment, I cloned that repository and put it up at 
GitHub:

https://github.com/herzen/pkgbuild/commits/ips2

I try to keep track of patches there. Maybe I will create a new "omnios" 
branch and add your patches to it. But I have nothing to do with the 
official maintenance of pkgbuild.

Besides this list, another place you might mention these patches is the 
freenode IRC channel #pkgbuild.

Alex

On 11/29/15 03:54 PM, Bob Friesenhahn wrote:> The attached two patches 
were found necessary in order to be able to
 > complete pkgbuild-1.3.105 on OmniOS r151016.  The configure.in should
 > really be renamed to configure.ac as well.
 >
 > After applying patches, I did
 >
 >    autoreconf --force --install
 >
 > Is the pkgbuild offered at SourceForge really the current release or is
 > there a more current offering from elsewhere?  Where is the source code
 > for it managed?
 >
 > Bob

[SFE-devel] Fixes to pkgbuild-1.3.105 to configure on OmniOS r151016

[Bob F. <bfr...@si...>]

The attached two patches were found necessary in order to be able to 
complete pkgbuild-1.3.105 on OmniOS r151016.  The configure.in should 
really be renamed to configure.ac as well.

After applying patches, I did

   autoreconf --force --install

Is the pkgbuild offered at SourceForge really the current release or 
is there a more current offering from elsewhere?  Where is the source 
code for it managed?

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Re: [SFE-devel] expect problems due to recent changes to OpenIndiana hipster C++ libraries

[Bob F. <bfr...@si...>]

On Wed, 3 Dec 2014, Thomas Wagner wrote:
>
> What can we do and what is your opinion on supporting OI Hipster
> which now derivates significantly from Solaris 11 in my view.

At the moment OI Hipster has a very small user base but it may become 
the basis for future stable OpenIndiana releases and therefore be the 
only open-sourced IPS-based Solaris derivative with an X11 desktop. 
It seems best to wait for OI Hipster to stabilize (e.g. perhaps in a 
year) and decide what to do then.

Most Illumos-based systems are using GCC already since there is no 
future from continuing to use the Studio compiler on an unsupported 
OS.  There are not likely any binary SFE packages for such systems.

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

[SFE-devel] expect problems due to recent changes to OpenIndiana hipster C++ libraries

[Thomas W. <to...@us...>]

Hi Maintainers,

I see that OpenIndiana Hipster now moves from Studio built
C++ libraries to G++
What I can see as well is, that they want to start changing
package names, e.g. library/g++/somelib will get library/c++/somelib.
And they as well plan to move a g++ compiled library form /usr/g++/lib
into /usr/lib and replace Sudio compiled libs completely.

I tried to convince them to leave the package names at the
old name, but I don't think they do. Same for the location move.

In the past it was easy for Solaris 11 and OpenIndiana 151a8 to
build the same stack of packages with the same spec files. The few
special cases have been solved by %if %else and some pnm_macros.
Bit there were (amlost) no *FLAGS to change changed between OI 151a8
and Solaris 11.

Now I see large problems coming (=many may exceptions to be programmed
into spec files) to support the new path OpenIndiana Hipster goes.
This is in the area of libraries formerly compiled with Studio
and contain C++ calls and the new storage location for the libs
in /usr/lib instead /usr/g++

What can we do and what is your opinion on supporting OI Hipster
which now derivates significantly from Solaris 11 in my view.

Any help in testing hipster and identifying the problem areas
and possible solutions of any kind are highly welcome.

Regards,
Thomas
-- 

Re: [SFE-devel] Problem building SFEffmpeg on OpenSolaris 2009.06

[Prashanth <pr...@gm...>]

I"m facing the same challenge in building my solaris code.. any solution 
to this please. Thanks in advance.

[SFE-devel] Action please :-) - migrate your rpo URL now - Re: read-only SVN repo, now merging the commits to the new repo - you need to switch your repo URL soon but please wait for the Okay!

[Thomas W. <to...@us...>]

Hi all,

I'm not really happy with what SF does to projects.
But it doesn't help much to complain. 

Now we have reached the successful migration of the
last writes to the old SVN repository.
The new SF SVN repo now contains the latest commits
(around April 22nd, commit 5338).
I could send two commits in (SFEopus.spec), so you'll
see repo revision 5340 now.

Your action:
****Important to get write access work for the new repository***
Now you can start relocating your local copy of the
repository to the new URL.

You might want to do a backup of your local files first,
e.g. with:

  svn diff > ~/my_copy_of_spec-files-extra-`date +'%Y%m%d-%H%M%S'`.svn_diff

and

  gtar zcf ~/my_tarball_of_spec-files-extra-`date +'%Y%m%d-%H%M%S'`.tar.gz

then switch to the new repository URL with:

svn switch --relocate  \
 https://pkgbuild.svn.sourceforge.net/svnroot/pkgbuild/spec-files-extra/trunk  \
 https://svn.code.sf.net/p/pkgbuild/code/spec-files-extra/trunk

After that, you should be able to do get updates to the repo:

  svn up

(use svn info to see the revision, should be >= 5340)



Open Issues for now:

  - Get back nice commit hooks to have email notifications of the changes.
    What we have now is highly unsatifying and I can't find out how
    SF lets us change this.

Suggestions on how to get the SF platform send us better formatted Emails
are welcome.


If you have questions, please let me know.

Regards,
Thomas


On Sat, May 25, 2013 at 10:22:12PM +0200, Thomas Wagner wrote:
> Hi all,
> 
> sourceforge now changed the old SVN repo location to read-only
> by using a commit hook script preventing the writes.
> 
> Please wait a short time until I give you an Okay to switch to
> the new repository URL and start sending commit writes.
> 
> I'll use the instructions from the SF FAQ and make a Shell-Login 
> to the Sourceforge platform. This will migrate the changes
> from the old repository to the new one which wasn't used for
> writes since the initial copy. The starting point will be
> commit 5095 from around Nov 12th 2012 up to April 2013.
> 
> I'll send you another email saying that I'm finished with the
> migration and then you can switch svn URLs and start sending
> commits again.
> 
> Please do not switch before the Okay, just to prevent accidential
> commits which would potentially mess up the repo if we change
> the same files.
> 
> About my question on changing the repository to git/mercurial/hg/
> fancyother: Thanks for your replys, I must admit there is no
> clear winner for now.
> As I don't believe that git or hg or others can do much better
> with merging conflicting changes, then we can stay with SVN 
> for a while.
> 
> Thanks much,
> Thomas
> 
> 
> ================
> 
> 
> Thats what is displayed if you did not yet switch to the new repo URL:
> 
> svn: Commit failed (details follow):
> svn: Commit blocked by start-commit hook (exit code 1) with output:
> 
> This repository has moved to a new location.  This project was upgraded to the new SourceForge platform, so a one-time move of this repo was performed.  There are instructions for switching to the new location below.  You can no longer commit to the repo at this location.
> 
> Please update your configuration with the following command:
> 
>     svn relocate ßvn+ssh://USE...@sv.../p/pkgbuild/code/"
> 
> Older versions of SVN may need to use the command:
> 
>     svn switch --relocate OLD_URL ßvn+ssh://USE...@sv.../p/pkgbuild/code/"
> 
> where OLD_URL is the URL from the output of svn info.
> 
> If you receive an error regarding mismatched UUIDs, or "Can't find entry" see
> http://sourceforge.net/p/forge/community-docs/SVN%20and%20project%20upgrades/
> for instructions on how to resolve it.
> 
> More information available at: https://sourceforge.net/p/forge/community-docs/Repository%20Upgrade%20FAQ/
> 
> result code from pkgtool  --download build-only SFEopus.spec base-specs/opus.spec && svn commit was: 1
> 
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service 
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _________________________________________________________________
> SFE-devel mailing list - Pkg...@li...
> http://pkgbuild.wiki.sourceforge.net/SFE
> https://lists.sourceforge.net/lists/listinfo/pkgbuild-sfe-devel
> 

-- 
-- 
Thomas Wagner

------------------------------------------------------------------------
Service rund um UNIX(TM),     Wagner Network Services, Thomas Wagner
Solaris(TM), Linux(TM)        Eschenweg 21, 89174 Altheim, Germany
Novell(TM), Windows(TM)       TEL: +49-731-9807799, FAX: +49-731-9807711
Telekommunikation, LAN,       MOBILE/CELL: +49-171-6135989
Internet-Service, Elektronik  EMAIL: wa...@wa...

[SFE-devel] read-only SVN repo, now merging the commits to the new repo - you need to switch your repo URL soon but please wait for the Okay!

[Thomas W. <to...@us...>]

Hi all,

sourceforge now changed the old SVN repo location to read-only
by using a commit hook script preventing the writes.

Please wait a short time until I give you an Okay to switch to
the new repository URL and start sending commit writes.

I'll use the instructions from the SF FAQ and make a Shell-Login 
to the Sourceforge platform. This will migrate the changes
from the old repository to the new one which wasn't used for
writes since the initial copy. The starting point will be
commit 5095 from around Nov 12th 2012 up to April 2013.

I'll send you another email saying that I'm finished with the
migration and then you can switch svn URLs and start sending
commits again.

Please do not switch before the Okay, just to prevent accidential
commits which would potentially mess up the repo if we change
the same files.

About my question on changing the repository to git/mercurial/hg/
fancyother: Thanks for your replys, I must admit there is no
clear winner for now.
As I don't believe that git or hg or others can do much better
with merging conflicting changes, then we can stay with SVN 
for a while.

Thanks much,
Thomas


================


Thats what is displayed if you did not yet switch to the new repo URL:

svn: Commit failed (details follow):
svn: Commit blocked by start-commit hook (exit code 1) with output:

This repository has moved to a new location.  This project was upgraded to the new SourceForge platform, so a one-time move of this repo was performed.  There are instructions for switching to the new location below.  You can no longer commit to the repo at this location.

Please update your configuration with the following command:

    svn relocate ßvn+ssh://USE...@sv.../p/pkgbuild/code/"

Older versions of SVN may need to use the command:

    svn switch --relocate OLD_URL ßvn+ssh://USE...@sv.../p/pkgbuild/code/"

where OLD_URL is the URL from the output of svn info.

If you receive an error regarding mismatched UUIDs, or "Can't find entry" see
http://sourceforge.net/p/forge/community-docs/SVN%20and%20project%20upgrades/
for instructions on how to resolve it.

More information available at: https://sourceforge.net/p/forge/community-docs/Repository%20Upgrade%20FAQ/

result code from pkgtool  --download build-only SFEopus.spec base-specs/opus.spec && svn commit was: 1

Re: [SFE-devel] SVN question after update of sourceforge platform

[Pavel H. a.k.a. h. <tro...@gm...>]

hi,
I use mercurial almost exclusively and find git quite complex so I avoid
git whenever possible.
hth
P.
On Mar 31, 2013 9:59 PM, "Thomas Wagner" <to...@us...>
wrote:

>
> Hi all,
>
> I'm wondering whats the right thing to do with the
> sourceforge SVN repository.
>
> Maybe I'm missing a step on my side and this needs
> updating to a new SVN URL and merging recent cahnges.
> I'm getting emails from the sourceforge platform that
> I use a old repository location and this needs fixing.
>
> Now the main questions are, do we have two repositories
> (old and new) and what is the repository *we* the
> maintainers are committing to? I believe most of
> us commit to the *old* svn repo.
>
> Maybe no one has yet committed to the new location,
> then we need to set the old location read-only now.
> Then change the local repository URL and commit all
> diffs since the creation of the new repository.
>
> Well, what should we do? Take the chance to switch
> to *git* (or alternatives) and make the old SVN
> repository a read-only-copy of the new git repo
> to keep the old read-only customers?
>
> sourceforge provides a few pages with informations on
> that svn upgrade:
>   http://sourceforge.net/p/forge/community-docs/Subversion/
>
> http://sourceforge.net/p/forge/community-docs/SVN%20and%20project%20upgrades/
>
> (our project was upgraded before Dec-12 2012)
>
> Maybe we just jump into the cold water and switch
> to a better SCM then svn is *now*. Especially if
> we only have the old SVN repo but not a new one
> yet (I didn't create one myself....so we don't
> have a new one?)
>
> Ideas and discussion welcome. This email typed in a
> little hurry (sorry).
>
> If you have no ideas or no preferences, just let us know
> with a short note.
>
> Regards,
> Thomas
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel(R) Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest. Compete
> for recognition, cash, and the chance to get your game on Steam.
> $5K grand prize plus 10 genre and skill prizes. Submit your demo
> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
> _________________________________________________________________
> SFE-devel mailing list - Pkg...@li...
> http://pkgbuild.wiki.sourceforge.net/SFE
> https://lists.sourceforge.net/lists/listinfo/pkgbuild-sfe-devel
>

Re: [SFE-devel] SVN question after update of sourceforge platform

[Milan J. <mil...@xy...>]

Hi Thomas,

On ne, 2013-03-31 at 22:04 +0200, Thomas Wagner wrote:
> Additional info:
> It looks like we got the SVN repo auto-migrated but
> *fortunatly* no one used the new location since the
> import. 
> 
> The last revision stamp was:
> spec-files-extra 	2012-12-11 	kenmays 	[r5095] SFEsdl-ttf.spec: bump to 2.0.11 
> (for the *NEW* repo location, so please don't start using that
> new location for the moment)
> 
> Any thoughts, should we give "git" or any other SCM
> on Sourceforge a try?
> 

please, no git. That large swiss knife is unnecessary complex with no
real benefit. If you want to migrate to distributed rcs then mercurial.
But I do not thing we need it. svn is just fine for something so simple
as spec files.

Best regards,

Milan

> Until then we can commit to the old repository location,
> but that one might become read-only any day soon.
> 
> Regards,
> Thomas
> 
> 
> On Sun, Mar 31, 2013 at 09:40:04PM +0200, Thomas Wagner wrote:
> > 
> > Hi all,
> > 
> > I'm wondering whats the right thing to do with the
> > sourceforge SVN repository. 
> > 
> > Maybe I'm missing a step on my side and this needs
> > updating to a new SVN URL and merging recent cahnges.
> > I'm getting emails from the sourceforge platform that
> > I use a old repository location and this needs fixing.
> > 
> > Now the main questions are, do we have two repositories
> > (old and new) and what is the repository *we* the
> > maintainers are committing to? I believe most of
> > us commit to the *old* svn repo.
> > 
> > Maybe no one has yet committed to the new location,
> > then we need to set the old location read-only now.
> > Then change the local repository URL and commit all 
> > diffs since the creation of the new repository.
> > 
> > Well, what should we do? Take the chance to switch
> > to *git* (or alternatives) and make the old SVN 
> > repository a read-only-copy of the new git repo
> > to keep the old read-only customers?
> > 
> > sourceforge provides a few pages with informations on
> > that svn upgrade:
> >   http://sourceforge.net/p/forge/community-docs/Subversion/
> >   http://sourceforge.net/p/forge/community-docs/SVN%20and%20project%20upgrades/
> > 
> > (our project was upgraded before Dec-12 2012)
> > 
> > Maybe we just jump into the cold water and switch
> > to a better SCM then svn is *now*. Especially if
> > we only have the old SVN repo but not a new one
> > yet (I didn't create one myself....so we don't 
> > have a new one?)
> > 
> > Ideas and discussion welcome. This email typed in a
> > little hurry (sorry).
> > 
> > If you have no ideas or no preferences, just let us know
> > with a short note.
> > 
> > Regards,
> > Thomas
> 
> -- 

Re: [SFE-devel] SVN question after update of sourceforge platform

[Bob F. <bfr...@si...>]

On Sun, 31 Mar 2013, Thomas Wagner wrote:

> Additional info:
> It looks like we got the SVN repo auto-migrated but
> *fortunatly* no one used the new location since the
> import.
>
> The last revision stamp was:
> spec-files-extra 	2012-12-11 	kenmays 	[r5095] SFEsdl-ttf.spec: bump to 2.0.11
> (for the *NEW* repo location, so please don't start using that
> new location for the moment)
>
> Any thoughts, should we give "git" or any other SCM
> on Sourceforge a try?

I find "git" to be inordinately more complex and confusing as compared 
with Mercurial ("hg").  Somehow Git has become more popular.

Before switching my project to Hg (repository on SourceForge) I used 
CVS for many years.  The only thing about Hg that I have not found 
reasonably intuitive is its behavior if the upstream repository has a 
change which has not yet been pulled and requires a merge before push 
("remote repository would have two heads").

Git offers the user with more "power" in its baseline configuration 
and this "power" makes experienced users a lot more equal than other 
users.  Some projects using Git require special knowledge about how 
the project operates before one can reasonably pull and push changes. 
It seems that Git allows pushing individual branches whereas Hg always 
keeps the whole repository in sync when it pushes (pushes all 
branches).  It is easy for the Git user to push the wrong branch and 
assume that upstream has been updated (when it has not).

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Re: [SFE-devel] SVN question after update of sourceforge platform

[Thomas W. <to...@us...>]

Hm. Alan responded to my IRC chat:
22:17 < alanc> the original spec-files (from JDS) is now hg
22:17 < alanc> https://hg.java.net/hg/solaris-desktop~spec-files


To see differences in command line usage git / mercurial(hg) see e.g.
http://www.wikivs.com/wiki/Git_vs_Mercurial

Re: [SFE-devel] SVN question after update of sourceforge platform

[Thomas W. <to...@us...>]

Additional info:
It looks like we got the SVN repo auto-migrated but
*fortunatly* no one used the new location since the
import. 

The last revision stamp was:
spec-files-extra 	2012-12-11 	kenmays 	[r5095] SFEsdl-ttf.spec: bump to 2.0.11 
(for the *NEW* repo location, so please don't start using that
new location for the moment)

Any thoughts, should we give "git" or any other SCM
on Sourceforge a try?

Until then we can commit to the old repository location,
but that one might become read-only any day soon.

Regards,
Thomas


On Sun, Mar 31, 2013 at 09:40:04PM +0200, Thomas Wagner wrote:
> 
> Hi all,
> 
> I'm wondering whats the right thing to do with the
> sourceforge SVN repository. 
> 
> Maybe I'm missing a step on my side and this needs
> updating to a new SVN URL and merging recent cahnges.
> I'm getting emails from the sourceforge platform that
> I use a old repository location and this needs fixing.
> 
> Now the main questions are, do we have two repositories
> (old and new) and what is the repository *we* the
> maintainers are committing to? I believe most of
> us commit to the *old* svn repo.
> 
> Maybe no one has yet committed to the new location,
> then we need to set the old location read-only now.
> Then change the local repository URL and commit all 
> diffs since the creation of the new repository.
> 
> Well, what should we do? Take the chance to switch
> to *git* (or alternatives) and make the old SVN 
> repository a read-only-copy of the new git repo
> to keep the old read-only customers?
> 
> sourceforge provides a few pages with informations on
> that svn upgrade:
>   http://sourceforge.net/p/forge/community-docs/Subversion/
>   http://sourceforge.net/p/forge/community-docs/SVN%20and%20project%20upgrades/
> 
> (our project was upgraded before Dec-12 2012)
> 
> Maybe we just jump into the cold water and switch
> to a better SCM then svn is *now*. Especially if
> we only have the old SVN repo but not a new one
> yet (I didn't create one myself....so we don't 
> have a new one?)
> 
> Ideas and discussion welcome. This email typed in a
> little hurry (sorry).
> 
> If you have no ideas or no preferences, just let us know
> with a short note.
> 
> Regards,
> Thomas

-- 
-- 
Thomas Wagner

------------------------------------------------------------------------
Service rund um UNIX(TM),     Wagner Network Services, Thomas Wagner
Solaris(TM), Linux(TM)        Eschenweg 21, 89174 Altheim, Germany
Novell(TM), Windows(TM)       TEL: +49-731-9807799, FAX: +49-731-9807711
Telekommunikation, LAN,       MOBILE/CELL: +49-171-6135989
Internet-Service, Elektronik  EMAIL: wa...@wa...

[SFE-devel] SVN question after update of sourceforge platform

[Thomas W. <to...@us...>]

Hi all,

I'm wondering whats the right thing to do with the
sourceforge SVN repository. 

Maybe I'm missing a step on my side and this needs
updating to a new SVN URL and merging recent cahnges.
I'm getting emails from the sourceforge platform that
I use a old repository location and this needs fixing.

Now the main questions are, do we have two repositories
(old and new) and what is the repository *we* the
maintainers are committing to? I believe most of
us commit to the *old* svn repo.

Maybe no one has yet committed to the new location,
then we need to set the old location read-only now.
Then change the local repository URL and commit all 
diffs since the creation of the new repository.

Well, what should we do? Take the chance to switch
to *git* (or alternatives) and make the old SVN 
repository a read-only-copy of the new git repo
to keep the old read-only customers?

sourceforge provides a few pages with informations on
that svn upgrade:
  http://sourceforge.net/p/forge/community-docs/Subversion/
  http://sourceforge.net/p/forge/community-docs/SVN%20and%20project%20upgrades/

(our project was upgraded before Dec-12 2012)

Maybe we just jump into the cold water and switch
to a better SCM then svn is *now*. Especially if
we only have the old SVN repo but not a new one
yet (I didn't create one myself....so we don't 
have a new one?)

Ideas and discussion welcome. This email typed in a
little hurry (sorry).

If you have no ideas or no preferences, just let us know
with a short note.

Regards,
Thomas

Re: [SFE-devel] Fixed conflict between parcellite and pkg:/gnome/locale/pl

[Milan J. <mil...@xy...>]

Hi,

committed. Thank you

Milan

On po, 2013-01-21 at 20:32 +0100, Luca De Pandis wrote:
> Hi guys,
> 
> this my first contribution to the SFE project.
> 
> In this commit, i fixed a bug of SFEparcellite. This package
> conflicted with pkg:/gnome/locale/pl, because
> the first installed the polish localization in /usr/share/locale/pl_PL
> rather than in /usr/share/locale/pl.

[SFE-devel] Fixed conflict between parcellite and pkg:/gnome/locale/pl

[Luca De P. <luc...@gm...>]

#
# spec file for package SFEnetspeed-applet
#
# includes module(s): netspeed_applet
#
# Copyright 2008 Sun Microsystems, Inc.
# This file and all modifications and additions to the pristine
# package are under the same license as the package itself.
#

%include Solaris.inc

Name:                    SFEparcellite
IPS_Package_Name:	desktop/clipboard/parcellite
Summary:                 The lightweight GTK+ clipboard manager.
Group:                   System/GUI/GNOME
Version:                 1.0.2rc5
IPS_Component_Version:	1.0.2.0.5
Source:                  %{sf_download}/parcellite/parcellite-%{version}.tar.gz
SUNW_BaseDir:            %{_basedir}
BuildRoot:               %{_tmppath}/%{name}-%{version}-build
%include default-depend.inc

Requires:    SUNWgnome-libs
Requires:    SUNWgnome-panel
BuildRequires:    SUNWgnome-libs-devel
BuildRequires:    SUNWgnome-common-devel
BuildRequires:    SUNWperl-xml-parser

%package root
Summary:                 %{summary} - / filesystem
SUNW_BaseDir:            /
%include default-depend.inc

%package l10n
Summary:                 %{summary} - l10n files
SUNW_BaseDir:            %{_basedir}
%include default-depend.inc
Requires:                %{name}

%prep
rm -rf %name_%version
%setup -q -n parcellite-%version

%build
CPUS=`/usr/sbin/psrinfo | grep on-line | wc -l | tr -d ' '`
if test "x$CPUS" = "x" -o $CPUS = 0; then
     CPUS=1
fi

export CFLAGS="%optflags" 
export LDFLAGS="%_ldflags"

aclocal
automake -a -f
autoconf -f

./configure --prefix=%{_prefix} \
            --mandir=%{_mandir} \
            --libdir=%{_libdir} \
            --libexecdir=%{_libexecdir} \
            --infodir=%{_infodir} \
            --sysconfdir=%{_sysconfdir} \
            --datadir=%{_datadir} \

sed -i.orig -e 's/pl_PL/pl/' po/Makefile
mv po/pl_PL.po po/pl.po

make -j$CPUS

%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr (-, root, bin)
%dir %attr (0755, root, bin) %{_bindir}
%{_bindir}/*
%dir %attr (0755, root, sys) %{_datadir}
%dir %attr (0755, root, other) %{_datadir}/applications
%{_datadir}/applications/*
%dir %attr(0755, root, bin) %{_mandir}
%dir %attr(0755, root, bin) %{_mandir}/man1
%{_mandir}/man1/*
%dir %attr (0755, root, other) %{_datadir}/pixmaps
%{_datadir}/pixmaps/*

%files l10n
%defattr (-, root, bin)
%dir %attr (0755, root, sys) %{_datadir}
%attr (-, root, other) %{_datadir}/locale

%files root
%defattr(-, root, sys)
%dir %attr (-, root, sys) %{_sysconfdir}/xdg
%dir %attr (-, root, sys) %{_sysconfdir}/xdg/autostart
%attr (-, root, sys) %{_sysconfdir}/xdg/autostart/*

%changelog
* Mon Jan 21 2013 - Luca De Pandis (luc...@gm...)
- Fixed conflict with pkg:/gnome/locale/pl
* Mon Oct 27 2008 - Andras Barna (and...@gm...)
- Initial spec

[SFE-devel] we shouldn't use pkgbuild 1.3.104 in Solaris11u1 binary repository?

[瀧 康史 <ta...@ju...>]

Hello, All.

Solaris 11u1 has pkgbuild 1.3.104.
But we shouldn't use pkgbuild 1.3.104 in Solaris11u1 binary repository?

We meet some error on solaris11u1 zone, while pkgbuild is compiling.

Default: set --ips
ips_utils: failed to parse line: solaris        (syspub)     origin   online T <system-repository>
ips_utils: failed to parse line: solaris        (syspub)     origin   online T <system-repository>
INFO: IPS packages will be installed by default from http://work-spec:10000/
INFO: Copying %use'd or %include'd spec files to SPECS directory
INFO: Processing spec files
Use of uninitialized value $cond in substitution (s///) at /usr/lib/pkgbuild-1.3.104/rpm_spec.pm line 1289, <SPEC_FILE7> line 14.
Use of uninitialized value $number in pattern match (m//) at /usr/lib/pkgbuild-1.3.104/rpm_spec.pm line 1861, <SPEC_FILE7> line 14.
Use of uninitialized value $cond in substitution (s///) at /usr/lib/pkgbuild-1.3.104/rpm_spec.pm line 1289, <SPEC_FILE13> line 1134.
Use of uninitialized value $number in pattern match (m//) at
/usr/lib/pkgbuild-1.3.104/rpm_spec.pm line 1861, <SPEC_FILE13> line 1134.


---------------------
Other problem,

pkgbuild: substr outside of string at /usr/lib/pkgbuild-1.3.104/pkgbuild.pl line 1474.
pkgbuild: Use of uninitialized value $relpath in concatenation (.) or string at /usr/lib/pkgbuild-1.3.104/pkgbuild.pl line 1478.
pkgbuild: Use of uninitialized value $relpath in concatenation (.) or
string at /usr/lib/pkgbuild-1.3.104/pkgbuild.pl line 1480.

When $basedir's length is longer than $fname 's.

Example...
Failed:
 [usr/postgres/] ne [usr/postgres/9.0/]
Safe:
 [usr/postgres/9.0/lib/amd64/plpython.so/] ne [usr/postgres/9.0/]



-------------------
◉ JUSTPLAYER Co.,Ltd.
-When you want is when you play-

CEO President, Founder
TAKI, Yásushi

ZIP 422-8077
3-29,Yamato 2chome,Suruga-ku, Shizuoka City, Shizuoka.
mailto:ta...@ju... http://www.justplayer.co.jp/
Blog: http://kohju.justplayer.com/
Twitter: http://twitter.com/twitter
Facebook
http://www.facebook.com/taki.yasushi

[SFE-devel] Scientific Software for OpenIndiana

[Aurélien L. <aur...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
I would like to enquire whether someone would be interested in
developing some kind of scientific software packaging initiative ?

I am a post-doc researcher in applied and computational math and I am
using OpenIndiana on my workstation and personal computing nodes.
To the question "Why ?", I would reply that it's mainly about having the
possibility to setup a RAIDZ on the workstation and then benefiting from
better data "safety" (few horror/corruption stories with ext3...), using
snapshots for my data sets and results, as well as the possibility to
rollback if a new version of numerical libraries breaks something (or
even just an upgrade).
Another good point is the good support of Nvidia graphic cards and the
fact that something on the system is not breaking after every single
upgrade...

To this regard OpenIndiana is a very good working environment for a
researcher.
The main drawback is that it requires lots of "manual" installations
which any researcher/engineer cannot afford.
Before considering using optimized libraries, one is mainly concerned
about just doing his research work :)

As the compilation and upgrade of numerical libraries and application
tends to be tedious and as I need to upgrade PETSc and friends, I am
taking the time now to package any software I am using at work.

I am currently packaging TeXLive, LaTeX Gedit plugin, Scilab, Paraview
and linear algebra and PDE solver software which have been using in the
past years.

I am using pkgbuild and SFE and here is a link to a sandbox where I
started pushing spec files I wrote this week:

https://bitbucket.org/alarcher/oi-scientific/wiki/Home

Related to this, I have then few questions:

- - What can be a good way to collaborate on packaging scientific software ?
- - Should we provide the packages through the OI SFE repository or a
separate one ? Then how ?
- - Should we focus on using GCC 4.6.3 provided by SFE ? (I personally
don't have the time to handle SUNCC gotchas if any :S)
- - Where should the "OI Scientific" project by hosted ?
- - How should we handle dependencies to OI packages ? (for instance Ant
from OI is too old for some software I am using).

Moreover, if there are enough people interested I would advocate having
a system similar to Debian Sciences with few maintainer per package and
for each a separate repository with spec files, copyright, patches,
etc... (something like Redmine ?).

So if you are interested in a joint effort in that direction, I would be
glad to hear you suggestions.

Best regards,

Aurélien






-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQr69qAAoJEA/MOW1tOCCga/8H/i6anp+u01ZtrcGRXymouxmv
5DodCaOUPMXsflEnRMnkmQnup7dPPoEBvMGOS1GtMeHzWIrQfATst5dxLyxetwNL
zPX83g9ychjAq/8xaHMt/ADt0isjhGXoofKR0UAvzPyy5eXhbvIfB2wxVHe9e/GC
zJbwAd984K5iAtEyp/AE7TpqGlx1Z1Tdt5aTyYs3BMxPSIEp7CUbjVecp/0kShoh
UmnqErmpTUEe+cVRw9EV5R4LTpBDcdahNzcm0F2cogMbKxxMn2EgGeqHh8Jkd2I6
zvHp4ROUfkqE6x1Sfr4yzXHyMnw30Ul58ye5JUYOxChY2JRc5MFDhqbP3YZjkms=
=nKLb
-----END PGP SIGNATURE-----